What would you think is the best solution to look at given these factors?
AlwaysON is designed to meet business uptime and availability wherein you can afford minimal data loss and downtime. It requires proper planning and implementation.
As per your question, it seems that the databases are not that business critical (business have no problem accepting the nightly backup as restore point).
Based on the information that you provided, your business will be able to survive with Log Shipping as a DR solution.
The benefit is that you dont have to worry about windows cluster and other complexities associated with AlwaysON like DNS, Windows failover cluster, etc. Check the prereq and requirements.
Logshipping is well tested and is the most mature of all the DR technologies that you get from SQL Server. You can adjust the frequency of Transaction log backup,copy and restore as per your needs.
Note: This part of the answer corrects the misconception about Log Shipping not being compatible with Failover Clustering.
As @sp_BlitzErik implies in the comments, Log Shipping is very much compatible with Failover Clustering. I've seen others fall prey to this implied lack of interoperability as it seems the MSDN article you link to is a direct reference of this MS Blog post from 2013. It seems even @Shanky commented about this discrepancy directly on that article as well.
Long story short, that article is incomplete. It should also reference Failover Clustering under Log Shipping along with a handful of other DR technologies.
Final note on using log shipping with Failover Clusters; the main caveat is to ensure your TLogs are being backed up to a clustered share that can failover along with the instance and other clustered services.
Answer: Now to address the rest of the answer.
You've got a few options. Really what you're able to do is often limited by your budget (e.g. licensing, hardware, etc.), so any option proposed will need to fall within your budgetary constraints. That being said, here some options I can think of, but by no means do I consider this a complete list of your available options:
- Log Shipping: For the sake of completeness, you CAN configure log shipping on a failover cluster. As I say above, be sure to configure the backup location as a shared folder that fails over along with the other clustered resources (e.g. SQL Server Service, SQL Agent, etc.).
- Multi-Subnet Failover Cluster: This is adding onto what it sounds like you already have, but you can include a different site into your failover cluster. Proper care will need to be taken so that automatic failover to your DR site is only done when necessary. Additional constraints are replicating the data to the DR site. Configuration of this approach is not simple and will depend a great deal on your Windows Version(s), SQL Server version, budget, etc.
- SAN-to-SAN Replication: This is generally a hardware based approach and will depend upon your SAN vendor. Most Enterprise-level SAN solutions support SAN-to-SAN replication and in conjunction with virtualization/etc. you can run across some elegant and expedient DR solutions.
Disaster Recovery is a complex topic and providing anything resembling a complete answer can't be provided on any forum answer. If you're new to this or feel overwhelmed, I heavily suggest reaching out to MS, a MS Partner, a Consulting Firm/Consultant, etc. and ask for help.
Best Answer
Did you read The link you shared in the question, BTW I cannot see the diagram you posted in the question when I referred the link. I will quote from the same link.
So the concept here is the two machines are using 2 different disk which is made as one disk and presented to FCI as single storage via Storage Direct Spaces technology.. Azure does not have concept of shared storage so you need some tool to present disks as shared storage to FCI. What it does is