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

Azure Managed Instance for Apache Cassandra ist ein vollständig verwalteter Service für reine Open-Source Apache Cassandra-Cluster. Der Dienst ermöglicht außerdem, konfigurationen abhängig von den spezifischen Anforderungen jeder Workload außer Kraft zu setzen, um maximale Flexibilität und Kontrolle zu gewährleisten.

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 selbst gehosteten Umgebung verfügen, können Sie azure Managed Instance für Apache Cassandra verwenden, um diesen Clustern weitere Rechenzentren hinzuzufügen und zu verwalten.

Voraussetzungen

• Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter "Erste Schritte mit 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. Um den Authentifizierungsprozess abzuschließen, führen Sie die in Ihrem Terminal angezeigten Schritte aus. Weitere Anmeldeoptionen finden Sie unter Authentifizieren bei Azure mithilfe der Azure CLI.

  • Installieren Sie die Azure CLI-Erweiterung bei der ersten Verwendung, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden und Verwalten 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.

• Dieser Artikel erfordert die Azure CLI-Version 2.30.0 oder höher. Bei Verwendung von Azure Cloud Shell ist die aktuelle Version bereits installiert.
• Verwenden Sie ein virtuelles Azure-Netzwerk mit Konnektivität zu Ihrer selbst gehosteten oder lokalen Umgebung. Weitere Informationen zum Verbinden lokaler Umgebungen mit Azure finden Sie unter Verbinden eines lokalen Netzwerks mit Azure.

Konfigurieren eines Hybridclusters

1. Melden Sie sich beim Azure-Portal an, und wechseln Sie zu Ihrer virtuellen Netzwerkressource.

2. Wählen Sie die Registerkarte "Subnetze " aus, und erstellen Sie ein neues Subnetz. Weitere Informationen zu den Feldern im Formular " Subnetz hinzufügen " finden Sie unter "Subnetz hinzufügen".

   

   Die Bereitstellung von 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 innerhalb Ihres virtuellen Netzwerks nicht auf die folgenden wichtigen Azure-Dienste blockieren, die für die ordnungsgemäße Funktionsweise von Azure Managed Instance für Apache Cassandra erforderlich sind. Eine Liste der IP-Adressen und Portabhängigkeiten finden Sie unter "Erforderliche ausgehende Netzwerkregeln".

   • Azure Storage
   • Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)
   • Skalierungsgruppen für virtuelle Azure-Computer
   • Azure Monitor
   • Microsoft Entra ID
   • Microsoft Defender for Cloud

3. Wenden Sie einige spezielle Berechtigungen auf das virtuelle Netzwerk und das Subnetz an, das azure Managed Instance für Apache Cassandra erfordert, indem Sie die Azure CLI verwenden. Verwenden Sie den Befehl az role assignment create. Ersetzen , <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>
   

   Die Werte assignee und role im vorherigen Befehl sind feste Dienstprinzipal- bzw. Rollenbezeichner.

4. Konfigurieren Sie Ressourcen für Ihren Hybridcluster. Da Sie bereits über einen Cluster verfügen, ist der Clustername eine logische Ressource, um den Namen Ihres vorhandenen Clusters zu identifizieren. Verwenden Sie den Namen Ihres vorhandenen Clusters, wenn Sie die clusterName- und clusterNameOverride-Variablen 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 die Knoten-zu-Knoten-Verschlüsselung in Ihrem vorhandenen Cluster nicht implementiert ist, müssen Sie sie implementieren. Weitere Informationen finden Sie unter Node-to-Node-Verschlüsselung. Geben Sie den Pfad zum Speicherort der Zertifikate an. Jedes Zertifikat sollte im Privacy Enhanced Mail (PEM)-Format vorliegen, zum Beispiel -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Im Allgemeinen gibt es zwei Möglichkeiten zum Implementieren von Zertifikaten:

   • Selbstsignierte Zertifikate. Private und öffentliche Zertifikate ohne Zertifizierungsstelle (Ca) für jeden Knoten. In diesem Fall benötigen Sie alle öffentlichen Zertifikate.
   • Von einer Zertifizierungsstelle signierte Zertifikate. Zertifikate, die von einer selbstsignierten Zertifizierungsstelle oder einer öffentlichen Zertifizierungsstelle ausgestellt wurden. In diesem Fall benötigen Sie das Root-Zertifikat der CA und, sofern zutreffend, alle Zwischenzertifikate. Weitere Informationen finden Sie unter Vorbereiten von SSL-Zertifikaten (Secure Sockets Layer) für die Produktion.

   Wenn Sie optional die Client-zu-Knoten-Zertifikatauthentifizierung oder tls (Mutual Transport Layer Security) implementieren möchten, stellen Sie die Zertifikate im gleichen Format bereit wie beim Erstellen des Hybridclusters. Weitere Informationen finden Sie im Azure CLI-Beispiel weiter unten in diesem Artikel. Die Zertifikate werden im --client-certificates Parameter bereitgestellt.

   Dieser Ansatz lädt Ihre Clientzertifikate hoch und wendet sie auf den Vertrauensspeicher für Ihre azure Managed Instance für Apache Cassandra Cluster an. Sie müssen keine Einstellungen bearbeiten cassandra.yaml . Nachdem die Zertifikate angewendet wurden, benötigt der Cluster Cassandra, um die Zertifikate zu überprüfen, wenn ein Client eine Verbindung herstellt. Weitere Informationen finden Sie unter require_client_auth: true Cassandra client_encryption_options.

   Der Wert der delegatedManagementSubnetId Variablen, die Sie in diesem Code angeben, ist identisch mit dem Wert, den --scope Sie in einem früheren 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 isn't 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
   

   Wenn Ihr Cluster bereits über eine Node-zu-Knoten- und Client-zu-Knoten-Verschlüsselung verfügt, sollten Sie wissen, wo Ihr vorhandener Client oder TLS/SSL-Zertifikate gespeichert sind. Wenn Sie unsicher sind, führen Sie den Befehl keytool -list -keystore <keystore-path> -rfc -storepass <password> aus, um die Zertifikate zu drucken.

5. 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 \
   

6. Mit dem obigen Befehl werden Informationen zur Umgebung der verwalteten Instanz zurückgegeben. Sie benötigen die Gossip-Zertifikate, damit Sie sie im Vertrauensspeicher für Knoten in Ihrem vorhandenen Rechenzentrum installieren können. Der folgende Screenshot zeigt die Ausgabe des vorherigen Befehls und des Formats von Zertifikaten.

   

   Die vom vorherigen Befehl zurückgegebenen Zertifikate enthalten Zeilenumbrüche, die als Text dargestellt werden. Beispiel ist \r\n. Kopieren Sie jedes Zertifikat in eine Datei, und formatieren Sie es, bevor Sie versuchen, es in Ihren vorhandenen Vertrauensspeicher zu importieren.

   Kopieren Sie den gossipCertificates Arraywert, der im Screenshot angezeigt wird, in eine Datei. Verwenden Sie das folgende Bash-Skript, um die Zertifikate zu formatieren und jeweils separate PEM-Dateien zu erstellen. Um das Bash-Skript herunterzuladen, sehen Sie unter Download jq für Ihre Plattform nach.

   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
   

7. Erstellen Sie als Nächstes im Hybridcluster ein neues Rechenzentrum. Ersetzen Sie die Variablenwerte durch Ihre Clusterdetails.

   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
   

   Wählen Sie für den Wert für --sku aus den folgenden verfügbaren Produkttarifen aus:

   • 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

   Der Wert für --availability-zone ist auf false gesetzt. Legen Sie diesen Wert auf true fest, um Verfügbarkeitszonen zu aktivieren. Verfügbarkeitszonen erhöhen den Verfügbarkeitsgrad der Service-Level-Vereinbarung (SLA) für den Dienst. Weitere Informationen finden Sie unter SLA für Onlinedienste.

   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. Unterstützte Regionen finden Sie in der Azure-Regionsliste.

   Die erfolgreiche Bereitstellung von Verfügbarkeitszonen unterliegt auch der Verfügbarkeit von Computeressourcen in allen Zonen in der jeweiligen Region. Bereitstellungen können fehlschlagen, wenn die ausgewählte Produktebene oder Kapazität nicht in allen Zonen verfügbar ist.

8. Nachdem das neue Rechenzentrum erstellt wurde, führen Sie den Befehl aus, um seine datacenter show 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
   

   Der vorherige Befehl zeigt die Seedknoten des neuen Rechenzentrums an.

   

9. Fügen Sie die Seedknoten des neuen Rechenzentrums zur Seedknotenkonfiguration Ihres vorhandenen Rechenzentrums in der Datei cassandra.yaml hinzu. Installieren Sie die gossip-Zertifikate der verwalteten Instanz, die Sie zuvor im Vertrauensspeicher für jeden Knoten in Ihrem vorhandenen Cluster gesammelt haben. Verwenden Sie den keytool Befehl für jedes Zertifikat:

   keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
   

   Wenn Sie weitere Rechenzentren hinzufügen möchten, wiederholen Sie die vorherigen Schritte, aber Sie benötigen nur die Seedknoten.

   Wichtig

   Wenn Ihr vorhandener Apache Cassandra-Cluster nur über ein einzelnes Rechenzentrum verfügt und dieses Rechenzentrum als erstes hinzugefügt wurde, stellen Sie sicher, dass der Parameter endpoint_snitch in cassandra.yaml auf GossipingPropertyFileSnitch festgelegt ist.

   Wenn Ihr vorhandener Anwendungscode zur Konsistenz QUORUM verwendet, stellen Sie vor dem Ändern der Replikationseinstellungen im nächsten Schritt sicher, dass Ihr vorhandener Anwendungscode zum Herstellen einer Verbindung mit Ihrem vorhandenen Cluster LOCAL_QUORUM verwendet. Andernfalls schlagen Liveupdates fehl, nachdem Sie die Replikationseinstellungen im folgenden Schritt geändert haben. Nachdem Sie die Replikationsstrategie geändert haben, können Sie bei Bedarf zu QUORUM zurückkehren.

10. Verwenden Sie schließlich die folgende Cassandra Query Language-Abfrage, um die Replikationsstrategie in jedem Schlüsselbereich zu aktualisieren, um alle Rechenzentren im gesamten Cluster einzuschließen:

    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}
    

    Wenn die Rechenzentren in Ihrem vorhandenen Cluster keine Client-zu-Knoten-Verschlüsselung (SSL) erzwingen und Sie beabsichtigen, dass Ihr Anwendungscode eine direkte Verbindung mit Azure Managed Instance für Apache Cassandra herstellt, müssen Sie auch TLS/SSL in Ihrem Anwendungscode aktivieren.

Verwenden eines Hybridclusters für die Echtzeitmigration

Die vorstehenden Anweisungen enthalten Anleitungen zum Konfigurieren eines Hybridclusters. Dieser Ansatz ist auch eine hervorragende Möglichkeit, eine nahtlose Migration ohne Ausfallzeiten zu erreichen. Das folgende Verfahren zeigt Ihnen, wie Sie eine lokale oder andere Cassandra-Umgebung migrieren, die Sie außer Betrieb setzen möchten, mit null Ausfallzeiten, zu Azure Managed Instance für Apache Cassandra.

1. Konfigurieren Sie einen Hybridcluster. Folgen Sie den vorherigen Anweisungen.

2. Deaktivieren Sie während der Migration vorübergehend automatische Reparaturen in azure Managed Instance für Apache Cassandra:

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

3. Verwenden Sie in der Azure CLI den folgenden Befehl, um auf jedem Knoten in Ihrer neuen verwalteten Azure-Instanz für Apache Cassandra-Rechenzentrum auszuführen nodetool rebuild . Ersetzen Sie <ip address> durch die IP-Adresse des Knotens. Ersetzen Sie <sourcedc> durch den Namen Ihres vorhandenen 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>"=""
   

   Führen Sie diesen Befehl erst aus, nachdem Sie alle vorherigen Schritte ausgeführt haben. Dieser Ansatz sollte sicherstellen, dass alle historischen Daten in Ihren neuen Rechenzentren in Azure Managed Instance für Apache Cassandra repliziert werden. Sie können rebuild gleichzeitig auf einem oder mehreren Knoten ausführen. 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 ein oder zwei parallel ausführen, sodass Sie den Cluster nicht überladen.

   Warnung

   Sie müssen die Quelle data center angeben, wenn Sie ausführen nodetool rebuild. Wenn Sie das Rechenzentrum beim ersten Versuch falsch angeben, werden Token-Bereiche kopiert, ohne dass Daten für Ihre Nichtsystemtabellen kopiert werden. Nachfolgende Versuche schlagen fehl, auch wenn Sie das Rechenzentrum ordnungsgemäß bereitstellen. Um dieses Problem zu beheben, löschen Sie Einträge für jeden Nichtsystem-Schlüsselraum in system.available_ranges mithilfe des cqlsh Abfragetools in Ihrer Azure Managed Instance für das Apache Cassandra Datacenter.

   delete from system.available_ranges where keyspace_name = 'myKeyspace';
   

4. Schneiden Sie Ihren Anwendungscode aus, um auf die Seedknoten in Ihrer neuen azure Managed Instance für Apache Cassandra-Rechenzentren zu verweisen.

   Wie auch in den Anweisungen zur Hybrideinrichtung erwähnt, aktivieren Sie dieses Feature in Ihrem Anwendungscode, wenn die Rechenzentren in Ihrem vorhandenen Cluster keine Client-zu-Knoten-Verschlüsselung (SSL) erzwingen. Azure Managed Instance für Apache Cassandra erzwingt diese Anforderung.

5. Führen Sie ALTER KEYSPACE für jeden Schlüsselraum auf die gleiche Weise wie zuvor aus. Jetzt können Sie Ihre alten Rechenzentren entfernen.

6. Führen Sie node tool decommission für jeden alten Knoten des Rechenzentrums aus.

7. Schalten Sie bei Bedarf oder nach Präferenz Ihren Anwendungscode wieder auf QUORUM um.

8. Automatische Reparaturen reaktivieren:

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

Problembehandlung

Wenn beim Anwenden von Berechtigungen für 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 Graphdatenbank 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.

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

Bereinigen von Ressourcen

Wenn Sie diesen verwalteten Instanzcluster nicht weiterhin verwenden werden, führen Sie die folgenden Schritte aus, um ihn zu löschen:

1. Wählen Sie im Azure-Portal im Menü auf der linken Seite die Option Ressourcengruppen aus.
2. Wählen Sie in der Liste die Ressourcengruppe aus, die Sie für diese Schnellstartanleitung erstellt haben.
3. Wählen Sie im Ressourcengruppenbereich Übersicht die Option Ressourcengruppe löschen aus.
4. Geben Sie im nächsten Bereich den Namen der zu löschenden Ressourcengruppe ein, und wählen Sie dann "Löschen" aus.

Nächster Schritt