Saltar al contenido

Disponibilidad de VCloud: información sobre la replicación del tráfico

Disponibilidad de VCloud

A finales de enero de este año, VMware anunció la familia de productos vCloud Availability para vCloud Director, que es una sencilla herramienta de recuperación ante desastres basada en la nube. La herramienta está diseñada para resolver directamente problemas urgentes tanto de los proveedores de servicios en la nube como de los clientes.

Hoy en día, las organizaciones necesitan proteger los datos de la nube, pero lamentablemente todavía no existe una solución que se ajuste como una bota sin dimensiones a cualquier tamaño de pie. Los proveedores de servicios, como los clientes, primero deben comprender los requisitos técnicos y comerciales y luego asegurarse de que se seleccionen las herramientas adecuadas para la tarea a realizar. Con la disponibilidad de vCloud para vCloud Director, los clientes tienen una solución de recuperación ante desastres basada en la nube simple y rentable adecuada para pequeñas, medianas y grandes empresas.

En pocas palabras, vCloud Availability actúa como un servicio que amplía las capacidades de vCloud Director al replicar máquinas virtuales entre entornos vSphere y nubes públicas. La particularidad de la solución es que no es necesario crear redes privadas (privadas) para la replicación del tráfico entre entornos locales multiusuario y nubes públicas. La replicación bidireccional garantiza la circulación segura del tráfico de Internet, que se trata con más detalle en este artículo.

Un ejemplo de conexión de una nube pública con la infraestructura de vSphere

Un ejemplo de conexión de una nube pública con la infraestructura de vSphere

Para comprender cómo se organiza la replicación entre la infraestructura local y la nube pública mediante la disponibilidad de vCloud, veamos los componentes clave.

Componentes en su lugar

Por lo tanto, un entorno local multiusuario funciona con casi cualquier versión de vSphere que use la aplicación vSphere Replication (VR). La tecnología permite la replicación de datos entre sitios, implementada a nivel de hipervisor, por lo que no es necesario involucrar las capacidades particulares del sistema de almacenamiento. Desde el punto de vista del usuario, el proceso parece transparente y sencillo. El hipervisor supervisa los cambios realizados en los discos de la máquina virtual y, según los criterios especificados, realiza una sincronización regular con el sitio de respaldo. Al mismo tiempo, las VM del servicio VR Appliance ubicadas a cada lado administran la sincronización. Las aplicaciones requieren acceso a Internet, pero no es necesario establecer una IP pública enrutable. El dispositivo de realidad virtual puede estar detrás de un firewall NAT seguro con solo un puerto TCP 443 abierto. VSphere Replication tiene tres componentes:

  • Servicio de vSphere Replication Manager (vRMS) Es esencialmente un «cerebro» de realidad virtual interno que utiliza una base de datos interna o externa de su elección. VRMS también proporciona un complemento de vSphere Web Client para administrar la replicación.
  • vSphere Replicación servidor (vRS) – Un punto clave para la replicación entrante (desde la nube) que se utiliza antes de que el tráfico llegue a su destino como almacén de datos de destino. Este componente admite el escalado en caso de que necesite implementar subprogramas adicionales. Sin embargo, el componente no se utiliza para la replicación saliente.
  • vCloud Tunelización Agente (vCTA) – el componente responsable de organizar un túnel seguro al conectarse a la nube. Supervise y deje la conexión abierta para la replicación inversa.

Aparte de los componentes nombrados, no se requiere nada más, ya que el motor de replicación real (agente de replicación vSphere y filtro vSCSI) ya está presente en el hipervisor: ESXi VMkernel. Entonces, T.o-la-nube la replicación se lleva a cabo según el esquema:

Host ESXi (agente de realidad virtual)> vSphere Replication Appliance (vCTA)> Internet> extremo de disponibilidad pública de vCloud (VIP con equilibrio de carga de proxy en la nube)

Mientras lo replica Desde la nube use un orden diferente:

Punto de enlace público de disponibilidad de VCloud (proxy de nube)> Internet> vSphere Replication Appliance (vCTA)> vSphere Replication Server (integrado en el dispositivo de realidad virtual o independiente)> host ESXi

Componentes de la nube pública

El funcionamiento en la nube requiere una versión compatible de vCloud Director. Al mismo tiempo, vCloud Availability utiliza componentes de vSphere Replication en forma de aplicaciones vRMS. Además necesitará:

  • vSphere Replicación Nube Servicio (vRCS) – Aplicación de alta disponibilidad con API mejorada de vCloud VR. Además, la base de datos externa Cassandra y RabbitMQ se utilizan para interactuar con vCloud Director.
  • Nube Apoderado – Elementos del equilibrador de carga de vCloud Director como componentes con todos los servicios de vCloud deshabilitados y el único servicio de Cloud Proxy habilitado (vCTA multitenciado).
  • vCloud Disponibilidad Portal usos domésticos – Componentes del balanceador de carga sin estado para administrar la replicación en la nube, donde la IU de vSphere Replication local no está disponible.

En tal escenario, el proveedor de servicios podría atender a cientos de clientes con miles de túneles simultáneos. Para lograr este nivel de escalabilidad, Cloud Proxy se implementa en modo de escalamiento horizontal con un balanceador de carga al final. Al mismo tiempo, el equilibrio de carga proporciona control de conexión vCTA local, así como replicación del tráfico en la nube. Organizar En las nubes la replicación utiliza el siguiente esquema:

Dispositivo de realidad virtual local del inquilino> Internet> Equilibrio de carga> Proxy en la nube> vRS> Host ESXi

Para replicar Desde la nube se trata de un orden diferente, en el que se utiliza una de las dos opciones posibles: un equilibrador de carga con y sin un conjunto de reglas de aplicación L7. La segunda opción se considera más recomendada. Detengámonos en ello con más detalle.

Descripción general de vCloud Director y los componentes de disponibilidad de vCloud

Descripción general de vCloud Director y los componentes de disponibilidad de vCloud

Como se señaló anteriormente, la «conexión» siempre se inicia en el sitio. Es por eso que tenemos una conexión de control que equilibra la carga en uno de los proxies en la nube, en nuestro caso Nube Apoderado 2… El tráfico replicado proviene del host ESX, dirigido a la nube (2) a través de Interior Cargar Balancín a uno de Nube Apoderado… En nuestro caso usamos Nube Apoderado uno (3). Debido a la conexión establecida hastaPremisa vCTA recibe una notificación sobre qué Nube Apoderado utilizado para la replicación específica (4-7). En el ejemplo actual vCTA puede establecer una conexión con Nube Apoderado unodurante el uso 1: 1 DNAT IP/ FQDN Nube Apoderado (9). Por lo tanto, dos conexiones (3) es (9) como si estuvieran «cosidos» entre sí (diez), iniciando la transferencia de tráfico desde la nube al entorno local.

Resumiendo

Para que el patrón reproducido realmente funcione, también necesitará:

  • Balanceador de carga de Cloud Proxy con Cloud ProxyBase VIP, utilizado para el control de la conexión y la replicación a la nube.
  • Equilibrio de carga interno (interno) para el tráfico de ESXi a Cloud Proxy.
  • IP / FQDN público adicional para cada proxy en la nube al transferir tráfico desde la nube. El FQDN de voz se configura en el archivo global.properties en la celda de Cloud Proxy (loudproxy.reverseconnection.fqdn = FQDN: 443).
  • Si usa el mismo proxy en la nube y un FQDN diferente, debe asegurarse de que el certificado http de la celda del proxy en la nube esté instalado en ambos FQDN.

* Texto preparado con material del blog de Tom Fojta

Califica el artículo