Utiliser 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. Pour les besoins de la discussion, les exemples de la liste se concentrent sur le contrôleur de CPU.

Système (system.slice)

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

Comme indiqué dans l'exemple de graphique à secteurs précédent, la tranche système est divisée en autres sous-tranches. Par exemple, dans le cas de ressources CPU, nous pouvons disposer d'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 les services d'application personnalisés qui peuvent s'exécuter sur le système.

Utilisateur (user.slice)

Cette tranche de ressource est utilisée pour gérer l'allocation des ressources entre les sessions utilisateur. Une tranche unique 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 invités KVM et les conteneurs Linux. La tranche de machine n'est présente sur un serveur que si ce dernier héberge des machines virtuelles ou des conteneurs Linux.

L'analogie des graphiques à secteurs utilisée dans les sections précédentes permet de conceptualiser la division des ressources en tranches. Cependant, en termes d'organisation structurelle, les groupes de contrôle sont organisés dans une hiérarchie. Vous pouvez afficher la hiérarchie de 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 avec ses propres sous-tranches enfant cgroup.

En examinant la sortie de la commande systemd-cgls , vous pouvez voir comment, à l'exception de root -.slice, tous les processus se trouvent sur des noeuds feuille. Cette disposition est appliquée par cgroups v2, dans une règle appelée règle "aucun processus interne". Pour plus d'informations sur la règle "aucun processus interne", reportez-vous à la page cgroups (7).

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

La portée systemd est un type d'unité systemd qui regroupe les processus actifs de service système qui ont été lancés indépendamment de systemd. Les unités de portée sont des unités cgroups transitoires créées 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 indique que session-2.scope a été créé pour les processus que l'utilisateur a générés 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)