Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
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 créer un cluster avec Azure Managed Instance pour Apache Cassandra. Il montre également comment créer un centre de données et augmenter ou diminuer les nœuds dans le centre de données.
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.
- 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.
- Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Important
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.
Créer un cluster d’instances managées
Connectez-vous au portail Azure.
Définissez votre ID d’abonnement dans Azure CLI :
az account set --subscription <Subscription_ID>Créez un réseau virtuel avec un sous-réseau dédié dans votre groupe de ressources :
az network vnet create --name <VNet_Name> --location eastus2 \ --resource-group <Resource_Group_Name> --subnet-name <Subnet Name>Le déploiement d’une instance 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 dans votre réseau virtuel aux services Azure suivants requis pour qu’Azure Managed Instance pour Apache Cassandra fonctionne correctement :
- Stockage Azure
- Azure Key Vault
- Ensembles de mise à l’échelle de machines virtuelles Azure
- Azure Monitor
- Microsoft Entra ID (système d'identification de Microsoft)
- Microsoft Defender pour le cloud
Appliquez ces autorisations spécifiques au réseau virtuel. L’instance managée les requiert. Utilisez la
az role assignment createcommande, puis 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
assigneevaleurs etrolevaleurs sont des valeurs fixes. Entrez ces valeurs exactement comme indiqué dans la commande. Si vous ne le faites pas, cela entraîne des erreurs lorsque vous créez le cluster. Si vous rencontrez des erreurs lors de l’exécution de cette commande, vous n’avez peut-être pas les autorisations nécessaires pour l’exécuter. Contactez votre administrateur Azure pour obtenir des autorisations.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 avec la valeur de la
delegatedManagementSubnetIdvariable. (La valeurdelegatedManagementSubnetIdest le même nom de réseau virtuel pour lequel les autorisations ont été appliquées.)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='5.0' # 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 \ --debugCréez un centre de données pour le cluster avec trois machines virtuelles. Utilisez la configuration suivante :
- Taille de machine virtuelle : Standard E8s v5
- Disques de données : 4 disques P30 attachés à chacune des machines virtuelles déployées
Une fois toutes les informations en place, utilisez 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 falseChoisissez la valeur pour
--skuparmi les tailles de machine virtuelle disponibles suivantes :- Standard_E8s_v5
- Standard_E16s_v5
- Standard_E20s_v5
- Standard_E32s_v5
Par défaut,
--availability-zoneest définie surfalse. Pour activer les zones de disponibilité, définissez-la surtrue. Les zones de disponibilité aident à augmenter la disponibilité du service. Pour plus d’informations, consultez les Contrats de niveau de service pour les services en ligne.Les zones de disponibilité ne sont pas prises en charge dans toutes les régions Azure. 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 soumis à la disponibilité des ressources de calcul dans toutes les zones de la région que vous avez sélectionnée. Les déploiements échouent si la taille de machine virtuelle que vous avez choisie n’est pas disponible dans la région que vous avez sélectionnée.
Une fois le centre de données créé, vous pouvez exécuter la commande az managed-cassandra datacenter update pour effectuer un scale-down ou un scale-up de votre cluster. Remplacez la valeur du
node-countparamètre 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 à l’intérieur du même réseau virtuel. Cette ressource peut être une application ou une machine virtuelle avec Cassandra Query Language Shell (CQLSH) installée. CQLSH est un outil de requête open source Apache.
Vous pouvez utiliser un modèle Azure Resource Manager pour déployer une machine virtuelle Ubuntu.
En raison de certains problèmes connus liés aux versions de Python, nous vous recommandons d’utiliser une image Ubuntu 22.04 fournie avec Python3.10.12 ou un environnement virtuel Python pour exécuter CQLSH.
Se connecter à partir de CQLSH
Une fois la machine virtuelle déployée, utilisez Secure Shell pour vous connecter à la machine et installer CQLSH. Utilisez les commandes suivantes :
# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre
Vérifiez quelles versions de Cassandra sont toujours prises en charge et sélectionnez la version dont vous avez besoin. Nous vous recommandons d’utiliser une version stable.
Installez les bibliothèques Cassandra pour obtenir CQLSH. Suivez les étapes officielles de la documentation Cassandra.
Se connecter à partir d’une application
Comme avec CQLSH, lorsque vous utilisez l’un des pilotes clients Apache Cassandra pris en charge pour vous connecter à partir d’une application, le chiffrement TLS/SSL (Transport Layer Security/Secure Sockets Layer) doit être activé et la vérification des certificats doit être désactivée. Pour obtenir des exemples, consultez Java, .NET, Node.jset Python.
Nous vous recommandons de désactiver la vérification des certificats, car elle ne fonctionne pas, sauf si vous mappez des adresses IP de vos nœuds de cluster au domaine approprié. Si une stratégie interne vous oblige à effectuer la vérification des certificats TLS/SSL pour n’importe quelle application, ajoutez des entrées comme 10.0.1.5 host1.managedcassandra.cosmos.azure.com dans votre fichier hosts pour chaque nœud afin de faciliter cette configuration. Si vous adoptez cette approche, vous devez également ajouter de nouvelles entrées chaque fois que vous augmentez la capacité des nœuds.
Pour Java, nous vous recommandons d’activer la stratégie d’exécution spéculative où les applications sont sensibles à la latence de fin. Pour une démonstration illustrant le fonctionnement de cette approche et pour voir comment activer la stratégie, consultez Implémenter une stratégie d’exécution spéculative.
Vous n’avez généralement pas besoin de configurer des certificats (tels que rootCA, , nodeclientou truststore) pour vous connecter à Azure Managed Instance pour Apache Cassandra. Le chiffrement TLS/SSL utilise le magasin d’approbations par défaut et le mot de passe d’exécution choisi par le client. Pour obtenir un exemple de code, consultez Java, .NET, Node.jset Python). Les certificats sont approuvés par défaut. Si ce n’est pas le cas, ajoutez-les dans le magasin de confiance.
Configurer des certificats clients (facultatif)
La configuration des certificats clients est facultative. Une application cliente peut se connecter à Azure Managed Instance pour Apache Cassandra après avoir suivi les étapes précédentes. 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 : Certificats privés et publics sans autorité de certification pour chaque nœud. Dans ce cas, tous les certificats publics sont requis.
- Certificats signés par une autorité de certification : Certificats émis par une autorité de certification auto-signée ou une autorité de certification publique. Pour cette configuration, vous avez 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éparer des certificats SSL pour la production.
Pour implémenter l’authentification par certificat client à nœud ou la sécurité mutuelle de la couche transport, fournissez les certificats à l’aide d’Azure CLI. La commande suivante charge et applique vos certificats clients au magasin d’approbations de 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 pendant les connexions clientes. Pour plus d’informations, consultez require_client_auth: true cassandra client_encryption_options.
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 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 l’utilisateur ou le 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
Lorsque votre ressource n’est plus nécessaire, utilisez la az group delete commande pour supprimer le groupe de ressources, l’instance managée et toutes les ressources associées :
az group delete --name <Resource_Group_Name>
Étape suivante
Dans ce guide de démarrage rapide, vous avez appris à créer un cluster Azure Managed Instance pour Apache Cassandra à l’aide d’Azure CLI. Vous pouvez maintenant commencer à utiliser le cluster :