Si está hablando de un host de vSphere, es posible que vea u escuche a las personas referirse a él como ESXi o, a veces, como ESX. No, alguien no solo dejó caer la i, había una versión anterior del hipervisor de vSphere llamada ESX. También es posible que escuche que ESX se conoce como ESX classic o ESX full form.
Hoy quiero echar un vistazo a ESX vs ESXi y ver cuál es la diferencia entre ellos. Más importante aún, quiero analizar algunas de las razones por las que VMware cambió la arquitectura del hipervisor de vSphere a partir de 2009.
En Esta Guía
¿Qué es ESX? (Elastic Sky X)
¿Se pregunta qué es ESX? ESX significa Elastic Sky X. ESX es como se llamaba originalmente el hipervisor de metal desnudo de VMware que todos conocemos y amamos. Realmente es donde comenzó la virtualización.
Para la lección de historia de VMware de hoy, vamos a comenzar con ESX. ESX era lo que originalmente se llamaba el hipervisor de metal desnudo de VMware. Si bien la funcionalidad de los hosts ESXi de hoy en día es muy similar (aunque mucho más avanzada) a ESX, hay algunas diferencias arquitectónicas importantes.
La principal diferencia fue la consola de servicio ESX. De hecho, mi primera entrada de blog fue dedicada a la consola de servicio ESX.
Piense en la consola de servicios como una pequeña máquina virtual que se ejecutaba junto a sus máquinas virtuales invitadas y proporcionaba acceso de administración al host ESX. La consola de servicios le permitió iniciar sesión en ESX y emitir comandos esxcfg en una línea de comandos para configurar su host.
Aquí hay una representación muy simple de cómo se veía:
Además de acceder a la línea de comandos, puede descargar e instalar casi cualquier agente que desee en la consola de servicios ESX, como agentes para la supervisión de hardware, copias de seguridad o, bueno, cualquier cosa que realmente desee.
Los agentes de administración de ESX también vivían aquí en la consola de servicios.
La consola de servicio habló con el VMkernel, que es básicamente el cerebro de su host ESX o ESXi.
Antes de hablar más sobre el VMkernel, echemos un vistazo a lo que cambió con ESXi.
¿Qué es ESXi? (Integrado en ESX)
¿Se pregunta qué es ESXi? Es la próxima generación del hipervisor ESX de VMware. ESXi significa ESX integrated.
Cuando se creó ESXi, VMware integró la funcionalidad de la consola de servicios en el VMkernel, de la siguiente manera:De nuevo, este es un diagrama muy simple, pero puede ver cuáles fueron los cambios principales, el más grande que es eliminar la consola de servicios por completo de la arquitectura ESXi.
Por mucho que me resistiera a este cambio en ese momento, tenía sentido por varias razones. Recuerde, ESXi salió con vSphere 4 en 2009, que fue el auge de la virtualización. Todos estaban virtualizando todo en el sitio y ejecutando sus cargas de trabajo de misión crítica en ESX.
Aquí hay un par de razones que VMware ha creído conveniente realizar este cambio.
Rendimiento y estabilidad para VMware ESXi
Aunque la consola de servicios solo podía usar hasta 800 MB de RAM (lo que podría ser significativo, lo creas o no, en algunos de los hosts de la era de 2009), aún podría causar estragos en el rendimiento y la estabilidad.
¿Recuerdas los agentes de terceros de los que hablamos? Bueno, en este caso, un mal agente podría hacer que el host ESX se detuviera, lo que no fue bueno.
Seguridad del hipervisor de VMware
La razón por la que fue tan fácil desarrollar e instalar agentes en la consola de servicio fue porque la consola de servicio era básicamente una máquina virtual linux ubicada en su host ESX con acceso al VMkernel.
Esto significa que la consola de servicio tenía que ser parcheada como cualquier otro sistema operativo Linux, y era susceptible a cualquier cosa que fuera un servidor Linux.
¿Ves un problema con eso y con la ejecución de cargas de trabajo de misión crítica? Absolutamente.
Al deshacerse de esta «máquina virtual de administración», VMware pudo reducir en gran medida la superficie de ataque de su hipervisor, que se estaba volviendo cada vez más importante a medida que la adopción crecía tan rápidamente.
Simplificación de la administración de virtualización
Al integrar estas funciones de administración en el VMkernel, la arquitectura ESXi se volvió mucho más simple que ESX. Como cualquier persona que haya diseñado algo puede decirte, cuanto más simple, mejor.
Por ejemplo, en lugar de instalar un agente de terceros para la supervisión de hardware, VMware introdujo el Modelo de Información Común o CIM. Esto permitió que los datos de hardware se vieran fácilmente en vCenter server y que las plataformas de administración de hardware comunes accedieran a ellos a través de vCenter.
Para obtener una excelente visión general del CIM, no deje de visitar este blog en el sitio de VMware. Es de 2011, y explica maravillosamente este gran cambio en la arquitectura ESX vs ESXi.
Esto no solo simplificó la administración, sino que también aumentó la estabilidad y la seguridad de ESXi en su conjunto.
¿Qué es el VMkernel?
Hemos hablado mucho sobre el VMkernel, que es el cerebro de ESXi.
Quiero darle una visión general simple para que pueda comenzar a comprender realmente sus capacidades.
Como dije, el VMkernel es el cerebro de la operación. Maneja cosas como la programación de recursos y la administración de recursos.
Las pilas de redes y almacenamiento también se encuentran en el VMkernel, y los controladores de dispositivo hosts de ESXi también se manejan en el VMkernel.
¿Qué son los puertos VMkernel?
En los días de ESX, nos conectamos a nuestros hosts con un puerto de consola de servicio especial. Esto se configuró durante el proceso de instalación de ESX, por lo que pudimos conectarnos a nuestros hosts para continuar configurándolos y administrándolos.
A partir de ESXi, configuramos un puerto VMkernel para la administración. Hoy en día, los puertos VMkernel sirven para muchos más propósitos que solo la administración, ya que el producto vSphere ha avanzado enormemente.
Cuando se estrenó ESXi por primera vez, los puertos VMkernel se configuraron para Administración, vMotion y almacenamiento basado en IP si lo estaba utilizando. Si está configurando un puerto VMkernel para almacenamiento, simplemente no le dice a vSphere que es para un propósito especial como los mencionados anteriormente. Esto se debe a que va sobre la pila TCP/IP predeterminada en vSphere.
Los puertos VMkernel, por supuesto, existían antes de ESXi, pero a menos que estuviera utilizando almacenamiento IP o vMotion (que en los primeros días se creía o no que no se usaban comúnmente), probablemente nunca había configurado un puerto VMkernel antes.
Hoy en día, como puede ver, hay muchas más aplicaciones para usar puertos VMkernel. Puede obtener más información al respecto en la Guía de redes VMkernel de VMware.
ESX vs ESXi Ni siquiera es una Comparación
Cuando salió ESXi por primera vez, muchos administradores de vSphere, incluido yo mismo, estaban obsesionados con comparar ESX vs ESXi. Estábamos tan acostumbrados a la consola de servicios y a las operaciones de vSphere que supuso un gran cambio de paradigma.
Recuerdo que utilicé específicamente una herramienta en la consola de servicios para administrar mi gran entorno ESX. Antes de ESXi, cosas como PowerCLI no se usaban ampliamente porque no había razón para hacerlo, solo se usaban los comandos esxcfg en la consola de servicios.
El Kit de herramientas de infraestructura de VMware (para Windows), o el Kit de herramientas VI fue el predecesor de PowerCLI, ni siquiera se lanzó hasta julio de 2008. En retrospectiva, pudo ver a VMware preparando el escenario para el futuro de su plataforma, asegurando el rendimiento, asegurando la base de código y optimizando la capacidad de administración.
Seamos realistas, ESX como sabíamos que no iba a soportar la trayectoria ascendente continua de vSphere. VMware tuvo que tomar medidas para preparar su producto en el futuro para lo que estaba por venir.
En vSphere 4, VMware ofrecía ESX y ESXi para permitir a los clientes realizar el cambio gradualmente, pero cuando llegó vSphere 5 en 2011, ESXi se convirtió en el hipervisor VMware vSphere.
En esta época también vimos surgir herramientas como Auto Deploy y PowerCLI comenzó a estar sobrealimentado.
También vimos más y más funciones en ESXi y vCenter. Si compara ESX 4.1, que fue la última versión de ESX full form con ESXi 6.7, probablemente se reiría de ESX si su primera versión de vSphere fuera 6 o superior.
Si bien estaba claramente a la vanguardia cuando salió por primera vez, los cambios realizados en la arquitectura ESX vs ESXi sentaron las bases para el avance y el crecimiento continuos de vSphere. Sin este cambio a ESXi, simplemente no estaríamos donde estamos hoy.