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

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:

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.

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é ) 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!

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.

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