Microsoft Azure IaaS Solutions

Chapter 1. Introduction to Microsoft Azure

Microsoft Azure is a public cloud platform featuring powerful on-demand infrastructure and solutions for building and deploying applications workloads as well as a wide variety of IT and application services. You can use Azure as a public cloud provider and as a hybrid extension to existing on-premises infrastructure. Organizations that use Microsoft solutions on-premises are able to easily extend their infrastructure and operational processes to Azure.

With the growing popularity of Azure, today’s systems administrators need to acquire and strengthen their skills on this fast-growing public cloud platform. In this chapter we explore the Azure public cloud platform with a focus on the Infrastructure-as-a-Service (IaaS) features. We cover general architectural features of the Azure cloud including geographic regions, availability zones, and Service Level Agreements (SLAs) attached to the core Azure IaaS infrastructure.

Tip

Check out a full glossary of Azure terms available as a link in the additional resources.

Regions, Availability Zones, Availability Sets, and Uptime SLAs

The Azure cloud environment is segmented logically and physically to provide the following:

Geographic availability

Low-latency access to geographic locations for more rapid application and service access

Geographic resiliency

Multiple points of presence for distributing applications, workloads, and services to allow for high availability

Core services are available across the entire infrastructure, including Domain Name System (DNS), security, identity and directory services, and others that are often described as oxygen services.

The geographic layout of Azure is divided up into locations grouped into regions, and within each region they are physically separated Availability Zones.

Regions

Azure touts the largest public cloud, and it is growing at the fastest rate by percentage of any public cloud to date with 54 regions as of this writing. Regions are defined as an area within a specific geography that does not span across national borders and that contains one or more datacenters.

Regional access is an important consideration for many technical and business reasons. Both deployment considerations and user experience are affected by the availability of multiple regions. You must also weigh advantages against design considerations and complexity when using multiregion architectures.

Using multiple regions in order to support scale-out application and virtual machine deployments provides a way to ensure resiliency and availability. This concept is explored later in this guide in “Design Patterns for Availability Using Azure Virtual Machines”.

Another use case is ensuring low-latency access to customers within a specific region (e.g., customers in Asia-Pacific geographies would suffer from latency if they were to access a North American region).

There are also specialty regions that are purpose-built to deal with regulatory and governmental boundaries. These include the following:

• US Gov Virginia and US Gov Iowa

• China East and China North

• Germany Central and Germany Northeast

Each specialty region is designed to solve for specific governmental and security regulations that require distinct cloud environments for targeted customers with these requirements (e.g., FedRAMP, DISA).

Regional clouds in China and Germany provide local datacenter operations to be controlled by country-specific providers, which is a requirement for data sovereignty and other regulatory boundaries specific to those regions.

Paired Regions

Another feature within Azure is Paired Regions. These regions are in the same geography but are typically at least 300 miles apart and provide the ability to deploy cross-region services and applications while maintaining geographic residency.

Paired Regions also have operational processes that ensure that sequential updates occur and that prioritized regional recovery occurs in the event of an outage. This provides you with better resiliency options for application and systems architects to use when designing your Azure solutions.

Specific Azure services have replication options and will take advantage of the paired region, as shown in Figure 1-1, as the replication target in order to maintain geographic residency for data and application workloads.

Figure 1-1. Logical design example of a paired region

Using Paired Regions enables deployment patterns that can include applications that might be replicated rather than used in a distributed deployment. This enables active–passive deployment patterns with low-latency access to the second region for rapid recovery in the case of a fault.

Paired Regions services that can be replicated include compute (Azure Virtual Machines), Storage, and Database services. Additional third-party products are available to replicate resources and data outside of the native Azure offerings.

Tip

Additional reading and resources for Paired Regions are available online at http://bit.ly/2Mv9Tlv.

You can take advantage of the built-in offerings to create or enhance your business continuity and disaster recovery strategy using Azure. This is among one of the many ways to take advantage of the on-demand and built-in capabilities.

Availability Zones

Each region comprises at least one Availability Zone, which is defined as a datacenter with independent power, network, and cooling environments. Each Availability Zone is separated by a reasonable distance to ensure protection from a significant disruption (e.g., power grid failure) while also being close enough to maintain low-latency network access to other Availability Zones within the region.

Prior to 2016, Azure abstracted the physical topology within a region from the customer. This has been updated to include specific deployment and visibility of Availability Zones (formerly known as datacenters). There are three supported regions (Central US, France Central, West Europe) and two additional regions that are in preview (East US 2, Southeast Asia) as of this writing.

Availability Sets

Azure provides a powerful resiliency option called Availability Sets. This logical construct is made up of multiple VMs that usually make up a distributed application. The Availability Sets option also introduces the concept of a fault domain. Availability Sets distribute across fault domains to ensure greater availability in the case of a localized failure within the Azure infrastructure that could affect application availability on a single VM.

Update domains are also used for Availability Sets, and define the VMs that can be rebooted while still ensuring minimum application access within the Availability Set. This is especially important when designing for operational practices such as patching and software updates.

SLAs on Azure

Each of the Azure services provides SLAs for availability and guidance on how to increase availability through the use of architectural patterns such as using multiple Availability Zones, regions, and other methods to ensure application and service availability.

You calculate availability using the following formula:

Monthly Uptime % = (Minutes in the Month – Downtime) / Minutes in the Month 100

Azure customers receive a service credit for the Azure services that did not achieve the SLA in the event of a loss of service. Most of the Azure services are credited as follows in single-resource deployments:

<99.9% Availability = 10% credit

<99% Availability = 25% credit

<95% Availability = 100% credit

Some services vary on SLA options. This can be because of the maturity of the service, the geographic availability, and the criticality of the service. As an example, the Azure DNS service was recently upgraded to a 100% uptime SLA.

Azure Virtual Machines raise the SLA and are credited as follows:

<99.99% Availability = 10% credit

<99% Availability = 25% credit

<95% Availability = 100% credit

It is important to consider the SLA requirements for each service and to remember that if an SLA is missed, the result is only a credit toward your Azure subscription. Customers are responsible for designing and deploying to meet their own SLA requirements and to ensure high availability across all layers of the application stack. Each of the Azure services provides service tiers, design patterns, and options to increase availability across the environment.

Now that you have a basic understanding of the Azure environment and architecture, we move on to the IaaS compute platform, and deploy and perform some common operations processes in both the Azure portal and using the Azure CLI.