Diretrizes operacionais do Spanner

Nesta página, descrevemos algumas das configurações controladas pelo usuário que podem causar a exclusão de uma interrupção de uma instância do Spanner do contrato de nível de serviço (SLA) do Spanner, que exclui interrupções "causadas por fatores fora do controle razoável do Google". Ele também oferece diretrizes sobre como evitar essas configurações.

O Spanner gerencia muitos aspectos das operações de banco de dados, como divisão e rebalanceamento de dados, replicação, failover e todas as atualizações de hardware e software. É possível configurar muitos desses comportamentos com configurações integradas e APIs administrativas. Suas cargas de trabalho também dependem de outros componentes além do Spanner, como aplicativos e rede. Essas configurações controladas pelo cliente podem aumentar o risco de inatividade da instância, dependendo da carga do banco de dados e de outros parâmetros de configuração.

Se a instância ficar inativa e o Google determinar que ela não está em conformidade com os limites operacionais descritos nesta página, qualquer período de inatividade resultante não será coberto (ou não será considerado) pelo SLA do Spanner.

Configurações excluídas do SLA do Spanner

As configurações a seguir são excluídas do SLA do Spanner:

  • Se a instância for configurada e usada de maneira que a carga de trabalho a sobrecarregue, ela não será coberta pelo SLA.
  • O tempo de inatividade das instâncias resultante de ações ou omissões voluntárias não é coberto pelo SLA.
  • Se você desativar a API Spanner ou outras APIs Google Cloud necessárias para criar e se conectar ao Spanner, ela não será coberta pelo SLA.
  • A indisponibilidade da API Spanner resultante da configuração de rede, como regras de proxy e firewall, não é coberta pelo SLA.
  • A indisponibilidade do aplicativo devido a clientes desatualizados ou mal configurados não é coberta pelo SLA. Em particular, verifique se você está usando versões recentes do cliente com dependências compatíveis. Por exemplo, os aplicativos Java precisam usar a BOM do Google (lista de materiais) com um gerenciador de pacotes, como Gradle ou Maven.

Recomendamos configurar alertas e monitoramento usando o Cloud Monitoring.

Configurações a evitar

Para manter a cobertura do SLA do Spanner, evite as seguintes configurações:

  • Sobrecarga da CPU: se a utilização da CPU estiver consistentemente alta, a instância não estará dimensionada corretamente para a carga de trabalho e poderá não ser coberta pelo SLA. As recomendações de uso da CPU do Spanner fornecem sobrecarga para um evento de failover, em que os recursos de computação restantes ajudam a acomodar o tráfego de partes indisponíveis da instância. É possível usar as métricas de utilização da CPU do Spanner para monitorar o uso da CPU.
  • Armazenamento completo: o Spanner cobra apenas pelo armazenamento que você usa. No entanto, cada nó, ou unidade de computação, tem um limite para a quantidade de armazenamento que pode gerenciar. Se a instância não estiver dimensionada corretamente para o armazenamento endereçável por nó, ela poderá não ser coberta pelo SLA. É possível usar as métricas de utilização do armazenamento do Spanner para monitorar a utilização do armazenamento.
  • Limite de cota:os recursos de nó são limitados por cotas por usuário. Não solicitar aumentos de cota com antecedência pode resultar em sobrecarga de recursos de computação, o que pode não ser coberto pelo SLA. As solicitações de aumento de cota que exigem aprovação do Google geralmente são atendidas em um dia.
  • Sessões com provisionamento insuficiente: os clientes do Spanner usam canais gRPC para se comunicar com endpoints Google Cloud para consultas e administração. Se os ambientes de cliente não fornecerem canais suficientes para atender ao volume de solicitações de uma carga de trabalho, os aplicativos poderão apresentar alta latência e baixa capacidade de processamento de solicitações, o que pode não ser coberto pelo SLA.
  • Sobrecarga de conexão:muitas APIs do Spanner podem ser retentadas com segurança em caso de falha temporária, como um deadlock de transação em uma consulta, um problema de rede ou limites de taxa para APIs administrativas. Novas tentativas muito agressivas podem sobrecarregar as conexões atuais, causando esgotamento de recursos ou limitação adicional. O aumento da latência ou a redução do throughput podem não ser cobertos pelo SLA. Para mais informações, consulte Como gerenciar tempos limite e novas tentativas do cliente.
  • Sobrecarga da unidade de disco rígido (HDD):o armazenamento em camadas permite armazenar dados do Spanner em uma combinação de unidades de estado sólido (SSD) e unidades de disco rígido (HDD). Se a carga de disco no armazenamento HDD atingir 100%, a latência da instância do Spanner vai aumentar significativamente e talvez não seja coberta pelo SLA. É possível usar as métricas de armazenamento em camadas do Spanner para monitorar a carga do disco.

A seguir