您好,登錄后才能下訂單哦!
小編給大家分享一下vmware中APD和PDL的示例分析,希望大家閱讀完這篇文章之后都有所收獲,下面讓我們一起去探討吧!
APD和PDL的情形在虛擬化運維中,是相對來說比較棘手的問題,需要謹慎處理。
全部路徑異常 (APD):
? 數據存儲在“存儲”視圖中顯示為不可用。
? 存儲適配器指示設備的“操作狀態”為“不活動或出錯”
永久設備丟失 (PDL)
? 數據存儲在“存儲”視圖中顯示為不可用
? 存儲適配器指示設備的“操作狀態”為“通信中斷”
APD解析:
在 vSphere 4.x 中,如果設備的所有路徑都出現故障,則將發生全部路徑異常 (APD) 狀況。 由于沒有跡象表明這是永久性還是暫時性設備丟失,ESXi 主機會保持重新嘗試建立連接。 當從 ESXi/ESX 主機錯誤取消提供 LUN 時,通常會發生 APD 狀況。 ESXi/ESX 主機仍然認為該設備可用,將無限期重新嘗試所有的 SCSI 命令。 這會對管理代理產生影響,因為在重新可訪問該設備之前不會對其命令作出響應。 這將導致 ESXi/ESX 主機在 vCenter Server 中變得不可訪問/無響應。
在 vSphere 5.x/6.x 中,已在永久丟失 (PDL) 的設備和由于未知原因而發生全部路徑異常 (APD) 這一暫時性問題的設備之間進行了明確的區分。
例如,在 VMkernel 日志中,如果存儲設備將 SCSI 感知代碼 H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0 或 Logical Unit Not Supported 記錄到 ESXi 5.x/6.x 主機中,則表明 ESXi 主機永久不可訪問該設備,或者該設備處于永久設備丟失 (PDL) 狀態。 ESXi 主機不再嘗試重新建立連接或向該設備發出命令。
遇到不可恢復的硬件錯誤的設備也會被識別為正處于永久設備丟失 (PDL) 狀態。
如果未從設備返回 PDL SCSI 感知代碼(當無法聯系存儲陣列,或者所具有的存儲陣列未返回受支持的 PDL SCSI 代碼時),則該設備處于全部路徑異常 (APD) 狀態,ESXi 主機將繼續發送 I/O 請求,直到主機收到響應。
由于 ESXi 主機無法確定設備丟失是永久性 (PDL) 還是暫時性 (APD) 的,因此它會無限期重試 SCSI I/O,包括:
? 用戶領域 I/O(hostd 管理代理)
? 虛擬機客戶機 I/O
注意: 如果從客戶機發出 I/O 請求,則操作系統將超時并中止 I/O。
由于 APD 狀況的性質,沒有簡便的方法進行恢復。
? 需要在存儲陣列/結構層來解決 APD 狀況,才能還原與主機的連接。
? 所有受影響的 ESXi 主機都可能需要重新引導,以移除到處于 APD 狀態的受影響設備的任何殘留引用。
注意:
? 無法對未受影響的虛擬機執行 vMotion 遷移,因為管理代理可能會受到 APD 狀況的影響,且 ESXi 主機可能變為非受管狀態。 因此,重新引導受影響的 ESXi 主機會強制中斷該主機上所有未受影響的虛擬機。
? vSphere 6.0 和更高版本隨 vSphere HA 一起引入了強大的新功能,稱為虛擬機組件保護 (VMCP)。VMCP 可防止虛擬機出現與存儲相關的事件,尤其是永久設備丟失 (PDL) 和全部路徑異常 (APD) 事件。
注意:發生 APD 事件時,連接到 ESXi 的 LUN 可能會在 LUN 路徑恢復后仍無法訪問。 即使存儲路徑恢復后,140 秒的 APD 超時時間可能仍會到期。 在 /var/log/vmkernel.log 文件中,您會依次遇到以下事件: 設備進入 APD 狀態。 設備退出 APD 狀態。 由于超時或未找到或忙碌,設備上的檢測信號恢復和文件系統操作失敗。 盡管設備之前已退出 APD 狀態,但是“APD 超時”仍會到期。 此狀況與以下一個或多個行為有關: 虛擬機無法訪問。 主機無響應。 即使路徑已恢復且可用,存儲仍處于脫機狀態。 即使虛擬機仍在數據存儲上,vSphere Client 也不顯示數據存儲。 以下一個或多個事件可能會觸發 APD 事件: 上游光纖通道或以太網交換鏈路失敗會影響存儲陣列的所有路徑 存儲陣列故障或重新引導 存儲陣列固件更新(某些供應商)
當然并非所有 APD 事件均會出現此行為。 大多數情況下,LUN 和數據存儲會按預期正常退出 APD 超時狀況。
原因:
出現此問題的原因是 APD 處理時發生故障。 出現此問題時,LUN 路徑在 APD 事件期間可用且處于聯機狀態,但 APD 定時器會繼續計數,直到 LUN 進入“APD 超時”狀態。 初始 APD 事件后,只要活動工作負載與數據存儲關聯,該數據存儲將無法訪問。
遇到此問題時,必須終止虛擬機才能恢復數據存儲。HA(如果已啟用)應在其他主機上恢復這些虛擬機。如果必須重新啟動管理代理,則暫時將無法通過 vCenter Server 管理主機。
計劃內 PDL 與計劃外 PDL 解析:
當試圖移除向 ESXi 主機提供的設備時,將發生計劃內 PDL。 必須首先卸載數據存儲,然后分離設備,這樣才能在存儲陣列上取消提供該存儲設備。 有關如何在 ESXi 5.x 中正確取消提供 LUN 的詳細信息,請參見 如何從ESXi 主機卸載 LUN 或分離數據存儲設備 (2072353) 。
如果意外從存儲陣列取消提供存儲設備,而未在 ESXi 主機上執行卸載和分離,則將發生計劃外 PDL。
在 ESXi 5.5 中,VMware 提供了一種名為“自動移除”的功能,以便在計劃外 PDL 期間自動移除設備。 有關詳細信息,請參見 PDL AutoRemove feature in vSphere 5.5 (2059622)。
要清除計劃外 PDL,請執行以下操作:
數據存儲中所有運行的虛擬機必須關閉電源并從 vCenter Server 中取消注冊。
從 vSphere Client 中,轉到 ESXi 主機的配置選項卡,然后單擊存儲。
右鍵單擊要移除的數據存儲,然后單擊卸載。
此時將顯示確認卸載數據存儲窗口。 如果符合必備條件,則會顯示確定按鈕。
如果您在卸載 LUN 時看到以下錯誤:
在 vCenter Server <name_of_vCenter> 上為對象 <name_of_LUN> 調用數據存儲刷新失敗
(Call datastore refresh for object <name_of_LUN> on vCenter server <name_of_vCenter> failed)
您可能提供了快照 LUN。 要解決此問題,請在陣列端移除該快照 LUN。
在該 LUN 對其可見的所有 ESXi 主機上執行重新掃描。
注意: 如果存在對該設備或掛起 I/O 的活動引用,ESXi 主機在重新掃描后仍會列出該設備。 檢查可能仍具有對該設備或數據存儲的活動引用的虛擬機、模板、ISO 映像、軟盤映像和裸設備映射。
如果該 LUN 仍在使用中且再次可用,請轉到每個主機,右鍵單擊該 LUN,然后單擊掛載。
注意: 計劃外 PDL 的一個可能原因是 LUN 的空間不足,從而導致其變得無法訪問。
Vc 6.0解決方案:
如果啟用虛擬機組件保護 (VMCP),vSphere HA 可以檢測到數據存儲可訪問性故障,并為受影響的虛擬機提供自動恢復。
VMCP 可防止發生數據存儲可訪問性故障,這些故障可能會影響 vSphere HA 群集中主機上正在運行的虛擬機。當發生數據存儲可訪問性故障時,受影響的主機無法再訪問特定數據存儲的存儲路徑。您可以確定 vSphere HA 將對此類故障作出的響應,從創建事件警報到虛擬機在其他主機上重新啟動。
注:
使用虛擬機組件保護功能時,ESXi 主機的版本必須為 6.0 或更高版本。
故障類型
存在兩種類型的數據存儲可訪問性故障:
PDL
PDL(永久設備丟失)是在存儲設備報告主機無法再訪問數據存儲時發生的不可恢復的可訪問性丟失。如果不關閉虛擬機的電源,此狀況將無法恢復。
APD
APD(全部路徑異常)表示暫時性或未知的可訪問性丟失,或 I/O 處理中的任何其他未識別的延遲。此類型的可訪問性問題是可恢復的。
配置 VMCP
在 vSphere Web Client 中配置虛擬機組件保護。轉到配置選項卡并單擊 vSphere 可用性和編輯。在故障和響應下,可以選擇處于 PDL 狀態的數據存儲或處于 APD 狀態的數據存儲。您可選擇的存儲保護級別以及可用的虛擬機修復操作根據數據庫可訪問性故障的類型而異。
PDL 故障
在處于 PDL 狀態的數據存儲下,可以選擇發布事件或關閉虛擬機電源再重新啟動虛擬機。
APD 故障
響應 APD 事件是更加復雜的,相應地配置是更加精細的。可以選擇發布事件、關閉虛擬機電源再重新啟動虛擬機 - 保守的重新啟動策略或關閉虛擬機電源再重新啟動虛擬機 - 激進的重新啟動策略
針對APD和PDL的時間調度有幾個周期,分別是:
APD說明:
0s - 此時APD會激活時間計數器;
140s APD - ESXi主機會生命APDTimeout然后會針對故障設備執行NON VM I/O激活Fast Fail動作。這個Timeout的周期可以被修改;
140-320s APD - APD Timeout的時間到達之后,這之前VMCP的Timeout已經到達。如果故障存儲設備在這之前恢復正常,則可以通過對Response for APD recovery after APD timeout配置選項的配置來確保VM不會被強行重置;
320s APD - VMCP Timeout,同時激活Response for Datastore with All Paths Down(APD);
PDL說明:
0s PDL - VMs會立刻在正常ESXi主機上重新啟動;
VMCP的Timeout時間會是320秒,里面包含了APD的默認140秒。VMCP組件的配置可以通過勾選vSphereHA設定選項中Protect against Storage Connectivity Loss選項來激活;
針對VMCP的配置選項如下:
VM restartpriority - VM重啟優先級設定;
Response for Host Isolation - 主機被隔離時的響應方式;
Response for Datastore with Permanent Device Losss(PDL) - 三個配置選項,分別是Disabled、Issue events(不激活處理動作,只發通知訊息)、Power off and restart VMs(針對故障Vms嘗試做重啟動作);
Response for Datastore with All Path Down(APD) - 四個配置選項,分別是Disabled、Issue events(不激活處理動作,只發通知訊息)、Power off and restart(conservative)(受影響的Vms會被Kill掉,然后在連接正常的ESXi主機上重啟。如果故障主機無法與Master主機通訊則將無法激活)、Power off and restart VMs(aggressive)(受影響的Vms會被Kill掉,無論是否有主機可以通過重啟承載這些Vms。不論Master主機是否存在,是否能和其它主機通訊以及是否有足夠的資源);
Response for APD recovery after APD timeout - 這個選項表示在APDTimeout(140s)之后VMCP Timeout之前(320s)存儲設備恢復正常時的處理方式。它有2個可用配置選項,分別是:Disabled、Reset VMs(Vms會被強行于APD發生前所在主機重置);
注:
如果禁用“主機監控”或“虛擬機重新啟動優先級”設置,VMCP 將無法執行虛擬機重新啟動。但是,仍可監控存儲運行狀況,且可發布事件。
APD的解決方案補充:
此問題已在 ESXi 6.0 Update 1(可從 VMware Downloads 獲得)中得到解決。 有關詳細信息,請參見 VMware ESXi 6.0 Update 1 Release Notes。
如果無法升級,沒有其他措施可以保證在 APD 事件期間不會遇到此問題。 但是,出現此問題時有兩種權宜措施可以恢復生產。
要臨時解決此問題,請使用以下選項之一:
1、執行終止 LUN 的所有未完成 I/O 的過程。 有關非計劃 PDL 的信息,請參見 Cannot remount a datastore after an unplanned permanent device loss (PDL) (2014155)。 2、 注意: 可能還需要重新啟動 ESXi 管理代理。 有關詳細信息,請參見 Restarting the Management agents on an ESXi or ESX host (1003490)。 3、重新引導卷處于“APD 超時”狀態的所有主機。
其他補充:
腦裂
當群集發生裂腦的狀況時候,因為無法進行任何溝通而誤會對方無法運作,所以主與備份服務器都會啟動浮動IP和相關服務,此時若兩部服務器對外連線亦未短線,那么勢必導致有些使用者存取的是主要服務器,另外一些則存取備份服務器的情形。此外,如果兩部服務器共享一個存儲裝置,發生裂腦時兩部服務器會同時掛載該存儲裝置,亦同時存取相同的檔案,因此若共享存儲裝備缺乏良好的鎖定機制,更可能使得存儲裝置上的檔案因同時讀寫而損壞。更有可能導致硬盤中寫入不一致的信息,導致后期數據錯誤,甚至整個數據庫損壞,后果不堪設想。
對付HA系統“裂腦”的對策,目前我所了解的大概有以下幾條:
1)添加冗余的心跳線,例如雙線條線。盡量減少“裂腦”發生機會。
2)啟用磁盤鎖。正在服務一方鎖住共享磁盤,“裂腦”發生時,讓對方完全“搶不走”共享磁盤資源。但使用鎖磁盤也會有一個不小的問題,如果占用共享盤的一方不主動“解鎖”,另一方就永遠得不到共享磁盤。現實中假如服務節點突然死機或崩潰,就不可能執行解鎖命令。后備節點也就接管不了共享資源和應用服務。于是有人在HA中設計了“智能”鎖。即,正在服務的一方只在發現心跳線全部斷開(察覺不到對端)時才啟用磁盤鎖。平時就不上鎖了。
3)設置仲裁機制。例如設置參考IP(如網關IP),當心跳線完全斷開時,2個節點都各自ping一下參考IP,不通則表明斷點就出在本端,不僅“心跳”、還兼對外“服務”的本端網絡鏈路斷了,即使啟動(或繼續)應用服務也沒有用了,那就主動放棄競爭,讓能夠ping通參考IP的一端去起服務。更保險一些,ping不通參考IP的一方干脆就自我重啟,以徹底釋放有可能還占用著的那些共享資源。
看完了這篇文章,相信你對“vmware中APD和PDL的示例分析”有了一定的了解,如果想了解更多相關知識,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。