Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

アプライアンスのストレージボリュームを再マウントして再フォーマットする（手動の手順）

PDF

保存されたストレージ ボリュームを再マウントし、障害が発生したストレージ ボリュームを再フォーマットするには、2 つのスクリプトを手動で実行する必要があります。最初のスクリプトは、 StorageGRIDストレージ ボリュームとして適切にフォーマットされたボリュームを再マウントします。 2 番目のスクリプトは、マウントされていないボリュームを再フォーマットし、必要に応じて Cassandra データベースを再構築し、サービスを開始します。

開始する前に

  • 交換が必要であることがわかっている、障害が発生したストレージ ボリュームのハードウェアはすでに交換されています。

    実行中 `sn-remount-volumes`このスクリプトは、追加の障害が発生したストレージ ボリュームを識別するのに役立つ場合があります。

  • ストレージ ノードの廃止が進行中でないことを確認したか、ノードの廃止手順を一時停止しました。(グリッド マネージャーで、メンテナンス > タスク > 廃止 を選択します。)

  • 拡張が進行中ではないことを確認しました。(グリッド マネージャーで、メンテナンス > タスク > 拡張 を選択します。)

注意 複数のストレージ ノードがオフラインの場合、またはこのグリッド内のストレージ ノードが過去 15 日以内に再構築された場合は、テクニカル サポートに連絡してください。実行しないでください `sn-recovery-postinstall.sh`スクリプト。 15 日以内に 2 つ以上のストレージ ノードで Cassandra を再構築すると、データが失われる可能性があります。
タスク概要

この手順を完了するには、次の高レベルのタスクを実行します。

  • 回復したストレージ ノードにログインします。

  • 実行 `sn-remount-volumes`適切にフォーマットされたストレージボリュームを再マウントするスクリプト。このスクリプトを実行すると、次の処理が行われます。

    • 各ストレージ ボリュームをマウントおよびアンマウントして、XFS ジャーナルを再生します。

    • XFS ファイルの一貫性チェックを実行します。

    • ファイル システムに一貫性がある場合、ストレージ ボリュームが適切にフォーマットされたStorageGRIDストレージ ボリュームであるかどうかを判断します。

    • ストレージ ボリュームが適切にフォーマットされている場合は、ストレージ ボリュームを再マウントします。ボリューム上の既存のデータはそのまま残ります。

  • スクリプトの出力を確認し、問題を解決します。

  • 実行 `sn-recovery-postinstall.sh`スクリプト。このスクリプトを実行すると、次の処理が行われます。

    注意 リカバリ中にストレージノードを再起動しないでください。 sn-recovery-postinstall.sh (ステップ 4) 障害が発生したストレージ ボリュームを再フォーマットし、オブジェクト メタデータを復元します。ストレージノードを再起動する前に `sn-recovery-postinstall.sh`完了すると、起動を試みるサービスにエラーが発生し、 StorageGRIDアプライアンス ノードがメンテナンス モードを終了します。

    • ストレージボリュームを再フォーマットします。 `sn-remount-volumes`スクリプトをマウントできなかったか、形式が不適切であることが判明しました。

      メモ ストレージ ボリュームを再フォーマットすると、そのボリューム上のすべてのデータが失われます。 ILM ルールが複数のオブジェクト コピーを保存するように構成されている場合は、グリッド内の他の場所からオブジェクト データを復元するための追加手順を実行する必要があります。

    • 必要に応じて、ノード上の Cassandra データベースを再構築します。

    • ストレージ ノードでサービスを開始します。

手順

  1. 回復したストレージノードにログインします。

    1. 次のコマンドを入力します。 ssh admin@grid_node_IP

    2. 記載されているパスワードを入力してください `Passwords.txt`ファイル。

    3. ルートに切り替えるには、次のコマンドを入力します。 su -

    4. 記載されているパスワードを入力してください `Passwords.txt`ファイル。

    ルートとしてログインすると、プロンプトは $`に `#。

  2. 最初のスクリプトを実行して、適切にフォーマットされたストレージ ボリュームを再マウントします。

    メモ すべてのストレージ ボリュームが新しく、フォーマットする必要がある場合、またはすべてのストレージ ボリュームに障害が発生した場合は、この手順をスキップして 2 番目のスクリプトを実行し、マウントされていないすべてのストレージ ボリュームを再フォーマットできます。

    1. スクリプトを実行します: sn-remount-volumes

      このスクリプトは、データを含むストレージ ボリューム上で実行すると数時間かかる場合があります。

    2. スクリプトの実行中に出力を確認し、プロンプトに答えます。

      メモ 必要に応じて、 tail -f`スクリプトのログファイルの内容を監視するコマンド(/var/local/log/sn-remount-volumes.log`) 。ログ ファイルには、コマンド ライン出力よりも詳細な情報が含まれています。 
      root@SG:~ # sn-remount-volumes
The configured LDR noid is 12632740

====== Device /dev/sdb ======
Mount and unmount device /dev/sdb and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sdb:
Mount device /dev/sdb to /tmp/sdb-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12632740, volume number 0 in the volID file
Attempting to remount /dev/sdb
Device /dev/sdb remounted successfully

====== Device /dev/sdc ======
Mount and unmount device /dev/sdc and checking file system consistency:
Error: File system consistency check retry failed on device /dev/sdc.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh, this volume and any data on this volume will be deleted. If you only had two copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policies.

Don't continue to the next step if you believe that the data remaining on this volume can't be rebuilt from elsewhere in the grid (for example, if your ILM policy uses a rule that makes only one copy or if volumes have failed on multiple nodes). Instead, contact support to determine how to recover your data.

====== Device /dev/sdd ======
Mount and unmount device /dev/sdd and checking file system consistency:
Failed to mount device /dev/sdd
This device could be an uninitialized disk or has corrupted superblock.
File system check might take a long time. Do you want to continue? (y or n) [y/N]? y

Error: File system consistency check retry failed on device /dev/sdd.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh, this volume and any data on this volume will be deleted. If you only had two copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policies.

Don't continue to the next step if you believe that the data remaining on this volume can't be rebuilt from elsewhere in the grid (for example, if your ILM policy uses a rule that makes only one copy or if volumes have failed on multiple nodes). Instead, contact support to determine how to recover your data.

====== Device /dev/sde ======
Mount and unmount device /dev/sde and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sde:
Mount device /dev/sde to /tmp/sde-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12000078, volume number 9 in the volID file
Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      出力例では、1 つのストレージ ボリュームが正常に再マウントされ、3 つのストレージ ボリュームにエラーが発生しました。

      • `/dev/sdb`XFS ファイル システムの整合性チェックに合格し、有効なボリューム構造があったため、正常に再マウントされました。スクリプトによって再マウントされたデバイス上のデータは保持されます。

      • `/dev/sdc`ストレージ ボリュームが新規または破損しているため、XFS ファイル システムの整合性チェックに失敗しました。

      • `/dev/sdd`ディスクが初期化されていないか、ディスクのスーパーブロックが破損しているため、マウントできませんでした。スクリプトがストレージ ボリュームをマウントできない場合、ファイル システムの整合性チェックを実行するかどうかを尋ねられます。

        • ストレージ ボリュームが新しいディスクに接続されている場合は、プロンプトに N と答えます。新しいディスク上のファイルシステムをチェックする必要はありません。

        • ストレージ ボリュームが既存のディスクに接続されている場合は、プロンプトに Y と答えます。ファイル システム チェックの結果を使用して、破損の原因を特定できます。結果は `/var/local/log/sn-remount-volumes.log`ログファイル。

      • `/dev/sde`XFSファイルシステムの整合性チェックに合格し、有効なボリューム構造を持っていましたが、 `volID`ファイルがこのストレージノードのIDと一致しませんでした（ `configured LDR noid`上部に表示されます。このメッセージは、このボリュームが別のストレージ ノードに属していることを示します。

  3. スクリプトの出力を確認し、問題を解決します。

    注意 ストレージ ボリュームが XFS ファイル システムの整合性チェックに失敗した場合、またはマウントできなかった場合は、出力内のエラー メッセージを慎重に確認してください。実行することの意味を理解しなければなりません `sn-recovery-postinstall.sh`これらの巻のスクリプト。

    1. 結果に、予期したすべてのボリュームのエントリが含まれていることを確認します。ボリュームがリストされていない場合は、スクリプトを再実行します。

    2. マウントされたすべてのデバイスのメッセージを確認します。ストレージ ボリュームがこのストレージ ノードに属していないことを示すエラーがないことを確認します。

      この例では、/dev/sde の出力に次のエラー メッセージが含まれています。

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      注意 ストレージ ボリュームが別のストレージ ノードに属していると報告された場合は、テクニカル サポートに問い合わせてください。実行すると `sn-recovery-postinstall.sh`スクリプトを実行すると、ストレージ ボリュームが再フォーマットされ、データが失われる可能性があります。

    3. ストレージ デバイスをマウントできなかった場合は、デバイス名をメモし、デバイスを修復または交換します。

      メモ マウントできなかったストレージ デバイスは修復または交換する必要があります。

      デバイス名はボリュームIDを検索するために使用します。これは、 `repair-data`オブジェクト データをボリュームに復元するスクリプト (次の手順)。

    4. マウントできないデバイスをすべて修復または交換した後、 `sn-remount-volumes`スクリプトを再度実行して、再マウント可能なすべてのストレージ ボリュームが再マウントされたことを確認します。

      注意 ストレージ ボリュームをマウントできない場合、または正しくフォーマットされていない場合は、次の手順に進むと、ボリュームとボリューム上のすべてのデータが削除されます。オブジェクト データのコピーが 2 つある場合は、次の手順 (オブジェクト データの復元) を完了するまで、コピーは 1 つだけになります。
    注意 実行しないでください `sn-recovery-postinstall.sh`障害が発生したストレージ ボリュームに残っているデータをグリッド内の他の場所から再構築できないと思われる場合は、スクリプトを実行してください (たとえば、ILM ポリシーで 1 つのコピーのみを作成するルールが使用されている場合や、複数のノードでボリュームに障害が発生した場合など)。代わりに、テクニカル サポートに連絡して、データの回復方法を確認してください。

  4. 実行 sn-recovery-postinstall.sh`スクリプト： `sn-recovery-postinstall.sh

    このスクリプトは、マウントできなかったストレージ ボリュームや、不適切にフォーマットされていることが判明したストレージ ボリュームを再フォーマットし、必要に応じてノード上の Cassandra データベースを再構築し、ストレージ ノード上でサービスを開始します。

    次の点に注意してください。

    • スクリプトの実行には数時間かかる場合があります。

    • 通常、スクリプトの実行中は SSH セッションをそのままにしておく必要があります。

    • SSH セッションがアクティブな間は、Ctrl+C を押さないでください。

    • ネットワークの中断が発生して SSH セッションが終了した場合、スクリプトはバックグラウンドで実行されますが、リカバリ ページから進行状況を確認できます。

    • ストレージ ノードが RSM サービスを使用する場合、ノード サービスが再起動されると、スクリプトが 5 分間停止したように見えることがあります。この 5 分間の遅延は、RSM サービスが初めて起動するときに必ず発生します。

      メモ RSM サービスは、ADC サービスを含むストレージ ノード上に存在します。
    メモ 一部のStorageGRIDリカバリ手順では、Reaper を使用して Cassandra の修復を処理します。関連するサービスまたは必要なサービスが開始されるとすぐに、修復が自動的に実行されます。スクリプト出力に「reaper」または「Cassandra repair」と記載されていることに気付くかもしれません。修復が失敗したことを示すエラー メッセージが表示された場合は、エラー メッセージに示されているコマンドを実行します。

  5. として `sn-recovery-postinstall.sh`スクリプトが実行されたら、グリッド マネージャーのリカバリ ページを監視します。

    回復ページの進行状況バーとステージ列には、回復の高レベルのステータスが表示されます。 `sn-recovery-postinstall.sh`スクリプト。

    グリッド管理インターフェースでの回復の進行状況を示すスクリーンショット

  6. その後 `sn-recovery-postinstall.sh`スクリプトがノード上でサービスを開始すると、スクリプトによってフォーマットされた任意のストレージ ボリュームにオブジェクト データを復元できます。

    スクリプトは、Grid Manager ボリューム復元プロセスを使用するかどうかを尋ねます。

    • ほとんどの場合、"グリッド マネージャーを使用してオブジェクト データを復元する" 。答え `y`グリッド マネージャーを使用します。

    • まれなケースとして、テクニカルサポートから指示があった場合や、交換ノードのオブジェクトストレージに使用できるボリュームが元のノードより少ないことが分かっている場合は、"オブジェクトデータを手動で復元する"使用して repair-data`スクリプト。これらのケースのいずれかに該当する場合は、回答してください。 `n 。

      メモ

      答えると `n`グリッド マネージャーのボリューム復元プロセスを使用する (オブジェクト データを手動で復元する)

      • Grid Manager を使用してオブジェクト データを復元することはできません。

      • Grid Manager を使用して、手動復元ジョブの進行状況を監視できます。

      選択すると、スクリプトが完了し、オブジェクト データを回復するための次の手順が表示されます。これらの手順を確認した後、任意のキーを押してコマンド ラインに戻ります。