Caso d'uso: controllare le prestazioni della rete

Supponi di essere un amministratore di rete che supporta una rete che include diverse applicazioni con bilanciamento del carico. Ti è stato chiesto di verificare le configurazioni di rete che supportano queste applicazioni per garantire che siano coerenti con lo stato previsto della rete. Con questo controllo puoi assicurarti che i clienti ricevano la latenza più bassa possibile per le tue applicazioni.

Il seguente caso d'uso mostra come Network Topology può aiutarti a verificare le configurazioni esistenti. Ad esempio, puoi verificare che tutte le richieste del client vengano gestite da istanze dell'applicazione nell'area geografica di Google Cloud 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 interessa tre regioni Google Cloud (us-central1, europe-west1 e asia-east1). Tutte le richieste client esterne vengono gestite da un singolo bilanciatore del carico delle applicazioni esterno con più backend in ciascuna delle tre regioni. Le richieste dei client che provengono da una delle tre regioni aziendali (Americhe, EMEA e APAC) vengono gestite da istanze dell'applicazione nella regione Google Cloud più vicina.

Il grafico seguente mostra la gerarchia di primo livello per il deployment.

Topologia di esempio Network Topology (fai clic per ingrandire)

Risorse e percorsi di traffico

In questo esempio, il progetto contiene le seguenti risorse Google Cloud:

• 1 bilanciatore del carico HTTPS

• 4 servizi di backend: browse, shopping_cart, checkout e feeds

• 12 gruppi di istanze (ovvero 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 arrivi alle seguenti località:

• Il traffico proveniente dai paesi della regione commerciale Americas passa ai backend nella regione us-central1. Ad esempio, il traffico da un client esterno in Canada passa attraverso il bilanciatore del carico al backend checkout nella regione us-central1.
• Il traffico proveniente dai paesi della regione aziendale EMEA passa ai backend nella regione europe-west1. Ad esempio, il traffico da un client esterno in Polonia passa attraverso il bilanciatore del carico al backend checkout nella regione europe-west1.
• Il traffico proveniente dai paesi della regione aziendale APAC passa ai backend nella regione asia-east1. Ad esempio, il traffico da un client esterno in Giappone passa attraverso il bilanciatore del carico 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 viaggia solo tra istanze di database in quelle regioni.

Flusso di traffico imprevisto

In questo scenario, scopri che il traffico proveniente dalla regione aziendale EMEA starà ora in due diverse regioni Google Cloud, us-central1 e europe-west1. Grazie a Network Topology, scopri che uno dei backend è sovrautilizzato.

1. Vuoi verificare che il traffico esterno che passa attraverso il bilanciatore del carico alla fine venga indirizzato alla regione Google Cloud corretta. Filtra il grafico per mostrare solo il traffico per il bilanciatore del carico esterno shopping-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)

2. Tieni il puntatore su ogni area commerciale per mettere in evidenza la comunicazione con quell'area.

   Quando tieni il puntatore del mouse su Americhe e APAC, vedi il traffico verso la regione Google Cloud più vicina: us-central1 e asia- east1, rispettivamente. Tuttavia, quando tieni premuto il puntatore del mouse su EMEA, vedi il traffico diretto a us-central1 e europe-west1. Idealmente, per ridurre la latenza, tutto il traffico proveniente dall'EMEA deve essere indirizzato a europe-west1.

3. Successivamente, fai clic su EMEA per studiare la velocità effettiva tra questa località e le regioni di Google Cloud. Network Topology sovrappone i valori della larghezza di banda su ciascuna connessione. Come puoi notare, circa 0,58 byte al secondo corrispondono a us-central1 e 29,9 kilobyte al secondo corrispondono a europe-west1. Sai che la maggior parte del traffico viene indirizzata come previsto, ma una parte del traffico passa verso us-central1.

   

   Valori della larghezza di banda sovrapposti¹ (fai clic per ingrandire)

   ¹ La figura è solo un riferimento. I dati non riflettono il caso d'uso.

4. Per esaminare ulteriormente il traffico, espandi us-central1 per visualizzare dove viene indirizzato il traffico. Poiché esiste una sola rete con una singola subnet in quella regione, Network Topology non mostra questi livelli della gerarchia e passa ai gruppi di istanze.

   Come puoi notare, 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 piccola di traffico in direzione di europe-west1, è possibile che le risorse in europe-west1 siano sovrautilizzate e provochino un overflow del traffico fino a us-central1.

   

   Percorso di traffico¹ (fai clic per ingrandire)

   ¹ La figura è solo un riferimento. I dati non riflettono il caso d'uso.

5. Per confermare la 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 dei dettagli per l'istanza.

   Nel grafico, noti che la percentuale di utilizzo della CPU è all'81% per l'istanza. La soglia per questo esempio è dell'80%, che indica che l'istanza ha un abbonamento in eccesso. Per risolvere il problema, fai lo scale up del gruppo di istanze in modo che il traffico torni al flusso ideale.

   

   Grafico delle serie temporali per un'istanza¹ (fai clic per ingrandire)

   ¹ La figura è solo un riferimento. I dati non riflettono il caso d'uso.

Traffico tra regioni

Nella sezione seguente verificherai che il traffico interno tra regioni sia limitato al solo traffico delle istanze di database.

1. Per concentrarti sul traffico interno, nell'elenco Configurazione topologia, seleziona solo le caselle di controllo Istanze e Gateway Cloud NAT. Poiché stai visualizzando solo il traffico all'interno della tua applicazione, non hai bisogno di vedere client esterni e traffico del bilanciatore del carico esterno.

   

   Visualizzazione del traffico solo interno (fai clic per ingrandire)

2. Espandi la regione asia-east1 e vengono visualizzati cinque gruppi di istanze. Non sono aggregati per rete, subnet o zona perché si trovano tutti nella stessa rete, subnet e così via.

   Noterai che solo un gruppo di istanze (db-group-asia) contiene un percorso per il traffico tra regioni. Tutti gli altri gruppi di istanze comunicano all'interno della regione.

   Continua a espandere il gruppo db-group-asia fino a raggiungere l'entità di base. In questo scenario, l'entità di base è un'istanza di macchina virtuale (VM) (db-instance-asia) che agisce come server di database. Sta comunicando con altre regioni per replicare i dati, come previsto, quindi non sono necessarie ulteriori indagini.

   

   Traffico tra regioni¹ (fai clic per ingrandire)

   ¹ La figura è solo un riferimento. I dati non riflettono il caso d'uso.

Passaggi successivi

• Monitorare la configurazione di rete con Network Topology
• Caso d'uso: risolvere i problemi di connettività di rete
• Risolvere i problemi relativi a Network Topology