Estamos utilizando una aplicación con unos 300 usuarios simultáneos. Ahora todo está virtualizado: 1 VM como equilibrador de carga, 2 VM como servidor web (en este host ESXi hay otras 25 VM adicionales) y 1 servidor (bare metal) como SQL Server. Tenemos algunos problemas con el rendimiento y decidimos comprar hardware físico para mejorarlo.
No estoy seguro, ¿cómo podemos obtener un mejor rendimiento?:
Compramos 1 hardware de servidor en rack y ejecutamos ESXi con solo las 3 VM anteriores,
Compramos hardware de servidor en rack 1-1 para los servidores web e instalamos el servidor Windows solo con la aplicación. (y dejar el balanceador de carga como antes - VM)
- Compramos 3 servidores en rack para el equilibrador de carga y para los 2 servidores web.
Los usuarios están conectados con una interfaz web/aplicación de escritorio al servidor.
Gracias por tu ayuda, Drewo.
Respuesta1
Algunos datos a los que deberías encontrar la respuesta antes de decidir el camino a seguir:
Uso de CPU para las máquinas virtuales afectadas
- Desde el punto de vista del sistema operativo invitado, ¿el uso de CPU suele ser superior al 80 % y/o muestra estancamientos en lugar de picos en el uso? Es probable que su máquina virtual tenga falta de CPU. Agregue más vCPU (pero piense en posibles problemas de licencia).
- ¿Algunas vCPU de sus servidores están significativamente menos cargadas que otras? Podría tener un problema de escalado en su aplicación, donde simplemente colocar más vCPU en una sola VM (o en una máquina física) no ayudará.
- ¿Los
CPU readytiempos indican que el anfitrión se ha comprometido demasiado? Una regla general que a veces se ve es que desea menos del 5 % de tiempo de preparación promedio, pero mi experiencia es que incluso eso es demasiado para un sistema en el que realmente trabaja. Tenga en cuenta que si usa vCenter, el tiempo de preparación indicado está en milisegundos agregados desde la última actualización del gráfico. En la vista "en tiempo real", el gráfico se actualiza cada 20 segundos (=20000 ms), por lo que el porcentaje promedio por CPU para una VM se puede calcular usando la fórmula(indicated_ready_time * 100 / 20000) / number_of_vcpu.
Uso de RAM
(Siempre debe verificarse desde el sistema operativo invitado)
- ¿Generalmente por encima del 80%? Añade memoria.
- ¿Signos de pérdida de memoria? Repare la aplicación o prepárese para reiniciar/reiniciar con más frecuencia.
- ¿Signos de fuertes intercambios? Verifique si hay problemas de configuración. Añade memoria.
- ¿Tiene aplicaciones/procesos clave que "inexplicablemente" utilizan menos de 4 GB de memoria? Es posible que sea necesario reconstruirlos o reconfigurarlos para utilizar direccionamiento de 64 bits.
También verifique el rendimiento del disco y de la red para detectar problemas de latencia.
Dependiendo de cómo se amplíe su aplicación, podría ser una idea agregar más servidores web en lugar de agregar potencia de procesamiento o memoria a los existentes.
Una vez que tenga una idea de dónde están sus cuellos de botella y cuál es la mejor manera de utilizar su hardware, puede comenzar a elaborar un argumento comercial sobre qué comprar.
El argumento principal de las máquinas virtuales es que son más fáciles de administrar, realizar copias de seguridad y migrar en caso de falla del sistema. Permiten una mejor utilización de su hardware, siempre que en realidad no requieran todos los recursos que pueda ofrecerles, y si usa interfaces de red paravirtualizadas, la comunicación entre máquinas en el mismo host es tan rápida como la CPU puede administrar en lugar de estando limitado a velocidades de interfaz de red física.
Un sistema que se ejecuta directamente en una máquina física, por supuesto, no tendrá gastos generales debido al uso compartido de recursos, pero esto sólo es un beneficio si se puede utilizar la energía disponible.
Respuesta2
Sin una investigación de la causa de sus problemas de rendimiento y el conocimiento de su aplicación, no podrá saber cuál será la mejor y más fácil solución.
En el caso de que su problema sea realmente una falta de recursos de hardware, el monitoreo debería dejar bastante claro dónde está alcanzando los límites ahora y qué comprar (núcleos de CPU o velocidad de CPU, más memoria RAM, discos más rápidos) y dónde asignar eso. .
En mi experiencia, más de la mitad de los problemas de rendimiento se resolvieron más o menos fácilmente mediante un ajuste adecuado en lugar de dedicar más recursos de hardware al problema. La mayoría de los desarrolladores y muchos proveedores no tienen la capacidad o los recursos para probar sus aplicaciones y su base de datos con la misma cantidad de datos y una carga similar a la que se obtiene en producción, y hacen suposiciones y decisiones de diseño que no escalarán demasiado. bien en la práctica.
Un seguimiento cuidadoso le dará una idea de cuáles son sus cuellos de botella y qué es posible que deba abordar en la aplicación, la base de datos o el nivel de hardware.
Tenga en cuenta que el análisis y el ajuste del rendimiento son tanto una ciencia como un arte.
Los problemas de aplicación muy comunes que pueden abordarse fácilmente y que a menudo brindan beneficios significativos son
- índices faltantes en una base de datos
- agrupación de conexiones y almacenamiento en caché de consultas
- ajuste de límites de memoria, número de conexiones, sockets y subprocesos concurrentes de aplicaciones
Las fallas en el diseño de aplicaciones que son más difíciles de abordar son aquellas en las que hay demasiada lógica de procesamiento de datos en el front-end de la aplicación y las consultas a la base de datos son demasiado simples, no están vinculadas y devuelven demasiados datos (como con un SELECT * from GrowingDataSet): en su monitoreo, los síntomas de Estos pueden ser tan diversos como una alta carga de E/S del disco en el servidor de la base de datos, un alto consumo de memoria en el servidor de aplicaciones, enlaces de red saturados, cada uno de los cuales puede usarse para respaldar una decisión de compra de hardware diferente (actualización a SSD en el servidor de la base de datos, aumento RAM en el servidor de aplicaciones: actualice la red) probablemente ninguno de los cuales sea necesario cuando la aplicación comience a aplicar una mejor lógica y paginación en las consultas.