Szybki start: konfigurowanie klastra hybrydowego przy użyciu usługi Azure Managed Instance dla platformy Apache Cassandra

Usługa Azure Managed Instance for Apache Cassandra udostępnia zautomatyzowane operacje wdrażania i skalowania dla zarządzanych centrów danych Apache Cassandra typu open source. Ta usługa pomaga przyspieszyć scenariusze hybrydowe i zmniejszyć ciągłą konserwację.

W tym przewodniku Szybki start pokazano, jak skonfigurować klaster hybrydowy za pomocą poleceń interfejsu wiersza polecenia platformy Azure. Jeśli masz istniejące centra danych w środowisku lokalnym lub własnym, możesz użyć usługi Azure Managed Instance for Apache Cassandra, aby dodać inne centra danych do tego klastra i je obsługiwać.

Wymagania wstępne

  • Ten artykuł wymaga interfejsu wiersza polecenia platformy Azure w wersji 2.30.0 lub nowszej. Jeśli używasz usługi Azure Cloud Shell, najnowsza wersja jest już zainstalowana.

  • Usługa Azure Virtual Network z łącznością z własnym środowiskiem lub środowiskiem lokalnym. Aby uzyskać więcej informacji na temat łączenia środowisk lokalnych z platformą Azure, zobacz artykuł Łączenie sieci lokalnej z platformą Azure .

Konfigurowanie klastra hybrydowego

  1. Zaloguj się do Azure Portal i przejdź do zasobu Virtual Network.

  2. Otwórz kartę Podsieci i utwórz nową podsieć. Aby dowiedzieć się więcej o polach w formularzu Dodawanie podsieci, zobacz artykuł Virtual Network:

    Dodaj nową podsieć do Virtual Network.

    Uwaga

    Wdrożenie wystąpienia zarządzanego platformy Azure dla systemu Apache Cassandra wymaga dostępu do Internetu. Wdrażanie kończy się niepowodzeniem w środowiskach, w których dostęp do Internetu jest ograniczony. Upewnij się, że nie blokujesz dostępu w sieci wirtualnej do następujących ważnych usług platformy Azure, które są niezbędne do prawidłowego działania zarządzanej bazy danych Cassandra. Możesz również znaleźć obszerną listę zależności adresów IP i portów tutaj.

    • Azure Storage
    • Azure KeyVault
    • Azure Virtual Machine Scale Sets
    • Monitorowanie platformy Azure
    • Azure Active Directory
    • Zabezpieczenia platformy Azure
  3. Teraz zastosujemy specjalne uprawnienia do sieci wirtualnej i podsieci, której wymaga wystąpienie zarządzane Cassandra przy użyciu interfejsu wiersza polecenia platformy Azure. az role assignment create Użyj polecenia , zastępując wartości <subscriptionID>, <resourceGroupName>i <vnetName> odpowiednimi wartościami:

    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>
    

    Uwaga

    Wartości assignee i role w poprzednim poleceniu to odpowiednio stała zasada usługi i identyfikatory roli.

  4. Następnie skonfigurujemy zasoby dla klastra hybrydowego. Ponieważ masz już klaster, nazwa klastra w tym miejscu będzie tylko zasobem logicznym, aby zidentyfikować nazwę istniejącego klastra. Pamiętaj, aby użyć nazwy istniejącego klastra podczas definiowania clusterName zmiennych i clusterNameOverride w poniższym skrycie.

    Potrzebne są również co najmniej węzły początkowe z istniejącego centrum danych oraz certyfikaty plotek wymagane do szyfrowania węzła do węzła. Usługa Azure Managed Instance for Apache Cassandra wymaga szyfrowania węzła do węzła na potrzeby komunikacji między centrami danych. Jeśli nie masz szyfrowania węzła do węzła zaimplementowanego w istniejącym klastrze, musisz go zaimplementować — zapoznaj się z dokumentacją tutaj. Należy podać ścieżkę do lokalizacji certyfikatów. Każdy certyfikat powinien mieć format PEM, np. -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Ogólnie rzecz biorąc, istnieją dwa sposoby implementowania certyfikatów:

    1. Certyfikaty z podpisem własnym. Oznacza to, że certyfikat prywatny i publiczny (bez urzędu certyfikacji) dla każdego węzła — w tym przypadku potrzebujemy wszystkich certyfikatów publicznych.

    2. Certyfikaty podpisane przez urząd certyfikacji. Może to być urząd certyfikacji z podpisem własnym, a nawet publiczny. W takim przypadku potrzebujemy certyfikatu głównego urzędu certyfikacji (zapoznaj się z instrukcjami dotyczącymi przygotowywania certyfikatów SSL do produkcji) i wszystkich pośredników (jeśli ma to zastosowanie).

    Opcjonalnie, jeśli zaimplementowano również certyfikaty klient-węzeł (zobacz tutaj), należy również podać je w tym samym formacie podczas tworzenia klastra hybrydowego. Zobacz przykład poniżej.

    Uwaga

    Wartość podanej delegatedManagementSubnetId poniżej zmiennej jest dokładnie taka sama jak wartość --scope podanej w powyższym poleceniu:

    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
    

    Uwaga

    Jeśli klaster ma już szyfrowanie node-to-node i client-to-node, należy wiedzieć, gdzie przechowywane są istniejące certyfikaty SSL klienta i/lub plotek. Jeśli nie masz pewności, należy uruchomić polecenie keytool -list -keystore <keystore-path> -rfc -storepass <password> , aby wydrukować certyfikaty.

  5. Po utworzeniu zasobu klastra uruchom następujące polecenie, aby uzyskać szczegóły konfiguracji klastra:

    resourceGroupName='MyResourceGroup'
    clusterName='cassandra-hybrid-cluster'
    
    az managed-cassandra cluster show \
       --cluster-name $clusterName \
       --resource-group $resourceGroupName \
    
  6. Poprzednie polecenie zwraca informacje o środowisku wystąpienia zarządzanego. Potrzebne będą certyfikaty plotek, aby można je było zainstalować w magazynie zaufania dla węzłów w istniejącym centrum danych. Poniższy zrzut ekranu przedstawia dane wyjściowe poprzedniego polecenia i format certyfikatów:

    Pobierz szczegóły certyfikatu z klastra.

    Uwaga

    Certyfikaty zwrócone z powyższego polecenia zawierają podziały wierszy reprezentowane jako tekst, na przykład \r\n. Należy skopiować każdy certyfikat do pliku i sformatować go przed próbą zaimportowania go do istniejącego magazynu zaufania centrum danych.

    Porada

    gossipCertificates Skopiuj wartość tablicy pokazaną na powyższym zrzucie ekranu do pliku i użyj następującego skryptu powłoki bash (musisz pobrać i zainstalować środowisko jq dla danej platformy), aby sformatować certyfikaty i utworzyć oddzielne pliki pem dla każdej z nich.

    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 '1d' -e '$d' -i $filename
    done
    
  7. Następnie utwórz nowe centrum danych w klastrze hybrydowym. Pamiętaj, aby zastąpić wartości zmiennych szczegółami klastra:

    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
    

    Uwaga

    Wartość parametru --sku można wybrać z następujących dostępnych jednostek SKU:

    • Standard_E8s_v4
    • Standard_E16s_v4
    • Standard_E20s_v4
    • Standard_E32s_v4
    • Standardowa_DS13_v2
    • Standardowa_DS14_v2
    • Standard_D8s_v4
    • Standard_D16s_v4
    • Standard_D32s_v4

    Należy również pamiętać, że --availability-zone ustawiono wartość false. Aby włączyć strefy dostępności, ustaw tę wartość na true. Strefy dostępności zwiększają dostępność umowy SLA usługi. Aby uzyskać więcej informacji, zapoznaj się z pełnymi szczegółami umowy SLA tutaj.

    Ostrzeżenie

    Strefy dostępności nie są obsługiwane we wszystkich regionach. Wdrożenia nie powiedzą się, jeśli wybierzesz region, w którym strefy dostępności nie są obsługiwane. Zobacz tutaj , aby zapoznać się z obsługiwanymi regionami. Pomyślne wdrożenie stref dostępności podlega również dostępności zasobów obliczeniowych we wszystkich strefach w danym regionie. Wdrożenia mogą zakończyć się niepowodzeniem, jeśli wybrana jednostka SKU lub pojemność nie jest dostępna we wszystkich strefach.

  8. Teraz, po utworzeniu nowego centrum danych, uruchom polecenie show datacenter, aby wyświetlić jego szczegóły:

    resourceGroupName='MyResourceGroup'
    clusterName='cassandra-hybrid-cluster'
    dataCenterName='dc1'
    
    az managed-cassandra datacenter show \
      --resource-group $resourceGroupName \
      --cluster-name $clusterName \
      --data-center-name $dataCenterName
    
  9. Poprzednie polecenie generuje węzły początkowe nowego centrum danych:

    Pobierz szczegóły centrum danych.

  10. Teraz dodaj węzły inicjacyjne nowego centrum danych do konfiguracji węzła inicjacyjnego istniejącego centrum danych w pliku cassandra.yaml . Zainstaluj certyfikaty programu gossip wystąpienia zarządzanego zebrane wcześniej w magazynie zaufania dla każdego węzła w istniejącym klastrze przy użyciu keytool polecenia dla każdego certyfikatu:

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

    Uwaga

    Jeśli chcesz dodać więcej centrów danych, możesz powtórzyć powyższe kroki, ale potrzebne są tylko węzły początkowe.

    Ważne

    Jeśli istniejący klaster Apache Cassandra ma tylko jedno centrum danych i jest to pierwsze dodanie centrum danych, upewnij się, że endpoint_snitch parametr w cassandra.yaml pliku ma wartość GossipingPropertyFileSnitch.

    Ważne

    Jeśli istniejący kod aplikacji używa kwORUM w celu zapewnienia spójności, przed zmianą ustawień replikacji w poniższym kroku istniejący kod aplikacji używa LOCAL_QUORUM do nawiązania połączenia z istniejącym klastrem (w przeciwnym razie aktualizacje na żywo nie powiedzą się po zmianie ustawień replikacji w poniższym kroku). Po zmianie strategii replikacji możesz przywrócić wartość QUORUM, jeśli jest to preferowane.

  11. Na koniec użyj następującego zapytania CQL, aby zaktualizować strategię replikacji w każdej przestrzeni kluczy, aby uwzględnić wszystkie centra danych w klastrze:

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
    

    Należy również zaktualizować kilka tabel systemowych:

    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}
    

    Ważne

    Jeśli centra danych w istniejącym klastrze nie wymuszają szyfrowania ssl (client-to-node) i zamierzasz połączyć się bezpośrednio z wystąpieniem zarządzanym Cassandra, musisz również włączyć protokół SSL w kodzie aplikacji.

Używanie klastra hybrydowego do migracji w czasie rzeczywistym

Powyższe instrukcje zawierają wskazówki dotyczące konfigurowania klastra hybrydowego. Jest to jednak również doskonały sposób na osiągnięcie bezproblemowej migracji bez przestojów. Jeśli masz lokalne lub inne środowisko Cassandra, które chcesz zlikwidować z zerowym przestojem, na rzecz uruchamiania obciążenia w wystąpieniu zarządzanym platformy Azure dla platformy Apache Cassandra należy wykonać następujące kroki w tej kolejności:

  1. Konfigurowanie klastra hybrydowego — postępuj zgodnie z powyższymi instrukcjami.

  2. Tymczasowo wyłącz automatyczne naprawy w wystąpieniu zarządzanym platformy Azure dla rozwiązania Apache Cassandra przez czas trwania migracji:

        az managed-cassandra cluster update --cluster-name --resource-group--repair-enabled false
    
  3. Uruchom polecenie nodetool repair --full na każdym węźle w centrum danych istniejącego klastra. Należy to uruchomić dopiero po wykonaniu wszystkich poprzednich kroków. Powinno to zapewnić, że wszystkie dane historyczne są replikowane do nowych centrów danych w usłudze Azure Managed Instance for Apache Cassandra. W przypadku większości instalacji można uruchomić tylko jeden lub dwa równolegle, aby nie przeciążyć klastra. Można monitorować konkretny przebieg naprawy, sprawdzając nodetool netsats i nodetool compactionstats względem określonego węzła. Jeśli masz bardzo dużą ilość danych w istniejącym klastrze, może być konieczne uruchomienie napraw na poziomie przestrzeni kluczy lub nawet na poziomie tabeli — zobacz tutaj , aby uzyskać więcej informacji na temat uruchamiania napraw w systemie Cassandra.

    Uwaga

    Aby przyspieszyć naprawy, zalecamy (jeśli obciążenie systemu zezwala na to) w celu zwiększenia przepływności strumienia i zwartej przepływności, jak w poniższym przykładzie:

      az managed-cassandra cluster invoke-command --resource-group $resourceGroupName --cluster-name $clusterName --host $host --command-name nodetool --arguments "setstreamthroughput"="" "7000"=""
       
      az managed-cassandra cluster invoke-command --resource-group $resourceGroupName --cluster-name $clusterName --host $host --command-name nodetool --arguments "setcompactionthroughput"="" "960"=""
    
  4. Przekroj kod aplikacji, aby wskazać węzły początkowe w nowym wystąpieniu zarządzanym platformy Azure dla centrów danych Apache Cassandra.

    Ważne

    Jak wspomniano również w instrukcjach konfiguracji hybrydowej, jeśli centra danych w istniejącym klastrze nie wymuszają szyfrowania klient-węzeł (SSL), należy włączyć to w kodzie aplikacji, ponieważ wystąpienie zarządzane Cassandra wymusza to.

  5. Uruchom ponownie naprawę narzędzia nodetool we wszystkich węzłach w centrum danych istniejącego klastra, w taki sam sposób jak w kroku 3 powyżej (aby upewnić się, że wszystkie różnice są replikowane po wycięciu aplikacji).

  6. Uruchom polecenie ALTER KEYSPACE dla każdej przestrzeni kluczy w taki sam sposób, jak wcześniej, ale teraz usuń stare centra danych.

  7. Uruchom likwidację narzędzia NodeTool dla każdego starego węzła centrum danych.

  8. Przełącz kod aplikacji z powrotem do kworum (jeśli jest to wymagane/preferowane).

  9. Ponowne włączanie automatycznych napraw:

        az managed-cassandra cluster update --cluster-name --resource-group--repair-enabled true
    

Rozwiązywanie problemów

Jeśli wystąpi błąd podczas stosowania uprawnień do Virtual Network przy użyciu interfejsu wiersza polecenia platformy Azure, takiego jak Nie można odnaleźć użytkownika lub jednostki usługi w bazie danych grafów dla elementu "e5007d2c-4b13-4a74-9b6a-605d999f03501", możesz zastosować to samo uprawnienie ręcznie z Azure Portal. Dowiedz się, jak to zrobić tutaj.

Uwaga

Przypisanie roli usługi Azure Cosmos DB jest używane tylko do celów wdrażania. Wystąpienie zarządzane platformy Azure dla usługi Apache Cassandra nie ma zależności zaplecza w usłudze Azure Cosmos DB.

Czyszczenie zasobów

Jeśli nie zamierzasz nadal korzystać z tego klastra wystąpień zarządzanych, usuń go, wykonując następujące czynności:

  1. W menu po lewej stronie Azure Portal wybierz pozycję Grupy zasobów.
  2. Z listy wybierz grupę zasobów utworzoną na potrzeby tego przewodnika Szybki start.
  3. W okienku Przegląd grupy zasobów wybierz pozycję Usuń grupę zasobów.
  4. W następnym oknie wprowadź nazwę grupy zasobów do usunięcia, a następnie wybierz pozycję Usuń.

Następne kroki

W tym przewodniku Szybki start przedstawiono sposób tworzenia klastra hybrydowego przy użyciu interfejsu wiersza polecenia platformy Azure i wystąpienia zarządzanego platformy Azure dla platformy Apache Cassandra. Teraz możesz rozpocząć pracę z klastrem.