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 bases de datos MySQL y PgSQL entre los sitios. Se realiza una copia de seguridad de los archivos de configuración y RRD 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 en el sitio en espera ni supervisa 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 la GUI y la API y los dispositivos administrados se conectan al sitio activo para todos los servicios de administración de red. La conectividad entre el sitio en espera y los dispositivos administrados está deshabilitada mientras 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 en espera y se establece la conectividad entre el sitio en 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 cuándo el sitio remoto deja de funcionar. El organismo de control de recuperación ante desastres del sitio local comprueba si hay problemas de conectividad entre ambos sitios (haciendo ping a los nodos del sitio remoto) y si los sitios están conectados a dispositivos de árbitro (si utiliza el algoritmo de arbitraje de dispositivos).

El vigilante de recuperación ante desastres de 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 en un intervalo configurable regular. El valor predeterminado para el intervalo es 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 vigilante de recuperación ante desastres vuelve a intentar el ping durante un número configurable de veces. De forma predeterminada, el número de reintentos es 4.

• Si se produce un error en todos los reintentos, el organismo de control de recuperación ante desastres del 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 ante desastres no concluye que el sitio remoto esté inactivo porque el sitio remoto puede estar cambiando la dirección VIP a un nodo en espera debido a un cambio 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 activo.

  Si se produce un error en el ping a los nodos, el organismo de control de recuperación ante desastres no concluye que el sitio remoto esté inactivo. En cambio, el organismo de control de recuperación de 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 se requiere una conmutación por error.

  Una conmutación por error solo se inicia si el porcentaje de dispositivos de árbitro administrados por el sitio activo cae por debajo del umbral de conmutación por error. A continuación, el sitio activo se convierte en el sitio en espera y el sitio en espera se convierte en el sitio activo.

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

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

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

• El porcentaje de dispositivos de á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 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 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) deben configurarse exactamente de la misma manera, con las mismas aplicaciones, adaptadores de dispositivo, mismas configuraciones de familia IP, y así sucesivamente.

• Ambos clústeres deben configurarse con información del servidor SMTP de 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 tanto del sitio activo como del sitio en espera notifiquen al administrador por correo electrónico si se produce un error en las replicaciones.

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 activo y en espera. Esto significa:

  • 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 utilizar SCP para transferir archivos entre los sitios activos y en espera

  • La replicación de bases de datos en los dos clústeres es posible a través de los puertos TCP 3306 (replicación de bases de datos MySQL) y 5432 (replicación de bases de datos 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 se realiza correctamente. Aunque el ancho de banda exacto requerido depende de la cantidad de datos transferidos, recomendamos un mínimo de una conexión de ancho de banda de 100 Mbps con una latencia de menos de 150 milisegundos.

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

• Conectividad independiente de capa 3 entre cada clúster y los clientes 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 uno en espera.

Organismo de Control de Recuperación de Desastres

El guardián de recuperación ante desastres, también conocido como perro guardián de recuperación ante desastres, 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 supervisa el estado general de la configuración de recuperación ante desastres, inicia una conmutación por error desde el sitio activo al sitio en espera cuando se produce un error en el sitio activo, y permite que el sitio en espera reanude los servicios de administración de red con una interrupción mínima del servicio. Se inicia una instancia del vigilante de recuperación ante desastres 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 proporciona los siguientes servicios:

• Latido
• mysqlMonitor
• pgsqlMonitor
• fileMonitor
• arbiterMonitor
• configMonitor
• serviceMonitor
• Notificación

Detección de errores mediante el algoritmo de arbitraje de dispositivos

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

• Debe poder llegar a los dispositivos árbitros a través de conexiones SSH iniciadas por Junos Space desde ambos sitios. No seleccione dispositivos que utilicen conexiones iniciadas por dispositivos a la plataforma Junos Space.

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

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

• Debe elegir dispositivos de árbitro 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 de árbitro sean inaccesibles desde sus sitios.

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

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

En el sitio activo:

1. Haga ping a todos los dispositivos árbitros seleccionados.

2. Calcule el porcentaje de dispositivos arbitrales a los que se puede hacer ping.

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

   • Si el porcentaje de dispositivos de árbitro conectados es superior o el mismo que el valor configurado del umbral de conmutación por error (parámetro failureDetection.threshold.failover en la sección de vigilancia 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 de árbitro está por debajo del valor configurado del umbral de conmutación por error, se inicia la conmutación por error (si la conmutación por error automática está habilitada) y el sitio activo pasa a estar en espera. Si la conmutación por error automática está deshabilitada, el sitio activo permanece activo.

En el lugar de espera:

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

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

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

4. Calcule el porcentaje de dispositivos árbitros a los que no se puede acceder a través de conexiones SSH.

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

   • Si el porcentaje de dispositivos de árbitro 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 el sitio activo puede conectar y administrar los dispositivos a los que no se puede acceder desde el sitio en espera, el sitio en espera asume que el sitio activo administra todos los dispositivos árbitros a los que no se puede acceder 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 (parámetro failureDetection.threshold.adjustManaged en la sección de vigilancia de la API de recuperación ante desastres, el valor predeterminado es 50%), el sitio en 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 sumando los dispositivos administrados por el sitio activo y los dispositivos árbitros a los que no se puede acceder está por debajo del umbral de conmutación por error, el organismo de control de recuperación ante desastres concluye que se debe iniciar una conmutación por error.

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

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

Detección de errores mediante 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 errores (sh, bash, Perl o Python) para decidir cuándo o si se debe conmutar por error al sitio en espera. Los scripts de error personalizados invocan el comando y obtienen la configuración de recuperación ante desastres y el jmp-dr api v1 config ––include estado de los servicios de vigilancia de recuperación ante desastres. La configuración de recuperación ante desastres y el estado de los servicios de vigilancia de recuperación ante desastres en un sitio se organizan en varias secciones. En el cuadro 1 se enumeran estas secciones.

Utilice la opción -- include <section-name> para ver los detalles de una sección o utilice los detalles de la sección en el script de detección de errores personalizado.

{ 
"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 del script personalizado informa al vigilante de recuperación ante desastres si se requiere una conmutación por error al sitio en espera. El vigilante de recuperación ante desastres interpreta el resultado del script en formato JSON. El siguiente es un ejemplo:

En la tabla 2 se describen los detalles de la salida del script.

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 la 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 plataforma de administración de red de Junos Space versión 14.1R3 y anteriores.

   No es necesario realizar este paso para una instalación limpia de la versión 15.2R1 de la plataforma de administración de red de Junos Space.

2. Configure 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 las áreas de trabajo de la plataforma de administración de red de Junos Space.

3. Copie el archivo con la lista de dispositivos árbitros (si está utilizando el algoritmo de arbitraje de dispositivos) o el script de detección de errores personalizado en la ubicación adecuada del sitio activo. Asegúrese de que todos los dispositivos de árbitro se descubran en el sitio activo. Para obtener más información, consulte Descripción general de los perfiles de detección 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 errores.

5. Configure el archivo de configuración de recuperación ante desastres en el sitio en 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 notificaciones.

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

   Para obtener más información, consulte Configuración del proceso de recuperación ante desastres entre un sitio activo y un sitio 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.