VMware vSphere/iSCSI: Configuracion Multipathing

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.
Una vez creado el vSwitch y los puertos VMkernel, haber habilitado el iniciador iSCSI por Software y haber configurado los iSCSI Targets, proseguimos con la configuración de multipathing para los Datastores VMFS que se encuentran en la SAN iSCSI.

Introducción

Para mantener una conexión constante entre un host ESX/ESXi y su storage, VMware soporta funcionalidades de multipathing. Multipathing es una tecnica que permite utilizar más de una ruta fisica para transferir datos entre el host y un dispositivo de almacenamiento externo.

En caso de una falla de cualquier elemento en una red SAN, ya sea un adaptador de red, un switch o un cable, el host puede cambiar a otra ruta fisica, la cual no utiliza ninguno de los componentes con problemas. Este proceso de cambio de ruta es conocido como Path Failover.

Adicionalmente al Path Failover, Mutipathing provee balanceo de carga, distribuyendo la carga de I/O entre multiples rutas fisicas. El balanceo de carga reduce o remueve potenciales cuellos de botella.

El I/O de una VM puede ser retrasado por hasta 60 segundos mientras se realiza el proceso de Path Failover. Estas demoras le permiten a la SAN estabilizar estabilizar su configuracion despues de los cambios en la topologia. Generalmente estas demoras en el I/O pueden ser más extensas en arreglos activo-pasivos que en arreglos activo-activos. En algunos casos puede ser necesario realizar configuraciones adicionales en las maquinas virtuales para evitar problemas en los servicios producto de estas demoras en el I/O.

Para administrar Multipathing, VMware utiliza una capa especial de VMkernel, la PSA (Pluggable Storage Architecture), que es un framework abierto y modular, que permite coordinar las operaciones simultaneas de multiples plug-ins de multipathing (MPP).
El plug-in de multipathing que ESX/ESXi provee por defecto es el "VMware Native Multipathing Plug-in" o NMP, el cual es un modulo extensible que administra sub-plugins. Hay dos tipo de sub-plugins de NMP:

• Storage Array Type Plug-Ins (SATPs). SATP se preocupa de manejar los Path Failovers para un arreglo de Storage.
• Path Selection Plug-Ins (PSPs). PSP se preocupa de determinar cual ruta fisica es usada para emitir un requerimiento I/O a un dispositivo de Storage.

Los plug-ins SATP y PSP pueden ser provistos por VMware o por software de terceros. Si se requieren funcionalidades adicionales de Multipathing, un software de terceros puede proveer un MPP para ejecutarse como complemento o reemplazo de NMP (Plug-in por defecto de VMware).

NMP asigna un PSP por defecto para cada dispositivo logico basado en el SATP asociado con la ruta fisica para ese dispositivo, sin embargo esta asignacion puede ser sobrescrita. Por defecto VMware NMP soporta los siguientes PSP:

• MRU (Most Recently Used): Selecciona la ruta que el host uso más recientemente para acceder a un dispositivo de storage. Si esta ruta llega a encontrarse no disponible, el host cambia a una ruta alternativa y la continua utilizando mientras ésta se encuentre disponible. MRU es la politica de multipathing por defecto para arreglos activo-pasivo.
• Fija o Fixed: Utiliza la ruta designada como preferida si esta ha sido configurada. De lo contrario utiliza la primera ruta descubierta que se encuentre funcionando correctamente. Si el host no puede usar la ruta preferida, selecciona una ruta alternativa disponible en forma aleatoria. El host vuelve a utilizar la ruta preferida tan pronto como dicha ruta vuelva a encontrarse disponible. Esta politica es la politica por defecto para arreglos activo-activo.
• Round Robin: Utiliza un algoritmo de seleccion de rutas que va rotando a través de todas las rutas activas disponibles, permitiendo balanceo de carga a traves de las rutas.

Configuración de Multipathing para iSCSI

Para configurar el multipathing en nuestros hosts ESX/ESXi, debemos realizar dicha configuración en cada uno de los Datastores asignados a los hosts a traves de iSCSI

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage". Seleccionamos uno de los Datastores de nuestro Storage iSCSI y hacemos click en "Properties"
	A continuación se nos muestra los detalles del Datastore seleccionado. Se hace click sobre el boton "Manage Paths" para continuar.
	En nuestro caso, por defecto VMware seleccionó la politica MRU (Most Recently Used) para acceder a esta Datastore en la SAN iSCSI. Esta politica es seleccionada al tratarse de un arreglo iSCSI del tipo activo-pasivo. En nuestro caso modificaremos la politica para utilizar Round Robin como politica de Multipathing.
	Seleccionamos "Round Robin (VMware)" de la lista de seleccion de Paths y luego presionamos el boton "Change". Luego de unos segundos la configuración quedará de la siguiente forma.
	Finalmente cerramos las propiedades del Datastore haciendo click en Close. Al volver a la lista de Datastores disponibles en la sección "Storage", podemos ver que los Datastores estan utilizando Round Robin como politica de Multipathing, y que ven todos los caminos disponibles.

Al completar estos pasos ya contamos con Datastores VMFS a traves de nuestra red iSCSI, y configurados para usar la politica de Multipathing que nos permita asegurar conectividad continua hacia nuestro storage iSCSI, además de proveer balanceo de carga para las conexiones iSCSI. En los siguientes articulos detallaremos como habilitar Jumbo Frame y otras consideraciones como el uso de CHAP para asegurar las comunicaciones iSCSI.

Read More

VMware vSphere 4.1: VirtualCenter Server Service puede fallar al migrar a 4.1

Se ha publicado el KB 1026688 respecto a posibles problemas luego de una migración a vCenter Server 4.1

Sintomas

• El servicio VirtualCenter Server falla luego de la migración a  vCenter Server 4.1.
• Aparece el siguiente error en los logs vpxd:
  
  Panic: Win32 exception: Access Violation (0xc0000005)
     Read (0) at address 0000000000000098
     rip: 000000014071edcc rsp: 000000000419c700 rbp: 000000000419e160
     rax: 000000000419c7a8 rbx: 0000000000000018 rcx: 0000000000000020
     rdx: 000000000419c798 rdi: 0000000000000000 rsi: 000000000e8667b0
     r8:  000000000419c7a8 r9:  000000000cab1eea r10: 0000000002d27fd0
     r11: 000000000419c750 r12: 0000000007279700 r13: 0000000007279740
     r14: 00000000032edeb0 r15: 0000000000000004
  
• En vCenter Server 4.0, las operaciones como la busqueda en el inventario puede fallar.  El archivo vws.log se trunca con el error "Chuncked stream ended unexpected"  
• En vCenter Server 4.1, vCenter falla inmediatamente despues que se inicia el servicio, y el archivo vpxd-*.log muestra errores como los siguientes:
• ASSERT d:/build/ob/bora-258902/bora/vpx/vpxd/util/vpxdDbLoad.cpp:1059
• ASSERT d:/build/ob/bora-258902/bora/vpx/vpxd/util/vpxdDbLoad.cpp:1066

Solución

Este problema es causado por entradas corruptas sobre las maquinas virtuales en la base de datos de vCenter.

Para evitar toparse con este issue se deben seguir los siguientes pasos:

 

1. Descargar el Script apropiado (Para SQL u Oracle).  Los Scripts están disponibles en la publicación del KB.
2. Descomprimir y ejecutar los scripts en la base de datos de vCenter Server 4.0.
• La consulta SQL debe ser ejecutada utilizando nombres completos de las tablas de base de datos (fully qualified database table names).  Si se tienen multiples instancias de base de datos, puede ser necesario utilizar ademas el nombre de db-instance y de db-owner:
• ..VPX_VM_CONFIG_INFO
3. Si ningún resultado es devuelto por la consulta, se puede continuar con la migración. Si cualquiera de las maquinas virtuales es reportada con datos inconsistentes, se debe remover la maquina virtual del inventario de vCenter y luego registrarla nuevamente.
   
4. Continuar con la migración.

Si se realiza el upgrade a vCenter Server 4.1 y el servidor sigue fallando se deben seguir los siguientes pasos:

1. Realizar un roll-back de vCenter Server a la versión 4.0 y conectarlo a un backup de la base de datos.
2. Ejecutar los scripts descargadps en la base de datos de vCenter Server 4.0. 
3. Averiguar si alguna maquina virtual es reportada con datos inconsistentes.
4. Utilizando el vSphere Client, remover y volver a registrar las maquinas virtuales identificadas como inconsistentes.
5. Intentar nuevamente la migración. 

Para revisar el KB completo y descargar los scripts requeridos pueden dirigirse al siguiente link:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026688

Read More

VMware vSphere/iSCSI: Configuracion Target iSCSI

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.
Una vez creado el vSwitch y los puertos VMkernel, y haber habilitado el iniciador iSCSI por Software, proseguimos con la configuración de los target iSCSI para luego agregar los Datastores VMFS a los hosts.

Configuración de los Targets para el iniciador iSCSI

Se debe configurar las direcciones de descubrimiento de los Targets, de manera que el iniciador iSCSI pueda determinar cuales recursos de Storage se encuentran disponibles en la red.
ESX/ESXi soportan 2 metodos de descubrimiento:

• Dynamic Discovery, también conocido como descubrimiento SendTargets. Cada vez que el iniciador se contacta con un servidor iSCSI especifico, el iniciador envia las solicitudes SendTargets al servidor (Target). El servidor responde indicando una lista de targets disponibles para el iniciador. Los nombres e IP's de los targets aparecen en el tab "Static Discovery". Si se remueve uno de los target estaticos agregados por Dynamic Discovery, el target volverá a agregarse a la lista la proxima vez que se produzca un Rescan, se reinicien las HBA's o el host ESX/ESXi sea reiniciado.
• Static Discovery. El iniciador no tiene que realizar ningún descubrimiendo. El iniciador tiene una lista de targets que puede contactar utilizando las direcciones IP y nombres de targets.

Configuración de Dynamic Discovery iSCSI

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage Adapters". Ingresamos a las propiedades del "iSCSI Software Adapter"
	En la ventana de propiedades nos dirigimos al tab "Dynamic Discovery" y presionamos "Add" para agregar la IP de un servidor iSCSI. Agregamos la IP del Storage iSCSI.
	Basta agregar solo una de las IP's utilizadas por las controladoras iSCSI que pueda tener el Storage (en nuestro caso el Storage cuenta con 2 controladoras con 2 puertas iSCSI cada una). No obstante, algunos Storage más basicos pueden requerir incluir todas las IP utilizadas por las controladoras en el tab "Dynamic Discovery"
	Si nuestro Storage ya se encuentra configurado para ser utilizado por los hosts (Creación de arreglos, LUNs, CHAP, etc.), podremos todos los Targets disponibles en el Tab "Static Discovery". Hacemos Click en "Close"
	A continuación se nos mostrará un mensaje recomendando un Rescan de los adaptadores iSCSI debido al cambio de configuración. Hacemos click en "Yes".
	Esto puede tomar unos minutos.
	Finalmente podemos observar que el iniciador iSCSI tiene visibilidad de las LUNs creadas y asignadas a nuestros hosts. Aqui podemos observar además los caminos disponibles entre el host y el Storage iSCSI.

Creación de Datastores VMFS

Una vez configurado los Targets iSCSI en nuestro iniciador, y luego de asegurarnos de que nuestro host tiene conexión con las distintas LUNs asignadas en el Storage iSCSI, podemos proceder con la creación de los Datastores VMFS.

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage". Hacemos click en "Add Storage" para agregar un nuevo Datastore.
	Seleccionamos el tipo de Storage a utlizar. En nuestro caso seleccionamos "Disk/LUN" que es la opción para Datastores sobre SAN iSCSI y Fiber Channel. Hacemos click en Next para continuar.
	Seleccionamos la LUN que queremos agregar. Hacemos click en Next para continuar.
	Nos muestra un resumen con la información de la LUN que agregaremos. Hacemos click en Next para continuar.
	Seleccionamos un nombre para el Datastore. Hacemos click en Next para continuar.
	Seleccionamos la capacidad a utilizar por el Datastore. Recordar que no se debe crear más de un Datastore por LUN. Seleccionamos además el tamaño de bloques del sistema de archivos. De la opción que elijamos dependerá el tamaño maximo que podrá tener un disco virtual (VMDK). Hacemos click en Next para continuar.
	Nos muestra un resumen del Datastore a crear. Hacemos click en Finish para terminar el proceso.
	Una vez que agregamos todos los Datastores que necesitemos, podremos ver algo como lo que se ve en la imagen, donde tenemos 4 Datastores VMFS disponibles para el uso de nuestra plataforma VMware.

Al completar estos pasos ya contamos con Datastores VMFS a traves de nuestra red iSCSI, y que pueden ser utilizados por nuestra plataforma VMware para crear Virtual Machines, Templates, etc. En los siguientes articulos detallaremos como configurar las politicas de Multipathing, asi como la habilitación de Jumbo Frame.

Read More

VMware vSphere/iSCSI: Habilitación del iniciador iSCSI

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.

Una vez creado el vSwitch y los puertos VMkernel para el trafico iSCSI, debemos proceder con la habilitación del iniciador iSCSI por Software, asi como la asignación de los puertos VMkernel a dicho iniciador.

Configuración de Iniciador iSCSI

Habilitación del Iniciador iSCSI

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage Adapters". Ingresamos a las propiedades del "iSCSI Software Adapter"
	En la ventana de propiedades hacemos click en Configure.
	A continuación hacemos click en "Enabled" para habilitar el iniciador iSCSI.
	Una vez habilitado nos aparecerá la siguiente información en las propiedades del iniciador iSCSI, incluyendo el identificador IQN de éste. Hacemos click en close para terminar.

Asignación de puertos VMkernel al Iniciador iSCSI

Una vez habilitado el iniciador iSCSI por software, es necesario asignar cada uno de los puertos VMkernel (designados como vmk#) a dicho iniciador. De esta forma podemos luego habilitar el uso de Multipathing. Este paso solo es posible realizarlo a traves de la interfaz de comandos.

	Ingresamos a la interfaz de comandos vCLI.
	Ingresamos el siguiente comando por cada uno de los puertos VMkernel a asignar al iniciador iSCSI. esxcli --server ip_fqdn_host swiscsi nic add -n vmk1 -d vmhba37 Aqui se debe indicar la IP del host ESX/ESXi sobre el cual estamos trabajando, asi como el identificador del puerto VMkernel y del iniciador iSCSI (por default vmhba37). Ejecutamos este comando por cada uno de los puertos VMkernel
	Si ejecutamos el siguiente comando podremos ver los puertos VMkernel asignados al iniciador iSCSI: esxcli --server ip_fqdn_host swiscsi nic list -d vmhba37

En el caso de requerir remover un puerto VMkernel desde un iniciador iSCSI, el comando a utilizar es el siguiente:
esxcli --server ip_fqdn_host swiscsi nic remove -n port_name -d vmhba

Al completar estos pasos ya tenemos habilitada nuestra red iSCSI, incluyendo la configuración inicial del iniciador iSCSI por Software. En los siguientes articulos detallaremos como agregar Targets al iniciador iSCSI, asi como la creación de los datastores VMFS creados sobre LUNs iSCSI..

Read More

VMware vSphere/iSCSI: Configuración de la red para iSCSI

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.

Si se usa un adaptador iSCSI por Software o por Hardware, se debe configurar la red para iSCSI antes de poder habilitar y configurar los adaptadores iSCSI. La configuración de red para iSCSI incluye abrir los puertos VMkernel pare ltrafico entre el adaptador iSCSI y la interfaz fisica.

Dependiendo del numero de interfaces fisicas que se utilicen para el trafico iSCSI, la configuración de la red puede variar:

• Si se tiene una unica NIC fisica, se crea un puerto iSCSI sobre un vSwitch conectado a dicha NIC. VMware recomienda que se designe un adaptador de red separado para iSCSI. Este adaptador debe ser de 1Gbit o superior.
• Si se tiene dos o más NIC fisicas, se deben crear puertos iSCSI por cada NIC fisica y usar dichas NICs para el multipathing iSCSI.

Configuración de red iSCSI

A continuación realizamos la creación del vSwitch para iSCSI, asi como los puertos VMkernel para cada una de las interfaces fisicas existentes.

Si se tiene una unica interfaz de red fisica para el trafico iSCSI, los puertos VMkernel que se creen deberan asignarse a esa unica interfaz de red.

Creación del vSwitch para iSCSI

	Ingresamos al host ESX/ESXi o a vCenter utilizando vSphere Client.
	Hacemos click en el tab de Configuración del host y seleccionamos "Network Adapters". Aqui podemos ver las NICs disponibles y que podemos utilizar para la red iSCSI. En nuestro caso utilizaremos las NICs 4, 6, 8 y 10.
	Nos dirimos hacia la sección Networking y vemos los vSwitches existentes. En nuestro caso solo tenemos creado el vSwitch por defecto, el cual contiene el VMkernel Port para la Management Network (ESXi). Hacemos Click en "Add Networking"
	En el asistente seleccionamos VMkernel como el tipo de conexión a crear.
	Seleccionamos las NICs a utilizar en nuestra red iSCSI. En nuestro caso las 4 NICs a ser utilizadas se configurarán en un unico vSwitch con 4 puertos VMkernel. Hacemos click en Next.
	Seleccionamos el nombre del primer puerto VMkernel. En nuestro caso se llamará MD3200i_iSCSI01. Hacemos clien en Next.
	Seleccionamos una IP dentro del segmento de red asignado para la red iSCSI. Ingresamos también la mascara de subred y damos click en next para continuar.
	En caso de no tener configurado un Gateway por defecto aparecerá la siguiente alerta. Debido a que la red iSCSI utilizará un segmento IP no ruteable no requeriremos este paramentro. Hacemos click en "No" para continuar. Presionamos "Finish" para terminar el asistente.
	Se nos creará un vSwitch de la siguiente manera

Creación puertos VMkernel adicionales

	Ingresamos a las propiedades del vSwitch creado donde veremos la siguiente configuración. Hacemos click en "Add" para crear nuevos puertos VMkernel y realizamos el mismo proceso creado anteriormente para crear el primer puerto VMkernel
	Una vez creados todos los puertos VMkernel veremos la configuración de la siguiente manera.

Asignar cada puerto VMkernel a una unica NIC.

	En las propiedades del vSwich seleccionamos uno de los puertos VMkernel creados y hacemos click en "Edit"
	Nos vamos al Tab "NIC Teaming" y seleccionamos la opción "Override vSwitch Failover Order".
	A continuación dejamos solo una de las NICs activas, dejando las otras 3 NIC como adaptadores no utilizados. Este paso es requerido para la configuración iSCSI con Multipathing.
	Al volver a las propiedades del vSwitch podemos ver que el puerto VMkernel tiene una unica NIC activa. Repetimos el proceso para cada uno de los puertos VMkernel, asignandole una unica NIC activa, diferente para cada puerto. Hacemos click en Close para cerrar las propiedades del vSwitch.
	Ahora podemos ver los cuatro puertos VMkernel creados en el vSwitch, junto con las NIC asignadas.

Al completar estos pasos ya tenemos la primera parte de la configuración requerida para habilitar una red iSCSI. En los siguientes articulos detallaremos como habilitar el iniciador iSCSI por software, y como asignar los puertos VMkernel a dicho iniciador.

Read More

VMware vSphere 4.1: Conexión a una SAN iSCSI

En los siguientes articulos detallaremos el proceso de configuración de nuestra plataforma VMware, de manera de poder utilizar una SAN iSCSI como repositorio para los Datastores VMFS. Incluiremos la configuración requerida a nivel de red, iSCSI y multipathing.

Introducción

Es posible utilizar ESX/ESXi en conjunto con una SAN, que es basicamente una red especializada que conecta sistemas computacionales con subsistemas de almacenamiento de alta performance. El uso de una SAN, ya sea iSCSI o de Fiber Channel, provee una consolidacion del almacenamiento, al mismo tiempo que mejora la disponibilidad y facilita la recuperacion ante desastres.

Una SAN iSCSI utiliza una conexión Ethernet entre servidores y un sistema de almacenamiento de alta performance. Los componentes de una SAN incluyen HBAs (host bus adapters) iSCSI o interfaces de red (NICs) en el servidor, switches y routers que transportan el trafico del storage, Storage Processors (SP o controladoras) y sistemas de discos.

Como funcion el iniciador iSCSI por software?

Una SAN iSCSI utiliza una arquitectura cliente servidor, donde el cliente llamado iniciador iSCSI opera en el host. Este cliente inicia las sesiones iSCSI emitiendo comandos SCSI y trasmitiendolos, encapsulados en el protocolo iSCSI, a un servidor conocido como iSCSI target. El iSCSI target representa un sistema de almacenamiento fisico en la red y responde a los comandos del iniciador transmitiendo los datos iSCSI requeridos.

VMware utiliza puertos VMkernel como los iniciadores de sesiones, por lo que debemos configurar cada puertos que queramos utilizar como un camino (path) para el Storage. Esto es independiente del numero de NICs o HBAs iSCSI, pero en la mayoria de los casos será una relación uno a uno entre los puertos VMkernel y las interfaces disponibles. Una vez que las sesiones a la SAN son iniciadas, VMware NMP se encargará de balancear la carga y distribuir el trafico I/O entre todos los caminos disponibles.

Los volumenes en una SAN iSCSI pueden ser utilizados por ESX/ESXi como un Datastore VMFS o un Raw Device Map (RDM). El iniciador iSCSI por software utiliza los puertos VMkernel que fueron creados y establece una sesion a la SAN y a los volumenes. Con las versiones anteriores de VMware, estas sesiones eran establecidas utilizando un unico camino y cualquier NIC adicional era utilizada solo para efectos de Failover. Con las mejoras de vSphere y MPIO se pueden utilizar multiples caminos a la SAN para un mayor ancho de banda y performance.

Cada puerto VMkernel se encuentra asignado a un adaptador fisico. Dependiendo de la plataforma se pueden crear hasta 8 sesiones simultaneas a un volumen. Para una implementación estandar se recomienda el uso de una relación uno a uno (1:1) entre los puertos VMkernels y las interfaces fisicas, o sea si existen 4 interfaces fisicas, se crearía 4 puertos VMkernel, y se asociaria cada uno de estos puertos a una NIC separada. Este esquema puede ser expandido dependiendo del numero de NICs que se tengan disponibles.

A medida que la infraestructura va creciendo se pueden establecer multiples sesiones a la SAN suscribiendo más puertos VMkernel a las interfaces fisicas existentes. Esto establece multiples sesiones a un volumen, pero aun utiliza las mismas interfaces fisicas para acceder a dicho volumen.

Nuevas caracteristicas del iniciador iSCSI en vSphere

VMware vSphere ofrece muchas mejoras sobre el iniciador iSCSI por Software, junto con la conectividad para SAN iSCSI. Muchas de estas nuevas caracteristicas requieren configuración avanzada para trabajar apropiadamente, de hecho la configuración iSCSI utilizada en ambientes ESX/ESXi 3.5 no suficiente para habilitar todas las funciones avanzadas ofrecidas por vShere.

• Iniciador iSCSI por Software: Este iniciador fue re-escrito completamente en vSphere 4.1 para mejorar su performance y funcionalidad.
• Jumbo Frames: En vSphere 4.1 se puede habilitar Jumbo Frame en el iniciador iSCSI por Software. El soporte para Jumbo Frame permite la transferencia de paquetes más grandes entre los servidores VMware y la SAN, mejorando de esta forma la performance y eficiencia. Jumbo Frame puede ser habilitado solamente via la interfaz de linea de comandos (vCLI). Si se desea habilitar Jumbo Frame se debe recordar que esta configuración debe hacerse end-to-end, o sea desde el vSwitch hasta el Storage iSCSI, incluyendo los componentes intermedios.
• MultiPath I/O (MPIO): Con vSphere es posible el uso de Multipathing iSCSI desde los hosts ESX/ESXi y la SAN, permitiendo multiples conexiones concurrentes, aumentando asi el ancho de banda.

Buenas Practicas

• Se recomienda el uso de un Switch de red Gigabit Ethernet separado para el manejo del trafico iSCSI.
• Se recomienda conectar cada host VMware a 2 Switches iSCSI, cada uno de estos conectados a todas las controladoras disponibles en el Storage.
• Los servidores, Switches y puertos de las controladoras del Storage deben estar en el mismo segmento de red
• Se recomienda tener más de una HBA iSCSI o NIC dedicada para el trafico iSCSI.

Requisitos

Para la configuración de iSCSI en vSphere existen algunos requisitos que se detallan a continuación:

• Al menos una HBA iSCSI o NIC para el trafico iSCSI. En nuestro ambiente utilizaremos cuatro NICs para la configuración iSCSI.
• No se debe utilizar Switches Distribuidos (dVS) para el trafico iSCSI.
• Un segmento de IP dedicado para el trafico iSCSI. En nuestro caso utilizaremos el segmento no ruteable 10.0.0.x
• Verificar que todo el hardware utilizado, incluyendo las interfaces fisicas, el Storage y los servidores ESX/ESXi, se encuentren soportados por VMware.  Comprobar la compatibilidad en la Hardware Compatibility List (HCL)
• Solo se debe crear un Datastore VMFS por cada LUN creada en el Storage
• En VM utilizando Windows, aumentar el valor del parametro SCSI TimeoutValue para permitir que Windows tolere mejor las demoras en el I/O que pueda resultar del failover de los caminos o paths.
• Cuando se utiliza vCenter Server con vMotion o DRS, asegurarse de que las LUNs para las maquinas virtuales estén disponibles para todos los hosts ESX/ESXi requeridos.

Restricciones

• ESX/ESXi no soporta dispositivos de cinta conectados por iSCSI
• No se puede utilizar software de Multipathing en las maquinas virtuales para realizar el balanceo de carga de I/O a una unica LUN fisica.
• Un host no puede acceder a una LUN utilizando simultaneamente adaptadores iSCSI por software y por hardware.

Configuración de iSCSI en vSphere

Habiendo entendido la arquitectura de una SAN iSCSI y sus requerimientos y buenas practicas, a continuación detallaremos el proceso de configuración de iSCSI en VMware vSphere 4.1:

• Configuración de Red para iSCSI
• Habilitación del iniciador iSCSI
• Configuración de Targets iSCSI y agregar Datastores
• Configuración Multipath
• Habilitación de Jumbo Frame

Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware.

Read More

vSphere 4.1 / Cluster MSCS: Consideraciones finales

A continuación, y terminando con la Implementación de Cluster MSCS Across Boxes, entregaremos algunas consideraciones finales luego de la creación del Cluster.

Cuando se utiliza MSCS en un ambiente VMWare con HA o DSR habilitado, se deben realizar algunas configuraciones tanto a nivel de host como de virtual machine:

Todos los hosts que estan ejecutando virtual machines en cluster MSCS pueden ser parte de un cluster HA/DRS en vCenter Server. No obstante, si el cluster MSCS se encuentra en maquinas virtuales corriendo sobre un cluster VMware, se deben crear reglas de afinidad o de anti-afinidad. 

Las reglas de afinidad especifican cuales maquinas virtuales debieran permanecer juntas en el mismo host (esto aplica para cluster MSCS en una configuración Cluster In a Box). Por otro lado, las reglas de anti-afinidad especifican cuales maquinas virtuales debieran permanecer separadas en hosts fisicos distintos (esto aplica para cluster MSCS en una configuración Cluster Across Boxes). En nuestro caso especifico utilizaremos reglas de anti-afinidad. 

Para asegurar que las reglas de afinidad o anti-afinidad son aplicadas estrictamente, se debe configurar la opción avanzada ForceAffinePoweron para VMware DRS, dejandola con el valor "1", lo cual permitirá la aplicación estricta de las reglas creadas.

Se debe configurar el nivel de automatización de todas las maquinas virtuales en un cluster MSCS, dejandolas como "Partially Automated" o parcialmente automatizadas. Con esto se logra que vCenter Server realice la ubicacion inicial de las virtual machines cuando estas son encendidas y proveerá de recomendaciones de migración para estas. Considerar que no es recomendado la migración de Virtual Machines que sean parte de un cluster MSCS

Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware.

Espero que toda esta serie de articulos les haya sido de utilidad. Como siempre, estoy atento a cualquier consulta.

Read More