Démarrage rapide : Configurer un cluster hybride avec Azure Managed Instance pour Apache Cassandra

2025-06-13

Azure Managed Instance pour Apache Cassandra est un service entièrement managé pour de purs clusters Apache Cassandra open source. Le service permet également aux configurations d’être remplacées, en fonction des besoins spécifiques de chaque charge de travail, ce qui permet une flexibilité et un contrôle maximum, le cas échéant.

Ce guide de démarrage rapide montre comment utiliser les commandes Azure CLI pour configurer un cluster hybride. Si vous disposez de centres de données existants dans un environnement local ou auto-hébergé, vous pouvez utiliser Azure Managed Instance pour Apache Cassandra pour ajouter d’autres centres de données à ces clusters et les gérer.

Prérequis

Utilisez l’environnement Bash dans Azure Cloud Shell. Pour obtenir plus d’informations, consultez Démarrage d’Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
- Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour obtenir d’autres options de connexion, consultez S’authentifier auprès d’Azure à l’aide d’Azure CLI.
- Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser et gérer des extensions avec Azure CLI.
- Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.

Azure CLI version 2.30.0 ou ultérieure. Si vous utilisez Azure Cloud Shell, sachez que la version la plus récente est déjà installée.
Un réseau virtuel Azure connecté à votre environnement autohébergé ou local. Pour plus d’informations sur la connexion d’environnements locaux à Azure, consultez Connecter un réseau local à Azure.

Configurer un cluster hybride

Connectez-vous au portail Azure et accédez à votre ressource de réseau virtuel.
Ouvrez l’onglet Sous-réseaux et créez un sous-réseau. Pour en savoir plus sur les champs du formulaire De sous-réseau ajouté , consultez Ajouter un sous-réseau.
Notes

Le déploiement d’Azure Managed Instance pour Apache Cassandra nécessite un accès Internet. Le déploiement échoue dans les environnements où l’accès à Internet est limité. Vérifiez que vous ne bloquez pas l’accès au sein de votre réseau virtuel aux services Azure essentiels suivants qui sont nécessaires pour que Managed Cassandra fonctionne correctement. Pour obtenir la liste des dépendances d’adresse IP et de port, consultez Règles de réseau sortant requises.
- Stockage Azure
- Azure KeyVault
- Groupes de machines virtuelles identiques Azure
- Surveillance Azure
- Microsoft Entra ID (système d'identification de Microsoft)
- Sécurité Azure
Appliquez certaines autorisations spéciales au réseau virtuel et au sous-réseau requis par Cassandra Managed Instance à l’aide d’Azure CLI. Utilisez la commande az role assignment create, en remplaçant <subscriptionID>, <resourceGroupName> et <vnetName> par les valeurs appropriées :
```
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>
```
Notes

Les valeurs assignee et role de la commande précédente sont respectivement des identificateurs fixes de principal de service et de rôle.
Configurez des ressources pour notre cluster hybride. Étant donné que vous disposez déjà d’un cluster, le nom du cluster est une ressource logique pour identifier le nom de votre cluster existant. Veillez à spécifier le nom du cluster existant quand vous définissez les variables clusterName et clusterNameOverride dans le script suivant.

Vous avez également besoin, au minimum, des nœuds seed de votre centre de données existant et des certificats gossip requis pour le chiffrement de nœud à nœud. Azure Managed Instance pour Apache Cassandra nécessite le chiffrement de nœud à nœud pour la communication entre les centres de données. Si vous n’avez pas de chiffrement de nœud à nœud implémenté dans votre cluster existant, implémentez-le. Pour plus d’informations, consultez chiffrement de nœud à nœud. Indiquez le chemin d’accès à l’emplacement des certificats. Chaque certificat doit être au format PEM, par exemple -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. En général, il existe deux façons d’implémenter des certificats :
- Certificats auto-signés. Un certificat privé et public (sans autorité de certification) pour chaque nœud. Dans ce cas, vous avez besoin de tous les certificats publics.
- Certificats signés par une autorité de certification. Ce certificat peut être une autorité de certification auto-signée ou même une autorité de certification publique. Dans ce cas, nous avons besoin du certificat d'autorité de certification racine et de tous les certificats intermédiaires, le cas échéant. Pour plus d’informations, consultez Préparation des certificats SSL pour la production.
Si vous souhaitez également implémenter l’authentification par certificat client à nœud ou mTLS (Transport Layer Security) mutuelle, fournissez également les certificats au même format que lors de la création du cluster hybride. Consultez l’exemple Azure CLI plus loin dans cet article. Les certificats sont fournis dans le --client-certificates paramètre.

Cette approche charge et applique vos certificats clients au magasin de confiance pour votre cluster d’instances managées Cassandra. Autrement dit, vous n’avez pas besoin de modifier les paramètres cassandra.yaml . Une fois appliqué, votre cluster exige que Cassandra vérifie les certificats lorsqu’un client se connecte. Voir require_client_auth: true dans Cassandra client_encryption_options.

Notes

La valeur de la delegatedManagementSubnetId variable que vous fournissez dans ce code est la même que la valeur de celle que --scope vous avez fournie dans une commande antérieure :
```
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
```
Notes

Si votre cluster a déjà un chiffrement de nœud à nœud et de client à nœud, vous devez savoir où vos certificats SSL client et/ou gossip existants sont conservés. Si vous êtes incertain, exécutez keytool -list -keystore <keystore-path> -rfc -storepass <password> pour imprimer les certificats.

Une fois la ressource cluster créée, exécutez la commande suivante pour afficher les détails de l’installation du cluster :

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

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

La commande ci-dessus retourne des informations sur l’environnement Managed Instance. Vous avez besoin de certificats gossip pour pouvoir installer ces derniers sur le magasin de confiance des nœuds de votre centre de données existant. La capture d’écran suivante montre la sortie de la commande précédente et le format des certificats :

Notes

Les certificats retournés par la commande précédente contiennent des sauts de ligne représentés sous forme de texte, par exemple \r\n. Vous devez copier chaque certificat dans un fichier et le mettre en forme avant de tenter de l’importer dans votre magasin d’approbations existant.
Conseil

Copiez la gossipCertificates valeur de tableau affichée dans la capture d’écran dans un fichier et utilisez le script bash suivant pour mettre en forme les certificats et créer des fichiers pem distincts pour chacun d’eux. Pour télécharger le script Bash, consultez Télécharger jq pour votre plateforme.
```
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
```
Créez maintenant un centre de données dans le cluster hybride. Remplacez les valeurs des variables par les détails de votre 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
```
Notes

Vous pouvez choisir la valeur de --sku parmi les références SKU suivantes disponibles :
- 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
La valeur pour --availability-zone est définie sur false. Pour activer les zones de disponibilité, définissez cette valeur truesur . Les zones de disponibilité augmentent le contrat SLA de disponibilité du service. Pour plus d’informations, consultez le contrat SLA pour les services en ligne.
Avertissement

Les zones de disponibilité ne sont pas prises en charge dans toutes les régions. Les déploiements échouent si vous sélectionnez une région où les zones de disponibilité ne sont pas prises en charge. Pour les régions prises en charge, consultez la liste des régions Azure.

La réussite du déploiement des zones de disponibilité dépend également de la disponibilité des ressources de calcul dans toutes les zones de la région donnée. Les déploiements peuvent échouer si la référence SKU sélectionnée ou la capacité n’est pas disponible dans toutes les zones.

Une fois le centre de données créé, exécutez la commande datacenter show pour voir les détails du centre de données :

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

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

La commande précédente affiche les nœuds de départ du nouveau centre de données :
Ajoutez les nœuds de départ du nouveau centre de données à la configuration de nœud de départ de votre centre de données existant dans le fichier cassandra.yaml . Installez les certificats gossip des instances gérées que vous avez collectés précédemment dans le magasin de confiance pour chaque nœud de votre cluster existant, à l’aide de la commande keytool pour chaque certificat :
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Notes

Si vous souhaitez ajouter d’autres centres de données, vous pouvez répéter les étapes précédentes, mais vous n’avez besoin que des nœuds de départ.

Important

Si votre cluster Apache Cassandra existant n’a qu’un seul centre de données et que ce centre de données est le premier ajouté, vérifiez que le endpoint_snitch paramètre dans cassandra.yaml est défini sur GossipingPropertyFileSnitch.

Important

Si votre code d’application existant utilise QUORUM pour la cohérence, assurez-vous qu’avant de modifier les paramètres de réplication à l’étape suivante, votre code d’application existant utilise LOCAL_QUORUM pour vous connecter à votre cluster existant. Sinon, les mises à jour actives échouent après avoir modifié les paramètres de réplication à l’étape suivante. Après avoir modifié la stratégie de réplication, vous pouvez revenir au quorum si vous le souhaitez.
Pour finir, exécutez la requête CQL suivante pour mettre à jour la stratégie de réplication dans chaque espace de clés et inclure ainsi tous les centres de données dans le cluster :
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
```
Vous devez également mettre à jour plusieurs tables système :
```
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}
```
Important

Si les centres de données de votre cluster existant n’appliquent pas le chiffrement client à nœud (SSL) et que vous avez l’intention que votre code d’application se connecte directement à l’instance managée Cassandra, vous devez également activer SSL dans votre code d’application.

Utiliser un cluster hybride pour la migration en temps réel

Les instructions précédentes fournissent des conseils pour la configuration d’un cluster hybride. Cette approche est également un excellent moyen d’atteindre une migration sans temps d’arrêt fluide. La procédure suivante consiste à migrer un environnement Local ou autre Cassandra que vous souhaitez désactiver sans temps d’arrêt, vers Azure Managed Instance pour Apache Cassandra.

Configurer un cluster hybride. Suivez les instructions précédentes.

Désactivez temporairement les réparations automatiques dans Azure Managed Instance pour Apache Cassandra pendant la migration :

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

Dans Azure CLI, utilisez la commande suivante pour s’exécuter nodetool rebuild sur chaque nœud de votre nouveau centre de données Azure Managed Instance pour Apache Cassandra, en remplaçant <ip address> par l’adresse IP du nœud et <sourcedc> par le nom de votre centre de données existant, celui à partir duquel vous effectuez la migration :
```
az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
```
Vous devez exécuter cette commande uniquement une fois que toutes les étapes précédentes ont été effectuées. Cette approche doit s’assurer que toutes les données historiques sont répliquées vers vos nouveaux centres de données dans Azure Managed Instance pour Apache Cassandra. Vous pouvez exécuter la reconstruction sur un ou plusieurs nœuds en même temps. Exécutez sur un nœud à la fois pour réduire l’impact sur le cluster existant. Exécutez sur plusieurs nœuds lorsque le cluster peut gérer la pression supplémentaire des E/S et du réseau. Pour la plupart des installations, vous ne pouvez exécuter qu’un ou deux en parallèle pour ne pas surcharger le cluster.
Avertissement

Vous devez spécifier le centre de données source lorsque vous exécutez nodetool rebuild. Si vous fournissez le centre de données de manière incorrecte lors de la première tentative, les plages de jetons sont copiées sans que les données soient copiées pour vos tables hors système. Les tentatives suivantes échouent même si vous fournissez le centre de données correctement. Vous pouvez résoudre ce problème en supprimant les entrées pour chaque espace de clés non système dans system.available_ranges en utilisant l’outil de requête cqlsh dans votre centre de données Cassandra MI cible :
```
delete from system.available_ranges where keyspace_name = 'myKeyspace';
```
Basculez le code de votre application pour pointer vers les nœuds seed de vos nouveaux centres de données Azure Managed Instance pour Apache Cassandra.

Important

Comme indiqué dans les instructions d’installation hybrides, si les centres de données de votre cluster existant n’appliquent pas le chiffrement client à nœud (SSL), activez cette fonctionnalité dans votre code d’application, car l’instance managée Cassandra applique cette exigence.
Exécutez ALTER KEYSPACE pour chaque espace de clés de la même manière que précédemment, mais supprimez maintenant vos anciens centres de données.
Exécutez node tool decommission pour chaque ancien nœud du centre de données.
Revenez au quorum de votre code d’application, si nécessaire ou souhaité.

Réactivez les réparations automatiques :

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

Dépannage

Si vous rencontrez une erreur lorsque vous appliquez des autorisations à votre réseau virtuel à l’aide d’Azure CLI, vous pouvez appliquer la même autorisation manuellement à partir du portail Azure. Un exemple de telle erreur est Impossible de trouver un utilisateur ou un principal de service dans la base de données de graphiques pour « e5007d2c-4b13-4a74-9b6a-605d99f03501 ». Pour plus d’informations, consultez Utiliser le portail Azure pour ajouter un principal de service Azure Cosmos DB.

Notes

L’attribution de rôle Azure Cosmos DB est utilisée à des fins de déploiement uniquement. Azure Managed Instance pour Apache Cassandra n’a aucune dépendance back-end sur Azure Cosmos DB.

Nettoyer les ressources

Si vous ne comptez pas continuer à utiliser ce cluster Managed Instance, supprimez-le en effectuant les étapes suivantes :

Dans le menu de gauche du portail Azure, sélectionnez Groupes de ressources.
Dans la liste, sélectionnez le groupe de ressources créé pour ce guide de démarrage rapide.
Dans le volet Vue d’ensemble du groupe de ressources, sélectionnez Supprimer un groupe de ressources.
Dans la fenêtre suivante, entrez le nom du groupe de ressources à supprimer, puis sélectionnez Supprimer.

Étape suivante

Gérer les ressources Azure Managed Instance pour Apache Cassandra à l’aide d’Azure CLI

Partager via