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...
'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:
And here's the same policy in the new vSphere Client (HTML5)
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
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
'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:
And here's the same policy in the new vSphere Client (HTML5)
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
Thank you both.
we will Test it out with the settings both of you mentioned.
regards