Each AV set contains several fault/update domains numbered from zero and each domain is other rack/AV zone in AWS term.
Does the same domain number in different AV sets corresponds to the same rack/AV zone?
I would like to assign different domains for VM in different AV sets (actually different accounts). If 1st VM is in domain 0 in set AV_SET1, and 2nd VM is in domain 1 in AV_SET2, does it mean they really have different power supply, etc.?
Thanks.
Imagine a room with 100,000 servers in. spread across a few thousand racks. You clearly couldn't identify them from a single digit number. (this is obviously hypothetical, but its not an unreasonable assumption for one of their larger datacentres - or even one of their smaller ones!)
In AWS an availability Zone is the equivalent of a separate building for a discreet deployment of servers, it is possible to specify which zone you deploy a server into.
Azure has no such concept of specifiable zones. You get a region, which generally has multiple sites within that region (similar to AWS Zones)
An availability set will exist within a single zone, the next availability set you launch could be in that zone or not. There is no way to know, and no way to specify.
A rack within a zone is considered to be a fault domain. An unspecified number of racks becomes a stamp. A stamp is a unit of compute, storage and networking services. an unspecified number of stamps becomes an upgrade domain.
There could be a large number of small upgrade domains or a small number of large ones. There is very little documentation that clearly describes this system (most of this information is gleaned from videos that assorted MS employees have created with internal MS information)
However it seems incredulous that these would be counted in single or double digits as that would put a huge number of servers at risk if an update failed.
Working on the presumption that updates are performed with x+1 capacity, it would mean that if there were 20 update domains they would need 5% of the capacity sitting idle just to take up the slack if an update failed. When you're talking tens of thousands of servers this wouldn't make sense.
So clearly there are going to be many thousand fault domains. and a 'large' number of update domains.
The only guarantee that is given about fault / update domains is that they exist within an AV, there is no reason that to believe that a VM in domain 0 in AV1 isn't residing on the same physical machine as a VM in domain 1 in AV2, or in the same rack, or in the same stamp, or in the same zone.
It makes more sense to design your solution with that thought in mind. That a single failure could take down separate domains in different AVs
I would very much to be able to provide some citations for what I've said here, but the majority of it has come from videos and snippets of documentation I've seen over the years of Azure being built. So everything I say here could be entirely fictional!
Does the same domain number in different AV sets corresponds to the same rack/AV zone?
NO. You will always see FD0 and FD1 (and for ARM deployments - FD2). An Azure region may have more FDS, but this is internal organisation of the infrastructure, for which the customer is not responsible and cannot influence.
Fault domains describe hardware boundaries. Whether it is single rack, or set of racks, no one can tell you. But rest assured, when you properly organize your workloads into AV sets with min. of 2 VMs in each, you will have the promised SLA 99.95%.
It is interesting though, what is motivation and driver behind the wish to have control over VM placements in different AV sets.
Have no illusion - deploying single VM into an AV set will NOT grant you 99.95% SLA.
