Teoría general y arqueología de virtualización x86

Introduccion

Equipo de autores

Publicado por Anton Zhbankov ( AntonVirtual , cloudarchitect.cc )
Coautores: Grigory Pryalukhin , Evgeny Parfenov

Conceptos generales de virtualización

Tuve que ver muchas interpretaciones de lo que es la virtualización y escuchar mucha controversia, no un poco más cerca de discutir el resultado práctico. Y como saben, el argumento de dos personas inteligentes se reduce a un debate sobre las definiciones. Definamos qué es la virtualización y qué proviene de ella.

Probablemente la definición más cercana de virtualización será "abstraer" de la programación orientada a objetos. O, si se traduce al ruso normal, esto oculta la implementación detrás de una interfaz abstracta. Lo cual, por supuesto, explicaba todo a la vez. Intentemos nuevamente, pero para aquellos que no han estudiado programación.

Virtualización: esconde una implementación específica detrás de un método estandarizado universal de acceso a recursos / datos.

Si intenta poner en práctica esta definición, resulta que funciona en temas completamente inesperados. Digamos el reloj. Entonces, se inventó un reloj de sol hace varios miles de años, y en la Edad Media se inventó uno mecánico. ¿Qué hay en común? El sol y algunos engranajes? Algún tipo de tontería. Y luego osciladores de cuarzo y todo lo demás.
La conclusión es que tenemos una interfaz estándar: un puntero o puntero digital, que en una forma estándar universal indica la hora actual. ¿Pero nos importa cuán específicamente se implemente este mecanismo dentro de la caja, si el tiempo se indica con suficiente precisión para nosotros?
“Permítanme”, pueden decir, “¡pero pensé que la virtualización se trataba de máquinas, procesadores, etc.!
Sí, se trata de automóviles y procesadores, pero este es solo un caso especial. Miremos más ampliamente, ya que el artículo afirma audazmente una teoría general.

POZOR!

Uwaga! Achtung! Pozor!

Este artículo tiene un objetivo educativo general para vincular un conjunto completo de tecnologías y palabras de miedo junto con la historia en una determinada estructura, y debido a esta circunstancia contiene una cantidad significativa de simplificaciones intencionales . Por supuesto, también contiene una gran cantidad de omisiones molestas e incluso errores cursis con errores tipográficos. La crítica constructiva es bienvenida, especialmente en la forma de "Déjame traerte esta parte a la mente".

Tipos de virtualización

Regresemos de conceptos completamente abstractos a los más familiares para nuestras queridas computadoras.

Virtualización de almacenamiento

El primero, probablemente, es el tipo de virtualización que encuentra un geek novato: la virtualización de un sistema de almacenamiento de datos. En este caso, el sistema de almacenamiento no se utiliza en el sentido de una gran matriz con discos conectados a través de un canal de fibra, sino como un subsistema lógico responsable del almacenamiento de datos a largo plazo.

FS -> LBA -> CHS

Tomemos el caso más simple de un sistema de almacenamiento en un solo disco magnético duro. El formato habitual para trabajar con datos son los archivos que están en la unidad lógica. El archivo se puede abrir, leer, cerrar. Pero un objeto como un archivo simplemente no existe físicamente: solo hay una manera de acceder a ciertos bloques de datos utilizando el método de direccionamiento del formulario "unidad: \ carpeta1 \ carpeta2 \ archivo". Es decir Nos encontramos con la primera capa de virtualización: desde lo mnemotécnico y comprensible hasta los humanos, traducimos todo en direcciones entendibles por el sistema. En las tablas de metadatos, el controlador del sistema de archivos busca qué tipo de bloques de datos hay y obtenemos la dirección en el sistema de direccionamiento de bloques lógicos (LBA). En el sistema LBA, los bloques tienen un tamaño fijo y se siguen linealmente, es decir, de alguna manera puede tener que ver con el almacenamiento de datos en cinta magnética, ¡pero el disco duro es de alguna manera completamente diferente! Y aquí vamos a la segunda capa de virtualización: la traducción del direccionamiento LBA a CHS (cilindro / cabezal / sector).



CHS, a su vez, ya en el controlador del disco duro comienza a traducirse en parámetros físicos para la lectura, pero esta es una historia completamente diferente.
Incluso en un simple acceso al archivo para, por ejemplo, ver una vidosik con memasics, nos encontramos con tres capas de virtualización de inmediato.
Todo sería demasiado simple si las capas no comenzaran a superponerse en orden aleatorio y en una variedad de formas.

RAID

La siguiente capa de virtualización, que muchas personas erróneamente no consideran virtualización, es RAID (matriz redundante de discos económicos / independientes).

La característica clave de RAID en el contexto de los conceptos discutidos no es su capacidad para proteger los datos de la falla de un disco físico en particular. RAID proporciona un segundo nivel de direccionamiento LBA además de varias (a veces muchísimas) direcciones LBA independientes. Como podemos acceder al RAID, independientemente del nivel de RAID, exactamente de la misma manera que un solo disco sin RAID, podemos decir con confianza:

RAID es virtualización de disco.

Además, el controlador RAID no solo crea un gran disco virtual a partir de varios discos físicos, sino que puede crear un número arbitrario de ellos al agregar otra capa de virtualización.

Ver virtualización

El siguiente tipo de virtualización, que muchos de nosotros usamos casi todos los días, pero no lo consideramos virtualización, es una conexión remota al escritorio.

Los servidores de terminal, VDI e incluso solo RDP a través de VPN para el servidor son todos virtualización de sesión. Usando una interfaz estándar (monitor, teclado, mouse) trabajamos con una máquina real o con un diseño incomprensible desde un escritorio virtual en un clon vinculado con una aplicación en contenedor, desde la cual transferimos datos a través de un búfer a una aplicación con entrega de transmisión. O no, ¿quién lo resolverá, además del que lo diseñó?

Introducción a la virtualización x86

Historia y resumen de procesadores

Ejecución del programa

En la primera lección de un curso especial de programación, Vladimir Denisovich Lelyukh (descanse en paz para él) les dijo a los estudiantes: la computadora, a pesar de su nombre, no puede contar, puede pretender que puede contar. Pero si algo parece un pato, camina como un pato y grazna como un pato, desde un punto de vista práctico, es un pato.

Intentemos recordar esto para un uso práctico adicional.

La computadora, y específicamente el procesador, en realidad no hace nada: solo espera algunos parámetros de entrada en ciertos lugares, y luego, a través de la terrible magia negra, da algunos resultados en ciertos lugares.

Un programa en este caso es un cierto flujo de comandos ejecutados estrictamente secuencialmente, como resultado de lo cual esperamos ver un cierto resultado.
Pero si el programa se está ejecutando, ¿cómo se pueden ingresar los datos? ¿Y en general, de alguna manera interactuar en una computadora?

Para esto, se inventaron las interrupciones de hardware. El usuario presiona una tecla: el controlador del teclado lo señala y hay una interrupción en la ejecución del hilo de código actual. Las direcciones de los manejadores de interrupciones se registran en un área de memoria específica, y después de guardar el estado actual, el control se transfiere al manejador de interrupciones. A su vez, el controlador debe, en teoría, procesar rápidamente todo, luego él y el controlador, escribir la tecla presionada en el búfer deseado y devolver el control. Por lo tanto, la aplicación parece estar ejecutándose y podemos interactuar con el sistema.

Los controladores de interrupciones (y el tipo principal de controladores son controladores de dispositivos) tienen la oportunidad de ingresar a un modo de procesador especial, cuando no se pueden implementar otras interrupciones antes de salir de este modo. Lo que al final a menudo condujo a un problema de bloqueo: un error en el controlador no permitió salir de la interrupción.

Multitarea

¿Qué hacer en una situación si es necesario ejecutar varios programas (secuencias de código con sus estructuras de datos y memoria) al mismo tiempo? Obviamente, si hay más flujos de código que dispositivos capaces de ejecutarlos, entonces esto es un problema.

La pseudo-multitarea aparece cuando se ejecuta una tarea al cambiar directamente a ella.

En el futuro, aparece una cooperativa (multitarea no preventiva): la tarea ejecutable en sí misma comprende que ya no necesita recursos del procesador y le da el control a otra persona. Pero todo esto no es suficiente.

Y aquí nuevamente, las interrupciones + la capacidad de fingir nos rescatan. Realmente no le importa al usuario que se ejecuten estrictamente simultáneamente, es suficiente para verse así.
Por lo tanto, simplemente se cuelga un controlador para interrumpir el temporizador, que comienza a controlar qué secuencia de código se debe ejecutar a continuación. Si el temporizador se activa con bastante frecuencia (digamos 15 ms), para el usuario todo parece una operación paralela. Y entonces hay una multitarea moderna desplazada.

Modo real

El modo de procesador real en este artículo se puede describir de manera bastante simple: toda la memoria está disponible para todos. Cualquier aplicación, incluido el malware (malware, software malicioso), puede acceder a cualquier lugar, tanto para leer como para escribir.

Este es el modo de operación inicial de la familia de procesadores Intel x86.

Modo protegido

En 1982, apareció una innovación en el procesador Intel 80286 (en adelante, simplemente 286), un modo de operación protegido, que trajo consigo innovaciones en la organización del trabajo con memoria (por ejemplo, asignación de tipos de segmentos de memoria: código, datos, pila). Pero lo más importante que el procesador 286 trajo al mundo x86 es el concepto de anillos de protección, que todavía utilizamos.

El concepto de anillos de protección apareció originalmente en el sistema operativo Multics para el mainframe GE645 (1967) con una implementación parcial de software y hardware completo ya en 1970 en el sistema Honeywell 6180.



La idea básica de los anillos de defensa se asemeja a las fortalezas medievales de varios niveles; las más valiosas se encuentran en el centro detrás de las múltiples paredes. En este caso, lo más valioso es el acceso directo ilimitado a cualquier área de RAM y el control sobre todos los procesos. Están poseídos por procesos que operan en el anillo cero de protección. Detrás de la pared, en el primer anillo, funcionan procesos menos importantes, como controladores de dispositivos y, en el último, aplicaciones de usuario. El principio es simple: desde adentro puedes salir, pero desde afuera está prohibido. Es decir ningún proceso de usuario puede acceder a la memoria del núcleo del sistema operativo, como era posible en modo real anteriormente.

En la primera implementación completa del Honeywell 6180, se implementaron 8 anillos de protección, pero Intel decidió simplificar el circuito a 4, de los cuales en la práctica los fabricantes de sistemas operativos comenzaron a usar solo dos: cero y tercero.

32bit

En 1985, se lanzó otro procesador extremadamente arquitectónicamente importante en la línea x86: 80386 (en adelante 386), que implementó el direccionamiento de memoria de 32 bits y utilizó instrucciones de 32 bits. Y, por supuesto, la virtualización de la memoria. Como ya se mencionó, la virtualización es la ocultación de la implementación real a través de la provisión de recursos artificiales "virtuales". En este caso, estamos hablando de direccionamiento de memoria. El segmento de memoria tiene su propio direccionamiento, que no tiene nada que ver con la ubicación real de las celdas de memoria.
El procesador resultó tener tanta demanda que se produjo antes de 2007.
La arquitectura en términos de Intel se llama IA32.

64bit

Por supuesto, incluso sin virtualización a mediados de la década de 2000, la industria ya estaba llegando a los límites de 32 bits. Hubo soluciones parciales en forma de PAE (Extensión de dirección física), pero complicaron y ralentizaron el código. La transición a 64 bits fue una conclusión inevitable.

AMD presentó su versión de la arquitectura, que se llama AMD64. En Intel, esperaban la plataforma IA64 (Intel Architecture 64), que también conocemos con el nombre de Itanium. Sin embargo, el mercado conoció esta arquitectura sin mucho entusiasmo, y como resultado, Intel se vio obligado a implementar su propio soporte para las instrucciones AMD64, que primero se llamaba EM64T, y luego solo Intel 64.

En definitiva, todos conocemos esta arquitectura como AMD64, x86-64, x86_64 o, a veces, x64.

Dado que se suponía que el uso principal de los servidores en ese momento era físico, sin virtualización, sucedió algo técnico divertido con los primeros procesadores de 64 bits en virtualización. Los hipervisores anidados a menudo se usaban como servidores de laboratorio; no todos podían permitirse varios grupos de servidores físicos. Y al final resultó que la VM de carga en el hipervisor incorporado solo podía funcionar en modo de 32 bits.

En los primeros procesadores x86-64, los desarrolladores, manteniendo una compatibilidad total con el modo operativo de 32 bits, descartaron una parte importante de la funcionalidad en el modo de 64 bits. En este caso, el problema era simplificar enormemente la segmentación de la memoria. Se eliminó la capacidad de garantizar la inviolabilidad de un pequeño trozo de memoria en la VM donde funcionaba el controlador de excepciones del hipervisor. En consecuencia, el sistema operativo invitado pudo modificarlo.
Posteriormente, AMD devolvió la posibilidad de limitar segmentos, e Intel simplemente esperó la introducción de la virtualización de hardware.

UMA

Los sistemas multiprocesador X86 comenzaron a funcionar con el modo UMA (Acceso uniforme a la memoria), en el que la distancia desde cualquier procesador (retraso en el acceso a una celda de memoria) a cualquier barra de memoria es la misma. En los procesadores Intel, este esquema de trabajo se conservó incluso después de la aparición de procesadores multinúcleo hasta la generación 54xx (Harpertown). Comenzando con la generación 55xx (Nehalem), los procesadores han cambiado a la arquitectura NUMA.

Desde el punto de vista de la lógica de ejecución, esta es la aparición de subprocesos de hardware adicionales, a los que puede asignar secuencias de código para su ejecución en paralelo.

NUMA

NUMA (acceso no uniforme a la memoria): arquitectura con acceso desigual a la memoria. Dentro de esta arquitectura, cada procesador tiene su propia memoria local, a la que se accede directamente con baja latencia. Se accede indirectamente a la memoria de otros procesadores con mayores retrasos, lo que conduce a un rendimiento reducido.

Para los procesadores Intel Xeon escalables v2 para 2019, la arquitectura interna sigue siendo UMA dentro del zócalo, convirtiéndose en NUMA para otros zócalos (aunque no realmente, y solo pretende serlo). Los procesadores Opteron de AMD tenían arquitectura NUMA incluso durante la época del UMA Xeon más antiguo, y luego NUMA se convirtió incluso dentro del zócalo hasta la última generación de Roma, en la que volvieron a NUMA = zócalo.

Máquina virtual

Máquina virtual (VM, de la máquina virtual en inglés): un sistema de software y / o hardware que emula el hardware de alguna plataforma (el objetivo es la plataforma objetivo o invitada) y ejecuta programas para la plataforma objetivo en la plataforma host (el host es la plataforma host , la plataforma host), o virtualizando alguna plataforma y creando entornos en ella que aíslen programas e incluso sistemas operativos entre sí. Wikipedia
En este artículo diremos "máquina virtual", que significa "máquinas virtuales de sistema", lo que permite simular completamente todos los recursos y hardware en forma de construcciones de software.
Hay dos tipos principales de software para crear máquinas virtuales: con full y resp. virtualización incompleta

La virtualización completa es un enfoque en el que se emula todo el hardware, incluido el procesador. Le permite crear entornos independientes del hardware y ejecutar, por ejemplo, el sistema operativo y el software de aplicación para la plataforma x86 en sistemas SPARC, o los conocidos emuladores Spectrum con el procesador Z80 en el conocido x86. La otra cara de la independencia total es la alta sobrecarga para virtualizar el procesador y el bajo rendimiento general.

La virtualización incompleta es un enfoque en el que no se virtualiza el 100% del hardware. Dado que la virtualización incompleta es la más común en la industria, hablaremos de ello. Acerca de las plataformas y tecnologías de máquinas virtuales de sistema con virtualización incompleta para la arquitectura x86. En este caso, virtualización incompleta del procesador, es decir con la excepción de la sustitución parcial u ocultación de ciertas llamadas al sistema, el procesador ejecuta el código binario de la máquina virtual directamente.

Virtualización de software

La consecuencia obvia de la arquitectura del procesador y los hábitos de los sistemas operativos para trabajar en el anillo cero fue el problema: el núcleo del sistema operativo invitado no puede funcionar en el lugar habitual. El anillo cero está ocupado por el hipervisor, y solo tiene que dejar que el sistema operativo invitado llegue allí también; por un lado, volvimos al modo real con todas las consecuencias, y por otro lado, el sistema operativo invitado no espera a nadie allí, y destruirá instantáneamente todas las estructuras de datos y dejará caer el automóvil.

Pero todo se decidió simplemente: dado que para el hipervisor el sistema operativo invitado es solo un conjunto de páginas de memoria con acceso directo completo, y el procesador virtual es solo una cola de comandos, ¿por qué no reescribirlos? Sobre la marcha, el hipervisor arroja de la cola de instrucciones para la ejecución en el procesador virtual todas las instrucciones que requieren privilegios de anillo cero, reemplazándolos por otros menos privilegiados. Pero el resultado de estas instrucciones se presenta exactamente de la misma manera que si el SO huésped estuviera en el anillo cero. Por lo tanto, puede virtualizar cualquier cosa, hasta la ausencia total de un sistema operativo invitado.
Este enfoque fue implementado por el equipo de desarrollo en 1999 en el producto VMware Workstation, y luego en 2001 en los hipervisores del servidor GSX (el segundo tipo, como Workstation) y ESX (el primer tipo).

Paravirtualización

La paravirtualización es un concepto muy simple, que supone que el SO huésped sabe que está en una máquina virtual y sabe cómo acceder al SO host para ciertas funciones del sistema. — , .
x86 2003 Linux Xen.

, . , VMware ESXi SCSI PVSCSI, , . ( VMware Tools), Linux (open-vm-tools).

, .

— Intel VT-x AMD-V , , . .

2 (hosted)

Los hipervisores del segundo tipo son aplicaciones que se ejecutan sobre el sistema operativo host. Todas las llamadas de máquina virtual son manejadas por el sistema operativo host ascendente. Los hipervisores del segundo tipo tienen un rendimiento muy limitado, ya que la aplicación del hipervisor, al no tener derecho a la asignación exclusiva de recursos informáticos, se ve obligada a competir por ellos con otras aplicaciones de usuario. En términos de seguridad, los hipervisores tipo 2 dependen directamente de las políticas de seguridad del sistema operativo del usuario y su vulnerabilidad a los ataques. Hoy en día, existe una opinión unánime en la industria de que tales plataformas de virtualización para el nivel empresarial no son adecuadas. Sin embargo, son muy adecuados para el desarrollo multiplataforma y la implementación de stands directamente en las máquinas de los desarrolladores de software, ya que son fáciles de administrar e implementar.

Ejemplos del segundo tipo de hipervisor: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

Tipo 1 (metal desnudo)

Los hipervisores del primer tipo no requieren un sistema operativo de propósito general, a diferencia de los anteriores. El hipervisor en sí es un monolito que controla tanto la asignación de recursos informáticos como la E / S. En el anillo de seguridad cero, hay un micro-núcleo, sobre el cual funcionan todas las estructuras de control. En esta arquitectura, el hipervisor controla la distribución de los recursos informáticos y controla todas las llamadas de las máquinas virtuales a los dispositivos. VMware ESX fue considerado el primer hipervisor del primer tipo para x86 durante mucho tiempo, aunque ahora lo atribuiríamos a 1+. El único representante "honesto" de este tipo hoy en día es VMware ESXi, el sucesor de ESX, después de que fuera un poco fuera de la sección principal con RHEL.

ESXi. API , VMkernel. , , . , .



: “” , HCL (hardware compatibility list).

1+ ( )

Los hipervisores de tipo híbrido (también son tipos 1+, 1a, 1.5) se caracterizan por el aislamiento del sistema operativo base en una entidad especial llamada partición primaria (partición primaria en terminología Microsoft Hyper-V) o un dominio primario (dominio dom0 en terminología Xen). Entonces, después de instalar la función del hipervisor, el núcleo ingresa al modo de soporte de virtualización y el hipervisor es responsable de asignar recursos en el host. Pero la sección principal se encarga de la función de procesamiento de llamadas a los controladores de dispositivos y operaciones de E / S.

, . : , ESXi, , HCL. , .

1+ :



: VMware ESX, Microsoft Hyper-V, Xen-based (Citrix XenServer Xen Linux). , Citrix XenServer – RHEL-based OS, Red-Hat Enterprise Linux. Xen : Linux Xen dom0. , Xen-based 1 .

Se tomará la base de la terminología de VMware, como la plataforma de virtualización más avanzada tecnológicamente. En este artículo, nos restringimos a las tecnologías de los propios hipervisores y al sistema de control básico. Toda la funcionalidad avanzada implementada por productos adicionales por dinero adicional se quedará detrás de escena. Las tecnologías se agrupan en grupos condicionales para el propósito principal, como le pareció al autor, con quien tiene derecho a estar en desacuerdo.

SLA

Esta es una colección de tecnologías que afectan principalmente el rendimiento de los SLA para la accesibilidad (RPO / RTO).

HA

Alta disponibilidad: una tecnología para garantizar la alta disponibilidad de máquinas virtuales en un clúster mediante un hipervisor. En el caso de una muerte del host, la VM se reinicia automáticamente en los hosts supervivientes. Efecto: minimizar RTO antes del tiempo de espera de HA + reiniciar OS / servicios.

FT

Tolerancia a fallos: tecnología para garantizar el funcionamiento continuo de las máquinas virtuales, incluso en caso de muerte del huésped. Se crea una VM virtual en el segundo host, que es completamente idéntica a la principal y repite las instrucciones detrás de ella. Por lo tanto, la diferencia en los estados de VM se mide en decenas o cientos de milisegundos, lo cual es bastante aceptable para muchos servicios. Cuando el host muere, la ejecución cambia automáticamente a Shadow VM. Efecto: minimizar RTO a cero.

Tco

Esta es una colección de tecnologías que influyen principalmente en el TCO.

vMotion

vMotion es una tecnología para la migración en vivo de un punto de ejecución de VM de un host totalmente funcional a otro. Al mismo tiempo, el punto de conmutación del punto de ejecución es menor que los tiempos de espera de conexión de red, lo que nos permite considerar la migración como en vivo, es decir. sin interrupción en el trabajo de servicios productivos. Efecto: reducir el RTO a cero para interrupciones planificadas para el mantenimiento del servidor y, como resultado, la eliminación parcial de las interrupciones en sí mismas.

VMotion de almacenamiento

Storage vMotion es una tecnología para la migración en vivo de un punto de almacenamiento de VM de un almacenamiento totalmente funcional a otro. Al mismo tiempo, el trabajo con el sistema de discos no se detiene, lo que permite que la migración se considere en vivo. Efecto: reducir el RTO a cero para las interrupciones planificadas para el mantenimiento del almacenamiento y, como resultado, la eliminación parcial de las interrupciones en sí mismas.

DPM

Administración de energía distribuida: tecnología para controlar el nivel de carga del host y el encendido / apagado de los hosts a medida que cambia la carga en el clúster. Requiere DRS para su funcionamiento. Efecto: reducción general del consumo de energía.

VSwitch distribuido

VSwitch distribuido es una tecnología para la administración centralizada de la configuración de red de conmutadores de host virtual. Efecto: reduciendo el volumen y la complejidad del trabajo en la reconfiguración del subsistema de red, reduciendo los riesgos de errores.

EVC

La compatibilidad mejorada de vMotion es una tecnología que permite enmascarar las instrucciones de procesador disponibles para máquinas virtuales en modo automático. Se utiliza para alinear el trabajo de las máquinas virtuales en un clúster desigual con la familia de procesadores más antigua, proporcionando la capacidad de migrar máquinas virtuales a cualquier host. Efecto: ahorro en la complejidad de la infraestructura al tiempo que aumenta gradualmente la capacidad / actualización parcial de los clústeres.

QoS

Esta es una colección de tecnologías que influyen principalmente en el rendimiento de SLA en términos de calidad de servicio.

vNUMA

vNUMA es una tecnología que permite que el SO huésped se comunique con la topología virtual NUMA de VM para máquinas anchas (vCPU o vRAM> nodo NUMA). Efecto: la falta de una penalización en el rendimiento del software de aplicación que admite NUMA.

Grupo de recursos

Grupos de recursos: la tecnología de combinar varias máquinas virtuales en un solo grupo de recursos para controlar el consumo o garantizar la asignación de recursos. Efecto: simplificar la administración, proporcionar un nivel de servicio.

Límite / reserva

La memoria / procesador limitante y redundante le permite limitar la asignación de recursos, o viceversa, para garantizar su asignación en una situación de escasez y competencia para garantizar el mantenimiento de máquinas virtuales / grupos de alta prioridad.

DRS

Programador dinámico de recursos: equilibrio automático de máquinas virtuales por parte de hosts según la carga para reducir la fragmentación de recursos en el clúster y proporcionar un nivel de servicio para máquinas virtuales. Requiere soporte de vMotion.

Control de IO de almacenamiento

Storage IO control — , “ ”, , . — / .

Network IO Control

Network IO Control — , “ ”, .

Storage Integration (VAAI etc)

:

• / , .
• Integración de nivel de protocolo - VAAI, ODX. Estas tecnologías le permiten descargar el subsistema de disco, transfiriendo parte de la carga estándar a la disposición de almacenamiento inteligente. Por ejemplo, esta categoría incluye operaciones tales como bloques de puesta a cero, clonación de máquinas virtuales, etc. Debido a esto, el canal hacia el sistema de almacenamiento está significativamente descargado, y el sistema de almacenamiento realiza las operaciones de disco de una manera más óptima.

Seguridad

Microsegmentación

La microsegmentación de una red virtual en uso práctico es la capacidad de construir un firewall distribuido virtual que controla las redes virtuales dentro del host. Mejora extremadamente la seguridad de la red virtual.

AV sin agente

Soporte de tecnología antivirus sin agentes. En lugar de ser verificado por agentes en el SO huésped, el tráfico de las operaciones de disco de la VM es dirigido por el hipervisor a la VM del servicio seleccionado. Reduce significativamente la carga en los procesadores y el sistema de disco, matando efectivamente las "tormentas antivirus".

Sistemas hiperconvergentes

Los sistemas convergentes, como su nombre indica, son sistemas con una combinación de funciones. Y en este caso, nos referimos a la combinación del almacenamiento y la ejecución de la VM. Parece simple, pero el marketing de repente interrumpe.

Por primera vez con el término sistemas convergentes, los especialistas en marketing entran al mercado. Los sistemas convergentes vendían servidores clásicos ordinarios + almacenamiento + conmutadores. Justo debajo de un número de socio. O ni siquiera estaban vendiendo, pero se produjo un artículo llamado "arquitectura de referencia". Condenamos sinceramente este enfoque y pasamos a la consideración arquitectónica.

Arquitectura

Manteniendo la convergencia como un principio arquitectónico, obtenemos una combinación del punto de almacenamiento y el punto de ejecución de la VM en un solo sistema.

La arquitectura convergente, en otras palabras, implica el uso de los mismos servicios de hardware tanto para ejecutar máquinas virtuales como para almacenarlos en discos locales. Bueno, dado que debería haber tolerancia a fallas, en una arquitectura convergente hay una capa de SDS distribuido.

Obtenemos:

• El sistema clásico: software, almacenamiento, conmutación y servidores provienen de diferentes lugares, combinados por las manos del cliente / integrador. Contratos de soporte separados.
• Sistema convergente: todo de una fuente, un soporte, un número de socio. No debe confundirse con el autoensamblaje de un proveedor.

Y resulta que el término para nuestra arquitectura convergente ya está tomado. Exactamente la misma situación que con el supervisor.

Sistema hiperconvergente : un sistema convergente con arquitectura convergente.
Por supuesto, no fue sin la segunda venida de los vendedores. Aparecieron sistemas convergentes en los que no había combinación de almacenamiento, pero hay nodos de almacenamiento dedicados bajo el control de SDS distribuido. Dentro del marco de las guerras de marketing, incluso apareció el término especial HCI desagregado (infraestructura hipervergénica desagregada). En particular, por ejemplo, NetApp con un sistema similar al principio luchó intensamente por el derecho a llamar a su sistema hiperconvergente, pero finalmente se rindió. NetApp HCI hoy (finales de 2019): infraestructura de nube híbrida.

Opciones de implementación

Debido al hecho de que los sistemas hiperconvergentes funcionan con virtualización, en realidad hay dos opciones y media para la implementación.

• 1. El módulo del núcleo. SDS funciona como un monolito en el núcleo del hipervisor, por ejemplo vSAN + ESXi
• 1.5 Módulo de la sección principal. SDS funciona como un servicio como parte de la sección principal del hipervisor, por ejemplo S2D + Hyper-V
• 2. La máquina virtual. SDS se implementa como una máquina virtual dedicada en cada host. Nutanix, Cisco Hyperflex, HPE Simplivity.

Obviamente, además de los problemas discutidos con el efecto de incrustar en el rendimiento, existe un problema muy importante de aislamiento y soporte de hipervisores de terceros. En el caso 1, es obvio que este puede ser solo un sistema del proveedor del hipervisor, mientras que 2 puede funcionar en cualquier hipervisor.

Contenedores

La virtualización en contenedores, aunque técnicamente es muy diferente de la virtualización completa, parece bastante simple en estructura. Al igual que con el modelo de red OSI, la pregunta es el nivel. La virtualización de contenedores es un nivel superior, a nivel del entorno de la aplicación, y no a la física.

La tarea principal de la virtualización de contenedores es dividir el sistema operativo en partes independientes, desde las cuales las aplicaciones aisladas no podrían interferir entre sí. La virtualización completa no es compartida por el sistema operativo, sino por un servidor físico.

VM vs Contenedor

Los pros y los contras de ambos enfoques son bastante simples y directamente opuestos.

La virtualización completa (VM) brinda total independencia al nivel de hierro, incluido el sistema operativo totalmente independiente, el disco y las pilas de red. Por otro lado, cada aplicación, debido a que nos adherimos al esquema 1 aplicación = 1 servidor, requiere su propio sistema operativo, su propio disco y pila de red. es decir Hay un gasto múltiple de recursos.

Los contenedores tienen discos comunes y pilas de red con el sistema operativo host, y todos juntos usan el mismo núcleo en todo el servidor físico (bueno o virtual, como en los últimos tiempos), lo que en su conjunto le permite ahorrar bastante recursos en paisajes homogéneos.

Históricamente, x86 inicialmente tenía contenedores para todo, junto con servidores físicos. Después del advenimiento de la virtualización completa, la importancia de los contenedores disminuyó drásticamente en casi 15 años, y las máquinas virtuales gruesas reinó en el mundo corporativo. En ese momento, los contenedores se encontraban en servidores que proporcionaban cientos de servidores web del mismo tipo, donde su ligereza era muy solicitada. Pero en los últimos años, desde aproximadamente 2015, los contenedores han vuelto a la realidad corporativa en forma de aplicaciones nativas de la nube.

Contenedores 0.1

chroot

El prototipo de contenedores en 1979 fue chroot.

“Chroot es la operación de cambiar el directorio raíz en sistemas operativos tipo Unix. Un programa lanzado con un directorio raíz modificado solo tendrá acceso a los archivos contenidos en este directorio ".

Es decir de hecho, el aislamiento es solo a nivel del sistema de archivos, de lo contrario, es solo un proceso normal en el sistema operativo.

Cárcel de Freebsd

Significativamente más avanzada fue la prisión de BSD libre, que apareció en 1999. Jail le permitió crear instancias de SO virtuales completas con sus propios conjuntos de aplicaciones y archivos de configuración basados ​​en la base FreeBSD. Seguramente hay quienes dicen, ¡y qué hace la cárcel en contenedores, porque esto es paravirtualización! Y estarán parcialmente en lo cierto.

Sin embargo, antes de la virtualización completa (y su variante en forma de paravirtualización) la cárcel carece de la capacidad de ejecutar el núcleo de una versión diferente en la VM invitada y de agruparse con la migración de la VM a otro sistema host.

Zonas de Solaris

Solaris Zones es una tecnología de virtualización del sistema operativo (virtualización de contenedores), introducida en 2004 en Sun Solaris. El principio básico es una baja sobrecarga de virtualización.

Sin ganar mucha popularidad, migró a OpenSolaris y las distribuciones basadas en él, disponibles en 2019.

Contenedores 1.0

En la era de los contenedores 1.0, han aparecido dos direcciones principales de contenedorización: estos son productos comerciales para proveedores de alojamiento y la contenedorización de aplicaciones.

Virtuozzo / OpenVZ

SWsoft ruso presentó en 2001 su primera versión de virtualización de contenedores Virtuozzo, dirigida al mercado de proveedores de hosting. Debido a la determinación y al público objetivo comercial específico, el producto resultó ser bastante exitoso y ganó popularidad. Tecnológicamente, en 2002, se demostró la operación simultánea de 2500 contenedores en un servidor de 8 procesadores.

En 2005, apareció una versión abierta de contenedores Virtuozzo para Linux llamada OpenVZ. Y casi se convirtió en el estándar de oro para alojar VPS.

Lxc

LinuX Containers (LXC) es otra virtualización de contenedores bien conocida basada en espacios de nombres y grupos c, que apareció en 2008. Es la base de los dockers actualmente populares, etc.

Contenedores 1.1 (virtualización de aplicaciones)

Si los contenedores restantes están diseñados para dividir el sistema operativo base en segmentos, entonces, ¿por qué no cortar esta capa del sistema y empaquetarla en una sola caja con la aplicación y todo su entorno? Y luego este paquete listo para usar se puede iniciar como una aplicación normal a nivel de usuario.

App-v

Microsoft Application Virtualization (App-V), anteriormente Softricity SoftGrid: tecnología para contener aplicaciones específicas (el contenedor es al revés) en un entorno aislado, luego Microsoft. En 2006, Microsoft adquirió el inicio de Softricity, que en realidad cambió el contenedor.

Thinapp

VMware ThinApp (anteriormente Thinstall) es un producto de contenedorización de aplicaciones de Jilt adquirido por VMware en 2008. VMware estima que el 90-95% de todas las aplicaciones empaquetadas en el mundo usan esta tecnología.

Contenedores 2.0

La historia de la aparición de contenedores 2.0 está muy asociada con un cambio en el proceso de desarrollo de software. El deseo de la empresa de reducir un parámetro tan importante como el tiempo de comercialización obligó a los desarrolladores a reconsiderar los enfoques para crear productos de software. La metodología de desarrollo de Waterfall (ciclos de lanzamiento largos, toda la aplicación se actualiza) se reemplaza por Agile (ciclos de lanzamiento cortos y fijos, los componentes de la aplicación se actualizan independientemente) y obliga a los desarrolladores a separar las aplicaciones monolíticas en componentes. Si bien los componentes de las aplicaciones monolíticas aún son bastante grandes y no hay muchos de ellos que se puedan colocar en máquinas virtuales, pero cuando una aplicación consta de decenas o cientos de componentes, las máquinas virtuales ya no son muy adecuadas. Además, también surge el problema de las versiones de software auxiliar, bibliotecas y dependencias, a menudo hay una situación en la que diferentes componentes requieren diferentes versiones o variables de entorno configuradas de manera diferente. Dichos componentes deben distribuirse a diferentes máquinas virtuales, porque Es casi imposible ejecutar simultáneamente varias versiones de software dentro del mismo sistema operativo. El número de VM comienza a crecer como una avalancha. Aquí, los contenedores aparecen en el escenario, lo que permite en el marco de un sistema operativo invitado crear varios entornos aislados para iniciar componentes de aplicaciones. La contenerización de aplicaciones le permite continuar la segmentación de una aplicación monolítica en componentes aún más pequeños y pasar al paradigma de una tarea = un componente: un contenedor, esto se denomina enfoque de microservicio, y cada uno de esos componentes es un microservicio.

Contenedor debajo del capó

Si observa el contenedor con una mirada del administrador del sistema, estos son solo procesos de Linux que tienen sus propios pids, etc. ¿Qué hace posible aislar procesos que se ejecutan en contenedores entre sí y consumir los recursos del SO huésped juntos? Dos mecanismos estándar presentes en el núcleo de cualquier distribución moderna de Linux. El primero, Linux Namespaces, que garantiza que cada proceso vea su propia representación del sistema operativo (sistema de archivos, interfaces de red, nombre de host, etc.) y el segundo, Linux Control Groups (cgroups), que restringe el proceso al consumo de recursos del sistema operativo invitado (CPU, memoria ancho de banda de red, etc.).

Espacios de nombres de Linux

Por defecto, cada sistema Linux contiene un solo espacio de nombres. Todos los recursos del sistema, como sistemas de archivos, identificadores de proceso (ID de proceso), identificadores de usuario (ID de usuario), interfaces de red pertenecen a este espacio de nombres. Pero nadie nos impide crear espacios de nombres adicionales y redistribuir los recursos del sistema entre ellos.

Cuando se inicia un nuevo proceso, se inicia en un espacio de nombres, estándar del sistema o uno de los creados. Y este proceso verá solo aquellos recursos que están disponibles en el espacio de nombres utilizado para ejecutarlo.

Pero no todo es tan simple, cada proceso no pertenece a un solo espacio de nombres, sino a un espacio de nombres en cada una de las categorías:

• Monte (mnt)
• ID de proceso (pid)
• Red (net)
• Comunicación entre procesos (ipc)
• UTS
• ID de usuario (usuario)

Cada tipo de espacio de nombres aísla un grupo de recursos correspondiente. Por ejemplo, el espacio UTS define el nombre de host y el nombre de dominio visibles para los procesos. Por lo tanto, dos procesos dentro del sistema operativo invitado pueden suponer que se ejecutan en servidores diferentes.

El espacio de nombres de red determina la visibilidad de las interfaces de red, el proceso en el interior solo verá las interfaces que pertenecen a este espacio de nombres.

Grupos de control de Linux (cgroups)

Linux Control Groups (cgroups) es el mecanismo del sistema del kernel (Kernel) de los sistemas Linux que limita el consumo de recursos del sistema por parte de los procesos. Cada proceso o grupo de procesos no podrá obtener más recursos (CPU, memoria, ancho de banda de red, etc.) de los que está asignado, y no podrá capturar los "otros" recursos: los recursos de los procesos vecinos.

Docker

Como se indicó anteriormente, Docker no inventó los contenedores como tales. Los contenedores han existido durante muchos años (incluidos los basados ​​en LXC), pero Docker los hizo muy populares al crear el primer sistema que facilitó y facilitó la transferencia de contenedores entre diferentes máquinas. Docker ha creado una herramienta para crear contenedores: empaquetar la aplicación y sus dependencias y ejecutar contenedores en cualquier sistema Linux con Docker instalado.

Una característica importante de Docker es la portabilidad no solo de la aplicación en sí y sus dependencias entre distribuciones de Linux completamente diferentes, sino también la portabilidad del entorno y el sistema de archivos. Por ejemplo, un contenedor creado en CentOS puede ejecutarse en un sistema Ubuntu. En este caso, dentro del contenedor lanzado, el sistema de archivos se heredará de CentOS, y la aplicación considerará que se ejecuta sobre CentOS. Esto es algo similar a una imagen OVF de una máquina virtual, pero el concepto de una imagen Docker usa capas. Esto significa que cuando se actualiza solo una parte de la imagen, no es necesario volver a descargar la imagen completa, es suficiente descargar solo la capa modificada, como si en la imagen OVF fuera posible actualizar el sistema operativo sin actualizar toda la imagen.

Docker ha creado un ecosistema para crear, almacenar, transferir y lanzar contenedores. Hay tres componentes clave para el mundo Docker:

• Imágenes: una imagen, esta es la entidad que contiene su aplicación, el entorno necesario y otros metadatos necesarios para iniciar el contenedor;
• Registros: repositorio, lugar de almacenamiento para imágenes Docker. Hay una variedad de repositorios, que van desde el oficial - hub.docker.com y terminan con los privados implementados en la infraestructura de la compañía;
• Contenedores: un contenedor, contenedor de Linux creado a partir de una imagen de Docker. Como se mencionó anteriormente, este es un proceso de Linux que se ejecuta en un sistema Linux con Docker instalado, aislado de otros procesos y del sistema operativo en sí.

Considere el ciclo de vida del contenedor. Inicialmente, un desarrollador crea una imagen de Docker con su aplicación (el comando de compilación de Docker), completamente desde cero o utilizando imágenes ya creadas como base (recuerde las capas). Además, el desarrollador puede iniciar esta imagen directamente en su propia máquina o puede transferirla a otra máquina: el servidor. Para la portabilidad, a menudo se utilizan repositorios (el comando push docker): cargan la imagen en el repositorio. Después de eso, la imagen se puede descargar a cualquier otra máquina o servidor (docker pull). Finalmente, cree un contenedor de trabajo (Docker Run) a partir de esta imagen.

Kubernetes

Como ya dijimos, el concepto de microservicios significa dividir una aplicación monolítica en muchos servicios pequeños, generalmente realizando una sola función. Bueno, cuando hay docenas de tales servicios, todavía se pueden administrar manualmente a través de, por ejemplo, Docker. Pero, ¿qué hacer cuando hay cientos y miles de tales servicios? Además del entorno industrial, necesita un entorno de prueba y entornos adicionales para diferentes versiones del producto, es decir. multiplique por 2, por 3 o incluso más. Google también enfrentó los mismos problemas, sus ingenieros fueron uno de los primeros en utilizar contenedores a escala industrial. Así nació Kubernetes (K8s), creado bajo el nombre de Borg en los muros del producto de Google, luego dado al público en general y renombrado.

K8s es un sistema que facilita la implementación, administración y monitoreo de aplicaciones en contenedores (microservicios). Como ya sabemos, cualquier máquina Linux es adecuada para lanzar contenedores y los contenedores están aislados unos de otros, respectivamente, y los K8 pueden administrar diferentes servidores con diferentes hardware y bajo el control de diferentes distribuciones de Linux. Todo esto nos ayuda a usar el hardware disponible de manera efectiva. Al igual que la virtualización, K8s nos proporciona un conjunto común de recursos para lanzar, administrar y monitorear nuestros microservicios.

Dado que este artículo está destinado principalmente a ingenieros de virtualización, para una comprensión general de los principios de operación y los componentes principales de K8, le recomendamos que lea el artículo que establece el paralelismo entre K8 y VMware vSphere: https://medium.com/@pryalukhin/kubernetes-introduction-for-vmware- usuarios-232cc2f69c58

Historia de virtualización industrial X86

VMware

VMware apareció en 1998, comenzando con el desarrollo de un segundo tipo de hipervisor, que más tarde se conocería como VMware Workstation.

La compañía ingresó al mercado de servidores en 2001 con dos hipervisores: GSX (Ground Storm X, segundo tipo) y ESX (Elastic Sky X, primer tipo). Con el tiempo, las perspectivas del segundo tipo en aplicaciones de servidor se han vuelto obvias, es decir Ninguno. Y el GSX pagado se convirtió primero en un servidor VMware gratuito, y luego se detuvo y enterró por completo.

En 2003, apareció el sistema de administración central del Centro Virtual, la tecnología vSMP y la migración en vivo de máquinas virtuales.

En 2004, VMware fue adquirido por EMC, un gigante de almacenamiento, pero dejó de funcionar de manera independiente.

En 2008, convirtiéndose en el estándar de facto de la industria, VMware estimuló el rápido crecimiento de las ofertas competitivas: Citrix, Microsoft, etc. Se hace evidente la necesidad de obtener una versión gratuita del hipervisor, lo que era imposible, ya que una sección principal en ESX utilizaba RHEL bastante comercial. El proyecto para reemplazar RHEL con algo más fácil y gratuito se implementó en 2008 con el sistema busybox. El resultado es ESXi, conocido por todos hoy.

Paralelamente, la compañía se está desarrollando a través de proyectos internos y adquisiciones de startups. Hace unos años, una lista de productos de VMware ocupaba un par de páginas A4, así que digamos. VMware para 2019 sigue siendo el estándar de facto en el mercado de virtualización corporativa corporativa local con una cuota de mercado de más del 70% y un líder absoluto en tecnología, y una revisión detallada de la historia merece un artículo muy extenso.

Connectix

Fundada en 1988, Connectix trabajó en una variedad de utilidades del sistema hasta que tomó la virtualización. En 1997, se creó el primer producto VirtualPC para Apple Macintosh, permitiendo que Windows se ejecute en una máquina virtual. La primera versión de VirtualPC para Windows apareció en 2001.

En 2003, Microsoft compró VirtualPC y, de acuerdo con Connectix, los desarrolladores se cambiaron a Microsoft. Después de eso, Connectix cerró.

El formato VHD (disco duro virtual) fue desarrollado por Connectix para VirtualPC, y como recordatorio, los discos virtuales de las máquinas Hyper-V contienen "conectix" en su firma.
La PC virtual, como puede suponer, es un hipervisor de escritorio clásico del segundo tipo.

Microsoft

El viaje de Microsoft hacia la virtualización industrial comenzó con la compra de Connectix y el cambio de marca de Connectix Virtual PC en Microsoft Virtual PC 2004. Virtual PC desarrollado por un tiempo, se incluyó bajo el nombre de Windows Virtual PC en Windows 7. En Windows 8 y posterior, Virtual PC fue reemplazado por versión de escritorio de Hyper-V.

Basado en Virtual PC, se creó el hipervisor del servidor Virtual Server, que existió hasta principios de 2008. Debido a la evidente pérdida tecnológica antes de VMware ESX, se decidió restringir el desarrollo del segundo tipo de hipervisor en favor de su propio primer tipo de hipervisor, que se convirtió en Hyper-V. Existe una opinión no oficial en la industria de que Hyper-V es sorprendentemente similar a Xen en arquitectura. Aproximadamente lo mismo que .Net en Java.

"Por supuesto, podrías pensar que Microsoft robó la idea de Java". Pero esto no es cierto, ¡Microsoft la inspiró! - (de un discurso de un representante de Microsoft en la presentación de Windows 2003 Server)

Desde los momentos curiosos, se puede observar que dentro de Microsoft, el uso de productos de virtualización patentados en los años cero fue, por decirlo suavemente, opcional. Hay capturas de pantalla de Technet de artículos sobre virtualización, donde el logotipo de VMware Tools está claramente presente en la bandeja. Además, Mark Russinovich en la Plataforma 2009 en Moscú realizó una demostración con VMware Workstation.

En un esfuerzo por ingresar a nuevos mercados, Microsoft creó su propia nube pública, Azure, utilizando un Nano Server altamente modificado con Hyper-V, S2D y SDN como plataforma. Vale la pena señalar que inicialmente, Azure en algunos puntos estaba muy por detrás de los sistemas locales. Por ejemplo, el soporte para máquinas virtuales de segunda generación (con soporte para arranque seguro, arranque desde particiones GPT, arranque PXE, etc.) apareció en Azure solo en 2018. Mientras se encuentra en las instalaciones, las máquinas virtuales de segunda generación se conocen desde Windows Server 2012R2. Lo mismo ocurre con las soluciones de portal: hasta 2017, Azure y Windows Azure Pack (solución en la nube Multi-Tenancy con SDN y compatibilidad con VM protegida, que reemplazó a System Center App Controller en 2013) utilizaron el mismo diseño de portal. Después de que Microsoft anunció un curso sobre nubes públicas, Azure dio un paso adelante para desarrollar e implementar varios conocimientos. Alrededor del año 2016, puede observar una imagen completamente lógica: ahora todas las innovaciones en Windows Server provienen de Azure, pero no en la dirección opuesta. El hecho de copiar partes de la documentación de Azure en las instalaciones "tal cual" lo indica (consulte la documentación en Azure SDN y Network Controller), que por un lado sugiere la actitud hacia las soluciones locales y, por el otro, indica la relación de las soluciones en términos de entidades y arquitectura. Quién copió de quién y cómo es realmente: una pregunta discutible.

En marzo de 2018, Satya Nadela (CEO de Microsoft) anunció oficialmente que la nube pública se estaba convirtiendo en la prioridad de la compañía. Lo que, obviamente, simboliza el plegado gradual y el desvanecimiento de la línea del servidor para productos locales (sin embargo, el estancamiento se observó en 2016, pero se confirmó con la primera versión beta de Windows Server y otras líneas de productos locales), con la excepción de Azure Edge, el servidor mínimo requerido Infraestructura en la oficina del cliente para servicios que no se pueden llevar a la nube.

Plancha virtual

Fundada en 2003, Virtual Iron ofreció una versión comercial de Xen y fue una de las primeras en ofrecer al mercado soporte completo de virtualización de hardware.
En 2009, Oracle asumió el control para desarrollar su propia línea de virtualización Oracle VM y expandirla en x86. Antes de esto, Oracle VM solo se ofrecía en la plataforma SPARC.

Innotek

A principios de 2007, Innotek GmbH lanzó el hipervisor de escritorio propietario de segundo tipo, VirtualBox, que es gratuito para uso no comercial. En el mismo año, se lanzó una versión de código abierto.

En 2008, fue adquirida por Sun, que a su vez fue adquirida por Oracle. Oracle ha mantenido el uso gratuito del producto para fines no comerciales.
VirtualBox admite tres formatos de discos virtuales: VDI (nativo), VMDK (VMware), VHD (Microsoft). Como sistema operativo host, se admiten Windows, macOS, Linux, Solaris y OpenSolaris. La bifurcación de VirtualBox para FreeBSD es conocida.

Ibm

El mainframe es la computadora principal del centro de datos con una gran cantidad de memoria interna y externa (para referencia: en los años 60, 1 MB de memoria se consideraba irrealmente grande). En realidad, el mainframe era un centro de cómputo: las primeras computadoras ocupaban salas de máquinas enteras y consistían en enormes bastidores. En estos días se llama centros de datos. Pero en los centros de datos en la misma sala de máquinas puede haber miles de computadoras, y en los albores de la tecnología informática, una computadora ocupaba una sala completa. Cada bastidor vendía un (!) Dispositivo de computadora (bastidores separados con memoria, bastidores separados con dispositivos de almacenamiento y dispositivos periféricos por separado). El núcleo de esta enorme máquina era un bastidor con un procesador, se llamaba main o mainframe.Después de cambiar a los circuitos integrados de transistores, el tamaño de este milagro del pensamiento científico y de ingeniería disminuyó significativamente, y la unidad central de IBM y sus análogos comenzaron a entenderse como la unidad central.

En los años 60 del siglo XX, el alquiler de la potencia informática de todo el mainframe, sin mencionar su compra, costó mucho dinero. Muy pocas empresas e instituciones pueden permitirse ese lujo. El poder de cómputo de arrendamiento era por hora (el prototipo del modelo moderno de pago por uso en nubes públicas, ¿no?). El acceso a los inquilinos para la informática se otorgó de forma secuencial. La solución lógica era paralelizar la carga computacional y aislar los cálculos de los inquilinos entre sí.

Por primera vez, el Centro de Ciencias de Cambridge de IBM propuso la idea de aislar varias instancias de sistemas operativos en un mainframe basado en el mainframe IBM System / 360-67. El desarrollo se llamó CP / CMS y, de hecho, fue el primer hipervisor y proporcionó paravirtualización. CP (Programa de control): el propio hipervisor, que creó varias "máquinas virtuales" (VM) independientes. CMS (originalmente el Cambridge Monitor System, luego renombrado como Conversational Monitor System) era un sistema operativo liviano para un solo usuario. Curiosamente, CMS todavía está vivo y todavía se usa en la última generación de mainframes z / VM. Vale la pena señalar que en ese momento y hasta los años 90, una máquina virtual significaba una separación lógica de discos físicos (se compartían discos o dispositivos de almacenamiento,el hipervisor no proporcionó almacenamiento para sus propias necesidades) con una pieza dedicada de memoria virtual y tiempo de procesador utilizando la tecnología Time-Sharing. Las máquinas virtuales no proporcionaban interacción con la red, porque las máquinas virtuales de esa época se referían a la computación y el almacenamiento de datos, y no a la transferencia de ellos. En este sentido, las máquinas virtuales de esa época eran más como contenedores que máquinas virtuales en el sentido moderno.

CP/CMS VM/370 System/370 2 1972 . – VM, VM IBM. , ( ) – VM/370. : () System/370 VM/370 ( ! – ). .

Los años 80 se pueden llamar con seguridad la "era del mainframe". VM fue un éxito con los desarrolladores de sistemas operativos, se escribieron aplicaciones para ello y se hicieron cálculos. Esta fue la década en que la proporción de bases de datos dominadas por el sistema operativo VM comenzó a prevalecer en los mainframes. Uno de los cambios más importantes fue el recurso de acceso de partición lógica (LPAR), que en realidad proporcionó dos niveles de virtualización. Los clientes ahora pueden usar el mismo conjunto de procesadores, dispositivos de E / S y módems en sistemas VM que se ejecutan en diferentes LPAR y permiten que los recursos se migren de un sistema VM a otro. Esto permitió a las organizaciones de TI ofrecer un rendimiento constante al procesar picos de carga de trabajo. Para racionalizar la creciente base de clientes, VM se dividió en tres productos separados,disponible a finales de los 80:

VM / SP: el sistema operativo de virtualización multipropósito habitual para servidores System z
HPO (Opción de alto rendimiento): VM / SP de alto rendimiento para modelos anteriores de servidor System z
VM / XA (arquitectura extendida): variante VM compatible con la arquitectura S / S extendida 370

A principios de los 90, la simplicidad y la conveniencia de la arquitectura x86 se volvieron más atractivas para los clientes, y los mainframes estaban perdiendo relevancia rápidamente. Los mainframes han sido reemplazados por sistemas de clúster, como el grunge, que reemplazó al glam metal al mismo tiempo. Sin embargo, para una determinada clase de tareas, por ejemplo, al construir un almacén de datos centralizado, los mainframes se justifican tanto en términos de productividad como desde un punto de vista económico. Por lo tanto, algunas empresas aún usan mainframes en sus infraestructuras, y IBM diseña, lanza y da soporte a las nuevas generaciones.

Linux Xen

Xen (pronunciado zen) es un hipervisor desarrollado en el Laboratorio de Computación de la Universidad de Cambridge bajo la dirección de Ian Pratt y distribuido bajo la GPL. La primera versión pública apareció en 2003. Posteriormente, Ian continuó trabajando en el hipervisor en su versión comercial, estableciendo la empresa XenSource.
En 2013, Xen quedó bajo el control de la Fundación Linux.

XenSource

Tras haber existido durante varios años en el mercado con los productos XenServer y XenEnterprise, a finales de 2007 fue adquirida por Citrix.

Citrix XenServer

Habiendo absorbido XenSource por $ 500 millones, Citrix no pudo comercializar el problema. Más precisamente, realmente no intenté hacerlo, sin considerar a XenServer como el producto principal, y confiando en lo barato de las licencias permanentes. Después de ventas francamente infructuosas en medio del exitoso VMware ESX, se decidió lanzar XenServer al mundo de forma gratuita y con código abierto completo en 2009. Sin embargo, el código del sistema de administración patentado de XenCenter no se abrió.
Cabe señalar una interesante coincidencia cronológica de las iniciativas de Citrix y Microsoft en el campo de la virtualización industrial, a pesar de que las empresas siempre estuvieron muy unidas.

A pesar de su nombre comercial común, Citrix XenApp y XenDesktop no tienen nada que ver con el hipervisor Xen.

Amazonas

Amazon IaaS EC2 (Elastic Compute) 2006 . EC2 Xen, Amazon , , .

2017 EC2 KVM . , EC2 KVM .

Linux QEMU / KVM

QEMU (Quick EMUlator) — , GPL v2. x86 ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64. QEMU , . QEMU x86 , KVM (Kernel-based Virtual Machine) Qumranet.

KVM — QEMU KVM, qcow2 (QEMU copy-on-write 2) KVM.
, QEMU , QEMU / KVM .

Qumranet

Una compañía israelí, un antiguo desarrollador y patrocinador principal del hipervisor KVM y el protocolo SPICE. Fundada en 2005, ganó fama después de incorporar KVM en el kernel de Linux. 4 de septiembre de 2008, adquirido por Red Hat.

Sombrero rojo

Como todos los fabricantes de distribución GNU / Linux, hasta 2010, Red Hat tenía soporte incorporado para el hipervisor Xen en sus distribuciones. Sin embargo, al ser un jugador importante en el mercado y una marca seria, pensé en mi propia implementación del hipervisor. La base fue tomada por el hipervisor KVM poco notable pero prometedor. La primera versión de Red Hat Enterprise Virtualization 2.2 (RHEV) se introdujo en 2010 con la pretensión de competir por una parte del mercado de soluciones VDI con Citrix y VMware debido al desarrollo de Qumranet, que se adquirió dos años antes. Fuera de la caja, estaban disponibles clústeres de alta disponibilidad, migración en vivo y herramientas de migración M2M (solo RHEL). Es de destacar que, a juzgar por la documentación de esa época, Red Hat retuvo la notación Xen al describir la arquitectura de la solución.

El 28 de octubre de 2018, IBM anunció la compra de Red Hat.

OpenStack

Históricamente, el proyecto OpenStack surgió como una iniciativa para contrastar algo con el monopolio real de VMware en el campo de la virtualización de servidores pesados ​​x86. El proyecto apareció en 2010 gracias a los esfuerzos conjuntos de Rackspace Hosting (un proveedor de la nube) y la NASA (que abrió el código para su propia plataforma Nebula). El picante de la situación se debió al hecho de que en 2012 VMware se unió a la gestión del proyecto OpenStack y causó una ola de indignación entre los activistas fundadores.

Con el tiempo, Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle se unieron al proyecto.

Sin embargo, no todo fue sencillo. En 2012, la NASA abandonó el proyecto, optando por AWS. A principios de 2016, HPE cerró por completo su proyecto Helion basado en OpenStack.

Como parte del proyecto OpenStack, KVM ha sido adoptado como el hipervisor estándar. Sin embargo, debido a la modularidad del enfoque, se puede implementar un sistema basado en OpenStack utilizando otros hipervisores, dejando, por ejemplo, solo un sistema de control de OpenStack.

Existe una amplia gama de opiniones con respecto al proyecto OpenStack, desde el culto entusiasta hasta el escepticismo serio y las duras críticas. La crítica no carece de razón: se registró un número significativo de problemas y pérdidas de datos al usar OpenStack. Lo que, sin embargo, no impide que los fanáticos nieguen todo y se refieran a la curvatura en la implementación y operación de los sistemas.

El proyecto OpenStack no se limita únicamente a la virtualización, sino que con el tiempo se ha convertido en un número significativo de varios subproyectos y componentes para la expansión en el área de la pila de servicios en la nube pública. Además, la importancia de OpenStack probablemente debería evaluarse con precisión en esta parte: estos componentes se han convertido en clave en muchos productos y sistemas comerciales tanto en el campo de la virtualización como más allá.

En Rusia, OpenStack fuera de las nubes públicas es conocido principalmente por su papel en la sustitución de importaciones. OpenStack incluye la mayor parte de las soluciones y productos de virtualización, incluidos los sistemas hiperconvergentes, con diversos grados de refinamiento.

Nutanix AHV

Nutanix VMware vSphere. - , - VMware , . KVM, AHV (Acropolis HyperVisor).

Paralelos

7 Virtuozzo KVM.

Proxmox

Proxmox VE (Virtual Environment) es un proyecto de código abierto de la compañía austriaca Proxmox Server Solutions GmbH basado en Debian Linux. El primer lanzamiento fue en 2008.
El producto admite la virtualización de contenedores LXC (anteriormente OpenVZ) y la virtualización completa con el hipervisor KVM.

Paralelos / Virtuozzo / Rosplatform

Fundada en 1999 por Sergey Belousov, SWsoft tomó el software de gestión de hosting. En 2003, se adquirió la compañía rival de Novosibirsk, Plesk.

En 2004, SWsoft adquirió la compañía rusa Parallels Nikolai Dobrovolsky con su producto Parallels Workstation (hipervisor de escritorio del segundo tipo en Windows).
La compañía combinada conserva su nombre Parallels y pronto explotará el mercado con Parallels Desktop para Mac (hipervisor de escritorio del segundo tipo para MacOS).

Como parte de la virtualización del servidor, el enfoque continúa en el alojamiento de proveedores y centros de datos, en lugar del uso corporativo. Debido a las características específicas de este mercado en particular, los contenedores Virtuozzo y OpenVZ, en lugar de las máquinas virtuales del sistema, se convirtieron en el producto clave. Posteriormente, Parallels, sin mucho éxito, está tratando de ingresar al mercado de virtualización de servidores empresariales con el producto Parallels Bare Metal Server (posteriormente Parallels Hypervisor y Cloud Server, y luego Virtuozzo), agrega hiperconvergencia con su Cloud Storage. El trabajo continúa en la automatización y orquestación de proveedores de hosting.

2015 — ( ) Virtuozzo, . Depo IBS -.

7 Virtuozzo , 7 KVM. , — KVM.
, 2019 .

Parallels Desktop Parallels Corel. Odin IngramMicro. Virtuozzo / .