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!

Advertisements

One thought on “Protección nativa de datos en Nutanix Acropolis Distributed Storage Fabric

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s