- Windows Server 2008 R2產品已於2020年1月14號之後就停止安全性更新了，我想有部分的公司也開始逐漸規劃升級廠內的伺服器版本，而最近有人表示想將現有的Windows Server 2008 R2升級至Windows Server 2012 R2，主要遷移的環境有Windows Server Failover Cluster(File Server Service)，以及檔案伺服器資源管理的配置，再加上底層的Storage的資料也要一併遷移過去，因為連DataStore內的資料都要遷移的話，就會變得有點棘手了呢。 (此篇測試花費我了整整1個多月的時間，據了解在2020過年的時候，對方就已經在評估升級的打算，直到4月底朋友那邊才叫我看能不能先幫忙自建環境並測試)
- 對方現有的環境是採用vSphere 6.5 U2版本，而WSFC虛擬機器是透過Windows ISCSI Initiator與Storage連接，聽說對方是有購入新的Storage及Rack Server，並從原IP SAN換成FC SAN的架構，且也想趁這次連同將虛擬機器上的Windows Server(WSFC)版本也一併Upgrade。(過程中我是有建議朋友看他們新買的Rack Server是否要安裝ESXI 6.7以上的版本，畢竟vSphere 6.7以上的版本可以採用Virtual Volume提供給WSFC服務使用，且比起Physical RDM來得更有優勢及易管理，但是聽說對方目前還是比較希望可以與現有舊Rack Server保持在相同的版本)
- 參考VMware環境下WSFC Solution的配置，而在vSphere 6.5版本上就必須採用物理RDM模式。
相關資訊網址參考 :
- 之前有聽對方問了一個非常好的問題，對方表示希望可以跟現有的舊IP SAN一樣，透過虛擬機器上連接的設備及Windows Multipath I/O(MPIO)功能來直接掛接Storage上的LUN，藉此達到符合WSFC的需求，但是這方法會有一些缺點，就是虛擬機器無法在線vMotion至其它ESXI主機上，所以只要ESXI面臨維護就需將虛擬機器關機，且當位於該WSFC上的ESXI發生故障了，也會導致無法透過vSphere HA移轉至其它的ESXI主機。另外目前環境是採用2張Dual Port Fibre Channel HBA(16G)連接現有的vSphere環境，據朋友了解對方是想再加裝HBA，讓WSFC虛擬機器不會與其它服務相互佔用頻寬，不過我個人是認為沒必要，因目前頻寬有16G且還有Multipath加持(共4個PORT)，已足以可以應付整體虛擬機器上的Loading了
- 實際測試環境 :
1. 於各2台Windows Server 2012上安裝檔案伺服器及檔案資源管理服務
2. 新增Failover Cluster功能
3. 於2台檔案伺服器配置網路卡的順序
4. Heartbeat網路介面卡上取消勾選登錄DNS位址
5. 至WINS停用NetBIOS服務
6. Storage配置LUN並指派給各台ESXI，就可以進入ESXI管理介面，至Storage Device查看是否已連接LUN
7. 編輯設定第一台2012檔案伺服器，新增SCSI控制器
8. 選擇VMware半虛擬化，SCSI匯流排共用為實體
9. 接著新增RDM磁碟
10. 選擇目標LUN
11. 虛擬裝置節點指派給新的SCSI控制器
12. 接著編輯第二台WSFC虛擬機器，新增SCSI控制器，一樣是選擇VMware半虛擬化及匯流排共用設定為實體
13. 新增現有的硬碟
14. 於Share DataStore內的第一台WSFC虛擬機器資料夾內，選擇先前新增RDM硬碟所產生的VMDK檔
15. 不要忘記虛擬裝置節點需選擇新增的SCSI控制器
16. 我們回到WSFC 2012主節點上，就可以看到RDM所掛載的磁碟
17. 先來驗證一下現在是否已符合配置Windows Server容錯移轉的條件
18. 驗證沒問題的話，就可以開始建立叢集
19. 建立完成，由於我目前還沒有配置Witness，所以這邊才會跳出Alert
20. 配置網路通訊
21. 由於叢集內還尚未加入任何的可用磁碟，所以故先新增
22. 選擇要加入的磁碟
23. 加入磁碟完成
24. 接著設定Witness
25. 選取仲裁見證並下一步
26. 因依配合對方環境的需求，所以我這邊選擇設定檔案共用見證
27. 選擇Witness共享資料夾並下一步
28. 仲裁設定完成
29. 在WSFC_2008主節點上透過網路磁碟掛載WSFC_2012的叢集磁碟槽 (這邊強烈建議掛載網路磁碟的網路IP最好是採用Heartbeat網路，避免在做同步複製時，去佔用到廠內Public網路頻寬的流量)
30. 這邊我是利用第三方複製同步程式，將舊File Server裡面的資料複製到WSFC_2012虛擬機器叢集磁碟內 (當然還有其它的Solution方式)
31. 這邊需要特別注意的就是File Server權限的配置，各部門底下都會有位於該部門人員帳號的個人資料夾以及同部門的公用區
32. 所有部門及公司資料區的資料夾皆有設定共用
33. 在各部門(工程部)的權限並無繼承至前面的資料夾權限，且僅只有CW-L群組的人才可以進去
34. 在工程部底下的個人資料夾僅只有該同仁(CW01)可以編輯，且並無繼承至前面的工程部資料夾權限
35. 各部門(工程部)的公用區一樣是無繼承至前面的資料夾權限(工程部)，僅只有工程部公用區的群組權限才可以編輯
36. 公司資料區有共享且無繼承前面的權限，廠內的同仁都可以唯讀該資料夾
37. 在公司資料區底下的多部門開會紀錄資料夾，無繼承至前面(公司資料區)的權限，且僅有Public-多部門開會紀錄群組可以編輯
38. 在公司資料區內的資料暫存資料夾，一樣是沒有繼承至前面(公司資料區)的權限，而廠內所有的同仁都是可以編輯的
39. 在檔案伺服器資源管理員可以看到針對不同的部門來分派各自的配額空間
40. 而在資料暫存的資料夾有特別封鎖音訊及影片檔
41. 那麼到這邊就開始進行複製的作業 (選擇同步的複製)
42. 在同步複製過程中，我還有測試開啟部分的檔案做編輯 (因第一次同步會比較久，所以通常都會利用一般的時段去做。而在一般時段都會有user編輯或是唯讀檔案，所以這邊我還是會來模擬實際整體的現狀)
43. 由於有些檔案還有正在開啟中，所以才會有該錯誤訊息
44. 複製完成後，我們先檢查步驟42中所開啟的檔案是否也都有跟著同步過去 (另外實際測試開啟檔案也正常)
45. 接著準備複製2008 R2檔案伺服器資源管理(FSRM)配置至2012 R2，首先需停止檔案伺服器資源管理的相關Service
net stop srmsvc
net stop srmreports
net stop quota
net stop datascrn
46. 輸入指令 Robocopy "E:\System Volume Information\SRM" "備份路徑" /ZB /R:3 /W:5 (E槽是檔案伺服器的路徑)
47. 至WSFC_2012主節點上先停止檔案伺服器管理資源(FSRM)服務
48. 複製WSFC_2008_FS01主節點上的檔案伺服器資源管理(FSRM)配置的檔案到WSFC_2012_FS01上 (指令可按照步驟46)
49. 於WSFC_2012_FS01上重新啟動FSRM相關的服務
50. 這邊我們就可以看到FSRM配額的設定已順利複製過去
51. 但是在配額範本中並沒有跟著複製過去
52. 至WSFC_2008_FS01將FSRM的配額配置範本匯出XML
針對FSRM指令相關資訊可參考網址：
輸入指令 Dirquota.exe template export /file:路徑名稱.xml
53. 回到WSFC_2012_FS01匯入配額範本設置xml即可
輸入指令 Dirquota.exe template import /file:路徑名稱.xml
54. 開啟FSRM即可看到已匯入的配額範本 (這邊我是建議先匯入配額範本再進行複製配額的設定)
55. 接著來看檔案檢測的部分，可發現路徑配置有複製過去，但是檔案群組卻是空白的，我是有嘗試使用Filescrn.exe匯出XML並匯入還是一樣沒有，看來也只能一個一個手動去設定了 (不過還好對方實際的環境所配置的路徑並不多)
56. 那麼我們準備遷移WSFC服務
57. 選擇來源WSFC_2008_MGT叢集
58. 選擇要遷移的服務
59. 由於是採用新的DataStore，所以這邊故選擇新的存放裝置
60. 選擇可用磁碟
61. 下一步
62. 完成
63. 此時可發現目前WSFC 2012檔案伺服器服務是停止的，所以我們需要做切換的動作，且會有短暫的停機 (由於考慮到資料同步的一致性，切換前請務必再做一次同步複製的作業，另外強烈建議是利用停機的時段再做WSFC服務的切換)
64. 先將WSFC_2008檔案伺服器的服務關閉
65. 於WSFC_2012啟動角色服務
66. 當WSFC服務切換完成後，Client也不需重新登出再登入即可正常進入網路磁碟槽
67. 那麼我們先來Check資料夾的權限，在步驟32對照，所有部門及公司資料區的資料夾都有設為共用
68. 在步驟33權限對照，各部門(工程部)資料夾並沒有繼承前面的權限，且僅只有CW-L群組可以進入
69. 依步驟34權限對照，各部門(工程部)底下的個人資料夾僅只有該同仁可以編輯及進入，且一樣是無繼承至前面(工程部)資料夾的權限
70. 依步驟35權限對照，各部門(工程部)底下的部門公用區，一樣是無繼承至前面(工程部)資料夾的權限，且只有該部門(工程部)公用區才可以編輯及進入
71. 在步驟36權限對照，公司資料區無繼承至前面的權限，廠內所有同仁都可以唯讀該資料夾
72. 在步驟37權限對照，公司資料區底下的多部門開會紀錄資料夾無繼承至前面(公司資料區)權限，且僅只有多部門開會紀錄群組才可編輯
73. 在步驟38權限對照，公司資料區內的資料暫存一樣是沒有繼承至前面(公司資料區)權限，廠內所有的同仁都是可以編輯的
74. 若資料夾權限都沒問題的話，接著我們來檢查檔案伺服器資源管理員的配置，首先測試在工程部丟入超過1G以上的檔案，此時則跳出沒有足夠的空間
75. 而在資料暫存底下的每個資料夾都僅有200M的空間限制
76. 嘗試於資料暫存內新增一個資料夾，此時可發現到資料暫存範本將會自動產生配額的設置
77. 測試在資料暫存放入影片，會因開啟檔案檢測功能而遭到限制 (別忘記還要再將WSFC主節點服務轉到WSFC_2012_FS02並測試FSRM是否也是可正常運作的唷)
78. 我們來看Windows Server 2012版本之後才有的(重複壓縮與刪除功能)功能，對方是表示既然已經升級至2012版本當然希望可以使用該功能，首先於2台WSFC虛擬機器安裝重複壓縮與刪除功能
Microsoft針對重複壓縮與刪除說明參考網址：
79. 選擇欲Deduplication的磁碟並設定啟用重複壓縮與刪除功能
80. 啟用重複資料刪除功能，並設定執行最佳化的時間 (管理員可自行決定重複檔案存在的天數來進行重覆與刪除的作業)
81. 依使用者選擇要執行的時段即可
82. 我們先來看在未執行重複壓縮與刪除作業前，目前E槽已佔用6.92G，而資料夾部分則有12個資料夾及1419個檔案
83. 我們可透過PowerShell指令來手動執行Deduplication的作業
start-dedupjob –type optimization –volume E: (手動執行Deduplication作業)
get-dedupjob (查看執行dedulication的作業進度)
get-dedupstatus (查看執行deduplication的壓縮與刪除的狀態)
get-dedupstatus E: | fl (當然也可以用該指令查看Deduplication詳細狀態)
84. 當然也可透過GUI來查看重複壓縮與刪除的內容
85. 與(步驟82)未執行Deduplication作業前的空間相比，現在E槽總佔空間僅1.47G，而在資料夾的已使用的空間大小是不會變的，但是對磁碟大小僅只有120KB (所以在RDM磁碟也是沒問題的)
86. 在步驟78提供的參考網址內文提到Deduplication在操作性上有幾個重要的事項要留意，這邊就特別抓出來說明，在WSFC環境下看起來是沒啥問題的，而FSRM可能就要稍微留意一下，若是在磁碟根目錄配置硬配額的話可能會導致Deduplication作業失敗
87. 而對方FSRM環境只有針對底下各部門的資料夾設置硬配額，所以我們就在這邊來實際測試看看在Deduplication作業下是否會有所影響，在圖中範例所示，目前工程部有配置1G的硬配額
88. 先複製6個類似的檔案進去，目前尚未執行Deduplication作業，這時工程部資料夾內磁碟大小已佔用了229M，而在磁碟內容共佔用1.72G
89. 當完成執行Deduplication作業後，工程部資料夾磁碟大小僅佔用20KB，而磁碟內容空間佔用了1.53G
90. 我們再將較大的檔案丟入工程部，此時會跳出沒有足夠的空間訊息，在此測試環境下，Deduplication及FSRM皆是可以正常運作的
91. 在Windows Server 2012 R2中，重複資料刪除工作管線會每個磁碟區使用一個執行緒與I/O佇列。若要確保最佳化工作不會因為落後，而導致磁碟區的整體節省率降低，必須將大型資料集分割成較小的磁碟區。適當的磁碟區大小取決於該磁碟區的預期變換。在高變換磁碟區的最大值約是6~7 TB，而低變換磁碟區的大約是9~10 TB。據了解對方File Server實際總共約有11TB的資料量，所以我是會比較建議對方存放一般使用者的資料夾是可以不用做Deduplication，只要針對機台的生產程式所上傳的文件就好，因光是機台所產生的檔案總共有6TB多，已剛好達到高變換磁碟的理想值，且裡面的檔案大都是txt及map..等，所以Deduplication起來一定會比一般使用者存放的資料來得更有效率，只是這樣就需要把生產機台的檔案與一般使用者的檔案各放至不同的磁碟(2個Physical RDM)，或是設定重複刪除把一般使用者存放的資料夾排除掉，總之最後就依對方來決定哪種Solution
相關資訊參考網址：
92. Deduplication在Memory上也有一些要求，依以下圖示所示，若對方volume為6TB的話，當在優化作業的情況下，預設會利用系統總記憶體的50%比例來做Deduplication作業，所以建議記憶體至少要24G以上（預留12G給Deduplication作業使用），當然也可以透過Powershell指令來變更使用記憶體%數的比例
相關資訊參考網址：
93. 另外還要再特別注意的是不能在執行Deduplication的磁碟上採用Robocopy的方式複製檔案，否則可能將會造成檔案意外性的損毀。在搜尋的部分也會因Deduplication關係而影響到索引內容的功能
94. 微軟這邊有針對Windows Server 2012 R2版本的Deduplication可能會造成部分的問題進而發佈Hotfix來修正(KB2919355)
相關資訊參考網址：
95. 但是在安裝KB2919355則出現無法安裝的訊息
96. 需先安裝KB2919442 (安裝完成後不用重開機)
97. 接著就可以安裝KB2919355，之後再重開機，並測試也是沒甚麼問題 (此KB檔案還蠻大的，需要耐心等待)
98. 接續測試Windows Server Failover Cluster容錯移轉是否正常，首先測試將主節點Public網路中斷，這時已Failover至第二節點上
99. 再測試將WSFC_2012_FS02虛擬機器關機，可發現服務順利Failover至WSFC_2012_FS01節點上
100. 進行到這邊，Windows Server的部分終於告一個段落了，緊接著我們準備測試vSphere進階的功能吧(不停機在線Expand RDM空間、vSphere HA、虛擬機器在線vMotion)。那麼開始進行在線擴充RDM空間，依圖示所示，目前RDM磁碟空間為20G
擴充RDM磁碟Solution資訊參考網址：
101. 當Storage內LUN擴充空間完成後，於ESXI上的Storage Device Rescan就可發現已擴大後的磁碟
102. 接著到WSFC_2012_FS01主節點上的磁碟管理可發現容量已為30G，並利用延伸功能將磁碟區空間擴大即可
103. 在有WSFC虛擬機的環境下，要確保觸發vSphere HA功能時，避免將這2台WSFC虛擬機都位於在同一台ESXI主機上，所以我們需要特別建立規則才行
104. 那麼我們將位於WSFC_2012_FS01上的ESXI主機關機測試看看
105. 此時可注意到WSFC_2012_FS01虛擬機器已Migrate至ESXI(10.0.0.73)主機上並持續運作
106. 我們再來測試在線vMotion，將WSFC_2012_FS01從ESXI(10.0.0.73)遷移至ESXI(10.0.0.71)主機上也沒問題
107. 最後是進行測試虛擬機器的備份，由於環境有Deduplication，所以在備份軟體的部分也必須經過測試，尤其是在還原時，一定要確保資料的完整性。而對方現在備份是採用Acronis Backup 12.5軟體，所以我這邊就來實際測試看看吧。在官方說明可以看到Acronis有針對Physical RDM或是啟用端ISCSI的磁碟來透過代理程式進行備份的
108. 備份完成
109. 若是從Acronis主控台上將備份檔裡面的特定檔進行還原的話，會發現只要是經過Deduplication的檔案下載下來都是空的 (另外我有嘗試將備份檔還原至整台新的虛擬機器是可以讀取經過Deduplication的檔案)
結論 : 根據對方的說法，他們之前Windows Server 2008 R2是僅備份系統，而ISCSI掛載的Disk內的資料是透過複製軟體定時排程將檔案同步至NAS上，避免同仁誤殺資料或是中勒索病毒..等情況時即可復原，不過他們日後升級Windows Server 2012 R2上也只能先暫時用先前的備份做法，當然此做法一直存在著很大的風險，因為要是新的Storage這邊出現問題了，光是還原時就會花費很長的時間。而現在對方已有兩座Storage，我相信等到他們順利將File Server服務的系統順利升級至2012版本後，應該就會針對WSFC進行評估災難異地備援的解決方案。
沒有留言:
張貼留言