網管人雜誌
本文刊載於 網管人雜誌第 240 期 - 2026 年 1 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
最新發佈的 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 超融合全域重複資料刪除示意圖
vSAN 9 Global Dedup 運作架構
由於 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 所示）：
1. vSAN 叢集讀取離散的 4KB 資料區塊，並產生要儲存在重複資料刪除中繼資料物件中，進行安全加密的雜湊內容。
2. vSAN 叢集將會在重複資料刪除中繼資料中，尋找符合的 Hash Entry，倘若探索到與重複資料刪除物件中的資料相符且一致時，便會使用中繼資料指標更新資料區塊並回收儲存空間。
3. 如果在重複資料刪除物件中，並沒有找到符合的 Hash Entry 時，它會將目前資料和原始資料，同時遷移到重複資料刪除物件中，使用中繼資料指標更新資料區塊並回收儲存空間。
4. 如果完全找不到符合的 Hash Entry 時，則會讓資料保持原樣，而 Hash Entry 將會在中繼資料物件中建立，並具有資料所在的反向指標，以便在後續識別重複 Hash Entry 時，可以如上所述刪除重複資料。
圖 2、vSAN ESA 運作架構重複資料刪除處理程序示意圖
實戰 – 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）資料保護機制運作架構示意圖
部署 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 所示）。
值得注意的是，在系統提醒資訊中，說明當 vSAN Datastore 儲存資源使用量「超過 70%」門檻值後，系統將會停止執行 vSAN DP 快照的自動化排程作業，避免 vSAN DP 快照影響 vSAN 儲存資源的正常運作。
圖 4、查看 vSAN Data Protection 簡要資訊和快照儲存空間使用率頁面
請依序點選「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 虛擬主機選項
圖 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 所示）：
- 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： 顯示最初開始建立快照的時間點。
圖 8、查看新增完成的 Protection Group 簡要資訊
手動建立 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 快照
圖 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 虛擬主機
圖 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 並啟用不可變更模式
圖 19、檢查 Protection Group 是否啟用不可變更模式
啟用不可變更模式的 Protection Groups，只剩手動執行 vSAN DP 快照作業，以及系統自動排程執行的快照任務，管理人員無法調整和編輯 Protection Group 組態設定內容，甚至無法刪除這個特殊的Protection Group，因此即便惡意人士取得 vCenter 管理者權限，仍然無法刪除這個被 vSAN DP 快照保護的 Protection Group，以及受 vSAN DP 快照保護和 VM 虛擬主機（如圖 20 所示）。
圖 20、即便有 vCenter 最大管理權限，也無法變更和刪除不可變更模式的 Protection Groups
結語
透過本文的深入剖析和實戰演練後，管理人員除了理解最新發佈 vSAN 9.0 版本中，有哪些亮眼的特色功能之外，透過實戰演練小節，實作 vSAN 9 DP 快照保護機制，有效幫助企業和組織，保護重要的 VM 虛擬主機和營運服務，能夠在災難事件發生時快速回復回原先良好的運作狀態。