I would like to know the difference between the two. I dont find a specific explanation and also there is no specific documentation pertaining to Placement groups. It is always explained in relation to an Availaibilty set similar to the link belo. It is ecplained that it is similar to placement groups, but when to use one over the other?
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-placement-groups
The only closest difference I was able to find was that the Azure Placement group maintains its own fault and update domains. But isnt that what Availability sets also focus on, separate fault and update domains?
In most cases, an availability set and a placement group provide the same availability guarantees (namely, that VMs within each are spread across update domains and fault domains). The difference is in how each may be used. Availability sets are used with VMs and cannot be used with availability zones. On the other hand, placement groups are created implicitly when you create a scale set. Scale sets allow for greater scale by deploying across multiple placement groups and even across multiple availability zones.
So, you may think, why not always use scale sets? Because scale sets require the same configuration for all VMs in the set (same VM size, same extensions on the VM, etc.). To summarize, you should use availability sets when you are ok with smaller scale but want each VM to be unique. On the other hand, you should use scale sets/placement groups when you want larger scale, often across availability zones, and are ok with each VM being the same.
I hope this helps. I've written up a quick blog post as well describing the different high availability strategies on Azure. Check it out if you're interested :): https://negatblog.wordpress.com/2018/06/04/high-availability-on-azure/
Cheers,
Neil
TL;DR: If latency is your first priority, put VMs in a Proximity Placement Group and the entire solution in an availability zone (a single proximity placement group cannot span zones). But, if redundancy and resiliency/high availability is your top priority, put your instances in an Availability Set (this will spread your instances across fault domains; these fault domains do not possess "common power sources and network switches").
Availability sets "[are] a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability...In an availability set, VMs are automatically distributed across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions."
Proximity placement groups, on the other hand, "...offer co-location in the same data center. [Therefore] planned maintenance events, like hardware decommissioning at an Azure datacenter, could potentially affect the alignment of resources in proximity placement groups. Resources may be moved to a different data center, disrupting the collocation and latency expectations associated with the proximity placement group."
Resources:
https://learn.microsoft.com/en-us/azure/virtual-machines/availability#availability-sets
https://learn.microsoft.com/en-us/azure/virtual-machines/linux/co-location
Related
I understood both Azure regions and Availability Zones are meant for fail over. But is there any specific difference between these?
Region pair are two regions nearby that are at least 300 miles away. Availability zones are inside region or can be between two region.
This is covered in documentation: https://learn.microsoft.com/en-us/azure/availability-zones/az-overview.
Azure availability zones are physically separate locations within each Azure region that are tolerant to local failures.
A region can contain multiple availability zones.
They protect against more local failures while the region pairs are further apart and protect from larger failures.
I was reading article from Microsoft which states as below
Managed disks are integrated with availability sets to ensure that the disks of VMs in an availability set are sufficiently isolated from each other to avoid a single point of failure. Disks are automatically placed in different storage scale units (stamps). If a stamp fails due to hardware or software failure, only the VM instances with disks on those stamps fail. For example, let's say you have an application running on five VMs, and the VMs are in an Availability Set. The disks for those VMs won't all be stored in the same stamp, so if one stamp goes down, the other instances of the application continue to run.
So the question is:
Is it single storage unit? I mean, if that storage unit is down, all VM goes down?
If yes, Does managed disk is the solution?
Answer to both is Yes. Use Managed Disks with Availability Sets when creating VMs so to avoid Hardware failures within a Zone aka Data Center. Multiple Zones aka multiple Data Centers combine to become an Azure Region. In one region you will have a minimum of 3 zones (data centers) and max has no limit as of now.
Managed disks by design have a high availability (SLA~~99.99%)This is done by providing you with three replicas of your data. If one or even two replicas experience issues, the remaining replicas help ensure persistence of your data and high tolerance against failures.
In fact, It is even better but more expensive, to use managed disks with Availability Zone Option, which protects your apps from a data center failure.. (Which happens!)
Availability Zones are not available in all regions in Azure yet.
So, in the absence of this feature what are some HA alternatives adopted by customers ?
usually its combination of built-in geo redundancy with the one you implement on your own (say, Azure SQL replication + VMs in 2 regions) and traffic manager\azure front door on top of that.
That's correct, not all regions have Availability Zones. For VM's, you can use Availability Sets to get pretty close to the SLA for AZ's.
You should not really use multiple regions as an high-availability option if your workload is latency-sensitive. Regions should be considered for DR.
I have a two websites on a VM with WHM/cPanel and MySql.
I am looking to move this into Azure and use vertical scaling. Visits to the website are usually stable but three or four times a year there is a big increase in traffic which historically has caused big problems for the existing host.
I am looking to move it into the A5-A7 range of servers for the vertical scaling.
I cannot find anything anywhere about whether there is any downtime involved when Azure scales up my VM from A5 to A6 or whatever.
Does anyone have any experience with this and can give me a definitive answer as to whether there is downtime when using vertical scaling, and if there is any downtime involved then the kind of downtime I would expect
Thank you for your time.
Yes, it will incur downtime. Post on it
Azure will restart your VM.
Quote from the page (I highlighted the important bit):
When considering the ability to resize virtual machines there are
three key concepts that will impact how simple it is to change the
size of your VM.
The region in which your VM is deployed. Different VM sizes require different physical hardware. In some instances, an Azure region may
not contain the hardware required to support the desired VM size. All
Azure regions support the VM sizes Standard_A0 – A7 and Basic_A0 – A4.
You can then find which other VM sizes are supported in each region
under the Services tab of the Azure Regions web page.
The physical hardware currently hosting your VM. If the physical hardware currently running your virtual machine also supports your
desired new size, then it is very easy to change the VM size through a
simple size change operation which results in a VM reboot.
The deployment model used for the VM. The two deployment models are Classic and Resource Manager. The Resource Manager model is the newer
model, and it supports some ease of use functionality not available in
the classic deployment model.
I'm a little bit confused about when to use Azure Availability Set and when to use Azure Affinity Group.
Lets look at the key purpose of Availability set and Affinity Group briefly to begin with.
Availability Set: is predominately to provide High Availability for your deployment. Azure does this via Fault domains and Upgrade domains.
A fault domain: is basically a different hardware rack in the same datacenter. The solution will be deployed in two different hardware racks.
Upgrade domains: is exactly same like fault domains in function, but they support upgrades rather than failures. The Upgrade domain is a logical unit of instance separation that determines which instances in a particular service will be upgraded at a point in time.
Affinity Group: In order to explain it, we need to take peek into Azure DC . Windows Azure Data Centers are purpose build , you might see rows and rows of containers (something like shipping containers) that contain clusters and racks. Each of those Containers have specific services, for example, Compute and Storage, SQL Azure, Service Bus, Access Control Service, and so on. Those containers are spread across the data center.
When you deploy a service using Portal or PowerShell , the service will talk directly to RDFE (Red Dog Front End). The RDFE controls the DC and nodes. The Cluster of nodes is controlled by Fabric Controller.. When you specify Affinity Group , the Fabric controller will place all the required elements of a deployment together. This has number of advantages like reducing latency (since required elements are close together) , Networking.
There are new changes brought in related to Network Affinity group , you can refer them (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-migrate-to-regional-vnet/).
To address you question
You would use Availability set when you want to have Highly Available system and also want to have SLA for Compute. Without Availability set there wont be SLA for your VM or PaaS Instances in other words will single instances of VM (IaaS) and PaaS wont have SLA and prone to downtime during HW failure and Upgrades of OS.
Availability set can be implemented after the deployment as well. Do note there is cost associated with the Availability set , since you are running additional instances , so they will be charged.
Affinity group you need to include them at the time of Creation of the services . It cannot be updated after the creation. So it very important to include Affinity group at the time of creation. There is no additional charges for including Affinity group.
Do share your feedback if the response addresses your question.