Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapitre 8. « Networking » (Réseau)

Au cours du temps, la pile réseau de Red Hat Enterprise Linux a été mise à niveau avec de nombreuses fonctionnalités automatisées. Pour la plupart des charges de travail, les paramètres réseau automatiquement configurés offrent des performances optimisées.
Dans la plupart des cas, les problèmes de performance réseau sont en fait causés par un malfonctionnement du matériel ou par une infrastructure défectueuse. Ce type de causes sont au-delà de l'étendue des explications de ce document, les problèmes de performance et les solutions dont il est question dans ce chapitre servent à parfaitement optimiser des systèmes fonctionnels.
Le « Networking » est un sous-système délicat, contenant différentes parties avec des connexions sensibles. Ce qui explique pourquoi la communauté Open Source et Red Hat investissent tant de travail dans l'implémentation de diverses manières d'optimiser les performances réseau automatiquement.

8.1. Améliorations des performances réseau

Ci-dessous figurent les améliorations des performances réseau apportées à Red Hat Enterprise Linux 6.1 :

RPS (« Receive Packet Steering »)

RPS active une seule file d'attente rx NIC pour que sa charge de travail softirq de réception soit distribuée sur plusieurs CPU. Ceci aide à empêcher que le trafic réseau ne soit congestionné sur une seule file d'attente de matériel NIC.
Pour activer RPS, veuillez spécifier les noms des CPU cibles dans /sys/class/net/ethX/queues/rx-N/rps_cpus, remplaçant ethX par le nom du périphérique correspondant à la NIC (par exemple, eth1, eth2) et rx-N par la file de réception NIC spécifiée. Ceci permettra aux CPU spécifiés dans le fichier de traiter les données de la file d'attente rx-N sur ethX. Lorsque vous spécifiez les CPU, prenez en considération les affinités du cache [4]de la file d'attente.

RFS (« Receive Flow Steering »)

RFS est une extension de RPS, permettant à l'administrateur de configurer une table de hachage qui est automatiquement remplie lorsque les applications reçoivent des données et sont interrogées par la pile réseau. Ceci permet de déterminer quelles applications reçoivent quelles données réseau (en se basant sur des informations réseau source:destination).
À l'aide de ces informations, la pile réseau peut programmer le CPU optimal pour qu'il reçoive chaque paquet. Pour configurer RFS, veuillez utiliser les réglages suivants :
/proc/sys/net/core/rps_sock_flow_entries
Ce réglage contrôle le nombre maximal de sockets ou de flux que le noyau peut diriger vers n'importe quel CPU spécifié. La limite définie est globale et partagée.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt
Ce réglage contrôle le nombre maximal de sockets ou flux que le noyau peut diriger vers une file de réception spécifiée (rx-N) située sur une NIC (ethX). Remarquez que la somme de toutes les valeurs par file de ce réglage sur toutes les NIC devrait être égale ou inférieure à /proc/sys/net/core/rps_sock_flow_entries.
Contrairement à RPS, RFS permet à la file de réception et à l'application de partager le même CPU lors du traitement des flux de paquets. Dans certains cas, cela se traduit par de meilleures performances. Cependant, ces améliorations dépendent de facteurs tels que la hiérarchie des caches, la charge de l'application, et ainsi de suite.

Prise en charge de getsockopt pour les flux de type « thin-stream » TCP

Thin-stream est un terme utilisé pour caractériser les protocoles de transport avec lesquels les applications envoient des données à des débits si bas que les mécanismes de retransmission du protocole ne sont pas complètement saturés. Les applications qui utilisent des protocoles « thin-stream » effectuent habituellement leur transport via des protocoles fiables, comme TCP ; dans la plupart des cas, ce type d'applications offre des services urgents (comme des opérations en bourse, jeux en ligne et systèmes de contrôle).
Sur les services urgents, la perte de paquets peut se révéler dévastatrice pour la qualité du service. Pour vous aider à éviter cela, l'appel getsockopt a été amélioré afin de prendre en charge deux options supplémentaires :
TCP_THIN_DUPACK
Ce booléen active le déclenchement dynamique des retransmissions après un « dupACK » pour les « thin-streams ».
TCP_THIN_LINEAR_TIMEOUTS
Ce booléen active le déclenchement dynamique des délais d'expirations linéaires pour les « thin-streams ».
Ces deux options sont spécifiquement activées par l'application. Pour obtenir des informations supplémentaires sur ces options, veuillez consulter file:///usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt. Pour obtenir des informations supplémentaires sur les « thin-streams », veuillez consulter file:///usr/share/doc/kernel-doc-version/Documentation/networking/tcp-thin.txt.

Prise en charge des TProxy (proxys transparents)

Le noyau peut maintenant gérer des sockets UDP et TCP IPv4 non-localement liés pour prendre en charge des proxys transparents. Pour activer cela, vous devrez configurer iptables en conséquence. Vous devrez aussi activer et configurer la stratégie de routage correctement.
Pour obtenir des informations supplémentaires sur les proxys transparents, veuillez consulter file:///usr/share/doc/kernel-doc-version/Documentation/networking/tproxy.txt.

[4] S'assurer des affinités du cache entre un CPU et une NIC signifie les configurer pour qu'ils partagent le même cache L2. Pour obtenir des informations supplémentaires, veuillez consulter la Section 8.3, « Aperçu des réceptions de paquets ».