Cet article constitue la deuxième partie d'une série qui traite de la reprise après sinistre (DR, Disaster Recovery) dans Google Cloud. Cette partie traite des services et des produits que vous pouvez utiliser comme structure pour votre plan de reprise après sinistre, qu'il s'agisse de produits Google Cloud ou de produits sur plusieurs plates-formes.
La série comprend les éléments suivants :
- Guide de planification de reprise après sinistre
- Structure de la reprise après sinistre (cet article)
- Scénarios de reprise après sinistre pour les données
- Scénarios de reprise après sinistre pour les applications
- Concevoir une solution de reprise après sinistre pour des charges de travail limitées à la localité
- Cas d'utilisation de reprise après sinistre : applications d'analyse de données limitées à la localité
- Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud
Introduction
Google Cloud propose un large éventail de produits que vous pouvez utiliser dans le cadre de votre architecture de reprise après sinistre. Dans cette section, nous traitons des fonctionnalités des produits de reprise après sinistre les plus couramment utilisées en tant que structure de reprise après sinistre Google Cloud.
Beaucoup de ces services disposent de fonctionnalités haute disponibilité. La haute disponibilité ne couvre pas entièrement la reprise après sinistre, mais bon nombre de ses objectifs s'appliquent également à la conception d'un plan de reprise après sinistre. Par exemple, en tirant parti des fonctionnalités de haute disponibilité, vous pouvez concevoir des architectures optimisant le temps d'activité et permettant d'atténuer les effets des défaillances à petite échelle, telles que sur une seule VM. Pour plus d'informations sur les relations entre reprise après sinistre et haute disponibilité, consultez le Guide de planification de reprise après sinistre.
Les sections suivantes décrivent ces structures de reprise après sinistre Google Cloud et l'aide qu'elles vous apportent pour mettre en œuvre vos objectifs dans ce domaine.
Calcul et stockage
 Compute Engine |
|
 Cloud Storage |
|
 GKE |
|
Compute Engine
Compute Engine fournit des instances de machine virtuelle (VM) qui constituent l'outil de travail de Google Cloud. Outre la configuration, le lancement et la surveillance des instances Compute Engine, vous recourez généralement à diverses fonctionnalités associées pour mettre en œuvre un plan de reprise après sinistre.
Pour les scénarios de reprise après sinistre, vous pouvez empêcher la suppression accidentelle de VM en définissant l'indicateur de protection contre la suppression. Ceci est particulièrement utile lorsque vous hébergez des services avec état, tels que des bases de données. Pour vous aider à atteindre des valeurs d'objectif de délai de reprise (RTO, Recovery Time Objective) et d'objectif de point de reprise (RPO, Recovery Point Objective) faibles, suivez les bonnes pratiques pour concevoir des systèmes robustes.
Vous pouvez configurer une instance avec votre application préinstallée, puis enregistrer cette configuration en tant qu'image personnalisée. Votre image personnalisée peut refléter le DMIA que vous souhaitez atteindre.
Modèles d'instances
Vous pouvez utiliser des modèles d'instance Compute Engine pour enregistrer les détails de configuration de la VM, puis créer des instances à partir de modèles d'instance existants. Lorsque vous devez mettre en place l'environnement cible de votre reprise après sinistre, vous pouvez utiliser le modèle pour lancer autant d'instances que vous le souhaitez, configurées exactement comme vous le souhaitez. Les modèles d'instance sont répliqués globalement, ce qui vous permet de recréer facilement l'instance n'importe où dans Google Cloud avec la même configuration.
Vous pouvez créer des modèles d'instance à l'aide d'une image personnalisée ou sur la base d'instances de VM existantes.
Nous fournissons plus de détails sur l'utilisation des images Compute Engine dans la section Équilibrage de la configuration d'image et de la vitesse de déploiement, plus loin dans ce document.
Groupes d'instances gérés
Les groupes d'instances gérés fonctionnent avec Cloud Load Balancing (décrit plus loin dans ce document) pour répartir le trafic vers des groupes d'instances configurées de manière identique et copiées dans différentes zones. Les groupes d'instances gérés autorisent des fonctionnalités telles que l'autoscaling et l'autoréparation, dans lesquelles le groupe d'instances géré peut supprimer et recréer automatiquement des instances.
Réservations
Compute Engine permet de réserver des instances de VM dans une zone spécifique, à l'aide de types de machines personnalisés ou prédéfinis, avec ou sans GPU supplémentaires ou SSD locaux. Afin de garantir la capacité de vos charges de travail critiques pour la reprise après sinistre, vous devez créer des réservations dans vos zones cibles de reprise après sinistre. Sans réservation, il est possible que vous ne puissiez pas obtenir la capacité à la demande dont vous avez besoin pour atteindre votre objectif de temps de récupération. Les réservations peuvent être utiles dans les scénarios de reprise après sinistre à froid, tièdes ou à chaud. Elles vous permettent de conserver des ressources de récupération disponibles pour le basculement afin de répondre à des besoins en RTO plus faibles, sans avoir à les configurer et à les déployer à l'avance.
Disques persistants et instantanés
Les disques persistants sont des périphériques de stockage réseau durables auxquels vos instances peuvent accéder. Ils ne dépendent pas de vos instances. Vous pouvez donc détacher et déplacer des disques persistants pour conserver vos données même après la suppression de vos instances.
Vous pouvez effectuer des sauvegardes ou des instantanés incrémentiels de VM Compute Engine que vous pouvez copier dans différentes régions et utiliser pour recréer des disques persistants en cas de sinistre. Vous pouvez également créer des instantanés de disques persistants pour vous protéger contre les pertes de données dues aux erreurs utilisateur. Les instantanés sont incrémentiels et se créent en quelques minutes seulement, même si vos disques d'instantané sont associés à des instances en cours d'exécution.
Les disques persistants sont dotés d'une fonction de redondance intégrée qui protège les données contre les pannes de matériel et qui assure la disponibilité de ces données lors des événements de maintenance du centre de données. Les disques persistants sont soit zonaux, soit régionaux. Les disques persistants régionaux répliquent les écritures dans deux zones d'une région. En cas de panne de zone, une instance de VM de secours peut forcer l'association d'un disque persistant régional dans la zone secondaire. Pour en savoir plus, consultez la page Options de haute disponibilité avec des disques persistants régionaux.
Migration à chaud
La migration à chaud maintient vos instances de machine virtuelle en fonctionnement même lorsqu'un événement système hôte se produit, tel qu'une mise à jour logicielle ou matérielle. Compute Engine migre à chaud vos instances en cours d'exécution vers un autre hôte situé dans la même zone, au lieu de nécessiter un redémarrage de vos VM. Cela permet à Google d'effectuer une maintenance essentielle à la protection et à la fiabilité de l'infrastructure sans interrompre vos VM.
Outil d'importation de disque virtuel
L'outil d'importation de disque virtuel vous permet d'importer des formats de fichier, tels que VMDK, VHD et RAW, pour créer de nouvelles machines virtuelles Compute Engine. À l'aide de cet outil, vous pouvez créer des machines virtuelles Compute Engine ayant la même configuration que vos machines virtuelles sur site. C'est une bonne approche lorsque vous ne pouvez pas configurer les images Compute Engine à partir des fichiers binaires sources du logiciel déjà installé sur vos images.
Cloud Storage
Cloud Storage est un magasin d'objets idéal pour stocker des fichiers de sauvegarde. Il fournit différentes classes de stockage adaptées à des cas d'utilisation spécifiques, comme indiqué dans le diagramme suivant.
Dans les scénarios de reprise après sinistre, les stockages Nearline, Coldline et Archive présentent un intérêt particulier, dans la mesure où ils réduisent vos coûts de stockage par rapport à un stockage standard. Toutefois, la récupération de données ou de métadonnées stockées dans ces classes entraîne des coûts supplémentaires, ainsi que des durées de stockage minimales facturées. Nearline est conçu pour les scénarios de sauvegarde dont l'accès ne dépasse pas une fois par mois, ce qui est idéal pour vous permettre de réaliser des tests réguliers de contrainte de reprise après sinistre tout en maintenant des coûts bas.
Les solutions Nearline, Coldline et Archive sont optimisées pour un accès peu fréquent, et le modèle de tarification est conçu dans cet esprit. Par conséquent, vous êtes facturé pour les durées de stockage minimales et la récupération de données ou de métadonnées dans ces classes avant la durée de stockage minimale de la classe entraîne des coûts supplémentaires.
Pour protéger les données d'un bucket Cloud Storage contre toute suppression accidentelle ou malveillante, vous pouvez utiliser la fonctionnalité de suppression réversible pour conserver les objets supprimés et écrasés pendant une période spécifiée.
Le service de transfert de stockage vous permet d'importer des données à partir de sources HTTP ou Amazon S3 dans Cloud Storage. Dans les scénarios de reprise après sinistre, vous pouvez utiliser le service de transfert de stockage pour :
- sauvegarder les données d'autres fournisseurs de stockage sur un bucket Cloud Storage ;
- déplacer les données d'un bucket se trouvant dans un emplacement birégional ou multirégional vers un bucket situé dans un emplacement régional afin de réduire les coûts de stockage des sauvegardes.
Filestore
Les instances Filestore sont des serveurs de fichiers NFS entièrement gérés à utiliser avec des applications exécutées sur des instances Compute Engine ou GKE.
Les instances Cloud Filestore sont zonales et ne permettent pas la réplication entre zones. Une instance Cloud Filestore n'est pas disponible si la zone dans laquelle elle réside est en panne. Nous vous recommandons de sauvegarder régulièrement vos données en synchronisant votre volume Filestore avec une instance Filestore dans une autre région à l'aide de la commande gsutil rsync. Pour cela, une tâche doit être planifiée pour s'exécuter sur des instances Compute Engine ou des clusters GKE.
Dans les scénarios de DR (reprise après sinistre), les applications peuvent récupérer rapidement l'accès aux volumes Filestore en passant à Filestore dans des régions de basculement sans avoir à attendre la fin du processus de restauration. La valeur RTO de cette solution de DR dépend en grande partie de la fréquence de la tâche planifiée.
GKE
GKE est un environnement géré, prêt à la production, permettant de déployer des applications en conteneur. GKE vous permet d'orchestrer des systèmes haute disponibilité et inclut les fonctionnalités suivantes :
- Réparation automatique des nœuds. Si un nœud échoue lors de vérifications consécutives de l'état sur une période prolongée (environ 10 minutes), GKE lance un processus de réparation pour ce nœud.
- Vérification de la vivacité. Vous pouvez spécifier une vérification d'activité qui informe périodiquement GKE que le pod est en cours d'exécution. Si le pod échoue, la sonde peut être redémarrée.
- Volumes persistants. Les bases de données doivent pouvoir persister au-delà de la vie d'un conteneur. En utilisant l'abstraction de volume persistant mappée sur un disque persistant Compute Engine, vous pouvez maintenir la disponibilité du stockage indépendamment des conteneurs individuels.
- Clusters multizones et régionaux. Vous pouvez répartir les ressources Kubernetes sur plusieurs zones d'une même région.
- La passerelle multicluster vous permet de configurer des ressources d'équilibrage de charge partagées entre plusieurs clusters GKE dans différentes régions.
- Le service Sauvegarde pour GKE vous permet de sauvegarder et de restaurer des charges de travail sur des clusters GKE.
Mise en réseau et transfert de données
 Cloud Load Balancing |
|
 Traffic Director |
|
 Cloud DNS |
|
 Cloud Interconnect |
|
Cloud Load Balancing
Cloud Load Balancing fournit une haute disponibilité pour Compute Engine en distribuant les requêtes utilisateur sur un ensemble d'instances. Vous pouvez configurer Cloud Load Balancing avec des vérifications d'état qui déterminent si des instances sont disponibles pour que le trafic ne soit pas acheminé vers des instances en échec.
Cloud Load Balancing fournit une seule adresse IP accessible dans le monde entier pour faire face à vos instances Compute Engine. Votre application peut avoir des instances s'exécutant dans différentes régions (par exemple, en Europe et aux États-Unis) et vos utilisateurs finaux sont dirigés vers l'ensemble d'instances le plus proche. En plus de fournir un équilibrage de charge pour les services exposés à Internet, vous pouvez configurer un équilibrage de charge interne pour vos services derrière une adresse IP d'équilibrage de charge privée. Cette adresse IP est accessible uniquement aux instances de VM internes à votre cloud privé virtuel (VPC).
Traffic Director
Avec Traffic Director, déployez un plan de contrôle du trafic entièrement géré pour le maillage de services. Traffic Director gère la configuration des proxys de service qui s'exécutent à la fois dans Compute Engine et GKE. Déployez un service dans plusieurs régions pour qu'il soit à haute disponibilité. Traffic Director décharge les vérifications d'état du service et lance une configuration de basculement des proxys de service, redirigeant ainsi le trafic vers des instances saines.
Traffic Director est également compatible avec les concepts avancés de contrôle du trafic, les ruptures de circuit et l'injection de pannes. Avec la rupture de circuit, vous pouvez appliquer des limites aux requêtes adressées à un service particulier. Ainsi, les requêtes ne peuvent pas atteindre le service, ce qui empêche qu'il se dégrade davantage. Avec l'injection de pannes, Traffic Director peut retarder ou interrompre une partie des requêtes vers un service afin de tester facilement la capacité de votre service à survivre aux requêtes retardées.
Cloud DNS
Cloud DNS fournit un moyen automatisé de gérer vos entrées DNS dans le cadre d'un processus de récupération automatique. Cloud DNS utilise notre réseau mondial de serveurs de noms Anycast pour desservir vos zones DNS à partir d'emplacements redondants dans le monde entier, ce qui offre une haute disponibilité et une latence réduite à vos utilisateurs.
Si vous avez choisi de gérer les entrées DNS sur site, vous pouvez activer les VM dans Google Cloud pour résoudre ces adresses via le transfert Cloud DNS.
Cloud DNS est compatible avec des règles pour configurer la manière dont il répond aux requêtes DNS. Par exemple, vous pouvez configurer des règles de routage pour permettre le basculement vers une configuration de sauvegarde afin de fournir une haute disponibilité ou pour acheminer les requêtes DNS en fonction de leur emplacement géographique.
Cloud Interconnect
Cloud Interconnect permet de transférer vers Google Cloud des informations à partir d'autres sources. Nous en parlerons plus tard dans la section Transférer des données vers et à partir de Google Cloud.
Gestion et surveillance
| Tableau de bord d'état du cloud |
|
Google Cloud Observability |
|
Tableau de bord d'état du cloud
Le tableau de bord d'état du cloud indique la disponibilité actuelle des services Google Cloud. Vous pouvez afficher l'état sur la page et vous pouvez vous abonner à un flux RSS mis à jour chaque fois qu'il y a des actualités concernant un service.
Cloud Monitoring
Cloud Monitoring collecte des métriques, des événements et des métadonnées provenant de Google Cloud, d'AWS, de vérifications du temps d'activité, de l'instrumentation d'applications et de divers composants d'application. Vous pouvez configurer les alertes pour envoyer des notifications à des outils tiers tels que Slack ou Pagerduty afin de fournir des informations rapides aux administrateurs. Une autre façon d'utiliser Cloud Monitoring pour la reprise après sinistre consiste à configurer un récepteur Pub/Sub et à utiliser Cloud Functions pour déclencher un processus automatisé en réponse à une alerte Cloud Monitoring.
Structure de reprise après sinistre multiplate-forme
Lorsque vous exécutez des charges de travail sur plusieurs plates-formes, vous pouvez sélectionner un outil qui fonctionne avec toutes les plates-formes que vous utilisez pour réduire les coûts opérationnels. Cette section traite de certains outils et services qui ne dépendent pas de la plate-forme et qui prennent donc en charge les scénarios de reprise après sinistre multiplate-forme.
Outils de modélisation déclaratifs
Les outils de modélisation déclaratifs vous permettent d'automatiser le déploiement d'une infrastructure sur plusieurs plates-formes. Terraform est l'un des outils de modélisation déclaratifs les plus utilisés.
Outils de gestion de la configuration
Pour les infrastructures de reprise après sinistre complexes ou volumineuses, nous recommandons des outils de gestion logicielle indépendants de la plate-forme, tels que Chef et Ansible. Ces outils garantissent que des configurations reproductibles peuvent être appliquées, peu importe où se trouve votre charge de travail de calcul.
Stockage d'objets
Un modèle de reprise après sinistre courant consiste à détenir des copies d'objets dans des magasins d'objets de différents fournisseurs de cloud. L'outil multiplate-forme Boto est une bibliothèque Python Open Source permettant de se connecter à Amazon S3 et à Cloud Storage.
Outils d'orchestration
Les conteneurs peuvent également être considérés comme une structure de reprise après sinistre. Ils sont un moyen de regrouper les services et d'introduire une cohérence entre les plates-formes.
Si vous travaillez avec des conteneurs, vous utilisez généralement un système d'orchestration. Kubernetes ne fonctionne pas uniquement pour gérer les conteneurs dans Google Cloud (à l'aide de GKE), mais constitue un moyen d'orchestrer les charges de travail basées sur les conteneurs de plusieurs plates-formes. Google Cloud, AWS et Microsoft Azure fournissent tous des versions gérées de Kubernetes.
Pour répartir le trafic vers les clusters Kubernetes s'exécutant sur différentes plates-formes cloud, vous pouvez utiliser un service DNS prenant en charge les enregistrements pondérés et intégrant la vérification de l'état.
Vous devez également vous assurer que vous pouvez extraire l'image vers l'environnement cible. Cela signifie que vous devez pouvoir accéder à votre registre d'images en cas de sinistre. Nous vous conseillons pour ce faire d'utiliser Artefact Registry, qui présente en outre l'avantage de ne pas dépendre de la plate-forme.
Transfert de données
Le transfert de données est un élément essentiel des scénarios de reprise après sinistre multiplate-formes. Assurez-vous de concevoir, mettre en œuvre et tester vos scénarios de reprise après sinistre multiplate-formes en utilisant des maquettes réalistes de ce que le scénario de transfert de données de reprise après sinistre implique. Nous discutons des scénarios de transfert de données dans la section suivante.
Modèles de reprise après sinistre
Cette section présente quelques-uns des modèles les plus courants pour les architectures de reprise après sinistre, basés sur les structures décrites précédemment.
Transférer des données vers et depuis Google Cloud
Un aspect important de votre plan de reprise après sinistre est la rapidité avec laquelle les données peuvent être transférées vers et depuis Google Cloud. Cette exigence est essentielle lorsque votre plan de reprise après sinistre est basé sur le déplacement des données sur site vers Google Cloud ou depuis un autre fournisseur cloud vers Google Cloud. Dans cette section, nous abordons le sujet des services réseau et des services Google Cloud capables d'assurer un bon débit.
Lorsque vous utilisez Google Cloud en tant que site de récupération pour des charges de travail sur site ou dans un autre environnement cloud, vous devez prendre en compte les éléments clés suivants :
- Comment vous connectez-vous à Google Cloud ?
- Combien de bande passante y a-t-il entre vous et le fournisseur d'interconnexion ?
- Quelle est la bande passante fournie directement par le fournisseur à Google Cloud ?
- Quelles autres données seront transférées via ce lien ?
Si vous utilisez une connexion Internet publique pour transférer des données, le débit du réseau est imprévisible, car vous êtes limité par la capacité et le routage du FAI. Le FAI peut proposer un contrat de niveau de service limité, voire aucun. D'autre part, ces connexions ont des coûts relativement bas.
Cloud Interconnect propose plusieurs options pour se connecter à Google et à Google Cloud :
- Cloud VPN permet de créer des tunnels VPN IPsec entre un réseau VPC Google Cloud et un réseau cible. Le trafic échangé entre les deux réseaux est chiffré par une passerelle VPN, puis déchiffré par l'autre passerelle VPN. Le VPN haute disponibilité vous permet de créer des connexions VPN à haute disponibilité avec un contrat de niveau de service garantissant une disponibilité de 99,99 %, ainsi qu'une configuration simplifiée par rapport à la création de VPN redondants.
- L'appairage direct fournit un minimum de sauts de réseau aux adresses IP publiques de Google. Vous pouvez utiliser l'appairage direct pour échanger du trafic Internet entre votre réseau et les points de présence périphériques de Google.
- L'interconnexion dédiée fournit une connexion physique directe entre le réseau sur site et le réseau de Google. Elle fournit un contrat de niveau de service et un débit plus cohérent pour les transferts de données volumineux. Les circuits atteignent 10 Gbit/s ou 100 Gbit/s et sont arrêtés dans l'une des installations hébergées en colocation de Google.
En utilisant une bande passante plus importante, vous pouvez réduire le temps nécessaire pour transférer des données sur site vers Google Cloud. Le tableau suivant illustre les gains de vitesse lors de la mise à niveau de 10 Gbit/s à 100 Gbit/s.
- L'interconnexion partenaire offre des fonctionnalités similaires à celles de l'interconnexion dédiée, mais à des vitesses inférieures à 10 Gbit/s. Consultez la section Fournisseurs de services agréés.
Le diagramme suivant fournit des conseils sur la méthode de transfert à utiliser, en fonction de la quantité de données à transférer vers Google Cloud.
Vous pouvez utiliser le simulateur de temps de transfert pour évaluer la durée d'un transfert en fonction de la taille de l'ensemble de données que vous déplacez et de la bande passante disponible pour le transfert. Pour en savoir plus sur le transfert de données dans le cadre de votre planification de reprise après sinistre, consultez la section Transférer des ensembles de données volumineux.
Équilibrer la configuration de l'image et la vitesse de déploiement
Lorsque vous configurez une image système pour le déploiement de nouvelles instances, prenez en compte l'effet de votre configuration sur la vitesse de déploiement. Il existe un compromis entre la quantité de préconfiguration de l'image, les coûts de maintenance de l'image et la vitesse de déploiement. Par exemple, si une image système est configurée de manière minimale, les instances qui l'utilisent auront besoin de plus de temps pour se lancer, car elles doivent télécharger et installer des dépendances. En revanche, si votre image système est configurée de façon avancée, les instances qui l'utilisent se lancent plus rapidement, mais vous devez mettre à jour l'image plus souvent. Le temps pris pour lancer une instance entièrement opérationnelle aura une corrélation directe avec votre DMIA.
Maintenir la cohérence de l'image système dans des environnements hybrides
Si vous mettez en œuvre une solution hybride (sur site vers le cloud ou d'un cloud à un autre), vous devez trouver un moyen de maintenir la cohérence des VM dans les environnements de production.
Si une image entièrement configurée est requise, envisagez d'utiliser Packer qui peut créer des images système identiques pour plusieurs plates-formes. Vous pouvez utiliser les mêmes scripts avec des fichiers de configuration spécifiques à la plate-forme. Dans le cas de Packer, vous pouvez placer le fichier de configuration dans le contrôle de version pour garder une trace de la version déployée en production.
Une autre option consiste à utiliser des outils de gestion de la configuration tels que Chef, Puppet, Ansible ou Saltstack pour configurer des instances de manière plus précise, en créant des images de base, des images à configuration minimale ou des images à configuration avancée, selon les besoins. Pour savoir comment utiliser ces outils de manière efficace, consultez la page Déploiement à partir de zéro avec Chef sur Google Cloud.
Vous pouvez également convertir et importer manuellement des images existantes, telles que des AMI Amazon, des images Virtualbox et des images de disque RAW vers Compute Engine.
Mettre en œuvre un stockage à plusieurs niveaux
Le modèle de stockage à plusieurs niveaux est généralement utilisé pour les sauvegardes où la sauvegarde la plus récente se trouve sur un stockage plus rapide. Vous migrez ensuite lentement vos sauvegardes anciennes vers un stockage lent moins coûteux. Il existe deux manières de mettre en œuvre le modèle à l'aide de Cloud Storage, en fonction de l'origine de vos données : sur Google Cloud ou sur site. Dans les deux cas, vous migrez des objets entre des buckets de différentes classes de stockage, généralement des classes de stockage standards aux classes de stockage Nearline (moins chères).
Si vos données source sont générées sur site, la mise en œuvre ressemble au diagramme suivant :
Vous pouvez également modifier la classe de stockage des objets d'un bucket à l'aide d'instructions de cycle de vie des objets pour automatiser le changement dans une classe d'objets.
Maintenir la même adresse IP pour des instances privées
Un modèle courant consiste à gérer une seule instance de diffusion de VM. Si la VM doit être remplacée, le remplacement doit apparaître comme s'il s'agissait de la VM d'origine. Par conséquent, l'adresse IP que les clients utilisent pour se connecter à la nouvelle instance doit rester la même.
La configuration la plus simple consiste à mettre en place un groupe d'instances géré qui gère exactement une instance. Ce groupe d'instances géré est intégré à un équilibreur de charge interne (privé) qui garantit que la même adresse IP est utilisée pour comme façade pour l'instance, qu'il s'agisse de l'image d'origine ou de remplacement.
Partenaires technologiques
Google dispose d'un écosystème de partenaires robuste qui prend en charge les cas d'utilisation de la sauvegarde et de la reprise après sinistre avec Google Cloud. En particulier, nous voyons des clients utiliser des solutions partenaires pour effectuer les tâches suivantes :
- Sauvegarder des données sur site vers Google Cloud. Dans ce cas, Cloud Storage est intégré en tant que cible de stockage pour la plupart des plates-formes de sauvegarde sur site. Vous pouvez utiliser cette approche pour remplacer les bandes et d'autres appareils de stockage.
- Mettre en œuvre un plan de reprise après sinistre des installations sur site vers Google Cloud. Nos partenaires peuvent vous aider à éliminer les centres de données secondaires et à utiliser Google Cloud comme site de reprise après sinistre.
- Mettre en œuvre la reprise après sinistre et la sauvegarde pour les charges de travail basées sur le cloud.
Pour en savoir plus sur les solutions partenaires, consultez la page Partenaires sur le site Web de Google Cloud.
Étape suivante
- Apprenez-en plus sur les zones géographiques et régions Google Cloud.
Consultez d'autres articles de cette série sur la reprise après sinistre :
- Guide de planification de reprise après sinistre
- Scénarios de reprise après sinistre pour les données
- Scénarios de reprise après sinistre pour les applications
- Concevoir une solution de reprise après sinistre pour des charges de travail limitées à la localité
- Cas d'utilisation de reprise après sinistre : applications d'analyse de données limitées à la localité
- Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.