This week EMC announced Unity/VNX3 as a flash-optimized array that can help you modernize your IT. While we applaud EMC for aggressively shifting its product line to all-flash and espousing the view that an all-flash storage environment is key to modernization, the question that arises is can you use a 20-year old architecture configured with all-flash to drive “real” business and IT transformation?
Before we dig deeper, let’s highlight a few things we like about Unity/VNX3:
In the previous post titled Retro meets “Modernize” at EMC World 2016, Matt Kixmoeller made the argument that modern, all-flash arrays rely on rich, always-fast metadata architectures, where the metadata is core to the inter-workings of the array and is difficult or impossible to retrofit. Here are several important and tangible considerations where we feel Unity exhibits its retrofit heritage and falls short in delivering results:
1. NOT Efficient: Unity/VNX3 doesn’t offer any data reduction technologies (deduplication or compression). While Pure can deliver 100TBs usable with 35TBs raw flash with an average of 5-to-1 data reduction, Unity/VNX3 would require 125TBs (72% more flash) to store the same amount of data. To be fair, EMC has announced plans for introducing a software update to add inline compression in Q2’16. Customers may be wary given the experience of XtremIO customers who were left stranded on XIOS3.0 with the introduction of compression in XIOS4.0. Customers will also need to understand the potential performance impact of switching on compression, as it will add additional load to the Unity CPUs. A non-obvious caveat is that VNX2 customers who are using file level dedupe and planning to forklift upgrade to Unity/VNX3 will be taking a step backwards with no data reduction and may need to buy extra, unplanned capacity.
2. NOT Simple: Given the slick marketing demos at EMC World, a view that Unity/VNX3 is not simple may seem strange… but, let’s explore the complexity that is built-in:
2a) RAID management: You must choose between RAID 1/0 (1+1, 2+2, 3+3, 4+4)/ 5 (4+1, 8+1, 12+1)/6 (4+2, 6+2, 10+2, 14+2) on a per Pool basis. Sound simple?
2b) Pool management: This is probably the Achilles heel. Drives are grouped into “Pools” with an assigned RAID type before storage LUNs can be created. There are several implications for the administrator that stem from this:
– Creation of pools creates silos of drives. LUNs provisioned from a given pool can only access the performance of the subset of drives in the given pool, not the entire system. Sound simple?
– Pools can lower the capacity utilization due to stranded capacity. Once a drive is admitted into a pool, you may not be able to shrink the pool (we’re not aware of such a capability existing). Different apps tend to grow at different rates, and capacity in one pool might be sapped faster than another, leaving you with capacity that is available but can’t be accessed from outside the pool. Sound simple?
– An All-Flash pool consists of a single drive size and single RAID option. Use the same drive size and freeze the speed, density, and economics of the flash that you purchase for the lifetime of the system or create more pools in the future. Sound simple?
– According to the EMC Unity Best Practices Guide, “Storage Pools MUST maintain free capacity in order to operate properly. By default, Unity will raise an alert if a storage pool has less than 30% free capacity, and will begin to automatically invalidate Snapshots and Replication sessions if the storage pool has less than 5% free capacity. EMC recommends that a storage pool always have at least 10% free capacity, in order to maintain proper functioning.” An immediate ominous question comes to mind: What will happen if the pool runs out of free capacity? Sound simple?
– Snapshots and Replication complicate pool management. According to the EMC Unity Best Practices Guide, Snapshots use the pool capacity to store the older data being tracked by the Snapshot, which increases the amount of capacity used in the pool. Similarly, Asynchronous Replication creates Snapshots, which consume capacity. Setting a lower RPO, results in more Snapshot operations and more capacity consumption. Considering the severity of running out of capacity in a pool, you might be better off on Unity/VNX3 not using native snapshots and replication. Sound simple?
2c) Data-at-Rest Encryption upfront selection and key management: Encryption is optional and can only be turned on at the time of system installation. EMC recommends making external backups of the encryption keys after system installation, and immediately following any change in the system’s drives (such as creating or expanding a storage pool, adding new drives, replacing a faulted drive, etc.). Sound simple?
2d) Hot Spares: Traditional approach to setting aside dedicated hot spares is employed. One hot spare drive is set aside per drive capacity type per 30 drives. So, adding different drive sizes, not only incurs additional pool management overhead, but it also costs you additional dedicated spare drives. Sound simple?
2e) NAS servers management: NAS servers are assigned to a single SP (Storage Processor), and all file systems by that NAS server will have I/O processed by the single SP. For load balancing, the EMC Unity Best Practices Guide recommends that you create at least two NAS servers per Unity system and assign file systems to each NAS server. Sound simple?
3. NOT Scalable: While Unity/VNX3 supports scaling the capacity online to PBs, performance can’t be scaled non-disruptively given it’s scale-up architecture. For example, if you start on Unity 300F, there is no non-disruptive path to upgrade the controllers to Unity 400F, 500F, 600F, or to a next-generation controller. In contrast, the Pure Storage FlashArray offers non-disruptive scaling of capacity or performance (including upgrades to next-gen controllers) with zero performance impact. FlashArray//m10 can be upgraded online to //m20, //m50, //m70 or //m.next.
3a) We were surprised that given its positioning as an all-flash array – arrays that are typically deployed for performance use cases – that performance data was lacking in the Unity/VNX3 launch. From the scant public information, our understanding is that Unity 600F can offer up to 300,000 80/20 (R/W) 8K IOPS. While 8K figures help to buttress hero claims, our experience with real-world workloads has been that 32K average block I/O is prevalent. That’s why we quote 32K IOPS numbers. Adjusting Unity/VNX3’s IOPS to the real-world 32K numbers reveals Unity 600F is capable of 75,000 32K IOPS (hardly respectable for an all-flash array). The Pure Storage FlashArray //m10 (entry model) can deliver more at 100,000 32K IOPS. It’s also important to understand that the performance numbers that Pure quotes are inclusive of data reduction, encryption, and dual-SSD failure protection being always-on. The Unity 600F performance information is likely NOT inclusive of any of these data services/protection levels, thereby leaving you to face tradeoffs and added risk.
4. NOT Resilient: Unity/VNX3 doesn’t have a published proven track record of delivering >99.999% availability for mission-critical enterprise workloads. Given it’s Active/Active dual-controller architecture, you stand to have significant application performance impact (up to 50%) upon a controller failure under load (note same behavior applies to software upgrades). And, while dual-drive failure protection is an option with RAID 6, you would have to manually configure it consistently for each pool. Otherwise, dual SSD failure (e.g. a failed drive and a bit error on another) can land you in data loss situation. (Note RAID 6 should be your RAID selection to protect against this risk.) In contrast, the Pure Storage FlashArray offers proven >99.999% uptime across our installed base with hardware, software and generational upgrades included; full performance during controller failure; and dual-SSD failure protection is built-in.
5. NOT Evergreen: While Unity/VNX3 has been added to the EMC XpectMore Program, which offers up to 7 years of flat maintenance, it is nowhere close to delivering the benefits of Evergreen Storage. Given the architectural limitation of not being able to support non-disruptive controller upgrades, Unity/VNX3 locks you into today’s compute technology and your storage infrastructure ages as compute and flash continue to advance annually consistent with Moore’s Law. The inevitable driver to upgrade to get to the latest technology advances requires a complete re-buy of the hardware and software and migration of 100% of your data. That’s been the reality for EMC CX, VNX, and now the VNX2 customers. And the same will apply to Unity/VNX3. That’s not Evergreen.
While Unity/VNX3 may be a fine option for customers who have a $20K budget constraint, anyone else who can afford to spend a little more can get a lot more with Pure Storage FlashArray//m10.
Imagine an all-flash array that:
That’s a lot more than EMC Unity 300F. That’s modern. That’s //m10!
Before I close, I want to touch upon one other important point. There have been some suggestions that the Pure Storage FlashArray//m70 is comparable to EMC Unity 600F – I find that amusing. While both products use dual controllers, the similarities end there. If the aforementioned retrofit limitations of Unity/VNX3 and the advantages of the Pure Storage FlashArray still have anyone confused, here’s our comparison of //m70 and Unity 600F. The result: we estimate that the //m70 requires 70%+ less flash and less than half the space (rack units) to store 400+ TBs of data while delivering 4X the IOPS for real-world applications workloads.
Given the retrofit limitations of Unity/VNX3 in every dimension (Not Efficient, Not Simple, Not Scalable, Not Resilient, Not Evergreen), one should question its suitability for modernizing your data center, especially when modern, Tier1 all-flash arrays (such as Pure) offer the opportunity to modernize without these compromises. If you’re interested in hearing more about our vision about modernizing and/or ready to accelerate the possible, drop us an email or give us a call.