Anwendungsfall: Netzwerkleistung prüfen

Angenommen, Sie sind Administrator eines Netzwerks, das mehrere Anwendungen mit Load-Balancing umfasst. Sie wurden gebeten, die Netzwerkkonfigurationen für diese Anwendungen zu prüfen, um sicherzustellen, dass die Konfigurationen dem erwarteten Status des Netzwerks entsprechen. Mit dieser Prüfung können Sie dafür sorgen, dass die Latenz der Kunden zu Ihren Anwendungen so gering wie möglich gehalten wird.

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

Topologieübersicht

Die Bereitstellung erstreckt sich über drei Google Cloud-Regionen (us-central1, europe-west1 und asia-east1). Alle externen Clientanfragen werden von einem einzigen externen Application Load Balancer verarbeitet, der in jeder der drei Regionen mehrere Back-Ends hat. Clientanfragen aus einer von drei Geschäftsregionen (Amerika, EMEA und APAC) werden von Anwendungsinstanzen in der nächstgelegenen Google Cloud-Region verarbeitet.

Das folgende Diagramm zeigt die allgemeine Hierarchie für die Bereitstellung:

Beispieltopologie für die Netzwerktopologie (zum Vergrößern klicken)

Ressourcen und Trafficpfade

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

• 1 HTTPS-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

Es wird davon ausgegangen, dass Traffic aus bestimmten Ländern zu den folgenden Standorten weitergeleitet wird:

• Traffic aus Ländern in der Geschäftsregion Americas wird an Back-Ends in der Region us-central1 weitergeleitet. Traffic von einem externen Client in Kanada wird beispielsweise über den Load-Balancer zum Back-End checkout in der Region us-central1 weitergeleitet.
• Traffic aus Ländern in der Geschäftsregion EMEA wird an Back-Ends in der Region europe-west1 weitergeleitet. Traffic von einem externen Client in Polen wird beispielsweise über den Load-Balancer zum Back-End checkout in der Region europe-west1 weitergeleitet.
• Traffic aus Ländern in der Geschäftsregion APAC wird an Back-Ends in der Region asia-east1 weitergeleitet. Traffic von einem externen Client in Japan wird beispielsweise über den Load-Balancer zum Back-End checkout in der Region asia-east1 weitergeleitet.
• Der Traffic zu einer Datenbankinstanz kommt von einem Back-End in derselben Region. Beispielsweise senden die Back-Ends in asia-east1 Daten nur an die Datenbankinstanz in asia-east1.
• Der regionenübergreifende 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, weitergeleitet wird. Mithilfe von Netzwerktopologie stellen Sie fest, dass eines der Back-Ends überlastet ist.

1. Sie möchten prüfen, ob der externe Traffic, der über den Load-Balancer weitergeleitet wird, schließlich in die richtige Google Cloud-Region gelangt. 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 Netzwerktopologie nur die Verbindungen an, die sich auf den Load-Balancer beziehen, wie im folgenden Beispiel gezeigt.

   

   Filter für einen Load-Balancer (zum Vergrößern klicken)

2. Halten Sie den Mauszeiger jeweils über einen der Geschäftsbereiche, um die Kommunikation zu dieser Region hervorzuheben.

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

3. Klicken Sie anschließend auf EMEA, um den Durchsatz zwischen EMEA und den Google Cloud-Regionen zu prüfen. Netzwerktopologie blendet Bandbreitenwerte zu jeder Verbindung ein. Sie sehen, dass etwa 0,58 Byte pro Sekunde zu us-central1 und 29,9 Kilobyte pro Sekunde an europe-west1 gehen. Sie wissen, dass der Großteil des Traffics wie erwartet weitergeleitet wird, aber ein Teil des Traffics fließt an us-central1.

   

   Eingeblendete Bandbreitenwerte¹ (zum Vergrößern klicken)

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

4. Wenn Sie den Vorgang weiter untersuchen möchten, maximieren Sie us-central1, um zu sehen, wohin der Traffic geht. Da es in dieser Region nur ein Netzwerk mit einem einzelnen Subnetz gibt, zeigt Netzwerktopologie diese Hierarchieebenen nicht an und fährt mit den Instanzgruppen fort.

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

   

   Traffic-Pfad¹ (zum Vergrößern klicken)

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

5. Zur Bestätigung Ihrer Schlussfolgerung erweitern Sie die Region europe-west1, bis Sie die Instanz erreichen, die dem Back-End-Dienst desselben Load-Balancers zugeordnet ist. Netzwerktopologie zeigt Zeitachsendiagramme im Bereich "Details" für die Instanz an.

   Im Diagramm sehen Sie, dass die CPU-Auslastungsrate für die Instanz bei 81% liegt. Der Schwellenwert für dieses Beispiel ist 80 %, die Instanz ist also zu stark ausgelastet. Zum Beheben dieses Problems skalieren Sie die Instanzgruppe entsprechend hoch, damit der Traffic wieder den idealen Weg nimmt.

   

   Zeitreihendiagramm für eine Instanz¹ (zum Vergrößern klicken)

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

Interregionaler Traffic

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

1. Wenn Sie sich auf den internen Traffic konzentrieren möchten, klicken Sie in der Liste Topologiekonfiguration nur die Kästchen Instanzen und Cloud NAT-Gateways an. Da Sie sich nur den Traffic in Ihrer Anwendung ansehen, müssen die externen Clients und der Traffic der externen Load-Balancer nicht angezeigt werden.

   

   Nur internen Traffic anzeigen (zum Vergrößern klicken)

2. Maximieren Sie die Region asia-east1 und Sie sehen fünf Instanzgruppen. Diese werden nicht nach Netzwerk, Subnetz oder Zone zusammengefasst, da sie sich im selben Netzwerk, Subnetz usw. befinden:

   Wie Sie sehen, enthält nur eine Instanzgruppe (db-group-asia) einen Pfad für den interregionalen Traffic. Alle anderen Instanzgruppen kommunizieren innerhalb der Region.

   Maximieren Sie 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 dient. Sie kommuniziert mit anderen Regionen, um Daten zu replizieren. Dies ist genau, was Sie erwartet haben, sodass keine weiteren Untersuchungen erforderlich sind.

   

   Interregionaler Traffic¹ (zum Vergrößern klicken)

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

Nächste Schritte

• Netzwerkkonfiguration mit Netzwerktopologie überwachen
• Anwendungsfall: Netzwerkkonnektivität beheben
• Fehlerbehebung bei Netzwerktopologie