You are on page 1of 78

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

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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
2015 VMware, Inc. Todos los derechos reservados.
Pgina 3 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 4 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 5 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 6 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 7 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 8 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 9 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 10 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 11 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 12 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 13 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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).

2015 VMware, Inc. Todos los derechos reservados.


Pgina 14 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 15 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 16 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 17 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 18 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

$VCLOUD_HOME/etc/global
.properties

128

200

vcloud.http.minThreads

$VCLOUD_HOME/etc/global
.properties

25

32

vcloud.http.acceptorThreads

$VCLOUD_HOME/etc/global
.properties

16

2015 VMware, Inc. Todos los derechos reservados.


Pgina 19 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 20 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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).
2015 VMware, Inc. Todos los derechos reservados.
Pgina 21 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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": {},

2015 VMware, Inc. Todos los derechos reservados.


Pgina 22 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
"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%

No tolera la prdida de ningn nodo.

33%

No tolera la prdida de ningn nodo.

100%

No tolera la prdida de ningn nodo.

67%

No tolera la prdida de ningn nodo.

50%

No tolera la prdida de ningn nodo.

100%

Tolera la prdida de un nodo.

75%

Tolera la prdida de un nodo.

60%

Tolera la prdida de un nodo.

100%

Tolera la prdida de un nodo.

80%

Tolera la prdida de un nodo.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 23 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 24 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 25 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 26 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 27 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 28 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 29 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 30 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 31 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 32 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 33 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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).

2015 VMware, Inc. Todos los derechos reservados.


Pgina 34 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 35 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 36 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 37 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 38 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 39 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

Compatibilidad con arquitectura de


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.

Compatibilidad con arquitectura de


red spine-leaf

Implementacin compleja

Altamente escalable
Compatibilidad con caractersticas
adicionales de NSX administrado
por el proveedor

2015 VMware, Inc. Todos los derechos reservados.


Pgina 40 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 41 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.


2015 VMware, Inc. Todos los derechos reservados.
Pgina 42 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 43 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 44 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 45 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 46 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 47 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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).

2015 VMware, Inc. Todos los derechos reservados.


Pgina 48 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 49 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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>

2015 VMware, Inc. Todos los derechos reservados.


Pgina 50 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 51 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 52 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 53 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 54 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 55 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 56 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 57 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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

Puerta de enlace Edge


compacta

3 Gb/s

Puerta de enlace Edge


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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 58 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 59 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 60 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 61 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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).
2015 VMware, Inc. Todos los derechos reservados.
Pgina 62 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 63 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 64 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

Clster de administracin

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

8.2.2 Celdas de vCloud Director


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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 65 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 66 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

Clster de administracin

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 67 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 68 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 69 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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.
2015 VMware, Inc. Todos los derechos reservados.
Pgina 70 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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

2015 VMware, Inc. Todos los derechos reservados.


Pgina 71 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 72 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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

%ProgramFiles%\VMware\VMware vCenter
Chargeback\Apache2.2\logs

Se archiva en un
recurso compartido
de archivos central

Recopilador de
datos

%ProgramFiles%\VMware\VMware vCenter
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

%ProgramFiles%\VMware\VMware vCenter
Chargeback VMware Cloud Director
DataCollector\\logs

Se archiva en un
recurso compartido
de archivos central.
El proceso de
archivado almacena
registros de forma
diaria.

Instalador

%ProgramFiles%\VMware\VMware vCenter
Chargeback\DataCollector-Embedded\logs

Se archiva en un
recurso compartido
de archivos central.
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 73 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 74 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

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)

2015 VMware, Inc. Todos los derechos reservados.


Pgina 75 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 76 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 77 de 78

VMware vCloud Architecture Toolkit for Service Providers


Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios

11.2.1 Celdas de vCloud Director


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.

2015 VMware, Inc. Todos los derechos reservados.


Pgina 78 de 78