Seguimos estudiando cgroups. En Red Hat Enterprise Linux 7, están habilitados de forma predeterminada, ya que usa systemd, y él, a su vez, ya tiene cgroups integrados. Con Red Hat, Red Hat Enterprise Linux 6 es un poco diferente. De hecho, los controladores de cgroups estaban inicialmente allí, pero esta versión fue lanzada, recuerda en enero de 2010, es decir, hace un par de siglos en términos de años de computadora.
Sin embargo, los cgroups en Red Hat Enterprise Linux 6 son capaces de mucho incluso hoy, lo que ilustraremos hoy.
Analicemos las capacidades de cgroups en Red Hat Enterprise Linux 6 usando un ejemplo puramente hipotético, basado completamente en eventos reales. Pero para empezar, por tradición, una pequeña digresión.
Nunca ha habido tantos problemas con la seguridad de TI como ahora. No es sorprendente, porque hoy no solo todas las computadoras y teléfonos están conectados a la red, sino también refrigeradores, aspiradoras y muchas otras cosas: el alcance de las amenazas a la red es simplemente inmenso. Y la lucha contra estas amenazas, por regla general, comienza de inmediato en todos los frentes. Instalación rápida de parches de seguridad? Si definitivamente! Fortalecimiento de la seguridad del sistema: firewalls, SELinux, autenticación inteligente, ¿eso es todo? Por supuesto! ¿Escáneres antivirus en máquinas Linux? Bueno, como decirlo ...
En las máquinas Linux, los escáneres antivirus a veces hacen más daño que bien. Sin embargo, los guardias de seguridad tienen sus propias razones, y a menudo requieren que ejecute análisis antivirus regularmente, sin pensar realmente en su solidez desde un punto de vista técnico. Y esta es una realidad que uno tiene que soportar y con la que, tarde o temprano, se enfrenta casi cualquier especialista en TI.
El segundo punto es que Red Hat Enterprise Linux 7 es, por supuesto, moderno, avanzado y genial, pero muchos todavía usan Red Hat Enterprise Linux 6 y no piensan rechazarlo. De hecho, es por eso que la gente elige Red Hat: puede sentarse en la misma versión durante años y aún tener los últimos parches, actualizaciones y soporte.
Volvamos a nuestro ejemplo ... Imagine que hay un tipo llamado Jerry. Jerry trabaja en una oficina grande y es responsable del servidor Red Hat Enterprise Linux 6. Está completamente satisfecho con su funcionamiento, y no necesita nuevos problemas y problemas.
Pero luego, los chicos del departamento de seguridad deciden que en todos sus servidores necesitas poner una cosa llamada ScanIT. Y dado que esto revisará periódicamente los discos y la memoria en busca de virus y otro malware, necesita acceso completo a la raíz.
Jerry suspira, baja la guitarra y va a poner ScanIT en una máquina de prueba. Bastante rápido resulta esto:
- Al realizar un análisis antivirus, scanit (este es un script para iniciar el proceso) consume todo el tiempo del procesador que puede alcanzar. Y esto afecta gravemente el trabajo de la máquina de prueba, una vez que Jerry ni siquiera podía alcanzarlo en ssh.
- Además, el proceso de escaneo consume memoria de vez en cuando como en sí mismo. Como resultado, OOM Killer se despierta y comienza a matar cualquier proceso que no sea el escaneo en sí.
En general, hay que hacer algo con esto.
Jerry toma la guitarra y, tocando Grateful Dead, comienza a pensar. Muy rápidamente, se le ocurrió que los mismos cgroups de Red Hat Enterprise Linux 7 probablemente podrían ayudar aquí, por lo que un amigo llamado Alex zumbó por sus oídos. Jerry nuevamente se quita la guitarra y comienza a leer los
muelles enviados por Alex
en Red Hat Enterprise Linux 6 . Resulta que lo primero que necesita es libcgroup.
No hay libcgroup en la máquina de prueba, por lo que Jerry comienza a instalarlo:
Además, Jerry incluye dos servicios que son necesarios para el trabajo de grupos permanentes (persistentes):
- cgconfig: proporciona una interfaz más o menos simple para trabajar con árboles cgroup. Jerry ciertamente podría montar y configurar cgroups manualmente, pero ¿por qué, si puede ahorrar tiempo?
- cgred: esto es un motor de reglas de cgroup: cuando se inicia un proceso, este servicio lo coloca en uno u otro cgroup de acuerdo con las reglas especificadas.
Después de instalar y configurar todo esto, Jerry finalmente puede proceder directamente al problema en sí. Después de pensarlo detenidamente, toma la siguiente decisión:
- scanit y sus procesos secundarios no deben consumir más del 20% de los recursos de la CPU. De hecho, incluso menos: no más del 20% de los recursos de un núcleo de procesador, incluso en una máquina de múltiples núcleos. En cgroups, esto se hace usando cuotas de CPU.
- En cuanto a la memoria, scanit y sus procesos secundarios no deben consumir más de 512 MB de memoria del sistema. Si están cruzando esta línea, el sistema debería matarlos, y no a ningún otro proceso.
¡No es necesario que me digas qué hacer!
Jerry tendrá que lidiar con dos conjuntos de archivos de configuración:
- /etc/cgconfig.conf: generado automáticamente al instalar libcgroup.
- /etc/cgrules.conf: contiene un conjunto de reglas de conjunto de reglas, según las cuales cgred clasifica los procesos en ejecución por grupos de cgroups.
Así es como se ve el archivo cgconfig.conf predeterminado:
Jerry podría haber hecho los cambios necesarios directamente a él, pero es mejor usar archivos de confguración para esto. Como funciona Si coloca (eng. Drop-in - drop) en la carpeta /etc/cgconfig.d cualquier archivo con la extensión .conf, el sistema lo procesará y realizará los cambios apropiados en la configuración. Esto es conveniente porque puede crear complementos para diferentes tareas y agregarlos o eliminarlos de la configuración utilizando las herramientas que más le gusten (digamos, Ansible, bueno, sigue siendo un blog de Red Hat).
Jerry primero crea un archivo desplegable para la CPU:
Miramos lo que tenemos aquí y cómo funciona.
La palabra clave de grupo simplemente establece el nombre del nuevo cgroup, en nuestro caso, scanit. Dentro de las llaves, especificamos los controles de cgroup que queremos usar. Aquí, cpu.cfs_period_us y cpu.cfs_quota_us, le permiten establecer los límites correspondientes en el Programador completamente justo, el programador del kernel utilizado por defecto en Red Hat Enterprise Linux 6. Veamos qué se escribe sobre ellos en la
Guía de administración de recursos de Red Hat Enterprise Linux 6 :
En otras palabras, Jerry escribió esto en su lista desplegable: “Para cada proceso relacionado con cgroup llamado scanit, una vez por segundo verifique la cantidad de recursos de CPU asignados a él. Si el tiempo total del procesador para todos los procesos en este grupo es más de 200,000 milisegundos, entonces deje completamente de dar tiempo al procesador a estos procesos ". Bueno, es decir, asignar a todos los procesos en el grupo cgroup de scanit, así como a sus procesos secundarios, en total no más del 20% del tiempo del procesador.
Después de reiniciar cgconfig, el servidor actualizará la configuración, y si ingresa al sistema de archivos, veremos que scanit ahora se encuentra en el directorio del controlador de la CPU:
Esto, por supuesto, es bueno, pero aún necesitamos empujar scanit en este cgroup. Crged es útil aquí, por defecto se parece a esto:
Usar este archivo es más o menos fácil. Sin embargo, para esto tendremos que editar directamente el archivo cgrules.conf, ya que el mecanismo de inserción no es compatible aquí. Indicamos el usuario o grupo que posee el proceso, así como el nombre del proceso específico, si lo desea, así como un controlador personalizado y un grupo de destino de cgroup.
En nuestro ejemplo, en lugar del escaneo real del escáner antivirus, usamos un script que también se llama scanit, pero en realidad solo emula la carga. Sin cgroup, todo se ve así:
La CPU está totalmente ocupada, principalmente por el espacio del usuario y un poco de un sistema.
Jerry se rasca la barba. Inicia vi y, utilizando exactamente un dedo índice, realiza algunos cambios y reinicia el demonio cgred:
Luego se inicia manualmente scanit ...:
Y - ¡salud! Victoria
Como puede ver, nuestros procesos de emulación de carga (procesos secundarios de escaneos) ahora consumen un total del 20% de los recursos de la CPU, principalmente en el espacio del usuario y un poco en el sistema. Entonces, este maldito antivirus ya no cargará el auto a la locura total.
¿Recuerdas lo que sigue?
Regocijado por el éxito, Jerry casi se olvida de su memoria. Pero aún así recuerda y comienza a vi nuevamente para arreglar su archivo de configuración.
Ahora agrega dos configuraciones con respecto a la memoria allí:
- Memory.limit_in_bytes - máx. La cantidad de RAM que pueden usar todos los procesos en el cgroup de scanit. Y excluyendo el espacio de intercambio. Jerry lo limita a 256 MB
- Memory.memsw.limit_in_bytes - máx. Volumen de RAM, más espacio en el archivo de intercambio, que puede asignarse a todos los procesos en el grupo cgroup de scanit, en total. Si se supera este umbral, el asesino OOM matará los procesos. Jerry lo establece en 512 MB.
Oh no! Que esta mal
Jerry mira hacia arriba y ve que los procesos secundarios de escaneo todavía se están ejecutando. Como este cgroup está actualmente en uso, Jerry no puede iniciar el servicio. Por lo tanto, mata los procesos secundarios manualmente y reinicia dichos servicios.
Ahora una pequeña edición en cgred.conf:
Para verificar, Jerry ejecuta varias tareas de escaneo a la vez, para que el asesino OOM funcione con seguridad.
Entonces Jerry mira el registro del sistema y asiente con satisfacción: scanit ya no puede dejar la memoria en ninguna cantidad con impunidad.
Esperamos que nuestra serie de artículos de cgroups lo haya ayudado a comprender qué es, cómo usarlo en Red Hat Enterprise Linux 7, cómo crearlo en Red Hat Enterprise Linux 6 y cómo usarlo en su entorno.