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

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

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:

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:

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.

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

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

Saludos!

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

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

La arquitectura

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

¿Enterprise o Standalone CA?

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

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

Root y Subordinates

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

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

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

Algoritmo de hash

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

Conclusión

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

 

Saludos!

Libro: vRealize Operations Performance and Capacity Management

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

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

Primera novedad: el autor

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

Segunda novedad: el enfoque

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

Una palabra final: aplicación práctica

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

Conclusión

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

Tres niveles de (in) dependencia de Multicast en VXLAN

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

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

1. vCloud Networking & Security: barato como un cachorrito

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

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

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

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

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

VMware NSX: el auge del plano de control distribuido

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

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

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

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

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

Saludos!

VXLAN: conceptos, funcionamiento e implementación (2/2)

Ha pasado un buen tiempo desde que publiqué la primera parte de esta entrada y bueno, ya es hora de continuar.

Entre más aprendo sobre el tema, más difícil se hace comprimir todo en un post. En ésta ocasión cubriré la implementación de VXLAN en un entorno VMware vSphere y algunos de los siguientes temas serán tratados en entradas posteriores:

A. VXLAN y el requisito de multicast: tres niveles diferentes de (in)dependencia de Multicast

B. vCNS Edge como un eficiente y costo-efectivo gateway VXLAN

C. Un día en la vida de una trama VXLAN

Sin más, entremos en materia.

Configuración de VXLAN en un entorno vSphere

Para preparar un clúster para VXLAN se deben cumplir los siguientes prerrequisitos:

A. Una VLAN aprovisionada en la red física. Esta se usará para la comunicación entre VTEPs

B.Todos los host del clúster deben estar unidos a un distributed Virtual Switch

C. La red física debe soportar el paso de paquetes con tamaño mínimo de 1600 bytes sin requerir fragmentación

El procedimiento se lleva a cabo desde la interfaz de vCNS Manager con los siguientes pasos:

1. Dirigirse a Datacenters > Network Virtualization > Preparation

2. Dar clic en Edit…

3. Seleccionar un cluster y asociarlo con el respective dVS y VLAN ID que se haya obtenido previamente:

4. En la siguiente pantalla, seleccionar la política de Teaming de los uplinks o interfaces de red en el dVS. Está soportado Etherchannel, Link Aggregation Group o Static Failover, éste último es el que selecciono en el laboratorio pues no cuento con una implementación que soporte los demás métodos en la red física.

El resultado de los procesos anteriores luciría algo mejor que lo siguiente:

La solución al inconveniente anterior en gran parte, consiste en asignar las IPs a las vmknic creadas por VXLAN en cada host ó configurar un DHCP server en la VLAN que usuarán los VTEP.

Ahora se configurarán los rangos del grupo Multicas tasi como de los VNI que se usarán en la implementación. Para ello los pasos continúan de ésta manera:

5. Dar clic en “Segment ID” > “Edit…”

Es necesario que se configure la misma cantidad de VNI o “Segment IDs” que de IPs multicast en el grupo, cada segmento VXLAN llevará asociada una IP del grupo Multicast.

Los pasos siguientes aplican si el entorno de implementación no es administrador por vCloud Director (en caso que lo fuere, en éste punto el Provider vDC ya estaría listo para hacer uso de redes VXLAN). El post de @punchingclouds brinda mayores luces al respecto.

6. Dirigirse al link de “Network scopes” y crear un scope con el clúster previamente preparado:

7. En este punto se puede iniciar con la creación de redes, segmentos o VXLAN virtual wires (los nombres son equivalentes) que en vCenter se verán como portgroups del dVS a los cuales se pueden conectar máquinas virtuales de la manera tradicional. La creación de redes se lleva a cabo en el link “Networks”:

8. Finalmente en la pestaña “Edges” se puede aprovisionar una instancia de vCNS Edge que sirva como Gateway para las MVs conectadas a un VXLAN virtual wire y que puedan salir al “mundo exterior” para comunicarse con servicios en Internet o con equipos físicos en VLANs tradicionales.

Profundizaré en ello en un post posterior.

Gracias!

VXLAN: conceptos, funcionamiento e implementación (1/2)

Por estos días VXLAN parece cada vez más estar en boca de todos los que siguen el mercado de la virtualización de redes. Por un lado el Internet Engineering Task Force  (IETF) aprobó hace cerca de tres semanas pasar la tecnología VXLAN del estado borrador o draft a ser un protocolo reconocido por un RFC, lo que provee una base más sólida para su consolidación.

Por otra parte, el creciente auge de la suite de SDN de VMware: NSX ha llevado a partners como Juniper Networks, Arista Networks, entre otros; a ofrecer dispositivos capaces de integrarse con NSX usando como protocolo overlay a VXLAN, por sus capacidades y su flexibilidad en cuanto a requerimientos de infraestructura.

Esta es la motivación para ésta serie de 2 entradas que, dedos cruzados, se convertirán en más publicaciones sobre el avance de NSX como plataforma para SDN.

Entremos en materia.

VXLAN: ¿qué es?

Es un protocolo de superposición de redes (overlay networks) definido por el RFC 7348 que el IETF aprobó hace algunas semanas, y que hace uso del protocolo IP como la base sobre la cual implementa segmentos LAN similares a las VLAN, pero con un esquema diferente de encapsulación que eleva considerablemente el número de redes que es posible transportar, a la vez que aprovecha la ubicuidad y alcance geográfico de IP para agregar flexibilidad y extensibilidad a la implementación de redes L2.

¿Por qué VXLAN?

Uno de los desafíos a los que se enfrentan actualmente los arquitectos de red en el centro de datos moderno, consiste en las limitaciones del omnipresente Spanning Tree Protocol que es casi el mecanismo de-facto que las organizaciones implementan para evitar los loops en capa 2, sin embargo STP inevitablemente deja múltiples links sin uso por lo que en la escala masiva de los datacenter para la nube, esto significa un enorme costo de inversión en puertos que finalmente no se pueden usar.

Por otro lado y a diferencia de protocolos de capa 3 como IP, las redes de capa 2 tienen poca movilidad fuera del datacenter y ciertamente la carga operacional para extenderlos o activar dominios capa 2 en un sitio alterno reduce las opciones para la implementación efectiva de requerimientos como Disaster Recovery de cargas de trabajo virtualizadas hacia un datacenter alterno, manteniendo todas las propiedades de conectividad del sitio principal de forma automatizada.

Por si fuera poco, el mecanismo tradicional de aislamiento de red en capa 2 que son las VLANs, definen el VLAN ID como un atributo numérico de 12 bits, limitando el número de redes posibles a 4094. Por muchos años pareció lejana la posibilidad de alcanzar este límite, pero en el datacenter actual con múltiples tenants consumiendo servicios de conectividad y a la vez creando sus propias redes y servicios, éste límite rápidamente se ha convertido en un obstáculo a la vista para la escalabilidad del centro de datos.

Figura 1. VXLAN agrega un ID de 24 bits antes de transportar el paquete por la red IP. En el destino se lleva a cabo la desencapsulación.

VXLAN surge, pues, como una propuesta conjunta de fabricantes como VMware, Cisco, RedHat, Arista, entre otros; para convertirse en el mecanismo que efectivamente extienda la funcionalidad de las VLAN tanto en escala como en alcance. En escala pues su identificador de red, definido como VNI (VXLAN Network Identifier o Segment ID) es de 24 bits de longitud con lo que se alcanza un máximo de 16 millones de redes que pueden converger en una misma implementación VXLAN.

La extensión del alcance de las VLAN la logra VXLAN al valerse del protocolo IP, tan ampliamente implementado y con diversos mecanismos de movilidad, como medio de transporte para las redes L2 que viajan encapsuladas. Es por esto que a VXLAN también se le incluye en la categoría de tecnologías o protocolos de tunelamiento.

Componentes

La siguiente es una lista de componentes necesarios para una implementación de VLXAN en un entorno VMware:

A. VTEP (VXLAN Tunnel Endpoint): es la entidad que origina y/o termina túneles VXLAN. Se implementa en cada host ESXi y se compone a su vez de los siguientes módulos:

1. Módulo vmkernel: hace parte del distributed Virtual Switch (dVS) y se instala como un vib en el hipervisor. Actúa como plano de datos al mantener las tablas de enrutamiento así como se encarga de la encapsulación y desencapsulación de paquetes
2. Adaptador vmknic: se instala uno en cada host cuando el clúster se prepara para VXLAN. Se encarga de transportar el tráfico de control de VXLAN. Actúa en parte como control plane al alimentar la información de rutas visible en la red IP y alimentarla a la tabla mantenida por el plano de datos en el módulo vmkernel de VXLAN.
3. Port group VXLAN: incluye la información tradicional de los portgroups dVS de vSphere, y se crea un portgroup automáticamente por cada red ó segmento VXLAN implementado.

B. vCNS Manager: este es el verdadero plano de administración o management plane, pues ofrece la gestión centralizada de los segmentos VXLAN así como de las interfaces vmknic y los clústers en cuyos hosts se ha instalado el VTEP. No administra el tráfico como tal, pero si mantiene el estado actual de la implementación VXLAN dentro de un vCenter.

C. vCNS Gateway: es un appliance que ofrece servicios de conectividad y seguridad avanzados y que es implementado y administrado por vCNS Manager. Se trata de un componente realmente especial dentro de la arquitectura de VMware VXLAN pues tiene la capacidad de dar salida a las MVs conectadas a los segmentos VXLAN hacia el “mundo exterior” con funcionalidades de NAT, Firewall perimetral, DHCP, DNS Relay, VPN, entre otras y es una alternativa para la eterna pregunta acerca de cómo terminar segmentos o túneles VXLAN en dispositivos físicos. Esto será materia de otra entrada, pero quedémonos con que el vCNS Gateway es efectivamente el puente entre redes VXLAN y servicios externos de conectividad.

Figura 2. Arquitectura simplificada de implementación de VMware VXLAN

En la próxima entrada veremos los mecanismos bajo los cuales opera VXLAN así como los pasos prácticos para la implementación del protocolo en un entorno VMware.

Saludos!

Mi experiencia en el VCAP-CIA

El pasado lunes, Pat Gelsinger (VMware CEO) compartió una definición de valentía: ser decisivo en tiempos de incertidumbre. Bueno, debo decir que las circunstancias que en últimas me llevaron a tomar y aprobar el examen VCAP-CIA darían para pensar que algo de valentía hay en m, pues llegue el sábado pasado a San Francisco para VMworld y fue allí en la habitación del hotel donde decidí aprovechar el descuento, programar el examen para el día siguiente (!!) y terminar de estudiar en menos de 24 horas el 48% del blueprint, que era lo que me faltaba. Habiendo tardado alrededor de 3 meses estudiando el primer 52% (con toda la práctica necesaria) la tarea por momentos me pareció que había sido un gran error.

Finalmente presenté el examen y después de intensas 4 horas, esta es mi experiencia y mis recomendaciones:

1. Si ha leído previamente que uno de los factores más importantes para el éxito en un examen VCAP es la administración del tiempo, yo agregaría a ello la habilidad de desarrollar múltiples (entre 2 y 3) preguntas al mismo tiempo. Esto tiene que ver con que, al menos en mi experiencia, me había tomado 2 horas en resolver nada mas 8 preguntas, restaban 24 y la regla de tres simplemente daba para reprobar el examen por contestar solo la mitad. Fue allí que empecé a desarrollar tres preguntas a la vez anotando en la pizarra que Pearson suministra en el examen los números de esas preguntas para tener una rápida referencia visual y no olvidar responder ninguna a medida que avanzaba en las demás. Esta técnica salvó mi resultado en el examen.

2. Si ha leído previamente que el examen toca TODO el blueprint ha leído bien. No subestime ningún skill o habilidad que allí vea pues todas sin excepción serán evaluadas.

3. Recuerde que vCloud Director corre en un ambiente Linux por lo que debe sentirse a gusto con la linea de comandos y sin importar la tarea, siempre las man pages y la ayuda de los comandos evita que tenga que aprender de memoria comandos u opciones de los mismos.

4. El examen, como lo indica su versión de prueba o mock disponible en my.learn.vmware.com esta pensado para simular un ambiente de producción por lo que no debe temer considerarlo como tal y operarlo con el cuidado y proactividad necesarias.

Utilicé como principal recurso de estudio la guía de virtualizationexpress.com y el laboratorio que mi empleador me ha suministrado.

Sin mas, estoy feliz y sorprendido de haber aprobado. Se puede lograr mucho cuando estas bajo presión😉

Saludos

¿Cómo configurar widgets en vCenter Operations Manager?

No se puede corregir aquello que no puedes medir. Es ésta una de las premisas que en mi opinión guía la planeación de TI en sus diferentes capas.

VMware vCenter Operations Manager ofrece una cantidad casi abrumadora de métricas para el Software-Defined Data Center y poder asignarle un contexto y una metodología clara de presentación y análisis es clave en el éxito de la introducción de vCOPS en la organización.

Para lograr ésta meta, la creación de dashboards personalizados para vCOPS Custom ha probado ser una estrategia eficaz,  incluyendo en ésos espacios los widgets apropiados.

En éste artículo se cubrirá la configuración del widget “Top-N Analysis” en el contexto de la creación de un nuevo dashboard. Para conocer los diferentes tipos de widget así como mayores generalidades sobre dashboards de vCOPS, recomiendo la lectura del manual de usuario.

Procedimiento

1. Inicie sesión en vCOPS custom (https://URL_vCOPS_UI/vcops-custom)

2.  Dirigirse a la parte superior y dar click en Dasboards > Add:

3. En la sección de la izquierda, seleccionar el widget que se va a agregar y arrastrarlo a la sección derecha:

4. Una vez haya terminado de editar las propiedades del dashboard, proceda a dar click en OK

5. Dirigirse al nuevo dashboard y editar el widget haciendo click en el ícono de engrane de la parte superior:

6.  Allí verá múltiples opciones. Mencionaremos algunas puntuales:

Self provider: se deshabilita ésta opción en caso que se desee colectar métricas desde otro widget para mostrarlas en el widget actual. En caso de habilitarlo, el widget actual será quien colecte y despliegue las métricas, siendo éste el caso más común.

Bars count: define el tipo de Top que se va a desplegar, por ejemplo un valor de 5 en éste campo, significa que se mostrará un Top 5 de la métrica que elija.

Widget mode: puede trabajar con etiquetas o métricas. En éste caso se fija la opción en “Metric”.

7. En la parte inferior podrá seleccionar el tipo de métrica a desplegar. En el ejemplo se desplegará un Top 10 con las más altas latencias de lectura en los datastore de los múltiples vCenter conectados a ésta instancia de vCOPS:

Y éste es el resultado final (se omiten nombres para proteger la identidad de los implicados😉 ):Esta fue una muy breve introducción a la configuración del widget TOP-N Analysis.

Recursos adicionales

Curso: vCOPS Analyze and Predict

Libro: vCOPS Essentials de Lauren Malhoit

Saludos!

 

Configuración de un repositorio de disponibilidad continua para perfiles de usuario en pools RDS de VMware Horizon with View 6

Si, ya era hora de tener un título largo.

Como es sabido por casi todos, VMware Horizon 6 ahora soporta Microsoft RDS (yay!) y con ello se presenta una real alternativa para productos como Citrix XenDesktop al poder entregar pools de sesiones basadas en RDS.

En una implementación de éste tipo, no es soportado por ahora el uso de VMware Persona Management para la gestión de los perfiles de usuario por lo que se deben gestionar usando Group Policy en Active Directory.  Es común encontrar que un requerimiento funcional para un entorno de VDI es la redirección de los perfiles de usuario a un servidor de archivos centralizado, y aún mejor, establecer el mecanismo para proveer alta disponibilidad a ése repositorio.

Este post cubre las herramientas nativas de Microsoft Windows Server 2012 con las que se puede satisfacer éste requerimiento y la manera en que interopera con VMware Horizon 6.

Escenario de prueba

Windows Server 2012 R2 Standard Edition (x2)

Dos unidades compartidas:

1 para Quorum/witness disk

1 para almacenamiento de datos

Roles/features habilitados en los dos nodos:

Failover Cluster, File Server

Tres (3) tarjetas de red en cada servidor @1GBPs:

1 para almacenamiento iSCSI

1 para comunicación interna del clúster

1 para conexión de clientes al clúster

PROCEDIMIENTO

CREAR EL FAILOVER CLUSTER

1. Instalar el rol de File Server con las herramientas de administración en cada nodo:

Install-WindowsFeature FS-FileServer –IncludeManagementTools

2. Instalar el Feature de Failover Clustering en cada nodo:

Install-WindowsFeature Failover-Clustering –IncludeManagementTools

3. En solo UNO de los dos nodos configurar el feature de Failover Cluster:

A. Iniciar Failover Cluster Manager

B. Crear un nuevo cluster:

C.    Agregar el FQDN del nodo donde se está llevando a cabo la configuración:

D.    En la siguiente pantalla, seleccionar “Yes” para correr la validación
E.    Correr todas las pruebas de validación:

F.    Una vez concluyan las pruebas, se obtiene un reporte que puede arrojar error, warning o éxito. En caso que arroje Error, se deberán solucionar los inconvenientes reportados, en estado warning se puede crear el clúster pero se debe atender a las recomendaciones para tener un servicio completamente funcional:

G.    Seleccionar una dirección IP en la red de comunicación interna del cluster y asignar un nombre NETBIOS, éste nombre e IP deben corresponder a una entrada en el DNS:

CONFIGURAR EL ROL

En el Failover Cluster Manager, dirigirse a la sección Roles > Configure Role… :

B. Seleccionar el rol de File Server y dar click a “Next”:

C. En el caso de almacenamiento de perfiles de usuario, es seguro seleccionar la opción de “File Server for general use”. Es importante señalar también que éste opción es la única que soporta replicación DFS, y ésta característica es esencial para mantener los folders de perfiles replicados entre nodos:

D. Seleccionar un nombre NETBIOS y una dirección IP que usarán los clientes para acceder a los folders. Este NETBIOS e IP deben corresponder a una entrada en el DNS y el usuario con que se ejecuta el wizard debe tener permisos de escritura en el Controlador de Dominio, pues se agregará el nombre NETBIOS como una computadora más del dominio:

E. A continuación seleccionar el almacenamiento que se requiere habilitar en modo de Disponibilidad Continua.

Una vez se concluyen estos pasos, se verá el File Server en la pestaña de Roles:

AGREGAR EL FILE SHARE DE ALTA DISPONIBILIDAD

A. Seleccionar el File Server dentro de la sección “Roles” y en el menú de la parte derecha seleccionar “Add File Share”:B.    En el menú que se despliega, seleccionar “SMB Share – Quick” y dar click en “Next”:

C.    Seleccionar el volumen y el path que apuntará a este share:

D.    Asignar un nombre al share:

E.    Configurar las opciones necesarias, en el caso de usar el share para perfiles de usuario, es recomendable habilitar Access-Based Enumeration como una manera de aislar la visibilidad de los perfiles solo para los usuarios propietarios del perfil:

F.    En las siguientes pantallas configurar los permisos del share (los usuarios del dominio que vayan a ingresar al pool RDS deben tener permisos de escritura en éste share), y luego proceder a confirmar
G.    Verificar que el share se ha creado seleccionando el File Server en la sección “Roles”:

En éste punto ya se puede probar el acceso al share desde el Explorer de cualquier equipo en el mismo bosque (forest) Active Directory que aquel en el que está registrado el File Server:

A partir de éste punto, todas las operaciones de escritura/lectura sobre el SMB share quedaràn replicadas entre los File Server del clúster y los archivos permanecerán accesibles aún si hay miembros del clúster que no estén disponibles, siempre y cuando no se supere el número de fallas que el clúster tolera.

Redirección de los perfiles de usuario al CAFS

En éste punto se debe contar con acceso administrador al controlador de dominio Active Directory del entorno al que perteneces el pool RDS, lo anterior para poder editar la GPO y especificar la redirección de los folders de los perfiles de usuario al share previamente creado:

 

1. Iniciar sesión como con rol de Domain Administrator en el controlador de dominio
2. Ejecutar la herramienta Group Policy Management
3. Seleccionar la OU donde están alojados Remote Desktop Session Host
4. Editar la GPO asignada a esa OU:

5.    Ir a User Configuration\Policies\Windows Settings\Folder Redirection

6.    Allí seleccionar los folders que se van a redigir y en cada uno:
a.    Dar clic derecho
b.    Properties…
c.    Seleccionar Setting: Basic – Redirect everyone’s folder to the same location
d.    Seleccionar Target folder location: Create a folder for each user under the root path
e.    En el campo de root path ingresar la ruta del share recientemente creado:

CONCLUSION

Después de éste largo post y el procedimiento -que no es nada complicado aunque pareciera-, puede contar con un repositorio de disponibilidad continua al cual puede agregar servidores de archivos como miembros del clúster para elevar aún más la resiliencia de los perfiles de usuario.

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:

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:

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!