WSFC2016 On Azure

本篇文章，老王將爲你們介紹WSFC在Azure上面跑的一些執行操做，以及操做過程當中須要注意的地方

之因此要寫這篇文章有幾個緣由

1.爲你們破除羣集可否在公有云平臺跑的迷思

2.爲你們帶來羣集在公有云平臺跑的思考

3.爲你們介紹WSFC 2016 藉助於Azure實現的雲S2D，雲仲裁

首先，WSFC羣集能不能在公有云平臺跑呢，答案是能夠的，理論上來講，只要能夠知足創建羣集的要求，咱們能夠在私有云，公有云，混合雲任何一個平臺上面部署羣集

思考一下，當咱們建置一個羣集時有哪些最基本的先決條件要準備

1.確保能夠獲得已激活，正常的操做系統

2.確保節點與節點之間網絡質量良好

3.確保能夠節點間能夠看到共享存儲，或使用第三方複製以實現相似於共享存儲的效果

實現這點要求第三方插件能夠和羣集配合，利用第三方插件複製磁盤作出來的磁盤能被羣集認可爲羣集磁盤，其次若是要在公有云或其它雲平臺上面跑，要確保第三方複製插件能夠被平臺支持。

確認了必備條件後，咱們就能夠來監視各類公有云平臺了，看看對於羣集的需求，公有云平臺是否能夠支援

首先，操做系統，羣集要求能夠獲得一個已被激活，健康穩定的OS，所以須要確保公有云提供的OS，足夠健康，不會由於系統問題而致使羣集的不穩定

確保公有云羣集節點更改機器名，更改成靜態IP，不會影響OS的正常運行。

網絡

羣集節點能夠接受沒有多塊網卡，可是至少要有一塊網卡，這塊網卡會被用來承擔業務流量，CSV流量，羣集通訊流量，羣集須要進行運行情況檢測。

因此，在咱們思考公有云平臺部署羣集時，最主要的一點，公有云上面虛擬機與虛擬機要能夠經過網卡正常通訊，且網絡質量應該是穩定高效的，由於全部流量都壓在一塊卡上，最佳實踐仍是建議能使用多塊網卡則爲公有云羣集節點使用多塊網卡。若是公有云虛擬機網卡能獲得性能優化則最好。

存儲

在以前的傳統概念中，羣集就是必定要訪問共享存儲的，應用必定要數據寫入共享存儲中，隨着應用和第三方插件的更新，應用開始能夠支持使用本地磁盤+複製，以實現羣集磁盤，或高可用效果。

在公有云上面跑羣集很重要的一點:  咱們是在人家的平臺上面，跑 VM 的 Guest Cluster

這意味着咱們沒有FC,FCOE,ISCSI,JBOD,RBOD這些存儲底層架構的訪問權，咱們沒有權利去控制存儲的分配，因此虛擬機能使用什麼樣子的共享存儲，徹底取決於公有云廠商公開到什麼程度，但一般並不會很高，一些有良心的廠商maybe會開放相似於share vhdx的技術，經過底層虛擬化的技術同時把一個虛擬磁盤掛載到多個節點，或者能夠提供ISCSI網關，經過一個安全的方式來提供ISCSI target給虛擬機節點。

若是廠商沒提供方案，咱們以前就須要藉助一些第三方廠商來實現一種，跨節點本地磁盤的複製，讓羣集覺得這是羣集磁盤，但正如以前所說，這要求羣集支持，公有云平臺支持部署這種插件

身份驗證

若是計劃部署羣集爲工做組模型，則不須要考慮公有云平臺對於AD域的支持

若是計劃部署羣集爲AD域模型，則請確認公有云廠商支持安裝AD類型虛擬機，確保安裝出來的AD域能夠在公有云環境能夠正常提供域服務，確保不會由於公有云平臺的磁盤緩存設置，網絡緣由，而致使AD域控制器的不正常運行

一旦羣集部署爲AD域模型，將須要寫入羣集CNO對象，VCO對象的，所以須要確保公有云支持虛擬機跑AD域架構，AD域虛擬機能夠和羣集節點虛擬機在公有云上面正常通訊，羣集節點虛擬機對於AD域的身份驗證請求，CNO，VCO讀取寫入請求能夠正常進行。

以上四條基本要求若是公有云平臺能夠知足後，則意味着羣集在公有云上面跑，就是可行的，那麼咱們就能夠思考下一步，咱們是否真的有必要在公有云部署羣集，什麼場景下，咱們應該在公有云上面部署羣集，對於羣集而言，若是部署在公有云我能夠得到那些好處

首先先來看下，咱們已知的公有云能夠給咱們帶來的好處

1.規模足夠大，可用資源足夠多，咱們能夠部署足夠多的節點

2.使用上咱們只須要爲使用了的資源付費，未使用的資源不會產生費用

3.公有云平臺會負責爲咱們維護服務器，存儲，網絡，等底層設施，咱們不須要爲維護這些設施而花費精力財力

4.公有云平臺一般會定義Region機制，能夠幫助咱們確保若是資源的，存儲，VM，網絡都在同一個Region，那麼同一個Region下的VM，存儲，網絡等資源會盡量的靠近，以得到更好的性能。

5.公有云平臺一般會置備完整的故障轉移，災難恢復方案，在咱們購買服務時，會爲咱們保證SLA，若是SLA獲得違反，咱們做爲使用者能夠獲得賠償。對於公有云平臺的存儲磁盤，一般會獲得多個副本的複製，這個複製多是同Region，或跨Region的機制，針對於網絡，默認狀況下網絡會盡量的和VM，存儲靠近，使用同Region下面的優化網絡鏈路，若是同Region下面的網絡鏈路出現問題，公有云廠商一般能夠幫咱們把網絡鏈路進行快速的切換，針對於虛擬機資源，若是咱們選擇虛擬機到不一樣的Region FaultDomain，或不一樣的Rack FaultDomain，當公有云平臺維護時，可以確保不會同時維護不一樣Rack或Region下的資源。

那麼，既然公有云自己經具有了對於存儲的複製能力，網絡鏈路的冗餘能力，虛擬機的FaultDomain能力，已經這麼完美了，咱們直接在虛擬機上面跑應用就行了，何須再在公有云上面跑WSFC呢

其實非也，從最根原本說，公有云廠商站在的角度，他們是須要保證IAAS架構的SLA，確保您的訂閱不會違背SLA原則，他們不會被要求賠償，這就是公有云廠商的角度，他們只是站在運維保證他們雲平臺的硬件能夠正常服務，維護不會致使停機，就OK了，對於你虛擬機上面跑了應用，你應用的高可用性，是和公有云廠商沒有關係的，須要你本身去在意，本身去選擇合適的方案。

這裏，老王說的只是IAAS的場景，若是說，雲平臺提供PAAS級別的服務，能夠知足您的需求，例如，雲平臺若是提供SQL paas服務，那麼您可能就不須要在公有云上面部署WSFC了，由於咱們之因此要部署WSFC，是由於咱們care vm裏面的應用持續提供服務，個人應用若是是有狀態的，那麼我只部署在一臺，若是我這臺壞了，上面運行的狀態和應用如何遷移到其餘節點運行，iaas級別，公有云廠商是無論你的，公有云廠商只保證，網絡，存儲，服務器不會出現故障，維護或故障不會影響SLA，但若是您的VM裏面跑了有狀態的應用，您但願應用能夠持續提供服務，一旦一臺VM故障，應用依然能夠提供服務，那麼IAAS您必定是須要部署羣集架構來實現。

若是說您以爲公有云廠商提供Paas服務能夠知足個人需求，您接受這種新的思惟，例如SQL paas，這是個應用級別的雲服務，所以公有云廠商會負責從底層硬件，再到系統，到應用的高可用，這是他們應該是care的，例如，一般公有云廠商若是提供數據庫的paas服務，他們一般會置備分片，羣集，高可用組，等技術來幫咱們保證應用的高可用性

若是您以爲信不過paas，這種paas 我又看不到，不知道到底怎麼切換的，我也不熟悉，您但願選擇一種熟悉的模型，那麼您care應用的持續可用，iaas狀況下，只好部署WSFC

所以，WSFC在公有云平臺跑，如下兩種狀況是有必要的

1.購買了公有云的IAAS服務，可是虛擬機裏面跑了應用，您care應用的連續性

2.您不肯意接受雲平臺的PAAS服務，但願得到更高的Control權，使用本身熟悉的方式管理應用的高可用

WSFC在公有云平臺上面跑還有幾種典型的雲優化場景

1.開發測試，本地部署生產的WSFC，上傳雲端跑一套一樣環境的WSFC用做開發測試調試

2.災難恢復，WSFC本地部署一部分節點，雲端部署一部分節點，正常運行在本地端，雲端節點無投票，本地端出現故障，直接failover到公有云，此場景，對於本地端與公有云端網絡鏈路質量要求高

3.雲爆發：本地部署少數節點WSFC以備平常使用，一旦使用發生暴增的狀況，本地節點已經沒法hold，能夠利用雲爆發，直接擴展節點至公有云節點，僅在爆發時使用，爆發後再回到本地節點，計費應僅在爆發時使用

經過上面的介紹，相信你們應該知道了

1.WSFC 部署到公有云的好處

2.WSFC 什麼場景有必要再公有云上面部署

3.WSFC 在公有云上面跑的典型場景

4.WSFC 在公有云部署時須要關注的點

沒有全明白也不要緊，下面咱們將實際以WSFC on Azure公有云平臺爲例，在實驗中討論上面說到的內容

WSFC On Azure 可行性評估

1.操做系統

Azure上面內置了不少虛擬機模板，虛擬機部署後爲已激活，機器名可更改，且是獲得優化的模板，能夠獲得信賴

2.網絡

Azure上面對於網絡採用VNET架構，同一個VNET下的雲虛擬機能夠正常通訊，支持爲虛擬機固定IP，但有一點須要注意，Azure虛擬機默認建立出來都是一塊網卡，咱們出於對羣集的最佳實踐考慮，可能但願可使用多塊網卡，在Azure上面對於已建立在運行的虛擬機要添加網卡極爲麻煩，所以若是但願使用最佳實踐置備WSFC節點多塊網卡，最好在規劃階段規劃好，這樣建立出來的Azure虛擬機就帶有多網卡

3.存儲

在WSFC2016以前，若是WSFC要上Azure，那麼至少08R2以上的，WSFC上了Azure後，對於Guset VM級別的WSFC，Azure不支持公開存儲，不支持ISCSI,SAS,SCSI等方案，沒辦法讓底層的存儲直接分配到虛擬機，share vhdx技術也暫時沒看到可使用的地方，便是說，Azure自己沒有支持Guest VM WSFC共享存儲的方案，Azure虛擬機在其每一個虛擬磁盤上都有獨佔鎖，基於Azure Blob存儲的磁盤將不支持永久保留，也不支持虛擬機裏面直接跑ISCSI Server給WSFC用，所以在WSFC 2016以前，若是要在Azure上面build羣集，那麼羣集存儲只有這幾種方案選擇

> 在Azure上面跑WSFC，可是隻跑不須要共享存儲的羣集appllication，能夠在application級別使用附加虛擬機本機磁盤複製以達到HA的，例如SQL AG

> 使用第三方方案，爲WSFC節點安裝插件，經過第三方插件各個節點本地磁盤進行復制，包裹一層造成羣集能夠認到的羣集磁盤，相似產品有SIOS DataKeeper，Starwind

> 使用Express Route，打通本地和公有云，實現可以把本地端的ISCSI經過安全通道公開給公有云WSFC節點

所以，你們能夠看出，以前在Azure上面跑WSFC，場景頗有限，由於畢竟大多數羣集應用仍是須要一個共享存儲來寫入數據，達到failover的效果，像是SQL AG這樣的仍是在少數，第三方方案，也不見得每一個人都熟悉，Express Route 又超級貴，不是全部公司都用得起，所以，對於公有云能不能跑WSFC不確認的放棄一批，在Azure上面跑了WSFC，可是由於共享存儲沒法公開給虛擬機，羣集應用不能跑，又放棄一批，因此實際上在WSFC 2016以前，在Azure上面跑WSFC的人不多不多

到了WSFC 2016新出了不少雲優化的功能，使WSFC on Azure有了新的可能，WSFC 2016 能夠和Azure配合使用的技術有Storage Space Direct，Storage Replica，Cloud witness，其中對於WSFC On Azure 幫助最大的是Storage Space Direct，如下簡稱S2D，這是一項讓人振奮人心的功能，簡單來講，有了S2D以後，羣集再也不必須須要共享存儲了，您可使用各節點本地磁盤，把各節點本地磁盤貢獻出來，造成一個基於羣集的存儲池，這個存儲池能夠作SSD HHD NVME的分層存儲，或全SSD ,全NVME的存儲池，構建出來的羣集存儲池，上面再構建羣集存儲空間，即虛擬磁盤，每一個虛擬磁盤均可以有本身的容錯策略，簡單，鏡像，奇偶校驗，能夠基於節點級別，磁盤級別定義存儲的QOS，這是微軟進軍軟件定義存儲的新里程碑。

既然提到了S2D，就不得不提存儲池，存儲空間，羣集存儲池，JBOD，SOFS這些概念，正好也藉機會爲你們補一補羣集存儲的課

傳統意義上的羣集存儲已經不用我多講，咱們經過SAN,ISCSI等技術，使用多路徑，把目標分給多個節點服務器，確保全部節點均可以認到磁盤便可

那麼什麼是存儲池和存儲空間呢，簡單來講，老王認爲這是微軟對於存儲虛擬化的一個基本實現，經過OS層面的功能，以及和硬件設備的配合，實現能夠經過廉價的Share SAS，或JBOD，RBOD方案，來構建可靠應用存儲，甚至是羣集存儲，整個過程徹底是在Windows 軟件層面進行定義。

設想一下傳統SAN上面的架構，首先底層也會是一個磁盤集合，而後由上層帶CPU的控制器層對物理磁盤進行集中管理，在控制器層一般存儲設備能夠控制磁盤容錯策略，去重，精簡模式，存儲分層，緩存設置，等一系列存儲管理調整操做，最終最前面是鏈接適配器，將存儲分配給節點後，節點經過ISCSI,FC,FCOE方式，使用多路徑鏈接進來存儲

微軟的存儲池和存儲空間，提出的概念就是要在Windows Server 2012開始，就內置在系統級別支持能夠定義全部的，磁盤集合，存儲控制，最終交付，咱們說過的傳統存儲上面的功能，2012均可以實現，磁盤集合對應到存儲池，存儲控制對應到存儲空間，鏈接適配器對應到SMB，2012開始SMB協議獲得優化，能夠獲得SMB多通道技術，自動聚合多路徑，SMB傳輸過程也能夠利用RDMA,RSS等硬件技術實現傳輸性能優化，所以微軟推出存儲池和存儲空間的願景，是爲了替代掉傳統存儲昂貴的價格，只須要使用share sas，廉價的jbod，rbod，就能夠在系統上面實現存儲上面的高級功能。

那麼，雖然咱們有了存儲池和存儲空間，這很好，咱們把機器插到JBOD上面，在系統層面配置存儲的Raid，去重，分層，精簡模式，這看起來很酷，可是隻是在單機上面跑，咱們還看不到這種場景的價值，真正要想看到存儲池，存儲空間的應用價值，咱們最佳還須要在羣集中構建這種架構，在WSFC 2012開始，咱們能夠在羣集上面部署羣集存儲池，再基於羣集存儲池構建存儲空間，其實所謂的存儲空間，對應到落地就叫作虛擬磁盤的概念了，當咱們建立每一個虛擬磁盤的時候，能夠選擇虛擬磁盤的容錯方案，是否精簡等設置。

一旦咱們部署了羣集存儲池和羣集存儲空間的架構，那咱們這個存儲架構就變了，至關於，咱們把存儲裏面，控制器這個level給羣集化了，咱們在羣集上面配置的存儲池和存儲空間，配置磁盤容錯策略，去重，精簡模式，存儲分層，即使當其中一個節點宕機，羣集存儲池，羣集存儲空間，以及咱們配置過的策略依然會存在，咱們實現了存儲控制器的高可用。

同時，基於羣集存儲池，構建出來的存儲空間虛擬磁盤，被建立完成後，是直接能夠在羣集磁盤裏面看到的，由於控制器被羣集化了，因此建立的虛擬磁盤能夠被全部節點磁盤管理器看到，能夠支持做爲羣集磁盤

這樣咱們就能夠完成一個場景，即Cluster in a Box，我這個羣集就部署在一個Box裏面，這個box裏面有兩個計算節點，還有兩個share sas，或一個JBOD綁定，咱們不用共享存儲，就在一個box裏面，使用JBOD，或share sas，就能夠構建一個羣集啓動起來，羣集磁盤是經過節點的羣集存儲池-羣集存儲空間構建出來，而後最好有RDMA，實現一個SMB3 RDMA 多通道的架構，或者您也能夠獨立出來單獨使用一個JBOD，而後上面接入兩個羣集節點，這樣咱們就實現經過廉價存儲，結合2012的存儲虛擬化技術，配合實現羣集。

那麼SOFS是什麼呢，不少人會覺得SOFS就是存儲空間，存儲池的一套，其實聽完老王的介紹，您就會發現它們根本不是同同樣東西

存儲池，存儲空間最終交付的就是一個磁盤，一個能夠在羣集磁盤中看到的磁盤，意思就是說，你羣集不用在意我底層是什麼存儲架構，不用管底層架構是ISCSI,SAN,仍是羣集存儲池，反正我分給你一塊盤，一塊能夠被全部節點看到的，合格的羣集磁盤就夠了。

而對於SOFS來講，SOFS是無論你是經過什麼途徑提供來的磁盤的，由於SOFS是直接要在CSV上面跑一個共享，SOFS只認CSV，你的底層能夠是SAN,ISCSI,存儲空間，SOFS根本不Care，SOFS只Care，你是否提供了一個正常的CSV，換句話說，即使咱們是傳統SAN架構，咱們也能夠有SOFS

那麼SOFS到底幹嗎的呢，說白了，這是SMB技術配合羣集技術，CSV技術，DNS輪詢技術實現的一種存儲持續可用方案，當咱們構建一個羣集文件服務時，若是選擇應用程序數據的橫向擴展文件服務器，那麼咱們就能夠獲得一個SOFS，獲得SOFS後，咱們會建立新的共享獲得一個UNC路徑，若是支持UNC的羣集角色則可使用SOFS，目前Hyper-V和SQL可使用SOFS的UNC路徑，把應用數據寫入SOFS路徑內，若是在應用感知SOFS的狀況下，咱們能夠獲得持續可用的存儲鏈接

由於SOFS是透明故障轉移的，咱們使用SOFS時，並不會使用一個傳統虛擬的羣集IP，SOFS的UNC路徑名稱會對應到各個節點的本地IP，當應用訪問SOFS路徑時，其實是基於DNS輪詢的，這樣便是說，SOFS UNC路徑對應的文件服務器是AA模式的，全部節點均可以承載鏈接，每次自動挑選最合適的節點提供存儲服務，2012R2開始能夠基於SOFS裏面的不一樣share實現負載均衡，例如針對\\SOFS\Share1由NODE1提供，\\SOFS\Share2由NODE2提供

另外SOFS之因此叫作橫向擴展文件服務器，是由於SOFS支持添加Server，自動加入SMB負載輪詢，例如當前有兩個節點負責三個share的SOFS UNC路徑提供，這就意味着會有一個節點要負責兩個share，這時候若是再添加進來一個節點，就會由三個節點，每一個節點負責一個share的請求提供，以實現負載均衡橫向擴展功能

基本上咱們使用SOFS的核心意義，就是爲了利用SOFS的負載均衡橫向擴展優化性能，或是透明故障轉移能力，在WSFC 2012時代，SOFS尚未獲得優化，那時若是咱們嘗試把虛擬機存在一個SMB路徑下，這時把提供SMB路徑的文件服務器節點直接斷電，上面全部虛擬機將會崩潰。後來SOFS改變了這一點，由於應用每次對於SOFS的訪問，會經過SOFS特有的wintess service來確認用戶訪問的是哪臺節點，而後跟蹤應用的SMB客戶端會話，一旦發生應用當前所在節點宕機，直接透明的把應用的會話轉入到另一個節點，對於Hyper-V和SQL來講，用戶不會感受到中斷，這是最核心的部分，SOFS在DNS輪詢之上，羣集之上，實現了基於羣集的見證檢測引擎，以確保用戶的SMB客戶端會話能夠始終獲得保持。

以上老王簡單爲你們複習了下羣集存儲在2012以後涉及到的新東西，接下來開始就是咱們的重頭戲了，S2D，也是咱們實做WSFC On Azure以前，所須要瞭解的最重要的東西

簡單來講，你們能夠這樣理解，S2D架構，是2012時代 JBOD+存儲虛擬化+羣集的升級版，你2012不是說使用JBOD架構構建羣集廉價嗎，可是也還須要買一個JBOD是吧，我2016比你更廉價，我直接就能夠用每一個節點本地磁盤來作羣集，這個就厲害了，也更加好用，由於JBOD這東西，國內比較仍是用得少，若是你說，你支持本地磁盤貢獻的架構，那可能就更多的人願意嘗試

S2D架構呢，基本上就是咱們羣集時指定NoStorage參數，建立完成羣集後，開啓S2D，開啓S2D會去掃描，每一個羣集節點，當前除了C盤系統啓動盤，還有那些是同樣大小的磁盤，磁盤能夠是SCSI ,SCSI ,SATA均可以，被掃描到的合格的磁盤，會被加入羣集的S2D機箱，以後咱們就能夠繼續作羣集存儲池，羣集存儲空間，CSV , SOFS這些東西了，因此說S2D這個東西，並非說替代掉原有的存儲池，存儲空間，它只是一種：可以在羣集中，把各個節點上面的非系統磁盤聚合起來造成可用存儲池的一種技術。

有了這樣的一個技術，咱們玩WSFC on Azure，就能夠有更多花樣了，爲何呢，由於咱們care wsfc 能不能跑在azure上面，無非是care共享存儲怎麼辦，如今有這種S2D技術了，那我直接啓動幾臺虛擬機，虛擬機我附加數據磁盤，而後在虛擬機裏面啓動羣集，而後開S2D，認到各節點附加數據磁盤能夠做爲能夠存儲池了，而後咱們就能夠玩花樣了，羣集存儲池，羣集存儲空間，到存儲空間這裏，羣集磁盤裏面就能夠看到咱們建立的虛擬磁盤了，已經能夠認到羣集磁盤，這個羣集磁盤底層是經由S2D構建，HA的羣集存儲控制器，且存儲空間建立出來的虛擬磁盤-羣集磁盤，能夠是鏡像的，或校驗的。

固然，這種在雲端上面使用S2D的先決條件，底層的虛擬化主機要和咱們的Guest VM可以相配合，目前根據老王發現，只有底層是Hyper-V主機或ESXI主機，能夠經過附加磁盤的方式來實現Guest S2D Clsuter。

OK，最主要的S2D介紹完了,後邊咱們一會會經過一系列的實驗，來爲你們看清上面老王說的這些S2D的架構，幫助你們在腦殼裏構想出這樣的架構

對於咱們部署WSFC on Azure，除了S2D這一項關鍵技術，咱們還能夠藉助存儲複製，雲仲裁技術，優化咱們的羣集。

存儲複製，是Windows Server 2016上面退出的一項基於Valume Manager 下，Partition manager上面插入的一層複製技術，能夠幫助咱們完成控制存儲的同步複製，或異步複製，複製的級別能夠是本地磁盤，跨服務器磁盤，多站點羣集各站點磁盤，跨羣集磁盤。

有一個典型的場景咱們能夠在Azure上面利用到這項存儲技術

即咱們有一套應用環境，當前基於S2D跑起來在中國，咱們但願在歐洲也有個備份，那麼咱們就能夠分別在中國和歐洲架起來兩座S2D Cluster羣集，而後兩個region下的S2D羣集磁盤作存儲複製，這樣一旦S2D羣集在中國跑，跑失敗了，咱們還可使用歐洲的S2D Cluster，存儲數據都會同步過去

由於Azure自己的磁盤已經能夠是本地複製，或異地複製，所以咱們再Guest內使用存儲複製功能，那必定是由於，對於應用來講，咱們須要可控的複製管理，不管是羣集對羣集，節點對節點，咱們使用存儲複製都是但願可以在故障狀況下，快速保證依賴應用的運行。

雲見證技術，是WSFC 2016和Azure配合新增的一項功能，簡單來講，就是把見證移動到Azure上面，當咱們使用雲見證技術，實際上咱們會在Azure上面建立個存儲帳戶，而後咱們獲取到存儲帳戶的名稱，主訪問鍵值，服務終結點名稱，以後咱們在WSFC 2016裏面選擇雲見證，填寫入這些信息後，會經過HTTPS REST鏈接到Azure的存儲帳戶中，在咱們輸入的存儲帳號下生成一個blob，而後利用這個blob做爲本地WSFC，或Azure上面WSFC的雲見證，每註冊一個羣集使用雲見證後，會在仲裁blob下面帶有ClusterInstanceID，以幫助咱們標識當前blob被那個羣集所使用

雲見證能夠有不少場景，例如，一個多站點羣集的場景，例如北京，上海都有羣集節點，兩邊的羣集數據磁盤都經過存儲複製功能進行復制，可是見證磁盤因爲裏面有羣集數據庫依賴於時間戳，所以不可以使用複製技術，因此，咱們要不就把見證磁盤放到一個遠程站點，別是北京，也別是上海，最好放在一個公平的地方，兩個站點正常均可以訪問到，這樣一旦發生分區後，那個站點能夠訪問到見證磁盤，就能夠被優先啓動，可是若是企業真的就沒有這種第三個站點怎麼辦呢，或者說在第三個站點部署個見證磁盤划過來的代價很高，那麼一般您能夠選擇使用文件共享見證的方式來處理這種多站點羣集，但使用文件共享見證須要注意老王以前提到過的時間分區問題，文件共享見證在幫忙處理羣集分區的場景下能夠很好的工做，但對於時間分區則處理不如磁盤見證優秀，雲見證就是適用於這種，企業沒辦法作第三個站點的磁盤見證或共享見證，那麼雲見證就能夠做爲您的第三個站點，只要付費就可使用雲見證幫助您遵循多站點仲裁的最佳實踐，只要確保您的WSFC節點443端口能夠和Azure通，可以正常聯網，那麼就可以使用雲端見證。

OK，理論準備部分已經基本結束，下面咱們直接進入WSFC On Azure的實戰部分，本次咱們以國內版Azure爲例，在構建WSFC On Azure時，咱們須要在Azure上準備如下內容

1.一個規劃好的VNET，VNET地址空間，預先在子網中規劃好DNS

2.一個標準的存儲帳號，用於雲見證使用

3.確保正常運做狀況下，VM,存儲，網絡，在同一個Region下面運做

4.一個規劃好的雲服務，確保全部WSFC 虛擬機在同一個雲服務下面

5.針對於WSFC節點，利用同一個服務下面的可用性集技術

6.爲每一個WSFC節點，至少新增至少兩塊數據磁盤

除了以上六點外，還有一點須要考慮的，WSFC 2016 的部署模型，要採用工做組模式，仍是基於AD域的模型，在 WSFC 2016時×××始支持使用徹底工做組架構來部署羣集，可是部署出來的羣集，可以適用的應用不多，其中最爲典型的是基於SA驗證的SQL Server羣集，後面老王也會專門發博客講解這種部署模型。

本文咱們仍是主要專一於傳統的羣集模型，即便用AD的羣集，使用AD作身份驗證，這樣能夠確保大部分應用均可以支持

那麼若是咱們決定了要在Azure上面部署AD則又有一些須要須要注意的地方

1.儘可能爲虛擬機使用靜態IP

2.AD數據庫不要存放C盤，Azure的虛擬機Wndows C盤是通過緩存優化的，而AD數據庫不能和這種緩存協同工做，必定要單獨附加一塊無緩存的磁盤用作AD數據庫

3.若是確認Azure的虛擬機要使用域控制器，那麼須要實如今規劃VNET的時候規劃好，域控制器應該是那個DIP，而後把這個DIP保留，並配置爲VNET的DNS服務器，這樣全部同VNET下的WSFC節點，安裝好了後就能看到DNS是域控的IP，能夠正常加入Azure上面的IAAS域。

DC On Azure 有幾個典型的場景

1.使用Azure上面虛擬機安裝DC，而後和本地AD網絡打通，使用Azure做爲AD站點的遠程站點

2.Azure上面跑了一些虛擬機，這些虛擬機須要爲用戶提供Web服務，可是身份驗證每次都須要×××回到本地域控驗證，不只有安全隱患，並且影響性能，能夠選擇雲端部署一臺域控，這樣雲端用戶訪問都是使用雲端域控驗證，本地用戶訪問都是使用本地端域控驗證

3.只是純粹爲Azure上面虛擬機使用而須要部署一臺域控制器提供集中身份驗證，確保最大control度

實驗驗證

建立規劃虛擬網絡，選擇位置在中國北部地區

編輯虛擬網絡訪問空間，對應到VMM的概念這裏應該是VM Network與VM Subnet

規劃虛擬網絡DNS服務器統一爲10.0.0.4，這裏注意，若是咱們但願在Azure上面部署WSFC，虛擬機務必要使用手動規劃的虛擬網絡，不然默認的話，每一個虛擬機都會單獨自動建立虛擬網絡，不會在同個子網下面

完成第一步網絡規劃後，咱們建立一個存儲帳號，用於後期作雲端見證，可是在中國版Portal門戶上面咱們能夠發現已經不能操做存儲帳號，操做存儲帳號會被重定向到新的portal上面

建立存儲帳號，選擇標準，複製保持默認，位置選擇中國北部，確保資源儘量獲得靠近

建立china16dc，node1，node2虛擬機，三臺虛擬機都選擇同一個雲服務下面，確保使用相同虛擬網絡，虛擬網絡子網，相同存儲帳號，針對於node1，node2 WSFC節點，咱們能夠建立設置可用集，利用Azure雲平臺提供的rack faultdomain能力，保證咱們的兩臺機器始終位於不一樣機架，不會同時被維護

針對於Node1 ，Node2 WSFC節點，需開啓443終結點，以便後期節點能夠聯繫到雲端見證

在新portal上面能夠手動選擇三臺機器IP地址爲靜態，咱們選擇爲靜態，對於域控制器咱們按照規劃設置爲10.0.0.4，其它兩個節點5和6

打開域控制器虛擬機能夠看到IP地址已經按照咱們的規劃進行了配置

正常安裝DC On Azure IaaS，建立用於安裝WSFC羣集的cluadmin帳戶，加入DomainAdmins組

確保活動目錄數據庫在E盤，總之，必定要是個非C盤，非D盤的無緩存的數據磁盤！

正常把Node1，Node2加入DC on IAAS的ha.com域

到這裏咱們已經邁出第一大步，構建了一套Azure上面能夠正常提供服務的iaas域環境，咱們再經過遠程登陸時能夠經過ha.com\cluadmin，直接管理WSFC節點虛擬機

接下來咱們準備部署S2D Cluster On Azure，爲Node1，Node2分別附加兩個相同大小的數據磁盤

對於S2D節點的數據磁盤，咱們可使用默認的的存儲帳號，咱們也能夠單獨再建立一個高級性能類型的存儲帳號，而後在裏面建立SSD類型的數據磁盤附加給虛擬機，以獲取更高的性能，若是您的羣集應用須要獲取更高的性能，那麼您有必要這樣作。

上面咱們討論過S2D 讓WSFC on Azure有了不少可能，那麼如今Azure具體有那些WSFC場景呢

1. 使用Express Route打通本地ISCSI Server到Azure WSFC羣集

2. 使用第三方插件構建複製節點本地存儲爲羣集磁盤

3. 不使用S2D的SQL AG(AG自己並不必定須要共享存儲，可在應用級別完成複製)

4. 基於S2D的SQL羣集

5. 基於S2D的SQL AG 

6. 基於S2D提供SOFS，並公開給同VNET下的SQL羣集，實現SQL文件存SOFS(或本羣集)

7. 基於S2D提供SOFS，用於RDS UPD存放路徑，RDS能夠是公有云，或打通×××給本地私有云
   

8. 基於S2D的WSFC羣集，用於其餘羣集負載，例如傳統文件服務器，通用程序，通用服務等

9. 基於S2D的WSFC羣集，實現跨Region羣集對羣集的存儲複製
   

接下來老王將爲你們你們實做第四種場景出來，咱們經過在WSFC on Azure上面構建一個S2D的存儲模型，而後上層提供一個SOFS路徑，這個SOFS能夠被用於本羣集，或交付給同VNET下的其它羣集。

接下來咱們要在WSFC on Azure上面啓S2D了，根據實驗，老王發現Azure上面啓動S2D和本地端不太同樣，咱們不能使用Enable-ClusterStorageSpacesDirect命令來構建，但可使用Enable-ClusterS2D，此外對於每一個S2D節點，須要執行winrm /quickconfig

針對於Node1，Node2執行winrm /quickconfig

爲Node1，Node2安裝故障轉移羣集功能，而後執行如下命令，建立羣集

New-Cluster –Name sofs –Node Node1,Node2  -StaticAddress 10.0.0.12 –NoStorage

建立完成後咱們獲得了一個正常的WSFC on Azure，但如今羣集沒有存儲，除非使用SQL AG等不須要共享存儲的應用。

接下來咱們須要爲羣集開啓S2D，讓羣集去收集各節點本地磁盤，聚集成可用的羣集存儲池

若是是使用Enable-ClusterStorageSpacesDirect建立S2D，你會發現一個83頁VPD的警告，隨後SDS報錯沒法找到合適磁盤

這時使用Enable-ClusterS2D命令則可規避此問題，因爲咱們都是HDD環境，因此不須要進行緩存設置

Enable-ClusterS2D -CacheState disabled -Autoconfig 0 -SkipEligibilityChecks

建立完成後提示警告，打開所屬htm，能夠看到只是咱們執行的結果，2塊系統磁盤沒法被收集進入能夠存儲池，各節點兩塊數據磁盤，共計四塊，已被添加至羣集能夠的存儲池。

打開羣集機箱能夠看到已有的機箱信息

點擊池，新建存儲池，輸入名字後，能夠看到S2D收集上來的可用磁盤組，這和2012R2 JBOD的顯示還不太同樣

2012R2 JBOD架構構建羣集存儲池直接顯示爲Clustered Storage Spaces

選擇可用物理磁盤，若是這裏磁盤少於3塊，則會提示沒法進行下一步建立存儲池。

建立完成後，咱們如今有了羣集存儲池，點擊新建虛擬磁盤，構建羣集存儲空間

建立結果以下，你們能夠看到，咱們能夠爲每個虛擬磁盤，選擇存儲數據佈局，簡單，鏡像，校驗

通常狀況下，建立完成的羣集存儲空間虛擬磁盤，就能夠直接在羣集存儲中看到磁盤，應該是羣集和存儲存儲空間達成了一些合做，一旦檢測到存儲空間分出來的虛擬磁盤，那就是分配給全部節點的，那就是應該用作羣集磁盤，因此自動拿了過來

添加磁盤爲CSV，注意，可用存儲須要被格式化爲NTFS格式，才能夠被用於CSV

最終，咱們要交付一個SOFS路徑，經過羣集添加角色便可，須要注意，因爲SOFS須要在CNO同OU下產生VCO，因此須要賦予CNO對象對於OU的管理權限，以及對於DNS區域能夠建立DNS記錄的權限，不然SOFS不會建立成功

DNS正常添加了DNN記錄

SOFS文件服務器也經能夠正常基於CSV添加，隨之咱們建立一個路徑，給SQL羣集使用，如今咱們獲得了一個SOFS On S2D Cluster On Windows Azure！

經過實驗，相信你們已經瞭解了雲平臺上面跑WSFC羣集的S2D架構流程

雲平臺級別附加虛擬機磁盤 -> 建立WSFC羣集  -> 開啓S2D功能收集磁盤  -> 建立羣集存儲池  -> 建立存儲空間 -> 獲得羣集磁盤 ->構建羣集共享卷 -> 交付SOFS

雖然有點複雜，但只要理清了思路，並不難，關鍵仍是思惟的轉變，說簡單些，咱們只是找到了一種新的羣集存儲架構模式，利用一整套存儲虛擬化帶來的好處，經過S2D能夠爲羣集構建羣集磁盤，而再也不須要提供商公開存儲。經過使用S2D技術爲咱們在公有云上面部署WSFC帶來了不少新的可能，將來也但願微軟推出更多方便好的技術，幫咱們在各類雲平臺部署WSFC，把WSFC帶到任何地方

相比之下，雲見證技術並不如S2D在WSFC on Azure上面發揮了那麼重要的做用，可是雲見證技術也能夠幫咱們優化羣集，不管是本地WSFC，或是WSFC On Azure，本地WSFC節點打通到Azure的443端口就可使用雲見證，WSFC on Azure，雖然咱們能夠經過S2D構建起來羣集，可是咱們須要考慮羣集的見證磁盤，若是就是WSFC本節點經過S2D啓一個見證磁盤，也能夠啓，可是這不是最佳實踐，咱們能夠利用徹底獨立於WSFC S2D以外的雲見證技術來完成羣集的見證，利用Azure上面的存儲blob來幫助咱們保證羣集見證。

對於雲見證，咱們不須要準備太多，確保WSFC節點443端口獲得正常開放，能夠和Azure存儲通訊，以後準備一個標準的存儲帳號便可

複製事先準備好存儲帳號的主鍵值

打開羣集仲裁嚮導，選擇高級仲裁配置

選擇仲裁見證爲，配置雲見證

輸入存儲帳戶名，複製的存儲帳戶主訪問鍵，若是是Global Azure，服務終結點保持默認便可，國內版Azure 須要更改成core.chinacloudapi.cn

點擊下一步，WSFC 2016節點會經過443端口去聯繫Azure存儲帳號，follow 服務終結點去尋找一個能夠被寫入的存儲路徑，以後把WSFC的ClusterInstanceID記錄下來，生成一個塊blob，咱們WSFC的雲見證仲裁就是由這個blob提供

配置成功後能夠在羣集上面看到當前見證已經變爲雲見證

雲見證很好，是一項很好的技術，在咱們沒有第三個站點的狀況下，能夠幫助本地多站點架構遵循最佳實踐，使用公有云做爲見證仲裁，由Azure存儲幫咱們保證見證的可用性，惟獨要求打通443端口，對於WSFC on Azure來講，第三個站點見證也不便於部署，因此能夠利用雲見證技術

在面對一個集羣網絡分區的時候，例如兩個節點之間不通時，那個節點能夠和雲見證經過443創建鏈接，那個節點就能夠獲勝繼續提供服務，只要雲見證在咱們的羣集就能夠支撐到最後一個節點

若是說您的 WSFC on Azure 羣集不須要遵循最佳實踐，能夠正經常使用就行，那麼您也能夠選擇經過一臺其它的Azure機器，例如DC，來構建一個文件共享，用於WSFC on Azure的共享見證

與雲見證相似的，還有一種看起來可行的方案，Azure File Services，不少朋友也會想到使用一個Azure File路徑來爲羣集作文件共享，但實際操做你會發現羣集會拒絕一個Azure File Services的Azure文件共享見證，由於使用Azure File Service 必需要輸入Azure分配的特定身份驗證信息，因此若是要藉助Azure技術實現WSFC見證，只有雲見證技術能夠選擇

那麼以前文章裏面挖過的坑，也是時候該填上了，雲見證到底能不能處理時間分區

時間分區便是說其它節點不在線的的狀況下，我修改羣集信息，新增資源，以後shutdown，以前羣集信息修改不在線的節點再開機，是否能夠繼續提供服務，2012R2時代，磁盤見證能夠，由於磁盤見證裏面有一份羣集數據庫，即使其它節點修改資源時我不在線，我也能夠從磁盤見證裏面撈回來最新的羣集數據庫，而文件共享見證則不能夠，文件共享見證在這種狀況下，以前修改羣集信息時不在的節點，再開機，會發現羣集沒法啓動，由於沒有最新的羣集數據庫，只有等待以前以前修改信息的節點啓動才行。

實驗驗證，雲見證一樣沒法處理時間分區，緣由是雲見證blob裏面不會有羣集數據庫

能處理時間分區的只有磁盤見證，所以若是您擔憂會發生時間分區場景，那麼您須要想辦法讓羣集使用磁盤見證，能夠是S2D構建或express route打通，或者您能夠選擇在Azure上面部署奇數節點的羣集，這樣有百分之66左右的概率能夠支撐到最後一個節點！