Concevoir une solution de reprise après sinistre pour des charges de travail limitées à la localité

Last reviewed 2022-06-10 UTC

Ce document explique comment utiliser Google Cloud pour concevoir une solution de reprise après sinistre (DR, Disaster Recovery) afin de répondre aux exigences spécifiques à un emplacement. Pour certains secteurs réglementés, les charges de travail doivent respecter ces exigences. Dans ce cas de figure, une ou plusieurs des exigences suivantes s'appliquent :

  • Les données au repos doivent être limitées à un pays spécifié.
  • Les données doivent être traitées dans le pays où elles résident.
  • Les charges de travail ne sont accessibles qu'à partir d'emplacements prédéfinis.
  • Les données doivent être chiffrées à l'aide de clés gérées par le client.
  • Si vous utilisez des services cloud, chacun d'entre eux doit fournir au moins deux emplacements redondants. Pour obtenir un exemple d'exigences de redondance des emplacements, consultez le Cloud Computing Compliance Criteria Catalogue (directive C5).

Cet article constitue la cinquième partie d'une série qui traite de la reprise après sinistre (DR, Disaster Recovery) dans Google Cloud. Il décrit le processus de planification de reprise après sinistre et vous explique comment établir et mettre en œuvre un plan de reprise.

La série comprend les éléments suivants :

Terminologie

Avant de commencer à concevoir une solution de DR pour des charges de travail limitées à la localité, il est recommandé de consulter la terminologie liée à la localité utilisée dans Google Cloud.

Google Cloud fournit des services dans des régions des Amériques, d'Europe et du Moyen-Orient, ainsi qu'en Asie-Pacifique. Par exemple, Londres (europe-west2) est une région située en Europe, et l'Oregon (us-west1) est une région située en Amérique du Nord. Certains produits Google Cloud regroupent plusieurs régions dans un emplacement multirégional spécifique, accessible de la même manière que vous utiliseriez une région.

Les régions sont également divisées en zones dans lesquelles vous déployez certaines ressources Google Cloud telles que des machines virtuelles, des clusters Kubernetes ou des bases de données Cloud SQL. Les ressources sur Google Cloud sont multirégionales, régionales ou zonales. Certains ressources et certains produits désignés par défaut comme multirégionaux peuvent également être limités à une région. Les différents types de ressources sont expliqués comme suit :

  • Les ressources multirégionales sont conçues par Google Cloud pour être redondantes et distribuées dans et entre les régions. Les ressources multirégionales sont résilientes à l'échec d'une seule région.
  • Les ressources régionales sont déployées de façon redondante dans plusieurs zones d'une région et résistent aux défaillances d'une zone de la région.
  • Les ressources zonales fonctionnent dans une seule zone. Si une zone devient indisponible, toutes les ressources zonales qu'elle comporte ne peuvent plus être utilisées tant que le service n'est pas restauré. Considérez une zone comme un domaine de défaillance unique. Vous devez concevoir vos applications de sorte à limiter les effets de l'indisponibilité d'une seule zone.

Le tableau suivant montre la relation actuelle entre les régions, les zones et les emplacements pour l'Europe.

Région Zones Emplacement
europe-north1 a, b, c Hamina, Finlande
europe-west1 b, c, d Saint-Ghislain, Belgique
europe-west2 a, b, c Londres, Angleterre, Royaume-Uni
europe-west3 a, b, c Francfort, Allemagne
europe-west4 a, b, c Eemshaven, Pays-Bas
europe-west6 a, b, c Zurich, Suisse

Pour plus d'informations, consultez la page Zones géographiques et régions.

Planifier la reprise après sinistre pour les charges de travail limitées à la localité

L'approche à adopter pour concevoir votre application dépend du type de charge de travail et des exigences que vous devez remplir en termes de localité. Déterminez également les raisons pour lesquelles vous devez répondre à ces exigences, car ce que vous décidez a une incidence directe sur votre architecture de DR.

Commencez par lire le guide de planification de reprise après sinistre de Google Cloud. Si vous envisagez des charges de travail limitées à la localité, concentrez-vous sur les exigences décrites dans cette section de planification.

Définir vos exigences en termes de localité

Avant de débuter la conception, définissez vos exigences en termes de localité en répondant aux questions suivantes :

  • Où se trouvent les données au repos ? La réponse détermine les services que vous pouvez utiliser, ainsi que les méthodes de haute disponibilité et de reprise après sinistre que vous pouvez employer pour atteindre vos valeurs de RTO/RPO. Consultez la page Emplacements Cloud pour déterminer quels produits sont couverts.
  • Existe-t-il des techniques de chiffrement permettant de limiter cette exigence ? Si vous êtes en mesure de limiter les exigences en termes de localité en employant des techniques de chiffrement avec Cloud External Key Manager et Cloud Key Management Service, vous pouvez utiliser des services multirégionaux et birégionaux, et appliquer les techniques de haute disponibilité/reprise après sinistre décrites sur la page Scénarios de reprise après sinistre pour les données.

  • Les données peuvent-elles être traitées en dehors de leur emplacement de repos ? Vous pouvez utiliser des produits tels que GKE Enterprise pour fournir un environnement hybride répondant à vos besoins ou mettre en œuvre des contrôles spécifiques aux produits, tels que l'équilibrage de charge des instances Compute Engine sur plusieurs zones d'une région. Utilisez la contrainte d'emplacement des ressources de la règle d'administration pour limiter l'emplacement où les ressources peuvent être déployées.

    Si les données peuvent être traitées en dehors de l'emplacement où elles doivent être au repos, vous pouvez concevoir les parties "traitement" de votre application en suivant les instructions figurant sur les pages Structure de la reprise après sinistre et Scénarios de reprise après sinistre pour les applications.

    Configurez un périmètre VPC Security Controls pour contrôler qui peut accéder aux données et limiter les ressources pouvant les traiter.

  • Pouvez-vous utiliser plusieurs régions ? Si vous pouvez utiliser plusieurs régions, vous pouvez utiliser la plupart des techniques décrites dans la série sur la reprise après sinistre. Vérifiez les contraintes liées aux régions et aux emplacements multirégionaux pour les produits Google Cloud.

  • Avez-vous besoin de limiter l'accès à votre application ? Google Cloud propose plusieurs produits et fonctionnalités qui vous aident à limiter l'accès à vos applications :

    • Identity-Aware Proxy (IAP). Cette fonctionnalité vérifie l'identité d'un utilisateur, puis détermine si cet utilisateur doit être autorisé à accéder à une application. La règle d'administration utilise la contrainte de partage restreint de domaine pour définir les ID Cloud Identity ou d'espace de travail Google autorisés dans les stratégies IAM.
    • Contrôles de localité spécifiques aux produits. Reportez-vous à chaque produit que vous souhaitez utiliser dans votre architecture pour connaître les contraintes de localité appropriées. Par exemple, utilisez le gestionnaire de configuration GKE Enterprise pour appliquer des règles spécifiques à la localité à vos clusters GKE gérés par GKE Enterprise. Si vous utilisez Cloud Storage, créez des buckets dans des régions spécifiées.

Identifier les services que vous pouvez utiliser

Identifiez les services qui peuvent être utilisés en fonction de vos exigences en termes de localité et de précision régionale. La conception d'applications soumises à des restrictions de localité nécessite de comprendre quels produits peuvent être limités à quelle région et quels contrôles peuvent être mis en œuvre pour appliquer les exigences de restriction d'emplacement.

Identifier la précision régionale pour votre application et vos données

Identifiez la précision régionale pour votre application et vos données en répondant aux questions suivantes :

  • Pouvez-vous utiliser des services multirégionaux dans votre conception ? En utilisant des services multirégionaux, vous pouvez créer des architectures résilientes à disponibilité élevée.
  • L'accès à votre application est-il soumis à des restrictions d'emplacement ? Utilisez ces produits Google Cloud pour appliquer les exigences concernant les emplacements à partir desquels vos applications sont accessibles :
    • Google Cloud Armor. Vous permet de mettre en œuvre des contraintes basées sur les adresses IP et la géolocalisation.
    • VPC Service Controls. Fournit un périmètre de sécurité basé sur le contexte.
  • Vos données au repos sont-elles limitées à une région spécifique ? Si vous utilisez des services gérés, assurez-vous que les services que vous utilisez peuvent être configurés de sorte que vos données stockées dans ceux-ci soient limitées à une région spécifique. Par exemple, utilisez les restrictions de localité de BigQuery pour déterminer où vos ensembles de données sont stockés et sauvegardés.
  • À quelles régions devez-vous limiter votre application ? Certains produits Google Cloud ne sont soumis à aucune restriction régionale. Consultez la page Emplacements Cloud et les pages propres à chaque produit pour vérifier dans quelles régions vous pouvez utiliser le produit, et quelles fonctionnalités d'atténuation sont disponibles le cas échéant pour limiter votre application à une région spécifique.

Respecter les restrictions de localité liées à l'utilisation des produits Google Cloud

Cette section décrit les fonctionnalités et les techniques d'atténuation permettant d'utiliser les produits Google Cloud dans le cadre de votre stratégie de DR pour les charges de travail limitées à la localité. Nous vous recommandons de lire cette section ainsi que la page Structure de la reprise après sinistre.

Règles d'administration

Le service de règles d'administration vous offre un contrôle centralisé sur vos ressources Google Cloud. À l'aide de règles d'administration, vous pouvez configurer des restrictions sur l'ensemble de votre hiérarchie de ressources. Tenez compte des contraintes liées aux règles suivantes lors de la conception des charges de travail limitées à la localité :

  • Partage restreint de domaine : par défaut, toutes les identités d'utilisateur peuvent être ajoutées aux stratégies IAM. La liste des membres autorisés/refusés doit spécifier une ou plusieurs identités client Cloud Identity ou d'espace de travail Google. Si cette contrainte est active, seules les identités figurant dans la liste des autorisations peuvent être ajoutées aux stratégies IAM.

  • Ressources avec restrictions d'emplacement : cette contrainte fait référence à l'ensemble des emplacements dans lesquels des ressources Google Cloud basées sur l'emplacement peuvent être créées. Les règles de cette contrainte peuvent spécifier les emplacements suivants comme étant autorisés ou refusés : des emplacements multirégionaux (Asie et Europe, par exemple), des régions (telles que us-east1 ou europe-west1) ou des zones individuelles (telles que europe-west1-b). Pour obtenir la liste des services compatibles, consultez la page Services compatibles avec les emplacements de ressources.

Chiffrement

Si vos exigences en termes de localité des données concernent la restriction d'accès aux données, la mise en œuvre de méthodes de chiffrement peut être une stratégie applicable. En utilisant des systèmes de gestion de clés externes pour gérer les clés que vous fournissez en dehors de Google Cloud, vous pouvez déployer une architecture multirégionale pour répondre à vos exigences en termes de localité. Si les clés ne sont pas disponibles, les données ne peuvent pas être déchiffrées.

Google Cloud propose deux produits qui vous permettent d'utiliser des clés que vous gérez :

  • Cloud External Key Manager (Cloud EKM) : Cloud EKM vous permet de chiffrer les données dans BigQuery et Compute Engine avec des clés de chiffrement stockées et gérées dans un système de gestion des clés tiers déployé en dehors de l'infrastructure de Google.

  • Clés de chiffrement fournies par le client (CSEK, Customer-Supplied Encryption Key) : vous pouvez utiliser des clés CSEK avec Cloud Storage et Compute Engine. Google utilise votre clé pour protéger les clés générées par Google qui sont utilisées pour chiffrer et déchiffrer vos données.

    Si vous spécifiez une clé CSEK, Google ne la stocke pas de manière permanente sur les serveurs Google et ne la gère pas. Vous devez la fournir pour chaque opération, et elle est supprimée définitivement des serveurs Google une fois l'opération terminée.

Lorsque vous gérez votre propre infrastructure de clés, vous devez examiner attentivement les questions de la latence et de la fiabilité, et vous assurer que vous mettez en œuvre des processus de récupération et de haute disponibilité adaptés à votre gestionnaire de clés externes. Vous devez également comprendre vos exigences de RTO. Les clés font partie intégrante de l'écriture des données. Par conséquent, le RPO n'est pas la principale préoccupation, car aucune donnée ne peut être écrite en toute sécurité sans les clés. Le véritable problème est le RTO, car sans vos clés, vous ne pouvez pas déchiffrer ni écrire des données en toute sécurité.

Stockage

Lorsque vous concevez une solution de DR pour des charges de travail limitées à la localité, vous devez vous assurer que les données au repos sont situées dans la région requise. Vous pouvez configurer les services de stockage d'objets et de fichiers Google Cloud pour répondre à vos exigences.

Cloud Storage

Vous pouvez créer des buckets Cloud Storage qui respectent les restrictions de localité.

Outre les fonctionnalités décrites dans la section Cloud Storage de l'article "Structure de la reprise après sinistre", lorsque vous concevez une solution de DR pour des charges de travail limitées à la localité, déterminez si la redondance entre régions est une exigence : les objets stockés dans des emplacements multirégionaux et des emplacements birégionaux sont stockés dans au moins deux zones géographiquement distinctes, quelle que soit de leur classe de stockage. La géoredondance garantit une disponibilité maximale de vos données, même pendant des perturbations majeures, telles que des catastrophes naturelles. Les emplacements birégionaux permettent d'obtenir cette redondance en utilisant une paire de régions que vous choisissez. Les multirégions obtiennent la géoredondance en utilisant n'importe quelle combinaison de centres de données dans l'emplacement multirégional spécifié, ce qui peut inclure des centres de données qui ne sont pas explicitement répertoriés comme régions disponibles.

La synchronisation des données entre les buckets s'effectue de manière asynchrone. Si avoir la certitude que les données ont été écrites dans une autre région revêt une grande importance pour vous afin de respecter vos valeurs de RTO et de RPO, une stratégie consiste à utiliser deux buckets à région unique. Vous pouvez ensuite écrire l'objet en double, ou bien l'écrire dans un bucket et faire en sorte que Cloud Storage le copie (rewriteTo) dans le second bucket.

Stratégies d'atténuation dans une seule région lors de l'utilisation de Cloud Storage

Si vos exigences vous obligent à utiliser une seule région (par exemple, Londres ou Zurich), vous êtes limité à cette région et ne pouvez pas implémenter une architecture redondante entre les emplacements géographiques en n'utilisant que Google Cloud. Dans ce scénario, vous pouvez envisager d'utiliser une ou plusieurs des techniques suivantes :

  • Adoptez une stratégie multicloud ou hybride. Cette approche vous permet de choisir une autre solution cloud ou sur site dans la même zone géographique que votre région Google Cloud. Vous pouvez stocker des copies de vos données dans des buckets Cloud Storage sur site ou utiliser Cloud Storage comme cible pour vos données de sauvegarde.

    Pour utiliser cette approche, procédez comme suit :

    • Assurez-vous que les exigences de distance sont remplies.
    • Si vous utilisez AWS en tant qu'autre fournisseur cloud, consultez le guide sur l'interopérabilité de Cloud Storage pour savoir comment configurer l'accès à Amazon S3 à l'aide des outils Google Cloud.
    • Pour les autres solutions cloud et sur site, envisagez des solutions Open Source telles que minIO et Ceph pour fournir un magasin d'objets sur site.
    • Envisagez d'utiliser des solutions partenaires pour fournir un magasin d'objets sur site.
    • Envisagez d'utiliser une solution partenaire pour mettre en œuvre des workflows vous permettant d'écrire des données dans Cloud Storage et dans un service de stockage d'objets d'un autre fournisseur cloud.
    • Envisagez d'utiliser Cloud Composer avec l'utilitaire de ligne de commande gsutil pour transférer des données d'un magasin d'objets sur site vers Cloud Storage.
    • Utilisez le service de transfert des données sur site pour copier des données stockées sur site dans Cloud Storage.

  • Mettez en œuvre des techniques de chiffrement. Si vos exigences en termes de localité autorisent l'utilisation de techniques de chiffrement comme solution de contournement, vous pouvez utiliser des buckets multirégionaux ou birégionaux.

Filestore

Filestore fournit un stockage de fichiers géré que vous pouvez déployer dans des régions et des zones en fonction de vos exigences de restriction de localité.

Bases de données gérées

La page Scénarios de reprise après sinistre pour les données décrit les méthodes permettant de mettre en œuvre des stratégies de sauvegarde et de récupération pour les services de base de données gérés de Google Cloud. En plus de ces méthodes, vous devez également prendre en compte les restrictions de localité pour chaque service de base de données géré que vous utilisez dans votre architecture. Exemple :

  • Bigtable est disponible dans les emplacements zonaux d'une région. Les instances de production ont au moins deux clusters, qui doivent se trouver dans des zones uniques de la région. La réplication entre les clusters d'une instance Bigtable est automatiquement gérée par Google. Bigtable synchronise vos données entre les clusters, en créant une copie distincte et indépendante de vos données dans chaque zone où votre instance comporte un cluster. La réplication permet au trafic entrant de basculer vers un autre cluster de la même instance.

  • Des restrictions de localité s'appliquent à BigQuery et déterminent où vos ensembles de données sont stockés. Les emplacements des ensembles de données peuvent être régionaux ou multirégionaux. Pour assurer la résilience en cas de catastrophe régionale, vous devez sauvegarder les données dans un autre emplacement géographique. Dans le cas d'emplacements multirégionaux BigQuery, nous vous recommandons d'éviter d'effectuer des sauvegardes dans des régions qui font partie de l'emplacement multirégional concerné. Si vous sélectionnez l'emplacement multirégional "EU", vous excluez Zurich et Londres de la configuration multirégionale. Pour obtenir des conseils sur la mise en œuvre d'une solution de DR pour BigQuery qui puisse résister à l'événement improbable d'une perte régionale physique, consultez la section Perte de région.

    Pour comprendre les implications de l'adoption des configurations BigQuery régionales ou multirégionales, consultez la documentation BigQuery.

  • Vous pouvez utiliser Firestore pour stocker vos données Firestore dans un emplacement multirégional ou régional. Les données comprises dans une zone multirégionale sont traitées au sein d'une configuration répliquée multizone et multirégionale. Sélectionnez un emplacement multirégional si vos exigences en matière de restriction de la localité le permettent et si vous souhaitez maximiser la disponibilité et la durabilité de votre base de données. En effet, les emplacements multirégionaux peuvent supporter la perte de régions entières et maintenir la disponibilité sans perte de données. Les données comprises dans un emplacement régional sont traitées au sein d'une configuration répliquée multizone.

  • Vous pouvez configurer Cloud SQL pour la haute disponibilité. Une instance Cloud SQL configurée pour la haute disponibilité est également appelée "instance régionale". Elle se situe dans une zone principale et dans une zone secondaire de la région configurée. Dans une instance régionale, la configuration se compose d'une instance principale et d'une instance de secours. Assurez-vous de bien comprendre le temps moyen de basculement de l'instance principale à l'instance de secours.

    Si vos exigences le permettent, vous pouvez configurer Cloud SQL avec des instances dupliquées interrégionales. En cas de sinistre, l'instance dupliquée avec accès en lecture dans une région différente peut être promue. Étant donné que les instances dupliquées avec accès en lecture peuvent être configurées pour la haute disponibilité à l'avance, elles n'ont pas besoin de modifications supplémentaires après cette promotion. Vous pouvez également configurer des instances dupliquées avec accès en lecture pour qu'elles aient leurs propres instances dupliquées interrégionales qui offrent une protection immédiate contre les défaillances régionales après la promotion de l'instance dupliquée.

  • Vous pouvez configurer Spanner comme étant régional ou multirégional. Pour toute configuration régionale, Spanner gère trois instances répliquées avec accès en lecture/écriture, chacune étant dans une zone Google Cloud différente dans cette région. Chaque instance dupliquée avec accès en lecture/écriture contient une copie complète de votre base de données opérationnelle, capable de diffuser les requêtes en lecture/écriture et en lecture seule.

    Spanner utilise des instances répliquées dans différentes zones, de sorte que votre base de données reste disponible en cas de défaillance d'une zone unique. Un déploiement multirégional Spanner fournit un environnement cohérent dans plusieurs régions, y compris deux régions de lecture/écriture et une région témoin contenant une instance répliquée témoin. Vous devez vérifier que les emplacements de toutes les régions respectent vos exigences de restriction de localité.

Compute Engine

Les ressources Compute Engine sont globales, régionales ou zonales. Les ressources Compute Engine telles que les instances de machines virtuelles ou les disques persistants zonaux sont appelées ressources zonales. D'autres ressources, telles que les adresses IP externes statiques, sont régionales. Les ressources régionales peuvent être utilisées par toutes les ressources de cette région, quelle que soit la zone, tandis que les ressources zonales ne peuvent être utilisées que par d'autres ressources de la même zone.

Le positionnement des ressources dans différentes zones d'une région les protège contre la plupart des pannes d'infrastructure physique et des pannes des services logiciels d'infrastructure. En outre, le positionnement des ressources dans différentes régions offre un degré encore plus élevé d'indépendance en cas de panne. Cette approche vous permet de concevoir des systèmes robustes dont les ressources sont réparties sur différents domaines de défaillance.

Pour en savoir plus, consultez la page Régions et zones.

Utiliser un environnement sur site ou un autre cloud comme site de production

Il se peut que vous utilisiez une région Google Cloud qui vous empêche d'utiliser des combinaisons birégionales ou multirégionales pour votre architecture de DR. Dans ce cas de figure, pour respecter les restrictions de localité, envisagez d'utiliser votre propre centre de données ou un autre cloud comme site de production ou site de basculement.

Cette section traite des produits Google Cloud optimisés pour les charges de travail hybrides. Les architectures de DR qui utilisent un environnement sur site et Google Cloud sont décrites sur la page Scénarios de reprise après sinistre pour les applications.

GKE Enterprise

GKE Enterprise est la plate-forme d'applications hybride ouverte et multicloud de Google Cloud qui vous aide à exécuter vos charges de travail basées sur des conteneurs en toute sécurité. GKE Enterprise garantit la cohérence entre les environnements sur site et cloud, ce qui vous permet d'avoir un modèle d'exploitation cohérent et une vue unique de vos clusters Google Kubernetes Engine (GKE), quel que soit l'endroit où vous les exécutez.

Dans le cadre de votre stratégie de DR, GKE Enterprise simplifie la configuration et l'exploitation des architectures haute disponibilité et de basculement dans des environnements différents (entre Google Cloud et un environnement sur site ou un autre cloud). Vous pouvez exécuter vos clusters de production GKE Enterprise sur site. En cas de sinistre, vous pouvez basculer pour exécuter les mêmes charges de travail sur les clusters GKE Enterprise dans Google Cloud.

GKE Enterprise sur Google Cloud propose trois types de clusters:

  • Cluster à zone unique. Un cluster à zone unique possède un seul plan de contrôle s'exécutant dans une zone. Ce plan de contrôle gère les charges de travail sur les nœuds qui s'exécutent dans la même zone.
  • Cluster multizone. Un cluster multizone comporte une seule instance dupliquée du plan de contrôle s'exécutant dans une seule zone et plusieurs nœuds s'exécutant dans plusieurs zones.
  • Cluster régional. Les clusters régionaux répliquent les instances principales et les nœuds de cluster dans plusieurs zones d'une même région. Par exemple, un cluster régional dans la région us-east1 crée des instances dupliquées du plan de contrôle et des nœuds dans trois zones us-east1 : us-east1-b, us-east1-c et us-east1-d.

Les clusters régionaux sont les plus résilients aux pannes zonales.

Google Cloud VMware Engine

Google Cloud VMware Engine vous permet d'exécuter des charges de travail VMware dans le cloud. Si vos charges de travail sur site sont basées sur VMware, vous pouvez concevoir votre solution de DR pour qu'elle s'exécute sur la même solution de virtualisation que celle sur site. Vous pouvez sélectionner la région qui répond à vos exigences en termes de localité.

Mise en réseau

Lorsque votre plan de DR est basé sur le déplacement des données sur site vers Google Cloud ou depuis un autre fournisseur cloud vers Google Cloud, vous devez élaborer votre stratégie de mise en réseau. Pour plus d'informations, consultez la section Transférer des données vers et depuis Google Cloud du document "Structure de la reprise après sinistre".

VPC Service Controls

Lorsque vous planifiez votre stratégie de DR, vous devez vous assurer que les contrôles de sécurité qui s'appliquent à votre environnement de production s'étendent également à votre environnement de basculement. En utilisant VPC Service Controls, vous pouvez définir un périmètre de sécurité allant des réseaux sur site à vos projets dans Google Cloud.

L'approche de VPC Service Controls pour le contrôle des ressources cloud repose sur l'activation de l'accès contextuel. Vous pouvez créer des règles précises de contrôle d'accès dans Google Cloud sur la base d'attributs tels que l'identité des utilisateurs et l'adresse IP. Ces règles permettent de s'assurer que les contrôles de sécurité appropriés sont mis en place dans vos environnements sur site et Google Cloud.

Étape suivante