Nous continuons d'étudier les cgroups. Dans Red Hat Enterprise Linux 7, ils sont activés par défaut, car il utilise systemd, et lui, à son tour, a déjà des groupes de contrôle intégrés. Avec Red Hat, Red Hat Enterprise Linux 6 est un peu différent. En fait, les contrôleurs cgroups étaient initialement là , mais cette version a été publiée, rappelez-vous en janvier 2010, c'est-à -dire il y a quelques siècles en termes d'années informatiques.
Cependant, les cgroups dans Red Hat Enterprise Linux 6 sont capables de bien plus encore aujourd'hui, ce que nous allons illustrer aujourd'hui.
Analysons les capacités des cgroups dans Red Hat Enterprise Linux 6 à l'aide d'un exemple purement hypothétique, entièrement basé sur des événements réels. Mais pour commencer, par tradition, une petite digression.
Il n'y a jamais eu autant de problèmes de sécurité informatique qu'aujourd'hui. Ce n'est pas surprenant, car aujourd'hui, non seulement tous les ordinateurs et téléphones sont connectés au réseau, mais aussi des réfrigérateurs, des aspirateurs et un tas d'autres choses - la portée des menaces du réseau est tout simplement immense. Et la lutte contre ces menaces, en règle générale, commence immédiatement sur tous les fronts. Installation rapide des correctifs de sécurité? Oui, bien sûr! Renforcer la sécurité du système - pare-feu, SELinux, authentification intelligente, est-ce tout? Bien sûr! Scanners antivirus sur les machines Linux? Eh bien, comment dire ...
Sur les machines Linux, les analyseurs antivirus font parfois plus de mal que de bien. Cependant, les agents de sécurité ont leurs propres raisons, et ils vous demandent souvent d'exécuter des analyses antivirus régulièrement, sans vraiment penser à leur solidité d'un point de vue technique. Et c'est une réalité à laquelle on doit faire face et à laquelle, tôt ou tard, presque n'importe quel spécialiste informatique doit faire face.
Le deuxième point est que Red Hat Enterprise Linux 7 est bien sûr à la mode, avancé et cool, mais beaucoup utilisent toujours Red Hat Enterprise Linux 6 et ne pensent pas à le refuser. En fait, c'est pourquoi les gens choisissent Red Hat - vous pouvez vous asseoir sur la même version pendant des années et avoir toujours tous les derniers correctifs, mises à jour et support.
Revenons à notre exemple ... Imaginez qu'il y a un gars du nom de Jerry. Jerry travaille dans un grand bureau et est responsable du serveur Red Hat Enterprise Linux 6. Il est entièrement satisfait de la façon dont ils fonctionnent, et il n'a pas besoin de nouveaux problèmes ni de problèmes.
Mais ensuite, les gars du service de sécurité décident que sur tous ses serveurs, vous devez mettre une chose appelée ScanIT. Et puisque cette chose vérifiera périodiquement les disques et la mémoire pour les virus et autres logiciels malveillants, elle a besoin d'un accès root complet.
Jerry soupire, pose sa guitare et va mettre ScanIT sur une machine de test. Il se révèle assez rapidement ceci:
- Lors d'une analyse antivirus, scanit (c'est un script pour démarrer le processus) consomme tout le temps processeur qu'il peut atteindre. Et cela affecte très mal le travail de la machine de test - une fois que Jerry ne pouvait même pas l'atteindre sur ssh.
- De plus, le processus scanit consomme de la mémoire de temps en temps comme s'il était en lui-même. En conséquence, OOM Killer se réveille et commence à tuer tous les processus autres que scanit lui-même.
En général, quelque chose doit être fait avec cela.
Jerry prend la guitare et, jouant le Grateful Dead, commence à réfléchir. Assez rapidement, il lui vint à l'esprit que les mêmes groupes de contrôle de Red Hat Enterprise Linux 7 pourraient probablement aider ici, à propos desquels un ami nommé Alex résonna dans ses oreilles. Jerry éteint à nouveau sa guitare et se met à lire les
quais envoyés par Alex
sur Red Hat Enterprise Linux 6 . Il s'avère que la première chose dont il a besoin est libcgroup.
Il n'y a pas de libcgroup sur la machine de test, donc Jerry commence Ă l'installer:
En outre, Jerry comprend deux services qui sont nécessaires pour le travail des groupes de contrôle permanents (persistants):
- cgconfig - fournit une interface plus ou moins simple pour travailler avec des arbres de groupe de contrĂ´le. Jerry pourrait certainement monter et configurer des groupes de contrĂ´le manuellement, mais pourquoi, si vous pouvez gagner du temps?
- cgred - cette chose est un moteur de règles cgroup: quand un processus démarre, ce service le place dans l'un ou l'autre cgroup selon les règles spécifiées.
Après avoir installé et configuré tout cela, Jerry peut enfin procéder directement au problème lui-même. Après mûre réflexion, il prend la décision suivante:
- scanit et ses processus enfants ne devraient pas consommer plus de 20% des ressources CPU. En fait, encore moins - pas plus de 20% des ressources d'un cœur de processeur, même sur une machine multicœur. Dans les groupes de contrôle, cela se fait en utilisant des quotas CPU.
- En ce qui concerne la mémoire, scanit et ses processus enfants ne devraient pas consommer plus de 512 Mo de mémoire système. S'ils franchissent cette ligne, le système devrait les tuer, et pas d'autres processus.
Pas besoin de me dire quoi faire!
Jerry devra gérer deux ensembles de fichiers de configuration:
- /etc/cgconfig.conf - Généré automatiquement lors de l'installation de libcgroup.
- /etc/cgrules.conf - contient un ensemble de règles d'ensemble de règles, selon lesquelles cgred trie les processus en cours d'exécution par groupes de cgroups.
Voici à quoi ressemble le fichier cgconfig.conf par défaut:
Jerry aurait pu lui apporter directement les modifications nécessaires, mais il est préférable d'utiliser des fichiers de configuration pour cela. Comment ça marche? Si vous placez (eng. Drop-in - drop) dans le dossier /etc/cgconfig.d n'importe quel fichier avec l'extension .conf, le système le traitera et apportera les modifications appropriées à la configuration. C'est pratique car vous pouvez créer des drop-ins pour différentes tâches et les ajouter ou les supprimer de la configuration en utilisant les outils que vous préférez (par exemple, Ansible, eh bien, c'est toujours un blog Red Hat).
Jerry crée d'abord un fichier de dépôt pour le CPU:
Nous regardons ce que nous avons ici et comment cela fonctionne.
Le mot-clé group définit simplement le nom du nouveau cgroup, dans notre cas, scanit. À l'intérieur des accolades, nous spécifions les contrôles cgroup que nous voulons utiliser. Ici, cpu.cfs_period_us et cpu.cfs_quota_us, ils vous permettent de définir les limites appropriées dans Completely Fair Scheduler, le planificateur de noyau utilisé par défaut dans Red Hat Enterprise Linux 6. Voyons ce qui est écrit à leur sujet dans le
Guide de gestion des ressources Red Hat Enterprise Linux 6 :
En d'autres termes, Jerry a écrit ceci dans son drop-in: «Pour chaque processus lié à cgroup nommé scanit, vérifiez une fois par seconde la quantité de ressources CPU allouées. Si la durée totale du processeur pour tous les processus de ce groupe est supérieure à 200 000 millisecondes, arrêtez complètement de donner du temps processeur à ces processus. " Eh bien, c'est-à -dire à allouer à tous les processus du groupe de contrôle scanit, ainsi qu'à leurs processus enfants, au total pas plus de 20% du temps processeur.
Après avoir redémarré cgconfig, le serveur mettra à jour la configuration, et si vous entrez dans le système de fichiers, nous verrons que scanit est maintenant situé dans le répertoire du contrôleur CPU:
Bien sûr, c'est bien, mais nous devons toujours pousser scanit lui-même dans ce groupe de contrôle. Crged est utile ici, par défaut, il ressemble à ceci:
L'utilisation de ce fichier est plus ou moins simple. Cependant, pour cela, nous devrons éditer directement le fichier cgrules.conf, car le mécanisme de dépôt n'est pas pris en charge ici. Nous indiquons l'utilisateur ou le groupe propriétaire du processus, ainsi que le nom du processus spécifique - si vous le souhaitez -, ainsi qu'un contrôleur personnalisé et un groupe de destination de groupe de contrôle.
Dans notre exemple, au lieu du véritable scanner antivirus scanit, nous utilisons un script qui est également appelé scanit, mais qui émule simplement la charge. Sans cgroup, tout ressemble à ceci:
Le CPU est entièrement occupé, principalement par l'espace utilisateur et un peu de système.
Jerry se gratte la barbe. Il démarre vi et, en utilisant exactement un index, apporte quelques modifications et redémarre le démon cgred:
Ensuite, il lance manuellement scanit ...:
Et - bravo! Victoire
Comme vous pouvez le voir, nos processus d'émulation de charge (processus enfants de scanits) consomment maintenant un total de 20% des ressources CPU, principalement dans l'espace utilisateur et un peu dans le système. Donc, ce fichu antivirus ne chargera plus la voiture à la folie complète.
Rappelez-vous quelle est la prochaine Ă©tape?
Réjoui du succès, Jerry a presque oublié sa mémoire. Mais ensuite, il se souvient encore et redémarre vi pour corriger son fichier de configuration.
Il y ajoute maintenant deux paramètres concernant la mémoire:
- Memory.limit_in_bytes - max. La quantité de RAM que tous les processus du groupe de contrôle scanit peuvent utiliser. Et hors espace de swap. Jerry le limite à 256 Mo
- Memory.memsw.limit_in_bytes - max. Volume de RAM, plus espace dans le fichier d'échange, qui peut être alloué à tous les processus du groupe de contrôle scanit, au total. Si ce seuil est dépassé, les processus seront tués par le tueur OOM. Jerry le fixe à 512 Mo.
Oh non! Qu'est-ce qui ne va pas?
Jerry regarde en haut et voit que les processus enfants scanit sont toujours en cours d'exécution. Étant donné que ce groupe de contrôle est actuellement utilisé, Jerry ne peut pas démarrer le service. Par conséquent, il tue manuellement les processus enfants et redémarre ces services.
Maintenant, une petite modification dans cgred.conf:
Pour vérifier, Jerry exécute plusieurs tâches scanit à la fois, afin que le tueur OOM fonctionne à coup sûr.
Jerry regarde ensuite le journal système et hoche la tête avec satisfaction - scanit ne peut plus laisser la mémoire en quantité en toute impunité.
Nous espérons que notre série d'articles cgroups vous a aidé à comprendre de quoi il s'agit, comment l'utiliser dans Red Hat Enterprise Linux 7, comment le créer dans Red Hat Enterprise Linux 6 et comment l'utiliser dans votre environnement.