VMworld 2012 Storage Nerdvana: vVols, vSAN and vFlash

Announced this year at VMworld 2012 (Watch the Monday general session from 51:26) were several cool technologies coming from VMware in the near future that focus on storage, or rather vStorage: Virtual Volumes (vVols), Virtual SAN (vSAN) and Virtual Flash (vFlash?). So what is this all about, and where is it going?



Virtual Volumes or vVols

How SAN and NAS systems work today, is something that they have been doing for years: Take a bunch of disks, stripe data across them introducing some availability from failure, bind them together in logical chunks and deliver them out to servers. This is still the case today: You have either LUNs or exports/shares and you put a number of virtual disks on them.

But think about it: Is this really the optimum solution? What if you want to replicate a VM… Yes you need to replicate the entire LUN to the other side. So one approach is to just create LUNs of x size, and put VMs on them, but the other approach is to dedicate LUNs to a certain VM to allow for granular replication… and there is no optimum mix. Or is there? What you would like to have is just one endpoint to onnect up all VMs, and be done with the entire idea of LUNs or shares:

From LUNs to vVols. From many LUNs to a single protocol endpoint… No more LUN carving!


So what would this look like in a real world? I guess the array would still deliver a single LUN or NFS share/export, which is used for control of the vVols. Next to that, the vVols would be delivered directly out to the VMs running on vSphere, where the volumes could be primary VMDKs, backup copies, replicas, clones, thin, thick, etc. Profiles would be used to tell the storage what kind of performance, QoS and space limitation a certain vVol would have.

It is a cool new way of thinking about storage, and it will surely become mainstream in the years to come. Try to get your head around it for now, be more comfortable with the idea in the future.


vSAN

Another announcement made this year at VMworld was the idea of a virtual SAN, or vSAN. As we all know, VMware is already taking this route with their vSphere Replication and the vSphere Storage Appliance. But these are quite limited, and can right now be seen as glue-on products.

The new vSAN approach is far more interesting; in this setup the vSAN technology is embedded right inside the vSphere hypervisor, being part of the core technology without any virtual appliances:

Overview of the vSAN technology, leveraging local storage inside vSphere nodes to prosent out as shared storage. Note the fact that the “distributed storage” is part of the actual hypervisor, much like the already existing distributed networking.



If VMware can get away with building this in a way that:

  • vCenter is used only to configure this, NOT to bring it online;
  • Protect the data across nodes in a mirror or RAID-5/6 style;
  • Allow more than three nodes to be used (which is a limit of the current VSA implementation);
  • Harden the system to cope with segregation of nodes (and the split-brain nightmare);
  • Come up with some decent snapshotting technology inside.

… It may actually work very well. The idea of integrating the SAN inside the hypervisor gives way to all kinds of new ideas and integrations, which will become much easier as you will not need any 3rd party stuff to integrate things. On the other hand: Building decent storage is hard, VERY HARD.


Designing storage is hard… VERY HARD
Allow me to give you one very simple example just to show how hard designing storage is:

Ever considered a two-node setup where you’d use the VMware VSA to turn local storage into shared storage? Let’s look closer how VMware built this:

  • The VSAs mirror their storage across both nodes;
  • For each piece of shared storage delivered, there is a master and a slave node;
  • The master performs IOPS in and out of its local disks, and syncs the writes to the other node.

Looks bulletproof right? Now imagine these three scenarios:

  1. The master node dies;
  2. The slave node dies;
  3. The master and slave nodes loose connectivity between each other.

The first two are really easy: If the master dies, the slave takes over, right? And if the slave dies, the master continues to deliver the data… But consider the third failure scenario: The master thinks the slave failed. The slave thinks the master failed. Question to you: Should the slave resume the I/O or not?

As you may have guessed, there is no right answer to the last question: If the master truly is down, the slave could safely resume I/O. If master and slave were segregated, the slave should NOT resume I/O because split brain would occur. The difficult part is to identify which failure scenario is taking place. This throws you right into the stretched cluster discussions where for example the EMC VPLEX is managing quite well, but requiring a third site (where a “Witness” lives that decides between the two scenarios). SO I’d vote for the three-node setup using the VMware VSA any time… Not as simple as you initially thought right?

I hope VMware gets it right though; the abilities of a powerful vSAN are limitless!


Virtual Flash (vFlash?)

Looking at the vSAN overview above, you may have noticed flash being drawn there as well. Will the vSAN incorporate flash? Definitely… Looking at the third interesting vStorage announcement made by Steve Herrod at VMworld 2012 (Virtual Flash), I think there will be two different but closely related solutions: Next to vSAN, we will probably also see the Virtual Flash (vFlash?). The vFlash would create a pool of local SSDs, that would perform read AND write caching for VMs:



All of this looks very much like the way EMC has been incorporating flash into its arrays: In the array itself you can have disks of several types (NL-SAS/SATA, SAS and SSD). Inbetween controllers and disks so to speak, you have FAST-cache, which is basically (but not exactly) an SSD-based extension of the DRAM cache.

Looking at the way VMware now paints the picture of storage futures, I see the exact same thing: Flash lives as a tier in the vSAN, or as a tier that performs caching. Coincidence or could it be that EMC and VMware are working closer and closer together? I’m guessing the latter… We have seen a lot of stuff coming from EMC being incorporated into VMware (anyone remember EMC autostart which became the original HA?) and still there is more to come (look at the new VMware VDP where EMC’s Avamar technology steps up to the plate to make backing up and restoring really cool and integrated).

I am hoping that VMware’s technology will someday reach that point: Autotiering between tiers like EMC’s FAST-VP to obtain “cheap GBs with near-SSD performance”, while caching reads AND writes in memory and/or SSDs to instantly boost performance where the autotiering is not granular or fast enough: Storage nerdvana!!!

One Response to “VMworld 2012 Storage Nerdvana: vVols, vSAN and vFlash”

Soon to come
  • Coming soon

    • Determining Linked Clone overhead
    • Designing the Future part1: Server-Storage fusion
    • Whiteboxing part 4: Networking your homelab
    • Deduplication: Great or greatly overrated?
    • Roads and routes
    • Stretching a VMware cluster and "sidedness"
    • Stretching VMware clusters - what noone tells you
    • VMware vSAN: What is it?
    • VMware snapshots explained
    • Whiteboxing part 3b: Using Nexenta for your homelab
    • widget_image
    • sidebars_widgets
  • Blogroll
    Links
    Archives