Voici quelques points importants à prendre en compte pour le déploiement des dispositifs 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 passer de 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 de sauvegarde ? Avez-vous besoin de sauvegardes à distance pour la reprise après sinistre en cas de sinistre 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 des sauvegardes interrégionales. Cela signifie que vous devez stocker vos sauvegardes dans plusieurs emplacements, de sorte que si l'un d'eux est touché par un sinistre, vos données restent 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 (DR)
Pour optimiser les performances et réduire les coûts, déployez la console de gestion des dispositifs et les dispositifs 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 un 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 la sauvegarde et de la reprise après sinistre
Pour des performances optimales et un coût réduit, déployez une console de gestion de l'appareil dans la même région que la charge de travail de production, et une deuxième console de gestion de l'appareil dans une région que vous pouvez utiliser pour la reprise après sinistre.
Déployez des appliances de sauvegarde/récupération 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 pré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 DR peuvent être utilisées pour récupérer vos charges de travail si la région de production est indisponible.
Les charges de travail se trouvent dans plusieurs régions
La meilleure stratégie de sauvegarde entre régions dépend de vos besoins.
Si vous n'avez pas besoin de reprise après sinistre (DR)
Pour optimiser les performances et réduire les coûts, déployez la console de gestion de l'appareil dans l'une des régions où vos charges de travail sont exécutées. Cela permet une gestion centralisée de l'ensemble des charges de travail et des 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 un stockage birégional ou multirégional. Le stockage des sauvegardes dans une région ou un emplacement multirégional différent entraîne des frais de réseau et de stockage.
Si vous avez besoin à la fois de la sauvegarde et de la 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 DR.
Déployez des appareils de sauvegarde/restauration dans les régions de charge de travail de production et dans la région de DR 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 un 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 des charges de travail si la région de production est indisponible.
Topologie réseau recommandée pour Backup and DR
Google Cloud recommande l'utilisation d'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 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é.
Un réseau 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, telles que les sous-réseaux, les routes et les pare-feu.
La console de gestion de l'appareil est activée dans un réseau VPC de 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/récupération d'échanger des métadonnées. Le trafic de sauvegarde ne transite pas par ce lien. Toutefois, une console de gestion des dispositifs doit communiquer avec tous les dispositifs de sauvegarde/restauration déployés sur n'importe quel réseau.
Bonnes pratiques pour les VPC partagés
Les bonnes pratiques suivantes sont recommandées :
Connexion à la console de gestion de l'appareil : 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 où les charges de travail sont exécutées (projets de service) et Backup and DR.
Emplacement de l'appareil de sauvegarde/récupération : les appareils de sauvegarde/récupération 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 appareils. 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 central de l'informatique. L'équipe centrale de sauvegarde gère le provisionnement du service. Par conséquent, tous les dispositifs de sauvegarde/récupération 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. L'appareil de sauvegarde/restauration est installé dans les projets de service de ces VPC. Cela permet la colocation de la charge de travail et de l'appareil de sauvegarde/restauration dans un seul 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'appareil de sauvegarde/récupération de communiquer avec des API telles que Compute Engine, Cloud Storage et Cloud Logging, ce qui est important pour le 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 des appliances de sauvegarde/récupération pour autoriser les connexions à la plage CIDR199.36.153.8/30sur le port TCP 443.