ハードウェアが故障してもOzoneは動作し続ける：Apache Ozoneの故障容錯メカニズム解析

はじめに

分散型ストレージシステムは現代のクラウドインフラストラクチャにおいて不可欠な要素です。特に、ハードウェア障害が発生した際にもデータの可用性を維持する「故障容錯（fault tolerance）」機能は、システムの信頼性と信頼性を確保する上で極めて重要です。本記事では、Apache OzoneというHDFSとS3プロトコルをサポートする分散型ストレージシステムの故障容錯メカニズムを深く掘り下げ、その設計原理と実裝戦略を解説します。OzoneはApache Foundationのプロジェクトとして開発され、高可用性とデータの一貫性を実現するための革新的なアプローチを採用しています。

技術の定義と基本概念

Apache Ozoneは、HDFSとS3プロトコルをサポートする分散型ストレージシステムであり、大規模なデータセットの管理と高可用性を目的として設計されています。Ozoneの核心となるアーキテクチャは以下の3つの主要コンポーネントで構成されています：

Ozone Manager (OM)：ファイル名、ボリューム、バケットなどのメタデータを管理し、Raftプロトコルを用いて高可用性を実現します。データは3ノード間で複製され、クラスタ全體の可用性を確保します。
Storage Container Manager (SCM)：ストレージコンテナ（Storage Container）のメタデータを管理し、データの複製と配布を制御します。SCMもRaftプロトコルを採用し、クラスタ內のデータ一貫性を維持します。
Data Node：実際のデータブロックを保存し、SCMによって管理されます。データの複製と再配布を処理するための基本的な単位です。

これらのコンポーネントは、Ozoneがハードウェア障害に備えるための堅牢な設計を支えています。

重要な特性と機能

故障タイプと対応メカニズム

ネットワーク障害

リーダー分離：リーダーとフォロワー間のネットワーク切斷が発生すると、フォロワーがリーダーを選出します。元のリーダーはタイムアウト後に自動的に降格します。
自動回復：ネットワークが復舊した後、元のリーダーはクラスタに再參加し、最新の狀態と同期します。
Raft一貫性：すべての操作はクォーラム（2/3ノード）の確認を経て行われ、狀態の一貫性を保証します。

ノード障害

ノードダウン：殘りの2ノードが動作し、クライアントは新しいリーダーに操作を再試行します。
ノード置換：ハードウェア障害が発生したノードはブートストラピングを通じてクラスタに再參加し、データを同期します。
冗長性の推奨：RAID 1の設定を推奨し、ディスクの冗長性を高めます。

ディスク障害

Ozone Managerディスク障害：ディスクが読み書きできない場合、ノードはエラーを記録し、リーダー選挙をトリガーします。管理者がディスクを交換し、クラスタに再參加させます。
Data Nodeディスク障害：
- ボリュームスキャナーメカニズム：
  - ディスクマウントポイントと権限設定の検証
  - I/O検証（テストデータの書き込み→同期→読み込み検証→テストデータの削除）
  - スライディングウィンドウメカニズムを採用し、連続2回の検証失敗時にディスク障害を検出
- コンテナスキャナーメカニズム：
  - コンテナ內のすべてのブロックのチェックサムとRockDBメタデータの検証
  - データ一貫性を確認し、データ損傷が発生した場合に複製をトリガー

故障処理の詳細

データ複製戦略：データノード障害が発生した場合、SCMはノードをStaleとマークし、確認後複製をトリガー
パフォーマンスの考慮：過剰な複製を避けるため、ノード障害の判定精度を確保
監視メカニズム：Reconサービスが定期的にノード狀態を収集し、Web UIで表示
エラー処理：一時的なI/Oエラーには複數回のチェックメカニズムを採用し、誤検出を防ぐ

故障回復プロセス

ネットワーク分離：自動リーダー選挙と狀態同期
ノードダウン：殘りのノードが継続して動作し、クライアントが操作を再試行
ディスク障害：ボリュームスキャナーとコンテナスキャナーが段階的に障害を検出し、データ複製をトリガー
クラスタ回復：故障ハードウェアを交換し、クラスタに再參加し、最新の狀態と同期

データ一貫性の検証メカニズム

ディスクの健康チェック

ディスクチェックプロセス：
1. データを書き込み、読み込み結果とメモリデータを比較
2. 無誤りを確認後、ファイルを削除
3. いずれかの段階で失敗した場合、多段階チェック戦略を採用
4. デフォルトではスライディングウィンドウメカニズム（最近3回のチェック）を採用
  - 前2回のチェックが成功した場合、ディスクは正常とみなされる
  - 連続2回のチェック失敗が発生した場合、ディスクを異常と判定し、データ複製をトリガー
異常処理戦略：
- 間歇的なI/Oエラーによる高コストな複製を避ける
- 不安定なディスクの殘留はクライアントの再試行とパフォーマンス低下を引き起こす可能性がある
- 2/3回のチェック失敗が発生した場合、ディスクを停止し、データ複製をトリガー

コンテナスキャナー

2段階チェックメカニズム：
1. メタデータチェック：
  - コンテナディレクトリの存在性と読み取り可能性の確認
  - メタデータファイル（metadata file）の整合性の検証
  - 大量のコンテナに適した高速なチェック
2. データチェック：
  - コンテナ內のすべてのブロックを巡迴
  - ブロック長とチェックサム、RockDBメタデータと比較
  - 前端負荷を避けるため、チェック頻度を制限
異常処理：
- ブロックデータが破損した場合、コンテナ全體を不健康と判定
- 個別ブロック破損はまれ（ビット腐敗、宇宙線など）であり、コンテナ全體の複製を実施する方が簡潔で複雑さを減らす

按需スキャン（On-Demand Scans）

トリガー條件：
- クライアントが読み取り/書き込み時に異常が発生
- 背景スキャンが未処理のコンテナ問題を検出
処理フロー：
1. クライアントがコンテナ異常を検出
2. データノードがディスクとコンテナを待機狀態にマーク
3. SCM（Storage Container Manager）が複製を調整：
  - 他の健全なノードからデータを複製
  - 異常ノードのデータ複製を削除

クライアントデータ一貫性検証

書き込みフロー：
1. チェックサムを生成
2. 並列でデータノードに転送
3. ノードがチェックサム一致を確認し、永続化
読み取りフロー：
1. ノードがデータとチェックサムを返卻
2. クライアントが一致を確認し、読み取り成功
3. 不一致の場合は他のノードに再試行

今後の改善方向

チェックサム最適化：
- チェックサム検証のオーバーヘッドを削減
- ブロックファイルヘッダーにチェックサムを保存し、ゼロコピー転送を支援
ソフト障害処理：
- ノード/ディスクの遅延問題を処理
- SCMとReconサーバーでノード狀態を監視
- データ転送パスを動的に調整
チェックサム保存方法：
- ブロックファイルヘッダーにチェックサムを保存
- RockDBとネットワーク転送間のデータ分離を削減

設定と監視

調整可能なパラメータ：
- スキャン頻度と帯域幅配分
- エラー検出閾値（スライディングウィンドウ長さ）
- データ複製戦略
監視指標：
- スキャンに消費される帯域幅と頻度
- 発見されたエラー數と種類
- ディスク/コンテナの異常率

ディスク障害処理の詳細

RockDB障害処理：
- ノードがRaftトランザクションを処理できなくなった場合、自動的にシャットダウン
- 新しいノードがリーダーの役割を引き継ぐ
- 故障ノードは手動で調査（ディスク破損/データベース腐敗）が必要
- 他のノードが完全なデータを保持しているため、データ復舊が可能
データノードディスク構成：
- 各ディスクは1つのRockDBストレージコンテナメタデータに対応
- メタデータはコンテナ複製中に同期
- ディスク障害はコンテナ障害とみなされ、他の複製體からデータを再構築する必要があります

ボリューム障害処理メカニズム

ストレージボリュームが障害を発生した場合、システムは他のバックアップノードからデータをクラスタの現有スペースに再書き込みます。このプロセスはメタデータも同時に処理され、メタデータとともに移動され、他のRockインスタンスに注入されます。このメカニズムにより、データの可用性が維持され、クラスタ全體の一貫性が保持されます。

データノードのメンテナンスモード

データノードはDecommissionとMaintenanceの2つのメンテナンスモードを提供します。

Decommissionモード：
- 用途：ノードを永久に削除し、すべてのデータ再複製（re-pc）をトリガー
- 行為：
  - ノードが削除され、データが他のバックアップノードから移動
  - ノードは再起動されません
  - 長期的なノード削除に適しています
Maintenanceモード：
- 用途：ノードを一時的に停止し、データ再複製をトリガーしない
- 行為：
  - ノードがメンテナンス狀態にマークされ、システムはデータ再複製を自動的にトリガーしない
  - ノードは予測可能な再起動に適しています
  - オペレーティングシステムのアップグレードなどの一時的なメンテナンスに適しています

メタデータノードのDecommissionメカニズム

メタデータノード（主ノード）はのみDecommissionモードをサポートし、クラスタメンバーシップが靜的（固定3ノード）です。操作フローは以下の通りです：

Decommission CLIツールを使用して指定されたノードを停止
Raftプロトコルがクラスタ狀態を更新し、ノードを停止狀態にマーク
システムは新しい主ノードを選出し、クラスタが継続して動作
アップグレードが完了した後、Recommission操作を通じてクラスタに再參加
このプロセスを3つの主ノード間で繰り返すことで、メンテナンスをローテーションできます

この設計により、主ノードの安定性とクラスタの高可用性が保証されます。

結論

Apache Ozoneは、ハードウェア障害に備えた堅牢な分散型ストレージシステムとして、HDFSとS3プロトコルをサポートし、高可用性とデータの一貫性を実現しています。Ozoneの設計は、Raftプロトコルを採用した高可用性メタデータ管理、自動的なデータ複製と回復メカニズム、そして詳細な故障検出と処理戦略によって支えられています。これらの特性により、Ozoneは大規模なデータストレージ環境において信頼性と信頼性を確保するための優れた選択肢です。実裝においては、冗長性の設定や監視指標の調整を適切に行い、クラスタの安定性を維持することが重要です。