Instâncias, clusters e nós

Para usar o Cloud Bigtable, crie instâncias com até quatro clusters aos quais seus aplicativos podem se conectar. Cada cluster contém nós, as unidades de computação que gerenciam os dados e realizam as tarefas de manutenção.

Esta página fornece mais informações sobre clusters, nós e instâncias do Cloud Bigtable.

Antes de ler esta página, conheça a visão geral do Cloud Bigtable.

Instâncias

Uma instância do Cloud Bigtable é um contêiner para seus dados. As instâncias têm um ou mais clusters, localizados em zonas diferentes. Cada cluster tem pelo menos um .

Uma tabela pertence a uma instância, não a um cluster ou nó. Se você tiver uma instância com mais de um cluster, está usando a replicação. Isso significa que não é possível atribuir uma tabela a um cluster individual ou criar políticas de coleta de lixo exclusivas para cada cluster em uma instância. Também não é possível fazer com que cada cluster armazene um conjunto diferente de dados na mesma tabela.

Uma instância tem algumas propriedades importantes que você precisa conhecer:

  • O tipo de armazenamento (SSD ou HDD)
  • Os perfis de aplicativo, que são principalmente para instâncias que usam replicação

As seções a seguir descrevem essas propriedades.

Tipos de armazenamento

Ao criar uma instância, você precisa escolher se os clusters da instância armazenarão dados em unidades de estado sólido (SSD) ou unidades de disco rígido (HDD). SSD costuma ser a opção mais eficiente e econômica.

A escolha entre SSD e HDD é permanente, e todo cluster na instância precisa usar o mesmo tipo de armazenamento. Dessa maneira, não se esqueça de escolher o tipo de armazenamento certo para o caso de uso. Consulte Como escolher entre armazenamento SSD e HDD antes de decidir.

Perfis de aplicativo

Depois de criar uma instância, o Cloud Bigtable usa a instância para armazenar perfis de aplicativo, ou perfis de app. Para instâncias que usam replicação, os perfis de aplicativo controlam como os aplicativos se conectam aos clusters da instância.

Se a instância não usar a replicação, ainda será possível usar perfis de app para fornecer identificadores separados a cada um dos aplicativos ou a cada função em um aplicativo. Em seguida, é possível ver gráficos separados para cada perfil de app no Console do Cloud.

Clique aqui para saber mais sobre perfis de aplicativos. Para saber como configurar os perfis de aplicativos da sua instância, acesse este artigo.

Clusters

Um cluster representa o serviço do Cloud Bigtable em um local específico. Cada cluster pertence a uma única instância do Cloud Bigtable, e uma instância pode ter até quatro clusters. Quando o aplicativo envia solicitações para uma instância do Cloud Bigtable, essas solicitações são processadas por um dos clusters na instância.

Cada cluster está localizado em uma única zona. Os clusters de uma instância precisam estar em zonas exclusivas. É possível criar outro cluster em qualquer zona em que o Cloud Bigtable esteja disponível. Por exemplo, se o primeiro disco estiver em us-east1-b, é possível escolher uma zona diferente na mesma região, como us-east1-c ou uma zona em uma região separada, como europe-west2-a. Para uma lista de zonas e regiões em que o Cloud Bigtable esteja disponível, consulte Locais do Cloud Bigtable.

As instâncias do Cloud Bigtable com apenas um cluster não usam replicação. Se você adicionar um segundo cluster a uma instância, o Cloud Bigtable começará a replicar automaticamente os dados mantendo cópias separadas dos dados em cada zona dos clusters e sincronizando as atualizações entre as cópias. É possível escolher a qual cluster seus aplicativos se conectam, o que permite isolar diferentes tipos de tráfego. Também é possível deixar o Cloud Bigtable balancear o tráfego entre clusters. Caso um cluster fique indisponível, será possível usar o failover de um cluster para outro. Para saber mais sobre como funciona a replicação, consulte Visão geral da replicação.

Nós

Cada cluster em uma instância tem um ou mais nós, que são recursos de computação que o Cloud Bigtable usa para gerenciar seus dados.

Nos bastidores, o Cloud Bigtable divide todos os dados em uma tabela em blocos separados. Os blocos são armazenados em disco, separados dos nós, mas na mesma zona que eles. Um bloco está associado a um único nó.

Cada nó é responsável por:

  • Acompanhar blocos específicos no disco.
  • Lidar com leituras e gravações recebidas para seus blocos.
  • Executar tarefas de manutenção nos blocos, como compactação periódica.

Um cluster precisa ter nós suficientes para aceitar a carga de trabalho atual e a quantidade de dados que armazena. Do contrário, o cluster talvez não consiga processar solicitações de entrada, e a latência poderá aumentar. Monitore o uso da CPU e do disco dos clusters e adicione nós a uma instância quando suas métricas excederem as recomendações e os limites listados abaixo.

Para mais detalhes sobre como o Cloud Bigtable armazena e gerencia dados, consulte Arquitetura do Cloud Bigtable.

Uso da CPU

O Cloud Bigtable informa as seguintes métricas de uso da CPU:

Métrica Descrição
Uso médio da CPU

O uso médio da CPU em todos os nós do cluster.

Os valores máximos recomendados oferecem espaço para breves picos de uso.

Se um cluster exceder o valor máximo recomendado para sua configuração por mais de alguns minutos, adicione nós ao cluster.

Uso do melhor nó pela CPU

Uso da CPU no nó mais ocupado do cluster.

Caso o melhor nó esteja frequentemente acima do valor recomendado, mesmo quando o uso médio da CPU é razoável, talvez você esteja acessando uma pequena parte dos dados com muito mais frequência do que o restante dos dados.

  • Use a ferramenta Key Visualizer para identificar pontos de acesso em sua tabela que podem estar causando picos no uso da CPU.
  • Verifique o design do esquema para se certificar de que ele aceita uma distribuição equilibrada de leituras e gravações em cada tabela.

Os valores dessas métricas não podem exceder o seguinte:

Configuração Valores máximos recomendados
Cluster único

70% de uso médio da CPU
90% de uso do melhor nó pela CPU

Qualquer número de clusters com roteamento de cluster único

70% de uso médio da CPU
90% de uso do melhor nó pela CPU

Dois clusters com roteamento de vários clusters

35% de uso médio da CPU
45% de uso do melhor nó pela CPU

Três ou mais clusters com roteamento de vários clusters

Depende da sua configuração. Veja os exemplos de configurações de replicação para casos de uso comuns.

Uso do disco

O Cloud Bigtable informa as seguintes métricas de uso do disco:

Métrica Descrição
Uso do armazenamento (bytes)

A quantidade de dados armazenados no cluster.

Ele afeta os custos. Além disso, conforme descrito abaixo, convém adicionar nós a cada cluster à medida que a quantidade de dados aumenta.

Uso do armazenamento (% máx.)

A porcentagem da capacidade de armazenamento do cluster usado. A capacidade se baseia no número de nós no cluster.

Em geral, não use mais de 70% do limite máximo de armazenamento total, para que você tenha espaço para adicionar mais dados. Se você não planeja adicionar quantidades significativas de dados à sua instância, use até 100% do limite absoluto.

Se você estiver usando mais do que a porcentagem recomendada do limite de armazenamento, adicione nós ao cluster. Também é possível excluir dados atuais, mas dados excluídos ocupam mais espaço, e não menos, até que ocorra uma compactação.

Para detalhes sobre como esse valor é calculado, consulte Uso do armazenamento por nó.

Carga do disco

A porcentagem que o cluster está usando da largura de banda máxima possível em leituras e gravações HDD. Disponível apenas para clusters de HDD.

Caso esse valor esteja sempre em 100%, talvez haja mais latência. Adicione nós ao cluster para reduzir a porcentagem da carga de disco.

Nós para clusters replicados

Em uma instância que use replicação, verifique se cada cluster tem nós suficientes para aceitar o caso de uso:

  • Caso você use a replicação para fornecer alta disponibilidade ou use o roteamento de vários clusters em alguns perfis de aplicativos, cada cluster precisará ter o mesmo número de nós. Além disso, conforme mostrado acima, em Uso da CPU, a utilização recomendada da CPU é reduzida pela metade.

    Essa configuração ajuda a garantir que, se um failover automático for necessário, o cluster responsivo terá capacidade suficiente para processar todo o tráfego.

  • Caso todos os perfis de app usem roteamento de cluster único, cada cluster poderá ter um número de nós diferente. Redimensione cada cluster conforme necessário com base na carga de trabalho do cluster.

    Como o Cloud Bigtable armazena uma cópia separada dos dados com cada cluster, cada um precisa ter sempre nós suficientes para aceitar o uso do disco e replicar gravações entre clusters.

    Ainda não é possível fazer failover manualmente de um cluster para outro, se necessário. Porém, caso um cluster tenha muito mais nós do que outro e você precise fazer failover para o cluster com menos nós, talvez seja necessário adicionar nós primeiro. Não há garantia de que nós adicionais estarão disponíveis quando você precisar fazer failover. A única maneira de reservar nós com antecedência é os adicionando ao cluster.

A seguir