Export (0) Print
Expand All

Microsoft Azure Architectures for SharePoint 2013

 

Applies to: SharePoint 2013, Microsoft Azure

Topic Last Modified: 2014-05-19

Summary: SharePoint solutions can be hosted in Microsoft Azure Infrastructure Services. This topic describes some available SharePoint Server solutions and how you can set up Microsoft Azure to host a SharePoint Server solution.

Azure is a good environment for hosting a SharePoint Server solution. In most cases, we recommend Office 365, but a SharePoint Server farm hosted in Azure can be a good option for specific solutions. This article describes how to architect SharePoint solutions so they are a good fit in the Azure platform. The following two specific solutions are used as examples:

Azure Infrastructure Services is a compelling option for hosting SharePoint solutions. Some solutions are a better fit for this platform than others. The following table shows recommended solutions.

 

Solution Why this solution is recommended for Azure

Development and test environments

It’s easy to create and manage these environments.

Disaster recovery of on-premises SharePoint farms to Azure

Hosted secondary datacenter   Use Azure instead of investing in a secondary datacenter in a different region.

Lower-cost disaster-recovery environments   Maintain and pay for fewer resources than an on-premises disaster recovery environment. The number of resources depends on the disaster recovery environment you choose: cold standby, warm standby, or hot standby.

More elastic platform   In the event of a disaster, easily scale-out your recovery SharePoint farm to meet load requirements. Scale in when you no longer need the resources.

See SharePoint Server 2013 Disaster Recovery in Microsoft Azure.

Internet-facing sites that use features and scale not available in Office 365

Focus on developing a great site rather than building infrastructure.

Take advantage of elasticity in Azure   Size the farm for the demand, and pay only for resources you need. Dynamic machine allocation is not supported (auto scale).

Use Azure Active Directory (AD)   Take advantage of Azure AD for customer accounts.

Add SharePoint functionality not available in Office 365   Add deep reporting and web analytics.

See Internet Sites in Microsoft Azure using SharePoint Server 2013.

App farms to support Office 365 or on-premises environments

Build, test, and host apps in Azure to support both on-premises and cloud environments.

Host this role in Azure instead of buying new hardware for on-premises environments.

For intranet and collaboration solutions and workloads, consider the following options:

  • Determine if Office 365 meets business requirements or can be part of the solution. This solution provides a rich feature set that is always up to date.

  • If Office 365 does not meet all your business requirements, consider a standard implementation of SharePoint 2013 on premises by Microsoft Consulting Services (MCS). A standard architecture can be a quicker, cheaper, and easier solution for you to support than a customized one.

  • If a standard implementation doesn’t meet your business requirements, consider a customized on-premises solution.

  • If using a cloud platform is important for your business requirements, use Azure. SharePoint solutions are much easier to support in Azure than other non-native Microsoft public cloud platforms.

While this article uses example SharePoint topologies, you can use these design concepts with any SharePoint farm topology. Before you design the Azure environment, use the topology, architecture, capacity, and performance guidance on TechNet to design the SharePoint farm.

Each SharePoint Server farm relies on Active Directory to provide administrative accounts for farm setup. At this time, there are two options for SharePoint solutions in Azure. These are described in the following table.

 

Option Description

Dedicated domain

You can deploy a dedicated and isolated Active Directory domain to Azure to support your SharePoint farm. This is a good choice for public-facing Internet sites.

Extend the on-premises domain through a site-to-site VPN connection

When you extend the on-premises domain through a site-to-site virtual private network (VPN) connection, users access the SharePoint farm via your intranet as if it were hosted on premises. You can take advantage of your on-premises Active Directory and DNS implementation.

A site-to-site VPN connection is required for building a disaster-recovery environment in Azure to fail over to from your on-premises farm.

This article includes design concepts for extending the on-premises domain through a site-to-site VPN connection. If your solution uses a dedicated domain, you don’t need to design for a VPN connection.

First you need a virtual network in Azure, which is where you define an IP address range for your virtual machines. Azure uses infinite-lease DHCP addresses, and you can’t assign static IP addresses.

If you are extending your on-premises network to Azure through a site-to-site VPN connection (required for a disaster recovery environment), it is important to coordinate these addresses with your on-premises environment.

Figure 1: On-premises environment with Windows Server 2012 Routing and Remote Access Service (RRAS) for connection to Azure

Shows a virtual network in Azure next to the on-premises environment.

In this diagram:

  • A virtual network in Azure is illustrated side-by-side to the on-premises environment. The two environments are not yet connected by a VPN connection.

  • At this point, the virtual network includes no other architecture elements.

The next deployment step is to create the site-to-site VPN connection (if this applies to your solution). When you set up a VPN connection, the VPN service resides in a separate subnet. Azure manages the primary and secondary instances of this service for high availability; you will not see the secondary instance.

When you plan for a VPN connection, you define and create an on-premises network with a VPN gateway: required virtual machines, subnets, static routes, and a VPN gateway device.

Figure 2: Using a VPN gateway to provide site-to-site connectivity between the on-premises environment and Azure

Shows a virtual network in Azure next to the on-premises environment.

In this diagram:

  • Adding to the previous diagram, 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 Gateway subnet.

  • A standby VPN virtual machine is also shown in the Gateway subnet. However, the annotation indicates that this virtual machine is not visible. It is automatically configured and managed by Azure.

  • The on-premises environment includes a Windows Server 2012 RRAS server.

Additional resources:

A cloud service in Azure is a logical container within a virtual network for hosting virtual machines. Cloud services are typically used to group virtual machines by role, based on functionality that occurs at the cloud service level. If you are a SharePoint architect or IT professional, the key things to know about cloud services are:

  • Cloud services and the virtual machines within them can be started and stopped separately.

  • Cloud services can load balance endpoints. For example, a cloud service can load balance requests to two or more SharePoint web servers contained in it.

  • You can export and import a cloud-service configuration. The configuration controls monitoring, remote access, and other settings for the virtual machines contained in the cloud service.

  • You can use a cloud service to auto-scale roles (grow computing resources dynamically), but this is not supported by SharePoint. Do not create additional cloud services for this purpose.

We recommend that you start with one cloud service and add additional cloud services only if necessary. The following diagram illustrates a best-practice starting point for a SharePoint environment.

Figure 3: Cloud services for a SharePoint recovery environment

Shows three cloud services in the Azure virtual network environment.

This diagram builds on the previous diagrams by illustrating three cloud services within the virtual network in the Azure environment. These are described in the following table:

 

Cloud service Purpose

1

Hosts the Windows Server Active Directory and DNS roles.

2

Hosts the database servers.

This satisfies a requirement in Azure for using a listener with SQL availability groups. The client application (in this case, the SharePoint servers) must reside in a different cloud service from the SQL Server AlwaysOn availability group virtual machines. With this cloud-service configuration, you can set up an availability group listener, which can direct incoming connections to a replica database. For more information about setting up a listener, see Tutorial: Listener Configuration for AlwaysOn Availability Groups in Microsoft Azure.

3

Hosts all SharePoint roles, as well as Office Web Apps.

Be sure to plan your cloud-service configuration before creating virtual machines.

Some Internet-facing site scenarios can require an additional cloud service. These are described in the following table.

 

Scenario More information

Load-balancing apps on the same port over the Internet

Applies to: Internet-facing solutions, not site-to-site VPN solutions.

Issue: One Internet address per cloud service.

Solution: Put SharePoint and Office Web Apps in separate cloud services.

Load-balancing websites running on app servers

Examples: Load-balanced Central Admin site or separate URL for authoring.

Applies to: Sites accessed from the intranet in a solution that is public-facing.

Issue: Only virtual machines with public IPs can be load balanced.

Solution: Apply a public IP to the app servers, place these in a different cloud service from the web servers, and protect them by using access control lists (ACLs).

The Cloud Services topic in the Azure library on MSDN includes more detailed information about cloud services in Azure.

For disaster recovery in Azure, you deploy Active Directory Domain Services (AD DS) and DNS in a hybrid scenario where Windows Server Active Directory Domain Services (AD DS) is deployed both on premises and on Azure Virtual Machines.

Figure 4: Hybrid Active Directory domain configuration

Shows the Active Directory and Domain Name Services VMs added to the cloud service in Azure environment.

This diagram builds on the previous diagrams by adding two virtual machines in the first cloud service. These virtual machines host Active Directory and DNS. They are an extension of the on-premises Active Directory environment.

The following table provides configuration recommendations for these virtual machines in Azure. Use the recommendations in the following table as a starting point for designing your own environment—even for a dedicated domain where your Azure environment doesn’t communicate with your on-premises environment.

 

Item Configuration

VM size in Azure

Small

Operating system

Windows Server 2012

Active Directory role

AD DS domain controller designated as a global catalog server. This configuration reduces egress traffic across the VPN connection.

In a multidomain environment with high rates of change (this is not common), configure domain controllers on premises not to sync with the global catalog servers in Azure, to reduce replication traffic.

DNS role

Install and configure Windows DNS on the domain controllers.

Data disks

Place the Windows Server AD DS database, logs, and SYSVOL on Azure data disks. Do not place these on the operating system disk or the temporary disks provided by Azure.

IP addresses

Use dynamic addresses.

ImportantImportant:
Before you deploy Active Directory in Azure, read Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines. These help you determine if a different architecture or different configuration settings are needed for your solution.

Use the two additional cloud services for the SharePoint farm.

Figure 5: Placement of SharePoint virtual machines in cloud services

Shows the SharePoint farm server roles with the other two cloud services.

This diagram builds on the previous diagrams by adding the SharePoint farm server roles in their respective cloud services.

  • Two 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, distributed cache servers, and back end servers.

A fault domain is a grouping of hardware in which role instances run. Virtual machines within the same fault domain can be updated by the Azure infrastructure at the same time. Or, they can fail at the same time because they share the same rack. To avoid the risk of having two virtual machines on the same fault domain, you can configure your virtual machines as an availability set, which ensures that each VM is in a different fault domain. If three virtual machines are configured as an availability set, Azure guarantees that no more than two of the virtual machines are located in the same fault domain.

When you design the Azure architecture for a SharePoint farm, configure identical server roles to be part of an availability set. This ensures that your virtual machines are spread across multiple fault domains.

Figure 7: Use Azure Availability Sets to provide high availability for farm virtual machines

Shows configuration of availability sets in the Azure infrastructure.

This diagram calls out the configuration of availability sets within the Azure infrastructure. Each of the following roles share a separate availability set:

  • Active Directory and DNS

  • Front end

  • Distribute cache

  • Back end

  • SQL Server

The SharePoint farm might need to be fine tuned in the Azure platform. To ensure high availability of all components, ensure that the server roles are all configured identically.

Here is an example that shows a standard Internet Sites architecture that meets specific capacity and performance goals. This example is featured in the following architecture model: Internet Sites Search Architectures for SharePoint Server 2013.

Figure 8: Planning example for capacity and performance goals in a three-tiered farm

Shows capacity and performance examples in the Azure envrionment.

In this diagram:

  • A three-tiered farm is represented: web servers, application servers, and database servers.

  • The three web servers are configured identically with multiple components.

  • The two database servers are configured identically.

  • The three application servers are not configured identically. These server roles require fine tuning for availability sets in Azure.

Let’s look closer at the application server tier.

Figure 9: Application server tier before fine tuning

Shows the application server tier.

In this diagram:

  • Three servers are included in the application tier.

  • The first server includes four components.

  • The second server includes three components.

  • The third server includes two components.

You determine the number of components by the performance and capacity targets for the farm. To adapt this architecture for Azure, we’ll replicate the four components across all three servers. This increases the number of components beyond what is necessary for performance and capacity. The tradeoff is that this design ensures high availability of all four components in the Azure platform when these three virtual machines are assigned to an availability set.

Figure 10: Application server tier after fine tuning

Shows all three application server configured identically with the same four componenets.

This diagram shows all three application servers configured identically with the same four components.

Join the discussion

Contact us Description

What solutions do you need?

We are creating content for solutions that span multiple Microsoft products and services. Let us know what you think about our cross-server solutions, or ask for specific solutions by sending email to MODAcontent@microsoft.com.

Join the solutions discussion

If you are passionate about solutions, consider joining the Solutions Advisory Board (SAB) to connect with a larger, vibrant community of Microsoft solutions content developers, industry professionals, and customers from around the globe. Email SAB@microsoft.com to join. Anyone can read community-related content on the SAB blog; however, SAB members get access to private solutions webinars and can participate in the SAB Yammer network.

Get the art you see here

If you want an editable copy of the art you see in the Solutions using Office Servers and the Cloud content, we’ll be glad to send it to you. Email your request, including the URL and title of the art, to MODAcontent@microsoft.com.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft