How to configure a stand-alone FCI DR instance for auto or manual failover?



  • I have 2 instances configured as FCI (active/passive).

    They share the same SAN. Thus providing high availability.

    For DR, presently we are replicating the SAN into another SAN on remote location. The remote location currently doesn't have sql server installed.

    I'm exploring whether I can add a 3rd instance (on the remote site) that plugs into the remote SAN and is also part of the FCI (along with 2 onprem instances), be default in passive state, such that a disaster on premise should activate the remote instance 3 via automatic or manual failover. Is this doable with sql server? Any link reference to such an implementation guide will be useful.



  • Yes, this can be done.

    See the below mention on this strategy from https://docs.microsoft.com/en-us/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-ver15 , found in the Always on failover cluster instances section under Disaster Recovery.

    FCIs can be used for disaster recovery. As with a normal availability group, the underlying cluster mechanism must also be extended to all locations, which adds complexity. There is an additional consideration for FCIs: the shared storage. The same disks need to be available in the primary and secondary sites, so an external method such as functionality provided by the storage vendor at the hardware layer or using storage Replica in Windows Server, is required to ensure that the disks used by the FCI exist elsewhere.

    It sounds like you have the storage covered already. So, your main concern will be configuring the stretch-cluster properly.

    A few things you'll want to consider.

    1. You'll want to your DR node to be set as a manual failover. You would not want a failover to happen randomly, in the middle of the day. There's going to be other work that needs to happen on the SAN layer during a failover, as the replicated SAN would typically be a read-only copy.
    2. Plan how you'll handle quorum. With 2 nodes in Prod, 1 in DR, that is an odd number. But ideally, you would not want your DR providing a tie-break vote to your Prod cluster. Any issues with your WAN, and your entire cluster will go down. Consider a file share witness in Prod, and remove votes from DR.
    3. Addressing. Your Prod and DR nodes will be on separate subnets. You'll want to make sure you have correct IP resources on the cluster for each subnet, and that clients can access DR when it's the primary.

Log in to reply
 


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2