Introduction

Pour garantir un SLA le plus proche de 99.95% sur les services hébergés par vos VMs (IaaS), Microsoft a mis en place les Availability Sets. Ils vous offrent ainsi la possibilité de grouper virtuellement les VMs pour pallier à tout problèmes hardware (host crash) mais aussi software (updates), en plaçant les VMs sur différents hosts avec une logique de tel sorte qu’on évite le downtime du service que vous hébergez.

Subtilité

Un Availability Set permet de regrouper les VMs hébergeant le même service et rendre l’infrastructure Azure consciente de ceci via deux notions, le Fault Domain et l’Update Domain.

[tabs class= »yourcustomclass »]
[tab title= »Fault Domain » active= »active »]

Fault Domain est assimilé à un rack, comprenez un regroupement de hosts avec alimentation, réseau … en commun. Toutes VM dans le même Fault Domain sera dans le même rack, son utilisation est donc pour pallier aux problèmes hardware des Datacenters. Le but étant d’avoir toujours une instance du service active après un problème hardware sur un rack.

[/tab]
[tab title= »Update Domain« ]

Update Domain a été mis en place pour garder une haute disponibilité de vos services en cas d’update. Même si en IaaS Microsoft ne s’occupe pas de la mise à jour de vos VMs, il s’occupe par contre de la couche basse donc de l’Hyperviseur et ses potentielles failles software. En ajoutant des VMs dans un UD, vous autorisez Microsoft à les freezer/redémarrer en même temps pour procéder à des mises à jour. De ce fait au moins une instance de votre service tournera vu qu’il n’y aura jamais deux UD en maintenance en même temps, par contre l’ordre ne sera pas forcément séquentiel.

[/tab]
[tab title= »Affinity Group« ]

Affinity Group est un concept (obsolète) en rapport avec la distance physique, lorsque vous en spécifiez un le Fabric Controler place les éléments (VMs…) ensemble ou du moins le plus proche possible. Il y a un certain nombre d’avantages notamment la réduction de la latence.

[/tab]
[/tabs]

[rule style= »rule-dotted » ]

A la création d’un AS vous avez par défaut 5 UDs (0,1,2,3,4) non configurables séparés entre 2 FDs (0,1). Si vous y insérez plus de 5 VMs, la 6^e sera insérée dans le même UD que la 1^e VM, la 7^e avec la 2^e et ainsi de suite.

Résumé :

1 Availability Set = 1 Service (ex. SQL, IIS …)

1 Availability Set = 2 Fault Domains + 5 Update Domains (Par défaut)

1 Fault Domain = 1 Rack –> Crash groupé

1 Update Domain = Extinction/Freeze groupé

Affinity Group = Performance (- de Latence)

Uptime 99.9% = Availability Set + Load Balancer (ILB)

Si vous redimensionnez une VM dans un Availability Set, il faudra éteindre toutes les VM, faire la modification et les démarrer ensuite. Cette limitation vient du fait que les VMs doivent être sur le même cluster hardware, hors le cluster actuel n’a pas forcément la nouvelle quantité de RAM.

Exemple :

Le client me demande de garder en toute circonstance au moins 2 VMs mais si possible 3, je propose donc un design de 5 VMs.

Si il y a un problème dans le DC qui engendre la perte d’un rack complet :

• FD0 il me reste Srv1 et Srv3 (2/5) [progressbar value= »40″ barstyle= »progress-striped active »]
• FD1 il me reste Srv0, Srv2 et Srv4 (3/5) [progressbar value= »60″ barstyle= »progress-striped active »]

En cas de mise à jour des Hyperviseurs, une seule VM sera impactées à la fois. Il me reste donc au minimum 4 VMs, mes services restent Up & Running. [progressbar value= »80″ barstyle= »progress-striped active »]

1 vote(s)

Loading...