El despliegue multizona de Lindorm distribuye las réplicas entre distintas zonas para lograr una recuperación ante desastres en el centro de datos o la ciudad. Cada tabla admite consistencia fuerte o eventual, y la conmutación por error se ejecuta automáticamente.
Funciones
Para cargas de trabajo que exigen resistencia ante fallas de servidor, interrupciones de red o desastres en la ciudad, el despliegue multizona ofrece lo siguiente:
Recuperación ante desastres en el centro de datos o la ciudad.
Compatibilidad con consistencia de datos fuerte y eventual.
Detección automática de fallas y conmutación por error sin intervención manual.
Limitaciones
Los clientes de código abierto, como el cliente de HBase, no admiten el despliegue multizona.
El despliegue multizona solo aplica para LindormTable. Las funciones de LindormTable, como índices secundarios, columnas dinámicas y columnas comodín, son compatibles. Las funciones dependientes del motor, como los índices de búsqueda y los índices columnares, no lo son.
No se admite el almacenamiento en frío ni la separación de datos fríos y calientes.
Cómo funciona el despliegue multizona
En un despliegue multizona, cada partición de tabla ancha tiene una réplica independiente en cada zona. Lindorm sincroniza las réplicas mediante su protocolo de consenso, el cual requiere datos de como mínimo dos réplicas. Las entradas del registro de escritura anticipada (WAL) se almacenan en LindormDFS dentro de la Zona C. Si la Zona A falla, el WAL de la Zona C restaura los datos hacia la Zona B.
Lindorm admite dos niveles de consistencia: fuerte y eventual. Configure cada tabla según sus necesidades.
Consistencia fuerte
Con la consistencia fuerte, todas las lecturas y escrituras pasan por la partición principal. Las particiones secundarias reciben los datos a través del protocolo de consenso. Las lecturas siempre devuelven los datos escritos más recientemente.
Si todos los servidores de la zona principal se detienen o la zona deja de estar disponible, Lindorm promueve automáticamente una zona secundaria. Este proceso requiere un breve periodo de transición.
Consistencia eventual
La consistencia eventual permite lecturas y escrituras tanto en las particiones principales como en las secundarias. Los datos se sincronizan entre zonas de forma asíncrona, por lo general en menos de 100 ms.
Los clientes leen y escriben en la zona más cercana. Si los clientes de lectura y escritura están en la misma zona, siempre ven los datos más recientes. Cuando una zona deja de estar disponible, Lindorm enruta las solicitudes a una zona disponible sin esperar a que se promueva otra. Esto reduce los picos de latencia.
Cómo elegir el nivel de consistencia adecuado
Las tablas nuevas usan consistencia eventual de forma predeterminada, lo cual es adecuado para la mayoría de las cargas de trabajo:
Por lo general, se pueden leer los datos escritos en los últimos 100 ms.
Los clientes leen y escriben desde la zona más cercana.
Las particiones locales siguen disponibles durante interrupciones transitorias o apagados de servidor.
Elija la consistencia fuerte si necesita lo siguiente:
Consistencia inmediata de lectura tras escritura.
Operaciones atómicas como Increment y CheckAndPut.
Índices secundarios en la tabla.
Nota: En el modo de consistencia fuerte, todas las lecturas pasan por la partición principal y no se distribuyen entre las réplicas. Si la zona principal falla, promover una zona secundaria toma tiempo.
Comparación de arquitecturas
Recuperación ante desastres tradicional principal/secundaria
En la recuperación ante desastres tradicional principal/secundaria, se despliegan dos instancias en zonas separadas. Lindorm Tunnel Service (LTS) sincroniza los datos de forma bidireccional. Cuando la instancia o la zona principal falla, cambie manualmente a la secundaria.
Este enfoque presenta varios inconvenientes:
Sin consistencia fuerte de datos. La sincronización entre instancias es asíncrona. Durante la conmutación por error, la instancia secundaria podría carecer de los datos más recientes. Las operaciones atómicas como Increment y CheckAndPut podrían generar resultados fuera de orden o revertidos. Además, los problemas de red en la zona principal dejan incompleta a la secundaria hasta que se resuelvan.
Baja utilización de recursos. La instancia secundaria permanece inactiva, excepto durante la conmutación por error.
Conmutación por error manual. Supervise la instancia principal e implemente su propia lógica de conmutación.
El despliegue multizona resuelve estos problemas.
Comparación de funciones
A continuación se comparan el despliegue multizona, la recuperación ante desastres principal/secundaria y los protocolos basados en Paxos o Raft.
|
Función |
Despliegue de alta disponibilidad multizona |
Recuperación ante desastres principal/secundaria |
Protocolo de consenso basado en Paxos o Raft |
|
|
Consistencia fuerte |
Consistencia eventual |
|||
|
Pérdida de datos (RPO) |
0 |
< 100 ms |
< 1 s |
0 |
|
Recuperación del servicio (RTO) |
1 minuto |
De 10 s a 30 s |
Depende del tiempo de conmutación |
De 30 segundos a 3 minutos |
|
Tiempo de respuesta de acceso |
Acceso a los datos en la zona principal. Las lecturas y escrituras pueden cruzar zonas. |
Acceso a los datos en la zona más cercana. Las lecturas y escrituras se dirigen a varias zonas, lo que reduce los picos de latencia. |
Acceso a los datos en la zona principal. Las lecturas y escrituras pueden cruzar zonas. |
Acceso a los datos en la zona principal. Las lecturas y escrituras pueden cruzar zonas. |
|
Facilidad de uso |
Sin impacto en las aplicaciones empresariales. |
Sin impacto en las aplicaciones empresariales. |
Requiere cambios en la aplicación. Usa un enlace de sincronización externo que usted gestiona. |
Sin impacto en las aplicaciones empresariales. |
|
Número mínimo de zonas para registros |
3 |
2 |
2 |
3 |
|
Número mínimo de zonas para datos |
2 |
2 |
2 |
3 |
Frente a las alternativas, el despliegue multizona ofrece un acceso a los datos más flexible, un tiempo de recuperación más corto y mayor facilidad de uso.
Nota: Lindorm detecta fallas y ejecuta la conmutación por error automáticamente para todas las tablas anchas, sin importar el nivel de consistencia. Conéctese a una sola instancia; no se requiere middleware. Si su carga de trabajo no exige consistencia fuerte, use la consistencia eventual para obtener menor latencia. Si la carga de trabajo sí la requiere, establezca el nivel de consistencia de la tabla en strong.
Comprar una instancia de Lindorm multizona
Para comprar una instancia multizona, cree una instancia en la consola de Lindorm.
Usar una instancia de Lindorm multizona
Crear una tabla y configurar el nivel de consistencia
Nota: La API de HBase y HBase Shell no garantizan la consistencia de los datos. Las tablas creadas mediante la API de HBase o HBase Shell usan consistencia eventual de forma predeterminada. Modifique el atributo CONSISTENCY como se describe a continuación.
Conéctese a LindormTable con Lindorm-cli. Use Lindorm-cli to connect to and use LindormTable.
-
Configure el atributo CONSISTENCY de la tabla.
Cree una tabla con consistencia fuerte: ``
CREATE TABLE dt ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='strong');``Cree una tabla con consistencia eventual: ``
CREATE TABLE dt2 ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='eventual');``Cambie una tabla a consistencia eventual: ``
ALTER TABLE dt SET CONSISTENCY='eventual';``Cambie una tabla a consistencia fuerte: ``
ALTER TABLE dt2 SET CONSISTENCY='strong';``
Escribir datos en una tabla ancha
Escribir datos en una instancia multizona funciona igual que en una instancia de una sola zona. Use Lindorm-cli to connect to and use LindormTable.
Importar datos a una tabla ancha
Para importar datos mediante una API, use el endpoint de la instancia desde la consola de Lindorm. El proceso es el mismo para las instancias multizona.
Con BulkLoad, importe una copia de los datos en cada zona. Póngase en contacto con soporte técnico para obtener asistencia.