Cloud Computing

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

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

Tip de diseño – Dimensionamiento de vShield Edge

Que tal gente creo que la información que estaremos tocando en este articulo es de crucial importancia para un correcto dimensionamiento de un ambiente de vCloud o en el caso de estar utilizando vCNS en un ambiente vSphere. vShield Edge cuenta con 3 distintos tamaños para poder cumplir con distintos requerimientos, vamos a conocer que tamaños tenemos y en donde aplican cada uno de ellos. Es importante saber que aún cuando realicemos la entrega de algún tamaño en especifico, tenemos la opción de poder modificar posteriormente su tamaño.

Si realizamos la entrega de un appliance vShield edge a través de vShield Manager tenemos las siguientes opciones o tamaños de vShield edge:

tamañosedge

Y si lo comparamos en el caso de vCloud Director tenemos lo siguiente:

tamañosedgevcd

Básicamente en el caso de vCloud Director no contamos con el tamaño x-large, solo contamos con compacta y full que vendrían siendo compacta y large en vShield Manager. Pero… ¿Que diferencia existe entre estos distintos tamaños?

  • Compacta – Esta configuración o tamaño de vShield edge cuenta con 1 vCPU, 256MB de RAM y 512MB de Disco duro para almacenamiento de logs. Este tamaño esta pensado para un uso bajo en cuanto a ancho de banda y conexiones concurrentes se refiere, los casos de uso vendrían siendo VMs de bajo consumo en red o ambientes de lab/Desarrollo. Esta pensada para hasta 64,000 conexiones concurrentes y un throughput de <1Gbps. El uso de IPsec VPN o SSL VPN-Plus no es recomendado con este tamaño de apliance debido al overhead o la cantidad de procesamiento que se requiere para manejar dichas conexiones.
  • Large – Cuenta con 2 vCPUs , 1GB en RAM y 320 MB en disco para logs. Este tamaño o configuración esta pensado para soportar hasta 1,000,000 de conexiones con aproximado de 7Gbps y soporta el uso de SSL VPN-Plus y IPsec. Este es el tamaño que debemos de utilizar en ambientes productivos en vCD aunque no esta pensado para VMs con un tráfico excesivo.
  • x-large – Este tamaño de vShield edge cuenta con 2 vCPUs, 8GB en RAM y 320MB para logs. En este caso utiliza un sistema operativo de 64-bits a diferencia de large y compact. Este tamaño esta pensado para mas de 1,000,000 conexiones concurrentes pero no cuenta con soporte para SSL VPN-Plus. No esta soportado para vCloud Director.

Aunque no tengamos soporte por vCD para x-large, podemos realizar el “upgrade” o modificar el tamaño de nuestros vShield Edge desde la consola de administración de vShield Manager, claramente esto no esta soportado.

En la siguiente imagen podemos ver que tenemos 2 appliances de vShield Edge, ambas de tamaño “Large” estas fueron entregadas desde vCD 5.1:

applianceslab

Para poderlas llevar al tamaño x-large es tan simple como seleccionar el appliance en cuestión y hacer click en el menu de “actions” lo que nos permitirá seleccionar “Convert to X-large”:

conv-x-large

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.

Entendiendo VXLAN

Que tal gente, el día de hoy vamos a hablar de algo que llegó para quedarse y que de seguro han estado o estarán escuchando en esta epoca, estaremos analizando de que se trata VXLAN y su arquitectura.

Antes que nada quiero dejarles claro que aunque dentro de VMware pertenezca a un grupo de SMEs para networking en lo absoluto me considero un guru ni nada por el estilo, así que si en algo podemos mejorar este articulo o si pueden descubrir un problema con el mismo les pido que puedan apoyarme con sus comentarios.

¿Que es VXLAN?

Bueno, creo que esta es la pregunta obligada… VXLAN por sus siglas en ingles Virtual eXtensible Local Area Network actualmente es un draft del IEEE (Internet Engineering Task Force) que ha sido desarrollado por varias compañias lideres como Cisco, Arista, VMware, Broadcom, etc. Básicamente se trata de un prótocolo de encapsulamiento para poder crear redes de L2 sobre L3, cada red de L2 creada se le conoce como un segmento de VXLAN que es identificado de los demas mediante un ID de segmento que esta constituido por 24 bits lo cual en teoría nos puede permitir crear hasta 16 millones de segmentos de VXLAN unicos lo que equivale al mismo numero de redes lógicas.

Encapsulación

en el caso específico de VMware, la encapsulación de los paquetes de L2 en L3 sucede a través de un módulo de kernel en conjunto con una vmknic (puerto de vmkernel) que hacen las veces de VTEP (Virtual Tunnel End Point)  la ip que es asignada al puerto de vmkernel es la que estará usando el VTEP, esto se vería de la siguiente manera:

vtep

Este VTEP se encarga de manejar toda la encapsulación y desencapsulación del tráfico de VMs que sucede en dicho host el VTEP encapsula el tráfico con el siguiente formato:

VXLAN + UDP + IP

Enviando el paquete inicialmente en un multicast y en comunicaciones conocidas como unicast aquí podemos ver el formato:

vlxan encap

Aquí podemos ver la información que se maneja en el encapsulado, esta constituida por lo siguiente:

  • Outer MAC DA – Básicamente la MAC address del destination address o quien estará recibiendo este paquete, en este caso se trata del VTEP donde se recibirán los paquetes para ser desencapsulados y después enviados como comunicación L2 a la VM en cuestión. Se trata del host ESXi que contiene la VM destino en la comunicación.
  • Outer MAC SA – Aquí estamos hablando del Source Address o el VTEP encargado de crear todo este paquete. A partir de donde se generó el paquete. Se trata del host ESXi que contiene la VM origen en la comunicación.
  • Outer 802.1 q – básicamente la VLAN de transporte para el paquete
  • Outer IP DA – IP del VTEP destino, host ESXi ejecutando la VM receptora del paquete en cuestión
  • Outer IP SA – IP del VTEP origen , host ESXi ejecutando la VM que esta enviando el paquete.
  • Outer UDP – Contiene el puerto origen, destino e información de checksum. El puerto origen es generado a partir de un hash del header que contiene el paquete ethernet interno (la información que se pretende enviar).
  • VXLAN ID – se trata de 8 bytes que contienen toda la información del VNI (VXLAN Network Identifier).

Flujo de información

Si consideramos el siguiente escenario:

  • VM1 “Base de datos”
  • VM2 “Aplicación”
  • VXLAN ID 100
  • Multicast Group 239.119.1.1

Y se precisa entablar una comunicación entre la VM1  y la VM2 que estan siendo ejecutadas en distintos hosts ESXi en un segmento de 192.168.1.x/24 comenzando esta comunicación desde la VM1 sucedería lo siguiente:

  1. ambos VTEPs se anuncian en el multicas group 239.119.1.1 a través de IGMP.
  2. La VM 1 envia un ARP para descubrir la MAC address de la VM2 (en el caso que esta sea desconocida) este ARP (broadcast) es encapsulado en un multicast con la información pertinente del VTEP y VNI donde se esta generando la información y es enviado al multicast group al que pertenece la L2 de la VM origen.
  3. Todos los VTEPs receptores verificarán de primera instancia el ID de la L2, desencapsulando el paquete en el caso que se encuentre una VM perteneciente a dicha L2 para que la información sea recibida por la VM.
  4. La VM2 en este caso ya recibió el ARP y lo responde a través de un unicast y el VTEP de la VM destino (VM2) entabla una comunicación directa con el VTEP de la VM origen (VM1)

Gráficamente se vería de la siguiente manera:

vxlan-com

Es importante notar que en este ejercicio no se consideró las IPs de los VTEPs por temas de simplicidad, al igual es importante saber que el multicast inicial solo se da en el caso que la tabla de ruteo del VTEP no contenga la relación entre MAC address de la VM destino con la IP del VTEP destino, una vez que esta información es agregada a la tabla de ruteo la comunicación se realiza de punto a punto.

¿Que hay de comunicación inter- VXLAN?

Utilizemos la siguiente imagen para poder entender los distintos casos:

inter

  • Escenario 1 – Todos los participantes en la comunicación se encuentran en un solo host ESXi, VM1, VM2, VM3 y vShield Edge.

En este caso en específico estariamos teniendo una comunicación en un mismo host ESXi, la comunicación sería enviada al gateway que es nuestro vShield Edge quien se encargaría de rutear entre ambos segmentos.

  • Escenario 2 –  VM1,VM2 (azul) y vShield Edge se estan ejecutando en el mismo host ESXi y la VM3 en otro host ESXi

En este caso estariamos teniendo comunicación que viaja a través de la infraestructura física, aquí estarían participando los distintos VTEPs y vShield Edge para rutear entre los distintos segmentos. Puede darse el caso que se trate de comunicación entre la VM1 y VM2 lo cual mantendría esto dentro del mismo host ESXi.

  • Escenario 3 – Todas las VMs se ejecutan en distintos hosts ESXi incluyendo a vShield Edge

Este es el caso más dificil debido a que aquí la información tendría que estar saliendo siempre a través de la infraestructura física para ser ruteada por vShield edge y regresar a al destino. Esto puede tener implicaciones muy grandes en cuestiones de diseño, debido a que si esto sucede entre datacenters, es posible que la información este viajando entre datacenters dependiendo de donde se coloca vShield edge lo que nos puede llevar a tener tromboning en la red.

 

Tip de diseño – asignación de Limits y shares a nivel de VM en vCloud Director

Que tal gente un post corto, a nivel de vCloud Director podemos aplicar reservación de recursos, asignación y manejo de los mismos a nivel de org vDC, que se vería algo como lo siguiente:

Screen Shot 2012-12-20 at 1.46.29 PM

Allocation Pool

Screen Shot 2012-12-20 at 1.56.48 PM

Reservation Pool

Screen Shot 2012-12-20 at 1.57.05 PM

Pay-As-You-Go

Pero, ¿Que hay de limites, shares y manejo de recursos a nivel de vApps que se ejecutan dentro de dichos Org vDCs?, esto es algo que lo podemos aplicar facilmente haciendo click derecho sobre el vApp en cuestión, y editando cualquiera de sus máquinas:

Screen Shot 2012-12-20 at 2.15.02 PM