Netzwerkleistung prüfen

Angenommen, Sie sind ein Netzwerkadministrator, der ein Netzwerk unterstützt, das mehrere Anwendungen mit Load-Balancer enthält. Sie wurden aufgefordert, die Netzwerkkonfigurationen zu überprüfen, die diese Anwendungen unterstützen, um sicherzustellen, dass die Konfigurationen mit dem erwarteten Zustand Ihres Netzwerks übereinstimmen. Durch diese Prüfung können Sie sicherstellen, dass Kunden die geringstmögliche Latenz für Ihre Anwendungen erhalten.

Der folgende Anwendungsfall zeigt, wie Sie mit der Netzwerktopologie Ihre vorhandenen Konfigurationen überprüfen können. Sie können beispielsweise überprüfen, ob alle Clientanfragen von Anwendungsinstanzen aus der Google Cloud-Region bearbeitet werden, die dem Client am nächsten liegt. Sie können auch sicherstellen, dass der regionale Traffic gering ist, da dieser Traffic aus Datenbanken stammt, die Daten global replizieren.

Topologieübersicht

Die Bereitstellung umfasst drei Google Cloud-Regionen (us-central1, europe-west1 und asia-east1). Alle externen Clientanfragen werden von einem einzelnen HTTP(S)-Load-Balancer bedient, der in jeder der drei Regionen mehrere Back-Ends hat. Kundenanfragen aus einer von drei Geschäftsregionen (Amerika, EMEA und APAC) werden von Anwendungsinstanzen in der nächstgelegenen Google Cloud-Region bearbeitet.

Das folgende Diagramm zeigt die Hierarchie der obersten Ebene für die Bereitstellung:

Ressourcen und Traffic-Pfade

In diesem Beispiel enthält das Projekt die folgenden Google Cloud-Ressourcen:

  • 1 HTTP(S)-Load-Balancer
  • 4 Back-End-Dienste: browse, shopping_cart, checkout und feeds.
  • 12 Instanzgruppen (die Back-Ends des Load-Balancers). Für jeden Back-End-Dienst gibt es in jeder der drei Regionen eine Instanzgruppe.
  • 3 Datenbankinstanzen, eine in jeder Region.

Sie erwarten, dass Traffic aus bestimmten Ländern an folgende Orte geleitet wird:

  • Der Traffic aus Ländern in der Geschäftsregion Americas wird an Back-Ends in der Region us-central1 weitergeleitet. Beispielsweise wird der Traffic von einem externen Client in Kanada über den Load-Balancer zum Back-End checkout in der Region us-central1 geleitet.
  • Der Traffic aus Ländern in der Geschäftsregion EMEA wird an Back-Ends in der Region europe-west1 weitergeleitet. Beispielsweise wird der Traffic von einem externen Client in Polen über den Load-Balancer zum Back-End checkout in der Region europe-west1 geleitet.
  • Der Traffic aus Ländern in der Geschäftsregion APAC wird an Back-Ends in der Region asia-east1 weitergeleitet. Beispielsweise wird der Traffic von einem externen Client in Japan über den Load-Balancer zum Back-End checkout in der Region asia-east1 geleitet.
  • Der Traffic zu einer Datenbankinstanz erfolgt über ein Back-End in derselben Region. Beispielsweise senden die Back-Ends in asia-east1 nur Daten an die Datenbankinstanz in asia-east1.
  • Der regionale Traffic ist auf die Datenbankreplikation beschränkt. Beispielsweise wird der Traffic zwischen us-central1 und europe-west1 nur zwischen Datenbankinstanzen in diesen Regionen übertragen.

Unerwarteter Trafficfluss

In diesem Szenario stellen Sie fest, dass der Traffic aus der Geschäftsregion EMEA jetzt in zwei verschiedene Google Cloud-Regionen us-central1 und europe-west1 geleitet wird. Mithilfe der Netzwerktopologie stellen Sie fest, dass eines der Back-Ends überlastet ist.

  1. Sie möchten überprüfen, ob der externe Traffic, der durch den Load-Balancer geleitet wird, schließlich in die richtige Google Cloud-Region geleitet wird. Sie filtern das Diagramm so, dass nur der Traffic für Ihren externen Load-Balancer shopping-site-lb angezeigt wird.

    Nachdem Sie den Filter angewendet haben, zeigt die Netzwerktopologie nur die Verbindungen an, die sich auf den Load-Balancer beziehen, wie im folgenden Beispiel gezeigt.

  2. Sie halten den Zeiger über jede Geschäftsregion, um die Kommunikation mit dieser Region hervorzuheben.

    Wenn Sie den Zeiger über Americas und APAC halten, wird der Traffic zur nächstgelegenen Google Cloud-Region geleitet: us-central1 bzw. asia-east1. Wenn Sie jedoch den Zeiger über EMEA halten, wird der Traffic zu us-central1 und europe-west1 geleitet. Um die Latenz zu verringern, sollte der gesamte Traffic von EMEA idealerweise auf europe-west1 gehen.

  3. Als Nächstes klicken Sie auf EMEA, um den Durchsatz zwischen EMEA und den Google Cloud-Regionen zu untersuchen. Die Netzwerktopologie überlagert die Bandbreitenwerte jeder Verbindung. Sie sehen, dass ungefähr 10 MBit/s auf us-central1 und 90 MBit/s auf europe-west1 gehen. Sie wissen, dass der größte Teil des Traffics wie erwartet geleitet wird, aber ein Teil des Traffics fließt nach us-central1.

    1 Die Abbildung dient als Referenz. Die Daten spiegeln nicht den Anwendungsfall wider.

  4. Um weitere Untersuchungen durchzuführen, erweitern Sie us-central1, um anzuzeigen, wohin der Traffic fließt. Da es in dieser Region nur ein Netzwerk mit einem einzelnen Subnetz gibt, zeigt die Netzwerktopologie diese Hierarchieebenen nicht an und springt zu den Instanzgruppen.

    Sie sehen, dass der Traffic an eine Instanzgruppe geht, die dem Back-End-Dienst des Load-Balancers zugeordnet ist. Da es sich um eine relativ kleine Menge an Traffic handelt, die zu europe-west1 geht, ist es möglich, dass Ressourcen in europe-west1 überlastet sind und der Traffic zu us-central1 überläuft.

    1 Die Abbildung dient als Referenz. Die Daten spiegeln nicht den Anwendungsfall wider.

  5. Um Ihre Schlussfolgerung zu bestätigen, erweitern Sie den Bereich us-central1, bis Sie die Instanz erreichen, die dem Back-End-Dienst desselben Load-Balancers zugeordnet ist. Die Netzwerktopologie zeigt Zeitreihendiagramme im Detailbereich der Instanz an.

    Im Diagramm stellen Sie fest, dass die CPU-Auslastungsrate für die Instanz bei 82% liegt. Der Schwellenwert für dieses Beispiel beträgt 80%, was darauf hinweist, dass die Instanz überzeichnet ist. Sie beheben dieses Problem, indem Sie die Instanzgruppe so skalieren, dass der Traffic zum idealen Fluss zurückkehrt.

    1 Die Abbildung dient als Referenz. Die Daten spiegeln nicht den Anwendungsfall wider.

Traffic zwischen den Regionen

Im folgenden Abschnitt überprüfen Sie, ob der interne Traffic zwischen Regionen nur auf Datenbankinstanz-Traffic beschränkt ist.

  1. Um sich auf den internen Traffic zu konzentrieren, deaktivieren Sie die Entitäten Externe Clients und Load-Balancers aus der Liste Entitäten. Da Sie nur den Traffic in Ihrer Anwendung anzeigen, müssen Sie keine externen Clients und keinen externen Load-Balancer-Traffic anzeigen.

  2. Sie erweitern die Region asia-east1 und sehen 5 Instanzgruppen. Sie werden nicht nach Netzwerk, Subnetz, Zone oder Infrastruktursegment zusammengefasst, da sie sich alle im selben Netzwerk, Subnetz usw. befinden.

    Sie stellen fest, dass nur eine Instanzgruppe (db-group-asia) einen Pfad für den Traffic zwischen Regionen enthält. Alle anderen Instanzgruppen kommunizieren innerhalb der Region.

    Sie erweitern die Gruppe db-group-asia weiter, bis Sie die Basisentität erreichen. In diesem Szenario ist die Basisentität eine VM-Instanz (db-instance-asia), die als Datenbankserver fungiert. Sie kommuniziert mit anderen Regionen, um Daten zu replizieren, was Sie erwartet haben, sodass keine weiteren Untersuchungen erforderlich sind.

    1 Die Abbildung dient als Referenz. Die Daten spiegeln nicht den Anwendungsfall wider.

Nächste Schritte