En los grandes sistemas de nube, la cuestión del equilibrio o nivelación automática de la carga de los recursos informáticos es especialmente grave. Tionix (desarrollador y operador de servicios en la nube, parte del grupo de empresas Rostelecom) también se ha ocupado de este problema.
Y, dado que nuestra principal plataforma de desarrollo es Openstack y nosotros, como todas las personas, somos vagos, se decidió seleccionar algún módulo ya preparado que ya esté incluido en la plataforma. Nuestra elección recayó en Watcher, que decidimos utilizar para nuestras necesidades.
Primero, veamos los términos y definiciones.
Términos y definiciones
objetivo Es un resultado final legible por humanos, observable y mensurable que debe lograrse. Hay una o más estrategias para lograr cada objetivo. Una estrategia es la implementación de un algoritmo que es capaz de encontrar una solución para un objetivo determinado.
Acción es una tarea elemental que cambia el estado actual del recurso administrado de destino del clúster OpenStack, como por ejemplo: migrar una máquina virtual (migración), cambiar el estado de energía de un nodo (change_node_power_state), cambiar el estado del servicio nova (change_nova_service_state ), cambio de sabor (cambiar tamaño), registro de mensajes NOP (nop), falta de acción durante un cierto período de tiempo: pausa (suspensión), transferencia de disco (volume_migrate).
Plan de ACCION - un flujo específico de acciones llevadas a cabo en un orden determinado para lograr un Objetivo específico. El Plan de Acción también contiene el desempeño global medido con un conjunto de indicadores de desempeño. Watcher genera un plan de acción tras una auditoría exitosa, como resultado del cual la estrategia utilizada encuentra una solución para lograr el objetivo. Un plan de acción consta de una lista de acciones secuenciales.
Auditoría es una solicitud para optimizar el clúster. La optimización se realiza para lograr un objetivo en un grupo determinado. Para cada auditoría exitosa, Watcher genera un Plan de Acción.
Alcance de auditoría es un conjunto de recursos dentro del cual se realiza la auditoría (zona(s) de disponibilidad, agregadores de nodos, nodos de computación individuales o nodos de almacenamiento, etc.). El alcance de la auditoría se define en cada plantilla. Si no se especifica un alcance de auditoría, se audita todo el clúster.
Plantilla de auditoría — un conjunto guardado de configuraciones para iniciar una auditoría. Se necesitan plantillas para ejecutar auditorías varias veces con la misma configuración. La plantilla debe contener necesariamente el propósito de la auditoría; si no se especifican estrategias, se seleccionan las estrategias existentes más adecuadas.
Grupo es una colección de máquinas físicas que proporcionan recursos informáticos, de almacenamiento y de red y están administradas por el mismo nodo de administración de OpenStack.
Modelo de datos de clúster (CDM) es una representación lógica del estado actual y la topología de los recursos administrados por el clúster.
Indicador de eficiencia - un indicador que indica cómo se realiza la solución creada con esta estrategia. Los indicadores de desempeño son específicos de un objetivo particular y generalmente se utilizan para calcular la efectividad global del plan de acción resultante.
Especificación de eficacia Es un conjunto de características específicas asociadas a cada Objetivo que define los diversos indicadores de desempeño que una estrategia para alcanzar el Objetivo correspondiente debe alcanzar en su solución. De hecho, cada solución propuesta por la estrategia se comparará con la especificación antes de calcular su efectividad global.
Motor de puntuación es un archivo ejecutable que tiene entradas bien definidas, salidas bien definidas y realiza una tarea puramente matemática. De esta manera, el cálculo es independiente del entorno en el que se realiza: dará el mismo resultado en cualquier lugar.
Planificador de vigilantes - parte del motor de toma de decisiones de Watcher. Este módulo toma un conjunto de acciones generadas por una estrategia y crea un plan de flujo de trabajo que especifica cómo programar estas diferentes acciones en el tiempo y, para cada acción, cuáles son las condiciones previas.
Objetivos y estrategias del observador
objetivo
estrategia
objetivo ficticio
Estrategia ficticia
Estrategia ficticia utilizando motores de puntuación de muestra
Estrategia ficticia con cambio de tamaño
Ahorrar energía
Estrategia de ahorro de energía
Consolidación de servidores
Consolidación básica de servidores sin conexión
Estrategia de consolidación de cargas de trabajo de VM
Equilibrio de carga de trabajo
Estrategia de migración del equilibrio de carga de trabajo
Estrategia de equilibrio de capacidad de almacenamiento
Estabilización de la carga de trabajo
vecino ruidoso
vecino ruidoso
Optimización térmica
Estrategia basada en la temperatura de salida
Optimización del flujo de aire
Estrategia de migración de flujo de aire uniforme
Mantenimiento de hardware
Migración de zona
Sin clasificar
Solenoide
objetivo ficticio — objetivo reservado que se utiliza con fines de prueba.
Estrategias relacionadas: estrategia ficticia, estrategia ficticia que utiliza motores de puntuación de muestra y estrategia ficticia con cambio de tamaño. La estrategia ficticia es una estrategia ficticia que se utiliza para pruebas de integración a través de Tempest. Esta estrategia no proporciona ninguna optimización útil, su único propósito es utilizar pruebas de Tempest.
Estrategia ficticia que utiliza motores de puntuación de muestra: la estrategia es similar a la anterior, la única diferencia es el uso de un "motor de puntuación" de muestra que realiza cálculos utilizando métodos de aprendizaje automático.
Estrategia ficticia con cambio de tamaño: la estrategia es similar a la anterior, la única diferencia es el uso del cambio de sabor (migración y cambio de tamaño).
No utilizado en producción.
Ahorrar energía — minimizar el consumo de energía. La estrategia de ahorro de energía de este objetivo, junto con la estrategia de consolidación de cargas de trabajo de VM (consolidación de servidores), es capaz de implementar funciones de administración dinámica de energía (DPM) que ahorran energía al consolidar dinámicamente las cargas de trabajo incluso durante períodos de baja utilización de recursos: las máquinas virtuales se mueven a menos nodos y los nodos innecesarios se desactivan. Después de la consolidación, la estrategia ofrece una decisión sobre activar/desactivar nodos de acuerdo con los parámetros especificados: “min_free_hosts_num” - el número de nodos habilitados libres que están esperando la carga, y “free_used_percent” - el porcentaje de hosts habilitados libres para el Número de nodos que están ocupados por máquinas. Para que la estrategia funcione debe haber Ironic habilitado y configurado para manejar el ciclo de energía en los nodos.
Parámetros de estrategia
parámetro
тип
por defecto
descripción
porcentaje_usado_libre
Número
10.0
relación entre el número de nodos informáticos libres y el número de nodos informáticos con máquinas virtuales
min_free_hosts_num
Int.
1
número mínimo de nodos informáticos libres
La nube debe tener al menos dos nodos. El método utilizado es cambiar el estado de energía del nodo (change_node_power_state). La estrategia no requiere recopilar métricas.
Consolidación de servidores: minimice la cantidad de nodos informáticos (consolidación). Tiene dos estrategias: consolidación básica de servidores sin conexión y estrategia de consolidación de cargas de trabajo de VM.
La estrategia de consolidación básica de servidores sin conexión minimiza la cantidad total de servidores utilizados y también minimiza la cantidad de migraciones.
La estrategia básica requiere las siguientes métricas:
métrica
servicio
complementos
comentario
Computar.nodo.cpu.porcentaje
ninguna
cpu_util
ninguna
Parámetros de estrategia: migraciones_intentos: número de combinaciones para buscar candidatos potenciales para el cierre (predeterminado, 0, sin restricciones), período: intervalo de tiempo en segundos para obtener agregación estática de la fuente de datos métrica (predeterminado, 700).
Métodos utilizados: migración, cambio del estado del servicio nova (change_nova_service_state).
La estrategia de consolidación de carga de trabajo de VM se basa en una heurística de primer ajuste que se centra en la carga de CPU medida e intenta minimizar los nodos que tienen demasiada o muy poca carga dadas las limitaciones de capacidad de los recursos. Esta estrategia proporciona una solución que da como resultado un uso más eficiente de los recursos del clúster mediante los siguientes cuatro pasos:
- Fase de descarga: procesamiento de recursos sobreutilizados;
- Fase de consolidación: manejo de recursos subutilizados;
- Optimización de la solución: reducción del número de migraciones;
- Deshabilitar los nodos de computación no utilizados.
La estrategia requiere las siguientes métricas:
métrica
servicio
complementos
comentario
memoria
ninguna
tamaño.raíz.del.disco
ninguna
Las siguientes métricas son opcionales, pero mejorarán la precisión de la estrategia si están disponibles:
métrica
servicio
complementos
comentario
memoria.residente
ninguna
cpu_util
ninguna
Parámetros de estrategia: período: intervalo de tiempo en segundos para obtener agregación estática de la fuente de datos métrica (predeterminado, 3600).
Utiliza los mismos métodos que la estrategia anterior. Más detalles .
Equilibrio de carga de trabajo — equilibrar la carga de trabajo entre los nodos informáticos. El objetivo tiene tres estrategias: estrategia de migración de equilibrio de carga de trabajo, estabilización de carga de trabajo y estrategia de equilibrio de capacidad de almacenamiento.
La estrategia de migración de equilibrio de carga de trabajo ejecuta migraciones de máquinas virtuales en función de la carga de trabajo de la máquina virtual host. Se toma una decisión de migración siempre que el porcentaje de utilización de CPU o RAM de un nodo supera el umbral especificado. En este caso, la máquina virtual movida debería acercar el nodo a la carga de trabajo promedio de todos los nodos.
Requisitos
- Uso de procesadores físicos;
- Al menos dos nodos informáticos físicos;
- Instalé y configuré el componente Ceilometer: ceilometer-agent-compute, que se ejecuta en cada nodo de cómputo, y la API de Ceilometer, además de recopilar las siguientes métricas:
métrica
servicio
complementos
comentario
cpu_util
ninguna
memoria.residente
ninguna
Parámetros de la estrategia:
parámetro
тип
por defecto
descripción
métrica
Cordón
'cpu_util'
Las métricas subyacentes son: 'cpu_util', 'memory.resident'.
umbral
Número
25.0
Umbral de carga de trabajo para la migración.
período
Número
300
Período de tiempo acumulado Ceilómetro.
El método utilizado es la migración.
La estabilización de la carga de trabajo es una estrategia destinada a estabilizar la carga de trabajo mediante la migración en vivo. La estrategia se basa en un algoritmo de desviación estándar y determina si hay congestión en el clúster y responde activando la migración de la máquina para estabilizar el clúster.
Requisitos
- Uso de procesadores físicos;
- Al menos dos nodos informáticos físicos;
- Instalé y configuré el componente Ceilometer: ceilometer-agent-compute, que se ejecuta en cada nodo de cómputo, y la API de Ceilometer, además de recopilar las siguientes métricas:
métrica
servicio
complementos
comentario
cpu_util
ninguna
memoria.residente
ninguna
Estrategia de equilibrio de capacidad de almacenamiento (estrategia implementada a partir de Queens): la estrategia transfiere discos según la carga en los grupos de Cinder. Se toma una decisión de transferencia cada vez que la tasa de utilización del grupo excede un umbral específico. El disco que se mueve debería acercar el grupo a la carga promedio de todos los grupos de Cinder.
Requisitos y restricciones
- Mínimo dos piscinas de Cinder;
- Posibilidad de migración de disco.
- Modelo de datos de clúster: recopilador de modelos de datos de clúster de Cinder.
Parámetros de la estrategia:
parámetro
тип
por defecto
descripción
umbral_volumen
Número
80.0
Valor umbral de discos para equilibrar volúmenes.
El método utilizado es la migración de disco (volume_migrate).
Vecino ruidoso: identifique y migre un "vecino ruidoso": una máquina virtual de baja prioridad que afecta negativamente el rendimiento de una máquina virtual de alta prioridad en términos de IPC al utilizar en exceso la caché de último nivel. Estrategia propia: Vecino ruidoso (el parámetro de estrategia utilizado es cache_threshold (el valor predeterminado es 35), cuando el rendimiento cae al valor especificado, se inicia la migración. Para que la estrategia funcione, habilite Métricas LLC (caché de último nivel), último servidor Intel con soporte CMT, además de recopilar las siguientes métricas:
métrica
servicio
complementos
comentario
cpu_l3_cache
ninguna
Se requiere Intel .
Modelo de datos de clúster (predeterminado): recopilador de modelos de datos de clúster Nova. El método utilizado es la migración.
Trabajar con este objetivo a través del Panel no está completamente implementado en Queens.
Optimización térmica — optimizar el régimen de temperatura. La temperatura de salida (aire de escape) es uno de los sistemas de telemetría térmica importantes para medir el estado térmico/de carga de trabajo de un servidor. El objetivo tiene una estrategia, la estrategia basada en la temperatura de salida, que decide migrar cargas de trabajo a hosts térmicamente favorables (temperatura de salida más baja) cuando la temperatura de salida de los hosts de origen alcanza un umbral configurable.
Para que la estrategia funcione, necesita un servidor con Intel Power Node Manager instalado y configurado , además de recopilar las siguientes métricas:
métrica
servicio
complementos
comentario
hardware.ipmi.node.outlet_temperature
IPMI
Parámetros de la estrategia:
parámetro
тип
por defecto
descripción
umbral
Número
35.0
Umbral de temperatura para la migración.
período
Número
30
El intervalo de tiempo, en segundos, para obtener la agregación estadística del origen de datos de métrica.
El método utilizado es la migración.
Optimización del flujo de aire — optimizar el modo de ventilación. Estrategia propia: flujo de aire uniforme mediante migración en vivo. La estrategia desencadena la migración de la máquina virtual cada vez que el flujo de aire del ventilador del servidor supera un umbral específico.
Para que la estrategia funcione necesitas:
- Hardware: nodos de computación < compatibles con NodeManager 3.0;
- Al menos dos nodos informáticos;
- El componente ceilometer-agent-compute y Ceilometer API instalado y configurado en cada nodo informático, que puede informar con éxito métricas como el flujo de aire, la potencia del sistema y la temperatura de entrada:
métrica
servicio
complementos
comentario
hardware.ipmi.node.flujo de aire
IPMI
hardware.ipmi.nodo.temperatura
IPMI
hardware.ipmi.node.potencia
IPMI
Para que la estrategia funcione, necesita un servidor con Intel Power Node Manager 3.0 o posterior instalado y configurado.
Limitaciones: El concepto no está destinado a la producción.
Se propone utilizar este algoritmo con auditorías continuas, ya que solo se planea migrar una máquina virtual por iteración.
Las migraciones en vivo son posibles.
Parámetros de la estrategia:
parámetro
тип
por defecto
descripción
umbral_flujo de aire
Número
400.0
El umbral de flujo de aire para la unidad de migración es 0.1 CFM.
umbral_entrada_t
Número
28.0
Umbral de temperatura de entrada para la decisión de migración
umbral_potencia
Número
350.0
Umbral de potencia del sistema para la decisión de migración
período
Número
30
El intervalo de tiempo, en segundos, para obtener la agregación estadística del origen de datos de métrica.
El método utilizado es la migración.
Mantenimiento de hardware - mantenimiento de hardware. La estrategia relacionada con este objetivo es la migración de zonas. La estrategia es una herramienta para la migración efectiva, automática y mínima de máquinas virtuales y discos en caso de necesidad de mantenimiento de hardware. La estrategia construye un plan de acción de acuerdo con pesos: se planificará un conjunto de acciones que tengan más peso antes que otras. Hay dos opciones de configuración: action_weights y paralelización.
Limitaciones: es necesario configurar los pesos de acción y la paralelización.
Parámetros de la estrategia:
parámetro
тип
por defecto
descripción
nodos_calculados
matriz
Ninguna
Computar nodos para la migración.
grupos_de_almacenamiento
matriz
Ninguna
Nodos de almacenamiento para migración.
total_paralelo
entero
6
El número total de actividades que deben ejecutarse en paralelo.
paralelo_por_nodo
entero
2
El número de acciones realizadas en paralelo para cada nodo de cálculo.
paralelo_por_grupo
entero
2
El número de acciones realizadas en paralelo para cada grupo de almacenamiento.
lista de prioridades
objeto
Ninguna
Lista de prioridades para máquinas virtuales y discos.
con_volumen_adjunto
booleano
Falso
Falso: las máquinas virtuales se migrarán después de que se hayan migrado todos los discos. Verdadero: las máquinas virtuales se migrarán después de que se hayan migrado todos los discos conectados.
Elementos de la matriz de nodos informáticos:
parámetro
тип
por defecto
descripción
src_nodo
cadena
Ninguna
El nodo informático desde el que se migran las máquinas virtuales (obligatorio).
dst_nodo
cadena
Ninguna
Calcule el nodo al que están migrando las máquinas virtuales.
Elementos de la matriz de nodos de almacenamiento:
parámetro
тип
por defecto
descripción
src_pool
cadena
Ninguna
El grupo de almacenamiento desde el que se migran los discos (obligatorio).
dst_pool
cadena
Ninguna
El grupo de almacenamiento al que se migran los discos.
tipo_src
cadena
Ninguna
Tipo de disco original (obligatorio).
tipo_dst
cadena
Ninguna
El tipo de disco resultante (obligatorio).
Elementos de prioridad de objeto:
parámetro
тип
por defecto
descripción
proyecto
matriz
Ninguna
Nombres de proyectos.
nodo_calculado
matriz
Ninguna
Calcular los nombres de los nodos.
grupo_almacenamiento
matriz
Ninguna
Nombres de grupos de almacenamiento.
calcular
enumerar
Ninguna
Parámetros de la máquina virtual [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
STORAGE
enumerar
Ninguna
Parámetros del disco [“tamaño”, “creado_at”].
Los métodos utilizados son migración de máquinas virtuales, migración de discos.
Sin clasificar - un objetivo auxiliar utilizado para facilitar el proceso de desarrollo de la estrategia. No contiene especificaciones y se puede utilizar siempre que la estrategia aún no esté asociada con un objetivo existente. Este objetivo también se puede utilizar como punto de transición. Una estrategia relacionada con este objetivo es Actuator.
Creando una nueva meta
Motor de decisión del observador tiene una interfaz de complemento de "objetivo externo" que permite integrar un objetivo externo que se puede lograr mediante una estrategia.
Antes de crear un nuevo objetivo, debe asegurarse de que ningún objetivo existente satisfaga sus necesidades.
Creando un nuevo complemento
Para crear un nuevo objetivo, debe: extender la clase de destino, implementar un método de clase obtener_nombre() para devolver el ID único del nuevo objetivo que desea crear. Este identificador único debe coincidir con el nombre del punto de entrada que declare más adelante.
A continuación necesitas implementar el método de clase. get_display_name() para devolver el nombre para mostrar traducido del destino que desea crear (no utilice una variable para devolver la cadena traducida para que la herramienta de traducción pueda recopilarla automáticamente).
Implementar un método de clase get_translatable_display_name()para devolver la clave de traducción (en realidad, el nombre para mostrar en inglés) de su nuevo objetivo. El valor de retorno debe coincidir con la cadena traducida a get_display_name().
Implementar su método get_efficacy_specification()para devolver la especificación de eficiencia para su objetivo. El método get_efficacy_specification() devuelve la instancia Unclassified() proporcionada por Watcher. Esta especificación de rendimiento es útil en el proceso de desarrollo de su objetivo porque corresponde a la especificación vacía.
→
Arquitectura de Watcher (más detalles) ).
Компоненты
API de vigilancia - un componente que implementa la API REST proporcionada por Watcher. Mecanismos de interacción: CLI, complemento Horizon, SDK de Python.
Vigilante DB — Base de datos del observador.
Aplicador de vigilancia — un componente que implementa la ejecución de un plan de acción creado por el componente Watcher Decision Engine.
Motor de decisión del observador - El componente responsable de calcular un conjunto de posibles acciones de optimización para lograr el objetivo de la auditoría. Si no se especifica una estrategia, el componente selecciona de forma independiente la más adecuada.
Editor de métricas de Watcher - Un componente que recopila y calcula algunas métricas o eventos y los publica en el punto final de CEP. La funcionalidad del componente también puede ser proporcionada por el editor Ceilometer.
Motor de procesamiento de eventos complejos (CEP) — motor para procesamiento de eventos complejos. Por motivos de rendimiento, puede haber varias instancias de CEP Engine ejecutándose simultáneamente, cada una de las cuales procesa un tipo específico de métrica/evento. En el sistema Watcher, CEP desencadena dos tipos de acciones: - registrar los eventos/métricas correspondientes en la base de datos de series temporales; - enviar eventos apropiados al Watcher Decision Engine cuando este evento pueda afectar el resultado de la estrategia de optimización actual, ya que el clúster Openstack no es un sistema estático.
Los componentes interactúan mediante el protocolo AMQP.
→
Esquema de interacción con Watcher.
Resultados de la prueba del observador
- En la página Optimización - Planes de acción 500 (tanto en Queens puros como en un stand con módulos Tionix), aparece solo después de que se inicia la auditoría y se genera un plan de acción; el vacío se abre normalmente.
- Hay errores en la pestaña Detalles de la acción, no es posible obtener el objetivo y la estrategia de auditoría (tanto en Queens puras como en un stand con módulos Tionix).
- Las auditorías con finalidad de Dummy (test) se crean y lanzan normalmente, se generan planes de acción.
- Las auditorías para el objetivo Sin clasificar no se crean porque el objetivo no es funcional y está destinado a una configuración intermedia al crear nuevas estrategias.
- Las auditorías con fines de equilibrio de carga de trabajo (estrategia de equilibrio de capacidad de almacenamiento) se crean correctamente, pero no se genera un plan de acción. No se requiere optimización del grupo de almacenamiento.
- Las auditorías para el objetivo de Equilibrio de carga de trabajo (Estrategia de migración de equilibrio de carga de trabajo) se crean correctamente, pero no se genera un plan de acción.
- Las auditorías para el equilibrio de la carga de trabajo (estrategia de estabilización de la carga de trabajo) fallan.
- Las auditorías para el objetivo Vecino ruidoso se crean correctamente, pero no se genera un plan de acción.
- Las auditorías con fines de mantenimiento de hardware se crean con éxito, el plan de acción no se genera en su totalidad (se generan indicadores de desempeño, pero no se genera la lista de acciones en sí).
- Las ediciones en las configuraciones de nova.conf (en la sección predeterminada Compute_monitors = cpu.virt_driver) en los nodos de computación y control no corrigen los errores.
- Las auditorías dirigidas a la consolidación de servidores (estrategia básica) también fallan.
- Las auditorías con fines de consolidación de servidores (estrategia de consolidación de cargas de trabajo de VM) fallan con un error. En los logs hay un error al obtener los datos de origen. Discusión del error, en particular. .
Intentamos especificar Watcher en el archivo de configuración (no ayudó; como resultado de un error en todas las páginas de Optimización, volver al contenido original del archivo de configuración no corrige la situación): [watcher_strategies.basic] fuente de datos = ceilómetro, ñoquis - Fallan las auditorías para el Ahorro de Energía. A juzgar por los registros, el problema sigue siendo la ausencia de Ironic; no funcionará sin un servicio baremetal.
- Las auditorías de optimización térmica fallan. El rastreo es el mismo que para la consolidación de servidores (estrategia de consolidación de carga de trabajo de VM) (error de datos de origen)
- Las auditorías con el fin de optimizar el flujo de aire fallan con un error.
También se encuentran los siguientes errores de finalización de auditoría. Seguimiento en los registros de decision-engine.log (el estado del clúster no está definido).
→ Discusión del error
Conclusión
El resultado de nuestra investigación de dos meses fue la conclusión inequívoca de que para obtener un sistema de equilibrio de carga funcional y completo, en esta parte tendremos que trabajar estrechamente para perfeccionar las herramientas para la plataforma Openstack.
Watcher ha demostrado ser un producto serio y de rápido desarrollo con un enorme potencial, cuyo uso completo requerirá mucho trabajo serio.
Pero más sobre esto en los próximos artículos de la serie.
Fuente: habr.com