Solaris Containers (que incluye Solaris Zones ) es una implementación de tecnología de virtualización a nivel de sistema operativo para sistemas x86 y SPARC, lanzada públicamente por primera vez en febrero de 2004 en la versión beta 51 de Solaris 10 , y posteriormente en la primera versión completa de Solaris 10, 2005. Está presente en distribuciones de illumos (anteriormente OpenSolaris ), como OpenIndiana , SmartOS , Tribblix y OmniOS, y en la versión oficial de Oracle Solaris 11.
Un contenedor Solaris es la combinación de controles de recursos del sistema y la separación de límites proporcionada por zonas . Las zonas actúan como servidores virtuales completamente aislados dentro de una única instancia del sistema operativo. Al consolidar varios conjuntos de servicios de aplicaciones en un sistema y colocar cada uno en contenedores de servidores virtuales aislados, los administradores de sistemas pueden reducir los costos y proporcionar la mayoría de las mismas protecciones de máquinas separadas en una sola máquina. [1]
El nombre de esta tecnología cambió durante el desarrollo y los eventos públicos previos al lanzamiento. Antes del lanzamiento de Solaris Zones en 2005, un contenedor Solaris era cualquier tipo de carga de trabajo limitada por las funciones de administración de recursos de Solaris. En un principio, este último había sido un paquete de software independiente. En 2007, el término Solaris Containers pasó a significar una zona Solaris combinada con controles de administración de recursos.
Más tarde, se produjo un cambio gradual, de modo que los contenedores de Solaris se referían específicamente a zonas no globales, con o sin administración de recursos adicional. Las zonas alojadas por una zona global se conocen como "zonas no globales", pero a veces se las llama simplemente "zonas". El término "zona local" se desaconseja específicamente, ya que en este uso "local" no es un antónimo de "global". La zona global tiene visibilidad de todos los recursos del sistema, ya sea que estén asociados con la zona global o con una zona no global. A menos que se indique lo contrario, "zona" se referirá a zonas no globales en este artículo.
Para simplificar la terminología, Oracle abandonó el uso del término Contenedor en Solaris 11 y volvió al uso del término Zona Solaris independientemente del uso de controles de administración de recursos.
Cada zona tiene su nombre de nodo, acceso a interfaces de red virtuales o físicas [2] y almacenamiento asignado; no existe ningún requisito para que una zona tenga una cantidad mínima de hardware dedicado aparte del almacenamiento en disco necesario para su configuración única. En concreto, no requiere una CPU, memoria, interfaz de red física o HBA dedicados , aunque cualquiera de estos puede asignarse específicamente a una zona. [3]
Cada zona tiene un límite de seguridad que la rodea, lo que impide que un proceso asociado con una zona interactúe con procesos de otras zonas o los observe. Cada zona se puede configurar con su propia lista de usuarios independiente. El sistema administra automáticamente los conflictos de ID de usuario; es decir, dos zonas de un sistema podrían tener un ID de usuario 10000 definido y cada una de ellas se asignaría a su propio identificador global único. [4]
Una zona puede estar en uno de los siguientes estados:
Algunos programas no se pueden ejecutar desde una zona no global; normalmente esto se debe a que la aplicación requiere privilegios que no se pueden conceder dentro de un contenedor. Como una zona no tiene su propio núcleo independiente (a diferencia de una máquina virtual de hardware ), las aplicaciones que requieren manipulación directa de las características del núcleo, como la capacidad de leer o alterar directamente el espacio de memoria del núcleo, pueden no funcionar dentro de un contenedor.
Las zonas generan una sobrecarga muy baja en la CPU y la memoria. La mayoría de los tipos de zonas comparten el espacio de direcciones virtuales de la zona global. Una zona puede asignarse a un grupo de recursos (conjunto de procesadores más clase de programación) para garantizar un uso determinado, puede limitarse a una capacidad de cómputo fija ("CPU limitada") o se le pueden asignar partes a través de una programación de reparto equitativo . [5]
Actualmente, se puede crear un máximo de 8191 zonas no globales dentro de una única instancia del sistema operativo. Las "zonas dispersas", en las que la mayor parte del contenido del sistema de archivos se comparte con la zona global, pueden ocupar tan solo 50 MB de espacio en disco. Las "zonas raíz completas", en las que cada zona tiene su propia copia de los archivos de su sistema operativo, pueden ocupar desde varios cientos de megabytes hasta varios gigabytes, según el software instalado. Los límites de 8191 surgen del límite de 8192 conexiones de bucle invertido por instancia de Solaris. Cada zona necesita una conexión de bucle invertido. La zona global obtiene una, dejando 8191 para las zonas no globales.
Incluso con zonas raíz completas, los requisitos de espacio en disco pueden ser insignificantes si el sistema de archivos del sistema operativo de la zona es un clon ZFS de la imagen de la zona global, ya que solo los bloques diferentes de una imagen instantánea deben almacenarse en el disco; este método también permite crear nuevas zonas en unos pocos segundos.
Aunque todas las zonas del sistema comparten un núcleo común, se ha añadido un conjunto de características adicionales llamadas zonas de marca ( BrandZ , para abreviar). Esto permite que las zonas individuales se comporten de una manera distinta a la marca predeterminada de la zona global. Las marcas existentes (octubre de 2009) se pueden agrupar en dos categorías:
La marca de una zona se establece en el momento en que se crea la zona. La segunda categoría se implementa con puntos de interposición dentro del núcleo del sistema operativo que se pueden usar para cambiar el comportamiento de las llamadas al sistema , la carga de procesos , la creación de subprocesos y otros elementos.
Para la marca 'lx', se requieren bibliotecas de Red Hat 3 o una distribución equivalente como CentOS para completar el entorno emulado.
El sistema operativo Solaris proporciona páginas de manual para Solaris Containers de forma predeterminada; se puede encontrar documentación más detallada en varios recursos técnicos en línea.
El primer documento publicado y de referencia práctica para Solaris Zones fue escrito en febrero de 2004 por Dennis Clarke en Blastwave, y proporcionaba los elementos esenciales para comenzar. Brendan Gregg amplió considerablemente este documento en julio de 2005. [8] Los contenedores de Solaris 8 y Solaris 9 fueron documentados en detalle por Dennis Clarke en Blastwave nuevamente en abril de 2008. El documento de contenedores de Solaris 8 y Solaris 9 de Blastwave se publicó en una etapa muy temprana del ciclo de lanzamiento de la tecnología de contenedores de Solaris y las acciones e implementación en Blastwave dieron como resultado un seguimiento por parte del departamento de marketing de Sun Microsystems. El libro Oracle Solaris 10 System Virtualization Essentials escrito por Jeff Victor, et al., ofrece detalles de las características y las mejores prácticas. Se puede encontrar documentación más extensa en el sitio de documentación de Oracle. [9]
A partir de Solaris 10 10/08, las zonas de marca son compatibles con la arquitectura sun4us (servidores Fujitsu PRIMEPOWER) a través de los paquetes FJSVs8brandr y FJSVs9brandr. [10]