Mettre au point un plan de continuité d’activité et reprise d’activité
Votre organisation vous demande de concevoir une stratégie de récupération de site pour vos applications. Tout d’abord, vous devez comprendre les exigences spécifiques de votre environnement hybride pour la récupération de site. Vous devez également savoir quels sont les outils Azure qui peuvent vous y aider.
Dans cette unité, vous apprenez à identifier les infrastructures clés, les objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO). Vous identifiez les exigences susceptibles de s’appliquer aux services PaaS (platform as a service) que vous comptez utiliser. Vous apprenez également à planifier la sauvegarde et la reprise d’activité. Enfin, vous découvrez certaines fonctionnalités Azure qui permettent de créer une solution de récupération de site.
Continuité d’activité et reprise d’activité
Vous devez développer un plan BCDR pour concevoir une solution de récupération de site appropriée. Le plan BCDR vous permet de restaurer vos applications à un état de fonctionnement après un événement important. Cet événement peut être une catastrophe naturelle comme un tremblement de terre. Il peut également s’agir d’un événement technique, comme la suppression d’une base de données. Ces événements ont généralement un impact beaucoup plus grand et nécessitent des efforts de récupération plus importants.
Pour concevoir un bon processus de reprise d’activité, vous devez d’abord évaluer le type d’impact que les défaillances éventuelles peuvent avoir sur l’entreprise. Il est conseillé d’automatiser autant que possible le processus de reprise d’activité. Inévitablement, certaines tâches de votre processus de reprise d’activité impliquent une intervention humaine, vous devez donc entièrement documenter le processus. Vous devez également simuler régulièrement des catastrophes pour que votre processus de reprise d’activité reste efficace.
Identifier l’infrastructure et les principales parties prenantes
Identifiez toutes les personnes qui ont besoin que vos applications restent fonctionnelles. Ces personnes peuvent être des utilisateurs externes ou internes. L’équipe du support technique et toutes les personnes chargées des entrées manuelles du processus BCDR sont des parties prenantes. Les autres applications et services qui s’appuient sur vos applications peuvent également être considérés comme des parties prenantes.
Identifiez l’infrastructure qui compose l’environnement de vos applications. Cette infrastructure comprend généralement les machines virtuelles (VM), les ressources réseau, les ressources de stockage et tout autre service fonctionnant avec ces ressources.
Identifier les objectifs de point de récupération et les objectifs de temps de récupération
Le RPO définit la perte de données acceptable pour votre application en cas de sinistre. Par exemple, si votre application est en panne, vous pouvez estimer qu’il n’est pas acceptable qu’elle s’exécute en s’appuyant sur des données datant de plus d’une demi-heure après la récupération. Certaines applications peuvent fonctionner avec des données plus anciennes, mais pour d’autres, il est essentiel de les exécuter avec des données les plus récentes possibles.
Le RTO est le temps d’arrêt maximal que votre application peut accepter. Par exemple, vous pourriez trouver inacceptable que votre application soit indisponible pendant plus de quatre heures en raison de la perte potentielle de productivité qui résulterait d’une interruption plus longue. Les applications critiques nécessitent un RTO plus court.
Les exigences contractuelles ou réglementaires peuvent souvent influencer le RPO et le RTO de votre application. Le RPO et le RTO peuvent également varier d’une application à l’autre. Les applications moins critiques peuvent avoir des valeurs plus élevées de RPO/RTO, alors que les applications vitales pour l’entreprise peuvent avoir une moins grande tolérance aux temps d’arrêt et à la perte de données. Vous calculez le RTO et le RPO en fonction de la compréhension qu’a votre organisation du risque et des coûts liés aux temps d’arrêt et à la perte de données.
Identifier les conditions de PaaS
Même si vous contrôlez le temps d’arrêt et la récupération des applications que vous gérez, vous pouvez ne pas avoir le même contrôle sur les services PaaS. Comme les services PaaS que vous utilisez peuvent avoir leurs propres garanties de disponibilité et leurs propres plans de récupération, vous devez en tenir compte dans votre plan BCDR.
Identifiez et inventoriez les services dont dépend votre entreprise, afin de pouvoir incorporer leurs fonctionnalités de récupération dans votre plan BCDR. Vous devez bien comprendre vos besoins et comment ils affectent le processus BCDR.
Azure Site Recovery
Azure Site Recovery est un service qui fournit des fonctionnalités BCDR pour vos applications locales et Azure, ainsi que pour vos applications issues d’autres fournisseurs cloud. Site Recovery a des plans qui vous aident à automatiser la reprise d’activité. Il vous permet de définir comment les machines sont basculées et l’ordre dans lequel elles sont redémarrées après le basculement. De cette façon, Site Recovery permet d’automatiser les tâches et de réduire votre RTO. Vous pouvez aussi utiliser Site Recovery pour tester régulièrement les basculements et l’efficacité générale du processus de récupération.
Sauvegardes de données
Les sauvegardes protègent les applications contre l’altération ou la suppression accidentelles des données. Les sauvegardes jouent un rôle important dans tout plan BCDR.
Votre RPO dépend de la fréquence et de la régularité d’exécution des processus de sauvegarde. Par exemple, si vous avez un processus de sauvegarde configuré pour s’exécuter toutes les deux heures et que vous subissez un sinistre cinq minutes avant la prochaine sauvegarde, vous perdrez une heure et 55 minutes de données. Plus les sauvegardes sont fréquentes, plus les RPO sont courts. Dans votre plan global, vous devez inclure un processus de sauvegarde détaillé.
Vous pouvez utiliser la Sauvegarde Azure comme processus de sauvegarde. Le service Sauvegarde Azure fournit une sauvegarde sécurisée pour toutes les ressources de données gérées par Azure. Il utilise des solutions sans infrastructure pour autoriser les sauvegardes et les restaurations en libre-service, avec une gestion à grande échelle dont le coût est prévisible.
La Sauvegarde Azure offre des solutions de sauvegarde spécialisées pour les machines virtuelles Azure et locales. La Sauvegarde Azure donne également aux charges de travail de type SQL Server ou SAP HANA exécutées sur des machines virtuelles Azure des options de sauvegarde et de restauration de niveau entreprise.
Les services Sauvegarde et Azure Site Recovery visent tous deux à rendre le système plus résilient aux pannes et aux défaillances. Toutefois, l’objectif premier de la Sauvegarde Azure est de gérer des copies de données avec état qui vous permettent de remonter dans le temps. Site Recovery réplique les données en quasi-temps réel et permet le basculement. En savoir plus sur la Sauvegarde Azure.
Fonctionnalités de résilience Azure
Azure est doté de plusieurs fonctionnalités qui garantissent la résilience de vos applications et de votre infrastructure. Les fonctionnalités de résilience Azure comprennent le jumelage des régions, les jeux de disponibilité et les zones de disponibilité.
Appairage des régions
Chaque région Azure est associée à une autre région. Dans une paire de régions, les régions ne sont jamais mises à jour en même temps. Elles le sont l’une après l’autre. Si quelque chose arrive à une région, l’autre région du jumelage devient disponible.
Ces paires de régions sont également utilisées pour la réplication. Les services de stockage et de nombreux services PaaS sont répliqués et ont un pair de basculement dans la région appairée. Dans le cadre de votre planification BCDR, vous devez utiliser l’appairage de région pour tirer parti de l’isolation qu’il fournit. Vous pouvez réduire le temps nécessaire à la récupération après une défaillance et augmentez votre disponibilité.
Groupes à haute disponibilité
Un groupe à haute disponibilité est une fonctionnalité de regroupement logique dans Azure. Vous pouvez placer des ressources VM dans un jeu de disponibilité pour vous assurer que ces ressources VM sont isolées les unes des autres lorsqu’elles sont déployées dans un centre de données Azure. Les groupes à haute disponibilité sont constitués de domaines de mise à jour et de domaines d’erreur.
Les domaines de mise à jour garantissent qu’une partie des serveurs de votre application continuent de s’exécuter si les hôtes VM d’un centre de données Azure doivent être arrêtés pour une maintenance. La plupart des mises à jour des hôtes VM peuvent être effectuées sans affecter les machines virtuelles qu’ils hébergent, mais il arrive que ce type de mise à jour ne soit pas possible.
Pour garantir que les mises à jour ne s’effectuent pas simultanément, le centre de données Azure est divisé de manière logique en domaines de mise à jour. Lorsqu’un événement de maintenance se produit, comme une mise à jour des performances et un correctif de sécurité critique qui doivent être appliqués à l’hôte, cet événement de maintenance est séquencé à travers les domaines de mise à jour. L’utilisation du séquencement par les domaines de mise à jour garantit que la totalité du centre de données n’est pas indisponible pendant l’application des mises à jour et correctifs de la plateforme.
Les domaines d’erreur représentent des sections physiques du centre de données et garantissent la diversité des racks de serveurs dans un groupe à haute disponibilité. Les domaines d’erreur correspondent à la séparation physique du matériel partagé au sein du centre de données. Cela inclut l’alimentation, le système de refroidissement et le matériel réseau qui prend en charge les serveurs physiques situés dans les racks de serveurs.
Si le matériel qui prend en charge un rack de serveurs devient indisponible, la panne affecte uniquement ce rack de serveurs. Quand vous placez vos machines virtuelles dans un groupe à haute disponibilité, elles sont automatiquement réparties sur plusieurs domaines d’erreur. Si une défaillance matérielle se produit, elle affecte uniquement certaines de vos machines virtuelles.
Zones de disponibilité
Les zones de disponibilité sont des emplacements de centre de données physiques indépendants au sein d’une région. Les zones de disponibilité comprennent leur propre puissance, leur propre refroidissement et leur propre réseau. Quand vous utilisez les zones de disponibilité pour le déploiement des ressources, vous pouvez protéger les charges de travail contre les pannes des centres de données et maintenir la présence dans une région.
Les services zonaux sont des services (comme les machines virtuelles) que vous pouvez déployer dans des zones spécifiques au sein d’une région. Les autres services sont des services redondants interzone qui sont répliqués dans les zones de disponibilité de la région Azure spécifique. Les deux types de service garantissent qu’il n’existe aucun point de défaillance unique dans une région Azure.
