Página 1 de 146

Información ____________________________________________________________________________________ 8
Virtualización con VMware Arquitectura, proyecto, seguridad y feedbacks _____________________ 8
Prologo _________________________________________________________________________________________ 8
Introducción ___________________________________________________________________________________ 8
Agradecimientos _______________________________________________________________________________ 9
Virtualización de Sistemas de Información __________________________________________________ 9
Las diferentes áreas de aplicación de la virtualización ____________________________________________ 9
1. La virtualización de servidores ___________________________________________________________ 9
2. La virtualización del almacenamiento __________________________________________________ 11
3. La virtualización de las aplicaciones ____________________________________________________ 13
4. La virtualización de los puestos de trabajo ____________________________________________ 14
¿Por qué pasar a la virtualización? ______________________________________________________________ 14
1. Reducción de costes CAPEX/OPEX ______________________________________________________ 14
a. La compra de materiales tipo servidor ____________________________________________________ 15
b. Compra de hardware de red ______________________________________________________________ 15
c. Consumo eléctrico ________________________________________________________________________ 15
d. Necesidades en climatización _____________________________________________________________ 15
e. Consumo de espacio _____________________________________________________________________ 15
f. Error fatal ________________________________________________________________________________ 16
g. La copia de seguridad ____________________________________________________________________ 16
h. El aspecto seguridad _____________________________________________________________________ 17
2. La facilidad de despliegue y administración____________________________________________ 17
3. El material obsoleto y la gestión de cambio ____________________________________________ 19
El mercado de la virtualización __________________________________________________________________ 20
1. VMware (nuestra elección para este libro) _____________________________________________ 20
2. Citrix - XEN _______________________________________________________________________________ 21
3. Microsoft _________________________________________________________________________________ 21
4. Los aspirantes ____________________________________________________________________________ 22
El Proyecto de Virtualización _________________________________________________________________ 22
Preámbulo de un proyecto de virtualización _____________________________________________________ 22
1. Definición de la necesidad _______________________________________________________________ 22
2. La noción de perímetro __________________________________________________________________ 23
3. La auditoría preliminar __________________________________________________________________ 23
La definición del perímetro ______________________________________________________________________ 24
1. El enfoque por negocio __________________________________________________________________ 24
2. El enfoque por entidad lógica ___________________________________________________________ 24
3. El enfoque por estructura física _________________________________________________________ 25
4. Conclusión ________________________________________________________________________________ 25
Página 2 de 146
La auditoría preliminar y la influencia del histórico ______________________________________________ 26
1. Auditoría técnica _________________________________________________________________________ 26
2. Auditoría organizativa ___________________________________________________________________ 28
Los requisitos previos y las competencias requeridas ____________________________________________ 28
1. Un ROI/TCO aprobado al más alto nivel jerárquico ___________________________________ 28
2. Una sensibilización sobre la gestión de cambios ______________________________________ 30
3. La elección tecnológica material ________________________________________________________ 30
a. Fabricante de servidores _________________________________________________________________ 30
b. Fabricante del material de almacenamiento _______________________________________________ 33
Construcción de una Infraestructura ________________________________________________________ 34
Introducción __________________________________________________________________________________ 34
La capa de virtualización (Hipervisor) ___________________________________________________________________ 34
1. VMware ESX __________________________________________________________________________________ 34
2. Virtual SMP ___________________________________________________________________________________ 35
3. Virtualcenter __________________________________________________________________________________ 36
4. VMOTION ____________________________________________________________________________________ 37
5. VMware DRS __________________________________________________________________________________ 38
6. VMware HA ___________________________________________________________________________________ 39
7. VCB _______________________________________________________________________________________ 39
La arquitectura de VMware ESX 3 ______________________________________________________________________ 40
1. La Service Console _____________________________________________________________________________ 40
2. El VMkernel ___________________________________________________________________________________ 40
3. VMM ________________________________________________________________________________________ 41
4. Matriz de flujo ________________________________________________________________________________ 42
5. Las máquinas virtuales __________________________________________________________________________ 42
a. Definición___________________________________________________________________________________ 42
b. OS invitado _________________________________________________________________________________ 42
c. Los archivos de configuración ___________________________________________________________________ 42
d. Hardware virtual Maximal por VM _______________________________________________________________ 43
e. Las "vmware tools" ___________________________________________________________________________ 43
f. El almacenamiento y las máquinas virtuales ________________________________________________________ 43
g. Los snapshots ____________________________________________________________________________ 44
Las grandes orientaciones de arquitectura_______________________________________________________ 45
1. Arquitecturas orientadas a costes ______________________________________________________ 45
2. Arquitecturas orientadas a rendimiento ________________________________________________ 47
3. Arquitecturas orientadas a disponibilidad ______________________________________________ 47
Recursos y Virtualizacion ____________________________________________________________________ 48
La potencia de cálculo _______________________________________________________________________________ 48

Página 3 de 146
 1. Los procesadores ______________________________________________________________________________ 48
2. La elección de la asignación y la gestión vCPU _______________________________________________________ 49
3. Caso práctico __________________________________________________________________________________ 50
4. El principio de los "Shares" ______________________________________________________________________ 50
5. Intel VS AMD _____________________________________________________________________________ 50
La capacidad de memoria _______________________________________________________________________ 51
1. La capacidad total _______________________________________________________________________ 51
2. La sobreasignación ______________________________________________________________________ 51
3. La gestión transparente de páginas de memoria compartidas ________________________ 51
4. El Ballooning _____________________________________________________________________________ 52
5. El Swapping ______________________________________________________________________________ 53
El almacenamiento ______________________________________________________________________________ 53
1. Los cuatro tipos de almacenamiento ___________________________________________________ 53
a. SCSI LOCAL ______________________________________________________________________________ 53
b. Fibra óptica ______________________________________________________________________________ 54
c. iSCSI _____________________________________________________________________________________ 54
d. NFS ______________________________________________________________________________________ 55
2. El sistema de archivos VMFS ____________________________________________________________ 55
3. Raw Device Mapping _____________________________________________________________________ 56
La red ____________________________________________________________________________________________ 56
1. La conectividad a nivel físico _____________________________________________________________________ 57
2. La conectividad virtual __________________________________________________________________ 57
Seguridad y Virtualización ___________________________________________________________________ 62
Repaso de los grandes principios de seguridad _____________________________________________ 62
Reto nº 1: asegurar la disponibilidad de las infraestructuras virtuales ___________________________ 64
1. La alta disponibilidad de los servidores ________________________________________________ 64
2. La alta disponibilidad del almacenamiento _____________________________________________ 65
3. La alta disponibilidad de las máquinas virtuales y de las aplicaciones _______________ 66
4. La alta disponibilidad de la red _________________________________________________________ 68
5. La supervisión de la infraestructura virtual ____________________________________________ 69
a. La supervisión de los servidores hosts ____________________________________________________ 70
b. La supervisión del almacenamiento _______________________________________________________ 71
c. La supervisión de la red __________________________________________________________________ 72
d. La supervisión de los sistemas invitados, aplicaciones y servicios críticos _________________ 73
Reto nº 2: garantizar la integridad y la confidencialidad de los servidores VMware ESX __________ 74
1. El problema del aislamiento _____________________________________________________________ 74
a. Riesgo a nivel de la capa de virtualización ________________________________________________ 75
b. Riesgo a nivel de la capa de red __________________________________________________________ 77
Página 4 de 146
 c. Riesgo a nivel de la Service Console ______________________________________________________ 78
d. Riesgo a nivel de las máquinas virtuales __________________________________________________ 81
e. Riesgo a nivel de almacenamiento ________________________________________________________ 83
f. Riesgo a nivel de Virtualcenter ____________________________________________________________ 84
2. Autenticación y autorización ____________________________________________________________ 87
3. Las actualizaciones y las futuras protecciones _________________________________________ 89
Reto n°3: luchar contra las consecuencias inherentes de la virtualización ________________________ 90
1. La pérdida de la defensa perimétrica ___________________________________________________ 90
a. Bypass de las protecciones de red ________________________________________________________ 90
b. Detección de intrusiones obsoleta ________________________________________________________ 91
2. Pérdida de visión de la información ____________________________________________________ 91
3. La criticidad real de los hosts ___________________________________________________________ 92
Virtualización y Entornos Críticos ___________________________________________________________ 92
Introducción __________________________________________________________________________________ 93
¿Qué dificultades tiene la virtualización de entornos críticos? ____________________________________ 93
1. Primera dificultad: determinar las dependencias funcionales y técnicas_____________ 94
2. Segunda dificultad: la comprensión de interacciones _________________________________ 94
3. Tercera dificultad: encontrar métricas fiables _________________________________________ 95
¿Cómo determinar la elección de un entorno para la virtualización? _____________________________ 97
1. Determinar las características del entorno _____________________________________________ 98
2. Posicionar las posibles optimizaciones para responder a la necesidad_______________ 99
3. Buscar un feedback/recurrir a empresas especializadas _____________________________ 102
Dos testimonios sobre estudios y pruebas realizadas ___________________________________________ 103
1. Una aplicación para interacciones complejas _________________________________________ 103
2. Una aplicación que combina política, presupuesto y problemas técnicos ___________ 104
Virtualización y PRD _________________________________________________________________________ 104
El plan de recuperación ante desastres _________________________________________________________ 104
1. ¿Qué entendemos por PRD? ____________________________________________________________ 104
a. Definición _______________________________________________________________________________ 104
b. Los diferentes tipos de desastres ________________________________________________________ 105
c. RPO y RTO ______________________________________________________________________________ 106
2. El PRD: guía de proyecto _______________________________________________________________ 107
a. Fase 1: lanzamiento del proyecto de PRD ________________________________________________ 108
b. Fase 2: estudio funcional (BIA) __________________________________________________________ 108
c. Fase 3: auditoría de vulnerabilidades (BIA) ______________________________________________ 109
d. Fase 4: análisis de riesgos (BIA) ________________________________________________________ 109
e. Fase 5: presentación de soluciones ______________________________________________________ 110
La sinergia "Virtualización & PRD/PCA" _________________________________________________________ 110
Página 5 de 146
 1. El PRD con presupuesto reducido ______________________________________________________ 110
2. Superar el aspecto hardware __________________________________________________________ 111
3. La virtualización y el RPO/RTO ________________________________________________________ 112
4. Limitar la pérdida de datos _____________________________________________________________ 114
Casos de empresa _____________________________________________________________________________ 115
1. Ejemplo con VMware SRM ______________________________________________________________ 115
2. Caso clientes ____________________________________________________________________________ 118
Copia de Seguridad y Restauración _________________________________________________________ 118
La copia multinivel _____________________________________________________________________________ 118
1. La copia del Hipervisor _________________________________________________________________ 118
a. La copia de la Service Console ___________________________________________________________ 119
b. La copia de VMware ESX ________________________________________________________________ 119
c. La copia de la configuración de las máquinas virtuales ___________________________________ 119
2. La copia de Virtualcenter _______________________________________________________________ 119
3. La copia de las VM ______________________________________________________________________ 119
Los diferentes tipos de copia de seguridad _____________________________________________________ 119
1. La copia por agente _____________________________________________________________________ 120
2. La copia a nivel de imagen a través de agente ________________________________________ 121
3. La copia a nivel de imagen a través de VMware ______________________________________ 122
La optimización de la copia de seguridad _______________________________________________________ 123
1. La copia incremental____________________________________________________________________ 123
2. La copia diferencial _____________________________________________________________________ 125
3. La deduplicación ________________________________________________________________________ 126
Las soluciones de copia optimizadas para las VM _______________________________________________ 128
1. VCB ______________________________________________________________________________________ 128
a. VCB a nivel de archivos _________________________________________________________________ 128
b. VCB a nivel de imagen __________________________________________________________________ 128
2. Vizioncore vRanger _____________________________________________________________________ 129
3. Veeam Backup __________________________________________________________________________ 129
Futuros Retos y Evoluciones de la Virtualización __________________________________________ 130
El Provisioning _________________________________________________________________________________ 130
1. Definición ________________________________________________________________________________ 130
2. Las Templates ___________________________________________________________________________ 131
3. El Thin Provisioning _____________________________________________________________________ 131
La noción de soporte ___________________________________________________________________________ 131
1. ¿Por qué es un reto? ____________________________________________________________________ 132
2. ¿Cómo se orienta el mercado? _________________________________________________________ 132
La Capacity Planning _______________________________________________________________________________ 132
Página 6 de 146
 1. Las métricas fiables____________________________________________________________________________ 133
2. Anticipar a la evolución _________________________________________________________________ 133
Hacia una concentración de arquitecturas ______________________________________________________ 134
1. Las iniciativas de los fabricantes ______________________________________________________ 134
2. Nuevos actores… ¿la revolución ha empezado? ______________________________________ 135
¿Qué queda por mejorar? ______________________________________________________________________ 136
1. Hacia un Hipervisor integrado _________________________________________________________ 136
2. La estandarización ______________________________________________________________________ 137
3. El añadido de funcionalidades y el soporte de material ______________________________ 137
4. Virtualización y multimedia ____________________________________________________________ 138
La virtualización al alcance de las PYME ________________________________________________________ 139
1. SYSTANCIA ______________________________________________________________________________ 139
2. Neocoretech _____________________________________________________________________________ 139
El Cloud Computing ____________________________________________________________________________ 140
1. Definición ________________________________________________________________________________ 140
2. ¿Virtualización y Cloud Computing? ___________________________________________________ 140
3. Modo de facturación ____________________________________________________________________ 140
4. Ventajas/inconvenientes _______________________________________________________________ 141
5. Los actores de mercado del Cloud Computing ________________________________________ 142
GreenIT________________________________________________________________________________________ 142
1. Definición ________________________________________________________________________________ 142
2. Algunas cifras ___________________________________________________________________________ 142
3. Virtualización y GreenIT ________________________________________________________________ 143
4. Experiencia de GreenIT _________________________________________________________________ 144
5. ¿Qué futuro para el GreenIT? __________________________________________________________ 144
Primicia ________________________________________________________________________________________ 145
1. VMware vShield _________________________________________________________________________ 145
2. Cisco Nexus 1000v ______________________________________________________________________ 145

Página 7 de 146
Información
Virtualización con VMware Arquitectura, proyecto,
seguridad y feedbacks
Este libro sobre la virtualización con VMware se dirige tanto a directores de sistemas de información como a arquitectos
que deseen comprender el mundo de la virtualización.
Proporciona las claves para comprender mejor la gestión de este tipo de proyectos: retorno de la inversión, dificultades
de puesta en marcha,elecciones técnicas, visualización de objetivos que se quieran alcanzar,integración en el
entorno existente, consecuencias desde un punto de vista de seguridad, validez para arquitecturas y aplicaciones
críticas, aporte en el marco de planes de retoma de actividad (PRA).
El lector descubrirá igualmente la mirada crítica del autor sobre los diferentes actores del mercado, tanto desde un punto
de vista técnico como estratégico, lo que le aportará los elementos para hacerse las preguntas necesarias y forjarse
su propia opinión. Los feedbacks y las recomendaciones, de múltiples proyectos y despliegues piloto por el autor en
PYMES o grandes cuentas y realizados sobre VMware, completan e ilustran eficazmente todos los temas.
El libro comienza con una presentación del mercado de la virtualización y de lagestión de proyectos de
virtualización (los conceptos, retos, objetivos, etapas...). En los capítulos siguientes, el autor detalla el principio de
funcionamiento de una arquitectura virtual con VMware y los diferentes componentes que participan. El autor insiste en
los aspectos de seguridad que muy a menudo se dejan de lado y responde a numerosas preguntas que se plantean las
RSSI o cualquier otra persona encargada de la conservación de los activos de la empresa. En uno de los capítulos, el autor
demuestra lacomplementariedad de la virtualización con los planes de reanudación de actividad. Para finalizar, el
autor da su visión de futuro de la virtualización, gracias a sus muchas pruebas en primicia y a su fuerte interacción
con VMware y ecosistema de asociados.
Los elementos complementarios se pueden descargar desde esta página.

Philippe GILLET
Después de ser Consultor Senior en seguridad de sistemas de información, en los sectores bancarios, industriales y de las
telecomunicaciones, Philippe Gilletes hoy Director General de VIRTUALI, empresa líder en virtualización y seguridad de
sistemas de información. Por este motivo, interviene regularmente en misiones de auditoría y consultoría en estas áreas
y considera positivo compartir toda esta experiencia con los lectores de este libro. Muchas empresas han solicitado sus
servicios para arrancar grandes proyectos de virtualización, a menudo con el objetivo de reducir costes. Además, dispone
de prestigiosas certificaciones que acreditan su dominio en el área de la seguridad, la gestión de proyectos, la auditoría y
sobre todo de la virtualización: CISSP - Certified Information Systems Security Professionnel, CISA - Certified Information
Systems Auditor, CISM - Certified Information Security Manager et VMware Certified Professional.

Prologo
Introducción
Virtualización seguramente es una de las palabras más utilizadas actualmente en las empresas. Esto se debe a muchas
razones, siendo la principal los beneficios económicos que se pueden conseguir.

La virtualización parece ser la única solución viable a día de hoy para reducir realmente los costes relacionados con los
sistemas de información.

La virtualización tiene impacto sobre multitud de áreas: Sistemas - Aplicaciones - Almacenamiento - Redes y Seguridad.
Es por tanto muy importante, antes de abordar un proyecto de virtualización, conocer perfectamente los actores del
mercado e identificar el ecosistema asociado.

Dentro de unos años no nos preguntaremos si debemos virtualizar o no. Los expertos están de acuerdo sobre el tema:
la virtualización es un paso obligatorio para todas las empresas a corto o largo plazo.

Este libro se basa en VMware, líder indiscutible en el mercado de la virtualización. Su objetivo es orientarle lo mejor
posible en cada una de las etapas de su proyecto de virtualización y hacer que sus objetivos se cumplan a la perfección.
Mas allá de los aspectos puramente técnicos de los productos de VMware, este libro estudia el impacto organizativo de
la virtualización y las ventajas/inconvenientes descubiertos durante numerosos despliegues y consultorías realizadas por
el autor.

Como podrá ver, este libro contiene numerosos "feedbacks", con situaciones, necesidades y entornos sin ningún punto
en común, para ofrecer un panorama real de todas las problemáticas existentes.

Página 8 de 146
 El tema Seguridad será especialmente abordado enfocado a la virtualización, ya que durante mucho tiempo ha existido
una falta de información al respecto.

En último lugar, este libro ofrece una descripción general de lo que sucederá de corto a largo plazo: nuevos actores de
mercado, cloud Computing, greenIT, evoluciones funcionales, etc.

Por tanto, este libro está especialmente adaptado para arquitectos o para responsables de sistemas de información.

Agradecimientos
Me gustaría dar las gracias a muchas personas en este libro. A mi novia, Raphaelle, que me ha apoyado durante toda la
escritura. A mis padres y hermanas que me animaron en los malos momentos. Y finalmente a mis amigos y colaboradores,
que me ayudaron a finalizar este proyecto. Quiero agradecer particularmente a Franck, Virginie, Vanessa, Edouard,
Jacques, Yasser, Daniel, Fabrice, Philippe y muchos otros. Gracias igualmente a Sylvain Sioux de VMware por sus amables
correcciones.

También agradecer por adelantado a todos los lectores que me dejarán sus comentarios. Por favor, enviadme vuestros
emails a pgillet@virtuali.fr

Virtualización de Sistemas de
Información
Las diferentes áreas de aplicación de la virtualización

1. La virtualización de servidores
La virtualización es a día de hoy una de las palabras mas utilizadas en nuestras empresas. Sin embargo, pocas personas
saben que esta tecnología no es nueva en absoluto. Ésta data de los años ochenta, gracias a unos primeros trabajos de
IBM en la materia.

La virtualización no comenzó a interesar a todos los actores del mercado hasta después del año 2000, dos años después
del lanzamiento de la sociedad VMware y un año después de la salida de su primer producto: VMware Workstation 1.0.
¡El punto fuerte de VMware ha sido poner finalmente la virtualización al alcance de todos!

Por tanto, a VMware se le asocia con virtualización como a Microsoft se le asocia con OS (Operating System). Para
comprender la virtualización de servidores, debemos entender todas las sutilezas y la visión de VMware en este campo.

La virtualización es, según Wikipedia: «La unión de técnicas materiales y/o programas que permiten hacer funcionar
sobre una sola máquina varios sistemas operativos y/o varias aplicaciones, separadas unas de otras, como si funcionaran
sobre máquinas físicas independientes». Esta unión de técnicas es bastante amplia actualmente, lo que provoca mucha
confusión.

Los servidores son los primeros interesados en esta tecnología por muchas razones:

 Hasta ahora, la mayoría solamente eran utilizados de un 10 a un 15% en promedio. Los residuos son considerables,
sin duda, pero necesarios para garantizar la seguridad y el buen funcionamiento de las aplicaciones (principio
clásico de: «1 aplicación por 1 servidor»).
 Son monosistema. No se puede hacer funcionar dos sistemas operativos en paralelo. Un sistema debe gestionar
todos los recursos fisicos disponibles (que está lejos de ser el caso).
 Su proliferación es demasiado rápida. Hoy en día, el consumo de espacio y electricidad para los Datacenter es más
que crítico.
 Los servidores son cada vez más potentes (múltiples núcleos, capacidad de RAM, etc.).

El principio de virtualización de servidores es simple. Consideramos el servidor como un conjunto de recursos (CPU - RAM
- DISCOS - RED). Estos recursos son asignados de manera estática o dinámica a los servidores virtuales. Estos servidores
virtuales no ven los recursos que le son asignados y están aislados unos de otros. Un usuario, desde el punto de vista de
la red, no verá ninguna diferencia entre un servidor físico y uno virtual. De esta manera pueden coexistir múltiples
sistemas operativos en el interior del mismo servidor.

Página 9 de 146
 Virtualizar servidores no es tan simple desde un punto de vista técnico. Hay que tener en cuenta que los sistemas
operativos no están concebidos originalmente para ser virtualizados (cosa que parece lógica, ya que la virtualización es
un fenómeno reciente). Los sistemas operativos están habituados a comunicarse al más bajo nivel con el hardware (lo
que garantiza mejor un rendimiento).

La virtualización ha existido desde hace tiempo de una forma algo diferente mediante el uso de mainframes (VM/CMS
por ejemplo).

En el enfoque de la virtualización de servidores X86, es la capa de virtualización la que debe comunicarse con el hardware
(es decir, a más bajo nivel). Esto plantea un problema evidente: ¿como puede el sistema operativo virtualizado
comunicarse al más bajo nivel ahora que ya no tiene acceso?

Varios planteamientos son posibles:

 Hacer creer al sistema operativo virtualizado que se encuentra en el nivel más bajo (será necesario interceptar
todas las comunicaciones y modificarlas sobre la marcha).
 Modificar el sistema operativo virtualizado para que no necesite comunicarse al más bajo nivel (funciona
correctamente, pero ¿qué pasa con el soporte?).
 Dejar que el sistema operativo virtualizado se comunique a veces directamente, a veces indirectamente mientras
le permite al hardware comunicarse con la capa de virtualización (esto implica un conocimiento del sistema de
virtualización y un uso de funcionalidades de virtualización nativas a nivel de hardware).

Todos estos planteamientos tienen ventajas e inconvenientes. La última parece lógicamente la que asumirían los
proveedores de hardware que también quieran invertir en el mercado de la virtualización. Recientemente, Intel ha lanzado
unos procesadores con una opción llamada VT (Virtualization Technology). AMD tambien está en desarrollo de AMD-V
(AMD Virtualization).

La virtualización de servidores tiene muchas ventajas:

 El mantenimiento de hardware, el consumo eléctrico y las necesidades de espacio y climatización se dividen de

forma considerable.
 La compra de material ya no es un imperativo para cada implementación.
 El hardware obsoleto se queda en un recuerdo.
 La seguridad no está dispersa de manera aleatoria.
 La compra de componentes de red se reduce (las comunicaciones pueden hacerse dentro de la máquina virtual).
 Los errores no son fatales (posibilidad de marcha atrás).
 Las copias de seguridad son menos complejas (las máquinas virtuales no son más que simples archivos).
 Se eliminan prácticamente todas las problemáticas de la implementación.
 Es posible crear arquitecturas de alta disponibilidad.
 Se facilita la gestión de cambios.
 La supervisión en tiempo real se lleva a cabo de una forma mucho más simple.

Página 10 de 146
 Este libro está principalmente enfocado a la virtualización de servidores ya que es la etapa más importante
de cualquier proyecto de virtualización de infraestructura y es la que actualmente está más desarrollada.

2. La virtualización del almacenamiento

La virtualización del almacenamiento es un área de la virtualización que sigue siendo controvertida. Los actores del
mercado tienen planteamientos muy diferentes. Cada uno hace el suyo, lo que provoca que todo sea incomprensible para
el resto de los mortales.

He aquí la definición que parece más adecuada en este momento:

La virtualización del almacenamiento consiste en abastecerse de almacenamiento físico y descomponerlo en

almacenamiento de carácter lógico. La virtualización del almacenamiento permite actuar de manera independiente a la
localización física de los datos creando un espacio lógico de almacenamiento.

Aunque pueda parecer impresionante, es una operación que se lleva a cabo en cualquier sistema operativo. Windows
posee su LDM (Logical Disk Manager) y Linux/UNIX su LVM (Logical Volume Manager). La virtualización aquí consiste
simplemente en utilizar una capa de software que permita interceptar las E/S que hará creer al sistema operativo casi
cualquier cosa.

La virtualización del almacenamiento también afecta a algunos elementos del almacenamiento dedicado, como las NAS
o las SAN. Los actores del almacenamiento han comprendido también los retos de la virtualización. Así, cada uno ha
desarrollado su propia tecnología para poder crear espacios lógicos de datos.

Página 11 de 146
 La combinación de muchos elementos de almacenamiento puede dar lugar a un espacio lógico de datos (o LUN: Logical
Unit Number) con capacidades escalables (el añadido de elementos de almacenamiento se realiza de forma transparente
en el espacio lógico y aumenta la capacidad total). Los fabricantes incluyen cada vez más esta capa de virtualización.
Esto permite mejorar día a día el espacio de almacenamiento y el reparto de E/S. Además, permite resolver problemáticas
relacionadas con la evolución. La capacidad de almacenamiento no dependerá de la capacidad física de un elemento, sino
únicamente de la restricción presupuestaria.

Además, no dependiendo de la noción física, es posible imaginar espacios lógicos de almacenamiento en arquitecturas
alrededor de diferentes fabricantes. Así, será cada vez mas común ver programas dedicados a la gestión de espacios de
almacenamiento lógicos durante su ciclo de vida.

Página 12 de 146
 Las ventajas de la virtualización de almacenamiento son muy numerosas:

 Las limitaciones materiales ya no existen. No hay que preocuparse por el fabricante y su interoperatibilidad.
 La evolución se realiza de manera transparente para los sistemas y usuarios.
 Se hace más fácil llevar a cabo las operaciones de replicación o de sincronización.
 La granularidad está mucho más avanzada (posibilidad de optimizar de una manera más fina).
 Las restricciones presupuestarias se pueden adaptar de acuerdo al rendimiento deseado (almacenamiento puro,
archivaje, Bases de Datos, etc.).

3. La virtualización de las aplicaciones

La virtualización de las aplicaciones existe actualmente gracias a un pionero del mercado: CITRIX (ahora llamado XEN).
Sin embargo, la virtualización de aplicaciones se encuentra todavía en la infancia. Es por eso que coexisten muchas
soluciones que funcionan de manera diferente.

 La virtualización de aplicaciones puede consistir en publicar una aplicación instalada en un servidor hacia un equipo
cliente. En este último caso, la aplicación no es más que un acceso directo a la aplicación instalada en el servidor.
Todo se ejecuta en el lado servidor en lugar de en el lado cliente. La pantalla de resultados o la interfaz se
mostrarán del lado del usuario. Las ventajas son evidentes:
 Los clientes no realizan los cálculos pesados.
 Se evitan problemas de compatibilidad.
 Las instalaciones defectuosas son imposibles (nada se instala localmente).
 Las actualizaciones están centralizadas y no es necesario realizar ninguna modificación en el lado de los
clientes.
 La carga de red se reduce.

 La virtualización de aplicaciones puede también consistir en la ejecución de software en un contexto particular. Por
ejemplo, podemos imaginar ejecutar una aplicación gráfica sobre Windows XP como si se ejecutara sobre
Windows NT4. VMware destaca este aspecto con su producto ThinApp. Las ventajas son las siguientes:
 No existen conflictos entre sistema, dll, etc. Los paquetes creados son más o menos autónomos
dependiendo de la necesidad y del propio contexto.
 Las aplicaciones antiguas pueden ser ejecutadas en máquinas recientes y beneficiarse del rendimiento de
la máquina que las ejecuta.
 Las aplicaciones se benefician de una mayor seguridad ya que se ejecutan en un contexto restringido
(principio de sandbox).
 Provoca poco impacto en la red.
 Las actualizaciones también se centralizan.

Página 13 de 146
XenAPP también ofrece este modo desde hace poco (aunque las diferencias son substanciales).

4. La virtualización de los puestos de trabajo

La virtualización de los puestos de trabajo es la evolución lógica de la virtualización de los servidores. Ya que los servidores
son potentes, capaces de ejecutar entornos aislados (Máquinas Virtuales) y fáciles de crear rápidamente, ¿por qué no
implementar los puestos de trabajo sobre servidores y visualizar lo que suceda en una máquina virtual a través de simples
clientes ligeros?

Las ventajas son evidentes:

 Nada se hace en local. La carga está repartida en los servidores (potencia asegurada).
 Los puestos de trabajo no dependen del hardware (se acabaron las reparaciones, los cambios de PC, las
actualizaciones de hardware, etc.).
 El riesgo de fugas de información está más controlado (ningún dato se almacena en local).
 Es posible evitar el vandalismo o el robo (el terminal solamente se conecta). Por si solo, no sirve para nada y no
es caro.
 El consumo eléctrico se reduce.
 No es necesario comprar o actualizar el hardware.

¿Por qué pasar a la virtualización?

1. Reducción de costes CAPEX/OPEX

La reducción de costes es un lema extremadamente importante, sobre todo en periodos de recesión... La virtualización
es una tecnología que permite realizar ahorros substanciales, pero es conveniente conocer si estos empiezan a verse a
corto o largo plazo.

Las empresas distinguen entre 2 tipos de costes:

 CAPEX (Capital Expenditure): corresponde a los gastos relacionados con inversiones y capital (por ejemplo:
hardware, software, etc.).
 OPEX (Operational Expenditure): corresponde a los gastos relacionados con el funcionamiento de la empresa (por
ejemplo: expertos, servicios, consultoría, gestión de proyectos, etc).

Página 14 de 146
 He aquí algunos feedbacks sobre proyectos de virtualización llevados a cabo en diferentes entornos y que han ayudado
a reducir gastos (los nombres de los clientes no se citan):

a. La compra de materiales tipo servidor

Durante los proyectos de virtualización, el principal ahorro visible de inmediato es lo que tiene que ver con la compra de
servidores. Este ahorro está expresado en factor (por ejemplo: factor 6 significa que una máquina alojará 6 máquinas
virtuales). En ese caso, los ahorros se pueden calcular. Los costes de material se dividen por 6.

Esta división está muy simplificada y no considera los costes de gestión de la virtualización día a día. Hay que tener en
cuenta otros aspectos causados por la virtualización. Anteriormente, un servidor físico podía tener varios roles (lo que
desde el punto de vista de la seguridad siempre estaba mal visto). Con la virtualización, cada máquina virtual tiene un
rol único (en todo caso, hay que esperar que eso será así…). El factor 6 está distorsionado en nuestro ejemplo y es mejor
trabajar con un factor inferior.

Por otro lado, hace falta considerar la noción de las licencias de software. La multiplicación de las máquinas virtuales
multiplica igualmente la cantidad de licencias, que aumenta considerablemente el precio total. Esto también reduce el
factor 6 de nuestro ejemplo.

En resumen, la compra de material se reduce en gran medida (algunos proyectos nos han llevado a trabajar con factores
20), pero evidentemente se deben integrar también todas las nociones subyacentes.

b. Compra de hardware de red

La compra de componentes de red se reduce en gran medida gracias a la virtualización. Teniendo en cuenta que las
máquinas virtuales son capaces de comunicarse a través de un mismo host físico, no se necesita ningún componente de
red (switch o router). Además, las máquinas virtuales normalmente están conectadas desde la misma tarjeta de red o
agrupadas sobre la misma interfaz, lo que permite economizar en la compra de componentes de red suplementarios.

c. Consumo eléctrico

En un momento en que la ecología se ha convertido en una prioridad, el ahorro energético es una manera de desmarcarse
de los competidores (sobre todo en el sector del automóvil). La ola verde también afectó al sector de los sistemas de
información. Los fabricantes anuncian reducciones del consumo y servidores sin metales pesados (normas RoHS), etc.

La virtualización es una tecnología que permite reducir el consumo eléctrico considerablemente. En el ejemplo anterior,
el consumo eléctrico se reduce por 6. Del mismo modo, este cálculo es demasiado simplista. Los servidores integran
actualmente tecnologías integradas, en los procesadores por ejemplo, que permiten regular el consumo eléctrico en
función de la carga. En nuestro caso, la virtualización aumenta en gran medida la carga de los servidores, lo que deja
estas tecnologías obsoletas.

El factor 6 del ejemplo tiene que tomarse entonces con precaución.

d. Necesidades en climatización

Las necesidades en climatización tienen que ver al consumo energético. Si el consumo baja gracias a la virtualización,
pasará lo mismo con las necesidades de climatización. Sin embargo, un problema se hace evidente rápidamente. Un
Datacenter que aloje infraestructuras virtuales tendrá una carga dinámica y móvil. Dinámica, porque la concentración de
más máquinas virtuales sobre un host físico aumenta el riesgo de la carga. Móvil, porque la carga puede moverse de una
plataforma a otra (gracias al reparto de cargas).

La necesidad de climatización debe entonces adaptarse a estas restricciones, cosa que no es fácil. Se necesitará una
climatización adaptable a la carga, e igualmente capaz de refrigerar localmente, dependiendo del consumo energético.

e. Consumo de espacio

El consumo de espacio es una desventaja mayor en un Datacenter ya que el espacio no se extiende hasta el infinito, y
es extremadamente caro de mantener. Éste es el caso en las PYMES, donde el espacio está reservado en primer lugar a
los empleados, y la informática se suele encontrar mal ubicada.

Las necesidades de espacio se ven ampliamente reducidas gracias a la virtualización, ya que la necesidad de hardware
es muy inferior a la que había anteriormente.

Sin embargo tenga cuidado, ya que muchas empresas, después de haber entendido que se podía integrar todo en un
espacio reducido, han decidido concentrarlo todo, con riesgo de perder todo el entorno en caso de un problema mayor
(de hecho, la virtualización aumenta la criticidad de los servidores). Esta noción se verá ampliamente en el capítulo
dedicado a la seguridad.

Página 15 de 146
f. Error fatal

Aunque los errores están permitidos, es conveniente evitarlos en la medida de lo posible, sobre todo en los entornos
críticos. Es por ello que desde que apareció la informática existen las copias de seguridad.

Desafortunadamente, las copias de seguridad son molestas por su pesadez. Algunas veces hacen falta hasta 48 h para
restaurar un simple archivo o una semana para restaurar un sistema (siempre que sea posible...). ¿Quién no ha tenido
miedo de ejecutar un comando con efecto aleatorio como «root»? ¿Quién no tiembla ante la migración de un Active
Directory? Los productos son, según los vendedores, todos más milagrosos que los demás. Cierto... pero hay que ser
realista. Los usuarios están constantemente bajo presión y ¡no pueden conocer todos los pros y contras de un comando
o una solicitud!

Los usuarios normalmente sueñan con: poder volver atrás en todo momento, ¡y con seguridad! La virtualización puede
al fin cumplir sus deseos.

En efecto, gracias a la virtualización, es posible volver atrás a un instante T (siendo T el momento presente) -X (siendo
X un punto preciso en el tiempo). Esta manipulación es simple y rápida. Sólo hace falta pensar en el célebre [Ctrl] Z de
Windows que permite deshacer los cambios.

Aunque esta tecnología es fantástica, también tiene consecuencias. Una persona puede querer deshacer un cambio en
las modificaciones del sistema, pero no forzosamente en los datos almacenados. Sin embargo, cuando se restaura un
sistema a un instante T - X, los datos almacenados en el sistema son restaurados a ese preciso instante. Para una base
de datos, eso puede tener consecuencias catastróficas.

Por lo tanto, es una tecnología extremadamente práctica que convendrá dominar perfectamente antes de creer que el
milagro podrá producirse sin problemas...

g. La copia de seguridad

En ocasiones, la copia de seguridad está considerada por los expertos como un proyecto complejo que depende del
entorno y de la herramienta de copia seleccionada. Es verdad que en cierta manera depende bastante de los sistemas
operativos presentes y de las aplicaciones instaladas. Las empresas han entendido rápidamente que es posible vender
licencias suplementarias adaptadas a nuestras aplicaciones. Una vez se haya seleccionado la herramienta de copia de
seguridad, será difícil dar marcha atrás. Así, el cliente está obligado a pedir licencias de uso para poder utilizar, por
ejemplo, los agentes Exchange, MSSQL, Oracle, Sharepoint, etc.
Página 16 de 146
 Esto ha contribuido a hacer los proyectos de copia de seguridad impopulares; algo lógico porque tienen tanto gasto desde
un punto de vista financiero, que es difícil justificar todos los costes para la mayoría de la gente (responsables y
financieros por ejemplo).

La virtualización simplifica los procesos de copia de seguridad por la siguiente razón: los sistemas son vistos como simples
archivos. Así, la copia de seguridad de un sistema operativo tipo Microsoft, por ejemplo, se hará como una copia de un
archivo clásico. No habrá licencias suplementarias, restricciones de sistemas o actualizaciones de los agentes (salvo por
la capa de virtualización... aunque ésta no cambia muy a menudo). La operación es tan simple como un copiar-pegar.

La solución parece perfecta, sin embargo, después de muchos feedbacks de los clientes, la realidad no era tan buena
como inicialmente se anunció, por varias razones:

 Las máquinas virtuales se ven como simples archivos, y es imposible distinguir los datos de sistema de una máquina
virtual (salvo que las hayamos creado de forma inteligente...).
 Las aplicaciones de tipo transaccional o que generan mucha entrada/salida necesitan además un agente en la
máquina virtual para no perder ningún dato (ésa es también la recomendación de los desarrolladores en el área
de la virtualización).
 La copia de seguridad puede generar un mayor impacto en los servidores. Estos están mucho más cargados, y
pueden llegar a su límite durante el tiempo dedicado a la copia de seguridad.
 La copia de seguridad de máquinas virtuales ofrece poca granularidad. Es difícil restaurar un simple archivo en una
máquina virtual. La tendencia es, entonces, dejar un agente en las máquinas virtuales únicamente para la copia
de seguridad de los datos.

En conclusión:

Gracias a la virtualización, la copia de seguridad es más segura, ya que los sistemas se copian fácilmente. Sin embargo,
esto complica los proyectos de copia de seguridad. Los fabricantes trabajan en este área para poder simplificar la copia
de seguridad de los entornos virtuales y es esta razón por la que han aparecido pequeñas empresas desmarcándose de
los fabricantes tradicionales: VizionCore, Veeam, etc.

No cabe duda de que estas empresas recibirán rápidamente sus propuestas de compra... Mientras tanto, ¡es aconsejable
ir comprobando sus soluciones!

h. El aspecto seguridad

La seguridad es mucho más que un simple proyecto. De hecho, es primordial para la vida de la empresa.

Gracias a la virtualización, es posible reforzar la seguridad (o destruirla... es un arma de doble filo).

Un capítulo completo está dedicado a la seguridad en la virtualización.

2. La facilidad de despliegue y administración

El despliegue de servidores nuevos o de nuevas aplicaciones suele ser problemático en las estructuras medianas y
grandes. Los diferentes actores contribuyen (sin querer) a ralentizar el proceso de integración.

Veamos un pequeño esquema que resume de forma (un poco) exagerada un proceso de integración clásico:

Página 17 de 146
 La virtualización permite facilitar en gran medida este proceso. Por un lado, el hardware no debe comprarse ya que es
suficiente con crear una nueva máquina virtual. Por otro lado, esto puede hacerse rápidamente de manera automatizada.
Antes, la integración podía tardar varios meses. Ahora unas bastan cuantas horas...

Sin embargo, no hay que pensar que el coste de despliegue es nulo, ya que también necesita licencias y recursos. ¡La
dirección financiera es entonces un actor importante antes de cualquier despliegue! Sin embargo, de la misma manera
que es fácil cuantificar los gastos del material físico, será difícil cuantificar los de los recursos virtuales...

Trabajar de acuerdo con las direcciones financieras es una prioridad para que puedan construir sus métricas
válidas en un contexto técnicamente avanzado.

La administración de los entornos virtuales también es una ventaja. Con ella es posible supervisar todas las máquinas
virtuales para saber cuánto consumen y comprender sus modos de funcionamiento (ver el capítulo Virtualización y
entornos críticos).

Página 18 de 146
3. El material obsoleto y la gestión de cambio
Según Wikipedia , la obsolescencia es el hecho de que un producto llegue a su vencimiento, y por tanto pierda todo su
valor, desde el punto de vista de la evolución tecnológica o de la moda, aunque el producto esté en perfecto estado de
funcionamiento.

Esta noción aparece muy a menudo en el sector de los sistemas de información. Toda empresa tiene un ciclo de vida de
material y de aplicaciones. Tomemos un ejemplo concreto. Muchas empresas aún tienen aplicaciones funcionando sobre
Windows NT4 o Windows 2000. Si sus servidores dejaran de funcionar, ningún hardware actual sería capaz de soportar
hoy en día esos sistemas. Por poco que esas aplicaciones sean críticas, las personas a cargo prácticamente rezan cada
día para que los servidores no tengan un colapso. La migración de estas aplicaciones hacia un entorno virtual puede
resolver esta problemática. El hardware que soporta los antiguos sistemas virtualizados es reciente. Aunque los
fabricantes ya no den soporte a estos sistemas, permanecen estables en el material soportado. Esto no resuelve los
problemas de actualización, de soporte de fabricantes, etc., pero contribuye a dar un respiro a las empresas para no
tener que precipitarse en un nuevo desarrollo total de sus aplicaciones, que costaría una fortuna.

La obsolescencia de material es mucho más reducida ya que las máquinas virtuales son independientes del aspecto
material. Así, la migración de un servidor «obsolescente» a un servidor más reciente no supondrá ningún problema y se
realizará de una forma totalmente transparente.

Sin embargo, hay que imaginar la evolución de las infraestructuras virtuales en el futuro. Las máquinas virtuales no
tienen porqué ser forzosamente interoperativas entre los diferentes editores y no está garantizado (aunque esto sea una
contradicción desde un punto de vista comercial) que las máquinas virtuales de un mismo editor (VMware, XEN, Microsoft,
etc.) sean compatibles de una versión a otra.

Además de la gestión de cambios, la virtualización aporta muchas mejoras.

La gestión de cambios es uno de los seis procesos de la parte "Servicios de apoyo" de buenas prácticas ITIL.

Un cambio consiste en modificar, crear o suprimir uno de los componentes de la infraestructura de un sistema de
información (programa, aplicación, equipamiento, material, configuración, documentación, procedimiento, etc.).

La virtualización permite gestionar los cambios más fácilmente. El ciclo de vida de una máquina virtual está controlado
de una manera mucho más fácil. Además, se puede eliminar material de forma transparente, lo que contribuye a mejorar
la gestión del ciclo de vida del material.

Un ejemplo sobre la gestión de cambios en un entorno virtualizado:

Página 19 de 146
 La empresa en cuestión forma parte del sector industrial, y ha instalado una infraestructura virtual utilizando los miles
de servidores físicos sobre ESX. La empresa cuenta con alrededor de 2.000 personas dedicadas a la gestión de SI
(Sistemás de Información). Los administradores disfrutan, después de muchos años, de las ventajas de la virtualización.
En poco tiempo, el entorno cuenta con unas 10.000 máquinas virtuales. Alrededor de una tercera parte de ellas son las
que realmente se utilizan. Eso les conduce a decidir si realizar o no una gestión de cambios real. Este proyecto fue muy
instructivo.

A partir de cierto nivel, realizar un auténtico proceso de industrialización de la virtualización se convierte en una
necesidad. El proyecto consistió en realizar una gestión del ciclo de vida de las máquinas virtuales.

Por ejemplo, una máquina virtual debe, obligatoriamente:

 Tener un coste fijo calculado según diversos criterios.

 Pasar por un proceso de validación (a nivel financiero y técnico).
 Estar creada por un usuario formado.
 Estar aprobada por los equipos a cargo de la validación técnica: seguridad, sistemas, redes, aplicaciones, etc.
 Estar desplegada con un EOL (End Of Life) específico.
 Ser archivada o destruida según demanda de su EOL.

El mercado de la virtualización

1. VMware (nuestra elección para este libro)

VMware, sociedad comprada por EMC en 2004, es a día de hoy la sociedad líder en la virtualización. Ellos fueron los
primeros en imaginar la virtualización sobre máquinas clásicas tipo X86, y a ellos les debemos las primeras versiones de
VMware Workstation que transformaron nuestra forma de probar las aplicaciones y los sistemas operativos.

Algunas cifras de la sociedad VMware:

Creación: 1998, comprada por EMC en 2004, entró en bolsa en agosto de 2007 (NYSE:VMW)

Volumen de negocio: 1330 millones de dólares

Clientes: 120.000, de los cuales el 100% son de la lista de empresas de Fortune 100

Empleados: más de 6.300

Central: Palo Alto, California, Estados Unidos

Oficinas: 36 oficinas en todo el mundo

Partners: 19.000

VMware es una sociedad en busca constante de la innovación. Ellos lanzaron la noción de alta disponibilidad de máquinas
virtuales o la de reparto dinámico de cargas, etc. VMware es una sociedad que busca llegar cada día más lejos. Han sido
además hábiles al crear una auténtica comunidad de apasionados. Gracias a esto, VMware ha sido un éxito. Los usuarios
suelen ser miembros activos que buscan compartir la experiencia de la virtualización.

Han lanzado numerosas iniciativas:

VMTN: un foro que consiste en una base de datos gigantesca para todos los que busquen:

 arreglar problemas técnicos,

 experiencias de uso,
 sugerir mejoras de los productos de VMware.

VMMARK: un sitio dedicado a los resultados de tests obtenidos de la virtualización. El principio consiste en tomar las
arquitecturas representativas y efectuar tests de carga (http://www.vmmark.com).

VROOM: uno de sus numerosos blogs de VMware dedicado a las pruebas de rendimiento
(http://blogs.vmware.com/performance/)

VMware Security Blog: blog dedicado a la seguridad de los entornos virtuales (http://blogs.vmware.com/security/)

http://www.vmware.com/events: los eventos organizados por VMware.

Los libros blancos: http://www.vmware.com/technical-resources

Página 20 de 146
 Los documentos técnicos: http://www.vmware.com/resources/techresources/

Hemos elegido VMware en este libro por muchas razones:

 Es el único sistema de virtualización completo que actualmente posee experiencia suficiente de clientes.
 Es el sistema de virtualización más avanzado, tecnológicamente hablando, y que posee un historial considerable.
 VMware posee soporte de usuario y una comunidad inigualable. El entusiasmo suscitado a partir del año 2000
nunca se ha perdido y la comunidad se extiende cada día.
 Los productos dedicados a producción (actualmente ESX 3.5 y ESXi) son los únicos del mercado capaces de superar
las pruebas de cualificación y validación más exigentes (pruebas de carga, validación de hardware, etc.).
 La empresa es más que rentable y es improbable que desaparezca a corto plazo (aunque el contexto económico
global actual no sea favorable...).
 VMware posee un número de aliados y partners inmenso, prueba de su saber hacer en marketing y comercial.
 Desde el punto de vista de la seguridad, VMware es la única sociedad que realmente se pronuncia sobre el tema.
Existen documentos muy precisos desde un punto de vista técnico identificando las buenas prácticas de seguridad
para los entornos virtualizados y las plataformas de alojamiento (veremos próximamente llegar la API VMSAFE y
VSHIELD).
 VMware posee una visión estratégica a largo plazo. El grupo se ha pronunciado poco al respecto, pero todo apunta
a creer que actualmente desarrolla un ecosistema de software dedicado a la gestión de futuros Datacenter (como
Cisco...). Igualmente piensan impulsar el fenómeno del Cloud Computing.

2. Citrix - XEN
XEN es un hipervisor de máquinas virtuales, desarrollado por la comunidad Open Source, que permite hacer funcionar
varios sistemas operativos sobre la misma máquina host. La sociedad XenSource es la que en gran medida ha contribuido
en XEN, que fue comprado por Citrix en 2007.

XenServer es un tipo de producto llamado paravirtualización.

La paravirtualización significa que las máquinas virtuales son conscientes de que no se ejecutan sobre una arquitectura
de hardware clásico. Por tanto, es necesario adaptar las máquinas virtuales para que se puedan ejecutar correctamente.

Contrariamente a VMware, XEN no emula una arquitectura hardware completa por cada máquina virtual. Sólo el acceso
a los recursos está virtualizado, cosa que teóricamente permite aumentar el rendimiento. Hay que tener en cuenta que
XEN no permite utilizar máquinas virtuales Windows sin el soporte de la virtualización hardware Intel-VT y AMD-V. Este
detalle no es necesariamente un problema, ya que todos los servidores recientes incorporan procesadores con estas
capacidades.

Citrix es, desde hace mucho tiempo, líder en el mundo de la virtualización de aplicaciones. Tienen un modelo económico
muy diferente: Citrix se ha convertido en la competencia sobre el sector de la virtualización de servidores X86 (con los
productos XEN) a la vez que ellos mismos son los dueños de la virtualización de aplicaciones (en todo caso desde cierto
enfoque, que parece cada vez más consistente para muchos expertos).

Citrix tendrá que trabajar su oferta de virtualización de servidores además de rediseñar la de virtualización de
aplicaciones. El reto es enorme pero no imposible. Los desarrolladores de CITRIX trabajan duro en la virtualización de
aplicaciones y en su nueva y rebautizada plataforma XenApp (prueba que la compra de XEN también inducirá cambios
en sus productos de virtualización de aplicaciones, que antes se llamaban CITRIX Presentation Server).

La oferta de virtualización de servidores: XenServer, también ha tenido un fuerte impulso. Se han establecido muchas
asociaciones, y Xen se va a beneficiar de los comerciales y equipos de marketing de Citrix. Además, Xen ha sido durante
mucho tiempo un producto Open Source, con lo que se han unido a su alrededor muchos usuarios y desarrolladores
apasionados; no ha llegado a tener la popularidad de VMware, pero la base parece muy sólida.

3. Microsoft
Windows Server 2008 Hyper-V es el motor de virtualización (hipervisor) previsto en Windows Server 2008.
Lamentablemente, Microsoft se perdió la tecnología de la virtualización. Las primeras versiones de su software de
virtualización Virtual Server 2005, no convencieron en absoluto al público. Estas son las razones que expresan los
expertos:

 Falta de comunicación sobre el tema. Microsoft no orientó su estrategia sobre la virtualización sino que produjo un
producto tipo «wait for better days», es decir, un producto que busca demostrar que Microsoft trabaja en la
virtualización pero que habrá que esperar a futuras versiones antes de poder poner alguna en producción.
Desgraciadamente, en este momento, VMware ya posee versiones dedicadas al mundo de la producción...
 Contiene un gran número de «bugs» y menor rendimiento.

Página 21 de 146
  La imposibilidad de utilizar otros sistemas salvo los de Microsoft (en el caso de que sea soportado).
 La gestión de máquinas virtuales (nada práctica y controvertida).

Por tanto, Microsoft quiere volver a la delantera del escenario y cuenta con llegar hasta allí además de haber ganado la
de Internet (con el intento fallido de compra de Yahoo, etc.). La maquinaria de guerra de marketing de Microsoft está
bien engrasada y tiene un impacto mucho mayor que sus competidores en las empresas. Además, Microsoft tiene
argumentos de peso:

 La coherencia de entornos Microsoft no puede estar asegurada… salvo por Microsoft (noción de homogeneidad
buscada por las DSI).
 El precio de las licencias y la integración nativa en Microsoft Windows Server 2008.
 El soporte de máquinas virtuales Microsoft será mejor, por fuerza, si la herramienta que proporciona la
virtualización está proporcionada... por Microsoft (problemática de soporte en entorno virtualizado).
 Los partners, integrantes y constructores soportarán mucho mejor las iniciativas de Microsoft, por razones político-
tecno-financieras.

Sin embargo, Microsoft tiene muchos retos por delante:

 La pesadez de su hipervisor (un Hyper-V compacto tipo VMware ESXi es improbable por el momento).
 La seguridad del hipervisor (que será por fuerza sensible a las vulnerabilidades de Microsoft).
 Retomar la confianza de los clientes potenciales poco a poco. Sabemos que los productos no suelen tener una
segunda oportunidad en el mundo de los sistemas de información…
 La gestión de su hipervisor y de su evolución sobre una gama de productos Microsoft (política de patching, reinicio
necesario, Service Pack, agregado de funcionalidades, etc.).

4. Los aspirantes
Entre los aspirantes, algunas empresas han conseguido destacar:

Virtuozzo (de Parallels). Dedicado principalmente al hosting, Parallels atrae cada vez a más empresas, gracias a precios
atractivos y a una gestión administrativa comprobada.

KVM, verdadero producto Open Source, integrado de manera nativa en los sistemas Red Hat. Históricamente hablando,
Red Hat integraba XEN (antes de que este último fuera comprado por Citrix). Esta decisión comercial ha costó caro a Red
Hat. Los clientes que adoptaron Xen en su momento se encontraron en una posición incómoda.

OracleVM: después de la compra de SUN, habrá que seguir muy de cerca a Oracle para comprender su estrategia en
materia de virtualización.

El Proyecto de Virtualización
Preámbulo de un proyecto de virtualización

1. Definición de la necesidad
Cuando se estudia un proyecto de virtualización, la primera pregunta que el responsable de informática se hace es la
siguiente: ¿cuál es la inversión inicial necesaria y cuánto tiempo hay que esperar para alcanzar el retorno de inversión?
Esta es una cuestión formidable ya que, desde hace algunos años, la informática está considerada como un centro de
coste que necesita constantemente más recursos.

Por otro lado, durante varios años, se han puesto en marcha numerosos proyectos de reducción de costes, gracias a la
convergencia (ToIP, VoIP) y a la externalización. Sin embargo, hay que constatar que muchas empresas no han obtenido
los resultados esperados debido a sobrecostes ocultos o problemas técnicos importantes.

«Gato escaldado, del agua fría huye»: ésta es la fórmula que podría resumir la situación actual. Los que deciden quieren
soluciones probadas con feedbacks concretos antes de lanzarse o decidirse por una solución milagrosa. Los
desarrolladores de software o de soluciones lo saben bien, ya que cada vez se organizan más ferias, con el objetivo
principal de encontrar el máximo número de clientes.

Del lado de la virtualización, este fenómeno se conoce bien, ya que los primeros años fueron caóticos. Es difícil encontrar
información sobre el tema actualmente, pero está claro que durante la primera fase de la implementación en las empresas
piloto, no dio los resultados esperados. Es por eso que fue necesario reorientar la estrategia de comunicación y hacer
Página 22 de 146
 comprender a los responsables que un proyecto de virtualización, como todo proyecto, necesita un marco estricto y una
definición de necesidades perfectamente clara.

Es esencial comprender que un proyecto de virtualización a menudo tiene un perímetro complejo y denso que es necesario
enmarcar bien antes de empezar. El retorno de la inversión es difícil de calcular debido a que contiene numerosas
variables. Por tanto, es muy recomendable reducir el perímetro de los proyectos de virtualización a un mínimo durante
el primer periodo. Así se reduce la complejidad y se puede calcular un ROI (Return On Investment) con mayor fiabilidad.
Es muy tentador, para un integrador, por ejemplo, virtualizar al máximo la infraestructura de una empresa. Este método
es peligroso y no debería utilizarse salvo en caso de que se domine perfectamente la infraestructura global.

Una vez el perímetro está establecido, es obligatorio proceder a lo que se llama comúnmente una auditoría preliminar.
Esta auditoría permite determinar la viabilidad del proyecto sobre el perímetro marcado (a esta auditoría también se le
llama estudio de viabilidad).

Una vez la auditoría está terminada, hay que reunir a todos los actores del proyecto y decidir un planning común.

A veces, y más en las grandes cuentas, el perímetro no puede escogerse sin haber realizado un estudio inicial. Este
estudio permite seleccionar un cierto número de perímetros a escoger.

Hay que tener en cuenta que una empresa a menudo no es capaz de determinar sus propias necesidades. Hará falta
guiarla hacia el objetivo y no buscar agrandar el perímetro a toda costa, a riesgo de no conseguir suficientes compromisos
en términos de ROI.

2. La noción de perímetro
El perímetro de un proyecto de virtualización es el elemento más importante para las operaciones siguientes. Su elección
es absolutamente crucial, sobretodo cuando una empresa nunca se ha enfrentado a entornos virtuales.

De hecho, si el perímetro se elige de forma óptima, tendremos todas las oportunidades de nuestro lado para garantizar
el TCO/ROI prometido inicialmente.

Por el contrario, si la fase piloto no funciona, la empresa tendrá la impresión, y con razón, de que la tecnología aún tiene
camino para mejorar o hacerse fiable. La primera impresión a menudo es la correcta, y la conclusión será que la fase
piloto habrá sido un fracaso y aplazará la cuestión de la virtualización… por unos cuantos años.

A continuación, estudiaremos en detalle los diferentes perímetros posibles y las ventajas e inconvenientes de cada uno.

3. La auditoría preliminar
Como veíamos antes, la auditoría preliminar es una fase muy importante. Ésta es a la vez técnica y organizativa.

A menudo, nos encontramos con consultorías que proponen paquetes de software que permiten determinar si el perímetro
es compatible con la virtualización. A esta aproximación le falta singularmente pragmatismo. Tomemos un ejemplo
concreto de una experiencia previa:

Una empresa desea virtualizar sus bases de datos ORACLE que contienen sus aplicaciones críticas. Repasando
brevemente la herramienta de compatibilidad, llegará a la conclusión evidente de que la plataforma es virtualizable y que
habrá que prever N recursos.

Sin embargo, a nivel organizativo, los obstáculos que se encuentran a menudo son los siguientes:

 La aplicación está gestionada por una entidad que exige una muy alta disponibilidad y tienen contratados SLA.
 Los DBA de Oracle exigen un alto nivel de rendimiento (están sujetos a los compromisos adquiridos…).
 El equipo que se ocupa del almacenamiento no sabe cómo gestionar los cambios que hay que realizar para poder
acoger la plataforma virtual. Estos necesitan tiempo para determinar las inversiones necesarias.
 La supervisión de los procesos críticos debe igualmente estar integrada en la nueva arquitectura. Los equipos de
supervisión anuncian generalmente un plazo de 6 meses mínimo para realizar la petición.
 Debe hacerse un estudio para determinar los parámetros de configuración de las máquinas virtuales. Esta
configuración debe ofrecer los máximos niveles de rendimiento.
 La directiva de seguridad está inquieta. Nunca han tenido que enfrentarse a la problemática de la seguridad de los
entornos virtuales y pide un estudio interno para poder así determinar los riesgos (análisis de riesgos).
 La directiva de compras se hace preguntas acerca del modelo de licencias Oracle en el entorno virtual. ¿Cómo
hacerlo para poder reducir los costes a ese nivel?
 La política de Oracle de dar soporte sobre entornos virtualizados es muy difusa.

Esta lista está lejos de ser exhaustiva, pero permite comprender más o menos que la tarea no es nada fácil.

Página 23 de 146
Algunos pueden argumentar que esto pasa con todo gran proyecto de infraestructura y que no es sólo resultado de la
virtualización. Eso es cierto, pero la virtualización no se vende como tal actualmente, de ahí la advertencia.

El aspecto organizativo obliga a anticiparse a todas las problemáticas. No integrar los aspectos organizativos desde el
inicio y reducir la virtualización a una simple expresión técnica conducirá inevitablemente al desastre. En el mejor de los
casos, el proyecto quedará en los cajones.

La auditoría preliminar nos permitirá sintetizar todo, para así poder presentar a los responsables una visión global del
trabajo que vamos a realizar. Es por eso que es muy recomendable trabajar con empresas especializadas en este campo.
Los consultores enviados no deben ser técnicos puros ni jefes de proyecto, pero sí ser capaces de controlar el proyecto
de punta a punta y poseer un talento particular para la conciliación y la diplomacia (sobre todo los que tengan que
enfrentarse con numerosos actores repartidos en muchos departamentos).

La definición del perímetro

Para clarificar la situación, vamos a ver las ventajas e inconvenientes de cada enfoque. Así permitiremos orientarle mejor
en función de la situación a la que se tenga que enfrentar.

1. El enfoque por negocio

Este enfoque consiste en virtualizar de acuerdo a la estructura jerárquica de la empresa. Tomemos por ejemplo una
empresa clásica con el organigrama siguiente: contabilidad, gestión de recursos humanos, dirección de operaciones, y
comunicación.

Un enfoque sería, por ejemplo, tomar como perímetro inicial la estructura de la que se ocupa la comunicación.

Las ventajas son las siguientes:

 Es fácil reagrupar a los actores ya que son los únicos presentes en la estructura que nos concierne.
 Es posible escoger para la prueba piloto la estructura menos dependiente de la plataforma informática.

Sólo un consejo, evite los departamentos que se ocupan de las nóminas…

 Un enfoque inteligente podría ser virtualizar aplicación por aplicación y obtener así inmediatamente un ejemplo de
uso (ralentización eventual, bug, cambios constantes, etc.).

Ahora mostraremos los inconvenientes:

 La primera reacción del departamento afectado será: "¿Por qué nosotros? ¿Por qué no otro departamento? No
podemos asumir nuevos problemas..."
 Debe obtener obligatoriamente la colaboración de la mayoría de las personas del departamento afectado. Si existen
personas antipáticas o reacias, desgraciadamente habrá que tratar con ellas…
 Si el departamento está repartido de una forma totalmente dispar (por ejemplo entre varios países), será difícil
planificar el conjunto del proyecto.

2. El enfoque por entidad lógica

Para simplificar, éste puede considerarse el enfoque más flexible, ya que usted puede tomar aquello que necesite,
mientras el perímetro formado esté bien definido. Por ejemplo, es posible crear una entidad lógica de 10 servidores, o
crear una entidad lógica que comprenda una o varias salas informáticas.

Las ventajas son las siguientes:

 Es muy fácil reducir el perímetro al mínimo, de forma que se pueda controlar perfectamente.
 Es posible adaptar cualquier tipo de estructura.
 Es interesante poder introducir una lógica en la creación del perímetro, en las estructuras formadas de manera
ilógica.

Y ahora los inconvenientes:

Página 24 de 146
  Es común encontrarse bajo una entidad lógica de cualquier forma y tipo. Mantener esta misma estructura lógica a
largo plazo es a menudo imposible.
 En algunos casos, el reagrupamiento puede densificar la complejidad; por ejemplo, en el caso de que muchas
entidades formen parte de la misma agrupación lógica.
 Es difícil crear una lógica en un entorno donde no hay necesidad…

Lo que hay que recordar de este enfoque es que a menudo se utiliza para montar entornos de pruebas o de desarrollo
para validar la tecnología en sí. El uso para la producción requiere un estudio mucho más profundo.

3. El enfoque por estructura física

Este enfoque se considera como el menos complicado, ya que reposa sobre una estructura perfectamente establecida:
la que existe a nivel físico.

Las ventajas son las siguientes:

 El perímetro es muy fácil de determinar.

 El perímetro está delimitado de forma fuerte. El desbordamiento es imposible.
 Es un enfoque apreciado por los responsables ya que es el que se entiende de forma más concreta.

Y los inconvenientes:

 El enfoque físico es evidentemente vinculante ya que no se puede adaptar fácilmente a las necesidades de cada
uno.
 El perímetro puede ser muy complejo en función del tamaño y la heterogeneidad de la estructura física.
 Está contraindicado partir de una estructura física cuando el principal objetivo de la virtualización es abstraerse de
dicha noción física.

4. Conclusión
Es muy recomendable para las grandes estructuras componer el perímetro utilizando en paralelo los 3 enfoques. Por
ejemplo:

Usted decide elegir un Datacenter de un país (perímetro físico).

En el Datacenter, usted puede escoger una entidad lógica como, por ejemplo, todos los servidores NEC y HP que hayan
sido integrados desde hace más de 4 años.

Página 25 de 146
 De esos servidores, solamente elegirá aquellos destinados al desarrollo de las aplicaciones internas (enfoque de negocio).

La auditoría preliminar y la influencia del histórico

1. Auditoría técnica
La auditoría técnica preliminar sirve para determinar con buen criterio el perímetro. Esto es, de hecho, algo técnico, ya
que el auditor debe verificar todos los detalles a lo largo de sus investigaciones.

De forma no exhaustiva, se deberán efectuar:

 Profiling: cambio - funcionamiento nominal - recursos afectados, etc.

 Inventario de los elementos presentes.
 Heterogeneidad del perímetro.
 Recuperación de información sobre los procesos, guías y procedimientos utilizados en la empresa, de cara a
gestionar los elementos.
 Listado de los elementos potencialmente perturbadores: base de datos, aplicaciones críticas, aplicaciones sensibles,
aplicaciones sobrecargadas, etc.

Hay mil y una formas de realizar el inventario de un perímetro determinado. La primera etapa consiste, generalmente,
en acercarse a los equipos que éste controla. Igualmente es necesario hacer una comprobación sobre sí mismo (nunca
se es demasiado prudente). Las herramientas de red se utilizan a menudo para desmantelar el perímetro. Después, será
necesario trabajar con herramientas mucho más orientadas a sistemas para entrar en el corazón del perímetro.

Hay que tener en cuenta que cuanto más heterogéneo es el perímetro, más difícil es virtualizarlo. Así, una fase de la
auditoría consiste en determinar los diferentes tipos de elementos presentes en el perímetro. Generalmente, se
encontrará con las siguientes categorías:

Sistemas operativos: tipo: (Windows, Linux, Unix, Solaris, etc.), versión (SP2, update 5, etc.) y configuración.

Servidores físicos: fabricante (HP, IBM, DELL, SUN, Nec, etc.), modelo y características técnicas (procesadores,
memoria, discos, tarjetas de red, tarjetas RAID, etc.).

La red: fabricante (Cisco, Juniper, Alcatel, 3Com, etc.), categoría (Router, Switch, Hub, Firewall, etc.), modelo y
configuración.

El almacenamiento: fabricante (EMC, NetAPP, HDS, HP, IBM, etc.), categoría (Middle End, High-End, etc.), modelo y
configuración.

Una vez se ha efectuado el trabajo, el auditor debe recuperar el máximo de información sobre el trato operacional de
cada uno de los elementos. Para eso, puede trabajar con los procesos existentes en la entidad que gestionan los
elementos diariamente.

¿Por qué es esto necesario? Simplemente porque la virtualización no puede contradecir el orden establecido. La
virtualización sirve también para mejorar la gestión de las infraestructuras. Aunque, para adaptarse, se hayan hecho
determinadas concesiones por los operarios de todos los proyectos de virtualización, es conveniente evitarlo. A menudo
esto crea sobrecostes ocultos: procedimientos que hay que reescribir totalmente, formación suplementaria, compra de
utilidades, etc.

Un ejemplo simple: la virtualización impacta a menudo sobre la carga del departamento que se ocupa de las copias de
seguridad (hay un capítulo dedicado a ello). Si la virtualización impone, por ejemplo, cambiar la aplicación de copia de
seguridad, todo lo que se haya capitalizado por la empresa hasta el momento para esta herramienta se perderá.
Tratándose de la copia de seguridad, es un tema que se vuelve costoso rápidamente.

Aquí tenemos una lista no exhaustiva de procesos utilizados comúnmente:

 Copia de seguridad
 Recuperación
 Supervisión
 Arranque y parada

Al final, el auditor deberá interesarse por los elementos perturbadores. Este último paso es el más difícil ya que depende
únicamente de la experiencia del auditor. Por tanto es un punto siempre sujeto a discusión.

Se dice que un elemento es potencialmente perturbador, si se reconoce como difícilmente virtualizable.

Página 26 de 146
Atención, esto no significa en ningún caso que no pueda ser virtualizable, sino que indica que habrá que poner especial
atención a ese elemento en su configuración o en la configuración de la futura máquina virtual asociada.

Para aportar alguna experiencia al tema, aquí veremos unos ejemplos:

 Las bases de datos: son muy codiciosas en recursos y requieren rendimientos excelentes en términos de
entrada/salida (E/S).
 Las aplicaciones críticas: deben estar absolutamente disponibles y a menudo instaladas en máquinas llamadas
tolerantes a fallos.
 Las aplicaciones sensibles: deben estar absolutamente aisladas del resto de máquinas, ya que su confidencialidad
es extrema.
 Las aplicaciones con sobrecarga: soportan muchas solicitudes en términos de recursos, y a menudo se reparten
geográficamente para poder homogeneizar la carga.
 Las aplicaciones especiales: son las aplicaciones que no entran en el resto de áreas. Por ejemplo, una aplicación
que necesita un hardware particular para funcionar correctamente (puerto Firewire, Token propietario, etc.)
 Los sistemas hiper propietarios: son los sistemas que no pueden virtualizarse porque están formados para un
material específico: HP-UX, AS400, estación alpha, Superdome, etc.

A menudo, las utilidades de mercado de determinación de compatibilidad serán útiles al auditor en caso de duda o para
obtener una confirmación.

Página 27 de 146
2. Auditoría organizativa
La auditoría organizativa es sin duda la parte que menos se domina actualmente y la que demanda una comprensión de
aspectos mas allá de lo que es puramente la virtualización. Esto no es un juicio de valores, sino más bien una constatación
por la actitud de los editores en este ámbito al comunicar sobre los aspectos de instalación y despliegue de la
virtualización.

Para más información, visite http://tinyurl.com/6kfqx4

Si bien es cierto que hoy en día es posible el despliegue rápido y fácil de una infraestructura, sigue siendo difícil evaluar
las consecuencias de un proyecto de virtualización de un SI existente (sobre todo si es complejo).

Además, está claro que la posición actual de las sociedades vendedoras de virtualización está más orientada a soluciones
técnicas con una lista de tecnologías de virtualización. Es lógico: es difícil encontrar personas o equipos que dominen
tanto el aspecto técnico de la virtualización como la auditoría organizativa de los SI. Los auditores (incluyendo la
organización) están buscados y se conservan, por lo que se encuentran pocas veces en proyectos de virtualización.

Así, para paliar el problema, las empresas prefieren pronunciarse sólo sobre el aspecto técnico (y a veces también sobre
el aspecto de gestión de proyecto, ya que la tendencia actual es la de colocar a cualquiera como jefe de proyecto… pero
eso es otro tema).

Es muy aconsejable hacer intervenir a un auditor certificado. Aunque existen numerosas certificaciones, solamente hay
una que actualmente concierne a los SI: la CISA (Certified Information System Auditor). Esta certificación la entrega la
ISACA (Information System Audit and Control Association) muy conocida en el mundo de los auditores de SI.

Evidentemente es difícil escribir una regla preestablecida que concierna a la forma de auditar un SI para poder virtualizar
el perímetro. Sin embargo, he aquí algunos elementos sobre los que reflexionar:

 ¿Cuál es la visión estratégica de la empresa a largo plazo (reagrupación, externalización, descentralización,

adquisición de filiales, etc)?
 ¿Cuál es el tiempo de adaptación evaluado de los equipos operacionales sobre el perímetro dado una vez que la
virtualización se haya establecido?
 ¿Hay un presupuesto previsto para la posible contratación de personal suplementario?
 ¿La visibilidad del proyecto se percibe a alto nivel?
 ¿Existe comunicación entre la entidad encargada del proyecto y las entidades potencialmente impactadas?
 ¿Cuál será el tipo de soporte de los nuevos socios/fabricantes?
 ¿Cómo se gestionarán las incidencias?
 ¿Cuál es la garantía de restablecimiento?
 ¿Hay medios para dar marcha atrás?
 ¿Hay presupuesto para formación?
 ¿Cuáles son los tipos de compromisos que se tomarán en caso de problema (compromiso de métodos o de
resultados?)
 ¿Hay un SLA en el perímetro escogido?
 ¿El soporte de las aplicaciones está completamente asegurado en el caso de la virtualización?
 ¿Qué consecuencias hay desde un punto de vista de seguridad?
 ¿Existe un representante para la seguridad en las reuniones desde el inicio del proyecto?

Existen evidentemente muchos otros elementos en los que se puede profundizar. Sin embargo, estas preguntas serán
suficientes para poner en contexto a cualquier persona a cargo de un proyecto de virtualización.

Los requisitos previos y las competencias requeridas

1. Un ROI/TCO aprobado al más alto nivel jerárquico

Antes de nada, un proyecto de virtualización deberá estar aprobado al más alto nivel. Esta constatación es fruto de
intercambios de experiencias y de la analogía que podría hacerse con los proyectos de seguridad de los sistemas de
información.

Las RSSI y otros encargados de la seguridad lo saben bien: la seguridad debe percibirse y aprobarse al más alto nivel
jerárquico. Esto permite que las acciones que se lleven a cabo tengan cierta legitimidad.

La virtualización pertenece a esta categoría por diversas razones:

Página 28 de 146
  Es un proyecto estructurante.
 Es un proyecto que implica numerosas modificaciones, incluida la forma de pensar, de entender y de construir
nuevas arquitecturas.
 Es un proyecto que puede implicar serias complicaciones de seguridad.
 Es un proyecto pesado desde un punto de vista financiero. Implica muchas compras y prestaciones variadas.
Además, impone a los directivos encargados de las compras una nueva forma de pensar.

La mejor manera de actuar consiste en implicar a la directiva y en enseñarle, desde el principio, lo que va a mejorarse
concretamente. Un directivo es una persona muy dada a la protección de los activos de la empresa y de la rentabilidad
de ésta. Por tanto, estará atento a las nociones de retorno de la inversión (ROI: Return On Investment) además del coste
total de posesión TCO (Total Cost of Ownership) que se le venderán.

Los elementos estructurantes de un ROI/TCO para un proyecto de virtualización generalmente son:

 Los gastos de las nuevas máquinas necesarias.

 Las compras necesarias para el almacenamiento (SAN, NAS, etc.).
 Las licencias del software de virtualización, además de las licencias del ecosistema relacionado.
 Las consultorías (MOA), estudio (MOE), integración y mantenimiento en condiciones operativas.
 La formación para el personal que se hará cargo de la nueva infraestructura.
 El ROI/TCO será sensiblemente distinto de una empresa a otra, visto el número de parámetros presentes en la
ecuación.

La mejor forma de calcular el ROI/TCO es respetar lo que se dijo al principio. Esto permite delimitar el proyecto de la
mejor manera y conocer el tamaño (al menos a nivel macroscópico).

Ya sólo quedará determinar la cantidad de trabajo necesario para todos los participantes en el proyecto. Para ello, el
reparto en tareas o hilos es habitual y permite cuantificar con precisión. Es difícil sugerir los hilos o tareas genéricas ya
que todos los proyectos de virtualización son diferentes. El único punto en común es el preámbulo. No obstante, aquí se
muestra un ejemplo de proyecto relacionado con el sector médico:

Página 29 de 146
 Una vez hecho esto, se puede calcular el TCO/ROI.

2. Una sensibilización sobre la gestión de cambios

La gestión de cambios es un aspecto a menudo subestimado en el cálculo del ROI/TCO. Todos los proyectos de
virtualización comportan una etapa de transferencia de competencias que, lamentablemente, es a menudo insuficiente.

He aquí un ejemplo concreto:

Los administradores del sistema se tienen que habituar a controlar los entornos virtuales (integración de máquinas host,
gestión centralizada, alojamiento de recursos, etc.).

Los arquitectos deberán integrar la noción de virtualización para poder crear plataformas virtuales optimizadas.

Los responsables de seguridad deberán revisar la seguridad de arriba a abajo (desde el modelo de procedimientos y la
guía de buenas prácticas).

Los responsables PCA/PRD (Plan de Continuidad de la Activitad/Plan de Recuperación ante Desastres) deberán revisar
completamente su manera de actuar…

Aunque los cambios son substanciales, una vez la virtualización haya llegado a la madurez, permitirá poner en marcha
una auténtica gestión de cambios en la empresa. De hecho, el ciclo de la vida de los sistemas y de las aplicaciones hasta
ahora estaba relacionado con el buen hacer de los fabricantes y desarrolladores. La virtualización permitirá flexibilizar
ampliamente esta gestión de cambios.

Dado que ya no habrá dependencia técnica relacionada con el material (virtualización de los servidores), podemos
imaginar que una máquina virtual podrá vivir y evolucionar únicamente según las necesidades del negocio.

Del mismo modo, ya no habrá dependencia técnica relacionada con los sistemas (virtualización de las aplicaciones),
podemos imaginar también que una aplicación podrá vivir y evolucionar de forma idéntica.

La incógnita que queda es el apoyo de los desarrolladores y las responsabilidades que deberán asumir los directivos
cuando el soporte no sea efectivo…

3. La elección tecnológica material

Aunque la virtualización permite eliminar restricciones materiales, no significa que la elección del material sea secundaria,
más bien al contrario... En términos de virtualización de servidores y aplicaciones, la elección tecnológica se reduce,
debido al número de participantes presentes en el mercado. Por el contrario, la elección no es tan limitada cuando se
trata de elegir entre los fabricantes de servidores físicos, de los terminales o bahías de almacenamiento.

El objetivo de este libro es dar una visión objetiva del mercado, dando además consejo sobre lo que ha sido comprobado
y calificado por sociedades especializadas.

a. Fabricante de servidores
NEC

Nec es una sociedad japonesa que se conoce poco en el ámbito de los servidores en Europa, aunque sean líderes en
Japón. Los servidores NEC son fiables y robustos según las diferentes comprobaciones de virtualización efectuadas. Se
adaptan perfectamente al mundo de la producción para las infraestructuras físicas con requisitos de alta disponibilidad.
De hecho, no hay muchos bugs, con lo que las actualizaciones son relativamente poco frecuentes.

Por otro lado, es cierto que los servidores Nec a menudo son menos potentes que sus competidores, ya que estos últimos
no dudan en implantar las nuevas tecnologías en cuanto les es posible.

Página 30 de 146
 Nec posee, a nuestro parecer, dos argumentos de peso:

 Un servidor llamado FT (Fault Tolerant). Cada elemento está redundado, con lo que la alta disponibilidad está
asegurada. El servidor es compatible con VMware ESXi y ESX 3.0.2.

 Una oferta híbrida que acoge 6 ranuras de un blade con una NAS/SAN, todo por un precio módico. La interfaz de
administración es única en su género y es extremadamente simple en comparación con sus competidores.

Nec es un candidato incontestable en el mundo de la virtualización de servidores aunque, lamentablemente, es poco

conocido, por muy competitivo que sea en términos de precio y funcionalidad.

HP

Hewlett Packard es una de las empresas pioneras en la virtualización de servidores. Desde muy pronto, HP se desmarcó
en probar los productos VMware sobre sus diferentes plataformas.

HP se considera a menudo líder en términos de rendimiento ya que es reactiva en relación al mercado. Gracias a su
historia y a su antigüedad, HP posee una oferta variada y modulable, además de un soporte técnico muy reactivo. Esta
sociedad es líder incontestable de la supervisión a través de su utilidad Hp OpenView que, a pesar de todas las críticas
recibidas, ha sido durante mucho tiempo una de las utilidades indispensables para todo aquél que buscaba métricas
fiables para supervisar su entorno.

HP tiene un punto a destacar, ya que proporciona una lista de hardware compatible para los entornos VMware. HP
participa activamente en la iniciativa Vmmark, lo que demuestra que están muy pendientes de los aspectos relacionados
con el rendimiento de sus plataformas.

En último lugar, HP posee una base de conocimientos inmensa, con foros especializados sobre problemáticas técnicas.

Los servidores HP estarán por tanto destinados a aquellas personas con dificultades en cuanto al rendimiento o que
quieran tener un soporte de un nivel muy alto.

Las plataformas con mejor reputación de HP son:

Página 31 de 146
 La oferta c-Class que permite consolidar de forma óptima en un espacio reducido. Las bahías son particularmente
robustas y a toda prueba.

La oferta Proliant DL. Estos servidores están particularmente adaptados a la virtualización y disponen de
numerosos feedbacks positivos al respecto.

IBM

IBM, desde hace mucho tiempo, ha desarrollado tecnologías de virtualización sobre sus propios sistemas (no X86). Hace
algún tiempo, IBM sufrió el terremoto VMware y decidió ser parte del movimiento. Sin embargo, los argumentos de IBM
son aún un tanto paradójicos sobre sus ofertas. IBM propone en paralelo una oferta de virtualización clásica X86 con
VMware - XenServer y Hyper-V y por otro lado una oferta propietaria de virtualización (a menudo con AIX).

IBM explica esto asegurando que las dos ofertas responden a las necesidades de clientes bien diferenciados. Sin embargo,
hay que constatar que en realidad, no siempre es así. IBM tiene un interés evidente, desde un punto de vista estratégico
y económico, en revender sus propias soluciones, que domina perfectamente; para ello, intenta imponer su ecosistema
de software asociado (Tívoli, etc). Por tanto, es particularmente recomendable estar atento sobre este punto.

Desde hace algún tiempo, IBM parece que se implica más en la virtualización X86 y empieza a competir seriamente con
los líderes del mercado.

Como en el caso de Microsoft, IBM podrá convertirse rápidamente en uno de los líderes ineludibles de la virtualización
X86.

DELL

En DELL se dieron cuenta rápidamente de que la virtualización iba a cambiar las normas de las infraestructuras. Partidario
de la ecología y de la economía de la energía, DELL ha sabido conjugarlo todo de forma inteligente.

DELL se ha hecho con un puesto de líder en el mercado de la virtualización. Debe su reputación a la buena integración y
compatibilidad material pero peca mucho en cuanto a soporte y falta de feedbacks. DELL se compara a menudo con Free
en el área de componentes de conexión a Internet: excelentes rendimientos, numerosas posibilidades de parametrización
y personalización, pero sólo reservado a personas experimentadas.

Existen otros fabricantes como Unisys, Sun, Fujitsu-Siemens que igualmente poseen excelentes servidores para la
virtualización.

Página 32 de 146
b. Fabricante del material de almacenamiento

En el área del almacenamiento y de la virtualización (SAN + NAS), dos gigantes pelean por el liderazgo: NetApp y EMC.

NetApp

NetApp comprendió rápidamente que la virtualización representaba el futuro, y se convirtió en la referencia absoluta en
materia de virtualización del almacenamiento y en una privilegiada con su software para informes de material. Los
programadores han diseñado un mini sistema (Data Ontap) que integra nativamente la virtualización bajo las capas más
bajas.

Aunque ello impacto al rendimiento, ya que la capa de software es más pesada, y penaliza a NetApp para las arquitecturas
llamadas High End, el mercado de baja y media gama está constituido principalmente por bahías de almacenamiento
NetApp, sobre todo cuando se buscan soluciones de virtualización.

Todos los expertos en virtualización le dirán que NetApp es el líder indudable del momento.

Su oferta posee una modularidad única, ya que es posible partir de modelos bajos de gama e ir aumentando en potencia
sin ningún perjuicio. Además, todos los modelos tienen por defecto interfaces de comunicación Fibra y Ethernet.
Igualmente, se puede utilizar iSCSI, FCP o NFS de forma nativa (con rendimientos excelentes).

La oferta de NetApp tiene la ventaja de ser perfectamente polivalente, modulable y evolutiva.

EMC

Sociedad líder en almacenamiento, EMC es evidentemente una posible elección para la virtualización. Aunque hayan
comprado a VMware, EMC aún está retrasada en la virtualización. Eso puede parecer paradójico, pero aún no se ha
sacado el máximo provecho de la compra.

Los expertos están de acuerdo en el hecho de que EMC aún no ha sacado todo provecho posible de VMware. Los recientes
acontecimientos políticos son una prueba irrefutable (http://tinyurl.com/5wosru).

EMC tiene una gran reputación en cuanto a su fiabilidad y su gestión de infraestructuras High End. Sin embargo, como
la virtualización está relativamente poco desarrollada en contextos ultra críticos, EMC aún no ha podido aún mostrar todo
su potencial.

Además, EMC tiene una política tarifaria que deja fuera a muchas PYMES, lo que contribuye a que NetApp se abra camino…

Página 33 de 146
Hitachi Data Systems

Con muy buena reputación en los grandes Datacenter, HDS se beneficia del saber hacer de Hitachi en la gestión de
discos. La oferta de HDS está sobretodo orientada al High End. Los pequeños clientes no son el objetivo de HDS.

Desde el punto de vista del rendimiento, HDS tiene un aura incomparable. Para una empresa que tenga el presupuesto
suficiente, HDS es realmente una excelente elección.

Los fabricantes de servidores fabrican a menudo de sus propias bahías de almacenamiento: IBM - HP - NEC - SUN - DELL,
etc.

Construcción de una Infraestructura

Introducción
Este capítulo permite hacerse una idea sobre la arquitectura de VMware ESX y de su uso para crear una infraestructura
virtual. Evidentemente, está particularmente indicado para las personas a cargo del aspecto técnico. Sin embargo, ya
que la arquitectura define el retorno de inversión, el capítulo permite a los responsables comprender las elecciones
técnicas efectuadas.

La capa de virtualización (Hipervisor)

1. VMware ESX
La capa de virtualización es la capa de software que permite virtualizar los servidores. En VMware, el producto destinado a la producción se llama
VMware ESX (actualmente versión 3.5). Éste contiene algunas funcionalidades base además de funcionalidades avanzadas de pago.

Los cuatro modos de licencias que existen actualmente para VMware ESX son:

Página 34 de 146
 (1) vCenter es requisito para funcionar.

ESXi: contiene VMware ESX (o ESXi), SMP y VMFS.

Foundation: contiene VMware ESX (o ESXi), SMP y VMFS, la posibilidad de integración en Virtualcenter, Update Manager y Consolidated Backup.

Standard: contiene el conjunto de funcionalidades de Foundation y VMware HA.

Enterprise: contiene el conjunto de funcionalidades de Standard y VMOTION, Storage VMOTION, DPM y DRS.

2. Virtual SMP
VMware SMP permite configurar máquinas virtuales con soporte multiprocesador. SMP no tiene ninguna relación con el número de procesadores
presentes en la máquina host. Usted puede hacer funcionar máquinas multiprocesador sin SMP. Actualmente, las máquinas virtuales no pueden recibir
más de 4 procesadores virtuales. La próxima versión de VMware ESX (4.0) permitirá configurar máquinas virtuales con hasta 8 procesadores.

Página 35 de 146
3. Virtualcenter
Una vez que usted posea varios servidores físicos que funcionen sobre VMware ESX, necesitará Virtualcenter para poder gestionarlos todos desde una
interfaz centralizada. Virtualcenter es un componente que se instala sobre una máquina Windows. Muchas de las funcionalidades avanzadas de
VMware necesitan VMware Virtualcenter.

Página 36 de 146
4. VMOTION
VMOTION es un mecanismo que permite migrar máquinas virtuales de un servidor físico a otro al vuelo. Es obligatorio disponer de un recurso
compartido entre los servidores (una NAS/SAN). Sobre la infraestructura clásica, los servidores necesitan mantenimiento, lo que a menudo se traduce
en una parada completa de una o varias actividades. Esta tecnología es por tanto particularmente apreciada por aquellos que necesitan garantizar el
máximo nivel de disponibilidad.

Página 37 de 146
 ¿Cómo funciona?

Los archivos de configuración y de datos de las máquinas virtuales están presentes en el almacenamiento compartido accesible desde máquinas hosts
ESX. Ya que los archivos se ven desde los dos lados, se puede arrancar las máquinas virtuales sobre los dos hosts. La "magia" de VMOTION reside en
el hecho de que todo el contexto de la máquina virtual se migra al segundo host ESX (memoria, proceso y carga de red). Esta operación no es visible
de cara a los usuarios finales, ya que el proceso hace esta migración transparente (sin corte).

Virtualcenter se requiere, sin embargo, para utilizar VMOTION.

El VMkernel es capaz de hacer creer a la máquina virtual que está situada siempre sobre el mismo servidor. La memoria de la máquina virtual se
"snapshotea" sobre el host origen y se envía al servidor de destino, sucesivamente hasta que se ha transferido la memoria por completo.

Hay que imaginar que mientras se transfiere la memoria, puede modificarse por los usuarios que siguen trabajando. Así, podrán producirse varias
transferencias hasta que el traspaso de un host al otro sea efectivo.

El uso más frecuente concierne al mantenimiento de servidores. A menudo VMOTION puede ser útil cuando usted deba aplicar un parche a nivel de
VMware que requiera un reinicio.

Aunque VMOTION parezca una tecnología milagrosa, es necesario saber que el traspaso debe estudiarse y planificarse bien. La compatibilidad de las
CPU es, por ejemplo, uno de los elementos fuente de problemas. Para más información y asegurarse de que el proceso se realizará correctamente, hay
que documentarse en el sitio de VMware : http://www.vmware.com/resources/techresources/

Igualmente hay que recordar que VMware Vmotion puede utilizarse indistintamente en VMware ESX 3.5 y ESXi.

5. VMware DRS
DRS es la herramienta que permite migrar, de forma dinámica, máquinas virtuales en función de su carga. DRS crea recomendaciones basadas en la
carga, que pueden actuar de forma manual o automática. DRS está controlado y ejecutado únicamente por Virtualcenter.

El principal objetivo de DRS es mover las máquinas virtuales de un host físico a otro, en función de la carga de CPU y memoria (lo que representa el
99 % de los cuellos de botella de los hosts físicos…).

DRS es capaz igualmente de crear reglas de afinidad. La ventaja es poder gobernar su entorno de forma granular y teniendo en cuenta los
inconvenientes de la producción.

Página 38 de 146
6. VMware HA
VMware HA es el mecanismo que permite proteger a las máquinas virtuales en caso de que un servidor físico se caiga. El tiempo de respuesta es igual
al tiempo necesario para poder reiniciar las máquinas virtuales en otro servidor físico. VMware HA crea lo que nosotros llamamos la noción de cluster,
gracias a la que es posible disponer de arquitecturas capaces de resistir a N fallos de servidores físicos.

Hay que tener en cuenta que la noción de Alta disponibilidad se trata, efectivamente, por VMware pero en ningún caso significa que las máquinas
virtuales vayan a funcionar de manera ininterrumpida gracias a los mecanismos HA de VMware.

7. VCB
VMware Consolidated Backup es un add-on que permite hacer copias de seguridad de las máquinas virtuales, al que
conviene prestarle atención. VCB no es un producto de copia de seguridad, sino un componente que permite interferir
entre el producto de copia de seguridad y VMware ESX. VCB podría entonces estar considerado como un proxy de copia
de seguridad.

Página 39 de 146
La arquitectura de VMware ESX 3

1. La Service Console
La Service Console es la interfaz de comunicación con el VMkernel. De hecho, es una máquina virtual Linux un poco especial, que permite al usuario
beneficiarse de una interfaz amigable de control de gestión del VMkernel. En sí, la Service Console no es estrictamente necesaria; es más, VMware no
la incluye en su producto ESXi.

La Service Console o COS permite interaccionar con el usuario de diferentes maneras :

 Acceso directo.
 SSH.
 Interfaz Web.
 Comunicación propietaria (herramienta de terceros).

Una de las ventajas de la Service Console que hay que tener en cuenta es la de integrar por defecto un firewall (Iptables). Trataremos este punto en el
capítulo Seguridad y virtualización.

Además, como todo Unix, es posible ejecutar comandos que permiten conocer o modificar el estado del sistema. VMware tuvo la buena idea de incluir
por defecto un paquete de comandos muy útiles.

La Service Console incluye también comunicación con el material no crítico, por ejemplo, CD-Rom, los puertos USB, serie y paralelo.

Es evidente, vista la funcionalidad de la Service Console, que consume algunos recursos físicos; por defecto, se necesitan 272 MB.

2. El VMkernel
El VMkernel es el responsable de la gestión de los recursos físicos y de su uso, además de su reparto. Es también responsable de todas las tareas
relacionadas con la virtualización en el host.

El VMkernel es por tanto el corazón del sistema que permite la virtualización. Es totalmente propietario y está desarrollado por completo por los
ingenieros de VMware.

Las funciones principales del VMkernel son las siguientes:

Reparto de CPU, memoria y almacenamiento

El VMkernel se debe asegurar de que las máquinas virtuales tienen acceso a los recursos en función de sus necesidades. Se habrá dado cuenta de que el
reparto de los recursos de red no forma parte de las tareas del VMkernel. Debido a la naturaleza sensible del protocolo TCP/IP, no es posible hacer el
reparto a este nivel.

Gestión de las páginas de memoria

Página 40 de 146
 El VMkernel es capaz de asegurar un seguimiento de los recursos de memoria de forma notable.

Gestión de la virtualización de almacenamiento multinivel

VMware ha integrado bajo la capa de red de VMkernel, un paquete de protocolos que permiten disponer del almacenamiento del tipo SAN o NAS.

Gestión de la virtualización de la pila de red

Gracias a ello, el VMkernel permite construir switchs virtuales, crear una NIC en equipo o agrupada (creación de redes redundantes), VLAN Tagging
(para aislar las redes) o incluso crear Port Group (que permite crear políticas a nivel de puertos de un switch virtual).

Integración de módulos complementarios

Las funcionalidades avanzadas de VMware se integran a menudo así. Por ejemplo, los fabricantes pueden integrar en el VMkernel herramientas de
supervisión de hardware. Es también un excelente medio de aplicar las actualizaciones, ya que hace posible actualizar las funcionalidades sin
necesidad de actualizar el conjunto del núcleo.

El VMkernel y la Service Console constituyen lo que comúnmente se llama el HIPERVISOR.

3. VMM
VMM significa Virtual Machine Monitor. El VMM hace de regulador situado entre la máquina virtual y el VMkernel. Existe un proceso VMM por
máquina virtual y, en el interior de cada proceso, un hilo por vCPU.

El VMM determina, según las peticiones de CPU recibidas, si las instrucciones pueden ejecutarse directamente sobre la capa física o si debe utilizarse
el VMkernel para poder ejecutarla sobre un contexto concreto de protección de CPU.

El VMM es, además, responsable de la representación de la memoria. Debe presentar páginas de memoria física no contiguas como si lo fueran a la
máquina virtual. Eso asegura, entre otras cosas, la correlación entre memoria física y memoria virtual.

Página 41 de 146
4. Matriz de flujo
La matriz de flujo entre los diferentes componentes de una infraestructura virtual es muy importante, ya que permite la comunicación entre los
diferentes elementos en una infraestructura filtrada.

5. Las máquinas virtuales

Hasta ahora, el término máquina virtual se ha utilizado, pero realmente no se ha definido. Este capítulo se concentrará en lo que es realmente una
máquina virtual.

a. Definición

Una máquina virtual está formada por la combinación de material virtual y de una bios virtualizada presentada a un Operating System llamado
invitado. Éste, de hecho, no está al corriente de que el hardware está virtualizado. El OS ve un cierto tipo de procesador, memoria, red,
almacenamiento, etc.

b. OS invitado

Llamamos OS invitado al OS instalado en una máquina virtual. Es, por tanto, el software de sistema instalado sobre la máquina virtual. El proceso de
instalación es idéntico al de una instalación clásica, salvo que la virtualización hace que sea mucho más fácil de utilizar.

Para conocer la lista de OS soportados, puede consultar la siguiente URL:

http://www.vmware.com/pdf/GuestOS_guide.pdf

c. Los archivos de configuración

Una máquina virtual es un directorio que contiene varios tipos de archivos con extensiones diferentes. Listaremos las principales:

 .vmx: archivo de configuración de la máquina virtual.

 .nvram: Bios virtual.
 .vmdk: archivo que describe la configuración de un disco virtual.
 .flat-vmdk: archivo que contiene todos los datos (OS + aplicaciones + datos).
 .vswp: archivo de swap de la máquina virtual.
 .delta: archivo de snapshot.
 .vmsn: el snapshot de la memoria.
 .log: los logs.

Página 42 de 146
d. Hardware virtual Maximal por VM

Para poder crear máquinas virtuales, VMware ESX emula una placa base. Ésta tiene un chipset INTEL 440BX que asegura la compatibilidad con los
sistemas más antiguos. Gracias a esta placa base virtual, esto es lo que se soporta:

 1 a 2 lectores de disquetes.
 1 a 2 lectores de CD/DVD.
 6 ranuras PCI de las que la sexta está reservada para el adaptador de vídeo.
 1 a 4 vCPU.
 Hasta 16 GB de RAM.
 1 puerto paralelo.
 1 a 2 puertos serie.

Los conocedores de otros productos VMware (incluyendo Workstation) habrán notado la ausencia de sonido y de puertos USB. Se puede evitar esta
restricción utilizando un HUB USB IP. En este caso, las llamadas a la interfaz USB son redirigidas a través de la red.

e. Las "vmware tools"

Las VMware Tools son una colección de herramientas que permiten al OS invitado comunicarse con el Hipervisor de manera que el OS se ve
optimizado para funcionar en una arquitectura virtual.

Éstas son algunas ventajas:

 Drivers SVGA.
 Posibilidad de pasar de una máquina virtual a otra con un simple clic (ganancia en tiempo de administración).
 Mejora de los rendimientos de red.
 Sincronización de tiempo con el host físico.
 Posibilidad de apagar correctamente las máquinas virtuales desde la interfaz de control.

f. El almacenamiento y las máquinas virtuales

Habrá visto que las máquinas virtuales están contenidas en un directorio. Este directorio puede ser local en el servidor ESX o remoto. En el caso que
un administrador de sistema decidiera utilizar VMware HA, DRS o VMOTION, será obligatorio pasar al almacenamiento remoto ya que, en un cluster
ESX, las máquinas virtuales deben ser visibles por todos los servidores presentes en el cluster.

Aunque parece simple, el almacenamiento de las máquinas virtuales y de los discos virtuales que las componen es un tema complejo. Existen muchas
formas de crear discos virtuales y de gestionarlos.

Por ejemplo, existen 4 formas de aprovisionar discos virtuales (.vmdk):

Zeroed Thick: es el aprovisionamiento por defecto de ESX. El disco está asignado, aunque los bloques no se borran inmediatamente.

Eager Zeroed Thick: idéntico a Zeroed Thick, aunque los datos son sobreescritos totalmente por bloques con 0.

Thick: en este caso, el espacio también está previamente reservado pero los datos no se eliminan. En algunos casos, este método contiene riesgos de
seguridad. La opción thick no está disponible a través de la interfaz gráfic

a y habrá que utilizar la

linea de comandos para crear este tipo de discos.

Thin: aquí, el espacio no está previamente reservado. Esto permite el ahorro, ya que sólo los datos útiles inicializan los bloques. Éste es el
funcionamiento por defecto, ya que los datos se escriben en un espacio de almacenamiento NFS.
Página 43 de 146
g. Los snapshots

Los snapshots son una de las funcionalidades más interesantes de una infraestructura virtual, ya que permiten crear un
Checkpoint o, dicho de otra manera, puntos de copia de seguridad en el tiempo. Esto hace posible volver en cualquier
momento a estos famosos Checkpoint, sea cual sea el estado de la máquina virtual.

Por ejemplo, imagine que ha creado un punto de copia de seguridad en T y en T+1. Un día, el sistema se corrompe
completamente. Es imposible arrancar la máquina virtual (una pantalla azul por ejemplo). Sería suficiente ordenar a la
máquina virtual volver al estado T+1 o a T para poder recuperar el sistema, y sólo le llevaría unos segundos. Para que
los desarrolladores puedan probar en uno o varios entornos, esta funcionalidad es una de las más eficaces.

Además, también es posible crear esquemas en forma de árbol de snapshots no lineales. En ese caso, un snapshot padre
puede tener varios hijos, aunque un snapshot hijo puede tener un solo padre.

Aunque esta tecnología podría resolver numerosos problemas, puede ser extremadamente peligrosa si no se utiliza con
precaución. Para ello, vamos a mostrar un caso práctico que nos permitirá hacernos una idea. Imagine que su servidor
posee una base de datos utilizada por muchos usuarios. Un día, el servidor falla completamente y es imposible volverlo
a arrancar. No se preocupe, con los snapshots, una simple restauración y está todo arreglado.

Pero entonces habrá otro problema: ¿qué pasa con los datos de la base? La respuesta es fácil. Si no se ha hecho nada
para prevenir este caso, los datos restaurados serán aquellos que estaban presentes en el momento del snapshot. Con
lo que habrá que prever una pérdida de datos…

Es por este motivo que VMware ha previsto diferentes tipos de funcionamiento de los discos virtuales: independiente y
clásico. Pasando un disco virtual a modo independiente, los snapshots no le afectan. Cuando un disco es independiente,
existen dos modos:

Persistant

En este caso, los datos que se escriben una vez se escriben para siempre. Éste es el comportamiento que existe para
una máquina física clásica, y el modo que permite resolver la problemática.

Non persistant

En este caso, los datos en el disco no son modificables a partir del momento en que el disco pasa al modo non persistant.
Las modificaciones se eliminan en el siguiente reinicio. Este modo es útil, por ejemplo, en los entornos públicos o en las
máquinas que deben permanecer idénticas a cada reinicio.

Página 44 de 146
Las grandes orientaciones de arquitectura
Las arquitecturas virtuales pueden estar construidas de diferentes maneras según la necesidad. Podemos distinguir tres
tipos:

 Arquitecturas orientadas a costes.

 Arquitecturas orientadas al rendimiento.
 Arquitecturas orientadas a la disponibilidad.

Es evidente que se pueden crear arquitecturas híbridas, pero estas grandes orientaciones son las que van a determinar
realmente la implementación técnica; una vez que la elección esté hecha, será relativamente difícil dar marcha atrás.

1. Arquitecturas orientadas a costes

Las arquitecturas orientadas a costes son a menudo las primeras que escogen las empresas que dan sus primeros pasos
en la virtualización de los sistemas de información. El motivo es simple: la principal razón de los responsables, sobretodo
en periodo de crisis financiera, por la que pasar a la virtualización, es la reducción de costes. El resto de aspectos son
importantes, pero secundarios, al menos al principio.

Las arquitecturas orientadas a costes parten de la siguiente postura: se hará todo lo posible para que el coste de una
máquina virtual sea lo más bajo posible. Para esto, habrá que hacer que la suma de todas las partes que la componen
sea lo más pequeña posible.

Existen cuatro componentes determinantes que pueden hacer variar el precio:

 Procesadores.
 Memoria.
 Almacenamiento.
 Red.

Página 45 de 146
 Para los procesadores, el principio es asignar un máximo de máquinas virtuales, para hacerlas lo más rentables posible.
La elección del procesador que tenga la mejor relación frecuencia/precio es también un factor que puede hacer bajar el
presupuesto. Igualmente, hay que pensar en crear las máquinas virtuales mono vCPU ya que esto permite ahorrar
recursos.

Debe darse prioridad al almacenamiento local, ya que éste permite reducir el precio del espacio de disco.

A nivel de memoria, en la medida de lo posible habrá que hacer la reduplicación (poniendo los mismos OS invitado en el
servidor… veremos esto más adelante).

A nivel de red, las tarjetas deben ser Ethernet Gigabit simples.

Destaque los servidores medios (Cuatriprocesador cuatrinúcleo, 128 GB de RAM, etc) para maximizar el número de
máquinas virtuales por host físico o muchos servidores pequeños, en función de la curva siguiente:

Para no quedarnos sólo en la teoría, vamos a hacer una simulación:

Servidor Cuatriprocesador cuatrinúcleo (2.8 Ghz) con 64 GB de Ram, 2 TB de disco y 4 tarjetas de red. Coste: 25.000 €.

Capacidad de alojamiento: entorno a 40 máquinas virtuales localmente.

Licencia VMware: coste aproximado 500 € (licencia ESXi con soporte).

Atención, algunos elementos no se han tenido en cuenta voluntariamente para no complicar demasiado los cálculos. El
cálculo no tiene en cuenta la gestión dinámica de recursos. En realidad, los servidores virtuales no tienen un precio fijo ya
que los recursos no están reservados de forma estricta.

Las máquinas virtuales disponen de un entorno:

 Un semi núcleo (16 núcleos lógicos para 30 máquinas) alrededor de 1.4 Ghz.
 2 GB de RAM cada una.
 70 GB de disco.
 130 Mbits a nivel de red.

Página 46 de 146
 Este tipo de máquina virtual es capaz de hacer funcionar la mayoría de aplicaciones actuales. El coste de una máquina
virtual es de (25.000 + 500) / 40 = 640 € aproximadamente.

Muchos argumentarán que este cálculo es demasiado simple. Evidentemente que sí…

Asimismo, habrá que calcular el coste de mantenimiento, de consumo eléctrico, de renovación en caso de obsolescencia,
etc.

Nada le impide construir su propia tabla de comparaciones para manejar las cifras y así maximizar sus inversiones.

2. Arquitecturas orientadas a rendimiento

Las arquitecturas orientadas a rendimiento son las que escogen a menudo las DSI que quieren poner en marcha una
política de virtualización a largo plazo. A menudo, ya han implementado una infraestructura virtual y deciden emprender
sistemas críticos que necesitan rendimientos elevados.

Las arquitecturas orientadas a rendimiento parten de la siguiente idea: las máquinas virtuales creadas deben tener un
nivel de rendimiento máximo.

Para ello, el principio es siempre el mismo. A nivel de CPU, hay que premiar las más recientes y con más núcleos, para
asignarlos de manera óptima en las máquinas virtuales. No siempre es interesante crear máquinas virtuales multi vCPU.
De hecho, esto puede, al contrario, ralentizar el sistema en el OS invitado y las aplicaciones que haya.

Por contra, las reglas de afinidad de VMware así como las reservas de vCPU son muy apreciadas, ya que garantizan la
potencia de las máquinas virtuales de forma continua.

El almacenamiento debe ser remoto, preferentemente a través de SAN. Se aconseja la fibra óptica si no hay problemas
importantes de presupuesto, aunque iSCSI o NFS tienen una relación calidad/precio inigualable.

Además, con la llegada de las conexiones iSCSI de 10 Gbit, la fibra óptica ya no será durante mucho tiempo el protocolo
más ventajoso en cuanto a rendimiento (ver también la FCoE (Fibre Channel Over Ethernet)).

No debe economizarse en memoria. Hace falta reservar el máximo soportado por OS invitado.

Las tarjetas de red deben ser tarjetas de fibra o Ethernet 10 Gbits.

3. Arquitecturas orientadas a disponibilidad

Estas arquitecturas son especialmente estudiadas por los responsables PRD/PCA o por las entidades de seguridad. El
principio es que las máquinas virtuales deben disponer de un nivel de disponibilidad máximo.
Página 47 de 146
 Según el mismo principio, hace falta de forma no exhaustiva:

 Disponer de servidores físicos con tolerancia a fallos. Estos servidores son capaces de soportar la pérdida de uno
o varios elementos. En este caso, el 320 Fc de NEC es un candidato particularmente útil.
 Crear clusteres, tanto a nivel VMware con VMware HA, como a nivel de máquinas virtuales (con MSCS por ejemplo),
o combinar ambos hábilmente.
 Almacenar de forma remota en una SAN o NAS. Lo más importante es que sea de alta disponibilidad. Teniendo en
cuenta las SAN probadas, NetApp es un candidato excelente, gracias a la gama FAS. Para todo aquél que necesite
una seguridad precisa, la gama 30XX con doble controladora es una excelente elección. Las pruebas han
demostrado la calidad de los componentes y la resistencia a los incidentes (corte eléctrico, discos de cambio en
caliente, corte de alimentación, etc.)
 Redundar los caminos de acceso a las máquinas virtuales a partir de ESX (ya que las máquinas virtuales están
almacenadas de forma descentralizada). Esta noción forma parte de la integración de VMware ESX bajo el nombre
de Multipathing.

 Repartir las interfaces de red virtuales a través de diferentes switchs físicos o utilizar una NIC agrupada.

Recursos y Virtualizacion
La potencia de cálculo

1. Los procesadores
El host físico es capaz de descomponerse en vCPU (Procesador lógico): el número de CPU que podrá ser utilizada por las máquinas virtuales es igual
al número de CPU físicas multiplicado por el número de núcleos por CPU (por ejemplo, un servidor con 2 CPU cuatrinúcleo permitirá disponer de 8
vCPU para las máquinas virtuales).

¡Atención! La activación del Hyperthreading multiplica por 2 el número de vCPU.

Página 48 de 146
 El término vCPU no indica que los procesadores sean virtualizados para asignarse a las máquinas virtuales. Existen, de hecho, dos modos de
ejecución:

 Directo, cuando la máquina virtual puede acceder al procesador directamente (generalmente, son las instrucciones que piden un nivel de
protección llamado de Ring 1 a Ring 3). El modo directo tiene la ventaja de ser mucho más rápido, ya que las instrucciones no necesitan ser
virtualizadas por el núcleo de VMware (VMkernel).
 Virtualizado, cuando la máquina virtual debe ejecutar instrucciones que requieran un nivel de protección Ring 0. Aquí, la máquina virtual no
puede tener un nivel de acceso directo y el VMkernel está obligado a intervenir para hacer creer que las instrucciones se ejecutan en modo de
protección Ring 0. Esto aumenta el trabajo del núcleo VMware y crea lo que se llama "Overhead".

2. La elección de la asignación y la gestión vCPU

Las vCPU pueden asignarse de varias formas a una máquina virtual en función de las necesidades:

 Primero, habrá que decidir el número de vCPU que se va a asignar a una máquina virtual. Ésta puede, de momento con VMware ESX 3.X,
contar de 1 a 4 vCPU. Ya que se pueden asignar varios vCPU a una máquina virtual (VM), el modo SMP está activo (con las versiones ESX
2.X, hacía falta una licencia SMP para crear máquinas virtuales con varios vCPU). Las máquinas virtuales disponen así de aún más potencia
de cálculo, sin embargo, el OverHead a nivel de VMkernel es más importante. Es necesario pensarlo bien antes de crear máquinas virtuales
con varios vCPU ya que las consecuencias a nivel de VMkernel no son despreciables.
 Seguidamente, hay que decidir cómo se va a establecer la correspondencia entre las vCPU y las CPU físicas. El enfoque de VMware ESX 3.X
a este nivel es extremadamente modular. Cada vCPU seleccionada corresponde a un núcleo o a un procesador físico (si los procesadores
físicos son mononúcleo). Entonces es posible asignar a las máquinas virtuales uno o más núcleos sobre uno o más procesadores físicos. En
los casos más corrientes, este reparto se hace de forma dinámica, ya que el VMkernel tiene un "Scheduler" que permite repartir mejor la

Página 49 de 146
 carga en los núcleos/procesadores menos cargados. Sin embargo, es posible forzar a las vCPU a corresponderse con un núcleo preciso para
minimizar el impacto sobre ciertos procesadores o núcleos.
 Por último, hay que pensar en parametrizar el perfil de uso de las vCPU. De hecho, VMware ESX gestiona los recursos lo mejor posible
limitándolos a la VM. Para las vCPU, VMware ESX es capaz de disminuir el número de operaciones permitidas lo que se traduce en la
posibilidad de limitar la frecuencia de uso (en Mhz) de las vCPU. Por ejemplo, un procesador cuatrinúcleo E4505 de INTEL proveerá una
potencia de 2 Ghz por núcleo, o lo que es lo mismo, 8 Ghz en total. Es posible imaginarse un vCPU que corresponde al núcleo n°3 del
procesador asignado a una VM, que tenga definido un perfil de uso restringido del vCPU a 500 MHZ máximo. Así, garantizamos que los
1500 MHZ restantes no serán utilizados por esta máquina virtual.

Al revés, también es posible garantizar los recursos para un vCPU. Por tanto, es posible garantizar que las VM tendrán un mínimo de MHZ
disponibles. Tomando el mismo ejemplo, el núcleo nº 3 puede reservarse completa o parcialmente a una máquina virtual.

La cuestión planteada es evidente: ¿cuándo hay que utilizar uno u otro?

3. Caso práctico
Con los despliegues efectuados, hemos tenido suficientes casos prácticos que necesitan la configuración limitada y/o garantizada a nivel de vCPU.

El primer caso tiene que ver con la implementación de un ERP en el sector médico (Registros Médicos del Paciente). Éste está compuesto por una
máquina virtual que hace de base de datos (MSSQL) y otras máquinas virtuales que sirven de clientes TS (Terminal Server). Los clientes TS son
mucho menos críticos que la base de datos. Habrá que garantizar entonces que la máquina virtual que contiene el servidor SQL tiene un procesador
cuatrinúcleo físico exclusivamente para ella, o lo que es lo mismo, cuatro vCPU que corresponden a los cuatro núcleos del procesador físico.

El otro caso concierne al despliegue de puestos de trabajo virtualizados en una gran oficina consultora. La arquitectura está basada sobre un servidor
FlexPower con 4 blade, cada uno de los cuales contiene 2 procesadores cuatrinúcleo con 24 GB de RAM. Se ha utilizado VMware View 3 además de
los terminales Wyse. Los perfiles de usuario se han creado en función de las necesidades. Para todos, se ha tenido que restringir el uso de vCPU para
que un usuario/máquina virtual no pueda impactar sobre el conjunto de recursos o sobre el resto de usuarios.

4. El principio de los "Shares"

El principio de los Shares permite dar una prioridad sobre los recursos de una o un conjunto de máquinas virtuales. Como la QoS a nivel de red, el
principio de los Shares no se activará salvo que se necesite. Si los recursos son suficientes y las máquinas virtuales no deben competir para acceder a
uno, el principio de los Shares no se activará jamas.

Para comprender mejor este principio, podemos hacer una comparación con lo que nos encontramos en el mundo de las finanzas. Si usted tiene la
mayoría de las acciones de una empresa (en Sociedad Anónima), tiene la suficiente influencia como para "aplastar" a los demás. Por el contrario, si no
tiene suficientes acciones, usted no podrá influir en nadie.

Con VMware, los shares permiten definir quién tendrá la prioridad en caso de contención a nivel de asignación de recursos.

Sistemáticamente, para favorecer los entornos de producción, piense en poner un valor más alto en las máquinas críticas, lo que permitirá, en muchos
casos, salvar los muebles…

5. Intel VS AMD
El debate lleva mucho tiempo desarrollándose y ninguno de los actores tiene realmente unanimidad. Sin embargo, sigue
siendo un aspecto primordial del rendimiento de los servidores físicos. La mayor parte de los procesadores actuales,
tanto de Intel como de AMD, tienen rendimientos casi equivalentes y una capa de virtualización nativa (AMD-V y INTEL
VT).

¿Cuáles son entonces los criterios para la elección?

Política: Intel es el líder del mercado y comunica mucho sobre la virtualización. En caso de problemas, difícilmente se
podrá reprochar a un responsable haber elegido al líder… AMD es el "aspirante" y por tanto está más dispuesto a negociar
a nivel económico.
Página 50 de 146
 Soporte fabricante: según la marca de servidores seleccionada, los acuerdos marco pueden influir en la elección del
procesador.

Consumo energético: tanto Intel como AMD se pronuncian muchísimo sobre el consumo energético (GreenIT) de sus
procesadores. Intel parece que va por delante al respecto… (ver http://tinyurl.com/q3xa7z).

Roadmap: Intel & AMD participan en una carrera imparable hacia el multinúcleo. En esta carrera, ganará aquél que
tenga más núcleos y que VMware soporte mejor. Hay algunos detalles interesantes: Intel ha comprado parte de VMware
a EMC (la casa madre) al igual que CISCO. Si esto es así, se confirmaría la ligera ventaja de Intel en la materia, ya que
significa que estaría estudiando tecnologías de virtualización de hardware, seguramente avanzadas respecto a AMD. Sin
embargo, aún queda mucho por recorrer…

La capacidad de memoria

1. La capacidad total
La capacidad de memoria total se descompone en dos partes:

 La memoria asignada al servicio de consola de VMware.

 La memoria asignable a las máquinas virtuales.

La capacidad de memoria se considera a menudo como la segunda causante del cuello de botella principal de la
virtualización. Por suerte, es más fácil agregar tarjetas de memoria que agregar procesadores. De todos modos, no tiene
sentido comprar servidores con poca memoria. Es muy recomendable proveer a los servidores de una gran capacidad de
memoria, y más aún viendo que cada vez cuesta menos.

Generalmente, la mayor parte de los servidores cuentan con entre 16 y 64 GB de RAM de promedio. A menudo es la
mejor opción en términos financieros y le permite arrancar un cierto número de máquinas virtuales.

2. La sobreasignación
Esta técnica permite asignar más memoria de la que realmente existe en el servidor a los sistemas operativos invitados.
El principio es simple y parte de un hecho evidente: los sistemas operativos invitados no consumen la totalidad de la
memoria que se les asigna. Este principio es aún más cierto cuando múltiples máquinas virtuales conviven con el mismo
sistema operativo. La probabilidad de que todas las máquinas consuman el máximo en el mismo momento está
probablemente cerca de cero.

Esta técnica tiene la particularidad de que no impacta en el rendimiento de las máquinas virtuales ya que todo se gestiona
de forma transparente para el VMkernel. Una vez que los recursos físicos del servidor se consumen por completo, se
desencadenan otros mecanismos.

3. La gestión transparente de páginas de memoria compartidas

La gestión transparente de las páginas de memoria compartidas es una tecnología de VMware ESX, que permite reducir
la memoria física consumida. Esto se consigue cuando se agrupan en un mismo host físico las máquinas virtuales que
tienen similitudes.

Un ejemplo concreto:

Todas las máquinas que funcionan con Windows XP ejecutarán casi los mismos procesos de sistema al iniciarse. Si,
además, las aplicaciones instaladas y utilizadas por los usuarios son las mismas, el espacio de memoria de cada máquina
virtual será casi idéntico. En ese caso, será fácil realizar la compresión como cuando se hace para imágenes que tienen
muchos colores idénticos…

No hay muchos testimonios sobre la gestión transparente de páginas de memoria, ya que no es algo obligatoriamente
útil en producción (por la variedad de los entornos). Sin embargo, existe un caso muy interesante con la virtualización

Página 51 de 146
 de puestos de trabajo. En este caso, todas las máquinas virtuales son prácticamente idénticas y la gestión transparente
de las páginas de memoria compartidas se convierte en algo muy eficaz.

4. El Ballooning
Cuando la sobreasignación y la gestión transparente de páginas de memoria compartidas se sobrepasan por completo,
se activa el Ballooning. Primera precisión importante: el Ballooning sólo se activa si las VMware Tools están instaladas
en el OS invitado.

Este método, como su nombre indica, hace referencia a un globo que es posible inflar o desinflar en función de las
necesidades. El principio es el siguiente:

El driver instalado en el OS invitado hará creer que hay tal demanda de memoria que el OS invitado se verá obligado a
usar la memoria swap. Así, la memoria física liberada puede ir libremente a otra máquina virtual.

Página 52 de 146
5. El Swapping
El swapping es la última etapa que se ejecuta cuando todas las otras soluciones han sido agotadas. Es evidente que esta
solución es la que tendrá más impacto en el rendimiento. El swapping de una máquina virtual se hará sobre un archivo
destinado a esto. Para una máquina virtual, es aconsejable que tenga el mismo tamaño que el total de memoria asignada,
lo que permite pasar a swap el total de la memoria física atribuida. La principal diferencia con el memory Ballooning es
que aquí, el VMkernel decide pasar a swap la memoria sin preocuparse de saber si el OS invitado la utiliza o no.

El almacenamiento

1. Los cuatro tipos de almacenamiento

a. SCSI LOCAL

La mayoría de servidores tienen discos locales (excepto los servidores blade donde los discos no suelen estar presentes).
Generalmente son discos SCSI o SAS (raramente SATA).

La primera razón válida para almacenar en los discos locales es el precio. De hecho, los discos locales son mucho más
baratos que los discos en una bahía de almacenamiento, sea cual sea.

El principal problema es el siguiente: si usted decide almacenar localmente las máquinas virtuales, sólo se podrá acceder
a ellas por el servidor físico donde estén presentes los discos. Esto implica que las tecnologías HA, VMOTION y DRS no
podrán utilizarse.

El almacenamiento local en máquinas virtuales se aconseja para pequeñas estructuras que no necesiten invertir en un
almacenamiento SAN (Storage Area Network).

Una excepción a la regla. Ciertos fabricantes tuvieron la acertada idea de proponer servidores "Blade" con discos locales
vistos por los blades como un SAN. Esto permite reducir de forma importante los costes, beneficiándose igualmente de
las tecnologías avanzadas de VMware.

Ver http://tinyurl.com/oy44p6

Página 53 de 146
 Antes de comprar un servidor y utilizar los discos locales para máquinas virtuales, es necesario comprobar si el VMkernel
soporta sin problemas las tarjetas controladoras. Una práctica actual es posicionar un RAID 1 para la instalación de la
Service Console de VMware ESX y de poner un RAID 5 para las máquinas virtuales.

En resumen:

VENTAJAS del almacenamiento local SCSI

 Coste. Siempre será menos caro que una SAN.

 Simple de usar y configurar. No es necesaria ninguna experiencia con SAN.

INCONVENIENTES del almacenamiento local SCSI

 Es difícil recuperarse de un crash de la máquina host.

 Nada de VMOTION, DRS ni HA.

b. Fibra óptica

Las SAN de fibra óptica son las más utilizadas actualmente. Permiten a VMware acceder a nivel de bloque, lo que favorece
el rendimiento. Las únicas comunicaciones que pasan a través de la fibra son las entradas/salidas de los discos. Desde
un punto de vista de seguridad y rendimiento, no hay nada mejor…

En resumen:

VENTAJAS del almacenamiento SAN de Fibra

 Utilizado sobre todo en producción, con lo que está muy maduro.

 Rendimientos excelentes en entornos multiservidor.
 Seguridad acentuada.
 Acceso a nivel de bloque para excelentes rendimientos descomunal en entrada/salida.

INCONVENIENTES del almacenamiento SAN de Fibra

 El precio.

c. iSCSI

Desde la versión 3.0 de VMware ESX, VMware tuvo la buena idea de incluir un driver en el VMkernel para acceder a nivel
de bloque como en una infraestructura clásica sobre TCP/IP.

Para poder "hablar" iSCSI, hay que crear un iniciador. Existen actualmente dos tipos de iniciadores: Hardware y Software.

Un iniciador hardware es una tarjeta dedicada mientras que un iniciador software está incluido en el VMkernel en la
tarjeta de red.

El protocolo iSCSI encapsula las llamadas SCSI vía TCP/IP. Esto implica una capa suplementaria y, por tanto, una pérdida
de rendimiento. Esta pérdida está ampliamente compensada con un iniciador hardware, ya que en ese momento, es la
tarjeta la que gestiona el trabajo de encapsulación. La velocidad máxima constatada es de 1 Gbits/sec (de hecho, el
límite de la red Ethernet a 1 Gbit).

La llegada del Ethernet 10 Gb debería cambiar la balanza respecto a la fibra óptica (actualmente 8 Gbits/s max) que
quedaría en desventaja con el rendimiento del iSCSI.

Esto es la teoría. La fibra óptica está actualmente en sus días dorados. Además, migrar una red de 1 a 10 Gbits no es
una minucia.

En resumen:

VENTAJAS del almacenamiento iSCSI

 Excelente relación calidad/precio.

 Almacenamiento centralizado para adaptarse a toda la estructura (Ethernet).
 Acceso a nivel de bloque.
 Podría superar los rendimientos de la fibra en un futuro cercano.

INCONVENIENTES del almacenamiento iSCSI

Página 54 de 146
  Rendimientos inferiores respecto a la fibra.
 El paso a 10 Gbits no se hará en un futuro cercano.
 La seguridad: no existe la segregación STOCKAGE (SAN FC) - RED ETHERNET.

d. NFS

VMware también soporta el protocolo NFS, además del almacenamiento centralizado a través de NAS.

Al principio, el debate sobre NFS hizo estragos, siendo el tema del rendimiento uno de los más destacados por sus
detractores. Es cierto que NFS es un protocolo UNIX que nunca ha tenido fama de tener un rendimiento particularmente
elevado…

Y sin embargo, durante 20 años este protocolo se ha enriquecido y se ha convertido en un auténtico estándar de la
industria en materia de almacenamiento y centralización de datos.

Las pruebas de rendimiento actuales muestran que NFS puede ser particularmente potente, a poco que la bahía de
almacenamiento gestione perfectamente el protocolo. Es el caso, por ejemplo, de NetApp cuyas bahías soportan NFS
desde hace mucho.

El protocolo NFS está soportado a nivel de VMkernel, lo que aplica una carga adicional y puede impactar en el rendimiento.

NFS será particularmente apreciado en los entornos donde UNIX sea una parte integrante de los sistemas desplegados.

En resumen:

VENTAJAS del almacenamiento NFS

 NFS es muy estable y fiable.

 Ya existe a menudo en la mayoría de organizaciones.
 Almacenamiento óptimo (Thin provisionning: sólo se asigna lo que se consume).
 Almacenamiento centralizado que se puede adaptar a cualquier estructura (Ethernet).
 Podrá superar el rendimiento de la fibra en un futuro cercano.

INCONVENIENTES del almacenamiento NFS

 Rendimientos inferiores respecto a la fibra.

 El impacto a nivel de rendimiento es fuerte ya que no existen tarjetas hardware para hacer NFS…
 El paso a 10 Gbits no se hará en un futuro cercano.

2. El sistema de archivos VMFS

El sistema de archivos VMFS es el principal sistema de archivos transaccional de VMware. Los objetivos principales son
aportar un sistema de archivos capaz de soportar grandes ficheros y aportar a la vez los mejores rendimientos.

VMFS permite:

 Extender un volumen VMFS sobre varios discos o LUN.

 La gestión de accesos concurrentes.
 256 volúmenes por sistema.
 2 TB por extensión.
 32 extensiones por volumen.
 Un tamaño máximo de 64 TB.

La posibilidad de extender un volumen VMFS sobre varios discos o LUN

Es posible crear volúmenes VMFS extendidos sobre varios LUN. El beneficio es que es posible crear enormes volúmenes
(esto se encuentra a menudo en máquinas virtuales Microsoft Exchange, por ejemplo). Sin embargo, hay que prestar
atención a esta técnica. Si una de las LUN está constituida por un simple RAID0, y un disco se estropea durante el uso,
el volumen entero no volverá a funcionar. Es necesario entonces verificar que el ensamblado de las LUN está montado
con tolerancia a errores.

Gestión de accesos concurrentes

Esta funcionalidad permite que todos los volúmenes sean vistos por todos los hosts a la vez. Esta tecnología permite la
activación de VMOTION, HA y DRS. El VMkernel no bloquea el sistema de archivos, lo que permite los accesos

Página 55 de 146
 concurrentes. El bloqueo se efectúa a nivel de archivo (archivo .lck) para que la máquina virtual no pueda iniciarse más
que en un servidor físico a la vez.

256 volúmenes por sistema

ESX gestiona hasta 256 volúmenes VMFS. Generalmente, nos encontraremos, como máximo, con una decena por host
físico. Esta cifra debe ser tomada con precaución ya que nunca se acercará a un caso real de producción.

2 TB por extensión, 32 extensiones por volumen = 64 TB Max

Cada LUN vista por un servidor ESX no puede pasar de 2 TB. Es posible crear un volumen que tenga 32 extensiones, lo
que significa que, como máximo, VMware ESX soportará volúmenes de 64 TB.

3. Raw Device Mapping

VMware ESX posee un método particular para mapear directamente las LUN sin pasar por un sistema de archivos VMFS
y archivos VMDK: RDM. Hay que distinguir en RDM entre dos métodos de acceso a disco: Virtual y Físico.

 En el caso del RDM Virtual, el acceso a la LUN en modo RAW está totalmente virtualizado por el VMkernel. Esto
permite hacer snapshots, ya que todas las posibilidades que tenemos con los ficheros VMDK estarán también
disponibles. Clásicamente, nos encontramos con este tipo de acceso para los discos grandes que ya existen sobre
servidores de archivos, de datos o de mensajería.
 En el otro caso: RDM físico, todas las peticiones SCSI se envían directamente a la bahía. De este modo, usted verá
sobre su máquina virtual las características de sus discos (como si estuvieran adjuntados en DAS). Típicamente,
encontraremos esta configuración en un cluster MSCS (es la responsabilidad del cluster MSCS, y no del VMkernel,
bloquear los accesos a los discos).

Una falsa creencia consiste en decir que el modo RDM permite obtener rendimientos superiores que un sistema de
archivos VMFS clásico. Esto no se ha demostrado en la cantidad de pruebas efectuadas al respecto. RDM permite ser
flexible. Usted podrá manejar las arquitecturas físicas y virtuales en cualquier momento.

La red
VMware ESX comporta numerosas nociones de red que es necesario conocer para poder comprender las múltiples posibilidades que se ofrecen. En
resumen, he aquí el concepto clave:

Página 56 de 146
1. La conectividad a nivel físico
La conectividad física se utiliza para unir un host ESX con el exterior. En sí misma, esta conectividad no es necesaria ya que las máquinas virtuales
pueden comunicarse entre ellas sin pasar por la red física. En el momento que hay que interactuar con las máquinas virtuales, la conectividad física se
convierte en necesaria.

Como recordatorio, la red física está constituida por switch o routers físicos. Estos últimos aseguran las interconexiones en todas las empresas. Las
tarjetas de red físicas permiten estas conexiones, y están, evidentemente, presentes en los hosts ESX. Una buena práctica consiste en tener varias
tarjetas de red sobre un host ESX.

2. La conectividad virtual
La conectividad virtual permite construir una verdadera infraestructura de red utilizando componentes lógicos integrados
por VMware ESX. Los puntos clave son los siguientes: tarjeta de red virtual, switchs virtuales y grupos de puertos.

Tarjeta de red virtual (vNIC)

Una tarjeta de red virtual o vNIC es un adaptador de red configurado en VMware ESX para ser utilizado por una o varias
máquinas virtuales. El número de interfaces máximo por máquina es de 4. La primera pregunta que a menudo se plantean
los administradores de red es la siguiente: ¿cómo hacer para que cada tarjeta de red tenga una dirección MAC diferente?
La respuesta es fácil. VMware tiene un mecanismo de atribución de direcciones MAC únicas para cada tarjeta de red.

Los "rangos" elegidos por VMware son los siguientes:

 00 :0c :29
 00 :50 :56

Switch virtual (vSwitch)

Un switch virtual es un componente lógico de VMware ESX que equivale a un switch físico de nivel 2. Un switch virtual
existe de 2 modos:

 Público
 Privado

Página 57 de 146
 Los switchs públicos son los que más se utilizan en un entorno ESX. Las tarjetas de red físicas pueden conectarse para
comunicarse con la red externa. Hay que tener en cuenta que una interfaz de red física sólo puede pertenecer a un único
switch virtual.

Los switchs privados no tienen conexiones físicas con la red externa y tampoco están conectados a una interfaz física, lo
que significa que el tráfico de red se transfiere a través del bus del sistema. Esto le permite tener un nivel de aislamiento
completo. Típicamente, es posible crear varias redes con las mismas direcciones IP, montar los controladores de dominio
con los mismos nombres, o construir alguna DMZ.

Un switch virtual está configurado por defecto para permitir el uso de 56 puertos. Cada vNIC configurada sobre una
máquina virtual utiliza un puerto. Es posible configurar un vSwitch para que pueda tener hasta 1.016 puertos. Es posible
configurar algunas opciones sobre cada Switch (y seguramente serán muchas más cuando el switch virtual Nexus 1000v
de Cisco esté disponible para VMware ESX 4).

El filtrado del tráfico

VMware ESX soporta el filtrado del tráfico generalmente conocido por los administradores de red con el nombre de "traffic
shaping policy". El error más común consiste en creer que VMware ESX puede limitar el tráfico descendiente (INCOMING
TRAFFIC). VMware ESX sólo soporta el filtrado de tráfico ascendente (OUTGOING TRAFFIC).

Página 58 de 146
La NIC Teaming

Esta funcionalidad permite a VMware ESX activar otras dos funcionalidades:

 El reparto de carga
 La detección de fallos de red

El reparto de carga

VMware ESX tiene tres métodos para poder repartir el tráfico generado por las máquinas virtuales. Cada método permite
asegurar una alta disponibilidad creando una redundancia en la red.

Virtual port Based

Permite al VMkernel escoger sobre qué tarjeta física va a enviar los datos basándose en su Virtual Port ID. El Virtual port
ID es un elemento asignado a cada tarjeta de red virtual cuando se conecta a un switch virtual. Este método es compatible
con cualquier tipo de switch.

Source Mac Based

Igual que en el reparto de carga Virtual port Based, los switchs son compatibles. Sin embargo, en lugar de basarse sobre
el Port ID, el reparto sobre las tarjetas de red físicas se hará combinando la dirección MAC de origen con un algoritmo
de selección interno en VMware ESX. Este método no se aprecia según las pruebas como una mejora en producción (por
ello, el reparto por defecto a partir de la Versión 3 es Virtual port Based).

IP Based
Página 59 de 146
 El último método consiste en repartir las cargas basándose en la dirección IP de destino. Este método es mejor en cuanto
a redundancia y reparto equilibrado, pero necesita que la red física esté configurada correctamente. Habrá que prever la
configuración de los protocolos 802.3ad o Etherchannel (Cisco) . De todos modos, nos podemos hacer una idea de que
este tipo de casos es raro y deberá revisarse en colaboración con los equipos de red.

Detección de fallos de red

VMware ESX utiliza dos métodos diferentes para detectar los fallos de red:

Link Status only

En esta configuración, la detección es muy simple. La tarjeta física detecta si sigue habiendo un link entre ella y el switch
de red físico. Es un método que funciona en la mayoría de casos.

Beacon Probing

Existe un caso donde la ruta no es accesible aunque el link entre la tarjeta de red y el switch físico se mantenga activo.
Hay que pensar en un caso donde el switch físico conectado a la tarjeta física no tenga acceso al switch que permite
alcanzar su destino.

Veamos un esquema que nos permitirá apreciar mejor la situación:

Página 60 de 146
 La ruta 1 está identificada como fallida, por lo que se toma la ruta 2. Ese fallo no habría sido detectado en el primer caso.
El envío del paquete permite darse cuenta de la situación. Sin embargo, esto supone una sobrecarga de tráfico de red,
además de un cierto lapso, ya que la ruta debe probarse antes de enviar el tráfico. Además, se considera indispensable
que las tarjetas de red físicas estén conectadas a switchs físicos diferentes para funcionar correctamente. Atención, este
método comporta también ciertos riesgos, ya que pueden detectarse fallos sin que haya habido fallo o corte en la
comunicación.

Los Ports Group

Los Ports Group son componentes lógicos que permiten agrupar varios puertos virtuales en un switch virtual para poder
atribuirles configuraciones idénticas (seguridad, configuración del tráfico, reparto de carga o hasta VLAN).

Existen actualmente tres tipos de Port Group:

Service Console

Los Ports Group Service Console permiten configurar el acceso a la consola de control de VMware ESX y sólo pueden
tener una IP única.

VMkernel

Sirve para configurar VMOTION o permitir acceder a los elementos de almacenamiento basados en red (NFS o iSCSI).
Igualmente, debe configurarse una dirección IP para poder comunicarse con los elementos de almacenamiento o para
comunicarse con otro host ESX para poder utilizar VMOTION.

Virtual Machine

Este Port Group permite a las máquinas virtuales comunicarse. Cada máquina virtual que tenga una o más tarjetas de
red virtuales deberá estar enlazada a un Port Group «Virtual machine». Cada vNIC no puede tener más de una
configuración de Port Group a la vez, aunque una máquina virtual que pueda tener hasta 4 interfaces de red virtuales,
puede estar configurada de forma que cada interfaz de red se encuentre en un Port Group diferente.

Página 61 de 146
Seguridad y Virtualización
Repaso de los grandes principios de seguridad
Antes de abordar la seguridad de la virtualización en particular, es bueno hacer un repaso sobre la seguridad de los
sistemas de información.

La seguridad de los sistemas de información reposa sobre lo que se llama el capital informativo. Éste representa la
información de la empresa, por ejemplo, la clientela, la concurrencia, el saber hacer, el círculo de accionistas, los métodos
de fabricación, las patentes, etc. Se trata de activos materiales y, sobre todo, inmateriales, de los que es difícil imaginar
el coste real en caso de pérdida, aunque es casi seguro que, si algo pasara, la empresa podría verse rápidamente obligada
a cerrar sus puertas.

"Lo inmaterial está en el corazón de la estrategia de las empresas que crean valor: el resultado más sorprendente de
nuestro estudio es que, el 60% del valor de las principales empresas europeas se explica por su capital inmaterial" según
Ernst & Young.

La seguridad de los sistemas de información consiste en:

 Garantizar que las personas autorizadas pueden acceder al sistema de información (Disponibilidad).
 Garantizar que sólo las personas autorizadas tienen acceso al sistema de información de la empresa
(Confidencialidad).
 Garantizar que los elementos considerados del sistema de información son exactos y completos (Integridad).
 Garantizar que el acceso y tentativas de acceso a los elementos considerados del sistema de información son
trazados y que las trazas son conservadas y explotables (Trazabilidad).

Usted encontrará a menudo la noción DICT entre expertos de seguridad a lo largo de varios proyectos.

Los organismos americanos no consideran la trazabilidad como un criterio de seguridad y proponen un modelo llamado
CIA (Confidentiality - Integrity - Availability).

Página 62 de 146
 Hay diversas y variadas amenazas que pesan sobre los sistemas de información. A poco que existan vulnerabilidades
técnicas u organizativas en una empresa, esas amenazas serán capaces de aprovecharlas. A partir del momento en que
la amenaza o la vulnerabilidad están presentes, existe un riesgo.

Para verificar que el riesgo es real y tangible, los expertos en seguridad efectúan lo que comúnmente se llama un análisis
de riesgos. Sin entrar en detalles, el análisis de riesgos permite afrontar:

 la probabilidad de aparición de una amenaza que aproveche una vulnerabilidad.

 el impacto generado por esta explotación.

Se deduce una matriz por cada riesgo proponiendo una escala de valores.

Ya se sabe que conocerlo todo perfectamente no es fácil. Cuántas personas piensan hoy en día que el avión no es un
medio de transporte muy seguro, y resulta que estadísticamente es uno de los más fiables mientras que, en realidad, es
el transporte en automóvil el que comporta mayor peligro. Sin embargo, los usuarios no tienen la impresión de estar en
riesgo cada vez que conducen. Para tener una visión objetiva, a veces es necesario ver las cosas desde fuera.

Las amenazas se descuidan a menudo por falta de tiempo o recursos. Sin embargo, los sistemas de información tienen
un número incalculable de puntos de entrada. Un simple servidor debe estar protegido a todos los niveles para poder
garantizar el principio del DICT.

Un ejemplo:

Página 63 de 146
Reto nº 1: asegurar la disponibilidad de las infraestructuras virtuales
Como ya hemos visto, la Disponibilidad es un elemento esencial de la seguridad de los sistemas de información.
Asegurarla en entornos virtuales debe ser, por tanto, primordial. Existen muchas posibilidades de asegurar la
disponibilidad de un conjunto de servicios, sin embargo también existen muchas amenazas que pueden atentar contra
esta disponibilidad. Sabiendo cómo se define una infraestructura virtual (ver el capítulo anterior), es necesario asegurar
al máximo la disponibilidad de los elementos siguientes:

 La alta disponibilidad de los servidores.

 La alta disponibilidad del almacenamiento.
 La alta disponibilidad de las máquinas virtuales y de las aplicaciones.
 La alta disponibilidad de la red.
 La supervisión del conjunto de infraestructura.

1. La alta disponibilidad de los servidores

La alta disponibilidad de los servidores o "hosts" es un elemento determinante para garantizar que las máquinas virtuales
que haya, heredan igualmente esa disponibilidad. Los servidores deben tener mecanismos que permitan paliar en mayor
o menor medida los errores de hardware. Por ejemplo:

 Ventilación redundante. En caso de error de un ventilador, otro debe poder asumir la carga, para continuar con
las operaciones.
 Alimentación redundante. Hoy en día, los servidores a menudo tienen 2 alimentaciones. Es necesario que, en
caso de que falle una no perjudique a las demás. Algunos fabricantes no aíslan lo suficiente unas alimentaciones
de otras, lo que conlleva, a veces, al fallo total de todas en caso de problemas.
 CPU redundantes. Los fabricantes proponen que las CPU estén aisladas unas de otras para evitar la parada de
sistema en caso de error; desgraciadamente, según las pruebas elaboradas en nuestros laboratorios, está
comprobado que VMware ESX no soporta la parada de un procesador físico. El servidor se parará inmediatamente.
 Memoria redundante. Las placas de memoria también deberían ser independientes. Es posible que algunas de
ellas fallen, y cuantas más haya, mayor es el riesgo de fallo de alguna. Por eso es importante que la pérdida de
una placa de memoria no entrañe la parada total de las actividades del servidor. A nivel de pruebas, está
comprobado que los resultados son diferentes en función de los fabricantes. VMware parece gestionar

Página 64 de 146
 correctamente la pérdida de memoria física siempre y cuando el fabricante gestione correctamente a nivel de
hardware la excepción generada. Es preferible asegurarse de que las placas de memoria provienen del mismo
fabricante y que tienen las mismas referencias, lo que evita comportamientos erráticos que pueden conducir a
una PSOD (Purple Screen Of Death).
 Tarjeta de red redundante. Los servidores deben tener suficientes tarjetas de red para poder paliar la pérdida
de conectividad de una de éllas. Generalmente, este tipo de error está bien soportado (p.ej.: VMware con el NIC
Teaming).

En VMware, la PSOD es equivalente a la BSOD (Blue Screen Of Death) de Microsoft Windows.

 Discos duros redundantes. A menudo, el hipervisor se instala en local. Debe estudiarse correctamente el modo
Boot From San de VMware ESX (que permite almacenar el hipervisor sobre una SAN) antes de instalarlo (sobre
todo desde un punto de vista de coste). El hipervisor debe encontrarse sobre discos RAID 1 o 5 (ver otros RAID
dependiendo el soporte del fabricante). Hay que evitar absolutamente el RAID 0, que no nos permitirá asegurar
la pérdida de un disco.

La alta disponibilidad de los servidores puede también implicar el uso de material especifico llamado hardware tolerante
a errores. Éste permite paliar cualquier problema de hardware sin impactar sobre la operatividad. Todo elemento de un
servidor Fault Tolerant puede fallar sin perjudicar al servidor y a los servicios presentes.

Puede haber un impacto sobre los niveles de rendimiento, pero los servicios continúan disponibles.

2. La alta disponibilidad del almacenamiento

El almacenamiento es crucial para asegurar la disponibilidad de la información. Es aquí donde reside el conjunto de datos.
Hoy en día, los fabricantes de bahías SAN/NAS incluyen algunos mecanismos que permiten paliar los errores mas críticos:

 Fallos de disco. Los fabricantes han incluido mecanismos RAID probados. Algunos no dudan en sacar versiones
RAID que permiten alcanzar una muy alta disponibilidad, por ejemplo el RAID DP (Doble paridad). Además, los
discos tienen generalmente un MTBF (Mean Time Before Failure o tiempo medio antes de un fallo) muy superior
al de los discos clásicos de los servidores.
 Fallos de los Storage Processors (SP). Los SP permiten asegurar todas las operaciones efectuadas en las bahías
SAN. Generalmente, los fabricantes permiten tener SP redundantes para paliar errores.
 Fallos a nivel de alimentación. Las bahías de almacenamiento también pueden ser sensibles a los problemas
de alimentación. Por tanto, las bahías deben poseer obligatoriamente varias alimentaciones aisladas unas de
otras.
 Fallo de ventiladores. Las bahías de almacenamiento también se refrigeran. Aunque no se calientan tanto como
los servidores, es esencial conservarlas a temperaturas convencionales.
Página 65 de 146
  Fallos de red. Los fabricantes deben poder paliar los errores de red de una o varias tarjetas de red o HBA. Hasta
hoy, VMware gestionaba completamente el Multipathing. Parece que en la próxima versión (VMware ESX 4), el
fabricante de bahías de almacenamiento podría gestionarlo completamente, lo que permitirá asegurar una mejor
disponibilidad de los datos.

Existen técnicas que permiten asegurar la alta disponibilidad del almacenamiento virtualizándolo directamente. Se puede
citar, por ejemplo, la sociedad DATACORE que posee un programa que permite abstraerse del aspecto material de las
bahías de almacenamiento.

Gracias a este programa, se puede hacer creer a los servidores que el espacio de almacenamiento es ilimitado o, por el
contrario, que es muy reducido. Igualmente se puede mejorar la provisión de espacio, repartir la carga, gestionar la
replicación de LUNS, etc. El único punto débil reside en los servidores que tienen la capa de abstracción. Estos son muy
críticos y concentran las E/S. Los rendimientos pueden verse ligeramente afectados.

3. La alta disponibilidad de las máquinas virtuales y de las aplicaciones

La alta disponibilidad de las máquinas virtuales y de las aplicaciones es un tema mucho más delicado ya que hoy en día
no existe ninguna solución técnica sobre el tema. Primero, hay que asegurarse de que la máquina virtual está presente
sobre una bahía de almacenamiento centralizado y que ésta está redundada. Esto equivale a un sobrecoste importante.
Evidentemente, también hay que asegurarse de que las rutas de red están disponibles y que los servidores hosts que
alojan a las máquinas virtuales están redundados.

Hay que crear una arquitectura llamada "Full Mesh".

Página 66 de 146
 Por tanto, la problemática de la disponibilidad de las máquinas virtuales permanece intacta. Si un servidor falla, la
máquina virtual será retomada por otro servidor, aunque existe un lapso de tiempo durante el que la máquina virtual no
estará disponible.

Para paliar el problema, existen dos enfoques:

 Crear una alta disponibilidad a nivel de aplicación o de sistema operativo invitado.

 Crear una alta disponibilidad a nivel de máquina virtual (y no a nivel del host).

En el primer caso, esto depende totalmente de la aplicación y del sistema.

Por ejemplo, a nivel de sistema, se puede crear un cluster Microsoft MSCS. En este caso, dos máquinas virtuales están
en cluster. Si una máquina virtual se cae, la otra retoma automáticamente el relevo. La creación del cluster MSCS es
posible sobre VMware; sin embargo, es necesario tener en cuenta muchos aspectos (mas allá del ámbito del libro).

A nivel de aplicación, por ejemplo, se puede crear clusteres de bases de datos con ORACLE y RAC (Real Application
Clusters). Aunque esto no está soportado por Oracle, es totalmente realizable (ver igualmente
http://tinyurl.com/phqowk).

Es necesario calificar el entorno con numerosas pruebas para asegurar la coherencia del ensamblado, lo que implica un
sobrecoste considerable.

En el segundo caso, VMware parece empezar a proponer soluciones. La próxima versión de VMware ESX introducirá la
noción de máquina virtual "Fault tolerant". El principio es crear una máquina virtual primaria, a la vez que un clon, que
recibirá todas las instrucciones enviadas a la máquina primaria. De hecho, las dos máquinas virtuales son totalmente
idénticas. El principio es muy simple aunque, técnicamente hablando, extremadamente complejo. Una vez más, antes
de lanzarse al uso de este tipo de soluciones, habrá que validar esta opción con departamentos especializados…

Página 67 de 146
 Sea cual sea la solución, la disponibilidad de las máquinas virtuales y de las aplicaciones debe hacer sus pruebas. VMware
propone un enfoque, aunque corresponde igualmente a los fabricantes de aplicaciones proponer soluciones (integración
con MSCS, clustering nativo, enfoque modular, etc.).

4. La alta disponibilidad de la red

La alta disponibilidad de la red es un elemento que VMware no trataba hasta ahora. Había que contentarse con NIC
Teaming y algunas funcionalidades integradas en la capa de red de VMware ESX. VMware es muy consciente de que la
red se ha convertido en un elemento crítico en todas las infraestructuras.

Existen muchas posibilidades, a nivel de redes físicas, para asegurar una alta disponibilidad, o todo aquello que está
indirectamente relacionado:

 Gestión de tipos de flujo.

 Protocolos utilizados.
 802.1Q.
 802.1X.
 STP & RSTP.
 QoS.

Lamentablemente es imposible aplicar estos últimos a nivel de switch virtual.

Así pues, desde hace algunos años, Cisco está invirtiendo en una colaboración con VMware (también han comprado parte
de su mercado).

Hace poco, Cisco comunicó a todos los niveles la llegada de la virtualización en los mundos de la red con productos
innovadores como el Nexus 1000v.

El objetivo del Nexus 1000v es substituir al vSwitch de nivel 2 presente en VMware ESX, para ofrecer todas las
funcionalidades que propone un Switch físico. El objetivo es, en cualquier caso, elevar las máquinas virtuales desde un
punto de vista de red, al mismo nivel funcional que las máquinas físicas.
Página 68 de 146
 El Nexus 1000v sólo será compatible con vSphere.

No obstante, la alianza con Cisco debería permitir una mejora en la alta disponibilidad de la red.

5. La supervisión de la infraestructura virtual

A menudo, no es suficiente con configurar una arquitectura de alta disponibilidad para asegurarse la disponibilidad de los
datos y los sistemas. Es igualmente necesario poder verificar, en todo momento, por ejemplo, el estado de los
componentes, la disponibilidad de los servicios, la temperatura de los servidores, la accesibilidad de los datos, etc.

Todo esto se resume en una palabra: supervisión.

Antes de seguir, es indispensable hacernos las preguntas siguientes:

 ¿Qué se necessita supervisar?

 ¿Cómo se traspasa la información de supervisión?
 ¿Quién supervisa?
 ¿Qué métricas se utilizan?
 ¿Cuándo habrá que desencadenar procesos automáticos o manuales?

Para asegurar la disponibilidad de su sistema de información, es conveniente supervisar el conjunto de servicios que lo
componen. Para una arquitectura virtual, esto implica supervisar, al menos:

 Los servidores hosts.

 El almacenamiento.
 La red.
 Los sistemas invitados, aplicaciones y servicios críticos.

El traspaso de información es muy importante. A menudo, los protocolos de supervisión comportan fallos de seguridad
por lo que será conveniente utilizarlos con parsimonia y teniendo en cuenta los riesgos inherentes a su utilización.

Habrá que determinar quién supervisa la infraestructura virtual. De ello se desprende un conjunto de procedimientos,
una guía de buenas prácticas, y la formación del personal capacitado para identificar las métricas importantes.

Página 69 de 146
 Efectivamente, todo puede supervisarse, aunque toda la información de supervisión no tiene la misma importancia. Habrá
que seleccionar y decidir las métricas que parecen válidas o no.

Las personas encargadas de la supervisión deberán poder desencadenar los procedimientos cuando sea necesario.

La supervisión es un tema que debe trabajarse antes de la puesta en producción de una infraestructura virtual y que
necesitará ser mejorada constantemente a medida que evolucionan los procesos y las tecnologías.

a. La supervisión de los servidores hosts

Los fabricantes de servidores llevan trabajando desde hace mucho en la supervisión material de sus servidores. Esto
permite transmitir las alertas que conciernen a todos los componentes internos. Existen varios enfoques para la
supervisión de material:

 A través de los agentes que se instalan en la Service Console. Estos pueden recoger los datos y enviarlos a un
colector centralizado (por ejemplo el agente HP Insight Manager para VMware).

 A través del Health Status de VMware ESX 3.5, desde la versión Update 2. La información es menos precisa pero
no es necesario ningún agente.

Página 70 de 146
  A través de las célebres SNMP. Sin embargo, este modo no es aconsejable, ya que SNMP no está securizado por
defecto y puede hacer circular información confidencial por la red.

Sea cual sea el modo de supervisión adoptado, habrá que interesarse particularmente en:

 los procesadores,
 la memoria,
 los discos locales,
 las tarjetas de red.

Estos elementos no son exhaustivos. Es posible añadir otros que haya que a supervisar según el tipo de servidor escogido.

b. La supervisión del almacenamiento

Ya que el espacio de almacenamiento reside a menudo en SAN/NAS, los constructores facilitan diferentes métodos para
supervisar sus equipos:

 a través de interfaces propietarias,

 a través del envío de mensajes SNMP.

Página 71 de 146
c. La supervisión de la red

La supervisión de una infraestructura virtual pasa igualmente por la supervisión de la red física y virtual. La red física
puede ser supervisada de mil y una formas (existen multitud de proyectos Open Source).

La supervisión de la red es por el momento muy reducida a nivel de VMware ESX. Sin embargo se puede supervisar:

 la utilización media,
 la tasa de transmisión,
 la tasa de recepción,
 el número de paquetes recibidos y transmitidos.

Página 72 de 146
d. La supervisión de los sistemas invitados, aplicaciones y servicios críticos

La supervisión de los sistemas invitados está bien gestionada sobre VMware ESX. Es posible recibir mucha información
sobre, por ejemplo, la tasa de uso de los discos en E/S, el consumo en CPU y memoria, etc. Estos criterios pueden
visualizarse en tiempo real o en un resumen de histórico. Virtualcenter puede recoger la información de los servidores y
de las máquinas virtuales.

Últimamente, Virtualcenter Update 4 permite resumir, en una sola página, los criterios más importantes, lo que permite
tener una visión global rápidamente.

El problema es que un host no tiene conocimiento del sistema invitado, o sólo es consciente parcialmente (a través de
las VMware tools). Esto provoca más problemas, especialmente el no supervisar las aplicaciones y servicios críticos
ejecutados en el sistema invitado. Habrá que remitirse a las herramientas que permitan tener una visión más cercana
del sistema invitado y de las aplicaciones que se ejecutan.

Existen muchas empresas que se dedican a ofrecer soluciones en este mercado tan prometedor:

 Sysload Software
 HP
 ManageEngine
 Monitis

Página 73 de 146
 Las empresas han desarrollado incluso sus propios módulos de supervisión gracias al Open Source.

Reto nº 2: garantizar la integridad y la confidencialidad de los

servidores VMware ESX

1. El problema del aislamiento

Según el primer principio de la virtualización, un proceso ejecutado en una máquina virtual está totalmente
compartimentado. Es imposible que pueda comunicar o modificar un proceso de la máquina host o de otra máquina
virtual.

Sin embargo, una máquina virtual se comunica de forma permanente con su host a través de los canales encubiertos, lo
que el VMkernel intercepta a través de una backdoor VMware. Ésta es utilizada incluso por las VMware Tools para poder
interactuar entre el sistema host y el sistema invitado.

La introducción del juego de instrucciones Intel VT y AMD-V mejora el aislamiento, gracias a un control a nivel de
instrucciones que provienen de la máquina virtual a la host.

La compartimentación se hace por los mecanismos internos de VMware (aunque el hardware contribuye a garantizar el
aislamiento). Esta capa es, evidentemente, vulnerable a errores humanos, por lo que hay un riesgo significativo.

Como prueba, miremos el histórico de VMware ESX.

En 2008, constatamos que el número de vulnerabilidades está comprendido entre 0 y 3 por mes, lo que es poco, teniendo
en cuenta la complejidad del sistema. Sin embargo, esto muestra igualmente que los fallos existen y que VMware ESX
no está en ningún caso exento de ellos.

Hasta ahora, en VMware ESX 3, ningún fallo se ha determinado como crítico. No hay PoC (Proof of Concept) que permita
comprometer el hipervisor, por ejemplo, a partir de una máquina virtual. Por el contrario, sí que se da el caso para otro
producto de VMware: VMware Workstation. Sin embargo, el 29% son vulnerabilidades llamadas altamente críticas, lo
que significa igualmente que el riesgo está presente.

Página 74 de 146
 Los principales posibles impactos en caso de explotación son muy sugerentes:

 Acceso al sistema: pérdida del aislamiento.

 DoS: ataque a la disponibilidad.

Dos ejemplos concretos:

CVE-2007-4496: un fallo podía permitir a una cuenta privilegiada en un sistema invitado provocar una corrupción de
memoria en un proceso del host, para hacer ejecutar a este último un código arbitrario.

CVE-2007-4497: un fallo podía permitir a un sistema invitado provocar un mal funcionamiento en los procesos del host.

Es importante situar estos datos en su contexto. Las principales vulnerabilidades vienen de la Service Console que es, de
hecho, un sistema operativo Redhat 3. VMware no es responsable en absoluto de las vulnerabilidades de la distribución
Linux RedHat.

En conclusión, es esencial tener en cuenta que dos máquinas virtuales no pueden garantizar el mismo grado de
aislamiento que dos máquinas físicas.

a. Riesgo a nivel de la capa de virtualización

VMware integra mecanismos de seguridad a nivel de la capa de virtualización que comprende el VMkernel y el VMM.

 La protección de memoria está asegurada, de forma que se reserva el hyperspacing, lo que significa que la máquina
virtual no puede leer o escribir en otros espacios de memoria salvo los que están reservados por el VMM en esta
máquina virtual.
 El VMM soporta la propagación del bit No Execute (páginas de memoria marcadas como no ejecutables) en
procesadores virtuales. Esto permite a los sistemas invitados, como Microsoft Windows XP o Windows 2003,
activar la función "Data Execution Prevention".

El único riesgo que está considerado como plausible sigue siendo el que se pueda aprovechar una vulnerabilidad que
pueda conllevar la ejecución de código arbitrario a nivel de VMM o de VMkernel. Vistas las protecciones, parece que un
DoS (Deny of Service) debe ser más temible que una toma de control del hipervisor o de las máquinas virtuales.

Página 75 de 146
 Aquí mostramos como ayuda un boceto de los análisis de riesgos:

Amenaza Probabilidad Posible Contramedidas Comentario

impacto

Ataque tipo Buffer Posible Disponibilidad El VMM soporta la propagación del bit Un ataque tipo Buffer
Overflow NX/XD. Visto que el traductor binario no Overflow es posible aunque
opera sobre las traducciones de más de 12 difícil. Es necesario que quien
instrucciones, es difícil imaginar tener un quiera llevarlo a cabo tenga un
Buffer OverFlow. nivel de conocimientos muy
alto.

Utilizar el Improbable Disponibilidad Los servidores ESX no dan la posibilidad a la

hyperthreading máquinas virtuales de utilizar el
hyperthreading; sin embargo, muchas
máquinas virtuales pueden utilizar al mismo
tiempo el mismo núcleo. Será extremadamente
difícil utilizar esta vulnerabilidad para crear un
DoS.

Aprovechar el uso de Improbable Disponibilidad Cuando una máquina virtual pide memoria al El hyperspacing es realmente
memoria del VMkernel, éste pone a cero el conjunto de difícil en este caso concreto.
VMkernel páginas. Teóricamente, la máquina virtual
tiene un control total de su espacio de memoria
y ninguna otra máquina puede acceder.

Fuga de memoria Imposible N/A Cuando una máquina virtual intenta modificar La protección está
debido a una una página de memoria compartida, recupera perfectamente asegurada
compartición una copia privada gracias a un ingenioso
transparente de mecanismo.
páginas

Página 76 de 146
b. Riesgo a nivel de la capa de red

La capa de virtualización de la red permite que las máquinas virtuales se comuniquen con la red física, así como que se
integren con SAN/NAS gracias al protocolo iSCSI o NFS.

VMware ESX propone algunos mecanismos de red para asegurar la protección del nivel 2:

 El Promiscuous Mode: por defecto en modo Reject, lo que permite impedir a la máquina virtual escuchar el
tráfico de red sobre la interfaz conectada al vSwitch. Si esta opción está activa, nada impide a un usuario seguir
todo el tráfico de red del vSwitch con una utilidad llamada Wireshark o Ethereal.
 Mac Address Changes: por defecto en Accept, este modo permite rechazar los paquetes donde la dirección MAC
no corresponde a la inscrita en el archivo .Vmx de la máquina virtual. La activación de este modo permite bloquear
los ataques tipo Mac spoofing.
 Forged Transmits: impide a una VM que transmita paquetes ARP creados con el objetivo de redirigir el tráfico.
Esto impide, teóricamente, los ataques de tipo Arp Spoofing y Cache Poisoning.

Como habrá visto, la capa de red de VMware permite prevenir ataques que serían difíciles de prever en una infraestructura
clásica.

Sin embargo, ya que la capa de red sigue siendo software, es posible que aparezcan los siguientes riesgos:

 Una vulnerabilidad que entrañe un Deny of Service. Ninguna prueba de estrés tipo Fuzzing ha sido probada
realmente contra la capa de virtualización de VMware (en cualquier caso ningún estudio público). Cabe la
posibilidad de que se produzcan disfunciones a este nivel.
 La intercepción del tráfico VMotion. Aunque no se ha demostrado, existe un riesgo sobre VMotion, ya que el
contenido de la memoria de un sistema invitado transita sobre la red LAN. Si el tráfico fuera interceptado y
descifrado por una persona malintencionada, cabría la posibilidad de que consiguiera suficiente información para
penetrar en el sistema invitado.
 La realización de ataques de red a nivel 2 ó 3 (Mac Spoofing, Arp Spoofing, IP spoofing, etc.).
 Intercepción de tráfico de red y escuchas.
 Evitar el aislamiento de la red (VLAN).

Aquí mostramos como ayuda un boceto de los análisis de riesgos:

Amenaza Probabilidad Posible impacto Contramedidas Comentario

Ataque sobre la Improbable Confidencialidad La conexión entre Switch virtual es casi imposible.
integridad de los
Switch virtuales Integridad Los Switch virtuales no comparten la conexión física. No es
posible usar un señuelo como en los Switch físicos clásicos.

Cada Switch virtual tiene su propia tabla de transferencias. No

existe ningún mecanismo que permita transferir esta tabla.

Ataque a través de Improbable Disponibilidad Los Switch virtuales no tienen conocimiento de la red a través
una VM enlazada a un de entidades externas. Una máquina virtual no puede
Switch virtual modificar la tabla de un Switch, porque no está diseñado para
evolucionar.

Página 77 de 146
 Amenaza Probabilidad Posible impacto Contramedidas Comentario

Tráfico interno de Imposible Confidencialidad Es importante configurar el tráfico por VLAN a nivel de
VLAN VMware ESX.

Los expertos en red creen que la minimización del soporte a

nivel de las VLAN aporta un grado de seguridad
suplementaria.

Ataque de red a través Improbable Confidencialidad El uso de Switch físicos separados por los diferentes Switch
de las VLAN de los virtuales es igualmente una buena idea
Switch virtuales Integridad

Disponibilidad

Brecha en la red por Posible Confidencialidad El etiquetado de las VLAN permite evitar la confusión.
error humano
Disponibilidad

MAC spoofing Posible Confidencialidad Parametrizando las opciones de seguridad a Reject a nivel de
Switch virtual para el modo Mac Address Changes y Forged
Transmits, este ataque es totalmente imposible.

c. Riesgo a nivel de la Service Console

Como habrá visto anteriormente, la Service Console es, de hecho, un sistema operativo Linux RedHat. Se trata, en
realidad, de una máquina virtual especial gestionada por el VMkernel. Si la Service Console estuviera en compromiso, el
conjunto de máquinas virtuales del host podría estarlo igualmente.

La Service Console no es un sistema exento de defectos. Se pueden instalar muchos servicios y paquetes. Existen
protocolos no securizados: FTP, Telnet, NIS, SNMP, SMTP, etc. Además, los desarrolladores y fabricantes aportan su
granito de arena creando paquetes dedicados especialmente a la Service Console para la copia de seguridad y
Supervisión.

Unos ejemplos de riesgos:

 Explotación de una vulnerabilidad de software/conceptual/protocolaria que podría comprometer la Service Console.

Típicamente el compromiso del SSH V1, la escucha de tráfico Telnet, FTP o incluso SMTP.
 Explotación de debilidades Unix inherentes: programa con el bit setuid/setgid, contraseña débil, etc.

Página 78 de 146
 Aquí mostramos como ayuda un boceto de los análisis de riesgos:

Amenaza Probabilidad Posible impacto Contramedidas Comentario

Infiltración en la Posible Disponibilidad No autorizar las conexiones salvo Por defecto el ESX posee un firewall
Service Console si vienen de una red protegida. configurado para no dejar entrar
desde una red externa Integridad ninguna conexión externa.
No debe permitirse ninguna
conexión que venga directamente Los únicos puertos abiertos de salida
de Internet. son los estrictamente necesarios para la
comunicación entre los diferentes
elementos de la Infraestructura.

Intercepción de las Posible Disponibilidad Todas las comunicaciones del La única posibilidad sería que la
comunicaciones de la cliente están cifradas con SSL conexión se hiciera desde una red
Integridad
Service Console (AES 256 y RSA 1024). WAN y que tuviera lugar un ataque
tipo MIM (Man In The Middle) (ya que
pocas personas observan las
certificaciones en la conexión).

Acceso a la Service Posible Disponibilidad El servidor Tomcat instalado en el

Console a través del VMware ESX se ha modificado
Browser Web para soportar únicamente la
administración y la supervisión.

Ataque de la Service Posible Disponibilidad VMware es muy activo a la hora de La reactividad de VMware en este tema
Console a través de sacar rápidamente parches para la es, por el momento, ejemplar.
Integridad Service Console.
una vulnerabilidad de
RedHat

Página 79 de 146
 Amenaza Probabilidad Posible impacto Contramedidas Comentario

Ataque de la Service Posible Disponibilidad Los servicios no securizados no Durante los períodos de mantenimiento,
Console a través de están activos por defecto. es posible que puertos como los de FTP
Integridad
servicios no o SMB permanezcan abiertos. Sin
securizados embargo, la ventana de apertura es muy
reducida.

Ataque de la Service Posible Disponibilidad El número de aplicaciones que

Console a través del utilizan setuid/setgid se reduce al
Integridad
cambio de permisos mínimo.

Ataque de la Service Improbable Disponibilidad ESX sólo soporta SNMPv1 y en

Console a través de read-only. Por tanto, no se puede
SNMP parametrizar nada.

Ataque de la Service Improbable Disponibilidad Hay que aislar la Service Console

Console a través de la con una VLAN.
red clásica Integridad

Ataque de la Service Posible Disponibilidad VMware ESX tiene un Firewall

Console a través de configurado por defecto para sólo
Integridad
puertos clásicamente autorizar de salida los puertos 902,
usados 80, 443 y 22. No se autoriza en
entrada.

Un DoS sobre estos puertos es

posible. Poner un Firewall
Hardware delante de la Service
Console es una opción a tener en
cuenta.

El firewall está basado sobre

Iptables, lo que le permite llegar
lejos en su configuración.

Ataque de la Service Improbable Disponibilidad La mayoría de agentes de copia de Es cierto que cuanto mayor es el
Console a través de seguridad y supervisión probados número de puertas abiertas, mayor es el
sus aplicaciones o utilizan derechos reducidos que no riesgo.
servicios permiten a un atacante tomar
complementarios posesión de la Service Console.

Uso de la Service Probable Disponibilidad Verificación de la integridad de los La Service Console es un sistema
Console como un archivos y de los procesos en RedHat completamente customizado y
Integridad
sistema Linux RedHat marcha. Exportación de los modificado para ejecutar solamente los
clásico Confidencialidad archivos de logs a un punto central procesos estrictamente necesarios en la
de forma automática. comunicación con el Vmkernel. Toda
instalación de paquetes RedHat
suplementarios puede añadir
vulnerabilidades que no serán tratadas
por los parches de VMware.

Código Posible Disponibilidad El aislamiento sobre una red El uso de código malintencionado es
malintencionado protegida reduce en gran medida mucho mas difícil, ya que la Service
este tipo de amenaza. Console es una versión restringida de
un sistema RedHat 3.

VMware, en sus Best Practices, no

aconseja hoy en día el uso de un agente
antivirus.

Página 80 de 146
 Amenaza Probabilidad Posible impacto Contramedidas Comentario

Modificación no Posible Integridad Los archivos y directorios

autorizada de siguientes deberán ser verificados
servicios principales regularmente desde un punto de
de VMware ESX vista de integridad :

/etc/profile,

/etc/ssh/sshd_config,

/etc/pam.d/system_auth,

/etc/ntp,

/etc/ntp.conf,

/etc/passwd,

/etc/group,

/etc/sudoers,

/etc/shadow,

/etc/vmware/

Hacer una copia de seguridad

puede ser igualmente útil.

Ataque de Internet o Posible Disponibilidad No usar el cliente VI Infrastructure

mala utilización de la en más de un sitio.
Service Console Integridad
No se recomienda el uso directo de
la Service Console. No debe
utilizarse (a través de SSH) salvo
en los casos precisos que no
puedan ser resueltos a través del
cliente VI.

DoS rellenando las Posible Disponibilidad Hay que crear diferentes Si la partición Root está llena, es
particiones (Root por particiones para /home, /tmp, y posible un DoS.
ejemplo) /var/log. Éstas son las únicas
particiones que probablemente
pueden rellenarse de forma
automática.

d. Riesgo a nivel de las máquinas virtuales

Aunque la virtualización con VMware ESX no modifica de forma alguna el sistema invitado, introduce nuevas
vulnerabilidades :

 El uso de las VMware Tools permite a una VM disponer de funcionalidades tipo Copy/Paste, Shared Folders, Drag
& Drop y Memory Ballooning. Estas funcionalidades, aunque son extremadamente prácticas, permiten la fuga de
información, el agotamiento de los recursos de un sistema invitado o el error humano…
 El Snapshot. Aunque esta funcionalidad es extraordinaria, su mala utilización puede resultar catastrófica.
 La monopolización de los recursos por una sola máquina virtual en detrimento de las otras.

Página 81 de 146
  Las máquinas virtuales no son más que simples archivos. Por tanto, es muy fácil importarlas y exportarlas… ¡con
todos los datos que haya! El riesgo llamado Rogue Virtual Machine o máquina virtual espía puede ser algo
corriente…

Aquí mostramos como ayuda un boce de los análisis de riesgos:

Página 82 de 146
 Amenaza Probabilidad Posible impacto Contramedidas Comentario

Ataque de una Imposible Disponibilidad El VMkernel y la VMM controlan el Evidentemente, las máquinas
máquina virtual a aislamiento. virtuales pueden comunicarse entre
través de una ruta de ellas si se encuentran sobre el
otra VM sobre el mismo Switch virtual o si están
mismo servidor ESX enlazadas al mismo Switch físico.

DoS a través de un Posible Disponibilidad Es posible parametrizar límites tanto a Si la parametrización está bien
consumo excesivo nivel de recursos como de reservas. hecha, el riesgo de consumo
de recursos excesivo se reduce bastante. Sin
embargo, parametrizar estas
opciones requiere conocer muy bien
el entorno.

Riesgos clásicos de Posible Disponibilidad El hecho de que las máquinas sean

las máquinas virtuales no impide que deban tratarse
Integridad
virtuales como máquinas físicas con un antivirus,
Confidencialidad un anti spyware, filtraje, la detección de
intrusiones, el endurecimiento, etc.

Ataque a través de la Posible Disponibilidad Una buena parametrización de derechos

Consola VI a nivel de máquina virtual permite
evitar este riesgo.

e. Riesgo a nivel de almacenamiento

VMware está extremadamente relacionado con el almacenamiento y, especialmente, por tanto, con los fabricantes de
bahías de almacenamiento. Anteriormente, las redes SAN estaban bien aisladas, pero con la llegada de la virtualización,
esto no es obligatoriamente así. Las bahías de almacenamiento soportan la administración basada en IP, y los protocolos
tipo iSCSI o FCOE (FC Over Ethernet) permiten comunicarse a través de la red IP con las bahías de almacenamiento.

La virtualización ha cambiado las costumbres a nivel de redes SAN, abriéndolas mucho más al mundo IP.

Esta apertura permite a los individuos malintencionados acceder a los datos confidenciales.

Página 83 de 146
 Aquí mostramos como ayuda un boceto de los análisis de riesgos:

Amenaza Probabilidad Posible impacto Contramedidas Comentario

Presentación no Probable Integridad El Zoning y el LUN Masking son Aunque las SAN permiten el
autorizada de datos de elementos que hay que tener en cuenta acceso a nivel de archivo (SMB,
Confidencialidad
la SAN en una red SAN. NFS, etc.), igualmente será
necesario asegurar una buena
parametrización.

Captura de datos de Improbable Integridad Las máquinas virtuales no entienden el

las redes SAN a través protocolo FC y no ven más que
Confidencialidad
de una máquina periféricos SCSI. Incluso el
virtual Multipathing se gestiona de forma que la
máquina virtual no ve nada de la red
SAN.

DoS de una máquina Posible Disponibilidad Es posible restringir la máquina virtual a

virtual accediendo de nivel de E/S (con la noción de SHARE).
forma intensiva a la
SAN

Ataque de la interfaz Posible Disponibilidad Casi todas las SAN se administran a

de administración de través de la red IP. Es necesario cambiar
Confidencialidad
redes SAN las contraseñas por defecto y crear
Integridad contraseñas fuertes.

f. Riesgo a nivel de Virtualcenter

Virtualcenter es un elemento extremadamente crítico en toda la arquitectura VMware ESX. A partir de Virtualcenter, es
posible dirigir el conjunto de operaciones sobre todos los servidores ESX.

Virtualcenter está afectado, desgraciadamente, por el síndrome de la acumulación de módulos. Está compuesto por:

Página 84 de 146
  Windows 2003-2008 como sistema operativo (con la llegada de vSphere). Este sistema está sometido a muchas
vulnerabilidades.
 Una base de datos MSSQL 2000 o 2005. Los ataques sobre bases de datos son muchos, sobre todo sobre MSSQL
2000.
 Un número de módulos complementarios impresionantes viniendo del ecosistema de VMware. Estos módulos
comunican y abren puertos (DoS posible).

Como prueba, veremos qué nos podremos encontrar en un servidor Virtualcenter al que se le han añadido algunos
módulos:

Página 85 de 146
 Ahora un análisis de riesgos:

Página 86 de 146
 Amenaza Probabilidad Posible impacto Contramedidas Comentario

Ataques específicos a Probable Integridad Endurecimiento de Microsoft Windows 2003. Endurecimiento

Windows Server de MSSQL 2000 ó 2005. Uso de detectores de intrusión,
Confidencialidad antivirus, antispyware y gestión de parches.

Disponibilidad

Uso de privilegios a Probable Integridad Dado que Virtualcenter puede estar integrado en Active
causa de un error Directory, el posicionamiento por error de un usuario es
Confidencialidad
humano posible. Hay que prestar atención a la atribución de roles,
Disponibilidad privilegios y objetos.

Acceso a información Posible
almacenada en
Windows que permita
recuperar información
útil
Disponibilidad Virtualcenter tiene un sistema de logs elaborado. Otros
archivos también son importantes: licencias, configuración de
Integridad
Virtualcenter (formato XML), etc. Estos últimos están
repartidos en muchos directorios donde los derechos de acceso
pueden estar fácilmente mal configurados. Es por tanto
necesario posicionar los derechos de forma que impidan un
acceso fraudulento a estos.

Corrupción de Poco Disponibilidad Virtualcenter es un programa desarrollado por VMware con

Virtualcenter a través probable .NET. Se han integrado muchas contramedidas para evitar un
Confidencialidad
de un ataque tipo desbordamiento del buffer. Sin embargo, la posibilidad existe.
Buffer Overflow Integridad Es conveniente activar DEP al mínimo e instalar un software
que permita controlar la memoria (detectar la intrusión en el
host) para asegurar que Virtualcenter no será comprometido.

2. Autenticación y autorización
Existen dos métodos que permiten acceder a un servidor ESX: por la Service Console o utilizando Virtualcenter. El
principal problema reside en el hecho de que los derechos presentes a nivel de ESX no repercuten a nivel de Virtualcenter
y viceversa. Este problema se debe al hecho de que Virtualcenter se instala sobre sistemas Microsoft y se comunica con
Active Directory, mientras que la Service Console es un sistema Unix.

Por defecto, a nivel de ESX, solamente la cuenta root puede tener un acceso total. Una vez integrada en Virtualcenter,
la cuenta vpxuser se añade localmente al servidor ESX y tiene derechos de administrador. La cuenta vpxuser tiene una
contraseña generada aleatoriamente y cambiada regularmente (no hay ningún problema de seguridad debido a esta
cuenta).

La complejidad de las contraseñas, además de su caducidad, se puede configurar a través del comandoesxcfg-auth,
pudiéndose definir:

 la duración máxima de una contraseña,

 la caducidad de las contraseñas,
 la complejidad de las contraseñas,
 la longitud mínima de las contraseñas.

Hay que tener presente que las cuentas que hay en el servidor host son locales. Habrá que borrarlas manualmente
después de usarlas.

Una vez se ha integrado Virtualcenter, es posible gestionar todos los servidores ESX a través de una sola interfaz. El
servidor que contenga Virtualcenter puede también integrarse a sí mismo en Active Directory de Microsoft. Con esto es
posible atribuir derechos a nivel de Virtualcenter a los usuarios en Active Directory.

Página 87 de 146
 Virtualcenter atribuye los derechos según 4 criterios:

 los usuarios y grupos,

 los privilegios,
 los roles,
 los permisos sobre los objetos.

El principio es el siguiente:

Una vez que el usuario ha sido seleccionado (un usuario local o un usuario en Active Directory), habrá que atribuirle un
rol. Existen numerosos roles por defecto que tienen el derecho de realizar una o varias acciones o "privilegios". Los roles
por defecto son:

 administrador de máquinas virtuales,

 administrador de Datacenter,
 usuario con poder de máquinas virtuales,
 usuario de máquinas virtuales,
 administrador de un conjunto de recursos.

Es posible crear roles personalizados o modificar los existentes (salvo el rol no Access, read-only y Administrador).

Una vez elegidos el usuario y los roles, el usuario se le otorgan privilegios que modificarán su perfil o lo dejarán tal cual.

En último lugar, habrá que seleccionar los objetos que se verán afectados. Es posible aplicar derechos sobre los objetos
siguientes:

 datacenters
 clusters
 hosts
 máquinas virtuales
 directorios
 conjuntos de recursos

Página 88 de 146
3. Las actualizaciones y las futuras protecciones
VMware, a través de Virtualcenter, propone actualizar el conjunto de servidores ESX (que engloba a los ESXi) a través
del componente VMware Update Manager. VMware Update Manager es un proxy de actualizaciones en el sentido que
recupera todas las actualizaciones de los servidores ESX y es capaz de redistribuirlas.

VMware Update Manager puede igualmente actualizar los sistemas operativos siguientes:

 Windows
 Linux

Las ventajas de VMware Update Manager son las siguientes:

 centralización de las actualizaciones,

 posibilidad de actualizar a la vez sistemas Linux y Microsoft Windows,
 está integrado en Virtualcenter (no se necesitan máquinas virtuales suplementarias o mecanismos tipo WSUS).

VMware debería permitir garantizar mejor la protección de sus máquinas virtuales con un add-on que estará disponible
con VMware ESX 4: vShield.

vShield debería permitir supervisar, bloquear y trazar las comunicaciones inter VM entre servidores ESX o entre servidores
de un mismo cluster. La granularidad prometida debería extenderse hasta el nivel de aplicación.

Página 89 de 146
 En resumen, vShield debería permitir crear políticas de seguridad de red como un Firewall/IPS/IDS. Queda saber si
cumplirá sus compromisos y si será suficientemente fácil de usar para evitar errores humanos.

Reto n°3: luchar contra las consecuencias inherentes de la

virtualización

1. La pérdida de la defensa perimétrica

La primera consecuencia de la virtualización es la destrucción de la defensa perimétrica. De hecho, la virtualización crea
redes virtuales, que redirigen el flujo de diferentes formas según sus conexiones a las redes físicas.

A lo largo de muchas auditorías, han aparecido dos casos:

 Bypass de las protecciones de red.

 Detección de intrusiones obsoleta.

a. Bypass de las protecciones de red

Las protecciones de red tipo Firewall y ACL son difíciles de mantener en infraestructuras virtualizadas.

Puede darse el caso de que la noción de Switch virtual sea mal entendida por los actores de la red (hasta a los expertos
de VMware les resulta difícil).

Los firewalls pueden estar cortocircuitados debido a una mala comprensión. Para comprenderlo mejor, vamos a ver un
esquema sacado de una auditoría reciente:

Página 90 de 146
 La conexión de un Switch virtual a un Switch físico ha permitido saltar dos firewalls y dejar así acceso libre a una máquina
virtual. Desde esa máquina, el pirata podría haber tomado posesión de todas las otras máquinas virtuales.

Dada la complejidad de las redes, la interacción con las redes privadas (VLAN), las virtuales (vSwitch) y las físicas
(Switch, router, etc.) va a llevar inevitablemente a estar expuesto a este tipo de riesgo. Sería conveniente permanecer
alerta respecto a esta amenaza.

b. Detección de intrusiones obsoleta

La detección de intrusiones es un tema particularmente sensible estos últimos años. Los actores del mercado intentan
vendernos sus soluciones con mayor o menor éxito. La tecnología de detección de intrusiones se convierte en
imprescindible, dada la complejidad de los ataques.

Desgraciadamente, la virtualización puede poner en peligro este mercado. De hecho, la detección de intrusos es una
tarea muy difícil en una red virtual. Los flujos no pasan obligatoriamente por donde deberían, lo que convierte a los
IDS/IPS más o menos ineficaces.

Vamos a ver un ejemplo concreto:

El pirata forma parte de la red interna, y se conecta de forma completamente normal a una máquina virtual en una DMZ.
A partir de ahí, el pirata aprovecha el hecho de que las máquinas virtuales están ligadas a vSwitch internos.

Este caso es evidentemente discutible, ya que la arquitectura no está optimizada desde un punto de vista de seguridad.
Pero ofrece una buena ilustración de lo que podría encontrarse cada vez más en muchas empresas, ya que la crisis
financiera no favorece la compra de material destinado a esto y que los responsables prefieren un aislamiento virtual a
un aislamiento físico, en término de costes.

2. Pérdida de visión de la información

La virtualización está muy ligada a la noción de Cloud Computing. Hay que imaginar lo que la virtualización ofrecerá en
unos años. Las máquinas virtuales irán de un Datacenter a otro sin cortes. Dependiendo de las cargas a las que se
enfrenten, migrarán a máquinas más potentes. Es la ilusión de un mundo perfecto, donde todo está automáticamente
gestionado, y donde la adaptación es la palabra clave.

Por otro lado, también hay que imaginar que usted no sabrá dónde encontrar su propia información, ni incluso su
máquinas virtuales. Esto puede constituir un auténtico problema.

¿Quién garantiza, hoy en día, que su máquina virtual no estará duplicada en un país contra el que se esté en guerra?

¿Quién garantiza que su máquina virtual no esté en un país embargado?

Página 91 de 146
 ¿Quién le garantiza que su máquina virtual no está en este momento en manos de la competencia?

¿Quién le garantiza que el Datacenter al que acaba de migrar su máquina virtual utiliza la misma política de seguridad
que aquel dónde estaba antes?

¡Podemos hacernos muchas preguntas!

Es evidente que la virtualización contribuirá enormemente a mejorar la disponibilidad de la información, pero no deberá
hacerse nunca en detrimento de la confidencialidad y de la integridad.

La noción de Cloud Computing implica que los datos confidenciales van a encontrarse duplicados en muchos sitios físicos
repartidos por todo el mundo, o al menos durante un período de tiempo definido, se encontrarán en más de un lugar,
con lo que podrían ser copiados. Esto deja muchas ventanas y puertas abiertas a su información; es el sueño dorado de
la fuga de información…

3. La criticidad real de los hosts

Uno de los problemas inherentes a la virtualización concierne al aspecto dinámico y evolutivo. Es un punto muy positivo
en muchos casos, pero no obligatoriamente en el de la seguridad. De hecho, cuando hay que analizar la criticidad de un
servidor, hay que tener en cuenta las máquinas virtuales que se encuentran en él. Esto complica, en gran medida, el
trabajo de los que deben realizar un análisis de riesgos. Imagínese que, además, esas máquinas virtuales pueden
moverse y migrar de un entorno a otro; será difícil caracterizar entonces la criticidad de un entorno.

Tomemos un ejemplo:

La máquina virtual A es muy crítica y la máquina virtual B no lo es. Estas máquinas virtuales se encuentran en el mismo
host físico. ¿Cuál es su criticidad?

La primera respuesta consiste en considerar que, en el momento en que una máquina virtual confidencial se encuentra
en un host, éste se convierte en crítico.

Ahora que el host es crítico, la máquina virtual confidencial migra a otro servidor host. ¿Qué sucede con su criticidad?

Ya habrá entendido que, los análisis de riesgos y e incluso la visión del riesgo van a ser mucho más complejos en entornos
virtuales.

Virtualización y Entornos Críticos

Página 92 de 146
Introducción
Antes de nada, repasaremos la noción de entorno.

Un entorno se considera aquí un conjunto de sistemas o aplicaciones que permiten a una empresa efectuar tareas
diversas.

La virtualización de entornos críticos es un punto capital en cualquier proyecto de virtualización. A menudo, las empresas
que deciden dar el paso tienen mucho miedo a virtualizar los sistemas vitales, ya que cualquier tecnología nueva comporta
riesgos, como por ejemplo:

 Una débil madurez, por lo que tiene muchos bugs.

 Un número de experiencias de clientes insuficiente, por tanto una posible inviabilidad técnica.
 La posibilidad de fallar ante imprevistos.

Tomemos el ejemplo de una gran cuenta. Si un bug cualquiera afecta a los servidores Web internos virtualizados, no se
podrá acceder a la Intranet. Las posibles consecuencias son:

 La imposibilidad de consultar los perfiles de compañeros y sus respectivos departamentos.

 Los números de teléfono y emails del personal interno están momentáneamente inaccesibles.
 No es posible buscar documentación interna.

Aunque esto puede retrasar el trabajo, su efecto es limitado.

Tomemos otro ejemplo de otra gran cuenta. Si un bug cualquiera afecta esta vez a los sistemas encargados de los pagos
en línea, las posibles consecuencias son:

 Los clientes no pueden pagar en línea y por tanto no pueden comprar (pérdida de ventas).
 Los clientes no saben si sus pagos se han aceptado o no, lo que les genera desconfianza (pérdida de imagen
de marca).
 Los procesos de validación de pedidos no pueden verificar el estado de los pagos (retraso de pedidos, quejas
de clientes, problemas en la cadena logística, etc.).

En este tipo de escenario, es posible que se llame rápido a quien haya tomado la decisión de virtualizar…

En resumen, la decisión de virtualizar un entorno crítico no es fácil, y demanda un profundo estudio de la viabilidad
técnica, un análisis de riesgos minimalista y una puesta en producción vigilada y controlada.

¿Qué dificultades tiene la virtualización de entornos críticos?

Hoy en día, muchas empresas piensan que conocen sus entornos críticos. Sin embargo, las consultorías de seguridad le
dirán que todas las empresas, pequeñas y grandes, no conocen el conjunto de sus vulnerabilidades, ya que no conocen
sus puntos vitales o "activos" (assets). En el mundo de la seguridad de los sistemas de información, los activos
representan todo aquello que tiene un valor o que permite crear valor para la empresa; es lo que conviene proteger en
todos los casos. Los activos pueden ser materiales o inmateriales, como ya hemos visto.

Un entorno crítico es un entorno dependiente de aplicaciones/sistemas donde un mal funcionamiento tendrá un impacto
importante sobre la seguridad o la vida de las personas, empresas o bienes.

Por tanto, un entorno puede convertirse en crítico de un día para otro, a lo largo del desarrollo de la empresa, y al
contrario. La noción de criticidad es, además, relativa en comparación a la visión de cada uno de sus activos. Es por eso
que una opinión objetiva y externa es a menudo conveniente para mejorar la visión de los propios activos.

A continuación mostraremos tres ejemplos que conciernen a sectores de actividades diferentes, que dan una primera
idea de las dificultades que se encuentran al virtualizar entornos críticos.

Atención, los testimonios hay que tomarlos con precaución. Dependen en gran medida del contexto, del entorno y del
histórico de cada empresa. Es posible que, mientras tanto, hayan surgido nuevos elementos que permitan tratar de otra
forma las problemáticas expuestas.

Página 93 de 146
1. Primera dificultad: determinar las dependencias funcionales y técnicas
Nos podemos dar cuenta de la criticidad de un entorno preguntándonos lo siguiente: ¿qué pasaría si este entorno faltara?
La pregunta es muy fácil, y permite recolocar el entorno en su contexto. El entorno puede, por ejemplo, estar relacionado
con:

 los clientes,
 el personal interno,
 los activos materiales de la empresa,
 los activos inmateriales de la empresa,
 los responsables de la empresa,
 terceras personas en el contrato.

Desgraciadamente para muchas empresas, los entornos son independientes unos de otros. Esta independencia ha
permitido favorecer estos últimos años el aspecto «modular», pero también ha complicado el conjunto del Sistema de
Información. Un entorno ya no está solo, y vive en un auténtico ecosistema. Su evolución está relacionada a la de otros
entornos, y todo cambio que le afecte impacta sobre el conjunto de entornos relacionados.

Esto puede parecer evidente a simple vista, pero es importante recordarlo para ser consciente de que tocar un entorno
vital para el núcleo del negocio, a menudo puede provocar efectos de abordo imprevisibles.

Tomemos un ejemplo concreto de un testimonio de una empresa.

Caso de una empresa de logística

Una empresa tiene como actividad principal la logística. Encamina los paquetes de todos sus clientes a destino, a nivel
nacional o internacional. Su proceso interno de despacho de paquetería se realiza a través de una herramienta interna,
basada en una base de datos centralizada, que permite a la empresa disponer de una ventaja sobre la competencia: la
rapidez y muy pocos errores de entrega.

Parece evidente que el entorno que se ocupa del despacho de paquetes es crítico, así como la base de datos. Mirándolo
más de cerca, nos daremos cuenta de que el entorno depende de un conjunto de subsistemas, que son:

 El etiquetado de los paquetes.

 La localización de las direcciones.
 La sincronización con la base de datos de las empresas de transporte.

Sin embargo, el lector se sigue preguntando: sí, pero ¿qué tiene esto que ver con la virtualización?

La respuesta es la siguiente: el proyecto consistía en virtualizar tanto el conjunto de puestos de trabajo como los
servidores de la empresa. A primera vista, virtualizar la base de datos no era un problema, ya que no generaba muchas
E/S. El entorno de encaminamiento, en sí, no representaba ningún problema en particular.

El problema era el siguiente: el etiquetado de los paquetes se hacía con un aparato muy especial conectado a un
ordenador por Bluetooth. Por tanto, era técnicamente imposible virtualizar todos los puestos de trabajo como se había
previsto. Conclusión: sólo el 75% del perímetro podía virtualizarse y los puestos de trabajo que se ocupaban del
etiquetado quedaron de momento como estaban, sin poder ser «masterizados» como el resto del parque, lo que entraña
un problema de seguridad así como un sobrecoste de mantenimiento. Si la virtualización se hubiera vendido de entrada
como «LA» solución milagro, el DSI habría tenido que justificar sus informes de cara a sus superiores y asumir todas las
consecuencias que se derivaran.

2. Segunda dificultad: la comprensión de interacciones

Un entorno puede ser crítico si interactúa con datos críticos. En sí, el entorno puede no ser indispensable. Por contra,
todos los datos que manipula a diario son muy sensibles.

La cuestión que nos planteamos rápidamente y que merece la pena hacerse es: «¿Pero en qué va a cambiar la
virtualización una interacción?». De hecho, la virtualización no tiene por objetivo cambiar el modo de funcionamiento (si
no, no se adoptaría masivamente). En cambio, las manipulaciones que se derivan pueden provocar efectos mucho más
devastadores que en una arquitectura clásica.

Tomemos otra vez un ejemplo de una experiencia concreta.

Caso de una empresa del sector médico

Una empresa tiene como actividad principal la gestión diaria de los plannings de hospitales y de las recetas de los
pacientes, para lo que se ha creado una ERP, con diferentes módulos enlazados a una base de datos centralizada. Estos
Página 94 de 146
 módulos se comunican entre sí a través de un disco compartido (sobre una SAN o NAS) creando archivos temporales con
un significado particular. Por ejemplo:

Un archivo Go.txt significa que hay que recalcular los plannings para optimizar los tiempos de respuesta.

Un archivo license.txt contiene las licencias de la ERP. Sin éste, el software deja de funcionar al cabo de 15 días.

El número de E/S en este disco compartido es bastante alto, debido al volumen de información que se intercambia.

La empresa acaba de firmar un contrato y despliega su nuevo software en colaboración con el equipo informático de un
importante hospital. El hospital acaba de invertir en una nueva arquitectura virtual y pide que se instale la ERP sobre
máquinas virtuales, lo que que se hará sin grandes dificultades.

Pasan algunos meses desde la puesta en producción, y los equipos gestionan diariamente la nueva arquitectura.
Desgraciadamente, los problemas económicos obligan al DSI a desprenderse de una bahía SAN debido a su elevado coste
de mantenimiento. Esta bahía SAN se ocupaba antes de la compartición de archivos de la ERP. La bahía SAN se retira y
se configura una máquina virtual dedicada a la compartición de archivos. Esta máquina virtual contiene dos discos
virtuales: uno para el sistema y otro para compartir los datos.

Una vez se crea la máquina, se hace un snapshot para garantizar una marcha atrás en caso de fallo del sistema.

Al cabo de unas semanas, la máquina virtual falla, debido a una actualización. Los administradores se sienten muy
orgullosos de poder utilizar las funcionalidades de los snapshots para restaurar el sistema en pocos segundos. Se envía
un email a la DSI: «Gracias a la nueva arquitectura virtual, hemos restablecido las operaciones en sólo 5 minutos.»

15 días después, el ERP se bloquea completamente y nadie es capaz de encontrar la causa del problema. Las actividades
del hospital se reducen al mínimo, y se va a evitar la "catástrofe" por poco.

Sin embargo, la explicación es lógica. La máquina virtual creada para reemplazar los archivos SAN se ha «snapshoteado»
después de haberla configurado correctamente. Sin embargo, los datos que contiene la SAN se transfirieron después del
snapshot de la máquina virtual.

En el momento que el equipo decide hacer una restauración, el snapshot reinicializó el disco de sistema y el disco de
datos al estado inicial, lo que permitió retomar el trabajo rápidamente (la máquina virtual «snapshoteada» era
perfectamente operativa) pero tuvo por efecto eliminar todos los datos presentes en el disco de datos (y por tanto el
archivo licence.txt).

3. Tercera dificultad: encontrar métricas fiables

Cuando se debe virtualizar un entorno crítico que genera numerosas E/S, no es fácil comprometerse sobre el rendimiento
de la nueva arquitectura. Hay que tener un buen número de métricas: las KPI (Key Performance Indicator).

Página 95 de 146
 Hoy en día, todos los fabricantes comunican en sus Benchmark, mostrando resultados siempre mejores unos que otros.
Sin embargo, aunque las pruebas tienen cierta validez, no siempre son representativas de lo que una empresa instalará
realmente. Existen múltiples soluciones, según las limitaciones de tiempo y presupuesto; mostraremos algunas:

 Pedir una opinión de cliente sobre esa arquitectura.

 Hacer simulaciones en laboratorio.
 Probar directamente en producción durante un periodo de tiempo bien definido.

Cada solución tiene sus ventajas y sus inconvenientes.

Caso de una empresa del sector industrial

Veamos el caso de una empresa del sector industrial encargada de fabricar chips electrónicas. El DSI, viendo que los
puestos de trabajo estaban anticuados, decide cambiarlos, pero ya que la empresa sufre la crisis económica, decide
virtualizarlos para reducir costes. Su empresa tiene un acuerdo marco con fabricantes de servidores, y por tanto puede
negociar la compra de muchos servidores blade para mutualizar toda la infraestructura de estos.

La empresa posee actualmente 800 puestos de trabajo, por lo que el DSI deberá crear 800 máquinas virtuales dedicadas
para los usuarios y habrá que invertir igualmente en la compra de 800 terminales ligeros.

El DSI se pregunta: ¿cuántas máquinas virtuales puedo alojar en cada host?

La arquitectura es la siguiente:

Página 96 de 146
 El DSI decide realizar un estudio, y elimina inmediatamente la opción "Probar directamente en producción sobre un
período de tiempo bien definido" ya que lo considera demasiado peligroso.

Había poca experiencia sobre este tipo de configuraciones como para hacerse una idea.

El DSI se decanta por expertos externos a la empresa que concluyen rápidamente que habría que probar la configuración
en laboratorio y simular la carga de 800 usuarios sobre 800 máquinas virtuales.

Se plantean entonces muchos problemas:

 ¿Cómo simular el comportamiento de un usuario?

 ¿Cómo determinar el perfil de funcionamiento del usuario?
 ¿Qué garantía hay de que un usuario se comporte con el tiempo de forma idéntica?
 ¿Cuántos perfiles de funcionamiento de usuario existen?
 ¿Cuáles son las incógnitas? (usuarios muy consumidores de recursos, etc.).

El estudio se llevó a cabo con utilidades experimentales. En lugar de simular simplemente el flujo de usuarios como se
hace en muchas empresas especializadas, los expertos crearon una inteligencia artificial capaz de simular el
comportamiento de un usuario clásico (apertura de Microsoft Word, lectura de emails en Outlook, visualización de sitios
Web con IE 7, modificación de archivos Excel, etc), añadiendo además cierta aleatoriedad en las tareas completadas.
Esta inteligencia artificial, un poco rudimentaria, permitió simular el comportamiento de 800 usuarios sobre 800 máquinas
virtuales. Aunque esta técnica sea la mejor para obtener métricas fiables, la realidad es distinta.

 No se tiene realmente en cuenta la parte desconocida, como en toda simulación.

 Seguramente, no todos los perfiles son idénticos en la realidad.
 Los perfiles varían. Una persona puede modificar su comportamiento de un día para otro.

En resumen, tener las métricas fiables es un auténtico desafío. Sea cual sea el proyecto, las métricas nunca serán
perfectas. La mejor forma de actuar consistirá en escoger el mejor método para obtener métricas suficientemente
representativas de lo que pasa en realidad.

¿Cómo determinar la elección de un entorno para la virtualización?

Página 97 de 146
 Ahora que se han identificado las principales dificultades, nos conviene interesarnos en la noción de elección. Un entorno
crítico puede virtualizarse si pasa todos los criterios de elección. Si no es el caso, el entorno no será virtualizado o lo será
sólo parcialmente.

1. Determinar las características del entorno

La determinación de las características de un entorno es la primera etapa. Es primordial observar su contexto técnico y
funcional para disponer del mayor número de elementos posible. Hay muchas formas de determinar las características
técnicas de un entorno.

Muchas utilidades pueden ayudar en este caso:

PowerRecon de Platespin

Esta utilidad permite recoger información relacionada con el entorno objetivo para orientarnos a diferentes escenarios de
virtualización. La recogida de información se hace de forma no intrusiva (por tanto sin instalación de agente). Integra
una noción de ROI/TCO interesante.

SP Analyst de Sysload Software

El funcionamiento es idéntico: recoger el máximo de información posible para definir las características del entorno
objetivo. Sysload es muy atractivo, visualmente hablando, y tiene un número de métricas increíble. En cambio, es
obligatorio instalar un agente, por lo que el programa es algo intrusivo. Actualmente, es una de las herramientas más
usadas del mercado en materia de supervisión y de control de rendimientos.

OmniVision de Systar

Página 98 de 146
 Con menos fama en este campo, esta herramienta es perfecta para visualizar rápidamente la información básica
(sistemas sobrecargados, errores, uptime, etc). La interfaz gráfica no es tan elocuente como la de sus competidores,
pero tiene la ventaja de ir directa al grano.

El principal problema de estas herramientas reside en la imposibilidad de reemplazar un auténtico auditor. Es por lo que
podrán, sin duda, aportar métricas fiables, pero no permitirán gestionar el lado organizativo de los entornos, cosa que,
como ya habrá visto en ejemplos anteriores, es seguramente el aspecto más importante.

Si usted no posee ninguna de estas herramientas y no quiere invertir en ellas, la observación es una excelente alternativa.
Además, existe una gran cantidad de herramientas libres: Nagios, Cacti, MRTG, etc.

2. Posicionar las posibles optimizaciones para responder a la necesidad

La construcción de una infraestructura virtual requiere muchas habilidades, lo que indica que las posibilidades de
optimización son numerosas. Estas optimizaciones permiten, principalmente:

 aumentar el rendimiento;
 asegurar un máximo de disponibilidad;
 asegurar una estabilidad precisa.

En el momento que un entorno se convierte en crítico, se necesita un cierto número de optimizaciones.

Es suficiente mirar desde el lado de VMware para comprender que se observa particularmente el aspecto del rendimiento.
Posee un blog dedicado a las pruebas de rendimiento y utiliza las herramientas más conocidas del mercado para
garantizar la validez de sus métricas según el público. Las utilidades SPEC por ejemplo, llegan a simular entornos
bancarios, de e-commerce o de soporte.

Estos entornos son representativos de lo que se encuentra normalmente en muchas empresas, por lo que las pruebas
aportan un éxito rotundo.

Cada prueba realizada por VMware o por sus colaboradores sigue un protocolo particular impuesto. Esto permite
garantizar que estos se reproduzcan.

Página 99 de 146
 Cuando observe los protocolos de pruebas de cerca, verá que los colaboradores posicionan cada vez un gran número de
optimizaciones para obtener los mejores resultados.

Desde hace poco, VMware creó un conjunto de tests para validar la virtualización de entornos críticos (la web es
www.vmmark.com)

El conjunto de pruebas sirve para validar los rendimientos de sistemas virtualizados pesados con reputación como:

 un servidor email Exchange;

 un servidor JAVA;
 un servidor Web dedicado;
 una base de datos;
 un servidor de archivos.

VMmark está, por encima de todo, dedicado a los fabricantes de material de servidores. Estos compiten por estar en
cabeza de lista o, al menos, por aparecer en la lista oficial. VMmark es observado de cerca por los responsables, para
hacerse una idea de quiénes son los mejores competidores del mercado.

El cuarteto en cabeza actualmente es:

Página 100 de 146

  HP
 DELL
 IBM
 SUN

Estos actores son, por el momento, los más reconocidos en el mercado de la virtualización. Otros como NEC, Fujitsu o
Cisco deberían aparecer próximamente, ya que la competición se ha endurecido en Europa.

El denominador común de todas estas pruebas son los procesadores, o más exactamente el número de núcleos, ya que
sólo AMD y INTEL están presentes en el mercado.

Las pruebas realizadas por cada uno de los actores presentan numerosas optimizaciones como muestra la pantalla
siguiente:

Página 101 de 146

3. Buscar un feedback/recurrir a empresas especializadas
Cuando usted debe construir una casa, se inspirará con lo que se haya hecho mejor en otros sitios y querrá ver los
materiales que se han utilizado. Un responsable de un proyecto de virtualización debe hacer lo mismo. Siempre hay que
ver lo que se ha hecho en otros sitios para no tener que pagar el precio de la experimentación.

Desde hace algunos años, los feedbacks en materia de virtualización son, afortunadamente, muy numerosos. VMware ha
comprendido extremadamente bien el fenómeno y hace públicos los testimonios de muchos clientes. Los fabricantes
también han comprendido el fenómeno.

Un pequeño truco representativo: VMware ha creado un salvapantallas que agrupa testimonios de varios usuarios sobre
arquitecturas importantes.

Los eventos organizados por VMware permiten comunicar las novedades "Business Case" y "Sucess Stories" y los
colaboradores/fabricantes que se han asociado. Así, todo el mundo gana.

Existen muchos sitios relacionados con los proyectos de virtualización. Entre ellos están:

 http://www.vmware.com/a/customers/
 http://blogs.vmware.com/vmtn/case_studies/

Google siempre es una opción…

Muchas empresas especializadas han hecho su aparición. Es difícil hacer un panorama de éstas trabajando para una de
éllas. Lo que sigue a continuación debe tomarse con una cierta distancia y el lector está invitado a hacerse una idea
objetiva contactándoles directamente.

VIRTUALI: empresa especializada en la seguridad y virtualización de los Sistemas de Información. Esta sociedad se
especializa en la puesta en marcha de PRD/PCA, en pruebas de carga y simulaciones de laboratorio, la puesta en marcha
de infraestructuras de muy alta disponibilidad y la virtualización de aplicaciones, puesto de trabajo y entornos críticos.
Es la única empresa que integra realmente la seguridad a todos los niveles de la infraestructura virtual. Sitio Web:
http://www.virtuali.fr

ARUMTEC: empresa líder tanto en el mercado de la virtualización como en el de la integración. ARUMTEC tiene mucha
experiencia con empresas y se especializa en estudios de ingeniería: estudios de elegibilidad, migraciones físicas contra
virtuales, etc. ARUMTEC es hoy en día la referencia para el consejo y el acompañamiento en grandes proyectos de
virtualización. La sociedad cuenta hoy con muchas referencias a su activo, incluyendo grandes cuentas. Sitio Web:
http://www.arumtec.net

NWARE: empresa muy activa en el área de la virtualización, NWARE tiene buenas referencias en el área bancaria. Nware
agrupa a los apasionados de la virtualización bajo una comunidad internauta llamada GuVirt. GuVirt es muy conocida por
su gran dominio de las herramientas de virtualización del mercado: VMware, Citrix, Hyper-V, etc. Sitio Web:
http://www.nware.fr/

DELETEC: empresa que tiene un gran dominio de las tecnologías y una gran experiencia en los Sistemas de Información.
Se lanzó rápidamente a la virtualización y ha tenido mucho éxito en la banca y en el área financiera en general. DELETEC
Página 102 de 146
 aborda los proyectos de virtualización gracias a una metodología cercana a la célebre PDCA (Plan Do Check Act) que
permite al cliente maximizar sus inversiones y gestionar mejor su nueva infraestructura. Sitio Web:
http://www.deletec.fr/

Seguro que existen otras empresa que merecerían ser citadas. Las empresas de prestación de servicios o grandes
estructuras no han sido seleccionadas ya que la virtualización no es parte de su actividad principal.

Dos testimonios sobre estudios y pruebas realizadas

El objetivo de este capítulo es dar a los lectores testimonios sobre la virtualización de aplicaciones o de entornos
considerados críticos y la manera de abordar cada proyecto. Estos testimonios se han extraído voluntariamente de
ámbitos diferentes.

1. Una aplicación para interacciones complejas

El cliente era un líder en el área del transporte que desarrolló durante años un software interno, capaz de gestionar el
día a día:

 los horarios de salida y llegada de los diferentes medios de transporte que forman parte de la plantilla de la
empresa.
 los plannings de las personas a cargo de los transportes.
 las alertas, en tiempo real, que conciernen a los retrasos y las incidencias que provocan.

El software está estructurado sobre una solución a base de:

 CITRIX.
 Microsoft SQL SERVER.
 Active Directory.
 varios módulos .NET repartidos en diferentes plataformas.

En su época, el programa tenía muchas críticas en cuanto a sus terribles tiempos de respuesta. Debía entonces acogerse
en una nueva plataforma, virtual o no y ya que la política de la empresa era la reducción de costes, la virtualización
parecía una buena opción.

Dada la importancia del programa (sin él nada funcionaba correctamente), su criticidad se consideraba extrema. Había
que proceder a una auditoría preliminar que permitiera realizar la matriz de flujo e identificar las interacciones existentes
entre los distintos módulos. El aspecto organizativo también era muy importante, ya que había que prever un planning
estricto, prevenir a los diferentes actores y, sobre todo, convencer a la dirección de la necesidad de virtualizar una
aplicación así de crítica.

Tras esta etapa, se decidió probar durante un primer periodo el funcionamiento de la infraestructura virtualizada en
laboratorio. Esto permitió definir las características de los módulos que faltaban, y probar después el tiempo de reacción
de la aplicación sobre la nueva base. Los resultados fueron asombrosos: la aplicación respondió perfectamente con
tiempos de respuesta excelentes.

Tras las pruebas de laboratorio, se decidió pasar a un entorno llamado de integración. Este entorno estaba destinado a
probar la aplicación con usuarios y datos que provenían del entorno de producción.

El entorno de integración sufría los mismos síntomas que el entorno de producción: lentitud, tiempos de respuesta
inimaginables, etc. Por tanto, el problema provenía de los usuarios o de los datos manipulados. Profundizando al respecto,
se averiguó que el Active Directory estaba sobrecargado por algunos GPO muy consumidores de recursos y que los
perfiles de CITRIX tenían problemas.

Además de conocimientos clásicos en virtualización, el proyecto requería:

 conocimientos en Citrix Presentation Server.

 dominio de Microsoft Active Directory.
 dominio de GPO y de su interacción con productos CITRIX.

Se contactó entonces con expertos en cada una de estas áreas y, algunos meses después, el entorno de integración
funcionaba perfectamente. El entorno se pasó entonces a producción.

Página 103 de 146

2. Una aplicación que combina política, presupuesto y problemas técnicos
El cliente es líder en el ámbito de la construcción de edificios y grandes obras; de renombre internacional, se ocupa de
grandes proyectos por todo el mundo.

Disponiendo de una contabilidad centralizada muy compleja y costosa, emerge un proyecto a nivel de la DSI cuyo objetivo
es reducir radicalmente los costes.

La compatibilidad se basa en un software líder de mercado asociado a una base de datos Oracle, configurada en cluster
gracias a Oracle RAC (Real Application Cluster).

Esta base tiene muchas dificultades:

 genera muchas E/S.

 Oracle no la soporta si se virtualiza (la polémica Oracle/VMware todavía existe).
 no puede estar parada más de una hora.
 hasta la fecha, no se tiene ningún testimonio sobre la virtualización de Oracle RAC en producción.

Sin embargo, la decisión que se toma es virtualizar sin tener en cuenta el soporte de Oracle. De hecho, el cliente consideró
que los expertos de Oracle de la empresa tenían conocimiento suficiente para paliar cualquier posibles fallos. Además,
dada la cuantía del contrato con Oracle, el cliente disponía de una gran presión.

La primera etapa del proyecto consistió en buscar métricas fiables para dimensionar el material necesario. E/S de disco,
operaciones/segundo, consumo de CPU y memoria, ancho de banda necesario, etc.

Estas métricas son muy difíciles de conseguir en un entorno crítico de producción. Los DBA de Oracle, en colaboración
con nuestro equipo, decidieron montar un laboratorio para ello, lo que también permitió validar el proceso de
virtualización. Se desplegaron numerosas herramientas de vigilancia. Las de la SAN se mostraron muy eficaces por las
E/S y operaciones/ segundo. Se probó el cluster RAC virtualizado a nivel de alta disponibilidad, para comprobar que la
virtualización no provocaba impacto y se realizaron numerosas pruebas de estrés.

La segunda parte consistó en la integración de máquinas virtuales Oracle RAC al cluster RAC, como si fueran máquinas
clásicas. Poco a poco, todas las máquinas puramente físicas del cluster se irán dejando de lado (cosa que aún no se ha
realizado).

Hoy en día, gracias a la virtualización, el cliente puede añadir máquinas virtuales al cluster RAC con una plantilla
predefinida. Con ello, gana al menos un mes por cada puesta en producción (el proveedor puede desplegar mucho más
rápido) y le cuesta más barato (no hay que comprar máquinas físicas, prestación minimalista, consumo por día/persona
ampliamente disminuido en interno). Además, ya no hay errores de configuración y los DBA de Oracle se encuentran en
entornos totalmente idénticos, lo que facilita el trabajo diario.

Virtualización y PRD
El plan de recuperación ante desastres

1. ¿Qué entendemos por PRD?

a. Definición

El PRD (Plan de Recuperación ante Desastres) es hoy en día un objetivo importante para los Sistemas de Información.
Después de los recientes acontecimientos, sobre todo el 11 de septiembre, los dirigentes de muchas empresas se dieron
cuenta de repente de la importancia de su Sistema de Información. La simple copia de seguridad no es suficiente como
lo era antes. El Sistema de Información se ha convertido en un elemento crítico de la empresa, y en este sentido, debe
estar siempre disponible. Como los responsables de PRD indican, "para estar preparados para cualquier cosa, hay que
imaginar lo peor".

Antes de seguir, vamos a recordar la diferencia entre PRD y PCA.

El PCA es el Plan de Continuidad de Actividad, a menudo ligado a la noción de alta disponibilidad. El PCA tiene como
principal objetivo asegurar la disponibilidad de la información ante cualquier problema.

Contrariamente al PCA, el PRD no permite asegurar una disponibilidad total a nivel de información, sino únicamente
asegurar que las actividades podrán retomarse en un lapso de tiempo predefinido.

Página 104 de 146

 Aunque la diferencia puede parecer mínima, ya que el PCA está a menudo ligado al PRD. Simplemente hay que considerar
que el PRD interviene cuando se encuentra ante un escenario grave o un desastre, de donde viene el equivalente en
inglés del PRD: DRP o Disaster Recovery Planning.

Veamos algunas cifras de CLUSIF (Club de la seguridad de la información francesa) que permitirán comprender por qué
el PRD/PCA es tan importante:

 El 95% de los empleados de las empresas declaran haber perdido archivos informáticos que representaban desde
1 hora hasta varios días de trabajo.
 El 80% de las PYME no preparadas no sobreviven a un crash informático mayor.
 El 20% de los ordenadores portátiles han sido objeto de un siniestro (rotura o robo).
 El 70% de las PYME no hacen copias de seguridad de sus datos.
 El 60% de las PYME que han sufrido un siniestro informático desaparecen a los 5 años.
 El 98% de las empresas de más de 200 empleados dependen de forma moderada o fuerte de la informática.
 El 42% de las empresas de más de 200 empleados no tienen formalizado el proceso de continuidad de la actividad,
y el 32% sólo lo tienen parcialmente.

b. Los diferentes tipos de desastres

Al cabo del año, existen muchos desastres en el mundo… Imaginar todos los escenarios de desastre para una empresa
es difícil. Sin embargo, es concebible imaginar las consecuencias.

Veamos una lista, no exhaustiva, de las consecuencias posibles de cada desastre:

El fallo de un software o de una aplicación

Este caso sucede frecuentemente y puede ser crítico, según la importancia de la aplicación. Una aplicación puede pararse
por no haberse escrito correctamente o por haber sufrido un ataque externo (DoS, Buffer Overflow, etc).

El fallo de un Sistema Operativo

Igualmente, también es un caso bastante frecuente según los sistemas (parece ser que unos fallan más que otros); el
fallo de un sistema operativo entraña a menudo la pérdida de las aplicaciones instaladas y de los datos que contuviera.

El número de fallos a nivel de sistema a menudo va ligado a la incompetencia de las personas responsables…

Pérdida de las comunicaciones de red

La pérdida de las comunicaciones se debe muy a menudo a una mala configuración de los elementos que constituyen la
red, especialmente los Switchs, los routers o cortafuegos. Cuando las comunicaciones se cortan, los sistemas enlazados
son incapaces de intercambiar información, lo que puede conducir a diferentes tipos de escenarios: corte, pérdida de
datos, saturación, pérdida de sincronización, pánico del sistema, paro de actividades.

Pérdida de un conjunto de sistema o de un rack

En el caso de que varios sistemas fallen simultáneamente o que un armario tipo rack que contenga varios servidores
falle, las actividades se detendrán a menudo parcial o totalmente. Estadísticamente hablando, este fenómeno está
relacionado a menudo con un problema eléctrico o una sobrecarga generalizada.

Pérdida de un inmueble o de un local

La probabilidad de perder un inmueble o local es elevada, al contrario de lo que piensa la mayoría de la gente. Se puede
perder un inmueble debido a un incendio, un cortocircuito, una inundación, etc. Los inmuebles y locales comerciales
están asegurados obligatoriamente, aunque el coste resultante de la pérdida de actividad no se tiene en cuenta.

Pérdida de un centro de datos

La pérdida de un centro de datos es algo muy grave. Un centro de datos está a menudo protegido contra daños comunes:
inundación, corte eléctrico, fuego, tormenta, ciclones u otros. Sin embargo, hay muchos supuestos que no se cubren
como, por ejemplo, la malversación interna, los atentados, la propagación de enfermedades contagiosas, etc. La pérdida
de un centro de datos impacta, evidentemente, en numerosos clientes y engendra repercusiones extremas.

Pérdida de una ciudad entera

Este caso es muy raro (afortunadamente) pero hay que tenerlo en cuenta según el país. Los terremotos o los bombardeos
pueden, por ejemplo, cortar todas las actividades informáticas de una ciudad. Algunos ejemplos recientes: el huracán
Katrina o los terremotos en Japón.

Página 105 de 146

 Desastre regional

Algunas regiones tienen más probabilidad que otras de que ocurra un desastre (por ejemplo, algunas regiones de Estados
Unidos, azotadas regularmente por los huracanes). El desastre regional puede impactar sobre numerosos Datacenter y
ciudades, con lo que sus consecuencias pueden ser catastróficas.

SUN ha desarrollado un concepto interesante para responder a este tipo de desastre: la Blackbox. La Blackbox es un
auténtico Datacenter móvil, que sirve para asegurar la continuidad de los departamentos informáticos en caso de desastre
mayor. Esta iniciativa merece ser destacada.

Desastre nacional

Cuando el país es pequeño, un desastre nacional es una hipótesis realista. Luxemburgo, Mónaco, o incluso Singapur
pueden ser víctimas de este tipo de desastre.

Desastre planetario

Este supuesto no se ha vivido hasta ahora, aunque existen hipótesis: colisión con un meteorito, guerra nuclear
generalizada, contaminación bacteriológica global, etc.

Esto no impide que algunas empresas se especialicen en el análisis de riesgos de este tipo de escenarios catastróficos.

c. RPO y RTO

El enfoque de los responsables de PRD consiste actualmente en prever algunos escenarios catastróficos validados por las
más altas instancias. El mejor enfoque consiste, actualmente, en seguir las recomendaciones del DRI (Disaster Recovery
Institute).

Hay que distinguir dos elementos muy importantes en todo PRD:

 El RTO: Recovery Time Objective.

 El RPO: Recovery Point Objective.

El RTO especifica el plazo máximo que la empresa tolera para retomar su actividad. Comprende desde algunos segundos
hasta algunas días.

El RPO designa, por su parte, la duración máxima de guardado de datos que una empresa considera aceptable de perder
en caso de una avería. Esta duración varía desde cero hasta muchos días.

El RTO define a menudo el tipo de infraestructura necesaria para paliar los fallos y desastres. Por ejemplo, un servidor
de socorro podrá fácilmente implementar un RTO de varios días. En cambio, un RTO cerca de cero forzará el uso, por

Página 106 de 146

 ejemplo, de un caro mecanismo de Clustering. El RTO está, por tanto, extremadamente ligado a la noción de alta
disponibilidad.

Pequeño cálculo sobre el aspecto disponibilidad:

Indisponibilidad (minutos por año) Porcentaje de disponibilidad Clase

50.000 (34 días, 17 horas y 20 min) 90% 1

5.000 (3 días, 11 horas y 20 min) 99% 2

500 (8 horas 20 minutos) 99,9% 3

50 (algo menos de una hora) 99,99% 4

5 minutos 99,999% 5

0,5 (30 segundos) 99,9999% 6

0,05 (3 segundos) 99,99999% 7

El RPO existe en función de la criticidad de la información manipulada. Si no es crítica, no hay necesidad de invertir en
un sistema de copia de seguridad complejo con numerosos procesos. Sin embargo, si los datos o sistemas son críticos,
habrá que implementar, por ejemplo, un mecanismo de replicación simultáneo muy costoso.

2. El PRD: guía de proyecto

El PRD, como todo proyecto, está ligado al tamaño del perímetro y al sector de la empresa. Sin embargo, la trama es
casi la misma para todas las estructuras. El PRD consiste en una reunión de lanzamiento que será controlada por un BIA
(Business Impact Analysis). El BIA está compuesto de 3 fases: el estudio funcional, la auditoría de vulnerabilidades y el
análisis de riesgos.

Página 107 de 146

a. Fase 1: lanzamiento del proyecto de PRD

Antes de empezar un estudio de PRD, es esencial precisar un perímetro. Es conveniente que la dirección de la empresa
valide, a través de un comité de dirección, las actividades concernientes y los tipos de riesgos que hay que tener en
cuenta. Puede tratarse del conjunto de actividades o, por el contrario, de un plan de socorro limitado a un área
estratégica.

Para cada actividad, diseñaremos el correspondiente PRD del equipo de proyecto. La dificultad de este tipo de estudios
reside básicamente en la aplicación de un PRD adaptado al entorno. La adopción de una metodología personalizada
facilitará la apropiación por los responsables relacionados.

Es necesario que la dirección detalle los riesgos que quiere cubrir. Según lo que elija, se precisarán los "objetos en riesgo"
relacionados (material informático, material de telefonía, suministros externos, personal, local…) y la naturaleza de los
riesgos (¿hace falta por ejemplo tratar el riesgo social?).

b. Fase 2: estudio funcional (BIA)

La fase del estudio funcional tiene por objetivo definir para cada actividad las exigencias relativas al RPO y al RTO. Para
ello, conviene examinar los objetivos, identificar las actividades esenciales y evaluar las consecuencias de interrupción o
degradación de dichas actividades (parada temporal o definitiva, pérdida de datos, degradación del servicio). La
comparación de las diferentes situaciones permitirá tener muestras de los niveles de impacto (definición del carácter "no
soportable" de una situación) que serán utilizados posteriormente, en la fase de análisis de riesgos. En resumen, hace
falta:

 inventariar los elementos del Sistema de Información indispensables para que la actividad continúe (aplicaciones,
servidores, datos, red, etc).
 precisar lo mejor posible el RPO y RTO por actividad.
 determinar las aplicaciones críticas.
 recurrir a recursos humanos.
 auditar y calificar los locales.
 hacer un inventario de los equipamientos (puestos de trabajo, teléfonos, impresoras, red…).
 prever el nivel aceptable de degradación del servicio (tiempo de respuesta, actividades que pueden ser manuales…)
o modo llamado "degradado".
 preparar las condiciones de retorno a la normalidad.
Página 108 de 146
  ocuparse de los suministros externos indispensables.

El inventario debería realizarse con los correspondientes responsables de cada tarea de la empresa. En ese caso, es
necesario proceder a las consolidaciones y a verificar la coherencia global de las necesidades expresadas.

Una tendencia natural conduce a menudo a los empleados a pensar que su actividad es estratégica.

Si fuera necesario, se realizará un arbitraje por la Dirección General.

Deduciremos de esta fase la lista de aplicaciones que constituirán la trama estratégica del PRD.

c. Fase 3: auditoría de vulnerabilidades (BIA)

Como en toda auditoría de seguridad, es necesario evaluar los dispositivos de seguridad actuales o previstos. Si esta
evaluación no se ha realizado ya en el marco de una auditoría global, al menos habrá que hacer una revisión de los
siguientes temas:

 la organización de la seguridad.
 la cobertura a nivel de las aseguradoras que conciernen a los riesgos informáticos.
 la seguridad general (entorno, accesos físicos, seguridad contra incendios y daños por agua, consignas de
seguridad).
 los medios de seguridad implementados o previstos (servidores, red, terminales, alimentación eléctrica,
climatización, suministros, personal, etc). Es importante en este punto del proyecto apreciar el grado de confianza
que se puede dar a estos medios de socorro (¿los plazos de aplicación están garantizados? ¿Los medios están
documentados y probados?).
 los medios de protección de la información almacenada.
 soportes informáticos: copias de seguridad, archivos (acompañados de procesos de restauración fiables).
 soportes en papel (carpetas, archivos, documentación…).
 los medios de aplicación para garantizar la seguridad de los intercambios exteriores (protección de la red…).
 los contratos de mantenimiento del hardware y el software (verificación del grado de compromiso de los
prestatarios).
 los contratos de proveedores para los suministros sensibles (garantías de restablecimiento de servicio en caso de
interrupción).
 los medios de administración y explotación de los sistemas (auditoría de vulnerabilidades de sistemas y
aplicaciones, seguimiento de alertas…).

d. Fase 4: análisis de riesgos (BIA)

La fase de análisis de riesgos tiene por objetivo la clasificación de los riesgos de indisponibilidad total o parcial del Sistema
de Información y evidenciar las prioridades a la hora de tratar los riesgos. Ya que suele ser pesado llevar a cabo el PRD,
la definición de las prioridades puede facilitar su realización por partes.

El análisis de riesgos puede descomponerse en dos etapas:

 una etapa técnica de estudio de escenarios de siniestros.

 una etapa funcional de estudio de impacto.

El estudio técnico consiste, apoyándose en las constataciones de la fase anterior, en inventariar para cada objeto en
riesgo uno o varios riesgos significativos; a continuación, para cada riesgo que resulte, en estudiar y describir las
consecuencias directas de su realización sobre el Sistema de Información. En este punto, aún no nos preocupamos por
el impacto del siniestro. El objetivo es realizar una balanza entre consecuencias directas en términos:

 de duración de indisponibilidad de los medios (aplicaciones, servicios…).

 de perdida de información (últimas actualizaciones, flujo, archivos…).
 de potencial de riesgo. Según el método utilizado en la fase anterior, el potencial será atribuido directamente o
calculado.

La etapa funcional consiste en medir el impacto de los posibles riesgos ayudándose de criterios definidos en la fase de
lanzamiento. Esta evaluación debe realizarse con la ayuda de los responsables funcionales para tener en cuenta los
posibles medidas de contención existentes.

Página 109 de 146

e. Fase 5: presentación de soluciones

Las soluciones deducidas se validan entonces en el comité de decisión. Éstas son diferentes según todos los criterios que
hemos visto anteriormente. Veamos los grandes rasgos:

 La movilización de recursos necesarios:

 Recursos humanos: movilización de equipos de intervención.
 Reserva de medios de socorro (requisamiento de los medios, alerta de un prestatario externo…).
 Recuperación de copias de seguridad.
 Recuperación de la documentación.
 El soporte a los equipos informáticos:
 Restauración de entornos de sistema.
 Adaptaciones técnicas (el material de soporte no siempre es idéntico al material original).
 Restauración de aplicaciones.
 Validación de las restauraciones.
 El soporte a la red:
 Instalación de equipos de soporte.
 Basculación de los enlaces de soporte.
 Parametrización de los diferentes equipamientos.
 El soporte a la telefonía:
 Enrutamiento de las llamadas.
 Instalación de los equipos de soporte.
 Parametrización.
 La reanudación de los procesos:
 Adaptaciones de programas.
 Adaptaciones de procesos de explotación.
 Recuperación del flujo y sincronización de los datos.
 Tratamientos excepcionales.
 Validaciones funcionales.
 La logística:
 Transportes.
 Suministros.
 Gestión de crisis de personal (elección del personal que hay que movilizar, rotación de los equipos,
valoración de las situaciones individuales…).
 El realojamiento:
 Organización del realojamiento de urgencia.
 Preparación de los puestos de reemplazo.
 La reanudación de actividades y de servicios de usuario:
 Tareas de usuario antes de la implementación de los medios de soporte.
 Organización de un servicio mínimo.
 Trabajos excepcionales (procesos de contención, puestas al día…).
 La comunicación de crisis:
 Interna (personal, otras entidades…).
 Externa (clientes, asociados, público…).
 Los dispositivos de post-recuperación:
 Dispositivos previos y de acompañamiento (seguro, recuperación del estado de los locales, salvamiento de
los materiales…).
 Dispositivos de retorno a la normalidad (constituyen un plan específico).

La sinergia "Virtualización & PRD/PCA"

1. El PRD con presupuesto reducido

La virtualización va a permitir crear PRD de forma mucho mas fácil y racionalizando los costes. ¿Por qué? Por muchas
razones:

La mayoría de los planes de recuperación ante desastres consideran que las actividades deben retomarse en un sitio
secundario. Este sitio secundario debe acoger una parte o toda la carga de los servidores del sitio primario. Por tanto, a
menudo, habrá que invertir en material… que probablemente no se usará jamás. Si los servidores se virtualizan, la
inversión en material es mucho más reducida.

La virtualización simplifica enormemente los procesos de replicación y sincronización, al almacenar las máquinas virtuales
en bahías de almacenamiento, que soportan la replicación síncrona o asíncrona.
Página 110 de 146
 Igualmente, se pueden virtualizar los puestos de trabajo. Será suficiente con terminales "durmientes" en el sitio
secundario para que una gran parte de los usuarios pueda continuar su trabajo.

Los servidores no son más que simples archivos, por lo que son mucho más fáciles de guardar y transportar. La logística
es, por tanto, mucho menos importante. La restauración seguirá el mismo principio.

2. Superar el aspecto hardware

Tratándose de la virtualización, el hardware ya no será un problema. De hecho, un servidor ya no estará ligado al aspecto
material, lo que significa que un servidor virtual puede desplegarse sobre cualquier host físico y podrá reiniciarse sin que
interfiera ninguna incompatibilidad de hardware.

Además, los PRD conducen a menudo a lo que se llama "periodo degradado". De hecho, después de un desastre, la
actividad no se reanuda tan rápido. El personal está a menudo bajo los efectos del shock, no encuentra su entorno, el
sitio no está garantizado, los rendimientos son menores, no se reanudan todas las aplicaciones, etc. Resumiendo, durante
un periodo más o menos largo, el rendimiento puede sufrir un gran impacto.

La virtualización permite priorizar las actividades críticas. Por ejemplo, imagine que un servidor virtual reanuda el 30%
de la actividad global de una gran empresa. Seguramente le será difícil reanudarlo todo, ya que la carga es elevada, así
que podrá priorizar algunas máquinas o ciertas aplicaciones por encima de las demás. Las actividades serán degradadas,
cierto, pero todo lo que sea crítico podrá funcionar correctamente.

Página 111 de 146

 El mayor problema al implantar un PRD son los usuarios que deben, bajo cualquier concepto, poder seguir trabajando,
por lo que necesitan sus puestos de trabajo con su entorno. En un PRD clásico, el problema era mayor ya que hacía falta
un puesto de trabajo por usuario, lo que conllevaba costes a menudo prohibitivos. Una solución consiste en acordar con
un fabricante la entrega rápida de máquinas nuevas preparadas en caso de un duro golpe.

Con la llegada de la virtualización, la revolución está en marcha. Los puestos de trabajo no son más que simples archivos,
y no es necesario comprar puestos de trabajo, sino simples terminales ligeros, mucho más baratos. Ya que todos los
puestos de trabajo virtualizados están centralizados, los usuarios encontrarán rápidamente su entorno de trabajo, sea
cual sea el terminal desde el que se conecten.

3. La virtualización y el RPO/RTO
La virtualización permite considerar los sistemas como simples archivos. Por tanto, la restauración de un sistema se
vuelve casi tan rápida como la restauración de un archivo de gran tamaño.

Página 112 de 146

 Es suficiente preguntar a los administradores de sistemas el tiempo que necesitan para restaurar un sistema, Windows
o Unix. Según los procedimientos y procesos internos, esto puede suponer varias horas o incluso varios días o semanas.
La restauración de un archivo lleva, según el tamaño, desde algunos minutos hasta algunas horas.

Esto permite calcular en primera instancia la ganancia en RTO.

Veamos un ejemplo concreto:

Un servidor con Microsoft Windows 2003 Server se ha quemado. El administrador necesita:

 De varias horas a varios días para tener de un nuevo servidor (pasar por la central de compras, validar el pedido,
encontrar un modelo idéntico, etc).
 Varias horas para reinstalar una imagen del sistema (esperando que haya una y que funcione correctamente).
 Varias horas más para reconfigurar el sistema con las copias de seguridad (diferenciales, completas, etc).
 Varias horas, o incluso días, para restaurar los datos del sistema.

Estamos en el mejor de los casos. La máquina podría no estar bien guardada a nivel del sistema, en cuyo caso sería
necesario reinstalar totalmente Windows 2003 y reconfigurarlo como la primera vez, con el peligro que esto implica (no
existe garantía de que la reconfiguración se haga igual).

Tomemos ahora un ejemplo en el mundo virtual:

Un servidor físico que contenía una o varias máquinas se ha quemado.

En el peor de los casos, las máquinas virtuales estaban almacenadas localmente. Habrá que restaurar entonces las
máquinas virtuales en otro host físico (con riesgo de sobrecargarlo y entrar en un modo degradado temporal), lo que
puede suponer muchas horas.

En el mejor de los casos, las máquinas virtuales estaban almacenadas en una bahía centralizada con lo que sería suficiente
reasignar esas máquinas sobre otro host físico, que tenga acceso a la bahía de almacenamiento. Se necesitaría menos
de una hora para hacerlo.

Sea cual sea el caso, la ganancia en tiempo es considerable.

A nivel de RPO, tomemos el mismo ejemplo.

En el caso puramente físico, el servidor deberá restaurarse con los últimos datos. Existen varias posibilidades:

 los datos están centralizados y las pérdidas serán mínimas.

 los datos están almacenados localmente. Habrá que restaurar la última copia de seguridad (habrá mayor o menor
pérdida, según el proceso de copia de seguridad utilizado).

A nivel de sistema, si se hacen copias de seguridad según un período determinado, la pérdida de modificación será
mínima; si no se hacen, habrá una pérdida de las modificaciones del sistema o de las aplicaciones instaladas.

En una arquitectura clásica, la pérdida de datos es mínima a poco que la copia de seguridad se haga correctamente. A
nivel de sistema, esto es más difícil, y hay a menudo pérdidas de configuración o de las aplicaciones instaladas.

Veamos las diferencias con la virtualización implantada:

 los datos están centralizados, con lo que no cambia nada respecto a una arquitectura clásica.
 los datos no están centralizados y hay que restaurarlos con la última copia de seguridad. Aquí igualmente, no hay
demasiados cambios…

A nivel de sistema, sin embargo, el cambio es radical. En el momento en que los sistemas se virtualizan, son más fáciles
de guardar. El proceso de copia de seguridad garantiza que no habrá pérdida de configuración o de aplicaciones. No será
necesario restaurar el sistema además de restaurar la copia del sistema, lo que implica posibles problemas y pérdidas.

La pérdida de configuración y aplicaciones se minimiza gracias a la virtualización, ya que los sistemas se consideran como
datos clásicos.

Veamos una tabla recapitulativa para entenderlo mejor:

Comparativa RTO RPO

Modo clásico local Muy malo Muy malo

Página 113 de 146

 Comparativa RTO RPO

Modo clásico con datos traspasados Malo Bueno

Modo virtualizado con datos locales Bueno Bueno

Modo virtualizado con máquinas virtuales compartidas Muy bueno Muy bueno

Es posible que algunos productos del mercado permitan obtener un RTO o RPO mucho mejor en una infraestructura clásica.

4. Limitar la pérdida de datos

La pérdida de datos es un problema al que todo el mundo tiene que enfrentarse. Las infraestructuras virtuales responden
a este problema tanto para los servidores como para los puestos de trabajo.

Es relativamente fácil crear infraestructuras llamadas "Full Mesh", que son aquellas arquitecturas donde, si un elemento
falla, la arquitectura continuará funcionando. Esto permite garantizar igualmente un excelente RPO.

Veamos un tipo de arquitectura a menudo desplegada en clientes que quieren una alta disponibilidad además de la
garantía de no perder datos.

Los datos se replican gracias a las tecnologías propietarias en las bahías de almacenamiento. Podemos citar por ejemplo:

En NetApp: MetroCluster o SnapMirror (ver igualmente SnapManager for VI).

En EMC: SnapView o Sancopy (ver igualmente Replication Manager for VI).

Uno de los mayores miedos de los administradores es la pérdida de datos de usuarios almacenados localmente. En la
mayoría de infraestructuras actuales, existen paliativos, entre otros:

 Exportar "Documents and Settings" de los puestos de trabajo a un servidor centralizado.

 Impedir que los usuarios escriban en discos locales, ocultando los discos en cuestión.
 Instalar agentes en los puestos de trabajo para hacer copias de seguridad de los documentos de los usuarios.

Aunque estas soluciones funcionan correctamente, no significa que sean ágiles en términos de administración.

Página 114 de 146

 La virtualización de los puestos de trabajo responde a esta problemática. Ya que los puestos de trabajo se reemplazan
con terminales ligeros, no existe ningún dato local. El robo de puestos de trabajo no tiene sentido, ya que no contienen
ningún dato, ni siquiera residuales. Además, esto limita mucho el factor de "fuga de información". Los puertos USB u
otros pueden desactivarse fácilmente y toda la información queda centralizada en la empresa, siendo difícil que salga.

La virtualización de puestos de trabajo limita, por tanto, la pérdida de datos a muchos niveles. En resumen:

Puesto de trabajo clásico Puesto virtualizado

Pérdida de datos Todos los datos locales se pierden o deben ser Imposible
local restaurados.

Robo El puesto y todos los datos que contenía se pierden El robo es posible aunque el terminal por si sólo no
definitivamente. serviría para nada.

Siniestro Los puestos de trabajo siniestrados se pierden con los Sólo se pierde el terminal. Basta con comprar uno nuevo
datos que se encontraban en ellos. para poder trabajar con normalidad.

Fuga de A elegir: puerto USB, Bluetooth, firewire, etc. A peor, A poco que el terminal esté bien configurado, es muy
información robo del disco duro. difícil capturar datos.

Casos de empresa

1. Ejemplo con VMware SRM

VMware ha tomado la excelente iniciativa de lanzar un producto dedicado al plan de recuperación ante desastres. Era
difícil dejar esto de lado, ya que este capítulo está enteramente dedicado al PRD.

VMware Site Recovery Manager es un plug-in para Virtualcenter que permite instaurar una estrategia de recuperación de
la actividad. Ya VMware sólo controla el material servidor y no las bahías de almacenamiento, decidieron que el plug-in
SRM se comunicara con la utilidad propietaria de replicación inter bahía de cada fabricante.

Las ventajas son muchas:

 La replicación es rápida ya que los mecanismos son propietarios. No hay subcapa "VMware".
 Se crea una sinergia entre los fabricantes de bahías de almacenamiento y VMware (entre EMC y VMware, es más
bien normal…).
 El plug-in es ligero y se integra con todas las bahías de los fabricantes que respeten las recomendaciones de
desarrollo de VMware.
 La replicación es transparente para VMware y no se necesita comprobar que se haya llevado a cabo. Los fabricantes
se encargan de esta tarea sin impactar en los recursos del servidor.

SRM permite definir un plan de recuperación de actividad preconfigurando todas las etapas y automatizándolas hasta un
cierto nivel. Resumiendo, SRM se presenta como un coordinador que permite crear un auténtico PRD en la infraestructura
virtual existente con 2 sitios distantes.

Es evidente que SRM no se ocupa de los aspectos organizativos del PRD. Sólo un experto podrá coordinar el aspecto
técnico de SRM con las implicaciones a nivel organizativo.

SRM funciona de la siguiente manera:

Página 115 de 146

 VMware Virtualcenter se instala en 2 sitios diferentes: uno de producción y otro de backup. Hay que crear una
sincronización entre los dos, lo que vendrá a ser que uno de los Virtualcenter se llamará primario (sitio de producción)
mientras el otro será el secundario. Una vez que la sincronización está hecha, podrán intercambiar información de las
máquinas virtuales presentes.

El sitio primario puede comunicar al sitio secundario las máquinas protegidas. De hecho, SRM permite ser granular. La
protección puede hacerse eligiendo un conjunto de máquinas virtuales. Cuanto mayor sea el número de máquinas
virtuales seleccionadas, mayor será el tiempo de replicación de las bahías. Las máquinas llamadas protegidas se
encuentran sobre una LUN replicada.

Sea cual sea la tecnología de replicación y la conectividad utilizada, las LUN se replican desde el sitio de producción al
sitio de backup. En el sitio de Backup, las LUN son de sólo lectura, por lo que el Virtualcenter de Backup puede ver las
máquinas virtuales sin poderlas ejecutar. En caso de desastre, las bahías de almacenamiento del sitio de backup pasan
la/s LUN a modo READ/WRITE. A continuación arranca un proceso de guardado de máquinas virtuales para poderlas
reiniciar.

La ventaja de SRM es que es totalmente independiente al tipo de almacenamiento. Esto permite imaginar configuraciones
que permitirían reanudar las actividades, desde luego de forma degradada, pero con un coste muy inferior.

Página 116 de 146

 SRM posee particularidades interesantes, especialmente la posibilidad de:

 Simular el basculado para verificar que todo se pasa correctamente.

 Bascular las máquinas virtuales a una red particular para no crear conflictos a nivel de direccionamiento.
 Priorizar el arranque de ciertas máquinas para reiniciar inmediatamente los servicios críticos.

Página 117 de 146

  Seguir en tiempo real el basculado con todas las etapas previstas.
 Incluir scripts personalizados.

Uno de los puntos negativos de SRM sería su imposibilidad de gestionar el "Failback". Haría falta que VMware mejore su
utilidad para que sea posible volver atrás una vez que el sitio primario tiene la capacidad de retomar las operaciones.

2. Caso clientes
En último lugar, para convencer a los lectores de las ventajas de la virtualización al implantar un PRD, veamos un caso
de una empresa del CAC40 del sector industrial (el CAC40 es un índice bursátil francés) que concierne a la implantación
de un PRD a nivel mundial.

El cliente poseía dos Datacenter separados por muchos kilómetros, conectados entre ellos por fibra óptica. La
implantación del PRD se había programado hacía tiempo debido a la criticidad de los servidores de la primera sala de
máquinas, que permitían hacer funcionar todas las plantas de producción a nivel mundial.

En aquel momento, el cliente había despedido a 3.000 personas, debido a una reestructuración, con lo que la tensión era
palpable y la reducción de costes, una línea a seguir. El PRD era una apuesta importante pero estaba igualmente sujeto
a la reducción de costes. Se decidió entonces virtualizar la sala de seguridad.

El principio era relativamente rudimentario: las máquinas críticas fueron "ghosteadas" o reconstruidas en un entorno
virtual y no era posible hacer un PRD "Full VMware", ya que la primera sala no estaba virtualizada. Sin embargo, con un
poco de astucia y muchos scripts, se pudo construir un entorno operativo en la segunda sala de servidores.

El cliente tuvo la mala suerte de sufrir un corte eléctrico total debido a un incendio en un bosque. La empresa eléctrica
cortó por error todas las llegadas, incluso las de los sitios críticos (en este caso, los sitios de la empresa eran sitios
SEVESO, clasificación de empresas de riesgo según una directiva europeo).

La consecuencia directa fue que la producción de todas las plantas se detuvo y todas las salas informáticas sufrieron el
corte. Desgraciadamente, aquel día, los SAIs estaban en mantenimiento.

Hay que admitir que el cliente tuvo una mala suerte particular… Con su desgracia, ¡pudo validar su PRD!

Todos los servidores se vinieron abajo a la vez. El responsable del PRD decidió bascular las actividades a la otra sala de
máquinas. La basculación se realizó correctamente sin muchos problemas. Siempre hay imprevistos, pero con la
supervisión "en tiempo real" que se había implementado, fue muy fácil reaccionar rápidamente a los problemas
detectados.

La reanudación de actividades a nivel servidor funcionaba perfectamente, con lo que sólo quedaba bascular las líneas de
red al nuevo sitio, lo que desgraciadamente no funcionó bien. Los compromisos de los proveedores de acceso no eran
claras respecto a la noción del restablecimiento y hubo que esperar 5 horas hasta que la basculación fue efectiva.

Una vez se realizó la basculación, las actividades se pudieron retomar con normalidad.

Con lo que hay que quedarse de este caso es que un PRD es un proyecto complejo ligado a muchos actores, y que es
indispensable verificar que cada uno de ellos es capaz de asumir su papel. Existen soluciones técnicas en casi todos los
casos, pero a menudo es difícil contratar o exigir compromisos a los asociados o proveedores.

Copia de Seguridad y Restauración

La copia multinivel

1. La copia del Hipervisor

Desde versiones anteriores de VMware ESX, la Service Console ha tenido una importancia capital. VMware ha invertido
mucho para desvincular la Service Console del VMkernel, lo que hace que su copia de seguridad sea "menos crítica".
VMware también ha publicado VMware ESXi, versión más ligera de VMware ESX, que no tiene service console.

Existen tres componentes primarios de los que haya que hacer copia de seguridad en un host ESX:

 La configuración de la Service Console.

 La configuración de VMware ESX.
 La configuración de las Máquinas Virtuales.
Página 118 de 146
 La pregunta que nos hacemos es la siguiente:

Si usted almacena todas sus máquinas virtuales en una bahía de almacenamiento, con la misma configuración para todos
los hosts ESX, ¿realmente hay interés de guardar un host ESX?

Según sus procedimientos y métodos de configuración, es posible que la copia de seguridad de sus hosts ESX no sea
necesaria, y más aún cuando la reinstalación es muy rápida.

a. La copia de la Service Console

En las próximas versiones, VMware espera poder constituir un sistema prácticamente estático, lo que permitirá constituir
una base muy sólida a nivel de seguridad. Sin embargo, por el momento, deben hacerse copias de seguridad de la Service
Console. Como habrá podido ver, la Service Console es de hecho una distribución RedHat Linux 3 despojada de todos los
paquetes inútiles y optimizada para la comunicación con el VMkernel. Los directorios o archivos que hay que guardar son
los siguientes:

 /etc/profile
 /etc/ssh/sshd_config
 /etc/pam.d/
 /etc/ntp/
 /etc/ntp.conf
 /etc/passwd
 /etc/group
 /etc/shadow
 /etc/syslog.conf

b. La copia de VMware ESX

La configuración de VMware ESX y del VMkernel está almacenada en el directorio /etc/vmware. Aparte de casos
particulares, la copia de VMware ESX no es necesaria. El uso de VMware ESXi favorece este fenómeno.

c. La copia de la configuración de las máquinas virtuales

La configuración de las máquinas virtuales ya no es en absoluto dependiente del host donde se encuentre y se almacena
en un solo directorio. Por tanto, este punto se trata a parte en la copia de máquinas virtuales

2. La copia de Virtualcenter
No debe olvidarse Virtualcenter a nivel de copia de seguridad. Virtualcenter es, de hecho, una base de datos (o varias si
se instalan módulos complementarios), por lo que habrá que hacer sus copias de seguridad como cualquier máquina que
albergue una base de datos. Virtualcenter contiene las opciones, permisos y métricas usadas a diario por los
administradores.

Desde que Virtualcenter puede instalarse en una máquina virtual, es posible incluirlo en la copia de las VM. Sin embargo,
se aconseja igualmente copiar la base de datos de forma independiente.

3. La copia de las VM
Aunque la virtualización permite obtener un RPO mejor que en los entornos clásicos, la copia de seguridad también es
un elemento clave en una infraestructura virtual.

Existen dos formas de tratar la copia de máquinas virtuales:

La copia de seguridad de máquinas virtuales puede hacerse como antes con las máquinas físicas. Se pueden utilizar las
posibilidades de los OS invitados como por ejemplo: VSS, TAR, los comandos shell, etc.

Igualmente, se puede utilizar la portabilidad de las máquinas virtuales. Dado que se consideran como simples archivos,
su copia se puede realizar con mucha facilidad.

La elección no es simple, ya que a menudo cada máquina tiene sus ventajas e inconvenientes. La capitalización de
herramientas de copia interna es un argumento de peso que hace inclinar la balanza hacia los agentes propietarios. La
madurez de los agentes y su capacidad de trazabilidad y verificación son también puntos importantes aunque, por culpa
especialmente de la crisis económica, esto podría cambiar. ¿Por qué utilizar un agente (de pago) cuando es posible hacer
una copia de seguridad de todo el sistema con un simple comando?

Los diferentes tipos de copia de seguridad

Página 119 de 146

1. La copia por agente
La copia por agente es el método clásicamente más utilizado en los entornos físicos. Un agente se instala en el OS
invitado y la copia se inicia de manera regular o controlada por un servidor de backup externo.

Veamos las ventajas y los inconvenientes:

Ventajas

 Permite la copia a nivel de "archivos". La granularidad está muy mejorada. Es posible copiar simples archivos o
directorios de forma individual.
 Permite copiar los datos presentes en discos de tipo RDM en modo físico.
 Es independiente del Hipervisor.
 No necesita conocimientos particulares de VMware, lo que es interesante para equipos de copia de seguridad
existentes (no hace falta una formación adicional, los agentes son los mismos que para las máquinas virtuales,
todos los procesos implementados siguen siendo los mismos, etc).
 Comprensión de las aplicaciones internas, lo que permite copiar las aplicaciones transaccionales (por ejemplo Bases
de Datos).

Inconvenientes

 Es muy difícil copiar por completo el sistema.

 La portabilidad de las máquinas virtuales no se aprovecha.
 ¡El coste!

Página 120 de 146

2. La copia a nivel de imagen a través de agente
La copia a nivel de imagen permite preservar todo un sistema invitado y en el mundo físico se llama comúnmente copia
"Bare Metal", ya que requiere un alto consumo de recursos y por otro lado, es muy difícil de realizar cuando el sistema
está en línea.

La virtualización permite hacer una copia Bare Metal de una forma totalmente revolucionaria. La Service Console ve las
máquinas virtuales como un conjunto de archivos. Es muy sencillo por tanto conservarlos a través de los comandos
clásicos de copia de seguridad de archivos en UNIX.

Una máquina virtual está compuesta como máximo en producción (salvo en casos excepcionales) por unos diez archivos
(sin contar los archivos de log). La restauración será por tanto muy rápida, al contrario de las restauraciones Bare Metal
clásicas.

Existen varias formas de concebir la copia a nivel de imagen. De nuevo, todas tienen sus ventajas e inconvenientes.

La copia Bare Metal puede hacerse por un agente. La copia del sistema debe efectuarse en correlación con la creación de
un CD-Rom de arranque. Puede iniciarse un servidor en ese CD-Rom para restaurarlo completamente. El CD-Rom no
contiene ninguna imagen, sólo sirve para cargar un entorno mínimo (basado a menudo en Windows PE o LinuxPE) que
permite recuperar una imagen de la red o de un soporte local como USB, Firewire, etc.

Como el entorno es virtual y hay que aplicar el método Bare Metal tradicional, es indispensable tener algunos
conocimientos del entorno VMware.

Veamos las ventajas e inconvenientes:

Ventajas
Página 121 de 146
  La copia de seguridad puede hacerse a través del mismo agente utilizado para la copia a nivel de archivo.
 Se integra perfectamente en la infraestructura existente.
 Los procedimientos y procesos implementados se mantienen.

Inconvenientes

 El proceso de restauración es manual, debido a su complejidad (sin embargo se puede hacer un script).
 El coste.

3. La copia a nivel de imagen a través de VMware

Como habrá visto anteriormente, la copia de seguridad puede hacerse a través de la Service Console. Gracias a los
snapshots, los archivos VMDK pueden copiarse perfectamente mientras siguen en uso y exportarse a cualquier tipo de
soporte. El principio es el siguiente:

Página 122 de 146

 Veamos las ventajas y los inconvenientes:

Ventajas

 La copia es simple y poco costosa.

 Poco impacto a nivel de rendimiento, comparado con el método clásico Bare Metal.
 No intrusivo, ya que no necesita ningún agente. Sólo se usan los mecanismos de VMware.
 Mucho más fiable.

Inconvenientes

 No se puede hacer copia de seguridad a nivel de archivos.

 Necesita un cambio en los procedimientos y procesos existentes.

La optimización de la copia de seguridad

1. La copia incremental
En una infraestructura tradicional, la copia incremental no tiene en cuenta los archivos que no se han modificado desde
la última copia. Pero en una infraestructura virtual, sólo se modifica el archivo .VMDK, y se hace de forma constante. La
copia incremental, por tanto, no tiene, a priori, razón de existir.

Para responder a esta necesidad, los editores de software decidieron considerar los archivos VMDK como archivos
especiales, que se descompondrán en múltiples partes. De hecho, el archivo VMDK se visualiza a nivel de bloque. Sólo
los bloques modificados serán copiados.

Para poder comparar los bloques, es necesario haber hecho previamente al menos una copia completa del archivo .VMDK.

Veamos un ejemplo concreto:

El archivo .VMDK se copia por completo el fin de semana.

El Lunes, se modifican los bloques del 1 al 3.

El Martes, se modifican los bloques del 4 al 7.

El Jueves, sólo se modifica el bloque 8.

El Viernes, se modifican los bloques 8 y 9.

Es por tanto fácil comparar el espacio de almacenamiento que se ahorra en comparación a una copia completa.

Página 123 de 146

 Copia completa

Día Bloques modificados

Sábado 10

Lunes 10

Martes 10

Miércoles 10

Jueves 10

Viernes 10

TOTAL 60

Copia incremental

Día Bloques modificados

Sábado 10

Lunes 3

Martes 2

Miércoles 0

Jueves 1

Viernes 2

TOTAL 18

Aquí, en este ejemplo, el espacio de almacenamiento está dividido en 3.

Desgraciadamente, la restauración de la copia incremental no es muy práctica. De hecho, se considera como la más
económica, pero también la que tiene peor RTO. Hay que imaginar el caso en que un administrador desee restaurar los
archivos corruptos entre semana, por ejemplo, el Jueves. Deberá restaurar la copia completa y luego restaurar cada una
de las copias incrementales, es decir, Lunes, Martes, Miércoles y Jueves.

Veamos las ventajas e inconvenientes :

Ventajas

 Sólo se tienen en cuenta los datos modificados.

 El espacio de almacenamiento se maximiza, ya que a menudo se reduce por 3 ó 4 el espacio que normalmente
consumía una copia completa.

Inconvenientes

 El RPO es muy malo. Es necesario restaurar la copia completa además de cada una de las copias incrementales
hasta el punto de recuperación deseado.
 Ya que cada bloque se copia de forma independiente, y que la alteración de un solo bloque puede conducir a la
corrupción completa del archivo VMDK, la probabilidad de corromper este mismo archivo es mucho más alta.

Página 124 de 146

2. La copia diferencial
La copia diferencial consiste en guardar todos los bloques que se han modificado después de la última copia completa.
La comparación se hace cada vez con la copia completa.

Veamos un ejemplo concreto idéntico al anterior:

El mismo archivo .VMDK se copia por completo el fin de semana.

El Lunes, se modifican los bloques del 1 al 3.

El Martes, se modifican los bloques del 4 al 7.

El Jueves, sólo se modifica el bloque 8.

El Viernes, se modifican los bloques 8 y 9.

Esto nos permite comparar con el espacio de almacenamiento que nos ahorramos respecto a una copia completa.

Copia completa

Día Bloques modificados

Sábado 10

Lunes 10

Martes 10

Miércoles 10

Jueves 10

Viernes 10

TOTAL 60

Copia diferencial

Página 125 de 146

 Día Bloques modificados

Sábado 10

Lunes 3

Martes 5

Miércoles 5

Jueves 6

Viernes 7

TOTAL 36

Aquí podemos ver dos diferencias respecto a la copia incremental. El Miércoles no se realiza ningún cambio y sin embargo,
se copian 5 bloques, ya que hay 5 bloques modificados desde la última copia completa.

El Viernes, el bloque 8 se modifica por segunda vez. Al contrario que en la copia incremental, la copia diferencial considera
que el bloque 8 se ha modificado desde la última copia, pero no guarda la modificación entre el jueves y el viernes, sino
que sólo guarda la diferencia entre la copia completa y el viernes.

Aquí, el espacio ahorrado está alrededor del 40% respecto a copias completas. La copia diferencial no es tan eficaz como
la copia incremental en términos de espacio.

Sin embargo, la restauración es mucho más práctica, ya que es suficiente con restaurar la copia completa y la copia
diferencial.

Veamos las ventajas e inconvenientes :

Ventajas

 El RTO es mejor: sólo serán necesarias dos etapas para restaurar un archivo .VMDK.
 El espacio de almacenamiento es menor respecto a la copia completa.
 La probabilidad de corrupción es reducida.

Inconvenientes

 La copia diferencial tiene un efecto de bola de nieve. Cuantos más días pasan, más se modifican los datos, lo que
implicará que crezca el tamaño del archivo.
 Teóricamente, si todos los bloques se modifican, la copia diferencial puede tener el mismo tamaño que la copia
completa. Sin embargo, esta probabilidad es débil en los archivos VMDK.

3. La deduplicación
La deduplicación podría compararse con la tecnología usada por VMware para la compartición de páginas de memoria.
La deduplicación permite eliminar la información redundante que exista en los sistemas con similitudes.

Cada archivo se descompone en partes, y a cada parte se le asocia un identificador único, que se almacena en un índice.
El objetivo de la deduplicación es almacenar una sola vez la misma parte de un archivo. Cada vez que se localiza una
parte idéntica, se reemplaza por un puntero hacia el identificador correspondiente.

Página 126 de 146

 En el despliegue de una arquitectura virtual, los sistemas invitados instalados en las máquinas virtuales son a menudo
idénticos o presentan muchas similitudes. Las únicas diferencias se sitúan a nivel de parametrización de cada sistema
invitado.

Según las pruebas efectuadas recientemente con clientes sobre la virtualización de puestos de trabajo con VMware View
3 y de bahías de almacenamiento NetApp FAS 3040, la reducción del consumo de espacio de disco era del orden del
90%. La explicación es lógica : la virtualización de puestos de trabajo implica el uso de Template, lo que significa que los
sistemas invitados serán prácticamente idénticos.

La deduplicación es diferente a la copia de seguridad, pero permite reducir enormemente la cantidad de datos que hay
que guardar. Desgraciadamente, esta tecnología tiene una gran vulnerabilidad: el índice general es vital y si tuviera que
alterarse, sería imposible recuperar las máquinas virtuales.

Veamos las ventajas e inconvenientes :

Ventajas

 Reducción extrema de la cantidad de datos que hay que guardar.

 La copia de máquinas virtuales es muy rápida.
 La deduplicación tiene poco impacto en el rendimiento.

Inconvenientes

 La vulnerabilidad del índice generado.

 En caso de fallo total, deberá restaurarse todo antes de poder reanudar las actividades.
 La ausencia de determinismo. No se puede conocer el beneficio del uso de esta técnica si no se hace una prueba
en entorno real.

Página 127 de 146

Las soluciones de copia optimizadas para las VM

1. VCB
VCB o VMware Consolidated Backup es un plug-in desarrollado por VMware que permite a los desarrolladores de software
de copia de seguridad disponer de comandos y controles necesarios para poder copiar las máquinas virtuales a nivel de
archivo y a nivel de imagen.

Un error común consiste en considerar que VCB es un programa de copia de seguridad, mientras que se creó para
eliminar la necesidad de un agente clásico en las máquinas virtuales. VCB es, de hecho, un proxy de copia de seguridad,
que permite leer un archivo .VMDK en modo sólo lectura y montarlo sobre un servidor Windows para poder buscar los
datos deseados. Desgraciadamente, al contrario que los agentes clásicos, el proxy VCB sólo puede leer las particiones
Windows. Para los demás sistemas, la restauración a nivel de archivo con VCB no será posible.

Hay que distinguir VCB para los dos modos de copia de seguridad: a nivel de archivos o a nivel de imagen.

a. VCB a nivel de archivos

Para comprender el modo de funcionamiento de VCB para la copia a nivel de archivo, veamos un resumen de las etapas:

 Un usuario desencadena VCB o un software de copia de terceros.

 Se puede ejecutar un script para congelar las E/S.
 Se efectúa un snapshot de cada disco VMDK. Si los discos no pueden ser snapshoteados, no se podrá hacer la
copia a través de VCB.

Los discos RDM tipo físico o no persistentes no pueden copiarse con VCB.

 Una vez hecho el snapshot, se retoman las E/S.

 Los discos VMDK se montan sobre el proxy de copia.
 El agente de Terceras partes copia los datos en el interior de los archivos VMDK montados.
 Los directorios se desmontan.
 Los snapshots se reaplican a los archivos VMDK para poder reanudar las actividades.

Veamos las ventajas e inconvenientes:

Ventajas

 Reduce la necesidad de un agente en las máquinas virtuales.

 El impacto a nivel de rendimiento es mínimo.
 Todo pasa a nivel de SAN, por lo que el impacto a nivel de red será también mínimo.
 Permite a una empresa utilizar una sola plataforma Proxy para realizar las copias de seguridad de todo su entorno.

Inconvenientes

 Requiere el uso de una SAN.

 Todo se coordina desde el Proxy VCB. Esta máquina es por tanto crítica y recibirá un gran impacto en caso de
restauración.
 Es un sistema Windows que accede a las LUN VMFS, lo que puede engendrar un posible riesgo de corrupción.
 Restauración a nivel de archivo únicamente para Microsoft Windows.

b. VCB a nivel de imagen

VCB puede hacer copias completas de los archivos VMDK sin necesidad de montarlos. Como VCB no necesita mirar en el
interior de los archivos VMDK, la copia a nivel de imagen es compatible con cualquier sistema invitado.

Veamos un resumen de las etapas:

 Un usuario desencadena VCB o un software de copia de terceros.

 Se puede ejecutar un script para congelar las E/S.
 Se efectúa un snapshot de cada disco VMDK. Si los discos no pueden ser snapshoteados, no se podrá hacer la
copia a través de VCB.

Los discos RDM tipo físico o no persistentes no pueden copiarse con VCB.

Página 128 de 146

  Una vez que el snapshot se ha efectuado, se retoman las E/S.
 Los discos VMDK se exportan a un directorio especificado por el usuario de VCB.
 Los snapshots se reaplican a los archivos VMDK para poder reanudar las actividades.

Veamos las ventajas e inconvenientes:

Ventajas

 Permite copiar fácilmente todas las máquinas virtuales.

 El impacto a nivel de rendimiento es mínimo.
 Todo pasa a nivel de SAN, el impacto a nivel de red será también mínimo.
 ¡El coste! (respecto a una solución Bare Metal clásica).

Inconvenientes

 Necesita un espacio de almacenamiento consecuente para todas las máquinas virtuales.

 Es imposible restaurar archivos desde una copia a nivel de imagen.
 Es un sistema Windows que accede a las LUN VMFS, lo que puede engendrar un posible riesgo de corrupción.
 Genera muchas E/S tanto a nivel de proxy como de SAN.

2. Vizioncore vRanger
vRanger es una herramienta desarrollada por Vizioncore que permite realizar copias de las máquinas virtuales. Se puede
integrar con VCB para aprovechar sus ventajas y posee un driver VSS que permite realizar mejores copias de seguridad
de máquinas virtuales que tienen aplicaciones transaccionales. Veamos en detalle algunas ventajas de vRanger:

Copia diferencial

vRanger puede realizar copias diferenciales a través de VCB para reducir el tamaño de los archivos al mínimo.

Uso de VSS

Tiene un driver VSS integrado, para copiar las aplicaciones transaccionales de forma consistente. Típicamente, esto
permite realizar copias de bases de datos y restaurarlas a nivel de archivo.

Integración con VCB

La integración con VCB permite repartir el trabajo en servidores Proxy. La infraestructura sigue siendo coherente ya que
todo saldrá de las máquinas VCB.

3. Veeam Backup
Veeam Backup es una herramienta particularmente interesante y fácil de probar, ya que está disponible en descarga
libre (para la versión gratuita).

Veeam Backup soporta:

 La copia de seguridad de ESX y ESXi.

 La restauración tanto a nivel de imagen como de archivos en una sola copia. Por tanto, ya no será necesario
realizar dos tipos de copia de seguridad…
 El soporte de VSS para poder copiar correctamente las aplicaciones transaccionales.
 La deduplicación. Cuando las máquinas virtuales presentan similitudes, Veeam Backup es capaz de reducir el
espacio de almacenamiento necesario (incluso si la deduplicación está activa a nivel de SAN).
 La integración con VCB.

Página 129 de 146

Futuros Retos y Evoluciones de la
Virtualización
El Provisioning

1. Definición
El Provisioning consiste en asignar recursos de forma más o menos automática en función de las necesidades. Gracias a
la virtualización, el provisioning tiene mucho sentido. Es posible asignar recursos "on demand". La ventaja del provisioning
es evidente: no será necesario asignar recursos hasta que se necesiten, lo que evita gastos inútiles.

Por otro lado, la facilidad de crear máquinas virtuales ha cambiado la forma de trabajar de muchas direcciones de los
Sistemas de Información. Desde que un proyecto emerge, se aprovisiona una máquina virtual. Cuando se trata de
entidades que gestionan miles de proyectos cada año, imagínese la cantidad de máquinas virtuales "huérfanas", ya que
no hay quién sepa cuándo, ni por qué existen.

Será por tanto obligatorio desplegar un auténtico proceso de gestión de la vida de las máquinas virtuales. VMware ha
trabajado mucho sobre este aspecto con VMware Lifecyle Manager y VMware Orchestrator. Desgraciadamente, estas
herramientas están muy poco extendidas, aunque la demanda real exista.

Una vez perfectamente industrializadas, estas herramientas permitirán gestionar a diario el conjunto de la infraestructura
virtual. Una máquina virtual se crea por una necesidad concreta, tiene una duración de vida (extensible o no) y será
automáticamente retirada cuando pase el periodo.

Aunque también es posible llegar aún más lejos.

Como si fuera un programa (ver el Software Development LifeCyle: SDLC. http://tinyurl.com/6gt5os), una máquina
virtual también debe tener un ciclo de vida. Es posible, por ejemplo, configurar el proceso siguiente:

Etapa 1: surge la necesidad. Se realiza un estudio de viabilidad, según el que los arquitectos decidirán crear una máquina
virtual.

Etapa 2: el equipo de red valida la máquina virtual y le asigna una o varias direcciones IP.

Etapa 3: el equipo a cargo de la copia de seguridad verifica la necesidad en términos de espacio de disco y se asignan
discos a la máquina virtual.

Etapa 4: el equipo de seguridad valida el conjunto de la máquina virtual y verifica que sea conforme a la política de
seguridad interna.
Página 130 de 146
 Etapa 5: los arquitectos reciben la confirmación de que todas las partes han validado la máquina virtual, y pueden
empezar su creación.

Etapa 6: la máquina virtual creada se asigna a su propietario.

2. Las Templates
Las Templates permiten crear nuevas máquinas virtuales a partir de una imagen existente. Es posible crear máquinas
virtuales llamadas de referencia y customizarlas lo suficiente para crear máquinas virtuales totalmente independientes.
Es posible crear las Templates de máquinas Linux, Windows, Solaris u otras. Sin embargo, VMware gestiona mejor la
parametrización de las máquinas Windows, gracias a herramientas como SYSPREP.

Las Templates son una gran ventaja para los operarios ya que:

 Permiten desplegar muy rápidamente nuevas máquinas sin pasar por las etapas clásicas: instalación por CD-Rom
o imagen ISO, instalación de drivers, etc.
 Esto permite garantizar que la máquina virtual desplegada a partir de una Template cumple toda la parametrización
efectuada al crear la Template. Por ejemplo, muchas empresas han invertido mucho en lo que llaman un MASTER,
que es una imagen tipo desplegada en un entorno particular. Un MASTER de oficina será, por ejemplo, desplegado
en todos los entornos PC de oficina.
 La seguridad se refuerza ya que las Templates se despliegan de forma totalmente automatizada, lo que reduce
enormemente el riesgo de error humano. Los parámetros de seguridad se integran a las Templates y no será una
persona quien los introduzca o reconfigure.
 Las Templates se pueden reconfigurar fácilmente. Basta con desplegar una máquina virtual a partir de una
Template, hacerla evolucionar (actualizaciones, instalación de productos, etc), y volver a convertir la máquina
virtual en Template.

Desde un punto de vista organizativo, las Templates garantizan que el trabajo de los operarios se centre en utilizar lo
que han definido los arquitectos. Las Templates permiten diferenciar bien los roles de cada uno. Habitualmente, los
operarios tienen la responsabilidad de la instalación y la configuración de las máquinas, pero no por ello se les ha formado
en los productos que instalan o configuran. Por tanto, pesa la incertidumbre sobre la garantía de que todo se haya hecho
correctamente, según las normas impuestas por los arquitectos, o incluso que los procesos, guías y procedimientos se
hayan seguido de forma que se reduzca el margen de error.

Si las Templates se han fabricado por arquitectos o personas con la capacidad necesaria para la configuración de las
máquinas, la posibilidad de error humano por parte de los operarios se reduce bastante.

En un futuro cercano, sería deseable que las Templates se integren aún mejor con los sistemas invitados (parámetros
suplementarios, integración automática de utilidades, actualizaciones, etc) y que sea mucho más fácil desplegar varias
máquinas virtuales de forma totalmente automatizada (además de por scripts…).

3. El Thin Provisioning
El Thin Provisioning es una tecnología proveniente del mundo del almacenamiento, que consiste en asignar los recursos
sólo cuando se solicitan. Por tanto, es una evolución del provisioning clásico. Esta tecnología presenta un espacio de
almacenamiento a una aplicación, pero sólo reserva físicamente lo que de verdad se utiliza. Esto permite por tanto
economizar una gran cantidad de espacio de almacenamiento.

El Thin Provisioning a menudo está ligado a la capacidad llamada Over Allocation. Esta tecnología permite hacer creer a
un sistema que dispone de un espacio de almacenamiento infinitamente mayor del que realmente existe, físicamente
hablando. Las ventajas son las siguientes:

 No es indispensable pensar en la evolución de las aplicaciones y de los sistemas. El almacenamiento físico será
asignado dinámicamente según lo que las aplicaciones y sistemas demanden día a día.
 No hay complejos obstáculos relacionados con el aumento o la disminución de la partición. ¿Quién no se ha
enfrentado nunca al famoso problema de la partición del sistema que llega a la saturación?

VMware integra la noción de Thin Provisioning desde la versión 3 de VMware Workstation. Desde la llegada de VMware
ESX 3, se pueden crear discos llamados "thin ". Además, los desarrolladores de software han llegado al mercado para
proponer el Thin Provisioning avanzado.

Datacore es un innegable actor de mercado en este aspecto.

La noción de soporte
Página 131 de 146
1. ¿Por qué es un reto?
Cuando hablamos de virtualización, una simple pregunta puede calentar los ánimos: la noción de soporte. Muchos actores
de mercado no ven con buenos ojos la llegada de la virtualización, debido a muchas razones:

 Los desarrolladores de software creen que la virtualización les traerá muchos problemas (ralentización, bugs,
problemas de E/S, etc). El hecho de no soportar un software en un entorno virtualizado permite prevenirse contra
muchos posibles fallos...
 Algunos desarrolladores han visto un interés estratégico. Oracle, por ejemplo, rechazó garantizar, en un primer
momento, el soporte de sus productos en un entorno virtualizado. Por otra parte, sólo su propio sistema de
virtualización (Oracle VM) soportaba bien sus productos. De la misma forma, es evidente que Microsoft, que
posee su propio sistema de virtualización, asegura un mejor soporte para todos sus productos si están instalados
bajo su propio hipervisor.

El reto, por tanto, es principalmente estratégico. Los programadores de sistemas operativos se convierten poco a poco
en programadores de software de virtualización. Uno de los pocos actores que no tiene un sistema operativo propio es
líder en el mercado de la virtualización, como es el caso de VMware. Éste es un punto débil contra el que el resto de
actores van a atacar con anuncios más o menos ambiguos; lo importante será distinguir lo verdadero de lo falso en sus
discursos de marketing.

2. ¿Cómo se orienta el mercado?

El mercado está dominado de momento por VMware, por su avance tecnológico y por su amplia experiencia con clientes.
Sin embargo, la competencia empieza a conseguir buenas referencias y recortan poco a poco la diferencia. Por el
momento, la noción de soporte de las máquinas virtuales es algo confusa.

Es evidente que frente a la oleada de la virtualización, los desarrolladores de software, sea el que sea, no podrán resistir
mucho. Sin embargo, a pesar de todo, no existe garantía de que quieran invertir para facilitar esta transición. (Ver
http://tinyurl.com/phqowk).

La virtualización introduce arquitecturas distribuidas complejas pero muy robustas. El problema de las arquitecturas
complejas a menudo tiene que ver con el soporte. Cada uno de los actores puede potencialmente reportar la falta sobre
los otros; es lo que a menudo se llama el "Ping-Pong " en el argot informático.

La Capacity Planning

Página 132 de 146

1. Las métricas fiables
La mayoría de las veces, los operarios se esfuerzan en tener una visión de la capacidad global del Sistema de información para absorber la carga
corriente. Esto se traduce por un "ansia" en la compra de material. Cuandos más servidores existan y mayor sea el espacio de almacenamiento, más
aplicaciones nuevas podrán acogerse.

Esta reflexión tiene sus limitaciones, sobre todo en un contexto de crisis económica. Hoy en día, el lugar está en la consolidación. Está fuera de lugar
para los responsables de compras adquirir nuevo hardware mientras, a menudo, el 75% de la capacidad de su Sistema de Información está sin utilizar.

El problema se debe, en general, a la heterogeneidad de los sistemas históricamente desplegados. Estos se comunican de forma distinta y se utilizan de
manera disparatada. Además, las alertas y métricas reportadas no están en el mismo formato, lo que impide la instalación de un sistema de recolección
centralizado.

La virtualización responde a esta problemática. Ya que la capa de virtualización es la misma en todos los servidores, los informes son idénticos sean
cuales sean los sistemas invitados (lo que no impide implementar un traspaso de información para cada uno de los sistemas invitados).

Por tanto, es posible desplegar un auténtico Capacity Planning. La virtualización, como habrá visto anteriormente, se concentra en las CPU, la
memoria, los discos y las tarjetas de red. Las métricas concernientes a estos cuatro elementos se estandarizan perfectamente. La interfaz de
centralización se encuentra en Virtualcenter o vCenter más recientemente en VMware. Toda la información se almacena en una base de datos SQL,
que permite crear consultas personalizadas en base a las necesidades.

2. Anticipar a la evolución
El despliegue de un sistema de Capacity Planning permite prever la evolución de su propio Sistema de Información.
Aunque esto sería un cálculo de probabilidades, los indicadores son muy significativos y merecen una atención particular.

Por ejemplo, es posible calcular:

 La media de uso del conjunto de las CPU, memoria, discos y consumo de red.
 Los picos de carga, el impacto de las actualizaciones y las copias de seguridad.
 El impacto de los procesos batch y otros sistemas de proceso.

Es muy recomendable prever el crecimiento de su Sistema de Información como harían los analistas del sector financiero.

Página 133 de 146

 Un desarrollador se interesa particularmente en este sector: Vkernel http://www.vkernel.org

Hacia una concentración de arquitecturas

1. Las iniciativas de los fabricantes

Los fabricantes han comprendido que la consolidación sólo sería efectiva hasta si podían unir sus servidores con la
virtualización. Los sistemas Blade, como los Bladesystem en HP o Bladecenter en IBM, permiten concentrar muchos

Página 134 de 146

 servidores en un espacio reducido. Además, la administración se hace desde un punto central a nivel de hardware, lo
que permite reducir el tiempo de administración de bajo nivel.

Generalmente, los sistemas Blade se comunican con las bahías de almacenamiento a través de una red muy potente
(fibra óptica o FCOE). Los fabricantes rivalizan ingeniosamente para combinar virtualización y sistemas blade. Proponen,
por ejemplo, capas de abstracción suplementarias a nivel de hardware.

A veces, los fabricantes integran el almacenamiento o permiten virtualizar la red. Sea como sea, hay muchas iniciativas.
La apuesta es importante por varias razones:

 Los fabricantes elegidos van a invertir de ahora en adelante en el área de red, sistemas, supervisión y
administración. Es una forma de asegurarse poder vender una importante cantidad de prestaciones.
 Las empresas deberán comunicarse con pocos actores a la vez, y del sistema actual llamado de "referencia". Esto
permite reducir costes ya que los actores seleccionados se comprometen a ofrecer precios que desafían cualquier
competencia. Así, los fabricantes seleccionados saben que tienen la posibilidad de invertir en todas las áreas sin
ser molestados por posibles competidores. El objetivo es vender el máximo de material, a riesgo de perder dinero,
para después poder proponer muchas prestaciones. Por esta razón, los fabricantes de hardware (HP e IBM en
cabeza) se han transformado estos últimos años en sociedades de servicios.
 El dominio del Sistema de Información se basa, a pesar de todo, en la arquitectura física. Si el fabricante no valida
desde un punto de vista de hardware, será imposible desde un punto de vista hardware, no habrá nada que
hacer. Por tanto, será el hardware el que tenga la última palabra.

2. Nuevos actores… ¿la revolución ha empezado?

Hasta ahora, los líderes de la virtualización de servidores eran:

 HP
 Dell
 IBM

Hay nuevos actores que invierten en el mercado de la virtualización y que los van a retar. Recientemente, la adquisición
de SUN por Oracle hace presagiar que los servidores SUN van a ser optimizados para las aplicaciones Oracle, y sobre
todo para la virtualización (no olvidemos que, aunque sus productos nunca han tenido demasiado éxito, SUN y Oracle
han desarrollado sus propias herramientas de virtualización).

Esta compra fue una sorpresa para todo el mundo, y más teniendo en cuenta que IBM había hecho una oferta para
comprar SUN. Si hubiera sido el caso, un actor habría desaparecido progresivamente del mercado de los servidores.
Ahora debería ser al revés, con la aparición de un nuevo actor en la virtualización de servidores, que tiene un gran control
de las aplicaciones críticas. Así que ahora podemos imaginar los paquetes "servidores SUN - capa de virtualización -
aplicaciones Oracle".

Recientemente, Cisco anunció que quería conquistar el mundo de los servidores gracias a la oferta Cisco UCS (Unified
Computing System), con lo que pretende ser totalmente innovador.

Se teme la llegada de Cisco al mundo de los servidores, por varias razones:

 Cisco posee acciones de VMware, por lo que hay una gran probabilidad de que su colaboración vaya más allá de
una cooperación clásica.

Página 135 de 146

  Cisco domina la red. Aunque existen muchos fabricantes que tienen su propia tecnología de red (especialmente HP
con los Procurve), no dan la talla frente al líder del mercado.
 Cisco ha trabajado en VMware ESX 4 con los switchs Nexus1000v, por lo que pronto será indispensable para
cualquier infraestructura virtual.
 Cisco se ha aliado, para la UCS, con un competidor de almacenamiento para crear una oferta totalmente
competitiva: NetApp. Esta voluntad de escoger a un competidor está evidentemente calculada, y muestra que
Cisco quiere romper las reglas establecidas en el mercado de los servidores y ser más agresivo comercialmente.
 Cisco ha colaborado con Intel incorporando, varios meses antes, procesadores Nehalem. La UCS se ha ido
desarrollando por tanto en colaboración con Intel en un marco muy secreto. En el momento que se ha escrito
este libro, la UCS se ha probado en una sola empresa en Europa y 6 en Estados Unidos. Después de haber
trabajado durante algún tiempo en la primicia de la implementación de la UCS a nivel europeo, es evidente que:
 La UCS es extremadamente potente y modulable. El uso de FCOE sobre interfaces 10 Gbits permite
maximizar los costes, asegurando unos resultados fuera de lo común.
 La UCS añade una capa de abstracción suplementaria a nivel de red. Se pueden tener direcciones Mac y
WWN virtuales.
 Cisco quiere que nos olvidemos totalmente del hardware, para lo que se ha creado la noción de perfil. Es
totalmente posible crear perfiles que tienen componentes hardware diferentes sin ninguna capa de
virtualización. La virtualización se añade bajo los perfiles creados.
 La UCS es extremadamente compleja, ya que lo agrupa todo en un solo bloque. La interfaz creada para la
ocasión es, de momento, difícil de gestionar. Esta interfaz estaba en versión Beta, y ha evolucionado
según las necesidades aparecidas. Cisco ha estado muy atento a nuestras peticiones, algo excelente.

Por otro lado, algunos también han llegado a salir del apuro. Nec se pronuncia sobre el Flexpower, un servidor tipo Blade
que agrupa espacio de almacenamiento (visto como una SAN) y ranuras clásicas. Las ventajas son muchas:

 Los precios han tirado a la baja y los discos son mucho más baratos que los discos SAN.
 El servidor es totalmente autónomo.
 La interfaz de configuración es extremadamente intuitiva.

Sea como sea, los líderes tendrán que aguantar una fuerte competencia en los próximos años.

¿Qué queda por mejorar?

1. Hacia un Hipervisor integrado

Los Hipervisores son, de momento, la propiedad de los programadores de software de virtualización, y deben:

 Ser cada vez más ligeros.

 Ser cada vez más potentes.
 Soportar cada vez más hardware.

Se deben prever varias soluciones. Muchos piensan que el Hipervisor migrará a nivel de procesadores, ya que estos
tienen instrucciones dedicadas a la virtualización, y deberían integrar cada vez más memoria, permitiendo así la
integración del Hipervisor en el núcleo del procesador. Aunque esta posibilidad no se contempla oficialmente por el
momento, estaría propuesta como una opción en la BIOS u otro.

Se puede prever esta posibilidad, pero conlleva muchos problemas políticos. De hecho, ¿qué hipervisor será el integrado
en el procesador? Ya que Intel ha tenido muchos problemas jurídicos, especialmente en lo que concierne a abuso de
posición dominante, no podría aliarse con un solo editor.

Página 136 de 146

 Otros creen que la capa de virtualización se instalará en una partición especial de los servidores, que estará reservada
únicamente al Hipervisor. Igualmente, las ventajas serán muchas. Esta partición se beneficiará de una protección
particular y podrá optimizarse de varias formas.

Una opción interesante sería la posibilidad de parametrizar a bajo nivel los servidores, para que se registren
automáticamente en la gestión de recursos virtualizados. Así, si se añadieran servidores se percibiría como el añadido
de recursos a una o varias pools, y existiría una abstracción total de cara al hardware.

Sin embargo, quedaría una pregunta en el aire: ¿cuál será la interoperatibilidad del Hipervisor integrado?

2. La estandarización
La estandarización es un tema delicado en el medio de la virtualización. De hecho, todos los actores quieren convertirse
en el Hipervisor de referencia, a riesgo de ser totalmente gratuito, para poder revender el ecosistema asociado. Sin
embargo, los responsables tienen miedo de encontrarse rápidamente acorralados por una sola tecnología. La
interoperatibilidad entre los diferentes productos de virtualización, además de la estandarización, es una etapa principal
antes de conseguir madurez en el mercado de la virtualización.

Hoy en día, se llevan a cabo numerosos trabajos en este sentido:

 Las máquinas virtuales son cada vez más interoperables. Aunque aún se necesitan programas para convertirlas,
es posible que de aquí a unos años las máquinas virtuales puedan exportarse de forma transparente a cualquier
Hipervisor.
 El estándar OVF adelantado por Dell, HP, IBM, Microsoft, VMware y Citrix. Permite desplegar máquinas virtuales
preconfiguradas independientemente del Hipervisor.
 El acuerdo Citrix-Microsoft. Permite garantizar que el Hipervisor de Microsoft o Citrix será soportado por una u otra
plataforma de gestión de entornos virtualizados.

Todos los expertos se plantean la siguiente cuestión:

¿Será posible crear entornos interoperables virtuales para no quedarse encerrado en una sola tecnología?

De momento, la respuesta es no. Las apuestas financieras de la virtualización son enormes para los próximos años, con
lo que es evidente que se firmarán acuerdos, que serán frágiles hasta que el mercado se estabilice.

3. El añadido de funcionalidades y el soporte de material

La subida espectacular de las máquinas conduce a los desarrolladores de software de virtualización a redoblar el ingenio.

Cuando se edite este libro, VMware vSphere 4 debería ser accesible para todos. Se incorporan muchas funcionalidades,
especialmente:

Página 137 de 146

  Vmsafe
 Vshield
 El módulo Fault tolerant
 Las vNetwork Distributed Switch

El soporte de hardware será incluido por defecto:

 255 GB de Ram por máquina virtual

 Hasta 64 CPU lógicas
 1 TB de Ram por servidor físico
 Soporte de muchos hardwares
 Soporte de muchos sistemas invitados

Para más información, puede visitar http://tinyurl.com/cxw782

(Imagen Copyright VMware)

4. Virtualización y multimedia
La multimedia y la virtualización no han sido de momento buenos amigos. Aunque se han hecho esfuerzos recientemente,
hay que constatar que, de momento es imposible, por ejemplo, jugar o ver un vídeo HD en una máquina virtual.

Esto deberá cambiar de aquí a algunos años.

La aceleración material a nivel de puestos de trabajo virtualizados es una idea que seduce. En la mayoría de empresas,
no es raro encontrar a empleados navegando por http://www.youtube.com o http://www.dailymotion.com u otro
proveedor de contenido digital. Otros tienen la costumbre de jugar a juegos en Flash o incluso utilizan sus puestos de
trabajo para desarrollar juegos, imágenes de síntesis o para retocar fotos (infografistas y otros…). Hasta ahora, la
virtualización no respondía a esta demanda. La adopción de la virtualización de puestos de trabajo se ha frenado por
tanto un poco.
Página 138 de 146
El hecho de que los empleados ya no puedan ver vídeos se percibe a veces como una ventaja…

Recientemente se han conocido algunos detalles, lo que demuestra que VMware trabaja sobre el tema. En primer lugar,
en el VMworld 2009 de Cannes, se realizó una demostración de un puesto de trabajo virtualizado; éste permitía usar
GoogleEarth sin ralentización ninguna. El protocolo PCoIP de la sociedad Teradici ha visto la luz y permite dotar de
funciones multimedia al puesto de trabajo virtualizado.

Corren rumores sobre la futura integración de PCoIP en la nueva versión de VMware View, la solución de virtualización
de puestos de trabajo de VMware. Esta solución sería totalmente software, aunque el añadido de tarjetas gráficas
especializadas sea una opción que permitiría ir aún más lejos.

Además, en las fases de Beta Test de Vsphere 4, hemos podido comprobar que, en las máquinas virtuales, se han añadido
opciones que conciernen a la tarjeta gráfica integrada. Veamos una captura de pantalla que muestra la diferencia entre
la versión 3.5 y 4 de VMware ESX.

La virtualización al alcance de las PYME

Aunque la virtualización reduzca los costes radicalmente, a menudo se considera reservada a las grandes empresas.
Muchas PYME pasan de largo de la virtualización, por el desconocimiento del mercado.

Existen muchas empresas creadas en los últimos años que proponen soluciones robustas y fiables que reducen los costes
de forma importante.

1. SYSTANCIA
Systancia es una empresa francesa que comercializa una solución equivalente a Citrix XenAPP. La solución se ha probado
y validado en nuestro laboratorio y es una auténtica alternativa a CITRIX.

Systancia tiene las siguientes ventajas:

 Solución mucho más ligera que sus competidoras;

 Precio de las licencias mucho más bajo;
 Soporte protocolario excelente;
 Gestión de impresión mucho más conseguida;
 Rendimientos a menudo superiores.

Systancia ya posee numerosas referencias en Francia. Es muy recomendable darle un vistazo a su solución para tener
una opinión propia.

2. Neocoretech
Neocoretech propone desde 2008 su solución NDV (Neocoretech Desktop Virtualisation) dedicada exclusivamente a la
virtualización de puestos de trabajo bajo Microsoft Windows o Linux.

Uno de los principales triunfos de esta solución es la simplicidad de su instalación y utilización. Es posible, con algunos
clics, desplegar centenares de PCs virtuales, completamente securizados tanto para el usuario como para el departamento

Página 139 de 146

 informático. El administrador puede actualizar en cualquier momento los PCs virtuales NDV de forma centralizada, asignar
más recursos físicos a grupos de usuarios y preparar, por ejemplo, salas de formación en unos segundos. Además, es
posible añadir servidores se virtualización en caliente sobre una infraestructura NDV existente, lo que representa una
auténtica flexibilidad en el dimensionamiento del parque de PCs virtuales.

La solución NDV permite un ahorro de almacenamiento importante, ofreciendo nativamente la Alta Disponibilidad en la
infraestructura, sin recurrir a una SAN y sin sobrecoste de licencias.

Para gestionar el conjunto, una consola intuitiva permite encargarse rápidamente de la solución.

Resultante de la investigación francesa, Neocoretech forma parte de las empresas que impulsan la virtualización a nivel
de PYME. Como prueba, muchos hospitales y organismos de formación han dado ya el paso. La solución NDV debería
seducir rápidamente al conjunto de los sectores de actividad con un posicionamiento tarifario muy atractivo.

El Cloud Computing

1. Definición
El Cloud Computing es un concepto relativamente reciente. Se basa en un espacio virtual, la nube, que concentra potentes
arquitecturas. Esta nube representa un conjunto de recursos que se puede utilizar, bajo demanda, por los usuarios. Esta
nube está repartida por todo el mundo, no tiene frontera y se relaciona gracias a Internet o a redes dedicadas.

Esta nube permite a los usuarios disponer de una potencia considerable modulable segun las necesidades de su profesión.

El Cloud Computing es la posibilidad de dispersar un Sistema de Información sobre infraestructuras de las que se ha
hecho cargo uno o varios prestatarios. La localización geográfica de estos recursos virtualmente ilimitados no importa en
absoluto.

Es posible hacer una comparación con el consumo eléctrico actual. Las sociedades especializadas ofrecen esta "Cloud"
del mismo modo que las eléctricas ofrecen su red, y la potencia de cálculo además del almacenamiento de información
consumido serían comparables al consumo eléctrico de los usuarios. Así, las empresas ya no necesitarían DSI (en
cualquier caso, sería el objetivo), ni una informática propia. Los puestos de trabajo se convertirían en simples terminales
ligeros que podrían mostrar un puesto de trabajo presente en un Cloud, mientras que los servidores serían simples
objetos, gestionados por lo que habría que llamar el "resto" de la DSI.

El Cloud Computing es resultado de modelos como el modo SaaS (Software As A Service) o el Grid Computing, que aún
no han demostrado todas sus posibilidades.

2. ¿Virtualización y Cloud Computing?

La virtualización va a convertirse en la piedra angular del Cloud Computing, por muchas razones:

 Para proponer la creación de máquinas virtuales en el Cloud, es necesario virtualizar.

 Las interfaces de gestión del Cloud deberán comunicarse con las herramientas de virtualización para automatizar
el conjunto.
 El Cloud debe permitir facturar únicamente lo que se consuma. Sin virtualización esto no sería en absoluto rentable
para las empresas que propusieran el Cloud Computing (compra de material muy concreto, obsolescencia,
consumo eléctrico, etc).
 La virtualización permitirá desplegar arquitecturas de alta disponibilidad. Con el principio del Cloud Computing, las
DSI serán muy exigentes sobre sus SLA. Teniéndolo todo externalizado, no aceptarán cortes o incidentes como
lo hacían antes.
 Para proponer todo tipo de sistemas, independientemente del hardware, es necesario pasar a la virtualización.

La virtualización permitirá llevar a cabo técnicamente este tipo de infraestructura. Sin embargo, el lado tecnológico sólo
es la punta visible del iceberg.

3. Modo de facturación
El modo de facturación del Cloud Computing es uno de los principales frenos para su adopción. Aunque el Cloud
Computing debería hacer bajar los costes, realmente no hay nada probado por el momento. Las simulaciones que se
están llevando a cabo actualmente no tienen en cuenta la mayoría de los elementos.

De hecho, hoy en día muchas empresa han escogido externalizar su Sistema de Información. Entre éstas, hay muchas
que han decidido dar marcha atrás. ¿Por qué? Simplemente porque los costes ocultos son considerables. Para revisarlos
necesitaríamos escribir otro libro… De algún modo, las DSI se han vuelto muy prudentes tratándose de la externalización.

Página 140 de 146

 El coste real del Cloud Computing es difícil de calcular. La mayoría de los actores facturan según el consumo de los cuatro
elementos siguientes:

RAM

La RAM consumida se multiplica por el número de horas que esta misma RAM se ha utilizado.

Transferencia de datos

El número de datos (en Mbps, Gbps) que salen o entran en la nube.

Almacenamiento

El espacio de almacenamiento utilizado al mes.

Licencias

Las licencias necesarias para la empresa que desea utilizar el Cloud.

Existen variantes donde el número de ciclos de CPU consumida también se factura.

Tomemos un ejemplo concreto:

Una empresa quiere tener un servidor que tenga 512 MB de Ram. Cada mes, se consumen 338 horas.

Coste unitario de 1 GB de Ram: 0,20 € por hora.

El servidor tendrá un coste mensual de 0,5 * 338 * 0,20 = 33.8 €

Por otro lado, el servidor almacena 50 GB de datos.

Coste unitario de 1 GB de datos = 0,15 € al mes.

Por tanto, 0,15 * 50 = 7,5 €

El servidor ha recibido 8 GB de datos (lo que representa, por ejemplo, todas las conexiones de los clientes en ese mes).

Coste unitario: 1 Gb = 0,5 €

Por tanto, 8 * 0,5 = 4 €

En último lugar, el servidor contiene una licencia de MSSQL Workgroup edition, que se factura a 54 € al mes.

Así, en total, la empresa gastará 99.3 € al mes para satisfacer a sus clientes.

Es difícil de calcular cuánto costaría esto mismo en modo de alojamiento clásico; todo es cuestión de anticipación. El
trabajo para las DSI que deseen abrirse al modo del Cloud Computing, consistirá en calcular a largo plazo el ROI de este
enfoque.

4. Ventajas/inconvenientes
Aunque sobrepase ampliamente el marco de este libro, veamos un breve resumen de las ventajas e inconvenientes que
representa a día de hoy el Cloud Computing.

Ventajas

 En teoría, permite reducir los costes (reducción de efectivos, consumo eléctrico, coste de material, etc).
 Permite evitar una gran cantidad de fallos.
 Permite prever arquitecturas altamente disponibles.
Página 141 de 146
  Favorece la adopción de SLA y la contractualización de compromisos sobre la disponibilidad de datos y de sistemas.
 Permite anticipar la escalabilidad y los problemas de usuarios.

Inconvenientes

 Dominio de costes difícilmente controlables.

 Puede convertirse en poco o nada rentable (sobreconsumo puntual, parámetros imprevistos, costes de licencias
excesivos, etc).
 Poco maduro tecnológicamente (la mayoría de Clouds actuales tienen cortes generales que tienen consecuencias
en todos los clientes). Ejemplo: http://tinyurl.com/mpqta4
 Es muy dependiente de la red. Atención al aumento de "canalizaciones" necesarias para seguir la evolución.
 Un fallo puede convertirse rápidamente en catastrófico.
 Se critica la seguridad en todos los niveles (confidencialidad, integridad, trazabilidad, etc).
 Nada indica que los precios permanecerán idénticos en los próximos años.

5. Los actores de mercado del Cloud Computing

Es interesante constatar que la mayoría de gigantes de la informática proponen sus propios sistemas de Cloud Computing.
IBM, Microsoft y Google han anunciado que propondrán una oferta de Cloud Computing que se intensificará en los
próximos años.

Veamos por el momento los que han llamado nuestra atención:

 Microsoft Azure
 Amazon Elastic Compute Cloud (Amazon EC2)
 IBM Blue Cloud
 Google App Engine
 GoGrid

El mercado del Cloud Computing representa alrededor de 56 millones de dólares en 2009 según Gartner.

GreenIT

1. Definición
El Green Computing o GreenIT es un concepto basado puramente en el marketing. Estos últimos años, la ecología se ha
visto impulsada por los diferentes medios de comunicación del planeta (televisión, internet, radio, etc). Ecología e
informática han sido enemigos durante muchos años. La informática consume cada vez más electricidad, genera
centenares de millones de toneladas de deshechos al año (pcs y servidores usados, cables, pantallas, etc), y tiene un
lugar considerable tanto para el particular como para la empresa. Durante estos últimos años, la tecnología ha permitido
reducir considerablemente la huella ecológica de los Sistemas de Información.

2. Algunas cifras
Consideramos que las tecnologías de la información consumen entre un 10 y un 15% de la electricidad en España y son
responsables de alrededor del 5% de las emisiones de CO2.

La electricidad representa alrededor de un 10% del presupuesto de la DSI.

El consumo eléctrico de los PCs aumenta un 5% cada año.

El consumo eléctrico de los Datacenters aumentó un 15% en 2008.

La factura de electricidad de los ordenadores (a lo largo de su vida) es mucho mayor que el coste de compra.

Entre 2000 y 2005, el consumo eléctrico de los Datacenters aumentó más del doble en el mundo. En Estados Unidos,
está probado que durante 2010 será necesario construir 10 nuevas centrales para los sistemas de información.

Los Datacenters desperdician el 50% de su electricidad (ver http://tinyurl.com/lzbrsb).

El uso medio de un servidor no sobrepasa el 6%.

Como ejemplo, dos peticiones a Google consumen tanta energía como para hacer hervir el agua de una olla.

Página 142 de 146

 Otro ejemplo realmente impresionante: el consumo de energía necesario para mantener con vida un avatar en Second
Life durante un año sería superior al de un brasileño medio, ¡unos 1.752 kilowatios hora!

La industria de la informática y las comunicaciones genera alrededor de un 2% de las emisiones totales de dióxido de
carbono, casi tanto gas efecto invernadero como el conjunto de todas las compañías aéreas del mundo.

Entre 2001 y 2006, la factura de electricidad aumentó un 70% debido a la liberalización del mercado.

El 26% de los crashs informáticos se deben a problemas de electricidad.

La agencia americana de información sobre la energía (EIA) estima que el consumo mundial de energía podría crecer un
57% de aquí a 2030.

Un PC encendido inútilmente cuesta de 19 a 30 euros al año.

La huella de carbón de la descarga de un programa o de una obra digital sería unas 9 veces menor que la de un DVD. Una
cifra totalmente olvidada en el debate sobre la ley Hadopi.

3. Virtualización y GreenIT
La virtualización está en camino de convertirse en el mejor amigo del GreenIT, por muchas razones:

 La virtualización reduce considerablemente la necesidad de servidores y puestos de trabajo.

 La virtualización permite concentrar varios sistemas en un solo servidor. La factura eléctrica se reduce bastante.
 VMware ha introducido mecanismos que permiten gestionar dinámicamente las máquinas virtuales y apagarlas si
no se utilizan. (VMware DPM: Distributed Power Management).
 La virtualización permite desplegar terminales ligeros que consumen muy poco comparado con un puesto de
trabajo clásico.

Veamos igualmente algunas cifras claves que permitan hacernos una idea más precisa:

 Consolidando 10 máquinas físicas en un mismo servidor, las tecnologías de virtualización reducen la factura
eléctrica de un 80 a un 90% aproximadamente.
 De media, cada servidor físico virtualizado representa un ahorro anual de 7.000 (kWh), que equivale a 4 toneladas
de CO2.
 En diez años, VMware estima haber permitido ahorrar 39 mil millones de kWh, que equivalen a 4 mil millones de
euros.
 La virtualización de puestos de trabajo permite reducir por 3 la factura de electricidad en comparación a puestos
de trabajo clásicos.
 Es posible calcular de forma relativamente fácil la reducción de su consumo eléctrico al pasar a la virtualización.

Página 143 de 146

4. Experiencia de GreenIT
Al contrario que el resto de testimonios en este libro, el ejemplo que veremos a continuación forma parte del dominio
público.

El autor precisa que este ejemplo proviene de personas de vExpert (VMware Expert) y que el grupo AGRICA es conocido
por su trabajo en la virtualización.

Agrica es uno de los principales interlocutores del mundo agrícola en materia de pensión complementaria, ahorro y
prevención sanitaria.

Después de haber virtualizado el 90% de sus servidores en 2007 para desplegar un sistema de PRD, Agrica decidió en
2008 virtualizar los puestos de trabajo con las herramientas de VMware ESX 3.5. Se desplegaron terminales tipo Wyse
para reducir costes y contribuir a la conducta interna de responsabilidad medioambiental.

Los puestos de trabajo convencionales de Agrica consumían alrededor de 230 kWh al año.

Los clientes ligeros desplegados por Agrica necesitan por su parte alrededor de 25 kWh al año + 87 kWh al año por
máquina virtual del lado del servidor. El ahorro energético es, por tanto, del orden de 120 kWh al año.

La factura de electricidad de los puestos de trabajo se redujo a la mitad.

El interés del estudio consiste en incluir en el consumo eléctrico el consumo del servidor dedicado a los puestos de trabajo
virtuales. La mayoría de los fabricantes de terminales ligeros informan hoy en día sólo sobre el consumo del terminal. La
tasa de reducción está por tanto lejos de los factores 8 ó 10 que anuncian…

Sin embargo, hay que tener en cuenta que los puestos de trabajo de Agrica ya consumían muy poca energía. Se considera
que, globalmente, un puesto de trabajo consume entre 400 y 500 kWh al año.

5. ¿Qué futuro para el GreenIT?

La virtualización va a contribuir en gran parte a una informática más verde. Otros actores contribuyen a esta tendencia.

 Intel y AMD lanzan muchos proyectos para reducir el consumo eléctrico de sus procesadores.
 Los terminales ligeros también consumen cada vez menos y serán cada vez más miniaturizados.
 La norma RoHS se adopta masivamente.
 La Environmental Protection Agency ha publicado recientemente la norma Energy Star for Servers 1.0.
 Los distintos gobiernos deberían establecer ayudas para todos los que contribuyan a un desarrollo sostenible.

Página 144 de 146

 El principal problema del GreenIT consiste en probar que la ecología también permite ahorrar. Hoy en día, el principal
freno para la adopción de coches ecológicos es el precio. Si mañana, gracias a subvenciones fiscales y ayudas diversas,
el precio de estos coches fuera inferior al de los coches clásicos (que sería el caso de la ecotasa, etc), la adopción sería
mucho mayor. En informática, la ventaja es doble. Es posible ahorrar a corto y medio plazo, e igualmente en la compra.

Habrá por tanto que convencer a las DSI y a los compradores con argumentos fuertes y feedbacksconcretos. Las ayudas
gubernamentales y las iniciativas europeas podrían acelerar este fenómeno.

Primicia

1. VMware vShield
Es difícil terminar este libro sin haber hablado de vShield, la nueva herramienta de VMware que permite implementar
una política de seguridad inter VM.

VMware vShield proviene de la compra de la sociedad Bluelane (como prueba, encontramos el nombre Bluelane por
defecto en las máquinas virtuales vShield).

Hemos podido probar en primicia vShield para conocer lo que aportará. Aunque las primeras impresiones nos parecieron
negativas, vShield constituye una auténtica oportunidad de implementar una infraestructura securizada, administrable
desde un punto de vista centralizado.

El principio es sencillo: VMware vShield permite implantar una política de filtraje L2/L3/L4 entre las máquinas virtuales.
Aunque el producto parece de momento muy restringido y difícilmente configurable, es evidente que va a evolucionar y
que se convertirá en un pilar de la seguridad de las empresas.

La integración con las herramientas de terceros queda por verificar, especialmente la detección de intrusiones, el
antivirus, etc. Sea como sea, la iniciativa merece resaltarse.

2. Cisco Nexus 1000v

El Nexus 1000v permitirá resolver todos los problemas relativos a la red que se han encontrado hasta ahora. Hoy en día,
los administradores de red no pueden tener una visión de las máquinas virtuales desplegadas, ya que están bloqueados
a nivel del Switch virtual. El Nexus 1000v permitirá llegar mucho más lejos.

Las máquinas virtuales estarán conectadas a un "Distributed Virtual Switch", que tendrá todas las propiedades de un
switch clásico.

No hemos probado todas las funcionalidades ni rendimiento del Nexus1000v. Sin embargo, el principio, en sí, es
revolucionario. Además, VMware se ha abierto tanto a Cisco, como a sus asociados. Todos los fabricantes de hardware
de red van a aportar una respuesta en los próximos meses.

Página 145 de 146

 Quedan muchas pruebas que realizar y problemas que resolver. El uso del Nexus1000v a gran escala no será inmediato.
Sin embargo, es bastante probable que este principio se adopte próximamente de forma masiva en los Datacenters
virtualizados.

Página 146 de 146