Escolar Documentos
Profissional Documentos
Cultura Documentos
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
VIRTUALIZACIÓN ASIX2
1. Introducció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.
1
VIRTUALIZACIÓN ASIX2
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
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.
2
VIRTUALIZACIÓN ASIX2
É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.
- Abstraen los recursos físicos de la máquina anfitriona para las distintas máquinas
virtuales.
3
VIRTUALIZACIÓN ASIX2
- Algunos ejemplos como: Xen, Citrix, XenServer, KVM, VMware ESX/ESXi, Microsoft Hyper-V.
- Ejemplos: VMware Workstation, VMware Server, VirtualBox, QEMU, Microsoft Virtual PC,
Oracle VM VirtualBox.
4
VIRTUALIZACIÓN ASIX2
- Permite gestionar un CPD como una agrupación para toda la capacidad de recursos
(procesador, memoria, red, almacenamiento) dentro de una infraestructura.
5
VIRTUALIZACIÓN ASIX2
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.
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.
6
VIRTUALIZACIÓN ASIX2
El mercado ofrece varios tipos de Hipervisores a alto nivel. Los más importantes y conocidos
son:
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
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.
7
VIRTUALIZACIÓN ASIX2
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.
Migración de Sí Sí Sí
máquinas virtuales
Migración Sí Sí No
automática
Power Management Sí Sí No
Migración de Sí Sí Sí
almacenamiento
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 Sí Sí No
integrada
Líder en el mercado 1 2 3
8
VIRTUALIZACIÓN ASIX2
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.
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".
9
VIRTUALIZACIÓN ASIX2
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.
10
VIRTUALIZACIÓN ASIX2
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.
Por ejemplo:
- Virtualización de almacenamiento.
11
VIRTUALIZACIÓN ASIX2
Ejemplos:
o LVM en Linux.
o ZFS en Open Solaris.
o Sistemas de ficheros distribuidos (OCFS2, GlusterFS, GFS, etc.).
- Virtualización de Red.
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:
12
VIRTUALIZACIÓN ASIX2
- Otras:
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.
13
VIRTUALIZACIÓN ASIX2
- Virtualización parcial.
14
VIRTUALIZACIÓN ASIX2
- Paravirtualización.
15
VIRTUALIZACIÓN ASIX2
Ventajas: Es muy rápida. La capa de virtualización es muy ligera. El rendimiento muy cercano
al nativo.
- 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..
16
VIRTUALIZACIÓN ASIX2
- Otras:
17
VIRTUALIZACIÓN ASIX2
2. ESXi
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.
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.
Hardware
Sistema invitado
Consola de servicio (Console OS, ServiceConsole)
Características:
18
VIRTUALIZACIÓN ASIX2
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.
19
VIRTUALIZACIÓN ASIX2
ESX
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.
20
VIRTUALIZACIÓN ASIX2
ESXi
o El monitoreo de Hardware.
En la nueva arquitectura de VMware vSphere ESXi, el COS ha eliminado y todos los agentes de
VMware ejecutarse directamente en el VMkernel.
21
VIRTUALIZACIÓN ASIX2
A continuación, una tabla que compara las características de la arquitectura ESX o con la de
ESXi.
Instalación automática Sí Sí
SNMP Sí Sí
Jumbo Frames Sí Sí
Auto Deploy No Sí
Syslog seguro No 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.
22
VIRTUALIZACIÓN ASIX2
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.
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.
23
VIRTUALIZACIÓN ASIX2
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.
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.
24
VIRTUALIZACIÓN ASIX2
Ventajas principales
Características principales
Acceso remoto desde cualquier ubicación: con vSphere Web Client se pueden
gestionar las funciones de vSphere desde cualquier explorador en cualquier
parte.
25
VIRTUALIZACIÓN ASIX2
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.
Hardware
26
VIRTUALIZACIÓN ASIX2
Software
27
VIRTUALIZACIÓN ASIX2
Está diseñada para organizaciones que desean virtualizar por completo sus centros de datos y
proporcionar estas tecnologías como servicios.
- Reducción de costes. Disminuye los gastos de propiedad hasta un 80% y los costes
operativos en un 30%.
28
VIRTUALIZACIÓN ASIX2
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.
29
VIRTUALIZACIÓN ASIX2
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.
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.
30
VIRTUALIZACIÓN ASIX2
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.
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.
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.
Etiquetado IEEE 802.1p: etiqueta los paquetes que salen del host de vSphere para que los
recursos de red físicos los gestionen correctamente.
31
VIRTUALIZACIÓN ASIX2
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:
32
VIRTUALIZACIÓN ASIX2
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.
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.
33
VIRTUALIZACIÓN ASIX2
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.
- Gestión sencilla y centralizada con visibilidad del estado de las aplicaciones desde
VMware vCenter Server.
34
VIRTUALIZACIÓN ASIX2
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.
35
VIRTUALIZACIÓN ASIX2
- Requisitos mínimos: SRM 5.0, ESXi 5.0, Virtual center Server 5.0 (No vcenter appliance),
Hardware virtual 7.
- Ú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.
36
VIRTUALIZACIÓN ASIX2
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.
37
VIRTUALIZACIÓN ASIX2
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.
38
VIRTUALIZACIÓN ASIX2
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.
39
VIRTUALIZACIÓN ASIX2
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.
40
VIRTUALIZACIÓN ASIX2
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.
- Crea una copia puntual de datos de una máquina virtual que pueda utilizarse para operaciones de
prueba, copia de seguridad y recuperación.
- 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.
41
VIRTUALIZACIÓN ASIX2
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.
42
VIRTUALIZACIÓN ASIX2
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.
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.
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.
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.
43
VIRTUALIZACIÓN ASIX2
44
VIRTUALIZACIÓN ASIX2
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.
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.
45
VIRTUALIZACIÓN ASIX2
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).
46
VIRTUALIZACIÓN ASIX2
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.
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.
47
VIRTUALIZACIÓN ASIX2
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.
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.
48
VIRTUALIZACIÓN ASIX2
5. Almacenamiento compartido
Para realizar un buen sistema de almacenamiento compartido deberemos montar una red SAN
(Storage área network).
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.
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.
49
VIRTUALIZACIÓN ASIX2
Distancia: Estas redes al ser construidas con fibra óptica heredan sus beneficios por lo
tanto pueden tener dispositivos separados por mucha distancia sin repetidores.
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.
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.
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.
50
VIRTUALIZACIÓN ASIX2
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.
51
VIRTUALIZACIÓN ASIX2
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.
52
VIRTUALIZACIÓN ASIX2
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.
53
VIRTUALIZACIÓN ASIX2
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.
54
VIRTUALIZACIÓN ASIX2
Una vez realizadas estas dos configuraciones ya podremos ver los discos compartidos desde el
FreeNAS en el Vsphere.
55
VIRTUALIZACIÓN ASIX2
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.
56
VIRTUALIZACIÓN ASIX2
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.
57
VIRTUALIZACIÓN ASIX2
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.
58
VIRTUALIZACIÓN ASIX2
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.
59
VIRTUALIZACIÓN ASIX2
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.
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
Fase 3: Swtichover
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
60
VIRTUALIZACIÓN ASIX2
vMotion en curso, el VMkernel utilizará todos los adaptadores de red disponibles para
distribuir el tráfico de vMotion.
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.
61
VIRTUALIZACIÓN ASIX2
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.
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).
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.
62
VIRTUALIZACIÓN ASIX2
Novedades
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
63
VIRTUALIZACIÓN ASIX2
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.
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.
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.
64
VIRTUALIZACIÓN ASIX2
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.
Una vez finalice el proceso observamos en las propiedades de la máquina virtual migrada que
se ha migrado correctamente al disco elegido.
65
VIRTUALIZACIÓN ASIX2
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.
66
VIRTUALIZACIÓN ASIX2
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.
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.
67
VIRTUALIZACIÓN ASIX2
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.
Aplicaciones.
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.
68
VIRTUALIZACIÓN ASIX2
8.1 HA
Aumentar la disponibilidad
Mejorar el rendimiento
Escalabilidad
Tolerancia a fallos
Recuperación ante fallos en poco tiempo
Reducir costes
Consolidar servidores
Consolidar el almacenamiento
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.
69
VIRTUALIZACIÓN ASIX2
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.
70
VIRTUALIZACIÓN ASIX2
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.
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
71
VIRTUALIZACIÓN ASIX2
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.
72
VIRTUALIZACIÓN ASIX2
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.
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
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.
73
VIRTUALIZACIÓN ASIX2
74
VIRTUALIZACIÓN ASIX2
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.
Mejorar los niveles de servicio asegurándose de que las máquinas virtuales dispongan
de los recursos apropiados.
75
VIRTUALIZACIÓN ASIX2
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.
76
VIRTUALIZACIÓN ASIX2
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.
77
VIRTUALIZACIÓN ASIX2
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.
78
VIRTUALIZACIÓN ASIX2
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.
79
VIRTUALIZACIÓN ASIX2
80
VIRTUALIZACIÓN ASIX2
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”
81
VIRTUALIZACIÓN ASIX2
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:
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
82
VIRTUALIZACIÓN ASIX2
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.
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)
Los hosts seguirán corriendo usando los recursos disponibles pero no habra recomendaciones
para optimización de recursos.
83
VIRTUALIZACIÓN ASIX2
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
Errores de VMotion:
Solución: Quitar la VM del cluster, quitar la afinidad y volver a meter al clúster DRS.
Alertas de VMotion:
84
VIRTUALIZACIÓN ASIX2
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:
85
VIRTUALIZACIÓN ASIX2
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.
86
VIRTUALIZACIÓN ASIX2
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
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.
87
VIRTUALIZACIÓN ASIX2
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:
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.
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).
Anti-afinidad de VMDK: en una máquina virtual que tiene varios discos virtuales, estos
últimos se colocan en almacenes de datos diferentes.
88
VIRTUALIZACIÓN ASIX2
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:
89
VIRTUALIZACIÓN ASIX2
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.
90
VIRTUALIZACIÓN ASIX2
Requisitos
Para que Fault Tolerance funcione son necesarios una serie de requisitos:
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.
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.
91
VIRTUALIZACIÓN ASIX2
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.
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 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.
92
VIRTUALIZACIÓN ASIX2
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.
93
VIRTUALIZACIÓN ASIX2
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.
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.
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.
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.
94
VIRTUALIZACIÓN ASIX2
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).
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.
95
VIRTUALIZACIÓN ASIX2
replay.supported = “true”
replay.allowFT = “true”
replay.allowBTOnly = “true”
Básicamente estas reglas significan que Fault Tolerance está habilitado y nos permite seguir
trabajando.
96
VIRTUALIZACIÓN ASIX2
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 Restart Secondary – con esta opción la VM secundaria se reinicia, con lo cual
podemos verificar la consistencia entre la secundaria y primaria.
97
VIRTUALIZACIÓN ASIX2
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:
98
VIRTUALIZACIÓN ASIX2
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.
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.
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.
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.
99
VIRTUALIZACIÓN ASIX2
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.
100
VIRTUALIZACIÓN ASIX2
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.
101
VIRTUALIZACIÓN ASIX2
102
VIRTUALIZACIÓN ASIX2
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.
103
VIRTUALIZACIÓN ASIX2
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).
104
VIRTUALIZACIÓN ASIX2
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
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/
105
VIRTUALIZACIÓN ASIX2
Problema FT:
http://www.virtuallyghetto.com/2011/07/how-to-enable-nested-vft-virtual-fault.html
106