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

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

共同作成者
PDF

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

作業を開始する前に

  • 障害が発生したストレージボリュームのうち、必要と判断した場合はハードウェアを交換しておく必要があります。

    を実行します sn-remount-volumes スクリプトを使用すると、障害ストレージボリュームを追加で特定できる場合があります。

  • ストレージノードの運用停止処理が進行中でないこと、またはノードの手順 の運用停止処理が一時停止されていることを確認しておきます（ Grid Manager で、 * maintenance * > * Tasks * > * Decommission * を選択します）。

  • 拡張が進行中でないことを確認しておきます（ Grid Manager で、 * maintenance * > * Tasks * > * Expansion * を選択します。）

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

この手順 を完了するには、次の作業を行います。

  • リカバリされたストレージノードにログインします。

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

    • 各ストレージボリュームをマウントしてアンマウントし、 XFS ジャーナルをリプレイします。

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

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

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

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

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

    重要 リカバリ中は、を実行する前にストレージノードをリブートしないでください sn-recovery-postinstall.sh （手順4）障害ストレージボリュームの再フォーマットとオブジェクトメタデータのリストア実行前にストレージノードをリブートしています sn-recovery-postinstall.sh completesを指定すると、サービスが開始しようとするとエラーが発生し、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 Webscale will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policy.

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 Webscale will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policy.

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ファイルシステムの整合性チェックに合格し、ボリューム構造が有効でした。ただし、のLDRノードIDです 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を検索します。この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 スクリプトが実行され、Grid Managerのリカバリページが監視されます。

    のステータスの概要は、リカバリページの進捗状況バーとステージ列で確認できます sn-recovery-postinstall.sh スクリプト：

    グリッド管理インターフェイスにおけるリカバリの進行状況を示すスクリーンショット

  6. のあとに入力します sn-recovery-postinstall.sh スクリプトによってノードのサービスが開始されました。スクリプトでフォーマットされた任意のストレージボリュームにオブジェクトデータをリストアできます。

    オブジェクトデータを手動でリストアするかどうかを確認するメッセージが表示されます。

    • ほとんどの場合、あなたはすべきです "Grid Managerを使用してオブジェクトデータをリストアする"。回答 n をクリックしてください。

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

      メモ

      回答 を選択した場合 y オブジェクトデータを手動でリストアするには：

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

      • 手動リストアジョブの進捗状況は、Grid Managerを使用して監視できます。