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

Exemples de paramètres de réplication

Cette page décrit certains cas d'utilisation courants permettant d'activer la réplication Bigtable, puis présente les paramètres que vous pouvez utiliser pour ces cas d'utilisation.

Isoler les charges de travail d'analyse par lot des autres applications
Générer 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 définir les paramètres à utiliser si votre scénario n'est pas répertorié ici.

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.

Quel que soit votre cas d'utilisation, provisionnez toujours suffisamment de nœuds dans chaque cluster d'une instance pour vous assurer que chaque cluster peut gérer la réplication en plus de la charge reçue 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.

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éez une instance avec deux clusters ou ajoutez un second cluster à une instance existante.

Suivez les recommandations standards d'utilisation du processeur pour cette configuration.
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.
Surveillez l'utilisation du processeur pour les clusters de l'instance et ajoutez des nœuds aux clusters si nécessaire.
Surveillez la latence côté client à l'aide d'un outil de votre choix. Si vous utilisez le client HBase pour Java, vous pouvez surveiller la latence avec ses métriques côté client.

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

Créez une instance à trois clusters ou ajoutez des clusters à une instance existante jusqu'à ce qu'elle en comporte trois.

Suivez les recommandations standards d'utilisation du processeur pour cette configuration.

Ces étapes supposent que vos clusters utilisent les ID cluster-a, cluster-b et cluster-c.

Utilisez le même nombre de nœuds dans cluster-a et cluster-b s'ils servent la même application. Utilisez un plus grand nombre de nœuds dans cluster-c pour pouvoir supporter la charge de travail plus importante.
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.
Surveillez l'utilisation du processeur pour les clusters de l'instance et ajoutez des nœuds aux clusters si nécessaire.
Surveillez la latence côté client à l'aide d'un outil de votre choix. Si vous utilisez le client HBase pour Java, vous pouvez surveiller la latence avec ses métriques côté client.

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.

Pour en savoir plus sur la façon dont Bigtable aide à atteindre la haute disponibilité, consultez la page Créer une présence mondiale des données avec Bigtable .

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

Clusters dans au moins trois régions (configuration recommandée). 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 nombre minimal de clusters que vous devez diffuser pour vos données est de 2, vous avez besoin d'une instance à quatre clusters pour gérer 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
Pour cette configuration, provisionnez suffisamment de nœuds pour maintenir une cible d'utilisation du processeur de 23 % pour une instance à trois clusters et à trois régions, et de 35 % pour l'utilisation du processeur pour une instance à quatre clusters et quatre régions. Ainsi, même si deux régions sont indisponibles, le ou les clusters restants peuvent diffuser tout le trafic.
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
Suivez les recommandations standards d'utilisation du processeur pour cette configuration.
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
Suivez les recommandations standards d'utilisation du processeur pour cette configuration.
Deux clusters dans la région A et un troisième dans la région B. Avec cette option, vos données sont disponibles même si vous ne pouvez pas vous connecter à l'une des régions. De plus, elle fournit de la capacité supplémentaire dans la région A.

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
Commencez par un objectif d'utilisation du processeur de 35 % dans la région à deux clusters, et de 70 % dans l'autre région. Surveillez les clusters de l'instance et ajustez le nombre de nœuds selon vos besoins afin que chaque cluster dispose d'assez de ressources pour gérer un basculement.

Vous pouvez simuler un basculement pour ce cas d'utilisation afin de tester votre application :

Utilisez un profil d'application qui utilise un routage multicluster pour exécuter une charge de travail de test.
Utilisez Google Cloud Console pour surveiller les clusters de l'instance et vérifier que ceux-ci traitent les requêtes entrantes.
Supprimez l'un des clusters pour simuler une panne.

Cette modification supprime également la copie des données stockée avec le cluster.
Continuez à surveiller les taux de latence et d'erreur. Si les clusters restants disposent d'assez de ressources de processeur, ils devraient pouvoir suivre le rythme des requêtes entrantes.
Ajoutez un cluster à l'instance et continuez à la surveiller. Les données doivent commencer à être répliquées sur le nouveau cluster.

Fournir une solution de secours 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.

Suivez les recommandations standards d'utilisation du processeur pour cette configuration.

Pour implémenter cette configuration :

Utilisez le 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 des écritures en conflit pendant le 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 à 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éez 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.

Suivez les recommandations standards d'utilisation du processeur pour cette configuration.

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.

Lors de la configuration initiale de l'instance, ne dépassez pas 35 % d'utilisation du processeur pour chaque cluster. Cet objectif garantit que chaque cluster peut gérer le trafic qui serait normalement traité par l'autre cluster de sa région en cas de basculement. Vous devrez peut-être ajuster cet objectif en fonction du trafic et de vos habitudes d'utilisation.

Vous pouvez simuler un basculement pour ce cas d'utilisation afin de tester votre application :

Exécutez une charge de travail de test.
Utilisez la console Google Cloud pour surveiller les clusters de l'instance et vérifier que les quatre clusters traitent les requêtes entrantes.
Supprimez l'un des clusters de la région A pour simuler un problème de connexion à une zone.

Cette modification supprime également la copie des données qui est stockée avec le cluster.
Continuez à surveiller les taux de latence et d'erreur pour les clusters restants.

Si les clusters disposent d'assez de ressources de processeur, ils devraient pouvoir suivre le rythme des requêtes entrantes.
Ajoutez un cluster à l'instance de la région A et continuez à surveiller l'instance.

La réplication des données sur le nouveau cluster devrait commencer.
Supprimez les deux clusters de la région A pour simuler un problème de connexion à une région.

Cette modification supprime les copies de vos données qui se trouvaient dans ces clusters.
Continuez à surveiller les taux de latence et d'erreur pour les clusters restants.

Si les clusters disposent d'assez de ressources de processeur, ils doivent pouvoir suivre le rythme des requêtes entrantes qui étaient traitées par l'autre région. Si les clusters ne disposent pas d'assez de ressources, vous devrez peut-être ajuster le nombre de nœuds.

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.