ノード障害

代替ノードを準備し、設定を更新してクラスターへの参加を復旧し、データ修復を確認します。

分散構成の RustFS クラスターは、イレイジャーコーディングにより一部のノードが故障しても読み書きを継続し、ノードが再参加するとデータを自動的に修復します。このガイドでは、次の手順を説明します。

代替ノードの準備

ハードウェアとシステムの準備 代替ノードのハードウェア（CPU、メモリ、ネットワーク、ディスク種別）が、障害ノードとおおむね揃っていることを確認します。より高いスペックのハードウェアを使っても、クラスターの性能には影響しません。オペレーティングシステム、カーネル、依存関係を含め、ほかのノードと一致するソフトウェアバージョンを使い、環境の不一致による問題を避けます。
ドライブへの排他アクセス 物理ドライブの操作と同様に、RustFS はそのストレージボリュームへの排他的なアクセスを必要とします。ほかのプロセスやスクリプトがこれらのボリュームのデータを直接変更しないようにします。直接変更すると、データが破損したり、冗長性が低下したりする可能性があります。

DNS と hosts の設定 代替ノードの IP アドレスが障害ノードと異なる場合は、旧ノードのホスト名（例: rustfs-node-2.example.net）を新しいノードの IP アドレスへ向けます。これにより、クラスター内のノードは同じ名前で互いに到達できます。

# Example: Add or modify line in /etc/hosts
192.168.1.12 rustfs-node-2.example.net

ping または nslookup を使い、ホスト名が新しいノードに解決されることを確認します。

ダウンロードとインストール 既存ノードと同じ RustFS バージョンを、同じインストール方法とディレクトリでインストールします。起動スクリプト、環境変数、設定ファイル（/etc/default/rustfs など）が、ほかのノードと同一であることを確認します。
設定の確認
/etc/default/rustfs 内の RUSTFS_VOLUMES がほかのノードとバイト単位で同一であり、代替ノードのホスト名とポートを含んでいることを確認します。
すべてのノードが同じアクセスキーと権限設定を使っていることを確認します。異なると、新しいノードは認証に失敗し、クラスターに参加できません。

systemctl start rustfs

独自の起動スクリプトで RustFS を起動する方法もあります。続いて journalctl -u rustfs -f を実行し、新しいノードがほかのノードを検出してデータ修復を開始したことを確認します。

データ修復状態の監視 ノードが再参加すると、データ修復はバックグラウンドで実行されます。手動コマンドは不要です。代替ノードのサービスログで進捗を確認し、RustFS Console でノードとディスクの状態を見ます。

journalctl -u rustfs -f

コミュニティでの観測結果 コミュニティでの検証では、ノードがオフラインになってから再参加したとき、RustFS はクラスター全体をリバランスせず、そのノードだけを修復します。これにより、不要なネットワークと I/O の急増を避けられます。

監視とアラート
データ修復中はディスクとネットワークの負荷を監視し、クラスターが読み取り、書き込み、帯域幅の要件を満たしていることを確認します。
ノードのデータ修復が失敗したとき、または進捗がしきい値を超えて停滞したときに、運用チームへ通知するアラートを設定します。
定期的な障害試験 定期的にノード障害の訓練を行い、復旧手順の全体を練習して、コマンドとインシデント対応の流れに慣れておきます。
根本原因分析 繰り返し故障するノードやディスクでは、SMART データや BIOS ログなどの詳細なハードウェア診断を実施し、予防保守の計画を用意します。
サポート 障害原因の診断やクラスター復旧の支援が必要な場合は、RustFS の開発チームまたはコミュニティへ連絡します。

これらの手順で、障害ノードを交換し、そのデータを修復します。コマンドは環境に合わせて調整し、ノード間の設定は同一に保ちます。