Cet article fait partie d'une série qui traite de la reprise après sinistre dans Google Cloud. Dans cette partie, nous abordons les scénarios courants de reprise après sinistre pour les applications.
La série comprend les éléments suivants :
- Guide de planification de reprise après sinistre
- Structure de la 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 (le présent article)
- 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
Présentation
Cet article présente les scénarios de reprise après sinistre (DR, Disaster Recovery) des applications relatifs aux modèles DR indiquant dans quelle mesure l'application peut se remettre d'un incident. Il reprend les concepts abordés dans l'article Structure de la reprise après sinistre pour expliquer comment mettre en œuvre un plan de DR de bout en bout adapté à vos objectifs de reprise.
Pour commencer, nous allons examiner certaines charges de travail courantes pour montrer comment votre plan de DR dépend directement de vos considérations en matière d'objectifs et d'architecture de récupération.
Charges de travail de traitement par lot
En général, les charges de travail de traitement par lot n'ont pas de caractère critique. Vous n'avez donc pas à investir dans la conception d'une architecture de haute disponibilité (HA) afin d'optimiser le temps d'activité. En effet, les charges de travail de traitement par lot supportent les interruptions. Ce type de charge de travail peut tirer parti de produits économiques tels que les instances de VM préemptives, que vous pouvez créer et exécuter pour un coût bien inférieur à celui des instances normales. Toutefois, Compute Engine arrête ("préempte") ces instances si d'autres tâches doivent accéder à leurs ressources, et l'arrêt intervient dans un délai maximal de 24 heures après le lancement.
La mise en place de points de contrôle réguliers au cours du traitement permet de reprendre la tâche à partir du point de défaillance lorsque de nouvelles VM sont lancées. Si vous utilisez Dataproc, le processus de lancement des nœuds de calcul préemptifs est assuré par un groupe d'instances géré. La situation est semblable à un scénario tiède, dans lequel une courte pause permet d'attendre que les VM de remplacement poursuivent le traitement.
Sites d'e-commerce
Dans les sites d'e-commerce, certaines parties de l'application peuvent avoir des valeurs RTO (temps de récupération) plus élevées. Par exemple, le pipeline d'achat réel doit être hautement disponible, mais le processus de messagerie qui envoie des notifications de commande aux clients peut tolérer un délai de quelques heures. Les clients sont informés de leur achat. Bien qu'ils s'attendent à recevoir un e-mail de confirmation, la notification ne constitue donc pas un élément essentiel du processus. Il s'agit d'une combinaison de modèles à chaud (achats) et tiède/à froid (notifications).
La partie transactionnelle de l'application nécessite un temps d'activité élevé avec une valeur RTO minimale. Ainsi, cette partie de l'application utilise une configuration HA pour maximiser sa disponibilité. Cette approche peut être considérée comme un modèle à chaud.
Le scénario du e-commerce montre qu'il est possible de définir des valeurs RTO différentes au sein d'une même application.
Streaming vidéo
Une solution de streaming vidéo comporte de nombreux composants qui doivent être hautement disponibles, de la fonctionnalité de recherche au processus de diffusion du contenu auprès de l'utilisateur. De plus, le système nécessite une faible latence pour créer une expérience utilisateur satisfaisante. Si un aspect de la solution n'est pas à la hauteur de ces exigences, le fournisseur comme le client en subissent les conséquences. Or de nos jours, les clients peuvent se tourner vers la concurrence.
Dans ce scénario, une architecture procurant une haute disponibilité est indispensable, accompagné de valeurs RTO peu élevées. Un modèle à chaud sur l'ensemble de l'architecture d'application est donc primordial pour limiter au maximum l'impact en cas de sinistre.
Architectures DR et HA pour la production sur site
Dans cette section, nous décrivons comment mettre en œuvre trois modèles (à froid, tiède et à chaud) lorsque l'application s'exécute sur site et que votre solution de DR repose sur Google Cloud.
Modèle à froid : récupération sur Google Cloud
Dans un modèle à froid, vous disposez de ressources minimales dans le projet de DR de Google Cloud, mais juste assez pour activer un scénario de récupération. Si l'environnement de production n'est plus en mesure d'exécuter les charges de travail de production à la suite d'un incident, la stratégie de basculement nécessite de démarrer un environnement de production miroir dans Google Cloud. Les clients peuvent alors utiliser les services à partir de l'environnement de DR.
Dans la présente section, nous allons examiner un exemple de ce modèle. Dans cet exemple, Cloud Interconnect est configuré avec une solution VPN autogérée (non Google Cloud) pour fournir une connectivité à Google Cloud. Les données sont copiées sur Cloud Storage dans le cadre de l'environnement de production.
Composants fondamentaux de reprise après sinistre :
- Cloud DNS
- Cloud Interconnect
- Solution VPN autogérée
- Cloud Storage
- Compute Engine
- Cloud Load Balancing
- Deployment Manager
Le diagramme ci-dessous représente l'architecture de cet exemple :
Pour configurer votre environnement, procédez comme suit :
- Créez un réseau VPC.
- Configurez la connectivité entre votre réseau sur site et le réseau Google Cloud.
- Créez un bucket Cloud Storage qui fera office de cible pour la sauvegarde de données.
- Générez une clé de compte de service pour un compte de service dédié. Ce fichier permet de transmettre les identifiants à un script automatisé.
Copiez la clé du compte de service sur la machine sur site depuis laquelle vous exécuterez le script permettant d'importer les sauvegardes de la base de données. (Il peut s'agir de votre serveur de base de données, mais vos règles de sécurité risquent de vous empêcher d'installer un logiciel supplémentaire sur ce serveur.)
Créez une stratégie IAM pour limiter l'accès au bucket et à ses objets à certains utilisateurs. Veillez à inclure le compte de service créé spécifiquement à cet effet. Vous devez également ajouter le compte utilisateur ou le groupe d'utilisateurs aux stratégies de votre opérateur ou de votre administrateur système, afin d'accorder à toutes ces identités les autorisations appropriées. Pour en savoir plus sur les autorisations d'accès à Cloud Storage, consultez la page Autorisations IAM pour Cloud Storage.
Vérifiez que vous pouvez importer et télécharger des fichiers dans le bucket cible.
Créez un script de transfert de données.
Créez une tâche planifiée pour exécuter le script.
Créez des images personnalisées configurées pour chaque serveur dans l'environnement de production. Chaque image doit avoir la même configuration que son équivalent sur site.
Dans le cadre de la configuration de l'image personnalisée du serveur de base de données, créez un script de démarrage qui copie automatiquement la dernière sauvegarde d'un bucket Cloud Storage sur l'instance, puis appelle le processus de restauration.
Configurez Cloud DNS pour qu'il pointe vers vos services Web sur Internet.
Créez un modèle Deployment Manager qui créera des serveurs d'applications sur votre réseau Google Cloud à l'aide des images personnalisées que vous avez configurées précédemment. Ce modèle doit également définir les règles de pare-feu appropriées.
Vous devez mettre en œuvre des processus pour vous assurer que la version de l'application reproduite dans les images personnalisées est la même que celle sur site. Veillez à intégrer les mises à jour aux images personnalisées dans votre cycle de mises à jour standard, et assurez-vous que votre modèle Deployment Manager utilise la dernière image personnalisée.
Processus de basculement et tâches après redémarrage
En cas de sinistre, vous pouvez restaurer le système exécuté sur Google Cloud. Pour ce faire, vous devez lancer le processus de récupération afin de créer l'environnement de récupération à l'aide du modèle Deployment Manager que vous avez créé. Lorsque les instances de l'environnement de récupération sont prêtes à accepter le trafic de production, vous devez ajuster le DNS pour qu'il pointe vers le serveur Web dans Google Cloud.
Pour lancer une séquence de reprise, procédez comme suit :
- Utilisez le modèle Deployment Manager pour créer un déploiement dans Google Cloud.
- Appliquez la sauvegarde de base de données la plus récente dans Cloud Storage au serveur de base de données exécuté dans Google Cloud. Pour ce faire, suivez les instructions fournies par votre système de base de données pour récupérer les fichiers de sauvegarde.
- Appliquez les journaux de transactions les plus récents dans Cloud Storage.
- Vérifiez que l'application fonctionne comme prévu en simulant des scénarios utilisateur dans l'environnement récupéré.
- Une fois les tests réussis, configurez Cloud DNS pour qu'il pointe vers le serveur Web sur Google Cloud. (Par exemple, utilisez une adresse IP Anycast derrière un équilibreur de charge Google Cloud, avec plusieurs serveurs Web à l'arrière de l'équilibreur de charge.)
Le diagramme suivant montre l'environnement récupéré :
Lorsque l'environnement de production s'exécute à nouveau sur site et peut gérer les charges de travail de production, vous devez inverser les étapes que vous avez suivies pour basculer vers l'environnement de récupération Google Cloud. Une séquence de retour à l'environnement de production se déroule généralement de la façon suivante :
- Effectuez une sauvegarde de la base de données exécutée sur Google Cloud.
- Copiez le fichier de sauvegarde dans l'environnement de production.
- Appliquez le fichier de sauvegarde à votre système de base de données de production.
- Empêchez les connexions à l'application dans Google Cloud (par exemple, les connexions à l'équilibreur de charge global). À partir de là, votre application ne sera plus accessible jusqu'à la restauration de l'environnement de production.
- Copiez tous les fichiers journaux de transactions dans l'environnement de production, puis appliquez-les au serveur de base de données.
- Configurez Cloud DNS pour qu'il pointe vers votre service Web sur site.
- Assurez-vous que le processus en place pour copier les données sur Cloud Storage fonctionne comme prévu.
- Supprimez le déploiement.
Instance de secours dans un modèle tiède : récupération sur Google Cloud
Un modèle tiède est généralement mis en œuvre pour maintenir les valeurs RTO et RPO aussi faibles que possible sans les efforts et les dépenses liés à une configuration haute disponibilité complète. Plus les valeurs RTO et RPO sont faibles, plus les coûts sont élevés alors que vous êtes proche d'avoir un environnement entièrement redondant pouvant acheminer le trafic à partir de deux environnements. Par conséquent, la mise en place d'un modèle tiède pour le scénario de DR constitue un bon compromis entre budget et disponibilité.
Un exemple de cette approche consiste à se servir de Cloud Interconnect configuré avec une solution VPN autogérée pour fournir une connectivité à Google Cloud. Une application à plusieurs niveaux s'exécute sur site tout en utilisant une solution de récupération minimale sur Google Cloud. La solution de récupération se compose d'une instance de serveur de base de données opérationnelle sur Google Cloud. Cette instance doit toujours être en cours d'exécution pour pouvoir recevoir les transactions répliquées via des techniques de réplication asynchrone ou semi-synchrone. Pour réduire les coûts, vous pouvez exécuter la base de données sur le plus petit type de machine capable d'exécuter le service de base de données. Comme vous pouvez utiliser une instance de longue durée, des remises automatiques proportionnelles à une utilisation seront appliquées.
Composants fondamentaux de reprise après sinistre :
- Cloud DNS
- Cloud Interconnect
- Solution VPN autogérée
- Compute Engine
- Deployment Manager
Les instantanés de Compute Engine permettent de créer des sauvegardes que vous pouvez restaurer à un état antérieur. Les instantanés sont utilisés dans cet exemple, car les pages Web mises à jour et les fichiers binaires d'application sont souvent écrits sur le site Web de production et les serveurs d'applications. Ces mises à jour sont régulièrement répliquées sur le serveur Web de référence et les instances de serveur d'applications sur Google Cloud. (Les serveurs de référence n'acceptent pas le trafic de production, mais permettent de créer les instantanés.)
Le diagramme suivant représente une architecture mettant en œuvre cette approche. Les cibles de réplication ne sont pas illustrées ici.
Pour configurer votre environnement, procédez comme suit :
- Créez un réseau VPC.
- Configurez la connectivité entre votre réseau sur site et le réseau Google Cloud.
- Répliquez vos serveurs sur site sur des instances de VM Google Cloud. Une option consiste à utiliser une solution partenaire. La méthode employée dépend de votre situation.
- Créez une image personnalisée de votre serveur de base de données sur Google Cloud ayant la même configuration que votre serveur de base de données sur site.
- Créez des instantanés du serveur Web et des instances du serveur d'applications.
- Démarrez une instance de base de données dans Google Cloud à l'aide de l'image personnalisée que vous avez créée précédemment. Utilisez le plus petit type de machine capable d'accepter les données répliquées de la base de données de production sur site.
- Rattachez des disques persistants à l'instance de base de données Google Cloud pour les bases de données et les journaux de transactions.
- Configurez la réplication entre votre serveur de base de données sur site et le serveur de base de données dans Google Cloud, en suivant les instructions de votre logiciel de base de données.
- Définissez l'indicateur de suppression automatique sur les disques persistants rattachés à l'instance de base de données sur
no-auto-delete. - Configurez une tâche planifiée pour créer des instantanés réguliers des disques persistants de l'instance de base de données sur Google Cloud.
- Créez des réservations pour assurer la capacité de votre serveur Web et de vos serveurs d'applications, si nécessaire.
- Testez le processus de création d'instances à partir des instantanés et de la réalisation d'instantanés des disques persistants.
- Créez des instances du serveur Web et du serveur d'applications à l'aide des instantanés que vous avez créés précédemment.
- Créez un script qui copie les mises à jour de l'application Web et du serveur d'applications chaque fois que les serveurs correspondants sur site sont mis à jour. Écrivez le script pour générer un instantané des serveurs mis à jour.
- Configurez Cloud DNS pour qu'il pointe vers votre service Web sur site.
Processus de basculement et tâches après redémarrage
Pour gérer un basculement, vous devez généralement vous servir de votre système de surveillance et d'alerte pour appeler un processus de basculement automatisé. Lorsque l'application sur site doit basculer, vous devez configurer le système de base de données sur Google Cloud afin qu'il puisse accepter le trafic de production. Il faut également que vous démarriez les instances du serveur Web et d'applications.
Le diagramme suivant représente la configuration après le basculement vers Google Cloud, ce qui permet de diffuser les charges de travail de production à partir de Google Cloud :
Pour lancer une séquence de reprise, procédez comme suit :
- Redimensionnez l'instance du serveur de base de données afin de pouvoir gérer les charges de production.
- Servez-vous des instantanés de serveur Web et d'applications sur Google Cloud pour créer des instances de serveur Web et d'applications.
- Vérifiez que l'application fonctionne comme prévu en simulant des scénarios utilisateur dans l'environnement récupéré.
- Une fois les tests réussis, configurez Cloud DNS pour qu'il pointe vers votre service Web sur Google Cloud.
Lorsque l'environnement de production s'exécute à nouveau sur site et peut gérer les charges de travail de production, vous devez inverser les étapes que vous avez suivies pour basculer vers l'environnement de récupération Google Cloud. Une séquence de retour à l'environnement de production se déroule typiquement de la façon suivante :
- Effectuez une sauvegarde de la base de données exécutée sur Google Cloud.
- Copiez le fichier de sauvegarde dans l'environnement de production.
- Appliquez le fichier de sauvegarde à votre système de base de données de production.
- Empêchez les connexions à l'application dans Google Cloud Pour ce faire, vous pouvez empêcher les connexions au serveur Web en modifiant les règles de pare-feu. À partir de là, votre application ne sera plus accessible jusqu'à la restauration de l'environnement de production.
- Copiez tous les fichiers journaux de transactions dans l'environnement de production, puis appliquez-les au serveur de base de données.
- Vérifiez que l'application fonctionne comme prévu en simulant des scénarios utilisateur dans l'environnement de production.
- Configurez Cloud DNS pour qu'il pointe vers votre service Web sur site.
- Supprimez les instances du serveur Web et du serveur d'applications qui s'exécutent dans Google Cloud. Laissez les serveurs de référence continuer à s'exécuter.
- Redimensionnez le serveur de base de données sur Google Cloud en lui appliquant la taille minimale de l'instance pouvant accepter les données répliquées à partir de la base de données de production sur site.
- Configurez la réplication entre votre serveur de base de données sur site et le serveur de base de données dans Google Cloud, en suivant les instructions de votre logiciel de base de données.
Configuration HA à chaud sur site et sur Google Cloud
Si vous avez des valeurs RTO et RPO faibles, vous ne pouvez les atteindre qu'en exécutant simultanément la haute disponibilité dans votre environnement de production et dans Google Cloud. Cette approche fournit un modèle à chaud, car le trafic de production est acheminé à la fois par les services sur site et par Google Cloud.
La principale différence par rapport à un modèle tiède est que les ressources des deux environnements s'exécutent en mode production et acheminent le trafic de production.
Composants fondamentaux de reprise après sinistre :
- Cloud Interconnect
- Cloud VPN
- Compute Engine
- Groupes d'instances gérés
- Cloud Monitoring
- Cloud Load Balancing
Le diagramme ci-dessous représente l'architecture de cet exemple. Sa mise en œuvre vous permet de disposer d'un plan de DR qui n'exige qu'une intervention minimale en cas de sinistre.
Pour configurer votre environnement, procédez comme suit :
- Créez un réseau VPC.
- Configurez la connectivité entre votre réseau sur site et votre réseau Google Cloud.
- Créez des images personnalisées dans Google Cloud, configurées pour chaque serveur dans l'environnement de production sur site. Chaque image Google Cloud doit avoir la même configuration que son équivalent sur site.
Configurez la réplication entre votre serveur de base de données sur site et le serveur de base de données dans Google Cloud, en suivant les instructions de votre logiciel de base de données.
De nombreux systèmes de base de données n'autorisent qu'une seule instance de base de données accessible en écriture lorsque vous configurez la réplication. Par conséquent, vous devrez peut-être vous assurer que l'une des instances dupliquées de la base de données agit en tant que serveur en lecture seule.
Créez des modèles d'instance individuels qui utilisent les images des serveurs d'applications et des serveurs Web.
Configurez des groupes d'instances gérés régionaux pour le serveur d'applications et le serveur Web.
Configurez les vérifications d'état à l'aide de Cloud Monitoring.
Configurez l'équilibrage de charge à l'aide des groupes d'instances gérés régionaux que vous avez configurés précédemment.
Configurez une tâche planifiée pour créer des instantanés réguliers des disques persistants.
Configurez un service DNS pour répartir le trafic entre votre environnement sur site et l'environnement Google Cloud.
Avec cette approche hybride, vous devez utiliser un service DNS qui accepte le routage pondéré vers les deux environnements de production afin de pouvoir diffuser la même application depuis les deux environnements.
Vous devez concevoir le système pour les défaillances pouvant survenir dans seulement une partie de l'environnement (échecs partiels). Dans ce cas, le trafic doit être redirigé vers le service équivalent dans l'autre environnement de sauvegarde. Par exemple, si les serveurs Web sur site deviennent indisponibles, vous pouvez désactiver le routage DNS vers cet environnement. Si votre service DNS accepte les vérifications de l'état, le processus est automatique lorsque la vérification de l'état détermine que les serveurs Web de l'un des environnements ne sont pas accessibles.
Dans la plupart des cas, si vous utilisez un système de base de données n'autorisant qu'une seule instance en écriture, l'instance dupliquée en lecture seule sera automatiquement promue instance principale en écriture lorsque la pulsation entre la base de données en écriture d'origine et l'instance dupliquée en lecture perd le contact. Veillez à bien comprendre cet aspect de la réplication de votre base de données au cas où vous devriez intervenir après un sinistre.
Vous devez mettre en œuvre des processus pour vous assurer que la version de l'application reproduite dans les images de VM personnalisées sur Google Cloud est la même que celle de l'application sur site. Intégrez les mises à jour aux images personnalisées dans votre cycle de mises à jour standard, et assurez-vous que votre modèle Deployment Manager utilise la dernière image personnalisée.
Processus de basculement et tâches après redémarrage
Dans la configuration de scénario à chaud décrite ici, un sinistre signifie que l'un des deux environnements n'est pas disponible. Il n'existe pas de processus de basculement semblable aux scénarios tièdes ou à froid, dans lesquels vous devez déplacer des données ou effectuer le traitement dans le deuxième environnement. Cependant, vous devrez peut-être procéder aux modifications de configuration suivantes :
- Si votre service DNS ne redirige pas automatiquement le trafic en cas d'échec de la vérification de l'état, vous devez reconfigurer manuellement le routage DNS pour envoyer le trafic au système encore opérationnel.
- Si votre système de base de données ne promeut pas automatiquement une instance dupliquée en lecture seule comme instance principale en écriture en cas d'échec, vous devez intervenir pour promouvoir l'instance dupliquée.
Lorsque le deuxième environnement s'exécute à nouveau et peut gérer le trafic de production, vous devez resynchroniser les bases de données. Comme les deux environnements sont disponibles pour les charges de travail de production, vous n'avez pas à intervenir pour définir la base de données principale. Une fois les bases de données synchronisées, vous pouvez à nouveau autoriser la distribution du trafic de production entre les deux environnements en modifiant les paramètres DNS.
Architectures DR et HA pour la production sur Google Cloud
Lors de la conception de votre architecture d'applications pour la charge de travail de production sur Google Cloud, les fonctionnalités HA de la plate-forme ont une influence directe sur l'architecture de DR.
Scénario à froid : serveur d'application récupérable
Dans un scénario de basculement à froid où vous avez besoin d'une seule instance de serveur active, une seule instance doit écrire sur le disque. Dans un environnement sur site, vous utilisez souvent un cluster actif/passif. Lorsque vous exécutez un environnement de production sur Google Cloud, vous pouvez créer une VM dans un groupe d'instances géré qui n'exécute qu'une seule instance.
Composants fondamentaux de la reprise après sinistre :
- Compute Engine
- Groupes d'instances gérés
Ce scénario de basculement à froid est illustré dans l'exemple d'architecture suivant :
Pour obtenir une présentation complète du déploiement de cet exemple de scénario et tester la récupération en cas de défaillance, consultez la page Déployer un serveur Web récupérable à froid à l'aide d'instantanés de disques persistants.
La procédure suivante explique comment configurer ce scénario de basculement à froid :
- Créez un réseau VPC.
- Créez une image de VM personnalisée configurée avec le service Web de votre application.
- Configurez la VM de sorte que les données traitées par le service de l'application soient écrites sur un disque persistant associé.
- Créez un instantané à partir du disque persistant associé.
- Créez un modèle d'instance qui référence l'image de VM personnalisée du serveur Web.
- Configurez un script de démarrage pour créer un disque persistant à partir du dernier instantané et installer le disque. Ce script doit pouvoir obtenir le dernier instantané du disque.
- Créez un groupe d'instances géré et des vérifications d'état avec une taille cible de un (1) faisant référence au modèle d'instance.
- Créez une tâche programmée pour créer des instantanés réguliers du disque persistant.
- Configurez un équilibreur de charge d'application externe.
- Configurez des alertes à l'aide de Cloud Monitoring pour envoyer une alerte en cas de défaillance du service.
Ce scénario de basculement à froid exploite certaines des fonctionnalités de haute disponibilité de Google Cloud. En cas de défaillance d'une VM, le groupe d'instances géré tente de recréer automatiquement la VM. Vous n'avez pas besoin de lancer cette étape de basculement. L'équilibreur de charge d'application externe garantit que même lorsqu'une VM de remplacement est nécessaire, l'adresse IP derrière laquelle le serveur d'application est placé ne change pas. Le modèle d'instance et l'image personnalisée garantissent que la VM de remplacement est configurée de la même manière que l'instance qu'elle remplace.
Votre RPO est déterminé par le dernier instantané. Plus vous capturez souvent des instantanés, plus la valeur de RPO est faible.
Le groupe d'instances géré fournit une haute disponibilité en profondeur. Le groupe d'instances géré offre la possibilité de réagir aux défaillances au niveau de l'application ou de la VM. Vous n'avez pas besoin d'intervenir manuellement si l'un de ces scénarios se produit. Une taille cible de un (1) est la garantie qu'une seule instance active s'exécute dans le groupe d'instances géré pour diffuser le trafic.
La nature zonale des disques persistants requiert des instantanés pour recréer des disques en cas de défaillance dans la zone. Des instantanés sont également disponibles dans toutes les régions, ce qui vous permet de restaurer un disque dans une autre région aussi facilement que dans la même région.
Dans le cas peu probable d'une défaillance de zone, vous devez intervenir manuellement pour effectuer la récupération, comme indiqué dans la section suivante.
Processus de basculement
Si une VM échoue, le groupe d'instances géré tente automatiquement de recréer une VM dans la même zone. Le script de démarrage du modèle d'instance crée un disque persistant à partir du dernier instantané et l'associe à la nouvelle VM.
Toutefois, un groupe d'instances géré dont la taille est définie sur un (1) ne peut pas être récupéré en cas de défaillance d'une zone. En cas de défaillance d'une zone, vous devez réagir à l'alerte de Cloud Monitoring ou d'une autre plate-forme de surveillance lorsque le service rencontre une défaillance, puis créer manuellement un groupe d'instances dans une autre zone.
Une variante de cette configuration consiste à utiliser des disques persistants régionaux plutôt que des disques persistants zonaux. Dans cette approche, il n'est pas nécessaire de se servir d'instantanés pour restaurer le disque persistant dans le cadre de l'étape de reprise. Cependant, cette variante consomme deux fois plus d'espace de stockage, et vous devez le prévoir dans votre budget. Pour déployer ce scénario alternatif et tester la reprise après sinistre, consultez la page Déployer un serveur Web récupérable à froid avec des disques persistants régionaux.
L'approche que vous choisissez est déterminée par votre budget ainsi que par les valeurs RTO et RPO.
Scénario tiède : basculement d'un site statique
Si les instances Compute Engine échouent, vous pouvez limiter les interruptions de service en ayant recours à un site statique en veille basé sur Cloud Storage. L'utilisation d'un site statique est une solution lorsque votre application Web est principalement statique. Dans ce scénario, l'application principale s'exécute sur des instances Compute Engine. Ces instances sont réunies dans des groupes d'instances gérés, lesquels font office de services de backend pour un équilibreur de charge HTTPS. Celui-ci dirige le trafic entrant vers les instances en fonction de sa configuration, de la configuration de chaque groupe d'instances et de l'état de chaque instance.
Composants fondamentaux de reprise après sinistre :
- Compute Engine
- Cloud Storage
- Cloud Load Balancing
- Cloud DNS
Le diagramme ci-dessous représente l'architecture de cet exemple :
Pour obtenir une présentation complète du déploiement de cet exemple de scénario et du test de la reprise après échec, consultez la page Déployer un serveur Web tiède récupérable à l'aide de Cloud DNS avec Compute Engine et Cloud Storage.
Pour configurer ce scénario, procédez comme suit :
- Créez un réseau VPC.
- Créez une image personnalisée configurée avec le service Web de l'application.
- Créez un modèle d'instance qui utilise l'image pour les serveurs Web.
- Configurez un groupe d'instances géré pour les serveurs Web.
- Configurez les vérifications de l'état à l'aide de Monitoring.
- Configurez l'équilibrage de charge à l'aide des groupes d'instances gérés que vous avez configurés précédemment.
- Créez un site statique basé sur Cloud Storage.
Dans la configuration de production, Cloud DNS est configuré pour pointer vers cette application principale et le site statique demeure en état de veille. Si l'application Compute Engine tombe en panne, vous devez configurer Cloud DNS pour qu'il pointe vers ce site statique.
Processus de basculement
Si le ou les serveurs d'application tombent en panne, votre séquence de reprise consiste à configurer Cloud DNS pour qu'il pointe vers votre site Web statique. Le diagramme suivant représente l'architecture en mode récupération :
Lorsque les instances de l'application Compute Engine s'exécutent à nouveau et sont en mesure de traiter les charges de travail de production, vous inversez les étapes de récupération : vous configurez Cloud DNS pour qu'il pointe vers l'équilibreur de charge à l'avant des instances.
Pour découvrir une autre approche qui utilise l'équilibreur de charge d'application externe au lieu de Cloud DNS pour contrôler le basculement, consultez la page Déploiement d'un serveur Web tiède récupérable avec Compute Engine et Cloud Storage. Ce modèle est utile si vous n'avez pas ou ne souhaitez pas utiliser Cloud DNS.
Scénario à chaud : application Web HA
Lorsque votre environnement de production s'exécute sur Google Cloud, un modèle à chaud consiste à établir un déploiement HA solidement structuré.
Composants fondamentaux de reprise après sinistre :
- Compute Engine
- Cloud Load Balancing
- Cloud SQL
Le diagramme ci-dessous représente l'architecture de cet exemple :
Ce scénario exploite les fonctionnalités HA disponibles dans Google Cloud. Vous n'avez pas à lancer de procédure de basculement, car elles seront automatiquement appliquées en cas de sinistre.
Comme illustré dans le diagramme, l'architecture utilise un groupe d'instances géré régional avec un équilibrage de charge global et Cloud SQL. Dans notre exemple, un groupe d'instances géré régional permet de distribuer les instances sur trois zones.
Avec cette approche, vous obtenez une haute disponibilité en profondeur. Les groupes d'instances gérés régionaux intègrent des mécanismes qui réagissent aux défaillances survenant au niveau de l'application, de l'instance ou de la zone. Vous n'avez pas à intervenir manuellement si l'un de ces scénarios se produit.
Lors de la préparation du groupe d'instances gérés pour procéder à la récupération au niveau de l'application, vous devez configurer les vérifications de l'état HTTP qui contrôlent que les services s'exécutent correctement sur les instances de ce groupe. Si une vérification de l'état identifie un service défaillant sur une instance, le groupe recrée automatiquement cette instance.
Si vous souhaitez connaître la procédure détaillée pour configurer une application Web HA sur Google Cloud, consultez la page sur les applications Web évolutives et résilientes sur 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
- Structure de la reprise après sinistre
- Scénarios de reprise après sinistre pour les données
- 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.