Implementacion de una infraestructura en VMware 5.5

Implementación de

una infraestructura

en VMware 5.5

Xavier Montolio

Josep Mª Vellido

VIRTUALIZACIÓN ASIX2

Índice

Título pág 1. Introducción ........................................................................................... 1

1.1 Virtualización ....................................................................................... 2

1.2 Hipervisor Bare-Metal .............................................................................. 6

1.3 Tipos de virtualización ........................................................................... 11

2. ESXi .................................................................................................... 18

3. vCenter Server ........................................................................................ 24

3.1 VMware vSphere ................................................................................... 28

3.2 vSphere Client Web ............................................................................... 43

4. Arquitectura del proyecto .......................................................................... 46

5. Almacenamiento compartido ....................................................................... 49

6. vMotion ................................................................................................ 59

7. Storage vMotion ...................................................................................... 62

8. Cluster ................................................................................................. 67

8.1 HA ................................................................................................... 69

8.2 DRS .................................................................................................. 75

9. Storage DRS ........................................................................................... 85

10. Fault Tolerance .................................................................................... 90

11. Conclusión del Proyecto .........................................................................103

12. Webgrafía..........................................................................................105


1

1. Introducción

El proyecto realizado ha consistido en la Virtualización, los tipos de ésta y como trabajar en

un entorno capaz de administrar un Datacenter, con su Cluster, con sus hosts y sus máquinas

virtuales.

La característica principal ha sido la administración de máquinas virtuales en un entorno

capaz de agregarle funciones para mejorar el sistema de virtualización.

Nos decidimos en hacer este trabajo porque nos parecía un tema interesante y que podíamos

profundizar todavía más, ya que en Internet no hay mucha información sobre las nuevas

versiones que está utilizando VMware y ESXi con su virtualización. Como es un concepto nuevo

y con mejores capacidades y tecnologías, los usuarios normales no han desarrollado, todavía,

este tipo de proyectos. Y podemos decir que nosotros somos de los primeros usuarios que

investigan sobre algunas funciones recién salidas al mercado.

También supone una motivación especial debido a que nuestros estudios se basan en los

Sistemas y queríamos saber si nosotros mismos podíamos ir más allá.

El trabajo realizado ha sido pensado para un entorno empresarial. Es decir, aunque

seguramente las empresas necesitarían más recursos en cualquier situación, nosotros hemos

valorado e implementado funciones que muchas empresas utilizan para la mejora de la

virtualización, totalmente necesarias para dar una alta disponibilidad y redundancia al cliente

que alquila sus servidores.

En cuanto al método de trabajo, hemos necesitado del uso de 3 máquinas físicas con 8 GB de

RAM cada una y con un procesador Intel Core i3.

A la hora de buscar información, primero hemos encontrado la documentación y entendido

todas las funciones que realizaban nuestras implementaciones en el proyecto. Más tarde

hicimos la configuración necesaria en el programa y por último la prueba y/o testeo de estas

aplicaciones para comprobar si realmente era la función que queríamos, si podíamos ir un

paso más allá o si la configuración no era del todo correcta.

El proyecto también ha tenido alguna limitación, sobretodo en cuanto a Hardware de las

máquinas físicas. Aunque con 8 GB de RAM por PC y un procesador Intel Core i3, con unos

recursos mejores se podía haber realizado la práctica más cómodamente.

En algunas situaciones, al tener unas 3 o 4 máquinas virtuales, la CPU daba advertencias de

que podía llegar a su máximo.

También cabe destacar que no hemos trabajado con un entorno 100% real en cuanto a

virtualización. Ya que los Sistemas Operativos ESXi deben estar instalados en la misma

máquina y por falta de dichos recursos (básicamente 2 PCs limpios que no teníamos) no hemos

podido instalar esos Sistemas Operativos en la misma máquina.


2

En este caso hemos utilizado el programa VMware Workstation para hacer la simulación de

todos estos casos. Pero debe quedar claro, que esto no es la virtualización en la que se ha

basado el proyecto. Más adelante explicaremos los tipos de virtualización que hay y se

entenderá este proceso realizado.

La finalidad y/u objetivos de este proyecto ha sido analizar las características que aportan

VMware y la utilización de estos en un mundo laboral, así como diferenciar lo que hace una

virtualización totalmente física y real.

1.1 Virtualización

¿Qué es la virtualización? pues si seguimos la típica definición de Wikipedia, sería:

Es la creación -a través de software- de una versión virtual de algún recurso tecnológico,

como puede ser una plataforma de hardware, un sistema operativo, un dispositivo de

almacenamiento u otros recursos de red.

Es decir, que la virtualización utiliza la combinación de Hardware y Software para que un

recurso físico pueda funcionar con buen rendimiento.

La historia de la virtualización se remonta a los años 60-70. Ya que en los 60 ya podíamos

conocer el término "pseudo-máquina" y en los 70 ya tuvimos una empresa (IBM) que desarrolló

sistemas con soporte de virtualización.

Un componente llamado Virtual Machine Monitor (VMM) ejecutaba varias instancias de

sistemas operativos sobre el hardware real. Aunque fue una idea muy popular en esos años,

en los 80 no gustó tanto, ya que el hardware era barato, se necesitaban PCs y Sistemas

Operativos multiusuarios que carecerían en aquellas épocas.

Pero la idea volvió a tener sentido en los 90, esto concuerda con la fundación de VMware y el

lanzamiento de su primer producto (VMware Workstation). Más tarde también se inventarían

versiones como Xen y otras tecnologías.

En la virtualización podemos encontrar dos conceptos muy importantes:

- Anfitrión/Host. Es el sistema operativo que ejecuta el software de virtualización. Este S.O.

anfitrión controla el hardware real.

- Invitado/Guest. Es el sistema operativo virtualizado. Puede haber varios S.O en un mismo

host. Estos invitados no pueden interferir ni entre ellos, ni con el anfitrión.


3

Gráficamente este sería el ejemplo explicado:

Varias máquinas de sistemas operativos diferentes en un mismo servidor.

Al software de virtualización se le llama: Hipervisor.

Éste se encarga de ejecutar como parte del sistema host o es el mismo host.

La instancia del hardware virtualizado se la conoce como Máquina Virtual. Y los sistemas

operativos se ejecutan dentro de una máquina virtual.

Las características de un Hipervisor:

- Permiten que diferentes SSOO, tareas y configuraciones de software coexistan en una

misma máquina física.

- Abstraen los recursos físicos de la máquina anfitriona para las distintas máquinas

virtuales.

- Garantizan un nivel de aislamiento entre los invitados.

- Proporcionan una interfaz única para el hardware.

Existen dos tipos de Hipervisores:


4

Tipo 1. Llamado también "nativo" o "bare-metal". El hipervisor se ejecuta

directamente sobre el hardware y gestiona los Sistemas Operativos invitados.

- Al sistema operativo se le llama Dominio de control y se ejecuta sobre el hipervisor.

- Los invitados son Dominios Lógicos.

- Algunos ejemplos como: Xen, Citrix, XenServer, KVM, VMware ESX/ESXi, Microsoft Hyper-V.

Tipo 2. Conocido como "hosted". El hipervisor se ejecuta en el entorno de un sistema

operativo. Es decir, representa una capa software que se ejecuta sobre el sistema

operativo anfitrión.

- Ejemplos: VMware Workstation, VMware Server, VirtualBox, QEMU, Microsoft Virtual PC,

Oracle VM VirtualBox.

.


5

¿Qué ventajas aporta la virtualización?

- Reutilización de hardware existente (para utilizar software más moderno).

- Optimizar el aprovechamiento de todos los recursos de hardware.

- Rápida incorporación de nuevos recursos para los servidores virtualizados.

- Reducción de costes y consumo.

- Administración global centralizada y simplificada.

- Permite gestionar un CPD como una agrupación para toda la capacidad de recursos

(procesador, memoria, red, almacenamiento) dentro de una infraestructura.

- Mejora en los procesos de clonación y copia de sistemas: Mayor facilidad para la

creación de entornos de test que permiten poner en marcha nuevas aplicaciones sin

impactar a la producción, agilizando el proceso de las pruebas.

- Aislamiento: un fallo general de sistema de una máquina virtual no afecta al resto de

máquinas virtuales.

- Reduce los tiempos de parada.

- Migración en caliente de máquinas virtuales (sin pérdida de servicio) de un servidor

físico a otro, eliminando la necesidad de paradas planificadas por mantenimiento de

los servidores físicos.

- Balanceo dinámico de máquinas virtuales entre los servidores físicos.


6

1.2 Hipervisor Bare-Metal

Como hemos comentado anteriormente. El Hipervisor que utilizaremos será el de “Tipo 1”

que también es llamado “Bare-Metal” o “nativo”. Hay que tener en cuenta que este tipo de

virtualización tiene el Hipervisor después del Hardware real. No hay un sistema operativo, ya

que él mismo es el Sistema operativo.

En casos como VMware Workstation, Virtual Box y otras plataformas con máquinas virtuales

son del tipo 2.

La virtualización Bare-Metal es mucho más útil. Primero de todo porque ganamos en recursos

y dedicamos la máquina exquisitamente dicho Hipervisor. Si utilizaremos una máquina virtual

en VMware ya tendríamos “el lastre” de tener el S.O iniciado.

Para entender mejor como funciona, tenemos este gráfico:

Como hemos comentado. Primero está el sistema físico, es decir, el hardware, la máquina

real en sí. En dicha máquina instalamos ya de por si el Hipervisor (hay muchos tipos) y ya

dentro de éste estarán las demás máquinas virtuales instaladas.

Un hipervisor bare-metal no funciona bajo un sistema operativo instalado sino que tiene

acceso directo sobre los recursos hardware. Esto significa que obtendremos un

mejor rendimiento, escalabilidad y estabilidad. Por contra, en este tipo de tecnología de

virtualización el hardware soportado es más limitado ya que normalmente es construido con

un conjunto limitado de drivers.

La tecnología bare-metal se adapta mejor a centros de datos empresariales. Esto es porque

dispone de características avanzadas como la administración de recursos, alta disponibilidad,

seguridad y administración centralizada de la infraestructura de virtualización.


7

El mercado ofrece varios tipos de Hipervisores a alto nivel. Los más importantes y conocidos

son:

VMware ESX y ESXi

VMware es el fabricante con la tecnología de virtualización más madura del mercado. Ofrece

características avanzadas y escalabilidad. En contra tiene los altos costes de licenciamiento.

Microsoft Hyper-V

Desde su lanzamiento, Hyper-V se ha convertido en un serio competidor de VMware ESX

(ESXi). En contra tiene que no dispone de ciertas características avanzadas disponibles en los

productos de VMware. De todos modos, como no podía ser de otra forma, se integra

perfectamente con los productos Windows. Para aquellos que no necesitan funcionalidades

avanzadas, puede ser un producto perfecto para llevar a cabo su proyecto de virtualización.

Citrix XenServer

Citrix también tiene una plataforma de virtualización basada en el proyecto Open SourceXen.

El hipervisor es gratis, pero de igual modo a como pasa con VMwareESXi, no dispone de

características avanzadas. Éstas se obtienen a partir de licencias que ofrecen gestión

avanzada, automatización y alta disponibilidad.

Oracle VM

De igual modo a Citrix, Oracle ha desarrollado su hipervisor a partir del proyecto Xen. El

producto de Oracle no presenta funcionalidades avanzadas que podemos encontrar en otros

hipervisoresbare-metal. Además su ciclo de desarrollo es lento y limitado, por lo que no

puede competir con los productos de VMware, Microsoft o Citrix. Sin embargo, como es

lógico, es un producto que se adapta perfectamente a los productos de Oracle.


8

En la siguiente tabla comparativa mostraremos las funciones de los 3 productos más potentes

de mercado en cuanto al mundo de la virtualización. Todos aportan un gran nivel de

características.

Funciones

VMware ESX

Microsoft Hyper-V

Citrix XenServer

Migración de

máquinas virtuales

Sí Sí Sí

Migración

automática

Sí Sí No

Power Management Sí Sí No

Migración de

almacenamiento

Sí Sí Sí

Tamaño del Cluster 32 hosts y 4000 VMs 64 hosts y 8000 VsM 16 hosts

Fault Tolerance Sí No No

High Availability Sí Sí No

App HA Sí Sí No

Replicación Sí Sí Sí

Copia de Seguridad

integrada

Sí Sí No

Compatibilidad

Hardware

Alta compatibilidad

general

Alta compatibilidad

con Windows

Algo limitada

Líder en el mercado 1 2 3

Precio anual 3.500$ 6.100$ 500$


9

Analizando la tabla comparativa, los tres son capaces de administrar un Datacenter con las

opciones básicas.

La migración de máquinas virtuales es algo fundamental y que cualquier empresa tendrá dicha

opción. Así como la migración del almacenamiento.

En cuanto a la migración automática, llamada DRS en VMware ESXi o Gestión de Memoria en

Hyper-V, podemos apreciar como Citrix no dispone de esa función. Si quieres dar un paso

más, necesitarás esta función, capaz de coordinar los recursos de los hosts y equilibrar la

carga entre ellos. En cuanto a optimización y consumo de energía es muy útil.

"Power Management" va ligada con la migración automática. Ya que utiliza también la

administración de recursos para reducir los propios recursos físicos y balancear los hosts.

Depende de la función de cada producto, pero es capaz de bajar un 20% la energía de un host.

Si hablamos de capacidad y el tamaño que puede adquirir un cluster, sin duda Hyper-V es el

que menos límites pone. 64 hosts y 8000 máquinas virtuales dentro de un Cluster, la mitad

puede llegar a almacenar el ESXi con 32 hosts y 4000 máquinas. Citrix se queda bastante atrás

con solo 16 hosts por cluster.

Una función que en estos momentos solo puede conseguirse en ESXi es Fault Tolerance.

Hyper-V no cuenta con ella y es una característica que permite una alta disponibilidad

bastante importante. Si un host se cae, y la máquina que está hospeda en dicho host, gracias

a la función Fault Tolerance (siempre que esté habilitada, claro) será capaz de migrarse a un

segundo host. Lo más importante, sin duda, es la NO pérdida de actividad. Es decir, sin

downtime. La opción HA con vMotion si tiene ese parón mientras migra las páginas. Fault

Tolerance evita la inactividad.

La opción App HA es una opción bastante avanzada, capaz de restaurar objetos y funciones en

mal estado. Como es a un nivel importante, para obtener dicha función, es necesario pagar un

poco más u obtener funciones más "Plus".


10

En cuanto a replicación, todos pueden adquirirla. Y en cuanto

Copia de Seguridad integrada, con Citrix no viene integrada, pero también puedes adquirla.

La compatibilidad del Hardware es un tema que administra muy bien ESXi. Es capaz de

integrarse con muchos componentes y versiones distintas. Todo lo contrario que Windows,

que aunque su nivel es muy alto, solo se adecua bien con componentes propios de Windows, si

se utilizan otras versiones puede dar fallos o falta de compatibilidad. Citrix es la que más

limitación tiene y no llega al nivel de los dos anteriores.

En conclusión, el líder del mercado en estos momentos es ESXi, pero Hyper-V está muy cerca

y es una opción bastante fiable y capaz de darle un gran rendimiento a todas las funciones

para administrar un Datacenter.

En tercer lugar situaríamos a Citrix, que aunque no es mala opción, de las "3 grandes" es la

que menos posibilidades te da. Pero sin duda es una mejor alternativa que Oracle VM, Virtual

Bridges, IBM (PowerVM 2.2), Red Hat (RHEV 3.3) que están por debajo de los ya mencionados.

El precio es relativo, porque hay muchas versiones distintas de cada producto. En este caso

hemos tenido en cuenta los precios anuales con las opciones indicadas y las que vienen por

defecto.


11

1.3 Tipos de virtualización

La virtualización es muy extensa y nos podemos encontrar muchos tipos, nosotros nos

centraremos en los principales, ya que hay muchas formas de catalogar o ver la

virtualización. Algunas personas extienden los tipos en más y otros lo hacen de forma más

comprimida y organizada.

Pero generalmente podemos encontrar estos dos tipos y dentro de ellas subtipos capaces de

hacer virtualizaciones específicas y basadas en algo en concreto.

Virtualización de recursos: esta permite agrupar varios dispositivos para que sean vistos

como uno solo, o al revés, dividir un recurso en múltiples recursos independientes.

Generalmente se aplica a medios de almacenamiento. También existe una forma de

virtualización de recursos muy popular que no es sino las redes privadas virtuales o VPN,

abstracción que permite a un PC conectarse a una red corporativa a través de la Internet

como si estuviera en la misma sede física de la compañía.

Involucra la simulación de recursos básicamente. Sean volúmenes de almacenamiento,

espacios de nombres o recursos de red.

Por ejemplo:

Discos RAID y gestores de volúmenes (como Linux LVM).

Virtualización de almacenamiento como SAN (Storage Area Network).

Redes privadas virtuales (VPN).

Sistemas de multiprocesador y multinúcleo.

Clusters, grid computing, cloud computing.

Las más conocidas y utilizadas:

- Virtualización de almacenamiento.

Es un tipo de virtualización, en donde se unen múltiples dispositivos de almacenamiento en

red, en lo que aparenta ser una única unidad de almacenamiento.

La virtualización de almacenamiento es utilizada en redes de área de almacenamiento, una

subred de alta velocidad que comparte dispositivos de almacenamiento, y realiza tareas de

almacenamiento, respaldo y recuperación de datos de forma más fácil y rápida.

La virtualización de almacenamiento es generalmente implementada vía aplicaciones de

software, hardware y redes.


12

Los sistemas de almacenamiento pueden proveer almacenamiento accedido por bloque o

almacenamiento accedido por fichero. El acceso por bloque generalmente es entregado por

canal de fibra, SAS, FICON u otros protocolos. En tanto el acceso por fichero es generalmente

proviso usando protocolos NFS y CIFS.

Las principales ventajas que tiene son:

- Costes reducidos. Mejora la eficiencia de almacenaje para recortar los gastos de

administración, refrigeración y potencia malgastados en recursos infrautilizados

- Gestión simplificada. Consolida diversos sistemas de almacenamiento en una única fuente

para reducir los gastos administrativos. Facilita la planificación de la capacidad y automatiza

la asignación de capacidad con el aprovisionamiento ajustado.

- Flexibilidad operativa. Posibilita la ampliación del almacenamiento a demanda para

satisfacer de forma dinámica las necesidades cambiantes.

- Disponibilidad aumentada. Consigue escalabilidad sin interrupciones y equilibrado

automático de la carga para minimizar los periodos de inactividad planificados.

Ejemplos:

o LVM en Linux.

o ZFS en Open Solaris.

o Sistemas de ficheros distribuidos (OCFS2, GlusterFS, GFS, etc.).

- Virtualización de Red.

La virtualización de redes es la reproducción completa en software de una red física. Las

redes virtuales cuentan con las mismas características y garantías que una red física. Sin

embargo, ofrecen los beneficios operativos y la independencia del hardware de la

virtualización: aprovisionamiento rápido, implementación sin interrupciones, mantenimiento

automatizado y compatibilidad con aplicaciones nuevas y heredadas.

La virtualización de redes expone los dispositivos y servicios de redes lógicos (puertos,

switches, routers, firewalls, equilibradores de carga, VPN, etc. lógicos) a las cargas de

trabajo conectadas. Las aplicaciones de la red virtual se ejecutan exactamente igual que en

una red física.

Puede crear una estructura de red altamente escalable que proporcione niveles más altos de

agilidad y eficiencia operativas, aprovisionamiento más rápido, solución de problemas y

clonación, con supervisión, calidad de servicio.

Ejemplos:

o Open vSwitch (Linux/FreeBSD).

o Crossbow (OpenSolaris)


13

- Otras:

Memoria Virtual: Se le permite agregar una memoria añadida y virtual. No contaremos

realmente con 1GB de RAM (por ejemplo), pero podrá ser utilizada y virtualizada.

Particiones de Bases de Datos: Es la división de un solo recurso (casi siempre grande),

como el espacio de disco o el ancho de banda de la red, en un número más pequeño y

con recursos del mismo tipo que son más fáciles de utilizar. Esto es muchas veces

llamado “zoning”, especialmente en almacenamiento de red.

Virtualización de plataforma: se trata de simular una máquina real (servidor o PC) con todos

sus componentes (los cuales no necesariamente son todos los de la máquina física) y prestarle

todos los recursos necesarios para su funcionamiento. En general, hay un software anfitrión

que es el que controla que las diferentes máquinas virtuales sean atendidas correctamente y

que está ubicado entre el hardware y las máquinas virtuales. Dentro de este esquema caben

la mayoría de las formas de virtualización más conocidas, incluidas la virtualización de

sistemas operativos, la virtualización de aplicaciones y la emulación de sistemas operativos.

- Virtualización de Emulación o simulación.

La máquina virtual simula un hardware completo, admitiendo un sistema operativo

“guest” sin modificar para una CPU completamente diferente. Este enfoque fue muy

utilizado para permitir la creación de software para nuevos procesadores antes de que

estuvieran físicamente disponibles. Por ejemplo Bochs, PearPC, Qemu sin aceleración,

y el emulador Hercules.

Ventajas: simular hardware que no está físicamente disponible.

Desventajas: bajo rendimiento y un alto conste de computación.


14

- Virtualización nativa o completa.

La máquina virtual simula un hardware suficiente para permitir un sistema operativo

invitado sin modificar (uno diseñado para la misma CPU) para correr de forma aislada.

Típicamente, muchas instancias pueden correr al mismo tiempo. Este enfoque fue el

pionero en 1966 con CP-40 y CP[-67]/CMS, predecesores de la familia de máquinas

virtuales de IBM. Algunos ejemplos: VMware Workstation, VMware Server, Parallels

Desktop, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro y z/VM.

Ventajas: flexibilidad y un alto rendimiento.

Desventajas: no se pueden emular otras arquitecturas.

- Virtualización parcial.

En la virtualización parcial, incluida la dirección de virtualización, la máquina virtual

simula múltiples instancias de gran parte de un entorno de hardware subyacente, en

especial los espacios de direcciones. Por lo general, esto significa que los sistemas

operativos completos no se pueden ejecutar en la máquina virtual (que sería el signo

de la virtualización completa) pero que muchas aplicaciones se puede ejecutar. Una

forma clave de virtualización parcial es la dirección de la virtualización del espacio,

en el que cada máquina virtual consiste en un espacio de direcciones independiente.

Esta capacidad requiere hardware reubicación dirección, y ha estado presente en los

ejemplos más prácticos de la virtualización parcial.

Ventajas: más fácil de implementar que la virtualización completa. Puede soportar

aplicaciones importantes y máquinas sólidas. Importante para compartir recursos

informáticos entre usuarios.

Desventajas: Falta de compatibilidades con versiones anteriores. Poco portable.


15

- Paravirtualización.

En paravirtualización, la máquina virtual no simula necesariamente de hardware, sino

que ofrece una API especial que sólo puede ser utilizado por la modificación de la

"huésped" OS. Para que esto sea posible, el "invitado" código fuente del sistema

operativo debe estar disponible. Si el código fuente está disponible, es suficiente para

reemplazar las instrucciones sensibles con las llamadas a VMM API "), a continuación,

volver a compilar el OS y el uso de los nuevos binarios.

Ventajas: mayor rendimiento que la virtualización nativa, no se necesita de ua CPU

con soporte para la virtualización.

Desventajas: hay que modificar el SO invitado.

- Virtualización a nivel de sistema operativo.

En la virtualización a nivel de sistema, un servidor físico se virtualiza a nivel del

sistema operativo, lo que permite múltiples servidores virtualizados aislado y seguro

para ejecutar en un único servidor físico. El "invitado" entornos OS comparten el

mismo sistema operativo que el sistema anfitrión (es decir, el mismo núcleo del

sistema operativo se utiliza para implementar los ambientes "invitados"). Las

aplicaciones que se ejecutan en un entorno "guest" dado lo ven como un sistema

autónomo. La aplicación pionera fue jaulas de FreeBSD, otros ejemplos incluyen

Solaris Containers, OpenVZ, Linux-VServer, LXC, AIX particiones de carga de trabajo,

Parallels Virtuozzo Containers y cuentas virtuales Icore.


16

Ventajas: Es muy rápida. La capa de virtualización es muy ligera. El rendimiento muy cercano

al nativo.

Desventajas: Muy difícil de implementar en un aislamiento completo. No se pueden virtualizar

diferentes Sistemas Operativos.

- Virtualización de aplicaciones.

Consiste en ejecutar una aplicación usando los recursos locales en una máquina virtual

apropiada. Estas aplicaciones virtuales se ejecutan en un "pequeño" entorno virtual

que le proporciona todos los componentes necesarios.

El entorno actúa como una capa entre la aplicación y el sistema operativo y elimina los

conflictos entre las aplicaciones y el sistema operativo. Por ejemplo: Java Virtual

Machine de Sun (JVM), Softricity, Thinstall, Altiris, Trigence..


17

- Virtualización asistida por hardware.

En la virtualización asistida por hardware, el hardware proporciona soporte

arquitectónico que facilita construir un monitor de máquina virtual y permite a los

sistemas operativos invitados que se ejecuten de forma aislada. En este tipo de

virtualización se cuenta con ayuda del procesador. Compañías como Intel o AMD

proporcionan dicha ayuda por hardware al software de virtualización. Esto permite a

los hipervisores un rendimiento mayor. Y aunque el procesador incluya la tecnología,

se debe activar en la BIOS.

Ejemplos de plataformas de virtualización adaptadas a dicho hardware incluyen Linux

KVM, VMware Workstation, VMware Fusion, Microsoft Hyper-V, Microsoft Virtual PC,

Xen, Parallels Desktop para Mac, Oracle VM Server para SPARC, VirtualBox y Parallels

Workstation

Ventajas: Mayor rendimiento. Fácil de implementar.

- Otras:

- Virtualización de bibliotecas: Wine (API Win32). Permite la ejecución nativa

de aplicaciones Windows en plataformas de Linux, FreeBSD o Solaris.

- Virtualización de escritorio: Virtual Desktop Infrastructure (VDI) consiste

básicamente en implementar el escritorio como servicio. Permite hospedar un

SO de escritorio dentro de una máquina virtual. Ejemplos: VDI, VMware View,

Citrix, etc.


18

2. ESXi

La definición exacta de ESXi es:

VMware ESXi es una plataforma de virtualización a nivel de centro de datos producido por

VMware, Inc.. Es el componente de su producto VMware Infraestructure que se encuentra al

nivel inferior de la capa de virtualización, el hipervisor, aunque posee herramientas y

servicios de gestión autónomos e independientes.

Está compuesto de un sistema operativo autónomo que proporciona el entorno de gestión,

administración y ejecución al software hipervisor, y los servicios y servidores que permiten la

interacción con el software de gestión y administración y las máquinas virtuales.

Como hemos comentado más arriba, ESX es un hipervisor de tipo Bare Metal. Trabaja en el

mismo núcleo del sistema operativo, así que evita esa carga añadida.

ESX está basado en Linux, en la distribución de Red Hat Enterprise, pero modificado

específicamente para la ejecución del hipervisor y los componentes que virtualiza VMware.

El arranque de la máquina anfitriona se produce a través de la ejecución de un núcleo Linux

el cual proporciona servicios de consola y hardware

En colaboración con el hipervisor funcionando en modo "Supervisor". A partir de la versión

vSphere (versión 4.0), el hipervisor aplica los teoremas de la paravirtualización y sustituye al

núcleo Linux por sus propias interfaces y pasando a ejecutar el entorno operativo como una

máquina virtual.

El vmkernel está programado y configurado siguiendo la arquitectura de microkernel,6 y tiene

las siguientes interfaces con el exterior:

Hardware

Sistema invitado

Consola de servicio (Console OS, ServiceConsole)

Características:

Fiabilidad y seguridad - La arquitectura de ESX en versiones anteriores a vSphere 5.0

se basó en una clase de servicio basados en Linux para el servicio y la integración de

socios basada en agentes. En el nuevo sistema operativo arquitectura ESXi

independiente, la funcionalidad de gestión necesaria ha sido

implementadoadirectamente en el núcleo VMkernel.


19

Optimización - La nueva arquitectura ESXi tiene muchos menos elementos de

configuración, lo que simplifica enormemente el despliegue y la configuración y lo que

es más fácil mantener la coherencia.

Reducir los gastos generales de gestión - El socio modelo de integración basado en la

API de la arquitectura ESXi elimina la necesidad de instalar y administrar agentes de

administración de terceros. Puede automatizar tareas rutinarias mediante el

aprovechamiento de la línea de entornos de scripts de comandos remotos como vCLI o

PowerCLI.

Simplificación de Hypervisor, parches y actualización - Debido a su pequeño tamaño

y los componentes limitados, la arquitectura ESXi requiere muchos menos parches que

las primeras versiones, acortando las ventanas de servicio y la reducción de las

vulnerabilidades de seguridad. Durante su vida útil, la arquitectura ESXi requiere

aproximadamente 10 veces menos parches que el hipervisor ESX.

¿Cómo trabajan ESX & ESXi?

Como hemos comentado, el trabajo de un Hipervisor como este, es la instalación directa en el

servidor de Hardware. Se inserta una capa de virtualización robusta entre el propio hardware

y el sistema operativo ESX/ESXi, particionando un servidor físico en múltiples hosts y

máquinas virutales, que se puedej ejecutar en cualquier situación, en caso de caídas.

Cada máquina virtual representa un sistema completo de procesadores, memoria, creación de

redes, almacenamiento, BIOS, aplicaciones de software, etc.

Las máquinas virtuales están completamente aisladas una de otras por la capa de

virtualización, lo que impide cualquier error o accidente de configuración que pueda afectar

a las demás.

Una de las grandes ventajas es la compartación de recursos de los servidores físicos entre

varias máquinas virtuales, aumenta la utilización del hardware y disminuye los costos en

cuanto a capital se supone.

Contar con una arquitectura Bare-Metal proporciona un control total sobre el servidor, los

recursos asignados a cada máquina virtual y prevé un rendimiento de la máquina casi nativo,

de una clase empresarial y con una escalabilidad importante.

La alta disponibilidad integrada, más la gestión y seguridad de los propio recursos y

características nos ofrece un nivel de servicio y software de aplicaciones al nivel máximo.


20

¿Qué diferencia hay entre ESX y ESXi?

ESX

VMware y agentes de terceros se ejecutan en la clase de servicio.

La mayor funcionalidad de gestión previsto por los agentes que se ejecutan en los CDS.

Los usuarios inician sesión en COS con el fin de ejecutar los comandos para la

configuración y diagnóstico.

El kernel de virtualización (VMKernel) fue aumentado con una partición de gestión conocido

como el sistema operativo de la consola (COS o consola de servicio).

El propósito principal de los COS era proporcionar una interfaz de gestión en el huésped.

Varios agentes de administración de VMware se desplegaron en el COS, junto con otros

agentes de servicios de infraestructura (por ejemplo, servicio de nombres, servicio de tiempo,

registro, etc.) En esta arquitectura, muchos clientes despliegan otros agentes de terceros

para proporcionar una funcionalidad concreta, como el monitoreo de hardware y gestión del

sistema. Por otra parte, los usuarios administradores individuales conectados a la COS para

ejecutar comandos de diagnóstico y scripts de configuración.


21

ESXi

Los agentes de VMware se ejecutan directamente en VMkernel.

Los módulos de terceros autorizados también pueden funcionar en VMkernel. Estos

proporcionan una funcionalidad específica.

o El monitoreo de Hardware.

o Los controladores de hardware.

Componentes de VMware y componentes de terceros actualizan de forma

independiente.

El enfoque de "doble imagen" le permite volver a la imagen anterior si se desea.

No se permite la ejecución de código arbitrario en el sistema.

En la nueva arquitectura de VMware vSphere ESXi, el COS ha eliminado y todos los agentes de

VMware ejecutarse directamente en el VMkernel.


22

Los servicios de infraestructura se proporcionan de forma nativa a través de módulos incluidos

con la VMkernel. Otros módulos de terceros autorizados, tales como controladores de

hardware y componentes de monitoreo de hardware, se pueden ejecutar en VMkernel

también. Sólo los módulos que han sido firmados digitalmente por VMware están permitidos

en el sistema, la creación de una arquitectura fuertemente bloqueada.

A continuación, una tabla que compara las características de la arquitectura ESX o con la de

ESXi.

Función ESX ESXi

Consola de servicio (COS) Sí No

CLI Admin / config COS + vCLI PowerCLI + vCLI

Solución de problemas avanzados COS ESXi Shell

Instalación automática Sí Sí

Arranque desde SAN Sí Sí

SNMP Sí Sí

Active Directory Integrado Integrado

Monitoreo del Hardware Sí Sí

Conectividad Puerto Serial Sí Sí

Jumbo Frames Sí Sí

Auto Deploy No Sí

Creación y gestión de la imagen No Sí

Syslog seguro No Sí

Firewall con interfaz Sí Sí

Como podemos apreciar, ESXi es una versión más básica. Ha sido capaz de reducir su tamaño

(a 150 MB hacia arriba) gracias a que los agentes corren directamente en el VMKernel.

Aun así, ofrece la misma funcionalidad y rendimiento que la versión ESX.


23

El nuevo ESXi (5.5) añade un nuevo paso hacia la seguridad y fiabilidad, ya que su código base

más pequeño representa "una superficie de ataque" más pequeña con menos código y por

ende, más pequeño para parchear y corregir errores.

Sin duda estamos delante de un producto pensado en la simplicidad, con menús y

configuraciones automáticas que hacen que sea una forma muy fácil de trabajar con el tema

de la virtualización.

La mayor diferencia es que ESX depende de un sistema operativo Linux operativo en el propio

sistema, el llamado "Consola de servicio" que realiza gestiones como la ejecución de scripts,

la instalación de otros agentes para el control del hardware, copias de seguridad u otros

sistemas.

La consola se elimina en ESXi, por lo tanto, reduce esta "huella" y completa una tendencia en

cuanto a la funcionalidad de gestión de los comandos y yendo más hacia la administración

mediante una interfaz y una serie de normas.


24

3. vCenter Server

vCenter Server es una plataforma escalable y ampliable para una gestión proactiva de

virtualización, que posibilita la máxima visibilidad de la infraestructura virtual. vCenter

Server permite gestionar de forma centralizada los entornos VMware vSphere y simplifica las

tareas cotidianas mejorando notablemente el control administrativo de entorno.

¿Qué es VMware vCenter Server?

vCenter Server permite unificar la gestión de todos los hosts y máquinas virtuales del centro

de datos en una única consola. De este modo los administradores pueden mejorar el control,

simplificar las tareas cotidianas y el coste de la gestión de entornos.

¿Cómo funciona VMware vCenter Server?

vCenter Server incluye diversos componentes fundamentales que funcionan de manera

conjunta para proporcionar un centro escalable para la gestión de la virtualización. Los

servidores de gestión ofrecen puntos de gestión centrales a los hosts y máquinas virtuales con

información de inventario y rendimiento almacenada en una base de datos.

Para acceder a vCenter Server se puede utilizar vSphere Client en cualquier pc con Windows o

también con vSphere Web Client remotamente desde cualquier explorador web.

Los roles y permisos se replican entre los servidores de gestión, de esta forma se pueden

gestionar varias instancias de vCenter Server desde la misma consola.


25

Ventajas principales

Rápido análisis y solución de problemas con máxima visibilidad de vSphere y de su

infraestructura subyacente.

Mejora de la capacidad de respuesta al gestionar de forma proactiva el entorno de

vSphere con aprovisionamiento rápido, balanceo automatizado de la carga de

máquinas virtuales y ciclos de trabajo de la automatización.

Implementación rápida de vCenter Server y gestión de vSphere mediante un dispositivo

virtual basado en Linux con vCenter Server Appliance.

Escalabilidad a la medida de las necesidades de los entornos empresariales más

exigentes y gestión de hasta 10000 máquinas virtuales.

Características principales

Control centralizado y visibilidad detallada

Acceso remoto desde cualquier ubicación: con vSphere Web Client se pueden

gestionar las funciones de vSphere desde cualquier explorador en cualquier

parte.

Supervisión en tiempo real de elementos virtuales dinámicos: vCenter Server

conoce perfectamente todos los elementos virtuales y los componentes físicos,

incluido el hardware de servidores, almacenamiento compartido y red.

Los activadores de eventos y alarmas facilitan la supervisión del entorno como

el diagnóstico y la solución de los problemas. vCenter Server supervisa el

rendimiento y la disponibilidad de las máquinas virtuales y otros elementos

virtuales, como los pools de recursos con estadísticas y gráficos que se pueden

consultar en tiempo real.

Activadores de alarmas personalizadas: vCenter Server puede generar alertas

y notificaciones automatizadas como desencadenar ciclos de trabajo

automatizados para solucionar y prevenir problemas

Navegación simplificada y búsquedas de inventario: La función de búsqueda

global permite acceder al inventario completo de instancias de vCenter Server

que incluye máquinas virtuales, hosts, datastores y redes.


26

Gestión proactiva de los entornos vSphere

Aprovisionamiento rápido y gestión de parches simplificada: Se pueden crear

máquinas virtuales o hosts en unos minutos mediante asistentes o plantillas con

el fin de minimizar los errores y las interrupciones del servicio.

Asignación dinámica de recursos para garantizar los SLA: vCenter Server

supervisa continuamente la utilización de los pools de recursos con DRS, que

permite migrar de manera inteligente las máquinas virtuales entre hosts sin

paradas y sin comprometer los acuerdos a nivel de servicio (SLA).

Automatización de ciclos de trabajo: vCenter Server incluye VMware vCenter

Orchestrator que es un potente motor de organización que simplifica la

gestión. Se pueden automatizar más de 800 tareas utilizando ciclos de trabajo

predefinidos o bien organizar los ciclos de trabajo mediante una sencilla

interfaz con funciones de arrastrar y colocar.

Disponibilidad de vCenter Server: Una consola de gestión muestra el estado

de los componentes de vCenter permitiendo identificar y corregir rápidamente

los problemas de la infraestructura.

Escalabilidad y capacidad de ampliación

Gestion a gran escala: vCenter Server es una solución de 64 bits que permite

gestionar los entornos más grandes. Una única instancia de vCenter Server

permite gestionar hasta 1000 hosts y 10000 máquinas virtuales.

Arquitectura abierta: Las vCenter API y una extensión .NET permiten la

integración entre vCenter Server y otras herramientas, y admiten los

componentes personalizados para vSphereClient.

Requisitos hardware/software de Vcenter Server 5

Hardware

Procesador 2 CPUs 64bits 2.0GHz Intel o AMD x86

Memoria: 4GB RAM

Disco Duro 4GB

Red: Adaptador Ethernet (1 Gigabyte)


27

Software

Windows XP Profesional 64-bit con SP2 y SP3

Windows Server 2003 64-bit Standard Enterprise y Datacenter con SP1,SP2

Windows Server 2008 64-bit Standard Enterprise y Datacenter con SP2

Windows Server 2008 R2 64-bit

Novedades en la version 5.5

Implementación simplificada. Un modelo de instalación única para los clientes de

todos los tamaños se ofrece ahora.

Mejorada la integración de Microsoft Active Directory. La incorporación de soporte

nativo de Active Directory permite autenticación entre dominios con uno y confianzas

bidireccionales comunes en entornos multidominio.

Arquitectura. Construido desde cero, esta arquitectura elimina el requisito de una

base de datos y ahora ofrece una solución de autenticación de varios maestros con la

replicación y soporte para múltiples arrendatarios incorporado.


28

3.1 VMware vSphere

¿Qué es VMWare vSphere?

Es una plataforma de virtualización que permite construir infraestructuras cloud.

Está diseñada para organizaciones que desean virtualizar por completo sus centros de datos y

proporcionar estas tecnologías como servicios.

vSphere permite transformar los centros de datos en entornos de cloud computing

drásticamente simplificados, capaces de proporcionar una generación de servicios flexibles y

fiables.

Ventajas que aporta este tipo de plataforma:

- Eficiencia. Gracias a su utilización y automatización, capaz de conseguir que la

utilización del hardware mejore del 5 al 15% hasta un 80% sin sacrificar el

rendimiento.

- Reducción de costes. Disminuye los gastos de propiedad hasta un 80% y los costes

operativos en un 30%.

- Agilidad. Una infraestructura que proporciona disponibilidad, escalabilidad y

rendimientos integrados y garantizados en las aplicaciones que ejecuta vSphere.


29

Características:

A continuación se mostrará algunas de las funciones que utiliza VMware vSphere de una manera

resumida. En páginas posteriores se ha investigado con más detalle y de forma específica de

algunas funciones que ofrece vSphere.


30

vSphere ESXi Capa de virtualización sólida y de alto rendimiento que abstrae los recursos de hardware de

los servidores y permite que se puedan compartir entre varias máquinas virtuales.

DRS

Coordina los recursos informáticos con las prioridades de la empresa equilibrando

automáticamente la carga entre los hosts. Optimiza el consumo de energía apagando los hosts

durante los períodos de menos carga.

vMotion

Elimina el tiempo de inactividad de las aplicaciones derivado del mantenimiento planificado

de servidores, migrando en caliente las máquinas virtuales de un host a otro.

Big Data Extensions

Ejecuta cargas de trabajo para lograr una mayor utilización, fiabilidad y agilidad de los

sistemas.Gracias a vSphere Web Client, las empresas pueden asignar recursos de manera

flexible para responder a las necesidades cambiantes de la empresa con solo hacer clic en un

botón.

DPM

vSphere Distributed Power Management (DPM) nace en vSphere 4 con el objetivo de ahorrar

energía. DPM es estratégico en un Datacenter grande, pensar que en estas instalaciones la

energía es el coste operativo más importante en el total.

En vSphere 5.5 aparece Host Power Management (HPM), una función complementaria a DPM

cuya misión es, también, el ahorro de energía, motivo por el cual puede generar confusiones.

DPM funciona dentro de un cluster DRS, cuando DPM está activado, al disminuir la carga de

computación sobran hosts para atender a las VMs, DPM se encarga de vaciar los sistemas con

vMotion y “apagar” estos hosts, al aumentar la carga de computación en el cluster se

“arrancan” los hosts necesarios para atender las VMs y el cluster DRS “reparte” la carga entre

los hosts.

HPM funciona en cada host de forma independiente, si se habilita en la BIOS del host, el

hipervisor, a través del ACPI, es capaz de manejar los C-states de la CPU. Los estados C del

procesador son estados intermedios de ahorro energético, la granularidad de estos estados se

llaman deep C-states que permiten dormir o parar un procesador cuando no se utiliza,

disminuyendo el consumo energético.


31

¿Cómo se configura HPM?

En la configuración de host de vSphere 5.5, en la opción de Power Management, la política

por defecto es Balanced, las políticas existentes son :

High Performance: Máximo rendimiento, no se utilizan HPM ni los deep C-states de la CPU.

Balanced: Solo se utilizan los deep C-states si no afectan al rendimiento del procesador.

LowPower: Utiliza los deep C-states de la CPU pudiendo disminuir el rendimiento del host.

Cuando las estrategias de eficiencia energética y el Green IT dominan el escenario.

Custom: Es la política Balanced pero con capacidad de modificar las métricas de la política.

Network I/O Control Se utiliza para configurar reglas y políticas en el nivel de máquina virtual, así como para

asegurarse de que siempre haya recursos disponibles para sus aplicaciones esenciales para el

negocio. Network I/O Control supervisa la red. Cada vez que detecta congestión,

automáticamente reasigna los recursos a las aplicaciones de máxima prioridad conforme a lo

definido en las reglas empresariales.

De este modo, Network I/O Control permite mejorar la productividad de los administradores,

ampliar la virtualización a mayor número de cargas de trabajo y aumentar la versatilidad de

la infraestructura.

Las ventajas que aporta son:

Aislamiento: garantiza el aislamiento del tráfico, para que un flujo determinado nunca

domine por encima de los demás, lo que evita las pérdidas de paquetes.

Cuotas: permiten un particionamiento flexible de la capacidad de red, para ayudar a los

usuarios a gestionar la situación cuando los flujos compiten por los mismos recursos.

Límites: aplicar límites de ancho de banda del tráfico de red.

Etiquetado IEEE 802.1p: etiqueta los paquetes que salen del host de vSphere para que los

recursos de red físicos los gestionen correctamente.


32

Network I/O Control clasifica el tráfico en varios pools de recursos predefinidos:

- VMware vSphere vMotion

- iSCSI

- Registro de tolerancia a fallos

- Gestión

- Sistemas de archivos de red (NFS)

- Tráfico de máquinas virtuales

- Tráfico de vSphere Replication

- Definido por el usuario

Distributed Switch

Centraliza el aprovisionamiento, la administración y la supervisión de la red mediante la

agregación de redes en todo el centro de datos.

Características:

- Simplificación de la configuración de red de las máquinas virtuales.

- Prestaciones mejoradas de supervisión y solución de problemas de la red.

- Compatibilidad con las funciones de red avanzadas de VMware vSphere.


33

vSphere Distributed Switch amplía las funciones y prestaciones de las redes virtuales a la vez

que simplifica el aprovisionamiento y el proceso continuo de configuración, supervisión y

gestión.

Los conmutadores de red de vSphere se pueden desglosar en dos secciones lógicas: plano de

datos y plano de gestión.

El plano de gestión implementa la conmutación, el filtrado, etiquetado, etc. de paquetes

propiamente dichos y es la estructura de control que se emplea para que el operador pueda

configurar la funcionalidad del plano de datos. Cada vSphere Standard Switch (VSS) contiene

los dos planos, de datos y de gestión. El administrador configura y mantiene cada conmutador

individualmente.

DistributedSwitch alivia esta carga de gestión, pues trata la red como un recurso agregado.

Los conmutadores virtuales del nivel de host individual se abstraen en un único

DistributedSwitch de gran tamaño que abarca varios hosts en el nivel del centro de datos. En

este diseño, el plano de datos sigue siendo local para cada vSphereDistributedSwitch, pero el

de gestión se centraliza.


34

High Availability

Proporciona alta disponibilidad en todo el entorno de virtualizado sin el coste ni la

complejidad de las soluciones en clúster tradicionales.

App HA

Detecta los fallos de las aplicaciones o sistemas operativos y efectúa su recuperación.

Complementa la funcionalidad de High Availability con supervisión y reparación automatizada

en el nivel de aplicaciones. App HA aumenta el tiempo de actividad de las aplicaciones

mediante:

- Supervisión y reparación basadas en políticas.

- Integración con vSphere HA para proporcionar numerosas opciones de recuperación,

por ejemplo: reiniciar el servicio de las aplicaciones o la máquina virtual

Además, reduce el coste y la complejidad, aportando:

- Protección y soporte uniformes para muchas aplicaciones comerciales de uso común.

- Gestión sencilla y centralizada con visibilidad del estado de las aplicaciones desde

VMware vCenter Server.


35

Fault Tolerance

Proporciona disponibilidad continua para aplicaciones sin pérdida alguna de datos en caso de

fallo de algún servidor.

Protección de datos

Protege sus datos mediante copias de seguridad en disco rápidas y sin agentes, con

eliminación de duplicados para minimizar el espacio en el disco de copia de seguridad.

Data Protection (VDP) proporciona una copia de seguridad rápida a disco y una recuperación

más fiable.

Divide los archivos en subsegmentos de longitud variable con objeto de determinar cuáles son

únicos y minimizar los requisitos de almacenamiento para la copia de seguridad.

Replicación

Permite la sincronización entre una máquina/s virtual local y una remota, lo cual es una

excelente forma de realizar copias de seguridad y disponer de tolerancia a fallos en nuestro

datacenter, ya que, ante una avería en nuestros servidores centrales, en muy poco tiempo

podríamos tener en funcionamiento las máquinas virtuales de respaldo.

vSphere Replication es un producto que destaca por su sencillez el cual funciona

perfectamente y cumple su cometido al 100%. Precisamente esta sencillez de puesta en

marcha y configuración se puede convertir a la vez en su gran desventaja a la hora de

decantarnos por este producto como solución de réplica. Hay una serie de limitaciones o

carencias de configuración que podemos encontrarnos y que debemos de saber a la hora de

elegir o no vSphere Replication:


36

- Protege máquinas virtuales de manera individualizadas.

- Requisitos mínimos: SRM 5.0, ESXi 5.0, Virtual center Server 5.0 (No vcenter appliance),

Hardware virtual 7.

- No dispone de una gestión de uso de ancho de banda.

- No permite realizar tareas programadas de replicación. Solamente los tiempos de RPO

siendo el de 15 minutos el más agresivo.

- Solo permite un único punto de recuperación.

- No replica máquinas virtuales apagadas.

- No replica snapshots de las máquinas virtuales origen.

- Discos RDM no están soportados.

- Únicamente permite funcionar con un Virtual center. No soporta virtual center hearthbeat.

- Solo funciona a través del virtual center. Necesitamos el Virtual center para realizar

cualquier tarea ya sea de configuración o recuperación.


37

Auto Deploy

Facilita y agiliza la implementación de servidores y aprovisionamiento de hosts de vSphere

aprovechando las prestaciones de arranque a través de la red de los servidores x86 junto con

la reducida presencia del hipervisor VMware ESXi.

Con Auto Deploy, los hosts de vSphere se arrancan a través de la red desde un servidor de

Auto Deploy central en cuya memoria está instalado directamente el software de ESXi.Una

vez instalado, el host se configura por medio de un perfil de host de VMware vCenter. El host

ya configurado se conecta a vCenter, donde está disponible para las máquinas virtuales del

host. Todo el proceso está automatizado por completo, de forma que se pueden aprovisionar

nuevos hosts sin intervención manual.

Update Manager

Reduce el tiempo dedicado a las correcciones rutinarias automatizando el seguimiento, la

aplicación de parches y la actualización de los hosts de vSphere.

Host Profiles

Permite crear un perfil una vez y utilizarlo para configurar numerosos hosts de vSphere.


38

vShield Endpoint

Elimina la presencia de los antivirus en las máquinas virtuales y mejora el rendimiento de los

análisis antivirus descargando sus funciones en un dispositivo virtual de seguridad.

Permite gestionar las políticas antivirus y antimalware para entornos virtualizados con las

mismas interfaces de gestión que se utilizan para proteger la infraestructura física. vShield

Endpoint refuerza la seguridad de la virtualización con protección reforzada de los puntos de

acceso.


39

Storage DRS

Proporciona distribución de máquinas virtuales y mecanismos de equilibrio de carga basados

en la latencia de E/S y la capacidad de almacenamiento.

Storage vMotion

Lleva a cabo migraciones sin interrupciones del almacenamiento, elimina los cuellos de

botella de E/S del almacenamiento en las máquinas virtuales y libera la valiosa capacidad de

almacenamiento.

Profile-Driven Storage

Proporciona visibilidad del pool de almacenamiento, para que pueda automatizar y optimizar

el aprovisionamiento del almacenamiento.

Mediante la configuración de una serie de perfíles y etiquetas podremos definir las

características de nuestros datastores. Podremos definir nuestros almacenes en función de su

rendimiento, disponibilidad, valor, etc. para posteriormente almacenar las máquinas virtuales

en ellos en función de la calidad de servicio que queremos/debemos ofrecer. A la hora de

crear una máquina virutal, migrarla de datastore o clonarla, vCenter nos mostrará los

datastores compatibles donde almacenaremos dicha máquina evitando por tanto cualquier

error humano.


40

Storage I/O Control Prioriza el acceso al almacenamiento supervisando continuamente las cargas de E/S de un volumen

de almacenamiento y asignando dinámicamente los recursos de E/S disponibles a las máquinas

virtuales según las necesidades empresariales.

Storage I/O Control permite activar la supervisión de la latencia de dispositivos que los hosts

experimentan al comunicarse con el almacén de datos. Cuando la latencia supera un umbral

establecido, la función se activa automáticamente, para aliviar la congestión. A cada máquina

virtual que accede a ese almacén de datos se le asignan recursos de E/S de forma

proporcional a su cuota.

Nos permite mejorar el rendimiento de disco a la hora de usar asignaciones de recursos en las

máquinas virtuales. En vSphere podemos asignar diferentes prioridades a una máquina virtual

a nivel de CPU, RAM y disco, así como la CPU y la RAM las prioriza únicamente el host que las

ejecuta, en el acceso a disco (compartido) lo priorizará de forma proporcional entre el resto

de los hosts. Requisitos: vSphere 4.1 Enterprise Plus, un sólo vCenter gestionará los

almacenes, soportado para FC e iSCSI (no NFS o RDM/RAW), multiplesextends no soportados.


41

VMFS

Es un sistema de archivos en clúster de alto rendimiento optimizado para máquinas virtuales. Si bien

los sistemas de archivos convencionales solamente permiten que un servidor tenga acceso de lectura

y escritura al mismo sistema de archivos en un momento dado, VMFS aprovecha el almacenamiento

compartido para permitir que varios hosts de VMwarevSphere lean y escriban en el mismo

almacenamiento de forma simultánea.

- Simplifica el aprovisionamiento y la administración de máquinas virtuales almacenando el estado

de toda la máquina virtual en una ubicación centralizada.

- Crea una copia puntual de datos de una máquina virtual que pueda utilizarse para operaciones de

prueba, copia de seguridad y recuperación.

- Admite capacidades únicas basadas en la virtualización, como la migración en caliente de

máquinas virtuales en funcionamiento entre servidores, el reinicio automático de una máquina

virtual con fallos en otro servidor y el clústering de máquinas virtuales en servidores diferentes.

- Añade el espacio de discos virtuales a máquinas virtuales en funcionamiento para aumentar los

recursos disponibles o con fines de copia de seguridad.

- Utiliza el registro distribuido para recuperar máquinas virtuales con más rapidez y fiabilidad si se

producen errores en el servidor.


42

Flash Read Cache

Virtualiza la memoria flash del servidor mediante una capa de caché de lectura de alto rendimiento

que reduce drásticamente la latencia de las aplicaciones. El almacenamiento en caché es totalmente

transparente para la máquina virtual sin necesidad de agentes guest. Flash Read Cache permite

asignar recursos de memoria flash a nivel de disco de máquina virtual.

La memoria flash de servidor, en forma de tarjetas PCIe o de unidades de estado sólido, es una

forma almacenamiento fiable y asequible para el entorno de vSphere. La memoria flash de servidor

proporciona un nuevo nivel de almacenamiento de baja latencia que se puede aprovechar para que

los datos estén más cerca de las máquinas virtuales, con una relación calidad-precio cada vez mejor.


43

3.2 vSphere Client Web

vSphere Web Client tiene la misma utilidad que vSphere Client. La gran diferencia es que

como indica su nombre "Web". Nos permite realizar las tareas administrativas desde un

navegador.

Para ello debes descargarte en la página oficial de VMware el plugin/extensión que te

permite navegar vía web. Hay que tener en cuenta que vCenter tiene que estar habilitado e

iniciado en todo momento para poder realizar todas estas funciones.

La versión web no fue muy utilizada en 5.0, pero a partir de 5.1 VMware realizó una

estrategia en la que solo algunos complementos podían ser utilizados desde el navegador y no

desde el programa habitual. Por ejemplo vSphere Replication, la gestión de vSphere SSO o la

integración con vCenter Orchestrator.

La forma de acceder es con la dirección: https://nombre:9443/vsphere-client.

Destacar que el puerto 9443 utiliza el protocolo TCP/IP, garantiza la entrega de paquetes de

datos en la misma orden, en que fueron mandados.

Además, de la inclusión de HTTPs para navegar de forma segura y poder administrar tu

servidor sin ningún tipo de problema de seguridad.

Otra de las características de este cliente web es su velocidad y fiabilidad.

Es bastante cómodo trabajar con él y se pueden crear filtos de manera muy rápida, haciendo

así una búsqueda más rápida y fiable.

Se agrega soporte para drag & drop de objetos a nivel del inventario, permitiéndonos así

tener una navegación y uso del cliente mucho mas amigable de lo que se tenia en versiones

anteriores.

También se ha incluido soporte para Mac OS y una consola de HTML para visualizar e

interactuar con las máquinas virtuales.

https://nombre:9443/vsphere-client


44

Diferencias entre vSphere Client y vSphere Web Client

Funcionalidades vSphere Client vSphere Web Client

Windows Requerido No requerido

Java y Flash No requerido Requerido

Navegadores Soportados - Firefox, IE, Chrome

Puerto de acceso 443 443/9443

Crear VMs en v9 de hardware No Si

Control directo de host Si A través de vCenter

Update Manager Plugin Si No

Single Sign On Soportado Soportado

Motor de búsqueda Simple Mejorado

Soporte SRM 5.1 No soportado Soportado

vMotion mejorado No soportado Soportado

Instancias del vCenter Una Múltiples

Gestión de LOGs Simple Mejorada

vSphere Replication No soportado Soportado

vSphere Data Protection No soportado Soportado

Transferencia de ficheros en

Datasotore

Soportado Soportado

Acceso a consola VM Soportado Soportado


45

En vSphere Client no es posible crear máquinas virtuales de versión 9 y 10, pero si es posible

administrarla. Gracias a vSphere Client Web, podemos empezar a crear dichas máquinas con

el tutorial o guía correspondiente, además de luego poder editar las opciones.

Hay que tener cuidado con esto, porque si utilizas una máquina de versiones 9 o 10, con

vSphere Client no podrás editar sus opciones.

Hay otros ejemplos como para utilizar Single Sign On en el cliente web se necesita instalar

vSphere Data Integration.

O la posibilidad de transferir archivos a un Datastore pero requiere client integration

En el cliente Web para gestionar la consola de las máquinas virtuales se necesita instalar

vSphere Client Integration.

Nuevas características de vSphere Web Client

Work In Progress: Esta nueva característica permite iniciar una nueva tarea, como por

ejemplo instalar una nueva máquina virtual y después poner la tarea en pausa para

trabajar en otras cosas en cambio en las versiones anteriores si iniciabas una tarea

nueva hasta que no acabara no podías realizar otra tarea, con esta función las tareas

seguirán su proceso incluso si se cierra el navegador y se vuelve a abrir.

Single Sign On: Esta función permite al administrador iniciar sesión en una vez y luego

se autenticará en otras funciones instaladas de forma automática. Esta característica

puede utilizar contraseñas de active directory pero no se podrá trabajar con

componentes de versiones anteriores. Esta nueva característica también permite

administrar varios vCenters sin tener que usar el modo vinculado.

vSphere Replicación: Permite replicar las máquinas virtuales a través de internet o un

enlace WAN a otro sitio diferente. Este proceso copia únicamente los bloques

cambiados en el sitio de recuperación por lo tanto reduce el ancho de banda y hace

posible objetivos de punto de recuperación más agresivos.

Tagging Inventario: Permite asignarle un nombre, una descripción y una categoría a

un objeto de vSphere, esto es útil para hacer anotaciones sobre los objetos que

deseemos y realizar la búsqueda utilizando esas notas

vSphere Data Protection: Esta característica solo disponible en el cliente web

permite realizar copias de seguridad rápidas a los discos con una recuperación fiable,

además amplia las prestaciones de copias de seguridad con mayor escalabilidad e

integración a nivel de aplicaciones esenciales.


46

4. Arquitectura del proyecto

Para realizar nuestro proyecto deberemos montar la siguiente Arquitectura de Red.

Esta arquitectura está compuesta por dos equipos ESXI que harán la función de hipervisores,

dos sistemas FreeNAS los cuales realizarán la compartición de discos ISCSI hacia los ESXI para

poder guardar las máquinas virtuales que se instalen en estos y así no ocupar capacidad en los

Datastores propios de estos ESXI y finalmente tendremos un Windows Server 2008 R2 en el

cual instalaremos el Vcenter Server y el cliente VSphere para poder administrar los sistemas

ESXI.

En esta arquitectura crearemos 4 redes diferentes una que será la red de administración

(Management Network), la red ISCSI por la cual se compartirán los discos, la red VMOTION

para poder realizar esta función y finalmente la red FT (Fault Tolerance).


47

Red de Administración

Esta es la red principal de la arquitectura y está formada por los dos sistemas ESXI y un

sistema Windows Server 2008 R2 en el cual instalaremos el Vcenter Server y el programa

Vsphere el cual sirve para poder administrar los dos sistemas ESXI.

Los equipos de esta red tendrán direcciones ip a partir de la 192.168.1.0

Red ISCSI

En esta red tendremos dos sistemas FreeNAS que se encargarán de compartir discos ISCSI a los

dos sistemas ESXI para que estos puedan guardar las máquinas virtuales que se instalen en

estos discos externos y así no se ocupará

espacio en los datastores propios del ESXI.

Esto también nos servirá para que en caso de

que un sistema ESXI se estropeara las

máquinas virtuales no las perderíamos ya que

están almacenadas en discos externos.

Los equipos de esta red tendrán direcciones IP

a partir de la 192.168.2.0


48

Red VMOTION

Esta red está compuesta de solo los dos sistemas ESXI y servirá para poder realizar el servicio

de VMOTION el cual consiste en poder migrar las máquinas de un host a otro.

Hemos de crear una red nueva para este servicio para no saturar las otras redes mientras se

realiza la migración de la máquina virtual.


Red Fault Tolerance

Esta red está compuesta de los dos sistemas ESXI instalados y servirá para poder realizar el

servicio Fault Tolerance el cual consiste en que las máquinas virtuales estén activas en los dos

hosts (uno en modo activo y otro en modo pasivo) y cuando el host primario se caiga se pueda

seguir trabajando con la misma máquina desde el host secundario.

Hemos de crear una nueva red para poder realizar este servicio para que el cambio de host se

haga rápido para que el usuario no pueda notar este cambio de host en la máquina virtual.



49

5. Almacenamiento compartido

Para realizar un buen sistema de almacenamiento compartido deberemos montar una red SAN

(Storage área network).

¿Qué es una SAN?

Una SAN es una red de almacenamiento integral. Esta arquitectura agrupa los siguientes

elementos:

Una red de alta velocidad de canal de fibra o ISCSI

Un equipo de interconexión dedicado

Elementos de almacenamiento de red

Esta red se distingue de los otros modos de almacenamiento por el modo de acceso a bajo

nivel, el tipo de tráfico de esta red es similar al de los discos duros.

Una red SAN proporciona acceso a nivel de bloque a LUNs. Un LUN (número de unidad lógica),

es un disco virtual proporcionado por la SAN. El Administrador del sistema tiene el mismo

acceso a la LUN como si fuera un disco directamente conectado a la red.

Los dos principales protocolos utilizados en una red SAN son FibreChannel e ISCSI. Una red

FibreChannel es muy rápida y no está saturada por el tráfico de la red LAN.

Estructura básica de una red SAN

Las redes SAN se componen de tres capas:

Capa de Host: Consiste principalmente en Servidores, dispositivos o componentes y

software.

Capa de Fibra: Esta capa la conforman los cables así como los SAN Hubs y los SAN

Switches como punto central de conexión para la SAN.

Capa de Almacenamiento: La componen las formaciones de discos y cintas empleados

para almacenar los datos

La red de almacenamiento puede ser de dos tipos:

FibreChannel: Es una red física de dispositivos FibreChannel que emplea

FibreChannelswitches y directores y el protocolo FCP (FibreChannelProtocol) para

transporte.

Red IP: Emplea la infraestructura estándar de la LAN con hubs y switches Ethernet

interconectados. Una red SAN IP emplea ISCSI para el trasporte


50

Características de una red SAN

Latencia: Una de las principales características de las redes SAN es que son construidas

para minimizar el tiempo de respuesta del medio de transmisión

Conectividad: Permite que múltiples servidores estén conectados al mismo grupo de

discos permitiendo que los sistemas de almacenamiento sean óptimos.

Distancia: Estas redes al ser construidas con fibra óptica heredan sus beneficios por lo

tanto pueden tener dispositivos separados por mucha distancia sin repetidores.

Velocidad: Las redes SAN actualmente tienen una velocidad de transferencia de la

información entre 4 y 8 Gigabits por segundo.

Disponibilidad: Al tener mayor conectividad permiten que los servidores y dispositivos

de almacenamiento se conecten más de una vez a la SAN, de esta forma se pueden

tener rutas redundantes que incrementarán la tolerancia a fallos.

Seguridad: Las redes SAN tienen una tecnología de zonificación que consiste en que un

grupo de elementos se aíslen del resto para evitar problemas.

Componentes: Los principales componentes de una red SAN son switches, HBAs,

Servidores y librerías de cintas.

Topología: Las redes SAN tienen las siguientes topologías:

Cascada

Anillo

Malla

Núcleo

ISL (Inter switch link): Las conexiones entre los switches de la SAN se hacen mediante

puertos tipo “E” y pueden agruparse para formar una troncal que permita un mayor

flujo de la información y tolerancia a fallos.

Ventajas y desventajas

El rendimiento de la red SAN está directamente relacionado con el tipo de red que se

utiliza.

La capacidad de una red SAN se puede extender de manera casi ilimitada.

Permite compartir datos entre varios equipos de la red sin afectar el rendimiento

porque el tráfico de SAN está totalmente separado del tráfico de usuario.


51

Una red SAN es mucho más costosa que una NAS ya que es una arquitectura completa

que utiliza una tecnología cara.

Configuraciones

Primero en la máquina virtual FreeNAS añadiremos los discos para poder crear los RAIDS que

deseemos, en nuestro caso tendremos 4 RAIDS.

Una vez tengamos los discos añadidos accederemos al FreeNAS mediante web poniendo su ip

en el explotador e iremos al apartado Storage y seleccionaremos la opción UFS volume

Manager.

Se nos abrirá la siguiente ventana en la que deberemos asignar un nombre al nuevo RAID,

seleccionar los discos que lo compondrán e indicar que será de tipo Mirror.


52

Una vez hayamos creado el RAID iremos al apartado ISCSI ubicado dentro de Services en el

menú de la izquierda y empezaremos a configurar diferentes cosas para poder compartir este

RAID creado.

Primero añadiremos un nuevo Extent en el que indicaremos el nombre que tendrá, que será

de tipo File, también indicaremos el Path donde estará ubicado este extent creado y

finalmente indicaremos el espacio que tendrá en nuestro caso 60GB ya que el RAID lo forman

dos discos de 30GB cada uno.

Ahora crearemos el Iniciador en el cual indicaremos que tendrá como destino todos los

equipos ya que en el caso del sistema ESXI no hay manera de saber su iniciador.


53

Seguidamente crearemos un nuevo Portal, aquí debemos dejar las opciones que salen por

defecto y no configurar nada.

Ahora crearemos un nuevo Target, esto lo que hace es relacionar el Portal creado

anteriormente con el Iniciador también creado antes, deberemos indicar el nombre que

tendrá este nuevo target e indicaremos el número de Portal y de iniciador que se

relacionarán.


54

Finalmente para acabar con las configuraciones del FreeNAS crearemos un Target/Extent para

relacionar el Target creado anteriormente con el Extent también creado anteriormente.

Una vez realizadas todas estas configuraciones en el sistema FreeNAS ya tendremos creada

nuestra compartición de discos.

Ahora añadiremos estos discos compartidos en los hosts ESXI, esto se deberá hacer desde el

programa Vsphere. Una vez estemos en el Vsphere iremos a la configuración del host en el

que deseamos poner el disco compartido, iremos al apartado Storage Adapters y entraremos

en las propiedades del adaptador ISCSI.

Dentro de estas propiedades deberemos habilitar el adaptador chequeando la casilla

“Enabled”.


55

Seguidamente en la pestaña DynamicDiscovery indicaremos la ip del FreeNAS que sirve el

disco compartido.

Una vez realizadas estas dos configuraciones ya podremos ver los discos compartidos desde el

FreeNAS en el Vsphere.


56

Ahora iremos al apartado Storage y añadiremos un nuevo disco seleccionando la opción “Add

Storage”.

Se nos abrirá una nueva ventana, primero nos preguntará que tipo de almacenamiento

queremos crear, seleccionaremos la primera opción Disk/LUN.

Seleccionamos el disco que hemos compartido antes desde el FreeNAS.


57

Ahora seleccionaremos la Versión de archivo de sistema que tendrá este nuevo disco,

seleccionamos la versión 5 ya que es la más nueva.

Seguidamente deberemos indicar el nombre que tendrá este nuevo disco creado dentro del

ESXI, en nuestro caso se llamará Disco4 ya que tenemos otros tres ya creados anteriormente.


58

En esta nueva ventana indicaremos la capacidad que tendrá este nuevo disco creado, se

pueden seleccionar dos opciones la primera que nos pondrá el máximo espacio disponible que

tiene el disco compartido y la segunda en la que podremos indicar el espacio exacto que

deseamos que tenga el nuevo disco, en nuestro caso seleccionaremos la primera opción.

Para finalizar el proceso de crear un nuevo disco en el ESXI nos saldrá un breve resumen con

todas las configuraciones que hemos indicado.


59

6. vMotion

El servicio VMotion permite trasladar máquinas virtuales instaladas en el sistema ESX y que

están en funcionamiento de un servidor ESX a otro sin tiempo de inactividad. La máquina

virtual retiene su indentidad y conexiones de red. La memoria activa y el estado de ejecución

preciso de la máquina virtual se transfieren a través de una red de alta velocidad, esto

permite que la máquina virtual pase de ejecutarse en el host de origen a ejecutarse en el

host de destino.

El estado de ejecución consta de tres componentes principales:

Estado de dispositivos virtuales.

Conexiones de dispositivos de red e ISCSI.

Memoria física de la máquina virtual.

Estado de dispositivos virtuales

Incluyendo el estado de la CPU, red, adaptadores de disco y más cosas vSphere puede

serializar el estado de los dispositivos virtuales que generalmente tienen un tamaño menor a

8MB.

Conexiones de dispositivos de red e ISCSI

La arquitectura de red virtual de VSphere centrada en los vSwitch y en las vNIC permite que

sea más fácil preservar las conexiones de red existentes, incluso después de que una máquina

virtual sea migrada a otro host. Como cada vNIC tiene su propia MAC que es independiente de


60

la MAC de las NIC físicas al mover una máquina virtual de un host a otro la conexión de red

seguirá activa. Una vez que la migración se completa correctamente el host de destino envía

un paquete RARP al switch físico para asegurar que actualice sus tablas con el nuevo puerto

de switch utilizado por la máquina virtual migrada.

El uso de almacenamiento compartido como SAN o NAS hará que sea muy fácil transferir el

estado de los discos.

Memoria física de la máquina virtual

Este es el componente de mayor tamaño que necesita ser transferido durante el proceso de

VMotion.

Para permitir que la máquina virtual siga ejecutándose durante la transferencia de la

memoria y que el proceso sea totalmente transparente para el usuario, el proceso se deberá

llevar a cabo en tres fases:

Fase 1: Seguimiento de la máquina virtual

En esta etapa se realiza un seguimiento de las páginas de memoria de la máquina virtual para

poder registrar cualquier modificación en la máquina virtual durante la migración. Este

seguimiento puede causar una bajada del rendimiento de la máquina virtual.

Fase 2: Pre-copia

Como la máquina virtual continua en ejecución y modificando el estado de la memoria en el

host de origen durante el proceso de VMotion, el contenido de la memoria de la máquina

virtual es copiado desde el host de origen al host de destino en un proceso iterativo.

Con la primera iteración se copia todo el contenido de la memoria y en las siguientes

iteraciones se copian solo las páginas que fueron modificadas durante este periodo.

Fase 3: Swtichover

Esta es la fase final de todo el proceso de VMotion, la máquina es pausada momentáneamente

en el host de origen, para poder copiar los últimos cambios en la memoria al host de destino y

que finalmente la máquina virtual retome sus operaciones en el host de destino.

Mejoras de vMotion en Vsphere5

Uso de múltiples NICs para vMotion

Vsphere 5 permite utilizar multiples adaptadores de red para vMotion lo cual permite reducir

mucho el tiempo de migración de las máquinas virtuales.

Con esta mejora el VMkernel balanceará de forma transparente el tráfico de vMotion entre

todas las vmknics configuradas para este servicio. Aunque solo haya una única operación de


61

vMotion en curso, el VMkernel utilizará todos los adaptadores de red disponibles para

distribuir el tráfico de vMotion.

Stun During Page Send (SDPS)

La nueva versión de Vsphere incluye nuevas mejores para asegurar que vMotion no fallará

debido a problemas en la copia de memoria. Como se ha comentado anteriormente el proceso

de transferencia de la memoria durante una operación de vMotion incluye un proceso

iterativo. En la mayoría de casos una iteración debe tomar menos tiempo que la anterior, no

obstante hay casos en que la máquina virtual modifica la memoria más rápido de lo que

puede ser transferida y esto daba como resultado una operación fallida de vMotion en

versiones anteriores.

Para poner solución a estos problemas en la nueva versión de Vsphere se reduce la velocidad

de la máquina y así se asegura que la tasa de modificación de la memoria sea menor que la

tasa de transferencia.

Otras mejoras

Mejoras para minimizar el impacto de la tarea de seguimiento de los cambios en la memoria

Mejoras para reducir el tiempo necesario para que la máquina virtual retome su nivel normal

de performance después de una operación de vMotion

Optimizaciones que permiten que vMotion sature de forma selectiva un ancho de banda de

10GBE durante la migración con vMotion.


62

7. Storage vMotion

Storage vMotion permite migrar en caliente los archivos de disco de las máquinas virtuales en

las matrices de almacenamiento y entre ellas , sin provocar una interrupción del servicio. La

migración de archivos de disco de las máquinas virtuales sin ninguna interrupción a distintos

tipos de almacenamiento permite gestionar de una forma más rentable esos discos como

parte de una estrategia de almacenamiento distribuida en diferentes niveles.

Principales funciones de Storage vMotion:

Realizar migraciones de almacenamiento sin ningún tiempo de inactividad y con una

integridad absoluta de las transacciones.

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

del sistema operativo que tengan instalado y del hardware de servidor donde se

ejecuten.

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

sistema de almacenamiento que sea compatible con vSphere (Fibre Channel, iSCSI,

FCoE o NFS).

Optimización dinámica del rendimiento del almacenamiento

Storage vMotion optimiza el rendimiento del almacenamiento ya que mover los archivos de

disco, sin ninguna interrupción, de las máquinas virtuales a LUN alternativos los cuales están

mejor diseñados para proporcionar el rendimiento necesario.


63

Esta optimización permite:

Gestionar los problemas de rendimiento del almacenamiento sin programar ningún

tiempo de inactividad. Solucionar los cuellos de botella del almacenamiento antes de que se conviertan en

problemas graves.

Gestión eficaz de la capacidad del almacenamiento

Storage vMotion permite recuperar la capacidad de almacenamiento no utilizada y asignarla a

otras máquinas virtuales. Storage vMotion también permite utilizar el almacenamiento con

eficacia para evitar futuros problemas de rendimiento. Para ello, permite mover las máquinas

virtuales, sin interrupciones, a otra unidad de almacenamiento con más capacidad a medida

que los archivos de disco de esas máquinas se acercan a los límites de tamaño de la unidad de

almacenamiento total.

Novedades

A partir de la versión 5.0 de vSphere Storage vMotion utiliza un nuevo método,

conocido como “modo de mirroring”. En un plano superior, el modo de mirroring

utiliza una copia de los datos datos anteriores del datastore de origen al de destino,

con los bloques modificados en el datastore de origen reflejados en el de destino.

En esta nueva versión se pueden realizar hasta cuatro copias de disco simultáneas por

cada operación que se realice de Storage vMotion mientras que en las versiones

anteriores, vSphere copiaba en serie los discos pertenecientes a una máquina virtual.

En la siguiente imagen podemos ver la comparación del proceso en las versiones

anteriores de vSphere con la versión 5.1


64

Versiones anteriores de vSphere. A partir de la versión 5.1 de vSphere

Beneficios de Storage vMotion

Mover el disco de una máquina virtual desde una cabina de almacenamiento antigua a

otra más nueva, esto permite reconfigurar o mantener un entorno de almacenamiento

sin la necesidad de parar las máquinas virtuales.

Balancear manualmente los discos de las máquinas virtuales a diferentes DataStores

para mejorar el rendimiento.

Retirar cabinas de almacenamiento físico sin la necesidad de parar las máquinas

virtuales.

Migrar los discos de las máquinas virtuales de un DataStore de Fibre Channel a otro

DataStore iSCSI, NAS o disco local.

Actualización del software de VMware sin la necesidad de parar las máquinas virtuales.

Como realizar Storage vMotion

Primer ponemos en marcha un ping que comunique la máquina del vSphre con la máquina

virtual, esto nos servirá para comprobar que la máquina virtual no se para durante el proceso

de Storage vMotion.

Seguidamente hacemos clic derecho sobre la máquina virtual que deseamos migrar y

seleccionamos la opción Migrate.


65

Una vez seleccionemos esa opción se nos abrirá la siguiente ventana en la que

seleccionaremos la opción Change datastore.

Ahora deberemos elegir el disco de destino de la máquina virtual, elegiremos el DRS2 ya que

la máquina actualmente se encuentra en el DRS.

Observamos en la parte inferior de vSphere que se está realizando el proceso de Storage

vMotion.

Una vez finalice el proceso observamos en las propiedades de la máquina virtual migrada que

se ha migrado correctamente al disco elegido.


66

Finalmente volvemos a la consola donde se estaba realizando el ping hacia la máquina virtual

y observamos que no se ha parado en ningún momento.


67

8. Cluster

Un clúster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad,

de tal forma que el conjunto es visto como un único ordenador, más potente que los

comunes.

Los clústeres son normalmente usados para mejorar el rendimiento y la disponibilidad por

encima de la que es prevista por un solo ordenador normalmente siendo más económico que

ordenadores individuales de rapidez y disponibilidad similares.

De un clúster correctamente implementado debe tener estos servicios:

1. Alto Rendimiento

2. Alta disponibilidad

3. Balanceo de carga

4. Escalabilidad

Componentes de un clúster

Nodos: Los llamados Nodos de un clúster son los ordenadores que forman parte de

este, en un cluster puede haber dos tipos de nodos los dedicados y los no dedicados.

Los nodos dedicados son un tipo de nodos que se usan exclusivamente para realizar

tareas relacionadas con el clúster, en cambio los nodos no dedicados realizan más

tareas a parte de las relacionadas con el clúster.


68

Almacenamiento: Puede consistir en una NAS, una SAN, o almacenamiento interno en

el servidor. El protocolo más comúnmente utilizado es NFS, sistema de ficheros

compartido entre servidor y los nodos. Sin embargo existen sistemas de ficheros

específicos para clústeres como Lustre (CFS) y PVFS2.

Sistemas operativos.

Conexiones de red: Los nodos de un clúster pueden conectarse mediante una simple

red Ethernet con adaptadores de red o NICs, o utilizar tecnologías especiales de alta

velocidad como Fast Ethernet, Gigabit Ethernet, Myrinet, InfiniBand o SCI.

Protocolos de comunicación y servicios.

Aplicaciones.

Ventajas e inconvenientes de la utilización de un clúster

La utilización de un clúster tiene diferentes ventajas:

1. Ahorro de costes en recursos.

2. Compartición de información.

3. Soporte multiplataforma con la gestión de diferentes sistemas operativos y aplicaciones.

4. Es muy sencillo de implementar ya que esta tecnología es transparente para el usuario.

5. No exige ninguna sustitución ni adición de hardware.

La única desventaja que tiene un clúster es la seguridad ya que actualmente los protocolos de

seguridad, autentificación y control no están suficiente desarrollados para el uso de cualquier

usuario.


69

8.1 HA

Un Clúster de Alta Disponibilidad (HA) es un conjunto de dos o más servidores que se

caracteriza por compartir el sistema de almacenamiento, y porque están constantemente

monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de

las maquinas que forman el clúster, el software de alta disponibilidad es capaz de volver a

arrancar automáticamente los servicios que han fallado en uno de los otros equipos que

forman el clúster y cuando el servidor que ha fallado se vuelve a recuperar estos servicios se

migran de nuevo a la máquina original.

Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la

integridad de los datos, permite que los usuarios no noten ningún problema.

Hay diferentes razones para implementar este tipo de clúster:

Aumentar la disponibilidad

Mejorar el rendimiento

Escalabilidad

Tolerancia a fallos

Recuperación ante fallos en poco tiempo

Reducir costes

Consolidar servidores

Consolidar el almacenamiento

Configuraciones del cluster HA

En un clúster HA hay dos tipos de configuraciones el activo/activo y el activo/pasivo.

Configuración Activo/Activo

En una configuración de tipo activo/activo, todos los servidores del clúster pueden

ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los

mismos recursos y pueden acceder a estos independientemente de los otros servidores

del clúster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen

estando accesibles a través de los otros servidores del clúster.

La ventaja principal de esta configuración es que los servidores en el clúster son más

eficientes porque pueden trabajar todos a la vez. Sin embargo, si uno de los servidores

deja de estar accesible, su carga de trabajo pasa a los servidores restantes, lo que

produce una bajada del nivel global de servicio ofrecido a los usuarios.


70

Configuración Activo/Pasivo

Consiste en un servidor que posee los recursos del clúster y otros servidores que son

capaces de acceder a esos recursos, pero no los activan hasta que el servidor

propietario de los recursos ya no esté disponible.

Las ventajas de la configuración activo/pasivo son que no hay una bajada de servicio y

que los servicios solo se reinician cuando el servidor activo deja de responder.

Una desventaja de esta configuración es que los servidores pasivos no proporcionan

ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos

eficiente que el clúster de tipo activo/activo. Otra gran desventaja de este tipo de

configuración es que los sistemas tardan un tiempo en migrar los recursos al nodo en

espera.


71

Funcionamiento del cluster HA

En un clúster de alta disponibilidad, el software de clúster realiza dos funciones

fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando

continuamente su estado y detectando fallos. Y por otro lado administra los servicios

ofrecidos por el clúster, teniendo la capacidad de migrar dichos servicios entre diferentes

servidores físicos como respuesta a un fallo.

Elementos y conceptos básicos en el funcionamiento del clúster

Recurso y Grupos de Recursos

En un clúster de alta disponibilidad, el software de clúster, independiza a los servicios

de un host concreto, posibilitando que estos servicios se desplacen entre diferentes

servidores de forma trasparente para la aplicación o los usuarios.

El software de clúster permite definir grupos de recursos, los cuales son todos aquellos

recursos necesarios por el servicio.

Intercomunicación

El software de clúster que gestiona servicios y recursos en los servidores, tiene que

mantener continuamente entre estos una visión global de la configuración y estado del

clúster. De esta forma, ante el fallo de un nodo, el resto conoce que servicios se

deben restablecer.

Ya que la comunicación entre los servidores del clúster es básica para el

funcionamiento de este, es habitual utilizar un canal específico como una red IP

independiente o una conexión serie, la cual no se pueda ver afectada por problemas

de seguridad o rendimiento.

Heartbeat

El software de clúster conoce en todo momento la disponibilidad de los equipos físicos,

gracias a la técnica de heartbeat. Su funcionamiento consiste en que cada nodo

informa periódicamente de su existencia enviando al resto una “señal de vida”.

Escenario Split-Brain

En un escenario split-brain, más de un servidor o aplicación que pertenecen a un

mismo clúster intentan acceder a los mismos recursos, esto puede causar daños a

dichos recursos. Este escenario ocurre cuando cada servidor en el clúster cree que los

otros servidores han fallado e intenta activar y utilizar dichos recursos.


72

Monitorización de Recursos

Ciertas soluciones de clustering HA permiten monitorizar si un host físico está

disponible y también pueden realizar seguimientos a nivel de recursos o servicios y

detectar el fallo de estos.

Reiniciar Recursos

Cuando un recurso falla, lo primero que realiza el clúster es intentar reiniciar este

recurso en el mismo nodo. Esto supone detener una aplicación o liberar un recurso y

posteriormente volverlo a activar.

Migración de Recursos

Cuando un nodo ya no está disponible, o cuando un recurso que ha fallado no se puede

reiniciar correctamente en un nodo, el software de clúster reacciona migrando el

recurso o grupo de recursos a otro nodo disponible en el clúster. De este modo el

tiempo de inactividad por el posible fallo es bajo, y el clúster seguirá proporcionando

el correspondiente servicio.

Dependencia entre recursos

Habitualmente para que el clúster proporcione un servicio, son necesarios varios

recursos lo cual se conoce como grupo de recursos. Cuando se arranca o detiene un

servicio, sus recursos tienen que activarse en el orden correcto ya que unos dependen

de otros. El software de clúster tiene que permitir definir estas dependencias entre

recursos así como entre grupos.


73

Preferencia de Nodos

En configuraciones de clúster con múltiples nodos, es normal distribuir los servicios

entre los diferentes servidores ya que puede ser que los servidores tengan

características hardware diferentes y nos interese que, para un estado correcto del

clúster, algunos servicios se ejecuten siempre en un determinado servidor.

Comunicación con otros sistemas

El clúster tiene que monitorizar que un servidor y sus servicios están activos pero

también debe de comprobar que de cara a los usuarios el servidor no queda

desconectado de la red por algún fallo, por esta razón el software de clúster debe

comprobar que los nodos son alcanzables.

Fencing

En los clústers HA existe la situación en la cual un nodo deja de funcionar

correctamente pero todavía sigue levantado accediendo a algunos recursos y

respondiendo a peticiones. Para evitar que el nodo corrompa recursos o responda con

peticiones, los clústers lo solucionan utilizando una técnica llamada Fencing.

Su función principal es hacerle saber al servidor que está funcionando en mal estado,

retirarle sus recursos asignados para que los atiendan otros nodos, y dejarlo en un

estado inactivo.

Quorum

Para evitar que se produzca un escenario de Split-Brain, algunas características del

clúster HA introducen un canal de comunicación adicional que se emplea para

determinar exactamente que nodos están disponibles en el clúster y cuáles no.

Esto se implementa utilizando los llamados quorum devices que son un volumen de

almacenamiento compartido exclusivo. También existen implementaciones que

utilizan una conexión de red adicional o una conexión serie.


74

Novedades del clúster HA en Vsphere.

Capacidad de establecer el tamaño de la ranura para fallos de host tolerados a través

del cliente web.

Capacidad de recuperar una lista de las máquinas virtuales que abarcan múltiples

ranuras.

Soporte para el modo de suspensión del sistema operativo invitado.


75

8.2 DRS

Distributed Resource Scheduler (DRS) es una función que tiene VMware vSphere que se

encarga de balancear la carga que tienen los hosts ESX de un cluster. De esta forma nos

garantizamos mejorar el uso de los recursos dentro del mismo cluster.

Básicamente, DRS te permite administrar la carga de la CPU y memoria de un host para que

éste no se vea saturado y con un alto porcentaje de consumo.

El algoritmo de DRS tiene como entrada la información de uso de los recursos tanto de las VMs

como de los Hosts y como salida las recomendaciones de movimientos de las VMs de un host

origen a otro destino, es decir el emplazamiento de las VMs.

DRS acepta tres modos de funcionamiento: Manual, Partial o Full Automated Control y

dependiendo del modo elegido el emplazamiento de las VMs se hará de forma más o menos

automática.

Las funciones básicas de un DRS son:

Proporcionar recursos altamente disponibles para sus cargas de trabajo.

Equilibrar las cargas de trabajo para lograr un rendimiento óptimo.

Escalar y gestionar los recursos informáticos sin interrumpir el servicio.

De esta forma, DRS es capaz de equilibrar la capacidad informática mediante clústeres,

aportando así un rendimiento optimizado a los hosts y a las máquinas virtuales. Y gracias a

esto, nos ofrece:

Mejorar los niveles de servicio asegurándose de que las máquinas virtuales dispongan

de los recursos apropiados.

Implementar más capacidad en un clúster sin interrumpir el servicio.

Migrar automáticamente las máquinas virtuales durante las tareas de mantenimiento

sin interrumpir el servicio.

Supervisar y gestionar más cantidad de infraestructura por cada administrador del

sistema.


76

También debemos saber que el DRS puede reducir el consumo de energía del propio cluster,

para ello utiliza la tecnología DPM.

DRS es muy útil en casos de emergencia donde uno de los hosts o la propia máquina virtual

esté saturada y no sea capaz de dar más de sí, por falta de recursos. Gracias a esta función

podremos ver como las máquinas pasan de un host a otro sin ver interrumpida su

funcionalidad. Un usuario corriente desconocerá el movimiento de dicha máquina virtual

mientras éste estaba realizando cualquier uso.

Diagrama

Esta imagen nos indica lo que comentábamos más arriba. La máquina que no dispone de los

recursos necesarios por el motivo que sea (le falta memoria, tiene un procesador limitado, ha

llegado al tope de sus posibilidades, etc.) se migra automáticamente (utilizando por supuesto,

VMotion) a otro Datastore capaz de soportar estos datos.

DRS automáticamente distribuye las cargas de trabajo de las máquinas virtuales entre los

hosts de vSphere de un clúster y supervisa los recursos disponibles. En función del nivel de

automatización elegido, DRS migrará las máquinas virtuales a otros hosts del clúster, para

maximizar el rendimiento.


77

En cuanto una máquina virtual se vea al máximo de sus posibilidades en cuanto a rendimiento

se refiere, el DRS se activará y la migrará de un host a otro sin pérdida de información.

Mediante una serie de reglas podemos disponer de un Clúster DRS con más opciones y más

personalización, permitiéndonos establecer unas normas a nuestro gusto en cuánto tipo de

máquinas (grupos), tipo de hosts (si es un ESX u otro), un tipo de rendimiento en memoria o

CPU alcanza ciertos niveles, etc.

En la configuración del DRS podemos elegir como queremos que funcione la migración. Si

queremos que sea manual (es decir, que nosotros la ejecutemos). Si queremos que sea a base

de recomendaciones (Partially automated), con lo que el propio DRS nos avisará de que

máquinas deberían migrarse (según recomienda la propia función).

Y por último que se migren automáticamente cuando los recursos de los hosts lo necesiten.

Además, podemos hacer que la migración sea “Agresiva” en un nivel máximo. En cuanto vea

que es necesaria dicho cambio, lo haga sin dudar.


78

También tenemos la configuración DPM, que aunque no la hemos utilizado sirve para

optimizar los recursos físicos. Con esta opción podemos reducir un porcentaje importante de

energía para evitar el alto consumo de tantas máquinas iniciadas.

Reglas

La gran función que tiene DRS es que puedes agregar una serie de reglas y personalizar como

trabajarán tus hosts y tus máquinas virtuales. También nos permite agrupar una serie de

máquinas o hosts en un mismo grupo definido, esto nos simplifica el trabajo y si queremos

añadir una regla a unas cuantas máquinas, no tendrás que hacerlo una a una.

En la imagen podemos apreciar cómo se han creado dos grupos. Uno llamado Windows y otro

Linux. En cada uno se les ha insertado las máquinas virtuales respectivas de sus sistemas

operativos.

De la misma forma nos deja agrupar los hosts.


79

Aquí podemos ver, si seleccionamos el grupo “Windows” podremos seleccionar que máquinas

pertenecerán a ese grupo.

Después de la agrupación, ya podemos definir las reglas y ahorrarnos ese trabajo mencionado.

Esta regla específicamente trabaja para que las máquinas virtuales dentro del grupo “Linux”

se inicien automáticamente en el host ESX2. Como dice la regla “Should run on hosts in

group”. Cuando se inicia el servicio de vCenter y arrancamos los hosts, podemos apreciar

como cada máquina irá al destinatario correcto.


80

Por lo tanto, las reglas quedarían así:

- Las máquinas Windows en el host ESX1.

- Las máquinas Linux en el host ESX2.


81

Otra forma de agregar reglas es añadiendo Alarmas.

De esta forma podemos indicar una serie de acciones que pueden hacer las máquinas

dependiendo del “motivo” que tenga para hacerlo.

Es decir, podemos agregarle la opción de que si la CPU llega al 70% en cualquier máquina

virtual, entonces, esa máquina deberá migrarse automáticamente al otro host. De esta

manera evitamos que uno de los hosts esté con una alta carga de recursos y así podamos

igualar los dos para trabajar de una mejor forma.

Por ejemplo, añadimos una Alarma donde la condición sea que cuando la CPU supere el 30%

de rendimiento nos avise con un “Warning”


82

Entonces, una vez avisado, tomará la acción que le indicaremos. La acción tomada será

“Migrate VM” (utilizando vMotion). Le indicaremos que el host donde debe migrarse las

máquinas será el 192.168.1.41 (por ejemplo).

Y en la lista de tareas y resultados podemos ver como automáticamente hace esta migración,

sin tocar nada:

Pequeño estudio de Mercado

No solo VMware dispone de la tecnología DRS, otras marcas también tienen funciones

similares.

Es el caso de Hyper-V y su llamado “Dynamic Optimization”. El estilo es similar al DRS, ya

que Dynamic Optimization utiliza el Vmotion en las máquinas virtuales que están dentro de un

clúster para mejorar el equilibrio de carga entre los hosts. Pueden ser migradas con una

frecuencia y agresividad que tú específicas y por defecto cada 10 minutos se migrarán dichas

máquinas con la opción "Agresiva".

Si un grupo de hosts contiene independientes anfitriones, los clústeres de hosts que no

soportarán la migración en vivo, o el modo de mantenimiento. Dynamic Optimization no se

llevará a cabo en estos equipos.

Si un clúster de hosts contiene máquinas virtuales sin alta disponibilidad, las máquinas

virtuales no harán este proceso de migración.

También RedHat con su versión RHEV-M 3.3 presenta como nueva tecnología este tipo de

función. Incluye un nuevo planificador para manejar la colocación de la máquina virtual, lo

que permite a los usuarios crear nuevas políticas de planificación, y también escribir su propia

lógica en Python e incluirlo en una política. El nuevo planificador sirve solicitudes de

programación para ejecutar o migrar máquinas virtuales. La planificación se lleva a cabo


83

mediante la aplicación de restricciones "agresivas" y restricciones "blandas" para conseguir el

anfitrión óptimo para esa solicitud en un punto dado del tiempo.

IBM con PowerVM 2.2 también cuenta con este tipo de migración por balanceo llamadas

"FSM" o "VMControl". Son herramientas opcionales que vienen con el producto y utiliza reglas

para la reubicación y automización de los hosts dentro de un grupo de servidores.

Anteriormente Citrix XenServer también utilizaba una opción de balanceo de carga, pero a

partir de la versión 6.2 se suprimió. Los motivos aparentemente son porque los clientes que

utilizan XenServer no han utilizado esta opción y los porcentajes han sido bastante bajos en

cuanto a "adopción" del producto.

Problemas y preguntas frecuentes

¿Qué ocurre si quitamos un host del Cluster?

Si tenemos Manual o Partially Automated nos mostrará sus recomendaciones, si tenemos

configurado Fully Automated las VMs seran migradas a otros hosts.

¿Qué ocurre si ponemos un host en Maintenance Mode?

Las operaciones en dicho host se restringen automáticamente: No se pueden encender nuevas

VMs dicho host y no se pueden migrar VMs a dicho host.

El administrador deberá apagar las VMs o migrarlas a otras (se recomendara) y posteriormente

apagar el host.

(El host marcado como en mantenimiento no será tenido en cuenta para HA)

¿Qué ocurre si se cae el Virtual Center Server?

Los hosts seguirán corriendo usando los recursos disponibles pero no habra recomendaciones

para optimización de recursos.

A tener en cuenta una serie de características:

DRS es proactivo, actúa para balancear y no provoca downtime (tiempo inactivo). No

confundir con VMware HA que es reactivo: actúa cuando se ha caído un host y si tiene

downtime de las VMs.


84

Monitorización:

La monitorización del Clúster se puede realizar a través del propio Virtual Center.

Un clúster sin ningún color en particular nos indica que todo está correctamente.

Un clúster de color amarillo (Overcommitedor Host down) indica que algún

requerimiento de recursos no está siendo satisfecho por el cluster. Solución: aumentar

recursos o decrementarreservations.

Un clúster de color rojo nos indica que el clúster está inconsistente o es invalido

Errores de DRS

No se puede encender una VM aunque tenga de reservation menos que la capacidad

sin reservar del resource pool.

Causa: El host tiene que tener suficiente Aggregateunreservedcapacity y Per-corecapacity.

Solución: Establecer en los hosts esta opcion de

configuracionCpu/VMAdmitCheckPerVcpuMinto 0 (OJO: notrecommended)

Errores de VMotion:

Relación de clúster entre VMs (MSCS)

La VM tiene afinidad a una CPU fisica:

Solución: Quitar la VM del cluster, quitar la afinidad y volver a meter al clúster DRS.

La VM tiene conectado el CD-ROM / floppy

Alertas de VMotion:

La VM está configurada a un virtual switch interno pero no está conectada a él.

La VM está configurada para acceder al CD-ROM/floppy pero NO está conectada a él.


85

9. Storage DRS

Storage DRS equilibra continuamente la utilización del espacio y la carga de E/S del

almacenamiento. Al mismo tiempo, evita los cuellos de botella de los recursos para respetar

los niveles de servicio de las aplicaciones. El uso de DRS le permite una serie de ventajas:

Implementar e integrar capacidad de almacenamiento adicional en un pool de

almacenamiento.

Sacar partido de la nueva capacidad.

Mejorar los niveles de servicio para todas las aplicaciones.

Aumentar la productividad de los administradores de VMware vSphere permitiéndoles

supervisar y gestionar la infraestructura adicional.

vSphere 5 introduce el concepto de cluster de datastore. Un cluster de almacenamiento es,

desde la perspectiva de un administrador, un conjunto de discos (datastores) agregados en

una única unidad. Cuando se crea un cluster de este tipo, Storage DRS puede administrar los

recursos de almacenamiento de igual manera a como hace DRS a nivel de procesamiento para

un cluster de hosts, balanceando la carga entre los discos disponibles en el cluster.

Hay que saber diferenciar entre:

Datastore Cluster sin SDRS activado: solo es un grupo de datastores.

Datastore Cluster con SDRS activado: Balanceo de cargas y espacio.


86

¿Qué operaciones realiza SDRS?

Un cluster de SDRS realiza las siguientes operaciones:

Colocación inicial. En el momento que nosotros creemos una nueva máquina virtual,

estaremos seleccionando un datastore cluster en vez de seleccionar un datastore tradicional,

con esto, le permitiremos a SDRS tomar en cuenta el histórico de latencia que se tiene de los

datastores que componen dicho cluster (estaremos hablando de como se obtiene más

adelante) y el espacio disponible.

Por defecto, colocarán todos los archivos de una máquina en un mismo datastore aunque esto

puede ser modificado con reglas de afinidad y anti afinidad entre las máquinas, en este punto

será el primer beneficio que SDRS nos entrega, permitiendo colocar las máquinas en el

datastore con mejores características.

Balanceo de Carga. Una vez que las máquinas virtuales sean colocadas en los datastores que

conforman dicho cluster, se comenzará a recolectar estadísticas de latencia en cada uno de

los datastores que conforman dicho datastore cluster, hasta después de 16 horas de capturar

estadísticas se comienza con el balanceo de cargas a nivel de I/O.

En el caso de que se esté ejecutando alguna operación de Storage VMotion la captura de

estadísticas no comienza ya que este tipo de operaciones alteran bastante el comportamiento

de nuestro almacenamiento, por lo cual, puede tardar más de 16 horas en comenzar el

balanceo.

Las recomendaciones dadas por SDRS se

basarán en 2 tresholds modificables, el

espacio libre y la latencia a disco, en el

caso de latencia a disco se tiene un valor

por defecto de 15 ms, al igual que DRS,

estas se aplicarán o no según el nivel de

automatización que se tenga en dicho

datastore cluster.

Las estadísticas de latencia son obtenidas

cada 30 minutos y se analizan las cargas

en periodos de 8 horas, por lo cual se

tiene un histórico, y en el momento de

realizar las recomendaciones se tomará

en cuenta si estas nos entregarán un

beneficio por lo menos 24 horas de lo

contrario no se aplicarán. Solo en el

momento que se exceden los valores

definidos es cuando comienza el balanceo.


87

Cuando el rendimiento de un disco está llegando al máximo, utiliza la función DRS, que ligada

al almacenamiento nos permite migrar todo el contenido de una máquina virtual (eso significa

la carpeta y todos los archivos) hacia otro disco.

En Storage DRS podemos encontrar dos puntos muy importantes para la utilización del mismo,

ofreciendo la comodidad del servicio.

Supervisión continúa

Storage DRS supervisa el espacio de almacenamiento y la utilización de E/S en un almacén de

datos preasignado. Además, coordina los recursos de almacenamiento para cubrir sus

necesidades de crecimiento empresarial. La supervisión de Storage DRS le permite:

Especificar cómo se asignan los recursos de almacenamiento a las máquinas virtuales,

mediante reglas y políticas.

Asignar infraestructura de almacenamiento dedicada a las unidades de negocio, e

incrementar el índice de utilización del almacenamiento mediante grupos de

volúmenes de almacenamiento.

Capacitar a las unidades de negocio para que creen y gestionen máquinas virtuales

dentro de sus grupos de almacenamiento y, al mismo tiempo, brindar al equipo de TI

el control centralizado de todos estos recursos.

Mantenimiento sin interrupciones

Cuando un administrador de vSphere coloca en modo de mantenimiento un clúster de

almacenes de datos habilitado para Storage DRS, este último mueve los archivos de disco de

las máquinas virtuales a otro almacén de datos. Un almacén de datos permanece en el estado


88

de transición al modo de mantenimiento hasta que todos los discos virtuales se han movido a

otros almacenes de datos del clúster. Storage DRS presenta también las siguientes

funcionalidades:

Recomendaciones de colocación para la migración de discos virtuales.

Una lista de errores que muestra los archivos de disco de las máquinas virtuales que no

se pueden mover y los motivos de ello.

Hay que tener en cuenta que Storage DRS utiliza y se aprovecha de las tecnologías DRS y

vMotion. Cuando el DRS se activa por el uso drástico de los discos, empieza la migración. Y

dicho movimiento se realiza gracias a vMotion. Todo ligado hace el uso de Storage DRS, el

cuál no hay que confundir con Storage vMotion, ya que éste se hace manualmente o con la

utilización de un Clúster HA.

Gracias a Storage DRS podemos tener un equilibrio continúo.

Es decir, Storage DRS toma decisiones con Storage vMotion para reducir la latencia de E/S y

garantizar un rendimiento óptimo de todas las máquinas virtuales.

Reglas de afinidad

Como método opcional se pueden definir una serie de reglas de afinidad y anti-finadad para

los archivos de los discos de las máquinas virtuales (llamados VMDK).

De forma predeterminada, los archivos de disco de las máquinas se guardan en el mismo

almacén de datos, pero Storage DRS te permite:

Afinidad de VMDK (opción predeterminada): los discos virtuales de una máquina

virtual se mantienen juntos en el mismo almacén de datos.

Anti-afinidad de VMDK: en una máquina virtual que tiene varios discos virtuales, estos

últimos se colocan en almacenes de datos diferentes.

Anti-afinidad de máquina virtual: dos máquinas virtuales concretas, incluidos sus

discos asociados, se colocan en almacenes de datos diferentes.


89

La correlación de almacenes de datos es un mecanismo avanzado de equilibrio de la carga de

E/S incluido en Storage DRS. Detecta si dos almacenes de datos diferentes están usando el

mismo grupo de discos físicos de una matriz. Cuando esto sucede, aplica las reglas de afinidad

y mueve los archivos de disco de las máquinas virtuales para mitigar los cuellos de botella de

E/S.

Por ejemplo, se puede definir que dos máquinas virtuales estén separadas y en diferentes

almacenes de datos:

Estadísticas

La latencia medida por SDRS no es en tiempo real, esta es tomada a partir de datos históricos,

por ejemplo, si el día anterior se tuvo latencias mayores a 15 ms el 94% del tiempo se

considera que dicho datastore está sobre cargado. Algo interesante es que podemos definir

ventanas de tiempo para que estas no sean consideradas en los históricos de SDRS, esto nos

hace mucho sentido si

tenemos ventanas

definidas de anti-virus:


90

10. Fault Tolerance

VMware Fault Tolerance es un componente de VMware vSphere que proporciona una

disponibilidad continua de las aplicaciones mediante la prevención de tiempo de inactividad y

la pérdida de datos de máquinas virtuales en caso de fallas en el servidor ESX.

Fault Tolerance permite que una máquina virtual, esté en Activo/Pasivo en sendos hosts.

Básicamente se duplica el fichero de memoria RAM y se accede a la vez a las máquinas

virtuales por dos hosts ESX, siendo uno el Activo, el que atiende las peticiones de los usuarios

y quedando el otro en pasivo y no escuchando peticiones de usuario.

Entonces, si una máquina virtual está en Fault Tolerance y el host ESX que la soporta cae, el

otro host ESX que está en modo pasivo, entra automáticamente en modo activo y empieza a

escuchar peticiones, pudiendo haber pérdida de algún ping pero no del servicio.

Adicionalmente Fault Tolerance busca otro host ESX con suficientes recursos y lo configura

como pasivo para que la VM siga estando en Fault Tolerance.

La máquina virtual no se duplica, esto es, es una sola entidad con una IP y un hostname y

todas sus características internas añadidas. Pensemos que podemos tener en Fault Tolerance

un Windows XP, un Linux o un Solaris 10x64, por poner algunos ejemplos.

La función Fault Tolerance (FT) proporciona disponibilidad continua para las aplicaciones en

caso de fallos del servido al crear una instancia duplicada en tiempo real de una máquina

virtual que siempre está sincronizada con la principal. En caso de interrupción del hardware,

la función FT activa automáticamente la conmutación por error, garantizando el tiempo de

inactividad cero y evitando la pérdida de datos.

Tras la conmutación por error, la función FT crea automáticamente una nueva máquina

virtual secundaria con el fin de proporcionar protección continua a la aplicación.

La función FT protege cualquier máquina virtual, incluso las aplicaciones internas y

personalizadas que los productos de alta disponibilidad tradicionales no pueden proteger.

Algunas de las funciones de FT son las siguientes:

Es compatible con cualquier tipo de almacenamiento compartido, incluido

FibreChannel, iSCSI, FCoE y NAS.

Es compatible con todos los sistemas operativos admitidos por vSphere.

Funciona con clústeres DRS o HA.

Contiene un mecanismo de control de versiones que permite que las máquinas

virtuales principal y secundaria se ejecuten en hosts que admitan la función FT con

niveles de parches distintos, pero compatibles.


91

Requisitos

Para que Fault Tolerance funcione son necesarios una serie de requisitos:

1. VMware FT está disponible después de versiones de vSphereAdvanced versión

(Advanced, Enterprise, Enterprise Plus).

2. Hardware virtualización debe estar activado en el BIOS.

3. CPU debe ser compatible con el FT.

4. Activar las máquinas virtuales que se deben colocar en el almacenamiento compartido

(FC, iSCSI o NFS).

5. Las máquinas virtuales se deben colocar en un DRS/HA Cluster.

6. FT no se puede utilizar con DRS en vSphere 4.0 FT pero está totalmente integrado

apartir de DRS de vSphere 4.1.

7. A partir de vSphere 4.0, ESX primaria y secundaria debe tener la misma versión de

ESX. Esta limitación no ocurre en vSphere 4.1 o más.

8. Sólo se permiten 4 máquinas virtuales por ESX / ESXi.

9. VMotion y FT Logging deben estar habilitadas en la red VMKernel de la máquina virtual

(NIC separada para vMotion y FT registro está recomendando junto con la agrupación

de NIC).

10. La comprobación de certificado de host debe estar habilitado (activado por defecto).

11. Tarjeta Ethrenet 10 GB entre servidores ESX dará mejores resultados de rendimiento.

12. Puertos FT 8100, 8200 (TCP saliente, UDP entrante y saliente) debe estar abierto si

existe cualquier firewall entre los servidores ESX.

13. Mínimo de 3 hosts en clúster DRS/HA habilitado es el requisito para el funcionamiento

de FT protegida con máquinas virtuales.

14. Máquinas virtuales FT no se pueden copiar utilizando la tecnología de copia de

seguridad como (VCB, recuperación de datos de VMware), que utiliza la función de

instantáneas.

15. NPIV (N-portid Virtualización) no es compatible con VMware FT


92

16. Usar redundancia en todas las capas (como la agrupación de NIC, múltiples switches de

red y de almacenamiento multiruta) para aprovechar al máximo las características de

FT.

17. Clusters MSCS no son compatibles con VMwareFaultTolerance.

18. En vSphere 4.0, se permite vmotion Manual, pero el equilibrio de carga automático

utilizando VMotion por DRS es totalmente compatible a partir de vSphere 4.1.

Diagrama

En esta imagen se puede apreciar como el Cliente se conecta a una máquina virtual, en la

cual tiene todos sus datos (que los está recibiendo de los discos en la nube).

El usuario puede estar trabajando tranquilamente y no darse cuenta de la caída de su

servicio. El Fault Tolerance es cuando actúa en este momento, cuando se cae el host con la

máquina virtual dentro, automáticamente el segundo host (el cual ha estado en modo pasivo

esperando algún tipo de problema del primario) se activa y responde a la caída.

El host primario activa vMotion y pasa todas las máquinas que tenga en ese host caído al otro

host (secundario). Una vez se ha realizado dicha tarea, el host secundario se convierte en el

primario y actúa de la misma forma de como lo hacía con anterioridad el otro host.

De esta forma, los usuarios pueden seguir trabajando como si no hubiera pasado nada.


93

Aquí podemos apreciar el movimiento que hace el host primario hacia el host secundario de la

máquina virtual:

A pesar de ambas máquinas virtuales primarias y secundarias aparecen como una sola entidad

y acceden a un disco común, ambas corren con una única dirección IP, dirección MAC, pero

las escrituras sólo se llevan a cabo por las máquinas virtuales primarias. Las máquinas

virtuales primarias y secundarias envían entre cada latidootra frecuencia con intervalos de

milisegundos a la comprobación de la disponibilidad. Si alguna de las máquinas virtuales

pierde dicho latido, otra máquina se hará cargo del rol de máquina virtual primario

inmediatamente.


94

¿Qué sucede cuando se ha activado la tolerancia de fallos en la máquina virtual?

Cuando se habilita la tolerancia a fallos de la máquina virtual, la secundaria será creada para

trabajar con la máquina virtual primaria en el que se ha habilitado FT. La máquina virtual

primaria y secundaria residen en un hosts diferentes del clúster.

¿Qué sucederá cuando el host ESX de VM primaria caiga?

Cuando se detecta un fallo en el host ESX primaria, la máquina virtual secundaria (que se

ejecuta en el servidor ESX, pero en otro host) toma el lugar de la primera con la menor

interrupción posible del servicio.

¿Si vCenter no está disponible, podrá ejecutarse FaultTolerance?

El servidor vCenter sólo es necesario para permitir que Fault Tolerance esté configurado en la

máquina virtual. vCenter no está obligado a estar en línea para que Fault Tolerance funcione.

La conmutación por error entre primaria y secundaria volverá a aparecer incluso si el vCenter

está caído.

¿En qué se diferencian VMware FT y VMware HA/DRS?

1. VMware HA/DRS es un Cluster y FT es una característica para máquinas virtuales.

2. En caso de que ocurra un fallo en el host ESX, las máquinas virtuales que estén dentro

del host son reiniciadas y se cargan/mueven en los otros hosts activos del cluster.La

duración del reinicio de las máquinas virtuales es el "downtime" (tiempo de

inactividad) de dichas máquinas en el Cluster HA/DRS.

En cambio, en Fault Tolerance no hay este downtime (tiempo de inactividad).

Si uno de los hosts falla, vMotion hará que la secundaria se convierte en primaria y

continúe ejecutando los servicios donde la primera se quedó antes de fallar. Esto se

produce automáticamente sin perder los datos, sin tiempo de inactividad y con un

pequeño delay (retraso), pero que los usuarios no verán ningún tipo de interrupción.


95

Configuración

A la hora de realizar la configuración para Fault Tolerance necesitamos una red más, que

conecte ambos ESXi.

Creamos la tarjeta de red en la opciones de ESXi. Añadimos dicha red a vSphere (en ambos

hosts).

El primer paso es habilitar el registro de tolerancia a fallos en un puerto VMkernel, en todos

los hosts en la que se quieran tener las máquinas protegidas. Una vez más, la alta

disponibilidad dictan un puerto VMkernal dedicado en una tarjeta de red dedicada (aunque

esto no es un requisito estricto).

Hay que seleccionar la opcion “use this port group for Fault Tolerance logging”.

Y debería quedar una tarjeta de red solo para FT en una nueva red.

Durante el proceso de comprobación de Fault Tolerance tuvimos problemas de

compatabilidades. Algunas máquinas necesitaban agregar una serie de condiciones o reglas

avanzadas para poder iniciarse y permitirse la función FT.


96

Estas tres opciones tienen que estar habilitadas:

replay.supported = “true”

replay.allowFT = “true”

replay.allowBTOnly = “true”

Básicamente estas reglas significan que Fault Tolerance está habilitado y nos permite seguir

trabajando.


97

El siguiente paso es encender la opción en la máquina virtual:

Las opciones de Fault Tolerance son las siguientes:

Disable Fault Tolerance – en el caso que nosotros quisiéramos solo deshabilitar

temporalmente FT debemos utilizar esta opción, ya que se conserva la VM secundaria,

la configuración y el historial de las VMs.

Turn off Fault Tolerance – en este caso se eliminan las VMs secundarias y toda

configuración de las mismas.

Migrate Secondary – con esta opción podemos migrar de host nuestra VM secundaria.

Test Failover – con esta opción se realiza un failover de nuestra VM principal a la

secundaria, y se creará nuevamente una VM secundaria en algún otro host del cluster.

Test Restart Secondary – con esta opción la VM secundaria se reinicia, con lo cual

podemos verificar la consistencia entre la secundaria y primaria.


98

En la primera ocasión tarda un poco en procesarse, pero luego ya tendremos FT rápido y sin

problemas:

La imagen nos muestra como se ha creado la máquina XP2 “secondary” en el segundo host

(192.168.1.41). Mientras la primaria sigue donde estaba (192.168.1.40).

Una vez iniciemos las máquinas, deberíamos ver las dos pantallazas y como la secundaria es

una réplica remota de la primaria:


99

Una vez se apague el host primario, el secundaria hará el proceso Fault Tolerance para

convertirse en primario, como ya hemos explicado más arriba.

Limitaciones

Aunque Fault Tolerance es una gran función, lamentablemente también tiene una serie de

limitaciones que no permiten disfrutar al máximo de este tipo de posibilidades.

Las instantáneas se deben quitar antes de FT se puede habilitar en una máquina

virtual. Además, no es posible tomar instantáneas de máquinas virtuales en el que FT

está habilitado.

N_Port ID Virtualization (NPIV) no es compatible con el FT. Para usar el FT con una

máquina virtual debe desactivar la configuración NPIV.

Adaptadores paravirtualizados no son compatibles con el FT.

RDM física no es compatible con el FT. Solo se pueden usar RDM virtuales.

FT no se admite con las máquinas virtuales que tienen CD-ROM o dispositivos virtuales

de disquete conectado a un dispositivo físico o remoto. Para usar el FT con una

máquina virtual con este problema, quite el CD-ROM o dispositivo virtual floppy o

volver a configurar el respaldo con un ISO instalado en el almacenamiento compartido.

La función de conexión se desactiva automáticamente por culpa de las VMs con Fault

Tolerance. Para los dispositivos de conexión en caliente (cuando ya sea agregando o

quitando ellos), se debe apagar momentáneamente FT, realizar la conexión en

caliente, y luego poner FT de nuevo.

EPT / RVI se desactiva automáticamente para máquinas virtuales con FT activado.

IPv6 no es compatible; debe utilizar direcciones IPv4 con FT.

Sólo se puede utilizar FT en un vCenter Server que se ejecuta como una máquina

virtual si se está ejecutando con una sola CPU virtual.

VMotion se admite en habilitado para FT máquinas virtuales, pero no puedes VMotion

las máquinas virtuales tanto primarias como secundarias al mismo tiempo. SVMotion no

se admite en habilitado para FT VMs.


100

A partir de vSphere 4.1, se puede utilizar el FT con DRS cuando la función está

activada EVC. DRS llevará a cabo la colocación inicial en habilitado para FT máquinas

virtuales, y también incluirá en los cálculos de equilibrio de carga del cluster. Si EVC

en el clúster está deshabilitado, los fabricantes de vehículos habilitados para FT se les

da un nivel de automatización DRS de "discapacitado". Cuando una máquina virtual

primaria está encendida, la máquina secundaria se coloca de forma automática, y

tampoco VM se mueve con fines de equilibrio de carga.

Para comprobar que todo nuestro sistema (Datacenter, Cluster, Hosts y máquinas virtuales)

cumplen los requisitos necesarios para el Fault Tolerance, VMware ofrece una herramienta

llamada "Perfil Cumplimiento vCenter Server".

Para acceder al uso de este método sólo tienes que seleccionar el clúster en el panel

izquierdo de vSphere Client y, a continuación, en el panel derecho, seleccione la ficha Perfil

de Cumplimiento.

VMware recomienda no utilizar FT con mezclas entre ESX y ESXi. Esto básicamente es por

temas de compatabilidad.

Una vez se cumplan los requisitos, Fault Tolerance es sencillo y solo se tiene que utilizar con

los pasos descritos más arriba.

Consideraciones

VMware pasó mucho tiempo trabajando con Intel y AMD para refinar sus procesadores

físicos para que VMware pudiera implementar su tecnología vLockstep, que replica las

transacciones no deterministas entre los procesadores mediante la reproducción de sus

instrucciones de la CPU. Todos los datos se sincronizan, lo que no hay pérdida de datos

o transacciones entre los dos sistemas. En caso de un fallo de hardware, es posible que

tenga un paquete IP transmitido, pero no hay ninguna interrupción en el servicio o la

pérdida de datos, ya que la VMs secundarias siempre pueden reproducirse en la

ejecución de la máquina virtual primaria hasta su última salida.

FT no utiliza una característica específica de la CPU, pero requiere que las familias

específicas de la CPU para funcionar. vLockstep es más de una solución de software

que se basa en algunas de las funciones de base de los procesadores. El nivel de

software registra las instrucciones de la CPU en el nivel de máquina virtual y se basa

en el procesador para hacerlo, tiene que ser muy preciso en términos de tiempo y

VMware necesitaba los procesadores para ser modificados por Intel y AMD para

asegurar la exactitud completa. La utilidad SiteSurvey simplemente se ve en ciertos

modelos de CPU y las familias, pero las características no específicas de la CPU, para

determinar si una CPU es compatible con FT. En el futuro, VMware podrá actualizar su

utilidad CPU ID reportar también si la CPU es FT-capaz.


101

En el caso de escenarios de cerebro dividido (es decir, pérdida de conectividad de la

red entre los hosts), la máquina virtual secundaria puede tratar de convertirse en la

principal, resultando en dos primarias que se ejecutan al mismo tiempo. Esto se evita

mediante el uso de un bloqueo en un archivo de FT especial, una vez que se detecta

un fallo, tanto máquinas virtuales tratará de cambiar el nombre de este archivo, y si

tiene éxito la secundaria se convierte en el primario y engendra una nueva secundaria.

Si falla la secundaria es porque el principal sigue funcionando y ya tiene el archivo

bloqueado, la VM secundaria es “asesinado” y una nueva secundaria se genera en otro

host.

No hay límite en el número de hosts habilitados para FT en un clúster, pero no se

puede tener grupos que abarquen VMs compatibles con FT. Una versión futura puede

apoyar a las agrupaciones que abarcan VM compatibles con FT.

Existe una API para FT que proporciona la capacidad de scripts ciertas acciones, por

ejemplo, deshabilitar / habilitar FT utilizando PowerShell.

Hay un límite de cuatro máquinas virtuales habilitadas para FT por host (no por

grupo); esto no es un límite obligado, pero se recomienda para un rendimiento

óptimo.

La versión actual de FT está diseñada para ser utilizado entre los hosts en el mismo

centro de datos, y no está diseñado para trabajar a través de enlaces WAN entre los

centros de datos debido a los problemas de latencia y las complicaciones de

conmutación por error entre sitios. Las futuras versiones pueden ser diseñados para

permitir el uso de FT entre los centros de datos externos.

Hay que tener en cuenta que la máquina secundaria puede ralentizar la primaria si no

está recibiendo suficientes recursos de la CPU para mantenerse al día. Esto se nota por

un lapso de tiempo de varios segundos o más. Para resolver esto, hay que ajustarla a

una reserva de la CPU en la máquina primaria, que también se aplica a la máquina

secundaria y se asegurará de que tanto las máquinas virtuales se ejecuten a la misma

velocidad de la CPU. Si la VM secundaria se ralentiza hasta el punto que está

afectando gravemente el desempeño de la primaria, FT hace que se cierre y se cree

una nueva secundaria en otro host.

FT puede activarse y desactivarse fácilmente en cualquier momento, a menudo esto es

necesario cuando se necesita para hacer algo que no se admite cuando se utiliza FT,

tales como SVMotion, instantánea o hot-add de hardware a la máquina virtual.

Además, si hay períodos de tiempo específicos cuando la disponibilidad de la máquina

es crítica, como cuando un proceso mensual se está ejecutando, puede habilitarlo

para ese período de tiempo para asegurarse de que se mantiene mientras el proceso


102

está en marcha, y desactivarlo después.

Cuando FT está habilitado, los límites de memoria de la máquina virtual de primaria

serán eliminados y una reserva de memoria se establecerán igual a la cantidad de

memoria RAM asignada a la máquina virtual. Después no se podrán cambiar los límites

de memoria, acciones, o reservas en la máquina primaria mientras que FT está

habilitada.


103

11. Conclusión del Proyecto

Ha sido un proyecto bastante gratificante de hacer. Gracias a las funcionalidades que ofrece

VMware hemos aprendido muchas tecnologías y opciones que no sabíamos que existían en el

mundo de la virtualización.

Por ejemplo, la utilización de DRS es bastante importante para una empresa. Conocíamos de su

existencia, pero no como funcionaba realmente. Gracias a una profunda investigación y puesta

práctica, sabemos que si una Empresa de alto nivel quiere tener una alta disponibilidad

necesitará tener un DRS implementado, para así evitar que los hosts lleguen a sus máximos y

acaben bloqueándose.

No sabíamos que podíamos personalizar tan ampliamente la opción DRS. Añadiendo una serie

de reglas y alarmas puedes administrar perfectamente el rendimiento de todo tu hardware.

Otra opción, la cual desconocíamos era Fault Tolerance. Sin duda un gran "avance" para el

mundo de la virtualización y hospedaje de máquinas dentro de servidores. Esta opción también

nos permite una alta disponibilidad máxima. Gracias a Fault Tolerance podemos evitar

desastres, por ejemplo, si un host se cae y tenemos Fault Tolerance activado en dicha

máquina, automáticamente podremos acceder a la máquina sin ningún problema. Es decir, el

usuario normal y corriente puede seguir trabajando sin ningún problema y sin conocer de este

problema, ya que no existe un tiempo de inactividad como sí presentan otras opciones como HA

con vMotion.

Pero todavía hay más, Fault Tolerance es una tecnología que puede engrandecerse más y

mejorar. Solo VMware dispone de esta opción, las otras grandes empresas de virtualización

como Hyper-V o Citrix no cuentan con algo similar. Sin duda lo más destacable es que Fault

Tolerance puede evolucionar mucho más, todavía tiene alguna serie de limitaciones que serán

arregladas en futuras versiones.

En este proyecto hemos podido trabajar con una infraestructura real. Con dos ESXi instalados,

más dos núcleos de almacenamiento (FreeNAS) y el panel de administración desde vCenter y

vSphere Client nos ha permitido trabajar cómodamente. Las opciones que presenta vSphere son

muy intuitivas y puedes administrar todo el montaje sin problemas.

Para reunir toda la información y datos hemos buscado muchísima información por Internet. En

algunas ocasiones no encontrábamos nada y nos hemos puesto en contacto con expertos en

VMware y hemos visitado los Foros oficiales para llegar a obtener esa información poco

documentada por la red.

El tipo de proceso utilizado para la recopilación de datos ha sido conocer con que estábamos

trabajando, buscar ejemplos (vídeos, imágenes), implementarlo y probarlo en vSphere y por

último documentarlo.


104

Nos hubiera gustado seguir avanzando en este proyecto. Creemos que todavía se puede

investigar e implementar más opciones de vSphere, ya que es un mundo muy amplio en cuanto

a virtualización, pero lamentablemente el tiempo no fue el suficiente, además de un

inconveniente inicial, ya que este no era nuestro proyecto pensado en primer momento y

decidimos cambiar. Una decisión que nos alegramos de haber tomado, ya que con vSphere y sus

demás complementos hemos aprendido cómo se maneja un mundo de virtualización.

La única limitación y "pero" que le pondríamos al proyecto es la falta de recursos que hemos

tenido. En muchas ocasiones, cuando administrábamos vSphere Client hemos tenido problemas

de funcionalidades a causa del hardware, el cual era un poco limitado.

Los PCs utilizados para los hosts no están orientados para trabajar con una infraestructura ESXi,

físicamente hubiéramos necesitado una mayor capacidad. Hay que tener en cuenta que

nosotros hemos virtualizado un hypervisor, cuando éstos deben ya estar instalados en el propio

servidor físico, en cambio nosotros hemos tenido "la barrera" de un sistema operativo por

encima y luego emularlo con VMware. Eso ha reducido la dedicación total hacia el servidor.

También destacar que durante el trabajo con vSphere, nos saltaban muchas alertas de CPU.

Disponíamos de dos Intel i3, quizás con un poco más (un i5) no habríamos tenido estas alertas

un poco molestas, ya que en algunas situaciones no nos dejaba trabajar por la limitación de un

host (por ejemplo, se ponía a 100% de CPU con 2 máquinas virtuales con Fault Tolerance).

A pesar de todo eso, no ha supuesto un impedimento para seguir trabajando e investigando.

Sabemos que en cualquier empresa existen problemas, errores u obstáculos para el trabajo

diario. Eso nos ha ayudado a tener más paciencia, a seguir buscando hasta encontrar una

solución práctica.


105

12. Webgrafía

VMware página:

http://www.vmware.com/es/products/vsphere/features.html

DRS:

http://www.vmware.com/es/products/vsphere/features/drs-dpm.html

https://www.youtube.com/watch?v=US0bGHtiISc

https://www.youtube.com/watch?v=gATLj6pUxnk

Storage DRS

https://www.youtube.com/watch?v=z77xmaxoNec

Fault Tolerance

http://www.youtube.com/watch?v=zoi9gdy-Ceg

http://www.josemariagonzalez.es/2009/06/11/prueba-tu-mismo-vsphere-vmware-fault-

tolerance.html

Dudas, requisitos y cosas de FT:

http://www.vmwarearena.com/2012/08/vmware-interview-questions-answers.html

Mucha información sobre vMware:

http://www.josemariagonzalez.es/

Reglas DRS y explicación DPM:

http://blog.hispavirt.com/tag/drs/

Advanced Rules DRS:

http://www.virtuallyghetto.com/2011/07/new-vsphere-5-ha-drs-and-sdrs.html

Storage DRS:

http://www.yellow-bricks.com/2011/07/12/vsphere-5-0-storage-drs-introduction/

Más virtualización:

http://www.ideasmultiples.com/imvps/virtualizacion.php

http://centrodeartigos.com/articulos-noticias-consejos/article_126331.html

Virtualización Bare-Metal:

http://blog.virtualizamos.es/tag/bare-metal/

vSphere Client vs Web

http://federicocinalli.com/blog/item/119-vsphere-client-vs-vsphere-web-

client#.U4Wae_l_uBo

http://www.vmware.com/es/products/vsphere/features.html

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

https://www.youtube.com/watch?v=z77xmaxoNec

http://www.youtube.com/watch?v=zoi9gdy-Ceg

http://www.josemariagonzalez.es/2009/06/11/prueba-tu-mismo-vsphere-vmware-fault-tolerance.html

http://www.josemariagonzalez.es/2009/06/11/prueba-tu-mismo-vsphere-vmware-fault-tolerance.html

http://www.vmwarearena.com/2012/08/vmware-interview-questions-answers.html

http://www.josemariagonzalez.es/

http://blog.hispavirt.com/tag/drs/

http://www.virtuallyghetto.com/2011/07/new-vsphere-5-ha-drs-and-sdrs.html

http://www.yellow-bricks.com/2011/07/12/vsphere-5-0-storage-drs-introduction/

http://www.ideasmultiples.com/imvps/virtualizacion.php

http://centrodeartigos.com/articulos-noticias-consejos/article_126331.html

http://blog.virtualizamos.es/tag/bare-metal/

http://federicocinalli.com/blog/item/119-vsphere-client-vs-vsphere-web-client#.U4Wae_l_uBo

http://federicocinalli.com/blog/item/119-vsphere-client-vs-vsphere-web-client#.U4Wae_l_uBo


106

Reglas Storage DRS:

http://blog.hispavirt.com/2011/08/27/vsphere-5-%E2%80%93-sdrs-%C2%A1drs-para-nuestro-

almacenamiento/

Problema con HA:

http://geekswing.com/geek/vmware-cpu-and-ram-reservations-fixing-insufficient-resources-

to-satisfy-configured-failover-level-for-ha/

Problema FT:

http://www.virtuallyghetto.com/2011/07/how-to-enable-nested-vft-virtual-fault.html

http://blog.hispavirt.com/2011/08/27/vsphere-5-%E2%80%93-sdrs-%C2%A1drs-para-nuestro-almacenamiento/

http://blog.hispavirt.com/2011/08/27/vsphere-5-%E2%80%93-sdrs-%C2%A1drs-para-nuestro-almacenamiento/

http://geekswing.com/geek/vmware-cpu-and-ram-reservations-fixing-insufficient-resources-to-satisfy-configured-failover-level-for-ha/

http://geekswing.com/geek/vmware-cpu-and-ram-reservations-fixing-insufficient-resources-to-satisfy-configured-failover-level-for-ha/

http://www.virtuallyghetto.com/2011/07/how-to-enable-nested-vft-virtual-fault.html

Implementacion de una infraestructura en VMware 5.5

Technology

Transcript of Implementacion de una infraestructura en VMware 5.5