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 Red Hat 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. Il suppose que vous avez lu Bonnes pratiques pour la reprise après sinistre. Les documents de cette série sont les suivants :
- Bonnes pratiques pour la reprise après sinistre
- 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 (cette page)
Architecture de reprise après sinistre
La reprise après sinistre actif-inactif consiste à maintenir une région secondaire en veille, qui n'est activée qu'en cas de sinistre. Contrairement aux configurations actif-passif, où les données sont répliquées en continu, cette stratégie repose sur des sauvegardes périodiques stockées dans Cloud Storage, avec une infrastructure provisionnée et des données restaurées lors du basculement. Vous pouvez utiliser des outils tels que Velero, intégré à OpenShift API for Data Protection (OADP), pour effectuer des sauvegardes périodiques backups. Cette approche minimise les coûts, ce qui la rend idéale pour les applications qui peuvent tolérer des temps de récupération plus longs. Elle peut également aider les organisations à s'aligner sur des objectifs de temps de récupération (RTO) et des objectifs de point de récupération (RPO) étendus.
Dans un scénario de reprise après sinistre actif-inactif, les données sont régulièrement sauvegardées dans la région de secours, mais ne sont pas répliquées activement. L'infrastructure est provisionnée dans le cadre du processus de basculement et les données sont restaurées à partir de la sauvegarde la plus récente. Vous pouvez utiliser OpenShift API for Data Protection (OADP), basé sur le projet Open Source Velero, pour effectuer des sauvegardes régulières. Nous vous recommandons de stocker ces sauvegardes dans des buckets Cloud Storage pour lesquels la gestion des versions est activée. En cas de sinistre, vous pouvez utiliser OADP pour restaurer le contenu du cluster. Cette approche minimise les coûts continus, mais entraîne des RTO plus longs et des RPO potentiellement plus élevés que l'approche actif-passif. Cette configuration convient aux applications dont les objectifs de temps de récupération sont plus longs.
Le schéma suivant illustre un déploiement actif-inactif et le processus de basculement :
Le processus de basculement est le suivant :
- Un événement de reprise après sinistre est déclenché lorsqu'un service surveillé devient indisponible.
- Un pipeline provisionne automatiquement l'infrastructure dans la région de reprise après sinistre.
- Un nouveau cluster OpenShift est provisionné.
- Les données, les secrets et les objets de l'application sont restaurés à partir de la dernière sauvegarde via OADP.
- L'enregistrement Cloud DNS est mis à jour pour pointer vers les équilibreurs de charge régionaux de la région de reprise après sinistre.
Comme le montre le diagramme précédent, deux clusters OpenShift régionaux distincts sont déployés, chacun dans une région différente Google Cloud , par exemple us-central1 et europe-west1. Chaque cluster doit être disponibilité élevée dans sa région et utiliser plusieurs zones pour permettre la redondance.
Description des composants dans un scénario de reprise après sinistre actif-inactif
L'architecture présente la configuration suivante :
- Région principale (région A) : contient le cluster OpenShift entièrement opérationnel qui diffuse le trafic de production.
- Région secondaire (région B) : contient initialement des ressources minimales (VPC et sous-réseaux). L'infrastructure (instances Compute Engine et OCP) est provisionnée lors du basculement.
- Stockage de sauvegarde : les buckets Google Cloud Storage stockent des sauvegardes périodiques (OADP ou Velero pour les objets d'application, ainsi que les PV et les sauvegardes de base de données). Nous vous recommandons d'utiliser la gestion des versions et la réplication entre régions pour le bucket.
- Gestion de la configuration : le dépôt Git stocke l'Infrastructure as Code (IaC, par exemple, Terraform) et les manifestes Kubernetes ou OpenShift (pour GitOps).
- Outil de sauvegarde : OADP (Velero) configuré dans le cluster principal pour effectuer des sauvegardes planifiées dans Cloud Storage.
- Orchestration : des scripts ou des outils d'automatisation déclenchent le provisionnement de l'infrastructure et les processus de restauration lors du basculement.
Produits utilisés
- Google Compute Engine
- Google Cloud Équilibreur de charge HTTPS externe global
- Google Cloud Équilibreurs de charge réseau passthrough
- Cloud DNS
- Groupes de points de terminaison du réseau
- Cloud Storage
- Cloud SQL
- Persistent Disk
- Secret Manager
- Cloud Monitoring
- Réseau VPC
Cas d'utilisation
La reprise après sinistre actif-inactif est recommandée pour les cas d'utilisation suivants :
- Applications pouvant tolérer des RTO plus longs (par exemple, de plusieurs minutes à plusieurs heures).
- Environnements où l'optimisation des coûts est importante et où le coût d'un cluster de secours en cours d'exécution est prohibitif. Le coût continu principal concerne le stockage d'objets plutôt que l'exécution d'instances de calcul.
- Charges de travail de développement, de test ou de production moins critiques.
- Systèmes d'archivage ou de traitement par lot où le temps de récupération est moins critique.
Considérations de conception
Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie qui répond à vos exigences spécifiques en matière de sécurité, de fiabilité, de coût et de performances.
Configuration de l'application en tant que code (GitOps)
Nous vous recommandons d'adopter une approche GitOps pour stocker toutes les configurations de cluster et d'application dans un dépôt Git. Cette approche permet une restauration rapide dans un scénario de reprise après sinistre en activant la synchronisation avec un état connu pour s'exécuter de manière fiable dans un autre cluster. Les sauvegardes vous permettent de disposer d'instantanés de votre état d'exécution. Toutefois, vous avez également besoin d'un moyen fiable de redéployer rapidement la logique, les manifestes et les définitions d'infrastructure de l'application après un sinistre.
Utiliser l'opérateur OpenShift GitOps
L'opérateur OpenShift GitOps, basé sur Argo CD, fournit un moyen compatible avec Red Hat d'implémenter des modèles GitOps directement dans un environnement OpenShift. Il automatise le processus de rapprochement continu de l'état de votre cluster avec la configuration choisie et le stocke dans un dépôt Git.
Le contrôleur de l'opérateur OpenShift GitOps s'assure en permanence que l'état du cluster correspond à la configuration définie dans ce dépôt. Si des ressources dérivent ou sont manquantes, il les rapproche automatiquement. Pour en savoir plus, consultez À propos de Red Hat OpenShift GitOps.
Exécution du scénario de reprise après sinistre
En cas de sinistre, procédez comme suit :
- Configurez un nouveau cluster OpenShift dans une autre région.
- Installez l'opérateur OpenShift GitOps.
- Appliquez le même manifeste d'application faisant référence à votre dépôt Git.
L'opérateur synchronise l'état du cluster pour qu'il corresponde à votre dépôt, en redéployant rapidement les déploiements, les services, les routes, les opérateurs et toutes les autres ressources définies dans votre code.
Pour éviter tout problème lors de la reprise après sinistre, nous vous recommandons de procéder comme suit :
- Maintenez des stratégies strictes de ramification et de balisage dans votre dépôt Git afin de pouvoir identifier les configurations stables adaptées à la reprise après sinistre.
- Vérifiez que votre cluster de reprise après sinistre dispose d'une connectivité réseau et des autorisations appropriées pour accéder au dépôt Git.
- Incluez tous les types de ressources en tant que code pour éviter toute intervention manuelle lors du basculement (par exemple, les composants d'infrastructure, les charges de travail d'application et les configurations).
Règles de pare-feu
Définissez des règles de pare-feu unifiées et appliquez-les de manière cohérente aux deux clusters pour contrôler le flux de trafic et améliorer la sécurité.
Suivez le principe du moindre privilège, ce qui signifie que vous limitez le trafic entrant et sortant à ce qui est nécessaire au fonctionnement de l'application.
Déploiement
Pour savoir comment déployer une topologie basée sur cette architecture de référence, consultez la documentation Red Hat.
É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.