Gestion des cgroups avec systemd

Dans ce dernier volet de ma série d'articles en quatre parties sur les groupes de contrôle, j'aborde l'intégration des groupes de contrôle avec systemd. Assurez-vous également de consulter les parties un, deux et trois de la série.

Cgroups avec systemd

Par défaut, systemd crée un nouveau groupe de contrôle sous le system.slice pour chaque service qu'il surveille. Revenons à notre hôte OpenShift Control Plane, en exécutant systemd-cgls montre les services suivants sous le system.slice (la sortie est tronquée par souci de brièveté) :

└─system.slice
  ├─sssd.service
  ├─lvm2-lvmetad.service
  ├─rsyslog.service
  ├─systemd-udevd.service
  ├─systemd-logind.service
  ├─systemd-journald.service
  ├─crond.service
  ├─origin-node.service
  ├─docker.service
  ├─dnsmasq.service
  ├─tuned.service
  ├─sshd.service
  ├─NetworkManager.service
  ├─dbus.service
  ├─polkit.service
  ├─chronyd.service
  ├─auditd.service
    └─getty@tty1.service

Vous pouvez modifier ce comportement en modifiant le fichier de service systemd. Il existe trois options concernant la gestion des groupes de contrôle avec systemd :

Modifier le fichier de service lui-même.
Utilisation de fichiers d'insertion.
Utilisation de systemctl set-property commandes, qui sont les mêmes que l'édition manuelle des fichiers, mais systemctl crée les entrées requises pour vous.

Je les couvre plus en détail ci-dessous.

Modification des fichiers de service

Modifions le fichier d'unité lui-même. Pour ce faire, j'ai créé un fichier unité très simple qui exécute un script :

[Service]
Type=oneshot
ExecStart=/root/generate_load.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Le script bash n'a que deux lignes :

#!/bin/bash
/usr/bin/cat /dev/urandom > /dev/null &

Lorsque vous examinez la sortie de systemd-cgls , vous voyez que notre nouveau service est imbriqué sous le system.slice (sortie tronquée):

└─system.slice
  ├─cat.service
  ├─tuned.service
  ├─sshd.service
  ├─NetworkManager.service
  ├─sssd.service
  ├─dbus.service
  │ └─getty@tty1.service
  └─systemd-logind.service

Que se passe-t-il si j'ajoute la ligne suivante au fichier de service systemd ?

Slice=my-beautiful-slice.slice

La sortie de systemd-cgls montre quelque chose de curieux. Le cat.service le fichier est maintenant profondément imbriqué :

Control group /:
├─my.slice
│ └─my-beautiful.slice
│   └─my-beautiful-slice.slice
│     └─cat.service
│       └─4010 /usr/bin/cat /dev/urandom

Pourquoi est-ce? La réponse a à voir avec la façon dont systemd interprète les cgroups imbriqués. Les enfants sont déclarés de la manière suivante :-.slice . Étant donné que systemd tente d'être utile, si un parent n'existe pas, systemd le crée pour vous. Si j'avais utilisé des traits de soulignement _ au lieu de tirets - le résultat aurait été ce à quoi vous vous attendiez :

Control group /:
├─my_beautiful_slice.slice
│ └─cat.service
│   └─4123 /usr/bin/cat /dev/urandom

Utiliser des fichiers d'insertion

Les fichiers d'insertion pour systemd sont assez simples à configurer. Commencez par créer un répertoire approprié basé sur le nom de votre service dans /etc/systemd/system . Dans le cat exemple, exécutez la commande suivante :

# mkdir -p /etc/systemd/system/cat.service.d/

Ces fichiers peuvent être organisés comme bon vous semble. Ils sont actionnés en fonction de l'ordre numérique, vous devez donc nommer vos fichiers de configuration quelque chose comme 10-CPUSettings.conf . Tous les fichiers de ce répertoire doivent avoir l'extension de fichier .conf et vous obliger à exécuter systemctl daemon-reload chaque fois que vous ajustez l'un de ces fichiers.

J'ai créé deux fichiers d'insertion pour montrer comment vous pouvez diviser différentes configurations. Le premier est 00-slice.conf . Comme on le voit ci-dessous, il configure les options par défaut pour une tranche distincte pour le cat service :

[Service]
Slice=AWESOME.slice
MemoryAccounting=yes
CPUAccounting=yes

L'autre fichier définit le nombre de CPUShares, et il s'appelle 10-CPUSettings.conf .

[Service]
CPUShares=256

Pour montrer que cette méthode fonctionne, je crée un deuxième service dans la même tranche. Pour faciliter la distinction des processus, le deuxième script est légèrement différent :

#!/bin/bash
/usr/bin/sha256sum /dev/urandom > /dev/null &

J'ai ensuite simplement créé des copies du cat fichiers, en remplaçant le script et en modifiant la valeur CPUShares :

# sed 's/load\.sh/load2\.sh/g' cat.service > sha256sum.service
# cp -r cat.service.d sha256sum.service.d
# sed -i 's/256/2048/g' sha256sum.service.d/10-CPUSettings.conf

Enfin, rechargez le démon et démarrez les services :

# systemctl daemon-reload
# systemctl start cat.service
# systemctl start sha256sum.service

[ Les lecteurs ont également aimé :Que se passe-t-il dans les coulisses d'un conteneur Podman sans racine ? ]

Au lieu de vous montrer la sortie de top , c'est le bon moment pour vous présenter systemd-cgtop . Cela fonctionne de la même manière que top normal sauf qu'il vous donne une ventilation par tranche, puis à nouveau par services dans chaque tranche. Ceci est très utile pour déterminer si vous faites bon usage des cgroups en général sur votre système. Comme on le voit ci-dessous, systemd-cgtop montre à la fois l'agrégation de tous les services dans une tranche particulière dans le cadre du système global et l'utilisation des ressources de chaque service dans une tranche :

Utilisation de la propriété set-systemctl

La dernière méthode qui peut être utilisée pour configurer les cgroups est la systemctl set-property commande. Je vais commencer par un fichier de service de base md5sum.service :

[Service]
Type=oneshot
ExecStart=/root/generate_load3.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
Slice=AWESOME.slice

[Install]
WantedBy=multi-user.target

Utilisation de la systemctl set-property La commande place les fichiers dans /etc/systemd/system.control . Ces fichiers ne doivent pas être édités à la main. Toutes les propriétés ne sont pas reconnues par le set-property commande, donc la Slice la définition a été placée dans le fichier de service lui-même.

Après avoir configuré le fichier d'unité et rechargé le démon, j'utilise le systemctl commande similaire à la suivante :

# systemctl set-property md5sum.service CPUShares=1024

Cela crée un fichier d'insertion pour vous situé dans /etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf . N'hésitez pas à consulter les fichiers si vous êtes curieux de connaître leur contenu. Comme ces fichiers ne sont pas destinés à être modifiés à la main, je ne passerai pas de temps dessus.

Vous pouvez tester pour voir si les modifications ont pris effet en exécutant :

systemctl start md5sum.service cat.service sha256sum.service

Comme vous le voyez dans la capture d'écran ci-dessous, les modifications semblent avoir réussi. sha256sum.service est configuré pour 2048 CPUShares, tandis que md5sum.service a 1024. Enfin, cat.service a 256.

[ Vous pensez à la sécurité ? Consultez ce guide gratuit pour renforcer la sécurité du cloud hybride et protéger votre entreprise. ]

Récapitulez

J'espère que vous avez appris quelque chose de nouveau tout au long de notre voyage ensemble. Il y avait beaucoup à faire, et nous avons à peine effleuré ce qui est possible avec les cgroups. Outre le rôle que jouent les cgroups dans le maintien de votre système en bonne santé, ils jouent également un rôle dans une stratégie de "défense en profondeur". De plus, les cgroups sont un composant essentiel des charges de travail Kubernetes modernes, où ils contribuent au bon fonctionnement des processus conteneurisés. Les Cgroups sont responsables de tant de choses, notamment :

Limiter les ressources des processus.
Déterminer les priorités en cas de conflit
Contrôler l'accès aux appareils en lecture/écriture et mknod
Fournir un haut niveau de comptabilité pour les processus qui s'exécutent sur un système.

On pourrait dire que la conteneurisation, Kubernetes et une foule d'autres implémentations critiques pour l'entreprise ne seraient pas possibles sans tirer parti des cgroups.

Si vous avez des questions ou des commentaires ou peut-être d'autres idées d'articles, n'hésitez pas à me contacter sur Twitter. J'ai hâte d'entendre tous vos commentaires.

Sources

https://0xax.gitbooks.io/linux-insides/content/Cgroups/linux-cgroups-1.html
https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups -cgroups
https://itnext.io/chroot-cgroups-and-namespaces-an-overview-37124d995e3d
https://www.certdepot.net/rhel7-get-started-cgroups/
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/chap-introduction_to_control_groups
https://oakbytes.wordpress.com/2012/09/02/ cgroup-cpu-allocation-cpu-shares-examples/
https://www.redhat.com/en/blog/world-domination-cgroups-part-1-cgroup-basics
https:/ /www.redhat.com/en/blog/world-domination-cgroups-rhel-8-welcome-cgroups-v2
https://youtu.be/z7mgaWqiV90
https://youtu.be /el7768BNUPw
https://youtu.be/sK5i-N34im8
https://youtu.be/_AODvcO5Q_8
https://youtu.be/x1npPrzyKfs
https:/ /youtu.be/yZpNsDe4Qzg
https://access.redhat.com/solutions/4489171