The stealth announcement of the IBM XIV is perplexing. Given such a different architectural approach, you would think IBM would explain the system's merits. Is it a niche product that does not deserve marketing dollars, or is it a signpost to the future that will threaten revenues from other products? Let’s look inside the IBM XIV and evaluate.
The hardware components are shown in Figure 1.
XIV Components The system fills a standard 19 inch rack. The three UPS’s provide the power supply to support saving the cache data to disk if the external power fails. The double conversion for AC supplies provides power without spikes but adds to the power requirements. The disks are industry standard 1TB SATA disks (only one disk type). The total number of disks is 180. All the interface modules, caches and maintenance processors are from volume Intel chipsets. Each interface module includes 2 4GB FC ports and 2 1GB iSCSI/management ports, for a total of 12 FC ports and 12 iSCSI ports.
XIV Architecture The XIV architecture is full virtualization. Each volume is split into 1GB pages, and spread over all the 180 disk drives. Only data that has to be written is stored; space that is allocated but not yet used is not written.
The data is mirrored and each page written to a different disk and module. There is also longitudinal data recovery, which allows for recovery from up to three failed disks and one data module. Data is recovered by reading the volume from all 180 disks and rewriting to the remaining disks. Recovery from a disk failure is claimed to be about 30 minutes.
The cache is distributed across all 15 data modules (8GB each) for a total of 120GB. The cache uses a 4K cache segment size, optimized for high cache hit rates on random data. Cache integrity is maintained in the event of the loss of one data module.
XIV Software The full virtualization enables simple software implementation of thin provisioning and virtual copies (snapshots). Consistency groups are supported by snapshots.
Synchronous (but not asynchronous) remote mirroring is supported. There is support for data migration from external arrays, which allows an XIV volume to be connected to an external volume and copied over while the host is processing against that volume. This eliminates the copy time for migrating external volumes, but not the administrative time.
XIV Performance Performance of the system is designed to be consistent for all users. All the disks are used to read or write volumes. I/O would be expected to be very evenly distributed across all drives and modules, and hotspots would be generally limited. The small cache segment size optimizes performance for random workloads. Wikibon predicts good performance on tier 1b and tier 2 applications, but predicts that the XIV will be less suitable for tier 1a applications requiring high performance and data mining applications with large sequential processing characteristics.
XIV Management The key design characteristic of the IBM XIV is ease of use. The architecture minimizes the need for performance management. The virtualization hides the complexities of LUN security from administrators. The use of virtualization, thin provisioning and virtual copies should enable very high storage utilization rates, as high as 85%-90% utilization. The storage pools are logical pools, not physical pools. It is easy to move administrative function that would traditionally need trained storage administrators to end-user storage administrators. Wikibon expects that the ease of use will similar or better than 3PAR, currently the gold standard for storage ease-of-use.
XIV Limitations The XIV architecture leads to some limitations in function. As all the drives are used to read and write volumes:
- Mixing different drives with different capacities and performance characteristics within a single XIV rack does not make sense and is probably not possible. Historically, 3PAR with a similar (but not identical) full virtualization architecture had initial support for only 10K FC drives. Customer demand for additional drive types drove support for additional drive types over time. Wikibon would expect the same for XIV, with the difference that a single rack is likely to have only one drive type. Wikibon expects that if and when XIV racks can be clustered, different racks will support different drive types. The advent of support for different drives types will allow support for more application types.
- Tiered storage within a single XIV rack does not make sense. Wikibon expects that tiered storage may be implemented across clustered racks of XIV processors.
- NAND storage (tier-0) does not make sense at the disk drive level (although it may be used in the caches). It is possible that an XIV rack with fewer NAND-only drives may be introduced as part of a cluster, but Wikibon believes that to be unlikely in any probable user planning horizon.
- Implementing MAID technologies makes little sense as I/O is very evenly distributed across all the drives. Even if there is no I/O, there are background scrubbing tasks within the XIV that generate I/O. This means that the XIV would not be the best array for archive data applications that are not expected to be accessed.
- All 180 drives have to be used. The only way IBM provides smaller configurations within a rack is to allow users to use less capacity in each disk drive, as long as the user agrees to buy the full capacity in the near future.
- There is no mainframe support for ESCON or FICON. IBM could invest in mainframe support in the future, but this is unlikely because of the impact on IBM 8000 revenues
XIV Summary Storage executives should initially evaluate the IBM XIV as a niche product. It is a niche product at the moment; it is low cost, will achieve very high storage utilization, and be very effective for the large amount of tier 1b and tier 2 applications. Wikibon expects utilization, ease of use, and speed of change to be world-class, and availability and recovery to be very good.
The XIV announcement legitimizes full virtualization architectures in general, including those from vendors such as 3PAR and Compellent. If IBM can deliver on the future clustered vision as Moshe as discussed, XIV will become a signpost to be future and will cover a wide spectrum of data center requirements. It will be a strong alternative to the IBM 8000 and 4000 lines and will affect revenues from those products.
Action Item: IBM's XIV is both a niche product and a signpost to the future. IBM has legitimized full virtualization architectures on commodity hardware. Wikibon believes that this will fundamentally change the storage array marketplace as the technology matures. Both infrastructure and application development groups should follow this trend closely. Senior executives should make themselves familiar with full virtualization architectures from IBM and other vendors and ensure that high utilization, flexibility and administrative costs are fully reflected in the technology comparisons and business cases. Design reviews of future systems should assume that storage will be architected in a similar way to XIV; requests for higher performance storage systems should be met with skepticism and reviewed extensively.
Footnotes:
