WSFC2016 跨羣集複製

   前面兩篇文章中，老王和你們介紹了存儲複製的功能，在單機對單機，以及延伸羣集的實踐，基本上你們能夠看出，這是一種基於塊級別的存儲複製，原生內置於Windows Server 2016上面，能夠幫助咱們實如今單機對單機場景下的災備，也能夠結合羣集，實現存儲和應用結合，當發生站點級別災難的時候，自動轉移存儲和應用

   對於工程師來講，如今架構上又多了一個新的選擇，咱們能夠不借助設備，不借助第三方產品，就使用微軟原生的OS實現高可用+災難恢復

  雖說延伸羣集很好，可是仍有一個弊端，即不能直接使用各節點本地磁盤完成存儲複製，各站點節點還必須接入本身站點的存儲，兩個站點需以非對稱共享存儲的方式來完成複製，老王猜測微軟的本意，就是但願把延伸羣集這項功能用於異地站點不一樣共享存儲，例如北京站點各節點接入北京站點的存儲，天津站點各節點接入天津站點的存儲，而後呢，在兩個Site之間作存儲複製，以實現延伸羣集的效果，即使是本地站點存儲和計算節點所有崩潰，另一個站點也可使用

  不過老王猜測應該仍是羣集機制的緣由，致使目前延伸羣集還不能使用各節點本地磁盤，由於微軟羣集設計之初就是要求實現羣集存儲永久保留，羣集數據存放共享存儲，以便切換直接掛載，若是直接本地磁盤進入羣集磁盤，故障切換上會有一些問題

  雖說微軟2016有了S2D技術，能夠實現超融合存儲，可是它本質上功能和咱們講的災難恢復仍是有一些區別，S2D老王認爲是存儲+羣集結合起來的一項技術，咱們在羣集上面啓用S2D，以後經過一個存儲匯流排把各個節點的磁盤聚集在一塊兒，可是注意，這裏並非說各節點的本地磁盤直接就進到羣集磁盤，而是在羣集存儲裏面機箱的區域能夠看到全部節點的可用磁盤，咱們開啓S2D後，能夠至關於咱們邏輯的構建了一個存儲機櫃，這個存儲機櫃裏面的存儲是來自各個節點的磁盤，接下來要怎麼用呢，咱們還須要在這個邏輯的存儲機櫃上面劃分Lun給各個節點接入，因此咱們建立存儲池，虛擬磁盤，實現容錯，分層，緩存，最終交付到羣集上面是虛擬磁盤，虛擬磁盤就能夠被認做是一個羣集磁盤，可是事實上只會顯示一個羣集磁盤，即使這個虛擬磁盤是經過邏輯存儲機櫃，多個節點建立出來的。

  因此，在老王看來，S2D是藉助於羣集，實現了一個邏輯存儲機櫃，而後分配存儲給羣集應用使用，因此這個概念你們能夠看到，和咱們的存儲複製仍是有一些出入，相對來看，彷佛業界都是經過S2D這樣的超融合架構來實現延伸羣集

  

  直接底層S2D邏輯存儲機櫃的層面作好站點感知，而後分配給羣集，存儲在底層已經作好了容錯，微軟爲何沒有實現這種架構，老王猜測應該是優化和機制的問題

  1.當前S2D只能作到機架感知和機箱感知，不能作到站點感知，即沒辦法控制數據撒到不一樣站點

  2.S2D對於網絡性能要求過高，不適用於延伸羣集場景

也maybe，過幾個版本微軟會針對於S2D作站點感知的優化，到時咱們就能夠實現超融合延伸羣集，或者災難恢復延伸羣集

就目前的狀況來看，咱們只能經過災難恢復來實現延伸羣集的效果，那麼不少朋友可能會問，爲何延伸羣集不能和S2D相結合一塊兒來用

首先老王認爲在微軟生態環境中這是兩個解決不一樣場景的方案

延伸羣集，是爲了處理跨站點羣集，存儲的災難恢復，爲兩個站點的存儲實現複製，確保能夠接受站點級別的災難

S2D，     是爲了處理存儲設備昂貴，經過本地磁盤實現羣集存儲，經過操做系統軟件實現存儲設備的管理功能

若是咱們使用S2D，在同一個羣集內並不會顯示兩套存儲，僅會顯示一套存儲，由於S2D是在底層實現的存儲容錯

而延伸羣集須要兩套存儲，以實現不一樣站點的存儲複製

因此根據目前這個定位來看，老王認爲延伸羣集不會和S2D有什麼契合點，除非後面的版本有大變化

1. 廢棄當前經過存儲複製機制實現的延伸羣集，優化S2D站點感知，實現延伸羣集

2. 優化S2D站點感知，實現兩種延伸羣集模型

3. S2D架構開通一個click鍵，是否要實現延伸羣集，若是是，則不經過底層容錯，而提供兩套存儲，實現存儲複製

就老王來看，我認爲1和3的概率都不大，2的概率大一些，反正如今網絡也不是瓶頸，若是企業有錢，固然能夠選擇用S2D實現延伸羣集

事實上老王以爲目前這個存儲複製實現的延伸羣集效果也挺好的，對於企業沒有高級存儲設備，可是又想實現跨站點的災備，經過存儲複製+羣集，能夠實現很低的RTO和RPO，災難切換的時候實現徹底自動化，這更是一大優點

那麼這是對於延伸羣集中存儲複製，S2D的一些探討，對於Windows Server 2016的存儲複製來講，咱們還有另一種場景，跨羣集複製，將存儲複製擴展至羣集邊界外

在這種場景中，咱們就能夠把S2D方案和存儲複製方案相結合

前文咱們提到過，存儲複製解決方案對於存儲沒有要求，底層能夠是本地SCSI/SATA，ISCSI，Share SAS ，SAN，SDS，對於延伸羣集來講，多是須要非對稱共享存儲的架構，要是ISCSI，SAN，JBOD等架構，可是對於單機對單機或者羣集對羣集來講，就沒有這麼多說法了，咱們可使用本地磁盤和SDS架構，在單機對單機的架構中，就至關因而，我給你係統OS提供一個存儲，你別管我是怎麼來的，只要兩邊大小一致符合要求就能夠創建存儲複製，羣集對羣集也基本上差很少，能夠把一個羣集當作一個大主機，兩個羣集就是兩個大主機，你別管我這個羣集的存儲怎麼來的，總之我羣集有符合要求的存儲，只要兩個羣集的存儲配置都符合要求，就能夠進行羣集對羣集的複製

這就有不少場景能夠玩啦

例如：北京站點羣集存儲架構是ISCSI，天津站點羣集存儲架構是S2D，而後針對於兩個羣集作存儲複製，一旦ISCSI主存儲沒法正常提供服務，馬上切換至天津站的提供服務，或者北京站點採用物理機部署，天津站點採用虛擬機部署，北京站點使用私有云部署羣集，而後再在公有云部署羣集，本地羣集和存儲宕機，公有云裏面的羣集和存儲能夠啓動起來

羣集對羣集複製的好處

1.不用額外配置站點感知，若是北京羣集都在北京站點，只會是羣集內故障轉移

2.兩個站點的存儲底層架構能夠不同，避免單一類型存儲都出現故障

3.支持同步複製與異步複製

4.支持更復雜的架構，例如華北羣集和華南羣集，華北羣集由北京節點和天津節點構成，華南羣集由廣東和深圳節點構成，各站點內部分別配置站點故障感知，北京節點壞了或者天津節點壞了可有可無，應用會漂移至同羣集的相近站點，若是整個華北地區羣集所有宕機，還能夠再華南羣集從新啓動羣集角色

5.幫助實現羣集級別的容災，例如若是北京羣集配置出現故障，不會影響到天津羣集，天津羣集能夠利用複製過來的存儲啓動羣集角色

6.兩個站點可使用不一樣的網絡架構，以實現子網的容錯

羣集對羣集複製的壞處

1.須要手動使用命令進行故障轉移，無圖形化界面操做

2.故障轉移時，需事先在備羣集準備好羣集角色，而後從新掛載上存儲

3.針對於文件服務器，跨羣集故障轉移後需使用新名稱訪問

跨羣集複製技術部署需求

1. 各複製節點操做系統須要是Windows Server 2016數據中心版

2. 至少有四臺服務器（兩個羣集中各兩臺服務器），支持最多 2 個 64 節點羣集

3. 兩組共享存儲， SAS JBOD、SAN、Share VHDX、S2D或 iSCSI，每一個存儲組設置爲僅對每一個羣集可用

4. 複製節點需安裝File Server角色，存儲副本功能，故障轉移羣集功能

5. Active Directory域環境，提供複製過程各節點的Kerberos驗證

6. 每一個複製羣集至少須要兩個磁盤，一個數據磁盤，一個日誌磁盤

7. 數據磁盤和日誌磁盤的格式必須爲GPT，不支持MBR格式磁盤

8. 兩個羣集數據磁盤大小與分區大小必須相同，最大 10TB

9. 兩個羣集日誌磁盤大小與分區大小必須相同，最少 8GB

10. 須要爲各羣集內須要被複制的磁盤分配CSV或文件服務器角色

11. 存儲複製使用445端口（SMB - 複製傳輸協議），5895端口（WSManHTTP - WMI / CIM / PowerShell的管理協議），5445端口（iWARP SMB - 僅在使用iWARP RDMA網絡時須要）

    
    

跨羣集複製規劃建議

1. 建議爲日誌磁盤使用SSD，或NVME SSD，存儲複製首先寫入數據至日誌磁盤，良好的日誌磁盤性能能夠幫助提升寫入效率

2. 建議規劃較大的日誌空間，較大的日誌容許從較大的中斷中恢復速度更快，但會消耗空間成本。

3. 爲同步複製場景準備可靠高速的網絡帶寬，建議1Gbps起步，最好10Gbps，同步複製場景，若是帶寬不足，將延遲應用程序的寫入請求時間

4. 針對於跨雲，跨國，或者遠距離的跨羣集複製，建議使用異步複製

跨羣集複製能夠整合的其它微軟技術

部署：Nano Server , SCVMM

管理：PS，Azure ASR，WMI，Honolulu，SCOM，OMS，Azure Stack

整合：Hyper-V，Storage Spaces Direct ，Scale-Out File Server，SMB Multichannel，SMB Direct，重複資料刪除，ReFS，NTFS

微軟跨羣集複製場景實做

本例模擬兩座異地羣集相互複製，北京站點兩個節點，天津站點兩個節點，北京站點有一臺DC，也承載ISCSI服務器角色，北京站點羣集使用ISCSI存儲架構，天津站點兩個節點，使用S2D架構，分別模擬節點宕機，站點宕機，站點恢復後反向複製。

AD&北京ISCSI

Lan：10.0.0.2 255.0.0.0

ISCSI：30.0.0.2 255.0.0.0

 

16Server1

MGMT: 10.0.0.3 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.3 255.0.0.0

Heart：18.0.0.3 255.0.0.0

 

16Server2

MGMT: 10.0.0.4 255.0.0.0 DNS 10.0.0.100

ISCSI：30.0.0.4 255.0.0.0

Heart：18.0.0.4 255.0.0.0

天津站點

16Server3

MGMT: 10.0.0.5 255.0.0.0 DNS 10.0.0.2

S2D：30.0.0.5 255.0.0.0

Heart：19.0.0.5 255.0.0.0

 

16Server4

MGMT: 10.0.0.6 255.0.0.0 DNS 10.0.0.2

S2D：30.0.0.6 255.0.0.0

Heart：19.0.0.6 255.0.0.0

因爲咱們採用羣集對羣集架構，所以網絡上面也更加靈活，例如，心跳網絡沒必要都在同一個網段內，由於心跳網絡是羣集級別，跨羣集了以後即使你在一個網段，另外的羣集也不知道，管理網絡也可使用不一樣的子網，例如若是不作多個複製組，不作多活的話，那麼天津的對外網絡能夠設置在一個安全的網段下，正常不對外提供服務，再經過網絡策略限制存儲複製流量從ISCSI卡到S2D卡，這樣只須要打通兩個羣集的存儲流量便可，天津若是有DC，則最好羣集可使用天津站點DC。當災難發生時，再把北京的網絡和天津的管理網絡打通，讓北京用戶訪問天津的角色

操做流程

1.北京站點接入存儲

2.北京站點建立羣集

3.北京站點建立羣集角色

4.天津站點接入存儲

5.天津站點建立羣集

6.天津站點開啓S2D

7.天津站點建立羣集角色

8.分配互相羣集權限

9.建立存儲複製

10.站點災難恢復

北京站點接入存儲

16server1

16server2

北京站點建立羣集，配置羣集仲裁爲文件共享見證或雲見證

北京站點建立文件服務器羣集角色

能夠看到，老王這裏建立的羣集角色是SOFS，這是跨羣集複製和延伸羣集的不一樣點，延伸羣集的時候微軟說明負載只是CSV和傳統高可用文件服務器角色，可是在跨羣集複製時場景又變成了能夠支持SOFS，咱們都知道SOFS主要強調的是文件服務器雙活以及透明故障轉移，因爲在延伸羣集中故障轉移須要先存儲切換再轉移角色，所以很難實現透明故障轉移，在跨羣集複製時，可能因爲是兩個羣集，因此每一個羣集內部能夠部署SOFS，實現羣集內部的透明故障轉移，至於站點故障，則沒辦法徹底透明

天津各節點接入本地存儲，大小隨意，最後咱們在羣集存儲空間上面會從新建立羣集磁盤

16server3

16server4

拿到存儲後，各節點把磁盤聯機，初始化爲GPT磁盤便可，不要直接對磁盤進行分區操做，咱們須要再經過S2D包上一層才能交付給羣集

天津站點建立S2D羣集

New-Cluster -Name TJCluster -Node 16Server3,16Server4  -StaticAddress 10.0.0.20 –NoStorage

注：執行前確保節點已符合S2D需求，生產環境建議執行羣集驗證

開啓羣集S2D功能

Enable-ClusterS2D -CacheState disabled -Autoconfig 0 -SkipEligibilityChecks

若是你是在vmware workstation上面模擬這個實驗，你會發現開啓S2D的過程會始終卡在這裏，沒辦法進行下去，查看日誌發現S2D一直沒辦法識別磁盤

可是究竟是什麼緣由識別不了磁盤呢，vmware虛擬上來的磁盤是SAS總線的，也符合S2D的需求，通過一番研究後，老王找到了緣由，原來經過vmware虛擬出來的虛擬機沒有Serial Number，而開啓S2D會去找磁盤的這個數字，找不到，因此磁盤沒辦法被聲明爲S2D可用

經過在vmware虛擬機vmx配置文件關機添加參數便可

disk.EnableUUID="true"

添加完成後開機能夠看到Serial Number已經能夠正常顯示

配置各節點磁盤MediaType標籤

再次開啓S2D，順利經過，如今咱們能夠在vmware workstation上面模擬S2D實驗！

建立羣集存儲池

新建虛擬磁盤（存儲空間），這裏的虛擬磁盤交付出來就是羣集磁盤，因此咱們要和北京羣集的羣集磁盤大小確保一致，以便實現存儲複製

數據磁盤

日誌磁盤

天津站點配置羣集角色

在天津站點任意節點上授予到北京站點羣集的權限

Grant-SRAccess -ComputerName 16server3 -Cluster BJcluster  

在北京站點任意節點上授予到天津站點羣集的權限

Grant-SRAccess -ComputerName 16server1 -Cluster TJcluster  

建立羣集對羣集複製關係

New-SRPartnership -SourceComputerName bjcluster -SourceRGName rg01 -SourceVolumeName C:\ClusterStorage\Volume1 -SourceLogVolumeName R: -DestinationComputerName tjcluster -DestinationRGName rg02 -DestinationVolumeName C:\ClusterStorage\Volume1 -DestinationLogVolumeName R:

建立完成複製關係後，當前天津羣集的數據磁盤會變成 聯機(無訪問權) ，到這裏你們須要有這個意識，對於跨羣集來講，咱們如今把複製的邊界跨越了羣集，所以每一個複製組運做過程當中都會有一個羣集的數據磁盤是待命狀態，對於待命羣集，複製組內磁盤不能被使用，若是部署多個跨羣集複製組，能夠實現羣集應用互爲待命。

當前文件服務器羣集角色在北京站點提供服務，全部者節點爲16server1，已經有一些數據文件

直接斷電16server1，SOFS自動透明故障轉移至同站點內16server2

存儲複製繼續在同站點16server2進行，由此你們能夠看出，存儲複製和Hyper-V複製同樣，在羣集內有一個複製協調引擎，經過羣集名稱和外面的羣集進行復制，而後再協調內部由那個節點進行復制，一旦某個羣集節點宕機，自動協調另一個節點參與複製，區別在於Hyper-V複製在羣集有顯式的羣集角色，存儲複製的羣集角色是隱藏的

接下來模擬北京站點所有發生災難，16server1,16server2所有斷電，這時來到天津站點的羣集能夠看到，當前羣集磁盤處於脫機狀態，並不會自動完成跨羣集的故障轉移

手動強制跨羣集故障轉移

Set-SRPartnership -NewSourceComputerName tjcluster -SourceRGName rg02 -DestinationComputerName bjcluster -DestinationRGName rg01 -force

執行完成後當前數據在天津站點可讀

打開數據磁盤CSV能夠看到北京站點的數據被完整複製過來

實際測試跨服務器故障轉移後，共享文件夾權限並不會被自動遷移，默認狀況下會是未共享狀態，自行手動共享便可，猜測是跨服務器轉移磁盤的緣故，若是權限較多，你們能夠嘗試下配合權限遷移可否映射過來，不過事實上，對於這種跨服務器故障轉移的負載，實際生產環境仍是建議以SQL文件，VHDX，VHD文件爲主，發生跨羣集故障轉移後直接在新羣集從新啓動數據庫或虛擬機角色。

如今咱們完成了跨羣集的災難恢復，若是採用網絡分離的架構，把天津站點的訪問公開給北京用戶便可，正如咱們以前所說，轉移後會使用新的名稱進行訪問

即使這時天津站點再壞掉一個節點，SOFS也能夠透明故障轉移至僅存的節點存活，前提是仲裁配置得當

僅剩下一個最後節點時，存儲複製會處於暫停狀態，等待其它節點恢復

等待一段時間後，各站點服務器陸續修復完成上線，存儲複製自動恢復正常連續複製，當前主複製站點爲天津站點

若是但願此時繼續由北京站點恢復爲主站點，能夠執行反轉複製，把天津站點內容複製回北京站點，主備關係恢復

經過三篇對於Windows Server 2016存儲複製功能的介紹，相信你們對於這項技術都有了瞭解，很高興的一點是聽聞有的朋友看了個人博客已經開始在實際環境使用了，存儲複製技術是2016存儲的一項主要進步，原生的塊級別複製，若是節點不多，不想維護羣集的話，可使用單機對單機場景實現災難恢復，若是但願羣集得到最低的RTO/RPO，可使用延伸羣集功能，得到自動化的災難恢復，若是但願規劃更爲複雜的架構，針對於不一樣站點但願使用不一樣網絡和存儲架構，實現跨羣集跨站點級別的災難恢復，如今也能夠實現，最終但願你們看了文章後都能有本身的思考