Showing posts with label Availability Sets. Show all posts
Showing posts with label Availability Sets. Show all posts
Why using availability sets is critical in Azure
Yesterday we learnt that using availability sets are more than just a recommended best practise in Microsoft Azure. As Microsoft had scheduled maintenance updates for the Spectre/Meltdown vulnerability for January 10th these were suddenly scrambled into action due to the public announcement of the issue, and updates automatically completed from January 3rd into January 4th without any advance warning.
These updates were obviously critically required and absolutely the right decision from Microsoft but it did also create issues for customers that had production servers rebooted during business hours. Of course these issues did not impact customers that were already utilising availability sets within their infrastructure for high availability.
Availability sets consist of update domains that two or more virtual machines (VM's) are connected to when originally provisioned. These update domains are updated and rebooted at different times thus preventing downtime across VM's that have been provisioned in them creating a high availability redundancy across your applications.
This is useful in the three scenarios - unplanned hardware maintenance events, an unexpected downtime or a planned maintenance event. Each VM in an availability set is placed in an update domain (UD) and a fault domain (FD). A fault domain is used for shared power and network at the rack level. Please read about this more in further detail in the official documentation linked at the bottom of this article.
Microsoft also recommends utilising managed disks when provisioning new VM's in availability sets (or in general) as this creates better availability of disks by isolating them using different storage clusters, as well as creating less overhead management of storage accounts associated to various VM's that you are provisioning.
It is also a good idea to add VM's of different application tiers into their own availability sets as this creates better redundancy for your applications. For example you can place front end web servers in one availability set and back end database servers into a separate availability set. This creates a situation that you will have one server from each tier online at the same time preventing downtime to your application.
To sum it up availability sets need to be thought about and addressed in planning of your architecture and should really be implemented for any business critical VM's or applications in order to prevent any downtime as some experienced yesterday.
Subscribe to:
Posts (Atom)
