Storage

vFlash Deepdive

Que tal gente, continuando con los artículos sobre lo nuevo que nos trajo VMworld (muchas cosas además de vSphere) es turno de meternos de lleno a lo que nos ofrece VMware con vFlash. Esta nueva funcionalidad nos permite acelerar operaciones de lectura a nivel de VMDK de máquina virtual, por lo cual dependiendo del caso de uso y tipo de aplicación puede ser de bastante interesante.

Debemos comenzar por definir algunos términos que estaremos manejando en el articulo:

  • Memoria Flash – este tipo de memoria no es volátil (a diferencia de la memoria RAM) y es de tipo electrónica por lo que no maneja ninguna parte móvil se tienen dos tipos principales de memoria flash, NOR y NAND siendo la última la mas común y utilizada ampliamente hoy en día.
  • SSDs – Tomando un fragmento de mi articulo “vSAN Deepdive” :

    “Solid State Drive”, este tipo de disco a diferencia del tradicional o mecánico no tiene partes móviles lo que permite tener tiempos de acceso mucho mas rápidos y menor latencia. Si lo comparamos con una memoria USB estos dos comparten algo en común, el hecho que ambos almacenan información en memoria flash, claramente los discos de estado solido tienen una estructura semejante a un disco tradicional y son mucho mas sofisticados que una simple memoria USB. La  cantidad de IOPS en un SSD se encuentra en el orden de los miles y a diferencia de un disco mecánico estos son mucho mejores en operaciones de lectura que en escritura, esto debido a que no se puede sobre escribir información sin que se ejecute un proceso llamado “garbage collection” lo que permite la escritura en esa ubicación cosa que no sucede en un disco mecánico de cualquier manera generalmente tienen mejor rendimiento que los discos mecánicos. Existen distintos tipos de SSDs, tenemos SSDs con interfaz SATA, SAS o tarjetas PCIe que contienen SSD o memoria Flash para poder acelerar operaciones de I/O a nivel del servidor. Cabe destacar que este pequeño intro a los SSDs no es tantito la vista completa de como trabaja un SSD, recuerden investigar mas sobre el tema.

  • Cache –el cache es memoria designada específicamente para la aceleración y almacenamiento temporal de operaciones de I/O, puede ser memoria RAM o disco (SSD) (hablando de operaciones a nivel de almacenamiento, claramente el término cache tiene distintos usos), en el caso de vFlash nos apoya a poder acelerar operaciones de lectura unicamente, esto debido a que se trata de cache “write through” por lo que no puede reducir los tiempos de respuesta en escritura como lo haría el cache de tipo “writeback”. vFlash en el espacio designado almacena los bloques de información que son accedidos con mayor intensidad, permitiendo así servir a las operaciones de lectura desde cache lo cual evita una consulta de estos bloques en el almacenamiento o backend (donde se encuentran los discos). Para tener una mejor idea de como trabaja el cache a nivel de almacenamiento (desde una perspectiva general y no especifica para algún fabricante) les recomiendo leer mi articulo “EMCISA – Intelligent Storage System”.
  • VFFS se trata de un sistema de archivos que deriva del afamado VMFS, en este caso VFFS esta pensado para agrupar todos los discos de estado solido SSD como una única entidad o grupo de recursos y optimizado para poder trabajar con este tipo de disco.

¿Que es vFlash?

Lo se, bastantes términos e introducción pero debemos sentar las bases para poder platicar de manera mas profunda sobre la funcionalidad… vFlash es una solución 100% basada en el hipervisor, es decir, existe como parte del core del hipervisor (ESXi) por lo que no depende de ningún appliance virtual u otro enfoque, nos permite acelerar operaciones de lecturas a nivel de VMDK de VM a través de SSDs locales que hacen las veces de cache y sin necesidad que estos sean exactamente iguales en cuanto a modelo, tamaños y demás. El administrador de la infraestructura deberá configurar el pool de recursos de vFlash (que estará construyendo el sistema de archivos VFFS) a partir de discos de estado solido conectados directamente a los servidores ESXi, esto lo podemos notar en la siguiente imagen:

SSDVFFS Aquí podemos notar que en mi laboratorio seleccione un SSD de 55GB (en realidad son 60GB) para ser formar parte de VFFS, una vez que dejamos listo el o los distintos discos de estado solido que conformaran nuestro pool de recursos solo es cuestión de repartir de manera individual este espacio disponible para cada VMDK de VM, es importante saber que nosotros tenemos la opción incluso de solo acelerar un disco de una VM que tenga mas discos o VMDKs esto nos da la posibilidad de tener un control mucho mas granular en la entrega de este cache basándonos en el perfil de I/O que presenta nuestras VMs. Una herramienta que nos puede ayudar en poder conocer que perfil de I/O manejan nuestras VMs es el ya confiable y ampliamente utilzado vscsiStats donde podemos conocer todo tipo de información como el tamaño de operaciones, latencia,entre otras, aquí les dejo algunos artículos de mi blog donde pueden leer mas sobre vscsiStats:

VCAP – Sección 3 – utilizar herramientas avanzadas para el monitoreo de performance

VCAP – Sección 6 – Troubleshooting de almacenamiento

Paso-a-paso – vscsiStats

Es importante conocer el patrón de I/O que presentan nuestras VMs debido a que en la configuración de vFlash a nivel de VDMK definiremos tamaño del cache y bloque del mismo (lo mejor es que sea el mismo que el utilizado por la aplicación/servicio):

vFlashconf

En cuanto a requerimientos para poder habilitar este cache a nivel del VMDK de nuestras VMs solo tenemos los siguientes:

  • VM compatibility (Hardware virtual) versión 10
  • SSD local en el host ESXi

La configuración de esta funcionalidad es únicamente a través del vSphere Web client, al igual que todas las funcionalidades nuevas que se han ido agregando a vSphere solo están y estarán disponibles desde el cliente basado en web. Una vez configurado el cache este es transparente para la VM pero tiene ciertas consideraciones de diseño que estaremos revisando más adelante.

Arquitectura

vFlash introdujo algunos nuevos componentes a ESXi y de igual manera al stack de I/O de la VM (solo en caso del VMDK que esta habilitado con vFlash) se tienen dos componentes nuevos:

  • vFlash infrastructure – aquí tenemos la librería (vFlashlib) con la cual trabaja el vmx para poder interactuar con el cache, de igual manera se encuentra un módulo de hipervisor interesante llamado FDS (File System Switch)  que esta colocado entre el adaptador vSCSI de la VM y el módulo de cache del hipervisor que permite la abstracción de los distintos SSDs que constituyen el pool de recursos de tal manera que se tiene una interacción común aún teniendo distintos dispositivos y por último tenemos el sistema de archivos VFFS como parte de este “vFlash infrastructure”
  • vFlash cache module – módulo del hipervisor encargado de manejar el cache y la interacción con el VFFS, este cache es transparente para VMs y aplicaciones.

El flujo  de información se vería mas o menos de esta manera:

flujovflashCada vez que se enciende una VM se crea su cache, es decir, este no es persistente a reincios y demás, vFlashlib lo crea una vez que el proceso de VM (VMM) comienza, el pool de recursos que a su vez construye el sistema de archivos VFFS es un sistema de archivos que existe a todo momento e incluso tiene un punto de montaje en /vmfs/devices/vflash/.

Interoperabilidad

En el momento que consideramos integrar vFlash en nuestros diseños de infraestructura la primera pregunta sería ¿Como afecta y/o como trabaja con otras funcionalidades como HA, vMotion,DRS, etc?, vamos a revisar cada una de las funcionalidades mas relevantes de vSphere:

  • vMotion, Storage vMotion y XvMotion (enhanced vMotion) todas estas operaciones son soportadas, nosotros como administradores decidiremos si es que queremos migrar el cache o recrearlo en el host destino, para el caso en especifico de Storage vMotion no tiene impacto esto debido a que no migramos de host. Claramente la decisión de migrar o no el cache impactara en la carga que se tendrá a nivel de red y el tiempo de migración debido a que se deberá copiar el cache en uso y si tomamos la decisión de migrar la VM sin su cache se tendrá un impacto en el rendimiento debido a que el cache será reconstruido con el tiempo (se deberá esperar tiempo para que se tenga información “caliente” en el cache”. Podemos ver en la imagen la migración con vFlash activado:

opcionesmigracionvflash

  • HA claramente en el momento de tener un evento de failover al reiniciarse de manera forzosa la VM en otro servidor del cluster el cache no viaja con ella y deberá ser reconstruido. Acá entra una decisión importante en cuanto a diseño se refiere y es el control de admisión, es decir, si tenemos nuestros SSDs 100% utilizados en cada host o no existen recursos suficientes de vFlash en el momento de requerir un reinicio de VM por un evento de HA esta simplemente no se reiniciará en otro host, por lo que debemos considerar cierto espacio libre en nuestros SSDs para eventos de HA.
  • DRS – DRS funciona sin ningún problema con vFlash, en este caso estará ocupado XvMotion para migrar la VM y copiar a la vez el cache. Aquí entramos a una consideración de diseño similar al caso de HA, y básicamente es que DRS al estar realizando el análisis del cluster para poder determinar recomendaciones y así realizar migraciones para el balanceo del cluster (dependiendo claramente de el nivel de automatización) sino encuentra los recursos suficientes de manera “continua” o en un mismo host (no fragmentados entre todo el cluster las VMs no serán candidatas a poderse migrar ya que no se puede satisfacer la cantidad de vFlash entregado.

Consideraciones extra

Acá podemos encontrar algunas consideraciones y limites de vFlash en esta versión:

  • El tamaño máximo de SSD soportado es de 4TB
  • Se soportan hasta 8 SSDs por VFFS lo cual nos da un total de 32TB para VFFS
  • Solo se soporta un VFFS por host ESXi
  • Se tiene un máximo de 400GB de cache por VM con un tamaño mínimo de bloque de 1KB hasta 1024KB
  • No se soporta SSDs compartidos (solo una partición)
  • No se soporta SSDs remotos
  • No se soporta FT
  • No se puede compartir un SSD entre vSAN y vFlash

Casos de uso

Podemos ver que esta versión inicial de vFlash puede cubrir ciertos requerimientos de aplicaciones, en general aplicaciones con muchas lecturas. vFlash nos permite agregar mayor cantidad de aplicaciones críticas, pero un caso de uso que a mi me llama mucho la atención es VDI, y ¿Porque VDI? pues es simple, podemos descargar bastantes operaciones de I/O (lecturas) del almacenamiento y que estas sean servidas a partir del mismo SSD local (mejorando drásticamente el rendimiento de dichas operaciones) esto se vería bastante claro en la carga que recibe la replica si estuviéramos hablando de horizon view.  En este punto Horizon View 5.2 no esta soportado para  vFlash, aunque técnicamente no tendría problema para funcionar esto no será soportado oficialmente por servicios de soporte VMware (Global Support Services, GSS).

Conclusión

vFlash nos permite reducir la carga a nivel de nuestro almacenamiento centralizado (sería bueno incluso hablar de vSAN :D) a través de disco “barato” porque al final del día es mas costoso adquirir mayor cantidad de IOPS a nivel de una SAN/NAS que entregándolos a partir de disco SSD local. Existen distintas soluciones allá afuera que ofrecen este tipo de funcionalidades con otras ventajas, como por ejemplo, PernixData FVP y Proximal Data AutoCache

Estén atentos a mis siguientes artículos, donde estaré cubriendo el monitoreo de vFlash, a través de linea de comando y de los distintos indicadores de rendimiento que fueron agregados a nivel de vCenter.

De igual manera les recomiendo leer los links que estaré actualizando en este articulo sobre vFlash:

FAQs por Duncan Epping (Yellow Bricks) Frequently asked questions about vSphere Flash Read Cache

VSAN Deepdive

Que tal gente el día de hoy les voy a hablar sobre vSAN, una tecnología que fue anunciada en VMworld 2013 SFO. vSAN en conjunto con NSX (sobre el cual estaremos hablando en otro artículo) y vCHS fueron de los anuncios mas relevantes y disruptivos que se tuvieron en VMworld claramente también tenemos una versión nueva de vSphere (de la cual estaremos hablando de igual manera en otro articulo mas adelante)vCD, etc, y todo esto llega a marcar nuevamente el liderato de VMware en muchos aspectos del Software Defined Data Center.  vSAN cubre la automatización y “abstracción” del almacenamiento de tal manera que nos permite tener arquitecturas distribuidas que no solo dependan de almacenamiento SAN o NAS, sino que puedan hacer uso de los recursos locales de disco en los servidores que constituyen el cluster y aún así mantener los SLAs definidos para cada una de las aplicaciones y/o servicios que alojamos dentro de el almacenamiento presentado a partir de recursos locales con un excelente rendimiento que nos permite albergar aplicaciones demandantes y críticas para el negocio.

Es importante recordar que vSAN esta disponible como beta público, todavía no es GA, podemos probar vSAN aplicando para el beta público en la siguiente liga:

http://www.vmware.com/vsan-beta-register

Conceptos básicos

Antes de comenzar a hablar de vSAN vamos a darnos algo de tiempo para explicar algunos conceptos básicos para que todas las audiencias entiendan perfectamente bien de lo que hablamos.

Con la llegada de vSAN debemos manejar y entender los siguientes términos:

  • SSD – “Solid State Drive”, este tipo de disco a diferencia del tradicional o mecánico no tiene partes móviles lo que permite tener tiempos de acceso mucho mas rápidos y menor latencia. Si lo comparamos con una memoria USB estos dos comparten algo en común, el hecho que ambos almacenan información en memoria flash, claramente los discos de estado solido tienen una estructura semejante a un disco tradicional y son mucho mas sofisticados que una simple memoria USB. La  cantidad de IOPS en un SSD se encuentra en el orden de los miles y a diferencia de un disco mecánico estos son mucho mejores en operaciones de lectura que en escritura, esto debido a que no se puede sobre escribir información sin que se ejecute un proceso llamado “garbage collection” lo que permite la escritura en esa ubicación cosa que no sucede en un disco mecánico de cualquier manera generalmente tienen mejor rendimiento que los discos mecánicos. Existen distintos tipos de SSDs, tenemos SSDs con interfaz SATA, SAS o tarjetas PCIe que contienen SSD o memoria Flash para poder acelerar operaciones de I/O a nivel del servidor. Cabe destacar que este pequeño intro a los SSDs no es tantito la vista completa de como trabaja un SSD, recuerden investigar mas sobre el tema.
  • Disk Group – en el momento de habilitar vSAN como funcionalidad del cluster tenemos que crear algo que se le conoce como “Disk Group”, básicamente este es un conjunto de HDDs y SSDs los cuales son presentados al cluster, como espacio en el caso de los HDDs y como cache (lecturas) y buffering (escrituras) en el caso de los SSDs. diskgroupvsanLos discos de estado solido están pensados para ofrecer cache y buffering enfrente de los discos mecánicos, es importante notar que no todos los hosts ESXi que participan en un cluster de vSAN necesitan presentar disk groups aunque si es necesario contar con al menos 3 servidores ESXi que entreguen espacio al cluster mientras que los otros 5 (tomando como base el máximo de 8 hosts ESXi en un cluster de vSAN) podrían estar teniendo acceso a dicho datastore sin necesidad de ofrecer espacio. Se recomienda una proporción de 1:10 hablando de SSDs a HDDs pero esto varia mucho dependiendo que tipo de SSD es el que estaremos utilizando. Para mejorar el rendimiento se utiliza RAID0 y dependiendo de la cantidad de “stripes” que definamos será la cantidad de discos duros a través de los cuales se distribuya la información para tener un mejor rendimiento (esto lo estaremos tocando mas adelante).
  • VM Storage Profiles – vSAN requiere de perfiles de almacenamiento para nuestras VMs, esto para poder asegurar y mantener los SLAs que distintas aplicaciones y/o servicios que vivan en ellas requieren. vSAN provee información a través de VASA, por lo que en el momento de crear un perfil de almacenamiento para nuestras VMs podemos seleccionar el proveedor VASA de vSAN y así seleccionar las distintas opciones o capacidades que nos ofrece este proveedorvmstorageprofile. En la imagen podemos notar las distintas capacidades que nos ofrece este proveedor VASA (vSAN) podemos definir disponibilidad, rendimiento etc. Es importante saber que no es 100% necesario crear perfiles de VMs para poder almacenar VMs en el datastore presentado por vSAN, esto es para poder gozar de las capacidades avanzadas que tiene este almacenamiento, mas adelante estaremos revisando cada una de las opciones y cuando debemos utilizarlas.

Arquitectura

Llego el momento de hablar sobre la arquitectura de esta nueva manera presentar almacenamiento en vSphere, comencemos revisando los pre requisitos para poder habilitar y utilizar vSAN en nuestro cluster:

  • Controladora RAID SAS- con modo “pass thru” o “hba”, es importante notar que la controladora debe de ser SAS no SATA, debido a que esta controladora puede manejar tanto interfaces SAS como SATA, puede que una controladora SATA nos permita crear el cluster pero esto no esta soportado. Se requiere tener el modo “pass thru” o “hba” en la controladora para que los discos que están siendo controlados sean accedidos directamente por el host ESXi sin RAID, para que vSAN se encargue de entregar la protección de los datos y rendimiento a nivel de software.
  • Red a 10Gbe – es importante notar que necesitamos un backbone de red para vSAN a 10Gbe esto debido a que 1Gbe puede convertirse en un cuello de botella, si lo comparamos contra soluciones que se encuentran en el mercado donde estamos hablando de “scale-out” estas generalmente requieren infiniband y/o 10Gbe, en el caso de vSAN solo se tiene el requerimiento de 10Gbe.
  • Discos SAS/SATA – Como lo comenté se requiere una proporción de 1:10 de SSDs a HDDs, estos pueden ser SAS o SATA dependiendo de los casos de uso en especifico estaremos determinando un diseño en especifico que cubra con las necesidades, sea SATA o SAS.

Una vez que entendimos los requerimientos básicos vamos a revisar la arquitectura:

vsanarchconceptual

Como podemos notar vSAN nos permite crear un sistema de archivos distribuido a partir de almacenamiento local de los servidores ESXi que participan en el cluster, en el momento que habilitamos vSAN y creamos nuestros Disk groups para definir que espacio y disco de estado solido estarán siendo utilizados para almacenar los datos se crea un sistema de archivos en el cual todos los servidores que pertenecen al cluster pueden acceder sin ningún problema, lo interesante esta en el funcionamiento “por debajo” o mas a fondo del sistema de archivos, me parece que esa imagen la estarán viendo en muchas presentaciones, webinars y demás, vamos a revisar a fondo como trabaja vSAN.

vSAN crea un sistema de archivos que ofrece protección de datos y rendimiento a través de una arquitectura de tipo “RAIN” o Redundant Array of Independent Nodes, esto permite que la capa de software (en este caso vSAN) se encargue de entregar todas las capacidades que un RAID estaría ofreciendo, lo interesante es que esto se realiza a través de nodos físicos (esxi) permitiendo tener rendimiento y protección de datos aún cuando un host ESXi no este disponible (claramente su almacenamiento local tampoco).

vsancmmds

Como podemos notar en la imagen, se requiere de una interfaz de vmkernel para la comunicación de vSAN, esta comunicación sucede a través de RDT o “Reliable Datagram Transport Protocol” que esta pensado para el envío de datagramas con una cantidad de información bastante grande de manera confiable, manteniendo prioridad en los paquetes (cosa que muchas veces en un ambiente TCP puede no asegurarse) y trabajando de la mano con el servicio de cluster que maneja vSAN llamado CMMDS “Cluster Monitoring, Membership and Directory Services” para poder determinar que conexiones y “paths” o caminos utilizar para el envio de esta información.

vmkernelvSAN

El servicio CMMDS se encarga de descubrir y mantener el listado de los nodos que pertenecen al cluster (hosts ESXi), dispositivos de almacenamiento, redes, etc. De igual manera almacena el metadata del sistema de archivos donde se encuentra información de la topología del sistema RAIN y políticas aplicas, por último detecta posibles fallas en los nodos. Algo interesante de este servicio es que tenemos un nodo del cluster ejecutando el rol “primario” mientras que otro tendrá el rol de “respaldo o backup” en el caso de tener problemas en la red o que un nodo se caiga y que este sea un nodo primario o de backup se sigue el mismo algoritmo de selección que maneja FDM (Fault Domain Manager, HA) para seleccionar sus nodos y sus roles (primario, respaldo o backup y “agent”).

Funcionamiento del sistema de archivos

Algo muy importante y que fue algo “dificil” entender para mi es que vSAN a diferencia de otros sistemas de archivos que VMware utiliza se basa en objetos, por lo que las VMs, discos, snapshots y demás son considerados “objetos”,  la manera de como se escribe a este sistema de archivos es bastante interesante y se define en gran parte por el perfil de almacenamiento de VM así que vamos a ver un caso práctico para poder entender todas las opciones que nos brinda el proveedor VASA de vSAN:

  1. Se requiere crear una VM, esta vm cuenta con ciertos SLAs definidos, Alta disponibilidad de tipo N+1,un requerimiento de 900 IOPS y que el espacio sea entregado de manera “thick”, para esto el administrador crea un perfil de VM que cumple con este SLA:vmstorageprofileejemplo
    Podemos notar en la imagen que se tienen los siguientes atributos o capacidades en el Perfil de almacenamiento de VM:*Number of disks stripes per object – aquí definimos entre cuantos discos se estará realizando un stripe del objeto (VM), tomando como el ejemplo , al requerir 900 IOPS con  base que nuestros discos nos ofrecen 150 IOPS necesitamos utilizar 6 discos para completar este requerimiento que forma parte del SLA. Se recomienda que se deje el valor por defecto de “1” esto pensando en que el cache de SSD podrá entregar los IOPS requeridos, en el momento que las lecturas o el “working set” no estén en cache (cache miss) ahí sería cuando estas estarían siendo entregadas a partir de los HDDs, todas las escrituras son servidas por HDDs de cualquier manera (aunque se realiza un buffer de estas en el SSD). Para motivos de este articulo no modifiqué el valor del stripe a 6, lo deje en el valor por defecto que es 1.* Number of failures to tolerate –  aquí definiremos la disponibilidad del objeto, en este caso seleccione 1 (n+1) por lo que el objeto será protegido por RAID1 en 2 hosts ESXi, esto permitiendo que se tenga una caída de un host ESXi y seguir manteniendo acceso al objeto o vm, es importante notar que vSAN utiliza un “witness” que vendría siendo un tercer host ESXi en este caso para poder mantener la disponibilidad del RAID1 (> 50% de los componentes), esto lo veríamos conceptualmente de la siguiente manera:numberfailures1
    Lo podemos ver mucho mas claro una vez que realizamos la entrega de la VM con ese nivel de disponibilidad desde el vSphere Web Client (importante notar que en la imagen modifiqué el stripe del objeto a que fuera 1 como es recomendado y es el valor por defecto):numberfailures1web
    Aquí notamos perfectamente el RAID1 que existe entre el host “vesxi-1” y “vesxi-3” mientras que el witness queda en el tercer host “vesxi-2”.  Claramente los escenarios que se pueden llegar a dar pueden ser muy complejos, es por eso que VMware recomienda mantener el valor por defecto de 1 lo cual nos dara tolerancia a caída de un host ESXi y podemos tener la estructura de RAID mucho mas sencilla. En un articulo futuro estaré tocando que casos podemos llegar a tener modificando estos valores.*Flash Read cache reservation – Esta propiedad nos permite dictar una reservación de flash read cache (espacio del disco SSD) para que sea utilizado por la VM/objeto en cuestión, de igual manera se recomienda dejarlo en 0% y que el hipervisor se encargue de entregar el cache bajo demanda de manera “mas” equitativa.*Force Provisioning – En este caso la VM es aprovisionada aún cuando no se cumpla con las características dictadas (ej. number of failures to tolerate) y cuando los recursos esten disponibles para poder cumplir dichas características estas serán aplicadas.

    *Object Space Reservation – Aquí definimos el porcentaje de disco que será entregado de manera “thick provision”.

Para la creación de la VM u el objeto se toman en cuenta todas las características definidas en el perfil de almacenamiento seleccionado, con esto tres componentes del sistema de archivos entran en acción (componentes que existen en cada uno de los hosts ESXi como parte del core del hipervisor), CLOM (cluster level object manager), DOM (Distributed object manager) y LSOM (Local Log-structured object manager), básicamente cuando se requiere crear una vm u objeto CLOM se encarga de definir y asegurarse que las características del almacenamiento y la distribución a través de los nodos ESXi que conforman el arreglo RAIN sea la correcta (que se cuenten con los disk groups para satisfacer las necesidades), esto lo realiza a través del CMMDS de cada nodo, una vez que se ha identificado que se tienen disk groups, DOM se encarga de crear los distintos componentes del objeto o VM de manera  local (a través de LSOM) y remotamente a a través de CMMDS que a su vez habla on DOM localmente en los otros nodos que estarán albergando la información (esto a través de RDT). Después del proceso de creación todas las escrituras y lecturas suceden de manera distribuida a través de DOM, todo esto esto es ejecutado “por debajo” de lo que nosotros como usuarios o administradores podemos ver, pero creo que es interesante conocer a fondo el como se maneja este sistema de archivos.

¿Como suceden las escrituras y lecturas en este sistema de archivos distribuido?

  • Escrituras – en el momento que la VM es encendida en un host, ejemplo host 5, este se vuelve “dueño” de dicho objeto (vDisk) considerando que tenemos una tolerancia a fallos de 1 este objeto o vDisk estará replicado en otro host ESXi ej. host 4, por lo que en el momento que sucede una escritura desde el Guest OS de la VM esta escritura es enviada a SSD para el buffer y en paralelo es replicada a través de la red de vSAN al host que tiene localmente la replica de dicho objeto, en este caso el host4, el “dueño” o host 5 espera un acknowledge por parte del host que tiene la replica (host 4) para que después de esto el sistema de archivos se encargue de realizar el flush del buffer de las operaciones que se tienen en SSD en ambos nodos hacia la capa de HDDs
  • Lecturas – en el momento que el guest OS realiza una lectura el “dueño” de dicho objeto (vdisk) consulta el cache de SSD para poder determinar si la información se encuentra en SSD, en caso de tener un read miss esta información será servida a partir de HDDs y posiblemente puede ser almacenada en cache (SSD) para su futuro uso. Si la operación es servida a través del cache esta lectura será distribuida a través de las distintas replicas que se tienen en el cluster (los nodos que forman parte del RAID1 de dicho objeto, maximizando el rendimiento).

Interoperabilidad y consideraciones

vSAN en su versión inicial es compatible con los siguientes productos y/o funcionalidades:

  • Snapshots de VMs
  • VMware HA (implementación específica para vSAN, esto lo tocaremos en un siguiente articulo)
  • DRS
  • vMotion
  • SvMotion
  • SRM/vSphere Replication
  • VDP/VDPA

No es compatible con los siguientes productos y/o funcionalidades:

  • SIOC
  • Storage DRS
  • DPM

vSAN no es compatible con SIOC debido a que vSAN maneja de manera independiente la optimización de las VMs. Para el caso de Storage DRS simplemente no es posible utilizarlo debido a que solo manejamos un datastore y como último DPM no puede ser activado ya que aunque el host ESXi en cuestión a ser “suspendido” no tenga VMs ejecutándose puede darse el caso que se este utilizando un disk group provisto por el mismo.

Casos de uso

Al utilizar almacenamiento local lo primero que estaremos reduciendo es el TCO o el costo de adquirir la solución, en este caso podríamos estar pensando en vSAN como un producto que nos ofrece acceso a almacenamiento con alto rendimiento, bajo costo y lo mejor de todo excelente para contar con un diseño simplificado, es decir, poder reproducir los “PODs” computacionales donde se incluya CPU, RAM, y Storage de tal manera que sea repetible (sabiendo perfectamente el rendimiento de cada POD) ¿Entonces donde haría sentido esta manera de “diseñar? Horizon View, desarrollo, QA, DR (solo se soporta vSphere Replication), otros casos de uso son naturales a este tipo de solución.

Otro punto a considerar la reducción en los tiempos operativos u OPEX, es tan simple como comparar el tiempo que toma entregar una LUN o almacenamiento a los Hosts ESXi vs trabajar con un datastore provisto por vSAN que crece y se expande conforme vamos agregando nodos que aporten almacenamiento a través de sus disk groups… ¿Alguien pensó en Software defined Storage?

Actualizando almacenamiento en homelab – LenovoEMC PX6-300D

Que tal gente, el día de hoy les quiero compartir los resultados a nivel de almacenamiento que tuve al actualizar mi infraestructura de networking y almacenamiento. Para mi laboratorio tengo un rendimiento bastante satisfactorio, se agregaron 2 nuevos componentes, Switch de capa 3 Cisco SG200-26 y nuevos discos para mi antiguo y siempre confiable PX6-300D.

En el switch se activó jumbo frames (MTU 9000) para la comunicación de iSCSI por lo que el payload de cada paquete es mucho mayor, pudiendo asi optimizar la transmisión de información.

LenovoEMC LifeLine 4.0

Con la actualización de mi almacenamiento a la última versión de su sistema operativo (LifeLine) se agregaron capacidades bastante interesantes, en este caso estaremos enfocándonos al cache de SSD, es importante notar que no se trata de soporte o capacidad de conectar discos duros de SSD al almacenamiento y utilizarlos como espacio para presentarlo a los clientes.

Screen Shot 2013-08-20 at 12.35.20 PM

SSD caching básicamente nos permite crear pooles de discos de estado solido para acelerar las escrituras y lecturas a los volúmenes que estamos presentando, en este caso estaría realizando cache de toda la información que es accedida de manera intensa en los discos de estado solido para que sean servidos desde esta capa con un acceso mucho mas rápido que el de los discos duros tradicionales.Screen Shot 2013-08-20 at 1.05.09 PM Como podemos ver en la imagen tengo creado un pool de SSD caching con 100GB (disco de 120GB) de espacio, este es utilizado para almacenar todos aquellos archivos/info que son accedidos con mayor frecuencia. Como pueden ver tengo un Arreglo con nivel de RAID5 constituido por 5 discos SATA 3 con cache de 64MB, el problema esta en que este arreglo solo soporta operación a SATA2, debido al RAID5 me quedo con una cantidad de 7.2 TB utilizables.

Números, impacto de SSD caching

En el momento que me enteré que la nueva versión de LifeLine ofrecía SSD caching quize comparar el rendimiento que estaba presentando mi almacenamiento y el que presentaría con los nuevos discos, un RAID5 y SSD caching.

  • Layout de almacenamiento previa a la actualización:
  • 6 Discos SATA2 (16MB de cache) 250GB c/u, RAID0.
  • Layout de almacenamiento post actualización:
  • 5 Discos SATA3 (64MB de cache) 2TB c/u,RAID5, SSD Kingston Hyperx SATA3 120GB (SSD cache)

 

Para poder determinar el rendimiento que presentaba mi almacenamiento y el que presentaría después de actualizarlo decidí utilizar el fling de VMware llamado I/O Analyzer, aplicando dos distintos perfiles de iometer (claramente no son perfiles de cargas reales de trabajo) Max_IOPS y Max_Write_Throughput. Recordemos que previamente tenia RAID0 por lo que no se tenia ninguna penalidad de RAID y después de la actualización se tiene un RAID5 con penalidad de 4 IOPs por cada escritura.

  • Rendimiento Previo, 17044 IOPS máximo y una velocidad de escritura máxima de 111MBPS:

Screen Shot 2013-08-20 at 1.39.18 PMMax IOPS

Screen Shot 2013-08-20 at 1.39.04 PMMax write throughput

  • Rendimiento Actual 19573 IOPS máximo y una velocidad de escritura máxima de 112 MBPS:

Screen Shot 2013-08-20 at 1.42.31 PMScreen Shot 2013-08-20 at 1.47.33 PM

Como podemos notar aún considerando la penalidad del RAID5 (para mas información de RAID hacer click aquí) y teniendo un disco duro menos al agregar el pool de SSD para cache pude mejorar el rendimiento de mi almacenamiento “modesto” para mi laboratorio casero, creo que casí 20k de IOPS es algo bastante bueno para correr mis VMs y demos.

Lo que sigue es poder agregar un segundo puerto para mi comunicación de iSCSI y determinar que mejora en rendimiento podría representar agregar un LACP entre mi PX6300D y mis ESXi.

 

EMCISA – Intelligent Storage System

Que tal gente, el día de hoy vamos a continuar con otro punto del temario de la certificación EMCISA v2, es momento de hablar de los componentes y características que conforman un sistema de almacenamiento inteligente.

En el articulo pasado platicamos sobre lo que es un RAID, sus tipos y las ventajas que nos ofrecen, pero debe de quedar claro que un simple RAID no cubre las necesidades en cuanto a I/O y alta disponibilidad de los datos se refiere. Los sistemas de almacenamiento inteligentes incluyen tecnologías para el manejo de los datos o la manera que llegan estos datos al sistema de una manera optimizada, aprovechando distintos caminos o “paths” hacia el mismo almacenamiento; de igual manera estos integran “cache” en forma de memoría DRAM esto para poder almacenar de manera temporal aquella información que es altamente requerida con lo que se logra que cada vez que se requiera un acceso a dicha información esta sea servida a partir de esta memoria o “cache” obteniendo una latencia menor y acelerando las operaciones de I/O.
Claramente no solo estaremos hablando de cache y optimización de paths, si no estaremos conociendo distintos métodos y tecnologías que nos permiten tener un manejo y acceso a la información optimizado.

¿Cuales son los componentes de un sistema de almacenamiento inteligente?

Se tienen 4 componentes principales en un almacenamiento inteligente (claramente no es la totalidad de componentes), “frontend”, cache backend y discos.

Almacenamientointeligente

Revisemos cual es el rol de cada uno de estos componentes en el procesamiento y manejo de la información:

  • Front End – este componente se encarga de manejar la interacción directa con el host que esta pidiendo acceso de cualquier tipo a la información, sea lectura o escritura. Generalmente consiste de dos o mas controladoras que a su vez tienen múltiples puertos para poder permitir la conexión de muchos servidores a la vez. La controladora es la encargada de manejar el protocolo utilizado en la comunicación, por ejemplo, iSCSI, FC, FCoE, NFS, etc; esta controladora se comunica con el cache mediante un bus de información interno, a través del cual envía escrituras y lecturas, una vez que el cache da acceso a la información (sea entregándola a partir de su memoria o acceso directo al backend) se envía un “acknowledge” o se reconoce que la operación ha sido satisfactoria.
  • Cache – el cache generalmente esta compuesto por memoria DRAM, aunque almacenamientos avanzados pueden llegar a combinar distintos niveles o “tiers” de cache, por ejemplo, DRAM, SSD, etc Este componente es critico para poder acelerar las operaciones a nivel de almacenamiento, esto se logra almacenando aquella información “caliente” o que ha mostrado una actividad (I/O) alta en la memoria propia de este cache para que los servidores que tienen acceso al sistema de almacenamiento reciban dicha información a partir de este cache y así prevenir el acceso a los discos duros mecánicos que tienen un tiempo de acceso mucho mayor a este cache hablando de tiempos en ms (de seek time) en el caso de los discos duros cuando DRAM esta por debajo del ms.El cache esta constituido por dos componentes principales “data store” y “tag ram”, donde la función del “data store” es básicamente almacenar la información en unidades llamadas “páginas” mientras que la función de “tag ram” es la darle seguimiento o saber donde se encuentra la información para poder utilizarla (parecido a lo que es un metadata), de igual manera identificar que información ha sido enviada a disco a través de un indicador “dirty bit” y por último mantener los tiempos de acceso a dicha información para poder ir determinando que información debe estar en el cache (basándose en las políticas definidas para el cache, que estaremos viendo mas adelante)Es importante saber que en el momento que un servidor pide información al sistema de almacenamiento se busca dicha información en el “tag ram” para determinar si será servida o no desde cache, en el caso que esta sea servida desde cache se le conoce como un “Read Hit”, si la información no se encuentra en cache esta tendrá que ser servida a partir de los discos en el backend y esto es conocido como “Read Miss”. En el momento que se detecta un acceso secuencial puede darse que el sistema de almacenamiento cuente con la tecnología de prefetch (este puede ser de tamaño fijo o variable) o “read ahead” a partir de la cual se definirá un conjunto de bloques o información secuencial a la información que se esta accediendo para ser transferido de los discos hacia el cache para que en el caso que el host los requiera se pueda acelerar el acceso a esta información. A mayor Read Hits mejor rendimiento se tendrá en las operaciones de lectura hacia nuestro sistema de almacenamiento.El cache no solo optimiza las operaciones de lectura, tenemos dos distintos modos de cache para las operaciones de escritura, “write-back cache” y “write-through cache” donde el primero permite tener tiempos de respuesta mas rápidos debido a que en el momento que llega una operación de escritura esta es almacenada en el cache e inmediatamente se envia un “acknowledge” o se reconoce que dicha operación de escritura ya fue realizada y mas adelante es escrita a disco o “de-staged” el segundo modo de escritura con cache o write-through cache recibe la escritura la almacena temporalmente en memoria y la escribe inmediatamente a disco después de esto por lo que el “acknowledge” o reconocimiento que la operación sucedió tiene una latencia mayor. Las operaciones que son almacenadas en ambos modos de cache será determinada por el tamaño máximo de I/O  configurado a través del cual se decide si este estará siendo almacenada en cache o enviada directamente a disco.Claramente la cantidad de cache en cualquier sistema de almacenamiento inteligente es mucho menor de el espacio disponible en disco, por lo que el cache debe de ser utilizado de manera óptima y solo almacenar la información que “merece” o debe de estar ahí para poder optimizar las operaciones de I/O, para esto se cuentan con distintos algoritmos que evitan la saturación de este componente y permite manejar los ciclos de vida de información según el uso que esta presentando, se manejan los siguientes algoritmos:Least Recently Used (LRU) – Este algoritmo se encuentra constantemente monitoreando el último acceso a la información identificando paginas almacenadas en cache que no han sido utilizadas por mucho tiempo, en el momento que dichas páginas son identificadas se marcan para ser reutilzadas o en el caso de que estas contengan información de escritura que no ha sido enviada a disco (ej. write-back cache) esta es primero enviada a disco para después marcar dichas páginas para reutilizarse.Most Recently Used (MRU) – Este algoritmo es exactamente lo opuesto a LRU, básicamente se definen las páginas del cache que han sido utilizadas recientemente tomando como premisa que debido que la información fue accedida hace poco tiempo esta no será requerida pronto.

    Independientemente de el algoritmo para mantener almacenada o no la información en cache se requiere definir en que puntos de utilización (espacio de cache consumido) se deberá realizar un “flush”  de toda aquella información que se encuentra en cache y no ha sido escrita a disco para poder gestionar el espacio disponible en cache y no saturarlo. Basadandose en la cantidad de espacio consumido del cache se definirá el ritmo de flush o escritura de información a partir del cache a disco, se tienen 3 estados, “High Watermark”, “Idle flushing” y “Forced Flushing”
    Flushes El flush de tipo “idle” sucede a un ritmo moderado debido a que esta por debajo o en el nivel de utilización marcado como “Low Watermark”, el Flush de tipo High Watermark sucede a un ritmo mas rápido debido a que ya se superó o se encuentra en uso la cantidad de páginas de cache marcadas como “High Watermark” y para el último tipo de flush que es llamado “Forced Flushing” básicamente el cache ha llegado a un 100% de consumo de espacio por lo que se requiere un ritmo de escritura de la información en cache hacia el disco muy rápida, a mayor ritmo de escritura el sistema de almacenamiento dedica mayor cantidad de recursos para poder cumplir con el ritmo.

    Algo que pueden estar pensando en este momento es, “Esta bastante interesante todo este tema de cache, su funcionamiento, etc, ¿Pero acaso no tenemos información en el cache que no ha sido escrita o flushed a discos? ¿Que hay de la protección para el cache y/o la información que vive en el?” y esto es justamente lo que estaremos comentando a continuación, debemos de considerar que al tratarse de manejo de información siempre debemos de tener en mente nuestros SPOFs o “Singe Points of Failure” por lo que se manejan dos principales métodos para proteger aquella información que continua en el cache y no ha sido escrita a disco, Cache Mirroring y Cache Vaulting.

    Cache Mirroring – Con este método básicamente lo que se esta realizando es tener una copia exacta de todas aquellas operaciones de I/O que son escrituras y que están viviendo en el cache (básicamente información que no ha sido escrita a disco) por lo que contamos con distintas unidades de memoría donde la información es copiada por si se da el caso de tener una falla en alguna de las unidades de memoria, esto lo podríamos ver como un nivel de RAID 1. Cabe destacar que en ambas copias se lleva un seguimiento puntual de la estructura y la información que vive en ellas debido a que debemos de contar con la misma información y que esta este integra, a este proceso se le conoce como “cache coherency”.

    Cache Vaulting – Este método logra proteger la información que vive en el cache a través de discos dedicados a almacenar la información que este activa en el cache, por lo que cuando se tiene un problema de energía eléctrica la información es copiada a estos discos dedicados como “vault” donde la información deja de ser volátil, en el momento que la energía eléctrica regresa esta información es copiada de nuevo al cache y es escrita a los discos donde debía de ser escrita en un principio.

  • Back End – Este componente de el sistema de almacenamiento inteligente sirve como interfaz de comunicación entre el cache y los discos físicos, en este  se encuentra los distintos algoritmos para permitir una configuración de RAID. El flujo de información sucede de la siguiente manera, una vez que la operación de escritura es enviada a escribirse a disco desde el cache, llega al backend donde puede ser almacenada por una breve ventana de tiempo para después ser ruteada hacia el o los discos donde debe de estar viviendo. En el backend también se cuenta con mecanismos para detectar errores y corregirlos además de los mecanismos para controlar el o los niveles de RAID, estas controladoras están conectadas a los discos a través de puertos que tiene cada controladora generalmente hablamos de dos o mas controladoras para brindar alta disponibilidad y múltiples paths de acceso a los discos físicos
  • Discos Físicos – básicamente aquí estamos hablando de discos como los conocemos, generalmente este tipo de sistemas de almacenamiento tienen soporte para distintos tipos de discos, desde SAS, SATA, EFD, FC, etc. Aquí es donde sucede todo la asignación y reservación de espacio según distintas políticas definidas donde podemos estar hablando de alta disponibilidad, rendimiento, capacidad, etc. este proceso es conocido como “storage provisioning” o asignación de almacenamiento.Para asignar espacio primero debemos segmentar o agrupar los discos físicos en grupos lógicos a los cuales se les asigna un nivel de RAID, a este grupo lógico se le conoce como RAID Set, dependiendo de la cantidad de discos y el tipo de los mismos (claramente tomando en cuenta el nivel de RAID aplicado) se contará con cierta cantidad de espacio utilizable, cierto rendimiento y disponibilidad de los datos.
    Provisioning
    Una vez creado el RAID Set este es particionado con lo que se crean las unidades lógicas que estarán siendo entregadas a los servidores que requieren acceso a disco, estas unidades se les conoce como LUNs o Logical Unit Number, a cada unidad se le asigna un número único. Estos LUNs son básicamente una porción de espacio del total con el que se cuenta en el RAID Set, los sistemas de almacenamiento tradicionales entregan estos LUNs en formato “thick” o con asignación completa del espacio configurado, mientras que los sistemas de almacenamiento avanzados pueden entregar los LUNs en un modo “virtual” o “thin” en la imagen podemoslunthin notar que básicamente la entrega de almacenamiento en modo virtual o “thin” es presentar al servidor que requiere acceso a espacio en disco un LUN que desde la perspectiva del Sistema Operativo es reconocido como el espacio en su totalidad (en este ejemplo 80GB) pero en el sistema de almacenamiento solo estará ocupando aquel espacio que haya sido escrito a dicho LUN, la ventaja de este método de asignación es que podemos contar con “overcommitment” o asignar mayor cantidad de espacio en disco de la cual tenemos en realidad en nuestro sistema de almacenamiento (existen múltiples consideraciones al entregar LUNs en thin Provision). Thin Provision permite entregar el espacio bajo demanda y no asignar desde el inicio la totalidad de el espacio.

    Algunas de las consideraciones que debemos tener en el momento de decidir si estaremos asignando el espacio de manera tradicional o “thick” o lo estaremos haciendo a través de Thin Provision o “virtual” son:

    1. Si la aplicación requiere un rendimiento esperado lo mas recomendable es Thick provision.
    2. Contamos con aplicaciones o servicios con información que es modificada constantemente o que incrementa de manera sustancial, para esto de igual manera se recomienda thick provision.
    3. Se tiene aplicaciones o servicios que no cambiarán su información de manera constante, no escribirán a disco o básicamente tienen contenido estático, para esto podemos utilizar thin provision

    Claramente estas no son todas las consideraciones que existen pero es un claro ejemplo que debemos planear que tipo de LUNs estaremos asignando según los requerimientos que se presenten.

    Una vez que el espacio de un LUN fue definido contamos con distintos métodos para poder incrementar el espacio vamos a echarle un vistazo:
    MetaLUN – es la manera que tenemos para poder expander un LUN existente ya sea para darle mejor rendimiento o agregar espacio. Un MetaLUN básicamente es la construcción lógica a partir de dos o más LUNs, se tiene el LUN inicial que es llamado LUN Base y una o más LUNs componentes, una vez que agregamos una o mas LUNs como resultado tenemos un “MetaLUN” que nos brindará espacio extra o un rendimiento mayor. Se cuenta con dos métodos para crear un MetaLUN, concatenación de dos o más LUNs o stripe.

    METALUN En el caso de tener un MetaLUN debemos comprender que al concatenar 2 o mas LUNs no estaremos teniendo ninguna ganancia en cuanto a rendimiento se refiere ya que no se estará realizando un stripe de la información en la nueva LUN (recordemos que el proceso de Stripping es distribuir la los datos en varios discos, en este caso al referirnos de LUNs sería la distribución de la información en varios LUNs). Claramente cuando creamos un MetaLUN con stripping además de incrementar el espacio también estaremos beneficiándonos de un mejor rendimiento debido a que estaremos sirviendo la información de todos los discos que han sido asignados a cada uno de los LUNs que constituyen el MetaLUN.

    Para poder presentar los LUNs disponibles a nuestros servidores debemos definir que hosts tienen acceso a los LUNs, esto se le conoce como LUN Masking. En el momento de realizar LUN masking debemos definir los LUNs y los identificadores de los Hosts según el protocolo que estemos utilizando, ej. iSCSI, FC, etc. (IQNs para iSCSI, WWNs para FC). Esto es controlado del lado del sistema de almacenamiento, por lo que en el momento que un servidor quiere acceder al LUN se verificará si el identificador del servidor esta permitido para acceder y que tipo de permiso tiene (ej. escritura/lectura o solo lectura).

Tipos de almacenamientos inteligentes

Los sistemas de almacenamiento son clasificados en dos tipos, High-end y Midrange:

  • High-End Storage Systems – este tipo de sistemas están pensados para cargas altamente transaccionales y/o críticas, cuentan con múltiples controladoras en modo activo-activo para brindar acceso a los distintos LUNs, en este caso cualquier controladora permite acceso a los LUNs. Generalmente este tipo de almacenamientos ofrecen mayor cantidad de espacio, de cache, arquitecturas tolerantes a fallos, etc. Un ejemplo claro de este tipo de almacenamientos inteligentes es Symmetrix de EMC.
  • Midrange Storage Systems – este tipo de sistemas cuentan generalmente con dos controladoras en un esquema activo-pasivo, es decir, una controladora es dueña de ciertas LUNs, lo que quiere decir es que cualquier actividad de I/O debe de llegar a través de la controladora dueña de la LUN, mientras que la otra controladora permanece pasiva. En el caso de tener una falla en alguna controladora se puede dar un “trespassing” de la controladora fallida a la controladora que permanece funcional con esto dicha controladora se vuelve dueña de los LUNs que eran controlados por la otra controladora que falló. Un ejemplo de almacenamiento midrange es VNX de EMC.

EMCISA – Data Protection (RAID)

Que tal gente, el día de hoy comenzaré con esta nueva serie de artículos sobre fundamentos de almacenamiento, estaremos cubriendo exactamente todos el temario del examen E10 – 001 de EMC que analiza los conocimientos cubiertos en el curso ISM v2 y aprobándolo podemos ser acreditados como EMCISA (EMC  – Information Storage Associate).

El día de hoy estaremos conociendo que es un RAID, sus distintos niveles y que ventajas nos ofrece.

¿Que es un RAID y porque utilizar RAID?

RAID es una técnica que nos permite combinar dos o mas discos físicos en un una unidad lógica (RAID Set), esto para brindarnos protección de datos, rendimiento, o una combinación de ambos.

La necesidad de tener un mecanismo para brindar protección a los datos existe debido a la posibilidad de que estos fallen, el tiempo aprox. o posibilidad de que fallen esta definido por el MTBF (Mean Time Between Failures) que básicamente nos da un tiempo estimado de falla mecánica del disco, estos tiempos son provistos por el fabricante. Entonces revisando un ejemplo donde tenemos lo siguiente:

  • 100 Discos en un arreglo utilizando el disco especificado

Para poder conocer el tiempo de falla de un disco debemos de dividir el MTBF entre la cantidad de discos, cosa que nos dará el siguiente resultado:

750,000/100 = 7,500 horas

Básicamente aquí estamos definiendo que el tiempo aprox. para tener una falla de un disco es de 7,500 horas, claramente esto esta seriamente impactado por el trabajo que se le de al arreglo/discos, temperatura, etc.

Con esto queda demostrado que es necesario poder contar con mecanismos para la protección de los datos que existan en dichos discos que presentarán una falla, es por esto y por cuestiones de rendimiento que distintas tecnologías de RAID son ampliamente utilizadas.

¿Que métodos tenemos para implementar RAID?

Existen dos métodos de poder crear un RAID, software y hardware. Dentro de estos métodos de implementación tenemos distintos niveles de RAID que almacenan la información de distinta manera cada uno con sus desventajas y ventajas.

  • Software RAIDeste método de implementación utiliza mecanismos de software (a nivel del sistema operativo) para crear el arreglo RAID, claramente los recursos necesarios para el procesamiento y manejo de este serán provistos por el host. Entre las limitantes que presenta este método están el impacto en el rendimiento general del sistema (uso de CPU), no se soportan todos los niveles de RAID, problemas de compatibilidad entre el SO y el RAID, no existe protección en el momento de booteo, etc. Dentro de software RAID tenemos un “hibrido” donde se cuenta con un BIOS de RAID en la HBA o en la MOBO que permite contar con la protección de RAID aun cuando se esta iniciando el sistema.
  • Hardware RAID – este método de implementación utiliza un componente de hardware dedicado para el RAID (controladora) , este puede ser implementado del lado del host o del lado del almacenamiento. Este componente de hardware dedicado se encarga de controlar el acceso a los discos, presenta los distintos RAID Sets y se encarga de regenerar la información en el caso de tener una perdida de un disco, cuando hablamos de  almacenamiento centralizado este componente tiene algunas otras tareas como presentar grupos lógicos a partir de estos RAID sets (LUNs), etc.

Técnicas de RAID

Vamos a conocer las tres principales técnicas utilizadas para la distribución de los datos en el RAID Set  y la disponibilidad de los mismos, a partir de estas técnicas también se construyen los distintos niveles de RAID (los cuales revisaremos mas adelante en este articulo):

  • Stripingesta técnica permite distribuir los datos a través de dos o mas discos duros para que funcionen en paralelo, permitiendo así tener un rendimiento de escritura y lectura mayor al que se tendría con los discos por su cuenta. Al tener un RAID set contamos por cada disco físico un conjunto pre definido de bloques continuos, en este caso este conjunto es conocido como “strip” recordemos que un RAID set agrupa de manera lógica varios discos por lo que al conjunto de strips alineados que se existen a lo largo de todos los discos que constituyen este RAID set se le conoce como “stripe”.
    El tamaño de strip define la cantidad de información que puede ser escrita o leída (bloques) en un solo disco del RAID set, el tamaño de stripe es definido al multiplicar el tamaño de strip de los discos que pertenecen al RAID por la cantidad de discos (ej. 64KB de strip por disco por 10 discos en el RAID nos daría un tamaño de stripe de 640KB).
  • Mirroring  esta técnica consiste en tener dos copias de la información en 2 discos, es decir, lo que es escrito en un disco será escrito en otro disco que contendrá exactamente la misma información, con esto al fallar un disco la información puede ser entregada a partir del segundo disco. La consideración en este caso es que la información es duplicada por lo que necesitamos el doble de almacenamiento para la misma cantidad de información.
  • Paridad la paridad es una técnica que permite brindar protección de datos sin necesidad de contar con un mirror o “espejo”, en este caso se cuenta con un disco (o mas dependiendo del nivel de RAID) asignado específicamente para almacenar la información de la “paridad” (aunque también puede ser distribuida a lo largo de distintos discos del RAID set), el calculo de la paridad es una tarea mas de la controladora RAID. Tomando como ejemplo que tengamos 5 discos duros conformando un arreglo de discos o RAID tendríamos un disco dedicado exclusivo para almacenar la información de paridad por lo cual solo 4 discos estarían dedicados para almacenar los datos, en el caso de presentarse una falla de un disco se puede reconstruir la información perdida a partir de un cálculo matemático donde se substrae la información restante de la paridad (en realidad es una operación bitwise XOR). Es importante notar que al utilizar paridad no se toma en cuenta el o los discos que contengan paridad como parte del Strip size, entonces regresando a nuestro ejemplo, teniendo 5 discos, 4 con información y uno de paridad estaríamos multiplicando el strip por la cantidad de discos para calcularlo (ej. 4x64KB).

Niveles de RAID

Una vez que ya conocemos las distintas técnicas utilizadas a nivel de RAID podemos continuar a lo siguiente que es los niveles de RAID, el nivel de RAID será definido a partir de los requerimientos que pueda presentar la aplicación, servicio, tipo de información etc. esto definirá el nivel requerido de disponibilidad y rendimiento de nuestra información. Los distintos niveles de RAID utilizan una o mas técnicas para asegurar la información y/o brindar mayor rendimiento.
Contamos con los siguientes niveles de RAID (los mas comunes), copiaré información del articulo “VCAP – Sección 1 – Determinar el nivel de RAID para nuestras aplicaciones.”:

  • RAID 0 – (Stripe) este tipo de arreglo básicamente distribuye los datos entre los discos que conforman esta entidad lógica, aquí el problema que tenemos es la falta de un cálculo de paridad y por lo tanto cero tolerancia a fallos. Con este tipo de RAID obtenemos mejor rendimiento.

  • RAID 1 – también conocido como espejo, este tipo de RAID crea una copia exacta entre un numero de discos, ej. si tenemos 2 discos cada uno tendría la misma información ya que una vez que se está por escribir la información esta es escrita en ambos discos. Con este tipo de RAID obtenemos mejor tolerancia a fallos sacrificando rendimiento.

  • RAID 5 – Con este tipo de RAID obtenemos tolerancia a fallos y un mejor rendimiento, se hace el cálculo de la paridad y se escribe alternativamente entre los discos que conforman el arreglo de igual manera toda la información que se necesite escribir a disco es escrita de manera alternativa entre los discos. Con esto tenemos la capacidad de perder un disco del arreglo, en el momento que se pierde se reconstruye la información perdida a partir de la paridad. Aquí necesitamos como mínimo 3 discos, este tipo de arreglo es uno de los más comunes y de los mas adoptados debido a su buen rendimiento y tolerancia a fallos.

  • RAID 1+0 – Este tipo de RAID es una combinación tanto de RAID 1 y RAID 0, como podrán imaginarse aquí hacemos una combinación tanto de la tolerancia de fallos que nos ofrece el arreglo 1 con el rendimiento que nos ofrece el arreglo 0. Este arreglo también conocido como RAID 10 es el más rápido y ofrece buena seguridad de datos, el problema es la cantidad de discos y por lo tanto la cantidad de $$ que requerimos para implementarlo, como mínimo requerimos 4 discos y solo pudiendo utilizar 2.

Es Importante notar que tenemos dos distintos niveles de RAID que combinan RAID 0 y RAID 1, en este caso describí RAID1+0 que no es lo mismo que RAID0+1, ambos ofrecen los mismos beneficios y tienen las mismas consideraciones, donde podemos encontrar la diferencia es en el momento de la reconstrucción de datos en el caso que se requiera. RAID 1+0 es conocido como “Stripped Mirror” la mecánica para el manejo de los datos en este tipo de RAID es que primero se realiza un mirror de la información entre los distintos mirror sets y después se realiza el stripe de la información entre los discos de datos y en el momento que falla un disco solo el “espejo” o mirror es reconstruido a partir de su par.

RAID 0+1 es conocido como “Mirrored Stripe” en este nivel de RAID la mecánica es crear el stripe de información inicialmente y después realizar el mirror de esta información, en este caso al fallar un disco todo el stripe de información es afectado, en este caso la información es reconstruida en su totalidad a partir del mirror que se tiene. Tomemos como ejemplo tener un RAID 0+1 constituido por 8 discos, en este caso se crearían primero 2 sets conteniendo 4 discos donde la información estaría en stripe (RAID 0) pero al tener 2  sets con la misma cantidad de discos también aplicamos un RAID1 o “mirror” por lo que la información también esta protegida.

Impacto de los distintos niveles de RAID

Al decidir que tipo de RAID se estará utilizando es importante conocer el impacto en el rendimiento que cada uno de estos niveles de RAID tiene, este impacto u “overhead” es debido a las mecánicas principalmente de paridad, esta penalidad se presenta en el momento de tener escrituras a disco ya que las lecturas no requieren actualizar la información, escribir nueva información o una modificación de la paridad a partir de la nueva información escrita. Vamos a revisar la penalidad en el rendimiento de los niveles de RAID mas comunes:

  • RAID 1 – en este caso la penalidad es exactamente el numero de escrituras enviadas a disco, ya que estamos hablando de un espejo o “mirror” por lo que se requiere escribir su copia exacta. Por lo que una operación se traduce en el backend a 2 operaciones en disco.
  • RAID 5 – en este nivel de RAID estamos hablando de una penalidad de 4 operaciones (2 lecturas/2 escrituras) por cada operación a disco, esto debido a que primero debemos de leer la información actual (1 operación), la paridad actual (2 operaciones), escribir la nueva información (tres operaciones) y actualizar la paridad (4 operaciones).
  • RAID 6 En el caso de este niel de RAID vamos a estar hablando de 6 operaciones a nivel de disco (3 lecturas/3 escrituras) ya que primero debemos de leer la información(1 lectura), después leer la doble paridad (3 lecturas), Después debemos actualizar la información (4 lecturas) y por último recalcular la doble paridad (6 lecturas).

Como podemos ver es importante poder entender el impacto que tiene cada uno de los distintos niveles de RAID, muchos vendors utilizan los mismos niveles de RAID ya que existen otros elementos que impactan al rendimiento como lo puede ser el cache, la secuencialización de operaciones, etc.

Vamos a revisar algunos ejemplos para calcular penalidad en el backend (iops reales requeridos) según el nivel de RAID y el perfil de operaciones:

Escenario 1:

  • Aplicación demandando 2500 IOPS
  • RAID 5 configurado
  • Perfil de aplicación u operaciones, 40% escrituras / 60% lecturas

En este caso para calcular el impacto que tiene el nivel de RAID (RAID 5) debemos de tomar como base la siguiente fórmula:

(IOPS objetivo x porcentaje de lectura) + ((IOPS objetivo x porcentaje de escritura) x penalidad RAID) = IOPS en backend

Lo cual para este caso nos daría lo siguiente:

(2500x.60) + ((2500x.40)x4) = 5500 IOPS en backend

Escenario 2:

  • Aplicación demandando 1200 IOPS
  • RAID 1+0 configurado
  • Perfil de aplicación u operaciones, 2/3 lecturas / 1/3 escrituras

Lo cual para este caso nos daría lo siguiente:

(1200x.6666) + ((1200x.3333)x2) =

(799.92) + (799.92) = 1600 IOPS (redondeando).

Nivel de RAID según perfil de aplicación

Tomando en cuenta los niveles de RAID mas comunes que estuvimos cubriendo en este articulo vamos a revisar para que perfil de aplicación u perfil de operaciones debe de ser considerado:

  • RAID 1+0 – Este nivel de RAID es excelente para aplicaciones o perfiles de I/O donde tenemos pequeñas operaciones de tipo “random” o no secuenciales e intensivas en escrituras (30% de escrituras en adelante).
  • RAID 3 – Este nivel de RAID nos da un buen rendimiento para aplicaciones o ambientes donde tenemos un perfil de I/O con operaciones secuenciales y con un tamaño considerable, por ejemplo, respaldos o streaming de videos.
  • RAID 5 – Este nivel de RAID nos da buen rendimiento en ambientes donde contamos con perfiles de I/O con operaciones no secuenciales o “random” con un porcentaje alto de lecturas.