Novedades en el SDS

imagesSDS
Por Alberto Giorgi (VCI, VCP-DCV, VCP-NV, VCP-Cloud, CCSI, CCNP, ex MCT).

Hola a todos. Bienvenidos a esta nota sobre las novedades de SDS que decidí compartir porque quizás te pase como a mí. Metido en tantas tecnologías al mismo tiempo, es difícil mantenerse actualizado en todas. Basta que ponga foco en una para que las demás continúen avanzando y cuando te descuidas te encuentras con un montón de novedades, siglas y conceptos nuevos.

Buscas un documento que te lo explique todo desde cero, que sea fácil de comprender y solo te encuentras con información parcial, mucho marketing, que explica las cosas superficialmente, muy orientado a los decision makers pero no a los técnicos, que necesitamos saber además de para qué sirve, como trabaja.

El océano de información es cada vez más grande, y mantenerse a flote cada vez más difícil.

Esto último es lo que me volvió a pasar cuando intenté comenzar a entender los últimos cambios a nivel de almacenamiento. Había estado profundizando en el SDN, con el NSX de VMware y la solución de Cisco ACI, mientras escuchaba hablar sobre vSAN a algunos de mis colegas sin poder prestarle demasiada atención.

Ahora que ya tengo controlado el Software-defined networking (SDN) me toca entender sobre el Software-defined storage (SDS), que junto con el Software-defined Computing (SDC) conforman las tres columnas que sostienen el Software-defined Data Center (SDDC). (Cuantas siglas!!)

Muchas cosas están cambiando en la tradicional tecnología de almacenamiento, y como me he pasado varios días investigando, intentaré resumirlas en dos notas complementarias para hacerle la tarea más fácil a alguien que como yo esté intentado entender todos estos cambios que se están disparando en poco tiempo, después de décadas de quietud en esta área. En la primera parte de la nota explicaré conceptos como el storage multitier y algunos conceptos de virtualización a nivel de storage como los VASA, VAAI o VVols, y en la segunda parte me centraré en los demás elementos que requiere VVols y en las alternativas de QoS que permiten diferenciar dichas tecnologías.

Es complicado incluso hasta tratar de ordenar tantas novedades.

Hasta no hace mucho tiempo el almacenamiento era una caja negra que el sistema operativo (S.O.) utilizaba para dar órdenes como guardar o leer datos.

Casi toda la inteligencia del almacenamiento era responsabilidad del S.O., que desconocía cosas tan elementales como que calidad de servicio (QoS) ofrecía ese almacenamiento. Prácticamente lo único que hacían las cabinas eran recibir las órdenes del S.O. y organizar los datos el bloques o en archivos, según se tratara de una NAS o una SAN, o uno o varios discos según se tratara de un HD o una LUN.

Si el S.O. necesitaba clonar una VM, tenía que tomarse el trabajo de abrir los archivos en la LUN de origen, leer bloque por bloque y copiarlo en la LUN de destino. Esto requería que las operaciones fueran desde el S.O. a la cabina, los datos desde la cabina al S.O. y de nuevo a la cabina, en algo que se conoce como hairpining y que está muy lejos de ser eficiente, tal como muestra la siguiente figura:

Image 1

Las grandes diferencias que había en materia de almacenamiento eran físicas. Tecnología SAS o SATA, discos de 7200, 10000 o 15000 rpm, cache en las controladoras, políticas write back o write through, protocolos de transporte (FC, FCoE, iSCSI, NFS), etc.

Solo el administrador del storage era capaz de diferenciar la calidad de una LUN de otra, y eso si sabía perfectamente con que “material” había sido construida esa LUN. Todos los archivos eran tratados de la misma manera y no había diferencia a nivel de la cabina entre un VMDK o una imagen ISO.

Recientemente muchas tecnologías han irrumpido en esta área. Intentaré enumerar las principales a continuación.

Almacenamiento multitier

Una de las últimas novedades han sido los discos de estado sólido (SSD), que se diferencian de los de naturaleza electromecánica (HDD) por carecer de latencias en el proceso de seek y search y que por lo tanto son mucho más rápidos que los discos tradicionales (y al parecer mucho más fiables que hace unos años atrás).

Ya comienzan a aparecer las primeras cabinas de discos SSD, y uno de los nuevos players en este mercado es Cisco, un mercado en el que solo participaba hasta ahora ofreciendo switches fibre channel o FCoE. La solución se llama Cisco UCS Invicta y podéis encontrar más información aquí.

Esto agrega un nivel más a las velocidades ya mencionadas, lo que permite construir soluciones multitier o de múltiples niveles, donde podemos utilizar distintas calidades de almacenamiento más caras (y por lo tanto más rápidas y quizás más escasas) o más baratas (más lentas y más masivas) para guardar la información según la velocidad de acceso necesaria.

Imagine un periódico que usará los discos más rápidos para almacenar la publicación de hoy, otros un poco más lentos para guardar las publicaciones de la última semana, otro más lentos aún para las publicaciones del último mes, y finalmente los más lentos de todos para las publicaciones del último año. De una manera eficiente las cabinas pasarán las notas de archivo que de repente vuelven a tener vigor del almacenamiento más lento al más rápido de forma totalmente automática, y que devolverán al almacenamiento de último nivel cuando ya no se necesite más. Este es el tipo de inteligencia que las cabinas comienzan a aplicar mediante una combinación de discos HDD y SSD. Esto no es nuevo en realidad, hace años algunas aplicaciones de backup ya se encargaba de gestionar la distribución de la información en niveles on-line, near-line u off-line (cintas).

Virtualización en el almacenamiento

Pero la virtualización del storage ha agregado mucho más que los aspectos físicos, no en vano el software permite innovar mucho más rápido que el hardware.

Los conceptos como VASA y VAAI ya eran conocidos a partir de la versión 4 de vSphere, pero a medida que pasan las versiones han ido mejorando los servicios.

Si nunca escuchó hablar de estos términos, permítame que se los explique.

vStorage APIs for Storage Awareness (VASA):

Son APIs que permiten que el S.O. conozca detalles sobre la calidad del almacenamiento, de manera que pueda diferenciar por ejemplo entre una LUN conformada por discos de 15000 rpm, con RAID 1, con caché write back con protección por batería y accedida por FC, de otra LUN conformada por discos de 7200, con RAID5, sin caché y accedida por iSCSI.

A partir de esta información el administrador de vSphere ya puede saber si crear una VM SQL en la primera LUN o en la segunda. Sin VASA era prácticamente imposible que el administrador pudiera saberlo. Esta diferenciación se puede realizar gracias a Perfiles llamados Profile-Driven Storage, como veremos más adelante.

Las APIs de VASA son provistas por el fabricante de la cabina y son entendidas por el vCenter en forma nativa o bien luego de integrar el software del fabricante.

vStorage API for Array Integration (VAAI) :

También son APIs, pero en este caso ofrecen primitivas que aceleran ciertas operaciones que anteriormente eran llevadas a cabo exclusivamente por el S.O. consumiendo valiosos ciclos de CPU. Recuerda el concepto de hairpining que mencioné antes, bueno, suponga que quiere clonar una VM de una LUN a otra, gracias a VAAI, el S.O. le da la orden a la cabina de discos de que clone los archivos de la VM de una LUN a la otra, y todo ocurre dentro de la cabina, a velocidad del bus de la controladora, de la forma más eficiente y por lo tanto más rápido. Existen muchas otras primitivas, no solo la de clonación, que liberan al S.O. de pesadas tareas.

Image 2

 

Virtual Volumes (VVols)

Antes de la virtualización los servidores físicos tenían acceso directo a los discos o las LUNs donde se instalaba el S.O., las aplicaciones o se guardaban los datos, la relación disco/LUN y partición era unívoca. La siguiente figura demuestra esta relación:

Image 3

La virtualización agregó una nueva capa de abstracción que llamamos DataStore (DS) y aparecieron los vDisks, como en la siguiente figura:

Image 4

Pero los vDisk eran solo uno (el más importante) de los archivos que definían a las VMs . Definimos las VMs como un conjunto discreto de archivos que podían ser guardados en un repositorio a nivel de bloque (VMFS) o de archivos/carpetas (NFS).

Supongamos que necesitáramos mantener replicadas ciertas VMs pero otras no. En este escenario (sacando vSphere replication) se hace a nivel de LUN, y replicaría todas las VMs dentro de esa LUN, o nos obligaría a tener dos LUNs, una con replicación y otra sin y a tener que determinar que VM creamos en que LUN, lo que complica la gestión. Es decir, los servicios de almacenamiento se centran en la LUN, y no en las VMs.

En el nuevo paradigma de Virtual Volumes volvemos otra vez al esquema original, tal como se puede ver en la siguiente figura:

Image 5

Con esta nueva tecnología la cabina de discos soportará en forma nativa los VVols, y ya no necesitamos definir LUNs ni estamos atados a los límites como por ejemplo el tamaño o capacidad de las mismas, ni a que los servicios de almacenamiento estén ligados a ellas.

El concepto de LUN centric desaparece con la tecnología de Virtual Volumes (VVols) y todo pasa a estar centrado en las VMs. Las VVols permiten tratar a los VMDKs no como un simple archivo, sino con la importancia que este se merece.

Bueno, hasta aquí esta primera parte de la nota sobre las novedades del SDS.

Los espero en la segunda parte para terminar de explicar el resto de los elementos que componen el VVol, y las QoS que podremos utilizar gracias a VASA 2.0.

Saludos

Alberto Giorgi.

 

One thought on “Novedades en el SDS

  1. Pingback: Novedades en el SDS, Parte II | OpenCloud.es

Deja un comentario