Guia de início rápido: criar uma instância gerenciada do Azure para cluster Apache Cassandra a partir do portal do Azure

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 quando necessário

Este guia de início rápido demonstra como usar o portal do Azure para criar uma Instância Gerenciada do Azure para o cluster Apache Cassandra.

Pré-requisitos

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

Criar um cluster de instância gerenciado

  1. Inicie sessão no portal do Azure.

  2. Na barra de pesquisa, procure por Instância Gerenciada para Apache Cassandra e selecione o resultado.

    Captura de ecrã da pesquisa de Instância Gerida SQL do Azure para Apache Cassandra.

  3. Selecione o botão Criar instância gerenciada para cluster Apache Cassandra.

    Criar o cluster.

  4. No painel Criar instância gerenciada para Apache Cassandra , insira os seguintes detalhes:

    • Assinatura - Na lista suspensa, selecione sua assinatura do Azure.
    • Grupo de Recursos- Especifique se deseja criar um novo grupo de recursos ou usar um existente. Um grupo de recursos é um contentor que mantém recursos relacionados para uma solução do Azure. Para obter mais informações, consulte o artigo de visão geral do Grupo de Recursos do Azure.
    • Nome do cluster - Insira um nome para o cluster.
    • Local - Local onde o cluster será implantado.
    • Versão Cassandra - Versão do Apache Cassandra que será implantada.
    • Extensão - Extensões que serão adicionadas, incluindo o Índice Cassandra Lucene.
    • Senha inicial de administrador Cassandra - 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 de Saída ou crie uma nova.
    • Atribuir funções - As Redes Virtuais requerem permissões especiais para permitir a implantação de clusters Cassandra gerenciados. Mantenha esta caixa marcada se estiver a criar uma nova Rede Virtual ou a utilizar uma Rede Virtual existente sem permissões aplicadas. Se estiver usando uma rede virtual onde você já implantou clusters Cassandra da Instância Gerenciada SQL do Azure, desmarque essa opção.

    Preencha o formulário de criação de cluster.

    Gorjeta

    Se você usa VPN , então você não precisa abrir nenhuma outra conexão.

    Nota

    A implantação de uma instância gerenciada do Azure para 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 vitais do Azure que são necessários para que a Cassandra Gerida funcione corretamente. Consulte Regras de rede de saída necessárias para obter informações mais detalhadas.

    • Storage do Azure
    • Azure KeyVault
    • Conjuntos de Dimensionamento de Máquinas Virtuais do Azure
    • Monitorização do Azure
    • Microsoft Entra ID
    • Azure Security
    • Auto Replicate - Escolha a forma de replicação automática a ser utilizada. Mais informações
    • Estratégia de Agendamento de Eventos - A estratégia a ser usada pelo cluster para eventos agendados.

    Gorjeta

    • StopANY significa parar qualquer nó quando há um agendado mesmo para o nó.
    • StopByRack significa apenas nó de parada em um determinado rack para um determinado Evento Agendado, por exemplo, se dois ou mais eventos forem agendados para nós em racks diferentes ao mesmo tempo, apenas nós em um rack serão interrompidos enquanto os outros nós em outros racks serão atrasados.
  5. Em seguida, selecione a guia Data center .

  6. Introduza os detalhes seguintes:

    • Nome do data center - Digite um nome de data center no campo de texto.
    • Zona de disponibilidade - Marque esta caixa se quiser que as zonas de disponibilidade sejam habilitadas.
    • Tamanho da SKU - Escolha entre os tamanhos de SKU da máquina virtual disponíveis.

    Captura de tela de selecionar um tamanho de SKU.

    Nota

    Introduzimos o cache write-through (Public Preview) através da utilização de SKUs 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. Esses SKUs específicos são equipados com discos conectados localmente, garantindo IOPS extremamente maiores para operações de leitura e latência de cauda reduzida.

    Importante

    O cache de gravação está em visualização pública. Esse recurso é fornecido sem um contrato de nível de serviço e não é recomendado para cargas de trabalho de produção. Para obter mais informações, veja Termos Suplementares de Utilização para Pré-visualizações do Microsoft Azure.

    • N.º de discos - Escolha o número de discos p30 a serem anexados a cada nó Cassandra.
    • N.º de nós - Escolha o número de nós Cassandra que serão implantados neste datacenter.

    Revise o resumo para criar o datacenter.

    Aviso

    As zonas de disponibilidade não são suportadas em todas as regiões. As implantações falharão se você selecionar uma região onde as zonas de disponibilidade não são suportadas. Consulte aqui as regiões suportadas. A implantação bem-sucedida de zonas de disponibilidade também está sujeita à disponibilidade de recursos de computação em todas as zonas em determinada região. As implantações podem falhar se a SKU selecionada ou a capacidade não estiver disponível em todas as zonas.

  7. Em seguida, selecione Rever + criar>Criar

    Nota

    Pode levar até 15 minutos para que o cluster seja criado.

    Revise o resumo para criar o cluster.

  8. Após a conclusão da implantação, verifique seu grupo de recursos para ver o cluster de instância gerenciada recém-criado:

    Página de visão geral após a criação do cluster.

  9. Para navegar pelos nós do cluster, navegue até o recurso de cluster e abra o painel Data Center para visualizá-los:

    Captura de tela dos nós do datacenter.

Dimensionar um datacenter

Agora que você implantou um cluster com um único data center, pode dimensionar horizontal ou verticalmente destacando o data center e selecionando o Scale botão:

Captura de tela do dimensionamento de nós do datacenter.

Dimensionamento horizontal

Para dimensionar em nós, mova o controle deslizante para o número desejado ou apenas edite o valor. Quando terminar, pressione Scale.

Captura de tela mostrando a seleção do número de nós do datacenter.

Escala vertical

Para escalar para um tamanho de SKU mais poderoso para seus nós, selecione na Sku Size lista suspensa. Quando terminar, pressione Scale.

Captura de tela mostrando a seleção do Tamanho da Sku.

Nota

O tempo que leva para uma operação de dimensionamento depende de vários fatores, pode levar vários minutos. Quando o Azure notifica que a operação de escala foi concluída, isso não significa que todos os seus nós se juntaram ao anel Cassandra. Os nós serão totalmente comissionados quando todos exibirem um status de "íntegro" e o status do datacenter for "bem-sucedido".

Adicionar um datacenter

  1. Para adicionar outro datacenter, clique no botão Adicionar no painel Data Center :

    Captura de ecrã a mostrar a adição de um centro de dados.

    Aviso

    Se você estiver adicionando um datacenter em uma região diferente, precisará selecionar uma rede virtual diferente. Você também precisará garantir que essa rede virtual tenha conectividade com a rede virtual da região primária criada acima (e quaisquer outras redes virtuais que hospedem datacenters dentro do cluster de instância gerenciada). Consulte este artigo para saber como emparelhar redes virtuais usando o portal do Azure. Você também precisa certificar-se de que aplicou a função apropriada à sua rede virtual antes de tentar implantar um cluster de instância gerenciada, usando o comando abaixo da CLI.

        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>
    
  2. Preencha os campos apropriados:

    • Nome do datacenter - Na lista suspensa, selecione sua assinatura do Azure.
    • Zona de disponibilidade - Marque esta caixa se quiser que as zonas de disponibilidade sejam habilitadas neste datacenter.
    • Local - Local onde seu datacenter será implantado.
    • Tamanho da SKU - Escolha entre os tamanhos de SKU da máquina virtual disponíveis.
    • N.º de discos - Escolha o número de discos p30 a serem anexados a cada nó Cassandra.
    • N.º de nós - Escolha o número de nós Cassandra que serão implantados neste datacenter.
    • Rede virtual - Selecione uma rede virtual e uma sub-rede que estão saindo.

    Adicionar Datacenter.

    Aviso

    Observe que não permitimos a criação de uma nova rede virtual ao adicionar um datacenter. Você precisa escolher uma rede virtual existente e, como mencionado acima, precisa garantir que haja conectividade entre as sub-redes de destino onde os datacenters serão implantados. Você também precisa aplicar a função apropriada à VNet para permitir a implantação (veja acima).

  3. Quando o datacenter é implantado, você deve ser capaz de exibir todas as informações do datacenter no painel Data Center :

    Exiba os recursos do cluster.

  4. Para garantir a replicação entre data centers, conecte-se ao 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 serão atualizadas automaticamente):

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
    
  5. Se você estiver adicionando um data center a um cluster onde já há dados, precisará executar rebuild para replicar os dados históricos. Na CLI do Azure, execute o comando abaixo para executar nodetool rebuild em cada nó do novo data center, substituindo <new dc ip address> pelo endereço IP do nó e <olddc> pelo nome do seu data center existente:

     az managed-cassandra cluster invoke-command \
       --resource-group $resourceGroupName \
       --cluster-name $clusterName \
       --host <new dc ip address> \
       --command-name nodetool --arguments rebuild="" "<olddc>"=""
    

    Aviso

    Você não deve permitir que os clientes de aplicativos gravem no novo data center até que você tenha aplicado as alterações de replicação de espaço de chave. Caso contrário, a reconstrução não funcionará e você precisará criar uma solicitação de suporte para que nossa equipe possa executar repair em seu nome.

Atualizar configuração Cassandra

O serviço permite a atualização da configuração Cassandra YAML em um datacenter através do portal ou usando comandos CLI. Para atualizar as configurações no portal:

  1. Encontre Cassandra Configuration em configurações. Realce o data center cuja configuração você deseja alterar e clique em atualizar:

    Captura de tela do data center selecionado para atualizar a configuração.

  2. Na janela que se abre, insira os nomes dos campos no formato YAML, conforme mostrado abaixo. Em seguida, clique em atualizar.

    Captura de tela da atualização da configuração do data center Cassandra.

  3. Quando a atualização estiver concluída, os valores substituídos serão exibidos no Cassandra Configuration painel:

    Captura de tela da configuração atualizada de Cassandra.

    Nota

    Apenas os valores de configuração Cassandra substituídos são mostrados no portal.

    Importante

    Verifique se as configurações de Cassandra yaml fornecidas são apropriadas para a versão do Cassandra que você implantou. Veja aqui as configurações de Cassandra v3.11 e aqui para v4.0. As seguintes configurações de YAML não podem ser atualizadas:

    • cluster_name
    • seed_provider
    • initial_token
    • Autobootstrap
    • client_encryption_options
    • server_encryption_options
    • transparent_data_encryption_options
    • audit_logging_options
    • autenticador
    • autorizador
    • 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
    • divisor
    • rpc_address
    • rpc_interface

Atualizar versão Cassandra

Importante

Cassandra 4.1, 5.0 e Turnkey Version Updates, estão em pré-visualização pública. Esses recursos são fornecidos sem um contrato de nível de serviço e não são recomendados para cargas de trabalho de produção. Para obter mais informações, veja Termos Suplementares de Utilização para Pré-visualizações do Microsoft Azure.

Você tem a opção de realizar atualizações de versão principal in-loco diretamente do portal ou através de modelos Az CLI, Terraform ou ARM.

  1. Encontre o Update painel na guia Visão geral

    Captura de tela da atualização da versão Cassandra.

  2. Selecione a versão Cassandra na lista suspensa.

    Aviso

    Não salte versões. Recomendamos atualizar apenas de uma versão para outro exemplo 3.11 para 4.0, 4.0 para 4.1.

    Captura de tela da seleção da versão Cassandra.

  3. Selecione a atualização para salvar.

Replicação chave na mão

Cassandra 5.0 introduz uma abordagem simplificada para a implantação de clusters de várias regiões, oferecendo maior conveniência e eficiência. Usando a funcionalidade de replicação turnkey, a configuração e o gerenciamento de clusters de várias regiões tornaram-se mais acessíveis, permitindo uma integração e operação mais suaves em ambientes distribuídos. Esta atualização reduz significativamente as complexidades tradicionalmente associadas à implantação e manutenção de configurações de várias regiões, permitindo que os usuários usem os recursos da Cassandra com maior facilidade e eficácia.

Selecione a opção referida na lista suspensa.

Gorjeta

  • Nenhum: a replicação automática está definida como nenhuma.
  • SystemKeyspaces: replicar automaticamente todos os keyspaces do sistema (system_auth, system_traces, system_auth)
  • AllKeyspaces: replique automaticamente todos os keyspaces e 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

  • Ao adicionar um novo data center, o recurso de replicação automática no Cassandra será executado nodetool rebuild perfeitamente para garantir a replicação bem-sucedida de dados no data center adicionado.
  • A remoção de um data center aciona uma remoção automática do data center específico dos keyspaces.

Para data centers externos, como os hospedados localmente, eles podem ser incluídos nos keyspaces por meio da utilização da propriedade do data center externo. Isso permite que a Cassandra incorpore esses data centers externos como fontes para o processo de reconstrução.

Aviso

Definir a replicação automática para AllKeyspaces alterará a replicação de keyspaces para incluir WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Se essa não for a topologia desejada, você precisará usar SystemKeyspaces, ajustá-los você mesmo e executar nodetool rebuild manualmente na Instância Gerenciada do Azure para cluster Apache Cassandra.

Desalocar cluster

  1. Para ambientes que não sejam de produção, você pode pausar/desalocar recursos no cluster para evitar ser cobrado por eles (você continuará a ser cobrado pelo armazenamento). Primeiro, altere o tipo de cluster para NonProductione, em seguida deallocate, .

Aviso

Não execute nenhum esquema ou operações de gravação durante a desalocação - isso pode levar à perda de dados e, em casos raros, corrupção de esquema que requer intervenção manual da equipe de suporte.

Captura de ecrã a mostrar a pausa de um cluster.

Resolução de Problemas

Se você encontrar um erro ao aplicar permissões à sua Rede Virtual usando a CLI do Azure, como Não é possível localizar o usuário ou a entidade de serviço no banco de dados gráfico para 'e5007d2c-4b13-4a74-9b6a-605d99f03501', você pode aplicar a mesma permissão manualmente no portal do Azure. Saiba como fazer isso aqui.

Nota

A atribuição de função do Azure Cosmos DB é usada apenas para fins de implantação. A Instância Gerenciada do Azure para Apache Cassandra não tem dependências de back-end no Azure Cosmos DB.

Conectando-se ao cluster

A Instância Gerenciada do Azure para Apache Cassandra não cria nós com endereços IP públicos, portanto, para se conectar ao cluster Cassandra recém-criado, você precisará criar outro recurso dentro da VNet. Isso pode ser um aplicativo ou uma máquina virtual com a ferramenta de consulta de código aberto CQLSH do Apache instalada. Você pode usar um modelo para implantar uma máquina virtual do Ubuntu.

Conectando-se a partir do CQLSH

Depois que a máquina virtual for implantada, use SSH para se conectar à máquina e instale o CQLSH usando os comandos abaixo:

# 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

Conectando-se a partir de um aplicativo

Tal como acontece com o CQLSH, a ligação a partir de uma aplicação utilizando um dos controladores de cliente Apache Cassandra suportados requer que a encriptação SSL esteja ativada e que a verificação de certificação seja desativada. Veja exemplos para se conectar à Instância Gerenciada do Azure para Apache Cassandra usando Java, .NET, Node.js e Python.

A desativação da verificação de certificado é recomendada porque a verificação de certificado não funcionará a menos que você mapeie endereços I.P dos nós do cluster para o domínio apropriado. Se você tiver uma política interna que exige que você faça a verificação do certificado SSL para qualquer aplicativo, você pode facilitar isso adicionando entradas como 10.0.1.5 host1.managedcassandra.cosmos.azure.com em seu arquivo hosts para cada nó. Se adotar essa abordagem, você também precisará adicionar novas entradas sempre que escalar nós.

Para Java, também é altamente recomendável habilitar a política de execução especulativa onde os aplicativos são sensíveis à latência de cauda. Você pode encontrar uma demonstração ilustrando como isso funciona e como habilitar a política aqui.

Nota

Na grande maioria dos casos, não deve ser necessário configurar ou instalar certificados (rootCA, nó ou cliente, truststores, etc.) para se conectar à Instância Gerenciada do Azure para Apache Cassandra. A criptografia SSL pode ser habilitada usando o armazenamento confiável padrão e a senha do tempo de execução que está sendo usado pelo cliente (consulte Exemplos de Java, .NET, Node.js e Python ), porque a Instância Gerenciada do Azure para certificados Apache Cassandra será confiável por esse ambiente. Em casos raros, se o certificado não for confiável, talvez seja necessário adicioná-lo ao armazenamento confiável.

Configurando certificados de cliente (opcional)

A configuração de certificados de cliente é opcional. Um aplicativo cliente pode se conectar à Instância Gerenciada do Azure para Apache Cassandra, desde que as etapas acima tenham sido executadas. No entanto, se preferir, você também pode criar e configurar adicionalmente certificados de cliente para autenticação. Em geral, existem duas maneiras de criar certificados:

  • Certs auto-assinados. Isso significa um certificado privado e público (sem CA) para cada nó - neste caso, precisamos de todos os certificados públicos.
  • Certificados assinados por uma autoridade de certificação. Pode ser uma autoridade de certificação autoassinada ou até mesmo pública. Neste caso, precisamos do certificado de autoridade de certificação raiz (consulte as instruções sobre como preparar certificados SSL para produção) e todos os intermediários (se aplicável).

Se você quiser implementar a autenticação de certificado de cliente para nó ou mTLS (Transport Layer Security) mútuo, precisará fornecer os certificados por meio da CLI do Azure. O comando abaixo carregará e aplicará seus certificados de cliente ao armazenamento confiável para seu cluster de Instância Gerenciada Cassandra (ou seja, você não precisa editar cassandra.yaml as configurações). Uma vez aplicado, seu cluster exigirá que Cassandra verifique os certificados quando um cliente se conectar (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

Clean up resources (Limpar recursos)

Se você não quiser continuar a usar esse cluster de instância gerenciada, exclua-o com as seguintes etapas:

  1. No menu à esquerda do portal do Azure, selecione Grupos de recursos.
  2. Na lista, selecione o grupo de recursos que você criou para este início rápido.
  3. No painel Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
  4. Na janela seguinte, introduza o nome do grupo de recursos a eliminar e, em seguida, selecione Eliminar.

Próximos passos

Neste início rápido, você aprendeu como criar uma Instância Gerenciada do Azure para cluster Apache Cassandra usando o portal do Azure. Agora você pode começar a trabalhar com o cluster: