SAN

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?

¿DRS para nuestro almacenamiento?

¿Alguna vez han querido darle cierta preferencia a una vm en cuanto al vmfs se refiere? Bueno, pues esto puede ser una realidad, en varios posts en la web se ha hablado de una nueva posible característica que VMware incluirá en un próximo release de vSphere ¿El nombre? Storage I/O Control (SIOC), les recomiendo que lean el post del gurú de performance en VMware Scott Drummonds, que lo pueden encontrar en este link : http://vpivot.com/2010/05/04/storage-io-control/#more-515.

Todos sabemos que muchas veces la perdida de performance en una infraestructura VMware se debe a una mala configuración de nuestro almacenamiento , o a que el mismo no tiene la capacidad de entregar la cantidad de IOPS que nuestra infraestructura requiere , SIOC lo que nos permitirá es definir shares de disco pero esta vez no a nivel servidor ESX, sino a nivel arreglo, es decir esto aplicara para todos los servidores ESX que estén accediendo a un VMFS determinado en algún arreglo de discos esto lo podemos ver en las siguientes imágenes :

En esta primera  imagen podemos ver claramente que la distribución de nuestro arreglo está totalmente dispareja, la vm C está teniendo 50% del Queue del almacenamiento, mientra s las otras maquinas se reparten el otro 50%.

En esta segunda imagen podemos ver él como SIOC en base a los shares que tenemos configurados para cada máquina virtual , asignará los respectivos porcentajes de queue a nuestras vms, repartiendo el acceso al arreglo de una manera más equitativa.

SIOC se basará en la latencia que está presentando nuestro vmfs , y esto como nos comenta Scott , se basa en el total de latencias que están teniendo todas las vms que residen en dicho vmfs. Cuando este valor sobrepase el valor que nosotros configuramos como tope, se reducirá el acceso a nuestro arreglo a las maquinas con menos shares, permitiendo así que las maquinas criticas puedan mantener un buen funcionamiento.

Recuerden que esta funcionalidad no ha sido revelada oficialmente, hasta ahora solo se ha comentado que se está trabajando en ella,  aquí les dejo un link de vmware donde pueden lver una presentación del vmworld 2009 sobre SIOC:

http://vmworld.com/docs/DOC-3855