В falamos dos nosos intentos de usar Watcher e proporcionamos un informe de proba. Periódicamente realizamos este tipo de probas para o equilibrio e outras funcións críticas dunha gran empresa ou nube de operador.
A alta complexidade do problema que se está a resolver pode requirir varios artigos para describir o noso proxecto. Hoxe publicamos o segundo artigo da serie, dedicado a equilibrar máquinas virtuais na nube.
Algunha terminoloxía
A compañía VmWare presentou a utilidade DRS (Distributed Resource Scheduler) para equilibrar a carga do ambiente de virtualización que desenvolveron e ofrecían.
Conforme
"VMware DRS (Distributed Resource Scheduler) é unha utilidade que equilibra as cargas informáticas cos recursos dispoñibles nun ambiente virtual. A utilidade forma parte dunha suite de virtualización chamada VMware Infrastructure.
Con VMware DRS, os usuarios definen regras para distribuír recursos físicos entre máquinas virtuais (VM). A utilidade pódese configurar para o control manual ou automático. As agrupacións de recursos de VMware pódense engadir, eliminar ou reorganizar facilmente. Se o desexa, pódense illar as agrupacións de recursos entre diferentes unidades de negocio. Se a carga de traballo nunha ou máis máquinas virtuais cambia drasticamente, VMware DRS redistribúe as máquinas virtuais en servidores físicos. Se a carga de traballo xeral diminúe, algúns servidores físicos poden quedar temporalmente fóra de liña e a carga de traballo consolidada".
Por que é necesario o equilibrio?
Na nosa opinión, o DRS é unha función imprescindible na nube, aínda que isto non significa que o DRS deba usarse sempre e en todas partes. Dependendo do propósito e das necesidades da nube, pode haber diferentes requisitos para o DRS e os métodos de equilibrio. Pode haber situacións nas que o equilibrio non sexa necesario. Ou mesmo prexudicial.
Para comprender mellor onde e para que clientes se necesita DRS, consideremos os seus obxectivos e obxectivos. As nubes pódense dividir en públicas e privadas. Aquí están as principais diferenzas entre estas nubes e os obxectivos dos clientes.
Nubes privadas / Clientes grandes empresas
Nubes públicas / Medianas e pequenas empresas, persoas
O principal criterio e obxectivos do operador
Proporcionar un servizo ou produto fiable
Reducir o custo dos servizos na loita nun mercado competitivo
Requisitos do servizo
Fiabilidade a todos os niveis e en todos os elementos do sistema
Rendemento garantido
Prioriza as máquinas virtuais en varias categorías
Seguridade da información e datos físicos
SLA e soporte XNUMX/XNUMX
Máxima facilidade para recibir o servizo
Servizos relativamente sinxelos
A responsabilidade dos datos é do cliente
Non é necesaria a priorización de VM
Seguridade da información a nivel de servizos estándar, responsabilidade no cliente
Pode haber fallos
Sen SLA, calidade non garantida
Soporte por correo electrónico
Non é necesaria a copia de seguranza
Características do cliente
Moi ampla gama de aplicacións.
Aplicacións legadas herdadas na empresa.
Arquitecturas personalizadas complexas para cada cliente.
Regras de afinidade.
O software funciona sen parar en modo 7x24.
Ferramentas de copia de seguridade ao voo.
Carga cíclica de clientes previsible.
Aplicacións típicas: equilibrio de rede, Apache, WEB, VPN, SQL
A aplicación pode deterse por un tempo
Permite a distribución arbitraria de máquinas virtuales na nube
Copia de seguridade do cliente
Carga media predicible estatísticamente cun gran número de clientes.
Implicacións para a arquitectura
Xeoclustering
Almacenamento centralizado ou distribuído
IBS redundante
Almacenamento local de datos en nodos de cálculo
Obxectivos de equilibrio
Distribución uniforme da carga
Máxima capacidade de resposta da aplicación
Tempo mínimo de atraso para o equilibrio
Equilibrar só cando sexa claramente necesario
Levar algúns equipos para mantemento preventivo
Reducir os custos do servizo e os custos dos operadores
Desactivando algúns recursos en caso de baixa carga
Aforrar enerxía
Redución de custos de persoal
Extraemos por nós mesmos as seguintes conclusións:
Para nubes privadasproporcionado a grandes clientes corporativos, o DRS pódese utilizar suxeito ás seguintes restricións:
- seguridade da información e tendo en conta as regras de afinidade á hora de equilibrar;
- dispoñibilidade de recursos suficientes en reserva en caso de accidente;
- os datos da máquina virtual están situados nun sistema de almacenamento centralizado ou distribuído;
- escalonar os procedementos de administración, copia de seguridade e equilibrio ao longo do tempo;
- balance só dentro dun agregado de hosts cliente;
- equilibrando só cando hai un forte desequilibrio, as migracións de VM máis eficaces e seguras (ao final, a migración pode fallar);
- equilibrar máquinas virtuais relativamente "tranquilas" (a migración de máquinas virtuais "ruidosas" pode levar moito tempo);
- equilibrar tendo en conta o "custo": a carga do sistema de almacenamento e da rede (con arquitecturas personalizadas para grandes clientes);
- equilibrio tendo en conta as características individuais de comportamento de cada VM;
- O equilibrio realízase preferentemente en horario non laborable (noites, fins de semana, festivos).
Para nubes públicasproporcionando servizos a pequenos clientes, DRS pódese usar con moita máis frecuencia, con capacidades avanzadas:
- ausencia de restricións de seguridade da información e regras de afinidade;
- equilibrio dentro da nube;
- equilibrio en calquera momento razoable;
- equilibrar calquera VM;
- equilibrar máquinas virtuais "ruidosas" (para non molestar aos demais);
- os datos da máquina virtual adoitan localizarse en discos locais;
- tendo en conta o rendemento medio dos sistemas e redes de almacenamento (a arquitectura da nube está unificada);
- balance segundo as regras xerais e as estatísticas de comportamento do centro de datos dispoñibles.
Complexidade do problema
A dificultade de equilibrar é que o DRS debe funcionar cunha gran cantidade de factores incertos:
- comportamento dos usuarios de cada un dos sistemas de información dos clientes;
- algoritmos para o funcionamento dos servidores de sistemas de información;
- comportamento dos servidores DBMS;
- carga en recursos informáticos, sistemas de almacenamento, rede;
- interacción dos servidores entre si na loita polos recursos na nube.
A carga dun gran número de servidores de aplicacións virtuais e bases de datos en recursos na nube ocorre co tempo, as consecuencias poden manifestarse e solaparse entre si cun efecto imprevisible nun tempo imprevisible. Mesmo para controlar procesos relativamente sinxelos (por exemplo, para controlar un motor, un sistema de calefacción de auga na casa), os sistemas de control automático necesitan utilizar complexos. algoritmos con feedback.
A nosa tarefa é moitas ordes de magnitude máis complexa, e existe o risco de que o sistema non poida equilibrar a carga aos valores establecidos nun tempo razoable, aínda que non haxa influencias externas dos usuarios.
Historia dos nosos desenvolvementos
Para resolver este problema, decidimos non comezar de cero, senón aproveitar a experiencia existente e comezamos a interactuar con especialistas con experiencia nesta área. Afortunadamente, a nosa comprensión do problema coincidiu completamente.
Etapa 1
Usamos un sistema baseado na tecnoloxía de redes neuronais e tentamos optimizar os nosos recursos en función del.
O interese desta etapa estaba en probar unha nova tecnoloxía, e a súa importancia estaba en aplicar un enfoque non estándar para resolver un problema onde, en igualdad de condicións, os enfoques estándar practicamente se esgotaran.
Lanzamos o sistema, e realmente comezamos a equilibrar. A escala da nosa nube non nos permitiu obter os resultados optimistas declarados polos desenvolvedores, pero estaba claro que o equilibrio estaba funcionando.
Ao mesmo tempo, tiñamos limitacións bastante serias:
- Para adestrar unha rede neuronal, as máquinas virtuais deben funcionar sen cambios significativos durante semanas ou meses.
- O algoritmo está deseñado para a súa optimización baseándose na análise de datos "históricos" anteriores.
- Adestrar unha rede neuronal require unha cantidade bastante grande de datos e recursos informáticos.
- A optimización e o equilibrio pódense facer relativamente raramente, unha vez cada poucas horas, o que claramente non é suficiente.
Etapa 2
Como non estabamos satisfeitos co estado das cousas, decidimos modificar o sistema e, para iso, responder pregunta principal -¿Para quen o facemos?
Primeiro - para clientes corporativos. Isto significa que necesitamos un sistema que funcione rapidamente, con esas restricións corporativas que só simplifican a implementación.
Segunda pregunta - Que queres dicir coa palabra "prontamente"? Como resultado dun breve debate, decidimos que podíamos comezar cun tempo de resposta de 5-10 minutos, para que as ondas a curto prazo non introduciran o sistema en resonancia.
Terceira pregunta – Que tamaño do número equilibrado de servidores escoller?
Este problema resolveuse por si só. Normalmente, os clientes non fan que as agregacións de servidores sexan moi grandes, e isto é consistente coas recomendacións do artigo para limitar as agregacións a 30-40 servidores.
Ademais, ao segmentar o grupo de servidores, simplificamos a tarefa do algoritmo de balance.
Cuarta pregunta – Que tan adecuada é unha rede neuronal para nós co seu longo proceso de aprendizaxe e o seu raro equilibrio? Decidimos abandonalo en favor de algoritmos operativos máis sinxelos para obter resultados en segundos.
Pódese atopar unha descrición dun sistema que utiliza tales algoritmos e as súas desvantaxes
Implementamos e lanzamos este sistema e obtivemos resultados alentadores: agora analiza regularmente a carga da nube e fai recomendacións para mover máquinas virtuais, que son en gran parte correctas. Aínda agora está claro que podemos conseguir un 10-15% de liberación de recursos para novas máquinas virtuais ao mesmo tempo que melloramos a calidade do traballo das existentes.
Cando se detecta un desequilibrio na RAM ou na CPU, o sistema envía comandos ao programador Tionix para realizar a migración en directo das máquinas virtuais necesarias. Como se pode ver dende o sistema de monitorización, a máquina virtual pasou dun host (superior) a outro (inferior) e liberou memoria no host superior (resaltado en círculos amarelos), ocupándoo respectivamente no inferior (resaltado en branco). círculos).
Agora estamos tentando avaliar con máis precisión a eficacia do algoritmo actual e tentamos atopar posibles erros nel.
Etapa 3
Parece que se pode calmar con isto, esperar a eficacia comprobada e pechar o tema.
Pero estamos empuxados a levar a cabo unha nova etapa polas seguintes oportunidades de optimización obvias
- A estatística, por exemplo, и mostra que os sistemas de dous e catro procesadores teñen un rendemento significativamente inferior ao dos sistemas dun só procesador. Isto significa que todos os usuarios reciben significativamente menos saída de CPU, RAM, SSD, LAN, FC comprados en sistemas multiprocesador en comparación cos dun só procesador.
- Os propios planificadores de recursos poden ter erros graves, sobre este tema.
- As tecnoloxías que ofrecen Intel e AMD para supervisar a memoria RAM e a caché permiten estudar o comportamento das máquinas virtuais e situalas de forma que os veciños "ruidosos" non interfiran coas máquinas virtuais "tranquilas".
- Ampliación do conxunto de parámetros (rede, sistema de almacenamento, prioridade da máquina virtual, custo da migración, a súa preparación para a migración).
En total
O resultado do noso traballo para mellorar os algoritmos de equilibrio foi a clara conclusión de que utilizando algoritmos modernos é posible conseguir unha optimización significativa dos recursos do centro de datos (25-30%) e, ao mesmo tempo, mellorar a calidade do servizo ao cliente.
Un algoritmo baseado en redes neuronais é certamente unha solución interesante, pero que precisa de máis desenvolvemento, e debido ás limitacións existentes, non é axeitado para resolver este tipo de problemas nos volumes típicos das nubes privadas. Ao mesmo tempo, o algoritmo mostrou bos resultados en nubes públicas de tamaño significativo.
Contarémosche máis sobre as capacidades dos procesadores, os programadores e o equilibrio de alto nivel nos seguintes artigos.
Fonte: www.habr.com