Story Transcript
VMware vCloud® Architecture Toolkit™ for Service Providers Arquitectura de soluciones de VMware vCloud Director® para proveedores de servicios Versión 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 demás nombres y marcas mencionados aquí podrían ser marcas comerciales de sus respectivas compañías.
VMware, Inc. 3401 Hillview Ave Palo Alto, CA 94304 www.vmware.com
© 2015 VMware, Inc. Todos los derechos reservados. Página 2 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
Contenido 1.
Introducción....................................................................................... 7
2.
Descripción de la tecnología ............................................................. 8 2.1 Glosario de términos ...................................................................................................... 9
3.
Consideraciones sobre el modelo de implementación .................... 12 3.1 Ofertas de servicios ..................................................................................................... 12
4.
Descripción general de la arquitectura ............................................ 17
5.
Componentes de administración de la nube ................................... 18 5.1 vCenter Server de administración................................................................................ 18 5.2 vCloud Director ............................................................................................................ 18 5.3 Base de datos de métricas de las máquinas 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 administración de grupos de recursos ............................................ 31 6.2 Recurso informático ..................................................................................................... 31 6.3 Redes ........................................................................................................................... 32 6.4 Almacenamiento .......................................................................................................... 44
7.
Diseño 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 organización ............................................................. 53 7.4 Redes ........................................................................................................................... 56 7.5 Almacenamiento .......................................................................................................... 60 7.6 Catálogos ..................................................................................................................... 61 7.7 vApps ........................................................................................................................... 62
8.
Escalabilidad ................................................................................... 64 8.1 Grupo de recursos ....................................................................................................... 64 8.2 Clúster de administración ............................................................................................ 65 8.3 Federación de vCloud Director .................................................................................... 66 © 2015 VMware, Inc. Todos los derechos reservados. Página 3 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
9.
Capacidad de recuperación ............................................................ 67 9.1 Descripción general ..................................................................................................... 67 9.2 Clúster de administración ............................................................................................ 67 9.3 Cargas de trabajo de tenants....................................................................................... 68
10.
Seguridad.................................................................................... 69 10.1 Instrucciones ................................................................................................................ 69 10.2 Registro de auditoría .................................................................................................... 71
11.
Consideraciones operativas ........................................................ 75 11.1 Supervisión de vCloud Director ................................................................................... 75 11.2 Revisiones de VMware vCloud Director ...................................................................... 77
© 2015 VMware, Inc. Todos los derechos reservados. Página 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 replicación de almacenamiento ...................................................................................... 15 Figura 6. Componentes del clúster de administración................................................................................ 17 Figura 7. Diseño de la base de datos de métricas de las máquinas 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 diseño de RabbitMQ ............................................................................................... 26 Figura 12. Flujo de trabajo de vCloud Usage Meter ................................................................................... 30 Figura 13. Arquitectura tradicional de acceso/adición/núcleo .................................................................... 34 Figura 14. Leaf-spine con clúster Edge/informático ................................................................................... 35 Figura 15. Leaf-spine con clúster Edge/informático y VDC no elástico ...................................................... 36 Figura 16. Leaf-spine con clúster Edge dedicado ...................................................................................... 37 Figura 17. Leaf-spine con clúster Edge dedicado y Edge ECMP ............................................................... 38 Figura 18. Clúster 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 físicas, virtuales y de abstracción de nube ............................................................. 47 Figura 22. Clúster de Edge compartido para instancias de VDC de organización de reserva .................. 55 Figura 23. Red de servicio .......................................................................................................................... 59
© 2015 VMware, Inc. Todos los derechos reservados. Página 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. Métricas de consumo de recursos y rendimiento de máquinas virtuales ..................................... 20 Tabla 4. Instrucciones de configuración de Cassandra .............................................................................. 23 Tabla 5. Métricas de vCenter Chargeback ................................................................................................. 27 Tabla 6. Resumen de las opciones de implementación de clústeres Edge ............................................... 40 Tabla 7. Requisitos de características del clúster de NSX Controller ........................................................ 41 Tabla 8. Definiciones de centros de datos virtuales ................................................................................... 47 Tabla 9. Notificaciones de token de OAuth................................................................................................. 51 Tabla 10. Tamaños de puertas de enlace Edge ......................................................................................... 58 Tabla 11. Rendimiento de puertas de enlace Edge .................................................................................... 58 Tabla 12. Copia de seguridad de componentes de administración ............................................................ 67 Tabla 13. Direcciones URL de portal web permitidas por el firewall de aplicación 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. Supervisión de celdas de vCloud Director .................................................................................. 75 Tabla 19. Supervisión de vCenter Chargeback .......................................................................................... 76 Tabla 20. Registros de vCloud Director ...................................................................................................... 76
© 2015 VMware, Inc. Todos los derechos reservados. Página 6 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
1.
Introducción
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 híbrida: 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 pública cumpla con los siguientes requisitos híbridos: •
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 virtualización abierto (Open Virtualization Format, OVF) para movimiento bidireccional de cargas de trabajo
Este documento incluye instrucciones sobre cómo diseñar vSphere, vCloud Director y otras tecnologías complementarias para que todos los proveedores de servicios puedan obtener el distintivo VMware Hybrid Cloud Powered Service.
© 2015 VMware, Inc. Todos los derechos reservados. Página 7 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
2.
Descripción de la tecnología
Para diseñar una nube híbrida, es necesario utilizar un conjunto de tecnologías 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 virtualización informática y de redes subyacente, en la que se puede utilizar cualquier recurso físico compatible (servidores, almacenamiento, conmutadores de red y enrutadores). vCloud Director se utiliza para el plano de administración de la nube. Admite, agrupa y abstrae de manera nativa la plataforma de virtualización en términos de centros de datos virtuales. Ofrece características multitenant y acceso de autoservicio para tenants a través de una interfaz gráfica de usuario nativa o a través de la API de vCloud, lo que permite un acceso programable para los tenants (para consumo) y para el proveedor (administración de la nube). Además, la API de vCloud ofrece un marco para servicios de extensión, 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 demás y brinda la posibilidad de diseñar 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 utilización de las mismas herramientas de VMware o de terceros para la administración. VMware vCloud Usage Meter recopila datos de consumo de distintos componentes de software de VMware para ofrecer una concesión de licencias de paquetes VMware Service Provider Program (VSPP) según el uso. De manera opcional, se pueden utilizar componentes adicionales de VMware para la integración de sistemas de soporte operativos y empresariales: •
® VMware vCloud Connector para simplificar migraciones de máquinas virtuales, plantillas e imágenes ISO hacia y desde la nube pública para clientes y proveedores (administración de catálogo público).
•
VMware vCenter™ Chargeback™ para mediciones e informes de uso. La API de vCenter Chargeback se integra con los sistemas de facturación existentes.
•
VMware vRealize™ Operations Manager™ para supervisión y análisis de rendimiento y capacidad.
•
VMware vRealize Hyperic® para servicios de supervisión de componentes de administración.
•
VMware vRealize registro Insight™ para administración y análisis centralizado de registros.
•
VMware vRealize Orchestrator™ para servicios de extensión o tareas de automatización recurrentes (incorporación y ciclo de vida de tenants).
•
VMware Site Recover Manager™ para protección de recuperación ante desastres de componentes de administración de la nube.
De manera opcional, VMware Virtual SAN™ puede extender los servicios de virtualización 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. Página 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 términos
Tabla 1. Glosario Término
Definición
Grupo de asignación
Grupo de recursos asignados para los cuales se garantiza un cierto porcentaje de recursos informáticos.
Zona de disponibilidad
Un solo dominio de errores para recursos.
Catálogo
Repositorio de plantillas y elementos multimedia de vApp disponibles para la implementación por parte de los usuarios. Los catálogos pueden publicarse y compartirse entre organizaciones en el mismo entorno de vCloud.
Nube dedicada
Recursos de nube dedicados a un tenant en una infraestructura física dedicada.
Puerta de enlace Edge
Dispositivos virtuales para brindar seguridad en el perímetro de la red. Las puertas de enlace Edge conectan las redes aisladas y privadas de tenants de la nube con el lado público de la red del proveedor a través 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.
Clúster de administración
Recursos virtuales y físicos dedicados a funciones de administración.
Grupos de redes
Recopilaciones de redes virtuales de Capa 2 aisladas a las que vCloud Director puede acceder para la implementación automatizada de redes de organizaciones y vApp.
Nube a petición
Recursos de nube confirmados para el tenant que se facturan solamente cuando se usan.
Organización
Unidad multitenant que representa un solo límite de seguridad lógico. Una organización contiene usuarios, centros de datos virtuales y catálogos.
Administrador de organización
El administrador de una organización de vCloud Director, responsable de administrar los recursos suministrados, los servicios de red, los usuarios y las directivas de vApp.
Redes de VDC de organización
Las instancias de redes de VDC de organización se crean a través de grupos de redes y se enlazan al VDC de una sola organización o se comparten entre organizaciones. Las redes de VDC de organización pueden estar aisladas, enrutarse o conectarse directamente con una red externa. © 2015 VMware, Inc. Todos los derechos reservados. Página 9 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios Término
Definición
Centro de datos virtual de organización
Subgrupo de recursos informáticos, de red y de almacenamiento asignados a una sola organización desde el centro de datos virtual de un proveedor. Un centro de datos virtual es un entorno de implementación donde se pueden crear instancias de vApp, implementar vApps y encender vApps. Los centros de datos virtuales de organización no pueden expandirse a varias organizaciones.
Pago por uso
Se genera la ilusión de un grupo de recursos ilimitado. Los recursos solo se confirman cuando se crean vApps en el centro de datos virtual de la organización.
Centro de datos virtual de proveedor
Agrupamiento de recursos informáticos 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 informáticos asignados al centro de datos virtual de organización son completamente reservados y dedicados.
Grupo de recursos
Recursos informáticos, almacenamiento y redes para cargas de trabajo de tenants administrados por un vCenter Server.
vApp
Contenedor para la solución de software en la nube. Una vApp es la unidad estándar de implementación para vCloud Director. Contiene una o varias máquinas 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 máquinas virtuales dentro de una vApp implementada por un consumidor desde un grupo de redes.
vCenter Chargeback
Solución de medición y cálculo 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. Página 10 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios Término
Definición
vCloud Director
Solución de software que ofrece un conjunto de características de administración, automatización 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 ejecución de servicios de vCloud Director en una máquina física o virtual. Es posible agrupar varias celdas dentro de una instancia de vCloud Director mediante la conexión 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. Página 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 implementación
3.1
Ofertas de servicios
El modelo de implementación actual depende de la oferta de cada proveedor de servicios. En esta sección, se analizan las opciones de configuración más comunes y sus consideraciones de implementación.
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 informáticos, de almacenamiento y de red a usuarios finales como bloques de creación para implementar sistemas operativos y aplicaciones (cargas de trabajo). Por lo general, la zona de disponibilidad se define como una ubicación (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 interrupción de gran magnitud en una ubicación provocará una alteración total de los servicios que se ejecutan allí. En la siguiente figura se representa un modelo de implementación típico de la oferta de zona de disponibilidad individual de IaaS. Figura 1. Zona de disponibilidad individual
© 2015 VMware, Inc. Todos los derechos reservados. Página 12 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios Un solo clúster de administración ejecuta componentes de administración de la nube (vCloud Director), además de componentes de administración 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 clústeres administrados mediante un solo vCenter Server. Es posible disponer de más de un grupo de recursos para escalar más allá de los límites de un vCenter Server, pero todos los grupos se deben ubicar dentro de la misma zona de disponibilidad.
3.1.2 Zonas de disponibilidad múltiples de IaaS Con el concepto de zona de disponibilidad múltiple, los usuarios finales pueden implementar sus aplicaciones en un modelo distribuido. De esa manera, cuando se producen errores en una zona de disponibilidad, la aplicación puede continuar en ejecución. El usuario final es responsable de mantener el estado de la aplicación entre las zonas. El proveedor debe disponer de dos sitios (centros de datos) a una distancia suficiente como para anular la correlación de su probabilidad de error y a una cercanía suficiente como para mantenerlos bajo la misma administración de nube. Además, el proveedor debe garantizar la recuperación ante desastres de los componentes de administración de la nube. Existen dos opciones para diseñar zonas de disponibilidad múltiples. Esas opciones difieren en la forma de implementar los componentes de administración 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 administración, como se muestra en la siguiente figura. Figura 2. Grupos de recursos distribuidos
Los componentes de administración de la nube se ubican en un sitio principal. Si se produce un desastre o una interrupción, los componentes de administración pueden conmutarse por error al sitio secundario para reducir el tiempo de inactividad. Los grupos de recursos y sus componentes de administración se aíslan por zona de disponibilidad sin conmutación 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 administración de la nube.
© 2015 VMware, Inc. Todos los derechos reservados. Página 13 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios Ventajas de este diseño: •
Se ofrece acceso a los componentes de administración de la nube incluso si se producen errores.
•
Con un diseño apropiado de aplicaciones, el tenant puede evitar el tiempo de inactividad en las aplicaciones.
•
El proveedor de servicios puede ofrecer un servicio de recuperación ante desastres.
3.1.2.2. Grupo de recursos ampliado Este diseño, que se utiliza con menos frecuencia, amplía un grupo de recursos en las dos zonas de disponibilidad, con algunos clústeres en el primer sitio y otros en el segundo. La administración de grupos de recursos se ubica en el sitio principal con conmutación por error al grupo secundario. La ventaja principal de este diseño consiste en que es posible ampliar redes de organización 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 recuperación ante desastres de los componentes de administración en el grupo de recursos y la posibilidad de alteración lógica de los componentes de administración, 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 diseños multisitio requiere un almacenamiento ampliado (solución de clústeres metro de almacenamiento). Sin embargo, se puede utilizar el almacenamiento ampliado para la recuperación ante desastres en la capa de administración. 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 máxima de 20 milisegundos entre sitios (aproximadamente 1600 km).
© 2015 VMware, Inc. Todos los derechos reservados. Página 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 múltiples de IaaS Las regiones son instancias de nube completamente aisladas y separadas por grandes distancias. Los tenants pueden colocar sus cargas de trabajo más cerca de los usuarios finales y protegerlos ante un desastre que afecte a toda la región. La gran distancia implica que las aplicaciones de los tenants deben mantener su estado de manera asíncrona. vCloud Director no ofrece compatibilidad nativa para varias instancias (federación). Por ese motivo, el proveedor debe utilizar su propio portal o el de un tercero además de vCloud Director. Figura 4. Regiones
3.1.4 IaaS con acuerdo de nivel de servicio para Disaster Recovery Ninguna de las opciones de implementación anteriores garantiza acuerdos de nivel de servicio de recuperación 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 replicación en el nivel de la aplicación. Sin embargo, las aplicaciones heredadas no admiten la replicación de estado en el nivel de la aplicación y es necesario utilizar la replicación que ofrece la infraestructura. En este caso, el proveedor puede aprovechar la replicación 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 replicación de almacenamiento
© 2015 VMware, Inc. Todos los derechos reservados. Página 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 diseñar la recuperación ante desastres con replicación de almacenamiento: •
Replicación de almacenamiento genérica síncrona o asíncrona con conmutación por error manual o generada por script al otro sitio. Para obtener más 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.
•
Solución de almacenamiento que admite vSphere MetroStorage Cluster con conmutación por error automatizada proporcionada por vSphere HA. Para obtener más 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 pública según el consumo deseado del cliente. Los siguientes modelos están disponibles: •
Nube a petición
•
Nube privada virtual
•
Nube dedicada
3.1.5.1. Nube a petición El cliente no se suscribe por adelantado a los recursos de la nube y paga solo según el consumo. Por lo general, esto es beneficioso para cargas de trabajo por ráfaga o por temporada, que aumentan o disminuyen según el momento. El cliente consume los recursos desde un grupo aparentemente infinito que el proveedor debe mantener. La predicción de este tipo de demanda puede ser difícil para el proveedor. Por ese motivo, lo compensa con un exceso de suscripciones de esos recursos o encareciéndolos. Esta oferta se relaciona directamente con el modelo de asignación de pago por uso del centro de datos virtual de la organización (Organization Virtual Data Center, Org VDC). 3.1.5.2. Nube privada virtual El cliente compra un fragmento de recursos en términos de nube privada virtual (Virtual Private Cloud, VPC), que consiste en recursos informáticos (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 período mínimo (por lo general, al menos un mes). El proveedor administra el exceso de suscripción de recursos; el cliente no tiene ningún control sobre esto. El tamaño de la VPC puede ser arbitrario, desde apenas una porción de un host hasta varios clústeres de vSphere, gracias a la posibilidad de compartir la infraestructura física y virtual de vSphere subyacente entre diferentes tenants. Esta oferta se relaciona directamente con el modelo de asignación Tipo de asignación de Org VDC. 3.1.5.3. Nube dedicada En casos donde el cliente no ejecuta cargas de trabajo en la misma infraestructura física que otros tenants, o debido a motivos de concesión de licencias, pueden adquirir una nube dedicada. Varios hosts físicos (desde un clúster de vSphere) están dedicados para el tenant, que tiene el control total sobre el exceso de suscripción de las cargas de trabajo que se implementan en su nube dedicada. Esta oferta se relaciona directamente con el modelo de asignación Tipo de reserva de Org VDC. © 2015 VMware, Inc. Todos los derechos reservados. Página 16 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
4.
Descripción general de la arquitectura
La arquitectura de la nube pública típica consiste en componentes de administración que se implementan en el clúster de administración, y en grupos de recursos para alojar las cargas de trabajo del tenant. Algunos de los motivos de la separación son los siguientes: •
Diferentes acuerdos de nivel de servicio (disponibilidad, capacidad de recuperación, rendimiento) para componentes de administración y para cargas de trabajo del tenant
•
Separación de tareas (vCloud Director se encarga de administrar los grupos de recursos)
•
Administración y escala coherentes de los grupos de recursos
El clúster de administración ejecuta los componentes de administración de la nube y los componentes de administración del grupo de recursos. Figura 6. Componentes del clúster de administración
Los grupos de recursos son dominios de infraestructura independiente representados por recursos informáticos, de redes y de almacenamiento virtualizados, cada uno de ellos administrado por su propio vCenter Server.
© 2015 VMware, Inc. Todos los derechos reservados. Página 17 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios
5.
Componentes de administración de la nube
5.1
vCenter Server de administración
A excepción de los entornos pequeños, VMware recomienda que el clúster de administración sea administrado por su propio vCenter Server. Esto permite una protección de recuperación ante desastres con Site Recovery Manager y mejora más la separación 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 administración.
5.2
vCloud Director
5.2.1 Celdas de vCloud Director La funcionalidad de vCloud Director está dada por celdas sin estado, máquinas 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 través del bus de mensajes ActiveMQ en la interfaz principal. Además, comparten una base de datos común de vCloud Director, donde las celdas conservan los datos de configuración y estado. El servicio de transferencia requiere que todas las celdas tengan acceso a una carpeta compartida común, por lo general un montaje de NFS. Las siguientes son consideraciones de diseño 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 máquinas virtuales encendidas (utilice la mayor de las dos opciones).
•
Para evitar una situación de cerebro dividido, compruebe que las celdas se comuniquen entre sí a través 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 más de un proxy. Para realizar esta tarea manualmente, debe dispararse la reconexión 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 tráfico de equilibrio de carga a una celda específica. 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 recuperación ante desastres.
•
Utilice un firewall de aplicaciones web para finalizar el tráfico HTTPS de vCloud en el equilibrador de carga y para aplicar reglas de firewall de Capa 7. Puede filtrarse según la URL, la dirección IP de origen o el encabezado de autenticación para proteger el acceso a ciertas organizaciones o llamadas de API (ámbito del proveedor). El tráfico entre el equilibrador de carga y las celdas también debe estar cifrado con HTTPS. Habilite la inserción de encabezados HTTP X-Forwarded-For en el equilibrador de carga para rastrear la dirección IP de origen de las solicitudes en los registros de vCloud Director. El tráfico 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 conexión de socket SSL propia. © 2015 VMware, Inc. Todos los derechos reservados. Página 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 sesión se guarda en la memoria caché en el nivel de la celda, y también se almacena en la base de datos de vCloud.
•
Utilice un algoritmo de equilibrio de carga por turnos o según 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:///api/server_status (la respuesta esperada es “Service is up” [El servicio está en funcionamiento]). https:///sdk/vimServiceVersions.xml o una comprobación simple del puerto TCP 443.
•
Después 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 información necesaria para implementar celdas nuevas o adicionales (por ejemplo, la contraseña 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 tamaño suficiente para almacenar todas las importaciones/exportaciones o migraciones de OVF o ISO simultáneas entre grupos de recursos (por ejemplo, 10 transferencias de 50 GB simultáneas necesitan un máximo 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 tamaño, aumente el tamaño de pila de JVM, el grupo de conexiones de la base de datos y la conexión Jetty en $VCLOUD_HOME/bin/vmware-vcd-cell. Consulte la tabla a continuación.
Tabla 2. Propiedades avanzadas de las celdas de vCloud Director Nombre de la opción avanzada
Ubicación
Valor predeterminado
Valor recomendado para entornos de gran tamaño
Tamaño 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
2
16
© 2015 VMware, Inc. Todos los derechos reservados. Página 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 diseño 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 artículo 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 Clúster de conmutación 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 diseño caso por caso.
•
Siga las prácticas recomendadas de configuración de base de datos de vCloud Director según lo especificado en el artículo de la base de conocimientos de VMware: Instalación y configuración 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 métricas de las máquinas virtuales
A partir de vCloud Director 5.6, se recopilan métricas de consumo de recursos y rendimiento de máquinas virtuales, y se ofrecen datos históricos hasta un máximo de dos semanas de antigüedad. Tabla 3. Métricas de consumo de recursos y rendimiento de máquinas virtuales Nombre de la métrica
Tipo
Unidad
Descripción
cpu.usage.average
Velocidad
Porcentaje
Vista del host de la utilización activa promedio de la CPU como porcentaje del total disponible
cpu.usagemhz.average
Velocidad
Megahercio
Vista del host de la utilización activa promedio de la CPU como medición sin procesar
cpu.usage.maximum
Velocidad
Porcentaje
Vista del host de la utilización activa máxima 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. Página 20 de 78
VMware vCloud Architecture Toolkit for Service Providers Arquitectura de soluciones de VMware vCloud Director para proveedores de servicios A través de la API de vCloud, se pueden recuperar métricas actuales e históricas. Las métricas actuales se recuperan directamente de la base de datos de vCenter Server, con la API de PerformanceManager. Las métricas históricas se recuperan cada 5 minutos, con una granularidad de 20 segundos, a través del proceso StatsFeeder que se ejecuta en las celdas y se aplica al almacenamiento persistente (clúster 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 diseño recomendado de la base de datos de métricas de las máquinas virtuales. Se implementan varios nodos Cassandra en la misma red. Se ejecuta una base de datos KairosDB en cada nodo, lo que además 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 dirección IP virtual que se configura a través de la herramienta de administración de la celda como el endpoint de métricas de la máquina virtual. Figura 7. Diseño de la base de datos de métricas de las máquinas virtuales
Las siguientes son consideraciones de diseño de la base de datos de métricas de las máquinas virtuales: •
En la actualidad, solo se admiten KairosDB 0.9.1 y Cassandra 1.2.x/2.0.x.
•
El tamaño de clúster mínimo es de tres nodos (la cantidad de nodos debe ser mayor o igual al factor de replicación). Utilice un enfoque de escalado horizontal, no de escalado vertical, ya que el rendimiento de Cassandra escala de manera lineal según la cantidad de nodos.
•
Calcule los requisitos de E/S de acuerdo con la cantidad de máquinas virtuales esperada, y configure adecuadamente el tamaño del clúster de Cassandra y su almacenamiento. n: cantidad de máquinas virtuales esperada m: cantidad de métricas por máquina virtual (actualmente 8) t: retención (días) r: factor de replicación E/S de escritura por segundo = n × m × r / 10 Almacenamiento = n × m × t ×r × 114 kB Para 30.000 máquinas 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 retención de datos es de 6 semanas y el factor de replicación es 3).
•
Habilite la estrategia de compactación nivelada (Leveled Compaction Strategy, LCS) en el clúster de Cassandra para mejorar el rendimiento de escritura.
•
Instale JNA (Java Native Access) versión 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. Página 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 estadísticas de rendimiento) y disponibilidad, VMware recomienda aumentar el factor de replicación a 3.
•
Tamaño 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 retención de datos. Por lo tanto, los datos de métricas antiguos deben borrarse periódicamente con un script.
En el siguiente ejemplo, se borran los datos de un mes: #!/bin/sh if [ "$#" -ne 4 ]; then echo "$0 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