Las computadoras son hardware. Y hoy volvimos al punto de partida, en el sentido de que ahora rara vez se encuentra un host físico en el que se realiza una sola tarea. Incluso si solo se está ejecutando una aplicación en el servidor, lo más probable es que consista en varios procesos, contenedores o incluso máquinas virtuales (VM), y todos funcionan en el mismo servidor. Red Hat Enterprise Linux 7 se adapta bien a la distribución de los recursos del sistema en tales situaciones, pero por defecto se comporta como una amable abuela, trata a sus nietos con un pastel casero y dice: "Igual para todos, igual para todos".
En teoría, el principio de "igualmente dividido", por supuesto, es hermoso, pero en la práctica, algunos procesos, contenedores o máquinas virtuales son más importantes que otros y, por lo tanto, deberían recibir más.
Linux siempre ha tenido herramientas de administración de recursos (agradable, ulimit, etc.), pero con el advenimiento de Red Hat Enterprise Linux 7 y systemd, finalmente tenemos un poderoso conjunto de herramientas integradas en el sistema operativo. El hecho es que el componente clave de systemd es un conjunto de cgroups personalizado y listo para usar que se utiliza completamente a nivel de sistema operativo.
Bueno, ¿qué tipo de cgroups son estos y adónde va la gestión de recursos o rendimiento?
Control de nivel de kernel
A partir de la versión 2.6.24, lanzada en enero de 2008, apareció el kernel de Linux que fue originalmente inventado y creado en Google bajo el nombre de "contenedores de procesos", y en Linux se conoció como "grupos de control", abreviados cgroups. En resumen, cgroups es un mecanismo de kernel que le permite limitar el uso, mantener registros y aislar el consumo de recursos del sistema (CPU, memoria, E / S de disco, red, etc.) a nivel de colecciones de procesos. Cgroups también puede congelar procesos para verificar y reiniciar. Los controladores Cgroups aparecieron por primera vez en la versión 6 de Red Hat Enterprise Linux, pero allí tuvieron que configurarse manualmente. Pero con la llegada de Red Hat Enterprise Linux 7 y systemd, el conjunto preconfigurado de cgroups viene incluido con el sistema operativo.
Todo esto funciona al nivel del núcleo del sistema operativo y, por lo tanto, garantiza un control estricto sobre cada proceso. Así que ahora es extremadamente difícil para cualquier malware cargar el sistema para que deje de responder y se congele. Aunque, por supuesto, el código defectuoso con acceso directo al hardware (por ejemplo, controladores) todavía es capaz de esto. Al mismo tiempo, Red Hat Enterprise Linux 7 proporciona una interfaz para interactuar con cgroups, y todo el trabajo con ellos se realiza principalmente a través del comando systemd.
Tu pedazo de pastel
El siguiente diagrama, que recuerda a un pastel en rodajas, muestra tres cgroups que están por defecto en el servidor Red Hat Enterprise Linux 7: Sistema, Usuario y Máquina. Cada uno de estos grupos se denomina "corte" (sector de corte). Como puede ver en la figura, cada segmento puede tener sectores secundarios de corte. Y, como en el caso del pastel, en total, todas las rebanadas dan el 100% del recurso correspondiente.
Ahora veamos varios conceptos de cgroups usando recursos de procesador como ejemplo.
La figura anterior muestra que el tiempo del procesador se divide por igual entre los tres sectores de nivel superior (Sistema, Usuario y Máquina). Pero esto solo sucede bajo carga. Si algún proceso del sector Usuario solicita el 100% de los recursos del procesador y nadie más necesita estos recursos en este momento, recibirá todo el 100% del tiempo del procesador.
Cada uno de los tres sectores de nivel superior está diseñado para su tipo de carga de trabajo, que divide los sectores secundarios dentro del segmento primario:
- Sistema - demonios y servicios.
- Usuario - sesiones de usuario. Cada usuario recibe un segmento secundario, y todas las sesiones con el mismo UID "en vivo" en el mismo segmento, de modo que especialmente los astutos expertos no pueden obtener recursos más de lo que deberían.
- Máquina : máquinas virtuales, como invitados KVM.
Además, el concepto de la llamada "pelota" (compartir) se utiliza para controlar el uso de los recursos. Una pelota es un parámetro numérico relativo; su valor solo tiene sentido en comparación con los valores de otras bolas incluidas en el mismo grupo c. Por defecto, todas las secciones tienen una bola igual a 1024. En la sección del sistema en la figura anterior, las bolas de CPU igual a 1024 están configuradas para httpd, sshd, crond y gdm. Los valores de la bola para las secciones del sistema, usuario y máquina también son 1024. ¿Es un poco confuso? De hecho, esto se puede representar como un árbol:
- Sistema - 1024
- httpd - 1024
- sshd - 1024
- crond - 1024
- gdm - 1024
- Usuario - 1024
- bash (mrichter) - 1024
- bash (dorf) - 1024
- Máquina - 1024
En esta lista, tenemos varios demonios en ejecución, un par de usuarios y una máquina virtual. Ahora imagine que todos solicitan simultáneamente todo el tiempo de procesador que se pueda obtener.
En resumen:
- El Sistema Slice recibe el 33.333% del tiempo del procesador y lo comparte por igual entre cuatro demonios, lo que les da a cada uno el 8.25% de los recursos de la CPU.
- El segmento de usuario recibe el 33.333% del tiempo del procesador y lo comparte entre dos usuarios, cada uno de los cuales tiene el 16.5% de los recursos de la CPU. Si el usuario mrichter cierra la sesión o detiene todos los procesos en ejecución, dorf tendrá acceso al 33% de los recursos de la CPU.
- Slice Machine recibe el 33.333% del tiempo del procesador. Si apaga la VM o la pone en modo inactivo, los segmentos del sistema y del usuario recibirán aproximadamente el 50% de los recursos de la CPU, que luego se compartirán entre sus segmentos secundarios.
Además, para cualquier daemon, usuario o máquina virtual, puede ingresar no solo restricciones relativas, sino también absolutas en el consumo de tiempo del procesador, no solo uno, sino también varios procesadores. Por ejemplo, el usuario slice mrichter tiene la propiedad CPUQuota. Si lo configura al 20%, entonces mrichter en ningún caso recibirá más del 20% de los recursos de una CPU. En servidores de varios núcleos, la CPUQuota puede ser más del 100% para que el segmento pueda utilizar los recursos de más de un procesador. Por ejemplo, con CPUQuota = 200%, un segmento puede utilizar completamente dos núcleos de procesador. Es importante comprender que CPUQuota no reserva, en otras palabras, no garantiza un porcentaje dado de tiempo de procesador para cualquier carga del sistema; este es solo el máximo que se puede asignar a un segmento teniendo en cuenta todos los demás segmentos y configuraciones.
¡Gíralo al máximo!
¿Cómo puedo cambiar la configuración de corte?
Para esto, cada segmento tiene propiedades personalizadas. Y dado que es Linux, podemos escribir manualmente la configuración en los archivos de configuración o establecerla desde la línea de comandos.
En el segundo caso, se usa el comando systemctl set-property. Esto es lo que sucederá en la pantalla si escribe este comando, agrega el nombre del segmento al final (en nuestro caso, Usuario) y luego presiona la tecla Tab para mostrar las opciones:
No todas las propiedades en esta captura de pantalla son configuraciones de cgroup. Estamos principalmente interesados en aquellos que comienzan en Block, CPU y Memory.
Si prefiere no la línea de comandos, sino los archivos de configuración (por ejemplo, para la implementación automatizada en varios hosts), tendrá que ocuparse de los archivos en la carpeta / etc / systemd / system. Estos archivos se crean automáticamente cuando establece propiedades utilizando el comando systemctl, pero también se pueden crear en un editor de texto, sellado a través de Puppet o incluso generado por scripts sobre la marcha.
Entonces, con los conceptos básicos de cgroups, todo debería estar claro. La próxima vez veremos algunos escenarios y veremos cómo los cambios en ciertas propiedades afectan el rendimiento.
Y literalmente mañana, invitamos a todos al Red Hat Forum Rusia 2018 : habrá una oportunidad para hacer preguntas directamente a los ingenieros de Red Hat.Otras publicaciones de cgroups de nuestra serie Resource Fight están disponibles en: