Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

オブジェクトの整合性を検証

共同作成者
PDF

StorageGRID システムは、ストレージノード上のオブジェクトデータの整合性を検証し、オブジェクトの破損や欠落の有無を確認します。

検証プロセスには、バックグラウンド検証とオブジェクトの存在チェック（旧称フォアグラウンド検証）の 2 つがあります。データの整合性を確保するために連携して機能します。バックグラウンド検証は、オブジェクトデータの正確性を継続的にチェックするために自動的に実行されます。オブジェクトの存在チェックは、オブジェクトの有無（正確性ではなく）をより迅速に確認するためにユーザによってトリガーされることがあります。

バックグラウンド検証とは何ですか？

バックグラウンド検証プロセスは、ストレージノードにオブジェクトデータの破損したコピーがないかどうかを自動的かつ継続的にチェックし、問題が見つかった場合は自動的に修復を試みます。

バックグラウンド検証は、レプリケートオブジェクトとイレイジャーコーディングオブジェクトの整合性を次の方法でチェックします。

  • * レプリケートオブジェクト * ：バックグラウンド検証プロセスで破損したレプリケートオブジェクトが検出された場合、破損したコピーはその場所から削除され、ストレージノード上の他の場所に隔離されます。その後、アクティブな ILM ポリシーに従って新しいコピーが生成され、配置されます。新しいコピーは、元のコピーに使用されていたストレージノードに配置されるとはかぎりません。

メモ 破損したオブジェクトデータは、引き続きアクセスできるように、システムから削除されるのではなく隔離されます。隔離されたオブジェクトデータへのアクセスの詳細については、テクニカルサポートにお問い合わせください。

  • * イレイジャーコーディングオブジェクト * ：バックグラウンド検証プロセスでイレイジャーコーディングオブジェクトのフラグメントの破損が検出された場合、 StorageGRID は自動的に残りのデータとパリティフラグメントを使用して同じストレージノード上に欠落フラグメントの再構築を試みます。破損したフラグメントを再構築できない場合は、オブジェクトの別のコピーを取得しようとします。読み出しに成功すると、 ILM 評価が実行されて、イレイジャーコーディングオブジェクトの置き換え用のコピーが作成されます。

    バックグラウンド検証プロセスでは、ストレージノード上のオブジェクトのみチェックされます。アーカイブノード上またはクラウドストレージプール内のオブジェクトはチェックされません。バックグラウンド検証を実行するには、 4 日以上経過したオブジェクトが必要です。

バックグラウンド検証は、通常のシステムアクティビティを妨げないように設定された間隔で継続的に実行されます。バックグラウンド検証を停止することはできません。ただし、問題があると疑われる場合は、バックグラウンド検証の回数を増やして、ストレージノードの内容をより迅速に検証することができます。

バックグラウンド検証に関連するアラートとアラーム（レガシー）

破損したオブジェクトが検出され、自動的に修正できない場合（破損によってオブジェクトを特定できないため）は、* Unidentified corrupt object detected *アラートがトリガーされます。

別のコピーが見つからないため、バックグラウンド検証で破損したオブジェクトを置き換えることができない場合は、* Objects lost *アラートがトリガーされます。

バックグラウンド検証レートを変更します

データ整合性に関する懸念事項がある場合は、バックグラウンド検証によってストレージノード上のレプリケートオブジェクトデータをチェックする速度を変更できます。

作業を開始する前に
このタスクについて

ストレージノードに対するバックグラウンド検証の検証レートを変更できます。

  • Adaptive ：デフォルト設定です。最大 4MB/ 秒または 10 オブジェクト / 秒（先に超過した方）で検証するようにタスクが設計されます。

  • High ：ストレージ検証は高速で実行され、通常のシステムアクティビティの処理速度が低下する可能性があります。

この設定は、ハードウェアまたはソフトウェアの障害により、オブジェクトデータが破損している可能性がある場合にのみ使用します。優先度の高いバックグラウンド検証が完了すると、検証レートは自動的に適応にリセットされます。

手順

  1. サポート * > * ツール * > * グリッドトポロジ * を選択します。

  2. 「 * _ ストレージノード _ * > * LDR * > * Verification * 」を選択します。

  3. * Configuration * > * Main * を選択します。

  4. 「 * LDR * > * Verification * > * Configuration * > * Main * 」に移動します。

  5. バックグラウンド検証で、 * 検証レート * > * 高 * または * 検証レート * > * 適応 * を選択します。

    検証レートを設定しています
    メモ Verification Rate を High に設定すると、 Notice レベルで VPRI （ Verification Rate ）レガシーアラームがトリガーされます。

  6. [ 変更の適用 *] をクリックします。

  7. レプリケートオブジェクトのバックグラウンド検証の結果を監視します。

    1. ノード * > * Storage Node* > * Objects * に移動します。

    2. 「検証」セクションで、「破損したオブジェクト」および「破損したオブジェクトの特定なし」の値を監視します。

      バックグラウンド検証で破損したレプリケートオブジェクトデータが見つかった場合は、「破損したオブジェクト * 」指標が増分され、 StorageGRID は次のようにデータからオブジェクト ID の抽出を試みます。

      • オブジェクト ID を抽出できる場合は、 StorageGRID によってオブジェクトデータの新しいコピーが自動的に作成されます。新しいコピーは、アクティブな ILM ポリシーを満たしていれば、 StorageGRID システム内のどこにでも作成できます。

      • オブジェクトIDが破損しているために抽出できない場合は、* Corrupt Objects Unidentified 指標が増分され、 Unidentified corrupt object detected *アラートがトリガーされます。

    3. 破損したレプリケートオブジェクトデータが見つかった場合は、テクニカルサポートに連絡して破損のルート原因 を確認します。

  8. イレイジャーコーディングオブジェクトのバックグラウンド検証の結果を監視します。

    バックグラウンド検証でイレイジャーコーディングオブジェクトデータの破損したフラグメントが検出された場合は、 Corrupt Fragments Detected 属性がその分だけ増分します。StorageGRID は、破損したフラグメントを同じストレージノード上に再構築して、この状況からリカバリします。

    1. サポート * > * ツール * > * グリッドトポロジ * を選択します。

    2. 「 * _ ストレージノード _ * > * LDR * > * イレイジャーコーディング * 」を選択します。

    3. Verification Results テーブルで、 Corrupt Fragments Detected （ ECCD ）属性を監視します。

  9. 破損したオブジェクトが StorageGRID システムによって自動的にリストアされたら、破損したオブジェクトの数をリセットします。

    1. サポート * > * ツール * > * グリッドトポロジ * を選択します。

    2. 「 * _ ストレージノード _ * > * LDR * > * Verification * > * Configuration * 」を選択します。

    3. 「破損オブジェクト数をリセット」を選択します。

    4. [ 変更の適用 *] をクリックします。

  10. 隔離されたオブジェクトが不要であると確信している場合は、それらのオブジェクトを削除できます。

    メモ Objects Lost * アラートまたは LOST （ Lost Objects ）レガシーアラームがトリガーされた場合、テクニカルサポートは、隔離されたオブジェクトにアクセスして、基になる問題 のデバッグやデータリカバリを試みることができます。

    1. サポート * > * ツール * > * グリッドトポロジ * を選択します。

    2. 「 * _ ストレージノード _ * > * LDR * > * Verification * > * Configuration * 」を選択します。

    3. ［ * 隔離オブジェクトの削除 * ］ を選択します。

    4. 「 * 変更を適用する * 」を選択します。

オブジェクトの存在チェックとは何ですか？

オブジェクトの存在チェックでは、オブジェクトとイレイジャーコーディングフラグメントの想定されるレプリケートコピーがすべてストレージノードに存在するかどうかが検証されます。オブジェクトの存在チェックでは、オブジェクトデータ自体は検証されません（バックグラウンド検証で検証されます）。代わりに、ストレージデバイスの整合性を検証する方法が提供されます。特に、最新のハードウェア問題 がデータの整合性に影響を与える可能性がある場合に役立ちます。

自動的に実行されるバックグラウンド検証とは異なり、オブジェクト存在チェックジョブは手動で開始する必要があります。

オブジェクトの存在チェックでは、 StorageGRID に格納されているすべてのオブジェクトのメタデータが読み取られ、レプリケートされたオブジェクトコピーとイレイジャーコーディングされたオブジェクトフラグメントの両方の存在が検証されます。不足しているデータは次のように処理されます。

  • * Replicated Copies * ：レプリケートオブジェクトデータのコピーが見つからない場合、 StorageGRID はシステム内の別の場所に格納されているコピーからコピーを自動的に置き換えます。ストレージノードは既存のコピーに対して ILM を評価します。これにより、別のコピーがないために、このオブジェクトに関して現在の ILM ポリシーは満たされていないという結果となります。システムのアクティブな ILM ポリシーに沿って新しいコピーが生成されて配置されます。この新しいコピーは、欠落したコピーが格納されていた場所に配置されるとはかぎりません。

  • * イレイジャーコーディングされたフラグメント * ：イレイジャーコーディングされたオブジェクトのフラグメントが欠落している場合、 StorageGRID は自動的に残りのフラグメントを使用して同じストレージノード上に欠落フラグメントの再構築を試みます。失われたフラグメントが多すぎるために欠落フラグメントを再構築できない場合、ILMはオブジェクトの別のコピーを探し、このコピーを使用して新しいイレイジャーコーディングフラグメントを生成します。

オブジェクトの存在チェックを実行します

オブジェクト存在チェックジョブは、一度に 1 つずつ作成して実行します。ジョブを作成するときに、検証するストレージノードとボリュームを選択します。また、ジョブの整合性制御も選択します。

作業を開始する前に

  • を使用して Grid Manager にサインインします "サポートされている Web ブラウザ"。

  • Maintenance または Root アクセス権限が必要です。

  • チェックするストレージノードがオンラインであることを確認しておきます。ノードの表を表示するには、 * nodes * を選択します。チェックするノードのノード名の横にアラートアイコンが表示されないようにします。

  • チェックするノードで次の手順が * 実行されていないことを確認します。

    • Grid の拡張：ストレージノードを追加

    • ストレージノードの運用停止

    • 障害ストレージボリュームのリカバリ

    • 障害システムドライブがあるストレージノードのリカバリ

    • EC のリバランシング

    • アプライアンスノードのクローン

これらの手順の実行中は、オブジェクトの存在チェックで有用な情報が得られません。

このタスクについて

オブジェクトの存在チェックジョブは、グリッド内のオブジェクトの数、選択したストレージノードとボリューム、および選択した整合性制御によって、完了までに数日から数週間かかることがあります。一度に実行できるジョブは 1 つだけですが、同時に複数のストレージノードとボリュームを選択することもできます。

手順

  1. [* maintenance * （メンテナンス * ） ] > [* Tasks * （タスク * ） ] > [* Object existence check * （オブジェクトの存在

  2. 「 * ジョブの作成 * 」を選択します。Create an object existence check job ウィザードが表示されます。

  3. 検証するボリュームが含まれているノードを選択します。オンラインノードをすべて選択するには、列ヘッダーの*[ノード名]*チェックボックスをオンにします。

    ノード名またはサイトで検索できます。

    グリッドに接続されていないノードは選択できません。

  4. 「 * Continue * 」を選択します。

  5. リスト内のノードごとに 1 つ以上のボリュームを選択します。ストレージボリューム番号またはノード名を使用してボリュームを検索できます。

    選択した各ノードですべてのボリュームを選択するには、列ヘッダーの*[ストレージボリューム]*チェックボックスを選択します。

  6. 「 * Continue * 」を選択します。

  7. ジョブの整合性制御を選択します。

    整合性制御は、オブジェクトの存在チェックに使用するオブジェクトメタデータのコピー数を決定します。

    • * strong-site * ：単一のサイトにおけるメタデータのコピーが 2 つ

    • * strong-global * ：各サイトにおけるメタデータのコピーが 2 つ

    • * all * （デフォルト）：各サイトに 3 つのメタデータのすべてのコピーを格納します。

      整合性制御の詳細については、ウィザードの説明を参照してください。

  8. 「 * Continue * 」を選択します。

  9. 選択内容を確認します。「 * Previous * 」を選択すると、ウィザードの前の手順に進み、選択内容を更新できます。

    オブジェクト存在チェックジョブが生成され、次のいずれかが実行されるまで実行されます。

    • ジョブが完了します。

    • ジョブを一時停止またはキャンセルした場合。一時停止したジョブは再開できますが、キャンセルしたジョブは再開できません。

    • ジョブが停止します。Object existence check has ストール * アラートがトリガーされます。アラートに対して指定された対処方法に従います。

    • ジョブが失敗します。* Object existence check has failed * というアラートがトリガーされます。アラートに対して指定された対処方法に従います。

    • 「 Service Unavailable 」または「 Internal server error 」というメッセージが表示されます。1 分後にページを更新して、ジョブの監視を続行します。

      メモ 必要に応じて、 [ オブジェクトの有無 ] チェックページから移動して、ジョブの監視を続行することができます。

  10. ジョブの実行中に、「 * Active job * 」タブを表示して、検出されたオブジェクトコピーが欠落していることを確認します。

    この値は、レプリケートオブジェクトとイレイジャーコーディングオブジェクトの欠落コピーのうち、 1 つ以上のフラグメントが欠落しているものの合計数を表します。

    検出された欠落オブジェクトコピーの数が 100 を超える場合は、ストレージノードのストレージを含む問題 が存在する可能性があります。

    OEC アクティブジョブ

  11. ジョブが完了したら、さらに必要なアクションを実行します。

    • 欠落オブジェクトコピーが 0 であることが検出された場合、問題は見つかりませんでした。対処は不要です。

    • 欠落オブジェクトコピーがゼロより大きいことが検出され、「 Objects lost * 」アラートがトリガーされていない場合は、欠落しているすべてのコピーがシステムによって修復されました。ハードウェアの問題が修正され、オブジェクトコピーが今後破損しないようになっていることを確認する。

    • 欠落オブジェクトコピーがゼロより大きいことが検出され、「 * Objects lost * 」アラートがトリガーされた場合は、データの整合性に影響する可能性があります。テクニカルサポートにお問い合わせください。

    • grepを使用してLLST監査メッセージを抽出すると、損失オブジェクトコピーを調査できます。 grep LLST audit_file_name。

      この手順 はのものと似ています "損失オブジェクトを調査しています"（ただし、オブジェクトコピーの場合は検索します） LLST ではなく OLST。

  12. ジョブに対して strong-site または strong-global 整合性制御を選択した場合は、メタデータの整合性が保証されるまで約 3 週間待ってから、同じボリューム上でジョブを再実行してください。

    ジョブに含まれるノードとボリュームでメタデータの整合性を維持するための時間がかかっていた場合、誤って報告された欠落オブジェクトコピーまたは原因 を見逃していたオブジェクトコピーをジョブで再実行することで解決できます。 StorageGRID

    1. [* maintenance * （メンテナンス * ） ] > [* Object existence check * （オブジェクトの存在確認 * ） ] > [* Job history * （ジョブ

    2. 再実行する準備ができているジョブを特定します。

      1. 3 週間以上前に実行されたジョブを特定するには、「 * End time * 」列を参照してください。

      2. これらのジョブについては、コンシステンシコントロール列をスキャンして、強サイトまたは強グローバルを確認します。

    3. 再実行する各ジョブのチェックボックスをオンにして、*再実行*を選択します。

      OEC 再実行

    4. ジョブの再実行ウィザードで、選択したノードとボリューム、および整合性制御を確認します。

    5. ジョブを再実行する準備ができたら、 * 再実行 * を選択します。

[ アクティブジョブ ] タブが表示されます。選択したジョブはすべて、 strong-site の整合性を制御している 1 つのジョブとして再実行されます。[ 詳細 ] セクションの [ 関連ジョブ ] フィールドには、元のジョブのジョブ ID が一覧表示されます。

完了後

データの整合性についてまだ懸念がある場合は、 * support * > * Tools * > * Grid Topology * > * site _ * > * _ Storage Node* > * LDR * > * Verification * > * Configuration * > * Main * に移動し、バックグラウンド検証レートを増やします。バックグラウンド検証は、格納されているすべてのオブジェクトデータの正確性を確認し、見つかった問題を修復します。潜在的な問題をできるだけ早く検出して修復することで、データ損失のリスクが軽減されます。