ソフトウェアでエミュレーションされたウォッチドッグの既知の制限
概要
たとえば、ストレージベースのフェンシング (fence_sbd) を備えた Red Hat Enterprise Linux (RHEL) 高可用性クラスターでは、ウォッチドッグを有効にすることを推奨します。このウォッチドッグは、フェンスされているノードが自身を再起動できるようにすることで、リソースが同時に複数のノードで実行されてデータの整合性の問題が発生するのを防ぎます。
SBD が使用するこのウォッチドッグタイマーデバイスは、softdog ドライバーのようにソフトウェアでエミュレーションすることはできません。このようなプログラムは、カーネルが提供する制限と利用可能なリソースの範囲内で動作するため、オペレーティングシステムが誤動作している場合や、リソースが不足している場合に、必要な再起動アクションを実行することが保証されません。これにより、クラスター内の他のノードは、ノードがフェンスされて再起動したと想定しますが、実際にはその想定どおりにはなっておらず、クラスターの不整合状態やデータ損失が発生する可能性があります。
この記事では、使用に際しての 既知の制限および非推奨の設定 について説明します。これにより、特定のインストール内でそのように設定するリスクを許容できるかどうかエンドユーザーが評価できるようにします。
既知の問題
ソフトロックアップ
ソフトウェアでエミュレーションされたウォッチドッグをノードで使用すると、フェンスイベントが発生した場合に自身を再起動するアクションが、ノード上の他のすべてのプロセスと同じ環境で実行されます。ソフトロックアップが発生したり、システムのリソースが枯渇したりすると、カーネルはプロセスをスケジュールできなくなり、カーネル自体の再起動も実行できなくなります。
仮想プラットフォーム
クラスターノードがハイパーバイザー上で仮想マシンとして実行されている場合、ライブマイグレーションや一時停止/再開アクティビティー などの影響を受ける可能性があります。ゲスト OS は、ライブマイグレーションアクティビティーがいつ、どのくらいの頻度で発生するかを制御できません。ただし、このようなアクティビティーの間 (ライブマイグレーションの準備後) は、ライブマイグレーション を完了し、別のハイパーバイザーで操作を続行するために、ゲスト OS が一時停止します。ライブマイグレーション 中にフェンスイベントが発生した場合、ソフトウェアウォッチドッグは一時停止の影響を受ける可能性があります。したがって、セルフフェンシングを完了できず、再起動を実行できないおそれがあります。
特に機密性の高いワークロード
共有データアクセス
クラスターノードが Resilient Storage (GFS2、SMB/CIFS) にアクセスできるセットアップでは、すべてのクラスターノードの整合状態を確保することが特に重要です。上記のいずれかの状況など、フェンスイベント後にクラスターノードが自身を再起動できない場合、すでに実行中のプロセスが共有ストレージへの書き込みを継続する可能性があります。この場合、クラスター内の他のノードは、特定のノードがフェンスされており、そのノードのプロセスは実行されず、共有ストレージにも書き込まれないと信じています。再起動に失敗したために、これらのプロセスが共有ストレージに引き続き書き込みできる場合、データの不整合やデータ損失につながる可能性があります。この状況は、たとえばフェンスされたノードが共有ストレージに書き込むことを強制的に阻止する SCSI フェンシングが設定されている他の共有ストレージとは異なります。
ミッションクリティカルなワークロード
上記のような状況のため、Red Hat は、Fence SBD を使用する、ソフトウェアでエミュレーションされたウォッチドッグを、実稼働環境またはミッションクリティカルなワークロードで使用することを推奨しません。Red Hat Enterprise Linux 高可用性クラスターは、クラスターの可用性とデータの整合性に影響を与える外部イベントのリスクを最小限に抑えるように設計する必要があります。ハードウェアウォッチドッグやその他のフェンシングメカニズムとは対照的に、ソフトウェアでエミュレーションされたウォッチドッグは信頼性が低く、可用性とデータの整合性に影響を与える傾向があります。
Comments