During a recent visit with a prospective customer, I was discussing how simple SimpliVity hyperconverged infrastructure is to deploy and use. While “child’s play” might sound far-fetched, it’s actually not. In fact, when I was explaining concepts of our hyperconvergence and deduplication, I found myself using a child’s toy in my analogy … in this case, Legos.
For those of you who didn’t play with Legos as a child (or adult), Legos are colorful interlocking plastic “bricks” used to construct things. Today, Legos may come by the bucket—a mix of bricks, gears, mini figures, etc.—or come in sets with guides for building everything from the Eiffel tower to the Star Wars Deathstar.
So what do Lego bricks have to do with hyperconvergence? Well, SimpliVity OmniStack software delivered on an x86 system creates hyperconverged infrastructure that assimilates all data center infrastructure and services “below the hypervisor.” This is a SimpliVity OmniCube building block. You use OmniCube systems as building blocks to create VMware clusters in your data centers. And, when you need more CPU, memory and storage capacity to your data center, you simply add OmniCube building blocks.
One of the key features of SimpliVity’s hyperconverged infrastructure is data efficiency. SimpliVity’s Data Virtualization Platform deduplicates, compresses and optimises all data upon ingest. I’ll use Lego in my analogy to explain how this works.
We all know that virtualization provides an abstraction layer between the physical hardware and the software running on it. SimpliVity’s Data Virtualisation Platform abstracts data from its underlying hardware. Virtual machines running on SimpliVity are actually just data maps pointing to deduplicated blocks on the storage.
When a VM writes to the Data Virtualisation Platform, all the changes are registered to map to the physical deduplicated unique blocks on the disk. It only does a physical write to the disk if there is a new unique 4K-8K block that was never before received from anywhere in the cluster. Otherwise, the map is updated to note the location of the existing block. This makes the VMs very “light” and portable, and enables you to clone, move, back up and recover VMs in seconds.
Let’s imagine a virtual machine on a host (in this case, an OmniCube system) is a “Lego Racing Car” set. For this analogy, the instruction booklet is equivalent to the map (i.e., the details for which Lego bricks and in which order you need in order to build the “Lego Racing Car”), the Lego bricks are data, and the bucket holding the Legos is your physical storage.
I build my racing car to spec. The instruction guide is the map for what I have built. Now, let’s say, I replicate my “Lego Racing Car” from my Las Vegas data center to New York. Instead of moving all of the legos used in my car construction, I just move the instruction book. Once the instructions arrive, there’s a check for which Lego bricks I have in the New York Lego bucket versus those used to build the Lego Car. If I do not have some specific Lego piece in New York, then I just have to request that one is sent from Las Vegas.
It’s a lot faster and easier to move just the instruction books and use the Legos that exist at the destination than to move all the Legos from a bucket in one location to one in another location.
The same thing occurs for backup and recovery tasks. It’s a lot faster to work with the instruction books detailing the required Lego bricks (the map) than to move all the pieces of your Lego creation (the data) around between buckets (physical storage).
Child’s play, right?