Descripción general de la recuperación ante desastres

Solución de recuperación ante desastres

Después de configurar e iniciar el proceso de recuperación ante desastres entre un sitio activo y un sitio en espera, se inicia la replicación asincrónica de las bases de datos MySQL y PgSQL entre los sitios. La configuración y los archivos RRD se copian de seguridad en el sitio de espera a través de SCP en intervalos de tiempo definidos.

El proceso de recuperación ante desastres no realiza la replicación en tiempo real de la base de datos de Cassandra al sitio de espera ni monitorea el servicio de Cassandra que se ejecuta en los nodos de Junos Space.

Durante el funcionamiento normal de la solución de recuperación ante desastres, los usuarios de GUI y API y los dispositivos administrados se conectan al sitio activo para todos los servicios de administración de red. La conectividad entre el sitio de espera y los dispositivos administrados está deshabilitada siempre que el sitio activo sea funcional. Cuando el sitio activo deja de estar disponible debido a un desastre, el sitio en espera pasa a estar operativo. En este momento, se inician todos los servicios del sitio de espera y se establece la conectividad entre el sitio de espera y los dispositivos administrados.

La figura 1 muestra la solución de recuperación ante desastres.

Figura 1: Solución de recuperación ante desastres

El proceso de vigilancia de recuperación ante desastres se inicia en el nodo VIP de los sitios activos y en espera para supervisar el estado del proceso de replicación y detectar cuando el sitio remoto se cae. El organismo de control de recuperación ante desastres en el sitio local comprueba si hay problemas de conectividad entre ambos sitios (haciendo ping a los nodos en el sitio remoto) y si los sitios están conectados a dispositivos árbitros (si utiliza el algoritmo de arbitraje de dispositivos).

El organismo de control de recuperación ante desastres en un sitio realiza las siguientes tareas para confirmar la conectividad con el sitio remoto y los dispositivos del árbitro:

• Haga ping a la dirección VIP del sitio remoto a un intervalo configurable regular. El valor predeterminado para el intervalo es de 30 segundos.

  Para cada ping, espere una respuesta dentro de un intervalo de tiempo de espera configurable. El valor predeterminado para el intervalo de tiempo de espera es de 5 segundos.

• Si el sitio local no recibe una respuesta dentro del intervalo de tiempo de espera, el organismo de control de recuperación ante desastres reintentos el ping durante un número configurable de veces. De forma predeterminada, el número de reintentos es 4.

• Si todos los reintentos fallan, el organismo de control de recuperación ante desastres en el sitio local concluye que no se puede acceder a la dirección VIP del sitio remoto.

  Sin embargo, el organismo de control de recuperación de desastres no concluye que el sitio remoto esté inactivo porque el sitio remoto puede estar cambiando a través de la dirección VIP a un nodo en espera debido a una conmutación local.

• Para considerar la posibilidad de un cambio de dirección VIP, el organismo de control de recuperación ante desastres hace ping a las direcciones IP de los otros nodos del equilibrador de carga en el sitio remoto. Si el ping a cualquiera de los nodos recibe una respuesta, el organismo de control de recuperación ante desastres concluye que el sitio remoto sigue funcionando.

  Si el ping a los nodos falla, el organismo de control de recuperación ante desastres no concluye que el sitio remoto esté inactivo. En su lugar, el organismo de control de recuperación ante desastres considera la posibilidad de problemas de conectividad entre los sitios. Ambos sitios intentarán activarse.

• Para evitar que ambos sitios intenten activarse, el organismo de control de recuperación ante desastres inicia el algoritmo de arbitraje de dispositivos y determina si es necesaria una conmutación por error.

  Solo se inicia una conmutación por error si el porcentaje de dispositivos del árbitro administrados por el sitio activo cae por debajo del umbral de conmutación por error. Luego, el sitio activo se convierte en el sitio de espera y el sitio de espera se convierte en el sitio activo.

  Si el porcentaje de dispositivos del árbitro está por encima del umbral de conmutación por error, el sitio de espera permanece en espera y el sitio activo permanece activo. El porcentaje de dispositivos de árbitro administrados por el sitio activo es configurable y su valor predeterminado es del 50 %.

La conmutación por error se inicia si se cumplen las siguientes condiciones:

• El sitio de espera no puede llegar a la dirección VIP del sitio activo ni a las direcciones IP del nodo de otros nodos del equilibrador de carga en el sitio activo.

• El porcentaje de los dispositivos del árbitro administrados por el sitio activo está por debajo del umbral de conmutación por error.

Para obtener más información acerca del algoritmo de arbitraje de dispositivos, consulte Detección de errores mediante el uso del algoritmo de arbitraje de dispositivos.

Requisitos previos para configurar la recuperación ante desastres

Debe asegurarse de que la instalación de Junos Space cumple con los siguientes requisitos previos antes de configurar la recuperación ante desastres:

• El clúster de Junos Space en el sitio principal o activo (que puede ser un solo nodo o varios nodos) y el clúster en el sitio remoto o en espera (que puede ser un solo nodo o varios nodos) se deben configurar exactamente de la misma manera, con las mismas aplicaciones, adaptadores de dispositivo, las mismas configuraciones de familia IP, y así sucesivamente.

• Ambos clústeres deben configurarse con información del servidor SMTP desde la interfaz de usuario de Junos Space. Para obtener más información, consulte Administración de servidores SMTP. Esta configuración permite que los clústeres del sitio activo y del sitio de espera notifiquen al administrador por correo electrónico si las replicaciones fallan.

Requisitos de conectividad para configurar la recuperación ante desastres

Debe asegurarse de que la solución de recuperación ante desastres cumple los siguientes requisitos de conectividad antes de configurar la recuperación ante desastres:

• Conectividad de capa 3 entre los clústeres de Junos Space en los sitios activos y en espera. Esto significa lo siguiente:

  • Cada nodo de un clúster puede hacer ping correctamente a la dirección VIP del otro clúster

  • Cada nodo de un clúster puede usar SCP para transferir archivos entre los sitios activos y en espera

  • La replicación de la base de datos en los dos clústeres es posible mediante los puertos TCP 3306 (replicación de base de datos MySQL) y 5432 (replicación de base de datos de PostgreSQL)

  • El ancho de banda y la latencia de la conexión entre los dos clústeres son tales que la replicación de la base de datos en tiempo real es correcta. Aunque el ancho de banda exacto requerido depende de la cantidad de datos transferidos, recomendamos una conexión mínima de ancho de banda de 100 Mbps con una latencia de menos de 150 milisegundos.

• Conectividad de capa 3 independiente entre cada clúster y los dispositivos administrados

• Conectividad de capa 3 independiente entre cada clúster y clientes de GUI o NBI

Para configurar el proceso de recuperación ante desastres, consulte Configuración del proceso de recuperación ante desastres entre un sitio activo y en espera.

Organismo de control de recuperación ante desastres

El guardián de la recuperación ante desastres, también conocido como guardián de DR, es un mecanismo integrado de Junos Space para supervisar la integridad de la replicación de datos (base de datos MySQL, base de datos PgSQL, archivos de configuración y archivos RRD) en todos los sitios. El organismo de control de recuperación ante desastres también monitorea el estado general de la configuración de recuperación ante desastres, inicia una conmutación por error desde el sitio activo al de espera cuando el sitio activo falla y permite que el sitio en espera reanude los servicios de administración de red con una interrupción mínima del servicio. Una instancia del guardián de recuperación ante desastres se inicia en el nodo VIP de ambos sitios cuando se inicia el proceso de recuperación ante desastres.

El organismo de control de recuperación ante desastres ofrece los siguientes servicios:

• Latido
• mysqlMonitor
• pgsqlMonitor
• monitor de archivos
• Monitor de árbitro
• configMonitor
• monitor de servicio
• Notificación

Detección de fallas mediante el uso del algoritmo de arbitraje de dispositivos

Se utiliza un algoritmo de arbitraje de dispositivo para detectar fallas en un sitio. Se selecciona una lista de dispositivos altamente accesibles que ejecutan Junos OS y son administrados por Junos Space Platform como dispositivos árbitros. Recomendamos que seleccione los dispositivos del árbitro según los siguientes criterios:

• Debe poder comunicarse con los dispositivos del árbitro a través de las conexiones SSH iniciadas por Junos Space desde ambos sitios. No seleccione dispositivos que usen conexiones iniciadas por el dispositivo a Junos Space Platform.

• Debe poder hacer ping a los dispositivos del árbitro desde ambos sitios de recuperación ante desastres.

• Debe elegir dispositivos árbitros que permanezcan conectados a la plataforma Junos Space o que se reinicien o apaguen con menor frecuencia, ya que esto puede afectar los resultados del algoritmo de arbitraje de dispositivos. Si prevé que ciertos dispositivos árbitros estarán desconectados durante alguna parte de sus vidas, evite elegir esos dispositivos.

• Debe elegir dispositivos árbitros de diferentes ubicaciones geográficas para asegurarse de que un problema en la red de administración en una ubicación no haga que todos los dispositivos del árbitro sean inalcanzables de sus sitios.

• No puede seleccionar dispositivos TDR y ww Junos OS como dispositivos árbitros.

El algoritmo de arbitraje de dispositivos en el sitio activo usa ping para conectarse a los dispositivos del árbitro desde el sitio activo. El algoritmo de arbitraje de dispositivos en el sitio de espera inicia sesión en los dispositivos del árbitro a través de conexiones SSH mediante el uso de las credenciales de inicio de sesión de la base de datos de Junos Space Platform. A continuación, se presentan los flujos de trabajo del algoritmo de arbitraje de dispositivos en los sitios activos y de espera.

En el sitio activo:

1. Ping a todos los dispositivos del árbitro seleccionados.

2. Calcule el porcentaje de dispositivos del árbitro que se pueden hacer ping.

3. Compruebe si el porcentaje de dispositivos de árbitro a los que se puede hacer ping está por encima o el mismo que el valor configurado del umbral de conmutación por error.

   • Si el porcentaje de dispositivos del árbitro conectados está por encima o el mismo valor configurado del umbral de conmutación por error (parámetro failureDetection.threshold.failover en la sección watchdog de la API de recuperación ante desastres), la conmutación por error no se inicia porque el sitio activo administra la mayoría de los dispositivos del árbitro.

   • Si el porcentaje de dispositivos del árbitro está por debajo del valor configurado del umbral de conmutación por error, se inicia la conmutación por error (si está habilitada la conmutación por error automática) y el sitio activo se convierte en espera. Si la conmutación por error automática está deshabilitada, el sitio activo permanece activo.

En el sitio de espera:

1. Inicie sesión en los dispositivos del árbitro a través de conexiones SSH.

2. Ejecute un comando en cada dispositivo árbitro para recuperar la lista de conexiones SSH a cualquier nodo (administrado por el nodo) en el sitio activo.

3. Calcule el porcentaje de dispositivos del árbitro administrados por el sitio activo.

4. Calcule el porcentaje de dispositivos del árbitro a los que no se puede acceder mediante las conexiones SSH.

   • Si el porcentaje de dispositivos de árbitro administrados por el sitio activo está por encima o el mismo que el valor configurado del umbral de conmutación por error, no es necesaria la conmutación por error, ya que el sitio activo sigue administrando la mayoría de los dispositivos del árbitro.

   • Si el porcentaje de dispositivos árbitros administrados por el sitio activo está por debajo del valor configurado del umbral de conmutación por error, el organismo de control de recuperación ante desastres concluye que puede ser necesaria una conmutación por error.

5. Sin embargo, dado que los dispositivos a los que no se puede acceder desde el sitio de espera pueden estar conectados y administrados por el sitio activo, el sitio en espera asume que el sitio activo administra todos los dispositivos del árbitro a los que no se puede llegar y calcula el nuevo porcentaje de dispositivos administrados por el sitio activo.

   • Si el porcentaje de dispositivos administrados por el sitio activo está por debajo del porcentaje de umbral para ajustar los dispositivos administrados (el parámetro failureDetection.threshold.adjustManaged en la sección watchdog de la API de recuperación ante desastres, el valor predeterminado es 50 %), el sitio de espera permanece en espera. De forma predeterminada, el porcentaje de umbral para ajustar los dispositivos administrados debe estar por debajo del umbral de conmutación por error.

   • Si el nuevo porcentaje calculado al agregar los dispositivos administrados por el sitio activo y los dispositivos del árbitro que no se pueden alcanzar está por debajo del umbral de conmutación por error, el organismo de control de recuperación de desastres concluye que se debe iniciar una conmutación por error.

     Si la conmutación por error automática está habilitada, el sitio de espera inicia el proceso de activarse. Si la conmutación por error automática está deshabilitada, no se produce ninguna conmutación por error.

Si desactivó la conmutación por error automática o la función se desactivó debido a problemas de conectividad, debe ejecutarse jmp-dr manualFailover en el sitio de espera para reanudar los servicios de administración de red desde el sitio de espera.

Detección de errores mediante el uso de scripts personalizados de detección de errores

Además de usar el algoritmo de arbitraje de dispositivos, puede crear scripts personalizados de detección de fallas (sh, bash, Perl o Python) para decidir cuándo o si se va a pasar por error al sitio de espera. Los scripts de error personalizados invocan el jmp-dr api v1 config ––include comando y recuperan la configuración de recuperación ante desastres y el estado de los servicios de control de recuperación ante desastres. La configuración de recuperación ante desastres y el estado de los servicios de control de recuperación ante desastres en un sitio se organizan como varias secciones. En el cuadro 1 se enumeran estas secciones.

Utilice la opción -- include <sección-name> para ver los detalles de una sección o usar los detalles de la sección en la secuencia de comandos personalizada de detección de errores.

{ 
"core": {
  "peerVip": "10.155.90.210",
  "adminPass": "ABCDE12345",
  "scpTimeout": 120,
  "peerLoadBalancerNodes": "10.155.90.211",
   "peerBusinessLogicNodes": "10.155.90.211",
   "peerDeviceMgtIps": "10.155.90.211"}
}

{ "mysql": {
   "hasDedicatedDb": false,
   "peerVip": "10.155.90.210",
   "peerNodes": "10.155.90.211"
   }
}

{ "psql": {
  "hasFmpm": false,
  "peerFmpmVip": "10.155.90.210",
  "peerNodes": "10.155.90.211"
  }
}

{ "file": {
  "backup": {
    "maxCount": 3,
    "hoursOfDay": "*",
    "daysOfWeek": "*" },
  "restore": {
    "hoursOfDay": "*",
"daysOfWeek": "*" }
  }
}

{ "watchdog": {
  "heartbeat": {
"retries": 4,
"timeout": 5,
"interval": 30 },
  "notification": {
    "email": "abc@example.com",
    "interval": 3600 },
  "failureDetection": {
"isCustom": false,
"script": "/var/cache/jmp-geo/watchdog/bin/arbitration",
    "threshold": {
      "failover": 0.5,
      "adjustManaged": 0.5,
      "warning": 0.7 },
      "waitDuration": "8h",
      "arbiters": [{
        "username": "user1",
        "password": "xxx",
        "host": "10.155.69.114",
        "port": 22,
        "privateKey": ""
      }]
}
  }
}

{ "deviceManagement": {
   "peerNodes": "10.155.90.211",
   "nodes": "10.155.90.222",
”ip”: “10.155.90.228,eth0”
 }
}

{ "states": {
    "arbiterMonitor": {
      "progress": "idle",
      "msg": {
        "service": "arbiterMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:18:55+00:00"
      },
"service": {}
   },

    "configMonitor": {
      "progress": "idle",
      "msg": {
        "service": "configMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:15+00:00"
      },"service": {}
    },

    "fileMonitor": {
      "progress": "idle",
      "msg": {
        "service": "fileMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:18:59+00:00"
      },
"service": {}
    },

    "heartbeat": {
      "progress": "unknown",
      "msg": {
        "service": "heartbeat",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "localFailover": false
        },
        "time": "2015-07-18T22:17:49+00:00"
      },
"service": {
        "booting": false,
        "bootEndTime": null,
        "waitTime": null,
        "automaticFailover": false,
        "automaticFailoverEndTime": "2015-07-18T07:41:41+00:00"
      }
    },

"mysqlMonitor": {
      "progress": "idle",
      "msg": {
        "service": "mysqlMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:09+00:00"
      },
"service": {}
    },

    "pgsqlMonitor": {
      "progress": "unknown",
      "msg": {
        "service": "pgsqlMonitor",
        "description": "Master node pgsql in active or standby site maybe CRASHED. Pgsql replication is in bad status. Please manually check Postgresql-9.4 status.",
        "state": false,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 1098
        },
        "time": "2015-07-18T22:18:27+00:00"
      },"service": {}
    },

 
    "serviceMonitor": {
      "progress": "running",
      "msg": {
        "service": "serviceMonitor",
        "description": "",
        "state": true,
        "force": false,
        "progress": "unknown",
        "payload": {
          "code": 0
        },
        "time": "2015-07-18T22:19:30+00:00"
      },
      

"service": {}
    }
  }
}                                      

El resultado de la secuencia de comandos personalizada informa al organismo de control de recuperación ante desastres si es necesaria una conmutación por error en el sitio de espera. El guardián de recuperación ante desastres interpreta el resultado del script en formato JSON. A continuación se muestra un ejemplo:

En la tabla 2 se describen los detalles de la salida de la secuencia de comandos.

Pasos para configurar la recuperación ante desastres

Para configurar la recuperación ante desastres entre un sitio activo y un sitio en espera:

1. Detenga el proceso de recuperación ante desastres configurado durante versiones anteriores antes de actualizar a la versión 15.2R1 de la plataforma de administración de red de Junos Space. Para obtener más información sobre el proceso de actualización, consulte la sección Instrucciones de actualización en las Notas de versión 15.2R1 de la plataforma de administración de red de Junos Space.

   Para obtener más información acerca de cómo detener el proceso de recuperación ante desastres configurado durante versiones anteriores, consulte Detención del proceso de recuperación ante desastres en la versión 14.1R3 y versiones anteriores de la plataforma de administración de red de Junos Space.

   No es necesario realizar este paso para una instalación limpia de Junos Space Network Management Platform versión 15.2R1.

2. Configure los servidores SMTP en ambos sitios desde la interfaz de usuario de Junos Space para recibir notificaciones. Para obtener más información, consulte Administración de servidores SMTP en la Guía del usuario de los espacios de trabajo de la plataforma de administración de red de Junos Space.

3. Copie el archivo con la lista de dispositivos del árbitro (si utiliza el algoritmo de arbitraje de dispositivos) o la secuencia de comandos personalizada de detección de errores en la ubicación adecuada en el sitio activo. Asegúrese de que todos los dispositivos del árbitro se descubran en el sitio activo. Para obtener más información, consulte Descripción general de perfiles de descubrimiento de dispositivos en la Guía del usuario de los espacios de trabajo de la plataforma de administración de red de Junos Space.

4. Configure el archivo de configuración de recuperación ante desastres en el sitio activo. La configuración de recuperación ante desastres incluye la configuración de SCP para sincronizar la configuración y los archivos RRD, la configuración de latidos, la configuración de notificaciones y el mecanismo de detección de fallas.

5. Configure el archivo de configuración de recuperación ante desastres en el sitio de espera. La configuración de recuperación ante desastres incluye la configuración de SCP para sincronizar la configuración y los archivos RRD, la configuración de latidos y la configuración de notificación.

6. Inicie el proceso de recuperación ante desastres desde el sitio activo.

   Para obtener más información, consulte Configurar el proceso de recuperación ante desastres entre un sitio activo y en espera.

Comandos de recuperación ante desastres

Utilice los comandos de recuperación ante desastres enumerados en la tabla 3 para configurar y administrar sitios de recuperación ante desastres. Debe ejecutar estos comandos en el nodo VIP del sitio. Puede usar la --help opción con estos comandos para ver más información.