Failover Cluster - Best way to do it? Any Improvements

[titch]

Hi All

 

We currently have a decent 3 host cluster connected to a San. In another building, we have a very old single server with local storage which is getting served replicators via Veam. When we shut down the decent cluster we need to "fire up" the replicas on the old replica server. I'm looking to make this sleeker a process by upgrading the replica server with 2 refurbished in a new cluster using local storage spaces. I know the world has moved on since this was originally set up and would like the replica server to play more of a role but I'm not sure if this is possible.

 

What I'm basically looking for is some kind of:

 

Constant Mirroring of Cluster 1 to the new Cluster 2 and Vis a Visa

The ability for Cluster 2 to be housing some of the live VMs and take some of the strain from Cluster 1

Ability to failover "instantly" from each cluster to the other should one die

 

So really in essence for cluster 2 to be "part of" cluster 1 but be located somewhere different with a different storage setup. We have a decent backbone to make this viable I just don't know if anything can work in that way currently.

 

Thanks in advance and open to any different ideas

[Primus]

Do you mean a stretch cluster such as this: https://docs.microsoft.com/en-us/windows-server/storage/storage-replica/stretch-cluster-replication-using-shared-storage ?

[titch]

That is exactly what I mean. Thanks.

 

Do you think this can be installed on the new cluster without have to rebuild the original cluster? I wouldn't want to start again! Also from the notes I can't figure out of the storage needs to be identical for both clusters or just be the same partition size and block size?

 

Does anyone use a stretch clutch? Anything I should look out for?

[Primus]

I think you will be able to use the existing cluster and add to it.

 

The MS page says:

• You must create two volumes on each enclosure: one for data and one for logs.
  
• Log and data disks must be initialized as GPT, not MBR.
  
• The two data volumes must be of identical size.
  
• The two log volumes should be of identical size.
  
• All replicated data disks must have the same sector sizes.
  
• All log disks must have the same sector sizes.
  
• The log volumes should use flash-based storage and high performance resiliency settings. Microsoft recommends that the log storage be as faster than the data storage. Log volumes must never be used for other workloads.
  
• The data disks can use HDD, SSD, or a tiered combination and can use either mirrored or parity spaces or RAID 1 or 10, or RAID 5 or RAID 50.
  
• The log volume must be at least 9GB by default and can to be larger or smaller based on log requirements.
  
• The volumes must be formatted with NTFS or ReFS.
  

[dmj]

I would approach this by decoupling the storage and the servers: using Ceph setup a CRUSH map so that older system is a failure domain of the first then have the 'servers' run as pods in a kubernetes cluster serving the SMB.

The only slightly tricky thing about this setup is that you'll probably want to use the new gateway api instead of an ingress controller to serve the smb. We had a similar setup at my previous job serving 25,000 users at a university - it was based on ZFS but with the smb servers as vm's. The general principal is the same though.