RPS Software Design
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 |
|---|---|
| RPS Node | A running instance of the RPS system |
| Configuration Item (CI) | A vehicle that contains entity definitions |
| DSC | Microsoft’s PowerShell Desired State Configuration software package |
| Cmdlet | A lightweight command that is used in the Windows PowerShell environment |
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 site
- It is common for vehicles not to 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 site 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.
Long lead times to fielded 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 automations across various device types (routers, switches, radios, servers, etc.).
- Codependency on automations tasks (To accommodate cross-device requirements and prerequisites).
- A componentized automations model to simplify development of automations tasks.
- An extensible toolset to meet automations needs to accommodate environmental variances.
- Offline automations 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 functionality 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 |
|---|---|---|---|
| Data Persistence | MS SQL Server | Underlying data storage that maintains the metadata needed by the system to manage the task automations. Commonly referred to as RPS CMDB. | Coordinated Automation |
| Automation Framework | MS SMA | Underlying automations framework used by RPS to provide RPS automation of tasks. | Coordinated Automation |
| 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 | Underlying content delivery framework to replicate and deliver content across the network. | Content Synchronization |
| Messaging Service | C# | Underlying messaging framework to provide command and control communication capability between RPS nodes. | 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 |
| Application Server | IIS | Provides the capability to host a web application. | UI |
| 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 |
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 automations 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 automations 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 the solution will run on
- RPS API
- Provides the .NET and PowerShell modules necessary to access, manage and maintain a RPS Node
- Microsoft SQL Server 2012
- Provides the underlying SQL support for the custom Configuration Management Database (CMDB)
- Provides the core SQL services to SMA
- Microsoft Service Management Automation (SMA)
- Automation engine
- .NET Framework 5
- Provides enhanced PowerShell frameworks and support for advanced automations
- Windows Management Framework (WMF) 5.1
- Extends PowerShell support to enhance Desired State Configuration functionality
- Microsoft Distributed File System Replication services (DFSR)
- 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) |
|---|---|---|---|
| SQL | 4 | 20 | 4 |
| SMA | 2 | 60 | 4 |
| GUI | 2 | 50 | 4 |
| CDN | 2 | 100 (Depends on content) | 4 |
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, or 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)
- Single server RPS node, multiple SMA runbook workers on multiple servers
- Multi-server RPS node (each component on its own instance of Windows across multiple servers)
- Multi-server RPS node, multi-SMA runbook workers (separate component installs, multiple SMA runbook workers)
Sample RPS Architecture
A sample RPS deployment is shown in Figure 3. This architecture places systemically similar components on separate compute entities to maximize efficiency.
Figure 4 illustrates a multi-node RPS hierarchical architecture. In this example, the Master Node may exist in the cloud; however, this is not a requirement.
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 Tasks | Provides the commands necessary to manage and register tasks. |
| Managing Target Items | Manage Target Items, properties, their relationship to other items, and other item related metadata. |
| Managing Resource Items | Manage resources, their properties, and metadata. |
| Managing Task Maps | Manage Task Maps and their definitions, what tasks to run, what their dependencies are, filtering criteria, etc. |
| Managing Resource Items | Manage Assignments between Resource Items and Target Items. |
| Managing Task Assignments | Manage Assignments between Tasks/Task Maps and Target Items. |
| 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. |
| Managing RPS Infrastructure Data | Actions such as registering and managing RPS nodes and their relationships to each other. |