Points de contrôle
Create the firewall rule
/ 100
Améliorer les performances réseau I
- GSP045
- Présentation
- Objectifs
- Préparation
- Cas d'utilisation 1 : mise en réseau et nombre de cœurs Compute Engine
- Tâche 1 : Reproduire ce comportement
- Tâche 2 : Améliorer les résultats
- Cas d'utilisation 2 : mise en réseau Google Cloud avec des adresses IP internes
- Tâche 3 : Exécuter des tests dans votre propre environnement
- Tâche 4 : Pour aller plus loin
- Félicitations !
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) ;
- vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Démarrer l'atelier et se connecter à la console Google Cloud
-
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
-
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. -
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.
-
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. -
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.
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 :
Test de connexion
Procédez à un test de connexion rapide pour vérifier que tout fonctionne correctement.
-
Connectez-vous en SSH à l'
instance-1
en cliquant sur le bouton "SSH" à côté de son nom dans la console. -
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
:
Exemple de résultat :
- Pinguez une autre instance. Remplacez
<external ip address of instance-3>
par l'adresse IP externe de l'instance-3
, puis exécutez la commandeping
:
Exemple de résultat :
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
-
Revenez à la liste des instances de VM dans la console Compute Engine.
-
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
:
- Connectez-vous ensuite en SSH à l'
instance-2
(un processeur virtuel, 3,75 Go), puis générez du traficiperf
renvoyant à l'instance-1
:
Exemple de résultat :
- Revenez à l'
instance-1
, puis appuyez sur Ctrl+C pour arrêter le récepteur.
Environnement de test
-
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). -
Exécutez la commande suivante, pour la configurer en tant que "récepteur" :
Exemple de résultat :
- Dans la fenêtre SSH de l'
instance-2
, testez la connexion à l'instance-6
:
Exemple de résultat :
- 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.
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.
- Connectez-vous en SSH à l'
instance-3
(quatre processeurs virtuels avec mémoire de 15 Go), puis exécutez cette commande :
Exemple de résultat :
- Connectez-vous en SSH à l'
instance-4
(quatre processeurs virtuels et mémoire de 15 Go) :
Exemple de résultat :
- Maintenant, réessayez avec quatre threads :
- Et avec huit threads :
- 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.
- 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é :
Lors de la reproduction du test, la configuration du réseau était identique, mais le test a donné des résultats assez différents :
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.
- Dans la console, connectez-vous en SSH à l'
instance-1
et configurez le récepteur iPerf :
Exemple de résultat :
- Connectez-vous en SSH à l'
instance-2
et vérifiez la connexion avec l'adresse IP externe :
Exemple de résultat :
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.
- À présent, vérifiez la connexion avec l'adresse interne :
Exemple de résultat :
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 :
Exemple de résultat (les vôtres peuvent être différents) :
Machine à quatre processeurs haute capacité
- Connectez-vous en SSH à l'
instance-5
et testez la connexion avec l'adresse IP interne :
Exemple de résultat :
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
-
Dans la console, accédez au Menu de navigation > Mise en réseau > Réseaux VPC > Pare-feu.
-
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 |
- Cliquez sur Créer.
Cliquez sur Vérifier ma progression pour valider l'objectif.
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.