Today, I want to talk to you about how to attach application lifecycle policies like glued to your environment. In a given life of a virtual machine, it needs to be protected. It might need replication, maybe even want to perform quality of service, maybe a max performance threshold for that virtual machine. In a traditional environment, we can control that at the storage level, "This LUN or this datastore is replicated," "This one is on slower storage," "This one is on SSD," and so by virtue of moving a virtual machine into that piece of hardware or that section of the environment, it takes on the characteristics of the hardware. In Tintri's world, we are attaching policies directly to the VMs themselves, so assigning replications, snapshots, data protection, quality of service is never really more than a right-click away. You can right-click on a VM and say, "I want to build a grandfather-father-son backup snapshot process policy for this VM." That way, as we move virtual machines from one place to another in the environment, that policy sticks to the VM.

That means you can have multiple Tintris in your environment and say, "My database server is going to have 15-minute snapshots all the time because its production, and we're going to replicate those snapshots to its second site." That means when the pooling mechanism within Tintri takes over and says, "That database server needs to move to a different Tintri," the policy stays the same. The snapshots go with it, statistics go with it, and all the policies governing the lifecycle of that virtual machine go with it as well. It makes for a much, much more flexible environment. You're not locked in and saying, "Only this area can be protected," so it means that the future planning and also, the dynamic nature of how to manage applications and their lifecycles is much easier to support in a Tintri environment.

If you want to learn more about Tintri, contact one of our experts today. 

Upcoming Webinar:
www.palmiq.com/tintri