L'objectif principal de la continuité des opérations pour les systèmes stratégiques est d'aider une organisation à être résiliente et à poursuivre ses activités commerciales pendant et après des événements de défaillance. 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 grave défaillance du système, une attaque de cybersécurité ou même une erreur de configuration du système.
Il est essentiel d'optimiser un système pour qu'il résiste aux défaillances afin d'assurer une continuité des activités efficace. La fiabilité d'un système peut être influencée par plusieurs facteurs, y compris, mais sans s'y limiter, les performances, la résilience, la disponibilité, 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 Google Cloud Well-Architected Framework et 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é des activités peut être définie comme la capacité d'une organisation à poursuivre ses fonctions ou services clés à des niveaux acceptables prédéfinis à la suite d'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 informatiques assurant des fonctions métier critiques sont opérationnels dès que possible après une interruption. 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 commercial doit définir deux métriques clés : l'objectif de point de récupération (RPO) et l'objectif de temps de récupération (RTO). Pour plus de conseils sur l'utilisation de Google Cloud dans le cadre de 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 un coût plus élevé, car cela signifie qu'il faut créer des systèmes redondants. Les systèmes redondants capables d'effectuer une réplication des données en temps quasi réel et fonctionnant à la même échelle après un événement d'échec augmentent la complexité, les frais administratifs et les coûts.
Le choix d'une stratégie de reprise après sinistre ou d'un modèle doit être basé sur une analyse de l'impact commercial. Par exemple, les pertes financières subies par une organisation de services financiers, même en cas de quelques minutes d'indisponibilité, peuvent dépasser de loin le coût de l'implémentation d'un système de reprise après sinistre. Toutefois, les entreprises d'autres secteurs peuvent supporter des heures d'indisponibilité 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 Continuité d'activité hybride. Le cloud peut être particulièrement intéressant d'un point de vue financier, 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 à moindre coût, une solution cloud permet à une entreprise d'accepter l'augmentation potentielle des valeurs RPO et RTO.
Le schéma précédent illustre l'utilisation du cloud comme environnement de reprise après sinistre ou de basculement vers 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.
L'évaluation d'une reprise après sinistre dans plusieurs clouds par rapport à l'utilisation d'un seul fournisseur de 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 depuis plusieurs fournisseurs de services cloud peuvent être coûteux en cas de communication inter-cloud continue.
- La réplication de bases de données peut générer un volume de trafic élevé.
- le coût total de possession et le coût de gestion de l'infrastructure réseau multicloud.
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 de services cloud situé également dans votre pays comme solution de reprise après sinistre. 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 restructurer votre solution cloud, votre deuxième fournisseur de services cloud doit idéalement proposer toutes les fonctionnalités et tous les services requis dans la région.
Considérations de conception
- Attentes en matière de reprise après sinistre : les objectifs de RPO et de RTO que votre entreprise souhaite atteindre doivent orienter votre architecture de reprise après sinistre et la planification de la création.
- Architecture de la solution : avec ce modèle, vous devez répliquer les fonctions et les capacité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 réhébergement, de la refactorisation ou de la réarchitecture de vos applications afin de fournir les mêmes fonctions et performances (ou des fonctions et performances plus optimisées) dans l'environnement cloud.
- Concevez et créez : 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 Conception de la zone d'atterrissage 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 reprise après sinistre 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 temps de récupération (RTO) faible ?
- Comment concevoir les mécanismes de détection et de notification des défaillances système pour déclencher le basculement conformément au RTO attendu ?
- Comment le trafic est-il redirigé vers l'environnement de reprise après sinistre une fois la défaillance détectée ?
Validez vos réponses à ces questions en effectuant des 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 peut vous donner plus d'assurance pour invoquer la reprise après sinistre si nécessaire. Chaque fois qu'une nouvelle modification ou mise à jour est apportée au processus ou à la solution technologique, effectuez à nouveau les tests.
Compétences de l'é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é des activités offre 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 vous permet de stocker des données dans Cloud Storage dans un bucket biré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 des 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 une réplication plus rapide avec un RPO plus faible, les objets stockés dans des régions doubles peuvent éventuellement utiliser la réplication turbo entre 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 région multiple.
- Fournit une ou plusieurs des options suivantes pour réduire les dépenses en capital et les dépenses d'exploitation 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 signifie que vous ne payez 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'adapter automatiquement la taille de votre environnement de reprise après sinistre selon vos 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 continue des données. 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 d'échec, le DNS doit pointer vers l'adresse IP externe de 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'invocation d'une reprise après sinistre, de provisionnement de la charge de travail dans le cloud et de redirection 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 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.
- En fonction de votre analyse de l'impact sur l'activité et des objectifs de RPO et de RTO requis identifiés, envisagez les actions suivantes :
- 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 maillé peut être une bonne option pour répliquer 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 séparation peut amener les systèmes des deux environnements à conclure que l'autre environnement n'est pas disponible et qu'ils disposent d'un accès exclusif aux données. Cela peut entraîner des modifications conflictuelles des données. Il existe deux façons courantes d'éviter le problème de split-brain :
- Utilisez un environnement informatique tiers. 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 Reprise après sinistre pour les bases 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 faisable) afin que les systèmes restent cohérents dans tous les environnements. Vous pouvez y parvenir en utilisant des conteneurs et Kubernetes. En utilisant 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. Vous pourrez ainsi rediriger les utilisateurs vers des systèmes de secours en cas de sinistre.
Sélectionnez la règle DNS et la règle 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 des environnements sur site et cloud grâce à une configuration DNS multi-fournisseurs.
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 DNS public multi-fournisseurs utilisant Cloud DNS.
Lorsque vous utilisez des systèmes de secours, créez un basculement automatique à l'aide d'équilibreurs de charge. 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 certains scénarios qui se produisent lorsque vous utilisez ce modèle d'architecture. Les requêtes de clients internes ou les requêtes de clients 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 répartition du trafic basée sur le poids. Pour en savoir plus, consultez la présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.
Envisagez d'utiliser Cloud Interconnect ou interconnexion cross-cloud si le volume de données sortantes 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 sortantes pour le trafic qui remplit 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 réplications de données, ainsi que d'autres tâches qui répondent à vos exigences, y compris vos objectifs de RPO et de RTO.
Testez et évaluez les scénarios d'invocation de la reprise après sinistre pour comprendre dans quelle mesure l'application peut se remettre d'un sinistre par rapport à la valeur RTO cible.
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 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.