Si les paramètres par défaut du système d'exploitation Linux ne répondent pas aux exigences de votre charge de travail, vous pouvez personnaliser les paramètres au niveau du pool de nœuds afin d'optimiser les performances du système. Après l'application des paramètres personnalisés, le système met à jour les configurations des nœuds par lots. Ces modifications s'appliquent immédiatement aux nœuds existants et sont automatiquement héritées par les nouveaux nœuds ajoutés au pool.
Remarques relatives à l'utilisation
Cette fonctionnalité est prise en charge uniquement sur les clusters ACK managés, les clusters ACK dédiés et les clusters ACK Edge exécutant la version 1.28 ou ultérieure.
La création de nouveaux clusters ACK dédiés n'est plus prise en charge. Pour mettre à niveau votre cluster, consultez la rubrique Mettre à niveau un cluster .
La modification dynamique des paramètres du système d'exploitation peut déclencher un redéploiement des pods. Avant de poursuivre, assurez-vous que votre application est configurée pour la haute disponibilité (HA).
Un ajustement incorrect des paramètres du système d'exploitation peut modifier le comportement du noyau, entraînant une dégradation des performances ou des pannes de nœuds qui affectent vos services. Comprenez parfaitement l'objectif de chaque paramètre et testez toutes les modifications dans un environnement hors production avant de les appliquer en production.
Configurer les paramètres du système d'exploitation du pool de nœuds
Vous pouvez personnaliser les paramètres sysctl et Transparent Huge Pages (THP) au niveau du pool de nœuds. Bien que tous les paramètres soient configurables via des fichiers, une sélection de paramètres sysctl et tous les paramètres THP peuvent être définis à l'aide de la console ACK ou de l'API OpenAPI.
Configurer à l'aide de la console ou de l'API OpenAPI
Console
L'application de paramètres personnalisés du système d'exploitation modifie la configuration des nœuds existants et peut avoir un impact sur vos services. Nous vous recommandons d'effectuer cette opération pendant les heures creuses.
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, recherchez le cluster à gérer et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Nodes > Node Pools.
Dans la liste des pools de nœuds, repérez le pool de nœuds cible et choisissez ... > OS Configuration dans la colonne Actions.
Lisez attentivement les remarques affichées à l'écran. Cliquez sur + Custom Parameters, sélectionnez les paramètres et spécifiez les nœuds cibles. Définissez le nombre maximal de nœuds à réparer par lot via le champ Maximum Number of Nodes to Repair per Batch (la valeur maximale est 10), puis cliquez sur Submit.
Après avoir défini le Maximum Number of Nodes to Repair per Batch, la configuration du système d'exploitation est appliquée aux nœuds par lots. Pendant ce processus, vous pouvez surveiller la progression dans la section Event History et contrôler l'exécution avec des actions telles que pause, resume et cancel.
La mise en pause vous permet de valider les nœuds mis à niveau. Si vous mettez la tâche en pause, la configuration des nœuds en cours se termine, mais le processus ne se poursuit pas sur les autres nœuds tant que vous ne l'avez pas reprise.
Terminez la tâche de configuration rapidement. Toute tâche en pause est automatiquement annulée après sept jours, et toutes les informations associées aux événements et aux journaux sont supprimées.
API OpenAPI
En plus de la console, vous pouvez personnaliser les paramètres du système d'exploitation à l'aide de l'opération ModifyNodePoolNodeConfig.
Configurer à l'aide d'un fichier de configuration
ACK vous permet d'écrire des paramètres personnalisés dans le fichier /etc/sysctl.d/99-user-customized.conf. Ce fichier est réservé aux configurations personnalisées appliquées lors de l'initialisation et du redémarrage des nœuds. Les paramètres sysctl de ce fichier ont la priorité lors du redémarrage du nœud, remplaçant à la fois les valeurs par défaut du système d'exploitation et les paramètres appliqués via la fonctionnalité OS Configuration de la console.
L'ajustement des paramètres sysctl modifie le fonctionnement du noyau Linux et peut entraîner une dégradation des performances ou une panne du nœud, ce qui affecte vos services. Évaluez entièrement les risques avant d'effectuer des modifications.
Nœuds existants
Pour les nœuds existants du pool de nœuds, connectez-vous au nœud et modifiez le fichier de configuration. Ensuite, exécutez la commande suivante pour appliquer immédiatement les modifications :
sysctl -p /etc/sysctl.d/99-user-customized.conf
Exemple de fichier de configuration (/etc/sysctl.d/99-user-customized.conf) :
# Filesystem settings
fs.file-max = 2097152
fs.nr_open = 1048576
# Networking settings
net.core.somaxconn = 32768
net.ipv4.tcp_max_syn_backlog = 8096
# Memory / kernel settings
vm.max_map_count = 262144
Remplacez les noms et les valeurs des paramètres par ceux dont vous avez besoin pour votre charge de travail.
Nouveaux nœuds (mise à l'échelle horizontale)
Pour les nouveaux nœuds ajoutés au pool de nœuds par mise à l'échelle horizontale, vous pouvez ajouter un script au champ User Data du pool de nœuds. Cela garantit que les nouveaux nœuds utilisent automatiquement les valeurs de paramètres personnalisées.
Dans le champ User Data de la configuration de votre pool de nœuds, ajoutez un script pour écrire la configuration personnalisée dans un fichier du répertoire /etc/sysctl.d/. Remplacez ${sysctl_key} et ${sysctl_value} par le paramètre et la valeur réels.
#!/bin/bash
echo "${sysctl_key} = ${sysctl_value}" >> /etc/sysctl.d/99-user-customized.conf
sysctl -p /etc/sysctl.d/99-user-customized.conf
Pour plus d'informations, consultez la rubrique Créer et gérer des pools de nœuds .
Vérifier que les modifications ont pris effet
Après avoir appliqué les paramètres personnalisés du système d'exploitation, vérifiez que les modifications ont bien été appliquées à vos nœuds.
Connectez-vous à un nœud du pool de nœuds. Pour plus d'informations, consultez la rubrique Se connecter à une instance ECS.
-
Exécutez la commande
sysctlpour vérifier la valeur actuelle d'un paramètre. Par exemple : Sortie attendue :sysctl fs.file-maxfs.file-max = 2097152 -
Pour les paramètres THP, lisez le fichier sysfs correspondant. Par exemple :
cat /sys/kernel/mm/transparent_hugepage/enabled Dans la console ACK, vérifiez l'état de la tâche de configuration dans la section Event History du pool de nœuds.
Liste des paramètres sysctl
Dans les tableaux suivants, la Default Value correspond à la valeur définie par défaut par ACK lors de l'initialisation d'un pool de nœuds.
Pour connaître la plage de valeurs valides de ces paramètres, consultez la documentation relative aux paramètres sysctl du noyau Linux.
Pour les paramètres non répertoriés ici ou non encore pris en charge dans la console ou l'API OpenAPI, vous pouvez les modifier en suivant les étapes décrites dans la section Configurer à l'aide d'un fichier de configuration.
Paramètres du système de fichiers
Ces paramètres contrôlent les limites des handles de fichiers, les watches inotify et le comportement du système de fichiers. Ajustez ces paramètres pour les charges de travail intensives en E/S ou les applications qui ouvrent un grand nombre de fichiers.
| Nom du champ | Description | Valeur par défaut | Console ou API OpenAPI |
|---|---|---|---|
fs.aio-max-nr |
Le nombre maximal d'opérations d'E/S asynchrones. | 65536 | Oui |
fs.file-max |
Le nombre maximal de handles de fichiers que le système peut ouvrir. | 2097152 | Oui |
fs.inotify.max_user_watches |
Le nombre maximal de watches inotify qu'un seul utilisateur peut créer. | 524288 | Oui |
fs.inotify.max_user_instances |
Le nombre maximal d'instances inotify qu'un seul utilisateur peut créer. Limite l'utilisation des ressources par utilisateur. | 16384 | Non |
fs.inotify.max_queued_events |
Le nombre maximal d'événements du système de fichiers pouvant être mis en file d'attente dans le noyau. | 16384 | Non |
fs.nr_open |
Le nombre maximal de descripteurs de fichiers qu'un seul processus peut ouvrir. Cette valeur doit être inférieure à fs.file-max. |
1048576 | Oui |
fs.may_detach_mounts |
Permet au noyau de détacher en toute sécurité un point de montage d'un namespace même s'il est toujours utilisé par un processus, empêchant ainsi le verrouillage de l'intégralité du namespace. | 1 | Non |
Paramètres réseau
Ces paramètres régissent les tampons de socket, la mise en file d'attente des connexions, la mémoire TCP et le comportement du cache ARP. Ajustez ces paramètres pour les charges de travail à fort trafic ou à haute concurrence.
| Nom du champ | Description | Valeur par défaut | Console ou API OpenAPI |
|---|---|---|---|
net.core.netdev_max_backlog |
Le nombre maximal de paquets de données pouvant être mis en file d'attente pour traitement lorsqu'une interface réseau reçoit des paquets plus rapidement que le noyau ne peut les traiter. | 16384 | Oui |
net.core.optmem_max |
La taille maximale du tampon auxiliaire pour chaque socket réseau, en octets. | 20480 | Oui |
net.core.rmem_max |
La taille maximale du tampon de réception pour chaque socket réseau, en octets. | 16777216 | Oui |
net.core.wmem_max |
La taille maximale du tampon d'envoi pour chaque socket réseau, en octets. | 16777216 | Oui |
net.core.wmem_default |
La taille par défaut du tampon d'envoi pour chaque socket réseau, en octets. | 212992 | Oui |
net.core.somaxconn |
Le nombre maximal de connexions pouvant être mises en file d'attente pour un socket en écoute, contrôlant la capacité de gestion des connexions simultanées. | 32768 | Non |
net.ipv4.tcp_mem |
La quantité de mémoire disponible pour la pile TCP, mesurée en pages mémoire (généralement 4 Ko). Ce paramètre se compose de trois valeurs entières : le seuil bas, le seuil de pression et le seuil haut. Vous devez définir ces valeurs dans l'ordre. | Calculé dynamiquement en fonction de la mémoire totale du système. | Oui |
net.ipv4.tcp_wmem |
Les tailles minimale, par défaut et maximale du tampon d'envoi TCP, en octets. Ce paramètre affecte directement le débit réseau et la consommation de mémoire des connexions TCP. | 4096 12582912 16777216 | Non |
net.ipv4.tcp_rmem |
Les tailles minimale, par défaut et maximale du tampon de réception TCP, en octets. Ce paramètre affecte directement le débit réseau et la consommation de mémoire des connexions TCP. | 4096 12582912 16777216 | Non |
net.ipv4.tcp_max_syn_backlog |
Le nombre maximal de demandes de connexion avec une poignée de main en trois temps incomplète dans la file d'attente SYN. | 8096 | Non |
net.ipv4.tcp_slow_start_after_idle |
Contrôle si une connexion TCP réintègre l'algorithme de démarrage lent après une longue période d'inactivité. | 0 | Non |
net.ipv4.ip_forward |
Active le transfert de paquets IPv4, permettant au système d'agir comme un routeur. | 1 | Non |
net.ipv4.neigh.default.gc_thresh1 |
Le nombre minimal d'entrées à conserver dans le cache ARP. Le système n'effectue pas de garbage collection si le nombre d'entrées est inférieur à cette valeur. | Préréglage du système | Oui |
net.ipv4.neigh.default.gc_thresh2 |
La limite souple du nombre maximal d'entrées dans le cache ARP. Lorsque le nombre d'entrées atteint cette valeur, le système planifie l'exécution du garbage collection après un délai de cinq secondes. | 1024 | Oui |
net.ipv4.neigh.default.gc_thresh3 |
La limite stricte du nombre maximal d'entrées dans le cache ARP. Le système effectue immédiatement le garbage collection lorsque le nombre d'entrées atteint cette valeur. Si le nombre d'entrées dépasse constamment cette limite, le processus de garbage collection s'exécute en continu. | 8192 | Oui |
net.bridge.bridge-nf-call-iptables |
Permet au trafic bridgé d'être traité par les règles iptables, garantissant l'application des politiques de sécurité réseau. | 1 | Non |
Paramètres de mémoire et du noyau
Ces paramètres contrôlent les limites des processus, le nombre de threads, le mappage mémoire et les diagnostics du noyau. Ajustez ces paramètres lorsque vos charges de travail nécessitent un grand nombre de processus ou de threads, ou lorsque vous devez adapter le comportement du noyau pour la stabilité.
| Nom du champ | Description | Valeur par défaut | Console ou API OpenAPI |
|---|---|---|---|
kernel.pid_max |
L'identifiant de processus (PID) maximal que le système peut attribuer. | 4194303 | Oui |
kernel.threads-max |
Le nombre maximal de threads que le système peut créer. | 504581 | Oui |
kernel.softlockup_panic |
Lorsqu'il est activé, le noyau déclenche un panic et redémarre le système en cas de soft lockup, permettant au système de restaurer rapidement son état. | 1 | Non |
kernel.softlockup_all_cpu_backtrace |
Lorsqu'il est activé, capture les informations de débogage de tous les processeurs lorsqu'un soft lockup est détecté, facilitant ainsi les diagnostics. | 1 | Non |
vm.max_map_count |
Le nombre maximal de zones de mappage mémoire qu'un seul processus peut avoir. Limite l'utilisation excessive de la mémoire. | 262144 | Non |
user.max_user_namespaces |
Le nombre maximal de namespaces utilisateur qu'un seul utilisateur peut créer. | 0 | Oui |
Liste des paramètres THP
Transparent Huge Pages (THP) est une fonctionnalité du noyau Linux qui fusionne automatiquement les petites pages mémoire (généralement 4 Ko) en pages plus grandes (généralement 2 Mo ou plus). Ce processus réduit la surcharge des entrées de table de pages (PTE) et le nombre d'accès mémoire, diminuant ainsi la pression sur le Translation Lookaside Buffer (TLB) et améliorant l'efficacité des accès mémoire.
Tous les paramètres suivants peuvent être configurés via la console ACK ou l'API OpenAPI.
Les valeurs par défaut de ces paramètres varient selon le système d'exploitation et la version du noyau. Pour plus d'informations, consultez la documentation relative aux paramètres THP du noyau Linux.
| Nom du champ | Description | Valeurs possibles |
|---|---|---|
transparent_enabled |
Contrôle si THP est activé globalement. |
- - - |
transparent_defrag |
Contrôle si le noyau effectue une défragmentation de la mémoire pour créer des huge pages. Lorsqu'il est activé, le système peut fusionner de petites pages en une seule huge page, ce qui réduit la taille de la table des pages et améliore les performances. |
- - - - - |
khugepaged_defrag |
khugepaged est un thread du noyau qui gère et fusionne les huge pages pour réduire la fragmentation de la mémoire et améliorer les performances. Il recherche des huge pages dispersées et les fusionne en blocs contigus, améliorant ainsi l'utilisation de la mémoire. Comme ce processus implique des opérations de verrouillage dans le chemin d'accès à la mémoire et que le thread du noyau khugepaged peut scanner et convertir des pages à des moments inopportuns, il peut potentiellement affecter les performances des applications. |
- - |
khugepaged_alloc_sleep_millisecs |
Le temps, en millisecondes, pendant lequel le thread du noyau khugepaged attend avant la prochaine tentative d'allocation de huge page après un échec. Cela évite les échecs d'allocation répétés sur une courte période. |
Pour plus d'informations, consultez la rubrique Défragmentation khugepaged. |
khugepaged_scan_sleep_millisecs |
L'intervalle, en millisecondes, entre chaque réveil du thread du noyau khugepaged pour scanner la mémoire. |
|
khugepaged_pages_to_scan |
Le nombre de pages mémoire que le thread du noyau khugepaged scanne à chaque réveil. |