Granularity and restore
If you’ve read this far, you may be thinking, “That’s okay, most of the time I want to protect all the VMs in a LUN anyway.” Even when that’s true, you usually have to jump through some hoops to make it work. At a minimum, you’ll have a variety of different LUNs with different performance levels and data protection policies. And if you need to change the data protection for a VM? You’ll have to migrate it to a different LUN.
But you’ll really notice the difference when you do a restore—when you can least afford to waste time or execute a complicated manual process. Suppose you need to recover a VM in short order. With storage based on LUNs, you have two options:
- Restore the entire LUN in place, which is in itself a lengthy process because of the amount of data to be moved.
- Copy the entire LUN to scratch space and then recover what you need, adding time and complexity to the process.
And remember that, either way, moving data out of the cloud can be expensive. Restoring a LUN will cost more than restoring a single VM.
Restoring an entire LUN means unaffected VMs will also be restored to the same point in time. That’s almost never going to be what you want. Restoring the entire LUN to scratch space—assuming enough space exists—and then recovering just the desired VM or VMs quickly—becomes the only viable alternative.
Because Tintri Cloud Connector allows you to recover at VM-level and container granularity, it avoids these complications entirely. Need to restore a VM? You just restore it directly; no fuss, no muss.
Granularity and automation
In the opening, I talked about the increasing importance of automation in IT. As a closing thought, let’s look at the impact of granularity on your ability to automate data protection.
First, think about the task of manually provisioning a VM that needs hourly snapshots and twice daily replication. If you already have a LUN with that schedule, you just make sure that enough space exists in the LUN before provisioning the VM (and hope that the new VM isn’t a “noisy neighbor” for the other VMs in the LUN.) If you don’t have a LUN with those policies, you’ll have to either create one or settle for the LUN that’s the closest match. Now, imagine trying to automate this process. It gets complicated, fast.
In the previous section, I talked about the complex process of restoring an individual VM from a LUN. This too is a process that’s difficult or impossible to automate.
By operating at the right granularity, Tintri Cloud Connector makes cloud data protection much simpler, and as a result, it makes automation much simpler too. During provisioning, you simply have to assign the snapshot and replication schedule you want to the VM or container. Data moves directly from your all-flash storage array to S3 with no middlemen to add complexity. Restore is just a matter of specifying the VM or container to be restored, which version you want, and where to restore it. Because these processes are as simple as they can be, they are extremely easy to automate, which in turn makes them highly amenable to self-service.
Next time we’ll look more closely at efficiency.
By operating at VM and container-level granularity, Tintri Cloud Connector simplifies backup and restore to the cloud, and makes automation of these processes much simpler.
An imperative for almost every IT team is to get more done with the same—or even fewer—resources. That means simplifying your infrastructure and processes and automating as much as possible. Data protection remains a primary concern for many of us—because of its obvious importance—but also because of the complexity of the processes involved, especially when it comes to restores.
When Tintri introduced Cloud Connector, our goal was to create a simple-to-use and easy-to-automate solution for cloud data protection that was also extremely efficient. The first post in this series explained how Cloud Connector eliminates transition points, cutting out the middleman so that data can flow more readily. This post looks at the importance of operating at the right level of granularity to simplify operations and facilitate automation.
The importance of VM and container-level granularity
With traditional storage, the base level of granularity is often the LUN or volume. But as enterprises have moved towards full virtualization, the standard unit of granularity on the server has become the VM or the vDisk. If you perform data protection operations like snapshot and replication on a LUN, you’re operating on tens or hundreds of VMs.
The situation is similar with containers. While there are a variety of ways to manage containers and provide persistent storage for their use, none of these occurs at the LUN-level of abstraction either, creating the same disconnect.
One of the core features of Tintri all-flash arrays is they operate directly at VM-level and container-level granularity and that carries through directly to Cloud Connector. You can snapshot an individual VM and replicate it to S3 independently from other storage objects. You also have the flexibility to group storage objects together and apply the same data protection policies to a set as desired.