Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht es auch, Konfigurationen zu überschreiben, je nach den spezifischen Anforderungen jeder Workload, die maximale Flexibilität und Kontrolle bei Bedarf ermöglicht.
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
Melden Sie sich beim Azure-Portal an.
Suchen Sie in der Suchleiste nach Managed Instance for Apache Cassandra, und wählen Sie das Ergebnis aus.
Wählen Sie "Verwaltete Instanz erstellen" für Apache Cassandra-Cluster aus.
Geben Sie im Bereich Managed Instance for Apache Cassandra-Cluster erstellen folgende Details ein:
- Abonnement – Wählen Sie im Dropdownmenü 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.
- Clustername: Geben Sie einen Namen für den Cluster ein.
- Standort – Standort zur Bereitstellung des Clusters.
- Cassandra Version - Die Version von Apache Cassandra einzusetzen.
- Extention - Erweiterungen, die hinzugefügt werden sollen, 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 verlassendes virtuelles Netzwerk und Subnetz aus, oder erstellen Sie ein neues Netzwerk.
- Zuweisen von Rollen – Virtuelle Netzwerke erfordern spezielle Berechtigungen, 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 Berechtigungen verwenden. Wenn Sie ein virtuelles Netzwerk verwenden, in dem Sie zuvor Azure SQL Managed Instance Cassandra-Cluster bereitgestellt haben, deaktivieren Sie diese Option.
Tipp
Wenn Sie VPN verwenden, müssen Sie keine weitere Verbindung öffnen.
Hinweis
Die Bereitstellung einer azure managed Instance für Apache Cassandra erfordert Internetzugriff. In Umgebungen, in denen der Internetzugriff eingeschränkt ist, tritt ein Fehler bei der Bereitstellung auf. Stellen Sie sicher, dass Sie den Zugriff in Ihrem virtuellen Netzwerk nicht auf die folgenden wichtigen Azure-Dienste blockieren, die erforderlich sind, damit verwaltete Cassandra ordnungsgemäß funktioniert. Weitere Informationen finden Sie unter "Erforderliche ausgehende Netzwerkregeln".
- Azure Storage
- Azure Key Vault
- Skalierungsgruppen für virtuelle Azure-Computer
- Azure-Überwachung
- Microsoft Entra ID
- Azure Security
- Auto-Replikation. Wählen Sie die zu verwendende Form der Autoreplizierung aus. Weitere Informationen finden Sie unter Turnkey-Replikation.
- Veranstaltungsstrategie planen. Die Strategie, die vom Cluster für geplante Ereignisse verwendet wird.
Tipp
- StopANY bedeutet, dass jeder Knoten beendet wird, wenn ein geplantes Ereignis für den Knoten vorhanden ist.
- StopByRack bedeutet, dass nur der Knoten in einem bestimmten Rack für ein bestimmtes geplantes Ereignis beendet wird. Wenn beispielsweise mehrere Ereignisse für Knoten in unterschiedlichen Racks gleichzeitig geplant werden, werden nur Knoten in einem Rackstopp geplant. Andere Knoten in anderen Racks werden verzögert.
Wählen Sie als Nächstes die Registerkarte Rechenzentrum aus.
Geben Sie die folgenden Details ein:
- Name des Rechenzentrums. Geben Sie einen Rechenzentrumsnamen in das Textfeld ein.
- Verfügbarkeitszone. Aktivieren Sie dieses Kontrollkästchen, wenn Verfügbarkeitszonen aktiviert werden sollen.
- SKU-Größe. Wählen Sie aus den verfügbaren SKU-Größen des virtuellen Computers aus.
Hinweis
Wir haben das Write-through-Caching (Public Preview) mithilfe von L-Series-VM-SKUs 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 Datenträgern ausgestattet, die eine enorm erhöhte IOPS für Lesevorgänge und reduzierte Taillatenz gewährleisten.
Wichtig
Write-Through-Caching, ist in der öffentlichen Vorschau. Dieses Feature wird ohne Vereinbarung zum Servicelevel bereitgestellt. Sie sollte nicht für Produktionsworkloads verwendet werden. 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 für dieses Rechenzentrum bereitgestellt werden sollen.
Warnung
Verfügbarkeitszonen werden in allen Regionen nicht unterstützt. Bereitstellungen schlagen fehl, wenn Sie eine Region auswählen, in der Verfügbarkeitszonen nicht unterstützt werden. Weitere Informationen finden Sie in der Azure-Regionsliste.
Die erfolgreiche Bereitstellung von Verfügbarkeitszonen unterliegt auch der Verfügbarkeit von Computeressourcen in allen Zonen in der angegebenen Region. Bereitstellungen können fehlschlagen, wenn die ausgewählte SKU oder Kapazität nicht in allen Zonen verfügbar ist.
Wählen Sie dann "Überprüfen" und "Erstellen" aus>.
Hinweis
Es kann bis zu 15 Minuten dauern, bis ein Cluster erstellt wird.
Nachdem die Bereitstellung abgeschlossen ist, aktivieren Sie Ihre Ressourcengruppe, um den neu erstellten managed Instance-Cluster anzuzeigen:
Um die Clusterknoten anzusehen, wählen Sie die Clusterressource aus und öffnen Sie den Bereich Data Center:
Skalieren eines Rechenzentrums
Nachdem Sie nun einen Cluster mit einem einzigen Rechenzentrum bereitgestellt haben, können Sie horizontal oder vertikal skalieren, indem Sie das Rechenzentrum hervorheben und die Schaltfläche " Skalieren " 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 "Skalieren" aus.
Vertikale Skalierung
Wenn Sie die SKU-Größe für Ihre Knoten nach oben skalieren oder verkleinern möchten, wählen Sie die Option " Sku-Größe" aus. Wenn Sie fertig sind, wählen Sie "Skalieren" aus.
Hinweis
Die Zeitdauer für einen Skalierungsvorgang hängt von verschiedenen Faktoren ab. Dies kann einige Minuten dauern. Wenn Azure Sie benachrichtigt, dass der Skalierungsvorgang abgeschlossen ist, bedeutet dies nicht, dass alle Knoten dem Cassandra-Ring beigetreten sind. Knoten werden vollständig in Auftrag gegeben, wenn alle einen Status von fehlerfreien anzeigen und der Rechenzentrumsstatus liest, erfolgreich.
Die Skalierung ist ein Onlinevorgang und funktioniert auf die gleiche Weise wie beim Patchen beschrieben. Weitere Informationen finden Sie unter Patching.
Hinzufügen eines Rechenzentrums
Um ein weiteres Rechenzentrum hinzuzufügen, wählen Sie im Rechenzentrumsbereich die Schaltfläche "Hinzufügen" aus:
Warnung
Wenn Sie ein Rechenzentrum in einer anderen Region hinzufügen, müssen Sie ein anderes virtuelles Netzwerk auswählen. Außerdem müssen Sie sicherstellen, dass dieses virtuelle Netzwerk über Eine Verbindung mit dem virtuellen Netzwerk der primären Region verfügt, das zuvor erstellt wurde. Stellen Sie außerdem sicher, dass alle anderen virtuellen Netzwerke, die Rechenzentren im verwalteten Instanzcluster hosten, gehostet werden. Weitere Informationen finden Sie unter Verbinden virtueller Netzwerke mit virtuellem Netzwerk-Peering.
Außerdem müssen Sie sicherstellen, dass Sie die entsprechende Rolle auf Ihr virtuelles Netzwerk angewendet haben, bevor Sie versuchen, einen verwalteten Instanzcluster 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>
Füllen Sie die entsprechenden Felder aus:
- Name des Rechenzentrums. Wählen Sie in der Dropdownliste Ihr Azure-Abonnement aus.
- Verfügbarkeitszone. Wählen Sie aus, ob Verfügbarkeitszonen in diesem Rechenzentrum aktiviert werden sollen.
- Ort. Standort, an dem Ihr Rechenzentrum bereitgestellt wird.
- SKU-Größe. Wählen Sie aus den verfügbaren SKU-Größen des virtuellen Computers 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 für dieses Rechenzentrum bereitgestellt werden sollen.
- Virtuelles Netzwerk. Wählen Sie ein verlassendes virtuelles Netzwerk und Subnetz aus.
Warnung
Das Azure-Portal lässt die Erstellung eines neuen virtuellen Netzwerks nicht zu, wenn Sie ein Rechenzentrum hinzufügen. Sie müssen ein vorhandenes virtuelles Netzwerk auswählen und sicherstellen, dass die Konnektivität zwischen den Zielsubnetzen besteht, in denen Rechenzentren bereitgestellt werden. Sie müssen auch die entsprechende Rolle auf das virtuelle Netzwerk anwenden, um die Bereitstellung zuzulassen, wie zuvor beschrieben.
Wenn das Rechenzentrum bereitgestellt wird, sollten Sie alle Rechenzentrumsinformationen im Bereich Rechenzentrum anzeigen können:
Um die Replikation zwischen Rechenzentren sicherzustellen, stellen Sie eine Verbindung mit cqlsh her, und verwenden Sie die folgende CQL-Abfrage, um die Replikationsstrategie in jedem Keyspace zu aktualisieren, um alle Rechenzentren im gesamten Cluster einzuschließen. Systemtabellen werden automatisch aktualisiert.
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
Wenn Sie ein Rechenzentrum zu einem Cluster hinzufügen, in dem bereits Daten vorhanden sind, führen Sie die Ausführung aus
rebuild
, um die historischen Daten zu replizieren. Verwenden Sie in Azure CLI den folgenden Befehl, der auf jedem Knoten des neuen Rechenzentrums ausgeführt wirdnodetool rebuild
. Diese Aktion ersetzt<new dc ip address>
durch die IP-Adresse des Knotens und<olddc>
durch den Namen Ihres vorhandenen 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 nicht zulassen, dass Anwendungsklienten in das neue Rechenzentrum schreiben, bis Sie Änderungen der Keyspace-Replikation anwenden. Andernfalls funktioniert die Neuerstellung nicht, und Sie müssen eine Supportanfrage erstellen, damit unser Team
repair
in Ihrem Auftrag ausführen kann.
Aktualisieren der Cassandra-Konfiguration
Der Dienst ermöglicht Updates für cassandra YAML-Konfiguration in einem Rechenzentrum mithilfe des Azure-Portals oder mithilfe von CLI-Befehlen. So aktualisieren Sie Einstellungen im Portal
Suchen Sie in den „Einstellungen“ nach
Cassandra Configuration
. Markieren Sie das Rechenzentrum, dessen Konfiguration Sie ändern möchten, und wählen Sie "Update" aus:Geben Sie im daraufhin geöffneten Fenster die Feldnamen im YAML-Format ein, wie hier gezeigt. Wählen Sie dann "Aktualisieren" aus.
Nach Abschluss der Aktualisierung werden die überschriebenen Werte im
Cassandra Configuration
Bereich angezeigt:Hinweis
Im Azure-Portal werden nur überschriebene Cassandra-Konfigurationswerte angezeigt.
Wichtig
Stellen Sie sicher, dass die von Ihnen bereitgestellten Cassandra-Yaml-Einstellungen für die von Ihnen bereitgestellte Version von Cassandra geeignet sind. Siehe Cassandra v3.11 für die Einstellungen von Cassandra v3.11 und Cassandra v4.0 für die Einstellungen von v4.0. Sie können die folgenden YAML-Einstellungen nicht aktualisieren:
- Clustername
- seed_provider
- initial_token
- autobootstrap
- Client-Verschlüsselungsoptionen
- Server-Verschlüsselungsoptionen
- Optionen für die transparente Datenverschlüsselung
- audit_logging_options
- Authentifikator
- Genehmigungsgeber
- role_manager
- Speicheranschluss
- 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-Schnittstelle
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. Wir empfehlen diese Features nicht für Produktionsworkloads. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.
Sie können direkte Upgrades von Hauptversionen direkt über das Portal oder über Az CLI, Terraform oder ARM-Vorlagen durchführen.
Suchen Sie das
Update
Panel über die Registerkarte "Übersicht".Wählen Sie die Cassandra-Version aus der Dropdownliste aus.
Warnung
Überspringen Sie keine Versionen. Es wird empfohlen, nur von einer Version auf ein anderes Beispiel 3.11 auf 4.0, 4.0 auf 4.1 zu aktualisieren.
Wählen Sie "Aktualisierung" zum Speichern aus.
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. Wenn Sie turnkey-Replikationsfunktionen verwenden, wird das Einrichten und Verwalten von Multi-Region-Clustern barrierefreier, sodass eine reibungslosere Integration und ein reibungsloserer Betrieb in verteilten Umgebungen möglich ist.
Dieses Update reduziert die Komplexitäten im Zusammenhang mit der Bereitstellung und Wartung mehrerer Regionskonfigurationen erheblich, sodass Benutzer die Funktionen von Cassandra mit größerer Leichtigkeit und Effektivität nutzen können.
Tipp
- Keine: Automatische Replikation ist auf keine eingestellt.
- SystemKeyspaces: Autoreplicate alle Systemtastentasten (system_auth, system_traces, system_auth).
- AllKeyspaces: Autoreplicate alle Keyspaces und überwachen, wenn neue Keyspaces erstellt werden, und wenden Sie dann automatisch autoreplicate-Einstellungen an.
Autoreplizierungsszenarien
- Wenn Sie ein neues Rechenzentrum hinzufügen, wird das Feature "Autoreplicate" 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.
Für externe Rechenzentren, z. B. lokal gehostete, können sie mithilfe der externen Rechenzentrumseigenschaft in die Keyspaces aufgenommen werden. Mit diesem Ansatz kann Cassandra diese externen Rechenzentren als Quellen für den Neuerstellungsprozess integrieren.
Warnung
Wenn Sie "Autoreplicate" auf "AllKeyspaces" festlegen, ändert sich die Replikation ihrer Schlüsseltasten, um Folgendes einzuschließen:
WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }
Wenn diese Topologie nicht das ist, was Sie möchten, verwenden Sie SystemKeyspaces, passen Sie sie selbst an und führen Sie nodetool rebuild
manuell auf der Azure Managed Instance für Apache Cassandra-Cluster aus.
Deallocate Cluster
Bei Nichtproduktionsumgebungen können Sie Ressourcen im Cluster anhalten oder umordnen, um zu vermeiden, dass sie in Rechnung gestellt werden. Sie werden weiterhin für den Speicherplatz belastet. Ändern Sie den Clustertyp zuerst in NonProduction
, dann in deallocate
.
Tipp
Der Clustertyp sollte nur als "Nichtproduktion" verwendet werden, um Entwicklungskosten zu sparen. Sie sind möglicherweise mit kleineren SKUs verfügbar und sollten nicht in Produktionsumgebungen verwendet werden.
Warnung
- Der als "Nichtproduktion" definierte Clustertyp hat keine SLA-Garantien darauf angewendet.
- Führen Sie während der Deallocation keine Schema- oder Schreibvorgänge aus. Diese Aktion kann zu Datenverlusten und in seltenen Fällen zu Schemabeschädigungen führen, die manuelle Eingriffe des Supportteams erfordern.
Problembehandlung
Wenn beim Anwenden von Berechtigungen auf Ihr virtuelles Netzwerk mithilfe der Azure CLI ein Fehler auftritt, können Sie dieselbe Berechtigung manuell über das Azure-Portal anwenden. Ein Beispiel für einen solchen Fehler ist Der Benutzer- oder Dienstprinzipal in der Diagrammdatenbank für "e5007d2c-4b13-4a74-9b6a-605d99f03501"kann nicht gefunden werden. Weitere Informationen finden Sie unter Verwenden des Azure-Portals zum Hinzufügen von Azure Cosmos DB-Dienstprinzipal.
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 für Apache Cassandra erstellt keine Knoten mit öffentlichen IP-Adressen. Um eine Verbindung mit Ihrem neu erstellten Cassandra-Cluster herzustellen, erstellen Sie eine weitere Ressource innerhalb des virtuellen Netzwerks. Diese Ressource kann eine Anwendung oder ein virtueller Computer sein, 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. Siehe Beispiele zum Herstellen einer Verbindung mit azure Managed Instance für Apache Cassandra mit Java, .NET, Node.jsund Python.
Es wird empfohlen, die Zertifikatüberprüfung zu deaktivieren, da die Zertifikatüberprüfung nicht funktioniert, es sei denn, Sie ordnen IP-Adressen Ihrer Clusterknoten der entsprechenden Domäne zu. Wenn Sie über eine interne Richtlinie verfügen, die die ÜBERPRÜFUNG von SSL-Zertifikaten für jede Anwendung vorschreibt, können Sie diese Einrichtung vereinfachen, indem Sie Einträge wie 10.0.1.5 host1.managedcassandra.cosmos.azure.com
in der Hostdatei für jeden Knoten hinzufügen. Wenn Sie diesen Ansatz verfolgen, müssen Sie auch neue Einträge hinzufügen, wenn Knoten skaliert werden.
Für Java sollten Sie unbedingt auch spekulative Ausführungsrichtlinien aktivieren, wenn Anwendungen empfindlich auf die Latenzzeit reagieren. Eine Demo, die veranschaulicht, wie dieser Ansatz funktioniert, finden Sie unter und wie Sie die Richtliniendemo aktivieren: Implementieren der spekulativen Ausführung.
Hinweis
In den meisten Fällen sollte es nicht erforderlich sein , Zertifikate (z. B. RootCA, Node oder Client, Truststores) zu konfigurieren oder zu installieren, um eine Verbindung mit azure Managed Instance für Apache Cassandra herzustellen. SSL-Verschlüsselung kann mithilfe des Standardmäßigen Truststores und des Kennworts der vom Client verwendeten Laufzeit aktiviert werden, da Azure Managed Instance für Apache Cassandra-Zertifikate von dieser Umgebung als vertrauenswürdig eingestuft werden. In seltenen Fällen müssen Sie es möglicherweise dem Truststore hinzufügen, wenn das Zertifikat nicht vertrauenswürdig ist. Siehe Java, .NET, Node.jsund Python.
Konfigurieren von Clientzertifikaten (optional)
Das Konfigurieren von Clientzertifikaten ist optional. Eine Clientanwendung kann eine Verbindung mit azure Managed Instance für Apache Cassandra herstellen, solange die vorherigen Schritte abgeschlossen sind. Bei Bedarf können Sie jedoch auch Clientzertifikate für die Authentifizierung erstellen und konfigurieren. Im Allgemeinen gibt es zwei Möglichkeiten zum Erstellen von Zertifikaten:
- Selbstsignierte Zertifikate. Ein privates und öffentliches Zertifikat (keine Zertifizierungsstelle) für jeden Knoten. In diesem Fall benötigen Sie alle öffentlichen Zertifikate.
- Zertifikate, die von einer Zertifizierungsstelle signiert wurden. Dieses Zertifikat kann eine selbstsignierte Zertifizierungsstelle oder sogar eine öffentliche Zertifizierungsstelle sein. In diesem Fall benötigen Sie das Zertifikat der Stammzertifizierungsstelle und alle Vermittler (falls zutreffend). Weitere Informationen finden Sie unter Vorbereiten von SSL-Zertifikaten für die Produktion.
Wenn Sie die Client-zu-Knoten-Zertifikatauthentifizierung oder die gegenseitige Transport Layer Security (mTLS) implementieren möchten, stellen Sie die Zertifikate mithilfe der Azure CLI bereit. Der folgende Befehl lädt Ihre Clientzertifikate hoch und wendet sie auf den Truststore für den verwalteten Instanzcluster an. Sie müssen keine Einstellungen bearbeiten cassandra.yaml
. Nachdem Sie den Befehl angewendet haben, benötigt Ihr Cluster Cassandra, um die Zertifikate zu überprüfen, wenn ein Client eine Verbindung herstellt. Siehe require_client_auth: true
in 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:
- Wählen Sie im linken Menü des Azure-Portals die Option Ressourcengruppen aus.
- Wählen Sie in der Liste die Ressourcengruppe aus, die Sie für diesen Schnellstart erstellt haben.
- Wählen Sie im Ressourcengruppenbereich Übersicht die Option Ressourcengruppe löschen aus.
- Geben Sie in dem nächsten Fenster den Namen der zu löschenden Ressourcengruppe ein, und wählen Sie dann Löschen aus.