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 àa 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 des clients externes sont traitées par un seul équilibreur de charge HTTP(S) qui dispose 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 vous attendez à ce que le trafic provenant de certains pays soit dirigé 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 au Japon est acheminé via l'équilibreur de charge vers le backend checkout dans la région asia-east1.
  • Le trafic vers une instance de base de données provient d'un backend dans 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 la région asia-east1.
  • Le trafic interrégional est limité à la réplication de la base de données. Par exemple, le trafic entre us-central1 et europe-west1 ne circule qu'entre des instances de base de données dans 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 maintenez le pointeur sur chaque région commerciale pour mettre en évidence la communication avec cette région.

    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 voyez qu'environ 10 Mbit/s sont acheminés vers us-central1 et 90 Mbit/s vers europe-west1. Vous savez que la majeure partie du trafic est dirigé comme vous vous y attendez, mais une partie du trafic est acheminée vers us-central1.

    1La figure est fournie à titre indicatif. Ses 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 voyez que le trafic est acheminé 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.

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

  5. Pour confirmer votre conclusion, vous développez la région us-central1 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 à 82 % 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.

    1La figure est fournie à titre indicatif. Ses 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, désélectionnez les entités Clients externes et Équilibreurs de charge dans la liste Entités. Étant donné que vous affichez uniquement le trafic dans votre application, vous n'avez pas besoin de voir les clients externes et le trafic de l'équilibreur de charge externe.

  2. Vous développez la région asia-east1 et vous voyez 5 groupes d'instances. Ils ne sont pas agrégés par réseau, sous-réseau, zone ou segment d'infrastructure, 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 pour le trafic interrégional. Tous les autres groupes d'instances communiquent au sein de la région.

    Vous continuez à développer 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 (db-instance-asia) qui agit comme un serveur de base de données. Elle communique avec d'autres régions pour répliquer les données, ce à quoi vous vous attendiez, donc aucune analyse plus approfondie n'est requise.

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

Étape suivante