Fonctionnement de la haute disponibilité et de la reprise après incident dans Code Engine

La haute disponibilitéLa capacité d'un service ou d'une charge de travail à résister aux défaillances et à continuer à fournir une capacité de traitement selon un niveau de service prédéfini. (HA) est la capacité d'un service à rester opérationnel et accessible malgré des défaillances inattendues. La reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception de haute disponibilité à le gérer. est le processus de rétablissement des opérations de service après une perturbation majeure.

Code Engine est un service régional hautement disponible conçu pour maintenir la disponibilité pendant les pannes zonales. Code Engine atteint les objectifs de niveau de service(SLO) avec le plan standard.

Pour plus d'informations sur les normes de haute disponibilité et de reprise après sinistre dans l' IBM Cloud, consultez l'article « Comment l' IBM Cloud garantit la haute disponibilité et la redondance ». Vous pouvez également trouver des informations sur Accords de niveau de service.

Disponibilité des instances Code Engine

IBM Cloud® Code Engine est proposé dans plusieurs lieux (régions). Chaque région contient trois centres de données (zones) pour la redondance.

Lorsque vous mettez à disposition un projet Code Engine, vous sélectionnez la région (MZR) dans laquelle l'instance est créée. La région détermine l'endroit où vos charges de travail (telles que les applications, les tâches, les fonctions et les flottes) sont hébergées.

Par défaut, votre charge de travail est déployée au sein d'une seule zone. En cas de défaillance de la zone d'hébergement, la charge de travail est automatiquement recréée dans l'une des zones restantes.

Le service effectue des déplacements contrôlés de la charge de travail entre les zones pendant les opérations normales, telles que la maintenance du service et les mises à niveau du logiciel. Ces redémarrages de déploiement sont effectués de manière gracieuse afin de minimiser les perturbations. Des basculements non planifiés peuvent se produire lors d'événements inattendus dans l'environnement opérationnel.

Code Engine stocke les métadonnées (y compris les définitions de projet, d'application, de fonction, de travail, de flotte et de construction d'image) et les réplique dans toutes les zones d'une région à des fins de disponibilité. En tant que service de calcul uniquement, Code Engine n'est pas responsable de la haute disponibilité des données de votre charge de travail ou des images de conteneurs. Consultez la documentation des services en nuage respectifs pour obtenir des conseils sur la façon d'assurer une haute disponibilité. Pour la disponibilité des images de conteneurs, suivez les conseils donnés dans IBM Cloud Container Registry pour vous assurer que votre charge de travail reste opérationnelle pendant une panne de zone. Si vous lisez ou stockez des données dans IBM Cloud Object Storage ou dans tout autre service de base de données ou de stockage IBM Cloud, reportez-vous à la documentation de chaque service pour connaître les caractéristiques de haute disponibilité.

Code Engine topologie régionale topologie régionale topologie régionale — Code Engine

Code Engine régions

Le tableau suivant répertorie les régions où Code Engine est disponible et leur état de haute disponibilité.

Régions hautement disponibles Code Engine
Zone géographique	Région	Haute disponibilité
Asie Pacifique	Australie, Sydney (`au-syd`)	Région multizone
Asie Pacifique	Inde, Chennai (`in-che`)	Région multizone
Asie Pacifique	Japon, Osaka (`jp-osa`)	Région multizone
Asie Pacifique	Japon, Tokyo (`jp-tok`)	Région multizone
Europe	Allemagne, Francfort (`eu-de`)	Région multizone
Europe	Espagne, Madrid (`eu-es`)	Région multizone
Europe	Royaume-Uni, Londres (`eu-gb`)	Région multizone
Amérique du Nord	Canada, Toronto (`ca-tor`)	Région multizone
Amérique du Nord	États-Unis, Dallas (`us-south`)	Région multizone
Amérique du Nord	États-Unis, Washington (`us-east`)	Région multizone
Amérique du Sud	Brésil, São Paulo (`br-sao`)	Région multizone

Une zone géographique est une zone géographique qui comprend une ou plusieurs régions. Chaque région comprend plusieurs zones de disponibilité afin de répondre aux exigences locales en matière d'accès, de faible latence et de sécurité. Chaque région multizone(MZR) se compose de 3 zones indépendantes ou plus, ce qui garantit qu'une défaillance n'affecte qu'une seule zone.

Reprise après incident pour les instances Code Engine

Lors d'une catastrophe régionale majeure – telle qu'un tremblement de terre, une inondation ou un phénomène météorologique extrême –, toute une région peut être touchée. Pour garantir la résilience de vos charges de travail face à de tels événements, déployez-les sur plusieurs MZR et mettez en place un mécanisme de basculement automatique à l'aide d'un service Edge Proxy. Par exemple, vous pouvez utiliser IBM Cloud® Internet Services. Pour plus d'informations sur le déploiement d'une application dans plusieurs régions, voir Déploiement d'une application dans plusieurs régions avec un nom de domaine personnalisé.

Code Engine topologie mondiale topologie mondiale topologie mondiale — Code Engine

Comment IBM aide à assurer la reprise après sinistre

Sauvegarde des instances Code Engine

IBM Cloud sauvegarde automatiquement les métadonnées du projet Code Engine et les stocke dans un espace de stockage interrégional à des fins de reprise après sinistre.

Critères d'évaluation interrégionaux
Région Code Engine	Noeud final interrégional
`au-syd`	`AP`
`br-sao`	`BR`
`ca-tor`	`CA`
`eu-de`	`EU`
`eu-es`	`EU`
`eu-gb`	`EU`
`jp-osa`	`AP`
`jp-tok`	`AP`
`us-east`	`US`
`us-south`	`US`

Pour éviter tout impact involontaire sur vos charges de travail - comme la duplication de tâches ou le déploiement d'instances d'applications non désirées - Code Engine ne restaure pas automatiquement vos charges de travail. Le rétablissement de vos charges de travail relève de votre responsabilité. Pour plus d'informations, reportez-vous à la rubrique décrivant vos responsabilités lors de l'utilisation de Code Engine.

Objectif de temps de récupération (RTO) et objectif de point de récupération (RPO)

L' objectif de temps de récupération (RTO) est le temps maximum acceptable pendant lequel un système, une application ou un processus d'entreprise peut être hors ligne avant d'avoir un impact significatif sur l'entreprise.
L' objectif de point de récupération (RPO) définit la quantité maximale acceptable de perte de données (mesurée en temps) après un événement HA ou DR.

IBM effectue régulièrement des tests HA/DR qui comprennent le basculement HA, des scénarios DR isolés (à l'exclusion des données appartenant au client et des définitions de charge de travail), la restauration des données et la simulation de paramètres non techniques.

Au cours de ces tests, les objectifs RTO (recovery time) et RPO (recovery point) sont mesurés et vérifiés.

Objectifs RTO/RPO
Objectif	Cible
Basculement automatique en cas de panne de la zone	RTO = secondes, RPO = 0
Reprise après sinistre, à l'exclusion de la récupération des objets appartenant au client	RTO = heures, RPO = 1 jour

Planification de la reprise après incident

En plus des tests HA/DR de IBM, vous devez pratiquer régulièrement vos procédures de reprise après sinistre. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec et les résolutions suivants.

Événements HA/DR et résolution
Evénement	Résolution
Défaillance matérielle (infrastructure informatique)	IBM fournit une infrastructure qui résiste aux pannes matérielles ponctuelles dans une zone - aucune configuration n'est requise.
défaillance de zone	Basculement automatique (voir Disponibilité des instances Code Engine ). La charge de travail est automatiquement déplacée vers une zone disponible.
Altération de données	Vous êtes responsable de la création de sauvegardes de vos données.
Défaillance régionale	Pas de basculement automatique. Comme décrit dans la section Reprise après sinistre pour les instances Code Engine, vous devez déployer votre charge de travail dans une deuxième région multizone.
Disponibilité de la charge de travail	Vous êtes responsable de la mise en œuvre de vos applications commerciales pour récupérer l'état d'un stockage externe ou d'une base de données.
Résilience HA/DR	Il vous incombe de veiller à ce qu'un personnel qualifié soit disponible pour gérer vos composants et restaurer vos charges de travail et les données appartenant au client pendant une panne.

Vos responsabilités en matière d'HA et de DR

Utilisez les listes de contrôle suivantes associées à chaque caractéristique pour vous aider à créer et à mettre en pratique votre plan.

Images de conteneurs utilisées pour IBM Cloud® Code Engine apps, jobs et flottes

Vérifiez que vos images de conteneurs sont disponibles dans votre région de sauvegarde IBM Cloud Container Registry.
Les faisceaux de codes utilisés pour les fonctions de IBM Cloud® Code Engine

Vérifiez que vos paquets de codes sont disponibles dans votre région de sauvegarde IBM Cloud Container Registry.

Un plan de test complet de haute disponibilité (HA) et de reprise après sinistre (DR) comprend la définition des objectifs RTO et RPO, l'identification des systèmes critiques et la validation de l'intégrité des sauvegardes, du basculement du réseau et de la synchronisation des données. Les étapes clés consistent à simuler des défaillances (telles qu'une défaillance de nœud ou une panne de site), à exécuter des procédures de basculement, à vérifier le fonctionnement du système et à documenter le processus de repli.

Préparation
- Définir les objectifs: Confirmez votre objectif de temps de récupération (RTO) et votre objectif de point de récupération (RPO).
- Identifier les systèmes critiques: Dressez la liste de tous les systèmes, données et applications qui nécessitent un basculement.
- Établir les rôles de l'équipe: Définir les responsabilités de l'équipe DR et désigner une personne de contact clé.
- Vérification des sauvegardes: Confirmer que les sauvegardes sont valides et accessibles.
- Isolation de l'environnement: Isoler les systèmes d'essai pour éviter tout impact accidentel sur les environnements de production.
Exécution des tests
- Simuler un scénario de défaillance: initier une défaillance planifiée, telle que la coupure de la connectivité réseau, l'arrêt d'un service ou l'arrêt d'un serveur primaire.
- Exécution du basculement: Exécuter la procédure de basculement documentée vers le site secondaire/DR.
- Vérifier l'intégrité des données: Utilisez des sommes de contrôle ou des valeurs de hachage pour vous assurer que les données ne sont pas corrompues.
- Validation des applications: Tester la fonctionnalité des applications sur le site DR.
- DNS/Routage du trafic: Valider que le trafic des utilisateurs est redirigé vers le nouveau nœud actif.
Post-test et documentation
- Effectuer une reprise sur panne: Remettre le site primaire en ligne et resynchroniser les données.
- Documenter les résultats: Enregistrez les délais, les réussites et tout écart par rapport au plan.
- Identifier les lacunes: Identifier les lacunes du plan et mettre à jour les procédures en conséquence.
- Audit de communication: Vérifier que les notifications ont été envoyées à toutes les parties prenantes.
Scénarios de test courants
- Test HA: Basculement local vers un nœud de secours (par exemple, dans le même centre de données).
- Test DR: Basculement complet vers un site géographiquement séparé.
- Restauration des données: Restauration complète des données appartenant au client et des artefacts de charge de travail à partir d'un datastore de sauvegarde vers l'emplacement principal ou l'emplacement de sauvegarde sélectionné.
- Disponibilité du personnel: Testez l'impact opérationnel si le personnel clé est indisponible ou incapable de se connecter à vos systèmes.