FRD.docx

NETCOM

Global Enterprise Fabric (GEF) Functional Requirements Document (FRD)

Version 1.4 3 September 2015

THIS PAGE IS INTENTIONALLY BLANK

DISCLAIMER

The contents of this document are not to be construed as an official Department of the Army position unless so designated by other authorized documents. The use of trade names in this document does not constitute an official endorsement or approval of the use of such commercial hardware or software. Do not cite this document for the purpose of advertisement.

CHANGES

Refer requests for all changes that affect this document to:

DISPOSITION INSTRUCTIONS

Destroy this document when no longer needed. Do not return it to the organization. Safeguard and destroy this document with consideration given to its classification or distribution statement requirements.

DOCUMENT REVISION LIST

TABLE OF CONTENTS

LIST OF FIGURES

LIST OF TABLES

FOR OFFICIAL USE ONLY

FOR OFFICIAL USE ONLY

NETC-OP-R-GEF-14-199-v1.2 iFOR OFFICIAL USE ONLY ii

FOR OFFICIAL USE ONLY

EXECUTIVE SUMMARY

This document sets forth the functional requirements for the Global Enterprise Fabric. It includes a background and a brief history of the concepts of “cloud computing” and the evolution of the LandWarNet (LWN) enterprise.

The Global Enterprise Fabric is the Network Enterprise Technology Command (NETCOM) description for a cloud enterprise hosting environment that is envisioned to provide the US Army a complete suite of computing enterprise services under three broad areas: Infrastructure as a Service, Network Services, and Computer Network Defense. NETCOM will implement these requirements to meet the Department of Defense goals of a secure network and a responsive enterprise as envisioned by the Joint Information Environment (JIE).

vi FOR OFFICIAL USE ONLY Template Ver. 2.0 / 1 Feb 13 Purpose This document sets forth the framework, terminology, and vision for the Global Enterprise Fabric (GEF) in addition to its requirements.

References DoD CIO Memorandum, “Joint Information Environment Implementation Guide,” 26 Sep 13.

Joint Staff J3, “DOD Joint Information Environment (JIE) EXORD,” 05 Dec 12.

DoD CIO Memorandum, “Department of Defense Cloud Computing Strategy,” July 12.

US Department of Commerce, “The NIST Definition of Cloud Computing,” Sept 11.

AR 25-2, Information Assurance, 24 Oct 07 (Rapid Action Revision, 23 Mar 09).

Scope The scope of the requirements laid out in this document applies to the Non-secure Internet Protocol Router Network (NIPRNet), Secret Internet Protocol Router Network (SIPRNet) and Global Mission Network (GMN) environments for all US Army units and organizations, including Army National Guard and Army Reserves. The GMN is a separate network that the Army built to extend strategic SIPRNET to the tactical formations. The intent is to merge the GMN infrastructure into the GEF using the same technical concepts of cloud, virtualization and hosted services.

Background Information technology (IT), data, computer and enterprise networks across the Department of Defense (DoD) have been steadily shifting towards a cloud computing architecture, and today, the term cloud computing is more synonymous with the term “virtualization.”

Each year, the armed forces are investing in a scalable computing services concept that is independent of hardware changes made to their underlying infrastructure. This concept is notionally called a “converged hardware architecture.” The focus of this effort is to reduce IT costs, provide consistent and timely services to users, improve management of resources from a centralized design (i.e. a converged architecture), and establish responsive security measures uniform to the enterprise. With virtualization, physical resources such as servers, clients, data storage, and networking are conserved, while delivering the following attributes:

Elasticity and Scalability – Adding new resources and services is flexible and customizable to each organization’s mission need. Operations can better handle surging demands and peak usage through the tailoring of resources from computing power, virtual machines, storage, and bandwidth utilization.

Pooled Resources – Computing, storage, and network resources are grouped in the same infrastructure environment to allow for reallocation of those resources by demand.

Customer Self-Service – Virtualization provisioning basic resources for a customer such as services, virtual machines, mailboxes, and user accounts without needing IT intervention.

Usage Monitoring and Auditing – Capturing metrics on resource consumption, reporting on installed services, and recording data for comparative baseline analysis will aid in the efficient management of the enterprise.

This trend continually evolves as the DoD seeks to leverage the armed services in adapting cloud computing strategies that will enable the department to achieve the goals of the Joint Information Environment (JIE).

0. US Army Network and Directories Evolution Steady changes in commercial IT from 2000 to 2010 have had a direct impact on the DoD and affected the US Army’s IT infrastructure. The key technology enabling IT infrastructure and networks during this time was Microsoft Active Directory (AD) built around Windows New Technology (NT) 4.0 2004 platforms. This time is considered the “Pre-Enterprise Directory Services” period, wherein the US Army IT network consisted of multiple complex environments of stand-alone hardware in noncontiguous enclaves. The decentralized aspect of the network in this earlier period added to the non-standardized “silo” effect of regionally developed AD solutions. Later, as a result of this decentralization, the US Army would have difficulty efficiently managing its network as an IT enterprise.

Starting in 2010, NETCOM has made great strides to bring the LWN enterprise to what it is today, a “Multiple Directory Services Environment.” Gone are the many noncontiguous network enclaves as a result of implementing an AD domain forest collapse throughout the enterprise. In its place are the contiguous multiple domain forests that will shape the LWN into an even more consolidated environment. However, today’s environment still has challenges regarding compliance and security, infrastructure complexity, and “server sprawl.” Table 1 gives a snapshot of users in the enterprise and the projected numbers of current domain controllers (DC) from the continued consolidation of the LWN enterprise based on the current method of deploying servers.

Table 1: Domain Controller Consolidation

0.1 NETCOM’s GEF

The GEF is NETCOM’s concept to meet the US Army’s goal of fulfilling the DoD JIE vision. However, meeting that goal requires transformative steps that mediate the evolution of the LWN enterprise and, in a deliberate manner, balance the needs of the US Army with JIE.

NETCOM envisions a “Theater Forest Single Domain Model” with five theater and functional domains: US Army Pacific (USARPAC), US Army Europe (USAREUR), South West Asia (SWA), Korea, and Continental United States (CONUS). The GEF, under this model, will establish “Enterprise Directory Services” on the Windows 2012 platform. It will be 100% virtualized, centralized, and standardized with JIE, Joint Regional Security Stack (JRSS), JIE Management Network (JMN) Multi-Protocol Label Switching (MPLS) networks, and security stack architecture. Figure 1 below depicts the periods the LWN enterprise has undergone transition and consolidation.

Figure 1. LWN Transition Periods Envisioning the US Army GEF In addition to the continual consolidation of the Active Directory (forests and domains) directory services, NETCOM envisioned approach to the GEF hosting environment will take into account its computing enterprise services in three broad areas: (i) Infrastructure as a Service, (ii) Network Services, and (iii) Computer Network Defense. Each computing enterprise service, having a broad area, is supported by specific services or “capabilities”. These services are evaluated in status and “rolls up” to give an overall status of the area in which they are organized. By establishing these three broad areas, NETCOM believes it will enable the ability to centrally manage and view the overall “health” status of its network.

Figure 2, below depicts how these services are organized in our current environment to present a “Network Health Hierarchy”.

Figure 2. Network visibility vision on the GEF NETCOM envisions that the GEF will allow for centralized management and monitoring as the LWN enterprise matures into a cloud computing environment.

0.2 Converged Architecture Objectives

The Enterprise Fabric features a convergence of the US Army architecture in three broad areas:

Hardware converged architecture, where computing and network hardware are integrated, shared resources for the hosted infrastructure services (shown in Fig 2);

Virtual converged architecture, where virtual machines (VM) host each infrastructure service stored in a Storage Area Network (SAN)’s array;

Army converged services, where enterprise management systems are used for maintaining the environment.

This approach is to package hardware architecture in three configurable sizes for the GEF: small (IFN), medium (RFN or IFN), and large (DFMN), which are intended for deployment across US Army posts, camps, and stations within the enterprise. The GEF will consolidate the architecture at each site with the following objectives in mind.

a. Build Operate, Maintain, Defend, and “See the Core Operating Environment (COE) End-to-End”

b. Global unfettered access to information

c. Global standard for Army networks, workstations, servers, applications, and data

d. Secure/reliable service, anywhere, anytime

e. Synchronization with JRSS solution

f. Centralized management, monitoring, and reporting

0.2.1 Converged Architecture Goals

Listed as follows are the envisioned engineering fabric pod goals:

a. Support for multiple diverse workloads

b. Full end-to-end high-availability

c. 100% virtualization

d. 100% automation

e. Self Service Portal for Administration and Guests

f. Sub-system scale-out for the following:

i. Compute

ii. Storage

iii. Networking

g. Reduction of cost to serve

h. Removal of middleware

i. Hardware platform independent

j. Just-in-time hardware provisioning US Army GEF Program Benefits Listed as follows are the envisioned benefits the GEF will offer:

a. Faster Deployment

i. End-to-end architectural and deployment guidance

ii. Streamlined infrastructure planning due to predefined capacity

iii. Enhanced functionality and automation through deep knowledge of infrastructure

iv. Integrated management for VM and infrastructure deployment

b. Reduced Risk

i. Tested end-to-end interoperability for computing, storage, and networking

ii. Predefined, out-of-box solutions based on a common cloud architecture

iii. High degree of service availability through automated load balancing

c. Lower Cost-of-Ownership

i. Near-zero downtime with exceptional fault tolerance, providing high availability

ii. Dynamic Pooling that can enhance the use of virtualization resources by combining Hypervisor and supported storage and network devices

iii. Use of low-cost switches that consume less power and deliver high throughput for large bandwidth requirements US Army GEF Overview The GEF is conceived primarily as a hosting platform to virtualize the US Army NETOPS Enterprise capabilities and Directory Services at various US Army sites. The NETOPS Enterprise Capabilities currently used consists of Enterprise Directory Services (DS) and Authentication, Host-Based Security Systems (HBSS), ITSM/Remedy, Spectrum, Microsoft System Center, REM/Retina (Assured Compliance Assessment Solution) and Security Incident Management System (SIMS). These and other capabilities to include regional and local applications would be hosted as “workloads” or virtualized servers on a converged architecture.

A converged architecture refers to sharing a network topology between traditional network traffic and storage traffic. This means Ethernet network devices and network controllers must have converged features that will provide the segregation, quality of service (performance), and scalability for the fabric pod. The goal is for the GEF to be physically less complex, possess greater agility, and have lower costs than those solutions associated with traditional Fiber Channel-based storage networks.

NETCOM envisions that the topology needed must support the many storage systems used in converged architecture, including hyperconverged designs with traditional SANs and Server Message Block (SMB) 3.0-enabled SANs in order to integrate within the environment. The main points in a converged architecture are that all storage connectivity is network-based (iSCSI, FCoE for converged designs and network file system (NFS) or common Internet file system (CIFS) for hyperconverged designs), and it uses a single media type for traffic (such as copper. NOTE: Small Form-Factor Pluggable (SFP)+ adapters are more commonly used.

NETCOM envisions that the key difference between the fabric pod and traditional converged systems will be how the servers (shared computing) connect to the storage, and the advanced networking features provided by converged network adapters (CNA). High-density server blade systems must feature advanced hardware options that present physical or virtual network adapters to the virtual host, while supporting a variety of protocols. Figure 3 depicts NETCOM’s analysis of the requirements expressed as a minimum hardware specifications (see Paragraph 7, Hardware Requirements, for a more detailed specification). Alternative solutions, configurations and specifications from industry will be considered.

Figure 3. NETCOM’s Analysis for Minimum Hardware Specifications *NOTE: Alternative solutions, configurations and specifications from industry will be considered.

Operational Requirements These principles, defined below, help power the GEF elasticity and also distinguish it from a traditional local area network (LAN) in which key pieces are virtualized. While virtualized LAN deliver some of the benefits of virtualization, such as increased utilization, an enterprise fabric model includes automation and management capabilities that can mean revolutionary changes in how the Army delivers enterprise IT services and how users consume them.

Resource Pooling The GEF depends on the flexible pooling of computing (processor and memory), storage, networking, and software resources. This pooling helps deliver greater utilization and efficiency and is powered by virtualization, which abstracts the platform from the physical infrastructure. Multiple consumers—such as multiple customers or multiple organizational units—can share pooled resources, resulting in higher resource utilization and efficiency for both planners and users.

Elasticity and Perception of Infinite Capacity From the user’s perspective, GEF services should appear to have infinite capacity. End users can consume as much or as little of the service as needed, just as they consume electricity. This perception is possible because, in contrast to a reactive approach that leads to inefficient resource use, the private cloud facilitates proactive capacity planning so that the infrastructure can satisfy peak requests on demand. This principle helps achieve greater balance between the cost of unused capacity and the desire for agility.

0.3 Perception of Continuous Availability

From the user’s perspective, GEF services should always be available when needed. The consumer should never experience an interruption in IT services, even if failures occur within the cloud infrastructure. To achieve this continuous availability, the private cloud architecture delivers a highly automated environment in which infrastructure redundancies, such as failover clustering, are complemented by intelligent automation and management capabilities.

0.4 Predictability

Both Regional Cyber Centers (RCCs) and users require predictability from a private cloud infrastructure. For consumers, GEF services should be consistent—they should have the same quality and functionality each time they are used.

To achieve this predictability, the virtualized environment standardizes functions across physical servers, network devices, and storage. This standardization helps to assure consistent treatment of hosted workloads, even during fluctuating demand. With virtualization, users can also benefit from predictability on the service Planner’s side of the console through its management and automation tools, which standardize service offerings and processes. This predictability is a fundamental requirement if planners are to deliver on the potential of a virtualized environment.

0.5 Service Planner’s Approach to IT

Historically, when units needed new or expanded IT services, they purchased the necessary components and then built an infrastructure specific to the service requirements. The result was often disappointing in terms of agility and also meant delays, duplicate infrastructure, increased costs, and poor utilization.

With virtualization units can instead make use of IT as a set of services they consume rather than as a collection of hardware they deploy. The virtualized environment helps planners provide infrastructure as a service (IaaS) so that users can consume what they need when they need it, avoiding an underutilized, duplicating infrastructure. In addition, the shared resource model means planners can take advantage of economies of scale and greater agility in providing additional services or expanding existing ones.

0.6 Multi-Tenancy

The GEF can be subdivided for each mission partner and provision logically isolated resources to different customers. Users can also benefit from the multitenant capabilities of the GEF infrastructure because resources can be provisioned for distinct organizational units within the Army LWN, which facilitates usage metering and chargeback.

0.7 Security and Identity

The private cloud delivers strong security for cloud computing through three pillars:

Protected infrastructure Application access Network access The GEF uses security and identity technologies to protect both physical and virtual hosts, information, and applications in the data center. These technologies take advantage of the least-privileged user account access principle—an approach that ensures that users always log on with limited user accounts until they are granted additional privileges.

The GEF will secure application access through integration with the DoD’s and Army Identity and Access Management (IdAM) system. IdAM is an enterprise capability that would be hosted as a workload on the fabric. This identity foundation ensures that users have secure access to IT resources within the enterprise by using numerous devices.

Network access in the private cloud is secured at the perimeter through the JRSS and through Host-Based Security System (HBSS, a DoD mandated capability). Internet Protocol Security (IPsec) also enables logical isolation of server and domain resources so that administrators can limit access to authenticated and authorized computers. Alternative solutions will be considered if proposed.

Enterprise System Hardware Defined Requirements Based on the Army’s analysis, the fabric pod, such as the DFMN is envisioned to have at least the following hardware requirements for computing, network access, and storage, and are presented in the following tables (Tables 2-4) as a proposed hardware specification, based on the government’s assessment of current technologies. Alternative solutions, configurations and specifications from industry will be considered. All hardware and software components must be on the DOD DISA Approved Products List (APL).

Table 2. Requirements - Enterprise Hardware, Compute Compute Requirements

7.2.1. Configured with at minimum a primary and redundant compute centers with “n” number of machines for hosting virtualization

7.2.2. Configured to characteristically represent “small,” “medium,” and “large” compute centers with at least 10 cores per CPU with hyper threading support, and having at least two physical CPUs.

7.2.3. Equipped with 256 GB host RAM minimum, and upgradeable to a minimum 512GB.

7.2.4. Will have the minimum number of servers per cluster, which is four for optimal load balancing and availability

7.2.5. Will have at least two 10GbE ports per server.

7.2.6. Must fully support Out-Of-Band Management (OOBM, also referred to as “Lights-Out Management”) enabling full KVM access to the server.

7.2.7. Server must support booting from internal SD Card or internal USB drive.

Table 3. Requirements - Enterprise Hardware, Networking Network Requirements

7.3.1. Must be capable of Link Aggregation such as link aggregation control protocol (LACP).

7.3.2. Must have local-to-host virtualized storage controllers for supporting IP Storage.

7.3.3. Must have ability to tag/allow multiple VLANs on individual Ethernet ports or aggregate links.

7.3.4. Must be able to support fully redundant 10GB Ethernet ports.

7.3.5. Switch must be not more than 2U and support 1GbE and 10GbE and 8/16Gb native Fibre Channel on all slots.

7.3.6. Minimum of 32 fixed ports.

7.3.7. Must support Layer 2 and Layer 3 traffic on all ports.

7.3.8. All physical network devices must be able to be monitored by US Army network monitoring tools.

7.3.9. Any network element must use two or more authentication servers for the purpose of granting administrative access.

7.3.10. Have at least separate switch infrastructure to support out-of-band management supporting 100Mb Ports.

Table 4. Requirements - Enterprise Hardware, Storage Storage Requirements

7.4.1. Automated tiering across all disk storage pools or disk provisioning groups.

7.4.3. Ability to dynamically allocate Flash Drive capacity to Storage Processor read and write cache for increased performance and serve the entire array, or selectively choose which pools to support.

7.4.4. Must support Solid State Hard Drives.

7.4.5. Must support multi-drive, multi-protection level, and performance tiering within a storage pool.

7.4.6. Must have storage processors able to support of Multi Core CPU Processing.

7.4.8. SLA 4 Hour acknowledgement time in the event of technical issues with a 24 hour resolution time.

7.4.9. System must have 99.999% availability/uptime

7.4.10. Storage tiering among multi-tiered, in-memory caches, SSD and HD.

7.4.11. Must support Disk Storage Pools or Disk Provisioning Groups.

7.4.13. Storage Pools or Provisioning Groups must support Solid State Disks as well as all speeds of traditional mechanical disks.

7.4.14. Must be able to mix drive types within the same disk shelf.

7.4.16. Must provide user selectable data protection levels

7.4.17. Must be able to support a minimum of 150,000 or more IOPS

7.4.18. Disks may not be used in more than one Disk Storage Pool or Disk Provisioning Group at a time.

7.4.19. Must support 8/16GB Fibre Channel and/or 10GbE Network connectivity.

7.4.20. Must support block level storage.

7.4.21. Must support LUN snapshots or more granular, per-VM snapshots.

7.4.22. Must support the use flash memory for system I/O caching.

7.4.24. Must do block or variable length deduplication.

7.4.25. Must do block or sub-block compression.

7.4.26. Must be able to present thin provisioned storage resources.

7.4.27. Proposed solution must not be end of life

7.4.29. Must have scalable storage for growth capacity.

7.4.30. Must employ or support existing data-at-rest encryption solutions currently used by the US Army.

Site-Level Hardware Defined Requirements The following are requirements for the installation fabric node (IFN), typically at the site garrison level based on the government’s assessment of current technologies. The IFN is characteristically the Army Network Enterprise Center (NEC) and is a “service” node as it sends data to the management node. Alternative solutions, configurations and specifications from industry will be considered.

Table 5. Requirements - Site Hardware, File to Object-Object Gateway Data Ingester Requirements

8.5.1. Solution supports file sharing over global namespace and global locking and NAS integration with object store.

8.5.2. Data at Rest Encryption - Data stored in all of the components of the solution is encrypted at rest.

8.5.3. Data in Flight Encryption - Communications between all of the components of the system are encrypted.

8.5.4. Full support for standard NAS features, such as AD (including Windows 2012 AD), LDAP, CIFS, NFS, and S3.

8.5.5. Supports Content Sharing/Roaming Home Directories - Users can easily access content from any site.

8.5.6. Supports a Global Access Topology and namespace, with multi-layer caching (on the endpoint, in site caches, and in content distribution caches) and selective pre population capabilities allowing users and applications to access data from the device nearest in proximity for improved collaboration, continuity, performance and streamlined availability processes.

8.5.7. Supports Adaptive Cloud Tiering - adapts to changes in file metadata, then automatically tiers corresponding content to the appropriate private or public cloud storage tier for enhancing TCO and security.

8.5.8. Multi-cloud support within same namespace, so to host different data sets in different cloud tiers; such as S3 enabled services.

8.5.9. Supports replication, data protection and file restore without requiring additional HW or SW. Supports file system point in time snapshots for recovery of file and folders by both the administrator and the end users.

8.5.10. Compatible granular archive policies that provide the capability to tier storage from local devices to consolidated storage, to archive storage for long term data retention.

8.5.11. Supports granular archive policies to version, deleting and report on data based upon retention policies.

8.5.12. No system wide single point of failure.

8.5.13. Supports Active data protection, data integrity monitoring and healing.

8.5.14. Supports Replication and failover capabilities between remote sites and central object store.

8.5.15. Supports local or remote restoration.

8.5.16. Perform an immediate recovery of all file system metadata in case of a failure.

8.5.17. Supports OpenStack - can replace Swift as Datastore.

8.5.18. Supports de-duplication (variable and fixed block) and compression of data (No Single instance storage).

8.5.19. Must Support Object Store Caching as well provide a Virtual Appliance.

8.5.20. Upgrades can be performed online with no 0% downtime

8.5.21. Must support high-speed bus, disk and data protection architectures.

8.5.22. Storage architecture is Active/Active meaning - Any data can be accessed by any port within the system with no additional latency, providing the user has appropriate tenant privileges.

8.5.23. All content moved to central object repository.

8.5.24. Must support intelligent caching keeps active data set in cache with the remaining content retrieved on demand from central object store.

8.5.25. Allow NAS migration for existing filers and servers.

8.5.26. Supports file restore for user self-service.

8.5.27. Supports content sharing in a distributed cloud environment.

8.5.28. Has a fast RTO with single server recovery in minutes, regardless of volume of data.

8.5.29. Must Support multi-site read/write operations maintaining consistency and providing locking capabilities.

8.5.30. Must support CIFS/NFS simultaneous access to same file system.

8.5.31. Ability to extend backup retention of existing backup solutions.

8.5.32. Single Management view of all data center object and can integrated with storage assets.

8.5.33. Ability to support HDFS with shared object storage system.

8.5.34. Ability to load data via object analyze via HDFS within Object store.

8.5.35. Integrated User Self Service Portal within Object Store.

8.5.36. Integrated Showback / Chargeback system within Object Store

Site-Level Backup Software for Virtual Infrastructure Defined Requirements The site level requires an agentless architecture that is application-aware for backups and recovery, along with file, application-item, and in-place restores without agents, based on the government’s assessment of current technologies. Alternative solutions, configurations and specifications from industry will be considered.

Table 6. Requirements - Site Hardware, Backup to Disk Backup Software for Virtual Infrastructure Requirements

9.6.1. Agentless architecture.

9.6.2. Application-aware backup and recovery.

9.6.3. File, application-item and in-place restores without agents.

9.6.4. Image Based application that pulls API data calls from the hypervisor.

9.6.5. "End to End" 256 AES Encryption (At Source, In Flight & At Rest).

9.6.6. Recovery Explorers for: Exchange, Active Directory, Share Point and SQL (a way to find the items when you don't recall the file, folder, table name faster by doing an Explorer Search).

9.6.7. Instant VM Recovery - Ability to launch a VM directly from a de-duplicated compressed backup file located on a backup repository (storage device). Allowing, for instant, restart from failed VM's without having to extract that file from the backup repository, rehydrate the file, and un-compress the file back into your production storage device. Ability to launch a failed VM in minutes.

9.6.8. Ability to test backups and verify backups can be recovered without restoring to production via launching the OS and doing a Ping test from the backup hardware in order to ensure everything was backed up correctly.

Enterprise System Hypervisor Defined Requirements The hypervisor is the virtualization part of the fabric pod. In the GEF it is the software piece on the fabric pod that creates and runs virtual machines. The fabric pod on which a hypervisor is running one or more virtual machines is defined as a host machine, and each virtual machine is called a guest machine that will be a server to host a capability. The hypervisor requirements are presented in the following tables based on the government’s assessment of current technologies. Alternative solutions, configurations and specifications from industry will be considered.

Table 7. Requirements - Hypervisor Hypervisor Requirements

10.7.1. The hypervisor has to interoperate with and be managed by Army tools (e.g., SCCM)

10.7.2. The hypervisor must demonstrate dynamic resource allocation by responding to changing workloads, demonstrate rapid and high elasticity for added VM’s, appliances and nodes, using templates, snapshots and cloning.

10.7.3. The hypervisor requires the ability to implement standardization by designing custom templates and "macros"

10.7.4 Hypervisor must demonstrate the ability to adequately manage and be managed by another hypervisor from another vendor through the use of an Enterprise Manager Software intermediary.

10.7.5. Hypervisor must support minimal or no additional development for interfaces to support Army Capabilities at no additional cost

10.7.6. Hypervisor must demonstrate reasonable resiliency and reliability in the event of temporary loss, or degraded services with US Army Enterprise Capability (e.g. NETOPS capabilities) like NTP, DNS, or AD.

10.7.7. The Hypervisor must interoperate and conform to industry hypervisor standards to include but is not limited to OpenStack.

Enterprise System Management Defined Requirements The management requirements of the fabric pod are confined to the converged architecture’s software, commonly known as an enterprise manager system. It is generally a bundled or integrated suite of software components used for monitoring the enterprise (centralized management), while controlling the fabric pod (decentralized execution). It is specialized software for the converged architecture that sits “above” the hypervisor and is designed to receive real-time or near-real-time data feeds from every system component in the enterprise, providing a “roll up” picture of the overall enterprise status and performance. Table 8 indicates the requirements based on the government’s assessment of current technologies. Alternative solutions, configurations and specifications from industry will be considered.

Table 8. Requirements - Enterprise Manager System Enterprise Manager Requirements

11.8.1. The Enterprise Manager Software must have features that will allow for the creation, management and access control of a “single pane of glass” for an operational picture on the enterprise health, status, standardization and performance.

11.8.2 The Enterprise Manager Software must include tools that will allow for the inspection, analysis and reporting of compliance for DoD DISA IA STIGS, GPO’s, Army Golden Master (AGM) versioning as part of enforcing enterprise standardization.

11.8.2. Enterprise Manager Software must include alerting features that immediately notifies of any fabric node administrators actions that could potentially harm, degrade or exceed a fabric node existing capacity, and include “failsafe” features that can only be overridden by another authority.

11.8.3 The Enterprise Manager Software must support an “applications store (AP store)” and “Service Catalog” to include the tools to manage it.

11.8.4 The Enterprise Manager Software must have customization for a “single pane of glass,” operational picture to support “Big Data” presentation, discovery analysis and reporting. It must be able to enforce standardized views, while allowing for views specific to a capability, region and or site level.

11.8.5 The Enterprise Manager Software must provide or support customizable automated functions for provisioning resources. “Blueprinting” or “onboarding” of capabilities must be standardized with custom templates having input parameters, where upon instantiation will allocate, create and place VMs for that capability with minimal effort.

11.8.6 The Enterprise Manager Software must be able to smartly support any identified XaaS (“X” being a variable, for example “Infrastructure”, “Data Base”, “Security” etc “as a Service”) with ease of provisioning, placement and management.

11.8.7 The Enterprise Manager Software must be able to demonstrate “elastic” response to dynamically scale up or scale down resources with ease in anticipation or response to workload changes and without interruption of operations for the existing VM’s in the fabric.

11.8.9 The Enterprise Manager Software must demonstrate effective VM lifecycle management from the instantiation, operation, maintenance, decommissioning and archiving of the VM, its hosted application and data.

11.8.10 The Enterprise Manager Software must provide sufficient application, data and VM back up abilities in supporting Contingency of Operations Plans (COOP) for recovery and restoration purposes in the event of a catastrophic loss within or at a fabric node.

11.8.11 The Enterprise Manager Software must demonstrate sufficient application, data and VM replication of varied topologies and granularity, back up and moving abilities within and between fabric nodes in support of unspecified daily operations and COOP operations.

11.8.12 The Enterprise Manager Software must efficiently demonstrate the ability to immediately identify and isolate sources of classified “spillage” for analysis, “sanitation,” remediation and release.

11.8.13 The Enterprise Manager Software will effectively demonstrate the ability to host “image based” applications that allows application program interface (API) data calls from the hypervisor.

11.8.14 The Enterprise Manager Software will support the minimally acceptable US Government encryption standard for NIPR and SIPR enclaves when required.

11.8.15 The Enterprise Manager Software will provide a safe testing environment for VMs before its introduction into the operational fabric on the node, and provide “roll back” features to recover the VM from the fabric in the event the VM is unsuitable.

11.8.16 The Enterprise Manager Software must allow for data redundancy policies providing options for single host failures and simultaneous failures with no impact to data availability.

11.8.17 The Enterprise Management Software must have software defined networking (SDN) features and can allow, support or enhance load balancing the traffic between VMs, the VM gateways and external components to the DFMN for “elastic network security,” to include automating or manually adjusting restrictions, control, and network traffic between local, “within-the-node” and enterprise devices and services.

11.8.18 The Enterprise Management Software must allow, support or enhance SDN with rapid implementation and operational efficiency through configurable SDN templates.

11.8.19 The Enterprise Management Software SDN abilities must address network infrastructure through the needs of networked VM services and applications itself.

11.8.19 The Enterprise Management Software must support a message notification system for logging and reporting events that will be flagged for performed automated actions (e.g. self-healing) or manual actions needing attention (e.g. service desk/capacity manager operators) such as customer’s requests or changes to or for capacity.

11.8.20 Enterprise Manager Software must demonstrate automated “self-healing” features for the fabric node.

11.6.21 The Enterprise Management Software must demonstrate robust qualities to ensure “safety and security” by configurable policy that can enforce “Two Person Integrity (TPI)” using workflows, alerts, notifications and or use existing ticketing systems for some of the more critical aspects of operating the fabric node.

11.6.22 The Enterprise Management Software must support defined customer self-service abilities empowering capability managers to manage their own enterprise services with minimal intercession from the capacity operator manager and without adverse impact to the fabric node.

11.6.23 The Enterprise Manager Software must provide or support tools that will give “true” utilization of fabric resources like disk space, to report what is actually consumed, e.g. allocated disk space for an application apart from what is actually used within that allocation of that disk space.

11.8.24 The Enterprise Manager Software must have or support “Chargeback” or “Showback” or “metering” abilities of the resources consumed by each application running on the shared infrastructure, and showing “recoverable IT costs” that would translate to a “cost savings report” to a capability manager.

11.8.25 Software licensing fees must stay within the budget of every Fabric Node (i.e. no “true-up costs”), or leverage existing ELA arrangements between the software vendor and the US Army

Vendor Enterprise System’s Support Defined Requirements The US Army wants to move away from providing direct support and technical refresh of hardware and software components, in an effort to save on funding and manning for resources. The US Army also wants to only manage the fabric pod in an operational setting. This means support must be provided by the vendor during the life cycle of the fabric pod. The vendor must respond to the build, delivery, installation, maintenance, and decommissioning of the hardware and software components, with the provision NETCOM will project manage the effort by coordinating access to various Army camp, post, and stations. The vendor must have personnel with the appropriate technical expertise as well as Government security clearances for NETCOM to effectively project manage the vendor’s build, delivery, installation, maintenance, and decommissioning of the hardware and software components of the fabric pod. Additional detailed requirements are given below, in Table 9.

Table 9. Requirements - Vendor's Systems Support System’s Support Requirements

12.9.1 The vendor will demonstrate and perform efficient patch maintenance of the integrated components of the converged architecture, to include but is not limited to, firmware updates, software driver updates and enterprise manager updates.

12.9.2 The vendor will demonstrate 99.99% uptime of the VM servers on the converged architecture without disruption of service during hardware and software patching and update installs.

12.9.3 The vendor will demonstrate little or no performance degradation for the VM servers on the converged architecture when performing software patching and updates. Any performance degradation will not exceed 24 hours.

12.9.4 The vendor will perform patching and update installs on the hardware aspect of the node onsite located though out the US Army’s secure computing facilities. If permitted, remote access to patching and update resources from the site is only permissible on the Unclassified enclaves.

12.9.5 The vendor performing patching must rely on approved DOD storage medium for patching when remote access to patching and update resources are not available.

12.9.6 Any DOD approved storage medium used by the vendor for patching and updates becomes the property of the US Army for NETCOM’s disposition to IA.

12.9.7 The vendor will use NETCOM lab resources to test firmware and hardware patches and updates and demonstrate their soundness before implementation to the production management and service nodes.

12.9.8 All hardware and software tested in NETCOM lab resources will have an active Authority to Operate (ATO) and certificate of networthiness (CoN) before their release and implementation on the operational environment.

12.9.9 The vendor must demonstrate the converged architecture solution is reliable and robust enough to allow NETCOM to adopt a next business day service support agreement for a significant cost savings.

12.9.10 The vendor will provide a 5 year warranty and support on the hardware, and will respond to a critical hardware part replacement in the event of an identified “HazCon” or hazardous condition (i.e. eminent catastrophic failure).

12.9.11 The vendor must provide training to the operator on any standard and customizable features that enable the operation and monitoring of the converged architecture solution.

12.9.12 The vendor will provide support when needed to assist in the “onboarding” or the migration of US Army capabilities (“structured data”) from physical-to-virtual with regards to its application and data, as well as with site level onboarding with “unstructured data.”

12.9.13 The vendor must provide all documentation on the converged architecture solution in an organized and comprehensible presentation that is reproducible and releasable by the US Army for official use.

12.9.14 The vendor must be available to participate, write and provide technical expertise to NETCOM when NETCOM is developing further documentation, per US Army document format, on their accepted converged architecture solution, to include but is not limited to concepts of operations (CONOPS) and enterprise technical procedures (ETP) documents.

12.9.15 The vendor must deliver a single integrated system in a single shipment per installation site (i.e. no “piecemeal” shipments).

12.9.16 The hardware solution the vendor provides will run on DoD approved STIG-ed software and/or US Army software systems to include but is not limited to AGM, and the NETOPS capabilities.

Generalized Functional Requirements The GEF is envisioned to feature a layered architecture in which virtualization abstracts operating systems, data, applications, and user states from the underlying hardware. These layers enable the wide range of automation and management capabilities that differentiate a cloud infrastructure from a highly virtualized LAN. The layered architecture develops complex workflow and automation over time as various software pieces do the following:

Create a collection of simple automation tasks.

Assemble those tasks into procedures that are managed by the management layer.

Create workflows and process automation that are controlled by the orchestration layer.

These layers are envisioned as Automation, Management, Orchestration, Services Management, Self-Service and Security. Alternative solutions, configurations and specifications from industry will be considered.

0.8 Automation Layer

The ability to automate all expected operations over the lifetime of a hardware or software component is critical. Without this capability threaded throughout all layers of the infrastructure, dynamic processes stop as soon as user intervention or other manual processing is required.

The automation layer is made up of the foundational automation technology plus a series of single-purpose commands and scripts that perform operations such as starting or stopping a VM, rebooting a server, or applying a software update. These units of automation or workflows are combined and executed by higher-level management systems. The modularity of this layered approach dramatically simplifies development, debugging, and maintenance.

0.9 Management Layer

The management layer consists of the tools and systems used to deploy and operate the infrastructure. In most cases, this consists of a variety of different toolsets for managing hardware, software, and applications. Ideally, all components of the management system would take advantage of the automation layer and not introduce their own protocols, scripting languages, or other technologies (as it increases complexity and may require additional staff expertise).

The management layer is used to perform activities such as provisioning the SAN, deploying an operating system, or monitoring an application. A key attribute is its abilities to manage and monitor every component of the infrastructure remotely and to capture the dependencies among all of the infrastructure components.

0.10 Orchestration Layer

The orchestration layer takes advantage of the management and automation layers. In much the same way that an enterprise resource planning (ERP) system manages a business process such as order fulfillment and handles exceptions such as inventory shortages, the orchestration layer provides an engine for IT-process automation and workflow. The orchestration layer is the critical interface between the IT organization and its infrastructure.

Ideally, the orchestration layer provides a graphical interface in which complex workflows that consist of events and activities across multiple management-system components can be combined, so as to form an end-to-end IT business process, such as automated patch management or automatic power management. The orchestration layer must provide the ability to design, test, implement, and monitor these IT workflows.

0.11 Services Management Layer

The Service Management layer provides the means for automating and adapting IT service management best practices, such as those found in the IT Infrastructure Library, to provide built-in processes for incident resolution, problem resolution, and change control.

0.12 Self-Service Layer

The Self-Service layer provides an interface for private cloud tenants or authorized users to request, manage, and access the services, such as VMs, provided by the cloud architecture. Using role-based access control and authorization, the Self-Service layer provides the ability to delegate certain aspects of administration (such as starting/stopping VMs) to designated “workload administrators.”

0.13 Security

Security for the GEF is founded on the following three pillars:

Protect the infrastructure with coordinated security technologies and controls at each layer of the architecture. These controls follow a defense-in-depth strategy, which assigns users, processes, and IT components a level of trust that governs review priority.