Cgroups

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Unified hierarchy cgroups et systemd.

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

Ce travail a débuté par des ingénieurs de Google (d'abord par 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ées.

Fonctionnalités[modifier | modifier le code]

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:

  • La Limitation des Ressources: des groupes peuvent être mis en place afin de ne pas dépasser une limite de memory — cela inclut aussi le file system cache[3]. L'article original a été présenté au Linux Symposium et peut être trouvé à Containers: Challenges with the memory resource controller and its performance[4]
  • La Priorisation: certains groupes peuvent obtenir une plus grande part de 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 connections réseaux ou leurs fichiers[2].
  • Contrôle: figer les groupes ou créer un point de sauvegarde et redémarrer[7].

Utilisation[modifier | modifier le code]

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 à ce 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 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[8], libvirt, systemd, Open Grid Scheduler/Grid Engine[9].

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

Isolation par espace de nommage[modifier | modifier le code]

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 lequel 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 du 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[11].
  • 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" [12].
  • 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[13].
  • 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 "cloné"[14].

Articles connexes[modifier | modifier le code]

Références[modifier | modifier le code]

  1. (en) Jonathan Corbet, « Process containers », LWN.net,‎ 29 mai 2007
  2. a, b et c (en) Jonathan Corbet, « Notes from a container », LWN.net,‎ 29 oct. 2007
  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,‎ juillet 2007
  5. (en) Jonathan Corbet, « Kernel space: Fair user scheduling for Linux », Network World,‎ 23 oct. 2007 (consulté le 22 août 2012)
  6. (en) Kamkamezawa Hiroyu (19 nov. 2008). « Cgroup and Memory Resource Controller » (PDF presentation slides) Japan Linux Symposium , Japan Linux Symposium. 
  7. a et b (en) Dave Hansen. « Resource Management » (PDF presentation slides) Linux Foundation , Linux Foundation. 
  8. (en) Matt Helsley, « LXC: Linux container tools », IBM developerWorks,‎ 3 fé. 2009
  9. (en) « Grid Engine cgroups Integration », Scalable Logic,‎ 22 mai 2012
  10. http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
  11. (en) Pavel Emelyanov, Kir Kolyshkin, « PID namespaces in the 2.6.24 kernel », LWN.net,‎ 19 nov. 2007
  12. (en) Jonathan Corbet, « Network namespaces », LWN.net,‎ 30 janv. 2007
  13. (en) Serge E. Hallyn, Ram Pai, « Applying mount namespaces », IBM developerWorks,‎ 17 sept. 2007
  14. (en) Janak Desai, « Linux kernel documentation on unshare »,‎ 11 janv. 2006

Lien externe[modifier | modifier le code]