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

[アーティクル]
11/15/2023

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

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

前提条件

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンスコマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
- ローカルインストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、Azure CLI でのサインインに関するページを参照してください。
- 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

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

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

Azure portal にサインインし、仮想ネットワークリソースに移動します。
[サブネット] タブを開いて新しいサブネットを作成します。 [サブネットの追加] フォームにあるフィールドの詳細については、仮想ネットワークに関する記事を参照してください。
Note

Azure Managed Instance for Apache Cassandra をデプロイするには、インターネットへのアクセスが必要です。インターネットへのアクセスが制限されている環境では、デプロイは失敗します。 Managed Cassandra が適切に機能するために必要な、次の重要な Azure サービスへのアクセスが VNet 内でブロックされていないことを確認します。 IP アドレスとポートの依存関係の広範な一覧をこちらで確認することもできます。
- Azure Storage
- Azure KeyVault
- Azure 仮想マシンスケールセット
- Azure 監視
- Microsoft Entra ID
- Azure Security
次に Azure CLI を使用して、Cassandra Managed Instance に必要ないくつかの特殊なアクセス許可を VNet とサブネットに適用します。 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 値は、それぞれ固定されたサービスプリンシパルとロール識別子です。
次に、ハイブリッドクラスターのリソースを構成します。既にクラスターはあるので、ここでのクラスター名は、既存のクラスターの名前を識別するための論理リソースにすぎません。以下のスクリプトで clusterName および clusterNameOverride 変数を定義する際は、必ず既存のクラスターの名前を使用してください。

また、少なくとも、既存のデータセンターのシードノードと、ノード間の暗号化に必要な gossip 証明書も必要です。 Azure Managed Instance for Apache Cassandra では、データセンター間の通信にノード間暗号化が必要になります。既存のクラスターにノード間暗号化が実装されていない場合は、それを実装する必要があります。こちらのドキュメントを参照してください。証明書の場所へのパスを指定する必要があります。各証明書は、PEM 形式にする必要があります (例: -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----)。一般に、証明書を実装するには、次の 2 つの方法があります。
1. 自己署名証明書。これは、各ノードのプライベートおよびパブリック (CA なし) 証明書を意味します。この場合は、すべてのパブリック証明書が必要になります。
2. CA によって署名された証明書。これは、自己署名 CA でも、パブリック CA でもかまいません。この場合は、ルート CA 証明書 (Preparing SSL certificates for production の手順を参照) と、すべての中継局 (該当する場合) が必要になります。
必要に応じて、クライアントからノードへの証明書認証または相互トランスポート層セキュリティ (mTLS) も実装する場合は、ハイブリッドクラスターを作成するときと同じ形式で証明書を指定する必要があります。以下の Azure CLI サンプルを参照 - 証明書は --client-certificates パラメーターで提供されています。これにより、Cassandra Managed Instance クラスターのトラストストアにクライアント証明書がアップロードされて適用されます (つまり、cassandra.yaml 設定を編集する必要はありません)。適用されると、クラスターでは、クライアントの接続時に証明書を検証するための Cassandra が必要になります (Cassandra client_encryption_options の require_client_auth: true を参照)。

Note

以下で指定する 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 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
```
Note

クラスターにノード間およびクライアントからノードへの暗号化が既に存在する場合は、既存のクライアントおよび gossip SSL 証明書が保持されている場所がわかっている必要があります。わからない場合は、keytool -list -keystore <keystore-path> -rfc -storepass <password> を実行して証明書を出力することができます。

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

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

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

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

Note

上記のコマンドから返される証明書には、テキストとして表される改行が含まれています (例: \r\n)。各証明書を既存のデータセンターの信頼ストアにインポートする前に、それをファイルにコピーして書式設定する必要があります。
ヒント

上記のスクリーンショットに示されている gossipCertificates 配列値をファイルにコピーして、以下の bash スクリプト (お使いのプラットフォーム用の jq をダウンロードしてインストールする必要があります) を使用して、証明書の書式を設定し、それぞれに個別の pem ファイルを作成します。
```
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
```
次に、ハイブリッドクラスターに新しいデータセンターを作成します。変数の値は、実際のクラスターの情報に置き換えてください。
```
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
```
Note

--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 の詳細に関するこちらを参照してください。
警告

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

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

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

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

前のコマンドによって、新しいデータセンターのシードノードが出力されます。
ここで、新しいデータセンターのシードノードを 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 に戻すことができます。
最後に、次の 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 Managed Instance に直接接続することを意図している場合は、アプリケーションコードで SSL を有効にする必要もあります。

リアルタイム移行にハイブリッドクラスターを使用する

上記の手順では、ハイブリッドクラスターの構成に関するガイダンスを提供しました。ただし、これはシームレスなダウンタイムなしの移行を実現する優れた方法でもあります。 Azure Managed Instance for Apache Cassandra でワークロードを実行するために、オンプレミス環境または他の Cassandra 環境の使用をダウンタイムなしで停止したい場合は、次の手順をこの順序で行う必要があります。

上記の手順に従って、ハイブリッドクラスターを構成します。

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

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

Azure CLI で、次のコマンドを実行して、新しい Azure Managed Instance for Apache Cassandra データセンターの各ノードで nodetool rebuild を実行し、ノードの IP アドレスと既存のデータセンターの名前 (移行元のデータセンター) を <ip address> と <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';
```
アプリケーションコードをカットオーバーして、新しい Azure Managed Instance for Apache Cassandra データセンターのシードノードを指すようにします。

重要

ハイブリッドセットアップ手順でも説明したように、既存のクラスターのデータセンターでクライアントからノードへの暗号化 (SSL) が適用されていない場合は、Cassandra Managed Instance がこれを強制するため、アプリケーションコードでこれを有効にする必要があります。
前に行ったのと同じ方法で、各キースペースに ALTER KEYSPACE を実行します。ただし、ここでは古いデータセンターを削除します。
古いデータセンターの各ノードに対して nodetool decommission を実行します。
アプリケーションコードをクォーラムに戻します (必要な場合、またはその方がよい場合)。

自動修復をもう一度有効にします。

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

トラブルシューティング

Azure CLI を使用して Virtual Network にアクセス許可を適用するときにエラー ("Cannot find user or service principal in graph database for 'e5007d2c-4b13-4a74-9b6a-605d99f03501' ('e5007d2c-4b13-4a74-9b6a-605d99f03501' に対するユーザーまたはサービスプリンシパルがグラフデータベース内で見つかりません) " など) が発生した場合、Azure portal から同じアクセス許可を手動で適用できます。この方法についてはこちらを参照してください。

注意

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

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

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

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

次のステップ

このクイックスタートでは、Azure CLI と Azure Managed Instance for Apache Cassandra を使用してハイブリッドクラスターを作成する方法を説明しました。これで、クラスターの操作を開始できます。

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

Share via

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

前提条件

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

リアルタイム移行にハイブリッドクラスターを使用する

トラブルシューティング

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

次のステップ

その他のリソース

Share via

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

前提条件

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

リアルタイム移行にハイブリッド クラスターを使用する

トラブルシューティング

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

次のステップ

その他のリソース

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

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

リアルタイム移行にハイブリッドクラスターを使用する