Nos grandes sistemas de nube, o problema do equilibrio automático ou nivelación da carga dos recursos informáticos é especialmente agudo. Tionix (un desarrollador e operador de servizos na nube, parte do grupo de empresas Rostelecom) tamén se ocupou deste tema.
E, dado que a nosa principal plataforma de desenvolvemento é Openstack, e nós, como todas as persoas, somos preguiceiros, decidiuse seleccionar algún módulo preparado que xa está incluído na plataforma. A nosa elección recaeu en Watcher, que decidimos utilizar para as nosas necesidades.
En primeiro lugar, vexamos os termos e definicións.
Termos e definicións
Meta é un resultado final lexible, observable e medible polo ser humano que debe acadarse. Existen unha ou máis estratexias para acadar cada obxectivo. Unha estratexia é a implementación dun algoritmo que é capaz de atopar unha solución para un determinado obxectivo.
Acción é unha tarefa elemental que cambia o estado actual do recurso xestionado de destino do clúster OpenStack, como: migrar unha máquina virtual (migración), cambiar o estado de enerxía dun nodo (change_node_power_state), cambiar o estado do servizo nova (change_nova_service_state). ), cambiar o sabor (cambiar o tamaño), rexistrar mensaxes NOP (nop), falta de acción durante un período de tempo determinado: pausa (suspensión), transferencia de disco (volume_migrate).
Plan de Acción - Un fluxo específico de accións realizadas nunha determinada orde para acadar un Obxectivo específico. O Plan de Acción tamén contén un rendemento global medido cun conxunto de indicadores de rendemento. Watcher xera un plan de acción tras unha auditoría exitosa, como resultado da cal a estratexia utilizada atopa unha solución para acadar o obxectivo. Un plan de acción consiste nunha lista de accións secuenciais.
Auditoría é unha solicitude para optimizar o clúster. A optimización realízase para acadar un obxectivo nun clúster determinado. Para cada auditoría exitosa, Watcher xera un Plan de Acción.
Ámbito da auditoría é un conxunto de recursos dentro dos cales se realiza a auditoría (zonas de dispoñibilidade, agregadores de nodos, nodos de cálculo individuais ou de almacenamento, etc.). O alcance da auditoría defínese en cada modelo. Se non se especifica un ámbito de auditoría, auditarase todo o clúster.
Modelo de auditoría — un conxunto gardado de configuración para iniciar unha auditoría. Os modelos son necesarios para realizar auditorías varias veces coa mesma configuración. O modelo debe conter necesariamente o propósito da auditoría; se non se especifican as estratexias, elíxense as estratexias existentes máis adecuadas.
Clúster é unha colección de máquinas físicas que proporcionan recursos de computación, almacenamento e rede e son xestionadas polo mesmo nodo de xestión de OpenStack.
Modelo de datos de clúster (CDM) é unha representación lóxica do estado actual e da topoloxía dos recursos xestionados polo clúster.
Indicador de eficiencia - un indicador que indica como se realiza a solución creada mediante esta estratexia. Os indicadores de rendemento son específicos para un obxectivo particular e normalmente úsanse para calcular a eficacia global do plan de acción resultante.
Especificación de eficacia é un conxunto de características específicas asociadas a cada Obxectivo que define os distintos indicadores de rendemento que unha estratexia para acadar o Obxectivo correspondente debe acadar na súa solución. De feito, cada solución proposta pola estratexia comprobarase coa especificación antes de calcular a súa eficacia global.
Motor de puntuación é un ficheiro executable que ten entradas ben definidas, saídas ben definidas e realiza unha tarefa puramente matemática. Deste xeito, o cálculo é independente do ambiente no que se realice; dará o mesmo resultado en calquera lugar.
Vixiante planificador - parte do motor de toma de decisións de Watcher. Este módulo leva un conxunto de accións xeradas por unha estratexia e crea un plan de fluxo de traballo que especifica como programar estas diferentes accións no tempo e para cada acción, cales son as condicións previas.
Obxectivos e estratexias dos observadores
Meta
estratexia
Gol ficticio
Estratexia Dummy
Estratexia simulada usando motores de puntuación de mostra
Estratexia simulada con cambio de tamaño
Aforro de enerxía
Estratexia de aforro enerxético
Consolidación de servidores
Consolidación básica do servidor fóra de liña
Estratexia de consolidación da carga de traballo de VM
Equilibrio de carga de traballo
Estratexia de migración de balance de carga de traballo
Estratexia de balance da capacidade de almacenamento
Estabilización da carga de traballo
Veciño ruidoso
Veciño ruidoso
Optimización térmica
Estratexia baseada na temperatura de saída
Optimización do fluxo de aire
Estratexia uniforme de migración do fluxo de aire
Mantemento de hardware
Migración de zonas
Sen clasificar
Atuador
Gol ficticio — obxectivo reservado que se utiliza para fins de proba.
Estratexias relacionadas: Dummy Strategy, Dummy Strategy usando motores de puntuación de mostra e Dummy Strategy con cambio de tamaño. A estratexia ficticia é unha estratexia ficticia utilizada para probas de integración a través de Tempest. Esta estratexia non proporciona ningunha optimización útil, o seu único propósito é utilizar probas Tempest.
Estratexia simulada usando motores de puntuación de mostra: a estratexia é similar á anterior, a única diferenza é o uso dun "motor de puntuación" de mostra que realiza cálculos mediante métodos de aprendizaxe automática.
Estratexia simulada con cambio de tamaño: a estratexia é semellante á anterior, a única diferenza é o uso de cambiar o sabor (migración e cambio de tamaño).
Non se usa na produción.
Aforro de enerxía - minimizar o consumo de enerxía. A estratexia de aforro de enerxía deste obxectivo, xunto coa estratexia de consolidación da carga de traballo de VM (consolidación de servidores), é capaz de contar con funcións de xestión dinámica de enerxía (DPM) que aforran enerxía ao consolidar dinámicamente as cargas de traballo mesmo durante períodos de baixa utilización de recursos: as máquinas virtuais móvense a menos nodos. , e os nós innecesarios están desactivados. Despois da consolidación, a estratexia ofrece a decisión de activar/desactivar os nodos de acordo cos parámetros especificados: "min_free_hosts_num" - o número de nodos habilitados gratuítos que están esperando para cargar e "free_used_percent" - a porcentaxe de hosts libres habilitados para o número de nodos que están ocupados por máquinas. Para que a estratexia funcione ten que haber habilitado e configurado Ironic para xestionar o ciclo de enerxía nos nodos.
Parámetros da estratexia
parámetro
тип
predeterminado
описание
por cento libre_usado
Número
10.0
relación entre o número de nodos de computación libres e o número de nodos de computación con máquinas virtuais
min_free_hosts_num
Int
1
número mínimo de nodos de computación libres
A nube debe ter polo menos dous nodos. O método utilizado é cambiar o estado de enerxía do nodo (change_node_power_state). A estratexia non require recoller métricas.
Consolidación do servidor: minimiza o número de nodos informáticos (consolidación). Ten dúas estratexias: consolidación básica do servidor fóra de liña e estratexia de consolidación da carga de traballo de VM.
A estratexia Basic Offline Server Consolidation minimiza o número total de servidores utilizados e tamén minimiza o número de migracións.
A estratexia básica require as seguintes métricas:
métricas
servizo
complementos
comentario
calcular.nodo.cpu.porcentaxe
ningún
cpu_util
ningún
Parámetros da estratexia: migration_attempts - número de combinacións para buscar posibles candidatos para o apagado (predeterminado, 0, sen restricións), período - intervalo de tempo en segundos para obter a agregación estática da fonte de datos métricas (predeterminado, 700).
Métodos empregados: migración, cambio do estado do servizo nova (change_nova_service_state).
A estratexia de consolidación da carga de traballo de VM baséase nunha heurística de primeiro axuste que se centra na carga da CPU medida e intenta minimizar os nós que teñen demasiada ou moi pouca carga dadas as limitacións de capacidade de recursos. Esta estratexia ofrece unha solución que resulta nun uso máis eficiente dos recursos do clúster mediante os seguintes catro pasos:
- Fase de descarga - procesamento de recursos sobreutilizados;
- Fase de consolidación: procesamento de recursos infrautilizados;
- Optimización da solución - reducindo o número de migracións;
- Desactivando os nós de cálculo non utilizados.
A estratexia require as seguintes métricas:
métricas
servizo
complementos
comentario
memoria
ningún
tamaño.raíz.disco
ningún
As seguintes métricas son opcionais, pero mellorarán a precisión da estratexia se están dispoñibles:
métricas
servizo
complementos
comentario
memoria.residente
ningún
cpu_util
ningún
Parámetros da estratexia: período — intervalo de tempo en segundos para obter a agregación estática da fonte de datos métricas (predeterminado, 3600).
Utiliza os mesmos métodos que a estratexia anterior. Máis detalles .
Equilibrio de carga de traballo — equilibrar a carga de traballo entre os nodos informáticos. O obxectivo ten tres estratexias: Estratexia de migración de balance de carga de traballo, estabilización de carga de traballo, Estratexia de equilibrio de capacidade de almacenamento.
A estratexia de migración de balance de carga de traballo executa migracións de máquinas virtuais baseadas na carga de traballo da máquina virtual do host. Unha decisión de migración tómase sempre que o % de utilización da CPU ou da RAM dun nodo supera o limiar especificado. Neste caso, a máquina virtual movida debería achegar o nodo á carga de traballo media de todos os nodos.
Requisitos
- Uso de procesadores físicos;
- Polo menos dous nodos informáticos físicos;
- Instalouse e configurouse o compoñente Ceilometer: ceilometer-agent-compute, que se executa en cada nodo de cálculo e a API de Ceilometer, ademais de recoller as seguintes métricas:
métricas
servizo
complementos
comentario
cpu_util
ningún
memoria.residente
ningún
Parámetros da estratexia:
parámetro
тип
predeterminado
описание
métricas
Corda
'cpu_util'
As métricas subxacentes son: 'cpu_util', 'memory.resident'.
límite
Número
25.0
Limiar de carga de traballo para a migración.
período
Número
300
Período de tempo acumulado Ceilómetro.
O método empregado é a migración.
A estabilización da carga de traballo é unha estratexia dirixida a estabilizar a carga de traballo mediante a migración en directo. A estratexia baséase nun algoritmo de desviación estándar e determina se hai conxestión no clúster e responde a ela activando a migración da máquina para estabilizar o clúster.
Requisitos
- Uso de procesadores físicos;
- Polo menos dous nodos informáticos físicos;
- Instalouse e configurouse o compoñente Ceilometer: ceilometer-agent-compute, que se executa en cada nodo de cálculo e a API de Ceilometer, ademais de recoller as seguintes métricas:
métricas
servizo
complementos
comentario
cpu_util
ningún
memoria.residente
ningún
Estratexia de equilibrio da capacidade de almacenamento (estratexia implementada a partir de Queens): a estratexia transfire discos dependendo da carga dos pools de Cinder. Unha decisión de transferencia tómase sempre que a taxa de utilización do grupo supera un limiar especificado. O disco que se está movendo debería achegar a piscina á carga media de todas as piscinas Cinder.
Requisitos e restricións
- Mínimo dúas piscinas Cinder;
- Posibilidade de migración de disco.
- Modelo de datos de clúster - Recolector de modelos de datos de clúster de Cinder.
Parámetros da estratexia:
parámetro
тип
predeterminado
описание
volume_limiar
Número
80.0
Valor límite dos discos para equilibrar volumes.
O método empregado é a migración do disco (volume_migrate).
Veciño ruidoso: identifique e migre un "veciño ruidoso": unha máquina virtual de baixa prioridade que está a afectar negativamente o rendemento dunha máquina virtual de alta prioridade en termos de IPC mediante un uso excesivo da caché de último nivel. Estratexia propia: Veciño ruidoso (o parámetro de estratexia utilizado é cache_threshold (o valor predeterminado é 35), cando o rendemento cae ata o valor especificado, iníciase a migración. Para que a estratexia funcione, está activada Métricas de LLC (Last Level Cache), último servidor Intel con soporte CMT, así como recoller as seguintes métricas:
métricas
servizo
complementos
comentario
cpu_l3_cache
ningún
Requírese Intel .
Modelo de datos de clúster (predeterminado): Recolector de modelos de datos de clúster Nova. O método empregado é a migración.
Traballar con este obxectivo a través do Dashboard non está totalmente implementado en Queens.
Optimización térmica - Optimizar o réxime de temperatura. A temperatura de saída (aire de escape) é un dos sistemas de telemetría térmica importantes para medir o estado térmico/carga de traballo dun servidor. O obxectivo ten unha estratexia, a estratexia baseada na temperatura de saída, que decide migrar as cargas de traballo a anfitrións térmicamente favorables (temperatura de saída máis baixa) cando a temperatura de saída dos anfitrións de orixe alcanza un limiar configurable.
Para que a estratexia funcione, necesitas un servidor con Intel Power Node Manager instalado e configurado , así como recoller as seguintes métricas:
métricas
servizo
complementos
comentario
hardware.ipmi.node.outlet_temperature
IPMI
Parámetros da estratexia:
parámetro
тип
predeterminado
описание
límite
Número
35.0
Limiar de temperatura para a migración.
período
Número
30
O intervalo de tempo, en segundos, para obter a agregación estatística a partir da fonte de datos métricas.
O método empregado é a migración.
Optimización do fluxo de aire - Optimizar o modo de ventilación. Estratexia propia: fluxo de aire uniforme mediante a migración en directo. A estratexia desencadea a migración da máquina virtual sempre que o fluxo de aire do ventilador do servidor supera un limiar especificado.
Para que a estratexia funcione necesitas:
- Hardware: nodos de cálculo < compatible con NodeManager 3.0;
- Polo menos dous nodos informáticos;
- O compoñente ceilometer-agent-compute e Ceilometer API instalados e configurados en cada nodo informático, que poden informar correctamente métricas como o fluxo de aire, a potencia do sistema e a temperatura de entrada:
métricas
servizo
complementos
comentario
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.nodo.temperatura
IPMI
hardware.ipmi.nodo.power
IPMI
Para que a estratexia funcione, necesitas un servidor con Intel Power Node Manager 3.0 ou posterior instalado e configurado.
Limitacións: o concepto non está destinado á produción.
Proponse utilizar este algoritmo con auditorías continuas, xa que só se prevé migrar unha máquina virtual por iteración.
As migracións en directo son posibles.
Parámetros da estratexia:
parámetro
тип
predeterminado
описание
fluxo de aire_limiar
Número
400.0
O limiar do fluxo de aire para a unidade de migración é de 0.1 CFM
limiar_entrada_t
Número
28.0
Limiar de temperatura de entrada para a decisión de migración
potencia_limiar
Número
350.0
Limiar de potencia do sistema para a decisión de migración
período
Número
30
O intervalo de tempo, en segundos, para obter a agregación estatística a partir da fonte de datos métricas.
O método empregado é a migración.
Mantemento de hardware - Mantemento de hardware. A estratexia relacionada con este obxectivo é a migración de zona. A estratexia é unha ferramenta para a migración automática e mínima de máquinas virtuais e discos en caso de necesidade de mantemento de hardware. A estratexia constrúe un plan de acción de acordo cos pesos: un conxunto de accións que teña máis peso serán planificadas antes que outras. Hai dúas opcións de configuración: action_weights e paralelización.
Limitacións: é necesario configurar os pesos das accións e a paralelización.
Parámetros da estratexia:
parámetro
тип
predeterminado
описание
compute_nodes
orde
ningún
Nodos de cálculo para a migración.
pools_almacenamento
orde
ningún
Nodos de almacenamento para a migración.
total_paralelo
número enteiro
6
O número total de actividades que se deben executar en paralelo.
paralelo_por_nodo
número enteiro
2
O número de accións realizadas en paralelo para cada nodo de cálculo.
paralelo_por_pool
número enteiro
2
O número de accións realizadas en paralelo para cada grupo de almacenamento.
prioridade
obxecto
ningún
Lista de prioridades para máquinas virtuais e discos.
con_volume_adxunto
booleano
Falso
Falso: as máquinas virtuais migraranse despois de migrar todos os discos. Verdade: as máquinas virtuais migraranse despois de migrar todos os discos conectados.
Elementos da matriz de nodos informáticos:
parámetro
тип
predeterminado
описание
src_node
corda
ningún
O nodo de cálculo desde o que se migran as máquinas virtuais (obrigatorio).
dst_node
corda
ningún
Calcula o nodo ao que están a migrar as máquinas virtuais.
Elementos da matriz de nodos de almacenamento:
parámetro
тип
predeterminado
описание
src_pool
corda
ningún
A agrupación de almacenamento desde a que se migran os discos (obrigatorio).
dst_pool
corda
ningún
A agrupación de almacenamento á que se migran os discos.
tipo_src
corda
ningún
Tipo de disco orixinal (obrigatorio).
tipo_dst
corda
ningún
O tipo de disco resultante (obrigatorio).
Elementos prioritarios do obxecto:
parámetro
тип
predeterminado
описание
proxecto
orde
ningún
Nomes de proxectos.
compute_node
orde
ningún
Calcula os nomes dos nodos.
pool_almacenamento
orde
ningún
Nomes das agrupacións de almacenamento.
computar
enumeración
ningún
Parámetros da máquina virtual [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
almacenamento
enumeración
ningún
Parámetros do disco [“tamaño”, “creado_en”].
Os métodos empregados son a migración de máquinas virtuais, a migración de discos.
Sen clasificar - un obxectivo auxiliar utilizado para facilitar o proceso de desenvolvemento da estratexia. Non contén especificacións e pódese utilizar sempre que a estratexia aínda non estea asociada a un obxectivo existente. Este obxectivo tamén se pode usar como punto de transición. Unha estratexia relacionada con este obxectivo é Actuator.
Creando un novo obxectivo
Motor de decisión de Watcher ten unha interface de complemento "obxectivo externo" que permite integrar un obxectivo externo que se pode acadar mediante unha estratexia.
Antes de crear un novo obxectivo, debes asegurarte de que ningún obxectivo existente satisfaga as túas necesidades.
Creando un novo complemento
Para crear un novo obxectivo, debes: ampliar a clase de destino, implementar un método de clase get_name() para devolver o ID único do novo destino que quere crear. Este identificador único debe coincidir co nome do punto de entrada que declare máis tarde.
A continuación, cómpre implementar o método de clase get_display_name() para devolver o nome de visualización traducido do destino que quere crear (non use unha variable para devolver a cadea traducida para que a ferramenta de tradución poida recollela automaticamente.).
Implementar un método de clase get_traducible_display_name()para devolver a clave de tradución (en realidade o nome de visualización en inglés) do teu novo destino. O valor de retorno debe coincidir coa cadea traducida a get_display_name().
Implementar o seu método obter_especificación_de_eficacia()para devolver a especificación de eficiencia para o seu obxectivo. O método get_efficacy_specification() devolve a instancia Unclassified() proporcionada por Watcher. Esta especificación de rendemento é útil no proceso de desenvolvemento do teu obxectivo porque se corresponde coa especificación baleira.
→
Arquitectura Watcher (máis detalles) ).
Compoñentes
API Watcher - un compoñente que implementa a API REST proporcionada por Watcher. Mecanismos de interacción: CLI, complemento Horizon, SDK de Python.
Watcher DB - Base de datos de observadores.
Aplicador Watcher — un compoñente que implementa a execución dun plan de acción creado polo compoñente Watcher Decision Engine.
Motor de decisión de Watcher - O compoñente responsable de calcular un conxunto de posibles accións de optimización para acadar o obxectivo da auditoría. Se non se especifica unha estratexia, o compoñente selecciona independentemente a máis adecuada.
Editor de métricas de Watcher - Un compoñente que recolle e calcula algunhas métricas ou eventos e publícaos no punto final do CEP. A funcionalidade do compoñente tamén pode ser proporcionada pola editorial Ceilometer.
Motor de procesamento de eventos complexos (CEP). — motor para o procesamento de eventos complexos. Por motivos de rendemento, pode haber varias instancias de CEP Engine executando simultáneamente, cada unha procesando un tipo específico de métrica/evento. No sistema Watcher, CEP desencadea dous tipos de accións: - rexistrar eventos/métricas relevantes na base de datos de series temporais; - enviar os eventos apropiados ao motor de decisións de Watcher cando este evento pode afectar o resultado da estratexia de optimización actual, xa que o clúster Openstack non é un sistema estático.
Os compoñentes interactúan mediante o protocolo AMQP.
→
Esquema de interacción con Watcher
Resultados das probas de Watcher
- Na páxina Optimización - Plans de acción 500 (tanto en Queens puros como nun stand con módulos Tionix), aparece só despois de que se inicie a auditoría e se xere un plan de acción; o baleiro ábrese normalmente.
- Hai erros na pestana Detalles da acción, non é posible obter o obxectivo e a estratexia da auditoría (tanto en Queens puros como nun stand con módulos Tionix).
- As auditorías co propósito de Dummy (proba) créanse e lánzanse normalmente, xéranse plans de acción.
- Non se crean auditorías para o obxectivo Non clasificado porque o obxectivo non é funcional e está pensado para unha configuración intermedia á hora de crear novas estratexias.
- As auditorías para o equilibrio da carga de traballo (estratexia de equilibrio da capacidade de almacenamento) créanse correctamente, pero non se xera un plan de acción. Non se precisa optimización da agrupación de almacenamento.
- As auditorías para o obxectivo de equilibrio de carga de traballo (estratexia de migración de equilibrio de carga de traballo) créanse correctamente, pero non se xera un plan de acción.
- As auditorías para o equilibrio da carga de traballo (estratexia de estabilización da carga de traballo) fallan.
- As auditorías para o obxectivo Veciño ruidoso créanse correctamente, pero non se xera un plan de acción.
- As auditorías para o mantemento do hardware créanse con éxito, o plan de acción non se xera na súa totalidade (xéranse indicadores de rendemento, pero non se xera a propia lista de accións).
- As edicións nas configuracións nova.conf (na sección predeterminada compute_monitors = cpu.virt_driver) nos nodos de cálculo e control non corrixen os erros.
- As auditorías dirixidas á consolidación de servidores (estratexia básica) tamén fallan.
- As auditorías para o propósito da consolidación do servidor (estratexia de consolidación da carga de traballo de VM) producen un erro. Nos rexistros hai un erro ao obter os datos de orixe. Discusión do erro, en particular .
Tentamos especificar Watcher no ficheiro de configuración (non axudou - como resultado dun erro en todas as páxinas de optimización, volver ao contido orixinal do ficheiro de configuración non corrixe a situación): [watcher_strategies.basic] datasource = ceilómetro, ñoquis - As auditorías para aforrar enerxía fallan. A xulgar polos rexistros, o problema segue sendo a ausencia de Ironic; non funcionará sen un servizo baremetal.
- As auditorías para a optimización térmica fallan. O rastrexo é o mesmo que para Server Consolidation (estratexia de consolidación da carga de traballo de VM) (erro de datos de orixe)
- As auditorías para a optimización do fluxo de aire producen un erro.
Tamén se atopan os seguintes erros de finalización da auditoría. Seguimento nos rexistros decision-engine.log (o estado do clúster non está definido).
→ Discusión do erro
Conclusión
O resultado da nosa investigación de dous meses foi a conclusión inequívoca de que, para obter un sistema de equilibrio de carga de traballo completo, teremos que, nesta parte, traballar estreitamente no perfeccionamento das ferramentas para a plataforma Openstack.
Watcher demostrou ser un produto serio e de rápido desenvolvemento cun enorme potencial, cuxo uso completo requirirá moito traballo serio.
Pero máis sobre isto nos próximos artigos da serie.
Fonte: www.habr.com