Exemplos de configurações de replicação

Esta página descreve alguns exemplos de utilização comuns da replicação do Bigtable e apresenta as definições que pode usar para suportar estes exemplos de utilização.

Esta página também explica como decidir que definições usar para outros exemplos de utilização.

Antes de ler esta página, deve conhecer a vista geral da replicação do Bigtable.

Antes de adicionar clusters a uma instância, deve ter em atenção as restrições que se aplicam quando altera as políticas de recolha de lixo em tabelas replicadas.

Na maioria dos casos, ative o ajuste de escala automático para os clusters da instância. O dimensionamento automático permite que o Bigtable adicione e remova automaticamente nós de um cluster com base na carga de trabalho.

Se optar pela atribuição manual de nós, provisione nós suficientes em cada cluster numa instância para garantir que cada cluster consegue processar a replicação, além da carga que recebe das aplicações. Se um cluster não tiver nós suficientes, o atraso na replicação pode aumentar, o cluster pode ter problemas de desempenho devido à acumulação de memória e as gravações noutros clusters na instância podem ser rejeitadas.

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

Isole as cargas de trabalho de estatísticas em lote de outras aplicações

Quando usa um único cluster para executar uma tarefa de estatísticas em lote que realiza inúmeras leituras grandes, juntamente com uma aplicação que realiza uma combinação de leituras e escritas, a tarefa em lote grande pode tornar as coisas mais lentas para os utilizadores da aplicação. Com a replicação, pode usar perfis de apps com o encaminhamento de cluster único para encaminhar tarefas de estatísticas em lote e tráfego de aplicações para diferentes clusters, de modo que as tarefas em lote não afetem os utilizadores das suas aplicações.

Para isolar duas cargas de trabalho:

  1. Crie uma instância com dois clusters.

  2. Cria dois perfis de apps, um denominado live-traffic e outro denominado batch-analytics.

    Se os IDs dos clusters forem cluster-a e cluster-b, o perfil da app live-traffic deve encaminhar pedidos para cluster-a e o perfil da app batch-analytics deve encaminhar pedidos para cluster-b. Esta configuração oferece consistência de leitura das suas escritas para aplicações que usam o mesmo perfil de app, mas não para aplicações que usam perfis de app diferentes.

    Se necessário, pode ativar as transações de linha única no perfil da app live-traffic. Não é necessário ativar as transações de linha única no perfil da app batch-analytics, partindo do princípio de que só vai usar este perfil da app para leituras.

  3. Use o perfil da app live-traffic para executar uma carga de trabalho de tráfego em direto.

  4. Enquanto a carga de trabalho de tráfego em direto está em execução, use o perfil da app batch-analytics para executar uma carga de trabalho em lote só de leitura.

Para isolar duas cargas de trabalho mais pequenas de uma carga de trabalho maior:

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

    Estes passos pressupõem que os seus clusters usam os IDs cluster-a, cluster-b e cluster-c.

  2. Crie os seguintes perfis de apps:

    • live-traffic-app-a: Encaminhamento de cluster único da sua aplicação para cluster-a
    • live-traffic-app-b: Encaminhamento de cluster único da sua aplicação para cluster-b
    • batch-analytics: encaminhamento de cluster único do trabalho de estatísticas em lote para cluster-c

  3. Use os perfis de apps de trânsito em tempo real para executar cargas de trabalho de trânsito em tempo real.

  4. Enquanto as cargas de trabalho de tráfego em direto estão em execução, use o perfil da app batch-analytics para executar uma carga de trabalho em lote só de leitura.

Crie alta disponibilidade (HA)

Se uma instância tiver apenas um cluster, a durabilidade e a disponibilidade dos seus dados estão limitadas à zona onde esse cluster está localizado. A replicação pode melhorar a durabilidade e a disponibilidade armazenando cópias separadas dos seus dados em várias zonas ou regiões e fazendo automaticamente a comutação por falha entre clusters, se necessário.

Para configurar a sua instância para um exemplo de utilização de alta disponibilidade (HA), crie um novo perfil da app que use o encaminhamento multicluster ou atualize o perfil da app predefinido para usar o encaminhamento multicluster. Esta configuração oferece consistência eventual. Não vai poder ativar as transações de linha única porque podem causar conflitos de dados quando usa o encaminhamento de vários clusters.

As configurações para melhorar a disponibilidade incluem o seguinte.

  • Clusters em três ou mais regiões diferentes (configuração recomendada). A configuração recomendada para a HA é uma instância que tem N+2 clusters, cada um numa região diferente. Por exemplo, se o número mínimo de clusters de que precisa para publicar os seus dados for 2, precisa de uma instância com quatro clusters para manter a HA. Esta configuração oferece tempo de atividade mesmo no caso raro de duas regiões ficarem indisponíveis. Recomendamos que distribua os clusters por vários continentes.

    Exemplo de configuração:

    • cluster-a na zona us-central1-a no 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. Esta opção oferece elevada disponibilidade dentro da disponibilidade da região, a capacidade de realizar uma comutação por falha sem gerar custos de replicação entre regiões e sem aumento da latência na comutação por falha. Os seus dados numa instância do Bigtable replicada estão disponíveis desde que qualquer uma das zonas para as quais são replicados esteja disponível.

    Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões.

    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. Esta configuração de várias regiões oferece elevada disponibilidade, como a configuração de várias zonas anterior, mas os seus dados estão disponíveis mesmo que não consiga estabelecer ligação a uma das regiões.

    A replicação de escritas entre regiões é cobrada.

    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. Esta opção disponibiliza os seus dados, mesmo que não consiga estabelecer ligação a uma das regiões, e oferece capacidade adicional na região A.

    A replicação de escritas entre regiões é cobrada. Se escrever na região A, é-lhe cobrado um valor porque só tem um cluster na região B. Se escrever na região B, são-lhe cobradas duas vezes as taxas porque tem 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

Ofereça uma cópia de segurança quase em tempo real

Em alguns casos, por exemplo, se não puder dar-se ao luxo de ler dados desatualizados, tem sempre de encaminhar pedidos para um único cluster. No entanto, pode continuar a usar a replicação processando pedidos com um cluster e mantendo outro cluster como uma cópia de segurança quase em tempo real. Se o cluster de publicação ficar indisponível, pode minimizar o tempo de inatividade fazendo manualmente a comutação por falha para o cluster de cópia de segurança.

Para configurar a sua instância para este exemplo de utilização, crie um perfil da app que use o encaminhamento de cluster único ou atualize o perfil da app predefinido para usar o encaminhamento de cluster único. O cluster que especificou no perfil da sua app processa os pedidos recebidos. O outro cluster funciona como uma cópia de segurança caso precise de fazer failover. Esta disposição é, por vezes, conhecida como configuração ativa-passiva e oferece consistência forte e consistência de leitura das suas escritas. Se necessário, pode ativar as transações de linha única no perfil da app.

Para implementar esta configuração:

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

  2. Use a Google Cloud consola para monitorizar os clusters da instância e confirmar que apenas um cluster está a processar pedidos recebidos.

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

  3. Atualize o perfil da app para que aponte para o segundo cluster na sua instância.

    Recebe um aviso sobre a perda da consistência de leitura/escrita, o que também significa que perde a consistência forte.

    Se ativou as transações de linha única, também recebe um aviso sobre o potencial de perda de dados. Perde dados se enviar gravações em conflito enquanto a comutação por falha está a ocorrer.

  4. Continue a monitorizar a sua instância. Deve ver que o segundo cluster está a processar pedidos recebidos.

Mantenha a alta disponibilidade e a resiliência regional

Suponhamos que tem concentrações de clientes em duas regiões distintas num continente. Quer publicar cada concentração de clientes com clusters do Bigtable o mais próximo possível dos clientes. Quer que os seus dados estejam altamente disponíveis em cada região e pode querer uma opção de failover se um ou mais dos seus clusters não estiverem disponíveis.

Para este exemplo de utilização, pode criar uma instância com dois clusters na região A e dois clusters na região B. Esta configuração oferece alta disponibilidade, mesmo que não consiga estabelecer ligação a uma Google Cloud região. Também oferece resiliência regional, porque, mesmo que uma zona fique indisponível, o outro cluster na região dessa zona continua disponível.

Pode optar por usar o encaminhamento de vários clusters ou o encaminhamento de cluster único para este exemplo de utilização, consoante as necessidades da sua empresa.

Para configurar a sua instância para este caso de utilização:

  1. 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 têm de 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 aplicações perto de cada região.

Pode optar por usar o encaminhamento de vários clusters ou o encaminhamento de cluster único para este exemplo de utilização, consoante as necessidades da sua empresa. Se usar o encaminhamento de vários clusters, o Bigtable processa as comutações por falha automaticamente. Se usar o encaminhamento de cluster único, usa o seu próprio julgamento para decidir quando fazer failover para um cluster diferente.

Opção de encaminhamento de cluster único

Pode usar o encaminhamento de cluster único para este exemplo de utilização se não quiser que o cluster do Bigtable faça automaticamente a comutação por falha se uma zona ou uma região ficar indisponível. Esta opção é uma boa escolha se quiser gerir os custos e a latência que podem ocorrer se o Bigtable começar a encaminhar tráfego de e para uma região distante, ou se preferir tomar decisões de comutação por falha com base no seu próprio julgamento ou regras empresariais.

Para implementar esta configuração, crie, pelo menos, um perfil de app que use o encaminhamento de cluster único para cada aplicação que envia pedidos para a instância. Pode encaminhar os perfis de apps para qualquer cluster na instância do Bigtable. Por exemplo, se tiver três aplicações em execução em Lisboa e seis em Tóquio, pode configurar um perfil de app para a aplicação de Lisboa para encaminhar para asia-south1-a e dois que encaminham para asia-south1-c. Para a aplicação Tóquio, configure três perfis de apps que encaminham para asia-northeast1-a e três que encaminham para asia-northeast1-b.

Com esta configuração, se um ou mais clusters ficarem indisponíveis, pode fazer uma comutação por falha manual ou optar por deixar os seus dados temporariamente indisponíveis nessa zona até que a zona esteja novamente disponível.

Opção de encaminhamento em vários clusters

Se estiver a implementar este exemplo de utilização e quiser que o Bigtable faça automaticamente a comutação por falha para uma região se a sua aplicação não conseguir alcançar a outra região, use o encaminhamento de vários clusters.

Para implementar esta configuração, crie um novo perfil de app que use o encaminhamento de vários clusters para cada aplicação ou atualize o perfil de app predefinido para usar o encaminhamento de vários clusters.

Esta configuração oferece consistência eventual. Se uma região ficar indisponível, os pedidos do Bigtable são enviados automaticamente para a outra região. Quando isto acontece, é cobrado pelo tráfego de rede para a outra região e a sua aplicação pode ter uma latência mais elevada devido à maior distância.

Armazene dados perto dos seus utilizadores

Se tiver utilizadores em todo o mundo, pode reduzir a latência executando a sua aplicação perto dos utilizadores e colocando os dados o mais perto possível da aplicação. Com o Bigtable, pode criar uma instância com clusters em várias Google Cloud regiões, e os seus dados são automaticamente replicados em cada região.

Para este exemplo de utilização, use perfis de apps com o encaminhamento de cluster único. O encaminhamento multicluster não é desejável para este exemplo de utilização devido à distância entre os clusters. Se um cluster ficar indisponível e o respetivo perfil da app de vários clusters encaminhar automaticamente o tráfego a uma grande distância, a sua aplicação pode sofrer uma latência inaceitável e incorrer em custos de rede adicionais inesperados.

Para configurar a sua instância para este caso de utilização:

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

  2. Coloque um servidor de aplicações perto de cada região.

  3. Crie perfis de apps 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, a sua aplicação usa o perfil da app para o cluster mais próximo. As escritas em qualquer cluster são replicadas automaticamente nos outros dois clusters.

Outros exemplos de utilização

Se tiver um exemplo de utilização que não esteja descrito nesta página, use as seguintes perguntas para ajudar a decidir como configurar os perfis de apps:

O que se segue?