3 Replies Latest reply on May 9, 2019 11:35 AM by Darking

    Exchange DAG on a stretched vsan

    Darking Novice

      Hi.

       

      We are currently migrating to our new vsan stretched cluster.

       

      The question has come up: does it make sense to have both FTT=1 and PFTT=1 on a DAG replicated cluster. Or is pinning each VM in the DAG to a Site (via host pinning) and running FTT=1 but no PFTT "OK"

       

      It Does seem a bit overkill to us to keep so many copies of the data...

        • 1. Re: Exchange DAG on a stretched vsan
          TheBobkin Virtuoso
          VMware EmployeesvExpert

          Hello Darking,

           

           

          "It Does seem a bit overkill to us to keep so many copies of the data..."

          Probably a bit overkill alright and it will probably have better performance as PFTT=0,SFTT=1 as no vSAN data needs to traverse the intersite network.

           

          "Or is pinning each VM in the DAG to a Site (via host pinning) and running FTT=1 but no PFTT "OK""

          While you can of course use DRS affinity/anti-affinity rules (and/or 'pinning' e.g. as used for Kubernetes), you shouldn't need to as you can just configure the VMs on each site with opposing FTT=0,SFTT=1 rules (e.g. one for 'Preferred' and one for 'Non-Preferred).

           

           

          Bob

          1 person found this helpful
          • 2. Re: Exchange DAG on a stretched vsan
            Jasemccarty Champion
            VMware EmployeesvExpert

            'Host Pinning' is a term often used when using the vSAN Host Affinity feature.

             

            Stretched Cluster vSAN (since vSAN 6.6) has allowed for 'Site Affinity' to give you the ability to have data only in one site or the other.


            Consider 2 VM's with a need for one in each site. Say they are using DAG, or some other application replication technology, and you do not want to write to both sites.

            Essentially, data is only needed in one site for each VM because data is replicated at the application layer.

             

            Create a Storage Policy with the following rules (minimum) for the VM to reside in the Preferred Site:

            PFTT=0
            SFTT=1/2/3FTM=Mirroring/Erasure Coding
            Data Locality: Preferred Fault Domain

             

            Here's that policy in the vSphere Web Client:
            PREF-OLD.png
            And here's the same policy in the new vSphere Client (HTML5)
            PREF-NEW.png

             

            Create a Storage Policy with the following rules (minimum) for the VM to reside in the Secondary Site:

            PFTT=0

            SFTT=1/2/3

            FTM=Mirroring/Erasure Coding

            Data Locality: Non-Preferred Fault Domain

             

            You'll also want to use VM/Host Groups/rules with the "Must Run On..." option to make sure that the VM for the Preferred Site only runs on the Preferred and the other only runs on the Non-Preferred site.

             

            Most of this is covered in detail in the vSAN Stretched Cluster Guide: https://vmware.com/go/vsanstretchedclusterguide

             

            I hope this helps.

             

            Jase

            • 3. Re: Exchange DAG on a stretched vsan
              Darking Novice

              Thank you both.

               

              we will Test it out with the settings both of you mentioned.

               

              regards