In a play on the old saying “the king is dead; long live the king!” this post will opine about the current resurgence of locally attached storage in the data center.
Before the emergence of virtualization, as some of you might remember, came the physical server. Yes, folks, we really did have a single machine running a single OS, and we really did have that machine running multiple applications or services. AD with DNS? DHCP and WINS? Not a problem. Also, while you are at it, put certificate management and dogfood on there too. Yep, why not?
Once virtualization started to spread though the computer room—yes it was a computer room—and processor capabilities caught up with the technology, our choke point moved to disk. DAS-based disk just did not allow the sexy stuff like vMotion. Also, the possibility of losing all our machines upon the failure of a single host was, quite rightly, a step too far. Anybody remember the “eggs in one basket” arguments? So, we started the massive move to SAN/NAS-based storage, which has arguably made many a company rich. In fact, this move made EMC buy VMware outright.
This, however, has turned out to be a poisoned chalice. Our computer rooms have morphed into “data centers,” and we have many multimillion-dollar SANS, all running our virtual machines. It would be fine if that were all they were doing; however, the majority of corporate SANS are multitasking, running VMs for servers, running VMs for desktops, running traditional storage (i.e., storing files in file servers and data in databases and CRM applications. This all makes for a chaotic array, with lots of different traffic profiles and some heavy-duty operational overhead.
Fast-forward to the twenty-tens, and suddenly DAS is cool again. However, this is not just any old command and garden locally attached disk. This new world of DAS has all the benefits of data locality, coupled with the benefits of array redundancy.
The move back to local disk started with the rise of the virtual storage appliance (VSA). A VSA is a VM that runs on your local disk. It uses the disk attached to the host it is running on to present a datastore for your hosts to consume, by running a VSA on a number of hosts. You can share their disk and provide for resilience from node failures by having duplicate data stored on remote hosts. Think LeftHand (now HP StoreVirtual) and VMware’s virtual storage appliance.
The next generation of DAS SANS was the hyperconverged crew: Nutanix, SimpliVity, and Scale Computing. These companies provide a black-boxed appliance, usually sold in starter packs of three units for resilience.
These insist that they are software-defined storage vendors, but that is an argument for another post. These three vendors provide a DAS-based appliance that converges storage, network, and compute into a single black box (hence the term “hyperconverged”). These three players are more advanced in their use of DAS: they utilise tiering to accelerate the IOPs by funky use of SDD to provide local caching of in-movement datablocks. They also further enhance the VSA paradigm by including features like dedupe or compression. These are not cheap, however, and you need to purchase three when you start to get the resilience required. Nevertheless, what they do give you is a single throat to choke for your virtualized infrastructure, and a single entity to manage.
The above image shows the architecture of a Nutanix cluster. Note the similarity to the VSA architecture. There is a controller VM on each node, and again the local storage is aggregated across the nodes for resilience. However, see the SSDs this allows for a local caching of inflight data to accelerate the IOPs available to the guest VMs.
The final (for now) chapter in this story is VSAN. This is VMware’s entry into the software-defined storage melee, and a natural progression in the story. Here, as with the scale-out architecture of the previous sections, the VSAN has tiering for IOPS acceleration. What it currently does not have is dedupe or compression. However, it does have storage profiles; this is where you can apply a form of QoS on your VSAN storage layer. The one major difference between VSAN and the previous iterations of DAS storage is that the active element is not a virtual machine running on the ESX host, but is actually installed in the vKernel as a VIB. (A VIB is a VMware method for extending the vKernel with additional features.)
Like the web-scale architecture of Nutanix, SimpliVity, and Scale Computing, VSAN grows linearly. Unlike Nutanix, SimpliVity, and Scale Computing, however, your nodes can be disparate. The only commonality is that they must have a flash-grade device. The actual disk capacity behind the flash can be different sizes and speeds.
It is the “grow your own” ability that is VSAN’s strongest and, paradoxically, weakest link. With VSAN, your node can be anything off the HCL. You are not forced into a common hardware platform predefined by a vendor. True, you can buy VSAN-ready nodes from tier-one vendors like Cisco, Dell Fujitsu, and even Supermicro. Yes, you can buy the exact same unit that Nutanix uses for its environment and create a VSAN on it.
This is exciting technology, and there are many use cases that it can address. However, this is not the end of the road. The real question that is being answered here is not what product is best, but instead where the best place to have your data is. The hyperconverged paradigm answers some questions, but not all. The plain fact is that your data runs faster when it is local to the compute.