Compartilhar via

Início Rápido: criar um cluster da Instância Gerenciada do Azure para Apache Cassandra usando a CLI do Azure

  • Artigo

A Instância Gerenciada do Azure para Apache Cassandra é um serviço totalmente gerenciado para clusters do Apache Cassandra apenas de código aberto. O serviço também permite que as configurações sejam substituídas, dependendo das necessidades específicas de cada carga de trabalho, permitindo flexibilidade e controle máximos quando necessário.

Este início rápido demonstra como usar comandos da CLI do Azure para criar um cluster com uma Instância Gerenciada do Azure para Apache Cassandra. Ele também mostra como criar um datacenter e escalar ou reduzir os nós verticalmente dentro do datacenter.

Pré-requisitos

Importante

Este artigo exige a CLI do Azure versão 2.30.0 ou superior. Se você está usando o Azure Cloud Shell, a última versão já está instalada.

Criar um cluster de instância gerenciada

  1. Entre no Portal do Azure

  2. Defina sua ID da assinatura na CLI do Azure:

    az account set -s <Subscription_ID>

  3. Em seguida, crie uma Rede Virtual com uma sub-rede dedicada em seu grupo de recursos:

    az network vnet create -n <VNet_Name> -l eastus2 -g <Resource_Group_Name> --subnet-name <Subnet Name>

    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 dentro de sua vNet aos seguintes serviços essenciais do Azure que são necessários para que o Cassandra gerenciado funcione corretamente:

    • 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

  4. Aplique algumas permissões especiais à Rede Virtual, que são exigidas pela instância gerenciada. Use o comando az role assignment create, substituindo <subscriptionID>, <resourceGroupName> e <vnetName> pelos valores apropriados:

    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>

    Observação

    Os valores de assignee e role no comando anterior são valores fixos; insira-os exatamente como mencionados no comando. Deixar de fazer isso levará a erros ao criar o cluster. Se você encontrar erros ao executar este comando, talvez não tenha permissões para executá-lo; entre em contato com seu administrador para obter permissões.

  5. Em seguida, crie o cluster na Rede Virtual recém-criada usando o comando az managed-cassandra cluster create. Execute o seguinte comando no valor da variável delegatedManagementSubnetId:

    Observação

    O valor da variável delegatedManagementSubnetId que você fornecerá abaixo é exatamente o mesmo que o valor --scope fornecido no comando acima:

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster_Name>'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/<VNet name>/subnets/<subnet name>'
initialCassandraAdminPassword='myPassword'
cassandraVersion='3.11' # set to 4.0 for a Cassandra 4.0 cluster

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --initial-cassandra-admin-password $initialCassandraAdminPassword \
  --cassandra-version $cassandraVersion \
  --debug

  6. Por fim, crie um datacenter para o cluster, com três nós, SKU de VM Standard D8s v4, com 4 discos P30 anexados para cada nó, usando o comando az managed-cassandra datacenter create:

    dataCenterName='dc1'
dataCenterLocation='eastus2'
virtualMachineSKU='Standard_D8s_v4'
noOfDisksPerNode=4

az managed-cassandra datacenter create \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --data-center-location $dataCenterLocation \
  --delegated-subnet-id $delegatedManagementSubnetId \
  --node-count 3 \
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false

    Observação

    O valor de --sku pode ser escolhido entre os seguintes SKUs disponíveis:

    • Standard_E8s_v4
    • Standard_E16s_v4
    • Standard_E20s_v4
    • Standard_E32s_v4
    • Standard_DS13_v2
    • Standard_DS14_v2
    • Standard_D8s_v4
    • Standard_D16s_v4
    • Standard_D32s_v4

    Observe também que --availability-zone é definido como false. Para habilitar zonas de disponibilidade, defina isso como true. As zonas de disponibilidade aumentam o SLA de disponibilidade do serviço. Para obter mais detalhes, revise os detalhes completos do SLA aqui.

    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.

  7. Depois que o datacenter for criado, se quiser escalar ou reduzir verticalmente os nós no datacenter, execute o comando az managed-cassandra datacenter update. Altere o valor do parâmetro node-count para o valor desejado:

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'
dataCenterName='dc1'
dataCenterLocation='eastus2'

az managed-cassandra datacenter update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --node-count 9

Conectar-se ao seu cluster

A Instância Gerenciada do Azure para Apache Cassandra não cria nós com endereços IP públicos. Para se conectar ao cluster do Cassandra recém-criado, você precisa criar outro recurso dentro da rede virtual. Esse recurso pode ser um aplicativo ou uma máquina virtual com a ferramenta de consulta de software livre CQLSH do Apache instalada. Você pode usar um modelo do Resource Manager para implantar uma máquina virtual 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, conforme mostrado nos 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

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

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.

Limpar os recursos

Quando não forem mais necessários, você poderá usar o comando az group delete para remover o grupo de recursos, a instância gerenciada e todos os recursos relacionados:

az group delete --name <Resource_Group_Name>

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 a CLI do Azure. Você já pode começar a trabalhar com o cluster:

Implantar um cluster do Apache Spark gerenciado com o Azure Databricks