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!

VCAP-CIA Objetivo 1.1 o el misterio del logging de vCloud Director

Contar con los mecanismos para indagar en el pasado y rastrear eventos ó comportamientos de un sistema computacional es uno de los requisitos principales para contar con una infraestructura tecnológica administrable, escalable y que facilite el cumplimiento de regulaciones en el ámbito de seguridad de la información.

En el caso de VMware vCloud Director y su componente de seguridad y conectividad vCloud Networking & Security existen diferentes métodos por los cuales se pueden recolectar registros de actividad así como niveles de detalle de esos registros ó logs.

Dominar éste tema es el objetivo 1.1 del examen de certificación VMware Certified Advanced Professional – Cloud Infrastructure Administration, mejor conocido como VCAP-CIA; y lo trataremos con detalle en éste post.

Logging en vCloud Director
vCloud recolecta dos tipos de log: audit log que es el registro de actividades en el espacio de usuario así como eventos de los servicios que componen a vCloud.  Entre otros, estos eventos incluyen inicios de sesión, operaciones sobre vApps, orgvDCs y estado del servicio. El otro tipo de log es el diagnostic log que reporta el estado de los diferentes componentes del servicio vCloud Director y tiene varios niveles de detalle, cuya selección debe obedecer al caso de uso que se busque evaluar (clic para ver más sobre los niveles de logging). En todo caso, los audit logs por defecto se almacenan en la base de datos por 90 días y al ingresar la IP o nombre de un servidor syslog en el menú de instalación de vCloud,  se está dando la instrucción de re dirigir el audit log a ese servidor syslog en que se podrá manejar una retención mayor.

¿Qué es log4j y que papel cumple?

Es un interceptor de logs para aplicaciones Java y se denomina así por no insertar mínimas declaraciones de logging en las aplicaciones (en éste caso vCloud Director) e interceptar el contenido para alojarlo en ubicación externa (que desde el punto de vista de la aplicación, puede ser el almacenamiento local).

Con respecto a vCloud Director, cumple la función de procesar los diagnostic logs y habilitar el envío de éstos a ubicación centralizada (syslog). También administra los diferentes niveles de detalle que los diagnostic logs pueden registrar.

Logging en vShield Manager

vShield Manager es el plano de control que lleva a cabo la implementación de los appliance sobre los que corren módulos como vShield Edge, vShield Edge o Endpoint. Sin embargo vSM no interactúa directamente con el tráfico de red o las reglas de seguridad como si lo hacen los módulos mencionados, sino que mantiene el inventario de la ubicación, propiedad (a qué tenant pertenece) y características de los módulos desplegados en el entorno.

Quizá atribuìdo a esa función de mera supervisión que cumple vSM, es que la única opción de logging corresponde a un sólo servidor syslog a donde vSM enviará los logs tipo audit:

Syslog para vShield Manager

Métodos de captura de logs

 

1. Local

Caso de uso: retención de audit logs por máximo 90 días, espacio NFS para almacenamiento de diagnostic logs.

Este es el método de recolección de log que por defecto usa vCloud Director en caso que no se especifique ningún servidor syslog. En éste caso los logs audit y diagnostic se almacenan en $VCLUD_HOME/logs en el almacenamiento de cada vCloud cell.

Se pueden modificar las siguientes opciones para los diagnostic logs alojados localmente:

  • Nivel de detalle (ver VMware KB # 1026815)

 

¿Cómo hacerlo?

A. Iniciar sesión en la celda vCloud

B. Editar el archivo $VCLOUD_HOME/etc/log4j.properties:

blog51

C.  Siguiendo la KB 1026815 ubicar las líneas

# Root logger log4j.rootLogger=ERROR, vcloud.system.debug, vcloud.system.info

y

log4j.appender.vcloud.system.debug.threshold=DEBUG

Una vez se haya elegido un nivel de logging, se debe editar en éstas dos líneas fijándolas en el mismo nivel de detalle. Por ejemplo, si eligiera el nivel “TRACE”, que trae el mayor detalle, las líneas finalmente se verían así:

Root logger log4j.rootLogger=TRACE, vcloud.system.debug, vcloud.system.info

log4j.appender.vcloud.system.debug.threshold=TRACE

D. Guardar los cambios y reiniciar el servicio vCloud Director
Nivel de retención y tamaño de archivos de log

 

¿Cómo hacerlo?

A. Editar el archivo $VCLOUD_HOME/etc/log4j.properties

B. Editar las líneas log4j.appender.vcloud.system.debug.MaxFileSize y log4j.appender.vcloud.system.debug.MaxBackupIndex fijando el tamaño máximo de los archivos de log y el número máximo de archivos a retener, respectivamente.

C. Guardar cambios en el archivo

D. No se requiere reiniciar el servicio vCloud Director

 

2. Local redireccionado

Consiste en usar el servicio rsyslog corriendo en el sistema operativo (RHEL o CentOS) en el que corre vCloud Director, para atrapar los logs que vienen de la aplicación y redirigirlos a uno o más servidores syslog remotos.  Debido a que syslog es un protocolo UDP y que por tanto carece de métodos de retransmisión en caso de pérdida de paquetes, es recomendable tener múltiples servidores syslog habilitados para captura de logs remotos.

¿Cómo hacerlo?

A. Instalar el paquete “rsyslog” en la celda vCloud (en caso que no esté ya instalado)

yum install rsyslog -y

B. Modificar el archivo $VCLOUD_HOME/etc/global.properties editando la línea

audit.syslog.host = 127.0.0.1

En éste punto, si solo se requiere redireccionar audit logs se procedería al paso D, si se busca redirigir también diagnostic logs, el procedimiento continúa en el punto C:

C. Editar el archivo $VCLOUD_HOME/etc/log4j.properties y agregar las líneas que indica la VMware KB # 2004564 especificando el servidor syslog local en la línea:

log4j.appender.vcloud.system.syslog.syslogHost=127.0.0.1

Los siguientes pasos consisten en habilitar a rsyslog para que reciba logs de la aplicación y los envíe a syslog remotos:

D.  Editar el archivo /etc/rsyslog.conf descomentando las siguientes líneas:

$ModLoad Imudp

$UDPServerRun 514

E. En el extremo inferior de ése mismo archivo, agregar la dirección IP de los syslog a los que se enviarán los logs:

*.*  @@server1

*.*  @@server2

..

F.  Guardar cambios en el archivo y reiniciar el servicio rsyslog:

service rsyslog restart

En éste punto ya empezarán a recogerse logs en el servidor o servidores syslog que se haya especificado.
3. Directamente centralizado

Finalmente, éste método provee envío directo de audit y diagnostic logs a un y solo un servidor syslog remoto que puede ser TCP o UDP.

¿Cómo hacerlo?

Envío de audit logs:

  1.  Modificar el archivo $VCLOUD_HOME/etc/global.properties editando la línea

audit.syslog.host = IP_SYSLOG_REMOTO

para que refleje la IP del syslog server.

2. Reiniciar el servicio vmware-vcd

Envío de diagnostic logs:

A. Editar el archivo $VCLOUD_HOME/etc/log4j.properties y agregar las líneas que indica la VMware KB # 2004564 especificando el servidor syslog local en la línea:

log4j.appender.vcloud.system.syslog.syslogHost=IP_SYSLOG_REMOTO

B.  Reiniciar el servicio vmware-vcd

Otros recursos

Recomendado Sesión 192 del Podcast de Packetpushers.net : “Logging design and best practices

http://packetpushers.net/show-192-logging-design-best-practices/

PDTA: Sé que este es un post largo y puede resultar confuso el tema, si se generan dudas no dude en escribirlas en los comentarios; pronto estarán publicados los slides y la grabación del podcast vBrownBag LATAM en el que traté este tema con un lab en vivo.

Saludos!