雲端運算平台和基礎結構,可透過 Microsoft 管理的資料中心全球網路來建置、部署和管理應用程式與服務。
Hi D100 PYShen,
Your planned architecture with two Azure VMs with SQL Server Enterprise, Windows Server Failover Cluster, SQL Server Always on Availability Groups, and an Internal Load Balancer is fully supported and feasible in Azure for a high availability SQL Server solution.
- Required IP Addresses and DNS Configuration (ILB and AG Listener):
- You will need at least:
- One static internal IP address for the Azure ILB this is assigned to the ILB and is later used by the AG listener.
- One DNS name (listener name) for the AG listener, which clients will use to connect.
- Each VM also retains its own private IP.
- The AG listener is created as part of your SQL configuration, and during its creation, you reference the ILB’s IP address.
- Register the AG listener DNS record with the domain’s DNS. This typically resolves to the ILB’s internal IP for application connectivity.
- If using multi-subnet clusters, ILB configuration becomes more complex—see Microsoft Docs for multi-subnet prerequisites.
- One DNS name (listener name) for the AG listener, which clients will use to connect.
- One static internal IP address for the Azure ILB this is assigned to the ILB and is later used by the AG listener.
- ILB Probe Port and Health Check Configuration:
A probe port must be configured on the ILB to direct SQL client traffic to the correct AG replica. This is a TCP port (often 59999 or similar) that the ILB uses to check the health of the AG listener and associated SQL Server instance.
This port must be allowed in the Windows firewall on both VMs, and you must configure a matching probe in the ILB properties.
Example: Set the probe port (e.g., 59999), then on each SQL VM, set up a corresponding probe listener (using PowerShell or scripts as described in Azure guidance). - File Share Witness or Cloud Witness for WSFC Quorum:
- A quorum witness is required for a two-node failover cluster to prevent split-brain scenarios.
- On Azure, the two main choices are:
- Cloud Witness (Azure Storage Account): Generally recommended for Azure deployments. It’s easy, cost-effective, and does not require another VM or file server.
- File Share Witness: Can be used, but requires a reliable file share in the same region/VNet or on-premises via VPN.
- Microsoft recommends Cloud Witness for simplicity and reliability in cloud environments.
- Cloud Witness (Azure Storage Account): Generally recommended for Azure deployments. It’s easy, cost-effective, and does not require another VM or file server.
https://www.datasoluzioni.com/post/sql-always-on-en
- Key Limitations, Caveats, and Best Practices in Azure:
- Availability Sets or Zones: Place both VMs in the same Azure Availability Set (for update/fault domain isolation) or, for higher resiliency, in different Availability Zones (with a minor increase in latency). Availability Sets are easier for two-VMs/same-region; Zones provide higher SLA.
- Supported SQL Versions: Only SQL Server Enterprise Edition (or SQL Server Standard for Basic AGs—1 DB, limited options) supports Always On AGs.
- Networking: Ensure all required internal ports (SQL, cluster, probe, etc.) are open between nodes.
- Full Recovery Model: Databases must use the FULL recovery model with recent full backups before being added to the AG.
- No public exposure: Use an Internal (not external) Load Balancer for production security.
- Automation and Scripting: Use ARM templates, PowerShell, or Azure CLI where possible to record configuration.
- Licensing: Ensure you have Azure Hybrid Use Benefit or correct SQL Server licensing for cost efficiency.
- Testing: Regularly validate failover, listener connectivity, backup/restore processes, and quorum behavior.
- Monitor for Latency: If using Availability Zones, test under your workload as higher latency can impact synchronous commit performance.
- Backups: Implement routine and regular backups; Azure Backup can integrate with SQL Server VMs.
Please Upvote and Accept Answer on it, so that it will be benefit to others in the community.