You probably do not understand how AlwaysOn replication works. To understand it better, let me give you how our AX Disaster Recovery setup looks like for Production.
Each server participating in our Production environment has 2 active nodes for each roles. That means 6 AX AOS service (2x User, 2x Batch+SSRS, 2x Integrations), 2x SSRS, 2x SSIS, etc. Each server is active, but the pairs are sitting at a different geolocation (couple of miles apart), and are connected by 2 independent 10 gig lines leased from different ISPs running on separate physical network paths essentially creating a LAN between the two datacenters. If one datacenter is gone, it would still allow the business to run without interruption, since the other site is still actively used, and the users/services would be redirected to the other instance when they reopen the clients / rerun the API/AIF requests etc. by the load balancer logic. You just essentially have half the resources available at that time.
This is a great DR planning, because you do not have hardware just sitting there doing nothing. It is fully put to use, your money is not wasted, and you can be sure that in case of a disaster you will not be left with your pants down by having the "idling hardware" not coming up - you are already using it!
Now for the SQL Server installation we have a 4-node AlwaysOn High Availability cluster, with the following roles:
- Primary SQL (synchronous commit, automatic failover) - datacenter 1 rack 1
- Secondary SQL (synchronous commit, automatic failover) - datacenter 1 rack 2
- Secondary SQL (asynchronous commit, manual failover) - datacenter 2 rack 1
- Secondary SQL (asynchronous commit, manual failover) - datacenter 2 rack 2
When you point your AX AOS against SQL, it would just go against a single AlwaysOn Listener, and SQL will take care for you with routing the request to the correct active, Primary role with update intention, and if you explicitly define ReadOnly intent, then it will go against your secondary with the weighting on how you set up which one is to be serving read requests.
Now with the synchronous commit, data is guaranteed to be the same between the two servers, so if the primary node blows up, it the secondary synchronous node takes over the role of being the Primary transparently without any user interaction in the background, during which SQL would roll back the currently running TTS transactions initiated by AX, and resume execution without other business interruptions on your 1st tier DR platform. Your users would be getting an error who are in the middle of a posting for example, but then they could retry without even closing AX.
If both the primary and secondary synchronous nodes are gone like there is a blackout in the datacenter, then it is a manual failover scenario that comes with a business decision. Is your IT going to try to recover the site, or you would need to manually fail over and set one of the asynchronous nodes as Primary instance, then start your business back online. The risk with that is that asynch nodes are slightly behind depending on your hardware and network setup, so you might lose a couple of transactions. This scenario is not likely to happen though, since this is a 2nd tier DR platform for extra assurance.
Then the 3rd tier of assurance is weekly full, daily differential, and every 15 minute transaction log backups saved to multiple onsite and offsite locations.
Depending on your budget, IT staff skills, and business requirements of complexity I can recommend such setup.
