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

Artigo
08/15/2024

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, permitindo 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. Atualmente realizamos uma pequena compactação através da reparação (ver Manutenção). Isso executa uma compactação da árvore Merkle, que é um tipo especial de compactação.
Dependendo da estratégia de compactação que foi definida na mesa usando CQL (por exemploWITH compaction = { 'class' : 'LeveledCompactionStrategy' }), Cassandra compacta automaticamente quando a mesa atinge um tamanho específico. Recomendamos que você selecione cuidadosamente uma estratégia de compactação para sua carga de trabalho e 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 aproximadamente 2 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 sofrer 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 por meio de ferramentas de serviço. Já os patches Cassandra (Z) que podem ser necessários para essa combinação de versão maior/secundária são feitos automaticamente.

Nota

O serviço atualmente suporta Cassandra versões 3.11 e 4.0. Ambas as versões são GA. Consulte nosso Guia de início rápido da CLI do Azure (etapa 5) para especificar a versão Cassandra durante a implantação do cluster.

Manutenção

O reparo do Nodetool é executado automaticamente pelo serviço usando o reaper. Esta ferramenta é executada uma vez por semana. Você pode desativá-lo se estiver usando seu próprio serviço para uma implantação híbrida.
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.
- Automaticamente trazendo nós com falha sempre que possível e manualmente trazendo 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 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 contato único para problemas de infraestrutura Cassandra - não há necessidade de levantar casos de suporte com equipes de IaaS (disco, computação, rede) separadamente.
Aconselhamento proativo via 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 aprovado 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

Investigaremos e diagnosticaremos quaisquer problemas relatados por meio do caso de suporte e resolveremos ou mitigaremos sempre que possível. No entanto, 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.

Caso investiguemos um caso de suporte e descubramos que a causa raiz do problema está no nível de configuração do Apache Cassandra (e não em quaisquer aspetos subjacentes do nível da plataforma que mantemos), ainda forneceremos recomendações e orientações sobre remediação ou mitigação (quando possível), antes de fechar o caso.

Recomendamos que você habilite as métricas e/ou 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 os acima.

Aviso

A Instância Gerenciada do Azure para Apache Cassandra também permite executar nodetool comandos para sstable 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 testados em ambientes que não sejam de produção. Sempre que possível, uma --dry-run opção deve ser implantada primeiro. A Microsoft não pode oferecer qualquer SLA ou suporte em problemas com a execução de comandos que alteram a configuração padrão do banco de dados e/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é 2 dias (48 horas). Não há custo para os 2 backups iniciais. Backups extras são cobrados, consulte os preços. Para alterar o intervalo de backup ou o período de retenção, você pode editar a política no portal:

Para restaurar a partir de um backup existente, registre uma solicitação de suporte no portal do Azure. Ao apresentar o caso de suporte, você precisa:

Forneça o ID de backup do portal para o backup que você deseja restaurar. Pode encontrar informações no portal:
Informe-nos se o datacenter de origem foi excluído. Isso será importante para identificar a conta de backup correta a ser restaurada.
Se a restauração de todo o cluster não for necessária, forneça o espaço de chave e a tabela (se aplicável) que precisam ser restaurados.
Informe se deseja que o backup seja restaurado no cluster existente ou em um novo cluster.
Se você quiser restaurar para um novo cluster, você precisa 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. Você também pode 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 originalmente criado.
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. Observe que nosso processo de restauração padrão substitui o espaço de system_auth chave.

Nota

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

Aviso

Os backups destinam-se a cenários de exclusão acidental e não são redundantes geograficamente. Portanto, eles não são recomendados para uso como uma estratégia de recuperação de desastres (DR) em caso de uma interrupção regional total. Para se proteger contra interrupções em toda a região, recomendamos uma implantação em várias regiões. Dê uma olhada em nosso 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 suprimentos controlada.
Monitoramento de vulnerabilidade comum e exposição (CVE) no nível do sistema operacional.
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 mais informações sobre os elementos de segurança, consulte o nosso artigo aqui.

Suporte híbrido

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

Próximos passos

Comece com um dos nossos guias de início rápido:

Partilhar via