Skip to main content
此產品有較新版本可以使用。
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

重新掛載及重新格式化應用裝置儲存磁碟區（以下稱「手動步驟」）

貢獻者
PDF

您必須手動執行兩個指令碼、才能重新掛載保留的儲存磁碟區、並重新格式化任何故障的儲存磁碟區。第一個指令碼會重新掛載已正確格式化為StorageGRID 「循環儲存磁碟區」的磁碟區。第二個指令碼會重新格式化任何未掛載的磁碟區、視需要重新建置Cassandra資料庫、然後啟動服務。

您需要的產品

  • 您已更換硬體、以更換已知需要更換的任何故障儲存磁碟區。

    執行「shn-remount-volume」指令碼、可能有助於識別其他故障儲存磁碟區。

  • 您已檢查儲存節點汰換是否在進行中、或您已暫停節點取消委任程序。（在Grid Manager中、選取* maintenance > Tasks > Decompress*。）

  • 您已檢查擴充是否在進行中。（在Grid Manager中、選取* maintenance > Tasks > Expansion *。）

警告 如果有多個儲存節點離線、或是此網格中的儲存節點在過去15天內已重建、請聯絡技術支援部門。請勿執行「shn-recovery -postinstall.sh」指令碼。在兩個或多個儲存節點上重建Cassandra、彼此之間的時間不超過15天、可能會導致資料遺失。
關於這項工作

若要完成此程序、請執行下列高階工作：

  • 登入恢復的儲存節點。

  • 執行「shn-remount-volume」指令碼、重新掛載格式正確的儲存Volume。執行此指令碼時、會執行下列動作：

    • 掛載和卸載每個儲存磁碟區、以重新播放XFS日誌。

    • 執行XFS檔案一致性檢查。

    • 如果檔案系統一致、請判斷儲存磁碟區是否為格式正確StorageGRID 的等化儲存磁碟區。

    • 如果儲存磁碟區格式正確、請重新掛載儲存磁碟區。磁碟區上的任何現有資料均保持不變。

  • 檢閱指令碼輸出並解決任何問題。

  • 執行「sh-recovery -postinstall.sh」指令碼。執行此指令碼時、會執行下列動作。

    重要 請勿在恢復期間重新啟動儲存節點、再執行「sh-recovery -postinstall.sh」（步驟4）重新格式化故障的儲存磁碟區並還原物件中繼資料。在「sh-recovery -postinstall.sh」完成之前重新啟動儲存節點、會導致嘗試啟動的服務發生錯誤、StorageGRID 並使該應用裝置節點離開維護模式。

    • 重新格式化無法掛載或被發現格式不正確的任何「n重新掛載磁碟區」指令碼的儲存磁碟區。

      註 如果重新格式化儲存磁碟區、則該磁碟區上的任何資料都會遺失。您必須執行其他程序、從網格中的其他位置還原物件資料、前提是ILM規則已設定為儲存多個物件複本。

    • 視需要在節點上重新建置Cassandra資料庫。

    • 啟動儲存節點上的服務。

步驟

  1. 登入恢復的儲存節點：

    1. 輸入下列命令：「sh admin@grid_node_ip`」

    2. 輸入「passwords.txt」檔案中所列的密碼。

    3. 輸入下列命令以切換至root：「u -」

    4. 輸入「passwords.txt」檔案中所列的密碼。

    以root登入時、提示會從「$」變更為「#」。

  2. 執行第一個指令碼、重新掛載任何格式正確的儲存磁碟區。

    註 如果所有的儲存磁碟區都是新的且需要格式化、或是所有的儲存磁碟區都失敗、您可以跳過此步驟並執行第二個指令碼、重新格式化所有未掛載的儲存磁碟區。

    1. 執行指令碼：「n-remount-volume」

      此指令碼可能需要數小時才能在含有資料的儲存磁碟區上執行。

    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.

      在範例輸出中、已成功重新掛載一個儲存磁碟區、三個儲存磁碟區發生錯誤。

      • dev/sdb'通過XFS檔案系統一致性檢查、並具有有效的Volume結構、因此已成功重新掛載。由指令碼重新掛載的裝置上的資料會保留下來。

      • 由於儲存磁碟區是新的或毀損、所以「dev/sdc」無法執行XFS檔案系統一致性檢查。

      • 由於磁碟未初始化或磁碟的超級區塊毀損、因此無法掛載「dev/sdd」。當指令碼無法掛載儲存磁碟區時、會詢問您是否要執行檔案系統一致性檢查。

        • 如果儲存磁碟區已附加至新磁碟、請在提示字元中回答* N*。您不需要檢查新磁碟上的檔案系統。

        • 如果儲存磁碟區已附加至現有磁碟、請在提示字元中回答* Y*。您可以使用檔案系統檢查的結果來判斷毀損的來源。結果會儲存在/var/local/log/sn-remount-Volumes.log記錄檔中。

      • dev/sde'通過XFS檔案系統一致性檢查、並具有有效的Volume結構；不過、「volID」檔案中的LdR節點ID與此儲存節點的ID（頂端顯示的「已設定的LdR noid」）不符。此訊息表示此磁碟區屬於另一個儲存節點。

  3. 檢閱指令碼輸出並解決任何問題。

    重要 如果儲存磁碟區未通過XFS檔案系統一致性檢查或無法掛載、請仔細檢閱輸出中的錯誤訊息。您必須瞭解在這些磁碟區上執行「sh-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.
      警告 如果儲存磁碟區被回報為屬於其他儲存節點、請聯絡技術支援部門。如果您執行「shn-recovery -postinstall.sh」指令碼、儲存磁碟區將會重新格式化、這可能會導致資料遺失。

    3. 如果無法掛載任何儲存裝置、請記下裝置名稱、然後修復或更換裝置。

      註 您必須修復或更換任何無法掛載的儲存裝置。

      您將使用裝置名稱來查詢磁碟區ID、這是執行「重新配對資料」指令碼以將物件資料還原至磁碟區時所需的輸入（下一步驟）。

    4. 修復或更換所有無法掛載的裝置之後、請再次執行「shn-remount-volume」指令碼、確認所有可重新掛載的儲存磁碟區均已重新掛載。

      重要 如果儲存磁碟區無法掛載或格式不正確、而您繼續下一步、則磁碟區和磁碟區上的任何資料都會被刪除。如果您有兩份物件資料複本、則在完成下一個程序（還原物件資料）之前、只會有一份複本。
    警告 如果您認為無法從網格的其他位置重建故障儲存磁碟區上的剩餘資料（例如、如果您的ILM原則使用只製作一個複本的規則、或是多個節點上的磁碟區故障）、請勿執行「sh-recovery -postinstall.sh」指令碼。請聯絡技術支援部門、以決定如何恢復資料。

  4. 執行「shn-recovery -postinstall.sh」指令碼：「n-recovery -postinstall.sh」

    此指令碼會重新格式化任何無法掛載或被發現格式不正確的儲存磁碟區；如有需要、可在節點上重新建置Cassandra資料庫；並在儲存節點上啟動服務。

    請注意下列事項：

    • 指令碼可能需要數小時才能執行。

    • 一般而言、您應該在指令碼執行時、單獨保留SSH工作階段。

    • SSH工作階段處於作用中狀態時、請勿按* Ctrl+C*。

    • 如果發生網路中斷、指令碼會在背景執行、並終止SSH工作階段、但您可以從「恢復」頁面檢視進度。

    • 如果儲存節點使用的是RSM服務、則當節點服務重新啟動時、指令碼可能會停滯5分鐘。每當首次啟動RSM服務時、預期會有5分鐘的延遲時間。

      註 其中包含了ADC服務的儲存節點上有此RSM服務。
    註 部分StorageGRID 還原程序會使用Reaper來處理Cassandra的修復作業。一旦相關或必要的服務開始、系統就會自動進行修復。您可能會注意到指令碼輸出中提到「Shaper」或「Cassandra repair」。 如果您看到指出修復失敗的錯誤訊息、請執行錯誤訊息中指示的命令。

  5. 當「sh-recovery -postinstall.sh」指令碼執行時、請在Grid Manager中監控「恢復」頁面。

    「恢復」頁面上的進度列和「階段」欄提供「sh-recovery -postinstall.sh」指令碼的高層級狀態。

    顯示Grid Management Interface恢復進度的快照

在節點上啟動「shn-recovery -postinstall.sh」指令碼之後、您可以將物件資料還原至任何由指令碼格式化的儲存磁碟區、如下一步驟所述。

相關資訊

檢閱儲存節點系統磁碟機恢復的警告

將物件資料還原至應用裝置的儲存磁碟區