[English] VSAN 6.2 study notes (Part 1)

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

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

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

VSAN 6.2 general considerations

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

VSAN AFA (All-Flash)

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

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

vbb_01

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

 

Thanks!

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:

image

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:

image

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√≠:

vpostgres01

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:

image

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:

image

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

image

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:

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!

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!