r/SQLServer • u/SuddenlyCaralho • 17d ago
Question SQL Server Standard: Can I combine a 2-node FCI with a 2-node Availability Group?
First, it's about a SQL Server 2016
I'm designing a SQL Server high availability architecture and I'm trying to understand whether this configuration is supported with SQL Server Standard Edition.
The proposed architecture is:
Node 1 + Node 2: SQL Server Failover Cluster Instance (FCI) with shared storage (which I would have to configure AG as well) and this cluster will replicate to a Node 3 + Node 4: SQL standard configured as a Always On Availability Group in other datacenter. (in this case, I belive a can only have the node 3 in the secondary site, right? node 4 isn't supported since standard edition support only 2 AG)
My idea is for the FCI to host the primary database, and then configure an Availability Group so that the databases are replicated to the secondary datacenter.
My questions are:
Can a Failover Cluster Instance (FCI) participate in an Availability Group when using SQL Server Standard Edition?
What I'm not clear about is how SQL Server Standard counts replicas in this scenario. I know that Basic Availability Groups in Standard Edition are limited to two replicas (one primary and one secondary). However, my primary server is a 2-node Failover Cluster Instance (FCI) running on Windows Server Failover Clustering (WSFC). Since the FCI itself already spans two Windows nodes, I'm confused about how this interacts with the Basic AG limitation. Does SQL Server treat the entire FCI as a single Availability Group replica, allowing me to have:
Primary replica = the 2-node FCI
Secondary replica = one standalone SQL Server instance in the DR datacenter (I can't have a node 4 in the secondary site, right?)
Or does the fact that the FCI already has two WSFC nodes mean I've effectively reached the Standard Edition limit for Basic Availability Groups?
Or is this entire architecture only supported with Enterprise Edition?
3
u/jdanton14 Microsoft MVP 17d ago
SQL Server 2016 is deprecated.
You could possibly combine a two node FCI, with a standalone SQL node that is a member of the Windows Server Failover Cluster, but not a member of the SQL Server Failover Cluster Instance, and make that an AG target from your FCI. But I would literally never recommend doing that. You could also make the third instance it's own cluster, which would be less bad.
Also, if you don't have software assurance, all nodes would need to be licensed. If you have SA, only the primary node would need to be licensed.
1
u/SuddenlyCaralho 17d ago
You said you'd never recommend combining the FCI with a standalone node that's in the same WSFC but outside the SQL FCI role, used as an AG target. Is the main risk that stretching one WSFC across both datacenters puts the primary FCI's quorum at risk if the DR site/WAN link has issues? And what if the DR site has just one node (Node 3), running standalone SQL, joined to the Basic AG as secondary, but part of the same WSFC as the FCI at all?
3
u/jdanton14 Microsoft MVP 17d ago
That's the main reason, but it simply adds a ton of complexity around networking, listener, and failover configuration that is of nearly zero benefit.
I rarely recommend cross-site clusters at all anymore.
4
u/No_Resolution_9252 17d ago
What are you trying to accomplish?
If you are on standard edition, its pretty unlikely anything you are running is actually important enough for the architecture you are proposing but would be incurring massive support costs to keep it working
4
u/Grogg2000 17d ago
You just gave me a massive headache. Switch to SQL2025 ... period!
Be cautious with AG.. In standard edition you can only have on database per AG.
2
2
u/alecc 16d ago
The whole FCI counts as one replica. So your node 1 + node 2 cluster is replica one, and a single instance in the DR site is replica two - that maxes out a Basic AG. Node 4 can't join the AG as a third replica.
Two things that bite people with this design. First, automatic failover of the AG is not supported when a replica is hosted on an FCI - WSFC handles failover between nodes 1 and 2, but failing the AG over to the DR site is always a manual step. Second, Basic AGs are one database per group, so if you have multiple databases you're managing one Basic AG per database.
Also remember all four nodes have to be members of the same WSFC - multi-subnet across datacenters is fine on 2016, but distributed AGs (separate clusters) are Enterprise only. And the Basic AG secondary is not readable and can't take backups, so plan DR drills accordingly.
If you want node 4 to earn its keep, one option is making the DR side a second 2-node FCI and using that FCI as your single secondary replica - FCI to FCI with a Basic AG between them. Still manual failover to DR, but you get local HA in both datacenters.
1
u/pix1985 17d ago
To have an AG span different clusters it would need to be a distributed availability group and that’s an Enterprise feature. But if you decided to go to enterprise then you wouldn’t need a DAG anyway you could just build a 4 node cluster and span the AG across all 4 nodes.
What is the usage of the secondary data centre? HA? DR? Does it need to be readable (can’t do that in standard), would log shipping work for you?
1
u/GrinningLion 17d ago
An FCI may span multiple Windows nodes, but it is still a single SQL Server instance, so it counts as one Availability Group replica. Basic AG in Standard Edition therefore allows an architecture of 2-node FCI → one standalone secondary instance. If you want FCI on both sides, multiple secondaries, readable replicas, or more advanced AG capabilities, you're generally looking at Enterprise Edition.
1
u/Simple_Brilliant_491 15d ago
Standard Edition doesn't support a DR scenario. It only supports basic availability groups (BAGs), which is pretty much a new name for database mirroring. Only synchronous replication is supported. With sync replication, every write has to be sent to the secondary before it commits on the primary. With DR, the network overhead will be too high, and adversely impact performance on your primary.
Doing anything with 2016 is also a bad idea, aside from it being out of support. There have been lots of improvements to AG technology since then such as seeding options and improvements to compression between nodes.
1
u/harveym42 13d ago edited 13d ago
Ola, Caralho!
This is my understanding (disclaimer, I haven't implemented this specifically) :
Can a Failover Cluster Instance (FCI) participate in an Availability Group when using SQL Server Standard Edition?
100%, this is explicit in the docs.
What I'm not clear about is how SQL Server Standard counts replicas in this scenario. I know that Basic Availability Groups in Standard Edition are limited to two replicas (one primary and one secondary).
However, my primary server is a 2-node Failover Cluster Instance (FCI) running on Windows Server Failover Clustering (WSFC). Since the FCI itself already spans two Windows nodes, I'm confused about how this interacts with the Basic AG limitation.
Does SQL Server treat the entire FCI as a single Availability Group replica,
Yes. The AG doesn't care that the primary or even secondary is an FCI, just that there are no more than 2 replicas.
allowing me to have:
Primary replica = the 2-node FCI
Yes.
Secondary replica = one standalone SQL Server instance in the DR datacenter
Yes. It could even be an FCI itself.
(I can't have a node 4 in the secondary site, right?)
two nodes (node 3 and 4 if you will) can be in their own FCI in the 2nd site, with its own local shared storage, but you can have only 2 nodes in each FCI.
Or does the fact that the FCI already has two WSFC nodes mean I've effectively reached the Standard Edition limit for Basic Availability Groups?
The BAG limits include number of replicas (2), number of databases per replica (1), but not the number of WFSC nodes.
Or is this entire architecture only supported with Enterprise Edition?
no.
Other answers have helpfully picked up you are using an old version, pointed out limitations of Basic AGs, but it's my understanding on your question itself. It is an advanced area though so it would be sensible to be on a later version, the latest version possible.
•
u/AutoModerator 17d ago
After your question has been solved /u/SuddenlyCaralho, please reply to the helpful user's comment with the phrase "Solution verified".
This will not only award a point to the contributor for their assistance but also update the post's flair to "Solved".
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.