- 是不是開放式架構(gòu)呢?硬件是否有更廣泛的兼容性?用戶不愿被硬件鎖定;
- 是否能輕易的過度到雙活架構(gòu)?并具備成熟的備份、容災方案?
- 是不是能和軟件定義存儲的控制平面無縫集成,為私有云奠定存儲自動化的基礎(chǔ);
- 是不是真正做到了計算、存儲和網(wǎng)絡三個關(guān)鍵組件的融合?基于 vSAN 的 VMware Cloud Foundation(VCF) 就能做到三者融合,使得用戶購買的 vSAN 成為未來就緒的超融合架構(gòu);
- 是不是更長遠的延展性,形成私有云乃至混合云的基礎(chǔ)架構(gòu)?不久后 VMware 和 AWS 基于 VCF 的方案將推出,使有狀態(tài)的業(yè)務負載在私有云和公有云之間在線漂移成為可能;
- 廠商是不是業(yè)內(nèi)所認可的?技術(shù)是不是具有前瞻性?生態(tài)是不是成熟?這關(guān)系到數(shù)據(jù)能否長期、安全地存放;也關(guān)系到萬一出問題是否有足夠的專業(yè)人員來解決?
言歸正傳,下面介紹 vSAN 雙活(也即 Virtual SAN Stretched Cluster)。自從 vSAN 雙活推出了,國內(nèi)已經(jīng)陸陸續(xù)續(xù)不少用戶使用了,甚至有些用戶在上面運行 Oracle、ERP 等關(guān)鍵應用。
下面的介紹分成三個部分:
- 通過青島農(nóng)業(yè)大學案例客觀地介紹 vSAN 雙活,乃至整個 VMware SDDC(還包含了 NSX )的優(yōu)劣;
- vSAN 6.6 雙活新特性;
- vSAN 雙活的基本介紹,包含最小帶寬的計算公式;
青島農(nóng)業(yè)大學 vSAN 雙活案例視頻
這個存儲雙活的項目,其實 VMware 介入的比較晚,此前已經(jīng)有存儲硬件雙活的方案推薦給用戶了。得益于當?shù)氐?VMware 同事的推薦,用戶從成本、管理等方面進行綜合考慮,最終選擇了存儲軟件雙活也即 VMware vSAN 延伸集群。
青島農(nóng)業(yè)大學的老師在 vFORUM 2016 中國大會上親自演講:
vSAN 6.6 雙活新特性
vSAN 6.6 新增的 23 個特性中,最亮眼的幾個之一,一定包含雙活新特性。在此之前,大家知道,VMware 只支持 FTT=1,兩副本分別存放在數(shù)據(jù)中心的兩個不同站點。這樣確實有不方便的地方,舉個例子,A 站點的 H11 出了故障,虛機就必須利用 vSphere HA 在 B 站點的 H21 上啟動。如果在 A 站點本地還有冗余數(shù)據(jù),就不用那么費神了。vSAN 6.6 在雙活上新的增強就解決了這個問題,不僅如此,還有更出色的表現(xiàn)。
在 vSAN 6.6 支持 Failure Tolerance Method (縮寫為 FTM ) 配置:
- 混合陣列和全閃存陣列都支持的是:跨站點做 RAID 1 , 每個站點內(nèi)做 RAID 1;
- 僅全閃存支持:跨站點做 RAID 1 , 每個站點內(nèi)做 RAID 5 或 RAID 6。
跨站點的冗余特性,對應的存儲策略是 Primary Failures to Tolerate (縮寫為 PFTT) ,它的值可以設置為 1,或者為 0。設置為 1 時,表示跨站點做鏡像;設置為 0 時,表示只在一個站點上有副本,其使用場景后面會介紹。
站點內(nèi)的冗余特性,對應的存儲策略是 Secondary Failures to Tolerate (縮寫為 SFTT ),它的值可以設置為 0 到 3 。
vSAN 6.6 雙活 之 PFTT 和 SFTT
vSAN 6.6 雙活 雙重數(shù)據(jù)保護
這樣,即使發(fā)生站點級故障時,剩余站點仍具本地的數(shù)據(jù)冗余,提高了可用性。以跨站點的 RAID 1+本地的 RAID 1,也即 SFTT=1 且 PFTT=1 為例,雖然一份數(shù)據(jù)共有 4 份副本,存儲利用率只有 25%。但針對關(guān)鍵業(yè)務應用,犧牲一些存儲利用率,換取更高的可用性是非常值得的。而且,這個冗余特性是可以在 vmdk 這個級別來設置的,也就是說,一個虛機里,可以根據(jù)不同的業(yè)務特性,為不同的 vmdk 設置不同的冗余度。有不少其他 HCI 產(chǎn)品,副本個數(shù)必須在整個集群設置,就過于粗糙了,這樣它只適用于單一的業(yè)務場景。
前面提到,PFTT 還可以設置為 0 時,表示只在一個站點上有副本。它的使用場景包括,例如開發(fā)測試數(shù)據(jù)可能不需要在兩個站點上都有副本;或者,已經(jīng)使用應用冗余(Exchange DAG、SQL AlwaysOn 等)的解決方案。需要注意的是,Oracle RAC 不太一樣,RAC 使用的是共享存儲,如果要全部層級高可用則需要在存儲這一級做雙活,vSAN 做為分布式的共享存儲,其雙活技術(shù)是可以支持 Oracle RAC。白皮書《Oracle Real Application Clusters on VMware Virtual SAN - REFERENCE ARCHITECTURE》上有更多細節(jié)。
微軟 Exchange DAG 和 SQL AlwaysOn,更像是服務器 +JBOD 存儲,在虛擬化環(huán)境里也即虛機+vmdk 的方式,兩個 JBOD 存儲之間做鏡像。也就是說,在應用層,就實現(xiàn)了兩份副本,這樣就不需要存儲層來跨站點做兩份副本了。所以,針對這種場景,需將PFTT設置為 0。SFTT 設置為多少,看用戶希望在本地站點得到怎樣的冗余度。
在 vSAN 雙活上部署 DAG 或 AlwaysOn 的時候,還需要注意 Affinity 的設置。有兩個不同層次的 Affinity,計算資源池對應的是 vSphere DRS Affinity,而存儲資源池對應的是由 SPBM 設置的,決定存儲組件存放位置的,與 vSAN 雙活特性相關(guān)的 Affinity。
白皮書《Microsoft Exchange Server on VMware vSphere》,里面清楚地提到,為了防止兩個 DAG 的虛機運行在同一個 ESXi Host,也即防止單點故障,建議設置為 DRS anti-affinity 或者 guest-to-host affinity。原文如下:
Allowing two nodes from the same DAG to run on the same ESXi host for an extended period is not recommended when using symmetrical mailbox database distribution. This condition will create a single-point-of-failure scenario if the two nodes have the only copies of one or more mailbox data bases. DRS anti-affinity or guest-to-host affinity rules should be used to mitigate the risk of running active and passive mailbox databases on the same ESXi host.
在 vSAN 6.6 雙活的配置過程中,是在配置 SPBM,也即存儲策略時進行選擇的。Affinity 可選擇的值有三個:None,Preferred Fault Domain(首選故障域),Secondary Fault Domain ,如下圖。
vSAN site Affinity
其實,Preferred 和 Secondary Fault Domain 在 vSAN 6.1(也即首次推出雙活技術(shù)的 vSAN 版本)時出現(xiàn)過。
vSAN 雙活 首選故障域
設計的原則是,Exchange VM #1 的 DRS affinity 規(guī)則和 vSAN 雙活站點的 affinity 規(guī)則設置成,讓虛機和存儲(也即 vmdk 對象)都在同一站點,如站點 A 上;Exchange VM #2 的 DRS affinity 規(guī)則和 vSAN 雙活站點的 affinity 規(guī)則設置成,讓虛機和存儲(也即 vmdk 對象)都在另外的同一站點上,如站點 B。這兩個虛機屬于一個 DAG,兩個 vmdk 對象是同步的。
vSAN 延伸集群(Stretched Cluster)基礎(chǔ)知識
以下描述圍繞著 vSAN 6.1 版來展開。
在業(yè)界為數(shù)不多的存儲雙活方案中,VMware 在原有成本較高的存儲硬件廠商提供的雙活方案之外,提供了具有高可靠、低成本、更細顆粒度、操作更簡單的軟件雙活方案– vSAN 延伸集群。
vSAN 延伸集群相當于一個 vSAN 集群橫跨兩個不同的站點,每個站點是一個故障域。和其他存儲硬件的雙活方案類似,兩個數(shù)據(jù)站點之間的往返延時少于 5 毫秒(距離一般在 100 公里以內(nèi)),另外還需要一個充當仲裁的見證(Witness)存放在不同于兩個數(shù)據(jù)站點之外的第三個站點上。Witness 不一定是物理服務器的 ESXi 主機上,也可以運行在第三個站點的虛機上,或者可以運行在公有云上,如國內(nèi)的天翼混合云,或者 AWS、Azure、阿里云等。如下圖所示,Witness 所在站點與數(shù)據(jù)站點之間的網(wǎng)絡要求較為寬松,往返延時在 200 毫秒以內(nèi),帶寬超過 100Mb/s 即可。
vSAN 6.1 支持軟件雙活,也即延伸集群 (Stretched Cluster)
用 X+Y+Z 的形式表示延伸集群的主機情況,XYZ 分別代表 ABC 站點的主機數(shù),A 和 B 都是數(shù)據(jù)站點,C 站點放置見證主機。當前情況下,vSAN 延伸集群可支持最小 1+1+1 個主機,最大 15+15+1 個主機。
而兩個數(shù)據(jù)中心站點之間的帶寬,在 VMware 網(wǎng)站和博客里建議的是 10Gb/s,但實際上,只需要滿足業(yè)務需求即可,這個需求就是:
- Bandwidth(B) > Write bandwidth(Wb) * Data Multiplier(md)*Resynchronization Multiplier(mr)
其中,Data mutiplier 指數(shù)據(jù)倍數(shù),包含了 VSAN 傳輸及其他相關(guān)操作的元數(shù)據(jù)開銷。VMware 建議設為 1.4。Resynchronization 指重同步倍數(shù),將可能的重同步的事件考慮在內(nèi)。VMware 建議規(guī)劃帶寬的時候,在最大帶寬基礎(chǔ)之上,額外預留 25%,用于偶爾可能發(fā)生的重同步需求。也即,這個值建議為 1.25。舉例來說:
假設 VSAN 上工作負載為每秒 10000 個寫操作,寫 IO 大小為 4KB,這就意味著寫帶寬為 40MB/s,或者 320Mb/s。這樣網(wǎng)絡帶寬要求為:
- B = 40MB/s * 1.4 * 1.25 = 70MB/s 或者 560 Mb/s
VSAN 延伸集群結(jié)合 vSphereReplication(VR)、SRM 可以實現(xiàn)自動化更高、成本較低的兩地三中心的高級容災。同城之間,利用VSAN延伸集群提供數(shù)據(jù)的同步復制,異地之間,利用 VR 提供數(shù)據(jù)的異步復制。
vSAN 延伸集群結(jié)合 VR、SRM 實現(xiàn)兩地三中心高級容災
VMware 建議 vSAN 延伸集群在二層上部署組播,這樣比較簡單。如果部署在三層,有 NSX(VMware 的軟件定義網(wǎng)絡)的支持,會如虎添翼,通過 NSX 實現(xiàn)跨站點的網(wǎng)絡虛擬化,包括跨三層的二層網(wǎng)絡延伸,全分布式網(wǎng)關(guān),以及安全策略延伸,無需昂貴的私有的硬件交換機,即可實現(xiàn) L2 Extension,如 OTV,VPLS,EVI 等。
不過需要注意的是,vSAN 與 NSX 本身是相互獨立的,沒有相互依賴的關(guān)系。
vSAN 延伸集群結(jié)合 NSX