Guia de início rápido: criar uma instância gerenciada do Azure para cluster Apache Cassandra usando a CLI 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 onde necessário.
Este guia de início rápido demonstra como usar os comandos da CLI do Azure para criar um cluster com a Instância Gerenciada do Azure para Apache Cassandra. Ele também mostra para criar um datacenter e dimensionar nós para cima ou para baixo dentro do datacenter.
Pré-requisitos
Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Guia de início rápido para Bash no Azure Cloud Shell.
Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.
Se estiver a utilizar uma instalação local, inicie sessão no CLI do Azure ao utilizar o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de entrada, consulte Entrar com a CLI do Azure.
Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre as extensões, veja Utilizar extensões com o CLI do Azure.
Execute o comando az version para localizar a versão e as bibliotecas dependentes instaladas. Para atualizar para a versão mais recente, execute o comando az upgrade.
Rede Virtual do Azure com conectividade com seu ambiente auto-hospedado ou local. Para obter mais informações sobre como conectar ambientes locais ao Azure, consulte o artigo Conectar uma rede local ao Azure .
Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar.
Importante
Este artigo requer a CLI do Azure versão 2.30.0 ou superior. Se você estiver usando o Azure Cloud Shell, a versão mais recente já está instalada.
Criar um cluster de instância gerenciado
Inicie sessão no portal do Azure
Defina sua ID de assinatura na CLI do Azure:
az account set -s <Subscription_ID>Em seguida, crie uma Rede Virtual com uma sub-rede dedicada no seu grupo de recursos:
az network vnet create -n <VNet_Name> -l eastus2 -g <Resource_Group_Name> --subnet-name <Subnet Name>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:
- Storage do Azure
- Azure KeyVault
- Conjuntos de Dimensionamento de Máquinas Virtuais do Azure
- Monitorização do Azure
- Microsoft Entra ID
- Azure Security
Aplique algumas permissões especiais à Rede Virtual, que são exigidas pela instância gerenciada. Use o
az role assignment createcomando, substituindo<subscriptionID>,<resourceGroupName>e<vnetName>com os 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>Nota
Os
assigneevalores eroleno comando anterior são valores fixos, insira esses valores exatamente como mencionado no comando. Não fazer isso levará a erros ao criar o cluster. Se você encontrar algum erro ao executar este comando, talvez não tenha permissões para executá-lo, entre em contato com seu administrador para obter permissões.Em seguida, crie o cluster em sua Rede Virtual recém-criada usando o comando az managed-cassandra cluster create . Execute o seguinte comando o valor da
delegatedManagementSubnetIdvariável:Nota
O valor da variável que você fornecerá abaixo é exatamente o mesmo que o valor da
delegatedManagementSubnetId--scopeque você forneceu 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 \ --debugFinalmente, crie um datacenter para o cluster, com três nós, Standard D8s v4 VM SKU, 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 falseNota
O valor para
--skupode ser escolhido entre as 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-zoneestá definido comofalse. Para habilitar zonas de disponibilidade, defina comotrue. As zonas de disponibilidade aumentam o SLA de disponibilidade do serviço. Para obter mais detalhes, consulte os detalhes completos do SLA aqui.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.
Depois que o datacenter for criado, se você quiser aumentar ou reduzir os nós no datacenter, execute o comando az managed-cassandra datacenter update . Altere o valor do
node-countparâmetro 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 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 Cassandra recém-criado, você deve criar outro recurso dentro da rede virtual. Este recurso 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 do Gerenciador de Recursos 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 instalar 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
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
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.
Clean up resources (Limpar recursos)
Quando não for mais necessário, você poderá usar o comando para remover o az group delete grupo de recursos, a instância gerenciada e todos os recursos relacionados:
az group delete --name <Resource_Group_Name>
Próximos passos
Neste início rápido, você aprendeu como criar uma Instância Gerenciada do Azure para cluster Apache Cassandra usando a CLI do Azure. Agora você pode começar a trabalhar com o cluster: