次の方法で共有

クイックスタート: Azure Managed Instance for Apache Cassandra を使用してハイブリッド クラスターを構成する

Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 また、このサービスを使用すると、各ワークロードの特定のニーズに応じて構成をオーバーライドして、柔軟性と制御を最大限に高めることができます。

このクイックスタートでは、Azure CLI のコマンドを使用してハイブリッド クラスターを構成する方法について説明します。 オンプレミスまたはセルフホステッド環境に既存のデータセンターがある場合は、Azure Managed Instance for Apache Cassandra を使用して、それらのクラスターに他のデータセンターを追加し、維持することができます。

前提条件

  • Azure Cloud Shell で Bash 環境を使用します。 詳細については、「Azure Cloud Shell の概要」を参照してください。

  • CLI リファレンス コマンドをローカル環境で実行したい場合は、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。 詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。

    • ローカル インストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 その他のサインイン オプションについては、「 Azure CLI を使用した Azure への認証」を参照してください。

    • 初回使用時に求められたら、Azure CLI 拡張機能をインストールします。 拡張機能の詳細については、「Azure CLI で拡張機能を使用および管理する」を参照してください。

    • インストールされているバージョンと依存ライブラリを調べるには、az version を実行します。 最新バージョンにアップグレードするには、az upgrade を実行します。

  • この記事では、Azure CLI バージョン 2.30.0 以降が必要です。 Azure Cloud Shell を使用している場合は、最新バージョンが既にインストールされています。
  • セルフホステッド環境またはオンプレミス環境への接続で Azure 仮想ネットワーク を使用します。 オンプレミス環境を Azure に接続する方法の詳細については、「オンプレミス ネットワークを Azure に接続する」を参照してください。

ハイブリッド クラスターを構成する

  1. Azure portal にサインインし、仮想ネットワーク リソースに移動します。

  2. [サブネット] タブ を 選択し、新しいサブネットを作成します。 [ サブネットの追加 ] フォームのフィールドの詳細については、「サブネットの 追加」を参照してください。

    仮想ネットワークにオプトインして新しいサブネットを追加するオプションを示すスクリーンショット。

    Azure Managed Instance for Apache Cassandra のデプロイには、インターネット アクセスが必要です。 インターネットへのアクセスが制限されている環境では、デプロイは失敗します。 Azure Managed Instance for Apache Cassandra が正常に動作するために必要な次の重要な Azure サービスへの仮想ネットワーク内のアクセスをブロックしていないことを確認します。 IP アドレスとポートの依存関係の一覧については、「 必要な送信ネットワーク規則」を参照してください。

    • Azure Storage
    • Azure Key Vault
    • Azure 仮想マシン スケール セット
    • Azure Monitor
    • Microsoft Entra ID
    • Microsoft Defender for Cloud

  3. Azure CLI を使用して、Azure Managed Instance for Apache Cassandra に必要な仮想ネットワークとサブネットにいくつかの特別なアクセス許可を適用します。 az role assignment create コマンドを使用します。 <subscriptionID>、<resourceGroupName>、および<vnetName>を適切な値に置き換えます。

    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>

    前のコマンドの assignee と role の値はそれぞれ、固定サービス プリンシパルとロール識別子です。

  4. ハイブリッド クラスターのリソースを構成します。 クラスターは既に存在するため、クラスター名は既存のクラスターの名前を識別するための論理リソースです。 次のスクリプトで clusterName 変数と clusterNameOverride 変数を定義するときは、既存のクラスターの名前を使用します。

    また、少なくとも、既存のデータセンターからのシード ノードと、ノード間の暗号化に必要なゴシップ証明書も必要です。 Azure Managed Instance for Apache Cassandra では、データセンター間の通信にノード間暗号化が必要になります。 ノード間暗号化が既存のクラスターに実装されていない場合は、それを実装する必要があります。 詳細については、「 ノード間暗号化」を参照してください。 証明書の場所へのパスを指定します。 各証明書は、 -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----など、プライバシー強化メール (PEM) 形式である必要があります。 一般に、証明書を実装する方法は 2 つあります。

    • 自己署名証明書。 ノードごとに証明機関 (CA) のないプライベート証明書とパブリック証明書。 この場合は、すべてのパブリック証明書が必要です。
    • CA によって署名された証明書。 自己署名 CA またはパブリック CA によって発行された証明書。 この場合は、ルート CA 証明書とすべての中継局 (該当する場合) が必要です。 詳細については、「 運用環境用に Secure Sockets Layer (SSL) 証明書を準備する」を参照してください。

    必要に応じて、クライアントからノードへの証明書認証または相互トランスポート層セキュリティ (TLS) を実装する場合は、ハイブリッド クラスターを作成したときと同じ形式で証明書を指定します。 この記事の後半の Azure CLI サンプルを参照してください。 証明書は、 --client-certificates パラメーターで指定されます。

    この方法では、クライアント証明書がアップロードされ、Azure Managed Instance for Apache Cassandra クラスターの信頼ストアに適用されます。 cassandra.yaml設定を編集する必要はありません。 証明書が適用された後、クラスターでは、クライアントが接続するときに Cassandra に証明書を検証する必要があります。 詳細については、Cassandra client_encryption_optionsのrequire_client_auth: trueを参照してください。

    このコードで指定する delegatedManagementSubnetId 変数の値は、前のコマンドで指定した --scope の値と同じです。

    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

    クラスターにノード間暗号化とクライアント対ノード暗号化が既にある場合は、既存のクライアントまたはゴシップ TLS/SSL 証明書が保持されている場所を把握しておく必要があります。 不明な場合は、 keytool -list -keystore <keystore-path> -rfc -storepass <password> を実行して証明書を印刷します。

  5. クラスター リソースが作成されたら、次のコマンドを実行してクラスターのセットアップの詳細を取得します。

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

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

  6. 前のコマンドを実行すると、マネージド インスタンス環境に関する情報が返されます。 gossip 証明書は、既存のデータセンター内のノードの信頼ストアにインストールするために必要となります。 次のスクリーンショットは、前のコマンドの出力と証明書の形式を示しています。

    クラスターから証明書の詳細を取得した結果を示すスクリーンショット。

    上記のコマンドから返される証明書には、テキストとして表される改行が含まれています。 たとえば \r\n です。 既存の信頼ストアにインポートする前に、各証明書をファイルにコピーして書式設定します。

    スクリーンショットに示されている gossipCertificates 配列値をファイルにコピーします。 次の Bash スクリプトを使用して証明書をフォーマットし、それぞれに個別の PEM ファイルを作成します。 Bash スクリプトをダウンロードするには、プラットフォームの ダウンロード jq を参照してください。

    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. 次に、ハイブリッド クラスターに新しいデータセンターを作成します。 変数の値をクラスターの詳細に置き換えます。

    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

    次の利用可能な製品レベルから --sku の値を選択します。

    • 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

    --availability-zoneの値はfalseに設定されます。 可用性ゾーンを有効にするには、この値を true に設定します。 可用性ゾーンにより、サービスの可用性サービス レベル アグリーメント (SLA) が向上します。 詳細については、 オンライン サービスの SLA を参照してください。

    可用性ゾーンは、すべてのリージョンでサポートされているわけではありません。 可用性ゾーンがサポートされていないリージョンを選択すると、デプロイは失敗します。 サポートされているリージョンについては、 Azure リージョンの一覧を参照してください。

    可用性ゾーンが正常にデプロイされた場合、特定のリージョン内のすべてのゾーンでコンピューティング リソースが利用できるかどうかも影響を受けます。 選択した製品レベル (容量) がすべてのゾーンで使用できない場合、デプロイが失敗する可能性があります。

  8. 新しいデータセンターが作成されたら、 datacenter show コマンドを実行してその詳細を表示します。

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

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

    前のコマンドは、新しいデータセンターのシード ノードを表示します。

    データセンターの詳細を取得する方法を示すスクリーンショット。

  9. cassandra.yaml ファイル内の既存のデータセンターのシード ノード構成に、新しいデータセンターのシード ノードを追加します。 前に収集したマネージド インスタンスのゴシップ証明書を、既存のクラスター内の各ノードの信頼ストアにインストールします。 各証明書に対して keytool コマンドを使用します。

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

    データセンターをさらに追加する場合は、前の手順を繰り返しますが、必要なのはシード ノードだけです。

    重要

    既存の Apache Cassandra クラスターに 1 つのデータセンターのみが存在し、このデータセンターが最初に追加される場合は、cassandra.yamlの endpoint_snitch パラメーターが GossipingPropertyFileSnitch に設定されていることを確認します。

    既存のアプリケーション コードで一貫性のために QUORUM を使用している場合は、 次の手順でレプリケーション設定を変更する前に、既存のアプリケーション コードがLOCAL_QUORUM 既存のクラスターに接続するために使用していることを確認してください。 それ以外の場合、次の手順でレプリケーション設定を変更した後、ライブ更新は失敗します。 レプリケーション戦略を変更した後は、必要に応じて QUORUM に戻すことができます。

  10. 最後に、次の Cassandra クエリ言語クエリを使用して、クラスター全体のすべてのデータセンターを含むように各キースペースのレプリケーション戦略を更新します。

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

    複数のシステム テーブルを更新する必要もあります。

    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}

    既存のクラスター内のデータセンターで クライアントからノードへの暗号化 (SSL) が適用されておらず、アプリケーション コードが Azure Managed Instance for Apache Cassandra に直接接続する予定の場合は、アプリケーション コードで TLS/SSL も有効にする必要があります。

ハイブリッド クラスターを使用したリアルタイム移行

前の手順では、ハイブリッド クラスターを構成する方法に関するガイダンスを提供します。 このアプローチは、シームレスなダウンタイムなしの移行を実現する優れた方法でもあります。 次の手順では、ダウンタイムをゼロにして、使用停止にするオンプレミスまたはその他の Cassandra 環境を Azure Managed Instance for Apache Cassandra に移行する方法を示します。

  1. ハイブリッド クラスターを構成します。 前の手順に従います。

  2. 移行中に Azure Managed Instance for Apache Cassandra で自動修復を一時的に無効にします。

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

  3. Azure CLI で、次のコマンドを使用して、新しい Azure Managed Instance for Apache Cassandra データセンター内の各ノードで nodetool rebuild を実行します。 <ip address>をノードの IP アドレスに置き換えます。 <sourcedc>を、移行元の既存のデータセンターの名前に置き換えます。

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

    このコマンドは 、前のすべての手順を実行した後にのみ実行します。 この方法では、すべての履歴データが Azure Managed Instance for Apache Cassandra の新しいデータセンターにレプリケートされるようにする必要があります。 rebuildは、1 つ以上のノードで同時に実行できます。 既存のクラスターへの影響を減らすために、一度に 1 つのノードで実行します。 クラスターが追加の I/O とネットワーク負荷を処理できる場合は、複数のノードで実行します。 ほとんどのインストールでは、クラスターをオーバーロードしないように、1 つまたは 2 つの並列実行のみを実行できます。

    警告

    nodetool rebuildを実行するときは、ソース data centerを指定する必要があります。 最初の試行でデータセンターを正しく指定しないと、非システム テーブルのデータがコピーされずにトークン範囲がコピーされます。 データセンターを正しく指定した場合でも、後続の試行は失敗します。 この問題を解決するには、ターゲットの Azure Managed Instance for Apache Cassandra データセンターの cqlsh クエリ ツールを使用して、system.available_ranges内の各非システム キースペースのエントリを削除します。

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

  4. アプリケーション コードをカットして、新しい Azure Managed Instance for Apache Cassandra データセンター内のシード ノードを指すようにします。

    ハイブリッド セットアップ手順でも説明したように、既存のクラスター内のデータセンターで クライアントからノードへの暗号化 (SSL) が適用されない場合は、アプリケーション コードでこの機能を有効にします。 Azure Managed Instance for Apache Cassandra では、この要件が適用されます。

  5. 前の手順と同じ方法で、キースペースごとに ALTER KEYSPACE を実行します。 これで、古いデータセンターを削除できます。

  6. 古いデータセンター ノードごとにノード ツールの使用停止 を実行します。

  7. 必要であれば、または望ましい場合は、アプリケーションコードをQUORUMに戻します。

  8. 自動修復を再び可能に:

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

トラブルシューティング

Azure CLI を使用して仮想ネットワークにアクセス許可を適用するときにエラーが発生した場合は、Azure portal から同じアクセス許可を手動で適用できます。 このようなエラーの例として、" e5007d2c-4b13-4a74-9b6a-605d99f03501のグラフ データベースにユーザーまたはサービス プリンシパルが見つかりません" があります。詳細については、「 Azure portal を使用して Azure Cosmos DB サービス プリンシパルを追加する」を参照してください。

Azure Cosmos DB のロールの割り当ては、デプロイの目的にのみ使用されます。 Azure Managed Instanced for Apache Cassandra には、Azure Cosmos DB へのバックエンドの依存関係はありません。

リソースをクリーンアップする

このマネージド インスタンス クラスターを引き続き使用しない場合は、次の手順に従って削除します。

  1. Azure portal の左側のメニューにある [リソース グループ] を選択します。
  2. 一覧から、このクイック スタート用に作成したリソース グループを選択します。
  3. リソース グループの [概要] ペインで、[リソース グループの削除] を選択します。
  4. 次のウィンドウで、削除するリソース グループの名前を入力し、[削除] を選択 します。

次のステップ

Azure CLI を利用して Azure Managed Instance for Apache Cassandra リソースを管理する

  • Last updated on