Chubascos Blog

Chubascos tecnológicos para quitarnos la neblina de las tecnologías de la nube! Viva la lluvia!

Archivos por Etiqueta: almacenamiento

Yet Another VCAP-DCA post – Sección 1 – Objetivo 1.1 / Parte 5

Hola,

Quinta parte del objetivo 1.1. Recordad que los temas a tratar en la entrada están enmarcados con asteriscos (*) y los temas tratados en entradas anteriores son hipervínculos a las mismas.

Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.

Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
*Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.*
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como “re-firma” me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento “profil-driven”.
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.

Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV

Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop

Contenido:

Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.

Bien, entramos de lleno en un tema más que interesante y que por el detalle que requiere se suele pasar por alto o dimensionar “más o menos a ojo y a base de experiencia”.

Como ya se habló en otro post de la serie, cada tipo de RAID viene acompañado de algún tipo de penalización en el momento de escribir. Esta penalización puede ser de 1-1 IOPS (penalización nula o dicho de otra forma, que no hay penalización) o como es el caso más conocido, el del RAID 5, el cual es 4-1 IOPS. Donde por cada operación de I/O que le sea solicitada a nuestro RAID, se generarán 4 IOPS.

Bien, determinar el nivel apropiado de RAID para los distintos tipos de cargas en las VMs primero y sobre todo, implica que conozcamos el tipo de carga de nuestra VM. Esto se refiere a:
– Porcentaje de lecturas
– Porcentaje de escrituras
– Frecuencia de acceso a la información
– Cantidad de información actual y previsión de crecimiento
– Tipo de operaciones (secuenciales o aleatorias)
– Picos y utilización media

Esto sólo para empezar! Para seguir con lo de “nivel apropiado de RAID”, también habría que conocer cómo calcular el impacto de cada tipo de RAID en determinados tipos de carga. Esto básicamente se reduce a una fórmula muy sencilla en la cual se consideran los porcentajes de lectura y de escritura así como la penalización por el tipo de RAID y también la cantidad de IOPS para las que estamos dimensionando el RAID.

Por último podríamos también hablar de la infraestructura en sí. Desde donde viajarán los datos (HBA), el tipo de protocolo que utilizaremos, el recorrido que harán y finalmente las características físicas y configuraciones que tengamos en nuestro storage…desde tipos de procesador hasta tipos de interconexión de los discos. Nada más imaginaos dimensionar un storage para soportar una cantidad altísima de operaciones pero lo conectamos todo a través de un cable a 1Gbps.

Como veréis, no son pocas las variables y sí es poco el conocimiento que se tiene del impacto REAL Y MEDIBLE de cada una de ellas. Evidentemente escribir un libro para calcular un RAID no es la idea (como lo de las HCL que comentábamos en otra entrada) por lo que veremos más en profundidad lo que a mi entender es más relevante.

Por favor, si os parece que me dejo algún aspecto relevante fuera del estudio, avisadme para poder valorar su inclusión en el post.

Tendremos en cuenta:

– Espacio necesario
– Porcentaje de lecturas
– Porcentaje de escrituras
– IOPS de la VM

Espacio necesario

Lo primero será obtener la información de la ocupación actual de la VM y la previsión de crecimiento. Esto es demasiado fácil como para tener que explicarlo 🙂 Pero basta con mirar la información de la VM desde el propio S.O. en todas sus particiones/puntos de montaje y mirar un poco el histórico de crecimiento además de preguntar si habrá algún tipo de cambio importante. Por ejemplo, que en un servidor de correo se desee ampliar la cuota de los buzones, que en un servidor de ficheros se piense comenzar a almacenar otro tipo de información como videos, fotos, etc por las mismas necesidades de negocio…vamos, cualquier cosa que pueda “romper” el histórico de crecimiento.

IOPS y distribución entre lecturas y escrituras

Esto ya tiene un poco más de miga (un poco) y podemos decir que hay muchas formas de verlo. Por ejemplo, con vcOPS. Esta herramienta ya nos presentará la información (TPS=Transacciones por segundo) desglozadas en lecturas y escrituras desde donde podremos obtener los porcentajes.

Utilizando esxtop o resxtop (la variante de esxtop que se usa desde vMA), podremos identificar las IOPS. Bastará con ir a la vista de las VMs (presionando “v”) y ver el número que nos muestra el campo CMDs de comandos por segundo. Normalmente este campo es igual al número de IOPS, salvo que algunas veces puede estar un poco hinchado por otro tipo de datos que no está demás contar como las reservas SCSI. “READS/s y WRITES/s” son la cantidad de inodos que se ven afectados ante las vibraciones de nuestro storage y la posición relativa del sol y la luna….que no! era para ver si estabais despiertos 😀 Evidentemente se trata de las lecturas y escrituras y la suma de estos dos valores dan como resultado los “CMDs” del primer campo.

Imagen

esxtop no sería mi primera opción ya que se trata de una herramienta para diagnosticar problemas y las circunstancias que los causan (root cause analisys). Sin embargo, se puede ejecutar esxtop de forma que guarde la información en un fichero y lugo la podamos “graficar” con un excel. Marco Broeken lo explica detalladamente en su blog http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/

Existe una versión gráfica de esxtop que podréis descargar desde los labs de VMware. Es un “fling” muy útil y fácil de usar.
http://labs.vmware.com/flings/visualesxtop

En lo personal suelo utilizar la versión opensource de Hyperic ya que además de analizar IOPS, me permite relacionar esas IOPS con otros factores como las consultas SQL, el número de usuarios conectados a una aplicación, bbdd, etc.
http://www.hyperic.com/hyperic-open-source-download

Las cuentas claras, conservan la amistad

Ahora sólo falta hacer números. Es MUY sencillo y no guarda ningún misterio. La fórmula con las modificaciones que Duncan Epping hizo para contemplar la penalización en las escrituras de los tipos de RAID, es la siguiente:

( IOPS de la VM × % lecturas ) + (( IOPS de la VM × % escrituras ) × Penalización RAID)

Por tanto, en caso de que nuestro estudio previo nos haya dado como resultado que nuestra VM necesita 1000 IOPS (aquí entra en factor un aspecto de diseño importante…diseñaremos para los picos de carga o diseñaremos para el consumo medio lo que resultará en ahorre de costes y cuellos de botella esporádicos. Aunque esto mejor dejarlo cuando vayamos por el VCAP-DCD 🙂 ) de los cuales el 40% son escrituras y el otro 60% son lecturas. La fórmula quedaría:

IOPS de la VM = 1000
% lecturas = 60%
% escrituras = 40%

( 1000 IOPS x 0,6 ) + (( 1000 IOPS x 0,4) * Penalización RAID) =
600 IOPS + ( 400 IOPS * Penalización RAID) =

Ahora toca jugar un poco con los RAIDs y recordar las penalizaciones para cada uno de ellos. Sobran las tablas por internet que muestran estas penalizaciones así que simplemente supondremos que queremos ver cómo nos quedaría con un RAID 5.

600 IOPS + ( 400 IOPS * 4 IOPS ) =
600 IOPS + 1600 IOPS = 2200 IOPS

Vemos así cómo para una VM con 1000 IOPS necesitaremos un RAID 5 de 2200 IOPS ya que cada una de las IOPS de escritura y sólo de escritura, tendrá una penalización de 4 IOPS por c/u de escritura.

Aquí se puede jugar mucho pero otra vez nos iríamos a la parte de diseño más que VCAP-DCA. Cuando tengamos que diseñar un storage, básicamente en este punto se tratará de un equilibrio entre IOPS y espacio que se necesita. De forma que la tarea se reduzca a encontrar la combinación que cubra las necesidades de IOPS y espacio con el menor coste posible. En este sentido, los discos de estado sólido están rompiendo las reglas del juego ya que para lo que antes podíamos necesitar barbaridades de discos, ahora con 4 o 5 discos de estado sólido lo conseguimos y a un mejor precio!

Algunas cosas que quiero comentar antes de dar por finalizado el post:

Lecturas – Si bien las escrituras sólo pueden quedarse igual o empeorar según el tipo de RAID que utilicemos, las escrituras sólo pueden mejorar. En este caso los cálculos son muy sencillos, basta con sumar las IOPS de los discos que forman el RAID y ya sabremos las IOPS de lectura que tenemos. Hay muchos debates en internet de “qué RAID es el mejor en lecturas”…la respuesta es fácil, mientras de más discos se pueda leer la información, mejor. Supongamos que un fichero de 10 MB está distribuido en 5 discos y que la controladora es capaz de leer de todos a la vez (a cada disco le toca leer 2MB)…mejor que si sólo tenemos el fichero en 2 discos (a cada disco le toca leer 5MB).

IOPS = La cantidad de operaciones de entrada/salida por segundo. Normalmente utilizada para medir los accesos aleatorios de escritura y lectura de bloques pequeños. Cargas habituales OLTP. Se puede calcular:
IOPS = throughput / block size

Throughput = La cantidad de información que se puede transmitir por segundo. Normalmente se utiliza para medir accesos aleatorios de bloques más grandes (64K). Se puede calcular:
Throughput = IOPS * block size

Block size = La cantidad de datos que se transmite en una operación de entrada/salida. Se puede calcular:
Block size = IOPS / Throughput

Frecuencia de acceso a la información = Casi todas las cabinas traen más o menos caché. Algunas con funcionalidades de tiering ponen en esta caché la información más utilizada por lo que es muy posible que cuando estemos realizando operaciones, muchas de ellas se valgan de la caché de nuestro storage. Por esto también es importante contrastar las fuentes de nuestra información. Una cosa es medir desde dentro del entorno virtual, otra es hacerlo a nivel de hipervisor y otra es hacerlo a nivel de storage. Como recomendación, si es posible, contrastar todas las fuentes para depurar la información en la que basaréis el diseño.

Bueno, otro post que se nos fue. Espero que esta información os sea útil y por favor dejad vuestros comentarios que hará ilusión leerlos 🙂

Saludos,
Sebastián Greco

Bibliografía utilizada para escribir este post:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008205
http://www.yellow-bricks.com/esxtop/
http://labs.vmware.com/flings/visualesxtop
https://communities.vmware.com/thread/456397
http://labs.vmware.com/flings/io-analyzer
http://goo.gl/t9Hl0Y
http://www.lucd.info/2011/04/22/get-the-maximum-iops/
http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/
http://www.hyperic.com/hyperic-open-source-download
http://wintelguy.com/2013/20130406_disk_perf.html
http://www.yellow-bricks.com/2009/12/23/iops/
http://www.tomshardware.co.uk/forum/251893-32-raid-raid#.
http://wintelguy.com/raidperf.pl
http://www.dataram.com/blog/?p=112
http://es.wikipedia.org/wiki/OLTP
http://es.wikipedia.org/wiki/OLAP

Yet Another VCAP-DCA post – Sección 1 – Objetivo 1.1 / Parte 4

Hola,

Vamos con la cuarta parte del objetivo 1.1. Recordad que los temas a tratar en la entrada están enmarcados con asteriscos (*) y los temas tratados en entradas anteriores son hipervínculos a las mismas.

Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.

Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
*Determinar los requerimientos y configurar NPIV.*
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como “re-firma” me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento “profil-driven”.
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.

Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV

Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop

Contenido:

Determinar los requerimientos y configurar NPIV.

En un fabric se encuentran varios tipos de puertos. Entre ellos los N_port, E_port, U_port y F_port. Los puertos que nos ocupan, los N_port, utilizados en los nodos que se conectan a un switch de fibra o a otro N_port en una conexión punto a punto, se identifican con una especie de MAC address que se llama “world wide name” de las siglas WWN. Al igual que una MAC address, este ID es único para cada port dentro del fabric. Una de las capacidades del protocolo Fibre Channel (alguna vez escuché que se escribe “Fibre” para distingirlo de una conexión que va por fibra “fiber” aunque si lo busco en el traductor aparecen las dos como válidas) es que permite virtualizar este ID, de forma que podamos asignar más de un ID a un mismo N_port físico. Por esto veremos que a veces uno habla del WWN del nodo o del port. Los puertos virtuales se crean y eliminan cada vez que uno enciende y apaga la VM. Para las operaciones de vMotion, este puerto (VPORT) se borra del host origen y “viaja con la máquina” para volver a ser creado en el host destino. A todos los efectos se comporta dentro de nuestro fabric como un puerto más de tipo N. Para los casos en que a una VM no le asignemos un VPORT, la misma utilizará el WWN del nodo para identificarse dentro de nuestro fabric.

vSphere permite aprovechar esta funcionalidad para que podamos presentarle a nuestras VMs, HBAs virtuales con distintos IDs y puertos. Cormac Hogan en su blog (la referencia a este blog está en la bibliografía) no termina de ver claro para qué se puede querer algo así. Leí una vez en el libro de vSphere Design Best Practices al cual ya no tengo acceso, que uno de los usos para este tipo de tecnología podía ser realizar zonings y/o maskings ya que este tipo de consideraciones era pertinente en la fase de diseño del storage y de los hosts (tipos y número de HBAs).

Vemos los requerimientos de esta tecnología:
– Sólo trabaja con discos RDM.
– HBAs compatibles con NPIV.
– Las HBAs de un host que accedan a la misma LUN deben ser de un único fabricante.
– Si un host utiliza paths de varias HBAs físicas para acceder al storage, la VM que utilice NPIV deberá estar en todas esas zonas. Esto es un requerimiento para soportar multipathing.
– Las HBA físicas del host deben tener acceso a las LUNs que queramos que nuestras VMs con los NPIV configurados tengan acceso.
– Los switches en el fabric tienen que soportar NPIV.
– Asegurarse que el NPIV ID configurado en LUN sea el de el NPIV ID del target que le queremos configurar.

Capacidades o funcionalidades soportadas por NPIV:
– vMotion. La VM retiene el WWN virtual asignado. También se puede hacer vMotion de esa VM a un host con HBAs que no soporten NPIV. En este caso la VM utilizaría el WWN del nodo (el WWN de la HBA física). Perderíamos zonnings y maskings hechos a la NPIV_ID. Para poder hacer vMotion, el RDM tiene que estar en el mismo datastore que el fichero de configuración (.vmx) de la VM.
– Para storages activo/activo que soporten I/O concurrentes, los I/Os concurrentes de 2 puertos NPIV también están soportados.

Limitaciones:
– Es necesario que la HBA física esté conectada a un switch de fibra. Dicho de otra forma no soporta DAS.
– Cuando se clona una VM o se despliega una desde una plantilla, el WWN asignado no persiste.
– Storage vMotion no está soportado.
– Deshabilitar y volver a habilitar la funcionalidad de NPIV en un switch puede provocar un fallo en el link y que por tanto se detengan las I/Os…supongo que esto según como puede llegar a estropear datos.

Si queréis ver cómo se configura, os recomiendo este link. http://blogs.vmware.com/vsphere/2011/11/npiv-n-port-id-virtualization.html

Yo no lo puedo probar en mi lab que lo tengo todo por red…el tema fibra evidentemente se me iba de presupuesto 🙂

No obstante, estos son los pasos según la documentación de VMware.

Asignar WWNs a las VMs en el cliente Web de vSphere:
– Seleccionar y editar la VM.
– Dentro de VM Options, expandir las opciones de “Fibre Channel NPIV” para ver las opciones.
– Deseleccionar el checkbox “Temporarily Disable NPIV for this virtual machine” .
– Seleccionar “Generate new WWNs”.
– Especificar el número de WWNNs (World Wide Node Name o el que se asigna a la VM) y WWPNs (World Wide Port Name o los que se asignan a cada WWNN). Se necesitan un mínimo de 2 WWPN para soportar failover con NPIV.
– Dar de alta los WWNs en el switch y configurar los zoning/masking deseados.
– Asignar las LUNs deseadas a los WWNs creados.

En estos pasos no consta la creación previa de un disco de tipo RDM…recordad que es condición necesaria para poder utilizar NPIV. En este link veréis una guía que sí contempla los pasos incluidos la creación de la VM con el RDM http://goo.gl/rNUccr

El post de hoy ha sido particularmente corto pero no he tenido tiempo para más. Espero que os sea de utilidad. Si os gustan estos posts y creéis que a alguien más le pueden ser de utilidad, por favor compartid el enlace :).

Saludos,
Sebastián Greco

Bibliografía utilizada para escribir este post:

http://goo.gl/uDboJR
http://en.wikipedia.org/wiki/Fibre_Channel#Ports
http://en.wikipedia.org/wiki/NPIV
http://www.valcolabs.com/2012/05/12/objective-1-1-implement-and-manage-complex-storage-solutions/
http://blogs.vmware.com/vsphere/2011/11/npiv-n-port-id-virtualization.html
http://blog.scottlowe.org/2009/11/27/understanding-npiv-and-npv/

Yet Another VCAP-DCA post – Sección 1 – Objetivo 1.1 / Parte 2

Hola,

Segunda parte del estudio para la preparación del VCAP-DCA. En la parte 1 ya vimos la información correspondiente a Identificar tipos de RAID. Lamento no poner dibujitos y esas cosas 🙂 aunque en los links que se referencian hay dibujos de sobras! Recordad que esto es sólo una guía de estudio personal que comparto y que os recomiendo que además de leer este fantástico blog 😉 vayáis a las fuentes y esto sirva más bien a modo de resumen. Como dijo el filósofo “The Truth Is Out There”

Para seguir un mismo guión, y darle cierta consitencia a los posts iré dejando constancia de los conocimientos, habilidades y herramientas que hay en el blueprint del VCAP-DCA así como el contenido escrito por mi y los puntos a tratar en el post, enmarcados por asteriscos “*”.

Conocimiento:
Identificar tipos de RAID.
*Identificar tipos de HBA soportadas.*
*Identificar formatos de discos virtuales.*

Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como “re-firma” me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento “profil-driven”.
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.

Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV

Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop

Contenido:

Identificar tipos de HBA soportadas
Las HBA o Host Bus Adapter son tarjetas con conectores que van en nuestros servidores. Los hay de varios tipos:
– FC
– iSCSI
– SCSI
– SAS
– SATA
– eSATA
– etc

Normalmente, uno en el mundillo de la virtualización se refiere a HBA cuando está hablando de tarjetas con conectividad FC. Las de iSCSI aunque también son HBAs, uno se suele referir a ellas como “tarjetas de red” con o sin TCP offload.

Las HBAs pueden ser físicas o virtuales siendo las HBA físicas encargads de empaquetar los I/O según las reglas del protocolo en cuestión (FC, SCSI, NFS, etc) y de transmitir la señal a la SAN. Cuando las HBA son virtuales, sobra decir que quien se encarga de estas tareas es nuestro micro. Aquí está la diferencia entre las tarjetas con TCP offload y las que no lo tienen. Las tarjetas de red con TCP offload descargan al micro de todas estas tareas y son ellas quienes asumen la carga. Existen 3 tipos de offload siendo el más común entre las HBA iSCSI la de “HBA full offload” que también se encarga de las tareas típicas del “initiator”.

En cuanto a recomendaciones de buenas prácticas, he escuchado de todo. Hay quien sostiene que no se recomienda mezclar distintos tipos de HBA en un mismo HOST y hay quien sostiene que sí, puesto que en caso de tener algún problema con un driver de esa HBA afectará sólo a una…este “debate” lo dejo abierto aunque en la documentación oficial de VMware lo deja bastante claro “Do not mix FC HBAs from different vendors in a single host. Having different models of the same HBA is supported, but a single LUN cannot be accessed through two different HBA types, only through the same type.”

Sí que hay que tener en cuenta el número máximo de HBAs que se pueden tener en un host. En el documento de “Configuration Maximums” se ve claramente que hay un máximo de 8 HBAs y de 16 puertos.

Tras esta brevísima introducción a las HBAs, veamos ahora cuáles son los tipos de HBA soportados por vSphere y su identificación.

La lista sería interminable, basta con buscar en la HCL de VMware para darnos cuenta que “enumerarlas” no será una pregunta 🙂 Entonces…clasificarlas? Creo que la mejor opción sería limitar el estudio a las que aparecen en el espacio de nombres del comando “esxcli storage san”:

Available Namespaces:
fc IO Device Management operations to the FC adapters on the system.
fcoe IO Device Management operations to the FCoE adapters on the system.
iscsi IO Device Management operations to the Software iSCSI adapters on the system.
sas IO Device Management operations to the SAS adapters on the system.

Y los CNA? Son los “fcoe”. Creo que esta pequeña lista es un buen punto de referencia porque repito, sería absurdo conocerse la lista de HBAs en la HCL y no creo que algo parecido sea objeto de examen.

Empezaremos por las CNA. Cuando conectamos una y vSphere la ve, la reconocerá (si tenemos el driver instalado) y mostrará 1 FC (vmhba) por un lado y el componente ethernet (vmnic) por otro. Por tanto, aunque este tipo de HBA esté soportado de forma nativa, lo gestionaremos como si se tratase de 2 tipos de HBA distintos. Se verá también que aunque muestre “vmhba”, en la descripción mostrará que se trata de FCoE. Es importante desde un punto de vista de diseño, entender que la HBA sigue siendo una y que por tanto, networking de datos y de storage van por el mismo cable, invalidando para la mayoría de los casos el “datastore heartbeat” de HA.

Una nueva característica de vSphere 5.5 es la capacidad de gestionar NICs de hasta 40 Gb. Para FC, nos encontramos con el tope de 16Gb. También nuevo en la versión 5.5 que estos 16Gb sean end-to-end ya que en versiones anteriores de vSphere aunque los 16GB también se soportaban, había que “caparlos” a 8Gb. FCoE 10Gb e iSCSI 10Gb.

Para escoger un tipo de arquitectura u otro, normalmente el precio suele ser determinante. También es importante ver distancias y latencias…no sólo la cantidad de “Gb”. Otro factor a tener en cuenta es el “coste” de la encapsulación y las repercusiones de un tipo u otro de protocolo. El ejemplo más claro y el que más había que tener en cuenta hasta la aparición de las “ATS”, eran los locks a nivel de LUN de las reservas SCSI. Estas consideraciones simplemente las menciono y no entro en detalle porque no me quiero ir mucho de tema…el “conocimiento” requerido en este punto, a mi entender, ya estaría más que cubierto con la información aquí puesta.

Identificar formatos de discos virtuales

Este es un tema que me gusta bastante 🙂 y del cual tomo bastantes consideraciones a la hora de diseñar una o varias VMs.

Al igual que tantas cosas en virtualización, tener este conocimiento es genial ya que no solo aplica a VMware…con distintos nombres también aplica a otras tecnologías de virtualización. Para no estirar más el tema, los formatos de discos virtuales con vSphere son 3:
Thin
Thick EagerZero
Thick LazyZero

Thin
Este formato de disco permitirá hacer “overprovision” de amlacenamiento. Digamos que nos permite “mentirle” a la VM diciéndole que tiene un disco de un determinado tamaño (20GB por ejemplo) cuando en realidad sólo estará consumiendo el espacio que haya utilizado.
Aquí hay que hacer una pequeña pausa y explicar bien. Primero con un ejemplo el funcionamiento de Thin Privisioning de disco:
1 VM con un disco duro virtual de 20GB en formato Thin. Si le instalamos un Windows 7 y un par de programitas básicos, lo normal sería que consumiera de nuestro storage unos 5-6 GB. Aunuqe la VM crea que le hemos dado 20GB.
Puede darse el caso de que una VM que muestre desde el propio S.O. una ocupación de 6GB por ejemplo, esté ocupando los 20GB en nuestro storage. Esto se debe a que Thin Provisioning funciona de forma tal que una vez que cambia un bloque en el disco, el bloque queda “ocupado” con o sin información, pero queda ocupado. Por este motivo, inclusive borrando información desde la propia VM, el disco (.vmdk) no reducirá su tamaño. Por esto es importante entender que “defragmentar” un disco duro virtual en Thin Provisioning puede traer consecuencias negativas y que hacer un “Thin provisioning” para luego formatear (no con el formato rápido…con el otro lento que no usa nadie 🙂 )el disco no tiene sentido porque escribiremos en todos los sectores del mismo y el provisionamiento “Thin” perderá sentido.

Para reducir la ocupación de un disco en Thin Provisioning como el del ejemplo (6GB de información pero 20GB de ocupación en nuestro storage). VMware implementó con la ayuda de los fabricantes de storage las VAAI. Una de las funciones de estas VAAI es la de hacer un “Thin Provisioning Block Space Reclamation” mediante una “primitiva” denominada “UNMAP”. Mediante este mecanismo vSphere informa al storage que que cierta información se borró o movió de determinado .vmdk, una vez hecho esto, el storage sería capaz de volver a marcar como “vacío” ese espacio. Esta funcionalidad al principio era automática (vSphere 5.0). Como daba problemas VMware recomendó que se deshabilitara esta funcionalidad y luego mediante parches, ya se encargaron de deshabilitarla ellos. Cuando finalmente solucionaron los problemas, el automatizmo siguió deshabilitado y había que trabajar con vmkftools para reclamar el espacio. Actualmente en la versión 5.5 y aunque siga sin ser un mecanismo automático, se puede reclamar el espacio mediante esxcli.

esxcli storage vmfs unmap (-l si queremos especificar el nombre del volumen o -u si queremos especificar el uuid).

Si queréis más info al respecto de UNMAP, Jason Boche en su blog hace un muy buen trabajo explicándolo. http://goo.gl/JaqjoZ

La forma normalmente utilizada es la de hacer un “Storage vMotion” ya que esta operación también reduce el .vmdk a su ocupación más mínima posible.

Por suerte, ya desde la versión 5.0 se incluyen alertas que monitorizan el crecimiento de los discos en ThinProvisioning y alertan antes de que se llene un datastore. Además, otra mejora es que si actualmente se llena un datastore, se ponen en “pause” las máquinas que quieren escribir en el mismo y no pueden. Las otras siguen trabajando con normalidad. Esto antes no era así…si se llenaba un datastore se pausaban todas las VMs que estaban en él.

Thin Provisining tiene la ventaja también de que es un tipo de disco muy rápido de crear y la desventaja de que mientras se “expande”, dará un rendimiento más pobre a nuestra VM ya que además de escribir la información que queremos que se escriba en disco, se tendrán que actualizar los metadatos del mismo e inicializar el sector donde se quiere escribir la información. Este efecto desaparece una vez el .vmdk alcanza su tamaño máximo (en nuestro ejemplo de 20GB).

Thick Eager Zero
Los tipos de disco “Thick”, reservan el espacio con el que creamos el .vmdk en nuestro storage y lo muestran ocupado. Por tanto, si creamos un disco thick de 20GB, en nuestro storage veremos que hay 20GB menos disponibles. Que el disco sea “Eager Zero”, quiere decir que al momento de crear el .vmdk, vSphere escribirá 0s en todos los bloques de este disco para inicializarlo. Esto hace que su creación sea mucho más lenta (aunque ahora hay VAAIs que aceleran mucho el proceso) pero que su rendimiento sea óptimo. También evita sorpresas y sustos como los que uno puede tener con discos de tipo “thin” donde un crecimiento de los mismos sin control, puede ocasionar caídas a nivel de datastore.

Thick Lazy Zero
Para los entendidos en inglés, “lazy” que quiere decir perezoso y un disco “Lazy Zero” a diferencia de un “Eager Zero” NO escribe 0s en todos los bloques del mismo. Esto tiene un impacto directo en el tiempo que tarda en crearse este disco (será mucho más rápida su creación) y también en que no será tan rápido a la hora de “trabajar” como un disco “Eager Zero” puesto que al momento de escribir por primera vez en un bloque, deberá inicializarlo.

Un tema interesante por ver pero que queda fuera de este estudio, es si utilizar Thin Provisioning desde vSphere, desde el Storage o desde ambos. En este sentido, Cormac Hogan, gurú en temas de storages y además un tipo de lo más simpático, escribió en su blog un artículo más que interesante y casi de lectura obligada http://blogs.vmware.com/vsphere/2012/03/thin-provisioning-whats-the-scoop.html

Bibliografía utilizada para este post:
http://en.wikipedia.org/wiki/Host_adapter
http://en.wikipedia.org/wiki/TCP_offload_engine
http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Storage-Technical-Whitepaper.pdf
http://goo.gl/gj9vJ4
http://goo.gl/cdY5E1
http://goo.gl/ll0689
http://blogs.vmware.com/vsphere/2013/09/a-summary-of-whats-new-in-vsphere-5-5.html
http://blogs.vmware.com/vsphere/tag/iscsi
http://www.mikelaverick.com/2013/09/vmworld-2013-whats-new-in-vsphere5-5-storage/
http://blogs.vmware.com/vsphere/2011/12/vmwares-software-fcoe-adapter.html
http://blogs.vmware.com/vsphere/2011/12/vmwares-software-fcoe-adapter.html
http://blogs.vmware.com/vsphere/2012/03/thin-provisioning-whats-the-scoop.html
http://goo.gl/JaqjoZ

Hasta aquí el post de hoy. Espero que os haya gustado. Tened en cuenta que esto es un guía de estudio y que en todos los aspectos me considero un estudiante por lo que si tenéis algo que queráis aportar, será más que bienvenida vuestra participación 🙂

Saludos,
Sebastián Greco

Yet Another VCAP-DCA post – Sección 1 – Objetivo 1.1 / Parte 1

Hola,

Empieza mi aventura para obtener el VCAP-DCA…a ver si llego! Puesto que normalmente tomo notas de lo que estudio y la mejor forma de aprender para mi es “hacerlo con cabeza de luego tener que explicarlo”, intentaré en la medida de lo posible, ir agregando posts con los distintos objetivos del blueprint. Como mi amigo @pipoe2h me recomendó por twitter: “blueprint y ármate un laboratorio con 2 hosts y vCenter y a seguir el blueprint” 🙂 Ya que sabe de lo que habla y además lo hace desde la experiencia puesto que tiene el VCAP-DCA y el VCAP-DCD…habrá que hacerle caso 🙂

No entraré en detalle de las distintas certificaciones que VMware tiene disponibles ni dónde entra el VCAP-DCA de vSphere. Si alguien quiere info al respecto, este es el link

http://mylearn.vmware.com/portals/certification/

Al lío pues y a ver qué sale.

Intentaré ir haciendo entradas en el blog según los objetivos del blueprint del examen. Para obtener el blueprint hay que registrarse (gratuito) y descargarlo desde el link correspondiente en la “Página oficial de VCAP-DCA”.

Nota: Esto es parte de mi estudio personal en el cual me valgo de recursos oficiales y de la ayuda que ponen a disposición en la web otros profesionales. Referenciaré cada uno de los recursos utilizados por mi o bien en “links de interés” o dentro del mismo cuerpo de esta guía. No invento nada y posiblemente no aporte nada nuevo salvo mi forma de entender y explicar algunas cosas. De todas formas, espero que este material de estudio le sea de utilidad a alguien más 🙂

Sección 1 – Objetivo 1.1 – Implementar y gestionar soluciones complejas de almacenamiento

Conocimiento:
*Identificar tipos de RAID.*
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.

Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como “re-firma” me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento “profil-driven”.
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.

Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV

Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop

Contenido:

Identificar tipos de RAID
Un RAID o redundant array of independent disks es una tecnología que permite agrupar 2 o más discos duros para obtener distintos niveles de rendimiento y/o redundancia (RAID 0 no ofrece redundancia). Escoger correctamente el tipo de RAID es imprescindible en el momento de diseñar una infraestructura ya que no solo afectará al rendimiento de la misma sino que también tiene una repercusión directa en los costes. Muy simplificado, esto sería: “Más rendimiento y más redundancia implican más o MUCHOS más discos”.

Hay varios tipos de niveles de RAID y como es el objetivo en este punto, la idea es poder identificarlos.
Digamos que existen niveles de RAID que no merece la pena estudiar puesto que a efectos prácticos no se utilizan: RAID 2 y RAID 3 (obsoletos), RAID 4 muy raro de ver salvo en NetApp donde es más normal ver “RAID DP” (hace mucha gracia en los concursos públicos donde “no se pueden mencionar fabricantes” que describan una cabina con “RAID DP”…vamos, que no se nota! 😛 ) RAID DP así como otros tipos de RAID específicos de fabricantes (Hadoop, SHR, etc) tampoco los estudiaremos. RAIDs que sí son estandard pero que es difícil encontrar como los que mezclan un tipo de RAID con el RAID 0, también conocidos como “nested”, tampoco los veremos a excepción de RAID 10 (RAID 0 y RAID 1). Lo importante de este último tipo de RAID es que combina lo mejor y peor de 2 tipos de RAID en cuanto a rendimiento, capacidad y redundancia.
También es importante entender que RAID se puede hacer tanto por hardware como por software. Como nota personal, ojo a las descripciones de los fabricantes de servidores ya que muchas veces las controladoras que soportan RAIDs y que vienen integradas en placa, soportan RAIDs pero por software, algo que para un host con vSphere no vale si es donde se quiere instalar ESXi. Asimismo, muchos tipos de RAID, necesitarán que se añadan componentes como baterías para las caché de las controladoras, etc.

Para todos los RAIDs veremos:
Penalización escritura: Cantidad de IOPS que son necesarias por cada operación de escritura. Menos es mejor.
Tolerancia a fallos: Cantidad de discos que el RAID se puede permitir perder. Más es mejor.
Nº mín. de discos: Cantidad mínima de discos necesarios para formar el RAID.
Nº de discos de redundancia: Cantidad de discos que utilizan su capacidad para mantener información redundante. La capacidad de estos discos, no suman a la capacidad “utilizable” por el usuario del volumen.
Aplicaciones típicas: Casos en los que se suele ver el tipo de RAID en cuestión.

Vale la pena destacar aquí para no tener que hacerlo en cada tipo de RAID, que si uno mezcla distintos tipos de HDD en un mismo RAID, cuando se tenga que leer/escribir información en el disco lento, el rendimiento será peor. Por tanto, un RAID puede llegar a ser tan bueno como su disco más malo.

Como último punto antes de ir a la descripción de cada tipo de RAID, creo importante entender que en términos de almacenamiento: latencia, buffers, interfaces, tipo de IOPS (lectura o escritura), tipos y cantidad de discos, procesadores de almacenamiento y una lista interminable de elementos más, determinan un funcionamiento óptimo o poco óptimo de nuestro almacenamiento…no todo se reduce en tipos de RAID.

RAID 0
Es un tipo de RAID que no ofrece redundancia. La forma más fácil de explicarlo es que se trata de una forma de hacer que varios discos sean visibles a nivel de S.O. como si fueran un único disco. Lo que hace es distribuir la información en 2 o más discos (todos los que formen el RAID). Si se agregan a un mismo RAID 0 discos de distintas capacidades, sumarán al RAID 0 la capacidad igual a la del disco más pequeño. Por esto, si hiciéramos un RAID 0 con 1 disco de 73GB y otro disco de 600GB, tendríamos un RAID 0 con 146GB.
En principio es un tipo de RAID que se utiliza o bien para disponer de un “disco” grande donde se suma de la capacidad de los discos que forman el, o para aumentar la performance de nuestro almacenamiento. Aunque según el tipo de información y la forma en que es accedida, esta mejora en la performance no siempre es perceptible ni real. El handicap más importante en este RAID es que basta que falle un (1) disco del RAID para que perdamos la información de todos los discos (existen herramientas que permiten recuperar parte de la información).

P. escritura: 1
Tolerancia a fallos: 0
Nº mín. de discos: 2
Nº de discos de redundancia: 0
Aplicaciones típicas: Workstations de diseñadores gráficos/Autocad, logging, equipos dedicados a la edición de video…también a los gamers les suele gustar este tipo de RAID 🙂

RAID 1
También conocido como “mirroring”, este tipo de RAID “replica” la información de un disco o conjunto de discos (según lo que la controladora permita hacer) en todos los discos que forman el RAID. Como buena práctica general, lo ideal sería tener un disco o dataset en controladoras diferentes y que estas soporten hacer lecturas en paralelo para obtener mayor rendimiento en las lecturas.

P. escritura: 2
Tolerancia a fallos: n-1 o dicho de otra forma, “un dataset tiene que quedar en pie”. Para el caso de un RAID 1 con 2 HDD, tolera que falle un disco. Si hay un RAID 1 con 3 HDD, tolera que fallen 2 discos y así.
Nº mín. de discos: 2
Nº de discos de redundancia: Al menos 50% del RAID.
Aplicaciones típicas: Bases de datos transaccionales, discos de sistema.

RAID 5
Este tipo de RAID es el más extendido ya que ofrece tolerancia a fallos a un bajo coste. También conocido como “distribuido con paridad” (sólo los muy frikis utilizan este término), este RAID distribuye la información de paridad (la que utiliza para reconstruir información en caso de pérdida de algún disco) entre todos los discos del RAID. Para generar esta información de paridad, RAID 5 debe realizar cálculos que son los que hacen que al escribir, haya una penalización tan alta. Es más, si se somete a un RAID 5 a operaciones de escrituras múltiples y pequeñas (más pequeñas que su tamaño de stripe), se sufrirá mucho más de esta penalización puesto que aumentará considerablemente el número de cálculos que se deban realizar.
A tener especial cuidado con este tipo de RAID en caso de cortes de luz, cuelgues en el sistema que está accediendo al RAID, etc. Si bien existen medidas que nos protegen de errores como los SAIs de las cabinas que permiten que lo que está en caché se escriba a disco, etc. existe el riesgo de que se pierda la consistencia en la paridad…de esta pérdida de consistencia no seremos conscientes hasta que se pierda un disco y se tenga que reconstruir la información. Por eso es importante monitorizar las alarmas de la cabina y reparar cualquier error que aparezca.

P. escritura: 4
Tolerancia a fallos: 1
Nº mín. de discos: 3
Nº de discos de redundancia: “0” La redundancia se distribuye entre todos los discos del RAID.
Aplicaciones típicas: Backup a disco, archiving, discos con ficheros (file servers)…también es “tipical spanish” utilizarlos para meter toda la infraestructura virtual sobre ellos por tema costes, aunque desde un punto de vista idealista y purista, no es lo recomendado.

RAID 6
Al igual que RAID 5, se utiliza un sistema de paridad distribuido simplemente que en este caso es doble. Digamos que almacena el doble de información de paridad en cada disco que un RAID 5. Esto ofrece ventajas como una mayor tolerancia a fallos (2 discos) inclusive durante operaciones de reconstrucción de un disco dañado aunque la penalización de escritura sea mayor (dije que no iba a hablar pero hay que mencionarlo, RAID DP es una especie de RAID 6 pero que es mucho más rápido gracias a una tecnología patentada denominada WAFL).

P. escritura: 6
Tolerancia a fallos: 2
Nº mín. de discos: 4
Nº de discos de redundancia: “0”. La redundancia se distribuye entre todos los discos del RAID.
Aplicaciones típicas: Aplicaciones críticas, presentación de storage “grande” a servidores.

RAID 10
También conocido como RAID 1+0, es uno de los RAIDs tipo “nested” más utilizados, sino el que más. Básicamente combina el RAID 1 con RAID 0 de la siguiente forma conocida como “división de espejos”:
Exisitirá un único RAID 0 formado por RAIDs 1 en lugar de discos “sueltos”. Parecido aunque no lo mismo que un RAID 01 del cual no se habla en este documento. No se han de confundir aunque se preste a la confusión.

P. escritura: 2
Tolerancia a fallos: Un disco por RAID 1 tiene que estar en pie.
Nº mín. de discos: 4
Nº de discos de redundancia: Al menos 50% del RAID.
Aplicaciones típicas: Bases de datos con mucha carga, servidores de aplicaciones con mucha carga.

Bueno, como esto está haciendo más largo de lo que me esperaba, “partiré” este objetivo en más de un post.

Aquí os dejo la bibliografía utilizada por mi para escribir lo que escribí y “no morir en el intento” 🙂

Links de interés:
Página oficial de VCAP-DCA – http://goo.gl/SHpUkS
http://wintelguy.com/raidcalc.pl

Guías de estudio:
http://wahlnetwork.com/2012/07/02/the-vcap5-dca-study-sheet/
http://www.vexperienced.co.uk/vcap5-dca/
http://thesaffageek.co.uk/vsphere-5-study-resources/vcap5-dca-objectives/
http://www.virtuallanger.com/vcap-dca-5/
http://www.valcolabs.com/vcap5-dca/
http://thefoglite.com/vcap-dca5-objective/
http://paulgrevink.wordpress.com/the-vcap5-dca-diaries/
http://www.seancrookston.com/blog/vcap-dca/

Bibliografía utilizada para este post (además de las ya mencionadas guías de estudio y links a docs de VMware):
http://en.wikipedia.org/wiki/RAID
http://en.wikipedia.org/wiki/Standard_RAID_levels
http://en.wikipedia.org/wiki/IOPS
http://es.wikipedia.org/wiki/RAID
http://www.yonahruss.com/architecture/raid-10-vs-raid-5-performance-cost-space-and-ha.html
http://shanibasha.blogspot.com.es/2011/02/all-about-iops-and-write-penalty.html
http://www.accs.com/p_and_p/RAID/BasicRAID.html
http://www.enhance-tech.com/press/raid-comparison-and-storage-systems.html
http://www.datarecovery.net/articles/raid-level-comparsion.html
http://www.adaptec.com/en-us/_common/compatibility/_education/raid_level_compar_wp.htm
http://www.netapp.com/us/communities/tech-ontap/tot-back-to-basics-raid-dp-1110.aspx
http://storageioblog.com/raid-and-iops-and-io-observations/
http://theithollow.com/2012/03/understanding-raid-penalty/
http://www.synology.com/en-us/support/tutorials/512
http://wintelguy.com/2013/20130406_disk_perf.html
http://wintelguy.com/raidperf.pl

Hasta la próxima!
Sebastián Greco