Share via

Guide de démarrage rapide : Créer un cluster Azure Managed Instance pour Apache Cassandra à l’aide d’Azure CLI

  • Article

Azure Managed Instance pour Apache Cassandra est un service complètement managé pour les clusters Apache Cassandra open source purs. 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 vous montre comment utiliser les commandes Azure CLI pour créer un cluster avec Azure Managed Instance pour Apache Cassandra. Il montre également comment créer un centre de données, et comment effectuer un scale-up ou un scale-down dans le centre de données.

Prérequis

Important

Pour cet article, vous avez besoin d’Azure CLI version 2.30.0 ou ultérieure. Si vous utilisez Azure Cloud Shell, la version la plus récente est déjà installée.

Créer un cluster Managed Instance

  1. Connectez-vous au portail Azure

  2. Définissez l’ID de votre abonnement dans Azure CLI :

    az account set -s <Subscription_ID>

  3. Créez ensuite un réseau virtuel avec un sous-réseau dédié dans votre groupe de ressources :

    az network vnet create -n <VNet_Name> -l eastus2 -g <Resource_Group_Name> --subnet-name <Subnet Name>

    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 essentiels qui sont nécessaires au bon fonctionnement de Managed Instance pour Apache Cassandra :

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

  4. Appliquez au réseau virtuel certaines autorisations spéciales qui sont demandées par l’instance managée. 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 des valeurs fixes. Entrez ces valeurs exactement comme indiqué dans la commande. Sinon, cela entraînera des erreurs lors de la création du cluster. Si vous rencontrez des erreurs lors de l’exécution de cette commande, vous ne disposez peut-être pas des autorisations nécessaires pour l’exécuter. Contactez votre administrateur pour obtenir les autorisations.

  5. Ensuite, créez le cluster dans votre réseau virtuel nouvellement créé à l’aide de la commande az managed-cassandra cluster create. Exécutez la commande suivante comme valeur de la variable delegatedManagementSubnetId :

    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='<Resource_Group_Name>'
clusterName='<Cluster_Name>'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/<VNet name>/subnets/<subnet name>'
initialCassandraAdminPassword='myPassword'
cassandraVersion='3.11' # set to 4.0 for a Cassandra 4.0 cluster

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --initial-cassandra-admin-password $initialCassandraAdminPassword \
  --cassandra-version $cassandraVersion \
  --debug

  6. Enfin, créez un centre de connaissances pour le cluster avec trois nœuds (référence SKU de machine virtuelle Standard D8s v4, avec quatre disques P30 attachés pour chaque nœud) en utilisant la commande az managed-cassandra datacenter create :

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

  7. Une fois le centre de données créé, vous pouvez effectuer un scale-up ou un scale-down des nœuds qu’il contientn exécutez la commande az managed-cassandra datacenter update. Remplacez la valeur du paramètre node-count par la valeur souhaitée :

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'
dataCenterName='dc1'
dataCenterLocation='eastus2'

az managed-cassandra datacenter update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --node-count 9

Se connecter au cluster

Azure Managed Instance pour Apache Cassandra ne crée pas de nœuds avec des adresses IP publiques. Pour vous connecter à votre nouveau cluster Cassandra, vous devez créer une autre ressource dans le réseau virtuel. Cette ressource peut être une application ou bien une machine virtuelle sur laquelle CQLSH, l’outil de requête open source d’Apache, est installé. Vous pouvez utiliser un modèle Resource Manager pour déployer une machine virtuelle Ubuntu.

Connexion depuis CQLSH

Après avoir déployé la machine virtuelle, utilisez SSH pour vous y connecter et installez CQLSH comme indiqué dans les commandes suivantes :

# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre

# Install the Cassandra libraries in order to get CQLSH:
echo "deb http://archive.apache.org/dist/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra

# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false

# Connect to CQLSH (replace <IP> with the private IP addresses of a node in your Datacenter):
host=("<IP>")
initial_admin_password="Password provided when creating the cluster"
cqlsh $host 9042 -u cassandra -p $initial_admin_password --ssl

Connexion depuis une application

Comme pour CQLSH, la connexion à partir d’une application en utilisant l’un des pilotes clients Apache Cassandra pris en charge nécessite l’activation du chiffrement SSL et la désactivation de la vérification de certification. Consultez des exemples de connexion à Azure Managed Instance pour Apache Cassandra à l'aide de Java, .NET, Node.js et Python.

La désactivation de la vérification de certificat est recommandée, car elle fonctionne seulement si vous mappez les adresses IP de vos nœuds de cluster au domaine approprié. Si vous avez une stratégie interne qui vous oblige à effectuer la vérification des certificats SSL pour une application, vous pouvez faciliter cette opération en ajoutant des entrées de type 10.0.1.5 host1.managedcassandra.cosmos.azure.com dans votre fichier d’hôte pour chaque nœud. Si vous utilisez cette approche, vous devez également ajouter de nouvelles entrées quand vous effectuez un scale-up des nœuds.

En outre, nous vous recommandons vivement d’activer pour Java une stratégie d’exécution spéculative où des applications sont sensibles à une latence de queue. Vous trouverez une démonstration illustrant comment cela fonctionne et comment activer la stratégie ici.

Notes

Dans la grande majorité des cas, il ne doit pas être nécessaire de configurer ou d’installer des certificats (certificat d’autorité de certification, nœud ou client, truststores, etc.) afin de se connecter à Azure Managed Instance pour Apache Cassandra. Le chiffrement SSL peut être activé à l’aide du truststore et du mot de passe par défaut du runtime utilisé par le client (consultez les exemples Java, .NET, Node.js et Python), car des certificats Azure Managed Instance pour Apache Cassandra sont approuvés par cet environnement. Dans de rares cas, si le certificat n’est pas approuvé, il est possible que vous deviez l’ajouter au truststore.

Configuration de certificats clients (facultatif)

La configuration de certificats clients est facultative. Une application cliente pourra se connecter à Azure Managed Instance pour Apache Cassandra aussi longtemps que les étapes ci-dessus auront été effectuées. Le cas échéant, si vous préférez, vous pouvez également créer et configurer des certificats clients pour l’authentification. En général, il existe deux façons de créer des certificats :

  • 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.
  • 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 souhaitez implémenter l’authentification par certificat client à nœud ou mTLS (mutual Transport Layer Security), vous devez fournir les certificats via Azure CLI. La commande ci-dessous charge et applique vos certificats clients au 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).

resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --client-certificates /usr/csuser/clouddrive/rootCert.pem /usr/csuser/clouddrive/intermediateCert.pem

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 n’avez plus besoin du groupe de ressources, de l’instance managée ni d’aucune des ressources associées, vous pouvez les supprimer avec la commande az group delete :

az group delete --name <Resource_Group_Name>

Étapes suivantes

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

Déployer un cluster Apache Spark managé avec Azure Databricks