Al implementar un solo servidor en un nuevo hardware, ¿lo virtualiza o no?

Hay algunas preguntas que he encontrado en ServerFault que sugieren este tema, y ​​aunque puede estar algo basado en opiniones, creo que puede caer en esa categoría "buena subjetiva" basada en lo siguiente:

Preguntas subjetivas constructivas:

* tend to have long, not short, answers
* have a constructive, fair, and impartial tone
* invite sharing experiences over opinions
* insist that opinion be backed up with facts and references
* are more than just mindless social fun

Así que fuera del camino.

Estoy ayudando a otro administrador del sistema que está reemplazando un servidor físico más antiguo que ejecuta Windows 2003 y está buscando no solo reemplazar el hardware sino también "actualizar" a 2012 R2 en el proceso.

En nuestras discusiones sobre su hardware de reemplazo, discutimos la posibilidad de que instale ESXi y luego convierta el "servidor" de 2012 en una máquina virtual y migre las aplicaciones / archivos / roles anteriores del servidor 2003 a la máquina virtual en lugar de a una instalación que no sea VM en el nuevo hardware.

No percibe en ningún momento en los próximos años la necesidad de mover cualquier otra cosa a una VM o crear VM adicionales, por lo que al final será un nuevo hardware que ejecuta una instalación normal o un nuevo hardware que ejecuta una sola VM en ESXi.

Mi propia experiencia se inclinaría hacia una VM aún, no hay una razón realmente convincente para hacerlo más que las posibilidades que puedan surgir para crear VM adicionales. Pero ahora existe el aspecto adicional de sobrecarga y administración del hipervisor, aunque he experimentado mejores capacidades de administración y capacidades de informes con una VM.

Entonces, con la premisa de esperar que esto pueda permanecer en la categoría "buena subjetiva" para ayudar a otros en el futuro, ¿qué experiencias / hechos / referencias / respuestas constructivas tiene que ayudar a apoyar cualquiera de los resultados (virtualizando o no un solo "servidor") ?

En el caso general, la ventaja de poner un servidor independiente en un hipervisor es a prueba de futuro. Hace que la expansión o las actualizaciones futuras sean mucho más fáciles, mucho más rápidas y, como resultado, más baratas. El principal inconveniente es la complejidad y el costo adicionales (no necesariamente desde el punto de vista financiero, sino desde una perspectiva de horas hombre y tiempo).

Entonces, para tomar una decisión, me hago tres preguntas (y generalmente prefiero poner el servidor en un hipervisor, por lo que vale).

1. ¿Qué tan grande es el costo adicional del hipervisor?
   • Financieramente, generalmente es mínimo o inexistente.
     • Tanto VMware como Microsoft tienen opciones de licencia que le permiten ejecutar un host y un solo invitado de forma gratuita, y esto es suficiente para la mayoría de los servidores independientes, con la excepción de que los servidores son especialmente intensivos en recursos.
   • Desde el punto de vista de la gestión y los recursos, determinar el costo puede ser un poco más complicado.
     • Básicamente duplica el costo de mantenimiento del sistema, porque ahora tiene dos sistemas para monitorear, administrar y mantenerse actualizado con parches y actualizaciones (el SO huésped y el SO host).
       • Para la mayoría de los usos, esto no es un gran problema, ya que no es terriblemente exigente mantener un servidor, aunque para algunas organizaciones especialmente pequeñas o con dificultades técnicas, esto puede ser una preocupación real.
     • También agrega a las habilidades técnicas requeridas. Ahora, en lugar de solo necesitar a alguien que pueda descargar actualizaciones de Windows Update, necesita a alguien que sepa lo suficiente para administrar y mantener el entorno de virtualización.
       • De nuevo, no suele ser un problema, pero a veces es más de lo que una organización puede manejar.
         
         
2. ¿Qué tan grande es el beneficio de la facilidad de actualización o expansión?
   • Esto se reduce a la probabilidad de expansión futura, porque obviamente, si no expanden o actualizan sus activos de servidor, este beneficio es cero.
     • Si este es el tipo de organización que solo va a llenar el servidor en una esquina y olvidarse de él durante 10 años hasta que deba ser reemplazado de todos modos, no tiene sentido.
     • Si es probable que crezcan organizativamente, o incluso solo técnicamente (por ejemplo, agregando nuevos servidores con diferentes roles, en lugar de simplemente tener un servidor todo en uno), esto proporciona un beneficio bastante sustancial.
       
       
3. ¿Cuál es el beneficio ahora ?
   • La virtualización brinda beneficios más allá de las pruebas futuras y, en algunos casos de uso, pueden ser sustanciales.
     • La más obvia es la capacidad de crear instantáneas y copias de seguridad triviales para restaurar antes de hacer algo en el sistema, por lo que si sale mal, puede revertirlo con un solo clic.
     • La capacidad de experimentar con otras máquinas virtuales (y jugar al juego "qué pasaría si") es otra de las que he visto entusiasmados a la gerencia. Sin embargo, para mi dinero, el mayor beneficio es la portabilidad adicional que obtienes al ejecutar un servidor de producción en un hipervisor. Si algo sale realmente mal y te encuentras en una situación de recuperación de desastres o restauración desde copias de seguridad, es casi infinitamente más fácil restaurar una imagen de disco en una máquina que ejecuta el mismo hipervisor que intentar hacer una restauración completa.

Creo que el sistema operativo que se está virtualizando es un factor importante, junto con los requisitos de rendimiento y el potencial de expansión / crecimiento. Los servidores actuales a menudo son excesivamente potentes para las aplicaciones y los sistemas operativos que utilizamos. En mi experiencia, la mayoría de los sistemas estándar de Windows no pueden hacer un uso eficiente de los recursos disponibles en un servidor moderno de doble socket . Con Linux, aproveché algunas de las herramientas de administración de recursos granulares ( cgroups ) y contenedores ( LXC ) para hacer un mejor uso de los sistemas físicos. Pero el mercado definitivamente está orientado hacia hardware optimizado para virtualización.

Dicho esto, en algunas situaciones he virtualizado sistemas individuales en lugar de instalaciones completas. Las razones comunes son:

• Licencias : el número cada vez menor de aplicaciones que otorgan licencias basadas en límites de núcleo rígido, socket o memoria ( sin tener en cuenta las tendencias en informática moderna ). Ver: ¿ Deshabilitar núcleos de CPU en BIOS?

• Portabilidad : la virtualización de un servidor abstrae la VM del hardware. Esto hace que los cambios en la plataforma sean menos disruptivos y permite que la VM haga referencia a dispositivos / componentes virtualizados estándar. He podido mantener sistemas decrépitos ( pero críticos ) de Windows 2000 en soporte vital utilizando este enfoque.

• Expansión futura : ahora tengo un cliente que tiene un controlador de dominio de Windows 2003 que se ejecuta en hardware de la era 2001. Estoy construyendo un nuevo sistema ESXi de host único para ellos que albergará un nuevo controlador de dominio R2 2012 para el ínterin. Pero seguirán más máquinas virtuales. En esta configuración, puedo ofrecer una expansión de recursos confiable sin costos de hardware adicionales.

La desventaja de hacer esto con un único host / VM es la administración. Vengo desde la perspectiva de VMware, pero en el pasado, ESXi era un poco más amigable con este acuerdo. Hoy en día, el requisito de vSphere Web Client y el acceso restringido a las funciones básicas hacen que la ejecución de una solución de host único ( y VM única ) sea menos atractiva.

Otras consideraciones son el monitoreo de hardware paralizado y una mayor complejidad relacionada con los periféricos externos comunes (dispositivos USB / unidad de cinta / copias de seguridad / soluciones UPS ). Los hipervisores de hoy realmente quieren ser parte de una suite de administración más grande.

Hay algunos beneficios al virtualizar un solo servidor. Las primeras cosas que vienen a la mente son

• Crear instantáneas
• Importar / Exportar máquinas virtuales (por ejemplo, exportar la máquina virtual como .OVF para que los desarrolladores puedan cargarla en la estación de trabajo o el reproductor para tener una copia exacta de un servidor)
• Clone o convierta fácilmente en una plantilla (para cuando decida que las máquinas virtuales son bastante buenas)
• Fácilmente disponible para agregar máquinas virtuales adicionales en el futuro

Creo que la más importante de ellas serían las capacidades de instantáneas. Usamos VMWare en toda nuestra empresa, por lo que para nosotros tendría sentido tener el servidor "listo" para cuando haya necesidad de más máquinas virtuales.

Esta no es una respuesta larga, pero de todos modos:

La razón más convincente para usar un hipervisor para un solo servidor, especialmente con algo como Windows Server es que tiene una abstracción total de hardware para el sistema operativo de producción y puede simplemente moverlo a un hardware de servidor completamente nuevo sin ningún problema, si surge la necesidad. Considero que esta es una característica realmente valiosa que supera con creces los inconvenientes de tener un hipervisor práctico innecesario ejecutándose en segundo plano.

No voy a proporcionar una respuesta tan detallada como lo han hecho otros, así que solo diré que me resulta cada vez más difícil justificar la instalación del sistema operativo del servidor en el metal desnudo en lugar de instalar un hipervisor (de su elección) y virtualizando las cargas de trabajo. Las ventajas de hacer esto, en mi opinión, son:

1. Coste-beneficio. A la larga, si necesito implementar cargas de trabajo adicionales, no tengo que pagar más hardware para esas cargas de trabajo adicionales. En algunos casos, cuando uso Hyper-V, incluso puedo ahorrar en mis costos de licencia.

2. Facilidad de implementación y redistribución.

3. Facilidad de implementar alta disponibilidad y conmutación por error.

4. Portabilidad. Es probable que pueda mover la VM a casi cualquier lugar si necesito desmantelar o externalizar el host actual.

5. Pruebas de futuro. Es posible que su compañero administrador de sistemas no vea ninguna necesidad futura de una infraestructura basada en hipervisor, pero supongo que dentro de 12 a 24 meses lo hará y se alegrará de haber elegido seguir la ruta de virtualización, si de hecho elige esa ruta .

6. Recuperación de desastres. Puedo hacer una copia de seguridad de una máquina virtual completa y restaurarla o replicarla a otro host en cuestión de minutos.

Y así sucesivamente y así sucesivamente...

Aquí hay algunas razones por las que diría que una VM es mejor:

• "KVM sobre IP" incorporado (más o menos): puede acceder a su servidor de forma remota en la consola sin necesidad de un KVM sobre IP. Algunas veces simplemente no quieres hacer algo a través de RDP y necesitas acceso a la consola. Con una VM, enciende la herramienta de administración de su elección (XenCenter, vSphere Client, etc.) y está en la consola de su VM.

• Con máquinas virtuales (y para servidores que no son máquinas virtuales, con mi KVM sobre IP) ya no tengo que permanecer en mi sala de servidores fría durante horas.

• Migración a nuevo hardware: aparte de la actualización del sistema operativo, para instalar su nuevo hardware, debe migrar el sistema, mover las cosas, etc. Con una VM, no tiene que hacer nada (generalmente). Actualiza su hardware, coloca los archivos VM en el nuevo hardware y se inicia.

• Si bien no se prevé una VM futura, " si la construyes, vendrán ". Querrá activar una nueva VM para probar algo y probar cosas nuevas, etc. Hay muchas más posibilidades.

• Las máquinas virtuales le brindan la capacidad de revertir con una instantánea, tomar una copia, hacer un clon de la máquina virtual (en tiempo de ejecución) y luego girarla, ya sea para probar algo antes de ponerlo en funcionamiento, o simplemente para tener un segundo primero. Hay muchas cosas que puede hacer con instantáneas de VM y similares.

• Redundancia: si agrega un segundo servidor VM, puede tener hardware redundante y, aunque no conozco los esquemas actuales de licencias de VMWare, XenServer ahora tiene XenMotion aparentemente parte del paquete gratuito, por lo que es posible que no se apliquen los costos generales.

Las razones por las que no usaría una VM:

• Sobrecarga: apenas, pero obviamente hay algo de sobrecarga.

• Más complejo de administrar, un poco más complejo pero fácil de aprender. Si no está buscando un entorno virtualizado enormemente grande, la capacitación es trivial.

Llego tarde, y siento que la gente ya ha hecho algunos de los puntos que hubiera querido hacer, pero resumiré brevemente:

• Preparado para el futuro: es más fácil agregar más RAM / CPU / disco / etc. a medida que surja la necesidad.
• Portabilidad: es más fácil pasar a un nuevo hardware, especialmente en caso de desastre.
• La virtualización es mejor que mantener un hardware viejo horrible para ejecutar algo de lo que no puede deshacerse.
• El software de gestión suele ser tan bueno como KVM o DRAC. (Además, si hereda algo donde el administrador anterior se fue sin dejar su contraseña, puede usarlo como "acceso físico" para entrar. Tan práctico como los cortadores de pernos que tengo en mi automóvil por la misma razón: anterior admin en un trabajo usó candados en el hardware. Heredé los servidores pero no la clave).
• Hacer instantáneas y hacer copias para que pueda probar procedimientos riesgosos antes de implementarlos.

Sin embargo, lo que nadie ha mencionado todavía y probablemente debería mencionarse: si está en el tipo de tienda donde la gente puede necesitar un servidor de prueba, y es probable que resuelva esa necesidad agarrando un escritorio de repuesto y abofeteando un sistema operativo del servidor en él, poder ofrecerles una VM probablemente se adaptará mucho mejor a sus necesidades. La virtualización del nuevo servidor puede ser la "razón" para permitir una futura expansión virtual. (Y, francamente, si no estás en ese tipo de tienda, probablemente ya tengas virtualización).

Por supuesto, no todo se virtualiza. Califiqué el hardware físico para el software de administración que incluía PXE al describirles lo que tendrían que hacer para desactivar la descarga del segmento TCP ( PXE se ejecutó como un perro con una sola pierna con TSO activado , pero habrían tenido que desactivarlo para toda la VLAN virtual, y no estaban dispuestos a hacerlo). Entonces, si el nuevo servidor es algo lo suficientemente especializado como para no ser adecuado, bueno, no importa.

Pero salvo ese tipo de especialización, valdría la pena deshacerme de un montón de máquinas (potencialmente no administradas) de clase PC que ejecutan sistemas operativos de servidor, ahora o en el futuro.

Absolutamente, virtualizo siempre que puedo. Esto me permite prepararme para hacer lo siguiente en el futuro:

• Copias de seguridad completas del sistema que son mucho más fáciles de hacer y, a menudo, también más baratas.
• El sistema operativo puede ser portátil, puedo mover la VM a otro host si lo necesito, con o sin tiempo de inactividad y agrupamiento, no importa en este momento
• Las licencias de Windows pueden volverse más baratas bajo ciertas condiciones
• Cuando tengo poco hardware, puedo usar sistemas de producción para probar actualizaciones (no es la mejor práctica, sino presupuesto, presupuesto ...), después de tomar una instantánea. No se puede hacer eso en un host normal, a menos que se inicie desde una SAN costosa
• Al obtener el hardware de servidor final más bajo posible, sigo obteniendo más recursos de los que podría necesitar para un rol de servidor específico. También podría obtener un mejor hardware y usarlo todo con máquinas virtuales.
• Las funciones de virtualización a menudo pueden reemplazar software innecesario. Por ejemplo, solía configurar doubletake y nunca fallaba mucho, para configurar réplicas DR de servidores Windows. Con la virtualización, puedo hacerlo a nivel de hipervisor, utilizando tecnologías mucho más baratas y ejecutando soluciones más confiables y flexibles.

En resumen, a menos que el servidor vaya a ejecutar un software específico que tiene limitaciones, prohibiendo que se virtualice (generalmente se requieren estrictas latencias de red o disco IO, y con el hardware adecuado, incluso con la virtualización se pueden lograr) Intento mantener las cosas lo más virtual posible

Una de las razones por las que puedo pensar a favor de virtualizar un solo servidor en una VM en un solo host es la capacidad que le brinda para luego meterse con un entorno de prueba para ese "servidor".

Si el hardware es más que capaz, puede clonar la máquina virtual del servidor y eliminar sus capacidades de NIC / red y aislar ese clon como una "plataforma de prueba" para meterse antes de probar lo mismo en el servidor de "producción". Un ejemplo sería si el servidor está ejecutando un software ERP y desea probar qué sucedería si ejecutara un script en particular contra el software / base de datos ERP. Puede hacerlo primero en la máquina virtual clonada como prueba. Esto podría hacerse junto con una instantánea de la máquina virtual en vivo antes de la implementación, con el beneficio adicional de saber que debería funcionar bien.

La creación del mismo entorno de "prueba" clonado podría hacerse con un P2V de un servidor físico existente, pero luego necesitaría un host físico adicional para colocar su nueva máquina virtual de prueba ... en lo anterior, todo puede residir en el mismo físico hardware (que hoy en día es casi siempre excesivo para una sola VM)

Si su caso de uso no requiere el 100% de la potencia del hardware dedicado, entonces me volvería virtual cada vez. Proporciona flexibilidad, facilidad para instantáneas y acceso a la consola integrada (aunque también debe usar la administración fuera de banda)

Un único punto que es bastante tangencial a la pregunta principal:

Recientemente tuve una máquina virtual cuyo disco no era lo suficientemente grande. Estaba ejecutando algo que generaba grandes cantidades de datos en una base de datos relacional, que por razones de rendimiento tenía que estar en la misma máquina.

Después de expandir la imagen del disco dos veces, llegué al escenario donde no quedaba suficiente espacio en el host para copiar y expandir la imagen de forma segura nuevamente. Me habría ahorrado un par de días trabajando para hacerlo desde el principio en una máquina dedicada, incluso si fuera una PC barata, no un servidor de alto rendimiento.

Con una máquina dedicada, puede apagarla y agregar más discos. Si se trata de un servidor que ejecuta otras máquinas virtuales, a menos que tenga bahías de intercambio en caliente de repuesto, es posible que tenga un problema para apagarlo.