Accessible diagram - Microsoft Azure: Deploy SharePoint with SQL Server AlwaysOn

  • Article

 

This article is an accessible text version of the diagram named Microsoft Azure: Deploy SharePoint with SQL Server AlwaysOn, which is available at Technical Diagrams.

Microsoft Azure Infrastructure Services frees you to create a highly available Internet-facing SharePoint farm in the cloud with virtual machines. SQL Server AlwaysOn manages the SharePoint databases for you and allows you to save your resources.

This poster has four sections: 

  • Instructions for setting up a SharePoint farm with SQL Server AlwaysOn.

  • A model of a SharePoint farm running on Azure.

  • A logical view of the SharePoint farm that shows how to publish to the Internet.

  • AlwaysOn availability groups and Azure availability sets.

Setting up a SharePoint farm with SQL Server AlwaysOn

The following procedures summarize the steps necessary to set up a SharePoint farm with SQL AlwaysOn.

Configure Azure components

  • Using the Management Portal, create one virtual network, one storage account, four subnets, and four virtual hard disks (VHDs). Also, you must create eight or more virtual machines for a minimum configuration:

    • Windows Server°2012 Datacenter (medium)

    • SQL Server Enterprise (size A7 or larger)

    • SharePoint Server Trial Servers (large)

    • Application Servers (large)

Configure domain controllers

  1. Add the Active Directory Domain Services Role to one of the Windows Server°2012 virtual machines.

  2. Restart the virtual machine.

  3. Add the following user accounts to the domain:

    • SharePoint Farm administrator

    • Database administrator (used to configure Windows Server Failover Clustering)

    • SharePoint installer

    • SQL Service Login 1 (Service account for primary SQL Server instance)

    • SQL Service Login 2 (Service account for secondary SQL Server instance)

  4. Add the AD°DS role to the second Windows Server°2012 virtual machine as a backup controller.

Configure the SQL Server virtual machines

  1. Attach a 500°GB VHD to each SQL Server virtual machine.

  2. Join the virtual machine to the domain and restart.

  3. Add the database administrator account as a sysadmin role to the default instance.

  4. Add the database administrator account as a virtual machine administrator.

  5. Configure the firewall to allow SQL Server to pass.

  6. Change the SQL Server instance to use the respective domain service account (Login 1, Login 2).

  7. Add a SQL Server login for NT AUTHORITY\SYSTEM with the following permissions: ALTER ANY AVAILABILITY GROUP, CONNECT SQL, and VIEW SERVER STATE.

Configure the SharePoint virtual machine

  1. Join the SharePoint virtual machine to the domain.

  2. Log on to the virtual machine.

  3. Deploy and configure your SharePoint farm using the primary SQL Server virtual machine as the database server.

    For more information, see Plan for SharePoint 2013.

Configure the Windows Server Failover Cluster

  1. Add the Failover Clustering feature to the virtual machines.

  2. To create the Windows failover cluster that includes the SQL Server virtual machines on the primary virtual machine, do the following:

    • Create a single-node failover cluster.

    • Take the cluster name offline.

    • Configure the cluster name’s IP address to a link-local address (169.254.x.x).

    • Bring the cluster name online.

    • Add other SQL Server virtual machines to the failover cluster.

  3. Enable AlwaysOn High Availability in SQL Server Configuration Manager on all SQL Server virtual machines.

    For more information, see Tutorial: AlwaysOn Availability Groups in Azure.

Create AlwaysOn Availability Groups and add databases

  1. Log on to the primary SQL Server virtual machine.

  2. Create a file share on one of the SQL servers and grant or modify rights to the SQL Server Service accounts.

  3. Use SQL Server Management Studio (SSMS) to do a full backup of the SharePoint databases.

  4. Run the New Availability Group Wizard to create an availability group (specifying the replicas and databases).

  5. Manually create an availability group listener.

  6. Remount the SharePoint databases using the availability group listener.

    For more information, see Configure SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013.

SharePoint Farm in the Cloud

The accompanying diagram shows a model of a SharePoint farm running on Azure. In the diagram, the farm uses a site-to-site VPN connection and includes the following:

  • The on-premises environment is connected to the Azure virtual network by a site-to-site VPN connection.

  • An active VPN virtual machine is contained in a separate subnet, labeled VPN gateway subnet.

  • A standby VPN virtual machine is also shown in the VPN gateway subnet. The gateway virtual machines are automatically provisioned by Azure when you set up a VPN gateway. You can’t access the virtual machines, however, you do not need to.

  • The on-premises environment includes a Windows Server 2012 Routing and Remote Access Service (RRAS) server.

The diagram also shows the SharePoint farm with several virtual machines placed in cloud services:

  • Four database virtual machines reside on one cloud service.

  • The other cloud service includes two virtual machines for each of the following roles: front end servers and application servers.

The server farm includes two front-end web servers, application servers, and a database server that is configured with a SQL AlwaysOn Availability Group. An Azure Virtual Network and its subnets provide virtual machines access to resources on the on-premises network.

Publish to the Internet

The accompanying diagram shows three separate logical views of a SharePoint farm and provides details on how to manage publishing features and identity for an Internet site.

SharePoint 2013 farm—logical view with sites (option 1). The accompanying diagram shows separate environments for development and production.

This configuration allows you to:

  • Author and publish in the same environment.

  • Use the cross-site publishing feature to separate authoring from live sites.

  • Apply SharePoint topology guidance to configure virtual machines and design service distribution across virtual machines.

For more information, see Overview of cross-site publishing in SharePoint Server 2013.

SharePoint 2013 farm—logical view with sites (option 2). The accompanying diagram shows separate environments for development, staging, and publishing.

This configuration allows you to use:

  • Multiple farm environments to satisfy isolation requirements or different service-level agreements.

  • Cross-site publishing across multiple SharePoint 2013 farms.

Logical view of the SharePoint 2013 farm with identity management. The accompanying diagram shows how to use Azure Active Directory for customer accounts while using your on-premises Active Directory accounts to authenticate site authors and developers.

  • In SharePoint 2013, identity management is factored into the configuration of SharePoint zones and authentication. For Internet-facing sites, the following approach separates internal and external access into different zones:

    • Configure the default zone for your internal accounts.

    • Configure the Internet zone for customer access, including both anonymous and authenticated access.

    • Use Azure Active Directory for customer accounts, or use a different Security Assertion Markup Language (SAML)-based provider.

  • To collaborate with external partners on the same content, an alternative approach is to implement one zone with SAML-based authentication across the different directories, resulting in one URL for all users.

Be more available

This section describes Windows Azure availability sets and SQL Server AlwaysOn availability.

Windows Server failover clustering

The accompanying diagram shows a failover cluster with an availability group that includes one primary replica, which hosts the primary databases, and four secondary replicas, each of which hosts a set of secondary databases and serves as a potential failover target for the availability group. Since the secondary replicas are not backups., you should back up your data as usual.

Deploying availability groups requires a Windows Server failover cluster. Each availability replica of a given availability group must reside on a different node of the same failover cluster.

For more information, see AlwaysOn Availability Groups (SQL Server).

Availability groups vs. availability sets

The accompanying diagram shows two fault domains with two virtual machines in each domain. The domains promote availability to mitigate hardware failures.

An availability group is a SQL Server AlwaysOn solution that provides high availability to databases. In contrast, Azure availability sets span fault domains and ensure that hardware failures do not take down multiple virtual machines.

The availability set is a supporting configuration to SQL Server AlwaysOn availability groups.

For more information, see Manage the Availability of Virtual Machines.