En Hemos hablado sobre los intentos de utilizar Watcher y presentamos un informe de pruebas. Realizamos estas pruebas periódicamente para el balanceo y otras funciones críticas de grandes nubes corporativas u operativas.
La alta complejidad de la tarea a resolver puede requerir varios artículos para describir nuestro proyecto. Hoy publicamos el segundo artículo del ciclo, dedicado al balanceo de máquinas virtuales en la nube.
Un poco de terminología
La empresa VmWare introdujo la herramienta DRS (Distributed Resource Scheduler) para el balanceo de carga en su entorno de virtualización desarrollado y ofrecido por ellos.
Como menciona
«VMware DRS (Planificador de Recursos Distribuidos) es una herramienta que equilibra las cargas computacionales con los recursos disponibles en un entorno virtual. La herramienta es parte del paquete de virtualización llamado VMware Infrastructure.
Con VMware DRS, los usuarios definen las reglas para repartir los recursos físicos entre las máquinas virtuales (VM). La herramienta se puede configurar para gestión manual o automática. Los grupos de recursos de VMware pueden ser fácilmente añadidos, eliminados o reorganizados. Si se desea, los grupos de recursos pueden estar aislados entre diferentes unidades de negocio. Si la carga de trabajo de una o varias máquinas virtuales cambia drásticamente, VMware DRS redistribuye las máquinas virtuales entre los servidores físicos. Si la carga de trabajo total disminuye, algunos servidores físicos pueden ser apagados temporalmente y la carga de trabajo consolidarse.»
¿Para qué sirve el balanceo?
En nuestra opinión, DRS es una función obligatoria en 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 los métodos de balanceo. Es posible que haya situaciones en las que el balanceo no sea necesario en absoluto. O incluso sea perjudicial.
Para entender mejor dónde y para qué clientes es necesario DRS, consideremos sus objetivos y necesidades. Las nubes se pueden dividir en públicas y privadas. Aquí están las principales diferencias entre estas nubes y los objetivos de los clientes.
Nubes privadas / Grandes clientes corporativos
Nubes públicas / Pequeñas y medianas empresas, individuos
Criterio y objetivos principales del operador
Proporcionar un servicio o producto confiable
Reducción de costos de servicios en la competencia del mercado
Requisitos del servicio
Confiabilidad en todos los niveles y en todos los elementos del sistema
Rendimiento garantizado
Priorización de máquinas virtuales en varias categorías
Seguridad de la información y física de los datos
SLA y soporte 24/7
Máxima simplicidad para obtener el servicio
Servicios relativamente simples
La responsabilidad de los datos recae en el cliente
No se requiere priorización de VM
Seguridad de la información a nivel de servicios estándar, responsabilidad del cliente
Pueden ocurrir fallos
Sin SLA, calidad no garantizada
Soporte por correo electrónico
La copia de seguridad no es obligatoria
Características del cliente
Un abanico muy amplio de aplicaciones.
Aplicaciones legadas, heredadas en la empresa.
Arquitecturas personalizadas complejas para cada cliente.
Reglas de afinidad.
Funcionamiento del software sin pausa en modo 24/7.
Herramientas de copia de seguridad "en caliente".
Carga cíclica predecible del cliente.
Aplicaciones típicas – balanceo de red, Apache, WEB, VPN, SQL
Puede haber una interrupción de la aplicación por un tiempo determinado
Se permite la distribución arbitraria de VM en la nube
Copia de seguridad a cargo del cliente
Carga promedio predecible estadísticamente con un gran número de clientes.
Consecuencias para la arquitectura
Geoclustering
Almacenamiento centralizado o distribuido de datos
SRK reservable
Almacenamiento local de datos en nodos de computación
Objetivos de balanceo
Distribución uniforme de la carga
Máxima capacidad de respuesta de las aplicaciones
Mínimo tiempo de retardo en el balanceo
Balanceo solo en caso de necesidad explícita
Llevar parte del equipo a mantenimiento preventivo
Reducción de costos del servicio y gastos del operador
Desconectar parte de los recursos en caso de baja carga
Ahorro de electricidad
Reducción de costos en personal
Llegamos a las siguientes conclusiones:
Para nubes privadas, proporcionadas a grandes clientes corporativos, DRS puede aplicarse considerando las limitaciones:
- seguridad de la información y consideración de las reglas de afinidad durante el balanceo;
- disponibilidad en reserva de un volumen suficiente de recursos en caso de emergencia;
- los datos de las máquinas virtuales se encuentran en un almacenamiento centralizado o distribuido;
- distribución temporal de procedimientos de administración, copias de seguridad y balanceo;
- balanceo solo dentro del conjunto de hosts del cliente;
- balanceo solo en caso de un fuerte desequilibrio, las migraciones de VM más efectivas y seguras (ya que la migración puede no tener éxito);
- balanceo relativo a máquinas virtuales "tranquilas" (la migración de máquinas virtuales "ruidosas" puede tardar mucho tiempo);
- balanceo teniendo en cuenta el "costo" — la carga en el almacenamiento y la red (en arquitecturas personalizadas para grandes clientes);
- balanceo considerando las características individuales del comportamiento de cada VM;
- el balanceo preferiblemente durante horas no laborables (noche, fines de semana, festivos).
Para nubes públicas,, que proporcionan servicios a pequeños clientes, DRS puede aplicarse con mayor frecuencia, con capacidades ampliadas:
- ausencia de restricciones de seguridad de la información y reglas de afinidad;
- balanceo dentro de la nube;
- balanceo en cualquier momento razonable;
- balanceo de cualquier VM;
- balanceo de máquinas virtuales "ruidosas" (para no interferir con las demás);
- los datos de las máquinas virtuales a menudo se encuentran en discos locales;
- consideración del rendimiento promedio del almacenamiento y la red (la arquitectura de la nube es única);
- balanceo según reglas generales y estadísticas de comportamiento del centro de datos.
Complejidad del problema
La complejidad del balanceo radica en que DRS debe trabajar con un gran número de factores inciertos:
- el comportamiento de los usuarios de cada uno de los sistemas de información de los clientes;
- los algoritmos de funcionamiento de los servidores de los sistemas de información;
- el comportamiento de los servidores de bases de datos;
- la carga en los recursos computacionales, almacenamiento y red;
- la interacción entre servidores en la lucha por los recursos de la nube.
La carga de un gran número de servidores virtuales de aplicaciones y bases de datos sobre los recursos de la nube se manifiesta a lo largo del tiempo, los efectos pueden aparecer y superponerse con resultados impredecibles en un tiempo impredecible. Incluso para gestionar procesos relativamente simples (por ejemplo, para controlar un motor, un sistema de calefacción de agua de una casa), los sistemas de control automático deben utilizar complejos con retroalimentación.
Nuestra tarea es significativamente más compleja, y existe el riesgo de que el sistema no pueda realizar un balanceo de carga a los valores establecidos en un tiempo razonable, incluso si no hay influencias externas por parte de los usuarios.
Historia de nuestros desarrollos
Para abordar este problema, decidimos no empezar de cero, sino basarnos en la experiencia existente, y comenzamos a interactuar con especialistas que tienen experiencia en este campo. Afortunadamente, nuestra comprensión de la problemática coincidía completamente.
Etapa 1
Utilizamos un sistema basado en tecnología de redes neuronales y tratamos de optimizar nuestros recursos con ello.
El interés de esta etapa radicaba en probar una nueva tecnología, y su importancia residía en aplicar un enfoque no estándar para resolver la tarea, donde en condiciones homogéneas los enfoques estándar prácticamente se habían agotado.
Pusimos en funcionamiento el sistema, y realmente hemos comenzado a realizar el balanceo. La escala de nuestra nube no nos permitió obtener resultados optimistas como los prometidos por los desarrolladores, pero era evidente que el balanceo estaba funcionando.
A pesar de ello, tenemos limitaciones bastante serias:
- Para entrenar la red neuronal, es necesario que las máquinas virtuales funcionen sin cambios significativos durante semanas o meses.
- El algoritmo está diseñado para optimizarse en base al análisis de datos "históricos" previos.
- Para entrenar la red neuronal se requiere un volumen considerable de datos y recursos computacionales.
- La optimización y el balanceo se pueden realizar con poca frecuencia, una vez cada pocas horas, lo cual es claramente insuficiente.
Etapa 2
Dado que la situación no era satisfactoria, decidimos modificar el sistema, y para ello responder a la pregunta principal – ¿para quién lo estamos haciendo?
Primero – para clientes corporativos. Así que necesitamos un sistema que funcione de manera oportuna, con las restricciones corporativas que solo simplifican su implementación.
Segunda pregunta – ¿qué se entiende por "de manera oportuna"? Después de breves debates, decidimos que podríamos basarnos en un tiempo de respuesta de 5 a 10 minutos, para que los picos momentáneos no resonaran en el sistema.
Tercer pregunta – ¿qué tamaño de la cantidad de servidores a balancear elegir?
Esta cuestión se resolvió por sí sola. Generalmente, los clientes no hacen que los grupos de servidores sean muy grandes, y esto está en línea con la recomendación del artículo de limitar los grupos a 30-40 servidores.
Además, al segmentar el grupo de servidores, facilitamos la tarea del algoritmo de balanceo.
Cuarta pregunta ¿Qué tan adecuada nos resulta una red neuronal con su largo proceso de aprendizaje y sus raros balanceos? Decidimos prescindir de ella a favor de algoritmos operativos más simples para obtener resultados en segundos.
Se puede familiarizar con la descripción del sistema que utiliza tales algoritmos y sus desventajas.
Implementamos y lanzamos este sistema y obtuvimos resultados alentadores: ahora analiza regularmente la carga de la nube y ofrece recomendaciones sobre el traslado de máquinas virtuales, las cuales son en gran medida acertadas. Incluso ahora se observa que podemos lograr un 10-15% de liberación de recursos para nuevas máquinas virtuales, mejorando la calidad del funcionamiento de las existentes.
Al detectar un desequilibrio en RAM o CPU, el sistema envía comandos al programador Tionix para realizar la migración en vivo de las máquinas virtuales necesarias. Como se puede ver en el sistema de monitoreo, la máquina virtual se trasladó de un host (superior) a otro (inferior) y liberó memoria en el host superior (marcado en círculos amarillos), ocupándola respectivamente en el inferior (marcado en círculos blancos).
Ahora estamos tratando de evaluar más precisamente la efectividad del algoritmo en funcionamiento y buscando posibles errores en él.
Etapa 3
A primera vista, podríamos estar tranquilos, esperar la eficacia probada y cerrar el tema.
Pero nos impulsan a llevar a cabo una nueva etapa las siguientes evidentes oportunidades de optimización.
- La estadística, por ejemplo, y muestra que los sistemas de dos y cuatro procesadores son significativamente menos eficientes que los de un solo procesador. Eso significa que todos los usuarios obtienen de los CPU, RAM, SSD, LAN, FC adquiridos en sistemas multiprocesador un rendimiento significativamente menor en comparación con los de un solo procesador.
- Los propios programadores de recursos pueden cometer errores graves, sobre este tema.
- Las tecnologías de monitoreo de RAM y caché ofrecidas por Intel y AMD permiten estudiar el comportamiento de las máquinas virtuales y ubicarlas de tal manera que los vecinos "ruidosos" no interfieran con las máquinas virtuales "tranquilas".
- Ampliación del conjunto de parámetros (red, almacenamiento, prioridad de la máquina virtual, costo de migración, preparación para la migración).
Total
El resultado de nuestro trabajo para mejorar los algoritmos de balanceo ha llevado a una conclusión clara de que, gracias a los algoritmos modernos, se puede lograr una optimización significativa de los recursos (25-30%) en los centros de datos, aumentando al mismo tiempo la calidad del servicio al cliente.
El algoritmo basado en redes neuronales es sin duda interesante, pero necesita un desarrollo adicional y, debido a las limitaciones existentes, no es adecuado para resolver este tipo de tareas en volúmenes típicos de nubes privadas. Sin embargo, en nubes públicas de gran tamaño, el algoritmo ha mostrado buenos resultados.
Hablaremos más sobre las capacidades de los procesadores, planificadores y balanceo de alto nivel en los próximos artículos.
Fuente: habr.com
