Basculements

Lorsqu'un cluster Cloud Bigtable ne répond plus, la réplication permet au trafic entrant de 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 manuels et automatiques dans une instance utilisant la réplication. Pour savoir comment effectuer un basculement, consultez la section Gérer les basculements.

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

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, Cloud Bigtable gère les basculements de manière automatique. Lorsque le cluster le plus proche est incapable de gérer une requête, Cloud 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 Cloud Bigtable achemine une requête vers un cluster et que ce dernier est excessivement long à répondre ou renvoie une erreur transitoire, Cloud Bigtable acheminera 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, Cloud 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, Cloud Bigtable redirige la requête vers le cluster suivant le plus proche.

Si vous utilisez la réplication avec routage multicluster afin d'atteindre une haute disponibilité 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 Cloud Console : accédez à la liste des instances, cliquez sur le nom de l'instance souhaitée, puis sur Surveillance.

Étapes suivantes