Apuntes sobre el funcionamiento de VXLAN sobre OVS en Nutanix Acropolis Hypervisor

Acropolis Hypervisor (AHV) es la respuesta de Nutanix a algo que no todos los fabricantes de infraestructura siquiera se hubiesen detenido a pensar: VMware ESXi es el líder de los hipervisores tipo I en la industria, pero puede contener más características de las que muchos clientes llegan a conocer: ¿sería posible construir un hipervisor que brinde una alternativa viable y soportada a ESXi con las funcionalidades necesarias?

Hubiese querido iniciar la exploración de Acropolis Hypervisor en orden pero bueno, el networking es un tema que siempre captura mi atención (después de todo, es quizá el campo más académico de la industria de IT); así que en éste post veremos algunos apartes sobre el esquema de redes que AHV entrega para las máquinas virtuales.

Open vSwitch

AHV implementa la conectividad usando Open vSwitch (OVS), que es un proyecto de código abierto respaldado por Linux Foundation y que busca desarrollar un switch virtual (creo que lo intuyeron ya) pensado desde su inicio para la automatización y programabilidad. Brinda muchas de las funcionalidades que un vSphere Distributed/Standard Switch entregarían pero con un enfoque abierto. Soporta características suficientes como para considerar su introducción en las empresas, o es mi conclusión al ver en la lista a:

  • LACP
  • STP y RSTP (si, aún no han muerto)
  • NIC bonding
  • IPv6
  • IEEE 802.1Q support (VLANs para los más tradicionales)
  • Protocolos de tunelamiento: GRE,STT, Geneve y …. VXLAN

¿Para qué VXLAN?

Bueno, quizá no soy la fuente más independiente para hablar de overlays, pues vengo trabajando con VXLAN hace unos años y escribiendo también (mi post al respecto ahora es una de las referencias en la Wikipedia!). Sin embargo y aunque no es para nada el único protocolo de tunelamiento, VXLAN es el que más ampliamente se ha implementado y cuenta con un amplio soporte por parte de fabricantes en el espacio de hardware y software de redes modernas.

VXLAN es, en resumen, el habilitador de la flexibilidad de redes capa 2 dentro del centro de datos y (proveídos algunos requerimientos sencillos) entre centros de datos remotos. Esto es grande, más grande de lo que muchos hemos entendido pues si las cosas salen como lo esperan el 70% de las compañias consultadas por IDC, la nube híbrida será el modelo más ampliamente implementado en un par de años. Y si quitamos del camino los demás factores de un proyecto de éste estilo, al final del día el aspecto que realmente hace que sea viable o no es precisamente la extensión de las funciones de red y las políticas y controles de seguridad desde las premisas del cliente hacia la nube pública. VXLAN no es necesariamente requerido para ello, pero agrega una eficiencia digna de la escala de la nube (webscale).

Por otro lado, hay al menos un túnel VXLAN en ejecución internamente en AHV y es utilizado para distribuir las respuestas a solicitudes DHCP en el IPAM (IP Address Management) interno.

¿Como funcionaría?

Lamentablemente, este es otro post teórico, por lo que todavía será sujeto de completa verificación en campo. Pero con la documentación en mano y una dosis de experiencia con VXLAN puedo aportar los siguientes apuntes:

  • Actualmente OVS no soporta los aspectos multicast de VXLAN de los que, en todo caso, muchos fabricantes están tratando de alejarse; como es el caso de VMware con NSX y su soporte para Unicast desde las primeras versiones.
  • El que OVS no soporte VXLAN Multicast crea una necesidad: establecer un plano de control. El mismo RFC 7348 indica que éste plano debe ser distribuido y no administrado centralmente. En AHV ésa labor la cumplen las CVM alojadas en cada nodo (vaya que hacen multitasking éstas VMs).

Me he tomado la libertad de usar la siguiente imagen de la Nutanix Bible en la sección 4.1.4. Networking para tratar de describirlo mejor.

Open vSwitch Network Overview

Toda máquina virtual en AHV es conectada directamente a un puerto tap (como un puerto de escucha) que entra a ser parte del entorno OVS interno al que también está conectada la vNIC de la CVM (vnet0). El que se trate de un puerto tap me hace pensar que internamente, hay alguna forma de replicación o escucha de tráfico en ambas vías que debe ser el medio por el cual el CVM cumple su rol en la parte de redes frente a las VMs y las VMs hacen allí sus diferentes solicitudes al respecto.

Pero, ¿cuál es ése de rol de las CVM? Bueno, similar a como ocurre con el Controller Cluster de VMware NSX, las CVM actuarán como el plano de control “aprendiendo” ´y distribuyendo información de enrutamiento a todo el clúster Nutanix en el cual tengan alcance. Adicionalmente, deben ser las responsables de mantener y actualizar la tabla de Forwarding (entradas ARP) y distribuirla a todos los nodos. Por supuesto ésto crea ventajas pues con AHV no sería necesario desplegar un producto adicional para tener acceso a una red más controlada por software (siempre han sido definidas por software las redes) y habilita la flexibilidad y optimización propias de un overlay con VXLAN que tiene su plano de control distribuido.

 Ideas finales

En caso que AHV soporte nativamente el protocolo de administración de OVS (OVSDB), entonces una integración adicional con los equipos de red físicos es posible y allí toda esa valiosa información de enrutamiento y forwarding sería aprendida y distribuida no sólo dentro del entorno virtualizado sino hacia la red física de transporte. Algunos fabricantes de hardware de red ya soportan éste protocolo, entre ellos Cumulus Networks que está haciendo un trabajo formidable en crear infraestructura abierta y escalable para redes de todos los tamaños. En caso que AHV no lo soportara, habría que considerar VMware NSX que desde sus inicios cuenta con ésta característica.

Conclusión

Estoy consciente que éste post no resuelve una pregunta que se haga todos los días, pero si se que muchos competidores de Nutanix apuntan al “complejo” modelo de redes de AHV como un punto negativo. Aunque no lo he descifrado en éste post para nada, consideré oportuno empezar la exploración de éste tema por el núcleo de todo que es OVS y VXLAN. Espero les sea de utilidad en alguna medida.

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!

Sistema de archivos distribuido: el verdadero habilitador de la hiperconvergencia

Algunos colegas del medio TI con quienes he interactuado, argumentan que la hiperconvergencia va en contravía de lo que dicta la arquitectura del Software Defined Datacenter: abstraer las funciones claves del centro de datos lejos de las especificaciones y limitaciones del hardware. Y esto lo mencionan pues –dicen- el funcionamiento y beneficios de la hiperconvergencia están atados a una arquitectura de hardware pre-definida y rígida.

Sin embargo la realidad de la  hiperconvergencia (o Integrated Systems como los llaman los analistas), que busca unificar la mayor cantidad de funciones clave del centro de datos en nodos –teóricamente- independientes y autónomos entre sí para que en suma operen como un gran bloque unificado; puede convertir la apreciación de mis colegas en una ventaja competitiva.

Y es que, en mi opinión, contar con una arquitectura de hardware predefinida puede brindar múltiples beneficios acogidos, de nuevo por el enfoque webscale:

  • Funcionalidades predecibles: debido a que, por naturaleza, hiperconvergencia se trata de una muy estrecha integración entre software y hardware, si minimizo el riesgo de incompatibilidad en la capa de hardware, puedo confiar en que obtendré las mismas características de software siempre, y son éstas últimas las que realmente interesan y aportan valor. Esto es como un mundo nuevo: no más Hardware Compatibiliy Lists o particularidades del hardware que impiden la actualización del sistema operativo (hipervisor) que allí se ejecuta y bloquea nuevas funcionalidades.
  • Menor carga operacional: lo sé, suena a bullet point de una presentación de ventas. Pero es un aspecto de diseño muy importante y pocas veces tenido en cuenta. Si el hardware se compone de elementos estándard con interconexiones y configuración pre-establecidas, se reduce considerablemente el esfuerzo de desplegar infraestructura para el centro de datos, manteniendo la homogeneidad.

La salsa secreta

Honestamente, ensamblar servidores con un factor de forma reducido (tipo half-width) en un chassis con funciones de interconexión de red y un software de administración es algo que prácticamente todo fabricante ha hecho y seguirá haciendo: antes se llamaban blade chassis, tiempo después con algo de sofisticación y variando el factor de forma se rebautizó como convergencia. Nada nuevo allí.

Solo hay 4 recursos que en realidad se pueden gestionar en el datacenter virtualizado: cómputo (memoria + CPU), redes, almacenamiento  y seguridad. Aún no ha visto la luz un mecanismo para agregar CPU y RAM a lo largo de un clúster –esto es, que si cuento con dos servidores físicos y creo una VM con 2 GB de RAM, 1 GB provenga del servidor 1 y el otro 1 GB del servidor 2. En cuanto a las redes existen diferentes mecanismos pero, desde el punto de vista de un puerto de switch, una sesión TCP particular en un sólo sentido no se distribuye tampoco a lo largo de múltiples puertos en simultánea.

Pero, ¿que hay del almacenamiento? Podría alguien lograr que, si asigno capacidad a una VM ésta provenga de más de una fuente simultáneamente? Eso sería la materialización de mi principal petición al enfoque webscale.

Pues bien, de éso precisamente se trata un sistema de archivos distribuido que en mi opinión, es la verdadera diferencia entre convergencia e hiperconvergencia. En otras palabras, me atrevería a decir que cualquier oferta actual de HCI (Hyper-converged infrastructure) sin un mecanismo para agregar y gestionar el almacenamiento de manera unificada no es verdadera HCI.

Ahora bien, la fuente de ese almacenamiento es lo que tiene el verdadero mérito: almacenamiento local en los servidores. Si, DAS (Direct Attached Storage) de aquel que se huye si uno busca hacer uso de características avanzadas en un hipervisor y que – a pesar de sus considerables ventajas como alto desempeño (si está bien diseñado), bajo costo- ha sido históricamente desplazado por los arreglos SAN.

Recordando mi anterior post: si pudiese unir varios hosts con discos locales a un clúster y el sistema de archivos agregara toda esa capacidad para gestionarla de manera unificada, entonces definitivamente tendría la vía fuera de la SAN.

Eso es lo que actualmente ofrece VMware con Virtual SAN y otros fabricantes. Sin embargo a cada quien lo que corresponde: sin ser un experto, veo en el sistema de almacenamiento de Nutanix una implementación especialmente madura y eficiente: me refiero al Distributed Storage Fabric (DSF).

Por longitud, lo trataré en posts posteriores pero solo cabe resaltar que Nutanix tampoco ignora que la salsa secreta es el DSF en principio; no en vano el buen Steven Poitras lo menciona como el componente que está en el corazón y el nacimiento mismo de la compañia.

Saludos!

Webscale para no webscalers

No, este no es un post patrocinado ni he sucumbido repentinamente a la fiebre de las buzzwords o términos de marketing abusados hasta el punto que no tienen significado alguno (ya saben como SDN, Software-Defined bla bla o Cloud).

El término webscale se refiere, en resumen, a una operación de TI de una escala comparable con los gigantes de internet (de ahí lo de web) como Google, Amazon, Facebook, etc. El término ha sido acuñado recientemente por Nutanix –más que cualquier otro,

Debido a que Nutanix genera atracción/controversia en la comunidad de virtualización por diversas razones, me pareció pertinente condesar en éste post lo que entiendo por webscale, mi experiencia personal/profesional con ello y por qué podria interesarnos al resto de los mortales que quizá pasemos a mejor vida sin nunca haber pisado un datacenter donde los servidores físicos se cuentan en unidades de 1,000.

La historia, mi historia

Corrían los primeros meses del 2012 y yo me encontraba trabajando para un ISP local (en Colombia) para encargarme del diseño y puesta en marcha de la infraestructura tecnológica para su nueva unidad de negocio de Computación en la Nube.

Resumiendo la historia, adoptamos un enfoque tipo Agile en que se iban liberando pequeñas nuevas funcionalidades para ésta plataforma 100% virtualizada, tratando de responder lo más rápidamente posible a las demandas de los clientes, traducidas por la fuerza de ventas en los países donde éste Service Provider tiene presencia.

Sin embargo, con el tiempo y el crecimiento constante del producto nos encontramos con una gran dificultad. Ya habíamos sorteado muchísimas antes pero ésta parecía un muro muy alto en el camino para nuestras aspiraciones: el almacenamiento centralizado (SAN) era muy complicado de escalar (léase caro y demorado) y a medida que la agregáramos capacidad a una SAN existente, estaríamos profundizando nuestra dependencia de un gran SPOF (Single Point of Failire) o Punto Único de Falla que ya nos había demostrado en el pasado, como era capaz de afectar seriamente los SLA hacia los clientes y hacernos fallar en la promesa de crear verdadero multi-tenancy operacional: los problemas del tenant A serían contenidos y no afectarían a ningún otro tenant. Esto es muy difícil de lograr cuando los tenant siempre tienen un punto en común que no obedece o reconoce completamente la lógica multi-tenant que yace en capas superiores.

Por esos días, yo había empezado a conocer acerca de Nutanix y su lema de ése momento que era: NO SAN.

nut_nosan
¿Recuerdan esto?

Así que fui con la propuesta al CTO: “si queremos salir de éstos problemas, tenemos que salir de las SAN, debemos dejar de usar SAN” : ésas fueron las palabras que usé.

Tomó un tiempo pero, de hecho después de varias sesiones llegamos a nuestro manifiesto de peticiones que saldríamos a tratar de encontrar en el mercado o lo construiríamos nosotros:

  1. Queríamos poder crecer rápida y fácilmente
  2. Queríamos que, al agregar nodos de cómputo, al mismo tiempo estuviésemos agregando capacidad de almacenamiento
  3. Soñábamos con un sistema de archivos distribuido que se alimentara de servidores con discos locales y creara un almacenamiento compartido para poder seguir utilizando vSphere HA, DRS, etc
  4. Queríamos que la infraestructura fuese realmente un commodity, desechable si así lo podemos llamar y poder concentrarnos en desarrollar la inteligencia en el software

Por diferentes razones no técnicas, al final la decisión fue construir los nodos con hardware OEM y usar una forma de sistema de archivos distribuido soportada. Las dificultades vinieron pero los resultaron tampoco se hicieron esperar y opacaron las largas noches de trabajo: la unidad de negocio de Nube había crecido considerablemente y se ha establecido en un lugar de relevancia en Colombia, al tiempo que habíamos formado un diverso y amplio equipo de trabajo gracias; principalmente, a la agilidad que nos entregaba éste enfoque y la incrementada habilidad para responder a los requerimientos de nuestros clientes así como una reducción considerable en la dependencia de alguno de los elementos de la infraestructura en la disponibilidad y recuperabilidad de la plataforma.

Si bien no teníamos un sistema de archivos distribuido tan sofisticado como el de Nutanix u otros fabricantes, habíamos tenido el primer vistazo del enorme poder que entregaba el enfoque que, solo años después vino a conocerse como webscale.

La relevancia para el resto de compañias

Si estás leyendo aún, te agradezco, porque el punto inicial pareciera perderse en una historia sobre el desafío de colaborar para un Service Provider. La realidad es que nuestro “manifiesto” apunta a unos requerimientos que el enfoque Webscale puede proveer; es decir estábamos buscando ése enfoque sin saberlo:

  • 1. Reducir la complejidad en la operación
  • 2. Crecimiento gradual, lineal y ágil
  • 3. Distribuir las funciones a lo largo de la infraestructura: no más grandes entidades centralizadas de las que depende todo
  • 4. Mayor enfoque en el software que en el hardware

Soy consciente que quizá para un empresa pequeña o incluso mediana el crecimiento de la infraestructura no es  una tarea frecuente y, por ende, no suele ser una preocupación. Eso puede reducir la atención en la característica número 2 de mi listado, pero todas las demás se enfocan en optimizar la operación y elevar la mirada de los racks y centros de datos hacia la capa donde está el verdadero valor: las aplicaciones.

¿Cuál es la razón por la que escribo éste post y otros que estoy preparando? No trabajo para Nutanix, ni siquiera para un partner de ellos pero considero una tarea pendiente para mí el poder indagar mejor la propuesta de un fabricante con tanta presencia en ésta comunidad, apartando el marketecture y todas las discusiones en Twitter.

Espero haber aportado algo de claridad en éste tema.

Saludos!