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

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

1. サービス ラップトップから、リカバリしたストレージ ノードにログインします。
   1. 次のコマンドを入力します：ssh admin@grid_node_IP
   2. Passwords.txtファイルに含まれているパスワードを入力します。
   3. 次のコマンドを入力してrootに切り替えます：su -
   4. Passwords.txtファイルに含まれているパスワードを入力します。
   rootとしてログインすると、プロンプトが$から#に変わります。
2. 最初のスクリプトを実行し、適切にフォーマットされたストレージ ボリュームを再マウントします。
   注:すべてのストレージ ボリュームが新規で、フォーマットが必要な場合、またはすべてのストレージ ボリュームで障害が発生した場合は、この手順を省略して手順4に進んでも構いません。
   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スクリプトの実行によって、これらのボリュームに生じる影響を把握する必要があります。
   1. 想定しているすべてのボリュームのエントリが結果に含まれているかどうかを確認します。表示されていないボリュームがあった場合は、スクリプトを再実行します。
   2. マウントされたすべてのデバイスのメッセージを確認します。ストレージ ボリュームがこのストレージ ノードに属していないことを示すエラーがないことを確認します。
      例
      /dev/sdeの出力に、次のエラー メッセージが含まれています。

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      ストレージ ボリュームが別のストレージ ノードに属しているというメッセージが表示された場合は、ディスクを交換または取り外してから、sn-remount-volumesスクリプトを再実行して、問題が解決されたことを確認します。

      リカバリしているストレージ ノードのノードIDは、スクリプトの最上部で確認できます（「configured LDR noid」）。他のストレージ ノードのノードIDはGrid Managerで検索できます。[Support] > [Grid Topology] > [Site] > [Storage Node] > [LDR] > [Overview]を選択します。

      注意:

      問題を解決できない場合は、テクニカル サポートにお問い合わせください。sn-recovery-postinstall.shスクリプトを実行すると、ストレージ ボリュームが再フォーマットされますが、それによってデータが失われる場合があります。
   3. マウントできなかったデバイスのメッセージを確認し、障害が発生した各ストレージ ボリュームのデバイス名をメモします。
      注:マウントできなかったストレージ デバイスはすべて修理または交換する必要があります。
      デバイス名を使用してボリュームIDを検索します。このIDは、次の手順（オブジェクト データのリストア）でrepair-dataスクリプトを実行するときに必要な入力情報です。
   4. sn-remount-volumesスクリプトを再実行し、有効なストレージ ボリュームがすべて再マウントされたことを確認します。
   注意:ストレージ ボリュームをマウントできなかった場合、またはストレージ ボリュームが適切にフォーマットされなかった場合に、手順4に進むと、ボリュームとそのボリューム上のデータは削除されます。オブジェクト データのコピーが2つあった場合、次の手順（オブジェクト データのリストア）を実行するまで、コピーは1つのみになります。

   注意:

   このボリューム上に残っているデータを、グリッド内の他の場所で再構築することができないと考えられる場合は、sn-recovery-postinstallスクリプトを実行しないでください（ILMポリシーでコピーを1つだけ作成するルールが使用されている場合や、複数のノードでボリュームに障害が発生した場合など）。その代わりに、テクニカル サポートに問い合わせて、データのリカバリ方法を確認してください。
4. 2番目のスクリプトを実行し、マウントされていない（障害が発生した）ストレージ ボリュームをすべて再フォーマットし、必要に応じてCassandraを再構築してから、ストレージ ノードでサービスを開始します。sn-recovery-postinstall.sh
5. スクリプトの実行中、Grid Managerの[Recovery]ページを監視し、コマンド ラインの出力を確認します。
   [Recovery]ページ上の進捗状況バーと[Stage]列に、sn-recovery-postinstall.shスクリプトのステータスの概要が表示されます。
   
   
   スクリプトの出力で、詳細なステータス情報を確認できます。
   例

   root@SG:~ # sn-recovery-postinstall.sh
   Starting Storage Node recovery post installation.
   Reformatting all unmounted disks as rangedbs
   Formatting devices that are not in use...
   Skipping in use device /dev/sdb
   Successfully formatted /dev/sdc with UUID d6533e5f-7dfe-4a45-af7c-08ae6864960a
   Successfully formatted /dev/sdd with UUID a2534c4b-6bcc-3a12-fa4e-88ee8621452c
   Skipping in use device /dev/sde
   All devices processed
   Creating Object Stores for LDR
   Generating Grid Interface Configuration file
   LDR initialization complete
   Cassandra data directory is empty.
   Cassandra needs rebuilding.
   Rebuild the Cassandra database for this Storage Node.
   
   ATTENTION: Do not execute this script when two or more Storage Nodes have failed
   or been offline at the same time. Doing so may result in data loss. Contact technical support.
   
   ATTENTION: Do not rebuild more than a single node within a 15 day period.
   Rebuilding 2 or more nodes within 15 days of each other may result in data loss.
   
   Enter 'y' to rebuild the Cassandra database for this Storage Node. [y/N]? y
   Cassandra is down.
   
   Rebuilding may take 12-24 hours. Do not stop or pause the rebuild.
   If the rebuild was stopped or paused, re-run this command.
   
   Cassandra node needs to be bootstrapped.
   Cleaning Cassandra directories for node.
   Adding replace_address_first_boot flag.
   Starting ntp service.
   Starting nginx service.
   Starting dynip service.
   Starting cassandra service.
   Cassandra mode is NORMAL. No bootstrap resume required.
   Rebuild was successful.
   Not starting services due to --do-not-start-services argument.
   
   Updating progress on primary Admin Node
   Starting services
   
   #######################################
           STARTING SERVICES
   #######################################
   
   Starting Syslog daemon
   Stopping system logging: syslog-ng.
   Starting system logging: syslog-ng.
   Starting SSH
   Starting OpenBSD Secure Shell server: sshd.
   No hotfix to install
   starting persistence ... done
   remove all error states
   starting all services
   services still stopped: acct adc ade-exporter cms crr dds idnt kstn ldr net-monitor nginx node-exporter ssm
   starting ade-exporter
   Starting service ade-exporter in background
   starting cms
   Starting service cms in background
   starting crr
   Starting service crr in background
   starting net-monitor
   Starting service net-monitor in background
   starting nginx
   Starting service nginx in background
   starting node-exporter
   Starting service node-exporter in background
   starting ssm
   Starting service ssm in background
   services still stopped: acct adc dds idnt kstn ldr
   starting adc
   Starting service adc in background
   starting dds
   Starting service dds in background
   starting ldr
   Starting service ldr in background
   services still stopped: acct idnt kstn
   starting acct
   Starting service acct in background
   starting idnt
   Starting service idnt in background
   starting kstn
   Starting service kstn in background
   all services started
   Starting service servermanager in background
   Restarting SNMP services::  snmpd
   
   #######################################
              SERVICES STARTED
   #######################################
   
   Loaded node_id from server-config
   node_id=5611d3c9-45e9-47e4-99ac-cd16ef8a20b9
   Storage Node recovery post installation complete.
   Object data must be restored to the storage volumes.
   Triggering bare-metal reboot of SGA to complete installation.
   SGA install phase 2: awaiting chainboot.

6. コンピューティング コントローラのIPアドレスを使用して「http://Controller_IP:8080」と入力し、StorageGRID Webscaleアプライアンス インストーラの[Monitor Install]ページに戻ります。
   [Monitor Install]ページには、sn-recovery-postinstall.shスクリプトが実行されている間のインストールの進行状況が表示されます。
7. アプライアンスが自動的にリブートされるまで待ってから、次の手順に進みます。