摘要

本次主要分享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就會看到它已經正常加入到集群中了。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!