Démarrage rapide : créer un cluster Azure Managed Instance pour Apache Cassandra à partir du portail Azure

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, ce qui permet une flexibilité et un contrôle maximum, le cas échéant.

Ce démarrage rapide montre comment utiliser le portail Azure pour créer un cluster Azure Managed Instance pour Apache Cassandra.

Prérequis

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

Créer un cluster d'instances gérées

1. Connectez-vous au portail Azure.

2. Dans la barre de recherche, recherchez Managed Instance pour Apache Cassandra et sélectionnez le résultat.

   

3. Sélectionnez Créer une instance managée pour un cluster Apache Cassandra.

   

4. Dans le volet Créer Managed Instance pour Apache Cassandra, entrez les informations suivantes :

   • Abonnement : dans la liste déroulante, sélectionnez votre abonnement Azure.
   • Groupe de ressources : indiquez si vous souhaitez créer un groupe de ressources ou utiliser un groupe existant. Un groupe de ressources est un conteneur réunissant les ressources associées d’une solution Azure.
   • Nom de cluster : entrez un nom pour votre cluster.
   • Emplacement : emplacement pour déployer le cluster.
   • Version de Cassandra - Version d’Apache Cassandra à déployer.
   • Extension : extensions à ajouter, y compris l’index Lucene Cassandra.
   • Mot de passe d’administrateur Cassandra initial : mot de passe utilisé pour créer le cluster.
   • Confirmer le mot de passe d’administrateur Cassandra : entrez à nouveau votre mot de passe.
   • Réseau virtuel : sélectionnez un réseau virtuel et un sous-réseau sortants, ou créez-en un.
   • Attribuer des rôles : les réseaux virtuels nécessitent des autorisations spéciales pour autoriser le déploiement de clusters Cassandra managés. Conservez cette case à cocher si vous créez un réseau virtuel ou utilisez un réseau virtuel existant sans autorisations appliquées. Si vous utilisez un réseau virtuel où vous avez précédemment déployé des clusters Cassandra Azure SQL Managed Instance, désélectionnez cette option.

   

   Conseil

   Si vous utilisez un VPN, vous n’avez pas besoin d’ouvrir une autre connexion.

   Remarque

   Le déploiement d’une instance managée Azure 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 suivants qui sont nécessaires pour que Managed Cassandra fonctionne correctement. Pour plus d’informations, 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
   • Réplication automatique. Choisissez la forme de la réplication automatique à utiliser. Pour plus d’informations, consultez Réplication clé en main.
   • Planifier une stratégie d’événement. Stratégie utilisée par le cluster pour les événements planifiés.

   Conseil

   • StopANY signifie arrêter tout nœud lorsqu'un événement est programmé pour ce nœud.
   • StopByRack signifie uniquement arrêter le nœud dans un rayon donné pour un événement planifié donné. Par exemple, si plusieurs événements sont planifiés pour les nœuds dans différents racks en même temps, seuls les nœuds d’un seul rack s'arrêtent. D’autres nœuds dans d’autres rayons sont retardés.

5. Sélectionnez ensuite l’onglet Centre de données.

6. Entrez les informations suivantes :

   • Nom du centre de données. Tapez un nom de centre de données dans le champ de texte.
   • Zone de disponibilité Cochez cette case si vous souhaitez que les zones de disponibilité soient activées.
   • Taille du SKU. Choisissez parmi les tailles de référence SKU de machine virtuelle disponibles.

   

   Remarque

   Nous avons introduit la mise en cache en écriture directe (préversion publique) à l’aide de références SKU de machine virtuelle de la série L. Cette implémentation vise à réduire les latences de fin et à améliorer les performances de lecture, en particulier pour les charges de travail gourmandes en lecture. Ces SKU spécifiques sont dotés de disques attachés localement, ce qui garantit une augmentation énorme des IOPS pour les opérations de lecture et une latence résiduelle réduite.

   Important

   La mise en cache en écriture directe est en préversion publique. Cette fonctionnalité est fournie sans contrat de niveau de service. Nous ne la recommandons pas pour les charges de travail de production. Pour plus d’informations, consultez Conditions d’Utilisation Supplémentaires relatives aux Évaluations Microsoft Azure.

   • Non de disques. Choisissez le nombre de disques p30 à attacher à chaque nœud Cassandra.
   • Non de nœuds. Choisissez le nombre de nœuds Cassandra à déployer sur ce centre de données.

   

   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 plus d’informations, 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.

7. Ensuite, sélectionnez Vérifier + créer>.

   Remarque

   La création d’un cluster peut prendre jusqu’à 15 minutes.

   

8. Une fois le déploiement terminé, vérifiez votre groupe de ressources pour voir le cluster d’instance managée nouvellement créé :

   

9. Pour parcourir les nœuds du cluster, accédez à la ressource de cluster et ouvrez le volet Centre de données :

   

Mettre à l’échelle un centre de données

Maintenant que vous avez déployé un cluster avec un centre de données unique, vous pouvez effectuer une mise à l’échelle horizontale ou verticale en mettant en surbrillance le centre de données, puis en sélectionnant le bouton Mettre à l’échelle :

Mise à l’échelle horizontale

Pour augmenter ou réduire le nombre de nœuds, ajustez le curseur jusqu'au nombre souhaité ou modifiez la valeur directement. Lorsque vous avez terminé, sélectionnez Redimensionner.

Mise à l’échelle verticale

Pour effectuer un scale-up ou un scale-down de la taille de la référence SKU pour vos nœuds, sélectionnez une option dans Taille de la référence SKU. Lorsque vous avez terminé, sélectionnez Échelle.

Remarque

La durée nécessaire à une opération de mise à l’échelle dépend de différents facteurs. Cette opération peut prendre quelques minutes. Quand Azure vous avertit que l’opération de mise à l’échelle s’est terminée, cela ne signifie pas que tous vos nœuds ont joint l’anneau Cassandra. Les nœuds sont entièrement mis en service lorsqu'ils affichent tous un état sain et que l'état du centre de données indique réussi.

La mise à l’échelle est une opération en ligne et fonctionne de la même manière que celle décrite pour la mise à jour corrective. Pour plus d’informations, consultez Patching.

Ajouter un centre de données

1. Pour ajouter un autre centre de données, sélectionnez le bouton Ajouter dans le volet Centre de données :

   

   Avertissement

   Si vous ajoutez un centre de données dans une autre région, vous devez sélectionner un autre réseau virtuel. Vous devez également vous assurer que ce réseau virtuel dispose d’une connectivité au réseau virtuel de la région primaire créé précédemment. Vérifiez également que tous les autres réseaux virtuels hébergent des centres de données au sein du cluster d’instance managée. Pour plus d’informations, consultez Connecter des réseaux virtuels avec l’appairage de réseaux virtuels.

   Vous devez également vous assurer que vous avez appliqué le rôle approprié à votre réseau virtuel avant de tenter de déployer un cluster d’instances managées à l’aide de la commande CLI suivante.

   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>
   

2. Renseignez les champs appropriés :

   • Nom du centre de données. Dans la liste déroulante, sélectionnez votre abonnement Azure.
   • Zone de disponibilité Sélectionnez si vous souhaitez que les zones de disponibilité soient activées dans ce centre de données.
   • Emplacement : Emplacement où votre centre de données est déployé.
   • Taille du SKU. Choisissez parmi les tailles de référence SKU de machine virtuelle disponibles.
   • Non de disques. Choisissez le nombre de disques p30 à attacher à chaque nœud Cassandra.
   • Non de nœuds. Choisissez le nombre de nœuds Cassandra à déployer sur ce centre de données.
   • Réseau virtuel. Sélectionnez un réseau virtuel et un sous-réseau sortants.

   

   Avertissement

   Le portail Azure n’autorise pas la création d’un nouveau réseau virtuel lorsque vous ajoutez un centre de données. Vous devez choisir un réseau virtuel existant et vous devez vous assurer qu’il existe une connectivité entre les sous-réseaux cibles où les centres de données sont déployés. Vous devez également appliquer le rôle approprié au réseau virtuel pour autoriser le déploiement, comme décrit précédemment.

3. Lorsque le centre de données est déployé, vous devez être en mesure d’afficher toutes les informations du centre de données dans le volet Centre de données :

   

4. Pour garantir la réplication entre les centres de données, connectez-vous à cqlsh et utilisez la requête CQL 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. Les tables système sont mises à jour automatiquement.

   ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
   

5. Si vous ajoutez un centre de données à un cluster où il y a déjà des données, exécutez-le rebuild pour répliquer les données historiques. Dans Azure CLI, utilisez la commande suivante pour exécuter nodetool rebuild sur chaque nœud du nouveau centre de données. Cette action remplace <new dc ip address> par l’adresse IP du nœud et <olddc> par le nom de votre centre de données existant :

    az managed-cassandra cluster invoke-command \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName \
      --host <new dc ip address> \
      --command-name nodetool --arguments rebuild="" "<olddc>"=""
   

   Avertissement

   Vous ne devez pas autoriser des clients de l’application à écrire dans le nouveau centre de données tant que vous n’avez pas appliqué les modifications de réplication de l’espace de clés. Sinon, la reconstruction ne fonctionne pas et vous devez créer une demande de support pour que notre équipe puisse s’exécuter repair en votre nom.

Mettre à jour la configuration Cassandra

Le service autorise les mises à jour de la configuration YAML Cassandra sur un centre de données à l’aide du portail Azure ou à l’aide de commandes CLI. Pour mettre à jour les paramètres dans le portail :

1. Sous les paramètres, recherchez Cassandra Configuration. Mettez en surbrillance le centre de données dont vous souhaitez modifier la configuration, puis sélectionnez Mettre à jour :

   

2. Dans la fenêtre qui s’ouvre, entrez les noms de champs au format YAML, comme illustré ici. Sélectionnez ensuite mettre à jour.

   

3. Une fois la mise à jour terminée, les valeurs substituées apparaissent dans le Cassandra Configuration volet :

   

   Remarque

   Seules les valeurs de configuration Cassandra substituées sont affichées dans le portail Azure.

   Important

   Vérifiez que les paramètres yaml Cassandra que vous fournissez sont appropriés pour la version de Cassandra que vous avez déployée. Consultez les paramètres de Cassandra v3.11 pour la version v3.11 et les paramètres de Cassandra v4.0 pour la version v4.0. Vous ne pouvez pas mettre à jour les paramètres YAML suivants :

   • nom de cluster
   • fournisseur de graines
   • initial_token
   • autobootstrap
   • client_encryption_options
   • options_de_cryptage_serveur
   • Options de chiffrement de données transparent
   • audit_logging_options
   • authentificateur
   • autorisateur
   • gestionnaire de rôles
   • port de stockage
   • ssl_storage_port
   • native_transport_port
   • native_transport_port_ssl
   • listen_address
   • listen_interface
   • adresse de diffusion
   • hints_directory
   • répertoires_de_fichiers_de_données
   • commitlog_directory
   • cdc_raw_directory
   • répertoire_des_caches_sauvés
   • endpoint_snitch
   • partitionneur
   • rpc_address
   • rpc_interface

Mettre à jour la version de Cassandra

Important

Les mises à jour de Cassandra 5.0 et de la version clé en main (Turnkey) sont en préversion publique. Ces fonctionnalités sont fournies sans contrat de niveau de service. Nous déconseillons ces fonctionnalités pour les charges de travail de production. Pour plus d’informations, consultez Conditions d’Utilisation Supplémentaires relatives aux Évaluations Microsoft Azure.

Vous pouvez effectuer des mises à niveau de version majeure sur place directement à partir du portail ou via az CLI, Terraform ou des modèles ARM.

1. Recherchez le Update panneau sous l’onglet Vue d’ensemble.

   

2. Sélectionnez la version de Cassandra dans la liste déroulante.

   Avertissement

   Ne pas ignorer les versions. Nous vous recommandons de mettre à jour une seule version vers un autre exemple 3.11 vers la version 4.0, 4.0 vers la version 4.1.

   

3. Sélectionnez mettre à jour pour enregistrer.

Réplication clé en main

Cassandra 5.0 introduit une approche simplifiée pour le déploiement de clusters multirégions, qui se révèle être plus pratique et plus efficace. Si vous utilisez la fonctionnalité de réplication clé en main, la configuration et la gestion des clusters multirégions deviennent plus accessibles, ce qui permet une intégration et une opération plus fluides dans les environnements distribués.

Cette mise à jour réduit considérablement les complexités associées au déploiement et à la maintenance de plusieurs configurations de région, ce qui permet aux utilisateurs d’utiliser les fonctionnalités de Cassandra avec plus de facilité et d’efficacité.

Conseil

• None : La réplication automatique est définie sur None.
• SystemKeyspaces : répliquer automatiquement tous les espaces de clés système (system_auth, system_traces, system_auth).
• AllKeyspaces : réplicez automatiquement tous les espaces de clés et surveillez si de nouveaux espaces de clés sont créés, puis appliquez automatiquement les paramètres de réplication automatique.

Scénarios de réplication automatique

• Lorsque vous ajoutez un nouveau centre de données, la fonctionnalité de réplication automatique dans Cassandra s’exécute nodetool rebuild en toute transparence pour garantir la réussite de la réplication des données dans le centre de données ajouté.
• Supprimer un centre de données entraîne automatiquement sa suppression des keyspaces.

Pour les centres de données externes, tels que ceux hébergés sur site, il est possible de les inclure dans les espaces de clés grâce à la propriété du centre de données externe. Cette approche permet à Cassandra d’incorporer ces centres de données externes en tant que sources pour le processus de reconstruction.

Avertissement

La définition de la réplication automatique sur AllKeyspaces modifie la réplication des espaces de clés pour inclure :

WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }

Si cette topologie n’est pas ce que vous voulez, utilisez SystemKeyspaces, ajustez-les vous-même et exécutez-les nodetool rebuild manuellement sur le cluster Azure Managed Instance pour Apache Cassandra.

Libérer un cluster

Pour les environnements hors production, vous pouvez suspendre ou libérer des ressources dans le cluster afin d’éviter d’être facturé pour eux. Vous continuez à être facturé pour le stockage. Remplacez d’abord le type de cluster par NonProduction, puis deallocate.

Conseil

Le type de cluster doit être utilisé comme « Non production » uniquement pour économiser les coûts de développement. Ils peuvent être fournis avec des références SKU plus petites et ne doivent pas être utilisés pour exécuter des charges de travail de production.

Avertissement

• Le type de cluster défini comme « Non-production » n’a pas de garanties SLA appliquées à celui-ci.
• N’exécutez pas de schéma ni d’opérations d’écriture pendant la désallocation. Cette action peut entraîner une perte de données et, dans de rares cas, une altération du schéma nécessitant une intervention manuelle de l’équipe de support technique.

Dépannage

Si vous rencontrez une erreur lors de l’application d’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 l’utilisateur ou le principal de service dans la base de données de 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.

Remarque

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.

Connexion à votre cluster

Azure Managed Instance pour Apache Cassandra ne crée pas de nœuds avec des adresses IP publiques. Pour vous connecter à votre cluster Cassandra nouvellement créé, créez une autre ressource à l’intérieur du réseau virtuel. Cette ressource peut être une application ou une machine virtuelle avec l’outil de requête open source DQLSH d’Apache installé. Vous pouvez utiliser un modèle pour déployer une machine virtuelle Ubuntu.

Connexion depuis CQLSH

Une fois la machine virtuelle déployée, utilisez SSH pour vous y connecter et installez CQLSH en utilisant les commandes ci-dessous :

# 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 les exemples de connexion à Azure Managed Instance pour Apache Cassandra à l’aide de Java, .NET, Node.jset Python.

Nous vous recommandons de désactiver la vérification des certificats, car la vérification des certificats ne fonctionne pas, sauf si vous mappez des adresses IP de vos nœuds de cluster au domaine approprié. Si vous disposez d’une stratégie interne qui vous oblige à effectuer la vérification des certificats SSL pour n’importe quelle application, vous pouvez faciliter cette configuration en ajoutant des entrées comme 10.0.1.5 host1.managedcassandra.cosmos.azure.com dans votre fichier hosts pour chaque nœud. Si vous adoptez cette approche, vous devez également ajouter de nouvelles entrées chaque fois que vous augmentez l'échelle 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. Pour une démonstration qui illustre le fonctionnement de cette approche, consultez Démo : implémentation d'une exécution spéculative et découvrez comment activer la stratégie.

Remarque

Dans la plupart des cas, il ne doit pas être nécessaire de configurer ou d’installer des certificats (tels que rootCA, node ou client, truststores) pour se connecter à Azure Managed Instance pour Apache Cassandra. Le chiffrement SSL peut être activé à l’aide du magasin de confiance et du mot de passe par défaut du runtime utilisé par le client, car les certificats Azure Managed Instance pour Apache Cassandra sont approuvés par cet environnement. Dans de rares cas, si le certificat n’est pas approuvé, vous devrez peut-être l’ajouter au truststore. Consultez Java, .NET, Node.jset Python.

Configuration de certificats clients (facultatif)

La configuration des certificats clients est facultative. Une application cliente peut se connecter à Azure Managed Instance pour Apache Cassandra tant que les étapes précédentes sont terminées. Toutefois, 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. 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, vous avez besoin du certificat d’autorité de certification racine et de tous les intermédiaires (le cas échéant). Pour plus d’informations, consultez Préparation des certificats SSL pour la production.

Si vous souhaitez implémenter l’authentification par certificat client à nœud ou mTLS (Transport Layer Security), fournissez les certificats à l’aide d’Azure CLI. La commande suivante charge et applique vos certificats clients au magasin de confiance pour le cluster d’instances managées. Vous n’avez pas besoin de modifier les paramètres cassandra.yaml. Après avoir appliqué la commande, votre cluster nécessite Cassandra pour vérifier les certificats lorsqu’un client se connecte. Voir require_client_auth: true dans 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

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.

Étape suivante

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