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!

Proxy ARP en VMware NSX: funcionamiento y consideraciones (2/2)

Continuando el tema que inicié hace un par de semanas, en éste post exploraremos un poco otro aspecto de la implementación de proxy ARP en la arquitectura de NSX, particularmente en la interacción entre redes VXLAN y redes “físicas” tradicionales (VLANs).

Hablaremos del DLR (Distributed Logical Router) que ejecuta, precisamente, funciones de enrutamiento desde el kernel space de los ESXi participantes del entorno NSX. Efectivamente y, como su nombre lo indica, es un router que está distribuido a lo largo de todos los hosts, todos ellos tienen el mismo router y tanto el plano de control como el de datos están distribuidos para no generar puntos únicos de falla. Como todo router lógico, sus interfaces también son lógicas, y son conocidas como LIFs (Logical Interfaces, –¿qué mas podrían ser? Winking smile ). Si requiero interconectar dos segmentos VXLAN, eso consume dos (2) LIFs y el enrutamiento se hace posible inmediatamente a lo largo de todos los hosts.

NSX 6.2 habilita, en éste sentido, un nuevo caso de uso: enrutamiento entre una red VXLAN y una red física (si, de las de VLAN). Como sabrán, la primera vez que se establezca dicha sesión, indefectiblemente tendrá que ocurrir una consulta ARP (“Tengo una IP, ¿donde está su MAC?) pero, ¿ésto significa que todos los hosts potencialmente estarán ejecutando ARP broadcast? Si la respuesta fuese si, no habría razón para éste post sino para hacer un Feature Request. Pero afortunadamente la respuesta es no, y es aquí donde el DRL hace uso de la Designated Instance.

Veamos de qué se trata.

He tomado prestado éste diagrama del buen Brad Hedlund y su post original al respecto del DLR con redes físicas. No teman, que ésto no es sólo una traducción, aportaré un enfoque diferente.

Figura 1. Entorno NSX con DLR conectado a red física. Tomado de bradhedlund.com

¿Se fijan cómo no hay hosts ESXi en éste diagrama? Bueno, para propósitos de claridad resulta útil que así sea, lo importante es que esa capa de NSX DLR está distribuida a lo largo de múltiples hosts y las tres LIF que utiliza están presentes en todos y cada uno de los hosts, hasta ahora todos son iguales.

1. La VM1 (que se ejecuta, digamos, en el host ESX1) requiere comunicarse con el equipo PH1 (quizá el proverbial ejemplo del servidor físico de base de datos) por primera vez, de manera que lanza una consulta ARP. La IP de PH1 es 192.168.0.100, por citar un ejemplo.

2. ¿Qué hará el host ESX1?.

Aquí nos detenemos un momento. Hay varias cosas que han sucedido antes que entráramos a la escena, y éstas son:

  • a. El controller cluster ha elegido a uno de los hosts ESXi para asignarle el rol de Designated Instance. El receptor de semejante honor tiene la responsabilidad de ejecutar todas las consultas ARP que vayan hacia/desde la red física y responderlas con su propia MAC (pMAC para ser preciso, que es una suerte de MAC address por LIF única por host). Ajá! allí estás proxy ARP. Curiosamente sólamente la documentación oficial se refiere al DI como un proxy ARP, y efectivamente lo es. En éste caso, vamos  a imaginar que el controller cluster eligió al host ESX3 para ser el DI de ésta red física específica.

b. El dispositivo físico (ya sea el servidor o router) cuenta con una ruta hacia la red de VXLAN cuyo next hop ó siguiente salto es la IP de la LIF del host ESX3 (la Designated Instance). Dicho en otras palabras, todo ésto es muy interesante pero no va a funcionar si hacemos tanto esfuerzo en enviar un paquete que luego no sabe cómo regresar.

— Dadas éstas consideraciones, podemos continuar:

El host ESX3 va a capturar la legítima consulta ARP que hace el ESX1 y, una vez tenga la respuesta va a actualizar su tabla ARP con una entrada que se vé así

IP Address MAC Address
192.168.0.100 (IP PH1) pMAC ESX3

3. Inmediatamente, el controller cluster publica la nueva entrada a todos los hosts en el clúster

4. Contrario a lo que podría pensarse, una vez que el paquete alcanza su destino, no retorna necesariamente por el ESX3 (Designated Instance). Si la VM1 está en el ESX1, entonces el paquete retornará directamente por el LIF3 del ESX1. SI la VM1 se mueve al host ESX3, entonces el paquete retornará por allí, pero sólo se debe a que la VM está presente allí. En otras palabras, el Designated Instance no hace parte de la ruta de regreso lo cual optimiza el enrutamiento de manera efectiva.

Como discutimos en la parte 1 de éste post, uno de los mayores argumentos contra proxy ARP es que crea una vulnerabilidad para ataques de tipo Man in the middle: si capturas al proxy ARP, entonces podrás falsificar toda comunicación de capa 2 y hacia arriba. Sin embargo NSX 6.2 incorpora un control para éste riesgo con el establecimiento de comunicación cifrada por SSL entre el controller cluster y los hosts ESXi; éste es el canal donde se transmite información sensible, como por ejemplo el host que ha sido elegido como Designated Instance.

Conclusiones

Utilizando funciones de proxy ARP, NSX puede entregar routing optimizado entre entornos virtuales y físicos así como una importante reducción en el tráfico broadcast debido a consultas ARP, lo cual agrega a los ya numerosos beneficios de la virtualización de redes.

Los comentarios son bienvenidos, saludos!