Voici quelques points importants à prendre en compte qui affectent la façon dont vous déployez les appareils de sauvegarde/restauration Backup and DR :
Quelles sont les exigences de votre organisation en matière d'objectif de temps de récupération (RTO) ? Le RTO correspond au délai maximal pendant lequel 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 appareils 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 appareils.
- La gestion décentralisée des sauvegardes signifie que vous disposez d'une console de gestion des appareils 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 suffit-il 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. Ainsi, si un emplacement est touché par un sinistre, 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 (DR)
Pour des performances optimales et des coûts réduits, déployez la console de gestion des appareils et les appareils de sauvegarde/restauration 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 sauvegarde et de reprise après sinistre
Pour des performances optimales et des coûts réduits, déployez une console de gestion des appareils dans la même région que la région de charge de travail de production et une deuxième console de gestion des appareils dans une région que vous pouvez utiliser pour la reprise après sinistre.
Déployez des appareils de sauvegarde/restauration dans la région de charge de travail de production et dans la région de reprise après sinistre pour réduire 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 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 entre les régions dépend de vos besoins.
Si vous n'avez pas besoin de reprise après sinistre (DR)
Pour des performances optimales et des coûts réduits, déployez la console de gestion des appareils 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/restauration 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 autre région ou dans plusieurs régions 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 appareils dans chacune des régions de charge de travail de production et une autre console de gestion des appareils dans la région de reprise après sinistre.
Déployez des appareils de sauvegarde/restauration dans les régions de charge de travail de production et dans la région de reprise après sinistre pour réduire 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 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 reprise après sinistre peut être utilisée pour récupérer les charges de travail si la région de production est indisponible.
Topologie réseau recommandée pour le service Backup and DR
Google Cloud recommande d'utiliser un VPC partagé lors du déploiement du service Backup and DR. Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau VPC (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, routes et pare-feu.
La console de gestion des appareils est activée dans un réseau VPC de producteur de services VPC. 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 que la console de gestion des appareils et les appareils de sauvegarde/restauration échangent des métadonnées. Le trafic de sauvegarde ne transite pas par ce lien. Toutefois, une console de gestion des appareils 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 des appareils : 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 des appareils transite par ce VPC, et donc par le projet hôte. Le provisionnement de la connectivité au service Backup and DR via un VPC partagé permet également une connexion transparente entre les projets où les charges de travail sont exécutées (projets de service) et le service Backup and DR.
Emplacement de l'appareil de sauvegarde/restauration : les appareils de sauvegarde/restauration doivent être déployés dans un sous-réseau pour lequel l'accès privé à Google est activé afin de pouvoir se connecter à la console de gestion des appareils. Nous vous recommandons deux stratégies pour sélectionner les projets pour les appareils de sauvegarde/restauration :
Dans le projet hôte central : dans cette stratégie, le service Backup and DR est traité comme un service central de l'informatique. L'équipe de sauvegarde centrale régit le provisionnement du service. Par conséquent, tous les appareils 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 à la sauvegarde 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 au sein de ces VPC. Cela permet de colocaliser la charge de travail et l'appareil de sauvegarde/restauration dans un seul projet.
Accès privé à Google : il est recommandé d'activer l'accès privé à Google pour chaque sous-réseau dans lequel vous installez un appareil de sauvegarde/restauration. Cela garantit que l'appareil de sauvegarde/restauration peut communiquer avec des 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 Google Cloud API, envisagez de configurer la résolution DNS pour
private.googleapis.com, comme décrit dans la section Résumé des options de configuration. Pour l'accès privé à Google, configurez les règles de pare-feu à partir des appareils de sauvegarde/restauration pour autoriser les connexions à la plage CIDR199.36.153.8/30sur le port TCP 443.