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!

Advertisements

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!

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.

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

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:

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

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 :

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

 

Thanks!

Protección nativa de datos en Nutanix Acropolis Distributed Storage Fabric

Continuando con la exploración de las características de Nutanix Acropolis DSF, en éste post trataré de brindar luces sobre algunos mecanismos que ésta plataforma utiliza para la protección de datos.

Lo que no es

Primero, es necesario empezar a pensar diferente para abordar la protección de datos moderna. Lo que hemos conocido tradicionalmente es la redundancia N+1 como medida base y, en muchas ocasiones, la máxima protección que podemos lograr. Esto lo vemos por ejemplo en los almacenamientos tradicionales con doble controladora que, en el mejor de los casos, serán Active/Active pero que manejan conceptos de propiedad  u ownership de las LUNs. En caso que una controladora falle, el sistema queda en un estado de frágil disponibilidad y las LUN que eran propiedad de la controladora fallida deben ser accedidas por un bus interno de menor desempeño, afectando el rendimiento (LUN trespassing de la vieja escuela).

También vemos éste principio en el diseño de clústers de cómputo donde se reserva la capacidad equivalente a un host adicional para proveer redundancia, o más en general, al tratar de introducir redundancia para mejorar la respuesta del sistema ante un fallo: doble tarjeta de red, doble HBA, doble blade chassis, RAID, etc.

Sin embargo, pensando en gran escala (o webscale si se quiere) surge la pregunta: ¿exactamente en que punto es necesario pasar de N+1 a N+2, o N+x? Es un método que tiene problemas de escalabilidad y que todavía está por verse qué tanta eficiencia reduce en el aprovechamiento de recursos del sistema.

¿No se podrá hacer diferente?

Redundancia y replicación

Acropolis maneja dos conceptos que en otras plataformas se condensan en uno solo (Failures to Tolerate anyone?) o que simplemente no se encuentran completamente. Veamos:

Redundancia: también se puede llamar Resiliencia, pero en todo caso debe responder a la pregunta: ¿cuántos componentes del sistema pueden fallar garantizando que siga respondiendo de manera confiable? La respuesta a ésa pregunta es un número conocido como Redundancy Factor o RF. Es necesario aclarar que Acrópolis considera “componentes” a un disco, una interfaz de red o un nodo completo.

Replicación: quizá el más antiguo de los métodos para proteger datos sea mantener más de una copia de los mismos: este principio rige los backups (respaldos), los niveles de RAID (excepto el 0), entre otros. Sin embargo en el caso de Acrópolis se mantienen múltiples copias de un dato así como del elemento que guarda información acerca de un dato: el metadato.

El número de copias de un dato que se mantienen en un clúster Acropolis se conoce como Replication Factor o RF. ¡Momento!. ¿No es confuso nombrarlo así teniendo en cuenta que el Redundancy Factor tiene la misma sigla? Bueno, es que están tan interrelacionados que en la práctica nos podemos referir a ellos con el mismo término. Esto amerita un dibujo:

En ésta figura se ilustra (conceptualmente) lo que sería un bloque Nutanix de 2U en rack y que contiene 3 nodos (puede contener hasta 4, ej. el modelo NX-3060 G5).

El RF es un parámetro que se configura desde Prism a nivel de container; entonces ¿qué sucede al configurar RF=2?. Detrás de cámaras ocurren varias cosas:

1. Cada dato será replicado a otro nodo en el bloque para así, tener dos copias del mismo (RF=2)

2. Sólamente hasta que esa réplica se complete, se considerará exitosa la escritura del dato (consistencia fuerte en toda su gloria, lo veremos en otro post)

3. Se establece una redundancia implícita de componentes: si el disco Dn falla, siendo el disco que almacena el dato B1 en el nodo 1 de nuestro diagrama; no hay problema: el dato está almacenado en un disco del nodo 2 e inmediatamente el CVM del nodo 2 iniciará una nueva replicación del dato B1 para cumplir la configuración de RF=2. Lo mismo sucede si todo el nodo 1 falla.

Es por ello que al configurar el Replication Factor en Prism, implícitamente estamos configurando el factor de Redundancia del sistema.

Entonces, de manera más general se puede decir que:

Redundancia = (Replication Factor) – 1

Asi que en nuestro ejemplo, si configuramos RF=3 para el container entonces se soporta el fallo de dos nodos, o de dos discos y así sucesivamente.

Interesante, pero no estaríamos hablando de almacenamiento moderno si nada más moviésemos bloques aquí y allá. ¿Habrá un elemento más ligero que un bloque, que almacene información relevante sobre un dato pero no el dato mismo?. Oh si, hablamos del metadato.

Acropolis le da un tratamiento de primera clase a los metadatos, después de todo son la columna vertebral de un sistema de archivos distribuido.

Veamos:

Un anillo para controlarlos a todos

Con respecto a los metadatos, Nutanix ha adoptado el uso de una versión modificada de Apache Cassandra (¿qué tan modificada?- lo veremos en un próximo post). En Cassandra –que no es otra cosa que una base de datos noSQL de alto desempeño y escalabilidad-, todos los nodos participan en una topología de distribución de datos de tipo anillo pensada para garantizar principalmente, Consistencia y Tolerancia a fallos (pueden ir adelantando –por favor- la lectura del teorema CAP, para un próximo post en que trataré esta parte).

La protección de metadatos se implementa con un factor de replicación no dependiente del RF configurado para el container y que corresponde a un número impar y dinámico, pues se adapta al tamaño del clúster.

Volviendo a nuestro NX-3060-G5 de 3 nodos, el metadato M1 por defecto se replicará en los 3 nodos (RF=3) aunque el RF de los datos sea de 2:

De los 3 nodos, se requiere elegir un coordinador que administra la ubicación de los metadatos en el clúster. Ese coordinador es 100% reemplazable (si falla, se elige un nuevo coordinador de entre los nodos restantes) y es una implementación del proyecto Apache Zookeeper (hay tanto que hablar aquí sobre sistemas distribuidos, que realmente planeo cubrirlo en publicaciones posteriores).

¿Descontento con los resultados de las más recientes elecciones? Bueno, en sistemas distribuidos se busca que las elecciones sean justas. En el caso de Acropolis, se implementa Paxos que es uno de los algoritmos de consenso más ampliamente utilizados. Ese algoritmo requiere que el número de nodos sea impar para evitar situaciones de empate en las votaciones que los nodos hacen para elegir al coordinador.

Es por ello que en un bloque Nutanix con 3 nodos, aunque configuremos RF=2 para los datos, para los metadatos tendremos en la práctica un RF=3 (metadatos replicados en los 3 nodos).

¿Que sucede si agrego un nodo más? El RF de metadatos sigue siendo RF=3.

¿Y qué sucede si agrego otro bloque? En ese caso, con al menos  5 nodos el RF de metadatos puede subir a RF=5 y comienza el maravilloso baile de Apache Cassandra para incluir nuevos nodos en el anillo de tal manera que la distancia entre nodos se mantenga igual y los dominios de falla se distribuyan, ahora, a lo largo de dos bloques. (Si no es muy claro, es porque amerita otro post específicamente sobre la escalabilidad que aporta Cassandra)

¿Comparable con RAID?

Confío que en este punto sea un poco (poquito) más claro que no tiene mucho lugar comparar Distributed Storage Fabric con un arreglo RAID, sin importar el nivel, por ejemplo y hablando de replicación de datos (no de metadatos):

Nivel de RAID	Símil en Acropolis DSF
0	RF =1 (no recomendado)
1	RF =2 tiene el mismo overhead pero no implica el Write penalty de RAID1 (2)
5	RAID 5 tiene Write penalty de 4; no existe ese concepto en DSF
6	Con RF=2 se soporta fallo de un (1) disco pero no existe el Write penalty de 6 (!)
1+0	Si uso RF=3 duplico la resiliencia comparado con RAID1+0 que soporta un (1) fallo

Fíjense que en esta breve e incompleta comparación me baso en tolerancia a fallos y algo de desempeño, sin siquiera tocar el tema de eficiencia en espacio. Entonces Acropolis DSF puede igualar y superar con creces éstos factores comparado con un arreglo RAID y si introducimos el ingrediente de escalabilidad, la comparación se hace menos necesaria.

Conclusión

Este post me costó mucho trabajo, lo admito. Y aunque he tomado previamente cursos en Sistemas Distribuidos para la nube, me costó trabajo unir algunas partes en mi mente y tratar de ilustrarlas aquí. Estoy seguro que el post está lejos de ser completo o realmente claro pero vamos, podemos así iniciar una parte muy interesante de ésta exploración.

He tratado de desenfocar el componente de storage de Acropolis porque creo que hay más que ello pero todavía falta mucho descubrimiento. Lo claro es que como en algún momento lo expresé en Twitter, Nutanix no es un startup de almacenamiento y ni siquiera un vendor de hiperconvergencia (con I latina)sino algo muy diferente: una compañía de sistemas distribuidos.

Saludos!

Alternativas en una situación de split-brain en vPostgres para vRealize Automation 6.x

Hace unos meses me encontré con un problema cuya solución se veía elusiva y que rápidamente escaló para convertirse en un aspecto bloqueante para el avance de un proyecto de amplio alcance en el que estaba trabajando. Después de intercambios y esperas con VMware GSS tuve que llegar a ese momento de poner en marcha una alternativa de solución que no parecía lo más predecible, pero que era una de las últimas opciones disponibles.

El escenario

Un clúster de vRealize Automation Appliance 6.x actuando como instancias de vFabric vPostgres externas para otro clúster de instancias de vRealize Automation (actuando ahora si como vRealize Automation). Algo así:

Este es un esquema soportado que se implementa con el fin de proveerle alta disponibilidad a la base de datos de vRA 6.x que aloja información muy importante, como por ejemplo el inventario de tenants.

En ésta ocasión, encontramos que el personal a cargo de las pruebas de failover/failback había fallado en seguir estrictamente el procedimiento de la base de conocimientos KB # 2108923 de VMware y al llevar a cabo las pruebas del clúster Activo/Pasivo de vPostgres llegamos a nuestra situación.

El problema

Siempre que se configura la réplica nativa de vPostgres (mejor conocida como WAL Archiving) aunque el destino (Replica) se especifique por dirección IP, vPostgres buscará el PTR para resolverla por FQDN. Hasta ahí, no hay problemas; después de todo hay que usar FQDNs siempre que sea posible en éstos tiempos.

Sin embargo, en nuestro caso lo que se hizo en vez de crear una entrada DNS tipo alias (algo así como vpostgres.domain.local) y hacerla apuntar al nodo maestro actual, se llevó a cabo el failover y se modificó la entrada DNS del nodo 01 para que apuntara a la IP del nodo 02. Es decir, dos entradas DNS apuntando a la misma IP.

Esto funcionaba pues el nodo 01 estaba apagado. Sin embargo al encenderlo y tratar de configurar la réplica en el sentido contrario (Nodo 02 a Nodo 01) lo que se obtenía eran los siguientes mensajes:

waiting for server to shut down…. done

server stopped

WARNING: The base backup operation will replace the current contents of the data directory. Please confirm by typing yes: yes

602439/602439 kB (100%), 1/1 tablespace

NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived

WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)

Y allí permanecía indefinidamente sin completar la reprotección de la base de datos.

El atajo (solución)

Uno de los síntomas que empecé a notar, es que el repositorio de los Write-Ahead Logs (algo como los Transact Logs de SQL Server) no contenía archivos nuevos: todos correspondían al momento en que empezó a fallar:

Cuando daba el comando ps –ef | grep wal lo que se observaba es que, precisamente, permanecía tratando de replicar el archivo 00000002.history

Por lo tanto, pensé que tomando las precauciones necesarias, podría intentar dejar que vPostgres re-generara éste archivo que después de todo, solo parecía ser un histórico de la replicación de los logs:

Fue así como, después de tomar snapshot de los dos nodos así como de los vRA Appliance que hacen uso de ésta base de datos, procedí a renombrar el archivo e iniciar el servicio de vPostgres (porque además el servicio no iniciaba correctamente):

Después de ello, no sólo se generaron nuevos archivos WAL sino que la replicación se pudo completar satisfactoriamente.

Conclusión

El clúster de vPostgres para vRA 6.x es de tipo Activo/Pasivo y soporta dos métodos para ser consumido: a través de un Load Balancer (asegurándose de tener sólamente un nodo activo en el pool) o con un DNS alias que apunte al nodo maestro actual. Fallar en la configuración del método que se elija, puede llevar a una situación como la aquí descrita en un evento de failover/failback.

Saludos!