Checklist pour les problèmes de performances réseau de la solution Bare Metal
Cette page fournit une checklist des problèmes de performance du réseau afin de les résoudre. L'organigramme ci-dessous présente les chemins à suivre pour résoudre ces problèmes.
Effectuer un test de vitesse (test de débit)
Effectuez un test de débit entre votre VM Compute Engine ou serveur d'applications et le serveur de la solution Bare Metal en cas de problèmes de bande passante entre l'hôte intermédiaire et le serveur de la solution Bare Metal.
Assurez-vous que le serveur source réside dans la même région que les serveurs de la solution Bare Metal, car les tests interrégionaux peuvent entraîner un débit inférieur et ne pas afficher les valeurs de débit attendues.
Un autre point important à vérifier est le type de machine de la machine source et la bande passante de sortie maximale (Gbps) fournie par chaque type de machine, comme décrit dans la page sur les types de machines de Compute Engine.
L'outil iperf3 doit toujours être exécuté avec plusieurs flux parallèles, car l'exécution de iperf3 avec un seul flux TCP présente une limite de bande passante.
Connectez-vous au serveur de la solution Bare Metal et exécutez le serveur iperf3 pour accepter les connexions TCP des clients.
iperf3 -s 192.168.1.10
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Laissez la connexion au serveur ouverte, et exécutez iperf3 à partir de la VM Compute Engine pour tester le débit.
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
Si vous n'obtenez pas la vitesse/bande passante souhaitée, vérifiez si votre problème correspond à l'un des scénarios suivants.
Scénario 1 : L'hôte intermédiaire est une petite VM avec une limite de bande passante de sortie maximale
La limite de bande passante de sortie maximale pour tous les types de serveurs est indiquée sur la page Types de machines de Compute Engine.
Si vous utilisez une VM Compute Engine (par exemple, n1-standard-1) dans la même région que le serveur de la solution Bare Metal avec une interconnexion partenaire de 5 Gbit/s, vous obtenez le résultat suivant :
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
Ces résultats montrent que nous n'obtenons toujours pas les performances souhaitées, même avec deux interconnexions offrant une vitesse de 5 Gbit/s chacune. En effet, la bande passante de sortie maximale acceptée par une machine n1-standard-1 est de 2 Gbit/s.
Solution : passez à une VM plus grande pour obtenir les résultats souhaités.
Scénario 2 : L'hôte intermédiaire est situé dans une région différente de celle du serveur de la solution Bare Metal
Lorsque vous effectuez un test de vitesse entre des serveurs interrégionaux, vous n'obtenez pas les résultats souhaités en raison de latences interrégionales supplémentaires.
Voici un test de vitesse entre une VM Compute Engine dans us-central1 et un serveur de la solution Bare Metal dans 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
La bande passante/vitesse diminue considérablement lors de la connexion interrégionale.
Solution : connectez-vous à un serveur de la solution Bare Metal de la même région.
Scénario 3 : iperf3 s'exécute avec plusieurs flux parallèles
Vous trouverez ci-dessous les résultats de l'exécution de iperf3 avec un seul flux 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'exécution de iperf3 à partir du même serveur, mais l'utilisation de plusieurs flux TCP permet d'obtenir les performances souhaitées.
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
Solution : utilisez plusieurs flux parallèles avec iperf3.
Étape 2 : Mesurer la latence du réseau
Si vous vous connectez au sein de la même région, vous pouvez vous attendre à une latence aller-retour moyenne inférieure à 2 ms.
Utilisez ping pour vérifier la latence entre les serveurs. Vous pouvez également utiliser mtr pour obtenir la latence moyenne.
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 latence minimale, moyenne et maximale est bien inférieure à 2 ms, ce qui correspond à la latence promise entre la région Google Cloud et l'extension de région.
Vous pouvez également utiliser MTR pour mesurer le temps de latence de manière dynamique.
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
L'utilisation de mtr vous permet également d'obtenir les performances réseau souhaitées.
Si vous constatez que la latence moyenne dépasse 2 ms, vérifiez que la connexion se produit au sein de la même région. L'exécution du test de latence entre les régions entraîne une hausse de latence supplémentaire, comme illustré ci-dessous.
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
Solution : connectez-vous au sein de la même région.
Étape 3 : Vérifier le nombre de sauts
Si vous constatez des incohérences dans les tests précédents, vérifiez le nombre de sauts entre votre hôte intermédiaire et l'hôte de la solution Bare Metal. L'introduction de sauts inutiles peut nuire aux performances du réseau.
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
Lorsque vous effectuez un test entre une instance Compute Engine située dans la même région que le serveur de la solution Bare Metal, vous ne devez constater aucun saut, ou au maximum un saut pour le routeur du centre de données côté hôte.
Dans l'exemple ci-dessus, l'adresse IP 169.254.215.122 est l'adresse IP du centre de données côté hôte.
Vous pouvez vérifier des adresses de ce type sur la page Connectivité hybride > Interconnexion de la console.
Si vous constatez des sauts pour la plage d'adresses IP 169.254.0.0, aucun problème n'est à signaler, car il s'agit des adresses IP Google Cloud internes du routeur cloud. Si vous constatez des sauts autres que ceux-ci, vous devrez peut-être approfondir vos connaissances sur le saut supplémentaire et également contacter l'assistance afin de savoir où et comment le saut supplémentaire est introduit.