Reprise après sinistre pour OpenShift sur Google Cloud

La reprise après sinistre est essentielle pour assurer la continuité de vos applications déployées sur OpenShift Container Platform surGoogle Cloud. Ce document présente les options d'architecture pour la reprise après sinistre avec OpenShift sur Google Cloud. Il aide votre organisation à minimiser les temps d'arrêt et à se rétablir rapidement en cas de sinistre.

Ce document s'adresse aux administrateurs système, aux architectes cloud et aux développeurs d'applications chargés de maintenir la disponibilité et la résilience des applications sur la plate-forme de conteneurs OpenShift déployée surGoogle Cloud.

Ce document fait partie d'une série axée sur les stratégies au niveau de l'application qui garantissent que vos charges de travail restent hautement disponibles et récupérables rapidement en cas de défaillance. Les documents de cette série sont les suivants :

Planification de la reprise après sinistre

La planification de la reprise après sinistre est un élément essentiel de l'exécution des charges de travail de production dans le cloud. Bien qu'OpenShift et Google Cloud offrent une redondance robuste au niveau de l'infrastructure, vous devez également concevoir et configurer vos applications pour qu'elles puissent se rétablir rapidement en cas de défaillance catastrophique.

Une planification efficace de la reprise après sinistre implique une approche par couches. Commencez par définir des objectifs de temps de récupération (RTO) et des objectifs de point de récupération (RPO) clairs pour votre application et votre système afin de permettre un redéploiement rapide.

Enfin, vos secrets et identifiants doivent également être récupérables et gérés de manière sécurisée. En tenant compte de tous ces facteurs, vous pouvez adopter une stratégie de reprise après sinistre qui vous permet de créer rapidement un cluster OpenShift dans une autre région ou de basculer vers un cluster secondaire inactif. Ce cluster secondaire reste hors connexion jusqu'à ce qu'une défaillance se produise. Il est alors démarré et mis en ligne pour prendre le relais avec un temps d'arrêt minimal.

Architectures pour la reprise après sinistre

Il existe différentes options d'architectures de déploiement que vous pouvez utiliser pour la reprise après sinistre avec OpenShift sur Google Cloud. Chacune de ces options a des implications différentes en termes de coût, de complexité et de disponibilité. Le tableau suivant présente ces architectures :

Architecture Description Cas d'utilisation Avantages Inconvénients
Actif-Passif Un cluster est actif et gère tout le trafic, tandis que l'autre est passif et prêt à prendre le relais. Les données sont répliquées dans le cluster passif. Convient aux applications ayant des exigences modérées en termes de RTO et de RPO. Plus simple à implémenter, coût inférieur pour le cluster de secours. RTO plus élevé en raison du temps de basculement et des éventuels retards de synchronisation des données.
Actif-Inactif Semblable à la configuration actif/passif, mais le cluster inactif n'est pas utilisé tant qu'un événement de reprise après sinistre ne se produit pas. Les données sont sauvegardées régulièrement. Idéal pour les environnements sensibles aux coûts qui autorisent des valeurs RTO et RPO plus élevées. Coût opérationnel réduit lorsqu'il est inactif, adapté à la reprise après sinistre où un système secondaire n'est pas en cours d'exécution (reprise après sinistre à froid) . Le RTO est plus élevé en raison du temps d'activation et de synchronisation, mais il est possible que les données deviennent obsolètes.
Actif-Actif Les deux clusters sont actifs et gèrent le trafic avec l'équilibrage de charge et la réplication des données entre les régions. Applications critiques nécessitant un temps d'arrêt minimal et une haute disponibilité. RTO et RPO les plus bas, disponibilité continue. Complexité et coût les plus élevés, nécessite une synchronisation robuste du réseau et des données.

Étapes suivantes