Azure Availability Sets and Azure Availability Zones explained

Posted on by Imran Rashid
Reading Time: 6 minutes

In this blog post I aim to simplify and help you understand the difference between Fault and Update Domains within an Azure Availability Set.

Furthermore, I will discuss the Azure SLA (Service Level Agreement) Microsoft offer on a single Virtual Machine, two or more Virtual Machines configured within an Azure Availability Set and finally Virtual Machines configured in an Azure Availability Zone.

What is an Azure availability Set?

• An availability set is a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability.

• Each virtual machine in your availability set is assigned an update domain and a fault domain by the underlying Azure platform. Each availability set can be configured with up to three fault domains and twenty update domains.

• There is no cost for the Availability Set itself, you only pay for each VM instance that you create.

• A VM can only be added to an availability set when it is created. To change the availability set, you need to delete and then recreate the virtual machine.

• Microsoft recommend that two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA.

What is an Update Domain?

• Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time.

• Each virtual machine in your availability set is assigned an update domain by the underlying Azure platform.

• When more than five virtual machines are configured within a single availability set with five update domains, the sixth virtual machine is placed into the same update domain as the first virtual machine, the seventh in the same update domain as the second virtual machine, and so on

• The order of update domains being rebooted may not proceed in a sequence during planned maintenance, but only one update domain is rebooted at a time

• A rebooted update domain is given 30 minutes to recover before maintenance is initiated on a different update domain.

What are Fault Domains?

• Fault domains define the group of virtual machines that share a common power source and network switch. For example, to be rack fault tolerant, your servers and your data must be distributed across multiple racks.

• By default, the virtual machines configured within your availability set are separated across up to three fault domains. Please note, selecting three fault domains may not always be possible.

What are Azure Availability Zones?

• Azure availability zones are physically separate locations within each Azure region that are tolerant to local failures. Failures can range from software and hardware failures to events such as earthquakes, floods, and fires

• Azure regions and availability zones are designed to help you achieve resiliency and reliability for your business critical workloads

• Each Azure region features datacentres deployed within a latency-defined perimeter.

• Each zone is composed of one or more datacentres equipped with independent power, cooling, and networking infrastructure.

• Availability Zones are not available at all regions, visit the following link for more info https://docs.microsoft.com/en-us/azure/availability-zones/az-overview

• 99.99% SLA for workloads deployed in Availability Zones

What are Azure Service Level Agreements (SLAs)?

Azure periodically updates its platform to improve the reliability, performance, and security of the host infrastructure for virtual machines. The purpose of these updates ranges from patching software components in the hosting environment to upgrading networking components or decommissioning hardware. Service-level agreements (SLAs) describe Microsoft’s commitments for uptime and connectivity.

The SLAs for Azure services that Microsoft offer can be located at the following Microsoft website, https://azure.microsoft.com/en-gb/support/legal/sla/

SLA provided on Single Azure VM vs Availability Set vs Availability Zone

To simplify this blog post, below is a table I compiled with the SLA’s provided for a single VM in Azure (with premium SDD or Ultra Disk storage), an availability set and finally an availability zone. We will refer to this table throughout this blog post.

DeploymentSLADowntime
Single VM (with Premium SDD or Ultra Disk)99.9%Per month: 43.83 mins
Availability Set99.95%Per month: 21.92 mins
Availability Zones99.99%Per month: 4.38 mins

Now let’s simplify further,

Deploying a single Azure Virtual Machine

In the diagram below, I demonstrate the deployment of a single virtual machine in Azure. As you can see from the below diagram, a physical host failure or a rack failure may cause down time for your single Virtual machine.

Deploy two Azure Virtual Machines

In the diagram below, I demonstrate the deployment of two virtual machines in Azure. As you can see from the below diagram, there is no guarantee that both VM’s will not be hosted within the same physical rack or physical host. A physical host failure or rack failure may cause down time for both virtual machines.

Deploy virtual web servers in an Azure Availability Set

In the diagram below I deploy an availability set with 2 fault domains and 4 update domains. As you can see from the diagram below, fault domains relate to physical racks with independent power source and network connectivity. Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. To simplify update domains, imagine the update domain as the underlying physical host that hosts your virtual machine.

So how does Microsoft deal with the below scenario. As you can see the four virtual web servers have been distributed across two fault domains as in physical racks and 4 update domains as in physical servers. As mentioned earlier in the post, Microsoft only reboot one update domain at a time, so for example, if Microsoft were to perform maintenance on the underlying physical hardware and there was a requirement to reboot your virtual machine, you would only lose 25% of your workloads, in this case one server. Microsoft would wait for 30 minutes to allow the server to stabilise before continuing to reboot the next update domain and so on. The benefit, your solution would continue running without downtime.

If I was to introduce an additional two virtual web servers to my availability set, the below table shows what my scenario would look like. Because I only configured 4 update domains within my Availability set (UD0, UD1, UD2, UD3), the two additional VM’s would return to update 0 (WEB5) and update 1 (WEB6). Therefore, if Microsoft rebooted update domain 3 (UD3), I would temporary lose server WEB4. If Microsoft moved on to rebooting UD0, I would temporary lose WEB1 and WEB5, whilst the remaining servers would remain up and running.

I hope this clarifies the difference between update and fault domains within an Azure Availability set.

Referring back to the SLA table I created further up in this post, your downtime is slashed in half when using Availability Sets compared to deploying a single Virtual Machine using premium or ultra disk.

Azure Availability Zones

Moving onto Azure Availability Zones. Please note that you can not select both Azure Availability Zones and Availability Sets when deploying virtual machines. You have the option to select one.

Azure availability zones are physically separate locations within each Azure region that are tolerant to local failures.

To simplify the above, Azure Availability Zones are independent physical datacentres located in a region. These datacentres reside close (approx 20 miles distance, however could be closer or further away) to the primary datacentre equipped with independent power, cooling, and networking infrastructure. As mentioned further up in this post, all Azure regions do not include Azure Availability Zones.

Most importantly, when deploying into an Azure region, Microsoft offer an SLA of 99.99% which equates s to downtime of 4.38 minutes per month.

If you wish to mitigate the risk of downtime in the event of a region failure such as an major earth quake which could take down the primary datacentre along with the Availability Zones in your region, you could utilise the partner region as a DR location, for example, UK South and UK West.

I hope this has helped

Configure Azure Portal Timeout Limit

Posted on by Imran Rashid
Reading Time: 2 minutes

In this short blog post I will go through the process of configuring a timeout limit on your Azure Portal sessions so that after a certain time of inactivity you’re logged out automatically. By default, the configuration is set to never sign out, however your admin may have setup a limit at the directory level. More on this as we go through this blog post.

The inactivity timeout setting helps to protect resources from unauthorised access if you forget to secure your workstation. After you have been idle for a while, you are automatically signed out of your Azure portal session.

  1. Logon to the Azure portal at portal.azure.com
  2. Click on the cog icon (Settings) available at the top pane in your Azure portal session

3. Click Signing out + notifications

4. Use the drop down under Sign me out when inactive

5. Select the timeout limit. In this example I have selected 15 minutes

If your admin has enabled an inactivity timeout policy, you can still set your own, as long as it’s shorter than the directory level setting. To do so, select override the directory inactivity timeout policy, then enter a time interval for the Override value.

If the admin has configured a timeout policy at the directory level, the below will be visible to you. In the example below, the admin has enforced an inactivity timeout of 15 minutes, therefore setting a timeout of 20 minutes is not possible, however 10 minutes is.

Hope this helps and please don’t forget to subscribe to stay up to date on the latest blog posts.

Configure Service Health Alerts in Azure

Posted on by Imran Rashid
Reading Time: 3 minutes

Service Health provides you with a customisable dashboard which tracks the health of your Azure services in the regions where you use them. In this dashboard, you can track active events like ongoing service issues, upcoming planned maintenance, or relevant health advisories. When events become inactive, they get placed in your health history for up to 90 days.

Finally, something which I will be configuring and covering in this blog post, you can use the Service Health dashboard to create and manage service health alerts which proactively notify you when service issues are affecting you.

  1. Login to your Azure Portal portal.azure.com
  2. Search and click Service Health

3. Click Health alerts from the left pane

4. Click + Add service health alert

5. I want to be notified of service issues in region UK South, UK West and global outages.

6. Select the services you wish to be notified of. I would like to be notified of all services so have left the default of 187 services at the time of writing this blog post.

7. Select the event type

Service Health currently tracks four types of health events that may impact your resources:

Service issues – Problems in the Azure services that affect you right now.

Planned maintenance – Upcoming maintenance that can affect the availability of your services in the future.

Health advisories – Changes in Azure services that require your attention. Examples include deprecation of Azure features or upgrade requirements (e.g upgrade to a supported PHP framework).

Security advisories – Security related notifications or violations that may affect the availability of your Azure services.

8. Next, we create the action group to trigger a notification when an issue is reported. Click the link Add action groups

9. Click + Create action group

10. Complete details (see example below). Click Next: Notifications

11. Select your notification method.

12. For the purpose of this demo, i’ll be enabling notifications via email. Input details as required and click OK

13. A name is required. Input a name for your alert.

14. Click review and create

Note: If you wish to configure additional actions post an alert being triggered, the actions tab provides a number of options you may wish to analyse. See screenshot below.

14. Click create and that’s your alert notification created

In the meantime, browse through the service health sections to find out if there are any existing service issues in your region or regions around the world. Another great site to track Azure service status updates is the Azure Status website

I hope you found this useful. Please comment below if you have any further questions.

How to Build an Azure Community

Posted on by Imran Rashid
Reading Time: < 1 minute

Microsoft MVP Mert Yeter invited me to the MSHOWTO show where I had the opportunity to discuss how to build an Azure Community.

MSHOWTO is an independent organisation created in 2005 with the primary goal of increasing Turkish content in the IT sector and to provide solutions related to products belonging to technology manufacturers. It is the longest-running, largest technical community and IT portal in Turkey. It aims to support all IT volunteers with Events, Articles, Videos, Webcasts, Podcasts, Forum Pages.

We had a great discussion, and covered a number of topics, including my blogs, Cloudbuild.co.uk and Azurecrazy.com. We also discussed the Bradford Cloud User Group, the importance of sharing knowledge, getting involved within the community, how to get started with a tech blog and more.

You can view the video below,

Deploy a WordPress website using Azure App Services

Posted on by Imran Rashid
Reading Time: 7 minutes

Azure App Service, part of the Microsoft Azure Cloud platform is a fully managed service for building, deploying, and scaling your web apps. More details on this service can be located at Azure App Service

In this blog post I will go through the process of creating an Azure App Service plan and a MySQL database to host a demo WordPress site.

  1. Login to the Azure Portal
  2. Search and select App Services using the search box

3. Click + Create

4. Select you subscription from the drop down if you have more than one

5. Create a resource group and click OK

6. Select a unique name for your website domain. A green tick will be displayed if the name is available.

7. Using the run time stack drop down, select PHP 7.4 (Latest version at the time of writing this post)

8. For the the purpose of this demo, I have selected region UK South, and Linux for the Operating System.

9. Create a new service plan and click ok

10. Click change size

11. Review the available tiers. For the purpose of this demo, I have selected the dev/test version. Note that the test/dev version does not include a custom domain or SSL but you can always upgrade plans later. Click Apply,

12. Click Review + Create. Review the details and click Create

13. Deployment complete. Click Go to Resource and review the various options.

14. WordPress requires a MySQL database so let’s create a database. Using the search field, search MySQL and select Azure Database for MySQL servers

15. Click + Create

16. For the purpose of this demo, I have selected Single Server, but you’ll notice Flexible server was in preview at the time of writing this post.

17. Resource Group: I have selected the resource group I created earlier

18. Input a server name, select region and workload type as required

19. Click configure server and explore the various server sizes on offer. For the purpose of this demo, I have selected the cheapest one available. Don’t forget to delete your resources if you’re lab’ing 🙂

20. High Availability (Zone redundant HA) is not available with the tier i have selected.

Availability Zone: You can optionally specify an availability zone in which you deploy your database server to co-locate with your application

HA: provides enhanced availability for your mission critical workloads by deploying a standby server in a different availability zone within the same region as your primary server

As this is a demo, i won’t be configuring HA

21. Select MySQL version and input a database username and password. Click ‘Next: Networking‘

22. Click + Add current client IP address to add your public IP address to the firewall. Connections from the IP addresses configured in the Firewall rules section below will have access to this server. By default, no public IP addresses are allowed.

23. Click Review + Create. Review the information and click Create. That’s the MySQL Database deployed. We will need to hook the app service plan to the database later.

24. Return to the app service plan we created earlier, click the app service plan.

25. Whilst the MySQL database server is deploying in the background, we’ll connect to our app service via SSH and download WordPress. From the left blade, under Development Tools, select SSH

26. Click Go

27. Type:

cd site/wwwroot/ (enter)

28. We’ll now download the latest WordPress version from WordPress

Type: wget -c http://wordpress.org/latest.tar.gz (Press enter)

29. Type ls to check if the zip file is visible

30. We’ll now unzip the folder
Type: tar -xzvf latest.tar.gz

31. The above process has unzipped a folder name WordPress. We must move all files from inside the WordPress folder to wwwroot

Type: mv wordpress/* /home/site/wwwroot/

32. We can now delete the WordPress folder and the zip file

rm -rf wordpress/
rm -r latest.tar.gz

33. Next, we’ll connect to our MySQL database using the a free application MySQL WorkBench. You can download the tool from https://dev.mysql.com/downloads/workbench/

35. Install the MySQL WorkBench app. If not already installed you’ll be prompted to install C+ + 2019 Redistribute Package before you’re able to install MySQL WorkBench. https://visualstudio.microsoft.com/downloads/#microsoft-visual-c-redistributable-for-visual-studio-2019

36. Now that MySQL WorkBench has been installed, we can connect to MySQL in Azure. Click the plus icon to add a connection

37. Enter your MySQL details

– connection name: select a name of your choice
– hostname
– username
– Password

You can obtain the hostname and username from the Azure portal, search Azure Database for MySQL server, click your server name and copy the server name and username from the overview tab. If you did not make a note of your password, use the reset password option.

38. After inputting the details, test connection. We have a successful connection. Click ok and ok again.

39. Open your connection located under MySQL connections which will launch MySQL editor

40. Click Schemas

41. Right click sys and click create schema (This is required to allow WordPress to communicate with MySQL)

42. Input a name, copy the name to a notepad file as you’ll require it shortly. Click Apply

click apply again and finish

43. Return to your web app in the Azure Portal, click overview from the left blade, and then click browse.

44. WordPress has been detected and the install wizard launches. Select your preferred language.

45. Click Let’s Go

46. Input your MySQL details. The database name is the schema name you just created. The username and hostname (servername) can be obtained from your MySQL database on the Azure portal.

47. Click Submit

48. Success, click ‘run the installation’

49. Input site details and continue. Avoid using username of admin as this is the default for WordPress.

Done, you can now configure your WordPress site