В Hablamos sobre nuestros intentos de utilizar Watcher y proporcionamos un informe de prueba. Periódicamente llevamos a cabo pruebas de este tipo para el equilibrio y otras funciones críticas de una gran empresa o de un operador de nube.
La alta complejidad del problema a resolver puede requerir varios artículos para describir nuestro proyecto. Hoy publicamos el segundo artículo de la serie, dedicado al equilibrio de máquinas virtuales en la nube.
Un poco de terminología
La empresa VmWare introdujo la utilidad DRS (Distributed Resource Scheduler) para equilibrar la carga del entorno de virtualización que desarrollaron y ofrecieron.
Según
“VMware DRS (Distributed Resource Scheduler) es una utilidad que equilibra las cargas informáticas con los recursos disponibles en un entorno virtual. La utilidad es parte de una suite de virtualización llamada VMware Infrastructure.
Con VMware DRS, los usuarios definen reglas para distribuir recursos físicos entre máquinas virtuales (VM). La utilidad se puede configurar para control manual o automático. Los grupos de recursos de VMware se pueden agregar, eliminar o reorganizar fácilmente. Si se desea, los grupos de recursos se pueden aislar entre diferentes unidades de negocio. Si la carga de trabajo en una o más máquinas virtuales cambia drásticamente, VMware DRS redistribuye las máquinas virtuales entre servidores físicos. Si la carga de trabajo general disminuye, es posible que algunos servidores físicos se desconecten temporalmente y la carga de trabajo se consolide".
¿Por qué es necesario el equilibrio?
En nuestra opinión, DRS es una característica imprescindible de la nube, aunque esto no significa que DRS deba utilizarse siempre y en todas partes. Dependiendo del propósito y las necesidades de la nube, pueden existir diferentes requisitos para DRS y métodos de equilibrio. Puede haber situaciones en las que no sea necesario realizar ningún equilibrio. O incluso perjudicial.
Para comprender mejor dónde y para qué clientes se necesita DRS, consideremos sus metas y objetivos. Las nubes se pueden dividir en públicas y privadas. Estas son las principales diferencias entre estas nubes y los objetivos del cliente.
Nubes privadas/clientes de grandes empresas
Nubes públicas / Medianas y pequeñas empresas, personas
El principal criterio y objetivos del operador.
Proporcionar un servicio o producto confiable.
Reducir el coste de los servicios en la lucha en un mercado competitivo.
Requisitos de servicio
Fiabilidad a todos los niveles y en todos los elementos del sistema.
Rendimiento garantizado
Priorice las máquinas virtuales en varias categorías
Seguridad de la información y de los datos físicos
SLA y soporte XNUMX horas al día, XNUMX días a la semana
Máxima facilidad para recibir el servicio
Servicios relativamente simples
La responsabilidad de los datos es del cliente.
No se requiere priorización de VM
Seguridad de la información a nivel de servicios estándar, responsabilidad del cliente.
Puede haber fallas
Sin SLA, calidad no garantizada
Soporte de correo electrónico
La copia de seguridad no es necesaria
Características del cliente
Muy amplia gama de aplicaciones.
Aplicaciones heredadas heredadas en la empresa.
Arquitecturas complejas personalizadas para cada cliente.
Reglas de afinidad.
El software funciona sin parar en modo 7x24.
Herramientas de respaldo sobre la marcha.
Carga de clientes cíclica predecible.
Aplicaciones típicas: equilibrio de red, Apache, WEB, VPN, SQL
La aplicación puede detenerse por un tiempo.
Permite la distribución arbitraria de VM en la nube
Copia de seguridad del cliente
Carga promediada estadísticamente predecible con una gran cantidad de clientes.
Implicaciones para la arquitectura
Geoagrupación
Almacenamiento centralizado o distribuido
SII reservado
Almacenamiento de datos local en nodos informáticos
Objetivos de equilibrio
Distribución uniforme de la carga
Máxima capacidad de respuesta de la aplicación
Tiempo mínimo de retraso para el equilibrio.
Equilibrar sólo cuando sea claramente necesario
Sacar algunos equipos para mantenimiento preventivo.
Reducir los costos de servicio y los costos del operador.
Deshabilitar algunos recursos en caso de baja carga
Ahorrar energía
Reducir los costes de personal
Sacamos las siguientes conclusiones por nosotros mismos:
Para nubes privadasProporcionado a grandes clientes corporativos, DRS se puede utilizar sujeto a las siguientes restricciones:
- seguridad de la información y teniendo en cuenta las reglas de afinidad al realizar el equilibrio;
- disponibilidad de recursos suficientes en reserva en caso de accidente;
- los datos de la máquina virtual se encuentran en un sistema de almacenamiento centralizado o distribuido;
- procedimientos asombrosos de administración, respaldo y equilibrio a lo largo del tiempo;
- equilibrar sólo dentro de un conjunto de hosts de clientes;
- equilibrar solo cuando hay un fuerte desequilibrio, las migraciones de VM más efectivas y seguras (después de todo, la migración puede fallar);
- equilibrar máquinas virtuales relativamente "silenciosas" (la migración de máquinas virtuales "ruidosas" puede llevar mucho tiempo);
- equilibrio teniendo en cuenta el "costo": la carga en el sistema de almacenamiento y la red (con arquitecturas personalizadas para grandes clientes);
- equilibrar teniendo en cuenta las características de comportamiento individuales de cada VM;
- El balance se realiza preferentemente en horas no laborables (noches, fines de semana, festivos).
Para nubes públicasAl brindar servicios a pequeños clientes, DRS se puede utilizar con mucha más frecuencia, con capacidades avanzadas:
- ausencia de restricciones de seguridad de la información y reglas de afinidad;
- equilibrio dentro de la nube;
- equilibrar en cualquier momento razonable;
- equilibrar cualquier VM;
- equilibrar máquinas virtuales "ruidosas" (para no molestar a los demás);
- los datos de las máquinas virtuales suelen estar ubicados en discos locales;
- teniendo en cuenta el rendimiento medio de los sistemas y redes de almacenamiento (la arquitectura de la nube está unificada);
- Equilibrio según reglas generales y estadísticas de comportamiento del centro de datos disponibles.
Complejidad del problema
La dificultad de equilibrar es que DRS debe trabajar con una gran cantidad de factores inciertos:
- comportamiento de los usuarios de cada uno de los sistemas de información de los clientes;
- algoritmos para el funcionamiento de servidores de sistemas de información;
- comportamiento de los servidores DBMS;
- carga de recursos informáticos, sistemas de almacenamiento, redes;
- interacción de servidores entre sí en la lucha por los recursos de la nube.
La carga de una gran cantidad de servidores de aplicaciones virtuales y bases de datos en los recursos de la nube ocurre con el tiempo, las consecuencias pueden manifestarse y superponerse entre sí con un efecto impredecible durante un tiempo impredecible. Incluso para controlar procesos relativamente simples (por ejemplo, para controlar un motor, un sistema de calentamiento de agua en casa), los sistemas de control automático necesitan utilizar sistemas complejos. algoritmos con retroalimentación.
Nuestra tarea es mucho más compleja y existe el riesgo de que el sistema no pueda equilibrar la carga con los valores establecidos en un tiempo razonable, incluso si no hay influencias externas de los usuarios.
Historia de nuestros desarrollos.
Para resolver este problema, decidimos no empezar desde cero, sino aprovechar la experiencia existente y comenzamos a interactuar con especialistas con experiencia en esta área. Afortunadamente, nuestra comprensión del problema coincidió completamente.
etapa 1
Utilizamos un sistema basado en tecnología de redes neuronales e intentamos optimizar nuestros recursos en base a él.
El interés de esta etapa era probar una nueva tecnología, y su importancia residía en aplicar un enfoque no estándar para resolver un problema donde, en igualdad de condiciones, los enfoques estándar prácticamente se habían agotado.
Lanzamos el sistema y realmente comenzamos a equilibrarlo. La escala de nuestra nube no nos permitió obtener los resultados optimistas declarados por los desarrolladores, pero estaba claro que el equilibrio estaba funcionando.
Al mismo tiempo, teníamos limitaciones bastante serias:
- Para entrenar una red neuronal, las máquinas virtuales deben funcionar sin cambios significativos durante semanas o meses.
- El algoritmo está diseñado para una optimización basada en el análisis de datos "históricos" anteriores.
- Entrenar una red neuronal requiere una cantidad bastante grande de datos y recursos informáticos.
- La optimización y el equilibrio se pueden realizar con relativa poca frecuencia: una vez cada pocas horas, lo que claramente no es suficiente.
etapa 2
Como no estábamos satisfechos con la situación, decidimos modificar el sistema y, para ello, responder pregunta principal – ¿Para quién lo hacemos?
Primero, para clientes corporativos. Esto significa que necesitamos un sistema que funcione rápidamente, con esas restricciones corporativas que sólo simplifican la implementación.
La segunda pregunta – ¿Qué quieres decir con la palabra “sin demora”? Como resultado de un breve debate, decidimos que podíamos comenzar con un tiempo de respuesta de 5 a 10 minutos, para que las sobretensiones a corto plazo no introdujeran resonancia en el sistema.
Tercera pregunta – ¿Qué tamaño del número equilibrado de servidores elegir?
Este problema se resolvió solo. Normalmente, los clientes no hacen que las agregaciones de servidores sean muy grandes, y esto es consistente con las recomendaciones del artículo de limitar las agregaciones a 30-40 servidores.
Además, al segmentar el grupo de servidores, simplificamos la tarea del algoritmo de equilibrio.
Cuarta pregunta – ¿Qué tan adecuada es para nosotros una red neuronal con su largo proceso de aprendizaje y su raro equilibrio? Decidimos abandonarlo en favor de algoritmos operativos más simples para obtener resultados en segundos.
Se puede encontrar una descripción de un sistema que utiliza tales algoritmos y sus desventajas.
Implementamos y lanzamos este sistema y obtuvimos resultados alentadores: ahora analiza periódicamente la carga de la nube y hace recomendaciones para mover máquinas virtuales, que en gran medida son correctas. Incluso ahora está claro que podemos lograr una liberación de recursos del 10 al 15% para nuevas máquinas virtuales y al mismo tiempo mejorar la calidad del trabajo de las existentes.
Cuando se detecta un desequilibrio en la RAM o la CPU, el sistema emite comandos al programador de Tionix para realizar la migración en vivo de las máquinas virtuales requeridas. Como puede verse en el sistema de monitoreo, la máquina virtual se movió de un host (superior) a otro (inferior) y liberó memoria en el host superior (resaltado en círculos amarillos), ocupándola respectivamente en el inferior (resaltado en blanco). círculos).
Ahora estamos tratando de evaluar con mayor precisión la efectividad del algoritmo actual y estamos tratando de encontrar posibles errores en él.
etapa 3
Parecería que podemos calmarnos al respecto, esperar a que se compruebe la eficacia y cerrar el tema.
Pero nos vemos empujados a llevar a cabo una nueva etapa por las siguientes oportunidades obvias de optimización.
- Las estadísticas, por ejemplo, и muestra que los sistemas de dos y cuatro procesadores tienen un rendimiento significativamente menor que los sistemas de un solo procesador. Esto significa que todos los usuarios reciben significativamente menos rendimiento de CPU, RAM, SSD, LAN, FC adquiridos en sistemas multiprocesador en comparación con sistemas de un solo procesador.
- Los propios programadores de recursos pueden tener errores graves, sobre este tema.
- Las tecnologías ofrecidas por Intel y AMD para monitorear la RAM y el caché permiten estudiar el comportamiento de las máquinas virtuales y colocarlas de tal manera que los vecinos "ruidosos" no interfieran con las máquinas virtuales "silenciosas".
- Ampliación del conjunto de parámetros (red, sistema de almacenamiento, prioridad de la máquina virtual, costo de la migración, su preparación para la migración).
En total
El resultado de nuestro trabajo para mejorar los algoritmos de equilibrio fue la conclusión clara de que utilizando algoritmos modernos es posible lograr una optimización significativa de los recursos del centro de datos (25-30%) y al mismo tiempo mejorar la calidad del servicio al cliente.
Un algoritmo basado en redes neuronales es ciertamente una solución interesante, pero necesita un mayor desarrollo y, debido a las limitaciones existentes, no es adecuado para resolver este tipo de problemas en los volúmenes típicos de las nubes privadas. Al mismo tiempo, el algoritmo mostró buenos resultados en nubes públicas de tamaño significativo.
Le contaremos más sobre las capacidades de los procesadores, programadores y equilibrio de alto nivel en los siguientes artículos.
Fuente: habr.com