Understanding DRS, HA and vMotion settings

[Pifemi1]

Hello everybody. 

Thank you very much for the help you offer to the community. I have a question about how the DRS works together with the HA.

I have an esxi 8.0 cluster in which there are hosts from two different datacenters. We have created affinity rules so that the VMs that belong to one of the datacenters only run on the hosts of that specific datacenter and so that, in the event of a host in the specific datacenter going down, the VMs are "powered on" only on hosts of the same datacenter . What we want to know is if there is any way that does not require the use of affinity rules to achieve this since, sometimes, after new deployments, we forget to add said VMs to their corresponding rule.

We have thought about configuring the vMotion VLAN differently between the hosts in one datacenter and those in the other. If the hosts in one datacenter have a different vMotion VLAN than the hosts in the other datacenter, the DRS will not try to migrate VMs to the hosts that do not does it have the same VLAN or will it try and show an error? In the event of a host crash in a specific datacenter, does having the vMotion VLAN different between hosts in a different datacenter mean that VMs will only "power on" on the hosts in the datacenter of the host where it was before the crash?

Another idea that has occurred to us is to configure different vDS for the hosts in one datacenter with respect to the hosts in the other datacenter. Does this mean that in the event of a host going down, vSphere detects the hosts that have networks in the same vDS as the VMs that have gone down and "powered on" them only on those?

I know the questions are a bit confusing. I hope that some member of the community is able to solve them. I thank you very much.

Many thanks and greetings!

[Mark Edwards]

 - Why don't you just setup a cluster per site. Each cluster will then act as your DRS boundary, no affinity rules required.

 

This is a pretty standard setup. You would typically also have a vCenter "per site" and configure them to be connected in Enhanced Linked Mode. That way you maintain separation of sites, whilst also retaining the ability to see everything in both sites from either vCenter and vMotion between sites if needed.

 

HTH

[Nathan Savolskis]

First,  , those are good questions to ask, especially when you are exploring different configurations and options. 

 provided the best answer to your first question.  Keeping things straightforward and simplified is extremely helpful.

I would also suggest that you develop a VM blueprint (in vRA or vROPs if you have that) where you can add rules to a configuration profile so that it is not forgotten.  But if you don't have those tools then it's a little more manual (or you can have someone build a script!).

For the other questions, configuring vMotion differently could work, but you may run into some unforseen issues with critical workloads that cannot be vMotioned the way you want to another data center. In that set-up, you'd essentially end up with a vCS at each site and have to manage and deploy workloads very specifically with stict VLAN and rule guides as you build/deploy.  That sounds like more work than it is worth.  But yes, if you have vMotion configured for a specific DC and hosts, then the VM 'should' power on within another host within the cluster in the same DC.  

For the vDS question, kind of a similar answer - but it will depend on how you configure the VLANs and uplinks on the vDS as to how it will behave in that situation. For the most part - unless the vDS goes down, it vCS will follow standard vMotino rules and you'll see results similar to the paragraph above. Again, the vDS option would be a vCS at each DC anyway - and then that agian could introduce some unforseen issues (I would test this config if you can in an isolated VLAN just to see what happens).  After all that, I'd still recommend one of the first two answers (the clulster per DC, or using VM blueprints to standardize how rules are applied to newly deployed workloads. 

Hope this helps.

[Pifemi1]

Good morning.  @markey165 and , thank you both very much for your responses, guys.

The idea of a cluster with servers in a single data center is what I have always followed in all my installations. In this particular case, the installation is inherited and the client is the one who wants to have it that way, so I can say little or nothing there. From there, I tried to find answers to my doubts since the cluster is going to stay like this, with hosts from two different datacenters.

, as I understand from your answer, and although unwanted behavior may occur on occasion, having two different vmotion vlans or the servers of both data centers with different vDS and Uplinks makes vSphere realize this and the DRS never migrates VMs from a host in one datacenter to another host in the other datacenter (because they do not have the same vMotion network) and, furthermore, when vSphere checks that they do not have the same networks, will it not migrate the VMs either? After a host crash, would the same thing happen? Would the HA notice the hosts that have some networks and not others and power on the VMs on the hosts in their corresponding datacenter?

Thank you very much for your help!

Regards!

[Nathan Savolskis]

 , sorry for the delayed response...busy week already.  

To your question - if it is a single vCenter for the overall environment, and HA is enabled for the VMs in question - yes, regardless of the different VLANs, vCS should take note and migrate/re-start VMs if a host has crashed.  The tricky part for you is having (potentially) different vMotion VLANs defined.  Again, if it a single vCS....that set-up won't really get you much more than more headaches. If you have multiple vCS (say at least one at each location) then it could work. I have not tried establishing that infrastructure configuration, so you have my sympathy (and curiosity!) for the situation. 

By chance does the environment include SRM or a newer instance, or a 3rd party storage-recovery solution? Asking as that may be another option to consider.

[Pifemi1]

Good morning,  . 

Thanks for the reply. There is only one vCenter for all this infrastructure.
Since it is a production environment, I will not be able to do many tests, so I will insist to the client that the most
convenient thing to do is to use affinity rules for this peculiar situation. I think that we will create a powercli script and configure a windows task to run every hour to check VM that are not include in any DRS affinity rule and put them inside one of the existing DRS affinity rules following some criteria about the name of the VMs.

I imagine we will create a powercli script and configure a Windows task to run every hour to check for VMs that are not included in any DRS affinity rules and move them (VMs that are not in any DRS affinity rules) within one of these affinity rules, using some criteria such as the name of the VMs.

Thanks a lot for all your help.

Regards!

[Nathan Savolskis]

 , that is a solid approach in this case.  Good luck!

[Duncan Epping]

Just tell the customer they really need to split up the cluster. This really makes no sense. It makes things unnecessarily complex for DRS as it needs to take the rules into account everytime it runs. Then if a failure occurs it also makes things complex for the HA placement logic. And it some point something is doomed to go wrong.