Introduction aux cgroups

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 Je me base ici sur Red Hat.

Les control groups, ou cgroups, sont une fonctionnalité du noyau Linux permettant d'allouer des ressources (CPU, RAM, Réseau, stockage... ou une combinaison de ceux-ci) parmi des groupes de processus (appellés tâches dans le cadre des cgroups). Cela nous permet de contrôler finement l'utilisation des ressources.

Organisation des cgroups

Organisation des processus

Les processus sur Linux sont tous parents d'un seul : le processus init, exécuté par le kernel au boot et qui lance les autres (qui peuvent à leur tour lancer des processus). Les processus Linux sont en un arbre unique. Chaque processus hérite de l'environnement de son parent.

Le modèle des cgroups

Les cgroups sont similaires au processus en ce que:

Ils sont hiérarchisés
Ils héritent des choses de leurs parents.

La différence fondamentale est que plusieurs hiérarchies de cgroups peuvent exister simultanément sur un système. Ces hiérarchies séparées sont nécessaires car chaque hiérarchie est attachées à un ou plusieurs sous-systèmes, chacun représente une ressource. Red Hat 6 fournit 10 sous-systèmes :

blkio : I/O vers et depuis les block devices
cpu : accès au scheduler pour fournir de l'accès CPU
cpuacct : Rapport des ressources CPU utilisées par les tâches d'un cgroup
cpuset : Assignes des des cpu (dans un environnement multithreadé) et des noeuds mémoire aux tâches d'un cgroup
devices : contrôle d'accès aux appareils
freezer : suspendre ou reprendre des tâches
memory : mettre des limites à l'utilisation mémoire des tâches ét générer des rapports
net_cls : tague les paquets réseau avec un identifiant de classe afin que le contrôleur de trafic Linux (tc) identifie les paquets venant d'une certaine tâche
net_prio : fournit dynamiquement la priorité des paquets par interface réseau
ns : le sous-système de namespace
perf_event : identifie quel tasks appartient à quel cgroup et permet des analyses de performances.

Pour ces sous-systèmes, on parle parfois de resource controller ou simplement de controler.

Relation entre subsystem, hiérarchies, control group et tasks

Quelques règles simples.

Une seule hiérarchie peut avoir un ou plusieurs sous-systèmes.

Un subsystem ne peut pas être attaché à plus d'une hiérarchie si l'une de ces hiérarchies a déjà un autre subsystem d'attaché à elle.

Chaque fois qu'une hiérarchie est créée sur un système, toutes les tâches du systèmes sont initialement membres du cgroup par défaut de la hiérarchie (connu comme le root cgroup). Pour chaque hiérarchie créée, chaque tâche du système peut être membre d'exactement un seul cgroup de la hiérarchie.Une seule tâche peut donc être dans plusieurs cgroups, tant que ces cgroups ne sont pas dans la même hiérarchie : si une tâche devient membre d'un autre cgroup d'une hiérarchie, elle est automatiquement enlevée du premier.

N'importe quel processus qui se forke lui-même créée une tâche enfant. Celle-ci hérite des cgroups du parents mais peut être déplacée. Une fois forkés, parent et enfants sont indépendants.

Implications en terme de contrôle de ressources

Puisqu'une tâche ne peut appartenir qu'à un seul cgroup par hiérarchie, il n'y a qu'un seul moyen de contrôler ou influer sur cette tâche. C'est une feature, pas une limitation.
On peut grouper plusieurs sous systèmes afin qu'ils affectent toutes les tâches dans une seule hiérarchie. Puisque les cgroups de cette hiérarchie ont différents paramètres, ces tâches seront affectées différement.
Il faut parfois "refactorer" une hiérarchie, par ex. en enlevant un subsystem d'une hiérarchie qui en a plusieurs et en l'attachant ailleurs.
On peut aussi faire l'inverse et converger les subsystems
Ce design permet une utilisation simple. On peut setter quelques paramètres pour des tâches spécifiques dans une seule hiérarchie, telle qu'une avec juste cpu et memory.
Ce deisgn permet aussi une configuration hautement spécifique. Chaque tâche peut être membre de toutes les hiérarchies avec avec pour chaque hiérarchie un seul subsystem d'attaché. On donne ainsi le contrôle absolu pour chacune des tâches.

Cgroups

Sommaire