Início rápido: Cria um Azure Managed Instance para o cluster Apache Cassandra a partir do portal Azure

Azure Managed Instance for Apache Cassandra é um serviço totalmente gerido para clusters Apache Cassandra puramente open-source. O serviço também permite que as configurações sejam substituídas, dependendo das necessidades específicas de cada carga de trabalho, para máxima flexibilidade e controle.

Este quickstart demonstra como usar o portal Azure para criar um Azure Managed Instance para o cluster Apache Cassandra.

Pré-requisito

Se não tiver uma subscrição Azure, crie uma conta gratuita antes de começar.

Criar um cluster de instância gerenciado

Inicie sessão no portal Azure.
Na barra de pesquisa, procure por Managed Instance para Apache Cassandra e selecione o resultado.
Selecione Create Managed Instance para o cluster Apache Cassandra.
No painel Create Managed Instance para Apache Cassandra, introduza a seguinte informação:
- Subscrição: Na lista suspensa, selecione a sua subscrição Azure.
- Grupo de recursos: especifique se deseja criar um novo grupo de recursos ou usar um existente. Um grupo de recursos é um contentor que contém recursos relacionados para uma solução Azure.
- Nome do cluster: insira um nome para o cluster.
- Local: Selecione o local para implantar o cluster.
- Versão Cassandra: Selecione a versão do Apache Cassandra a ser implantada.
- Extensão: Selecione extensões para adicionar, incluindo Cassandra Lucene Index. Isto só é relevante para Cassandra v3.11.
- Senha inicial de administrador Cassandra: Digite a senha usada para criar o cluster.
- Confirme a palavra-passe de administrador Cassandra: Reintroduza a sua palavra-passe.
- Rede virtual: selecione uma rede virtual e uma sub-rede existentes ou crie uma nova. Por favor, tome nota das regras de rede ou você pode usar a configuração baseada em VPN.
- Atribuir funções: as redes virtuais exigem permissões especiais para permitir que clusters Cassandra gerenciados sejam implantados. Mantenha esta caixa selecionada se você criar uma nova rede virtual ou usar uma rede virtual existente sem permissões aplicadas. Se usar uma rede virtual onde anteriormente implementou clusters Cassandra do Azure SQL Managed Instance, desative esta opção.
Se você usa uma rede privada virtual, não precisa abrir outra conexão.

A implementação de Azure Managed Instance para o Apache Cassandra requer acesso à internet. A implantação falha em ambientes onde o acesso à Internet é restrito. Certifique-se de que não está a bloquear o acesso na sua rede virtual aos seguintes serviços Azure vitais que são necessários para que o Managed Cassandra funcione corretamente. Para obter mais informações, consulte Regras de rede de saída necessárias.
- Armazenamento do Azure
- Azure Key Vault
- Conjuntos de Dimensionamento de Máquinas Virtuais do Azure (Dimensionamento de Conjuntos de Máquinas Virtuais do Azure)
- Azure Monitor
- Microsoft Entra ID
- Microsoft Defender para a Cloud
- Replicação automática: escolha a forma de replicação automática a ser usada. Para obter mais informações, consulte Replicação turnkey.
- Estratégia de agendamento de eventos: a estratégia que o cluster usa para eventos agendados.
Gorjeta
- StopANY significa interromper qualquer nó que tenha um evento agendado.
- StopByRack significa interromper nós somente numa estante específica para um evento especificamente agendado. Por exemplo, quando vários eventos são agendados ao mesmo tempo para nós em racks diferentes, apenas os nós num só rack desligam. Outros nós em outros racks encontram-se atrasados.
Selecione a guia Data center .
Insira as seguintes informações:
- Nome do data center: insira um nome de datacenter no campo de texto.
- Zona de disponibilidade: marque esta caixa de seleção se quiser habilitar as zonas de disponibilidade.
- Tamanho da SKU: escolha entre os tamanhos de camada de produto de máquina virtual (VM) disponíveis.
Introduzimos o cache de gravação (visualização pública) usando camadas de produto de VM da série L. Essa implementação visa minimizar as latências finais e melhorar o desempenho de leitura, particularmente para cargas de trabalho de leitura intensiva. Essas camadas de produto específicas são equipadas com discos conectados localmente, o que garante maior IOPS para operações de leitura e latência traseira reduzida.

O cache de gravação é fornecido sem um contrato de nível de serviço (SLA). Não recomendamos para cargas de trabalho de produção. Para mais informações, consulte Termos de Utilização Suplementares para Microsoft Azure Pré-visualizações.
- N.º de discosEscolha o número de discos p30 a serem ligados a cada nó do Cassandra. Ao calcular a capacidade de armazenamento, assuma uma utilização máxima sustentada de 50%. Este buffer tem em conta as lápides e o consumo de disco pelos serviços do sistema. Além disso, os backups consomem temporariamente espaço em disco antes de os dados serem mantidos para armazenamento Blob.
- N.º de nós: Escolha o número de nós Cassandra a serem implantados neste datacenter.
As zonas de disponibilidade não são suportadas em todas as regiões. As implantações falham se você selecionar uma região onde as zonas de disponibilidade não são suportadas. Para mais informações, consulte a lista de regiões Azure.

A implantação bem-sucedida de zonas de disponibilidade também está sujeita à disponibilidade de recursos de computação em todas as zonas na região específica. As implantações podem falhar se a camada de produto selecionada ou a capacidade não estiver disponível em todas as zonas.
Selecione Revisar e criar>Criar.

Pode levar até 15 minutos para criar um cluster.
Após a conclusão da implantação, verifique seu grupo de recursos para ver o cluster de instância gerenciada recém-criado.
Para navegar pelos nós do cluster, vá para o recurso de cluster e abra o painel Data Center .

Escalar um datacenter

Depois de implantar um cluster com um único datacenter, você pode dimensionar horizontal ou verticalmente. Realce o datacenter e selecione Dimensionar.

Escala horizontal

Para escalar para fora ou para dentro em nós, mova o controlo deslizante para o número desejado. Você também pode editar o valor. Quando terminar, selecione Escala.

Escala vertical

Para aumentar ou diminuir o tamanho do nível de produto para os nodos, selecione uma opção na lista suspensa Tamanho da SKU. Quando terminar, selecione Escala.

O tempo necessário para uma operação de dimensionamento depende de vários fatores. A operação pode levar vários minutos. Quando o Azure te notifica que a operação de escala terminou, isso não significa que todos os teus nós se juntaram ao anel de Cassandra. Os nós são totalmente comissionados quando todos mostram um status de Saudável e o status do datacenter é Concluído.

O dimensionamento é uma operação online e funciona da mesma maneira descrita para a aplicação de patches. Para obter mais informações, consulte Aplicação de patches.

Adicionar um datacenter

Para adicionar outro datacenter, no painel Data Center , selecione Adicionar.

Se você adicionar um datacenter em uma região diferente, precisará selecionar uma rede virtual diferente. Verifique se essa rede virtual tem conectividade com a rede virtual da região primária que foi criada anteriormente. Além disso, certifique-se de que todas as outras redes virtuais que hospedam datacenters estejam dentro do cluster de instâncias gerenciadas. Para obter mais informações, consulte Conectar redes virtuais com emparelhamento de rede virtual.

Certifique-se de que aplicou a função apropriada à sua rede virtual antes de tentar implantar um cluster de instância gerenciado. Use o seguinte comando do CLI do Azure:
```
   az role assignment create \
   --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
   --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
   --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>
```
Preencha os campos apropriados:
- nome do centro de dados: Na lista suspensa, selecione a sua subscrição Azure.
- Zona de disponibilidade: selecione se deseja habilitar as zonas de disponibilidade neste datacenter.
- Local: local onde o datacenter está implantado.
- Tamanho da SKU: escolha entre os tamanhos de camada de produto de VM disponíveis.
- N.º de discosEscolha o número de discos p30 a serem ligados a cada nó do Cassandra. Ao calcular a capacidade de armazenamento, assuma uma utilização máxima sustentada de 50%. Este buffer tem em conta as lápides e o consumo de disco pelos serviços do sistema. Além disso, os backups consomem temporariamente espaço em disco antes de os dados serem mantidos para armazenamento Blob.
- N.º de nós: Escolha o número de nós Cassandra a serem implantados neste datacenter.
- Rede virtual: selecione uma rede virtual e uma sub-rede existentes.
O portal do Azure não permite a criação de uma nova rede virtual quando se adiciona um datacenter. Você precisa escolher uma rede virtual existente e garantir que haja conectividade entre as sub-redes de destino onde os datacenters são implantados. Você também precisa aplicar a função apropriada à rede virtual para permitir a implantação, conforme descrito anteriormente.
Quando o datacenter é implantado, você deve ser capaz de exibir todas as informações do datacenter no painel Data Center .
Para garantir a replicação entre datacenters, conecte-se ao Cassandra Query Language Shell (CQLSH) e use a seguinte consulta CQL para atualizar a estratégia de replicação em cada espaço de chave para incluir todos os datacenters no cluster. As tabelas do sistema são atualizadas automaticamente.
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
Se você adicionar um datacenter a um cluster que já tenha dados, execute rebuild para replicar os dados históricos. No CLI do Azure, use o comando seguinte e execute nodetool rebuild em cada nó do novo centro de dados. Esta ação substitui <new dc ip address> pelo endereço IP do nó e substitui <olddc> pelo nome do seu datacenter existente:
```
 az managed-cassandra cluster invoke-command \
   --resource-group $resourceGroupName \
   --cluster-name $clusterName \
   --host <new dc ip address> \
   --command-name nodetool --arguments rebuild="" "<olddc>"=""
```

Não permita que os clientes de aplicações escrevam no novo datacenter até que aplique as alterações de replicação do keyspace. Caso contrário, a reconstrução não funciona e você precisa criar uma solicitação de suporte para que nossa equipe possa executar repair para você.

Atualizar configuração Cassandra

Pode usar o portal Azure ou os comandos CLI para atualizar a configuração do Cassandra YAML num datacenter. Para atualizar as configurações no portal:

Em Configurações, selecione Configuração de Cassandra. Realce o datacenter cuja configuração pretende alterar e, em seguida, selecione Atualizar.
Na janela que se abre, insira os nomes dos campos no formato YAML, conforme mostrado aqui. Em seguida, selecione Atualizar.
Quando a atualização estiver concluída, os valores substituídos aparecerão no painel Configuração do Cassandra .

Apenas os valores de configuração Cassandra sobrescritos são mostrados no portal Azure.

Verifique se as configurações do Cassandra YAML fornecidas são apropriadas para a versão do Cassandra que você implantou. Para mais informações, veja Cassandra v5.0, Cassandra v4.0 para v4.0 e Cassandra v3.11 para as definições de Cassandra v3.11. Não é possível atualizar as seguintes configurações de YAML:
- cluster_name
- seed_provider
- initial_token
- autobootstrap
- client_encryption_options
- server_encryption_options
- transparent_data_encryption_options
- audit_logging_options
- authenticator
- authorizer
- role_manager
- storage_port
- ssl_storage_port
- native_transport_port
- native_transport_port_ssl
- listen_address
- listen_interface
- broadcast_address
- hints_directory
- data_file_directories
- commitlog_directory
- cdc_raw_directory
- saved_caches_directory
- endpoint_snitch
- partitioner
- rpc_address
- rpc_interface

Atualizar a versão Cassandra

Pode realizar atualizações de versões maiores no local diretamente a partir do portal ou através dos modelos CLI do Azure, Terraform ou Azure Resource Manager.

Na guia Visão geral , selecione Atualizar.
Selecione a versão Cassandra na lista suspensa.

Não pule versões. Recomendamos que você atualize de apenas uma versão para outra. Por exemplo, atualize 3.11 para 4.0 ou 4.0 para 4.1 ou 4.1 para 5.0.
Selecione Atualizar para salvar.

Replicação chave na mão

Cassandra 5.0 introduz uma abordagem simplificada para implantar clusters de várias regiões, que oferecem maior conveniência e eficiência. Se você usar a funcionalidade de replicação turnkey, a configuração e o gerenciamento de clusters de várias regiões serão mais acessíveis. Você obtém integração e operação mais suaves em ambientes distribuídos.

Esta atualização reduz as complexidades associadas à implantação e manutenção de várias configurações de região. Os usuários podem usar os recursos da Cassandra com maior facilidade e eficácia.

Nenhum: A opção Replicação automática está definida como Nenhum.
Espaços de chaves do sistema: replique automaticamente todos os espaços de chaves do sistema (system_auth, system_tracese system_auth).
Todos os Keyspaces: replique automaticamente todos os keyspaces, monitore se novos keyspaces são criados e, em seguida, aplique as configurações de replicação automática automaticamente.

Cenários de replicação automática

Quando você adiciona um novo datacenter, o recurso de replicação automática no Cassandra é executado nodetool rebuild perfeitamente para garantir a replicação bem-sucedida de dados no datacenter adicionado. A remoção de um datacenter aciona uma remoção automática do datacenter específico dos espaços de chave.

Para datacenters externos, como aqueles hospedados localmente, use a propriedade de datacenter externo para incluí-los nos keyspaces. Essa abordagem permite que a Cassandra incorpore esses datacenters externos como fontes para o processo de reconstrução.

Se você definir a Replicação Automática como Todos os Keyspaces, a replicação de keyspaces será alterada para incluir:

WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }

Se esta topologia não for o que queres, usa SystemKeyspaces, ajusta-os tu mesmo e executa manualmente nodetool rebuild no Azure Managed Instance para o cluster Apache Cassandra.

Desalocar um cluster

Importante

Qualquer cluster desalocado por mais de sete dias deve ser recriado, pois pode não receber atualizações de segurança e pode representar um risco de segurança.

Para ambientes que não sejam de produção, você pode pausar ou desalocar recursos no cluster para evitar ser cobrado por eles. Continuará a ser cobrado pelo armazenamento. Primeiro, altere Tipo de cluster para Não produção e, em seguida, selecione Deslocalizar.

Use o tipo de cluster Não Produção apenas para economizar custos de desenvolvimento. Esse tipo de cluster pode vir com camadas de produto menores. Não o use para executar cargas de trabalho de produção.

Os tipos de cluster definidos como Não Produção não têm garantias de SLA aplicadas a eles.
Não execute nenhum esquema ou operações de gravação durante a deallocation. Esta ação pode levar à perda de dados. Em casos raros, poderá sofrer de corrupção de esquemas, o que requer intervenção manual da equipa de suporte.

Resolução de Problemas

Se encontrar um erro ao aplicar permissões à sua rede virtual ao usar a CLI do Azure, pode aplicar manualmente a mesma permissão a partir do portal Azure. Um exemplo deste tipo de erro é "Não é possível encontrar o principal de utilizador ou de serviço na base de dados de gráfico para e5007d2c-4b13-4a74-9b6a-605d99f03501." Para mais informações, veja Utilizar o portal do Azure para adicionar o principal de serviço do Azure Cosmos DB.

A atribuição de funções do Azure Cosmos DB é usada apenas para fins de implementação. Azure Managed Instance para Apache Cassandra não tem dependências de back-end no Azure Cosmos DB.

Conectar-se ao cluster

Azure Managed Instance para Apache Cassandra não cria nós com endereços IP públicos. Para se conectar ao cluster Cassandra recém-criado, crie outro recurso dentro da rede virtual. Este recurso pode ser um aplicativo ou uma VM com a ferramenta de consulta de código aberto CQLSH do Apache instalada. Você pode usar um modelo para implantar uma VM do Ubuntu.

Conecte-se a partir do CQLSH

Depois que a VM for implantada, use o Secure Shell para se conectar à máquina. Para instalar o CQLSH, use os seguintes comandos:

# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre

# Install the Cassandra libraries in order to get CQLSH:
echo "deb http://archive.apache.org/dist/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra

# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false

# Connect to CQLSH (replace <IP> with the private IP addresses of a node in your Datacenter):
host=("<IP>")
initial_admin_password="Password provided when creating the cluster"
cqlsh $host 9042 -u cassandra -p $initial_admin_password --ssl

Conectar a partir de uma aplicação

Assim como no CQLSH, quando você usa um dos drivers de cliente Apache Cassandra suportados para se conectar a partir de um aplicativo, a criptografia Transport Layer Security/Secure Sockets Layer (TLS/SSL) deve ser habilitada e a verificação de certificado deve ser desabilitada. Para amostras que são usadas para ligar a Azure Managed Instance para Apache Cassandra, veja Java, .NET, Node.js e Python.

Recomendamos que você desabilite a verificação de certificado porque ela não funciona, a menos que você mapeie os endereços IP dos nós do cluster para o domínio apropriado. Se uma política interna exigir que você execute a verificação do certificado TLS/SSL para qualquer aplicativo, adicione entradas como 10.0.1.5 host1.managedcassandra.cosmos.azure.com no arquivo hosts para cada nó para facilitar essa configuração. Se assumir esta abordagem, também precisará adicionar novas entradas sempre que expandir capacidade dos nós.

Para Java, recomendamos que ative a política de execução especulativa onde as aplicações são sensíveis à latência de cauda. Para uma demonstração que ilustre como esta abordagem funciona e para ver como ativar a política, veja Demo: Implementar execução especulativa.

Na maioria dos casos, não deveria ser necessário configurar ou instalar certificados (como rootCA, node, client ou truststore) para se ligar a Azure Managed Instance para o Apache Cassandra. Para habilitar a criptografia TLS/SSL, use o armazenamento confiável padrão e a senha do tempo de execução que o cliente está usando. Esse ambiente confia no Azure Managed Instance para certificados Apache Cassandra. Em casos raros, se o certificado não for confiável, talvez seja necessário adicioná-lo ao armazenamento confiável. Para código de exemplo, veja Java, .NET, Node.js e Python.

Configurar certificados de cliente (opcional)

A configuração de certificados de cliente é opcional. Uma aplicação cliente pode ligar-se a Azure Managed Instance para o Apache Cassandra se os passos anteriores estiverem concluídos. Se preferir, você também pode criar e configurar certificados de cliente para autenticação. Em geral, há duas maneiras de criar certificados:

Certificados autoassinados: Certificados privados e públicos sem Autoridade de Certificação (CA) em cada nó. Nesse caso, você precisa de todos os certificados públicos.
Certificados assinados por uma autoridade de certificação: Certificados emitidos por uma autoridade de certificação autoassinada ou pública. Nesse caso, você precisa do certificado de autoridade de certificação raiz e de todos os intermediários, se aplicável. Para obter mais informações, consulte Preparar certificados SSL para produção.

Se quiser implementar autenticação de certificado cliente-nó ou Segurança Mútua da Camada de Transporte (mTLS), use a CLI do Azure para fornecer os certificados. O comando a seguir faz o carregamento e aplica os seus certificados de cliente no repositório de confiança para o cluster de instância gerida. Não é necessário editar cassandra.yaml as configurações. Depois de aplicar o comando, o cluster requer que Cassandra verifique os certificados quando um cliente se conecta. Para obter mais informações, consulte require_client_auth: true em Cassandra client_encryption_options.

resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --client-certificates /usr/csuser/clouddrive/rootCert.pem /usr/csuser/clouddrive/intermediateCert.pem

Limpar recursos

Se você não quiser continuar a usar esse cluster de instância gerenciado, siga estas etapas para excluí-lo:

No menu esquerdo do portal de Azure, selecione Resource groups.
Na lista, selecione o grupo de recursos que você criou para este início rápido.
No painel Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
No painel seguinte, introduza o nome do grupo de recursos a eliminar e, em seguida, selecione Eliminar.

Próximo passo

Implementar um cluster Apache Spark gerido com Azure Databricks

Comentários

Esta página foi útil?

Last updated on 2026-04-08