Recuperación ante desastres 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.
Para cumplir con los requisitos de confiabilidad de sus datos y servicios, puede optar por implementar 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 un fallo de proceso, se inicia un nuevo proceso para garantizar el HA del servicio.
Instancia principal/en standby de DCS: Los datos se mantienen en el disco en el nodo principal y se sincronizan y persisten incrementalmente en el nodo en standby, logrando la persistencia de los datos y en standby caliente.
Instancia de clúster de DCS: Similar a una instancia principal/en standby, los datos de cada partición (proceso de instancia) de una instancia de clúster se sincronizan entre los nodos principal y en standby y se mantienen en ambos nodos.
DR entre las AZ dentro de una región
Los nodos principal y en standby de una instancia de DCS principal/en standby o de clúster se pueden implementar a través de 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 un fallo en el AZ donde se despliega el nodo principal, el nodo en standby se conecta al cliente y se hace cargo de las operaciones de lectura y escritura de datos.
Este mecanismo se aplica de manera similar a una instancia de clúster de DCS, en la que cada partición (proceso) se implementa a través de AZ.
Al crear una instancia principal/en standby de DCS, seleccione una AZ en standby que sea diferente de la AZ principal como se muestra a continuación.
También puede implementar 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.
Multiactividad 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 standby.
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.
Nota:
- 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.
- Se recomienda realizar operaciones en la caché L2 entre regiones en modo asincrónico.
