A menudo, una instalación de nuestra aplicación basada en Debian estable en el sitio se ejecuta en una máquina virtual, generalmente en VMware ESXi. En el caso general, no tenemos visibilidad o influencia sobre su entorno de virtualización y no tenemos acceso, por ejemplo, al cliente VMware vCenter o equivalente. Aquí me concentro en VMware, porque eso es, con mucho, el más común que vemos.
A nosotros nos gustaria:
- Informe al administrador de VMware de un cliente: puede ejecutar nuestra aplicación en, por ejemplo, su entorno VMware ESX, siempre que cumpla con los criterios de rendimiento X, Y y Z.
- Ser capaz de determinar si los criterios X, Y y Z se cumplen de hecho continuamente (por ejemplo, también ahora ), incluso en un sistema en ejecución (no podemos detener nuestra aplicación y ejecutar puntos de referencia, y un punto de referencia inicial no será suficiente, ya que el rendimiento en Los entornos virtuales cambian con el tiempo).
- Confíe en que si se cumplen los criterios X, Y y Z, tendremos recursos HW virtuales adecuados para ejecutar nuestra aplicación con un rendimiento satisfactorio.
Ahora, ¿qué son X, Y y Z?
Hemos visto una y otra vez que cuando hay problemas de rendimiento, el problema no es con nuestra aplicación, sino con el entorno de virtualización. Por ejemplo, otra máquina virtual usa toneladas de CPU, memoria o la SAN en la que los discos están realmente almacenados. Actualmente no tenemos forma de probar o refutar eso.
Teóricamente, también podría ser posible que a veces nuestra aplicación sea lenta ... ;-)
¿Cómo se determina la causa raíz de nuestros problemas de rendimiento: el entorno virtual o nuestra aplicación?
Normalmente hay 3 áreas para problemas de rendimiento CPU, memoria y E / S de DISCO.
UPC
En, por ejemplo, VMware, el administrador puede especificar Reserva y límite, expresado en MHz, pero ¿es, por ejemplo, 512 MHz en un host ESX exactamente igual a 512 MHz en otro host ESX, posiblemente en un clúster ESX completamente diferente?
¿Y cómo se mide si realmente lo conseguimos? Mientras nuestra aplicación se está ejecutando, tal vez podamos ver que tenemos una utilización de CPU del 212% en 4 CPU. ¿Es porque nuestra aplicación está haciendo mucho o porque otra VM en el mismo host está ejecutando una tarea intensiva de CPU y está usando toda la CPU?
Memoria (¿en globo?)
Si pedimos, por ejemplo, 16 GB de RAM, que a menudo se configura, pero debido a la expansión , en realidad solo obtenemos 4 GB y, sorprendentemente, nuestra aplicación funciona mal.
Uno puede preguntarle a las herramientas de VMware sobre el globo actual, pero descubrimos que a menudo miente (o al menos es inexacto). Hemos visto ejemplos en los que el sistema operativo cree que hay 16 GB de RAM total, la suma de la memoria residente (RSS) de todos los procesos es de 4 GB de RAM, pero solo hay 2 GB de RAM libre, incluso cuando las herramientas de VMware nos dicen que hay 0 globos: - (
Además, simplemente agregar RSS no es válido, ya que podría compartir fácilmente RAM, por ejemplo, memoria de copia en escritura, por lo que 512 MB + 512 MB no necesariamente significa 1 GB, pero podría significar algo menos. Por lo tanto, uno no puede simplemente restar RSS de todos los procesos para obtener una medida de la cantidad de RAM que debe estar libre y, por lo tanto, detectar un globo de forma confiable. Se pueden detectar algunos casos de globo, pero hay otros casos en los que el globo está en efecto, pero este método no puede detectarlo.
E / S de disco
Supongo que podríamos graficar con el tiempo la cantidad de lecturas y escrituras del disco, la cantidad de bytes leídos y escritos, y el% de espera IO. ¿Pero eso nos dará una imagen precisa de la E / S de disco? Me imagino que si hay un minero de bitcoin ejecutándose en otra VM que usa toda la CPU, nuestro% de espera de E / S aumentará, incluso si la SAN subyacente ofrece exactamente el mismo rendimiento, simplemente porque nuestros recursos de CPU disminuyen y, por lo tanto, IO espera ( que se mide en% ) sube.
En resumen, ¿qué lenguaje podemos usar para describir, por ejemplo, a un administrador de VMware, qué rendimiento necesitamos, de forma portátil y medible?
fuente
"It runs fine with x, y, and z"no es lo suficientemente preciso. Debe poder decir a sus clientes con precisión qué requiere su aplicación. Si le dan esos recursos y la aplicación funciona mal, entonces la pregunta no es"What do we need from a resource perspective?", pero"Why is it performing poorly even though the proper resources have been allocated?"Respuestas:
En serio, la mayoría de los administradores de VMware no son buenos en esto: mala comprensión de la gestión de recursos, a menudo sin conocimiento de Linux (ayuda) y falta de ancho de banda de tiempo. Creo que la mayoría de los administradores internos tienen dificultades para mantener un profundo conocimiento de virtualización.
¡Por suerte, hay un libro que puedes leer !
La mayoría de los entornos de VMware no son excelentes: diseño de clúster deficiente, mala planificación de recursos , almacenamiento deficiente (es decir, Synology NAS), HA mal configurada, sin monitoreo o parcheo.
VMware como organización nos falla: son particularmente malos diseminando información actualizada y promoviendo las mejores prácticas. Las búsquedas básicas de preguntas comunes generan resultados de revisiones anteriores y de 2009 de VMware, a pesar de que los procesos y diseños han cambiado con el tiempo.
Todas estas cosas trabajarán en tu contra.
Debe determinar los requisitos reales de su solución. Ser capaz de afirmar con precisión que su dispositivo requiere: 2 vCPU, 8 GB de RAM y 500 IOP de rendimiento de almacenamiento sería muy útil para alguien como yo.
El otro enfoque es observar un ambiente saludable o ideal y extrapolar las métricas desde allí.
Usted ha descrito problemas con ciertas implementaciones. ¿Cuáles fueron los problemas y los cuellos de botella?
Un ejemplo de una máquina virtual del tamaño correcto:
Un servidor de Exchange para una organización de 300 usuarios.
Ejemplos de monitoreo de recursos de VM.
Good-ish: - VM tiene el tamaño correcto. - La CPU está comprometida en exceso en el clúster, pero no estamos en conflicto.
Malo-ish:
fuente