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

  • 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 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 optimaux lorsque cela est nécessaire.

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 Manage Instance

  1. Connectez-vous au portail Azure.

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

    Capture d’écran de recherche d’Azure SQL Managed Instance pour Apache Cassandra.

  3. Sélectionnez le bouton Créer un cluster Managed Instance pour Apache Cassandra.

    Créez le cluster.

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

    • Abonnement : sélectionnez votre abonnement Azure dans la liste déroulante.
    • 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. Pour plus d’informations, consultez l’article de présentation Groupes de ressources Azure.
    • Nom de cluster : entrez un nom pour votre cluster.
    • Emplacement : emplacement où votre cluster sera déployé.
    • Version de Cassandra : Version d’Apache Cassandra qui sera déployée.
    • Extension : extensions qui seront ajoutées, y compris l’Index Cassandra Lucene.
    • 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 existant, ou créez-en un, et un sous-réseau.
    • Affecter des rôles : les réseaux virtuels nécessitent des autorisations spéciales pour permettre le déploiement de clusters Cassandra managés. Laissez cette case cochée si vous créez un réseau virtuel ou si vous utilisez un réseau virtuel existant sans autorisations appliquées. Si vous utilisez un réseau virtuel sur lequel vous avez déjà déployé des clusters Azure SQL Managed Instance Cassandra, désactivez cette option.

    Remplissez le formulaire de création du cluster.

    Conseil

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

    Remarque

    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. Pour plus d’informations, consultez Règles de trafic réseau sortant requises.

    • Stockage Azure
    • Azure KeyVault
    • Groupes de machines virtuelles identiques Azure
    • Surveillance Azure
    • Microsoft Entra ID
    • Sécurité Azure
    • Réplication automatique : Choisissez la forme de réplication automatique à utiliser. En savoir plus
    • Stratégie pour les événements planifiés : Stratégie à utiliser par le cluster pour les événements planifiés.

    Conseil

    • StopANY signifie que tous les nœuds sont arrêtés quand il y a un événement planifié pour les nœuds.
    • StopByRack signifie que seul le nœud dans un rack donné pour un événement planifié donné est arrêté. Par exemple, si plusieurs événements sont planifiés pour les nœuds de différents racks en même temps, seuls les nœuds d’un rack sont arrêtés, tandis que les autres nœuds des autres racks 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 activer les zones de disponibilité.
    • Taille de la référence (SKU) : choisissez une taills de référence SKU de machine virtuelle parmi celles disponibles.

    Capture d’écran de la sélection d’une taille de référence SKU.

    Remarque

    Nous avons introduit la mise en cache double écriture (préversion publique) via les références SKU VM 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 références SKU spécifiques sont dotées de disques attachés localement, ce qui garantit une augmentation considérable des IOPS pour les opérations de lecture et une réduction de la latence de fin.

    Important

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

    • Nombre 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 centres.

    Passer en revue le récapitulatif pour créer le 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. 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. Ensuite, sélectionnez Vérifier + créer>Créer.

    Remarque

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

    Passez en revue le résumé pour créer le cluster.

  8. Une fois le déploiement terminé, vérifiez votre groupe de ressources pour voir le cluster Manage Instance nouvellement créé :

    Page de vue d’ensemble après la création du cluster.

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

    Capture d’écran de nœuds de centre de données.

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

Maintenant que vous avez déployé un cluster avec un unique centre de données, vous pouvez mettre à l’échelle les nœuds horizontalement ou verticalement en mettant en surbrillance le centre de données, puis en sélectionnant le bouton Scale :

Capture d’écran de la mise à l’échelle de nœuds de centre de données.

Mise à l’échelle horizontale

Pour élargir sur les nœuds, déplacez le curseur vers le nombre souhaité ou modifiez simplement la valeur. Quand vous avez terminé, tapez sur Scale.

Capture d’écran de la sélection du nombre de nœuds de centre de données.

Mise à l’échelle verticale

Pour effectuer un scale-up vers une taille de référence SKU plus puissante pour vos nœuds, sélectionnez dans la liste déroulante Sku Size. Quand vous avez terminé, tapez sur Scale.

Capture d’écran de la sélection de la taille de la référence SKU.

Notes

La durée d’une opération de mise à l’échelle dépend de différents facteurs, cela 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 la boucle Cassandra. Les nœuds sont entièrement commandés lorsqu’ils affichent tous l’état « sain » et que l’état du centre de données indique « réussi ».

Ajouter un centre de données

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

    Capture d’écran de l’ajout d’un 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éé ci-dessus (et à tous les autres réseaux virtuels qui hébergent des centres de données au sein du cluster d’instances managées). Consultez cet article pour découvrir comment homologuer des réseaux virtuels à l’aide du Portail Azure. 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 ci-dessous.

        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 : sélectionnez votre abonnement Azure dans la liste déroulante.
    • Zone de disponibilité : cochez cette case si vous souhaitez activer les zones de disponibilité dans ce centre de données.
    • Emplacement : emplacement où votre centre de données sera déployé.
    • Taille de la référence (SKU) : choisissez une taills de référence SKU de machine virtuelle parmi celles 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 centres.
    • Réseau virtuel : sélectionnez un réseau virtuel et un sous-réseau existants.

    Ajouter un centre de données.

    Avertissement

    Notez que nous n’autorisons pas la création d’un nouveau réseau virtuel lors de l’ajout d’un centre de données. Vous devez choisir un réseau virtuel existant et, comme mentionné ci-dessus, vous devez vous assurer qu’il existe une connectivité entre les sous-réseaux cibles où les centres de données seront déployés. Vous devez également appliquer le rôle approprié au réseau virtuel pour autoriser le déploiement (voir ci-dessus).

  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 :

    Affichez les ressources du cluster.

  4. Pour assurer une réplication entre des 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 dans le 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ù des données existent déjà, vous devez exécuter rebuild pour répliquer les données d’historique. 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, en remplaçant <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 fonctionnera pas et vous devrez créer une demande de support pour que notre équipe puisse exécuter repair à votre place.

Mettre à jour la configuration Cassandra

Le service permet d’opérer une mise à jour vers une configuration YAML Cassandra sur un centre de données via le portail en utilisant des 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 cliquez sur Mettre à jour :

    Capture d’écran de la sélection du centre de données pour mettre à jour la configuration.

  2. Dans la fenêtre qui s’ouvre, entrez les noms de champs au format YAML, comme ci-dessous. Cliquez ensuite sur Mettre à jour.

    Capture d’écran de la mise à jour de la configuration Cassandra d’un centre de données.

  3. Une fois la mise à jour terminée, les valeurs remplacées s’affichent dans le volet Cassandra Configuration :

    Capture d’écran de la configuration Cassandra mise à jour.

    Notes

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

    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. Voyez ici les paramètres Cassandra v3.11 et ici les paramètres v4.0. La mise à jour n’est pas autorisée pour les paramètres YAML suivants :

    • nom_cluster
    • 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

Important

Cassandra 4.1, 5.0 et les mises à jour des versions clé en main sont en préversion publique. Ces fonctionnalités étant fournies sans contrat de niveau de service, elles sont déconseillées pour les charges de travail de production. Pour plus d’informations, consultez Conditions d’Utilisation Supplémentaires relatives aux Évaluations Microsoft Azure.

Vous avez la possibilité d’effectuer des mises à niveau de version principale sur place directement du portail ou via l’interface CLI az, Terraform ou les modèles ARM.

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

    Capture d’écran de la mise à jour de la version de Cassandra.

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

    Avertissement

    Ne sautez pas de version. Nous vous recommandons d’effectuer une mise à jour d’une version vers la suivante, par exemple de passer de 3.11 à 4.0 ou de 4.0 à 4.1.

    Capture d’écran de la sélection de la version de Cassandra.

  3. Sélectionnez la mise à jour à 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. Avec la fonctionnalité de réplication clé en main, la configuration et la gestion de clusters multirégions sont devenues plus accessibles, en offrant une intégration et des opérations plus fluides dans les environnements distribués. Cette mise à jour réduit considérablement les complexités habituellement associées au déploiement et à la maintenance de configurations multirégions, ce qui permet aux utilisateurs d’utiliser les fonctionnalités de Cassandra avec plus de facilité et d’efficacité.

Sélectionnez l’option référencée dans la liste déroulante.

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épliquer automatiquement tous les espaces de clés et surveiller si de nouveaux espaces de clés sont créés, puis appliquer automatiquement les paramètres de réplication automatique.

Scénarios de réplication automatique

  • Lors de l’ajout d’un nouveau centre de données, la fonctionnalité de réplication automatique dans Cassandra exécute nodetool rebuild de façon fluide pour garantir une réplication réussie des données dans le centre de données ajouté.
  • La suppression d’un centre de données déclenche une suppression automatique du centre de données en question des espaces de clés.

Les centres de données externes, tels que ceux hébergés localement, peuvent être inclus dans les espaces de clés en utilisant la propriété du centre de données externe. Cela 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 change votre réplication d’espaces de clés à inclure WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Si ce n’est pas la topologie que vous voulez, vous devez utiliser des SystemKeyspaces, les adapter vous-même et exécuter nodetool rebuild manuellement sur le cluster Azure Managed Instance pour Apache Cassandra.

Désallouer un cluster

  1. Pour des environnements hors production, vous pouvez suspendre/désallouer des ressources dans le cluster afin d’éviter d’être facturé pour celles-ci (la facturation de votre stockage se poursuivra). Remplacez d’abord le type de cluster par NonProduction, puis deallocate.

Avertissement

N’exécutez aucun schéma ou aucune opération d’écriture pendant la désallocation, ces exécutions peuvent 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.

Capture d’écran de la suspension d’un cluster.

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.

Connexion à votre cluster

Azure Managed Instance pour Apache Cassandra ne crée pas de nœuds avec des adresses IP publiques. Donc, pour vous connecter à votre cluster Cassandra nouvellement créé, vous devez créer une autre ressource dans le réseau virtuel. Il peut s’agir d’une application ou d’une machine virtuelle sur laquelle CQLSH, l’outil de requête open source d’Apache, est 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 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

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 démarrage rapide, vous avez appris à créer un cluster Azure Managed Instance pour Apache Cassandra à l’aide du portail Azure. Vous pouvez maintenant commencer à utiliser le cluster :

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