Cette page a été traduite par l'API Cloud Translation.

Exemples de configurations de réplication

Cette page décrit quelques cas d'utilisation courants de Bigtable la réplication et présente les paramètres que vous pouvez utiliser pour les utiliser cas d'utilisation.

Isoler les charges de travail d'analyse par lot des autres applications
Créer une haute disponibilité
Fournir une sauvegarde en quasi-temps réel
Maintenir une haute disponibilité et une résilience régionale
Stocker des données à proximité des utilisateurs

Cette page explique également comment choisir les paramètres à utiliser pour d'autres cas d'utilisation.

Avant de lire cette page, vous devez avoir pris connaissance de la présentation de la réplication Bigtable.

Avant d'ajouter des clusters à une instance, vous devez prendre en compte les restrictions qui s'appliquent lorsque vous modifiez les stratégies de récupération de mémoire des tables répliquées.

Dans la plupart des cas, activez l'autoscaling pour les clusters de votre instance. L'autoscaling permet à Bigtable d'ajouter et de supprimer automatiquement des nœuds à un cluster en fonction de la charge de travail.

Si vous optez pour l'allocation manuelle de nœuds, provisionnez suffisamment de nœuds tous les clusters d'une instance afin de s'assurer que chaque cluster peut gérer la réplication, en plus de la charge qu'elle reçoit des applications. Si un cluster ne dispose pas de suffisamment de nœuds, le délai de réplication peut augmenter. Celui-ci peut également rencontrer des problèmes de performances en raison de l'accumulation de mémoire. Les écritures sur d'autres clusters de l'instance peuvent être refusées.

Les exemples de ce document décrivent la création d'une instance, mais vous pouvez également ajouter des clusters à une instance existante.

Isoler les charges de travail d'analyse par lot des autres applications

Lorsque vous utilisez un seul cluster pour exécuter une tâche d'analyse par lot effectuant de nombreuses lectures volumineuses aux côtés d'une application réalisant une combinaison d'opérations de lecture et d'écriture, cela peut ralentir l'exécution de cette dernière. Avec la réplication, vous pouvez utiliser des profils d'application avec un routage à un seul cluster pour acheminer vers des clusters différents le trafic des applications et les tâches d'analyse par lot, afin que ces dernières ne nuisent pas à l'exécution de vos applications.

Pour isoler deux charges de travail, procédez comme suit :

Créer une instance avec deux clusters
Créez deux profils d'application, l'un appelé live-traffic et l'autre batch-analytics.

Si les ID de vos clusters sont cluster-a et cluster-b, le profil d'application live-traffic doit diriger les requêtes vers cluster-a, et le profil d'application batch-analytics doit diriger les requêtes vers cluster-b. Cette configuration fournit une cohérence de type "lecture de vos écritures" pour les applications utilisant le même profil d'application, mais pas pour les applications utilisant des profils d'application différents.

Si nécessaire, vous pouvez activer les transactions à ligne unique dans le profil d'application live-traffic. Il n'est pas nécessaire de les activer dans le profil d'application batch-analytics, celui-ci n'étant supposément destiné qu'aux lectures.
Adoptez le profil d'application live-traffic pour exécuter une charge de travail de trafic en temps réel.
Pendant que la charge de travail de trafic en temps réel est en cours d'exécution, utilisez le profil d'application batch-analytics pour exécuter une charge de travail par lot en lecture seule.

Pour isoler deux petites charges de travail d'une charge de travail plus importante :

Créer une instance avec trois clusters

Ces étapes supposent que vos clusters utilisent les ID cluster-a, cluster-b et cluster-c.
Créez les profils d'application suivants :
- live-traffic-app-a : routage vers un cluster unique, depuis votre application vers cluster-a
- live-traffic-app-b : routage vers un cluster unique, depuis votre application vers cluster-b
- batch-analytics : routage vers un cluster unique, depuis la tâche d'analyse par lot vers cluster-c
Utilisez les profils d'application de trafic en temps réel pour exécuter des charges de travail de trafic en temps réel.
Pendant que les charges de travail de trafic en temps réel sont en cours d'exécution, utilisez le profil d'application batch-analytics pour exécuter une charge de travail par lot en lecture seule.

Créer une haute disponibilité (HA)

Si vous ne disposez que d'un seul cluster dans une instance, la durabilité et la disponibilité de vos données sont limitées à la zone dans laquelle se trouve le cluster. La réplication peut améliorer la durabilité et la disponibilité en stockant des copies séparées de vos données dans plusieurs zones ou régions et en opérant un basculement automatique entre les clusters si nécessaire.

Afin de configurer votre instance pour un cas d'utilisation haute disponibilité (HA), créez un profil d'application qui utilise un routage multicluster ou mettez à jour le profil d'application par défaut pour qu'il utilise un routage multicluster. Cette configuration fournit une cohérence à terme. Vous ne pourrez pas activer les transactions à ligne unique, car celles-ci peuvent entraîner des conflits de données lorsque vous utilisez le routage multicluster.

Les configurations permettant d'améliorer la disponibilité sont les suivantes :

Clusters dans trois régions différentes ou plus (recommandé configuration). La configuration recommandée pour la haute disponibilité est une instance comportant N+2 clusters se trouvant chacun dans une région différente. Par exemple, si le le nombre minimal de clusters nécessaires pour diffuser vos données est de 2, vous avez besoin d'une instance avec quatre clusters pour assurer la haute disponibilité. Cette configuration assure un temps d'activité, même dans les rares cas où deux régions deviennent indisponibles. Nous vous recommandons de répartir les clusters sur plusieurs continents.

Exemple de configuration :
- cluster-a dans la zone us-central1-a en Iowa
- cluster-b dans la zone europe-west1-d en Belgique
- cluster-c dans la zone asia-east1-b à Taïwan
Deux clusters dans la même région, mais dans des zones différentes. Cette option offre une haute disponibilité dans la disponibilité de la région, la capacité à basculer sans générer de coûts de réplication entre régions, et aucune latence supplémentaire lors du basculement. Dans une instance Bigtable répliquée, vos données sont disponibles tant que l'une des zones vers lesquelles elle est répliquée est disponible.

Exemple de configuration :
- cluster-a dans la zone australia-southeast1-a à Sydney
- cluster-b dans la zone australia-southeast1-b à Sydney
Deux clusters dans différentes régions. Cette configuration multirégionale offre une haute disponibilité comme la configuration multizone précédente, mais vos données sont ici disponibles même si vous ne pouvez pas vous connecter à l'une des régions.

La réplication d'écritures entre régions vous est facturée.

Exemple de configuration :
- cluster-a dans la zone asia-northeast1-c à Tokyo
- cluster-b dans la zone asia-east2-b à Hong Kong
Deux clusters dans la région A et un troisième dans la région B. Avec cette option, vos données restent disponibles même si vous ne pouvez pas vous connecter à l'une des régions, et la région A bénéficie de capacité supplémentaire.

La réplication d'écritures entre régions vous est facturée. Si vous écrivez dans la région A, vous êtes facturé une fois, car vous n'avez qu'un seul cluster dans la région B. Si vous écrivez dans la région B, vous êtes facturé deux fois, car vous avez deux clusters dans la région A.

Exemple de configuration :
- cluster-a dans la zone europe-west1-b en Belgique
- cluster-b dans la zone europe-west1-d en Belgique
- cluster-c dans la zone europe-north1-c en Finlande

Fournir une sauvegarde en quasi-temps réel

Dans certains cas, vous devrez toujours rediriger les requêtes vers un seul cluster (par exemple, si vous ne pouvez pas vous permettre de lire des données obsolètes). Cependant, vous pouvez tout de même utiliser la réplication pour traiter les requêtes avec un seul cluster et en utiliser un autre pour effectuer une sauvegarde en quasi-temps réel. Si le cluster actif devient indisponible, vous pouvez basculer manuellement vers le cluster de secours pour réduire le temps d'arrêt.

Afin de configurer votre instance pour ce cas d'utilisation, créez un profil d'application qui utilise un routage à cluster unique ou mettez à jour le profil d'application par défaut de sorte qu'il utilise un routage à cluster unique. Le cluster spécifié dans le profil d'application traite les requêtes entrantes. L'autre agit en tant que cluster de secours au cas où un basculement est nécessaire. Cette configuration est parfois appelée configuration active/passive et fournit à la fois une cohérence forte et une cohérence de type "lecture de vos écritures". Si nécessaire, vous pouvez activer les transactions à ligne unique dans le profil d'application.

Pour implémenter cette configuration :

Utilisez un profil d'application qui utilise un routage à cluster unique pour exécuter une charge de travail.
Utilisez Google Cloud Console pour surveiller les clusters de l'instance et vérifier qu'un seul cluster gère les requêtes entrantes.

L'autre cluster utilise toujours les ressources de processeur pour effectuer la réplication et d'autres tâches de maintenance.
Mettez à jour le profil d'application afin qu'il pointe vers le deuxième cluster de l'instance.

Vous recevez un avertissement concernant la perte de cohérence de type "lecture de vos écritures", ce qui signifie également que vous perdez la cohérence forte.

Si vous avez activé les transactions à ligne unique, vous recevez également un avertissement concernant le risque de perte de données. Vous perdez des données si vous envoyez écritures en conflit lors du basculement.
Continuez à surveiller l'instance. Vous devez constater que le deuxième cluster traite les requêtes entrantes.

Maintenir une haute disponibilité et une résilience régionale

Imaginons que vous avez des clients concentrés dans deux régions d'un même continent. Vous voulez diffuser chaque concentration de clients avec des clusters Bigtable qui soient aussi proches que possible de ces clients. Vous souhaitez que vos données bénéficient d'une disponibilité élevée dans chaque région, et vous voudrez aussi peut-être une option de basculement au cas où l'un ou plusieurs de vos clusters ne soient pas disponibles.

Pour ce cas d'utilisation, vous pouvez créer une instance avec deux clusters dans la région A et deux clusters dans la région B. Cette configuration offre une haute disponibilité, même si vous ne pouvez pas vous connecter à une région Google Cloud. Elle offre également une résilience régionale. En effet, même si une zone n'est plus disponible, l'autre cluster de la région de cette zone le reste.

Vous pouvez choisir d'utiliser un routage multicluster ou un routage à cluster unique pour ce cas d'utilisation, en fonction des besoins de votre entreprise.

Pour configurer l'instance pour ce cas d'utilisation :

Créer une instance Bigtable avec quatre clusters: deux dans la région A et deux dans la région B. Les clusters d'une même région doivent se trouver dans des zones différentes.

Exemple de configuration :
- cluster-a dans la zone asia-south1-a à Mumbai
- cluster-b dans la zone asia-south1-c à Mumbai
- cluster-c dans la zone asia-northeast1-a à Tokyo
- cluster-d dans la zone asia-northeast1-b à Tokyo
Placez un serveur d'applications à proximité de chaque région.

Vous pouvez choisir d'utiliser un routage multicluster ou un routage à cluster unique pour ce cas d'utilisation, en fonction des besoins de votre entreprise. Si vous utilisez un routage multicluster, Bigtable gère automatiquement les basculements. Si vous utilisez le routage à cluster unique, il vous appartient de décider à quel moment basculer vers un autre cluster.

Option de routage à cluster unique

Vous pouvez utiliser le routage à cluster unique pour ce cas d'utilisation si vous ne souhaitez pas que votre cluster Bigtable bascule automatiquement lorsqu'une zone ou une région devient indisponible. Cette option est idéale si vous souhaitez gérer les coûts et la latence que vous pourriez rencontrer si Bigtable commençait à acheminer le trafic vers et depuis une région distante. Elle est idéale aussi si vous préférez que les décisions de basculement soient de votre propre initiative, ou basées sur des règles métier.

Pour mettre en œuvre cette configuration, créez au moins un profil d'application qui utilise un routage à cluster unique pour chaque application qui envoie des requêtes à l'instance. Vous pouvez acheminer les profils d'application vers n'importe quel cluster de l'instance Bigtable. Par exemple, si vous exécutez trois applications à Mumbai et six à Tokyo, vous pouvez configurer un profil d'application pour qu'une application de Mumbai achemine les requêtes vers asia-south1-a et les deux autres vers asia-south1-c. Pour les applications de Tokyo, vous pouvez configurer trois profils d'application acheminant les requêtes vers asia-northeast1-a, et trois qui les acheminent vers asia-northeast1-b.

Avec cette configuration, si un ou plusieurs clusters deviennent indisponibles, vous pouvez effectuer un basculement manuel ou choisir de laisser vos données temporairement indisponibles dans cette zone jusqu'à ce que la zone soit à nouveau disponible.

Option de routage multicluster

Si vous implémentez ce cas d'utilisation et que vous souhaitez que Bigtable bascule automatiquement vers une région si votre application ne peut pas atteindre l'autre, utilisez le routage multicluster.

Pour activer cette configuration, créez un profil d'application qui utilise un routage multicluster pour chaque application ou mettez à jour le profil d'application par défaut de sorte qu'il utilise le routage multicluster.

Cette configuration fournit une cohérence à terme. Si une région devient indisponible, les requêtes Bigtable sont automatiquement envoyées à l'autre région. Lorsque cela se produit, le trafic réseau vers l'autre région vous est facturé et l'application risque de subir une latence plus importante en raison de la distance plus grande.

Stocker des données à proximité des utilisateurs

Si vous avez des utilisateurs dans le monde entier, vous pouvez réduire la latence en exécutant votre application à proximité de vos utilisateurs et en plaçant vos données aussi proches que possible de votre application. Avec Bigtable, vous pouvez créer une instance comportant des clusters dans plusieurs régions Google Cloud, et vos données sont automatiquement répliquées dans chaque région.

Pour ce cas d'utilisation, utilisez les profils d'application avec routage à cluster unique. Le routage multicluster n'est pas souhaitable dans ce cas d'utilisation en raison de la distance entre les clusters. Si un cluster devient indisponible et que son profil d'application multicluster redirige automatiquement le trafic sur une grande distance, votre application risque de subir une latence de niveau inacceptable et d'engendrer des coûts réseau supplémentaires inattendus.