Componentes del Nutanix Distributed Storage Fabric (DSF)

Un componente fundamental y fundacional de Nutanix Acropolis (y de Nutanix como producto) es el Distributed Storage Fabric, como razonamos en un post pasado.

En éste post no brindaré una traducción de la fuente principal pero sí trataré de aportar comentarios que puedan ayudar a entender mejor los componentes del DSF y también, reflejen mis impresiones al respecto.

Generalidades

A pesar de mis primeras apreciaciones –que como todas, no son precisas- el DSF es mucho más que un sistema de archivos distribuido. Es una plataforma, un producto vivo en si mismo (si me permiten lo lírico) que implementa de una manera muy sofisticada la gestión del ciclo de vida de la información (ILM) que allí se aloja; manteniendo criterios de resiliencia, redundancia, eficiencia y alto desempeño.

Componentes

El siguiente diagrama pretende resumir la arquitectura del DSF en relación con sus componentes básicos:

image

Storage pool

Aunque mi reflejo inicial fué compararlo con el Storage Pool de las SAN tradicionales, hay una diferencia importante. El Storage Pool de Nutanix DSF es una agrupación de dispositivos de almacenamiento de varios tipos: PCIe SSD, SSD y HDDs. Hasta aquí, muy similar. Sin embargo, se trata de una bodega de capacidad de almacenamiento que es distribuida y por defecto, crece linealmente a medida que se agregan nodos al cluster. Esto es crecimiento scale out que es otra consecuencia positiva del enfoque webscale, como lo dedujimos previamente.

¿Se parece a como operaría la adición de shelfs/DAES/expansiones de discos a una SAN tradicional? No, debido a que en ése caso sólo estoy ampliando la capacidad disponible mientras que el plano de control y administración sigue siendo centralizado (controladoras/Storage Processors); profundizando la dependencia de cada vez más datos en unos componentes que no son infalibles, mientras que el Storage Pool de Nutanix cuenta con todos sus planos (administración, control y datos) distribuidos y por ende, pensados con la realidad de los fallos en mente, manejándolos con mucha mayor redundancia y resiliencia.

Container

Bueno, no está relacionado con Docker/Kubernetes/Mesos y todos sus amigos. Es más bien, una sub-división lógica del Storage Pool y reciben algunas opciones de configuración de manera global. Al tratarse de una sub-división, puede haber más de un container por Storage Pool. Por otro lado, típicamente se crea un datastore por container –por fin un término conocido: datastore. Estos son los volúmenes que por NFS/SMB se presentan al hipervisor.

vDisks

Aquí empieza a tomar verdadera distancia DSF de la mayoría de esquemas de almacenamiento (object/block) que haya conocido. DSF tiene visibilidad de los discos virtuales de las VMs: ya sean vmdks/vhds/etc. La manera en que ésta granularidad resulta en alto desempeño y eficiencia en el uso del espacio, la veremos con moderado detalle en éste post.

Lo primero que hay que decir es que no se alojan los vDisk asi nada más, sino que se sub-dividen en piezas más pequeñas llamadas Extents

Extents

En general en sistemas de archivos, un extent es un área de datos que deben cumplir una condición: ser considerados contiguos, es decir que no exista separación entre ellos. Ahora, eso tiene un límite y éste varía entre sistemas de archivos, pero todo lo que se ubique dentro de ese límite o longitud del extent se considera contiguo.

image

Un sistema de archivos eficiente busca trabajar con datos contiguos pues ésto beneficia el desempeño: la búsqueda de segmentos de almacenamiento a lo largo de regiones dispersas implica tiempo y recursos, lo cual se traduce en latencia y carga de CPU/RAM; mientras que con datos contiguos se optimiza el uso de éstos recursos.

¿De qué tamaño son esos bloques que se alojan dentro del extent? Eso depende del sistema operativo de las máquinas virtuales pues de allí directamente es de donde vienen. El DSF  lleva a cabo las operaciones de escritura/lectura/modificación no en todo un extent a la vez, sino en porciones del mismo, conocidas como slices (tajadas/rebanadas). El bloque es la unidad fundamental del almacenamiento (block), y como podrán notar, es a ése nivel que trabaja DSF; considerable nivel de granularidad.

Extent Group

También DSF lleva a cabo la agrupación de múltiples extent y corre sobre ellos tareas de deduplicación (ya saben, evitar guardar múltiples copias del mismo bloque). Dependiendo del éxito que tenga deduplicando, el extent group puede ocupar 4MB o llegar hasta 1 MB. Lo interesante es dónde y cómo se almacena: en el dispositivo de almacenamiento administrado por la Controller Virtual Machine o CVM que corre en cada nodo Nutanix. (NOTA: ¿les había mencionado que ese dispositivo se pasa directamente a la CVM sin abstracción? Direct-Path I/O en vSphere; se me ocurren muchas ventajas de ello que después abordaré Winking smile ) Además el Extent Group se distribuye por partes a lo largo de nodos (striping) lo cual beneficia el desempeño a la hora de leer bloques del extent group.

Conclusiones

Este post surgió de revisar con detalle sólo algunas páginas de la Nutanix Bible, que es una documentación escrita con la claridad, detalle y transparencia que realmente ya uno extraña de otros fabricantes. Mientras revisaba éste material pensaba que en mi humilde opinión, Nutanix no debería enfocarse en competencias de IOPs con otros vendors; la verdad la vasta mayoría de aplicaciones ni siquiera necesita todos esos números. Pero si el propósito fuese comparar y al menos juzgando por lo que conozco, el enfoque y sólida implementación del sistema distribuido que Nutanix es, no tiene punto de comparación con otras soluciones.

Debo recordar que éstos posts los escribo voluntariamente, me motiva el hecho de encontrar que un antigüo e indeleble interés profesional mío hoy encuentra protagonismo en el datacenter: los sistemas distribuidos.

Saludos!

Advertisements

Mi experiencia en el VCAP6-DCD

Ayer tuve mi cita con un examen al que lo rodea cierta aura de misterio y que, en todo caso, es un desafío importante y en buena medida, relevante aún. Hablo del VCAP6-DCD (VMware Certified Advanced Professional – Datacenter Design).

Es un examen muy interesante y que implica el desarrollo de nuevas habilidades y en general, una manera de pensar de diseñador de virtual datacenters que, si se aprende a dominar, puede iniciar el camino hacia convertirse en un verdadero arquitecto.

Pues bien, después de leer (y estudiar) 6 libros completos, revisar secciones interesantes de otros 3 (en total más de 2,000 páginas) además de leer whitepapers, guías, tomar cursos en Pluralsight e invertir cerca de 80 horas de estudio y práctica, fallé el examen.

Honestamente nunca había estudiado tanto para un examen y, en suma, me sentía preparado para el mismo. Y creo que si lo estaba; no en vano me pude desenvolver cómodamente en los escenarios que utilizan el temido design tool y me sobraron 50 minutos en total, tiempo suficiente para revisar todo. Hubo algunos escenarios en que no conocía todas las respuestas, pero en la mayoría si y además, había notado las “distracciones” introducidas en varios escenarios y estaba satisfecho porque para detectarlas, es necesario haber estudiado lo suficiente.

Aunque mi reacción inicial fue pensar: “si lo intentara mañana nuevamente, no sabría que responder diferente”, si he encontrado oportunidades de mejora en fortalecer el conocimiento en un par de temas para intentarlo de nuevo muy pronto. Mi meta no es pasar este examen sólamente, me preparo para llegar al VCDX y así estar habilitado para, a partir de ahí, seguir formándome como un arquitecto de verdad que puede aplicar éstas (y más) habilidades en un entorno VMware así como en cualquier otro entorno. Arquitectura de sistemas lo llaman.

En éste post reúno mi experiencia y retroalimentación de éste proceso hasta ahora:

Los recursos de estudio

Por lo menos juzgando por mi primer intento, siento que perdí mi tiempo leyendo y estudiando algunas de las referencias que da el blueprint oficial del examen, especialmente en las primeras secciones. Son una cantidad de whitepapers antiguos (algunos tienen más de 12 años) que en mi opinión, no dicen nada nuevo o nada que realmente me pudiese ayudar en el examen.

Los recursos que si encontré útiles para ésta experiencia

  • Libro vSphere Design, 2nd Edition de Scott Lowe
  • Libro vSphere 6 Datacenter Design Cookbook de Hersey Cartwright
  • Libro VCAP5-DCD Official Study Guide de Paul McSharry
  • Curso Pluralsight: Designing VMware Infrastructure de Scott Lowe
  • VSAN 6.2 Design and Sizing Guide por John Nicholson
  • Libro: Networking for VMware Administrators de Chris Wahl y Steve Pantol
  • vSphere Virtual Volumes Getting Started Guide

Recursos en los que quisiera haber invertido más tiempo:

  • Documentación oficial de vSphere: no quiero decir que no haya leído varias partes de la misma. Pero siempre he sostenido que la mejor guía de estudio de un producto es su documentación (cuando está bien escrita), sin embargo la documentación completa de vSphere son varios miles de páginas que en alguna manera, siempre ahuyentan la posibilidad de tomar el tiempo suficiente para estudiarla toda. En todo caso, debo pasar más tiempo con ésta que es la fuente más confiable.
  • Documentos de Compliance Solutions en Solutions Exchange: hay una buena razón por la que no los revisé: el blueprint ni los menciona. Es más, nadie los menciona.  Creo que si hay una tarea pendiente aquí por parte de VMware Education en hacer un esfuerzo adicional en habilitar a los aspirantes de éste examen, con algo más que un vago objetivo de “Based on stated security requirements, analyze the current state for compliance/non-compliance.” (Objective 2.7)
  • Practicar más la construcción de diagramas Entidad-relación.

El design tool

Debo agradecer los posts de Jordan Aroth pues me permitieron de alguna manera familiarizarme con el design tool y, en general, con el entorno del examen. El truco de copiar/pegar el último elemento en los diseños me ahorró mucho tiempo. De hecho me gustó la herramienta y me sentí cómodo interactuando con la misma. Aquí algunos consejos:

  • Leer los requirements lentamente y más de una vez
  • Ubicar los elementos en el canvas en el orden en que la sección de Requirements los enuncia. Esto facilita mucho las cosas
  • Una vez terminado el diagrama, revisar nuevamente en detalle todo el texto de Customer Requirements y asegurarse que el diseño cumple con precisión
  • CUIDADO: en el Category menú suelen haber más elementos de los que se necesitan; una completa comprensión de toda la sección Customer Requirements impedirá que seleccionemos un objeto incorrecto.
  • Asegurarse que los objetos correctos son los que están conectados: puede haber escenarios de diseño con gran cantidad de objetos y la herramienta no alerta acerca de una conexión incorrecta o sin sentido, así que es necesario asegurarse de ello.

Las aparentes ambigüedades

Aún más importante que el conocimiento técnico específico, creo que el mayor esfuerzo de preparación para éste examen debe estar en desarrollar una mentalidad de diseño: decisiones, justificaciones para ésas decisiones y consecuencias. Muchas preguntas pueden parecer ambigüas, mientras que otras lamentablemente, aún son del estilo VCP que requieren una respuesta tal cual como la dice la guía. Pero para aquellas preguntas que parecen subjetivas, es necesario tomarse el tiempo de pensar en todas, todas las implicaciones de una decisión y pasarlo por el filtro del contexto/requerimiento del cliente tal como el examen lo mencione. Aunque aún después de ello pueden quedar dudas, ciertamente se clarifica el criterio para elegir o descartar una decisión.

Es todo por ahora. ¿Qué tan útil es el post de alguien que falla el examen? Bueno, para mi al menos es útil pues me permite establecer el plan de mejora para el siguiente y último –espero- intento. Espero les sea de alguna utilidad también.

Saludos!

Sistema de archivos distribuido: el verdadero habilitador de la hiperconvergencia

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

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

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

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

La salsa secreta

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

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

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

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

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

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

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

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

Saludos!

Webscale para no webscalers

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

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

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

La historia, mi historia

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

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

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

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

nut_nosan
¿Recuerdan esto?

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

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

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

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

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

La relevancia para el resto de compañias

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

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

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

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

Espero haber aportado algo de claridad en éste tema.

Saludos!

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

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

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

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

Veamos de qué se trata.

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

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

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

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

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

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

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

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

— Dadas éstas consideraciones, podemos continuar:

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

IP Address MAC Address
192.168.0.100 (IP PH1) pMAC ESX3

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

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

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

Conclusiones

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

Los comentarios son bienvenidos, saludos!

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

Proxy ARP es un mecanismo utilizado en redes y seguridad desde hace décadas. Consiste en configurar un dispositivo de capa 3 (típicamente un router) para que responda a las solicitudes de ARP (traducción de IP a MAC address) con su propia MAC Address, evitando que el dispositivo que hizo la solicitud tenga que salir de la red para hacer la consulta y convirtiéndose, a su vez, en el punto designado por el cual se redirijan (forwarding) las subsiguientes sesiones de comunicación hacia la recién aprendida IP/MAC.

Dicho de otro modo, si dispositivos conectados en subredes diferentes requieren conectarse entre sí van a necesitar un router que actúe ademas como el default gateway para cada subred, esto es Networking 101 o menos para muchos. Pero ¿que pasa si no hay tal dispositivo? ¿Podría insertar un dispositivo que facilite esa comunicación incluso SIN configurar un gateway  para ninguna de las sub-redes? Esto es precisamente para lo que hace casi 30 años se concibió ProxyARP documentado inicialmente en el RFC 1027 (lectura interesante)

Utilidad

  • Introducir ProxyARP en la red no implica cambios en las tablas de enrutamiento de otros dispositivos en la red. Realmente, éste puede ser un beneficio que se pase por alto pero si hablamos de un entorno virtualizado donde es tán fácil crear VMs con múltiples vNICs, y si dicho entorno aun cuenta con un esquema tradicional de VLANs, entonces esas tablas pueden estar llegando a su límite operacional; que es más cercano de lo que pensamos como lo confirma el RFC 5556 (TRILL).
  • Por otro lado, habilita la creación de un modelo de red plana (flat-network) sin intervenir los dispositivos finales que, gracias a ProxyARP, piensan estar directamente conectados con dispositivos en las demás sub-redes. Esto puede habilitar el diseño de una DMZ en la cual los equipos no cuenten con un gateway configurado.

Dificultades

ProxyARP no es nada popular en muchos círculos, algunas de las razones que se esgrimen para ello son:

  • Afecta la confidencialidad de la red más de lo que la beneficia: si un atacante logra hacerse pasar como la MAC address del ARP Proxy (MAC-spoofing) entonces tendrá visibilidad de todo el tráfico de sesiones establecidas así como de consultas ARP.
  • Debido a que los dispositivos (por ejemplo máquinas virtuales) no pueden pasar a otra sub-red sus solicitudes ARP, la presencia del proxy a largo plazo eleva el volúmen de tráfico ARP que tiene que ir y regresar a la subred.
  • Como si no fuese suficiente, debido a que siempre habría una respuesta a una solicitud ARP, el dispositivo que originó la consulta confía en que efectivamente encontró el destino y continuará el envío de paquetes hacia allí. Sin embargo, en ningún punto el proxy verificó que efectivamente pudiese llegar al destino real. Esto crea el llamado efecto hoyo negro, pues se establecerá una “comunicación” que realmente no está llegando a ningún destino y los dispositivos no lo notan.

De aquí en adelante, ¿para qué hablar más de Proxy ARP? ¿Es completamente fallido? ¿Alguien lo sigue utilizando?

Veamos.

Proxy ARP en VMware NSX

Si eres nuevo en NSX, recomiendo ampliamente el webinar de arquitectura desarrollado por ipSpace (el hombre, la leyenda Ivan Pepelnjak)

En NSX, el plano de control es distribuido y el rol le pertenece a un cluster de Controllers (virtual appliances) que aprenden y distribuyen la información de forwarding a todos los VTEPs participando en la red para VXLAN.

Una de las funciones que provee el controller cluster se conoce como “ARP Supression” en la que habilita a los VTEPs instalados en los hosts ESXi para actuar como ARP Proxy cuando una VM hace una solicitud de ARP broadcast para resolver la MAC address de otra VM. Quizá sea más claro con una imagen (tomada de la guía de diseño de NSX-v):

image

Trataré de ampliar lo descrito por la guía de diseño (de otro modo, Google Translator habría sido en vano):

1. La VM1 pregunta “¿Dónde esta la dirección física de ésta dirección IP?”. Eso, en suma, es una solicitud ARP (“dónde ubico la MAC address corrrespondiente con ésta IP address). Normalmente esa amplia pregunta (broadcast) se hace en todo el dominio L2 de la VM, es decir, en su red VXLAN 5001 y, debido a que ésa red atravies múltiples hosts, la consulta se haría sobre múltiples puertos físicos. Esto es lo que tratará de evitar el “ARP supression”.

2. Antes de obedecer ciegamente la solicitud de la VM1 y pasarla a hacer broadcast a lo largo de todos los hosts en el Transport Zone, ESXi-1 le pasa la solicitud al Controller Cluster: “¿Dónde esta la dirección física de ésta dirección IP?”

3. El controller cluster recibe la solicitud. Nota para candidatos a VCIX-NV: el agente que lleva a cábo ésta comunicación se llama netcpa y se comunica con el Controller Cluster a través de un canal SSL establecido en el momento en que se prepara el cluster para NSX.

4. El controller hace lo que cualquier dispositivo L2 haría: consultar su tabla ARP local a ver si tiene ese registro.

5. En caso de contar con la respuesta, se la envía de vuelta al host ESXi-1

6. El host ESXi-1 hace lo que todo dispositivo de L2 en ése caso: recibe el mensaje del plano de control y actualiza su tabla local pero fíjense: lo que guarda en su tabla es la IP y MAC address del VTEP del host ESXI-2 donde se encuentra la VM2, no la información sobre la VM2 específicamente.

7. Aquí viene el truco: ESXi-1 fabrica una respuesta ARP en la cual la MAC address origen no es realmente la MAC de la VM2, sino la del VTEP del ESXi-2 que, de aquí en adelante, actuará como el ARP proxy para ésta comunicación.

Claro está, si en el paso 4 el controller determinó que NO cuenta con ésa entrada, entonces ejecutará el L2 broadcast y cuando tenga una respuesta de la red, actualizará su tabla y le informará el cambio a los hosts ESXi.

¿Qué pasa si la VM es migrada a otro host? En condiciones normales, al ejecutar vMotion ESXi envía, como parte del proceso, un ARP reverso (RARP) para actualizar las entradas ARP, por lo que una nueva comunicación entre VM1 y VM2 (que ahora está en el host ESXi-3) no debe pasar por el proceso de ARP descrito. En todo caso, tener en cuenta lo descrito en este KB, pues podría evitar el funcionamiento del RARP.

En la siguiente entrada, hablaremos más de funcionalidades similares que NSX despliega para la comunicación optimizada entre VXLAN y redes tradicionales basadas en VLAN.

Bienvenidos los comentarios!

Configuración de Agents para Horizon View en Log Insight

Saludos

Hace ya un buen tiempo VMware lanzó el Content Pack de Horizon View para vRealize Log Insight. La necesidad de contar con recolecciòn centralizada y análisis de eventos para toda la infraestructura de EUC que entrega Horizon View es innegable y este complemento llegó en un momento muy necesario.

¿Cómo funciona? Cliente-servidor. El servidor (Log Insight) ofrece la descarga de agentes para Windows o Linux que llevan una configuración básica que le permite a cada máquina que ejecute el agente, redirigir sus eventos hacia la instancia de Log Insight desde la que se descargó el instalador del agente. Sin embargo para hacer una captura más precisa de eventos e incluso filtrarlos desde archivos planos de logs, es necesario crear una plantilla de configuración desde el server, quien se encarga de publicarle esa configuración a los agentes que así se definan.

Aunque la documentación oficial de vRealize Log Insight describe el procedimiento de configuración de dichos agentes, en el caso específico del CP para Horizon View, la información dista de ser completa y, más bien, evita el funcionamiento inicial del logging de todos los componentes, como puede verse en éste thread

En éste post se describe brevemente los pasos necesarios para lograr que los servidores “core” de Horizon View 6 (Connection Server, Composer y Security Server) envíen sus eventos a vRealize Log Insight 3.3

  1. 1. Primero es necesario haber instalado el Content Pack v3.0 para Horizon View desde la sección Content Packs > Marketplace en Log Insight:
  2. image
  3. 2. Adicionalmente, es necesario instalar el agente de Log Insight para Windows en los servidores de Horizon View en mención: Connection Servers, Composers y Security Servers. Este agente se descarga desde la sección Administration > Agents:
  4. image
  5. 3. Una vez instalado el agente en los servidores, regresar a la sección Administration > Agents de Log Insight
  6. 4. Verificar que en el listado de Agents figuran todos los servidores en los que ha instalado el agente. Es posible que todos ellos muestren en la columna Events sent el número 0, lo que muestra la necesidad de configurar los Agents para recibir datos correctamente
  7. 5. Del menú desplegable Agents selecciónar la opción New Group:

image

6. En esta sección, se sugiere crear un grupo para cada rol de servidores (Connection, Composer, Security):

image

7.  Una vez se cree el grupo es necesario configurar su membresía utilizando alguno de los criterios disponibles para ello. Esta regla debe poder incluír unicamente a los servidores correctos en cada grupo (típicamente especificados por IP y/o hostname:

image

8. Luego de verificar que los servidores que se visualizan en la sección Agents son los correctos para el grupo, es necesario dirigir la atención a la sección inferior Agent configuration. Por defecto la sección no tiene contenido, por lo que es necesario dar clic en Edit:

image

9. ATENCIÓN: es aquí donde el procedimiento debe tratarse diferente a cómo la documentación del Content Pack (ver pestaña Tech Specs) lo enuncia. Allí se indica que se debe crear una configuración genérica del agente y distribuirla a todos los servidores:

[filelog|ViewMain]
directory=C:\ProgramData\VMware\VDM\logs
include=log-*.txt;debug-*.txt;pcoip_agent*.txt;pcoip_server*.txt
exclude=pcoip_perf*.txt;v4v*.log;wsnm_starts.txt

Make sure that agent is installed on the base image so that it runs on each View desktop, plus it should be installed on all the other servers as well including: ALL connection, security, & composer servers.

Es decir, se trata de la misma manera a los desktops así como a los servidores de Horizon View, lo cual no es preciso principalmente porque la ruta de ubicación de los logs no es la misma en todos estos componentes.

Dicha configuración es apropiada para los Connection Server, Security Server y Transfer Server (ver KB 1027744) pero NO para el Composer Server.

10. Es por ello que verificando la configuración genérica y contrastando contra la ubicación real de los logs así como el contenido de esas ubicaciones, aquí propongo generar la siguiente configuración específicamente para los Composer Server:

[filelog|ViewComposer]
directory=C:\ProgramData\VMware\View Composer\Logs

*No se especifica ninguna exclusión pues todos los archivos contenidos en esa ubicación para el Composer Server todos los archivos corresponden al log actual y los logs que han rotado y se requieren para análisis.

11. Una vez guardada la configuración, máximo 5 minutos después se puede evidenciar que empiezan a recibirse eventos por parte de los Composer Server así como los demás servidores de Horizon View.image

La configuración del agente del Horizon Client así como el agente para los Desktops puede ser tomado de la plantilla precargada en la sección Agents por parte del Content Pack para Horizon View.

Espero haber aportado en algo a ésta labor tan importante.

Saludos!

Algunas consideraciones de diseño para Microsoft AD Certificate Services 2012

Recientemente he recopilado algo de experiencia en el despliegue del rol Active Directory Certificate Services sobre Windows Server 2012 y 2012 R2 y, sin ser para nada una guía exhaustiva ni ser escrita por un experto en infraestructura Windows Server; quisiera compartir algunas consideraciones a tener en cuenta, especialmente en un ambiente en el que los consumidores de los certificados serán servicios de VMware:

La arquitectura

Hay varias opciones para el despliegue para lo cual considero recomendable leer y revisar la documentación de Microsoft al respecto de éste tema. Sin embargo la versión corta e imprecisa es que hay que tomar varias decisiones:

¿Enterprise o Standalone CA?

Standalone CA quiere decir que no va a estar unida al dominio y, por lo tanto, va a carecer de funciones como autenticar solicitudes de certificados contra AD, entregar certificados automáticamente ó usar plantillas.

Las Enterprise CA de Microsoft están unidas al entorno de Active Directory y por lo tanto, complementan la autenticación de AD con la entrega automatizada de certificados a los miembros del dominio, el uso de plantillas y la autenticación de solicitudes de certificado. Para el uso de Microsoft CA en un entorno con VMware vSphere, es necesario hacer configurar Enterprise CAs pues, como tocaré más adelante, se requiere plantilla de certificado con algunas variables adicionales a partir de vSphere 5.1

Root y Subordinates

Microsoft AD Certificate Services contempla una jerarquía de niveles de confianza y de autoridad en la que el mayor nivel es la Root Certificate Authority (Root CA) que debe ser confiada por todos los miembros del dominio y tiene permisos para emitir así como para revocar certificados, y también tiene el rol de distribuir los Listados de Revocación (CRLs) actualizados a todos los miembros de la jerarquía.

Las entidades subordinadas son todas aquellas que están bajo la entidad Root, siendo la subordinada inmediatamente abajo la que se conoce como entidad “Intermedia” que obtiene los certificados de la Root CA y los puede usar para emitir a entidades más “abajo” en la jerarquía.

En resumen, la decisión de diseño aquí corresponde a si el entorno de despliegue requiere solamente una Root CA que es autosuficiente para emitir certificados o se requieren también subordinadas.  La mejor práctica de Microsoft se refiere a desplegar una Root CA que permanezca aislada (de hecho, apagada después de implementada) y que sea una o más entidades subordinadas las que sean visibles para los dispositivos finales y controlen la emisión y revocación de certificados digitales; con la firma original de la Root CA.

Algoritmo de hash

Al configurar el rol de AD Certificate Services (para ello se puede seguir la guía de Technet)  la opción de algoritmo de hashing predeterminado es SHA-2 cuyo equivalente más seguro y completamente soportado por las versiones recientes de vSphere (ver KB) es SHA-256 que es mucho más resistente a ataques de colisión y tiene el potencial de ser el estándar de uso en la implementación de Public Key Infrastructure (PKI) en un entorno VMware.

Conclusión

Espero hayan sido de utilidad algunos de éstos datos, en el futuro si el todopoderoso tiempo lo permite, estaré agregando diagramas para clarificar mejor los asuntos.

 

Saludos!

Libro: vRealize Operations Performance and Capacity Management

Por una gentil invitación de la editorial Packt Publishing, he tenido la oportunidad de dar mi opinión para el libro “vRealize Operations: Performance and Capacity Management” que como todo recurso en vROPs (antes vCOPs) es muy bien recibido porque la documentación no siempre es clara o incluso existente.

Se trata pues de la ópera prima de Iwan Rahabok que incluye varias novedades que trataré de manera breve a continuación:

Primera novedad: el autor

De acuerdo con la introducción del libro, el autor Iwan Rahabok ha desempeñado desde hace varios años un rol como Systems Engineer para cuentas estratégicas, lo que es un cargo con un marcado acento comercial pero que, de ser ejercido con suficiente profundidad técnica, puede ser muy relevante para entregar soluciones oportunas a los clientes de VMware, en este caso. No es común ver a un SE tan involucrado con los detalles de un producto, por lo que es un ejemplo digno de imitarse.

Segunda novedad: el enfoque

El libro logra dar temas de interés y elementos para profundizar a una audiencia diversa: desde las diferencias fundamentales entre el centro de datos físicos y el virtual (como un CxO lo entendería) hasta profundizar en un tema cuya documentación ha sido notablemente escasa en el pasado: la definición de métricas de vROPs y su relación con las de vCenter.  De manera que un enfoque amplio y que se enfoca en los asuntos importantes y frecuentemente no tratados, hace del libro un recurso muy valioso.

Una palabra final: aplicación práctica

Como si los aportes mencionados no bastasen, Iwan Rahabok agrega un capítulo dedicado a un tema que suele ser tratado de manera muy operativa pero que ha carecido del componente de planeación y diseño: la creación de custom dashboards de vROPs que aunque implica Licenciamiento Advanced o Enterprise, definitivamente explota mucho del potencial de la herramienta para el monitoreo preventivo y la visualización de indicadores clave del centro de datos virtual.

Conclusión

VMware planea ahora para la suite de management un enfoque mucho más abierto e híbrido, y el enfoque de éste libro precisamente va alineado con esa visión de dar apertura a vROPs 6 y su paradigma de Intelligent Operations a diferentes tipos de ambientes, que son consumidos por diversos tipos de usuarios. Es definitivamente un recursos muy necesario y que fué publicado en el mejor momento.

Tres niveles de (in) dependencia de Multicast en VXLAN

Continuando  con la temática del protocolo VXLAN, en ésta ocasión trataré lo que ha solido citarse como la principal barrera para su adopción: el requisito de Multicast y la carga operacional que implica su administración y la complejidad de la implementación.

Para VMware y Cisco, dos de los principales impulsores de VXLAN no ha sido desconocido éste tema y han hecho diferentes actualizaciones a la línea de productos para ofrecer tunelamiento VXLAN en diferentes sabores con respecto al requisito de multicast. He identificado tres variantes hasta ahora, que pasaré a describir:

1. vCloud Networking & Security: barato como un cachorrito

Si una organización tiene acceso a vCloud Suite en edición Standard, ya tiene en su bolsillo el licenciamiento para vCNS. Con éste producto es posible crear una completa implementación de VXLAN que incluso pueda ser consumida como redes organizacionales por tenants de vCloud Director. Sin embargo aquí es completamente necesaria la presencia de Multicast en la red física, aspecto que se debe tener en cuenta a la hora de evaluar la solución y su costo operacional.

2. Cisco Nexus 1000V: viviendo al filo del RFC

A comienzos de 2013, Cisco anunció la implementación de al menos dos nuevos mecanismos en el switch Cisco Nexus 1000V que harían posible implementar VXLAN sin el requisitio de Multicast:

a. Nexus 1000V puede crear múltiples réplicas de cada paquete y enviar cada réplica a un VTEP en la red usando sólamente Unicast. Esta opción claramente dista de ser escalable pues en un entorno masivo se producirá algo similar a una “tormenta” Unicast.

b. Hacer uso del VSM (Virtual Supervisor Module) que hace parte de la implementación de Nexus 1000V para que actúe efectivamente como un plano de control distribuyendo la información de direcciones MAC de máquinas virtuales a los VEM (Virtual Ethernet Module) presentes en la red. Esto, aunque efectivo, contradice lo que establece el RFC de VXLAN con respecto a que el protocolo no debe depender de un plano de control ni entidad alguna de administración centralizada. Cisco lo sabe pero, el cliente siempre tiene la razón 😉

VMware NSX: el auge del plano de control distribuido

Durante el VMworld US 2014, el Dr. Bruce Davie compartió conceptos avanzados y el futuro de NSX en la sesión NET1674.

Allí detalló el uso de VXLAN como protocolo de tunelamiento para NSX y, con respecto a lo que nos ocupa, la manera en que NSX habilta el uso de OVSDB (Open vSwitch Database) como el protocolo a través del cual distribuye la tabla de direcciones MAC de las Máquinas virtuales a lo largo de los switches físicos que soporten el protocolo y que hagan parte de la infraestructura sobre la cual tiene alcance el NSX Controller.

OVSDB es un protocolo de administración cliente-servidor que busca dar acceso programático a la base de datos OVSDB que contiene la información de cómo opera la conmutación del Open vSwitch con datos como, por ejemplo, la tabla de direcciones MAC de las MVs del entorno.

El mecanismo principal con el cual NSX crea redes virtuales (llámense segmentos, virtual wires, túneles,etc) es VXLAN que en este caso, y dado que la tarea de distribución y actualización de direcciones MAC la asume el protocolo OVSDB, solo requiere la presencia del protocolo IP como transporte o underlay eliminando así el requerimiento de multicast en la red física.

Sin embargo, no todas las organizaciones van a poder abrazar éste enfoque pues surge un nuevo requerimiento quizá más etéreo que el de multicast: switches físicos que soporten OVSDB. Actualmente existe oferta al respecto por parte de fabricantes como Juniper o Arista y aparentemente Open vSwitch ha llegado para quedarse, que es lo que se desprende de su adopción no solo por parte de los grandes fabricantes sino de la iniciativa OpenDayLight de Linux Foundation, que busca establecer un marco de referencia para el avance de SDN como un programa abierto e interoperable (el mundo empieza a reaccionar contra la proliferación del vendor lock-in, o eso esperaría).

Saludos!