LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策
こんにちは、SCSKの前田です。
いつも TechHarmony をご覧いただきありがとうございます。
前回の連載（カテゴリ4）では、DataKeeperを用いたデータ保護の核心である「ミラー同期」や、バックアップ・リストア運用における注意点について詳しく解説しました。「データを守る」ことは、DR（災害復旧）や障害対策において最も重要な要素の一つです。
しかし、どれほどデータが守られていても、システム全体の「脳」であるクラスタが正しく状態を判断できなければ、サービスは継続できません。そこで今回から始まるカテゴリ5では、クラスタの健全性を維持するための要である「Quorum/Witness（クォーラム/ウィットネス）とコミュニケーションパス」にスポットを当てます。
特に第一弾となる今回は、意外と知られていない「Quorumの必要性の判断」から、設定時にハマりやすい「デバイス・権限の仕様」について、実際のサポート事例を交えて紐解いていきます。
💡 前回の記事（カテゴリ4）はこちら！
▶【DataKeeper：ミラー同期とデータ保護の核心 #1】同期中だから切り替わらない！？フェイルオーバーの「絶対条件」と性能評価の罠 – TechHarmony
▶【DataKeeper：ミラー同期とデータ保護の核心 #2】スナップショットから戻したのに動かない！？リストア後の「整合性」確保とバックアップ連携の盲点 – TechHarmony
はじめに
高可用性（HA）クラスタを構築する上で、避けて通れないのが「スプリットブレイン」対策です。両ノードが「自分が稼働系だ」と誤認し、同時にデータの書き込みを行ってしまう最悪の事態。これを防ぐための強力な仕組みが、第三者の立場で生存確認を行う「Quorum/Witness」です。
しかし、このQuorum/Witnessは非常に奥が深い機能です。 「物理サーバの共有ディスク構成なら、必ず設定すべきなのか？」 「Storageモードで使うパーティションは、どう準備するのが正解か？」 「Witnessサーバは、他のクラスタのものを使い回してもいいのか？」
こうした疑問に対する答えを誤ると、本来スプリットブレインを防ぐための仕組みが、逆にシステムを不安定にする要因となってしまいます。
本記事では、サポート窓口に寄せられた「設計・構築フェーズでの困った！」事例をもとに、Quorum/Witnessを正しく理解し、確実に設定するためのポイントを整理します。この記事を読み終える頃には、なんとなく設定していたQuorumが、自信を持って設計できる「頼れる番人」に変わっているはずです。
今回の「困った！」事例：Quorum/Witness 設定・運用の落とし穴
Quorum/Witnessは、クラスタの健全性を維持するための重要なコンポーネントですが、その設定や挙動は多岐にわたります。ここでは、設計・構築・運用の各フェーズで寄せられた実際の相談事例を見ていきましょう。
【設計編】「そもそも必要？」から始まる構成の判断
- 事例：共有ディスク構成なら不要な場合も？
「Windowsの共有ディスク構成でStorageモードを検討中だが、接続方法の記述が見当たらない」というご相談がありました。
【真相】 実は、Windowsの物理共有ディスク構成では、LifeKeeperがディスクの排他制御を行うため、Quorumによるフェンシングが必須ではないケースがあります。不要な設定を増やすことは、逆にトラブルの元。まずは構成の必要性を正しく判断することが第一歩です。 - 事例：Witnessサーバの「使い回し」は推奨されない？
「複数のクラスタで1台のWitnessサーバを共用できるか」という設計上の疑問です。
【真相】 以前は可能とされていましたが、現在は安定稼働の方針から「1クラスタにつき1Witnessサーバ」が原則です。構築後に設計変更にならないよう、最新のポリシー確認が欠かせません。
【構築編】デバイス準備・権限設定の罠
構築フェーズでは、選択したQuorumモードに応じた「正しい準備」ができているかが成否を分けます。
- 事例：Storageモード(block)での「良かれと思ったファイルシステム作成」がNG
物理ストレージやiSCSI、VMDKなどを使用する blockモード の場合、「パーティションを作ったら、次はフォーマット（xfsやext4など）」と考えがちですが、これはNGです。
【真相】 LifeKeeperがデバイスに直接書き込むため、ファイルシステムの作成は不要 です。VMDK使用時などはパーティション作成すら不要なケースもあります。逆にNFS（fileモード）を使用する場合は、マウントされたファイルシステム上の「ファイル」を指定する必要があり、モード混同によるミスが散見されます。 - 事例：S3 Quorumでのアクセス拒否とCLIの壁
aws_s3モード 設定時にAccessDeniedが発生したケース。
【真相】 S3オブジェクトの作成権限だけでなく、削除（Delete）権限が不足していてもエラーとなります。また、S3モードでは「AWS CLIがrootユーザーで実行可能か」「環境変数PATHが通っているか」といった、OS・クラウド連携特有のチェックポイントも重要です。
【運用編】「もしも」の時の挙動と監視
- 事例：再起動が速すぎてフェイルオーバしない？
Quorum喪失時にfastboot（再起動）を設定していたが、稼働系の復帰が速すぎて待機系が障害を検知できなかったケース。
【真相】 タイミングの不一致により、切り替えが意図通り行われないことがあります。確実な切り替えにはfastkillの検討や、デバッグログでの精査が必要です。 - 事例：Witnessサーバ側の障害に気づけるか
【真相】 Witnessサーバがダウンすると、クラスタ本体側に「LCM通信切断」のログが記録されます。「番人の不在」をいち早く検知できるよう、本体側の監視設計に含めておく必要があります。
「再発させない！」ための対応策と学び
今回の事例とマニュアルの要件から、モード別のチェックリストを整理しました。
【設計・構築時チェックリスト：Quorumデバイス編】
- [ ] 選択したモードの要件を正しく理解しているか？
- blockモードの場合：
- ファイルシステム（mkfs）を作成していないか？
- RAWデバイスではなく、ブロックデバイスを指定しているか？
/dev/disk/by-id/等の永続的な名前を使用しているか？
- fileモード（NFS）の場合：
- NFSサーバーのexportオプション（
no_root_squash等）が適切か？ /etc/fstabに登録し、再起動後も自動マウントされるか？
- NFSサーバーのexportオプション（
- aws_s3モードの場合：
- AWS CLIがインストールされ、rootで実行可能か？
- IAMポリシーに
PutObject/DeleteObject等が含まれているか？ - 整合性を考慮し、2つのリージョンにオブジェクトを分散しているか？
- blockモードの場合：
- [ ] 1クラスタ・1Witnessの原則： WitnessサーバやQuorumデバイスを他のクラスタと共用していないか？
【ベストプラクティス】
- 「マニュアルの注記」を侮らない： blockモードでの「アラインメント4K」や、S3モードでの「PATH設定」など、小さな注記がトラブル防止の鍵です。
- フェイルオーバ挙動の検証： 実際の運用環境に近いタイミングでQuorum喪失試験を行い、
fastbootで問題ないか、fastkillにすべきかを確認してください。 - Witnessサーバも監視対象に： クラスタ本体のイベントログで、LCMの切断（No.960）と復旧（No.959）を監視し、健全性を維持しましょう。
まとめ
Quorum/Witnessは、普段は意識することの少ない「黒子」のような存在ですが、ひとたび障害が起きれば、クラスタの命運を分ける「最後の審判」を下す重要な役割を担っています。
今回の事例から見えてきたのは、「モードごとの仕様の正確な把握」 と 「運用まで見据えた監視・検証」 の重要性です。共有ディスク構成だからと盲目的に設定するのではなく、自社のシステムにとって最適な「番人」の姿を、設計段階から吟味することが、強固なHAクラスタへの近道となります。
「日々の運用でここ（LCMログ等）を意識すれば、防げる障害はたくさんあります。この記事が、皆さんのクラスタ健全性維持の一助となれば幸いです。」
次回予告
次回は、同じカテゴリ5の中から、さらに一歩踏み込んだテーマをお届けします。 「記事案2：コミュニケーションパス途絶が招くクラスタ分離：見落としがちな設定ミス」
コミュニケーションパス（ハートビート）の瞬断や設定ミスが、どのようにクラスタの挙動を乱すのか。実際のトラブル事例とともに、その対策を深掘りします。お楽しみに！
📚 本連載のバックナンバー
過去のトラブル事例と解決策もぜひあわせてご覧ください！
カテゴリ1：リソース起動・フェイルオーバー失敗の深層
▶【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony
▶【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony
▶【リソース起動・フェイルオーバー失敗の深層 #3】設定ミス・通信障害・バージョン違いの深層と再発防止策 – TechHarmony
カテゴリ2：OS・LKバージョンアップで泣かないために
▶【OS・LKバージョンアップで泣かないために #1】OSバージョンは変えていないのに！？カーネル更新の「落とし穴」と互換性の真実 – TechHarmony
▶【OS・LKバージョンアップで泣かないために #2】「設定が消えた！？」「亡霊IPが警告！？」を防ぐロードマップ：単純な上書き更新に潜む落とし穴と回避策 – TechHarmony
カテゴリ3：クラウド環境特有の落とし穴
▶【クラウド環境特有の落とし穴 #1】良かれと思った自動復旧が仇に！？AWS環境（EC2/Route53/S3）でハマる構成と回避策 – TechHarmony
▶【クラウド環境特有の落とし穴 #2】オンプレ感覚の「同一サブネット」はNG!?Azure環境のネットワーク要件とQuorum設計の最適解 – TechHarmony
カテゴリ4：DataKeeper：ミラー同期とデータ保護の核心
▶【DataKeeper：ミラー同期とデータ保護の核心 #1】同期中だから切り替わらない！？フェイルオーバーの「絶対条件」と性能評価の罠 – TechHarmony
▶【DataKeeper：ミラー同期とデータ保護の核心 #2】スナップショットから戻したのに動かない！？リストア後の「整合性」確保とバックアップ連携の盲点 – TechHarmony
カテゴリ5：クラスタ健全性維持の要
▶【クラスタ健全性維持の要 #1】クラスタの番人Quorum/Witness：その設定、本当に必要？ 正しく選んで正しく守る設計術
