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

lunes, 21 de diciembre de 2009

Reporting Service 2005 integrado con MOSS 2007, sobre Windows 2008 R2

Si bien la instalación de Reporting Service 2005 integrado con MOSS 2007 es relativamente sencilla, su implementación sobre sistema operativo Windows Server 2008 puede tener algunas complicaciones que a más de uno les dará un buen dolor de cabeza.

El escenario en el que me tocó trabajar es el siguiente:
Granja Sharepoint de 3 servidores (1 servidor de aplicaciones y 2 Web Front-End) y un Cluster SQL Server 2005, todo ejecutandose sobre Windows Server 2008 R2.

Para la instalación de Reporting Service en un ambiente distribuido, se deben usar cuentas de dominio para su configuración, en vez de la utilización de la cuenta Network Service u otra similar, esto sobre Windows 2003 no implica problema alguno, sin embargo en Windows 2008 es un poco más complejo.

A continuación detallaré los pasos para instalar y configurar Reporting Service 2005 integrado con Sharepoint 2007, sobre sistema operativo Windows 2008 (valido también para la versión R2):

Instalación pre-requisitos:

Antes de instalar SSRS 2005 se deben instalar algunos roles y características de Windows:
Rol de Web Sever (IIS) con las siguientes características:
- Herramientas de Administración
- IIS 6 WMI Compatibility
- IIS 6 Metabase Compatibility
- ASP .Net
- Extensiones ISAPI
- Filtros ISAPI
- Default Document
- Directory Browsing
- HTTP Errors
- HTTP Redirections
- Static Content

Para datos adicionales pueden ingresar en el siguiente link: http://support.microsoft.com/kb/934164

Instalación SQL Server 2005 Reporting Service

Reporting Service se debe instalar sobre los servidores que actuan como Web Front End en la granja Sharepoint.  Se debe instalar solo el rol de Reporting Service:





Se utiliza una cuenta de dominio para ejecutar el servicio, en mi caso use la cuenta moss_apppools:



Esto se instala en cada uno de los Web Front End de la granja Sharepoint.  Luego de esto se debe instalar el ultimo Service Pack disponible para SQL.

Crear sitio para Reporting Services

En cada servidor Web Front-End se debe crear un sitio para Reporting Services y un Application Pool.  El sitio debe apuntar un directorio X (en mi caso C:\RS) utilizando un puerto a elección (en mi caso el 8080).  
En caso de estar instalando sobre Windows Server 2003, el sitio además debe configurarse para no aceptar conexiones anónimas.  Adicionalmente, el sitio debe tener permisos de Script Only en la seccion "Home Directory -> Application Settings" de las propiedades del sitio.





El Application Pool debe ejecutarse utilizando una cuenta de dominio, sin embargo en este punto y como configuración temporal utilizaremos la cuenta Network Service para la creación del Application Pool.  Esto aplica solo en la instalación sobre Windows Server 2008.  Al utilizar Windows Server 2003, el Application Pool se configura directamente para usar una cuenta de dominio.




Adicionalmente, el Application Pool debe configurarse para usar .Net Framework 2.0 y utilizar el Managed Pipeline Mode en Classic.




Adicionalmente, la cuenta utilizada para el servicio Reporting Service debe agregarse al grupo local SQLServer2005ReportingServicesWebServiceUser$SERVIDOR$MSSQLSERVER en cada uno de los servidores para Reporting Services.


Configurar para Reporting Services

Una vez completados los pasos anteriores, estamos en condiciones de configurar Reporting Services.  En cada uno de los servidores para Reporting Service se debe ingresar a "Reporting Service Configuration"



Se debe crear el Report Server Virtual Directory dentro del sitio creado anteriormente en IIS:



Luego se configura Report Manager Virtual Directory (este punto queda deshabilitado una vez que SSRS se integra con Sharepoint):



La seccion Windows Service Identity utiliza la cuenta especificada al instalar Reporting Service en el servidor.  DOMINIO\moss_apppools.  El servicio Report Server realiza la inicialización, encriptación reversible, tareas de mantención de base de datos, etc.  Este servicio se ejecuta en segundo plano y realiza el procesamiento end-to-end para los reportes que se ejecutan en forma programada.


Debido a que el servicio Report Server realiza todas las operaciones de encriptación, debe estar ejecutandose cada vez que se especifique o se utilicen valores encriptados.  Especificar credenciales almacenadas, ejecutar un reporte que utiliza credenciales almacenadas y publicando un reporte al servidor de reportes (la informacion del Data Source esta encriptada), son todas operaciones que requieren el servicio Report server



Luego procedemos a configurar la sección Web Service Identity, utilizando los Virtual Directories creados anteriormente.  Si la cuenta del Application Pool es una cuenta de dominio se generará el siguiente error:



Debido a que en puntos anteriores configuramos el Application Pool con la cuenta Network Service, la configuración pasará sin problemas.


Recordar que esta cuenta será modificada luego manualmente por una cuenta de dominio.  En mi caso se utiliza la misma cuenta del servicio Report Server, DOMINIO\moss_apppools.  El Report server Web Service realiza el procesamiento end-to-end para reportes que se ejecuten on-demand.  Además provee con la interfaz de programación principal para aplicaciones que se integran con un Report Server.





Luego continuamos con la configuración de la Base de Datos, nos conectamos al servidor de Bases de Datos donde alojaremos la data de Reporting Services.  La cuenta de usuario utilizada en el Application Pool debe tener seleccionado el rol RSExecRole en SQL para funcionar apropiadamente:




Una vez conectados procedemos con la creación de la base de datos, la cual se debe crear en modo integrado con Sharepoint.  En este punto le asignamos un nombre a la base de datos:




NOTA: Solo el servidor de reportes se conecta con la base de datos de reportes.  Las instancias Sharepoint que están integradas con un servidor de reportes nunca se conectarán u obtendrán data desde la base de datos de reporte directamente.

Una vez creada la base de datos se debe aplicar la configuración, obteniendo el siguiente resultado:



En este punto ya tenemos configurado Reporting Service e integrado con Sharepoint, sin embargo al intentar ingresar al sitio de Report Server (http://localhost:8080/reportserver) se obtiene el siguiente error:


Esto se produce debido a que el Application Pool está configurado con la cuenta Network Service.  Nos vamos entonces al IIS y configuramos la cuenta de ejecución del Application Pool para utilizar una cuenta de dominio:




Al hacer este cambio, se debe reconfigurar Reporting Service, pero esta vez de forma manual siguiendo los siguientes pasos:
  • Actualizar el archivo RSReportServer.config desde la carpeta SQLRSInstall\Microsoft SQL Server\ MSSQL.X \Reporting Services\ReportServer.  Se debe actualizar la linea WebServiceAccount para utilizar la cuenta de dominio especificada en el Application Pool.
  • Luego se realizan los siguientes cambios en el registro en la siguiente ubicacion (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Setup):   
             -  Las entradas ApplicationPoolConfigured_RM y ApplicationPoolConfigured_RS deben estar configuradas para utilizar el Application Pool creado anteriormente.
             -  Las entradas ReportManagerIdentityConfigured y WebServiceIdentityConfigured deben modificarse para utilizar la cuenta de dominio especificada en el Application Pool.
             -  Si alguna de estas entradas no existe, debe crearse como tipo String
  • Finalmente se reinicia el servidor Reporting Service para que tome los cambios.
La configuración de Reporting Service se verá de la siguiente forma:



Y al ingresar al sitio de Report Server se verá de la siguiente forma:


Con esto el servicio Reporting Service queda funcionando satisfactoriamente.


Instalar Reporting Services Add-In

Una vez que tenemos Reporting Service instalado y configurado, debemos instalar el Add-in de Reporting Service para Sharepoint de la siguiente manera:

-  Via linea de comando se debe ejecutar el instalador con el parametro SKIPCA=1
-  Se ingresa a la siguiente carpeta C:\Users\nombre_usuario\AppData\Local\Temp
-  Se ejecuta el siguiente comando rsCustomAction.exe /i

NOTA: El Reporting Services Add-In se instala en cada Web Front-End y en el servidores que hospeda la Administración Central.




Configuraciones Adicionales Sharepoint

Luego de instalado y configurado SSRS 2005 y el Add-In, se debe configurar Sharepoint para utilizar reporting Services:

-  Se ingresa a la Administración Central, en la seccion Application Management.



-  En la seccion Reporting Service se ingresa a Manage Integration Settings y se ingresa la dirección del sitio de Reporting Service creado anteriormente.  Si se usa NLB, la dirección debe apuntar a un FQDN que apunte a la IP virtual del NLB, en mi caso MOSSNLBDMZ.  
Se debe seleccionar el modo de autenticación "Trusted Account".  Este modo tiene que ser utilizado si Kerberos no está habilitado.


-  En la seccion Grant Database Access se ingresa el nombre del servidor de Reporting Service, luego de lo cual se debe ingresar una cuenta de dominio que pertenezca al grupo Farm Administrator, en mi caso DOMINIO\moss_setup, que es la cuenta con la que se instaló y configuró Sharepoint:







-  Finalmente se ingresa a la seccion Set Server Defaults y se deja todo por defecto para luego aceptar los cambios (estos parametros se pueden personalizar segun lo que se requiera).
-  Estos ultimos 2 puntos se deben repetir por cada servidor de Reporting Services, en caso de que exista más de un Web Front End actuando como servidor de reportes.




Solucion de Problemas

En situaciones donde se trabaje con más de un servidor Front End actuando como servidor de reportes, y utilizando Windows Network Load Balancing (NLB), es posible que se presenten problemas en la integración de Reporting Service.  

Específicamente al tratar de ingresar al sitio ReportServer via web, apuntando al FQDN del NLB (http://fqdnnlb:8080/reportserver) en vez de apuntar directamente a uno de los servidores de reportes, se pueden presentar problemas de autenticación que finalmente redundan en un error 401.1 del IIS.

Para solucionar esta situación, se debe crear una entrada en el registro de windows en cada Front End. Se debe ingresar a regedit y buscar la llave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.  Una vez aquí, se debe crear una nueva entrada DWORD con nombre "DisableLoopbackCheck".  Una vez creada, se debe configurar su valor en 1 y hacer click en OK.

Finalmente se reinician los servidores luego de lo cual el servicio funciona correctamente, permitiendo la conexión utilizando el NLB.


NOTA: En ocasiones será necesario además asociar un SPN con las cuentas utilizadas por el servicio Reporting Service.  Estos SPN se configuran en uno de los Domain Controllers del dominio en el que se implementó la plataforma, con los siguientes comandos:



  • setspn.exe -S http/IIS_computer's_NetBIOS_name DomainName\UserName
  • setspn.exe -S http/IIS_computer's_FQDN DomainName\UserName





Conclusión
Una vez completados todos estos pasos, tendremos un servicio de Reporting Services completamente funcional en nuestras plataformas.

En mi caso he realizado esta configuración tanto en ambientes con Windows 2008 y 2003 con buenos resultados.  Espero que les sea de utilidad.  Si necesitan mayor ayuda no duden en escribir.

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.

jueves, 3 de diciembre de 2009

EMC Sharepoint Archiving



Interesante solución que permite realizar Archiving del contenido sobre Sharepoint Server 2007.

EMC Sharepoint Archiving permite migrar el contenido creado en Sharepoint 2007 al repositorio EMC Documentum, entregando una infraestructura para el control centralizado del contenido Sharepoint.

Esto permite la consolidación del contenido en un repositorio corporativo para efectos de retención, reutilizarlo con otras aplicaciones, etc.  Mejora la performance de ambientes Sharepoint y baja los costos de almacenamiento.

Los documentos archivados pueden seguir estando disponibles a través de accesos directos o links en Sharepoint, permitiendo el acceso transparente a los usuarios a la vez que se controla el aumento del contenido en Sharepoint.

Mayor información la pueden obtener en el sitio de EMC.

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