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

2つのスクリプトを手動で実行して、問題のないストレージ ボリュームを再マウントし、障害が発生したストレージ ボリュームがある場合は再フォーマットする必要があります。最初のスクリプトは、StorageGRIDストレージ ボリュームとして適切にフォーマットされているボリュームを再マウントします。2番目のスクリプトは、マウントされていないボリュームを再フォーマットし、必要に応じて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.
      
      Do not continue to the next step if you believe that the data remaining on
      this volume cannot 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.
      
      Do not continue to the next step if you believe that the data remaining on
      this volume cannot 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を検索します。この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セッションが終了した場合、このスクリプトはバックグラウンドで実行されますが、進行状況は[Recovery]ページで確認できます。
    • ストレージ ノードがRSMサービスを使用している場合は、ノードのサービスが再開する間スクリプトが5分間停止しているように見えることがあります。この5分間の遅延は、RSMサービスが初めてブートするたびに発生します。
      注: RSMサービスは、ADCサービスを含むストレージ ノードにあります。
  5. sn-recovery-postinstall.shスクリプトの実行中は、Grid Managerの[Recovery]ページを監視します。
    [Recovery]ページ上の進捗状況バーと[Stage]列に、sn-recovery-postinstall.shスクリプトのステータスの概要が表示されます。
    グリッド管理インターフェイスにおけるリカバリの進行状況を示すスクリーンショット

終了後の操作

sn-recovery-postinstall.shスクリプトによってノードのサービスが開始されたら、スクリプトでフォーマットされたストレージ ボリュームにオブジェクト データをリストアできます(次の手順を参照)。