Introduction à la continuité d’activité et à la récupération après sinistre

Cette rubrique décrit les principaux cas d’utilisation pour la réplication et le basculement de données vers un compte Snowflake dans une autre région, voire une autre plateforme Cloud.

La fonctionnalité de réplication et de basculement/restauration de Snowflake est composée des fonctionnalités suivantes :

Réplication de base de données

La réplication de base de données permet de stocker des répliques en lecture seule d’une base de données primaire dans d’autres comptes Snowflake. Ces comptes, qui doivent être regroupés dans la même organisation, peuvent être situés dans différentes régions ou plateformes Cloud. L’actualisation de chaque réplique (base de données secondaire) synchronise les objets de la base de données et les données stockées avec sa base de données primaire.

Basculement/restauration de la base de données

Le basculement/restauration de base de données promeut une réplique pour servir de base de données primaire. À ce stade, l’ancienne base de données primaire devient une base de données secondaire en lecture seule, et l’ancienne réplique devient la base de données primaire en lecture-écriture.

Redirection des clients

La redirection des clients fournit une URL de connexion qui peut être utilisée par les clients de Snowflake pour se connecter à Snowflake. L’URL de connexion peut être redirigée vers un autre compte Snowflake si nécessaire.

Collectivement, ces fonctionnalités individuelles sont conçues pour prendre en charge un certain nombre de scénarios commerciaux fondamentaux différents, notamment :

  • Récupération après une panne dans une région de plateforme Cloud, en privilégiant les écritures de la base de données par rapport aux lectures.

  • Récupération après une panne dans une région de plateforme Cloud, en privilégiant les lectures de la base de données par rapport aux écritures.

  • Récupération après une panne dans une région de plateforme Cloud, en privilégiant à la fois les lectures et les écritures de la base de données.

  • Migration de vos bases de données d’une plateforme Cloud ou d’une région à une autre.

En outre, Snowflake Secure Data Sharing et la réplication de base de données permettent de partager les données en toute sécurité entre les régions et les plateformes Cloud.

Dans ce chapitre :

Continuité d’activité et récupération après sinistre

En cas de panne massive (en raison d’un problème de réseau, d’un bogue, etc.) perturbant les services Cloud computing dans une région donnée, l’accès à Snowflake sera indisponible jusqu’à ce que la source de la panne soit résolue et les services restaurés. Pour garantir la disponibilité continue et la durabilité des données dans un tel scénario, répliquez vos bases de données critiques sur un autre compte Snowflake de votre organisation dans une autre région.

Avec la réplication asynchrone, les répliques secondaires sont généralement en retard par rapport à la base de données primaire, en fonction de la fréquence de réplication que vous configurez. Par exemple, si vous choisissez de répliquer une base de données primaire toutes les 30 minutes, la réplique secondaire aura au maximum 30 minutes de retard sur la primaire pendant une panne.

Selon les besoins de votre entreprise, vous pouvez choisir les solutions suivantes :

  • Récupérer les lectures de la base de données en premier pour laisser les applications clientes lire les données qui sont périmées depuis 30 minutes.

  • Récupérer d’abord les écritures de la base de données pour récupérer les 30 dernières minutes de données sur la nouvelle base primaire avant d’ouvrir les lectures des applications clientes.

  • Récupérer simultanément les lectures et les écritures de la base de données, c’est-à-dire ouvrir les lectures des applications clientes sur des données périmées depuis 30 minutes pendant que vous récupérez les 30 dernières minutes de données sur la nouvelle base primaire.

Pour donner la priorité aux lectures et aux écritures de la base de données, suivez les étapes de l’un des scénarios suivants. Lorsqu’une panne survient dans une région, choisissez de basculer simultanément vos bases de données critiques et vos connexions client Snowflake.

Lectures de la base de données avant les écritures

Lorsqu’une panne dans une région entraîne une perte totale ou partielle de la disponibilité de Snowflake, ce chemin vous permet de rediriger les clients Snowflake vers les répliques en lecture seule des bases de données critiques en premier lieu pour un temps d’arrêt minimal. Le choix de fonctionner en mode lecture seule est souvent souhaitable lors de pannes de courte durée.

Une panne de longue durée combinée à la nécessité de disposer des dernières données nécessite le mode lecture-écriture.

Les étapes de ce chemin sont les suivantes.

Statut normal : la région est opérationnelle

  1. Réplication de bases de données : Répliquez les bases de données critiques sur un ou plusieurs comptes Snowflake dans des régions différentes de celle du compte qui stocke les bases de données primaires (source). Actualisez fréquemment les objets de la base de données et les données stockées.

Panne de la région

  1. Redirection des clients : Dirigez l’URL de connexion utilisée par les clients vers un compte Snowflake qui stocke vos répliques de bases de données (secondaires) en lecture seule.

  2. Basculement de la base de données (en cas de besoin) : en cas de panne à long terme, faites en sorte que les bases de données secondaires du compte Snowflake où pointe votre URL de connexion servent de bases de données primaires en lecture-écriture.

Statut normal : la panne est résolue

  1. Réplication des bases de données : actualisez les bases de données du compte Snowflake dans la région où la panne s’est produite.

  2. Restauration de la base de données : promouvez les bases de données du compte Snowflake où la panne s’est produite pour qu’elles servent à nouveau de bases de données primaires.

  3. Redirection des clients : dirigez l’URL de connexion utilisée par les clients vers le compte Snowflake dans la région où la panne s’est produite.

Écritures de la base de données avant lectures

Lorsqu’une panne dans une région entraîne une perte totale ou partielle de la disponibilité de Snowflake, ce chemin vous permet de récupérer les bases de données critiques et de continuer à traiter les données en priorité. Cette option est préférable pour les administrateurs de comptes qui souhaitent basculer leurs bases de données et leurs processus ETL (Extraction, Transformation, Chargement) en premier lieu, puis choisir de rediriger les clients Snowflake uniquement lorsque les données sont à jour.

Les étapes de ce chemin sont les suivantes.

Statut normal : la région est opérationnelle

  1. Réplication de bases de données : Répliquez les bases de données critiques sur un ou plusieurs comptes Snowflake dans des régions différentes de celle du compte qui stocke les bases de données primaires (source). Actualisez fréquemment les objets de la base de données et les données stockées.

Panne de la région

  1. Basculement de base de données : promouvez des répliques de bases de données critiques dans une région différente pour servir de bases de données primaires, ce qui permet d’écrire dans ces bases de données. Une fois que les bases de données sont accessibles en écriture, vous pouvez utiliser vos processus ETL pour prioriser les écritures et récupérer les données.

  2. Redirection des clients (si nécessaire) : dirigez l’URL de connexion utilisée par les clients vers le compte Snowflake qui stocke les nouvelles bases de données primaires.

Statut normal : la panne est résolue

  1. Réplication des bases de données : actualisez les bases de données du compte Snowflake dans la région où la panne s’est produite.

  2. Restauration de la base de données : promouvez les bases de données du compte Snowflake où la panne s’est produite pour qu’elles servent à nouveau de bases de données primaires.

  3. Redirection des clients : dirigez l’URL de connexion utilisée par les clients vers le compte Snowflake dans la région où la panne s’est produite.

Flux de continuité d’activité et de récupération après sinistre

Les diagrammes de cette section montrent les flux pour la continuité des activités et la reprise après sinistre.

Flux pour les bases de données

  1. Le diagramme suivant montre deux comptes appartenant à la même entreprise, mais dans des régions différentes (Region A et Region B). Dans un compte, une base de données locale a été promue pour servir de base de données principale. La réplication a été activée pour l’autre compte, ce qui lui permet de stocker un réplica de la base de données principale (c’est-à-dire une base de données secondaire) :

    Initial state of database replication
  2. Le diagramme suivant illustre une base de données secondaire créée dans le compte dans Region B. La flèche verte montre une opération d’actualisation des données en cours de la base de données primaire à la base de données secondaire :

    Data replication operation in progress
  3. Le diagramme suivant illustre un scénario de basculement : une interruption de service dans Region A, où se trouve le compte contenant la base de données primaire. La base de données secondaire (dans Region B) a été promue pour servir de base de données primaire. Parallèlement, l’ancienne base de données principale est devenue une base de données secondaire en lecture seule :

    Database failover

    Les étapes pour basculer une base de données sont décrites dans Basculement de bases de données sur plusieurs comptes.

  4. Le diagramme suivant montre que la panne de service dans Region A a été résolue. Une opération d’actualisation de la base de données est en cours depuis la base de données principale (dans Region B) vers la base de données secondaire (dans Region A) :

    Database failover
  5. Le dernier diagramme montre les opérations ayant retrouvé leur configuration initiale (c.-à-d. restauration automatique). La base de données secondaire (dans Region A) a été promue pour servir de nouveau de base de données principale pour les opérations commerciales normales. Parallèlement, l’ancienne base de données primaire (dans Region B) est devenue une base de données secondaire en lecture seule :

    Database failover

Flux pour les connexions

  1. Le diagramme suivant affiche deux comptes dans la même organisation mais dans des régions différentes (Region A et Region B) sur des plateformes Cloud identiques ou différentes. L’URL de connexion pour les connexions clients est configurée pour un compte dans Region A :

    Normal client connections
  2. Le diagramme suivant montre une interruption de service dans Region A qui entraîne l’échec des connexions des clients :

    Failed client connections
  3. Le schéma suivant montre que l’URL de connexion pour les connexions clients est maintenant configurée pour un compte dans Region B. Les clients se connectant à l’URL de connexion se connectent maintenant au compte dans Region B.

    Notez que la redirection des clients est un processus manuel. Voir les instructions dans Rediriger les connexions du client pour plus d’informations.

    Redirected client connections

Migration des comptes

La migration du compte est le processus unique de migration (ou de transfert) des objets Snowflake et de vos données stockées vers un compte situé dans une autre région ou sur une autre plateforme Cloud. Les raisons typiques de la migration de votre compte incluent une plus grande proximité avec votre base d’utilisateurs ou une préférence pour une plateforme Cloud différente basée sur votre stratégie d’entreprise ou la co-localisation avec d’autres actifs de Cloud (par exemple, un data lake).

Actuellement, la prise en charge de la réplication des objets Snowflake est limitée aux bases de données en tant que conteneurs pour les objets qui stockent des données (par exemple, les tables et les vues, y compris les vues matérialisées). Voir Objets de base de données répliqués pour la liste complète des objets répliqués. Travaillez avec l’assistance de Snowflake pour répliquer les objets du compte (par exemple, les utilisateurs et les rôles) ainsi que d’autres objets Snowflake vers le nouveau compte.

Note

Le basculement/la restauration de la base de données nécessite Business Critical (ou une version supérieure). Snowflake peut renoncer temporairement à cette exigence pour une migration de compte unique.