Stratégies de reprise après sinistre pour les configurations actif-passif

Ce document explique comment planifier et implémenter une reprise après sinistre actif-passif pour les déploiements OpenShift sur Google Cloud afin de vous aider à minimiser les temps d'arrêt et à accélérer la reprise 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 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 :

Architecture de reprise après sinistre

Le schéma d'architecture 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, car le cluster secondaire est préprovisionné et dans un état chaud. Cela signifie qu'il est configuré avec l'infrastructure et les composants d'application nécessaires, mais qu'il ne diffuse pas activement le 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 fait office de site principal (actif) et gère tout le trafic de production. Un cluster secondaire, 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

Cette architecture présente la configuration suivante :

  • Cluster OpenShift principal (actif) : situé dans la région principale Google Cloud , 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égion distincte Google Cloud pour l'isolation des pannes, ce cluster fait office de cluster de secours chaud. 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. L'infrastructure, la configuration OpenShift et les composants d'application nécessaires y sont déployés, 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 constituent la base de la reprise après sinistre. L'utilisation de régions distinctes garantit 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 : fait office de point d'entrée unique et global pour le trafic d'application. Dans des conditions normales, il est configuré pour acheminer tout le trafic vers le cluster principal (actif). Ses vérifications d'é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 la perte de données lors d'un basculement, ce qui vous aide à respecter votre RPO.
  • Surveillance et vérifications d'état : systèmes qui évaluent en permanence l'état et la disponibilité du cluster principal et de ses applications, par exemple Cloud Monitoring, les vérifications d'état de l'équilibreur de charge et la surveillance interne du cluster. Ces systèmes sont importants pour la détection rapide de toute défaillance.
  • Mécanisme de basculement : processus prédéfini (manuel, semi-automatisé ou entièrement automatisé) permettant de rediriger le trafic du cluster principal vers le cluster secondaire lors de la 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 sous-jacente qui Google Cloud crée la connectivité nécessaire entre les régions pour la réplication et la gestion des données.

Produits utilisés

Cas d'utilisation

La reprise après sinistre actif-passif 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 qui serait possible avec des 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 chaud est justifié par l'impact commercial des temps d'arrêt.

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception que vous devez 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.

Protection de l'état et de la configuration des applications

OpenShift Container Platform fournit OADP et offre une protection complète de reprise après sinistre 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 prend pas en charge la sauvegarde et la restauration complètes des clusters. Pour savoir comment configurer et planifier des sauvegardes, et comment restaurer des opérations, consultez la documentation Red Hat.

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

OADP est utile pour sauvegarder les définitions d'objets, garantir 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 transparente. Comme indiqué dans la section suivante, l'implémentation de la réplication des données du cluster principal vers le cluster secondaire dépend du type de stockage utilisé par l'application.

Stockage de blocs (volumes persistants)

Utilisez la réplication asynchrone de Google Persistent Disk 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 est ensuite utilisé pour la reprise après sinistre. Pour en savoir plus, consultez Configurer la réplication asynchrone de Persistent Disk.

Objets PersistentVolumes

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

Réplication au niveau de l'application

Certaines applications (par exemple, les bases de données et les files d'attente de messages) 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.

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 considérations de conception pour les 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 l'opérateur CloudNative PostgreSQL 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 en 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 en flux entre les clusters régionaux principal et secondaire pour vous assurer que les données sont disponibles, même en cas de panne dans la région principale. Cette réplication en 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 garantit un temps d'arrêt et une perte de données minimaux. Voici un exemple d'extrait de configuration permettant d'activer les sauvegardes planifiées à l'aide de l'opérateur CloudNative PostgreSQL :

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 de base de données appropriées pour chaque cluster.

Étant donné que la réplication asynchrone entraîne un RPO non nul, il existe un risque de perte des écritures de données les plus récentes. Vous devez concevoir votre application pour atténuer 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 de 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 d'état et des règles de basculement.

Lorsque le cluster secondaire est promu d'une instance répliquée avec accès en lecture à une 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 prend en compte les scénarios de reprise après sinistre.
  • Tests : testez la restauration des secrets dans un environnement intermédiaire pour vérifier que tous les services peuvent démarrer avec les identifiants fournis.
  • Validation : vérifiez 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 à partir de magasins externes.

Mise en réseau et gestion du trafic

Utilisez Google Cloud's équilibreur de charge HTTPS externe global comme 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 utilisateur vers le cluster de backend approprié en fonction de la proximité, de l'état et de la disponibilité.

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

  • Utiliser des équilibreurs de charge régionaux (NEG Internet) : configurez Google Cloud des groupes de points de terminaison du réseau (NEG) Internet pour qu'ils pointent vers les adresses IP externes des équilibreurs de charge régionaux exposant les services d'entrée de chacun de vos clusters OpenShift (routeurs OCP). L'équilibreur de charge global 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 d'entrée OpenShift pour qu'il utilise Google Cloud des groupes de points de terminaison du réseau (NEG) de 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 entraîne généralement une latence plus faible et permet une vérification d'état plus directe à partir de l'équilibreur de charge global.

Les deux configurations permettent à l'équilibreur de charge mondial 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 recommandons les approches suivantes pour la gestion des VPC :

  • VPC partagé : utilisez un VPC partagé pour centraliser la gestion du réseau pour les clusters principal et secondaire. Cette approche simplifie l'administration et garantit des règles réseau cohérentes entre 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é transparente 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 de 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 plages d'adresses IP qui se chevauchent entre les régions pour éviter les problèmes de routage.

Trafic inter-cluster avec Red Hat Service Mesh

OpenShift prend en charge 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.

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