SPECIFICATIONS |
| 1. |
Total initial storage capacity of 5TB which is made up of the following tiers of storage: |
| |
a. |
Tier 1 storage: 1TB stored on ~146GB 10K RPM FC disk drives (ten drives in two RAID 5 arrays) |
| |
b. |
Tier 2 storage: 2TB stored on ~300GB 10K RPM FC disk drives (ten drives in two RAID 5 arrays) |
| |
c. |
Tier 3 storage: 2TB stored on ~500GB nearline disk drives operating at least at 7,200 RPM (five drives in a RAID 5 array). |
| 2. |
This SAN must have at least 12 Fibre Channel host ports which operate at a data rate of at least 2Gbps (4Gbps preferred). |
| 3. |
This SAN must have at least two storage controllers which provide redundant data paths to the disk drives with “active/active” data paths. |
| 4. |
Must provide a fully redundant architecture for both the storage controllers and the power supplies that serve all other parts of the SAN system. |
| 5. |
Must provide support for RAID levels 0, 10, and 50. |
| 6. |
Must provide support for RAID 5 data to parity ratios ranging from 2:1 up to 8:1. |
| 7. |
Must provide capability to change LUN characteristics (RAID, drive type, drive placement, etc.) with no application disruption. |
| 8. |
Must provide capability to support both Fibre Channel and nearline disk drives. |
| 9. |
Must provide capability to distribute LUNs across all disk drives of a given type (e.g. FC or nearline). |
| 10. |
Must provide capability to expand LUNs while those LUNs are in use (“on-the-fly”). |
| 11. |
Must provide the capability to over-provision installed physical storage (thin provisioning - also known as oversubscription). The storage controllers must be able to allocate storage to the applications as required by application writes; not up-front when the LUN was created. This space must be allocated automatically, with no administrator involvement. In order to manage this capability, appropriate administrator-defined limits and warnings must be available, but not required for use. Warnings based on physical capacity remaining must also be provided. Thin provisioning is "just in time capacity" that essentially eliminates allocated but unused or stranded storage. It also greatly simplifies storage provisioning tasks thereby reducing system administration workload. |
| 12. |
Must provide capability to create Point-In-Time (PIT) physical and virtual copies of LUNs, usually called snapshots. The system must provide a simple, efficient and scalable copy-on-write snapshot capability that enables WVDL SAN administrators to quickly and efficiently create snapshots of managed data. These snapshots must be available on demand, instantly, in read-only or read-write access modes. Virtual snapshots must require no reserved space on the SAN, rather they must only consume SAN storage space when data is changed/written. The SAN system must support the creation of at least 90 snapshots per LUN, and be able to create snapshots of snapshots. |
| 13. |
Must provide support for snapshot consistency groups where a consistency group is a number of volumes (2 to 100 or more LUNs) that will be snapped at the same point-in-time. With this capability a snapshot of multiple LUNs that support a given application would be a consistent across the entire LUN set. |
| 14. |
Must provide a data cache of at least 8GB. |
| 15. |
Must provide a control cache of at least 4GB. |
| 16. |
Must be a self-configuring system – System administrators must be able to provision storage LUNs in under one minute with no pre-planning. |
| 17. |
Must be capable of online storage upgrades. |
| 18. |
Must be capable of online port upgrades. |
| 19. |
Must be capable of online firmware upgrades. |
| 20. |
Must provide capability of “phone-home” telecommunications via phone lines to alert service personnel of error or other service degradation conditions. |
| 21. |
Must support remote application of firmware upgrades by remote service personnel through the phone-home system. |
| 22. |
Must support troubleshooting through configurable logging of operations and events. |
| 23. |
The system must be self-tuning to automatically balance system load and thereby greatly reduce or eliminate system administration tasks. |
| 24. |
The SAN system must support a mixed workload – simultaneous support for traditional “file sharing” (high throughput) and Oracle database (high transaction rate) workloads with excellent performance for both. |
| 25. |
Components must be mountable in a standard 19” rack mount cabinet. |
| 26. |
Simple to use management graphical user interface (GUI) providing all day-to-day system admin functions through this simple interface. Use of command line interface for infrequent or setup commands is acceptable. |
| 27. |
System installation, configuration and training of WVDL staff must be completed in a single eight hour work day. |
| 28. |
The system must provide support for at least three administration levels (e.g. super user, edit, view only). |
| 29. |
Must provide full support for both VMware ESX Server 3.0.1 and Microsoft Windows Server 2003 SP1 with no changes to these operating systems other than the installation of drivers to enable SAN communication and use. |
| 30. |
The SAN must be listed in VMware’s VI3 SAN Compatibility document titled “Storage / SAN Compatibility Guide For ESX Server 3.x” -- current edition as of bid date. This guarantees the SAN solution is compatible with our VMware server environment. |
| 31. |
Must provide support for “boot from SAN” capability to enable the booting of VMware ESX and Microsoft Windows server systems from SAN storage space (LUNs). |
| 32. |
The SAN system must be expandable without application interruption to 60TB of storage space using up to 128 disk drives in the array. I.e., this SAN must accommodate the addition and configuration of up to 128 disk drives without shutting down the SAN itself or any of the server computers connected to it. |
