VMware vSAN 6.6 Journey (6) - Performance

前言

在第 6 代 vSAN版本當中，關於「效能」（Performance）的部分共新增 3 項特色功能（如下所示）。舉例來說，在新版 vSAN 6.6 叢集運作環境中，vSAN 叢集節點主機支援採用最新 Intel 3D XPoint NVMe 快閃儲存（Intel Optane P4800X）。此外，根據 VMware 官方進行的效能測試結果顯示，與舊版 vSAN 6.5 All-Flash 運作架構相較之下，新版 vSAN 6.6 All-Flash 架構整體儲存效能將能提升 50 %或更高。

• Deduplication and Compression
• Rebuild and Resynchronization Enhancements
• Checksum, De-Staging, iSCSI

Performance 新增特色功能

Deduplication and Compression

透過「重複資料刪除」(Deduplication)及「壓縮」(Compression)機制，可以有效降低寶貴的快閃記憶體儲存空間耗用，以提升快閃記憶體每 GB的可用成本。

簡單來說，透過重複資料刪除機制，將會有效針對快取層到容量層之間資料的「De-Staged」方式，以最大程度減少儲存空間的開銷。至於壓縮機制，則是針對「中繼資料」(Metadata)進行壓縮，以便降低 VM 虛擬主機和 vSAN 的「Backend I/O」開銷。

因此，在這 2 種機制的幫助之下，除了降低 vSAN 叢集工作負載之外也提供更可預設的運作效能，甚至當資料寫入行為是「順序寫入」(Dequential Write)時效果將更加明顯。

Rebuild and Resynchronization Enhancements

在 VMware vSAN 軟體定義儲存環境中，所有資料將會自動分散在不同 vSAN 節點主機之間，以達到服務高可用性及高運作效能。然而，在某些情況下 vSAN 節點主機之間需要大量同步資料，例如，將儲存原則由原本的 RAID-1變更為 RAID-5時，在  vSAN 節點主機之間的 vSAN 網路流量將會大幅增加。

另外一種情況是 vSAN 進行「修復」(Repair)操作時，也會造成 vSAN 節點主機之間的 vSAN 網路流量大幅增加，舉例來說，當某台 vSAN 節點主機因為發生硬體元件故障損壞事件，此時該台 vSAN 節點主機相關的物件及元件，將會被 vSAN 叢集標示為「Absent」，並且預設情況下會「等待 60 分鐘」之後，倘若標示為 Absent 的物件及元件仍未修復時，便會觸發自動修復機制。

這樣的修復程序設計原因在於，有時 vSAN 節點主機或許只是因為套用安全性更新重新啟動，或短暫的發生小小意外狀態導致暫時離線，但在很短時間內便會自動復原良好的運作狀態。簡單來說，vSAN 希望能夠在合理的時間內等待物件及元件復原，以避免 vSAN 節點主機之間產生大量的網路流量。

此外，當 vSAN 節點主機的可用儲存空間「少於 20%」時，vSAN 將會自動嘗試將資料遷移至其它較多可用空間的 vSAN 節點主機。

值得注意的是，針對 vSAN 修復程序產生的大量網路流量，雖然 vSAN 支援「節流」功能來限制修復程序產生的網路流量，然而此舉除了增加重建程序的執行時間之外，同時也會增加停機的風險。所以，VMware 官方最佳建議作法是保留預設值「禁用節流」(Throtting Disabled)功能較佳。

Checksum, De-Staging, iSCSI

在新版 vSAN 運作環境中，內建原生的「Checksum」機制有助於確保資料完整性，同時也針對資料讀取和寫入路徑進行最佳化，以避免多餘的 Table Lookup 操作而影響運作效能。

雖然，在極少數的情況下，中繼資料的增加可能會對 VM 虛擬主機的 I/O 儲存效能，以及同步操作產生些微的效能影響，例如，大量執行資料刪除作業時，便會大量增加中繼資料。因此，在新版 vSAN 6.6 當中透過「De-Staging」機制避免中繼資料的累積，以避免「寫入密集型」(Write Intensive)的工作負載，因為中繼資料的不斷累積進而影響運作效能。

此外，在 vSAN 運作環境中負責 iSCSI 服務的 FreeBSD 版本，已經升級至新版 FreeBSD 10.3版本，確保 vSAN 6.6 當中的 iSCSI 服務能夠提供更佳的 iSCSI 運作效能。