En este escenario, el sitio 1 principal de Palo Alto se ve afectado por un desastre natural y se desactiva por completo. El administrador de NSX realiza una conmutación por error manual al sitio 2 secundario de Austin.
Como el sitio principal se desactivó debido a circunstancias imprevistas, el administrador no puede preparar la conmutación por error antes de que se produzca el fallo real.
El administrador de
NSX quiere cumplir los siguientes objetivos principales:
- Realizar una conmutación por error en todo el sitio 2 con un periodo de inactividad mínimo.
- Conservar las direcciones IP de las aplicaciones del sitio 1 tras la conmutación por error en el sitio 2.
- Recuperar automáticamente toda la configuración de la interfaz de Edge y del protocolo BGP en el sitio 2.
Nota:
- El administrador puede realizar las tareas de conmutación por error manualmente mediante vSphere Web Client o bien al ejecutar las REST API de NSX. Asimismo, el administrador puede automatizar algunas tareas de conmutación por error mediante la ejecución de un archivo de script que contenga las API que se deben usar durante la conmutación por error. En este escenario, se explican los pasos para la conmutación por error manual con vSphere Web Client. Sin embargo, si algún paso requiere utilizar la CLI o las REST API de NSX, le facilitamos las instrucciones correspondientes.
- En este escenario, el flujo de trabajo de la recuperación ante desastres es específico de la topología explicada anteriormente, que cuenta con una instancia de NSX Manager principal y una única instancia de NSX Manager secundaria. Este escenario no prevé la utilización de un flujo de trabajo con varias instancias de NSX Manager secundarias.
Importante: Si el sitio 1 principal se enciende mientras la conmutación por error se está llevando a cabo en el sitio 2 secundario, primero debe asegurarse de que el proceso de conmutación por error se completa siguiendo el procedimiento para este escenario. Restablezca o conmute por recuperación todas las cargas de trabajo en el sitio 1 principal original únicamente después de concluir correctamente la conmutación por error en el sitio 2 secundario. Para obtener instrucciones detalladas sobre el proceso de conmutación por recuperación, consulte
Escenario 3: conmutación por recuperación completa del sitio principal.
Requisitos previos
- En los sitios 1 y 2, está instalado NSX Data Center 6.4.5 o versiones posteriores.
- vCenter Server está instalado en los sitios 1 y 2 en el Modo vinculado mejorado (Enhanced Linked Mode).
- En los sitios 1 y 2, se cumplen las siguientes condiciones:
- No hay configuradas directivas de seguridad específicas de aplicaciones en un firewall que no sea de NSX, en caso de que se utilice alguno.
- No hay configuradas reglas de firewall específicas de aplicaciones en un firewall que no sea de NSX, en caso de que se utilice alguno.
- El firewall está deshabilitado en las dos ESG porque el protocolo de enrutamiento ECMP está habilitado en los UDLR y, de esta forma, se asegura de que se permita todo el tráfico.
- En el sitio 2, se cumplen las siguientes condiciones antes de que se produzca la conmutación por error:
- En las ESG, hay interfaces de vínculo inferior similares configuradas manualmente de la misma forma que en el sitio 1.
- En las ESG, la configuración del BGP se establece manualmente de la misma forma que en el sitio 1.
- Las ESG están desconectadas cuando el sitio 1 principal está activo o en funcionamiento.
Procedimiento
- Compruebe que la instancia de NSX Manager principal del sitio 1 está desactivada.
- En la página Instalación y actualización (Installation and Upgrade), desplácese a .
- Si actualiza la página Instancias de NSX Manager (NSX Managers) en la sesión actual del navegador, la función de la instancia de NSX Manager principal cambia a Desconocido (Unknown).
- Si cierra la sesión de vSphere Web Client y vuelve a iniciarla o abre una sesión del navegador de vSphere Web Client nueva, la instancia de NSX Manager principal ya no aparecerá en la página Instancias de NSX Managers (NSX Managers).
- Acceda a .
- Si actualiza la página Panel de control (Dashboard) en la sesión del navegador actual, se mostrará el siguiente mensaje de error: No se pudo establecer conexión con NSX Manager. Póngase en contacto con el administrador (Could not establish communication with NSX Manager. Please contact administrator).. Este error indica que la instancia de NSX Manager principal ya no es accesible.
- Si cierra la sesión de vSphere Web Client y vuelve a iniciarla o abre una sesión del navegador de vSphere Web Client nueva, la instalación de NSX Manager principal ya no estará disponible en el menú desplegable NSX Manager.
- La instancia de NSX Manager secundaria debe pasar a tener una función principal.
- En la página Instalación y actualización (Installation and Upgrade), desplácese a .
- Seleccione la instancia de NSX Manager secundaria.
- Haga clic en . Cuando se le solicite continuar con la operación de desconexión, haga clic en Sí (Yes).
La instancia de
NSX Manager secundaria se desconecta de la instancia de
NSX Manager principal y pasa a tener la función
Tránsito (Transit).
- Haga clic en .
La instancia de
NSX Manager secundaria del sitio 2 pasa a tener una función principal.
Precaución: Como la salida local está deshabilitada en el UDLR, las máquinas virtuales de control del UDLR (máquinas virtuales del dispositivo de Edge) se implementan solo en el sitio principal original (sitio 1). Antes de que se produzcan fallos en el sitio 1, las máquinas virtuales de control del UDLR no están disponibles en el sitio secundario (sitio 2), que ahora pasa a ser principal. Por lo tanto, vuelva a implementar las máquinas virtuales de control del UDLR en el sitio principal promocionado (sitio 2) antes de volver a implementar el clúster de NSX Controller.
Si los nodos del controlador se implementan antes que las máquinas virtuales de control del UDLR, aparecerán las tablas de reenvío del UDLR. En consecuencia, se produce un periodo de inactividad inmediatamente después de que se implemente el primer nodo del controlador en el sitio 2. Esta situación podría provocar interrupciones en la comunicación. Para evitar este problema, implemente la máquina virtual de control del UDLR antes que los nodos de NSX Controller.
- Encienda todas las instancias de NSX Edge que estén apagadas e implemente las máquinas virtuales de control del UDLR (máquinas virtuales del dispositivo de Edge) en el sitio 2 secundario (que pasa a ser principal).
Para obtener instrucciones sobre cómo implementar la máquina virtual de control del UDLR, consulte la
NSXGuía de instalación de Cross-vCenter.
Mientras implementa la máquina virtual de control del UDLR, configure los siguientes ajustes de los recursos:
- Seleccione el centro de datos como sitio 2.
- Seleccione el grupo de clústeres y recursos.
- Seleccione el almacén de datos.
Nota: Después de implementar la máquina virtual de control del UDLR, se recuperarán automáticamente los ajustes de configuración que se indican a continuación en el sitio 2:
- Configuración de enrutamiento del protocolo BGP
- Configuración de la contraseña del protocolo BGP
- Ajustes de la interfaz interna y del enlace ascendente
- Implemente los tres nodos de clúster de NSX Controller en el sitio 2 (que pasa a ser principal).
Para obtener instrucciones detalladas sobre cómo implementar instancias de
NSX Controller, consulte la
NSXGuía de instalación de Cross-vCenter.
- Actualice el estado del clúster de NSX Controller.
- En la página Instalación y actualización (Installation and Upgrade), haga clic en Instancias de NSX Manager (NSX Managers).
- Seleccione la instancia de NSX Manager que pasa a ser principal.
- Haga clic en .
- Fuerce el servicio de sincronización del enrutamiento en cada clúster del sitio 2.
- En la página Instalación y actualización (Installation and Upgrade), haga clic en Preparación del host (Host Preparation).
- Seleccione la instancia de NSX Manager que pasa a ser principal.
- Seleccione un clúster a la vez y haga clic en .
- Seleccione Enrutamiento (Routing) y haga clic en Aceptar (OK).
- Migre las máquinas virtuales de carga de trabajo del sitio 1 al sitio 2.
Nota: Dado que las máquinas virtuales de carga de trabajo seguirán manteniéndose en el sitio 1, deberá migrar manualmente estas máquinas al sitio 2.
Resultados
De esta forma concluye la recuperación manual de los componentes de NSX y la conmutación por error del sitio principal (sitio 1) al sitio secundario (sitio 2).
Qué hacer a continuación
Compruebe que la conmutación por error al sitio 2 ha finalizado por completo. Para ello, siga estos pasos en el sitio 2 (que pasa a ser el sitio principal):
- Compruebe que NSX Manager tenga la función principal.
- Compruebe que la máquina virtual de control (máquina virtual del dispositivo de Edge) esté implementada en el UDLR.
- Compruebe que el estado de todos los nodos del clúster del controlador sea Conectado (Connected).
- Compruebe que el estado de preparación del host sea Verde (Green).
- Inicie sesión en la consola de la CLI de cada máquina virtual de control del UDLR (máquina virtual del dispositivo de Edge) y realice estos pasos:
- Compruebe que todos los vecinos BGP estén establecidos y activados. Para ello, ejecute el comando show ip bgp neighbors .
- Compruebe que todos los vecinos BGP conozcan las rutas de BGP mediante el comando show ip route bgp.
Después de completar la conmutación por error al sitio 2, todas las cargas de trabajo se ejecutarán en el sitio secundario (que pasa a ser principal) y el tráfico se enrutará a través del UDLR y las instancias de NSX Edge del sitio 2.