透過本文的深入剖析與實作，將能夠理解最新發布的vSAN 9.0版本中有哪些亮眼的特色功能，而透過實作vSAN 9 DP快照保護機制，將可以有效幫助企業組織保護重要的VM虛擬主機和營運服務，在災難事件發生時快速回復還原先良好的運作狀態。
最新發布的vSAN 9超融合運作架構，隨著最新VMware Cloud Foundation（VCF） 9.0一起推出。在vSAN 9版本中，主要的Express Storage Architecture（ESA）運作架構有許多亮眼特色功能，其中針對ESA架構最佳化的「全域重複資料刪除」（Global Deduplication）機制，如圖1所示，無論是執行效率或節省的儲存空間，與過往Original Storage Architecture（OSA）有非常大的不同。
圖1 vSAN ESA超融合全域重複資料刪除示意圖。 （圖片來源：Global Deduplication in vSAN ESA for VMware Cloud Foundation 9.0）
認識vSAN 9 Global Protection運作架構
由於vSAN ESA全新超融合架構可以有效跨越過去vSAN OSA的技術限制，所以能夠提供更高效能和更多儲存空間節省的目標。
首先，最大的差異是「重複資料刪除網域」（Deduplication Domain），在舊有vSAN OSA架構中，重複資料刪除網域被限制在vSAN叢集內單台vSAN節點主機的「磁碟群組」（Disk Group）當中，這會降低重複資料刪除的有效性。舉例來說，當相同的資料區塊位於不同的磁碟群組時，就無法刪除重複資料，這也是阻礙vSAN OSA重複資料刪除率的主要原因之一。
新式的vSAN ESA運作架構，重複資料刪除網域則是以整個vSAN叢集為單位，因此在vSAN叢集中只要出現相同的資料區塊，便能夠執行重複資料刪除作業，同時採用4KB資料顆粒度更小的設計，更容易讓系統明顯提升出到重複資料區塊的數量，進而提升重複資料刪除的效率和節省的儲存空間。
此外，在重複資料刪除執行效能方面，兩者也有很大的不同，在舊有vSAN OSA架構中，會將資料暫存至容量層級（Capacity Tier）當中，才觸發執行重複資料刪除作業程序，雖然這樣的行為是發生在資料寫入確認，傳送給客體作業系統之後，但此舉會造成資料移動至容量層級的速度變慢，同時讓緩衝區更容易被填滿，當採用的儲存裝置反應速度又較慢時，便會發生vSAN壅塞的情況，導致VM虛擬主機延遲反應的情況。
新式的vSAN ESA運作架構中，重複資料刪除不會發生在熱資料寫入路徑當中，確保重複資料刪除程序不會浪費資源在最新寫入的資料中，這些資料通常會在不久之後便被刪除或覆寫，同時搭配智慧化處理的方式來執行這些工作任務，動態確認當CPU週期空閒時，才會執行重複資料刪除的工作任務，針對運作中的VM虛擬主機干擾程度降至最低，並且透過中繼資料（Metadata）對應機制，讓系統能有效識別並優先刪除冷資料，然後再刪除較熱的資料，確保重複資料刪除處理效率。
當vSAN ESA叢集啟用重複資料刪除功能時，叢集將會建立兩個主要特殊化物件，如下所示：
‧重複資料刪除中繼資料物件（Dedup Metadata Object）：此物件會為叢集中儲存的每個4KB資料區塊，維護一個Hash Entry用來協助識別相同資料區塊。
‧重複資料刪除資料物件（Dedup Data Object）：此物件會將儲存重複資料刪除的4KB資料區塊，以專用物件的方式儲存重複資料刪除的資料，避免特定VM虛擬主機發生I/O熱點的情況。
原則上，vSAN ESA架構中的重複資料刪除技術，為延後處理程序機制，當系統發現CPU週期處於閒置時，便會執行重複資料刪除的工作程序，並且依照下列順序進行處理，如圖2所示：
圖2 vSAN ESA運作架構重複資料刪除處理程序示意圖。 （圖片來源：Global Deduplication in vSAN ESA for VMware Cloud Foundation 9.0）
1. vSAN叢集讀取離散的4KB資料區塊，並產生要儲存在重複資料刪除中繼資料物件內，進行安全加密的雜湊內容。
2. vSAN叢集將會在重複資料刪除中繼資料內，尋找符合的Hash Entry，倘若探索到與重複資料刪除物件內的資料相符且一致時，便會使用中繼資料指標更新資料區塊並回收儲存空間。
3. 如果在重複資料刪除物件內並沒有找到符合的Hash Entry時，它會將目前資料和原始資料同時遷移到重複資料刪除物件中，使用中繼資料指標更新資料區塊並回收儲存空間。
4. 如果完全找不到符合的Hash Entry時，則會讓資料保持原樣，而Hash Entry將會在中繼資料物件內建立，並具有資料所在的反向指標，以便在後續識別重複Hash Entry時，可以如上所述刪除重複資料。
實戰vSAN Data Protection 保護VM
事實上，vSAN Data Protection（DP）資料保護機制是從vSAN 8.0 Update3版本開始首次導入的新特色功能，能夠有效幫忙企業和組織在地端資料中心內vSAN叢集中，為vSAN儲存資源建立「原生快照」（Native Snapshots），同時完整擷取VM虛擬主機的運作狀態。當受保護的VM虛擬主機發生故障損壞事件，或是遭遇勒索軟體攻擊時，便能透過vSAN DP資料保護機制，將受保護的VM虛擬主機快速還原，回到先前良好的運作狀態繼續運作，如圖3所示。
圖3 vSAN Data Protection（DP）資料保護機制運作架構示意圖。 （圖片來源：VMware vSAN - Getting Started and Advanced Topics）
部署vSAN Data Protection Appliance
在實作vSAN DP資料保護機制前，必須先登入官方網站中點選「vSAN > Drivers and Tools」項目，下載vSAN Data Protection Appliance的OVA部署檔案。舉例來說，本文實作下載為vSAN Data Protection 9.0.4版本，有關部署的詳細資訊，請參考官方KB-388526 | Deploy vSAN Snapshot Service appliance for vSAN Data Protection知識文件庫內容。
值得注意的是，過去在vSAN 8.0 Update3版本中，vSAN DP功能是由vSAN Snapmanager Appliance負責。而現在最新的vSAN 9版本中，官方將vSAN Data Protection、vSphere Replication和VMware Live Recovery等服務整合進單一Appliance當中，同時vSAN DP已經與VMware Live Recovery服務整合，這表示可以達成在兩地之間整合vSAN-to-vSAN層級的備援機制。
此外，在部署vSAN DP Appliance過程中，如果系統需要匯入vCenter Server Certificate時，必須預先下載vCenter Server Certificate，如果管理人員不知道如何下載vCenter Server Certificate的話，請參考VMware KB-330833知識庫文章了解詳細資訊。
當順利部署vSAN DP Appliance後，便會在vCenter管理介面中的「Configure > vSAN」項目內自動出現「Data Protection」項目，以便進行後續組態設定vSAN DP資料保護機制。
新增Protection Groups
在vSAN DP運作架構中，便是透過「Protection Groups」機制，將一台或多台VM虛擬主機加入至同一個Protection Groups當中，然後針對這些受保護的VM虛擬主機，定義排程快照並管理快照。
在vCenter管理介面中，依序點選「vSAN9-ESA-Cluster > Configure > vSAN > Data Protection」項目，在預設的Summary頁面中，可以看到vSAN DP的簡要資訊和vSAN快照使用空間情況，如圖4所示。
圖4 查看vSAN Data Protection簡要資訊和快照儲存空間使用率頁面。
值得注意的是，在系統提醒資訊中，說明當vSAN Datastore儲存資源使用量「超過70%」門檻值後，系統便會停止執行vSAN DP快照的自動化排程作業，避免vSAN DP快照影響vSAN儲存資源的正常運作。
依序點選「Protection Groups > Create Protection Group」項目，將會彈出新增Protection Group精靈對話視窗，在1. General步驟中，於Protection group name欄位內鍵入Protection Group名稱，本文實作為「EC Services PG」，在Protection type下拉選單中，選擇至本文實作環境「Local protection」，後續如果整合VMware Live Recovery服務時，便可以選擇其他選項，在Membership選項中，選擇適合運作環境的選項，本文選擇採用「Dynamic VM name patterns」，以便稍後加入VM虛擬主機時，在名稱方面可以使用「*」萬用字元，一次性快速地加入所有符合條件的受保護VM虛擬主機，如圖5所示。
圖5 鍵入Protection Group名稱和保護方式及選擇加入VM虛擬主機選項。
在2. Add VM name patterns步驟中，於VM name pattern欄位內鍵入準備加入此Protection Group的VM虛擬主機名稱「EC*」後按下〔Add〕鈕，系統便將匹配VM虛擬主機中名稱開頭為「EC」並符合規則字元的VM虛擬主機列出，系統總共找到3個符合的VM虛擬主機並顯示於下方，如圖6所示，除了支援使用「*」萬用字元外，也支援使用「?」，以便匹配一個符合的任意字元。
圖6 透過萬用字元一次加入多台VM虛擬主機至受保護群組中。
在3. Add local snapshot schedules步驟中，系統預設值為每天自動建立快照並保留1週，管理人員可以依照需求自行調整快照的排程時間，舉例來說，本文實作調整為「每隔8小時」建立1份快照，並且保留最近「3個月」的快照檔案，如圖7所示。當然，管理人員若需要多個快照排程時，只要點選下方的「ADD SCHEDULE」，即可新增另一個快照排程時間。
圖7 組態設定vSAN DP快照的排程時間和保留期間。
在4. Review步驟中，再次檢視Protection Group組態設定，若內容無誤即可按下〔Create〕鈕。值得注意的是，建立Protection Group後，系統並不會立即建立一份快照，而是依照剛才組態設定的排程時間才會進行快照，倘若希望立即保護相關VM虛擬主機，可以先執行手動快照。
新增完成後，在Protection Group頁面中，可以看到剛才新增的Protection Group資訊，下列為每個欄位的簡要說明，如圖8所示：
圖8 查看新增完成的Protection Group簡要資訊。
‧Protection group：顯示目前系統中已經新增完成的Protection Group，點選名稱後即可查看詳細資訊。
‧Immutability mode：顯示不可變模式狀態，目前為Disabled表示處於停用狀態。後續實作中，也將建立啟用不可變模式的Protection Group，管理人員便能理解啟用和停用不可變模式兩者之間的差異在哪裡。
‧Status：顯示此Protection Group的運作狀態，目前為Active的活動狀態，表示系統將會依據組態設定的排程時間，自動為受保護的VM虛擬主機執行建立vSAN DP快照作業。
‧VMs：顯示目前受到Protection Group快照機制保護的VM虛擬主機數量。
‧Peer cluster：整合VMware Live Recovery機制後，便會顯示複寫目的端的vSAN叢集名稱。
‧Snapshots：顯示快照份數，目前為0份，必須等到排程時間後，系統才會自動建立，或是管理人員手動建立快照即可。
‧Latest snapshot：顯示最新建立快照的時間點。
‧Oldest snapshot：顯示最初開始建立快照的時間點。
手動建立vSAN DP快照
事實上，當Protection Group新增完成後，系統將會根據排程時間自動建立快照，以本文實作環境來說，必須等待8小時後系統才會自動執行vSAN DP快照的動作，如果希望立即保護相關VM虛擬主機，可以在排程時間執行之前，手動執行建立vSAN DP快照的動作。
在Protection Groups頁面中，點選希望建立vSAN DP快照的Protection Group，點選左方三個點圖示，在顯示視窗中選擇「Take local snapshot」項目，系統將會彈出快照作業視窗。
在Take local snapshot視窗中，系統預設會自動產生快照名稱並加上日期和時間，當然也可以在Snapshot name欄位內變更成符合企業及組織命名規則的快照名稱。
在Retention選項部分，依據運作環境需求，選擇適合的選項，即可立即進行快照作業，按下〔Take Snapshot〕鈕，系統便會立即執行vSAN DP快照的工作任務，如圖9所示。
圖9 手動為指定的Protection Group建立vSAN DP快照。
順利建立vSAN DP快照後，回到Protection Groups頁面，便可以看到Snapshots欄位已經從剛才的「0 份」和警告圖示轉變為「1份」快照，並且由於是第1份快照，所以最新與最舊快照時間點為一致的，如圖10所示。
圖10 手動建立vSAN DP快照後，查看快照份數和快照建立時間資訊。
新增其他受保護的VM虛擬主機
由於在新增Protection Groups時採用動態VM虛擬主機名稱搭配萬用字元的加入方式，因此後續只要新增VM虛擬主機時開頭名稱為「EC」，便符合當初動態加入Protection Groups的規則，系統便會自動將其加入Protection Groups中進行保護，而無須管理人員再次將希望受保護的VM虛擬主機手動加入至Protection Groups當中。
在vCenter管理介面中，依序點選「vSAN9-ESA-Cluster > Actions > New Virtual Machine」項目，並根據系統需求及運作環境進行組態設定後，部署1台新的VM虛擬主機，本文實作環境VM虛擬主機名稱為「EC-App02」，如圖11所示。
圖11 部署1台VM虛擬主機名稱為EC-App02。
如何驗證EC-App02虛擬主機是否已經自動被vSAN DP機制所保護呢？只要切換回Protection Groups頁面，然後再次手動執行建立vSAN DP快照的動作，完成之後快照份數的Snapshots欄位便會從原本數值「1」轉變為「2」，並且受保護的VMs欄位也從原本的數值「3」轉變為「4」，表示剛才新部署名稱為EC-App02的VM虛擬主機已經自動加入Protection Groups當中，並受到vSAN DP快照機制的保護，如圖12所示。
圖12 新部署的EC-App02虛擬主機，自動加入Protection Groups並受到保護。
此外，點選「VMs > Existing VMs」項目，即可查看現有VM虛擬主機中哪些已經被Protection Groups所保護，哪些尚未被保護，每個檢視欄位都可以使用過濾排序功能，方便管理人員檢索及查詢，可以看到剛才新部署的EC-App02虛擬主機已經被系統自動加入至Customer Service App的Protection Groups當中，並且狀態為Protected受保護狀態，如圖13所示。
圖13 檢索及查詢現有VM虛擬主機是否被vSAN DP快照機制保護。
快速還原VM虛擬主機
當VM虛擬主機受到vSAN DP快照機制保護後，一旦受保護的VM虛擬主機發生故障損壞事件，甚至相關人員錯誤操作導致被刪除時，都可以透過先前建立的vSAN DP快照進行快速還原，回到快照時間良好的運作狀態。
舉例來說，手動將剛才新部署的EC-App02虛擬主機Power Off強制關機後直接刪除，並且在剛才的「VMs > Existing VMs」項目中已經沒有顯示EC-App02虛擬主機在受保護清單中。
接著，點選「VMs > Removed VMs」項目，即可看到剛才為EC-App02虛擬主機建立的vSAN DP快照資訊和份數，如圖14所示，此時點選「Restore VM」項目，系統將會彈出精靈對話視窗進入還原程序。
圖14 準備還原已經被刪除的EC-App02虛擬主機。
在Restore VM視窗的1. Select a snapshot步驟中，可以選擇該台VM虛擬主機的快照還原時間點，由於本文實作中的EC-App02虛擬主機只有1份快照，所以無法選擇其他快照還原時間點，如圖15所示。
圖15 選擇受保護VM虛擬主機的快照還原時間點。
在2. Select name and folder步驟中，選擇VM虛擬主機還原後所要存放的資料中心以及VM資料夾路徑。然後，在3. Select compute resource步驟中，選擇還原後的VM虛擬主機所要運作的叢集和vSAN節點主機為何。在4. Review步驟中，則再次檢視還原的組態設定內容，如果正確無誤，就按下〔Restore〕鈕，就可以立即執行還原作業。
快速複製VM虛擬主機
其實，在vSAN DP資料保護運作架構中，除了將快照用於快速保護和還原VM虛擬主機之外，還有另一個用途，對於企業和組織在故障排除、測試、研發上也非常方便實用，便是將原有ESA快照機制整合ESA Linked-Clone技術來達成快速複製的目的。舉例來說，當管理人員需要對營運服務VM虛擬主機進行相關的除錯測試和研發等動作時，為了避免影響到線上營運服務，便可以使用vSAN DP Clone VM快速複製機制達成。
值得注意的是，vSAN DP Clone VM的特色功能，與原有vCenter管理介面中傳統的Cloning VM動作不同，這些透過vSAN DP Clone VM快速複製機制所複製產生出來的VM虛擬主機，並不會受到vSAN DP快照機制的保護。
舉例來說，在本文實作環境中，選擇EC-Web01虛擬主機後，點選「VMs > Existing VMs > Clone VM」項目，在彈出的Clone VM視窗1. Select a snapshot步驟中，選擇該台VM虛擬主機的快照時間點，如圖16所示，接著在2. Select name and folder步驟中，選擇VM虛擬主機複製後存放的資料中心和資料夾路徑，以及新複製後的VM虛擬主機名稱，本文實作名稱為「EC-Web01-Clone」。然後，在3. Select compute resource步驟中，選擇VM虛擬主機屆時運作的叢集和vSAN節點主機，在4. Review步驟中，則再次檢視快速複製組態設定，若內容無誤再按下〔Clone〕鈕，即可立即執行快速複製作業。
圖16 透過vSAN DP Clone VM快速複製機制複製EC-Web01虛擬主機。
如同剛才注意事項所述，透過vSAN DP Clone VM快速複製機制所部署的VM虛擬主機，並不會被vSAN DP快照機制所保護，所以該台VM虛擬主機的狀態為「Not protected」，如圖17所示，即便管理人員修改Protection Group內容，調整加入VM虛擬主機的規則，從「Dynamic VM name patterns」更改為「Individual VM selection」，在指定選擇VM虛擬主機頁面中也無法找到快速複製的EC-Web01-Clone虛擬主機，並且也會看到系統將提醒不支援Linked-clone VMs的說明。
圖17 vSAN DP Clone VM快速複製部署的VM虛擬主機不受保護。
Protection Groups不可變更模式
在vSAN DP資料保護機制中，支援啟用特殊的「不可變更模式」（Immutable Mode）。簡單來說，一旦Protection Group啟用不可變更模式後，無論是原先定義的VM虛擬主機名稱規則，或是快照排程時間和保留期間，所有的組態設定一旦完成後便再也無法變更，甚至連Protection Group也無法被刪除，即便具備vCenter最大管理者權限也無法刪除。這個不可變更模式的主要目的，是防止惡意攻擊者即便取得系統的最大權限，也無法刪除被不可變更模式保護下，VM虛擬主機運作的重要營運服務。
舉例來說，管理人員在建立Protection Group時，例如本文實作為「IT CoreInfra Service PG」，然後勾選「Immutability mode」選項，屆時這個Protection Group便會自動啟用不可變更模式，同時在勾選不可變更模式時，系統也會顯示警告資訊提醒管理人員，一旦啟用不可變更模式後，屆時將無法變更及修改Protection Group組態設定內容，如圖18所示。
圖18 建立Protection Group並啟用不可變更模式。
Protection Group建立完成後，在Immutability mode欄位中，可以看到欄位狀態顯示為「Enabled」，表示這個Protection Group已經正式啟用不可變動模式，如圖19所示。
圖19 檢查Protection Group是否啟用不可變更模式。
啟用不可變更模式的Protection Groups，只剩手動執行vSAN DP快照作業，以及系統自動排程執行的快照任務，管理人員無法調整和編輯Protection Group組態設定內容，甚至無法刪除這個特殊的Protection Group，因此即便惡意人士取得vCenter管理者權限，仍然無法刪除這個被vSAN DP快照保護的Protection Group，以及受vSAN DP快照保護的VM虛擬主機，如圖20所示。
圖20 即便有vCenter最大管理權限，也無法變更和刪除不可變更模式的Protection Groups。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞