Storage for Multiple Hypervisors With Tintri | Tintri

0 0

Storage for Multiple Hypervisors With Tintri

At Tintri, we built a VM-aware storage system with hypervisor neutrality in mind from the beginning. VMstore has been designed from the ground up to support multiple hypervisors concurrently providing the same level of per-VM data management and monitoring across all of them. It is easy to say that, of course, so we decided to put our money where our mouth is. We are proud to announce the technical preview of Red Hat Enterprise Virtualization (RHEV) support. Tintri VMstore’s architecture makes it easy for us to support per-VM performance visibility, snapshots, clones and replication functionality on RHEV just as we do for VMware.

A VM is a VM

While each hypervisor has its own unique capabilities and features, all VMs appear to be a similar set of properties to storage - they are a collection of disks (in similar formats) and configuration information.

Since Tintri breaks the VM down into these components, our VM-aware architecture allows us to accommodate different hypervisors easily, and treat VMs from one hypervisor the same way as the VMs from another hypervisor. This leads to a unified experience across multiple hypervisors. Rather than worrying about the differences, you can manage your infrastructure holistically.

RHEV for VMware users

As an example, let’s look at some of the similarities and the differences between RHEV and vSphere. At an architectural view RHEV looks very similar to vSphere, but there are some differences under the covers. Let’s start with a component by component comparison:

  • RHEV-M / vCenter: The RHEV manager (RHEV-M) manages a number of hypervisors, and exports a UI and a REST API for managing the cluster. It can be run in a VM or on a physical machine.
  • RHEV-H  / ESXi: RHEV-H is a stripped down distribution of RHEL that runs as a hypervisor (called a “thin” hypervisor). KVM is used as the hypervisor with a management stack (oVirt) placed around it. The distribution is stripped down to only the components needed to run a RHEV hypervisor, and is hardened against attack. It is not customizable, however.
  • RHEL Hypervisor / ESX: You can also use a full RHEL instance as a hypervisor (called a “thick” hypervisor) if you require more customization. In this case you run KVM and the oVirt stack on a standard RHEL machine, but can also install custom packages and services on the machine, at the cost of having to harden the node yourself.
  • Storage domain / Datastore: RHEV stores disk images in storage domains, which serve an equivalent purpose to datastores in vSphere, but are structured differently than datastores are in vSphere.
  • Data center / Data center: RHEV also has the concept of a data center, which as in VMware, contains a collection of storage, VMs and other resources.

High-level Differences

In terms of storage, there are a few key differences between RHEV and vSphere. In vSphere each VM is represented by a configuration file (a vmx file) which then references a number of other files (disks, descriptors, etc.). In general, all the information for a VM is placed in a single directory. VMs can be added or removed from inventory as desired. The same datastore can be mounted across multiple vCenters so long as each individual VM is only in inventory in one vCenter.

RHEV’s storage domains have structure imposed by RHEV itself. Each storage domain is a directory which contains a number of disks (each in their own directory) and then metadata about the domain. Each storage domain can only be mounted on one RHEV-M instance to avoid concurrency problems. In the RHEV world, VMs do not belong to any particular storage domain, but instead belong to a data center. Each disk of a VM is stored in one domain, but it is easy for a VM‘s disks to span storage domains by having disks in various domains.

The Nuts and Bolts

Tintri’s integration with RHEV works very similarly to our integration with VMware. The appliance presents itself as an NFS storage domain, which RHEV can use to create and store data. In addition to the data path, we communicate directly to RHEV-M using the REST interface to associate the storage constructs with VMs and vDisks.

Nuts & Bolts


RHEV and VMware VMs Side by Side

Tintri handles all of these storage differences for you under the cover. When you add a new RHEV VM to a Tintri VMstore, it shows up exactly the same way as a vSphere VM in our UI. You can see performance and capacity statistics, create and manage Tintri space-efficient snapshots, create zero space clones, and configure replication at a VM-level exactly the same way you do for vSphere VMs. The only differences are the host and hypervisor fields, which allow you to see which VMs are hosted on RHEV, and which are hosted on vSphere.

RHEV and VMware VMs Side by Side

By unifying the experience for VMs across disparate hypervisors, Tintri provides a way to mix and match RHEV and VMware as you desire, rather than requiring you to statically assign appliances or volumes to a particular hypervisor up-front. In addition rather than having to relearn storage for different hypervisors, Tintri allows you to manage all your VMs in the same, simple fashion. We are excited for RHEV users to experience the same powerful, simple features that our VMware customers have already enjoyed. Tintri support for RHEV is currently in technology preview and will be generally available in August 2014.

Brandon Salmon / Apr 10, 2014

Brandon Salmon has been working in systems and storage for over twelve years. He has a Ph.D in computer engineering from Carnegie Mellon University and a bachelors in computer science from Stanford...more