Ce document est destiné 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 OpenShift Container Platform déployé sur Google 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 disponibilité élevée et rapidement récupérables en cas de défaillance. Les documents de cette série sont les suivants :
- Bonnes pratiques pour la reprise après sinistre (cette page)
- Bonnes pratiques pour la haute disponibilité
- Stratégies de reprise après sinistre pour les configurations actif-passif
- Stratégies de reprise après sinistre pour les configurations actif-inactif
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 remettre rapidement de défaillances catastrophiques.
Une planification efficace de la reprise après sinistre implique une approche par couches. Vous 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 d'accélérer le redéploiement.
Vos secrets et vos 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 des opérations avec un temps d'arrêt minimal.
Architectures de 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 sur le cluster passif. | Convient aux applications avec des exigences modérées en termes de RTO et de RPO. | Implémentation plus simple, coût inférieur pour le cluster de secours. | RTO plus élevé en raison du temps de basculement, retards potentiels de synchronisation des données. |
| Actif-Inactif | Semblable à la configuration actif-passif, mais le cluster inactif n'est pas utilisé avant un événement de reprise après sinistre. Les données sont régulièrement sauvegardées. | Idéal pour les environnements sensibles aux coûts qui autorisent un RTO et un RPO plus élevés. | Coût opérationnel inférieur lorsqu'il est inactif, adapté à la reprise après sinistre lorsqu'un système secondaire n'est pas en cours d'exécution (reprise après sinistre à froid). | RTO plus élevé en raison du temps d'activation et de synchronisation, bien qu'il existe un risque d'obsolescence des données. |
| 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 faibles, disponibilité continue. | Complexité et coût les plus élevés, nécessite un réseau robuste et des synchronisations de données. |
Étape suivante
- Découvrez comment implémenter la surveillance et les alertes pour l'état du cluster, l'état de la réplication, la réussite des sauvegardes et les performances des applications dans les environnements principal et secondaire.
- Découvrez comment installer OpenShift sur Google Cloud.
- En savoir plus sur les solutions Red Hat sur Google Cloud