Modèles de continuité des opérations hybride et multicloud

Last reviewed 2025-01-23 UTC

L'objectif principal de la continuité des activités pour les systèmes critiques est d'aider une entreprise à être résiliente et à poursuivre ses activités pendant et après un incident. En répliquant les systèmes et les données sur plusieurs régions géographiques et en évitant les points de défaillance uniques, vous pouvez minimiser les risques de catastrophe naturelle affectant les infrastructures locales. D'autres scénarios de défaillance incluent une défaillance système grave, une attaque de cybersécurité ou même une erreur de configuration système.

L'optimisation d'un système pour qu'il résiste aux défaillances est essentielle pour établir une continuité d'activité efficace. La fiabilité du système peut être influencée par plusieurs facteurs, y compris, mais sans s'y limiter, les performances, la résilience, la disponibilité de l'application en ligne, la sécurité et l'expérience utilisateur. Pour en savoir plus sur la conception et l'exploitation de services fiables surGoogle Cloud, consultez le pilier Fiabilité du framework d'architecture Google Cloudet les composants fondamentaux de la fiabilité dans Google Cloud.

Ce modèle d'architecture repose sur un déploiement redondant d'applications dans plusieurs environnements informatiques. Dans ce modèle, vous déployez les mêmes applications dans plusieurs environnements informatiques dans le but d'accroître la fiabilité. La continuité d'activité peut être définie comme la capacité d'une organisation à poursuivre ses principales fonctions ou services métier à des niveaux acceptables prédéfinis après un événement perturbateur.

La reprise après sinistre (DR) est considérée comme un sous-domaine de la continuité des activités. Elle vise explicitement à garantir que les systèmes IT assurant des fonctions métier critiques sont opérationnels dès que possible après une perturbation. En général, les stratégies et plans de reprise après sinistre contribuent souvent à l'élaboration d'une stratégie plus globale de continuité des activités. D'un point de vue technologique, lorsque vous commencez à créer des stratégies de reprise après sinistre, votre analyse de l'impact sur l'entreprise doit définir deux métriques clés: l'objectif de point de récupération (RPO, Recovery Point Objective) et l'objectif de temps de récupération (RTO, Recovery Time Objective). Pour plus d'informations sur l'utilisation de Google Cloud pour la reprise après sinistre, consultez le guide de planification de reprise après sinistre.

Plus les valeurs cibles de RPO et de RTO sont faibles, plus les services peuvent récupérer rapidement d'une interruption avec une perte de données minimale. Toutefois, cela implique des coûts plus élevés, car cela implique de créer des systèmes redondants. Les systèmes redondants capables de répliquer des données en quasi temps réel et qui fonctionnent à la même échelle après un événement de défaillance augmentent la complexité, les frais administratifs et les coûts.

La décision de sélectionner une stratégie de reprise après sinistre ou un modèle doit être basée sur une analyse de l'impact commercial. Par exemple, les pertes financières subies par une entreprise de services financiers en cas de panne de quelques minutes peuvent largement dépasser le coût de l'implémentation d'un système de DR. Toutefois, les entreprises d'autres secteurs peuvent subir des heures d'arrêt sans que cela ait un impact significatif sur leur activité.

Lorsque vous exécutez des systèmes critiques dans un centre de données sur site, une approche de reprise après sinistre consiste à gérer les systèmes de secours dans un deuxième centre de données situé dans une autre région. Toutefois, une approche plus économique consiste à utiliser un environnement informatique basé sur un cloud public à des fins de basculement. Cette approche est le principal moteur du modèle de continuité d'activité hybride. Le cloud peut être particulièrement intéressant d'un point de vue coûteux, car il vous permet de désactiver une partie de votre infrastructure de reprise après sinistre lorsqu'elle n'est pas utilisée. Pour obtenir une solution de reprise après sinistre moins coûteuse, une solution cloud permet à une entreprise d'accepter l'augmentation potentielle des valeurs RPO et RTO.

Données transmises depuis un environnement sur site vers une instance de reprise après sinistre hébergée dans Google Cloud

Le schéma précédent illustre l'utilisation du cloud comme environnement de basculement ou de reprise après sinistre pour un environnement sur site.

Une variante moins courante (et rarement requise) de ce modèle est le modèle de continuité d'activité multicloud. Dans ce modèle, l'environnement de production utilise un fournisseur cloud et l'environnement de reprise après sinistre utilise un autre fournisseur cloud. En déployant des copies de charges de travail auprès de plusieurs fournisseurs cloud, vous pouvez obtenir une disponibilité supérieure à celle proposée par un déploiement multirégion.

Évaluer une reprise après sinistre dans plusieurs clouds par rapport à l'utilisation d'un fournisseur de services cloud avec différentes régions nécessite une analyse approfondie de plusieurs éléments, y compris les suivants:

  • Gestion
  • Sécurité
  • Faisabilité globale
  • Coût
    • Les frais potentiels de transfert de données sortantes de plusieurs fournisseurs de services cloud peuvent être élevés en cas de communication inter-cloud continue.
    • Le volume de trafic peut être élevé lors de la réplication de bases de données.
    • Le TCO et le coût de gestion de l'infrastructure réseau inter-cloud.

Si vos données doivent rester dans votre pays pour répondre aux exigences réglementaires, vous pouvez envisager d'utiliser un deuxième fournisseur cloud situé également dans votre pays comme solution de DR. L'utilisation d'un deuxième fournisseur de services cloud suppose qu'il n'est pas possible d'utiliser un environnement sur site pour créer une configuration hybride. Pour éviter de repenser votre solution cloud, dans l'idéal, votre deuxième fournisseur cloud doit proposer toutes les fonctionnalités et tous les services dont vous avez besoin dans la région.

Considérations de conception

  • Attentes concernant la DR: les objectifs de RPO et de RTO que votre entreprise souhaite atteindre doivent guider votre architecture de DR et la planification de la création.
  • Architecture de la solution: avec ce modèle, vous devez répliquer les fonctions et fonctionnalités existantes de votre environnement sur site pour répondre à vos attentes en matière de reprise après sinistre. Vous devez donc évaluer la faisabilité et la viabilité du rehosting, du refactoring ou de la refonte de vos applications pour fournir les mêmes fonctions et performances (ou plus optimisées) dans l'environnement cloud.
  • Concevoir et créer: la création d'une zone de destination est presque toujours une condition préalable au déploiement de charges de travail d'entreprise dans un environnement cloud. Pour en savoir plus, consultez la section Concevoir une zone de destination dans Google Cloud.
  • Appel de la reprise après sinistre: il est important que votre conception et votre processus de reprise après sinistre tiennent compte des questions suivantes:

    • Qu'est-ce qui déclenche un scénario de reprise après sinistre ? Par exemple, une DR peut être déclenchée par la défaillance de fonctions ou de systèmes spécifiques sur le site principal.
    • Comment le basculement vers l'environnement de reprise après sinistre est-il déclenché ? S'agit-il d'un processus d'approbation manuel ou peut-il être automatisé pour atteindre un objectif de RTO faible ?
    • Comment les mécanismes de détection et de notification des défaillances système doivent-ils être conçus pour appeler le basculement en fonction du RTO attendu ?
    • Comment le trafic est-il redirigé vers l'environnement de reprise après sinistre après la détection de la défaillance ?

    Validez vos réponses à ces questions par le biais de tests.

  • Tests: testez et évaluez minutieusement le basculement vers la reprise après sinistre. Assurez-vous qu'il répond à vos attentes en termes de RPO et de RTO. Cela vous permettra d'invoquer la DR plus facilement si nécessaire. Chaque fois qu'une modification ou une mise à jour est apportée au processus ou à la solution technologique, effectuez à nouveau les tests.

  • Compétences en équipe: une ou plusieurs équipes techniques doivent disposer des compétences et de l'expertise nécessaires pour créer, exploiter et résoudre les problèmes liés à la charge de travail de production dans l'environnement cloud, sauf si votre environnement est géré par un tiers.

Avantages

L'utilisation de Google Cloud pour la continuité de l'activité présente plusieurs avantages:

  • Comme Google Cloud propose un choix de nombreuses régions à travers le monde, vous pouvez l'utiliser pour sauvegarder ou répliquer des données sur un site différent du même continent. Vous pouvez également sauvegarder ou répliquer des données sur un site d'un autre continent.
  • Google Cloud permet de stocker des données dans Cloud Storage dans un bucket bi-régional ou multirégional. Les données sont stockées de manière redondante dans au moins deux régions géographiques distinctes. Les données stockées dans des buckets birégionaux et multirégionaux sont répliquées dans plusieurs régions géographiques à l'aide de la réplication par défaut.
    • Les buckets birégionaux offrent une géoredondance pour assurer la continuité des activités et les plans de reprise après sinistre. De plus, pour répliquer plus rapidement, avec un RPO plus faible, les objets stockés dans des régions duales peuvent éventuellement utiliser la réplication turbo dans ces régions.
    • De même, la réplication multirégionale offre une redondance dans plusieurs régions en stockant vos données dans les limites géographiques de la multirégion.
  • Fournit une ou plusieurs des options suivantes pour réduire les dépenses en capital et les dépenses opérationnelles afin de créer une reprise après sinistre :
    • Les instances de VM arrêtées n'engendrent que des coûts de stockage et sont nettement moins chères que les instances de VM en cours d'exécution. Vous pouvez ainsi réduire les coûts liés à la maintenance des systèmes de secours manuels.
    • Le modèle de tarification à l'utilisation de Google Cloud vous permet de ne payer que pour l'espace de stockage et la capacité de calcul que vous utilisez réellement.
    • Les fonctionnalités d'élasticité, comme l'autoscaling, vous permettent d'augmenter ou de réduire automatiquement votre environnement de DR selon les besoins.

Par exemple, le schéma suivant montre une application exécutée dans un environnement sur site (production) qui utilise des composants de récupération surGoogle Cloud avec Compute Engine, Cloud SQL et Cloud Load Balancing. Dans ce scénario, la base de données est préprovisionnée à l'aide d'une base de données basée sur une VM ou d'une base de données gérée Google Cloud , comme Cloud SQL, pour une récupération plus rapide avec une réplication de données continue. Vous pouvez lancer des VM Compute Engine à partir d'instantanés précréés pour réduire les coûts lors des opérations normales. Avec cette configuration, et après un événement de défaillance, le DNS doit pointer vers l'adresse IP externe de Cloud Load Balancing.

Application exécutée dans un environnement de production sur site à l'aide de composants de récupération sur Google Cloud avec Compute Engine, Cloud SQL et Cloud Load Balancing.

Pour que l'application soit opérationnelle dans le cloud, vous devez provisionner les VM Web et d'application. Selon le niveau de RTO ciblé et les règles de l'entreprise, l'ensemble du processus d'appel d'une DR, de provisionnement de la charge de travail dans le cloud et de réacheminement du trafic peut être effectué manuellement ou automatiquement.

Pour accélérer et automatiser le provisionnement de l'infrastructure, envisagez de la gérer en tant que code. Vous pouvez utiliser Cloud Build, un service d'intégration continue, pour appliquer automatiquement des fichiers manifestes Terraform à votre environnement. Pour en savoir plus, consultez la page Gérer une infrastructure en tant que code avec Terraform, Cloud Build et GitOps.

Bonnes pratiques

Lorsque vous utilisez le modèle de continuité d'activité, tenez compte des bonnes pratiques suivantes:

  • Créez un plan de reprise après sinistre qui documente votre infrastructure, ainsi que les procédures de basculement et de récupération.
  • Tenez compte des actions suivantes en fonction de votre analyse de l'impact commercial et des objectifs RPO et RTO requis :
    • Déterminez si la sauvegarde des données sur Google Cloud est suffisante ou si vous devez envisager une autre stratégie de reprise après sinistre (systèmes de secours à froid, tièdes ou à chaud).
    • Définissez les services et les produits que vous pouvez utiliser comme éléments de base pour votre plan de reprise après sinistre.
    • Définissez les scénarios de reprise après sinistre applicables à vos applications et à vos données dans le cadre de la stratégie de reprise après sinistre que vous avez sélectionnée.
  • Envisagez d'utiliser le modèle de transfert lorsque vous ne sauvegardez que des données. Sinon, le modèle en réseau maillé peut être une bonne option pour reproduire l'architecture réseau de l'environnement existant.
  • Réduisez les dépendances entre les systèmes exécutés dans des environnements différents, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances et réduire la disponibilité globale.
  • Évitez le problème de split-brain. Si vous répliquez des données de manière bidirectionnelle sur plusieurs environnements, vous pouvez être exposé au problème de split-brain. Le problème de split-brain se produit lorsque deux environnements qui répliquent des données de manière bidirectionnelle perdent la communication entre eux. Cette division peut amener les systèmes des deux environnements à conclure que l'autre environnement n'est pas disponible et qu'ils ont un accès exclusif aux données. Cela peut entraîner des modifications contradictoires des données. Il existe deux méthodes courantes pour éviter le problème de cerveau divisé:

    • Utiliser un troisième environnement IT Cet environnement permet aux systèmes de vérifier la présence d'un quorum avant de modifier les données.
    • Autorisez le rapprochement des modifications de données en conflit après la restauration de la connectivité.

      Avec les bases de données SQL, vous pouvez éviter le problème de split-brain en rendant l'instance principale d'origine inaccessible avant que les clients ne commencent à utiliser la nouvelle instance principale. Pour en savoir plus, consultez la page Reprise après sinistre de la base de données Cloud SQL.

  • Assurez-vous que les systèmes CI/CD et les dépôts d'artefacts ne se transforment pas en point de défaillance unique. Lorsqu'un environnement est indisponible, vous devez toujours pouvoir déployer de nouvelles versions ou appliquer des modifications de configuration.

  • Rendez toutes les charges de travail portables lorsque vous utilisez des systèmes de secours. Toutes les charges de travail doivent être portables (lorsque les applications le permettent et que cela est possible) afin que les systèmes restent cohérents dans tous les environnements. Pour ce faire, vous pouvez envisager d'utiliser des conteneurs et Kubernetes. En utilisant l'édition Enterprise de Google Kubernetes Engine (GKE), vous pouvez simplifier la compilation et les opérations.

  • Intégrez le déploiement de systèmes de secours dans votre pipeline CI/CD. Cette intégration permet de garantir la cohérence des versions et des configurations d'applications dans tous les environnements.

  • Assurez-vous que les modifications DNS sont propagées rapidement en configurant votre DNS avec une valeur TTL relativement courte afin de pouvoir rediriger les utilisateurs vers des systèmes de secours en cas de sinistre.

  • Sélectionnez les règles DNS et de routage qui correspondent à votre architecture et au comportement de votre solution. Vous pouvez également combiner plusieurs équilibreurs de charge régionaux avec des règles de routage DNS pour créer des architectures d'équilibrage de charge global pour différents cas d'utilisation, y compris la configuration hybride.

  • Utilisez plusieurs fournisseurs DNS. Lorsque vous utilisez plusieurs fournisseurs DNS, vous pouvez:

    • Améliorez la disponibilité et la résilience de vos applications et services.
    • Simplifiez le déploiement ou la migration d'applications hybrides qui ont des dépendances dans les environnements sur site et cloud grâce à une configuration DNS multifournisseur.

      Google Cloud propose une solution Open Source basée sur octoDNS pour vous aider à configurer et à exploiter un environnement avec plusieurs fournisseurs DNS. Pour en savoir plus, consultez la section DNS public multifournisseur avec Cloud DNS.

  • Utilisez des équilibreurs de charge lorsque vous utilisez des systèmes de secours pour créer un basculement automatique. N'oubliez pas que le matériel de l'équilibreur de charge peut tomber en panne.

  • Utilisez Cloud Load Balancing au lieu d'équilibreurs de charge matériels pour alimenter certains scénarios qui se produisent lorsque vous utilisez ce modèle d'architecture. Les requêtes client internes ou les requêtes client externes peuvent être redirigées vers l'environnement principal ou l'environnement de reprise après sinistre en fonction de différentes métriques, telles que la division du trafic basée sur le poids. Pour en savoir plus, consultez la section Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.

  • Envisagez d'utiliser Cloud Interconnect ou Cross-Cloud Interconnect si le volume de transfert de données sortant de Google Cloud vers l'autre environnement est élevé. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et peut réduire les frais de transfert de données sortants pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.

  • Envisagez d'utiliser la solution partenaire de votre choix sur Google Cloud Marketplace pour faciliter les sauvegardes et les réplications de données, ainsi que les autres tâches qui répondent à vos exigences, y compris vos cibles de RPO et de RTO.

  • Testez et évaluez les scénarios d'appel de DR pour comprendre dans quelle mesure l'application peut se remettre d'un sinistre par rapport à la valeur cible de RTO.

  • Chiffrez les communications en transit. Pour protéger les informations sensibles, nous vous recommandons de chiffrer toutes les communications en transit. Si le chiffrement est requis au niveau de la couche de connectivité, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, HA VPN via Cloud Interconnect et MACsec pour Cloud Interconnect.