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

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

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.
- Quand vous y êtes invité, installez l’extension Azure CLI à 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.

Cet article nécessite 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.
Utilisez un réseau virtuel Azure avec une connectivité à votre environnement auto-hé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.
Sélectionnez l’onglet Sous-réseaux et créez un sous-réseau. Pour en savoir plus sur les champs du formulaire Ajouter un sous-réseau , consultez Ajouter un sous-réseau.

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é. Assurez-vous 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 qu’Azure Managed Instance pour Apache 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 Key Vault
- Groupes de machines virtuelles identiques Azure
- Azure Monitor
- Microsoft Entra ID (système d'identification de Microsoft)
- Microsoft Defender pour le cloud
Appliquez certaines autorisations spéciales au réseau virtuel et au sous-réseau, dont Azure Managed Instance pour Apache Cassandra nécessite, à l’aide d’Azure CLI. Utilisez la commande az role assignment create. Remplacez <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>
```
Les valeurs assignee et role de la commande précédente sont des identificateurs fixes de principal de service et de rôle, respectivement.
Configurez des ressources pour votre 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. Utilisez le nom de votre cluster existant lorsque vous définissez clusterName et clusterNameOverride variables dans le script suivant.

Vous avez également besoin, au minimum, des nœuds de départ 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, vous devez l’implémenter. 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 (Privacy Enhanced Mail), 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. Certificats privés et publics 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. Certificats émis par une autorité de certification auto-signée ou une autorité de certification publique. Dans ce cas, vous avez besoin du certificat racine d’autorité de certification et de tous les certificats intermédiaires, le cas échéant. Pour plus d’informations, consultez Préparer les certificats SSL (Secure Sockets Layer) pour la production.
Si vous souhaitez implémenter l’authentification par certificat client à nœud ou TLS (Transport Layer Security), fournissez les certificats au même format que lorsque vous avez créé le 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 d’approbations pour votre cluster Azure Managed Instance pour Apache Cassandra. Vous n’avez pas besoin de modifier les paramètres cassandra.yaml. Une fois les certificats appliqués, le cluster nécessite Cassandra pour vérifier les certificats lorsqu’un client se connecte. Pour plus d’informations, consultez require_client_auth: true cassandra client_encryption_options.

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 précédente :
```
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
```
Si votre cluster dispose déjà d’un système de chiffrement de nœud à nœud et de client à nœud, vous devez savoir où sont conservés les certificats TLS/SSL ou gossip existants de vos clients. Si vous n’êtes pas sûr, exécutez-le 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.

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. Copiez chaque certificat dans un fichier et mettez-le en forme avant de tenter de l’importer dans votre magasin d’approbations existant.

Copiez la gossipCertificates valeur du tableau affichée dans la capture d’écran dans un fichier. 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
```
Choisissez la valeur pour --sku parmi les paliers de produit disponibles suivants :
- 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 de niveau de service de disponibilité (SLA) du service. Pour plus d’informations, consultez contrat SLA pour les services en ligne.

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.

Le déploiement réussi des zones de disponibilité est également soumis à la disponibilité des ressources de calcul dans toutes les zones de la région spécifique. Les déploiements peuvent échouer si le niveau de produit que vous avez sélectionné, ou la capacité, n’est pas disponible dans toutes les zones.

Maintenant que le nouveau centre de données est créé, exécutez la datacenter show commande pour afficher ses détails :

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 d’instance gérée que vous avez collectés précédemment dans le magasin de confiance pour chaque nœud de votre cluster existant. Utilisez la keytool commande pour chaque certificat :
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Si vous souhaitez ajouter d’autres centres de données, répétez 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.

Si votre code d’application existant utilise pour la cohérence, assurez-vous qu’avant de modifier les paramètres de réplication à l’étape suivante, votre code d’application existant utiliseLOCAL_QUORUM pour se connecter à votre cluster existant.QUORUM 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 à QUORUM si vous préférez.
Enfin, utilisez la requête Cassandra Query Language suivante pour mettre à jour la stratégie de réplication dans chaque espace de clés afin d’inclure tous les centres de données du 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}
```
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 de vous connecter directement à Azure Managed Instance pour Apache Cassandra, vous devez également activer TLS/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 sur 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 vous montre comment migrer un environnement Local ou autre Cassandra que vous souhaitez désactiver, sans temps d’arrêt, vers Azure Managed Instance pour Apache Cassandra.

Configurez 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 l'Azure CLI, utilisez la commande suivante pour exécuter nodetool rebuild sur chaque nœud de votre nouveau centre de données Azure Managed Instance pour Apache Cassandra. Remplacez <ip address> par l’adresse IP du nœud. Remplacez <sourcedc> par le nom de votre centre de données existant, celui à partir duquel vous migrez :
```
az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
```
Exécutez cette commande uniquement après avoir effectué toutes les étapes précédentes. Cette approche doit s’assurer que toutes les données historiques sont répliquées dans vos nouveaux centres de données dans Azure Managed Instance pour Apache Cassandra. Vous pouvez exécuter rebuild sur un ou plusieurs nœuds en même temps. Exécutez sur un nœud à la fois pour réduire l’effet 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 afin de ne pas surcharger le cluster.
Avertissement

Vous devez spécifier la source data center 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. Pour résoudre ce problème, supprimez les entrées de chaque espace de clé non système dans system.available_ranges en utilisant l’outil de requête cqlsh dans votre centre de données Apache Cassandra cible géré par Azure :
```
delete from system.available_ranges where keyspace_name = 'myKeyspace';
```
Coupez le code de votre application pour qu’il pointe vers les nœuds de départ dans vos nouveaux centres de données Azure Managed Instance pour Apache Cassandra.

Comme indiqué dans les instructions d’installation hybride, si les centres de données de votre cluster existant n’appliquent pas le chiffrement client à nœud (SSL), activez cette fonctionnalité dans le code de votre application. Azure Managed Instance pour Apache Cassandra applique cette exigence.
Exécutez ALTER KEYSPACE pour chaque keyspace de la même manière que précédemment. Vous pouvez maintenant supprimer vos anciens centres de données.
Exécutez node tool decommission pour chaque ancien nœud de centre de données.
Revenez à la version d'origine de votre code d'application QUORUM, si nécessaire ou préféré.

Réactiver 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. Par exemple, une telle erreur est « Impossible de trouver un utilisateur ou un principal de service dans la base de données graphe pour e5007d2c-4b13-4a74-9b6a-605d99f03501». Pour plus d’informations, consultez Utiliser le portail Azure pour ajouter un principal de service Azure Cosmos DB.

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

Nettoyer les ressources

Si vous ne souhaitez pas continuer à utiliser ce cluster d’instances managées, procédez comme suit pour le supprimer :

Dans le menu de gauche du portail Azure, sélectionnez Groupes de ressources.
Dans la liste, sélectionnez le groupe de ressources que vous avez 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 le volet suivant, 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

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-07-24