Utilización de la duplicación en un escenario de ejemplo de recuperación tras desastre
Este escenario de recuperación tras desastre de extremo a extremo muestra cómo utilizar la duplicación para proporcionar una mayor disponibilidad y mantener las aplicaciones en funcionamiento en caso de que una incidencia grave afecte a una región de IBM Cloud completa.
Se aprovisionaron dos clústeres en regiones diferentes y se configuraron para la duplicación (siguiendo la información de Activación de la duplicación) utilizando A y B como alias
de clúster.Un productor publica registros en un tema denominado accounting.invoices y un consumidor lee los mensajes de dicho tema en el clúster A.
El clúster de origen deja de estar disponible
Consideremos qué ocurre si se produce un desastre en la región del clúster de origen.
Es responsabilidad del propietario de la instancia Event Streams determinar si el impacto del suceso es tal como para declarar una catástrofe. El propietario de la instancia de servicio debe coordinar la migración tras error de las aplicaciones, incluyendo la reconfiguración, el redespliegue y el reinicio si es necesario.
Migración tras error de productores
Realice los pasos siguientes para la migración tras error:
- Detenga los productores que apuntaban al clúster A.
- Si el clúster A y el enlace de A al clúster B todavía están operativos, asegúrese de que se reflejan tantos datos como sea posible comprobando que el retraso en esos temas en el clúster B es cero.
- Reinicia los productores para que apunten a los puntos finales del clúster B.
- Inhabilite cualquier duplicación que todavía esté habilitada en los temas del clúster A al clúster B. Esto se puede hacer utilizando Controles de usuario.
El productor cambia ahora al clúster B y envía mensajes a un nuevo tema local con el mismo nombre que el original.
Migración tras error de consumidores
Realice los pasos siguientes para la migración tras error:
- Si el clúster A y el enlace de A al clúster B siguen operativos, permita a los consumidores leer todos los datos de mensaje en los temas del clúster A y confirmar sus desplazamientos al final del tema.
- Detener a los consumidores que apuntaban al cluster A.
- Reinicie los consumidores para que apunten a los puntos finales del clúster B.
Ahora el consumidor puede seguir consumiendo los mensajes existentes del accounting.invoices.A tema del cluster B mientras llegan nuevos mensajes del accounting.invoices.
Si la aplicación requiere un orden estricto, los temas remotos deben consumirse por completo primero antes de empezar a consumir de los temas locales. De este modo, los mensajes se procesan en el orden en el que se han producido.
Restablecimiento de un entorno de duplicación
El propietario de la instancia de servicio de Event Streams es responsable de decidir qué sucede cuando se recupera el clúster A.
En caso de que el clúster A no sea recuperable, el propietario de la instancia de servicio de Event Streams es responsable de habilitar la duplicación entre el clúster B y una instancia recién suministrada. Para habilitar la duplicación en una instancia nueva, realice los pasos siguientes:
- No se podrá a los productores y consumidores de A a B como se ha descrito anteriormente.
- Inhabilite la duplicación actual del clúster A al clúster B. Para obtener más información, consulte Inhabilitación de la duplicación.
- Una vez inhabilitada la duplicación, habilite la duplicación entre el clúster B (ahora el origen) en el clúster recién suministrado (el destino). Para obtener más información, consulte Habilitación de la duplicación.
Alternativamente, si el clúster A se ha recuperado, normalmente un usuario devuelve las operaciones al clúster A. Realice los pasos siguientes para devolver operaciones primarias al clúster A.
Antes de volver a fallar, debe activarse la duplicación en la dirección opuesta:
- Asegúrese de que el clúster A esté completamente operativo.
- Inhabilite la duplicación actual del clúster A al clúster B. Para obtener más información, consulte Inhabilitación de la duplicación.
- Después de inhabilitar la duplicación, habilite la duplicación entre el clúster B (ahora el origen) y el clúster A (ahora el destino). Para obtener más información, consulte Habilitación de la duplicación.
- El clúster de origen A ahora se convierte en el clúster de destino.
- El clúster de destino B se convierte en el nuevo clúster de origen.
- Habilite los temas que se van a duplicar desde el clúster B al clúster A. Puede hacerlo utilizando los Controles de usuario.
A continuación, asegúrese de que los datos se están replicando en el clúster A examinando los temas del clúster B que aparecen en el clúster A. Estos temas tienen el sufijo del nuevo cluster de origen, B.
No vuelvas a reflejar el tema de destino original en el cluster B ya que esto causaría un efecto cíclico no deseado. Como se muestra en el diagrama, reflejamos accounting.invoices del clúster B al clúster A, no accounting.invoices.A.
Restablecimiento
La decisión de restablecimiento recae de nuevo sobre el propietario de la instancia de Event Streams. El propietario de la instancia de servicio debe coordinar el restablecimiento de las aplicaciones, incluyendo la reconfiguración, el redespliegue y el reinicio si es necesario.
A diferencia del caso de conmutación por error, en este caso no se produjo ningún desastre en el clúster B. Por lo tanto, el restablecimiento es una operación controlada y se puede lograr con una pérdida mínima de datos o con un reproceso de datos.
Por último, vuelva a la configuración original, lo que significa que el clúster A vuelve a ser el origen y el clúster B vuelve a ser el destino.
- Asegúrese de que el clúster A y el clúster B estén completamente operativos.
- Inhabilite la duplicación actual del clúster B al clúster A. Para obtener más información, consulte Inhabilitación de la duplicación.
- Después de inhabilitar la duplicación, habilite la duplicación entre el clúster A (ahora el origen) y el clúster B (ahora el destino). Para obtener más información, consulte Habilitación de la duplicación.