Balancing VMDK between 2 SANs with sDRS?

langenoir

Let’s say that you have two SANs with three datastores each.

--SAN1---|---SAN2--

---

|

---

--1DS1---|---2DS1--
--1DS2---|---2DS2--
--1DS3---|---2DS3--

Now let’s say that you have 4 VMs that you want that you want to make sure stay on separate SAN in case one of the physical SANs goes down you still have a VM up. VM1 and VM3 will stay on SAN1 while VM2 and VM4 will stay on SAN2.


I would like to set SAN1 datastores as a cluster and SAN2 datastores as a cluster. Then keep VM1 and VM3 on any of the three SAN1 datastores with VM2 and VM4 on any of the three SAN2 datastores and an anti-affinity rule keeping VM1 & VM3 from being on the same SAN as VM2 and VM4. The problem that I run into is that if I set the cluster by SAN, I can only balance VMs between the datastores on that SAN.

If I set up clusters across say for 1DS1 and 2DS1, then I’ll get the anti-affinity I need, but I’ll lose the load balancing between the other datastores I need.

Is there a way to achieve what I’m trying to do with sDRS or will I have to pick one or the other?

dave330i

You don't need any anti-affinity rules since sDRS boundary is storage cluster.

langenoir

dave330i wrote: »

You don't need any anti-affinity rules since sDRS boundary is storage cluster.

But if I set up a cluster for SAN1 and SAN2, a person could still migrate a VMDK to a cluster I don't want it on right?

dave330i

langenoir wrote: »

But if I set up a cluster for SAN1 and SAN2, a person could still migrate a VMDK to a cluster I don't want it on right?

You can't create sDRS rules against an object that doesn't exist in the sDRS cluster.

tbgree00

langenoir wrote: »

But if I set up a cluster for SAN1 and SAN2, a person could still migrate a VMDK to a cluster I don't want it on right?

If I understand you correctly yes, someone could migrate VM1 to SAN2. As Dave said you can't create affinity rules outside of the datastore cluster. If you were extremely concerned you could make one cluster with all six datastores and create your rules in that mega cluster. That is assuming SAN1 and SAN2 are the same general performance level and technology (VMFS, NFS, etc). I wouldn't mix performance tiers or storage protocols. I've had bad juju with that in the past.

You could use storage profiles to tag SAN1 datastores and SAN2 datastores, then assign the profile to VMs 1 and 3. It wouldn't prevent a Storage vMotion but would give some red warnings and show that you're not in compliance in the VM summary.

scott28tt

Couldn't regular vCenter permissions prevent the undesirable move, by restricting admins who might inadvertently move the VM to somewhere it shouldn't be?