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級別的虛擬機應用保護：部署來賓羣集+宿主羣集，結合反相關性，確保來賓羣集的節點始終處於不一樣宿主，不管是單個主機宕機，或單個虛擬機宕機都不會影響應用

各位企業管理員或顧問能夠根據實際場景，虛擬機應用所須要的保護級別，選擇合適的方案，但願能夠經過這篇文章爲你們帶來思考！