Architecting A VMware VCloud Director Solution

VMware vCloud Architecture Toolkit
for Service Providers

Arquitectura de soluciones de VMware vCloud
Director para proveedores de servicios
Versin 1.0
Octubre de 2015
VMware vCloud Architecture Toolkit for Service Providers

Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
2015 VMware, Inc. Todos los derechos reservados. Este producto est protegido por las leyes de
propiedad intelectual y de copyright internacionales y de los Estados Unidos. Este producto est cubierto
por una o varias de las patentes que se detallan en http://www.vmware.com/download/patents.html.
VMware es una marca registrada o una marca comercial de VMware, Inc. en los Estados Unidos y otras
jurisdicciones. Todos los dems nombres y marcas mencionados aqu podran ser marcas comerciales
de sus respectivas compaas.
VMware, Inc.
3401 Hillview Ave
Palo Alto, CA 94304
www.vmware.com
2015 VMware, Inc. Todos los derechos reservados.

Pgina 2 de 78

Contenido
1.
Introduccin....................................................................................... 7
2.
Descripcin de la tecnologa ............................................................. 8

2.1 Glosario de trminos ...................................................................................................... 9
3.
Consideraciones sobre el modelo de implementacin .................... 12

3.1 Ofertas de servicios ..................................................................................................... 12
4.
Descripcin general de la arquitectura ............................................ 17
5.
Componentes de administracin de la nube ................................... 18

5.1 vCenter Server de administracin................................................................................ 18
5.2 vCloud Director ............................................................................................................ 18
5.3 Base de datos de mtricas de las mquinas virtuales................................................. 20
5.4 Pivotal RabbitMQ ......................................................................................................... 24
5.5 Chargeback Manager .................................................................................................. 27
5.6 vRealize Orchestrator .................................................................................................. 28
5.7 vRealize Operations Manager ..................................................................................... 29
5.8 vCloud Usage Meter .................................................................................................... 30
6.
Grupos de recursos......................................................................... 31
6.1 Componentes de administracin de grupos de recursos ............................................ 31
6.2 Recurso informtico ..................................................................................................... 31
6.3 Redes ........................................................................................................................... 32
6.4 Almacenamiento .......................................................................................................... 44
7.
Diseo del proveedor de vCloud ..................................................... 47

7.1 Centros de datos virtuales de proveedor ..................................................................... 48
7.2 Organizaciones ............................................................................................................ 49
7.3 Centros de datos virtuales de la organizacin ............................................................. 53
7.4 Redes ........................................................................................................................... 56
7.5 Almacenamiento .......................................................................................................... 60
7.6 Catlogos ..................................................................................................................... 61
7.7 vApps ........................................................................................................................... 62
8.
Escalabilidad ................................................................................... 64
8.1 Grupo de recursos ....................................................................................................... 64
8.2 Clster de administracin ............................................................................................ 65
8.3 Federacin de vCloud Director .................................................................................... 66
Pgina 3 de 78

9.
Capacidad de recuperacin ............................................................ 67

9.1 Descripcin general ..................................................................................................... 67
9.2 Clster de administracin ............................................................................................ 67
9.3 Cargas de trabajo de tenants....................................................................................... 68
10.
Seguridad.................................................................................... 69
10.1 Instrucciones ................................................................................................................ 69
10.2 Registro de auditora .................................................................................................... 71
11.
Consideraciones operativas ........................................................ 75

11.1 Supervisin de vCloud Director ................................................................................... 75
11.2 Revisiones de VMware vCloud Director ...................................................................... 77

Pgina 4 de 78

Lista de figuras
Figura 1. Zona de disponibilidad individual ................................................................................................. 12
Figura 2. Grupos de recursos distribuidos .................................................................................................. 13
Figura 3. Grupo de recursos ampliado ....................................................................................................... 14
Figura 4. Regiones ...................................................................................................................................... 15
Figura 5. DR con replicacin de almacenamiento ...................................................................................... 15
Figura 6. Componentes del clster de administracin................................................................................ 17
Figura 7. Diseo de la base de datos de mtricas de las mquinas virtuales............................................ 21
Figura 8. Extensiones de vCloud Director .................................................................................................. 24
Figura 9. Arquitectura de los mensajes AMQP ........................................................................................... 25
Figura 10. Ejemplo de RabbitMQ multiregional .......................................................................................... 26
Figura 11. Ejemplo de diseo de RabbitMQ ............................................................................................... 26
Figura 12. Flujo de trabajo de vCloud Usage Meter ................................................................................... 30
Figura 13. Arquitectura tradicional de acceso/adicin/ncleo .................................................................... 34
Figura 14. Leaf-spine con clster Edge/informtico ................................................................................... 35
Figura 15. Leaf-spine con clster Edge/informtico y VDC no elstico ...................................................... 36
Figura 16. Leaf-spine con clster Edge dedicado ...................................................................................... 37
Figura 17. Leaf-spine con clster Edge dedicado y Edge ECMP ............................................................... 38
Figura 18. Clster de NSX Controller universal .......................................................................................... 42
Figura 19. Servicios compartidos con firewall distribuido y DLR ................................................................ 43
Figura 20. NSX Edge de tenants ................................................................................................................ 44
Figura 21. Relaciones fsicas, virtuales y de abstraccin de nube ............................................................. 47
Figura 22. Clster de Edge compartido para instancias de VDC de organizacin de reserva .................. 55
Figura 23. Red de servicio .......................................................................................................................... 59

Pgina 5 de 78

Lista de tablas
Tabla 1. Glosario ........................................................................................................................................... 9
Tabla 2. Propiedades avanzadas de las celdas de vCloud Director .......................................................... 19
Tabla 3. Mtricas de consumo de recursos y rendimiento de mquinas virtuales ..................................... 20
Tabla 4. Instrucciones de configuracin de Cassandra .............................................................................. 23
Tabla 5. Mtricas de vCenter Chargeback ................................................................................................. 27
Tabla 6. Resumen de las opciones de implementacin de clsteres Edge ............................................... 40
Tabla 7. Requisitos de caractersticas del clster de NSX Controller ........................................................ 41
Tabla 8. Definiciones de centros de datos virtuales ................................................................................... 47
Tabla 9. Notificaciones de token de OAuth................................................................................................. 51
Tabla 10. Tamaos de puertas de enlace Edge ......................................................................................... 58
Tabla 11. Rendimiento de puertas de enlace Edge .................................................................................... 58
Tabla 12. Copia de seguridad de componentes de administracin ............................................................ 67
Tabla 13. Direcciones URL de portal web permitidas por el firewall de aplicacin web ............................ 70
Tabla 14. Registros de celdas de vCloud Director ..................................................................................... 71
Tabla 15. Registros de vCenter Chargeback Manager .............................................................................. 73
Tabla 16. Registros de puertas de enlace Edge ......................................................................................... 74
Tabla 17. Formato de registro de puerta de enlace Edge .......................................................................... 74
Tabla 18. Supervisin de celdas de vCloud Director .................................................................................. 75
Tabla 19. Supervisin de vCenter Chargeback .......................................................................................... 76
Tabla 20. Registros de vCloud Director ...................................................................................................... 76

Pgina 6 de 78

1.
Introduccin
Los proveedores de servicios de VMware vCloud Air Network con el distintivo VMware Hybrid Cloud
Powered Services ofrecen a sus clientes empresariales una verdadera experiencia de nube hbrida:
compatibilidad completa con las aplicaciones virtuales existentes que se ejecutan en un entorno VMware
vSphere interno mediante el uso del mismo conjunto de herramientas para administrar sus centros de
datos virtuales internos y en la nube.
El proveedor de servicios debe estar validado por VMware para comprobar que su nube pblica cumpla
con los siguientes requisitos hbridos:
Servicio de nube basado en vSphere y VMware vCloud Director
API de usuario de VMware vCloud expuesta a tenants de nube
Nube compatible con el formato de virtualizacin abierto (Open Virtualization Format, OVF) para
movimiento bidireccional de cargas de trabajo
Este documento incluye instrucciones sobre cmo disear vSphere, vCloud Director y otras tecnologas
complementarias para que todos los proveedores de servicios puedan obtener el distintivo VMware
Hybrid Cloud Powered Service.

Pgina 7 de 78

2.
Descripcin de la tecnologa
Para disear una nube hbrida, es necesario utilizar un conjunto de tecnologas prescritivas con el fin de
asegurar la compatibilidad requerida y la movilidad de las cargas de trabajo con un acceso de API
estandarizado.
vSphere, junto con VMware NSX, es la base de la plataforma de virtualizacin informtica y de redes
subyacente, en la que se puede utilizar cualquier recurso fsico compatible (servidores, almacenamiento,
conmutadores de red y enrutadores).
vCloud Director se utiliza para el plano de administracin de la nube. Admite, agrupa y abstrae de
manera nativa la plataforma de virtualizacin en trminos de centros de datos virtuales. Ofrece
caractersticas multitenant y acceso de autoservicio para tenants a travs de una interfaz grfica de
usuario nativa o a travs de la API de vCloud, lo que permite un acceso programable para los tenants
(para consumo) y para el proveedor (administracin de la nube). Adems, la API de vCloud ofrece un
marco para servicios de extensin, mediante el cual los proveedores de servicios pueden agregar
servicios adicionales a objetos de API nuevos o existentes. La API de vCloud permite que los
proveedores de servicios se diferencien de los dems y brinda la posibilidad de disear una interfaz de
usuario propia o utilizar la de un tercero. El lado de usuario de una API de vCloud que se expone a los
tenants permite la utilizacin de las mismas herramientas de VMware o de terceros para la
administracin.
VMware vCloud Usage Meter recopila datos de consumo de distintos componentes de software de
VMware para ofrecer una concesin de licencias de paquetes VMware Service Provider Program (VSPP)
segn el uso.
De manera opcional, se pueden utilizar componentes adicionales de VMware para la integracin de
sistemas de soporte operativos y empresariales:
VMware vCloud Connector para simplificar migraciones de mquinas virtuales, plantillas e imgenes
ISO hacia y desde la nube pblica para clientes y proveedores (administracin de catlogo pblico).
VMware vCenter Chargeback para mediciones e informes de uso. La API de vCenter

Chargeback se integra con los sistemas de facturacin existentes.
VMware vRealize Operations Manager para supervisin y anlisis de rendimiento y capacidad.
VMware vRealize Hyperic para servicios de supervisin de componentes de administracin.
VMware vRealize registro Insight para administracin y anlisis centralizado de registros.
VMware vRealize Orchestrator para servicios de extensin o tareas de automatizacin recurrentes

(incorporacin y ciclo de vida de tenants).
VMware Site Recover Manager para proteccin de recuperacin ante desastres de componentes
de administracin de la nube.
De manera opcional, VMware Virtual SAN puede extender los servicios de virtualizacin de
plataformas como una alternativa convergente de hipervisor con capacidad de escalado horizontal a los
sistemas de almacenamiento SAN o NAS tradicionales.

Pgina 8 de 78

2.1
Glosario de trminos
Tabla 1. Glosario
Trmino
Definicin
Grupo de asignacin
Grupo de recursos asignados para los cuales se garantiza un

cierto porcentaje de recursos informticos.
Zona de disponibilidad
Un solo dominio de errores para recursos.
Catlogo
Repositorio de plantillas y elementos multimedia de vApp

disponibles para la implementacin por parte de los usuarios.
Los catlogos pueden publicarse y compartirse entre
organizaciones en el mismo entorno de vCloud.
Nube dedicada
Recursos de nube dedicados a un tenant en una infraestructura

fsica dedicada.
Puerta de enlace Edge
Dispositivos virtuales para brindar seguridad en el permetro de

la red. Las puertas de enlace Edge conectan las redes aisladas
y privadas de tenants de la nube con el lado pblico de la red
del proveedor a travs de servicios como enrutamiento, firewall,
NAT, rel de DNS, DHCP, VPN IPsec de sitio a sitio y equilibrio
de carga.
Redes externas
Las redes externas ofrecen conectividad de Internet a redes de

organizaciones y se encuentran respaldadas por grupos de
puertos configurados para accesibilidad a Internet.
Clster de administracin
Recursos virtuales y fsicos dedicados a funciones de

administracin.
Grupos de redes
Recopilaciones de redes virtuales de Capa 2 aisladas a las que

vCloud Director puede acceder para la implementacin
automatizada de redes de organizaciones y vApp.
Nube a peticin
Recursos de nube confirmados para el tenant que se facturan

solamente cuando se usan.
Organizacin
Unidad multitenant que representa un solo lmite de seguridad

lgico. Una organizacin contiene usuarios, centros de datos
virtuales y catlogos.
Administrador de
organizacin
El administrador de una organizacin de vCloud Director,

responsable de administrar los recursos suministrados, los
servicios de red, los usuarios y las directivas de vApp.
Redes de VDC de
organizacin
Las instancias de redes de VDC de organizacin se crean a

travs de grupos de redes y se enlazan al VDC de una sola
organizacin o se comparten entre organizaciones. Las redes
de VDC de organizacin pueden estar aisladas, enrutarse o
conectarse directamente con una red externa.
Pgina 9 de 78

Trmino
Definicin
Centro de datos virtual de

organizacin
Subgrupo de recursos informticos, de red y de

almacenamiento asignados a una sola organizacin desde el
centro de datos virtual de un proveedor. Un centro de datos
virtual es un entorno de implementacin donde se pueden crear
instancias de vApp, implementar vApps y encender vApps. Los
centros de datos virtuales de organizacin no pueden
expandirse a varias organizaciones.
Pago por uso
Se genera la ilusin de un grupo de recursos ilimitado. Los

recursos solo se confirman cuando se crean vApps en el centro
de datos virtual de la organizacin.
Centro de datos virtual de

proveedor
Agrupamiento de recursos informticos y de almacenamiento

de un solo VMware vCenter Server. Un centro de datos
virtual de proveedor consiste en uno o varios grupos de
recursos y uno o varios almacenes de datos. Los recursos de
centro de datos virtuales de proveedor pueden compartirse con
varias organizaciones.
Grupo de reserva
Los recursos informticos asignados al centro de datos virtual

de organizacin son completamente reservados y dedicados.
Grupo de recursos
Recursos informticos, almacenamiento y redes para cargas de

trabajo de tenants administrados por un vCenter Server.
vApp
Contenedor para la solucin de software en la nube. Una vApp

es la unidad estndar de implementacin para vCloud Director.
Contiene una o varias mquinas virtuales, redes y servicios de
red, incluye operaciones de encendido y puede importarse o
exportarse.
vAppEdge
Instancia de enrutador virtual que se crea dentro de una vApp

para ofrecer servicios de enrutamiento, NAT, firewall y DHCP
en redes de vApp.
Red de vApp
Red que conecta mquinas virtuales dentro de una vApp

implementada por un consumidor desde un grupo de redes.
vCenter Chargeback
Solucin de medicin y clculo de costos con la que se puede

medir, configurar, analizar y realizar informes de costos de
manera precisa para entornos virtualizados. vCenter
Chargeback permite asignar costos de TI a unidades
empresariales o clientes externos.
API de vCloud
API de RESTful abierta para ofrecer y consumir recursos

virtuales desde la nube. Permite implementar y administrar
cargas de trabajo virtualizadas en nubes internas y externas.

Pgina 10 de 78

Trmino
Definicin
vCloud Director
Solucin de software que ofrece un conjunto de caractersticas

de administracin, automatizacin e interfaz para permitir que
los proveedores de servicios suministren recursos de vSphere
como un servicio basado en la Web.
Celda de vCloud Director
Celda de tiempo de ejecucin de servicios de vCloud Director

en una mquina fsica o virtual. Es posible agrupar varias
celdas dentro de una instancia de vCloud Director mediante la
conexin de una base de datos de vCloud Director para
equilibrio de carga y alta disponibilidad.
Nube privada virtual
Recursos de nube dedicados a un tenant dentro de una

infraestructura compartida.

Pgina 11 de 78

3.
Consideraciones sobre el modelo de implementacin
3.1
Ofertas de servicios
El modelo de implementacin actual depende de la oferta de cada proveedor de servicios. En esta

seccin, se analizan las opciones de configuracin ms comunes y sus consideraciones de
implementacin.
Nota
Es posible combinar ofertas de servicios.
3.1.1 Zona de disponibilidad individual de IaaS

La infraestructura como servicio (Infrastructure as a Service, IaaS) se define como un servicio con el que
se ofrecen recursos informticos, de almacenamiento y de red a usuarios finales como bloques de
creacin para implementar sistemas operativos y aplicaciones (cargas de trabajo).
Por lo general, la zona de disponibilidad se define como una ubicacin (centro de datos) que, si bien
ofrece un acuerdo de nivel de servicio de disponibilidad (por ejemplo, un tiempo de actividad de 99,9%)
para las cargas de trabajo de cliente, es un solo dominio de errores. Una interrupcin de gran magnitud
en una ubicacin provocar una alteracin total de los servicios que se ejecutan all.
En la siguiente figura se representa un modelo de implementacin tpico de la oferta de zona de
disponibilidad individual de IaaS.
Figura 1. Zona de disponibilidad individual

Pgina 12 de 78

Un solo clster de administracin ejecuta componentes de administracin de la nube (vCloud Director),
adems de componentes de administracin de grupos de recursos (instancias de vCenter Server y
sistemas complementarios). Cada grupo de recursos se representa con un entorno de vSphere
compuesto por varios clsteres administrados mediante un solo vCenter Server. Es posible disponer de
ms de un grupo de recursos para escalar ms all de los lmites de un vCenter Server, pero todos los
grupos se deben ubicar dentro de la misma zona de disponibilidad.
3.1.2 Zonas de disponibilidad mltiples de IaaS

Con el concepto de zona de disponibilidad mltiple, los usuarios finales pueden implementar sus
aplicaciones en un modelo distribuido. De esa manera, cuando se producen errores en una zona de
disponibilidad, la aplicacin puede continuar en ejecucin. El usuario final es responsable de mantener el
estado de la aplicacin entre las zonas. El proveedor debe disponer de dos sitios (centros de datos) a
una distancia suficiente como para anular la correlacin de su probabilidad de error y a una cercana
suficiente como para mantenerlos bajo la misma administracin de nube. Adems, el proveedor debe
garantizar la recuperacin ante desastres de los componentes de administracin de la nube.
Existen dos opciones para disear zonas de disponibilidad mltiples. Esas opciones difieren en la forma
de implementar los componentes de administracin del grupo de recursos. Se trata de las
configuraciones distribuidas o ampliadas.
3.1.2.1. Grupos de recursos distribuidos
Con un grupo de recursos distribuido, cada conjunto de grupos de recursos es una zona de
disponibilidad junto con sus componentes de administracin, como se muestra en la siguiente figura.
Figura 2. Grupos de recursos distribuidos
Los componentes de administracin de la nube se ubican en un sitio principal. Si se produce un desastre

o una interrupcin, los componentes de administracin pueden conmutarse por error al sitio secundario
para reducir el tiempo de inactividad. Los grupos de recursos y sus componentes de administracin se
aslan por zona de disponibilidad sin conmutacin por error. El tiempo de inactividad en una zona de
disponibilidad significa una inactividad completa para el grupo de recursos, pero no para los
componentes de administracin de la nube.

Pgina 13 de 78

Ventajas de este diseo:
Se ofrece acceso a los componentes de administracin de la nube incluso si se producen errores.
Con un diseo apropiado de aplicaciones, el tenant puede evitar el tiempo de inactividad en las
aplicaciones.
El proveedor de servicios puede ofrecer un servicio de recuperacin ante desastres.
3.1.2.2. Grupo de recursos ampliado

Este diseo, que se utiliza con menos frecuencia, ampla un grupo de recursos en las dos zonas de
disponibilidad, con algunos clsteres en el primer sitio y otros en el segundo. La administracin de
grupos de recursos se ubica en el sitio principal con conmutacin por error al grupo secundario.
La ventaja principal de este diseo consiste en que es posible ampliar redes de organizacin a los dos
sitios y lograr una adyacencia de Capa 2 para equilibrios de carga de cliente. Las desventajas son la falta
de estabilidad, la necesidad de la recuperacin ante desastres de los componentes de administracin en
el grupo de recursos y la posibilidad de alteracin lgica de los componentes de administracin, por lo
que se puede producir tiempo de inactividad en las dos zonas de disponibilidad.
Figura 3. Grupo de recursos ampliado
Nota
Ninguno de estos diseos multisitio requiere un almacenamiento ampliado (solucin de clsteres

metro de almacenamiento). Sin embargo, se puede utilizar el almacenamiento ampliado para la
recuperacin ante desastres en la capa de administracin. En este caso, la distancia entre sitios
se ve limitada por la latencia de ida y vuelta admitida en la red de almacenamiento (por lo
general, de 5 a 10 milisegundos).
vCloud Director y sus componentes admiten una latencia de red de ida y vuelta mxima de 20
milisegundos entre sitios (aproximadamente 1600 km).

Pgina 14 de 78

3.1.3 Regiones mltiples de IaaS

Las regiones son instancias de nube completamente aisladas y separadas por grandes distancias. Los
tenants pueden colocar sus cargas de trabajo ms cerca de los usuarios finales y protegerlos ante un
desastre que afecte a toda la regin. La gran distancia implica que las aplicaciones de los tenants deben
mantener su estado de manera asncrona.
vCloud Director no ofrece compatibilidad nativa para varias instancias (federacin). Por ese motivo, el
proveedor debe utilizar su propio portal o el de un tercero adems de vCloud Director.
Figura 4. Regiones
3.1.4 IaaS con acuerdo de nivel de servicio para Disaster Recovery

Ninguna de las opciones de implementacin anteriores garantiza acuerdos de nivel de servicio de
recuperacin ante desastres para las cargas de trabajo de los tenants. Es responsabilidad de cada
tenant garantizar la disponibilidad de las aplicaciones por medio de una replicacin en el nivel de la
aplicacin. Sin embargo, las aplicaciones heredadas no admiten la replicacin de estado en el nivel de la
aplicacin y es necesario utilizar la replicacin que ofrece la infraestructura.
En este caso, el proveedor puede aprovechar la replicacin de almacenamiento. Si se pierde una zona
de disponibilidad, el proveedor puede restaurar y activar todas las cargas de trabajo en otra.
Figura 5. DR con replicacin de almacenamiento

Pgina 15 de 78

Hay dos opciones para disear la recuperacin ante desastres con replicacin de almacenamiento:
Replicacin de almacenamiento genrica sncrona o asncrona con conmutacin por error manual o
generada por script al otro sitio. Para obtener ms detalles, consulte Caso de estudio de resistencia
de infraestructura de VMware vCloud Director (VMware vCloud Director Infrastructure Resiliency
Case), en http://www.vmware.com/files/pdf/techpaper/VMware-vCloud-Directore-Infrastructureresiliency-whitepaper.pdf.
Solucin de almacenamiento que admite vSphere MetroStorage Cluster con conmutacin por error
automatizada proporcionada por vSphere HA. Para obtener ms detalles, consulte Caso de estudio
de VMware vSphere Metro Storage Cluster (VMware vSphere Metro Storage Cluster Case Study), en
http://www.vmware.com/files/pdf/techpaper/vSPHR-CS-MTRO-STOR-CLSTR-USLET-102-HIRES.pdf.
3.1.5 Modelos de consumo

Los proveedores de servicio pueden adaptar su oferta de nube pblica segn el consumo deseado del
cliente. Los siguientes modelos estn disponibles:
Nube a peticin
Nube privada virtual
Nube dedicada
3.1.5.1. Nube a peticin

El cliente no se suscribe por adelantado a los recursos de la nube y paga solo segn el consumo. Por lo
general, esto es beneficioso para cargas de trabajo por rfaga o por temporada, que aumentan o
disminuyen segn el momento. El cliente consume los recursos desde un grupo aparentemente infinito
que el proveedor debe mantener. La prediccin de este tipo de demanda puede ser difcil para el
proveedor. Por ese motivo, lo compensa con un exceso de suscripciones de esos recursos o
encarecindolos.
Esta oferta se relaciona directamente con el modelo de asignacin de pago por uso del centro de datos
virtual de la organizacin (Organization Virtual Data Center, Org VDC).
3.1.5.2. Nube privada virtual
El cliente compra un fragmento de recursos en trminos de nube privada virtual (Virtual Private Cloud,
VPC), que consiste en recursos informticos (CPU y memoria), almacenamiento y redes. Dentro de la
VPC, implementa cargas de trabajo hasta alcanzar la capacidad total de recursos comprados. Este
modelo de consumo es beneficioso para cargas de trabajo estables, ya que el cliente conoce sus
necesidades y puede comprometerse a comprar los recursos durante un perodo mnimo (por lo general,
al menos un mes).
El proveedor administra el exceso de suscripcin de recursos; el cliente no tiene ningn control sobre
esto. El tamao de la VPC puede ser arbitrario, desde apenas una porcin de un host hasta varios
clsteres de vSphere, gracias a la posibilidad de compartir la infraestructura fsica y virtual de vSphere
subyacente entre diferentes tenants.
Esta oferta se relaciona directamente con el modelo de asignacin Tipo de asignacin de Org VDC.
3.1.5.3. Nube dedicada
En casos donde el cliente no ejecuta cargas de trabajo en la misma infraestructura fsica que otros
tenants, o debido a motivos de concesin de licencias, pueden adquirir una nube dedicada. Varios hosts
fsicos (desde un clster de vSphere) estn dedicados para el tenant, que tiene el control total sobre el
exceso de suscripcin de las cargas de trabajo que se implementan en su nube dedicada.
Esta oferta se relaciona directamente con el modelo de asignacin Tipo de reserva de Org VDC.
Pgina 16 de 78

4.
Descripcin general de la arquitectura
La arquitectura de la nube pblica tpica consiste en componentes de administracin que se implementan

en el clster de administracin, y en grupos de recursos para alojar las cargas de trabajo del tenant.
Algunos de los motivos de la separacin son los siguientes:
Diferentes acuerdos de nivel de servicio (disponibilidad, capacidad de recuperacin, rendimiento)

para componentes de administracin y para cargas de trabajo del tenant
Separacin de tareas (vCloud Director se encarga de administrar los grupos de recursos)
Administracin y escala coherentes de los grupos de recursos
El clster de administracin ejecuta los componentes de administracin de la nube y los componentes de

administracin del grupo de recursos.
Figura 6. Componentes del clster de administracin
Los grupos de recursos son dominios de infraestructura independiente representados por recursos
informticos, de redes y de almacenamiento virtualizados, cada uno de ellos administrado por su propio
vCenter Server.

Pgina 17 de 78

5.
Componentes de administracin de la nube
5.1
vCenter Server de administracin
A excepcin de los entornos pequeos, VMware recomienda que el clster de administracin sea
administrado por su propio vCenter Server. Esto permite una proteccin de recuperacin ante desastres
con Site Recovery Manager y mejora ms la separacin de grupos de recursos. El uso de
almacenamiento dedicado (por ejemplo, VMware Virtual SAN) significa que los grupos de recursos no
afectan el rendimiento de almacenamiento de los componentes de administracin.
5.2
vCloud Director
5.2.1 Celdas de vCloud Director

La funcionalidad de vCloud Director est dada por celdas sin estado, mquinas Linux (Red Hat
Enterprise Linux o CentOS) con los binarios de vCloud Director. Cada celda contiene un conjunto de
servicios, como el servicio de transferencia, el proxy de consola, el agente de escucha vCenter y otros.
Cada celda requiere al menos dos direcciones IP: una principal para la interfaz de usuario o API de
vCloud Director y otra secundaria para el proxy de consola remota de VMware. Esto se debe a que
ambos utilizan el puerto TCP 443. Las celdas se comunican entre s a travs del bus de mensajes
ActiveMQ en la interfaz principal. Adems, comparten una base de datos comn de vCloud Director,
donde las celdas conservan los datos de configuracin y estado. El servicio de transferencia requiere
que todas las celdas tengan acceso a una carpeta compartida comn, por lo general un montaje de NFS.
Las siguientes son consideraciones de diseo de celdas de vCloud Director:
Implemente al menos N+1 celdas, donde N es la cantidad de grupos de recursos, o bien n/3000+1,
donde n es la cantidad esperada de mquinas virtuales encendidas (utilice la mayor de las dos
opciones).
Para evitar una situacin de cerebro dividido, compruebe que las celdas se comuniquen entre s a
travs del bus de mensajes en la interfaz de red principal.
vCloud Director inicia el proxy (agente de escucha) de vCenter Server para cada uno de las
instancias de vCenter Server conectadas. Distribuya el proxy de vCenter Server entre las celdas de
forma tal que ninguna ejecute ms de un proxy. Para realizar esta tarea manualmente, debe
dispararse la reconexin de vCenter Server. En la instancia de vCenter Server reconectada, se inicia
un nuevo proxy de vCenter Server en la celda de vCloud Director menos utilizada.
Utilice el mismo certificado consoleproxy en todas las celdas.
Se puede dirigir el trfico de equilibrio de carga a una celda especfica. Sin embargo, las celdas no
se basan en el sitio, y las tareas se distribuyen al azar entre ellas. VMware recomienda mantener las
celdas en un sitio con su base de datos y recurso compartido de transferencia, y recuperarlas de
forma conjunta en caso de una recuperacin ante desastres.
Utilice un firewall de aplicaciones web para finalizar el trfico HTTPS de vCloud en el equilibrador de
carga y para aplicar reglas de firewall de Capa 7. Puede filtrarse segn la URL, la direccin IP de
origen o el encabezado de autenticacin para proteger el acceso a ciertas organizaciones o llamadas
de API (mbito del proveedor). El trfico entre el equilibrador de carga y las celdas tambin debe
estar cifrado con HTTPS.
Habilite la insercin de encabezados HTTP X-Forwarded-For en el equilibrador de carga para
rastrear la direccin IP de origen de las solicitudes en los registros de vCloud Director.
El trfico del proxy de la consola remota de VMware no puede finalizarse en el equilibrador de carga
y debe pasar por las celdas, ya que se trata de una conexin de socket SSL propia.
Pgina 18 de 78

Se recomienda utilizar sesiones adhesivas en el equilibrador de carga (por motivos de rendimiento),

aunque no son obligatorias, ya que el estado de sesin se guarda en la memoria cach en el nivel de
la celda, y tambin se almacena en la base de datos de vCloud.
Utilice un algoritmo de equilibrio de carga por turnos o segn la menor cantidad de conexiones para
compartir la carga.
Realice las siguientes comprobaciones de estado en el equilibrador de carga para el grupo de celdas:
http://<cell_HTTP_IP>/api/server_status (la respuesta esperada es Service is up [El servicio est en
funcionamiento]).
https://<cell_consoleproxy_IP>/sdk/vimServiceVersions.xml o una comprobacin simple del puerto
TCP 443.
Despus de instalar la primera celda de vCloud Director, realice una copia de seguridad de los
certificados y del archivo $VCLOUD_HOME/etc/responses.properties, que contenga toda la
informacin necesaria para implementar celdas nuevas o adicionales (por ejemplo, la contrasea de
la base de datos).
Compruebe que todas las celdas puedan acceder al recurso compartido de transferencia de celdas y
que el usuario Linux de vCloud tenga permisos de escritura. El recurso compartido de transferencia
debe tener el tamao suficiente para almacenar todas las importaciones/exportaciones o migraciones
de OVF o ISO simultneas entre grupos de recursos (por ejemplo, 10 transferencias de 50 GB
simultneas necesitan un mximo de 500 GB de capacidad de recursos compartidos de
transferencia).
Para redirigir los registros de vCloud Director a un syslog externo, edite el archivo
$VCLOUD_HOME/etc/log4j.properties.
Para entornos de gran tamao, aumente el tamao de pila de JVM, el grupo de conexiones de la
base de datos y la conexin Jetty en $VCLOUD_HOME/bin/vmware-vcd-cell. Consulte la tabla a
continuacin.
Tabla 2. Propiedades avanzadas de las celdas de vCloud Director

Nombre de la opcin
avanzada
Ubicacin
Valor
predeterminado
Valor
recomendado para
entornos de gran
tamao
Tamao de pila de JVM
$VCLOUD_HOME/bin/vmware
-vcd-cell
JAVA_OPTS:-Xms1536M Xmx2048M XX:MaxPermSize=

768m
JAVA_OPTS:-Xms1536M Xmx3072M XX:MaxPermSize=

768m
Database.pool.maxActive
$VCLOUD_HOME/etc/global
.properties
75
200
vcloud.http.maxThreads
.properties
128
200
vcloud.http.minThreads
.properties
25
32
vcloud.http.acceptorThreads
.properties
16

Pgina 19 de 78

5.2.2 Base de datos de vCloud Director

Las siguientes son consideraciones de diseo de la base de datos de vCloud Director:
A partir de vCloud Director 5.6, se admiten servidores de bases de datos Microsoft SQL y Oracle con
las siguientes opciones de alta disponibilidad. Consulte el artculo de la base de conocimientos de
VMware: Opciones de alta disponibilidad admitidas para la base de datos de vCloud Director
(Supported high availability options for the vCloud Director database) (2037802)
(http://kb.vmware.com/kb/2037802).
Oracle RAC
Clster de conmutacin por error de Microsoft SQL
Nota
No se admiten los grupos de disponibilidad AlwaysOn de Microsoft SQL, y VMware

recomienda utilizar el proceso RPQ para que VMware pueda validar el diseo caso por
caso.
Siga las prcticas recomendadas de configuracin de base de datos de vCloud Director segn lo
especificado en el artculo de la base de conocimientos de VMware: Instalacin y configuracin de
una base de datos de vCloud Director 5.1 o 5.5 (Installing and configuring a vCloud Director 5.1 or
5.5 database) (2034540) (http://kb.vmware.com/kb/2034540).
Coloque la base de datos de vCloud Director con celdas de vCloud Director en el mismo sitio para
minimizar la latencia de red.
5.3
Base de datos de mtricas de las mquinas virtuales
A partir de vCloud Director 5.6, se recopilan mtricas de consumo de recursos y rendimiento de

mquinas virtuales, y se ofrecen datos histricos hasta un mximo de dos semanas de antigedad.
Tabla 3. Mtricas de consumo de recursos y rendimiento de mquinas virtuales
Nombre de la mtrica
Tipo
Unidad
Descripcin
cpu.usage.average
Velocidad
Porcentaje
Vista del host de la utilizacin activa promedio de

la CPU como porcentaje del total disponible
cpu.usagemhz.average
Velocidad
Megahercio
Vista del host de la utilizacin activa promedio de

la CPU como medicin sin procesar
cpu.usage.maximum
Velocidad
Porcentaje
Vista del host de la utilizacin activa mxima de la

CPU como porcentaje del total disponible
mem.usage.average
Absoluto
Porcentaje
Uso como porcentaje de la memoria total

configurada o disponible
disk.provisioned.latest
Absoluto
Kilobytes
Espacio de almacenamiento potencialmente

utilizado
disk.used.latest
Absoluto
Kilobytes
Espacio de almacenamiento realmente utilizado
disk.read.average
Velocidad
Kilobytes por
segundo
Velocidad de lectura agregada de todos los

almacenes de datos
disk.write.average
Velocidad
Kilobytes por
segundo
Velocidad de escritura agregada de todos los

almacenes de datos

Pgina 20 de 78

A travs de la API de vCloud, se pueden recuperar mtricas actuales e histricas. Las mtricas actuales
se recuperan directamente de la base de datos de vCenter Server, con la API de PerformanceManager.
Las mtricas histricas se recuperan cada 5 minutos, con una granularidad de 20 segundos, a travs del
proceso StatsFeeder que se ejecuta en las celdas y se aplica al almacenamiento persistente (clster de
la base de datos de Cassandra NoSQL con el esquema y la API de la base de datos KairosDB).
La siguiente figura ilustra el diseo recomendado de la base de datos de mtricas de las mquinas
virtuales. Se implementan varios nodos Cassandra en la misma red. Se ejecuta una base de datos
KairosDB en cada nodo, lo que adems ofrece un endpoint de API para que las celdas de vCloud
almacenen y recuperen datos. Para lograr una alta disponibilidad, debe equilibrarse la carga de todas las
instancias de KairosDB en una sola direccin IP virtual que se configura a travs de la herramienta de
administracin de la celda como el endpoint de mtricas de la mquina virtual.
Figura 7. Diseo de la base de datos de mtricas de las mquinas virtuales
Las siguientes son consideraciones de diseo de la base de datos de mtricas de las mquinas virtuales:
En la actualidad, solo se admiten KairosDB 0.9.1 y Cassandra 1.2.x/2.0.x.
El tamao de clster mnimo es de tres nodos (la cantidad de nodos debe ser mayor o igual al factor
de replicacin). Utilice un enfoque de escalado horizontal, no de escalado vertical, ya que el
rendimiento de Cassandra escala de manera lineal segn la cantidad de nodos.
Calcule los requisitos de E/S de acuerdo con la cantidad de mquinas virtuales esperada, y configure
adecuadamente el tamao del clster de Cassandra y su almacenamiento.
n: cantidad de mquinas virtuales esperada
m: cantidad de mtricas por mquina virtual (actualmente 8)
t: retencin (das)
r: factor de replicacin
E/S de escritura por segundo = n m r / 10
Almacenamiento = n m t r 114 kB
Para 30.000 mquinas virtuales, la cantidad estimada de E/S es de 72.000 IOPS de escritura y
3.288 GB de almacenamiento (en el peor de los casos, si la retencin de datos es de 6 semanas
y el factor de replicacin es 3).
Habilite la estrategia de compactacin nivelada (Leveled Compaction Strategy, LCS) en el clster de

Cassandra para mejorar el rendimiento de escritura.
Instale JNA (Java Native Access) versin 3.2.7 o posteriores en cada nodo, ya que puede mejorar el
uso de memoria de Cassandra (sin intercambio de JVM).
Pgina 21 de 78

En casos de uso intensivo de lectura (muchos tenants que recopilan estadsticas de rendimiento) y
disponibilidad, VMware recomienda aumentar el factor de replicacin a 3.
Tamao recomendado de un nodo de Cassandra: 8 vCPU (una mayor cantidad de CPU mejora el
rendimiento de escritura), 16 GB de RAM (una mayor cantidad de memoria mejora el rendimiento de
lectura) y 2 TB de almacenamiento (cada uno de ellos respaldado por LUN/discos individuales con
un alto rendimiento de IOPS).
KairosDB no aplica la directiva de retencin de datos. Por lo tanto, los datos de mtricas antiguos
deben borrarse peridicamente con un script.
En el siguiente ejemplo, se borran los datos de un mes:

#!/bin/sh
if [ "$#" -ne 4 ]; then
echo "$0 <kairosdbvip> port month year"
exit
fi
let DAYS=$(( ( $(date -ud 'now' +'%s') - $(date -ud "${4}-${3}-01 00:00:00"
+'%s') )/60/60/24 ))
if [[ $DAYS -lt "42" ]]; then
echo "Date to delete is in not before 6 weeks"
exit
fi
METRICS=( `curl -s -k http://$1:$2/api/v1/metricnames -X GET|sed -e 's/[{}]/''/g' |
awk -v k="results" '{n=split($0,a,","); for (i=1; i<=n; i++) print a[i]}'|tr -d
'[":]'|sed 's/results//g'|grep -w "cpu\|mem\|disk\|net\|sys"` )
echo $METRICS
for var in "${METRICS[@]}"
do
for date in `seq 1 30`;
do
STARTDAY=$(($(date -d $3/$date/$4 +%s%N)/1000000))
end=$((date + 1))
date -d $3/$end/$4 > /dev/null 2>&1
if [ $? -eq 0 ]; then
ENDDAY=$(($(date -d $3/$end/$4 +%s%N)/1000000))
echo "Deleting $var from " $3/$date/$4 " to " $3/$end/$4
echo '
{
"metrics": [
{
"tags": {},

Pgina 22 de 78

"name": "'${var}'"
}
],
"cache_time": 0,
"start_absolute": "'${STARTDAY}'",
"end_absolute": "'${ENDDAY}'"
}' > /tmp/metricsquery
curl http://$1:$2/api/v1/datapoints/delete -X POST -d @/tmp/metricsquery
fi
done
done
rm -f /tmp/metricsquery > /dev/null 2>&1
Nota
El espacio recuperado no se observar hasta que se produzca la compactacin de datos y

expire la columna del marcador de eliminacin (tombstone), algo que sucede cada 10 das
de forma predeterminada. Si desea modificar esta opcin, edite gc_grace_seconds en el
archivo de configuracin cassandra.yaml.
KairosDB v0.9.1 utiliza el nivel de consistencia Curum tanto para lectura como para escritura. Para
calcular el nivel Curum, se lo redondea hacia abajo (factor de replicacin + 1)/2 y, tanto para lectura
como para escritura, la cantidad de nodos de rplica de Curum debe estar disponible. Los datos se
asignan a nodos a travs de un algoritmo de hash, y cada rplica tiene la misma importancia. En la
siguiente tabla, se ofrecen instrucciones sobre las configuraciones del factor de replicacin y el
tamao del clster.
Tabla 4. Instrucciones de configuracin de Cassandra

Factor de
repl.
Tamao del
clster
Cantidad de datos
del nodo
Curum
Disponibilidad
100%
No tolera la prdida de ningn nodo.
50%
33%
100%
67%
50%
100%
Tolera la prdida de un nodo.
75%
60%
100%
80%

Pgina 23 de 78

Factor de
repl.
Tamao del
clster
Cantidad de datos
del nodo
Curum
Disponibilidad
100%
Tolera la prdida de dos nodos.
83%
Tolera la prdida de dos nodos.
5.4
Pivotal RabbitMQ
La funcionalidad de vCloud Director puede extenderse de dos maneras diferentes:
vCloud Director y la API de vCloud incluyen un marco para la integracin de servicios de extensiones
a los que un cliente de API de vCloud puede acceder como si fueran servicios nativos. Adems de
las operaciones y los objetos especficos de servicios que ofrecen, los servicios de extensin pueden
implementar nuevas operaciones para objetos de API existentes.
Los mensajes de vCloud permiten conectar vCloud Director con sistemas externos mediante la
publicacin de notificaciones o mensajes de tareas de bloqueo en agentes de mensajera
empresariales basados en AMQP.
Figura 8. Extensiones de vCloud Director
Las dos opciones se basan en un agente de mensajes AMQP, que debe instalarse. El servicio AMQP
debe estar configurado en vCloud Director. VMware recomienda utilizar Pivotal RabbitMQ como agente
AMQP.
Pgina 24 de 78

El servicio AMQP (el publicador) de vCloud Director enva mensajes al intercambio AMQP, que luego los
enruta a colas especficas segn una clave de enrutamiento. Los sistemas externos (para los
consumidores, consulte VMware Fling en VCD-nclient) se conectan a las colas y escuchan los mensajes.
Figura 9. Arquitectura de los mensajes AMQP
Las siguientes son consideraciones de diseo de RabbitMQ:
Las celdas de vCloud Director vuelven a intentar la entrega de mensajes al agente AMQP hasta que
se alcanza el tiempo de espera configurado.
vCloud System Administrator recibe una notificacin por correo electrnico cuando se pierde la
conexin con el servidor AMQP.
El agente RabbitMQ puede implementarse en clster para lograr alta disponibilidad. Todas las
definiciones (intercambios, enlaces, usuarios, etc.) estn reflejadas en todo el clster. Puede utilizar
nodos RabbitMQ con equilibrio de carga (configure el servicio AMQP en vCloud Director con la
direccin IP virtual del equilibrador de carga), o bien cada celda de vCloud puede tener instalado el
servicio RabbitMQ (apunte el servicio AMQP a la direccin de localhost).
Cuando RabbitMQ est implementado en clster, no controla bien las particiones de red. Por lo tanto,
no se recomienda implementar nodos entre sitios. Una situacin de cerebro dividido provocar que
algunos mensajes no se entreguen correctamente. Es esencial supervisar el estado de los clsteres.
De forma predeterminada, las colas residen solo en el nodo donde se declararon. Para obtener alta
disponibilidad, deben reflejarse en nodos con un maestro y varios esclavos; esto se logra a travs de
una directiva. Los mensajes publicados en la cola se replican a todos los esclavos. Los
consumidores se conectan al maestro ms all del nodo al que estn asociados, y los esclavos
descartan los mensajes que se confirmaron en el maestro.
El consumidor se suscribe a la misma cola a travs de todos los agentes RabbitMQ o con un agente
de equilibrio de carga, y puede recuperar mensajes en caso de errores en un nodo.
Aunque VMware an ofrece la descarga de VMware vFabric RabbitMQ, el sitio web de Pivotal tiene
la versin ms reciente. Pivotal tambin ofrece soporte para RabbitMQ.
RabbitMQ escala verticalmente hasta miles de mensajes por segundo, una cantidad mucho mayor a
la que puede publicar vCloud Director. Por lo tanto, no es necesario equilibrar la carga de los nodos
de RabbitMQ por motivos de rendimiento.
RabbitMQ puede utilizar SSL para la comunicacin con vCloud Director y los consumidores. Esta
opcin debe habilitarse cuando la comunicacin pase por redes no seguras.
En algunos casos poco frecuentes, es posible que los tenants necesiten acceder a mensajes de
vCloud especficos de la organizacin para conectar sus propias herramientas de orquestacin.
Aunque esta situacin es ms probable en entornos de nube dedicada, es posible satisfacer esta
solicitud con el complemento Shovel de RabbitMQ. El proveedor implementar la propia instancia del
tenant de RabbitMQ, mientras que el RabbitMQ del proveedor conectar mediante un proxy un
subconjunto de mensajes de vCloud a la instancia del tenant.
El complemento Shovel tambin puede utilizarse para mensajes de agregacin de varias instancias
de vCloud Director en un receptor RabbitMQ. Esto puede ser til en una configuracin multiregional,
donde el portal de la federacin consume mensajes de una instancia de RabbitMQ central agregada.
Pgina 25 de 78

Figura 10. Ejemplo de RabbitMQ multiregional
En la siguiente figura, se muestra un ejemplo de un diseo de RabbitMQ con alta disponibilidad.

RabbitMQ se instala junto con vCloud Director en cada mquina virtual de celda en una configuracin en
clster, y adems se habilita la creacin de reflejos de colas. El servicio AMQP en vCloud Director
apunta el host AMQP a una URL de localhost. El consumidor (por ejemplo, vRealize Orchestrator)
establece una suscripcin con cada nodo. No es necesario utilizar un equilibrador de carga.
Figura 11. Ejemplo de diseo de RabbitMQ

Pgina 26 de 78

5.5
Chargeback Manager
VMware vCenter Chargeback Manager ofrece capacidad de medicin para permitir que los costos
sean transparentes. En entornos de proveedores de servicios, por lo general, se utiliza para medir el uso
que hacen los tenants de los recursos y tambin para proporcionar datos sin procesar a los sistemas de
facturacin existentes.
vCenter Chargeback se conecta con la base de datos de vCenter del grupo de recursos y recupera datos
de uso cada 30 minutos. La integracin con vCloud Director se maneja a travs de dos recopiladores de
datos adicionales, que recopilan datos en intervalos de 5 minutos:
El recopilador de datos de vCloud se conecta con vCloud Director a travs de la API de vCloud para
recopilar datos de uso de recursos para cada organizacin. vCenter Chargeback genera
automticamente las jerarquas de cada organizacin.
El recopilador de datos de vShield habla con VMware vCloud Networking and Security o con NSX
Manager y recopila informacin sobre los recursos de red que utilizan los tenants de vCloud.
Los recursos descritos en la siguiente tabla pueden medirse.

Tabla 5. Mtricas de vCenter Chargeback
Recurso
Mtricas de Chargeback
CPU
Uso/asignacin de CPU (GHz)

vCPU (recuento)
Memoria
Uso/asignacin de memoria (GB)
Red
Recuento de redes
Servicios de red (escala y disponibilidad de DHCP, enrutamiento esttico,

firewalls, NAT, IPSec, VPN, equilibrio de carga, puertas de enlace Edge)
Trfico de E/S de red externo (transmisin/recepcin, GB/hora)
Uso de almacenamiento (GB)
Uso de lectura/escritura de E/S del disco (GB/hora)
Costo fijo
Concesin de licencias
Disco
Personalizado
Las directivas de facturacin definen la cantidad de unidades de recursos informticos cobrables que
deben considerarse. Los modelos de precios consisten en tarifas de recursos y directivas de facturacin.
Los informes incluyen el costo o el uso de una entidad jerrquica en particular durante un perodo segn
un precio determinado.
Las siguientes son consideraciones de diseo de vCenter Chargeback:
Un recopilador de datos de vCenter Chargeback puede conectar un mximo de 5 instancias de

vCenter Server y recopilar informacin desde un mximo de 15.000 mquinas virtuales. Una
instancia de vCenter Chargeback puede conectar un mximo de 10 instancias de vCenter y recopilar
informacin de 5.000 jerarquas y 35.000 mquinas virtuales. El nivel de recopilacin de estadsticas
de vCenter puede elevarse hasta el nivel 3 en ciertos escenarios de cobro (lectura/escritura de disco,
transmisin de red) con una retencin de al menos 30 minutos. El recopilador de vCenter
Chargeback de intervalo recupera datos de la base de datos de vCenter.
Pgina 27 de 78

Los recopiladores de datos de vCenter Chargeback pueden instalarse en varios servidores para una
mayor escalabilidad. Implemente al menos dos de cada tipo para obtener alta disponibilidad.
Los datos medidos se conservan en la base de datos de vCenter Chargeback con trabajos de
acumulacin regulares. Hay una retencin de datos con una granularidad de datos de 5 minutos
disponible solo para las ltimas 24 horas. Luego se acumula en promedios mximos de 1 da, que se
conservan para siempre.
Puede utilizarse MS SQL u Oracle para la base de datos de vCenter Chargeback. Hay una
herramienta de dimensionamiento disponible en
https://www.vmware.com/support/vcbm/doc/CBM%20DB%20Size%20Calculator.xlsm.
Puede equilibrarse la carga de los nodos del servidor Chargeback a travs de un equilibrador de
carga integrado. No se admite un equilibrador de carga externo. Para obtener alta disponibilidad,
implemente el equilibrador de carga por separado en una mquina virtual de vCPU protegida por
VMware vSphere Fault Tolerance.
Los recopiladores de datos pueden implementarse externamente o integrarse en nodos del servidor
Chargeback. La carga se distribuye de manera uniforme entre ellos.
Por lo general, no se permite que los tenants vean directamente los informes de costo y uso.
vCenter Chargeback se integra con LDAP basado en Active Directory, pero el rol de superusuario de
vCenter Chargeback puede asignarse solo a un usuario local. vCenter Chargeback utiliza
autorizacin basada en recursos. Por lo tanto, antes de que un usuario de LDAP pueda acceder a
una determinada jerarqua de vCenter Chargeback, un superusuario debe habrsela asignado.
Los informes pueden programarse a travs de una API similar a REST y exportarse a un sistema de
facturacin en formato XML.
Hay un SDK disponible en https://www.vmware.com/pdf/cbm_api_prog_guide_2_5_0.pdf.
El complemento vRealize Orchestrator est disponible en

https://communities.vmware.com/docs/DOC-29977
vCenter Chargeback solo tiene compatibilidad limitada para vCloud Director 8.0.
5.6
vRealize Orchestrator
vRealize Orchestrator ofrece orquestacin de servicios. Puede automatizar tareas entre productos de
VMware mediante el aprovechamiento de la API de vCloud, la API de VIM, las API de vCloud Networking
and Security/VMware NSX o la API de vCenter Chargeback. A travs de complementos genricos (SSH,
SOAP, HTTP REST, SQL, PowerShell, Active Directory) o especficos de terceros, tambin puede
orquestar otros sistemas. vRealize Orchestrator ofrece una gran biblioteca de flujos de trabajo y acciones
en su configuracin bsica, y su biblioteca crece con cada complemento que se instala. Pueden
disearse flujos de trabajo potentes con conocimientos escasos o nulos de una API.
vRealize Orchestrator puede tener dos roles distintos en entornos de vCloud Director.
Puede actuar como una extensin que est suscripta a RabbitMQ y consume mensajes de vCloud
Director. En este rol, vRealize Orchestrator ampla a vCloud Director al ofrecerle servicios
adicionales (copia de seguridad, controles adicionales, integracin con CMDB, etc.).
Acta como orquestador para tareas comunes de incorporacin o ciclo de vida de tenants. Las
tareas se activan a travs de un portal externo (VMware vRealize Automation Advanced Service
Designer o a travs de la API de REST de vRealize Orchestrator). Al utilizar complementos, el
servicio del tenant puede configurarse de extremo a extremo.

Pgina 28 de 78

Las siguientes son consideraciones de diseo de vRealize Orchestrator:
vRealize Orchestrator puede instalarse en el sistema operativo Windows o proporcionarse como

dispositivo virtual.
vRealize Orchestrator requiere una base de datos. Se admiten las siguientes bases de datos: MS
SQL, Oracle, PostgreSQL, base de datos integrada o base de datos de vCenter Server (versin de
Windows de vRealize Orchestrator nicamente).
Para implementaciones de gran escala y configuraciones de alta disponibilidad, se recomienda

especialmente utilizar una base de datos externa.
En el modo de clster de alta disponibilidad, varios nodos de servidor de vRealize Orchestrator con
configuraciones idnticas de servidor y complementos funcionan de forma conjunta como clster y
comparten una base de datos. Solo los nodos activos responden a las solicitudes del cliente y
ejecutan flujos de trabajo. Todos los nodos del servidor se comunican entre s mediante el
intercambio de latidos (de forma predeterminada, cada 5 segundos, con un umbral de 12 latidos) a
travs de la base de datos. Si una instancia activa no enva latidos, se considera que no responde y
una de las instancias inactivas asume el control para reanudar todos los flujos de trabajo desde el
punto en que se interrumpieron. Debe utilizarse un equilibrador de carga de red para enviar las
solicitudes del cliente a un nodo activo.
Aunque es posible tener ms de un nodo activo en un clster, no puede utilizarse vRealize

Orchestrator Client debido a problemas de simultaneidad. La cantidad predeterminada de nodos
activos es uno (se recomienda un mximo de tres).
Es posible escalar horizontalmente con instancias independientes de vRealize Orchestrator que se

implementen para una tarea especfica (por ejemplo, consumir la cola de AMQP dedicada).
Puede utilizarse un complemento multinodo para coordinar flujos de trabajo entre instancias
independientes de vRealize Orchestrator.
A continuacin, se presentan los complementos externos de vRealize Orchestrator recomendados:
vCloud Director 8.0.0
VMware NSX 1.0.2
Vista previa tcnica de vCenter Chargeback Manager 2.0.0.3

(https://communities.vmware.com/docs/DOC-29977)
Escalabilidad: una sola instancia de vRealize Orchestrator admite un mximo de 300 instancias de
flujo de trabajo simultneas en estado de ejecucin, con 35.000 mquinas virtuales administradas en
el inventario.
5.7
vRealize Operations Manager
El rol de vRealize Operations Manager es supervisar el rendimiento y la capacidad del clster de

administracin y de los grupos de recursos, adems de integrarse con vCloud Director para ofrecer
mtricas tiles orientadas al proveedor. Algunos ejemplos son el uso de VDC, el exceso de suscripciones
y la utilizacin de VDC de organizacin.
Se recomiendan los siguientes paquetes de administracin:
MP para vCloud Director 3.0
MP para VMware NSX para vSphere 2.0
MP para vRealize registro Insight

Pgina 29 de 78

5.8
vCloud Usage Meter
vCloud Usage Meter es un dispositivo virtual que recopila datos de uso de vCenter Server y vCloud
Director con el fin de ofrecer datos para la concesin de licencias de VSPP. Debe tener acceso a
instancias de vCenter Server de grupos de recursos y a la API de vCloud Director.
Figura 12. Flujo de trabajo de vCloud Usage Meter

Pgina 30 de 78

6.
Grupos de recursos
Un grupo de recursos es un conjunto de recursos informticos, de redes y de almacenamiento dedicados

a cargas de trabajo de tenants y administrados por un solo par de vCenter Server/NSX Manager. vCloud
Director administra los recursos de todos los grupos de recursos conectados a travs de la comunicacin
de la API con vCenter Server y NSX Manager.
El aprovisionamiento de recursos en agrupamientos estandarizados ofrece un enfoque coherente para
escalar entornos de vCloud. Se recomienda utilizar una instancia de vCenter Server por separado para
administrar grupos de recursos en todos los casos, excepto para entornos muy pequeos. Si se utiliza
una sola instancia de vCenter Server para administrar componentes y grupos de recursos, coloque todos
los componentes de administracin de vCloud en un clster por separado.
La decisin de crear un nuevo grupo de recursos en lugar de escalar horizontalmente un grupo de
recursos existente se basa en lo siguiente:
Separacin de dominios de zona de errores
Requisitos del modo multisitio
Lmites de escalabilidad (para componentes fsicos y virtuales)
Lmites de objetos de vCloud Director (las redes VDC de proveedor o VDC de organizacin no
pueden expandir dominios de vCenter)
6.1
Componentes de administracin de grupos de recursos
Los componentes de administracin de los grupos de recursos estn instalados en el clster de

administracin, junto con los componentes de administracin de la nube, o en su propio clster de
administracin en la configuracin multisitio (consulte la seccin 3.1.2.1, Grupos de recursos distribuidos).
Por lo general, los componentes de administracin consisten en vCenter Server, NSX Manager y
sistemas complementarios (base de datos de vCenter Server, VMware vSphere Update Manager,
VMware vCenter Single Sign-On, syslog distribuido, Active Directory, etc.).
6.2
Recurso informtico
El recurso informtico est representado por un conjunto de clsteres de vSphere con VMware vSphere
High Availability y VMware vSphere Distributed Resource Scheduler (DRS) habilitados. Para obtener
detalles, consulte las consideraciones de diseo en el documento Arquitectura de plataformas
informticas de VMware vSphere para proveedores de servicios.
Las siguientes son consideraciones de diseo de recursos informticos:
Al calcular la capacidad informtica requerida, tenga en cuenta la sobrecarga de virtualizacin

(sobrecarga de procesos de VMkernel y memoria de mquinas virtuales) y los recursos necesarios
para los dispositivos virtuales de puertas de enlace Edge, que no se cobran en funcin del consumo
del tenant.
VMware recomienda no mezclar generaciones de CPU dentro de la misma oferta de servicios (VDC
de proveedor), ya que el cliente puede tener una experiencia de rendimiento diferente debido a la
asignacin de CPU de vCloud Director basada en la velocidad de reloj en GHz.
La seleccin de una directiva de control de admisin de High Availability depende de los acuerdos de
nivel de servicio (Service Level Agreement, SLA) requeridos. La nica directiva que garantiza el
reinicio de todas las cargas de trabajo de un host con errores es Especificar hosts de conmutacin
por error.
La cantidad de ncleos fsicos con hiperproceso determina la cantidad mxima de vCPU que los
tenants pueden asignar a sus mquinas virtuales.
Pgina 31 de 78

Debido a las implicancias de seguridad en entornos de varios tenants, deshabilite el uso compartido
transparente de pginas de memoria. Para obtener ms informacin, consulte el artculo de la base
de conocimientos de VMware Capacidades adicionales de administracin de uso compartido
transparente de pginas en las revisiones 5.5, 5.1 y 5.0 de ESXi, cuarto trimestre de 2014 (Additional
Transparent Page Sharing Management capabilities in ESXi 5.5, 5.1, and 5.0 patches in Q4, 2014)
(2091682), en http://kb.vmware.com/kb/2091682.
El exceso de suscripciones de memoria fsica puede provocar un aumento de memoria mediante

globo o un intercambio de discos duros, lo que puede afectar a otros tenants. En el modelo de
asignacin de tipo reserva, el tenant puede suscribir en exceso su VDC asignado real. Por lo tanto,
VMware recomienda utilizar siempre el modelo de asignacin tipo reserva en el hardware dedicado
del tenant.
6.3
Redes
vCloud Director crea y administra redes y servicios de redes virtuales a travs de un componente externo,
como VMware vShield Manager o NSX Manager. vShield Manager es el componente de
administracin de vCloud Networking and Security, que ya no se desarrolla y dejar de tener soporte en
2016.
VMware NSX for vSphere ofrece compatibilidad completa con versiones anteriores, y una ruta de acceso
de actualizacin sencilla para vCloud Networking and Security que agrega las siguientes funcionalidades:
Escalamiento mejorado (10.000 redes lgicas como mximo)
Modos de plano de control VXLAN hbrido y de unidifusin que simplifican la configuracin de la red
fsica subyacente (sin necesidad de enrutamiento PIM de multidifusin)
Enrutamiento lgico distribuido para conectividad Este-Oeste
Compatibilidad con los protocolos de enrutamiento dinmicos OSPF y BGP
Puente de VXLAN a VLAN
Caractersticas avanzadas de equilibrio de carga (descarga de SSL, reglas de aplicacin hasta

Capa 7)
VPN SSL de Capa 2
Firewall distribuido en el nivel de la vNIC
A partir de vCloud Director 8.0, las caractersticas de VMware NSX no estn disponibles para tenants, y
solo el proveedor puede aprovecharlas.
Algunas de las instrucciones de compatibilidad para el uso de caractersticas de NSX adems de vCloud
Director son las siguientes:
En general, VMware recomienda no alterar los objetos de red creados y administrados por vCloud
Director directamente a travs de NSX (por ejemplo, actualizar la puerta de enlace NSX Edge a la
versin 6). Realice todos los cambios de configuracin a travs de vCloud Director.
Puede utilizarse NSX Manager para aprovisionar objetos consumidos solo por vCloud Director.
Algunos ejemplos son enrutadores externos (Edge y DLR) y redes externas.
Puede utilizarse NSX Manager para alterar el modo de plano de control de la zona de transporte de
VXLAN de multidifusin a basada en controladoras (unidifusin o hbrido). Sin embargo, todas las
reconfiguraciones de VDC de proveedor que agreguen o quiten un clster modificarn el modo de
plano de control, que volver a ser de multidifusin.
Las reglas de firewall distribuido son transparentes para vCloud Director. Sin embargo, al aplicarlas a
redes de VDC de organizacin o vApp, debe utilizarse la opcin aplicado a, debido a la
superposicin de espacios de direcciones IP.
Pgina 32 de 78

6.3.1 Zonas de transporte

Una zona de transporte define el mbito de un conmutador lgico de VXLAN. Consiste en uno o varios
clsteres de vSphere. Las zonas de transporte pueden crearse manualmente. Sin embargo, vCloud
Director crea automticamente una zona de transporte para cada VDC de proveedor, que coincide con
los clsteres que se agregan al VDC de proveedor y se asocia con un grupo de redes VXLAN. Cuando el
administrador del sistema vCloud crea un VDC de organizacin, o cuando se lo crea a partir de una
plantilla de VDC, debe asignarse un grupo de redes. Todas las redes de VDC de organizacin y vApp
expandirn el alcance de la zona de transporte.
Nota
La zona de transporte creada por vCloud Director siempre utiliza el modo de plano de control de
VXLAN de multidifusin. Sin embargo, puede modificarse manualmente a unidifusin/hbrido. Al
agregar o quitar un clster en el VDC de proveedor se restablece su zona de control a modo de
multidifusin.
6.3.2 Clster de NSX Edge

Las redes superpuestas de VMware NSX permiten crear redes lgicas sobre un tejido de red IP existente.
Esto permite un diseo de red altamente escalable que utiliza una arquitectura de leaf-spine, donde el
lmite entre las redes de Capa 2 y Capa 3 est en el nivel del bastidor (leaf) y toda la comunicacin entre
bastidores es de Capa 3 solo a travs de un grupo de enrutadores spine.
Las redes lgicas de VMware NSX se expanden por todos los bastidores. Sin embargo, existe una
necesidad de conectar cargas de trabajo virtuales desde las redes lgicas hacia el mundo fsico exterior
(WAN, Internet, servidores fsicos coubicados, etc.). Estas redes estn representadas por un grupo de
VLAN, y debido a que la Capa 2 no se ampla por los bastidores, no pueden enlazarse troncalmente en
todos lados. Estn conectados a un solo bastidor (o a dos, por motivos de redundancia) y se convierten
en el clster de NSX Edge.
El objetivo del clster de NSX Edge es alojar enrutadores virtuales, puertas de enlace de servicio Edge
que ofrecen conectividad entre el mundo fsico (VLAN) y el mundo virtual (conmutadores lgicos de
VXLAN). Esto no significa que cada una de las puertas de enlace de NSX Edge deba implementarse all.
Si una puerta de enlace NSX Edge ofrece conectividad entre dos conmutadores lgicos VXLAN, puede
implementarse en cualquier lugar, ya que los enrutadores lgicos se expanden por todos los clsteres.
6.3.2.1. Opcin de diseo 1 Tradicional
En la arquitectura de red tradicional de acceso/adicin/ncleo, el lmite de Capa 2/Capa 3 est en los
conmutadores de adicin. Esto significa que todos los bastidores conectados al mismo conjunto de
conmutadores de adicin tienen acceso a las mismas VLAN. No hay necesidad de contar con un clster
Edge, ya que la mquina virtual Edge que conecta a la VLAN con redes basadas en VXLAN puede
ejecutarse en cualquier bastidor. En vCloud Director, si las redes externas (VLAN) se enlazan
troncalmente con conmutadores de adicin, la seleccin de la instancia Edge no resulta un problema.
Por lo general, el conjunto de bastidores (clsteres) conectados al mismo dominio de adicin se asigna a
un VDC de proveedor de vCloud Director. De esta manera, la zona de transporte es idntica al dominio
de adicin. La desventaja de este diseo es que los VDC de proveedor no pueden expandirse a varios
dominios de adicin.

Pgina 33 de 78

Figura 13. Arquitectura tradicional de acceso/adicin/ncleo
6.3.2.2. Opcin de diseo 2a Clster combinado Edge/informtico

Cuando se utiliza la arquitectura de red de leaf-spine, las VLAN que respaldan a las redes externas de
vCloud Director se enlazan troncalmente solo al clster Edge/informtico. El motor de seleccin de
vCloud Director implementa mquinas virtuales Edge en un clster segn la conectividad de la VLAN.
vCloud Director selecciona automticamente todas las puertas de enlace Edge en el clster
Edge/informtico, ya que es el nico clster donde existe conectividad externa (VLAN). Sin embargo,
vCloud Director tambin colocar de manera oportuna las mquinas virtuales normales de tenants en
este clster (de all su nombre, Edge/informtico).

Pgina 34 de 78

Figura 14. Leaf-spine con clster Edge/informtico
Esta opcin de diseo tiene todas las ventajas de escala de la arquitectura leaf-spine. Sin embargo, la
desventaja es la posibilidad de que las cargas de trabajo de los tenants ocupen el espacio limitado en el
clster Edge/informtico. Hay dos opciones para corregir esto:
El administrador del sistema vCloud siempre implementa las puertas de enlace Edge de vCloud
Director. Antes de la implementacin de las puertas de enlace Edge, el administrador puede
comprobar si existe capacidad suficiente en el clster Edge/informtico. Si no la hay, algunas cargas
de trabajo de los tenants pueden migrarse a otro clster. Esto debe realizarse desde dentro de
vCloud Director (opcin Grupo de recursos/Migrar a). La migracin en vivo solo es posible si el
clster Edge/informtico comparte el mismo VMware vSphere Distributed Switch (VDS) preparado
para VXLAN con el resto de los clsteres. Esta configuracin requiere al menos cuatro vnculos
superiores de red en los hosts del clster Edge/informtico (dos para el VDS Edge con VLAN
externas y dos para el VDS de VXLAN que se expande a todos los clsteres).
Limite artificialmente el tamao del clster Edge/informtico para que el motor de seleccin no lo
seleccione para cargas de trabajo normales de tenants. Esto puede lograrse aprovechando el grupo
de recursos, que el administrador del sistema crea manualmente en el clster Edge/informtico y
conecta con el VDC de proveedor, no con todo el clster. El administrador del sistema establece un
lmite artificial, que se aumenta solo cuando debe implementarse una nueva puerta de enlace Edge.
Lamentablemente, las dos opciones implican una significativa sobrecarga operativa.

Pgina 35 de 78

6.3.2.3. Opcin de diseo 2b Clster combinado Edge/informtico con VDC no elstico
Los tipos de VDC de organizacin elsticos (como los de pago por uso o asignacin) pueden expandirse
a varios clsteres. Tenga en cuenta el impacto de un VDC no elstico, como un grupo de reservas.
En un VDC de organizacin no elstico, todas las cargas de trabajo de un tenant se implementan en el
grupo de recursos del VDC de proveedor principal. Las mquinas virtuales Edge pueden implementarse
en grupos de recursos secundarios. Si el clster Edge/informtico se agrega como grupo de recursos
secundario en un VDC de proveedor, puede utilizarse esta opcin de diseo.
Figura 15. Leaf-spine con clster Edge/informtico y VDC no elstico
6.3.2.4. Opcin de diseo 3a Edge dedicado

Esta opcin de diseo posee un clster Edge dedicado no administrado por vCloud Director, adems de
introducir un nuevo tipo de puerta de enlace Edge: Edge de proveedor. El proveedor de servicios
implementa manualmente una instancia de Edge de proveedor en el clster Edge por fuera de vCloud
Director. Los vnculos superiores externos Edge de proveedor estn conectados a redes externas
basadas en VLAN, mientras que las interfaces internas estn conectadas a un conmutador lgico VXLAN
de trnsito que se expande a todos los clsteres informticos y Edge (a travs de zonas de transporte
creadas manualmente para todos los clsteres). De esta manera, vCloud Director consume las redes de
trnsito como redes externas.

Pgina 36 de 78

Las instancias de Edge de proveedor pueden ofrecer toda la funcionalidad de VMware NSX (protocolos
de enrutamiento dinmico en vnculos superiores externos, puentes de Capa 2, VPN de Capa 2, etc.).
Pueden escalar a medida que se agregan redes externas de vCloud Director (el mximo actual en
vCloud Director 8.0 es de 750 redes externas). De esta manera, las instancias de Edge implementadas
por vCloud Director se dirigen a clsteres informticos, ya que todas sus interfaces se conectan a
conmutadores lgicos VXLAN expandidos en todos lados en el VDC de proveedor.
Figura 16. Leaf-spine con clster Edge dedicado
6.3.2.5. Opcin de diseo 3b Clster Edge dedicado con Edge ECMP

En la opcin de diseo anterior, haba una sola instancia de Edge de proveedor en el clster Edge para cada
red externa de trnsito de vCloud Director, a la cual se conectaban puertas de enlace Edge de VDC de
organizacin. Esa opcin funciona bien para casos de uso donde la instancia de Edge de proveedor est
dedicada a tenants individuales, por ejemplo, la prestacin de servicios de VPN o puentes de Capa 2. (En un
caso de uso de puentes de Capa 2, la puerta de enlace Edge del VDC de organizacin no se implementa y
las redes del VDC de organizacin se conectan directamente a una red externa dedicada del tenant).
Para ofrecer acceso a un servicio compartido (por ejemplo, Internet) donde varias puertas de enlace
Edge de VDC de organizacin de diferentes tenants se conectan con la misma red externa, todo el
trfico de red externo debe pasar por una sola instancia de Edge de proveedor, algo que puede producir
cuellos de botella.
Pgina 37 de 78

Pueden implementarse puertas de enlace Edge de VMware NSX en una configuracin de enrutamiento
de mltiples rutas de igual costo (Equal Cost Multi-Path, ECMP), donde puede agregarse el ancho de
banda de 8 Edge (8 x 10 GB = 80 GB de capacidad de proceso) como mximo. La alta disponibilidad de
las instancias de Edge ECMP se logra a travs de un protocolo de enrutamiento dinmico (BGP o OSPF)
configurado con una sincronizacin intensa de tiempos cortos de conmutacin por error (3 segundos), lo
que elimina rpidamente las rutas de acceso que presenten errores de las tablas de enrutamiento.
El problema es que (a partir de vCloud Director 8.0), las instancias de Edge de VDC de organizacin se
implementan en modo heredado (vShield/vCloud Networking and Security) y no son compatibles con
enrutamiento ECMP o con protocolos de enrutamiento dinmico. El siguiente diseo funciona a pesar de
esta limitacin si se implementa un enrutador lgico distribuido (Distributed Logical Router, DLR) entre
las instancias de Edge de VDC de organizacin y de proveedor.
Figura 17. Leaf-spine con clster Edge dedicado y Edge ECMP

Pgina 38 de 78

La figura anterior muestra dos Edge ECMP de proveedor (que pueden escalar hasta una mximo de 8)
con dos conexiones de VLAN fsicas cada uno. Estas conexiones se realizan hacia el enrutador fsico
ascendente, y una interfaz interna al conmutador lgico de trnsito Edge. A continuacin, el DLR conecta
el conmutador lgico de trnsito Edge con la red externa de trnsito de vCloud Director, a la cual estn
conectadas todas las puertas de enlace Edge de VDC de organizacin de los tenants. El DLR tiene el
enrutamiento ECMP habilitado, adems de comunicacin del mismo nivel de enrutamiento dinmico
OSPF o BGP con las instancias de Edge de proveedor. El DLR ofrece dos (o ms) rutas de acceso
iguales a las instancias de Edge de proveedor ascendentes y selecciona una de acuerdo con un
algoritmo de hash de las direcciones IP de origen y destino del paquete enrutado.
De esta manera, las dos puertas de enlace Edge de VDC de organizacin mostradas (que pertenecen a
dos tenants diferentes) aprovechan todo el ancho de banda proporcionado por el clster Edge (indicado
con las flechas de color naranja).
La figura adems describe la mquina virtual de control del DLR. Este es el endpoint de protocolo que se
comunica en el mismo nivel con la instancia de Edge de proveedor para aprender y anunciar rutas. A
continuacin, el clster de VMware NSX Controller (no se muestra en la figura) distribuye las rutas en
el proceso de enrutamiento del VMkernel del host VMware ESXi. Un error de la mquina virtual de
control del DLR afecta la informacin de enrutamiento aprendida a travs de los protocolos OSPF/BGP,
incluso si el DLR tiene alta disponibilidad en la configuracin de espera activa. Esto se debe a los
temporizadores intensos del protocolo (la conmutacin por error de la mquina virtual de control del DLR
tarda ms de 3 segundos). Por lo tanto, se crea una ruta esttica en todos los Edge de proveedor ECMP
para la subred externa de trnsito de vCloud Director. Eso es suficiente para el enrutamiento Norte-Sur,
ya que las subredes de VDC de la organizacin siempre estn detrs de la puerta de enlace Edge de
VDC de la organizacin del tenant que ofrece traduccin de direcciones de red (Network Address
Translation, NAT). El enrutamiento Norte-Sur es esttico porque las puertas de enlace Edge de VDC de
organizacin estn configuradas con una puerta de enlace predeterminada definida en las propiedades
de red externas.
La otra consideracin es la seleccin de una mquina virtual de control del DLR. Si la mquina virtual
presenta errores junto con uno de los Edge de proveedor ECMP, las rutas de VMkernel del host ESXi no
se actualizan hasta que la funcionalidad de la mquina virtual de control del DLR conmute por error a la
instancia pasiva. Mientras tanto, la ruta hacia el Edge de proveedor que no funciona es trfico de agujero
negro. Si hay una cantidad suficiente de hosts en el clster Edge, implemente mquinas virtuales de
control del DLR con una regla de DRS de antiafinidad para todos los Edge ECMP. Lo ms probable es
que no haya una cantidad suficiente de hosts, por lo que se deben implementar mquinas virtuales de
control del DLR en uno de los clsteres informticos. Las mquinas virtuales son muy pequeas (512 MB,
1 vCPU). El impacto sobre la capacidad del clster es despreciable.

Pgina 39 de 78

6.3.3 Resumen de las opciones de implementacin de clsteres Edge

Tabla 6. Resumen de las opciones de implementacin de clsteres Edge
Opcin de diseo
Pros
Contras
Sin clster Edge
Simpleza
Las VLAN enlazadas troncalmente

a todos los hosts de VDC de
proveedor limitan la escala y
extienden el dominio de errores de
red.
Ideal para arquitecturas

tradicionales de red (tres niveles)
Clster combinado Edge/informtico
Compatibilidad con arquitectura de

red spine-leaf
Escala
Clster Edge dedicado
Implementacin simple
Se necesitan cuatro vnculos

superiores de red (para dos
conmutadores VDS) si se desea
tener la capacidad de migrar
cargas de trabajo en vivo del
clster Edge/informtico.

red spine-leaf
El Edge de proveedor puede

producir un cuello de botella en
implementaciones de gran
magnitud.
Compatibilidad con caractersticas

adicionales de NSX administrado
por el proveedor
Clster Edge dedicado con Edge
ECMP
Sobrecarga de administracin
alrededor de la administracin de
capacidad del clster
Edge/informtico.

red spine-leaf
Implementacin compleja
Altamente escalable
Compatibilidad con caractersticas
adicionales de NSX administrado
por el proveedor

Pgina 40 de 78

6.3.4 Clster de NSX Controller

El clster de NSX Controller es el componente del plano de control que tiene la funcin de administrar los
mdulos de conmutacin y enrutamiento en el VMkernel de ESXi. En la siguiente tabla se muestran las
caractersticas de VMware NSX que requiere el clster de NSX Controller.
Tabla 7. Requisitos de caractersticas del clster de NSX Controller
Caracterstica de NSX
Requisito del clster de NSX

Controller
Plano de control de transporte de

VXLAN
Multidifusin
Hbrido
Unidifusin
Firewall distribuido
Puertas de enlace de servicios de NSX
Edge
Enrutador lgico distribuido
Puentes VXLAN-VLAN
Supresin de ARP
Para la migracin de vCloud Network and Security a VMware NSX, el clster de NSX Controller debe
implementarse antes de utilizar cualquiera de las caractersticas avanzadas de NSX que requiere.
A continuacin, se presentan las consideraciones de diseo del clster de NSX Controller:
El clster de NSX Controller consiste en nodos de NSX Controller, que NSX Manager implementa en
el entorno de vSphere con el que NSX Manager est comunicado en el mismo nivel. Por lo tanto,
NSX Controller se ejecuta en los clsteres de vSphere del grupo de recursos.
El clster de NSX Controller consiste en tres nodos, que son mquinas virtuales implementadas por
NSX Manager. Un clster de NSX Controller con una mquina virtual puede utilizarse solo con fines
de capacitacin y demostracin. No se permite una cantidad par de controladoras, ya que siempre
debe haber curum.
Para contar con alta disponibilidad, cada nodo de NSX Controller debe colocarse en un host
diferente. Esto puede lograrse con una regla de DRS de antiafinidad creada manualmente.
La mquina virtual del nodo de NSX Controller debe conectarse con un grupo de puertos estndar o
distribuido. No puede conectarse con un grupo de puertos basado en VXLAN (conmutador lgico).
Las instancias de NSX Controller deben tener conectividad de red con vmknics de administracin de
NSX Manager y ESXi. No es necesario implementarlas en la misma subred de Capa 2.

Pgina 41 de 78

6.3.4.1. Opcin de diseo I Clster de Edge
La opcin de seleccin recomendada es implementar los nodos de NSX Controller en el clster Edge
(consulte la seccin 6.3.2.4, Opcin de diseo 3a Edge dedicado). Esto separa el componente de
administracin de las cargas de trabajo de tenants que se ejecutan en clsteres informticos. Adems, el
clster Edge tiene ms opciones de conectividad VLAN que los clsteres informticos. Debido al requisito
de tres nodos del clster NSX, VMware recomienda tener al menos cuatro nodos ESXi en el clster Edge.
6.3.4.2. Opcin de diseo 2 Clsteres informticos
Cuando no se utiliza un clster Edge dedicado, los nodos de NSX Controller pueden implementarse en
los clsteres informticos. La desventaja es que esta configuracin combina cargas de trabajo de tenants
con los componentes de administracin. Para la separacin lgica, deben utilizarse grupos de recursos
con lmites y reservas especficas, con el fin de garantizar el rendimiento de NSX Controller y permitir la
medicin de capacidad informtica por parte de vCloud Director. A continuacin, el VDC de proveedor se
asigna al grupo de recursos, no al clster de vSphere (consulte la seccin 7.1, Centros de datos virtuales
de proveedor).
La conectividad de red debe estar basada en VLAN, con enrutamiento a vmknics de administracin de
NSX Manager y ESXi. Se recomienda utilizar la red de administracin de ESXi.
6.3.4.3. Opcin de diseo 3 Clster de NSX Controller universal
La versin 6.2 de VMware NSX permite combinar varios dominios de vCenter/VMware en un solo
dominio de administracin. Aunque sigue existiendo la combinacin vCenter Server-NSX Manager, una
instancia de NSX Manager acta como dispositivo principal. La instancia principal de NSX Manager
implementa un solo clster de NSX Controller universal. Las instancias de NSX Manager secundarias no
implementan el clster de NSX Controller.
El clster de administracin de NSX Manager acta como dispositivo principal, mientras que todas las
instancias de NSX Manager de los grupos de recursos actan como dispositivos secundarios.
Figura 18. Clster de NSX Controller universal
Nota
A partir de octubre de 2015, vCloud Director ya no es interoperable con NSX 6.2.

Pgina 42 de 78

6.3.5 Firewall distribuido y enrutamiento lgico de NSX

Aunque vCloud Director no posee compatibilidad nativa con firewall distribuido y enrutamiento lgico
(DLR) de NSX, las caractersticas pueden seguir utilizndose en las redes del VDC de organizacin y
externas de vCloud Director si el proveedor las administra externamente o si estn automatizadas. El
DLR permite aprovisionar varias redes enrutables, sin tener en cuenta el lmite de 10 redes de los
enrutadores basados en mquinas virtuales. El firewall distribuido puede aplicar reglas de firewall entre
los segmentos enrutables y ofrecer una conducta similar a una VLAN privada en redes de Capa 2.
Un ejemplo de caso de uso seran servicios compartidos (como supervisin, revisiones o copias de
seguridad) disponibles en la red de servicio para las cargas de trabajo de los tenants. El tenant conecta
cargas de trabajo que poseen una interfaz de red secundaria con una red de servicios dedicados que
posee acceso enrutable a una red de servicios compartidos. Debido a que no es necesario utilizar NAT,
este enfoque es efectivo con cualquier solucin de supervisin o copias de seguridad.
El enrutador lgico distribuido ofrece enrutamiento escalable, mientras que el firewall distribuido
combinado con NSX SpoofGuard ofrece la aplicacin de seguridad para varios tenants necesaria en el
nivel de la vNIC de la mquina virtual del tenant.
Figura 19. Servicios compartidos con firewall distribuido y DLR
Nota
El firewall distribuido de NSX excluye automticamente todas las mquinas virtuales creadas
por VMware NSX. No se pueden crear reglas de firewall distribuido que se apliquen a puertas
de enlace Edge.

Pgina 43 de 78

6.3.6 Otros servicios de red

El proveedor de servicios puede aprovechar capacidades adicionales de VMware NSX fuera de vCloud
Director:
VPN de Capa 2 entre la infraestructura en las instalaciones del cliente y el centro de datos virtual en
la nube.
El proveedor de servicios implementa la puerta de enlace de NSX Edge en el clster Edge y
configura un servidor de VPN de Capa 2. La puerta de enlace Edge est directamente conectada, a
travs de una red externa de vCloud Director dedicada, con el VDC de organizacin del cliente. El
tenant implementa una instancia de NSX Edge independiente en la infraestructura de vSphere en las
instalaciones y la configura como un cliente VPN de Capa 2 (consulte la Gua de administracin de
VMware NSX en http://pubs.vmware.com/NSX-61/index.jsp#com.vmware.nsx.admin.doc/GUIDC9E2B0E4-F1C1-44A7-B142-F814F801FA42.html).
Enrutamiento esttico IPv6, protocolos de enrutamiento dinmicos o equilibrio de carga mejorado.

El proveedor de servicios puede implementar una puerta de enlace NSX Edge para cada tenant en el
clster Edge y configurar manualmente los servicios avanzados. El tenant est directamente
conectado con su NSX Edge a travs de una red externa de vCloud Director dedicada.
Nota La administracin de direcciones IP de vCloud Director (vCloud Director IP Address Management,

IPAM) a travs de personalizaciones de invitados de mquina virtual no es compatible con IPv6.
Figura 20. NSX Edge de tenants
6.4
Almacenamiento
En un entorno de vCloud Director, los usuarios pueden autoaprovisionar vApps en centros de datos
virtuales que contienen un grupo de capacidad de almacenamiento. El usuario no puede acceder a los
detalles del almacenamiento fsico. Se elimina el control preciso del lugar en el cual residen las vApps en
la infraestructura fsica, debido a que la responsabilidad de aprovisionamiento pasa a ser del usuario final.
El dimensionamiento del almacn de datos es un delgado equilibrio entre la disponibilidad, la capacidad
de recuperacin, el rendimiento y los requisitos de administracin. Cuando el aprovisionamiento fino, el
aprovisionamiento rpido o las instantneas estn habilitados, los requisitos de almacenamiento de las
mquinas virtuales existentes pueden aumentar y crear condiciones de almacenes de datos sin espacio.
Debe recurrirse a los umbrales amarillo y rojo del almacn de datos de vCloud Director, las alarmas de
vSphere y otras herramientas de supervisin de almacenamiento.

Pgina 44 de 78

6.4.1 Organizacin en niveles de almacenamiento

Para controlar la elasticidad y la escalabilidad requerida para una implementacin de vCloud, se
recomienda un enfoque en niveles de almacenamiento modular. Esto implica disear para el crecimiento
futuro y, al mismo tiempo, optimizar el rendimiento. Se determina la diferenciacin de almacenamiento
para cada nivel de servicio y, a continuacin, se presentan grupos de niveles de almacenamiento a
vCloud Director.
Las siguientes son consideraciones de diseo de la organizacin en niveles de almacenamiento:
Deben habilitarse directivas de almacenamiento de mquinas virtuales en cada clster de vSphere

del grupo de recursos.
Se crean etiquetas de almacenamiento definidas por el usuario (por ejemplo, bronce, plata, oro), que
se asignan a almacenes de datos de vSphere. Cada directiva de almacenamiento de mquina virtual
de vSphere se asigna a las etiquetas correspondientes con un conjunto de reglas. Despus de la
sincronizacin, las directivas de almacenamiento pueden asignarse a los VDC de proveedor en
vCloud Director. En trminos generales, no debe utilizarse el perfil de almacenamiento universal *
(cualquiera). (Si se utiliza, deshabilite el almacn de datos local).
vCloud Director hace referencia a los almacenes de datos por los nombres de la directiva de
almacenamiento de vSphere. El nombre no debe volver a cambiarse en el futuro dentro de vSphere.
Una sola mquina virtual de vCloud Director puede expandirse en varios almacenes de datos. Por
ejemplo, el disco 1 de la mquina virtual puede estar en el almacn de datos A y el disco 2 de la
mquina virtual en el almacn de datos B, donde los almacenes de datos A y B pertenecen a la
misma directiva de almacenamiento o a varias diferentes. La seleccin de los discos en diferentes
niveles de almacenamiento es posible solo a travs de la API de vCloud Director. Cuando el
aprovisionamiento rpido est habilitado en el nivel del VDC de organizacin, la mquina virtual no
puede expandirse en varios almacenes de datos.
Puede conectarse un solo disco a una sola mquina virtual de manera simultnea. Para el
almacenamiento compartido entre mquinas virtuales, puede utilizarse el almacenamiento IP de
invitados.
Los discos independientes (disponibles solo a travs de la API de vCloud Director) pueden moverse
con facilidad entre las mquinas virtuales.
Pueden utilizarse directivas de almacenamiento para la seleccin de mquinas virtuales en un

subgrupo de hosts ESXi debido a restricciones de licencias (hosts Windows a diferencia de Linux).
La directiva de almacenamiento de un tipo en particular (por ejemplo, Linux) se asigna a un almacn
de datos que se conecta solo a hosts con licencias para cargas de trabajo Linux.
6.4.2 Clsteres de almacenes de datos

Un clster de almacenes de datos es una recopilacin de almacenes de datos con recursos compartidos
y una interfaz de administracin compartida. Los clsteres de almacenes de datos son a los almacenes
de datos lo mismo que los clsteres de vSphere son a los hosts. Se requiere un clster de almacenes de
datos si se desea utilizar VMware vSphere Storage DRS para equilibrar la carga de los recursos de
almacenamiento.
Las siguientes son consideraciones de diseo de clster de almacenes de datos:
El equilibrio de espacio continuo en los LUN con aprovisionamiento fino por parte de la matriz de
almacenamiento crea espacio en blanco inutilizable. La operacin de VMware vSphere Storage
vMotion reubica los archivos de discos de la mquina virtual (VMs disk, VMDK) en la capa de
vSphere. Sin embargo, la matriz de almacenamiento no sabe que se puede volver a utilizar el
espacio liberado en el LUN de origen. Los bloques eliminados deben reclamarse manualmente con
el comando vmkfstools en el aviso de la interfaz de lnea de comandos de ESXi.
Pgina 45 de 78

Un clster de almacenes de datos con Storage DRS puede simplificar las migraciones y la
administracin del almacn de datos con el modo de mantenimiento de Storage DRS. Sin embargo,
ya no es posible administrar almacenes de datos individualmente (habilitar/deshabilitar, umbrales de
disco o VMware vSphere Storage APIs - Integracin de matrices para aprovisionamiento rpido).
Todos los almacenes de datos en un clster de almacenes de datos deben pertenecer a la misma
directiva de almacenamiento.
6.4.3 Operaciones de clonacin y copia

Al disear un almacn de datos (LUN, exportacin de NFS, Virtual SAN), tenga en cuenta la disposicin
y las consideraciones de la red de almacenamiento (en especial el ancho de banda) en cuanto a las
operaciones de clonacin y copia esperadas:
La importacin y la exportacin de plantillas hacia y desde vCloud Director, o el movimiento de

mquinas virtuales o imgenes ISO entre instancias de vCenter Server siempre pasa por vCloud
Director. Las celdas transfieren el volumen compartido por la red de administracin hacia la vmknic
de administracin del host ESXI.
Las operaciones de clonacin y copia entre clsteres de vSphere que no tienen un almacenamiento
compartido comn utilizan la vmknic de administracin del host ESXI o, en el caso de vSphere 6, la
vmknic con el servicio de aprovisionamiento habilitado.
Los medios ISO se almacenan como archivos en el almacn de datos de catlogo. Los elementos
multimedia no pueden montarse en una mquina virtual que est en ejecucin en un host sin acceso
al almacn de datos.
Solo se puede acceder al almacn de datos de Virtual SAN a travs del clster de vSphere al que
pertenece.
Cuando se utiliza el enlace de puertos, el trfico iSCSI no se puede enrutar.
vSphere 5.5 no admite el almacenamiento IP sobre redes IPv6.
Cuando se utiliza un VDC de organizacin elstico, el proveedor puede migrar las mquinas virtuales
en ejecucin de un clster o grupo de recursos a otro. Esta operacin, sin embargo, no admite la
compatibilidad mejorada de vMotion, y se requiere almacenamiento compartido entre los clsteres.
6.4.4 Virtual SAN

Virtual SAN es compatible con vCloud Director y se puede utilizar como nivel de almacenamiento para
tenants mediante directivas de almacenamiento creadas manualmente y relacionadas con las
capacidades de Virtual SAN.
Las siguientes son consideraciones de diseo de Virtual SAN:
El almacn de datos de Virtual SAN es un objeto que est estrechamente relacionado con un solo
clster de vSphere. No puede proporcionar almacenamiento a diferentes clsteres de vSphere.
VMware no recomienda el uso del almacenamiento de Virtual SAN para catlogos. vCloud Director
carga todas las imgenes de medios de catlogo (archivos ISO) como objetos de archivos en una
estructura de directorio de una carpeta. Si se utiliza el mismo almacn de datos de Virtual SAN como
directiva de almacenamiento para diferentes catlogos, estos ltimos comparten un objeto de
espacio de nombres del directorio principal de la mquina virtual con un tamao mximo de 256 GB.
Los dispositivos de almacenamiento virtual de terceros que consumen almacenamiento de Virtual

SAN y proporcionan servicios de archivos NFS se pueden utilizar para proporcionar catlogos a
clsteres con una escala superior a 256 GB.

Pgina 46 de 78

7.
Diseo del proveedor de vCloud
vCloud Director agrega una capa de abstraccin de recursos para permitir que haya varios tenants y
brindar interoperabilidad entre nubes compiladas con el estndar de API de vCloud.
Los recursos fsicos informticos, de almacenamiento y de red se pasan a la capa de vSphere en la

que se crean los grupos de recursos, los conmutadores virtuales y las directivas de almacenamiento.
A continuacin, los grupos de recursos y los almacenes de datos se pasan a vCloud Director y se
asocian a los centros de datos virtuales del proveedor.
Los recursos virtuales informticos y de almacenamiento puros se muestran a los usuarios mediante
las construcciones del centro de datos virtual. Los usuarios consumen recursos virtuales puros de los
centros de datos mediante varios modelos de asignacin.
Figura 21. Relaciones fsicas, virtuales y de abstraccin de nube
Para varios tenants, vCloud Director brinda las siguientes construcciones clave.
Tabla 8. Definiciones de centros de datos virtuales
Trmino
Definicin
Organizacin
Unidad de varios tenants que representa un nico lmite lgico de

seguridad. Una organizacin contiene usuarios y centros de datos
virtuales.
Centro de datos
virtual de
proveedor
Grupo de recursos informticos y de almacenamiento de una sola

instancia de vCenter Server. Un centro de datos virtual de proveedor
puede constar de uno o ms grupos de recursos. Combina grupos de
recursos con una o ms directivas de almacenamiento, y puede
compartir recursos con varias organizaciones.

Pgina 47 de 78

Trmino
Definicin
Centro de datos
virtual de
organizacin
Subgrupo de recursos informticos, de memoria y de almacenamiento,

redes y enrutadores de red asignados desde un centro de datos virtual
de proveedor. Un centro de datos virtual es un entorno de
implementacin en el que se pueden implementar y encender vApps, y
crear instancias de ellas. Los centros de datos virtuales no pueden
expandirse a varias organizaciones.
7.1
Centros de datos virtuales de proveedor
El centro de datos virtual (Virtual Datacenter, VDC) es el contenedor estndar de un grupo de recursos
informticos, de almacenamiento y de red. Hay dos tipos de centros de datos virtuales: de proveedor y
de organizacin. Los centros de datos virtuales de proveedor se pueden ensamblar desde grupos de
recursos y almacenes de datos representados por directivas de almacenamiento que administra una sola
instancia de vCenter Server de grupo de recursos.
Un VDC de proveedor puede expandirse a varios grupos de recursos (o clsteres dedicados) y formar
VDC de organizacin elsticos. Sin embargo, esto solo se admite para VDC de organizacin de pago por
uso y VDC de grupo de asignaciones. Los VDC de grupo de reservas nunca son elsticos y estn
restringidos por el tamao del grupo de recursos principal (clster) del VDC de proveedor.
Nota
El administrador de vCloud debe habilitar VDC de grupo de asignaciones elsticos. Esta es una
configuracin que se aplica en todo el sistema.
Las siguientes son consideraciones de diseo del centro de datos virtual de proveedor:
Aunque es posible mezclar los tipos de asignacin de VDC de organizacin con el VDC de
proveedor, esto complica la administracin de capacidad, especialmente cuando varios tipos de
asignacin tienen diferentes SLA de rendimiento.
Desde el punto de vista de la capacidad de administracin, VMware recomienda crear copias de

seguridad del VDC de proveedor con clsteres de vSphere. Tambin es posible dividir un clster en
varios grupos de recursos para asignarlos a diferentes VDC de proveedor. En este caso, establezca
manualmente el grupo de recursos para que vCloud Director conozca la cantidad de recursos que
puede consumir cada VDC de proveedor desde el clster subdividido de vSphere.
Cada zona de disponibilidad debe tener su propio VDC de proveedor. Esto permite la creacin de
VDC de organizacin especficos del sitio.
Los VDC de organizacin dedicados se crean en un clster dedicado del cliente dentro de un VDC
de proveedor dedicado del cliente.
Los VDC de proveedor elsticos permiten realizar una expansin perfecta (y posibles migraciones)
para VDC de organizacin de asignacin y de pago por uso.
Ante la creacin de cada VDC de proveedor, se crea automticamente un grupo de redes VXLAN
desde la que se aprovisionan las redes de VDC de organizacin y vApp. Cada grupo de redes
VXLAN est representado por el mbito de redes VXLAN que abarca clsteres de un VDC de
proveedor determinado. Un VDC de organizacin puede utilizar cualquier grupo de redes (siempre
que sea uno solo).
La preparacin de hosts no inserta el agente de vCloud en el host ESXi siempre y cuando no se

definan grupos de redes respaldadas mediante aislamiento de red de vCloud Director (vCloud
Director Network Isolation, VCDNI).

Pgina 48 de 78

7.1.1 Motor de seleccin

Cuando se crea una mquina virtual, el motor de seleccin la sita en el grupo de recursos de centro de
datos virtual de proveedor que mejor se ajusta a los requisitos de la mquina virtual. Se crea un grupo de
subrecursos para este centro de datos virtual de organizacin en el grupo de recursos de centro de datos
virtual de proveedor, y la mquina virtual se sita en ese grupo de subrecursos.
Al encender la mquina virtual, el motor de seleccin comprueba el grupo de recursos de centro de datos
virtual de proveedor para confirmar que sigue teniendo capacidad para encender la mquina virtual. En
caso contrario, el motor de seleccin mueve la mquina virtual a un grupo de recursos de VDC de
proveedor con suficientes recursos para ejecutarla. Se crea un grupo de subrecursos para el centro de
datos virtual de organizacin si an no hay uno. Si el movimiento requiere la transferencia de archivos de
mquina virtual, se utiliza la transferencia de protocolos de NFC sobre red de administracin o red de
aprovisionamiento (vSphere 6).
7.1.2 Niveles
Un nico centro de datos virtual de proveedor puede brindar varios niveles de almacenamiento
representados por directivas de almacenamiento y solo un nivel de proceso. El VDC de proveedor puede
expandirse a varios clsteres (grupos de recursos) de vSphere, pero est enlazado a una sola instancia
de vCenter Server.
Se crean varios VDC de proveedor por los siguientes motivos:
La nube requiere ms capacidad informtica que la que puede proporcionar una sola instancia de
vCenter Server.
Se requiere un proceso en niveles. Cada VDC de proveedor se asigna a clsteres de vSphere con
diferentes caractersticas (rendimiento o SLA).
Se requiere que las cargas de trabajo se ejecuten en una infraestructura fsica diferente (zonas de
disponibilidad).
7.2
Organizaciones
Las organizaciones son una unidad de varios tenants dentro de vCloud Director y representan un nico
lmite lgico de seguridad. Una organizacin de vCloud Director se asigna a un consumidor final. Las
organizaciones pueden utilizar cuentas locales de vCloud Director o integracin de LDAP directa (con
SSPI opcional) o pueden integrarse con SAML2 u OAuth (versin 8.0 de vCloud Director) con un
proveedor de identidad compatible (FS de AD, OpenAM, etc.).
Una organizacin administrativa se crea generalmente para proporcionar catlogos globales y
posiblemente otros servicios compartidos (servidores de concesin de licencias, repositorios de
revisiones, etc.).
El acceso del administrador de sistemas de vCloud Director se puede administrar mediante la
autenticacin LDAP o a travs de la federacin con el servicio vCenter Single Sign-On, que permite la
integracin perfecta de administracin entre vCloud Director y los objetos de vSphere. Si vCenter Single
Sign-On est federado, al intentar iniciar sesin, se redirige al administrador de sistemas de vCloud
Director a VMware vSphere Web Client para autenticarlo. Por lo tanto, se requiere una conectividad de
red adecuada para los administradores, no solo a vCloud Director, sino tambin a una instancia de
vSphere Web Cliente en particular.

Pgina 49 de 78

7.2.1 Administracin de usuarios

Las siguientes son consideraciones de diseo de administracin de usuarios:
Las cuentas locales de vCloud Director tienen opciones limitadas de aplicacin de directivas de
contraseas.
El usuario o el administrador de la organizacin pueden cambiar la contrasea del usuario solo si se

trata de una cuenta local de vCloud Director.
El administrador de sistemas es el encargado de ajustar la configuracin LDAP de la organizacin.

Las celdas de vCloud Director deben tener acceso de red a los servidores LDAP.
La integracin de SSPI de Active Directory permite el inicio de sesin nico de los tenants que ya
estn autenticados en el dominio de Active Directory.
El administrador de la organizacin puede configurar el proveedor de identidad SAML 2.0 (IdP). El

tenant puede utilizar su propio IdP (Active Directory) sin requerir conectividad de red entre las celdas
de vCloud Director y los servidores de IdP.
La autenticacin de OAuth 2.0 permite al usuario autenticarse con el token nico que proporciona el
proveedor de identidades externo. El proveedor del servicio puede revocar el derecho a configurar
OAuth del administrador de la organizacin y administrarlo a su nombre para la integracin del portal
de terceros o la federacin de varias instancias de vCloud Director.
Se pueden revocar los derechos del administrador de la organizacin para administrar usuarios. Esto
puede ser til si el proveedor administra cuentas en un proveedor de identidades centralizado y no
desea permitir que los tenants creen cuentas locales.
7.2.2 Autenticacin de OAuth

vCloud Director 8.0 agrega un proveedor de identidades nuevo: OAuth. OAuth simplifica la
administracin del acceso del usuario, particularmente en varios entornos federados de vCloud Director.
Flujo de trabajo tpico:
1. El administrador de sistemas habilita la organizacin de vCloud Director para la autenticacin de
OAuth.
2. El acceso del usuario a la organizacin y los roles se administran en el proveedor central de
identidades (por ejemplo, LDAP).
3. Cualquier usuario que desee acceder a una organizacin determinada debe primero autenticarse con
el proveedor central de identidades. El proveedor de identidades emite un token de OAuth2 portador
que da a cualquier persona que tenga acceso al recurso especfico.
4. El token de OAuth es una string de texto (https://tools.ietf.org/html/rfc7519) con tres secciones
delimitadas por un punto (.). La primera parte es el encabezado JWS (JSON Web Signature), la
segunda es el texto claims set (conjunto de notificaciones) y la tercera es la firma.
5. La seccin claims set debe contener el campo authz, que especifica a qu organizaciones tiene
acceso el usuario y bajo qu rol.
6. El usuario hace una llamada de API de vCloud a vCloud Director y pasa el token de OAuth en el
encabezado de autorizacin de la solicitud de API de HTTP junto con el nombre de la organizacin
de vCloud Director.
Authorization = Bearer <Base64 encoded OAuth Token>;org=<organization name>

Pgina 50 de 78

7. vCloud Director extrae el token y aplica la caducidad y la validacin de firma. Adems, recupera la
informacin de rol para establecer el contexto de seguridad de los usuarios. Se emite un token de
autorizacin de vCloud (x-vcloud-authorization), que se puede utilizar para solicitudes de API
posteriores o para el acceso al portal del explorador si el token est almacenado como una cookie
vcloud_session_id.
8. Si el usuario no existe en la organizacin de vCloud Director, se importa automticamente.
9. La llamada de API solicitada se realiza en el contexto de seguridad de usuarios correspondiente.
Nota
No es necesario que la llamada de API sea una solicitud de sesin de inicio (POST
/api/sessions). Puede ser cualquier solicitud de API. Por ejemplo, GET /api/session
devolvera un objeto de sesin que contendra el nombre de usuario y el vnculo de direccin
URL al objeto de la organizacin del usuario.
Tabla 9. Notificaciones de token de OAuth

Notificacin
Descripcin
Notas
jti
Identificador de token de OAuth
Se crea una sesin nueva si no existe an

una sesin asociada a jti
sub
Identificador del usuario que inicia

sesin
Identificador universal del asunto del token
email
Correo electrnico del usuario
uname
Nombre de usuario o UPN que utiliza

el usuario para iniciar sesin
nico, relacin 1:1 con el identificador de

usuario
cid
Identificador del tenant, empresa o

cliente al que pertenece el usuario
No se utiliza.
tvr
Versin del token de OAuth
vCloud Director admite solo la versin 2.0.
iat
Tiempo de emisin del token, en

segundos
El token se debe presentar una vez

transcurrido este tiempo o despus.
exp
Tiempo de caducidad del token en

segundos
El token se debe presentar antes de este

tiempo.
iss
Identificador del emisor del token
Se utiliza para comprobar que es el emisor

configurado quien emite el token.
authz
Representa el conjunto de roles para

cada instancia de servicio especfica.
instances
Instancias del servicio
Identificadores de organizacin
roles
Rol del usuario
Rol del usuario de vCloud Director

Pgina 51 de 78

La seccin authz debe tener el siguiente formato:
"authz" : {
"com_vmware_vchs_compute" : {
"instances": {
"34691574-7ccd-4fc1-b940-0bd2388bf3a5": {
"roles" : [
"Organization Administrator"
]
},
"48df38a4-aec8-4a34-b25a-b8f372bd8c33": {
"roles": [
"Organization Administrator"
]
}
}
}
}
Aqu, 34691574-7ccd-4fc1-b940-0bd2388bf3a5 y 48df38a4-aec8-4a34-b25ab8f372bd8c33 representan los identificadores de organizacin en los que el usuario tendr acceso con
el rol de administrador de la organizacin.
Nota
La string com_vmware_vchs_compute es obligatoria.
Las siguientes son consideraciones de diseo de la autenticacin de OAuth:
Mientras que una organizacin de vCloud Director puede utilizar varios proveedores de identidades
al mismo tiempo, un usuario de la organizacin se puede asociar con solo un proveedor de
identidades. Por ejemplo, no es posible que el mismo usuario inicie sesin mediante OAuth y la
autenticacin LDAP integrada.
El proveedor del servicio puede utilizar la autenticacin de OAuth para la federacin de varias
instancias de vCloud Director con el proveedor central de identidades, mientras que el tenant an
puede utilizar la autenticacin SAML para federar usuarios tenant con su instancia de Active
Directory de empresa (con Servicios de federacin [FS] de Active Directory). Los usuarios SAML no
existirn en el directorio central de identidades del proveedor.
Las herramientas externas que utilizan la API de vCloud (como vRealize Automation) y que
dependen de la autenticacin bsica no funcionarn con la autenticacin de OAuth. Para habilitar
OAuth, el proveedor del servicio debe implementar el siguiente proceso:
a. Interceptar llamadas de autenticacin de API (POST /api/sessions y /api/login).
b. Obtener el encabezado de autenticacin. Si no es una autenticacin bsica, pasarlo al endpoint
de la API de vCloud.
c.
Si se trata de un anlisis de autenticacin bsico y Base64, decodificar el encabezado para

obtener los valores <username>@<org>:<password>.
d. Utilizar los valores de credenciales para autenticarse con el proveedor de identidad central del
proveedor.

Pgina 52 de 78

e. Recuperar el token OAuth y reemplazar el encabezado de la autenticacin de la solicitud original
por el encabezado OAuth codificado de Base64 (Portador <OAuth-token>;org=<org>).
f.
7.3
Enviar la solicitud al endpoint de la API de vCloud.
Centros de datos virtuales de la organizacin
Un centro de datos virtual de la organizacin es un subgrupo de recursos informticos, de

almacenamiento y de red que residen en un centro de datos virtual del proveedor y se asignan a una
organizacin. Los centros de datos virtuales de la organizacin son entornos de implementacin en los
que se puede implementar y encender vApps, y crear instancias de ellas.
7.3.1 VDC de grupo de asignaciones no elsticas

Las siguientes son consideraciones de diseo de VDC de grupo de asignaciones no elsticas:
Se trata del mismo comportamiento heredado que el de vCloud Director 1.5 o versiones anteriores.
El VDC de organizacin del grupo de asignaciones est restringido por el tamao del grupo principal
de recursos (un clster de VDC de proveedor).
Una vez creada la instancia de VDC de organizacin del grupo de asignaciones no elsticas, se crea
un grupo de recursos secundario con lmites de CPU y memoria establecidos para la asignacin de
VDC de organizacin y reservas definidas para garantizar el valor de porcentaje x asignado.
El tenant no puede realizar una asignacin excesiva de memoria.
El tenant puede realizar una asignacin excesiva de vCPU (el uso de CPU est limitado por la
asignacin de CPU de VDC de organizacin).
7.3.2 VDC de grupo de asignaciones elsticas

Las siguientes son consideraciones de diseo de VDC de grupo de asignaciones elsticas:
La instancia de VDC de organizacin del grupo de asignaciones puede repartirte en varios grupos o
clsteres de recursos del VDC del proveedor.
Se debe especificar la velocidad de vCPU en GHz (el valor predeterminado es 1 GHz). Esta unidad
se utiliza para calcular la cantidad de vCPU que se podr implementar en VDC de organizacin
(asignacin (GHz)/velocidad (GHz) de vCPU).
El tenant no puede realizar una asignacin excesiva de memoria o vCPU.
Una vCPU no est limitada por la velocidad definida de vCPU, sino que, en realidad, las vCPU
comparten todos los GHz asignados.
7.3.3 VDC de pago por uso

El VDC de pago por uso proporciona capacidad confirmada instantnea a peticin. Los recursos (vCPU,
memoria y almacenamiento) se confirman solo cuando se crean instancias de las mquinas virtuales o
vApps dentro del VDC. Al tenant se le cobra solo segn los recursos confirmados (CPU y memoria para
mquinas virtuales encendidas, y almacenamiento para mquinas virtuales implementadas).
Se deben establecer lmites para el tamao mximo del VDC a fin de evitar un aumento repentino del
uso de recursos de un cliente, lo cual no permitira a otros tenants implementar mquinas virtuales
nuevas.

Pgina 53 de 78

7.3.4 VDC de tipo de reserva

Un VDC de tipo de reserva se utiliza para una oferta de servicio dedicado en el que el tenant obtiene sus
propios recursos informticos (clster de vSphere). El tenant puede establecer reservas, lmites y
recursos compartidos en el nivel de la mquina virtual, y administrar el exceso de suscripciones de
recursos.
El tamao mximo del VDC es la capacidad de clster que se puede utilizar (despus de quitar HA N+1 y
sobrecargas de hipervisores) menos los recursos necesarios para la implementacin de la puerta de
enlace Edge.
Las puertas de enlace Edge se pueden implementar en los grupos de recursos secundarios del VDC de
proveedor, que son tiles en escenarios de clsteres de NSX Edge (consulte la seccin 6.3.2.3, Opcin
de diseo 2b Clster combinado Edge/informtico con VDC no elstico). En este escenario, el clster
de las puertas de enlace Edge se puede compartir con varios VDC de proveedor diferentes si se lo divide
en grupos de recursos creados manualmente.
En la siguiente figura, el grupo de recursos principal de cada VDC de proveedor es un clster dedicado,
que puede estar compuesto por tan solo dos hosts. El clster de NSX Edge contiene varios grupos de
recursos pequeos, que se agregan a cada instancia de VDC de organizacin de reserva como grupos
de recursos secundarios.
Este diseo permite utilizar instancias de NSX Edge (activas o pasivas) con alta disponibilidad cuando un
tenant quiere adquirir clsteres de solo dos hosts y pagar la concesin de licencias de software (por
ejemplo, software de base de datos) de un host para utilizar el segundo nicamente como conmutacin
por error. En este caso, se establece el control de admisin de vSphere HA en el host de conmutacin
por error dedicado.

Pgina 54 de 78

Figura 22. Clster de Edge compartido para instancias de VDC de organizacin de reserva
VMware no recomienda el uso de un VDC de tipo de reserva en un clster compartido. El tenant puede
crear una mquina virtual arbitrariamente grande porque sus recursos informticos fsicos estn limitados
por el grupo de recursos de VDC de organizacin y no por los recursos de VDC asignados. (Por ejemplo,
dentro de una instancia de VDC de organizacin con 100 GB de RAM asignados, es posible encender
una mquina virtual con 200 GB de RAM). Si la memoria de la mquina virtual supera el lmite del grupo
de recursos, es muy probable que el host ESXi que ejecuta la mquina virtual intercambie la memoria
que no puede proporcionar por razones fsicas. Este intercambio puede crear mucha carga en el host y
su almacenamiento, y es posible que tenga un efecto negativo en las cargas de trabajo de otros tenants.

Pgina 55 de 78

7.4
Redes
Para admitir varios tenants, vCloud Director se integra con vCloud Network and Security o NSX Manager
a fin de administrar la creacin de redes de Capa 2 aisladas. Los grupos de puertos de vSphere crean
copias de seguridad de todas las redes creadas en vCloud Director. El acceso a redes de la nube se
controla con los enrutadores virtuales de NSX Edge.
7.4.1 Grupos de redes

Un grupo de redes contiene definiciones de red utilizadas para crear instancias de redes de VDC de
organizacin y vApp. Las redes creadas se deben aislar en la Capa 2 de todas las dems redes.
Cuando se crea el VDC de proveedor, se genera un grupo de redes VXLAN de forma automtica
siempre que el tejido VXLAN est preparado en la instancia de NSX Manager que controla vCenter de
VDC de proveedor.
Un grupo de redes VXLAN puede expandirse a varios conmutadores distribuidos si estos se administran
con una instancia de vCenter Server. La zona de transporte (mbito) de VXLAN se configura en NSX
Manager con vCloud Director de forma automtica cuando el VDC de proveedor se crea o se vuelve a
configurar con grupos de recursos de vSphere adicionales (clsteres).De forma predeterminada, la zona
de transporte de VXLAN siempre est en modo de plano de control de multidifusin.
Los grupos de redes basados en VLAN heredada, en grupos de puertos o en aislamiento de red de
vCloud Director (VCDNI) no se deben utilizar cuando se realiza un gran uso del proveedor de servicio, ya
que cuentan con una escala limitada.
7.4.2 Redes externas

Una red externa en vCloud Director es una red que proporciona conectividad externa a las organizaciones.
Cada red externa tiene una copia de seguridad en un grupo de puertos basado en VLAN o VXLAN en un
conmutador virtual con vnculos superiores a redes externas. Para poder crear la red externa, es
necesario hacer un aprovisionamiento previo del grupo de puertos.
Tenga en cuenta lo siguiente:
En vCloud Director 5.6 y versiones anteriores, en las que un grupo de puertos de un conmutador
lgico de la VXLAN creado manualmente se utiliza como red externa, se debe cambiar el nombre del
grupo de puertos para que no comience con la string vxw. Si comienza con dicha string, no aparece
visible en vCloud Director.
La opcin Permitir superposicin de redes externas se debe habilitar en la configuracin de vCloud

Director para aprovisionar varias redes externas basadas en VXLAN, ya que estas compartirn la
misma VLAN de transporte.
Si el conmutador lgico abarca varias instancias de vSphere Distributed Switch, varios grupos de
puertos harn una copia de seguridad de l. Se debe seleccionar el grupo de puertos correcto segn
las necesidades (por ejemplo, el grupo de puertos de vSphere Distributed Switch del clster
informtico).
Las redes externas se utilizan para proporcionar acceso a Internet, acceso dedicado a un servicio de
conexin directa o acceso a servicios compartidos (Syslog, concesin de licencias de sistema operativo y
revisiones).

Pgina 56 de 78

7.4.3 Redes de VDC de organizacin

Las redes de VDC de organizacin proporcionan a una organizacin una red privada a la que se pueden
conectar vApps. Los administradores de sistemas de vCloud crean redes de VDC de organizacin que
se conectan directamente a una red externa. Los administradores de la organizacin crean instancias de
redes de VDC de organizacin enrutadas o aisladas mediante los grupos de redes. De forma opcional,
las redes de VDC de organizacin se pueden compartir con otras instancias de VDC de organizacin de
la misma organizacin.
7.4.4 Redes de vApp

Las redes de vApp son redes que conectan mquinas virtuales dentro de una vApp. Estas redes no
pueden expandirse ms que una sola vApp. Entre las opciones de conectividad, se encuentran:
Aislado
Conectado a la red de VDC de organizacin (directa o enrutada)
Los usuarios finales determinan si colocarn la vApp detrs de una red de vApp. La mayora de las
vApps se conectan a redes de VDC de organizacin. Si el usuario final decide colocar barreras para una
vApp, la red de vApp se crea automticamente cuando se implementa la vApp.
7.4.5 Edges de vCloud Director

vCloud Director implementa mquinas virtuales Edge para proporcionar conectividad de red de VDC de
organizacin o vApp. La implementacin real se lleva a cabo mediante vCloud Networking and Security o
NSX Manager, pero es vCloud Director el que toma la decisin sobre la seleccin y configuracin de los
Edges. La puerta de enlace Edge de vCloud Director proporciona conectividad entre una o ms redes
externas de vCloud Director, y una o ms redes de VDC de organizacin. Se implementa dentro del VDC
de proveedor en un grupo de recursos de VDC de sistema especial de un almacn de datos que pertenece
a la directiva de almacenamiento predeterminada de VDC de organizacin. El motor de seleccin de
vCloud Director selecciona el clster ms adecuado en el que se puede implementar la mquina virtual
de la puerta de enlace Edge segn los clsteres que pertenezcan al VDC de proveedor, su capacidad
disponible y, lo que es ms importante, el acceso del que dispongan al almacenamiento y las redes
externas correspondientes.
Cada puerta de enlace Edge puede tener hasta 10 interfaces de red que, a su vez, pueden ser externas
o internas. Los administradores de la organizacin pueden configurar los servicios de red, como el
firewall, la NAT, el DHCP, la VPN, el enrutamiento esttico y el equilibrio de carga, en las puertas de
enlace Edge.
Las puertas de enlace Edge pueden ser de tres tamaos (compactas, completas y completas-4) y, de
forma opcional, estar en modo de alta disponibilidad (aplicacin activa-pasiva). Si se utiliza la
caracterstica de puerta de enlace Edge del equilibrador de carga, VMware recomienda utilizar una
configuracin completa o completa-4.

Pgina 57 de 78

Tabla 10. Tamaos de puertas de enlace Edge
Tamao de puertas de
enlace Edge
Consumo de recursos
Funcin recomendada
Compacta
256 MB de RAM, espacios en disco de

300 MB, 1 vCPU
Caso de uso estndar
Completa
1 GB de RAM, espacios en disco de 448 MB,

2 vCPU
Equilibrio de carga
Completa-4
4 GB de RAM, espacios en disco de 448 MB,

4 vCPU
Equilibrio de carga y
gran capacidad de
proceso
Tabla 11. Rendimiento de puertas de enlace Edge

Tamao de puertas de
enlace Edge
Capacidad de
proceso

compacta
3 Gb/s

completa
9,7 Gb/s
Los administradores de sistemas de vCloud subasignan direcciones IP externas en las redes de Internet.
Los administradores de la organizacin utilizan estas direcciones para configurar NAT para mquinas
virtuales internas a fin de permitir el acceso de entrada y salida de Internet.
Las instancias Edge de vApp proporcionan conectividad entre una red de VDC de organizacin y una red
de vApp. Siempre tienen solamente una interfaz externa y una interna. vCloud Director tambin
implementa en el grupo de recursos de VDC de sistema de VDC de proveedor, y existen solo cuando la
vApp est en modo implementado (encendida).
Las instancias de Edge de un solo brazo se implementan en redes de VDC de organizacin aisladas y,
de forma opcional, en redes de vApp a fin de proporcionar el servicio DHCP.
7.4.6 Ejemplo de caso de uso de una red de servicio

En la siguiente figura se muestra cmo se puede proporcionar de forma segura a los tenants los
servicios compartidos (repositorio de revisiones, servidores de administracin de licencias y registro).
Una red externa de vCloud Director se aprovisiona para la red de servicio con dos subredes asignadas a
ella. Una subred se utiliza para que las puertas de enlace Edge enven sus registros a un Syslog externo,
mientras que la otra se utiliza para la subasignacin de direcciones IP a la puerta de enlace Edge de
cada cliente con reglas NAT de origen preconfiguradas.

Pgina 58 de 78

Figura 23. Red de servicio
Para proporcionar acceso a los servicios compartidos y enviar los registros a Syslog:
1. Configure el Syslog externo para puertas de enlace Edge en vCloud Director desde Administracin >
Configuracin del sistema > General (IP b.b.b.1).
2. Subasigne una direccin IP al tenant desde la red externa. Subred A de servicios.
3. Cree de forma anticipada una regla SNAT de puerta de enlace Edge para esta direccin IP aplicada
en la red de registro a fin de llegar a los servicios en la organizacin de administracin (SNAT
0.0.0.0/0 > a.a.a.n).
4. Cree reglas DNAT en la puerta de enlace Edge para llegar a las mquinas virtuales de servicio
internas (DNAT a.a.a.4 > x.x.x.x, DNAT a.a.a.5 > y.y.y.y).
Los tenants ahora pueden consumir servicios compartidos (concesin de licencias y revisiones) en las
direcciones IP a.a.a.4 y a.a.a.5 mientras Syslog recibe solo registros de las puertas de enlace Edge.

Pgina 59 de 78

7.5
Almacenamiento
7.5.1 Instantneas
Los tenants pueden crear una instantnea de una vApp o una mquina virtual individual, incluido su
estado de ejecucin (memoria). Las siguientes son consideraciones de diseo de instantneas:
La instancia de VDC de organizacin requiere suficiente capacidad de almacenamiento libre para el

tamao mximo de la instantnea, que es igual al tamao total de los discos y la memoria
aprovisionados (si tambin se especifica una instantnea de memoria).
Al crear una instantnea, el rendimiento de E/S del disco se ve afectado. Con el tiempo, el tamao
de la instantnea aumenta, por lo que es algo que se debe tener en cuenta para la administracin de
capacidad. Adems, se deshabilitan las opciones de reconfiguracin de redes en la mquina virtual.
Es posible quitar la opcin "Crear, quitar y revertir una instantnea" de los roles de los tenants.
7.5.2 Aprovisionamiento rpido

El aprovisionamiento rpido ahorra tiempo al utilizar clones vinculados para las operaciones de
aprovisionamiento de la mquina virtual.
Un clon vinculado es un duplicado de la mquina virtual que utiliza el mismo disco base que el original,
con una cadena de discos delta para hacer un seguimiento de las diferencias entre el original y el clon. Si
el aprovisionamiento rpido est deshabilitado, todas las operaciones de aprovisionamiento generan
clones completos.
Es posible descargar la creacin de clones vinculados durante la copia de aprovisionamiento rpido o las
operaciones de clonacin en la matriz de almacenamiento:
Solo se admiten las matrices NFS.
El agente NAS se debe instalar en todos los hosts ESXi del grupo de recursos.
vSphere Storage APIs: se debe habilitar la integracin de matrices (Array Integration, VAAI) en la
matriz de almacenamiento. Es posible que la matriz requiera licencias adicionales para crear clones
rpidos.
La VAAI se debe habilitar en vCloud Director en todos los almacenes de datos o clsteres de
almacenes de datos.
Las siguientes son consideraciones de diseo de aprovisionamiento rpido:
Un clon vinculado no puede existir en otro almacn de datos que no sea la mquina virtual original.
vCloud Director crea mquinas virtuales instantneas para admitir la creacin de clones vinculados a
travs de instancias de vCenter Server y almacenes de datos para las mquinas virtuales asociadas
con una plantilla de vApp. Una mquina virtual instantnea es una copia exacta de la mquina virtual
original creada en el almacn de datos donde se crea el clon vinculado. Es posible ver una lista de
las mquinas virtuales instantneas asociadas con una mquina virtual de plantilla.
La creacin previa y automtica de mquinas virtuales instantneas en directivas de almacenamiento

diferentes o entornos de vCenter Server diferentes se puede configurar si se agrega la siguiente fila a
la tabla config de la base de datos de vCloud Director: valc.catalog.fastProvisioning=true.
Esta configuracin se aplica a todas las mquinas virtuales de catlogo de todas las organizaciones
y esto puede implicar una gran sobrecarga en la capacidad de almacenamiento. La creacin previa
se realiza cuando la mquina virtual se inserta en un catlogo y, despus de un da, se vuelve a
comprobar si el estado del almacn de datos cambia.

Pgina 60 de 78

Cuando se alcanza la longitud mxima de cadena (clon completo > clon vinculado > clon
vinculado > ), el siguiente clon pasa a ser un clon completo. La longitud predeterminada de la
cadena de clones vinculados de vSphere es 30. La longitud predeterminada de cadena VAAI es 256.
Si las matrices de almacenamiento admiten operaciones rpidas descargadas de clones de VAAI
con una longitud de cadena menor, la longitud de cadena VAAI se debe ajustar en la base de datos
de vCloud Director en la tabla config, fila VirtualMachine.AllowedMaxVAAIChainLength.
Nota
La cantidad de clones de un determinado clon completo no es limitada (la longitud de

cadena es solo 2).
Cuando se alcanza el umbral amarillo en un almacn de datos en particular, se dejan de crear clones
aprovisionados rpidamente. En su lugar, se aprovisiona un clon completo en otro almacn de datos.
El uso manual (activado por vSphere) de Storage vMotion de un clon vinculado crea un clon
completo.
El aprovisionamiento rpido de VAAI utiliza instantneas nativas de VAAI. Storage vMotion no se

puede utilizar en una mquina virtual con instantnea nativa. Toda reubicacin en otro
almacenamiento debe realizarse desde vCloud Director con la mquina virtual apagada.
A pesar de que la creacin de un clon vinculado de vSphere es bastante rpida, el rendimiento de

E/S depende de la longitud de la cadena. La escritura se realiza en un archivo delta, que se
desalinea en el nivel de almacenamiento y puede generar una sobrecarga de E/S de back-end. Las
lecturas pueden atravesar toda la cadena para buscar el bloque correcto y multiplicar las
operaciones de E/S necesarias de back-end.
Storage DRS admite clones vinculados de vSphere tanto para la seleccin como para el equilibrio.
Solo la seleccin funciona con el aprovisionamiento rpido de VAAI.
No es posible modificar el tamao de los discos de mquinas virtuales aprovisionadas rpidamente.

De ser necesario, el tenant puede agregar mquinas virtuales aprovisionadas rpidamente a su
catlogo y volver a implementarlas. La accin Agregar vApp desde catlogo permite modificar el
tamao de los discos.
El administrador del sistema vCloud puede crear un clon completo desde una mquina virtual
aprovisionada rpidamente con la accin Consolidar.
7.5.3 Umbrales en el almacn de datos

Existen dos umbrales en el nivel de almacn de datos o de clster de almacenes de datos:
Rojo: sin ms operaciones de aprovisionamiento en almacn de datos/clster de almacenes de datos
Amarillo: sin ms operaciones de aprovisionamiento rpido en almacn de datos/clster de

almacenes de datos
Debido a que las mquinas virtuales con aprovisionamiento rpido o fino y sus instantneas pueden
aumentar, es necesario disponer de suficiente reserva para evitar una condicin de falta de espacio en el
almacn de datos.
7.6
Catlogos
Los catlogos son el mecanismo de implementacin principal en vCloud Director, y sirven de repositorio
centralizado para las plantillas de vApp y los medios ISO. Los usuarios se autoaprovisionan vApps desde
plantillas de vApp ubicadas en catlogos internos o catlogos compartidos globales.

Pgina 61 de 78

Las siguientes son consideraciones de diseo de catlogos:
Los catlogos se pueden compartir, publicar y suscribir. Estos derechos se controlan con la
granularidad de la organizacin.
Los catlogos se pueden compartir con todas las organizaciones o con un subconjunto de ellas. Solo
un administrador del sistema vCloud puede compartir los catlogos con un subconjunto de
organizaciones, ya que este es el nico rol con acceso a la lista de organizaciones.
La publicacin de catlogos se puede utilizar para realizar copias intermedias de catlogos idnticos
compartidos globalmente entre los VDC de proveedor (instancias de vSphere) o las instancias de
vCloud Director (zonas y regiones de disponibilidad).
El mecanismo de publicacin-suscripcin de catlogos utiliza el almacenamiento compartido de

transferencias de las celdas de vCloud Director. Una exportacin anticipada de catlogos permite
mantener una copia de los catlogos exportados previamente en el almacenamiento compartido de
transferencias de la instancia de vCloud Director de origen. Esto aumenta la velocidad de
sincronizacin.
Es posible establecer una programacin de sincronizacin de catlogos (hora de inicio/detencin e

intervalos).
Los catlogos admiten el control de versiones.
Un catlogo se puede implementar con una directiva de almacenamiento en particular.
7.7
vApps
7.7.1 Descripcin general

Una vApp es un contenedor de una solucin de software y es la unidad estndar de implementacin en
vCloud Director. Contiene operaciones de encendido, consta de una o varias mquinas virtuales, redes
virtuales y metadatos, y se puede importar o exportar como un paquete de OVF.
Cuando se inicia una vApp, se implementan redes virtuales y mquinas virtuales, y se consumen
reservas del centro de datos virtual de la organizacin. El hecho de que una vApp se encuentre
parcialmente encendida significa que una o varias de sus mquinas virtuales se encuentran apagadas,
pero se siguen consumiendo redes y reservas. Una vApp en estado detenido libera todo menos los
recursos de almacenamiento.
7.7.2 Implementacin de vApps

Generalmente, el proveedor de servicios proporciona plantillas de vApp estandarizadas para sistemas
operativos invitados comunes en un catlogo de uso compartido global. Los tenants tienen la opcin de
crear sus propias vApps o importarlas mediante la importacin de OVF de vCloud Connector.
Las siguientes son consideraciones de diseo de implementacin de vApps:
Al crear una mquina virtual dentro de una vApp, se debe seleccionar el sistema operativo correcto
en las propiedades de la mquina virtual. Si se especifica mal el sistema operativo, el hardware
virtual presentado se ve afectado.
Se debe instalar VMware Tools para aprovechar la accin de apagado de sistema operativo
invitado y los scripts de personalizacin de invitado (asignacin de direccin IP y dems).
Los lmites de configuracin de mquinas virtuales se pueden aplicar mediante la tarea de bloqueo
(consulte el artculo de la base de conocimientos de VMware Aplicacin de lmite de CPU y memoria
para vCloud Director [CPU and Memory Limit enforcement for vCloud Director] en
https://communities.vmware.com/docs/DOC-21694.) (Los sitios web de terceros no son
responsabilidad de VMware y el contenido disponible en ellos puede variar).
Pgina 62 de 78

El estado de la vApp (memoria) se puede guardar en el catlogo. La vApp con un estado (en estado
suspendido) se puede mover entre los VDC de organizacin. Sin embargo, el estado no persiste
cuando se hace uso de la importacin y exportacin de OVF. (Esto tambin es vlido para las
migraciones de VDC de organizacin entre instancias de vSphere). vCloud Director no garantiza la
compatibilidad informtica (por ejemplo, la migracin entre un VDC de organizacin que se ejecuta
en una plataforma Intel y una plataforma AMD).
Solo es posible modificar el tamao de los discos SCSI. No se realiza ninguna extensin de la
particin de invitado. Los discos no se pueden reducir. Al modificar el tamao de un disco durante la
implementacin realizada desde el catlogo en un VDC de organizacin habilitado para
aprovisionamiento rpido, se crea un clon completo con mucho ms tiempo de implementacin.
No toda la configuracin adicional de OVF (consulte el artculo Configuracin de una lista blanca
para valores de configuracin avanzada de mquinas virtuales en vCloud Director [Configuring a
Whitelist for VM advanced settings in vCloud Director] en
http://www.virtuallyghetto.com/2014/05/configuring-a-whitelist-for-vm-advanced-settings-in-vclouddirector.html) es compatible con vCloud Director.
7.7.3 Personalizacin de invitado

vCloud Director admite la personalizacin de un sistema operativo invitado de mquina virtual durante la
implementacin o durante un cambio de configuracin de red. Se admiten las siguientes acciones:
Cambiar el nombre de equipo
Cambiar la contrasea raz o de administrador
Unirse a un dominio (solo en Windows)
Cambiar el identificador SID (solo en Windows)
Cambiar la configuracin de red
Ejecutar un script de personalizacin
Las siguientes son instrucciones para el diseo de personalizacin de invitado:
Las personalizacin de invitado puede habilitarse o deshabilitarse en el nivel de la mquina virtual.
VM Tools debe estar instalado para poder ejecutar la personalizacin de invitado.
La personalizacin completa de invitado se ejecuta una vez que se implementa una mquina virtual
desde un catlogo o cuando se ejecuta de forma explcita mediante la tarea Encender y forzar volver
a personalizar.
Cuando se cambia la configuracin de red (se agrega una NIC nueva a una mquina virtual o se
cambia la asignacin de una direccin IP), se realiza una personalizacin parcial de invitado despus
del siguiente encendido y se cambia solo la configuracin de red.
vCloud Director no admite IPv6 para la asignacin de direcciones IP de red.
La personalizacin de invitado de un sistema operativo Windows anterior (por ejemplo, 2003, XP,
etc.) requiere la instalacin adecuada de los archivos Sysprep en cada celda de vCloud Director.

Pgina 63 de 78

8.
Escalabilidad
Lograr una economa de escala significa escalar recursos de vCloud de forma consistente y previsible.
La separacin de los componentes de carga de trabajo de los clientes y de la administracin permite
usar el enfoque de escalamiento con bloques de creacin.
8.1
Grupo de recursos
Los clsteres de grupos de recursos ejecutan cargas de trabajo de tenants. Por lo general, un enfoque
de escalado vertical (un aumento de la capacidad informtica de los hosts ESXi) es viable solo al final de
la vida til de los componentes de hardware, cuando los hosts ESXi se reemplazan por hardware ms
nuevo y potente. El hardware de los clsteres de vSphere pertenecientes al VDC de un mismo proveedor
debe ser idntico y no combinado a fin de proporcionar una experiencia coherente al cliente y garantizar
la eficiencia de vSphere DRS. VMware recomienda usar un enfoque de escalado horizontal. vCloud
Director puede escalar sus recursos dentro de un clster, dentro de un lmite de vCenter o fuera de los
lmites de vCenter.
8.1.1 Escalabilidad de VDC de proveedor

Las cargas de trabajo de los clientes se ejecutan en los VDC de organizacin, que se aprovisionan
dentro de los VDC de proveedor. Los VDC de proveedor se asignan a grupos de recursos de vSphere o
a clsteres. Un VDC de proveedor se puede asignar a varios grupos de recursos o a un clster. Tambin
se puede crear un VDC flexible, excepto en el tipo de reserva de VDC de organizacin. Cuando un
cliente expande sus VDC de organizacin y solicita su extensin, la solicitud se puede aceptar solo si
existe capacidad disponible dentro de los VDC de proveedor. Si no existe capacidad disponible, se
separa un VDC de organizacin nuevo de otro VDC de proveedor, y es necesario aprovisionar el VDC
recientemente creado. Esto puede hacer que la implementacin de la mquina virtual de un cliente sea
ms difcil, ya que el cliente debe administrar la capacidad de varios VDC de organizacin.
8.1.2 Escalabilidad de clster

El lmite de clster de vSphere (HA/DRS) actual es de 32 hosts ESXi para vSphere 5.5 y de 64 para
vSphere 6. La escalabilidad de componentes adicionales (LUN de almacenamiento, puertos de red, etc.)
puede afectar los tamaos de los clsteres. El tamao mnimo de clster es de 2 hosts ESXi (con
redundancia N+1). Segn el ciclo de adquisicin de hardware nuevo, es posible preparar varios hosts
ESXi inactivos para agregar a cualquier clster determinado.
8.1.3 Escalabilidad dentro de vCenter

A pesar de que una red aislada o enrutada respaldada con VXLAN de vCloud Director puede expandirse
a varios conmutadores virtuales distribuidos, las redes de VDC de organizacin conectadas de forma
directa, que se asocian a una red externa (es decir, se acoplan al grupo de puertos de un conmutador
distribuido), no pueden hacerlo. La migracin en vivo de mquinas virtuales de un mismo VDC de
proveedor entre clsteres diferentes solo se puede realizar si las mquinas comparten el mismo
conmutador virtual distribuido.
8.1.4 Escalabilidad en sistemas vCenter Server

vCloud Director puede administrar hasta 20 sistemas vCenter Server. Para escalar de forma horizontal el
grupo de recursos, se deben agregar entornos de vSphere adicionales. Sin embargo, otros sistemas o
lmites de recursos pueden afectar la escala mxima.

Pgina 64 de 78

Nota
Las implementaciones desde catlogos o mediante el movimiento o la clonacin de vApps en

sistemas vCenter generan un proceso de copiado diferente al que se realiza en vCenter. El
proceso de copiado dentro de vCenter se realiza en los hosts ESXi directamente a travs de una
red de almacenamiento o mediante un protocolo de copia de archivo de red. El proceso de
copiado en los sistemas vCenter produce una exportacin de OVF que se aplica por etapas y se
copia con el almacenamiento de transferencias de celdas de vCloud Director. Este proceso es
mucho ms lento y afecta ms la infraestructura (ancho de banda de red, clculo de celdas de
vCloud Director y almacenamiento de transferencias).
8.1.5 Almacenamiento
Los almacenes de datos se asignan a los VDC de proveedor de vCloud Director mediante directivas de
almacenamiento de vSphere. Una forma fcil de escalar el almacenamiento es agregar nuevos
almacenes de datos a una directiva de almacenamiento en los clsteres que respaldan a los VDC de
proveedor. La cantidad mxima de almacenes de datos administrados de vCloud Director es 500.
8.1.6 Redes
La cantidad mxima admitida de redes externas es 750. Este valor puede afectar la cantidad de clientes
que se pueden conectar directamente y los casos de uso de puente de Capa 2 (consulte la seccin 6.3.6,
Otros servicios de red).
8.2
Todos los componentes de administracin de vCloud Director se deben colocar dentro de sus propios
clsteres ESXi administrados por su propia instancia de vCenter Server. Se pueden escalar
independientemente de los sistemas vCenter Server de grupos de recursos.
8.2.1 Base de datos de vCloud Director

Siempre existe una sola instancia de la base de datos de vCloud Director por instancia de vCloud Director.
Se debe supervisar su uso, tamao y requisitos de E/S de almacenamiento, y se deben aprovisionar ms
recursos a medida que se expande vCloud Director. Se admite la agrupacin en clsteres de Microsoft
SQL (u Oracle RAC).

Se puede disponer de varias celdas de vCloud Director para el equilibrio de carga y la alta disponibilidad.
La cantidad mxima admitida es 10 celdas. La cantidad mnima recomendada es 2 o N+1, en donde N es
la cantidad de sistemas vCenter Server de grupos de recursos. Si los usuarios de vCloud Director utilizan
mucho las transferencias de OVF o VMware Remote Console, el uso de celdas de vCloud Director
puede verse afectado, por lo que se debe considerar la implementacin de instancias nuevas. En el caso
de una gran cantidad de sistemas vCenter Server con una pequea cantidad de mquinas virtuales, se
puede utilizar la siguiente frmula:
Cantidad de instancias de celdas = n/3000 +1, en donde n es la cantidad esperada de mquinas virtuales
encendidas.
8.2.3 NSX Manager

Siempre existe una relacin de uno a uno entre el sistema vCenter Server de grupos de recursos y NSX
Manager. Al agregar un sistema vCenter Server de grupos de recursos, se implementa un dispositivo
virtual NSX Manager nuevo. Los recursos virtuales de ese dispositivo NSX (CPU y memoria) se pueden
aumentar, especialmente en entornos con un gran conjunto de puertas de enlace Edge.

Pgina 65 de 78

8.2.4 vCenter Chargeback

Una instancia de vCenter Chargeback Manager se puede conectar con hasta 10 sistemas vCenter
Server. Una instancia de vCenter Chargeback puede estar compuesta por varios servidores vCenter
Chargeback con carga equilibrada y varios recopiladores de datos (activos/pasivos). La base de datos de
vCenter Chargeback almacena todos los datos de uso, y se aplican los mismos criterios para la base de
datos de vCloud Director.
8.2.5 vCloud Usage Meter

De forma similar a vCenter Chargeback, VMware vCloud Usage Meter puede conectarse con hasta 10
instancias de vCenter Server diferentes. Puede medir datos de hasta 10.000 mquinas virtuales. El lmite
flexible de vCloud Director es de 20.000 mquinas virtuales. Por lo tanto, es posible que se requiera la
implementacin de ms instancias de vCloud Usage Meter si se alcanza el lmite de mquinas virtuales.
8.3
Federacin de vCloud Director
A pesar de que una sola instancia de lmites de escalabilidad de vCloud Director puede ser suficiente
para los proveedores de servicios pequeos, VMware recomienda crear una federacin de varias
instancias de vCloud Director (esto se describe en la seccin 3.1.3, Regiones mltiples de IaaS) para
proveedores de servicios ms grandes, particularmente debido a la separacin de los dominios de
errores lgicos.

Pgina 66 de 78

9.
Capacidad de recuperacin
9.1
Descripcin general
La continuidad empresarial y la recuperacin ante desastres son un componente fundamental de toda

implementacin de nube. VMware vCloud Director establece nuevos desafos debido a la capa de
abstraccin adicional y los metadatos de vCloud Director asociados. A pesar de que los componentes de
administracin se pueden proteger con un mecanismo estndar (VMware Site Recovery Manager o una
solucin de copia de seguridad de terceros compatible con VMware), se requiere coordinacin entre el
software de proveedor de copia de seguridad, vCenter Server y vCloud Director para completar la
restauracin de los objetos administrados por vCloud Director. Esto implica una integracin mediante
vSphere API, vCloud API y VMware vSphere Storage APIs - Data Protection (VADP).
9.2
Para la administracin de vCloud, se pueden utilizar los mtodos tradicionales para crear copias de
seguridad de mquinas virtuales y fsicas. En la siguiente tabla se enumeran las opciones de copias de
seguridad para varios componentes.
Tabla 12. Copia de seguridad de componentes de administracin
Elemento
Notas
Celdas de vCloud
Director
Copia de seguridad de nivel de figura de la celda de vCloud Director (sin

estado).
Proteccin de archivos confidenciales (global.properties y
responses.properties en el directorio $VCLOUD_HOME/etc/) y de
certificados.
Copias de seguridad de la base de datos de vCloud Director.
NSX Manager
Copia de seguridad de la configuracin y la base de datos de NSX en un

sitio FTP o SFTP mediante la opcin de interfaz de usuario integrada de
NSX Manager.
vCenter Chargeback
Copia de seguridad de nivel de figura de los servidores vCenter Chargeback.

Copias de seguridad de la base de datos de vCenter Chargeback.
Instancias de vCenter
Server
Copias de seguridad de nivel de figura de los sistemas vCenter Server.
Bases de datos
Prcticas recomendadas de creacin de copias de seguridad de bases de

datos del proveedor de bases de datos.
Hosts ESXi
Perfiles de host de vCenter.
Nota
Copias de seguridad de las bases de datos de vCenter Server, junto con

Inventory Service.
La restauracin de todos los componentes debe realizarse en el mismo punto en el tiempo para
evitar inconsistencias que se deban resolver manualmente.

Pgina 67 de 78

9.3
Cargas de trabajo de tenants
El proveedor puede ofrecer la creacin de copias de seguridad como un servicio para las cargas de
trabajo de los tenants. Se deben utilizar soluciones de copia de seguridad de terceros compatibles con
vCloud Director para crear copias de seguridad adecuadas de las mquinas virtuales y los metadatos de
vCloud Director asociados. Este servicio se muestra en el portal de ese tercero o en extensiones de API
de vCloud.

Pgina 68 de 78

10. Seguridad
10.1 Instrucciones
Las prcticas recomendadas para la seguridad incluyen las siguientes tareas:
Identificar y deshabilitar funcionalidades y software innecesarios.
Identificar interfaces innecesarias o no deseadas (VMCI).
Quitar todas las cuentas innecesarias.
Deshabilitar los servicios de red innecesarios.
Realizar auditora de la lista de puertos abiertos y sus usos.
Fortalecer la seguridad de las mquinas virtuales.
10.1.1 Administracin y cifrado de claves

vCloud Director requiere el cifrado HTTPS para todas las comunicaciones de servidor a cliente. El
puerto 80 permanece abierto, pero solo redirecciona la conexin al puerto de conexin seguro. La
interfaz de usuario de vCloud Director se protege con SSL sobre HTTPS (puerto 443/TCP). El
certificado se instala durante la configuracin de vCloud Director y se cifra en el archivo ubicado en
$VCLOUD_HOME/etc/certificates. Este archivo se protege con el valor system.info en el archivo
global.properties ubicado en $VCLOUD-HOME/etc.
La conexin proxy de consola tambin se protege con SSL en el puerto 443/TCP. Durante el inicio de la
conexin, se pasa una clave al explorador para autenticar la sesin de la consola en el proxy de consola.
Esta clave viene con una fecha de caducidad para mitigar los ataques de reproduccin.
Los certificados SSL se deben crear con una longitud de clave de al menos 2048 bits. El archivo de
almacn de claves que se utilice para configurar los certificados se debe proteger con una contrasea
compleja y, una vez completada la configuracin, se debe quitar de las celdas de vCloud Director.
La comunicacin de la base de datos de vCloud Director se enva en texto sin formato mediante una
conexin por cable. Por lo tanto, se debe restringir el acceso a la red.
Cuando se utiliza la autenticacin LDAP integrada, la comunicacin con el servidor debe utilizar LDAP
seguro cifrado (LDAPS) para evitar el acceso a las credenciales de usuario, ya que estas se transmiten
en texto sin formato.
La comunicacin de las celdas de vCloud Director con vCenter Single Sign-On (PSC), vCenter Server y
NSX Manager se cifra. Adems, para aumentar la seguridad, es posible cargar certificados de cada
componente mediante el archivo de almacn de claves JCEKS.
10.1.2 Archivos confidenciales de configuracin de vCloud

Las instalaciones de vCloud Director contienen datos confidenciales en la siguiente ubicacin:
$VCLOUD_HOME/*.properties.
El archivo global.properties contiene una copia segmentada de la contrasea de la base datos de
vCloud Director, como tambin una cadena creada de forma aleatoria que se utiliza para descifrar cierta
informacin de configuracin contenida dentro de la base de datos y el archivo de certificados.
El archivo de certificados contiene claves privadas y pblicas de los certificados SSL para los servicios
HTTP y de proxy de consola en un formato cifrado.

Pgina 69 de 78

10.1.3 Firewall de aplicacin web

La direccin URL web de administracin de vCloud Director y la direccin URL de la API de REST se
pueden filtrar de Internet en el nivel de equilibrador de carga para permitir la administracin nicamente
desde redes internas y para deshabilitar los ataques externos.
10.1.3.1.
Portal web
Los tenants acceden a la interfaz de usuario web con la siguiente direccin URL:
https://<vcloud_domain>/cloud/org/<company_name>, en la que <company_name> es el nombre corto
de la organizacin.
Los administradores de vCloud Director utilizan la siguiente direccin URL: https://<vcloud_domain>/cloud/.
Tabla 13. Direcciones URL de portal web permitidas por el firewall de aplicacin web
Direcciones URL permitidas
/cloud/transfer/.*
/cloud/org/.*
/cloud/vmrc/.*
/transfer/.*
10.1.4 API de vCloud

La API de VMware vCloud proporciona soporte para desarrolladores que compilan clientes interactivos
de vCloud Director mediante el estilo de desarrollo de aplicaciones RESTful. Los clientes de API de
vCloud y los servidores vCloud Director se comunican por HTTPS para intercambiar representaciones de
los objetos de vCloud. Algunas de las aplicaciones de ecosistemas VMware vCloud en las que se utiliza
la API de vCloud son vRealize Orchestrator (con el complemento de vCloud Director), VMware vSphere
PowerCLI, vCenter Chargeback (el recopilador de datos de vCloud Director), vCloud Connector,
vRealize Automation y vRealize Operations Manager (con el paquete de administracin de vCloud).
Actualmente, existen varias versiones de la API de vCloud, desde la versin 0.9 hasta la 9.0 (a partir de
la versin 8.0 de vCloud Director). Las versiones de la API de vCloud compatibles se pueden recuperar
de https://<vcloud_domain>/api/versions.
Solo se puede exponer a Internet un conjunto limitado de API. Se debe permitir el acceso a las llamadas
API de los tenants, ya que esas llamadas se relacionan con las operaciones de usuario y administrador
de la organizacin (mbito de usuario), y son necesarias para las aplicaciones de ecosistema que utilizan
las API de vCloud. Las llamadas API adicionales relacionadas con las operaciones de proveedor deben
exponerse solo a administradores de vCloud (mbito de proveedor). Los mbitos de usuario y de
proveedor se pueden separar en funcin de las direcciones IP de origen. El acceso desde Internet
permite usar solamente las API del mbito de usuario, mientras que el acceso desde un grupo definido
de direcciones de proveedores de servicios permite usar las API del mbito de proveedor.
El firewall de aplicacin web (Web Application Firewall, WAF) se debe usar para filtrar el acceso URL
segn el mbito. Este firewall finaliza la sesin SSL de cliente, examina el contenido y, segn las reglas
de filtros, permite o rechaza la sesin. Si la permite, se crea otra sesin SSL con carga equilibrada entre
el WAF y una celda de vCloud Director.
Nota
Todas las llamadas API excepto /api/versions y /api/sessions se deben autenticar, y el control de
acceso se aplica segn los privilegios de la cuenta.
Pgina 70 de 78

10.2 Registro de auditora

vCloud Director almacena un registro de actividad en la base de datos de vCloud Director. Los ltimos 30
das de datos de registro sobre actividad relevante se encuentran disponibles para los tenants.
Utilice los servidores de Syslog externos para redirigir los registros relevantes para fines de auditora y
solucin de problemas. Se puede utilizar vRealize registro Insight, ya que es una solucin escalable de
nivel empresarial para recopilar datos de registro mediante protocolos de Syslog tradicionales o con
agentes tanto de Linux como de Windows. Esta solucin proporciona paneles integrados para realizar
anlisis rpidos de datos recopilados para vSphere, vCloud Director, VMware NSX, SQL y otras
soluciones.
Los registros de puertas de enlace Edge pueden recopilarse con un proveedor en un servidor de Syslog
central, al que se pueda acceder a travs de una red externa de vCloud Director (consulte la seccin
7.4.5, Edges de vCloud Director), o en un servidor de Syslog de tenant (disponible en la API de vCloud
desde la versin 5.9).
POST /admin/edgeGateway/{id}/action/configureSyslogServerSettings.
10.2.1 Ubicaciones de los registros

Entre las ubicaciones de los registros, se encuentran:
Celdas de vCloud Director
vCenter Chargeback Manager
10.2.1.1.
Celdas de vCloud Director
En la siguiente tabla se enumeran las ubicaciones y los tipos de registros de las celdas de vCloud
Director.
Tabla 14. Registros de celdas de vCloud Director
Tipo de log
Ubicacin
Mtodo de recopilacin
Informacin de
vCloud Director y
registros de
depuracin
%VCLOUD%/logs/*
Recuperacin peridica (la mayora de los

registros se rotan con las extensiones .1, .2) %VCLOUD%/logs/vcloudcontainerdebug.log y %VCLOUD%/logs/vcloudcontainer-info.log. Si bien no son para
uso general, estos registros se pueden
redireccionar a Syslog mediante la
modificacin
de %VCLOUD%/etc/log4j.properties.
Eventos de vCloud
Director que se
pueden enviar a
Syslog
Enviado a travs de
Syslog
Establecer destinos de Syslog en:
Registros del
sistema vCloud
Director
Ubicaciones estndar de
los registros de Linux:
%VCLOUD%/etc/global.properties y
%VCLOUD%/etc/responses.properties;
Destinos de Syslog mediante syslog.conf
o recuperacin de agentes.
/var/log/messages
/var/log/secure

Pgina 71 de 78

Tipo de log
Ubicacin
Mtodo de recopilacin
Registros de acceso
web a API
%VCLOUD%/logs/*.re
Recuperacin peridica (registros

organizados por fecha, por ejemplo,
2015_07_09.request.log).
quest.log by date
Los registros relacionados con un cliente se pueden identificar mediante el identificador de organizacin
correspondiente. Una parte de una entrada de registro de vCloud Director contiene:
currentContext.login.org.id=###
Por ejemplo:
Jul 05 11:53:56 Event [id=1e523973-0620-4dc3-8ffc-865c0d4c61c1,
timestamp=1341442436853, type=com/vmware/vcloud/event/task/complete, properties={
currentContext.org.name=ACME,
currentContext.user.id=acmeadmin(com.vmware.vcloud.entity.user:3ec7999f-d732436c-bfd4-4919228c5146),
entity.type=com.vmware.vcloud.entity.task,
currentContext.login.user.id=com.vmware.vcloud.entity.user:3ec7999f-d732-436cbfd4-4919228c5146,
currentContext.user.name=acmeadmin,
currentContext.login.member.id=acmeadmin(com.vmware.vcloud.entity.user:0c9ec4a6
-351d-40da-94a8-0209b73393cd),
currentContext.o...<13>...rg.id=ACME(com.vmware.vcloud.entity.org:3c8970fb3b5b-482a-8056-b229744ad6f8),
task.ownerId=659e986c-21d5-49ed-b718-8a8d38e99811,
currentContext.success=true,
currentContext.login.org.id=com.vmware.vcloud.entity.org:3c8970fb-3b5b-482a8056-b229744ad6f8,
task.ownerType=com.vmware.vcloud.entity.vapp,
currentContext.user.clientIpAddress=,
task.name=VAPP_DEPLOY,
entity.name=VAPP_DEPLOY,
entity.id=VAPP_DEPLOY(com.vmware.vcloud.entity.task:f74b4e85-2608-4af6-b71030d62464a16f),
currentContext.cell.uuid=5252de5b-0a3c-4e75-822f-cbd9604b18f0,
currentContext.user.proxyAddress=,
10.2.1.2.
vCenter Chargeback Manager
En la siguiente tabla se enumeran las ubicaciones y los tipos de registros de vCenter Chargeback
Manager.

Pgina 72 de 78

Tabla 15. Registros de vCenter Chargeback Manager
Tipo de registro
Ubicacin
Mtodo de
recopilacin
Eventos del
sistema Windows
registro de seguridad de Windows
Syslog remoto
Eventos de la
aplicacin
Chargeback
%ProgramFiles%\VMware\VMware vCenter
Chargeback\apache-tomcat\logs
Se archiva en un
recurso compartido
de archivos central
LB de
Chargeback
Chargeback\Apache2.2\logs
Se archiva en un
recurso compartido
de archivos central
Recopilador de
datos
Chargeback\DataCollector-Embedded\logs
Se archiva en un
recurso compartido
de archivos central.
El proceso de
archivado almacena
registros de forma
diaria.
Recopilador de
datos
independiente de
vCloud
Chargeback VMware Cloud Director
DataCollector\\logs
Se archiva en un
recurso compartido
El proceso de
archivado almacena
registros de forma
diaria.
Instalador
Chargeback\DataCollector-Embedded\logs
Se archiva en un
recurso compartido
El proceso de
archivado almacena
registros de forma
diaria.
10.2.1.3.
Puertas de enlace Edge
Las direcciones IP de servidores de Syslog para puertas de enlace Edge se crean principalmente
mediante vCloud Director, al igual que para todos los Edges (puertas de enlace Edge o Edges en redes
de vApp). En vCloud Director 8.0, el tenant puede configurar su propio servidor de Syslog en su puerta
de enlace Edge mediante la API de vCloud.

Pgina 73 de 78

Tabla 16. Registros de puertas de enlace Edge
Tipo de registro
Ubicacin
Mtodo de
recopilacin
Eventos de regla vSE. Estos son

interacciones con reglas de firewall
con la casilla registro activada.
No corresponde
Syslog remoto
Un registro de puerta de enlace Edge presenta el siguiente formato:

<Date-Time><Edge-ID><program/daemon-Name>[[PID]:][[Tenant/OrganizationID]] : [EdgeService/Action-Identifier] <Message>
Por ejemplo:
Nov 26 12:29:42 vse-d61f13c3-b56e-42b7-9de3-f55e07f5a19a-0 firewall[]:
[3c8970fb-3b5b-482a-8056-b229744ad6f8]: ACCEPT_1IN= OUT=vNic_0 SRC=10.0.2.71
DST=77.75.72.3 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8
CODE=0 ID=23042 SEQ=135 MARK=0x2
Tabla 17. Formato de registro de puerta de enlace Edge
Nombre de campo
Descripcin
Fecha y hora
Fecha y hora en formato: mes da HH:MM:SS (por

ejemplo: sep 5 10:50: 56).
Identificador de Edge
Identificador nico de Edge proporcionado por NSX

Manager (no vCloud Director).
Programa/Nombre de daemon
Nombre para el daemon o el programa que registra este

mensaje (por ejemplo: dhcp, kernel, pluto, nginx).
PID
PID para el programa que registra este mensaje. Este

elemento es opcional, especialmente para mensajes
relacionados con kernel/iptables. El PID no se registra.
Tenant/Identificador de organizacin
Este es el identificador de la organizacin.
Servicio Edge/Identificador de
accin
Esto es opcional. Para algunos mensajes de registro (en

los que el nombre de daemon no especifica de forma
nica EdgeService), el identificador de servicio es el
prefijo del mensaje de registro (por ejemplo: DNAT,
SNAT, Firewall-policyapplied-to-rule=ACCEPT|DROP).
Mensaje
Este es el mensaje de registro real.
El servidor de Syslog agrega la direccin IP correspondiente al remitente de Syslog que es la puerta de

enlace Edge con la que se registra la interfaz externa de red.

Pgina 74 de 78

11. Consideraciones operativas

11.1 Supervisin de vCloud Director
La supervisin de vCloud Director se realiza mediante consultas personalizadas a vCloud Director a
travs de la API de administrador para recuperar datos de consumo en diversos componentes de vCloud.
Es posible hacer uso de vCloud Director Audit (https://blogs.vmware.com/vsphere/2012/03/auditreporting-with-vcloud-director.html) o herramientas similares basadas en PowerCLI. Se puede utilizar
vRealize Operations junto con el paquete de administracin de vCloud Director para proporcionar
paneles de uso de rendimiento y capacidad tanto para contextos de proveedor como de tenant.
11.1.1 Supervisin de los servicios de vCloud

El estado de los siguientes servicios se debe supervisar con una solucin empresarial de supervisin.
Tabla 18. Supervisin de celdas de vCloud Director
Parmetro
Motivo de la supervisin
Interrupcin de proceso
Compruebe que los siguientes procedimientos estn en ejecucin.
Espacio en disco utilizado
vmware-vcd
vmware-vcd-watchdog
Espacio libre disponible en $VCLOUD_HOME/data/transfer

Espacio libre disponible en $VCLOUD_HOME/logs/
Estado de puerto
Los siguientes puertos TCP deben estar respondiendo:
80 (redireccionamiento HTTP a Portal/API de HTTPS)
443 (Portal/API de HTTPS)
443 (proxy de VMRC)

Pgina 75 de 78

Tabla 19. Supervisin de vCenter Chargeback
Parmetro
Motivo de la supervisin
Interrupcin de proceso
Compruebe que los siguientes procedimientos estn en ejecucin.
vCenter Chargeback
Equilibrador de carga de vCenter Chargeback
Recopilador de datos integrado de vCenter Chargeback
De forma opcional, recopilador de datos de vCenter Chargeback
De forma opcional, vCenter Chargeback: Recopilador de datos

de VMware Cloud Director
VMware vCenter Chargeback: Recopilador de datos integrado

de vShield Manager
De forma opcional, vCenter Chargeback: Recopilador de datos

de vShield Manager
Espacio en disco utilizado
Compruebe que no se utilice ms del 90% del espacio disponible en

cada particin NTFS.
Estado de puerto
Compruebe que los siguientes puertos TCP respondan las

solicitudes:
8080 (http)
8009 (equilibrador de carga)
443 (https)
11.1.2 Supervisin de registros de vCloud

De forma predeterminada, todos los registros de celdas de vCloud Director se encuentran en
$VCLOUD_HOME/logs. La configuracin de los registradores que generan algunos de los archivos de
registro se almacena en el archivo $VCLOUD_HOME/etc/log4j.properties. Es posible configurar
registradores adicionales para redirigir los registros a soluciones de registro externas. Consulte el artculo
de la base de conocimientos de VMware Habilitar el registro centralizado en VMware vCloud Director
[Enabling Centralized Logging in VMware vCloud Director] en http://kb.vmware.com/kb/2004564.
Tabla 20. Registros de vCloud Director
Nombre del log
Descripcin
cell.log
Salida de la consola de las celdas de vCloud Director.
vcloud-container-debug.log
Mensajes de registro en el nivel de depuracin de la celda.
vcloud-container.info.log
Mensajes de registro de informacin de la celda. Este

registro tambin muestra advertencias sobre errores que
detecta la celda.

Pgina 76 de 78

Nombre del log
Descripcin
vcloud-console-debug.log
Mensajes de registro de nivel de depuracin generados en

el proceso de proxy de consola remota de las celdas.
statsfeeder.log
Recuperacin de mtricas de mquinas virtuales (de

vCenter Server) y mensajes informativos y de errores de
almacenamiento (KairosDB).
cell-management-tool.log
Mensajes de registro de la herramienta de administracin de

celdas de la celda.
vmware-vcd-watchdog.log
Mensajes de registro de informacin generados por el

Watchdog de la celda. Se registra el momento en que se
produce un error en la celda, se reinicia la celda, etc.
diagnostics.log
Registro de diagnsticos de celda. Este archivo permanece

vaco a menos que se habilite el registro de diagnsticos en
la configuracin local de registro.
YYYY_MM_DD.request.log
Registro de solicitud de API de vCloud
Cada celda de vCloud Director expone varios MBeans a travs de Java Management Extension (JMX)
para administrar las operaciones en el servidor y proporcionar acceso a las estadsticas internas. Se
puede utilizar cualquier cliente para acceder al servicio JMX de vCloud Director (por ejemplo, JConsole).
Para obtener ms informacin sobre MBeans expuesto, consulte el artculo de la base de conocimientos
de VMware MBeans de vCloud Director en http://kb.vmware.com/kb/1026065.
11.1.3 Sincronizacin de hora

La sincronizacin de hora es importante para los siguientes escenarios:
Se produce un evento en el que se requiere la reconstruccin de otros eventos pasados con

respecto a la hora.
Un evento no se produce por depender de otros eventos que se deban haber ejecutado en una
secuencia de tiempo especfica, pero no lo hicieron debido a una falta de sincronizacin de hora o
una hora incorrecta.
La capacidad para reconstruir eventos pasados de componentes de infraestructura relacionados ofrece a

los administradores la oportunidad de analizar problemas e implementar acciones correctivas efectivas.
La sincronizacin de NTP con un origen de capa de estrato comn en la zona de administracin se
configura para todos los hosts ESXi y los componentes de vCloud. Para las mquinas virtuales, se debe
utilizar v32time para Windows y NTP para Linux.
11.2 Revisiones de VMware vCloud Director

La administracin de actualizaciones es un factor clave para mantener el estado, el rendimiento y la
seguridad de la infraestructura de nube. Mantener una infraestructura actualizada puede ser una tarea
abrumadora para los administradores de TI, que deben rastrear con frecuencia los niveles de revisin y
aplicar correcciones de seguridad. Sin embargo, toda la infraestructura entra en riesgo si las
actualizaciones no se realizan de forma fiable y regular.

Pgina 77 de 78


Las revisiones de las celdas de vCloud Director se agregan manualmente mediante la ejecucin de un
archivo ejecutable. Antes de la actualizacin, se debe poner la celda en modo inactivo y activar el modo
de mantenimiento con la herramienta de administracin de celdas. Si la actualizacin requiere un cambio
de esquema de base de datos, el script que actualiza la base de datos se debe ejecutar nicamente en
una celda de la instalacin de vCloud Director. Se requiere tiempo de inactividad para todo el entorno de
vCloud Director.
11.2.2 Instancias de NSX Manager y NSX Edge

Las revisiones de NSX Manager se establecen de forma manual al cargar un archivo de revisin en el
dispositivo.
Las instancias de NSX Edge existentes se pueden actualizar manualmente al restablecer la red de vApp
de NSX Edge o volver a implementar la puerta de enlace Edge en la interfaz de usuario de vCloud
Director. Actualmente, no se admite la actualizacin de la versin 5 de NSX Edge a la versin 6 mediante
NSX Manager (desde vCloud Director 8.0).
La actualizacin de instancias de NSX Controller y componentes VIB de host ESXi se realiza dentro de la
interfaz de administracin de NSX.

Pgina 78 de 78

Architecting A VMware VCloud Director Solution

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Architecting A VMware VCloud Director Solution

Загружено:

Авторское право:

Доступные форматы

VMware vCloud Architecture Toolkit

for Service Providers

VMware vCloud Architecture Toolkit for Service Providers

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

Descripcin de la tecnologa ............................................................. 8

Consideraciones sobre el modelo de implementacin .................... 12

Descripcin general de la arquitectura ............................................ 17

Componentes de administracin de la nube ................................... 18

Diseo del proveedor de vCloud ..................................................... 47

VMware vCloud Architecture Toolkit for Service Providers

Capacidad de recuperacin ............................................................ 67

Consideraciones operativas ........................................................ 75

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

Servicio de nube basado en vSphere y VMware vCloud Director

API de usuario de VMware vCloud expuesta a tenants de nube

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

VMware vCenter Chargeback para mediciones e informes de uso. La API de vCenter

VMware vRealize Operations Manager para supervisin y anlisis de rendimiento y capacidad.

VMware vRealize Hyperic para servicios de supervisin de componentes de administracin.

VMware vRealize registro Insight para administracin y anlisis centralizado de registros.

VMware vRealize Orchestrator para servicios de extensin o tareas de automatizacin recurrentes

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

Grupo de recursos asignados para los cuales se garantiza un

Un solo dominio de errores para recursos.

Repositorio de plantillas y elementos multimedia de vApp

Recursos de nube dedicados a un tenant en una infraestructura

Puerta de enlace Edge

Dispositivos virtuales para brindar seguridad en el permetro de

Las redes externas ofrecen conectividad de Internet a redes de

Recursos virtuales y fsicos dedicados a funciones de

Recopilaciones de redes virtuales de Capa 2 aisladas a las que

Recursos de nube confirmados para el tenant que se facturan

Unidad multitenant que representa un solo lmite de seguridad

El administrador de una organizacin de vCloud Director,

Las instancias de redes de VDC de organizacin se crean a

VMware vCloud Architecture Toolkit for Service Providers

Centro de datos virtual de

Subgrupo de recursos informticos, de red y de

Pago por uso

Se genera la ilusin de un grupo de recursos ilimitado. Los

Centro de datos virtual de

Agrupamiento de recursos informticos y de almacenamiento

Los recursos informticos asignados al centro de datos virtual

Recursos informticos, almacenamiento y redes para cargas de

Contenedor para la solucin de software en la nube. Una vApp

Instancia de enrutador virtual que se crea dentro de una vApp

Red que conecta mquinas virtuales dentro de una vApp

Solucin de medicin y clculo de costos con la que se puede

API de RESTful abierta para ofrecer y consumir recursos

2015 VMware, Inc. Todos los derechos reservados.

VMware vCloud Architecture Toolkit for Service Providers

Solucin de software que ofrece un conjunto de caractersticas

Celda de vCloud Director

Celda de tiempo de ejecucin de servicios de vCloud Director

Nube privada virtual