Exemplos de configurações de replicação

Nesta página, descrevemos alguns casos de uso comuns para ativar a replicação do Bigtable e apresentamos as configurações que podem ser usadas nesses casos de uso.

Isolar cargas de trabalho de análise em lote de outros aplicativos
Criar alta disponibilidade
Criar backup quase em tempo real
Manter alta disponibilidade e resiliência regional
Armazenar dados perto de seus usuários

Você também saberá determinar quais configurações usar se seu caso de uso não estiver listado aqui.

Antes de ler esta página, familiarize-se com a visão geral da replicação do Bigtable.

Antes de adicionar clusters a uma instância, esteja ciente das restrições que se aplicam quando você altera as políticas de coleta de lixo nas tabelas replicadas.

Independentemente do caso de uso, sempre provisione nós suficientes em cada cluster em uma instância para garantir que cada cluster lide com a replicação, além da carga que recebe dos aplicativos. Caso um cluster não tenha nós suficientes, o atraso de replicação pode aumentar e talvez ele tenha problemas de desempenho devido ao acúmulo de memória e as gravações em outros clusters na instância podem ser rejeitadas.

Isolar cargas de trabalho de análise em lote de outros aplicativos

Quando você usa um único cluster para executar um job de análise em lote que desempenha várias leituras grandes ao lado de um aplicativo que realiza uma mescla de leituras e gravações, o job em lote grande pode atrasar as tarefas para os usuários do aplicativo. Com a replicação, é possível usar perfis de aplicativos com roteamento de cluster único para rotear jobs de análise em lote e tráfego de aplicativos até clusters diferentes. Assim, os jobs em lote não afetarão os usuários de seus aplicativos.

Para isolar duas cargas de trabalho:

Crie uma nova instância com dois clusters ou adicione um segundo cluster a uma instância atual.

Siga as recomendações padrão de uso da CPU para essa configuração.
Crie dois perfis de aplicativo, um chamado live-traffic e outro batch-analytics.

Se os IDs de cluster forem cluster-a e cluster-b, o perfil de aplicativo live-traffic deverá rotear solicitações para cluster-a e o perfil de aplicativo batch-analytics deverá rotear solicitações para cluster-b. Essa configuração fornece consistência na leitura de gravações em aplicativos que usam o mesmo perfil de aplicativo, mas não em aplicativos que usam perfis diferentes.

É possível ativar transações de linha única no perfil de aplicativo live-traffic, se necessário. Não é preciso ativar transações de linha única no perfil de aplicativo batch-analytics, supondo que ele só seja usado para leituras.
Use o perfil de aplicativo live-traffic para executar uma carga de trabalho de tráfego em tempo real.
Enquanto a carga de trabalho de tráfego em tempo real estiver em execução, use o perfil de aplicativo batch-analytics para executar uma carga de trabalho em lote somente leitura.
Monitore o uso de CPU dos clusters da instância e adicione nós aos clusters se necessário.
Monitore a latência do cliente usando a ferramenta de sua preferência. Se você usa o cliente HBase para Java, pode monitorar a latência usando as métricas do cliente.

Para isolar duas cargas de trabalho menores de uma carga de trabalho maior:

Crie uma nova instância com três clusters ou adicione clusters a uma instância atual até que ela tenha três clusters.

Siga as recomendações padrão de uso da CPU para essa configuração.

Nessas etapas, supõe-se que seus clusters usam os IDs cluster-a, cluster-b e cluster-c.

Use o mesmo número de nós em cluster-a e cluster-b se eles estiverem exibindo o mesmo aplicativo. Use um número maior de nós em cluster-c para aceitar a carga de trabalho maior.
Crie os seguintes perfis de aplicativo:
- live-traffic-app-a: roteamento de cluster único do seu aplicativo para cluster-a
- live-traffic-app-b: roteamento de cluster único do seu aplicativo para cluster-b
- batch-analytics: roteamento de cluster único do job de análise de lote para cluster-c
Use os perfis de aplicativo "live-traffic" para executar cargas de trabalho de tráfego em tempo real.
Enquanto as cargas de trabalho de tráfego em tempo real estiverem em execução, use o perfil de aplicativo batch-analytics para executar uma carga de trabalho em lote somente leitura.
Monitore o uso de CPU dos clusters da instância e adicione nós aos clusters se necessário.
Monitore a latência do cliente usando a ferramenta de sua preferência. Se você usa o cliente HBase para Java, pode monitorar a latência usando as métricas do cliente.

Criar alta disponibilidade (HA, na sigla em inglês)

Se uma instância tiver apenas um cluster, a durabilidade e a disponibilidade dos seus dados estarão limitadas à zona em que o cluster estiver. A replicação pode melhorar a durabilidade e a disponibilidade armazenando cópias separadas de seus dados em várias zonas ou regiões e fazendo failover automático entre clusters se necessário.

Para configurar a instância para um caso de uso de alta disponibilidade (HA, na sigla em inglês), crie um novo perfil de aplicativo que use o roteamento de vários clusters ou atualize o perfil de aplicativo padrão para usar o roteamento de vários clusters. Essa configuração oferece consistência posterior. Não será possível ativar transações de linha única, porque elas podem causar conflitos de dados ao usar o roteamento de vários clusters.

Para saber mais sobre como o Bigtable ajuda a alcançar alta disponibilidade, consulte Como criar uma presença de dados global com o Bigtable .

Veja as configurações para melhorar a disponibilidade:

Clusters em três ou mais regiões diferentes (configuração recomendada). A configuração recomendada para HA é uma instância que tenha clusters N+2 em uma região diferente. Por exemplo, se o número mínimo de clusters necessários para exibir os dados for dois, você precisará de uma instância de quatro clusters para manter a alta disponibilidade. Essa configuração oferece tempo de atividade mesmo no caso raro de duas regiões ficarem indisponíveis. Recomendamos que você distribua os clusters por vários continentes.

Exemplo de configuração:
- cluster-a na zona us-central1-a em Iowa
- cluster-b na zona europe-west1-d na Bélgica
- cluster-c na zona asia-east1-b em Taiwan
Para essa configuração, provisione nós suficientes para manter uma meta de 23% de utilização da CPU para uma instância de três clusters em três regiões e 35% de utilização da CPU para uma instância de quatro clusters em quatro regiões. Isso garante que, mesmo que duas regiões estejam indisponíveis, o cluster ou os clusters restantes possam exibir todo o tráfego.
Dois clusters na mesma região, mas em zonas diferentes. Essa opção oferece alta disponibilidade na disponibilidade da região, capacidade de fazer failover sem gerar custos de replicação entre regiões e não aumenta a latência no failover. Seus dados em uma instância replicada do Bigtable ficam disponíveis desde que as zonas em que eles são replicados estejam disponíveis.

Exemplo de configuração:
- cluster-a na zona australia-southeast1-a em Sydney
- cluster-b na zona australia-southeast1-b em Sydney
Siga as recomendações padrão de uso da CPU para essa configuração.
Dois clusters em regiões diferentes. Essa configuração de várias regiões fornece alta disponibilidade, como a configuração anterior de várias zonas, mas seus dados estão disponíveis mesmo que você não possa se conectar a uma das regiões.

Você é cobrado por replicar gravações entre regiões.

Exemplo de configuração:
- cluster-a na zona asia-northeast1-c em Tóquio
- cluster-b na zona asia-east2-b em Hong Kong
Siga as recomendações padrão de uso da CPU para essa configuração.
Dois clusters na região A e um terceiro cluster na região B. Essa opção disponibiliza seus dados mesmo que você não possa se conectar a uma das regiões e fornece capacidade adicional na região A.

Você é cobrado por replicar gravações entre regiões. Ao gravar na região A, você receberá uma cobrança porque tem apenas um cluster na região B. Ao gravar na região B, haverá duas cobranças porque há dois clusters na região A.

Exemplo de configuração:
- cluster-a na zona europe-west1-b na Bélgica
- cluster-b na zona europe-west1-d na Bélgica
- cluster-c na zona europe-north1-c na Finlândia
Comece com uma meta de 35% de uso da CPU na região com dois clusters e 70% na outra região. Monitore os clusters da instância e ajuste o número de nós, conforme necessário, para que cada cluster tenha recursos suficientes para manipular um failover.

É possível simular failover para este caso de uso para testar seu aplicativo:

Use o perfil de aplicativo com roteamento de vários clusters para executar uma carga de trabalho de teste.
Use o console do Google Cloud para monitorar os clusters da instância e confirmar se eles estão processando as solicitações recebidas.
Exclua um dos clusters para simular uma interrupção.

Essa alteração também exclui a cópia dos seus dados armazenada no cluster.
Continue monitorando as taxas de latência e erro. Se os clusters restantes tiverem recursos de CPU suficientes, eles poderão acompanhar as solicitações recebidas.
Adicione um cluster à instância e continue monitorando-a. Os dados começarão a ser replicados para o novo cluster.

Criar backup quase em tempo real

Em alguns casos (por exemplo, se não puder ler dados desatualizados), você sempre precisará rotear solicitações para um único cluster. No entanto, você ainda pode usar a replicação processando as solicitações com um cluster e mantendo outro cluster como backup quase em tempo real. Se o cluster de serviço ficar indisponível, será possível minimizar o tempo de inatividade realizando um failover manual no cluster de backup.

Para configurar a instância a ser usada neste caso de uso, crie um perfil de aplicativo com roteamento de cluster único ou atualize o perfil de aplicativo padrão para usar roteamento de cluster único. O cluster que você especificou no perfil de aplicativo processa as solicitações recebidas. O outro cluster age como backup caso seja necessário realizar um failover. Essa estrutura, às vezes chamada de configuração ativa-passiva, oferece consistência forte e consistência na leitura de gravações. É possível ativar transações de linha única no perfil de aplicativo, se necessário.

Siga as recomendações padrão de uso da CPU para essa configuração.

Para implementar esta configuração:

Use o perfil de aplicativo com roteamento de cluster único para executar uma carga de trabalho.
Use o console do Google Cloud para monitorar os clusters da instância e confirmar se apenas um cluster está processando as solicitações recebidas.

O outro cluster continua usando os recursos da CPU para realizar a replicação e outras tarefas de manutenção.
Atualize o perfil de aplicativo para que ele direcione ao segundo cluster da instância.

Você receberá um aviso sobre a perda da consistência de leitura das gravações, o que significa que também haverá uma perda de consistência forte.

Caso tenha habilitado as transações de linha única, você também receberá um aviso sobre possível perda de dados. Você perderá dados caso haja gravações conflitantes no momento em que o failover estiver sendo realizado.
Continue a monitorar a instância. Você verá que o segundo cluster está processando as solicitações recebidas.

Manter alta disponibilidade e resiliência regional

Digamos que você tenha concentrações de clientes em duas regiões distintas em um continente. Você quer disponibilizar cada concentração de clientes com clusters do Bigtable o mais perto possível deles. Também quer que seus dados estejam altamente disponíveis em cada região e talvez queira uma opção de failover, se um ou mais de seus clusters não estiverem disponíveis.

Para este caso de uso, é possível criar uma instância com dois clusters na região A e dois clusters na região B. Essa configuração fornece alta disponibilidade, mesmo que você não consiga se conectar a uma região do Google Cloud. Ela também fornece resiliência regional porque, mesmo que uma zona fique indisponível, o outro cluster na região dessa zona ainda estará disponível.

Opte por usar o roteamento de vários clusters ou o roteamento de cluster único para esse caso de uso, dependendo das necessidades do seu negócio.

Para configurar sua instância para este caso de uso:

Crie uma instância do Bigtable com quatro clusters: dois na região A e dois na região B. Os clusters na mesma região precisam estar em zonas diferentes.

Exemplo de configuração:
- cluster-a na zona asia-south1-a em Mumbai
- cluster-b na zona asia-south1-c em Mumbai
- cluster-c na zona asia-northeast1-a em Tóquio
- cluster-d na zona asia-northeast1-b em Tóquio
Coloque um servidor de aplicativos perto de cada região.

Opte por usar o roteamento de vários clusters ou o roteamento de cluster único para esse caso de uso, dependendo das necessidades do seu negócio. Se você usar o roteamento de vários clusters, o Bigtable processará failovers automaticamente. Se você optar pelo encaminhamento de cluster único, use o bom senso para decidir quando fazer o failover para um cluster diferente.

Opção de roteamento de cluster único

Use o roteamento de cluster único para esse caso de uso se não quiser que o cluster do Bigtable falhe automaticamente se uma zona ou região ficar indisponível. Essa é uma boa opção para gerenciar os custos e a latência que podem ocorrer se o Bigtable iniciar o roteamento do tráfego para e de uma região distante, ou se você preferir tomar decisões de failover com base nos seus julgamentos ou regras comerciais.

Para implementar essa configuração, crie pelo menos um perfil de aplicativo que use encaminhamento de cluster único para cada aplicativo que envia solicitações para a instância. Você pode rotear os perfis do aplicativo para qualquer cluster na instância do Bigtable. Por exemplo, se você tiver três aplicativos em execução em Mumbai e seis em Tóquio, poderá configurar um perfil de aplicativo para o aplicativo de Mumbai para rotear para asia-south1-a e dois para rotear paraasia-south1-c. Para o aplicativo de Tóquio, configure três perfis de aplicativos que fazem o roteamento para asia-northeast1-a e três para essa rota para asia-northeast1-b.

Siga as recomendações padrão de uso da CPU para essa configuração.

Com essa configuração, se um ou mais clusters ficarem indisponíveis, será possível executar um failover manual ou deixar seus dados temporariamente indisponíveis nessa zona até que ela esteja disponível novamente.

Opção de roteamento de vários clusters

Se você estiver implementando esse caso de uso e quiser que o Bigtable faça o failover automaticamente para uma região se seu aplicativo não puder alcançar a outra região, use o roteamento de vários clusters.

Para implementar essa configuração,crie um novo perfil de aplicativo que usa roteamento de vários clusters para cada aplicativo ou atualize o perfil de aplicativo padrão para usar o encaminhamento de vários clusters.

Essa configuração permite consistência eventual. Se uma região ficar indisponível, as solicitações do Bigtable serão enviadas automaticamente para a outra região. Quando isso acontece, você recebe cobranças pelo tráfego de rede para a outra região e seu aplicativo pode ter uma latência maior devido ao aumento da distância.

Quando você configura inicialmente sua instância, não exceda 35% de utilização da CPU para cada cluster. Essa meta assegura que cada cluster possa manipular o tráfego normalmente tratado pelo outro cluster na respectiva região, se ocorrer um failover. Pode ser necessário ajustar essa meta, dependendo dos padrões de tráfego e uso.

É possível simular failover para este caso de uso para testar seu aplicativo:

Execute uma carga de trabalho de teste.
Use o Console do Google Cloud para monitorar os clusters da instância e confirme se todos os quatro clusters estão manipulando solicitações recebidas.
Exclua um dos clusters na região A para simular um problema na conexão com uma zona.

Essa alteração também exclui a cópia dos seus dados armazenada no cluster.
Continue a monitorar a latência e as taxas de erro dos clusters que sobraram.

Se os clusters tiverem recursos de CPU suficientes, eles poderão acompanhar as solicitações recebidas.
Adicione um cluster à instância na região A e continue monitorando a instância.

Os dados começarão a ser replicados para o novo cluster.
Exclua os dois clusters na região A para simular um problema na conexão com uma região.

Essa alteração exclui as cópias de seus dados que estavam nesses clusters.
Continue a monitorar a latência e as taxas de erro dos clusters que sobraram.

Se os clusters tiverem recursos de CPU suficientes, eles poderão acompanhar as solicitações de entrada que foram manipuladas anteriormente pela outra região. Se os clusters não tiverem recursos suficientes, talvez seja necessário ajustar o número de nós.

Armazenar dados perto de seus usuários

Se você tiver usuários em todo o mundo, poderá reduzir a latência executando o aplicativo próximo aos usuários e colocando os dados o mais perto possível do aplicativo. Com o Bigtable, é possível criar uma instância que tenha clusters em várias regiões do Google Cloud, e seus dados são replicados automaticamente em cada uma delas.

Para este caso de uso, use perfis de aplicativo com roteamento de cluster único. O roteamento de vários clusters não é recomendável para este caso de uso devido à distância entre os clusters. Se um cluster ficar indisponível e o respectivo perfil de aplicativo de vários clusters redirecionar automaticamente o tráfego por uma grande distância, seu aplicativo poderá passar por uma latência inaceitável e gerar custos de rede adicionais inesperados.