Partilhar via

Guia de 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 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, para máxima flexibilidade e controle.

Este guia de 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ê estiver usando o Azure Cloud Shell, a versão mais recente 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 vá para seu 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 ecrã 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 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 Instância Gerida do Azure para Apache Cassandra funcione corretamente. Para obter uma lista de dependências de porta e endereço IP, consulte Regras de rede de saída necessárias.

    • Storage do Azure
    • Azure Key Vault
    • Conjuntos de Dimensionamento de Máquinas Virtuais do Azure
    • Azure Monitor
    • Microsoft Entra ID
    • Microsoft Defender para a Cloud

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

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

  4. Configure recursos para seu 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 ao definir clusterName e clusterNameOverride variáveis no script a seguir.

    Você também precisa, no mínimo, dos nós primários do seu datacenter existente e dos certificados de comunicação necessários para a criptografia nó a nó. A Instância Gerenciada do Azure para Apache Cassandra requer criptografia nó a nó para comunicação entre datacenters. Se você não tiver a criptografia nó a nó implementada em seu cluster existente, precisará implementá-la. Para obter mais informações, consulte Criptografia nó a nó. Forneça o caminho para o local dos certificados. Cada certificado deve estar no formato PEM (Privacy Enhanced Mail), por exemplo, -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Em geral, há duas maneiras de implementar certificados:

    • Certificados autoassinados. Certificados privados e públicos sem Autoridade de Certificação (CA) para cada nó. Nesse caso, você precisa de todos os certificados públicos.
    • Certificados assinados por uma autoridade de certificação. Certificados emitidos por uma autoridade de certificação autoassinada ou pública. Nesse caso, você precisa do certificado de autoridade de certificação raiz e 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 de cliente para nó ou TLS (Transport Layer Security) mútuo, forneça os certificados no mesmo formato de 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 os certificados do cliente ao repositório de confiança para a sua Instância Gerida do Azure para o cluster Apache Cassandra. Não é necessário editar cassandra.yaml as configurações. Depois que os certificados são aplicados, o cluster exige que Cassandra verifique os certificados quando um cliente se conecta. Para obter mais informações, consulte require_client_auth: true em Cassandra client_encryption_options.

    O valor da delegatedManagementSubnetId variável fornecida 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 nó a nó e cliente a nó, você deve saber onde estão mantidos seus certificados TLS/SSL existentes ou de troca de mensagens. Se estiver incerto, execute keytool -list -keystore <keystore-path> -rfc -storepass <password> para imprimir os certificados.

  5. Depois que o recurso de cluster for criado, execute o seguinte comando para obter os detalhes da 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 de instância gerenciada. Você precisa dos certificados de gossip para que possa instalá-los na loja de confiança para os nós no 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 seu armazenamento confiável existente.

    Copie o valor da gossipCertificates matriz mostrado na captura de tela para um arquivo. Use o seguinte script Bash para formatar os certificados e criar arquivos PEM separados para cada um. Para baixar o script Bash, consulte Baixar 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 novo datacenter no cluster híbrido. Substitua os valores das variáveis 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 para --sku entre as seguintes camadas 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 for --availability-zone é definido como false. Para habilitar zonas de disponibilidade, defina esse valor como true. As zonas de disponibilidade aumentam o contrato de nível de serviço (SLA) de disponibilidade do serviço. Para obter mais informações, consulte SLA para serviços online.

    As zonas de disponibilidade não são suportadas em todas as regiões. As implantações falham se você selecionar uma região onde as zonas de disponibilidade não são suportadas. 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 na região específica. As implantações podem 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 inicialização do novo datacenter.

    Captura de tela que mostra como obter detalhes do datacenter.

  9. Adicione os nós semente do novo centro de dados à configuração do nó semente do centro de dados existente no arquivo cassandra.yaml. Instale os certificados de gossip da managed instance que coletou anteriormente no repositório de confiança para cada nó do 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 quiser adicionar mais datacenters, repita as etapas anteriores, mas precisará apenas dos nós semente.

    Importante

    Se o cluster Apache Cassandra existente tiver apenas um único datacenter e este datacenter for o primeiro adicionado, certifique-se de que o endpoint_snitch parâmetro in cassandra.yaml esteja definido como GossipingPropertyFileSnitch.

    Se o código do aplicativo existente usa 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 use LOCAL_QUORUM para se conectar ao cluster existente. Caso contrário, as atualizações em tempo real 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ê pode reverter para QUORUM se preferir.

  10. Por fim, use a seguinte consulta Cassandra Query Language para atualizar a estratégia de replicação em cada espaço de chave para incluir 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 criptografia de cliente para nó (SSL) e você pretender que o código do aplicativo se conecte diretamente à Instância Gerenciada do Azure para Apache Cassandra, também precisará habilitar TLS/SSL no código do aplicativo.

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

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

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

  2. Desative 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 seguinte comando para executar nodetool rebuild em cada nó em sua nova Instância Gerenciada do Azure para o datacenter Apache Cassandra. Substitua <ip address> pelo endereço IP do servidor. Substitua <sourcedc> pelo nome do seu 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. Executado em vários nós quando o cluster pode lidar com a E/S extra e a pressão da 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 token serão copiados sem que os dados sejam copiados para suas tabelas que não sejam do sistema. As tentativas subsequentes falham mesmo se você fornecer o datacenter corretamente. Para resolver esse problema, exclua entradas para cada espaço de chave que não seja do sistema em system.available_ranges usando a cqlsh ferramenta de consulta em sua instância gerenciada do Azure de destino para o datacenter Apache Cassandra.

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

  4. Redirecione o código da aplicação para apontar para os nós de origem na sua nova Instância Gerida do Azure para datacenters Apache Cassandra.

    Como também mencionado nas instruções de configuração híbrida, se os datacenters em seu cluster existente não imporem 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 espaço de chave, da mesma maneira que feito anteriormente. Agora você pode remover seus datacenters antigos.

  6. Execute node tool decommission para cada nó antigo do datacenter.

  7. Mude o código do aplicativo de volta para QUORUM, se necessário ou preferido.

  8. Reative os reparos automáticos:

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

Resolução de Problemas

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

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)

Se você não quiser continuar a usar esse cluster de instância gerenciado, 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. No painel Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
  4. No painel seguinte, introduza o nome do grupo de recursos a eliminar e, em seguida, selecione Eliminar.

Próximo passo

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

  • Last updated on