- 在vSAN 6.7之前,vSAN就已支持Microsoft SQL Always-on Availability Groups (AAG)、Microsoft Exchange Database Availability Groups (DAG),及Oracle Real Application Clusters (RAC)了。不過需要說明的是,SQL Server AAG和Exchange DAG並不是通過共享磁碟來支持的,而是藉助應用層來實現數據的冗餘。而來到6.7版後此功能大幅提升,已可以透過ISCSI LUN共享磁碟來支援WSFC。
圖片來源 : https://blog.csdn.net/Urh3t1/article/details/79985804
- 此篇LAB採用vSAN 6.7 U1版本,並透過iscsi target服務提供File Server掛載Datastore,且採用FTM=1機制來保護ISCSI LUN。另外FileSrv都採用MPIO方式連接,來避免單點網路路徑的故障。
電腦名稱
|
Heart Beat IP
|
內網服務IP
|
FileSrv01
|
192.168.10.1
|
172.16.0.101
|
172.16.0.102
|
||
172.16.0.103
|
||
FileSrv02
|
192.168.10.2
|
172.16.0.104
|
172.16.0.105
|
||
172.16.0.106
|
||
容錯管理員叢集名稱
|
容錯叢集管理IP位址
|
|
File_vSAN_Service
|
172.16.0.78
|
|
檔案共用叢集服務名稱
|
叢集IP位址
|
|
File_vSAN_Share
|
172.16.0.80
|
|
ESXI主機名稱
|
Manage IP
|
ISCSI Target IP
|
ESXI01
|
172.16.0.1
|
172.16.0.190
|
ESXI02
|
172.16.0.2
|
172.16.0.191
|
ESXI03
|
172.16.0.3
|
172.16.0.192
|
1. 先將各3台ESXI主機新增vmk介面卡(ISCSI)
2. 啟用vSAN ISCSI Target服務
3. 設定iscsi目標及Datastore Policy
4. 我這邊是建立2個LUN (目前ISCSI LUN是由ESXI03主機上運作)
5. 於2台Filesrv上ISCSI啟動器新增搜尋入口 (三台Host的ISCSI Target ip)
6. 至目標啟用多重路徑,並進入進階設定
7. 設定啟動器與對應的目標IP
8. 將172.16.0.101~172.16.0.103這三個IP設定至172.16.0.190上
9. 接著開始設定故障容錯移轉功能,先執行驗證設定精靈是否可以成功
10. 開始建立叢集管理員,輸入叢集管理名稱及IP位址
11. 建立完成
12. 設定角色
13. 下一步
14. 輸入叢集角色服務名稱及IP位址
15. 選擇存放檔案伺服器的磁碟
16. 檔案伺服器叢集角色服務已建立完成
17. 來模擬FileSrv01系統當機,檔案伺服器服務會由FileSrv02接手繼續運作
18. 那麼若ESXI03(172.16.0.3)主機故障是否會導致影響File Server運作呢?因為目前這2個LUN目前都是在ESXI03主機上運作的,然而vSAN是採用RAID1來存放數據,即使在ISCSI運作的某一台ESXI故障,也是有其它ESXI的主機來讀取這些數據的,那麼就來驗證一下吧
19. 測試將ESXI03關機,這時ISCSI LUN已轉向172.16.0.2上運作了,且元件已不符合vSAN Default Policy
20. vSAN採用RAID1保護數據,就算在ISCSI運作的主機故障,也會有其它主機接手運作,且同時也會有2個相同的元件分佈在不同的ESXI主機上,這次的LAB僅影響到見證的元件
21. 那麼再模擬若FileSrv01與ESXI01(172.16.0.1)主機之間的網路中斷會如何呢??
22. FileSrv01上的NIC1網卡發生故障,也可以透過其它探索的目標IP,與其它可用的連結路徑持續運作
◎ 結論 : 到vSAN 6.7 U1版後,支援的層次相對也越來越多元化了,聽說未來還會導入支援RDM的功能,這倒是蠻讓人期待的
沒有留言:
張貼留言