Cas d'utilisation : Auditer les performances du réseau

Supposons que vous êtes un administrateur réseau chargé de gérer un réseau comprenant plusieurs applications à équilibrage de charge. Vous devez auditer les configurations réseau qui prennent en charge ces applications pour vous assurer que les configurations sont cohérentes avec l'état attendu de votre réseau. En effectuant cet audit, vous pouvez faire en sorte que les clients obtiennent la latence la plus faible possible pour vos applications.

Le cas d'utilisation suivant montre comment Network Topology peut vous aider à vérifier vos configurations existantes. Par exemple, vous pouvez vérifier que toutes les requêtes client sont traitées par des instances d'application de la région Google Cloud la plus proche du client. Vous pouvez également vous assurer que le trafic interrégional est faible, car il provient de bases de données qui répliquent les données à l'échelle mondiale.

Présentation de la topologie

Le déploiement s'étend sur trois régions Google Cloud (us-central1, europe-west1 et asia-east1). Toutes les requêtes client externes sont diffusées par un seul équilibreur de charge d'application externe doté de plusieurs backends dans chacune des trois régions. Les requêtes des clients provenant de l'une des trois régions commerciales (Amériques, EMEA et APAC) sont traitées par des instances d'application dans la région Google Cloud la plus proche.

Le graphique suivant montre la hiérarchie de premier niveau du déploiement.

Ressources et chemins du trafic

Dans cet exemple, le projet contient les ressources Google Cloud suivantes :

  • 1 équilibreur de charge HTTP(S)

  • 4 services de backend : browse, shopping_cart, checkout et feeds.

  • 12 groupes d'instances (qui sont les backends de l'équilibreur de charge).

    Il existe un groupe d'instances pour chaque service de backend dans chacune des trois régions.

  • 3 instances de base de données, une dans chaque région.

Vous prévoyez que le trafic de certains pays va se diriger vers les emplacements suivants :

  • Le trafic provenant des pays de la région commerciale Americas est acheminé vers les backends de la région us-central1. Par exemple, le trafic provenant d'un client externe au Canada est acheminé via l'équilibreur de charge vers le backend checkout dans la région us-central1.
  • Le trafic provenant des pays de la région commerciale EMEA est acheminé vers les backends de la région europe-west1. Par exemple, le trafic provenant d'un client externe en Pologne est acheminé via l'équilibreur de charge vers le backend checkout dans la région europe-west1.
  • Le trafic provenant des pays de la région commerciale APAC est acheminé vers les backends de la région asia-east1. Par exemple, le trafic provenant d'un client externe situé au Japon transite par l'équilibreur de charge vers le backend checkout de la région asia-east1.
  • Le trafic vers une instance de base de données provient d'un backend de la même région. Par exemple, les backends de asia-east1 n'envoient des données qu'à l'instance de base de données dans asia-east1.
  • Le trafic interrégional est limité à l'instance dupliquée de base de données. Par exemple, le trafic entre us-central1 et europe-west1 ne transite qu'entre les instances de base de données de ces régions.

Flux de trafic inattendu

Dans ce scénario, vous découvrez que le trafic provenant de la région commerciale EMEA est désormais acheminé vers deux régions Google Cloud différentes : us-central1 et europe-west1. En utilisant Network Topology, vous découvrez que l'un des backends est surexploité.

  1. Vous souhaitez vérifier que le trafic externe qui passe par l'équilibreur de charge est acheminé vers la bonne région Google Cloud. Vous filtrez le graphique pour n'afficher que le trafic de votre équilibreur de charge externe shopping-site-lb.

    Après avoir appliqué le filtre, Network Topology n'affiche que les connexions liées à l'équilibreur de charge, comme illustré dans l'exemple suivant.

  2. Vous placez le pointeur sur chaque région commerciale afin de mettre en évidence la communication avec celle-ci.

    Lorsque vous placez le pointeur sur Amériques et APAC, vous voyez le trafic acheminé vers la région Google Cloud la plus proche : us-central1 et asia- east1 respectivement. Cependant, lorsque vous maintenez le pointeur sur EMEA, vous voyez le trafic acheminé vers us-central1 et europe-west1. Idéalement, pour réduire la latence, tout le trafic provenant de la région EMEA doit être acheminé vers europe-west1.

  3. Ensuite, vous cliquez sur EMEA pour étudier le débit entre cette région et les régions Google Cloud. Network Topology superpose les valeurs de bande passante sur chaque connexion. Vous constatez qu'environ 0,58 octet par seconde va à us-central1 et 29,9 kilo-octets par seconde à europe-west1. Vous savez que la majeure partie du trafic est dirigée comme prévu, mais qu'une partie du trafic est dirigée vers us-central1.

    1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.

  4. Pour examiner la situation plus en détail, développez us-central1 pour voir où le trafic est acheminé. Comme il n'y a qu'un seul réseau avec un seul sous-réseau dans cette région, Network Topology n'affiche pas ces niveaux de la hiérarchie et passe aux groupes d'instances.

    Vous constatez que le trafic est dirigé vers un groupe d'instances associé au service de backend de l'équilibreur de charge. Comme il s'agit d'un trafic relativement faible acheminé vers europe-west1, il est possible que les ressources de europe-west1 soient surexploitées, provoquant un débordement du trafic vers us-central1.

    1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.

  5. Pour confirmer votre conclusion, vous développez la région europe-west1 jusqu'à atteindre l'instance associée au même service de backend de l'équilibreur de charge. Network Topology affiche des graphiques de séries temporelles dans le volet Détails de l'instance.

    Dans le graphique, vous remarquez que le taux d'utilisation du processeur est de 81% pour l'instance. Le seuil pour cet exemple est de 80 %, ce qui indique que l'instance est surexploitée. Pour résoudre ce problème, augmentez le groupe d'instances afin que le trafic retourne au flux idéal.

    1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.

Trafic interrégional

Dans la section suivante, vous vérifiez que le trafic interne entre les régions est limité au trafic d'instances de base de données.

  1. Pour vous concentrer sur le trafic interne, dans la liste Configuration de la topologie, vous ne cochez que les cases Instances et Passerelles Cloud NAT. Étant donné que vous ne consultez que le trafic dans votre application, vous n'avez pas besoin de voir les clients ni le trafic de l'équilibreur de charge externes.

  2. Vous développez la région asia-east1 et vous voyez cinq groupes d'instances. Ils ne sont pas agrégés par réseau, sous-réseau ou zone, car ils se trouvent tous dans le même réseau, sous-réseau, etc.

    Vous remarquez qu'un seul groupe d'instances (db-group-asia) contient un chemin d'accès pour le trafic interrégions. Tous les autres groupes d'instances communiquent dans la région.

    Vous développez le groupe db-group-asia jusqu'à atteindre l'entité de base. Dans ce scénario, l'entité de base est une instance de machine virtuelle (VM) (db-instance-asia) faisant office de serveur de base de données. Elle communique avec d'autres régions pour répliquer les données, ce qui est normal, donc aucune autre enquête n'est requise.

    1 La figure est fournie à titre indicatif. Les données ne reflètent pas le cas d'utilisation.

Étapes suivantes