來賓羣集是老王WSFC系列前面遺漏的一個章節，本篇老王將探討來賓羣集的架構，並對其中一些概念進行演示，之前老王和一些朋友探討來賓羣集，發現有一些朋友對於來賓羣集概念的理解，存在着一些誤區，因此希望通過這篇文章幫助大家正確理解來賓羣集架構
首先老王先來個來賓羣集下一個定義：基於虛擬化主機或虛擬化羣集中虛擬機裏面的應用羣集
當我們說虛擬化羣集，其實我們說的不是來賓羣集，我們目前在現實生活中探討的虛擬化羣集通常指的是主機級別的羣集，我們可能把幾臺物理機做成虛擬主機羣集，在上面跑了很多虛擬機，但是虛擬化羣集實質上是物理主機級別的容錯，當一臺物理機宕機，上面所承載的虛擬機會全部轉移到其它活着的節點上
而來賓羣集，則說的是我們在兩臺虛擬機之間，做成了羣集，有人會問，做虛擬化羣集不就好了嗎，爲什麼還要做來賓羣集呢，實質上是虛擬化之後帶來的正常需求，舉個例子，我們當前完成了公司虛擬化的遷移，將原來大部分物理機都已經轉換成了虛擬化羣集資源池，上面的所有業務都已經遷移到虛擬化環境，那麼好了，我原有業務是羣集架構，保證了高可用，遷移到虛擬化羣集之後你怎麼幫我解決我的應用高可用問題，這是應用管理員應該對羣集管理員提出的問題
傳統情況下 羣集管理員可能會想到 備份虛擬機 ，或者在虛擬化羣集級別對用戶多臺虛擬機進行控制，例如使用反相關性，保證用戶的應用虛擬機始終被分佈到不同主機上，從這一級別保證用戶虛擬機的高可用，但這這種配置僅適用於前端虛擬機，如果是有狀態的應用虛擬機，數據庫虛擬機，則需要配置成複製架構，這樣當一臺宕機後，另外一臺纔可以正常使用，但如果應用管理員處於一些原因並不願意將虛擬機設計成複製架構以配合主機羣集層面的反相關性，則就需要另想辦法，答案就是部署來賓羣集
允許應用管理員在兩臺虛擬機之間部署羣集，以解決應用高度可用問題，通過部署來賓羣集，在這個場景中，用戶將獲得和以前物理機管理羣集一樣的體驗，虛擬機裏面的應用將獲得高可用，當一臺虛擬機宕機，虛擬機裏面的應用會故障轉移至另外一臺虛擬機提供服務
來賓羣集的使用場景如下
單機物理機，公司可能資源有限，只能提供一臺性能充足的物理機，管理員就在這上面部署虛擬機給業務使用，業務需要保證虛擬機高可用，最小RTO，於是採用來賓羣集方案，爲虛擬機部署羣集，同時結合安全手段控制用戶訪問虛擬機
虛擬化羣集+來賓羣集，應用管理員希望擁有自己對於自身應用系統羣集的完全管理權限，希望應用維持和以前一樣的高可用架構方案，確保從主機到虛擬機應用的端到端高可用
對於應用管理員來說，部署來賓羣集是對自己應用可用性的又一道保障，舉個例子，如果不部署來賓羣集，可能用戶是兩臺虛擬機，部署在Hyper-V羣集上面，假設Hyper-V主機檢測到一臺虛擬機藍屏，會把虛擬機重啓，或者執行遷移到其它主機操作，但其實從應用角度我們需要的不是這個，需要的是被藍屏這臺虛擬機上面的應用快速轉移到其它虛擬機上，主機級別的羣集是看不懂你應用的，它最多隻能知道你這臺虛擬機藍屏了，或者那個服務停了，我應該把你這臺虛擬機遷移到其它主機上面試試看能不能啓動起來，而不會去操控虛擬機裏面應用的故障轉移，如果我們沒有爲虛擬機設計自動故障轉移的複製架構，這時候虛擬機裏面的應用就面臨着宕機
如果是部署了來賓羣集架構，會發生的就是 一臺虛擬機藍屏了，上面應用肯定掛了，來賓羣集其它虛擬機通過運行狀況檢測，檢測到有虛擬機宕機，自動會將它上面的應用轉移過來，提供服務，這就是有沒有來賓羣集的區別
對於來賓羣集而言，從應用的角度，應用是不知道我這是來賓羣集，還是物理機羣集，應用只知道我底層是一個操作系統，這個操作系統有沒有部署羣集，如果有部署羣集，那麼我就可以完成在來賓節點之間完成故障轉移。
部署來賓羣集是對虛擬機內部應用的保護，它防止的是這臺虛擬機操作系統的崩潰，一旦這臺虛擬機的操作系統崩潰，我的應用可以快速轉移到其它虛擬機節點工作
部署虛擬化羣集是對虛擬機對象和主機的保護，它防止的是某一臺物理機的崩潰，一旦一臺物理機崩潰，或發生硬件故障，則上面所有虛擬機可以轉移到其它節點工作
雖然我們上面說部署了來賓羣集之後，可以保障應用的可用性，除了防止主機故障，也可以防止操作系統故障，但是如果我們是虛擬化羣集+來賓羣集的架構，仍然需要應用管理員與羣集管理員的配合，以完善端到端的高可用性，舉例來說，如果不經過配合，虛擬化羣集通常會由專門的資源管理系統負責調度，很有可能會把用戶的來賓羣集所有節點都放在一個宿主機節點上，那麼一旦這臺宿主機宕機，則來賓羣集所有節點也就宕機，部署來賓羣集也就失去了意義，因此，爲了確保來賓羣集應用的高可用，必須要求羣集管理員爲來賓羣集配置維護策略，最好的解決辦法是配置反相關性，讓兩臺來賓羣集虛擬機不在相同物理機上運行，除非只剩下最後一臺物理機。這樣配置之後不論是WSFC還是SCVMM都會遵循反相關性策略，這樣就真正達到了主機高可用，虛擬機操作系統高可用，即便是一臺物理機壞了，也絕不會影響虛擬機裏面的應用
如果是四個節點的來賓羣集，則可以參考這樣的策略，宿主機羣集配置兩臺虛擬機的首選節點爲第一臺物理機，兩臺虛擬機的首選者節點爲第二臺物理機，這樣在羣集評估放置策略的時候也會遵循首選所有者策略，確保兩兩虛擬機分別在兩臺物理機上，如果一臺物理機宕機，來賓羣集仍在另外物理機上面可用
雖然部署來賓羣集的方案看起來很好，能夠爲虛擬機裏面的應用帶來更多保障，但也有它隨之帶來的問題
對於羣集來說，羣集是不管你是虛擬機或是物理機的，WSFC支持全虛擬化羣集，全物理機羣集，虛擬機物理機混合的羣集，只要羣集各節點滿足羣集部署的先決條件即可，那麼最重要的一點來了，共享存儲，我們說部署羣集就需要共享存儲，應用需要把數據存放在共享存儲裏面，纔可以把應用無縫的進行故障轉移
如果我們部署來賓羣集，存儲怎麼辦呢，就需要管理員想辦法，把物理環境中的磁盤公開給來賓羣集，讓來賓羣集完成羣集的建立
通常情況下來賓羣集的存儲分配大體有以下幾種方案
ISCSI，這個最常見了，隨着網絡速率的提高，ISCSI已經被用於很多現實企業環境，如果要提供給來賓羣集，如果設備或超融合產品支持，可以直接在物理環境上面分配一個target給虛擬機，或者部署iscsi server ，可以是微軟的或者starwind，最好是高度可用的ISCSI 提供呈現，如果沒有環境，那麼部署一臺單獨的虛擬機，或者直接在物理機上面安裝ISCSI提供給虛擬機使用也是可以的
直通磁盤，也是一種可行的方案，簡單來說，直通磁盤就是我們將物理磁盤不通過創建虛擬磁盤的方式，直接在虛擬化主機磁盤管理脫機，傳遞給虛擬機中使用，由虛擬機直接使用磁盤，在WSFC中直通磁盤僅限於來賓虛擬機羣集使用，且存在一定的限制，從WSFC 2008開始，微軟支持爲羣集添加直通磁盤，理論上我們可以部署一個虛擬化羣集，但是不給羣集分配共享存儲，而讓虛擬機使用直通磁盤
WSFC 2008時代爲羣集添加直通磁盤步驟如下
脫機物理機磁盤
脫機來賓羣集虛擬機
新增SCSI控制器，選擇被脫機的物理機磁盤
虛擬機開機，內部看見物理機分配的直通磁盤
在主機羣集管理器刷新虛擬機配置，看見直通磁盤成爲虛擬機依賴磁盤
WSFC 2012時代爲羣集添加直通磁盤步驟如下
脫機物理機磁盤
將直通磁盤添加至羣集磁盤
關閉來賓虛擬機，新增SCSI控制器，選擇直通磁盤
虛擬機開機，內部看見物理機分配的直通磁盤
在主機羣集管理器看見直通磁盤成爲虛擬機依賴磁盤
可以看到，雖然我們說直通磁盤可以被添加到虛擬化羣集，但實質上，並不是說使用直通磁盤來作爲羣集共享磁盤，而是在虛擬機配置中，把直通磁盤作爲一個依賴項目，添加進來，達到的是一個什麼效果，當發生計劃外故障轉移的時候，虛擬機會被轉移至其它節點，依賴的直通磁盤，也將轉移過去，因爲Hyper-V主機實際上並未安裝存儲。是guest虛擬機直接執行直通磁盤IO，這意味着所有節點無法同時訪問存儲，因此當發生故障轉移時，直通磁盤將在當前物理節點脫機，再到其它節點掛載聯機，之後才能完成虛擬機的遷移，這將大大增加故障轉移時間，實時遷移時直通磁盤將必須從當前的Hyper-V主機卸載然後安裝在新的Hyper-V主機上，此過程將減慢VM的遷移速度，並可能導致客戶端明顯暫停，甚至斷開連接。
除此之外，直通磁盤會與單臺虛擬機綁定，例如我們如果將一塊磁盤分配給虛擬機，那麼這塊直通磁盤將不能再用作其它用途
因此實際環境中使用直通磁盤做來賓羣集機率並不大，曾經在2008時代，直通磁盤效率與VHD有明顯差距，而且那時候單個VHD有2TB的限制，通過部署直通磁盤，在那時可以幫助我們解決性能問題，虛擬機磁盤大小問題，同時將底層的FC或其它架構存儲直接交付給虛擬機。
即便是使用直通磁盤，通常情況下企業也不會單獨使用，一個宿主機羣集裏面會有多臺來賓羣集，這些來賓虛擬機的操作系統，還是會被存放在共享存儲裏面，而直通磁盤更多的是一種專用存儲的概念，我們可以把一些類似於數據庫文件等數據存放在直通磁盤，這樣混合使用
直通磁盤羣集架構的利弊
支持映射Hyper-V物理環境連接的SAN，ISCSI，NAS，本地硬盤至虛擬機
在沒有Hyper-V增強會話模式之前支持映射USB存儲
不支持快照，差異磁盤，動態磁盤，Hyper-V副本
主機備份無法備份傳遞磁盤，需要在來賓虛擬機裏面安裝代理進行備份
計劃內維護遷移會有宕機時間
管理不夠靈活，不如管理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之間交替。
配置步驟如下
爲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級別的虛擬機應用保護：部署來賓羣集+宿主羣集，結合反相關性，確保來賓羣集的節點始終處於不同宿主，不論是單個主機宕機，或單個虛擬機宕機都不會影響應用
各位企業管理員或顧問可以根據實際場景，虛擬機應用所需要的保護級別，選擇合適的方案，希望可以通過這篇文章爲大家帶來思考！