Avamar：Avamar 上暫停的磁碟分割、等量和 hfscheck 故障

1.Avamar Administrator Server UI 中可能會出現下列錯誤。此訊息可能會產生 Dial Home 服務要求 （SR）：

Symptom Code: 22632, Desc: A server disk has become suspended.

2.與以下項目相關的 WARN 訊息： perfbeat 執行緒會報告在以下位置的資料儲存節點上： /data01/cur/gsan.log：

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3.可使用 status.dpn 輸出顯示磁碟具有掛起
的條帶：（此輸出僅在出現“WARN <1084>”時生成。

例如：

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

此輸出顯示有 2374 個暫停的等量。

4.可使用 hfschec如果磁碟分割在 hfscheck 正在運行。錯誤範例來自 /data01/hfscheck/err.log 或 /data01/cur/err.log 是： 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

默認情況下，gsan 定期每五分鐘「測試」一次 I/O 子系統，方法是從數據分區執行小型讀取。

它會驗證讀取效能是否為正常效能的 10%。

在下面的示例中，消息指示在生成警告消息的特定節點上，長時間試用的平均讀取性能，而 hfscheck 正在執行的速率約為 54.03 MB/秒。然而，在此特定測試中，實際效能為 0.57 MB/秒，低於平均值 10% 的「限制」，亦即 5.4029 MB/秒。

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

此測試的最初目的是提供一些警告，表明存在一些問題。 I/O 導致讀取效能過慢的子系統。 

在這種情況下，低於「平均」磁碟的 10% I/O 演奏。

可使用 perftriallimit 指定之前必須超出容錯的連續磁碟讀取測試次數 perfbeat 懷疑磁碟可能已降級。

可使用 perfinterval （預設為 300 秒或 5 分鐘） 指定每個之間的等待時間 perftriallimit 試。

當 perfbeat 懷疑磁碟已降級，它會告訴 gsan 以進入冷狀態 （停止所有與磁碟相關的活動）。 

它最多等待 20 分鐘 （硬連線） gsan 以在超時且不掛起磁碟之前達到此狀態。

如果達到冷態，則 perfbeat 執行 perfcoldtriallimit （預設值 4） 更多讀取測試間隔 perfcoldinterval （預設相隔 30 秒）。

只有當所有這些測試都表明磁碟仍在降級時，磁碟才會暫停。

暫停磁碟的可能原因：

• 當試圖達到冷狀態時，gsan 總是等待至少一分鐘（硬連線）。它也會等待所有擱置中的 gsan 磁碟 I/O 完成或暫停其操作的相關活動。但是，在達到冷狀態後，作業系統仍可能仍在執行磁碟 I/O，例如清除其緩存。此刷新活動是磁碟不必要地掛起的原因的一種可能解釋。隨著記憶體量越大，需要刷新的緩存數據就越多。

• 另一個可能的解釋是，效能歷程記錄資訊無法準確預測在各種 gsan 活動因為 gsan's 行為變化太快，歷史記錄無法反映（歷史記錄是過去 10 天性能測量的平均值）。

• 另一種可能的解釋是可能存在問題，例如沒有等待所有 gsan 磁碟 I/O 在進入冷狀態之前完成或暫停其操作的活動。

此外，研究表明，在 hfscheck 」indexsweep」階段 （當讀取索引等量中的所有雜湊，然後對許多資料參考記錄 （DRL） 檔案執行大量隨機寫入時） I/O 效能會在相當長的一段時間內下降。

在 Avamar Data Store Gen4、Gen4s 和 Gen4T 上，寫入作業的優先順序高於讀取作業，以及測試 I/O 子系統要低得多。此外，一些驅動器（如 Seagate Megalodon 磁碟機） 使用一些不同的技術，可能會混淆執行的測試和 perfbeat 線。

背景：

通常有三種不同的警告訊息可在 gsan 記錄：

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

警告 <0968> 表示存在個人 gsan I/O 測試速度很慢。

您可以放心忽略此訊息。

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

警告 <1051> 表示有足夠慢的讀取速度，導致 gsan 考慮將數據分區置於掛起狀態，但決定不這樣做。這就是MSG_ERR_UNNECESSARY所表明的。

您可以放心忽略此訊息。

WARN: <1084> changing disk 0 on node 0.3 to suspended state

警告 <1084> 表示 gsan 將資料分割區置於「掛起狀態」。

不得忽略此消息。

解決方案：

如果條帶進入掛起狀態，請使用以下準則調查並更正以下情況：

執行下列步驟以識別吊起的磁碟分割位置：

1.以系統管理員身分登入 Avamar Utility Node。

2.提升至 root 權限。

3.載入每個 Avamar 的根金鑰：如何登入 Avamar Server 並載入各種金鑰。

4.執行下列命令以識別吊起的磁碟分割位置：

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5.檢閱與上述結果相關的案例：

• • 無需採取任何動作。Stripe 會自動回到線上。很有可能 hfscheck 正在奔跑。 

• • 如果 stripe 自動回到線上，則很可能垃圾回收或 hfscheck 正在奔跑。
  • 重要：這可能表示磁碟問題或某些基本問題。
  • 雖然磁碟機尚未故障，但仍應使用以下步驟進行檢查：

1.判斷哪些實體磁碟與 Avamar 已暫停的磁碟相關聯。虛擬磁碟暫停內的實體磁碟發生問題，是暫停的根本原因：

avsysreport pdisk vdisk=x 

其中 x 是已掛起的虛擬磁碟 （資料分割區） 的編號。例如，如果第一個資料磁碟分割區顯示暫停的等量，則查詢 vdis=0。

2.確認實體磁碟層級沒有磁碟故障、預測性故障或其他錯誤。

3.確認代表相關節點上虛擬磁碟的實體磁碟上沒有 SCSI 錯誤 （在步驟 1 中判斷）。 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4.直寫模式下的虛擬磁碟可能會因為低 I/O。檢查控制器上的寫入原則：

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

如果在步驟 2-4 中偵測到任何問題，請向 Dell Technologies Avamar 支援開立 SR，以進行進一步調查。

案例 # 3：檢閱預設值 perftriallimit 設定：

1.請確認 perftriallimit 設定為 0：

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2.如果 perftriallimit 不是零：

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"