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