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

Artigo
08/18/2024

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 os comandos da CLI do Azure para configurar um cluster híbrido. Se tiver datacenters existentes em um ambiente local ou auto-hospedado, você 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, confira Início Rápido para Bash no Azure Cloud Shell.
Se preferir executar os comandos de referência da CLI localmente, instale a CLI do Azure. Para execuções no Windows ou no macOS, considere executar a CLI do Azure em um contêiner do Docker. Para obter mais informações, confira Como executar a CLI do Azure em um contêiner do Docker.
- Se estiver usando uma instalação local, entre com a CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga as etapas exibidas no terminal. Para ver outras opções de entrada, confira Conectar-se com a CLI do Azure.
- Quando solicitado, instale a extensão da CLI do Azure no primeiro uso. Para obter mais informações sobre extensões, confira Usar extensões com a CLI do Azure.
- Execute az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para fazer a atualização para a versão mais recente, execute az upgrade.

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.
Rede Virtual do Azure com conectividade com o ambiente local ou auto-hospedado. Para saber mais sobre como conectar ambientes locais ao Azure, confira o artigo Conectar uma rede local ao Azure.

Configurar um cluster híbrido

Entre no portal do Azure e navegue até recurso de Rede Virtual.
Abra a guia Sub-redes e crie uma sub-rede. Para saber mais sobre os campos no formulário Adicionar sub-rede, confira o artigo sobre a Rede Virtual:
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 na sua VNet aos serviços essenciais do Azure a seguir que são necessários para que o Cassandra Gerenciado funcione corretamente. Encontre também uma lista extensa de endereços IP e dependências de porta aqui.
- 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
Agora, aplicaremos algumas permissões especiais à VNet e à sub-rede, exigidas pela Instância Gerenciada do Cassandra, usando a CLI do Azure. 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 assignee e role no comando anterior são identificadores de função e de princípio de serviço fixos, respectivamente.
Em seguida, configuraremos os 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. Use o nome do cluster existente ao definir as variáveis clusterName e clusterNameOverride no script a seguir.

No mínimo, você também precisará dos nós semente do datacenter existente e dos certificados gossip necessários para a criptografia de nó para 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ê não tiver a criptografia de nó para nó implementada no cluster existente, precisará implementá-la. Confira a documentação aqui. Você deve fornecer o caminho para a localização dos certificados. Cada certificado deve estar no formato PEM, por exemplo, -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Em geral, há duas maneiras de implementar os certificados:
1. 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.
2. 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).
Opcionalmente, se você também quiser implementar a autenticação do certificado do cliente para nó ou o protocolo TLS mútuo (MTLs), você precisará fornecer os certificados no mesmo formato de quando criou o cluster híbrido. Consulte o exemplo de CLI do Azure abaixo; os certificados são fornecidos no parâmetro --client-certificates. Isso 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). Depois de aplicado, seu cluster exigirá que o Cassandra verifique os certificados quando um cliente se conectar (consulte require_client_auth: true em client_encryption_options do Cassandra).

Observação

O valor da variável delegatedManagementSubnetId que você fornecerá abaixo é exatamente o mesmo que o valor --scope fornecido 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
```
Observação

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

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 \

O comando anterior retorna informações sobre o ambiente da instância gerenciada. Você precisará dos certificados gossip para que possa instalá-los no repositório confiável dos nós no datacenter existente. A seguinte captura de tela mostra a saída do comando anterior e o formato dos certificados:

Observação

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 repositório confiável do datacenter existente.
Dica

Copie o valor da matriz gossipCertificates mostrado na captura de tela acima para um arquivo e use o script do Bash a seguir (você precisará baixar e instalar o jq para sua plataforma) a fim de 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 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
```
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.

Agora que o datacenter foi criado, execute o comando de mostrar o 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. Além disso, instale os certificados gossip da instância gerenciada que você coletou anteriormente no repositório confiável de cada nó no cluster existente usando o comando keytool para cada certificado:
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Observação

Se quiser adicionar mais datacenters, você poderá repetir as etapas acima, mas só precisará dos nós semente.

Importante

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

Importante

Se o código do aplicativo existente estiver usando QUORUM para consistência, você deverá 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 dinâmicas 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 QUORUM, se preferir.

Por fim, use a seguinte consulta CQL para atualizar a estratégia de replicação em cada keyspace para incluir todos os datacenters do 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 os data centers no cluster existente não impuserem a SSL (criptografia de cliente para nó) e você desejar que o código do aplicativo se conecte diretamente à Instância Gerenciada do Cassandra, você 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 diretrizes para configurar um cluster híbrido. No entanto, essa também é uma ótima maneira de alcançar uma migração perfeita de tempo de inatividade zero. Se você tiver um ambiente local ou outro Cassandra que deseje encerrar com tempo de inatividade zero, em favor da execução da carga de trabalho na Instância Gerenciada do Azure para Apache Cassandra, as seguintes etapas deverão ser concluídas nesta ordem:

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

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

Na CLI do Azure, execute o comando abaixo para executar nodetool rebuild em cada nó no novo datacenter da Instância Gerenciada do Azure para Apache Cassandra, substituindo <ip address> pelo endereço IP do nó e <sourcedc> pelo nome do data center existente (aquele de onde 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ê deverá 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. É possível executar a recompilação em um ou mais nós ao mesmo tempo. Execute em um nó por vez para reduzir o impacto 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ê só pode executar uma ou duas em paralelo para não sobrecarregar o cluster.
Aviso

É necessário especificar o data center de origem ao executar nodetool rebuild. Se fornecer o data center incorretamente na primeira tentativa, isso resultará na cópia de intervalos de token, sem que os dados sejam copiados para as tabelas que não pertencem ao sistema. As tentativas subsequentes falharão, mesmo se você fornecer o data center corretamente. Isso pode ser resolvido excluindo as entradas de cada keyspace que não pertence ao sistema em system.available_ranges por meio da ferramenta de consulta cqlsh no data center de MI do 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 semente no(s) seu(s) novo(s) data center(s) da Instância Gerenciada do Azure para Apache Cassandra.

Importante

Como também mencionado nas instruções de configuração híbrida, se os data centers em seu cluster existente não impuserem a SSL (criptografia de cliente para nó), você precisará habilitar isso no código do aplicativo, pois a Instância Gerenciada do Cassandra impõe isso.
Execute ALTER KEYSPACE para cada keyspace da mesma maneira como foi feito anteriormente, mas, agora, removendo seus data centers antigos.
Execute nodetool decommision para cada nó antigo do data center.
Alterne o código do aplicativo de volta para quorum (se necessário/preferencial).

Reabilite os 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 à 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

Caso não vá continuar usando esse cluster da instância gerenciada, exclua-o seguindo estas etapas:

No menu à esquerda do portal do Azure, selecione Grupos de recursos.
Na lista, selecione o grupo de recursos criado neste início rápido.
Na página Visão geral do grupo de recursos, selecione Excluir grupo de recursos.
Na próxima janela, insira o nome do grupo de recursos a ser excluído e selecione Excluir.

Próximas etapas

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

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

Compartilhar via