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.

9·1·1 | Identity Source

A falta de una definición mas detallada diré que el identity Source no es mas que un "vinculo" entre un origen de datos, en este caso un directorio activo, LDAP, NIS o Sam local y SSO.

9 | Instalación

En los siguientes apartados publicare los procedimientos de instalación de componentes de VMware que me vaya encontrando en el día a día. Remarcando las incidencias que me encuentre por el camino.

9·1 | Single Sign-On

VMware vCenter Single Sign-On

Con la nueva versión 5.1 aparece un componente nuevo, vCenter Single Sign-on, es un componente de autenticación centralizada y simplifica la autenticación de los usuarios en las diferentes capas de vCenter.

Con SSO se evita el Linked Mode y es posible configurar múltiples dominios aun sin relación de confianza entre ellos y usuarios locales, de este modo podremos validarnos desde un mismo cliente vSphere en diferentes servidores vCenter con credenciales de diferentes dominios y directorios dependiendo de los permisos de cada instancia. También acepta OpenSource (NIS, LDAP).

Esta pensado para el Cloud y MultiSites como se puede ver en la siguiente imagen.

Imagen. Diagrama de ejemplo SSO Multisite, fuente: VMware Blogs

SSO se instalara por defecto en una Base de Datos local de SQL Express aunque por supuesto se puede crear y especificar una en un SQL Server de la organización.

1·5·3 | Datastore Heartbeating

Datastore Heartbeating

Como ya se ha comentado antes todos los hosts del cluster intercambian heartbeats con los datastores para confirmar que estan activos.

vCenter seleccionara un minimo de dos y un maximo de cinco datastores, a ser posible de diferentes storages, solo podra seleccionar datastores accedidos por al menos dos hosts del cluster intentando maximizar el numero de hosts que tienen acceso a ellos.

Todo esto es configurable de forma manual, tambien se puede modificar el numero de datastores a seleccionar por defecto (entre 2 y 5) con el comando:

das.heartbeatdsperhost

y especificando como valor el numero de datastores.

Imagenes. vCenter da la opcion de seleccionar manualmente los datastores aunque de forma automatica ha seleccionado dos de diferentes storages (SAN/iSCSI y NAS) accedidos por todos los hosts del cluster.