Início Rápido: criar uma Instância Gerenciada do Azure para o cluster do Apache Cassandra no portal do Azure

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 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 do Apache Cassandra.

Pré-requisitos

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

Criar um cluster de instância gerenciada

Entre no portal do Azure.
Na barra de pesquisa, procure Instância Gerenciada para o Apache Cassandra e selecione o resultado.
Clique no botão Criar Instância Gerenciada para o cluster do Apache Cassandra.
No painel Criar Instância Gerenciada para o 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 contêiner que mantém os recursos relacionados a uma solução do Azure. Para obter mais informações, confira o artigo de visão geral do Grupo de Recursos do Azure.
- Nome do cluster – insira um nome para o cluster.
- Local – local em que o cluster será implantado.
- Versão do Cassandra – Versão do Apache Cassandra que será implantada.
- Extensão – Extensões que serão adicionadas, incluindo o Índice Cassandra Lucene.
- Senha inicial do administrador do Cassandra – senha usada para criar o cluster.
- Confirmar senha de administrador do Cassandra – insira novamente sua senha.
- Rede Virtual: selecione uma Rede Virtual ou Sub-rede existente ou crie uma.
- Atribuir funções: as Redes Virtuais exigem permissões especiais para permitir que clusters do Cassandra gerenciados sejam implantados. Mantenha esta caixa marcada se estiver criando uma rede virtual ou usando uma rede virtual existente sem permissões aplicadas. Se estiver usando uma Rede virtual em que você já implantou clusters do Cassandra de Instância Gerenciada de SQL do Azure, desmarque essa opção.
Dica

Se você usar VPN, não precisará abrir nenhuma outra conexão.
Observação

A implantação de um Instância Gerenciada do Azure para Apache Cassandra requer acesso à Internet. A implantação falha em ambientes em que o acesso à Internet é restrito. Verifique se você não está bloqueando o acesso na sua VNet aos serviços essenciais do Azure a seguir que são necessários para que o Cassandra Gerenciado funcione corretamente. Confira Regras de rede de saída necessárias para obter informações mais detalhadas.
- Armazenamento do Azure
- Azure KeyVault
- Conjuntos de Dimensionamento de Máquinas Virtuais do Azure
- Monitoramento do Azure
- ID do Microsoft Entra
- Segurança do Azure
- Replicação Automática – Escolha a forma de replicação automática a ser utilizada. Saiba mais
- Agendar estratégia de evento – a estratégia a ser usada pelo cluster para eventos agendados.
Dica
- StopANY significa parar qualquer nó quando houver um evento agendado para o nó.
- StopByRack significa apenas parar o nó em um determinado rack para um determinado Evento Agendado, por exemplo, se dois ou mais eventos estiverem agendados para nós em racks diferentes ao mesmo tempo, somente os nós em um rack serão interrompidos, enquanto os outros nós em outros racks serão adiados.
Em seguida, selecione a guia Data center.
Insira os seguintes detalhes:
- Nome do Data Center – Digite um nome de data center no campo de texto.
- Zona de disponibilidade: marque essa caixa de seleção se deseja habilitar as zonas de disponibilidade.
- Tamanho do SKU: escolha entre os tamanhos de SKU de Máquina Virtual disponíveis.
Observação

Introduzimos o cache de gravação (Visualização Pública) por meio 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, especialmente para cargas de trabalho com uso intensivo de leitura. Essas SKUs específicas são equipadas 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 versão prévia 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, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.
- Não. de discos - Escolha o número de discos p30 a serem anexados a cada nó do Cassandra.
- Não. de nós - Escolha o número de nós do Cassando que serão implantados nesse datacenter.
Aviso

Não há suporte para zonas de disponibilidade em todas as regiões. As implantações falharão se você selecionar uma região em que não haja suporte para as zonas de disponibilidade. Confira aqui para ver as regiões com suporte. 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 determinada. As implantações poderão falhar se o SKU selecionado ou a capacidade não estiver disponível em todas as zonas.
Em seguida, selecione Revisar + criar>Criar

Observação

Pode levar até 15 minutos para o cluster ser criado.
Depois de concluir a implantação, verifique o grupo de recursos para ver o cluster de instância gerenciada recém-criado:
Para procurar os nós de cluster, navegue até o recurso de cluster e abra o painel Data Center para exibi-los:

Dimensionar um datacenter

Agora que implantou um cluster com apenas um data center, você pode escalar horizontal ou verticalmente, realçando o data center e selecionando o botão Scale:

Escala horizontal

Para aumentar ou diminuir a escala dos nós, mova o controle deslizante para o número desejado ou simplesmente edite o valor. Quando terminar, clique em Scale.

Escala vertical

Para reduzir ou escalar verticalmente a SKU de seus nós, selecione na lista suspensa Sku Size. Quando terminar, clique em Scale.

Observação

O período de tempo necessário para que os nós sejam escalados depende de vários fatores e 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 nós tenham ingressado no anel do Cassandra. Os nós estarão totalmente prontos quando todos exibirem um status de "íntegro" e o status do datacenter for "bem-sucedido". O dimensionamento é uma operação online e funciona da mesma maneira descrita para aplicação de patches em Operações de gerenciamento

Adicionar um datacenter

Para adicionar outro datacenter, clique no botão adicionar no painel do Data Center:
Aviso

Se você estiver adicionando um datacenter em outra região, 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 estejam hospedando datacenters no cluster de instância gerenciada). Acesse este artigo para saber como emparelhar redes virtuais usando portal do Azure. Você também precisa verificar se aplicou a função apropriada à sua rede virtual antes de tentar implantar um cluster de instância gerenciada usando o comando da CLI abaixo.
```
    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 datacenter: na lista suspensa, selecione sua assinatura do Azure.
- Zona de disponibilidade: marque essa caixa de seleção se deseja habilitar as zonas de disponibilidade nesse datacenter.
- Local: local em que o datacenter será implantado.
- Tamanho do SKU: escolha entre os tamanhos de SKU de Máquina Virtual disponíveis.
- Não. de discos - Escolha o número de discos p30 a serem anexados a cada nó do Cassandra.
- Não. de nós - Escolha o número de nós do Cassando que serão implantados nesse datacenter.
- Rede Virtual: selecione um Rede Virtual de saída e uma sub-rede.
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, conforme mencionado acima, precisa garantir que haja conectividade entre as sub-redes de destino em que os datacenters serão implantados. Você também precisa aplicar a função apropriada à VNet para permitir a implantação (veja acima).
Quando o datacenter for implantado, você poderá exibir todas as suas informações no painel Data Center:
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 keyspace 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};
```
Se você estiver adicionando um data center a um cluster onde já existem dados, é necessário 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ê deve não permitir que clientes de aplicativos gravem no novo data center até que você tenha aplicado as alterações de replicação do keyspace. Caso contrário, a recompilação não funcionará e você precisará criar uma solicitação de suporte para que nossa equipe possa executar repair em seu nome.

Atualizar a configuração do Cassandra

O serviço permite atualizar a configuração do Cassandra YAML em um data center por meio do portal ou usando comandos da CLI. Para atualizar as configurações no portal:

Localize Cassandra Configuration nas configurações. Destaque o data center cuja configuração você deseja alterar e clique em atualizar:
Na janela que será aberta, insira os nomes de campo no formato YAML, conforme mostrado abaixo. Em seguida, clique em Atualizar.
Quando a atualização for concluída, os valores substituídos serão mostrados no painel Cassandra Configuration:

Observação

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

Verifique se as configurações do Cassandra YAML que você forneceu são apropriadas para a versão implantada do Cassandra. Veja aqui as configurações do Cassandra v3.11 e a versão v4.0 aqui. As configurações do YAML a seguir não têm permissão para serem 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
- partitioner
- rpc_address
- rpc_interface

Atualizar a versão do Cassandra

Importante

Cassandra 5.0 e atualizações de versão turnkey estão em versão prévia pública. Esses recursos são fornecidos sem 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, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

Você tem a opção de realizar as atualizações das versões principais in-loco diretamente do portal ou por meio de modelos da CLI do Azure, do Terraform ou do ARM.

Localize o painel Update na guia Visão Geral
Selecione a versão do Cassandra na lista suspensa.

Aviso

Não pule as versões. É recomendável atualizar apenas de uma versão para outra, por exemplo 3.11 para 4.0, 4.0 para 4.1.
Selecione a atualização para salvar.

Replicação turnkey

O Cassandra 5.0 apresenta uma abordagem simplificada para implantar 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. Essa 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 do Cassandra com maior facilidade e eficácia.

Dica

None: a replicação automática é definida como nenhuma.
SystemKeyspaces: replicar automaticamente todos os keyspaces do sistema (system_auth, system_traces, system_auth)
AllKeyspaces: replicar automaticamente todos os keyspaces, monitorar se novos keyspaces forem criados e aplicar automaticamente as configurações de replicação automática.

Cenários de replicação automática

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

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

Aviso

A configuração da replicação automática para AllKeyspaces alterará a replicação de seus 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 os SystemKeyspaces, ajustá-los por conta própria e executar nodetool rebuild manualmente no cluster da Instância Gerenciada do Azure para Apache Cassandra.

Desalocar o cluster

Para ambiente de não 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 NonProduction, depois deallocate.

Dica

O tipo de cluster deve ser usado como "Não produção" apenas para economizar custos de desenvolvimento. Eles podem vir com SKUs menores e NÃO devem ser usados para executar cargas de trabalho de produção.

Aviso

O tipo de cluster definido como "Não produção" não terá garantias de SLA aplicadas a ele.
Não execute nenhuma operação de esquema ou gravação durante a desalocação. Isso pode levar à perda de dados e, em casos raros, à corrupção do esquema que exige intervenção manual da equipe de suporte.

Solução de problemas

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

Observação

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

Como se conectar ao cluster

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

Conexão por meio do CQLSH

Após a implantação da máquina virtual, use o SSH para se conectar ao computador 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

Conexão por meio de um aplicativo

Assim como acontece com o CQLSH, a conexão por meio de um aplicativo usando um dos drivers de cliente do Apache Cassandra com suporte exige que a criptografia SSL esteja habilitada e que a verificação de certificação esteja desabilitada. Veja exemplos de conexões da Instância Gerenciada do Azure para o Apache Cassandra usando Java, .NET, Node.js e Python.

Recomendamos desabilitar a verificação de certificado, porque ela não funcionará, a menos que você mapeie os endereços IP dos nós de cluster para o domínio apropriado. Se você tiver uma política interna que determina que você faça a verificação de certificado SSL para qualquer aplicativo, você pode facilitar isso adicionando entradas como 10.0.1.5 host1.managedcassandra.cosmos.azure.com no seu arquivo de host para cada nó. Se estiver adotando essa abordagem, você também precisará adicionar novas entradas sempre que aumentar os nós.

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

Observação

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 ativada usando o repositório de confiança e a senha padrão do ambiente de execução utilizado pelo cliente (veja os exemplos em Java, .NET, Node.js e Python), pois os certificados da Instância Gerenciada do Azure para Apache Cassandra serão confiáveis nesse ambiente. Em casos raros, se o certificado não for confiável, talvez seja necessário adicioná-lo ao truststore.

Configurando certificados de cliente (opcional)

A configuração dos certificados do 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 poderá criar e configurar certificados de cliente adicionais para autenticação. Em geral, há duas maneiras de criar certificados:

Certificados autoassinados. Isso significa um certificado privado e público (sem a AC) para cada nó; nesse caso, precisamos de todos os certificados públicos.
Certificados assinados por uma AC. Isso pode ser uma AC autoassinada ou, até mesmo, uma pública. Nesse caso, precisamos do Certificado de Autoridade de Certificação raiz (veja as instruções sobre como preparar certificados SSL para produção) e de todos os intermediários (se aplicável).

Se quiser implementar a autenticação de certificado cliente para nó ou a Segurança de Camada de Transporte mútua (mTLS), você precisará fornecer os certificados por meio da CLI do Azure. O comando abaixo carregará e aplicará seus certificados do cliente ao truststore do seu cluster de Instância Gerenciada do Cassandra (ou seja, você não precisa editar as configurações do cassandra.yaml). Após ter sido aplicado, seu cluster irá requerer que o Cassandra verifique os certificados sempre que um cliente se conectar (confira require_client_auth: true nas client_encryption_options do Cassandra).

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 os recursos

Caso não vá continuar usando esse cluster da instância gerenciada, exclua-o seguindo estas etapas:

No menu à esquerda do portal do Azure, selecione Grupos de recursos.
Na lista, selecione o grupo de recursos criado neste início rápido.
Na página Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
Na próxima janela, insira o nome do grupo de recursos a ser excluído e selecione Excluir.

Próximas etapas

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

Implantar um cluster do Apache Spark gerenciado com o Azure Databricks

Compartilhar via

Início Rápido: criar uma Instância Gerenciada do Azure para o cluster do Apache Cassandra no portal do Azure

Pré-requisitos

Criar um cluster de instância gerenciada

Dimensionar um datacenter

Escala horizontal

Escala vertical

Adicionar um datacenter

Atualizar a configuração do Cassandra

Atualizar a versão do Cassandra

Replicação turnkey

Cenários de replicação automática

Desalocar o cluster

Solução de problemas

Como se conectar ao cluster

Conexão por meio do CQLSH

Conexão por meio de um aplicativo

Configurando certificados de cliente (opcional)

Limpar os recursos

Próximas etapas

Comentários

Recursos adicionais