Microsoft Hyper-V vs VMware ESXi

por | Jun 28, 2019

Las plataformas hipervisoras desarrolladas por Microsoft y VMware son dos de las soluciones privativas tradicionalmente más utilizadas en proyectos de virtualización. Si te dedicas a este sector seguro que las conoces bastante bien pero, ¿sabes exactamente cuáles son las diferencias entre Hyper-V y ESXSi? En este artículo vamos a tratar de desgranarlas tomando como referencia la última versión de ambos software para que tengas claro cuál de estas dos soluciones se adaptaría mejor a las necesidades de tu proyecto.

Los dos son hipervisores de Tipo 1, se ejecutan directamente sobre el hardware y pertenecen a los denominados microkernelizados o monolíticos. Hyper-V permite crear y gestionar múltiples máquinas virtuales (MV) y proporciona una plataforma de virtualización sobre la que se puede construir cualquier infraestructura TI. Cada MV cuenta con un espacio aislado, sin interferir las unas con las otras. El hipervisor ESXi se incluye dentro de VMware vSphere, una plataforma de virtualización que contiene una serie de productos necesarios para crear una infraestructura de virtualización de servidores, como VMware Workstation o vCenter.

Antes existían múltiples contrastes entre ambos productos, pero desde el lanzamiento de Windows Server 2016, el hipervisor de Microsoft se asemeja bastante al de VMware. No obstante, todavía existen diferencias, sobre todo en los aspectos que se detallan a continuación:

REQUERIMIENTOS TÉCNICOS DE MICROSOFT HYPER-V Y VMWARE ESXI

A continuación resumimos los principales requerimientos de hardware y de sistema. Conviene asegurarse de los procesadores y hardware que soportan, ya que las últimas releases de los 2 productos han dejado de ser compatibles con ciertas versiones.

ESXi requiere una plataforma de servidores compatible, un equipo host con mínimo 2 núcleos de CPU, el bit NX/XD debe estar habilitado para la CPU en el BIOS, hace falta un mínimo de 4 GB de RAM física, una controladora Gigabit o Ethernet, un disco SCSI o un LUN RAID local que no sea de red con espacio sin particionar para las MVs y, para la serie ATA, hay que disponer de un disco conectado a través de controladoras SAS compatibles o controladoras SATA integradas compatibles.

En la lista de requerimientos de Hyper-V encontramos como mínimo un host con 4 GB de RAM, un procesador de 64 bits con traducción de direcciones de segundo nivel (SLAT) y la CPU tiene que ser compatible con la extensión del modo monitor de la máquina virtual. La BIOS del sistema tiene que tener habilitada la tecnología de virtualización y la prevención de ejecución de datos aplicada por hardware.

CARACTERÍSTICAS TÉCNICAS: MICROSOFT HYPER-V VS VMWARE ESXI

La escalabilidad de ambas soluciones difiere en ciertos aspectos. Cada una de las soluciones gana a la otra en algún campo. Por ejemplo, vSphere admite 768 Logical CPUs por host e Hiper-V 512. Pero Hyper-V soporta 24TB de memoria RAM por host y vSphere se queda en 16.

La gestión de la memoria es diferente. El producto de VMware cuenta con técnicas de optimización, de manera que con el mismo espacio libre se
pueden realizar acciones diferentes con cada producto. Ambos cuentan con gestión dinámica de memoria y ofrecen la posibilidad de añadir cargas de trabajo con memoria estática.

El almacenamiento de las dos plataformas se realiza con discos duros virtuales, pero vSphere almacena los datos dentro del disco de la máquina virtual mientras que Hyper-V utiliza el formato de disco duro virtual. Las dos soluciones cuentan con un sistema nativo propio para gestionar los datos de los dispositivos de almacenamiento.

Respecto a la configuración de máquinas virtuales, VMware vSphere tiene más opciones, como la posibilidad de usar diferentes controladores (NNVMe para discos y RDMA para redes) y el soporte de memoria persistente.

Tanto Hyper-V como vSphere cuentan con un completo set de herramientas de gestión que se pueden instalar en la plataforma: VMware Tools y Microsoft Integration Services.

La tecnología de snapshots funciona de forma diferente en las dos plataformas, incluso cuenta con una nomenclatura distinta, ya que VMware utiliza el término snapshots e Hyper-V checkpoints. En el caso de VMware son transitorios, se realizan 32 por MV, se almacenan en las MV y no se pueden realizar mientras el entorno está en producción. En Hyper-V son persistentes, se realizan 64 por MV, se almacenan en el servidor y luego se pueden exportar y sí que se pueden realizar en producción.

Las dos soluciones cuentan con su propia tecnología para monitorizar los cambios realizados en el sistema: VMware Changed Block Tracking (CBT) y Microsoft Resilient Change Tracking (RCT). Lo mismo sucede con las tecnologías que permiten la migración de cargas de trabajo en la infraestructura. Cada fabricante tiene sus propias herramientas que conviene analizar de forma separada: VMware vMotion e Hyper-V Live Migration.

En cuanto al soporte de sistemas operativos, como era de esperar, el producto de Microsoft soporta Linux, si bien se centra en el soporte de Windows. VMware se abre más en este sentido, ofreciendo compatibilidad con Windows, Unix, macOS y otros SO.

Los dos hipervisores tienen una infraestructura de hiperconvergencia (HCI por sus siglas en inglés) integrada a nivel de kernel. vSphere incorpora vSAN e Hyper-V Almacenamiento Space Direct (SD2). Las dos permiten desplegar clusters de 2 nodos, si bien es cierto que vSAN necesita un host virtual ESXi externo y SD2 requiere un archivo o nube externa.

Los dos fabricantes ofrecen características avanzadas en términos de seguridad, ya que es uno de los aspectos que más preocupa a las organizaciones hoy en día. VMware aplica técnicas de encriptación y cifrado para proteger los datos en todo momento, incluso en entornos de nube híbrida, y evitar el acceso sin autorización al sistema. Hyper-V se puede administrar a través de Active Directory y proporciona componentes avanzados creando entornos seguros para las MVs, máquinas blindadas, encriptación… Además, incorpora la protección avanzada contra amenazas y exploits de Windows Defender.

Las dos plataformas de virtualización se pueden administrar con herramientas de gestión. La diferencia en este caso es que para Hyper-V existe software gratuito como PowerShell o Windows Admin Center. Para vSphere lo normal es optar por vCenter, que es de pago, porque además si no contratamos este producto no tendremos acceso a muchas funcionalidades avanzadas, como la alta disponibilidad, vSphere Distributed Resource Scheduler, vSphere Almacenamiento DRS, vSphere Fault Tolerance, Cross-vCenter with Long Distance vMotion, VMware Host Profiles o vSphere Auto Deploy. Pero lo cierto es que muchas de estas características no están disponibles para el hipervisor de Microsof ni pagando.

LICENCIAMIENTO

Resulta algo complicado comparar el licenciamiento de ambos productos, ya que parten de un concepto diferente. El modelo de licenciamiento para Hyper-V es por procesador y para vSphere es por socket. Dos versiones similares serían Windows Server 2019 Datacenter Edition (que permite correr máquinas virtuales ilimitadas) y vSphere 6.7 Enterprise Plus Acceleration Kit para 3 servidores, con 16 cores y 2 CPUs en cada servidor.

Una de las diferencias significativas radica en el número de entornos de sistemas operativos virtuales y contenedores que incluye cada producto. Al contrario que la de VMware, la licencia de Microsoft viene con un número ilimitado. Además, en el caso de Hyper-V, una única licencia sirve para crear un cluster, pero para crear un cluster ESXi (vSphere) necesitas una licencia de vCenter.

Cabe recordar que Hyper-V viene dentro de Windows Server 2019, y en la versión standard se incluyen la mayoría de las características del hipervisor sin coste extra. En el caso de vSphere, si queremos emplear todas las funcionalidades, no queda otra que adquirir una licencia Enterprise Plus, cuyo precio es más elevado. Los dos productos tienen una versión free que, en el caso de Microsoft incluye todas las funcionalidades, mientras que la de VMware tiene limitaciones.

Debido a las diferencias en algunos aspectos y similitudes en otros, la idoneidad de una solución u otra dependerá siempre del proyecto en concreto, de los requerimientos técnicos específicos y de uso que se vaya a hacer de la plataforma. Así que convendría estudiar con detenimiento ambas soluciones aplicadas a los escenarios reales y valorar también las tecnologías propietarias de otros fabricantes, como Citrix XenServer, Nutanix Acropolis… y otras Open Source, cuya implantación resulta mucho más económica, como RHEV, oVirt, XCP-ng

Si vas a utilizar la plataforma de virtualización para desplegar y gestionar escritorios y vApp virtuales, recordamos que nuestro broker de conexiones UDS Enterprise es compatible con todas ellas, permitiendo incluso habilitar varias de manera simultánea.

Fuentes:

TechTarget

vInfrastructure Blog

Nakivo

COMPARTIR

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas recientes

Archivos


Mantente al día de toda la actualidad de UDS ENTERPRISE a través de nuestras redes sociales. ¡Síguenos!

Ir al contenido