Voici quelques points importants à prendre en compte concernant le déploiement des dispositifs de sauvegarde et de reprise après sinistre Backup and DR :
Quelles sont les exigences de votre organisation en termes d'objectif de temps de récupération (RTO) ? Le RTO correspond à la durée maximale pendant laquelle vous pouvez vous permettre de ne pas avoir accès à vos données. Par exemple, si votre RTO est de quatre heures,vous devez pouvoir accéder à vos données dans les quatre heures suivant une défaillance.
Avez-vous besoin de centraliser la gestion de vos sauvegardes ? Vous devez décider si vous souhaitez gérer vos sauvegardes de manière centralisée ou non.
- La gestion centralisée des sauvegardes signifie que vous disposez d'une seule console de gestion des appliances pour gérer les sauvegardes de toutes vos charges de travail dans tous les secteurs d'activité. Cela peut être un moyen plus efficace de gérer les sauvegardes, car vous n'avez besoin de gérer qu'une seule console de gestion des appliances.
- La gestion décentralisée des sauvegardes signifie que vous disposez d'une console de gestion des appliances distincte pour chaque secteur d'activité. Le mode de fonctionnement varie d'une organisation à l'autre.
Quel est votre cas d'utilisation pour la sauvegarde ? Avez-vous besoin de sauvegardes à distance pour la reprise après sinistre en cas de catastrophe dans une région de production, ou est-il suffisant de protéger vos données localement ? Si vous avez besoin d'une fonctionnalité de reprise après sinistre, vous devez envisager les sauvegardes interrégionales. Cela signifie que vous devez stocker vos sauvegardes à plusieurs emplacements. Ainsi, si l'un d'eux est affecté par une catastrophe, vos données resteront accessibles.
Les charges de travail se trouvent dans une seule région
La meilleure stratégie de sauvegarde dans une région dépend de vos besoins.
Si vous n'avez pas besoin de reprise après sinistre
Pour optimiser les performances et réduire les coûts, déployez la console de gestion des appliances et les appliances de sauvegarde/récupération dans la même région que celle où vos charges de travail sont exécutées. Stockez vos images de sauvegarde dans la même région que vos charges de travail.
Si vous souhaitez également disposer de copies de sauvegarde hors site, vous pouvez stocker les sauvegardes dans une autre région ou utiliser le stockage birégional ou multirégional. Le stockage des sauvegardes dans une autre région entraîne des frais de réseau et de stockage.
Si vous avez besoin à la fois de sauvegarde et de reprise après sinistre
Pour optimiser les performances et réduire les coûts, déployez une console de gestion des appliances dans la même région que la région de charge de travail de production, et une deuxième console de gestion des appliances dans une région que vous pouvez utiliser pour la reprise après sinistre.
Déployez des appliances de sauvegarde/restauration dans la région de la charge de travail de production et dans la région de reprise après sinistre pour minimiser l'objectif de temps de récupération (RTO). Cela garantit qu'un environnement de reprise après sinistre est entièrement provisionné et disponible en cas de sinistre.
Stockez les images de sauvegarde dans la région de production et une copie dans la région de reprise après sinistre, ou utilisez un stockage birégional ou multirégional. La copie de sauvegarde de la région de production peut répondre aux besoins de sauvegarde de routine avec des performances plus rapides. Les données copiées dans votre région de reprise après sinistre peuvent être utilisées pour récupérer vos charges de travail en cas d'indisponibilité de la région de production.
Les charges de travail se trouvent dans plusieurs régions.
La meilleure stratégie de sauvegarde multirégionale dépend de vos besoins.
Si vous n'avez pas besoin de reprise après sinistre
Pour optimiser les performances et réduire les coûts, déployez la console de gestion des appliances dans l'une des régions où vos charges de travail sont exécutées. Cela permet une gestion centralisée de toutes les charges de travail et régions.
Déployez un ou plusieurs appareils de sauvegarde/récupération dans chaque région où les charges de travail sont exécutées. Stockez vos sauvegardes dans la même région que vos charges de travail.
Si vous souhaitez également disposer de copies de sauvegarde hors site, vous pouvez stocker les sauvegardes dans une autre région ou utiliser le stockage birégional ou multirégional. Le stockage des sauvegardes dans une région ou une multirégion différente entraîne des frais de réseau et de stockage.
Si vous avez besoin à la fois de sauvegarde et de reprise après sinistre
Déployez une console de gestion des appliances dans chacune des régions de charge de travail de production et une autre console de gestion des appliances dans la région de reprise après sinistre.
Déployez des appliances de sauvegarde/restauration dans les régions de charge de travail de production et dans la région de reprise après sinistre pour minimiser l'objectif de temps de récupération (RTO). Cela garantit qu'un environnement de reprise après sinistre est entièrement préprovisionné et disponible en cas de sinistre.
Stockez les sauvegardes dans la région de la charge de travail de production et une copie dans la région de reprise après sinistre, ou utilisez le stockage birégional ou multirégional. La copie de sauvegarde de la région de production peut être utilisée pour répondre aux besoins de sauvegarde.
Une image de sauvegarde dans la région de reprise après sinistre peut être utilisée pour récupérer les charges de travail si la région de production est hors service.
Topologie réseau recommandée pour Backup and DR
Google Cloud recommande d'utiliser un VPC partagé lors du déploiement de Backup and DR. Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau VPC (Virtual Private Cloud) commun, afin que ces ressources puissent communiquer entre elles de manière sécurisée et efficace en utilisant les adresses IP internes de ce réseau. Lorsque vous utilisez un VPC partagé, vous désignez un projet en tant que projet hôte et vous lui associez un ou plusieurs projets de service. Les réseaux VPC du projet hôte sont appelés réseaux VPC partagés. Les ressources éligibles des projets de service peuvent utiliser des sous-réseaux du réseau VPC partagé.
Le VPC partagé permet aux administrateurs d'une organisation de déléguer des responsabilités administratives, comme la création et la gestion d'instances, à des administrateurs de projet de service tout en conservant un contrôle centralisé sur les ressources réseau, comme les sous-réseaux, les routes et les pare-feu.
La console de gestion de l'appliance est activée dans un réseau VPC producteur de services. Ce VPC de producteur de services communique avec votre projet à l'aide de l'accès privé à Google. L'objectif principal de cette connexion est de permettre à la console de gestion des appliances et aux appliances de sauvegarde/restauration d'échanger des métadonnées. Le trafic de sauvegarde ne transite pas par ce lien. Toutefois, une console de gestion des appliances doit communiquer avec tous les appareils de sauvegarde/restauration déployés sur n'importe quel réseau.
Bonnes pratiques concernant les VPC partagés
Nous vous recommandons de suivre les bonnes pratiques suivantes :
Se connecter à la console de gestion de l'appliance : il est préférable de connecter le réseau du fournisseur de services à un VPC partagé au sein de votre réseau. Tout le trafic provenant de la console de gestion de l'appliance transite par ce VPC et, par conséquent, par le projet hôte. Le provisionnement de la connectivité à Backup and DR via un VPC partagé permet également une connexion fluide entre les projets dans lesquels les charges de travail sont exécutées (projets de service) et Backup and DR.
Emplacement du dispositif de sauvegarde/restauration : les dispositifs de sauvegarde/restauration doivent être déployés dans un sous-réseau sur lequel l'accès privé à Google est activé pour la connectivité à la console de gestion des dispositifs. Deux stratégies sont recommandées pour sélectionner les projets des appliances de sauvegarde/restauration :
Dans le projet hôte central : dans cette stratégie, Backup and DR est traité comme un service informatique central. L'équipe de sauvegarde centrale régit le provisionnement du service. Par conséquent, tous les dispositifs de sauvegarde/restauration sont provisionnés dans le projet hôte, ce qui permet aux administrateurs centraux de regrouper toutes les ressources de sauvegarde dans un projet central. Cette approche présente l'avantage de regrouper toutes les ressources liées aux sauvegardes et leur facturation dans un seul projet.
Dans les projets de service : cette stratégie convient aux équipes plus décentralisées, où les projets de service sont créés et leur gestion est déléguée à des équipes distribuées. Dans ce scénario, la bonne pratique recommandée consiste à provisionner un VPC pour les projets de service en aval. Les appliances de sauvegarde/restauration sont installées dans les projets de service de ces VPC. Cela permet la colocation de la charge de travail et de l'appliance de sauvegarde/restauration dans un même projet.
Accès privé à Google : nous vous recommandons d'activer l'accès privé à Google pour chaque sous-réseau sur lequel vous installez un dispositif de sauvegarde/récupération. Cela permet à l'appliance de sauvegarde/récupération de communiquer avec les API, telles que Compute Engine, Cloud Storage et Cloud Logging, ce qui est important pour le bon fonctionnement de la surveillance et des alertes. Pour simplifier et améliorer les connexions aux API Google Cloud , envisagez de configurer la résolution DNS pour
private.googleapis.com, comme indiqué dans la section Résumé des options de configuration. Pour l'accès privé à Google, configurez les règles de pare-feu à partir des appliances de sauvegarde/récupération pour autoriser les connexions à la plage CIDR199.36.153.8/30sur le port TCP 443.