ノードのデータ修復
障害が発生した RustFS のノードとディスクを復旧し、自動のデータ修復を監視し、rc で範囲を限定した手動のデータ修復タスクを実行します。
RustFS のデータ修復は、ストレージセットに残っている正常なシャードから、欠落または不整合なイレイジャーコーディングのデータを再構築します。利用できないノードを復旧したあと、障害ディスクを交換したあと、またはスキャナーと heal のアラートを調べるときに、この手順を使います。
データ修復は、クラスターのストレージ操作です。独立した RustFS デプロイのあいだでデータとアイデンティティ設定をコピーする サイトレプリケーション とは別の機能です。
データ修復はバックアップではない
RustFS がデータを再構築できるのは、影響を受けるイレイジャーセットに十分な正常シャードが残っているあいだだけです。障害がセットの利用可能な冗長性を超えたあと、データ修復でオブジェクトを復旧することはできません。意図的な削除や、アプリケーション層の破損からも保護しません。復旧要件に合わせて、独立したバックアップまたはレプリケーションを維持します。
データ修復の仕組み
RustFS は、クラスターの heal キューを通じて、複数のデータ修復ソースを調整します。
autoHeal: 自動ディスクスキャナーは、未フォーマットのディスク、または障害のあと復帰したディスクを検出し、イレイジャーセットのデータ修復をキューに入れます。scanner: バックグラウンドのデータスキャナーは、不整合なストレージ状態を見つけると、オブジェクトとバケットのデータ修復をキューに入れることができます。readRepair: read-repair の経路は、リクエストの処理中に見つかった作業を投入できます。internal: 内部の復旧経路は、システムが開始した作業を投入できます。admin: 管理者はrc admin heal startで、再帰、バケット、またはプレフィックスの heal を投入できます。
自動のディスク修復は、低い優先度で実行されます。healOperations 状態オブジェクトは、これらのソース名を使って、キュー待ち、実行中、再試行中の作業を分けます。
再構築はクラスターのリソースを消費する
データ修復は正常なシャードを読み、再構築したデータを書き込みます。ディープスキャンは、読み取りとチェックサムの作業を追加します。復旧が進んでいるあいだ、クライアントのレイテンシ、ディスク使用率、空き容量、heal キューを監視します。
要件
ノードまたはディスクを復旧する前に、次を準備します。
- 影響を受けるデータを再構築できるだけの正常シャードが残っている RustFS デプロイ。
- 安定したノードアドレスと、当初設定したストレージのマウントパス。
- 影響を受けるイレイジャーセットに見合う容量の交換用ストレージ。
- 保護された管理ホスト上の RustFS
rcクライアント。 - クラスター情報、スキャナー、heal の操作を許可する管理用認証情報。
- ハードウェアを交換するとき、または再帰的なディープスキャンを実行するときのメンテナンス時間。
ハードウェアを変更する前に、障害ノード、プール、セット、ディスクエンドポイント、マウントパス、ファイルシステムの UUID を記録します。復旧が完了するまで、同じイレイジャーセットから別のディスクを取り外さないでください。
障害のあるコンポーネントを特定する
まだなければ、rc のエイリアスを設定します。
rc alias set rustfs https://rustfs.example.com:9000 \
<your-access-key> <your-secret-key> \
--region us-east-1 --bucket-lookup pathクラスターの準備完了、トポロジ、ストレージの健全性、heal の活動を確認します。
rc ready rustfs
rc admin info cluster rustfs
rc admin info storage rustfs
rc admin scanner status rustfs
rc admin heal status rustfsクラスターが縮退しているあいだは、準備完了の確認が失敗することがあります。管理情報のコマンドを使い、利用できないノードまたはディスクを特定し、そのプールとイレイジャーセットの位置を控えます。
機械可読の出力が必要な場合は、JSON を要求します。
rc --json admin info storage rustfs
rc --json admin heal status rustfs集約された heal 状態は、実行時の状態、キュー待ちと実行中のタスク、再試行中の作業、リクエストのソース、優先度、利用可能な進捗カウンタを報告します。キューの長さが 0 でも、オフラインのディスクが交換されたことや、すべてのオブジェクトを復旧できることの証明にはなりません。ストレージのトポロジと準備完了の状態と突き合わせます。
ノードまたはディスクを復旧する
手動 heal を始める前に、根本原因の障害を直します。
ノード障害の場合は、次の手順です。
- ノードに設定されていたネットワーク識別情報を復旧し、S3 API ポート（通常は
9000）で、他のすべての RustFS ノードと通信できる状態にします。 - 元のデータディスクを、設定されていたパスへマウントします。
- RustFS プロセスが、クラスターの他のノードと同じストレージエンドポイント設定を使っていることを確認します。
- RustFS を起動し、ノードがクラスターへ再参加したことを確認します。
障害ディスクの場合は、次の手順です。
- ストレージを取り外す、または再マウントする前に、影響を受けるノードの RustFS プロセスを停止します。
- 障害デバイスを交換し、ディスクの準備に従ってファイルシステムを準備します。
- 交換用ディスクを、障害ディスクが使っていたパスそのものへマウントし、
/etc/fstabをそのファイルシステムの UUID で更新します。 - RustFS を起動する前に、マウント、ファイルシステムの種類、所有権、空き容量を確認します。
- RustFS を起動し、ディスクが想定したプールとイレイジャーセットに現れることを確認します。
findmnt /data/rustfs0
df -hT /data/rustfs0
rc admin info storage rustfs古いストレージを確認せずに再利用しない
RustFS のデータパスへマウントする前に、各デバイスの識別情報と内容を確認します。ディスク間で内部メタデータをコピーしないでください。設定済みの複数のエンドポイントを、1 つの交換用ファイルシステムにまとめないでください。必要なデータが残っているパスの上に、交換用ディスクをマウントしないでください。
自動のデータ修復を監視する
ノードまたは交換ディスクがオンラインになったあと、RustFS は復旧候補を検出し、イレイジャーセットのデータ修復をキューに入れることができます。ストレージの状態と、集約された heal の活動の両方を確認します。
rc admin info storage rustfs
rc admin heal status rustfs
rc admin scanner status rustfsJSON 出力では、次のグループを監視します。
| フィールド | 意味 |
|---|---|
state | active や idle などの、heal の実行時状態。 |
healQueueLength | heal キューで待機している作業の合計。 |
healActiveTasks | 現在実行中の heal タスクの合計。 |
healOperations | ソース（scanner、admin、autoHeal、internal、readRepair）と優先度で分けた、キュー、実行中、再試行の件数。 |
progress | スキャン済み、修復済み、失敗、処理済みバイト数について、利用できる合計。 |
clusterStatusComplete | 応答が、想定されるすべてのノードを含むかどうか。 |
idle であることだけを、復旧の成功と見なさないでください。交換ディスクがオンラインであること、heal の失敗が残っていないこと、クラスターが準備完了であること、代表的なオブジェクトが読めることを確認します。
対象を絞った手動 heal を実行する
自動復旧が必要なパスをカバーしない場合、またはインシデントのあと明示的なスキャンが必要な場合に、手動タスクを使います。影響を受けたデータを含む、最も狭いバケットまたはプレフィックスから始めます。
変更を適用せずに、バケット heal をプレビューします。
rc admin heal start rustfs \
--bucket my-bucket \
--scan-mode normal \
--dry-runプレビューを確認したあと、対象を絞った heal を実行します。
rc admin heal start rustfs \
--bucket my-bucket \
--scan-mode normal影響範囲が分かっている場合は、オブジェクトプレフィックスにタスクを限定します。
rc admin heal start rustfs \
--bucket my-bucket \
--prefix archive/ \
--scan-mode deepnormal が既定のスキャンモードです。より深いデータ検証が必要で、追加のディスク I/O を見込んでいる場合に deep を使います。--bucket を省略するのは、すべてのバケットを再帰スキャンする必要がある場合だけです。
変更オプションは別に確認する
--remove は孤立したオブジェクトまたはパートを削除し、--recreate は欠落データの再作成を要求します。影響を受けたストレージの状態を調べ、--dry-run で確認し、意図した結果だと確かめるまで、インシデント対応のコマンドにどちらのオプションも足さないでください。
手動タスクを追跡する
手動 heal は毎回 clientToken を返します。そのタスクの状態確認と停止にはトークンが必要なため、インシデントの記録と一緒に保存します。
バケットまたはプレフィックスのタスクでは、元の対象とトークンを渡します。
rc admin heal status rustfs \
--bucket my-bucket \
--prefix archive/ \
--client-token <client-token>--bucket なしで開始した再帰タスクでは、トークンだけを使います。
rc admin heal status rustfs --client-token <client-token>トークンを付けないコマンドは、これまでどおりクラスター全体のバックグラウンド概要を表示します。
rc admin heal status rustfsタスクの状態には、スキャン済み、修復済み、失敗の項目合計、処理済みバイト数、現在の項目、スキャンモード、開始時刻、最終更新が含まれることがあります。タスクの集計状態だけに頼らず、失敗した項目を調べます。
復旧を検証する
heal キューが空になったあと、クラスターと復旧したデータパスを検証します。
rc ready rustfs
rc admin info cluster rustfs
rc admin info storage rustfs
rc admin heal status rustfs影響を受けたバケットとバージョンから、代表的なオブジェクトを読みます。既知のテストオブジェクトの場合は次のとおりです。
rc object stat rustfs/my-bucket/hello.txt
rc object copy rustfs/my-bucket/hello.txt ./hello-recovered.txt独立したチェックサム、または信頼できるソースがある場合は、ダウンロードしたオブジェクトと照合します。オブジェクトの読み取りが成功しても、検証されるのはそのリクエストだけです。クラスター内のすべてのオブジェクトや、すべてのシャードが検証されるわけではありません。
クラスターが準備完了になったあとも、ストレージの健全性と heal の失敗を監視し続けます。インシデントの時系列、障害デバイスの情報、タスクのトークン、最終的な状態の出力を、レビュー用に残します。
手動 heal を停止する
特定したタスクだけを停止します。バケットまたはプレフィックスのタスクでは、元の対象とトークンを含めます。
rc admin heal stop rustfs \
--bucket my-bucket \
--prefix archive/ \
--client-token <client-token>トークンで対象を限定した再帰タスクは、次のコマンドで停止します。
rc admin heal stop rustfs --client-token <client-token>トークンなしの停止コマンドは、グローバルなバックグラウンド heal を対象にします。
rc admin heal stop rustfsグローバルな停止を使うのは、バックグラウンドの処理を続ける方が運用上のリスクが大きい場合だけです。データ修復を止めると、復旧は完了しないまま残ります。インシデントを閉じる前に、理由を記録し、データ修復をどのように再開するかを確認します。
トラブルシューティング
交換ディスクでデータ修復が進まない
交換用ディスクが、設定されたエンドポイントにマウントされ、rc admin info storage に現れることを確認します。RustFS のログで、ディスクの識別、フォーマット、権限、キュー受付の失敗を確認します。あわせて、rc admin heal status でデータ修復サービスが初期化されていることを確認します。
heal の状態が部分的である
clusterStatusComplete が false の場合、想定していたノードのうち 1 つ以上が、集約応答に含まれていません。クラスターの合計値を信頼する前に、ノード間の接続を復旧し、各ノードのストレージとプロセスの健全性を確認します。
キューが active のままである
ソースごとに、キュー待ち、実行中、再試行中の作業を比較します。autoHeal の件数が増えているときは、ディスクまたはイレイジャーセットの復旧を示します。スキャナーの作業は、バックグラウンドでの検出を示します。admin の作業は、手動で投入したタスクのものです。別のタスクを開始する前に、ディスクのレイテンシ、空き容量、ノード間の接続、項目の繰り返し失敗を確認します。
オブジェクトを再構築できない
影響を受けるイレイジャーセットに対する追加のメンテナンスを止めます。残っているディスクとログを保存し、十分な正常シャードが残っているかを判断します。利用できる冗長性をすでに超えている場合、ディープスキャンを繰り返してもデータは再構築できません。
手動タスクを照会できない
heal start が返した clientToken を使います。バケットとプレフィックスのタスクは、開始時と同じ --bucket と --prefix を指定して照会する必要があります。再帰的なルートタスクは、バケットを付けずトークンだけを使います。
次のステップ
- 準備完了、クラスター、容量の確認は ステータスチェック を参照してください。
- ディスクの健全性と、継続する復旧作業へのアラートは オブザーバビリティ で設定します。
- 復旧に独立した RustFS デプロイが必要な場合は、サイトレプリケーション を参照してください。