3PAR Comments on IBM XIV Platform

IBM claims that the XIV platform is primarily targeted at 3PAR Utility Storage and is aimed at cloud computing, SaaS, HaaS and Web2 opportunities. However the XIV array is not well positioned architecturally as a Utility Storage platform for utility computing since it does not provide the core requirements to allow the creation of ‘shared storage infrastructures for flexible workload consolidation’ – infrastructures that have to handle diverse and unpredictable workloads while providing the lowest total cost of ownership though high levels of written capacity utilization:
 
No intra-controller mixed workload support (high IOPS and Bandwidth at the same time on the same controller). Means XIV is unsuitable for unpredictable application workloads implemented on a shared platform

3PAR Gen3 ASIC and controller design that splits processing of control commands from movement of data provides this functionality
XIV has no ASIC and no such controller design – it can only use hardware segregation which causes high management overhead, poor array utilization and suffers performance limitations.

No virtual domain (private virtual array) support on a single array. Means XIV is unsuitable for shared infrastructures since it cannot provide administrative security and isolation for multiple different customers or business units sharing a single array.

3PAR Virtual Domains provides the ability to create thousands of secure private arrays on a single 3PAR InServ, a key requirement to overcome the leading inhibitor to internal service bureaus and service providers being able to take full advantage of a shared infrastructure (Virtual Domains are the equivalent of server virtualization technology applied to a storage array). XIV has no virtual domain capability and therefore cannot offer the security and resilience desired by customers of internal service bureaus and external service providers.
 
No low latency cache coherence between nodes in the XIV cluster (uses Ethernet vs 3PAR ASIC). Means XIV gets poor performance scaling for any given application beyond two nodes in a cluster – a major issue for Web2.0 applications and enterprise-class utility service providers.

3PAR Gen3 ASIC and clustered mesh backplane design provides low latency communications and tight cache coherence between controller nodes that allows linear performance scaling over up to eight nodes. XIV has no ASIC and uses relatively high latency 10Gb/s Ethernet for its internal array clustering communication, limiting linear application performance scaling to a couple of nodes.

Single QoS tier (SATA/RAID1) only. Means no ability to support diverse QoS levels (e.g. no bronze, silver, gold, platinum) necessary for ‘shared’ infrastructures and consolidation environments – capabilities needed by service providers and internal service bureaus.

3PAR InSpire architecture supports multiple RAID levels, disk types (FC, SATA etc.), data placement alternatives, and controller node coverage, as well as the ability to dynamically move data between QoS tiers without disruption to the running application.
XIV has no support for FC drives or other types of RAID level support like RAID 5/50, and so cannot offer multiple QoS levels.

Expensive RAID 1-like approach only. Means XIV offers very low usable capacity and maximum written utilization rates resulting in a high total cost of ownership (higher capital expenditures as well as higher power, cooling and floor space costs).

3PAR Fast RAID 5 enabled by an XOR parity engine in the 3PAR Gen3 ASIC offers the ability to minimise wasted storage capacity associated with RAID 1 overhead for most applications and thereby deliver much lower TCO including reduced capital expenditures and power, cooling and floor space costs. XIV’s has no RAID 5 support today (and no apparent ASIC support for a potential Fast RAID 5 implementation in the future).  Due to this limitation it only offers a maximum of 80 usable TBs out of every 180TB a customer purchases.  Written utilization will therefore be typically much less than even the 80 usable TBs (see next).

Chubby provisioning implementation of thin provisioning (1MB allocation units). Means XIV offers relatively low written utilization levels resulting in a high total cost of ownership (higher capital expenditures as well as higher power, cooling and floor space costs).

3PAR Thin Provisioning implementation is very efficient with a small 16KB allocation unit and has helped deliver proven and dramatic improvements in written capacity utilization of up to 80% or more and a lower resulting TCO (more than half of 100 3PAR independently surveyed by Wikibon were reported as saving more than 60% of capacity purchases compared with traditional alternatives) XIV’s implementation is a thin provisioning impostor that appears to use a massive 1MB allocation unit size resulting in chubby provisioning. This combined with its RAID-1 only implementation approach could lead to customers experiencing as little as a 25% or less written capacity utilisation rate (and much higher TCO).

No long distance DR (no asynchronous replication support). Means XIV does not meet a key Tier 1 requirement since it cannot offer resilient long distance disaster recover solutions for service providers and Web2.0 companies.

3PAR Remote Copy offers both synchronous and periodic asynchronous remote replication support over IP for metropolitan and wide area disaster recovery. XIV has no support for asynchronous remote replication.

Massive 180TB minimum purchase quantities (full rack). Means a customer choosing an XIV platform can’t start small and cost effectively and then scale just in time. This leads to very high upfront costs that are not aligned with the business needs of shared infrastructure service providers and Web 2.0 organizations. Even their Capacity on Demand (CoD) option requires an up front purchase of 80TB raw minimum (and this appears to be just a barely hidden leasing program).

3PAR InServ allows a customer to start with as few as 16 discs (2.4TB) and then scale massively and just in time – keeping up front costs small and incremental costs aligned with actual business needs. XIV requires massive minimum purchase quantities of 180TB as a standard – maybe associated with performance limitations of its SATA-only architecture.

No integration with utility computing infrastructure solutions like VMware SRM or VDI. Means XIV does not provide the kind of integration with server-based virtualization technologies that service providers, Web2.0 and internal service bureau organizations leveraging utility computing solutions require.

3PAR Thin Copy Desktop for VMware VDI and 3PAR Replication Adaptor for VMware SRM are just two examples of tight integration with server virtualisation and utility computing infrastructures. XIV offers no equivalent integration into VMware solutions and the utility computing ecosystem.

No non-disruptive updates between major software releases. Means XIV does not meet a key Tier 1 requirement for service providers, Web2.0 companies and internal service bureaus.

3PAR InForm OS offers non-disruptive upgrades between different minor and major release versions. XIV is reported to offer online updates between minor operating system releases only.

These are just some of the problems that make the IBM/XIV platform unsuitable for utility computing; unsuitable for shared virtualized infrastructures for flexible workload consolidation; unsuitable for handling diverse and unpredictable workloads; unsuitable for delivering a very low total cost of ownership through high written capacity utilization; and therefore unsuitable for cloud computing, SaaS, HaaS and Web2.0 environments.