Guia de início rápido: configurar um cluster híbrido com a Instância Gerenciada do Azure para Apache Cassandra

Artigo
11/15/2023

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 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 esse cluster e mantê-los.

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.

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

Configurar um cluster híbrido

Entre no portal do Azure e navegue até seu recurso de Rede Virtual.
Abra a guia Sub-redes e crie uma nova sub-rede. Para saber mais sobre os campos no formulário Adicionar sub-rede , consulte o artigo Rede Virtual:
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. Você também pode encontrar uma extensa lista de dependências de porta e endereço IP aqui.
- Storage do Azure
- Azure KeyVault
- Conjuntos de Dimensionamento de Máquinas Virtuais do Azure
- Monitorização do Azure
- Microsoft Entra ID
- Azure Security
Agora, aplicaremos algumas permissões especiais à VNet e à sub-rede que a Instância Gerenciada Cassandra exige, usando a CLI do Azure. Use o az role assignment create comando, 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 assignee valores e no comando anterior são identificadores de princípio de serviço fixo e role de função, respectivamente.
Em seguida, configuraremos recursos para nosso cluster híbrido. Como você já tem um cluster, o nome do cluster aqui será apenas um recurso lógico para identificar o nome do cluster existente. Certifique-se de usar o nome do cluster existente ao definir clusterName as variáveis no script a clusterNameOverride seguir.

Você também precisa, no mínimo, dos nós de propagação do seu datacenter existente e dos certificados de fofoca 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, será necessário implementá-la - consulte a documentação aqui. Você deve fornecer o caminho para o local dos certificados. Cada certificado deve estar em formato PEM, por exemplo. -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE----- Em geral, existem duas formas de implementar certificados:
1. 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.
2. 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).
Opcionalmente, se você quiser implementar a autenticação de certificado de cliente para nó ou mTLS (Transport Layer Security) mútuo, precisará fornecer os certificados no mesmo formato que ao criar o cluster híbrido. Consulte o --client-certificates exemplo de CLI do Azure abaixo - os certificados são fornecidos no parâmetro. Isso 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 as configurações cassandra.yaml). 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).

Nota

O valor da variável que você fornecerá abaixo é exatamente o mesmo que o valor da delegatedManagementSubnetId--scope que você forneceu no comando acima:
```
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 is not 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
```
Nota

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

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 \

O comando anterior retorna informações sobre o ambiente de instância gerenciada. Você precisará dos certificados de fofoca para que possa instalá-los no armazenamento confiável 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:

Nota

Os certificados retornados do comando acima contêm quebras de linha representadas como texto, por exemplo \r\n. Você deve copiar cada certificado para um arquivo e formatá-lo antes de tentar importá-lo para o armazenamento confiável do datacenter existente.
Gorjeta

Copie o valor da matriz mostrado na captura de tela acima em um arquivo e use o seguinte script bash (você precisaria baixar e instalar o gossipCertificates jq para sua plataforma) para formatar os certificados e criar arquivos pem separados para cada um.
```
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
```
Em seguida, crie um novo datacenter no cluster híbrido. Certifique-se de substituir 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
```
Nota

O valor para --sku pode 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-zone está definido como false. Para habilitar zonas de disponibilidade, defina como true. 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.

Agora que o novo datacenter foi criado, execute o comando show datacenter 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 produz os nós semente do novo datacenter:
Agora, adicione os nós semente do novo datacenter à configuração do nó semente do datacenter existente no arquivo cassandra.yaml. E instale os certificados de fofoca da instância gerenciada que você coletou anteriormente no armazenamento confiável para cada nó do cluster existente, usando keytool o comando para cada certificado:
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Nota

Se quiser adicionar mais datacenters, você pode repetir as etapas acima, mas só precisa dos nós de semente.

Importante

Se o cluster Apache Cassandra existente tiver apenas um único data center, e esta for a primeira vez que um data center está sendo adicionado, verifique se o endpoint_snitch parâmetro in cassandra.yaml está definido como GossipingPropertyFileSnitch.

Importante

Se o código do aplicativo existente estiver usando o QUORUM para consistência, você deve garantir que, antes de alterar as configurações de replicação na etapa abaixo, o código do aplicativo existente esteja usando 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 abaixo). Depois que a estratégia de replicação for alterada, você poderá reverter para o QUORUM, se preferir.

Por fim, use a seguinte consulta CQL 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}

Importante

Se o(s) datacenter(s) em seu cluster existente não impuserem criptografia de cliente para nó (SSL) e você pretender que o código do aplicativo se conecte diretamente à Instância Gerenciada Cassandra, também precisará habilitar o SSL no código do aplicativo.

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

As instruções acima fornecem orientação para configurar um cluster híbrido. No entanto, essa também é uma ótima maneira de alcançar uma migração sem interrupções sem tempo de inatividade. Se você tiver um ambiente local ou outro ambiente Cassandra que deseja encerrar com tempo de inatividade zero, em favor da execução de sua carga de trabalho na Instância Gerenciada do Azure para Apache Cassandra, as seguintes etapas devem ser concluídas nesta ordem:

Configurar cluster híbrido - siga as instruções acima.

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

Na CLI do Azure, execute o comando abaixo para executar nodetool rebuild em cada nó em sua nova Instância Gerenciada do Azure para o data center Apache Cassandra, substituindo <ip address> pelo endereço IP do nó e <sourcedc> pelo nome do seu data center 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>"=""
```
Você deve executar isso somente depois que todas as etapas anteriores tiverem sido executadas. Isso deve garantir que todos os dados históricos sejam replicados para seus novos data centers na Instância Gerenciada do Azure para Apache Cassandra. Você pode executar a reconstrução em um ou mais nós ao mesmo tempo. Execute em um nó de cada vez para reduzir o impacto 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ê só pode executar uma ou duas em paralelo para não sobrecarregar o cluster.
Aviso

Você deve especificar o data center de origem ao executar nodetool rebuildo . Se você fornecer o data center incorretamente na primeira tentativa, isso resultará em intervalos de token sendo copiados, sem que os dados sejam copiados para suas tabelas que não sejam do sistema. As tentativas subsequentes falharão mesmo se você fornecer o data center corretamente. Você pode resolver isso excluindo entradas para cada espaço de chave que não seja do sistema através system.available_ranges da cqlsh ferramenta de consulta no seu data center Cassandra MI de destino:
```
delete from system.available_ranges where keyspace_name = 'myKeyspace';
```
Corte o código do aplicativo para apontar para os nós de propagação em sua nova Instância Gerenciada do Azure para centros de dados Apache Cassandra.

Importante

Como também mencionado nas instruções de configuração híbrida, se o(s) datacenter(s) em seu cluster existente não impuserem criptografia de cliente para nó (SSL), você precisará habilitar isso no código do aplicativo, pois a Cassandra Managed Instance impõe isso.
Execute ALTER KEYSPACE para cada espaço de chaves, da mesma maneira que feito anteriormente, mas agora removendo o(s) seu(s) datacenter(s) antigo(s).
Execute o descomissionamento nodetool para cada nó antigo do data center.
Mude o código do aplicativo de volta para o quórum (se necessário/preferido).

Reative os reparos automáticos:

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

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)

Se você não quiser continuar a usar esse cluster de instância gerenciada, exclua-o com as seguintes etapas:

No menu à esquerda do portal do Azure, selecione Grupos de recursos.
Na lista, selecione o grupo de recursos que você criou para este início rápido.
No painel Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
Na janela seguinte, introduza o nome do grupo de recursos a eliminar e, em seguida, selecione Eliminar.

Próximos passos

Neste início rápido, você aprendeu como criar um cluster híbrido usando a CLI do Azure e a Instância Gerenciada do Azure para Apache Cassandra. Agora você pode começar a trabalhar com o cluster.

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

Share via