The USP V and its XP24000 and 9990V siblings combine thin provisioning, space-efficient point-in-time copies and virtualization in a highly scalable storage system that is operationally and financially appealing in the high-end storage market. Thin provisioning has the potential to provide one-time improvements in utilization rates, lower storage acquisition costs, and alter the design and management of storage infrastructures. Users should note that there are no plans to retrofit thin provisioning into USP, XP12000 or 9990.

• Thin provisioning will become a "must have" feature by 2012.
• In response to these Next-Gen announcements by Hitachi Data Systems (HDS), HP and Sun, EMC has announced its intention to deliver thin-provisioning capabilities for its Symmetrix family during the first half of 2008.

• Users should embrace thin-provisioning technology whenever possible.
• Users should negotiate upgrade prices and upgrade lead times as part of the initial acquisition contract.
• The USP V, XP24000 and 9990V are new storage systems that have not yet been market validated. Users should, therefore: plan on 30- to 60-day acceptance test periods; validate the performance, scalability and usability of thin provisioning during the acceptance test period; include training and, depending on internal skills, some level of on-site vendor support during the acceptance test period and transition into production as part of the purchase contract; and identify feature implementation limitations that can affect deployment plans.
• Thin provisioning and virtualization of non-native storage at First Customer Ship (FCS) coexist, but are not certified to work with each other; and remote copy is restricted to virtual volumes that do not use thin provisioning. Although HDS, HP and Sun have indicated that these certifications will be forthcoming by the end of 2007, users should demand contractual guarantees where appropriate.

The unique combination of value-add features offered by the USP V, XP24000 and 9990V make them attractive upgrades for existing HDS/HP/Sun high-end customers, and possibly EMC and IBM users as well. EMC and IBM users will need to balance the appeal of these systems against the costs and risks associated with converting to an architecturally different system, and the probability that EMC and IBM may respond with equivalent functionality in a timely manner. Other considerations include probable differences in costs and utilization rates that will vary by workload.

Also note that prior to the introduction of these new Next-Gen systems, the USP, XP12000 and 9990 competed effectively against DMX and DS8000 series systems. Therefore, where the performance and scale of USP, XP12000 and 9990 comfortably exceed the needs over the systems' planned service lives and where the economics of these systems are compelling, users should not hesitate to install them.

The USP V, XP24000 and 9990V share many design elements with their predecessors, but in implementation, include many hardware and architectural improvements. Visible hardware highlights are shown in Table 1.

The USP V, XP24000 and 9990V do not yet support Serial Attached SCSI (SAS) and Serial Advanced Technology Attachment (SATA) disks, but SATA disk support is promised for the middle of the fourth quarter 2007. The lack of native SAS support is only of potential importance from a cost perspective because similar capacity FC and SAS drives are practically indistinguishable from each other when comparing performance, throughput and mean time between failure (MTBF). Rather, it is the promise of lower SAS disk costs, the relative ease of designing disk enclosures that support the intermixing of SAS and SATA disk within the same enclosure, and the economies of scale that sharing a disk enclosure between SAS and SATA disks creates, that are driving the adoption of SAS disks. Likewise, the lack of native SATA disk is a nonissue because midrange systems configured with SATA disks can be cost-effectively virtualized behind a USP V, XP24000 or 9990V. Nonetheless, the addition of native SATA drive support later in 2007 will further enhance the appeal of these systems in tiered storage environments.

Thin provisioning has the potential to provide a one-time improvement in utilization rates that can delay capacity upgrades, reduce the environmental impact of storage by using all the storage that is allocated to a server, lower storage acquisition costs, alter the design and management of storage infrastructures, and improve staff productivity. Without thin provisioning, utilization rates are always below allocation rates; in other words, each server has storage allocated to it that is not utilized. With thin provisioning, utilization and allocation rates are essentially equal — there is no stranded capacity. Therefore, the difference between utilization rates and allocation rates will fund capacity growth until the system is fully utilized. Once the system is fully utilized, additional capacity demands always convert into capacity upgrades. The financial, operational and environmental benefits of thin provisioning will make it a "must have" feature by 2012.

The design of Hitachi's thin-provisioning implementation is different from other vendors' implementations. Instead of creating pools of like geometry and performance disks, Hitachi Dynamic Provisioning (HDP) Pools or XP Thin Provisioning (XP THP) are aggregates of LDEVs from Array Groups (also known as HDP Pool Volumes or RAID sets). This provides a natural separation between capacity allocation and error recovery, and helps explain the results of preliminary performance measurements that show negligible differences between Logical Volume Manager and HDP volume performance: virtual volumes vs. thin-provisioned volumes.

HDP enables additional LDEVs from a variety of array groups to be added to an HDP Pool as additional capacity is needed. In a future release as a background task, HDP will rebalance pages across these additional array groups to eliminate hot spots. In other words, as array groups are added to an HDP pool, they are interleaved into the pool and not concatenated. One consequence of building HDP pools from LDEVs in array groups is that depending on workloads, users may need to create and manage multiple HDP pools; that is, one pool for RAID 1 built with 146GB disks, another for RAID 5 (7D+1P) built with 300GB disks and yet another for RAID 5 (3-D+1P) and so on. At first, customer shipments of up to 32 pools are supported to address this need for distinct pools with specific performance characteristics.

Although HDP is a dramatic step forward in high-end storage-array provisioning, it is not yet fully autonomic. The creation of array groups and LDEVS, and their assignment to HDP pools, is still a manual process. In a fully autonomic implementation, the storage system would automatically build Array Groups or HDP Pool Volumes with the appropriate level of RAID protection from global pools of like-geometry, like-performance disks that could be replenished in a nondisruptive manner and assign them HDP pools on a just-in-time basis.

Hitachi provisions HDP volumes — virtual volumes visible to servers — in 42 MB "HDP Volume Pages" increments. Compared with the 2MB pages that Compellent uses with its thin-provisioning feature or the 16KB page used by 3PAR, this is very coarse. But, as with all design decisions, there are always tradeoffs. With an announced capacity of 247 PBs, a 42 MB page is less than 1 millionth of the system’s maximum capacity. Viewed from a virtual-volume-centric perspective, there are almost 24 pages per GB of storage, which is granular by any measure. Larger pages also mean that less metadata is needed to describe a virtual volume, which suggests that thin provisioning should scale well. Balanced against these advantages, the use of larger pages can create operational risk when an application formats the space that it is allocated because thin provisioning will allocate space to every block that is formatted or initialized. If these initialized blocks are distributed across the entire volume, then they can consume lots of 42 MB pages. Hence, it is important to understand the interactions of your operating system and middleware when sizing your system.

The virtualization capabilities of these systems simplify data migrations from installed storage systems to new systems and facilitate consolidation on an application-by-application basis. Like its predecessors, the USP V, XP24000 and 9990V support the logical partitioning of system resources into private virtual storage machines: ports, cache and disk. These virtual machines minimize cache pollution between servers and improve security when system resources are shared between users. Although not yet autonomic, system resources can be dynamically adjusted to meet quality-of-storage service objectives.

With the introduction of the USP V, XP24000, and 9990V, TrueCopy and HUR are, for the first time, usable by any partition or private virtual machine supporting open systems. For z/OS, all volumes have to be in partition 0; however, mainframe volumes can be in any cache logical partition. Depending on performance and operational requirements, remote links can be shared between partitions.

Preliminary HDS and HP performance measurements show that performance gains of the USP V, XP24000 and 9990V vs. their corresponding previous generation models are workload-dependent. When supporting typical online environments, these vendors claim that users can expect a 50% improvement over comparably configured predecessor systems. Specific performance factoids released by the vendors are shown in Table 2.

Performance and throughput are usually more important as scalability enablers than differentiators. More performance and throughput also usually translates into more-consistent performance unless the bottleneck is on the back-end disks. Therefore, the scalability and virtualization capabilities of USP V, XP24000 and 9990V make them attractive as consolidation platforms.