Introduction to SimpliVity
Founded in 2009 with a mission to simplify IT infrastructure, SimpliVity is one of the “Names” in the hyperconverged infrastructure space. Their OmniStack Data Virtualization Platform can be purchased in one of two ways:
- Pre-installed on a hardware appliance called an OmniCube
- As software to run on approved supported server hardware like Cisco UCS and Lenovo
The key to the OmniStack Data Virtualization Platform (DVP) is the inline, global data deduplication. As Simplivity is fond of saying, the least expensive write is one you don’t need to write.
In the hyperconverged stack, the DVP handles everything below the hypervisor layer. Incoming data is read into memory. If the DVP recognizes an 8k block as unique data it already has, it simply updates the metadata (which it would have had to do anyway if it were going to write the block). Writes only happen when a unique block that’s not already in the object store comes in. Unique data and metadata (and only unique data and unique metadata) are stored as small objects in the DVP’s own object store.
Now you’re thinking something along the lines of “Wait a second — virtual machines and their virtual disks are represented as files, not as 8k objects. You need a file system somewhere, don’t you?” Yes, you’re right; you do.
DVP presents the data to ESXi as a sort of virtual NFS filesystem. [NOTE: The phrase “virtual filesystem” is mine and one I use to help myself understand what’s happening deep inside the DVP. SimpliVity doesn’t use that phrase — they just say “is presented as NFS”.] The hypervisor sees the files it’s expecting, and acts accordingly. It doesn’t know that those files have been assembled from combinations of 8k objects in an object store — and it doesn’t need to; that’s the whole point of virtualization and layers of abstraction.
Yes, SimpliVity built their own object store and filesystem from the ground up. They probably could have had a product on the market earlier (SimpliVity only launched a product after 3.5 years of development) if they’d used an existing filesystem, but then they wouldn’t have the crazy data efficiency that they do. To date, SimpliVity has sold 1,000 Cisco UCS servers running OmniStack, storing more than an effective 350PB of data on them.
If you’ve followed that, now you’re thinking something like, “so if they’re just presenting the object store to VMware as if it were NFS, couldn’t DVP also present its storage to another hypervisor as if it were another type of filesystem?” In theory, yes, absolutely. In fact, that’s part of SimpliVity’s vision for the OmniStack DVP. Their intention is to be hypervisor-, hardware-, and management platform-agnostic. That is, the long-term goal is to be able to run any hypervisor (vSphere, Hyper-V, or KVM), on any server hardware (as long as it’s x86 or AWS) and use any management platform. At the time of this writing, VMware vSphere is the only hypervisor supported by OmniStack, but don’t expect it to stay that way.
Up until now, VMware vCenter has been the only management platform supported by OmniStack, but that changes with:
The latest version of the OmniStack Data Virtualization Platform adds several new features. I’ll focus on the big ones:
- Intelligent Workload Optimizer
- REST API
- Support for Multi-Node Stretched Clusters
Intelligent Workload Optimizer
The workload optimizer in DVP 3.5 takes a multi-dimensional approach to balancing workloads running in an OmniStack Federation. vSphere’s Distributed Resource Scheduler (DRS) is also a load-balancing tool, but it only considers CPU and memory resources. Customers with Enterprise Plus licenses for vSphere can also use Storage DRS to automatically migrate VMs between datastores (for example, from HDD to SSD or vice versa), but those migrations take time and aren’t helpful in the event of rapid changes in storage performance needs.
The DVP 3.5 workload optimizer considers:
- I/O Performance
- Data location
and does what it can to have applications running at peak performance without the need for migrations.
DVP 3.5 adds a new REST management API with simple commands and an integrated development environment. The hope is that with this available, it will help to encourage third-party management tools to add SimpliVity support to their suites. Additionally, customers can write their own scripts or applications.
The graphic below shows a sampling of some of what’s available via the API.
Multi-Node Stretched Clusters
I’ve found recently that there’s often confusion around what exactly a stretched cluster is. SimpliVity Federations can add to this confusion. Prior to 3.5, you could have an OmniStack Federation at one site working with another OmniStack Federation at another site, and manage them both through a single interface. Each Federation can provide data protection and failover services for the other. This, however, is not a stretched cluster. This is two separate clusters working together.
In “SimpliVity speak”, a stretched cluster would be a single OmniStack Federation with some of its nodes at one site and some at another — while still having them act as a single cluster.
Why do this? Stretched clusters offer customers some great benefits, including:
- Ability to balance workloads between/among sites
- Better availability and resiliency than all sites working from a single central data center, or than each site working only from their own data center
- Easier to meet uptime Service Level Agreements
- A Recovery Point Objective (RPO) of zero and a Recovery Time Objective (RTO) of seconds — if one site goes offline, VMware HA will automatically restart the VMs that had been running at that site
With all this awesomeness, why doesn’t everybody run stretched clusters? We’re still stuck with the limits of the speed of light. In order to work, the sites in a stretched cluster can’t have more than a 5ms round-trip latency for data packets. This means a stretched cluster works great across different buildings on the same campus, or between data centers no further apart than 60 miles (100km) or so.
In addition to OmniStack 3.5, SimpliVity also announced a new offering called OmniView. OmniView is Software as a Service (SaaS) that runs in the SimpliVity Support cloud.
OmniView provides insight into running SimpliVity deployments. It has customizable dashboards and reports, allowing for easy visualization of what’s happening in the SimpliVity deployment.
OmniView keeps track of historical data about the deployment and uses predictive analytics to spot trends and make forecasts that can be used for capacity planning.
OmniView offers the ability to drill down into multiple vCenter and SimpliVity data points in great detail, which can be helpful in diagnosing and troubleshooting any issues that come up.
You can see a screenshot of an OmniView dashboard below. It shows:
- Number of VMs
- Highest VM CPU usage
- VMs with highest CPU contention
- Largest unique backup growth trend
OmniStack 3.5 will be GA on 18 April.
OmniView will be GA on 18 April, but with caveats. OmniView is only available to those SimpliVity customers who have purchased the Mission-Critical level of support from SimpliVity. Approved SimpliVity partners will also have access to OmniView. OmniView is supported with OmniStack 3.0.8 and later.
In no particular order:
- I’ve been a fan of SimpliVity since I was first introduced to it. I like it that they have a big vision (any hypervisor on any hardware managed by whatever you want), but I also like it that they’re not trying to get to the entire vision all at once. Slow steps, but definitely always tangible forward progress towards that vision.
- If you read the SimpliVity press release, you may be thinking I’ve accidentally left out SimpliVity’s announcement of support for Hyper-V. I haven’t. Instead, I view it as SimpliVity accidentally mentioned Hyper-V support. OmniStack 3.5 doesn’t support Hyper-V. OmniStack will, at some as-yet unspecified point in the future support Hyper-V. I don’t know why they mentioned it. It’s not an announcement, but a dropping of a hint about an intention to announce it at some point in the future.
- I’m looking forward to getting some hands-on time with OmniView. I’m hoping I have a customer who qualifies for it, since my having access to that level of info about their systems would only improve the level of service I can offer them.
- For a while now, I’ve been telling a couple folks at SimpliVity that they should be talking to the folks at VMTurbo to get some Control Modules created for SimpliVity. I’m hoping that the new API in DVP 3.5 makes this integration possible now.