Universidad de Alcal

Escuela Politcnica Superior

Ingeniera tcnica en telecomunicaciones: Telemtica

Trabajo Fin de Carrera

Migracin de servidores SUN/Solaris: Compatibilidad software

bajo arquitectura SPARC

Rubn Hernndez Gmez

Septiembre 2015

Universidad de Alcal
Escuela Politcnica Superior

Ingeniera tcnica en telecomunicaciones: Telemtica

Trabajo Fin de Carrera

Migracin de servidores SUN/Solaris: Compatibilidad

software bajo arquitectura SPARC

Autor
Director
Co-Director

:
:
:

Tribunal

Rubn Hernndez Gmez

Luis de Marcos Ortega
Eva Garca Lpez

Presidente:
Vocal 1

Vocal 2

Calificacin

: _________________________

Alcal de Henares a,

de

del 2015

Dariannis, esto realmente no hubiera sido posible sin ti.

Gracias por tu paciencia, tu apoyo incondicional y por no perder la fe
en m. TE QUIERO.
Gracias a Pablo (PCI) por tus largas lecciones hasta altas horas de la
madrugada, por tu ayuda desinteresada y por tu paciencia.
Maie, gracias tambin a ti, al final mereci la pena.
A mis padres de una manera u otra, se lo deba.

RESUMEN
En los ltimos aos, las tcnicas de virtualizacin han cobrado especial inters
por ser una de las tcnicas ms utilizadas en el ofrecimiento de servicios
informticos. Es tan as, que la tendencia es ascendente y no se prevn cambios
en el futuro inmediato.
La virtualizacin consigue ejecutar diferentes mquinas (mquinas virtuales) en
un mismo servidor fsico. Cada una de esas mquinas puede dar un servicio
diferente. Gracias a esto, se obtienen diversos beneficios como por ejemplo:
ahorro en adquisicin de hardware, menor consumo elctrico y mejor gestin
administrativa tanto de las mquinas como de la red.
En contra hay que destacar que tambin hay desventajas cuando se desarrollan
tcnicas de virtualizacin. El principal problema es la obtencin de peores
tiempos de respuesta en servicios de entornos virtualizados que en entornos no
virtualizados. Sin embargo los beneficios son superiores con creces a los
inconvenientes, y prueba de ello es el crecimiento de utilizacin de estas
tcnicas en la mayora de las empresas que ofrecen servicios informticos.
En esta memoria se hace un recorrido de los diferentes modelos de
virtualizacin existentes y se plantea un caso real que justifica el uso de la
tecnologa.
Se partir de un escenario real para compatibilizar software gracias a la solucin
de virtualizacin de plataforma que ofrece ORACLE a travs de Solaris OS. Se
har un anlisis de la arquitectura de computadores del escenario,
estudiaremos el servidor que utilizaremos para llevar a cabo la implementacin
prctica y finalmente sacaremos conclusiones de los resultados obtenidos a
partir del trabajo realizado y alguna propuesta de trabajos futuros en el mismo
mbito.

PALABRAS CLAVE: Solaris, virtualizacin, UNIX, sistema operativo, ORACLE

VM, SPARC.

ABSTRACT
In recent years, virtualization techniques have gained particular interest as one
of the techniques used in providing IT services. Is as well, the trend is up and no
changes in the near future are anticipated.
Virtualization gets run different machines (VMs) on a single physical server.
Each of these machines can give a different service. Thanks to this, you get
various benefits such as: acquisition of hardware savings, lower power
consumption and better administration both machines and network.
Contrary should be noted that there are also disadvantages when virtualization
techniques are developed. The main problem is getting worse response times in
virtualized environments services in non-virtualized environments. However,
the benefits by far outweigh the disadvantages, and the proof is the growing
use of these techniques in most companies that offer computer services.
In this memory there is a tour of the various existing models and virtualization is
a real case that justifies the use of technology arises.
We will start a real scenario for software compatibility thanks to the platform
virtualization solution that offered through Oracle Solaris OS. An analysis of
computer architecture will stage, study the server will use to carry out the
practical implementation and finally we will draw conclusions from the results
obtained from the work and ideas for future work in the same field.

KEYWORDS: Solaris, Virtualization, UNIX, operating system, ORACLE VM,

SPARC.
8

NDICE

1. INTRODUCCIN
1.1 Justificacin del proyecto. 11
1.2 Objetivos y campo de aplicacin..11
1.3 Estructura de la memoria..13
2. VIRTUALIZACIN
2.1
Historia de la virtualizacin..17
2.1.1 Antecedentes.17
2.2
Terminologa19
2.2.1 Mquina virtual e hipervisor20
2.3
Modelos de virtualizacin..22
3. SOLARIS SPARC
3.1
Historia de Solaris..39
3.2

Hardware SUN40

3.3

Arquitectura SPARC..41
3.3.1 Arquitectura SPARC V-9.42
3.3.2 Procesador UltraSPARC-I..42
3.3.3 Estrategia SPARC.43
3.3.4 Arquitectura UltraSPARC45

3.4

SUNFIRE T2000.49
3.4.1 Gestin remota con ALOM CMT51
3.4.2 Fiabilidad, disponibilidad y capacidad..52

4. VIRTUALIZACIN EN SOLARIS
4.1
Dominios fsicos(DSD)..56
4.2
Oracle VM para SPARC63
4.2.1 Hipervisor y dominios lgicos.64
4.2.2 Logical Domain Manager .66
4.3
Solaris Zones ..74
4.3.1 Zonas globales y no globales76

 5. DISEO E IMPLEMENTACIN

5.1
5.2
5.3
5.4
5.5

Introduccin83
Estado inicial..85
Downgrade a Logical Domains 1.2..86
Configuracin del control domain88
Configuracin de dominios invitados.93
5.5.1 Asignacin de recursos.94

5.6

Instalacin de Solaris 10 en guest domain.97

5.6.1 Configuracin de red..107

5.7
5.8

Creacin de imagen flar de Solaris 9....111

Instalacin de flar en todd-test1111
5.8.1 Creacin de brandez zone112

CONCLUSIONES.....115
BIBLIOGRAFA Y URLs.119

10

1. INTRODUCCIN
1.1.

Justificacin y contexto del proyecto

En el mbito de las TIC (Tecnologas de la Informacin y la Comunicacin),

estamos continuamente sujetos a cambios.
Constantemente surgen nuevas tecnologas, otras evolucionan, y en muchas
ocasiones otras se estancan o incluso llegan a desaparecer.
Algunas veces aparecen avances tecnolgicos y productos que marcan un antes
y un despus en la historia, y que ya sea por su utilidad, versatilidad o economa
llegan a consolidarse en el mercado de manera estable.
Algn ejemplo de estos avances tan destacables son la revolucin de los 32 bits,
o la aparicin de interfaces grficos de usuario, podramos destacar tambin los
sistemas operativos multitarea y muchos otros ms.
La virtualizacin es una tecnologa que pertenece a este conjunto de hitos
histricos.
Ha pasado suficiente tiempo para que haya un consenso generalizado sobre las
innegables ventajas de la virtualizacin sobre la implantacin de CPD (Centro de
Procesamiento de Datos) con la exclusiva presencia de servidores fsicos.

1.2

Objetivos y campo de aplicacin

En muchas ocasiones los requerimientos hardware para aplicativos existentes

en un determinado momento son incrementados un tiempo despus por los
avances tecnolgicos naturales. Esto supone una necesidad de actualizacin de
hardware que en muchas ocasiones compite con el requerimiento de algunos
programas de correr en determinados sistemas operativos, en determinadas
versiones, y con determinadas arquitecturas.
Este proyecto se ve motivado por esta problemtica y se presenta en el
siguiente escenario:
Solaris es un sistema operativo de tipo UNIX muy extendido en el mundo
empresarial, sobre todo en sus versiones para arquitecturas SPARC (Scalable
Processor ARChitecture).
Muchas empresas requieren de software especfico creado exclusivamente para
las necesidades de esa empresa.
Nos situaremos en el caso de una empresa que compr en su da software
hecho a medida, que es perfectamente vlido para sus requisitos. Este software
corre en Solaris 9, versin que se encuentra fuera de periodo de soporte oficial
(finaliz en 2014), y muy probablemente tendr problemas de compatibilidad
en una versin superior.
Debido a las necesidades de la empresa, por aumento en nmero de clientes,
por ejemplo, es conveniente actualizar el hardware para beneficiarse tanto de la
potencia como de las novedades en versiones posteriores de Solaris, adems de
11

la evidente necesidad de disponer de un sistema operativo actualizado y con

soporte oficial.
Por otra, parte, en un servidor ms potente, pueden convivir, aprovechando la
consolidacin de servidores, ms mquinas virtuales dando diferentes servicios.
Incluso se puede prescindir de la mquina antigua, migrando sta a un servidor
con recursos excedentes, que puedan satisfacer las necesidades de la mquina
portadora de este software hecho a medida mencionado.
En nuestro caso migraremos una mquina antigua de la que la empresa va a
prescindir en la que corre Solaris 9 a una mquina relativamente moderna: SUN
T2000, con una versin actual de Solaris.
Para ello nos beneficiaremos de las bondades que nos ofrece el sistema
operativo Solaris a partir de la versin 10, ms concretamente en el llamado
Oracle VM (Oracle Virtual Machine) para SPARC.
Nos aprovecharemos esta funcionalidad de Solaris que nos permite virtualizar a
nivel de LDOM (Logical Domain), y a su vez crearemos una zona con sistema
operativo Solaris 9, virtualizando de esta manera compartiendo kernel,
consiguiendo nuestro objetivo principal, que es disponer de nuestro aplicativo.
Con esto habremos conseguido compatibilizar nuestro antiguo software en
mquinas actuales con mucha ms capacidad de procesamiento, y con soporte
oficial de ORACLE.
Nuestro esquema quedara as:

12

1.3

Estructura de la memoria

A continuacin vemos una introduccin a los captulos que componen la

memoria:
Captulo 2. Virtualizacin. En este captulo haremos un repaso de esta
tecnologa desde su origen hasta los modelos actuales. Nos familiarizaremos
con algunos conceptos indispensables para su comprensin, y estudiaremos los
diferentes modelos de virtualizacin que existen.
Captulo 3. Solaris SPARC. Analizaremos la evolucin del sistema operativo
Solaris, y nos centraremos en los sistemas con arquitectura SPARC, viendo las
novedades de algunos de los procesadores. Nos centraremos en la mquina
utilizada para la implementacin prctica estudiando sus caractersticas.
Captulo 4. Virtualizacin en Solaris. Veremos las soluciones que ofrece ORACLE
con sus modos de virtualizacin en su sistema operativo por excelencia:
dominios fsicos, dominios lgicos y zonas. Detallaremos en profundidad el
funcionamiento de los dos ltimos al ser materia fundamental de la
implementacin prctica.
Captulo 5. Diseo e implementacin. Trabajo prctico con un escenario real.
Disponemos de una mquina SUNFIRE T2000 donde implementaremos nuestro
entorno virtualizado. Montaremos los dominios lgicos y zonas requeridas para
poder simular una migracin y as justificar la compatibilidad de software.
Conclusiones. Analizaremos crticamente los resultados obtenidos y la utilidad
de la prctica, mostrando las bondades y debilidades del sistema elegido.

13

14

2. VIRTUALIZACIN
Sin lugar a dudas, la virtualizacin es una de las innovaciones tecnolgicas ms
decisivas en la actualidad, con gran calado y demanda que est revolucionando
el sector de las tecnologas de la informacin ya que modifica su modelo de
trabajo en casi todos los niveles.
Por definirlo en una oracin, virtualizar es conseguir la ejecucin de mquinas con sistemas operativos, aplicaciones y otros servicios propios dentro de otras
mquinas. Aqu yace una gran diferencia con respecto a otras tcnicas que
tambin adoptan la etiqueta de virtualizacin, pero muy distintas; por ejemplo
el Grid Computing o Server Agregation (agregacin de servidores), que consiste
en resumen en lograr percibir como uno solo, la conexin de mltiples
servidores.

Imagen 1: Consolidacin de servidores

Desde hace ms de cuarenta aos, la virtualizacin ha estado presente aunque

minoritariamente en grandes centros de clculo. Sin embargo, recientemente el
uso de esta tecnologa alcanz un crecimiento exponencial debido a la evolucin
del hardware, su reduccin de precio, y las constantes mejoras de software.
Comenzaba as el desarrollo de diversos proyectos tanto libres como de
empresa privada, lo que tuvo como consecuencia la llegada de la virtualizacin
al escritorio y con esto el evidente aumento de popularidad debido a las
bondades de su implantacin.
Esta tecnologa permite la instalacin, administracin, y configuracin de varias
mquinas lgicas (mquinas virtuales), cada una con su sistema operativo y
aplicaciones, con acceso a los recursos fsicos del servidor anfitrin.
La virtualizacin como tal (a diferencia de la emulacin y la simulacin), necesita
de una capa de abstraccin que sirva de interfaz entre las mquinas virtuales y
el servidor anfitrin, haciendo cambios en el sistema operativo anfitrin para
que las mquinas virtuales accedan a los recursos del servidor.
Algunos de los nombres de esta capa son: Hypervisor (hipervisor), o VMM,
Virtual Machine Monitor (monitor de mquinas virtuales).
15

Dentro de este modelo general de virtualizacin, hay diferencias que causan la

existencia de diversos modelos. Por ejemplo, puede haber o no hipervisor,
tambin diferencias en el sistema operativo de la mquina anfitriona,
transparencia en la virtualizacin para las mquinas virtuales, y la adicin de
otras tcnicas (por ejemplo, emulacin), provocan que estos modelos se
adapten a los diversos escenarios donde queremos implantar la virtualizacin, y
que hace que diferentes escenarios y tcnicas ofrezcan diferentes rendimientos
dependiendo de cada caso.
Ninguna es mejor ni peor, simplemente se deber elegir el sistema y la tcnica
adecuada para nuestras necesidades. Por ejemplo, virtualizacin a nivel de
sistema operativo, a nivel de aplicaciones, a nivel de hardware, a nivel de kernel
de Linux, etc.
Gracias a esta multitud de modelos y su configuracin, en la actualidad la
virtualizacin es de gran utilidad en las empresas, ya que las posibilidades son
muy variadas. Casi se puede decir que disponemos de un modelo para cada
situacin.
Cabe destacar entre todas las aplicaciones la consolidacin de servidores, es
decir encapsulacin de servidores en mquinas virtuales. La popularidad de la
consolidacin es debido al gran consumo energtico de los servidores
combinado con el poco porcentaje de utilizacin real de los recursos del
servidor.
En los CPDs actuales, (Centro de Procesamiento de Datos) se van adquiriendo
servidores dependiendo de las necesidades del servicio, aumentando as el
nmero de mquinas fsicas, ocupando ms espacio, e infrautilizando los
recursos disponibles.
En este punto es donde la consolidacin de servidores juega un papel
fundamental, permitiendo una reduccin de costes a todos los niveles: espacio,
energa, facilidad de realizar cambios, gestin, recuperacin antes fallas, etc
con la ventaja de ganar en eficiencia y optimizacin en el uso de recursos del
servidor gracias a la integracin de mltiples mquinas virtuales en una fsica.

16

2.1

Historia de la virtualizacin

Para comprender en profundidad la evolucin de la tecnologa de la

virtualizacin es necesario hacer un repaso histrico. De esta forma conociendo
el surgimiento y las circunstancias que se dieron, entenderemos la evolucin de
esta tecnologa hasta llegar a la situacin actual, en la que la virtualizacin
comprende una diversidad de modelos aplicables para solucionar las
necesidades de las empresas actuales.
Tanta variedad de modelos conlleva que se pueda confundir el trmino de
virtualizacin con otras tcnicas diferentes.
Haremos un recorrido detenindonos en algunos productos hardware de Intel y
de AMD, que son referencia en algunos escenarios en los que se requiere un
soporte fsico para llevar a cabo la virtualizacin.
Finalmente, entenderemos la importancia de la virtualizacin en la actualidad y
la seguridad de que seguir cobrando importancia en el futuro.
2.1.2 Antecedentes
El concepto de virtualizar es entendido en trminos generales como hacer
parecer algo en un estado que no es realmente en el que se encuentra.
Partiendo de este concepto, ha habido dos tcnicas que han evolucionado de
forma parelela:
Hacer que un computador reparta recursos para comportarse como
varios computadores (Virtualizacin)
Hacer que varios computadores unan recursos para comportarse como
un computador. (Grid computing o agregacin de servidores)
Podemos remontarnos 40 50 aos en los que ya se puede considerar que
exista la tcnica de la virtualizacin. Al igual que tantos otros servicios, y
tecnologas, eran slo aplicables en grandes centros de clculo, con grandes
recursos. Uno de los primeros usos en esta tcnica se dio con el IBM7044, en la
que haba una mquina fsica (M44), que albergaba mquinas lgicas para
procesos. Tambin el proyecto Atlas que desarroll la Manchester University.
Este proyecto destac debido a importantes novedades para la poca (dcada
de los 60) que ayudaba a mitigar los problemas de la forma de trabajo habitual:
el uso de un ordenador central y el acceso a los recursos a travs de terminales
por parte de los trabajadores.
Bsicamente se trataba de un particionado de recursos en el que el trabajo de
una persona no interfera en el de otro. As nace la virtualizacin, con esta
particin de recursos (memoria, uso de disco, capacidad de cmputo). De este
modo estas particiones o mquinas virtuales podran comunicarse por red, usar
sus propios recursos u otros en caso de que no estn siendo utilizados, podran
migrarse entre diferentes servidores, o tomar imgenes de su estado.
17

Imagen 2: Trabajador operando con una mquina IBM7044 en 1964

Ms tarde IBM desarroll versiones siguientes del IBM7044 declarando as su
intencin de evolucionar en la tecnologa de la virtualizacin. El Model 67
consegua virtualizar sus interfaces hardware gracias al VMM (Virtual Machine
Monitor), que ms tarde fue llamado hipervisor, ya que era capaz de alojar
sistemas operativos dentro de otros.
En estos comienzos de la virtualizacin, los sistemas operativos que corran en
las mquinas virtuales se llamaron CMS (Conversational Monitor Systems).
Los CMS fueron evolucionando y an en la actualidad corren en el mainframe
System z9.
Esto nos refleja algo importante en el proceso evolutivo de la virtualizacin: la
compatibilidad hacia atrs.
Otro uso de la virtualizacin en sus orgenes es la utilizacin del procesador
simulado (P-code), que se trata de un lenguaje a bajo nivel (mquina), que es
ejecutado en una mquina virtual. De este modo se consigue un alto grado de
portabilidad, ya que diferentes servidores con diferentes arquitecturas alojando
mquinas virtuales podan correr programas en P-Code.
Este mismo concepto lo siguieron otras mquinas virtuales que evolucionaron y
se encuentran actualmente como JVM (Java Virtual Machine).
El modelo de trabajo de varios terminales accediendo a un mainframe fue
desapareciendo gracias a la llegada de los PC (Personal Computer). Ahora la
prioridad era el rendimiento, y no la fiabilidad o la seguridad. Ya no era
necesario ese particionado de recursos, ya que los supercomputadores cayeron
en desuso y quedaron reducidos a lugares puntuales. Ya no era necesaria la
virtualizacin a este nivel y hubiera cado en el olvido de no ser por los centros
militares, universidades, bancos, algunos centros de investigacin, en los que la
fiabilidad era indispensable.
Esto nos llev poco a poco a sistemas con arquitectura de mainframe pero en
un hardware de miniordenador. Un ejemplo es el AS/400 de IBM comercializado
en 1988.

18

Imagen 3. Diferentes modelos de AS/400

Imagen 4. IBM System 9

Los ordenadores ganaron en potencia y eran ya capaces de ejecutar sistemas

multiusuario y multitarea, lo que provoc que se retomaran ciertas
funcionalidades del sistema Unix que fueron eliminadas por sus requerimientos
de potencia. Una de estas funcionalidades era la virtualizacin.
Surge la consolidacin de almacenamiento, volviendo de un disco duro por
persona a un disco duro para todos.
Actualmente la virtualizacin ha llegado al escritorio, con el consecuente
aumento de popularidad. Hoy es una de las tecnologas que ms se desarrollan
debido a sus mltiples ventajas y aplicaciones.
El rendimiento del hardware ya no es el problema y ahora se trata de mejorar lo
mximo posible la fiabilidad y seguridad.
Es tiempo de hacer un recorrido de las ventajas que ofrece esta tecnologa, y en
el presente proyecto las estudiaremos: migracin en caliente, planificacin,
entornos de laboratorio (prueba), aprovechamiento hardware, creacin de
mquinas y clonado, etc.

2.2

Terminologa

Una vez recorrida esta tecnologa en las ltimas cuatro dcadas, es fundamental
definir ciertos conceptos para llegar a comprender los modelos de virtualizacin
que nos encontramos en la actualidad.
Se introducen dos conceptos indispensables para la explicacin de esta tcnica:
mquina virtual e hipervisor.
Pese a que no todos los modelos de virtualizacin requieran mquina virtual, es
un trmino bsico para entender las tcnicas de vitualizacin.
El hipervisor, por ser elemento importante en las tcnicas de virtualizacin
completa y paravitualizacin, que son los modelos ms utilizados.
Una vez mencionado esto, podemos clasificar en cuatro modelos de
virtualizacin esenciales:
19

Virtualizacin de plataforma
Virtualizacin de recursos
Virtualizacin de aplicaciones
Virtualizacin de escritorio

Una vez conocida la esencia de estos modelos, estaremos en disposicin de

examinar ventajas e inconvenientes de cada uno de ellos.

2.2.1 Mquina virtual e hipervisor

Para profundizar en el funcionamiento de la virtualizacin es necesario explicar
estos dos conceptos clave, y comprender el papel que juega cada uno.
Dependiendo de las caractersticas de la mquina y de la funcin que
desempee, podemos clasificar en mquinas virtuales de sistema o hardware, o
de mquinas virtuales de aplicacin.

Imagen 5 : Arquitectura de virtualizacin en arquitectura x86

Mquina virtual de sistema:
Tienen acceso a la parte de recursos hardware que tiene asignada.
Realmente cree que esos recursos hardware estn a disposicin de ella,
cuando realmente estn asignados de manera virtual, ejecuta una instancia
de sistema operativo sobre el cual corren las aplicaciones.
Destacamos dos caractersticas para este tipo de mquinas virtuales, entre
su amplia funcionalidad: la consolidacin de servidores (que
implementaremos en este proyecto), en la que coexisten varios sistemas
operativos, y las pruebas o testeo de software y hardware, ya que se pueden
disponer de arquitecturas de instrucciones diferentes a las del host anfitrin.
El objetivo de este proyecto es la consolidacin de servidores, y este tipo de
mquinas virtuales son las que permiten realizar esta labor y sern nuestro
objeto de estudio.
20

Junto a ellas, el hipervisor tomar parte en la gestin de recursos,

distribuyndolos a cada mquina. El hipervisor es una capa software que
corre sobre la mquina anfitriona o sobre una de las virtuales, y da robustez
y estabilidad al sistema. Incluso si una mquina colapsa, el resto deben y
pueden seguir dando servicio. Esta capa tambin tiene el nombre de
monitor, ya que esa es otra de sus funciones: monitorizar las mquinas
virtuales.
Mquina virtual de proceso (o de aplicacin):
Se ejecuta en un sistema operativo como un proceso, y soporta un solo
proceso. En el momento de lanzar el proceso a ejecutar es cuando se inicia la
mquina y al finalizar ya no es necesaria y por lo tanto se detiene. Gracias a
este mtodo, se establece un entorno de ejecucin independiente de la
arquitectura y sistema operativo del host anfitrin que permite a un
programa ejecutarse independientemente de la plataforma en la que est
con la consecuente ganancia en compatibilidad.
Los casos ms conocidos son la JVM (Java Virtual Machine) y la mquina
virtual de .NET (Common Language Runtime).
Una vez introducidos los tipos de mquina virtual retomemos el concepto de
hipervisor.
IBM puso el nombre de supervisor al sistema operativo debido a que en
esencia, se trataba de un kernel que supervisaba al hardware. Debido a esto
se llam hipervisor a una nueva capa (algo as como otro kernel) que se
usaba en estas tecnologas de virtualizacin. Es por lo tanto un elemento
software que administra las mquinas virtuales. Tambin es conocido como
monitor VMM debido a su labor de monitorizacin.
Por lo tanto podemos, en esencia decir que el hipervisor tiene tres funciones:
1. Presentan a los sistemas virtualizados
2. Provee de hardware virtual a las mquinas virtuales
3. Monitorizan las mquinas virtuales
Existen bsicamente tres tipos de hipervisores:
Nativos: en este caso corre sobre el hardware anfitrin y gestiona el
acceso de las mquinas virtuales al hardware.
Este tipo es comn en modelos de virtualizacin completa y
paravirtualizacin (de los cuales hablaremos en el siguiente apartado)
La paravirtualizacin es el modelo con hipervisor ms popular ya que los
sistemas operativos de las mquinas virtuales se comunican
directamente con el hipervisor, sin elementos intermedios que
ralenticen, como ocurre en la virtualizacin completa.
21

Es el caso de VMWare ESX-Server, Citrix Xen y algn otro.

Alojado (hosted): aqu el hipervisor se ejecuta sobre un sistema operativo
y sobre ste se ejecutan las mquinas virtuales.
Aqu ponemos como ejemplo las mquinas virtuales Java y .Net
Hbrido: emulan un entorno sobre el que ejecutan un sistema operativo
invitado dentro del sistema operativo anfitrin. Interactan sobre el
hardware y con el sistema operativo anfitrin.

Imagen 6: Aquitectura con hipervisor nativo

2.3

Imagen 7: Arquitectura con

hipervisor alojado

Modelos de virtualizacin

El concepto de virtualizacin es demasiado genrico, y se usa

indiscriminadamente para abarcar diversas tecnologas que difieren entre s en
puntos importantes.
Muchas veces esta generalizacin puede hacer que el usuario final no distinga
entre las posibles soluciones que dan cada modelo.
Como primera aproximacin se puede definir la virtualizacin como la
abstraccin de recursos de un ordenador y la divisin de estos recursos en
varios entornos de ejecucin. Se proporciona acceso lgico a recursos fsicos.
Dependiendo de cmo sea ese recurso abstrado (recurso individual como
memoria, o plataforma completa como un servidor), y de quin lo use,
hablamos de diferentes modelos de virtualizacin.
Si hablamos de que por algn medio una mquina completa (hardware) sea
abstrada para que sea utilizado por varias instancias de sistemas operativos,
con sus aplicaciones, de tal manera que esas instancias crean que disponen en
exclusiva de esos recursos tenemos que hablar de virtualizacin de plataforma.
En definitiva, hay dos conceptos que determinan el tipo de modelo de
virtualizacin: por una parte el recurso abstrado, y por otra la aplicacin,
sistema, mquina, etc que dispone del recurso.
22

Aunque hay particularidades que los subdividen, podemos distinguir cuatro

principales modelos de virtualizacin:
Virtualizacin de plataforma: consiste en la simulacin de mquinas
virtuales. Se lleva a cabo en una mquina fsica abstrayendo
completamente el hardware de tal modo que puede ejecutarse
instancias distintas de sistema operativo con los recursos que les ha sido
asignado a cada mquina virtual. Es importante el detalle de que las
mquinas virtuales no son conscientes de la abstraccin. Es decir, cada
una piensa que esos recursos son exclusivamente suyos y no
compartidos.
Cabe destacar este modelo ya que ser el utilizado en la implementacin
prctica de este proyecto. Se trata de una aplicacin prctica muy
extendida: consolidacin de servidores.
Se puede interpretar como un sistema principal fsico particionado que
aloja diferentes mquinas virtuales dedicadas, con sus propios sistemas
operativos, aplicaciones y servicios a ofrecer. Todas estas mquinas
virtuales haran un inconsciente uso compartido del hardware
subyacente.
Analizaremos ms en detalle la consolidacin de servidores en los
captulos posteriores.
Dentro de la virtualizacin de plataforma, podemos distinguir varios
subtipos:
Sistemas operativos invitados:
Emulacin: un emulador es un software que permite la ejecucin
de programas en una plataforma con un hardware distinto del
aquel para el cual fueron escritos en su origen. Es por lo tanto una
rplica de una arquitectura al completo.
Destacamos MAME, MESS, VirtualPC y Qemu.
Virtualizacin completa: hay una diferenciacin de ejecucin entre
instrucciones no crticas (que se ejecutan directamente sobre el
hardware), e instrucciones crticas (intercepta el hipervisor y se
emulan en software).
Esto se debe a que la traduccin binaria (mtodo mediante el cual
las instrucciones son emuladas en software en vez de ejecutarse
sobre la mquina directamente) puede incurrir en una sobrecarga
en el rendimiento. Las instrucciones crticas pueden comprometer
la seguridad del sistema y pueden controlar el hardware, es por
esto por lo que emulndolas en software evitamos problemas de
seguridad. Sin embargo las instrucciones no crticas son
inofensivas para el hardware por lo que pueden ser ejecutadas
23

directamente sobre l, mejorando as el rendimiento. VMWare es

el ms claro ejemplo de este tipo de virtualizacin.
En este caso el hipervisor se encarga de monitorizar las mquinas
virtuales asimilando cada peticin que provenga de ellas y
ejecutndolas en la mquina real mejorando de esta manera el
rendimiento.
Por lo tanto, la virtualizacin completa combina traduccin binaria
con ejecucin directa, lo que hace que el rendimiento no sea ideal,
pero a cambio se consigue un aislamiento total de la mquina
virtual (sistema operativo invitado) que desconoce que es
virtualizado. Otros ejemplos de virtualizacin completa son:
XenServer, z/VM, Oracle VM, Sun xVM Server, Virtual Server,
VMware ESX Server, VMware Fusion, Xen, Hyper-V
Paravirtualizacin: es parecida a la virtualizacin completa. La
diferencia clave es que modifica los sistemas operativos invitados,
y por lo tanto son conscientes de la virtualizacin.
La principal ventaja de este sistema es la gran mejora de
rendimiento, ya que no hay traduccin binaria (no hay emulacin
de instrucciones crticas), son los propios sistemas operativos
invitados modificados los que colaboran evitando la captura de
instrucciones privilegiadas por parte del hipervisor.
En contraste con esta mejora de rendimiento (casi del 100%
respecto a una plataforma no virtualizada), la desventaja es la
necesidad de que los sistemas operativos invitados deben ser
modificables.
Las libreras y procesos ejecutados por mquinas virtuales tienen
que estar compiladas para el hardware anfitrin.
Existe la posibilidad de que haya un soporte hardware de
virtualizacin que mejore an ms el rendimiento, y tambin para
que pueda aplicarse sobre sistemas operativos no modificados,
gestionando las peticiones e instrucciones privilegiadas y
comunicndose con las mquinas virtuales.
Ejemplos de este tipo de virtualizacin son Xen, Logical Domains,
Oracle VM, y Sun xVM Server.
Virtualizacin a nivel de sistema operativo: en este caso el ncleo
del sistema operativo es el que crea varias instancias del sistema
operativo que son independientes y son vistas como un servidor.
No necesita de una capa intermedia de virtualizacin ya que es el
sistema operativo en exclusiva el que se encarga de ello.
El rendimiento alcanzado es bastante bueno con este sistema, ya
que se acerca al de un sistema sin virtualizar.
24

Como desventaja, al ser instancias de un mismo ncleo, no se

pueden instalar sistemas operativos diferentes, tan slo distintas
versiones de una misma distribucin.
Las libreras deben estar compiladas para el hardware anfitrin, y
el juego de instrucciones debe ser el mismo.
Debido al enfoque de este proyecto, citaremos como ejemplo
esencial Solaris Zones y Solaris Containers, ya que nos valdremos
de ello en la implementacin prctica.
Virtualizacin a nivel de kernel: se presenta en sistemas operativos
Linux, el cual habilita al kernel para que funcione como hipervisor,
permitiendo ejecutar mquinas virtuales e instancias de sistemas
operativos. No se trata de un kernel diferente, sino que es un
mdulo ms que permite esta funcin, de este modo, por ejemplo
se puede cargar y descargar en tiempo de ejecucin.
Las libreras, sistemas operativos y aplicaciones deben ser
compatibles con el hardware anfitrin. Destacamos KVM y Usermode Linux.
Virtualizacin de recursos: el recurso abstrado en este caso es un
recurso de un computador, por ejemplo una unidad de disco, o una
unidad de red. Distinguimos entre los siguientes tipos:
Memoria virtual: Uso muy extendido (Swap en Linux y paginado
en sistemas Microsoft) en el que el sistema cree que dispone de
ms memoria principal. El recurso abstrado es la memoria y el
disco.
Almacenamiento: La memoria de disco es el recurso que se
abstrae y es independiente del resto del hardware.
Como ejemplos tenemos SAN (Storage Area Network), NAS
(Network-Attached Storage), NFS (Network file systems)
Memoria: en este caso se usar memoria de diferentes
dispositivos conectados en red, unidos en una memoria virtual unificada.
Interfaces de red: consiste en la unin de varios enlaces de red
para conseguir un mayor ancho de banda. Son por lo tanto, lo
interfaces de red el recurso abstrado y como ejemplo podemos
nombrar: vNIC (Virtual Network Interfaces Card), vHBA (Virtual
Host Bus Adapter)
Virtualizacin de aplicaciones: Una vez desarrollada una aplicacin, y
despus de la compilacin, se obtiene el cdigo objeto (representacin
intermedia). En un entorno sin virtualizar, ese cdigo objeto se compila
25

para ser ejecutado en la mquina nativa. Sin embargo en un entorno con

virtualizacin de aplicacin el cdigo objeto se interpreta en una
mquina abstracta para poder ser ejecutado. Se consigue de este modo
que un mismo cdigo sea ejecutado en cualquier mquina
independientemente del hardware.
Podemos mencionar como ejemplos representativos Wine, capaz de
ejecutar aplicaciones de Microsoft Windows en entornos Linux. Tambin
JVM (Java Virtual Machine de Sun Microsystems), y CLR (Common
Language Runtime, para ejecucin en .NET de Microsoft).
Existen, a grandes rasgos dos tipos de virtualizacin de aplicaciones, una
en la que no existe capa intermedia de virtualizacin (Virtualizacin de
aplicaciones limitada: aplicaciones portables), y otro en el que s que
existe una capa de virtualizacin que media entre el sistema operativo y
hardware y la propia aplicacin virtualizada (virtualizacin de
aplicaciones completa).
Virtualizacin de escritorio: consiste en trminos generales en separar el
software que ejecuta el escritorio (lo que se ve en la pantalla) del equipo
fsico que es manipulado.
Es una ejecucin en remoto del escritorio (escritorio virtualizado), de un
sistema llamado servidor de escritorio, y por lo tanto necesita de una
conexin de red entre ambos.
Todos los programas, aplicaciones, procesos y datos se ejecutan en el
servidor de escritorio de manera centralizada. El escritorio del usuario es
encapsulado y entregado creando mquinas virtuales.
Como consecuencias, por un lado no sern necesarias complicadas y
pesadas herramientas distribuidas, y por otra parte es posible acceder a
los recursos desde cualquier sitio y desde diferentes tipos de dispositivos.
El recurso abstrado en este caso es el almacenamiento fsico del entorno
del escritorio del usuario. Algunos productos que trabajan con este tipo
de virtualizacin son por ejemplo VMWare View, Sun VDI, XenDesktop de
Citrix.

26

Modelo
Virtualizacin
de
plataforma

Submodelo

Recurso abstrado

Sistemas
operativos
invitados

Plataforma
hardware
completa

Emulacin

Plataforma
hardware
completa

Virtualizacin
completa

Plataforma
hardware
completa

Paravirtualizacin
a nivel de sistema
operativo
a nivel de kernel

Plataforma
hardware
completa
Plataforma
hardware
completa
Plataforma
hardware
completa

Ejemplos

VMware Workstation, Paralells

Desktop,
Sun xVM VirtualBox, Vmware
Player, Microsoft Virtual PC
Bochs, MAME, DOSBox, Hercules,
MESS,
VIrtualPC, Qemu
Vmware Server, XenServer, ORACLE
VM,
Sun xVM Server, Vmware ESX
Server,
VMware Server, Vmware Fusion
Xen, Logical Domains, ORACLE VM,
Sun xVM Server
Linux V-Server, Free BSDs chroot
jails, Solaris Zones, Solaris
Containers

KVM, User-mode Linux

Virtualizacin
de
recursos
Memoria virtual
Almacenamiento
Memoria
Interfaces de red
Virtualizacin
de
aplicaciones

Memoria y disco
Disco,
almacenamiento
Memoria RAM
Enlaces de red
Sistema operativo y
CPU

Espacio Swap, paginado de

memoria
RAID, SAN, NAS, NFS, iSCSI
Xsigo Systems, 2Leaf Systems
Java Virtual Machine,
Common Language Runtime, Perl,
Portable .NET, Citrix XenApp
27

Virtualizacin
de
escritorio

Localizacin fsica
del escritorio
que se encuentra
en un servidor
remoto

Wyse Technology,
Vmware View,
Sun VDI,
vDesk de Ring Cube

En la siguiente tabla se muestan los diferentes modelos y submodelos de

virtualizacin, as como los recursos abstrados en cada uno, y algunos ejemplos.

VIRTUALIZACIN: VENTAJAS Y DESVENTAJAS

Despus de hacer un recorrido histrico de la tecnologa de la virtualizacin,
desde los primero modelos que lo permitan, hemos visto cmo lleg un tiempo
en el que cay en el olvido, para resurgir de nuevo con ms fuerza gracias
tambin a una mayor accesibilidad al hardware, su llegada al escritorio y las
mltiples y tiles aplicaciones que tiene.
Ahora estudiemos por qu es tan importante esta tecnologa en el sector
empresarial y por qu se espera que siga aumentando su proyeccin.
Veamos algunos de los motivos que hace necesaria la implantacin de esta
tecnologa en los CPDs (Centor de Procesamiento de Datos).
Infrautilizacin de hardware:
En la actualidad, se puede hacer un clculo aproximado de la utilizacin real
de los recursos de una mquina de un 15%. Esto supone un desperdicio del
85% de la capacidad computacional, sin embargo el consumo elctrico y el
espacio fsico que ocupa es el mismo que si estuviera siendo utilizado al
mximo de sus posibilidades, lo que concluye en un desperdicio importante.
Gracias a la virtualizacin, es posible alojar en una mquina fsica con
hardware infrautilizado varias mquinas virtuales. Distribuyendo los recursos
hardware entre los diferentes sistemas se consigue un mayor
aprovechamiento de la inversin econmica de la empresa.
Espacio en CPDs:
Muchas compaas han ido incrementado su nmero de servidores porque
han sido planteados de forma aislada, en funcin de las necesidades segn
iban surgiendo.
Primero se compraba un servidor potente para ser usado como servidor de
correo. Despus, en base a, por ejemplo la necesidad de tener un servicio de
atencin al cliente, se compraba un nuevo servidor, el ms potente y se
creaba un servidor CRM, probablemente con otro fabricante y otro sistema
operativo.
28

De esta forma los CPDs crecen hasta el punto de ser muy difciles de
manejar.
Por otro lado, la evolucin del paso de almacenamiento fsico en papel a un
almacenamiento lgico, hace necesaria una forma de almacenar la
informacin, tal y como hemos matizado en apartados anteriores:
virtualizacin de almacenamiento.
As, gracias a la virtualizacin, alojamos varios servidores lgicos en uno
fsico, con un sistema de almacenamiento independiente que surten de
disco a las mquinas virtuales.
Gracias a esto se reduce el espacio ocupado en el CPD, y el consecuente
ahorro econmico.
Ahorro energtico:
Debido a esta reduccin de servidores, es de esperar que los costes por
consumo elctrico tambin se reduzcan, sin embargo, muchas veces a este
ahorro no se le da la importancia que realmente tiene, y en la decisin de
virtualizar no se tiene en cuenta este factor.
No slo eso, la virtualizacin ofrece algunas herramientas que permiten
aumentar este ahorro. Por ejemplo, DPM (Distributed Power Management)
es una herramienta que ofrece VMWare que monitoriza el uso de los
servidores.
Cuando detecta una baja carga de trabajo, migra diferentes mquinas
virtuales intentando que un servidor fsico quede sin ninguna activa. Una vez
logrado esto, apaga el servidor fsico con el consecuente ahorro elctrico
que supone. Si detecta un aumento de la carga, enciende automticamente
el servidor y vuelve a alojar mquinas virtuales en l.
Administracin de sistemas
Gracias a la virtualizacin, se puede disponer de una monitorizacin de
rendimiento de las mquinas, y de los servicios que corren en ella mucho
ms centralizada. Esto facilita en gran medida las tareas de administracin,
como puede ser el reemplazo de piezas defectuosas, instalacin o
actualizacin de sistemas operativos, aplicaciones, copias de seguridad,
redundancia, migracin
Tareas que antes eran muy tediosas debido al gran nmero de servidores
fsicos, ahora lo son menos ya que muchas de esas mquinas ahora son
virtuales, y por lo tanto, adems de haber menos, se pueden automatizar y
simplificar tareas.

29

 Alta disponibilidad:
Ms all del servicio que se ofrezca, un sistema tiene que ser fiable.
En los modelos de negocios actuales, no es admisible que un servicio, sobre
todo si es crtico, deje de funcionar ms de un determinado tiempo (lo ideal
es que funcione correctamente los 365 das del ao, las 24 horas del da).
Estos tiempos de prdida de servicio en casos de alta disponibilidad son
sumamente pequeos, por lo que requiere de ciertas medidas y planificacin
para no superarlos.
Una de estas medidas es la redundancia de servicios y/o servidores.
Mediante la virtualizacin, llevarlo a cabo es mucho ms sencillo y barato, ya
que se puede instanciar nuevas mquinas servicios duplicados que estn a la
espera de una posible falla para estar disponibles si eso ocurre, o tambin
para balancear la carga y no saturar servidores.
Obviamente, sin virtualizacin, los costes seran infinitamente mayores ya
que requerira de la adquisicin de nuevo hardware, etc.
Escalabilidad:
Cuando existe la necesidad de aadir un nuevo servidor a nuestro centro de
datos, es mucho ms sencillo aadirlo en un entorno virtualizado, ya que se
puede crear una mquina virtual en un servidor fsico existente que tenga
espacio para ella, y ms an, se pueden configurar plantillas de mquinas
virtuales para que cuando sea necesario aadirla tan slo se trate de una
copia de ficheros.
Compatibilidad hacia atrs:
La virtualizacin permite la utilizacin y el mantenimiento de sistemas
operativos y aplicaciones que no estn adaptados a los sistemas actuales.
Una empresa puede comprar un software hecho a medida que despus del
paso de los aos sigue siendo perfectamente vlido para la empresa pero no
es compatible con los sistemas actuales. La virtualizacin permite instanciar
una mquina virtual con el sistema operativo compatible con la aplicacin,
permitiendo la convivencia con un hardware y un sistema operativo
actualizado, con su correspondiente soporte.
En la implementacin prctica de este proyecto se pondr de manifiesto esta
bondad de la virtualizacin compatibilizando un software corriendo sobre
Solaris 9 (sin soporte), en una mquina con una versin superior de Solaris
(con soporte).

30

 Entorno de pruebas:
En las empresas actuales, resulta imprescindible probar las aplicaciones o los
cambios realizados, o la instauracin de nuevos servicios o incluso
servidores, antes de llevarlo a cabo. Por esta razn es muy til la
virtualizacin ya que permite realizar estos cambios y pruebas sin las
consecuencias que esto podra tener si fuera realizado en las mquinas que
dan servicio, para que despus, en caso de que sean satisfactorias pueda ser
integrado en entorno de produccin.
Seguridad y aislamiento:
Mediante la virtualizacin, conseguimos a muy bajo coste, proteger nuestros
sistemas ante posibles vulnerabilidades y/o ataques. Las instancias de las
mquinas virtuales son sistemas aislados en los que un ataque sobre una de
ellas afectar slo a ella.
Esto es gracias a que cada mquina virtual puede ejecutar instrucciones en
modo supervisor sobre ella misma, por lo tanto, se comporta ante los
ataques como mquinas independientes.
Esta ventaja es interesante tanto en el mundo empresarial como en
ordenadores personales.
Configuraciones estndar:
Uno de los problemas que surje con de los CPDs actuales es la dificultad de
previsin de su crecimiento, improvisando dependiendo de las necesidades
del momento y llegando a una heterogeneidad de hardware, sistemas
operativos, etc.
Gracias a la virtualizacin podemos estandarizar el escenario creando
configuraciones de mquinas anfitrionas e invitadas, reinventando nuestro
centro de datos en funcin de las necesidades.
Esto consigue un ahorro econmico y tambin en gestin administrativa, y
mejora la integracin de la infraestructura econmica del negocio, ya que
cambios en el modelo de negocio pueden ser reflejados en cambios de las
mquinas virtuales. Se consigue mucho ms dinamismo a muy bajo coste.
Calidad de servicio:
La posibilidad de crear un entorno de pruebas donde testear las nuevas
aplicaciones o sistemas aadidos, hace que se consiga una mayor fiabilidad y
calidad de servicio.
A esto le aadimos que en caso de una falla es posible haber creado una
imagen previa al cambio de la mquina virtual. Esto es posible porque una
mquina virtual no deja de ser un fichero y se puede volver
31

A esto se le aade que, cuando se va a instaurar un cambio o una nueva

aplicacin, se puede guardar una imagen previa al cambio. Esto es posible
porque una mquina virtual no deja de ser un fichero y en caso de que el
resultado del cambio no sea el esperado, se puede retornar al punto previo
sin mayores consecuencias.
Clonacin:
Ya sea por necesidad de redundancia de servicios o servidores, para
conseguir una alta disponibilidad, o por recuperacin ante fallas, tal y como
hemos anticipado antes, es muy til hacer un clon de una mquina
completa. Sin virtualizacin esto sera inadmisible debido a los costes y al
tiempo. Gracias a este trato de mquinas virtuales como ficheros, es muy
sencillo clonar o crear plantillas estndar para crear mquinas virtuales en
base a las necesidades, a coste casi cero, tan slo asignando nuevos
recursos.
Flexibilidad:
Utilizando virtualizacin tenemos total control sobre la distribucin de los
recursos de la mquina, podemos distribuirlos a nuestro antojo segn las
necesidades, asignando la memoria RAM, CPU, o espacio de disco que
necesitemos.
An ms, podemos asignar recursos exclusivos para las mquinas virtuales
que lo requieran, por ejemplo, una tarjeta de red exclusivamente para una
mquina virtual que soporte mucho trfico.
Y todo esto sin olvidarnos de la posibilidad de tener varias mquinas
virtuales con distintos sistemas operativos.
Portabilidad:
Como decamos, la configuracin de una mquina virtual consiste en uno o
ms ficheros.
De esta forma es muy sencillo migrar una mquina tan slo copiando esos
ficheros que encapsulan a la mquina virtual.
Incluso hay mecanismos que consiguen hacer esto en caliente de forma
transparente al usuario y al resto de procesos que estn corriendo.
Automatizacin:
Es posible monitorizar el funcionamiento de las mquinas virtuales en
tiempo real, y actuar en consecuencia. Si, por ejemplo, se detecta que hay
una mquina con excesivo porcentaje de uso de CPU, se puede automatizar
para que se le asigne dinmicamente ms CPU de alguna mquina que no
32

est siendo utilizada, o migrando a una mquina que disponga de mayor

CPU.
Una vez pasado este tiempo crtico de proceso, se puede reasignar volviendo
al estado original.
Uso en laboratorio:
Gracias a la facilidad de creacin de mquinas virtuales, se puede aplicar al
mbito docente, creando entornos de laboratorio donde poder instalar y
configurar sistemas operativos, aplicaciones, etc.
Estas son algunas de las ventajas de las que podemos beneficiarnos cuando
utilizamos virtualizacin. Por el contrario, no debemos olvidar las desventajas
que surgen de esta tecnologa. Pasamos a enumerar algunas de ellas:
Rendimiento inferior:
Un sistema operativo virtualizado, nunca podr tener el mismo rendimiento
que uno corriendo sobre la mquina fsica.
Al virtualizar, el hipervisor entra en juego como una capa intermedia que
interviene en la gestin de los recursos hardware y la concurrencia de tareas
y procesos.
Dependiendo del modelo de virtualizacin que utilicemos, habr mayor o
menor reduccin del rendimiento, pero en el mejor de los casos nunca ser
el 100% en comparacin con un sistema corriendo en una mquina sin
virtulizar.
Uso compartido del servidor:
Lo que a priori es una ventaja, puede verse como un inconveniente con una
mala gestin.
Hay que tener en cuenta la carga de trabajo en tiempo real mediante una
monitorizacin eficaz, para poder asignar recursos dinmicamente en base a
las necesidades de cada momento.
Mediante mecanismos en caliente como migracin, se puede automatizar
esta gestin para que se migren a servidores menos saturados mquinas
virtuales que estn sobrecargadas.
Esto hace que la labor de gestin en servidores virtualizados sea ms
compleja y ms decisiva. Ya que si esta gestin no es bien realizada pueden
darse situaciones de inconsistencia por saturacin de los recursos asignados
debido a la carga de trabajo.

33

 Compatibilidad hardware:
El hipervisor es la interfaz entre el hardware y las mquinas virtuales, por lo
tanto el hardware utilizado debe ser compatible con l.
El software de virtualizacin suele imponer condiciones sobre el hardware
utilizado. En caso de no satisfacerlas existen soluciones a base de emular el
hardware con la consecuente prdida de rendimiento.
Aceleracin de vdeo:
No es posible la aceleracin de vdeo por hardware en mquinas virtuales,
por lo que ejecucin de vdeo en 3D no sera posible.
Hay soluciones que lo permiten pero con prdida de rendimiento.
Organizacin de infraestructura:
Es necesaria una correcta planificacin de la infraestructura virtual ya que
por necesidades de negocio el nmero de mquinas va aumentando, y sin
una correcta organizacin, complicara as la administracin, la gestin de
licencias, y fallas en seguridad.
Nmero de mquinas virtuales:
El descontrol en la creacin de mquinas virtuales genera un consumo de
recursos que pueden ser ahorrados mediante, por ejemplo la optimizacin
de servicios en las mquinas virtuales ya existentes.
No es una solucin la creacin de mquinas para aumentar el porcentaje de
de las necesidades de uso real.
Servidor host como punto de fallo:
Una avera en el servidor anfitrin puede hacer que varias mquinas
virtuales se vean afectadas, e incluso provocar la prdida de servicio con el
consecuente impacto.
Hay soluciones que se pueden tomar para evitar o al menos reducir el riesgo
de este problema.
Mediante tcnica de redundancia de componentes hardware, replicacin de
servidores de los servicios ms importantes para que en caso de falla, un
nodo en espera se convierta en el nodo activo que tome la carga de trabajo.
Es importante una monitorizacin constante tanto del software como del
hardware para poder reaccionar a tiempo y reducir el impacto de la falla.
Tambin existen tcnicas de migracin en caliente portando en caso de falla
mquinas virtuales a servidores que no sufran daos.

34

 Portabilidad:
Depende del sistema operativo elegido y del software de virtualizacin la
portabilidad que tengamos ante diferentes arquitecturas.
Es importante prever las necesidades futuras para elegir correctamente el
software que nos permita una mayor flexibilidad ante necesidades de
portabilidad y migracin.
Venta de servidores:
Ante una solucin de virtualizacin, es necesario un menor nmero de
servidores, reduciendo as el nmero de ventas por parte de los
comerciantes.
Algunas empresas, aun sufriendo esta consecuencia, han apostado por
seguir dando soluciones de virtualizacin e invirtiendo en esta tecnologa.
Por el contrario, el hardware vendido ser ms potente.
Sistema operativo:
La estabilidad y seguridad de las mquinas virtuales dependen del sistema
operativo elegido, por lo que es vital analizar ventajas e inconvenientes
antes de tomar la decisin.
Solucin de virtualizacin:
Al igual que el sistema operativo, es de la mayor importancia saber elegir
una solucin de virtualizacin para las necesidades de la infraestructura.
Existen soluciones ms adecuadas para entornos de trabajo crticos, y otras
para no crticos.
Una arquitectura x86 tiene menos capacidad de direccionamiento que una
de 64 bits por ejemplo. VMWare se ejecuta sobre arquitectura x86, por lo
tanto, en caso de decidir una solucin para un entorno crtico, sera ms
conveniente en elegir una arquitectura de 64 bits (por ejemplo SPARC), y
una solucin adecuada a esa arquitectura (Solaris LDOMs).
Recursos finitos:
En un entorno virtualizado, varias mquinas virtuales utilizan recursos del
servidor anfitrin. En ocasiones la carga de trabajo ser tal, que dos o ms
mquinas necesiten disponer de ms memoria, o de un mayor uso de CPU,
por lo que es importante prever esto para que nunca falten.
Un estudio de la carga de trabajo para asegurar recursos en el peor de los
casos para varias mquinas a la vez puede evitar graves daos.
Herramientas de monitorizacin para examinar a tiempo real esa carga
permitira una asignacin dinmica de recursos e incluso migraciones en
caliente a otros servidores que estn con mayor nmero de recursos libres.
35

 Uso de la red:
Es posible que ante un pico de utilizacin de red, un servidor tenga saturadas
las interfaces de red que comunican a las mquinas virtuales. Esto puede
derivar en una congestin y prdida de rendimiento.
Se pueden instalar ms tarjetas para solventar este problema, o dar uso
exclusivo a alguna de ellas a la mquina que ms trfico de red soporte.
Hay que tener en cuenta que ante una migracin dinmica esta exclusividad
de recursos puede suponer un problema.
Complejidad de las actividades relacionadas con la red:
Varias mquinas virtuales, cada una con diversas interfaces de red y sus
configuraciones, pueden derivar en una complejidad de administracin
mayor que la que habra en un entorno no virtualizado. La configuracin de
elementos de red, como firewalls, y la capa software de red virtual que
interviene en las mquinas virtuales.
Una solucin o mtodo para suavizar esta desventaja puede ser la creacin
de subredes virtuales con un servidor DHCP para as facilitar las tareas de
encaminamiento de red.
Problemas aadidos:
En la administracin de un entorno virtualizado surgen problemas que no
haba antes. Por ejemplo, habr que ser realmente eficaz en la
monitorizacin para labores de distribucin de carga. Es necesario controlar
en qu servidores se encuentran corriendo las mquinas virtuales ya que
esto vara constantemente por tcnicas de migracin, tareas que no eran
necesarias en un entorno no virtualizado.
Licencias:
Hay que tener en cuenta que mltiples cuentas de usuario en un servidor, la
replicacin de mquinas virtuales, imponen requisitos de licencia con el
coste que ello implica.
Incluso hay vendedores de software que no venden licencias para entornos
virtualizados por lo que hay que comprobar antes de decantarse por uno de
ellos.

36

Veamos ahora un resumen en un cuadro de las ventajas e inconvenientes de

implementar infraestructuras virtualizadas.
Ventajas
Consolidacin de servidores
Administracin de Sistemas simplificada
Alta disponibilidad y recuperacin ante
desastres
Alto rendimiento y redundancia
Reduccin de costes

Desventajas
Prdida de rendimiento
Comparticin del servidor
Soporte del hardware

Hardware virtual obsoleto

Aceleracin de vdeo por hardware
Riesgo de la organizacin al implantar
Mejora de las polticas de puesta en marcha,
plataforma
copias de seguridad y de recuperacin
virtualizada
Optimizacin del uso y control de los recursos Nmero inadecuado de mquinas virtuales
Gran escalabilidad
Anfitrin como nico punto de fallo
Aprovisionamiento de mquinas virtuales
Portabilidad condicionada
Compatibilidad hacia atrs
Disminucin de ventas de hardware
Dependencia del sistema operativo
Disminucin del nmero de servidores fsicos
anfitrin
Dependencia de la solucin de
Mejora de la eficiencia energtica
virtualizacin
Seguridad y aislamiento
Disponibilidad insuficiente de recursos
Mejora de la calidad y fiabilidad
Congestin de red por servidor
Posible aumento de la complejidad de la
Clonacin de mquinas virtuales
adminitracin
Flexibilidad
Licencias software

37

38

SOLARIS SPARC

3.1

Historia de Solaris

En febrero de 1982, en Silicon Valley, Andy Bechtolshel, Vinod Khosla, Bill Joy y
Scott MacNealy fundan la empresa Sun Microsystems.
En su primer ao de vida, Sun lanza la Sun-1, una mquina con un procesador
Motorola a una velocidad de 6 MHz, 1MB de memoria RAM y 60MB de disco
duro. Esta mquina corra el sistema operativo SunOS 1 basado en BSD 4.1 con
el aadido de incorporar TCP/IP.
Pero Qu es BSD?
Empleados de los laboratorios Bell de AT&T, crearon las primeras versiones de
UNIX. AT&T autoriz a la Universidad de California en Berkeley a retocar el
cdigo y adaptarlo a sus necesidades. De este modo nace BSD (Berkeley
Software Distribution).
En 1984 Sun cre el sistema NFS (sistema de archivos de red), que consigue ver
como espacio de disco local, sistemas de archivos ubicados remotamente.
Esta tecnologa NFS se estandariz siendo incluida a partir de la siguiente
versin de SunOS 2 en 1985.
En 1986 es lanzada la versin SunOS 3, incluyendo System V (potente y eficaz
sistema de inicio que controla los programas que se inician al arrancar la
mquina). Este mismo ao se lanza la Sun-3, con un procesador Motorola a
25MHz y 32 MB de memoria RAM.
Un ao despus, con la Sun-4, se introduce la novedad de soporta arquitectura
SPARC V7 RISC.
En 1989 sale la versin SunOS, primera en ser compatible con arquitectura
SPARC, basada en BSD 4.3 pero incluyendo utilidades System V.
Sun lanza la versin SunOS 4.1.1, la llamada Solaris 1, y concluye as un ciclo.
Todas las versiones lanzadas hasta ahora (desde 1982 a 1990) se incluyen en ese
nombre de Solaris 1.
En junio de 1991 nace SunOS 5.0 con el nombre de Solaris 2, con varias
novedades:
Abandona el nombre antiguo por Solaris 2
Basada en System V
Con CDE (Common Desktop Environment), como escritorio
aunque no abandona OpenWindows
Soporte de Multiprocesamiento Simtrico (SMP) que permite
el uso de barias CPUs.
A partir de entonces se produce una rpida evolucin en las versiones de Solaris
hasta la disponible ahora Solaris 11.
En el siguiente cuadro aparecen las versiones con las principales novedades
incluidas en cada lanzamiento:
39

Versin de Solaris
Solaris 1.0 (SunOS 4.1.1)
Solaris 1.0 (SunOS 4.1.1)
Solaris 2.4 (SunOS 5.4)
Solaris 2.6(SunOS 5.6)
Solaris 7(SunOS 5.7)
Solaris 8 beta
Solaris 9 SPARC
Solaris 10

Ao
1990
1993
1994
1998
1998
1999
2002
2004

Solaris 10

2006

Solaris 11

2011

Tecnologas
NFS V3 Y CDE
x86 platform
Kerberos, PAM, TrueType 64 bits para plataforma
UltraSPARC
IPv6 support
Solaris Volume Manager
Java Desktop
Java Desktop , Solaris Containers ,
Service Management Facility (SMF)
NFSv4 /ZFS

En junio de 2005 nace OpenSolaris, un proyecto en el que Sun liber gran parte
del cdigo fuente pasando a ser desde entonces de libre distribucin.
Nuevas mejoras fueron aadidas en otras distribuciones a partir de esta
iniciativa.
En OpenSolaris.org se puede encontrar diferentes proyectos y mejoras, as
como grupos de trabajo que aportan sus ideas y funcionalidades a la
comunidad.

3.2

Hardware SUN

El crecimiento exponencial de la red, ha revolucionado la naturaleza de la

computacin.
Las redes actuales, en su mayor parte se ven sometidas a un flujo de
informacin alfanumrica, teniendo menos importancia el trfico dedicado a la
imagen, la geometra, audio, vdeo, etc
La tendencia futura es a invertir esta proporcin y las mquinas futuras debern
tener capacidad para tratar este tipo de datos con un buen rendimiento.
En 1987, Sun Microsystems anunci una arquitectura RISC (Reduced Instruction
Set Computing) abierta denominada SPARC, base de los productos venideros de
esta empresa.
SPARC sigue siendo el procesador estandarte de ORACLE (Sun Microsystems fue
comprada por ORACLE en 2010, en el proyecto hablaremos indistintamente de
Sun y de ORACLE). Gracias a la tenacidad en mejora de tecnologa y
refinamiento continuo demuestra su compromiso con este tipo de arquitectura.

40

En este proyecto, en la fase de implementacin prctica, utilizaremos una

SunFire T2000, correspondiente a la generacin de procesadores UltraSPARC T1.
Se trata de un procesador lanzado en el ao 2005, y dista en potencia de los
procesadores actuales. Por esta razn pasaremos de estudiar arquitectura
SPARC y UltraSPARC, detenindonos en los procesadores UltraSPARC,
UltraSPARC II y UltraSPARC IIi.
ORACLE (antes Sun), se centra en los grandes servidores y estaciones de trabajo,
mercado que poco a poco se ha ido acercando al de las mquinas de escritorio,
gracias a que estas ltimas han evolucionado considerablemente. Pero
podemos destacar que una particularidad es el uso del sistema operativo UNIX.
La estrategia de desarrollo se divide en tres campos:
1. Diseo de procesadores
2. Tecnologa de procesos
3. Arquitectura de instrucciones
En cada desarrollo, slo una de estas reas es atendida. En UltraSPARC I, III, V
(generaciones impares), se desarrollaron arquitecturas de pipeline, sin
embargo, en UltraSPARC II, IV (generaciones pares), las innovaciones vinieron
en el campo de tecnologa de procesos.
Gracias a este mtodo se consigue una total compatibilidad de binarios, y de
este modo, los consumidores no se ven forzados a grandes inversiones en
cambios de sistemas operativos y aplicaciones.
En base a lnea de trabajo, se desarrollaron tres series:
o Serie S: Orientadas a servidores y Workstation (estaciones de tabajo)
Son las UltraSPARC I, II, y II
o Serie I: Solucin de bajo coste, multifuncionalidad en el procesador
UltraSPARC IIi
o Serie E: Soluciones ntegras
microSPARC, ultraSPARC

3.3

Arquitectura SPARC

Destacamos las siguientes caractersticas:

Economa y rendimiento: los procesadores SPARC son capaces de un
gran nmero de ejecucin de instrucciones con un bajo nmero de transistores.
SPARC tiene por tanto, un diseo muy simplificado, con un juego de
instrucciones muy simple tambin, que logra en su conjunto un gran
rendimiento con un bajo coste.
41

Escalabilidad: SPARC es escalable dentro de mucha variedad de

tecnologas, en sus implementaciones de chip y configuracin de sistemas.
Dispone de una cach muy flexible a la hora de integrarse, tambin en el modo
de manejo de memoria, y coma flotante. Gracias a todo esto, existen
procesadores desde servidores a ordenadores porttiles con una relacin
calidad precio muy interesante.
Arquitectura abierta: Sun Microsystems, Inc. Fue pionero en este
concepto en los aos 80. Sun apuesta por el uso de tecnologas estndar, para el
desarrollo de tecnologas ms avanzadas manteniendo bajos costes. Por otra
parte, SPARC es compatible con productos de muchos vendedores, lo que
supone un atractivo aadido.
Herramientas de desarrollo: El sistema operativo Solaris, ha demostrado
su seguridad y fiabilidad desde hace muchos aos corriendo aplicaciones en
entornos crticos, mltiples aplicaciones, transacciones y negocios.
Existen completos juegos de herramientas de desarrollo software en SPARC.

3.3.1 Arquitectura SPARC V-9

La versin 9 de SPARC (SPARC-V9), ha sido un gran salto tecnolgico desde que
naciera en el ao 1987.
Destacan las siguientes mejoras:
o Direccionamiento de 64 bits y uso de 64 bits par datos enteros
o Mejor rendimiento del sistema
o Soporte para optimizacin de compiladores y alto rendimiento con
sistemas operativos
o Implementacin superescalar (paralelismo)
o Mejora en tolerancia a fallos
o Rpido manejo de trabas y cambiante contexto
o Uso de Big y Little Endian

3.3.2 Procesador UltraSPARC-I

Este procesador mantuvo la compatibilidad de su antecesor, el SPARC-V8, que
utilizaba 32 bits. De este modo poda ejecutar sin conflictos aplicaciones que
existan.
UltraSparc-I dispone de un direccionamiento de 64 bits, y tambin 64 bits para
datos, pero tambin tiene otros aadidos:
o Hasta 4 instrucciones por ciclo de reloj con 9 fases de pipeline
o Mejora del rendimiento de la cach y en la latencia de memoria
42

o Permite hasta 4MB de cach externo, 16K de datos y 16K de

instrucciones
o Soporta multi-procesador con baja latencia a los datos compartidos
o Soporte para grfico e imgenes en el chip
o 4 capas de metal a 3.3 voltios con tecnologa CMOS
o Empaquetado con plstico de 531 pins
o Tasas de transferencia de memoria altas (1.3GB/s.)
o Interconexin con el nuevo Ultra Port Architecture (UPA)

3.3.3 Estrategia SPARC

Sun Microsystems en los aos 80, transfiri la arquitectura SPARC a SPARC
international con el objetico de continuar con su desarrollo fomentando los
sistemas abiertos.
Es, por lo tanto una especificacin abierta, en la que el propio diseador no
tiene control total.
SPARC impone normas sobre su diseo y sobre la compatibilidad de software .
SPARC Compilance Definition nace para garantizar esta compatibilidad,
normalizando as las interfaces de hardware y especificando directrices para el
software de sistema.
La razn por la apuesta de Sun hacia una tecnologa abierta, es la rivalidad y
competitividad por el desarrollo e innovacin de los diferentes vendedores.
Aproximadamente media docena de distribuidores de SPARC consiguieron
licencia para fabricar con diferentes tecnologas (CMOS, ECL, GaAs,VLSI, etc.). El
fin fue mejorar en el desempeo, reducir costes y por lo tanto precios, e
intentar hacer de la arquitectura SPARC, un estndar del mercado.
SPARC destaca por su capacidad de multiprocesamiento, dispone de un bus con
gran ancho de banda, y su diseo permite que las aplicaciones corran
considerando una buena relacin precio-rendimiento. Lo sistemas son
diseados para un rendimiento alto en clculo de datos en coma flotante y
soporta simple y doble precisin, as como extendida en los datos y en las
operaciones.
Los sistemas SPARC consiguen altas velocidades de procesamiento gracias a sus
tcnicas de fabricacin de chips.
Con respecto al diseo del procesador, SPARC tena originalmente un
direccionamiento de 32 bits, que a partir del SPARC-V9 fueron 64 bits,
dedicados a programas de aplicacin. Tambin dispone de un bus de datos
flexible para la optimizacin de la arquitectura.

43

Imagen 8: Diagrama de bloques arquitectura SPARC

SPARC tiene definidas instrucciones, registros y datos enteros. Tiene un registro

de instrucciones sencillo, normalmente no sobre pasan un ciclo de reloj.
Los enteros y coma flotante, admiten ejecucin secuencial. Esto es gracias al
apoyo de una arquitectura para programas secuenciales.
Los enteros usan ventana de registro.
Estos registros son definidos por SPARC pero los fabricantes tienen total libertad
para elegir el nmero que consideren de ventanas de registros para satisfacer
las necesidades de acuerdo a una buena relacin precio-rendimiento.
En SPARC-V8 dispone de 32 bits de registros:
32 para single, 16 para doubl o 8 para quad.
SPARC-V9 tiene doble nmero de registros y aade carga (load) para nmeros
en coma flotante y almacenamiento (store) para operaciones con quad.
Los programas que corren en arquitectura SPARC, aumentan ligeramente el
nmero de instrucciones que ejecutan de las que se ejecutan en un sistema
CISC, pero a cambio necesita muchas menos referencias a memoria.
Caractersticas de la cach:
La memoria cach mejora el rendimiento facilitando un acceso ms rpido a los
datos, ya que sin un dato est en cach requiere de muchos menos ciclos de
reloj para ser accedido.
SPARC unifica las instrucciones de cach y datos mediante la Harvard cache
organization, que utiliza una instruccin independiente (I-cache) y cache de
datos (D-cache). En un solo ciclo de reloj un dato solicitado puede ser estar
disponible en buses de datos independientes a la vez. Es decir, el procesador
puede, en un ciclo de reloj, acceder al I-cache y al D-cache a la vez.
Acceso a memoria:
El acceso a memoria principal de un procesador SPARC es a travs de cach
virtual.
El sistema operativo Solaris utiliza la capacidad de la memoria virtual de SPARC
consiguiendo un mayor espacio de direccionamiento.
44

3.3.4 Arquitectura UltraSPARC

Para conseguir un alto rendimiento, se necesita una mejora de tres factores:
Nmero de instrucciones copiladas y generadas en un trazo de ejecucin (NI),
proporcin de instrucciones por ciclo (IPC), y la tasa de reloj.
Un sistema rentable debe mejorar estos tres puntos y no slo centrarse en las
tasas de reloj, y para ello se usan tecnologas de semiconductores principales.
Los sistemas UltraSPARC consiguen este objetivo dando un buen rendimiento
con tasas de reloj razonables y mejorando el IPC.
En resumen, el objetivo de la arquitectura es un buen manejo del pipeline del
procesador con unos tiempos de acceso a memoria. Reducir el tiempo de
acceso a memoria, junto con un aumento del nmero de instrucciones por ciclo,
desemboca en un mejor rendimiento, sin complicar demasiado el diseo del
procesador.
Con UltraSPARC-I, Sun Microsystems intent mejorar el rendimiento sin
aumentar los costes y por lo tanto, el precio final del producto. Consigue un
equilibrio considerando el procesador global y el coste, mientras se consigue un
buen rendimiento de operaciones en coma flotante y tamaos de cach.

45

Pasamos a hacer un repaso histrico de las implementaciones de los diferentes

procesadores de arquitectura SPARC, hasta llegar al lanzamiento del UltraSPARC
T1, que es el que se incorpor en la SunFire T2000, y que es la mquina que
utilizaremos en la implementacin prctica.

46

Imagen 9: Mapa histrico de lanzamiento de procesadores SPARC hasta 2005

47

48

3.4

SUNFIRE T2000

En noviembre de 2005, Sun Microsystems lanza al mercado el nuevo UltraSparc

T1 processor, bajo el nombre de Nigara. Se trata de un procesador de ocho
cores (hay versin de cuatro y seis cores) paralelos capaces de ejecutar 4
procesos casi simultneamente (multi-hilo). Cada core dispone de un pipeline
de enteros que es compartido por los cuatro hilos del core, para ocultar la
latencia de memoria.
Dispone slo de una unidad de nmero en coma flotante para todos los cores,
por lo que es un procesador diseado para programas que utilizan pocas o
ninguna operacin en coma flotante, como por ejemplo servidores web
(webservers) o bases de datos.
UltraSPARC T1 es compatible con UltraSPARC IV .
Cada uno de esos ocho cores del procesador, dispone de su propio nivel de
instrucciones y datos cach.
Esta mquina es un servidor de alto rendimiento con una alta escalabilidad y
extremadamente confiable. Todos los cores tienen acceso a un nivel 2 de cach
comn de 3 MB y a la memoria principal comn.
Un servidor Sun Fire T2000 con un procesador UltraSPARC T1 Niagara fue
instalado en RWTG Aachen Universities Center for Computing and
Comunication. Este sisema dispona de una memoria principal de 8Gbyte y
corra Solaris 10.

Imagen 10: Servidor SunFire T2000

49

Despus de la actualizacin de los grandes servidores Sun Fire con dual core
UltraSPARC IV del ao 2004, los sistemas Sun Fire T2000 fueron un importante
avance hacia el uso de los nuevos tipos de microprocesadores con tecnologas
multi-proceso y multi-hilo, las cuales dominaran el mercado de los sistemas en
el futuro.
Los procesadores UltraSPARC T1 mejora el caudal (thoughput) usando menos
energa y disipando menos calor que los diseos de procesadores
convencionales.
Dependiendo del modelo adquirido, el procesador tiene cuatro, seis u ocho
UltraSPARC cores.
Como hemos comentado antes, el procesador dispone de una L1 cache y L2
cache, controladores de memoria DDR2, y una interfaz JBus I/O (entrada/salida)
cuidadosamente optimizado para un magnfico rendimiento.
A continuacin se pueden observar las caractersticas del T2000 con sus
opciones de configuracin de adquisicin:

50

3.4.1 Gestin remota con ALOM CMT

La caracterstica Sun Advanced Lights Out Manager (ALOM) CMT es la
controladora del sistema (system controller o SC) que permite gestionar y
administar remotamente el servidor.
Esta caracterstica viene por defecto instalada en el firmware y se inicializa al
alimentar energticamente el sistema.
ALOM CMT permite monitorizar y controlar el servidor a travs de la red, o bien
utilizando un puerto serie para conectar al terminal o terminal server. Presenta
una interfaz de comandos para administrar remotamente el servidor cuando la
presencia fsica no es posible. ALOM CMT permite ejecutar remotamente
herramientas de diagnosis (como POST), que de otro modo requeriran
presencia fsica para conectar por puerto serie.
Permite configurar tambin para enviar alertas sobre eventos de fallo hardware,
y otros eventos relacionados con el servidor.
La circuitera de ALOM CMT es independiente del servidor, por lo que puede
utilizarse incluso cuando el servidor pierde conexin por red, o est
completamente apagado.

51

Aqu se observa el listado de componentes que puede monitorizar la ALOM

CMT:

3.4.2

Temperatura de CPU
Estado de disco duro
Condiciones trmicas del entorno
Velocidad del ventilador y estado
Estado de las fuentes de alimentacin
Fallas detectadas por POST
Solaris Predictive Self-Healing (PSF)

Fiabilidad, disponibilidad, y capacidad de servicio

Estas tres caractersticas son aspectos de un sistema que permite operar

continuamente y minimizar el tiempo necesario para servir al sistema.
La fiabilidad se refiere a la capacidad de operar continuamente sin fallos y
manteniendo la integridad de los datos.
La disponibilidad del sistma se refiere a la capacidad de recuperarse a un estado
operacional despus de un fallo, con un impacto mnimo. Y nos referimos a la
capacidad de servicio como el tiempo que le lleva al sistema de restaurar el
servicio despus de un fallo. Estas caractersticas juntas ofrecen un sistema de
continua operacin.
Para conseguir altos niveles de estas tres caractersticas, el Sun Fire T2000
ofrece los siguientes aadidos:
Conexin en caliente de discos duros
Redundancia de fuentes de alimentacin (dos) y posibilidad de cambio en
caliente
Redundancia de ventiladores (tres) y posibilidad de cambio en caliente
Monitorizacin de entorno
Deteccin y correccin de errores para una mejor integridad de datos
Fcil acceso a la mayora de reemplazo de componentes
Chequeos POST que borran componentes en fallo de la configuracin
PSH diagnosis que pone offline los componentes en fallo

52

Imagen 11: SunFire T2000 vista delantera y trasera

Los dispositivos que se suelen conectar al puerto serie de gestin suelen ser:
Servidor de terminales
Terminal alfanumrico o similar
Lnea Tip conectada a otro dispositivo Sun.
El puerto serie de gestin de SC se usa para administracin in situ por consola
(system controller)
El servidor dispone de redundancia de fuente de alimentacin para mayor
seguridad de suministro elctrico.

53

54

VIRTUALIZACIN EN SOLARIS

Tal y como se ha comentado anteriormente, las empresas, en busca de

incrementar sus niveles de eficiencia y reducir costes, lanzan iniciativas de
consolidacin de servidores. Aunque la consolidacin ofrece a las empresas la
oportunidad de una mejor utilizacin de recursos, el despliegue de varias
aplicaciones en un nico servidor deriva en un rendimiento inferior y muchas
veces en fallos de aplicacin. Adems, una sola aplicacin con un mal
comportamiento puede afectar a otros recursos o servicios software.
Los mtodos simples de consolidacin no proporcionan los lmites de seguridad
requeridos por las aplicaciones que acceden a informacin sensible.
Afortunadamente, las tecnologas de virtualizacin de mejorar las estrategias de
consolidacin, al permitir a las organizaciones crear lmites administrativos y de
recursos entre las aplicaciones dentro de un sistema. La capacidad de aislar los
programas de software que se ejecutan en un servidor consolidado ayuda a las
organizaciones de TI entregar el rendimiento de las aplicaciones y los requisitos
de seguridad, as como las necesidades de ajuste se encuentran personalizados.
Mediante la combinacin de cargas de trabajo y el uso de tcnicas de
virtualizacin, las empresas pueden maximizar el uso de plataformas de
cmputo, simplificar su infraestructura de TI, y traer nuevos niveles de
eficiencia, manejabilidad y agilidad.
Una serie de tecnologas permiten la virtualizacin de plataforma,
proporcionando a cada diversos grados de flexibilidad, disponibilidad y
seguridad. En algunos casos, las organizaciones se benefician mediante el uso
de varias herramientas en un solo servidor. Mediante la entrega de productos y
tecnologas avanzadas, y aprovechando su experiencia global en el suministro
de sistemas y software, Oracle ofrece una cartera completa de soluciones de
virtualizacin. Enfoque integral de Oracle aborda todas las categoras de
virtualizacin, incluyendo la gestin de recursos, la particin de dominios fsicos
(hard partitioning), virtualizacin a nivel de sistema operativo (OS), y la
tecnologa de mquina virtual (VM) (ver figura).
ORACLE, por lo tanto, ofrece diferentes soluciones de virtualizacin de
plataforma, tal y como vimos en el captulo terico de virtualizacin. En
concreto ofrece tres formas de virtualizacin de plataforma:
Dominios fsicos (Dynamic System Domains)
ORACLE VM para SPARC (anteriormente llamado Logical Domains o
LDOMs)
Zonas (Solaris Containers o Solaris Zones)

55

Imagen 12: Esquema de soluciones de virtualizacin ofrecidas por ORACLE

4.1

Dominios fsicos (Dynamic System Domains)

Oracle incluye esta solucin de virtualizacin en sus mquinas de gama alta. Se

trata de una particin elctrica del servidor. Es conocida como Dominios, y su
nombre real es Dynamic System Domains.
Un dominio es un recurso independiente del sistema que ejecuta su propia
copia del sistema operativo Oracle Solaris. Los dominios dividen los recursos
totales de un sistema en unidades separadas que estn afectados por las
operaciones de cada uno. Los dominios pueden ser utilizados para diferentes
tipos de procesamiento; Por ejemplo, un dominio puede ser utilizado para
probar nuevas aplicaciones, mientras que otro puede ser utilizado para fines de
produccin.
Cada servidor se compone de una o varias Physical System Board (PSB).
Una PSB consiste en 4 CPUs, 32 DIMMs y una interfaz de I/O (entrada-salida). La
I/O vara dependiendo del servidor, y puede incluir ranuras PCIe, PCI-X y built-in
I/O.
Una PSB puede estar dividida lgicamente dividida en una unidad (no dividida),
o lgicamente dividida en cuatro unidades. En el primer caso se le llama UniXSB, y en caso de estar dividida se le llama Quad-XSB.
A cada una de las divisiones lgicas se le llama Extended System Board (XSB).

56

Por lo tanto:
Uni-XSB
Una PSB no dividida lgicamente y configurada en una XSB
Contiene todos los recursos de la placa: en media 4 CPUs,
32 DIMMs e interfaz de E/S en un servidor de gama alta; 1
CPU, 8 DIMMs e interfaza de E/S en un servidor de nivel de
entrada.
Quad-XSB
Una PSB dividida lgicamente y configurada en cuatro XSBs
Cada una de las cuatro XSBs contiene un cuarto de los
recursos totales de la mquina: 1 CPU, 8 DIMMS, e interfaz
de E/S en un servidor de gama alta; En un servidor de gama
media slo dos XSBs tienen interfaz E/S.
Un dominio consiste en una o ms XSBs. Cada dominio dispone de su propia
copia de sistema operativo Solaris, y cada dominio debe tener como mnimo 1
CPU, 8 DIMMS, e interfaz de E/S.
Cada XSB est aislada elctricamente, por lo que supone una separacin
completa de mquinas. En definitiva, disponemos de un chasis con varias
mquinas totalmente independientes, y por lo tanto podemos tener diferente
kernel, parches, etc.

Aqu podemos observar una PSB

en modo Uni-XSB en un servidor
de gama baja (entry-level).

57

En este caso tenemos un

servidor de gama media con una
PSB formada por 4 CPU y 32
DIMMs

Observamos aqu un servidor de

gama alta, con 1 PSB en Uni-XSB
Con 4 CPUs, 32 DIMMs y 4
interfaz de E/S.

Aqu tenemos un servidor de

gama
media con una
configuracin en Quad-XSB, y
con dos dominios (XSB00-0 y
XSB00-1).
Debido a la necesidad de un
dispositivo de E/S en cada
dominio, no puede haber ms.
Los XSB restantes (XSB00-2,
XSB00-3)
pueden ser asignados a los
dominios existentes o a
ninguno.

58

Por ltimo, tenemos un servidor

de gama alta, configurado en
modo Quad-XSB, con cuatro
dominios, cada uno con 1 CPU, 8
DIMMs, e interfaz de E/S.
A continuacin, se muestran los
diferentes modelos de gama
media y alta comercializados por
SUN y con las caractersticas
bsicas de virtualizacin en
dominios fsicos.

Modelos de alta gama con PSB admitidos y nmero de dominios

Un dominio tiene dos modos de funcionamiento de CPU:

SPARC64 VI Compatible Mode (disponible para servidores de gama media
y gama alta):
En este modo todos los procesadores del dominio se comportan y
son tratados por el sistema operativo como procesadores
SPARC64 VI. Las caractersticas extendidas de SPARC64 VII y
SPARC64 VII+ no estn disponibles para este modo (dominios 1 y 2
de la figura siguiente).

59

 SPARC64 Enhanced Mode (disponible para servidores de gama baja,

media y alta):
Todas las placas del dominio tienen que contener solamente
procesadores SPARC64 VII+ o SPARC64 VII. En este modo, el
servidor utiliza las caractersticas extendidas de estos
procesadores (dominio 0 de la figura siguiente).

Imagen 13: Modelos de procesador SPARC64 VI y VII

Con respecto a la comunicacin de los dominios, hablaremos de:

Comunicacin interna entre el dominio y el Procesador de Servicio a
travs de red DSCP:
La red DSCP establece un enlace, usando direccin IP, entre el
Procesador de Servicio y los dominios. Este enlace establece
comunicacin entre ambos, y una trasmisin segura de
informacin.
Cada dominio tiene que tener asignada su propia direccin IP y el
Procesador de Servicio tiene que disponer de la suya.
DSCP est optimizado para un intercambio seguro de datos de
control como reporte de errores, eventos de fallo, y
sincronizacin.

Acceso al dominio desde el Procesador de Servicio:

Para acceder a un dominio, se puede primero hacer login al
Procesador de Servicio, y despus utilizar el comando console
para acceder a un dominio en particular.
Una vez ienes acceso a la consola del dominio, se dispone la
consola estndar de Solaris, con la Shell que est configurado.
60

 Acceso por red Ethernet:

Si se dispone de un servidor conectado en red (es lo habitual), se
puede hacer login al dominio directamente utilizando algunas de
las aplicaciones destinadas a este efecto: telnet, rsh, ssh, rlogin. Es
habitual el uso de ssh debido a que establece conexiones seguras.

XSCF: eXtended System Controller Facility

El XSCF es una utilidad para el control del servidor que incluye un procesador
independiente de los del servidor, es el Procesador de Servicio.
XSCF es un firmware que viene instalador por defecto en algunas de las
mquinas de gama media y alta de ORACLE (servidores Mx000) y que funciona
en la unidad XSCFU.
Cuando se suministra energa elctrica, en el servidor de alimentacin de
entrada, XSCF monitoriza el servidor y lo gestiona incluso aunque los dominios
estn apagados.
De hecho, es la forma de gestionarlos en este caso, y desde la XSCF se pueden
arrancar los dominios.
La XSCF proporciona una interfaz de comandos para el usuario en la que se
pueden gestionar los dominios y el servidor en s.
Dispone de dos interfaces externas: un puerto serie y un puerto LAN, y gracias a
estas se puede conectar mediante un terminal o un ordenador personal a travs
de conexin serie o conexin Ethernet.
A continuacin se observan algunos de los comandos que se pueden ejecutar
con la interfaz de comandos XSCF y la utilidad que tienen:

61

Existe un modo de configuracin redundante para conseguir una alta fiabilidad.

En esa configuracin una XSCF es la que toma el control (XSCF activa), y existen
otras XSCF que estn a la espera (stand-by).
Mediante una monitorizacin entre los XSCF en espera y activo, en caso de una
falla del XSCF activo, el que est (o uno de los que estn) en espera tomen el
control conmutando el servicio.

62

4.2

Oracle VM para SPARC

Otro tipo de soluciones que ofrece ORACLE para implantar virtualizacin es el

software llamado ORACLE VM para SPARC, antes conocido como LDoms (Logical
Domains, se usar en adelante tambin el trmino LDOM para referirse a
ORACLE VM para SPARC).
Se trata de una virtualizacin de plataforma, completa, en un escaln superior al
de los dominios fsicos explicado anteriormente.

Este tipo de virtualizacin se compone de una parte a nivel de firmware y de la

instalacin de Domain Controller, que es responsable de la gestin de los
dominios lgicos (logical domains) creados. En esta arquitectura el hypervisor se
encuentra a nivel de firmware, y el control domain a nivel de sistema operativo.
Se puede decir que el control domain es quien gestiona los dominios y se
comunica con el hardware.
Un poco ms adelante se explicar con ms detenimiento algunos trminos
necesarios para la comprensin del funcionamiento de esta solucin.
El dominio de control (control domain) y el dominio de servicio (service domain)
pueden correr juntos, pero las aplicaciones de usuario no deben estar instalada
en este dominio, con el fin de proteger la estabilidad y rendimiento del dominio.

Imagen 14: Esquema de virtualizacin con ORACLE VM

Gracias al comportamiento del firmware, se proporciona un entorno de
arranque diferente para cada dominio lgico, y en teora, es posible correr
cualquier sistema operativo programado para arquitectura SPARC.
63

Por lo tanto, la versin el sistema operativo Solaris que corre en un dominio

invitado puede ser diferente a la versin que corre en el dominio primario.
Consideramos este detalle de cara a la implementacin prctica del proyecto,
donde nos valdremos de esto para compatibilizar software mediante
consolidacin de servidores.

4.2.1 Hipervisor y dominios lgicos

El hipervisor es una capa firmware que provee de una arquitectura de mquina
virtualizada, estable, en la que un sistema operativo puede escribirse. Como
hemos visto anteriormente, el hipervisor, hace de intermediario entre el
hardware y los dominios lgicos, y las instancias de sistema operativo que
corren en ellos.
Un dominio lgico es una mquina virtual que tiene asignados una serie de
recursos, tiene su propio sistema operativo y se comporta como un sistema
independiente.
Como sistemas independientes, los dominios lgicos pueden ser creados,
destruidos, configurados y reiniciados, sin que sea necesario un reinicio del
servidor.
Tambin pueden correr diferentes aplicaciones sobre los distintos dominios
lgicos con los beneficios que ofrecen esa independencia: rendimiento y
seguridad.

El hipervisor asigna recursos del servidor a cada dominio lgico, y ste slo tiene
disponibles esos recursos.
El gestor de dominios lgicos (Logical Domain Manager), permite especificar
qu debe hacer el hipervisor a travs del dominio de control (control domain).
Esta asignacin de recursos y su configuracin, es fundamental para la
construccin de dominios lgicos.
A continuacin se ilustra con un diagrama el hipervisor soportando dos
dominios lgicos, as como las capas que llevan a cabo la funcionalidad de
Logical Domains:

Aplicaciones, y servicios de usuario

Kernel (sistema operativo)
Firmware (hipervisor)
Hardware, CPU, memoria y entrada-salida

64

Imagen 15: Esquema de virtualizacin Logical Domains con diferentes capas.

Como sabemos, el hipervisor asigna recursos (CPU, memoria y E/S) del servidor
a un dominio lgico, y gracias a esto se pueden ejecutar diferentes instancias de
sistema operativo, una por cada dominio lgico.
Cada domino lgico se administra como una mquina independiente, con su
ncleo, parches, cuentas de usuario, administradores, discos, interfaces de red,
direcciones MAC y direcciones IP.
El hipervisor hace posible y es responsable de la separacin entre dominios y de
la comunicacin entre ellos gracias a los LDC (logical domain channels), que no
slo comunica, sino que ofrece servicios de un dominio lgico a otro.
En el captulo anterior se habl del procesador de servicio (service processor o
SP), o controlador del sistema (system controller o SC), como una herramienta
para monitorizar, gestionar y administrar el servidor. Es importante el detalle de
que la SC slo influye en el servidor fsico y nunca sobre los dominios lgicos,
esa labor de gestin de dominios lgicos la cumple el Logical Domain Manager.

65

4.2.2 Logical Domain Manager

El Logical Domains Manager se utiliza para crear y administrar dominios lgicos,
as como tambin para asignar dominios a recursos fsicos. En un servidor slo
puede haber un Logical Domains Manager corriendo.
Los dominios lgicos se distinguen por los roles que pueden desempear, a
continuacin se explican esos roles:
Control domain: En l se instala el software Logical Domains Manager y
es donde se gestiona todo el medio de dominios lgicos. Se usa para
configurar recursos y dominios invitados. Slo puede existir un control
domain por servidor y se le llama primary.
Service domain: Provee de los servicios virtuales a los dominios invitados.
Estos servicios virtuales pueden ser discos virtuales, switches de red o
consolas virtuales. Cualquier dominio puede ser configurado como un
service domain. Existe uno por defecto, que es el control domain que
nutrir de servicios a los guest domains. El service domain tiene control
directo sobre el hardware del controlador PCI-E, y la SUNFIRE T2000 slo
dispone de dos PCI-E, por lo tanto slo puede haber dos service domain.
Si otro, a parte del control domain, es configurado como service domain,
se habla de configuracin Split-PCI-E.
I/O Domains: Un dominio de entrada-salida tiene participacin directa y
acceso directo a los dispositivos de entrada-salida, como una tarjeta de
red en un controlador PCI Express. Muchas veces es utilizado como un
service domain que distribuye dispositivos fsicos a otros dominios en
forma de dispositivos virtuales. El nmero de dominios de entrada-salida
depende del modelo del servidor.
Existe otro dominio llamado dominio raz, que tiene la propiedad
directa de los dispositivos PCI. Por lo tanto, tambin es llamado dominio
de entrada-salida.
Guest domains: Los dominios invitados no se comportan como ninguno
de los tipos anteriores. Simplemente ejecutan instancias de sistemas
operativos. Son dominios que no tienen dispositivos de entrada-salida,
sino dispositivos virtuales de entrada-salida, como discos virtuales o
interfaces de red virtuales.
Se trata de dominios consumidores de recursos y de servicios.
Durante la configuracin inicial de un sistema con LDOMs, primero se inicia con
este dominio especial, el Control Domain. Inicialmente este dominio tiene
disponible todo el hardware disponible en el sistema, incluyndo CPUs, RAM, y
todos los recursos de entrada-salida. Si se quiere mantener el sistema sin
66

virtualizacin, se podra trabajar con ese escenario. Para permitir sistemas

invitados, primero se cambia el tamao de ese dominio inicial (primary),
asignando una mnima cantidad de CPU y memoria (esto deja la mayora de la
CPU y memoria disponible para los recursos de dominios invitados.
LDOMs utilizan el hipervisor como capa de abstraccin entre el hardware fsico y
el virtual.
Este hardware virtual es luego usado para crear un nmero de sistemas
invitados, los cuales se comportan muy parecido a un sistema fsico
independiente.
El software de Logical Domains Manager se puede instalar en cualquier sistema
que no est ya configurado con dominios lgicos. Desde ese momento, esa
instancia de sistema operativo se convierte en el control domain. Una vez existe
el control domain, se puede balancear la carga de trabajo, creando nuevos
dominios y moviendo aplicaciones de un dominio a otro para conseguir un
sistema ms eficiente.
CPU
La arquitectura CMT (chip multi-threading) de soporte de CPUs (desde los
procesadores T1 hasta T4), proveen de un gran nmero de ncleos e hilos al
sistema operativo.
Por ejemplo, una CPU T4 tiene ocho ncleos, cada uno de ellos con ocho hilos,
eso hace un total de 64 hilos por socket. Para el sistema operativo, suponen 64
CPUs.
El hipervisor, cuando crea los sistemas invitados, simplemente asigna cierto
nmero de esos hilos exclusivamente a un invitado. El hipervisor slo asigna
CPUs y se mantiene al margen. No se ve envuelto en el trabajo de distribucin
desde el sistema operativo a la CPU, todo lo que hace es mantener aislamiento
entre los diferentes invitados.
Estas CPUs virtuales pueden ser reconfiguradas dinmicamente, es decir,
pueden ser aadidos o eliminados hilos asignados a un dominio lgico mientras
el sistema est corriendo sin necesidad de un reinicio.
MEMORIA
De forma parecida a la CPU, la memoria disponible en el servidor fsico es
virtualizada, de tal modo que el hipervisor provee de memoria a los diferentes
dominios lgicos.
La memoria puede ser asignada con incrementos de 8KB y, lo que es ms
importante, para las mquinas virtuales se presenta comenzando en la misma
direccin que para el sistema fsico. Esto es un punto importante para sistemas
operativos que pueden no funcionar si la memoria no est ubicada donde se
espera que est.
67

El proceso de traduccin de memoria del sistema fsico a la memoria de los

dominios lgicos se denomina mapeo (mapping). Esto ocurre en la mayora de
los sistemas operativos, incluido Solaris. Las aplicaciones ven la memoria que es
reasignada por el kernel de una direccin real a una virtual. El hipervisor,
trabajando con la unidad de gestin de memoria del hardware, da un paso ms,
asignando la memoria fsica (hardware), a la que se presenta al sistema
operativo, que en el caso de Solaris, ser referenciada como real.

Imagen 16: Esquema de asignacin de memoria

DISPOSITIVOS ENTRADA-SALIDA
Los dispositivos de entada-salida, como los discos internos, y las controladoras
PCI-Express, as como sus adaptadores y dispositivos adjuntos, se pueden
presentar a los distintos dominios lgicos de varias formas, dependiendo de los
requerimientos de la aplicacin y del modelo administrativo requerido.
Dispositivos I/O
El software LDOMs usa un modo en el que el hipervisor crea una asignacin del
dispositivo fsico a una interfaz virtual. El software permite al dominio lgico
mantener la propiedad del dispositivo.
En un entorno con dominios lgicos, el bus PCI-E puede ser programado para
asignar cada puerto a dos dominios diferentes utilizando el Logical Domains
Manager.
Esto habilita a ms de un dominio con acceso directo a los dispositivos fsicos al
contrario que ocurre con la virtualizacin de entrada-salida.

68

Cuando el sistema es encendido, el Control Domain tiene asignados todos los

recursos fsicos. Luego pueden ser liberados y ser propiedad independiente
como PCI-E A y PCI-E B.
En el esquema siguiente se ilustra esta asignacin:

Imagen 17: Esquema de asignacin de recursos del control domain.

Tal y como se puede observar, el lmite de nmero de dominios lgicos que

pueden poseer bus PCI-E es de dos, y esta es una de las razones de la necesidad
de la virtualizacin de entrada-salida, ya que provee de flexibilidad para que
ms dominios lgicos puedan acceder a dispositivos de entrada-salida,
compartiendo sin tenerlos propiedad directa.
Dispositivos I/O virtualizados
En contraste con los dispositivos directos (no virtualizados), los dispositivos
virtuales tienen la capacidad de poder compartir los dispositivos entre los
distintos dominios lgicos, permitiendo la creacin de redes de almacenamiento
virtuales, y por lo tanto aadiendo nuevos beneficios de consolidacin
racionalizando almacenamiento e interfaces.
El concepto de dispositivos virtuales est basado en al menos un service domain
que posee un dispositivo mediante le modelo de entrada-salida directa, y que
establece un camino con los otros dominios lgicos mediante un LCD (logical
domain channel). El sistema operativo en los dominios invitados ve el
controlador del dispositivo virtual con el que puede interactuar como si fuera un
dispositivo fsico local.
69

Imagen 18: Esquema con guest domain con dispositivos virtuales

Estos LCDs trabajan de forma muy parecida a las conexiones serie de alta
velocidad y son configurados automticamente cuando el Control Domain
aade o elimina dispositivos de entrada-salida virtuales.

RED
Con el software Logical Domains Manager, los adaptadores de red son recursos
virtualizados. La infraestructura de red virtual tiene dos componentes:
o Dispositivos de red virtual (vnet) implementan un dispositivo
Ethernet virtual y comunica con otros dispositivos vnet del sistema
utilizando un switch de red virtual.
o Switch de red virtual (vsw) es un switch de red que conecta los
dispositivos de red virtual a la red externa y conmuta paquetes
entre ellos.
CONECTIVIDAD
Una conexin de red desde un dominio invitado se consigue primero creando
un servicio vsw (vswitch), provisto por un service domain, como el control
70

domain, y luego creando dispositivos vnet que conectan con l, y son aadidos
al dominio invitado.
Es posible crear switches virtuales que no tienen acceso al dispositivo de red
fsico, creando una red privada entre uno o ms dominios. Por ejemplo, es de
utilidad cuando creamos una red privada entra un servidor de aplicaciones y un
servidor de base de datos en dominios separados, ayudando a incrementar la
seguridad y reduciendo el trfico de red en la LAN pblica.
DIRECCIONES MAC
Un punto importante de la tecnologa de Logical Domains es la habilidad de
crear redes sofisticadas, con mltiples switches virtuales y redes virtuales entre
dominios y las redes externas a los sistemas fsicos.
Esto requiere suficiente direcciones MAC para asignar a esos dispositivos y ,
como administradores, se tiene la opcin de asignar manualmente direcciones
MAC a esos dispositivos. Sin embargo, Sun provee de otras opciones de
asignacin automtica de direcciones MAC para los switches virtuales y
dispositivos de red.
ALMACENAMIENTO
La infraestructura de discos virtuales (vdisk) implementa un mecanismo para
que las aplicaciones en un dominio lgico accedan a los datos en disco
gestionado por el dominio con acceso directo de entrada-salida, como si los
discos estuvieran directamente disponibles por el dominio lgico.
La infraestructura vdisk tiene dos componentes con una interfaz comn:
o Controlador cliente de disco virtual (vdc), que reside en el dominio
lgico y proporciona acceso a los dispositivos de bloque estndar,
a las aplicaciones que se ejecutan en ese dominio.
o Controlador servidor de disco virutal (vds), que reside en el service
domain y aplica peticiones vdisk al correspondiente archivo o
volumen de disco exportado por l. El disco virtual puede basarse
en varios tipos de dispositivos, incluyendo:
Un disco fsico completo, que podra tambin ser una
particin presentada por un dispositivo SAN, a veces
denominado como logical unit number (LUN).
Un solo slice de un disco o LUN
Archivo de disco imagen en un file system (como un UFS o
ZFS)
Volumen de discos (ZFS, SVM, VxVM)

71

Imagen 19: Esquema de flujo con un dominio invitado y un control

domain que acta tambin como service domain.
CONSOLA
La consola ha sido tradicionalmente el conducto para acceder a un nivel del
sistema para propsitos administrativos, como la revisin de mensajes de
arranque durante una intervencin cuando otros mtodos no pueden ser
usados, como cuando los servicios de red estn cados. El dispositivo de consola
como conexin al entorno OpenBoot PROM est tambin virtualizado por el
hipervisor. Se consigue una conexin conectando al servicio de red en el control
domain a un puerto especfico.
Un servicio concentrador virtual de consola (vcc) se crea en un rango especfico
de puertos TCP que son asignados a los dominios secuencialmente segn son
creados.
Por ejemplo, si un concentrador de consola virtual es creado en un rango de
5000 al 5100, para conectar al primer dominio invitado se hara haciendo telnet
al puerto 5000, el segundo dominio creado sera conectando al puerto 5001, y
as sucesivamente.
Es posible tambin especificar un concentrador de consola virtual para agrupar
consolas virtuales para asistir en la administracin. Por defecto la conexin
puede solamente hacerse con el control domain.
RECONFIGURACIN DINMICA
Se habla de reconfiguracin cuando aadimos o eliminamos recursos virtuales
que estn asignados o vinculados a un dominio. As como podemos hacer esto
con la CPU, memoria, y otros recursos, es conveniente saber que pueden
cambiarse y cmo hacerlo. Hay dos tipos de reconfiguracin: dinmica y
retardada.
o Reconfiguracin dinmica significa que podamos hacer cambios en
los recuros asignados a un dominio mientras el dominio est
72

corriendo y el sistema operativo est funcionando. Para hacer

posible esto hay dos requisitos: el hipervisor tiene que poder
soportar esos cambios dinmicamente y el sistema operativo tiene
que poder asimilar esos cambios durante la operacin.
o Reconfiguracin retardada permite cambios que pueden estar
disponibles a partir del siguiente reinicio del sistema operativo
invitado (o parando e iniciando el dominio lgico si no hay un
sistema operativo cargado). Se pueden hacer muchos cambios de
configuracin teniendo como objetivo un dominio. Despus de
que el dominio es reiniciado, y los cambios de configuracin
retardados son llevados a cabo, las reconfiguraciones pueden ser
hechas en otros dominios. Tambin, si se han eliminado
dispositivos no virtuales de entrada-salida con un comando de
reconfiguracin retardada, se pueden cancelar con el
correspondiente comando.
o Modo de configuracin es el modo inicial de para el entorno
despus de la primera instalacin del software Logical Domains
Manager (o cuando la mquina es reseteada a la configuracin de
fbrica por defecto). Todos los cambios en este modo son
encolados y tienen que ser guardados en una nueva descripcin
de la mquina, y luego tendrn efecto despus del siguiente
reinicio.
SEGURIDAD
Los sistemas operativos UNIX, como es el caso de Solaris, presentan varios
niveles de confianza. Esos niveles son designados por el espacio que ocupan: el
entorno de usuario y el entorno de kernel, que es privilegiado.
El control domain, que contiene los procesos que intervienen en la creacin y la
gestin de dominios lgicos, necesita ser asegurado de forma parecida al
system controller (SC) en un sistema hardware multi-dominio. El control domain
puede afectar a todos los dominios lgicos del sistema. El software Logical
Domains, a travs del hipervisor, implementa un nivel adicional en este modelo
de confianza.
La capa de firmware por debajo de la mquina virtual, el hipervisor, corre en un
nivel hiper-privilegiado y los procesos del contol domain, como los demonios de
gestin del dominio y el Logical Domain Manager, interactan con la capa de
firmware usando LDCs (logical domain channels). Mediante el uso de los
llamados hypertraps, la implementacin de LDCs a este modo hiperprivilegiado
permite al hipervisor controlar los procesos del dominio. De un modo similar,
los traps se usan para mover desde el espacio de usuario al entorno del kernel.
El concepto principal a entender es que el hipervisor y los procesos del control
domain corren en un nivel mayor de privilegio para hacer su labor.
73

 OpenBoot PROM
El entorno OpenBoot PROM forma la base del programa inicial de carga y
ejecucin tpico de un sistema operativo. Tambin provee de otras
caractersticas, como diagnosis y parmetros en tiempo de arranque, para
controlar la operacin. En el software de Logical Domains, el enorno OpenBoot
PROM tambin est virtualizado, y puesto a disposicin en mltiples
particiones como discretos medios de arranque. El firmware OpenBoot es la
base de ejecucin del sistema operativo en un dominio lgico.
El prompt OpenBoot {0} ok es lo primero que se ve cuando conectamos por
consola a un dominio lgico recin creado, y resulta familiar a cualquiera con
experiencia en hardware con arquitectura SPARC.

Imagen 20: El porcentaje de utilizacin de recursos aumenta con la

consolidacin

4.3

Solaris Zones

Solaris Zones (previamente llamado Solaris Containers), es otra de las soluciones

que nos ofrece ORACLE como virtualizacin en mquinas de arquitectura SPARC,
aunque tambin para x86. Fue lanzada por primera vez en febrero de 2004,
como paquete adicional para la versin beta de Solaris 10, y despus se inclua
en la versin esable de Solaris 10, en 2005. Tambin est disponible en las
versiones de OpenSolaris, como OpenIndiana, SmartOS, y OmniOS, y por
supuesto en la versin oficial Solaris 11.
74

Solaris Zones da un alto grado de flexibilidad en el diseo de arquitecturas de

computadores. Como hemos adelantado, forma parte del sistema operativo, y
es capaz de aislar aplicaciones y servicios, usando lmites flexibles definidos a
nivel de software. En un acercamiento a la virtualizacin y al particionado
software, Solaris Zones permite varios entornos de ejecucin privados que son
creados en una misma instancia de sistema operativo. Cada entorno
virtualizado, llamado zona, tiene su propia identidad que es independiente del
hardware subyacente. Como consecuencia, cada zona se comporta como si
estuviera corriendo en su propio sistema, consiguiendo una consolidacin
simple y segura. Mientras cada zona parece ser independiente, todas las zonas
en un acceso al sistema, compiten por los recursos hardware compartidos.

Para hacer posible la consolidacin en entornos de centros de datos con carga

de trabajo, existen herramientas que se incluyen para gestionar la utilizacin de
recursos hardware.
Ya que las zonas Solaris son independientes del hardware subyacente, se
pueden recrear servicios de aplicacin en otros sistemas segn las necesidades.
Cada aplicacin corre en su entorno privado, y los recursos de aplicacin
pueden ser probados y desplegados en un solo servidor sin miedo a que pueda
afectar uno al otro.
Los sistemas y recursos de red pueden ser asignados y controlados en forma de
grano fino, ayudando a simplificar las infraestructuras de computadores y
mejorando la utilizacin de recursos. En consecuencia, las empresas pueden
consolidar aplicaciones en menos servidores sin preocuparse por la limitacin
de recursos, la propagacin de fallos, fallos en seguridad, simplificando la
prestacin de servicios.
Solaris Zones comprende dos tecnologas: Tecnologa de particionado de Solaris
Zones y caractersticas de gestin de recursos. Solaris Zones provee de entornos
de operacin virtualizados que tienen su propio hostname, direccin IP,
usuarios, file systems etc. Garantizando aislamiento en las aplicaciones y
proteccin entre ellas. El gestor de recursos controla cmo son distribuidos los
recursos ante las cargas de trabajo.

75

Existen dos tipos de zonas: zonas globales (global

zone) y zona no global (non-global zones). El entorno
estndar donde est instalado el sistema operativo se
le llama zona global, y las zonas no globales son los
entornos opcionales virtuales que pueden ser creados
para alojar aplicaciones.
Tenemos por lo tanto, un nico kernel compartido,
aunque aislado.
Un panic en una zona, no debera afectar a otra (en
teora).
De un modo parecido al que ocurre con Logical Domains, la zona global es la
encargada de gestionar a las dems.
La principal diferencia, a parte del kernel compartido, est en la reconfiguracin
dinmica.
No es posible hacer cambios de configuracin en caliente con Solaris Zones, es
necesario el reinicio para que los cambios tengan efecto.

4.3.1 Zonas globales y zonas no globales

Como se ha adelantado, existen dos tipos de zonas:
Zona global: es la zona que se instala por defecto el sistema operativo, y
lleva el control sobre todos los procesos. Siempre existe una zona global
aunque no haya otras zonas configuradas.
Zonas no globales (o simplemente zonas): son configuradas dentro de la
zona global. A efectos prcticos son sistemas aislados y no pueden
detectar la presencia de otras zonas. Las zonas estn aisladas del
hardware fsico y de la plataforma en s.
Un sistema operativo Solaris, contiene una zona global. Es la zona por defecto
del sistema y la zona usada para el control administrativo de todo el sistema.
Si no hay zonas no globales, todos los procesos corren en la zona global.
Se considera que:
El inicio de la zona global es equivalente al inicio del sistema hardware
Cada zona, incluida la zona global, tiene asignada un nombre. La zona
global siempre tiene el nombre global
Cada zona tiene asignada un nico identificador numrico. La zona global
tiene siempre el identificador ID 0
Cada zona tiene una ruta a su directorio raz que es relativa al directorio
raz de la zona global
76

 La zona global es la nica zona desde donde una zona no global puede
ser configurada e instalada
Se puede pensar en una zona como una caja con muros flexibles y definidos por
software. Una o ms aplicaciones pueden correr en esas cajas sin interactuar
con el resto del sistema. Ya que las zonas aslan aplicaciones software y
servicios, aplicaciones que corren en la misma instancia del sistema operativo
Solaris pueden ser gestionadas independientemente unas de otras. Por
ejemplo, diferentes versiones de la misma aplicacin pueden correr en
diferentes zonas.
Existe una solucin para ayudar con la gestin del entorno virtualizado por
zonas; se trata de la herramienta Manager Ops Center, el cual puede llevar a
cabo las siguientes acciones:
Crear zonas
Descubrir y gestionar zonas existentes
Iniciar, reiniciar, apagar, clonar, migrar y borrar zonas
Gestionar file systems de zonas, almacenamiento, red, y utilizacin de
recursos por cada zona.

77

Tipo de zona
Global

Caractersticas
El sistema le asigna el ID
Proporciona la nica instancia del ncleo de Solaris que se puede iniciar y ejecutar en
el sistema
Contiene una instalacin completa de los paquetes de software del sistema Solaris
Puede contener paquetes software adicionales, as como archivos, directorios,
software y otros datos adicionales que no se instalen como paquete

No global

Proporciona una base de datos de productos completa y coherente que contiene

informacin acerca de todos los componentes de software instalados en la zona global
Almacena solamente la informacin de configuracin especfica para la zona global
como, por ejemplo, la tabla del
sistema de archivos y el nombre de host de la zona global
Se trata de la nica zona que tiene informacin de todos los dispositivos y todos los
sistemas de archivos
Es la nica zona que tiene constancia de la existencia y la configuracin de la zona no
global
Es la nica zona desde la que se puede configurar, instalar, gestionar o desinstalar una
zona no global
El sistema le asigna un ID de zona cuando se inicia la zona
Comparte el funcionamiento en el ncleo de Solaris iniciado desde la zona global
Tiene instalado un subconjunto de los paquetes de software del sistema operativo
Solaris
Contiene paquetes de software Solaris compartidos desde la zona global
Puede contener paquetes de software instalados adicionales que no estn
compartidos desde la zona global
Puede contener archivos, directorios, software y otros datos adicionales creados en la
zona no global que no se instalan mediante paquetes y no estn compartidos desde la
zona global
Dispone de una base de datos de productos coherente que incluye informacin acerca
de todos los componentes de software instalados en la zona, con independencia de
que estn presentes en la zona no global o que sean elementos de slo lectura
compartidos desde la zona global
No tiene informacin sobre la existencia de ninguna otra zona
No se pueden instalar, gestionar ni desinstalar otras zonas, incluida ella misma
Dispone solamente de informacin de configuracin especfica para dicha zona no
global como, por ejemplo, la tabla del sistema de archivos y el nombre de host de la
zona no global
Puede tener su propia configuracin de zona horaria

78

Zonas no globales
Se pueden crear varios tipos de zonas no globales con diferentes propsitos. Se
clasificarn del siguiente modo:
Por file systems
o Sparse Root Zone: Contiene una copia de lectura/escritura de una
parte del sistema de archivos existente en la zona global. Otros
sistemas de archivos se montan en modo slo lectura desde la
zona global como sistemas de archivos virtuales (loop-back).
Cuando se crea una zona de este tipo, el administrador selecciona
qu file systems se van a compartir con la zona sparse adems de
los file systems en modo slo-lectura que existen por defecto:
/usr, /sbin, /platform
Todos los paquetes que se instalan en la zona global estn
disponibles para las zonas sparse; se crea una base de datos de los
paquetes y todos los file systems montados se comparten con la
zona.
o Whole Root Zone: Contiene una copia de lectura/escritura de
todo el file system que existe en la zona global. Cuando se crea
una zona de este tipo, todos los paquetes que se instalan en la
zona global, estn disponibles tambin en la zona; se crea una
base de datos de los paquetes y todos los ficheros se copian a la
zona para uso dedicado e independiente de ella.
o Branded Zone: Soporta diferentes versiones de sistema operativo
Solaris para compatibilidad de ejecucin de aplicaciones. Por
ejemplo, se puede instalar Solaris 8 9 en una zona de este tipo.

79

Ejemplo de zona con file systems tipo lofs (comparten los file
systems /usr, /lib, /sbin, /platform) El tamao de la zona no global
es muy pequeo.

Ejemplo de zona sin comparticin de file systems. Este aislamiento

permite tener diferentes paquetes de software instalados en la
zona, y diferentes parches.
Antes se ha mencionado la herramienta Enterprise Manager Ops Center como
ayuda para la gestin del entorno virtualizado. Esto no quiere decir que sea la
nica forma de gestionar nuestras zonas, como siempre, disponemos de la lnea
de interfaz de comandos (CLI).
Las zonas que son creadas con el Enterprise Manager Ops Center son
referenciadas como greenfield zones y tienen un icono particular en la
interfaz de usuario de la herramienta. Para este tipo de zonas, el Enterprise
Manager Ops Center tiene total acceso a la configuracin de las mismas y el
control de gestin es total.
En caso de zonas creadas con la interfaz de comandos, se denominan
brownfield zones, y en este caso el Enterprise Manager Ops Center no puede
detectar la configuracin de la zona y ofrece menos soporte que para las zonas
greenfield.
Por ejemplo, no puede realizar algunas acciones como: editar la configuracin,
agregar file systems, agregar almacenamiento, conecta a redes, migrar la zona.

80

Estado en las zonas no globales

Existen seis estados para las zonas no globales:
Configured (configurada): la configuracin de la zona est completada y
se enva a una ubicacin de almacenamiento, sin embargo an no estn
presentes los elementos del entorno de aplicacin de la zona que deben
especificarse tras el inicio inicial.
Incompleta (incomplete): ocurre cuando ha finalizado incorrectamente
una operacin de instalacin o desinstalacin de zona.
Instalada (installed): la configuracin de la zona se instancia en el
sistema. Los paquetes se instalan bajo la ruta raz de la zona. En este
estado, la zona no tiene ninguna plataforma virtual asociada.
Lista (ready): queda establecida la plataforma virtual para la zona. El
ncleo crea el proceso zxched, las interfaces de red se configuran y
quedan a disposicin de la zona, se montan los file systems y los
dispositivos se configuran. El sistema asigna ID de zona nico. An no hay
iniciados procesos asociados con la zona.
Ejecutndose (running): los procesos de usuario asociados con el entorno
de aplicacin estn en ejecucin. La zona pasa a este estado cuando el
primer proceso de usuario se crea (init).
Cerrndose y cerrada (shutting down): la zona est en estado de parada.
Control de recursos (Resource Manager)
Se trata de una tecnologa que permite controlar el uso de recursos de las
mquinas virtuales. Para llevar a cabo esto, se asignan recursos a cada una de
las zonas.
Se puede asignar porcentaje de utilizacin de CPU, cantidad de memoria RAM,
de red, etc.
Control de uso de CPU:
Puede ser de tres tipos:
CPU fija: en este modo se asigna una o ms CPUs a cada zona de forma
inalterable. La ms directa desventaja es el desaprovechamiento de
capacidad de procesamiento en caso de no requerir mucho uso de CPU.
CPUs dinmicas: es posible asignar umbrales de capacidad de
procesamiento para cada zona. Esto es asignar un mnimo y un mximo
81

de CPUs para cada zona. El daemon pool es el responsable del balanceo

de CPUs disponibles segn la carga de trabajo de cada zona.
CPUs compartidas: en este modo se dispone de una CPU o un pool de
CPUs que son compartidas por varias zonas. A cada zona se le indica qu
porcentaje mnimo de CPU puede utilizar.
Por ejemplo, si se dispone de tres zonas, con unos pesos de 6, 3 y 1, si
slo est procesando la zona de 6, usar toda la CPU. Si se comienza a
ejecutarla zona de peso 3, entonces la zona de peso 6 utilizar un mnimo
de 66% y la de peso 3 un 33%. SI se ejecuta la zona del 1, entonces los
porcentajes seran: 6-66%, 3-30%, y 1-10%
Control de uso de memoria:
Se utiliza el resource control del sistema, mediante una propiedad
llamada zone.max-locked-memory se establece un lmite de memoria
para la zona.
Control de uso de espacio de disco:
Las zonas pueden ser creadas en:
Discos independientes y particiones (slices): directorio de
un file system, particin o disco independiente.
Volmenes independientes: se pueden instalar zonas en
volmenes de Solaris Volume Manager y crear RAID1,
RAID5, etc.
ZFS: puede instalarse en un file system de tipo ZFS o
compartir un file system de la zona global.
Red: en la creacin de zonas, se asigna una direccin IP y una interfaz de red de
la zona global.
En la elaboracin de este documento he optado por enfocarme en la
arquitectura y funcionamiento terico de las tecnologas estudiadas, sin
detenerme en los comandos especficos utilizados tanto para la gestin y
administracin de dominios como para la de zonas.
En el siguiente captulo correspondiente a la implementacin prctica de
laboratorio ir aadiendo explicaciones a los comandos utilizados en cada parte
de la instalacin y configuracin.

82

DISEO E IMPLEMENTACIN

5.1 Introduccin
Muchas empresas requieren de herramientas y aplicaciones para el desarrollo
de su actividad. En ocasiones estas aplicaciones son tan especficas que son
solicitadas a otras empresas para que sean desarrolladas en funcin de las
necesidades del modelo de negocio.
En nuestro escenario partimos de una empresa que dispone de un software de
este tipo, hecho a medida, que corre y es compatible con Solaris 9.
El sistema operativo Solaris 9 fue lanzado en mayo de 2002 y finaliz su segundo
periodo de soporte a finales de 2015, por lo que interesa disponer de una
versin en periodo de soporte para tener el apoyo de ORACLE ante cualquier
problema que pueda ocurrir.

Por otra parte, nuestro software a medida, que sigue siendo perfectamente
vlido para las necesidades de negocio, fue programado para Solaris 9 y muy
probablemente tendr problemas de compatibilidad con otras versiones.
Para la realizacin prctica dispondremos de:
SUNFIRE T2000 donde haremos la implementacin prctica, la
configuracin de 6 core con 8GB de RAM
Porttil i5, con 8 gb de RAM para conectar por ssh al servidor

83

Se muestra, en estas imgenes nuestra

SUNFIRE T2000. Vemos vista de la mquina
en el rack, as como vista delantera y
trasera.
Se observa en la vista trasera que pese a
tener redundancia de alimentacin, slo se
est usando una de ellas.

84

Ya que no disponemos de otra mquina ms antigua para simular la situacin de

migracin explicada, utilizaremos un dominio lgico con Solaris 9 como si fuera
la mquina a migrar.
Montaremos dos dominios lgicos, uno, llamado todd-01 corriendo Solaris 10 y
todd-02 corriendo Solaris 9.
Como hemos visto en el captulo anterior, un domino lgico es una mquina
virtual virtualizada a nivel de firmware, y las trataremos como mquinas
independientes.
El servidor todd-02 ser la mquina antigua en la que corre el software hecho a
medida que mencionamos anteriormente, y por lo tanto tendr instalado Solaris
9.
El servidor todd-01 ser la mquina (dominio) destino.
La implementacin constar de las siguientes fases:

Estado inicial
Downgrade a la versin Logical Domains 1.2
Configuracin del control domain
Creacin y conifguracin de dominio lgico todd-01
Instalacin de Solaris 10 en todd-01
Creacin de flar en todd-test2 (Solaris 9)
Creacin de branded zone en todd-test1
Instalacin de flar en todd-test1.

Partimos de una instalacin ya hecha de Solaris 11, en una mquina SUNFIRE

T2000, con procesador T1 en arquitectura SPARC. Disponemos de la
configuracin de 6 cores y 4 hilos por cada core y de una memoria RAM de 4GB.

5.2 Estado inicial

Comenzamos mostrando nuestro servidor, para ello, conectaremos por consola.
En nuestro caso, conectaremos indirectamente a todd (nuestro servidor), a
travs de un firewall llamado lisa. Conectaremos al puerto 4023 por telnet y lisa
nos redirigir a la consola de todd (nuestro SUNFIRE T2000).

85

Como se observa, la consola es la ALOM (Advanced Lights Out Manager CMT)

Nos dar un prompt de sc (system controller). Para que el software de Logical
Domains Manager funcione, se requiere una versin de firmware 6.4 o superior.
Veamos qu versin tenemos:

Como vemos cumplimos los requisitos de firmware por lo que pasamos a la

instalacin del software de virtualizacin.
Una vez comprobado, podemos acceder a la mquina por ssh para comenzar la
configuracin.

5.3 Downgrade a Logical Domains 1.2

Solaris 11, viene con la versin ORACLE VM for SPARC 2.2. Esta versin requiere
procesadores T2, T2+, T3, o T4, por lo que no es compatible con nuestro
procesador T1. Por lo tanto debemos bajar a la versin Logical Domains 1.2.
Hay que decir que esta no es la mejor combinacin, ya que Solaris 11 no
dispone del comando patchadd por lo que no hay modo de aplicar parches a
Logical Domains 1.2 y nos veremos obligados a usar una versin sin parchear.
Pese a todo, para las pruebas que haremos es suficiente y no bajaremos de
versin de Solaris por no ser estrictamente necesaria.
Veamos algunas caractersticas de nuestra mquina:

Vemos que partimos de una instalacin de Solaris 11 e nuestra SUNFIRE T2000,

en su configuracin con 6 cores, cada uno con 4 hilos, un total de 24 hilos. Eso,
en la prctica tendr un comportamiento de 24 CPU virtuales que podremos
asignar a los dominios que creemos dependiendo de las necesidades.
Disponemos tambin de 8GB de memoria RAM.
86

Boot environment: Solaris, a partir de su versin 8, incluye esta funcionalidad.

Un boot environment es una caracterstica que permite un arranque completo y
totalmente diferente. Esto permite poder probar una nueva instalacin, o un
parcheado online, esto es, sin tener que detener sus servicios. Se hace la
comprobacin con la nueva configuracin, y en caso de que todo est correcto,
se puede reiniciar con el nuevo boot environment.
Veamos nuestros boot environment:

Creamos un nuevo boot environment:

As tendramos un nuevo entorno de arranque.

Como hemos dicho, necesitamos desinstalar la versin de ORACLE VM para
SPARC que viene con Solaris 11, por lo que procedemos:

Ya estamos en disposicin de instalar nuestro software de Logical Domains.

87

Comprobamos que no tenemos instalado el software de ldoms, que es el

servicio svc:/ldoms/ldmd

Una vez descomprimido el software vemos los paquetes que constituyen el

software:

Y vemos que tenemos disponible el correspondiente servicio habilitado:

Con esta operacin, tenemos nuestro software de virtualizacin Logical

Domains Manager 1.2 disponible instalado, y por lo tanto tenemos ya nuestro
control domain, que ser nuestro dominio primary.

5.4 Configuracin del control domain

Como hemos visto, una vez instalado el software de virtualizacin ya tenemos
control domain. Es en l donde gestionaremos todos los dominios, y donde
configuramos los recursos. Para ello nos valdremos de ldm que es el comando al
que obedece Logical Domains Manager.
88

Primero vamos a ver el estado actual de nuestro control domain, as como los
recursos disponibles:

89

Necesitamos crear los servicios que gestionar el control domain. Estos servicios
son tres:
Virtual disk service
Virtual switch service
Virtual console concentrator
Lo primero que debemos hacer es crear un vds (virtual disk service), que es el
servicio para gestin de discos virtuales.
Lo haremos con el comando add-vds:
Este comando crea un servidor de discos virtuales llamado primary-vds0 y lo
asigna al dominio primary (control domain). Este servicio permite asignar discos
a los futuros dominios lgicos que creemos.

90

Crearemos ahora el vconscon (virtual console concentrator service), que nos

permitir dar acceso por consola a los dominios invitados. Se trata de un
concentrador virtual, y todas las conexiones por consola se realizan mediante
un socket de UNIX.

Este comando crea el servicio primary-vcc, con un rango de puertos, en este

caso del 5000 al 5100 y lo asignamos al primary. Cada dominio invitado que
creemos tendr asignado un puerto en este rango, empezando en el 5000 con el
primer dominio que creemos y ascendiendo de forma correlativa. Podremos
conectar por consola al dominio haciendo telnet en local a ese puerto.
Ahora creamos el vsw (virtual switch service). Este servicio permitir la
comunicacin entre los dispositivos virtuales de red. Trataremos de explicar el
funcionamiento:
Pongamos por ejemplo en un caso real con varios ordenadores queriendo
conectar al mismo segmento de red. Para ello los conectaramos a un mismo
switch que dara salida al exterior. En el mundo virtual ocurre lo mismo,
crearemos un switch virtual que llamaremos primary-vsw0 y lo conectaremos a
la interfaz net0.

91

Ms tarde, cuando creemos los dominios lgicos, les aadiremos interfaces

virtuales de red y los asignaremos al switch para hacer posible la comunicacin
entre ellos, y tambin con el exterior mediante la interfaz de red net0 que
corresponde a la interfaz fsica e1000g0.
Una vez creados los tres servicios virtuales (switch, disco y concentrador),
continuamos con la configuracin:

Este comando asigna dos unidades aritmtico-lgicas al dominio primario.

La SUNFIRE T2000 tiene una unidad aritmtico lgica (MAU) por cada core, y
provee de asistencia en la multiplicacin y exponenciacin en procesamiento
SSL.
La FPU (Floating Point Unit) se comparte con todos los cores y la MAU, sirve de
ayuda para aliviar el problema de la unidad de coma flotante compartida.
Asignaremos ahora CPU a nuestro control domain. Recordemos que una de las
bondades de Logical Domains, es a la posibilidad de asignacin dinmica de
CPU.
Como hemos visto antes, nuestra mquina dispone de seis core con cuatro hilos
por core. Cada hilo puede ser tratado como una CPU virtual (VCPU) que pude
ser asignada al control domain o reservar para los dominios invitados que se
crearn.

92

Asignamos as 8 vCPU al control domain

Y ahora asignamos 2 GB de memoria RAM, dejando los otros 2 GB para los
dominios invitados:

Con esto hemos finalizado la configuracin del control domain pero an no est
salvada. Podemos usar el comando para listar las configuraciones y aadir la
nuestra:

Despus de un reinicio del servidor, iniciaremos el sistema con la nueva

configuracin, y de esta manera, siempre tenemos un sencillo proceso de
rollback en caso de querer volver al estado inicial.

5.5

Configuracin de dominios invitados

Una vez ya tenemos configurado el control domain, con todos los servicios y sus
recursos, estamos en disposicin de crear nuestros dominios invitados (guest
domains).
Como un dominio ms, se le deben asignar tambin vCPU (virtual CPU),
memoria RAM y unidad aritmtico-lgica. Como vemos, despus de ello,
tenemos nuestro dominio disponible.

93

Un dominio invitado puede estar en tres estados diferentes:

Inactivo (inactive):
En este estado el dominio est parado, y no tiene los recursos vinculados.
Es el estado adecuado para configurar, aadir recursos, y ms tarde
vincularlos.
Vinculado (bound):
Una vez asignados los recursos, es momento de vincularlos al dominio. El
control domain los hace visibles en los dominios invitados cuando el
dominio invitado est en estado bound.
Activo (active):
Cuando el dominio invitado est en estado activo, el sistema ha iniciado y
si tiene un sistema operativo instalado, y est configurado para que
arranque, lo har. En caso de que no est configurado para arrancar o no
tenga sistema operaitivo instalado, nos dejar en el prompt: ok

5.5.1 Asignacin de recursos

Una vez creado nuestro dominio invitado, y asignado vCPU, memoria RAM, y
unidad aritmtico-lgica, debemos tener una fuente de almacenamiento para
poder instalar el sistema operativo. Habitualmente este almacenamiento
proviene de cabinas externas destinadas a este efecto, o en otros casos la
mquina dispone de varios discos duros y podemos asignar uno de ellos a un
dominio, o hacer una particin para ello.
En nuestro caso, al disponer slo de un disco en el servidor, nos valdremos del
siguiente procedimiento:
Creamos un fichero que servir como disco duro del dominio invitado,
por ejemplo con mkfile
Lo aadimos como dispositivo de almacenamiento gracias al servicio que
hemos creado en el control domain primary-vds0
Una vez creado, lo hacemos visible para el dominio lgico.
94

Usaremos este mtodo tanto para la asignacin de disco de almacenamiento

para el sistema, como para hacer visible los archivos imagen (iso) de instalacin
de sistema operativo.
Procedemos:

Ya tenemos nuestro fichero que servir como disco duro para el dominio.

95

Ya tenemos nuestro disco asignado al dominio test1, donde instalaremos el

sistema operativo, pero para ello, debemos hacer visible para el dominio test1
una fuente de datos para instalar Solaris. Para ello copiamos en nuestro servidor
todd una imagen de Solaris 10, y la montaremos en otro dispositivo virtual para
hacerla visible en test1 como disco virtual.

Ya estamos en disposicin de instalar nuestro sistema operativo en test1. Para

ello, primero debemos abandonar el estado inactive a active, pasando por
estado bound.
96

5.6

Instalacin Solaris 10 en guest domain

Ya tenemos un sistema independiente, y para acceder a l, tenemos disponible

el puerto 5000 como consola. Por lo tanto accedemos por telnet al puerto 5000
de nuestro servidor, y eso nos llevar a la consola del dominio test1, que al no
tener un sistema instalado, nos llevar al ok.

Aqu podemos ver mediante el comando devalias los discos virtuales que son
accesibles desde test1.
Como hemos visto, como almacenamiento tendremos vdisk1, y nuestra iso de
Solaris 10 en iso_sol10. Ahora podemos iniciar desde iso_sol10.

97

98

99

100

101

102

Aqu est el proceso de identificacin de nuestra nueva mquina. Como se

puede observar, hemos salido de la instalacin al tener un problema al ubicar la
fuente de instalacin. Tanto como si ubicamos en un disco virtual como desde el
CDROM, no ser posible iniciar la instalacin.
Esto se debe a un bug de la versin de Solaris, en la que al buscar la fuente de
archivos no es capaz de encontrarlos.
Para solucionarlo montaremos el disco virtual en el cdrom.
Primero vemos cul es nuestro path de nuestro fichero de imagen.

Montamos en el cdrom nuestro disco e instalamos seleccionando como fuente

el cdrom.

103

104

105

106

Ya tenemos nuestro dominio con Solaris 10, accesible por consola. Por lo tanto,
ya tenemos nuestro sistema destino para hacer la migracin. Aunque el acceso
por consola se utiliza para labores de administracin, por lo que debemos darle
conexin por red.

5.6.1 Configuracin de red

Recordemos que en el control domain tenemos un switch virtual conectado a la
interfaz fsica de la mquina.
Debemos ahora crear un dispositivo de red virtual que agregaremos al dominio
invitado. Una vez hecho esto, tendremos una interfaz virtual en el dominio, a la
que podremos asignar una ip dentro del segmento para hacer visibles las dos
mquinas.
Primero creamos un dispositivo de red virtual desde el primary.

107

Ya tenemos nuestra vnet conectada al switch virtual. Ahora asignamos direccin

ip a la interfaz que se habr creado en el dominio test1.

108

Despus de asignar ip, comprobamos que hay conectividad. Para poder

conectar desde el exterior (a travs de todd), por ejemplo para hacer scp,
necesitamos aadir el gateway por defecto.

Una vez aadido, podemos transferir el software para la creacin de zonas.

Conectaremos desde todd a cada uno de los dominios, pero esta vez por ssh.
Para ello, y debido a que no hemos creado ningn usuario, debemos permitir
login al usuario root el acceso por ssh.

109

Una vez cambiada la variable, reiniciamos el servicio para actualizar el estado.

Hasta ahora hemos conseguido crear nuestro dominio lgico (todd-test1), le

hemos dado los recursos necesarios, hemos instalado el sistema operativo
(Solaris 10), y configurado la red y asegurado el acceso para la transferencia de
archivos.
Recordemos que en nuestro escenario partamos de una mquina con Solaris 9,
que corra un software til para la empresa y no compatible con otras versiones
de Solaris.
El objetivo es migrar esa mquina a una zona branded de Solaris 9 creada en
nuestro dominio con Solaris 10 (todd-test1). Ya que no disponemos de otra
mquina, simularemos la operacin creando un nuevo dominio que llamaremos
(todd-test2). Esta ser la mquina a migrar. El problema surge porque Solaris 11
(host anfitrin), no puede generar dominios con Solaris 9, por lo que lo
crearemos con Solaris 10 e instalaremos una zona en la versin 9. Ya que para la
prctica del proyecto slo es necesaria la migracin, obviaremos este proceso
que en su mayor parte es repeticin del que se acaba de ilustrar. Por eso
continuamos a partir de la siguiente situacin:

110

5.7

Creacin de imagen flar de Solaris 9

Un archivo flar (flash archive) es una imagen de sistema operativo. Esta imagen
es instalable y puede ser reinstalada en otras mquinas con el fin de lograr
sistemas iguales. Esto es de gran utilidad para, por ejemplo, JumpStarts, o para
nuestro fin, restaurar una imagen de Solaris 9 que crearemos para copiarla e
instalarla en nuestro servidor-destino de la migracin (todd-test1) en una
branded zone. De esta manera tendremos nuestra mquina disponible para
seguir dando servicio siendo compatible con un host anfitrin con Solaris 11.
En la mquina objetivo de migracin, corriendo el sistema Solaris 9, crearemos
el archivo flar

Con esto habremos creado nuestro fichero flar.

5.8

Instalacin de flar en todd-test1

Este fichero nos servir para migrar (clonar) la mquina en la que corre nuestro
aplicativo. Para ello, lo transferimos a nuestra mquina-destino (todd-test1) y lo
instalaremos.
Para poder instalar una zona en nuestra mquina debemos tener instalados los
siguientes paquetes: SUNWs9brandr, SUNWs9brandu, SUNWs9brandk
Los dos primeros vienen por defecto con la instalacin de Solaris 10, pero el
paquete SUNWs9brandk debe ser instalado manualmente. Hay que descargarlo
de la pgina de soporte de ORACLE, y slo est disponible con una licencia con
soporte. Descargamos el software Solaris Zone Containers en su versin 1.0.1
que es la necesaria para nuestra distribucin de sistema operativo.
Veamos lo que tenemos instalado:

111

Ahora instalamos el paquete necesario

Ya tenemos el software instalado por lo que podemos proceder a crear nuestra

zona donde despus instalaremos nuestro fichero flar.

5.8.1 Creacin de branded zone

Ya estamos en disposicin de crear nuestro container, que llamaremos Sol9destino.
Primero creamos la ruta en todd-test1 donde vamos a instalar la zona:

Ahora creamos la zona y la configuramos, mediante el comando zonecfg. Le

asignaremos la ruta, interfaz y mscara de red.

Luego comprobamos que todos los datos estn correctos y guardamos la

configuracin.
112

Ya tenemos nuestra zona creada aunque no est completa.

Ya podemos transferir el fichero flar que hemos creado en el punto anterior, lo

instalamos.

Como vemos, ya tenemos nuestra zona instalada, con el brand de Solaris 9.

Ahora podemos iniciar la zona para poder hacer login en ella. Una vez iniciada
estar en estado running.

113

Finalmente hacemos login desde la zona global a nuestra branded y ya estamos

en disposicin de utilizar nuestro aplicativo.

114

CONCLUSIONES

Con el desarrollo de este proyecto se ha podido demostrar una de las utilidades

que pueden tener la implantacin de infraestructuras virtualizadas,
concretamente nuestro modelo de virtualizacin de plataforma, y con dos tipos
diferenciados: paravirtualizacin (LDOMS), y virtualizacin a nivel de sistema
operativo con Solaris Zones.
Pese a que nos hemos enfocado en arquitectura SPARC, y Solaris, con estas
soluciones que nos ofrece, se pueden extrapolar algunas de las conclusiones a
otros modelos no estudiados en este proyecto.
Gracias a la tcnica utilizada, se proporciona a la infraestructura las claves para
una solucin exitosa: escalabilidad, flexibilidad, y un bajo coste con notable
mejora sobre un modelo no virtualizado.
Los servidores fsicos que ocupaban el CPD, son ahora mquinas virtuales,
completamente o casi completamente independientes. La flexibilidad es muy
grande debido a la facilidad para reorganizar nuestra red, migrado de mquinas
entre servidores fsicos, creacin de nuevas mquinas con plantillas
preconfiguradas, etc.
A parte de la ya innata escalabilidad de los sistemas SPARC, los entornos
virtualizados aumentan esta virtud, ms an con la asignacin dinmica de
recursos que ofrece Logical Domains. Y cuando los recursos disponibles no lo
permitan, siempre es ms sencilla la obtencin de un nuevo disco duro, o de un
mdulo de memoria que la adquisicin de un nuevo servidor completo.
El coste de implantacin de una infraestructura virtualizada, as como los gastos
de administracin y gestin a largo plazo, son mucho menores en comparacin
de un entorno no virtualizado. El suministro elctrico se divide por el nmero de
mquinas que aloja cada servidor anfitrin, y por lo tanto el gasto asociado a
ese consumo se divide tambin.
Adems, con respecto al rendimiento/coste, ORACLE con su cartera de
servidores en arquitectura SPARC, ofrece una relacin lder en el mercado,
unida a unos altos niveles de disponibilidad y gran seguridad y tolerancia a
fallos, indispensables para un entorno de criticidad mxima. Por otra parte,
Solaris es un sistema operativo completamente libre y gratuito, as como sus
soluciones de virtualizacin, lo que hace an ms atractiva la oferta.
En nuestro caso particular, partimos de un problema que debe ser solventado:
compatibilidad de software debido a la evolucin natural de los sistemas
operativos.
Salimos airosos consiguiendo esa compatibilidad con la solucin aplicada, unida
a los beneficios explicados anteriormente.

115

Aun as, no debemos olvidarnos de los problemas o desventajas que pueden

surgir a la hora de aplicar una solucin virtualizada, y que han sido detallados en
su captulo correspondiente: prdida de rendimiento, congestin de red, riesgo
en la organizacin al migrar servidores, nico punto de fallo del servidor
anfitrin, posible aumento de la complejidad de la administracin, etc.
Por todo esto es importante hacer un estudio previo para elegir un mtodo
idneo, en base a las necesidades de nuestro escenario. Aun as, las ventajas
son infinitamente superiores a los inconvenientes, y las tcnicas de
virtualizacin son tan amplias, que pueden solventar casi cualquier problema
que pueda surgir.
En nuestro caso, como hemos dicho, Solaris y sus soluciones de virtualizacin
nos resuelve un problema principal de compatibilidad, y nos aporta otros
muchos beneficios a una relacin coste/rendimiento muy alta.
En cuanto al impacto de la virtualizacin en el rendimiento del sistema, se
podra continuar con el trabajo haciendo estudios de rendimiento del sistema
antes y despus de virtualizar. Aproximadamente el impacto en el rendimiento
del software de zonas es menor de un 5%, pero podra ponerse a prueba el
sistema ante diferentes cargas de trabajo y sacar conclusiones al respecto tanto
por los containters como por los logical domains.
Tambin podran establecerse configuraciones ms avanzadas con zpools o
apuntando discos a cabinas de almacenamiento externas, o creacin de un
clster para poner a prueba las soluciones de ORACLE en caso de fallo.
Hay que dejar constancia, que la configuracin de la prctica no es la ms
adecuada.
Al tener instalada una versin de Solaris 11 en el host anfitrin en un servidor
SUNFIRE T2000.
Este servidor dispone de procesador T1, que no soporta las versiones actuales
de ORACLE VM for SPARC, por lo que hemos tenido que bajar a una versin del
software de virtualizacin muy anterior (Logical Domains Manager 1.2).
Solaris 11 no dispone de comando patchadd por lo que nuestro software de
virtualizacin no podr ser parcheado manualmente, y al no poder instalar una
versin posterior, no tenemos garantas de una total funcionalidad. Pese a
todo, en nuestra experiencia el comportamiento ha sido correcto y es vlido
para mostrar nuestra solucin.
Adems, no es compatible la creacin de container Solaris 9 directamente sobre
un host con Solaris 11, por lo que hemos tenido que utilizar un dominio lgico
invitado de ms.
Por todo esto, hubiera sido ms correcta una implementacin en un host
anfitrin con Solaris 10, pero por directrices del administrador de la mquina
fsica utilizada, nos hemos visto obligados a actuar as.
116

Aun as, esta configuracin es perfectamente vlida en escenario de laboratorio,

y nos sirve perfectamente para mostrar la solucin al problema.

117

118

BIBLIOGRAFA Y URLs
PFC Virtualizacin de servidores de telefona IP en GNU/Linux
Autor: Eugenio Eduardo Villar Fernndez
PFC ESTUDIO E IMPLEMENTACIN DE LA TCNICA DE VIRTUALIZACIN
EN LA DIRECCIN CENTRAL DE SERVICIOS COMPUTACIONALES, UTFSM
Autor: Alejandro Esteban Lara Molina
PFC Virtualizacin de servidores
Autor: Alex Mrquez
SystemAdministrationGuide: DevicesandFileSystems
Autor: Bill Calkins
SystemAdministration Guide: Solaris Containers-Resource Management
and Solaris Zones (Sun Microsystems)
Tutorial Solaris Zones Administration
Autor: Fahad Khalid
SystemAdministration Guide: BasicAdministration (Sun Microsystems)
SystemAdministrationGuide: AdvancedAdministration (Sun
Microsystems)
Guide to the Secure Configuration of Solaris 9 (National Security Agency)
NOVEDADES DE ORACLE SOLARIS 11 11/11 (ORACLE)
InstallingOracleSolaris11Systems (ORACLE)
Introducing Oracle Solaris 11 Express Whats New for System
Administrators (ORACLE)
Oracle Solaris 11 Frequently Asked Questions (ORACLE)
Oracle Solaris 11 Cheat Sheet General Administration (ORACLE)
Logical Domains 1.2 Administration Guide (ORACLE)
Servidores SPARC Enterprise M8000/M9000
Sun Advanced Lights Out Manager (ALOM) 1.6 Administration Guide (Sun
Microsystems)

SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers

Administration Guide (ORACLE)
http://codigounix.blogspot.com.es
http://sparcki.blogspot.com.es/ - Blog Solaris en castellano
SUNFIRE T2000 Server Administration Guide (ORACLE)
http://jjmora.es/ - Blog
https://docs.oracle.com numerosos vnculos
https://blogs.oracle.com numerosos vnculos

eXtended System Control Facility User's Guide (FUJITSU)

ORACLE Solaris 11 System Administration: The complete reference
Oracle Solaris Administration: Oracle Solaris Zones, Oracle Solaris 10
Zones, and Resource Management (ORACLE)
119

 Beginners Guide to Oracle VM Server for SPARC: Understanding and

Deploying Logical Domains (ORACLE)
http://www.unix.com
System Administration Guide: OracleSolaris Zones, Oracle Solaris 10
containers, and Resource Management (ORACLE)
Implementing Root Domains with Oracle VM Server for SPARC (ORACLE)

120

121