High Availability Installation on Microsoft Azure with SQL Server 2012

Overview:

Microsoft Azure is one of the most trending architecture/solution for Cloud Computing. Due to ease of implementation, it is attracting a good number of Customers to migrate or implement their enterprise application. Maintenance is facilitated by many providers and unexpected downtime are very minimum.

High Availability Solutions: Although there blogs and documents available on SCN & MSDN for achieving/implementing High Availability Systems but I still want to provide clarity regarding, working of Fail-Over in Azure, SQL Server Always On, Disk Sharing restrictions, Resource Mappings etc

SQL Server Always On: Microsoft has introduced a novel feature “Always On” which replaces the regular clustering solution and instead after its configuration you will have one or more than one live copy of database which remains in sync with the original database node or Primary Node.

Hardware: To build High Availability Solution with Microsoft Azure Cloud & SQL Server Always On functionality you will require four (4) VMs.

This minimum (4 VM) requirement is due to the below restrictions:

• Microsoft Azure doesn’t support Shared Disk Methodology for SAP Application Installation Clustering and without share disk you can’t install HA SAP Application

       There are 2 options available creating/configuring Shared Disk:

• Use third Party Solution (SIOS Datakeeper)
• Express Route for remote iSCSI Target shared block storage.
• Internal mechanism used in Microsoft Azure for failover which is ILB (Internal Load Balancer), it can support only one application at a time for failover in cluster and hence we cannot install SAP Application & Database both in same Cluster Group/Nodes/VMs.
• Along with above restrictions Azure doesn’t support Multiple Virtual IP Addresses.

With Microsoft Azure you can use two types of disks:

• Standard Storage/ Disks: These are regular disks as used in normal VMs. These can be used if we are going to install additional dialog instances on Azure because that will require very small size of disk.
• Premium Storage/Disks: These are high performance storage/disks and should be used for at least Central Application & Database. Below is table with detail of type/model of premium disks available in Microsoft Azure Cloud:

P10 disk provides good output/performance (better than regular SCSI) but for better or best performance we choose P20 or P30. Based on their IOPS and disk size these disks can be further sliced into smaller partitions but it is not recommended to perform too much slicing or partitions as it will impact their IOPS accordingly.

You can refer SAP Note 1928533 for further reference about the SAP Components compatibility on Azure and the type of hardware available.

Do's & Don't:

1. Always check Microsoft Windows Image to be used if going for high availability solution. (DO)
2. Configure Probe port with ILB IP Address for SAP Share prior to installing Additional Cluster Instance on Node B. (DO)
3. Configure Probe port with ILB IP Address for Database Nodes only when starting Availability Group and Listener configuration for SQL Server Always On. (DO)
4. Create entry for SAP ASCS (Cluster Name) and ILB IP Address in host file of all application and database hosts. (DO)
5. Disable Windows Firewall & IE Enhanced Security Configuration. (DO)
6. Ensure that <SIDADM> user is added to domain user group. (DO)
7. Always use non sidadm Administrator user for installation. (DO)

Below are the steps which I followed for doing SAP Netweaver 7.4 installation as HA with MS SQL 2012 database and used third party SIOS Tool for share disk mechanism.

Installation:

1. Distributed or High Availability Solution always is domain installation so either use Administartor user which is part of Domain Administrator or get <domain>\<sidadm> & <domain>\<SAPServiceSID> created in advance.
2. Install SIOS tool on both SAP Application Nodes and configure disks for synchronizing sync.
3. Maintain Registry Entries (Timeout).
4. Check if you are able to failover shared disk access between application nodes for SAP ASCS.
5. Install SAP First Cluster Node on Node A.
6. Install SAP Additional Cluster Node on Node B.
7. Install SQL Server 2012 with latest service packs on both Database node.
8. Ensure Collation is set to SQL_Latin1_General_CP850_BIN2.
9. Create Data & Log directories prior to installation of SAP Database on Database Node A.
10. Check if //<SAPASCS>/sapmnt path is accessible from database nodes.
11. Start SAP Database installation on Database Node A.
12. Initiate full database backup from Database Node A and transfer it to Database Node B.
13. Restore database backup of Node A to Node B with option “Restore with NoRecovery”.
14. Check Security Settings for SQL Server Always On Group.
15. Enable AlwaysOn Availablity Group for SQL Server Service Properties in SQL Server Configuration Manager. (Perform this step on both database nodes.)
16. Change Logon for SQL Server Service in SQL Server Configuration Manager to <Domain>\<SIDADM> user. (Perform this step on both database nodes.)
17. Create & Configure New SQL Server Availability Group through SQL Server Management Studio and add both database nodes with “Join Only” synchronization preference.
18. Create & Configure Listener (Client Access Point) Service.
19. Assign ILB IP Address to Listener Entry.
20. Set Dependency for SQL DB Availability Group to Listener.
21. Download the scripts for setting up logon credentials/groups/permissions similar on both database nodes.

http://blogs.msdn.com/b/saponsqlserver/archive/2012/03/29/sql-server-2012-alwayson-part-5-preparing-to-build-an-alwayson-availability-group.aspx

1. Execute sp_help_revlogin2 script on database node A.
2. Execute sap_help_revlogin script on database node A. Copy the result and create sql file and transfer the file to database node B.
3. Execute the result sql file on database node B. (Ignore error regarding SAP_<SID>_LocalAdmin group).
4. Compare Users/Permissions on both Database Nodes.
5. Change “DEFAULT” profile parameters “SAPDBHOST” and “dbs/mss/server” to Listener Name.
6. Stop & Start SAP ASCS Services.
7. Install Primary Application Server on SAP Node A. (If you are using only 4 VMs then can install this in local drive)
8. Install Additional Application Server Instance on SAP Node B. (If you are using only 4 VMs then can install this in local drive)
9. Update <SIDADM> environment variables. (e.g. MSSQL_SERVER, MSSQL_CONNOPTS etc.)
10. Stop SAP Application & Database and restart all nodes.
11. Install SAP License for both SAP Nodes.

Testing Scenarios:

1. Open Failover Cluster Manager on application nodes and move group/services from Node A to Node B and vice versa.
2. Restart one node while logged on SAP application and vice versa.
3. Open Failover Cluster Manager on database nodes and move group/services from Database Node A to Database Node B and vice versa
4. Restart one DB Node while SAP application and database are running and check if everything is working fine in application and database.

SAP Notes Reference:

• 1928533 - SAP Applications on Azure: Supported Products and Azure VM types.
• 1612283 - Hardware Configuration Standards and Guidance
• 1772688 - SQL Server AlwaysOn and SAP applications
• 2015553 - SAP on Microsoft Azure Support prerequisites
• 2020535 - Profile parameter conn_opts
• 2137130 - SAP startup hangs with SQL Server
• 2303398 - SAP on SQL Server in Microsoft Azure Virtual Machines

http://scn.sap.com/docs/DOC-56406

Microsoft References:

• https://blogs.technet.microsoft.com/askcore/2015/06/24/windows-server-failover-cluster-on-azure-iaas-vm-part-1-storage/
• https://blogs.msdn.microsoft.com/saponsqlserver/2015/05/20/clustering-sap-ascs-instance-using-windows-server-failover-cluster-on-microsoft-azure-with-sios-datakeeper-and-azure-internal-load-balancer/