Set up SQL AlwaysOn Availability Groups for Windows Azure Pack management databases

  • Article

 

Applies To: Windows Azure Pack

To support high-availability and disaster recovery for your Windows Azure Pack management databases, you can use the SQL AlwaysOn Availability Groups feature.

Each SQL Server not run by Resource Governance can belong to multiple Availability Groups. This means that you can have different applications, each in a different Availability Group, use the same SQL Server.

For more information about SQL Server AlwaysOn Availability Groups, go to https://msdn.microsoft.com/en-us/library/hh510230.aspx.

To set up Windows Azure Pack management database with SQL AlwaysOn Availability Groups

  1. Review and comply with the SQL AlwaysOn Availability Groups prerequisites listed here.

  2. Create an availability group with the corresponding availability group listener using default port 1433. For details, see the CREATE AVAILABILITY GROUP Data Definition Language statement.

  3. Run the following script on every SQL instance in the availability group.

    sp_configure 'contained database authentication', 1;  
GO  
RECONFIGURE;  
GO

    For more information on this script, see the contained database authentication Server Configuration Option topic.

  4. Deploy Windows Azure Pack for Windows Server. While configuring each of the Windows Azure Pack components, use the availability group listener name for the Database Server Name. This sets the availability group listener primary database as the Windows Azure Pack management database.

  5. Backup the databases created in the previous step. These databases include:

    • Microsoft.MgmtSvc.Config

    • Microsoft.MgmtSvc.MySQL

    • Microsoft.MgmtSvc.PortalConfigStore

    • Microsoft.MgmtSvc.SQLServer

    • Microsoft.MgmtSvc.Store

    • Microsoft.MgmtSvc.Usage

    • Microsoft.MgmtSvc.WebAppGallery

    For instructions on how to backup databases, see How to: Backup and Restore a Database (SQL Server).

  6. Add the databases backed up in the previous step to the availability group. For instructions on how to do this, see Join a Secondary Replica to an Availability Group (SQL Server). This synchronizes the databases to the secondary databases.

  7. For UR1 and earlier deployments, the management databases are not created as contained databases. Therefore, primary database user logins for Windows Azure Pack must be synchronized to the secondary databases as described in How to transfer logins and passwords between instances of SQL Server.

    • AdminSiteNotificationServiceUser

    • AuthSiteNotificationServiceUser

    • MgmtSvc-AdminSite

    • MgmtSvc-AuthSite

    • MgmtSvc-Monitoring

    • MgmtSvc-MySQL

    • MgmtSvc-SQLServer

    • MgmtSvc-TenantAPI

    • MgmtSvc-TenantPublicAPI

    • MgmtSvc-TenantSite

    • MgmtSvc-Usage

    • MgmtSvc-UsageCollector

    • MgmtSvc-UsageCollector_Management

    • MgmtSvc-WebAppGallery

    • MgmtSvc-WindowsAuthSite

    • TenantSiteNotificationServiceUser

    Note

    When deploying new installations of the UR2 version of Windows Azure Pack, you don't need to transfer the logins because the databases are created as contained databases. If you update your deployment from UR1 to UR2, the UR2 update will not change the existing databases to contained databases, so you must transfer the user logins as explained above.

  8. Verify the database replication by using the AlwaysOn Dashboard in the SQL Server Management Studio Options dialog box. For more information, see Use the AlwaysOn Dashboard (SQL Server Management Studio).

For more information Windows Azure Pack and SQL Server AlwaysOn, see Configure SQL AlwaysOn Availability Groups in Windows Azure Pack.