W mware v_sphere_proyecto_final

Proyecto final de curso ASIX Eduardo Luis Miranda Goya

1

Proyecto final de curso ASIX

Virtualización de servidores

con alta disponibilidad y

rendimiento en VMware

vSphere 6.0

Autor: Eduardo Luis Miranda Goya

Tutor: Luis Landajuela Aldecoa.

Administració de sistemes informàtics en xarxa

Centre d’Estudis Stucom. 2015 / 2016


2

Tabla de contenido

1. Introducción. ......................................................................................................................... 4

2. Virtualización. ........................................................................................................................ 5

2.1. ¿Qué es virtualización? ................................................................................................. 5

2.2. Ventajas de la virtualización. ......................................................................................... 5

2.3. VMware vSphere. .......................................................................................................... 5

2.3.1. Competencias de VMware vSphere. ..................................................................... 6

2.3.2. Precios de las licencias de VMware vSphere 6.0. .................................................. 6

2.3.3. Precios de las licencias de VMware vCenter Server. ............................................. 7

2.3.4. Comparativa de las características. ....................................................................... 7

2.3.5. Ventajas y desventajas de VMware vSphere. ....................................................... 7

3. Características la infraestructura de vSphere VMWare 6.0. ................................................. 8

3.1. Hipervisor ESXI. ............................................................................................................. 8

3.2. Almacenamiento compartido. ...................................................................................... 9

3.3. VMware vCenter Server. ............................................................................................... 9

4. Funcionalidades de VSphere. .............................................................................................. 10

4.1. vMotion. ...................................................................................................................... 10

4.2. Storage vMotion. ......................................................................................................... 11

4.2.1. ¿Cómo funciona Storage vMotion? ..................................................................... 11

4.3. High Availabity (HA). ................................................................................................... 11

4.3.1. ¿Cómo funciona HA? ........................................................................................... 12

4.3.2. Control de admisión. ........................................................................................... 13

4.4. vSphere Distributed Resource Sheduler (DRS). ........................................................... 14

4.4.1. Niveles de automatización de DRS. ..................................................................... 15

4.4.2. Niveles de sensibilidad de DRS. ........................................................................... 16

4.4.3. DPM. .................................................................................................................... 17

4.4.4. Reglas DRS. .......................................................................................................... 18

4.5. Fault Tolerance. ........................................................................................................... 19

4.5.1. ¿Cómo funciona FT? ............................................................................................ 19

4.5.2. Requerimientos para FT en vSphere. .................................................................. 20

4.5.3. Mejores prácticas de VMware para un ambiente vSphere que utilizará FT. ...... 21

5. Configuración de simulación del proyecto. ......................................................................... 21

5.1. Diagrama de simulación. ............................................................................................. 22

5.2. Instalación y configuración del servidor FreeNAS para el almacenamiento compartido

con iSCSI. ................................................................................................................................. 22


3

5.2.1. Instalación de FreeNAS. ...................................................................................... 22

5.2.2. Configuración de FreeNAS. ................................................................................. 23

5.2.3. Configuración del iniciador iSCSI. ........................................................................ 25

5.3. Instalación y configuración de los hipervisores ESXi. .................................................. 30

5.3.1. Instalación de ESXi. .............................................................................................. 30

5.3.2. Configuración de ESXi .......................................................................................... 31

5.4. Instalación y configuración de vCenter Server. ........................................................... 37

5.4.1. Instalación de vCenter Server. ............................................................................ 37

5.4.2. Configuración de vCenter Server. ....................................................................... 44

6. Configuración de las funcionalidades de vSphere. ............................................................. 50

6.1. Configuración de vMotion y Storage vMotion. ........................................................... 51

6.2. Configuración de High Availabity (HA). ....................................................................... 51

6.3. Configuración de DRS. ................................................................................................. 53

6.4. Configuración de FT. .................................................................................................... 54

7. Pruebas.de las características. ............................................................................................ 56

7.1. Pruebas con vMotion. ................................................................................................. 56

7.2. Pruebas con Storage vMotion. .................................................................................... 61

7.3. Pruebas con HA. .......................................................................................................... 64

7.4. Pruebas con FT. ........................................................................................................... 66

7.5. Pruebas de DRS ........................................................................................................... 67

7.5.1. DRS manual. ........................................................................................................ 67

7.5.2. DRS manual con reglas DRS. ................................................................................ 70

7.5.3. DRS automático. .................................................................................................. 73

8. Conclusión. .......................................................................................................................... 75

9. Bibliografía .......................................................................................................................... 76


4

Virtualización de servidores con alta

disponibilidad y rendimiento en

VMware vSphere 6.0

1. Introducción.

Este proyecto final de curso, utilizaré una de las herramientas más potentes dentro de la

virtualización de servidores como es VMware y su producto de gestión en la nube como es

VMware vSphere.

Durante proyecto probaremos las principales funcionalidades de vSphere como son la alta

disponibilidad, el rendimiento, la escalabilidad, ahorro de costes y tolerancia a fallos en las

organizaciones IT, simulando un pequeño datacenter.

He tratado de explicar lo explícito posible cada una de las funcionalidades y todo el trabajo

realizado en el proyecto.

En cuanto a la metodología he necesitado 3 máquinas físicas para poder realizar el proyecto, ya

que alguna de las características o funcionalidades de VMware vSphere consumía muchos

recursos como el caso de Fault Tolerance. También al ser MACs no en todos estaba instalado

Windows para los alumnos y el despliegue de las máquinas virtuales del proyecto están

realizados en WMware Workstation Player y el vCenter Server en VirtualBox.

Uno de los inconvenientes que tuve en el proyecto fue probar Fault Tolerance ya que a pesar de

tener 3 máquinas físicas consume muchos recursos como ancho de banda, y las pruebas

llegaban a demorar en completarse alrededor de unos 15 minutos y no se podía realizar ninguna

otra prueba ya que colapsaba la red, ya que utilizaba una tarjeta Gigabit Ethernet para simular

4 redes virtuales y Fault Tolerance necesita una sola real para su buen funcionamiento.

Otro inconveniente es que tuve que configurar una máquina virtual cualquiera como puerta de

enlace ya algunas características no reconocían la puerta de enlace configurada al inicio del

proyecto todo el despliegue de las máquinas virtuales estaba en mi PC de clase en modo NAT y

al final tuve que desplegarlo en otras PCs y colocar las tarjetas de red en modo Bridged.

El proyecto inicial estaba dedicado a poder gestionarlo desde la nube a través una web donde

los clientes puedan gestión y crear sus propias instancias como lo permite AWS (Amazon Web

Services), pero no pudo ser posible ya que para seguir probando productos de WMware el

siguiente nivel era con licencias de pago y si había algún producto de prueba era en laboratorios

externos donde no se podía seguir utilizando las configuraciones realizadas en clase.


5

2. Virtualización.

2.1. ¿Qué es virtualización?

Es el proceso mediante el que se crea una versión virtual, en lugar de una física. La virtualización

se puede aplicar a computadoras, sistemas operativos, dispositivos de almacenamiento de

información, aplicaciones o redes. Sin embargo, la virtualización de servidor es la parte más

importante de este concepto.

Cada máquina virtual puede interactuar de forma independiente con otros dispositivos,

aplicaciones, datos y usuarios, como si se tratara de un recurso físico independiente.

Diferentes máquinas virtuales pueden ejecutar diferentes sistemas operativos y múltiples

aplicaciones al mismo tiempo utilizando un solo equipo físico. Debido a que cada máquina virtual

está aislada de las otras máquinas virtualizadas, en caso de ocurrir un bloqueo esto no afecta a

las demás máquinas virtuales.

2.2. Ventajas de la virtualización.

Existen muchos beneficios para la consolidación de servidores Linux o Windows mediante el

aprovechamiento de los diferentes productos de virtualización de servidores existentes en el

mercado.

Disminuye el número de servidores físicos. Esto trae como consecuencia una reducción

directa de los costos de mantenimiento de hardware.

Mediante la implementación de una estrategia de consolidación de servidores, puede

aumentar la eficiencia de la utilización del espacio en nuestro centro de datos.

Al tener cada aplicación dentro de su propio “servidor virtual” podemos evitar que una

aplicación impacte otras aplicaciones al momento de realizar mejoras o cambios.

Podemos desarrollar una norma de construcción de servidor virtual que se puede

duplicar fácilmente lo que acelerará la implementación del servidor.

Podemos desplegar múltiples tecnologías de sistemas operativos en una sola plataforma

de hardware, como por ejemplo (Windows Server 2008, Windows Server 2012, etc.).

2.3. VMware vSphere.

Es la plataforma de virtualización de VMware en la nube (anteriormente se llamaba VMware

Infraestructure), el cual nos proporciona los recursos necesarios para la instalación y

administración de una infraestructura virtualizada con rendimiento y alta disponibilidad.

vSphere acelera el cambio hacia el cloud computing para los centros de datos existentes,

además de sustentar las ofertas de cloud pública, de tal forma que constituye una base para el

único modelo de cloud híbrida del sector. Cuenta con más de 250 000 clientes en todo el mundo,

por este motivo es la aplicación de confianza para cualquier aplicación.


6

2.3.1. Competencias de VMware vSphere.

VMware no está solo en el mercado, actualmente existen otros grandes competidores con

grandes ventajas:

Microsoft Hyper-V

El rol de virtualización de Microsoft, ha tenido buenos cambios en rendimiento, al igual

que los demás productos tiene funciones de disponibilidad, rendimiento y ahorro de

costes de energía. Hyper-V comenzó con su salida al mercado de la mano de Windows

2008 server con la activación de un rol que viene embebido con el sistema operativo.

Citrix XenServer.

Citrix XenServer Server es una plataforma de virtualización de nube, servidores y

escritorios, Open Source y gratuita, desarrollada en conjunto por una amplia comunidad

(proyecto Xen) y por Citrix. En esta versión están disponibles todas las funcionalidades

que anteriormente solo estaban presentes en las versiones de pago más avanzadas. De

esta manera las empresas de cualquier tamaño tienen a su disposición esta potentísima

solución a su alcance. Tiene muchas funciones iguales que vSphere como la migración

en caliente, balanceo de carga, etc.

Red Hat Enterprise Vitualization (RHEV).

RHVE es la plataforma de virtualización de Red Hat que está basado sobre el hipervisor

KVM. RHEV proporciona un servidor de administración centralizada basado en RHEL con

una interfaz web para la gestión de máquinas virtuales (VM) llamado RHEV manager.

2.3.2. Precios de las licencias de VMware vSphere 6.0.

Licencias a la carta con precios por CPU. Todas las ediciones se deben combinar con una edición

de vCenter Server existente o adquirida por separado. Las ediciones confieren derechos

específicos sobre la memoria virtual y la CPU. Si se necesitan más derechos, es preciso adquirir

licencias adicionales. Se necesita un contrato de soporte y suscripción (SnS) por un mínimo de

un año.


7

2.3.3. Precios de las licencias de VMware vCenter Server.

Se requiere un contrato de soporte y suscripción (SnS) por un mínimo de un año. vCenter Server

Standard también incluye vRealize Orchestrator y 25 transmisiones de registros de vRealize Log

Insight for vCenter Server.

2.3.4. Comparativa de las características.

Buscando información he hecho una pequeña comparativa entre vSphere y algunos de sus

competidores a nivel técnico.

2.3.5. Ventajas y desventajas de VMware vSphere.

Ventajas.

Eficiencia gracias a la utilización y a la automatización:

o Conseguimos índices de consolidación de 15:1 o más y mejore la utilización del

hardware del 5 al 15 % hasta un 80 % o más, sin sacrificar rendimiento.

Reducción drástica de los costes de TI:

o Disminuir los gastos de propiedad hasta un 70% y los costes operativos en un

30%, a fin de conseguir costes de infraestructuras de TI un 20 o 30% inferiores

por cada aplicación que se ejecute en vSphere.

Vmware vSphere 6.0 Windows Server

Enterprise Plus 2012 R2 Hyper-V

Procesador lógico por host 480 320 160

Memoria física por host 12TB 4TB 1TB

vCPU por host 2048 2048

vCPU por VM 128 64 32

Memoria por VM 4TB 1TB 192GB

VMs activas por host 1000 1024 500

Máximos nodos en un Clúster 64 64 16

Máximas VMs en un Clúster 8000 4000 1000

XenServer 6.5

Host

VM

Clúster

Sistema Recurso


8

Desventajas.

El precio de una solución de pago de vSphere puede llegar a costar entre $4000 y $8000.

Los requerimientos de hardware tienen que ser de una gama muy alta, por lo cual se

hace difícil de implementar para experimentos caseros.

3. Características la infraestructura de vSphere VMWare 6.0.

3.1. Hipervisor ESXI.

Se trata de un hipervisor, es el corazón de la infraestructura vSphere, es decir, es una capa de

virtualización que permite ejecutar varios sistemas operativos (VM) sobre la misma máquina

física. Este hipervisor es de tipo Bare-metal, esto quiere decir que se instala directamente sobre

el hardware sin necesidad de un sistema operativo Host (Windows o Linux).

Existen dos tipos de hipervisores:

Hipervisor tipo 1 (Nativos, unhosted o bare-metal): El hipervisor ESXi se ejecuta

directamente sobre el hardware físico; el hipervisor ESXi se carga antes que ninguno de

los sistemas operativos invitados, y todos los accesos directos a hardware son

controlados por él.

Hipervisor tipo 2 (Hosted): En ellos el hipervisor ESXi se ejecuta en el contexto de un

sistema operativo completo, que se carga antes que el hipervisor. Las máquinas

virtuales se ejecutan en un tercer nivel, por encima del hipervisor.


9

3.2. Almacenamiento compartido.

Una de las grandes ventajas de VMware vSphere es poder compartir el almacenamiento de las

máquinas virtuales, lo que hace referencia poder añadir cualquier máquina virtual a cualquiera

de los hosts que tengan como almacenamiento compartido el mismo Datastore.

WMware ofrece varias opciones para añadir los Datastores para el almacenamiento compartido:

iSCSI (Internet SCSI).

NFS (Network File System).

FC (Fibre Channel).

FCoE (Fibre Channel over Ethernet).

El almacenamiento compartido es uno de los requisitos para poder habilitar las funciones de

DRS, DPM, HA y FT.

3.3. VMware vCenter Server.

vCenter Server es considerado el componente más importante de una infraestructura virtual en

VMware vSphere 6.0. Es, por tanto, el componente que permite gestionar centralizadamente

múltiples servidores VMware vSphere ESXi y máquinas virtuales.

El vCenter Server añade funcionalidad en áreas tales como alta disponibilidad (VMware HA),

balanceo de carga (VMware DRS), Fault Tolerance (FT), actualización de componentes (Update

Manager) y conversiones de físico a virtual (VMware Converter).


10

4. Funcionalidades de VSphere.

Entre las principales funcionalidades que tiene el VSphere se encuentran:

vMotion.

Storage vMotion.

HA (High Availabity).

DRS.

Fault Tolerance.

4.1. vMotion.

VMotion nos permite trasladar de manera dinámica una máquina virtual completa y en

funcionamiento de un servidor a otro, sin tiempo de inactividad. La máquina virtual retiene su

identidad y conexiones de red, con lo que se garantiza un proceso de migración sin ningún tipo

de problema. Todo este proceso tarda menos de 2 segundos.

Requisitos para poder migrar las máquinas en caliente con vMotion:

2 servidores físicos con ESXi instalado. Una tarjeta Gigabit Ethernet dedicada para vMotion conectada entre los dos ESXi y

deben tener configurado un VMkernel.

PortGroup con tráfico vMotion habilitado.

Etiquetas (nombre) de red utilizadas por los Portgroups deben ser idénticos

Almacenamiento compartido entre los hosts. FC, iSCSI o NFS.

La CPU de los servidores origen y destino deben ser del mismo fabricante y familia.

Migraciones multivendor, entre Intel y AMD no están soportados.


11

4.2. Storage vMotion.

Storage vMotion es una tecnología o servicio distribuido de VMware, el cual permite migrar los

discos de las máquinas virtuales de un almacenamiento a otro y en caliente, sin afectar a la

máquina virtual. Storage vMotion es un proceso totalmente transparente para las máquinas

virtuales y no les genera indisponibilidad.

4.2.1. ¿Cómo funciona Storage vMotion?

Entre las principales funciones que encontramos en Storage vMotion son:

Realizar migraciones de almacenamiento sin perder tiempo de inactividad

Permite migrar los archivos de discos de las máquinas virtuales, independientemente

del sistema que tenga instalado y el hardware del servidor donde se ejecute.

Permite migrar en caliente los archivos de disco de las máquinas virtuales a cualquier

sistema de almacenamiento que sea compatible con vSphere (FC, iSCSI, NFS, etc.).

4.3. High Availabity (HA).

HA permite que múltiples hosts ESXI puedan ser configurados como un clúster para proveer de

alta disponibilidad y alta recuperación ante fallos, para todas las máquinas virtuales en dichos

hosts.


12

4.3.1. ¿Cómo funciona HA?

HA provee de alta disponibilidad a las MV formando clústers donde residen los hosts y dichas

MV. Los hosts en un clúster son monitoreados, y ante la falla de un host, las MV que residen en

dicho host son reiniciadas en otros hosts que se encuentren disponibles en el clúster.

A partir de vSphere 5, cuando se crea un clúster HA, uno de los hosts es designado como Master

host o host maestro, para comunicarse con vCenter Server y monitorear el estado de los otros

hosts y sus MV. Este host maestro debe ser capaz de detectar y tratar apropiadamente con los

diferentes tipos de fallas que pueden afectar a un host. Se debe distinguir, por ejemplo, entre

un host con fallas, de uno que ha llegado a estar aislado en la red.

Host maestros y esclavos.

Cuando un host es unido a un cluster HA, un agente es instalado y configurado en el host, para

comunicarse con otros agentes en el cluster. Cada host en un cluster funciona como maestro o

esclavo.

Cuando se habilita HA en un clúster, todos los hosts ACTIVOS participan en una elección para

elegir al host maestro del clúster. El host que tenga el mayor número de datastores montados

tiene una ventaja en la elección. Solo existe 1 host maestro por clúster, si este falla, es apagado,

o es removido del clúster, se realiza una nueva elección. Estas son las responsabilidades de un

host maestro:

Monitorear el estado de los hosts esclavos. Si uno de estos falla o se encuentra aislado,

el host maestro identifica que VM necesitan ser reiniciadas.

Monitorear el estado de todas las MV protegidas. Si una MV falla, el host maestro se

asegura que ésta sea reiniciada. Además, usando un motor de ubicación, el host

maestro también determina donde se debiera realizar el reinicio.

Gestiona la lista de hosts y MV protegidas del clúster.

Actúa como interfaz de administración con vCenter Server, y reporta el estado de salud

del clúster.


13

Los hosts esclavos contribuyen al clúster ejecutando las MV, monitoreando su estado de

ejecución, y reportando las actualizaciones de estado al host maestro. Un host maestro,

obviamente, también puede hospedar y monitorear MV.

Otra de las funciones realizadas por un host maestro, es la protección de MVs. Cuando se

protege una MV, HA garantiza que intentará volver a encenderla después de una falla (failover).

Las MV protegidas son aquellas en estado activo, no considerándose las MV apagadas.

vCenter Server reporta si un host es un host maestro Running (Master) o esclavo Connected

(Slave) usando lo que se conoce como vSphere HA host state. Este estado es reportado en el

tab Summary del host, en el vSphere Client, y en la vista de hosts en un Clúster o Datacenter.

Tipos de falla de Host y su detección.

Existen 3 tipo de fallas que pueden ser detectadas:

Un host deja de funcionar, por ejemplo, por falla de hardware.

Un host queda aislado en la red.

Un host pierde conectividad con el host maestro.

Datastore Heartbeating.

Cuando el host maestro en un cluster HA no se puede comunicar con un host esclavo sobre la

red de administración, el host maestro utiliza el Datastore Heartbeating para determinar si el

host esclavo ha fallado, se encuentra en una división de red, o está aislado en la red. Si el host

esclavo ha dejado de realizar el Datastore Heartbeating, es considerado como host fallido y sus

MV son reiniciadas en otros hosts del cluster.

4.3.2. Control de admisión.

HA utiliza control de admisión para asegurarse de que existan suficientes recursos disponibles

en el cluster para proveer de alta disponibilidad y asegurarse de que las reservaciones de

recursos de las MV sean respetadas.

Existen tres tipos de control de admisión:

A nivel de Host: Se asegura de que un host tenga suficientes recursos para satisfacer las

reservaciones de todas las MV que corran en él.

A nivel de Resource Pool: Se asegura de que un RP tenga suficientes recursos para

satisfacer las reservaciones, shares, y límites de todas las MV en el.

A nivel de Cluster HA: Se asegura de que se reserven suficientes recursos en un cluster

para la recuperación de MV ante la falla de un host.


14

El control de admisión impone restricciones en el uso de recursos y cualquier acción que pudiera

violar dichas restricciones, no está permitida, como, por ejemplo:

Encender una MV

Migrar una MV otro host, clúster o Resource Pool.

Aumentar la reservación de memoria o CPU de una MV.

Políticas de control de admisión

El control de admisión en un clúster HA puede ser configurado con una de las 3 políticas de

admisión disponibles:

Tolerar fallas de host en un clúster: permite configurar HA para tolerar un numero

especifico de fallas de hosts. Con esta política de control de admisión, HA se asegura

que un número específico de hosts puedan fallar, y aun queden suficientes recursos

disponibles en el clúster para hospedar a todas las MV de dichos hosts.

Porcentaje de recursos reservados en el clúster: Permite configurar HA para controlar

la admisión reservando un porcentaje especifico de los recursos de CPU y Memoria para

la recuperación ante la falla de uno o más hosts. Esta política utiliza las reservaciones de

las MV para aplicar el control de admisión. Si una MV no tiene reservas, se aplican los

valores por defecto de 0MB de RAM y 256Mhz de CPU.

Especificar hosts para failover: Permite configurar HA para designar hosts específicos

como hosts para failover. Con esta política, cuando un host falla, HA intenta reiniciar

sus MVs en uno de los hosts especificados para el failover. Si esto no es posible, por la

falla de uno de estos hosts designados, o por falta de recursos suficientes, HA intenta

reiniciar las MVs en otros hosts en el clúster.

Para asegurar de que exista capacidad suficiente en un host de failover, se evita que una MV sea

encendida, o migrada con vMotion a dicho host. Estos hosts además no son utilizados por DRS

para el balanceo de carga.

4.4. vSphere Distributed Resource Sheduler (DRS).

DRS básicamente balancea dinámicamente las máquinas virtuales de un servidor ESXI a otro u

otros servidores ESXI para mejorar el tiempo de respuesta de las aplicaciones de las máquinas

virtuales contienen.

Cuando una máquina virtual experimenta un aumento de la carga, VMware DRS

automáticamente asigna recursos adicionales mediante la redistribución de otras máquinas

virtuales entre los servidores físicos.

DRS utiliza vMotion para migrar las máquinas virtuales a hosts diferentes para que la carga

general de la infraestructura esté equilibrada.


15

4.4.1. Niveles de automatización de DRS.

DRS puede ser configurado de las siguientes formas:

Manual: DRS no se ejecuta de forma automática. Sin embargo, si queremos balancear

la carga de trabajo de los hosts, podemos pedirle manualmente recomendaciones, que

podrán ser aplicadas, también de forma manual, por el usuario con privilegios

suficientes que haya pedido la recomendación. Además, las máquinas que se enciendan

en el clúster no se colocarán de forma automática en el host más adecuado cuando se

enciendan, sino que preguntará al usuario el host de su elección.

Parcialmente automatizado: DRS evalúa cada cinco minutos la situación del clúster y

genera recomendaciones sobre que máquinas virtuales mover a que host. Los

movimientos de máquinas virtuales en este modo han de ser aprobados manualmente

por un usuario con privilegio suficientes. Sin embargo, que se colocan de manera

automática las máquinas virtuales que se enciendan en el clúster, teniendo en cuenta la

carga de los hosts del clúster.

Automático: DRS evalúa cada cinco minutos la situación del clúster y de forma

autónoma mueve de host las máquinas virtuales para las que ha obtenido

recomendaciones positivas.


16

4.4.2. Niveles de sensibilidad de DRS.

DRS tiene diferentes niveles de sensibilidad (prioridades de migración) para realizar

recomendaciones (que luego se llevarán a cabo o no dependiendo del nivel de automatización

que configuremos en el clúster).

Estos niveles son:

Nivel 1: Se trata del nivel más conservador. Tan solo realizará tareas de movimiento de

máquinas virtuales para poder cumplir con solicitudes como poner hosts en

mantenimiento o respetar reglas de afinidad (o anti afinidad).

Nivel 2: Solo se efectuarán recomendaciones que generen una mejora significativa del

nivel de carga de los hosts.

Nivel 3: Algo más agresivo que el anterior, recomendará migraciones de máquinas que

vayan a suponer una mejora moderada en la carga de los hosts.

Nivel 4: Siguiendo la línea anterior, las recomendaciones se harán en cuanto supongan

una pequeña mejora en el reparto de carga entre los hosts.

Nivel 5: Es el nivel más agresivo y recomendará aquellos movimientos de máquinas que

supongan mínimas mejoras en el reparto de la carga entre los hosts.


17

4.4.3. DPM.

Era una funcionalidad independiente que de a poco se ha ido fusionando con DRS. A partir de la

versión 5.5 se presenta como un apartado más de DRS llamado Power Management, utiliza

tecnologías IPM, ILO o Wake on LAN para encender y apagar servidores en función del nivel de

carga que presenten.

Para que DPM funcione correctamente, tiene que tener los siguientes requisitos:

DRS debe estar configurado en modo automático.

Se debe configurar las opciones IPM / iLO-BMC / Wake On Lan de los servidores que

queremos controlar.

Configuración de DPM.

DPM Off: DPM no funcionará ni encenderá ni apagará hosts.

DPM Manual: DPM recomendará encendidos o apagados de hosts en función de la

carga que observe (teniendo en cuenta los requisitos de HA). Sin embargo, no afectará

las acciones de automática, teniendo que aprobarlas una persona con privilegios.

DPM Automático: DPM encenderá y apagará los hosts de manera automática en

función de los niveles de carga que observe y las necesidades HA del clúster.

DPM tiene cinco niveles de sensibilidad, que van del 0 al 5, y que permiten desde

encender o apagar hosts por nivel de carga, hasta solo realizar estas acciones en caso

de necesitarlo para satisfacer las necesidades del clúster.


18

4.4.4. Reglas DRS.

Las reglas DRS o DRS rules son una de las funcionalidades más importantes de DRS que nos sirven

para establecer las denominadas reglas de afinidad o anti afinidad entre máquinas virtuales.

Existen varios tipos de reglas DRS:

Keep Virtual Machines Together.

Las reglas de afinidad VM-VM sirven para mantener en todo momento una serie de máquinas

virtuales juntas. Donde vaya una máquina virtual, irán sus compañeras. Es útil especialmente en

los siguientes casos:

Máquinas virtuales que tengan un tráfico de red muy intenso entre ellas y queremos

mantener ese tráfico de red dentro del host.

Máquinas virtuales que utilicen protocolos de red que nuestros switches no permitan

estilo multicast.

Separate Virtual Machines.

Las reglas Separate Virtual Machines en DRS se denominan de anti-afinidad VM-VM. Sirven para

asegurar que siempre se van a mantener separadas una serie de máquinas virtuales en

diferentes hosts. La utilidad de estas reglas de anti afinidad DRS es poder asegurarnos que, ante

el fallo de uno de los hosts, tenemos una máquina virtual que efectúa las mismas labores en

otro host diferente.

Virtual Machines to Hosts.

Las reglas Virtual Machines to Hosts sirven para asegurarnos de que una o varias máquinas

virtuales siempre están en ejecución en determinados hosts del clúster. Esto nos sirve en casos

como:

Dedicar memoria más fiable a máquinas virtuales más críticas.

Dedicar CPU con instrucciones especiales o mayor velocidad en Mhz por core para

máquinas virtuales que lo necesiten.

Cumplir con licenciamientos obsoletos como los que obligaban a licenciar un host físico

para determinadas aplicaciones.

Las reglas DRS se configuran en el apartado DRS Rules de la configuración del cluster y son tan

sencillas como elegir el tipo de regla y las máquinas a las que queremos aplicarlas.


19

4.5. Fault Tolerance.

Fault Tolerance es una característica de VSphere que permite proteger una máquina virtual (MV

primaria) creando una segunda instancia de la misma máquina en otro host (VM secundaria), la

cual actúa como un espejo, y replica todos los cambios realizados en la MV primaria, en tiempo

real, a través de una conexión de red de alta velocidad entre los hosts ESXI, utilizando una

tecnología que VMware denomina como vLockStep (reemplazada ahora por Fast

Checkpointing)

4.5.1. ¿Cómo funciona FT?

FT está diseñado para máquinas virtuales de misión crítica, las cuales requieren de disponibilidad

continua. FT provee de esta disponibilidad continua creando y manteniendo otra MV idéntica,

la cual se mantiene disponible para reemplazar a la MV protegida en una situación de Failover.

La MV protegida, como ya mencionamos, es denominada como MV Primaria. La MV duplicada

(MV secundaria), es creada y ejecutada en un host ESXi distinto a la MV Primaria.

La ejecución de la MV secundaria es idéntica a la de la MV Primaria, y puede tomar el control

(Failover) en cualquier momento sin interrupción, para así proveer protección tolerante a fallas.

Para lograr esto, la MV Primaria y Secundaria se monitorean entre sí, revisando continuamente

su estado para asegurar que se mantiene la tolerancia a fallas. FT en vSphere 6.0 utiliza una

tecnología denominada Fast Checkpointing, la cual es mucho más rápida que vLockStep utilizada

en versiones anteriores, y permite que continuamente se copie y se revisen los datos en la MV

secundaria.

Cuando el host que hospeda la MV primaria falla, ocurre lo que VMware denomina como

Failover transparente, en cuyo caso la MV Secundaria es activada inmediatamente para

reemplazar a la MV Primaria, sin pérdida de servicio ni conectividad. En este punto, la MV

Secundaria pasa a ser reconocida como MV Primaria.


20

Al mismo tiempo, una nueva MV Secundaria es creada e iniciada en otro host ESXi, de manera

que la redundancia es restablecida automáticamente, asegurando así la tolerancia a fallas.

Del mismo modo, si el host que hospeda una MV Secundaria falla, inmediatamente se crea una

nueva MV Secundaria en otro host disponible en el cluster para reemplazarla, y así mantener la

tolerancia a fallas.

Es importante destacar que cuando se protege una MV con Fault Tolerance, la MV Primera y

Secundaria no pueden hospedarse en el mismo host. Esta restricción permite asegurar que la

falla de un host no resulte en la perdida de ambas máquinas virtuales.

Destaquemos también que FT es totalmente transparente para las máquinas virtuales y su

sistema operativo guest. Es decir, no existe dependencia con el S.O. de la MV, ni con sus

aplicaciones

4.5.2. Requerimientos para FT en vSphere.

Algunos de los requerimientos para habilitar FT en vSphere son:

La CPUs que utilizan los hosts ESXi deben ser compatibles con vMotion, o utilizar EVC

(Enhanced vMotion Compatibility). Se soportan las siguientes CPUs

Intel Sandy Bridge o posterior. Avoton no es soportado.

AMD Bulldozer o posterior.

Se requiere conectividad de 10 GbE, verificando que la red es de baja letanía.

La máquina virtual debe estar en un almacenamiento compartido

Configurada una red para VMotion con 2 NIC por host.

Configurada una red para Faul Tolerance Logging con 2 NIC por host.

No podemos utilizar IPv6, ya que HA no soporta este protocolo.

No podemos migrar VMs utilizando Storage VMotion si estas tienen FT habilitado.

No podemos tener CDs presentados a dicha VM, en el caso de tener ISOs estos deberán

residir en un almacenamiento común a todos los hosts del cluster.

No podemos tener puertos seriales ni paralelos.

Nuestra VM no podrá tener snapshots, ni por lo tanto usar backups basados en

snapshots (cómo VCB o DataRecovery).

la MV no puede tener ningún dispositivo físico conectado del host (CD, adaptador PCI,

disquetera…)

En esta versión de vSphere 6.0. puede proteger hasta VM con 4 vCPU, en versiones

anteriores solo podía con 1 vCPU

NOTA: El número de vCPU por MV protegida con FT está limitado a la licencia

utilizada en vSphere. Es decir, licenciamiento vSphere Standard sigue soportando

solo 1 vCPU con FT. Para poder utilizar FT con hasta 4 vCPU por MV se requiere

licenciamiento vSphere Enterprise o Enterprise Plus. FT no es soportado con

licenciamiento vSphere Essentials o Essentials Plus.


21

4.5.3. Mejores prácticas de VMware para un ambiente vSphere que utilizará FT.

Como en todo diseño debemos pensar en redundancia, por lo cual debemos de tener

NICs redundantes para nuestro logging de FT, debemos tener acceso hacia el

almacenamiento redundante.

Dividir las redes para el tráfico de VMs, VMotion y FT, ya sea físicamente, o con VLANs.

La velocidad de los procesadores no debe diferir por más de 400 MHZ entre ellos.

Tratar de evitar que todas las VMs primarias residan en un mismo host (podemos tener

hasta 4 primarias por host).

Mantener la sincronización de tiempo tanto de nuestros Hosts ESX/ESXi y de VMs.

5. Configuración de simulación del proyecto.

En este proyecto, vamos a utilizar las siguientes máquinas para simular todo lo realizado:

He utilizado 3 PCs físicos MAC para poder utilizar grandes recursos cada una de las máquinas

virtuales.

1º MAC contiene:

Como lo realizamos en virtualización hosted utilizamos VMware Workstation Player sobre un

sistema operativo Windows 10, en donde he creado:

Servidor de almacenamiento compartido – FreeNAS.

Un hipervisor ESXi

2º MAC contiene:

Como lo realizamos en virtualización hosted utilizamos VMware Workstation Player sobre un

sistema operativo Windows 10, en donde he creado:

Un hipervisor ESXi

3º MAC contiene:

Un sistema operativo IOS donde se ha utilizado Virtual Box, ya que no tenía instalado Windows,

se ha creado:

Servidor Windows Server 2012 donde he añadido un disco más para instalar el vCenter

Server.


22

5.1. Diagrama de simulación.

5.2. Instalación y configuración del servidor FreeNAS para el almacenamiento

compartido con iSCSI.

5.2.1. Instalación de FreeNAS.

Creamos la máquina virtual con los siguientes requisitos:

Sistema Operativo: FreeBSD CPU: 1 Memoria: 2 GB (Mínimo)


23

Una vez instalado vemos la interfaz que nos indica el servidor y le configuramos una IP para

luego poder administrarlo desde la interfaz gráfica.

5.2.2. Configuración de FreeNAS.

Una vez instalado el servidor FreeNAS desde un navegador web, introducimos la IP que le hemos

asignado al FreeNAS y entramos al entorno gráfico para realizar la configuración.


24

Agregamos 4 discos más además del sistema operativo, con ellos vamos a configurar dos raids

los cuales asignaremos a los servidores ESXi para el almacenamiento compartido. Estos discos

se pueden conectar en caliente, es decir mientras la máquina está encendida.

Vamos a Storage → Volumes → Volume Manager. Le ponemos un nombre “Raid”. Verificamos

que el Volume layout este en Mirror para realizar el raid-1 y escogemos los discos con los que

realizamos el raid. Para finalizar escogemos Add Volume.


25

Procedemos a hacer lo mismo con los 2 discos restantes y le asignamos otro nombre “Raid2”.

Para ver si se han realizado los raids correctamente, vamos a View Volumes y vemos que se

encuentran los dos raids configurados Raid y Raid2.

5.2.3. Configuración del iniciador iSCSI.

Ahora configuramos los iniciadores para los servidores ESXi.

Vamos a Sharing → Blocks (ISCSI). Aquí vemos todos los campos que tenemos que configurar.


26

Para comenzar, escogemos Portal y creamos el portal para la conexión. En Comment le

ponemos un nombre “ESXI” y verificamos que este en el puerto 3260 que es por donde se

conecta el iniciador ISCSI y para finalizar a OK.

Luego escogemos Initiators y colocamos ALL para que todos los servidores ESXi puedan tener

acceso a los discos compartidos y la red autorizada le diremos ALL, es decir que todas las redes

se pueden conectar. Para finalizar OK.


27

Ahora realizamos el Target para cada servidor ESXi, escogemos un nombre de Target “esxi1” y

le añadimos un Alias. En Portal Group ID escogemos el Portal configurado que es 1 (ESXI) y el

Initiator Group ID el iniciador 3. Para finalizar le damos a OK.

Realizamos el otro Target para el otro raid creado. El portal y el initiator serán los mismos.


28

Ahora creamos las Extents, para el raid1 será la Extension1. En Path to the extent escogemos la

ruta del raid1-1 /mnt/Raid/extension1. Escogemos el tamaño de la extensión que será el

tamaño máximo posible al disco, en este caso 90GB.

Ahora hacemos la extension2 para el raid2 y le asignamos la ruta /mnt/Raid2/extension2. Le

asignamos también todo el tamaño posible del disco 90GB.


29

Para finalizar vamos a Targets / Extents y realizamos el del raid1, donde escogemos el Target

esxi1 y el Extent extension1. Le damos OK para finalizar.

Asi mismo realizamos un segundo Targets / Extents para el raid2. Escogemos el Target esxi2 y

la extension2 y lo guardamos.

Una vez realizada las configuraciones reiniciamos el Servicio iSCSI. Para ello vamos a Services →

Control Services y en iSCSI lo apagamos y lo volvemos a encender.


30

5.3. Instalación y configuración de los hipervisores ESXi.

5.3.1. Instalación de ESXi.

Creamos las máquinas virtuales con los siguientes requisitos:

Sistema Operativo: Other CPU: 2(Mínimo) Memoria: 4 GB (Mínimo) Tarjetas de red: 5 vmnic

Hemos como se han instalado los hipervisores ESXi correctamente. Luego configuramos las IP

estáticas a cada host 192.168.10.11 y 192.168.10.12.

NOTA: En la práctica final he aumentado a 4CPUs y a 8GB de memoria ya que funciones

como Fault tolerance consumían muchos recursos y la prueba iba muy lenta.


31

5.3.2. Configuración de ESXi

Una vez hayamos instalado los hipervisores ESXi. Vamos al navegador y colocamos la IP que le

hayamos indicado de gestión para los ESXi y de allí nos indicará que nos descarguemos y nos

instalemos el programa de VMware vSphere Client. También descargué el vCenter que lo

instalaré luego.

Una vez nos hemos descargado el instalador de vSphere Client, comenzamos con instalarlo en

la máquina física o virtual desde donde vamos a administrarlo.


32

Una vez se haya instalado el VMware vSphere Client nos aparece este pequeño recuadro donde

accedemos para poder administrarlo. Colocamos la IP de cualquiera de los dos ESXi, en este caso

la 192.168.10.12, el usuario administrador y su contraseña.

Una vez nos hayamos validado, nos abre una consola donde ya podremos administrar los ESXi

donde buscaremos los almacenamientos compartidos y configuraremos las tarjetas de red.


33

Primero vamos configurar las tarjetas de red, que hemos añadido para poder gestionarla cada

una de ellas para las configuraciones que necesitamos realizar. Vamos a la pestaña de

Configuración y vamos al apartado de Adaptadores de red. Recordamos que hay que realizar 4

redes virtuales:

1 red → Gestión de los ESXi

1 red → Almacenamiento compartido.

1 red → Heartbeat (Tráfico vMotion).

1 red (2 nics) → Fault Tolerance.

Escogemos añadir una nueva red y escogemos que sea de tipo VMkernel, ya que va a hacer para

controlar los servicios como ESXi, vMotion, etc.

Seleccionamos Crear un conmutador estándar de vSphere y seleccionamos una tarjeta nic

disponible.


34

Nos pide que le coloquemos una etiqueta de red, le colocamos un nombre identificativo para

cada red. Este nombre tiene que ser igual en la configuración de los dos ESXis, ya que nos puede

crear conflictos.

Le colocamos una dirección IP para esta red y para finalizar nos aparecería un resumen de cómo

quedaría la configuración de la red.


35

Realizamos la misma configuración para las otras 2 redes restantes, ya que la de gestión ya se

encontraba realizada. Realizamos la misma configuración en el otro ESXi y la configuración de

las redes nos debe quedar así.

Ahora ya que tenemos todas las redes configuradas, vamos a buscar los iniciadores iSCSI para

poder acceder al almacenamiento compartido que hemos configurado en FreeNAS. Vamos a

Adaptadores de almacenamiento y seleccionamos el vmhba33 que el iniciador del ESXi y le

indicamos que queremos agregar


36

Vamos a detección dinámica y agregamos una nueva ubicación del servidor iSCSI. Colocamos la

IP del servidor iSCSI que sería el FreeNAS y el puerto de conexión que es el 3260 le damos a

Agregar y cerrar y ha nos debería aparecer en la parte inferior los dos raid que hemos

configurados. Para terminar, debemos montarlos los raids.

Ahora si vamos a Almacenamiento, vemos que ya nos aparece los dos raids montados.


37

5.4. Instalación y configuración de vCenter Server.

Para instalar el vCenter primero instalamos un servidor Windows Server 2012 con los siguientes

requerimientos:

Procesador: 2 CPUs 64-bit 2.0GHz Intel o AMD x86. Memoria: 8GB RAM Disco: 2 discos (1 para el sistema operativo y otro para la instalación de

vCenter) Red: Adaptador Ethernet (1 Gigabyte recomendado). (Bridged).

5.4.1. Instalación de vCenter Server.

Lo primero que necesitas es descargarnos el instalador o la ISO de vCenter Server.

Luego ejecutamos el instalador de vCenter Server. Lo podremos encontrar como autorun.


38

A continuación, se abrirá la ventana de “VMware vCenter Installer” y escogemos vCenter Server

for Windows. Esta opción permite instalar vCenter Server y todos sus componentes en una

máquina física o virtual con Windows. Contiene todos los componentes, tales como el PSC y el

vCenter Server. Para continuar hacemos clic en Install.

Después nos aparecerá la pantalla de bienvenida y hacemos clic en Next.


39

Leemos y aceptamos el EULA. Después hacemos clic en Next.

En el paso siguiente, seleccionamos el tipo de despliegue Embedded Deployment y después

hacemos clic en Next.

vCenter tiene dos tipos de deployment:

Embedded Deployment: Instala el PSC y el vCenter Server en un mismo sistema

(máquina virtual o física). Por lo general, recomendado para ambientes pequeños. Es el

que utilizaré en este proyecto.

External Deployment: Este tipo permite instalar el PSC y el vCenter en dos sistemas

distintos. Es recomendado para ambientes grandes.


40

En el siguiente paso escribimos el FQND o dirección IP del servidor en donde se está instalando

el vCenter Server. Para continuar hacemos clic en Next.

En el siguiente paso nos pide especificar la configuración del SSO. Creamos un nuevo dominio

de SSO que será vsphere.local, vemos que el nombre del usuario por defecto es administrator.

Escribimos la contraseña y la confirmación de la misma.

NOTA: Si colocamos una IP, está IP no puede ser cambiada, ya que causó problemas y no

me permitía acceder a la plataforma de administración del vCenter Server. Incluso lo

pone en la parte inferior de la pantalla.


41

En el siguiente paso especificamos el vCenter Server Service Account. Por defecto, vCenter

Server se conecta con la cuenta del usuario local. Si deseamos conectarnos con otra cuenta de

usuario, la especificaríamos en Specify a user service account. Para continuar, hacemos clic en

Next.

Ahora nos pide que especifiquemos la base de datos. Como la utilizamos en un ámbito pequeño,

seleccionamos la opción Use an embedded database. Para continuar hacemos clic en Next.

Podemos escoger entre una base de datos embebida o externa. vPostgres es la base de datos

embebida, esta base de datos nos permite hasta 20 ESXi y 200 VMs. Si el entorno es más grande

tendríamos que utilizar base de datos externas como Microsoft SQL y Oracle.


42

El siguiente paso nos indica la configuración de los puertos. Si no tenemos que configurar nada

la dejamos por defecto. Hacemos clic en Next para continuar con la instalación.

Es necesario que vCenter pueda enviar y recibir datos hacia los ESXis, Web Client y PSC. Si alguno

de los puertos está siendo usado, el instalador nos mostrará un error y tendríamos que cambiar

para poder continuar.

El siguiente paso es Destination Directory. Para una mejor práctica, debemos instalar el vCenter

Server en un disco diferente al del sistema operativo. Después hacemos clic en Next para

continuar.

NOTA: Durante toda la realización del proyecto lo instalé en el disco E, pero al

caducarse la licencia he tenido que instalarlo de nuevo en una máquina nueva.


43

Ready to Install. En este paso verificamos que los parámetros que hemos configurado en los

pasos anteriores sean correctos y después hacemos clic en Install.

Una vez finalizada la instalación, nos aparecerá la siguiente ventana y hacemos clic en Launch

vSphere Web Client.


44

Ahora ya podemos validarnos con el nombre de usuario seguido de @, el nombre de dominio y

la contraseña que habíamos configurado durante la instalación

5.4.2. Configuración de vCenter Server.

Ahora procedemos a configurar el vCenter Server. Lo primero que tenemos que hacer es crear

el Datacenter para el proyecto. Nos colocamos sobre la IP del vCenter Server y hacemos clic

derecho y escogemos New Datacenter.

NOTA: Es necesario instalar Adobe Flash Player para poder emplear el

Web Client. Es decir, que necesitamos utilizar como navegador Google

Chrome, ya que en Internet Explorer no está instalado.


45

Ahora pide que se le asigne un nombre y le pongo el nombre de Proyecto y hacer clic en OK para

crearlo.

Ya vemos que se ha creado el Datacenter, ahora creamos el clúster donde daremos la

disponibilidad y el rendimiento. Hacemos clic derecho sobre el datacenter creado Proyecto y

escogemos la opción de New Cluster.

Nos pide que le pongamos un nombre, yo le puse el nombre Alta disponibilidad. Aquí ya nos

indica que podemos activar y configurar HA y DRS, pero lo dejo para más adelante. Ahora solo

creo el clúster.


46

Una vez creado el clúster Alta disponibilidad, añadimos los hosts ESXi al clúster. Sobre el clúster

creado Alta disponibilidad hacemos clic derecho y escogemos Add Host.

Nos aparece un cuadro de configuración para añadir el host. Primero nos pide que coloquemos

el nombre o la IP del host a añadir, le colocamos la IP de uno de los ESXi 192.168.10.11.y le

damos a Next para continuar.


47

Ahora en Connection settings nos pide que coloquemos el nombre de usuario de administración

con el que hemos creado el host y su contraseña. Para continuar clic en Next.

En Host summary nos indica los datos del host y las máquinas virtuales que tiene el host, si es

que tiene alguna creada en él. Hacemos clic en Next.


48

Luego en Asign license nos indica que le coloquemos la licencia del producto, como es de prueba

no le colocamos nada y hacemos clic en Next para continuar.

En Lockdown mode, dejamos la opción que nos marca por defecto la de Disabled.


49

Para finalizar en Ready to complete, vemos que nos indica que toda la configuración está

realizada.

Realizamos lo mismo con el host 192.168.10.12.


50

Ahora vemos que nos aparecen los hosts junto con las máquinas virtuales que se encontraban

en el host 192.168.10.12. Con esto ya hemos realizado la configuración básica. Ahora

empezaremos con la configuración de las funcionalidades de VMware vSphere.

6. Configuración de las funcionalidades de vSphere.

Una vez configurado el vCenter ya podremos configurar las funcionalidades que hemos

comentado en los apartados anteriores.


51

6.1. Configuración de vMotion y Storage vMotion.

Para poder configurar vMotion y Storage vMotion, como ya lo habíamos indicado debemos

dedicar una red virtual a vMotion y tenemos que indicar que se acepte el tráfico para vMotion.

Esto es si no lo habíamos habilitado ya cuando configuramos las redes en el VMware vSphere

Client.

6.2. Configuración de High Availabity (HA).

Vamos al clúster creado, nos colocamos sobre él, hacemos clic derecho y escogemos la opción

Edit Settings. Ahora vamos al apartado de HA y lo activamos seleccionando la casilla Turn On

vSphere HA y configuramos los siguientes parámetros:

Habilitamos Host Monitoring, pero es importante que lo deshabilitemos cuando vayamos a

realizar tareas de mantenimiento sobre un host, ya que el clúster HA entraría en mantenimiento

y comenzaría a mover máquinas virtuales entre los hosts miembros del clúster. También

habilitamos Protect against storage Connectivity Loss.


52

Habilitamos Admission Control, esto sirve para que el clúster siempre tenga reservados los

recursos necesarios en caso de fallo. En el apartado de Admission Control Policy le indicamos

que permitamos la caída de un host.

En el apartado de Virtual Machine Options, le indicamos la prioridad de restauración de las

máquinas virtuales.


53

Para finalizar, en Datastore Hearbeating, seleccionamos el almacenamiento de los dos RAIDs

configurados en FreeNAS (Raid y Raid2).

Guardamos toda la configuración realizada.

6.3. Configuración de DRS.

Ahora es el turno de configurar DRS. Al igual que HA seleccionamos la casilla Turn On vSphere

DRS. Como DRS tiene varias maneras de configurarse y verlas un poco cada una, las

configuraremos cuando realicemos las pruebas. De momento dejamos con la configuración por

defecto.


54

6.4. Configuración de FT.

Dentro del clúster HA creado, vamos a la máquina virtual que tenemos en uno de los hosts y

hacemos clic derecho y buscamos la opción de Fault Tolerance.

Nos aparece un pequeño mensaje que nos indica que para configurar Fault Tolerance en el host

es insuficiente, ya que el ancho de banda para Fault Tolerance es insuficiente. Como lo vimos en

los requisitos se necesita una tarjeta de 10GB Ethenet, pero podemos aplicarlo igual.


55

Ahora nos pedirá que seleccionemos los en donde queremos almacenar el disco de la VM

secundaria y los archivos de configuración de la misma. Para verificar nos indicará que es

compatible.

Luego nos pedirá que seleccionemos el host en donde queremos colocar la segunda máquina

virtual (lo recomendable sería colocarlo en otro diferente al que se encuentra la máquina virtual

principal).


56

Una vez se haya configurado FT si nos vamos al nodo donde se encontraba la máquina principal,

veremos que nos aparece indicando que ella es la principal (primary).

Y si vamos al otro host vemos que nos aparece una segunda máquina (secundary) de la principal

que se encuentra a la espera de algún error en la máquina principal para ejecutarse.

7. Pruebas.de las características.

Vamos a realizar unas pruebas para verificar que todas las características han sido configuradas

y funcionan correctamente.

7.1. Pruebas con vMotion.

Para probar vMotion cogeremos cualquier máquina virtual y la cambiaremos manualmente del

host donde se encuentra al otro.

Cogemos la máquina virtual Ubuntu_server y la arrastramos para cambiarla del host

192.168.10.11 al host 192.168.10.12

Para verificar que se hace la prueba correctamente la máquina virtual tiene que estar encendida

y en funcionamiento.


57

Al hacer este cambio nos aparece un cuadro indicando que Ubuntu server se va a migrar.

El primer paso nos indica que tipo de migración queremos hacer, seleccionamos la de Change

compute resource only, con esta opción indicamos que la máquina virtual se migrará a otro host

u otro clúster.


58

En el paso 2 nos indica que seleccionemos el host o clúster donde queremos arrancar de nuevo

esta máquina virtual. Seleccionamos el host 192.168.10.12 que es al que vamos a migrar la

máquina virtual Ubuntu_server. En la parte inferior nos indica si es compatible, si no lo fuera no

nos dejaría avanzar con la migración.

Si tuviéramos otro clúster configurado también podríamos cambiarlo de clúster.

En el paso 3 nos pide que seleccionemos la red de destino pero que ya la hemos configurado

antes.


59

Ahora nos indica la prioridad de vMotion y dejamos la que nos indica por defecto y que es la

recomendada.

Ahora nos indica que verifiquemos que la información es correcta y hacemos clic en Finish para

comenzar con la migración de la máquina virtual.


60

Ahora vemos que la máquina virtual Ubuntu_server ha cambiado al host 192.16810.12 y

también en la parte inferior en Recent Tasks nos muestra una tarea donde nos indica que la

máquina virtual se ha trasladado completamente.

Para finalizar nos colocamos sobre la máquina virtual Ubuntu_server y vamos al apartado de

Monitor → Events → Buscamos las últimas tareas y veremos que nos da información que la

máquina virtual ha sido migrada con vMotion.


61

7.2. Pruebas con Storage vMotion.

De la misma forma como realizamos las pruebas con Storage vMotion, en sí solo cambian

opciones cuando migramos una máquina.

En esta prueba escogemos la máquina virtual FTP que se encuentra en el host 192.168.10.11 y

la arrastramos hacia el host 192.168.10.12 para migrarla.

Ahora le indicamos que cambiemos tanto el recurso como el almacenamiento o cambiar el

almacenamiento del recurso solamente y que cual de los dos se cambie primero.


62

Ahora cambiamos la máquina virtual al host que hemos seleccionado 192.168.10.12.

Ahora escogemos sobre que datastore queremos colocar la máquina virtual, esto nos sirve que

ya que migramos la VM de forma manual la cambiemos de almacenamiento en caso de que uno

de los datastores se encuentre casi sin capacidad. Le indicamos que lo haga sobre el raid2 que

como vemos es el de mayor capacidad.

Ahora al igual nos indica que la red por donde queremos transportarlo.


63

También le indicamos la prioridad y escogemos la recomendada.

Al final nos indica que verifiquemos todo lo que hemos configurado para realizar la migración.

Al final hemos visto vemos como la máquina ha cambiado de host correctamente.


64

7.3. Pruebas con HA.

Ahora realizaremos una prueba para verificar que HA sido configurado correctamente. Para ello

vamos a simular una catástrofe donde uno de los hosts se ha caído. En este caso, simularemos

que el host 192.168.10.12 se cae repentinamente, para ello lo apagaremos directamente.

Vemos que los hosts siguen trabajando normalmente y que la máquina virtual Ubuntu_server

está iniciada en el host 192.168.10.12 que es donde hemos simulado la caída, para ver que nos

cambia de host automáticamente.

Vemos como ya nos empiezan a indicar los problemas en el host 192.168.10.12 indicando que

no responde y que vSphere HA detectado una posible falla en este host.

Pero si nos colocamos sobre la máquina virtual vemos que ha cambiado automáticamente al

host 192.168.10.11.


65

Si nos vamos a la consola de la máquina virtual donde estábamos trabajando vemos que nos

indica que la consola ha sido desconectada.

Si la recargamos vemos que nos aparece la máquina encendida, pero se nos inicia desde el login

y no desde donde la hemos dejado trabajando.


66

7.4. Pruebas con FT.

Para probar FT lo que haremos será tirar abajo el host donde se encuentra la máquina virtual

principal donde estaremos ejecutando cualquier función en el Ubuntu Server.

Una vez tirado el nodo abajo nos aparece una alerta indicando que el host 192.168.10.11 no

tiene conexión, comprobaremos que en ningún momento perdemos la conexión, ya que la

máquina virtual secundaria se activaría como principal y no habría ningún tiempo de inactividad,

y también verificamos que la máquina virtual ha cambiado del host 192.168.10.11 al

192.168.10.12.


67

Si nos vamos a consola que tenemos abierta de nuestra máquina en ejecución, veremos que nos

indica que “la consola ha sido desconectada”, solo necesitamos actualizarla y ya seguiría en

ejecución donde la habíamos dejado.

7.5. Pruebas de DRS

7.5.1. DRS manual.

Vamos a hacer pruebas con DRS, primero lo haremos con DRS en manual

Ahora vemos que todas las máquinas se encuentran en el host 192.168.10.12


68

Por medio de un pequeño código estresamos varias veces la máquina virtual Ubuntu_server con

el comando stress.

El comando para estresar con la salida:

stress -c -i -m

-c para las sobrecargas con el cpu

-i para sobrecargas en i/o

-m para sobrecargas en la memoria.

Para sobrecargas sobre el CPU con el comando stress

Stress -v -c 20000 -n -t 10

Donde 20000 es la cantidad de trabajos a realizar que se sobrecargan al cpu lo cual se realizó en

13 segundos. Esto es llamando a la función sqrt.


69

Si vamos al clúster, buscamos la pestaña de Monitor y vamos al apartado de vSphere DRS

veremos las recomendaciones que nos indica DRS al encontrarse en modo Manual, vemos que

nos indica que la máquina Ubuntu_Server debe ser migrada del host 192.168.10.12 al host

192.168.10.11. Le damos a Apply Recommendations para aplicar la migración

En el apartado inferior vemos las tareas recientes y vemos que la migración se encuentra en

progreso y que de momento en el host 192.168.10.12 no se encuentra ninguna máquina virtual.


70

Luego vemos que la tarea se ha realizado completamente y que máquina virtual ha migrado ya

hacia el host

7.5.2. DRS manual con reglas DRS.

Primero configuramos una regla DRS la que será la de Separate Virtual Machines. Vamos DRS y

buscamos la opción de Configuration →VM/Host Rules, le colocamos un nombre orientativo, le

indicamos el tipo de regla que ya hemos indicado que será la de separar máquinas virtuales y

sobre que máquinas queremos que se aplique esta regla, en este caso las máquinas virtuales

FTP y ubuntu_server2


71

Una vez configurada y guardada la regla, precedemos a encender las máquinas virtuales.

Recordar que DRS aplicaba sus recomendaciones de dos maneras una al encender las máquinas

virtuales y otra al consumo de los recursos.

Encendemos la máquina virtual FTP y vemos que nos indica dos recomendaciones:

Encenderla en el host 192.168.10.11 con prioridad de nivel 5 o encenderla en el host

192.168.10.12 con la misma prioridad de nivel 5.

Escogemos la primera recomendación y la máquina se encenderá en el host 192.168.10.11

aunque en ese momento se encuentre en el otro host.

Procedemos a encender la máquina Ubuntu_server, así mismo nos da dos recomendaciones,

pero en este caso nos indica que encienda en el host 192.168.10.12 con una prioridad de nivel

1 o que se encienda en el host 192.168.10.11 con una prioridad de nivel 5.


72

Para finalizar encendemos la máquina virtual Ubuntu_server2, en está vemos que solo nos

recomienda que se encienda en el host 192.168.10.12 con una prioridad de nivel 1. Esto se debe

a que la regla de anti afinidad configurada no nos permite poner está máquina virtual en el

mismo host donde encendimos la máquina virtual FTP y por eso prácticamente nos obliga a

encenderla en el host 192.168.10.12.

Ahora para esta prueba colocaremos todas las máquinas virtuales en el mismo host con el

vMotion, que será el 192.168.10.12 y como hemos configurado una regla de anti afinidad de

que la máquina ftp y la máquina Ubuntu_server2 estén en host diferentes.

Cuando estresamos las máquinas que se encuentran en el host 192.168.10.12 aunque no

estresemos la máquina virtual FTP nos dará la recomendación que la esta máquina debe ser

migrada al host 192.168.10.11 y también nos indica que la razón es porque tiene que aplicar una

regla de anti afinidad. Esto también se debe a cuando hemos encendido las máquinas nos ha

indicado unas recomendaciones de donde colocar las máquinas virtuales, FTP le indique

colocarla en el host 192.168.10.11 y ubuntu_server2 ya que no debía de estar en el mismo host

solo me dio una recomendación de colocarla en el host 192.168.10.12.


73

7.5.3. DRS automático.

Ahora vamos a configurar DRS automático.

Primero tenemos que verificar que tipo de configuración tienen las máquinas virtuales ya que

no dejarían probar correctamente este tipo de DRS.

Vamos al clúster Alta disponibilidad → Manage → Settings → Configuration → VM Overrides y

vemos que tipo de configuración de Nivel de Automatización DRS tienen las máquinas virtuales,

para ello tienen que estar en modo Fully Automated.

Ahora ponemos en Fully Automated el DRS y vamos a ver si las máquinas que se encuentran en

el host 192.168.10.12 después de estresarlas cambian de host automáticamente


74

Después de estresar las máquinas vemos que la máquina virtual Ubuntu_server ha cambiado al

host 192.168.10.11 sin que nos hiciera recomendación alguna. Lo que si podemos es ver que

nos ha indicado una tarea donde nos indica que DRS ha hecho la migración de la máquina virtual

de forma automática


75

8. Conclusión.

Después de haber practicado y realizado las funciones de VMware vSphere he llegado a la

conclusión que a pesar de su precio es ideal para la alta disponibilidad, rendimiento y ahorro en

costes para quién desee utilizar esta plataforma de la virtualización dentro de una organización

Es un producto muy potente que como ya hemos visto tiene muchas más funcionalidades para

garantizar a las organizaciones, una disponibilidad completa los 365 días del año, si se configura

los servicios de tal manera que el administrador ejecute en lo menor posible las tareas de

configuración y mantenimiento.

Incluso alguien (persona o empresa) que quiera dar servicios a otras organizaciones tiene una

herramienta ideal para su objetivo, gestionándolo desde la nube.

Después de haber llevado tiempo con el proyecto, pude encontrar mucha información que es

importante para el manejo del servicio de DRS, con todas las reglas que se pueden configurar

con él. Me quedo pendiente realizar y configurar Storage DRS que también tiene reglas para su

mejor funcionamiento.

También, aunque haya demorado mucho en configurarse FT debido a las limitaciones con el

ancho de banda, fue muy gratificante poder haberlo visto funcionar y ver cómo, aunque se caiga

un host, no perdemos las configuraciones que estemos realizando, ya sea instalando un

programa o subiendo archivos a un servidor.

Todo esto me ayuda a seguir investigando sobre todo el resto de funcionalidades, ya que tiene

muchas y no he podido configurar, así como en un futuro poder implementar el proyecto inicial.

Aunque no había mucha documentación sobre la versión actual con manuales y versiones

anteriores se iba configurando lo mayormente posible. Sobre todo, me ha ayudado con los

conceptos técnicos.


76

9. Bibliografía VMware vSphere

https://www.vmware.com/es/products/vsphere

Precios licencias

http://www.vmware.com/es/products/vsphere/pricing

vCenter

http://www.colombiavirtualizada.com/2015/03/18/instalacion-de-vcenter-server-6-0-parte-2/

vMotion y Storage vMotion

http://en.megacrack.es/2012/10/22/como-configurar-vmotion-en-vmware-esxi/

https://www.josemariagonzalez.es/2010/05/10/beneficios-vmware-storage-vmotion.html

HA

http://patriciocerda.com/2011/09/vsphere-5-como-funciona-ha-y.html

http://federicocinalli.com/blog/item/191-la-red-de-vmware-vsphere-ha#.V0f2CpGLTIV

DRS

http://www.unixarena.com/2014/02/configure-drs-cluster-esxi.html

https://virt.es/curso-de-vmware-5-5-drs-y-dpm/

http://blog.ragasys.es/configurar-y-gestionar-un-cluster-ha-y-drs-en-vsphere-6-0

https://www.josemariagonzalez.es/2010/12/06/polticas-afinidad-clster-vmware-drs.html

FT

http://patriciocerda.com/2015/02/vsphere-6-0-mejoras-y-funcionamiento-de-fault-

tolerance.html

http://www.colombiavirtualizada.com/2014/08/03/cosas-acerca-de-fault-tolerance-en-

vmware-vsphere-5-5/

http://www.tundra-it.com/uso-de-vmware-ft/

https://www.vmware.com/es/products/vsphere

http://www.vmware.com/es/products/vsphere/pricing

http://www.colombiavirtualizada.com/2015/03/18/instalacion-de-vcenter-server-6-0-parte-2/

http://en.megacrack.es/2012/10/22/como-configurar-vmotion-en-vmware-esxi/

https://www.josemariagonzalez.es/2010/05/10/beneficios-vmware-storage-vmotion.html

http://patriciocerda.com/2011/09/vsphere-5-como-funciona-ha-y.html

http://federicocinalli.com/blog/item/191-la-red-de-vmware-vsphere-ha#.V0f2CpGLTIV

http://www.unixarena.com/2014/02/configure-drs-cluster-esxi.html

https://virt.es/curso-de-vmware-5-5-drs-y-dpm/

http://blog.ragasys.es/configurar-y-gestionar-un-cluster-ha-y-drs-en-vsphere-6-0

https://www.josemariagonzalez.es/2010/12/06/polticas-afinidad-clster-vmware-drs.html

http://patriciocerda.com/2015/02/vsphere-6-0-mejoras-y-funcionamiento-de-fault-tolerance.html

http://patriciocerda.com/2015/02/vsphere-6-0-mejoras-y-funcionamiento-de-fault-tolerance.html

http://www.colombiavirtualizada.com/2014/08/03/cosas-acerca-de-fault-tolerance-en-vmware-vsphere-5-5/

http://www.colombiavirtualizada.com/2014/08/03/cosas-acerca-de-fault-tolerance-en-vmware-vsphere-5-5/

http://www.tundra-it.com/uso-de-vmware-ft/

Technology

W mware v_sphere_proyecto_final