Contract Document-Amendment-0007.docx

28321319R00000017 Amendment 0007

Table of Contents

SECTION A - Standard Form 1449 (SF 1449)

SECTION B – STATEMENT OF WORK (SOW)

The term of this contract will be for a potential period of performance of fourteen years, which includes requirements for Hardware, Software, Support, and Maintenance.

Minimum Government Guarantee: $100,000.00

Maximum Contract Ceiling: To Be Determined At Award

All delivery and task order pricing shall be consistent with the Hardware, Software, Support and Maintenance prices included in the Pricing Tables attached herein.

Period of Performance February 3, 2020, through February 2, 2034, if all options are exercised.

***Note: Italicized terms are defined in Definitions Attachment 3.

This is an Indefinite Delivery-Indefinite Quantity (IDIQ) contract with terms for the issuance of firm-fixed price delivery/task orders using the ordering procedures as described in Section D.

1. Overview

1.1. Mission

The Social Security Administration (SSA) is responsible for administering national social insurance programs and social welfare programs, and for providing operational systems support to other Federal and State agencies. SSA will use this Contract to purchase open systems storage hardware and software to store and manage data created by the agency’s programs.

The Office of Deputy Commissioner of Systems (DCS) is responsible for the planning, implementation and operation of computer systems in support of the SSA. It provides software support, hardware support, telecommunications support, and production to improve and modernize SSA's computer systems. In support of the DCS goals which support the Agency's mission, Office of Systems Operations and Hardware Engineering (OSOHE) is responsible for delivering 99% overall availability to the user community of the 65 major applications systems throughout the Continental United States (CONUS). Within OHE, Division of Systems Storage Management (DSSM) assures the integrity, security, and efficient utilization of all enterprise-wide storage media resources for SSA. DSSM manages state-of-the-art storage technologies utilizing disk, flash storage, and NVMe media to ensure that the Agency's data can be available and accessed when needed. DSSM is responsible for data storage backup and recovery operations and advises senior management of all aspects of storage media management.

1.2. Objective

The objective of this Indefinite Delivery Indefinite Quantity (IDIQ) contract is to acquire a Contractor’s proposed hardware, software, maintenance and support for SSA’s Open Systems (OS) Enterprise Disk Storage Infrastructure. This hardware will be located in SSA sites throughout the CONUS.

1.3. Scope of Work

This Contractor shall provide open systems storage for the agency. This Contract will allow SSA to collect, process, secure, encrypt, and protect all agency data. The Contractor shall deliver, install, and provide warranty and maintenance support OS storage hardware and software at all CONUS SSA sites.

1.4. OS Storage Subsystems Hardware and Software Requirements Summary

SSA requires delivery and installation of OS storage hardware, storage management software, and five-year warranty support. At the end of the warranty support, SSA estimates that at least one year of maintenance support will be needed for all storage hardware. Depending on the software, one or more years of maintenance will be required.

The hardware and software must include features for data at rest encryption, subsystem control, local replication, remote replication, thin provisioning, block level automated tiering, server-based path failover, storage reporting, and any other requirements detailed in Subsection 2 of this Statement of Work (SOW). For hardware that does not include block level automated tiering, all flash storage shall be included in the hardware.

1.5. OS Storage Connectivity Requirements Summary

SSA requires delivery and installation of OS switch and director hardware, storage management software, and five-year warranty support. SSA estimates that at least one year of maintenance support will be needed for all switches and directors purchased from this Contract.

The hardware and software must include features for switch and director Storage Area Network (SAN) zoning, switch and director reporting, and any other requirements detailed in Subsection 2 of this SOW.

1.6. OS De-duplication Appliance Hardware and Software Requirements Summary

SSA requires delivery and installation of OS de-duplication appliance hardware, storage management software, and five-year warranty support. SSA estimates that at least one year of maintenance support will be needed for all De-duplication Appliance Hardware and Software purchased from this Contract.

The hardware and software must include features for de-duplication appliance control, data at rest encryption, support for Veritas NetBackup data and Oracle RMAN, in-line and source-based de-duplication remote replication, and any other requirements detailed in Subsection 2 of this SOW.

1.7. OS Storage Virtualization Appliance Hardware and Software Requirements Summary

SSA requires delivery and installation of OS storage virtualization appliance hardware, storage management software, and five-year warranty support. SSA estimates that at least one year of maintenance support will be needed for all Storage Virtualization Appliance Hardware and Software purchased from this Contract.

The hardware and software must include features for control software, pooling storage from multiple storage devices, moving data between multiple storage arrays, remote replication, support for active-active server metro clusters in the same data center, and any other requirements detailed in Subsection 2 of this SOW.

1.8. Warranty and Maintenance Support Requirements Summary

The Contractor shall perform all warranty and maintenance support for all hardware and software. The Contractor shall arrive on site for problem identification, as well as any other requirements detailed in Subsection 2 of this SOW, within three-hours after SSA reports the problem.

1.9. Implementation and Support Requirements Summary

SSA requires support that include training, online support, and full time on-site Systems Engineer (SE) support at the Perimeter East Building (PEB), formerly the National Computer Center (NCC), National Support Center (NSC), and Second Support Center (SSC). SSA will issue task orders for specific work such as Customer Engineer (CE) or SE support, data erasure support, hardware relocation support, an OS yearly storage study, site shutdown support, and data migration.

1.10. Definitions See Attachment 3

2. Contractor Responsibilities

2.1. General Requirements

2.1.1. Commercially Available – The Contractor shall provide commercially available release levels for all hardware and software. Beta versions are unacceptable.

2.1.2. Replication Network - SSA’s remote replication network is currently a separate Ethernet Transmission Control Protocol and Internet Protocol (TCP/IP) based network. The remote replication network is completely isolated from SSA’s TCP/IP messaging network. All remote replication must occur via SSA’s remote replication network. For all remote replication connections, the Contractor shall provide any hardware and software needed to connect to the SSAs remote replication network. The remote replication network connections must have a minimum speed of one Gigabit per second (Gbps). The remote replication ports must be located on a minimum of two Input/Output (I/O) interfaces on the storage hardware. For any storage subsystem that requires Ethernet TCP/IP switches to be included in the storage subsystem configuration, the Contractor shall configure the storage subsystem as defined in 2.1.2.1 or 2.1.2.2.

2.1.2.1. The Contractor shall configure the subsystem with at least four physical Ethernet switches. The same switches must not connect to both SSA’s TCP/IP messaging network and SSA’s remote replication network;

2.1.2.2. The Contractor shall configure the switches without an internal network with routing disabled or the switches must be layer two unmanaged switches. At least two switches must be provided and configured with the storage subsystem.

2.1.3. Training - The Contractor shall provide classroom training to SSA on how to support the storage subsystem hardware. The training must focus on support for, hardware, software, and upgrades related to the proposed solution. SSA IT specialists and SSA IT managers will attend the training classes. The training classes must be offered throughout the first seven years of this contract. Training may occur at the Contractor’s site or be a live interactive online class. Classes must be all inclusive with all materials included. Classes can last as few as one day to as many as five days with a minimum of eight hours per day. The Contractor shall provide the SSA employee a certificate of completion of the training to certify that the employee has completed the training. The COTR and the Contractor will mutually agree on the date and time of the training classes prior to the award of the Task Order. The Training CLINs 200-1 and CLIN 200-2 are for one person per class.

2.1.4. Installation - The Contractor shall preform on-site installation of all hardware ordered from this Contract.

2.1.4.1. The COTR will determine the time frames available for installing all hardware and software. The COTR and the Contractor will mutually agree to establish a schedule for installation for the hardware and software.

2.1.4.2. Prior to starting any hardware and software installation, the Contractor shall report to SSA’s Systems Problem Resolution Branch (SPRB) to get approval to start the installation work. For hardware installations, the Contractor shall provide SPRB the SSA’s assigned device name for the hardware and the serial number of the hardware. SPRB will provide the Contractor the location of the hardware. Refer to Subsection 2.8 for more information about SPRB.

2.1.4.3. Prior to the Contractor leaving the site, the Contractor shall report to SPRB the status of the hardware installation.

2.1.4.4. The Contractor shall notify SPRB and Contracting Officer's Technical Representative (COTR) and Alternate COTR via e-mail when the hardware or software installation is complete.

2.1.5. Compliance with the Agency Security Policies - All Contractors that need access to any of SSA locations and/or access to SSA’s systems shall acquire Homeland Security Presidential Directives (HSPD) -12 identification cards.

2.1.5.1. Access to manage or change the hardware supplied by the Contractor must meet the following minimum password-security requirements.

2.1.5.1.1. All access points to the hardware including operating systems on service processors must be password protected.

2.1.5.1.2. Passwords must support a minimum of eight characters.

2.1.5.1.3. Passwords must support numeric, alphabetic, and special characters.

2.1.5.1.4. After the install of any hardware and software, the manufacture default passwords must be changed.

2.1.5.2. The Contractor shall email the COTR and Alternate COTR immediately upon employee resignation/termination.

2.2. General Hardware and Software Requirements

Unless otherwise stated, the following requirements apply to all subsystems.

2.2.1. Hardware Reliability - The Contractor shall configure all hardware and software to minimize loss of data and loss of server access to the data stored on the hardware. All proposed hardware must not have one or more components that are a single point of failure that may result in the loss of data and/or loss of server access to the data stored on the hardware.

2.2.2. Non-disruptive Microcode or Firmware Updates or Replacements - The hardware and software must have the ability to update or replace the controller microcode or firmware without having to shut down either the storage hardware, servers, or remove access to the attached storage hardware.

2.2.3. Failure Detection - The hardware and software must have the ability to detect a failed component or to detect when a component within the unit exceeds certain preset thresholds and alert the Contractor to take reparative action. The hardware must have the ability to automatically notify the Contractor and simultaneously notify via e-mail the SSA COTR or task manager when a failure occurs. When the Contractor receives this notification, SSA considers this point in time as the start of the three-hour response time. Refer to Subsection 2.8.10 where the three-hour response time requirement is defined.

2.2.4. Type of Hardware - The Contractor shall provide only new hardware including replacement parts.

2.2.5. Hardware Cabinets - The Contractor shall provide hardware cabinets/frames that do not exceed a height of 84 inches, a width of 30 inches, and a depth of 48 inches. The Contractor shall install the hardware with a front to back airflow that forces the heated exhaust air towards the back of the cabinet/frame. Input air (supplied by SSA) must enter through the front of the cabinet above the floor.

2.2.5.1. The Contractor shall provide at least two input power supplies for each cabinet, frame or device with input connectors each capable of independently supplying all needed power to the entire cabinet, frame or device from one power source.

2.2.5.2. The Contractor shall provide cabinets/frames to house all the hardware included with the storage subsystems, appliances, SAN directors and de-duplication appliances. All the cabinets/frames must have 208 Voltage Power Outlets built into the Rack.

2.2.5.3. All frames/cabinets must have power outlets compatible with three-phase 208V power receptacles or must be capable of utilizing single-phase L630 power receptacles.

2.2.5.4. The Contractor shall provide all connectors (both plugs and receptacles) needed to connect the proper voltage/amperage to each delivered subsystem system bay, storage bay, or SAN director. All receptacles must include a conduit adapter kit with grounding straps for connection to SSA’s supplied 3/4" power whips (e.g. for Russellstoll receptacles, they have a /C75 suffix for a 3/4" conduit).

2.2.5.5. The Contractor shall provide all required input voltage power plugs with attached cords required to connect to the receptacles.

2.2.5.6. The Contractor shall provide cabinets that support both overhead and under the floor cable systems including all power cables.

2.2.5.7. The Contractor shall provide cabinets that support environmental and power metering including the following features:

2.2.5.7.1. The cabinets must contain smart power strips.

2.2.5.7.2. The cabinets must contain front and rear temperature and humidity probes with ability to calibrate the probes.

2.2.5.7.3. The smart power strips must support reporting ampere measurements to the 10th of an ampere.

2.2.5.7.4. The smart power strip must support Simple Network Management Protocol (SNMP) to automate reporting of environmental and power values.

2.2.5.7.5. The smart power strip must contain a Network Interface Controller (NIC) Registered Jack-45 (RJ45) to support connection to network.

2.2.5.7.6. The Contractor shall use SSA supplied cabinets unless using SSA cabinets will jeopardize Loss of Data Warranty or Contractor’s Best Practices indicate Contractor supplied cabinets should be used.

2.2.6. Cabinet Hot Air Containment - The Contractor shall provide Hot Air Containment at the NSC and E-Vault in one of three ways (determined by the Contractor) for any hardware being installed in non-SSA supplied cabinets (i.e. Vendor-Supplied Cabinets):

2.2.6.1. A sealed cabinet that blocks air from front to back and only allows front-to-back airflow through the hardware itself (all other areas must be blocked). Hot air must be released via a rear top mounted chimney that is no more than 24 inches deep from the back of the cabinet and no wider than the cabinet itself. Chimney must be adjustable to reach 140 inches to 144 inches with an additional 2-inch rubber seal where it meets the ceiling tiles. Together they would be adjustable between 142 inches and 146 inches.

2.2.6.2. A sealed cabinet that blocks air from front to back and only allows front-to-back airflow through the hardware itself (all other areas must be blocked). Hot air must be released via perforated back door only.

2.2.6.3. A sealed cabinet that blocks air from front to back and only allows front-to-back airflow through the hardware itself (all other areas must be blocked). Hot air must be released via perforated back door and/or perforated top of cabinet. The perforated top of cabinet (no chimney) must either 1) be less than 24 inches from the back of the cabinet to the front or 2) any area that exceeds 24 inches must be blocked with a solid covering.

2.2.7. Data Erasure Software - The Contractor shall provide software that SSA will use to erase all data from a storage subsystem. The software must erase all data stored on the hardware in accordance with the most current version of Department of Defense (DoD) 5220.22-M data sanitization standard The Contractor shall provide data erasure software for all data storage hardware types in this contract.

2.2.8. Network Attached Storage (NAS) Access Requirements - All NAS storage subsystems must be capable of both read and write access at the same time from various operating systems e.g. Solaris, Linux, Microsoft and Windows. The NAS storage subsystems must also be capable of both read and write access at the same time from virtual servers hosted on VMware, Microsoft Hyper-V, and Oracle physical servers. All NAS storage subsystems must support Network File System (NFS) versions 3 and 4 and Common Internet File System (CIFS)/Server Message Block (SMB) version 3. All NAS subsystems must also support SSA security Control Minder for NFS shares on Unix Servers and Active Directory for Common Internet File System CIFS/SMB shares on Windows servers and Red Hat IPA for NFS shares on Linus servers.

2.2.9. Internet Protocol Version 6 (IPv6) - The Contractor shall ensure that that products and services that use the Internet Protocol provide full feature functionality in both dual stack (IPv4 and IPv6) and IPv6-only environments comply with National Institute of Standards and Technology United States Government version 6 Testing Program, see Special Publication 500-267, A Profile for IPv6 in the U.S. Government – Version 1.0. The contractor must notify the contracting officer of all contract specifications that do not comply with providing full feature functionality for IPv6 and act per the instructions of the contracting officer.

The contractor shall provide documentation that an accredited laboratory tested the product and showed it to be IPv6 capable/compliant or the contractor shall provide a Supplier’s Declaration of Conformity (SDOC) attesting to the IPv6 capability/compliance of their product(s). The agency will use submitted SDOCs to evaluate and compare product offerings prior to award.

Find the template for the SDOC at http://www-x.antd.nist.gov/usgv6/sdoc.html NOTE: Following acquisition and installation, if the agency finds a product is not IPv6 capable/compliant, despite the contractor’s SDOC, the contractor must remedy the deficiency to the agency’s satisfaction and at no cost to the agency.

2.2.10. Maintaining Compatibility – SSA will periodically update its hardware and software, which may interact with the Contractor’s hardware. The Contractor shall update its delivered hardware to maintain compatibility with the latest other commercial hardware and software technology changes taking place at SSA as newer versions of technology are implemented. The COTR will determine the time frames available for completing upgrades. The COTR and the Contractor will mutually agree to establish a schedule for upgrades for the hardware and software. Performing updates are included in the warranty and maintenance requirements.

2.2.11. Storage Subsystem, and De-Duplication Hardware and Software Summaries The following tables summarize the requirements for all storage subsystems, and de-duplication appliances.

Table 1 Storage Subsystem Requirements Table

Usable Storage Before Data Reduction

Software

Hardware Upgrades

* Recovery Point Objective (RPO) ** Recovery Time Objective (RTO) *** Non-Volatile Memory express (NVMe) Table 2 De-duplication Appliance Requirements Table

Software

2.3. OS Storage Subsystems Hardware and Software Specific Requirements

2.3.1. General

2.3.1.1. Unless otherwise stated, the storage hardware and software must be compatible with SSA’s OS computer operating systems : Solaris, Linux, Red Hat Linux, VMware, Microsoft Hyper-V, and Microsoft Windows.

2.3.1.2. The storage hardware and software must have the ability to complete migrations from the Dell EMC storage subsystems using Dell EMC VPLEX storage virtualization appliances to the proposed storage subsystems with no outage of the servers and the applications the servers support.

2.3.1.3. The storage hardware must be compatible with clustered servers. The hardware and software must support two or more computer systems that SSA groups together with other resources to act like a single system and enable high availability, load balancing, and parallel processing.

2.3.1.4. The storage hardware and software must be compatible with VMware’s Site Recovery Manager Software.

2.3.1.5. All storage subsystems and SAN director upgrades must occur online.

2.3.1.6. The storage subsystem must be compatible with the following system administrator tools: Veritas Volume Manager, Oracle Volume Manager, VMware’s vCenter and Microsoft Disk Administrator.

2.3.1.7. The Contractor shall provide all hardware with the software components needed to manage the subsystem.

2.3.1.8. To expedite server I/O configuration setup and problem resolution, the Contractor shall provide a utility that compares a server I/O configuration setup with the Contractor recommended configuration.

2.3.1.9. The Contractor shall deliver all storage subsystems and all storage subsystem upgrades with any additional hardware needed to handle drive failures. Any extra hardware is in addition to the required usable storage.

2.3.2. OS SAN Storage Subsystems - SSA will provide – Dell-EMC Unisphere Reports, See Attachment 7, to help the Contractor build the subsystems that will meet the performance needs of each subsystem. All Storage Subsystems must contain a minimum of two active-active controllers. The Contractor shall configure the subsystems with the required storage subsystem individual software licenses outlined below or the Contractor shall bundle all the required software licenses into one software package. The Contractor shall provide a configured storage subsystem that meets the following performance and capacity criteria:

2.3.2.1. The Contractor shall configure each storage subsystem as follows:

2.3.2.1.1. Storage Subsystem Type OS-1: All NVMe storage.

2.3.2.1.2. Storage Subsystem Type OS-2: All NVMe storage

2.3.2.1.3. Storage Subsystem Type OS-3: All flash storage.

2.3.2.1.4. Storage Subsystem Type OS-4: All flash storage.

2.3.2.1.5. Storage Subsystem Type OS-5: All flash storage or Block level automated tiering.

2.3.2.1.6. Storage Subsystem Type OS-6: All flash storage or Block level automated tiering.

2.3.2.1.7. Storage Subsystem Type OS-7: All flash storage or Block level automated tiering.

2.3.2.1.8. Storage Subsystem Type OS-8: All flash storage or Block level automated tiering.

2.3.2.2. The storage subsystems must be configured with the following minimum quantities of usable storage before data reduction:

2.3.2.2.1. Storage Subsystem Type OS-1: 500 TBs of usable storage.

2.3.2.2.2. Storage Subsystem Type OS-2: 600 TBs of usable storage.

2.3.2.2.3. Storage Subsystem Type OS-3: 500 TBs of usable storage.

2.3.2.2.4. Storage Subsystem Type OS-4: 50 TBs of usable storage.

2.3.2.2.5. Storage Subsystem Type OS-5: 500 TBs of usable storage.

2.3.2.2.6. Storage Subsystem Type OS-6: 300 TBs of usable storage.

2.3.2.2.7. Storage Subsystem Type OS-7: 400 TBs of usable storage.

2.3.2.2.8. Storage Subsystem Type OS-8: 100 TBs of usable storage.

2.3.2.3. The storage subsystems must be expandable to at least, the following quantities of usable storage before data reduction:

2.3.2.3.1. Storage Subsystem Type OS-1: 2 PBs of usable storage.

2.3.2.3.2. Storage Subsystem Type OS-2: 600 TBs of usable storage.

2.3.2.3.3. Storage Subsystem Type OS-3: 2 PBs of usable storage.

2.3.2.3.4. Storage Subsystem Type OS-4: 200 TBs of usable storage.

2.3.2.3.5. Storage Subsystem Type OS-5: 2 PBs of usable storage.

2.3.2.3.6. Storage Subsystem Type OS-6: 2 PBs of usable storage.

2.3.2.3.7. Storage Subsystem Type OS-7: 1 PBs of usable storage.

2.3.2.3.8. Storage Subsystem Type OS-8: 200 TBs of usable storage.

2.3.2.4. The Contractor shall provide upgrades that include all the hardware and software licenses needed to configure the storage subsystems with the following minimum increment quantities of usable storage before data reduction:

2.3.2.4.1. Storage Subsystem Type OS-1: 100 TB of usable storage.

2.3.2.4.2. Storage Subsystem Type OS-2: No Upgrades.

2.3.2.4.3. Storage Subsystem Type OS-3: 100 TB of usable storage.

2.3.2.4.4. Storage Subsystem Type OS-4: 50 TB of usable storage.

2.3.2.4.5. Storage Subsystem Type OS-5: 250 TB of usable storage.

2.3.2.4.6. Storage Subsystem Type OS-6: 100 TB of usable storage.

2.3.2.4.7. Storage Subsystem Type OS-7: 100 TB of usable storage.

2.3.2.4.8. Storage Subsystem Type OS-8: 50 TB of usable storage.

2.3.2.5. The Contractor shall configure the Storage Subsystem Type OS-1, Storage Subsystem Type OS-2, Storage Subsystem Type OS-3 and Storage Subsystem Type OS-4 and upgrades to the storage subsystem to maintain the following minimum Effective Storage Capacity Ratios.

2.3.2.5.1. Storage Subsystem Type OS-1: Effective Storage of three TBs for every one TB of usable storage. The Contractor shall provide a three to one Effective Storage Utilization ratio that is based solely on deduplication and compression of the data stored on the subsystem. In the event a Storage Subsystem Type OS-1, subsystem cannot maintain a three to one Effective Storage utilization ratio based solely on deduplication and compression the Contractor shall provide additional storage to account for the short fall in the Effective Storage Utilization.

2.3.2.5.2. Storage Subsystem Type OS-2: Effective Storage of three TBs for every one TB of usable storage. The Contractor shall provide a three to one Effective Storage Utilization ratio that is based solely on deduplication and compression of the data stored on the subsystem. In the event a Storage Subsystem Type OS-2, subsystem cannot maintain a three to one Effective Storage utilization ratio based solely on deduplication and compression the Contractor shall provide additional storage to account for the short fall in the Effective Storage Utilization.

2.3.2.5.3. Storage Subsystem Type OS-3: Effective Storage of two TBs for every one TB of usable storage. The Contractor shall provide a two to one Effective Storage Utilization ratio that is based solely on compression of the data stored on the subsystem. In the event a Storage Subsystem Type OS-3, subsystem cannot maintain a two to one Effective Storage utilization ratio based solely on compression the Contractor shall provide additional storage to account for the short fall in the Effective Storage Utilization.

2.3.2.5.4. Storage Subsystem Type OS-4: Effective Storage of two TBs for every one TB of usable storage. The Contractor shall provide a two to one Effective Storage Utilization ratio that is based solely on compression of the data stored on the subsystem. In the event a Storage Subsystem Type OS-4, subsystem cannot maintain a two to one Effective Storage utilization ratio based solely on deduplication and compression the Contractor shall provide additional storage to account for the short fall in the Effective Storage Utilization.

2.3.2.6. The storage subsystems must deliver maximum average service times for the following access densities:

2.3.2.6.1. Storage Subsystem Type OS-1: 0.3 millisecond average service time for an access density of 3.00 Input Outputs per Second (IOPS)/Gigabyte (GB)/sec.

2.3.2.6.2. Storage Subsystem Type OS-2: 0.3 millisecond average service time for an access density of 3.00 IOPS/GB/sec.

2.3.2.6.3. Storage Subsystem Type OS-3: 0.4 millisecond average service time for an access density of 2 IOPS/GB/sec.

2.3.2.6.4. Storage Subsystem Type OS-4: 0.4 millisecond average service time for an access density of two IOPS/GB/sec.

2.3.2.6.5. Storage Subsystem Type OS-5: 1 millisecond average service time for an access density of 0.32 IOPS/GB/sec.

2.3.2.6.6. Storage Subsystem Type OS-6: 1 millisecond average service time for an access density of 0.32 IOPS/GB/sec.

2.3.2.6.7. Storage Subsystem Type OS-7: 5-millisecond average service time for an access density of 0.2 IOPS/GB/sec.

2.3.2.6.8. Storage Subsystem Type OS-8: 5-millisecond average service time for an access density of 0.2 IOPS/GB/sec.

2.3.2.7. The storage subsystems must be delivered with the following minimum quantities of front-end fiber channel ports with a minimum speed of 16 Gbps:

2.3.2.7.1. Storage Subsystem Type OS-1: 64 ports.

2.3.2.7.2. Storage Subsystem Type OS-2: 20 ports.

2.3.2.7.3. Storage Subsystem Type OS-3: 64 ports.

2.3.2.7.4. Storage Subsystem Type OS-4: 8 ports.

2.3.2.7.5. Storage Subsystem Type OS-5: 64 ports.

2.3.2.7.6. Storage Subsystem Type OS-6: 64 ports.

2.3.2.7.7. Storage Subsystem Type OS-7: 10 ports.

2.3.2.7.8. Storage Subsystem Type OS-8: 8 ports.

2.3.2.8. The Contractor shall provide upgrades to front-end fiber channel ports in the following minimum increments:

2.3.2.8.1. Storage Subsystem Type OS-1: No upgrades.

2.3.2.8.2. Storage Subsystem Type OS-2: No upgrades.

2.3.2.8.3. Storage Subsystem Type OS-3: No upgrades.

2.3.2.8.4. Storage Subsystem Type OS-4: 4 ports.

2.3.2.8.5. Storage Subsystem Type OS-5: No upgrades.

2.3.2.8.6. Storage Subsystem Type OS-6: No upgrades.

2.3.2.8.7. Storage Subsystem Type OS-7: No upgrades.

2.3.2.8.8. Storage Subsystem Type OS-8: No upgrades.

2.3.2.9. All Storage Subsystems must contain a minimum of 4 front end 10 Gbps Ethernet ports for remote replication between sites:

2.3.2.10. The Contractor shall include a subsystem license for control software included with all subsystems. SSA will refer to this software as OS Subsystem Control Software. The Contractor shall provide both a command line interface and browser-based graphical interface that provide the following features:

2.3.2.10.1. Device management and device security including establishing and reporting on Effective Storage ratios.

2.3.2.10.2. Device and subsystem performance monitoring

2.3.2.10.3. Subsystem configuration management

2.3.2.10.4. Volume local and remote replication management

2.3.2.10.5. For Storage Subsystem Type OS-5, Storage Subsystem Type OS-6, Storage Subsystem Type OS-7 and Storage Subsystem Type OS-8 the Contractor shall include Block level automated tiering software. For Storage Subsystem Type OS-5, Storage Subsystem Type OS-6, Storage Subsystem Type OS-7 and Storage Subsystem Type OS-8 that does not include Block level automated tiering, all flash storage shall be included.

2.3.2.11. The Contractor shall include subsystem license for Data at Rest Encryption hardware or software with all of the storage subsystems. The encryption hardware or software must meet the following requirements:

2.3.2.11.1.1. The encryption hardware or software must conform to Federal Information Processing Standards (FIPS) 140-2 compliant as updated on March 27, 2018.

2.3.2.11.1.2. The encryption hardware or software must use Advanced Encryption Standard (AES) with a minimum of 128-bit cipher, in accordance with National Institute of Standards and Technology (NIST) standards.

2.3.2.11.1.3. The encryption algorithms in use must conform to NIST’s Cryptographic Module Validation Program as required by Federal Information Processing Standards. For more information, see ‘https://csrc.nist.gov/projects/cryptographic-module-validation-program’

2.3.2.12. The Contractor shall include a subsystem license for software included with all subsystems that provides local replication at the volume level. SSA will refer to this software as OS Volume Level Replication Software. This local replication software must include capabilities to copy-on-write (or low-capacity) snapshot and to create a cloned volume copy. This software must support the following operating systems currently in use at SSA: Linux, Red Hat Linux, Microsoft Hyper-V, Microsoft Windows, Oracle Solaris, and VMware. The software must have the ability to mount the backup volumes on the following operating systems in use at SSA: Linux, Microsoft Hyper-V, Microsoft Windows, Oracle Solaris, and VMware. The software must include the ability to flush cache on a Microsoft Windows server. The software must provide a feature to consistently split a set of secondary volumes from the primary volumes at the same point in time. If an application’s primary data is split between two different subsystems of the same model, the software must keep the backup copies of the data consistent. For Storage Subsystems Type OS-1 and Storage Subsystems Type OS-2, the Contractor shall extend the volume level local replication software to allow SSA to store the backup volumes on a second storage subsystem. This feature must allow SSA to store the backup volumes on any OS Subsystem currently owned by SSA or any of the subsystems the Contractor proposes for Storage Subsystem Types OS-1, OS-2, OS-3, OS-4 and OS-5.

2.3.2.13. The Contractor shall include a subsystem license with all subsystems for software that allows thin provisioned volumes. SSA will refer to this software as OS Thin Provisioning Software.

2.3.2.14. The Contractor shall include a subsystem license for compression software that compresses the data stored on the storage subsystem. This compression software must be included with Storage Subsystem Type OS-1, Storage Subsystem Type OS-2, Storage Subsystem Type OS-3 and Storage Subsystem Type OS-4.

2.3.2.15. The Contractor shall include a subsystem license for data deduplication software that eliminates duplicate copies of repeating data that is stored on the Storage Subsystem. The data deduplication software must be included with Storage Subsystem Type OS-1, Storage Subsystem Type OS-2, and Storage Subsystem Type OS-4.

2.3.2.16. The Contractor shall include a subsystem license for software included with subsystems Storage Subsystem Type OS-5, Storage Subsystem Type OS-6 Storage Subsystem Type OS-7 and Storage Subsystem Type OS-8 that allows block level automated tiering. SSA will refer to this software as OS Block Level Automated Tiering Software. This software must include the ability to place data on the proper storage device at the sub-LUN or block level within the system and with local replication and remote replication. The software must have the ability to move data as small as 100 MBs. Based on performance and availability requirements, the software must select the proper device for data placement. For hardware that includes all flash storage, this Section 2.3.2.16 does not apply.

2.3.2.17. The Contractor shall include a subsystem license with all subsystems for software that supplies server-based path-fail over, load balancing and I/O path management, path for Linux, Microsoft Windows, Oracle Solaris and VMware operating systems. SSA will refer to this software as OS Path Failover Software.

2.3.2.18. The Contractor shall include a subsystem license for software with all subsystems that provides remote replication at the volume level between subsystems. SSA will refer to this software as OS Remote Volume Level Replication Software. This software must meet or exceed the following salient requirements:

2.3.2.18.1. The software must support a Recovery Point Objective (RPO) of 15 minutes or less and Recovery Time Objective (RTO) of 24 hours or less.

2.3.2.18.2. If an application’s primary data is split between two or more different subsystems of the same model, the software must have the ability to keep the remote copies of the data consistent.

2.3.2.18.3. The software must provide a feature to use disk-based journals at both the primary and remote sites. In the event of a network outage, changed data at the primary site must be queued at the primary site until after the network is operational. The changed data must then be transmitted to the remote site.

2.3.2.18.4. The software must be able to keep a set of secondary volumes at the remote site at the same consistent point in time without the need to create a set of backup volumes at the remote site.

2.3.2.18.5. The software must provide the ability to keep data consistent in both asynchronous mode and synchronous mode.

2.3.2.18.6. The software must provide the ability to keep data asynchronously consistent between two data centers. The software must provide the ability to keep data asynchronously consistent between two data centers the NSC in Fredrick MD and the SSC in Durham NC the average network latency is 10 milliseconds. The software must also provide the ability to keep data asynchronously consistent between two additional data centers in Kansas City MO and Richmond CA the average network latency is 55 milliseconds. The storage hardware and software must be compatible with VMware’s Site Recovery Manager Software and all proposed Storage Virtualization Appliances.

2.3.2.19. The Contractor shall configure the storage subsystems using the Contractor’s proposed Redundant Array of Independent Disks (RAID) schema, based on the Contractor’s Best Practices and the Loss of Data Warranty that is defined in Section 2.8.4.

2.3.3. OS NAS Storage Subsystem - SSA will refer to the following modular NAS subsystem as Storage Subsystem Type OS-9. SSA intends to use this subsystem for workloads including file archiving, business analytics, and digital media. The Contractor shall deliver the Storage Subsystem and Storage Subsystem upgrades with the needed hardware to handle drive failures. The extra hardware is in addition to the required usable storage. All the hardware and software for this subsystem shall meet all the salient requirements outlined below:

2.3.3.1. The proposed NAS storage hardware and software must have the ability to complete migrations from Dell EMC NAS Isilon subsystems and Dell EMC Unity subsystems to the proposed storage subsystems with a maximum outage of five minutes for the servers and the applications using the Dell EMC NAS storage.

2.3.3.2. SSA will customize the type and number of modules each time this appliance is ordered.

2.3.3.3. The Contractor shall provide a subsystem delivered with all the needed hardware to support a minimum speed of 10 Gbps.

2.3.3.4. Each module must be configured with a minimum of two Ethernet ports with a minimum speed of 10 Gbps.

2.3.3.5. The Contractor shall configure the modules of the storage subsystem using its proposed data protection schema.

2.3.3.6. Storage Subsystem Type OS-9 must be delivered with Subsystem Control Software, Local and Remote Replication Software, OS Thin Provisioning Software, Storage Resource Management (SRM) software, Data at Rest Encryption hardware or software and Block Level or File Level Automated Tiering Software.

2.3.3.7. The Contractor shall provide one storage module designed to upgrade Storage Subsystem OS-9 to meet the following requirements. SSA will refer to this module as Storage Module OS-9-1.

2.3.3.7.1. The module must be delivered with 170 TB of usable storage all flash storage.

2.3.3.7.2. The module must provide a minimum 3.5 Gb/sec throughput for CIFS/SMB or Network File System (NFS).

2.3.3.7.3. The module must deliver a 0.5-millisecond average service time and a minimum of 60,000 IOPS.

2.3.3.8. The Contractor shall provide one-storage module designed to upgrade Storage Subsystem OS-9 to meet the following requirements. SSA will refer to this module as Storage Module OS-9-2.

2.3.3.8.1. The module must be delivered with 30 TB of usable storage all flash storage.

2.3.3.8.2. The module must provide a minimum 3.5 Gb/sec throughput for CIFS/SMB or NFS.

2.3.3.8.3. The module must deliver a 0.5-millisecond average service time for and a minimum of 60,000 IOPS.

2.3.3.9. The Contractor shall provide one-storage module designed to upgrade Storage Subsystem OS-9 to meet the following requirements. SSA will refer to this module as Storage Module OS-9-3.

2.3.3.9.1. The module must be delivered with 15 TB of usable storage all flash storage.

2.3.3.9.2. The module must provide a minimum 3.5 Gb/sec throughput for CIFS/SMB or NFS.

2.3.3.9.3. The module must deliver a 0.5-millisecond average service time and at least 60,000 IOPS per module.

2.3.3.10. The Contractor shall provide one-storage module designed to upgrade Storage Subsystem OS-9 with the following requirements. SSA will refer to this module as Storage Module OS-9-4.

2.3.3.10.1. The module must be delivered with 50 TB of usable storage.

2.3.3.10.2. The module must provide a minimum of 3 Gb/sec throughput for CIFS/SMB or NFS.

2.3.3.10.3. The module must deliver a 5-millisecond average service time and at least 30,000 IOPS per module.

2.3.3.11. The Contractor shall provide one-storage module designed to upgrade Storage Subsystem OS-9 with the following requirements. SSA will refer to this module as Storage Module OS-9-5. A

2.3.3.11.1. The module must be delivered with 275 TB of usable storage.

2.3.3.11.2. The module must provide a minimum of 1 Gb/sec throughput for CIFS/SMB or NFS.

2.3.3.11.3. The module must deliver a 15-millisecond average service and at least 4,000 IOPS per module.

2.3.3.12. The Contractor shall provide one-storage module designed to upgrade Storage Subsystem OS-9 with the following requirements. SSA will refer to this module as Storage Module OS-9-6.

2.3.3.12.1. The module must be delivered with 175 TB of usable storage.

2.3.3.12.2. The module must provide a minimum of 1 Gb/sec throughput for CIFS or NFS.

2.3.3.12.3. The module must deliver a 15-millisecond average service and at least 4,000 IOPS per module.

2.3.4. Object Storage - The Contractor shall provide a configured storage subsystem that meets the following performance and capacity criteria: SSA will refer to these subsystems as Storage Subsystem OS-10 and Storage Subsystem OS-11.

2.3.4.1. Storage Subsystem Type OS-10 and Storage Subsystem OS-11 must be delivered with Subsystem Control Software, Remote Replication, and OS Data at Rest Encryption hardware or software.

2.3.4.2. The proposed object storage subsystems must support NFS, Swift, and S3 access protocols.

2.3.4.3. When replicating data between object storage subsystems, the subsystems must be configured to store a complete copy of the data on each subsystem.

2.3.4.4. The object storage subsystems must provide a minimum of 40 Gb/sec throughput.

2.3.4.5. The object storage subsystems must be configured with storage that must deliver a maximum of 15-millisecond average service and support a maximum of 20,000 IOPS per subsystem.

2.3.4.6. The Contractor shall configure an Object Storage Subsystem OS-10 with 300 TB of usable storage.

2.3.4.7. The Contractor shall configure an Object Storage Subsystem OS-11 with one PB of usable storage.

2.3.4.8. The Contractor shall configure an upgrade to Object Storage Subsystem OS-10 or Object Storage Subsystem OS-10-11 with 300 TB of usable storage.

2.3.5. OS SAN and NAS Subsystem Software Additional Software (“Upgrades”)

2.3.5.1. The Contractor shall provide one subsystem license for SRM/ Storage Performance Management (SPM) reporting software. SSA will refer to this software as OS-SRM Software. The software must meet or exceed the following salient requirements:

2.3.5.1.1. The software must house all data in a relational database.

2.3.5.1.2. The software must collect and store current and historic demographic information about servers, storage subsystems, switches, and directors.

2.3.5.1.3. The software must provide the capability to generate reports, a dashboard displays, and alerts using the database.

2.3.5.1.4. The software must provide a feature to send alerts upon the failure of host adapters, SAN components, or storage components.

2.3.5.1.5. The software must provide set predefined queries that can be used to provide reports in HTML, PDF, or CSV formats.

2.3.5.1.6. The software must provide a capability to generate custom reports.

2.3.5…