Implementacion de una infraestructura en VMware 5.5

Implementación de
una infraestructura
en VMware 5.5
Xavier Montolio
Josep Mª Vellido

VIRTUALIZACIÓN ASIX2
Índice
Título pág
1. Introducción ........................................................................................... 1
1.1 Virtualización ....................................................................................... 2
1.2 Hipervisor Bare-Metal.............................................................................. 6
1.3 Tipos de virtualización ........................................................................... 11
2. ESXi .................................................................................................... 18
3. vCenter Server........................................................................................ 24
3.1 VMware vSphere ................................................................................... 28
3.2 vSphere Client Web ............................................................................... 43
4. Arquitectura del proyecto .......................................................................... 46
5. Almacenamiento compartido....................................................................... 49
6. vMotion ................................................................................................ 59
7. Storage vMotion ...................................................................................... 62
8. Cluster ................................................................................................. 67
8.1 HA ................................................................................................... 69
8.2 DRS .................................................................................................. 75
9. Storage DRS ........................................................................................... 85
10. Fault Tolerance.................................................................................... 90
11. Conclusión del Proyecto.........................................................................103
12. Webgrafía..........................................................................................105

1
1. Introducción
El proyecto realizado ha consistido en la Virtualización, los tipos de ésta y como trabajar en
un entorno capaz de administrar un Datacenter, con su Cluster, con sus hosts y sus máquinas
virtuales.
La característica principal ha sido la administración de máquinas virtuales en un entorno
capaz de agregarle funciones para mejorar el sistema de virtualización.
Nos decidimos en hacer este trabajo porque nos parecía un tema interesante y que podíamos
profundizar todavía más, ya que en Internet no hay mucha información sobre las nuevas
versiones que está utilizando VMware y ESXi con su virtualización. Como es un concepto nuevo
y con mejores capacidades y tecnologías, los usuarios normales no han desarrollado, todavía,
este tipo de proyectos. Y podemos decir que nosotros somos de los primeros usuarios que
investigan sobre algunas funciones recién salidas al mercado.
También supone una motivación especial debido a que nuestros estudios se basan en los
Sistemas y queríamos saber si nosotros mismos podíamos ir más allá.
El trabajo realizado ha sido pensado para un entorno empresarial. Es decir, aunque
seguramente las empresas necesitarían más recursos en cualquier situación, nosotros hemos
valorado e implementado funciones que muchas empresas utilizan para la mejora de la
virtualización, totalmente necesarias para dar una alta disponibilidad y redundancia al cliente
que alquila sus servidores.
En cuanto al método de trabajo, hemos necesitado del uso de 3 máquinas físicas con 8 GB de
RAM cada una y con un procesador Intel Core i3.
A la hora de buscar información, primero hemos encontrado la documentación y entendido
todas las funciones que realizaban nuestras implementaciones en el proyecto. Más tarde
hicimos la configuración necesaria en el programa y por último la prueba y/o testeo de estas
aplicaciones para comprobar si realmente era la función que queríamos, si podíamos ir un
paso más allá o si la configuración no era del todo correcta.
El proyecto también ha tenido alguna limitación, sobretodo en cuanto a Hardware de las
máquinas físicas. Aunque con 8 GB de RAM por PC y un procesador Intel Core i3, con unos
recursos mejores se podía haber realizado la práctica más cómodamente.
En algunas situaciones, al tener unas 3 o 4 máquinas virtuales, la CPU daba advertencias de
que podía llegar a su máximo.
También cabe destacar que no hemos trabajado con un entorno 100% real en cuanto a
virtualización. Ya que los Sistemas Operativos ESXi deben estar instalados en la misma
máquina y por falta de dichos recursos (básicamente 2 PCs limpios que no teníamos) no hemos
podido instalar esos Sistemas Operativos en la misma máquina.

2
En este caso hemos utilizado el programa VMware Workstation para hacer la simulación de
todos estos casos. Pero debe quedar claro, que esto no es la virtualización en la que se ha
basado el proyecto. Más adelante explicaremos los tipos de virtualización que hay y se
entenderá este proceso realizado.
La finalidad y/u objetivos de este proyecto ha sido analizar las características que aportan
VMware y la utilización de estos en un mundo laboral, así como diferenciar lo que hace una
virtualización totalmente física y real.
1.1 Virtualización
¿Qué es la virtualización? pues si seguimos la típica definición de Wikipedia, sería:
Es la creación -a través de software- de una versión virtual de algún recurso tecnológico,
como puede ser una plataforma de hardware, un sistema operativo, un dispositivo de
almacenamiento u otros recursos de red.
Es decir, que la virtualización utiliza la combinación de Hardware y Software para que un
recurso físico pueda funcionar con buen rendimiento.
La historia de la virtualización se remonta a los años 60-70. Ya que en los 60 ya podíamos
conocer el término "pseudo-máquina" y en los 70 ya tuvimos una empresa (IBM) que desarrolló
sistemas con soporte de virtualización.
Un componente llamado Virtual Machine Monitor (VMM) ejecutaba varias instancias de
sistemas operativos sobre el hardware real. Aunque fue una idea muy popular en esos años,
en los 80 no gustó tanto, ya que el hardware era barato, se necesitaban PCs y Sistemas
Operativos multiusuarios que carecerían en aquellas épocas.
Pero la idea volvió a tener sentido en los 90, esto concuerda con la fundación de VMware y el
lanzamiento de su primer producto (VMware Workstation). Más tarde también se inventarían
versiones como Xen y otras tecnologías.
En la virtualización podemos encontrar dos conceptos muy importantes:
- Anfitrión/Host. Es el sistema operativo que ejecuta el software de virtualización. Este S.O.
anfitrión controla el hardware real.
- Invitado/Guest. Es el sistema operativo virtualizado. Puede haber varios S.O en un mismo
host. Estos invitados no pueden interferir ni entre ellos, ni con el anfitrión.

3
Gráficamente este sería el ejemplo explicado:
Varias máquinas de sistemas operativos diferentes en un mismo servidor.
Al software de virtualización se le llama: Hipervisor.
Éste se encarga de ejecutar como parte del sistema host o es el mismo host.
La instancia del hardware virtualizado se la conoce como Máquina Virtual. Y los sistemas
operativos se ejecutan dentro de una máquina virtual.
Las características de un Hipervisor:
- Permiten que diferentes SSOO, tareas y configuraciones de software coexistan en una
misma máquina física.
- Abstraen los recursos físicos de la máquina anfitriona para las distintas máquinas
virtuales.
- Garantizan un nivel de aislamiento entre los invitados.
- Proporcionan una interfaz única para el hardware.
Existen dos tipos de Hipervisores:

4
 Tipo 1. Llamado también "nativo" o "bare-metal". El hipervisor se ejecuta
directamente sobre el hardware y gestiona los Sistemas Operativos invitados.
- Al sistema operativo se le llama Dominio de control y se ejecuta sobre el hipervisor.
- Los invitados son Dominios Lógicos.
- Algunos ejemplos como: Xen, Citrix, XenServer, KVM, VMware ESX/ESXi, Microsoft Hyper-V.
 Tipo 2. Conocido como "hosted". El hipervisor se ejecuta en el entorno de un sistema
operativo. Es decir, representa una capa software que se ejecuta sobre el sistema
operativo anfitrión.
- Ejemplos: VMware Workstation, VMware Server, VirtualBox, QEMU, Microsoft Virtual PC,
Oracle VM VirtualBox.
.

5
¿Qué ventajas aporta la virtualización?
- Reutilización de hardware existente (para utilizar software más moderno).
- Optimizar el aprovechamiento de todos los recursos de hardware.
- Rápida incorporación de nuevos recursos para los servidores virtualizados.
- Reducción de costes y consumo.
- Administración global centralizada y simplificada.
- Permite gestionar un CPD como una agrupación para toda la capacidad de recursos
(procesador, memoria, red, almacenamiento) dentro de una infraestructura.
- Mejora en los procesos de clonación y copia de sistemas: Mayor facilidad para la
creación de entornos de test que permiten poner en marcha nuevas aplicaciones sin
impactar a la producción, agilizando el proceso de las pruebas.
- Aislamiento: un fallo general de sistema de una máquina virtual no afecta al resto de
máquinas virtuales.
- Reduce los tiempos de parada.
- Migración en caliente de máquinas virtuales (sin pérdida de servicio) de un servidor
físico a otro, eliminando la necesidad de paradas planificadas por mantenimiento de
los servidores físicos.
- Balanceo dinámico de máquinas virtuales entre los servidores físicos.

6
1.2 Hipervisor Bare-Metal
Como hemos comentado anteriormente. El Hipervisor que utilizaremos será el de “Tipo 1”
que también es llamado “Bare-Metal” o “nativo”. Hay que tener en cuenta que este tipo de
virtualización tiene el Hipervisor después del Hardware real. No hay un sistema operativo, ya
que él mismo es el Sistema operativo.
En casos como VMware Workstation, Virtual Box y otras plataformas con máquinas virtuales
son del tipo 2.
La virtualización Bare-Metal es mucho más útil. Primero de todo porque ganamos en recursos
y dedicamos la máquina exquisitamente dicho Hipervisor. Si utilizaremos una máquina virtual
en VMware ya tendríamos “el lastre” de tener el S.O iniciado.
Para entender mejor como funciona, tenemos este gráfico:
Como hemos comentado. Primero está el sistema físico, es decir, el hardware, la máquina
real en sí. En dicha máquina instalamos ya de por si el Hipervisor (hay muchos tipos) y ya
dentro de éste estarán las demás máquinas virtuales instaladas.
Un hipervisor bare-metal no funciona bajo un sistema operativo instalado sino que tiene
acceso directo sobre los recursos hardware. Esto significa que obtendremos un
mejor rendimiento, escalabilidad y estabilidad. Por contra, en este tipo de tecnología de
virtualización el hardware soportado es más limitado ya que normalmente es construido con
un conjunto limitado de drivers.
La tecnología bare-metal se adapta mejor a centros de datos empresariales. Esto es porque
dispone de características avanzadas como la administración de recursos, alta disponibilidad,
seguridad y administración centralizada de la infraestructura de virtualización.

7
El mercado ofrece varios tipos de Hipervisores a alto nivel. Los más importantes y conocidos
son:
 VMware ESX y ESXi
VMware es el fabricante con la tecnología de virtualización más madura del mercado. Ofrece
características avanzadas y escalabilidad. En contra tiene los altos costes de licenciamiento.
 Microsoft Hyper-V
Desde su lanzamiento, Hyper-V se ha convertido en un serio competidor de VMware ESX
(ESXi). En contra tiene que no dispone de ciertas características avanzadas disponibles en los
productos de VMware. De todos modos, como no podía ser de otra forma, se integra
perfectamente con los productos Windows. Para aquellos que no necesitan funcionalidades
avanzadas, puede ser un producto perfecto para llevar a cabo su proyecto de virtualización.
 Citrix XenServer
Citrix también tiene una plataforma de virtualización basada en el proyecto Open SourceXen.
El hipervisor es gratis, pero de igual modo a como pasa con VMwareESXi, no dispone de
características avanzadas. Éstas se obtienen a partir de licencias que ofrecen gestión
avanzada, automatización y alta disponibilidad.
 Oracle VM
De igual modo a Citrix, Oracle ha desarrollado su hipervisor a partir del proyecto Xen. El
producto de Oracle no presenta funcionalidades avanzadas que podemos encontrar en otros
hipervisoresbare-metal. Además su ciclo de desarrollo es lento y limitado, por lo que no
puede competir con los productos de VMware, Microsoft o Citrix. Sin embargo, como es
lógico, es un producto que se adapta perfectamente a los productos de Oracle.

8
En la siguiente tabla comparativa mostraremos las funciones de los 3 productos más potentes
de mercado en cuanto al mundo de la virtualización. Todos aportan un gran nivel de
características.
Funciones VMware ESX Microsoft Hyper-V Citrix XenServer
Migración de
máquinas virtuales
Sí Sí Sí
Migración
automática
Sí Sí No
Power Management Sí Sí No
Migración de
almacenamiento
Sí Sí Sí
Tamaño del Cluster 32 hosts y 4000 VMs 64 hosts y 8000 VsM 16 hosts
Fault Tolerance Sí No No
High Availability Sí Sí No
App HA Sí Sí No
Replicación Sí Sí Sí
Copia de Seguridad
integrada
Sí Sí No
Compatibilidad
Hardware
Alta compatibilidad
general
Alta compatibilidad
con Windows
Algo limitada
Líder en el mercado 1 2 3
Precio anual 3.500$ 6.100$ 500$

9
Analizando la tabla comparativa, los tres son capaces de administrar un Datacenter con las
opciones básicas.
La migración de máquinas virtuales es algo fundamental y que cualquier empresa tendrá dicha
opción. Así como la migración del almacenamiento.
En cuanto a la migración automática, llamada DRS en VMware ESXi o Gestión de Memoria en
Hyper-V, podemos apreciar como Citrix no dispone de esa función. Si quieres dar un paso
más, necesitarás esta función, capaz de coordinar los recursos de los hosts y equilibrar la
carga entre ellos. En cuanto a optimización y consumo de energía es muy útil.
"Power Management" va ligada con la migración automática. Ya que utiliza también la
administración de recursos para reducir los propios recursos físicos y balancear los hosts.
Depende de la función de cada producto, pero es capaz de bajar un 20% la energía de un host.
Si hablamos de capacidad y el tamaño que puede adquirir un cluster, sin duda Hyper-V es el
que menos límites pone. 64 hosts y 8000 máquinas virtuales dentro de un Cluster, la mitad
puede llegar a almacenar el ESXi con 32 hosts y 4000 máquinas. Citrix se queda bastante atrás
con solo 16 hosts por cluster.
Una función que en estos momentos solo puede conseguirse en ESXi es Fault Tolerance.
Hyper-V no cuenta con ella y es una característica que permite una alta disponibilidad
bastante importante. Si un host se cae, y la máquina que está hospeda en dicho host, gracias
a la función Fault Tolerance (siempre que esté habilitada, claro) será capaz de migrarse a un
segundo host. Lo más importante, sin duda, es la NO pérdida de actividad. Es decir, sin
downtime. La opción HA con vMotion si tiene ese parón mientras migra las páginas. Fault
Tolerance evita la inactividad.
La opción App HA es una opción bastante avanzada, capaz de restaurar objetos y funciones en
mal estado. Como es a un nivel importante, para obtener dicha función, es necesario pagar un
poco más u obtener funciones más "Plus".

10
En cuanto a replicación, todos pueden adquirirla. Y en cuanto
Copia de Seguridad integrada, con Citrix no viene integrada, pero también puedes adquirla.
La compatibilidad del Hardware es un tema que administra muy bien ESXi. Es capaz de
integrarse con muchos componentes y versiones distintas. Todo lo contrario que Windows,
que aunque su nivel es muy alto, solo se adecua bien con componentes propios de Windows, si
se utilizan otras versiones puede dar fallos o falta de compatibilidad. Citrix es la que más
limitación tiene y no llega al nivel de los dos anteriores.
En conclusión, el líder del mercado en estos momentos es ESXi, pero Hyper-V está muy cerca
y es una opción bastante fiable y capaz de darle un gran rendimiento a todas las funciones
para administrar un Datacenter.
En tercer lugar situaríamos a Citrix, que aunque no es mala opción, de las "3 grandes" es la
que menos posibilidades te da. Pero sin duda es una mejor alternativa que Oracle VM, Virtual
Bridges, IBM (PowerVM 2.2), Red Hat (RHEV 3.3) que están por debajo de los ya mencionados.
El precio es relativo, porque hay muchas versiones distintas de cada producto. En este caso
hemos tenido en cuenta los precios anuales con las opciones indicadas y las que vienen por
defecto.

11
1.3 Tipos de virtualización
La virtualización es muy extensa y nos podemos encontrar muchos tipos, nosotros nos
centraremos en los principales, ya que hay muchas formas de catalogar o ver la
virtualización. Algunas personas extienden los tipos en más y otros lo hacen de forma más
comprimida y organizada.
Pero generalmente podemos encontrar estos dos tipos y dentro de ellas subtipos capaces de
hacer virtualizaciones específicas y basadas en algo en concreto.
Virtualización de recursos: esta permite agrupar varios dispositivos para que sean vistos
como uno solo, o al revés, dividir un recurso en múltiples recursos independientes.
Generalmente se aplica a medios de almacenamiento. También existe una forma de
virtualización de recursos muy popular que no es sino las redes privadas virtuales o VPN,
abstracción que permite a un PC conectarse a una red corporativa a través de la Internet
como si estuviera en la misma sede física de la compañía.
Involucra la simulación de recursos básicamente. Sean volúmenes de almacenamiento,
espacios de nombres o recursos de red.
Por ejemplo:
 Discos RAID y gestores de volúmenes (como Linux LVM).
 Virtualización de almacenamiento como SAN (Storage Area Network).
 Redes privadas virtuales (VPN).
 Sistemas de multiprocesador y multinúcleo.
 Clusters, grid computing, cloud computing.
Las más conocidas y utilizadas:
- Virtualización de almacenamiento.
Es un tipo de virtualización, en donde se unen múltiples dispositivos de almacenamiento en
red, en lo que aparenta ser una única unidad de almacenamiento.
La virtualización de almacenamiento es utilizada en redes de área de almacenamiento, una
subred de alta velocidad que comparte dispositivos de almacenamiento, y realiza tareas de
almacenamiento, respaldo y recuperación de datos de forma más fácil y rápida.
La virtualización de almacenamiento es generalmente implementada vía aplicaciones de
software, hardware y redes.

12
Los sistemas de almacenamiento pueden proveer almacenamiento accedido por bloque o
almacenamiento accedido por fichero. El acceso por bloque generalmente es entregado por
canal de fibra, SAS, FICON u otros protocolos. En tanto el acceso por fichero es generalmente
proviso usando protocolos NFS y CIFS.
Las principales ventajas que tiene son:
- Costes reducidos. Mejora la eficiencia de almacenaje para recortar los gastos de
administración, refrigeración y potencia malgastados en recursos infrautilizados
- Gestión simplificada. Consolida diversos sistemas de almacenamiento en una única fuente
para reducir los gastos administrativos. Facilita la planificación de la capacidad y automatiza
la asignación de capacidad con el aprovisionamiento ajustado.
- Flexibilidad operativa. Posibilita la ampliación del almacenamiento a demanda para
satisfacer de forma dinámica las necesidades cambiantes.
- Disponibilidad aumentada. Consigue escalabilidad sin interrupciones y equilibrado
automático de la carga para minimizar los periodos de inactividad planificados.
Ejemplos:
o LVM en Linux.
o ZFS en Open Solaris.
o Sistemas de ficheros distribuidos (OCFS2, GlusterFS, GFS, etc.).
- Virtualización de Red.
La virtualización de redes es la reproducción completa en software de una red física. Las
redes virtuales cuentan con las mismas características y garantías que una red física. Sin
embargo, ofrecen los beneficios operativos y la independencia del hardware de la
virtualización: aprovisionamiento rápido, implementación sin interrupciones, mantenimiento
automatizado y compatibilidad con aplicaciones nuevas y heredadas.
La virtualización de redes expone los dispositivos y servicios de redes lógicos (puertos,
switches, routers, firewalls, equilibradores de carga, VPN, etc. lógicos) a las cargas de
trabajo conectadas. Las aplicaciones de la red virtual se ejecutan exactamente igual que en
una red física.
Puede crear una estructura de red altamente escalable que proporcione niveles más altos de
agilidad y eficiencia operativas, aprovisionamiento más rápido, solución de problemas y
clonación, con supervisión, calidad de servicio.
Ejemplos:
o Open vSwitch (Linux/FreeBSD).
o Crossbow (OpenSolaris)

13
- Otras:
Memoria Virtual: Se le permite agregar una memoria añadida y virtual. No contaremos
realmente con 1GB de RAM (por ejemplo), pero podrá ser utilizada y virtualizada.
Particiones de Bases de Datos: Es la división de un solo recurso (casi siempre grande),
como el espacio de disco o el ancho de banda de la red, en un número más pequeño y
con recursos del mismo tipo que son más fáciles de utilizar. Esto es muchas veces
llamado “zoning”, especialmente en almacenamiento de red.
Virtualización de plataforma: se trata de simular una máquina real (servidor o PC) con todos
sus componentes (los cuales no necesariamente son todos los de la máquina física) y prestarle
todos los recursos necesarios para su funcionamiento. En general, hay un software anfitrión
que es el que controla que las diferentes máquinas virtuales sean atendidas correctamente y
que está ubicado entre el hardware y las máquinas virtuales. Dentro de este esquema caben
la mayoría de las formas de virtualización más conocidas, incluidas la virtualización de
sistemas operativos, la virtualización de aplicaciones y la emulación de sistemas operativos.
- Virtualización de Emulación o simulación.
La máquina virtual simula un hardware completo, admitiendo un sistema operativo
“guest” sin modificar para una CPU completamente diferente. Este enfoque fue muy
utilizado para permitir la creación de software para nuevos procesadores antes de que
estuvieran físicamente disponibles. Por ejemplo Bochs, PearPC, Qemu sin aceleración,
y el emulador Hercules.
Ventajas: simular hardware que no está físicamente disponible.
Desventajas: bajo rendimiento y un alto conste de computación.

14
- Virtualización nativa o completa.
La máquina virtual simula un hardware suficiente para permitir un sistema operativo
invitado sin modificar (uno diseñado para la misma CPU) para correr de forma aislada.
Típicamente, muchas instancias pueden correr al mismo tiempo. Este enfoque fue el
pionero en 1966 con CP-40 y CP[-67]/CMS, predecesores de la familia de máquinas
virtuales de IBM. Algunos ejemplos: VMware Workstation, VMware Server, Parallels
Desktop, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro y z/VM.
Ventajas: flexibilidad y un alto rendimiento.
Desventajas: no se pueden emular otras arquitecturas.
- Virtualización parcial.
En la virtualización parcial, incluida la dirección de virtualización, la máquina virtual
simula múltiples instancias de gran parte de un entorno de hardware subyacente, en
especial los espacios de direcciones. Por lo general, esto significa que los sistemas
operativos completos no se pueden ejecutar en la máquina virtual (que sería el signo
de la virtualización completa) pero que muchas aplicaciones se puede ejecutar. Una
forma clave de virtualización parcial es la dirección de la virtualización del espacio,
en el que cada máquina virtual consiste en un espacio de direcciones independiente.
Esta capacidad requiere hardware reubicación dirección, y ha estado presente en los
ejemplos más prácticos de la virtualización parcial.
Ventajas: más fácil de implementar que la virtualización completa. Puede soportar
aplicaciones importantes y máquinas sólidas. Importante para compartir recursos
informáticos entre usuarios.
Desventajas: Falta de compatibilidades con versiones anteriores. Poco portable.

15
- Paravirtualización.
En paravirtualización, la máquina virtual no simula necesariamente de hardware, sino
que ofrece una API especial que sólo puede ser utilizado por la modificación de la
"huésped" OS. Para que esto sea posible, el "invitado" código fuente del sistema
operativo debe estar disponible. Si el código fuente está disponible, es suficiente para
reemplazar las instrucciones sensibles con las llamadas a VMM API "), a continuación,
volver a compilar el OS y el uso de los nuevos binarios.
Ventajas: mayor rendimiento que la virtualización nativa, no se necesita de ua CPU
con soporte para la virtualización.
Desventajas: hay que modificar el SO invitado.
- Virtualización a nivel de sistema operativo.
En la virtualización a nivel de sistema, un servidor físico se virtualiza a nivel del
sistema operativo, lo que permite múltiples servidores virtualizados aislado y seguro
para ejecutar en un único servidor físico. El "invitado" entornos OS comparten el
mismo sistema operativo que el sistema anfitrión (es decir, el mismo núcleo del
sistema operativo se utiliza para implementar los ambientes "invitados"). Las
aplicaciones que se ejecutan en un entorno "guest" dado lo ven como un sistema
autónomo. La aplicación pionera fue jaulas de FreeBSD, otros ejemplos incluyen
Solaris Containers, OpenVZ, Linux-VServer, LXC, AIX particiones de carga de trabajo,
Parallels Virtuozzo Containers y cuentas virtuales Icore.

16
Ventajas: Es muy rápida. La capa de virtualización es muy ligera. El rendimiento muy cercano
al nativo.
Desventajas: Muy difícil de implementar en un aislamiento completo. No se pueden virtualizar
diferentes Sistemas Operativos.
- Virtualización de aplicaciones.
Consiste en ejecutar una aplicación usando los recursos locales en una máquina virtual
apropiada. Estas aplicaciones virtuales se ejecutan en un "pequeño" entorno virtual
que le proporciona todos los componentes necesarios.
El entorno actúa como una capa entre la aplicación y el sistema operativo y elimina los
conflictos entre las aplicaciones y el sistema operativo. Por ejemplo: Java Virtual
Machine de Sun (JVM), Softricity, Thinstall, Altiris, Trigence..

17
- Virtualización asistida por hardware.
En la virtualización asistida por hardware, el hardware proporciona soporte
arquitectónico que facilita construir un monitor de máquina virtual y permite a los
sistemas operativos invitados que se ejecuten de forma aislada. En este tipo de
virtualización se cuenta con ayuda del procesador. Compañías como Intel o AMD
proporcionan dicha ayuda por hardware al software de virtualización. Esto permite a
los hipervisores un rendimiento mayor. Y aunque el procesador incluya la tecnología,
se debe activar en la BIOS.
Ejemplos de plataformas de virtualización adaptadas a dicho hardware incluyen Linux
KVM, VMware Workstation, VMware Fusion, Microsoft Hyper-V, Microsoft Virtual PC,
Xen, Parallels Desktop para Mac, Oracle VM Server para SPARC, VirtualBox y Parallels
Workstation
Ventajas: Mayor rendimiento. Fácil de implementar.
- Otras:
- Virtualización de bibliotecas: Wine (API Win32). Permite la ejecución nativa
de aplicaciones Windows en plataformas de Linux, FreeBSD o Solaris.
- Virtualización de escritorio: Virtual Desktop Infrastructure (VDI) consiste
básicamente en implementar el escritorio como servicio. Permite hospedar un
SO de escritorio dentro de una máquina virtual. Ejemplos: VDI, VMware View,
Citrix, etc.

18
2. ESXi
La definición exacta de ESXi es:
VMware ESXi es una plataforma de virtualización a nivel de centro de datos producido por
VMware, Inc.. Es el componente de su producto VMware Infraestructure que se encuentra al
nivel inferior de la capa de virtualización, el hipervisor, aunque posee herramientas y
servicios de gestión autónomos e independientes.
Está compuesto de un sistema operativo autónomo que proporciona el entorno de gestión,
administración y ejecución al software hipervisor, y los servicios y servidores que permiten la
interacción con el software de gestión y administración y las máquinas virtuales.
Como hemos comentado más arriba, ESX es un hipervisor de tipo Bare Metal. Trabaja en el
mismo núcleo del sistema operativo, así que evita esa carga añadida.
ESX está basado en Linux, en la distribución de Red Hat Enterprise, pero modificado
específicamente para la ejecución del hipervisor y los componentes que virtualiza VMware.
El arranque de la máquina anfitriona se produce a través de la ejecución de un núcleo Linux
el cual proporciona servicios de consola y hardware
En colaboración con el hipervisor funcionando en modo "Supervisor". A partir de la versión
vSphere (versión 4.0), el hipervisor aplica los teoremas de la paravirtualización y sustituye al
núcleo Linux por sus propias interfaces y pasando a ejecutar el entorno operativo como una
máquina virtual.
El vmkernel está programado y configurado siguiendo la arquitectura de microkernel,6 y tiene
las siguientes interfaces con el exterior:
 Hardware
 Sistema invitado
 Consola de servicio (Console OS, ServiceConsole)
Características:
 Fiabilidad y seguridad - La arquitectura de ESX en versiones anteriores a vSphere 5.0
se basó en una clase de servicio basados en Linux para el servicio y la integración de
socios basada en agentes. En el nuevo sistema operativo arquitectura ESXi
independiente, la funcionalidad de gestión necesaria ha sido
implementadoadirectamente en el núcleo VMkernel.

19
 Optimización - La nueva arquitectura ESXi tiene muchos menos elementos de
configuración, lo que simplifica enormemente el despliegue y la configuración y lo que
es más fácil mantener la coherencia.
 Reducir los gastos generales de gestión - El socio modelo de integración basado en la
API de la arquitectura ESXi elimina la necesidad de instalar y administrar agentes de
administración de terceros. Puede automatizar tareas rutinarias mediante el
aprovechamiento de la línea de entornos de scripts de comandos remotos como vCLI o
PowerCLI.
 Simplificación de Hypervisor, parches y actualización - Debido a su pequeño tamaño
y los componentes limitados, la arquitectura ESXi requiere muchos menos parches que
las primeras versiones, acortando las ventanas de servicio y la reducción de las
vulnerabilidades de seguridad. Durante su vida útil, la arquitectura ESXi requiere
aproximadamente 10 veces menos parches que el hipervisor ESX.
¿Cómo trabajan ESX & ESXi?
Como hemos comentado, el trabajo de un Hipervisor como este, es la instalación directa en el
servidor de Hardware. Se inserta una capa de virtualización robusta entre el propio hardware
y el sistema operativo ESX/ESXi, particionando un servidor físico en múltiples hosts y
máquinas virutales, que se puedej ejecutar en cualquier situación, en caso de caídas.
Cada máquina virtual representa un sistema completo de procesadores, memoria, creación de
redes, almacenamiento, BIOS, aplicaciones de software, etc.
Las máquinas virtuales están completamente aisladas una de otras por la capa de
virtualización, lo que impide cualquier error o accidente de configuración que pueda afectar
a las demás.
Una de las grandes ventajas es la compartación de recursos de los servidores físicos entre
varias máquinas virtuales, aumenta la utilización del hardware y disminuye los costos en
cuanto a capital se supone.
Contar con una arquitectura Bare-Metal proporciona un control total sobre el servidor, los
recursos asignados a cada máquina virtual y prevé un rendimiento de la máquina casi nativo,
de una clase empresarial y con una escalabilidad importante.
La alta disponibilidad integrada, más la gestión y seguridad de los propio recursos y
características nos ofrece un nivel de servicio y software de aplicaciones al nivel máximo.

20
¿Qué diferencia hay entre ESX y ESXi?
ESX
 VMware y agentes de terceros se ejecutan en la clase de servicio.
 La mayor funcionalidad de gestión previsto por los agentes que se ejecutan en los CDS.
 Los usuarios inician sesión en COS con el fin de ejecutar los comandos para la
configuración y diagnóstico.
El kernel de virtualización (VMKernel) fue aumentado con una partición de gestión conocido
como el sistema operativo de la consola (COS o consola de servicio).
El propósito principal de los COS era proporcionar una interfaz de gestión en el huésped.
Varios agentes de administración de VMware se desplegaron en el COS, junto con otros
agentes de servicios de infraestructura (por ejemplo, servicio de nombres, servicio de tiempo,
registro, etc.) En esta arquitectura, muchos clientes despliegan otros agentes de terceros
para proporcionar una funcionalidad concreta, como el monitoreo de hardware y gestión del
sistema. Por otra parte, los usuarios administradores individuales conectados a la COS para
ejecutar comandos de diagnóstico y scripts de configuración.

21
ESXi
 Los agentes de VMware se ejecutan directamente en VMkernel.
 Los módulos de terceros autorizados también pueden funcionar en VMkernel. Estos
proporcionan una funcionalidad específica.
o El monitoreo de Hardware.
o Los controladores de hardware.
 Componentes de VMware y componentes de terceros actualizan de forma
independiente.
 El enfoque de "doble imagen" le permite volver a la imagen anterior si se desea.
 No se permite la ejecución de código arbitrario en el sistema.
En la nueva arquitectura de VMware vSphere ESXi, el COS ha eliminado y todos los agentes de
VMware ejecutarse directamente en el VMkernel.

22
Los servicios de infraestructura se proporcionan de forma nativa a través de módulos incluidos
con la VMkernel. Otros módulos de terceros autorizados, tales como controladores de
hardware y componentes de monitoreo de hardware, se pueden ejecutar en VMkernel
también. Sólo los módulos que han sido firmados digitalmente por VMware están permitidos
en el sistema, la creación de una arquitectura fuertemente bloqueada.
A continuación, una tabla que compara las características de la arquitectura ESX o con la de
ESXi.
Función ESX ESXi
Consola de servicio (COS) Sí No
CLI Admin / config COS + vCLI PowerCLI + vCLI
Solución de problemas avanzados COS ESXi Shell
Instalación automática Sí Sí
Arranque desde SAN Sí Sí
SNMP Sí Sí
Active Directory Integrado Integrado
Monitoreo del Hardware Sí Sí
Conectividad Puerto Serial Sí Sí
Jumbo Frames Sí Sí
Auto Deploy No Sí
Creación y gestión de la imagen No Sí
Syslog seguro No Sí
Firewall con interfaz Sí Sí
Como podemos apreciar, ESXi es una versión más básica. Ha sido capaz de reducir su tamaño
(a 150 MB hacia arriba) gracias a que los agentes corren directamente en el VMKernel.
Aun así, ofrece la misma funcionalidad y rendimiento que la versión ESX.

23
El nuevo ESXi (5.5) añade un nuevo paso hacia la seguridad y fiabilidad, ya que su código base
más pequeño representa "una superficie de ataque" más pequeña con menos código y por
ende, más pequeño para parchear y corregir errores.
Sin duda estamos delante de un producto pensado en la simplicidad, con menús y
configuraciones automáticas que hacen que sea una forma muy fácil de trabajar con el tema
de la virtualización.
La mayor diferencia es que ESX depende de un sistema operativo Linux operativo en el propio
sistema, el llamado "Consola de servicio" que realiza gestiones como la ejecución de scripts,
la instalación de otros agentes para el control del hardware, copias de seguridad u otros
sistemas.
La consola se elimina en ESXi, por lo tanto, reduce esta "huella" y completa una tendencia en
cuanto a la funcionalidad de gestión de los comandos y yendo más hacia la administración
mediante una interfaz y una serie de normas.

24
3. vCenter Server
vCenter Server es una plataforma escalable y ampliable para una gestión proactiva de
virtualización, que posibilita la máxima visibilidad de la infraestructura virtual. vCenter
Server permite gestionar de forma centralizada los entornos VMware vSphere y simplifica las
tareas cotidianas mejorando notablemente el control administrativo de entorno.
¿Qué es VMware vCenter Server?
vCenter Server permite unificar la gestión de todos los hosts y máquinas virtuales del centro
de datos en una única consola. De este modo los administradores pueden mejorar el control,
simplificar las tareas cotidianas y el coste de la gestión de entornos.
¿Cómo funciona VMware vCenter Server?
vCenter Server incluye diversos componentes fundamentales que funcionan de manera
conjunta para proporcionar un centro escalable para la gestión de la virtualización. Los
servidores de gestión ofrecen puntos de gestión centrales a los hosts y máquinas virtuales con
información de inventario y rendimiento almacenada en una base de datos.
Para acceder a vCenter Server se puede utilizar vSphere Client en cualquier pc con Windows o
también con vSphere Web Client remotamente desde cualquier explorador web.
Los roles y permisos se replican entre los servidores de gestión, de esta forma se pueden
gestionar varias instancias de vCenter Server desde la misma consola.

25
Ventajas principales
 Rápido análisis y solución de problemas con máxima visibilidad de vSphere y de su
infraestructura subyacente.
 Mejora de la capacidad de respuesta al gestionar de forma proactiva el entorno de
vSphere con aprovisionamiento rápido, balanceo automatizado de la carga de
máquinas virtuales y ciclos de trabajo de la automatización.
 Implementación rápida de vCenter Server y gestión de vSphere mediante un dispositivo
virtual basado en Linux con vCenter Server Appliance.
 Escalabilidad a la medida de las necesidades de los entornos empresariales más
exigentes y gestión de hasta 10000 máquinas virtuales.
Características principales
 Control centralizado y visibilidad detallada
 Acceso remoto desde cualquier ubicación: con vSphere Web Client se pueden
gestionar las funciones de vSphere desde cualquier explorador en cualquier
parte.
 Supervisión en tiempo real de elementos virtuales dinámicos: vCenter Server
conoce perfectamente todos los elementos virtuales y los componentes físicos,
incluido el hardware de servidores, almacenamiento compartido y red.
Los activadores de eventos y alarmas facilitan la supervisión del entorno como
el diagnóstico y la solución de los problemas. vCenter Server supervisa el
rendimiento y la disponibilidad de las máquinas virtuales y otros elementos
virtuales, como los pools de recursos con estadísticas y gráficos que se pueden
consultar en tiempo real.
 Activadores de alarmas personalizadas: vCenter Server puede generar alertas
y notificaciones automatizadas como desencadenar ciclos de trabajo
automatizados para solucionar y prevenir problemas
 Navegación simplificada y búsquedas de inventario: La función de búsqueda
global permite acceder al inventario completo de instancias de vCenter Server
que incluye máquinas virtuales, hosts, datastores y redes.

26
 Gestión proactiva de los entornos vSphere
 Aprovisionamiento rápido y gestión de parches simplificada: Se pueden crear
máquinas virtuales o hosts en unos minutos mediante asistentes o plantillas con
el fin de minimizar los errores y las interrupciones del servicio.
 Asignación dinámica de recursos para garantizar los SLA: vCenter Server
supervisa continuamente la utilización de los pools de recursos con DRS, que
permite migrar de manera inteligente las máquinas virtuales entre hosts sin
paradas y sin comprometer los acuerdos a nivel de servicio (SLA).
 Automatización de ciclos de trabajo: vCenter Server incluye VMware vCenter
Orchestrator que es un potente motor de organización que simplifica la
gestión. Se pueden automatizar más de 800 tareas utilizando ciclos de trabajo
predefinidos o bien organizar los ciclos de trabajo mediante una sencilla
interfaz con funciones de arrastrar y colocar.
 Disponibilidad de vCenter Server: Una consola de gestión muestra el estado
de los componentes de vCenter permitiendo identificar y corregir rápidamente
los problemas de la infraestructura.
 Escalabilidad y capacidad de ampliación
 Gestion a gran escala: vCenter Server es una solución de 64 bits que permite
gestionar los entornos más grandes. Una única instancia de vCenter Server
permite gestionar hasta 1000 hosts y 10000 máquinas virtuales.
 Arquitectura abierta: Las vCenter API y una extensión .NET permiten la
integración entre vCenter Server y otras herramientas, y admiten los
componentes personalizados para vSphereClient.
Requisitos hardware/software de Vcenter Server 5
 Hardware
 Procesador 2 CPUs 64bits 2.0GHz Intel o AMD x86
 Memoria: 4GB RAM
 Disco Duro 4GB
 Red: Adaptador Ethernet (1 Gigabyte)

27
 Software
 Windows XP Profesional 64-bit con SP2 y SP3
 Windows Server 2003 64-bit Standard Enterprise y Datacenter con SP1,SP2
 Windows Server 2008 64-bit Standard Enterprise y Datacenter con SP2
 Windows Server 2008 R2 64-bit
Novedades en la version 5.5
 Implementación simplificada. Un modelo de instalación única para los clientes de
todos los tamaños se ofrece ahora.
 Mejorada la integración de Microsoft Active Directory. La incorporación de soporte
nativo de Active Directory permite autenticación entre dominios con uno y confianzas
bidireccionales comunes en entornos multidominio.
 Arquitectura. Construido desde cero, esta arquitectura elimina el requisito de una
base de datos y ahora ofrece una solución de autenticación de varios maestros con la
replicación y soporte para múltiples arrendatarios incorporado.

28
3.1 VMware vSphere
¿Qué es VMWare vSphere?
Es una plataforma de virtualización que permite construir infraestructuras cloud.
Está diseñada para organizaciones que desean virtualizar por completo sus centros de datos y
proporcionar estas tecnologías como servicios.
vSphere permite transformar los centros de datos en entornos de cloud computing
drásticamente simplificados, capaces de proporcionar una generación de servicios flexibles y
fiables.
Ventajas que aporta este tipo de plataforma:
- Eficiencia. Gracias a su utilización y automatización, capaz de conseguir que la
utilización del hardware mejore del 5 al 15% hasta un 80% sin sacrificar el
rendimiento.
- Reducción de costes. Disminuye los gastos de propiedad hasta un 80% y los costes
operativos en un 30%.
- Agilidad. Una infraestructura que proporciona disponibilidad, escalabilidad y
rendimientos integrados y garantizados en las aplicaciones que ejecuta vSphere.

29
Características:
A continuación se mostrará algunas de las funciones que utiliza VMware vSphere de una manera
resumida. En páginas posteriores se ha investigado con más detalle y de forma específica de
algunas funciones que ofrece vSphere.

30
vSphere ESXi
Capa de virtualización sólida y de alto rendimiento que abstrae los recursos de hardware de
los servidores y permite que se puedan compartir entre varias máquinas virtuales.
DRS
Coordina los recursos informáticos con las prioridades de la empresa equilibrando
automáticamente la carga entre los hosts. Optimiza el consumo de energía apagando los hosts
durante los períodos de menos carga.
vMotion
Elimina el tiempo de inactividad de las aplicaciones derivado del mantenimiento planificado
de servidores, migrando en caliente las máquinas virtuales de un host a otro.
Big Data Extensions
Ejecuta cargas de trabajo para lograr una mayor utilización, fiabilidad y agilidad de los
sistemas.Gracias a vSphere Web Client, las empresas pueden asignar recursos de manera
flexible para responder a las necesidades cambiantes de la empresa con solo hacer clic en un
botón.
DPM
vSphere Distributed Power Management (DPM) nace en vSphere 4 con el objetivo de ahorrar
energía. DPM es estratégico en un Datacenter grande, pensar que en estas instalaciones la
energía es el coste operativo más importante en el total.
En vSphere 5.5 aparece Host Power Management (HPM), una función complementaria a DPM
cuya misión es, también, el ahorro de energía, motivo por el cual puede generar confusiones.
DPM funciona dentro de un cluster DRS, cuando DPM está activado, al disminuir la carga de
computación sobran hosts para atender a las VMs, DPM se encarga de vaciar los sistemas con
vMotion y “apagar” estos hosts, al aumentar la carga de computación en el cluster se
“arrancan” los hosts necesarios para atender las VMs y el cluster DRS “reparte” la carga entre
los hosts.
HPM funciona en cada host de forma independiente, si se habilita en la BIOS del host, el
hipervisor, a través del ACPI, es capaz de manejar los C-states de la CPU. Los estados C del
procesador son estados intermedios de ahorro energético, la granularidad de estos estados se
llaman deep C-states que permiten dormir o parar un procesador cuando no se utiliza,
disminuyendo el consumo energético.

31
¿Cómo se configura HPM?
En la configuración de host de vSphere 5.5, en la opción de Power Management, la política
por defecto es Balanced, las políticas existentes son :
High Performance: Máximo rendimiento, no se utilizan HPM ni los deep C-states de la CPU.
Balanced: Solo se utilizan los deep C-states si no afectan al rendimiento del procesador.
LowPower: Utiliza los deep C-states de la CPU pudiendo disminuir el rendimiento del host.
Cuando las estrategias de eficiencia energética y el Green IT dominan el escenario.
Custom: Es la política Balanced pero con capacidad de modificar las métricas de la política.
Network I/O Control
Se utiliza para configurar reglas y políticas en el nivel de máquina virtual, así como para
asegurarse de que siempre haya recursos disponibles para sus aplicaciones esenciales para el
negocio. Network I/O Control supervisa la red. Cada vez que detecta congestión,
automáticamente reasigna los recursos a las aplicaciones de máxima prioridad conforme a lo
definido en las reglas empresariales.
De este modo, Network I/O Control permite mejorar la productividad de los administradores,
ampliar la virtualización a mayor número de cargas de trabajo y aumentar la versatilidad de
la infraestructura.
Las ventajas que aporta son:
Aislamiento: garantiza el aislamiento del tráfico, para que un flujo determinado nunca
domine por encima de los demás, lo que evita las pérdidas de paquetes.
Cuotas: permiten un particionamiento flexible de la capacidad de red, para ayudar a los
usuarios a gestionar la situación cuando los flujos compiten por los mismos recursos.
Límites: aplicar límites de ancho de banda del tráfico de red.
Etiquetado IEEE 802.1p: etiqueta los paquetes que salen del host de vSphere para que los
recursos de red físicos los gestionen correctamente.

32
Network I/O Control clasifica el tráfico en varios pools de recursos predefinidos:
- VMware vSphere vMotion
- iSCSI
- Registro de tolerancia a fallos
- Gestión
- Sistemas de archivos de red (NFS)
- Tráfico de máquinas virtuales
- Tráfico de vSphere Replication
- Definido por el usuario
Distributed Switch
Centraliza el aprovisionamiento, la administración y la supervisión de la red mediante la
agregación de redes en todo el centro de datos.
Características:
- Simplificación de la configuración de red de las máquinas virtuales.
- Prestaciones mejoradas de supervisión y solución de problemas de la red.
- Compatibilidad con las funciones de red avanzadas de VMware vSphere.

33
vSphere Distributed Switch amplía las funciones y prestaciones de las redes virtuales a la vez
que simplifica el aprovisionamiento y el proceso continuo de configuración, supervisión y
gestión.
Los conmutadores de red de vSphere se pueden desglosar en dos secciones lógicas: plano de
datos y plano de gestión.
El plano de gestión implementa la conmutación, el filtrado, etiquetado, etc. de paquetes
propiamente dichos y es la estructura de control que se emplea para que el operador pueda
configurar la funcionalidad del plano de datos. Cada vSphere Standard Switch (VSS) contiene
los dos planos, de datos y de gestión. El administrador configura y mantiene cada conmutador
individualmente.
DistributedSwitch alivia esta carga de gestión, pues trata la red como un recurso agregado.
Los conmutadores virtuales del nivel de host individual se abstraen en un único
DistributedSwitch de gran tamaño que abarca varios hosts en el nivel del centro de datos. En
este diseño, el plano de datos sigue siendo local para cada vSphereDistributedSwitch, pero el
de gestión se centraliza.

34
High Availability
Proporciona alta disponibilidad en todo el entorno de virtualizado sin el coste ni la
complejidad de las soluciones en clúster tradicionales.
App HA
Detecta los fallos de las aplicaciones o sistemas operativos y efectúa su recuperación.
Complementa la funcionalidad de High Availability con supervisión y reparación automatizada
en el nivel de aplicaciones. App HA aumenta el tiempo de actividad de las aplicaciones
mediante:
- Supervisión y reparación basadas en políticas.
- Integración con vSphere HA para proporcionar numerosas opciones de recuperación,
por ejemplo: reiniciar el servicio de las aplicaciones o la máquina virtual
Además, reduce el coste y la complejidad, aportando:
- Protección y soporte uniformes para muchas aplicaciones comerciales de uso común.
- Gestión sencilla y centralizada con visibilidad del estado de las aplicaciones desde
VMware vCenter Server.

35
Fault Tolerance
Proporciona disponibilidad continua para aplicaciones sin pérdida alguna de datos en caso de
fallo de algún servidor.
Protección de datos
Protege sus datos mediante copias de seguridad en disco rápidas y sin agentes, con
eliminación de duplicados para minimizar el espacio en el disco de copia de seguridad.
Data Protection (VDP) proporciona una copia de seguridad rápida a disco y una recuperación
más fiable.
Divide los archivos en subsegmentos de longitud variable con objeto de determinar cuáles son
únicos y minimizar los requisitos de almacenamiento para la copia de seguridad.
Replicación
Permite la sincronización entre una máquina/s virtual local y una remota, lo cual es una
excelente forma de realizar copias de seguridad y disponer de tolerancia a fallos en nuestro
datacenter, ya que, ante una avería en nuestros servidores centrales, en muy poco tiempo
podríamos tener en funcionamiento las máquinas virtuales de respaldo.
vSphere Replication es un producto que destaca por su sencillez el cual funciona
perfectamente y cumple su cometido al 100%. Precisamente esta sencillez de puesta en
marcha y configuración se puede convertir a la vez en su gran desventaja a la hora de
decantarnos por este producto como solución de réplica. Hay una serie de limitaciones o
carencias de configuración que podemos encontrarnos y que debemos de saber a la hora de
elegir o no vSphere Replication:

36
- Protege máquinas virtuales de manera individualizadas.
- Requisitos mínimos: SRM 5.0, ESXi 5.0, Virtual center Server 5.0 (No vcenter appliance),
Hardware virtual 7.
- No dispone de una gestión de uso de ancho de banda.
- No permite realizar tareas programadas de replicación. Solamente los tiempos de RPO
siendo el de 15 minutos el más agresivo.
- Solo permite un único punto de recuperación.
- No replica máquinas virtuales apagadas.
- No replica snapshots de las máquinas virtuales origen.
- Discos RDM no están soportados.
- Únicamente permite funcionar con un Virtual center. No soporta virtual center hearthbeat.
- Solo funciona a través del virtual center. Necesitamos el Virtual center para realizar
cualquier tarea ya sea de configuración o recuperación.

37
Auto Deploy
Facilita y agiliza la implementación de servidores y aprovisionamiento de hosts de vSphere
aprovechando las prestaciones de arranque a través de la red de los servidores x86 junto con
la reducida presencia del hipervisor VMware ESXi.
Con Auto Deploy, los hosts de vSphere se arrancan a través de la red desde un servidor de
Auto Deploy central en cuya memoria está instalado directamente el software de ESXi.Una
vez instalado, el host se configura por medio de un perfil de host de VMware vCenter. El host
ya configurado se conecta a vCenter, donde está disponible para las máquinas virtuales del
host. Todo el proceso está automatizado por completo, de forma que se pueden aprovisionar
nuevos hosts sin intervención manual.
Update Manager
Reduce el tiempo dedicado a las correcciones rutinarias automatizando el seguimiento, la
aplicación de parches y la actualización de los hosts de vSphere.
Host Profiles
Permite crear un perfil una vez y utilizarlo para configurar numerosos hosts de vSphere.

38
vShield Endpoint
Elimina la presencia de los antivirus en las máquinas virtuales y mejora el rendimiento de los
análisis antivirus descargando sus funciones en un dispositivo virtual de seguridad.
Permite gestionar las políticas antivirus y antimalware para entornos virtualizados con las
mismas interfaces de gestión que se utilizan para proteger la infraestructura física. vShield
Endpoint refuerza la seguridad de la virtualización con protección reforzada de los puntos de
acceso.

39
Storage DRS
Proporciona distribución de máquinas virtuales y mecanismos de equilibrio de carga basados
en la latencia de E/S y la capacidad de almacenamiento.
Storage vMotion
Lleva a cabo migraciones sin interrupciones del almacenamiento, elimina los cuellos de
botella de E/S del almacenamiento en las máquinas virtuales y libera la valiosa capacidad de
almacenamiento.
Profile-Driven Storage
Proporciona visibilidad del pool de almacenamiento, para que pueda automatizar y optimizar
el aprovisionamiento del almacenamiento.
Mediante la configuración de una serie de perfíles y etiquetas podremos definir las
características de nuestros datastores. Podremos definir nuestros almacenes en función de su
rendimiento, disponibilidad, valor, etc. para posteriormente almacenar las máquinas virtuales
en ellos en función de la calidad de servicio que queremos/debemos ofrecer. A la hora de
crear una máquina virutal, migrarla de datastore o clonarla, vCenter nos mostrará los
datastores compatibles donde almacenaremos dicha máquina evitando por tanto cualquier
error humano.

40
Storage I/O Control
Prioriza el acceso al almacenamiento supervisando continuamente las cargas de E/S de un volumen
de almacenamiento y asignando dinámicamente los recursos de E/S disponibles a las máquinas
virtuales según las necesidades empresariales.
Storage I/O Control permite activar la supervisión de la latencia de dispositivos que los hosts
experimentan al comunicarse con el almacén de datos. Cuando la latencia supera un umbral
establecido, la función se activa automáticamente, para aliviar la congestión. A cada máquina
virtual que accede a ese almacén de datos se le asignan recursos de E/S de forma
proporcional a su cuota.
Nos permite mejorar el rendimiento de disco a la hora de usar asignaciones de recursos en las
máquinas virtuales. En vSphere podemos asignar diferentes prioridades a una máquina virtual
a nivel de CPU, RAM y disco, así como la CPU y la RAM las prioriza únicamente el host que las
ejecuta, en el acceso a disco (compartido) lo priorizará de forma proporcional entre el resto
de los hosts. Requisitos: vSphere 4.1 Enterprise Plus, un sólo vCenter gestionará los
almacenes, soportado para FC e iSCSI (no NFS o RDM/RAW), multiplesextends no soportados.

41
VMFS
Es un sistema de archivos en clúster de alto rendimiento optimizado para máquinas virtuales. Si bien
los sistemas de archivos convencionales solamente permiten que un servidor tenga acceso de lectura
y escritura al mismo sistema de archivos en un momento dado, VMFS aprovecha el almacenamiento
compartido para permitir que varios hosts de VMwarevSphere lean y escriban en el mismo
almacenamiento de forma simultánea.
- Simplifica el aprovisionamiento y la administración de máquinas virtuales almacenando el estado
de toda la máquina virtual en una ubicación centralizada.
- Crea una copia puntual de datos de una máquina virtual que pueda utilizarse para operaciones de
prueba, copia de seguridad y recuperación.
- Admite capacidades únicas basadas en la virtualización, como la migración en caliente de
máquinas virtuales en funcionamiento entre servidores, el reinicio automático de una máquina
virtual con fallos en otro servidor y el clústering de máquinas virtuales en servidores diferentes.
- Añade el espacio de discos virtuales a máquinas virtuales en funcionamiento para aumentar los
recursos disponibles o con fines de copia de seguridad.
- Utiliza el registro distribuido para recuperar máquinas virtuales con más rapidez y fiabilidad si se
producen errores en el servidor.

42
Flash Read Cache
Virtualiza la memoria flash del servidor mediante una capa de caché de lectura de alto rendimiento
que reduce drásticamente la latencia de las aplicaciones. El almacenamiento en caché es totalmente
transparente para la máquina virtual sin necesidad de agentes guest. Flash Read Cache permite
asignar recursos de memoria flash a nivel de disco de máquina virtual.
La memoria flash de servidor, en forma de tarjetas PCIe o de unidades de estado sólido, es una
forma almacenamiento fiable y asequible para el entorno de vSphere. La memoria flash de servidor
proporciona un nuevo nivel de almacenamiento de baja latencia que se puede aprovechar para que
los datos estén más cerca de las máquinas virtuales, con una relación calidad-precio cada vez mejor.

43
3.2 vSphere Client Web
vSphere Web Client tiene la misma utilidad que vSphere Client. La gran diferencia es que
como indica su nombre "Web". Nos permite realizar las tareas administrativas desde un
navegador.
Para ello debes descargarte en la página oficial de VMware el plugin/extensión que te
permite navegar vía web. Hay que tener en cuenta que vCenter tiene que estar habilitado e
iniciado en todo momento para poder realizar todas estas funciones.
La versión web no fue muy utilizada en 5.0, pero a partir de 5.1 VMware realizó una
estrategia en la que solo algunos complementos podían ser utilizados desde el navegador y no
desde el programa habitual. Por ejemplo vSphere Replication, la gestión de vSphere SSO o la
integración con vCenter Orchestrator.
La forma de acceder es con la dirección: https://nombre:9443/vsphere-client.
Destacar que el puerto 9443 utiliza el protocolo TCP/IP, garantiza la entrega de paquetes de
datos en la misma orden, en que fueron mandados.
Además, de la inclusión de HTTPs para navegar de forma segura y poder administrar tu
servidor sin ningún tipo de problema de seguridad.
Otra de las características de este cliente web es su velocidad y fiabilidad.
Es bastante cómodo trabajar con él y se pueden crear filtos de manera muy rápida, haciendo
así una búsqueda más rápida y fiable.
Se agrega soporte para drag & drop de objetos a nivel del inventario, permitiéndonos así
tener una navegación y uso del cliente mucho mas amigable de lo que se tenia en versiones
anteriores.
También se ha incluido soporte para Mac OS y una consola de HTML para visualizar e
interactuar con las máquinas virtuales.

44
Diferencias entre vSphere Client y vSphere Web Client
Funcionalidades vSphere Client vSphere Web Client
Windows Requerido No requerido
Java y Flash No requerido Requerido
Navegadores Soportados - Firefox, IE, Chrome
Puerto de acceso 443 443/9443
Crear VMs en v9 de hardware No Si
Control directo de host Si A través de vCenter
Update Manager Plugin Si No
Single Sign On Soportado Soportado
Motor de búsqueda Simple Mejorado
Soporte SRM 5.1 No soportado Soportado
vMotion mejorado No soportado Soportado
Instancias del vCenter Una Múltiples
Gestión de LOGs Simple Mejorada
vSphere Replication No soportado Soportado
vSphere Data Protection No soportado Soportado
Transferencia de ficheros en
Datasotore
Soportado Soportado
Acceso a consola VM Soportado Soportado

45
En vSphere Client no es posible crear máquinas virtuales de versión 9 y 10, pero si es posible
administrarla. Gracias a vSphere Client Web, podemos empezar a crear dichas máquinas con
el tutorial o guía correspondiente, además de luego poder editar las opciones.
Hay que tener cuidado con esto, porque si utilizas una máquina de versiones 9 o 10, con
vSphere Client no podrás editar sus opciones.
Hay otros ejemplos como para utilizar Single Sign On en el cliente web se necesita instalar
vSphere Data Integration.
O la posibilidad de transferir archivos a un Datastore pero requiere client integration
En el cliente Web para gestionar la consola de las máquinas virtuales se necesita instalar
vSphere Client Integration.
Nuevas características de vSphere Web Client
 Work In Progress: Esta nueva característica permite iniciar una nueva tarea, como por
ejemplo instalar una nueva máquina virtual y después poner la tarea en pausa para
trabajar en otras cosas en cambio en las versiones anteriores si iniciabas una tarea
nueva hasta que no acabara no podías realizar otra tarea, con esta función las tareas
seguirán su proceso incluso si se cierra el navegador y se vuelve a abrir.
 Single Sign On: Esta función permite al administrador iniciar sesión en una vez y luego
se autenticará en otras funciones instaladas de forma automática. Esta característica
puede utilizar contraseñas de active directory pero no se podrá trabajar con
componentes de versiones anteriores. Esta nueva característica también permite
administrar varios vCenters sin tener que usar el modo vinculado.
 vSphere Replicación: Permite replicar las máquinas virtuales a través de internet o un
enlace WAN a otro sitio diferente. Este proceso copia únicamente los bloques
cambiados en el sitio de recuperación por lo tanto reduce el ancho de banda y hace
posible objetivos de punto de recuperación más agresivos.
 Tagging Inventario: Permite asignarle un nombre, una descripción y una categoría a
un objeto de vSphere, esto es útil para hacer anotaciones sobre los objetos que
deseemos y realizar la búsqueda utilizando esas notas
 vSphere Data Protection: Esta característica solo disponible en el cliente web
permite realizar copias de seguridad rápidas a los discos con una recuperación fiable,
además amplia las prestaciones de copias de seguridad con mayor escalabilidad e
integración a nivel de aplicaciones esenciales.

46
4. Arquitectura del proyecto
Para realizar nuestro proyecto deberemos montar la siguiente Arquitectura de Red.
Esta arquitectura está compuesta por dos equipos ESXI que harán la función de hipervisores,
dos sistemas FreeNAS los cuales realizarán la compartición de discos ISCSI hacia los ESXI para
poder guardar las máquinas virtuales que se instalen en estos y así no ocupar capacidad en los
Datastores propios de estos ESXI y finalmente tendremos un Windows Server 2008 R2 en el
cual instalaremos el Vcenter Server y el cliente VSphere para poder administrar los sistemas
ESXI.
En esta arquitectura crearemos 4 redes diferentes una que será la red de administración
(Management Network), la red ISCSI por la cual se compartirán los discos, la red VMOTION
para poder realizar esta función y finalmente la red FT (Fault Tolerance).

47
Red de Administración
Esta es la red principal de la arquitectura y está formada por los dos sistemas ESXI y un
sistema Windows Server 2008 R2 en el cual instalaremos el Vcenter Server y el programa
Vsphere el cual sirve para poder administrar los dos sistemas ESXI.
Los equipos de esta red tendrán direcciones ip a partir de la 192.168.1.0
Red ISCSI
En esta red tendremos dos sistemas FreeNAS que se encargarán de compartir discos ISCSI a los
dos sistemas ESXI para que estos puedan guardar las máquinas virtuales que se instalen en
estos discos externos y así no se ocupará
espacio en los datastores propios del ESXI.
Esto también nos servirá para que en caso de
que un sistema ESXI se estropeara las
máquinas virtuales no las perderíamos ya que
están almacenadas en discos externos.
Los equipos de esta red tendrán direcciones IP
a partir de la 192.168.2.0

48
Red VMOTION
Esta red está compuesta de solo los dos sistemas ESXI y servirá para poder realizar el servicio
de VMOTION el cual consiste en poder migrar las máquinas de un host a otro.
Hemos de crear una red nueva para este servicio para no saturar las otras redes mientras se
realiza la migración de la máquina virtual.
Red Fault Tolerance
Esta red está compuesta de los dos sistemas ESXI instalados y servirá para poder realizar el
servicio Fault Tolerance el cual consiste en que las máquinas virtuales estén activas en los dos
hosts (uno en modo activo y otro en modo pasivo) y cuando el host primario se caiga se pueda
seguir trabajando con la misma máquina desde el host secundario.
Hemos de crear una nueva red para poder realizar este servicio para que el cambio de host se
haga rápido para que el usuario no pueda notar este cambio de host en la máquina virtual.

49
5. Almacenamiento compartido
Para realizar un buen sistema de almacenamiento compartido deberemos montar una red SAN
(Storage área network).
¿Qué es una SAN?
Una SAN es una red de almacenamiento integral. Esta arquitectura agrupa los siguientes
elementos:
 Una red de alta velocidad de canal de fibra o ISCSI
 Un equipo de interconexión dedicado
 Elementos de almacenamiento de red
Esta red se distingue de los otros modos de almacenamiento por el modo de acceso a bajo
nivel, el tipo de tráfico de esta red es similar al de los discos duros.
Una red SAN proporciona acceso a nivel de bloque a LUNs. Un LUN (número de unidad lógica),
es un disco virtual proporcionado por la SAN. El Administrador del sistema tiene el mismo
acceso a la LUN como si fuera un disco directamente conectado a la red.
Los dos principales protocolos utilizados en una red SAN son FibreChannel e ISCSI. Una red
FibreChannel es muy rápida y no está saturada por el tráfico de la red LAN.
Estructura básica de una red SAN
Las redes SAN se componen de tres capas:
 Capa de Host: Consiste principalmente en Servidores, dispositivos o componentes y
software.
 Capa de Fibra: Esta capa la conforman los cables así como los SAN Hubs y los SAN
Switches como punto central de conexión para la SAN.
 Capa de Almacenamiento: La componen las formaciones de discos y cintas empleados
para almacenar los datos
La red de almacenamiento puede ser de dos tipos:
 FibreChannel: Es una red física de dispositivos FibreChannel que emplea
FibreChannelswitches y directores y el protocolo FCP (FibreChannelProtocol) para
transporte.
 Red IP: Emplea la infraestructura estándar de la LAN con hubs y switches Ethernet
interconectados. Una red SAN IP emplea ISCSI para el trasporte

50
Características de una red SAN
 Latencia: Una de las principales características de las redes SAN es que son construidas
para minimizar el tiempo de respuesta del medio de transmisión
 Conectividad: Permite que múltiples servidores estén conectados al mismo grupo de
discos permitiendo que los sistemas de almacenamiento sean óptimos.
 Distancia: Estas redes al ser construidas con fibra óptica heredan sus beneficios por lo
tanto pueden tener dispositivos separados por mucha distancia sin repetidores.
 Velocidad: Las redes SAN actualmente tienen una velocidad de transferencia de la
información entre 4 y 8 Gigabits por segundo.
 Disponibilidad: Al tener mayor conectividad permiten que los servidores y dispositivos
de almacenamiento se conecten más de una vez a la SAN, de esta forma se pueden
tener rutas redundantes que incrementarán la tolerancia a fallos.
 Seguridad: Las redes SAN tienen una tecnología de zonificación que consiste en que un
grupo de elementos se aíslen del resto para evitar problemas.
 Componentes: Los principales componentes de una red SAN son switches, HBAs,
Servidores y librerías de cintas.
 Topología: Las redes SAN tienen las siguientes topologías:
 Cascada
 Anillo
 Malla
 Núcleo
 ISL (Inter switch link): Las conexiones entre los switches de la SAN se hacen mediante
puertos tipo “E” y pueden agruparse para formar una troncal que permita un mayor
flujo de la información y tolerancia a fallos.
Ventajas y desventajas
 El rendimiento de la red SAN está directamente relacionado con el tipo de red que se
utiliza.
 La capacidad de una red SAN se puede extender de manera casi ilimitada.
 Permite compartir datos entre varios equipos de la red sin afectar el rendimiento
porque el tráfico de SAN está totalmente separado del tráfico de usuario.

51
 Una red SAN es mucho más costosa que una NAS ya que es una arquitectura completa
que utiliza una tecnología cara.
Configuraciones
Primero en la máquina virtual FreeNAS añadiremos los discos para poder crear los RAIDS que
deseemos, en nuestro caso tendremos 4 RAIDS.
Una vez tengamos los discos añadidos accederemos al FreeNAS mediante web poniendo su ip
en el explotador e iremos al apartado Storage y seleccionaremos la opción UFS volume
Manager.
Se nos abrirá la siguiente ventana en la que deberemos asignar un nombre al nuevo RAID,
seleccionar los discos que lo compondrán e indicar que será de tipo Mirror.

52
Una vez hayamos creado el RAID iremos al apartado ISCSI ubicado dentro de Services en el
menú de la izquierda y empezaremos a configurar diferentes cosas para poder compartir este
RAID creado.
Primero añadiremos un nuevo Extent en el que indicaremos el nombre que tendrá, que será
de tipo File, también indicaremos el Path donde estará ubicado este extent creado y
finalmente indicaremos el espacio que tendrá en nuestro caso 60GB ya que el RAID lo forman
dos discos de 30GB cada uno.
Ahora crearemos el Iniciador en el cual indicaremos que tendrá como destino todos los
equipos ya que en el caso del sistema ESXI no hay manera de saber su iniciador.

53
Seguidamente crearemos un nuevo Portal, aquí debemos dejar las opciones que salen por
defecto y no configurar nada.
Ahora crearemos un nuevo Target, esto lo que hace es relacionar el Portal creado
anteriormente con el Iniciador también creado antes, deberemos indicar el nombre que
tendrá este nuevo target e indicaremos el número de Portal y de iniciador que se
relacionarán.

54
Finalmente para acabar con las configuraciones del FreeNAS crearemos un Target/Extent para
relacionar el Target creado anteriormente con el Extent también creado anteriormente.
Una vez realizadas todas estas configuraciones en el sistema FreeNAS ya tendremos creada
nuestra compartición de discos.
Ahora añadiremos estos discos compartidos en los hosts ESXI, esto se deberá hacer desde el
programa Vsphere. Una vez estemos en el Vsphere iremos a la configuración del host en el
que deseamos poner el disco compartido, iremos al apartado Storage Adapters y entraremos
en las propiedades del adaptador ISCSI.
Dentro de estas propiedades deberemos habilitar el adaptador chequeando la casilla
“Enabled”.

55
Seguidamente en la pestaña DynamicDiscovery indicaremos la ip del FreeNAS que sirve el
disco compartido.
Una vez realizadas estas dos configuraciones ya podremos ver los discos compartidos desde el
FreeNAS en el Vsphere.

56
Ahora iremos al apartado Storage y añadiremos un nuevo disco seleccionando la opción “Add
Storage”.
Se nos abrirá una nueva ventana, primero nos preguntará que tipo de almacenamiento
queremos crear, seleccionaremos la primera opción Disk/LUN.
Seleccionamos el disco que hemos compartido antes desde el FreeNAS.

57
Ahora seleccionaremos la Versión de archivo de sistema que tendrá este nuevo disco,
seleccionamos la versión 5 ya que es la más nueva.
Seguidamente deberemos indicar el nombre que tendrá este nuevo disco creado dentro del
ESXI, en nuestro caso se llamará Disco4 ya que tenemos otros tres ya creados anteriormente.

58
En esta nueva ventana indicaremos la capacidad que tendrá este nuevo disco creado, se
pueden seleccionar dos opciones la primera que nos pondrá el máximo espacio disponible que
tiene el disco compartido y la segunda en la que podremos indicar el espacio exacto que
deseamos que tenga el nuevo disco, en nuestro caso seleccionaremos la primera opción.
Para finalizar el proceso de crear un nuevo disco en el ESXI nos saldrá un breve resumen con
todas las configuraciones que hemos indicado.

59
6. vMotion
El servicio VMotion permite trasladar máquinas virtuales instaladas en el sistema ESX y que
están en funcionamiento de un servidor ESX a otro sin tiempo de inactividad. La máquina
virtual retiene su indentidad y conexiones de red. La memoria activa y el estado de ejecución
preciso de la máquina virtual se transfieren a través de una red de alta velocidad, esto
permite que la máquina virtual pase de ejecutarse en el host de origen a ejecutarse en el
host de destino.
El estado de ejecución consta de tres componentes principales:
 Estado de dispositivos virtuales.
 Conexiones de dispositivos de red e ISCSI.
 Memoria física de la máquina virtual.
Estado de dispositivos virtuales
Incluyendo el estado de la CPU, red, adaptadores de disco y más cosas vSphere puede
serializar el estado de los dispositivos virtuales que generalmente tienen un tamaño menor a
8MB.
Conexiones de dispositivos de red e ISCSI
La arquitectura de red virtual de VSphere centrada en los vSwitch y en las vNIC permite que
sea más fácil preservar las conexiones de red existentes, incluso después de que una máquina
virtual sea migrada a otro host. Como cada vNIC tiene su propia MAC que es independiente de

60
la MAC de las NIC físicas al mover una máquina virtual de un host a otro la conexión de red
seguirá activa. Una vez que la migración se completa correctamente el host de destino envía
un paquete RARP al switch físico para asegurar que actualice sus tablas con el nuevo puerto
de switch utilizado por la máquina virtual migrada.
El uso de almacenamiento compartido como SAN o NAS hará que sea muy fácil transferir el
estado de los discos.
Memoria física de la máquina virtual
Este es el componente de mayor tamaño que necesita ser transferido durante el proceso de
VMotion.
Para permitir que la máquina virtual siga ejecutándose durante la transferencia de la
memoria y que el proceso sea totalmente transparente para el usuario, el proceso se deberá
llevar a cabo en tres fases:
Fase 1: Seguimiento de la máquina virtual
En esta etapa se realiza un seguimiento de las páginas de memoria de la máquina virtual para
poder registrar cualquier modificación en la máquina virtual durante la migración. Este
seguimiento puede causar una bajada del rendimiento de la máquina virtual.
Fase 2: Pre-copia
Como la máquina virtual continua en ejecución y modificando el estado de la memoria en el
host de origen durante el proceso de VMotion, el contenido de la memoria de la máquina
virtual es copiado desde el host de origen al host de destino en un proceso iterativo.
Con la primera iteración se copia todo el contenido de la memoria y en las siguientes
iteraciones se copian solo las páginas que fueron modificadas durante este periodo.
Fase 3: Swtichover
Esta es la fase final de todo el proceso de VMotion, la máquina es pausada momentáneamente
en el host de origen, para poder copiar los últimos cambios en la memoria al host de destino y
que finalmente la máquina virtual retome sus operaciones en el host de destino.
Mejoras de vMotion en Vsphere5
Uso de múltiples NICs para vMotion
Vsphere 5 permite utilizar multiples adaptadores de red para vMotion lo cual permite reducir
mucho el tiempo de migración de las máquinas virtuales.
Con esta mejora el VMkernel balanceará de forma transparente el tráfico de vMotion entre
todas las vmknics configuradas para este servicio. Aunque solo haya una única operación de

61
vMotion en curso, el VMkernel utilizará todos los adaptadores de red disponibles para
distribuir el tráfico de vMotion.
Stun During Page Send (SDPS)
La nueva versión de Vsphere incluye nuevas mejores para asegurar que vMotion no fallará
debido a problemas en la copia de memoria. Como se ha comentado anteriormente el proceso
de transferencia de la memoria durante una operación de vMotion incluye un proceso
iterativo. En la mayoría de casos una iteración debe tomar menos tiempo que la anterior, no
obstante hay casos en que la máquina virtual modifica la memoria más rápido de lo que
puede ser transferida y esto daba como resultado una operación fallida de vMotion en
versiones anteriores.
Para poner solución a estos problemas en la nueva versión de Vsphere se reduce la velocidad
de la máquina y así se asegura que la tasa de modificación de la memoria sea menor que la
tasa de transferencia.
Otras mejoras
Mejoras para minimizar el impacto de la tarea de seguimiento de los cambios en la memoria
Mejoras para reducir el tiempo necesario para que la máquina virtual retome su nivel normal
de performance después de una operación de vMotion
Optimizaciones que permiten que vMotion sature de forma selectiva un ancho de banda de
10GBE durante la migración con vMotion.

62
7. Storage vMotion
Storage vMotion permite migrar en caliente los archivos de disco de las máquinas virtuales en
las matrices de almacenamiento y entre ellas , sin provocar una interrupción del servicio. La
migración de archivos de disco de las máquinas virtuales sin ninguna interrupción a distintos
tipos de almacenamiento permite gestionar de una forma más rentable esos discos como
parte de una estrategia de almacenamiento distribuida en diferentes niveles.
Principales funciones de Storage vMotion:
 Realizar migraciones de almacenamiento sin ningún tiempo de inactividad y con una
integridad absoluta de las transacciones.
 Permite migrar los archivos de disco de las máquinas virtuales, independientemente
del sistema operativo que tengan instalado y del hardware de servidor donde se
ejecuten.
 Permite migrar en directo los archivos de disco de las máquinas virtuales a cualquier
sistema de almacenamiento que sea compatible con vSphere (Fibre Channel, iSCSI,
FCoE o NFS).
Optimización dinámica del rendimiento del almacenamiento
Storage vMotion optimiza el rendimiento del almacenamiento ya que mover los archivos de
disco, sin ninguna interrupción, de las máquinas virtuales a LUN alternativos los cuales están
mejor diseñados para proporcionar el rendimiento necesario.

63
Esta optimización permite:
 Gestionar los problemas de rendimiento del almacenamiento sin programar ningún
tiempo de inactividad.
 Solucionar los cuellos de botella del almacenamiento antes de que se conviertan en
problemas graves.
Gestión eficaz de la capacidad del almacenamiento
Storage vMotion permite recuperar la capacidad de almacenamiento no utilizada y asignarla a
otras máquinas virtuales. Storage vMotion también permite utilizar el almacenamiento con
eficacia para evitar futuros problemas de rendimiento. Para ello, permite mover las máquinas
virtuales, sin interrupciones, a otra unidad de almacenamiento con más capacidad a medida
que los archivos de disco de esas máquinas se acercan a los límites de tamaño de la unidad de
almacenamiento total.
Novedades
 A partir de la versión 5.0 de vSphere Storage vMotion utiliza un nuevo método,
conocido como “modo de mirroring”. En un plano superior, el modo de mirroring
utiliza una copia de los datos datos anteriores del datastore de origen al de destino,
con los bloques modificados en el datastore de origen reflejados en el de destino.
 En esta nueva versión se pueden realizar hasta cuatro copias de disco simultáneas por
cada operación que se realice de Storage vMotion mientras que en las versiones
anteriores, vSphere copiaba en serie los discos pertenecientes a una máquina virtual.
En la siguiente imagen podemos ver la comparación del proceso en las versiones
anteriores de vSphere con la versión 5.1

64
Versiones anteriores de vSphere. A partir de la versión 5.1 de vSphere
Beneficios de Storage vMotion
 Mover el disco de una máquina virtual desde una cabina de almacenamiento antigua a
otra más nueva, esto permite reconfigurar o mantener un entorno de almacenamiento
sin la necesidad de parar las máquinas virtuales.
 Balancear manualmente los discos de las máquinas virtuales a diferentes DataStores
para mejorar el rendimiento.
 Retirar cabinas de almacenamiento físico sin la necesidad de parar las máquinas
virtuales.
 Migrar los discos de las máquinas virtuales de un DataStore de Fibre Channel a otro
DataStore iSCSI, NAS o disco local.
 Actualización del software de VMware sin la necesidad de parar las máquinas virtuales.
Como realizar Storage vMotion
Primer ponemos en marcha un ping que comunique la máquina del vSphre con la máquina
virtual, esto nos servirá para comprobar que la máquina virtual no se para durante el proceso
de Storage vMotion.
Seguidamente hacemos clic derecho sobre la máquina virtual que deseamos migrar y
seleccionamos la opción Migrate.

65
Una vez seleccionemos esa opción se nos abrirá la siguiente ventana en la que
seleccionaremos la opción Change datastore.
Ahora deberemos elegir el disco de destino de la máquina virtual, elegiremos el DRS2 ya que
la máquina actualmente se encuentra en el DRS.
Observamos en la parte inferior de vSphere que se está realizando el proceso de Storage
vMotion.
Una vez finalice el proceso observamos en las propiedades de la máquina virtual migrada que
se ha migrado correctamente al disco elegido.

66
Finalmente volvemos a la consola donde se estaba realizando el ping hacia la máquina virtual
y observamos que no se ha parado en ningún momento.

67
8. Cluster
Un clúster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad,
de tal forma que el conjunto es visto como un único ordenador, más potente que los
comunes.
Los clústeres son normalmente usados para mejorar el rendimiento y la disponibilidad por
encima de la que es prevista por un solo ordenador normalmente siendo más económico que
ordenadores individuales de rapidez y disponibilidad similares.
De un clúster correctamente implementado debe tener estos servicios:
1. Alto Rendimiento
2. Alta disponibilidad
3. Balanceo de carga
4. Escalabilidad
Componentes de un clúster
 Nodos: Los llamados Nodos de un clúster son los ordenadores que forman parte de
este, en un cluster puede haber dos tipos de nodos los dedicados y los no dedicados.
Los nodos dedicados son un tipo de nodos que se usan exclusivamente para realizar
tareas relacionadas con el clúster, en cambio los nodos no dedicados realizan más
tareas a parte de las relacionadas con el clúster.

68
 Almacenamiento: Puede consistir en una NAS, una SAN, o almacenamiento interno en
el servidor. El protocolo más comúnmente utilizado es NFS, sistema de ficheros
compartido entre servidor y los nodos. Sin embargo existen sistemas de ficheros
específicos para clústeres como Lustre (CFS) y PVFS2.
 Sistemas operativos.
 Conexiones de red: Los nodos de un clúster pueden conectarse mediante una simple
red Ethernet con adaptadores de red o NICs, o utilizar tecnologías especiales de alta
velocidad como Fast Ethernet, Gigabit Ethernet, Myrinet, InfiniBand o SCI.
 Protocolos de comunicación y servicios.
 Aplicaciones.
Ventajas e inconvenientes de la utilización de un clúster
La utilización de un clúster tiene diferentes ventajas:
1. Ahorro de costes en recursos.
2. Compartición de información.
3. Soporte multiplataforma con la gestión de diferentes sistemas operativos y aplicaciones.
4. Es muy sencillo de implementar ya que esta tecnología es transparente para el usuario.
5. No exige ninguna sustitución ni adición de hardware.
La única desventaja que tiene un clúster es la seguridad ya que actualmente los protocolos de
seguridad, autentificación y control no están suficiente desarrollados para el uso de cualquier
usuario.

69
8.1 HA
Un Clúster de Alta Disponibilidad (HA) es un conjunto de dos o más servidores que se
caracteriza por compartir el sistema de almacenamiento, y porque están constantemente
monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de
las maquinas que forman el clúster, el software de alta disponibilidad es capaz de volver a
arrancar automáticamente los servicios que han fallado en uno de los otros equipos que
forman el clúster y cuando el servidor que ha fallado se vuelve a recuperar estos servicios se
migran de nuevo a la máquina original.
Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la
integridad de los datos, permite que los usuarios no noten ningún problema.
Hay diferentes razones para implementar este tipo de clúster:
 Aumentar la disponibilidad
 Mejorar el rendimiento
 Escalabilidad
 Tolerancia a fallos
 Recuperación ante fallos en poco tiempo
 Reducir costes
 Consolidar servidores
 Consolidar el almacenamiento
Configuraciones del cluster HA
En un clúster HA hay dos tipos de configuraciones el activo/activo y el activo/pasivo.
 Configuración Activo/Activo
En una configuración de tipo activo/activo, todos los servidores del clúster pueden
ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los
mismos recursos y pueden acceder a estos independientemente de los otros servidores
del clúster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen
estando accesibles a través de los otros servidores del clúster.
La ventaja principal de esta configuración es que los servidores en el clúster son más
eficientes porque pueden trabajar todos a la vez. Sin embargo, si uno de los servidores
deja de estar accesible, su carga de trabajo pasa a los servidores restantes, lo que
produce una bajada del nivel global de servicio ofrecido a los usuarios.

70
 Configuración Activo/Pasivo
Consiste en un servidor que posee los recursos del clúster y otros servidores que son
capaces de acceder a esos recursos, pero no los activan hasta que el servidor
propietario de los recursos ya no esté disponible.
Las ventajas de la configuración activo/pasivo son que no hay una bajada de servicio y
que los servicios solo se reinician cuando el servidor activo deja de responder.
Una desventaja de esta configuración es que los servidores pasivos no proporcionan
ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos
eficiente que el clúster de tipo activo/activo. Otra gran desventaja de este tipo de
configuración es que los sistemas tardan un tiempo en migrar los recursos al nodo en
espera.

71
Funcionamiento del cluster HA
En un clúster de alta disponibilidad, el software de clúster realiza dos funciones
fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando
continuamente su estado y detectando fallos. Y por otro lado administra los servicios
ofrecidos por el clúster, teniendo la capacidad de migrar dichos servicios entre diferentes
servidores físicos como respuesta a un fallo.
Elementos y conceptos básicos en el funcionamiento del clúster
 Recurso y Grupos de Recursos
En un clúster de alta disponibilidad, el software de clúster, independiza a los servicios
de un host concreto, posibilitando que estos servicios se desplacen entre diferentes
servidores de forma trasparente para la aplicación o los usuarios.
El software de clúster permite definir grupos de recursos, los cuales son todos aquellos
recursos necesarios por el servicio.
 Intercomunicación
El software de clúster que gestiona servicios y recursos en los servidores, tiene que
mantener continuamente entre estos una visión global de la configuración y estado del
clúster. De esta forma, ante el fallo de un nodo, el resto conoce que servicios se
deben restablecer.
Ya que la comunicación entre los servidores del clúster es básica para el
funcionamiento de este, es habitual utilizar un canal específico como una red IP
independiente o una conexión serie, la cual no se pueda ver afectada por problemas
de seguridad o rendimiento.
 Heartbeat
El software de clúster conoce en todo momento la disponibilidad de los equipos físicos,
gracias a la técnica de heartbeat. Su funcionamiento consiste en que cada nodo
informa periódicamente de su existencia enviando al resto una “señal de vida”.
 Escenario Split-Brain
En un escenario split-brain, más de un servidor o aplicación que pertenecen a un
mismo clúster intentan acceder a los mismos recursos, esto puede causar daños a
dichos recursos. Este escenario ocurre cuando cada servidor en el clúster cree que los
otros servidores han fallado e intenta activar y utilizar dichos recursos.

72
 Monitorización de Recursos
Ciertas soluciones de clustering HA permiten monitorizar si un host físico está
disponible y también pueden realizar seguimientos a nivel de recursos o servicios y
detectar el fallo de estos.
 Reiniciar Recursos
Cuando un recurso falla, lo primero que realiza el clúster es intentar reiniciar este
recurso en el mismo nodo. Esto supone detener una aplicación o liberar un recurso y
posteriormente volverlo a activar.
 Migración de Recursos
Cuando un nodo ya no está disponible, o cuando un recurso que ha fallado no se puede
reiniciar correctamente en un nodo, el software de clúster reacciona migrando el
recurso o grupo de recursos a otro nodo disponible en el clúster. De este modo el
tiempo de inactividad por el posible fallo es bajo, y el clúster seguirá proporcionando
el correspondiente servicio.
 Dependencia entre recursos
Habitualmente para que el clúster proporcione un servicio, son necesarios varios
recursos lo cual se conoce como grupo de recursos. Cuando se arranca o detiene un
servicio, sus recursos tienen que activarse en el orden correcto ya que unos dependen
de otros. El software de clúster tiene que permitir definir estas dependencias entre
recursos así como entre grupos.

73
 Preferencia de Nodos
En configuraciones de clúster con múltiples nodos, es normal distribuir los servicios
entre los diferentes servidores ya que puede ser que los servidores tengan
características hardware diferentes y nos interese que, para un estado correcto del
clúster, algunos servicios se ejecuten siempre en un determinado servidor.
 Comunicación con otros sistemas
El clúster tiene que monitorizar que un servidor y sus servicios están activos pero
también debe de comprobar que de cara a los usuarios el servidor no queda
desconectado de la red por algún fallo, por esta razón el software de clúster debe
comprobar que los nodos son alcanzables.
 Fencing
En los clústers HA existe la situación en la cual un nodo deja de funcionar
correctamente pero todavía sigue levantado accediendo a algunos recursos y
respondiendo a peticiones. Para evitar que el nodo corrompa recursos o responda con
peticiones, los clústers lo solucionan utilizando una técnica llamada Fencing.
Su función principal es hacerle saber al servidor que está funcionando en mal estado,
retirarle sus recursos asignados para que los atiendan otros nodos, y dejarlo en un
estado inactivo.
 Quorum
Para evitar que se produzca un escenario de Split-Brain, algunas características del
clúster HA introducen un canal de comunicación adicional que se emplea para
determinar exactamente que nodos están disponibles en el clúster y cuáles no.
Esto se implementa utilizando los llamados quorum devices que son un volumen de
almacenamiento compartido exclusivo. También existen implementaciones que
utilizan una conexión de red adicional o una conexión serie.

74
Novedades del clúster HA en Vsphere.
 Capacidad de establecer el tamaño de la ranura para fallos de host tolerados a través
del cliente web.
 Capacidad de recuperar una lista de las máquinas virtuales que abarcan múltiples
ranuras.
 Soporte para el modo de suspensión del sistema operativo invitado.

75
8.2 DRS
Distributed Resource Scheduler (DRS) es una función que tiene VMware vSphere que se
encarga de balancear la carga que tienen los hosts ESX de un cluster. De esta forma nos
garantizamos mejorar el uso de los recursos dentro del mismo cluster.
Básicamente, DRS te permite administrar la carga de la CPU y memoria de un host para que
éste no se vea saturado y con un alto porcentaje de consumo.
El algoritmo de DRS tiene como entrada la información de uso de los recursos tanto de las VMs
como de los Hosts y como salida las recomendaciones de movimientos de las VMs de un host
origen a otro destino, es decir el emplazamiento de las VMs.
DRS acepta tres modos de funcionamiento: Manual, Partial o Full Automated Control y
dependiendo del modo elegido el emplazamiento de las VMs se hará de forma más o menos
automática.
Las funciones básicas de un DRS son:
 Proporcionar recursos altamente disponibles para sus cargas de trabajo.
 Equilibrar las cargas de trabajo para lograr un rendimiento óptimo.
 Escalar y gestionar los recursos informáticos sin interrumpir el servicio.
De esta forma, DRS es capaz de equilibrar la capacidad informática mediante clústeres,
aportando así un rendimiento optimizado a los hosts y a las máquinas virtuales. Y gracias a
esto, nos ofrece:
 Mejorar los niveles de servicio asegurándose de que las máquinas virtuales dispongan
de los recursos apropiados.
 Implementar más capacidad en un clúster sin interrumpir el servicio.
 Migrar automáticamente las máquinas virtuales durante las tareas de mantenimiento
sin interrumpir el servicio.
 Supervisar y gestionar más cantidad de infraestructura por cada administrador del
sistema.

76
También debemos saber que el DRS puede reducir el consumo de energía del propio cluster,
para ello utiliza la tecnología DPM.
DRS es muy útil en casos de emergencia donde uno de los hosts o la propia máquina virtual
esté saturada y no sea capaz de dar más de sí, por falta de recursos. Gracias a esta función
podremos ver como las máquinas pasan de un host a otro sin ver interrumpida su
funcionalidad. Un usuario corriente desconocerá el movimiento de dicha máquina virtual
mientras éste estaba realizando cualquier uso.
Diagrama
Esta imagen nos indica lo que comentábamos más arriba. La máquina que no dispone de los
recursos necesarios por el motivo que sea (le falta memoria, tiene un procesador limitado, ha
llegado al tope de sus posibilidades, etc.) se migra automáticamente (utilizando por supuesto,
VMotion) a otro Datastore capaz de soportar estos datos.
DRS automáticamente distribuye las cargas de trabajo de las máquinas virtuales entre los
hosts de vSphere de un clúster y supervisa los recursos disponibles. En función del nivel de
automatización elegido, DRS migrará las máquinas virtuales a otros hosts del clúster, para
maximizar el rendimiento.

77
En cuanto una máquina virtual se vea al máximo de sus posibilidades en cuanto a rendimiento
se refiere, el DRS se activará y la migrará de un host a otro sin pérdida de información.
Mediante una serie de reglas podemos disponer de un Clúster DRS con más opciones y más
personalización, permitiéndonos establecer unas normas a nuestro gusto en cuánto tipo de
máquinas (grupos), tipo de hosts (si es un ESX u otro), un tipo de rendimiento en memoria o
CPU alcanza ciertos niveles, etc.
En la configuración del DRS podemos elegir como queremos que funcione la migración. Si
queremos que sea manual (es decir, que nosotros la ejecutemos). Si queremos que sea a base
de recomendaciones (Partially automated), con lo que el propio DRS nos avisará de que
máquinas deberían migrarse (según recomienda la propia función).
Y por último que se migren automáticamente cuando los recursos de los hosts lo necesiten.
Además, podemos hacer que la migración sea “Agresiva” en un nivel máximo. En cuanto vea
que es necesaria dicho cambio, lo haga sin dudar.

78
También tenemos la configuración DPM, que aunque no la hemos utilizado sirve para
optimizar los recursos físicos. Con esta opción podemos reducir un porcentaje importante de
energía para evitar el alto consumo de tantas máquinas iniciadas.
Reglas
La gran función que tiene DRS es que puedes agregar una serie de reglas y personalizar como
trabajarán tus hosts y tus máquinas virtuales. También nos permite agrupar una serie de
máquinas o hosts en un mismo grupo definido, esto nos simplifica el trabajo y si queremos
añadir una regla a unas cuantas máquinas, no tendrás que hacerlo una a una.
En la imagen podemos apreciar cómo se han creado dos grupos. Uno llamado Windows y otro
Linux. En cada uno se les ha insertado las máquinas virtuales respectivas de sus sistemas
operativos.
De la misma forma nos deja agrupar los hosts.

79
Aquí podemos ver, si seleccionamos el grupo “Windows” podremos seleccionar que máquinas
pertenecerán a ese grupo.
Después de la agrupación, ya podemos definir las reglas y ahorrarnos ese trabajo mencionado.
Esta regla específicamente trabaja para que las máquinas virtuales dentro del grupo “Linux”
se inicien automáticamente en el host ESX2. Como dice la regla “Should run on hosts in
group”. Cuando se inicia el servicio de vCenter y arrancamos los hosts, podemos apreciar
como cada máquina irá al destinatario correcto.

80
Por lo tanto, las reglas quedarían así:
- Las máquinas Windows en el host ESX1.
- Las máquinas Linux en el host ESX2.

81
Otra forma de agregar reglas es añadiendo Alarmas.
De esta forma podemos indicar una serie de acciones que pueden hacer las máquinas
dependiendo del “motivo” que tenga para hacerlo.
Es decir, podemos agregarle la opción de que si la CPU llega al 70% en cualquier máquina
virtual, entonces, esa máquina deberá migrarse automáticamente al otro host. De esta
manera evitamos que uno de los hosts esté con una alta carga de recursos y así podamos
igualar los dos para trabajar de una mejor forma.
Por ejemplo, añadimos una Alarma donde la condición sea que cuando la CPU supere el 30%
de rendimiento nos avise con un “Warning”

82
Entonces, una vez avisado, tomará la acción que le indicaremos. La acción tomada será
“Migrate VM” (utilizando vMotion). Le indicaremos que el host donde debe migrarse las
máquinas será el 192.168.1.41 (por ejemplo).
Y en la lista de tareas y resultados podemos ver como automáticamente hace esta migración,
sin tocar nada:
Pequeño estudio de Mercado
No solo VMware dispone de la tecnología DRS, otras marcas también tienen funciones
similares.
Es el caso de Hyper-V y su llamado “Dynamic Optimization”. El estilo es similar al DRS, ya
que Dynamic Optimization utiliza el Vmotion en las máquinas virtuales que están dentro de un
clúster para mejorar el equilibrio de carga entre los hosts. Pueden ser migradas con una
frecuencia y agresividad que tú específicas y por defecto cada 10 minutos se migrarán dichas
máquinas con la opción "Agresiva".
Si un grupo de hosts contiene independientes anfitriones, los clústeres de hosts que no
soportarán la migración en vivo, o el modo de mantenimiento. Dynamic Optimization no se
llevará a cabo en estos equipos.
Si un clúster de hosts contiene máquinas virtuales sin alta disponibilidad, las máquinas
virtuales no harán este proceso de migración.
También RedHat con su versión RHEV-M 3.3 presenta como nueva tecnología este tipo de
función. Incluye un nuevo planificador para manejar la colocación de la máquina virtual, lo
que permite a los usuarios crear nuevas políticas de planificación, y también escribir su propia
lógica en Python e incluirlo en una política. El nuevo planificador sirve solicitudes de
programación para ejecutar o migrar máquinas virtuales. La planificación se lleva a cabo

83
mediante la aplicación de restricciones "agresivas" y restricciones "blandas" para conseguir el
anfitrión óptimo para esa solicitud en un punto dado del tiempo.
IBM con PowerVM 2.2 también cuenta con este tipo de migración por balanceo llamadas
"FSM" o "VMControl". Son herramientas opcionales que vienen con el producto y utiliza reglas
para la reubicación y automización de los hosts dentro de un grupo de servidores.
Anteriormente Citrix XenServer también utilizaba una opción de balanceo de carga, pero a
partir de la versión 6.2 se suprimió. Los motivos aparentemente son porque los clientes que
utilizan XenServer no han utilizado esta opción y los porcentajes han sido bastante bajos en
cuanto a "adopción" del producto.
Problemas y preguntas frecuentes
¿Qué ocurre si quitamos un host del Cluster?
Si tenemos Manual o Partially Automated nos mostrará sus recomendaciones, si tenemos
configurado Fully Automated las VMs seran migradas a otros hosts.
¿Qué ocurre si ponemos un host en Maintenance Mode?
Las operaciones en dicho host se restringen automáticamente: No se pueden encender nuevas
VMs dicho host y no se pueden migrar VMs a dicho host.
El administrador deberá apagar las VMs o migrarlas a otras (se recomendara) y posteriormente
apagar el host.
(El host marcado como en mantenimiento no será tenido en cuenta para HA)
¿Qué ocurre si se cae el Virtual Center Server?
Los hosts seguirán corriendo usando los recursos disponibles pero no habra recomendaciones
para optimización de recursos.
A tener en cuenta una serie de características:
 DRS es proactivo, actúa para balancear y no provoca downtime (tiempo inactivo). No
confundir con VMware HA que es reactivo: actúa cuando se ha caído un host y si tiene
downtime de las VMs.

84
Monitorización:
La monitorización del Clúster se puede realizar a través del propio Virtual Center.
 Un clúster sin ningún color en particular nos indica que todo está correctamente.
 Un clúster de color amarillo (Overcommitedor Host down) indica que algún
requerimiento de recursos no está siendo satisfecho por el cluster. Solución: aumentar
recursos o decrementarreservations.
 Un clúster de color rojo nos indica que el clúster está inconsistente o es invalido
Errores de DRS
 No se puede encender una VM aunque tenga de reservation menos que la capacidad
sin reservar del resource pool.
Causa: El host tiene que tener suficiente Aggregateunreservedcapacity y Per-corecapacity.
Solución: Establecer en los hosts esta opcion de
configuracionCpu/VMAdmitCheckPerVcpuMinto 0 (OJO: notrecommended)
Errores de VMotion:
 Relación de clúster entre VMs (MSCS)
 La VM tiene afinidad a una CPU fisica:
Solución: Quitar la VM del cluster, quitar la afinidad y volver a meter al clúster DRS.
 La VM tiene conectado el CD-ROM / floppy
Alertas de VMotion:
 La VM está configurada a un virtual switch interno pero no está conectada a él.
 La VM está configurada para acceder al CD-ROM/floppy pero NO está conectada a él.

85
9. Storage DRS
Storage DRS equilibra continuamente la utilización del espacio y la carga de E/S del
almacenamiento. Al mismo tiempo, evita los cuellos de botella de los recursos para respetar
los niveles de servicio de las aplicaciones. El uso de DRS le permite una serie de ventajas:
 Implementar e integrar capacidad de almacenamiento adicional en un pool de
almacenamiento.
 Sacar partido de la nueva capacidad.
 Mejorar los niveles de servicio para todas las aplicaciones.
 Aumentar la productividad de los administradores de VMware vSphere permitiéndoles
supervisar y gestionar la infraestructura adicional.
vSphere 5 introduce el concepto de cluster de datastore. Un cluster de almacenamiento es,
desde la perspectiva de un administrador, un conjunto de discos (datastores) agregados en
una única unidad. Cuando se crea un cluster de este tipo, Storage DRS puede administrar los
recursos de almacenamiento de igual manera a como hace DRS a nivel de procesamiento para
un cluster de hosts, balanceando la carga entre los discos disponibles en el cluster.
Hay que saber diferenciar entre:
 Datastore Cluster sin SDRS activado: solo es un grupo de datastores.
 Datastore Cluster con SDRS activado: Balanceo de cargas y espacio.

86
¿Qué operaciones realiza SDRS?
Un cluster de SDRS realiza las siguientes operaciones:
Colocación inicial. En el momento que nosotros creemos una nueva máquina virtual,
estaremos seleccionando un datastore cluster en vez de seleccionar un datastore tradicional,
con esto, le permitiremos a SDRS tomar en cuenta el histórico de latencia que se tiene de los
datastores que componen dicho cluster (estaremos hablando de como se obtiene más
adelante) y el espacio disponible.
Por defecto, colocarán todos los archivos de una máquina en un mismo datastore aunque esto
puede ser modificado con reglas de afinidad y anti afinidad entre las máquinas, en este punto
será el primer beneficio que SDRS nos entrega, permitiendo colocar las máquinas en el
datastore con mejores características.
Balanceo de Carga. Una vez que las máquinas virtuales sean colocadas en los datastores que
conforman dicho cluster, se comenzará a recolectar estadísticas de latencia en cada uno de
los datastores que conforman dicho datastore cluster, hasta después de 16 horas de capturar
estadísticas se comienza con el balanceo de cargas a nivel de I/O.
En el caso de que se esté ejecutando alguna operación de Storage VMotion la captura de
estadísticas no comienza ya que este tipo de operaciones alteran bastante el comportamiento
de nuestro almacenamiento, por lo cual, puede tardar más de 16 horas en comenzar el
balanceo.
Las recomendaciones dadas por SDRS se
basarán en 2 tresholds modificables, el
espacio libre y la latencia a disco, en el
caso de latencia a disco se tiene un valor
por defecto de 15 ms, al igual que DRS,
estas se aplicarán o no según el nivel de
automatización que se tenga en dicho
datastore cluster.
Las estadísticas de latencia son obtenidas
cada 30 minutos y se analizan las cargas
en periodos de 8 horas, por lo cual se
tiene un histórico, y en el momento de
realizar las recomendaciones se tomará
en cuenta si estas nos entregarán un
beneficio por lo menos 24 horas de lo
contrario no se aplicarán. Solo en el
momento que se exceden los valores
definidos es cuando comienza el balanceo.

87
Cuando el rendimiento de un disco está llegando al máximo, utiliza la función DRS, que ligada
al almacenamiento nos permite migrar todo el contenido de una máquina virtual (eso significa
la carpeta y todos los archivos) hacia otro disco.
En Storage DRS podemos encontrar dos puntos muy importantes para la utilización del mismo,
ofreciendo la comodidad del servicio.
Supervisión continúa
Storage DRS supervisa el espacio de almacenamiento y la utilización de E/S en un almacén de
datos preasignado. Además, coordina los recursos de almacenamiento para cubrir sus
necesidades de crecimiento empresarial. La supervisión de Storage DRS le permite:
 Especificar cómo se asignan los recursos de almacenamiento a las máquinas virtuales,
mediante reglas y políticas.
 Asignar infraestructura de almacenamiento dedicada a las unidades de negocio, e
incrementar el índice de utilización del almacenamiento mediante grupos de
volúmenes de almacenamiento.
 Capacitar a las unidades de negocio para que creen y gestionen máquinas virtuales
dentro de sus grupos de almacenamiento y, al mismo tiempo, brindar al equipo de TI
el control centralizado de todos estos recursos.
Mantenimiento sin interrupciones
Cuando un administrador de vSphere coloca en modo de mantenimiento un clúster de
almacenes de datos habilitado para Storage DRS, este último mueve los archivos de disco de
las máquinas virtuales a otro almacén de datos. Un almacén de datos permanece en el estado

88
de transición al modo de mantenimiento hasta que todos los discos virtuales se han movido a
otros almacenes de datos del clúster. Storage DRS presenta también las siguientes
funcionalidades:
 Recomendaciones de colocación para la migración de discos virtuales.
 Una lista de errores que muestra los archivos de disco de las máquinas virtuales que no
se pueden mover y los motivos de ello.
Hay que tener en cuenta que Storage DRS utiliza y se aprovecha de las tecnologías DRS y
vMotion. Cuando el DRS se activa por el uso drástico de los discos, empieza la migración. Y
dicho movimiento se realiza gracias a vMotion. Todo ligado hace el uso de Storage DRS, el
cuál no hay que confundir con Storage vMotion, ya que éste se hace manualmente o con la
utilización de un Clúster HA.
Gracias a Storage DRS podemos tener un equilibrio continúo.
Es decir, Storage DRS toma decisiones con Storage vMotion para reducir la latencia de E/S y
garantizar un rendimiento óptimo de todas las máquinas virtuales.
Reglas de afinidad
Como método opcional se pueden definir una serie de reglas de afinidad y anti-finadad para
los archivos de los discos de las máquinas virtuales (llamados VMDK).
De forma predeterminada, los archivos de disco de las máquinas se guardan en el mismo
almacén de datos, pero Storage DRS te permite:
 Afinidad de VMDK (opción predeterminada): los discos virtuales de una máquina
virtual se mantienen juntos en el mismo almacén de datos.
 Anti-afinidad de VMDK: en una máquina virtual que tiene varios discos virtuales, estos
últimos se colocan en almacenes de datos diferentes.
 Anti-afinidad de máquina virtual: dos máquinas virtuales concretas, incluidos sus
discos asociados, se colocan en almacenes de datos diferentes.

89
La correlación de almacenes de datos es un mecanismo avanzado de equilibrio de la carga de
E/S incluido en Storage DRS. Detecta si dos almacenes de datos diferentes están usando el
mismo grupo de discos físicos de una matriz. Cuando esto sucede, aplica las reglas de afinidad
y mueve los archivos de disco de las máquinas virtuales para mitigar los cuellos de botella de
E/S.
Por ejemplo, se puede definir que dos máquinas virtuales estén separadas y en diferentes
almacenes de datos:
Estadísticas
La latencia medida por SDRS no es en tiempo real, esta es tomada a partir de datos históricos,
por ejemplo, si el día anterior se tuvo latencias mayores a 15 ms el 94% del tiempo se
considera que dicho datastore está sobre cargado. Algo interesante es que podemos definir
ventanas de tiempo para que estas no sean consideradas en los históricos de SDRS, esto nos
hace mucho sentido si
tenemos ventanas
definidas de anti-virus:

90
10. Fault Tolerance
VMware Fault Tolerance es un componente de VMware vSphere que proporciona una
disponibilidad continua de las aplicaciones mediante la prevención de tiempo de inactividad y
la pérdida de datos de máquinas virtuales en caso de fallas en el servidor ESX.
Fault Tolerance permite que una máquina virtual, esté en Activo/Pasivo en sendos hosts.
Básicamente se duplica el fichero de memoria RAM y se accede a la vez a las máquinas
virtuales por dos hosts ESX, siendo uno el Activo, el que atiende las peticiones de los usuarios
y quedando el otro en pasivo y no escuchando peticiones de usuario.
Entonces, si una máquina virtual está en Fault Tolerance y el host ESX que la soporta cae, el
otro host ESX que está en modo pasivo, entra automáticamente en modo activo y empieza a
escuchar peticiones, pudiendo haber pérdida de algún ping pero no del servicio.
Adicionalmente Fault Tolerance busca otro host ESX con suficientes recursos y lo configura
como pasivo para que la VM siga estando en Fault Tolerance.
La máquina virtual no se duplica, esto es, es una sola entidad con una IP y un hostname y
todas sus características internas añadidas. Pensemos que podemos tener en Fault Tolerance
un Windows XP, un Linux o un Solaris 10x64, por poner algunos ejemplos.
La función Fault Tolerance (FT) proporciona disponibilidad continua para las aplicaciones en
caso de fallos del servido al crear una instancia duplicada en tiempo real de una máquina
virtual que siempre está sincronizada con la principal. En caso de interrupción del hardware,
la función FT activa automáticamente la conmutación por error, garantizando el tiempo de
inactividad cero y evitando la pérdida de datos.
Tras la conmutación por error, la función FT crea automáticamente una nueva máquina
virtual secundaria con el fin de proporcionar protección continua a la aplicación.
La función FT protege cualquier máquina virtual, incluso las aplicaciones internas y
personalizadas que los productos de alta disponibilidad tradicionales no pueden proteger.
Algunas de las funciones de FT son las siguientes:
 Es compatible con cualquier tipo de almacenamiento compartido, incluido
FibreChannel, iSCSI, FCoE y NAS.
 Es compatible con todos los sistemas operativos admitidos por vSphere.
 Funciona con clústeres DRS o HA.
 Contiene un mecanismo de control de versiones que permite que las máquinas
virtuales principal y secundaria se ejecuten en hosts que admitan la función FT con
niveles de parches distintos, pero compatibles.

91
Requisitos
Para que Fault Tolerance funcione son necesarios una serie de requisitos:
1. VMware FT está disponible después de versiones de vSphereAdvanced versión
(Advanced, Enterprise, Enterprise Plus).
2. Hardware virtualización debe estar activado en el BIOS.
3. CPU debe ser compatible con el FT.
4. Activar las máquinas virtuales que se deben colocar en el almacenamiento compartido
(FC, iSCSI o NFS).
5. Las máquinas virtuales se deben colocar en un DRS/HA Cluster.
6. FT no se puede utilizar con DRS en vSphere 4.0 FT pero está totalmente integrado
apartir de DRS de vSphere 4.1.
7. A partir de vSphere 4.0, ESX primaria y secundaria debe tener la misma versión de
ESX. Esta limitación no ocurre en vSphere 4.1 o más.
8. Sólo se permiten 4 máquinas virtuales por ESX / ESXi.
9. VMotion y FT Logging deben estar habilitadas en la red VMKernel de la máquina virtual
(NIC separada para vMotion y FT registro está recomendando junto con la agrupación
de NIC).
10. La comprobación de certificado de host debe estar habilitado (activado por defecto).
11. Tarjeta Ethrenet 10 GB entre servidores ESX dará mejores resultados de rendimiento.
12. Puertos FT 8100, 8200 (TCP saliente, UDP entrante y saliente) debe estar abierto si
existe cualquier firewall entre los servidores ESX.
13. Mínimo de 3 hosts en clúster DRS/HA habilitado es el requisito para el funcionamiento
de FT protegida con máquinas virtuales.
14. Máquinas virtuales FT no se pueden copiar utilizando la tecnología de copia de
seguridad como (VCB, recuperación de datos de VMware), que utiliza la función de
instantáneas.
15. NPIV (N-portid Virtualización) no es compatible con VMware FT

92
16. Usar redundancia en todas las capas (como la agrupación de NIC, múltiples switches de
red y de almacenamiento multiruta) para aprovechar al máximo las características de
FT.
17. Clusters MSCS no son compatibles con VMwareFaultTolerance.
18. En vSphere 4.0, se permite vmotion Manual, pero el equilibrio de carga automático
utilizando VMotion por DRS es totalmente compatible a partir de vSphere 4.1.
Diagrama
En esta imagen se puede apreciar como el Cliente se conecta a una máquina virtual, en la
cual tiene todos sus datos (que los está recibiendo de los discos en la nube).
El usuario puede estar trabajando tranquilamente y no darse cuenta de la caída de su
servicio. El Fault Tolerance es cuando actúa en este momento, cuando se cae el host con la
máquina virtual dentro, automáticamente el segundo host (el cual ha estado en modo pasivo
esperando algún tipo de problema del primario) se activa y responde a la caída.
El host primario activa vMotion y pasa todas las máquinas que tenga en ese host caído al otro
host (secundario). Una vez se ha realizado dicha tarea, el host secundario se convierte en el
primario y actúa de la misma forma de como lo hacía con anterioridad el otro host.
De esta forma, los usuarios pueden seguir trabajando como si no hubiera pasado nada.

93
Aquí podemos apreciar el movimiento que hace el host primario hacia el host secundario de la
máquina virtual:
A pesar de ambas máquinas virtuales primarias y secundarias aparecen como una sola entidad
y acceden a un disco común, ambas corren con una única dirección IP, dirección MAC, pero
las escrituras sólo se llevan a cabo por las máquinas virtuales primarias. Las máquinas
virtuales primarias y secundarias envían entre cada latidootra frecuencia con intervalos de
milisegundos a la comprobación de la disponibilidad. Si alguna de las máquinas virtuales
pierde dicho latido, otra máquina se hará cargo del rol de máquina virtual primario
inmediatamente.

94
¿Qué sucede cuando se ha activado la tolerancia de fallos en la máquina virtual?
Cuando se habilita la tolerancia a fallos de la máquina virtual, la secundaria será creada para
trabajar con la máquina virtual primaria en el que se ha habilitado FT. La máquina virtual
primaria y secundaria residen en un hosts diferentes del clúster.
¿Qué sucederá cuando el host ESX de VM primaria caiga?
Cuando se detecta un fallo en el host ESX primaria, la máquina virtual secundaria (que se
ejecuta en el servidor ESX, pero en otro host) toma el lugar de la primera con la menor
interrupción posible del servicio.
¿Si vCenter no está disponible, podrá ejecutarse FaultTolerance?
El servidor vCenter sólo es necesario para permitir que Fault Tolerance esté configurado en la
máquina virtual. vCenter no está obligado a estar en línea para que Fault Tolerance funcione.
La conmutación por error entre primaria y secundaria volverá a aparecer incluso si el vCenter
está caído.
¿En qué se diferencian VMware FT y VMware HA/DRS?
1. VMware HA/DRS es un Cluster y FT es una característica para máquinas virtuales.
2. En caso de que ocurra un fallo en el host ESX, las máquinas virtuales que estén dentro
del host son reiniciadas y se cargan/mueven en los otros hosts activos del cluster.La
duración del reinicio de las máquinas virtuales es el "downtime" (tiempo de
inactividad) de dichas máquinas en el Cluster HA/DRS.
En cambio, en Fault Tolerance no hay este downtime (tiempo de inactividad).
Si uno de los hosts falla, vMotion hará que la secundaria se convierte en primaria y
continúe ejecutando los servicios donde la primera se quedó antes de fallar. Esto se
produce automáticamente sin perder los datos, sin tiempo de inactividad y con un
pequeño delay (retraso), pero que los usuarios no verán ningún tipo de interrupción.

95
Configuración
A la hora de realizar la configuración para Fault Tolerance necesitamos una red más, que
conecte ambos ESXi.
Creamos la tarjeta de red en la opciones de ESXi. Añadimos dicha red a vSphere (en ambos
hosts).
El primer paso es habilitar el registro de tolerancia a fallos en un puerto VMkernel, en todos
los hosts en la que se quieran tener las máquinas protegidas. Una vez más, la alta
disponibilidad dictan un puerto VMkernal dedicado en una tarjeta de red dedicada (aunque
esto no es un requisito estricto).
Hay que seleccionar la opcion “use this port group for Fault Tolerance logging”.
Y debería quedar una tarjeta de red solo para FT en una nueva red.
Durante el proceso de comprobación de Fault Tolerance tuvimos problemas de
compatabilidades. Algunas máquinas necesitaban agregar una serie de condiciones o reglas
avanzadas para poder iniciarse y permitirse la función FT.

96
Estas tres opciones tienen que estar habilitadas:
 replay.supported = “true”
 replay.allowFT = “true”
 replay.allowBTOnly = “true”
Básicamente estas reglas significan que Fault Tolerance está habilitado y nos permite seguir
trabajando.

97
El siguiente paso es encender la opción en la máquina virtual:
Las opciones de Fault Tolerance son las siguientes:
 Disable Fault Tolerance – en el caso que nosotros quisiéramos solo deshabilitar
temporalmente FT debemos utilizar esta opción, ya que se conserva la VM secundaria,
la configuración y el historial de las VMs.
 Turn off Fault Tolerance – en este caso se eliminan las VMs secundarias y toda
configuración de las mismas.
 Migrate Secondary – con esta opción podemos migrar de host nuestra VM secundaria.
 Test Failover – con esta opción se realiza un failover de nuestra VM principal a la
secundaria, y se creará nuevamente una VM secundaria en algún otro host del cluster.
 Test Restart Secondary – con esta opción la VM secundaria se reinicia, con lo cual
podemos verificar la consistencia entre la secundaria y primaria.

98
En la primera ocasión tarda un poco en procesarse, pero luego ya tendremos FT rápido y sin
problemas:
La imagen nos muestra como se ha creado la máquina XP2 “secondary” en el segundo host
(192.168.1.41). Mientras la primaria sigue donde estaba (192.168.1.40).
Una vez iniciemos las máquinas, deberíamos ver las dos pantallazas y como la secundaria es
una réplica remota de la primaria:

99
Una vez se apague el host primario, el secundaria hará el proceso Fault Tolerance para
convertirse en primario, como ya hemos explicado más arriba.
Limitaciones
Aunque Fault Tolerance es una gran función, lamentablemente también tiene una serie de
limitaciones que no permiten disfrutar al máximo de este tipo de posibilidades.
 Las instantáneas se deben quitar antes de FT se puede habilitar en una máquina
virtual. Además, no es posible tomar instantáneas de máquinas virtuales en el que FT
está habilitado.
 N_Port ID Virtualization (NPIV) no es compatible con el FT. Para usar el FT con una
máquina virtual debe desactivar la configuración NPIV.
 Adaptadores paravirtualizados no son compatibles con el FT.
 RDM física no es compatible con el FT. Solo se pueden usar RDM virtuales.
 FT no se admite con las máquinas virtuales que tienen CD-ROM o dispositivos virtuales
de disquete conectado a un dispositivo físico o remoto. Para usar el FT con una
máquina virtual con este problema, quite el CD-ROM o dispositivo virtual floppy o
volver a configurar el respaldo con un ISO instalado en el almacenamiento compartido.
 La función de conexión se desactiva automáticamente por culpa de las VMs con Fault
Tolerance. Para los dispositivos de conexión en caliente (cuando ya sea agregando o
quitando ellos), se debe apagar momentáneamente FT, realizar la conexión en
caliente, y luego poner FT de nuevo.
 EPT / RVI se desactiva automáticamente para máquinas virtuales con FT activado.
 IPv6 no es compatible; debe utilizar direcciones IPv4 con FT.
 Sólo se puede utilizar FT en un vCenter Server que se ejecuta como una máquina
virtual si se está ejecutando con una sola CPU virtual.
 VMotion se admite en habilitado para FT máquinas virtuales, pero no puedes VMotion
las máquinas virtuales tanto primarias como secundarias al mismo tiempo. SVMotion no
se admite en habilitado para FT VMs.

100
 A partir de vSphere 4.1, se puede utilizar el FT con DRS cuando la función está
activada EVC. DRS llevará a cabo la colocación inicial en habilitado para FT máquinas
virtuales, y también incluirá en los cálculos de equilibrio de carga del cluster. Si EVC
en el clúster está deshabilitado, los fabricantes de vehículos habilitados para FT se les
da un nivel de automatización DRS de "discapacitado". Cuando una máquina virtual
primaria está encendida, la máquina secundaria se coloca de forma automática, y
tampoco VM se mueve con fines de equilibrio de carga.
Para comprobar que todo nuestro sistema (Datacenter, Cluster, Hosts y máquinas virtuales)
cumplen los requisitos necesarios para el Fault Tolerance, VMware ofrece una herramienta
llamada "Perfil Cumplimiento vCenter Server".
Para acceder al uso de este método sólo tienes que seleccionar el clúster en el panel
izquierdo de vSphere Client y, a continuación, en el panel derecho, seleccione la ficha Perfil
de Cumplimiento.
VMware recomienda no utilizar FT con mezclas entre ESX y ESXi. Esto básicamente es por
temas de compatabilidad.
Una vez se cumplan los requisitos, Fault Tolerance es sencillo y solo se tiene que utilizar con
los pasos descritos más arriba.
Consideraciones
 VMware pasó mucho tiempo trabajando con Intel y AMD para refinar sus procesadores
físicos para que VMware pudiera implementar su tecnología vLockstep, que replica las
transacciones no deterministas entre los procesadores mediante la reproducción de sus
instrucciones de la CPU. Todos los datos se sincronizan, lo que no hay pérdida de datos
o transacciones entre los dos sistemas. En caso de un fallo de hardware, es posible que
tenga un paquete IP transmitido, pero no hay ninguna interrupción en el servicio o la
pérdida de datos, ya que la VMs secundarias siempre pueden reproducirse en la
ejecución de la máquina virtual primaria hasta su última salida.
 FT no utiliza una característica específica de la CPU, pero requiere que las familias
específicas de la CPU para funcionar. vLockstep es más de una solución de software
que se basa en algunas de las funciones de base de los procesadores. El nivel de
software registra las instrucciones de la CPU en el nivel de máquina virtual y se basa
en el procesador para hacerlo, tiene que ser muy preciso en términos de tiempo y
VMware necesitaba los procesadores para ser modificados por Intel y AMD para
asegurar la exactitud completa. La utilidad SiteSurvey simplemente se ve en ciertos
modelos de CPU y las familias, pero las características no específicas de la CPU, para
determinar si una CPU es compatible con FT. En el futuro, VMware podrá actualizar su
utilidad CPU ID reportar también si la CPU es FT-capaz.

101
 En el caso de escenarios de cerebro dividido (es decir, pérdida de conectividad de la
red entre los hosts), la máquina virtual secundaria puede tratar de convertirse en la
principal, resultando en dos primarias que se ejecutan al mismo tiempo. Esto se evita
mediante el uso de un bloqueo en un archivo de FT especial, una vez que se detecta
un fallo, tanto máquinas virtuales tratará de cambiar el nombre de este archivo, y si
tiene éxito la secundaria se convierte en el primario y engendra una nueva secundaria.
Si falla la secundaria es porque el principal sigue funcionando y ya tiene el archivo
bloqueado, la VM secundaria es “asesinado” y una nueva secundaria se genera en otro
host.
 No hay límite en el número de hosts habilitados para FT en un clúster, pero no se
puede tener grupos que abarquen VMs compatibles con FT. Una versión futura puede
apoyar a las agrupaciones que abarcan VM compatibles con FT.
 Existe una API para FT que proporciona la capacidad de scripts ciertas acciones, por
ejemplo, deshabilitar / habilitar FT utilizando PowerShell.
 Hay un límite de cuatro máquinas virtuales habilitadas para FT por host (no por
grupo); esto no es un límite obligado, pero se recomienda para un rendimiento
óptimo.
 La versión actual de FT está diseñada para ser utilizado entre los hosts en el mismo
centro de datos, y no está diseñado para trabajar a través de enlaces WAN entre los
centros de datos debido a los problemas de latencia y las complicaciones de
conmutación por error entre sitios. Las futuras versiones pueden ser diseñados para
permitir el uso de FT entre los centros de datos externos.
 Hay que tener en cuenta que la máquina secundaria puede ralentizar la primaria si no
está recibiendo suficientes recursos de la CPU para mantenerse al día. Esto se nota por
un lapso de tiempo de varios segundos o más. Para resolver esto, hay que ajustarla a
una reserva de la CPU en la máquina primaria, que también se aplica a la máquina
secundaria y se asegurará de que tanto las máquinas virtuales se ejecuten a la misma
velocidad de la CPU. Si la VM secundaria se ralentiza hasta el punto que está
afectando gravemente el desempeño de la primaria, FT hace que se cierre y se cree
una nueva secundaria en otro host.
 FT puede activarse y desactivarse fácilmente en cualquier momento, a menudo esto es
necesario cuando se necesita para hacer algo que no se admite cuando se utiliza FT,
tales como SVMotion, instantánea o hot-add de hardware a la máquina virtual.
Además, si hay períodos de tiempo específicos cuando la disponibilidad de la máquina
es crítica, como cuando un proceso mensual se está ejecutando, puede habilitarlo
para ese período de tiempo para asegurarse de que se mantiene mientras el proceso

102
está en marcha, y desactivarlo después.
 Cuando FT está habilitado, los límites de memoria de la máquina virtual de primaria
serán eliminados y una reserva de memoria se establecerán igual a la cantidad de
memoria RAM asignada a la máquina virtual. Después no se podrán cambiar los límites
de memoria, acciones, o reservas en la máquina primaria mientras que FT está
habilitada.

103
11. Conclusión del Proyecto
Ha sido un proyecto bastante gratificante de hacer. Gracias a las funcionalidades que ofrece
VMware hemos aprendido muchas tecnologías y opciones que no sabíamos que existían en el
mundo de la virtualización.
Por ejemplo, la utilización de DRS es bastante importante para una empresa. Conocíamos de su
existencia, pero no como funcionaba realmente. Gracias a una profunda investigación y puesta
práctica, sabemos que si una Empresa de alto nivel quiere tener una alta disponibilidad
necesitará tener un DRS implementado, para así evitar que los hosts lleguen a sus máximos y
acaben bloqueándose.
No sabíamos que podíamos personalizar tan ampliamente la opción DRS. Añadiendo una serie
de reglas y alarmas puedes administrar perfectamente el rendimiento de todo tu hardware.
Otra opción, la cual desconocíamos era Fault Tolerance. Sin duda un gran "avance" para el
mundo de la virtualización y hospedaje de máquinas dentro de servidores. Esta opción también
nos permite una alta disponibilidad máxima. Gracias a Fault Tolerance podemos evitar
desastres, por ejemplo, si un host se cae y tenemos Fault Tolerance activado en dicha
máquina, automáticamente podremos acceder a la máquina sin ningún problema. Es decir, el
usuario normal y corriente puede seguir trabajando sin ningún problema y sin conocer de este
problema, ya que no existe un tiempo de inactividad como sí presentan otras opciones como HA
con vMotion.
Pero todavía hay más, Fault Tolerance es una tecnología que puede engrandecerse más y
mejorar. Solo VMware dispone de esta opción, las otras grandes empresas de virtualización
como Hyper-V o Citrix no cuentan con algo similar. Sin duda lo más destacable es que Fault
Tolerance puede evolucionar mucho más, todavía tiene alguna serie de limitaciones que serán
arregladas en futuras versiones.
En este proyecto hemos podido trabajar con una infraestructura real. Con dos ESXi instalados,
más dos núcleos de almacenamiento (FreeNAS) y el panel de administración desde vCenter y
vSphere Client nos ha permitido trabajar cómodamente. Las opciones que presenta vSphere son
muy intuitivas y puedes administrar todo el montaje sin problemas.
Para reunir toda la información y datos hemos buscado muchísima información por Internet. En
algunas ocasiones no encontrábamos nada y nos hemos puesto en contacto con expertos en
VMware y hemos visitado los Foros oficiales para llegar a obtener esa información poco
documentada por la red.
El tipo de proceso utilizado para la recopilación de datos ha sido conocer con que estábamos
trabajando, buscar ejemplos (vídeos, imágenes), implementarlo y probarlo en vSphere y por
último documentarlo.

104
Nos hubiera gustado seguir avanzando en este proyecto. Creemos que todavía se puede
investigar e implementar más opciones de vSphere, ya que es un mundo muy amplio en cuanto
a virtualización, pero lamentablemente el tiempo no fue el suficiente, además de un
inconveniente inicial, ya que este no era nuestro proyecto pensado en primer momento y
decidimos cambiar. Una decisión que nos alegramos de haber tomado, ya que con vSphere y sus
demás complementos hemos aprendido cómo se maneja un mundo de virtualización.
La única limitación y "pero" que le pondríamos al proyecto es la falta de recursos que hemos
tenido. En muchas ocasiones, cuando administrábamos vSphere Client hemos tenido problemas
de funcionalidades a causa del hardware, el cual era un poco limitado.
Los PCs utilizados para los hosts no están orientados para trabajar con una infraestructura ESXi,
físicamente hubiéramos necesitado una mayor capacidad. Hay que tener en cuenta que
nosotros hemos virtualizado un hypervisor, cuando éstos deben ya estar instalados en el propio
servidor físico, en cambio nosotros hemos tenido "la barrera" de un sistema operativo por
encima y luego emularlo con VMware. Eso ha reducido la dedicación total hacia el servidor.
También destacar que durante el trabajo con vSphere, nos saltaban muchas alertas de CPU.
Disponíamos de dos Intel i3, quizás con un poco más (un i5) no habríamos tenido estas alertas
un poco molestas, ya que en algunas situaciones no nos dejaba trabajar por la limitación de un
host (por ejemplo, se ponía a 100% de CPU con 2 máquinas virtuales con Fault Tolerance).
A pesar de todo eso, no ha supuesto un impedimento para seguir trabajando e investigando.
Sabemos que en cualquier empresa existen problemas, errores u obstáculos para el trabajo
diario. Eso nos ha ayudado a tener más paciencia, a seguir buscando hasta encontrar una
solución práctica.

105
12. Webgrafía
VMware página:
http://www.vmware.com/es/products/vsphere/features.html
DRS:
http://www.vmware.com/es/products/vsphere/features/drs-dpm.html
https://www.youtube.com/watch?v=US0bGHtiISc
https://www.youtube.com/watch?v=gATLj6pUxnk
Storage DRS
https://www.youtube.com/watch?v=z77xmaxoNec
Fault Tolerance
http://www.youtube.com/watch?v=zoi9gdy-Ceg
http://www.josemariagonzalez.es/2009/06/11/prueba-tu-mismo-vsphere-vmware-fault-
tolerance.html
Dudas, requisitos y cosas de FT:
http://www.vmwarearena.com/2012/08/vmware-interview-questions-answers.html
Mucha información sobre vMware:
http://www.josemariagonzalez.es/
Reglas DRS y explicación DPM:
http://blog.hispavirt.com/tag/drs/
Advanced Rules DRS:
http://www.virtuallyghetto.com/2011/07/new-vsphere-5-ha-drs-and-sdrs.html
Storage DRS:
http://www.yellow-bricks.com/2011/07/12/vsphere-5-0-storage-drs-introduction/
Más virtualización:
http://www.ideasmultiples.com/imvps/virtualizacion.php
http://centrodeartigos.com/articulos-noticias-consejos/article_126331.html
Virtualización Bare-Metal:
http://blog.virtualizamos.es/tag/bare-metal/
vSphere Client vs Web
http://federicocinalli.com/blog/item/119-vsphere-client-vs-vsphere-web-
client#.U4Wae_l_uBo

106
Reglas Storage DRS:
http://blog.hispavirt.com/2011/08/27/vsphere-5-%E2%80%93-sdrs-%C2%A1drs-para-nuestro-
almacenamiento/
Problema con HA:
http://geekswing.com/geek/vmware-cpu-and-ram-reservations-fixing-insufficient-resources-
to-satisfy-configured-failover-level-for-ha/
Problema FT:
http://www.virtuallyghetto.com/2011/07/how-to-enable-nested-vft-virtual-fault.html

Implementacion de una infraestructura en VMware 5.5

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Implementacion de una infraestructura en VMware 5.5

Más de Vellidin

Implementacion de una infraestructura en VMware 5.5