Elenco di controllo dei problemi di prestazioni della rete Bare Metal Solution
Questa pagina fornisce un elenco di controllo dei problemi per la risoluzione dei problemi relativi alle prestazioni della rete. Il diagramma di flusso riportato di seguito mostra i percorsi da seguire per la risoluzione di questi problemi.
Esegui un test di velocità (test di throughput)
Esegui un test di velocità tra la VM Compute Engine o il server di applicazioni e il server Bare Metal Solution se si verificano problemi di larghezza di banda tra l'host di jump e il server Bare Metal Solution.
Assicurati che il server di origine si trovi nella stessa regione dei server Bare Metal Solution, perché i test tra regioni potrebbero comportare un throughput inferiore e non mostrare i valori previsti.
Un altro punto importante da controllare è il tipo di macchina della macchina di origine e la larghezza di banda in uscita massima (Gbps) fornita da ciascun tipo di macchina, come descritto nella pagina relativa ai tipi di macchine di Compute Engine.
Lo strumento iperf3 deve sempre essere eseguito con più stream paralleli, perché l'esecuzione di iperf3 con un singolo stream TCP ha una limitazione di larghezza di banda.
Accedi al server Bare Metal Solution ed esegui il server iperf3 per accettare le connessioni TCP
dai client.
iperf3 -s 192.168.1.10
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Mantieni aperta la connessione al server ed esegui iperf3 dalla VM Compute Engine per testare il throughput
iperf3 -c 192.168.1.10 -P 128
Connecting to host 192.168.1.10, port 5201
[SUM] 0.00-10.00 sec 10.3 GBytes 8.85 Gbits/sec 150161 sender
[SUM] 0.00-10.00 sec 10.3 GBytes 8.82 Gbits/sec receiver
Se non ottieni la velocità/la larghezza di banda desiderata, controlla se il problema rientra in uno dei seguenti scenari.
Scenario 1: l'host di jump è una piccola VM con una limitazione della larghezza di banda in uscita massima
Puoi trovare il limite di larghezza di banda in uscita massima per tutti i tipi di server nella pagina Tipi di macchine di Compute Engine.
Se utilizzi una VM Compute Engine (ad esempio n1-standard-1) nella stessa regione del server della soluzione Bare Metal con un'interconnessione partner di 5 Gbps, vedrai quanto segue:
iperf3 -c 192.168.1.10 -P 128
Connecting to host 192.168.1.10, port 5201
[SUM] 0.00-10.00 sec 2.31 GBytes 1.98 Gbits/sec 129 sender
[SUM] 0.00-10.00 sec 2.24 GBytes 1.93 Gbits/sec receiver
Questi risultati mostrano che, anche se abbiamo due interconnessioni con una velocità di 5 Gbps ciascuna, non stiamo ancora ottenendo le prestazioni desiderate. Questo perché la larghezza di banda in uscita massima supportata da una macchina n1-standard-1 è di 2 Gbps.
Soluzione: passa a una VM più grande per ottenere i risultati desiderati.
Scenario 2: l'host di jump si trova in una regione diversa rispetto al server Bare Metal Solution.
Quando esegui un test di velocità tra server di regioni diverse, non ottieni i risultati desiderati a causa delle latenze tra regioni dei componenti aggiuntivi.
Di seguito è riportato un test di velocità tra una VM Compute Engine in us-central1
e un server Bare Metal Solution in southamerica-east1
iperf3 -c 192.168.1.10 -P 128
Connecting to host 192.168.1.10, port 5201
[SUM] 0.00-10.00 sec 3.12 GBytes 2.68 Gbits/sec 15569 sender
[SUM] 0.00-10.00 sec 3.02 GBytes 2.60 Gbits/sec receiver
Si verifica un calo significativo della larghezza di banda/velocità quando la connessione avviene tra regioni diverse.
Soluzione: connettiti a un server Bare Metal Solution dalla stessa regione.
Scenario 3: iperf3 è in esecuzione con più stream paralleli.
Di seguito sono riportati i risultati dell'esecuzione di iperf3 con un singolo stream TCP
iperf3 -c 192.168.1.10
Connecting to host 192.168.1.10, port 5201
[ 5] local 10.158.0.6 port 40382 connected to 192.168.1.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 325 MBytes 2.72 Gbits/sec 162 1.72 MBytes
[ 5] 1.00-2.00 sec 345 MBytes 2.89 Gbits/sec 42 1.36 MBytes
[ 5] 2.00-3.00 sec 345 MBytes 2.89 Gbits/sec 0 1.53 MBytes
[ 5] 3.00-4.00 sec 344 MBytes 2.88 Gbits/sec 0 1.68 MBytes
[ 5] 4.00-5.00 sec 345 MBytes 2.89 Gbits/sec 67 1.32 MBytes
[ 5] 5.00-6.00 sec 345 MBytes 2.89 Gbits/sec 0 1.49 MBytes
[ 5] 6.00-7.00 sec 345 MBytes 2.89 Gbits/sec 0 1.65 MBytes
[ 5] 7.00-8.00 sec 344 MBytes 2.88 Gbits/sec 0 1.79 MBytes
[ 5] 8.00-9.00 sec 321 MBytes 2.69 Gbits/sec 64 1.39 MBytes
[ 5] 9.00-10.00 sec 324 MBytes 2.72 Gbits/sec 91 1.13 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 3.30 GBytes 2.84 Gbits/sec 426 sender
[ 5] 0.00-10.00 sec 3.30 GBytes 2.83 Gbits/sec receiver
L'esecuzione di iperf3 dallo stesso server, ma utilizzando più stream TCP, consente di ottenere le prestazioni desiderate.
iperf3 -c 192.168.1.10 -P 128
Connecting to host 192.168.1.10, port 5201
[SUM] 0.00-10.00 sec 10.3 GBytes 8.85 Gbits/sec 150161 sender
[SUM] 0.00-10.00 sec 10.3 GBytes 8.82 Gbits/sec receiver
Soluzione: utilizza più stream paralleli con iperf3.
Passaggio 2: misura la latenza della rete
Se ti colleghi all'interno della stessa regione, puoi aspettarti una latenza di andata e ritorno media inferiore a 2&nbps;ms.
Usa ping per controllare la latenza tra i server. Puoi anche utilizzare mtr per ottenere la latenza media.
ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=88 time=1.78 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=88 time=0.507 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=88 time=0.659 ms
64 bytes from 192.168.1.10: icmp_seq=4 ttl=88 time=0.735 ms
64 bytes from 192.168.1.10: icmp_seq=5 ttl=88 time=0.592 ms
64 bytes from 192.168.1.10: icmp_seq=6 ttl=88 time=0.550 ms
64 bytes from 192.168.1.10: icmp_seq=7 ttl=88 time=0.552 ms
64 bytes from 192.168.1.10: icmp_seq=8 ttl=88 time=0.588 ms
64 bytes from 192.168.1.10: icmp_seq=9 ttl=88 time=0.614 ms
^C
--- 192.168.1.10 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 169ms
rtt min/avg/max/mdev = 0.507/0.730/1.781/0.378 ms
La latenza minima, media e massima è ben al di sotto di 2 ms, che è la latenza promessa tra la Google Cloud regione e l'estensione della regione.
In alternativa, puoi utilizzare anche MTR per misurare la latenza in modo dinamico.
mtr --curses 192.168.1.10
test-arka (10.158.0.6) 2020-12-11T08:08:51+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
host Loss% Snt Last Avg Best Wrst StDev
1. ???
2. 192.168.1.10 0.0% 16 0.7 0.7 0.6 1.5 0.2
Se utilizzi mtr, vedi anche il rendimento della rete desiderato.
Se la latenza media supera i 2&nbps;ms, controlla se la connessione avviene all'interno della stessa regione. L'esecuzione del test di latenza tra regioni introduce un overhead di latenza aggiuntivo, come mostrato di seguito.
ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=59 time=144 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=59 time=142 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=59 time=142 ms
64 bytes from 192.168.1.10: icmp_seq=4 ttl=59 time=142 ms
64 bytes from 192.168.1.10: icmp_seq=5 ttl=59 time=142 ms
64 bytes from 192.168.1.10: icmp_seq=6 ttl=59 time=142 ms
^C
--- 192.168.1.10 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5003ms
rtt min/avg/max/mdev = 142.004/142.390/144.079/0.845 ms
Soluzione: connettiti all'interno della stessa regione.
Passaggio 3: controlla il numero di hop
Se si verificano discrepanze nei test precedenti, controlla il numero di hop tra l'host di jump e l'host Bare Metal Solution. L'introduzione di hop non necessari può ostacolare le prestazioni della rete.
traceroute 192.168.1.10
traceroute to 192.168.1.10 (192.168.1.10), 30 hops max, 60 byte packets
1 * * *
2 169.254.215.122 (169.254.215.122) 2.713 ms * 1.757 ms
3 192.168.1.10 (192.168.1.10) 2.656 ms 2.595 ms *
traceroute 192.168.1.10
traceroute to 192.168.1.10 (192.168.1.10), 30 hops max, 60 byte packets
1 * * *
2 192.168.1.10 (192.168.1.10) 2.323 ms 2.260 ms 2.353 ms
Quando esegui un test tra un'istanza Compute Engine nella stessa regione del server Bare Metal Solution, non dovresti vedere alcun hop o al massimo un hop per il router del data center lato host.
Nell'esempio precedente, l'IP 169.254.215.122 è l'IP del data center lato host.
Puoi controllare indirizzi come questo nella pagina
Connettività ibrida -> Interconnessione
nella console.
Se vedi hop per l'intervallo IP 169.254.0.0, non c'è da preoccuparsi, poiché si tratta di indirizzi IP dei router cloud interni. Google Cloud Se vedi altri hop oltre a questo, potresti dover approfondire l'hop aggiuntivo e potresti anche dover contattare l'assistenza per sapere dove e come viene introdotto.