Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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:
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:
Forneça o ID de backup do portal para o backup que você deseja restaurar. Você pode encontrar essa ID no portal do Azure:
Informe-nos se o datacenter de origem foi excluído. Esse fato é importante para identificar a conta de backup correta a ser restaurada.
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.
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. 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.
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. Osystem_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 chavesystem_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.