Servidores virtuales: puros y clónicos
Un ordenador físico que contiene varios ordenadores lógicos: esta idea se encuentra en los mismos orígenes de los sistemas operativos, y ha evolucionado junto con ellos. En la actualidad se habla de dividir un servidor físico en múltiples servidores virtuales, entendiendo que estos contienen casi todas, cuando no todas, las capacidades del sistema que los aloja. Existen varias formas de crear esos servidores virtuales. En este artículo analizamos dos buenas opciones para conseguir que una máquina se transforme en tres ¡o treinta! servidores, y que (casi) no se note.
El sistema operativo VM/370 de IBM vio la luz en el año 1972. El VM/370 fue el heredero de una larga tradición de sistemas operativos de tiempo compartido, iniciada a principio de los años 60 en el M.I.T. Descendiente directo del CP/67, que se ejecutaba en sistemas 360, el VM/370 se entregaba con la flamante familia de sistemas 370, entonces la última joya de IBM. Una de las posibilidades más interesantes del VM/370 era su capacidad para crear máquinas virtuales independientes y ejecutar un sistema operativo diferente en cada una de ellas. Con otras palabras, hace treinta años existía una máquina que permitía tener varios sistemas virtuales en paralelo, con igual o distinto sistema operativo y, pásmese, tan independientes que el cuelgue de una máquina virtual no afectaba al resto.
El sistema operativo que se ejecutaba sobre una de estas máquinas virtuales no sabía que debajo de él no había un verdadero sistema 370, sino una máquina virtual que simulaba un ordenador de ese tipo. Esta forma de crear ordenadores lógicos, a los que llamaremos virtuales puros, presenta numerosas ventajas, como se verá más adelante, pero a costa de aumentar la complejidad de la solución y de penalizar el rendimiento de los servidores virtuales. En cambio, existe otra opción que simplifica la creación de los sistemas lógicos y que apenas incide en la carga de las máquinas. Por el contrario, no posee algunas de las ventajas de los virtuales puros, como la convivencia de diferentes sistemas operativos en el mismo servidor, o un control exhaustivo de los recursos de la máquina. A esta solución la denominaremos virtuales clónicos, y la trataremos con detenimiento en la segunda parte de este artículo.
Virtuales puros
Platón utilizó una conocida alegoría para explicar el mundo de las ideas. En ella, un grupo de esclavos, atados de pies y manos, tienen la cabeza inmovilizada de forma que sólo pueden ver las sombras que se proyectan en una pared de la caverna donde están recluidos. Los objetos reales no existen para ellos, porque no los han visto nunca. Los esclavos están convencidos de que las sombras son los únicos objetos reales, y sus conocimientos y experiencias no van más allá de esas sombras. Un sistema operativo sufre una situación parecida con respecto a los dispositivos reales. Linux, MS Windows o Solaris no tratan directamente con el hardware: no pueden ver la parte física del ordenador donde habitan. Los sistemas operativos utilizan la sombra lógica de los dispositivos, esto es, los controladores (drivers) y la microprogramación. ¿Quién no ha buscado un driver para que el sistema operativo ‘vea’ esa dichosa tarjeta gráfica o la nueva tarjeta de red? El sistema operativo vive feliz en su mundo de dispositivos lógicos, y no se preocupa por la chatarra que habita en el piso de abajo. Tanto es así, que no existe ningún obstáculo para que un controlador, en lugar de comunicarse con el hardware, trate con un dispositivo lógico que simule el correspondiente dispositivo físico.
Si ampliamos este concepto a todo el sistema, hablaremos de un nuevo nivel que, situado entre la parte física del servidor y el sistema operativo, convierte los elementos hardware de la máquina (procesadores, memoria, discos, etc.) en unidades lógicas que serán las que utilice el sistema operativo (figura 1). La gran ventaja que ofrece este nuevo nivel reside en la enorme flexibilidad y control que se obtiene sobre los dispositivos físicos. Antes de seguir profundizando en esta idea, básica para entender los servidores virtuales puros, permítanos que citemos un ejemplo que ayudará a comprender mejor lo que estamos hablando.
Existen en el mercado un buen número de tarjetas controladoras de discos que permiten unir un par de ellos en una estructura de tipo RAID 1. Ambos discos contendrán los mismos datos, y la controladora RAID se encargará de escribir por duplicado la información. Desde el punto de vista del sistema operativo, el servidor sólo tiene un disco, de tal modo que si los discos lo permiten, se puede quitar uno de ellos de golpe y el servidor seguirá funcionando sin problemas. Este mismo RAID 1 se puede crear a través de software, en lugar de hardware, y el sistema operativo creerá, de nuevo, que sólo tiene un disco duro, aunque en verdad existan dos.
De igual forma, la capa que se sitúa entre el nivel físico y los servidores virtuales puede engañar a estos últimos por completo, separando totalmente el hardware real del sistema operativo. Así funciona ESX Server de VMWare. Los sistemas operativos alojados por encima de ESX Server sólo acceden a dispositivos virtuales: procesadores, memoria, tarjetas de red, disquetera, controladoras SCSI,... todos son elementos lógicos controlados por ESX.
Aislamiento de fallos y gestión
La asignación de los recursos del sistema a cada servidor virtual permite controlar con mucho detalle el número de ciclos de CPU, la memoria, el disco y el ancho de banda que tendrá cada servidor. Se pueden modificar, de forma dinámica, estos valores, lo que da una gran flexibilidad a los administradores del sistema. Cada servidor virtual puede tener asignado un procesador –VMWare anuncia dos en su próxima versión– hasta 3,6 Gbytes de memoria, nueve TBytes de disco y cuatro adaptadores Ethernet. Por supuesto, estos dispositivos son virtuales, porque los dispositivos físicos están repartidos entre todos los servidores virtuales.
Un aspecto que preocupa mucho a los usuarios de este tipo de soluciones es el grado de aislamiento de los servidores virtuales ante el fallo de uno de ellos. ESX server asegura la estanqueidad de cada servidor virtual, lo que evita que la parada inesperada de uno de ellos arrastre a otros o, incluso, al sistema completo. Este grado de independencia también se ve reflejado en la gran variedad de sistemas operativos que admite ESX: FreeBSD, Red Hat y Red Hat Advanced Server, SuSE Server y Windows NT, 2000 y 2003.
La gestión de los servidores virtuales se hace desde una consola central, de forma local o remota, que permite crear, mover y eliminar servidores virtuales, y asignar los recursos que se deseen a cada uno de ellos. Una API en Perl facilita la provisión automática de servidores, a lo que se añade la supervisión remota a través de SNMP. En esta versión se ha aumentado hasta 64 el número máximo de servidores virtuales por máquina, y también la cantidad total de memoria física, que ahora llega a los 64 Gbytes.
Con todo esto no resulta extraño que, en un único servidor, se instale un W2000 con Exchange, un Linux con Apache, otro con TomCat y un cluster de SQL2000. Porque, esa es otra, con ESX se puede montar un cluster de Microsoft entre dos servidores virtuales que comparten dos discos virtuales, ya sean en la misma máquina física o con dos ordenadores con ESX Server. De este
El sistema operativo VM/370 de IBM vio la luz en el año 1972. El VM/370 fue el heredero de una larga tradición de sistemas operativos de tiempo compartido, iniciada a principio de los años 60 en el M.I.T. Descendiente directo del CP/67, que se ejecutaba en sistemas 360, el VM/370 se entregaba con la flamante familia de sistemas 370, entonces la última joya de IBM. Una de las posibilidades más interesantes del VM/370 era su capacidad para crear máquinas virtuales independientes y ejecutar un sistema operativo diferente en cada una de ellas. Con otras palabras, hace treinta años existía una máquina que permitía tener varios sistemas virtuales en paralelo, con igual o distinto sistema operativo y, pásmese, tan independientes que el cuelgue de una máquina virtual no afectaba al resto.
El sistema operativo que se ejecutaba sobre una de estas máquinas virtuales no sabía que debajo de él no había un verdadero sistema 370, sino una máquina virtual que simulaba un ordenador de ese tipo. Esta forma de crear ordenadores lógicos, a los que llamaremos virtuales puros, presenta numerosas ventajas, como se verá más adelante, pero a costa de aumentar la complejidad de la solución y de penalizar el rendimiento de los servidores virtuales. En cambio, existe otra opción que simplifica la creación de los sistemas lógicos y que apenas incide en la carga de las máquinas. Por el contrario, no posee algunas de las ventajas de los virtuales puros, como la convivencia de diferentes sistemas operativos en el mismo servidor, o un control exhaustivo de los recursos de la máquina. A esta solución la denominaremos virtuales clónicos, y la trataremos con detenimiento en la segunda parte de este artículo.
Virtuales puros
Platón utilizó una conocida alegoría para explicar el mundo de las ideas. En ella, un grupo de esclavos, atados de pies y manos, tienen la cabeza inmovilizada de forma que sólo pueden ver las sombras que se proyectan en una pared de la caverna donde están recluidos. Los objetos reales no existen para ellos, porque no los han visto nunca. Los esclavos están convencidos de que las sombras son los únicos objetos reales, y sus conocimientos y experiencias no van más allá de esas sombras. Un sistema operativo sufre una situación parecida con respecto a los dispositivos reales. Linux, MS Windows o Solaris no tratan directamente con el hardware: no pueden ver la parte física del ordenador donde habitan. Los sistemas operativos utilizan la sombra lógica de los dispositivos, esto es, los controladores (drivers) y la microprogramación. ¿Quién no ha buscado un driver para que el sistema operativo ‘vea’ esa dichosa tarjeta gráfica o la nueva tarjeta de red? El sistema operativo vive feliz en su mundo de dispositivos lógicos, y no se preocupa por la chatarra que habita en el piso de abajo. Tanto es así, que no existe ningún obstáculo para que un controlador, en lugar de comunicarse con el hardware, trate con un dispositivo lógico que simule el correspondiente dispositivo físico.
Si ampliamos este concepto a todo el sistema, hablaremos de un nuevo nivel que, situado entre la parte física del servidor y el sistema operativo, convierte los elementos hardware de la máquina (procesadores, memoria, discos, etc.) en unidades lógicas que serán las que utilice el sistema operativo (figura 1). La gran ventaja que ofrece este nuevo nivel reside en la enorme flexibilidad y control que se obtiene sobre los dispositivos físicos. Antes de seguir profundizando en esta idea, básica para entender los servidores virtuales puros, permítanos que citemos un ejemplo que ayudará a comprender mejor lo que estamos hablando.
Existen en el mercado un buen número de tarjetas controladoras de discos que permiten unir un par de ellos en una estructura de tipo RAID 1. Ambos discos contendrán los mismos datos, y la controladora RAID se encargará de escribir por duplicado la información. Desde el punto de vista del sistema operativo, el servidor sólo tiene un disco, de tal modo que si los discos lo permiten, se puede quitar uno de ellos de golpe y el servidor seguirá funcionando sin problemas. Este mismo RAID 1 se puede crear a través de software, en lugar de hardware, y el sistema operativo creerá, de nuevo, que sólo tiene un disco duro, aunque en verdad existan dos.
De igual forma, la capa que se sitúa entre el nivel físico y los servidores virtuales puede engañar a estos últimos por completo, separando totalmente el hardware real del sistema operativo. Así funciona ESX Server de VMWare. Los sistemas operativos alojados por encima de ESX Server sólo acceden a dispositivos virtuales: procesadores, memoria, tarjetas de red, disquetera, controladoras SCSI,... todos son elementos lógicos controlados por ESX.
Aislamiento de fallos y gestión
La asignación de los recursos del sistema a cada servidor virtual permite controlar con mucho detalle el número de ciclos de CPU, la memoria, el disco y el ancho de banda que tendrá cada servidor. Se pueden modificar, de forma dinámica, estos valores, lo que da una gran flexibilidad a los administradores del sistema. Cada servidor virtual puede tener asignado un procesador –VMWare anuncia dos en su próxima versión– hasta 3,6 Gbytes de memoria, nueve TBytes de disco y cuatro adaptadores Ethernet. Por supuesto, estos dispositivos son virtuales, porque los dispositivos físicos están repartidos entre todos los servidores virtuales.
Un aspecto que preocupa mucho a los usuarios de este tipo de soluciones es el grado de aislamiento de los servidores virtuales ante el fallo de uno de ellos. ESX server asegura la estanqueidad de cada servidor virtual, lo que evita que la parada inesperada de uno de ellos arrastre a otros o, incluso, al sistema completo. Este grado de independencia también se ve reflejado en la gran variedad de sistemas operativos que admite ESX: FreeBSD, Red Hat y Red Hat Advanced Server, SuSE Server y Windows NT, 2000 y 2003.
La gestión de los servidores virtuales se hace desde una consola central, de forma local o remota, que permite crear, mover y eliminar servidores virtuales, y asignar los recursos que se deseen a cada uno de ellos. Una API en Perl facilita la provisión automática de servidores, a lo que se añade la supervisión remota a través de SNMP. En esta versión se ha aumentado hasta 64 el número máximo de servidores virtuales por máquina, y también la cantidad total de memoria física, que ahora llega a los 64 Gbytes.
Con todo esto no resulta extraño que, en un único servidor, se instale un W2000 con Exchange, un Linux con Apache, otro con TomCat y un cluster de SQL2000. Porque, esa es otra, con ESX se puede montar un cluster de Microsoft entre dos servidores virtuales que comparten dos discos virtuales, ya sean en la misma máquina física o con dos ordenadores con ESX Server. De este
