Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Optimiser les performances du réseau sur les instances EC2 Windows

Il se peut que vous ayez besoin de modifier la configuration par défaut du système d’exploitation pour obtenir des performances réseau optimales sur vos instances Windows dont la mise en réseau est améliorée. Nous recommandons les modifications de configuration suivantes pour les applications nécessitant des performances réseau élevées. D’autres optimisations (telles que l’activation du déchargement de la somme de contrôle et l’activation du RSS, par exemple) sont déjà configurées sur les AMI Windows officielles.

Outre ces optimisations de système d’exploitation, vous devez également tenir compte de l’unité de transmission maximale (MTU) de votre trafic réseau et l’ajuster en fonction de votre charge de travail et de l’architecture réseau. Pour plus d’informations, consultez Unité de transmission maximale (MTU) du réseau pour votre instance EC2.

AWS mesure régulièrement les temps de latence aller-retour moyens entre les instances lancées dans un groupe de placement de cluster de 50 u et les temps de latence de queue de 200 u au percentile 99,9. Si vos applications nécessitent des temps de latence constamment faibles, nous vous recommandons d’utiliser la dernière version des pilotes ENA sur des instances à performances fixes et conçues sur le système Nitro.

Configurer l’affinité du processeur de mise à l’échelle côté réception

La distribution de la charge de l’UC du trafic réseau sur plusieurs processeurs est exécutée à l’aide de la technologie RSS (Receive side scaling) Par défaut, les AMI officielles d’Amazon Windows sont configurées avec les RSS activés. Les interfaces réseau élastiques ENA fournissent jusqu’à huit files d’attente RSS. En paramétrant l’affinité de l’UC pour les files d’attente RSS, ainsi que d’autres processus, il est possible de répartir la charge de l’UC sur des systèmes multicœurs, permettant ainsi le traitement d’un trafic réseau plus important. Sur les types d’instance avec plus de 16 vCPU, nous vous recommandons d’utiliser la commande PowerShell Set-NetAdapterRSS qui exclut manuellement le processeur de démarrage (processeur logique 0 et 1 lorsque la technologie « hyper-threading » est activée) de la configuration RSS pour toutes les interfaces réseau élastiques, afin d’éviter les conflits avec les différents composants du système.

Windows est compatible avec la technologie « hyper-thread » et veille à ce que les files d’attente RSS d’une même carte d’interface réseau (NIC) soient toujours placées sur des cœurs physiques différents. Par conséquent, à moins que l’hyper-threading ne soit désactivé, afin d’éviter tout conflit avec d’autres cartes NIC, répartissez la configuration RSS de chaque carte NIC sur une plage de 16 processeurs logiques. L’applet de commande Set-NetAdapterRss vous permet de définir la plage par carte réseau des processeurs logiques valides en définissant les valeurs BaseProcessorGroup, BaseProcessorNumber, MaxProcessingGroup, MaxProcessorNumber et NumaNode (facultatif). S’il n’y a pas assez de cœurs physiques pour éliminer complètement les conflits entre les cartes réseau, minimisez le chevauchement des plages ou réduisez le nombre de processeurs logiques dans les plages d’interfaces réseau élastiques en fonction de la charge de travail prévue pour l’interface (en d’autres termes, une interface réseau administrative à faible volume n’aura peut-être pas besoin d’autant de files d’attente RSS affectées). De plus, comme nous l’avons mentionné précedemment, divers composants doivent fonctionner sur le processeur 0, et nous recommandons donc de l’exclure de toutes les configurations RSS lorsque suffisamment de vCPU sont disponibles.

Par exemple, lorsqu’il y a trois interfaces réseau élastiques sur une instance de 72 vCPU avec 2 nœuds NUMA dont la technologie hyper-threading est activée, les commandes suivantes répartissent la charge réseau entre les deux processeurs sans chevauchement et empêchent complètement l’utilisation du cœur 0.

Set-NetAdapterRss -Name NIC1 -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessorNumber 16 
Set-NetAdapterRss -Name NIC2 -BaseProcessorGroup 1 -BaseProcessorNumber 0 -MaxProcessorNumber 14 
Set-NetAdapterRss -Name NIC3 -BaseProcessorGroup 1 -BaseProcessorNumber 16 -MaxProcessorNumber 30 

Notez que ces paramètres sont persistants pour chaque adaptateur réseau. Si une instance est redimensionnée avec un nombre différent de vCPU, vous devez évaluer à nouveau la configuration RSS pour chaque interface réseau élastique activée. La documentation complète de Microsoft pour l’applet de commande est disponible ici : Set-NetAdapterRss.

Remarque particulière pour les charges de travail SQL : nous vous recommandons également de revoir vos paramètres d’affinité des threads d’E/S ainsi que votre configuration RSS de l’interface réseau élastique afin de minimiser les conflits d’E/S et de réseau pour les mêmes processeurs. Consultez la section Configuration du serveur : masque d’affinité.