Partilhar 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 Apache Cassandra de código aberto puro. 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 onde necessário.

Este artigo define as operações de gerenciamento e os recursos fornecidos pelo serviço. Ele também explica a separação de responsabilidades entre a equipe de suporte do Azure e os clientes ao manter clusters híbridos .

Compactação

  • Existem diferentes tipos de compactação. Este serviço atualmente executa uma pequena compactação através de reparação. Para obter mais informações, consulte Manutenção. Esta operação realiza uma compactação da árvore Merkle, que é um tipo especial de compactação.

  • Dependendo da estratégia de compactação definida na tabela usando CQL, por exemplo WITH compaction = { 'class' : 'LeveledCompactionStrategy' }, 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 nenhuma compactação manual fora da estratégia.

Aplicação de patches

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

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

  • Durante a aplicação de patches, as máquinas são reinicializadas um rack de cada vez. Você não deve experimentar nenhuma degradação no lado do aplicativo, desde que a configuração de 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 usando ferramentas de serviço. Os patches do Cassandra (Z) que podem ser necessários para a combinação de versão principal e secundária são aplicados automaticamente.

Nota

O serviço atualmente suporta Cassandra versões 3.11 e 4.0. Ambas as versões são GA. Para especificar uma versão Cassandra ao implantar um cluster, consulte Guia de início rápido da CLI do Azure.

Manutenção

  • O serviço executa nodetool repair usando reaper. Esta ferramenta é executada uma vez por semana. Se utilizar o seu próprio serviço para uma implantação híbrida, pode querer desativar o reaper.

  • O monitoramento da integridade do nó consiste em:

    • Monitorar ativamente a associação de cada nó no anel Cassandra.
    • Deteção automática e mitigação automática de problemas de infraestrutura, como máquina virtual, rede, armazenamento, Linux e falhas de software de suporte.
    • Monitoramento proativo de CPU, disco, perda de quorum e outros problemas de recursos.
    • Reestabelecendo automaticamente nós com falha sempre que possível e ativando manualmente nós em resposta a alertas automatizados.

Suporte

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

Nossos benefícios de suporte incluem:

  • Ponto de contacto único para as questões relacionadas com as infraestruturas de Cassandra. Não há necessidade de levantar casos de suporte com equipes de IaaS, como disco, computação e rede separadamente.
  • Aconselhamento proativo por e-mail sobre gargalos de desempenho, dimensionamento e outros problemas de restrição de recursos.
  • Cobertura de suporte 24 horas por dia, 7 dias por semana, incluindo incidentes gerados automaticamente para quaisquer problemas graves de interrupção.
  • Suporte a patches aprovados pela comunidade. Consulte Aplicação de patches.
  • Suporte interno à equipe de engenharia Java JDK/JVM.
  • Suporte ao Sistema Operacional Linux com segurança da cadeia de suprimentos de software.

Importante

A Microsoft investiga e diagnostica quaisquer problemas relatados usando o caso de suporte. O suporte resolve ou atenua sempre que possível. Em última análise, você é responsável por qualquer uso do nível de configuração do Apache Cassandra que cause problemas de CPU, disco ou rede.

Exemplos de tais questões incluem:

  • Operações de consulta ineficientes.
  • Taxa de transferência que excede a capacidade.
  • Ingerir dados que excedam a capacidade de armazenamento.
  • Definições incorretas de configuração do espaço de chave.
  • Modelo de dados ruim ou estratégia de chave de partição.

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 aspeto subjacente de nível de plataforma que o Azure mantém. O suporte ainda fornece recomendações e orientações sobre a remediação ou mitigação, quando possível, antes de encerrar o caso.

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

Aviso

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

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

Cópia de segurança e restauro

Os backups de snapshot 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 retidos por até dois dias (48 horas). Não há custo para os dois backups iniciais. Backups extras são cobrados. Veja os preços. 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, registre uma solicitação de suporte no portal do Azure. Quando você registra um caso de suporte, você precisa:

  1. Forneça o ID de backup do portal para o backup que você deseja restaurar. Você pode encontrar essa ID no portal do Azure:

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

  2. Informe-nos se o datacenter de origem foi excluído. Esse fato é importante para identificar a conta de backup correta a ser restaurada.

  3. Se você não precisar restaurar todo o cluster, forneça o espaço de chave 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. Se você quiser restaurar para um novo cluster, você precisa criar o novo cluster primeiro. Certifique-se de que o cluster de destino corresponda 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 originalmente criado.

  6. Você também pode decidir se deseja manter system_auth o espaço de chave no novo cluster de destino ou permitir que a restauração o substitua por dados do backup. O system_auth keyspace em 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 espaço de chave system_auth.

Nota

O tempo necessário para responder a uma solicitação de restauração a partir do backup depende da gravidade do caso de suporte levantado, 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 depende do tempo necessário para restaurar o volume de dados.

Aviso

Os backups destinam-se a cenários de exclusão acidental e não são redundantes geograficamente. Não recomendamos backups para uso como uma estratégia de recuperação de desastres (DR) para interrupções regionais. Para se proteger contra interrupções em toda a região, recomendamos uma implantação em várias regiões. Para obter mais informações, consulte 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 controles e recursos de segurança explícitos internos:

  • Imagens de máquinas virtuais Linux reforçadas com uma cadeia de abastecimento controlada.
  • Monitorização de Vulnerabilidades e Exposições Comuns (CVE) ao nível do sistema operativo.
  • Rotação de certificados para os softwares Apache Cassandra e Prometheus hospedados nas Máquinas Virtuais gerenciadas.
  • Análise 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 de ceifador automatizadas executadas no serviço beneficiam todo o cluster. Esse aspeto inclui data centers que não são provisionados pelo serviço. É da sua responsabilidade manter o seu centro de dados no local ou alojado externamente.