La virtualización en el tiempo de hoy juega un papel fundamental. Desde el uso de escritorio a nivel de consumidor hasta los servicios en la nube a nivel empresarial, existe una variedad de aplicaciones.
Esta guía lo ayudará a comenzar con la virtualización de manera integral. Esto le brindará suficientes conocimientos fundamentales como estudiante, ingeniero o incluso como CTO para comprender los diferentes tipos de virtualización y cómo se usa en la industria actual.
Este es un artículo enorme, así que permítanme resumir de lo que voy a hablar en él.
- La primera parte presenta el sistema operativo host, las máquinas virtuales (VM) y los hipervisores
- La segunda parte describe los componentes esenciales de la virtualización:CPU, RAM, red y almacenamiento
- La tercera parte arroja luz sobre los beneficios de la virtualización
¡Comencemos!
Máquinas virtuales, hosts e hipervisores
Para comprender mejor las máquinas virtuales, los hosts y los hipervisores, es esencial que comience con los fundamentos del hardware.
Primero, necesita una máquina/servidor físico que incluya los siguientes componentes que componen todo el sistema:
- Unidad de fuente de alimentación (PSU)
- Placa base
- Unidad central de procesamiento (CPU)
- Memoria de acceso aleatorio (RAM)
- Tarjeta de interfaz de red (NIC)
- Almacenamiento:unidad de disco duro (HDD) o unidad de estado sólido (SSD)
Todos estos componentes se ensamblan juntos y se sincronizan como una sola unidad informática que se convierte en su propia computadora personal (PC) o servidor. ¡Espera, un servidor personal suena interesante!
¿Qué es un Sistema Operativo (SO)?
Un sistema operativo es un software de sistema que actúa como una interfaz entre el usuario y la computadora para ejecutar una variedad de aplicaciones, con o sin una interfaz gráfica de usuario. Una de estas aplicaciones pueden ser programas de virtualización dedicados como VirtualBox, por ejemplo.
¿Qué es un Hipervisor?
Un hipervisor es un software de sistema que actúa como intermediario entre el hardware de la computadora y las máquinas virtuales. Es responsable de asignar y aprovechar de manera efectiva los recursos de hardware para que los usen las respectivas máquinas virtuales, que funcionan individualmente en un host físico. Por este motivo, los hipervisores también se denominan administradores de máquinas virtuales.
Este software del sistema actúa como una interfaz entre el usuario y la computadora con el único propósito de virtualización, con o sin una interfaz gráfica de usuario. Un ejemplo de uno de estos hipervisores es VMware FXI.
Un hipervisor consta de tres módulos principales:
Despachador — Constituye el punto de entrada del monitor y redirige las instrucciones emitidas por la instancia de la máquina virtual a los módulos asignadores o intérpretes que se describen a continuación.
Asignador — Cada vez que una máquina virtual intenta ejecutar una instrucción que resulta en el cambio de los recursos de la máquina asociada, el asignador es invocado por el despachador, que luego asigna los recursos del sistema que se proporcionarán a la máquina virtual.
Intérprete — Consiste en rutinas de interpretación que se ejecutan cada vez que una máquina virtual ejecuta una instrucción privilegiada. Esto también lo invoca el despachador.
Debe instalar un sistema operativo o un hipervisor que actúe como una interfaz para que interactúe con una computadora/servidor host físico.
Supongamos que es Ubuntu Server donde puede alojar o ejecutar varias aplicaciones. Estas aplicaciones en el servidor se ejecutan dentro del sistema operativo.
Al utilizar el hardware, Ubuntu puede controlarlos y la cantidad de recursos a los que tienen acceso.
Por tanto, un sistema operativo o hipervisor se convierte en un intermediario entre las aplicaciones y el propio hardware.
¿Qué es una máquina virtual (VM)?
Una máquina virtual es un software que emula todas las funcionalidades de un servidor físico y se ejecuta sobre un sistema operativo host o un hipervisor.
Por lo tanto, no ejecutará aplicaciones en el sistema físico directamente. Se ejecutarán en máquinas virtuales, cada una con sus propios sistemas operativos independientes. De esta manera, las máquinas virtuales pueden ejecutar diferentes sistemas operativos individualmente dentro del mismo sistema físico.
Todas estas máquinas virtuales pueden compartir un conjunto común de hardware físico e incluso interactuar entre sí a través de una red virtual, tal como lo hacen las computadoras físicas.
Puede tener un montón de máquinas virtuales, cada una con su propio sistema operativo independiente, compartiendo y utilizando los mismos componentes físicos que se mencionaron anteriormente.
Un hipervisor o un software de virtualización que se ejecuta en un sistema operativo es en realidad lo que controla los recursos físicos.
Un hipervisor tiene acceso directo al hardware físico y controla a qué recursos tienen acceso las máquinas virtuales.
Eso incluye:
- Cuánta memoria (RAM) se asigna
- Cuánto acceso a la CPU física obtienen
- Cómo acceden a su red
- ¿Cómo acceden a su almacenamiento?
A medida que se crean más máquinas virtuales en un software de virtualización de sistema operativo (vamos a reducirlo a OSVS) o Hipervisor, también comparten exactamente el mismo conjunto de recursos físicos.
Por lo tanto, OSVS o Hipervisor controla:
- Cómo se comparten los recursos con las máquinas virtuales individuales
- Cómo se presentan los recursos a las máquinas virtuales individuales
Tipos de Hipervisores
Ahora echemos un vistazo a los tipos de hipervisores y cómo se diferencian entre sí.
Hipervisor tipo 1
Un hipervisor que puede instalarse de forma nativa y ejecutarse directamente en un host físico se denomina hipervisor Tipo 1.
Puntos clave
- Un hipervisor de tipo 1 se puede instalar directamente en un sistema completo o en un host físico.
- No requiere que un sistema operativo (SO) esté instalado o disponible primero, para implementarse en un servidor.
- Acceso directo a CPU, memoria, red, almacenamiento físico.
- La utilización del hardware es más eficiente y ofrece el mejor rendimiento.
- Mejor seguridad debido a la ausencia de cualquier capa adicional para el acceso al hardware.
- Cada hipervisor tipo 1 siempre requiere una máquina física dedicada.
- Puede costar más y ser más adecuado para soluciones de nivel empresarial.
- VMware ESXi, Citrix Hypervisor y Microsoft Hyper-V son algunos ejemplos de hipervisores de tipo 1.
Hipervisor tipo 2
Un hipervisor que no se puede instalar de forma nativa y requiere un sistema operativo para ejecutarse en un host físico se denomina hipervisor de tipo 2.
Puntos clave
- Un hipervisor de tipo 2 no se puede instalar directamente en un sistema completo o en un host físico.
- Requiere que un sistema operativo esté instalado o disponible primero, para implementarse.
- Acceso indirecto a CPU, memoria, red, almacenamiento físico.
- Debido a una capa adicional (SO) para acceder a los recursos, la utilización del hardware puede ser menos eficiente y retrasar el rendimiento.
- Posibles riesgos de seguridad debido a la disponibilidad del sistema operativo host.
- Cada hipervisor tipo 2 no requiere una máquina física dedicada. Puede haber muchos en un solo host.
- Puede costar menos y es más adecuado para soluciones de pequeñas empresas.
- VMware Workstation Player, VMware Workstation Pro y VirtualBox son algunos ejemplos de hipervisores de tipo 2.
Archivos de máquina virtual y estado en vivo
Comprendamos ahora los archivos que componen nuestras máquinas virtuales y cómo aprovechan el almacenamiento compartido.
Una máquina virtual aprovecha la memoria, la CPU, la red y el hardware de almacenamiento de nuestro host físico. ¿Cómo se está haciendo?
A través del hipervisor.
Cuando una máquina virtual se está ejecutando, tiene cierta información en la memoria. Esta información es parte del estado activo de la VM.
Entonces, la VM está realmente operativa en el host. Cada vez que reproduce un video o abre un navegador web en la VM, esas operaciones de tiempo de ejecución se producen en la memoria de la VM. Pero en realidad todos estos ocurren en el host físico. Este es el estado en vivo de cualquier máquina virtual.
El estado activo de la máquina virtual procesa todas las ejecuciones en tiempo de ejecución en la CPU, por lo que sucede en el host.
Cuando abre un navegador para cargar un sitio web, el ancho de banda de la red se atraviesa a través de la NIC, que también forma parte del host físico. Todo es parte del estado activo de una VM que utiliza adaptadores de almacenamiento para enviar tráfico de datos hacia un dispositivo de almacenamiento. Eso nuevamente, sucede en vivo en tiempo real en el host.
Una máquina virtual no tiene discos duros físicos. Si está ejecutando Linux en una máquina virtual, necesita la capacidad de leer y escribir datos hacia y desde una unidad física.
Esto significa que es necesario acceder a un disco físico. La máquina virtual está leyendo hacia y desde y se está ejecutando en una unidad asignada virtualmente. Pero las operaciones en realidad se están redirigiendo hacia un dispositivo de almacenamiento físico en alguna parte. Podría ser a través de una red de canal de fibra, una red ethernet o el propio disco local, justo dentro del hipervisor o del software de virtualización del sistema operativo.
Las máquinas virtuales tienen que utilizar un conjunto de archivos para la gestión de la virtualización. Uno de estos archivos representa una unidad asignada virtualmente o un disco virtual. Una máquina virtual necesita leer o escribir en el disco virtual a través de estos archivos. El tráfico de datos fluirá a través de un adaptador de almacenamiento para que eso suceda.
Por razones obvias, podría haber muchos de estos archivos correspondientes a otras máquinas virtuales que se almacenan en la misma ubicación física en el disco duro.
Hablemos ahora de cómo las máquinas virtuales se apagan y reinician.
Para poder hacer eso, la VM necesita información de configuración que se compone principalmente del estado en vivo:
- ¿Cuánta memoria se supone que debe tener la máquina virtual?
- ¿Cuánta CPU se supone que necesita?
- ¿Cuál es el tamaño del disco asignado?
- ¿Cómo accedería la VM a la red?
Una vez más, toda esta información se almacena en un archivo.
Permítanme enumerar todos los tipos de información que almacenan los archivos de la máquina virtual para garantizar su funcionalidad completa:
- Almacenamiento estático o dinámico
- Información de configuración
- Información del BIOS
- Instantáneas tomadas
Entonces, una máquina virtual almacena dos tipos de estados:
Estado en vivo
El estado en vivo es lo que sucede en tiempo real que, como acabo de comentar, podría ser:
- Cuánta memoria actual se está usando
- Cuánta CPU se está usando
- Qué aplicaciones actuales se están utilizando
- Cómo se usa o se atraviesa el ancho de banda de la red
Si el host físico o la máquina virtual que contiene fallan, toda la información en tiempo real anterior se perderá. Es similar a desconectar una computadora.
Estado persistente
El estado persistente son los archivos de esa máquina virtual, que se guardan permanentemente. Eso es posible gracias a:
- Archivos de almacenamiento
- Archivos de configuración
- Archivos de instantáneas
Los archivos relacionados con el estado persistente componen la VM.
Al igual que los humanos no podemos sobrevivir sin una nutrición adecuada, las máquinas virtuales también necesitan tener una asignación adecuada de recursos de manera constante. La falta de estos recursos significa que las máquinas virtuales no funcionarán al máximo.
Los cuatro elementos esenciales sin los cuales las máquinas virtuales no pueden lograr su mejor rendimiento son:
- CPU
- RAM
- Red
- Almacenamiento
Virtualización de CPU
¿Cómo obtiene acceso una máquina virtual a los recursos de la CPU del host físico?
El host físico tiene una CPU física. Digamos, por ejemplo, que tenemos una CPU con 4 núcleos físicos. Ahora, si desea asignar 2 de estos núcleos físicos, cuando comience a crear sus máquinas virtuales, asignará 2 CPU virtuales. Eso significa que la máquina virtual tendría acceso a 2 núcleos de procesadores físicos desde la CPU principal al crear una VM con 2 CPU virtuales.
Pero esta asignación no significa que otras máquinas virtuales no puedan aprovechar esos núcleos, lo que significa que puedo asignar los 4 núcleos a otra máquina virtual. De manera concluyente, estos recursos pueden ser compartidos por todas las máquinas virtuales en el hipervisor o el software de virtualización del sistema operativo.
Según el tipo de carga de trabajo, debe asignar los núcleos de la CPU en función de la necesidad de las máquinas virtuales. Si una VM está bien con una utilización de CPU del 25 %, podría estar asignando los recursos restantes a otras VM, por supuesto.
Por lo tanto, siempre debe esforzarse por ajustar el tamaño de sus máquinas virtuales en función de los requisitos de la aplicación, especialmente cuando se trata de recursos de CPU.
Virtualización de memoria
Ahora comprendamos cómo las máquinas virtuales pueden utilizar los recursos de memoria del hipervisor.
La cantidad de memoria que puede asignar a una máquina virtual se basa una vez más en la memoria física (RAM) que tiene en su servidor físico.
Por ejemplo, si su servidor tiene 8 GB de RAM, puede asignar 4 GB y ejecutar un escritorio Ubuntu completo en su máquina virtual. El escritorio de Ubuntu "piensa" que tiene 4 GB de memoria física. Pero lo que realmente sucede es que esta memoria asignada se mapea a partir de los 8 GB reales de memoria física.
Cuando asigna 4 GB a la máquina virtual, no puede usar más memoria que la cantidad asignada.
Al igual que las CPU, una vez más, no significa que estos 4 GB estén dedicados a la máquina virtual en todo momento. Si las aplicaciones que se ejecutan en esta máquina virtual no necesitan actualmente tanta memoria, otra máquina virtual puede utilizar el mismo recurso, cuando sea necesario.
Cuando una aplicación se ejecuta en una VM, el sistema operativo (en la VM) asigna la memoria en función de su propia tabla de memoria, y cuando se cierra en una VM, el sistema operativo marca esas páginas de memoria como libres. Pero dado que nunca es "consciente" de la presencia de un hipervisor o software de virtualización, nunca informará al servidor físico sobre esta desasignación.
Por lo tanto, es trabajo del hipervisor o del software de virtualización seguir buscando dentro del sistema operativo de la VM para monitorear estas asignaciones y asignar partes de memoria no utilizadas a otras VM de vez en cuando.
A diferencia de este aspecto compartido de la asignación de memoria entre máquinas virtuales, también puede aplicar la reserva de memoria para máquinas virtuales específicas para usar una parte específica de la memoria física. Esto significa que otras máquinas virtuales no pueden usar la memoria reservada incluso si la máquina virtual con memoria reservada no la está utilizando. En la práctica general, es mejor evitar este procedimiento, ya que compartir la memoria garantiza la utilización eficaz de los recursos al final del día.
Puede relacionar esto con servidores compartidos y dedicados que se proporcionan a través de Linode. Es más económico compartir servidores en la práctica y producción diarias de los administradores de sistemas.
Virtualización de red
Una VM de Ubuntu se ejecuta en un host en un hipervisor o en un software de virtualización. Esta máquina virtual tiene lo que llamamos una NIC virtual V-NIC. Eso se expande a la tarjeta de interfaz de red virtual.
El sistema operativo (Ubuntu) no sabe que se está ejecutando dentro de una máquina virtual. Por lo tanto, espera ver todo el mismo tipo de hardware que vería si estuviera ejecutándose en un servidor físico.
Cuando se trata de virtualización de red, debe proporcionar su máquina virtual, una tarjeta de interfaz de red virtual.
De hecho, Ubuntu va a implementar sus controladores para una tarjeta de interfaz de red. Como sistema operativo invitado, no tendrá idea de que en realidad no es una NIC física.
Es una NIC virtual que es un hardware falso presentado a nuestra máquina virtual como si fuera real. Entonces, si tiene un servidor físico con una NIC física, conectaría su cable de ethernet desde el puerto de ethernet hacia un conmutador físico.
Si tiene una máquina virtual con una NIC virtual, la conectará a un puerto en un conmutador virtual, como lo haría con una máquina física.
Por lo tanto, dentro de nuestro hipervisor o software de virtualización, vamos a tener algo llamado interruptor virtual. Puede conectar varias máquinas virtuales a este conmutador virtual y pueden comunicarse entre sí.
Siempre que los coloque en la misma VLAN (red de área local virtual), podrán comunicarse a través del conmutador virtual tal como lo harían a través de cualquier otro tipo de conmutador físico.
Entonces, si tiene una sola VM conectada a un conmutador virtual, puede conectar una segunda VM. Esto permite enviar tráfico de una máquina virtual a otra directamente dentro de ese conmutador virtual. Este tráfico nunca tiene que abandonar el host siempre que esas máquinas virtuales estén en la misma VLAN. Siempre que esas máquinas virtuales estén en la misma VLAN, pueden comunicarse y el tráfico nunca tiene que atravesar la red física.
Pero, aquí hay un punto importante. Parte del tráfico de la red tendría que atravesar la red física, por lo que el conmutador virtual necesitará un enlace ascendente.
Al igual que un conmutador físico tiene enlaces ascendentes a un conmutador físico de nivel superior o un enrutador físico, nuestro conmutador virtual también requiere enlaces ascendentes. Estos enlaces ascendentes son los adaptadores físicos reales en el host. Estos adaptadores físicos se denominan P-NIC, NIC físicos o NIC de VM.
Una tarjeta de interfaz de red física o NIC siempre está integrada en nuestras placas base modernas en nuestros servidores:
Pero si lo desea, también puede optar por una NIC dedicada, conectada a la placa base para redes adicionales:
Cuando crea un hipervisor en un host, ese host tiene una o más tarjetas de interfaz de red, como lo haría cualquier otro servidor.
Esas tarjetas de interfaz de red física en un host, se conectan a un conmutador físico y ese conmutador físico tendrá conexiones a los enrutadores. Esta es la forma en que envía tráfico a Internet.
A través de este mecanismo, también puede conectarse a otros servidores físicos que se encuentran dentro del mismo centro de datos.
Por lo tanto, las máquinas virtuales pueden comunicarse con todos esos componentes con o dentro del mismo servidor físico.
Si el tráfico necesita salir del host para comunicarse fuera del host para llegar a un enrutador y llegar a otra VLAN u otra red, ese tráfico fluirá fuera de la VM.
A través del conmutador virtual, uno de los enlaces ascendentes de los conmutadores virtuales hacia la red física.
Cuando ese tráfico llegue al conmutador físico, realizará una búsqueda en la tabla MAC (un registro de direcciones físicas únicas).
Proporcionará el puerto apropiado hacia el destino apropiado donde debe ir ese paquete. Podría dirigirse a Internet o a un host físico en su propia red local.
Pero este mecanismo garantiza la capacidad de todas sus máquinas virtuales para comunicarse con todos los dispositivos en mi red física. Esto es lo que hace un conmutador virtual.
La idea fundamental aquí es engañar al sistema operativo invitado en la máquina virtual para que "piense" que tiene una tarjeta de interfaz de red física. Por lo tanto, proporciona los mismos controladores a Ubuntu y pensará que tiene un dispositivo de hardware real.
Cuando se envían los paquetes de datos, el hipervisor realmente recupera el tráfico, que lo dirige hacia el conmutador virtual adecuado según las instrucciones.
Virtualización del almacenamiento
Ahora que ha aprendido cómo las máquinas virtuales aprovechan las CPU, la memoria y la red, procedamos con el recurso final:el almacenamiento.
Permítanme reiterar nuevamente que el sistema operativo invitado no tiene idea de que se está ejecutando dentro de una máquina virtual. Una VM no tiene hardware físico dedicado y eso incluye un disco de almacenamiento. La máquina virtual no tiene un disco físico dedicado a ella.
Con las redes, teníamos una NIC virtual.
Con la virtualización del almacenamiento, vamos a tener un controlador SCSI virtual, si pensamos en la forma en que funciona un servidor físico con discos duros internos. Cuando un sistema operativo necesita escribir algún tipo de datos en el disco, el sistema operativo genera un comando SCSI.
Si necesita leer datos del disco, genera un comando SCSI y envía ese comando al controlador SCSI, que interactúa con los discos físicos. Esa es la forma en que Ubuntu funciona con el almacenamiento, no sabe que se está ejecutando dentro de una máquina virtual aquí.
Por lo tanto, también debemos mantener esa ilusión para el sistema operativo invitado para los mecanismos de almacenamiento.
Por lo tanto, proporciona a Linux (que se ejecuta en la VM) un controlador SCSI virtual. Emulará como si estuviera ejecutando discos físicos reales.
Por lo tanto, cuando Ubuntu necesite ejecutar algún tipo de comando de almacenamiento, pensará que tengo un controlador SCSI real.
Cuando se envía un comando de almacenamiento al controlador SCSI, lo que realmente sucede es que el controlador SCSI virtual (un dispositivo virtual) los redirige al hipervisor. La máquina virtual envía esos comandos de almacenamiento a través de su controlador SCSI virtual y llegan al hipervisor.
El hipervisor determina qué sucede con esos comandos de almacenamiento desde aquí. Si la máquina virtual tiene su propio VMDK o archivo de disco virtual en un disco local, simplemente enviará esos comandos de almacenamiento a ese archivo en su disco duro local.
Aparte de esta funcionalidad más básica, también podría ser
- una matriz de almacenamiento de canal de fibra
- una matriz de almacenamiento iSCSI basada en Ethernet
- un canal de fibra a través de Ethernet
Pero todos funcionan de manera similar.
Lo que diferiría es en realidad la red.
Si el hipervisor envía ese comando de almacenamiento a un canal de fibra, ese comando de almacenamiento atravesará esa red de canal de fibra hasta que finalmente llegue al disco virtual.
Independientemente del hipervisor, su máquina virtual tendrá un disco virtual.
Así es como los comandos SCSI pasan de su máquina virtual a su disco virtual, independientemente de dónde se encuentre ese disco virtual.
Cuando una máquina virtual basada en Ubuntu genera un comando SCSI, lo envía al controlador SCSI virtual.
El hipervisor determina la ubicación adecuada para ese disco virtual y lo envía al adaptador de almacenamiento, y el comando de almacenamiento llega al almacén de datos.
Estos cambios transversales de datos en realidad se escriben en el archivo que contiene el disco virtual de la máquina virtual. Podría ser .VMX, .VMDK o cualquier otro tipo de archivo virtual.
Espero que ya haya entendido los conceptos básicos de la virtualización de redes y almacenamiento. Permítanme resaltar los beneficios de eficiencia y movilidad de la virtualización y también cómo puede convertir hosts físicos en máquinas virtuales.
Beneficios de la virtualización
Hasta ahora hemos hablado de cómo funciona básicamente la virtualización a través de los distintos modos de gestión de recursos. Hablemos ahora de los muchos beneficios clave.
Consolidación
Primero, hablemos de la eficiencia.
Si compara su infraestructura virtual con un gimnasio, y algunos de ustedes pueden haber experimentado esto antes.
Si vas al gimnasio alrededor del 1 de enero, el gimnasio comienza a estar muy ocupado.
Durante la parte normal del año, un gimnasio con alrededor de 20 cintas de correr y 50 máquinas de ejercicios sería suficiente.
Pero si eres propietario de un gimnasio, sabes que en enero habrá entre dos y tres veces más personas y sería más productivo triplicar el tamaño de tu entorno.
Cuando todas esas personas se dan cuenta de que, sí, tal vez no les gusta tanto hacer ejercicio, dejan de ir al gimnasio.
De ahora en adelante, puede reducir el tamaño del gimnasio según sus necesidades.
Ahora bien, esto también sería genial si pudiera hacer lo mismo con el hardware de su centro de datos virtual.
Cuando tratas con la virtualización, te lleva a la idea de la computación en la nube, donde hay un proveedor o proveedor de servicios como Linode, por ejemplo. Con él, puede poner en marcha un montón de máquinas virtuales temporales en el hardware de otra persona y acomodar esa época ocupada del año para sus clientes.
Pero realmente no se puede llegar a la computación en la nube sin virtualizar primero. Este es el primer paso en ese camino hacia donde podemos llegar a lo que llamamos un estado de elasticidad, donde su infraestructura puede crecer o reducirse rápidamente.
La virtualización es un componente básico hacia ese tipo de flexibilidad. Nos brinda la capacidad de consolidar cargas de trabajo.
A continuación, vemos un centro de datos de servidores físicos.
Como práctica recomendada, cada uno de estos servidores no debería ejecutar un solo sistema operativo.
¡Piense en cuántas cargas de trabajo más podría realizar si ejecutara de 20 a 30 instancias de Linux en cada uno de estos servidores en lugar de solo una por servidor!
Ese es el mayor beneficio de la virtualización. Ese es el beneficio que inicialmente impulsó esta innovación a la virtualización:la consolidación.
Eficiencia
En el siguiente diagrama, tiene tres servidores diferentes con diferentes roles que están disponibles como sistemas físicos individuales en nuestro entorno:
Tiene un servidor de impresión que utiliza el 20 por ciento de todos los recursos y lo mismo ocurre con el servidor web y de base de datos.
Estos son servidores físicos que realmente no están usando todos sus recursos. Si lo piensa, pagó por todo ese hardware, y si solo usa el 20 por ciento, está desperdiciando el 80 por ciento.
Al dejar los recursos en un host físico que solo puede ejecutar un sistema operativo, ahora tiene dos opciones para solucionar este problema:
Puede comenzar a instalar otras aplicaciones en nuestro servidor y hacer que varias aplicaciones se ejecuten en el mismo servidor. Pero si necesita reiniciar el servidor de impresión, le preocupará qué más se está ejecutando en ese servidor de impresión.
¿Qué más puede afectar al realizar el mantenimiento de mi servidor de impresión? Habrá demasiados escenarios y casos de uso de aplicaciones interdependientes en el mismo hardware, y eso reducirá enormemente la eficiencia.
Por lo tanto, la mayoría de las veces, terminamos con un desperdicio de recursos. En su lugar, puede deshacerse de esos servidores físicos y consolidar esas cargas de trabajo en un hipervisor:
A través de esta consolidación, ahora puede ejecutar múltiples instancias de sistema operativo en ese hipervisor. Ahora puede maximizar, cambiar el tamaño y alcanzar un punto ideal que podría ser del 60 o 70 por ciento de utilización de recursos de manera fácil y eficiente.
Así que ahora está utilizando de manera eficiente los recursos que ha comprado, pero no los está sobrecargando.
Ese es nuestro objetivo final con la virtualización:maximizar la inversión en hardware que se fabrica sin desperdiciar capital adicional en recursos que nunca se utilizarán.
Movilidad
Otro gran beneficio de la virtualización es la movilidad.
Si puede recordar cómo funciona la virtualización de red y almacenamiento, piense en un escenario aquí en el que tenga una matriz de almacenamiento de canal de fibra. Consideremos también que acaba de invertir en una nueva matriz de almacenamiento iSCSI.
Ahora supongamos que tiene su matriz de almacenamiento Fibre Channel y desea reubicar esta máquina virtual y todos sus archivos en su nuevo dispositivo de almacenamiento iSCSI, que se encuentra en una red diferente.
Digamos que está en la red Ethernet. Ahora puede reubicarse fácilmente con su hipervisor o software de virtualización. A medida que los comandos SCSI salen de su máquina virtual, el hipervisor los recibe. Cuando use otro adaptador de almacenamiento y reubique estos archivos VMS en la otra matriz de almacenamiento, el hipervisor se dará cuenta de que ha realizado ese cambio.
Simplemente redirigiría esos comandos de almacenamiento a la nueva ubicación y el punto positivo es que incluso puede hacer esto sin ningún tiempo de inactividad en su máquina virtual.
Veamos otro escenario.
Digamos que tiene varios hosts y ahora elige tomar una máquina virtual Linux y reubicar el estado activo de la máquina virtual en otro host. Eso también funcionará, siempre que el otro host tenga la capacidad de conectarse al almacenamiento compartido. Su VM aún podrá acceder a su disco virtual y a todos los demás archivos críticos de VM que necesita.
Así es como el almacenamiento, la virtualización y el almacenamiento compartido ayudan a lograr la movilidad. Puede tomar máquinas virtuales, moverlas a diferentes hosts, mover sus archivos de un sistema de almacenamiento a otro sin tiempo de inactividad.
Todo se debe al hipervisor en el medio que se interpone entre la máquina virtual y el hardware.
Esto es lo que popularmente se conoce como desacoplamiento. Significa que la máquina virtual no tiene una relación directa con ningún hardware. Puede moverlo de un servidor físico a otro. También puede moverlo de un sistema de almacenamiento a otro. No existe una relación fija entre la máquina virtual y el hardware específico. Están desacoplados en el verdadero sentido del término.
Por lo tanto, como puede ver, la movilidad es un beneficio importante de la virtualización.
Otra forma de verlo:
Digamos que tiene varios hosts y muchas máquinas virtuales ejecutándose en todos estos hosts y la carga de trabajo no está tan equilibrada como se desea.
Si en el host uno tiene tres máquinas virtuales ejecutándose, es posible que desee migrar algunos de esos VMS al host dos para igualar la carga de trabajo en esos dos hosts.
Desea asegurarse de que la utilización de recursos de nuestros hosts se utilice de manera bastante uniforme en todo momento.
Si el host uno tiene muy poca memoria, puede mover algunas máquinas virtuales a otro host e, idealmente, querrá hacerlo sin tiempo de inactividad.
Puede realizar una migración en vivo y tomar una máquina virtual en ejecución y moverla de un servidor físico a otro sin tiempo de inactividad. Esa es una razón importante por la que quizás desee migrar máquinas virtuales.
Otro motivo es también cuando se necesita realizar algún tipo de actividad de mantenimiento. Digamos que puede instalar algo de memoria física y agregar otro host o cualquier otra forma de mantenimiento físico.
Esto significa que tendrá tiempo de inactividad en un host. To prevent that, you can migrate all of the VMs to another host, perform maintenance, install memory or whatever you want to, say installing patches or carrying out a necessary reboot. You can migrate all VMs off of that host, do whatever you need to and then bring them back once the host is back up. All this can happen without any disruption for users.
How this is done:
Let's take a look at an example, migration, Say here we have a virtual machine running on host one you want to patch up. You also need to reboot this host.
So you have to initiate a migration of this VM from host one to host two.
But there are some prerequisites:
- Shared storage
- Virtual disk files
- Configuration files
- Virtual NICs
- Snapshots
This is a VM that has network access and that virtual neck is connected to a virtual switch and it's available on a VLAN.
The virtual switch is connected to a physical switch and the virtual machine is addressed accordingly.
This VM exists on some VLAN that's got a port group on the virtual switch. If you move this VM down to another host and the virtual switch there does not have a matching configuration, that network would become unavailable.
You don't want that.
So you must ensure you have a compatible network on both of these hosts.
Simply said, you don't want the migrated VM to see anything different when it moves the host two and you want the compatable processors you want as they were on host one.
If they're Intel on host one, you want them to be compatible with AMD on host two.
You want these two hosts to be as much identical as you can possibly make them.
When it comes to the network and storage configuration, they obviously need to match up.
Finally, you need a way to perform the transfer from host one to host two. So you're going to have a special network that takes all of the contents of memory, takes what's currently happening on the current VM and creates a copy of it on the other host.
Once you've covered my prerequisites, the rest of it is pretty straightforward.
You write a copy of the VM that is going to be created on a destination host in this case.
Based on VMware terminology, you're going to use something called a VM kernel port to create a network, and that network is going to be used to create a copy of the current VM on the destination host.
When that copy is complete, you will capture everything that's changed in that VM during that copy process. You call this a memory bitmap.
All of the contents of this memory bitmap are transferred over to the new copy of the VM and that becomes your live running virtual machine.
The downtime is so negligible, that it's not even perceptible to the users of your applications. This is called live migration of a virtual machine, while it's running and moved from one host to another.
This facilitates amazing flexibility, because you can move VMs wherever you need to.
Another notable advantage is automated load balancing.
You can group together hosts in what's called a cluster. Once you group those together, what you would now want is to allow your virtual machines to efficiently make use of the resources of the cluster as a whole.
You'll want to consider all of these hosts are interchangeable. It doesn't matter which host your VMs run on. If VMs need to move around to equalize workload, you can definitely make that to happen automatically.
That's the purpose of automatic load bouncing in VMware terminology.
This is also called distributed resource scheduler, in order to allow virtual machines to automatically be live migrated from host to host for the purposes of load balancing across themselves.
Converting physical servers to VMs
In this section, you'll learn about some concepts required to convert a physical machine to a virtual machine.
There are different software options out there to accomplish that.
Let's say you have a physical server with Ubuntu installed on it. It has all kinds of physical hardware like CPUs, RAM and network adapters and storage disks.
Our Ubuntu operating system has drivers for devices such as network adapters. It knows what kind of CPUs are being used:be it AMD or Intel CPUs. It has got a SCSI controller to connect to physical disks and the operating system is also aware of the actual physical hardware.
When we take this physical server and use one of our software tools to convert it to a virtual machine, the first step that happens is that virtual machine is created as virtual replica of the physical machine.
You're going to have a virtual machine present your hypervisor with the appropriate CPU, memory, network and storage specifications. It might not exactly match up with what we had in the physical server.
When you create a virtual machine, your goal should always be to rightsize that virtual machine. It's never to just take what the physical server had and duplicate it. The goal is always to right size it to give the virtual machine the correct resources that it needs to do its job (efficiently run applications) and nothing extra.
You'd want your resource consumption to be about 60, 70 percent utilization for CPU and the same for memory. You don't want them unutilized at 10 percent with four CPUs. That's not efficient.
You're also going to need a physical NIC, for the virtual machine and this is going to be a hardware change for the guest operating system.
So what would be most ideal to have is a network interface card that was specifically designed to run on a virtual machine, a good example of this is the VMware VMAX.
The beautiful thing about this, is that now the virtual machine has no relationship with actual physical hardware, so we get mobility by breaking out of specific hardware dependency everytime.
Other benefit that is often overlooked is the fact that as you virtualize, all of your OS instances(Linux/Mac/Windows) are going to have a similar set of virtual hardware. It allows you to standardize your operating system configuration.
You replace our physical hardware with virtual hardware and your physical hard disk with a virtual disk.
This is a file that could be on a local storage of the host, it could be on:
- a fibre channel
- a SCSI storage array
- an NFS server
What's most important is that you create this virtual disk and migrate all of the data from the source virtual machine to the virtual disk. When the power's on, it's got its new hardware with its new disk. From this point on, it should just work.
That's how you convert a physical server to a virtual machine.
Depending on which hypervisor you're using:
- VMware has vCenter converter
- Microsoft has VM converter
- Veeam has disk to VHD
You can start using these solutions on your existing physical servers, convert them to virtual machines and run them on your hypervisor. Helder has shared some tips on building homelab which is a good way to experiment.
Hope you found this detailed introduction to virtualization helpful. Please leave any feedback if you have in the comment section below. Thank you.