顯示具有 SDS 標籤的文章。 顯示所有文章
顯示具有 SDS 標籤的文章。 顯示所有文章

前言

日前 (2017/4/18),VMware 官方正式發佈 vSAN 第六代 VMware vSAN 6.6 Release 資訊。雖然距離上一版 vSAN 第五代 VMware vSAN 6.5 發佈才間隔短短五個月。但是,這次發佈的 vSAN 第六代總共新增 23 項特色功能!!

有關過去每一代 vSAN 版本的新增特色功能資訊,請參考站長歷來撰寫的 vSAN 專欄文章:
圖、VMware Virtual SAN版本演進及新增功能示意圖


那麼,接下來站長也將不定期針對第六代的 vSAN 6.6 深入剖析各項特色功能:

【簡介】(Introduction)




【安全性】(Security)

  • Native Encryption
  • Compliance



【管理】(Management)

  • Proactive Cloud Health Checks
  • vSAN COnfiguration Assist
  • Hardware Lifecycle Management
  • Highly Svailable COntrol Plane for Health Checks
  • Health and Performance Monitoring
  • vRealize Management Pack for vSAN
  • Stretched Cluster Witness Replacement
  • Host Evacuation
  • vSAN API and PowerCLI



【部署】(Deployment)

  • Easy Install
  • Multicast Dependency Removed
  • Extensibility


【可用性】(Availability)

  • Stretched Cluster Local Failure Protection
  • Stretched Cluster Site Affinity
  • Degraded Device Handling



【效能】(Performance)

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

前言

日前 (2017/4/18),VMware 官方正式發佈 vSAN 第六代 VMware vSAN 6.6 Release 資訊。



雖然距離上一版 vSAN 第五代 VMware vSAN 6.5 發佈才間隔短短五個月。但是,這次發佈的 vSAN 第六代總共新增 23 項特色功能!!

圖、VMware vSAN 原生超融合安全性

圖、VMware vSAN 提供 SDDC 中深度整合的安全性機制


vSAN 6.6 新功能簡介

由於新功能太多,因此本篇將是 vSAN 6.6 總共新增 23 項特色功能的概要說明。後續,將會把每項特色功能拆解後再依續深入剖析各項機制。首先,我們可以將這些新功能區分為五大類,分別是「安全、管理、部署、可用性、效能」

【安全性】(Security)

在安全性方面有 2 項新功能分別是「Native Encryption」「Compliance」,主要在 VMware SDDC 軟體定義資料中心的願景中,VMware vSAN 擔任 SDS 軟體定義儲存的重要角色。因此,確保儲存資源的安全性機制將相形重要,在新版 vSAN 6.6 當中無須依靠加密磁碟 (SED) 就可以達成靜態資料加密解決方案,有效保護企業及組織當中的機敏資訊。

圖、啟用 vSAN 加密機制


【管理】(Management)

在新版 vSAN 6.6 當中關於管理的部分共有 9 項新功能 (如下所示)。同時,在過往的 vSAN 版本當中,整個 vSAN 運作環境仍圍繞在 vCenter Server 為主要管理平台。現在,新版 vSAN 6.6 已經可以在 vCenter Server 離線時透過 VMware ESXi Host Client 進行管理,不過在哪一台 vSAN 叢集節點都可以查看健康情況。
  • Proactive Cloud Health Checks
  • vSAN Configuration Assist
  • Hardware Lifecycle Management
  • Highly Available Control Plane for Health Checks
  • Health and Performance Monitoring
  • vRealize Management Pack for vSAN
  • Stretched Cluster Witness Replacement
  • Host Evacuation
  • vSAN API and PowerCLI

圖、透過 ESXi Host Client 管理介面查看 vSAN 健康情況



【部署】(Deployment)

在新版 vSAN 6.6 當中關於部署的部分共有 3 項新功能 (如下所示)。在過往的 vSAN 運作環境中,最令管理人員感到困擾的便是 vSAN 叢集主機之間必須透過「Multicast」進行溝通。現在,新版 vSAN 6.6 改為採用「Unicast」(當舊版升級為 vSAN 6.6 後也會自動 Multicast -> Unicast)。
  • Easy Install
  • Multicast Dependency Removed
  • Extensibility

圖、新版 vSAN 改為採用 Unicast

圖、新版 vSAN 改為採用 Unicast



【可用性】(Availability)

在新版 vSAN 6.6 當中關於可用性的部分共有 3 項新功能 (如下所示)。事實上,從第二代 vSAN 6.0 版本開始便具備 vSAN Stretched Cluster 的運作架構,然而新版的 vSAN 6.6 結合本地端故障保護機制讓站台之間的容錯更具備彈性,甚至結合親和性規則讓儲存原則的管理更具備靈活性。
  • Stretched Cluster Local Failure Protection
  • Stretched Cluster Site Affinity
  • Degraded Device Handling

圖、Stretched Cluster Local Failure Protection 運作架構示意圖


圖、Stretched Cluster Site Affinity 運作架構示意圖




【效能】(Performance)

在新版 vSAN 6.6 當中關於效能的部分共有 5 項新功能 (如下所示)。在新版 vSAN 6.6 當中,支援最新 Intel 3D XPoint NVMe 快閃儲存 (Intel Optane P4800X),並且根據 VMware 官方的效能測試結果顯示,跟舊版 vSAN  All-Flash 運作架構相較之下儲存效能將提升 50%
  • Deduplication and Compression
  • Rebuild and Resynchronization Enhancements
  • Checksum
  • De-Staging
  • iSCSI

圖、ESXi vs Bare Metal 使用 Intel Optane 效能測試

圖、VMware vSAN 使用 Intel Optane 效能測試



參考資源


前言

簡單來說,在新一代 Windows Server 2016 雲端作業系統中,倘若 IT 管理人員需要透過 S2D (Storage Spaces Direct) 技術建構 SDS 軟體定義儲存環境。在相關教學文章及影片中,你應該會不斷看到強調支援「RDMA (Remote Direct Memory Access)」技術,主要原因在於 RDMA 技術能夠有效「降低 S2D 叢集節點 CPU 工作負載」同時「降低延遲時間」

然而,大家對於 RDMA 運作環境相對陌生,因此許多 IT 管理人員一開始的困惑便是,那麼「不支援」RDMA 的環境能否運作 Windows Server 2016 的 S2D 技術? 答案是,S2D 即便在不支援 RDMA (走一般的 TCP/IP 乙太網路) 的環境下仍能正常運作。



測試環境及測試工具

微軟官方採用同一批軟硬體環境,並且進行「RDMA Enabled」以及「RDMA Disabled」的測試,同時整理出 2 種運作環境的儲存效能,以便 IT 管理人員能夠了解這 2 種運作環境之間的效能差異。

測試環境 (4 Nodes S2D Cluster)

下列為 4 Nodes S2D Cluster 測試環境中,每台 S2D 叢集節點主機的硬體配置:
  • Host: Intel S2600WT Platform
  • CPU: E5-2699 v4 2.2 GHz *2 (每顆 22 Cores / 44 執行緒)。
  • Memory: 128 GB DDR4
  • SSD: Intel P3700 NVMe *4
  • NIC: Mellanox CX3 Pro 40Gb (Dual Port, RoCE v2)
  • BIOS: Power Performance Plan、C States Disabled、Turbo Enabled、HT Enabled。
  • OS: Windows Server 2016、S2D (Storage Spaces Direct)、High Performance Power Plan。
  • S2D Volume: 3-Way Mirror。

測試工具

  • DISKSPD
  • 4K 100% Random I/O (70% Read / 30% Write)。
  • 10 Threads (Queue Depth 4 per Thread,Total is 40)。
  • 10 GB file per Thread (Total is 100 GB)。

測試結果

下列圖表便是分享整理「RDMA Enabled」「RDMA Disabled」的測試結果,歸納重點如下:
  • 倘若,你希望 S2D 有良好的儲存效能表現。那麼,你應該要讓 S2D 運作在 RDMA Enabled 環境。
  • 此次的實作環境中 RDMA Enabled,能夠提升 28% IOPS、27% CPU 效能、36% Write Latency、28% Read Latency
  • 即便是 RDMA Disabled 環境 (TCP/IP 乙太網路),仍能夠提供 145,500 IOPS 的儲存效能。



此外,也可以參考去年 Microsoft Ignite 2016 大會中 BRK3088 - Discover Storage Spaces Direct, the ultimate software-defined storage for Hyper-V 議程。


在該議程中的測試環境,也有分別測試「RDMA Enabled」「RDMA Disabled」的效能測試結果 (節省 1/3 的 CPU 工作負載、達到提升 2 倍的 IOPS 效能表現):





參考資源


前言

在去年 Microsoft Ignite 2016 大會上,在 Meet Windows Server 2016 and System Center 2016 議程中展示 S2D (Storage Spaces Direct) 的儲存效能表現。在當時展示的運作環境中,每台 S2D 叢集節點配置的是 Chelsio T580CR 40GbE (iWARP) 網路介面卡,整個 S2D 叢集共有 16 台節點主機,最後打出高達「600 萬 IOPS」的儲存效能表現。




S2D 支援 10 / 25 / 40 / 100 GbE 網路環境

現在,Microsoft S2D 軟體定義儲存技術已經支援 10 / 25 / 40 / 100 GbE 網路環境。同時,Chelsio 也已經發行 T6 系列 100GbE 的網路介面卡。




S2D 使用 100GbE iWARP 的儲存效能輸送量

因此,Microsoft 官方也為 S2D 叢集節點主機配置 Chelsio T6 100GbE 網路介面卡,來測試在這樣的網路環境中 S2D 的儲存效能輸送量為多少。下列便是此次的 S2D 測試環境說明:

4 台 S2D 叢集節點主機 (Dell R730xd),每台硬體配置如下:

  • CPU: E5-2660 v3 2.60 GHz *2 (每顆 10 Cores / 20 執行緒)。
  • Memory: 256 GB DDR4 2133 MHz (16 GB * 16 DIMM)。
  • Storage: 3.2TB NVME Samsung PM1725 *4 (PCIe 3.0 x8)。
  • NIC: Chelsio T6 100GbE (Dual Port PCIe 3.0 x16)。
  • Cabling: QSFP28 Passive Copper Cabling。
  • BIOS Power: Performance Power Plan
  • OS: Windows Server 2016、S2D (Storage Spaces Direct)、High Performance Power Plan。
  • DCB 組態設定: 因為採用的 Chelsio T6 100GbE 為 RDMA 中的 iWARP,所以無須組態設定 DCB (PFC)。

工作負載

  • DISKSPD
  • VM Fleet
  • 80 VMs (16 GB VHDX),每台 S2D 叢集節點運作 20 Azure A1 Sized VMs (1 vCPU、1.75 GB RAM)。
  • 512 KB 100% Random Read (每台 VM 的 Queue Depth 為 3)。


IOPS 輸送量效能測試結果

下列便是採用 VMFleet 進行 IOPS 輸送量效能測試結果,從結果數據中可以看到總頻寬輸送量高達「83 GB/s」,也就是說每台 VM 虛擬主機使用超過 1GB/s 的輸送量,同時整個 Read Latency 也「< 1.5 ms」




參考資源


網管人雜誌

本文刊載於 網管人雜誌第 134 期 - 2017 年 3 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。



文章目錄

前言
vSAN 6.5 新功能
          iSCSI 存取
          2 台 vSAN Node 直接對接
          全功能 PowerCLI
          支援新世代硬碟 512e 進階格式
          全版本支援 All Flash
結語





前言

在 2016 年 11 月時,VMware 官方在 VMware VMworld 2016 大會上,正式發佈 VMware vSphere 6.5 最新版本並連同 VMware vSAN 6.5 版本也一起推出。簡單來說,VMware Virtual SAN(簡稱 vSAN),是 VMware 的「軟體定義儲存(Software-Defined Storage,SDS)」解決方案,它能夠將多台 x86 實體伺服器內的「本機硬碟(Local Hard Disk)」互相串連起來,進而將叢集當中所有 vSAN 節點主機的儲存資源整合起來,成為一個巨大的儲存資源池並且能夠互相共同使用。

圖 1、VMware vSAN 運作架構示意圖

事實上,從 VMware vSAN 版本的發佈頻率可知,VMware 官方對於打造 SDDC 軟體定義資料中心內,負責儲存資源的 SDS 軟體定義儲存技術的重視。第 1 代的 VMware vSAN 版本,是在 2014 年 3 月時隨著 vSphere 5.5 Update 1 版本開始內建(vSAN 1.0),接著在隔年推出第 2 代 VMware vSAN 版本,是在 2015 年 3 月隨著當時新版 vSphere 6.0 一同發佈,並直接與 vSphere 版本對齊成為 vSAN 6.0 版本(原訂新版本號應為 vSAN 2.0),在這個版本當中最重要的特色為支援 All Flash 運作架構,同時 vSAN 叢集規模可達到 64 台節點之多。
有關第 1 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 110 期《實戰部署 Virtual SAN套用政策自動化搭配 VM》,而第 2 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 114 期《動手建立 VSAN 6 儲存資源,實戰水平擴充與容錯網域》

接著,半年後於 2015 年 9 月時推出第 3 代的 vSAN 6.1 版本,其中最具代表性的功能便是「延伸叢集」(Stretched Cluster)與「支援 2 Nodes」的運作架構。再隔半年後於 2016 年 3 月推出第 4 代 vSAN 6.2 版本,在這個版本當中最重要的特色為 All Flash 運作架構,支援「重複資料刪除與壓縮」(Deduplication and Compression)及「RAID 5/6 EC 編碼技術」(RAID 5/6 Erasure Coding)。
有關第 3 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 120 期《VMware VSAN 延伸叢集,實作跨站點同步 HA 複寫》,而第 4 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 124 期《概覽 VMware VSAN 6.2 新功能加強健康狀態監控》

現在,於 2016 年 11 月隨著最新 VMware vSphre 6.5 的發佈也同時推出第 5 代的 vSAN 6.5 版本,此版本中重要的特色功能條列如下:
  • iSCSI 存取: 支援將 vSAN 儲存空間以 iSCSI目標的方式提供,讓具備 iSCSI 啟動器功能的伺服器能夠連接及使用 vSAN 儲存空間。
  • 2 台 vSAN Node 直接對接: 支援將 2 台 vSAN節點主機直接對接,讓企業及組織當中的分公司或小型企業在建置 vSAN 軟體定義儲存環境時,無須準備昂貴的 10GbE 網路交換器。
  • 全功能 PowerCLI: 在新版 vSAN 6.5 運作環境中,包括完整的 PowerCLI Cmdlet 功能讓企業及組織的自動化作業更具可擴充性及易用性。
  • 支援新世代硬體: 在新版 vSAN 6.5 運作環境中,支援新世代的 x86 硬體伺服器及相關元件,同時也支援 512e 新式大容量儲存裝置。
  • 全版本支援 All-Flash: 現在不管採用哪種 vSAN 6.5 授權版本,都可以使用及建置 vSAN All-Flash 運作架構。
圖 2、VMware Virtual SAN版本演進及新增功能示意圖





vSAN 6.5 新功能

在過去舊版的 vSAN 運作環境內,當 vSphere 管理人員將 vSAN 叢集中的節點主機儲存資源集合之後,儲存資源只能夠以「VMFS 檔案系統」的方式提供及運作 VM 虛擬主機。但是,對於需要採用其它方式使用儲存資源的應用程式或服務來說便會造成困擾,舉例來說,現行企業及組織當中有許多應用程式及服務的儲存資源,便是透過在伺服器中安裝及啟用「iSCSI 啟動器」(iSCSI Initiator)功能,然後透過 TCP/IP 乙太網路連接至「iSCSI 目標端」(iSCSI Target)所提供的 LUN 儲存資源,最後再將應用程式及服務運作在透過 iSCSI 協定所掛載的 LUN 儲存資源當中。

現在,最新版本的 vSAN 6.5 運作架構中,支援將整合後的 vSAN 儲存資源以 iSCSI 目標端的方式,提供給 iSCSI 啟動器掛載 LUN 儲存資源,有效解決過去舊版 vSAN 儲存資源美中不足的困擾。在運作規模方面,每個 vSAN 叢集最多支援提供 1,024 個 LUN 儲存資源,並且每個 LUN 儲存資源空間最大為 62 TB,同時每個 vSAN 叢集最多支援提供 128 個 iSCSI 目標

因為 iSCSI 目標所建立的 LUN 儲存資源,在 vSAN 運作架構底層中其實是以 VMDK 虛擬磁碟的方式存在,所以儲存空間與 VMDK 虛擬磁碟的限制相同為 62 TB。



iSCSI 存取

雖然,最終是以 iSCSI 協定提供儲存資源服務,但是整個運作架構底層還是建構在 vSAN 軟體定義儲存技術之上,所以當 vSAN 運作架構成型後 vSphere 管理人員若需要啟用 vSAN iSCSI 目標服務時非常簡單,並且同樣能夠以 vSAN 原有的「儲存原則」(Storage Policy),管控由 vSAN 所提供的 iSCSI LUN 儲存資源。此外,倘若運作環境中需要使用 iSCSI 的 CHAP 身分驗證機制時,那麼 vSAN iSCSI 目標也支援單向 CHAP 及雙向 CHAP 身分驗證機制。

圖 3、VMware vSAN 分散式 iSCSI Target 運作架構示意圖

啟用 iSCSI 目標服務
當 vSphere 管理人員需要啟用 vSAN iSCSI 目標服務時,請登入 vSphere Web Client 管理介面並點選叢集物件後,依序點選「Configure > Virtual SAN > General」項目,然後在 Virtual SAN iSCSI Target Service 組態設定區塊中按下「Edit」鈕,準備啟用 vSAN iSCSI 目標服務。

請在彈出的 Edit Virtual SAN iSCSI Target Service 視窗中,組態設定相關選項並在下拉式選單中選擇採用相關功能:
  • Enable Virtual SAN iSCSI target service: 請勾選此項目,以便啟用 vSAN iSCSI 目標服務。
  • Default iSCSI network: 透過下拉式選單指定屆時 vSAN iSCSI 目標服務,要採用哪個 VMkernel Port 進行 iSCSI 儲存流量傳輸作業。
  • Default TCP port: 指定 vSAN iSCSI 目標服務的連接埠號,請採用預設標準的 iSCSI 目標端連接埠號 3260 即可。
  • Default authentication: 透過下拉式選單指定 vSAN iSCSI 目標服務的身分驗證方式,預設值為 None 不啟用 CHAP 身分驗證機制,倘若需要的話 vSAN iSCSI 目標服務也支援單向 CHAP 及雙向 CHAP 身分驗證機制。
  • Storage policy for the home object: 透過下拉式選單指定 vSAN iSCSI 目標服務所要套用的 SPBM 儲存原則。
圖 4、啟用 vSAN iSCSI 目標服務功能及組態設定功能項目

建立 LUN 儲存資源
當 vSAN iSCSI 目標服務順利啟動後,接著便可以建立 iSCSI 目標及 LUN 儲存資源。請在 vSphere Web Client 管理介面中,依序點選「Configure > Virtual SAN > iSCSI Targets」項目後,在 Virtual SAN iSCSI Targets 組態設定區塊中按下「新增」鈕(綠色加號圖示),準備組態設定 vSAN iSCSI 目標及建立 LUN 儲存資源。

請在彈出的 New iSCSI Target 視窗中,組態設定相關選項並在下拉式選單中選擇採用相關功能:
  • Target IQN: 系統為 vSAN iSCSI 目標服務隨機產生的 iSCSI Target IQN。
  • Target alias: 管理人員可以為此 vSAN iSCSI 目標服務指定別名以利識別。
  • Target storage policy: 指定此 vSAN iSCSI 目標服務所要套用的 SPBM 儲存原則。
  • Network: 透過下拉式選單指定此 vSAN iSCSI 目標服務,要採用哪個 VMkernel Port 進行 iSCSI 儲存流量傳輸作業。
  • TCP port: 指定 vSAN iSCSI 目標服務的連接埠號,請採用預設的標準 iSCSI 目標端連接埠號 3260 即可。
  • Authentication: 透過下拉式選單指定此 vSAN iSCSI 目標服務的身分驗證方式,vSAN iSCSI 目標服務支援單向 CHAP 及雙向 CHAP 身分驗證機制,預設情況下請採用預設值 None 即可。
  • Add your first LUN to the iSCSI target(Optional): 請勾選此項目,以便建立及組態設定 LUN 儲存資源。
  • LUN ID: 指定此 LUN 儲存空間的 ID 數值。
  • LUN alias: 指定此 LUN 儲存空間的別名以利識別。
  • LUN storage policy: 指定此 LUN 儲存資源所要套用的 SPBM 儲存原則。
  • LUN size: 指定此 LUN 儲存資源的空間大小。
圖 5、組態設定 vSAN iSCSI 目標及 LUN 儲存資源

新增 iSCSI 啟動器存取清單
順利建立 LUN 儲存資源之後,在 Target Details 組態設定區塊中便會看到剛才所建立的 LUN 儲存資源資訊。最後,請在同組態設定區塊中切換到「Allowed Initiators」頁籤後按下「新增」鈕(綠色加號圖示),新增只有哪些 iSCSI 啟動器能夠存取此 vSAN iSCSI 目標所提供的 LUN 儲存資源。

圖 6、組態設定哪些 iSCSI 啟動器能夠存取 vSAN iSCSI 目標所提供的 LUN 儲存資源

現在,只要在允許存取 LUN 儲存資源清單中的 iSCSI 啟動器,便可以透過 TCP/IP 乙太網路順利存取由 vSAN iSCSI 目標所提供的 LUN 儲存資源。值得注意的是,根據 VMware 官方的最佳作法建議,倘若只是要運作 VM 虛擬主機的話,應該保持以原本的 VMFS 檔案系統來運作 VM 虛擬主機即可,倘若是要運作如 MSCS 微軟容錯移轉叢集或 Oracle RAC……等服務,並且規劃使用 IP-SAN(iSCSI)運作架構時才建議使用 vSAN iSCSI 目標服務。

在 vSAN iSCSI 目標服務容錯移轉的部分,因為 vSAN iSCSI 目標服務是完全整合於 vSAN 分散式運作架構,所以當 iSCSI 啟動器端連線時便會連接到 vSAN 目標端的「擁有者」(Owner)節點主機,並且由該台 vSAN 節點主機回應 iSCSI 啟動器端存取負責管理的 LUN 儲存資源。

倘若,原本負責 vSAN iSCSI 目標端擁有者的節點主機突然發生故障事件時,那麼便會由 vSAN 叢集中其它存活的節點主機接手服務,成為 vSAN iSCSI 目標端擁有者並且繼續服務 iSCSI 啟動器,而 iSCSI 啟動器便會連接至新的 vSAN iSCSI 目標端擁有者,繼續使用由 vSAN 叢集所提供的 LUN 儲存資源。

圖 7、vSAN iSCSI目標服務容錯移轉運作架構示意圖



2 台 vSAN Node 直接對接

事實上,在第 3 代 vSAN(vSAN 6.1)運作環境中,便已經支援「2 Node」的 vSAN 節點主機運作環境,也就是只要 2 台 vSAN 節點主機便能建構 vSAN 叢集,這樣的運作架構適用於企業及組織中分公司或小型運作環境時使用。然而這樣的 vSAN 運作架構雖然只有 2 台 vSAN 節點主機,卻仍需要配置 1 台昂貴的 10 Gbps 網路交換器,並且也僅用到該台 10 Gbps 網路交換器的 4 個連接埠而已,倘若考慮預防 SPOF 單點失敗情況的話,則需配置「2 台」10 Gbps 網路交換器,並且每台 10 Gbps 網路交換器只會用到 2 個連接埠而已,這對於建置分公司或小型 vSAN 運作規模的整體預算來說是項吃重的負擔。

現在,全新第 5 代 vSAN 6.5 運作環境中,原有 1 Gbps 負責 VM 虛擬主機網路傳輸的部分可繼續延用,然而原有 10 Gbps 負責 vSAN 節點主機資料同步的部分,正式支援 2 台 vSAN 節點主機透過「交叉式纜線」(Crossover Cables)的方式互相連接,無須再向過往舊版 vSAN 運作環境必須透過 10 Gbps 網路交換器。如此一來,建置分公司或小型 vSAN 運作環境時便無須再採購昂貴的 10 Gbps 網路交換器,因此能夠有效降低分公司或小型 vSAN 運作規模的整體預算,根據 VMware 官方分析調查的結果顯示可以有效降低約「20 %」的投資成本。

在組態設定部分,根據 VMware 官方的最佳作法建議,當在 vSAN 叢集當中的節點主機透過交叉式纜線互相連接之後,在 vSAN 節點主機網路流量規劃的部分,應該要將「vSAN 儲存流量」及「vMotion 遷移流量」分開在不同的 10 Gbps 纜線進行傳輸,以避免儲存或遷移流量互相干擾的情況發生,舉例來說,倘若 2 台 vSAN 節點主機正透過 vSAN 儲存流量網路大量同步資料狀態的情況下,此時又剛好以 vMotion 線上遷移機制大量遷移 VM 虛擬主機的話,那麼有可能會增加 10 Gbps 的網路延遲時間及工作負載。

因此,在 vSAN 節點主機網路流量規劃的部分,除了將儲存或遷移流量分開之外,也同時應設定為互相備援的組態配置以便故障情況發生時,能夠有另 1 個 10 Gbps 纜線進行網路流量的容錯移轉。

圖 8、2 台 vSAN 節點主機透過交叉式纜線連接後,網路流量規劃的組態配置示意圖

此外,在最新的 vSAN 6.5 版本開始,新增將「見證網路流量」(Witness Traffic)分離的功能,解決在 2 台 vSAN 節點主機上必須建立及維護靜態路由的組態設定,降低 vSAN 整體運作架構的複雜度,同時在安全性方面也得到改善,因為 vSAN 儲存網路流量與 WAN 見證網路流量得以完全分離。

因為,負責 vSAN 運作架構的見證虛擬設備不可以運作在 2 台 vSAN 節點主機上,同時一般來說 2 台 vSAN 節點主機的運作架構,通常是運作在企業及組織的分公司或遠端辦公室當中。倘若,分公司或遠端辦公室有透過 WAN 網路與主要辦公室連接時,那麼可以考慮將見證虛擬設備運作在主要辦公室當中,除了節省建置第 3 台 ESXi 主機以運作見證虛擬設備之外,將見證虛擬設備運作在主要辦公室以便統一進行管理。

圖 9、2 台 vSAN 節點主機及見證虛擬設備運作在主要辦公室運作架構示意圖



全功能 PowerCLI

在新版 vSAN 6.5 運作環境中,VMware 官方已經將 vSphere API 抽象化為簡單的 Cmdlet。因此,現在 vSphere 管理人員可以透過 VMware PowerCLI 的方式,以更快速且自動化的方式部署及管理 vSAN 運作環境:
  • 啟用重複資料刪除及壓縮機制。
  • 啟用 vSAN 效能服務。
  • 組態設定 vSAN 健康檢查服務。
  • 建立 All Flash 磁碟群組。
  • vSAN 故障網域管理。
  • 組態設定 vSAN 延伸叢集。
  • 為維護模式選擇正確的資料遷移選項。
  • 檢索儲存空間資訊。
圖 10、透過 VMware PowerCLI 管理 vSAN 運作環境示意圖



支援新世代硬碟 512e 進階格式

過去,舊有的儲存裝置(硬碟)都採用「512 Byte Sector」(又稱為 512n)格式,而新式儲存裝置「進階格式」(Advance Format,AF)則是採用「4,096 Byte Sector」(又稱為 4Kn)格式。現在,從 VMware vSphere 6.5 及vSAN 6.5 版本開始,只要配合最新的「VMFS 6」檔案系統便全面支援以「512e(512B Emulation)」的方式運作,也就是以 512e 模擬 4K 的方式運作配合實體硬碟特性增強整體運作效能。
請注意!! 採用舊版 vSAN 或 VMFS 檔案系統的話,不支援以 512e 的方式運作所以採用 512e 的儲存裝置時,可能會引發或造成潛在的運作效能問題。有關 512 / 4,096 Byte Sector 詳細資訊請參考 VMware KB 2091600

圖 11、vSAN 6.5 支援新式進階格式 512e 儲存裝置示意圖

簡單來說,「磁區大小」(Sector Size)是影響作業系統及 Hypervisor 虛擬化管理程序運作效能的關鍵,因為它是儲存裝置(硬碟)最底層 I/O 的基本單位。因此,新式 512e 與舊有 512n 相較之下,雖然新式 512e 邏輯磁區大小也是 512 Byte,但是實體磁區大小則是 4,096 Byte 這是二者間最大的不同,所以在資料的「讀取-修改-寫入」(Read-Modify-Write,RMW)行為上,新式的 512e 與舊有的 512n 相較之下,會減少許多在資料 RMW 行為時效能懲罰的部分。

雖然,原生 4Kn 不管在邏輯磁區大小或實體磁區大小都是 4,096 Byte,但是目前的情況為並非所有儲存裝置、作業系統及 Hypervisor 虛擬化管理程序都完全支援。在下列表格中,為讀者們條列舊有 512n 及新式 512e 和原生 4Kn 在邏輯及實體磁區大小上的運作差異:

請注意!! 目前最新版本的 VMware vSphere ESXi 6.5 及 vSAN 6.5 運作環境中,仍尚未支援原生 4K 儲存裝置。
在目前儲存裝置市場中,支援新式進階格式 512e 的儲存裝置空間從 300 GB 到 10 TB 都有,並且通過 VMware vSAN 6.5 版本硬體認證的 512e 硬碟約有 230 個型號,不同 OEM 硬碟供應商所通過的數量不定。建議在使用及建置前應向硬碟供應商再次確認,所使用的硬碟是否支援新式進階格式 512e,以確保屆時建置的 VMware vSAN 6.5 運作效能及穩定性。

圖 12、各家 OEM 廠商通過 VMware vSAN 6.5 版本硬體認證的 512e 硬碟統計圖



全版本支援 All Flash

雖然,VMware vSAN 從第 2 代 vSAN 6.0 版本開始便支援 All Flash 運作架構,然而在過去的 vSAN 軟體授權版本當中,至少要採用「進階版或企業版」的 vSAN 軟體授權才能夠使用 All Flash 的運作架構及特色功能。

現在,最新的 VMware vSAN 6.5 版本當中,不管採用哪種 vSAN 軟體授權版本皆支援使用 All Flash 運作架構。因此,即便是由 2 台 vSAN 節點主機所建構的小型 vSAN 運作環境,也能夠使用 All Flash 的硬體運作架構,為需要高 IOPS 儲存效能的分公司或小型 vSAN 環境提供解決方案。

值得注意的是,雖然開放「標準版」及「ROBO 版」支援採用 All Flash 硬體架構來建立 vSAN 運作環境,但是在 All Flash 運作架構中進階特色功能,例如,「重複資料刪除及壓縮」、「RAID5/6 Erasure Conding」特色功能,仍需要採用「進階版或企業版」vSAN 軟體授權才能夠使用。

此外,如果要讓建置的 vSAN 運作架構支援「延伸叢集」或「IOPS 儲存效能管控」特色功能時,那麼只能採用「企業版」的 vSAN 軟體授權才能夠使用這 2 項進階功能特色。

圖 13、VMware vSAN 6.5 軟體授權可使用特色功能示意圖





結語

透過本文的說明及實作相信讀者已經了解,在第 5 代最新 vSAN 6.5 版本當中有哪些特色功能,能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 SDS 軟體定義儲存運作環境。

同時,對於企業及組織的分公司或小型企業運作環境來說,以往在建立虛擬化環境時令人困擾的初期建置成本問題,在新版 vSAN 6.5 當中透過交叉式纜線的方式解決僅 2 台 vSAN 節點主機,就必須採購昂貴 10Gbps 網路交換器的問題。

前言

自從 Windows Server 2016 推出後,大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。本文,將要深入探討在 S2D 軟體定義儲存運作環境中「Storage Pool」的功能改進:

  • 每個 Storage Pool 最大支援「416 Drives」及 「1 PB Raw Capacity」,同時最佳建議是「One pool per Cluster」。
  • 執行「Enable-ClusterS2D」指令啟用 S2D 功能時,會自動建立 Storage Pool 並且把「合格的儲存裝置」(例如,未格式化過的磁碟) 加入到 Storage Pool 當中。同時,當加入新的 S2D 儲存節點時 (Scale-Out) 也會自動把相關的儲存裝置加入到 Storage Pool 當中,當儲存裝置發生故障時會自動退出並從 Storage Pool 當中移除。
  • 透過 S2D PM「Cosmos Darwin」撰寫的 PowerShell,可以輕鬆幫助你了解 Storage Pool 及儲存裝置空間的使用情況。






混亂的開始 (Resiliency, Slabs, Striping)

讓我們先從 3 Nodes 的 S2D 運作架構,每台 S2D Node 具備「2 x 800GB NVMe」以及「4 x 2TB SATA SSD」開始談起。




什麼是 Resiliency?

舉例來說,當我們建立「1 TB - 2WayMirror」的 Volume 時,這表示在「不同 Server、不同 Drives」必須維護共「2 份」副本資料,以便 1 份資料損壞時另 1 份仍然可用。所以,雖然建立 1TB Volume 但實際會佔用 2 TB 空間,這樣的行為稱之「Footprint on the Pool」。




什麼是 Slabs?

在建立的 1 TB Volume 儲存空間中,系統將會把它拆解成眾多的「Slab」並且每個 Slab 大小為「256 MB」(在 Windows Server 2016 技術預覽版本時稱為 Extent 大小為 1024 MB) 。因此,倘若建立 1 TB Volume 儲存空間的話便會拆解成「4,000 Slabs」。




什麼是 Striping?

當我們採用 2-Way Mirror 的方式建立 Volume 並且拆解成眾多 Slab 之後,「每個 Slab」將會建立「2 份副本」,然後透過 S2D 演算法分別存放在「不同 Server, 不同 Drives」當中。




因此,原則上眾多 Slabs 將會「平均且分散」的儲存到不同 Server 不同 Drives 當中。同時,預設情況下 Cluster 當中至少會有 5 個 Drive 儲存「Pool Metadata」以便後續「同步」(Synchronized)及「修復」(Repaired)等作業。此外,即便儲存的 Pool Metadata 都遺失,也不會影響 S2D 的部署及運作。






S2D 這樣設計的目的為何?

效能考量

將 Volume 拆解成眾多 Slab 然後平均分散放置到多個儲存媒體時,這樣可以提供「資料讀寫」的效益同時可以使用多個儲存媒體,以期「最大化 IOPS & I/O Throughput」。因此,S2D 的 2-Way Mirror 機制與傳統的 RAID-1 並不相同。



提升資料安全性

當「儲存裝置」發生故障時,原有儲存的資料副本將會在其它位置進行重建,這個行為稱之為「修復」(Repairing) 並執行下列 2 項操作步驟:

修復步驟1、從「存活」的資料副本中讀取 (讀取單位為 Bytes):
  • 想像一下,假設 S2D 沒有把 Volume 拆解成眾多 Slab 的話,那麼當 1TB Volume 副本所在的硬碟損壞時,採用的若是機械式硬碟要進行上述修復程序的第 1 項時,光是讀取 1TB Bytes 資料這個動作,可想而知整個資料重建程序將會非常緩慢!! 
  • 回到 S2D 的運作架構,有顆機械式硬碟損壞裡面存放一堆 Slab,但是這些 Slab 存活的資料副本是分佈在「不同機械式硬碟」中,有的可能在 Drive03、Drive15、Drive17……等。 
  • 重點就是,這個重建的動作可以同時使用到「多顆」機械式硬碟而非「單顆」機械式硬碟!!

修復步驟2、在其它位置寫入「新的」資料副本,以取代遺失的資料副本:
  • 原則上,只要哪裡有儲存空間就往哪裡寫。但是,機械式硬碟損壞的那台伺服器就會不再放置重新的資料副本。
  • 簡單來說,透過 Volume 打散成 Slab 的機制,不但提升資料安全性讓故障事件發生時「Resync」的等待時間縮短。






考量 Reserve Capacity

簡單來說,在你所建立的 Storage Pool 當中,應該要「預留」一些額外的儲存空間而不要都用盡!! 舉例來說,當機械式硬碟故障進行資料副本的修復程序時,才有緩衝的儲存空間可供使用。這個概念有點類似 HDD Hot Spare 但在實際運作上又有點不同。

強烈建議要預留空間,但就算沒有預留儲存空間 S2D 還是能正常運作,只是當「故障事件」發生時倘若沒有預設儲存空間的話將會影響修復速度。






自動建立儲存集區及重新負載平衡

當 S2D 叢集當中加入新的 S2D Node 時,會自動將 Slab 資料副本自動負載平衡到新的 S2D Node 當中,這個動作稱之為「最佳化」(Optimizing)「重新平衡」(Re-Balancing)。例如,在本文 S2D Cluster 中原本只有 3 Nodes 現在加入第 4 台 Node,只要鍵入「Add-ClusterNode -Name <Name>」PowerShell 指令即可。



順利將第 4 台 Node 加入後,「一開始」該 Node 的儲存裝置的使用空間還是空的。



預設情況下,經過「30 分鐘後」 S2D 將會「自動」執行「重新平衡」(Re-Balancing)的動作,但隨著運作規模大小將會需要不同的時間 (例如,幾小時)。倘若,你不希望等待 S2D 自動執行的話,可以手動執行「Optimize-StoragePool -FriendlyName "S2D*"」的 PowerShell 指令讓 S2D 立即執行重新平衡的動作,並且透過「Get-StorageJob」查看重新平衡的工作進度。



因此,當重新平衡作業執行完畢後,可以看到前 3 台 Node 的使用空間「下降」,因為平均且分散放置到第 4 台 Node 的儲存空間。






小結

  • 建立 S2D 的 Storage Pool 之後,無須再針對 Storage Pool 進行調整 (例如,新增 HDD、刪除 HDD……等)或額外再建立 Pool。
  • 建立的 Volume 會拆解成眾多 Slabs,然後平均分散到不同 Server / 不同 Drives。
  • 最好在 S2D Storage Pool 當中「預留」儲存空間,以便故障事件發生時能夠更快的進行修復作業。
  • 當 S2D 建立的 Storage Pool 加入新的 Node 時,會「自動」進行重新平衡的動作,保持資料副本平均分散到不同 Server / 不同 Drives 的原則。
  • 你可以透過「Get-StoragePool S2D*」、「Get-StoragePool S2D* | Get-PhysicalDisk」查看 S2D Storage Pool 相關資訊。
S2D PM「Cosmos Darwin」撰寫的 PowerShell





參考資源


前言

在 VMware VMworld 2016 大會上,由 VMware 執行長 Pat Gelsinger 正式發表 SDDC 軟體定義資料中心願景中最要的運作元件 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出,並且在日前 2016 年 11 月 15 日時 VMware 官方正式宣佈 vSphere 6.5 新版發佈,同時提供相關新版產品映像檔的下載。



站長將不定期撰寫相關新功能簡介文章: (更新文章符號 💩)

【簡介】




【vCenter Server】




【Security】




【Storage】




【VMware Taiwan vSphere 6.5 新功能介紹】


前言

自從 Windows Server 2016 推出後,大家對於 S2D (Storage Spaces Direct) 軟體定義儲存技術一直非常有興趣。甚至,微軟也推出 Project Kepler-47 的輕量型 OEM S2D 解決方案,讓分公司或小型運作環境也能夠享有 S2D 軟體定義儲存技術的好處。本文,將討論在 Windows Server 2016 中的 S2D 軟體定義儲存解決方案中,佔有舉足輕重地位的儲存裝置「SSD 固態硬碟」。



SSD 固態硬碟基礎知識

眾所周知 SSD 固態硬碟具有「資料讀寫壽命」的問題,隨著資料不斷大量的讀取及寫入後即便只是簡單的資料讀取都會有壽命成本的問題,在 SSD 固態硬碟運作環境中這個現象稱之為「讀取干擾 (Read Disturb)」。下列,為常見的 4 種 SSD 固態硬碟類型:

  • SLC: 1 bit per Cell (100,000 or more Write)。
  • MLC: 2 bits per Cell (10,000 ~ 20,000)。
  • TLC: 3 bits per Cell (> 1,000)。
  • QLC: 4 bits per Cell (> 100)。


因此,正確的規劃及選擇 SSD 固態硬碟便更顯現其重要性。那麼,我們來看看 SSD 固態硬碟的存取行為,一般情況下會透過「FTL (Flash Translation Layer)」連接到 NAND Flash 快閃記憶體的內部控制器。同時,FTL 具備下列 2 項機制:
  • 儲存資料時會一起儲存「ECC (Error Correcting Codes)」,當需要恢復資料時便會透過 ECC 機制進行復原的動作。
  • 具備「Over-Provisioning」機制以便超額提供儲存空間。事實上,NAND 是無法直接寫入資料的,必須經過「P/E (Program/Erase)」的處理流程後才能進行寫入資料,每個「Page」的空間最小可達「16 K」。同時,NAND 不會重複寫入同個 Page,然後 FTL 持續追蹤及更新 Erased Pages,並且合併重新寫入的資料區塊以及所對應的 Re-Written Logical Blocks,最終的結果就是 Over-Provisioning。


簡單來說,「NAND Flash SSD」是個複雜且動態的運作環境,必須要整合多項機制才能確保儲存資料的可用性。同時,隨著儲存密度不斷增加的情況下維持資料可用性的難度相形提高,目前為透過「緩衝區 (Buffers)」機制來處理這個部分。同時消費者等級與伺服器等級的 SSD 固態硬碟,在資料可用性的保護機制上也有所不同 :
  • 在「消費者等級」SSD 固態硬碟當中,透過「Volatile Cache」及「電池 (Battery)」機制以確保不會因為意外失去電源而導致資料遺失。
  • 在「伺服器等級」SSD 固態硬碟當中,則透過「電容 (Capacitor)」以提供電源保護機制。


舊式企業級 SSD」(Older Enterprise-Grade SSD),具備可拆卸及更換的「內建電池」提供電源保護機制。


新式企業級 SSD」(Newer Enterprise-Grade SSD),則是使用「電容 (Capacitor)」也就是下圖中 3 顆黃色顆粒裝置以便提供電源保護機制。


那麼,倘若在 S2D 軟體定義儲存的運作環境當中採用「消費者等級 SSD 固態硬碟」時會發生什麼事? 下列,便是採用 1TB SATA SSD (5 年保固)消費者等級的 SSD 固態硬碟進行實驗:
  • QD32 4K Read: 95,000 IOPS
  • QD32 4K Write: 90,000 IOPS
  • 資料儲存耐用性: 185 TB 


根據上述消費者等級的 SSD 固態硬碟效能數據及資料儲存耐用性,我們來估算一下這樣的消費者等級 SSD 固態硬碟其「DWPD (Device Writes per Day)」數值:
  • 185 TB / (365 days x 5 years = 1825 days) = ~ 100 GB writable per day
  • 100 GB / 1 TB total capacity = 0.10 DWPD


首先,透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試:
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Su -D -L -d1800 -Rxml Z:\load.bin

可以看到測試長度為「30 分鐘」,但是從測試數據中可以看到在資料存取不到「3 分鐘」之後 IOPS 突然「下降 10,000 IOPS」,這對於消費者等級的 SSD 固態硬碟來說是非常正常的現象。因為 FTL 已經用完預設準備給 NAND 的寫入空間了,所以導致資料存取速度變得非常的慢,因為整個資料存取動作已經中斷並且必須重新準備。


同樣的工作負載,再次透過 Diskspd 用「8 Threads - QD8 70 (Read):30 (Write) 4KB」的資料讀寫工作負載測試,但是加上「Write-Through」的動作 (參數 -Suw),讓整個 NAND 的延遲時間及 FTL/Buffer 真正顯現出來。從下圖中可以看到,IOPS 效能數據的結果非常差:
diskspd.exe -t8 -b4k -r4k -o1 -w30 -Suw -D -L -d1800 -Rxml Z:\load.bin



結論

因此,在 Windows Server 2016 所建構的 S2D 軟體定義儲存環境中,應該選擇及採用具備「Non-Volatile Write Cache」及「Enterprise-Grade SSD」特性的企業級 SSD 固態硬碟。那麼,該如何確認選擇的企業級 SSD 固態硬碟支援「Non-Volatile Write Cache」機制?
  • 在 DataSheet 中看到「PLP (Power Loss Protection)」字眼,例如,Samsung SM863、Toshiba HK4E…等。
  • 在  DataSheet 中看到「Enhanced Power Loss Data Protection」字眼,例如,Intel S3510、S3610、S3710、P3700…等。




參考資源