4 x nodes + SQL server 2017 or above AlwaysON topology and design

as stated here: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver15

The Always On availability groups feature is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring. Introduced in SQL Server 2012 (11.x), Always On availability groups maximizes the availability of a set of user databases for an enterprise.  

however...it is up to you to decide if this is the best option and to help with that you could see:

This session is for DBAs who are considering implementing AlwaysOn AGs, or who are wondering why their AlwaysOn setup is only OftenOn.

See more at: https://www.idera.com/resource-center/webcasts/sqlserver/geeksync/are-alwayson-availability-groups-right-for-you
As far as architecture goes - at high level details can be found here: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/an-overview-of-high-availability-and-disaster-recovery-solutions/ba-p/370479

just want to know ONLY based on the critria that both primary and DR both need HA and primary can failover to DR site, For how many solution we can use, the link do not tell in detial.

This solutoin is a bit different from what I do before ( 3 x nodes in total,. 2 x sync node in primary and 1 x async node in DR site), in terms of node majority, 5 is an odd number, should be for this situation .

so I am not sure if any offical doc , as an example ,. to say in this case, 3 x nodes on primary site in sync mode + 2 x nodes in DR site in async modes is the one to go.

I am also not sure if 1 x FCI 2 x nodes cluster on EACH PRIMARY and DR site can form a 2 x nodes AG across 2 x sites.

this is the only requirement i got:

 ----Prod + HA in prod and DR + HA in DR

so I think 2 x SQL server ,one on each site is not a good option, right?

money is not a concern but I think minimum AG configuratoin forthe requirement above is ok .

2 x FCI, means 2 x nodes and it is not using AlwaysON availability group any more, it is 2 x FCI only.

or you mean 2 x FCIs to form an AlwasyON availiability group ? it has a requirement to separate read and write in real time and load balance the READ and WRITE ,

and we have this requirement

So 2 x FCI , one on each site CAN'T do it?

by this :


When primary site DC failed, the FAILOVER will be automatically even it is in async mode, right?

under what condition it is NOT ?

any update for me ?

What I mean was to either use "Multi-Site Clustering with SAN Replication " from https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/an-overview-of-high-availability-and-disaster-recovery-solutions/ba-p/370479for a 4 nodes / 2 SQL clusters solution OR assuming you're running a higher Enterprise version than SQL 2016 you could setup "distributed availability groups" as detailed here: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups?view=sql-server-ver15 

A distributed availability group is a special type of availability group that spans two separate availability groups. The availability groups that participate in a distributed availability group do not need to be in the same location.

As far as the answer to your question: "When primary site DC failed, the FAILOVER will be automatically even it is in async mode, right? " Microsoft recommendation is the opposite at link posted above:

In a disaster recovery situation where you are switching data centers, you should not configure automatic failover (with rare exceptions).

Hi,

tks.
sorry for late reply as I am focusing on something else:

In a disaster recovery situation where you are switching data centers, you should not configure automatic failover (with rare exceptions).

This means technically I can configure that ?

and if we do not failover automatically fallover then this can be a big big disaster as business can't continue, so why is that?

do not AUTO FALLBACK is good as we don't know what was happened in primary that trigger the failover so we need to 100% sure we know what happened and it is fixed before we fallback .

tks.