Cette page présente la reprise après sinistre dans Cloud SQL.
Aperçu
Dans Google Cloud, la reprise après sinistre (DR, disaster recovery) de base de données consiste à assurer la continuité du traitement, en particulier en cas de défaillance ou d'indisponibilité d'une région. Cloud SQL est un service régional (lorsque Cloud SQL est configuré pour la haute disponibilité). Par conséquent, si la région Google Cloud qui héberge une base de données Cloud SQL devient indisponible, la base de données devient elle aussi indisponible.
Pour assurer la continuité du traitement, vous devez rendre la base de données disponible dans une région secondaire dès que possible. Le plan de reprise après sinistre nécessite la configuration d'une instance dupliquée interrégionale avec accès en lecture dans Cloud SQL. Un basculement basé sur l'exportation/importation ou sur la sauvegarde/restauration est également possible, mais cette approche prend plus de temps, en particulier pour les bases de données volumineuses.
Les scénarios métier suivants sont des exemples qui justifient une configuration de basculement interrégionale :
- Le contrat de niveau de service de l'application métier garantit une disponibilité supérieure à celle du contrat de niveau de service Cloud SQL régional (disponibilité de 99,99 %, selon votre édition de Cloud SQL). En basculant vers une région secondaire, vous pouvez limiter l'impact d'une indisponibilité de service.
- Tous les niveaux de l'application métier sont déjà multirégionaux et peuvent poursuivre les traitements en cours en cas de panne régionale. La configuration de basculement interrégionale garantit la disponibilité continue d'une base de données.
- L'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) attendus sont exprimés en minutes, et non en heures. Il est plus rapide de basculer vers une autre région que de recréer une base de données.
En général, il existe deux variantes pour le processus de reprise après sinistre :
- La base de données bascule vers une région secondaire. Une fois que la base de données basculée est prête et qu'elle est utilisée par une application, elle devient la nouvelle base de données principale et conserve ce statut.
- Une base de données bascule vers une région secondaire, mais repasse à la région principale une fois que celle-ci est à nouveau disponible.
Cette présentation de la reprise après sinistre de base de données Google Cloud SQL décrit la deuxième variante : lorsqu'une base de données défaillante est récupérée et revient à la région principale. Cette variante du processus de reprise après sinistre est particulièrement pertinent pour les bases de données devant s'exécuter dans la région principale en raison de la latence du réseau, ou parce que certaines ressources ne sont disponibles que dans cette région. Avec cette variante, la base de données ne s'exécute dans la région secondaire que pour la durée de l'indisponibilité du service dans la région principale.
Architecture de reprise après sinistre
Le schéma suivant illustre l'architecture minimale permettant la reprise après sinistre de la base de données pour une instance Cloud SQL à haute disponibilité :
L'architecture fonctionne comme suit :
- Deux instances Cloud SQL (une instance principale et une instance de secours) sont situées dans deux zones distinctes d'une même région (la région principale). Les instances sont synchronisées par le biais de disques persistants régionaux.
- Une instance Cloud SQL (instance dupliquée interrégionale avec accès en lecture) est située dans une deuxième région (la région secondaire). Pour la reprise après sinistre, l'instance dupliquée interrégionale avec accès en lecture est configurée pour se synchroniser (via la réplication asynchrone) avec l'instance principale à l'aide d'une configuration d'instance dupliquée avec accès en lecture.
Les instances principale et de secours partagent le même disque régional, leurs états sont donc identiques.
Étant donné que cette configuration utilise une réplication asynchrone, il est possible que l'instance dupliquée interrégionale avec accès en lecture accuse un léger retard sur l'instance principale. Lorsqu'un basculement a lieu, l'instance dupliquée interrégionale avec accès en lecture peut accepter un RPO de zéro.
Processus de reprise après sinistre
Le processus de reprise après sinistre commence lorsque la région principale devient indisponible. Pour reprendre le traitement dans une région secondaire, vous devez déclencher un basculement de l'instance principale en promouvant une instance répliquée interrégionale avec accès en lecture. Le processus de reprise après sinistre définit les étapes opérationnelles qui doivent être effectuées, manuellement ou automatiquement, afin de minimiser l'impact de la défaillance régionale et de lancer l'exécution d'une instance principale dans une région secondaire.
Le schéma suivant illustre le processus de reprise après sinistre :
Le processus de reprise après sinistre comprend les étapes suivantes.
- La région principale (R1), dans laquelle l'instance principale est exécutée, devient indisponible.
- L'équipe en charge des opérations reconnaît officiellement le sinistre et décide si un basculement est nécessaire.
- Si un basculement est nécessaire, vous pouvez promouvoir l'instance répliquée interrégionale avec accès en lecture dans la région secondaire (R2) en tant que nouvelle instance principale.
- Les connexions client sont reconfigurées pour reprendre le traitement sur la nouvelle instance principale et accéder à l'instance principale dans la région R2.
Ce processus initial permet de retrouver une base de données principale opérationnelle. Toutefois, il n'établit pas une architecture de reprise après sinistre complète, dans laquelle la nouvelle instance principale dispose à son tour d'une instance de secours et d'une instance dupliquée interrégionale avec accès en lecture.
Un processus de reprise après sinistre complet garantit que l'instance unique, la nouvelle instance principale, est activée pour la haute disponibilité et dispose d'une instance dupliquée interrégionale avec accès en lecture. Un processus de reprise après sinistre complet fournit également une solution de remplacement pour le déploiement d'origine dans la région principale d'origine.
Basculer vers une région secondaire
Un processus complet de reprise après sinistre étend le processus de base en ajoutant des étapes qui permettent d'établir une architecture complète de reprise après sinistre après un basculement. Le schéma suivant illustre une architecture complète de reprise après sinistre pour une base de données après le basculement :
Le processus complet de reprise après sinistre pour une base de données comprend les étapes suivantes :
- La région principale (R1), dans laquelle la base de données principale est exécutée, devient indisponible.
- L'équipe en charge des opérations reconnaît officiellement le sinistre et décide si un basculement est nécessaire.
- Si un basculement est nécessaire, vous pouvez promouvoir l'instance dupliquée interrégionale avec accès en lecture dans la région secondaire (R2) en tant que nouvelle instance principale.
- Les connexions client sont configurées de manière à accéder à la nouvelle instance principale (R2) et à travailler dessus.
- Une nouvelle instance de secours est créée et démarrée dans R2 et ajoutée à l'instance principale. L'instance de secours se trouve dans une zone différente de celle de l'instance principale. L'instance principale offre désormais une disponibilité élevée, car une instance de secours a été créée pour elle.
- Une nouvelle instance dupliquée interrégionale avec accès en lecture est créée dans une troisième région (R3), puis elle est associée à l'instance principale. À ce stade, vous disposez d'une architecture de reprise après sinistre complète et opérationnelle.
Si la région principale d'origine (R1) redevient disponible avant la mise en œuvre de l'étape 6, l'instance dupliquée interrégionale avec accès en lecture peut être placée directement dans la région R1 plutôt que dans la région R3. Notez qu'en ce cas, la mise en œuvre d'une solution de remplacement vers la région principale d'origine (R1) est moins complexe et nécessite moins d'étapes.
Éviter toute situation de split-brain
Une défaillance de la région principale (R1) ne signifie pas que l'instance principale d'origine et son instance de secours sont automatiquement arrêtées ou supprimés, ou qu'elles seront toujours inaccessibles lorsque la région R1 redeviendra disponible. Si R1 redevient disponible, les clients peuvent lire et écrire des données (même par accident) sur l'instance principale d'origine. Dans ce cas, une situation de split-brain peut se produire. Certains clients peuvent accéder à des données obsolètes dans l'ancienne base de données principale, tandis que d'autres accèdent à des données actualisées dans la nouvelle base de données principale, ce qui peut perturber vos activités.
Pour éviter toute situation de split-brain, vous devez vous assurer que les clients ne pourront plus accéder à l'instance principale d'origine une fois que R1 redeviendra disponible. Idéalement, vous devez rendre l'instance principale d'origine inaccessible avant que les clients ne commencent à utiliser la nouvelle instance principale, puis supprimer l'instance principale d'origine immédiatement après l'avoir rendue inaccessible.
Établir une sauvegarde initiale après le basculement
Lorsque vous promouvez l'instance dupliquée interrégionale avec accès en lecture en tant que nouvelle instance principale dans le cadre d'un basculement, il est possible que les transactions de la nouvelle instance principale ne soient pas entièrement synchronisées avec les transactions de l'instance principale d'origine. Par conséquent, les transactions "d'origine" peuvent ne pas être disponibles dans la nouvelle instance.
Il est recommandé de sauvegarder immédiatement la nouvelle instance principale dès le début du basculement et avant que les clients n'accèdent à la base de données. Cette sauvegarde représente un état cohérent et connu au moment du basculement. De telles sauvegardes peuvent être importantes à des fins réglementaires, ou pour effectuer la récupération d'un état connu si les clients rencontrent des problèmes lors de l'accès à la nouvelle instance principale.
Rebasculer sur la région principale d'origine
Comme décrit précédemment, ce document précise les étapes nécessaires pour revenir à la région d'origine (R1). Il existe deux versions différentes du processus de remplacement.
- Si vous avez créé la nouvelle instance dupliquée interrégionale avec accès en lecture dans une troisième région (R3), vous devez créer une autre (une deuxième) instance dupliquée interrégionale avec accès en lecture dans la région principale (R1).
- Si vous avez créé la nouvelle instance dupliquée interrégionale avec accès en lecture dans la région principale (R1), vous n'avez pas besoin de créer une autre instance dupliquée interrégionale avec accès en lecture dans la région R1.
Une fois que l'instance dupliquée interrégionale avec accès en lecture est créée dans la région R1, l'instance Cloud SQL peut rebasculer vers la région R1. Comme le remplacement est déclenché manuellement et non basé sur une panne, vous pouvez choisir un jour et une heure appropriés pour cette activité de maintenance.
Ainsi, pour obtenir une solution de reprise après sinistre complète comprenant une instance principale, une instance de secours et instance dupliquée interrégionale avec accès en lecture, vous avez besoin de deux basculements. Le premier basculement est déclenché par l'interruption de service (il s'agit d'un véritable basculement). Quant au second, il rétablit le déploiement de départ (il s'agit d'une opération de remplacement).
Le retour à la région principale d'origine (R1) comprend les étapes suivantes :
- Promouvoir l'instance répliquée interrégionale nouvellement créée dans la région principale d'origine (R1).
- Si l'instance promue n'a pas été créée à l'origine en tant qu'instance répliquée haute disponibilité, activez la haute disponibilité sur l'instance pour vous protéger contre les défaillances de zone.
- Reconfigurer vos applications pour qu'elles se connectent à la nouvelle instance principale.
- Créer une instance répliquée interrégionale pour la nouvelle instance principale dans la région de reprise après sinistre (R2).
- (Facultatif) Pour éviter d'exécuter plusieurs instances principales indépendantes, nettoyer l'instance principale dans la région de reprise après sinistre (R2).
Étapes suivantes
- Découvrez des architectures de référence, des schémas, des tutoriels et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.