cgroups (control groups) est une fonctionnalité du noyau Linux pour limiter, compter et isoler l'utilisation des ressources (processeur, mémoire, utilisation disque, etc.).

Unified hierarchy cgroups et systemd.

Ce travail a été initié par des ingénieurs de Google (d'abord Paul Menage et Rohit Seth) en 2006 sous le nom « conteneur de processus[1]» ; à la fin 2007, il a été renommé Control Groups (à cause de la confusion causée par les différentes significations du terme « conteneur » dans le noyau Linux) et intégré à la version 2.6.24 du noyau Linux[2]. Depuis lors, de nombreuses nouvelles fonctionnalités et contrôleurs ont été ajoutés.

Fonctionnalités modifier

L'un des buts de la conception de cgroups a été de fournir une interface unifiée à différents cas d'utilisation, en allant du contrôle de simples processus (comme nice) à la virtualisation au niveau du système d'exploitation (comme OpenVZ, Linux-VServer, LXC). Cgroups fournit :

  • Limitation des ressources : des groupes peuvent être mis en place afin de ne pas dépasser une limite de mémoire — cela inclut aussi le cache du système de fichier (en)[3]. L'article original a été présenté au Linux Symposium et s'intitule Containers: Challenges with the memory resource controller and its performance[4]
  • Priorisation : certains groupes peuvent obtenir une plus grande part de ressources processeur [5] ou de bande passante d'entrée-sortie[6].
  • Comptabilité : permet de mesurer la quantité de ressources consommées par certains systèmes en vue de leur facturation par exemple[7].
  • Isolation : séparation par espace de nommage pour les groupes, afin qu'ils ne puissent pas voir les processus des autres, leurs connexions réseaux ou leurs fichiers[2].
  • Contrôle : figer les groupes ou créer un point de sauvegarde et redémarrer[7].

Utilisation modifier

Un groupe de contrôle est une suite de processus qui sont liés par le même critère. Ces groupes peuvent être organisés hiérarchiquement, de façon que chaque groupe hérite des limites de son groupe parent. Le noyau fournit l'accès à plusieurs contrôleurs (sous-systèmes) à travers l'interface cgroup[2]. Par exemple, le contrôleur « memory » limite l'utilisation de la mémoire, « cpuacct » comptabilise l'utilisation du processeur, etc.

Les Control groups peuvent être utilisés de plusieurs façons :

  • En accédant au système de fichier virtuel cgroup manuellement en utilisant la commande mount[8]
  • En créant et gérant des groupes à la volée en utilisant des outils tels que cgcreate, cgexec, cgclassify (de libcgroup)
  • Le « démon de moteur de règles » qui peut automatiquement déplacer les processus de certains utilisateurs, groupes ou commandes vers un cgroup en respectant ce qui est spécifié dans la configuration.
  • Indirectement à travers d'autres logiciels qui utilisent cgroups, tels que la virtualisation LXC[9], libvirt, systemd, Open Grid Scheduler/Grid Engine[10].

La documentation du noyau Linux [11] contient de nombreux détails sur l'installation et l'utilisation des groupes de contrôle.

Isolation par espace de nommage modifier

Bien que ne faisant pas techniquement partie du travail des groupes de contrôle, une fonctionnalité liée est l’isolation par espace de nommage, dans laquelle des ensembles de processus sont séparés de telle façon qu'ils ne puissent pas « voir » les ressources des autres groupes. Par exemple, un espace de nommage par identifiant de processus (PID) fournit un ensemble distinct d'identifiants de processus dans chaque espace de nommage. Sont aussi disponibles des espaces de nommage par mount, UTS, réseau et SysV IPC. Très tôt dans le développement des groupes de contrôle, le sous-système « ns » a été ajouté, pour intégrer les espaces de nommage et les groupes de contrôle. Si le groupe de contrôle « ns » était monté, chaque espace de nommage aurait dû aussi créer un nouveau groupe dans la hiérarchie des groupes de nommage. Ce fut une tentative qui fut jugée plus tard peu adaptée pour l'API cgroups, et supprimée du noyau.

  • L'espace de nommage par identifiant de processus (PID namespace) fournit l'isolation pour l'allocation des identifiants de processus (PIDs), la liste des processus et de leurs détails. Tandis que le nouvel espace de nom est isolé de ses adjacents, les processus dans son espace de nommage « parent » voient toujours tous les processus dans les espaces de nommage enfants — quoique avec des numéros de PID différents[12].
  • L'espace de nommage réseau (Network namespace) isole le contrôleur de l'interface réseau (physique ou virtuel), les règles de pare-feu iptables, les tables de routage, etc. Les espaces de nommage réseau peuvent être connectés les uns avec chacun des autres en utilisant le périphérique virtuel Ethernet « veth »[13].
  • L'espace de nommage « UTS » (“UTS” namespace) permet le changement de nom d'hôte.
  • L'espace de nommage de montage (Mount namespace) permet de créer différents modèles de systèmes de fichiers, ou de créer certains points de montage en lecture-seule[14].
  • L'espace de nommage IPC (IPC namespace) isole le System V de communication inter-processus entre les espaces de nommage.

Les espaces de nom sont créés avec la commande « unshare » ou un appel système, ou en tant que nouveaux marqueurs dans un appel système « clone »[15].

Références modifier

  1. (en) Jonathan Corbet, « Process containers », LWN.net,
  2. a b et c (en) Jonathan Corbet, « Notes from a container », LWN.net,
  3. (en) Jonathan Corbet, « Controlling memory use in containers », LWN, 31 juil. 31 juillet 2007
  4. [PDF] (en) Balbir Singh et Vaidynathan Srinivasan, « Containers: Challenges with the memory resource controller and its performance », Ottawa Linux Symposium,
  5. (en) Jonathan Corbet, « Kernel space: Fair user scheduling for Linux », Network World, (consulté le )
  6. (en) Kamkamezawa Hiroyu « Cgroup and Memory Resource Controller » () (lire en ligne) Modèle:PDF presentation slides
  7. a et b (en) Dave Hansen « Resource Management » (lire en ligne) Modèle:PDF presentation slides
  8. Cyril Zarak, « Utilisation des cgroups v1 »,
  9. (en) Matt Helsley, « LXC: Linux container tools », IBM developerWorks, 3 fé. 2009
  10. (en) « Grid Engine cgroups Integration », Scalable Logic,
  11. http://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
  12. (en) Pavel Emelyanov, Kir Kolyshkin, « PID namespaces in the 2.6.24 kernel », LWN.net,
  13. (en) Jonathan Corbet, « Network namespaces », LWN.net,
  14. (en) Serge E. Hallyn, Ram Pai, « Applying mount namespaces », IBM developerWorks,
  15. (en) Janak Desai, « Linux kernel documentation on unshare »,

Annexes modifier

Articles connexes modifier

Lien externe modifier