Los centros de datos modernos rara vez ejecutan un solo sistema operativo por servidor físico. En su lugar, un hipervisor permite que un host físico ejecute muchas máquinas virtuales (VM) aisladas, y cada una cree tener su propia CPU, memoria, disco y tarjeta de red. Esto importa a los ingenieros de redes porque esas VM siguen necesitando VLAN (LAN virtuales), direcciones IP y políticas de seguridad, y gran parte de la conmutación ahora ocurre por software dentro del servidor. Entender las capas te ayuda a configurar el puerto del switch físico al que se conecta un host y a explicar por dónde viaja realmente un paquete.
Un hipervisor es la capa de software que crea y ejecuta las VM y reparte entre ellas el hardware físico. Un hipervisor tipo 1, también llamado bare-metal, se instala directamente sobre el hardware del servidor sin un sistema operativo de propósito general debajo. Algunos ejemplos son VMware ESXi, Microsoft Hyper-V y KVM (Kernel-based Virtual Machine). El tipo 1 es el que encuentras en centros de datos y nubes públicas porque es eficiente y estable. Un hipervisor tipo 2, también llamado hosted (alojado), se ejecuta como una aplicación sobre un sistema operativo normal, como Windows, macOS o un Linux de escritorio. Oracle VirtualBox y VMware Workstation son ejemplos. El tipo 2 es práctico para laboratorios, capacitación y pruebas en el escritorio, pero agrega sobrecarga porque el acceso al hardware pasa por el sistema operativo anfitrión.
Cada VM contiene un sistema operativo invitado completo con su propio kernel, bibliotecas y aplicaciones. Se conecta a la red mediante una NIC virtual (vNIC) que se enchufa a un switch virtual (vSwitch) dentro del hipervisor. El vSwitch reenvía tramas entre VM del mismo host sin que toquen nunca un cable físico, y se conecta a la red real a través de las NIC físicas del servidor. Esos uplinks suelen ser troncales 802.1Q para que distintas VM puedan estar en distintas VLAN. Por eso un puerto de switch conectado a un servidor con frecuencia se configura como troncal y no como puerto de acceso, a menudo con dos NIC hacia dos switches para tener redundancia.
Los contenedores adoptan un enfoque más ligero. En lugar de virtualizar el hardware, un motor de contenedores como Docker comparte el kernel del sistema operativo del host y empaqueta solo la aplicación y sus bibliotecas. Los contenedores arrancan en segundos, usan mucha menos memoria y disco que las VM, y caben muchos más en un solo host. La contrapartida es un aislamiento más débil: todos los contenedores de un host comparten un mismo kernel, y un contenedor debe construirse para ese tipo de kernel, así que los contenedores de Linux necesitan un kernel Linux. Las plataformas de orquestación como Kubernetes programan, escalan y conectan grandes cantidades de contenedores a través de muchos hosts.
Mantén claras las capas, porque el examen a menudo te pide ubicarlas. El hardware físico está en la base. Con el tipo 1, el hipervisor se ejecuta directamente sobre él y cada VM ejecuta su propio sistema operativo invitado. Con el tipo 2, un sistema operativo anfitrión se ejecuta sobre el hardware, el hipervisor corre como aplicación en ese sistema operativo y las VM funcionan por encima. Con los contenedores, un único sistema operativo del host ejecuta un motor de contenedores y los paquetes de aplicaciones aislados comparten su kernel. La virtualización ofrece beneficios que le gustan al examen: mejor aprovechamiento del hardware, aprovisionamiento más rápido a partir de plantillas, snapshots antes de cambios riesgosos y migración en vivo de VM en ejecución entre hosts para hacer mantenimiento.
Veamos un ejemplo práctico. Una empresa reemplaza doce servidores físicos poco utilizados por dos hosts que ejecutan un hipervisor tipo 1. Cada host tiene dos NIC físicas, una hacia cada uno de dos switches de acceso. Esos puertos del switch se configuran con switchport mode trunk y switchport trunk allowed vlan 10,20,30, y el vSwitch coloca la vNIC de cada VM en la VLAN 10, 20 o 30. Dos VM de la VLAN 20 en el mismo host se comunican a través del vSwitch sin salir del servidor. Mientras tanto, una desarrolladora prueba la aplicación web en su laptop con contenedores, y más tarde el equipo de operaciones ejecuta esas mismas imágenes de contenedor en hosts Linux del centro de datos.
Errores comunes: decir que Hyper-V o ESXi son de tipo 2 porque ves una consola de administración en un escritorio (el hipervisor en sí es bare-metal); pensar que cada contenedor lleva su propio kernel; suponer que un contenedor de Windows se ejecuta de forma nativa sobre un kernel Linux; configurar como puerto de acceso un puerto que da a un servidor y luego preguntarse por qué solo funcionan las VM de una VLAN; y olvidar que el tráfico entre VM de un mismo host puede no aparecer nunca en el switch físico, lo cual importa para el monitoreo y las políticas de seguridad.
Las preguntas del examen usan palabras clave claras. 'Bare metal', 'instalado directamente sobre el hardware' o 'centro de datos' apuntan al tipo 1. 'Se ejecuta sobre un sistema operativo existente' o 'software de laboratorio de escritorio' apunta al tipo 2. 'Comparte el kernel del host', 'ligero', 'arranca en segundos' o 'empaqueta la aplicación y sus dependencias' apunta a contenedores. 'Cada instancia tiene su propio sistema operativo' apunta a VM. 'Switch por software dentro del host' es un vSwitch, y 'el uplink del host transporta varias VLAN' significa una troncal 802.1Q.
Términos clave
- Hipervisor tipo 1 (type 1 hypervisor)
- Un hipervisor bare-metal instalado directamente sobre el hardware del servidor, como ESXi, Hyper-V o KVM.
- Hipervisor tipo 2 (type 2 hypervisor)
- Un hipervisor alojado que se ejecuta como aplicación en un sistema operativo de escritorio, como VirtualBox o VMware Workstation.
- Máquina virtual (VM)
- Una computadora definida por software, con su propio sistema operativo invitado y kernel, que se ejecuta sobre un hipervisor.
- Contenedor (container)
- Un paquete de aplicación aislado que comparte el kernel del sistema operativo del host en lugar de ejecutar su propio sistema operativo.
- Switch virtual (vSwitch)
- Software dentro de un hipervisor que conmuta el tráfico entre las NIC virtuales de las VM y las NIC físicas del host.
- Sistema operativo invitado (guest OS)
- El sistema operativo instalado dentro de una máquina virtual.
- Orquestación (orchestration)
- La programación, el escalado y la conexión en red automatizados de muchos contenedores a través de varios hosts, como hace Kubernetes.
El equipo de servidores de un hospital consolida sus servidores de archivos, impresión y directorio en un par de hosts con hipervisor tipo 1. El equipo de redes configura cada puerto de switch que da a un host como troncal 802.1Q que transporta las VLAN de servidores, administración y respaldo. Antes de aplicar parches a una VM, el equipo de servidores toma un snapshot, y durante el mantenimiento del hardware migra las VM en ejecución al otro host para que los usuarios no noten nada.
Comprueba lo que sabes
¿Qué tipo de hipervisor esperarías en un servidor de producción de un centro de datos y por qué?
Tipo 1 (bare-metal), porque se ejecuta directamente sobre el hardware con menos sobrecarga y menos capas que puedan fallar que un hipervisor alojado tipo 2.
¿Cuál es la diferencia arquitectónica clave entre una VM y un contenedor?
Una VM incluye su propio sistema operativo invitado completo y su kernel; un contenedor comparte el kernel del sistema operativo del host y empaqueta solo la aplicación y sus dependencias.
¿Por qué un puerto de switch conectado a un host de virtualización suele configurarse como troncal?
Porque las VM de ese host pertenecen a distintas VLAN, así que el uplink del vSwitch debe transportar tráfico etiquetado de varias VLAN.
Dos VM de la misma VLAN en el mismo host intercambian tráfico. ¿Ese tráfico cruza el switch físico?
Normalmente no; el vSwitch del hipervisor lo reenvía internamente, así que nunca aparece en la red física.