Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Centro de ayuda/ Distributed Cache Service/ Descripción general del servicio/ Recuperación ante desastres (DR) y solución multiactiva
Actualización más reciente 2025-01-23 GMT+08:00

Recuperación ante desastres (DR) y solución multiactiva

Ya sea que utilice DCS como caché frontend o almacenamiento de datos backend, DCS siempre está listo para garantizar la confiabilidad de los datos y la disponibilidad del servicio. La siguiente figura muestra la evolución de las arquitecturas DR de DCS.

Figura 1 Evolución de la arquitectura DR de DCS

Para cumplir con los requisitos de confiabilidad de sus datos y servicios, puede optar por desplegar su instancia de DCS dentro de una única AZ o entre AZ.

HA de la AZ única dentro de una región

Despliegue de la AZ única significa desplegar una instancia dentro de una sala de equipos físicos. DCS proporciona HA de proceso/servicio, persistencia de datos y políticas de DR en standby activa para diferentes tipos de instancias de DCS.

Instancia de nodo único de DCS: cuando DCS detecta una falla de proceso, se inicia un nuevo proceso para garantizar el HA del servicio.

Figura 2 HA para una instancia de DCS de nodo único implementada dentro de una AZ

Principal/en espera, separación de lectura/escritura o instancia de DCS de clúster: De forma predeterminada, los datos se mantienen en el disco en el nodo principal y se sincronizan y persisten en el nodo en espera de manera incremental, lo que permite lograr la persistencia de datos y la espera activa.

La siguiente figura muestra la sincronización de datos y la persistencia de los procesos de los nodos principales y en espera, incluidos los procesos de las instancias de separación principales/en espera y de lectura/escritura y cada partición de instancias de clúster.

Figura 3 HA entre nodos principales y en espera dentro de una AZ

DR entre las AZ dentro de una región

Los nodos principales y en espera de una instancia de DCS (no se incluye el tipo de nodo único) se pueden desplegar en las AZ (en diferentes salas de equipos). Las fuentes de alimentación y las redes de diferentes AZ están aisladas físicamente. Cuando se produce una falla en la AZ donde se despliega el nodo principal, el nodo en espera se conecta al cliente y se hace cargo de las operaciones de lectura y escritura de datos.

Figura 4 Despliegue entre las AZ de una instancia principal/en espera de DCS
Figura 5 Despliegue entre las AZ de una instancia de DCS de separación de lectura/escritura
Figura 6 Despliegue entre las AZ de una instancia de Clúster Proxy de DCS
Figura 7 Despliegue entre las AZ de una instancia de Clúster Redis de DCS

Al crear una instancia de DCS principal/en espera, de clúster o de separación de lectura/escritura, seleccione una AZ en espera que sea diferente de la AZ principal como se muestra a continuación.

Figura 8 Selección de diferentes AZ

También puede desplegar su aplicación en todas las AZ para garantizar la fiabilidad de los datos y la disponibilidad del servicio en caso de interrupciones en el suministro eléctrico o en la red.

Multiactividades entre las regiones

Actualmente, Huawei Cloud DCS no admite multiactividad entre regiones porque Redis no tiene una solución madura de actividad-actividad. Actividad-actividad es diferente de recuperación ante desastres o HA principal/en espera.

No se puede lograr Redis activo-activo entre las nubes o las regiones porque los protocolos de serialización de REdis (RESP) personalizados no están unificados. Si se requiere activo-activo, se puede implementar mediante escritura dual en el extremo de la aplicación.

Figura 9 Escritura dual en el lado de la aplicación para lograr multi-actividad

Notas:

  1. La solución de escritura dual no puede garantizar la coherencia de la caché (debido a problemas de red). Las aplicaciones deben tolerar la incoherencia de la caché (estableciendo el tiempo de vida para lograr una eventual consistencia). Si las aplicaciones requieren una fuerte coherencia de la caché, esta solución no es adecuada. Actualmente, no existe una solución en la industria para garantizar una sólida consistencia de la caché entre regiones.
  2. Se recomienda realizar operaciones en la caché L2 entre regiones en modo asincrónico.