Comencemos con el porqué

Ya es célebre la TED Talk que Simón Sinek dió en el 2009 presentando el denominado “Circulo dorado” que, según Sinek, es una manera muy efectiva en que los líderes inspiran a otros a la acción:

El círculo dorado de la inspiración en un mensaje. Imagen tomada de https://bit.ly/2UWDzwt

Es también uno de los principios culturales de Nutanix iniciar con el porqué, luego el cómo y finalmente qué.

Después de casi 4 meses trabajando para Nutanix e interactuando con muchas personas dentro de éste ecosistema, he tenido que llegar a responderme (y responder a otros) una pregunta esencial cuya respuesta yo mismo necesito para mantener mi sentido de propósito en ésta labor:

¿Por qué Nutanix?

Es decir, ¿por qué alguien debería siquiera considerar a Nutanix como una opción para su infraestructura?

Madurez

Nutanix es el pionero y sigue siendo el líder en el segmento de hiperconvergencia de acuerdo con Gartner. Esto es un asunto ya conocido.

Por otro lado, Nutanix provee un sistema distribuido que entrega -como se espera de un Sistema Distribuido- un alto nivel de resiliencia/redundancia en el plano de Administración, Control y Datos. Captura las funciones vitales del datacenter para que se ejecuten de manera integrada y completamente en software: Almacenamiento, protección de datos, virtualización, administración y operaciones, seguridad y redes virtualizadas.

Valor

Adicionalmente, en el centro de la propuesta de valor de Nutanix se encuentran los siguientes aspectos:

• Simplicidad en todo el ciclo de vida: desde la adquisición hasta las operaciones. La complejidad cuesta a una organización, y mucho.
• Libertad para elegir: tanto el hipervisor (ESXi, Hyper-V o AHV) como el hardware
• Mantener el mayor nivel de satisfacción del usuario, así como el mejor soporte técnico en la industria. Esto se puede comprobar fácilmente con la métrica estándar de satisfacción de los usuarios -o Net Promoter Score– visible públicamente en https://customer.guru/net-promoter-score/nutanix. Basta comprobar allí mismo que el promedio de satisfacción en la industria de TI (si, eso incluye a todos los demás fabricantes) es de apenas 54 mientras que Nutanix se mantiene sobre 90.

¿Cómo lo logra Nutanix?

Ahora, algo más de detalle en cómo maneja Nutanix los diferentes aspectos del centro de datos, clasificados en Infrastructure Qualities:

• Disponibilidad

Hay una diferencia esencial en el manejo de fallas de Nutanix: se enfoca no sólo en garantizar la Disponibilidad de los datos ante una falla (lo cual lo pueden asegurar otras soluciones también) sino también asegurar la protección de esos datos durante la situación de falla (lo cual es particular de Nutanix).

Una solución estándar de Nutanix se compone de 3 nodos. Si alguno de esos nodos falla sucede lo siguiente:

1. Los datos alojados en el nodo fallido están disponibles inmediatamente en algún otro nodo del clúster pues por defecto siempre se crea una réplica de cada dato en otro nodo. 
2. Tan pronto como se detecta la falla del nodo, las VM se reinician en otro nodo y acceden a sus datos inmediatamente
3. También de manera automática y sin retardos, se inicia la réplica de los datos sobrevivientes para que estos no solo estén disponibles, sino también protegidos y la recuperación del nodo no se vuelva un asunto de emergencia, como ocurriría en una solución tradicional. No se requiere contar con 4 o más nodos para esta funcionalidad, empezando con 3 nodos ése es el funcionamiento.
4. El alojamiento y replicación de datos ocurren con una granularidad de 1MB. De manera que si es un disco lo que falla, no sólo la recuperación de la redundancia de esos datos inicia inmediatamente, sino que implica una carga mucho menor en la red y por ende un tiempo menor para lograr la reprotección de los datos.

Comportamiento de clúster Nutanix ante fallo de un nodo. Imagen de https://nutanixbible.com/#anchor-book-of-acropolis-data-path-resiliency

Por otro lado, al ser un auténtico sistema distribuido, la falla del dispositivo SSD/NVMe de caching no implica indisponibilidad de ninguno de los componentes del clúster.

• Administración

La gestión simplificada se lleva a cabo en Prism, sin importar el hipervisor o hardware que se elija, Prism es el punto central de gestión y visibilidad de todo el stack: hipervisor, VMs, almacenamiento, redes, nube hibrida. Las tareas más comunes de hipervisor y manejo de VMs se pueden ejecutar desde Prism, sin tener que acudir a la interfaz de gestión de la solución de virtualización.

Nutanix Prism. Imagen tomada de https://bit.ly/2tly7aL

El plano de Administración en Nutanix evita los puntos únicos de falla de manera nativa: cada nodo incluye una instancia del software de gestión, con lo cual por ejemplo en un clúster de 3 nodos, hay 3 instancias de Prism sin recurrir a ninguna configuración adicional. En caso de fallo de algún nodo, la capacidad de tener gestión de la plataforma no se ve afectada. Asimismo, si el software de gestión del hipervisor elegido llegase a fallar, Prism no tiene dependencia con éste y puede seguir entregando métricas y visibilidad de la infraestructura virtual.

• Desempeño

¿Por qué siquiera tomar en cuenta una solución de hiperconvergencia que no corre in-kernel? 

Nutanix despliega una controladora virtual en cada nodo, conocida como CVM (Controller Virtual Machine).

Es cierto que el camino más rápido a los datos es el que va por Máquina Virtual > Kernel hipervisor > Controladora local > Disco. Sin embargo ésto solamente será valido si se puede asegurar que ése es el camino que toma toda VM para acceder a sus datos y que no tiene que agregar el paso de ir a la red. Este atributo se conoce como Localidad de Datos y es garantizado por Nutanix siempre. No importa si las VM se migran entre host, siempre accederán a la copia activa de sus datos de manera local, es decir, en el mismo host en el que residen.

La razón de no depender de la red tiene que ver con el hecho que ni Ethernet ni los protocolos derivados de éste, fueron diseñados para el tráfico de almacenamiento. Aspectos como las retransmisiones, el control de prioridades (PFC) y el evidente tiempo y procesamiento que le toma a un dato “subir” y “bajar” por la pila TCP/IP al enviarse/recibirse por la red hacen que cada vez más el cuello de botella de un almacenamiento distribuido sea la red. ¿La solución sería asignar más ancho de banda? No importa si usamos 10/25/40 etc Gbps, los problemas fundamentales que mencionamos persistirían.

Por éste aspecto fundamental de diseño, el desempeño de aplicaciones de misión crítica en Nutanix puede ser considerablemente superior. Entre varios otros tipos de aplicaciones ya validadas, es también por ésto que Nutanix fue el primer proveedor de HCI en ser certificado por SAP para correr HANA.

• Recuperabilidad/resiliencia

Nutanix posee funciones nativas para la toma de snapshots ligeros, de muy bajo impacto en el desempeño así como en la ocupación de espacio de almacenamiento, haciendo uso del método Redirect-on-Write. Utiliza estos snapshots para proveer backup, así como la habilidad de entregar Self Service Restore, o restauración granular de los respaldos para los usuarios de las VMs sin tener que integrar ninguna herramienta de terceros. Adicionalmente, lleva a cabo replicación entre datacenters así como alojamiento de respaldos en la nube pública de Amazon o Microsoft Azure, todo de manera nativa. Un video de cómo funciona se puede encontrar en: https://www.youtube.com/watch?v=c6UKQPX8CE8 

• Seguridad

El software de Nutanix trae un nivel alto de hardening aplicado de fábrica. Adicionalmente, asegura que a lo largo de la vida de la solución siempre se mantenga alineado con el hardening pues automáticamente está verificando y resolviendo desviaciones, función conocida como SCMA o Security Configuration Management Automation. Por otro lado, el compromiso con la Integridad de los datos alojados en Nutanix es completo, pues el software automáticamente lleva a cabo revisiones frecuentes de checksum para cada extent almacenado en el clúster, resolviendo también automáticamente los problemas que encuentre al respecto.

El cifrado de los datos en reposo, lo puede llevar a cabo Nutanix incluso sin depender de una solución de terceros para el manejo de llaves (Key Management Servers) sino que nativamente puede cifrar cada dato alojado en el clúster para imposibilitar que sean accedidos al retirar los discos.

Conclusión

Hay mucho más que estaremos contando acerca de ésta historia, pero confío en que la información proveída en éste post sirva como referencia para muchos de los casos en los que ésta pregunta surgirá.

Saludos!

Una introducción a NVMe

La primera publicación en éste blog fue un intento por introducir la interesante ciencia que explica el funcionamiento de los Discos de Estado Sólido. El post ciertamente es sujeto de muchas mejoras, pero uno de los mensajes que trata de dejar es que el cuello de botella para el desempeño de los SSD es la interfaz SATA con la que se conecta y sus conocidas limitaciones de ancho de banda. Aunque éste problema puede resolverse utilizando interfaz PCI, el último bastión del rezago tecnológico en éste sentido ha sido el protocolo de comunicación entre el host y el dispositivo, pues se ha seguido utilizando SCSI que aunque es un protocolo con buenas características y muy amplia adopción, después de más de 30 años de su primera versión ciertamente deja ver que no fue escrito para medios diferentes a discos magnéticos.

¿Qué es NVME?

NVM (Non-Volatile Memory) es una clase de memoria que puede retener los datos aún cuando haya perdido la alimentación de energía (es decir, cuando esté apagado). Por su parte, una memoria volátil (RAM, por ejemplo) pierde el contenido que estaba alojando cuando deja de recibir alimentación de una fuente de poder. Cabe recordar que el tipo de dispositivo NVM más ampliamente conocido es el Disco de Estado Sólido.

NVMe es un protocolo para la comunicación con dispositivos de Memoria No-Volátil (NVM por sus siglas en inglés), desarrollado y mantenido por la organización NVM Express, fundada oficialmente en 2014 e integrada por 13 compañias promotoras entre las que se encuentran Cisco, DellEMC, NetApp entre otros.

¿Por qué era necesario NVMe?

Para poner en evidencia la necesidad y la razón de los objetivos de NVMe, es necesario primero hablar del protocolo SCSI en dos aspectos principales en cualquier modo de almacenamiento: escala y desempeño.

Escala en SCSI

El hecho que SCSI sea originalmente la sigla de Small Computer System Interface nos da una idea de la época en que fue concebido: 1986 para la primera versión. Se trata de un trabajo titánico que ha sido exitoso en evolucionar a lo largo de los años e integrar los distintos tipos de medios de almacenamiento que han surgido en más de 3 décadas. Sin embargo, ahí yace precisamente una de las dificultades de escala de SCSI: es considerablemente complejo al incorporar tantas tecnologías y medios diferentes como lo evidencia el diagrama del grupo de estándares bajo el comité T10:

T10, la organización a cargo de mantener y desarrollar los numerosos protocolos SCSI que se ilustran en la imagen; tomada de http://www.t10.org/scsi-3.htm

Por otro lado y también recogiendo la herencia de décadas, SCSI fue concebido y sigue funcionando bajo un modelo cliente-servidor:

Modelo cliente-servidor en SCSI. Tomado de http://www.t10.org/cgi-bin/ac.pl?t=f&f=sam6r04.pdf

Este modelo puede verse en operación en protocolos de bloque como iSCSI, Fiber Channel (initiator-target) o en discos locales Direct-Attached Storage (discos-controladora). Sin embargo el almacenamiento que se considere medianamente moderno no responde a éste modelo sino más bien a lo opuesto: componentes homogéneos, distribuidos, decentralizados y con una alta resiliencia.

Desempeño en SCSI

Los protocolos de almacenamiento conocidos hasta ahora trabajan con instrucciones referidas como comandos. Todo se trata de ellos. ¿Cuántos puedo enviar en simultáneo? ¿Cómo puedo verificar que un comando se completó con éxito o no? ¿Cómo optimizar el tiempo que toma el envío y verificación de un comando? Estas y otras preguntas son las que busca abordar un procolo de éste estilo.

La interfaz más veloz para SCSI que sería aquella en la que los dispositivos se conectan de manera serial (Serial-Attached SCSI o SAS) y que puede acomodar 256 comandos en una cola de espera (queue). Entre más comandos pudiese manejar en simultánea en su cola de espera, entonces mayor número de operaciones de I/O por segundo (IOPS) vería el host (cualquiera sea el sistema operativo).

Por otro lado, un aspecto ampliamente ignorado por años con respecto al desempeño de almacenamiento es el costo en CPU de ejecutar un comando. Esta variable se mide en ciclos de reloj y entre más bajo su valor, menor costo y por ende menor consumo de potencia y mayor desempeño:

En condiciones normales de operación, se requieren más de 70,000 ciclos de CPU para completar un comando SCSI. Eso son unos 30 ms o menos en procesadores modernos. Imagen tomada de https://bit.ly/2Eaf9MI

Para alcanzar mejor desempeño a menor costo en la gran escala, es necesario encontrar una manera más eficiente de consumir los ciclos de reloj. Entre otras razones porque SCSI no garantiza que al enviar un comando por un CPU core determinado, la respuesta llegue por el mismo CPU core, lo que implica manejar más interrupciones y por ende, mayor tiempo de respuesta.

Arquitectura y componentes de NVMe

La controladora

La interfaz de control de NVMe, esa que se ubica entre el host (se cual fuere el sistema operativo) y los dispositivos NVM tiene una característica primordial que vale la pena detallar:

Mecanismos optimizados para el envío y verificación de comandos

Lo que yo esperaría al lanzar un boomerang es que regrese a mi mano, no a la de la persona ubicada 10 metros a mi derecha. Pues bien, precisamente en SCSI el host podía enviar un comando (el boomerang) utilizando algún CPU core definido, pero no estaba garantizado que la confirmación de ejecución de ese comando retornara por el mismo CPU core. Este problema lo resuelve NVMe implementando una cola de envío de comandos (Submission queue) que conviva junto con una cola de verificación de ejecución (Completion Queue) en el mismo CPU core. Esto significa que en NVMe está garantizado que no tendrá que haber comunicación entre CPU cores (la cual ocurre a una velocidad limitada) para poder verificar la ejecución (Completion) de un comando y que en cambio, las capacidades de procesamiento en paralelo de los procesadores modernos estarán disponibles para el almacenamiento. Incluso la especificación más reciente, incluye la posibilidad de contar con más de una Submission Queue dentro del mismo CPU core compartiendo una misma Completion Queue para todos, lo cual eleva aún más la eficiencia de uso de los recursos de procesamiento, cuya capacidad sigue incrementándose con los años.

Ejemplo de colas de envío (Submission Queue) y verificación (Completion Queue) en el caso de un par por CPU core. Imagen tomada de http://bit.ly/2qfLgR2

El set de comandos

Hace unas líneas mencionamos que los dispositivos SCSI con interfaz SAS soportan hasta 256 comandos en una cola. Pues bien, NVMe soporta hasta 64.000 comandos por cola (!) y un máximo de 64.000 colas, lo cual deja bastante espacio para contar con un desempeño considerablemente más alto que en interfaces SCSI. En la práctica, los dispositivos PCI NVMe manejan números mucho menores de comandos y de colas, pero aunque éstos parámetros varíen entre fabricante, son bastante más altos que en protocolos anteriores.

Conclusiones

¿Hablar de almacenamiento en pleno 2018? No es precisamente de lo que quieren hablar o leer los chicos cool. Ya saben, todos queremos hablar de Kubernetes, service meshes, microservicios, arquitectura event-driven, etc etc. Sin embargo, aunque sigan apareciendo abstracciones y métodos -que todos ellos tienen su lugar por supuesto- el valor a largo plazo de las organizaciones siguen siendo los datos. Así que sigue siendo necesario tomar en serio los esfuerzos por garantizar un acceso eficiente y un almacenaje responsable de los mismos.

Saludos!

Primera página de un nuevo capítulo

Después de un prolongado e interesante proceso he decidido aceptar una oferta laboral por parte de Nutanix para trabajar como GTM Partner Systems Engineer, basado en Bogotá (Colombia).

Decir que estoy emocionado y tengo grandes expectativas es poco, pero más que todo estoy sorprendido, agradecido y comprometido.

¿Por qué Nutanix?

Hasta hace unos meses, la mayoría de mi lógica para una decisión laboral se basaba principalmente en aspectos técnicos como los features de la tecnología que tal o cual compañía produce, o la cantidad de tecnologías nuevas que la compañía que evaluaba decía soportar o apoyar.

Sin embargo, y como muchos en la comunidad lo saben, el año 2017 me llevó a enfrentar dos veces la posibilidad real de morir, y pasé muchas semanas en hospitales donde, si no estaba sedado o en el quirófano, tuve algo de tiempo para reflexionar sobre lo que es realmente importante en la vida. Eso cambió de forma permanente la manera en que tomo decisiones, en donde ahora tienen un papel mucho más relevante los aspectos humanos del trabajo y menos la técnica. Con “aspectos humanos” me refiero a aquello que me acerca a las personas, que me conecta con quien soy realmente y que, finalmente, me puede poner en el camino de cumplir el propósito por el cual aún sigo en la Tierra.

Esto traducido al lenguaje corporativo es lo que se conoce como cultura organizacional, y es la principal razón terrenal por la que me decidí por Nutanix: su cultura, expresada más que un sitio web, en las personas que conozco que trabajan para ésta compañía en la región.

Hungry, Humble, Honest, Heart. Este es el resumen de la cultura de Nutanix que condensa el carácter que debe primar en sus integrantes: ambición  por hacer crecer la compañía y darle a los clientes la mejor experiencia, humildad para reconocer las debilidades propias y enfocarse en su mejora, honestidad para saber cuando Nutanix no es la respuesta para las necesidades de un cliente y para alejarse de cualquier práctica injusta de mercado y corazón, para conectarse con las necesidades de las comunidades locales y aportar lo posible para suplirlas.

Por otro lado, no se puede poner en duda que Nutanix es el pionero en hiperconvergencia (HCI). Nutanix fue el primero en adoptar y ejecutar con éxito la visión de ésta arquitectura; creó un mercado que sigue hoy día liderando a pesar de competir con los pesos más pesados de la industria. Es una compañía joven con una misión clara que comparto al nivel más profundo: simplificar la tecnología para trasladar el beneficio al cliente. Lo ha hecho con éxito para el almacenamiento (el principal cuello de botella en un entorno virtualizado), lo ha hecho para los hipervisores y ahora planea hacerlo para las múltiples nubes: centralizar, desagregar y simplificar. Es fácil de decir, es tremendamente difícil de lograr pero el resultado vale la pena, y Nutanix ya ha demostrado su capacidad para creer en una visión increíblemente ambiciosa y ejecutarla con éxito.

¿Por qué yo?

Bueno, no tengo una respuesta contundente a ésto, porque la verdad no esperaba ser el candidato seleccionado, tanto por la abundancia de talento capacitado en ésta región como por mis particularidades como persona.

Soy un introvert (introvertido) y al menos en nuestras latitudes ese término es casi un insulto sinónimo de asocial, tímido, incapaz de relacionarse con otros fuera de su zona de confort o en pocas, invisible. Por ello y para un tipo de rol como Partner SE -que no es un consultor de servicios profesionales- muchas veces pensé que en algún momento del proceso el implacable arma del prejuicio iba a hacer que fuese descartado porque, ya saben, ‘es muy técnico, se le puede dificultar el relacionamiento’ o conclusiones a priori de ése estilo.

¿Cuál es la realidad ampliamente incomprendida acerca de la personalidad introvertida?

De acuerdo con múltiples publicaciones especializadas, esta personalidad trae al entorno corporativo unos beneficios que difícilmente otro tipo de personalidad puede producir:

• Construcción de relaciones: si, el introvert no es un discapacitado social. Simplemente se enfoca en la construcción de relaciones significativas y duraderas; y como ésto simplemente no es posible hacerlo con todas las personas, puede verse como un individuo de pocos amigos; pero en realidad, construir verdaderas amistades implica un esfuerzo y perseverancia que hace que cada amigo real sea sumamente valioso en el mundo de una personalidad introvertida. Por otro lado, las relaciones comerciales de un introvert suelen estar mucho más basadas en la construcción de confianza con su contraparte que en eventos sociales pasajeros que, en muchas ocasiones, no pasen de lo superficial.
• La habilidad de escuchar atentamente, más de lo que se habla.
• Observación: la atención por los detalles y una elevada sensibilidad hacia lo que ocurre en el entorno son características de un introvert.
• Pensamiento crítico: al entorno de trabajo le aporta la habilidad de ser consciente de las debilidades de sí mismo como individuo y enfocarse -con una motivación que viene de adentro- en el desarrollo personal y profesional continuo. Asimismo poder detectar con mayor independencia las falencias de su producto o solución y enfocarse en mejorarla, sin contar con que suele aceptar la crítica con un enfoque más positivo.
• Reflexividad: un introvert piensa mucho, mucho las decisiones. Principalmente porque acude más a la memoria de largo plazo para comparar decisiones y resultados anteriores así como para valorar consecuencias y oportunidades.

Dejemos que una imagen, tomada de éste fantástico post, lo resuma brevemente:

Respuesta del cerebro de un extrovertido vs. un introvertido a estímulos externos; por ejemplo: una decisión.

Lo que viene

Adquirir nuevas habilidades, servir a los partners de la región y hacer éste trabajo con amor, pasión y excelencia son las principales metas ahora. Alguien dijo que es necesario conocerse a sí mismo para poder saber cuál ese ese trabajo que amas. Durante todo éste proceso he tratado de ser honesto conmigo mismo y con el equipo de Nutanix acerca de mis fortalezas pero sobre todo mis debilidades; y el haber encontrado un lugar que respeta y valora las diferencias, me hace sospechar que voy a amar éste trabajo.

Y aprovecho la ocasión para hacer público otro de los compromisos que independientemente he decidido adquirir al aceptar ésta posición: no esparcir Miedo, Incertidumbre o Duda (FUD en inglés) acerca de ningún competidor de Nutanix, ninguno. Creo firmemente que son los clientes quienes al final deben elegir cual estrategia, producto o solución es mejor para ellos por lo que sólo usaré mi posición para aportar información relevante, para educar y empoderar a las organizaciones o individuos con quienes interactúe para que puedan tomar decisiones informadas, incluso cuando no se decidan por Nutanix. Y esto también porque un comportamiento peyorativo o agresivo hacia la competencia, al final siempre resulta en vergüenza. Después de todo he decidido creer la sabiduría que está escrita hace tiempo:

 A los necios no les interesa tener entendimiento;
    solo quieren expresar sus propias opiniones.

³ Hacer el mal resulta en la vergüenza,
    y la conducta escandalosa trae desprecio. 

(Proverbios 18:2-3)

Saludos!

 

 

Intent-based networking: mitos y realidades

Hace cerca de un año y medio viene haciendo su debut en la industria un nuevo  buzzword (término de mercadeo sobreutilizado hasta perder significado) que en ésta ocasión está enmarcado en el medio de las redes de datos: hablo de Intent-Based Networking.

El término fue acuñado por un independiente reporte Gartner y hace referencia a la siguiente promesa:

• Un modelo de operación en el que se le indica de manera prescriptiva a la red cuáles son los resultados esperados (Intent o intención), pero no se le indica el cómo lograrlo pues los dispositivos de red descubrirán por sí mismos la mejor manera de implementar la intención; y además provee mecanismos para remediar automáticamente cualquier desviación que la red presente con respecto a la intención original.

Esto suena muy bien a decir verdad.

El único problema es que ésta nueva tendencia se presenta como la novedad que estábamos esperando pero realmente no es nada nuevo y, como suele suceder, crea otros problemas adicionales. Dicho de otra manera: desvía la atención, rememorando una vez más el famoso efecto de “salchicha aplastada” (squashed sausage) según el cual -generalmente- la simplificación de un elemento del sistema, introduce una elevación exponencial de la complejidad en alguna otra parte del mismo.

Crema de dientes aplastada. El principio es similar: reducir el volumen en un área, suele producir que salga crema por otras partes más complicadas. (Las ilustraciones de salchichas aplastadas eran muy desagradables)

El trasfondo

Hace unos meses hubo un capítulo memorable del Packet Pushers Podcast en el que Greg Ferro e Ivan Pepelnjak tenían una conversación casual sobre varios temas de la industria. Una de las mentes más críticas en la industria IT (Greg Ferro aka ‘Etherealmind’) junto a un hombre cuya trayectoria profesional, rigurosidad técnica y experiencia académica lo hacen uno de mis modelos a seguir (Ivan Pepelnjak) reunidos discutiendo, es realmente digno de escucharse.

En ése capítulo surgió el tema de Intent-Based Networking y allí Pepelnjak daba seguimiento a lo que ya había escrito hace un tiempo preguntándose: ¿estamos seguros que realmente alguna vez le hemos tenido que indicar, por ejemplo, a un router cómo descubrir otros dispositivos vía OSPF? ¿O le decimos expresamente a cada interfaz de un switch cómo redireccionar paquetes hacia otras interfaces específicas?

Realmente no.

Entonces, siempre hemos estado haciendo Intent-Based Networking. No hay nada nuevo bajo el sol.

Los desafíos

Para hablar de un sistema Intent-Based en primer lugar y de acuerdo con el reporte IDC correspondiente, se requiere una infraestructura abierta de red para poder intercambiar información con un sistema central que reciba, procese, implemente y verifique la Intención. El reporte incluso menciona entre las ventajas de una infraestructura de ése tipo la habilidad de poder gestionar equipos de diversos fabricantes, todos bajo una misma política. La realidad de ésto es que actualmente la industria carece de estándares para el intercambio de datos entre infraestructura heterogénea y esto frena considerablemente el cumplimiento de tal promesa.

Por otro lado y tal como ocurre hoy día en nuestras redes tradicionales no-Intent-Based, la Intención sería implementada por los dispositivos de la manera en la que el fabricante decidió previamente que era la mejor y así parametrizó al software o a los dispositivos para hacerlo. Es decir, así como hoy día al configurar -por ejemplo- BGP en un router el funcionamiento y la manera en que implementa el protocolo están condicionados por la programación hecha previamente por el fabricante, así mismo un sistema Intent-based tiene unos límites y parámetros previamente dictados por el vendor. Por más que se incluya el término “Machine Learning”.

Y finalmente, la famosa verificación y remediación de la plataforma de red que haría un sistema Intent-based tiene un pequeño gran problema conceptual: el sistema va a la misma red que configuró a ‘preguntarle’ si lo que hizo está bien. Pensemos como un humano lo haría: si yo creo que lo que hice está bien y para validarlo voy directamente al sistema que implementé, seguro que puedo caer en un ciclo infinito de autoengaño convenciéndome, cada vez un poco más, que lo que hice está bien.

Conclusión

Antes de leer lo que Ivan Pepelnjak había escrito sobre éste asunto, yo había llegado a la conclusión que ésta tendencia sólamente es un nivel superior de abstracción, pero no es nada realmente nuevo del todo. Sentí que no estaba tan sólo en ésto ni tan errado cuando leí que él piensa algo similar.

Así como lo reza el mismo RFC 6670, si la complejidad que se agrega al sistema cuando se simplifican otras partes se traslada del hardware al plano de control, generalmente esto produce un beneficio económico. Por ello es muy loable la dirección que están tomando fabricantes como VMware con la versión más reciente de NSX Datacenter (6.4), llevando cada vez más funciones (y complejidad) a un plano de control 100% software.

Por lo demás, el objetivo de éste post era desahogarme (lo siento) y proporcionar algunos elementos de juicio para no caer tan rápidamente en un nuevo juego de buzzwords; que ya no necesitamos uno más.

Les dejo con ésta canción, que tiene todo que ver con el tema:

 

Saludos!

 

Por la justicia idiomática: el uso correcto del término ‘data’

Las presentaciones en público en el medio de tecnología son escenario de toda clase de contenido y todo tipo de presentadores(ras). En esa diversidad  ha habido una sutil práctica difundida por años que consiste en hablar de ‘la data’ para referirse quizá a la información alojada o tratada con alguna tecnología particular.

Siempre me ha causado mucha incomodidad escucharlo, especialmente porque ignoro el origen de ese hábito y la razón de su inconsciente adopción. Lo sé, esto parece irrelevante y más el delirio de algún amargado purista del idioma, pero creo que vale la pena pensar dos veces lo que decimos y cómo lo decimos, especialmente en un caso como éste que, a mi juicio, refuerza la idea que la imprecisión es aceptable cuando se usa para sonar más sofisticados, más en un medio como el de IT en que sufrimos de cierta fascinación por lo complicado, nuevo y muchas veces, innecesario.

Entonces, ¿cuál es la manera correcta de utilizar el término data?

Hace poco, el equipo de ese fantástico podcast que es “The Grammar Girl” dedicó todo un capítulo a esta palabra.

Es un término en latín que significa “lo que se da (por cierto) ” y que, al menos en el idioma inglés, se empezó a adoptar hacia el siglo XVII aunque no fue sino hasta finales del siglo XIX (es decir hace más de 100 años) que empezó a tomar su significado moderno de información, documento o sustento.

El problema es que data es una palabra en plural, siendo su forma singular datum. Asi que la expresión ‘la data’ es un exabrupto gramatical al usar pronombre singular con un sustantivo en plural. Entonces si vamos a hablar de “los datos” correctamente y en el idioma debido deberíamos decir ‘quod data‘ o en singular ‘el dato’ sería ‘et datum‘.

Y ya en ese punto entonces podríamos decidir seguir oficiando la presentación en latín, de espaldas a la audiencia, obligando a las mujeres en el público a cubrirse con un velo y demás particularidades de los ritos tridentinos.

Así que en conclusión, para evitar incomodar a los dioses del idioma y poder comunicar con precisión y claridad nuestro mensaje, usemos el español que es bastante rico, utilizando expresiones como ‘la información’ o ‘los datos’.

Suena mejor, es correcto y un poco menos arcaico.

Saludos!

IBM AIX en Nutanix AHV: ¿qué significado tiene?

La semana pasada uno de los primeros anuncios de la conferencia Nutanix .NEXT 2018 consistió en que ahora el sistema operativo IBM AIX® está disponible y es soportado para ejecutarse completamente virtualizado en Nutanix Acropolis Hipervisor® corriendo en la plataforma POWER® de manera nativa. Sin embargo, en medio de los anuncios de otros productos durante el evento, parece que una solución como ésta realmente no recibió la atención que merece.

¿Qué es IBM AIX?

Es un sistema operativo basado en Unix System V introducido en 1986 por IBM para las computadoras avanzadas de la época: las workstation 6150 RT. Desde sus inicios y hasta ahora, es reconocido como una de las plataformas de mayor desempeño y capaz de cumplir las restricciones de seguridad más estrictas entre los sistemas operativos disponibles; no en vano sigue siendo la opción elegida por compañías del sector financiero – entre otras- para ejecutar los servicios más críticos. En un estudio reciente de IDC con respecto al market share de servidores, se evidencia que AIX toma al menos 58% del mercado corriendo en la plataforma POWER®:

Imagen tomada de https://www.skytap.com/blog/ibm-aix-still-pillar-enterprise/

De hecho en el estudio más reciente de IDC, se evidencia un crecimiento de 36,4% en el segmento de Unix (non-x86) debido,entre otros, a AIX corriendo en POWER9.

¿Qué son los sistemas POWER?

IBM se hizo una pregunta a mediados de los ’80 que iría más o menos así : ¿por qué usar los procesadores de Intel y su creciente complejidad si tenemos la capacidad de crear los nuestros? La respuesta a esa pregunta se lanzó en 1990 bajo el nombre de ‘Power Optimization With Enhanced RISC (POWER)‘ como una nueva arquitectura de procesador con una premisa poderosa: ser tan simple que las instrucciones se pudiesen ejecutar a la frecuencia de reloj más alta posible. Además las instrucciones tenían un tamaño estándard (4 bytes) y un formato unificado lo que lo hacía considerablemente más rápido que sus competidores de la época. Y sigue siendo así.

Sin embargo la principal innovación que capturó la atención del mercado es que este procesador, el POWER1®, tenía sus funciones separadas lógicamente: el control, los cálculos de punto fijo y de punto flotante, todo estaba funcionalmente particionado. Este es el origen mismo de lo que años después IBM seguiría desarrollando como LPARs o Logical Partition que es la primera forma de virtualización que el mundo conoció y que hasta hoy sigue estando en el corazón de la plataforma POWER®.

Si amig@s, la virtualización no surgió hace 20 años sino hace casi 30 en Big Blue 😉

Nutanix + IBM

Ya hace un año se había anunciado una relación de partnership entre Nutanix e IBM que permite ejecutar de manera soportada AHV en hardware IBM OpenPOWER LC. Y aunque esto es interesante por sí mismo, ahora estamos hablando de la joya de los sistemas operativos de IBM, con décadas de inversión en desarrollo y un importante número de patentes a cuestas que, por primera vez, sale del universo de IBM para correr en una plataforma de virtualización diferente a PowerVM, al tiempo que sigue aprovechando la estrecha integración entre AIX y el hardware POWER®.

Una de las objeciones que uno escucha, o que incluso está entrenado para decir cuando se habla de plataformas AIX es que su escalabilidad es principalmente vertical y obedecen a una arquitectura centralizada. De alto desempeño si, muy segura por supuesto, pero al fin de cuentas centralizada con los problemas que esto puede acarrear, especialmente de escalabilidad o resiliencia; lo cual se acentúa en el entorno actual de cargas de trabajo cada vez menos predecibles en términos de uso de recursos, como los containers.

La oportunidad

Tener ahora la posibilidad de unir un hardware robusto, un sistema operativo maduro y consolidado más un hipervisor moderno y todos los beneficios de escalabilidad de la hiperconvergencia junto con la filosofía de simplicidad operacional de Nutanix, simplemente es demasiado interesante y relevante como para dejarlo pasar.

Las arquitecturas no-x86 siempre han sido, al menos para mí en el área de virtualización, lo que es la parte derecha de la tabla periódica: tierras raras. No han sido pocas las veces que he encontrado organizaciones que quisieran traer los beneficios de la nube privada o la hiperconvergencia a cargas no-x86 pero esto siempre nos ha parecido, digamos, imposible. La conversación termina cuando no hablamos de Windows o Linux.

Pero eso fue así hasta ahora.

La oportunidad ahora consiste en conocer más a fondo lo que AIX ofrece a las organizaciones y enfocarse en éste lienzo en blanco que se ha abierto ante nosotros: hiperconvergencia nativa para no-x86.

Saludos!

Cartas a un enemigo silencioso

Estimad@s lector@s

No me he desviado del carácter puramente técnico de éste blog. El título no es algún pseudo-ensayo de un aspirante a columnista. Sin embargo, el título es la que considero por ahora, la mejor manera de resumir el objetivo de éste post: empezar a arrojar luz sobre un enemigo silente que ha establecido un régimen en la mentalidad de todos los que hacemos parte del mercado de tecnología empresarial para hacernos pensar que es ésta la única manera concebida de hacer que la innovación surja y la tecnología funcione. Les hablo de la complejidad.

Allá por 1962 el venerado Herbert A. Simon estableció una definición de complejidad en su trabajo seminal titulado “The Architecture of Complexity” que va mas o menos así: un sistema complejo es uno compuesto de varias partes que interactúan entre sí de formas no simples. Otra característica de tales sistemas es que si conocemos sus componentes y lo que pueden hacer por separado, no es trivial inferir lo que hacen cuando se unen en un sistema completo.

De acuerdo con Simon, una de las principales estructuras de complejidad presentes en la naturaleza, las organizaciones y en general en nuestro universo es la jerarquía. Un sistema se considera jerárquico cuando se puede descomponer en diferentes subsistemas, los cuales a su vez se pueden seguir descomponiendo en otros. ¿Hasta cuándo descomponer? Lamentablemente en cada contexto, los diseñadores -o la naturaleza- definen lo que consideran una unidad fundamental debajo de la cual no hay más subdivisiones. Aunque la complejidad surge nada más con la presencia de la jerarquía, hay mayor grado de complejidad a medida que se amplía el número de subsistemas en los cuales se divide un sistema completo.

Todo lo anterior, y mucho más presente en el trabajo de Simon, no pasaría de ser un importante descubrimiento en la psicología organizacional de no ser porque allí se pone en evidencia un hecho muy importante: la complejidad cuesta, y cuesta mucho. Tiene un efecto profundo y duradero en los individuos y las organizaciones, reduciendo drásticamente su capacidad de agregar valor y exceder las expectativas que sus clientes o interlocutores tienen de ellos.

El costo de la complejidad: una parábola

Para ayudar a aclarar el tema, Herbert A. Simon incluyó en su articulo una parábola magnífica que resumo aquí: dos relojeros, uno de nombre Hora y el otro, Tempus. Los dos excelentes en su oficio y muy exitosos pues el teléfono de la oficina de cada uno sonaba con frecuencia con clientes del otro lado haciendo nuevos pedidos. Todo parecía ir bien, sin embargo después de un tiempo, Hora prosperó cada vez más con su negocio, pero Tempus fue decayendo hasta que tuvo que cerrar su local. ¿Que pasó?

Bien, los dos fabricaban el mismo tipo de reloj: una obra de arte compuesta de mil piezas. Sin embargo, Tempus trabajaba con cada componente pieza por pieza y tenía que terminar cada reloj en una sola sesión, entonces cada vez que sonaba el teléfono y debía contestar -lo cual era cada vez más frecuente- las piezas se desarmaban y debía iniciar desde cero. Por otro lado, Hora tenía las mismas 1000 piezas pero había diseñado su reloj de tal manera que podía agrupar 10 piezas y convertirlas en un subcomponente. A su vez, podía luego unir 10 de esos subcomponentes y convertirlos en una pieza mayor, y con 10 de esas piezas mayores tenía un reloj completo. Esto es, el diseño de Hora abstraía la complejidad inherente del reloj.

A través de unos cálculos matemáticos sencillos documentados en el artículo del profesor Simon, y que tienen en cuenta la probabilidad que cada relojero tiene de ser interrumpido, se llega a un estimado en que a Tempus le tomaba 4.000 veces más tiempo completar un reloj que a Hora. Pensémoslo un momento, el pobre manejo que hizo Tempus de la complejidad en ésta historia, hace que mientras un relojero satisface los requerimientos de 4.000 clientes, Tempus sólo satisface a uno.

Aterrizaje en IT

Entendido, ¿y ésto que tiene que ver con tecnología?

Todo.

Permítame ilustrarlo con un diagrama que elaboré en el que, después de un buen tiempo de experiencia en campo en el diseño, implementación y operación de servicios de nube pública, privada e híbrida; condenso sin exageraciones lo que sería una arquitectura promedio para una nube sin que necesariamente aplique para un solo fabricante:

Dependiendo el fabricante de elección, pueden haber más o menos componentes pero, al menos en mi experiencia, estos son los ingredientes promedio para una nube en un entorno enterprise. Y esto es sólo para proveer IaaS; otros modelos de servicio requerirán más componentes.

A la luz de las ideas del profesor Simon, este es un sistema complejo en toda su gloria: una jerarquía con múltiples subcomponentes que se interrelacionan entre sí de formas no triviales y para los que, si se toman por separado, no es elemental inferir exactamente qué es lo que hace el sistema completo.

¿Cuál es el costo de la complejidad en éste contexto?

Veámoslo por etapas:

Ciclo de ventas

Los que hacemos parte de esta etapa, estamos inmersos en un sistema que prácticamente premia la complejidad. Entre más componentes se agreguen mayor beneficio. Cada componente tiene decenas de features pero muy comúnmente se incluyen sólo por uno de esos features; lo demás permanece sin uso pero si requiriendo mantenimiento. Este aspecto parece poco visible desde esta etapa y ciertamente poco nos afectaría que nuestra flamante solución resulte en una enorme carga operacional, pero por el bien del beneficio a largo plazo de nuestras marcas y nuestros clientes, creo que un comercial o preventa sensato, debería pensar en esto.

Diseño

En esencia, la labor de diseño consiste en capturar exitosamente los Requerimientos del cliente, minimizar los Supuestos a través del levantamiento de información y un enfoque consultivo, identificar y documentar de manera anticipada los Riesgos y reconocer las Restricciones del proyecto. Entonces, cuando hay tantos componentes disimiles que pueden hacer tantas cosas e interactuar de tantas maneras entre sí, surge una complejidad que cuando menos, significa más tiempo en la etapa de Diseño y también una mayor probabilidad de dejar Riesgos sin contemplar o no lograr que el amplísimo mundo de Requerimientos -léase deseos– de un cliente, frente a las innumerables opciones que brinda el software se encuentren en una solución que realmente agregue valor y sea viable de implementar y operar.

Implementación

Esta es interesante. Las unidades de servicios profesionales -especialmente las de muchos fabricantes- son parte de éste esquema pues la estabilidad del trabajo y del nivel de ingresos está directamente relacionada con la complejidad que se le ha vendido a un cliente. Entre más compleja una solución, más sofisticado parece el consultor y mejor pagado es. Por otro lado, así como a Tempus le sucedía, la incapacidad de abstraer la complejidad hace que el trabajo sea serializado y obedezca a unas directrices de diseño que a todas luces favorecen la agregación de subsistemas y características a costa de tiempo de implementación.

El proyecto de nube de gran escala que más rápido he visto concluir ha tomado 5 meses. Eso en horas, y teniendo en cuenta solo un 70% facturable, daría unas 560 horas. Si éste es Tempus confeccionando su reloj y Hora tarda 4.000 veces menos, eso serían poco más de 8 minutos. ¿Habrá un día una manera de entregar un servicio como éstos para un entorno enterprise en un tiempo como ése? El tiempo lo dirá.

Operación

Esto se pone peor. Con una considerable cantidad de elementos disimiles por entender -para lo cual quizá requieran entrenamiento formal y servicios profesionales- y operar, la calidad de vida para quienes trabajan en ésta área se reduce con el tiempo. Esto lo he visto suceder en diferentes verticales y diferentes geografías y lo más frustrante es ver que parecemos aceptar que así es como son las cosas: es necesario correr listas de chequeo “preventivas” sobre todos y cada uno de los componentes, tratando de alinearnos con un evento de naturaleza cuasi aleatoria como lo es una falla en el software o hardware, y además contar con matrices de escalamiento, turnos rotativos, ventanas de mantenimiento, servicios profesionales para hacer actualizaciones (no quisiera vivir para ver uno más de éstos) y, en suma, consumir la vida tratando de evitar lo inevitable: el software eventualmente funciona y el hardware eventualmente falla. El problema aquí es que en un sistema complejo, el procedimiento para la resolución de problemas difiere de componente a componente y esto significa menor cumplimiento de SLAs, mucho mayor OPEX y en suma, mucha menor eficiencia.

Conclusión

Todo lo que escribo aquí es producto de muchas horas de reflexión solitaria al respecto de mi labor y el mercado de tecnología en el que me he desempeñado por años y, como espero hayan notado, no se trata de ningún fabricante en particular. ¿Cuál es el punto, cual es el objetivo entonces? Este es mi blog personal y como tal, es eso precisamente; una ventana también a lo que pasa por mi mente y que considero relevante compartir. ¿Este post va a cambiar en algo el status quo? Seguro que no. Pero al menos podrá ser útil para que otros más tomemos conciencia de cómo nos hemos convertido en mercaderes de la complejidad y que cada uno, desde su rol, puede hacer algo para abstraerla. No se trata de remover la complejidad o ignorarla pues ésta es una característica inherente de nuestro universo: con el tiempo todo evoluciona hacia lo complejo. Sin embargo, el desafío de las mayores mentes de la naturaleza – nosotros- en uno de los medios profesionales de mayor énfasis en el conocimiento – la tecnología- es que logremos absorber la complejidad y traducirla para las masas. Yo creo que ese si es el verdadero mérito intelectual en ésta profesión.

Saludos!

 

 

 

 

Conociendo a fondo el comportamiento de VSAN con Observer 6.5

Ha pasado un largo tiempo con distintas vicisitudes pero aquí estamos de nuevo retomando la escritura.

Quienes conocen VSAN, el almacenamiento definido por software de VMware, sabrán que VSAN Observer no es un tema nuevo sino que existe hace más de 3 años. Sin embargo, tanto tiempo después sigue siendo una herramienta ampliamente desconocida entre los clientes que usan el producto, de manera que este post busca dar una introducción al mismo para apoyar su adopción.

¿Qué es VSAN Observer?

Es un servicio de inspección, monitoreo y análisis del desempeño y estructura de un clúster con VSAN, y está disponible desde vSphere 5.5 U1. La utilidad corre embebida en vCenter Server (tanto Windows como VCSA) y está basada en RbVmomi, la interfaz de acceso al API de vSphere escrita en el framework Ruby.

¿Cómo acceder?

De aquí en adelante, los ejemplos los haremos con vCenter Server Appliance. NOTA: no es necesario desplegar un appliance separado, puede conectarse al vCenter donde reside el clúster de VSAN..

1. Iniciar sesión SSH al vCenter Appliance con la cuenta de root
2. Escribir rvc SSOAdmin@localhost . NOTA: SSOAdmin típicamente es administrator@vsphere.local. Este comando debe escribirse SIN invocar el bash shell del appliance, sino directamente después de iniciar sesión SSH:

3. Dirigirse a cd localhost

4. Dirigirse al Virtual Datacenter con el comando cd nombre_de_datacenter    NOTA: es posible encontrar el nombre de datacenter con un ls

5. Iniciar Observer contra el clúster:  vsan.observer computers/nombre_del_cluster –run-webserver –force

Verán una buena cantidad de texto generarse en la sesión SSH terminando con algo similar a

2018-01-14 19:02:24 -0400: Live-Processing inventory snapshot
2018-01-14 19:02:24 -0400: Collection took 10.60s, sleeping for 49.40s
2018-01-14 19:02:24 -0400: Press <Ctrl>+<C> to stop observing

Si es así, hemos iniciado correctamente VSAN Observer

6. Ahora conectarse a la interfaz web usando el navegador a https://vCenter_IP_o_FQDN:8010 e ingresando el password del SSOAdmin:

Procedimientos comunes

a. Revisar el desempeño global de cada host en el clúster. Esta información se encuentra directamente en la primera pantalla que Observer despliega (VSAN Client):

En ésta sección, hay métricas conocidas pero otras que ameritan conocerse mejor:

• Latency stddev: la desviación estándard, esta piedra filosofal de la estadística descriptiva, indica que tan alejados están los datos del promedio. Entonces, Observer mide la latencia promedio de cada host y, a lo largo del tiempo, la dispersión de cada medida de latencia con respecto a la media. Un valor alto de ésta métrica en VSAN es un indicador claro de desempeño inconsistente causado, por ejemplo, por problemas en uno o más discos locales, latencia de red entre hosts, entre otros.
• Outstanding IO: indica el número de solicitudes enviadas por VMs hacia VSAN que aún no se han completado. Números altos pueden ser el comienzo de un problema de latencia y pueden deberse a encolamiento de comandos SCSI en la controladora de almacenamiento local, de manera que es recomendable adquirir controladoras con un QD (Queue Depth) alto; éste valor puede verificarse para cada modelo en la lista de compatibilidad de VMware,

b. Verificar el desempeño de cada disco (tanto Capacity como Cache) en cada uno de los host (para ésto es necesario primero seleccionar el host del menú desplegable):

¿Cómo reconocer cuál es el disco ó los discos de cache?: sólo para ellos se obtiene la métrica WriteBuffer Fill que -como su nombre lo señala- muestra el porcentaje de ocupación del buffer de escritura del dispositivo de caching para VSAN. También es importante aclarar que este cache no guarda ninguna relación con las capacidades de caching que eventualmente pudiese tener la controladora de discos locales que, en todo caso, debería estar deshabilitada.

Los datos importantes en ésta sección son, principalmente:

• Latency:  se trata de una métrica agregada de escritura y lectura
• RC Hit Rate: porcentaje de solicitudes de IO que son tomadas de la cache de lectura. En realidad no hay buenos o malos valores en ésta métrica, todo depende del patrón de IO de las aplicaciones que estén usando a VSAN.
• Evictions: el número de operaciones de liberación de la cache. Es el mecanismo de la mayoría de sistemas que usan caching para mantener espacio disponible en esa capa, por lo que VSAN hace un destaging o movimiento de datos no solicitados de cache hacia los discos de capacity.

Conclusión

El almacenamiento de objetos de VSAN no es elemental y comprende varios mecanismos para la protección de los datos, manejo de fallos y desempeño entre otros. Contar con una visibilidad profunda permitirá a los administradores comprender mejor y apropiarse más del funcionamiento de ésta plataforma, y allí es donde VSAN Observer juega un papel importante. Algunos recursos adicionales que pueden consultarse para profundizar en el tema son el manual de uso y el KB # 2064240.

Como siempre, espero sea de utilidad.

Saludos!

GENEVE: una porción del futuro disponible hoy con NSX-T

Fue hace unos seis años cuando tuve el primer encuentro con lo que –para ése momento- era una tecnología muy joven en el campo de redes de centro de datos: Virtual Extensible LAN o VXLAN y las posibilidades que permite me dejaron cautivado. En su momento era un draft, pero ya hace un par de años es un estándard establecido por la IETF y su adopción no ha parado desde entonces convirtíendolo casi en el sinónimo de virtualizaciòn de redes (o SDN para los más osados) en el entorno empresarial.

Esquema de una trama TCP con el header adicional de VXLAN. Cortesía de http://bit.ly/2ukgJSe

Hemos escuchado el discurso al respecto: un header de 24 bits adicionales que nos permite transportar hasta 16M de redes virtuales; es todo lo que necesitamos por mucho tiempo.

Con el problema de escalabilidad de las VLAN tradicionales (que solo llegan hasta 4093 redes) resuelto, la industria volcó su esfuerzo a ampliar la soportabilidad de éste protocolo y fue así que casi todos los fabricantes de hardware de conectividad han llegado al punto de ofrecer dentro de su portafolio, equipos que soportan de manera nativa el protocolo e incluso pueden fungir como gateway traductor entre VXLAN/VLAN y viceversa.

Entonces, ¿hay algo más que hacer en éste campo de los protocolos de encapsulación? ¿No es suficiente con STT o VXLAN?

Parece que no. Y la principal razón es sencilla: flexibilidad.

¿Con que otro insumo podríamos garantizar la interoperabilidad, agilidad y automatización de una infraestructura de red moderna sino con flexibilidad?

Elaboremos mejor en que aporta específicamente GENEVE en éste caso.

¿Qué es GENEVE?

GENEVE (Generic Network Virtualization Encapsulation) es un esfuerzo conjunto de Microsoft, Intel y VMware entre otros para evitar crear un nuevo protocolo de redes virtuales (u overlay) al que ahora todos debamos actualizar, sino más bien crear un mecanismo modular que sea fácilmente adaptable a la infraestructura existente y mucho más rico en funciones para las redes de hiper-escala del futuro cercano.

Esquema de trama GENEVE donde el único contenido fijo es de 8 bytes. Tomado de http://bit.ly/2ukimzk, adaptado de http://bit.ly/2tmFFvb

Aunque apenas completa 3 años de haber sido creado como draft o borrador en la IETF y aún no es un estandard completamente definido, la simplicidad de GENEVE es convincente: un header cuyo contenido inicial es de sólo 8 bytes (comparado con 50 bytes de VXLAN) en el que se transporta el ID de la red virtual (Virtual Network Identifier o VNI) y el campo Protocol Type. Todo lo demás es completamente definible para la implementación particular, lo que podría resultar en un tamaño de trama menor al de VXLAN (1550 bytes) pues solo transporta la información que se considere necesaria, elevando así la posibilidad de extender las redes virtuales a lo largo de la WAN, donde normalmente Jumbo Frames no es una opción viable de extremo a extremo.

Suena bien, pero… ¿alguien lo está usando?

Veamos.

 ¿Qué es NSX-T?

NSX-T es quizá la primera aventura seria de VMware fuera de su zona de comfort: un producto completo de virtualización de redes y seguridad pensado para entornos donde vSphere no está presente. Lanzado hace muy poco y con su versión 1.1 apenas liberada en Febrero de éste año, denota un esfuerzo intencional de investigaciòn y desarrollo para el mundo multi-hipervisor.

Arquitectura de NSX-T para entorno KVM. Imagen tomada de http://bit.ly/2tqELP7 <-Recurso recomendado

Aunque amerita un post aparte introducir NSX-T, podemos mencionar por ahora que conserva una arquitectura similar a su contraparte en vSphere (NSX-v) pero incorpora mejoras que lo hacen ver como el producto de elección para un entorno heterogéneo de nube privada o híbrida. Por ejemplo incluye:

• Un modelo de routing multi-tenant que muestra beneficios inmediatos para operadores de nube que ya se han encontrado con los enormes retos de conectividad en un entorno heterogéneo
• Nodos Edge (virtuales o físicos) que aprovechan las ventajas de Intel DPDK para elevar considerablemente el desempeño del procesamiento de paquetes haciendo uso del recurso de CPU de los nodos de cómputo. Esto es enorme.

Y claro, aparte de éstas y otras características, la que nos compete en éste post: a partir del release 1.1 (Feb 2017) NSX-T usa GENEVE para transportar las redes virtuales.

Una porción del futuro, disponible ahora.

 Implicaciones de adopción de GENEVE

Es importante mencionar que, por la misma naturaleza que describimos acerca del protocolo aquí, adoptar GENEVE en una red de datacenter actual:

• No requiere adquisición de equipamiento especializado
• Puede interoperar con topologías complejas que hagan uso de enrutamiento dinámico (muy común en redes medianas/grandes o en ISPs)
• Viabiliza aún más el santo grial de la conectividad multi-cloud: transporte de funciones de red y seguridad a lo largo de diferentes entornos; privado, público e híbrido sin que sufran modificación. Esto requiere una enorme dosis de interoperabilidad ayudada por protocolos como GENEVE.

Conclusión

Así como BGP, LLDP –entre otros- son protocolos que dominan ampliamente su campo y han podido evolucionar y adaptarse exitosamente a las demandas modernas al adoptar un enfoque de flexibilidad, GENEVE se augura como ese sustrato confiable en el que se puedan diseñar y ejecutar los requerimientos de virtualización de red para los entornos más complejos, móviles y heterogéneos del ahora y el mañana.

Saludos!

¿Tráfico legítimo es bloqueado por el NSX Distributed Firewall?

Recientemente tuve la oportunidad de participar en un proyecto de microsegmentación con VMware NSX 6.2 en el que vi “saltar” los flags TCP del libro de texto a la realidad y además pude evidenciar que realmente el Distributed Firewall de NSX es stateful (bueno, no es que no lo creyese, pero verlo es diferente).

Pues bien, para tener visibilidad de éstos eventos lo primero es configurar la regla de DFW (ya sea creada directamente allí o a través de Service Composer) para que genere logs:

En el instante en que se guarden los cambios, los logs empezarán a redirigirse hacia la entidad externa de syslog. Dado que toda edición de NSX cuenta con vRealize Log Insight dentro del paquete de licencias y que el Content Pack de NSX para Log Insight da cuenta de una integración muy cercana entre los dos, puede ser quizá la mejor opción para el análisis de eventos de NSX el utilizar Log Insight, como lo veremos en éste caso.

El three-way handshake revisitado

Al iniciar con el análisis de los eventos generados para la regla default de una de las secciones que había creado para éste proyecto, empezaron a surgir conexiones cuyas características no daban para ser capturadas por la regla default sino por una de las reglas definidas a nivel superior. Por ejemplo, tendría una regla de éste estilo:

IP origen	IP destino	Puerto destino	Acción
ANY	192.168.0.0/24	88 (TCP)	ALLOW
ANY	192.168.0.0/24	ANY	BLOCK

Sin embargo veía múltiples mensajes en los logs con éste tipo de información:

2017-03-03T16:22:22.313Z ESXi-host dfwpktlogs: 25833 INET match PASS domain-c8235/1024 IN 40 TCP 10.22.131.45/51495->192.168.0.10/88 RA

Veamos,

IP origen: no importa

IP destino: hace parte del rango definido en la regla

Puerto destino: 88 TCP, permitido

Entonces, ¿por qué lo habría de capturar la regla default?

Claro, en ése momento la regla por defecto estaba configurada para permitir todo (por ello el PASS) pero cuando se habilitara la acción de bloquear (como todo regla default en un firewall usando enfoque positivo) estos paquetes aparentemente legítimos empezarían a bloquearse.

La respuesta vino al revisar nuevamente la teoría. Dentro de la trama (frame) TCP estándar hay espacio para 6 posibles banderas (flags) –explicadas brevemente aquí– pero un firewall de tipo stateful (es decir, que mantiene registro de cada sesión/conexión y mantiene la inspección hasta que las sesión/conexión se cierre) va a cotejar un intento de conexión contra las reglas definidas siempre y cuando contenga el flag SYN, que es con el que se establece la conexión:

Imagen tomada de resources.infosecinstitute.com

Sin embargo y como una de las ventajas precisamente de los firewall stateful, éste no permitirá un nuevo intento de conexión con la misma combinación de origen/destino mientras esté activa la conexión ya establecida (evitando session hijacking, que es a lo que estaría expuesto un firewall stateless).

Así que, visitando nuevamente nuestro críptico mensaje de log:

TCP 10.22.131.45/51495->192.168.0.10/88 RA

La comunicación se estableció en las siguientes etapas:

1. El equipo 10.22.131.45 solicita una sesión a la IP 192.168.0.10 y le solicita que se establezca por el puerto 88 (usando SOCKET API)

2. El Distributed Firewall validó esa conexión haciendo match con la regla configurada y por lo tanto la permitió pues estaba configurada para ello

3. El host destino (192.168.0.10) respondió al origen con los flags SYN+ACK para confirmar la recepción de la solicitud y establecer la sesión, pero lo envió por el puerto 51495 TCP

4. Ante esa respuesta, el origen (10.22.131.45) respondió con RST+ACK (de ahí el “RA” en los logs!) para rechazar la solicitud pues el puerto no está abierto. Esto no cierra la conexión, pero hace que el host 192.168.0.10 tenga que enviar su SYN+ACK por un puerto abierto según le informe el destino.

La razón por la que ese paquete con flags RST+ACK no es permitido por el DFW es la prueba reina sobre el caracter stateful del mismo: no permitió una solicitud de (re) establecer la sesión con la misma combinación origen destino pues la conexión ya se había establecido en el punto 3 (desde el punto de vista del firewall).

De manera que, por esa misma vía, el monitoreo de logs del DFW puede enfocarse en los paquetes con flag “S” y no en todo lo demás pues sólo corresponde al funcionamiento saludable y normal de TCP.

¿Por qué el destino enviaría una respuesta SYN+ACK por un puerto tan exótico? Esto depende enteramente de la aplicación, en éste caso se trataba de Kerberos y da luces sobre el desafío que implica traer microsegmentación a un mundo de aplicaciones que no contemplaron la posibilidad de que existiese un firewall este-oeste en la red.

Espero les sea de utilidad

Saludos!