Chapitre 10. Optimiser la mise en réseau
Le SDN OpenShift utilise OpenvSwitch, des tunnels LAN virtuels extensibles (VXLAN), des règles OpenFlow et iptables. Ce réseau peut être réglé en utilisant des trames jumbo, des contrôleurs d'interface réseau (NIC) offloads, des files d'attente multiples et des paramètres ethtool.
OVN-Kubernetes utilise Geneve (Generic Network Virtualization Encapsulation) au lieu de VXLAN comme protocole de tunnel.
VXLAN offre des avantages par rapport aux VLAN, tels qu'une augmentation des réseaux de 4096 à plus de 16 millions, et une connectivité de couche 2 à travers les réseaux physiques. Cela permet à tous les pods derrière un service de communiquer entre eux, même s'ils fonctionnent sur des systèmes différents.
VXLAN encapsule tout le trafic tunnelé dans des paquets UDP (User Datagram Protocol). Toutefois, cela entraîne une augmentation de l'utilisation de l'unité centrale. Ces paquets externes et internes sont soumis aux règles normales de somme de contrôle pour garantir que les données ne sont pas corrompues pendant le transit. En fonction des performances de l'unité centrale, ce surcroît de traitement peut entraîner une réduction du débit et une augmentation de la latence par rapport aux réseaux traditionnels non superposés.
Les performances des CPU Cloud, VM et bare metal peuvent être capables de gérer un débit réseau bien supérieur à 1 Gbps. Lors de l'utilisation de liens à bande passante plus élevée, tels que 10 ou 40 Gbps, des performances réduites peuvent se produire. Il s'agit d'un problème connu dans les environnements basés sur VXLAN et qui n'est pas spécifique aux conteneurs ou à OpenShift Container Platform. Tout réseau reposant sur des tunnels VXLAN aura des performances similaires en raison de l'implémentation de VXLAN.
Si vous souhaitez aller au-delà d'un Gbps, c'est possible :
- Évaluer les plugins réseau qui mettent en œuvre différentes techniques de routage, telles que le protocole de passerelle frontalière (BGP).
- Utiliser des adaptateurs réseau compatibles avec la charge VXLAN. VXLAN-offload déplace le calcul de la somme de contrôle des paquets et le surcoût associé de l'unité centrale du système vers un matériel dédié sur l'adaptateur réseau. Cela libère des cycles de CPU pour les pods et les applications, et permet aux utilisateurs d'utiliser toute la bande passante de leur infrastructure réseau.
Le VXLAN-offload ne réduit pas la latence. Cependant, l'utilisation du CPU est réduite même dans les tests de latence.
10.1. Optimiser le MTU pour votre réseau
Il existe deux unités de transmission maximale (MTU) importantes : la MTU du contrôleur d'interface réseau (NIC) et la MTU du réseau en grappe.
Le MTU de la carte réseau n'est configuré qu'au moment de l'installation d'OpenShift Container Platform. Le MTU doit être inférieur ou égal à la valeur maximale supportée par le NIC de votre réseau. Si vous optimisez le débit, choisissez la valeur la plus élevée possible. Si vous optimisez la latence, choisissez une valeur plus faible.
Le MTU du plugin réseau OpenShift SDN doit être inférieur au MTU du NIC d'au moins 50 octets. Cela tient compte de l'en-tête de la couche SDN. Ainsi, sur un réseau Ethernet normal, cette valeur doit être fixée à 1450. Sur un réseau Ethernet à trame jumbo, elle doit être réglée sur 8950. Ces valeurs doivent être réglées automatiquement par l'opérateur de réseau de cluster en fonction du MTU configuré de la carte d'interface réseau. Par conséquent, les administrateurs de clusters ne mettent généralement pas à jour ces valeurs. Les environnements Amazon Web Services (AWS) et bare-metal prennent en charge les réseaux Ethernet à trame jumbo. Ce paramètre améliore le débit, en particulier avec le protocole de contrôle de transmission (TCP).
Pour OVN et Geneve, le MTU doit être inférieur au MTU du NIC de 100 octets au minimum.
Cet en-tête de recouvrement de 50 octets est pertinent pour le plugin réseau SDN d'OpenShift. D'autres solutions SDN peuvent nécessiter une valeur supérieure ou inférieure.
