Upgrade a vCenter Server 5.0

Una serie de articulos detallando el proceso de Upgrade a vCenter Server 5.0

Upgrade a ESXi 5.0

Una serie de articulos detallando el proceso de Upgrade a ESXi 5.0

Instalación de ESXi 5.0

Una serie de articulos detallando el proceso de Instalación de ESXi 5.0

Configuración iSCSI en vSphere 5.0

Una serie de articulos dedicados a la configuración de iSCSI en vSphere 5.0

Reconocido como vExpert 2011

Reconocido como vExpert 2011

VMware View 4.5

Una serie de articulos dedicados a View 4.5 y todas sus nuevas funcionalidades.

VMware View Transfer Server 4.5

Una serie de articulos dedicados a View Transfer Server y sus caracteristicas.

VMware View Composer 2.5

Una serie de articulos dedicados a View Composer y sus caracteristicas.

Cluster MSCS Across Boxes en vSphere 4.1

Serie de articulos detallando el proceso de creación y configuración de un cluster MSCS en configuración Across Boxes en vSphere 4.1

Mostrando entradas con la etiqueta Hyper-V. Mostrar todas las entradas
Mostrando entradas con la etiqueta Hyper-V. Mostrar todas las entradas

domingo, 8 de enero de 2012

Impacto de la virtualización en la estrategia de Respaldo y Disaster Recovery



Hasta hace no muchos años, antes de que la virtualización entrara fuertemente en el Datacenter de las compañias, respaldar la información critica podia llegar a ser un desafio.  Aun más, el proceso de restauración podia llegar a ser una pesadilla en muchos casos, y muchas veces este proceso no podia ser completado exitosamente.

En este punto debemos separar además el termino "Restauración" de "Recuperación".  Si bien en muchos casos podemos llegar a restaurar los archivos requeridos, hay mucho camino aun por recorrer para poder llevar a cabo una Recuperación exitosa del servicio o aplicación requerida

En un ambiente fisico tradicional, los fabricantes de soluciones de respaldo tradicionales muchas veces se conformaban con el hecho de extraer los datos desde los respaldos y llevarlos a un almacenamiento accesible para su uso, lo cual claramente no es suficiente si consideramos que el proceso no estara completo si la aplicación que requiere el dato restaurado no ha podido volver a estar operativa.

Por otro lado, las soluciones de respaldo estaban pensadas principalmente para poder respaldar y restaurar datos.  Con el uso de agentes especializados, los fabricantes sumaron soporte para el respaldo y restauración de aplicaciones y servicios como Bases de Datos, Servidores de correo, etc.  Estos agentes, si bien solucionaban esa necesidad puntual, aumentaban drasticamente el costo de la solución de respaldo, asi como también su complejidad.

Aun más, en un ambiente fisico existe un desafio aun mayor...  ¿Qué sucede si el servidor ha fallado completamente y es necesario recuperarlo desde cero?

Una alternativa es reinstalar el sistema operativo y las aplicaciones/servicios, con la correspondiente configuración, para luego restaurar los datos almacenados en los respaldos...  Pero esto toma demasiado tiempo no?  De hecho una solución asi en muchos casos es inaceptable para servidores de misión critica, debido a que podria tardar horas en el mejor de los casos.

Para enfrentar este desafió, la mayoria de las soluciones de respaldo cuentan con capacidades de restauración "Bare Metal", que permiten una restauración desde cero, pero este tipo de soluciones suelen ser poco confiables, debido a que dependen mucho del hardware de reemplazo, donde un pequeño cambio puede provocar que las restauraciones fallen.

Y el desafio final en ambientes fisicos, es que el proceso de recuperación rara vez involucra a un unico servidor.  Por ejemplo, ante la falla del Storage que soporta la aplicación (por ejemplo en una configuración en Clúster), o cuando el Datacenter completo sufre una caida, el proceso de restauración involucrará varias capas (tiers) de servidores, lo cual muchas veces debe ser realizado en un orden especifico para asegurar que el proceso sea exitoso.

Todos estos desafios que enfrenta una infraestructura fisica tradicional, hacen que poder contar con una estrategia de Recuperación ante Desastres y de Continuidad de Negocios sea extremadamente dificil.  Ni hablar de procedimientos para probar los respaldos, proceso que podria durar por siempre....

La llegada de la virtualización.
Con la aparición de la virtualización y su explosiva adopción, especialmente con VMware, todos los paradigmas de gestión de un Datacenter sufieron un cambio profundo, especialmente los procedimientos relacionados a Disaster Recovery y Bussines Continuity.

Las antiguas soluciones de respaldo, asi como los procedimientos de recuperación ante desastres, si bien aun pueden ser utilizados en los ambientes virtualizados, estan lejos de ser eficientes y debieran ser reemplazados por soluciones y procedimientos acorde, que puedan aprovechar todas los beneficios que la virtualización nos entrega.

Si bien la virtualización nos ayuda a enfrentar de mejor manera los desafios antes mencionados, esta es solo parte de la solución.  La otra parte son las soluciones de Respaldo y Disaster Recovery que nos ofrecen los principales actores de la virtualización (VMware, Microsoft y Citrix), asi como las soluciones especializadas de terceros (Veeam, Quest, Symantec, CA, etc.).

Con las soluciones de respaldo y Disaster Recovery diseñadas para ambientes virtuales, cada servidor (máquina virtual) puede ser protegido completamente en un unico proceso de respaldo, aprovechando uno de los pilares de la virtualización, que no es otro que la ENCAPSULACIÓN de la MV en un conjunto de archivos.

Luego de realizar un respaldo full, al comunicarse directamente con el hypervisor, las soluciones de respaldo pueden realizar respaldos parciales (incrementales) almacenando solo los cambios o bloques modificados de la MV respecto al ultimo respaldo.  Adicionalmente las soluciones de respaldo actuales utilizan metodos avanzados de compresión y deduplicación, lo que permite un uso más eficiente de los recursos de almacenamiento y del ancho de banda en la red de respaldos.

Para que los respaldos sean consistentes, las soluciones de respaldo para ambientes virtualizados están basadas principalmente en los Snapshots de las máquinas virtuales, lo cual permite mantener multiples puntos de recuperación o versiones de respaldos.

Ahora lo escencial... ¿En que mejoran los procesos de recuperación?
Con la virtualización y las soluciones de respaldo y Diaster Recovery pensadas para ambientes virtuales, es posible recuperar una máquina virtual completa desde un respaldo, sin preocuparse de los problemas de compatibilidad de hardware que presentaban las soluciones Bare Metal tradicionales, porque como deben recordar, las máquinas virtuales son 100% independientes del hardware físico que las hospedan!

Esto nos permite restaurar una  o más máquinas virtuales en otro host o incluso en otro Site si es necesario, siendo de gran ayuda al momento de aplicar los procedimientos de Disaster Recovery

Mejor aun, si la situación asi lo requiere, y dependiendo de la solución de respaldo utilizada, es posible recuperar archivos especificos desde el respaldo de la MV, no siendo necesaria la restauración de la MV completa.  Del mismo modo, y dependiendo de la "inteligencia" de la solución de respaldo elegida, es posible realizar restauraciones granulares a nivel de aplicación, como puede ser un correo en un buzon Exchange, o un registro en una BD SQL/Oracle.

Algunos productos de Respaldo y Disaster Recovery tienen la habilitad de realizar una recuperación "in-place", que permite acelerar el proceso de recuperación montando la máquina virtual respaldada desde el mismo repositorio de respaldos, lo cual nos permite tener nuestros servicios operativos en forma casi instantanea en algunos casos, aun cuando tengan una performance degradada.  Una vez el servicio se encuentra restaurado, el administrador TI puede utilizar funcionalidades como Storage vMotion de vSphere para mover "en caliente" la MV al dispositivo de almacenamiento principal, sin ninguna interrupción, y normalizando la performance de dicho servicio.

Si requerimos soluciones de Disaster Recovery y Bussines Continuity, como el uso de Sites de Contingencia, apalancando la Virtualización y las tecnologias de respaldo modernas es posible pensar en sitios replicados y procedimientos de Failover y Failback de maneras que serían mucho más complejas de implementar en los ambientes fisicos tradicionales.

Con soluciones como VMware Site Recovery Manager, Veeam Backup and Replication y Quest vRanger, es posible contar con sitios replicados en ubicaciones remotas, donde ya no es requisito fundamental la compatibilidad entre los dispositivos de almacenamiento (SAN) existentes en el sitio principal y en el de contingencia.
De hecho, si asi lo requieren, el sitio de contingencia podria incluso funcionar sin un almacenamiento centralizado (SAN o NAS), utilizando nada más que almacenamiento local en cada host.  Claramente no es la situación ideal, pero cuando el presupuesto es escaso, es una solución bastante valida.

Un ultimo punto, pero no menos importante, es la posibilidad de probar los respaldos para asegurarnos que estos sean recuperables en caso que lo necesitemos.  Con la virtualización y las soluciones de respaldo y Disaster Recovery, es más sencillo generar ambientes aislados o sandbox virtuales donde poder comprobar que los respaldos sean recuperables y funcionales, sin afectar a los servicios productivos, y en tiempos mucho más acotados que en ambientes físicos tradicionales.

Como pueden ver, al virtualizar un Datacenter se deben introducir cambios bastante profundos en la manera en que se gestiona la plataforma y en los procedimientos que llevan a cabo los administradores de TI en diversas situaciones, en especial en lo relacionado a la Recuperación ante Desastres y Continuidad de Negocios.

Espero que les haya resultado interesante y que les sea de utilidad.

miércoles, 14 de diciembre de 2011

Regalo de navidad de Veeam! Licencias NFR de Veeam Backup and Replication 6


Como un regalo especial de fin de año, Veeam nuevamente esta entregando licencias gratuitas, esta vez del recientemente lanzado Veeam Backup and Replication v6.

Estas licencias están disponibles para VMware vExperts, VMware Certified Professionals y VMware Certified Instructors.  Del mismo modo, y considerando que ahora se cuenta con soporte para Hyper-V, estas licencias NFR pueden ser obtenidas tambien por Microsoft Certified Professionals y Microsoft MVPs.


Solo se requiere registrarse para recibir las licencias Veeam para propositos de Evaluación, Demostración y Entrenamiento.

Para quienes estén interesados este es el link:
http://www.veeam.com/news/holiday-gift-from-veeam-free-veeam-backup-and-replication-v6-licenses-for-your-lab155.html

miércoles, 30 de noviembre de 2011

Veeam Backup and Replication 6 - Finalmente disponible


Finalmente, a partir de ayer se encuentra disponible Veeam Backup & Replication v6, el cual es posible descargar en modo de evaluación para que puedan probar todas sus nuevas funcionalidades.

En un post anterior detallé las novedades de esta nueva versión de esta premiada solución de Veeam.

Entre las novedades podemos indicar:

  • Una nueva arquitectura distribuida
  • Soporte para Hyper-V
  • Mejoras importantes en la funcionalidad de Replicación con Failback incluido.
  • Nueva funcionalidad Quick Migration
Una descripción más detallada la pueden encontrar en el sitio de Veeam y en el articulo de What's New publicado anteriormente en este Blog.

martes, 11 de octubre de 2011

Nuevo sponsor del Blog - Veeam!


Hola a todos!

Solo una pequeña nota para contarles de que a partir de esta semana, Veeam Software se ha transformado en el primer sponsor de este humilde Blog.

Ya he publicado algunos artículos sobre los productos de Veeam, y espero seguirles informando de las novedades que vayan apareciendo acerca de sus soluciones.

Gracias a todos por seguir este Blog, y a Veeam por el apoyo.

miércoles, 28 de septiembre de 2011

Veeam Backup and Replication 6 - What's New!



En algunas semanas más Veeam Software hará el lanzamiento de la nueva versión de su producto Veeam Backup & Replication 6.

Una de las novedades que Veeam ha revelado, es el soporte para Hyper-V, además de el soporte para vSphere porsupuesto =)  Lo interesante es que desde una unica consola se podrán realizar respaldos y restauraciones, tanto de hosts ESX/ESXi, como de hosts Hyper-V, permitiendo una administración completamente centralizada.

No obstante lo anterior, SureBackup (validacion automatica de respaldos) e Instant VM Recovery (Ejecutar una VM desde el almacen de respaldos), no estarán disponibles aún para Hyper-V en este nuevo lanzamiento.  Todas las otras nuevas funcionalidades estarán disponibles tanto para Hyper-V como para vSphere.

A continuación un resumen de las nuevas caracteristicas de Veeam Backup 6, las cuales fueron anunciadas en el VMworld 2011 en Las Vegas.  La presentación la pueden descargar desde el siguiente link, además, para los asistentes al VMworld, está disponible la grabación de la sesión (SPO3981) en el sitio www.vmworld.com.

Arquitectura:
Ahora podemos observar una arquitectura distribuida, pudiendo separar los roles.



Antes:

  • Servidor de Backup

Ahora:

  • Servidor de Backup: Administración y balanceo de carga
  • Servidor Proxy: Obtener datos del origen
  • Servidor Repositorio: Escribir los datos en el repositorio.


Esta arquitectura provee mejoras significativas en la replicacion para ESXi, asi como tambien permite realizar respaldos en almacenamiento remoto, sobre la WAN, pensado especialmente para infraestructuras Cloud.

Además, esta nueva arquitectura permite un deploy y mantención automatica, asi como un balanceo de carga inteligente.

Se incluye además un balanceo de carga inteligente, dentro y entre los jobs.



Finalmente, esta arquitectura simplifica el crecimiento de la plataforma en el tiempo:

  • Proxies ligeros
  • Deploy y mantención automatica
  • Streamlines ROBO (remote office/branch office) e implementaciones a gran escala.


Replicación
La funcionalidad de replicacion tiene además una serie de nuevas funcionalidades, que le permiten competir bastante bien con lo que es Site Recovery Manager 5.


  • Re-IP on failover
  • Real failback
  • Seed from backup
  • Replica mapping
  • Preserve thin disks
  • Replicate to cluster
  • Traffic throttling


Quick Migration

  • Se incluye un asistente para migrar una o más MVs:
    • Desde un host a otro
    • Desde un datastore a otro
    • Ambos
  • Quick Migration es Instant VM Recovery aware.
  • Utiliza vMotion y Storage vMotion si es que están disponibles.
  • En caso contrario, utiliza la tecnologia de replicación de Veeam:
    • Entre hosts standalone
    • A un nuevo storage
    • etc.
  • Tambien utiliza, cuando es posible, la nueva tecnologia Veeam SmartSwitch
    • Elimina el downtime
    • Pausa el origen -> Copia el estado de la memoria -> Reanudar la MV en el destino.


Otras mejoras

  • Restauración de archivos en 1 Click
  • Restauración de MV en 1 Click


Para conseguir mayor información, pueden registrarse a la serie de Webinar que Veeam estará ofreciendo para detallar todas las nuevas funcionalidades del producto.

sábado, 23 de enero de 2010

Guest NLB sobre Hyper-V R2

En consideración a la fuerte penetración que ha tenido la Virtualización en los Datacenter en la actualidad, comienza a ser frecuente la necesidad de levantar ambientes productivos en alta disponibilidad, ya sea utilizando Guest Failover Cluster o Guest Network Load Balancing (NLB).  En este articulo detallaremos el procedimiento para configurar NLB con maquinas virtuales sobre Hyper-V R2.

Requerimientos.

En nuestro escenario, se creará un NLB con 2 nodos sobre maquinas virtuales ejecutando Windows Server 2008 R2.  El NLB se configurará en modo Unicast, por lo que necesitaremos un mínimo de 2 tarjetas de red por cada nodo.

Cada nodo contará con una tarjeta privada, la cual será utilizada para administrar el servidor, y una tarjeta publica, utilizada para configurar el NLB.

Cada tarjeta requerirá una IP, y adicionalmente se requerirá una IP para el NLB (IP virtual).  En nuestro caso se reservaron 5 IP's para el laboratorio.  Adicionalmente se debe registrar el nombre del NLB en los servidores DNS, en nuestro caso labnlb.dominio.com.  Las direcciones IPs de cada nodo deben ir en el mismo segmento de red.

Aunque suena obvio, los nodos a utilizarse en el NLB deben ir conectados a distintos Switch físicos.  En el caso de maquinas virtuales, se recomienda que cada servidor Hyper-V este conectado a un Switch distinto, de manera de evitar posibles conflictos en la red.  En nuestro caso cada nodo se ejecuta sobre un servidor Hyper-V R2 separado, por lo que estos últimos están conectados a Switches distintos.

Procedimiento.

1.- Una vez tenemos los dos nodos con Windows Server 2008 R2 instalado, procedemos con la instalación de la Feature Network Load Balancing.  Esto lo instalamos directamente desde la consola Server Manager:



2. Finalizado el asistente de instalación tendremos el siguiente mensaje.  Se debe instalar esta Feature en cada nodo que formará parte del NLB.



3.  A continuación procedemos a realizar la configuración de red de ambos nodos.  La configuración de la tarjeta privada difiere de la tarjeta publica.  A continuación la configuración que debe tener la tarjeta privada en ambos nodos:







4.  A continuación la configuración de la tarjeta de red publica (utilizada para el NLB).  Especial cuidado se debe tener en la configuración de velocidad de conexión de esta tarjeta.  Todos los nodos deben tener la misma configuración y a la vez la puerta correspondiente en el Switch debe utilizar la misma configuración.  Si esto no se realiza correctamente pueden producirse problemas de comunicación en el NLB.  En nuestro caso las tarjetas y las puertas del Switch están forzadas a 1Gbps.








5.  Si la maquina virtual es Windows 2008, antes de configurar el NLB se debe instalar el hotfix KB953828  y reiniciar.   En caso de que se trate de Windows 2008 R2, este paso no es necesario.

6.  En uno de los nodos ingresamos a la configuración de Network Load Balancing.





7.  Hacemos click derecho sobre "Network Load Balancing Clusters" y ejecutamos el Wizard para crear un nuevo cluster.

8.  A continuación debemos digitar el nombre del primer nodo que formará parte del NLB y presionamos en "Connect".  Esto nos mostrará las interfaces de red disponibles en el nodo para la configuración del NLB.  Seleccionamos la tarjeta publica y hacemos click en Next.





9.   Luego debemos ingresar una IP para el cluster NLB.  Esta IP fue la que mencionamos anteriormente y que registramos en el DNS como labnlb.dominio.com



10.  A continuación ingresamos el FQDN que utilizará el cluster NLB y que registramos anteriormente en los DNS.  En este punto además debemos seleccionar el modo de operacion del NLB que utilizaremos.  En nuestro caso seleccionamos Unicast.



11.-  A continuación podemos configurar las reglas de puertos.  En nuestro caso dejamos todo por defecto.



12.  Damos click en finalizar con lo cual se termina la configuración del primer nodo del cluster NLB.



13.  En este punto, si intentamos hacer ping a la tarjeta publica o a la IP del NLB no tendremos respuesta.  Para solucionar esto debemos realizar un cambio en la configuración de la maquina virtual en la consola de Hyper-V R2.

Apagamos el servidor y nos dirigimos a la consola de administración de Hyper-V.  Abrimos la configuración de la maquina virtual, y en la interfaz de red utilizada por el NLB seleccionamos la opción "Enable spoofing of MAC Address".



Guardamos los cambios y encendemos el nodo.  Con esto, si intentamos realizar un ping a la IP de la tarjeta publica o a la IP del NLB, esta responderán correctamente.

14.  A continuación procedemos a agregar el segundo nodo al cluster NLB.  Esto podemos realizarlo desde cualquiera de los 2 nodos.

Accedemos a la consola "Network Load Balancing Manager", si estamos en el primer nodo se conectará de inmediato al cluster NLB creado en los puntos anteriores.  Si nos encontramos en el segundo nodo, primero debemos conectarnos al NLB.

Una vez conectados al NLB, hacemos click derecho sobre este y seleccionamos la opción "Add Host to Cluster" con lo cual se ejecutará el Wizard correspondiente.




15.  Digitamos el nombre del segundo nodo y presionamos "Connect".  Luego seleccionamos la tarjeta publica, al igual que lo hicimos con el primer nodo.




16. Continuamos con el resto del Wizard dejando las opciones por defecto, con lo cual finaliza la configuración del NBL quedando de la siguiente forma:




17.  Al igual que con el primer nodo, debemos apagar el servidor y en la consola de administración de Hyper-V se debe habilitar la opción "Enable spoofing of MAC Address" en la configuración de la maquina virtual.

18.  Con esto finalizamos la configuración del NLB, dejandolo totalmente funcional para el rol que le asignemos.  En nuestro caso será utilizado para hospedar los servidores Web Front End de una granja Sharepoint.

Informacion Adicional.

En versiones anteriores de Windows Server, como Windows Server 2003, la configuración del NLB es un poco más compleja.  Los pasos a grandes rasgos son los siguientes:


  • Configuración de las tarjetas de red de ambos nodos de la misma forma en que se señala en este procedimiento.
  • Ejecutamos el Wizard de configuración de NLB en uno de los nodos hasta que obtenemos la MAC Address del NLB, y cancelamos el Wizard.
  • Configuramos manualmente la MAC Address en la tarjeta publica de dicho nodo (Windows 2008 R2 lo hace automaticamente).
  • Ejecutamos nuevamente el Wizard y finalizamos la configuración del NLB en el primer nodo.
  • En el segundo nodo se configura manualmente la MAC Address en la tarjeta publica.
  • En la configuración del NLB se ejecuta el Wizard para agregar un nuevo nodo al NLB, y se siguen las instrucciones.
  • Con estos pasos el NLB debiera quedar operativo en versiones anteriores a Windows Server 2008 R2.

Este procedimiento es valido también para ambientes físicos.  Si tienen alguna duda respecto a los pasos aquí mencionados, no duden en consultar.

viernes, 11 de diciembre de 2009

Top Five Hyper-V Best Practices













Excelente articulo con las 5 mejores practicas para la implementación de Hyper-V, con enfoque en las caracteristicas de la version R2 de Windows Server 2008:
  • Network configuration
  • Setting the correct iGroup and LUN protocol type
  • Virtual machine disk alignment
  • Using cluster shared volumes (CSVs)
  • Getting the most from NetApp storage software and tools
El articulo completo se puede acceder desde AQUI.

miércoles, 2 de diciembre de 2009

Hyper-V R2 - Alta disponibilidad con Host Cluster






En este pequeño articulo quisiera compartir mi experiencia en la implementación de Hyper-V R2 para sistemas en ambiente de producción.  En ningún caso se pretende conseguir un manual de instalación infalible, sino una guía que los oriente para conseguir implementar un ambiente de virtualización robusto y que ofrezca alta disponibilidad.  En su momento me fue difícil encontrar documentación adecuada para conseguir este objetivo y con este articulo espero poder aportar a quienes estén dando sus primeros pasos en esta tecnología.

En el marco de la implementación de una plataforma SharePoint 2007, y tomando en consideración la nueva política corporativa de consolidación y virtualización de servidores, comencé a evaluar las distintas alternativas con las que trabajamos.

Por un lado tenia VMWare ESX 3.5 y por otro Hyper-V.  Todos los puntos se los llevaba VMWare por lejos, pero estaba el tema costos, lo cual es un tema importante cuando se trabaja con VMWare.  Por otro lado Hyper-V hasta ese momento no contaba con buenas características de Alta Disponibilidad, comparable con un Cluster HA de VMWare y VMotion, que entregara protección ante fallas de Hardware en el Host.

En eso estaba cuando fue lanzado Windows Server 2008 R2, con un Hyper-V totalmente mejorado, incluyendo nuevas características como LiveMigration y Cluster Shared Volume (CSV), que lo acerca bastante a las funcionalidades que VMWare incluye desde hace unos años. 


Características de Hyper-V
Hyper-V soporta una arquitectura de alta disponibilidad en Failover Clustering y en NLB.  En este articulo nos centraremos solo en Failover Clustering.

Hyper-V soporta Failover Cluster tanto a nivel de Host (host cluster), como a nivel de Guest (guest cluster)
En el caso de Host Cluster, Microsoft soporta de 2 a 16 nodos con Hyper-v funcionando conjuntamente de modo de poder mover las maquinas virtuales de un nodo a otro según se requiera:
-       Caída no programada de un Host Hyper-V, ya sea por una falla de Hardware o Software.  En este caso la maquina virtual será movida automáticamente a otro nodo del cluster.
-       Migración manual o automática por mantenimiento programado de algún Host, o simplemente para distribuir carga entre los host (Aquí hecho de menos una funcionalidad como DRS de VMWare).

Respecto al Guest Cluster, se refiere a un Failover Cluster en el que los diferentes nodos que lo componen corresponden a maquinas virtuales sobre Hyper-V.  Para lograr esto se requiere conexión iSCSI, Fiber Channel no esta soportado para funcionalidades de Guest Failover Cluster.
Luego nos encontramos con Cluster Shared Volume, que nos permite compartir un único volumen o LUN, entre 2 o más host Hyper-V, pudiendo ser accedidos por todos los nodos del Host Cluster simultáneamente.

Finalmente, nos encontramos con Live Migration, funcionalidad comparable con VMotion de VMWare, que nos permite hacer migraciones “en caliente” de una maquina virtual, de un host a otro, sin provocar perdida de servicio o datos en la maquina virtual (Excepto cuando se produce una falla en el Host que provoque su apagado o reinicio, en cuyo caso la migración de la maquina virtual se realiza con la funcionalidad Quick Migration).

Mas detalles de las diferencias entre Live Migration y Quick Migration y sobre su funcionamiento lo pueden encontrar en el siguiente sitio:



Requisitos
Una vez tomada la decisión de trabajar con Hyper-V comenzó la tarea de preparar la plataforma para cumplir con los requisitos para su implementación.  A continuación un resumen de los requisitos mínimos para implementar un Host Cluster con Hyper-V

-       2 o más servidores para Hyper-V (Hasta 16 nodos son soportados), con una arquitectura lo más similar posible (idealmente idéntica), para evitar conflictos en los servidores virtuales al momento de una migración de un Host a otro.  Hyper-V requiere procesadores con arquitectura 64Bits.  En mi caso son 2 servidores Dell idénticos, con 4 sockets Intel Xeon Quadcore y 64GB en RAM c/u.
-       2 o más interfaces de red en cada host.  Idealmente se debe contar con una interfaz dedicada para Live Migration, una para la comunicación de las maquinas virtuales, una para la administración del servidor y una para comunicación iSCSI (si aplica).  En mi caso omito la interfaz para iSCSI ya que utilizaré conexión por Fiber Channel.
-       Acceso a un dispositivo de almacenamiento compartido, como una SAN, ya sea a través de iSCSI o Fiber Channel (Windows 2008 no soporta Failover Cluster usando el bus SCSI tradicional).  En mi caso una SAN EMC conectada por Fiber Channel.


Pasos de Instalación

Pre-Requisitos.

Se procede a instalar Windows Server 2008 R2 en todos los nodos del cluster.  Puede utilizarse la versión Enterprise o Datacenter, tanto en una instalación Full como en Server Core.  Todos los nodos deben tener la misma versión.

Se deben aplicar todos los parches de seguridad disponibles para el Sistema Operativo.

Se procede a configurar las interfaces de red para cada nodo.  En mi caso se configura las siguientes interfaces:

-       Interfaz de Administración
-       Interfaz para Maquinas Virtuales
-       Interfaz para Live Migration

Todos los servidores en el cluster deben estar en el mismo dominio Active Directory.

Se conectan los nodos al almacenamiento compartido (En mi caso una SAN EMC), y se crean las LUNs requeridas para el Cluster.  Cada LUN debe ser asignada a todos los nodos del Cluster, para que puedan acceder a su contenido.

Si en cada servidor se utiliza más de una conexión al almacenamiento compartido, para efectos de redundancia, se debe configurar el servidor para el manejo de múltiples Paths. La solución Multipath debe estar basado en Microsoft Multipath I/O (MPIO). En mi caso utilizo una herramienta del fabricante de la SAN, EMC PowerPath, para cumplir esta función.

A nivel de sistema operativo, las LUNs asociadas deben configurarse como Basic Disks, no Dynamics Disks.
Se recomienda formatear las particiones en formato NTFS.  Para el disco Witness esto es obligatorio.
Para las particiones se pueden utilizar Master Boot Record (MBR) o tabla de particiones GUID (GPT)

Se instala el rol de Hyper-V en todos los nodos del Cluster en la sección de roles de Server Manager:





Se instala la Feature Failover Cluster en todos los nodos del cluster, en la sección Features de Server Manager:



  


Configuración.


1.     1. Validación de la configuración.

Antes de que se pueda crear el cluster, se debe validar la configuración.  Se deben ingresar todos los servidores que formarán parte del cluster.





Se debe asegurar que se ejecuten todos los test disponibles, ya que la solución solo está soportada cuando se aprueban estos tests. 
Si la validación presenta Warnings, se puede continuar de igual forma con la instalación.  Si por el contrario la validación presenta errores, estos deben ser solucionados antes de proceder:






2.     2. Creación de Cluster.

Una vez que se haya pasado la validación, hacer click en la opción “Create a Cluster”.  Primero se deben seleccionar ambos nodos:







Luego se debe especificar el nombre virtual del cluster.  Este nombre debe haber sido registrado previamente en el servidor DNS.








Una vez confirmados los datos ingresados, se completa la creación del Cluster







Se puede ver la información del cluster abajo:






3.     3. Configuración de Red.

Una vez creado el cluster, se debe seleccionar una interfaz de red para ser usada como Live Migration:






También se debe configurar la interfaz a ser utilizada para las maquinas virtuales:






4.     4. Configuración de Almacenamiento.

Una vez creado el Cluster y configurada la red, se debe configurar los discos a ser utilizados en el cluster.  En mi caso se agregaron 2 LUNs para maquinas virtuales y una adicional a ser utilizada como disco Witness. 

Opcionalmente se puede cambiar la configuración del Quorum.  En mi caso dejé la configuración por defecto para la arquitectura que implementé, es decir “Node and Disk Majority”.

Para ver más detalles de las distintas configuraciones de Quorum, pueden ingresar en la siguiente pagina:


Para modificar la configuración del Quorum se elige la opción “Configure Cluster Quorum Settings” de las opciones del cluster:






A continuación se elige el tipo de configuración de Quorom a utilizar:






Luego se selecciona el disco a ser utilizado por el Quorum:






Se dejan las demás opciones por defecto y se finaliza la configuración, la cual queda de la siguiente forma:






La columna “Current Owner” muestra el nodo que esta utilizando actualmente el disco.  Para que todos los nodos puedan tener acceso simultaneo a los discos, se debe habilitar la función Cluster Shared Volumes.  Aun así, cada disco tendrá un Owner, pero podrá ser accedido por el resto de los nodos.

En la sección Cluster Shared Volumes se debe habilitar esta función:







Se deben agregar los discos que deberán ser accedidos por todos los nodos del Cluster.  La configuración quedaría de la siguiente forma:







Se pueden agregar mas discos a los Cluster Shared Volumes a medida que se van asignando más LUNs al cluster.






5.    5.  Validación de Cluster.

Finalmente, se recomienda ejecutar una validación del cluster para detectar posibles problemas de configuración.   Se deben ejecutar todos los tests disponibles.  Se debe tener especial cuidado de no ejecutar esta validación en un ambiente en producción, debido a que parte de los tests incluyen la desconexión y reconexión de los discos del Cluster, provocando así la caída de las maquinas virtuales que se ejecutan sobre el.

Pruebas del Cluster.


1.     1. Creación de maquina virtual de pruebas.

Para probar el cluster y sus funciones de Alta Disponibilidad, se debe crear una Maquina Virtual normal en uno de los nodos del Cluster.

La maquina virtual debe utilizar los discos del Cluster para almacenar los discos virtuales y su configuración.  La función Cluster Shared Volume crea un acceso directo en el disco C de cada nodo llamado “Cluster Storage”, el cual contiene cada uno de los volúmenes compartidos del Cluster.

En esta configuración los volúmenes no son visibles directamente a través de la interfaz de usuario del servidor.  Solo se puede acceder a ellos a través del acceso directo mencionado anteriormente.








2.     2. Configurando alta disponibilidad para la maquina virtual.

Una vez creada la maquina virtual, se debe configurar para las funciones de alta disponibilidad de Hyper-V.

Se debe entrar a la sección “Service and Applications” y seleccionar la opción “Configure a Service or Application”, donde aparecerá el siguiente asistente:








Aquí se debe seleccionar la opción “Virtual Machine”, luego de lo cual se debe seleccionar la maquina virtual a configurar:





Seleccionamos la maquina virtual creada y dejamos el resto de las opciones por defecto.

Una vez configurada la alta disponibilidad  para la maquina virtual, aparecerá de la siguiente forma.







En este punto podemos encender la maquina virtual desde esta ventana, o desde la consola de administración de Hyper-V.

Para evitar los pasos de habilitación de alta disponibilidad para cada maquina virtual que se crea, se puede utilizar Microsoft System Center Virtual Machine Manager para administrar las maquinas virtuales, el cual configura la alta disponibilidad en forma automática.


3.    3.  Moviendo una maquina virtual entre nodos.

Una vez configurada la alta disponibilidad, se pueden realizar pruebas de migración utilizando Live Migration.  En la consola Failover Cluster Manager, en la sección “Services and Applications”, se selecciona la maquina que se quiere migrar y se selecciona la opción “Live Migrate virtual machine to another node”, indicando el nodo al cual se quiere migrar:





Durante la migración la consola se verá de la siguiente forma:







Este proceso dura solo unos segundos, y depende de cuanta memoria tiene asignada la maquina virtual.

Para eventos de caídas de uno de los nodos, otro de los nodos del cluster tomará el control de las maquinas virtuales afectadas.  Se guardará el estado de estas maquinas y se moverán de nodo, donde se iniciarán nuevamente con un mínimo de downtime.


Conclusiones
En este punto ya tenemos habilitado un Cluster Hyper-V, con funcionalidades de alta disponibilidad utilizando Live Migration y Cluster Shared Volume.

La plataforma puede comenzar a ser utilizada creando nuevas maquinas virtuales para los servicios que se requieran, los cuales a la vez pueden formar un Guest Cluster o un NLB si así se requiere.

Para la administración de Hyper-V se pueden apoyar en System Center Virtual Machine Manager y en Data Proteccion Manager para efectos de respaldos. 

Al implementar una solución de virtualización se deben tomar todos los resguardos necesarios para asegurar la continuidad operacional, considerando que existirán múltiples servicios ejecutándose en un único servidor físico.

En próximos artículos hablaré de virtualización de SQL Server 2005 en alta disponibilidad y la implementación de SharePoint 2007 sobre Hyper-V utilizando Network Load Balancing (NLB).


Lecturas recomendadas