Just Another IT Blog

It's time to share some of my experiences, crazy ideas, tips and tricks !!!

Post Page Advertisement [Top]


vSphere Metrocluster or as sometimes knows as Stretched Cluster is a vSphere architecture design that decreases recovery time when disaster/downtime avoidance is a key requirement.
It’s based on the concept that you have your computer resources split between sites and some storage replication between them (to keep the data up-to-date).
To avoid some extra network and storage traffic over the link between the sites, VMware recommends the creation of some site affinity rules, defining a preferably site for each VM, that way the VM will be running just within the hosts of it’s preferable site, exception are made during disasters, on these cases the VMs will be restarted on any available host, no matter what site it’s in.

When you have VM’s creation control, you create the VM you choose what’s preferable site and assign it to the affinity group, so far so good.

Now with the dissemination of cloud environments, automation and self service, the virtualization team does not have the VM’s creation control anymore, they are being created anytime by several people/departments or even other organizations .

Let’s through vCloud Director into the Mix, DRS affinity groups is something vCenter related, your clients are creating VM’s through vCloud Portal, which abstracts vCenter concepts and details, they don’t even have access to vCenter, so vCloud is not aware of vCenter DRS affinity groups !!!!

How do you keep your Metrocluster environment running as it was designed to be ?

VMware’s answer for integrations between applications that do not, natively, communicate with each other is vCenter Orchestrator.
If you don’t know about it yet, VMware has a good Orchestrator’s blog, check it out!!

The idea behind this solution is that VM’s creation from vCloud can be intercepted analyzed and assigned to DRS affinity groups automatically,

Might a diagram helps to understand better how it works



1.     Through vCloud Portal, the client provisions a new vApp/VM;
2.     vCloud Director requests the VM’s provisioning to VMware vCenter;
3.     vCloud Director publishes the new VM information to the messaging queue;
4.     vCenter Orchestrator consumes the message;
5.     vCenter Orchestrator identify the VM and choose which group it should belongs to;
6.     vCenter Orchestrator sends a requisition to vCenter to change the DRS affinity group membership;
7.     vCenter add the new VM to the defined affinity group.


WOW how cool is that ?!?

On the next posts I will show you the details about how to implement a solution like that:


Stay tuned.



Bottom Ad [Post Page]