寫在前面:《vSAN 6.0設計與規模設定》系列文章是本人學習vSAN的一個學習記錄,該系列文章參照VMware白皮書《VSAN_Design_and_Sizing_Guide》,僅供你們學習交流,歡迎各位提出質疑互相討論!php
設計設計,說的就是可以對從一個總體的角度去思考,卻又能抓住其中的細節,作到粗中有細,細中現粗,所以我認爲在任何的設計面前,開始時的一個大方向不能有錯誤。同樣的,在進入vSAN的一些細節上的設計時,首先有幾個大方面須要先行考慮。
服務器
1、嚴格遵照VMware兼容性列表(VCG)架構
雖然VMware官方稱任何x86服務器都可以用於vSAN,但實際中並不是如此,只有保證你的硬件符合官方的兼容性要求,才能讓vSAN在實際業務中提供最高的穩定性和性能。VCG中包含了推薦的或者已通過測試的硬件、驅動版本、firmware。於是在實際項目中建議使用VCG列表中的硬件型號(服務器、存儲控制器、閃存設備、磁盤等等),固然若是條件容許,能夠直接使用Ready Node做爲vSAN節點。除了硬件型號意外,硬件環境對應的firmware和驅動版本也須要注意使用適合版本,保證最終的vSAN羣集可以提供最佳性能。
ide
(ps:VCG地址 http://www.vmware.com/resources/compatibility/search.php)性能
2、使用受支持的vSphere版本
學習
雖然vSAN支持vSphere 5.5(U1和U2)、vSphere 6.0多個版本,可是推薦使用vSphere最新版本以免出現一些已知問題(ps:畢竟vSAN是一個剛出不久的技術,VMware自己也在不斷改進修改,於是使用最新版本減小vSAN出現問題的可能性)。注意:VMware不支持將vSAN從Beta版本升級到GA版本,若是您當前使用Beta版本,故您只能採用全新部署的方法使用正式版本的vSAN。測試
3、平衡的主機配置
ui
做爲最佳的部署實踐,使用類似的甚至相同的ESXi主機配置(包括存儲設備)進行vSAN羣集的部署。這能夠進一步確保虛擬機組件在整個羣集和磁盤中能有一個平衡的分佈。當一臺沒有提供vSAN存儲容量的主機運行在vSAN羣集當中的時候,有可能會在出現羣集出現問題的時候發生其餘額外的錯誤。spa
4、vSAN羣集的生命週期設計
vSAN存儲的優點之一在於靈活的擴展性。它使得用戶可以經過簡單的增長vSAN節點的磁盤進行縱向擴展,也能夠經過增長羣集中的vSAN節點數量進行橫向擴展。這樣簡單的增長主機或者磁盤,便能使得用戶可以在不一樣的時間根據不一樣的業務需求組件更改vSAN羣集的規模。
在爲vSAN羣集進行硬件選型的時候,牢記一點:不管是在混合存儲架構仍是全閃存架構中,增長vSAN羣集的存儲容量要比在Cache層增長閃存設備容量來得容易。
當要爲vSAN羣集擴展容量的時候,只須要簡單的插入磁盤或者閃存盤便可。然而當你須要升級Cache層的閃存設備是,就得替換原有的閃存設備,操做更爲複雜。若是說容量和閃存設備同時增長,這卻是不難的。但若是隻是爲了增長Cache層的大小,那就不得不進行更多複雜的工做,遷移更多的數據。所以爲了不這種狀況出現,在設計之初就將將來所需的額外增長歸入考慮範圍。簡言之,Design for growth。
5、考慮容量、維護、可用性
vSAN羣集的最低要求是三臺ESXi主機,而後這個最低要求有很是大的限制。在vSAN羣集中,當出現設備或者節點故障時,vSAN會嘗試在羣集中重建故障設備或者幾點上的虛擬機組件。在一個3節點的vSAN羣集中,若是一個節點故障,羣集將沒法進行重建過程。一樣的,若是一臺主機須要進入維護模式,也沒法使用遷出全部該主機上全部數據的選項使主機進入維護模式。這些都只有當羣集中有4臺或以上的ESXi主機數量,而且有足夠的剩餘空間時纔可以實現。
另外一個須要考慮的問題就是vSAN羣集的Capacity層。在vSAN中虛機的存放是經過存儲策略驅動的,其中的一項策略參數就是FTT(NumberOfFailuresToTolerate),該參數定義了虛機存放的副本數量。所以進行vSAN羣集設計時須要考慮該值的設定對容量大小的影響。這個參數的具體將在後續文章中介紹。
至此,五個須要考慮的大方面已經說明完畢,接下來就是進入更爲詳細的考量階段了。