Comprendre la haute disponibilité et la reprise après incident pour Red Hat OpenShift on IBM Cloud
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.
Red Hat OpenShift on IBM Cloud est un service régional ou zonal hautement disponible, conçu pour être disponible pendant une panne régionale ou zonale. Red Hat OpenShift on IBM Cloud est conçu pour atteindre les objectifs de niveau de service (SLO) avec le plan standard.
Pour plus d'informations sur les régions et les centres de données disponibles, consultez la rubrique Disponibilité des services et des infrastructures par région.
Architecture à haute disponibilité
Red Hat OpenShift on IBM Cloud l'architecture crée une haute disponibilité aux niveaux régional, de zone et de cluster.
- Disponibilité des régions
- Chaque région est configurée avec un équilibreur de charge à haute disponibilité accessible à partir du noeud final d'API spécifique à la région. L'équilibreur de charge achemine les demandes entrantes et sortantes aux clusters sur les différentes zones régionales. La probabilité d'une défaillance totale au niveau de la région est faible. Toutefois, pour prendre en compte cette défaillance, vous pouvez configurer plusieurs clusters dans différentes régions et les connecter entre eux au moyen d'un équilibreur de charge externe. Si une région entière tombe en panne, le cluster de l'autre région peut prendre en charge la charge de travail.
- Disponibilité des clusters et des zones
- Une défaillance de zone affecte tous les hôtes de calcul physiques et le stockage NFS. Ces défaillances peuvent être des pannes de courant, de ventilation, de réseau ou de stockage ou être dues à des catastrophes naturelles, telles que des inondations, des tremblements de terre ou des ouragans. Pour vous protéger en cas de défaillance d'une zone, vous devez disposer de clusters dans deux zones différentes dont la charge est équilibrée au moyen d'un équilibreur de charge externe. Créer un cluster dans un site multizone, qui répartit le maître entre les zones. Ou bien, envisagez d'installer un deuxième cluster dans une autre zone.
- Disponibilité multizone
- Les clusters multizones répartissent les charges de travail sur plusieurs nœuds et zones de travail, ce qui crée une protection supplémentaire contre les défaillances de zone. Les nœuds de travail sont automatiquement déployés avec trois répliques réparties sur plusieurs zones. Si une zone entière subit une panne, votre charge de travail est planifiée sur les nœuds de travail des autres zones, protégeant ainsi votre application de la panne.
- Équilibrage de charge global
- Pour protéger votre application d'une défaillance du maître ou pour les clusters classiques qui doivent résider dans l'une des régions multizones prises en charge, vous pouvez créer plusieurs clusters dans différentes zones au sein d'une région et les connecter à un équilibreur de charge global.
Distribution des ressources pour une haute disponibilité.
Vos utilisateurs risquent moins de rencontrer des indisponibilités lorsque vous répartissez votre configuration entre plusieurs noeuds worker, zones et clusters. Les fonctions intégrées, telles que l'équilibrage de charge et l'isolement, augmentent la résilience en cas de pannes d'hôtes, de réseaux ou d'applications. Examinez ces configurations potentielles de cluster, classées par ordre croissant de disponibilité. Pour plus d'informations sur la répartition des ressources d' IBM Cloud s entre les zones géographiques et les régions, consultez la documentation sur les sites.
- Clusters à zone unique
- Classique uniquement
- Les clusters à zone unique ont des nœuds de travail qui sont répartis sur des hôtes physiques distincts au sein de la même zone. Cette option protège contre certaines pannes, comme lors d'une mise à jour de la base de données, et est plus simple à gérer. Cependant, il ne protège pas vos applications si une zone entière subit une panne.
- Clusters multizones
- Classique VPC
- Les clusters multizones ont des nœuds de travail déployés automatiquement avec trois répliques réparties sur plusieurs zones. Si une zone entière subit une panne, votre charge de travail est planifiée sur les nœuds de travail des autres zones, protégeant ainsi votre application de la panne.
- Clusters multiples reliés à des équilibreurs de charge
- Classique VPC
- Plusieurs clusters peuvent être configurés dans la même zone ou dans des zones différentes et connectés via un équilibreur de charge global. Cette option est utile si vous devez approvisionner un cluster dans une seule zone, mais que vous souhaitez tout de même bénéficier de la disponibilité multizone.
Fonctions de haute disponibilité
Passez en revue les fonctionnalités à votre disposition pour assurer une haute disponibilité de vos applications et services.
| Fonction | Description |
|---|---|
| Options anti-affinité | Utilisez des règles anti-affinité pour répartir le déploiement des pods sur les nœuds de travail au lieu de restreindre le déploiement à des nœuds spécifiques. Cela vous offre une flexibilité supplémentaire pour votre charge de travail. |
| jeux de répliques | Pour augmenter la disponibilité de votre application, vous pouvez spécifier un ensemble de répliques dans votre déploiement. En cas de défaillance d'une instance d'application, Kubernetes lance automatiquement une nouvelle instance de votre application pour conserver le nombre indiqué d'instances de l'application. |
| Équilibrage de charge multizone (Classic) | Lorsque vous créez un cluster multizone classic, un équilibreur de charge multizone est automatiquement créé dans chaque zone où réside votre cluster pour gérer toutes les demandes entrantes vers vos applications et équilibrer la charge des demandes entre les équilibreurs de charge d'application (ALB) dans les zones de votre cluster. Il active également des diagnostics d'intégrité pour les adresses IP Ingress publiques. |
| Équilibrage de charge VPC (VPC) | Lorsque vous créez un cluster VPC, un équilibreur de charge VPC est automatiquement créé pour vous permettre de gérer toutes les demandes entrantes vers vos applications et d'équilibrer la charge des demandes entre les équilibreurs de charge d'application (ALB) dans les zones de votre cluster. Il active également des diagnostics d'intégrité pour les adresses IP Ingress publiques. |
| Programme de mise à l'échelle automatique de cluster | Le module complémentaire cluster autoscaler fait évoluer automatiquement les pools de travailleurs de votre cluster afin d'augmenter ou de réduire le nombre de nœuds de travailleurs dans le pool de travailleurs en fonction des besoins de dimensionnement de vos charges de travail planifiées. |
Fonctions de reprise après sinistre
La stratégie générale de reprise après sinistre consiste à configurer le stockage et les sauvegardes de vos données avec des solutions telles qu' Portworx.
Red Hat OpenShift on IBM Cloud prend en charge les fonctions de reprise après sinistre suivantes :
| Fonction | Description |
|---|---|
| Portworx | Une solution de stockage définie par logiciel, tierce et hautement disponible, que vous pouvez utiliser pour gérer le stockage persistant local de vos bases de données conteneurisées et d'autres applications avec état, ou pour partager des données entre des pods dans plusieurs zones. Passer en revue les prérequis |
| OpenShift Data Foundation(ODF)Reprise après sinistre régionale | Une solution de reprise après sinistre qui permet une reprise automatisée "en un clic" en cas de sinistre régional. Les applications sont automatiquement redéployées vers un « OpenShift Container Platform » désigné avec un cluster ODF disponible dans une autre région. |
| Cloud Object Storage (COS) | Une option de stockage persistante et hautement disponible qui s'intègre à vos applications, disponible sous forme de plug-in. Passez en revue les limitations. |
| Reprise automatique | Le système de reprise automatique effectue diverses vérifications pour obtenir l'état de santé des noeuds worker. Si le système de reprise automatique détecte un mauvais état de santé d'un noeud worker d'après les vérifications configurées, il déclenche une mesure corrective (par exemple, le réamorçage d'un noeud worker VPC ou le rechargement du système d'exploitation dans un noeud worker classique. |
| Portabilité des données avec Velero | Une option tierce pour exporter les données de votre cluster vers une instance d' IBM, ou vers un autre fournisseur d' s3. |
Portabilité des données via l'interface de ligne de commande(kubectl) |
Exporter les données en utilisant l'interface de ligne de commande ( kubectl ) |
Examinez d' autres options d'exportation de données, telles que rclone ou OADP.
Objectif de temps de récupération (RTO) et objectif de point de récupération (RPO)
| Fonction | RTO et RPO | Considérations |
|---|---|---|
| Portworx | RTO = Récupération totale après sinistre ( <60s ), RPO = Récupération partielle après sinistre ( <60s )- 15m | Les valeurs diffèrent entre les configurations asynchrones ou synchrones (également appelées Metro DR). Pour plus d'informations, voir Configuration de la reprise après incident avec Portworx. |
| ODF Plan de reprise d'activité après sinistre | RTO = 0, RPO = 0 | Ces valeurs s'appliquent uniquement au niveau du cluster. La récupération de données régionale et métropolitaine n'est pas disponible actuellement. |
| Cloud Object Storage | Voir les documents sur le stockage d'objets. |
Comment l' IBM® e contribue à assurer la reprise après sinistre
IBM® prend des mesures de reprise spécifiques pour l' Red Hat OpenShift on IBM Cloud, en cas de sinistre.
Comment l' IBM e se remet des échecs
En cas de défaillance d'une zone ou d'une région, IBM est responsable de la récupération des composants. IBM tentera de restaurer le cluster dans la même région en se basant sur le dernier état de la mémoire interne persistante. IBM met à jour et récupère les composants opérationnels au sein du cluster, tels que l'équilibreur de charge de l'application Ingress et le plug-in de stockage de fichiers.
IBM offre également la possibilité de s'intégrer à d'autres services IBM Cloud, tels que les fournisseurs de services de stockage, afin que les données puissent être sauvegardées et restaurées. Il est de votre responsabilité de mettre en œuvre ces intégrations.
Comment l' IBM e maintient ses services
Toutes les mises à niveau suivent les meilleures pratiques de service d' IBM, y compris les plans de reprise et les processus de restauration. Une maintenance régulière peut entraîner de courtes interruptions, atténuées par la logique de relance de la disponibilité du client. Les changements sont déployés de manière séquentielle, région par région et zone par zone au sein d'une région. IBM annule les mises à jour au premier signe de défaut.
Les changements complexes sont activés et désactivés à l'aide de drapeaux de fonction pour contrôler l'exposition.
Les changements qui ont un impact sur les charges de travail des clients sont détaillés dans les notifications d' 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, consultez la rubrique Notifications et état de la surveillance.
Vos responsabilités en matière de haute disponibilité et de reprise après sinistre
Il est de votre responsabilité de tester en permanence votre plan de continuité des activités et de reprise après sinistre.
Des interruptions de la connectivité réseau et de courtes périodes d'indisponibilité d'un service peuvent survenir. 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 une haute disponibilité de l'application.
Il vous incombe de configurer votre cluster de manière à atteindre le niveau de disponibilité approprié pour vos applications et services. Le niveau de disponibilité que vous avez configuré pour votre cluster a une incidence sur la couverture que vous recevez dans le cadre de l'accord sur les niveaux de service IBM Cloud. Par exemple, pour recevoir une couverture haute disponibilité selon les termes du contrat de service, vous devez configurer un cluster multizone avec un total d'au moins 6 nœuds de travail, deux nœuds de travail par zone qui sont répartis également sur trois zones.
Il vous incombe d'assurer la reprise des charges de travail qui s'exécutent dans le cluster et vos données d'application. Pour plus d'informations sur vos responsabilités en matière de reprise après sinistre, voir Vos responsabilités dans l'utilisation de Red Hat OpenShift on IBM Cloud.
Gestion des modifications
La gestion des modifications comprend des tâches telles que les mises à niveau, les changements de configuration et la suppression. Gardez à l'esprit les points suivants pour réduire les temps d'arrêt ou les pertes de données pour votre charge de travail.
-
Il est recommandé d'attribuer aux utilisateurs et aux processus les rôles et les actions IAM avec le moins de privilèges requis pour leur travail. Par exemple, limiter la possibilité de supprimer des ressources de production.
-
Utilisez les outils API, CLI ou console pour appliquer les mises à jour des nœuds de travail fournies, y compris les correctifs du système d'exploitation, ou pour demander que les nœuds de travail soient redémarrés, rechargés ou remplacés.
-
Utilisez l'API, le CLI ou les outils de la console pour appliquer les modifications majeures et mineures fournies Kubernetes mises à jour du maître et majeures, mineures et mise à jour des nœuds de correctifs. Veillez à examiner les informations et les exigences relatives à chaque mise à jour de version afin d'éviter tout problème ou temps d'arrêt.
-
Assurez-vous que les nœuds de travail de votre cluster exécutent la dernière Ubuntu la plus récente.
-
Assurez-vous de bien comprendre les calendriers de publication de tous les modules complémentaires que vous exécutez dans votre cluster.
Considérations relatives au déploiement des applications et des services
La manière dont vous configurez votre cluster a un impact sur le niveau de disponibilité que vous obtenez pour vos applications et services. Plus votre configuration sera distribuée entre plusieurs noeuds worker et clusters, et moins vos utilisateurs seront susceptibles d'encourir des temps d'indisponibilité de votre application.
Examinez les configurations potentielles d'application suivantes, classées par ordre de disponibilité croissante.
- Un déploiement avec n+2 pods qui sont gérés par un ensemble de répliques sur un seul nœud.
- Déploiement avec n+2 pods gérés par un ensemble de répliques et disséminés entre plusieurs noeuds (anti-affinité) dans un cluster à zone unique.
- Déploiement avec n+2 pods gérés par un ensemble de répliques et disséminés entre plusieurs noeuds (anti-affinité) dans un cluster multizone entre différentes zones.
Consultez la documentation suivante pour obtenir des informations sur la création d'une charge de travail hautement disponible.