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

  • Article

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

Ce guide de démarrage rapide montre comment utiliser les commandes Azure CLI pour configurer un cluster hybride. Si vous avez déjà des centres de données dans un environnement local ou autohébergé, vous pouvez ajouter d’autres centres de données à ce cluster et gérer tous les clusters avec Azure Managed Instance pour Apache Cassandra.

Prérequis

  • Pour cet article, vous avez besoin d’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 l’article Connecter un réseau local à Azure.

Configurer un cluster hybride

  1. Connectez-vous au portail Azure et accédez à votre ressource de réseau virtuel.

  2. Ouvrez 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 l’article Réseau virtuel :

    Ajouter un sous-réseau à votre réseau virtuel.

    Notes

    Le déploiement d’une instance 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 dans votre réseau virtuel aux services Azure suivants essentiels et nécessaires au bon fonctionnement de Managed Cassandra. Vous pouvez également trouver une liste complète des dépendances de port et d’adresse IPici.

    • Stockage Azure
    • Azure KeyVault
    • Groupes de machines virtuelles identiques Azure
    • Surveillance Azure
    • Microsoft Entra ID
    • Sécurité Azure

  3. À présent, nous allons utiliser Azure CLI pour appliquer certaines autorisations spéciales, qui sont requises par Cassandra Managed Instance, au réseau virtuel et au sous-réseau. 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 dans la commande précédente correspondent aux identificateurs fixes du principal de service et du rôle, respectivement.

  4. Nous allons ensuite configurer des ressources pour le cluster hybride. Dans la mesure où vous avez déjà un cluster, le nom du cluster est ici simplement une ressource logique permettant d’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, vous devez l’implémenter. Consultez la documentation ici. Vous devez fournir 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 :

    1. Certificats auto-signés. Cela signifie qu’il s’agit d’un certificat privé et public (sans autorité de certification) pour chaque nœud. Dans ce cas, nous avons besoin de tous les certificats publics.

    2. Certificats signés par une autorité de certification. Il peut s’agir d’une autorité de certification auto-signée ou même d’une autorité de certification publique. Dans ce cas, nous avons besoin du certificat d’autorité de certification racine (reportez-vous aux instructions sur la préparation des certificats SSL pour la production) et à tous les intermédiaires (le cas échéant).

    Si vous voulez également implémenter l’authentification par certificat client à nœud ou mTLS (Transport Layer Security), vous devez fournir les certificats dans le même format que lors de la création du cluster hybride. Consultez l’exemple Azure CLI ci-dessous : les certificats sont fournis dans le paramètre --client-certificates. Cette opération charge et applique vos certificats clients dans le trustStore pour votre cluster Cassandra Managed Instance (c’est-à-dire que vous n’avez pas besoin de modifier les paramètres cassandra.yaml). Une fois appliqués, votre cluster imposera à Cassandra de vérifier les certificats lors de la connexion d’un client (consultez require_client_auth: true à la page client_encryption_options de la documentation Cassandra).

    Notes

    La valeur de la variable delegatedManagementSubnetId fournie ci-dessous est exactement la même que la valeur de --scope que vous avez fournie dans la commande ci-dessus :

    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

    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 ce n’est pas le cas, essayez d’exécuter keytool -list -keystore <keystore-path> -rfc -storepass <password> pour lister les certificats.

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

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

    Obtenir les détails des certificats à partir du cluster.

    Notes

    Les certificats renvoyés à partir de la commande ci-dessus 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 le magasin de confiance de votre centre de données existant.

    Conseil

    Copiez la valeur de tableau gossipCertificates indiquée dans la capture d’écran ci-dessus dans un fichier, puis utilisez le script bash suivant (vous devez télécharger et installer jq pour votre plateforme) pour formater les certificats et créer des fichiers PEM distincts pour chacun.

    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. Créez maintenant un centre de données dans le cluster hybride. Veillez à remplacer 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

    Vous pouvez également voir que le paramètre --availability-zone est défini sur false. Pour activer les zones de disponibilité, définissez cette valeur sur true. Les zones de disponibilité augmentent le contrat SLA de disponibilité du service. Pour plus d’informations, consultez les détails complets du contrat SLA.

    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. Consultez cette page pour connaître les régions prises en charge. 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 que vous avez sélectionnée, ou capacité, n’est pas disponible dans toutes les zones.

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

  9. La commande précédente retourne les nœuds seed du nouveau centre de données :

    Capture d’écran montrant comment obtenir les détails du centre de données.

  10. Ajoutez maintenant les nouveaux nœuds seed du centre de données à la configuration des nœuds seed de votre centre de données existant dans le fichier cassandra.yaml. Et 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, répétez les étapes ci-dessus, mais uniquement pour les nœuds seed.

    Important

    Si votre cluster Apache Cassandra existant ne possède qu’un seul centre de données et qu’il s’agit de la première fois qu’un centre de données est ajouté, vérifiez que le paramètre endpoint_snitch dans cassandra.yaml a la valeur GossipingPropertyFileSnitch.

    Important

    Si votre code d’application existant utilise QUORUM pour la cohérence, vous devez vous assurer qu’avant de modifier les paramètres de réplication dans l’étape ci-dessous, votre code d’application existant utilise LOCAL_QUORUM pour la connexion à votre cluster existant (sinon les mises à jour automatiques échoueront après la modification de vos paramètres de réplication dans l’étape ci-dessous). Une fois la stratégie de réplication modifiée, vous pouvez revenir au QUORUM si vous le souhaitez.

  11. 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 le ou les centres de données de votre cluster existant n’appliquent pas le chiffrement client à nœud (SSL) et que vous prévoyez que votre code d’application se connecte directement à Cassandra Managed Instance, vous devez également activer SSL dans votre code d’application.

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

Les instructions ci-dessus apportent des conseils pour la configuration d’un cluster hybride. Toutefois, il s’agit également d’un bon moyen de réaliser une migration fluide sans temps d’arrêt. Si vous disposez d’un environnement local ou d’un autre environnement Cassandra que vous souhaitez désactiver sans temps d’arrêt, en faveur de l’exécution de votre charge de travail dans Azure Managed Instance pour Apache Cassandra, les étapes suivantes doivent être effectuées dans cet ordre :

  1. Configurez un cluster hybride (suivre les instructions ci-dessus).

  2. Désactivez temporairement les réparations automatiques dans Azure Managed Instance pour Apache Cassandra pendant la durée de la migration :

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

  3. Dans Azure CLI, exécutez la commande ci-dessous pour 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 ne devez exécuter cette procédure qu’une fois que toutes les étapes ci-dessus ont été effectuées. Cela devrait garantir que toutes les données historiques sont répliquées sur 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 en 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 lors de l’exécution de nodetool rebuild. Si vous fournissez le centre de données de manière incorrecte lors de la première tentative, cela entraîne la copie des plages de jetons, sans que les données soient copiées pour vos tables non-système. Les tentatives suivantes échouent, même si vous fournissez correctement le centre de données. Vous pouvez résoudre ce problème en supprimant des entrées pour chaque espace de clés non-système dans system.available_ranges via l’outil de requête cqlsh de votre centre de données Cassandra MI cible :

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

  4. Basculez le code de votre application pour pointer vers les nœuds seed de votre ou vos nouveaux centres de données Azure Managed Instance pour Apache Cassandra.

    Important

    Comme indiqué également dans les instructions d’installation hybrides, si le ou les centres de données de votre cluster existant n’appliquent pas le chiffrement client à nœud (SSL), vous devez l’activer dans votre code d’application, car Cassandra Managed Instance l’applique.

  5. Exécutez ALTER KEYSPACE pour chaque espace de clés, de la même façon que précédemment, mais cette fois-ci en supprimant votre ou vos anciens centres de données.

  6. Exécutez nodetool decommision pour chaque nœud des anciens centres de données.

  7. Revenez au quorum de votre code d’application (si nécessaire/souhaité).

  8. 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 lors de l’application des autorisations à votre réseau virtuel avec Azure CLI, comme Utilisateur ou principal de service introuvable dans la base de données de graphe pour 'e5007d2c-4b13-4a74-9b6a-605d99f03501' , vous pouvez appliquer la même autorisation manuellement à partir du portail Azure. Découvrez comment procéder ici.

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 :

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

Étapes suivantes

Dans ce guide de démarrage rapide, vous avez appris à créer un cluster hybride en utilisant Azure CLI et Azure Managed Instance pour Apache Cassandra. Vous pouvez maintenant commencer à utiliser le cluster.

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