翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
アクティブ/アクティブ AWS IoT Greengrass V2 コンポーネント
この設定では、カスタム OCF (オープンクラスターフレームワーク) リソースエージェントを使用して Pacemaker で AWS IoT Greengrass V2 コンポーネントを管理します。これにより、Pacemaker は AWS IoT Greengrass V2 コンポーネントの状態をモニタリングし、コンポーネントが壊れた状態になったときに復旧アクションをトリガーできます。
重要
DRBD セットアップステップを除く、先に進む前提条件とクラスターのセットアップ前に のすべてのステップを完了します。この設定では DRBD を使用しません。代わりに、 を各インスタンスのローカルパス AWS IoT Greengrass V2 にインストールします。 は、すべてのインスタンスでプロビジョニングして実行 AWS IoT Greengrass V2 する必要があります。このチュートリアルでは、 AWS IoT Greengrass V2 が にインストールされていることを前提としています/greengrass/v2。別のパスを選択した場合は、それに応じて OCF スクリプトの GG_CLI変数を更新します。
カスタム OCF リソースエージェントを作成する
すべてのインスタンスでカスタムリソースエージェントディレクトリとスクリプトを作成します。この例では、 という名前のコンポーネントを管理しますPythonWebServer。
sudo mkdir -p /usr/lib/ocf/resource.d/custom
次の内容/usr/lib/ocf/resource.d/custom/gg-webserverのリソースエージェントスクリプトを に作成します。
#!/bin/bash # OCF Resource Agent for Greengrass Web Server component . /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs GG_CLI="/greengrass/v2/bin/greengrass-cli" COMPONENT="PythonWebServer" STATE_FILE="/run/gg-webserver.ocf-state" case "$1" in meta-data) cat <<EOF <?xml version="1.0"?> <resource-agent name="gg-webserver"> <version>1.0</version> <longdesc lang="en">Greengrass webserver component agent</longdesc> <shortdesc lang="en">GG Webserver</shortdesc> <parameters> </parameters> <actions> <action name="start" timeout="60"/> <action name="stop" timeout="10"/> <action name="monitor" timeout="5" interval="10"/> <action name="meta-data" timeout="5"/> </actions> </resource-agent> EOF ;; start) touch "$STATE_FILE" systemctl restart greengrass if [ $? -eq 0 ]; then exit $OCF_SUCCESS else rm -f "$STATE_FILE" exit $OCF_ERR_GENERIC fi ;; stop) rm -f "$STATE_FILE" exit $OCF_SUCCESS ;; monitor) # Check state file first — if absent, resource is stopped [ ! -f "$STATE_FILE" ] && exit $OCF_NOT_RUNNING # Check if the Greengrass service is running if ! systemctl is-active --quiet greengrass; then exit $OCF_NOT_RUNNING fi STATE=$($GG_CLI component details -n=$COMPONENT 2>/dev/null | grep '^[[:space:]]*State:' | awk '{print $2}') if [[ -z "$STATE" ]]; then ocf_log warn "Component $COMPONENT state is empty — component may not be deployed" exit $OCF_SUCCESS elif [[ "$STATE" == "BROKEN" ]]; then exit $OCF_ERR_GENERIC else exit $OCF_SUCCESS fi ;; *) echo "Usage: $0 {start|stop|monitor|meta-data}" exit $OCF_ERR_UNIMPLEMENTED ;; esac
スクリプトを実行可能にします。
sudo chmod +x /usr/lib/ocf/resource.d/custom/gg-webserver
注記
start アクションは AWS IoT Greengrass V2 サービス全体を再起動し、 だけでなく、インスタンス上のすべてのコンポーネントを再起動しますPythonWebServer。は個々のコンポーネントの再起動をサポートしていないため、これは唯一の実用的な復旧パス AWS IoT Greengrass V2 です。このエージェントはモニタリングラッパーであるため、stopアクションは意図的に no-op です。 AWS IoT Greengrass V2 サービスライフサイクルは、このエージェントではなく systemd によって管理されます。コンポーネントが永続的に (BROKENたとえば、不適切なデプロイが原因で) 残る場合、Pacemaker は最大 migration-threshold回再試行し、failure-timeout有効期限が切れるまでそのノードのリソースを禁止します。再試行サイクルを停止するには、根本原因を修正する必要があります (有効なコンポーネントバージョンを再デプロイするなど)。
リソースをアタッチする
カスタム OCF エージェントを使用して Pacemaker リソースを作成します。
sudo pcs property set stonith-enabled=false
警告
STONITH は、このチュートリアルを簡素化するためにここでは無効になっています。本番環境では、STONITH を有効にし、分割ブレインやデータの破損を防ぐためにフェンシングエージェント (fence_awsAmazon EC2 インスタンスなど) を設定する必要があります。
sudo pcs resource create gg-webserver ocf:custom:gg-webserver \ op monitor interval=30s \ op start timeout=60s \ meta migration-threshold=3 failure-timeout=60s \ clone
復旧の確認
-
初期状態を確認します。コンポーネントがすべてのインスタンスで実行され、正常であることを確認します AWS IoT Greengrass V2 。
sudo pcs status -
コンポーネントの障害をシミュレートします。コンポーネントのプロセスを強制終了して一時的な障害をシミュレートします。最初に内部復旧を試みる AWS IoT Greengrass V2 可能性があります。コンポーネントが
BROKEN状態になると、Pacemaker はそのコンポーネントを検出し、サービス再起動をトリガーします。が内部的にコンポーネントを AWS IoT Greengrass V2 復旧する場合、Pacemaker はアクションを実行しません。sudo pkill -f "PythonWebServer" # Wait 30-60 seconds, then check the component state sudo /greengrass/v2/bin/greengrass-cli component details -n=PythonWebServer -
復旧を確認します。Pacemaker は、コンポーネントに異常があることを検出し、カスタム OCF スクリプトで定義されている復旧ステップを実行します。フェイルオーバーは必要ありません — Pacemaker は同じインスタンスでサービスを再起動します。
HAProxy や などの他のサービスは、すべてのインスタンスで正常に動作し AWS IoT Greengrass V2 続けます。スタンバイインスタンス上のアプリケーションは、中断することなくリクエストを引き続き受け取ります。
sudo pcs status復旧したインスタンスがバックアップされると、ロードバランサーはそのインスタンスを識別し、必要に応じてクライアントリクエストを分散します。