Exemplos de configurações de replicação

Esta página descreve alguns casos de uso comuns para a replicação do Bigtable e apresenta as configurações que podem ser usadas para oferecer suporte a esses casos.

Esta página também explica como decidir quais configurações usar para outros casos de uso.

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.

Na maioria dos casos, ative o escalonamento automático para os clusters da sua instância. Com o escalonamento automático, o Bigtable adicionar e remover nós automaticamente em um cluster com base na carga de trabalho.

Se você escolher a alocação manual de nós, provisione nós suficientes em todos os clusters em uma instância, para garantir que eles possam processar replicação, além da carga que recebe dos aplicativos. Se um cluster não tiver nós suficientes, o atraso de replicação pode aumentar, o cluster enfrentar problemas de desempenho devido ao acúmulo de memória e realizar gravações em outros clusters na instância podem ser rejeitados.

Os exemplos neste documento descrevem a criação de uma instância, mas você também pode adicionar clusters a uma instância existente.

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:

  1. Criar uma instância com dois clusters.

  2. Crie dois perfis de app, um com o nome live-traffic. e outra chamada 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.

  3. Use o perfil de aplicativo live-traffic para executar uma carga de trabalho de tráfego em tempo real.

  4. 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.

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

  1. Crie uma instância com três clusters.

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

  2. 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

  3. Use os perfis de aplicativo "live-traffic" para executar cargas de trabalho de tráfego em tempo real.

  4. 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.

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.

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 alta disponibilidade é uma instância que tem N+2 clusters, cada um em uma região diferente. Por exemplo, se o número mínimo de clusters necessários para exibir os dados for 2, você vai precisar de uma instância com quatro clusters para manter a HA. 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

  • 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

  • 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

  • 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. Se você gravar na região A, vai receber uma cobrança porque tem apenas um cluster na região B. Se você gravar na região B, será cobrado duas vezes, 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

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, você poderá minimizar o tempo de inatividade realizando um failover manual no cluster de backup.

Se quiser configurar sua instância para este caso de uso, crie um perfil de aplicativo que use roteamento de cluster único ou atualize o padrão perfil de aplicativo para usar o 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.

Para implementar esta configuração:

  1. Use um perfil de app com roteamento de cluster único para executar uma carga de trabalho.

  2. Use o console do Google Cloud para monitorar os clusters da instância e confirme se apenas um cluster está processando as entradas solicitações.

    O outro cluster continua usando os recursos da CPU para realizar a replicação e outras tarefas de manutenção.

  3. Atualize o perfil de aplicativo para que ele direcione ao segundo cluster da instância.

    Você recebe 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.

    Se você tiver ativado as transações de linha única, também receberá um aviso sobre a possível perda de dados. Você perde dados se enviar gravações conflitantes enquanto o failover estiver ocorrendo.

  4. 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:

  1. Criar 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

  2. 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.

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.

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.

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

  1. Crie uma instância com clusters em três regiões geográficas distintas, como Estados Unidos, Europa e Ásia.

  2. Coloque um servidor de aplicativos perto de cada região.

  3. Crie perfis de aplicativo semelhantes aos seguintes:

    • clickstream-us: roteamento de cluster único para o cluster nos Estados Unidos
    • clickstream-eu: roteamento de cluster único para o cluster na Europa
    • clickstream-asia: roteamento de cluster único para o cluster na Ásia

Nesta configuração, seu aplicativo usa o perfil de aplicativo referente ao cluster mais próximo. As gravações em qualquer cluster são automaticamente replicadas para os outros dois clusters.

Outros casos de uso

Se o caso de uso não estiver descrito nesta página, use as perguntas abaixo para decidir como configurar os perfis de aplicativo:

A seguir