Planifier et concevoir un plan qui n'est pas prêt pour la production

La capacité de l'infrastructure DR doit pouvoir gérer les charges de travail de production, à moins que votre plan n'en décide autrement. La mise en œuvre d'un système de reprise après sinistre avec des ressources qui ne correspondent pas à votre environnement de production peut sembler intéressante du point de vue des coûts, mais elle peut rendre les effets d'un sinistre beaucoup plus graves.

Lorsque vous planifiez et mettez en œuvre votre environnement de reprise après sinistre, tenez compte de ses propres exigences en matière de résilience. N'essayez pas de réduire les coûts en diminuant les exigences de haute disponibilité de la mise en œuvre du DR. En cas de sinistre, les charges de travail de production ont besoin d'un environnement résilient. Les services en nuage sont évolutifs, ce qui permet d'augmenter la capacité ultérieurement, mais l'augmentation de la demande régionale provoquée par la catastrophe peut entraîner des pénuries de capacité à court terme.

Oublier les points de défaillance uniques non techniques

Les points de défaillance uniques (SPOF) peuvent se trouver n'importe où dans une solution, et pas seulement dans la technologie. Votre solution peut dépendre de personnes, de fournisseurs, de fournisseurs et d'autres dépendances externes. Identifiez clairement vos SPOF et atténuez vos dépendances. Soyez prêt à reconnaître les ressources SPOF lors des premières sessions de votre Test de reprise après incident.

Parmi les SPOF, le risque fournisseur est une condition à prendre en compte dans votre plan de reprise après sinistre. Lorsque vous avez à la fois la production et le DR chez le même fournisseur, votre condition de risque est accrue et doit être soigneusement examinée.

N'avoir qu'un plan A

Les catastrophes peuvent prendre de nombreuses formes, de sorte que la planification d'un scénario de catastrophe spécifique vous rend vulnérable à d'autres scénarios. Lors de la conception du plan de secours, envisagez plusieurs scénarios de catastrophe différents et démontrez la flexibilité du plan.

Tester votre plan de manière inadéquate

Une solution de DR non testée augmente les risques de rencontrer un obstacle au moment où le succès est le plus critique. Les essais sont essentiels pour s'assurer que la solution fonctionne. Les conditions que vous testez sont également importantes et nécessitent la création de plusieurs scénarios de test.

L'exécution d'un test de reprise après sinistre en procédant à un arrêt planifié des opérations sur un site et à un redémarrage bien organisé sur l'autre site vous permet de vous assurer que votre test de reprise après sinistre fonctionne. Cependant, un simple arrêt complet ne se produit pas toujours en cas d'urgence réelle.

Concevez vos tests de manière à reproduire le plus fidèlement possible les conditions d'urgence potentielles en simulant une "situation de catastrophe évolutive", dans laquelle votre charge de travail est progressivement affectée par la situation d'urgence. L'impact progressif teste la résilience de votre solution et donne un aperçu de votre capacité à résister aux conditions de stress.

Haute disponibilité

La haute disponibilité n'est pas synonyme de reprise après sinistre. IBM Cloud recommande aux clients de vérifier que leurs déploiements sont hautement disponibles, en tirant parti des régions multizones (MZR) de IBM Cloud. Chaque MZR comporte au minimum trois zones, qui sont des centres de données hautement interconnectés, mais séparés sur le plan opérationnel. Souvent, les problèmes et les pannes n'affectent qu'une seule zone, et non l'ensemble de la région. Le déploiement par défaut des charges de travail dans toutes les zones d'un MZR peut réduire les temps d'arrêt et la nécessité de déclencher un sinistre. Le basculement vers une deuxième région peut être un processus important, tout comme le retour, aussi faut-il prendre autant de mesures que possible pour éviter d'avoir à le faire. Cependant, les MZR n'empêchent pas les catastrophes telles que l'altération des données ou les dommages malveillants.

Réglementation et conformité

Certaines charges de travail et données sont soumises à des réglementations sectorielles strictes et à des normes de conformité, ce qui peut affecter l'emplacement physique dans lequel elles peuvent être exécutées ou stockées. Lorsque vous choisissez l'emplacement d'un site de reprise après sinistre, vérifiez que la région choisie répond à toutes les réglementations et à tous les critères de conformité nécessaires. Les emplacements où vous choisissez de répliquer les données doivent également être vérifiés.

Les buckets Object Storage interrégionaux permettent de répliquer les données dans différentes régions, mais à utiliser avec précaution si vos données sont soumises à des restrictions territoriales. Vérifiez que vos données ne sont pas transférées vers une région située dans un pays ou un territoire qui enfreint les règles de conformité de l'organisation ou de l'industrie.

Capacité dans la région de reprise après sinistre

Les catastrophes peuvent toucher de nombreux clients, qui mettent alors en œuvre leurs plans de reprise après sinistre. La demande supplémentaire pourrait mettre à rude épreuve la capacité d'une ou de plusieurs des régions les plus proches de la région défaillante. Cela pourrait entraîner une pénurie des ressources disponibles. Par exemple, si le site us-south tombe en panne, il est probable que de nombreux clients choisiront de récupérer d'abord dans la région us-east. Si eu-gb échoue, on s'attend à ce que davantage de demandes soient adressées à eu-de.

En cas de forte demande due à une catastrophe, il se peut que votre premier choix d'infrastructure ne soit pas disponible dans votre région de reprise. Cela inclut les profils VPC VSI les plus courants. Veillez à prendre en considération les différentes architectures de votre application qui peuvent tenir compte des situations dans lesquelles un profil VSI alternatif est nécessaire. Si votre application ne peut tolérer l'utilisation d'une infrastructure alternative, envisagez de construire ou de réserver autant de capacité que nécessaire dans la région de reprise d'activité de votre choix en prévision d'un sinistre, ou envisagez d'autres sites plus éloignés pour éviter les problèmes de capacité.

Vérifiez que vos sauvegardes peuvent être restaurées dans la région choisie. Par exemple, les bases de données ne peuvent pas être restaurées dans des régions qui dépassent les limites de conformité. Dans le cadre des bonnes pratiques, veillez à tester le délai de restauration de vos données et tenez compte du fait que ce délai pourrait être prolongé en cas de catastrophe majeure affectant une région entière, car de nombreux clients essaieront de restaurer leurs données en même temps.

Connectivité

L'approvisionnement et la configuration des services de mise en réseau peuvent prendre un certain temps, car ils peuvent nécessiter l'intervention d'un tiers ou l'installation d'une infrastructure physique. Lorsque vous élaborez un plan de reprise après sinistre, tenez compte des délais de mise en œuvre de ces services. Il est préférable de prévoir ces services à l'avance :

• Direct Link Transit Gateway Local et Global Transit Gateway
• VPC Edge
• Passerelle VPN et connexions
• DNS privé avec configuration VPC de DNS Hub & Spoke
• VPE pour les services partagés
• Règles de restriction basées sur le contexte
• Équilibreur de charge global sur DNS privé
• CIS avec Public LBaaS, VPE Private Path et PPNLB

Tirez parti de l'architecture déployable et de l'architecture de référence FS Cloud VPC landing zone et l'architecture de référence FS Cloud pour préparer votre connectivité à l'avance ou lors d'une reprise après sinistre.

Basculement partiel ou total

Le nuage est composé de différents services, et les applications peuvent s'appuyer sur plusieurs composants qui fonctionnent ensemble. Les plans de reprise après sinistre se préparent généralement à des défaillances catastrophiques au niveau régional et partent du principe que tous les services de la région sont perdus. Toutefois, des interruptions de service isolées peuvent se produire sans affecter les autres services de la région.

Dans ce cas, il est essentiel de déterminer si un basculement complet vers une autre région est nécessaire ou si seul le composant défaillant doit être traité.

Par exemple, si un service de base de données subit une défaillance catastrophique, devez-vous faire basculer l'ensemble de la charge de travail, y compris les services web ? Ou bien les autres composants peuvent-ils facilement basculer vers une base de données de secours en lecture réplique située dans une autre région ?

La facilité de gestion de ces scénarios dépend de la manière dont votre charge de travail est conçue et configurée. Évitez de coder en dur les noms des services et veillez à ce que votre architecture prenne en compte des facteurs tels que la latence du réseau afin de permettre des transitions en douceur en cas d'interruptions partielles.

Failback

Un autre élément à prendre en compte est la position de reprise après sinistre. La procédure de reprise est documentée dans le plan de reprise après sinistre. Les considérations relatives à la reprise après sinistre sont les suivantes :

• Le système est-il défaillant ou continue-t-il à fonctionner normalement sur le site de récupération ?
• Si la reprise sur panne est obligatoire, quand la tentez-vous ?
• Comment la reprise sur incident fonctionne-t-elle pour limiter autant que possible les perturbations ultérieures ?

La reprise après sinistre peut être aussi compliquée et perturbante qu'un sinistre, c'est pourquoi il convient de se demander si la reprise après sinistre est vraiment nécessaire. Au lieu de cela, les services peuvent-ils continuer à fonctionner sur le deuxième site ? Le moment de la reprise est également important. Vous devez vous assurer que les circonstances à l'origine du sinistre sont résolues et que la reprise n'entraîne pas de perturbations prolongées.

Que vous mettiez en œuvre un failback ou non, la provision DR doit être recréée ou réinitialisée.