View a markdown version of this page

Bloque de ejecución de la comprobación de estado de Amazon Route 53 - Controlador de recuperación de aplicaciones (ARC) de Amazon

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Bloque de ejecución de la comprobación de estado de Amazon Route 53

El bloque de ejecución de comprobaciones de estado de Amazon Route 53 le permite especificar las regiones a las que se redirigirá el tráfico de su aplicación durante la conmutación por error. El bloque de ejecución crea comprobaciones de estado de Amazon Route 53, que luego se adjuntan a los registros DNS de Route 53 de su cuenta. Cuando ejecuta su plan de cambio de región, el estado de las comprobaciones de estado de Route 53 se actualiza y el tráfico se redirige en función de su configuración de DNS.

importante

La zona alojada de Route 53 debe estar en la misma partición que el plan de conmutación regional.

Configuración

Para configurar un bloque de ejecución de las comprobaciones de estado de Route 53, introduzca los siguientes valores.

importante

Antes de configurar el bloque de ejecución, asegúrese de que la función de ejecución del plan cuente con la política de IAM correcta. Para obtener más información, consulte Política de ejemplo de bloque de ejecución de comprobación de estado de Route 53.

  1. Nombre del paso: introduzca un nombre.

  2. Descripción del paso (opcional): introduzca una descripción del paso.

  3. ID de zona alojada: el ID de la zona alojada del dominio y los registros de DNS en Route 53.

  4. Nombre del registro: introduzca el nombre del registro (nombre de dominio) de los registros que utilice, junto con las comprobaciones de estado asociadas, para redirigir el tráfico hacia su aplicación. La característica de cambio de región buscará los conjuntos de registros de Route 53 para el nombre del registro e intentará asignar cada conjunto de registros a una región, basándose en el nombre de la región incluido en el valor o identificador del conjunto de registros.

  5. Identificadores de conjuntos de registros (opcional): tiene la opción de proporcionar manualmente los identificadores de conjuntos de registros si el cambio de región no puede asignar automáticamente los conjuntos de registros a las regiones a partir del nombre de registro proporcionado en el paso 4 después de haber creado el plan. Si la evaluación del plan devuelve una advertencia que indica que se necesita más información, actualice su plan con identificadores de conjuntos de registros incluyendo lo siguiente para cada región:

    • Identificador del conjunto de registros: introduzca el identificador del conjunto de registros o la Value/Route dirección de tráfico del conjunto de registros.

    • Región: introduzca la región asociada al conjunto de registros que contiene la información del identificador del conjunto de registros.

  6. Elija Guardar paso.

  7. Configure las comprobaciones de estado de Route 53.

    El cambio de región proporciona un identificador de comprobación de estado, para cada región, para cada nombre de registro dentro de una zona alojada definida en el bloque de ejecución. Asegúrese de configurar las comprobaciones de estado de los conjuntos de registros correspondientes de su cuenta en Route 53 para que el cambio de región pueda redirigir correctamente el tráfico de su aplicación durante la ejecución del plan. En la pestaña Comprobaciones de estado de la página de detalles del plan, puede ver las comprobaciones de estado de todos los bloques de ejecución y regiones.

Cómo funciona el bloque de ejecución de chequeos de estado de Route 53 como mecanismo de conmutación por error de DNS de alta disponibilidad

El bloque de ejecución de comprobaciones de estado Route53 del conmutador de región ARC crea dos conjuntos de comprobaciones de estado, una para cada región si la carga de trabajo se despliega en dos regiones. Le vende estos chequeos de salud. Puede verlos a través de la consola del conmutador de región, en la pestaña «Supervisión», o a través de la ListRoute53HealthChecks API. A continuación, asocie estas comprobaciones de estado a sus registros DNS de Route 53.

Cuando se ejecuta el bloque de ejecución de las comprobaciones de estado de Route 53, utiliza el patrón STOP (Standby Takes Over Primary) oculto para cambiar el estado de las comprobaciones de estado y organizar la conmutación por error del DNS. La comprobación de estado principal se marca como «en mal estado» y la secundaria se marca como «en buen estado» cuando se organiza una conmutación por error de la principal a la secundaria. Route 53 utiliza este cambio en el estado de la comprobación de estado para redirigir el tráfico durante la conmutación por error.

Para active/passive: el chequeo de estado de la región principal comienza en buen estado; el control de estado de la región pasiva comienza en mal estado. Cuando se utiliza el bloque de ejecución de comprobaciones de estado de Route53 para realizar la conmutación por error, estos estados se invierten.

Para active/active: todos los controles de estado comienzan correctamente. Cuando se utiliza el bloque de ejecución de comprobaciones de estado de Route53 en un flujo de trabajo de desactivación, el flujo de trabajo establece el estado de comprobación de estado de la región que se está desactivando en mal estado. Cuando se utiliza el bloque de ejecución de las comprobaciones de estado de Route53 en un flujo de trabajo de activación para una región, el flujo de trabajo establece el estado de la comprobación de estado de la región de activación en correcto.

¿Por qué se trata de un mecanismo de conmutación por error de alta disponibilidad?

Dos razones hacen que sea un mecanismo de conmutación por error fiable:

  1. Las transiciones de estado de las comprobaciones de estado de Route 53 forman parte del plano de datos de Route 53, que está diseñado para ofrecer una disponibilidad del 100%

    Cambiar el estado de una comprobación de estado de Route53 es una operación del plano de datos. El plano de datos de Route53 está distribuido por todo el mundo y diseñado para ofrecer una disponibilidad del 100%. Los cambios de estado del Route53 no dependen del plano de control. Esto significa que el cambio de estado del chequeo funciona incluso si la región principal está alterada.

  2. El patrón STOP (el modo de espera pasa a ser el primario)

    El patrón STOP es un mecanismo para organizar una conmutación por error de DNS y se publicó en la entrada del blog aquí: Creación de mecanismos de recuperación ante desastres con Amazon Route 53. Este patrón lo utiliza el bloque de ejecución de las comprobaciones de estado de Route53, que se oculta bajo el capó. El patrón STOP implica utilizar la región sana como «agente de decisión» para cambiar el estado del chequeo médico en la región afectada. El patrón STOP no depende de la región afectada.

Así es como funciona en la práctica:

  • Al crear un bloque de ejecución de comprobaciones de estado de Route53, las comprobaciones de estado se crean por conmutación de región en cada región para su carga de trabajo y se envían a través de la consola de conmutación de región en la pestaña Supervisión o la API. ListRoute53HealthChecks

  • A continuación, los asocias manualmente al registro DNS de cada región. Tú asocias una comprobación de estado al registro DNS de la región principal y la otra al registro DNS de la región secundaria.

  • La comprobación de estado está asociada a los registros DNS de la región principal, pero supervisa un recurso de la región en espera (secundaria) (por ejemplo, la presencia de un archivo en S3) para cambiar el estado de la comprobación de estado.

  • La comprobación de estado está invertida: si no se puede acceder al recurso en espera, la comprobación de estado de la región principal se establece de forma predeterminada en buen estado. Si se descubre el recurso en espera, la comprobación de estado de la región principal pasa a estar en mal estado. Esto evita una conmutación por error accidental.

  • Para activar una conmutación por error, el archivo se crea mediante un conmutador de región de la región en espera. La comprobación de estado lo detecta, marca el estado principal en mal estado y Route53 cambia el DNS. El recurso en espera lo administra el servicio de conmutación de región y no depende del cliente.

La combinación de la ausencia de dependencia del plano de control (plano de datos distribuido globalmente) y la ausencia de una dependencia regional deficiente (patrón STOP) lo convierte en un mecanismo de conmutación por error del DNS de alta disponibilidad cuando el cliente solo opera desde dos regiones. Consulte el patrón STOP documentado aquí: Creación de mecanismos de recuperación ante desastres con Amazon Route 53.

Qué se evalúa como parte de la evaluación del plan

Cuando el cambio de región evalúa el plan, realiza varias comprobaciones de la configuración y los permisos del bloque de ejecución de comprobación de estado de Route 53. El cambio de región verifica que las comprobaciones de estado estén asociadas a los registros de DNS especificados en la configuración del bloque de ejecución. Es decir, el cambio de región verifica que los registros de DNS de una Región de AWS específica estén configurados para utilizar las comprobaciones de estado de esa región.

Comparación de los controles de enrutamiento ARC y los bloques de ejecución de comprobaciones de estado de Route 53

El bloque de ejecución de comprobaciones de estado de Amazon Route 53 en el conmutador de región ofrece una alternativa de menor coste para la gestión DNS-based del tráfico. Sin embargo, este bloque de ejecución depende del elemento Región de AWS que se esté activando, por lo que la región debe estar disponible. Esto satisface las necesidades de la mayoría de los clientes, ya que están activando una región próspera.

Los controles de enrutamiento ARC proporcionan una administración DNS-based del tráfico altamente confiable con un SLA de disponibilidad del 100%. Con los controles de enrutamiento, sus equipos de operaciones pueden trasladar el tráfico entre regiones con barandas de seguridad. Los controles de enrutamiento proporcionan una solución de usuario único con un SLA del 100%. Un clúster de control de enrutamiento está distribuido en cinco regiones y puede tolerar que dos regiones estén desconectadas. Si tiene aplicaciones muy críticas, considere la posibilidad de utilizar controles de enrutamiento.

No se requieren controles de enrutamiento para usar el conmutador de región. Puede usar el conmutador de región para administrar el redireccionamiento del tráfico mediante bloques de ejecución de comprobaciones de estado de Route 53 sin controles de enrutamiento.

Los controles de enrutamiento añaden valor con el cambio de región en las siguientes situaciones:

  • Necesita el SLA de disponibilidad del 100% para el propio mecanismo de control de tráfico.

  • Su organización requiere controles operativos manuales con normas de seguridad para las aplicaciones críticas.

  • Desea contar con una defensa exhaustiva para que los equipos de operaciones puedan anular manualmente las rutas de tráfico automatizadas si es necesario.

Los bloques de ejecución de las comprobaciones de estado de Route 53 no dependen del plano de control. Los cambios en los registros de Health Check utilizan el plano de datos, por lo que no requieren que la región de activación procese las actualizaciones de configuración. Los bloques de ejecución de las comprobaciones de estado de Route 53 son suficientes en las siguientes situaciones:

  • Su aplicación puede depender de lo Región de AWS que esté activando.

  • La redirección automática del tráfico como parte del flujo de trabajo de recuperación cumple con sus requisitos.

  • La optimización de los costes es una prioridad. Los bloques de ejecución de chequeos de estado de Route 53 tienen un costo menor que los controles de enrutamiento.

La mayoría de los clientes comienzan con los bloques de ejecución de comprobaciones de estado de Route 53 como mecanismo de enrutamiento de tráfico predeterminado y agregan controles de enrutamiento solo para las aplicaciones más críticas que requieren la mayor confiabilidad del mecanismo de administración del tráfico.