Objetivo 3.1 – Configurando almacenamiento de FC SAN.
3.1.1 – identificando los componentes de una SAN.
Cuando se decide usar una SAN en el ambiente de VMware primero tenemos que asegurar que esta SAN en particular está en la lista de hardware soportado de VMware (HCL). Una SAN está formada por diferentes compoenentes.
- SAN Controller
Esta es la parte que controla los discos, crea los LUNs y los presenta a nuestros ESX/ESXi. La mayoría de veces la controladora es manejada/administrada desde un entorno web o por un software determinado que proporciona el fabricante.
- SAN Switches
El SAN Controller y los host con ESX/ESXi deben estar conectados a estos Switches de Fibra. Se puede comparar un Switch de FC a uno de Ethernet pero no pueden ser mezclados.
- Host Bus Adapter (HBA)
Las HBA son las usadas para conectar nuestros ESX/ESXi a los SAN Switches, este también es un hardware que es muy recomendado sea soportado en el HCL.
Para leer más sobre Fabric Channel (FC) -> http://en.wikipedia.org/wiki/Fibre_Channel_fabric
3.1.2 – Identificando como las conexiones desde ESX/ESXi son realizadas al (FC) SAN Storage.
Los best practice indican que no solo para VMware ESX/ESXi los hosts conectados a una SAN deben contar con conexión redundante a la SAN, esto quiere decir que se necesitan 2 HBA por cada host conectadas a SAN Switches diferentes. Cuando se tienen estas 2 conectiones a la SAN se pueden configurar los host para que realicen round robin y combinar estos 4 para que trabajen como 1 con mejor desempeño.
Using ESX/ESXi with Fibre Channel SAN
3.1.3 – Describe el manejo de SAN en ESX.
El almacenamiento asignado a ESX desde una SAN es presentado como una LUN (Logical Unit Number). Las SAN usualmente pueden presentar hasta 25 LUN por cada controladora. Cuando una LUN es presentada a un host ESX a esta le será asignado un identificador único de 4 dígitos separado por dos-puntos (:). Por ejemplo: 1:0:0:2 estos dígitos representan un Adatador, Channel, Target, LUN.
En el vSphere Client podemos ver esta asignación de la siguiente manera:
Seleccionamos un host -> click en Configuration -> click en Storage Adapters -> seleccionar una HBA. El valor que estamos buscando aparece en la columna llamada “Runtime Name”.
3.1.4 – describir el concepto de zonning y LUN masking.
Estas técnicas son usadas para ocultar LUN a los hosts con ESX/ESXi.
- Zoning
Esta técnica es típicamente implementada en el SAN Switches. Zoning crea segmentos en los Switches de fibra que separa el tráfico de data permitiendo que solo los host configurados en esa zona puedan ver esas LUN.
- LUN Masking
Esta técnica es típicamente implementada en el host que tiene ESX/ESXi, con esta técnica se pueden ocultar las LUN desde el mismo host ESX/ESXi.
3.1.5 – Configurando LUN Masking.
LUN Masking es usado para ocultar ciertas LUN al host con ESX/ESXi. Todas las LUN presentadas al OS son normalmente visibles. Cuando se instala ESX en una LUN tenemos que asegurarnos que solo podemos ver la partición donde instalaremos el hypervisor, o corremos el riesgo de perder particiones con VMFS y por lo tanto con VM importantes.
El método de LUN Masking ha sido cambiado desde la versión 3.x. un nuevo comando es usado: “esxcli claimrules convert”. Este nuevo comando nos permite desenmascarar LUNs y convertirlas al nuevo formato que ahora es usado en ESX 4. Para enmascarar una LUN, el proceso debe realizar para cada camino existente desde el host hacia la SAN, esto quiere decir que si contamos con 4 caminos, debemos ejecutar el comando 4 veces.
esxcli corestorage claimrule add -r <claimrule_ID> -t <type> <required_option> -P <MASK_PATH>
En este enlace [ link ] podemos encontrar más ejemplos de LUN Masking.
3.1.6 – Buscando nuevas LUNs.
Cuando nuevas LUNs son presentadas en la SAN y asignadas a nuestros hosts con ESX/ESXi, estos deben realizar una búsqueda antes de que sean visibles para el sistema. Existen varias maneras de realziar esta búsqueda y nos permite hacer búsqueda para nuevos almacenamientos (New Storage Devices) y volúmenes VMFS (VMFS Volumes). Para realizar esta búsqueda desde el GUI (vSpehre Client) hacemos lo siguiente:
Seleccionamos el host ESX -> click en Configration -> click en Storage Adapters -> seleccionamos la HBA – click Rescan.
Nota: en ESXi no podemos seleccionar 1 solo HBA, el rescan se inicia en todos los HBA configurados.
3.1.7 – determinar y configurar la política apropiada de multi-pathing.
Multipathing es una técnica para optimizar el uso de todos los caminos hacia la SAN. Para manejar el Multipathing, ESX usa una capa especial en el VMkernel llamada Pluggeable Storage Architecture (PSA). PSA es un framework modular que coordina las operaciones simultáneas de multiples Multipathing Plugins (MPPs). Podemos seleccionar usar el Multipathing Plugin Nativo, o usar uno proporcionado por un vendor. Los policies de multipathing nativo que podemos usar con ESX 4 son:
- Most Recent USed (MRU)
Este selecciona el primero path funcional que fue descubierto al momento de iniciar el sistema. Si este path se vuelve inusable el host ESX cambia hacia el path alternativo. Esta es la configuración por defecto para LUNs presentadas desde un array configurado con Activo/Pasivo.
- Fixed (Fixed)
Este usa el path designado como preferido, si este ha sido configurado. De otro modo este usa el primer path funcional que fue descubierto al momento de iniciar el sistema. Si el host ESX no puede usar el path preferido, este seleccionara uno alternativo al azar, el host automáticamente volverá a usar el path preferido cuando este sea marcado como disponible. Esta es la configuración por defecto para LUNs prestadas desde un array configurado Activo/Activo.
- Round Robin (RR)
Este usa un modo automático de selección que rota entre todos los path disponibles y por ende habilitando la distribución de carga entre cada path. Para arrays configurados en Activo/Pasivo, solo el path hacia el controlador activo será usado en el Round Robin. Sin embargo para arrays configurados con Activo/Activo todos los path serán usados en el Round Robin. Esta configuración no está soportada para LUNs que son parte de un cluster de Microsoft (Microsoft Cluster Service – MSCS).
3.1.8 – Diferencias entre NMP y MPP de terceros.
El plugin de Multipathing proporcionado en el VMkernel por defecto es Native Multipathing Plugin (NMP), este es un módulo extensible que maneja subplugins. Existen 2 tipos de subplugins.
- Storage Array Type Plugins (SATPs).
- Selection Plugins (PSPs).
SATPs y PSPs pueden ser integrados y proporcionados por VMware o pueden ser proporcionados por un tercero. Si otras funcionalidades de Multipathing son necesarias, un vendor puede proporcionar un Multiple Multiphating Plugin (MPP) como adición, o como un remplazo del NMP. Un MPP es proporcionado específicamente para un arreglo de almacenamiento por el fabricante de este almacenamiento y puede contener configuraciones específicas de multipathing para mejorar el desempeño.
Los modulos de Multipathing realizan las siguientes funciones:
- Manejo del reclamo de los path físicos.
- Manejo de la creación, registro y eliminación de registros de los dispositivos lógicos.
- Asociación de los path físicos con los dispositivos lógicos.
- Procesamiento de peticiones I/O hacia los dispositivos lógicos.
- Selección del mejor path físico para una petición.
- Dependiendo del dispositivo de almacenamiento, realiza acciones específicas para manejar la pérdida de un path y reintentas comandos de I/O.
- Soporte de tareas administrativas, por ejemplo: abortar o resetear dispositivos lógicos.