Schnellstart: Erstellen eines Azure Managed Instance for Apache Cassandra-Clusters im Azure-Portal

Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht auch das Überschreiben von Konfigurationen, je nach den spezifischen Anforderungen der einzelnen Workloads, und bietet so ein Höchstmaß an Flexibilität und Kontrolle, wo dies erforderlich ist.

In dieser Schnellstartanleitung erfahren Sie, wie Sie mithilfe des Azure-Portals eine Azure Managed Instance-Instanz für einen Apache Cassandra-Cluster erstellen.

Voraussetzungen

Wenn Sie kein Azure-Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.

Erstellen eines Managed Instance-Clusters

1. Melden Sie sich beim Azure-Portal an.

2. Suchen Sie in der Suchleiste nach Managed Instance for Apache Cassandra, und wählen Sie das Ergebnis aus.

   

3. Wählen Sie die Schaltfläche Managed Instance for Apache Cassandra-Cluster erstellen aus.

   

4. Geben Sie im Bereich Managed Instance for Apache Cassandra-Cluster erstellen folgende Details ein:

   • Wählen Sie in der Dropdownliste unter Abonnement Ihr Azure-Abonnement aus.
   • Geben Sie für Ressourcengruppe an, ob Sie eine neue Ressourcengruppe erstellen oder eine vorhandene verwenden möchten. Eine Ressourcengruppe ist ein Container, der verwandte Ressourcen für eine Azure-Lösung enthält. Weitere Informationen finden Sie im Übersichtsartikel Was ist Azure Resource Manager?.
   • Clustername: Geben Sie einen Namen für den Cluster ein.
   • Speicherort: Der Speicherort, an dem der Cluster bereitgestellt wird.
   • Cassandra-Version - Version von Apache Cassandra, die eingesetzt werden soll.
   • Erweiterung: Erweiterungen, die hinzugefügt werden, einschließlich Cassandra Lucene Index.
   • Ursprüngliches Cassandra-Administratorkennwort: Das Kennwort, das zum Erstellen des Clusters verwendet wird.
   • Cassandra-Administratorkennwort bestätigen: Geben Sie Ihr Kennwort erneut ein.
   • Virtuelles Netzwerk: Wählen Sie ein vorhandenes virtuelles Netzwerk und ein Subnetz aus, oder erstellen Sie ein neues.
   • Rollen zuweisen: Für virtuelle Netzwerke sind besondere Berechtigungen erforderlich, damit verwaltete Cassandra-Cluster bereitgestellt werden können. Lassen Sie dieses Kontrollkästchen aktiviert, wenn Sie ein neues virtuelles Netzwerk erstellen oder ein vorhandenes virtuelles Netzwerk ohne angewendete Berechtigungen verwenden. Wenn Sie ein virtuelles Netzwerk verwenden, in dem Sie bereits Azure SQL Managed Instance-Cassandra-Cluster bereitgestellt haben, deaktivieren Sie diese Option.

   

   Tipp

   Wenn Sie VPN verwenden, müssen Sie keine weitere Verbindung herstellen.

   Hinweis

   Für die Bereitstellung einer Instanz von Azure Managed Instance for Apache Cassandra ist Internetzugriff erforderlich. In Umgebungen, in denen der Internetzugriff eingeschränkt ist, tritt ein Fehler bei der Bereitstellung auf. Stellen Sie sicher, dass der Zugriff im VNet auf die folgenden wichtigen Azure-Dienste, die für die richtige Funktionsweise von Managed Cassandra erforderlich sind, nicht blockiert ist. Ausführlichere Informationen finden Sie unter Erforderliche Netzwerkregeln für ausgehenden Datenverkehr.

   • Azure Storage
   • Azure Key Vault
   • Skalierungsgruppen für virtuelle Azure-Computer
   • Azure-Überwachung
   • Microsoft Entra ID
   • Azure Security
   • Automatische Replikation - Wählen Sie die Form der automatischen Replikation. Weitere Informationen
   • Schedule Event Strategy - Die Strategie, die der Cluster für geplante Ereignisse verwenden soll.

   Tipp

   • StopANY bedeutet, dass ein beliebiger Knoten gestoppt wird, wenn für diesen Knoten ein Termin vorliegt.
   • StopByRack bedeutet, dass nur Knoten in einem bestimmten Rack für ein bestimmtes geplantes Ereignis angehalten werden. Wenn z. B. zwei oder mehr Ereignisse für Knoten in verschiedenen Racks zur gleichen Zeit geplant sind, werden nur die Knoten in einem Rack angehalten, während die anderen Knoten in anderen Racks verzögert werden.

5. Wählen Sie als Nächstes die Registerkarte Rechenzentrum aus.

6. Geben Sie die folgenden Details ein:

   • Rechenzentrumsname: Geben Sie in das Textfeld einen Namen für das Rechenzentrum ein.
   • Verfügbarkeitszone: Aktivieren Sie dieses Kontrollkästchen, wenn Verfügbarkeitszonen aktiviert werden sollen.
   • SKU-Größe: Wählen Sie eine der verfügbaren VM-SKU-Größen aus.

   

   Hinweis

   Wir haben das Write-Through-Caching (Public Preview) durch die Verwendung von VM-SKUs der L-Serie eingeführt. Diese Implementierung zielt darauf ab, die Latenzzeiten zu minimieren und die Leseleistung zu verbessern, insbesondere bei leseintensiven Workloads. Diese speziellen SKUs sind mit lokal angeschlossenen Festplatten ausgestattet, die eine enorme Steigerung der IOPS bei Lesevorgängen und eine geringere Latenzzeit gewährleisten.

   Wichtig

   Write-Through-Caching, ist in der öffentlichen Vorschau. Dieses Feature wird ohne Vereinbarung zum Servicelevel bereitgestellt und ist nicht für Produktionsworkloads vorgesehen. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

   • Nein. von Datenträgern – Wählen Sie die Anzahl der P30-Datenträger aus, die an jeden Cassandra-Knoten angefügt werden sollen.
   • Nein. von Knoten – Wählen Sie die Anzahl der Cassandra-Knoten aus, die in diesem Rechenzentrum bereitgestellt werden.

   

   Warnung

   Verfügbarkeitszonen werden nicht in allen Regionen unterstützt. Bereitstellungen sind nicht erfolgreich, wenn Sie eine Region auswählen, in der Verfügbarkeitszonen nicht unterstützt werden. Informationen zu den unterstützten Regionen finden Sie hier. Die erfolgreiche Bereitstellung von Verfügbarkeitszonen unterliegt auch der Verfügbarkeit von Computeressourcen in allen Zonen in der angegebenen Region. Bei Bereitstellungen kann ein Fehler auftreten, wenn die von Ihnen ausgewählte SKU oder Kapazität nicht in allen Zonen verfügbar ist.

7. Wählen Sie dann Prüfung + Erstellen>Erstellen

   Hinweis

   Es kann bis zu 15 Minuten dauern, bis der Cluster erstellt ist.

   

8. Nachdem die Bereitstellung abgeschlossen ist, aktivieren Sie Ihre Ressourcengruppe, um den neu erstellten Managed Instance-Cluster anzuzeigen:

   

9. Navigieren Sie zum Durchsuchen der Clusterknoten zur Clusterressource, und öffnen Sie den Bereich Rechenzentrum, um sie anzuzeigen:

   

Skalieren eines Rechenzentrums

Nachdem Sie nun einen Cluster mit einem einzelnen Rechenzentrum bereitgestellt haben, können entweder horizontal oder vertikal skalieren, indem Sie das Rechenzentrum hervorheben und die Scale-Schaltfläche auswählen:

Horizontale Skalierung

Um Knoten auf- oder abzuskalieren, verschieben Sie den Schieberegler auf die gewünschte Zahl, oder bearbeiten Sie einfach den Wert. Wenn Sie fertig sind, wählen Sie Scale aus.

Vertikale Skalierung

Wenn Sie die SKU-Größe für Ihre Knoten nach oben skalieren oder verkleinern möchten, wählen Sie aus der Sku Size-Dropdownliste aus. Wenn Sie fertig sind, wählen Sie Scale aus.

Hinweis

Wie lange ein Skalierungsvorgang dauert, hängt von verschiedenen Faktoren ab; er kann mehrere Minuten dauern. Wenn Azure Ihnen mitteilt, dass der Skalierungsvorgang abgeschlossen ist, bedeutet dies nicht, dass alle Ihre Knoten dem Cassandra-Ring beigetreten sind. Knoten werden vollständig in Betrieb genommen, wenn alle den Status „fehlerfrei“ haben und der Rechenzentrumsstatus „erfolgreich“ ist. Die Skalierung ist ein Onlinevorgang und funktioniert auf die gleiche Weise wie für das Patchen in Verwaltungsvorgängen beschrieben.

Hinzufügen eines Rechenzentrums

1. Wenn Sie ein anderes Rechenzentrum hinzufügen möchten, klicken Sie im Bereich Rechenzentrum auf die Schaltfläche „Hinzufügen“:

   

   Warnung

   Wenn Sie ein Rechenzentrum in einer anderen Region hinzufügen, müssen Sie ein anderes virtuelles Netzwerk auswählen. Sie müssen auch sicherstellen, dass dieses virtuelle Netzwerk über eine Verbindung mit dem virtuellen Netzwerk der primären Region verfügt, das oben erstellt wurde (und allen anderen virtuellen Netzwerken, die Rechenzentren im Cluster der verwalteten Instanz hosten). Lesen Sie sich diesen Artikel durch, um mehr über das Peering virtueller Netzwerke mithilfe des Azure-Portals zu erfahren. Außerdem müssen Sie sicherstellen, dass Sie die entsprechende Rolle auf Ihr virtuelles Netzwerk angewendet haben, bevor Sie versuchen, einen Cluster der verwalteten Instanz mithilfe des folgenden CLI-Befehls bereitzustellen.

       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. Füllen Sie die entsprechenden Felder aus:

   • Datacenter name (Name des Rechenzentrums): Wählen Sie in der Dropdownliste Ihr Azure-Abonnement aus.
   • Verfügbarkeitszone: Aktivieren Sie dieses Kontrollkästchen, wenn Verfügbarkeitszonen in diesem Rechenzentrum aktiviert werden sollen.
   • Speicherort: Der Speicherort, an dem das Rechenzentrum bereitgestellt wird.
   • SKU-Größe: Wählen Sie eine der verfügbaren VM-SKU-Größen aus.
   • Nein. von Datenträgern – Wählen Sie die Anzahl der P30-Datenträger aus, die an jeden Cassandra-Knoten angefügt werden sollen.
   • Nein. von Knoten – Wählen Sie die Anzahl der Cassandra-Knoten aus, die in diesem Rechenzentrum bereitgestellt werden.
   • Virtuelles Netzwerk: Wählen Sie ein vorhandenes virtuelles Netzwerk und ein Subnetz aus.

   

   Warnung

   Beachten Sie, dass es beim Hinzufügen eines Rechenzentrums nicht erlaubt ist, ein neues virtuelles Netzwerk zu erstellen. Sie müssen ein vorhandenes virtuelles Netzwerk auswählen, und – wie oben erwähnt – sicherstellen, dass Konnektivität zwischen den Zielsubnetzen besteht, in denen Rechenzentren bereitgestellt werden. Sie müssen auch die entsprechende Rolle auf das VNet anwenden, um die Bereitstellung zu ermöglichen (siehe oben).

3. Wenn das Rechenzentrum bereitgestellt wird, sollten Sie alle Rechenzentrumsinformationen im Bereich Rechenzentrum anzeigen können:

   

4. Um die Replikation zwischen den Rechenzentren sicherzustellen, stellen Sie eine Verbindung mit cqlsh her und verwenden Sie die folgende CQL-Abfrage, um die Replikationsstrategie in jedem Keyspace zu aktualisieren und alle Rechenzentren im gesamten Cluster einzubeziehen (Systemtabellen werden automatisch aktualisiert):

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

5. Wenn Sie ein Rechenzentrum zu einem Cluster hinzufügen, in dem bereits Daten vorhanden sind, müssen Sie rebuild ausführen, um die historischen Daten zu replizieren. Führen Sie in Azure CLI den folgenden Befehl aus, um nodetool rebuild auf jedem Knoten des neuen Rechenzentrums auszuführen. Ersetzen Sie dabei <new dc ip address> durch die IP-Adresse des Knotens und <olddc> durch den Namen Ihres bestehenden Rechenzentrums:

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

   Warnung

   Sie sollten den Anwendungsclients nicht erlauben, in das neue Rechenzentrum zu schreiben, bevor Sie die Änderungen an der Keyspace-Replikation vorgenommen haben. Andernfalls funktioniert die Neuerstellung nicht und Sie müssen eine Supportanfrage erstellen, damit unser Team repair für Sie ausführen kann.

Aktualisieren der Cassandra-Konfiguration

Der Dienst ermöglicht die Aktualisierung auf eine Cassandra-YAML-Konfiguration in einem Rechenzentrum über das Portal oder mittels CLI-Befehlen. So aktualisieren Sie Einstellungen im Portal

1. Suchen Sie in den „Einstellungen“ nach Cassandra Configuration. Markieren Sie das Rechenzentrum, dessen Konfiguration Sie ändern möchten, und klicken Sie auf „Aktualisieren“:

   

2. Geben Sie im daraufhin geöffneten Fenster die Feldnamen im YAML-Format ein, wie unten gezeigt. Klicken Sie dann auf „Aktualisieren“.

   

3. Wenn die Aktualisierung abgeschlossen ist, werden die überschriebenen Werte im Bereich Cassandra Configuration angezeigt:

   

   Hinweis

   Nur überschriebene Cassandra-Konfigurationswerte werden im Portal angezeigt.

   Wichtig

   Stellen Sie sicher, dass die von Ihnen bereitgestellten Cassandra-YAML-Einstellungen für die von Ihnen bereitgestellte Version von Cassandra geeignet sind. Cassandra v3.11-Einstellungen finden Sie hier und v4.0-Einstellungen hier. Die folgenden YAML-Einstellungen dürfen nicht aktualisiert werden:

   • 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
   • Partitionierer
   • rpc_address
   • rpc_interface

Cassandra-Version aktualisieren

Wichtig

Die Updates von Cassandra 5.0 und der Turnkey-Version befinden sich in der öffentlichen Vorschau. Diese Features werden ohne Vereinbarung zum Servicelevel bereitgestellt und nicht für Produktionsworkloads empfohlen. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Sie haben die Möglichkeit, Hauptversions-Upgrades direkt über das Portal oder über Az CLI, Terraform oder ARM-Vorlagen durchzuführen.

1. Suchen Sie das Feld Update auf der Registerkarte Übersicht

   

2. Wählen Sie die Cassandra-Version aus der Dropdown-Liste aus.

   Warnung

   Überspringen Sie keine Versionen. Wir empfehlen, nur von einer Version auf eine andere zu aktualisieren, z.B. 3.11 auf 4.0, 4.0 auf 4.1.

   

3. Wählen Sie zum Speichern „Aktualisieren“.

Schlüsselfertige Replikation

Mit Cassandra 5.0 wird ein optimierter Ansatz für die Bereitstellung von Clustern mit mehreren Regionen eingeführt, der mehr Komfort und Effizienz bietet. Die schlüsselfertige Replikationsfunktionalität macht die Einrichtung und Verwaltung von Clustern mit mehreren Regionen leichter zugänglich und ermöglicht eine reibungslosere Integration und den Betrieb in verteilten Umgebungen. Dieses Update reduziert die Komplexität, die traditionell mit der Bereitstellung und Wartung von Konfigurationen für mehrere Regionen verbunden ist, erheblich und ermöglicht es Anwendern, die Funktionen von Cassandra einfacher und effektiver zu nutzen.

Tipp

• Keine: Automatische Replikation ist auf keine eingestellt.
• SystemKeyspaces: Automatische Wiederholung aller System-Keyspaces (system_auth, system_traces, system_auth)
• AllKeyspaces: Automatisches Replizieren aller Keyspaces und Überwachen, ob neue Keyspaces erstellt werden, um dann die Einstellungen für das automatische Replizieren automatisch anzuwenden.

Szenarien der automatischen Replikation

• Beim Hinzufügen eines neuen Rechenzentrums wird die automatische Replikationsfunktion in Cassandra nahtlos ausgeführt nodetool rebuild, um die erfolgreiche Replikation von Daten über das hinzugefügte Rechenzentrum sicherzustellen.
• Das Entfernen eines Rechenzentrums führt zu einer automatischen Entfernung des betreffenden Rechenzentrums aus den Keyspaces.

Externe Rechenzentren, z. B. solche, die vor Ort gehostet werden, können durch die Verwendung der Eigenschaft "Externes Rechenzentrum" in die Keyspaces aufgenommen werden. Dadurch kann Cassandra diese externen Rechenzentren als Quellen für den Wiederherstellungsprozess einbeziehen.

Warnung

Wenn Sie die automatische Replikation auf „AllKeyspaces“ setzen, wird die Replikation der Keyspaces so geändert, dass sie auch WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Wenn dies nicht die von Ihnen gewünschte Topologie ist, müssen Sie SystemKeyspaces verwenden, diese selbst anpassen und nodetool rebuild manuell auf dem Azure Managed Instance for Apache Cassandra-Cluster ausführen.

Aufheben der Clusterzuordnung

1. Für Nicht-Produktionsumgebungen können Sie Ressourcen im Cluster anhalten/deren Zuordnung aufheben, um zu vermeiden, dass sie in Rechnung gestellt werden (Speicher wird weiterhin in Rechnung gestellt). Ändern Sie den Clustertyp zuerst in NonProduction, und führen Sie dann deallocate aus.

Tipp

Der Clustertyp sollte nur als „NonProduction“ verwendet werden, um Entwicklungskosten zu sparen. Sie können mit kleineren SKUs verwendet werden und sollten NICHT zum Ausführen von Produktionsworkloads verwendet werden.

Warnung

• Der als „Nonproduction“ definierte Clustertyp hat keine SLA-Garantien darauf angewendet.
• Führen Sie während des Aufhebens der Zuordnung keine Schema- oder Schreibvorgänge aus. Dies kann zu Datenverlust und in seltenen Fällen zu Schemabeschädigungen führen, die einen manuellen Eingriff des Supportteams erfordern.

Problembehandlung

Wenn beim Anwenden von Berechtigungen für Ihre Virtual Network-Instanz mithilfe der Azure CLI ein Fehler mit dem Hinweis auftritt, dass der Benutzer oder Dienstprinzipal in der Graphdatenbank für „e5007d2c-4b13-4a74-9b6a-605d99f03501“ nicht gefunden werden kann, können Sie die gleiche Berechtigung manuell über das Azure-Portal anwenden. Informationen zur Vorgehensweise finden Sie hier.

Hinweis

Die Azure Cosmos DB-Rollenzuweisung wird nur für Bereitstellungszwecke verwendet. Azure Managed Instance for Apache Cassandra verfügt über keine Back-End-Abhängigkeiten von Azure Cosmos DB.

Herstellen einer Verbindung mit Ihrem Cluster

Azure Managed Instance for Apache Cassandra erstellt keine Knoten mit öffentlichen IP-Adressen. Um also eine Verbindung mit dem neu erstellten Cassandra-Cluster herzustellen, müssen Sie eine weitere Ressource im VNET erstellen. Dabei kann es sich um eine Anwendung handeln oder einen virtuellen Computer, auf dem das Open-Source-Abfragetool CQLSH von Apache installiert ist. Sie können eine Vorlage verwenden, um einen virtuellen Ubuntu-Computer bereitzustellen.

Herstellen einer Verbindung über CQLSH

Nachdem der virtuelle Computer bereitgestellt wurde, verwenden Sie SSH, um eine Verbindung mit dem Computer herzustellen, und installieren CQLSH mithilfe der folgenden Befehle:

# 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

Herstellen einer Verbindung über eine Anwendung

Wie bei CQLSH muss auch bei der Verbindung aus einer Anwendung, die einen der unterstützten Apache Cassandra-Clienttreiber verwendet, die SSL-Verschlüsselung aktiviert und die Zertifizierungsprüfung deaktiviert sein. Weitere Beispiele für die Verbindung zu Azure Managed Instance for Apache Cassandra mit Java, .NET, Node.js und Python.

Es wird empfohlen, die Zertifikatüberprüfung zu deaktivieren, da die Zertifikatüberprüfung nur dann funktioniert, wenn Sie die IP-Adressen Ihrer Clusterknoten der entsprechenden Domäne zuordnen. Wenn Sie über eine interne Richtlinie verfügen, die eine Überprüfung von SSL-Zertifikaten für jede Anwendung vorschreibt, können Sie dies vereinfachen, indem Sie Einträge wie 10.0.1.5 host1.managedcassandra.cosmos.azure.com in Ihrer Datei „hosts“ für jeden Knoten hinzufügen. Wenn Sie diesen Ansatz auswählen, müssen Sie auch neue Einträge hinzufügen, wenn Sie die Knoten hochskalieren.

Für Java sollten Sie unbedingt auch spekulative Ausführungsrichtlinien aktivieren, wenn Anwendungen empfindlich auf die Latenzzeit reagieren. Eine Demo zur Veranschaulichung der Funktionsweise und zum Aktivieren der Richtlinie finden Sie hier.

Hinweis

In den meisten Fällen sollte es nicht erforderlich sein, Zertifikate (rootCA, node oder client, truststores usw.) zu konfigurieren oder zu installieren, um eine Verbindung mit Azure Managed Instance for Apache Cassandra herzustellen. Die SSL-Verschlüsselung kann aktiviert werden, indem Sie den Standard-Truststore und das Kennwort der vom Client verwendeten Laufzeitumgebung verwenden (siehe Beispiele für Java, .NET, Node.js und Python), da Azure Managed Instance for Apache Cassandra-Zertifikate von dieser Umgebung als vertrauenswürdig eingestuft werden. In seltenen Fällen, wenn das Zertifikat nicht vertrauenswürdig ist, müssen Sie es möglicherweise zum Truststore hinzufügen.

Konfigurieren von Clientzertifikaten (optional)

Das Konfigurieren von Clientzertifikaten ist optional. Eine Clientanwendung kann eine Verbindung zu Azure Managed Instance for Apache Cassandra herstellen, wenn die oben genannten Schritte durchgeführt wurden. Sie können jedoch auch zusätzlich Clientzertifikate für die Authentifizierung erstellen und konfigurieren, wenn Sie dies wünschen. Im Allgemeinen gibt es zwei Möglichkeiten zum Erstellen von Zertifikaten:

• Selbstsignierte Zertifikate. Dies bedeutet, dass für jeden Knoten ein privates und ein öffentliches Zertifikat (kein Zertifizierungsstellenzertifikat) vorhanden sind. In diesem Fall benötigen wir alle öffentlichen Zertifikate.
• Zertifikate, die von einer Zertifizierungsstelle signiert wurden. Hierbei kann es sich um eine selbstsignierte Zertifizierungsstelle oder sogar um eine öffentliche Zertifizierungsstelle handelt. In diesem Fall benötigen wir das Stammzertifizierungsstellenzertifikat (siehe Anweisungen zum Vorbereiten von SSL-Zertifikaten für die Produktion) und alle Zwischenstufen (falls zutreffend).

Wenn Sie die Client-zu-Knoten-Zertifikatauthentifizierung oder gegenseitige Transport Layer Security implementieren möchten, müssen Sie die Zertifikate über Azure CLI bereitstellen. Mit dem folgenden Befehl werden Ihre Clientzertifikate hochgeladen und in den Vertrauensspeicher für Ihren verwalteten Cassandra-Instanzcluster angewendet (d. h. Sie müssen die Einstellungen cassandra.yaml nicht bearbeiten). Nach der Anwendung erfordert Ihr Cluster, dass Cassandra die Zertifikate überprüft, wenn ein Client eine Verbindung herstellt (siehe 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

Bereinigen von Ressourcen

Falls Sie diesen Managed Instance-Cluster nicht mehr benötigen, löschen Sie ihn wie folgt:

1. Wählen Sie im linken Menü des Azure-Portals die Option Ressourcengruppen aus.
2. Wählen Sie in der Liste die Ressourcengruppe aus, die Sie für diesen Schnellstart erstellt haben.
3. Wählen Sie im Ressourcengruppenbereich Übersicht die Option Ressourcengruppe löschen aus.
4. Geben Sie in dem nächsten Fenster den Namen der zu löschenden Ressourcengruppe ein, und wählen Sie dann Löschen aus.

Nächste Schritte

In dieser Schnellstartanleitung haben Sie erfahren, wie Sie mithilfe des Azure-Portals eine Azure Managed Instance-Instanz für einen Apache Cassandra-Cluster erstellen. Sie können jetzt beginnen, mit dem Cluster zu arbeiten.

Bereitstellen eines verwalteten Apache Spark-Clusters mit Azure Databricks