A implantação em várias zonas do Lindorm distribui réplicas entre diferentes zonas para oferecer recuperação de desastres no nível de data center ou cidade, com consistência forte ou eventual por tabela. O failover ocorre de forma automática.
Recursos
Para cargas de trabalho que exigem resiliência contra falhas de servidor, interrupções de rede ou desastres em nível de cidade, a implantação em várias zonas oferece:
Recuperação de desastres no nível de data center ou de cidade.
Suporte tanto para consistência de dados forte quanto eventual.
Detecção automática de falhas e failover sem necessidade de intervenção manual.
Limitações
Clientes de open source, como o cliente do HBase, não oferecem suporte à implantação em várias zonas.
A implantação em várias zonas aplica-se apenas ao LindormTable. Recursos do LindormTable, como índices secundários, colunas dinâmicas e colunas com curingas, são suportados. Recursos dependentes do mecanismo, como índices de pesquisa e índices colunares, não são suportados.
O armazenamento a frio e a separação de dados quentes e frios não são suportados.
Como funciona a implantação em várias zonas
Em uma implantação em várias zonas, cada partição de tabela larga possui uma réplica independente em cada zona. O Lindorm sincroniza as réplicas por meio de seu protocolo de consenso, que exige dados de pelo menos duas réplicas. As entradas de write-ahead log (WAL) são armazenadas no LindormDFS na Zona C. Se a Zona A falhar, o WAL na Zona C restaura os dados para a Zona B.
O Lindorm oferece suporte a dois níveis de consistência: forte e eventual. É necessário que você configure cada tabela de acordo com os seus requisitos.
Consistência forte
Com a consistência forte, todas as leituras e gravações passam pela partição primária. As partições secundárias recebem dados por meio do protocolo de consenso. As leituras sempre retornam os dados gravados mais recentemente.
Se todos os servidores na zona primária forem encerrados ou se a zona ficar indisponível, o Lindorm promove automaticamente uma zona secundária. Isso requer um breve período de transição.
Consistência eventual
A consistência eventual permite leituras e gravações tanto nas partições primárias quanto nas secundárias. Os dados são sincronizados entre as zonas de forma assíncrona, geralmente em até 100 ms.
Os clientes leem e gravam na zona mais próxima. Se os clientes de leitura e gravação estiverem na mesma zona, eles sempre verão os dados mais recentes. Quando uma zona fica indisponível, o Lindorm roteia as solicitações para uma zona disponível sem aguardar a promoção, o que reduz os picos de latência.
A escolha do nível de consistência adequado
As novas tabelas usam a consistência eventual por padrão, o que atende à maioria das cargas de trabalho:
Dados gravados nos últimos 100 ms geralmente podem ser lidos.
Os clientes podem ler e gravar a partir da zona mais próxima.
As partições locais permanecem disponíveis durante interrupções transitórias ou desligamentos de servidores.
Para isso, escolha a consistência forte se você precisar de:
Consistência imediata de leitura após gravação (read-after-write).
Operações atômicas, como Increment e CheckAndPut.
Índices secundários na tabela.
Nota No modo de consistência forte, todas as leituras passam pela partição primária e não podem ser distribuídas entre as réplicas. Se a zona primária falhar, a promoção de uma zona secundária levará algum tempo.
Comparação de arquiteturas
Recuperação de desastres tradicional primária/secundária
Na recuperação de desastres tradicional primária/secundária, duas instâncias são implantadas em zonas separadas. O Lindorm Tunnel Service (LTS) sincroniza os dados bidirecionalmente. Quando a instância ou zona primária falha, você alterna manualmente para a secundária.
Essa abordagem apresenta várias desvantagens:
Sem consistência forte de dados. A sincronização entre instâncias é assíncrona. Durante o failover, a instância secundária pode não ter os dados mais recentes. Operações atômicas, como Increment e CheckAndPut, podem produzir resultados fora de ordem ou revertidos. Problemas de rede na zona primária deixam a secundária incompleta até a recuperação.
Baixa utilização de recursos. A instância secundária fica ociosa, exceto durante o failover.
Failover manual necessário. Você precisa monitorar a instância primária e implementar sua própria lógica de failover.
A implantação em várias zonas resolve esses problemas.
Comparação de recursos
A tabela a seguir compara a implantação em várias zonas, a recuperação de desastres primária/secundária e os protocolos baseados em Paxos/Raft.
|
Recurso |
Implantação de alta disponibilidade em várias zonas |
Recuperação de desastres primária/secundária |
Protocolo de consenso baseado em Paxos ou Raft |
|
|
Consistência forte |
Consistência eventual |
|||
|
Perda de dados (RPO) |
0 |
< 100 ms |
< 1s |
0 |
|
Recuperação de serviço (RTO) |
1 minuto |
10s a 30s |
Depende do tempo de failover |
30 segundos a 3 minutos |
|
Tempo de resposta de acesso |
Acesse dados na zona primária. Leituras e gravações podem cruzar zonas. |
Acesse dados na zona mais próxima. Leituras e gravações vão para várias zonas, reduzindo picos de latência. |
Acesse dados na zona primária. Leituras e gravações podem cruzar zonas. |
Acesse dados na zona primária. Leituras e gravações podem cruzar zonas. |
|
Facilidade de uso |
Sem impacto nas aplicações de negócios. |
Sem impacto nas aplicações de negócios. |
Requer alterações na aplicação. Usa um link de sincronização externo que você gerencia. |
Sem impacto nas aplicações de negócios. |
|
Número mínimo de zonas para logs |
3 |
2 |
2 |
3 |
|
Número mínimo de zonas para dados |
2 |
2 |
2 |
3 |
Em comparação com as alternativas, a implantação em várias zonas oferece acesso a dados mais flexível, menor tempo de recuperação e maior facilidade de uso.
Nota O Lindorm lida com a detecção de falhas e o failover automaticamente para todas as tabelas largas, independentemente do nível de consistência. Conecte-se a uma única instância; nenhum middleware é necessário. Se a sua carga de trabalho não exigir consistência forte, use a consistência eventual para obter menor latência. Se a sua carga de trabalho exigir consistência forte, defina o nível de consistência da tabela como forte.
Comprar uma instância do Lindorm em várias zonas
Para comprar uma instância em várias zonas, crie uma instância no console do Lindorm.
Usar uma instância do Lindorm em várias zonas
Criar uma tabela e configure o nível de consistência
Nota A API do HBase e o HBase Shell não garantem a consistência dos dados. As tabelas criadas por meio da API do HBase ou do HBase Shell usam a consistência eventual por padrão. Em seguida, modifique o atributo CONSISTENCY conforme descrito abaixo.
Conecte-se ao LindormTable com o Lindorm-cli. Use Lindorm-cli to connect to and use LindormTable.
-
Em seguida, configure o atributo CONSISTENCY para a tabela.
Para consistência forte, crie uma tabela: ``
CREATE TABLE dt ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='strong');``Para consistência eventual, crie uma tabela: ``
CREATE TABLE dt2 ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='eventual');``Altere uma tabela para consistência eventual: ``
ALTER TABLE dt SET CONSISTENCY='eventual';``Altere uma tabela para consistência forte: ``
ALTER TABLE dt2 SET CONSISTENCY='strong';``
Gravar dados em uma tabela larga
A gravação de dados em uma instância em várias zonas funciona da mesma forma que em uma instância de zona única. Use Lindorm-cli to connect to and use LindormTable.
Importar dados para uma tabela larga
Para importar dados por meio de uma API, use o endpoint da instância no console do Lindorm. O processo é o mesmo para instâncias em várias zonas.
Com o BulkLoad, importe uma cópia dos dados em cada zona. Entre em contato com technical support para obter assistência.