Compartilhar via

Operações de gerenciamento na Instância Gerenciada do Azure para Apache Cassandra

  • Artigo

A Instância Gerenciada do Azure para Apache Cassandra é um serviço totalmente gerenciado para clusters do Apache Cassandra apenas de código aberto. O serviço também permite que as configurações sejam substituídas, dependendo das necessidades específicas de cada carga de trabalho, permitindo a máxima flexibilidade e controle quando necessário. Este artigo define as operações de gerenciamento e os recursos fornecidos pelo serviço. Este artigo também explica a divisão de responsabilidades entre a equipe de suporte do Azure e os clientes ao manter clusters híbridos.

Compactação

  • Há diferentes tipos de compactação. Atualmente, executamos uma compactação secundária por meio de reparo (consulte Manutenção). Isso executa uma compactação de árvore Merkle, que é um tipo especial de compactação.
  • Dependendo da estratégia de compactação que foi definida na tabela usando CQL (por exemplo WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), o Cassandra compacta automaticamente quando a tabela atinge um tamanho específico. Recomendamos selecionar cuidadosamente uma estratégia de compactação para sua carga de trabalho e não fazer nenhuma compactação manual fora dela.

Aplicação de patch

  • Os patches no nível do sistema operacional são feitos automaticamente em uma cadência de aproximadamente duas semanas.

  • Os patches no nível de software do Apache Cassandra são feitos quando são identificadas vulnerabilidades de segurança. A cadência da aplicação de patch pode variar.

  • Durante a aplicação de patch, as máquinas são reinicializadas em um rack por vez. Você não deve ter nenhuma degradação no lado do aplicativo, desde que a configuração quorum ALL não esteja sendo usada e o fator de replicação seja 3 ou superior.

  • A versão no Apache Cassandra está no formato X.Y.Z. Você pode controlar a implantação de versões principais (X) e secundárias (Y) manualmente por meio de ferramentas de serviço. Já os patches do Cassandra (Z) que podem ser necessários para essa combinação de versão principal/secundária são feitos automaticamente.

Observação

Atualmente, o serviço dá suporte às versões 3.11 e 4.0 do Cassandra. Ambas as versões têm GA. Confira nosso Início Rápido da CLI do Azure (etapa 5) para especificar a versão do Cassandra durante a implantação do cluster.

Manutenção

  • O Reparo nodetool é executado automaticamente pelo serviço usando o reaper. Essa ferramenta é executada uma vez por semana. Você pode querer desabilitá-la se estiver usando o seu próprio serviço em uma implantação híbrida.

  • O monitoramento de integridade do nó consiste em:

    • Monitorar ativamente a associação de cada nó no anel do Cassandra.
    • Problemas de detecção automática e mitigação automática de infraestrutura, como máquina virtual, rede, armazenamento, Linux e falhas de software de suporte.
    • Monitoramento ativo da CPU, disco, perda de quorum e outros problemas de recursos.
    • A criação automática de nós com falha sempre que possível e criação manual de nós em resposta a avisos gerados automaticamente.

Suporte

A Instância Gerenciada do Azure para Apache Cassandra fornece um SLA para a disponibilidade de data centers em um cluster gerenciado. Se encontrar problemas com o uso do serviço, faça uma solicitação de suporte no portal do Azure.

Nossos benefícios de suporte incluem:

  • Ponto único de contato para problemas de infraestrutura do Cassandra – não é necessário gerar casos de suporte com equipes de IaaS (disco, computação, rede) separadamente.
  • A consultoria pró-ativa por email sobre gargalos de desempenho, dimensionamento e outros problemas de restrição de recursos.
  • Cobertura de suporte 24x7, incluindo incidentes gerados automaticamente para quaisquer problemas graves de interrupção.
  • Suporte a patch aprovado pela comunidade (consulte Aplicação de patch).
  • Suporte interno da equipe de engenharia JDK/JVM Java.
  • Suporte ao sistema operacional Linux com segurança da cadeia de suprimentos de software.

Importante

Tentaremos investigar e diagnosticar os problemas relatados por meio do caso de suporte e resolver ou mitigar sempre que possível. No entanto, você é responsável pelo uso de qualquer nível de configuração do Apache Cassandra que cause problemas de CPU, disco ou rede.

Exemplos desses problemas incluem:

  • Operações de consulta ineficientes.
  • Taxa de transferência acima da capacidade.
  • Ingestão de dados que excedem a capacidade de armazenamento.
  • Definições de configuração de keyspace incorretas.
  • Modelo de dados ou estratégia de chave de partição ruins.

Se investigarmos um caso de suporte e descobrirmos que a causa raiz do problema está no nível de configuração do Apache Cassandra (e não em nenhum aspecto de nível de plataforma subjacente que mantemos), ainda forneceremos recomendações e diretrizes sobre correção ou mitigação (quando possível), antes de encerrar o caso.

Recomendamos habilitar as métricas e/ou familiarizar-se com nossa integração do Azure Monitor para evitar problemas comuns no nível da configuração/aplicativo no Apache Cassandra, como mostrado acima.

Aviso

A Instância Gerenciada do Azure para Apache Cassandra também permite executar nodetool e sstable comandos para administração de DBA de rotina – consulte o artigo aqui. Alguns desses comandos podem desestabilizar o cluster Cassandra e só devem ser executados com cuidado e depois de serem testados em ambientes de não produção. Sempre que possível, uma opção --dry-run deve ser implantada primeiro. A Microsoft não pode oferecer nenhum SLA ou suporte para problemas com a execução de comandos que alteram a configuração padrão de banco de dados e/ou tabelas.

Backup e restauração

Os backups de instantâneo são habilitados por padrão e feitos a cada 24 horas. Eles são armazenados em uma conta interna do Armazenamento de Blobs do Azure e são mantidos por até dois dias (48 horas). Não há custo para os dois backups iniciais. Backups extras são cobrados, confira os preços. Para alterar o intervalo de backup ou o período de retenção, edite a política no portal:

Captura de tela da página de configuração de agendamento de backup.

Para restaurar a partir de um backup existente, faça uma solicitação de suporte no portal do Azure. Ao arquivar o caso de suporte, você precisará:

  1. Fornecer a ID de backup do portal para o backup a ser restaurado. Isso pode ser encontrado no portal:

    Captura de tela da página de configuração de agendamento de backup realçando a ID do backup.

  2. Informe-nos se o datacenter de origem foi excluído. Isso será importante para identificar a conta de backup correta da qual restaurar.

  3. Se a restauração de todo o cluster não for necessária, forneça o keyspace e a tabela (se aplicável) que precisam ser restaurados.

  4. Informe se deseja que o backup seja restaurado no cluster existente ou em um novo cluster.

  5. Caso queira restaurar para um novo cluster, precisará criar o novo cluster primeiro. Verifique se o cluster de destino corresponde ao cluster de origem em termos do número de data centers e se o data center correspondente tem o mesmo número de nós. Também poderá decidir se deseja manter as credenciais (nome de usuário/senha) no novo cluster de destino ou permitir que a restauração substitua o nome de usuário/senha pelo que foi criado originalmente.

  6. Também poderá decidir se deseja manter o keyspace system_auth no novo cluster de destino ou permitir que a restauração o substitua com dados do backup. O keyspace system_auth no Cassandra contém dados de autorização e autenticação interna, incluindo funções, permissões de função e senhas. Observe que nosso processo de restauração padrão substitui o keyspace system_auth.

Observação

O tempo necessário para responder a uma solicitação de restauração do backup dependerá da gravidade do caso de suporte gerado (e do SLA correspondente para o tempo de resposta) e da quantidade de dados a serem restaurados. No entanto, não fornecemos um SLA por tempo para concluir a restauração, pois isso depende muito do volume de dados que está sendo restaurado.

Aviso

Os backups são destinados a cenários de exclusão acidental e não têm redundância geográfica. Portanto, eles não são recomendados para uso como uma estratégia de DR (recuperação de desastre) no caso de uma interrupção regional total. Para proteger contra interrupções regionais, recomendamos uma implantação em várias regiões. Confira o guia de início rápido para implantações em várias regiões.

Segurança

A Instância Gerenciada do Azure para Apache Cassandra fornece muitos recursos e controles de segurança explícitos internos:

  • Imagens de Máquina Virtual do Linux protegidas por uma cadeia de fornecimento controlada.
  • Monitoramento de exposição e de vulnerabilidades comuns (CVE) no nível do sistema operacional.
  • Rotação de certificado para os softwares Apache Cassandra e Prometheus hospedados nas Máquinas Virtuais gerenciadas.
  • Verificação ativa de vulnerabilidades.
  • Verificação ativa de vírus.
  • Práticas de codificação seguras.

Para obter mais informações sobre recursos de segurança, confira o artigo aqui.

Suporte híbrido

Quando um cluster híbrido é configurado, as operações automatizadas de reaper em execução no serviço beneficiam todo o cluster. Isso inclui datacenters que não são provisionados pelo serviço. Fora isso, é sua responsabilidade manter seu data center local ou hospedado externamente.

Próximas etapas

Introdução com um dos nossos guias de início rápido: