升級 vSan 6.5 計畫與實行步驟

緣起

近兩年來 VMware 軟體也不斷升級進化,更提出 vSAN 功能可以提升可用度及簡化備份程序,在這幾年持續觀察其演進,並仔細測試每一代的功能與容錯能力,經過上次外出上課,開始考量利用此最新的功能來改善公司的環境。

vSAN 機制藉由串連不同的主機(Host)內部的硬碟空間,作成一個容錯的機制分享空間機制,透過資源的自動分配使其任一虛擬機(VM)在此機制都能保留多份(看設定)資料,並於運行時自動更新所有分身的資料使其維持同步,這樣可以保證任一台主機(Host)故障、或是硬碟故障都可以在極短的時間啟動分身,大幅度減少停機時間,目前公司採用定期整機備份,除了復原有時間差外,每次備份都需要花上大量的時間以及空間,間接影響機器壽命。

計畫

本次升級將分成主機軟體升級、盤點採購所缺的 SSD 硬碟、更新DMZ區Switch、資料搬移及上線等步驟.

主機軟體升級

如同前述,公司使用該軟體已經多年的歷史,部分主機因為該機制穩定,極少主動更新系統,僅有於例行性系統更新時會安裝最新版的上一個版本,幾乎所有的主機都需要升級,但為保持公司運作正常服務不中斷,以及保險安全起見,我們升級時都須要把主機上的虛擬機搬移到其他主機上執行,再進行空機的升級,以免升級失敗導致服務中斷,但此作法會花掉較多的時間,並遇到較新的主機CPU功能較多,無法搬移到較舊的主機上運行等問題,都需要花時間一一規劃停機時間來排除問題。
我們的作法是先檢查同一群組內的主機(Host)最舊CPU規格,然後建立一個 Cluster 開啟 EVC 功能,來確保虛擬機能再主機間自由移轉不會有 CPU 干擾的因素,但主機搬移Cluster需要進入維護模式,我們則利用偷雞的方式在晚上把主機上面所有的虛擬機關機,進入維護模式,搬移到新的Cluster在重新啟動虛擬機,這樣可以同時處理所有的虛擬機也不會造成服務中斷。
接下來鎖定要升級的主機後,把他身上的虛擬機利用移轉(Migrate)的方式,一台台搬到其他主機身上,再透過 Update Manager 功能來作升級,但是偶而發生 v5.5 直接升級到 v6.5 會失敗或卡住,此時就只能手動升級來達成目的,另外也發現我們先前拿一般 PC 來安裝系統,也會因為硬體架構不相容而無法升級,造成時間上的消耗。

實際安裝

原本想要用原先主機上的 RAID 直接來做,所以先把所有的虛擬機先全部移動到其他主機上,只留下其中三台(有一台還是由 DMZ 區先借),把這三台主機分別都升級到最新版 (請留意這個步驟, 導致後面很多奇怪的現象),在不打掉原先主機設定,讓一顆 SSD 對應一個整個 RAID,違反VMWare 的建議。

在設定額外的 vKernel 來應付 vSAN 同步的流量,調整一下網卡的設定,這些安裝方法在網路上有許多非常詳細的說明,我這邊就不再重複,但因為我們的環境還是算非常小型的環境,所以我沒有設定VDS (virtual distribution switch),在 v6.5 的環境價,vSAN 是不需要額外安裝任何軟體。

啟動後利用自動的方式把可用硬碟加入到 vSan 裡面,但是在做系統檢查時卻一直出現 vSAN 硬碟內有包含舊有 vSAN 的物件,需要把把硬碟格是升級到 3.0,本來以為是系統誤判,所以就點擊了升級,但是每次都以失敗收場,最後甚至於想到那就每台 Host 上面的硬碟一個個加入,雖然這個笨方法剛開始是可行的,但是幾十分鐘後又跑回黃色的警告狀態.

後來思考是不是沒有依照 VMWare 的建議,vSan 最好是建置在主機沒有raid 的情況下,讓他自己去管理每顆硬碟的使用,所以每台主機去把原來的 raid 打掉,如果能改成 non-raid mode 就改(或是 Pass-through),不能的話需要每顆硬碟做成 raid 0,這些動作真的很花時間,接下來又是重新啟動 vSAN之後又失敗,這次失敗可能的原因是其他有台主機的 ssd, 先前是作 raid 1,兩個SSD內容都是相同的,打掉後 vSan 發現硬碟代號相同的有兩個,所以在重新安裝時發現硬碟代號相同不給裝,最後能想到的方式就是把硬碟分割區清空,但裝在 raid 卡上的硬碟用一般的開機還不見得能抓到,最笨的方法就是把所有的硬碟都建立一個 raid,然後用快速 初始化 (Fast Init.) 把分割區清掉。

經過以上走了很多彎路的錯誤,最後終於把整個 vSAN 弄到可以運作的狀況,雖然有部分出現黃色警告,但最少機器放入的裡面是可以執行的,執行了 監控(monitor) -> vSan -> 主動測試這個項目,裡面有三個測試項目(虛擬機器建立測試、多點傳送效能測試、儲存區效能測試)都顯示通過,在健全狀況下的檢查,所有的紅字都已經不見了,接下來挑戰就是一個個來解決問題。

測試運作過程中,vSAN的格式警告又跳回黃燈,但這次vSAN裡面已經存有資料,就不可以隨便打掉重來,過程中也利用 vCenter 自帶的 Update Manager 把所有的 ESXi 升級到最新版本,希望這些是因為版本的問題所造成,最後在 vmware 網站上看到連 vCenter 6.5 都有多個版本,但 Update Manager 並不會針對 vCenter 作升級 (或者是我不知道如何作),把更新檔案抓下來後,連接到 vCenter 的光碟機上,進入到畫面用 root 登入,密碼就是安裝vCenter 時所設定的 administrator@vmare.local 的密碼,依照步驟更新 vCenter,參考 VWmare 文件

更新完成重新開機後,vCenter 上就可以看到更多的 vSAN 選項,此時恍然大悟自己的 ESXi 已經升級上去,但是控制台反而是舊的,首先當然是來測試檔案格式的錯誤,再次檢查後升級就很順利的升級上去,在檢查其他檢測項目,發現有大量的元件需要同步,但是重新同步節流被打開需要花上一整天來同步40G左右的資料,把節流調整到最大時就把時間縮短到30分鐘,等待一下這個也就恢復正常。

期間內還有調整其他細節的項目到最終只剩下硬體相容性有出現警告,都是出在 Dell Raid 卡的錯誤,例如 PERC H710 Mini 這一片先前在 6.0還有支援,但是升級到 6.5 後就不再支援清單,雖然 esxi 是可以正常的驅動使用,但是還是有相容性不足的警告,除非透過機器不斷的更新,否則這個警告可能還需要忍受一陣子才會消失。

vSan 硬體相容性錯誤
vSan 硬體相容性錯誤

 

目前利用其中 3 台 Host 所創造出來的空間

vSan Size after setup
vSan Size after setup

可以看到一台虛擬機放置在 vSAN 上, 實際存放位置是在兩台主機上,另存一份在第三台主機的是見證資料,利用這個方法來達到容錯的目的。

vSan save VM guest in different esxi
vSan save VM guest in different esxi

 

Lesson Learned

 建立 vSAN 前確認所有的軟體版本應該是要統一版本,雖然 vCenter 先前跟 ESXi 的版本版次相差幾個 Update 是不會有問題的,但是未來可能vCenter 會跟 ESXi 的版本綁在一起。

 加入到 vSAN 的硬碟會被切割成一個2MB 及剩餘空間的分割區,VMWare 讀取到這些資訊是不允許在 VMWare 內刪掉,最好的做法是利用 vSAN 內的刪除磁碟群組功能刪掉,否則就要利用其他OS把資料刪除,好處是這些硬碟其實是可以被 vSAN識別

 未來要採購機器,如果要作 vSAN,在規格可以適量的減少硬碟的容量,因為不太需要買備份的容量, vSAN 會隨時幫忙做備份

 全部採用 flash 的配置可以在作 cache 的使用較好的 SLC 規格,作為儲存的使用 MLC 較便宜的規格即可

漸漸的把虛擬主機移動到這個機制上,也想要了解開始有少量的資料之後,系統是否能夠維持正常運作,以及遇到檢查錯誤時要如何地去故障排除,以及學習排除的方式及所需要的時間。

發表迴響

%d 位部落客按了讚: