Compartilhar via

Início Rápido: Configurar um cluster híbrido com a Instância Gerenciada do Azure para Apache Cassandra

A Instância Gerenciada do Azure para Apache Cassandra é um serviço totalmente gerenciado para clusters puros de código aberto do Apache Cassandra. 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 início rápido demonstra como usar os comandos da CLI do Azure para configurar um cluster híbrido. Se você tiver datacenters existentes em um ambiente local ou auto-hospedado, poderá usar a Instância Gerenciada do Azure para Apache Cassandra para adicionar outros datacenters a esses clusters e mantê-los.

Pré-requisitos

  • Este artigo requer a CLI do Azure versão 2.30.0 ou posterior. Se você está usando o Azure Cloud Shell, a última versão já está instalada.
  • Use uma 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 Conectar uma rede local ao Azure.

Configurar um cluster híbrido

  1. Entre no portal do Azure e acesse o recurso de rede virtual.

  2. Selecione a guia Sub-redes e crie uma nova sub-rede. Para saber mais sobre os campos no formulário Adicionar sub-rede , consulte Adicionar uma sub-rede.

    Captura de tela que mostra a opção de aceitar e adicionar uma nova sub-rede à sua rede virtual.

    A implantação da 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 em sua rede virtual aos seguintes serviços vitais do Azure necessários para que a Instância Gerenciada do Azure para Apache Cassandra funcione corretamente. Para obter uma lista de dependências de endereço IP e porta, consulte as regras de rede de saída necessárias.

    • Armazenamento do Azure
    • Azure Key Vault
    • Conjuntos de dimensionamento de máquina virtual do Azure
    • Azure Monitor
    • Microsoft Entra ID
    • Microsoft Defender para Nuvem

  3. Aplique algumas permissões especiais à rede virtual e à sub-rede, que a Instância Gerenciada do Azure para Apache Cassandra exige, usando a CLI do Azure. Use o comando az role assignment create. Substitua <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>

    Os valores assignee e role no comando anterior são identificadores fixos de principal de serviço e de função, respectivamente.

  4. Configure recursos para o cluster híbrido. Como você já tem um cluster, o nome do cluster é um recurso lógico para identificar o nome do cluster existente. Use o nome do cluster existente quando você definir clusterName e clusterNameOverride variáveis no script a seguir.

    Você também precisa, no mínimo, dos nós de semente do datacenter existente e dos certificados de fofoca necessários para criptografia de nó a nó. A Instância Gerenciada do Azure para Apache Cassandra exige a criptografia de nó a nó para a comunicação entre datacenters. Se você ainda não implementou a criptografia de nó a nó em seu cluster atual, é necessário fazê-lo. Para obter mais informações, confira Criptografia nó a nó. Forneça o caminho para o local dos certificados. Cada certificado deve estar no formato PEM (Email Avançado de Privacidade), por exemplo, -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Em geral, há duas maneiras de implementar certificados:

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

    Opcionalmente, se você quiser implementar a autenticação de certificado cliente a nó ou o TLS (Transport Layer Security), forneça os certificados no mesmo formato que quando você criou o cluster híbrido. Consulte o exemplo da CLI do Azure mais adiante neste artigo. Os certificados são fornecidos no --client-certificates parâmetro.

    Essa abordagem carrega e aplica seus certificados de cliente ao repositório de confiança para o cluster da Instância Gerenciada do Azure para Apache Cassandra. Você não precisa editar cassandra.yaml as configurações. Depois que os certificados são aplicados, o cluster requer que o Cassandra verifique os certificados quando um cliente se conecta. Para obter mais informações, consulte require_client_auth: true Cassandra client_encryption_options.

    O valor da delegatedManagementSubnetId variável que você fornece neste código é o mesmo que o valor fornecido --scope em um comando anterior:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster-legal-name'
clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'

# You can override the cluster name if the original name isn't legal for an Azure resource:
# overrideClusterName='ClusterNameIllegalForAzureResource'
# the default cassandra version will be v3.11

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
  --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
  # optional - add your existing datacenter's client-to-node certificates (if implemented):
  # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed

    Se o cluster já tiver criptografia de nó a nó e cliente para nó, você deverá saber onde seus certificados TLS/SSL de fofoca ou cliente existentes são mantidos. Se você não tiver certeza, execute keytool -list -keystore <keystore-path> -rfc -storepass <password> para imprimir os certificados.

  5. Após a criação do recurso de cluster, execute o seguinte comando para obter os detalhes de configuração do cluster:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'

az managed-cassandra cluster show \
   --cluster-name $clusterName \
   --resource-group $resourceGroupName \

  6. O comando anterior retorna informações sobre o ambiente da instância gerenciada. Você precisa dos certificados de gossip para poder instalá-los no repositório de confiança para nós em seu datacenter existente. A captura de tela a seguir mostra a saída do comando anterior e o formato dos certificados.

    Captura de tela que mostra o resultado da obtenção dos detalhes do certificado do cluster.

    Os certificados retornados do comando anterior contêm quebras de linha que são representadas como texto. Um exemplo é \r\n. Copie cada certificado para um arquivo e formate-o antes de tentar importá-lo para o repositório de confiança existente.

    Copie o valor da gossipCertificates matriz mostrado na captura de tela em um arquivo. Use o script Bash a seguir para formatar os certificados e criar arquivos PEM separados para cada um. Para baixar o script Bash, consulte Baixar o jq para sua plataforma.

    readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
# iterate through the certs array, format each cert, write to a numbered file.
num=0
filename=""
for item in "${cert_array[@]}"; do
let num=num+1
filename="cert$num.pem"
cert=$(jq '.pem' <<< $item)
echo -e $cert >> $filename
sed -e 's/^"//' -e 's/"$//' -i $filename
done

  7. Em seguida, crie um datacenter no cluster híbrido. Substitua os valores de variável pelos detalhes do cluster:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
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 9
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false

    Escolha o valor de --sku dentre as seguintes faixas de produto 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

    O valor de --availability-zone é definido como false. Para habilitar zonas de disponibilidade, defina esse valor como true. As zonas de disponibilidade aumentam o SLA (contrato de nível de serviço) de disponibilidade do serviço. Para obter mais informações, consulte SLA para serviços online.

    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 há suporte para zonas de disponibilidade. Para regiões com suporte, consulte a lista de regiões do Azure.

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

  8. Agora que o novo datacenter foi criado, execute o datacenter show comando para exibir seus detalhes:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'

az managed-cassandra datacenter show \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName

    O comando anterior exibe os nós de semente do novo datacenter.

    Captura de tela que mostra como obter detalhes do datacenter.

  9. Adicione os novos nós de semente do datacenter à configuração de nó de semente do datacenter existente no arquivo cassandra.yaml. Instale os certificados de fofoca da instância gerenciada que você coletou anteriormente no repositório de confiança para cada nó em seu cluster existente. Use o keytool comando para cada certificado:

    keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass

    Se você quiser adicionar mais datacenters, repita as etapas anteriores, mas precisará apenas dos nós de semente.

    Importante

    Se o cluster do Apache Cassandra existente tiver apenas um único datacenter e esse datacenter for o primeiro adicionado, verifique se o parâmetro endpoint_snitch em cassandra.yaml está definido como GossipingPropertyFileSnitch.

    Se o código do aplicativo existente usar QUORUM para consistência, certifique-se de que, antes de alterar as configurações de replicação na próxima etapa, o código do aplicativo existente esteja usando LOCAL_QUORUM para se conectar ao cluster existente. Caso contrário, as atualizações ao vivo falharão depois que você alterar as configurações de replicação na etapa a seguir. Depois de alterar a estratégia de replicação, você poderá, se preferir, reverter para QUORUM.

  10. Por fim, use a seguinte consulta de Linguagem de Consulta Cassandra para atualizar a estratégia de replicação em cada keyspace para abranger todos os datacenters no cluster.

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};

    Você também precisa atualizar várias tabelas do sistema:

    ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}

    Se os datacenters em seu cluster existente não imporem a criptografia cliente a nó (SSL) e você pretende que o código do aplicativo se conecte diretamente à Instância Gerenciada do Azure para Apache Cassandra, você também precisará habilitar o TLS/SSL no código do aplicativo.

Usar um cluster híbrido para migração em tempo real

As instruções anteriores fornecem diretrizes sobre como configurar um cluster híbrido. Essa abordagem também é uma ótima maneira de realizar uma migração sem interrupções e sem tempo de inatividade. O procedimento a seguir mostra como migrar um ambiente local ou outro ambiente de Cassandra que você deseja descomissionar, sem interrupção, para a Instância Gerenciada do Azure para Apache Cassandra.

  1. Configurar um cluster híbrido. Siga as instruções anteriores.

  2. Desabilite temporariamente os reparos automáticos na Instância Gerenciada do Azure para Apache Cassandra durante a migração:

    az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled false

  3. Na CLI do Azure, use o comando a seguir para ser executado nodetool rebuild em cada nó em seu novo datacenter da Instância Gerenciada do Azure para Apache Cassandra. Substitua <ip address> pelo endereço IP do nó. Substitua <sourcedc> pelo nome do datacenter existente, aquele do qual você está migrando:

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

    Execute este comando somente depois de executar todas as etapas anteriores. Essa abordagem deve garantir que todos os dados históricos sejam replicados para seus novos datacenters na Instância Gerenciada do Azure para Apache Cassandra. Você pode executar rebuild em um ou mais nós ao mesmo tempo. Execute em um nó de cada vez para reduzir o efeito no cluster existente. Execute em vários nós quando o cluster puder manipular a E/S adicional e a pressão de rede. Para a maioria das instalações, você pode executar apenas uma ou duas em paralelo para não sobrecarregar o cluster.

    Aviso

    Você deve especificar a origem data center ao executar nodetool rebuild. Se você fornecer o datacenter incorretamente na primeira tentativa, os intervalos de tokens serão copiados sem que os dados sejam copiados para suas tabelas não-sistema. As tentativas subsequentes falharão mesmo se você fornecer o centro de dados corretamente. Para resolver esse problema, exclua entradas para cada keyspace não-sistema em system.available_ranges utilizando a ferramenta de consulta cqlsh no datacenter de destino da Instância Gerenciada do Azure para Apache Cassandra:

    delete from system.available_ranges where keyspace_name = 'myKeyspace';

  4. Corte o código do aplicativo para apontar para os nós de semente em seus novos datacenters da Instância Gerenciada do Azure para Apache Cassandra.

    Como também mencionado nas instruções de instalação híbrida, se os datacenters em seu cluster existente não imporem a criptografia de cliente para nó (SSL), habilite esse recurso no código do aplicativo. A Instância Gerenciada do Azure para Apache Cassandra impõe esse requisito.

  5. Execute ALTER KEYSPACE para cada keyspace da mesma maneira que foi feito anteriormente. Agora você pode remover seus datacenters antigos.

  6. Execute o encerramento da ferramenta de nó para cada nó de datacenter antigo.

  7. Alterne o código da aplicação de volta para QUORUM, se for necessário ou preferido.

  8. Reativar reparos automáticos:

    az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled true

Solução de problemas

Se você encontrar um erro ao aplicar permissões à sua rede virtual usando a CLI do Azure, poderá aplicar a mesma permissão manualmente no portal do Azure. Um exemplo desse erro é "Não é possível localizar o usuário ou o serviço principal no banco de dados gráfico para e5007d2c-4b13-4a74-9b6a-605d99f03501". Para obter mais informações, consulte Usar o portal do Azure para adicionar o serviço principal do Azure Cosmos DB.

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 dependências de back-end no Azure Cosmos DB.

Limpar os recursos

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

  1. No menu esquerdo 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. Na página Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
  4. No próximo painel, insira o nome do grupo de recursos a ser excluído e selecione Excluir.

Próxima etapa

Gerenciar recursos da Instância Gerenciada do Azure para Apache Cassandra usando a CLI do Azure

  • Last updated on