次の方法で共有

クイックスタート: 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 Virtual Network。 オンプレミス環境を Azure に接続する方法の詳細については、「 オンプレミス ネットワークを Azure に接続する」を参照してください。

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

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

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

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

    注意

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

    • Azure Storage
    • Azure KeyVault
    • Azure 仮想マシン スケール セット
    • Azure 監視
    • マイクロソフト エントラ ID
    • Azure セキュリティ

  3. Azure CLI を使用して、Cassandra Managed Instance に必要な仮想ネットワークとサブネットにいくつかの特別なアクセス許可を適用します。 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 変数を定義する際は、必ず既存のクラスターの名前を使用してください。

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

    • 自己署名証明書。 各ノードのプライベート証明書とパブリック証明書 (CA なし)。 この場合は、すべてのパブリック証明書が必要です。

    • CA によって署名された証明書。 この証明書は、自己署名 CA でも、パブリック証明書でもかまいません。 この場合は、ルート CA 証明書とすべての中継局 (該当する場合) が必要です。 詳細については、 実稼働用の SSL 証明書の準備を参照してください。

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

    この方法では、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

    注意

    クラスターにノード間およびクライアントからノードへの暗号化が既に存在する場合は、既存のクライアントおよび gossip 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 の値は、次の使用可能な 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 リージョンの一覧を参照してください。

    可用性ゾーンの正常なデプロイは、特定のリージョン内のすべてのゾーンでコンピューティング リソースが使用可能であることにも左右されます。 選択した SKU または容量がすべてのゾーンで使用できない場合、デプロイが失敗する可能性があります。

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

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

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

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

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

  10. cassandra.yaml ファイル内の既存のデータセンターのシード ノード構成に、新しいデータセンターのシード ノードを追加します。 前に収集したマネージド インスタンスの gossip 証明書を、証明書ごとに 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 に戻すことができます。

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

    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) が適用されておらず、アプリケーション コードが Cassandra マネージド インスタンスに直接接続する場合は、アプリケーション コードで 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 の新しいデータ センターにレプリケートされるようにする必要があります。 1 つ以上のノードでリビルドを同時に実行できます。 既存のクラスターへの影響を軽減するために、一度に 1 つのノードで実行します。 クラスターが追加の I/O とネットワーク負荷を処理できる場合は、複数のノードで実行します。 ほとんどのインストールでは、クラスターをオーバーロードしないように並列で 1 つまたは 2 つしか実行できません。

    警告

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

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

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

    重要

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

  5. 前の手順と同じ方法で各キースペースに対して ALTER KEYSPACE を実行しますが、古いデータ センターは削除します。

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

  7. 必要に応じて、または希望する場合は、アプリケーションコードをクォーラムに戻します。

  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 Instance for Apache Cassandra には、Azure Cosmos DB に対するバックエンドの依存関係はありません。

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

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

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

次のステップ

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