Vous pouvez utiliser Google Cloud afin d'héberger des solutions de reprise après sinistre pour vos systèmes SAP exécutés sur Google Cloud, sur site ou via un autre fournisseur cloud.
Définition de la reprise après sinistre
La reprise après sinistre (DR, Disaster Recovery) et la haute disponibilité sont deux éléments distincts d'un concept plus vaste, la continuité des activités. Ce guide est consacré à la reprise après sinistre.
Une solution de DR est conçue pour restaurer le traitement des applications après qu'une catastrophe naturelle ou d'origine humaine ou bien une défaillance de l'infrastructure a provoqué une panne à grande échelle. Ce type de panne désactive non seulement le système principal de traitement des applications, mais également tout système de secours assurant une protection contre les défaillances du système ou de l'infrastructure locale à petite échelle.
Une solution de DR possède d'autres caractéristiques qui la distinguent d'une solution à haute disponibilité :
- Généralement, le système de reprise dans une solution de DR n'est pas un système de secours à chaud (hot-standby).
- Dans la plupart des cas, une procédure de reprise après sinistre nécessite de récupérer ou de restaurer manuellement le traitement des applications à partir de sauvegardes ou en utilisant la réplication des données, des systèmes et de l'infrastructure.
- La solution comprend un site de DR situé dans un emplacement géographique différent de celui du système principal.
- L'objectif de temps de récupération (RTO, Recovery Time Objective) d'une solution de reprise après sinistre est généralement mesuré en heures, voire en jours.
L'exemple d'architecture suivant montre un système SAP comprenant à la fois une solution à haute disponibilité et une solution de DR. Le site de DR, dans lequel le système sera restauré après un sinistre, se trouve à droite dans la partie Region 2 (Région 2). Le système principal se trouve à gauche dans la partie Region 1 (Région 1) et est configuré pour la haute disponibilité avec des clusters de basculement couvrant deux zones. La fonction de sauvegarde de la solution de DR est représentée par des lignes en pointillé s'étendant sur les deux régions. Pour le stockage, les systèmes utilisent un bucket Cloud Storage multirégional, représenté au bas du schéma.
L'exemple montre également une base de données. Bien que la récupération des applications dépende de celle des données, les procédures de DR pour les systèmes de base de données ne sont pas abordées dans ce guide. Reportez-vous à la documentation de la base de données et aux notes SAP applicables. Ce guide porte spécifiquement sur le système SAP NetWeaver (SAP ASCS/ERS) et les serveurs d'applications (SAP AAS).
Pour plus d'informations sur la mise en œuvre de systèmes SAP à haute disponibilité sur Google Cloud, consultez la page Guide de planification de la haute disponibilité pour SAP NetWeaver sur Google Cloud.
Pour plus d'informations sur la haute disponibilité et la reprise après sinistre pour SAP HANA sur Google Cloud, consultez respectivement le guide de planification de la haute disponibilité SAP HANA et le guide de planification de reprise après sinistre SAP HANA.
Pour obtenir des informations générales sur la DR dans Google Cloud, consultez la page Guide de planification de reprise après sinistre.
Approches de conception de solutions de DR pour les systèmes SAP non exécutés sur Google Cloud
Si votre système SAP principal ne s'exécute pas sur Google Cloud, vous pouvez adopter une approche Lift and Shift pour votre solution de DR, dans laquelle l'architecture et les logiciels du système de DR sur Google Cloud sont identiques à ceux du système principal. Vous pouvez également adopter une approche cloud native dans laquelle, dans le cadre de la conception de votre solution de DR, vous optimisez le système restauré pour le cloud, en utilisant les produits ou services de Google Cloud ou de ses partenaires.
Si vous optez pour l'approche Lift and Shift, vous devez vérifier que l'architecture de votre système principal est totalement compatible avec Google Cloud. Quelle que soit l'approche choisie, vous devez vous assurer que tous vos logiciels possèdent une licence appropriée pour être utilisés sur Google Cloud.
Pour plus d'informations sur les licences, consultez la page Conditions d'utilisation Google Cloud Platform.
Éléments de conception d'une solution de DR pour SAP NetWeaver sur Google Cloud
Une solution de DR pour SAP NetWeaver sur Google Cloud peut inclure les éléments de conception suivants :
- Emplacement du site de DR
- Mise en réseau
- Sécurité
- Considérations relatives aux machines virtuelles (VM, Virtual Machine)
- Options de sauvegarde
- Stockage
Pour mettre en œuvre chacun de ces éléments de conception, vous disposez de plusieurs options afin d'atteindre vos objectifs en matière de reprise et de coût.
Emplacement du site de DR
Lorsque vous choisissez une région Google Cloud pour votre site de DR, vous devez prendre en compte les aspects suivants :
- La zone d'impact potentielle de tout sinistre pouvant survenir sur votre site principal
- La localisation des utilisateurs de votre système SAP NetWeaver
- La disponibilité des ressources et des fonctionnalités Google Cloud utilisées par votre système SAP dans la région et la zone que vous choisissez
Pour votre site de DR, choisissez une région Google Cloud suffisamment éloignée de votre site principal, de sorte que le site de DR ne soit affecté par aucun sinistre susceptible de survenir sur le site principal. Une distance de 160 kilomètres ou plus est généralement considérée comme suffisante, mais les réglementations ou les directives organisationnelles peuvent exiger une distance minimale différente.
Si votre système SAP principal s'exécute sur Google Cloud, placez votre site de DR dans une région Google Cloud proche de vos utilisateurs, autre que celle dans laquelle votre système principal s'exécute. Les régions Google Cloud sont suffisamment éloignées les unes des autres pour qu'aucune d'entre elles ne soit susceptible d'être touchée par le même sinistre.
Si votre système SAP principal s'exécute en dehors de Google Cloud, placez votre site de DR dans une région aussi proche que possible de vos utilisateurs, sans qu'elle se trouve dans la zone d'impact potentielle de tout sinistre pouvant survenir sur le site principal.
Dans votre région de DR, placez votre système de DR dans une zone acceptant les types d'instances de VM et toute autre infrastructure requis par vos systèmes SAP et de base de données.
Une fois que vous avez sélectionné une région pour votre site de DR, vous devrez peut-être augmenter vos quotas de ressources de sorte que la région fournisse suffisamment de ressources au système de DR avant un événement.
Pour connaître l'emplacement de toutes les régions Google Cloud, consultez la page Régions et zones.
Pour voir les fonctionnalités disponibles dans chaque région, consultez la section Régions et zones disponibles.
Pour connaître les ressources Google Cloud globales, régionales et zonales, consultez la page Ressources globales, régionales et zonales.
Mise en réseau
Sur Google Cloud, le cloud privé virtuel (VPC, Virtual Private Cloud) fournit des fonctionnalités de mise en réseau pouvant s'étendre au monde entier.
Si aucun réseau VPC n'existe pour votre site de DR, vous devez créer un. Vous devez également créer un sous-réseau et une plage d'adresses IP pour le site de DR.
Si votre système principal se trouve sur Google Cloud, la configuration de votre réseau est plus facile lorsque le site principal et le site de DR se trouvent sur le même réseau VPC. Toutefois, si nécessaire, vous pouvez également les placer dans des réseaux VPC différents, voire dans des projets différents.
Lors de la conception de votre solution de DR, vous devez prendre en compte les chemins de communication suivants :
- La connexion entre le site principal et le site de DR dans Google Cloud
- La communication interne entre les applications, les bases de données et les serveurs qui composent votre système SAP
- La connexion entre vos utilisateurs et le système SAP
Pour les connexions depuis des sites externes à Google Cloud, Google Cloud fournit divers produits de mise en réseau compatibles avec chacun de ces points de connexion.
Connecter le site principal au site de DR
La connexion entre le site principal et le site de DR est requise pour stocker des sauvegardes ou fournir un chemin de réplication entre les deux systèmes. Ceci permet de rendre les ressources de reprise immédiatement disponibles en cas de sinistre, et de tester vos procédures de DR.
Si votre système principal s'exécute sur Google Cloud, la mise à disposition de vos sauvegardes sur le site de DR est presque automatique. Les instantanés Compute Engine peuvent être désignés comme étant multirégionaux. D'autres sauvegardes peuvent être stockées directement depuis le système principal dans des buckets Cloud Storage multirégionaux, pour les rendre instantanément disponibles sur le site de DR.
Si votre système principal ne s'exécute pas sur Google Cloud, vous pouvez connecter votre site principal à votre site de DR sur Google Cloud à l'aide de Cloud Interconnect ou de Cloud VPN.
Pour obtenir un exemple de topologie Cloud Interconnect à disponibilité élevée qui, moyennant quelques modifications, peut être adaptée à un scénario de DR, consultez la page Établir une disponibilité de 99,99 % pour l'interconnexion dédiée.
Pour obtenir des exemples de topologies de passerelles VPN multirégionales à disponibilité élevée pouvant également être adaptées à un scénario de DR, consultez la page Topologies Cloud VPN.
La bande passante est un élément clé à prendre en compte lors de la configuration de votre connexion à Google Cloud à partir d'un site hors plate-forme. La connexion doit pouvoir assurer le transfert régulier des données et des sauvegardes vers Google Cloud.
Pour plus d'informations sur les options de connexion à Google Cloud depuis des sites hors plate-forme, consultez la page Produits de connectivité hybride.
Connectivité entre les serveurs, les bases de données et les applications SAP
Si votre système principal s'exécute sur Google Cloud, pour maintenir la connectivité entre les serveurs, les bases de données et les applications SAP sur le site de DR, il suffit de modéliser les noms d'hôte, les sous-réseaux, les pare-feu, etc. sur le site principal.
Si votre système principal ne s'exécute pas sur Google Cloud, des tâches supplémentaires peuvent être nécessaires lors de la phase de conception afin de reproduire l'architecture de mise en réseau du site principal sur le site de DR sur Google Cloud.
Il est essentiel que vous testiez vos procédures de DR pour identifier et résoudre tout problème de connectivité avant que votre entreprise n'ait à dépendre du système récupéré.
Connecter les utilisateurs au site de DR
En cas de reprise, une fois le système SAP restauré sur le site de DR, le trafic de vos utilisateurs doit être réacheminé vers le système récupéré. Pour ce faire, vous devez généralement mettre à jour les alias réseau des entrées DNS avec les nouvelles adresses IP, qui sont régionales.
Si votre architecture de mise en réseau utilise des routes VPC, vous devrez les mettre à jour lors de la reprise.
Sur Google Cloud, vous pouvez utiliser Cloud DNS ou une autre solution DNS.
Ressources réseau régionales
Si votre système principal s'exécute sur Google Cloud et que vous utilisez des ressources réseau régionales telles que Cloud NAT ou un service Cloud Load Balancing régional, vous devez disposer d'une instance de la ressource dans chaque région.
Pour en savoir plus, consultez les pages suivantes :
Contrôle des accès au réseau
Assurez-vous que les ports ouverts sur le site de DR et sur le site principal sont identiques.
Vous pouvez définir des règles de pare-feu dans votre réseau VPC pour contrôler le trafic entrant et sortant de vos VM.
Si vous disposez d'un service Active Directory sur Windows Server, vous devez le configurer avant la reprise et le synchroniser avec l'instance Active Directory du site principal.
Sécurité
Sur votre site de DR, vous devez mettre en œuvre les mêmes autorisations et contrôles de sécurité que ceux appliqués sur votre site principal. Les mêmes règles de conformité s'appliquent également à votre environnement récupéré.
Tout utilisateur ou rôle nécessitant un accès au site principal a également besoin d'un accès au site de DR.
Pour obtenir des informations générales sur la conception de la sécurité pour une solution de DR sur Google Cloud, consultez la section Mettre en place des contrôles de sécurité et de conformité.
Considérations sur les VM
Vous pouvez accélérer le déploiement de vos instances de machine virtuelle (VM) Compute Engine et éviter les erreurs de configuration sur votre site de DR en utilisant des configurations Terraform fournies par Google Cloud, des produits et des fonctionnalités comme Cloud Deployment Manager, des modèles d'instances et des images personnalisées.
Configurer et déployer vos machines virtuelles
Google Cloud fournit des fichiers de configuration Terraform et des modèles Deployment Manager pour SAP sur Google Cloud que vous pouvez utiliser pour prédéfinir et déployer votre système SAP sur le site de reprise après sinistre. L'utilisation de ces fichiers Terraform ou Deployment Manager accélère le déploiement, réduit les erreurs de configuration et garantit que vos systèmes SAP répondent aux exigences de compatibilité de SAP.
Pour configurer vos VM à l'avance, vous pouvez également faire appel aux modèles d'instances Compute Engine. Ces derniers vous permettent d'accélérer le déploiement et de réduire la configuration manuelle de vos VM lors de la reprise. Toutefois, comme ils impliquent une certaine reconfiguration du site de DR, il peut s'avérer plus simple de récupérer vos VM depuis un disque de démarrage de récupération, comme décrit dans la section suivante.
Pour plus d'informations sur les modèles d'instances, consultez la page Modèles d'instances.
Vous pouvez également gérer vos déploiements d'infrastructure sur Google Cloud à l'aide d'outils d'orchestration de déploiement tels que Terraform.
Selon votre RTO, vous pouvez prédéployer vos instances Compute Engine. Sinon, comme le déploiement d'une VM ne prend que quelques minutes, vous pouvez effectuer le déploiement au moment de la reprise.
Si vous prédéployez vos VM, vous pouvez les arrêter pour réduire les coûts ou les utiliser à d'autres fins non essentielles jusqu'à ce qu'elles soient nécessaires à la reprise.
Vous pouvez également réduire les coûts en consolidant un système distribué sur un nombre moins important de VM sur le site de DR. Par exemple, si les serveurs d'applications du site principal se trouvent sur des hôtes dédiés de ce dernier, vous pouvez placer les serveurs d'applications du site de DR sur le même hôte que les services centraux SAP. Cependant, vous devez peser le pour et le contre, car les économies réalisées sont contrebalancées par une complexité accrue, liée à l'utilisation de configurations différentes sur chaque site.
Disque de démarrage de récupération
Vous pouvez créer une image personnalisée depuis le disque de démarrage de l'hôte sur votre système principal, puis utiliser cette image pour créer l'instance de reprise sur le site de DR.
Si votre système s'exécute sur Google Cloud, créez une image personnalisée si vous avez créé et modifié un disque de démarrage persistant Compute Engine pour votre système principal. Si vous utilisez une image publique Google Cloud non modifiée, vous pouvez également l'utiliser sur le site de DR. Pour en savoir plus, consultez la page Créer, supprimer et rendre obsolètes des images personnalisées.
Si votre système ne s'exécute pas sur Google Cloud, vous pouvez importer une image de disque de démarrage dans Google Cloud à partir de votre environnement sur site, ou importer des disques virtuels à partir de VM s'exécutant sur votre poste de travail local ou sur une autre plate-forme cloud.
Options de sauvegarde
Lorsque vous concevez une solution de DR, vous avez le choix entre plusieurs options de sauvegarde Google Cloud :
- Images personnalisées Compute Engine
- Instantanés de disque persistant Compute Engine
- Réplication
Images personnalisées Compute Engine
Pour sauvegarder le disque de démarrage du système principal afin de l'utiliser lors d'une reprise, vous pouvez le stocker sur Google Cloud sous la forme d'une image personnalisée Compute Engine. Pour en savoir plus, consultez la section Disque de démarrage de récupération.
Instantanés de disque persistant Compute Engine
Pour sauvegarder des systèmes SAP ou d'autres systèmes de fichiers sur un disque persistant Compute Engine, vous pouvez utiliser des instantanés de disque persistant.
Vous pouvez également définir une programmation d'instantanés afin de prendre des instantanés automatiquement à intervalles réguliers. Consultez la page Créer des programmations d'instantanés pour des disques persistants.
Les instantanés ne fournissent une cohérence qu'au niveau du bloc. Pour assurer la cohérence au niveau du fichier, vous devrez peut-être mettre en œuvre des mécanismes permettant de suspendre les activités en écriture sur les systèmes de fichiers cibles pendant la réalisation de ces instantanés.
Réplication
En fonction de votre solution de stockage partagé et de vos objectifs de point de récupération (RPO, Recovery Point Objective), vous pouvez répliquer vos systèmes de fichiers. Vous pouvez faire appel à la réplication pour des bases de données, un stockage au niveau du bloc ou des fichiers.
Une solution de DR qui utilise la réplication est idéale pour les applications stratégiques ayant une tolérance très faible à la perte de données.
Si votre système principal s'exécute sur Google Cloud, les buckets et les instantanés multirégionaux sont répliqués pour vous entre les régions sélectionnées.
Pour la réplication de stockage au niveau du bloc, vous pouvez utiliser la réplication asynchrone des disques persistants. La réplication asynchrone fournit une réplication asynchrone à faibles RPO (objectif de point de récupération faible) et RTO (objectif de temps de récupération) conçue pour la reprise après sinistre active/passive interrégionale
Vous pouvez également utiliser la réplication fournie par des solutions de stockage tierces.
Stockage
Lorsque vous concevez une solution de DR sur Google Cloud, il est probable que vous utilisiez plusieurs types de stockage, en fonction de l'emplacement d'exécution du système principal et de ce que vous stockez.
Buckets Cloud Storage pour les fichiers de sauvegarde
Pour les sauvegardes autres que les instantanés de disque, tels que les fichiers que vous importez depuis un système SAP qui ne s'exécute pas sur Google Cloud, créez un bucket dans Cloud Storage auquel vous pouvez accéder à partir du site principal et du site de DR. Lorsque vous créez un bucket, vous choisissez une classe de stockage par défaut et un emplacement.
Sélectionnez une classe de stockage par défaut en fonction du contrat de niveau de service dont vous avez besoin, de votre utilisation prévue de l'espace de stockage et de vos contraintes en matière de coûts. Pour la DR, la classe de stockage Coldline constitue souvent une bonne option.
Pour l'emplacement du bucket, choisissez un emplacement incluant la région du site de DR et, si votre système principal s'exécute sur Google Cloud, la région du site principal.
Si votre système principal se trouve sur Google Cloud, choisissez un emplacement multirégional comprenant les régions du site principal et du site de DR afin de pouvoir accéder au bucket à partir des deux sites.
Si votre système principal ne se trouve pas sur Google Cloud, pour réduire les coûts, vous pouvez sélectionner un emplacement comprenant une seule région dans la région qui inclut votre site de DR.
Si votre système principal se trouve sur Google Cloud et que vous utilisez une solution tierce pour le stockage partagé, cette solution peut conditionner les options de stockage dont vous disposez. Reportez-vous à la documentation de la solution ou à votre conseiller de l'équipe d'assistance Cloud Customer Care.
Pour plus d'informations sur la tarification, consultez la page Tarifs de Cloud Storage.
Stockage des instantanés de disque persistant Compute Engine
Lorsque vous créez un instantané, vous pouvez spécifier un emplacement de stockage. L'emplacement d'un instantané a une incidence sur sa disponibilité et peut entraîner des frais de mise en réseau au moment de sa création ou de sa restauration sur un nouveau disque.
Les instantanés peuvent être stockés dans un emplacement multirégional Cloud Storage, tel que asia, ou dans un emplacement régional Cloud Storage, tel que asia-south1.
Un emplacement de stockage multirégional offre une plus grande disponibilité et son utilisation peut réduire les frais de réseau lors de la création ou de la restauration d'un instantané. Un emplacement de stockage régional vous permet de mieux contrôler l'emplacement physique de vos données.
Quelles que soient les options d'emplacement que vous choisissez, les instantanés doivent être stockés dans un emplacement accessible depuis votre site de DR.
Pour en savoir plus sur les emplacements d'instantanés, consultez la section Sélectionner l'emplacement de stockage d'un instantané.
Pour obtenir des informations sur la tarification du stockage d'instantanés, consultez la section Tarifs des disques persistants.
Stockage d'images personnalisées
Une fois que vous avez ajouté des fichiers image personnalisés à votre liste d'images personnalisées, Compute Engine gère leur stockage. Les images figurant dans une liste d'images personnalisées sont des ressources globales et sont donc disponibles dans toutes les régions.
Pour plus d'informations sur la tarification du stockage d'images, consultez la section Stockage d'images.
Tester votre plan de DR
Une fois votre plan de DR terminé, testez-le régulièrement et notez les éventuels problèmes, puis ajustez le plan en conséquence.
Veillez à tester tous les aspects de votre plan de DR, y compris :
- les sauvegardes et les programmations de sauvegardes ;
- le transfert de données depuis des sites hors plate-forme ;
- la récupération à partir des sauvegardes stockées ;
- les contrôles de sécurité et l'accès au système ;
- le routage réseau.
Lorsque vous testez vos systèmes de DR, vos systèmes principaux continuent de s'exécuter. Pour éviter les conflits ou les scénarios de split-brain, vous devez isoler le système de test du système principal et de ses utilisateurs.
Pour obtenir des informations générales sur le test des plans de DR dans Google Cloud, consultez la page Guide de planification de reprise après sinistre.
Concevoir votre solution de DR de façon à atteindre vos RPO et RTO
Certains produits, fonctions et services Google Cloud sont essentiels à la conception d'une solution de DR permettant d'atteindre vos RPO et vos RTO.
Concevoir la solution en fonction d'un RPO
Lorsque vous concevez une solution de DR sur Google Cloud afin d'atteindre un RPO donné, deux variables contrôlent le moment où vous pouvez effectuer la récupération :
- Fréquence des sauvegardes
- La conservation des sauvegardes
Fréquence des sauvegardes
La fréquence des sauvegardes détermine la durée maximale pouvant s'écouler entre votre dernière sauvegarde et un sinistre. Si vous créez vos sauvegardes de DR toutes les 24 heures, vous risquez de perdre près de 24 heures de mises à jour de données en cas de survenue d'un sinistre 23 heures et 59 minutes après la dernière sauvegarde.
La réplication peut réduire la durée maximale écoulée depuis votre dernière sauvegarde à pratiquement zéro. Toutefois, comme ce processus est coûteux, vous ne pouvez l'utiliser que pour les bases de données et les fichiers d'applications stratégiques.
Dans une solution de DR, des copies ou des instantanés à un moment précis sont couramment utilisés pour sauvegarder les systèmes de fichiers d'applications SAP requis pour la reprise.
Sur Google Cloud, vous pouvez automatiser les instantanés de disque persistant Compute Engine en créant une programmation d'instantanés à fréquence horaire, quotidienne ou hebdomadaire. Toutefois, comme les instantanés Compute Engine ne contrôlent la cohérence qu'au niveau du bloc, envisagez de suspendre les activités en écriture sur les systèmes de fichiers cibles pendant la réalisation des instantanés afin d'assurer la cohérence au niveau du fichier.
Le principal coût à prendre en compte lorsque vous choisissez la fréquence des sauvegardes est celui du transfert de données. Vous devez également tenir compte du coût du stockage, mais votre règle de conservation des sauvegardes peut avoir une incidence plus importante sur ce coût que la fréquence des sauvegardes.
Pour en savoir plus sur les programmations d'instantanés, consultez la page Créer des programmations d'instantanés pour des disques persistants.
Conservation des sauvegardes
La conservation des sauvegardes détermine jusqu'où vous pouvez remonter dans le temps pour déplacer votre point de récupération. Garder des copies de sauvegarde vous protège contre les erreurs logiques en vous permettant d'effectuer une récupération à un moment précis où l'erreur ne s'était pas encore produite.
Vous pouvez définir des règles de conservation pour les instantanés Compute Engine et les buckets Cloud Storage qui suppriment automatiquement vos fichiers de sauvegarde après un certain temps.
Le principal coût à prendre en compte lorsque vous choisissez une règle de conservation est le coût du stockage. Les instantanés Compute Engine réduisent la quantité de stockage requise pour plusieurs instantanés en ne stockant que les modifications incrémentielles au niveau du bloc après le stockage du premier instantané complet.
Pour en savoir plus sur la définition des règles de conservation des instantanés, consultez la section Règle de conservation des instantanés.
Pour plus d'informations sur la définition des règles de conservation des buckets Cloud Storage, consultez la page Règles de conservation utilisant des verrous de bucket.
Concevoir la solution en fonction d'un RTO
Lorsque vous concevez une solution de DR sur Google Cloud afin d'atteindre un RTO donné, l'aptitude de l'infrastructure, des logiciels, des systèmes de fichiers et des données sur le site de DR est la principale variable de contrôle.
Par exemple, pour atteindre un RTO très faible, vous pouvez conserver un système de secours à chaud sur le site de DR, avec une infrastructure prédéployée, des systèmes SAP actifs et des données répliquées. Cependant, un RTO faible présente un coût plus élevé.
Vous pouvez trouver un équilibre entre les coûts et les temps de récupération en configurant à l'avance une infrastructure peu coûteuse ou gratuite, et en reportant certaines étapes de configuration jusqu'au moment de la récupération.
Par exemple, vous pouvez configurer et déployer une VM à l'avance, puis l'arrêter. Les ressources associées à la VM, telles que des adresses IP statiques externes ou des disques persistants, peuvent toujours entraîner des frais, mais ce n'est pas le cas de la VM arrêtée.
Étant donné que vous pouvez configurer et déployer une VM Compute Engine sur Google Cloud assez rapidement, vous pouvez le faire au moment de la récupération et quand même atteindre votre RTO, en particulier si vous utilisez Terraform ou Deployment Manager pour déployer votre système de DR ou si vous créez la VM à partir d'un modèle et d'une image personnalisée que vous créez à l'avance.
Considérations sur les quotas et les ressources pour les solutions de DR avec un RTO élevé
Si vous ne prédéployez pas votre infrastructure et vos systèmes, vérifiez régulièrement vos quotas de ressources dans la région du site de DR afin de vous assurer qu'ils sont suffisants pour déployer le système de DR.
En prédéployant autant de systèmes et d'éléments d'infrastructure de DR que votre budget le permet, vous vous assurez que le système de DR respecte vos quotas et que lorsqu'il a besoin des ressources Google Cloud, celles-ci sont disponibles.
Exemples d'architecture pour différents objectifs
Les schémas d'architecture suivants illustrent des exemples de conception d'une solution de DR pour différents RTO.
Chacun des schémas présente les options de sauvegarde multirégionales à gauche et une configuration SAP simplifiée correspondante sur le site de DR à droite.
Chaque exemple montre une combinaison possible d'éléments pour la conception d'une solution de DR. Pour adapter la conception de votre solution de DR à vos objectifs et à votre situation, vous pouvez combiner des éléments de tout ou partie des exemples.
Exemple d'architecture d'une solution de DR avec un RTO faible
Le schéma d'architecture suivant illustre un exemple de conception d'une solution de DR avec un RTO faible.
Dans cette conception, vous conservez un système SAP presque fonctionnel sur le site de DR. Les VM sont déployées et actives. Les serveurs d'applications SAP et le serveur de base de données sont actifs, mais le service d'application est arrêté.
Les options de sauvegarde que vous êtes susceptible d'utiliser dans ce scénario incluent les images de l'OS et les instantanés de disque persistant stockés dans Compute Engine, ainsi que la réplication de données entre le site principal et le site de DR. Pour la réplication de données, vous pouvez utiliser la réplication asynchrone des disques persistants.
Avec la réplication de données, le risque de perte de données est limité à la dernière synchronisation de la base de données.
Pour faire remonter votre RPO plus loin dans le temps, vous pouvez ajouter des sauvegardes de données vers Cloud Storage, ce qui n'est pas illustré dans le schéma. Pour les instantanés de disque persistant, vous pouvez utiliser des instantanés programmés et ajuster la règle de conservation en fonction de votre RPO.
Voici les actions que vous devez effectuer pour récupérer un système avec un RTO faible comme celui-ci :
- Si nécessaire, effectuez une synchronisation finale des fichiers ou récupérez-les à partir d'un instantané de disque persistant.
- Basculez la base de données principale sur le site de DR.
- Démarrez l'application sur le site de DR.
Des trois exemples d'architectures présentés dans ce document, celui avec un RTO faible est le plus coûteux.
Exemple d'architecture d'une solution de DR avec un RTO moyen
L'exemple suivant d'architecture d'une solution de DR présente un RTO plus élevé que celui de l'exemple précédent, mais son coût est inférieur.
Dans cette conception, le serveur de base de données est actif pour assurer la réplication à partir du site principal. Les VM des serveurs d'applications ne sont pas actives.
Les options de sauvegarde que vous êtes susceptible d'utiliser dans ce scénario incluent les images de l'OS et les instantanés de disque persistant stockés dans Compute Engine, ainsi que la réplication de données entre le site principal et le site de DR. Pour la réplication de données, vous pouvez utiliser la réplication asynchrone des disques persistants.
Avec la réplication de données, le risque de perte de données est limité à la dernière synchronisation de la base de données.
Pour faire remonter votre RPO plus loin dans le temps, vous pouvez stocker des sauvegardes de données dans un bucket Cloud Storage, ce qui n'est pas illustré dans le schéma. Pour les instantanés de disque persistant, vous pouvez utiliser des instantanés programmés et ajuster la règle de conservation en fonction de votre RPO.
En fonction des exigences de votre système de base de données, vous pourrez peut-être déployer votre base de données sur une VM plus petite sur le site de DR que celle requise sur le site principal, ce qui peut permettre de réduire les coûts jusqu'à l'activation du système de DR. Dans ce cas, vous devez redimensionner la VM à la taille requise pendant la récupération.
Voici les actions que vous devez effectuer pour récupérer un système comme celui-ci :
- Si nécessaire, déployez les instances de VM pour SAP NetWeaver et les serveurs d'applications à partir d'images ou d'instantanés de disque persistant.
- Synchronisez les systèmes de fichiers à partir d'instantanés de disque persistant ou d'un autre espace de stockage.
- Si nécessaire, redimensionnez l'instance de VM de la base de données.
- Basculez la base de données principale sur le site de DR.
- Démarrez le service d'application sur le site de DR.
Exemple d'architecture d'une solution de DR avec un RTO élevé
Le schéma d'architecture suivant a le RTO le plus élevé des exemples présentés dans ce document et constitue l'option la moins onéreuse.
Dans cette conception, vous pouvez prédéployer les serveurs, puis les arrêter pour éviter que des frais ne vous soient facturés pour les VM. Sinon, pour éviter les coûts associés aux disques persistants et aux autres ressources liées aux VM, vous pouvez déployer les VM dans le cadre de votre processus de récupération.
Les options de sauvegarde que vous êtes susceptible d'utiliser dans ce scénario incluent les images de l'OS et les instantanés de disque persistant stockés dans Compute Engine, ainsi que les sauvegardes de données stockées dans Cloud Storage.
Pour atteindre votre RPO, vous pouvez ajuster à la fois la fréquence des sauvegardes et les règles de conservation de vos programmations d'instantanés et des sauvegardes se trouvant dans le bucket Cloud Storage.
Voici les actions que vous devez effectuer pour récupérer un système comme celui-ci :
- Si nécessaire, déployez les instances de VM pour SAP NetWeaver, les serveurs d'applications et le serveur de base de données à partir d'images ou d'instantanés de disques persistants multirégionaux stockés dans Compute Engine.
- Synchronisez les systèmes de fichiers à partir d'instantanés de disque persistant ou d'un autre espace de stockage.
- Récupérez la base de données à partir de fichiers de sauvegarde se trouvant dans un bucket Cloud Storage multirégional ou à un autre emplacement.
- Basculez la base de données principale sur le site de DR.
- Démarrez le service d'application sur le site de DR.
Partenaires et produits pour solutions de DR pour SAP sur Google Cloud
Les partenaires pouvant vous aider avec votre solution de DR sont indiqués dans l'Annuaire des partenaires Google Cloud.
Vous pouvez également trouver divers produits et partenaires pour la prise en charge de votre solution de DR sur Google Cloud Marketplace.