Utilisation de Systemd pour gérer les groupes de contrôle

Cette section examine la façon dont systemd divise initialement chacun des contrôleurs de noyau par défaut, par exemple CPU, memory et blkio, en parties appelées "tranches", comme illustré par l'exemple de graphique à secteurs suivant :

Comme le montre le graphique à secteurs précédent, chaque contrôleur de ressources est divisé par défaut de manière égale entre les 3 tranches suivantes :

• Système (system.slice).

• Utilisateur (user.slice).

• Machine (machine.slice).

La liste suivante examine chaque tranche de plus près. À des fins de discussion, les exemples de la liste se concentrent sur le contrôleur CPU.

Système (system.slice)

Cette tranche de ressource est utilisée pour gérer l'affectation des ressources entre les démons et les unités de service.

Comme le montre l'exemple précédent de graphique à secteurs, le fragment de système est divisé en sous-tranches supplémentaires. Par exemple, dans le cas de ressources d'UC, nous pouvons avoir des allocations de sous-tranches dans la tranche système qui incluent les éléments suivants :

• httpd.service (CPUWeight=100)

• sshd.service (CPUWeight =100)

• crond.service (CPUWeight =100)

• app1.service (CPUWeight =100)

• app2.service (CPUWeight =100)

Dans la liste précédente, app1.service et app2.service représentent des services d'application personnalisés pouvant s'exécuter sur le système.

Utilisateur (user.slice)

Cette tranche de ressource est utilisée pour gérer l'allocation de ressources entre les sessions d'utilisateur. Une seule tranche est créée pour chaque UID, quel que soit le nombre de connexions actives par l'utilisateur associé sur le serveur. En continuant avec notre exemple de graphique à secteurs, les sous-tranches peuvent être les suivantes :

• user1 (CPUWeight=100, UID=982)

• user2 (CPUWeight=100, UID=1001)

Machine (machine.slice)

Cette tranche de la ressource est utilisée pour gérer l'allocation des ressources entre les machines virtuelles hébergées, telles que les clients KVM et les conteneurs Linux. La tranche de machine n'est présente sur un serveur que si le serveur héberge des machines virtuelles ou des conteneurs Linux.

L'analogie des graphiques à secteurs utilisée dans les sections précédentes est un moyen utile de conceptualiser la division des ressources en tranches. Cependant, en termes d'organisation structurelle, les groupes de contrôle sont organisés en une hiérarchie. Vous pouvez voir la hiérarchie du groupe de contrôle systemd sur le système en exécutant la commande systemd-cgls comme suit :

systemd-cgls

Control group /:
-.slice
...
├─user.slice (#1429)
│ → user.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
│ ├─user-982.slice (#4131)
│ │ → user.invocation_id: 9d0d94d7b8a54bcea2498048911136c8
│ │ ├─session-c1.scope (#4437)
│ │ │ ├─2416 /usr/bin/sudo -u ocarun /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
│ │ │ └─2494 /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
│ │ └─user@982.service … (#4199)
│ │   → user.delegate: 1
│ │   → user.invocation_id: 37c7aed7aa6e4874980b79616acf0c82
│ │   └─init.scope (#4233)
│ │     ├─2437 /usr/lib/systemd/systemd --user
│ │     └─2445 (sd-pam)
│ └─user-1001.slice (#7225)
│   → user.invocation_id: ce93ad5f5299407e9477964494df63b7
│   ├─session-2.scope (#7463)
│   │ ├─20304 sshd: oracle [priv]
│   │ ├─20404 sshd: oracle@pts/0
│   │ ├─20405 -bash
│   │ ├─20441 systemd-cgls
│   │ └─20442 less
│   └─user@1001.service … (#7293)
│     → user.delegate: 1
│     → user.invocation_id: 70284db060c1476db5f3633e5fda7fba
│     └─init.scope (#7327)
│       ├─20395 /usr/lib/systemd/systemd --user
│       └─20397 (sd-pam)
├─init.scope (#19)
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 28
└─system.slice (#53)
 ...
  ├─dbus-broker.service (#2737)
  │ → user.invocation_id: 2bbe054a2c4d49809b16cb9c6552d5a6
  │ ├─1450 /usr/bin/dbus-broker-launch --scope system --audit
  │ └─1457 dbus-broker --log 4 --controller 9 --machine-id 852951209c274cfea35a953ad2964622 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
 ...
  ├─chronyd.service (#2805)
  │ → user.invocation_id: e264f67ad6114ad5afbe7929142faa4b
  │ └─1482 /usr/sbin/chronyd -F 2
  ├─auditd.service (#2601)
  │ → user.invocation_id: f7a8286921734949b73849b4642e3277
  │ ├─1421 /sbin/auditd
  │ └─1423 /usr/sbin/sedispatch
  ├─tuned.service (#3349)
  │ → user.invocation_id: fec7f73678754ed687e3910017886c5e
  │ └─1564 /usr/bin/python3 -Es /usr/sbin/tuned -l -P
  ├─systemd-journald.service (#1837)
  │ → user.invocation_id: bf7fb22ba12f44afab3054aab661aedb
  │ └─1068 /usr/lib/systemd/systemd-journald
  ├─atd.service (#3961)
  │ → user.invocation_id: 1c59679265ab492482bfdc9c02f5eec5
  │ └─2146 /usr/sbin/atd -f
  ├─sshd.service (#3757)
  │ → user.invocation_id: 57e195491341431298db233e998fb180
  │ └─2097 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─crond.service (#3995)
  │ → user.invocation_id: 4f5b380a53db4de5adcf23f35d638ff5
  │ └─2150 /usr/sbin/crond -n
  ...

L'exemple de sortie précédent montre comment tous les groupes de contrôle "*.slice" résident sous la tranche racine -.slice. Sous la tranche racine, vous pouvez voir les groupes de contrôle user.slice et system.slice, chacun ayant ses propres sous-tranches enfants cgroup.

En examinant la sortie de la commande systemd-cgls , vous pouvez voir comment, à l'exception de la racine -.slice, tous les processus se trouvent sur des noeuds feuilles. Cet arrangement est appliqué par cgroups v2, dans une règle appelée règle "aucun processus interne". Voir cgroups (7) pour plus d'informations sur la règle "aucun processus interne".

La sortie de l'exemple de commande systemd-cgls précédent montre également comment les tranches peuvent avoir des groupes de contrôle enfants descendants qui sont des portées systemd. Les portées systemd sont vérifiées dans la section suivante.

La portée systemd est un type d'unité systemd qui regroupe les processus de traitement de service système lancés indépendamment de systemd. Les unités de portée sont des cgroups transitoires créés par programmation à l'aide des interfaces de bus de systemd.

Par exemple, dans l'exemple de code suivant, l'utilisateur avec UID 1001 a exécuté la commande systemd-cgls et la sortie affiche session-2.scope a été créé pour les processus que l'utilisateur a générés dynamiquement indépendamment de systemd (y compris le processus pour la commande elle-même, 21380 sudo systemd-cgls) :

sudo systemd-cgls

Working directory /sys/fs/cgroup:
...
├─user.slice (#1429)
│ → user.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
│ → trusted.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
...
│ └─user-1001.slice (#7225)
│   → user.invocation_id: ce93ad5f5299407e9477964494df63b7
│   → trusted.invocation_id: ce93ad5f5299407e9477964494df63b7
│   ├─session-2.scope (#7463)
│   │ ├─20304 sshd: oracle [priv]
│   │ ├─20404 sshd: oracle@pts/0
│   │ ├─20405 -bash
│   │ ├─21380 sudo systemd-cgls
│   │ ├─21382 systemd-cgls
│   │ └─21383 less
│   └─user@1001.service … (#7293)
│     → user.delegate: 1
│     → trusted.delegate: 1
│     → user.invocation_id: 70284db060c1476db5f3633e5fda7fba
│     → trusted.invocation_id: 70284db060c1476db5f3633e5fda7fba
│     └─init.scope (#7327)
│       ├─20395 /usr/lib/systemd/systemd --user
│       └─20397 (sd-pam)