Get best of the week

Evaluación integrada de métricas de carga del servidor

Al trabajar en uno de los bancos más grandes del país, tuve que enfrentar la tarea de evaluar la eficiencia del uso de recursos de aproximadamente 16 mil servidores. La tarea se formuló de manera muy simple: fue necesario desarrollar una metodología para evaluar las métricas de carga del servidor durante un período. Idealmente, la carga del servidor por período debe estimarse utilizando uno o varios (no más de 8) números.

Algunas palabras sobre las características del uso de servidores virtuales


Las grandes organizaciones (especialmente los bancos) tienen un abigarrado zoológico de aplicaciones heredadas implementadas en diferentes servidores que utilizan una variedad de tecnologías de virtualización. Una nube privada es una tecnología prometedora, pero en realidad, las grandes organizaciones utilizarán durante mucho tiempo varias plataformas de virtualización para implementar una variedad de aplicaciones.

A medida que las plataformas de virtualización evolucionan, llega un momento en el que nadie en la empresa puede comprender cuán eficientemente se utilizan los recursos. Incluso las herramientas de monitoreo más avanzadas no brindan una respuesta a esta pregunta debido a varios escenarios de uso del servidor. Por ejemplo, un departamento puede tener un servidor de informes que se cargará completamente solo por un período limitado de tiempo. Digamos 3-4 horas al final del mes. En escenarios de la vida real, nadie asigna recursos dinámicamente para dichos servidores; esto es difícil técnica y organizativamente. Los recursos se asignan específicamente para la carga máxima periódica del servidor, aunque ocurre con poca frecuencia.

Como resumen, en grandes organizaciones, los recursos de la granja virtual se gastan de manera extremadamente ineficiente.

A continuación, propongo una metodología con la que puede justificar fácilmente el aumento y la disminución de los recursos asignados al servidor virtual, independientemente del escenario.

Metodología


Para evaluar la carga de recursos, es necesario recopilar estadísticas de varios contadores; para evaluar la carga de recursos, se utilizarán varias métricas. Convencionalmente, los contadores se pueden dividir en 2 tipos (de acuerdo con la tasa de cambio): "rápido" y "lento". Un buen ejemplo de un contador "rápido" es el contador de carga del procesador (% CPU). Un ejemplo de contador lento es el porcentaje de espacio libre en el disco duro (% FreeSpace).
La evaluación de contadores lentos consiste en calcular el valor extremo (mínimo o máximo) de la métrica para el período. Este enfoque permite (por ejemplo, al evaluar el espacio libre en disco) estimar el recurso libre y, si es necesario, asignar volúmenes adicionales o reducir los actuales.

Para contadores rápidos, se utiliza un enfoque diferente. Las desventajas de usar métricas integrales simples (promedio, máximo, mínimo y mediana) para evaluar la dinámica de dichos contadores se describen aquí . Las desventajas comunes incluyen la falta de información sobre el aumento de las cargas (medio y pico). Si tomamos el valor máximo para el período como una métrica integral, entonces la presencia de valores atípicos (por ejemplo, carga instantánea de la CPU de hasta el 100% cuando se inicia el programa) no dará información objetiva.

En el articuloSe propone utilizar el cuantil 0.9 para estimar la métrica rápida (este es un valor que indica el nivel por debajo del cual se encuentra el valor observado en el 90% de las muestras). Con una carga de servidor uniforme de acuerdo con esta métrica, podemos estimar adecuadamente la carga promedio del procesador. Pero este enfoque tiene los mismos inconvenientes: la falta de información sobre el aumento de las cargas (medio y pico).

A continuación, como ilustración, el gráfico semanal y diario del contador% CPU. El valor máximo del contador en los gráficos fue del 100%.





El gráfico muestra que durante el período indicado hay una explosión de carga, que dura aproximadamente 3 horas. Para este contador, se calculó una variedad de métricas para la semana. La Figura 2 muestra que la mediana (línea verde, valor del 5%), promedio (amarillo, valor del 12%) y el cuantil 0.9 (rojo, valor del 27%) filtran el cambio de carga y se pierde información al respecto.

Como desarrollo de la idea de cuantiles, me gustaría proponer la idea de un cuantil móvil. Este es un análogo de la media móvil.pero el cuantil 0.9 se usa como una función de ventana. Además, utilizaremos 2 cuantiles deslizantes para estimar el nivel del contador: rápido con un período corto (1 hora) y lento con un período largo (24 horas). Un cuantil rápido filtrará las emisiones instantáneas y proporcionará información sobre la carga máxima. Un cuantil lento le permitirá estimar la carga promedio.

Como puede ver en los gráficos, los cuantiles móviles de 0.9 son características dinámicas (marrón - rápido, púrpura - lento). Para simplificar, evaluar el estado del contador como métrica que se propone utilizar:

  • el valor cuantil máximo con un período de 1 hora, que muestra la carga máxima continua del servidor para el período,
  • el valor cuantil promedio con un período de 24 horas, que muestra la carga promedio del servidor para el período.

En el gráfico, el valor máximo del cuantil rápido es la línea negra al 85%, el valor promedio del cuantil lento es la línea rosa al 30%.

Por lo tanto, al analizar la carga de recursos del servidor (de acuerdo con el contador del% de CPU), si tomamos el promedio del mes (12%) como una métrica, podemos tomar una decisión errónea de reducir los recursos asignados. La métrica cuántica de doble movimiento rápido / lento (85 y 30%) muestra que hay suficientes recursos asignados, pero no hay excedentes.

Decisión


La implementación de la evaluación de la eficiencia del uso de los recursos se ha descompuesto en 3 tareas:

  1. recopilación de datos
  2. desarrollo de metodología de evaluación
  3. implementación de metodología en la arquitectura actual

Arriba, examiné la tarea 2 de esta implementación, a continuación hablaremos un poco sobre la tercera tarea.

Los datos se recopilaron en la base de datos ClickHouse. Esta columna DBMS es ideal para almacenar datos de series temporales. Esto se discutió en detalle en ClickHouse Meetup el 5 de septiembre de 2019. Una comparación de ClickHouse con otros DBMS de series de tiempo se puede encontrar aquí .
Como resultado de la recopilación de datos, formamos varias tablas en las que los datos se organizaron línea por línea (los valores de cada contador se escribieron en una línea separada). Y, por supuesto, hubo problemas con los datos sin procesar.

El primer problema es la desigualdad de los intervalos entre las entradas del contador. Por ejemplo, si el período estándar de grabación del contador fue de 5 minutos, a veces hubo lagunas y el siguiente registro fue más de 5 minutos (hasta 20 minutos) del anterior.

El segundo problema es que a veces los datos del contador llegaron 2 o más veces (con valores diferentes) con la misma marca de tiempo.

Y el tercer problema: ClickHouse no tiene funciones de ventana.

Para resolver el primer problema, puede usar ASOF JOIN. La idea es bastante simple: para cada contador de cada servidor crear una tabla de manera uniforme con intervalos de tiempo llenos de manera uniforme. El uso de ASOF JOIN permite llenar los valores de la nueva tabla con los valores más cercanos de la tabla de datos sin procesar (se pueden configurar opciones de llenado similares a ffill y bfill).

La solución al segundo problema es la agregación con la elección del valor máximo en un momento dado.

Para resolver el tercer problema, se consideraron varias soluciones. Primero, el script Python fue rechazado debido a un rendimiento insuficiente. La segunda solución, copiar datos sin procesar a una base de datos MSSQL, calcular métricas y volver a copiar, parecía demasiado complicada de implementar. MSSQL también tiene funciones de ventana, pero no se necesita una función agregada. Uno podría estar perplejo y escribir su propia función SQL CLR. Pero esta opción fue rechazada debido a la excesiva complejidad.

Una solución de trabajo podría ser un script SQL para ClickHouse. Un ejemplo de este script se da a continuación. Para simplificar, busqué calcular solo el cuantil rápido para un solo contador para múltiples servidores. La solución no parece muy simple y no muy conveniente, pero funciona.

Como resultado, se creó un informe de prueba en PowerBI para demostrar la metodología.





Conclusión


En conclusión, me gustaría especular sobre el desarrollo de la solución. Si observa la solución desde el punto de vista de los almacenes de datos, puede ver que de esta manera se resuelve la tarea de crear un almacén de datos (Almacén de datos) a partir de una capa de datos sin procesar (Área de ensayo). Puede analizar la arquitectura, pero para ClickHouse como una base de datos de columnas, la normalización no es crítica (o incluso perjudicial).

El desarrollo adicional del repositorio se ve en la creación de tablas agregadas (día \ semana \ mes) con diferentes vidas (TTL). Esto evitará una hinchazón excesiva del almacenamiento.
El siguiente paso puede ser utilizar datos para análisis predictivos.

PD

El código y los datos para las pruebas se publican aquí .

More articles:


All Articles