Note : Mise à jour mai 2023 avec la configuration Arcep QoS mobile 2023 : le maximum de la fenêtre TCP passe de 16 à 32 Mo.

3/ Optimisations réseau et swappiness :

nano /etc/sysctl.d/90-server-optimization.conf
Copier / coller la configuration BBR ou la configuration Cubic en fonction de votre choix.

Serveur BBR : Copier / coller le texte ci-dessous dans le fichier :
# Algorithme d’évitement de congestion TCP et qdisc
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq

# décorrélation des tests successifs
net.ipv4.tcp_no_metrics_save=1

# Paramétrage de la fenêtre TCP à 32 Mio
net.ipv4.tcp_rmem=4096 131072 33554432
net.ipv4.tcp_wmem=4096 87380 33554432
net.core.rmem_max=33554432
net.core.wmem_max=33554432

# Limiter l’utilisation du swap
vm.swappiness = 1

# Augmentation de la file d'attente dans le noyau Linux où le trafic est stocké après réception par la carte réseau
net.core.netdev_max_backlog=4000

# Réduire le seuil où un DDOS impacte le serveur
net.ipv4.tcp_max_syn_backlog = 4096

# Augmenter le nombre de connexions entrantes
net.core.somaxconn = 4096
Serveur Cubic : Copier / coller le texte ci-dessous dans le fichier :
# Algorithme d’évitement de congestion TCP et qdisc
net.ipv4.tcp_congestion_control=cubic
net.core.default_qdisc=fq_codel

# décorrélation des tests successifs
net.ipv4.tcp_no_metrics_save=1

# Paramétrage de la fenêtre TCP à 32 Mio
net.ipv4.tcp_rmem=4096 131072 33554432
net.ipv4.tcp_wmem=4096 87380 33554432
net.core.rmem_max=33554432
net.core.wmem_max=33554432

# Limiter l’utilisation du swap
vm.swappiness = 1

# Augmentation de la file d'attente dans le noyau Linux où le trafic est stocké après réception par la carte réseau
net.core.netdev_max_backlog=4000

# Réduire le seuil où un DDOS impacte le serveur
net.ipv4.tcp_max_syn_backlog = 4096

# Augmenter le nombre de connexions entrantes
net.core.somaxconn = 4096

---

Explications de la configuration proposée :

Configuration BBR vs Cubic :

Cubic et BBR sont les deux algorithmes les plus utilisés côté serveur pour décider de la vitesse d’envoi des paquets.
Aujourd’hui, la majorité de l’internet utilise Cubic, créé en 2006, qui s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l'implémentation par défaut sous Linux, Android et MacOS.
Google a développé en 2016 BBR (pour « Bottleneck Bandwidth and Round-trip propagation time ») qui utilise un modèle différent se basant sur la bande passante maximale et le temps d’aller-retour (RTT ou « round trip time »). Cette approche permet à BBR de proposer un débit nettement plus élevé que Cubic sur un réseau qui perd des paquets sans lien avec une congestion. BBR est de plus en plus utilisé par certains grands acteurs de l’Internet.

« net.ipv4.tcp_congestion_control=bbr » va utiliser l’algorithme de congestion BBR, conçu par Google, à la place de Cubic, afin d’avoir de meilleures performances réseau.
Important : Le paramétrage "qdisc", le protocole de queuing discipline doit être adapté au protocole de congestion :
- Pour Cubic, on recommande fq_codel
- Pour BBR, on recommande fq

Optionnel, pour la configuration Cubic, proposer BBR en protocole de congestion optionnel : Si vous souhaitez qu'il soit disponible pour un outil tel que iperf3 qui permet de sélectionner le protocole de congestion, il faut créer un fichier pour charger le module :
nano /etc/modules-load.d/tcp_allowed_congestion_control.conf
Copier / coller le texte ci-dessous dans le fichier :
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr

---

Décorrélation des tests successifs : tcp_no_metrics_save=1

Par défaut, TCP enregistre diverses métriques de connexion dans le cache de routage lorsque la connexion se ferme, de sorte que les connexions établies dans un proche avenir peuvent les utiliser pour définir les conditions initiales. Habituellement, cela augmente les performances globales, mais peut parfois entraîner une dépendance du test N au test N-1.
Dans le cadre des tests de débit, et afin d’assurer une décorrélation des tests successifs, la mémorisation des tests précédents a été désactivée sur le serveur via « tcp_no_metrics_save=1 » afin d’éviter que le serveur bride tous les tests, à la suite d’une performance limitée.

---

Paramétrage de la fenêtre TCP : maximum de 32 Mio

TCP utilise un mécanisme de fenêtrage glissante pour empêcher qu'un émetteur rapide ne surcharge un récepteur plus lent. Le récepteur annonce la quantité de données que l'émetteur doit envoyer avant d'attendre l'actualisation de la fenêtre par le récepteur. Le délai le plus rapide d'actualisation d'une fenêtre correspond à un aller-retour, ce qui conduit à la formule suivante pour calculer l'une des limites de performance du transfert de données groupées sur une connexion TCP : Débit <= taille de la fenêtre / latence du délai aller-retour (DAR).

Une fenêtre TCP trop petite peut limiter artificiellement le débit pour les connexions à très haut débit ou forte latence. La configuration par défaut des serveurs peut limiter artificiellement les débits, notament pour les  utilisateurs ultramarines (quand le serveur est en métropole).

La taille de la fenêtre TCP est affectée par les 4 paramètres suivants :
• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem
• net.core.rmem_max
• net.core.wmem_max
Note : le paramétrage net.ipv4.xxx s’applique également au protocole IPv6.

Les deux premiers paramètres configurables affectent la taille de fenêtre TCP pour les applications qui laissent la fonction de réglage automatique de Linux se charger de cette tâche.
Les deux derniers paramètres configurables affectent la taille maximale de fenêtre TCP pour les applications qui tentent de contrôler directement la taille de la fenêtre TCP, en limitant la requête des applications à ces valeurs seulement.

Paramètres de la mémoire tampon de réception TCP (net.ipv4.tcp_rmem=4096 131072 33554432).  Les 3 valeurs sont :
• Taille minimale du tampon de réception pouvant être allouée à un socket TCP.
• Taille par défaut du tampon de réception.
• Taille maximale de la mémoire tampon de réception pouvant être allouée à un socket TCP.

Paramètres de la mémoire tampon d’envoi TCP (net.ipv4.tcp_wmem=4096 87380 33554432).  Les 3 valeurs sont :
• Espace minimal du tampon d'envoi TCP disponible pour un socket TCP.
• Espace par défaut du tampon autorisé pour un socket TCP.
• Espace maximal du tampon d'envoi TCP.

Taille maximale de la mémoire tampon de réception du système d'exploitation pour tous les types de connexions :
net.core.rmem_max= 33554432

Taille maximale de la mémoire tampon d'envoi du système d'exploitation pour tous les types de connexions :
net.core.wmem_max= 33554432

---

Limiter l’utilisation du swap :vm.swappiness = 1

Le paramètre « vm.swappiness = 1 » ne concerne pas TCP/IP, mais demande au système de limiter l’utilisation de l’espace d’échange situé sur disque (swap). Cet espace est utilisé par le système d'exploitation pour déplacer des données peu utilisées des programmes en cours d'exécution, afin d'utiliser l'espace libéré comme cache du système de fichiers.
Ce comportement risque de dégrader les performances réseau au moment où des données peu utilisées en mémoire vive sont mises dans le SWAP. Afin de fiabiliser le flux de données généré par le serveur, on met « vm.swappiness = 1 », ce qui permet de limiter l’utilisation du swap aux cas où c’est nécessaire.

5/ Limitation du nombre de connexions TCP simultanées par IP :

On va limiter à 100 connexions par IPv4 et par plage IPv6 /64, afin de bloquer certains types d’attaque par déni de service.
Pour un site web important, il peut être nécessaire de monter à 200 connexions simultanées (sur lafibre.info 100 connexions peuvent être insuffisante pour un usage légitime avec HTTP/2 d'activé).
On va loger les connexions, mais pour éviter d'être submergé par les connexions à loguer, on va limiter radicalement les logs : 1 log toutes les 2 minutes sans possibilité de burst.
nano /root/iptables-rules.sh
Copier / coller le texte ci-dessous dans le fichier :
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/usr/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j REJECT
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -j REJECT
chmod +x /root/iptables-rules.sh : On rend le script exécutable
echo "# Application des règles iptables au reboot" > /etc/cron.d/iptables-rules
echo "@reboot root /root/iptables-rules.sh" >> /etc/cron.d/iptables-rules : Lancmenbet du script au démarrage du serveur

---

6/ Nom de domaine FQDN (fully qualified domain name) :

Vérifier que le nom de domaine apparaît bien avec la commande :
hostname -f
Si ce n'est pas le cas, il faut rajouter les informations FQDN dans /etc/hosts : nano /etc/hosts
On met en premier l’IP, suivit d’un espace et du nom de domaine pleinement qualifié (avec le .com ou .fr) suivit d’un espace et du nom simple du serveur.
Si vous souhaitez changer le nom du serveur, il faut également modifier nano /etc/hostname
On met seulement le nom simple du serveur (pas besoin du nom complet avec le .com ou .fr)

11/ Optionnel : Limiter la taille des logs systemd /var/log/journal/

Si certains fichiers de log sont gérés par logrotate, les différents éléments du système sont lancés par systemd qui tient à jour son propre système de journalisation nommé The Journal, enregistré dans le répertoire /var/log/journal/. Si une machine a peu d'espace disque, on peut imiter la taille maximum du journal (par défaut à 10% de la taille du système de fichier, avec un maximum de 4 Go).

nano /etc/systemd/journald.conf

Pour la fixer à 500 Mo par exemple, on modifie la ligne #SystemMaxUse= par SystemMaxUse=600M

D'autres modifications peuvent être envisagée sur /etc/systemd/journald.conf :

• SystemKeepFree : L’espace qui doit rester libre sur la partition où sont trouvés les journaux. Par défaut 15%, ce qui veut dire qu’à 85% d’espace utilisé, journald supprimera des logs pour éviter de remplir la partition. S'il y avait suffisamment d'espace libre avant et que les fichiers journaux ont été créés, et par la suite quelque chose d'autre provoque le remplissage du système de fichiers, journald cessera d'utiliser plus d'espace, mais il ne supprimera pas non plus les fichiers existants pour réduire à nouveau l'empreinte. Notez également que seuls les fichiers archivés sont supprimés pour réduire l'espace occupé par les fichiers journaux.
• SystemMaxFileSize : Journald écrit ses fichiers au format binaire et fait une rotation sur ces fichiers. Le fichier en cours d’écriture sera rempli jusqu’à la taille spécifiée, avant qu’un nouveau fichier soit créé. Par défaut 1/8 de la taille totale définie avec SystemMaxUse. Par exemple, si vous définissez un SystemMaxUse de 600M, chaque fichier de journal sur disque fera au maximum 75M avant rotation.
• SystemMaxFiles : contrôle le nombre de fichiers journaux individuels à conserver au maximum. Notez que seuls les fichiers archivés sont supprimés pour réduire le nombre de fichiers jusqu'à ce que cette limite soit atteinte ; les fichiers actifs resteront. Cela signifie qu'en fait, il peut y avoir encore plus de fichiers journaux au total que cette limite une fois l'opération de nettoyage terminée. Ce paramètre est défini par défaut sur 100.

On peut aussi faire en sorte que les journaux ne soient pas conservés sur le disque au redémarrage afin de limiter l'usure des SSD sur un serveur avec de la ram ou les logs ne sont pas importants (on perdra les log au reboot du serveur) : Modifier la ligne #Storage=auto par Storage=volatile

Voici les options possibles :

• persistent : Les logs sont écrits sur le disque, dans le dossier /var/log/journal, à la condition que /var soit monté.
• volatile : Les logs sont gardés dans la mémoire, plus précisément stockés dans le dossier /run/log/journal
• auto (par défaut) : Le système choisit où sont écrits les logs. Si le dossier /var/log/journal existe et est accessible, alors les logs y seront écrits. Sinon, ça se fera en mémoire.
• none : Les logs ne sont pas stockés et donc directement droppés à la réception

Attention :

• Les options SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles= concernent le stockage persistant (sur disque donc).
• Les options RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles= sont leur équivalent pour le stockage volatile (en RAM donc).

Si vous partez sur Storage=volatile, il faudra donc définir un RuntimeMaxUse=300M pour limiter à 300 Mo l’utilisation de ram pour les logs.

Une fois les modifications effectuées, il faut redémarrer le service systemd-journald pour ce soit pris en compte :
systemctl restart systemd-journald

---

12/ Optionnel : détecter les sondes et rajouter les modules nécessaires

Exécuter sudo sensors-detect
Répondez positivement à toutes les questions ;
À un certain moment sensors-detect vous demande s'il doit ajouter lui même la configuration des capteurs au lancement d'Ubuntu en affichant ceci :
To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)Tapez yes, puis faites Entrée.

Vérification du contenu du fichier /etc/modules modifié : cat /etc/modules

16/ Vérifications que le watchdog fontionne (si installé)
Installation réalisée à l'étape 13/ Optionnel : Installation du Watchdog.

La commande pour interroger le watchdog est la suivante :
sudo ipmitool mc watchdog get

ok : il fonctionne parfaitement
# ipmitool mc watchdog get
Watchdog Timer Use:     SMS/OS (0x44)
Watchdog Timer Is:      Started/Running
Watchdog Timer Actions: Hard Reset (0x01)
Pre-timeout interval:   0 seconds
Timer Expiration Flags: 0x10
Initial Countdown:      120 sec
Present Countdown:      77 sec
Non ok : En cas de plantage, le serveur ne redémarrera pas.
# ipmitool mc watchdog get
Watchdog Timer Use:     SMS/OS (0x04)
Watchdog Timer Is:      Stopped
Watchdog Timer Actions: No action (0x00)
Pre-timeout interval:   0 seconds
Timer Expiration Flags: 0x10
Initial Countdown:      10 sec
Present Countdown:      10 sec
Détail des différentes lignes affichées :

• Watchdog Timer Is : Permet de savoir si le watchdog fonctionne : Il faut que ce soit « Started/Running ».
• Watchdog Timer Actions : L'action effectuée en cas d’expiration du délai « Initial Countdown » Il faut que ce soit « Hard Reset » pour provoquer un reboot.
• Initial Countdown : Délai du watchdog initial (celui configuré dans /etc/systemd/system.conf)
• Present Countdown : Délai actuel avant reboot (« Present Countdown » est remis régulièrement à « Initial Countdown » a la moitié du temps écoulé).

Si le wathdog ne fonctionne pas :

Le Watchdog peut être désactivé dans l'UEFI, il faut dans ce cas là l'activer :



Dépendance manquante dans /etc/modules : Les modules « ipmi_si » et « ipmi_devintf » sont nécessaire au Watchdog IPMI :
lsmod | grep ipmi
ipmi_ssif              24576  0
ipmi_devintf           20480  0
ipmi_si                57344  0
ipmi_msghandler        49152  3 ipmi_ssif,ipmi_devintf,ipmi_si

Si la ligne « ipmi_devintf » est absente : echo ipmi_devintf >> /etc/modules
Si la ligne « ipmi_si absent » est absente : echo ipmi_si >> /etc/modules


Vérification du contenu du fichier /etc/modules : cat /etc/modules


L'état du watatchdog peut aussi se vérifier dans l'iDrac pour un serveur Dell :