vSAN常見錯誤故障排錯

內容來源：2018 年 8 月 7 日，VMware大中華區原廠高級技術講師史峻在「VMware直播分享 第二期」進行《vSAN常見錯誤故障排錯》演講分享。IT 大咖說經主辦方和演講者審閱受權轉載發佈。

閱讀字數：5264 | 14分鐘閱讀

嘉賓演講視頻回放：suo.im/4ZGVwM

摘要

本次演講主要分享vSAN常見故障排除，其中包括：vSAN建立VM全過程介紹，vSAN排錯方法論和vSAN經常使用排錯工具。

vSAN Software Architecture

About vSAN

vSAN是軟件定義的對象存儲，VMware的對象存儲和虛擬化的產品是緊密的結合在一塊兒的，它其實是將本機磁盤組中的硬盤彙集起來打造的虛擬的軟件定義的共享存儲。這個環境中只有主機、服務器，沒有第三方的硬件存儲。

傳統存儲若是用的是共享存儲，服務器鏈接到LUN，而後在LUN中建立VMFS文件系統，文件系統中有虛擬機的文件夾，由vmkernel進行虛擬機文件I/O。

vSAN中再也不以文件的形式進行數據存取，vSAN建立以後有個vSAN Datastore，這個DataStore中存放着5類虛擬機的對象，分別是NameSpace、VMDK、快照、內存以及交換文件。

vSAN數據保護和性能提高主要經過軟件層面的策略來實現，由策略定義性能和可用性等。上圖是建立vSAN存儲策略的界面，能夠在此進行各類策略的配置。

Virtual Machine Storage Policy Capabilites for vSAN

可用性最基本的指標就是數據有多個副本，好比RAID 1能夠有兩個數據副本。在vSAN中經過PFTT策略來保證可用性，即容忍錯誤的數量是多少，若是爲0 就表示不能容錯，數據只有一份拷貝，1表示容忍出錯1次，數據有兩份拷貝。PFTT默認爲1，至關於實現了RAID 1的效果，最大能夠設置爲3。

在RAID中性能的提高須要依靠RAID 0，RAID 0是將數據切成多個條帶來進行保存。vSAN中也能將數據切分紅多個條帶，最多12份進行同時寫。

vSAN Architecture Components

vSAN中有這樣幾個軟件組件。CLOM（集羣級別的對象管理器），DOM（分佈式對象管理器），LSOM（本地日誌結構對象管理器），CMMDS（集羣成員監視和目錄服務）。

更形象一點的描述，CLOM能夠理解爲架構師，DOM是承包商，LSOM則是Worker，最後的CMMDS爲項目經理。

CLOM and Its Role: Architect

CLOM會根據建立的存儲策略決定對象是否能基於策略被建立出來，即策略會不會生效。好比副本數是3，要生成4分拷貝，可是集羣中只有3臺主機，很明顯此時的策略沒法生效，由於沒有充足的主機提供使用。CLOM還會檢測整個集羣範圍內主機的負載狀況，將對象及其組件分散到不一樣的主機上，而且當組件出現問題要進行修復的時候將決定該組件在哪些主機上重建。

CLOM組件在後臺有着一個進程，因此必定要保證主機上的這個進程沒有出現問題。因爲該進程是運行在每一個vSAN的節點之上，所以能夠經過/etc/init.d/clomd來查看它的當前狀態。

DOM and Its Role: Contractor

DOM也是運行在集羣中的每臺主機上。DOM會接收來自CLOM的指令，並着手實施，它會找LSOM來真正的幹活。前面提到的5類對象中都有一個DOM owner，用來審覈針對該對象的IO操做，決定是否可以執行，若是IO操做被容許就由DOM client來執行。

LSOM and Its Role: Worker

實際的I/O操做會被DOM分配到LSOM上，因爲LSOM會對設備直接進行I/O，因此它是運行在某個主機的內核空間中的，而沒有進程。

CMMDS and Its Role: Project Manager

CMMDS可以告訴咱們整個vSAN集羣拓撲的全貌和對象的狀態，包括集羣中的服務器、網絡、硬盤設備，對象元數據信息，新增或刪除主機等，它還會定義集羣中的三個角色master、backup、agent，master負責管理整個vSAN集羣的業務，backup是master的備份。

咱們簡單的梳理下這幾個組件之間的交互，首先由CLOM接到請求建立對象開始，若是根據策略能建立它就會將需求發給DOM，由DOM進行組件的建立，DOM決定好要建立哪一個組件以後將需求發送給LSOM，LSOM跟存儲層（SSD、硬盤）進行交互執行具體的I/O。另外的CMMDS會枚舉出整個集羣中的可用資源，以及這些資源的拓撲和可用狀況。

Virtual Machine Creation

虛擬機建立的時候，首先vCenter的vpxd進程會和主機進行通訊，選擇某個主機建立虛擬機存儲。主機上的vpxa進程接收到vpxd發出的請求後，CMMDS會建立策略，主機根據策略建立虛擬機及其關聯的vmdk。因爲vmdk是對象，所以要由CLOM根據策略來決定是否能建立該對象及其組件，當組件的建立的位置被決定好以後CMMDS會更新CLOM發出的組件拓撲信息。

另外主機上的DOM接收到CLOM發出的信息後，將建立對象組件的要求下發到本地LSOM上，最後LSOM經過本地存儲來建立虛擬機的存儲對象。

About Object

Home namesace對象實際上是一個小的虛擬機文件夾VMFS文件系統，VMDK、Swap、Snapshot deltas、VM memory這4個對象對應的是原來系統中的4個大文件。

這些對象不是直接放在硬盤上，而是分紅若干個組件的形式寫入存儲，這是爲了實現RAID、性能以及可用性。具體的切分方式和存儲策略相關，好比要實現RAID 1就將數據複製成兩個組件來寫（未計入Witness組件），既實現RAID 0又實現RAID 1則要4個組件。

上圖是RAID 1的組織結構，很明顯的看到有兩個Component組件，細心的朋友可能發現了這裏還多了個witness（仲裁組件）。RAID 1的兩個副本中若是其中之一損壞了，就沒法進行讀，由於此時不能肯定哪一個副本是無缺的。Witness的存在正是爲了解決這一問題，它的投票直接決定了哪一個組件可用。

Componet Count

下面咱們結合具體的例子來看下不一樣策略下對象和組件究竟是如何建立的。（如下組件的計算都不包含witness）

首先是PFTT等於0（容錯爲0），FTM爲RAID 1，條帶爲1的狀況，此時的硬盤會寫1個組件，由於只有1份拷貝。

PFTT等於1（容錯爲1），FTM爲RAID 1，條帶爲1的狀況下，硬盤會寫2個組件（拷貝爲2）。

PFTT等於2（容錯爲2），FTM爲RAID 1，條帶爲1的狀況下，硬盤會寫3個組件。須要注意的是這裏的witness會有兩個。

PFTT等於1（容錯爲1），FTM爲RAID 1，條帶爲2的狀況下。由於這裏的數據有2份拷貝，因此有2個Mirror，同時條帶又爲2，所以Mirror將會被拆成兩份。總結起來一共有4個組件。

PFTT等於2（容錯爲2），FTM爲RAID 1，條帶爲3的狀況下。根據上面的計算規律能夠很輕鬆的計算出，此時的組件數量應該爲9。

須要提到的是默認狀況下組件最大爲255G，若是某個VMDK對象大小超過255G，就會被平均拆成多份。

一樣是PFTT等於1（容錯爲1），FTM爲RAID 1，條帶爲1的狀況。此時因爲硬盤大小爲400G，超過了默認的255G，因此每一個盤會被拆分紅兩份，每份200G。一共是4個組件。

這裏是PFTT等於0（容錯爲0），FTM爲RAID 1，條帶爲1的狀況，由於是600G的硬盤，因此要被平均拆分紅3份（注：是每一個不超過255G）。

Object Inaccessibility

虛擬機沒法啓動有各類緣由，若是是vSAN存儲問題就多是因爲VMDK對象沒法訪問引發的。組件可否使用依賴於DOM，DOM會確認對象或組件是在線仍是離線，若是是離線就沒法訪問。離線緣由多是組件自身發生損壞，也可能與組件的健康狀態有關，好比LSOM組件或數據出現問題。數據的問題有兩方面的緣由，一方面是數據自己被破壞，另外一方面是數據同步有問題。全部必定要清楚組件和哪些對象關聯，當前狀態如何。

Torubleshooting Methodlogy

Defining the problem

定義問題不能僅限於表層的描述，要可以具體的找出引起問題的關鍵點。好比有關資源競爭的問題，在vSAN集羣中ESXi主機上不只會運行虛擬機還會進行硬盤的I/O，因爲主機是分佈式存儲集羣的一員，所以除了給虛擬機提供CPU和內存資源以外，還會額外的消耗資源在硬盤I/O上。若是I/O特別密集且虛擬機負載又高的話，二者之間就會產生競爭衝突。因此在出現資源競爭問題的時候，須要先看下CPU和內存的使用率是否太高。

要想解決問題，首先應儘量的收集額外的詳細信息。在遇到任何問題時候，第一舉措就是保護好現場，好比拍照或截屏，由於有些提示可能會一閃而過不會再重現。有了這些信息後，再根據自身掌握的知識體系結構列出可能緣由，而後依次排除。

這裏咱們對定義問題作更詳細的描述。首先是問題可否重現，若是能重現解決起來就相對容易。其次是逐漸縮小問題範圍，從集羣到主機再到組件依次排查。另外在問題出現以前是否對系統作過改動，經過日誌查看有哪些變更。因爲VMware的用戶基數很大，所以咱們能夠在相關論壇和官方網站中搜索是否有遇到一樣問題的線索。經過每次新版本發佈的Release Notes，也能判斷問題是否由BUG引發。

Identifying the Root Cause

問題定義完以後接下來就要找尋問題的緣由，根據現有產品中環境的狀態進行判斷，好比檢查當前集羣、對象和組件的健康狀態，硬盤以及虛擬機關聯對象是否存在問題等。上圖就是vSAN集羣的健康狀態監控，直觀的展現了當前集羣的各類狀況。

除了圖形界面外，還能夠經過一些vSAN的命令或腳本在控制檯中查看當前狀態。

Resolving the problem

最後要作的是構造解決方案，下面經過一些具體的例子來描述。好比主機進入維護模式形成虛擬機不可用，通常在有多份拷貝的狀況下進入維護模式並沒有太大影響，但只有兩份拷貝的時候，若是其中一個副本已損壞，另外一個正常的副本卻進入了維護模式，那麼在退出維護模式的時候這兩份數據副本就都不是最新狀態。因此在進維護模式以前必定要運行vsan.check_state腳本檢查對象的全部組件是否健康正常。

虛擬機I/O出錯頗有多是因爲其相關的組件有問題，能夠經過vsan.vm_object_info腳原本檢查對象信息，它會顯示出對象具體存在的問題並進行修復。也有多是主機進入維護模式引發的，這時能夠退出維護模式以進行修復。

性能問題一樣值得關注，好比磁盤組離線致使虛擬機出錯。通常性能出問題，有多是CPU和內存性能不夠也有可能與驅動器有關，硬盤是否兼容也要考慮到。

爲防止DataStore空間耗盡，在它達到70%臨界值的時候，就該計劃擴容分配加主機、磁盤組或硬盤。

Troubleshooting Tools

ESXICLI Commands

上圖列出是與esxcli相關的一些命令，能夠在主機本地shell或者經過ssh遠程鏈接到主機使用。這些命令並不須要強記，只要輸入esxcli就會列出後續的子命令列表，以下圖是使用esxcli storage後的幫助列表。

Useful Log Files

日誌文件是最經常使用的輔助手段之一，推薦你們關注vobd.log、vmkernerl.log、vmkwarning.log、clomd.log這個四個日誌文件。這些日誌文件能夠配合python腳原本使用。

上圖的vsanDiskFaultInjection.pyc腳本是用來模擬vSAN集羣出現問題後的狀況，經過 —help列出相關的幫助信息，好比 -u是模擬硬盤的熱拔出。

這是具體的執行命令，-d指明瞭要拔出的設備。

命令執行完以後在日誌中就展現出了錯誤信息。

設備從新上線後，日誌中的信息會進行更新，能夠看到下方已經顯示online了。

ESXCLI Namespaces in vSAN

最後咱們經過一個具體的例子來演示下如何使用esxcli相關的命令。假如集羣中的某臺服務器的系統損壞，可是硬盤沒有問題還保存着vSAN的數據，這時咱們要作的是對系統進行重裝，從新加入到vSAN集羣中。那麼如何加入呢，其實能夠經過esxcli vsan命令來完成。

在vSAN集羣的其餘正常主機上運行 esxcli vsan cluster get命令獲得當前集羣的信息，這裏有一個關鍵的條目——集羣的UUID（圖中紅色標識的）。

獲取到UUID以後，就能夠在新裝主機上執行esxcli vsan cluster join -u 「UUID」命令加入到集羣中，而後在當前主機上使用esxcli vsan cluster get就會看到它已經正常加入到集羣中了。