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, pour une flexibilité et un contrôle maximum.

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 une instance managée pour Apache Cassandra , entrez les informations suivantes :

   • Abonnement : dans la liste déroulante, sélectionnez votre abonnement Azure.

   • Groupe de ressources : spécifiez si vous souhaitez créer un groupe de ressources ou utiliser un groupe de ressources existant. Un groupe de ressources est un conteneur réunissant les ressources associées d’une solution Azure.

   • Nom du cluster : entrez un nom pour votre cluster.

   • Emplacement : sélectionnez l’emplacement pour déployer le cluster.

   • Version de Cassandra : sélectionnez la version d’Apache Cassandra à déployer.

   • Extension : sélectionnez des extensions à ajouter, y compris l’index Lucene Cassandra. Cela s’applique uniquement à Cassandra v3.11.

   • Mot de passe d’administrateur Cassandra initial : entrez le mot de passe utilisé pour créer le cluster.

   • Confirmez le mot de passe de l’administrateur Cassandra : réentez votre mot de passe.

   • Réseau virtuel : sélectionnez un réseau virtuel et un sous-réseau existants, ou créez-en un. Prenez note des règles de réseau. Vous pouvez également utiliser la configuration basée sur VPN.

   • Attribuer des rôles : les réseaux virtuels nécessitent des autorisations spéciales pour permettre le déploiement de clusters Cassandra managés. Conservez cette case sélectionnée 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ésactivez cette option.

     

   Si vous utilisez un réseau privé virtuel, vous n’avez pas besoin d’ouvrir une autre connexion.

   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 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 Key Vault

   • Groupes de machines virtuelles identiques Azure

   • Azure Monitor

   • Microsoft Entra ID (système d'identification de Microsoft)

   • Microsoft Defender pour le cloud

   • Réplication automatique : choisissez la forme de 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 n’importe quel nœud lorsqu’il existe un événement planifié pour le nœud.
   • StopByRack signifie interrompre les nœuds uniquement dans un rack spécifique lors d'un événement programmé particulier. Par exemple, si plusieurs événements sont programmés pour des nœuds dans différents racks en même temps, les nœuds d'un seul rack s'arrêtent. D’autres nœuds dans d’autres rayons sont retardés.

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

6. Entrez les informations suivantes :

   • Nom du centre de données : entrez un nom de centre de données dans le champ de texte.

   • Zone de disponibilité : cochez cette case si vous souhaitez activer les zones de disponibilité.

   • Taille de la référence SKU : choisissez parmi les tailles de niveau produit de la machine virtuelle disponible.

     

   Nous avons introduit la mise en cache en écriture directe (préversion publique) à l’aide des niveaux de produit 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 niveaux de produit spécifiques sont équipés de disques attachés localement, ce qui garantit une augmentation des E/S par seconde pour les opérations de lecture et une latence de queue réduite.

   La mise en cache en écriture directe est fournie sans contrat de niveau de service (SLA). 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.

     

   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.

   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.

7. Sélectionnez Vérifier + créer>Créer.

   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

Après avoir déployé un cluster avec un seul centre de données, vous pouvez effectuer une mise à l’échelle horizontalement ou verticalement. Mettez en surbrillance le centre de données, puis sélectionnez Redimensionner.

Mise à l’échelle horizontale

Pour effectuer un scale-out ou un scale-in sur des nœuds, déplacez le curseur vers le nombre souhaité. Vous pouvez également modifier la valeur. Lorsque vous avez terminé, sélectionnez Échelle.

Mise à l’échelle verticale

Pour augmenter ou réduire la taille du niveau de produit pour vos nœuds, sélectionnez des options dans la liste déroulante Taille du SKU. Lorsque vous avez terminé, sélectionnez Échelle.

La durée nécessaire à une opération de mise à l’échelle dépend de différents facteurs. L’opération peut prendre plusieurs minutes. Quand Azure vous avertit que l’opération de mise à l’échelle 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, dans le volet Centre de données , sélectionnez Ajouter.

   

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

   Veillez à appliquer le rôle approprié à votre réseau virtuel avant de tenter de déployer un cluster d’instance managée. Exécutez la commande Azure 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 activer les zones de disponibilité dans ce centre de données.

   • Emplacement : emplacement où votre centre de données est déployé.

   • Taille de la référence SKU : choisissez parmi les tailles de niveau produit 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 existants.

     

   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 à Cassandra Query Language Shell (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 qui a déjà des données, exécutez-le rebuild pour répliquer les données historiques. Dans Azure CLI, utilisez la commande suivante et exécutez 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 remplace <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>"=""
   

N'autorisez pas les clients d'application à écrire dans le nouveau centre de données tant que vous n'avez pas appliqué les modifications de réplication de keyspace. Sinon, la reconstruction ne fonctionne pas et vous devez créer une demande de support afin que notre équipe puisse s’exécuter repair pour vous.

Mettre à jour la configuration Cassandra

Vous pouvez utiliser le portail Azure ou les commandes CLI pour mettre à jour la configuration YAML Cassandra sur un centre de données. Pour mettre à jour les paramètres dans le portail :

1. Sous Paramètres, sélectionnez Configuration Cassandra. 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 s’affichent dans le volet Configuration de Cassandra .

   

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

   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. Pour plus d’informations, consultez [Cassandra v5.0] (https://github.com/apache/cassandra/blob/cassandra-5.0/conf/cassandra.yaml) et Cassandra v4.0 pour v4.0 et Cassandra v3.11 pour les paramètres de Cassandra v3.11. Vous ne pouvez pas mettre à jour les paramètres YAML suivants :

   • cluster_name
   • seed_provider
   • initial_token
   • autobootstrap
   • client_encryption_options
   • server_encryption_options
   • transparent_data_encryption_options
   • audit_logging_options
   • authenticator
   • authorizer
   • role_manager
   • storage_port
   • ssl_storage_port
   • native_transport_port
   • native_transport_port_ssl
   • listen_address
   • listen_interface
   • broadcast_address
   • hints_directory
   • data_file_directories
   • commitlog_directory
   • cdc_raw_directory
   • saved_caches_directory
   • endpoint_snitch
   • partitioner
   • rpc_address
   • rpc_interface

Mettre à jour la version de Cassandra

Les mises à jour de version Cassandra 5.0 et de la version clé en main sont en préversion publique. Ces fonctionnalités sont fournies sans contrat SLA. 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 principales sur place directement à partir du portail ou via les modèles Azure CLI, Terraform ou Azure Resource Manager.

1. Sous l’onglet Vue d’ensemble , sélectionnez Mettre à jour.

   

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

   Ne pas ignorer les versions. Nous vous recommandons de mettre à jour d’une seule version vers une autre. Par exemple, mettez à jour 3.11 vers 4.0, ou 4.0 vers 4.1, ou 4.1 vers 5.0.

   

3. Sélectionnez Mettre à jour pour enregistrer.

Réplication clé en main

Cassandra 5.0 introduit une approche simplifiée pour déployer des clusters multirégions, qui offrent une meilleure commodité et efficacité. Si vous utilisez la fonctionnalité de réplication clé en main, la configuration et la gestion des clusters multirégions sont plus accessibles. Vous bénéficiez d’une intégration et d’une opération plus fluide dans les environnements distribués.

Cette mise à jour réduit les complexités associées au déploiement et à la maintenance de plusieurs configurations de région. Les utilisateurs peuvent utiliser les fonctionnalités de Cassandra avec plus de facilité et d’efficacité.

• Aucun : l’option Réplication automatique est définie sur Aucun.
• Espaces de clés système : réplicez automatiquement tous les espaces de clés système (system_auth, system_traceset system_auth).
• Tous les espaces de clés : réplicez automatiquement tous les espaces de clés, 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é. La suppression d’un centre de données entraîne automatiquement la suppression de ce centre de données dans les keyspaces.

Pour les centres de données externes, tels que ceux hébergés localement, utilisez la propriété de centre de données externe pour les inclure dans les espaces de clés. Cette approche permet à Cassandra d’incorporer ces centres de données externes en tant que sources pour le processus de reconstruction.

Si vous définissez Réplication automatique sur Tous les espaces de clés, la réplication de vos espaces de clés change 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 pour éviter qu’elles ne soient facturées. Vous continuez à être facturé pour le stockage. Tout d’abord, remplacez le type de cluster par NonProduction, puis sélectionnez Libérer.

Utilisez le type de cluster NonProduction uniquement pour économiser des coûts de développement. Ce type de cluster peut être associé à des niveaux de produit plus petits. Ne l’utilisez pas pour exécuter des charges de travail de production.

• Les types de cluster définis comme NonProduction n'ont pas de garanties SLA concernant leur application.
• 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. Dans de rares cas, vous pouvez rencontrer une altération du schéma, ce qui nécessite une intervention manuelle de l’équipe de support technique.

Dépannage

Si vous rencontrez une erreur lorsque vous appliquez des autorisations à votre réseau virtuel lorsque vous utilisez 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.

Se connecter à 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.

Se connecter à partir de CQLSH

Une fois la machine virtuelle déployée, utilisez Secure Shell pour vous connecter à la machine. Pour installer CQLSH, utilisez 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

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 utilisés pour se connecter à Azure Managed Instance pour Apache Cassandra, 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 Démonstration : Implémenter une exécution spéculative.

Dans la plupart des cas, il ne doit pas être nécessaire de configurer ou d’installer des certificats (tels que rootCA, , nodeclientou truststore) pour se connecter à Azure Managed Instance pour Apache Cassandra. Pour activer le chiffrement TLS/SSL, utilisez le magasin de confiance et le mot de passe par défaut de l'environnement d'exécution que le client utilise. Cet environnement approuve les certificats Azure Managed Instance pour Apache Cassandra. Dans de rares cas, si le certificat n’est pas approuvé, vous devrez peut-être l’ajouter au magasin d’approbations. Pour obtenir un exemple de code, consultez Java, .NET, Node.jset Python.

Configurer des certificats clients (facultatif)

La configuration des certificats clients est facultative. Une application cliente peut se connecter à Azure Managed Instance pour Apache Cassandra si les étapes précédentes sont terminées. 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, 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 de l'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.

Si vous souhaitez implémenter l’authentification par certificat client à nœud ou mTLS (Transport Layer Security), utilisez Azure CLI pour fournir les certificats. La commande suivante charge et applique vos certificats clients au magasin d’approbations du 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. 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

Nettoyer les ressources

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

1. Dans le menu de gauche du portail Azure, sélectionnez Groupes de ressources.
2. Dans la liste, sélectionnez le groupe de ressources que vous avez 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 le volet suivant, entrez le nom du groupe de ressources à supprimer, puis sélectionnez Supprimer.

Étape suivante

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