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 de plus amples informations, veuillez consulter Unité de transmission maximale (MTU) du réseau pour votre instance EC2.

AWS mesure régulièrement les latences aller-retour moyennes entre les instances lancées dans un groupe de placement de clusters de 50 unités et les latences de queue de 200 unités au 99,9 centile. 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 comportant plus de 16 vCPU, nous vous recommandons d'utiliser l'Set-NetAdapterRSS PowerShell applet de commande, qui exclut manuellement le processeur de démarrage (processeurs logiques 0 et 1 lorsque l'hyper-threading est activé) de la configuration RSS pour toutes les interfaces réseau élastiques, afin d'éviter tout conflit avec divers 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'hyperthreading ne soit désactivé, pour éviter tout conflit avec d'autres cartes réseau, répartissez la configuration RSS de chaque carte réseau sur une plage de 16 processeurs logiques. L'Set-NetAdapterRssapplet de commande vous permet de définir la plage de processeurs logiques valides par carte réseau en définissant les valeurs de 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 Microsoft complète relative à l'applet de commande est disponible ici :. Set-NetAdapterRss

Remarque spéciale concernant les charges de travail SQL : nous vous recommandons également de revoir vos paramètres d'affinité de I/O thread ainsi que la configuration RSS de votre interface réseau Elastic afin de minimiser I/O les conflits réseau pour les mêmes processeurs. Consultez la section Configuration du serveur : masque d’affinité.