Compartilhar via

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

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, o que permite 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. No momento, esse serviço executa uma compactação secundária usando o reparo. Para obter mais informações, consulte Manutenção. Esta operação 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 que você selecione cuidadosamente uma estratégia de compactação para sua carga de trabalho. Não faça compactações manuais fora da estratégia.

Aplicação de patch

  • Os patches no nível do sistema operacional são feitos automaticamente em cadência de 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 de 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 experimentar nenhuma degradação no lado do aplicativo, desde que a configuração ALL de quorum 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 usando ferramentas de serviço. 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 do Cassandra até a v5.0. Para especificar uma versão do Cassandra ao implantar um cluster, consulte o Início Rápido da CLI do Azure.

Manutenção

  • O serviço executa nodetool repair usando reaper. Essa ferramenta é executada uma vez por semana. Se você usar seu próprio serviço para uma implantação híbrida, convém desabilitar o reaper.

  • O monitoramento de integridade do nó consiste em:

    • Monitorar ativamente a associação de cada nó no anel do Cassandra.
    • A detecção e mitigação automáticas de problemas de infraestrutura, como falhas em máquinas virtuais, redes, armazenamento, Linux e falhas de software de suporte.
    • Monitoramento ativo da CPU, disco, perda de quorum e outros problemas de recursos.
    • Restabelecimento automático de nós com falha sempre que possível e restabelecimento manual de nós em resposta a alertas 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, como disco, computação e rede separadamente.
  • Recomendações proativas por email sobre gargalos de desempenho, dimensionamento e outras limitações de recursos.
  • Cobertura de suporte 24x7, incluindo incidentes gerados automaticamente para quaisquer problemas graves de interrupção.
  • Suporte de 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

A Microsoft investiga e diagnostica todos os problemas relatados usando o caso de suporte. O suporte resolve ou mitiga sempre que possível. Você é responsável por qualquer uso de 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.

A Microsoft pode investigar um caso de suporte e descobrir que a causa do problema está no nível de configuração do Apache Cassandra. Esse problema não vem de nenhum aspecto de nível de plataforma subjacente que o Azure mantém. O suporte ainda fornece recomendações e diretrizes sobre correção ou mitigação, quando possível, antes que eles fechem o caso.

Recomendamos que você habilite as métricas e se familiarize com a integração do Azure Monitor para evitar problemas comuns de nível de configuração/aplicativo no Apache Cassandra, como descrito anteriormente.

Aviso

A Instância Gerenciada do Azure para Apache Cassandra também permite que você execute nodetool e sstable comandos para administração de rotina do DBA. Para obter mais informações, confira o Comandos DBA para a Instância Gerenciada do Azure para Apache Cassandra.

Alguns desses comandos podem desestabilizar o cluster cassandra. Você deve executar esses comandos com cuidado e depois de ser testado em ambientes de não produção. Sempre que possível, use primeiro uma opção --dry-run. A Microsoft não oferece nenhum SLA ou suporte a problemas com a execução de comandos que alteram a configuração ou tabelas de banco de dados padrão.

Backup e restauração

Os backups de instantâneo são habilitados por padrão e feitos a cada 24 horas. Os backups 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 o preço. Para alterar o intervalo de backup ou o período de retenção, você pode editar a política no portal do Azure:

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 um caso de suporte, você precisa:

  1. Fornecer a ID de backup do portal para o backup a ser restaurado. Você pode encontrar essa ID no portal do Azure:

    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. Esse fato é importante para identificar a conta de backup correta da qual restaurar.

  3. Se você não precisar restaurar todo o cluster, 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. Verifique se o data center correspondente tem o mesmo número de nós. Você também pode decidir se deseja manter as credenciais no novo cluster de destino. Como alternativa, permita que a restauração substitua o nome de usuário e a 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. O 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 depende da gravidade do caso de suporte gerado, do SLA para o tempo de resposta e da quantidade de dados a serem restaurados. Não fornecemos um SLA para o tempo de conclusão da restauração. Esse valor é dependente do tempo com base no volume de dados que está sendo restaurado.

Aviso

Os backups são destinados a cenários de exclusão acidental e não possuem redundância geográfica. Não recomendamos backups para uso como uma estratégia de recuperação de desastre (DR) para interrupção regional. Para proteger contra interrupções em toda a região, recomendamos uma implantação de várias regiões. Para obter mais informações, consulte guia de início rápido para implantações de 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 CVE (Vulnerabilidade & Exposição Comum) 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, consulte Segurança na Instância Gerenciada do Azure para Apache Cassandra.

Suporte híbrido

Quando um cluster híbrido é configurado, as operações automatizadas do reaper que são executadas no serviço beneficiam todo o cluster. Esse aspecto inclui data centers que não são provisionados pelo serviço. É sua responsabilidade manter seu data center local ou hospedado externamente.

Conteúdo relacionado

  • Last updated on