Chapitre 1313 minIntermédiaire
Disponibilité et sauvegarde : zones, SLA et Azure Backup
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- expliquer région, zone de disponibilité et région appairée ;
- convertir un SLA en temps d'arrêt et calculer un SLA composite ;
- concevoir une architecture qui survit à la perte d'une zone ;
- sauvegarder des ressources cloud en respectant la règle 3-2-1.
4 exercices corrigés1 schéma
La disponibilité d'un service cloud dépend de la façon dont il est réparti entre zones de disponibilité et régions, et elle se chiffre par un SLA, l'engagement de niveau de service du fournisseur, exprimé en pourcentage du temps. La sauvegarde est une autre question : elle protège contre la perte ou la corruption des données, ce que la redondance ne fait pas. Ce chapitre explique régions, zones et régions appairées, convertit un SLA en temps d'arrêt, calcule un SLA composite, montre comment survivre à la perte d'une zone, puis comment sauvegarder et reprendre un service cloud.
Régions, zones de disponibilité, régions appairées
- Une région est un ensemble de centres de données dans une zone géographique : France Central, à Paris.
- Une zone de disponibilité est un groupe de centres de données d'une région, physiquement séparé des autres, avec sa propre alimentation, son refroidissement et son réseau. France Central en compte trois. La panne d'une zone (incendie, coupure électrique) n'arrête pas les deux autres.
- Une région appairée est une seconde région du même pays ou de la même zone géographique, associée à la première pour la reprise après sinistre et la réplication géographique. Celle de France Central est France South, à Marseille, dont l'accès est réservé à ce type d'usage.
Une ressource peut être :
| Type | Placement | Ce qui se passe si sa zone tombe |
|---|---|---|
| Régionale (non zonale) | N'importe où dans la région, sans engagement | Elle peut tomber, si elle était dans cette zone |
| Zonale | Épinglée dans une zone choisie (la zone 1, par exemple) | Elle tombe avec sa zone |
| Redondante entre zones | Répliquée sur plusieurs zones par le service | Elle continue de fonctionner |
Le SLA : un engagement chiffré
Le SLA (Service Level Agreement) d'Azure fixe, service par service, le pourcentage de disponibilité mensuelle sur lequel Microsoft s'engage. S'il n'est pas tenu, le client obtient un avoir sur sa facture (service credit), une fraction du prix du service : pas l'indemnisation de ses pertes. Un SLA est donc une promesse commerciale, pas une garantie que la panne n'arrivera pas (cours Droit et RGPD).
| Service et configuration | SLA |
|---|---|
| Une VM seule avec des disques HDD Standard | 95 % |
| Une VM seule avec des disques SSD Standard | 99,5 % |
| Une VM seule avec des disques SSD Premium ou Ultra | 99,9 % |
| Deux VM ou plus dans un même groupe à haute disponibilité (availability set) | 99,95 % |
| Deux VM ou plus réparties sur au moins deux zones | 99,99 % |
| App Service, niveau Basic ou supérieur (pas de SLA en Free) | 99,95 % |
| Blob Storage, niveau chaud, LRS (lecture et écriture) | 99,9 % |
| Azure Database for MySQL, niveau Burstable | 99,9 % |
| Azure Database for MySQL avec haute disponibilité redondante entre zones | Jusqu'à 99,99 % |
Convertir un SLA en temps d'arrêt (avec 730 heures par mois et 8 760 heures par an) : le temps d'arrêt toléré vaut (1 − SLA) × durée.
| SLA | Arrêt toléré par mois | Arrêt toléré par an |
|---|---|---|
| 99,5 % | 3 h 39 min | 43 h 48 min |
| 99,9 % | 43 min 48 s | 8 h 45 min 36 s |
| 99,95 % | 21 min 54 s | 4 h 22 min 48 s |
| 99,99 % | 4 min 23 s | 52 min 34 s |
Le calcul de disponibilité, la mesure de la disponibilité réelle et les « neuf » sont détaillés dans le cours Haute disponibilité.
Le SLA composite
Une application utilise plusieurs services. Si elle a besoin de tous pour fonctionner, ils sont en série : on multiplie leurs disponibilités (cours Haute disponibilité).
L'application de suivi des livraisons, telle que déployée aux chapitres 8 à 10, dépend d'App Service (99,95 %), de MySQL en Burstable (99,9 %) et de Blob Storage au niveau chaud (99,9 %) :
0,9995 × 0,999 × 0,999 = 0,9975 (arrondi), soit 99,75 %
Arrêt toléré : (1 − 0,9975019995) × 730 h ≈ 1 h 49 min par mois
Le SLA composite est plus faible que chacun des SLA. Pour l'améliorer, on renforce le maillon le plus faible : avec une base en haute disponibilité redondante entre zones (99,99 %), on obtient 0,9995 × 0,9999 × 0,999 ≈ 99,84 %, soit environ 1 h 10 min par mois.
Si l'on déploie deux copies complètes de l'application dans deux régions, capables chacune de servir seule, elles sont en parallèle : l'indisponibilité totale est le produit des indisponibilités. Avec deux copies à 99,75 % : 1 − (1 − 0,9975)² ≈ 99,9994 %. En pratique, il faut ajouter le service qui bascule le trafic d'une région à l'autre, avec son propre SLA, et répliquer les données entre les régions : c'est cher et complexe, réservé aux services vraiment critiques.
Concevoir pour la panne d'une zone
Pour qu'un service survive à la perte d'une zone de France Central :
- Plusieurs instances, dans plusieurs zones : deux VM au moins dans deux zones derrière un équilibreur de charge Standard redondant entre zones ; ou une application App Service en niveau Premium avec la redondance de zone activée, qui répartit ses instances.
- Une base redondante entre zones : Azure Database for MySQL en General Purpose ou Business Critical, avec la haute disponibilité redondante entre zones, choisie à la création du serveur. La bascule vers le serveur de secours est automatique.
- Un stockage ZRS (ou GZRS) pour les fichiers.
- Pas de ressource zonale isolée au milieu de la chaîne : une seule VM épinglée en zone 1 annule tout le reste.
Au-delà de la zone, la reprise dans une autre région se prépare avec Azure Site Recovery, qui réplique les VM vers une région de secours et orchestre la bascule, et avec la géo-réplication des bases et du stockage. Pour Sorbier, la région appairée France South est d'accès restreint : une reprise dans une autre région européenne, comme Germany West Central, est plus simple à obtenir, mais elle fait sortir les données de France. La décision doit être notée au registre des traitements et dans le PRA (cours Sauvegarde et PRA).
Sauvegarder dans le cloud
La redondance recopie aussi les erreurs : une table supprimée ou des fichiers chiffrés par un rançongiciel le sont sur toutes les copies. Seules des sauvegardes protègent, avec des points de restauration dans le passé.
| Ressource | Ce qu'offre Azure | Ce qui reste à faire |
|---|---|---|
| VM (IaaS) | Azure Backup : un coffre (Recovery Services vault), une stratégie quotidienne ou plus fréquente, une rétention, la restauration d'une VM entière, d'un disque ou de fichiers | L'activer, choisir la stratégie, tester la restauration |
| Azure Database for MySQL | Sauvegardes automatiques, 1 à 35 jours, restauration à un instant précis ; sauvegarde géo-redondante en option, choisie à la création | Fixer la rétention ; garder un export mysqldump hors d'Azure |
| Blob Storage | Suppression réversible, versionnage, restauration à un instant précis, stratégies d'immuabilité | Les activer (chapitre 8) |
| SaaS (Microsoft 365) | Corbeilles et rétention limitées dans le temps | Une vraie sauvegarde, par un service dédié ou un outil tiers (cours Sauvegarde et PRA) |
Les coffres Azure Backup gardent les sauvegardes supprimées pendant 14 jours par défaut (suppression réversible) et peuvent être rendus immuables, pour qu'un attaquant qui a pris un compte d'administration ne puisse pas effacer les sauvegardes avant de chiffrer la production.
La règle 3-2-1 s'applique au cloud (cours Sauvegarde et PRA) : trois copies, deux supports, une hors site. Pour l'application de suivi des livraisons, Sorbier garde :
- la base de production dans Azure ;
- les sauvegardes automatiques d'Azure, dans un autre stockage du fournisseur ;
- un export
mysqldumpquotidien, chiffré, rapatrié sur le NAS du siège, hors du fournisseur et hors de son compte : si le compte Azure est compromis ou fermé, cette copie survit.
Exercices
Exercice 1 sur 4 Convertir des SLA Réussi À revoir
Avec 730 heures par mois et 8 760 heures par an, calcule le temps d'arrêt toléré par mois et par an pour : 99,9 %, 99,95 % et 99,99 %. Puis dis si cette phrase est juste : « Avec un SLA de 99,99 %, le service ne peut pas être coupé plus de 53 minutes dans l'année. »
Voir la réponseMasquer la réponse de l'exercice 1
- 99,9 % : 0,001 × 730 h = 0,73 h = 43 min 48 s par mois ; 0,001 × 8 760 h = 8,76 h = 8 h 45 min 36 s par an.
- 99,95 % : 0,0005 × 730 h = 0,365 h = 21 min 54 s par mois ; 4,38 h = 4 h 22 min 48 s par an.
- 99,99 % : 0,0001 × 730 h = 0,073 h = 4 min 22,8 s par mois ; 0,876 h = 52 min 33,6 s par an.
La phrase est fausse. Le SLA est un engagement contractuel, pas une limite physique : la panne peut durer plus longtemps. Le fournisseur doit alors un avoir sur la facture, rien de plus. Le SLA d'Azure se mesure en plus par mois, pas sur l'année.
Tu avais trouvé ?
Exercice 2 sur 4 Le SLA composite de Sorbier Réussi À revoir
L'application de suivi des livraisons dépend d'App Service (99,95 %), d'Azure Database for MySQL en Burstable (99,9 %) et de Blob Storage au niveau chaud (99,9 %).
- Calcule le SLA composite et le temps d'arrêt toléré par mois.
- Quel composant améliorer en priorité, et comment ? Calcule le nouveau SLA composite si la base passe à 99,99 %.
- La direction exige « au moins 99,9 % » pour l'application. Les deux architectures conviennent-elles ?
Voir la réponseMasquer la réponse de l'exercice 2
- 0,9995 × 0,999 × 0,999 = 0,9975019995, soit 99,75 %. Arrêt toléré : 0,0024980005 × 730 h ≈ 1,82 h, soit 1 h 49 min par mois.
- Les maillons les plus faibles sont la base et le stockage (99,9 %). La base est la plus simple à renforcer : niveau General Purpose avec haute disponibilité redondante entre zones, ce qui impose de recréer le serveur (la haute disponibilité redondante entre zones se choisit à la création). Nouveau SLA : 0,9995 × 0,9999 × 0,999 ≈ 99,84 %, soit environ 1 h 10 min par mois.
- Non, aucune des deux : 99,75 % et 99,84 % sont sous 99,9 %. Il faudrait aussi renforcer le stockage et l'application (plusieurs instances, redondance de zone), ou une seconde région. Explique-le à la direction avec le coût de chaque option, plutôt que de promettre un chiffre que l'architecture ne tient pas.
Tu avais trouvé ?
Exercice 3 sur 4 Résister à la perte d'une zone Réussi À revoir
Aujourd'hui, l'application tourne sur une seule VM (zone non précisée), avec une base MySQL Burstable et un stockage LRS. Liste les changements nécessaires pour qu'elle survive à la perte d'une zone de France Central.
Voir la réponseMasquer la réponse de l'exercice 3
- Calcul : au moins deux instances dans deux zones différentes (deux VM zonales derrière un équilibreur de charge Standard redondant entre zones, ou App Service Premium avec redondance de zone).
- Base : passer en General Purpose avec haute disponibilité redondante entre zones (impossible en Burstable), donc créer un nouveau serveur et y restaurer les données.
- Stockage : passer le compte en ZRS (ou GZRS pour couvrir aussi une région).
- Vérifier qu'aucun autre élément de la chaîne n'est unique et zonal (passerelle, adresse IP publique, autre VM), et tester la bascule.
Tu avais trouvé ?
Exercice 4 sur 4 Le plan de sauvegarde Réussi À revoir
Propose les sauvegardes de l'application de suivi des livraisons (base MySQL, bons de livraison en Blob Storage, code de l'application) en respectant la règle 3-2-1. La direction accepte de perdre au plus 24 heures de données (RPO) et de rester au plus 8 heures sans service (RTO).
Voir la réponseMasquer la réponse de l'exercice 4
| Élément | Sauvegarde | Respecte |
|---|---|---|
| Base MySQL | Sauvegardes automatiques d'Azure, rétention 14 jours, restauration à un instant précis ; plus un mysqldump quotidien chiffré, copié sur le NAS du siège | RPO de quelques minutes avec Azure, 24 h avec l'export ; copie hors fournisseur |
| Bons de livraison | Suppression réversible et versionnage activés, compte en GRS (copie à Marseille) ; plus une copie hebdomadaire vers le stockage objet hors Azure, en compartiment immuable | Trois copies, deux fournisseurs, une copie immuable |
| Code | Dépôt Git hébergé (GitHub), avec un clone sur un serveur du siège ; l'application se redéploie en quelques minutes par le pipeline | Le code n'est pas une donnée à restaurer : il se redéploie |
Le RTO de 8 heures est tenable : restaurer la base dans Azure prend quelques dizaines de minutes, redéployer l'application aussi. Un test de restauration complet, au moins une fois par an, le prouve : note le temps réel (cours Sauvegarde et PRA).
Tu avais trouvé ?