Les ordinateurs sont du matériel. Et aujourd'hui, nous sommes revenus au point de départ, dans le sens où vous trouvez maintenant rarement un hôte physique sur lequel une seule tâche est effectuée. Même si une seule application est en cours d'exécution sur le serveur, elle se compose très probablement de plusieurs processus, conteneurs ou même machines virtuelles (VM), et elles fonctionnent toutes sur le même serveur. Red Hat Enterprise Linux 7 s'adapte bien à la distribution des ressources système dans de telles situations, mais par défaut, il se comporte comme une gentille grand-mère, traitant ses petits-enfants avec un gâteau fait maison et disant: "De manière égale à tout le monde, également à tout le monde."
En théorie, le principe du "partage égal" est bien sûr beau, mais dans la pratique, certains processus, conteneurs ou VM sont plus importants que d'autres, et devraient donc en recevoir plus.
Linux possède depuis longtemps des outils de gestion des ressources (nice, ulimit, etc.), mais avec l'avènement de Red Hat Enterprise Linux 7 et systemd, nous avons enfin un ensemble puissant de tels outils intégrés dans le système d'exploitation lui-même. Le fait est que le composant clé de systemd est un ensemble de cgroups prêt à l'emploi et entièrement utilisé au niveau du système d'exploitation.
Eh bien, quels types de groupes de contrôle sont-ils, et où va la gestion des ressources ou des performances?
Contrôle au niveau du noyau
À partir de la version 2.6.24, publiée en janvier 2008, le noyau Linux est apparu qui a été initialement inventé et créé dans Google sous le nom de «conteneurs de processus», et sous Linux, il est devenu connu sous le nom de «groupes de contrôle», abrégés cgroups. En bref, cgroups est un mécanisme de noyau qui vous permet de limiter l'utilisation, de conserver des enregistrements et d'isoler la consommation des ressources système (CPU, mémoire, E / S disque, réseau, etc.) au niveau des collections de processus. Les groupes de contrôle peuvent également geler les processus de vérification et de redémarrage. Les contrôleurs Cgroups sont apparus pour la première fois dans la version 6 de Red Hat Enterprise Linux, mais ils ont dû être configurés manuellement. Mais avec l'avènement de Red Hat Enterprise Linux 7 et de systemd, l'ensemble préconfiguré de cgroups est fourni avec le système d'exploitation.
Tout cela fonctionne au niveau du noyau du système d'exploitation et garantit donc un contrôle strict sur chaque processus. Il est donc extrêmement difficile pour un logiciel malveillant de charger le système afin qu'il cesse de répondre et se bloque. Bien sûr, le code bogué avec un accès direct au matériel (par exemple, les pilotes) est toujours capable de cela. En même temps, Red Hat Enterprise Linux 7 fournit une interface pour interagir avec les cgroups, et tout le travail avec eux se fait principalement via la commande systemd.
Votre morceau de gâteau
Le diagramme ci-dessous, qui rappelle une tarte en tranches, montre trois groupes de contrôle qui sont par défaut sur le serveur Red Hat Enterprise Linux 7 - Système, Utilisateur et Machine. Chacun de ces groupes est appelé «tranche» (secteur de tranche). Comme vous pouvez le voir sur la figure, chaque tranche peut avoir des secteurs de découpe enfants. Et, comme dans le cas du gâteau, au total, toutes les tranches donnent 100% de la ressource correspondante.
Examinons maintenant plusieurs concepts de cgroups en utilisant les ressources du processeur comme exemple.
La figure ci-dessus montre que le temps du processeur est également réparti entre les trois tranches de niveau supérieur (système, utilisateur et machine). Mais cela ne se produit que sous charge. Si un processus de la tranche Utilisateur demande 100% des ressources du processeur et que personne d'autre n'a besoin de ces ressources pour le moment, il recevra l'intégralité du temps du processeur.
Chacune des trois tranches de niveau supérieur est conçue pour son type de charge de travail, qui tranche les secteurs enfants dans la tranche parent:
- Système - démons et services.
- Utilisateur - sessions utilisateur. Chaque utilisateur reçoit une tranche enfant et toutes les sessions avec le même UID "en direct" dans la même tranche, de sorte que les sages particulièrement malins ne peuvent pas obtenir plus de ressources qu'ils ne devraient.
- Machine - machines virtuelles, telles que les invités KVM.
En outre, le concept de la soi-disant «boule» (part) est utilisé pour contrôler l'utilisation des ressources. Une balle est un paramètre numérique relatif; sa valeur n'a de sens qu'en comparaison avec les valeurs des autres balles incluses dans le même groupe de contrôle. Par défaut, toutes les tranches ont une boule égale à 1024. Dans la tranche Système de la figure ci-dessus, les boules CPU égales à 1024 sont définies pour httpd, sshd, crond et gdm. Les valeurs de balle pour les tranches Système, Utilisateur et Machine sont également 1024. Est-ce un peu déroutant? En fait, cela peut être représenté comme un arbre:
- Système - 1024
- httpd - 1024
- sshd - 1024
- crond - 1024
- gdm - 1024
- Utilisateur - 1024
- bash (mrichter) - 1024
- bash (dorf) - 1024
- Machine - 1024
Dans cette liste, nous avons plusieurs démons en cours d'exécution, quelques utilisateurs et une machine virtuelle. Imaginez maintenant qu'ils demandent tous simultanément tout le temps processeur qui peut être obtenu.
En résumé:
- Le système Slice reçoit 33,333% du temps processeur et le partage également entre quatre démons, ce qui donne à chacun 8,25% des ressources CPU.
- La tranche utilisateur reçoit 33,333% du temps processeur et la partage entre deux utilisateurs, chacun disposant de 16,5% des ressources CPU. Si l'utilisateur mrichter se déconnecte ou arrête tous les processus en cours d'exécution, alors dorf aura accès à 33% des ressources du processeur.
- Slice Machine reçoit 33,333% du temps processeur. Si vous éteignez la machine virtuelle ou la mettez en mode veille, les tranches système et utilisateur recevront environ 50% des ressources CPU, qui seront ensuite partagées entre leurs tranches enfants.
De plus, pour tout démon, utilisateur ou machine virtuelle, vous pouvez entrer non seulement des restrictions relatives, mais aussi absolues, sur la consommation de temps processeur, non seulement un, mais également plusieurs processeurs. Par exemple, la tranche utilisateur mrichter a la propriété CPUQuota. Si vous le définissez à 20%, mrichter ne recevra en aucun cas plus de 20% des ressources d'un processeur. Sur les serveurs multicœurs, le CPUQuota peut être supérieur à 100% afin que la tranche puisse utiliser les ressources de plusieurs processeurs. Par exemple, avec CPUQuota = 200%, une tranche peut utiliser pleinement deux cœurs de processeur. Il est important de comprendre que CPUQuota ne réserve pas, en d'autres termes, il ne garantit pas un pourcentage donné de temps processeur pour toute charge système - ce n'est que le maximum qui peut être alloué à une tranche en tenant compte de toutes les autres tranches et paramètres.
Tournez à fond!
Comment puis-je modifier les paramètres de tranche?
Pour cela, chaque tranche a des propriétés personnalisées. Et comme il s'agit de Linux, nous pouvons écrire manuellement les paramètres dans les fichiers de configuration ou définir à partir de la ligne de commande.
Dans le second cas, la commande systemctl set-property est utilisée. Voici ce qui se passera à l'écran si vous tapez cette commande, ajoutez le nom de la tranche à la fin (dans notre cas, Utilisateur), puis appuyez sur la touche Tab pour afficher les options:
Toutes les propriétés de cette capture d'écran ne sont pas des paramètres de groupe de contrôle. Nous sommes principalement intéressés par ceux qui démarrent sur Block, CPU et Memory.
Si vous ne préférez pas la ligne de commande, mais les fichiers de configuration (par exemple, pour un déploiement automatisé sur plusieurs hôtes), vous devrez traiter les fichiers dans le dossier / etc / systemd / system. Ces fichiers sont créés automatiquement lorsque vous définissez des propriétés à l'aide de la commande systemctl, mais ils peuvent également être créés dans un éditeur de texte, tamponnés via Puppet ou même générés par des scripts à la volée.
Donc, avec les concepts de base des cgroups, tout devrait être clair. La prochaine fois, nous passerons en revue certains scénarios et verrons comment les modifications de certaines propriétés affectent les performances.
Et littéralement demain, nous invitons tout le monde au Forum Red Hat Russie 2018 - il sera possible de poser des questions directement aux ingénieurs de Red Hat.D'autres articles cgroups de notre série Resource Fight sont disponibles sur: