GSP045

Présentation

Dans cet atelier pratique, vous allez découvrir des scénarios réels, recréer les environnements présentés et tenter d'améliorer les faibles performances des exemples de réseau.

Vous pourrez vous amuser à essayer de comparer les différentes instances comme dans un scénario de résolution de problème. Ainsi, vous pourrez démontrer les résultats et vous familiariser avec la procédure à suivre pour améliorer les performances de vos propres systèmes.

Cet atelier s'inspire d'articles de blog de Colt McAnlis : Core count and the Egress problem (Nombre de cœurs et problème en sortie) et Internal IP vs External IP Performance (Performances des adresses IP internes et externes). Colt McAnlis publie sur Medium des articles concernant les performances réseau de Google Cloud.

Objectifs

• Tester la connectivité et les performances réseau à l'aide d'outils Open Source
• Inspecter le trafic réseau à l'aide d'outils Open Source
• Découvrir comment la taille des machines influence les performances réseau

Prérequis

• Connaissances de base des services Google Cloud (le mieux est d'avoir préalablement suivi les ateliers de la quête Google Cloud Essentials)
• Connaissances de base des réseaux Google Cloud et du protocole TCP/IP (le mieux est d'avoir préalablement suivi les ateliers de la quête Networking in the Google Cloud)
• Connaissances de base de la ligne de commande Unix/Linux

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;

Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

5. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas aux essais offerts.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche.

L'objectif de cet atelier est de vous présenter le rapport entre taille du cœur et débit. Vous aurez accès à six instances pré-intégrées, créées au démarrage de l'atelier.

• Dans la console Cloud, accédez au Menu de navigation > Compute Engine > Instances de VM pour afficher vos instances :

Remarque : La région et la zone de vos instances peuvent être différentes de celles qui apparaissent dans la capture d'écran.

Test de connexion

Procédez à un test de connexion rapide pour vérifier que tout fonctionne correctement.

1. Connectez-vous en SSH à l'instance-1 en cliquant sur le bouton "SSH" à côté de son nom dans la console.

2. Dans la nouvelle fenêtre de shell, pinguez l'une de vos autres instances et exécutez la commande suivante, en remplaçant <external ip address of instance-2> par l'adresse IP externe de l'instance-2 :

ping -c 5 <external ip address of instance-2>

Exemple de résultat :

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.158.169 PING 35.194.158.169 (35.194.158.169) 56(84) bytes of data. 64 bytes from 35.194.158.169: icmp_seq=1 ttl=76 time=1.89 ms 64 bytes from 35.194.158.169: icmp_seq=2 ttl=76 time=0.409 ms 64 bytes from 35.194.158.169: icmp_seq=3 ttl=76 time=0.542 ms 64 bytes from 35.194.158.169: icmp_seq=4 ttl=76 time=0.557 ms 64 bytes from 35.194.158.169: icmp_seq=5 ttl=76 time=0.559 ms --- 35.194.158.169 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.409/0.792/1.894/0.554 ms

3. Pinguez une autre instance. Remplacez <external ip address of instance-3> par l'adresse IP externe de l'instance-3, puis exécutez la commande ping :

ping -c 5 <external ip address of instance-3>

Exemple de résultat :

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.187.75 PING 35.194.187.75 (35.194.187.75) 56(84) bytes of data. 64 bytes from 35.194.187.75: icmp_seq=1 ttl=64 time=1.59 ms 64 bytes from 35.194.187.75: icmp_seq=2 ttl=64 time=0.336 ms 64 bytes from 35.194.187.75: icmp_seq=3 ttl=64 time=0.338 ms 64 bytes from 35.194.187.75: icmp_seq=4 ttl=64 time=0.302 ms 64 bytes from 35.194.187.75: icmp_seq=5 ttl=64 time=0.270 ms --- 35.194.187.75 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.270/0.568/1.596/0.514 ms

Tout a l'air de fonctionner. Passons maintenant à la suite.

Examiner les règles de pare-feu

Des règles de pare-feu ont également été créées pour cet atelier.

• Pour les afficher, accédez au Menu de navigation > Mise en réseau > Réseaux VPC > Pare-feu, puis cliquez sur le pare-feu iperftesting.

La règle de pare-feu iperftesting utilise la configuration suivante :

Champ	Valeur	Commentaires
Nom	iperftesting	Nom de la nouvelle règle
Cibles	Toutes les instances du réseau
Plages d'adresses IP sources	0.0.0.0/0	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Protocoles et ports	tcp : 5001 ; udp : 5001
Sens du trafic	Entrée
Action en cas de correspondance	Autoriser

Vous pouvez maintenant commencer à suivre l'atelier.

Cas d'utilisation 1 : mise en réseau et nombre de cœurs Compute Engine

Dans ce premier scénario, vous verrez comment la taille des machines utilisées affecte le débit mesurable.

Dobermanifesto est un réseau de microblogs vidéo dédié exclusivement aux animaux. Des vidéos montrant des animaux peuvent y être ajoutées partout dans le monde, puis envoyées n'importe où pour être visualisées.

Lors du transfert de données depuis ou vers ses backends Compute Engine, la bande passante observée n'était pas aussi élevée que l'espérait l'équipe de Dobermanifesto :

Tâche 1 : Reproduire ce comportement

Pour essayer de reproduire ce comportement, deux instances ont été créées dans la même zone et un test iperf a été exécuté 100 fois entre elles.

Les performances obtenues sont encore pires ! Manifestement, un problème est survenu lors du test. L'entreprise doit fournir des informations supplémentaires et une liste plus détaillée des étapes à suivre pour reproduire le comportement souhaité.

Vous allez maintenant élaborer le scénario.

Environnement de Dobermanifesto

1. Revenez à la liste des instances de VM dans la console Compute Engine.

2. Connectez-vous en SSH à l'instance-1 (un processeur virtuel, 3,75 Go), puis exécutez cette commande pour configurer une sorte de "récepteur" iperf :

iperf -s

3. Connectez-vous ensuite en SSH à l'instance-2 (un processeur virtuel, 3,75 Go), puis générez du trafic iperf renvoyant à l'instance-1 :

iperf -c <external ip address of instance-1>

Exemple de résultat :

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.225.180.44 ------------------------------------------------------------ Client connecting to 35.225.180.44, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.0.4 port 56330 connected with 35.225.180.44 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0000-10.0010 sec 4.66 GBytes 4.00 Gbits/sec

4. Revenez à l'instance-1, puis appuyez sur Ctrl+C pour arrêter le récepteur.

Environnement de test

1. Revenez à la console Compute Engine et ouvrez une autre fenêtre SSH pour l'instance-6 (un processeur virtuel e2-micro de 0,6 Go).

2. Exécutez la commande suivante, pour la configurer en tant que "récepteur" :

iperf -s

Exemple de résultat :

student-00-aafd1bd9c185@instance-6:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

3. Dans la fenêtre SSH de l'instance-2, testez la connexion à l'instance-6 :

iperf -c <internal ip address of instance-6>

Exemple de résultat :

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.7 ------------------------------------------------------------ Client connecting to 10.40.0.7, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.5 port 54029 connected with 10.40.0.7 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.29 GBytes 1.96 Gbits/sec

4. Revenez à l'instance-6, puis appuyez sur Ctrl+C pour arrêter le récepteur.

Que s'est-il passé ? La bande passante semble avoir augmenté. Il est possible que ce soit aussi le cas pour vous. Peut-être dans une moindre mesure.

Dans la section suivante, nous verrons que la bande passante est limitée par le nombre total de cœurs, et qu'avec un petit nombre de cœurs (un seul), la bande passante ne pourra jamais dépasser 2 Gbit/s environ. Résultat : le débit du réseau est faible et la bande passante est limitée, comme pour le réseau de Dobermanifesto. Lorsque vous effectuerez le test avec des machines à quatre processeurs dans un instant, les résultats seront supérieurs.

Le nombre de cœurs est directement lié au débit en Gbit/s

Pourquoi les résultats ne diffèrent-ils pas plus ? Voici ce qu'indique la documentation de Compute Engine :

Le trafic sortant (de sortie) d'une machine virtuelle est soumis à des limites maximales de débit de sortie réseau. Ces limites dépendent du nombre de processeurs virtuels appartenant à une instance de machine virtuelle. Chaque cœur est soumis à une limite de 2 Gbit/s pour des performances optimales. Chaque cœur supplémentaire augmente le plafond de débit jusqu'à un maximum théorique de 16 Gbit/s par machine virtuelle.

En d'autres termes, plus votre réseau compte de processeurs, plus le débit réseau est important.

Pour voir à quoi cela ressemble en pratique, plusieurs groupes avec des tailles de cœur différentes ont été configurés dans la même zone, et un test iPerf a été exécuté 1 000 fois entre eux.

Lorsque le nombre de cœurs augmente, les débits moyen et maximal augmentent eux aussi. Même avec ce simple test, la limite stricte de 16 Gbit/s s'applique aux machines comptant le plus de cœurs.

Remarque : Si vous exécutez le test iPerf avec plusieurs threads (environ huit), vous pouvez dépasser les 10 Gbit/s et atteindre environ 16 Gbit/s en utilisant une machine e2-standard-16 ou supérieure. Dans cet environnement d'atelier, nous ne disposons pas d'une machine de cette taille, mais procédons néanmoins au test avec plusieurs threads. Il existe également des VM plus coûteuses dans les séries N2, N2D, C2 et C2D qui vous permettent de sélectionner une configuration de niveau 1 à bande passante élevée et d'atteindre 50 à 100 Gbit/s.

Tâche 2 : Améliorer les résultats

Le réseau utilisé par Dobermanifesto utilise des machines ayant un seul processeur virtuel. L'augmentation de la taille du cœur aidera sans doute Dobermanifesto à obtenir de meilleurs résultats. Testons dès maintenant cette théorie.

1. Connectez-vous en SSH à l'instance-3 (quatre processeurs virtuels avec mémoire de 15 Go), puis exécutez cette commande :

iperf -s

Exemple de résultat :

student-00-aafd1bd9c185@instance-3:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. Connectez-vous en SSH à l'instance-4 (quatre processeurs virtuels et mémoire de 15 Go) :

iperf -c <internal ip address of instance-3>

Exemple de résultat :

student-00-aafd1bd9c185@instance-4:~$ iperf -c 10.40.0.2 ------------------------------------------------------------ Client connecting to 10.40.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.4 port 54081 connected with 10.40.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 8.93 GBytes 7.67 Gbits/sec

3. Maintenant, réessayez avec quatre threads :

iperf -c <internal ip address of instance-3> -P4

4. Et avec huit threads :

iperf -c <internal ip address of instance-3> -P8

5. Revenez à l'instance-3, puis appuyez sur Ctrl+C pour arrêter le récepteur.

Lors de ces expériences, le serveur et le client étaient tous les deux configurés avec quatre processeurs virtuels, et le débit a augmenté considérablement. Le taux de transfert a augmenté de 6,64 gigaoctets, et la bande passante de 5,71 Gbit/s. Avec plusieurs threads, les performances ont atteint la limite maximale pour ce nombre de cœurs.

6. Poursuivez le test avec l'instance-5, une machine à quatre processeurs virtuels offrant des performances supérieures, de type "highcpu-4".

Ce type d'instance bénéficie de processeurs plus rapides, mais de moins de mémoire. Constatez-vous des différences ? Lesquelles ? Avec plusieurs threads ?

À présent, l'équipe de Dobermanifesto doit décider de la marche à suivre. Après avoir analysé l'utilisation du processeur et examiné les informations sur la tarification, elle a décidé d'opter pour une machine e2-standard-4, qui lui a permis de presque quadrupler le débit moyen, tout en étant plus abordable qu'une machine e2-standard-8.

L'un des avantages de passer à une machine plus performante est qu'elle s'exécute moins souvent. Il s'avère que les machines de l'équipe passaient beaucoup de temps à transférer des données. Avec cette plus grande machine, les instances étaient plus souvent arrêtées, ce qui permettait à l'équilibreur de charge de réduire le nombre total d'instances exécutées quotidiennement. Au final, l'équipe payait pour une machine de niveau supérieur, mais comptabilisait aussi moins d'heures d'utilisation du cœur par mois.

Dès lors que vos performances ont un impact direct sur vos résultats, vous devez envisager de nombreux compromis nuancés.

Cas d'utilisation 2 : mise en réseau Google Cloud avec des adresses IP internes

Dans cet exemple, vous allez utiliser iperf pour tester le débit. Vous configurerez une machine en tant que serveur, d'autres machines renvoyant à ce serveur, puis vous comparerez les résultats.

Gecko Protocol, entreprise B2B offrant un protocole réseau léger et personnalisé pour le jeu et les autres systèmes graphiques en temps réel, a constaté que ses machines de backend, responsables du transfert et du transcodage de fichiers vidéo et graphiques volumineux, avaient un débit plus lent que prévu.

Voici les résultats du test iPerf de référence qu'elle a mené :

------------------------------------------------------------ Client connecting to 104.155.145.79, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 53504 connected with 104.155.145.79 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.03 GBytes 884 Mbits/sec

Lors de la reproduction du test, la configuration du réseau était identique, mais le test a donné des résultats assez différents :

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.128.0.2 ------------------------------------------------------------ Client connecting to 10.128.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 38978 connected with 10.128.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.27 GBytes 1.95 Gbits/sec

Le débit de 1,95 Gbit/s était bien supérieur à celui constaté par Gecko Protocol sur ses graphiques. Comment expliquer cette différence ?

À présent, reproduisez ce scénario.

1. Dans la console, connectez-vous en SSH à l'instance-1 et configurez le récepteur iPerf :

iperf -s

Exemple de résultat :

student-00-aafd1bd9c185@instance-1:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. Connectez-vous en SSH à l'instance-2 et vérifiez la connexion avec l'adresse IP externe :

iperf -c <external ip address of instance-1>

Exemple de résultat :

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.201.145.135 ------------------------------------------------------------ Client connecting to 35.201.145.135, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 58691 connected with 35.201.145.135 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.36 GBytes 1.16 Gbits/sec

En discutant plus longuement avec l'équipe de Gecko Protocol, il s'est avéré qu'elle connectait ses machines via des adresses IP externes, alors que le test utilisait des adresses IP internes. Lorsque les machines appartiennent à un réseau, le fait de les connecter avec des adresses IP internes a pour effet d'accélérer le débit.

3. À présent, vérifiez la connexion avec l'adresse interne :

iperf -c <internal ip address of instance-1>

Exemple de résultat :

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 42950 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.26 GBytes 1.94 Gbits/sec

Observez les différences de taux de transfert et de vitesses de bande passante. Dans cet exemple, le remplacement par une adresse IP interne s'est traduit par une augmentation du taux de transfert de 0,9 Gigaoctets, et une accélération de la bande passante de 0,78 Gbit/s. Vous venez de prouver que la connexion interne est plus rapide.

En vous appuyant sur ce que vous avez appris en résolvant le problème de Dobermanifesto, pensez-vous pouvoir accélérer encore davantage le débit réseau en utilisant une machine plus performante ? L'instance-2 ne comporte qu'un processeur virtuel. Avec une machine un peu plus performante, quelle peut être la vitesse de connexion ? Ou avec une machine beaucoup plus performante ? Poursuivez les tests avec l'adresse IP interne, sans hésiter à tester aussi l'adresse externe, si vous en avez le temps.

Machine à quatre processeurs virtuels

• Connectez-vous en SSH à l'instance-3 et testez la connexion avec l'adresse IP interne :

iperf -c <internal ip address of instance-1>

Exemple de résultat (les vôtres peuvent être différents) :

student-00-aafd1bd9c185@instance-3:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.6 port 39115 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 4.53 GBytes 3.89 Gbits/sec

Machine à quatre processeurs haute capacité

• Connectez-vous en SSH à l'instance-5 et testez la connexion avec l'adresse IP interne :

iperf -c <internal ip address of instance-1>

Exemple de résultat :

student-00-aafd1bd9c185@instance-5:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.3 port 39736 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.3 GBytes 8.84 Gbits/sec

Le débit est bien supérieur.

Il semble que Gecko Protocol devra aussi réfléchir à la taille de cœur la plus pertinente. Cette petite session de débogage s'est traduite par une multiplication par environ 14 du débit de transfert des données vidéo et graphiques. Ce qui est énorme, si l'on considère que son offre est basée sur des services de backend supérieurs pour les scénarios de calcul hautes performances.

Tâche 3 : Exécuter des tests dans votre propre environnement

Cet atelier n'aborde pas les tests sur votre propre système, mais voici des informations supplémentaires à consulter. Pour en savoir plus sur l'exécution de tests sur votre propre réseau, reportez-vous à l'article Network Throughput Testing with iPerf (Test du débit réseau avec iPerf).

Si vous avez du temps et souhaitez configurer une VM à tester, n'hésitez pas. Lorsque vous créez vos VM, assurez-vous d'utiliser la règle de pare-feu et le tag "iperftest". Testez votre adresse IP interne et votre adresse IP externe.

Paramètres à appliquer pour tester le débit de votre propre réseau

1. Dans la console, accédez au Menu de navigation > Mise en réseau > Réseaux VPC > Pare-feu.

2. Cliquez sur Créer une règle de pare-feu. Utilisez la configuration suivante pour créer une règle de pare-feu :

Champ	Valeur	Commentaires
Nom	iperf-testing	Nom de la nouvelle règle
Cibles	Toutes les instances du réseau
Plages d'adresses IP sources	0.0.0.0/0	Nous allons ouvrir le pare-feu à toutes les adresses IP provenant d'Internet.
Sens du trafic	entrée
Action en cas de correspondance	Autoriser
Protocoles et ports	tcp : 5001 ; udp : 5001

3. Cliquez sur Créer.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer la règle de pare-feu

La tendance consiste à approcher le plus possible la charge de travail de 100 %, ce qui laisse peu d'espace pour la défragmentation du disque, etc.

Un objectif de 90-93 % est recommandé. À 98 %, les conflits de ressources sont nombreux, ce qui réduit les performances.

Pendant les tests, si les performances d'E/S se dégradent, vérifiez les compteurs de limitation. Si aucune limite ne s'applique, examinez l'utilisation du processeur. Si elle est élevée, tout le problème est là.

Tâche 4 : Pour aller plus loin

Dans l'interface de l'atelier, sous "Ressources destinées aux élèves" à gauche, vous verrez des liens vers des vidéos en rapport avec cet atelier. Elles sont vraiment très intéressantes.

Félicitations !

Félicitations ! Dans cet atelier, vous avez appris à tester la connectivité réseau et les performances à l'aide d'outils Open Source. Vous aussi avez découvert en quoi la taille de votre machine peut influer sur les performances de votre réseau.

Étapes suivantes et informations supplémentaires

• Consultez l'article du blog Google Cloud intitulé Using Google's cloud networking products: A guide to all the guides (Utiliser les produits de mise en réseau cloud de Google : le guide de référence de tous les guides).
• Lisez la documentation sur la mise en réseau Compute Engine.
• Obtenez des informations sur les sous-réseaux.
• Publiez vos questions et trouvez des réponses sur Stack Overflow à l'aide du tag google-compute-engine ou google-cloud-platform.

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière modification du manuel : 4 octobre 2023

Dernier test de l'atelier : 4 octobre 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.