Balancing VMDK between 2 SANs with sDRS?

langenoirlangenoir ■□□□□□□□□□ Posts: 79Member ■□□□□□□□□□
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?

Comments

  • dave330idave330i ■■■■■■■■■■ Posts: 2,091Member ■■■■■■■■■■
    You don't need any anti-affinity rules since sDRS boundary is storage cluster.
    2018 Certification Goals: Maybe VMware Sales Cert
    "Simplify, then add lightness" -Colin Chapman
  • langenoirlangenoir ■□□□□□□□□□ Posts: 79Member ■□□□□□□□□□
    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?
  • dave330idave330i ■■■■■■■■■■ Posts: 2,091Member ■■■■■■■■■■
    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.
    2018 Certification Goals: Maybe VMware Sales Cert
    "Simplify, then add lightness" -Colin Chapman
  • tbgree00tbgree00 ■■■■□□□□□□ Posts: 553Member ■■■■□□□□□□
    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.
    I finally started that blog - www.thomgreene.com
  • scott28ttscott28tt ■■■■□□□□□□ Posts: 665Member ■■■■□□□□□□
    Couldn't regular vCenter permissions prevent the undesirable move, by restricting admins who might inadvertently move the VM to somewhere it shouldn't be?
    VCP2 / VCP3 / VCP4 / VCP5 / VCAP4-DCA / VCI / vExpert 2010-2012
    Blog - http://vmwaretraining.blogspot.com
    Twitter - http://twitter.com/vmtraining
    Email - [email protected]
Sign In or Register to comment.