This post is live-blogged from the SimpliVity presentation at #VFD4. The structure and organization will undoubtedly be poor, since this is all captured on the fly from our chat.
Overview
Jesse St. Laurent kicked off the presentation by helping us understand where OmniCube fits in the market, where it fits in the data center, and what sort of workload it’s suited for. 65% of SimpliVity customers surveyed (out of 66 participants) run 100% of their enterprise apps on OmniCube! He told us that cities run their 911 app and banks run their ATM app on OmniCube. Backup to AWS is possible, but the standard model is to replicate between OmniCubes at different sites within the organization. The backups in AWS aren’t VMs that can be turned up, so you would need an OmniCube to restore to in the event of a failure. You can use the storage/replication/deduplication features of OmniCube with additional “computer nodes” (which would be an ESXi host for instance). This helps create the ability to scale non-linearly, which is a typical concern with hyper-convergence.
Demo
We got to see a sweet demo where we looked at the Federation View, the Data Center View, and the VM-level View. The OmniCube management is done through a vSphere Client plugin, and a vSphere Web Client plugin is coming with the next release of vSphere. (Who knows when that could be?!?) The Federation can operate in a hub-and-spoke layout, or a full-mesh layout, depending on your unique needs, and supposedly their federation technology is smart enough to figure out which is best. Backup and replication are managed via VM-based policies. They are notably very simple, and that’s part of the draw here. Policies are always VM-based, and at this time there isn’t a way to assign policies to a higher level construct like a folder or a resource pool. The deep integration with the vSphere Client is purposely designed so that an administrator familiar with managing a VMware environment will have an easy time jumping in. File-level restore is coming soon, it will mount removable media to the target machine and allow a user to copy off the requested data. It can’t automatically overwrite the target, which is by design. Better safe than sorry when it comes to data. 8 Omni nodes per data center, 32 nodes per federation.
Data Efficiency in Hyper-convergence
The OmniCube Accelerator is what allows deduplication of data at inception, and then not have to rehydrate/dedupe again moving forward. Offloading CPU cycles and IOPS to the card allows inline processing without taxing the resources used to run VMs. The card is designed by SimpliVity – definitely purpose-built and not an off-the-shelf card. Every write to Omni storage goes to multiple cubes. As such, a card failure will be handled gracefully by the system.
Architecture Deep-Dive
The components of their Data Virtualization Platform are Accelerated Global Predupe (via the aforementioned card) and Global Unified Management. These things allow the delivery of true hyper-convergence. Part of what makes the efficiency possible is that the DVP organizes disparate sized writes into full stripes before writing down to disk. Also, hot blocks are cached (not tiered) so there’s no overhead in moving data back and forth. Changing gears – there is no additional software licensing. Everything is included. Global data-efficiency is achieved in part by leveraging metadata references in an “object storage” sort of fashion, although this isn’t exactly object storage. Due to this design, substantially less data needs to be sent across the wire during replication. Also, backups are more efficient, because a copy of the metadata tree can serve as a point-in-time to restore to.
That’s it for this session! I’ll have more thoughtful follow up info later. Join us again in about an hour for Platform9!
