martes, 13 de marzo de 2012

[MVA - Soporte a Infraestructura] Metodología de Resolución de Problemas

Los ingenieros de soporte necesitamos una metodología para solucionar los problemas de nuestros clientes. Hace algunos años atrás, miembros del grupo de soporte de escalación para Latinoamérica se reunieron y crearon una metodología que usa las mejores prácticas basadas en la experiencia del grupo y en el método científico para la solución de problemas. Este blog, usa el contenido de dicho trabajo realizado por los Support Escalation Engineers Viviane Lopes y Andre Teixeira.

Son varios los beneficios que se obtienen al utilizar una metodología para solucionar los problemas, entre ellos llegar a una solución lo más rápido posible. Hemos querido compartir con todos nuestros clientes estas mejores prácticas para que sean aplicadas no solamente en los casos de soporte de Microsoft, sino en general en cualquier escenario de solución de problemas técnicos.

El método científico parte de la definición de un problema, crea una hipótesis, recolecta los datos necesarios, analiza estos datos, entrega un reporte de lo que en los datos se encontró y valida o rechaza la hipótesis.

Estos mismos conceptos los podemos aplicar como metodología para la solución de los problemas de soporte técnico. De esta manera surgieron las cuatro etapas utilizadas por los ingenieros del grupo de soporte de Microsoft de Latinoamérica.

Estas cuatro etapas son:

· Defining.

· Gathering.

· Analyzing.

· Fixing.

image

Fig. 1. Metodología de resolución de problemas

Estas están representadas en la figura 1. Su representación es cíclica porque el proceso de resolución se mueve a través de las cuatro fases en secuencia con el objetivo de que en cada interacción el problema sea acotado más y más hasta llegar a la solución. La recomendación es seguir las fases en secuencia y no omitir ninguna.

Es muy difícil llegar al lugar a donde queremos ir si no definimos cual es dicho lugar. El proceso de resolución de problemas debe siempre comenzar con la definición del problema. A continuación vamos a hablar de cada una de las etapas en detalle.

Fase 1: Defining (Definición)

El primer paso es elaborar una buena definición del problema. Depende de cómo definamos el problema, va a ser más fácil o más difícil solucionarlo exitosamente. La definición del problema nos ayuda a definir también el criterio de solución del mismo. Esto es lo que llamamos scope del problema.

A menos que el problema este correctamente definido, es poco probable que sea encontrada una solución satisfactoria.

Existen varias técnicas que pueden ser utilizadas durante esta etapa y que ayudan a nuestros ingenieros a definir un problema, entre ellas tenemos:

· Escuchar activamente.

· Realizar preguntas precisas.

· Parafrasear.

Para quien ha interactuado anteriormente con nuestro grupo de soporte, seguramente estas técnicas les son familiares. El objetivo es capturar la mayor cantidad de detalles e información que nos ayude a definir el problema de una manera precisa.

Con base en la definición del problema y el conocimiento de cómo el producto debería funcionar, el siguiente paso que realiza el ingeniero es crear una hipótesis acerca de que podría ser la causa del problema.

Recordemos que una hipótesis es una declaración que aún no se ha establecido como cierta. En el caso de los ingenieros de soporte, diríamos que es una aproximación educada basada en experiencia, conocimiento, habilidades e intuición.

El crear una hipótesis nos ayuda a darle un enfoque a nuestro pensamiento y continuar con las siguientes fases.

La fase de defining o definición, nos debe dar como resultados:

· Una definición clara del problema.

· El criterio bajo el cual se define la solución del problema.

· Una o más hipótesis.

Fase 2: Gathering (Recolección)

Con base en la hipótesis creada, ahora sí podemos comenzar a recolectar los datos que son necesarios para comprobar o refutar la hipótesis. Muchas veces tendemos a capturar información sin antes haber definido el problema y puede ser frustrante invertir tiempo en recolectar información que no será usada. El primer objetivo de esta fase es definir un plan de acción efectivo para la recolección de los datos de tal manera que todos los datos necesarios sean recolectados en la primera vez. El segundo objetivo de esta fase es garantizar que la calidad de los datos es óptima antes de pasar al análisis.

Un buen plan de acción debe ser detallado, incluir información específica de lo que se necesita y si es el caso, incluir explicaciones detalladas de como recolectar la información. Actualmente existen herramientas de soporte remoto que facilitan esta labor, caso que se necesite de ayuda para recolectar los datos.

Después de definir el plan de acción de cuales datos se necesitan y cómo van a ser recolectados, el siguiente paso es recolectar dicha información siguiendo el plan creado. Una buena práctica es tomar una pequeña muestra de los datos para estar seguros que se está recolectando correctamente. Un ejemplo de este escenario son los logs del performance monitor. Se puede tomar una muestra por un periodo corto de tiempo para garantizar que los contadores están trabajando como se espera.

Antes que los datos sean analizados deben ser validados. La validación consiste en responder las siguientes preguntas:

· ¿Es leíble la información? Por ejemplo un dump de memoria. El cliente puede revisar que es válido antes de enviarlo al ingeniero usando herramientas como el dumpchk.exe.

· ¿Los datos contienen información relevante? Por ejemplo en una captura de red. El cliente puede revisar con en Network Monitor que la captura incluye tráfico entre las maquinas relevantes al problema.

Estas pequeñas acciones evitan invertir tiempo innecesario tanto del cliente como del ingeniero.

La fase de gathering o recolección, nos debe dar como resultados:

· Un plan de acción detallado para recolectar los datos necesarios.

· Validación de los datos recolectados.

Fase 3: Analyzing (Analisis)

El objetivo de esta fase es analizar la información recolectada en la fase anterior. Esta información es estudiada para confirmar o rechazar la hipótesis o hipótesis generadas en la primera fase.

Analizar el problema implica aprender sobre el mismo lo más que se pueda. En esta fase la experiencia en el tema es crítica así como también las herramientas usadas para el análisis.

Dentro de las acciones que un ingeniero de soporte realiza durante esta fase de análisis están:

· Separar los datos que son relevantes para el análisis basado en la definición del problema y en el conocimiento y experiencia sobre el tema.

· Buscar por evidencia obvia primero antes de invertir tiempo en un análisis más profundo. Para clarificar este punto, un ejemplo es revisar los logs de Event Viewer antes de tomar un dump completo de la máquina.

· Buscar por contenido ya existente en las bases de datos de conocimiento. Nuestros clientes podrían realizar este paso buscando en el sitio de soporte de Microsoft y también revisando sus bases de datos de problemas internos.

· Realizar un análisis más profundo. Esto es, investigar los datos recolectados en detalle, intentar reproducir el problema, comparar los datos recolectados con relación a un ambiente que esté trabajando normalmente.

Como resultado de este análisis, debemos ser capaces de confirmar la hipótesis, hay suficiente evidencia que confirme la hipótesis y soporte un diagnostico; o por el contrario tenemos que rechazar la hipótesis.

En caso que la hipótesis sea rechazada, tendremos que comenzar un ciclo, esto es, ir a la fase de definición nuevamente. En este punto se debe considerar colaboración o escalación del problema al siguiente nivel.

La fase de analyzing o análisis, nos debe dar como resultados:

· Hipótesis confirmada por el análisis de los datos.

· Resultado del análisis de los datos.

· Posible causa raíz identificada.

· Comunicación a nivel de las personas involucradas informando el progreso.

Fase 4: Fixing ( Solución)

En esta fase con base al análisis realizado previamente, necesitamos elaborar un plan de acción para solucionar el problema. Este plan de acción de solución debe considerar el impacto y los riesgos de las acciones sugeridas. De ser necesario se recomienda probar el plan de acción en un ambiente de pruebas y de no ser posible, incluir las medidas necesarias tales como tener un respaldo (backup), planes de contingencia, en caso que el plan de acción deba ser aplicado directamente a producción.

Como mejores prácticas para la solución de problemas técnicos, la experiencia nos enseña a:

· Si hay varias maneras de solucionar el problema o una solución involucra varios pasos, aplicar un cambio cada vez y observar los resultados.

· Seguir los pasos de acuerdo a las instrucciones dadas y al orden recomendado.

· En caso de dudas sobre el plan de acción, preguntar antes de ejecutar.

Aquí podemos tener varias situaciones, que veremos a continuación.

· Si después de aplicar el plan de acción, los síntomas desaparecen, podemos considerar el problema como resuelto.

· Si el problema original está resuelto pero aparece un problema diferente, esto se debe manejar como un nuevo incidente de soporte e iniciar nuevamente con el ciclo de solución.

· Si el problema continúa, no hay cambio en los síntomas, debemos retornar a la fase de definición y comenzar nuevamente. Escalación al siguiente nivel debe ser considerara en esta situación.

· Si el problema empeora (esta condición es la menos deseada por supuesto!), escalación al siguiente nivel debe ser considerada a este punto.

La fase de fixing o solución, nos debe dar como resultados la solución al problema originalmente definido o la decisión de volver a la fase de defining o definición nuevamente; obviamente considerando la posibilidad de involucrar recursos adicionales que nos ayuden a llegar a una solución.

Esperamos que este contenido les sea de utilidad y les ayude a solucionar los problemas siguiendo esta metodología que hemos compartido con ustedes y que si de ser necesario tienen la necesidad de interactuar con nuestro grupo de ingenieros de soporte se les facilite el trabajo y puedan llegar a una solución satisfactoria en conjunto lo más rápido posible.

sábado, 10 de marzo de 2012

VCAP – Sección 1.10 – VMware DirectPath I/O

Que tal Gente, el día de hoy comienzo con esta serie de posts como una referencia de todos los requerimientos para la certificación VCAP – DCA , la nueva certificación por parte de VMware, aquí les dejo un link hacia un documento donde podemos ver el glosario de todos los requerimientos en cuanto a conocimiento para poder aprobar el examen VDCA410:

http://communities.vmware.com/docs/DOC-12751

bueno como podemos aver notado en el titulo del post, vamos a hablar sobre DirectPath I/O, esta capacidad de VMware permite el uso de dispositivos PCI y PCI-e físicos del host ESX/ESXi por las maquinas virtuales.

Con esto todas las instrucciones que se tengan a dicho dispositivo no tiene que pasar por la capa de virtualización, quitando así el overhead que se tiene, VMs que requieran el uso de dispositivos para altas transacciones de I/O (ej. 10Gb Ethernet) son candidatos claros para el uso de esta tecnología. Actualmente se soportan interfaces de red y adaptadores de storage (HBAs de Fibra). Se pueden tener hasta 2 dispositivos PCI conectados a una VM.

Para poder hacer uso de esta tecnología debemos cumplir con las siguientes características:

  • Instrucciones  Intel Virtualization Technology for Directed I/O (VT-d) , se pueden encontrar en arquitecturas Nehalem.
  • Instrucciones en procesadores AMD IP Virtualization Technology (IOMMU).
  • Las maquinas virtuales deben contar con hardware virtual versión 7.

Al activar esta función perdemos varias capacidades que nos ofrece VMware:

  • VMotion
  • Storage VMotion
  • FT
  • Hot add de dispositivos
  • Suspender y resumir VM
  • Record  & replay

Bueno espero haya quedado claro en que nos ayuda y que nos afecta, ahora vamos a conocer como lo activamos.

Paso 1-. Seleccionamos el Host ESX que esta alojando la VM en cuestión , navegamos a Configuration > Advanced Settings

Paso 2-. Se nos mostrará una ventana de VMDirectPath Configuration damos click en "Configure Passthrough", esto nos abrirá una pequeña ventana donde marcaremos el dispositivo.

Paso 3-. Una vez seleccionados los dispositivos, reiniciamos nuestro Host ESX/ESXi.

Paso 4-. Seleccionamos la VM a la cual queremos agregar dicho dipositivo, damos click derecho sobre la misma y "edit settings" y damos click en "add"

Paso 5-. Se nos abrirá una nueva ventana donde seleccionamos el tipo de hardware que deseamos agregar, seleccionamos PCI device y a continuación seleccionamos el dispositivo que marcamos para VMDirectPath

Con esto al iniciar nuestra VM podremos notar que se detecta el nuevo dispositivo.


VCAP – Sección 1.9 – NPIV

Que tal gente, hoy vamos a hablar de NPIV (N_Port ID Virtualization) continuamos con los temas de VCAP.

¿Que es NPIV?

Es un standard de ANSI T11 , con el cual tenemos la capacidad de asignar WWN (World Wide Name) por maquina virtual, con esto logramos compartir una misma HBA de fibra para varios WWNs , primero vamos a entender un escenario clasico de Fabric:

En esta imagen tenemos un servidor Fisicos conectado a un arreglo de discos a través de FC . Los componentes son los siguientes:

1-. Servidor

2-. Switch de fibra

3-. Almacenamiento

4-. N-port

5-. F-port

Aquí podemos ver claramente que parte de la fabric o de nuestra infraestructura es un N-Port, en pocas palabras es el puerto de nuestra HBA de fibra que se conecta hacia el switch de fibra.

Existen 2 tipos de WWN:

  • WWNN: este identificador es asignado a cada uno de los nodos que conforman la fabric,  esta conformado por una serie de valores hexadecimales. Estos identificadores WWN pueden ser regenarados a diferencia de los WWPN. En el caso que el host tenga una HBA con varios puertos estos puertos compartirán el mismo WWNN.
  • WWPN: Este identificador se asigna fisicamente a cada uno de los puertos, como pueden ser HBAs , puertos del almacenamiento, etc. Estos son valores únicos y no se pueden modificar. La comunicación entre el almacenamiento , switches y servidores se lleva a cabo entre los WWPNs.

Para que quede mas claro podemos tomar el ejemplo de un almacenamiento X que tenga 4 puertos de fibra, cada uno de estos puertos tendra un unico WWPN , y el almacenamiento en si tendra solo 1 WWN :

 

¿Que ventajas nos ofrece el NPIV?

  • Menos componentes físicos, por lo tanto menos puntos de falla. Ej. con una HBA podemos asignar varios WWN para un grupo de máquinas, logrando así el poder administrar el almacenamiento por VM o aplicación.
  • Seguridad Granular con NPIV podemos zonificar por VM con esto logramos restringir el acceso a LUNs.
  • Monitoreo mucho mas granular, tomando en cuenta que cada máquina tendría un único identificador WWN podemos hacer uso de herramientas existentes para servidores físicos ya que la comunicación es etiquetada con sus identificadores.
  • Movilidad, cada VM conserva su identificador WWN sin importar en que servidor se encuentre, con lo cual no requerimos hacer cambios en nuestra zonificación.

Desventajas:

  • Solo funciona con RDMs , VMFS no esta soportado.
  • FT no esta soportado
  • Storage VMotion no esta soportado

 

Requerimientos:

  • Switches de Fibra compatibles con NPIV
  • HBAs de Fibra compatibles con NPIV (Brocade, Emulex y Qlogic)

Pasos para Configurar NPIV

Paso 1-. Tener un RDM agregado a nuestra VM, sin esto no tendremos habilitadas las opciones de NPIV.

*Nota para poder hacer uso de VMotion con NPIV necesitamos tener nuestro apuntador de RDM residiendo en el mismo datastore de nuestra VM y nuestro RDM tiene que ser creado en modo virtual.

Paso 2-. Hacemos click derecho sobre nuestra VM , y damos click en "edit Settings", una vez abierta la ventana de settings vamos a la pestaña de "options" y seleccionamos "generate".

Paso 3-. una vez creados los WWNs los utilizamos para realizar la zonificación de nuestro almacenamiento basandonos en estos.

 
¿Como puedo verificar la creación del VPORT?


Paso 1-. identificamos nuestra HBA

# ls /proc/scsi

Qlogic es identificado como qla2300

Emulex es identificado como lpfc

Paso 2-. Una vez encendida la VM con NPIV habilitado, ingresamos a nuestra service console y con el resultado de la identificación de nuestra HBA hacemos uso de los siguientes comandos (dependiendo que marca es nuestra HBA).

# cat /proc/scsi/qla2300/6 (Qlogic, sustituimos el numero "6″ por el numero de nuestra HBA)

Este comando nos dará información como la siguiente:

FC Port Information for Virtual Ports:
Virtual Port index = 1
Virtual Port 1:VP State = <ACTIVE>, Vp Flags = 0×0
scsi-qla2-port-3=500601609020fd54:500601601020fd54:a00000:1000: 1;
scsi-qla2-port-4=500601609020fd54:500601681020fd54:a10000:1000: 1;
Virtual Port 1 SCSI LUN Information:
( 0:10): Total reqs 10, Pending reqs 0, flags 0×0, 2:0:1000,

# cat /proc/scsi/lpfc/3 (Emulex, sustituimos el valor "3″ por el numero de nuestra HBA)

Se nos dará información como esta:

# cat /proc/scsi/lpfc/3
SLI Rev: 3
NPIV Supported: VPIs max 127 VPIs used 1
RPIs max 512 RPIs used 13
Vports list on this physical port:
Vport DID 0x2f0901, vpi 1, state 0×20
Portname: 48:19:00:0c:29:00:00:0d Nodename: 48:19:00:0c:29:00:00:0b

Desde nuestros Switches de fibra también podemos verificar que efectivamente se creo el VPORT:

Brocade: con el comando  "nsshow" el cual nos muestra información sobre el switch y de nodos conectados al mismo. Solo buscamos en los nodos los secuencia de valores "00:0c:29″ que hacen referencia a los VPORTs de VMware.

Qlogic: con el comando "show ns"  se nos mostrarán los nodos conectados , nuevamente solo necesitamos confirmar que existe la secuencia de valores "00:0c:29″ sobre la columna de "Node WWN"


VCAP – Sección 1.8 – Configurar,administrar plugins PSA y arquitecturas complejas

Que tal gente, el día de hoy vamos a hablar del objetivo 1.3 de nuestra guía de VCAP, en este caso estaremos tocando temas referentes a la nueva arquitectura para el manejo de nuestro almacenamiento en vSphere – PSA (Pluggable Storage Architecture).

Un poco antes de comenzar con esta serie de posts de VCAP publique este post:

vSphere – ¿Que es VMware PSA?

aquí plasmo de manera completa (a mi parecer) como está conformada esta nueva arquitectura de almacenamiento y que ventajas tenemos. Creo que faltan algunos puntos en este post, vamos a echar un  vistazo:

¿Como modifico el PSP (Path Selection Plugin) predefinido de un SATP (Storage Array Type Plugin)?

Ej. Para un almacenamiento reconocido como Activo/Activo se le asigna un PSP Fixed.  Ejecutando el siguiente comando podemos ver cuáles son las reglas predefinidas

esxcli nmp satp list

En este caso estaremos trabajando con un almacenamiento Netapp, el cual es activo/activo. Así que haremos las modificaciones a la regla correspondiente para cada vez que se detecte un LUN de este almacenamiento se le asigne Round Robin en lugar de MRU.

Aquí tenemos el cómo se detecta un LUN por default para este tipo de almacenamiento:

Este tipo de almacenamiento es detectado como "VMW_SATP_DEFAULT_AA" así que haremos las modificaciones necesarias en dicho SATP:

esxcli nmp satp setdefaultpsp –satp VMW_SATP_DEFAULT_AA –psp VMW_PSP_RR

–SATP (Storage Array Type Plugin)

–PSP (Path Selection Plugin) en este caso lo modificamos a "VMW_PSP_RR" el cual es Round Robin.

con esto tenemos el siguiente resultado:

Una vez reiniciado nuestro host ESX/ESXi detectará todas las LUNS presentadas por almacenamientos activo/activo y les asignará el PSP de Round Robin:


Configurar iscsi port binding (iscsi multipathing)

ISCSI al ser un protocolo basado en tcp/ip y en el caso de iscsi basado en software (manejado por el vmkernel) este entabla todas las comunicaciones a traves de nuestras pNICS o tarjetas de red. En el caso que nosotros quisiéramos tener varios "paths" o caminos también conocido como multipathing necesitamos seguir ciertos pasos para poder habilitar varios puertos de vmkernel para la comunicación de ISCSI.

Inicialmente tenemos una configuración como la siguiente, un puerto vmkernel y en el mismo vSwitch donde reside este puerto puede existir una o más tarjetas de red realizando un nic teaming.

En este punto tenemos comunicación con nuestro almacenamiento iscsi de manera redundante mas no distintos "paths" o caminos hacia dicho almacenamiento ya que la comunicación es a través de una sola ip del lado de nuestro servidor ESX/ESXi siguiendo los siguientes pasos habilitaremos la comunicación para dos puertos vmkernel esto lo conocemos como iscsi port binding:

Paso 1-. Creamos uno o más puertos vmkernel (segun numero de pNics):

 

Nos aseguramos que cada uno de los puertos de vmkernel estén utilizando una de las tarjetas asignadas a dicho vSwitch, damos click en "properties…" seleccionamos uno de los puertos de vmkernel y damos click en "edit" después seleccionamos el tab de "nic teaming" y marcamos el checkbox de "override vSwitch failover order", con esto tendremos la capacidad de seleccionar una pNIC como activa y la otra(s) desactivadas, esto lo realizamos en cada uno de los puertos de vmkernel asignados para nuestra comunicación ISCSI habilitando una tarjeta exclusiva para cada uno de ellos:

 

Paso 2-. En este momento necesitamos crear la asociación entre puerto vmkernel y pnic para que nuestro servidor ESX/ESXi sea capaz de utilizar ambos puertos para la comunicación ISCSI.

dentro de nuestro service console o del tsm (esxi) e ingresamos el siguiente comando para crear dicha asignación:

esxcli swiscsi nic add -n vmk1 -d vmhba33

-n nombre del puerto vmkernel, vmk#

-d hba de sw iscsi (esto lo verificamos en "configuration>Storage Adapters")

Paso 3-. Verificamos que efectivamente ya esta asignado el vmknic:

esxcfg-vmknic -l

 


VCAP – Sección 1.7 – Analizar comportamientos de I/O para determinar los requerimientos de almacenamiento

Que tal gente, continuando con los temas de VCAP nos toca hablar sobre el como analizar los comportamientos o workloads a nivel del almacenamiento, para esto estaremos primero entendiendo ciertos conceptos y factores que componen estos workloads.

Es importante conocer el comportamiento que tienen nuestras aplicaciones para poder hacer un correcto diseño de nuestra infraestructura, en este caso nos estamos enfocando al almacenamiento parte fundamental del performance que tendrán nuestras aplicaciones virtualizadas.

¿Que elementos determinan el performance de nuestro almacenamiento?

  • IOPS: I/O per secondbásicamente la cantidad de lecturas y escrituras que un disco puede realizar en un segundo, esto básicamente nos dirá la capacidad del disco o del tipo de disco que estaremos utilizando para responder a nuestras operaciones. Existen valores aceptados y utilizados como base para cada tipo de disco:

  • Latencia: básicamente es la cantidad de tiempo que nuestro disco o almacenamiento tarda en responder a nuestras solicitudes en disco, este valor se mide en ms,  un valor aceptable estaría entre 5 ms a 10 ms dependiendo los requerimientos de las aplicaciones virtualizadas.
  • Ancho de banda o capacidad del arreglo/disco/interfaz (Mbps): este ancho de banda depende de que interfaz estaremos utilizando, existen varias interfaces actualmente, IDE, SATA,SCSI,SAS y FC.  Estas interfaces son vistas de distinta manera en el lado de un almacenamiento central (SAN, NAS), ya que ahí estaríamos hablando de 2 tipos de interfaces, back-end y front-end. En el caso de back-end es la interconexión entre los distintos controladores o storage processors de dicho almacenamiento aquí generalmente hablamos de interfaces SAS y FC. Finalmente en el caso de Front-end hace referencia a la interfaz que tiene contacto directamente con los servidores o clientes de este almacenamiento, aquí demos interfaces de FC y ethernet (ISCSI , NFS ,CIFS).

  • RAID: en un post anterior tocamos el tema de los niveles de RAID, aquí tenemos que tener en cuenta que el nivel de RAID implica cierta implicación al performance en cuanto a escritura se refiere , para ser más claro, debido a la paridad que se tenga dependiendo del nivel de RAID para poder hacer la escritura de un bloque tiene que también escribir los bloques de su paridad es por eso que debemos tener en consideración este punto en el momento de hacer el calculo de nuestro almacenamiento. Aquí les dejo el link a mi post anterior sobre los niveles de RAID:

http://hispavirt.wordpress.com/2010/10/11/vcap-%e2%80%93-seccion-1-%e2%80%93raid-y-vms/

  • Cache: En los sistemas de almacenamiento central, incluso en los mismos discos que utilizamos día a día existe un factor clave para mejorar el performance, el cache, por cache entendemos escencialmente memoria RAM que actua como buffer almacenando las operaciones de I/O, existen 2 tipos de caches , volatiles y no volatiles estos se diferencian simplemente en si se pierde o no la información almacenada en el caso de perdida de energía. Generalmente el cache para operaciones de escritura es no volatil es decir no se pierde en el caso de perdida de energía al contrario del cache para lecturas. Al ser memoria RAM es mucho más veloz que cualquier sistema de disco con esto mejoramos significativamente el performance de nuestro almacenamiento debido a que las operaciones son almacenadas temporalmente en estos caches y después escritas a disco, con esto ganamos la capacidad de aceptar mas operaciones concurrentes y en el caso de lectura almacena las lecturas anteriores a disco y en casos de almacenamientos avanzados existen algoritmos que predicen que información será leída y se almacena en dicho cache para ser entregada mas rápido.
  • Queuing: con esta capacidad del almacenamiento se encolan las operaciones de I/O para poder ser procesadas después, esto puede ser a nivel del almacenamiento y directamente en las HBAs de nuestros servidores.
  • Coalescing: esta capacidad de algunos almacenamientos lo que realiza es ordenar las operaciones de I/O almacenadas en cache  en el caso que tengamos un comportamiento "random" con esto se busca reducir la cantidad de actividad en disco ya que los comportamientos de escritura serán uniformes.

¿Que tipos de comportamientos o workloads existen? ¿Que debo tener en cuenta?

Existen 2 principales tipos de comportamientos en cuanto a operaciones a disco se refiere, secuencial y random. En el caso de un comportamiento secuencial las operaciones de I/O se llevan a cabo de manera más rápida debido a que se necesita un menor numero operaciones de "seek" que básicamente lo que se realiza es un posicionamiento de la aguja del o los discos en el correcto sector donde reside la información. Al contrario en el caso de un comportamiento random o al azar las operaciones de I/O estarán tratando de acceder a distintos sectores del almacenamiento, aumentando así las operaciones de seek a este tiempo se le llama "seek latency".

Una vez que sabemos que tipo de comportamiento tiene nuestra aplicación sea secuencial o random es importante tener en cuenta los siguientes elementos:

  • tamaño de las operaciones I/O (I/O request size):  el tamaño de la información leída o escrita a nuestro almacenamiento, entre más grande el tamaño de nuestra operación ej. 64k será más eficiente de procesar y decrece el uso de procesador. Existen distintos tamaños, podemos ver 2k, 4k, 8k, etc. En el caso que quisiéramos virtualizar servidores Windows podemos determinar el tamaño de nuestras operaciones utilizando perfmon y ejecutando el siguiente counter "Avg. Disk Bytes/Read".
  • porcentaje de escritura y/o lectura: importante para determinar el nivel de RAID a utilizar, ej. en el caso de aplicaciones que requieran un alto nivel de escritura se benefician de un raid 10.

¿Como puedo obtener todos estos datos?

VCAP – Sección 1.6 – LUN masking utilizando comandos de PSA

Que tal gente, continuando con los temas para la preparación de VCAP nos toca hablar de cómo hacer un mask o prevenir que ciertos hosts ESX/ESXi puedan tener visibilidad de algún LUN en especifico, esto basándonos sobre el nuevo plugin de PSA MASK_PATH de PSA.

En el diseño de nuestra arquitectura siempre es importante tomar en cuenta la cantidad de Hosts que estarán accediendo concurrentemente a un LUN, debido a que a mayor cantidad de hosts , mayor cantidad de operaciones SCSI. Si nosotros tenemos un granja de servidores ESX/ESXi 15+  servidores es un punto que tenemos que tener muy presente, aquí es donde entra el objetivo de enmascarar ciertas LUNs para ciertos hosts.

Generalmente este enmascaramiento lo hacemos del lado de la SAN y lo conocemos como zoning, pero también tenemos la capacidad de hacer este enmascaramiento directamente en los hosts ESX/ESXi, tengamos en cuenta que lo recomendado y lo más sano en términos de administración es hacerlo del lado de nuestro almacenamiento.

¿Cómo enmascaro algun LUN en mis hosts ESX/ESXi?

Paso 1-. Ingresamos a nuestro servidor ESX/ESXi con el vSphere Client, una vez dentro, navegamos a configuration>Storage Adapters

Paso 2-. Seleccionamos el adaptador a través del cual se esté llegando a dicho almacenamiento (HBA de FC , SW iscsi o HBA de ISCSI). Una vez seleccionado, en  los detalles de dicho adaptador encontraremos 2 tipos de vista Devices/Paths , damos click en Paths, aquí se nos mostrará cuales son los paths a través de los cuales se llega a dicho almacenamiento:

Paso 3-. Una vez que ya tenemos enlistados los paths, es cuestión de crear reglas para enmascarar cada uno de ellos, comenzamos por enlistar las reglas existentes para poder saber con que numero de regla podemos comenzar:

esxcli corestorage claimrule list

Paso 4-. Creamos las reglas necesarias (numero de paths) para enmascarar dicho LUN:

esxcli corestorage claimrule add -P MASK_PATH -r 120 -t location -A vmhba33 -C 3 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 121 -t location -A vmhba33 -C 2 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 122 -t location -A vmhba33 -C 1 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 123 -t location -A vmhba33 -C 0 -T 0 -L 0

-C Canal o channel

-T destino o Target

-L LUN

-A adaptador

Recuerden que estos son los elementos del runtime name

Paso 5-. Cargamos las reglas que recién creamos y verificamos que efectivamente ya se muestran en la lista de reglas:

esxcli corestorage claimrule load

esxcli corestorage claimrule list

Paso 6-. Si se trata de un LUN que ya se presentaba en nuestro host ESX/ESXi, necesitamos quitar la regla actual:

esxcli corestorage claiming unclaim -t location -A vmhba33

Paso 7-. Ejecutamos nuestras reglas:

esxcli corestorage claimrule run

Una vez realizados estos pasos ya hemos enmascarado dicho LUN a nuestro host, si ingresamos con nuestro vSphere client y navegamos a configuration>Storage Adapters se nos muestran los paths como "dead":