Exemplos de configurações de replicação

Veja, nesta página, alguns casos de uso comuns para ativar a replicação do Cloud Bigtable. Conheça também as configurações que podem ser usadas nesses casos de uso.

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

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

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

  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.

  5. Monitore o uso de CPU dos clusters da instância e adicione nós aos clusters, se necessário.

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

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

  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.

  5. Monitore o uso de CPU dos clusters da instância e adicione nós aos clusters, se necessário.

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

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 a ser usada neste caso de uso, crie um novo perfil de aplicativo que use o roteamento de vários clusters ou atualize o perfil de aplicativo padrão para usar roteamento de vários clusters. Essa configuração permite consistência posterior. Não será possível ativar transações de linha única porque elas podem causar conflitos de dados quando você usa o roteamento de vários clusters.

Veja as configurações para melhorar a disponibilidade:

  • Dois clusters na mesma região, mas em zonas diferentes. Essa opção fornece alta disponibilidade e capacidade de failover sem gerar custos de replicação entre regiões. Seus dados em uma instância replicada do Cloud Bigtable estão disponíveis desde que as zonas em que eles são replicadas 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 de várias zonas descrita acima, mas seus dados estarão disponíveis mesmo que você não possa se conectar a uma das regiões.

    Você recebe cobranças 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 não seja possível se conectar a uma das regiões e proporciona capacidade adicional na região A.

    Você recebe cobranças 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:

  1. Use o perfil de aplicativo com roteamento de vários clusters para executar uma carga de trabalho de teste.

  2. Use o Console do Google Cloud para monitorar os clusters da instância e confirmar se eles estão manipulando as solicitações de entrada.

  3. Exclua um dos clusters para simular uma interrupção.

    Essa alteração também exclui a cópia dos seus dados armazenada no cluster.

  4. Continue monitorando a latência e as taxas de erro. Se os clusters restantes tiverem recursos de CPU suficientes, eles poderão acompanhar as solicitações recebidas.

  5. 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 disponibilização ficar indisponível, minimize o tempo de inatividade fazendo failover manual para o 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 especificado no perfil de aplicativo processará 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:

  1. Use o perfil de aplicativo 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á manipulando solicitações de entrada.

    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 de modo que ele aponte para o 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 ativado 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.

  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 atender a cada uma com clusters do Cloud Bigtable o mais próximos possível dos clientes. 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. Crie uma instância do Cloud 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ê usa o roteamento de vários clusters, o Cloud Bigtable manipula failovers automaticamente. Se você usa roteamento de cluster único, use o bom senso para decidir quando fazer failover para outro cluster.

Opção de roteamento de vários clusters

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

Para implementar essa configuração, 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 permite consistência posterior. Se uma região ficar indisponível, as solicitações do Cloud 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.

É possível usar apenas um perfil de aplicativo com roteamento de vários clusters por instância, e não é possível usar uma combinação de perfis de roteamento de vários clusters e de clusters únicos. Uma instância usa um ou outro.

Quando você configura inicialmente sua instância, tente não exceder 35% do uso 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:

  1. Execute uma carga de trabalho de teste.

  2. Use o Console do Cloud para monitorar os clusters da instância e confirmar se os quatro clusters estão manipulando solicitações de entrada.

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

  4. Continue monitorando a latência e as taxas de erro dos clusters restantes.

    Se os clusters tiverem recursos de CPU suficientes, eles poderão dar conta das solicitações recebidas.

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

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

  7. Continue monitorando a latência e as taxas de erro dos clusters restantes.

    Se os clusters tiverem recursos de CPU suficientes, eles poderão dar conta das 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.

Opção de roteamento de cluster único

É possível usar o roteamento de cluster único para este caso de uso, se você não quiser que o cluster do Cloud Bigtable efetue failover 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 Cloud Bigtable iniciar o roteamento de tráfego para e de uma região distante. Use-a também se preferir tomar decisões de failover com base no seu bom senso ou nas regras de negócios.

Para implementar essa configuração, crie quatro perfis de aplicativo que usem roteamento de cluster único. Cada perfil de aplicativo é encaminhado para um cluster diferente na instância do Cloud Bigtable.

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.

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 Cloud Bigtable, é possível criar uma instância com clusters em várias regiões do Google Cloud, e seus dados são replicados automaticamente em cada região.

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.

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

  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