Stardate: 5977.497.471 (Aka VMAX3 has a big day)

Congrats to the VMAX engineering team - for getting the Q4 VMAX3 Service Release out last week as committed! The specific release is 5977.497.471, which there was an internal thread where Jeremy Burton noticed it looked like something from.

"Captains Log. Stardate 5977/497.471. We're circling planet Nebulon 4, where the Borg have .."

In all seriousness - this is a HUGE release ("SR" doesn't do it justice).

With VMAX3 we decided to move from one colossal release in a massive "waterfall" like release, into something more akin to a staged release (not quite "agile" CI/CD - but a great improvement to huge massive batches0. It's important to not understate the code complexity (HYPERMAX has about the same amount of new code as the 2.6 Linux kernel).

It's also important to not understate that these systems are placed into the most mission critical use cases you can imagine, so hardening the base IO stack before putting the next stage of releases (replication/indirection as well as the first layered HYPERMAX functions) makes it easier for customers to press them into action and validate at the right pace.

This second part of the release adds a ton of new capabilities - most interestingly to me are these 4, because they represent something interesting to both the customers, and from a core technology standpoint.

Embedded NAS: Using the revolutionary new HYPERMAX OS hypervisor technology, customers get VNX file inside VMAX using software defined data movers and no additional hardware.

Why this is cool for customers - VMAX is now truly a unified platform, not just in the control plane (Unisphere for common management), but in offering block/NAS data planes - without the need for additional hardware.
Why this is cool from a tech standpoint - we've been on a journey of modularizing the code, using abstractions (both kernel mode, and container-type) for storage stacks. VNXe works this way, and VMAX does with HYPERMAX. Future VNX platforms will work the same way. BTW - this uses the same NAS stack (with all the associated capabilities) as VNX2 (it's File OE 8.x). I'm looking forward to the day where we use this to eliminate the service processor entirely, to eliminate the need for gateway devices in all shapes and forms :-)
Scale points: For each platform, there's a maximum number of data movers (which are really a logical thing now). Specifically: VMAX 100K - 2 data movers, 2 control stations; VMAX 200K - 2 or 4 data movers, 2 control stations; VMAX 400K - 2 or 4 data movers, 2 control stations
I/O Modules: 10 GbE, 2-port optical; 10 GbE Base-T, 2-port copper; 1 GbE Base-T, 4-port; 8 Gb FC, 4-port (backup to tape)
ONE IMPORTANT NOTE for embedded NAS - a bummer, but to make sure we're nailing it, it applies only to new configurations - no upgrades to existing VMAX3 arrays with the Q4 2014 Service Release

TimeFinder SnapVX: the next generation of local replication, with snapshots now existing 100% in memory for instant copy creation and deletion.

Why this is cool for customers - finally (it can be argued this is overdue) VMAX can do modern snapshots, with no target device requirement, no Symmetrix Logical Volume (SLV) number used, no cache (!!!!) used. and it's fully compatibile with SRDF and FAST.
Why this is cool from a tech standpoint - snapshot engines are fundamentally about metadata and pointer mechanisms. Clearly we've moved away from a core COFW approach, and clearly have totally overhauled the core engine here. This (in all storage) is also the core engine for other data reduction techniques (dedupe and compression). Expect this to be the foundation for more to come.
Scale Points: up to 256 snapshots and 1024 mounted copies per source.

SRDF: People ask "why enterprise arrays" vs. AFAs - but, IMO they are missing the point. That question presumes that people pick "enterprise arrays" for performance. That hasn't been true for a long time (technically at least). When it came to $/IOps, latency at a given $, bandwidth at a given $ - "enterprise" has lagged (and even now lags) AFAs and some dense-flash "Type 1" hybrids (which have very simple direct IO paths relative to Type 2 hybrids) - BTW - see here for definitions of these storage stacks. The reason that people select "enterprise" arrays is not performance, but Reliability, Availability, and Serviceability. That can mean scale (tens of thousands of consistency groups), it can mean RPOs that are the tightest, it can mean many things - but for many, many customers - it means SRDF. We've taken the industry-leading remote replication and made it even better. How? By taking advantage of VMAX3's Dynamic Virtual Matrix we could make SRDF operations highly parallelized and therefore smoking fast. SRDF/A got enhanced to provide bookmarking yielding more granular control of RPOs. Hardware compression is available across all models to drive better space efficiency .

Why this is cool for customers - SRDF. The best enterprise-class remote replication just got better.
Why this is cool from a tech standpoint - as the engineering team re-wrote core parts of the core, the model of HYPERMAX to take parts that used to be "pinned" to a core and make them distributed (and linked to the accelerating inter-node fabric that defines "Type 2" shared memory space storage stacks) makes old things better (SRDF, dynamic balancing of FA/DA etc). but also makes new things possible!

ProtectPoint: This is really a industry-unique thing. The engineering team integrated VMAX3 and Data Domain to provide faster, more efficient native backups, streamlined granular restore, and no application server impact .

Why this is cool for customers - When you have a mission critical app (and usually the part of the app stack that the VMAX touches is the high-end RDBMS - usually Oracle - built on a platform 2 architecture depending on rich infratructure services) - backup is as important as DR. So while the new SRDF stuff is great, there was an opportunity to innovate around the backup/recovery part of data protection. This ain't superficial integration - it's deep, and makes lightning fast backup and recovery that never touches the network. It has the behaviors of a snapshot for near term fast test dev and recovery, with the retention of a longer-term backup. If you like things like NetApp snapshot->snapvault (which are great choices from a respected competitor), and wish that it had all the things you love about Symmetrix and Data Domain - you just got it :-)
Why this is cool from a tech standpoint - this uses Federated Tiered Storage (EMC lingo for being able to use an external storage target) which we integrated to work with the Data Domain vDisk format model. This means you keep all the things you love, and get the added benefit of Data Domain SISL and the core dedupe engine. The integration automates the full Oracle RMAN integration toolset required. It's a reflection of what we can do if we keep simplifying where we can at the control plane layer (think ViPR Controller, Unisphere) but also using the intellectual property in the portfolio together more and more in the data path itself.

There's more of course (Unisphere updates which are nice, huge improvements to OpenReplicator, etc..) A huge shout out to the engineering team that worked so hard to deliver this holiday gift for EMC customers!

What are your thoughts? Are you a VMAX customer - give us good/bad/ugly feedback on what you see us doing!