RPS Software Design
Last updated on January 13, 2021.
Last Reviewed and Approved on PENDING REVIEW
Introduction
The Rapid Provisioning System (RPS) is designed to provide a mobile, modular, and extensible framework that allows coded automation activities to be executed across a wide area network environment with limited connectivity and bandwidth. This solution was designed to survive the inherent constraints and challenges that have been observed within a mobile tactical network. RPS is designed to be a flexible solution for programs with similar constraints and automation requirements. This document will outline the technology, approach, and functionality provided by this solution.
Basic RPS Definitions
This section provides the definition for terms that are used throughout this document. Refer to this section for how these terms are being used within the RPS system.
| Term | Definition |
|---|---|
| Cmdlet | A lightweight command that is used in the Windows PowerShell environment |
| Configuration Item (CI) | A vehicle that contains entity definitions |
| DSC | Microsoft’s PowerShell Desired State Configuration software package |
| RPS Node | A running instance of the RPS system |
Constraints and Challenges of a Tactical Environment
There are many constraints and challenges inherent to a mobile tactical network:
- Network capability is limited to modern satellite and line-of-sight (LOS).
- Vehicles don't always have network connectivity for extended periods of time. This period can range from a few days to several weeks.
- When a satellite connection is available, vehicles experience extremely high latency combined with extremely low throughput.
Line-of-sight (LOS) provides an improvement in the network capabilities of the vehicle but has limited accessibility when vehicles are on the move (OTM).
Immediate response capabilities for combat situations:
- RPS is designed as a combat-ready system to support the warfighter in the field.
- Service downtime must be schedulable and interruptible.
- RPS is designed as a combat-ready system to support the warfighter in the field.
Long lead times to field changes:
- Time for changes to hardware and software takes years to progress from adoption to operating in a fielded solution.
- Fielded solutions often have a long lifespan due to costs associated with high cost to upgrade and difficulty implementing changes to the field.
- The RPS solution will be designed to use the latest commercial off the shelf (COTS) solutions to provide for the longest possible lifespans.
Design Goals
The RPS toolset is designed to provide the following functionality to meet the requirements of the tactical Environment:
- Targeted automation across various device types (routers, switches, radios, servers, etc.).
- Codependency on automation tasks (To accommodate cross-device requirements and prerequisites).
- A componentized automation model to simplify development of automation tasks.
- An extensible toolset to meet automation needs to accommodate environmental variances.
- Offline automation capabilities, specifically the ability to discretely operate with limited or no connectivity to upper-tier systems.
- Low-compute capabilities for executing on low resource systems.
Architectural Overview
The RPS system is designed to provide the infrastructure upon which various PORs can extend to automate tasks specific to their missions and deployments.
RPS Functionality
The common set of functionalities provided by RPS is shown below.
- User interface to manage task assignments and executions – Provides the ability for a user to manage the provisioning process at a granular level. The user can start, halt, and return feedback on provisioning processes for a specific target item.
- Coordinated Automation – Provides the ability to automate and coordinate a variety of tasks.
- Content Synchronization – Provides the ability to synchronize content across RPS nodes to support the tasks being automated.
- Interface to Services & Data – Provides a standard interface to access RPS services through a well-documented API.
- Telemetry Services – Provides the ability to collect heuristic information from a system.
- IP Spreadsheet Capabilities – Provides the ability to read in the standard TNACC/TNIC provided IP spreadsheet and deliver expected results.
RPS Components
| Component | Core Technology | Description | Functionality Mapping |
|---|---|---|---|
| Application Server | IIS | Provides the capability to host a web application. | UI |
| Configuration Management | DSC | Underlying configuration management framework to specify, setup and maintain a desired machine configuration. | Coordinated Automation Content Synchronization Interface to Services and Data UI |
| Content Delivery | BITS, DFSR | Underlying content delivery framework to replicate and deliver content across the network. | Content Synchronization |
| Core Modules | C#, PowerShell | RPS specific implementation to provide a generic capability to perform task automation. This includes all the RPS runbooks, modules and capabilities that are exposed via the RPS API. | Coordinated Automation, Content Synchronization, Interface to Services and Data, Telemetry Services, IP Spreadsheet Capabilities |
| Data Persistence | PostgreSQL Server | Underlying data storage that maintains the metadata needed by the system to manage the task automation. Commonly referred to as RPS CMDB. | Coordinated Automation |
| Messaging Service | C# | Underlying messaging framework to provide command and control communication capability between RPS nodes. | Content Synchronization |
| RPS Web Application | .ASP.NET MVC, IIS, jQuery, Knockout, C# | RPS specific user interface to allow a user to initiate automated tasks on target systems. | UI |
| Task Management Service (TMS) | Windows Service / RPS Phyr | Automated Task Management service used to process RPS Task Assignments. | Coordinated Automation |
Note
Refer to each component’s individual documentation for more details on the internals of each component.
Data Persistence (CMDB)
The detailed software design documentation for this component is available at:
RPS > Documents > Operations > RPS Data Persistence (CMDB) Design.docx
Automation Framework
The detailed software design documentation for this component is available at:
RPS > Documents > Operations > RPS Automations Package Guidelines.docx
Configuration Management
The detailed software design documentation for this component is available at:
RPS > Documents > Operations > RPS Configuration Management (DSC) Design.docx
Content Delivery
The detailed software design documentation for this component is available at:
RPS > Documents > Operations > RPS Content Management.docx
Messaging Service
The detailed software design documentation for this component is available at:
RPS > Documents > Development > RPS Sync Services.docx
Application Server
The application server provides the ability to host a web application. RPS uses Microsoft’s IIS web server to provide this capability.
RPS Web Application
The detailed software design documentation for this component is available at:
RPS > Documents > Software > TODO
Software Development Kit (SDK)
The RPS SDK provides the developer-oriented documentation for the RPS system. It will include:
- RPS binary code
- Sample PowerShell source code runbooks
- RPS > Documents > Samples
- API and cmdlet documentation
- RPS > Documents > Development > RPS API Documentation.PDF
RPS Server Architecture
The RPS server architecture is intended to provide scalability for most automation requirements. To accommodate this, each RPS node will be able to either operate on its own or receive instructions from another RPS node. Those instructions will provide operations information to the RPS solution to request executions of automation code, or to manage its own environment.
Software Requirements
The RPS infrastructure requires the following software:
- A Microsoft Windows operating system (Windows Server 2012 R2 or greater)
- The core operating system version the solution will run on.
- RPS API
- Provides the .NET and PowerShell modules necessary to access, manage and maintain a RPS Node.
- PostgreSQL database
- Provides the underlying PostgreSQL database support for the custom Configuration Management Database (CMDB)
- Task Management Service (TMS)
- RPS Task Management
- .NET Framework 5
- Provides enhanced PowerShell frameworks and support for advanced automation.
- Windows Management Framework (WMF) 5.1
- Extends PowerShell support to enhance Desired State Configuration functionality.
- Microsoft Distributed File System Replication services (DFSR).
- Background Intelligent Transfer Service (BITS)
- Software for maintaining content distribution over slow, unstable WAN links.
- RPS Sync Service
- Provides Windows service to synchronize RPS nodes.
Server Role Minimum Requirements
| Role | CPU Cores | Hard Disk (GB) | RAM (GB) |
|---|---|---|---|
| CDN | 2 | 100 (Depends on content) | 4 |
| GUI | 2 | 50 | 4 |
| PostgreSQL | 2 | 10 | 2 |
Server Architecture
It is important to note that the server layout of the RPS components is designed to be fluid based on requirements. This section will outline the software components of the RPS architecture and how they interact, rather than the server architecture of a specific implementation.
The software components of a given node can be placed on any server layout provided network communications and software prerequisites are available. Each collection of RPS components is identified as a “RPS Node”. These nodes are intended to operate both individually, and in a distributed workload capacity. Node layouts will vary based upon the requirements of a given implementation. For example:
- Single server RPS node (all software on one system)
- Multi-server RPS node (each component on its own instance of Windows across multiple servers)
RPS API - PowerShell Module and Data Access
The RPS API is a single library to be used in conjunction with the RPS CMDB. The API provides .NET and PowerShell interfaces for managing and manipulating RPS data and actions.
PowerShell and API Functionality
Table 2 outlines the available actions the RPS API and PowerShell module offers to support and maintain the RPS environment.
| High Level Actions | Purpose |
|---|---|
| Managing RPS Infrastructure Data | Actions such as registering and managing RPS nodes and their relationships to each other. |
| Managing Resource Assignments | Manage Assignments between Resource Items and Target Items. |
| Managing Resource Items | Manage resources, their properties, and metadata. |
| Managing Target Items | Manage Target Items, properties, their relationship to other items, and other item related metadata. |
| Managing Tasks | Provides the commands necessary to manage and register tasks. |
| Managing Task Assignments | Manage Assignments between Tasks/Task Maps and Target Items. |
| Managing Task Maps | Manage Task Maps and their definitions, what tasks to run, what their dependencies are, filtering criteria, etc. |
| Misc. Toolset Functionality | Actions such as resets, initiating Task Map evaluations, setting requests for user-interaction, or other functions that may not necessarily directly relate to CMDB data. |