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

StorageGRIDストレージボリュームの再マウントと再フォーマット（手動手順）

PDF

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

開始する前に

  • 交換が必要であると判明している故障したストレージボリュームのハードウェアは、既に交換済みです。

    `sn-remount-volumes`スクリプトを実行すると、障害が発生した他のストレージボリュームを特定するのに役立つ場合があります。

  • ストレージノードの廃止処理が進行中ではないことを確認したか、またはノードの廃止処理を一時停止しました。（グリッドマネージャーで、Maintenance > Tasks > Decommission を選択します。）

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

  • "ストレージノードのシステムドライブ復旧に関する警告を確認しました"があります。

    注意 複数のストレージノードがオフラインになっている場合は、テクニカルサポートにお問い合わせください。 `sn-recovery-postinstall.sh`スクリプトは実行しないでください。
タスク概要

この手順を完了するには、以下の概要タスクを実行します：

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

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

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

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

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

    • ストレージボリュームが正しくフォーマットされている場合、ストレージボリュームを再マウントします。当該ボリュームに関する既存のデータはすべてそのまま保持されます。

  • スクリプトの出力結果を確認し、問題があれば解決してください。

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

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

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

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

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

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

手順

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

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

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

    3. 以下のコマンドを入力して root に切り替えます： su -

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

    rootとしてログインすると、プロンプトが `$`から `#`に変わります。

  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ファイル内のLDRノードIDがこのストレージノードの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つだけになります。
    注意 障害が発生したストレージボリュームに残っているデータがグリッド内の他の場所から再構築できないと思われる場合（たとえば、ILM ポリシーで 1 つのコピーのみを作成するルールを使用している場合、またはボリュームが複数のノードで障害を起こしている場合）は、 `sn-recovery-postinstall.sh`スクリプトを実行しないでください。代わりに、テクニカルサポートに連絡して、データの復旧方法を確認してください。

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

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

    以下の点にご注意ください。

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

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

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

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

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

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

  5. `sn-recovery-postinstall.sh`スクリプトが実行される間、Grid Manager のリカバリページを監視してください。

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

    Grid Management Interfaceで復旧の進捗状況を示すスクリーンショット

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

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

    • ほとんどの場合、"Grid Managerを使用してオブジェクトデータを復元する"。回答 y Grid Manager を使用します。

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

      メモ

      Grid Manager のボリューム復元プロセス（オブジェクトデータを手動で復元する）の使用に `n`と回答した場合：

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

      • Grid Manager を使用すると、手動復元作業の進捗状況を監視できます。

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