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 nestes casos de uso:

Você também saberá como 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.

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 encaminhamento de cluster único para encaminhar 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 aplicativos, um chamado live-traffic e o outro, batch-analytics.

    Se os códigos do cluster forem cluster-a e cluster-b, o perfil de aplicativo live-traffic encaminhará as solicitações para cluster-a. Já o perfil batch-analytics as encaminhará para cluster-b. Essa configuração permite consistência na leitura das gravações para todos os aplicativos que usam esses perfis.

    É possível ativar transações em linha única no perfil de aplicativo live-traffic se necessário. Caso você só use o perfil batch-analytics para leituras, não é preciso ativar transações desse tipo nele.

  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 sendo executada, use o perfil de aplicativo batch-analytics para executar uma carga de trabalho em lote de 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, presumimos que seus clusters usam os códigos cluster-a, cluster-b e cluster-c.

    Use o mesmo número de nós no cluster-a e no cluster-b se eles estiverem atendendo ao mesmo aplicativo. Use um número maior de nós no cluster-c para ser compatível com a carga de trabalho maior.

  2. Crie os seguintes perfis de aplicativos:

    • live-traffic-app-a: encaminhamento de cluster único do seu aplicativo para o cluster-a
    • live-traffic-app-b: encaminhamento de cluster único do seu aplicativo para o cluster-b
    • batch-analytics: encaminhamento de cluster único do job de análise em lote para cluster-c
  3. Use os perfis de aplicativos live-traffic para executar cargas de trabalho de tráfego em tempo real.

  4. Enquanto as cargas de trabalho em tempo real estiverem sendo executadas, use o perfil de aplicativo batch-analytics para executar uma carga de trabalho em lote de 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.

Melhorar a 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 encaminhamento de vários clusters ou atualize o perfil de aplicativo padrão para usar encaminhamento de vários clusters. Essa configuração permite consistência eventual. Não será possível habilitar transações de linha única porque elas podem causar conflitos de dados quando você usar o encaminhamento de vários clusters.

As configurações para melhorar a disponibilidade incluem:

  • Dois clusters na mesma região, mas em diferentes zonas. 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 diferentes regiões. Essa configuração de várias regiões fornece alta disponibilidade, como a configuração de várias zonas descrita acima, 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. Se você gravar na região A, será cobrado uma vez, porque terá apenas um cluster na região B. Se você gravar na região B, será cobrado duas vezes, porque terá 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 encaminhamento de vários clusters para executar uma carga de trabalho de teste.

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

  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 as taxas de latência e 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á encaminhar 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 encaminhamento de cluster único ou atualize o perfil de aplicativo padrão para usar encaminhamento 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 e oferece consistência forte e consistência na leitura de gravações. É possível habilitar 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 encaminhamento de cluster único para executar uma carga de trabalho.

  2. Use o Console do Google Cloud Platform para monitorar os clusters da instância e confirme se apenas um cluster está lidando com as solicitações recebidas.

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

  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 se não é possível se conectar a uma região do GCP. 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 encaminhamento de vários clusters ou o encaminhamento 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-a em Tóquio
  2. Coloque um servidor de aplicativos perto de cada região.

Opte por usar o encaminhamento de vários clusters ou o encaminhamento de cluster único para esse caso de uso, dependendo das necessidades do seu negócio. Se você usa o encaminhamento de vários clusters, o Cloud Bigtable lida com 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 encaminhamento de vários clusters

Use o encaminhamento de vários clusters se você estiver implementando esse caso de uso e quiser que o Cloud Bigtable efetue failover automaticamente em 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 encaminhamento de vários clusters 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 Cloud Bigtable serão enviadas automaticamente para a outra região. Quando isso acontece, você é cobrado 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 encaminhamento de vários clusters por instância, e não é possível usar uma combinação de perfis de encaminhamento 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 GCP para monitorar os clusters da instância e confirme se todos os quatro clusters estão manipulando solicitações recebidas.

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

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

Opção de encaminhamento de cluster único

É possível usar o encaminhamento 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 encaminhamento 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 aplicativos que usam encaminhamento 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 optar por 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 GCP, e seus dados são replicados automaticamente em cada uma delas.

Para este caso de uso, use perfis de aplicativos com encaminhamento de cluster único. O encaminhamento 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 aplicativos semelhantes aos seguintes:

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

Nesta configuração, seu aplicativo usa o perfil do aplicativo para o 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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud Bigtable