このドキュメントでは、Cloud Exchangeにおける高可用性（HA）の仕組みについて説明します。アーキテクチャ図の機能一覧、前提条件、およびサイジングガイドラインを確認した後、Cloud Exchange に HA をデプロイします。導入に関するセクションの後には、移行、アップグレード、セキュリティ強化、既知の制限事項、トラブルシューティングについて説明するセクションがあります。
HAアーキテクチャ
Features
- Cloud Exchangeノードのアクティブ/アクティブ構成により、システムの可用性と耐障害性が向上します。
- Cloud Exchange Coreコンテナは、複数のタスクを同時に処理できる専用ワーカーとして機能するように設計されています。中規模のシステムでは10個のタスクを処理でき、大規模なシステムでは20個のタスクを処理できます。これらのタスクには、ポーリング、データ取り込み、心拍数モニタリングなどの操作が含まれる場合があります。3つのノードで構成される高可用性（HA）クラスタでは、処理能力が実質的に3倍になり、システムの実行能力が向上します。
- タスクの割り当てはRabbitMQを介して調整され、RabbitMQはコアコンテナのワーカーの現在の負荷と、ワーカーがアクティブに処理しているタスクの数に基づいて、タスクをワーカーに分配します。コアコンテナの再起動やノード障害が発生した場合、データの損失を防ぐため、変換および取り込みタスクは再キューイングされます。一方、データ取得タスクは、通常、障害発生から5分以内に、新しいノードのワークロードに応じて、別のノードに再割り当てされます。
- 要約すると、コアコンテナは、継続的な運用とデータの整合性を確保するために、タスクレベルとノードレベルの両方で高可用性（HA）を備えるように設計されています。
- クラスター環境では、MongoDBとRabbitMQのインスタンスが複数存在することになります。いずれかのノードがダウンしても、他のノードがリクエストの処理を継続するため、ダウンタイムは発生しません。
- Cloud Exchangeの複数の同一ノードは同時に稼働します。そしてそれら全てが、プラグインのタスクを同時に積極的に処理している。
Cloud Exchange HA の設定方法に関するビデオをご覧になるには、再生ボタンをクリックしてください。
Cloud ExchangeのHAフェイルオーバーの仕組みに関するビデオをご覧になるには、再生ボタンをクリックしてください。
クラスターステータスのUIダッシュボード
Cloud Exchangeのホームページで、現在のクラスタの状態を確認してください。
コアサービスはUIサービスに依存しています。セキュリティ上の理由から、コアサービスは一般公開していません。コアサービスはUIサービスを通じてアクセス可能となり、内部ネットワーク経由でアクセスされます。UIサービスがダウンしている場合、コアはダッシュボードに不明なステータスを表示します。
重要な注意事項
- スタンドアロン構成から高可用性（HA）構成に移行する場合は、メンテナンスパスワードを知っておく必要があります。これは、Mongoデータを新しい構成に移行するために必要となるためです。
- Cloud Exchange VMとして利用している場合は、この点を確認し、ホスト名を適切に変更してください。
すべてのマシンに異なるホスト名を設定してください。このコマンドは、特定のマシンのホスト名を変更します。sudo hostnamectl set-hostname <new_hostname>
- すべての機器が、対象機器自体を含め、下記のポートに接続できることを確認してください。現在のマシンを含める理由は、API呼び出しがサーバーのIPアドレスに対して行われ、API呼び出しがDockerコンテナ内部から行われるためです。したがって、ポートの接続は IPアドレスによって許可される必要があります。 記載されているポートおよびすべてのマシンに対するファイアウォールポリシーは、マシン間のシームレスな接続を確保するように構成する必要があります。
- 4369 (RabbitMQ ノードと CLI ツールによって使用されるピア検出サービス)
- 8000
- 5671 (TLS を使用しない AMQP 0-9-1 および AMQP 1.0 クライアントによって使用される)
- 15671 (TLSを使用しないHTTP APIクライアント、管理UI、およびrabbitmqadmin)
- 25672 (ノード間および CLI ツールの通信に使用)
- 35672 (CLI ツール通信に使用)
- 27017（mongodおよびmongosインスタンスのデフォルトポート）
- 選択されたUIポート（デフォルトはHTTPSの場合は443、HTTPの場合は80）（UIおよびノード間ヘルスチェックへのアクセス用）
- 24007-24029 (GlusterFSポート ノード間通信、ヘルスチェック、自己修復デーモン、ブリック通信用)
Cloud Exchange VMとして利用している場合、
firewalldは既にインストールされており、デフォルトで無効になっています。 これらのコマンドを実行してファイアウォールを有効にし、Dockerサービスを再起動する必要があります。 sudo systemctl enable firewalld
sudo systemctl start firewalld
sudo systemctl restart docker
ファイアウォールを使用して 443 ポートを開くサンプル コマンド:
sudo firewall-cmd --permanent --add-port=443/tcp
これらのポートは MongoDBおよびRabbitMQサービスのクラスタリングに使用されます。 また、UIポートはすべてのマシンからヘルスチェックを実行するために必要です。
Cloud ExchangeにHAをデプロイする
プライマリノードを設定する
- Netskope CEが導入されるすべてのマシンで
netskopeoss/ta_cloud_exchangeGithubリポジトリをクローンしてください:mkdir netskope cd netskope git clone https://github.com/netskopeoss/ta_cloud_exchange cd ta_cloud_exchange
既にリポジトリをクローンしている場合は、ローカルでの変更をすべて削除し、最新バージョンをプルしてください。
git reset --hard
git pullご希望のバージョンをご確認ください。先に進む前に、リポジトリの目的のバージョンをチェックアウトしてください。例えば、バージョン6.1.0をチェックアウトする場合。
git checkout v6.1.0
あなたが CEをVMとして実行している場合、リポジトリは
/opt/cloudexchange/cloudexchangeパスで利用できます。 現在のディレクトリをcloudexchangeディレクトリに変更してください。cd /opt/cloudexchange/cloudexchange
- （オプション）
cloudexchange.configファイルをコピーして編集します。cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
- メンテナンスパスワードとJWTシークレットパスワードは データベース認証のためにCloud Exchange内部で使用されます。 これらのパスワードは、バックアップを復元する際に必要になります。
- メンテナンスおよび JWT シークレット パスワードでは、非 ASCII 文字 (アクセント付き文字、その他のスクリプト、絵文字など) はサポートされていません。これらの特殊文字を使用すると、一部のプロセスが機能せず、システム障害が発生する可能性があります。 これらの特殊文字。
- 必要に応じて変数を編集し、ファイルを保存してください。次に、以下のコマンドを実行してください。
sudo systemctl stop cloud-exchange && sudo systemctl disable cloud-exchange
- セットアップを実行します。
sudo ./setup
- 開始を実行してスタンドアロン インスタンスを起動します。
sudo ./start
- ノードが起動したら、 Settings > General > Node Configuration .
に移動します。
- Enable HAをクリックして、選択を確定してください。ストリーミングされたログを確認してください。HAを有効にする際、ノードは一度再起動します。
ノードが起動したら、RabbitMQ、MongoDB、Core、およびUIのサービスステータスを確認します。
セカンダリノードを設定する
- プライマリノードからJWTシークレットキーをコピーします。プライマリノードの JWT シークレット値が思い出せない場合は、ここに記載されている手順に従って新しい JWT トークンを生成して適用してください。
netskopeoss/ta_cloud_exchange公開 GitHub リポジトリをクローンします。- ご希望のバージョンをご確認ください。先に進む前に、リポジトリの目的のバージョンをチェックアウトしてください。例えば、バージョン6.1.0をチェックアウトするには、以下の場合は、この 3 つの手順をスキップしてください。 CE を VM イメージとして使用します (CE を VM イメージとして使用する場合は、
/opt/cloudexchange/cloudexchangeパスに移動してください)。
git checkout v6.1.0
cloudexchangeリポジトリがクローンされたフォルダ内のセカンダリノードで、cloudexchange.configファイルを編集し、プライマリノードからJWTシークレットキーを更新します。
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
sudo systemctl stop cloud-exchange && sudo systemctl disable cloud-exchange
- プライマリノードの
ta_cloud_exchange/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.keyから既存のCAキーをコピーします。 - セカンダリノードの同じパスに貼り付けてください。ファイル名は
tls_cert_ca.keyと完全に一致する必要があります。 - セカンダリノードでセットアップを実行します。新しいノードでのセットアップが完了すると、そのノード用の新しい証明書が生成され、既存の認証局によって署名されます。これにより、新しいノードとHAクラスタ間の管理サーバー通信が可能になります。
sudo ./setup
HAクラスタにセカンダリノードを追加する
- セットアップスクリプトがすべてのノードで正常に実行されたら、プライマリノードにログインし、[設定] > [一般] > [ノード構成] に移動します。
- [新しいノードの追加] ボタンをクリックし、新しいノードの FQDN/IP アドレスを入力します。
- 新しいノードの横にある + アイコンをクリックすると、新しいノードとして追加できます。
ストリーミングされたログを確認してください。新しいノードを追加すると、プライマリノードも再起動します。
HAノード管理
- クラスターに新しいセカンダリノードを追加するには、 Settings > General > Node Configurationsに移動します。
- AddをクリックしてセカンダリノードのIPアドレスを入力し、次に追加（ + ）アイコンをクリックします。
- ノードの横にある停止アイコンをクリックすると、ノードを停止できます。
- ユーザーはノード設定プロセスの過去のノード「使う」 ログアイコンも 確認できます。
- 削除アイコンをクリックして、クラスターからセカンダリノードを削除します。
- 同様にCloud Exchange UI から任意のノードを再起動するには、再起動アイコンをクリックします。
スタンドアロンモードに戻したい場合は、このビデオを見て方法を学んでください。
硬化ガイドライン
- 様々なマシン上のDockerサービス間の必要な接続を確立し、ノードをクラスタに統合しやすくするために、Dockerサービスから以下のポートを公開しました。これらのポートは、Cloud Exchange HA の展開を予定しているすべてのマシンからアクセス可能な状態にしておくことが不可欠です。セキュリティ対策を強化するため、これらのポートへのアクセスを他のIPアドレスから制限することも推奨されます。
これらのポートは MongoDBおよびRabbitMQサービスのクラスタリングに使用されます。 また、UIポートはすべてのマシンからヘルスチェックを実行するために必要です。- 4369 (RabbitMQ ノードと CLI ツールによって使用されるピア検出サービス)
- 5672 (TLS を使用しない AMQP 0-9-1 および AMQP 1.0 クライアントによって使用される)
- 15672 (TLSを使用しないHTTP APIクライアント、管理UI、およびrabbitmqadmin)
- 25672 (ノード間および CLI ツール通信に使用)
- 35672 (CLI ツール通信に使用)
- 27017（MongoDBおよびMongosインスタンスのデフォルトポート）
- 選択されたUIポート（デフォルトはHTTPSの場合は443、HTTPの場合は80）（UIおよびノード間ヘルスチェックへのアクセス用）
- GlusterFSのインストールとセットアップは、Cloud Exchangeのユーザーインターフェースと管理サーバーを通じて行われ、これらは共有ストレージとして機能し、高可用性（HA）機能も備えています。HAクラスタに関わるすべての仮想マシンは、HA構成時にGlusterFSリポジトリへの接続性を確保する必要があります。
クラスタノード数の要件
障害発生時のMongoDBレプリケーションおよびRabbitMQミラーリングの要件の一環として、HAクラスタが稼働状態を維持し、Cloud Exchangeノードの大部分がACTIVE/ONLINE状態であることを確認することが非常に重要です。Cloud Exchangeノードの数が奇数であるHAクラスタは、Cloud Exchangeノードの数が偶数であるクラスタよりも、稼働状態を維持できる可能性が高い。
| HAクラスタ内のCEノードの総数。 | HAクラスタが正常に動作するために必要な、任意の時点でのアクティブ/オンラインのCEノードの最小数。 |
|---|---|
| 3 | 2 |
| 4 | 3 |
| 5 | 3 |
| 6 | 4 |
| 7 | 4 |
| 8 | 5 |
| 9 | 5 |
制限事項
- HA構成のセットアップ中は、GlusterFSリポジトリへの接続性を確保する必要があります。
- Cloud Exchangeの冗長インスタンスを複数運用するには、追加のハードウェアとコンピューティングリソースが必要です。
- 場合によっては、HA構成では、データの複製やアクティブなインスタンス間の調整が必要となるため、レイテンシが増加する可能性があります。
- IPアドレスやノード関連の設定に変更があった場合は、変更がクラスタ全体に適切に反映され同期されるように、システム内のすべてのマシンでセットアップスクリプトと開始スクリプトの両方を実行する必要があります。 必要なマシンはすべて一度に追加し、 マシンに固定IPアドレスを割り当てることをお勧めします。
- ノードの大部分を常に稼働状態に維持することが極めて重要です。そうしないと、クラスタの障害につながります。例えば、3ノードのクラスタでは、常に少なくとも2つのノードが稼働している必要があります。同様に、5ノードのクラスタでは、少なくとも3つのノードが稼働している必要があります。より大きなクラスターにおいても、同様の傾向が続く。これは、このような状況下ではMongoDBがプライマリー選挙プロセスを開始しないためです。さらに、ネットワーク分断によって引き起こされる不整合に伴う課題を軽減するために、RabbitMQにpause_minorityオプションを実装しました。ノードが復旧してクラスターに再接続すれば、この問題は解消されるはずです。クラスターに必要な最小稼働ノード数については、 「クラスターノード数要件」を参照してください。
参照: https://www.mongodb.com/docs/v5.0/core/replica-set-elections/#network-partition| https://www.rabbitmq.com/partitions.html#options - まれなケースとして、クラスタでノード障害が連続して発生すると、キューが頻繁にリーダーとミラーの状態になるため、RabbitMQでデータ損失が発生する可能性があります。このような場合、他のノードはまだ同期されていないデータを失う可能性があります。
参照： https ://www.rabbitmq.com/ha.html#behaviour - SSOでは、リダイレクトURLとして1つのノードのIPアドレスのみを追加できます。 オプションとして、ロードバランサーをすべてのIPアドレスに対して構成し、 ロードバランサーのIPアドレスを使用してSSOを構成することもできます。 そして、リクエストは利用可能なノードにリダイレクトされます。
Cloud Exchange の HA のトラブルシューティング
- HA 内の
./stopスクリプトは、クラスターから MongoDB および RabbitMQ ノードを削除します。そして、その特定のマシン上のサービスを停止してください。./stop を実行する際は、サービスが稼働している状態であることが非常に重要です。スクリプト。そうしないと、スクリプトがノードを削除するためのMongoクライアントを作成できないため、スクリプトが失敗する可能性があります。 - 移行中にノード名の変更で問題が発生した場合は、前提条件を確認し、手順1で作成したバックアップを復元してください。次に、2番目の手順から移行を再試行してください。
sudo rm -rf <path-to-ta_cloud_exchange>/data/mongo-data/data/* sudo cp -R <temp-mongo-path>/*
<path-to-ta_cloud_exchange>/data/mongo-data/data/ - docker/podmanサービスが実行されていることを確認してください。そうでない場合は、このコマンドを使用してサービスを実行します
sudo systemctl restart docker
- UI上でいずれかのコンテナが長時間ダウン状態と表示された場合は、コンテナの状態を確認し、必要に応じて再起動を実行してください。該当する場合はどこでも podman を使用します。
- コンテナの状態を確認してください。すべてのサービスが正常に動作している場合は、次のステップに進んでください。それ以外の場合は、開始スクリプトを再度実行してコンテナを回復します。
docker ps
- MongoDBクラスタの状態を確認してください。以下のコマンドを実行して、MongoDBコンテナ内でコマンドを実行してください。
docker compose exec -- mongodb-primary bash mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD rs.status()
ステータスが長期間にわたってPRIMARYまたはSECONDARY以外の状態を示す場合は、このコマンドを実行して特定のマシン上のコンテナを再起動してください。
docker compose restart mongodb-primary
- RabbitMQクラスタの状態を確認してください。RabbitMQコンテナ内でコマンドを実行するには、以下のコマンドを実行してください。
docker compose exec -- rabbitmq-stats bash rabbitmqctl cluster_status
出力結果の「実行中のノード」セクションを確認し、接続されているノードと実行中のノードを特定してください。必要に応じて、RabbitMQコンテナを再起動してください。
docker compose restart rabbitmq-stats
- コンテナの状態を確認してください。すべてのサービスが正常に動作している場合は、次のステップに進んでください。それ以外の場合は、開始スクリプトを再度実行してコンテナを回復します。
- ワーカーがRabbitMQに接続されていないなど、いずれかのノードでワーカー喪失エラーが発生した場合は、該当するコアコンテナを再起動してワーカーを復旧してください。この問題は、RabbitMQクラスタが長時間停止した場合に発生する可能性が高いです。
docker compose restart core
- Cloud Exchange起動中に GlusterFS のインストールエラーが発生した場合: 開始スクリプトの実行中に「glusterfs のインストールに失敗しました」というエラーが表示された場合は、このエラーを無視しても構いません。 Cloud Exchangeスタンドアロン インスタンスとして起動し、HA クラスタを有効にする必要がない場合。 HAクラスタリングをアップグレードしたい場合は、環境がGlusterFSリポジトリに接続できることを確認し、このドキュメント「VM上のCloud Exchangeの基盤となるOSをアップグレードする」の手順に従ってください。