Description de la haute disponibilité et de la reprise après incident pour IBM Cloud VPC
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 en cas de défaillance inattendue. 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 de l'instance de service dans un état opérationnel.
IBM Cloud® Virtual Private Cloud est un service hautement disponible conçu pour répondre aux objectifs de niveau de service(SLO). Il est composé de services zonaux et régionaux.
Pour plus d'informations sur les régions et les centres de données disponibles, voir Disponibilité des services et de l'infrastructure par région.
Architecture à haute disponibilité
Les ressources VPC sont divisées en services de plan de contrôle et de plan de données pour permettre aux clients de créer des applications hautement disponibles sur le VPC. Le plan de contrôle permet d'approvisionner et de gérer les ressources VPC (création, mise à jour, suppression) et de fournir des fonctions de contrôle. Le plan de données est la collection de ressources VPC provisionnées telles que les instances de serveurs virtuels, les adresses IP flottantes, les groupes de sécurité, le stockage en bloc, etc.
Le plan de contrôle est hébergé sur du matériel redondant entre les zones, ce qui permet de pallier les défaillances matérielles et zonales. Le plan de contrôle et le plan de données se trouvent dans des domaines de défaillance différents. Par exemple, une panne du plan de contrôle n'a pas d'incidence sur la disponibilité du plan de données. Toutes les ressources existantes des clients continuent à fonctionner sans aucun impact. Pour une résilience accrue, les utilisateurs peuvent créer des applications à partir de ressources redondantes du plan de données.
Les ressources VPC sont classées en ressources zonales et en ressources régionales en fonction de leur portée. Certaines ressources, comme les VPC, s'étendent sur plusieurs zones et sont considérées comme des ressources régionales. La plupart des ressources sont délimitées par zone et sont disponibles dans une zone spécifique. Par exemple, les sous-réseaux, les listes de contrôle d'accès, les groupes de sécurité, les tables de routage, les passerelles publiques et les passerelles Virtual Private Endpoint existent dans la zone où ils ont été créés.
Pour plus d'informations sur la protection du plan de données contre les défaillances du plan de contrôle, l'indépendance des services zonaux et la redondance des services régionaux, voir IBM Cloud service architecture for high availability and resiliency.
défaillance de zone
Si une défaillance complète de la zone se produit, le plan de contrôle et le plan de données sont tous deux affectés sur la zone. Les fonctions de contrôle dans les zones concernées ne sont pas disponibles et toutes les ressources zonales sont hors service. Par exemple, les instances de serveurs virtuels de la zone affectée sont indisponibles et ne sont pas déplacées vers une autre zone saine. Les modifications apportées aux ressources régionales ne prennent pas effet sur la zone défaillante tant que celle-ci n'est pas rétablie.
Le plan de données dans les autres zones n'est pas affecté et toutes les ressources zonales dans les zones non affectées continuent à fonctionner sans interruption. Les ressources régionales telles que le VPC continuent de fonctionner sur les zones saines. Le plan de contrôle est hautement disponible et permet aux services de gérer les ressources dans les autres zones non affectées.
Les clients doivent développer des mécanismes pour gérer la haute disponibilité de leurs applications en répartissant les ressources entre les zones (domaines de défaillance) et planifier la reprise après sinistre.
Défaillance régionale
Dans le cas inhabituel d'un désastre régional, tous les problèmes sous-jacents sont résolus et le plan de contrôle du VPC est restauré en se concentrant sur la réduction de la perte de données pour les ressources. Le plan de données est également restauré en récupérant l'état des données du client à partir du stockage, dans le but de respecter l'objectif de point de récupération (RPO) et l'objectif de délai de récupération (RTO).
Dans une région multizone à campus unique (SC-MZR), le sinistre d'un centre de données peut avoir des répercussions sur l'ensemble de la région, car les zones sont plus étroitement liées. Les services doivent utiliser des stratégies de sauvegarde et de récupération pour une autre ZIM afin d'éviter la perte de données.
Défaillances matérielles
Les ressources sont fournies par du matériel fiable et souvent redondant, mais une défaillance imprévue du matériel peut mettre ces ressources hors service. Par exemple, une instance de serveur virtuel peut tomber en panne lorsque le matériel
sous-jacent tombe en panne. Dans cette situation, la politique de reprise après défaillance de l'hôte détermine la manière dont le serveur virtuel est récupéré. Si la panne
survient et que la stratégie de reprise sur panne d'hôte est définie sur le paramètre par défaut, restart, le plan de contrôle détecte la panne matérielle et migre le serveur virtuel vers le matériel disponible dans la même
zone, puis redémarre le serveur virtuel. Le stockage sur disque éphémère n'est pas restauré sur le volume de démarrage. Les volumes de données sont disponibles, mais il peut manquer des écritures de cache d'application ou de système d'exploitation
qui ne sont pas sauvegardées au moment de la panne.
Les volumes de blocs sont soutenus par du matériel redondant avec des techniques de réplication avancées pour améliorer la résilience. Toutefois, un sinistre de zone ou une défaillance de plusieurs matériels peut entraîner la défaillance d'un volume de blocs. La sauvegarde et la restauration constituent une approche appropriée pour atténuer la perte ou la corruption de données. Cette approche peut également être utilisée pour atténuer les effets d'un désastre régional en répliquant les données dans d'autres régions IBM Cloud. La fonction d'instantané peut être utilisée pour prendre en charge la sauvegarde et la restauration. Les clients peuvent également répartir leurs applications sur d'autres zones afin d'éviter toute interruption et d'améliorer le RPO/RTO.
Il peut exister une forte corrélation entre le stockage des volumes et la défaillance de l'application serveur associée. Veillez à examiner et à tester les charges de travail afin de déterminer le comportement de l'application en présence d'un périphérique de stockage défaillant.
Pour plus d'informations sur les serveurs bare metal et le stockage qui leur est associé, voir Présentation du stockage sur Bare Metal Servers for VPC. Les instantanés ne sont pas disponibles pour les disques locaux sur les serveurs bare metal. Les clients doivent gérer la haute disponibilité et la reprise après sinistre de ces appareils.
Création d'applications HA
Vous pouvez utiliser un équilibreur de charge VPC pour distribuer les requêtes entrantes à plusieurs serveurs virtuels et serveurs métalliques nus. Les serveurs virtuels et les serveurs "bare metal" qui deviennent indisponibles cessent de répondre aux contrôles de santé; l'équilibreur de charge répartit alors la charge sur les ressources disponibles. Vous pouvez utiliser un équilibreur de charge d'application (ALB) pour distribuer le trafic d'une charge de travail aux serveurs virtuels dans plusieurs zones et pour créer des charges de travail qui sont disponibles même lorsqu'une zone entière devient indisponible.
Lorsque l'ALB lui-même est configuré sur des sous-réseaux à travers des zones, il est résistant à une défaillance d'une seule zone. Le Network Load Balancer est un service zonal distribué sur plusieurs serveurs virtuels sous-jacents et résistant à la défaillance d'un seul serveur virtuel.
La stratégie de base pour améliorer la disponibilité des charges de travail construites à partir de ressources VPC consiste à répartir la charge de travail sur plusieurs ressources. Il est possible de distribuer les ressources à l'intérieur d'une zone, entre plusieurs zones dans une région multizone (MZR) ou entre plusieurs régions. Pour plus d'informations, voir Déployer des charges de travail isolées sur plusieurs sites et zones; cette stratégie utilise IBM Cloud Internet Services (CIS) et un équilibreur de charge global.
Fonctions de haute disponibilité
IBM Cloud VPC prend en charge les fonctions de haute disponibilité suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Equilibreur de charge d'application | Un ALB répartit la charge entre les zones et les adresses IP. | La charge de travail doit être évolutive. |
| Equilibreur de charge réseau | Un NLB distribue la charge aux adresses IP au sein d'une zone. | La charge de travail doit être évolutive. |
| Mise à l'échelle automatique pour VPC | Améliorez les performances et les coûts en créant dynamiquement des instances de serveurs virtuels pour répondre aux exigences de votre environnement. | La charge de travail doit être évolutive. |
| Équilibreur de charge et groupe d'instances | Les charges de travail évolutives qui sont gérées par un équilibreur de charge répartissent la charge entre plusieurs instances dans différentes zones. | La charge de travail doit être évolutive. |
En tant que client, vous pouvez créer et soutenir l'AH :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Charge de travail évolutive | Créez un serveur virtuel ou une charge de travail basée sur un serveur nu qui peut être mis à l'échelle horizontalement avec davantage de serveurs. | Toutes les charges de travail ne peuvent pas être mises à l'échelle horizontalement. |
Charge de travail évolutive
Les charges de travail évolutives peuvent répondre à une demande accrue en ajoutant des serveurs qui exécutent la même image. La charge de travail évolutive peut être mise en œuvre à l'aide de répartiteurs de charge et d'Auto Scale for VPC.
Architecture de reprise après sinistre
La stratégie de reprise après sinistre consiste à automatiser l'écriture de scripts pour restaurer une charge de travail VPC dans un emplacement de reprise. Par exemple, lorsqu'une région devient indisponible, il incombe au client de migrer la charge de travail et les données associées vers une région disponible. IBM prend en charge le système d'infrastructure en tant que code Terraform, qui peut être utilisé pour définir des charges de travail avec des emplacements et des performances paramétrés. L'API, le SDK et le CLI VPC peuvent être utilisés par les clients pour créer des scripts de récupération des ressources dans un emplacement disponible en cas de sinistre. Pour plus d'informations, voir Planification de la reprise après sinistre.
Pour en savoir plus sur l'utilisation de IBM Cloud Object Storage, IBM Cloud Schematics qui fournit Terraform-as-a-Service, et les architectures déployables, voir Utilisation des services IBM Cloud dans votre reprise après sinistre.
Fonctionnalités de reprise après sinistre
IBM Cloud VPC prend en charge les fonctions de reprise après sinistre suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Instantanés d'un seul volume | Un instantané est une copie ponctuelle de votre volume de démarrage ou de données. Block Storage les instantanés sont stockés dans l'instance régionale Cloud Object Storage. | Un instantané est indépendant de son volume source. Si la zone du volume source n'est pas disponible, l'instantané peut être utilisé pour créer un nouveau volume dans une autre zone de la région. Les instantanés peuvent être créés à la demande dans la console, à partir du CLI, avec l'API ou Terraform. Elles peuvent également être planifiées à l'aide du service Backup for VPC. |
| Copies instantanées interrégionales | Vous pouvez utiliser des copies de clichés interrégionales indépendantes de leurs clichés sources pour créer de nouveaux volumes. | Les instantanés peuvent être copiés dans une autre région manuellement dans la console, à partir de l'interface de programmation, ou par programmation avec l'API ou Terraform. Vous pouvez également inclure la création d'une copie dans une autre région dans votre politique de sauvegarde. |
| Instantanés du groupe de cohérence | Un groupe de cohérence d'instantanés contient des instantanés de plusieurs volumes Block Storage attachés à la même instance de serveur virtuel. | Lorsque vous demandez un instantané d'un groupe de cohérence, le système génère des instantanés de tous les volumes Block Storage étiquetés qui sont attachés à l'instance de serveur virtuel en même temps. Vous pouvez inclure ou exclure des volumes de démarrage. Le stockage de l'instance n'est pas inclus. |
| Restauration rapide d'instantanés | Les instantanés de restauration rapide sont des instantanés mis en cache dans la zone du volume de blocs parent. Lorsque vous créez un serveur virtuel avec un snapshot de restauration rapide amorçable, le serveur devient pleinement opérationnel plus rapidement que lorsque vous approvisionnez son volume d'amorçage à partir d'un snapshot normal. | |
| Réplication de fichiers partagés | Si le partage source devient indisponible, vous pouvez lancer un basculement de réplication vers le partage réplique. | Vous pouvez créer un partage réplique dans une autre zone de la même région. Vous pouvez également créer une réplique dans une autre région de la même zone géographique. Vous pouvez répliquer vos données toutes les 15 minutes. |
La restauration d'un volume ou d'un partage à partir d'un instantané est une opération manuelle qui prend du temps. Si vous avez besoin d'un niveau de service plus élevé pour la reprise après sinistre, consultez les services de sauvegarde et de reprise d'activité sur le site IBM Cloud.
En tant que client, vous pouvez créer et prendre en charge des options supplémentaires de reprise après sinistre :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Source externe de vérité pour la configuration du VPC | Construction d'un VPC, d'un réseau et de serveurs capturés dans des fichiers de configuration gérés par le client, tels que des scripts Terraform, des scripts shell ou des programmes. | Le client doit créer le script et conserver la configuration à un endroit où elle pourra être utilisée en cas de sinistre. |
| Scripts créés par le client pour la sauvegarde et la copie du stockage des fichiers | Copier le contenu d'un fichier partagé pour le rendre disponible à un autre endroit. | Le client doit créer le script ou utiliser une sauvegarde et une restauration continues gérées par le client. |
| Sauvegarde et restauration continues gérées par le client pour les volumes de blocs et le stockage de fichiers | Les clients peuvent installer des agents tiers et des pilotes de système d'exploitation sur les serveurs qui s'intègrent aux systèmes de sauvegarde et de restauration tels que Veeam. | Le client doit installer et gérer la solution de sauvegarde et de récupération de tiers. |
Planification de la reprise après incident
Les étapes de la reprise après sinistre doivent être pratiquées régulièrement. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec et les résolutions suivants.
| Echec | Résolution |
|---|---|
| Échec du volume d'amorçage | Vous pouvez créer un nouveau volume à partir d'une image personnalisée que vous avez créée à partir de votre volume. Vous pouvez également restaurer un volume à partir d'un instantané dans la console, à partir de l'interface de commande, avec l'API, Terraform ou en utilisant une solution de sauvegarde et de restauration continues gérée par le client. Lorsque vous restaurez un volume de démarrage à partir d'un instantané, attendez-vous à une certaine dégradation des performances pendant que les données sont copiées sur le volume de démarrage à partir de l'instantané. L'utilisation d' instantanés de restauration rapide permet d'atteindre les objectifs de temps de récupérationDans le cadre de la planification de la reprise après sinistre, le temps nécessaire à la restauration d'un processus d'entreprise après un sinistre. (RTO) plus rapidement qu'avec une restauration à partir d'un instantané normal, car toutes les données sont disponibles et les performances ne sont pas affectées. |
| Défaillance du volume de données ou corruption des données | Restaurez un volume à partir d'un instantané dans la console, à partir du CLI, avec l'API, Terraform, ou en utilisant une solution de sauvegarde et de restauration continue gérée par le client. Des instantanés de restauration rapide sont également disponibles pour les volumes de données. |
| Corruption des données de partage de fichiers | Vous pouvez créer des instantanés de partage de fichiers pour conserver les données sur votre partage de fichiers à un moment précis. Vous pouvez ainsi restaurer les données d'un instantané de partage de fichiers si le contenu du partage de fichiers est accidentellement supprimé ou écrasé. |
| Échec du partage de fichiers | Atténué en initiant un basculement vers une réplique existante dans une autre zone. Testez le processus de basculement pour voir combien de temps il prend. |
| Défaillance d'un serveur virtuel | Atténué par l'utilisation des fonctions de haute disponibilité d'un équilibreur de charge et d'Auto Scale pour VPC, créant ainsi une charge de travail évolutive. Un redémarrage du serveur virtuel peut être nécessaire. La résolution des défaillances des volumes de blocs peut être nécessaire. |
| Défaillance d'un serveur bare metal | Solution de sauvegarde et de restauration gérée par le client. |
| défaillance de zone | Atténué par l'utilisation des fonctions de haute disponibilité d'un équilibreur de charge et d'Auto Scale pour VPC, créant ainsi une charge de travail évolutive. Utilisez une source externe de vérité pour la configuration de la zone VPC afin de créer des ressources dans une zone disponible en utilisant la résolution des pannes de serveur et la résolution des pannes de volume de blocs. |
| Défaillance régionale | Utiliser une source externe de vérité pour la configuration de la région VPC afin de créer des ressources dans une région disponible. Restaurer les volumes et le stockage des fichiers aux valeurs antérieures en utilisant la résolution des pannes de serveur. |
Vos responsabilités en matière de haute disponibilité et de reprise après sinistre
Pour en savoir plus, consultez la rubrique " Comprendre vos responsabilités lors de l'utilisation d'un nuage privé virtuel". Il est de votre responsabilité de tester en permanence votre plan d'HA et de DR. Pour plus d'informations, voir Test de reprise après sinistre.
Des interruptions de la connectivité du réseau et de courtes périodes d'indisponibilité d'un service peuvent se produire. Il est de votre responsabilité de vous assurer que le code source de l'application inclut une logique de relance de la disponibilité du client afin de maintenir la haute disponibilité de l'application.
Vous pouvez utiliser les listes de contrôle suivantes pour vous aider à créer et à mettre en pratique votre plan.
-
Instantané d'un volume de blocs
-
Réplication du stockage de fichiers
-
Source externe de vérité pour la configuration du VPC
Gestion des modifications
La gestion des modifications comprend des tâches telles que les mises à niveau, les changements de configuration et la suppression.
Attribuer aux utilisateurs et aux processus les rôles et les actions IAM avec le moins de privilèges possibles pour leur travail. Pour plus d'informations, voir Comment empêcher la suppression accidentelle de services?
Envisagez de créer une sauvegarde manuelle avant de modifier les configurations de l'infrastructure.
Comment IBM® aide à soutenir la planification de la reprise après sinistre
IBM® prend des mesures de récupération spécifiques pour IBM Cloud VPC en cas de catastrophe.
En cas de défaillance inattendue d'un seul hôte, les serveurs virtuels de l'hôte défaillant peuvent être automatiquement redémarrés sur un hôte sain. Pour plus d'informations sur la façon dont IBM surveille l'infrastructure et répond aux défaillances des hôtes, voir Stratégies de reprise sur défaillance des hôtes.
Comment IBM récupère les défaillances de zones
Les pannes de zone peuvent résulter de catastrophes naturelles, de problèmes d'infrastructure tels qu'une panne d'électricité, d'actions accidentelles ou malveillantes qui suppriment des informations, ou de de mises à jour logicielles contenant un bogue ou une erreur. En cas de défaillance d'une zone, IBM s'efforce de récupérer les installations et les centres de données, le réseau physique et les dispositifs, stockage physique, serveurs physiques et mémoire, et hyperviseurs. Pour plus d'informations, voir Partage des responsabilités pour l'utilisation des produits IBM Cloud.
Comment IBM se remet des échecs régionaux
Dans le cas où une région entière connaîtrait une défaillance, IBM s'efforce à nouveau de récupérer les installations et les centres de données, le réseau physique et les appareils, le stockage physique, les serveurs physiques et la mémoire, et les hyperviseurs, les serveurs physiques et la mémoire, ainsi que les hyperviseurs. Pour plus d'informations, voir Responsabilités partagées pour l'utilisation des produits IBM Cloud et FAQ sur la reprise après sinistre.
Si IBM ne peut pas restaurer l'instance de service, vous devez restaurer le service comme décrit dans l'architecture de reprise après sinistre.
Comment IBM maintient les services
Lorsque la maintenance de routine est effectuée sur les serveurs virtuels, les hôtes et les centres de données, les protocoles de routine sont suivis. Pour plus d'informations, voir Présentation des opérations de maintenance de cloud.
Toutes les mises à niveau suivent les meilleures pratiques du service IBM, y compris les plans de reprise et les processus de retour en arrière. La maintenance régulière peut entraîner de brèves interruptions, atténuées par la logique de relance de la disponibilité du client. Les modifications sont déployées de manière séquentielle, région par région, et zone par zone à l'intérieur d'une région. IBM annule les mises à jour au premier signe de défaut.
Les modifications complexes sont activées et désactivées à l'aide d'indicateurs de caractéristiques afin de contrôler l'exposition.
Les changements qui ont un impact sur les charges de travail des clients sont détaillés dans les notifications IBM Cloud. Pour plus d'informations sur la maintenance planifiée, les annonces et les notes de version qui ont un impact sur ce service, voir Surveillance des notifications et de l'état.