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.

toothpaste
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!

 

Advertisements

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®:

unix1

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ó?

tempushora

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:

Cloud_arch_complex

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:

observer01

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:

observer02

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):

observer03

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):

observer04

¿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.

Image result for vmware vxlan header size

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.

GENEVE Packet Format

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.

image

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:

image

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:

Image result for tcp 3 way handshake flags

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!

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!

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

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

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

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

Funcionamiento

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

image

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

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

Vamos por partes, Jack.

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

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

image

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

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

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

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

Ventajas del enfoque Nutanix

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

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

Escalabilidad

Hay dos conceptos importantes en localidad de datos:

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

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

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

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

Menor dependencia en Ethernet

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

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

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

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

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

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

Conclusión

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

Espero haber aportado algún contenido de valor.

Saludos!

[English] VSAN 6.2 study notes (Part 1)

Welcome!. This site is mainly written in spanish but i’m starting to open a new section for an english-speaking audience, touching different topics that -I consider- may have even more resonance in the broader reach that english language enable in this globalized world 😉

As part of my preparation for the VCAP6-DCV Design exam, I red different official documents and came across with a bunch of notes written, mainly, in a very informal format that could be rapidly understood by me when I needed to review them. I have practical experience deploying VSAN since the creepy 1.0 version and I have witnessed the constant effort from the VMware team to enhance the product.

VSAN 6.2 is a release that bring interesting features to the table, and I will touch some of them in this post, written in the format of personal study notes.

VSAN 6.2 general considerations

  • Listen carefully: even if there’s no Stripe Width configured different than the default (1), VSAN could decide to stripe a component in multiple disks. When it decides that? Well, if the object is bigger than 256GB it will be striped across multiple drives
  • Regarding the use of network teaming policies like Etherchannel, LACP, etc: VSAN does not balance traffic across links
  • When FTT=1, the VMDK OBJECT is comprised of two COMPONENTS. In VSAN (object storage) OBJECTS ARE MADE UP OF COMPONENTS.
  • There is a typical RAID 1+0 behavior when it comes to writes: for every write requested, there is (at least, assuming FTT=1) one replica of the write that is stored in the write buffer of ANOTHER host in the cluster. That’s because the write buffer is NON-VOLATILE: if the current host fail, the “hot” data in the write buffer remains available in the other host.
  • Two roles for magnetic disks in Hybrid: capacity and factor for stripe width
  • It’s always better to choose I/O controllers that allow pass-through instead of RAID-0
  • Do you like LSI’s FastPath? Well, VMware recommends to DISABLE any hardware acceleration in the controller
  • Heads up!: VSAN can rebuild components in a disk group different than the one in which the component used to live. I mean, if the caching device fails in host 1 (for a three node cluster with FTT=1), VSAN will check if there is free space in other disk group and will then rebuild the component there. If you have enough capacity but a single Disk group created, VSAN won’t be able to recover this.
  • If a caching device fails, THE WHOLE DISK GROUP NEEDS TO BE REBUILD
  • VM swap is Thick provisioned by default (OSR = 100%), and also has preconfigured Force Provisioning=true ,FTT=1
  • Snapshot delta disks inherit the policy from the base disk
  • VSAN does not interoperate with HA completely, because it doesn’t let HA validate if there is enough disk space in other nodes to rebuild components after a host failure. Simply, if a 60 min timeout is reached, VSAN will do whatever it takes to make the VM compliant again: new replicas, new stripes, whatever. This might cause oversubscription of resources
  • Fault Domains: it’s a logical extension of the role an ESXi host plays in a VSAN 5.x deployment: if FTT>0, no two copies of a VM’s data reside in the same host. Well, it’s not the Army of One anymore, if you group multiple hosts by, for example, the rack in which they are located, then you have a Fault Domain: no two copies of VM’s data will reside in that group of hosts.

VSAN AFA (All-Flash)

Since VSAN 6.1 it’s now supported (it was possible before, though) to create All-Flash VSAN disk groups in addition to hybrid ones (that hold a flash device used for caching and hard drives for capacity). Using AFA implies the following considerations:

  1. There is no vFlash Read Cache: for obvious reasons, flash devices (NVMe/SSD) in the capacity tier wouldn’t need read acceleration.
  2. Still there is a Flash device from the Disk Group that is used for write caching
  3. A maximum of 200 VMs per host are supported
  4. CAUTION: you CANNOT have AFA and HYBRID disk groups in the same cluster, that’s not supported right now.
  5. The 10% cache-to-capacity ratio remains true even in AFA
  6. With VSAN 6.2 hybrid , it doesn’t matter how many full disk writes per day (DWPD) the SSD supports. As long as it doesn’t become larger than the Terabytes Written (TBW) the device supports in a day. TBW = (SSD size) * (DWPD)
  7. For VSAN AFA, the VMware specification is higher than for hybrid: 4TBW. In both cases this only really matters for the caching device, not for the capacity drives. This parameter can be found at the VSAN HCL, in the detail of the Caching Tier for any VSAN ready node you will find the Endurance value expressed in TBW. For example this is the HP E-Class 779164-B21 SSD :

vbb_01

I will share more design-focused notes in a later post

 

Thanks!