Product Documentation

Recuperación ante desastres

Puede planificar y configurar implementaciones de XenMobile que contengan varios sitios para la recuperación ante desastres con la ayuda de una estrategia de conmutación por error desde el sitio activo al sitio pasivo.

La estrategia recomendada de recuperación ante desastres que se describe en este artículo consiste en:

  • Un solo sitio activo de XenMobile en el centro de datos de una ubicación geográfica que sirve a todos los usuarios de empresa a nivel mundial, conocido como el sitio principal.
  • Un segundo sitio de XenMobile en el centro de datos de una segunda ubicación geográfica, conocido como el sitio de recuperación ante desastres. Este sitio de recuperación ante desastres ofrece una conmutación por error desde el sitio activo al sitio pasivo si se produce un error en el centro de datos del sitio principal. El sitio principal incluye XenMobile, la base de datos SQL, la infraestructura de NetScaler para facilitar la conmutación por error y ofrecer a los usuarios acceso a XenMobile si falla la conectividad con el sitio principal.

Los servidores XenMobile presentes en el sitio de recuperación ante desastres permanecen fuera de línea durante las operaciones habituales. Solo se ponen en línea en situaciones de recuperación ante desastres, donde se requiere una conmutación por error completa del sitio principal al sitio de recuperación ante desastres. Los servidores SQL presentes en el sitio de recuperación ante desastres deben estar activos y listos para ofrecer conexiones antes de iniciarse los servidores XenMobile en el sitio de recuperación ante desastres.

Esta estrategia de recuperación ante desastres se basa en la conmutación por error manual del nivel de acceso de NetScaler mediante cambios de DNS para enrutar las conexiones de MDM y MAM al sitio de recuperación ante desastres en caso de una interrupción.

Nota:

Para poder usar esta arquitectura, debe tener un proceso implementado para copias de seguridad asíncronas de las bases de datos y alguna forma de garantizar una alta disponibilidad de la infraestructura SQL.

Proceso de conmutación por error en caso de recuperación ante desastres

  1. Si está probando su proceso de conmutación por error en caso de recuperación ante desastres, apague los servidores XenMobile que haya presentes en el sitio principal para simular un fallo del sitio.
  2. Modifique los registros DNS públicos para que los servidores XenMobile apunten a las direcciones IP externas del sitio de recuperación ante desastres.
  3. Modifique el registro DNS interno para que SQL Server apunte a la dirección IP del servidor SQL presente en el sitio de recuperación ante desastres.
  4. Ponga en línea las bases de datos SQL de XenMobile en el sitio de recuperación ante desastres. Compruebe que el servidor SQL Server y la base de datos estén activos y listos para ofrecer conexiones desde los servidores XenMobile locales en el sitio.
  5. Encienda los servidores XenMobile en el sitio de recuperación ante desastres.

Proceso de actualización de XenMobile Server

Siga estos pasos cada vez que actualice XenMobile con parches y versiones para mantener uniforme el código de los servidores principales y de recuperación ante desastres.

  1. Compruebe que los servidores XenMobile en el sitio principal disponen de los parches más recientes o están actualizados.
  2. Compruebe que el registro DNS para el servidor SQL se esté resolviendo en la base de datos activa del servidor SQL en el sitio principal.
  3. Ponga en línea los servidores XenMobile del sitio de recuperación ante desastres. Esos servidores se conectan a la base de datos del sitio principal a través de WAN solo durante el proceso de actualización.
  4. Aplique las actualizaciones y los parches necesarios a todos los servidores XenMobile del sitio de recuperación ante desastres.
  5. Reinicie los servidores XenMobile y confirme que el parche o la actualización se haya realizado correctamente.

Diagrama de la arquitectura de referencia en una recuperación ante desastres

En el siguiente diagrama se muestra la arquitectura de alto nivel para una implementación de recuperación ante desastres de XenMobile.

Diagrama de la arquitectura de referencia en una recuperación ante desastres

GSLB para la recuperación ante desastres

Un elemento clave de esta arquitectura es el uso de Global Server Load Balancing (GSLB) para dirigir el tráfico al centro de datos correcto.

De forma predeterminada, el asistente de NetScaler para XenMobile configura NetScaler Gateway de una manera que no permite el uso de GSLB para la recuperación ante desastres. Por lo tanto, se deben tomar medidas adicionales.

Cómo funciona GSLB

GSLB es, principalmente, un tipo de DNS. Los dispositivos NetScaler que intervienen actúan como servidores DNS autorizados y resuelven los registros DNS a la dirección IP correcta (por regla general, la dirección IP virtual que debe recibir tráfico). El dispositivo NetScaler comprueba el estado del sistema antes de responder a una consulta de DNS y dirigir el tráfico a ese sistema.

Tras resolverse el registro, termina el rol de GSLB en resolver el tráfico. El cliente se comunica directamente con la dirección IP virtual (VIP) de destino. El comportamiento del cliente DNS desempeña un papel importante en cómo y cuándo caduca un registro. Eso está en gran medida fuera de los límites del sistema de NetScaler. Como tal, GSLB está sujeto a las mismas limitaciones que la resolución de nombres DNS. Los clientes guardan en caché las respuestas. Por tanto, este equilibrio de carga no es tan inmediato como el equilibrio de carga tradicional.

La configuración de GSLB en NetScaler, incluidos los sitios, los servicios y las supervisiones, existe para proporcionar la resolución de nombres DNS correcta.

La configuración real para los servidores de publicación (en este caso, la configuración que crea el asistente de NetScaler para XenMobile) no se ve afectada por el GSLB. GSLB es un servicio independiente en NetScaler.

Dificultades con la delegación de dominio al usar GSLB con XenMobile

El asistente de NetScaler para XenMobile configura NetScaler Gateway para XenMobile. Este asistente genera tres servidores virtuales de equilibrio de carga y un servidor virtual NetScaler Gateway.

Dos de los servidores virtuales de equilibrio de carga gestionan el tráfico MDM, en los puertos 443 y 8443. NetScaler Gateway recibe el tráfico MAM y lo reenvía al tercer servidor, el servidor virtual de equilibrio de carga de MAM, en el puerto 8443. Todo el tráfico enviado al servidor virtual de equilibrio de carga de MAM pasa a través de NetScaler Gateway.

El servidor virtual de equilibrio de carga de MAM requiere el mismo certificado SSL que los servidores XenMobile y utiliza el mismo FQDN que se usa para inscribir los dispositivos. El servidor de equilibrio de carga de MAM también utiliza el mismo puerto (8443) que uno de los servidores de equilibrio de carga de MDM. Para permitir que el tráfico se resuelva, el asistente de NetScaler para XenMobile crea un registro DNS local en NetScaler Gateway. El registro DNS coincide con el FQDN utilizado para inscribir los dispositivos.

Esta configuración es eficaz cuando la URL del servidor XenMobile no es una URL de dominio GSLB. Si se utiliza una URL de dominio GSLB como URL del servidor XenMobile, como se requiere para la recuperación ante desastres, el registro DNS local impide que NetScaler Gateway resuelva el tráfico a los servidores de equilibrio de carga de MDM.

Usar el método CNAME para la recuperación ante desastres de GSLB

Para solucionar las dificultades que presenta la configuración predeterminada creada por el asistente de NetScaler para XenMobile, puede crear un registro CNAME para el FQDN del servidor XenMobile en el dominio principal (company.com) y apuntar un registro en la subzona delegada (gslb.company.com) para la cual NetScaler está autorizado. Al hacerlo, se permite la creación del registro A de DNS estático para la dirección VIP de equilibrio de carga MAM requerida para resolver el tráfico.

  1. En el DNS externo, cree un CNAME para el FQDN del servidor XenMobile que apunte al FQDN de dominio GSLB en NetScaler GSLB. Necesita dos dominios GSLB: uno para el tráfico MDM y otro para el tráfico MAM (NetScaler Gateway).

    Ejemplo:

    CNAME = xms.company.com IN CNAME xms.gslb.comany.com

  2. En la instancia de NetScaler Gateway de cada sitio, cree un servidor virtual GSLB con el FQDN al que apunta el registro CNAME.

    Ejemplo:

    bind gslb vserver xms-gslb -domainName xms.gslb.company.com

    Cuando utilice el asistente de NetScaler para XenMobile para implementar NetScaler Gateway, use la URL del servidor XenMobile cuando configure el servidor de equilibrio de carga de MAM. Así, crea un registro A de DNS estático para la URL del servidor XenMobile.

  3. Realice pruebas con los clientes que se inscriban en Secure Hub utilizando la URL del servidor XenMobile (xms.company.com).

    En este ejemplo se utilizan los siguientes FQDN:

    • xms.company.com es la URL utilizada por el tráfico de MDM y utilizada por los dispositivos que se inscriben; se ha configurado en este ejemplo desde el asistente de NetScaler para XenMobile.
    • xms.gslb.company.com es el FQDN de dominio GSLB para el servidor XenMobile.