¿Cuándo mover un servidor virtualizado a físico?

La virtualización tiene algunos grandes beneficios, pero hay momentos en los que un servidor virtualizado necesita más rendimiento y debe pasar a la física.

Mi pregunta es, ¿cómo saber cuándo son estos tiempos? Estoy buscando datos medibles y métricas que muestren que mover un servidor a su propia caja física marcaría una diferencia significativa en el rendimiento. Personalmente, estoy interesado en Windows, pero presumiblemente los elementos esenciales son los mismos en todas las plataformas.

El único caso en el que tuve que llevar a cabo un V2P fue para una caja MS SQL que se había estado ejecutando en CPU de doble núcleo dual de 3.2Ghz (CPU total de 14.4Ghz) que migramos a un clúster ESX 2.5 donde el hardware subyacente era más nuevo con más núcleos más lentos (2.4Ghz IIRC). Agregando una sobrecarga de ~ 10% incluso con 4 vCPU, esta VM solo podría obtener una CPU agregada efectiva de 8-8.5Ghz. 60% de CPU máxima antes de que la migración se convirtiera en 90-100% después de la migración, el cliente quería espacio libre, así que volvimos a la física. Para responder a su pregunta específicamente, vimos que la caja se estaba ejecutando al 100% de CPU en todos los ámbitos en Perfmon y en el cliente VI. Una mejor solución (en mi opinión) hubiera sido actualizar a CPU más rápidas, pero hay casos extremos como este en los que eso no es económico, especialmente con la tendencia a una CPU más lenta '

Con ESX 4 podríamos aumentar una caja como esta hasta 8 vCPU, pero esa no era una opción en ese momento.

En cuanto a buscar límites de rendimiento que puedan indicar que necesita abandonar su VM y luego con un Windows Guest en un entorno VMWare, entonces la combinación de Perfmon y VI Client debería ser más que suficiente para encontrar cualquier VM que tenga un rendimiento limitado. . Agregue la posibilidad de obtener algunos análisis de SAN si puede, pero si el SAN muestra un problema, entonces seguramente estará reelaborando el almacenamiento para aislar y / o mejorar los volúmenes en los que se almacenan los discos virtuales de la VM. Lo mismo se aplica a cualquier otra combinación de sistema operativo / hipervisor: obtenga las estadísticas internas que pueda pero correlacione con la vista del hipervisor de lo que está sucediendo porque el 100% de la CPU que se informa dentro de una máquina virtual (por ejemplo) no necesariamente significa que el hipervisor nunca podría entregar más rendimiento,

No estoy de acuerdo con que un servidor virtual deba trasladarse a físico debido al rendimiento. Los hipervisores ahora están tan cerca del metal que prácticamente no hay (juego de palabras) ningún impacto en el rendimiento. Especialmente ahora que muchos fabricantes de placas incluyen hipervisores en el conjunto de chips. Si tomara dos servidores con hardware idéntico, uno con un solo invitado y otro con una copia exacta de ese invitado en el hardware físico, creo que sería difícil notar una diferencia en el rendimiento.

Sin embargo, hay otras razones por las que puede necesitar un servidor físico en lugar de virtual. Uno de ellos es la compatibilidad de hardware. Si su aplicación requiere hardware no estándar con su propio bus único, es posible que no pueda ejecutarlo en una máquina virtual.

Estoy ansioso por escuchar lo que otros tienen que decir. Gran pregunta

NOTA: Tenemos servidores que se virtualizaron y luego se volvieron a colocar en el mismo hardware solo para tener las capacidades de instantánea / vmotion que amamos.

No soy un experto en este tema, pero en general: las aplicaciones de E / S muy hambrientas (especialmente las que escriben poco y rápido) son las que obtienen su propio servidor físico.

Tampoco es muy difícil encontrarlos, solo ejecuta el monitor de rendimiento y busca altos tiempos de espera de E / S.

Además, las bases de datos de gama alta suelen tener su propio servidor dedicado, por varias razones:

1. Quieren almacenar en caché todo lo que pueden, el uso de RAM es enorme
2. Funcionan mejor con subprocesos en varios núcleos (8 vías es normal), y generalmente no desea asignar más de 1 CPU virtual a ningún servidor debido al bloqueo
3. Son muy hambrientos de E / S cuando cargan datos en caché, la latencia baja en E / S es clave.

Esto depende mucho del servicio que esté realizando.

Por lo general, miro los recursos que se están utilizando y determino si realmente son cuellos de botella para este huésped y los servicios que proporciona.

Esto de esta manera:

Si tiene un invitado de doble núcleo (2vSMP), 4 GB de RAM que ejecuta un servidor web (IIS) y no está maximizando las solicitudes de CPU y RAM, entonces tal vez el invitado no necesite más hardware.

Nos hemos encontrado con casos en los que ejecutar una base de datos Oracle en una plataforma de virtualización se acerca a la misma cantidad de rendimiento que un servidor de hardware de tamaño similar.

Obviamente, si desea tener un servidor de 16 núcleos como VM, es posible que tenga problemas para ver que funcione tan bien como el hardware dedicado.

Cuando la VM carece de recursos (o tal vez priva a otras VM de recursos), por ejemplo:

1. Cuando el IO de la VM no puede ser satisfecho a través del host
2. Cuando la VM necesita más ancho de banda de red del que es posible compartir la troncal
3. Cuando los procesos de la VM quieren más CPU de la que puede obtener, por ejemplo, si hay un solo proceso que está maximizando una CPU virtual
4. Si es Linux y necesita un tiempo muy preciso (si se está ejecutando en un host VMware Linux hosts bajo el tiempo de deriva VMware. Esto se puede aliviar mediante el uso de ntp, sin embargo, para aplicaciones que requieren un tiempo muy preciso, por ejemplo, Kerberos, puede considerar hardware real)
5. Cuando es Linux y necesita un disco muy confiable (si se está ejecutando en un host VMware, VMware ha tenido y creo que todavía tiene problemas SCSI en VMWare bajo ciertas condiciones. Se solucionó el problema, pero todavía ocurre, aunque con mucha menos frecuencia)

Diría que es cuando el servidor está en el punto en el que está consumiendo suficientes recursos del servidor para que no pueda compartir el hardware.

ESX, ESXi y Window Hyper V deberían brindarle un rendimiento casi real. Por lo tanto, siempre que una de las máquinas no esté utilizando el 90% de los recursos por sí sola, no debería necesitar pasar a un hardware real.

Las excepciones son que no querría cosas como sus 2 controladores de dominio en la misma caja si falla el hardware.

Dudo que haya una respuesta genérica para esto, pero si te preocupa el rendimiento, entonces eso es lo que tienes que mirar. Lo obvio sería verificar si está maximizando la CPU, E / S, ...

Pero también, las pruebas de rendimiento y los puntos de referencia también lo ayudarán a decidir si hay alguna penalización por ser virtual y si tener una sola VM en el host es sensato o no.

Primero debe identificar qué recurso es el cuello de botella.

El monitor de rendimiento de Windows ( perfmon ) proporciona muchos contadores para diversos aspectos, como cola de disco, estadísticas de memoria virtual, etc.

Si está vinculado a un disco, puede ser de gran ayuda dar a la máquina virtual acceso directo a un disco en lugar de algo así como un archivo vmx con VMWare.

Creo que todo depende de dos factores: