vCloud

vCloud Director 5.5 – ¿Que hay de nuevo?

Que tal gente, el día de hoy vamos a hablar de lo nuevo que nos ofrece vCD 5.5, hemos estado revisando lo nuevo que nos ofrecerá vSphere 5.5 en el momento que sea liberado al publico (GA), pero todavía no tocamos otros productos que también fueron mejorados entre los cuales se encuentra vCD.

Mejoras a nivel de vApp

Aquí estaremos revisando las mejoras que impactan directamente a nuestras VMs o servicios:

  • Soporte para vm compatibility o harware virtual versión 10 –  permitiéndonos  utilizar adaptadores SATA para los discos de las VMs y CD/DVD.
  • Multi–core vCPUs – Esto nos permite definir múltiples cores en cada socket de vCPU, generalmente esto nos beneficia en temas de licenciamiento. Recordemos que la manera de realizar la asignación de pCPUs vs vCPUs a nivel del host ESXi es exactamente igual, un core virtual o un vCPU uni core son asignado de la misma manera por el scheduler de el vmkernel.

multicorevcd

  • Uso de dispositivos USB desde el cliente de VMRC en versiones anteriores podíamos redireccionar dispositivos como CDs y floppys, ahora se agrega la capacidad de poder redireccionar dispositivos USB.

dispositivosvmrc

  • Modificación de hardware en “caliente” – esto puede resultar bastante interesante, tenemos la posibilidad de modificar el hardware virtual de una VM dentro de un vApp. Podemos agregar, quitar y crecer en “caliente” discos duros, de igual manera podemos agregar tarjetas de red (vNICs) en caliente, removerlas, conectarlas y desconectarlas (esto no es posible solo a nivel de la vNIC principal). Por último podemos agregar vCPUs multicore en caliente.
  • Personalización de templates de vApp – Tenemos la posibilidad de modificar el hardware virtual de un template de vApp antes de agregarlo a nuestra “nube”, esto nos permite modificar la o las VMs que pertenezcan a este vApp a nivel de vCPU, RAM, y discos duros. Debemos de tener las siguientes consideraciones, solo se soporta hw virtual 8 en adelante, no podemos modificar la cantidad de cores, no podemos re dimensionar discos con snapshots y/o que sean fast provisioned y en el caso que agreguemos espacio a un disco a nivel del gOS necesitamos configurar el OS para utilizar dicho espacio.

modificacionhwvcd55

  • Importar y exportar OVFs – se nos permite en esta versión importar vApps directamente desde templates y de igual manera exportar un vApp como OVF. Algo bastante interesante es la capacidad de poder “resumir” conexiones interrumpidas, por lo que si tenemos un problema al importar un OVF de varios GB podemos resumir la transferencia. También se nos permite la descarga desde el catálogo de distintos archivos, como ISOs, vApps, etc. (estaremos hablando un poco sobre la capacidad de los catálogos mas adelante)

descargavcd55ovf

  • Operaciones a nivel de vApp con estado de memoria activo (encendida) – Se nos brinda la capacidad de poder clonar la memoria activa de un vApp que puede estar en funcionamiento o suspendida. Esto nos permite 3 tipos de operaciones, clonar un vApp encendida/suspendida, capturar al catálogo un vApp encendida/suspendida y exportar un vApp suspendido a OVF. Esto es posible a través de snapshots que suceden a nivel de vCenter, es importante notar que si exportamos un vApp con estado de memoria OVF y lo deseamos importar en otra instancia de vCenter la memoria será descartada.
  • Personalización de Guests las capacidades que se tienen a nivel de vCenter para personalizar y modificar los gOS al momento de realizar la entrega a partir de templates ya es exactamente la misma que tenemos a nivel de vCD, también se agrega la capacidad de poder importar especificaciones a través de xml.
  • Shadow VMs – el mecanismo de “shadow vm” existe desde la versión 1.5 de vCD, esto fue pensado para aquellas vApps que utilizan Fast Provision, básicamente al realizar la entrega de un vApp que este basado en Fast Provisioning este dependerá de la imagen base (muy parecido a lo que tenemos a nivel de Horizon View con linked clones), el problema surgía en el momento de tener entrega de vApps a través de distintos datastores que puedan incluso estar en distintos vCenters, para esto se realiza una copia de la imagen base en el datastore destino a partir de la cual los clones estarían accediendo. En la versión 5.5 tenemos la opción de realizar un “eagerly provision” que básicamente estará creando estos shadow VMs en el background, toma en cuenta un concepto de “hubs” que para nosotros serían resource pools (pVDC) y storage profiles presentados a dicho pVDC o “hub”, en el momento que se detecta que un datastore con un consumo alto (alerta amarilla) se creará en otro datastore que pertenezca a dicho storage profile el shadow vm para no tener impacto a nivel del aprovisionamiento de nuevos vApps (básicamente espera para la creación de los shadow VMs). Esto no esta habilitado por defecto tenemos que habilitarlo a través del archivo global.properties

Catálogos

En esta sección tenemos capacidades que vienen a cubrir distintas peticiones por los usuarios de vCD, podemos ver casos de uso distribuidos, tiering etc. Vamos a conocer las nuevas capacidades:

  • Soporte para distintos perfiles de almacenamiento En versiones anteriores de vCD el catálogo de una organización era colocado en el perfil de almacenamiento que era asignado a el pVDC a partir del cual se proveian recursos a la misma, esto generalmente impactaba de manera negativa teniendo información con un requerimiento de almacenamiento distinto a las vApps de producción. En la versión 5.5 podemos asignar un perfil de almacenamiento en específico para que el catálogo sea almacenado (ej. Tier3 / SATA).

catalogoperfilstorage

  • Publicación, suscripción y almacenamiento remoto – En el momento de la creación de un catálogo podemos definir si este tendrá la capacidad de ser publicado de tal manera que otros catálogos puedan sincronizarse con el, es decir, poder copiar la información (vApps, ISOs, etc) que viven en el. Todo cambio que es realizado en el content catalog origen será reflejado en aquellos catálogos que estan suscritos al mismo, esto suscripcióncatalogose maneja a través de versiones de el catálogo, aquí podemos pensar en distintos casos de uso, por ejemplo, publicación de un catálogo a distintas organizaciones, ambientes distribuidos geograficamente, distintas instancias de vCD, etc. El catálogo a ser suscrito deberá presentar una password y el link para suscribirse, una vez que este esta suscrito a través de un protocolo llamado vCSP (VMWare Content Suscription Protocol) se realizarán las deciciones si se necesita actualizar cierto archivo que tenga una nueva versión o que sea nuevo en el catálogo, todo esto sucede siempre a través de un “pull”, es decir, el catálogo suscrito descargará la información del catálogo origen, nunca se tendrá un “Push” de información.  Algo interesante es que los suscriptores pueden seleccionar un modelo “on–demand” que unicamente descarga el metadata de dicho catalogo y no la información en su totalidad, el listado de objetos mostrará todo el contenido y en el caso de requerir un objeto (ej. ISO) se realiza una sincronización manual con un click derecho y “syncrhonize”.
    Se permite que el “publicador” (al cual los catálogos se sincronizan) no sea un catálogo existente sino almacenamiento que pueda trabajar con JSON (Java Script Object Notation) para publicar y sincronizar los archivos que puedan ser almacenados en este mismo… (¿OpenStack Swift?)….
    Por último es interesante saber que el catálogo ya puede almacenar todo tipo de objetos, no solo ISOs, templates, etc..

Acceso y configuración

  • Soporte para CentOS 6.x como gOS donde instalar vCD.
  • Preparación de Hosts para vCD 5.5  en versiones anteriores se requeria de manera forzosa preparar los Hosts ESXi que serían utilizados por vCD, esto entre otras tareas instalaba el agente de vCD o vslad. En la versión 5.5 a menos que se requiera de VCNI (vCloud Network Isolation) se tendrá que instalar el agente, si no es necesario y los hosts son versión 5.5 de vSphere no se requerirá el agente de vCD.
  • Storage Profiles – vCD 5.5 puede trabajar con Profile Driven Storage y  Storage Policy Based Management (SPBM) que esta disponible en la versión 5.5, ambos los presenta como storage profiles… Para conocer mas sobre SPBM les sugiero leer el siguiente articulo de la oficina del CTO de VMware “Storage Directions for the software defined datacenter”
  • HTML5 – para los clientes basados en OSX (Firefox y Chrome) se ofrece acceso a la consola de la VM a través de HTML5 sin necesidad de un plugin. No se trata de un sustituto para el VMRC, ya que este no soporta dispositivos USB, CDs, etc, no realiza un “grab” o capturado del cursor, no toma las combinaciones de teclas, etc.. es muy parecido a VNC.

Extensibilidad

vCD 5.5 tiene la capacidad de registrar dos extensiones para interactuar con ellas, vFabric Data Director y Cloud Foundry. Esto permite a los administradores presentar a las organizaciones servicios de DBaaS (Database As A Service) y SaaS (Software As A Service).

Actualización a Lab

Que tal gente, solo para platicarles que debido a requerimientos de recursos de computo para poder tener ambientes mas complejos y poder estudiar, escribir en mi blog y en otras fuentes me dí a la tarea de actualizar mi laboratorio.

Como parte de este esfuerzo se agregó un nuevo nodo ESXi para sustituir otros 2 nodos de menor capacidad que gestionaban las cargas de Management (vCD, vCenter, vCO, etc). Podemos ver que en la capacidad actual cluster ya se cuenta con 128GB de memoria RAM y 29GHz de CPU.

Screen Shot 2013-07-28 at 11.14.11 PM

Además de la capacidad para poder contar con ambientes mas complejos que consumen mas recursos de computo, también esto fue con el objetivo de poder reducir la cantidad de energía consumida, podemos ver que con los 2 servidores (whiteboxes) encendidos y un servidor que ya se convirtió en workstation (16GB de RAM/proc hexa core) se consumen aprox 420 – 450 Kw (esto en estado “steady” sin carga), falta realizar una prueba de estrés al ambiente para poder determinar los consumos reales en el momento de estar trabajando con el mismo.

imageEl consumo que podemos ver en la imagen esta siendo realizado por los siguientes elementos de mi laboratorio:

* 2 “Servidores” (Whiteboxes)

* NAS PX6 -300D Iomega con 6 discos SATA

*Switch Dell Powerconnect 2708

*Switch TRENDnet teg-s80g (soporte para jumbo frames, tráfico iSCSI)

* Workstation

Características de Whiteboxes:

“Servidor 1”

  • Motherboard Gigabyte X79-UP4 Socket LGA2011 8 DIMMs
  • Procesador Intel Core i7-3820 Quad/HT
  • 64GB RAM DDR3 / 1333MHz (no ECC)
  • 2 Puertos LAN gigabit onboard, intel 82579V/Realtek

“Servidor 2”

  • Motherboard Asus P9X79 Deluxe Socket LGA2011 8 DIMMs             la foto
  • Procesador Intel Core i7-3820 Quad/HT
  • 64GB RAM DDR3 / 1333MHz (no ECC)
  • 2 Puertos LAN gigabit onboard, intel 82579V/Realtek

Workstation

  • Motherboard Gigabyte GA-880GM Socket AM3 4 DIMMs
  • Procesador AMD Phenom II X6 1090T
  • 16GB RAM DDR / 1333MHz (No ECC)
  • 1 Puerto LAN gigabit Realtek onboard RTL8169
  • 1 Puerto LAN gigabit Realtek en tarjeta PCI RTL8169

¿Siguientes Pasos?

Como siguientes mejoras tengo en mente mejorar el networking del laboratorio tal vez con un switch SG300-x para poder contar con capacidades de L3 y poder consolidar el networking en solo un switch administrable.
También se tiene la necesidad de crecer el almacenamiento disponible, por cuestiones de presupuesto en su tiempo adquirí discos duros de 250GB SATA para la NAS Iomega, cosa que pienso crecer a discos de 3TB.

Ya con el tiempo iremos viendo que mas se agrega, tal vez podrán considerar esto como una inversión que no se justifique, pero aparte de utilizarlo para escribir aquí, estudio, y me divierto en el ambiente (si para mi es divertido el tiempo en laboratorio) así que siempre que pueda estaré agregando mejores componentes a este lab.

Tip para agregar SCVMM 2012 en vCAC 5.2

Que tal gente, el día de hoy me encuentro configurando mi ambiente demo en el laboratorio donde estoy incluyendo como endpoints para mi instancia de vCAC (vCloud Automation Center), SCVMM 2012 gestionando Hyper-v 2008R2, KVM (CentOS 6.4) y claramente vSphere 5.1, vCD será incluido en un futuro en conjunto con XenServer.

Deje lista la instalación de SCVMM 2012 SP1, cree un cluster y me disponía a crear un endpoint en mi instancia de vCAC 5.2, esto para poder comenzar a jugar con los recursos que me proporcionaría Hyper-v, y lo primero que me vino a la cabeza fue el instalar el agente para Hyper-v para después agregar un endpoint que reflejara los recursos que se estarían descubriendo a través de este agente (En este caso ya no se requiere del agente de Hyper-v, esto se realiza nativamente). Agregué las credenciales con las cuales me estaría conectando a dicho endpoint y me dispuse a crear el endpoint virtual de tipo SCVMM:

Endpoint creado

Como pueden ver el endpoint fue agregado sin ninguna novedad y lo único que faltaba era realizar una sincronización de sus recursos para después crear un grupo enterprise.

Así que esta vez hice click derecho sobre dicho endpoint de SCVMM, y ejecute el workflow de “Data Collection”:

Screen Shot 2013-07-11 at 6.43.28 PM

Esto debe de ejecutar un conjunto de tareas (en este caso powershell) que obtienen los recursos disponibles de dicha instancia de SCVMM, para esto podemos ver el resultado de dicho workflow haciendo click en “Workflow History”

Screen Shot 2013-07-11 at 6.46.42 PM

Y bueno analizando lo que se me presentaba, podía ver que la última tarea que estaba siendo ejecutada por el DEM (worker) era un workflow llamado “ScvmmEndpointDataCollection” y que este no era reconocido como un cmdlet (esto por powershell) y claramente la tarea aparecía como fallida.

Revisando algunos de los requerimientos en la guía de instalación de vCloud Automation Center 5.2 (específicamente en la página 61 “SCVMM Requirements”) pude notar que NO cumplia con los requerimientos para registrar una instancia de SCVMM:

The DEM must have access to the SCVMM PowerShell module installed with the console

Por lo que lo primero que revisando en nuestra primera y única herramienta de referencias exactas (Google) pude encontrar el blog de Mike Laverick, donde especificaba esto, confirmando así que lo que debía realizar era la instalación de el VMM console que forma parte de SCVMM, conecté el .iso de SCVMM a mi instancia de vCAC:

cd

y comencé con la instalación (importante notar que requieren PowerShell v3.0 para poder instalarlo):

vmmconsole

Screen Shot 2013-07-11 at 7.03.56 PM

Una vez instalado podemos notar que se agregan los módulos para la gestión de VMs, ahora es necesario cambiar la política de ejecución de PowerShell a “RemoteSigned” o “Unrestricted” Por lo que ejecuté Powershell e ingresé el comando:

set-executionpolicy -executionpolicy unrestricted

Screen Shot 2013-07-11 at 7.06.21 PM

Una vez realizado esto, decidí ejecutar de nuevo la recolección de datos de el endpoint (SCVMM), teniendo resultados satisfactorios:

Screen Shot 2013-07-11 at 7.09.49 PM

Con esto ya era cuestión de crear un grupo enterprise para poder seleccionar los nuevos recursos que habían sido descubiertos y poder verificar que efectivamente se estaba recolectando la información de dicho endpoint:

Screen Shot 2013-07-11 at 7.13.02 PM

Y pues bueno yendo al endpoint y seleccionando “View Compute Resources” ya podía ver que todo estaba listo para continuar:

Screen Shot 2013-07-11 at 7.14.58 PM

Conociendo vCloud Automation Center (vCAC) 5.1 – parte 1

Que tal gente, el día de hoy vamos a hablar sobre un producto muy reciente de VMware que es el resultado de la adquisición de DynamicOps, su nombre es vCloud Automation Center (vCAC). Este producto llega a cubrir varias areas de oportunidad que el stack de cloud computing ofrecido por VMware en esos momentos le faltaba. Vamos a conocer más sobre este producto:

 

¿Que es vCloud Automation Center?

Screen Shot 2013-01-15 at 11.34.06 AM

vCAC nos permite crear un SDDC al 100% debido a su naturaleza, vCAC antes conocido como Dynnamic Ops es una solución pensada para la administración,orquestación, auto provisionamiento y gestión de los ciclos de vida de los distintos componentes que forman una nube privada. vCAC nos permite contar con ambientes de distintos proveedores, tanto físicos como virtuales.

Esta solución nos brinda la capacidad de poder definir vDCs elasticos consumiendo recursos de distintos endpoints como puede ser vSphere, vCloud Director, Hyper-v, AWS/EC2, entre otros.

vCAC cuenta con múltiples integraciones y workflows para distintos productos como lo podemos ver en la siguiente imagen:

integracionesvcac

 

¿Cuales son los componentes de vCAC?

Screen Shot 2013-01-15 at 12.01.40 PM

  • Base de datos – Básicamente aquí se estarán almacenando todos los datos que son utilizados por la aplicación. IMPORTANTE en esta versión (5.1) solo se tiene soporte para MS SQL.
  • Model Manager – controla el acceso a los datos y la base de datos e implementa la lógica de negocio que se requiere ejecutar (workflows).  Es utilizado para crear y gestionar modelos y flujos personalizados lo que permite que se intergre con muchas soluciones externas e incluso de 3eros.
  • Manager Service – Este servicio se encarga de intergar los distintos componentes como lo son, base de datos, agentes, AD, SMTP.
  • Portal Web Site – Interfaz web para la administración este se comunica con el servicio de Model Manager para obtener actualización de los distintos DEMs, agentes proxy (vSphere, Xen, Hyper-v, etc) y la base de datos.
  • Reports Website – Portal que nos provee de reportes propios de vCAC, este portal solo interactua con la base de datos.
  • Distributed Execution Manager (orchestrator) – Los DEMs son los encargados de distribuir (orquestador) y ejecutar los flujos deseados, DEO o Distributed Execution Orchestrator (DEM con rol de orquestador) se encarga exlusivamente de procesar y distribuir los flujos para ser ejecutados en los distintos DEMs ejecutores o “workers”.
  • Distributed Execution Manager (worker) – estan encargados de ejecutar los flujos deseados.
  • Agentes – Tenemos distintos tipos de agentes, estos se encargan de comunicarse con los recursos o sistemas operativos guest. Los Proxy Agents se comunican con plataformas como vSphere, Hyper-v y Xen, tenemos agentes para sistema operativo (guest agents) y para ambientes como VDI (integration agents).

 

¿Como se ve la integración entre vCD y vCAC?

Nos debe quedar en claro que vCAC coexiste con vCD. vCAC aprovecha los recursos y construcciones lógicas de vCD para poder aprovisionar vApps desde vCAC en la siguiente imagen podemos ver la relación entre las distintas construcciones lógicas:

vcdvcac

Tenemos conceptos nuevos como lo es los blueprints y Resource reservations, los cuales estaremos analizando en un ambiente demo para poder tener una idea mucho más clara.

 

¿Como podemos adquirir vCAC?

Contamos con 2 opciones principales:

  • SKUs standalone de vCAC – Estos estan en sus versiones para servidores (virtual, físico y nube pública), escritorios (usuarios concurrentes) y la versión para desarrollo.
  • vCloud Suite Enterprise – vCAC esta incluido como parte de la suite de vCloud, aquí estamos restringuidos al uso exclusivo en las VMs que son ejecutadas en los hosts ESXi que cuentan con licenciamiento de vCloud Suite.

 

¿Como instalo vCAC? ¿Que necesito para poder probarlo?

Pues bueno, creo que llegamos a la parte interesante y la que muchos quieren ver, acá les dejo un video tutorial creado por mi de como poder cumplir con todos los requerimientos y después instalar el producto.

vCloud Director 101 – parte 1

Que tal gente, el día de hoy voy a comenzar con una serie de posts sobre vCloud director, en esta serie vamos a estar aprendiendo que es vCD, como instalarlo y configurarlo. Vamos a conocer algunos tips y algo de troubleshooting.

Comencemos por entender que es vCloud director, vCD es una solución de VMware que nos permite construir nubes privadas o hibridas agrupando recursos de infraestructura virtual en datacenters virtuales (vDC) los cuales podemos ofrecer al usuario final u organización desde una interfaz web. En pocas palabras nos permite entregar infraestructura como servicio (IaaS) partiendo de recursos virtuales.

Una vez instaurado, el cliente solo necesitará una conexión a internet para ingresar a sus recursos, los cuales serán entregados según los requerimientos del cliente. El proveedor se encargará de definir distintos niveles de servicio en los cuales se tendrán distintas capacidades de computo y performance.

Antes que nada seria bueno diferenciar lab manager y vCD ya que me he encontrado con bastantes personas que se cuestionan esto,

  • Lab Manager: 1 servidor contiene el aplicativo y base de datos, solo puede interactuar con 1 vCenter y 1 Datacenter. En pocas palabras estamos limitados a una instancia de vCenter y somos vulnerables a la caida de el servidor que contiene Lab Manager y su base de datos.
  • vCloud Director: múltiples servidores (cells) que eliminan el único punto de falla que se tenia el LM, estas multiples células trabajan de manera balanceada y sincronizada. En vCD podemos interactuar con varias instancias de vCenter (25 instancias máximo) y con varios datacenters con lo cual se incrementa nuestra escalabilidad.

Arquitectura de vCloud Director

Comencemos por describir a una célula de vCD:


Front End

  • Webapplet Servlet – también conocido como jetty, maneja todas las conexiones web a la célula con motivos de administración
  • Transfer service – este servicio se encarga de permitir el subir y descargar VMs, vApps y media (Isos/floppys) hacia o desde la nube a través de HTTPs
  • Console Proxy – este servicio permite las conexiones remotas a través de HTTPs a las VMs, la comunicación se re dirige al interior de la nube en los puertos 902/903 con lo cual evitamos el contacto directo con la plataforma vSphere.
  • Despachador REST –  este servicio se encarga de manejar todas las peticiones  (GET, PUT, DELETE, & POST) a través del API de REST (Representational State Transfer) sobre HTTPs, redireccionando estas peticiones a los distintos servicios de la célula.
  • Servicios OSGi – plataforma modular para JAVA, les recomiendo leer el siguiente link para una descripción completa de OSGi http://javaup.org/?q=node/57

Back End

  • VC Inventory – es responsable de monitorear los cambios en  el inventario de vCenter, se tiene un cache de este inventario.
  • VC Control – es responsable de mandar las operaciones correspondientes a cada uno de los vCenters (en el caso de tener un ambiente de múltiples instancias de vCenter)
  • VC Proxy – también conocido como VC listener, a través de este se obtienen las actualizaciones de vCenter

¿Como abstrae los recursos vCloud Director?


  • Provider vDC – grupo lógico de recursos abstraídos de una infraestructura virtual (resource pools, datacenters, clusters incluyendo almacenamiento y red). Con estos grupos lógicos podemos definir distintos niveles de servicio (tier 1, tier 2, etc) englobando distintos tipos de recursos.
  • Organización – grupo lógico de usuarios a los cuales les estaremos presentando recursos, estas organizaciones están aisladas de otras que puedan estar compartiendo recursos físicos de una misma nube.
  • Organization vDC (Org-vDC) – conjunto de recursos ofrecidos a una organización, estos son obtenidos a partir de uno o mas Providers vDCs, con un modelo de asignación de recursos (pay-as-you-go,reservation pool, allocation pool)

Modelos para asignar recursos a las organizaciones

Vamos a conocer los modelos para asignación de recursos que tenemos: