WSFC 來賓群集架構

來賓群集是老王WSFC系列前面遺漏的一個章節，本篇老王將探討來賓群集的架構，并對其中一些概念進行演示，之前老王和一些朋友探討來賓群集，發現有一些朋友對于來賓群集概念的理解，存在著一些誤區，因此希望通過這篇文章幫助大家正確理解來賓群集架構

首先老王先來個來賓群集下一個定義：基于虛擬化主機或虛擬化群集中虛擬機里面的應用群集

當我們說虛擬化群集，其實我們說的不是來賓群集，我們目前在現實生活中探討的虛擬化群集通常指的是主機級別的群集，我們可能把幾臺物理機做成虛擬主機群集，在上面跑了很多虛擬機，但是虛擬化群集實質上是物理主機級別的容錯，當一臺物理機宕機，上面所承載的虛擬機會全部轉移到其它活著的節點上

而來賓群集，則說的是我們在兩臺虛擬機之間，做成了群集，有人會問，做虛擬化群集不就好了嗎，為什么還要做來賓群集呢，實質上是虛擬化之后帶來的正常需求，舉個例子，我們當前完成了公司虛擬化的遷移，將原來大部分物理機都已經轉換成了虛擬化群集資源池，上面的所有業務都已經遷移到虛擬化環境，那么好了，我原有業務是群集架構，保證了高可用，遷移到虛擬化群集之后你怎么幫我解決我的應用高可用問題，這是應用管理員應該對群集管理員提出的問題

傳統情況下 群集管理員可能會想到 備份虛擬機 ，或者在虛擬化群集級別對用戶多臺虛擬機進行控制，例如使用反相關性，保證用戶的應用虛擬機始終被分布到不同主機上，從這一級別保證用戶虛擬機的高可用，但這這種配置僅適用于前端虛擬機，如果是有狀態的應用虛擬機，數據庫虛擬機，則需要配置成復制架構，這樣當一臺宕機后，另外一臺才可以正常使用，但如果應用管理員處于一些原因并不愿意將虛擬機設計成復制架構以配合主機群集層面的反相關性，則就需要另想辦法，答案就是部署來賓群集

允許應用管理員在兩臺虛擬機之間部署群集，以解決應用高度可用問題，通過部署來賓群集，在這個場景中，用戶將獲得和以前物理機管理群集一樣的體驗，虛擬機里面的應用將獲得高可用，當一臺虛擬機宕機，虛擬機里面的應用會故障轉移至另外一臺虛擬機提供服務

來賓群集的使用場景如下

1. 單機物理機，公司可能資源有限，只能提供一臺性能充足的物理機，管理員就在這上面部署虛擬機給業務使用，業務需要保證虛擬機高可用，最小RTO，于是采用來賓群集方案，為虛擬機部署群集，同時結合安全手段控制用戶訪問虛擬機

2. 虛擬化群集+來賓群集，應用管理員希望擁有自己對于自身應用系統群集的完全管理權限，希望應用維持和以前一樣的高可用架構方案，確保從主機到虛擬機應用的端到端高可用

對于應用管理員來說，部署來賓群集是對自己應用可用性的又一道保障，舉個例子，如果不部署來賓群集，可能用戶是兩臺虛擬機，部署在Hyper-V群集上面，假設Hyper-V主機檢測到一臺虛擬機藍屏，會把虛擬機重啟，或者執行遷移到其它主機操作，但其實從應用角度我們需要的不是這個，需要的是被藍屏這臺虛擬機上面的應用快速轉移到其它虛擬機上，主機級別的群集是看不懂你應用的，它最多只能知道你這臺虛擬機藍屏了，或者那個服務停了，我應該把你這臺虛擬機遷移到其它主機上面試試看能不能啟動起來，而不會去操控虛擬機里面應用的故障轉移，如果我們沒有為虛擬機設計自動故障轉移的復制架構，這時候虛擬機里面的應用就面臨著宕機

如果是部署了來賓群集架構，會發生的就是 一臺虛擬機藍屏了，上面應用肯定掛了，來賓群集其它虛擬機通過運行狀況檢測，檢測到有虛擬機宕機，自動會將它上面的應用轉移過來，提供服務，這就是有沒有來賓群集的區別

對于來賓群集而言，從應用的角度，應用是不知道我這是來賓群集，還是物理機群集，應用只知道我底層是一個操作系統，這個操作系統有沒有部署群集，如果有部署群集，那么我就可以完成在來賓節點之間完成故障轉移。

部署來賓群集是對虛擬機內部應用的保護，它防止的是這臺虛擬機操作系統的崩潰，一旦這臺虛擬機的操作系統崩潰，我的應用可以快速轉移到其它虛擬機節點工作

部署虛擬化群集是對虛擬機對象和主機的保護，它防止的是某一臺物理機的崩潰，一旦一臺物理機崩潰，或發生硬件故障，則上面所有虛擬機可以轉移到其它節點工作

雖然我們上面說部署了來賓群集之后，可以保障應用的可用性，除了防止主機故障，也可以防止操作系統故障，但是如果我們是虛擬化群集+來賓群集的架構，仍然需要應用管理員與群集管理員的配合，以完善端到端的高可用性，舉例來說，如果不經過配合，虛擬化群集通常會由專門的資源管理系統負責調度，很有可能會把用戶的來賓群集所有節點都放在一個宿主機節點上，那么一旦這臺宿主機宕機，則來賓群集所有節點也就宕機，部署來賓群集也就失去了意義，因此，為了確保來賓群集應用的高可用，必須要求群集管理員為來賓群集配置維護策略，最好的解決辦法是配置反相關性，讓兩臺來賓群集虛擬機不在相同物理機上運行，除非只剩下最后一臺物理機。這樣配置之后不論是WSFC還是SCVMM都會遵循反相關性策略，這樣就真正達到了主機高可用，虛擬機操作系統高可用，即便是一臺物理機壞了，也絕不會影響虛擬機里面的應用

如果是四個節點的來賓群集，則可以參考這樣的策略，宿主機群集配置兩臺虛擬機的首選節點為第一臺物理機，兩臺虛擬機的首選者節點為第二臺物理機，這樣在群集評估放置策略的時候也會遵循首選所有者策略，確保兩兩虛擬機分別在兩臺物理機上，如果一臺物理機宕機，來賓群集仍在另外物理機上面可用

雖然部署來賓群集的方案看起來很好，能夠為虛擬機里面的應用帶來更多保障，但也有它隨之帶來的問題

對于群集來說，群集是不管你是虛擬機或是物理機的，WSFC支持全虛擬化群集，全物理機群集，虛擬機物理機混合的群集，只要群集各節點滿足群集部署的先決條件即可，那么最重要的一點來了，共享存儲，我們說部署群集就需要共享存儲，應用需要把數據存放在共享存儲里面，才可以把應用無縫的進行故障轉移

如果我們部署來賓群集，存儲怎么辦呢，就需要管理員想辦法，把物理環境中的磁盤公開給來賓群集，讓來賓群集完成群集的建立

通常情況下來賓群集的存儲分配大體有以下幾種方案

1. ISCSI，這個最常見了，隨著網絡速率的提高，ISCSI已經被用于很多現實企業環境，如果要提供給來賓群集，如果設備或超融合產品支持，可以直接在物理環境上面分配一個target給虛擬機，或者部署iscsi server ，可以是微軟的或者starwind，最好是高度可用的ISCSI 提供呈現，如果沒有環境，那么部署一臺單獨的虛擬機，或者直接在物理機上面安裝ISCSI提供給虛擬機使用也是可以的

   
   

2. 直通磁盤，也是一種可行的方案，簡單來說，直通磁盤就是我們將物理磁盤不通過創建虛擬磁盤的方式，直接在虛擬化主機磁盤管理脫機，傳遞給虛擬機中使用，由虛擬機直接使用磁盤，在WSFC中直通磁盤僅限于來賓虛擬機群集使用，且存在一定的限制，從WSFC 2008開始，微軟支持為群集添加直通磁盤，理論上我們可以部署一個虛擬化群集，但是不給群集分配共享存儲，而讓虛擬機使用直通磁盤

WSFC 2008時代為群集添加直通磁盤步驟如下

1. 脫機物理機磁盤 

2. 脫機來賓群集虛擬機

3. 新增SCSI控制器，選擇被脫機的物理機磁盤

4. 虛擬機開機，內部看見物理機分配的直通磁盤

5. 在主機群集管理器刷新虛擬機配置，看見直通磁盤成為虛擬機依賴磁盤

   
   

WSFC 2012時代為群集添加直通磁盤步驟如下

1. 脫機物理機磁盤

2. 將直通磁盤添加至群集磁盤

3. 關閉來賓虛擬機，新增SCSI控制器，選擇直通磁盤

4. 虛擬機開機，內部看見物理機分配的直通磁盤

5. 在主機群集管理器看見直通磁盤成為虛擬機依賴磁盤
   

可以看到，雖然我們說直通磁盤可以被添加到虛擬化群集，但實質上，并不是說使用直通磁盤來作為群集共享磁盤，而是在虛擬機配置中，把直通磁盤作為一個依賴項目，添加進來，達到的是一個什么效果，當發生計劃外故障轉移的時候，虛擬機會被轉移至其它節點，依賴的直通磁盤，也將轉移過去，因為Hyper-V主機實際上并未安裝存儲。是guest虛擬機直接執行直通磁盤IO，這意味著所有節點無法同時訪問存儲，因此當發生故障轉移時，直通磁盤將在當前物理節點脫機，再到其它節點掛載聯機，之后才能完成虛擬機的遷移，這將大大增加故障轉移時間，實時遷移時直通磁盤將必須從當前的Hyper-V主機卸載然后安裝在新的Hyper-V主機上，此過程將減慢VM的遷移速度，并可能導致客戶端明顯暫停，甚至斷開連接。

除此之外，直通磁盤會與單臺虛擬機綁定，例如我們如果將一塊磁盤分配給虛擬機，那么這塊直通磁盤將不能再用作其它用途

因此實際環境中使用直通磁盤做來賓群集幾率并不大，曾經在2008時代，直通磁盤效率與VHD有明顯差距，而且那時候單個VHD有2TB的限制，通過部署直通磁盤，在那時可以幫助我們解決性能問題，虛擬機磁盤大小問題，同時將底層的FC或其它架構存儲直接交付給虛擬機。

即便是使用直通磁盤，通常情況下企業也不會單獨使用，一個宿主機群集里面會有多臺來賓群集，這些來賓虛擬機的操作系統，還是會被存放在共享存儲里面，而直通磁盤更多的是一種專用存儲的概念，我們可以把一些類似于數據庫文件等數據存放在直通磁盤，這樣混合使用

直通磁盤群集架構的利弊

1. 支持映射Hyper-V物理環境連接的SAN，ISCSI，NAS，本地硬盤至虛擬機

2. 在沒有Hyper-V增強會話模式之前支持映射USB存儲

3. 不支持快照，差異磁盤，動態磁盤，Hyper-V副本
   

4. 主機備份無法備份傳遞磁盤，需要在來賓虛擬機里面安裝代理進行備份

5. 計劃內維護遷移會有宕機時間

6. 管理不夠靈活，不如管理VHD方便，提供的直通磁盤管理接口很少
   

到了2012開始，虛擬機磁盤文件進行了優化，VHDX格式的磁盤，已經和直通磁盤的性能差距接近，同時達到了單個磁盤64TB的大小限制，來賓群集架構也更加靈活，提供了虛擬光纖通道，ShareVHDX等交付存儲的架構，因此在群集中使用直通磁盤的案例已經越來越少，少數場景下用戶仍然會延續習慣，在單機上面為虛擬機增加直通磁盤。

3.虛擬光纖通道

在2012之前，如果想要將SAN提供給虛擬機，我們只有通過在FC中實施ISCSI網關，或者采用直通磁盤，2012開始微軟推出虛擬光纖通道功能，讓虛擬機也能像物理機一樣使用虛擬HBA擁有虛擬光纖通道，擁有自己的WWN，VM直接連接到FC SAN中的LUN

這項技術能夠得以實現主要依賴于三項技術

NPIV - Hyper-V guest虛擬機的虛擬光纖通道使用現有的N_Port ID虛擬化（NPIV）T11標準將多個虛擬N_Port ID映射到單個物理光纖通道N_port。每次啟動配置了虛擬HBA的虛擬機時，都會在主機上創建新的NPIV端口。當虛擬機在主機上停止運行時，將刪除NPIV端口。

虛擬SAN - 定義了一組連接到同一物理SAN的命名物理光纖通道端口。

虛擬HBA - 分配給虛擬機來賓的硬件組件，并分配給特定的虛擬SAN

實現虛擬光纖通道的條件與限制：

支持NPIV的FC SAN

主機必須運行Windows Server 2012/2012R2

主機必須具有帶有支持Hyper-V和NPIV驅動程序的FC HBA

無法使用虛擬光纖通道適配器從SAN引導VM; 虛擬光纖通道僅用于數據LUN

唯一支持虛擬光纖通道的客戶機操作系統是Windows Server 2008，Windows Server 2008 R2和Windows Server 2102。

WWPN:提供給類似于MAC地址的光纖通道HBA的唯一號碼，用于允許存儲結構識別特定的HBA

WWNN(即全球節點名稱)：每臺虛擬機都能夠分配到自己的專有WWNN，并以此為基礎直接與SAN相連接

為了虛擬機如何從一個主機移動到另一個主機而不破壞從VM到存儲的IO流，Hyper-V設計了每個虛擬HBA兩個WWN的架構，虛擬機使用WWN A連接到存儲。在實時遷移期間，目標主機上的虛擬機的新實例是用WWN B設置的。當實時遷移在目標主機上時VM可以立即連接到LUN，并且不間斷地繼續IO，對于原始主機或任何其他主機，每個后續的實時遷移都將導致虛擬機在WWN A和WN B之間交替。虛擬機中的每個虛擬HBA都是如此。在Hyper-V集群中可以有多達64個主機，但是每個虛擬光纖通道適配器將在兩個WWN之間交替。

配置步驟如下

1. 為Hyper-V創建虛擬SAN

2.關閉虛擬機，為虛擬機添加光纖通道適配器，接入虛擬SAN

3.為虛擬機WWNN分配存儲，虛擬機開機使用，創建來賓群集

虛擬光纖通道是hyper-v 2012的技術，利用虛擬HBA NPIV等技術將虛擬機直接接入物理SAN，解決了以往的局限性，但這項技術仍然不少限制，例如只能用于Windows操作系統虛擬機，如果是linux虛擬機則不能使用，后面2012R2的sharevhdx相對來說支持的操作系統更多一些，技術配置也沒有虛擬SAN這么繁瑣

4.ShareVHDX

ShareVHDX是2012R2推出的一項技術，看著像是虛擬化里的技術，但主要還是依賴WSFC，主要用于提供給來賓群集共享存儲使用，通過這項技術實現了對于對于來賓群集屏蔽底層物理存儲結構，虛擬機將不會直接和物理存儲相聯系，而是通過虛擬主機提供的ShareVHDX來實現來賓群集

2012R2時代，這項技術實際呈現效果，我們為來賓群集虛擬機依次添加同樣SCSI虛擬磁盤，在磁盤高級選項中選擇啟用虛擬磁盤共享即可，這樣選擇之后，我們就可以把一個虛擬磁盤，同時給兩臺虛擬機使用，對于來賓群集來說，這就是一個共享磁盤，可以被群集使用，但前提條件是這個虛擬磁盤必須存放在群集CSV卷或SOFS路徑下

這項技術非常好用，老王曾經在山東做過一個項目，該項目通過2臺linux虛擬機做oracle rac群集，但是需要共享磁盤，又不便將底層存儲公開給虛擬機，于是采用ShareVHDX技術，將磁盤同時掛接給兩臺虛擬機，虛擬機內部就可以正常創建rac使用，效果很好

對于來賓群集來說，無疑這是最佳最方便的方案，但一個很重要的前提就是底層必須要有虛擬化群集的支持，ShareVHDX的磁盤文件必須存在虛擬化群集的CSV或SOFS路徑下，或者說有專門的一個存儲群集提供給虛擬化群集使用，所有的ShareVHDX都存放在存儲群集，前端的虛擬化群集不配置共享存儲，所有的虛擬機都指向存儲群集的SOFS路徑以存儲sharevhdx，但實際效果來看，老王認為在2012R2時代，ShareVHDX直接存放在自身虛擬化群集CSV中效果更好

ShareVHDX技術最大的一個好處是對于底層存儲架構的屏蔽，你虛擬機不用管我底層是SAN，JBOD，S2D，ISCSI，只要交付給VM一個CSV或SOFS路徑，VM就可以利用這個路徑來完成ShareVHDX的創建，進而交付給來賓群集共享存儲

ShareVHDX技術還可以用于后端存儲群集，前端多臺Hyper-V主機的場景，虛擬機在其中兩臺主機上，分別指向存儲群集SOFS路徑，這樣做了之后來賓群集可以獲得高可用性，但是主機沒做群集，同樣會帶來隱患，因此最佳還是應該虛擬化群集+來賓群集

在2012R2時代，ShareVHDX還是技術有所限制，經過勾選啟用硬盤共享的磁盤

不支持調整Share VHDX的大小和遷移

不支持創建Share VHDX的備份或副本

Windows Server 2016里面這項技術進行了更新，升級為ShareSet，取消了這些限制，但是要求GuestOS必須為Windows server 2016才可以使用，該技術一直延續到2019

在2016中，ShareSet的添加方式如下

1.為虛擬機創建VHD Set格式磁盤，存放在CSV或SOFS路徑下

2.為虛擬機添加SCSI 控制器下的Share Drive

3.為Share Drive掛載存在VHD Set

被創建的VHD Set將產生兩個新的文件格式

一個.avhdx文件，包含實體數據，此文件是固定的或動態的。

一個.vhds文件，包含用于協調來賓群集節點之間信息的元數據。該文件的大小幾乎是260KB。

對于已經使用了ShareVHDX的技術的虛擬機，可以使用Convert-VHD將ShareVHDX文件離線轉換到VHD Set格式，再添加至ShareDrive

如果您的環境中當前使用的是linux來賓群集，但是使用了2012R2 ShareVHDX，建議先不要升級為2016 ShareSet，可能會存在不支持的情況。

對于來賓群集老王建議首選2012R2 ShareVHDX或2016 ShareSet作為來賓群集共享存儲架構，這種方案對于現有環境的改變最少，不需要改變物理存儲拓撲，其次是ISCSI/虛擬光纖通道/直通磁盤

總結一下，經過寫這篇博客，老王也隨著思考了下實際場景的應用，企業也并非一定要部署來賓群集，尤其是已經有虛擬化群集的情況下

對于虛擬化群集來說，本身你的一個個虛擬機，對于WSFC來說就是一個群集角色對象，節點檢測宕機我按照策略正常故障轉移

但是隨著WSFC和Hyper-V團隊的配合，現在僅在宿主機級別就能夠對Guest虛擬機里面的應用進行一些保護

例如，藍屏檢測，針對我們部署的虛擬機，WSFC可以檢測到虛擬機OS是否藍屏，如果藍屏是要在當前節點或是轉移到一臺其它或者的節點上

應用檢測，WSFC2012開始針對于虛擬機還可以檢測到虛擬機里面的某個服務，一旦超過限定的失敗次數就在當前節點重啟，或轉移到其它節點

來賓網卡保護，可以做到檢測虛擬機連接的網卡，一旦失去連接，則將虛擬機故障轉移到其它節點上。

其實如果不部署來賓群集，我們也可以在這幾個級別來保障虛擬機對象，虛擬機OS，虛擬機網絡連接，虛擬機里面應用的健康，但如果應用確實很關鍵，則仍需要部署來賓群集架構，以獲得最高的可用性，一旦單個節點虛擬機OS崩潰，應用可以故障轉移到另外的虛擬機里面運行，大大減少宕機時間，如果是僅部署一臺虛擬機結合宿主群集，則會帶來重啟的宕機時間。

level1級別的虛擬機應用保護：部署單臺虛擬機，結合藍屏檢測，應用檢測，網卡檢測，防止除主機宕機外這三個因素導致的應用宕機

level2級別的虛擬機應用保護：部署多臺虛擬機，但是不部署來賓群集，虛擬機之間采用應用復制技術，配合宿主群集實現反相關性，讓虛擬機始終不在同一節點，單臺宕機，利用復制技術自動或手動切換應用至其它虛擬機

level3級別的虛擬機應用保護：部署來賓群集+宿主群集，結合反相關性，確保來賓群集的節點始終處于不同宿主，不論是單個主機宕機，或單個虛擬機宕機都不會影響應用

各位企業管理員或顧問可以根據實際場景，虛擬機應用所需要的保護級別，選擇合適的方案，希望可以通過這篇文章為大家帶來思考！