Schnellstart: Konfigurieren eines Hybridclusters mit Azure Managed Instance for Apache Cassandra

Artikel
11/16/2023

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 wird veranschaulicht, wie Sie die Azure CLI-Befehle zum Konfigurieren eines Hybridclusters verwenden. Wenn Sie über vorhandene Rechenzentren in einer lokalen oder selbstgehosteten Umgebung verfügen, können Sie diesem Cluster mit Azure Managed Instance for Apache Cassandra weitere Rechenzentren hinzufügen und diese verwalten.

Voraussetzungen

Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Schnellstart für Bash in Azure Cloud Shell.
Wenn Sie CLI-Referenzbefehle lieber lokal ausführen, installieren Sie die Azure CLI. Wenn Sie Windows oder macOS ausführen, sollten Sie die Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter Ausführen der Azure CLI in einem Docker-Container.
- Wenn Sie eine lokale Installation verwenden, melden Sie sich mithilfe des Befehls az login bei der Azure CLI an. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Informationen zu anderen Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.
- Installieren Sie die Azure CLI-Erweiterung beim ersten Einsatz, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden von Erweiterungen mit der Azure CLI.
- Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.

Für diesen Artikel ist die Azure CLI-Version 2.30.0 oder höher erforderlich. Wenn Sie Azure Cloud Shell verwenden, ist die neueste Version bereits installiert.
Azure Virtual Network mit einer Verbindung mit Ihrer selbstgehosteten bzw. lokalen Umgebung. Weitere Informationen zum Herstellen einer Verbindung für lokale Umgebungen mit Azure finden Sie im Artikel Verbinden eines lokalen Netzwerks mit Azure.

Konfigurieren eines Hybridclusters

Melden Sie sich beim Azure-Portal an, und navigieren Sie zu Ihrer VNET-Ressource.
Öffnen Sie die Registerkarte Subnetze, und erstellen Sie ein neues Subnetz. Weitere Informationen zu den Feldern des Formulars Subnetz hinzufügen finden Sie im Artikel zu virtuellen Netzwerken:
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. Eine umfassende Liste der IP-Adressen und Portabhängigkeiten finden Sie hier.
- Azure Storage
- Azure Key Vault
- Skalierungsgruppen für virtuelle Azure-Computer
- Azure-Überwachung
- Microsoft Entra ID
- Azure Security
Als Nächstes wenden wir über die Azure CLI einige spezielle Berechtigungen auf das VNET und das Subnetz an, die für die Cassandra Managed Instance benötigt werden. Verwenden Sie den Befehl az role assignment create, und ersetzen Sie <subscriptionID>, <resourceGroupName> und <vnetName> durch die entsprechenden Werte:
```
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>
```
Hinweis

Die Werte assignee und role im vorherigen Befehl sind feste Dienstprinzipal- bzw. Rollenbezeichner.
Als Nächstes konfigurieren wir Ressourcen für unseren Hybridcluster. Da Sie bereits über einen Cluster verfügen, dient der Clustername hier nur als logische Ressource zum Identifizieren des Namens Ihres vorhandenen Clusters. Achten Sie darauf, dass Sie den Namen Ihres vorhandenen Clusters verwenden, wenn Sie die Variablen clusterName und clusterNameOverride im folgenden Skript definieren.

Außerdem benötigen Sie mindestens die Startknoten aus Ihrem vorhandenen Rechenzentrum und die Gossip-Zertifikate, die für die Knoten-zu-Knoten-Verschlüsselung erforderlich sind. Azure Managed Instance for Apache Cassandra erfordert eine Knoten-zu-Knoten-Verschlüsselung für die Kommunikation zwischen Rechenzentren. Wenn Sie in Ihrem vorhandenen Cluster keine Knoten-zu-Knoten-Verschlüsselung implementiert haben, müssen Sie sie implementieren. Weitere Informationen finden Sie in dieser Dokumentation. Sie müssen den Pfad zum Speicherort der Zertifikate bereitstellen. Jedes Zertifikat sollte im PEM-Format vorliegen, z. B. -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Im Allgemeinen gibt es zwei Möglichkeiten zum Implementieren von Zertifikaten:
1. 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.
2. 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 optional auch die Client-zu-Knoten-Zertifikatauthentifizierung oder die gegenseitige Transport Layer Security (mTLS) implementieren möchten, müssen Sie die Zertifikate im gleichen Format bereitstellen wie beim Erstellen des Hybridclusters. Siehe Azure CLI-Beispiel unten: Die Zertifikate werden im Parameter „--client-certificates“ bereitgestellt. Dadurch 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).

Hinweis

Der Wert der von Ihnen unten angegebenen Variablen delegatedManagementSubnetId stimmt exakt mit dem Wert von --scope überein, den Sie im obigen Befehl angegeben haben:
```
resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster-legal-name'
clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'

# You can override the cluster name if the original name is not legal for an Azure resource:
# overrideClusterName='ClusterNameIllegalForAzureResource'
# the default cassandra version will be v3.11

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
  --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
  # optional - add your existing datacenter's client-to-node certificates (if implemented):
  # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed
```
Hinweis

Wenn Ihr Cluster bereits über Knoten-zu-Knoten- und Client-zu-Knoten-Verschlüsselung verfügt, müssen Sie wissen, wo Ihre vorhandenen Client- und/oder Gossip-SSL-Zertifikate gespeichert werden. Falls Sie sich nicht sicher sind, sollten Sie keytool -list -keystore <keystore-path> -rfc -storepass <password> ausführen können, um die Zertifikate auszugeben.

Führen Sie nach dem Erstellen der Clusterressource den folgenden Befehl aus, um die Details zur Clustereinrichtung anzuzeigen:

resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'

az managed-cassandra cluster show \
   --cluster-name $clusterName \
   --resource-group $resourceGroupName \

Mit dem obigen Befehl werden Informationen zur Umgebung der verwalteten Instanz zurückgegeben. Sie benötigen die Gossip-Zertifikate für die Installation im Vertrauensspeicher für die Knoten in Ihrem vorhandenen Rechenzentrum. Im folgenden Screenshot ist die Ausgabe des vorherigen Befehls und das Format der Zertifikate dargestellt:

Hinweis

Die vom obigen Befehl zurückgegebenen Zertifikate enthalten Zeilenumbrüche, die als Text dargestellt werden, z. B. \r\n. Sie sollten jedes Zertifikat in eine Datei kopieren und formatieren, bevor Sie versuchen, es in den Vertrauensspeicher Ihres vorhandenen Rechenzentrums zu importieren.
Tipp

Kopieren Sie den im obigen Screenshot gezeigten Arraywert gossipCertificates in eine Datei, und verwenden Sie das folgende Bash-Skript (Sie müssen jq für Ihre Plattform herunterladen und installieren), um die Zertifikate zu formatieren und jeweils separate PEM-Dateien zu erstellen.
```
readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
# iterate through the certs array, format each cert, write to a numbered file.
num=0
filename=""
for item in "${cert_array[@]}"; do
  let num=num+1
  filename="cert$num.pem"
  cert=$(jq '.pem' <<< $item)
  echo -e $cert >> $filename
  sed -e 's/^"//' -e 's/"$//' -i $filename
done
```
Erstellen Sie als Nächstes im Hybridcluster ein neues Rechenzentrum. Achten Sie darauf, dass Sie die Variablenwerte durch die Details für Ihren Cluster ersetzen:
```
resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'
dataCenterLocation='eastus2'
virtualMachineSKU='Standard_D8s_v4'
noOfDisksPerNode=4

az managed-cassandra datacenter create \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --data-center-location $dataCenterLocation \
  --delegated-subnet-id $delegatedManagementSubnetId \
  --node-count 9
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false
```
Hinweis

Der Wert für --sku kann aus den folgenden verfügbaren SKUs ausgewählt werden:
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
Beachten Sie auch, dass --availability-zone auf false festgelegt ist. Legen Sie diesen Wert auf true fest, um Verfügbarkeitszonen zu aktivieren. Verfügbarkeitszonen erhöhen die Verfügbarkeits-SLA des Diensts. Ausführlichere Informationen finden Sie hier in den vollständigen SLA-Details.
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.

Führen Sie nach Abschluss der Erstellung des neuen Rechenzentrums den Befehl „datacenter show“ aus, um die zugehörigen Details anzuzeigen:

resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'

az managed-cassandra datacenter show \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName

Mit dem obigen Befehl werden die Startknoten des neuen Rechenzentrums ausgegeben:
Fügen Sie die Startknoten des neuen Rechenzentrums in der Datei cassandra.yaml der Startknotenkonfiguration Ihres vorhandenen Rechenzentrums hinzu. Installieren Sie außerdem die Gossip-Zertifikate der verwalteten Instanz, die Sie zuvor im Vertrauensspeicher für alle Knoten in Ihrem vorhandenen Cluster erfasst haben, mit dem keytool-Befehl für jedes Zertifikat:
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Hinweis

Falls Sie weitere Rechenzentren hinzufügen möchten, können Sie die obigen Schritte wiederholen, aber Sie benötigen hierfür nur die Startknoten.

Wichtig

Wenn Ihr vorhandener Apache Cassandra-Cluster nur über ein einzelnes Rechenzentrum verfügt und dies das erste Mal ist, dass ein Rechenzentrum hinzugefügt wird, stellen Sie sicher, dass der Parameter endpoint_snitch in cassandra.yaml auf GossipingPropertyFileSnitch festgelegt ist.

Wichtig

Wenn Ihr vorhandener Anwendungscode QUORUM für die Konsistenz verwendet, sollten Sie dies sicherstellen, bevor Sie die Replikationseinstellungen im folgenden Schritt ändern. Ihr vorhandener Anwendungscode verwendet LOCAL_QUORUMfür die Verbindung zu Ihrem vorhandenen Cluster (andernfalls schlagen Live-Aktualisierungen fehl, nachdem Sie die Replikationseinstellungen im folgenden Schritt geändert haben). Sobald die Replikationsstrategie geändert wurde, können Sie zu QUORUM zurückkehren, wenn Sie dies wünschen.
Verwenden Sie abschließend die folgende CQL-Abfrage, um die Replikationsstrategie in den einzelnen Keyspaces so zu aktualisieren, dass alle Rechenzentren des gesamten Clusters eingebunden sind:
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
```
Sie müssen auch mehrere Systemtabellen aktualisieren:
```
ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
```
Wichtig

Wenn das/die Rechenzentrum(e) in Ihrem bestehenden Cluster keine Client-zu-Knoten-Verschlüsselung (SSL) erzwingt/erzwingen und Sie beabsichtigen, dass sich Ihr Anwendungscode direkt mit der Cassandra Managed Instance verbindet, müssen Sie in Ihrem Anwendungscode ebenfalls SSL aktivieren.

Verwenden Sie hybride Cluster für die Echtzeit-Migration

Die obigen Anweisungen dienen als Anleitung für die Konfiguration eines Hybrid-Clusters. Dies ist jedoch auch eine gute Möglichkeit, eine nahtlose Migration ohne Ausfallzeiten zu erreichen. Wenn Sie eine lokale oder andere Cassandra-Umgebung haben, die Sie ohne Ausfallzeiten stilllegen möchten, um Ihre Arbeitslast in Azure Managed Instance for Apache Cassandra auszuführen, müssen die folgenden Schritte in dieser Reihenfolge ausgeführt werden:

Konfigurieren Sie den Hybrid-Cluster - folgen Sie den obigen Anweisungen.
Deaktivieren Sie vorübergehend automatische Reparaturen in Azure Managed Instance für Apache Cassandra für die Dauer der Migration:
```
az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled false
```
Führen Sie in Azure CLI den unten angegebenen Befehl aus, um auf jedem Knoten in Ihrem neuen Azure Managed Instance for Apache Cassandra-Rechenzentrum nodetool rebuild auszuführen, indem Sie <ip address> durch die IP-Adresse des Knotens ersetzen und <sourcedc> durch den Namen Ihres vorhandenen Rechenzentrums (des Rechenzentrums, von dem Sie migrieren):
```
az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
```
Dies sollte erst ausgeführt werden, nachdem Sie alle oben genannten Schritte durchgeführt haben. Dadurch soll sichergestellt werden, dass alle Verlaufsdaten in Ihre neuen Rechenzentren in Azure Managed Instance for Apache Cassandra repliziert werden. Sie können einen oder mehrere Knoten zugleich neu erstellen. Führen Sie den Befehl auf jeweils einem Knoten aus, um die Auswirkungen auf den vorhandenen Cluster zu verringern. Führen Sie den Befehl auf mehrere Knoten aus, wenn der Cluster den zusätzlichen E/A- und Netzwerkdruck verarbeiten kann. Bei den meisten Installationen können Sie nur einen oder zwei parallel laufen lassen, um den Cluster nicht zu überlasten.
Warnung

Beim Ausführen von nodetool rebuild müssen Sie das Quell-Rechenzentrum angeben. Eine fehlerhafte Angabe des Rechenzentrums beim ersten Versuch führt dazu, dass Tokenbereiche kopiert werden, ohne dass Daten für andere als Systemtabellen kopiert werden. Nachfolgende Versuche schlagen dann fehl, auch wenn Sie das Rechenzentrum ordnungsgemäß angeben. Sie können dies beheben, indem Sie Einträge für jeden nicht systemeigenen Schlüsselbereich in system.available_ranges mithilfe des cqlsh-Abfragetools in Ihrem Cassandra MI-Zielrechenzentrum löschen:
```
delete from system.available_ranges where keyspace_name = 'myKeyspace';
```
Überarbeiten Sie Ihren Anwendungscode, um auf die Seed-Knoten in Ihrem neuen Azure Managed Instance for Apache Cassandra-Rechenzentrum zu verweisen.

Wichtig

Wie auch in den Anweisungen zur Hybrid-Einrichtung erwähnt, müssen Sie, wenn das/die Rechenzentrum(e) in Ihrem bestehenden Cluster keine Client-zu-Knoten-Verschlüsselung (SSL) erzwingen, dies in Ihrem Anwendungscode aktivieren, da Cassandra Managed Instance dies erzwingt.
Führen Sie ALTER KEYSPACE für jeden Keyspace auf die gleiche Weise wie zuvor aus, entfernen Sie aber jetzt Ihr(e) altes(n) Rechenzentrum(e).
Führen Sie nodetool decommission für jeden alten Rechenzentrumsknoten aus.
Stellen Sie Ihren Anwendungscode wieder auf Quorum um (falls erforderlich/bevorzugt).

Aktivieren Sie die automatische Reparatur wieder:

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled true

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.

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.

Nächste Schritte

In dieser Schnellstartanleitung wurde beschrieben, wie Sie mit der Azure CLI und Azure Managed Instance for Apache Cassandra einen Hybridcluster erstellen. Sie können nun mit der Nutzung des Clusters beginnen.

Verwalten von Azure Managed Instance for Apache Cassandra-Ressourcen mit der Azure CLI

Share via