Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Caso d'uso: controlla le prestazioni della rete
Supponiamo che tu sia un amministratore di rete che supporta una rete che include diverse applicazioni bilanciate in base al carico. Ti è stato chiesto di controllare le configurazioni di rete che supportano queste applicazioni per assicurarti che siano coerenti con lo stato previsto della rete. Eseguendo questo controllo, puoi assicurarti che i clienti ricevano la latenza più bassa possibile per le tue
applicazioni.
Il seguente caso d'uso mostra in che modo Network Topology può aiutarti a controllare le configurazioni esistenti. Ad esempio, puoi verificare che tutte le richieste del client vengano gestite da istanze dell'applicazione della Google Cloud
regione più vicina al client. Puoi anche assicurarti che il traffico tra regioni sia ridotto perché proviene da database che replicano i dati a livello globale.
Panoramica della topologia
Il deployment si estende su tre Google Cloud regioni (us-central1,
europe-west1 e asia-east1). Tutte le richieste dei client esterni vengono gestite da un singolo bilanciatore del carico delle applicazioni esterno con più backend in ciascuna delle tre regioni. Le richieste dei client provenienti da una delle tre regioni di attività (America, EMEA e APAC) vengono gestite dalle istanze dell'applicazione nella regioneGoogle Cloud più vicina.
Il seguente grafico mostra la gerarchia di primo livello per il deployment.
Esempio di topologia di Network Topology (fai clic per ingrandire)
Risorse e percorsi di traffico
In questo esempio, il progetto contiene le seguenti Google Cloud
risorse:
1 bilanciatore del carico HTTPS
4 servizi di backend: browse, shopping_cart, checkout e feeds
12 gruppi di istanze (che sono i backend del bilanciatore del carico)
Esiste un gruppo di istanze per ogni servizio di backend in ciascuna delle tre regioni.
3 istanze di database, una in ogni regione
Prevedi che il traffico proveniente da determinati paesi venga indirizzato alle seguenti località:
Il traffico proveniente dai paesi della regione aziendale Americas viene indirizzato ai backend della regione us-central1. Ad esempio, il traffico di un client esterno in Canada passa attraverso il bilanciatore del carico fino al backend checkout nella regione us-central1.
Il traffico proveniente dai paesi della regione dell'attività EMEA viene indirizzato ai backend della regione
europe-west1. Ad esempio, il traffico da un client esterno in Polonia passa attraverso il bilanciatore del carico fino al backend checkout nella regione europe-west1.
Il traffico proveniente dai paesi della regione dell'attività APAC viene indirizzato ai backend della regione
asia-east1. Ad esempio, il traffico di un client esterno in Giappone passa attraverso il bilanciatore del carico fino al backend checkout nella regione asia-east1.
Il traffico verso un'istanza di database proviene da un backend nella stessa regione. ad esempio, i backend in asia-east1 inviano dati solo all'istanza di database in asia-east1.
Il traffico tra regioni è limitato alla replica del database. Ad esempio, il traffico tra us-central1 e europe-west1 avviene solo tra le istanze di database in queste regioni.
Flusso di traffico imprevisto
In questo scenario, scopri che il traffico proveniente dalla regione dell'attività EMEA ora arriva a due regioni Google Cloud diverse, us-central1 e
europe-west1. Utilizzando Network Topology, scopri che uno dei backend è sovrautilizzato.
Vuoi verificare che il traffico esterno che passa per il bilanciatore del carico alla fine venga indirizzato alla regione corretta. Google Cloud Filtra il grafico in modo da mostrare solo il traffico per il bilanciatore del carico esternoshopping-site-lb.
Dopo aver applicato il filtro, Network Topology mostra solo le connessioni relative al bilanciatore del carico, come mostrato nell'esempio seguente.
Filtra per un bilanciatore del carico (fai clic per ingrandire)
Tieni premuto il cursore sopra ogni regione aziendale per evidenziare la comunicazione rivolta a quella regione.
Quando tieni premuto il cursore sopra Americas e APAC, viene visualizzato il traffico diretto alla regione Google Cloud più vicina: us-central1 e asia-
east1 rispettivamente. Tuttavia, quando tieni premuto il cursore sopra EMEA, visualizzate il traffico verso us-central1 e europe-west1. Idealmente, per ridurre la latenza, tutto il traffico proveniente dall'EMEA dovrebbe essere indirizzato a europe-west1.
Poi fai clic su EMEA per studiare il throughput tra questa regione e le altre regioniGoogle Cloud . Network Topology sovrappone i valori della larghezza di banda su ogni connessione. Vedrai che circa 0,58 byte al secondo vengono indirizzati a us-central1 e 29,9 kilobyte al secondo a europe-west1. Sai che la maggior parte del traffico viene indirizzata come previsto, ma parte del traffico viene indirizzata a us-central1.
Valori di larghezza di banda sovrapposti1 (fai clic per ingrandire)
1La figura è fornita come riferimento. I dati non riflettono il caso d'uso.
Per approfondire, espandi us-central1 per visualizzare la destinazione del traffico. Poiché in quella regione esiste una sola rete con una singola sottorete, Network Topology non mostra questi livelli della gerarchia e passa ai gruppi di istanze.
Vedrai che il traffico viene indirizzato a un gruppo di istanze associato al servizio di backend del bilanciatore del carico. Poiché si tratta di una quantità relativamente ridotta di traffico diretto a europe-west1, è possibile che le risorse in europe-west1 siano sovrautilizzate e causino il sovraccarico del traffico in us-central1.
Percorso del traffico1 (fai clic per ingrandire)
1La figura è fornita come riferimento. I dati non riflettono il caso d'uso.
Per confermare la tua conclusione, espandi la regione europe-west1 fino a raggiungere l'istanza associata al servizio di backend dello stesso bilanciatore del carico. Network Topology mostra i grafici delle serie temporali nel riquadro dettagli dell'istanza.
Nel grafico, noti che il tasso di utilizzo della CPU è pari all'81% per l'istanza. La soglia per questo esempio è dell'80%, il che indica che l'istanza è sovraabbonata. Per risolvere il problema, esegui l'aumento di scala del gruppo di istanze in modo che il traffico torni al flusso ideale.
Grafico delle serie temporali per un'istanza1 (fai clic per ingrandire)
1La figura è fornita come riferimento. I dati non riflettono il
caso d'uso.
Traffico tra regioni
Nella sezione seguente, verifichi che il traffico interno tra regioni sia limitato solo al traffico delle istanze di database.
Per concentrarti sul traffico interno, nell'elenco Configurazione della topologia seleziona solo le caselle di controllo Istanze e Gateway NAT cloud. Poiché visualizzi solo il traffico all'interno della tua applicazione, non è necessario visualizzare i client esterni e il traffico del bilanciatore del carico esterno.
Visualizzazione del traffico solo interno (fai clic per ingrandire)
Espandi la regione asia-east1 e visualizzi cinque gruppi di istanze. Non vengono aggregati per rete, subnet o zona perché si trovano tutti nella stessa rete, subnet e così via.
Noti che solo un gruppo di istanze (db-group-asia) contiene un percorso per il traffico interregionale. Tutti gli altri gruppi di istanze comunicano all'interno della regione.
Continua ad espandere il gruppo db-group-asia fino a raggiungere l'entità di base. In questo scenario, l'entità di base è un'istanza di una macchina virtuale (db-instance-asia) che funge da server di database. Sta comunicando con altre regioni per replicare i dati, come previsto, quindi non sono necessarie ulteriori indagini.
̦
Traffico interregionale1 (fai clic per ingrandire)
1La figura è fornita come riferimento. I dati non riflettono il
caso d'uso.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 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)"]]
