Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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 umfasst drei Google Cloud Regionen (us-central1,
europe-west1 und asia-east1). Alle externen Clientanfragen werden von einem einzelnen 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ächstgelegenenGoogle Cloud -Region verarbeitet.
Das folgende Diagramm zeigt die allgemeine Hierarchie für die Bereitstellung:
Beispieltopologie für die Netzwerktopologie (zum Vergrößern anklicken)
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. Der 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. Der 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. 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 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.
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 anklicken)
Halten Sie den Mauszeiger jeweils über einen der Geschäftsbereiche, um die Kommunikation zu dieser Region hervorzuheben.
Wenn Sie den Mauszeiger auf 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.
Klicken Sie anschließend auf EMEA, um den Durchsatz zwischen EMEA und denGoogle Cloud -Regionen zu prüfen. Netzwerktopologie blendet Bandbreitenwerte zu jeder Verbindung ein. Sie sehen, dass etwa 0,58 Byte pro Sekunde an us-central1 und 29,9 Kilobyte pro Sekunde an europe-west1 gesendet werden. Sie wissen, dass der Großteil des Traffics wie erwartet weitergeleitet wird, aber ein Teil geht auch an us-central1.
1Die Abbildung dient als Referenz. Die Daten spiegeln nicht den Anwendungsfall wider.
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 geht, 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.
Trafficpfad1 (zum Vergrößern anklicken)
1Die Abbildung dient als Referenz. Die Daten spiegeln nicht den Anwendungsfall wider.
Maximieren Sie die Region europe-west1, bis Sie die Instanz erreicht haben, die dem Back-End-Dienst desselben Load Balancers zugeordnet ist. So lässt sich Ihre Schlussfolgerung bestätigen. 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 Instanz1 (zum Vergrößern anklicken)
1Die 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.
Wenn Sie sich auf den internen Traffic konzentrieren möchten, aktivieren Sie in der Liste Topologiekonfiguration nur die Kästchen für Instanzen und Cloud NAT-Gateways. 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 anklicken)
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.
̦
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[],[],null,["# Use case: Audit network performance\n===================================\n\nAssume that you're a network administrator who supports a network that includes\nseveral load-balanced applications. You've been asked to audit the network\nconfigurations that support those applications to ensure that the configurations\nare consistent with the expected state of your network. By doing this audit, you\ncan ensure that customers are getting the lowest possible latency to your\napplications.\n\nThe following use case demonstrates how Network Topology can help you\ncheck your existing configurations. For example, you can check that all client\nrequests are being served by application instances from the Google Cloud\nregion that's closest to the client. You can also ensure that cross-region\ntraffic is low because that traffic comes from databases that replicate data\nglobally.\n\nTopology overview\n-----------------\n\nThe deployment spans three Google Cloud regions (`us-central1`,\n`europe-west1`, and `asia-east1`). All external client requests are served by a\nsingle external Application Load Balancer that has multiple backends in each of the three\nregions. Client requests that come from one of three business regions (Americas,\nEMEA, and APAC) are served by application instances in the closest\nGoogle Cloud region.\n\nThe following graph shows the top-level hierarchy for the deployment.\n[](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-topology.png) Network Topology example topology (click to enlarge)\n\n### Resources and traffic paths\n\nIn this example, the project contains the following Google Cloud\nresources:\n\n- 1 HTTPS load balancer\n\n- 4 backend services: `browse`, `shopping_cart`, `checkout`, and `feeds`\n\n- 12 instance groups (which are the load balancer's backends)\n\n There is one instance group for each backend service in each of the three\n regions.\n- 3 database instances, one in each region\n\nYou expect that traffic from certain countries goes to the following\nlocations:\n\n- Traffic from countries in the `Americas` business region goes to backends in the `us-central1` region. For example, traffic from an external client in Canada travels through the load balancer to the `checkout` backend in the `us-central1` region.\n- Traffic from countries in the `EMEA` business region goes to backends in the `europe-west1` region. For example, traffic from an external client in Poland travels through the load balancer to the `checkout` backend in the `europe-west1` region.\n- Traffic from countries in the `APAC` business region goes to backends in the `asia-east1` region. For example, traffic from an external client in Japan travels through the load balancer to the `checkout` backend in the `asia-east1` region.\n- Traffic to a database instance comes from a backend in the same region. For example, the backends in `asia-east1` send data only to the database instance in `asia-east1`.\n- Cross-region traffic is limited to database replication. For example, traffic between `us-central1` and `europe-west1` travels only between database instances in those regions.\n\nUnexpected traffic flow\n-----------------------\n\nIn this scenario, you discover that traffic from the `EMEA` business region\nis now going to two different Google Cloud regions, `us-central1` and\n`europe-west1`. By using Network Topology, you discover that one of\nthe backends is overutilized.\n\n1. You want to check that external traffic that is going through the load\n balancer eventually goes to the correct Google Cloud region. You filter\n the graph to show only the traffic for your external load balancer\n `shopping-site-lb`.\n\n After you apply the filter, Network Topology shows only the\n connections related to the load balancer, as shown in the following example.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-filter.png) Filter for a load balancer (click to enlarge)\n2. You hold the pointer over each business region to highlight the communication\n to that region.\n\n When you hold the pointer over **Americas** and **APAC** , you see traffic\n going to the nearest Google Cloud region: `us-central1` and `asia-\n east1` respectively. However, when you hold the pointer over **EMEA** , you\n see traffic going to `us-central1` and `europe-west1`. Ideally, to reduce\n latency, all traffic from EMEA should go to `europe-west1`.\n3. Next, you click **EMEA** to study the throughput between it and the\n Google Cloud regions. Network Topology overlays bandwidth\n values on each connection. You see that about 0.58 bytes per second is\n going to `us-central1` and 29.9 kilobytes per second is going\n to `europe-west1`. You know that most of the traffic is being directed as\n you would expect, but some traffic is flowing to `us-central1`.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-bandwidth.png) Overlaid bandwidth values^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n4. To investigate further, you expand `us-central1` to view where traffic is\n going. Because there's only one network with a single subnet in that region,\n Network Topology doesn't show those levels of the hierarchy and\n skips to the instance groups.\n\n You see that traffic is going to an instance group that's associated with the load\n balancer's backend service. Because it's a relatively small amount of traffic\n going to `europe-west1`, it's possible that resources in `europe-west1` are\n overutilized and causing traffic to overflow to `us-central1`.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-traffic.png) Traffic path^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the use\n case.\n5. To confirm your conclusion, you expand the `europe-west1` region until you\n reach the instance that is associated with the same load balancer's backend\n service. Network Topology shows time-series charts in the details\n pane for the instance.\n\n In the chart, you notice that the CPU utilization rate is at 81% for the\n instance. The threshold for this example is 80%, indicating that the instance\n is oversubscribed. You resolve this issue by scaling up the instance group so\n that traffic returns to the ideal flow.\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-chart.png) Time-series chart for an instance^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\nInter-region traffic\n--------------------\n\nIn the following section, you check that internal traffic between regions\nis limited to only database instance traffic.\n\n1. To focus on internal traffic, in the **Topology configuration** list, you select\n only the **Instances** and **Cloud NAT gateways** checkboxes. Because you are only\n viewing traffic within your application, you don't need to see external clients\n and external load balancer traffic.\n\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-internalonly.png) Showing internal-only traffic (click to enlarge)\n2. You expand the `asia-east1` region, and you see five instance groups. They are\n not aggregated by network, subnet, or zone because\n they are all in the same network, subnet, and so on.\n\n You notice that only one instance group (`db-group-asia`) contains a path\n for inter-region traffic. All other instance groups are communicating within\n the region.\n\n You continue to expand the `db-group-asia` group until you reach the base\n entity. In this scenario, the base entity is a virtual machine (VM) instance\n (`db-instance-asia`) that acts as a database server. It's communicating with\n other regions to replicate data, which is what you expected, so no further\n investigations are required.\n ̦\n [](/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-dbtraffic.png) Inter-region traffic^1^ (click to enlarge) \n\n ^1^The figure is for reference. Its data doesn't reflect the\n use case.\n\n \u003cbr /\u003e\n\nWhat's next\n-----------\n\n- [Monitor your networking configuration with Network Topology](/network-intelligence-center/docs/network-topology/how-to/audit-troubleshoot-networking-issues)\n- [Use case: Troubleshoot network connectivity](/network-intelligence-center/docs/network-topology/concepts/troubleshooting-network-connectivity)\n- [Troubleshoot Network Topology](/network-intelligence-center/docs/network-topology/support/troubleshooting)"]]
