(Thanks to StarWind)
Always On Failover Cluster Instances (FCI) has a very similar goal as AG – deliver High Availability for your SQL Server. The main difference though is that FCI works on a server-instance level. FCI represents a single instance of an SQL Server that is deployed across Failover Cluster nodes. In case of hardware or software issues on the node, the instance is failed over to the other one.
Just as with AG, FCI runs in a Failover Cluster while quorum is
maintained. The difference here is storage. Whereas AG does not need any shared
storage, FCI requires some form of it. This can be cluster disks on an iSCSI or
Fiber Channel SAN, Storage Spaces Direct, StarWind Virtual SAN or
SMB file shares.
In
this case, shared storage allows moving FCI among the nodes in the cluster and
this can be done either manually whenever maintenance on other node is needed
or automatically (in case of an actual failover event). Of course, there is
only a single owner node of SQL Server instance at a time. Correspondingly,
there are no specific replication settings as it was with AG since the failover
is handled by WSFC and there is no data loss.
Benefits of Failover
Cluster Instances
So, what are the
benefits you get with FCI?
·
High Availability at
the SQL Server instance level;
·
Both automatic and
planned failover are available and managed from a Failover Cluster;
·
Flexible shared
storage options like iSCSI or FC SAN, SMB shares etc.;
·
No need to reconfigure
applications and clients associated with SQL Server instance during failovers.
Restrictions of
Failover Cluster Instances
Despite providing a
lot of benefits for SQL Server high Availability, there are certain downsides
to Always On Failover Cluster Instances.
·
No option to read from
secondary databases as with AG since there is a single instance running, hence,
no load balancing;
·
Relying on a single
SAN as shared storage creates a single point of failure;
·
No Disaster Recovery
options unless combined with AG.
No comments:
Post a Comment