Basculements

Lorsqu'un cluster Bigtable ne répond plus, la réplication rend possible la communication le trafic doit basculer vers un autre cluster de la même instance. Le basculement peut s'effectuer manuellement ou automatiquement, en fonction du profil d'application utilisé et de sa configuration.

Cette page décrit le fonctionnement des basculements manuel et automatique dans une instance utilisant la réplication. Pour savoir comment effectuer un basculement, consultez la section Gérer ou des basculements d'environnement.

Avant de lire cette page, vous devez avoir pris connaissance de la présentation de la réplication Bigtable. Vous devez également connaître les options de routage disponibles.

Basculements manuels

Si un profil d'application utilise le routage à cluster unique pour diriger toutes les requêtes vers un seul cluster, il vous appartient de décider à quel moment basculer vers un autre cluster.

Voici quelques signaux indiquant qu'il est temps de basculer vers un autre cluster :

  • Le cluster commence à renvoyer un grand nombre d'erreurs système transitoires.
  • Un grand nombre de demandes commencent à expirer.
  • La latence moyenne de réponse augmente à un niveau inacceptable.

Ces signaux peuvent apparaître pour différentes raisons. Il n'est donc pas garanti que le basculement vers un autre cluster permette de résoudre le problème sous-jacent. Surveillez votre instance avant et après le basculement pour vérifier que les métriques se sont améliorées.

Pour plus d'informations sur la procédure de basculement manuel, consultez la section Effectuer un basculement manuel.

Basculements automatiques

Si un profil d'application utilise un routage multicluster, Bigtable gère les basculements de manière automatique. Lorsque le cluster le plus proche est incapable de gérer une requête, Bigtable achemine le trafic vers le cluster disponible le plus proche.

Les basculements automatiques peuvent se produire même si un cluster est indisponible sur une très courte période. Par exemple, si Bigtable dirige une requête vers un cluster et que ce dernier est excessivement long à répondre ou renvoie une erreur transitoire, Bigtable dirigera généralement cette demande vers l'autre cluster.

Si vous utilisez le routage multicluster et que vous envoyez une requête avec un délai, Bigtable bascule automatiquement en cas de besoin pour respecter ce délai. Si le délai de la requête approche, mais que le cluster initial n'a pas envoyé de réponse, Bigtable redirige la requête vers le cluster suivant le plus proche.

Bigtable utilise un algorithme interne la dernière écriture prévaut pour gérer les conflits de données pouvant survenir suite à un basculement avant la fin de la réplication. Pour en savoir plus, consultez la section Résolution des conflits.

Si vous utilisez la réplication avec routage multicluster afin d'atteindre une haute disponibilité (HA) pour votre application, vous devez localiser vos serveurs clients ou vos VM au sein de plusieurs régions Google Cloud, ou à proximité de celles-ci. Cette recommandation s'applique même si votre serveur d'applications n'est pas hébergé par Google Cloud, car vos données entrent dans le réseau Google Cloud via la région Google Cloud la plus proche de votre serveur d'applications. Comme pour toute requête, un basculement se produit plus rapidement sur des distances plus courtes.

De nombreux basculements automatiques sont si brefs que vous ne les remarquerez pas. Pour afficher le nombre de requêtes qui ont été reroutées automatiquement sur une période donnée, vous pouvez consulter le graphique des Basculements automatiques dans la console Google Cloud : accédez à la liste des instances, cliquez sur le nom de l'instance souhaitée, puis sur Surveillance.

Étape suivante