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

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

開始する前に

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

タスク概要

接続されているストレージのチェック、サーバに接続されたストレージ ボリュームの検索とマウント、さらにボリュームがStorageGRID Webscaleのオブジェクト ストアと同じように構造化されていることの確認を行うために、手動でスクリプトを実行する必要があります。マウントできないストレージ ボリュームや、このチェックに合格しなかったストレージ ボリュームは、障害が発生しているとみなされて再フォーマットされます。対象のストレージ ボリューム上のデータはすべて失われます。

障害ストレージ ボリュームの特定とリカバリには、次の2つのリカバリ スクリプトを使用します。

sn-recovery-postinstall.shスクリプトが完了すると、アプライアンスでStorageGRID Webscaleソフトウェアのインストールが完了し、アプライアンスが自動的にリブートされます。リブートが完了するまで待ってから、リカバリしたストレージ ボリュームへのオブジェクト データのリストアに進んでください。

手順

  1. サービス ラップトップから、リカバリしたストレージ ノードにログインします。
    1. 次のコマンドを入力します:ssh admin@grid_node_IP
    2. Passwords.txtファイルに含まれているパスワードを入力します。
    3. 次のコマンドを入力してrootに切り替えます:su -
    4. Passwords.txtファイルに含まれているパスワードを入力します。
    rootとしてログインすると、プロンプトが$から#に変わります。
  2. 一部またはすべてのストレージ ボリュームに有効なデータが含まれている可能性がある場合は、次の手順を実行します。
    1. ストレージ ボリュームをチェックして再マウントするスクリプトを実行します。sn-remount-volumes
      このスクリプトは、保持されているストレージ ボリュームを確認して、再マウントします。この例では、/dev/sddは問題があったため再マウントされませんでした。
      root@SG:~ # sn-remount-volumes
      The configured LDR noid is 12632740
      Attempting to remount /dev/sdg
      Found LDR node id 12632740, volume number 4 in the volID file
      Device /dev/sdg remounted successfully
      Attempting to remount /dev/sdf
      Found LDR node id 12632740, volume number 3 in the volID file
      Device /dev/sdf remounted successfully
      Attempting to remount /dev/sde
      Found LDR node id 12632740, volume number 2 in the volID file
      Device /dev/sde remounted successfully
      Failed to mount device /dev/sdd
      Attempting to remount /dev/sdc
      Found LDR node id 12632740, volume number 0 in the volID file
      Device /dev/sdc remounted successfully
      
      スクリプトで検出されてマウントされたデバイス上のデータは保持されますが、このノードにあるその他のデータはすべて失われ、他のノードからリカバリする必要があります。
    2. スクリプトでマウントされたデバイス、またはマウントできなかったデバイスのリストを確認します。
      • 有効であることがわかっているボリュームがスクリプトでマウントされていない場合は、スクリプトを終了して調査する必要があります。スクリプトによるデバイスのマウントを阻害している問題をすべて解決したら、もう一度スクリプトを実行します。

      • マウントできなかったストレージ デバイスはすべて修理または交換する必要があります。
      注:tail -fコマンドを使用して、スクリプトのログ ファイル(/var/local/log/sn-remount-volumes.log)の内容を監視できます。このログ ファイルには、コマンドラインの出力よりも詳細な情報が記録されています。
    3. 各障害ストレージ ボリュームのデバイス名を記録し、そのボリュームID(var/local/rangedb/number)を特定します。
      障害ボリュームのボリュームIDは以降の手順「ストレージ ボリュームへのオブジェクト データのリストア」で必要になります(データのリカバリに使用するスクリプトに入力します)。
      次の例では、スクリプトで/dev/sddのマウントが失敗しています。
      Attempting to remount /dev/sde
      Found LDR node id 12632740, volume number 2 in the volID file
      Device /dev/sde remounted successfully
      Failed to mount device /dev/sdd
      Attempting to remount /dev/sdc
      Found LDR node id 12632740, volume number 0 in the volID file
      Device /dev/sdc remounted successfully
      
      この場合、/dev/sddはボリューム番号1に対応します。
  3. sn-recovery-postinstall.shを実行して、マウントされていない(障害)ストレージ ボリュームをすべて再フォーマットし、必要に応じてCassandraを再構築し、すべてのStorageGRID Webscaleサービスを開始します。
    スクリプトによってポストインストール ステータスが出力されます。
    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/sdc
    Successfully formatted /dev/sdd with UUID d6533e5f-7dfe-4a45-af7c-08ae6864960a
    Skipping in use device /dev/sde
    Skipping in use device /dev/sdf
    Skipping in use device /dev/sdg
    All devices processed
    Creating Object Stores for LDR
    Generating Grid Interface Configuration file
    LDR initialization complete
    Setting up Cassandra directory structure
    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.
    
    Cassandra is down.
    
    Rebuild may take 12-24 hours. Do not stop or pause the rebuild.
    If the rebuild was stopped or paused, re-run this command.
    
    Removing Cassandra commit logs
    Removing Cassandra SSTables
    Updating timestamps of the Cassandra data directories.
    Starting ntp service.
    Starting cassandra service.
    Running nodetool rebuild.
    Done. Cassandra database successfully rebuilt.
    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.
    
    sn-recovery-postinstall.shスクリプトが実行されている間、グリッド管理インターフェイスで進行状況が更新されます。

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

    グリッド管理インターフェイスにおけるリカバリの進行状況を示す2つ目のスクリーンショット
  4. E5600SGコントローラまたはE5700SGコントローラのIPアドレスを使用して「http://Controller_IP:8080」と入力し、StorageGRID Webscaleアプライアンス インストーラの[Monitor Install]ページに戻ります。
    [Monitor Install]ページには、sn-recovery-postinstall.shスクリプトが実行されている間のインストールの進行状況が表示されます。
  5. アプライアンスが自動的にリブートするまで待ちます。
  6. ノードがリブートしたら、リカバリしたノードのソフトウェア バージョンを確認します。
    1. [Grid]を選択します。
    2. [site] > [grid node] > [SSM] > [Services]を選択します。
    3. インストールされているバージョンを[Packages]フィールドで確認します。
    4. このバージョンが、プライマリ管理ノードのバージョンと、以前に適用されたホットフィックスも含めて一致することを確認します。
    5. ソフトウェア バージョンが一致しない場合は、リカバリしたノードにホットフィックスを手動で再適用する必要があります。
  7. 再構築されたすべてのストレージ ボリュームにオブジェクト データをリストアします。手順については、「オブジェクト データのリストア」を参照してください。