Zerto: Or What I Learned at Tech Field Day #6!

The last day of Tech Field Day #6 myself and all the other delegates were lucky enough to get a sneak peek at stealth startup ‘Zerto‘. We weren’t allowed to talk about it until the 22nd and I know I am a little slow on the punch but I currently haven’t seen a lot of coverage. Just for an initial disclosure statement my trip to Tech Field Day 6 was paid for by the vendors we visited, however, I am in no way obligated to write about them or publicize them in any manner.

Zerto is an Israeli and US based company founded by Ziv and Odem Kedem. They are doing very interesting things in the BC/DR space for the enterprise and cloud sector regarding Virtualization. They promise host based storage agnostic replication and complete vCenter integration. Also a nice feature VM and VMDK consistency grouping, meaning it is built for vSphere environments and replicates on a VM/VMDK level. When I did a little pressing to see how it is done it was discovered that it doesn’t use vStorage APIs at all but it uses a vApp per host and a driver loaded directly into the hypervisor. That would mean it goes much deeper than Changed Block Tracking to determine incremental changes but it actually looks at the data coming thru the vSCSI stack.

It works similar to a lot of current enterprise replication products where in that it splits the IO as reads and writes are coming thru, however, instead of putting it into Array Cache it puts it into memory since it is working directly in the Hypervisor. To credit @gabvirtualworld he mentioned that it uses the VMware IOVP API to complete this task in his post that goes a bit deeper.

Zerto boasts application protection policies and built in support for VSS to attain better application consistency on the other side. This would be useful for example with Virtualized Exchange environments and running databases. The feature I really like is RDM replication to VMDK or the other way around. This would be really useful if you were moving datacenters and wanted to change some things around in your storage configuration during the initial replication stage. What I also like a lot is the ability to create checkpoints/bookmarks on your replicated VMs from different points in time just in case you had a replication of a corrupted VM or data inconsistency that you needed to go back in time to resolve (This is similar to the Recoverpoint technology). See the video below for a quick explanation of their product:

Being kind of an old school FC Network guy and a big user of array specific replication products like SRDF and Recover point (the founders of the company actually created the Recover Point Technology and sold it to EMC) I am still very curious to see the speed and resilliency of the replication. For instance would the built in compression and WAN optimization be enough for a massive 100TB+ environment and how would it handle the initial synchronization?

Would a product such as Riverbed Steelhead or any other WAN optimization products be able to increase the replication efficiency? It would be very interesting over time to see what third party partnerships and certifications they develop to better the usability and maturity of their product.

Multi-Hypervisor Management and the Future

In a previous post, vCenter Integration Mantra, I made the point that vSphere vAdmins wants the 3rd party modules to integrate into the vCenter client and show their delicious addon-value there, and not in their own management interface. Give the vAdmins the info they need, where they do most, if not all their work. Open up the admin client and let us get all that juicy and fruity information we need. Sounds good, right?

Yes, it does. It sounds really good, but there is this one small curve-ball that can change everything. The 500 pound gorilla in the room that no-one wants to talk about, but we all know is there. As a day-to-day VMware vSphere admin it’s really easy to get our blinders on and not see the forest for all the trees.

During Embotics presentation at Tech Field Day #6 in Boston, it dawned on me:

We might just be approaching this entirely the wrong way around.

This epiphany was caused by one single statement from Embotics: “Our plan is to be hypervisor agnostic, and support other architectures in future versions”.

Multi-hypervisor support? Provisioning VMs regardless of hypervisor, just create what the business or application owner needs, on the performance and storage tier that suits that particular usage pattern best. Of course, this very much ties into the whole cloud mindset, and as a concept of management it is really interesting.

Consider the following scenario:

Your enterprise has a high-performance VMware vSphere environment where mission-critical applications run. All the bells and whistles are available in this environment; HA/DRS, High Performance SAN, 10GigE networking and loads of CPU and RAM.
For a given set of workloads available in the service catalog, the default would be to create new mission-critical workloads in this environment. Of course, chargeback mechanisms would also come into play, and price workloads in this environment at a premium level.
For the sake of simplicity we’ll call this tier “Tier 1”

“Tier 2” would be your test/development and QA environment where you probably won’t need the performance and high availability you get in “Tier 1”, and the chargeback mechanisms would reflect this in the cost model. This environment runs Hyper-V, has cheaper storage and simpler networking.

“Tier 3” is your hosted environment, available outside of your own datacenters. Some workloads belong here too, and of course, chargeback would come into play here as well. To further complicate things, the provider uses Xen for their environment.

If 3rd party applications where to tie into the administration tools for those three separate hypervisors, administrators would have to use three different tools to manage their environment.

What if we turn everything on its head, and look at it from the exact opposite direction. Why should 3rd party vendors have to tie into the hypervisors management tools? They wouldn’t have to if the hypervisor vendors made their admin tools available in a manner that let 3rd party vendors integrate their management tool into theirs instead?

Solarwinds does something really interesting in their Virtualization Manager product, the statistics and status reports you get in your Solarwinds Virtualization Manager dashboard are all available as web “widgets” that you can include in other web pages. In other words, you can integrate Solarwinds Virtualization Manager data into your existing dashboards.

What if you could do the same with output from future VMware vSphere, Hyper-V and Citrix XenServer management products? VKernel could do the same for their data, and you could easily create your own dashboard that contained information from a wealth of sources.

Of course, there are a number of issues with doing something like this, like “what happens if you want to move something from Tier 2 to Tier 1, and the VMs run on different hypervisors?”, “How do you enforce security between hypervisors with different management systems?” and so on.

This is not something that can be very easily done today, and it might even be a pipe-dream, but it’s an intriguing thought. I do think we will see more and more multi-hypervisor environments in the years to come, and getting into the market for management of such environments seems like a good business opportunity (Note: IANAA = I Am Not An Analyst).

Of course, this is an overly simplified scenario, but it does show that the need for management tools to be hypervisor agnostic is very much present, and will be even more so in the future.

We as vAdmins need to apply pressure on our hypervisor vendors to try and make them open up their management tools in such a way that this could be possible someday, the multi-hypervisor world is already here and it’s growing.

I wrote this post while on the plane returning from Tech Field Day #6 in Boston. Greg Ferro has replied to my original post with a post of his own vCenter Integration Mantra – vEverything Is Not Wise where he pretty much says the same as I do in this post.

Tom Howarth also commented on the original post. In fact, I even voiced this opinion in the session we had with Embotics, when the Tech Field Day delegates had a roundtable discussion after the presentations.

It all goes to show that you can in fact get blinded by the light.

vCenter Integration Mantra

During Tech Field Day #6 in Boston one particular general feature request has become increasingly prominent;

Can we have it inside the vCenter client?

In short, what we want is for all those great third party vendors like VKernel, Solarwinds and others to be able to put their feature addons directly into the vCenter client. Currently most third party apps “integrate” by offering a new tab where you can access it, but I would love to see that being expanded even further.

As a concrete example, I would love to see for instance VKernel identify performance problems for a VM and then tell me, inside the summary tab for that VM that there is a problem. Show it to me where I do my work, which is in vCenter, and mostly on the summary screen. Dashboards are great, but we’re all suffering from dashboarditis, and the more disparate dashboards and tabs we get to have relations with, the less we’re actually able to use them properly.

Also, raise a vCenter alert to leverage my existing alerting scheme to get my attention. If a 3rd party plugin sees that something is wrong, tell me through the existing infrastructure I already have in place. No need to reinvent the wheel each and every time, from each and every vendor.

Couple that with my back-end user authentication (eg. Active Directory) for sign-on into your solution, and we’re getting much closer to the “single pane of glass” nirvana scenario we’re all craving.

From what I gather the vCenter client (I am in no way, shape or form a developer), doesn’t allow this level of integration on the VM summary screen right now but VMware needs to make it possible in the future.

We admins want this, and we need it, and frankly, I think we deserve it (and so does the 3rd party vendors contributing to this ecosystem).


Read Multi-Hypervisor Management and the Future for an updated and more forward thinking post on the same subject matter.