Localidad de datos: relevancia e implementación en Nutanix DSF

Por la física clásica sabemos que todo camino que imponga menos resistencia al movimiento requiere menos esfuerzo para ser transitado. Vamos, que ésto lo sabemos hasta por el sentido común de cualquier caminante Winking smile

Pues bien, ésto también es completamente cierto en el movimiento de datos en una red. Si podemos minimizar el número de “saltos” que un paquete debe dar en la red, reduciremos el costo (esfuerzo) de la comunicación. Es más, si podemos lograr que el paquete no tenga que viajar, consideraríamos a ése dato como local y llevaríamos el costo de la comunicación casi a cero. Un dato que no tiene que desplazarse tiene un riesgo mínimo de ser afectado en el movimiento (corrupción, pérdida) y con seguridad llega más rápido al destino pues origen y destino son el mismo lugar.

Este concepto se conoce como localidad de datos y en éste post pretendo describir con ligero detalle su funcionamiento y particularidades en Nutanix DSF.

Funcionamiento

Consideremos un bloque Nutanix NX-3060 G5 de 3 nodos con un Replication Factor de 2. Con una sola VM ejecutándose en el clúster, una versión muy simplificada de como se vería se ilustra en el siguiente diagrama:

image

Como vimos en un post pasado, los vDisk/VMs se alojarán en DSF en forma de extents de 1MB compuestos por bloques de datos contiguos. Con un RF=2 vamos a tener dos copias de cada extent distribuidas a lo largo del clúster, siendo una de ellas la copia Activa que es entregada por el CVM local en el nodo donde la VM se está ejecutando (“Extent1” en el diagrama). Desde NOS 4.5 y superiores, y si los datos del Extent son de uso frecuente (datos calientes); Nutanix DSF mantendrá en caché solamente la copia local del extent mientras que las copias remotas (y los extent locales de acceso no frecuente) se alojarán en el almacenamiento persistente o SATA tier; ésto para elevar la eficiencia en el uso del precioso espacio de los dispositivos flash.

¿Qué sucede si la VM es migrada o el nodo falla?

Vamos por partes, Jack.

Si la VM del diagrama es migrada al Nodo 02 y debe leer nuevamente el Extent1, la lectura se hará localmente y si la consulta es frecuente, el CVM subirá los metadatos del Extent1 al Unified cache del Nodo 02. ¿Qué sucede si la VM1 va a escribir un nuevo dato en, por ejemplo, Extent2? Esa escritura se hará primero localmente y se replicará luego a otro nodo para cumplir con el RF.

Ahora, ¿qué pasa si la VM requiere leer un dato que estaba originalmente en el nodo 01? Bien, ese dato será migrado a través de la red desde el Nodo 01 al Nodo02 pero en forma de Extents de 1MB. (Este nivel de granularidad en un eventual movimiento de datos es algo digno de anotar porque no está presente en el almacenamiento distribuido de otros fabricantes y beneficia el desempeño, lo cual espero ampliar en éste post). En éste punto, el diagrama se vería ahora así:

image

Inmediatamente luego que la VM se migra al Nodo 02, Nutanix DSF pone en marcha la Gestión de ciclo de vida de la Información (ILM por sus siglas en inglés) y trasladará metadatos entre niveles de caching o desde/hacia el Extent Store (capa persistente a.k.a. SATA tier) aprovechando los recursos y nivelando la utilización de los mismos a lo largo del clúster desde el momento cero.

El comportamiento es similar si el Nodo 01 fallara, con la diferencia que se crearía una nueva copia de los Extent que residían en ese nodo.

¿Qué sucede cuando se agregan nodos al clúster?

Si se agregan nuevos nodos y se migra allí la VM, entonces los datos (extent) que esté utilizando (el Active Working Set que es visible en Prism) se migra inmediatamente al nuevo nodo e ILM hace de ahi en adelante su trabajo para optimizar el uso del espacio de memoria/SSD a lo largo del clúster, mientras que Stargate se encargará también que sólo se modifique una copia del caché al mismo tiempo, para mantener la coherencia de los datos allí alojados (cache coherence).

Ventajas del enfoque Nutanix

Bueno, durante todo éste tiempo he evitado hacer comparaciones con otras plataformas de hiperconvergencia que conozco y seguiré evitándolo en lo posible porque no creo tener toda la visibilidad y autoridad para hacerlo.

Sin embargo, encuentro dos ventajas competitivas que Nutanix DSF brinda en cuanto al manejo de la localidad de datos:

Escalabilidad

Hay dos conceptos importantes en localidad de datos:

  • Localidad temporal: datos referenciados recientemente tienen más probabilidad de ser referenciados en el futuro cercano.
  • Localidad espacial: datos con ubicaciones cercanas entre sí tienden a ser referenciados dentro de cierto rango de tiempo

(Buen recurso académico sobre el tema aquí)

Así como otros productos del mercado, Nutanix DSF hace uso de los dos tipos de localidad sin embargo, su diferenciador se ve en el momento en que se agregan nuevos nodos a la infraestructura. En ese caso y como lo vimos en éste mismo post, Nutanix inmediatamente empezará a hacer uso de los recursos de cómputo, redes y almacenamiento que provean esos nodos y se encargará de mantener la eficiencia y nivelación global en uso de recursos. Sin embargo otras plataformas -que se precian de no mover datos después que una VM ha sido creada-, fallarían en utilizar la capacidad de nuevos nodos pues aunque la VM de nuestro ejemplo se moviera a un nuevo nodo (Nodo 04 digamos), aún así seguiría accediendo de manera remota a sus datos en los nodos originales, dejando esa nueva capacidad de flash y SATA sin utilizar.

Esto no sólo significa un impacto en la eficiencia en uso de capacidad, retorno de la inversión y demás, sino que también puede impactar de manera negativa al desempeño. En el siguiente punto puedo dar más luces sobre ello.

Menor dependencia en Ethernet

La verdad sea dicha: Ethernet es un estándard no construido para servir como transporte de almacenamiento. Se han propuesto e implementado una diversa cantidad de protocolos que buscan en suma lo mismo: atenuar las dificultades del estándard para servir como un medio confiable y que garantice cero pérdidas (lossless), como sí lo promete FiberChannel – que a su vez crea otras limitaciones, etc.

Uno de esos mecanismos es Flow Control que básicamente es un árbitro en el medio, quien notifica al equipo que envía I/O cuando está enviando más contenido del que se puede recibir actualmente en el destino y trata de atenuar gradualmente el volumen, así como de informar cuando se pueden incrementar ése volumen. De ahi incluso, se derivan aún más protocolos cada vez más sofisticados.

Otras plataformas de almacenamiento distribuido temerariamente afirman que es muy seguro depender de la red para mover datos en tamaños de bloques (algunos hasta de 256GB vs 1MB de Nutanix DSF) y moverlos preventivamente a todos los nodos puesto que hoy día lo común es contar con redes a 10G y dentro de poco viene 25G y 40G.

En mi opinión: no. No y no. El problema no se trata de ancho de banda –además que no todas las compañias tienen todo el stack a 10G- sino de la eficiencia de la red en el manejo de datos. Un problema fundamental como éste, no se soluciona simplemente arrojándole ancho de banda.

El enfoque Nutanix muestra una dependencia mucho menor en la red por medio de:

  • Movimiento de datos con menos frecuencia: sólo extents remotos si éstos son solicitados; no se mueven datos “preventivamente”
  • Movimiento de unidades mucho más pequeñas: si realmente es necesario mover un dato, la granularidad del extent reduce considerablemente la posibilidad de estár moviendo datos innecesarios. Es como evitar rentar el camión de mudanzas para trasladar sólo un par de medias, porque las necesitaba.

Conclusión

Quizá no haya un sólo enfoque infalible en cuanto a la localidad de los datos, pero si hablamos de uno que puede involucrar simultáneamente un manejo eficiente del espacio de flash, el aprovechamiento balanceado de los recursos del clúster y una dependencia reducida en las particularidades de la red para beneficiar el desempeño y la gestión de la capacidad; entonces estamos ante un jugador de peso en éste segmento, como lo es el Distributed Storage Fabric de Nutanix.

Espero haber aportado algún contenido de valor.

Saludos!

Advertisements

Protección nativa de datos en Nutanix Acropolis Distributed Storage Fabric

Continuando con la exploración de las características de Nutanix Acropolis DSF, en éste post trataré de brindar luces sobre algunos mecanismos que ésta plataforma utiliza para la protección de datos.

Lo que no es

Primero, es necesario empezar a pensar diferente para abordar la protección de datos moderna. Lo que hemos conocido tradicionalmente es la redundancia N+1 como medida base y, en muchas ocasiones, la máxima protección que podemos lograr. Esto lo vemos por ejemplo en los almacenamientos tradicionales con doble controladora que, en el mejor de los casos, serán Active/Active pero que manejan conceptos de propiedad  u ownership de las LUNs. En caso que una controladora falle, el sistema queda en un estado de frágil disponibilidad y las LUN que eran propiedad de la controladora fallida deben ser accedidas por un bus interno de menor desempeño, afectando el rendimiento (LUN trespassing de la vieja escuela).

También vemos éste principio en el diseño de clústers de cómputo donde se reserva la capacidad equivalente a un host adicional para proveer redundancia, o más en general, al tratar de introducir redundancia para mejorar la respuesta del sistema ante un fallo: doble tarjeta de red, doble HBA, doble blade chassis, RAID, etc.

Sin embargo, pensando en gran escala (o webscale si se quiere) surge la pregunta: ¿exactamente en que punto es necesario pasar de N+1 a N+2, o N+x? Es un método que tiene problemas de escalabilidad y que todavía está por verse qué tanta eficiencia reduce en el aprovechamiento de recursos del sistema.

¿No se podrá hacer diferente?

Redundancia y replicación

Acropolis maneja dos conceptos que en otras plataformas se condensan en uno solo (Failures to Tolerate anyone?) o que simplemente no se encuentran completamente. Veamos:

Redundancia: también se puede llamar Resiliencia, pero en todo caso debe responder a la pregunta: ¿cuántos componentes del sistema pueden fallar garantizando que siga respondiendo de manera confiable? La respuesta a ésa pregunta es un número conocido como Redundancy Factor o RF. Es necesario aclarar que Acrópolis considera “componentes” a un disco, una interfaz de red o un nodo completo.

Replicación: quizá el más antiguo de los métodos para proteger datos sea mantener más de una copia de los mismos: este principio rige los backups (respaldos), los niveles de RAID (excepto el 0), entre otros. Sin embargo en el caso de Acrópolis se mantienen múltiples copias de un dato así como del elemento que guarda información acerca de un dato: el metadato.

El número de copias de un dato que se mantienen en un clúster Acropolis se conoce como Replication Factor o RF. ¡Momento!. ¿No es confuso nombrarlo así teniendo en cuenta que el Redundancy Factor tiene la misma sigla? Bueno, es que están tan interrelacionados que en la práctica nos podemos referir a ellos con el mismo término. Esto amerita un dibujo:

image

En ésta figura se ilustra (conceptualmente) lo que sería un bloque Nutanix de 2U en rack y que contiene 3 nodos (puede contener hasta 4, ej. el modelo NX-3060 G5).

El RF es un parámetro que se configura desde Prism a nivel de container; entonces ¿qué sucede al configurar RF=2?. Detrás de cámaras ocurren varias cosas:

1. Cada dato será replicado a otro nodo en el bloque para así, tener dos copias del mismo (RF=2)

2. Sólamente hasta que esa réplica se complete, se considerará exitosa la escritura del dato (consistencia fuerte en toda su gloria, lo veremos en otro post)

3. Se establece una redundancia implícita de componentes: si el disco Dn falla, siendo el disco que almacena el dato B1 en el nodo 1 de nuestro diagrama; no hay problema: el dato está almacenado en un disco del nodo 2 e inmediatamente el CVM del nodo 2 iniciará una nueva replicación del dato B1 para cumplir la configuración de RF=2. Lo mismo sucede si todo el nodo 1 falla.

Es por ello que al configurar el Replication Factor en Prism, implícitamente estamos configurando el factor de Redundancia del sistema.

Entonces, de manera más general se puede decir que:

Redundancia = (Replication Factor) – 1

Asi que en nuestro ejemplo, si configuramos RF=3 para el container entonces se soporta el fallo de dos nodos, o de dos discos y así sucesivamente.

Interesante, pero no estaríamos hablando de almacenamiento moderno si nada más moviésemos bloques aquí y allá. ¿Habrá un elemento más ligero que un bloque, que almacene información relevante sobre un dato pero no el dato mismo?. Oh si, hablamos del metadato.

Acropolis le da un tratamiento de primera clase a los metadatos, después de todo son la columna vertebral de un sistema de archivos distribuido.

Veamos:

Un anillo para controlarlos a todos

Con respecto a los metadatos, Nutanix ha adoptado el uso de una versión modificada de Apache Cassandra (¿qué tan modificada?- lo veremos en un próximo post). En Cassandra –que no es otra cosa que una base de datos noSQL de alto desempeño y escalabilidad-, todos los nodos participan en una topología de distribución de datos de tipo anillo pensada para garantizar principalmente, Consistencia y Tolerancia a fallos (pueden ir adelantando –por favor- la lectura del teorema CAP, para un próximo post en que trataré esta parte).

La protección de metadatos se implementa con un factor de replicación no dependiente del RF configurado para el container y que corresponde a un número impar y dinámico, pues se adapta al tamaño del clúster.

Volviendo a nuestro NX-3060-G5 de 3 nodos, el metadato M1 por defecto se replicará en los 3 nodos (RF=3) aunque el RF de los datos sea de 2:

image

De los 3 nodos, se requiere elegir un coordinador que administra la ubicación de los metadatos en el clúster. Ese coordinador es 100% reemplazable (si falla, se elige un nuevo coordinador de entre los nodos restantes) y es una implementación del proyecto Apache Zookeeper (hay tanto que hablar aquí sobre sistemas distribuidos, que realmente planeo cubrirlo en publicaciones posteriores).

¿Descontento con los resultados de las más recientes elecciones? Bueno, en sistemas distribuidos se busca que las elecciones sean justas. En el caso de Acropolis, se implementa Paxos que es uno de los algoritmos de consenso más ampliamente utilizados. Ese algoritmo requiere que el número de nodos sea impar para evitar situaciones de empate en las votaciones que los nodos hacen para elegir al coordinador.

Es por ello que en un bloque Nutanix con 3 nodos, aunque configuremos RF=2 para los datos, para los metadatos tendremos en la práctica un RF=3 (metadatos replicados en los 3 nodos).

¿Que sucede si agrego un nodo más? El RF de metadatos sigue siendo RF=3.

¿Y qué sucede si agrego otro bloque? En ese caso, con al menos  5 nodos el RF de metadatos puede subir a RF=5 y comienza el maravilloso baile de Apache Cassandra para incluir nuevos nodos en el anillo de tal manera que la distancia entre nodos se mantenga igual y los dominios de falla se distribuyan, ahora, a lo largo de dos bloques. (Si no es muy claro, es porque amerita otro post específicamente sobre la escalabilidad que aporta Cassandra)

¿Comparable con RAID?

Confío que en este punto sea un poco (poquito) más claro que no tiene mucho lugar comparar Distributed Storage Fabric con un arreglo RAID, sin importar el nivel, por ejemplo y hablando de replicación de datos (no de metadatos):

Nivel de RAID Símil en Acropolis DSF
0 RF =1 (no recomendado)
1 RF =2 tiene el mismo overhead pero no implica el Write penalty de RAID1 (2)
5

RAID 5 tiene Write penalty de 4; no existe ese concepto en DSF

6 Con RF=2 se soporta fallo de un (1) disco pero no existe el Write penalty de 6 (!)
1+0 Si uso RF=3 duplico la resiliencia comparado con RAID1+0 que soporta un (1) fallo

Fíjense que en esta breve e incompleta comparación me baso en tolerancia a fallos y algo de desempeño, sin siquiera tocar el tema de eficiencia en espacio. Entonces Acropolis DSF puede igualar y superar con creces éstos factores comparado con un arreglo RAID y si introducimos el ingrediente de escalabilidad, la comparación se hace menos necesaria.

Conclusión

Este post me costó mucho trabajo, lo admito. Y aunque he tomado previamente cursos en Sistemas Distribuidos para la nube, me costó trabajo unir algunas partes en mi mente y tratar de ilustrarlas aquí. Estoy seguro que el post está lejos de ser completo o realmente claro pero vamos, podemos así iniciar una parte muy interesante de ésta exploración.

He tratado de desenfocar el componente de storage de Acropolis porque creo que hay más que ello pero todavía falta mucho descubrimiento. Lo claro es que como en algún momento lo expresé en Twitter, Nutanix no es un startup de almacenamiento y ni siquiera un vendor de hiperconvergencia (con I latina)sino algo muy diferente: una compañía de sistemas distribuidos.

Saludos!

Componentes del Nutanix Distributed Storage Fabric (DSF)

Un componente fundamental y fundacional de Nutanix Acropolis (y de Nutanix como producto) es el Distributed Storage Fabric, como razonamos en un post pasado.

En éste post no brindaré una traducción de la fuente principal pero sí trataré de aportar comentarios que puedan ayudar a entender mejor los componentes del DSF y también, reflejen mis impresiones al respecto.

Generalidades

A pesar de mis primeras apreciaciones –que como todas, no son precisas- el DSF es mucho más que un sistema de archivos distribuido. Es una plataforma, un producto vivo en si mismo (si me permiten lo lírico) que implementa de una manera muy sofisticada la gestión del ciclo de vida de la información (ILM) que allí se aloja; manteniendo criterios de resiliencia, redundancia, eficiencia y alto desempeño.

Componentes

El siguiente diagrama pretende resumir la arquitectura del DSF en relación con sus componentes básicos:

image

Storage pool

Aunque mi reflejo inicial fué compararlo con el Storage Pool de las SAN tradicionales, hay una diferencia importante. El Storage Pool de Nutanix DSF es una agrupación de dispositivos de almacenamiento de varios tipos: PCIe SSD, SSD y HDDs. Hasta aquí, muy similar. Sin embargo, se trata de una bodega de capacidad de almacenamiento que es distribuida y por defecto, crece linealmente a medida que se agregan nodos al cluster. Esto es crecimiento scale out que es otra consecuencia positiva del enfoque webscale, como lo dedujimos previamente.

¿Se parece a como operaría la adición de shelfs/DAES/expansiones de discos a una SAN tradicional? No, debido a que en ése caso sólo estoy ampliando la capacidad disponible mientras que el plano de control y administración sigue siendo centralizado (controladoras/Storage Processors); profundizando la dependencia de cada vez más datos en unos componentes que no son infalibles, mientras que el Storage Pool de Nutanix cuenta con todos sus planos (administración, control y datos) distribuidos y por ende, pensados con la realidad de los fallos en mente, manejándolos con mucha mayor redundancia y resiliencia.

Container

Bueno, no está relacionado con Docker/Kubernetes/Mesos y todos sus amigos. Es más bien, una sub-división lógica del Storage Pool y reciben algunas opciones de configuración de manera global. Al tratarse de una sub-división, puede haber más de un container por Storage Pool. Por otro lado, típicamente se crea un datastore por container –por fin un término conocido: datastore. Estos son los volúmenes que por NFS/SMB se presentan al hipervisor.

vDisks

Aquí empieza a tomar verdadera distancia DSF de la mayoría de esquemas de almacenamiento (object/block) que haya conocido. DSF tiene visibilidad de los discos virtuales de las VMs: ya sean vmdks/vhds/etc. La manera en que ésta granularidad resulta en alto desempeño y eficiencia en el uso del espacio, la veremos con moderado detalle en éste post.

Lo primero que hay que decir es que no se alojan los vDisk asi nada más, sino que se sub-dividen en piezas más pequeñas llamadas Extents

Extents

En general en sistemas de archivos, un extent es un área de datos que deben cumplir una condición: ser considerados contiguos, es decir que no exista separación entre ellos. Ahora, eso tiene un límite y éste varía entre sistemas de archivos, pero todo lo que se ubique dentro de ese límite o longitud del extent se considera contiguo.

image

Un sistema de archivos eficiente busca trabajar con datos contiguos pues ésto beneficia el desempeño: la búsqueda de segmentos de almacenamiento a lo largo de regiones dispersas implica tiempo y recursos, lo cual se traduce en latencia y carga de CPU/RAM; mientras que con datos contiguos se optimiza el uso de éstos recursos.

¿De qué tamaño son esos bloques que se alojan dentro del extent? Eso depende del sistema operativo de las máquinas virtuales pues de allí directamente es de donde vienen. El DSF  lleva a cabo las operaciones de escritura/lectura/modificación no en todo un extent a la vez, sino en porciones del mismo, conocidas como slices (tajadas/rebanadas). El bloque es la unidad fundamental del almacenamiento (block), y como podrán notar, es a ése nivel que trabaja DSF; considerable nivel de granularidad.

Extent Group

También DSF lleva a cabo la agrupación de múltiples extent y corre sobre ellos tareas de deduplicación (ya saben, evitar guardar múltiples copias del mismo bloque). Dependiendo del éxito que tenga deduplicando, el extent group puede ocupar 4MB o llegar hasta 1 MB. Lo interesante es dónde y cómo se almacena: en el dispositivo de almacenamiento administrado por la Controller Virtual Machine o CVM que corre en cada nodo Nutanix. (NOTA: ¿les había mencionado que ese dispositivo se pasa directamente a la CVM sin abstracción? Direct-Path I/O en vSphere; se me ocurren muchas ventajas de ello que después abordaré Winking smile ) Además el Extent Group se distribuye por partes a lo largo de nodos (striping) lo cual beneficia el desempeño a la hora de leer bloques del extent group.

Conclusiones

Este post surgió de revisar con detalle sólo algunas páginas de la Nutanix Bible, que es una documentación escrita con la claridad, detalle y transparencia que realmente ya uno extraña de otros fabricantes. Mientras revisaba éste material pensaba que en mi humilde opinión, Nutanix no debería enfocarse en competencias de IOPs con otros vendors; la verdad la vasta mayoría de aplicaciones ni siquiera necesita todos esos números. Pero si el propósito fuese comparar y al menos juzgando por lo que conozco, el enfoque y sólida implementación del sistema distribuido que Nutanix es, no tiene punto de comparación con otras soluciones.

Debo recordar que éstos posts los escribo voluntariamente, me motiva el hecho de encontrar que un antigüo e indeleble interés profesional mío hoy encuentra protagonismo en el datacenter: los sistemas distribuidos.

Saludos!