7·2 | Credenciales SSO

En ocasiones me he encontrado al actualizar vCenter a la versión 5.1 que no he podido acceder a vCenter con las credenciales del dominio, esto se debe a que Sign-On and Discovery no ha podido descubrir el directorio activo durante la instalación de SSO, seguramente por un problema de resolución DNS, conectividad o otros.

Para solucionar esto tendremos que crear un Identity Source nuevo y vincular SSO con el directorio activo de la organización, para ello seguiremos los siguientes pasos.


1 Accederemos a vCenter mediante vSphere Web Client con las credenciales de admin@system-domain y la contraseña especificada el la instalación.

Imagen. Validacion mediante vSphere Web Client

Nota. si no lo tenemos instalado, deberemos instalar el plug-in de vSphere Web client desde esta misma pantalla

2 En el panel izquierdo ir a Sign-On and Discovery > Configuration

 

Imagen. Configuracion de Sign-On and Discovery

3 Añadir un nuevo Identity Source para vincular Single Sign-On con el directorio activo

 

Imagen. Configuración del Identity Source.

 

4 Una vez creado marcarlo como Identity Source (dominio) por defecto.

 

 

Imagen. Dominios por defecto

 

5 Desplazar el dominio al principio de la lista de consulta o donde proceda.

 

 

Imagen. Vista de orden de dominios por defecto.

 

6 Ahora ya es posible agregar permisos en vCenter a usuarios del dominio desde Add Permissions.

 

 

 

 



7 | Errores comunes

7·1 | CPU/MMU Virtualization

En ocasiones, al realizar una conversión P2V de una maquina Windows 2000 nos podemos encontrar que el procesador se mantiene al 100% de uso. Existen varias posibles soluciones para este problema.

Lo primera a probar seria la siguiente, no siempre me ha funcionado:

Molificación de HAL de procesador:


1 Ejecutar un snapshot de la VM afectada.

2 Acceder al SO de la VM y modificar el HAL a uniprocesador, desde el Administrador de dispositivos > Equipo > cambiar controlador a uniprocesador.

3 Detener la VM y dejarle una única vCPU.

4 Iniciar la VM y reiniciarla si asi lo pidiese

5 Comprobar si el rendimiento es óptimo (no al 100%), debería serlo. De ser así:

6 Iniciar la VM e instalar el controlador multiprocesador. Parar la VM, asignarle una segunda vCPU, iniciar la VM y comprobar rendimiento. Si es óptimo, repetir el proceso añadiendo hasta 4 vCPUs o 8 dependiendo de la versión de Windows 2000 y licencia de VMware, se recomienda no usar mas de 4 vCPUs en sistemas operativos obsoletos.

Me he encontrado frecuentemente con este problema al convertir maquinas físicas Windows 2000 con HAL uniprocesador. Aun así puede funcionar en algunos casos con equipos físicos con HAL multiprocesador.

También seria aconsejable en la VM convertida marcar en el administrador de dispositivos "Ver dispositivos ocultos" y eliminar todos los heredados del servidor físico (los que están en gris claro), como agentes de HP, tarjetas de red, etc.. (snapshot por delante).


Molificación del CPU/MMU Virtualization:

El segundo procedimiento que en ocasiones me ha funcionado es modificar las instrucciones de acceso a memoria de la CPU, por defecto este valor estará en automático pero no siempre el elegido es el mas adecuado.

Imagen. Molificación del CPU/MMU Virtualization.

1·1·4 | NPIV - N Port ID

La tecnología NPIV también conocida como Node Port ID Virtualization, es una capacidad especifica de SAN FC, y es una extensión del estándar de canal de fibra existente, permite la creación de WWNs virtuales en las VMs, de este modo es posible el uso de zonas como si de servidores físicos se trataran.

El uso de NPIV mejora sustancialmente la seguridad, evitando accesos indeseados cuando presentamos una LUN a los servidores ESXi, por ejemplo, para crear un disco RDM. Es posible crear una zona SAN para acceso a una única VM, ante el uso de vMotion no hay requisitos especiales para asegurar que el resto de nodos tienen acceso a la LUN, la VM tiene acceso y es suficiente para que el host de destino herede la capacidad de acceso a el.
 
Para habilitar NPIV en el entorno se requieren varios componentes, los switches SAN deben soportar NPIV, cualquier Switch Brocade con un Fabric OS v5.1.0 o posterior soportara NPIV.

Las HBAs deben soportar NPIV, actualmente cualquier HBA Emulex o QLogic lo soporta.

El uso de NPIV es aplicable únicamente a discos RDM.

vMotion esta soportado para VMs con varios RDMs NPIV, eso si, los punteros a los RDMs deben estar en el mismo datastore.

Storage vMotion no esta soportado con RDMs NPIV.

NPIV es completamente transparente para los arrays de disco, por lo que los sistemas de almacenamiento en sí no requieren una configuración especial.

Bien, vamos a la práctica, conectaremos una LUN a una VM mediante NPIV, dispongo de una cabina HP MSA 2000 G2, HBAs QLogic ISP2532 de 8GB en los hosts y Switches SAN Brocade.

 Preparación del entorno:

Se asume que ya están correctamente configuradas las zonas entre las HBAs de los hosts ESXi y las controladoras de la MSA. De no ser asi, crearlas y comprobar la conectividad.

También se asume que están creados los Hosts con los WWNs pertinentes para las HBAs de los ESXis, de no ser así, también hay que crearlos.

1 En primer lugar crearemos una LUN, en adelante (NPIV_HB) y la presentaremos a los hosts ESXi con el mismo LUN ID para todas las HBAs.

2 En los switches SAN comprobaremos que NPIV este habilitado en los puertos correspondientes, en este caso los que van a las HBAs de los hosts ESXi 5.1
 

 

Imagen. Vista del estado de NPIV en los puertos pertinentes mediante GUI.

Realizamos una conexion SSH al Switch SAN y con el comando portcfgshow seguido del numero de puerto revisamos el estado del mismo.

portcfgshow 0

Comprobar que NPIV Capability este en ON


De no estar habilitado NPIV en los switchs los habilitaremos para cada puerto con el comando

portcfgnpivport --enable seguido del puerto.

Imagen. Activación de NPIV en cada puerto

3 A continuación identificaremos las HBAs en los hosts ESXi, para ello accederemos mediante una sesión SSH hasta la ruta:

/proc/scsi #

con ls identificaremos el folder de las HBAs, en este caso qla2xxx hace referencia a una QLogic ISP2532, una vez dentro nuevamente con ls nos dará las instancias de las HBAs.

Imagen. instancias de las HBA Qlogic del host

Con el comando cat seguido del identificador nos proporcionara la información necesaria sobre la HBA, entre otras cosas si soporta NPIV (NPIV Supported : Yes). y con una revisión rápida para cada instancia comprobaremos el tipo y el estado de conectividad de cada (puerto).
 

Imagen. información sobre una de las instancias de la HBA.

4 A continuación mediante el cliente vSpere pararemos la VM a configurar NPIV y la editaremos.

En la pestaña Options Desmarcaremos la opción Temporarily Disable NPIV for this virtual machine y marcaremos que genere un WWNN y un WWPN nuevos y aceptaremos para que aplique y los genere.

Imagen. Vista de Fibre Channel virtual WWNs.

3 Volvemos a acceder a la configuración de la VM y aparecerán los WWNN/WWPNs

Imagen: WWN y WWPN generados
 

Para comprobar que realmente ha creado y linkado el VPort, abrir una sesión SSH al servidor ESXi y ejecutar el siguiente comando, esxcli storage core adapter list, en la descripción aparecerán con () Virtual y en Link State el estado del mismo.

 

 

 

Imagen. Lista de adaptadores

 

4 Ahora le conectaremos el disco RDM mediante la LUN previamente presentada, especificaremos que use una controladora SCSI separado para la VM (en este caso SCSI (1:0)).

Imagen. Usar un canal SCSi separado para el RDM.

La VM se mantiene apagada en todo momento.

Configuración de zonas para NPIV:

La configuración de zonas para el uso de NPIV tiene una serie de requisitos a tener en cuenta:
-Las HBAs fisicas deben tener acceso a todas las LUNs a las que accedan las VMs.

-El modo de presentación del host (HBA) debe ser igual para cualquier VM que tenga habilitado NPIV a traves de esta HBA.

-Las LUNs deben presentarse con el mismo LUN ID tanto a las HBAs físicas como virtuales.

-El LUN Masking de la cabina debe incluir tanto WWNs fisicos como WWNs virtuales.

Bien, vamos a la configuración de las zonas:

1 Creamos un Alias para la VM NPIVTest

Imagen. Alias nuevo

2 Agregamos el WWPN y el WWNN generado por vCenter para la VM.

 

Imagen. WWPN de la VM

 

Imagen. Vista del Alias creado


3 Crear una zona y agregar el Alias de la VM (NPIVTest) y la cabina de almacenamiento.

 

Imagen. Zona nueva.

 

Imagen. Miembros de la zona.

4 Agregar la zona creada a la configuración de zona e Inicializarla

Imagen. Miembros de configuracion de zona.

Configuración en cabina:


Esta parte varia en cada marca y modelo de cabina de almacenamiento, ire incluyendo la configuración para cada cabina en que lo vaya implementando, por ahora vamos con la HP MSA P2000 G2.

 

1 Acceder a la cabina de almacenamiento, en el apartado de hosts se autodescubrira un nuevo Host con el WWPN generado (vPort ID) en la VM, renombrarlo adecuadamente, en este caso (NPIVTest). De no aparecer se tendrá que agregar el host manualmente.

 

 

 

Imagen. Agregar host (NPIVTest) con el World Wide Port Name WWPN generado en la VM.

2 Ir a la LUN presentada a la VM y presentársela a el nuevo host creado (NPIVTest), asegurarse que el LUN ID es el mismo que se utilizo para presentarla a las HBAs.

 

Imagen. Presentar la LUN perteneciente al RDM al host (NPIVTest).
 

Nota. Es muy importante que el LUN ID sea el mismo para los dos hosts.

 

 

Imagen. LUN presentado a las HBAs físicas y el WWPN de la VM.

Iniciaremos la VM (NPIVTest) y ya lo tenemos configurado.
 

 

1·1·3 | VMDK Thin/Thick

A la hora de crear un disco virtual VMDK deberemos escoger su tipo de formato, tenemos tres opciones posibles, Thin Provisioning, Thick Provisioning eager zeroed y Thick provisioning lazy zeroed.

Veamos en que consisten los tres tipos de formato:

Thin Provisioning: Genera el disco VMDK sin reserva de espacio, este crecerá conforme la VM lo necesite. Este espacio se asigna y aumenta a voluntad a través del controlador VMFS en función de la demanda del sistema operativo de la VM. Esta opción es útil cuando requerimos discos de capacidad superior a la disponible en el almacenamiento. Hay que tener en cuenta que el uso de discos Thin ha de ser muy controlado, no olvidemos que estamos engañando a la VM, puede pasar que dispongamos de 30GB. le asignemos 60GB y esta los use realmente. Con Thin Provisioning, los bloques del disco VMDK no se asignan en el almacenamiento físico hasta que se escriben durante la actividad normal del sistema operativo guest.

Thick Provisioning (Eager zeroed): Genera el disco VMDK reservando todo el espacio especificado escribiendo ceros en todos los bloques. El aprovisionamiento del disco es mas lento pero en cambio el rendimiento es superior que Lazy zeroed (menor latencia de disco).

Thick Provisioning (Lazy zeroed): Genera el disco VMDK reservando todo el espacio especificado pero sin escribir ceros en los bloques. El aprovisionamiento es mas rápido pero el rendimiento de uso es inferior a Eager zeroed (mayor latencia de disco).

Es posible convertir un disco VMDK, para ello se deberá realizar una migración de la VM que tiene el disco asignado con Storage vMotion a otro datastore, el asistente permitirá el cambio de formato. 

 

Imagen. Se puede ver como se han asignado 3 discos VMDK, uno en Thick Provisioning (Pesado) de 20GB. y dos en Thin Provisioninig (Ligeros) de 40GB y 80GB. un total de 140GB. de los cuales se usan 80GB de un datastore que en realidad solo tiene 100GB. Fuente: VMware Datasheets

1·1·2 | Discos VMDK / RDM

Existen dos tipos de discos a utilizar en una VM, aunque el rendimiento es sumamente parecido en ambos hay varios factores a tener en cuenta para la elección, entre ellas la cabina de almacenamiento que dispongamos, si vamos a utilizar sus herramientas de gestión, replicación, snapshots, etc..

Lo recomendado en la mayoría de los casos es utilizar discos VMDK, estos ofrecen una mayor agilidad a la hora de realizar backups y recuperación ya sea con vDP o software de terceros como Veeam Backup, ofrecen una mayor movilidad y agilidad de los datos en caso de un Disaster Recovery, redimensión del espacio sin gestión en cabina. En general se reduce la administración en operaciones comunes como una clonación, un snapshot, etc.

Bien, en algunos casos no es posible el uso de discos VMDK y deberemos usar discos RDM, los mas comunes son:

-Necesidad del uso de NPIV (NPort ID Virtualization) en una VM 1·2 | NPIV

-Configuracion de un Cluster de Microsoft.

-Necesitemos ejecutar operaciones sobre el disco directamente en cabina.

-El disco posea volumenes de datos muy grandes.
 
-Conversion P2V, en algunos casos es posible presentar una LUN no VMFS y conectarla como disco RDM sin necesidad de migracion a VMDK.

-Ejecutar comandos SCSI desde la VM que afecten directamente a la LUN.
 

1·1 | Conceptos vSphere

En este apartado intentare explicar los conceptos mas comunes de VMware vSphere 5, tales como Maquina Virtual, Snapshots, vMotion, HA, etc..

Todo a nivel teórico, en los apartados de Buenas practicas, instalación y otros que irán apareciendo explicare procedimientos mas prácticos y configuraciones a realizar.

8·3 | HP EVA

Configurando Round Robin

Aplica a ESXi 5.0 / 5.1

Es practica recomendada por HP para sus cabinas EVA el uso de la política de Multipath PSP Round Robin, por defecto al instalar un servidor ESXi configura la política MRU, es decir, el trafico siempre va por el ultimo camino utilizado a no ser que este se vea interruptido de forma fortuita (fallo de tarjeta, switch, cableado..), en ese caso cambiara a el próximo camino disponible.

Esto puede generar alertas en la EVA, especialmente en las P6300 de cambios excesivos en numero de la controladora propietaria de las LUNs presentadas a los hosts.

Para evitar esto se modificara el modo de Path de los vDisks (LUNs) en la EVA y se configurara Round Robin como PSP por defecto en los hosts.

Definiendo el Path en los vDisks conseguiremos que el trafico siempre vaya a través de la misma controladora y solo cambie de propietario en el caso de fallo y modificando el Multipath a Round Robin conseguiremos que el trafico cambie de camino cada X numero de IOPS que también configuraremos. Si a esto sumamos unas alertas bien configuradas en los hosts comprobaremos el correcto funcionamiento de todos los caminos.

Nota. Personalmente he aplicado este procedimiento con cabinas EVA4100, 4400 y P6300 con resultados óptimos, aunque he leido que es practica recomendada para todas las EVA con dos controladoras Activa-Activa no lo he podido comprobar con otros modelos.

1 Modificación en vDisks

El procedimiento es el siguiente (Desde Command View EVA):

Acceder a las opcioned de presentacion a los hosts y modificar el Prefered Path en los Vdisks, ha de ser uno de los siguientes:


-Path A-Failover/failback
-Path B-Failover/failback

Nota. Si hay mas de una LUN a modo de datastore hay que intentar repartir el trafico entre las dos controladoras.

Nota. El uso de la política PSP Round Robin ignorando la preferencia de ruta óptima puedeser beneficioso cuando es necesario aumentar el ancho de banda de los puertos de las controladoras para dar cabida a una carga de trabajo de escritura intensiva.

2 Molificación de la política PSP de los datastores.

Desde el cliente vSphere conectaremos a el host o vCenter y abriremos las propiedades del datastore a modificar.

Comprobaremos cual es el controlador que usa, (por defecto VMW_SATP_ALUA) ya que mas adelante sera al que le aplicaremos la politica por defecto.

3 Configuración de Round Robin como política PSP por defecto (ESXi 5 - 5.1).

Hemos modificado manualmente (desde el cliente vSphere) los datastores ya conectados, pero si creamos uno nuevo este aparecerá con la politica PSP MRU, ahora cambiaremos este comportamiento para que la politica por defecto sea Round Robin.

Se ha de conectar mediante vCLI, Putty o similar a el host a modificar y lanzar el siguiente comando:

Nota. Recordar que para acceder por SSH a los hosts hay que iniciar los servicios de SSH y Shell.

esxcli storage nmp satp set -s VMW_SATP_ALUA -P VMW_PSP_RR

Para comprobar que la configuración ha sido efectiva lanzar el siguiente comando:

esxcli storage nmp satp list

Reiniciar el host (pasar a modo mantenimiento si fuese necesario)

3 Modificar número de IOPS

Por defecto, al configurar Round Robin, la configuración de IOPS especificada para el cambio de camino es de 1000 para cada dispositivo que accede. Segun las recomendaciones de HP para las cabinas EVA en entornos vSphere 4.x y 5.x este valor ha de ser 1. A continuación lo modificaremos para todos los dispositivos que acceden a las LUNs.

Lo primero es extraer un listado de dispositivos con el comando:

esxcli storage nmp device list | grep naa.600

Lo recomendable es pegar el resultado en Notepad++ y preparar los comandos a ejecutar editando los identificadores de la siguiente manera.

esxcli storage nmp psp roundrobin deviceconfig set -d naa.600143801259c2fb00004000011d0000 --iops 1 --type iops

Con esto queda configurado el uso de RR.

8·1 | MSA P2000 G3 VAAIs

VAAI (vStorage API for Array Integration)

VAAI es una de las Storages Application Programming Interface (API), que se pueden establecer en vSphere, permiten liberar la carga de hardware, los hosts ESXi realizan ciertas operaciones más rápido y consumen menos recursos del servidor. Si tu dispositivo de almacenamiento lo soporta, es buena practica aplicar el plug-in en vSphere.

HP MSA P2000 G3 y despliegue de VAAI.

HP introdujo el soporte para HP MSA VAAI en la P2000 partir de la versión del firmware T230 y esta es la forma de implementarlo:

Requisitos previos

1. La HP P2000 G3 MSA debe disponer de un firmware en las controladoras de al menos la versión TS230P006 o posterior.

2. El Appliance VM (vMA) no es compatible.

3. Es necesario disponer de PUTTY o vCLI para conectarse por linea de comandos.

4. Update Manager para vSphere 5.xo posterior instalado.

Pasos generales

Este es el resumen a groso modo de los pasos necesarios para implementar el plugin VAAI:

1.Importa el plug-in VAAI en vCenter, (via vUM)

2.Instala la VAAI plug-in en el host vSphere (vía vUM)

3.Verifica el estado del plug-in

Pasos detallados

1 Importar el VAAI plug-in en el servidor vCenter (Se asume que tenemos Update Manager instalado)

1. Validarse en vCenter con privilegios de Administrador

2. Importar el Plug-in desde Update Manager > Patch Repository > Import Patches

3. Selecciona el Bundle VAAI Offline e importalo.

4. Crea un Baseline nuevo del tipo Host Extension

5. En la ventana de extensiones selecciona el plug-in HP P2000 VAAI.

2 Instalación del plug-in en el host

1. Haz clic en el Datacenter y ves a Update Manager

2. Haz un Attach del baseline creado previamente.

3. Para garantizar que el contenido del parche y las extensiones se sincronizan, haz clic en el Datacenter que tiene los servidores ESX / ESXi que quieres realizar el Stage. Luego, en el panel izquierdo, haz clic en el Datacenter y selecciona Buscar actualizaciones. Cuando lo pida, asegúrate de que los parches y extensiones están seleccionados y, a continuación, haz clic en Escanear.

4. Haz clic en Stage para abrir el Asistente.

5. Selecciona los hosts de destino de VMware para la extensión que vas a instalar y, a continuación, haz clic en Siguiente y finalizar.

Completa la instalación:

1. Haz clic en Remediation para abrir el Asistente.

2. Selecciona el host de destino de VMware que quieres reparar y, a continuación, haz clic en Siguiente.

3. Asegúrate de que la extensión VAAI está activada y, a continuación, haz clic en Siguiente.

4. Llena la información relacionada y a continuación, haz clic en Siguiente y Finalizar.

¿Cómo puedo saber si VAAI está habilitado?

Para determinar si VAAI se habilita mediante el cliente vSphere:

1. En el panel de inventario del cliente vSphere, selecciona el host a comprobar.

2. Haz clic en la pestaña Configuración, y haz clic enConfiguración avanzada en Software.

3. Asegúrate de que estas opciones se establece en 1 (habilitado):

DataMover.HardwareAcceleratedMove

DataMover.HardwareAcceleratedInit

VMFS3.HardwareAcceleratedLocking

¿Qué necesito saber acerca de el Soporte de hardware de aceleración?

Si vas a Host> Configuración> Almacenamiento, se puede ver el estado de la aceleración de hardware en el en el lado derecho del panel de la derecha.

Para cada dispositivo de almacenamiento y datastore, el cliente vSphere muestra el estado hardware accelerator en la columna de la aceleración de hardware de la vista de los dispositivos y la vista de Datastores.

Los valores de estado son Unknow, Supported, y Not Supported. El valor inicial es Unknow. El estado cambia a Suported si se ha completado con exito las operaciones básicas de OffLoad. Si la operación OffLoad no funciona, el estado cambia a Not Supported

Para determinar si tu dispositivo de almacenamiento es compatible con VAAI, prueba la Full Copy VAAI:

1. Utiliza el cliente vSphere, haz un Browse datastore y localiza un disco virtual (VMDK) de al menos 4 MB. que no esté en uso.

2. Copia el disco virtual en un nuevo archivo.

3. Comprueba el estado de la aceleración de hardware, debe aparecer si es compatible o no.

Nota: las primitivas VAAI también se pueden probar mediante la creación de una VM con al menos un nuevo disco virtual, o la clonando una VM.

8 | Buenas Prácticas

Buenas prácticas

A menudo al visitar un cliente y revisar por primera vez un entorno virtual y de almacenamiento me encuentro con instalaciones standard, es decir, practicamente con los valores por defecto, ya sea por desconocimiento o por seguir la regla de oro de "si así funciona no lo toques", es cierto que así ya funciona pero podría mejorarse considerablemente su rendimiento y disponibilidad.

Por ejemplo te encuentras, BIOS mal configuradas en los servidores, networking mal configurado para el tipo de NIC del servidor, como es el caso de los servidores Blades que requieren una configuración especifica, políticas de Multipath incorrectas que desaprovechan seriamente las posibilidades de tener mas de una HBA o NICs designadas para iSCSI, almacenamiento configurado por defecto, caches, LUNs con paths mal definidos, VAAIs sin configurar o no implementadas, etc..

Esto se puede remediar tomando como norma en la instalación la consulta de documentos de buenas prácticas del fabricante del almacenamiento, servidores y VMware, o los foros y blogs de usuarios que con herramientas como esxtop, IOMeter, VeeamONE o otros han experimentado con la configuración hasta conseguir la mas óptima.

En este apartado intentare publicar las buenas prácticas a implementar en algunos entornos, algunas las he podido comprobar y otras no.

9·2 | vCenter Data Protection

¿Que es Data Protection?

Con la llegada de vSphere 5.1 desaparece VMware Data Recovery y entra en juego vCenter Data Protection, VDP utiliza la base de EMC Avamar para deduplicar a nivel de bloque y continua utilizando la API VADP (vSphere API for Data Protection) y la tecnología de (Changed Blocks Tracking) CBT, no necesita agentes, cambia la administración, ya de entrada la gestión se realiza desde vSphere Web Client y no desde el cliente vSphere como vDR, proporciona recuperación granular a el usuario final aunque aun no lo he probado.

Ubicación de los Backups

vCenter Data Protection precisa de un Datastore para desplegar el Appliance y los discos VMDK que utilizara para albergar los backups.

Ya no es posible utilizar shares, y con ello desaparecen los dichosos errores e Integrity Checks interminables de Shares sobre discos USB (los que los utilizaban).

Cada uno designara el Datastore que crea conveniente, personalmente prefiero designar un disco (Raid0, asumiendo el riesgo que ello implica) o dos (Raid1, si el presupuesto lo permite) de la cabina y crear una LUN especifica para el Datastore de Backup.

Hay que tener en cuenta a la hora de escoger un disco dedicado en NRAID o RAID0 que ahora no es posible separar el Appliance de el destino de copias, el Appliance va junto los discos del mismo, es decir que en caso de perdida del disco físico no solo se perderán los bakups almacenados, también se perderá el Appliance.

Dependiendo de la cabina y las políticas respecto a el almacenamiento de cada empresa se designara el espacio que convenga. Este espacio sera de 800GB, 1.6GB o 3.02GB. dependiendo de la cantidad de VMs a copiar y el tamaño de sus discos. Se instalara la versión del Appliance dependiendo del tamaño escogido, las versiones son las de 500Gb. 1TB o 2TB. respectivamente.

Hay que tener en cuenta en la elección que Data Protection deduplica, existe una tabla en la documentación de VMware que ayudara en la elección. (aunque creo que no son demasiado fiables).

Vamos a la práctica:

Requisitos:

-Agregar el usuario a utilizar como Administrator de vCenter (Datacenter)

-Desplegar el OVF, OVA desde el cliente Web vSphere

-Crear los registros DNS y DNS inversos en el servidor DNS, comprobar la correcta resolución con nslookup.

Importante!. También han de estar creados los registros DNS y PTR de los servidores ESXi, de lo contrario no podrá hacer Attach de los discos y los backups fallaran con el error:

E10055:failed to attach disk


-Ha de estar NTP configurado correctamente tanto en vCenter como en los hosts ESXi.

-Servidor vCenter 5.1

-Incluir el puerto 902 y 9443 en la regla de acceso de VMware en firewall de Windows.

-Instalación de VMware Client Integration Plug-in 5.1.0


Despliegue del Appliance:


Una vez descargado de VMware el appliance adecuado al storage designado para backup, 0,5TB, 1 TB o 4TB. se despliega desde el cliente vSphere Web Client. En este caso desplegaremos el Appliance de 1 TB. que instalaremos sobre un Datastore creado específicamente para Backup.

Iniciamos sesión en vCenter mediante vSphere Web Client con un usuario con privilegios de administración.

Imagen. Inicio de sesión mediante vSphere Web Client.

Nota. Es requisito tener instalado el VMware Client Integration Plug-in 5.1.0, de no ser así lo instalaremos desde esta misma pantalla.

Desde la vista de VMs and Templates despegaremos el template OVA.

 

Imagen. Deploy OVF Template...

Imagen. Ubicación del OVA

Imagen. Descripción.

 

Imagen. Aceptar el acuerdo.

Especificar el nombre para el Appliance y el Datacenter para el despliegue.

 

Imagen. selección de nombre y Datacenter

Seleccionar el host, vApp o RP para el despliegue.

 

Imagen. Selección de recursos para el despliegue.

Seleccionar el Datastore, recordar que para el Appliance de 1TB, deberá ser al menos de 1.6 TB. Escoger el formato de disco, Thin, Thik Lazy Zeroed o Thik Eager Zeroed, en este caso utilizare Thik Eager Zeroed, prefiero reservar todo el espacio necesario y que escriba ceros en todos los bloques, el proceso de aprovisionamiento sera mas lento pero ganare en rendimiento de uso.

Imagen. Selección de el formato de los discos y Datastore para su ubicación.

Selecciona el networking de destino.

Imagen. Selección del Networking.
 
Especificar la configuración de red para el Appliance.

 

Imagen. Configuración de red.
 
Nota. Es sumamente importante que en los servidores DNS especificados estén los registros DNS y DNS inversos de el Appliance y correctamente replicados. Realizar pruebas con pings y nslookup set=type=ptr para comprobar que la resolución sea correcta para vCenter, vSphere Data Protection y los hosts ESXi, de lo contrario los backups no serán satisfactorios.
 
Finalizar el asistente y esperar, paciencia, tiene que generar los discos en Thik Zeroed (en este caso) y tardara.

Con esto hemos terminado el despliegue del producto, vamos a la configuración.



Configuración del Appliance:
Una vez desplegado el Appliance lo iniciaremos desde vCenter y abriremos la consola del mismo. En ella nos especificara la URL para su configuración.

https://<ip address of VDP appliance>:8543/vdp-configure/

Imagen. Consola de vDP y ruta URL.

Accedemos vía web a la URL especificada y aparecera la pantalla de login. Nos validamos con el usuario root y contraseña por defecto changeme

Imagen. validación en vSphere Data Protection.

Comienza la configuración

Especificar la configuración de red, recordar la importancia de los registros DNS y PTR, el nombre de host ha de ser igual MAY-MIN que el registro DNS.

Imagen. Configuración de red.

Especificar la zona horaria.

Imagen. Zona horaria.

Especificar las credenciales para el Appliance segun los criterios que marca.

Imagen. Credenciales

Registrar el Appliance en vCenter Server, aun con los registros DNS correctamente configurados me he encontrado problemas para resolver el nombre del servidor SSO y vCenter, de ser asi utilizar las IPs.

El formato de usuario ha de ser SERVIDOR-DOMINIO\Usuario, aun si utilizamos validación local en el servidor vCenter.

Realizar un Test de conexión antes de continuar.

Imagen. Registro de vDP en vCenter Server

Finalizar el asistente de configuración y reiniciar el Appliance desde vCenter (Restart Guest). El proceso de reinicio incluye un Integrity Check de los discos, dependiendo del tamaño de estos puede alargarse en el tiempo, en esta caso ha tardado unos 40 minutos en reiniciar. Paciencia.

 

 

Imagen. Finalización y reinicio.


Revisión Post-Instalación:

Bien, si todo ha ido bien tras el reinicio al acceder al Appliance via Web por segunda vez.
 
https://<ip address of VDP appliance>:8543/vdp-configure/

ya no debería aparecer el configurador, si es así es que no se han guardado correctamente los cambios y se deberá volver a ejecutar.
 
Nos validamos y comprobamos el estado de los servicios en la pestaña Status.

A partir de ahora desde el gestor web de vDP podremos reconfigurar la red, el registro con otro vCenter (perderemos las tareas y los objetos), la zona horaria, podremos volver a un estado anterior del Appliance y actualizarlo mediante las nuevas isos que vayan saliendo.
 
Para configurar los backups iniciaremos sesión en vCenter mediante vSphere Web Client y clicaremos Connect sobre vSphere Data Protection. Mas adelante creare una entrada con la configuración óptima, cuando lo tenga rodado y vea la capacidad de deduplicación y rendimiento de los backups.
 
Errores encontrados:
 
Hay un error típico y conocido que muy probablemente os encontréis:

Execution Error: E10055:Failed to attach disk.

Es un error que afecta a las VMs con sistema operativo Windows Server 2008 y sus VSS, para solucionarlo deberéis parar las VMs con este OS, eliminarlas del inventario y editar su archivo VMX con Notepad++ o similar, deberéis modificar el valor disk.EnableUUID que por defecto esta en TRUE y cambiarlo a FALSE.
Esta modificación, a mi entender, viene a ser lo mismo que parar el servicio de proveedor de instantaneas de VMware, por lo tanto existe la posibilidad de inconsistencia de datos, siempre configurar el schedule de las copias en horas fuera de producción.

Además este error se puede dar en VMs con cualquier sistema operativo si no hay una correcta resolución de nombres de los servidores ESXi por parte de vCenter, recordar la insistencia con los registros DNS y PTR, vSphere 5.1 es muy susceptible con esto.