OpenShift sur Google Cloud : stratégies de reprise après sinistre pour les configurations actif-passif et actif-inactif

Ce document explique comment planifier et implémenter la reprise après sinistre actif-passif et actif-inactif pour les déploiements OpenShift sur Google Cloud . Il vous aidera à minimiser les temps d'arrêt et à assurer une reprise rapide en cas de sinistre. Il fournit des bonnes pratiques pour sauvegarder les données, gérer la configuration en tant que code et gérer les secrets afin de vous aider à récupérer rapidement vos applications 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 une plate-forme OpenShift Container 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. Il suppose que vous avez lu les bonnes pratiques de reprise après sinistre avec OpenShift. Cette série comprend les documents suivants :

Architectures de reprise après sinistre

Cette section décrit les architectures pour les scénarios de reprise après sinistre actif-passif et actif-inactif.

Produits utilisés

Déploiements actif-passif

Le schéma suivant illustre un scénario de déploiement actif-passif pour OpenShift sur Google Cloud.

Déploiement actif-passif, expliqué dans le texte suivant.

Comme le montre le schéma précédent, dans un déploiement actif-passif pour la reprise après sinistre, un cluster OpenShift dans la région principale gère tout le trafic de production. Un cluster secondaire dans une autre région est prêt à prendre le relais en cas de défaillance du cluster principal. Cette configuration garantit un temps d'arrêt minimal en préprovisionnant le cluster secondaire et en le maintenant dans un état tiède. Cela signifie qu'il est configuré avec l'infrastructure et les composants d'application nécessaires, mais qu'il ne diffuse pas activement de trafic tant que cela n'est pas nécessaire. Les données d'application sont répliquées dans le cluster passif pour minimiser la perte de données, conformément au RPO.

L'un des clusters régionaux sert de site principal (actif) et gère l'ensemble du trafic de production. Un cluster secondaire, situé dans une autre région, est en veille pour la reprise après sinistre. Le cluster secondaire est maintenu dans un état "chaud" et est prêt à prendre le relais avec un délai minimal en cas de défaillance du cluster principal.

Description des composants dans un scénario de reprise après sinistre actif-passif

L'architecture présente la configuration suivante :

  • Cluster OpenShift principal (actif) : situé dans la régionGoogle Cloud principale, ce cluster exécute la charge de travail de production et diffuse activement tout le trafic utilisateur dans des conditions de fonctionnement normales.
  • Cluster OpenShift secondaire (passif) : situé dans une régionGoogle Cloud distincte pour l'isolation des pannes, ce cluster sert de cluster de secours actif. Il est partiellement configuré et en cours d'exécution, et il est prêt à prendre le relais en cas de défaillance du système principal. Il dispose de l'infrastructure, de la configuration OpenShift et des composants d'application nécessaires, mais il ne diffuse pas de trafic de production en direct tant qu'un événement de basculement n'est pas déclenché.
  • Google Cloud régions : emplacements géographiquement isolés qui servent de base à la reprise après sinistre. L'utilisation de régions distinctes permet de s'assurer qu'un événement à grande échelle ayant un impact sur une région n'affecte pas le cluster de secours.
  • Équilibreur de charge HTTPS externe global : sert de point d'entrée unique et global pour le trafic des applications. Dans des conditions normales, il est configuré pour acheminer tout le trafic vers le cluster principal (actif). Ses vérifications de l'état surveillent la disponibilité du cluster principal.
  • Mécanisme de réplication des données : processus ou outils continus chargés de copier les données d'application essentielles du cluster principal vers le cluster secondaire (par exemple, l'état des bases de données ou des volumes persistants). Cette approche garantit la cohérence des données et minimise leur perte lors d'un basculement, ce qui vous aide à respecter votre RPO.
  • Surveillance et vérifications de l'état : systèmes qui évaluent en continu l'état et la disponibilité du cluster principal et de ses applications (par exemple, Cloud Monitoring, vérifications de l'état de l'équilibreur de charge, surveillance interne du cluster). Ces systèmes sont importants pour détecter rapidement les éventuelles défaillances.
  • Mécanisme de basculement : processus prédéfini (manuel, semi-automatique ou entièrement automatique) permettant de rediriger le trafic du cluster principal vers le cluster secondaire en cas de détection d'une défaillance irrécupérable dans le cluster principal. Ce processus implique généralement la mise à jour de la configuration du backend de l'équilibreur de charge global pour cibler le cluster secondaire, ce qui en fait le nouveau site actif.
  • Réseau VPC : infrastructure réseau Google Cloud sous-jacente qui crée la connectivité nécessaire entre les régions pour la réplication et la gestion des données.

Déploiements actifs/inactifs

La reprise après sinistre active-inactive 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é à l'API OpenShift for Data Protection (OADP), pour effectuer des sauvegardes périodiques. 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. Il peut également aider les entreprises à s'aligner sur des objectifs de temps de récupération (RTO) et 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 de manière active. 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 l'API OpenShift for Data Protection (OADP), basée 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 un RTO plus long et un RPO potentiellement plus élevé 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.

Processus de basculement.

Voici le processus de basculement :

  1. Un événement de reprise après sinistre est déclenché lorsqu'un service surveillé devient indisponible.
  2. Un pipeline provisionne automatiquement l'infrastructure dans la région de reprise après sinistre.
  3. Un nouveau cluster OpenShift est provisionné.
  4. Les données, les secrets et les objets de l'application sont restaurés à partir de la dernière sauvegarde via OADP.
  5. 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 schéma précédent, deux clusters OpenShift régionaux distincts sont déployés, chacun dans une région Google Cloud différente, comme us-central1 et europe-west1. Chaque cluster doit être hautement disponible 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 un minimum de ressources (VPC et sous-réseaux). L'infrastructure (instances Compute Engine et OCP) est provisionnée lors du basculement.
  • Stockage des sauvegardes : les buckets Google Cloud Storage stockent des sauvegardes périodiques (OADP ou Velero pour les objets d'application, ainsi que les sauvegardes de volumes persistants et de bases de données). Nous vous recommandons d'utiliser le versioning et la réplication multirégionale pour le bucket.
  • Gestion de la configuration : le dépôt Git stocke l'Infrastructure as Code (IaC, par exemple, Terraform) et les fichiers manifestes Kubernetes ou OpenShift (pour GitOps).
  • Outils 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 les processus de provisionnement et de restauration de l'infrastructure lors du basculement.

Cas d'utilisation

Cette section fournit des exemples des différents cas d'utilisation pour les déploiements actif-passif et actif-inactif.

Cas d'utilisation de la reprise après sinistre actif-passif

La reprise après sinistre active-passive est recommandée pour les cas d'utilisation suivants :

  • Applications nécessitant un RTO plus faible (par exemple, de quelques minutes à quelques heures) que celui possible avec les restaurations à froid, où les données sont restaurées à partir d'une sauvegarde qui n'est pas immédiatement accessible.
  • Systèmes où la réplication continue des données est possible et où le RPO doit être minimisé (par exemple, de quelques minutes à quelques secondes).
  • Secteurs réglementés avec des limites strictes de temps d'arrêt et applications métier critiques où le coût de maintenance d'un cluster de secours actif est justifié par l'impact commercial des temps d'arrêt.

Cas d'utilisation de la reprise après sinistre actif-inactif

La reprise après sinistre active-inactive 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ù les dépenses liées à un cluster de secours en cours d'exécution sont prohibitives. Le principal coût continu 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 répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, de coût et de performances.

Considérations de conception active-passive

Cette section décrit les considérations de conception pour un scénario de reprise après sinistre actif-passif.

Protéger l'état et la configuration de l'application

OpenShift Container Platform fournit OADP et offre une protection complète contre les sinistres pour les applications exécutées dans des clusters. Vous pouvez l'utiliser pour sauvegarder les objets Kubernetes et OpenShift utilisés par les applications conteneurisées et les machines virtuelles (par exemple, les déploiements, les services, les routes, les PVC, les ConfigMaps, les secrets et les CRD). Toutefois, OADP ne permet pas de sauvegarder et de restaurer l'intégralité du cluster. Pour savoir comment configurer et planifier des sauvegardes, et comment effectuer des opérations de restauration, consultez la documentation Red Hat.

OADP fournit des processus de sauvegarde et de restauration pour les volumes persistants qui s'appuient sur le stockage par blocs et les magasins NFS utilisés par les applications. Vous pouvez effectuer ces processus à l'aide des outils Restic ou Kopia pour créer des instantanés ou effectuer des sauvegardes au niveau des fichiers.

OADP est utile pour sauvegarder les définitions d'objets, assurer la cohérence de la configuration et, si nécessaire, restaurer des applications ou des espaces de noms spécifiques, en complément de la réplication des données.

Pour réduire davantage le RPO et le RTO dans une configuration actif-passif, nous vous recommandons de configurer la réplication des données entre les régions principale et secondaire.

La réplication des données est importante pour garantir que le cluster secondaire peut prendre le relais de manière fluide. Comme indiqué dans la section suivante, l'implémentation de la réplication des données des clusters principaux vers les clusters secondaires dépend du type de stockage utilisé par l'application.

Stockage de blocs (volumes persistants)

Utilisez la réplication asynchrone des disques persistants Google pour copier les données de la région principale vers la région secondaire. Dans cette approche, vous créez un disque principal dans la région principale, un disque secondaire dans la région secondaire et configurez la réplication entre eux. L'utilisation de groupes cohérents garantit que les deux disques contiennent des données de réplication à partir d'un point commun dans le temps, qui sont ensuite utilisées pour la reprise après sinistre. Pour en savoir plus, consultez Configurer la réplication asynchrone des disques persistants.

Objets PersistentVolumes

Dans OpenShift, créez des objets PersistentVolumes dans les deux clusters qui sont associés à ces disques, et assurez-vous que les applications utilisent les mêmes PersistentVolumeClaims (PVC) dans les deux clusters.

Réplication au niveau de l'application

Certaines applications (bases de données et files d'attente de messages, par exemple) disposent de fonctionnalités de réplication intégrées que vous pouvez configurer sur plusieurs clusters. Vous pouvez également utiliser un service géré tel que Pub/Sub pour faciliter la réplication de types spécifiques de données ou d'événements d'application. (par exemple, les bases de données et les files d'attente de messages).

Sauvegardes de bases de données

Les applications peuvent dépendre de différents types de produits de base de données. Pour vous aider à définir les points à prendre en compte pour la conception des sauvegardes de bases de données, ce document utilise PostgreSQL comme exemple de base de données.

Sauvegardes auto-hébergées à l'aide d'un opérateur de base de données dans le cluster

Les opérateurs de base de données tels que CloudNative PostgreSQL Operator peuvent faciliter les sauvegardes planifiées et la reprise après sinistre pour les clusters PostgreSQL. L'opérateur CloudNative PostgreSQL s'intègre de manière native à des outils tels que pg_basebackup et prend en charge les sauvegardes de réplication par flux. Vous pouvez stocker les sauvegardes dans des services de stockage cloud tels que Google Cloud Storage (Cloud Storage) pour la durabilité et la récupération.

Vous pouvez configurer la réplication par flux entre les clusters régionaux principaux et secondaires pour vous assurer que les données sont disponibles, même en cas d'indisponibilité dans la région principale. Cette réplication par flux est généralement synchrone dans une région et asynchrone entre les régions. Pour obtenir la procédure de configuration détaillée, consultez la documentation CloudNativePG.

En cas de sinistre, vous pouvez restaurer les sauvegardes dans un nouveau cluster PostgreSQL, ce qui permet de minimiser les temps d'arrêt et les pertes de données. Voici un exemple d'extrait de configuration permettant d'activer les sauvegardes planifiées à l'aide de l'opérateur CloudNativePG :

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

Services gérés

Les bases de données gérées telles que Cloud SQL disposent de fonctionnalités de sauvegarde et de réplication intégrées. Nous vous recommandons de configurer la réplication asynchrone de l'instance de base de données principale vers une instance répliquée dans la région secondaire. Pour en savoir plus, consultez À propos de la réplication dans Cloud SQL. Dans OpenShift, configurez des secrets ou des cartes de configuration pour qu'ils pointent vers les chaînes de connexion à la base de données appropriées pour chaque cluster.

Comme la réplication asynchrone entraîne un RPO non nul, il existe un risque de perte des données les plus récentes. Vous devez concevoir votre application de manière à éviter la perte de données. Vous pouvez également envisager d'utiliser une autre méthode de réplication.

Nous vous recommandons également d'activer les sauvegardes automatiques Cloud SQL. Pour en savoir plus, consultez Créer et gérer des sauvegardes à la demande et automatiques.

Processus de basculement

En cas de défaillance du cluster principal, Cloud DNS redirige automatiquement le trafic vers le cluster régional secondaire en fonction des vérifications de l'état et des règles de basculement.

Lorsque le cluster secondaire est promu d'instance répliquée avec accès en lecture à instance principale, il devient un site actif et diffuse le trafic de production. Cette promotion est nécessaire pour pouvoir accepter les écritures dans la base de données.

Pour configurer la reprise après sinistre pour Cloud SQL, suivez les étapes décrites dans la documentation sur la reprise après sinistre de Google Cloud SQL. L'utilisation d'une réplication asynchrone de base de données ou de stockage entraîne un RPO non nul pour vous assurer que votre application peut tolérer la perte des écritures les plus récentes. Vous pouvez également envisager d'utiliser une autre méthode de réplication.

Gestion sécurisée des secrets

Les secrets tels que les mots de passe de base de données, les clés API et les certificats TLS sont des aspects importants de la reprise après sinistre. Vous devez pouvoir restaurer ces secrets de manière sécurisée et fiable dans un nouveau cluster.

Voici quelques approches courantes de la gestion des secrets :

  • Utiliser des secrets externes : utilisez un outil tel que l'opérateur de secrets externes pour extraire les secrets de Google Secret Manager.
  • Sauvegarder les secrets avec l'opérateur OADP : si vous n'utilisez pas de magasin externe, assurez-vous que les secrets sont inclus dans vos sauvegardes.
  • Rotation régulière : effectuez régulièrement une rotation des secrets et assurez-vous que votre stratégie de gestion des secrets tient compte des scénarios de reprise après sinistre.
  • Test : testez la restauration du secret dans un environnement intermédiaire pour vérifier que tous les services peuvent démarrer avec les identifiants fournis.
  • Validation : validez le fait que votre cluster de reprise après sinistre dispose des rôles IAM ou des méthodes d'authentification nécessaires pour récupérer les secrets des magasins externes.

Mise en réseau et gestion du trafic

Utilisez l'équilibreur de charge HTTPS externe mondial de Google Cloudcomme point d'entrée principal pour répartir le trafic entre plusieurs clusters OpenShift (par exemple, les clusters principal et secondaire). Ce service global dirige les requêtes des utilisateurs vers le cluster de backend approprié en fonction de la proximité, de l'état et de la disponibilité.

Pour connecter l'équilibreur de charge mondial à vos clusters OpenShift, vous pouvez utiliser l'une des approches suivantes :

  • Utilisez des équilibreurs de charge régionaux (NEG Internet) : configurez desGoogle Cloud groupes de points de terminaison réseau (NEG) Internet pour qu'ils pointent vers les adresses IP externes des équilibreurs de charge régionaux exposant chacun des services d'entrée de vos clusters OpenShift (routeurs OCP). L'équilibreur de charge mondial achemine ensuite le trafic vers ces adresses IP d'équilibreur de charge régional. Cette approche fournit une couche d'abstraction, mais implique un saut vers un réseau supplémentaire.
  • Routage direct des pods (Compute Engine_VM_IP_PORT NEGs) : configurez l'intégration du contrôleur Ingress OpenShift pour utiliser les groupes de points de terminaison réseau (NEG) Google Cloudde type Compute Engine_VM_IP_PORT. Cette approche permet à l'équilibreur de charge mondial de cibler directement les pods du contrôleur Ingress OpenShift (routeur) à l'aide de leur PodIP:TargetPort interne. Cette méthode contourne le saut supplémentaire et le proxying de nœud supplémentaire. Elle permet généralement de réduire la latence et d'effectuer des vérifications d'état plus directes à partir de l'équilibreur de charge global.

Les deux configurations permettent à l'équilibreur de charge global de gérer efficacement la répartition du trafic entre les clusters de différentes régions. Pour en savoir plus, consultez Configurer un équilibreur de charge d'application externe mondial avec un backend externe.

VPC

Nous vous recommandons les approches suivantes pour la gestion du VPC :

  • VPC partagé : utilisez un VPC partagé pour centraliser la gestion du réseau pour les clusters principaux et secondaires. Cette approche simplifie l'administration et assure la cohérence des règles réseau dans toutes les régions.
  • Routage dynamique global : activez le routage dynamique global dans vos VPC pour propager automatiquement les routes entre les régions, ce qui garantit une connectivité fluide entre les clusters.
  • VPC en mode personnalisé : utilisez des VPC en mode personnalisé et créez des sous-réseaux spécifiques dans les régions où vos clusters s'exécutent. Cela est souvent nécessaire pour la mise en réseau des pods natifs au VPC requise par des méthodes telles que le routage Compute Engine_VM_IP_PORT.
  • Appairage de réseaux VPC : si vous devez utiliser des réseaux VPC distincts pour chaque région et chaque cluster, utilisez l'appairage de réseaux VPC pour connecter les régions et les clusters.

Sous-réseaux et adresses IP

Créez des sous-réseaux régionaux dans chaque région pour maintenir la segmentation du réseau et éviter les conflits d'adresses IP.

Assurez-vous qu'il n'y a pas de chevauchement de plages d'adresses IP entre les régions pour éviter les problèmes de routage.

Trafic entre clusters avec Red Hat Service Mesh

OpenShift est compatible avec la fédération Service Mesh, qui permet la communication entre les services déployés sur plusieurs clusters OpenShift. Cette fonction est particulièrement utile pour les scénarios de reprise après sinistre où les services peuvent avoir besoin de communiquer entre les clusters lors du basculement ou de la réplication des données.

Pour savoir comment configurer la fédération Service Mesh entre les clusters principal et secondaire, consultez la documentation Red Hat.

Points à prendre en compte pour la conception des états actif/inactif

Cette section décrit les considérations de conception pour une solution de reprise après sinistre active-inactive.

Configuration d'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 en cas de reprise après sinistre, en permettant la synchronisation vers un état connu pour fonctionner 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 d'application, les fichiers manifestes et les définitions d'infrastructure 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 réconciliation continue de l'état de votre cluster avec la configuration de votre choix 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 réconcilie automatiquement. Pour en savoir plus, consultez À propos de Red Hat OpenShift GitOps.

Exécution d'un 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 fichier 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 :

  • Adoptez des stratégies strictes d'embranchement et de taggage dans votre dépôt Git pour 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 renforcer la sécurité.

Suivez le principe du moindre privilège, ce qui signifie que vous devez limiter 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.

Étapes suivantes