Chubascos Blog

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

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

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: