Quantcast
Channel: 不自量力 の Weithenn
Viewing all 596 articles
Browse latest View live

117 期 - 微軟最新 S2D 儲存技術,跨伺服器硬碟組成資源池

$
0
0

網管人雜誌

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

文章目錄

1、前言
2、S2D 技術有何不同?
          採用 S2D 技術有何好處?
          S2D 技術的運作架構
          S2D 技術的部署模式
          S2D 技術的資料存放原則及容錯機制
          S2D 技術的容錯機制
3、S2D 實戰 – 硬體需求
          安裝 Windows Server 2016 TP2 或 TP3
          安裝 Hyper-V 並建立虛擬交換器
          安裝 Windows Server 角色及功能
          建立 SOFS 容錯移轉叢集
          啟用 Storage Spaces Direct 機制
          建立 Storage Pool、Virtual Disk、Volume
          建立 SOFS 高可用性角色
          建立 SOFS 檔案分享資源
4、結語

1、前言

Windows Server vNext 為目前 Windows Server 2016 先前的開發名稱,並在 2014 年 10 月 1 日時正式發佈「技術預覽 (Technical Preview,TP)」版本,接著在 2015 年 5 月 4 日發佈 TP2 技術預覽版本。最新版本,則是在 2015 年 8 月 19 日發佈的 TP3 技術預覽版本。

在 Windows Server 2016 TP2 技術預覽版本中,導入許多新的特色功能如 Nano Server、Storage Replica、PowerShell DSC (Desired State Configuration)…等技術。至於,最新版本的 Windows Server 2016 TP3 技術預覽版本中,則主要是新增了 Windows Server Containers 技術在裡面。

本文,要向大家介紹及實作的微軟「軟體定義儲存 (Software-Defined Storage,SDS)」技術,則是內含在 Windows Server 2016 TP2 技術預覽版本當中,它是由 Windows Server 2012 R2 當中的「Storage Space」技術演化而來,在 Windows Server 2016 當中稱之為「Storage Spaces Direct (S2D)」。

事實上,目前的微軟 SDS 技術名稱 Storage Spaces Direct,在 Windows Server vNext 開發時期稱之為「Storage Spaces Shared Nothing」。

2、S2D技術有何不同?

首先,大家一定對於 Windows Server 2016 當中 S2D 軟體定義儲存技術感到好奇,並且極想了解它與 Windows Server 2012 R2 當中的 Storage Space 技術有何不同。簡單來說,最主要的關鍵在於 S2D 技術,可以將多台伺服器的「本機硬碟 (Local Disk)」結合成為一個大的儲存資源池。

在 Windows Server 2012 R2 當中的 Storage Space 技術,底層的儲存資源是採用「共享式JBOD (Shared JBOD)」的方式,將多座 JBOD 結合成為一個大的儲存資源池。然後,再透過其上的 SOFS (Scale-Out File Server)叢集節點,將掛載的 JBOD 儲存資源,透過 SMB 3.0 協定將儲存資源分享給 Hyper-V 容錯移轉叢集。

圖 1、Windows Server 2012 R2 Storage Space 技術運作示意圖

在 Windows Server 2016 TP2 當中的 S2D 技術,則可以直接將原本的 SOFS (Scale-Out File Server) 叢集節點主機中「本機硬碟 (Local Disk)」,透過 RDMA 網路環境將多台 SOFS 叢集節點的本機硬碟資源,結合成為一個大的儲存資源,然後透過 SMB 3.0 協定將儲存資源分享給 Hyper-V 容錯移轉叢集。

圖 2、Windows Server 2016 TP2 S2D(Storage Space Direct) 技術運作示意圖

採用 S2D 技術有何好處?

首先.採用 S2D 技術對於企業或組織的 IT 管理人員來說,最大的好處便是「簡化部署」。因為,採用 S2D 技術之後可以拋開傳統複雜的 SAS 網狀架構 (採用 JBOD 架構的副作用),改為採用相對單純的網路架構即可。

此外,因為省去了 JBOD 硬碟機箱,連帶節省大量的機櫃空間、電力、冷氣…等,這也是額外帶來的效益。因此,現在企業或組織的 IT 管理人員除了不用規劃及組態設定 SAS Cabling 事宜外,也不用安裝及設定 MPIO 多重路徑機制。

圖 3、Windows Server 2012 R2 Storage Space with Shared JBODs 運作示意圖

另一項好處則是可以「無縫式進行擴充」,簡單來說可以達成「水平擴充 (Scale-Out)」的運作架構。現在,IT 管理人員只要增加 SMB 容錯移轉叢集架構中的叢集節點,即可同時增加整體的「儲存空間」以及「傳輸速率」,並且新加入的叢集節點將會自動進行儲存資源的負載平衡作業。

圖 4、Windows Server 2016 TP2 Storage Spaces Direct with Internal Disks 運作示意圖

當然,若企業或組織已經建置 Windows Server 2012 R2 的共享式 JBOD 架構的話,那麼在 Windows Server 2016 當中的 S2D 技術,除了支援本機硬碟成為儲存資源池之外,也支援原有的共享式 JBOD 架構,讓企業或組織可以輕鬆將共享式 JBOD 運作架構,由原本的 Windows Server 2012 R2 升級為 Windows Server 2016。

圖 5、Windows Server 2016 TP2 Storage Spaces Direct with JBOD 運作示意圖

S2D 技術的運作架構

在 S2D 軟體定義儲存技術中,整個運作架構包含了 SOFS (Scale-Out File Server)、CSVFS (Clustered Shared Volume File System)、Storage Spaces、Failover Clustering等技術。那麼,讓我們來看看在相關運作層級中,每個層級所專司的運作角色以及功能為何。

Network:在 S2D 運作架構中,每台 SMB 叢集節點主機是透過支援「RDMA (Remote Direct Memory Access)」功能的網路卡,進行資料傳輸作業。透過採用支援 RDMA 功能的網路卡,可以有效讓 SMB 叢集節點主機能夠達到「高輸送量 (High Throughput)、低延遲 (Low Latency)、低 CPU 使用率 (Low CPU Utilization)」,也就是不會對 SMB 叢集節點主機造成效能影響。

Storage Node: S2D 運作架構至少要由「4台」SMB叢集節點主機所組成,每台節點主機可以採用本機硬碟或共享式 JBOD,至於硬碟的支援度部分除了可以採用 SAS/NL-SAS/SATA 之外,還支援新一代的 NVMe(NVM Express)。

Software Storage Bus:微軟便是透過此「軟體儲存匯流排 (Software Storage Bus)」技術,將眾多 SMB 叢集節點主機當中的本機硬碟,串連成為一個大的儲存資源池,也就是讓所有的硬碟可以座落在同一個 Storage Spaces Layer 之上。

Storage Pool:這是原本在 Windows Server 2012 R2 當中 Storage Spaces 的技術。簡單來說,底層已經透過 Software Storage Bus 技術,將眾多 SMB 叢集節點主機的本機硬碟串連成儲存資源池,接著便可以透過 Storage Pool 技術,針對不同的硬碟介面或顆數進行儲存資源池的建立作業。

Virtual Disks:當建立好 Storage Pool 儲存資源池作業後,便可以建立「虛擬磁碟 (Virtual Disks)」。此時,便可以決定硬碟的容錯等級,例如,採用 2-Way / 3-Way Mirror 方式,以便兼顧硬碟運作效能的同時還能保有資料容錯的特性。

CSVFS:在 S2D 運作架構中,並非採用舊有的 NTFS 檔案系統,而是採用新一代的 ReFS v2檔案系統,並且針對 Storage Space 機制進行優化處理,除了具備 Error Detection、Automatic Correction 機制之外,還針對 VHD/VHDX(Fixed、Dynamic、Merge) 格式進行「加速(Accelerations)」處理。

SOFS:將底層的儲存資源池及高可用性機制處理完成後,最後便是透過「SOFS (Scale-Out File Server)」機制,將儲存資源分享給 VM 虛擬主機、SQL Server...等使用。

圖 6、Windows Server 2016 TP2 Storage Spaces Direct 運作架構示意圖

S2D 技術的部署模式

那麼,我們來看看S2D軟體定義儲存技術有哪些部署模式,以便稍後進行實作時不致發生觀念混亂的情況。在S2D技術中支援兩種部署模式:

  • 超融合式 (Hyper-Converged)。
  • 「融合式 (Converged)」或稱「分類 (Disaggregated)」。

首先,如果採用「超融合式(Hyper-Converged)」部署模式的話,那麼便是將「運算 (Compute)、儲存 (Storage)、網路 (Network)」等資源全部「整合」在一起,適合用於中小型規模的運作架構。

圖 7、S2D 超融合式部署模式運作示意圖

如果,採用「融合式(Converged)」部署模式的話,那麼便是將「運算 (Compute)、儲存 (Storage)、網路 (Network)」等資源全部「分開」進行管理,適合用於中大型規模的運作架構。

圖 8、S2D 融合式部署模式運作示意圖

S2D 技術的資料存放原則及容錯機制

S2D 運作架構在資料存放原則的部分,與過去 Windows Server 2012 R2 稍有不同,最明顯的部分便是「Extent」。現在,建立的 虛擬磁碟(Virtual Disk)其實是由眾多的 Extent 所組成,每個 Extent 的單位大小為「1 GB」,舉例來說,100 GB 大小的虛擬磁碟便是由 100 個 Extent 所組成。

因此,當儲存資源池及虛擬磁碟建立完畢後,便會產生許多 Extent 並且會自動擺放在不同的 SMB 叢集節點主機當中。此外,假設虛擬磁碟為 100 GB 大小所以會有 100 個 Extents,當我們採用 3-Way Mirror 容錯機制時(所以會有 300 個 Extents),那麼系統便會確保第 2、3 份 Extent 擺放在不同台 SMB 叢集節點主機當中,以便因應後續如硬碟故障、SMB 叢集節點主機...等故障損壞事件。

圖 9、S2D 資料存放原則運作示意圖

S2D 技術的容錯機制

當 S2D 軟體定義儲存技術,在達成簡單部署及磁碟效能的同時,當然還要兼顧到資料的容錯機制。在資料的容錯機制方面,它可以有效因應「硬碟 (Hard Disk)、機箱 (Enclosure)、伺服器 (Server)」等發生故障損壞事件。

先前已經提到,S2D 技術最少必須由「4台」叢集節點組合而成,在這樣的運作架構下可以建立 3-Way Mirror 機制,並且可以容許「2台」叢集節點發生故障並且也支援容錯分區機制,也就是說可以支援資料的「放置、修復、重建、負載平衡」等機制,讓線上存取資料的動作能夠不被故障事件所影響並持續運作。

圖 10、S2D 容錯機制運作示意圖

3、S2D 實戰 – 硬體需求

那麼,讓我們來看看若企業或組織的IT管理人員,若要搶先體驗及建置 S2D 軟體定義儲存技術的話,該如何建構 S2D 測試環境:

節點主機:最少必須由 4 台節點主機組成。在 Windows Server 2016 TP2 版本時最多支援 12 台伺服器,在 2016 TP3 版本時最多支援 16 台伺服器。

硬碟控制器:每台節點主機,應該採用 SATA Connected 或 SAS HBA Connected 的連接方式,而非使用 ACHI Controller 或 RAID Controller 的方式。

硬碟數量:每台節點主機,最少應該使用 1 顆 SSD 固態硬碟及 1 顆機械式硬碟。

網路卡:每台節點主機,最少應該使用 1 Port 10GbE 網路,並且必須支援 RDMA 特色功能 (RoCE、iWARP、InfiniBand),目前支援的網路卡廠商有 Mellanox (CX3-Pro)、Chelsio (T5)、Avago/Emulex (Skyhawk)...等。

此外,值得注意的部分是,請只採用 PowerShell來進行 S2D 的「管理」作業,不要使用伺服器管理員 (Server Manager),或是容錯移轉叢集管理員 (Failover Cluster Manager) 來管理 S2D 運作環境,同時 S2D 運作架構並不支援 Microsoft Multipath MPIO Software Stack。

安裝 Windows Server 2016 TP2 或 TP3

因為 S2D (Storage Spaces Direct) 技術,是從 Windows Server 2016 TP2 才開始支援的特色功能,所以請為規劃的節點主機安裝 Windows Server 2016 TP2 或 TP3 版本。

本次實作環境將安裝 Windows Server 2016 TP3 版本,並且也加入以 2016 TP3 版本所架設的網域控制站,當然所有的節點主機都必須加入「同一個」Windows AD 網域才行。

圖11、為節點主機安裝 Windows Server 2016 TP3 作業系統

安裝 Hyper-V 並建立虛擬交換器

本次實作環境為採用 S2D「超融合式 (Hyper-Converged)」部署模式,所以也必須在 SMB 叢集節點主機中安裝 Hyper-V 角色,並且建立虛擬交換器。請在節點主機中,開啟 PowerShell 並鍵入如下指令安裝 Hyper-V 角色,安裝角色完畢後將會重新啟動主機:

Install-WindowsFeature –Name Hyper-V –IncludeManagementTools –Restart

在 Windows Server 2012 R2 時有項限制,也就是採用 RDMA功能的網路卡「無法」建立虛擬交換器,也就是說 RDMA 網卡只能專用於儲存網路而已。現在,在 Windows Server 2016 中已經解除這項限制,你可以為使用 RDMA 網卡建立虛擬交換器,並且啟用「SET(Switch-Embedded Teaming)」機制。

圖 12、RDMA with Switch-Embedded Teaming 運作架構示意圖

值得注意的是,目前主流的 RDMA 協定為 RoCE (RDMA over Converged Ethernet),以及iWARP (Internet Wide Area RDMA Protocol)。若你採用的 RDMA 網卡為 RoCE的話,那麼採用的網路交換器「必須」要支援及啟用「DCB (Data Center Bridging)」才行,雖然採用 iWARP的 RDMA 網卡,無須依賴交換器的 DCB 功能,但普遍來說在支援 DCB 特色功能的網路交換器上運作,可以更容易透過 DCB 功能達到 QoS 網路流量的目的。

請在節點主機中依序鍵入下列指令,以便指派 RDMA 網卡建立虛擬交換器,同時啟用及確認是否啟用 RDMA 功能。

PS C:\> Add-VMNetworkAdapter SwitchName S2DSwitch Name RDMA1
PS C:\> Add-VMNetworkAdapter SwitchName S2DSwitch Name RDMA2
PS C:\> Enable-NetAdapterRDMA "vEthernet (RDMA1)","vEthernet (RDMA2)"
PS C:\> Get-NetAdapterRdma
Name                  InterfaceDescription                      Enabled
-------               -------------------------                 ----------
RDMA1 (S2DSwitch)     Hyper-V Virtual Ethernet Adapter #7       True
RDMA2 (S2DSwitch)     Hyper-V Virtual Ethernet Adapter #7       True
SLOT3                 Mellanox ConnectX-3 Pro Ethernet Adapter  True
SLOT2                 Mellanox ConnectX-3 Pro Ethernet Adapter  True


安裝 Windows Server 角色及功能

請為每一台節點主機,鍵入如下 PowerShell 指令,以便安裝「檔案伺服器 (File-Services)」角色,以及「容錯移轉叢集 (Failover-Clustering)」功能,並包含相關管理工具。

Install-WindowsFeature –Name File-Services, Failover-Clustering –IncludeManagementTools

建立 SOFS 容錯移轉叢集

在建立 SOFS 容錯移轉叢集運作環境前,先進行容錯移轉叢集的驗證動作。此實作環境中,四台節點主機的電腦名稱為「S2D-Node <編號 1~4>」,因此請鍵入如下 PowerShell 指令進行叢集環境的驗證動作。

Test-Cluster -Node S2D-Node1,S2D-Node2,S2D-Node3,S2D-Node4 -Include "Storage Spaces Direct",inventory,Network,"System Configuration"

此外,若使用「-Include "Storage Spaces Direct"」參數時,那麼容錯移轉叢集的驗證程序便會測試共享儲存,造成叢集驗證程序發生警告或錯誤的情況。

容錯移轉叢集驗證無誤後,接著在建立容錯移轉叢集之前,請先確保每台 S2D-Node 中沒有任何硬碟被「宣告 (Claimed)」使用(例如,硬碟若被格式化過為 MBR、GPT...等),若硬碟已經被使用過的話,請先以 Diskpart 指令確認硬碟編號,然後就可以使用 Clear-Disk 的 PowerShell 來清掃硬碟中所有的內容。 (請注意!! 硬碟必須為 Online 狀態下,那麼 Clear-Disk 指令才能順利清掃硬碟內容。)

Clear-Disk  –Number 1  -RemoveData  -RemoveOEM         //處理單顆硬碟
Clear-Disk  –Number 1,2,3,4  -RemoveData  -RemoveOEM   //一次處理多顆硬碟


執行完 Clear-Disk 動作後,硬碟的狀態應恢復到「Unknown、Not Initialized、Unallocated」才是正確狀態。請注意 !! 若硬碟未呈現正確狀態的話,稍後啟動「Software Storage Bus」機制時,將無法順利把節點主機的本機硬碟加入至儲存資源池中。

圖 13、將硬碟回到未宣告狀態,以利後續加入至儲存資源池中

前置作業都完成後,便可以放心建立容錯移轉叢集。此實作環境中叢集名稱為「S2D-FC」,而容錯移轉叢集IP位址為「192.168.250.106」,請鍵入如下 PowerShell 指令建立容錯移轉叢集。(請注意!! 執行建立容錯移轉叢集的 PowerShell 指令後,若出現「There were issues while creating the clustered role that may prevent it from starting. For more information view the report file below」警告訊息的話,可以放心忽略它。)

New-Cluster –Name S2D-FC -Node S2D-Node1,S2D-Node2,S2D-Node3,S2D-Node4 –NoStorage –StaticAddress 192.168.250.106

圖 14、建立 S2D 容錯移轉叢集

啟用 Storage Spaces Direct 機制

當容錯移轉叢集順利建立完成後,便可以使用 PowerShell 指令「啟用 Storage Spaces Direct 機制」,這個動作就是設定容錯移轉叢集啟用「Software Storage Bus」特色功能。

(Get-Cluster).DASModeEnabled=1      //For Windows Server 2016 TP2
Enable-ClusterStorageSpacesDirect   //For Windows Server 2016 TP3


當順利啟用 Storage Spaces Direct 機制後,此時四台節點主機規劃加入儲存資源池的硬碟,便會全部消失在磁碟管理員視窗中,並且出現在「Failover Cluster Manager > Storage > Enclosures」項目內。此實作環境中,每台節點主機共有 1 顆 100 GB 的 SSD 固態硬碟以及 900 GB 的 SAS 硬碟。

圖 15、啟用 Storage Spaces Direct 機制

建立 Storage Pool、Virtual Disk、Volume

接著,就是大家所熟悉的 Storage Space 技術操作流程,也就是依序建立「Storage Pool > Virtual Disk > Volume」。值得注意的是,目前在 Windows Server 2016 技術預覽版本中,有下列相關限制:

1. 必須要「停用」WBC (Write Back Cache)機制。
2. 設定 SSD 固態硬碟採用「日誌(Journal)」模式。
3. 「停用」ReFS 檔案系統中 Volume 的 Integrity Streams 功能。
4. 目前建立出來的 Volume 不支援「Resizing」功能。

建立 SOFS 高可用性角色

完成後,便可以建立 SOFS 高可用性角色,以便稍後以 UNC Path 的方式結合 SMB 3.0 協定,分享檔案資源給 Hyper-V 中的 VM 虛擬主機使用。值得注意的是,SOFS 高可用性角色的名稱請不要超過「15 個字元」。

New-StorageFileServer  -StorageSubSystemName S2D-WSFC  -FriendlyName S2D-SOFS  -HostName S2D-SOFS  -Protocol SMB

建立 SOFS 檔案分享資源

最後,便是建立 SOFS 檔案分享資源。值得注意的部分是,這個 SOFS 檔案分享資源的權限部分,必須要確保「Hyper-V 主機、Hyper-V 管理者帳號、Hyper-V 叢集」這三者都要具備「Full Control」的權限,否則屆時建立 VM 虛擬主機時將會因為權限問題而導致建立失敗。

在加入 Hyper-V 主機及 Hyper-V 叢集名稱時,記得結尾必須加上「$」符號,舉例來說,若 Hyper-V 主機名稱為 HV-Node1 的話,那麼名稱便為「HV-Node1$」。請注意,必須採用 PowerShell 指令進行設定,若是在容錯移轉叢集管理員中進行權限設定將會發生設定錯誤的情況。

圖 16、建立 SOFS 檔案分享資源

4、結語

至此,S2D 軟體定義儲存的運作環境已經建構完成,企業及組織的IT管理人員可以嘗試將測試用途的 VM 虛擬主機,建立在 S2D 儲存資源當中,以便確認是否符合企業營運服務的運作要求。

事實上,在今年 5 月份的微軟 Ignite 大會上,已經展示透過 4 台節點主機所建立的 S2D 軟體定義儲存運作環境,其磁碟效能已經高達「110 萬 IOPS」,而在今年 8 月份 Intel IDF 大會上,微軟也展示由 16 台節點主機所建立的 S2D 軟體定義儲存運作環境,每台節點主機僅用4顆硬碟便可以打造出高達「420 萬 IOPS」的磁碟效能。此外,相信在 2016 年正式推出的Windows Server 2016,將有更高的運作效能以及更簡便的設定步驟才是。

翻譯 - 實戰 Azure 混合雲|基礎架構 x 高可用性 x 災難復原

$
0
0

書籍簡介

本書將帶領你探索雲端運算,以及 Microsoft Azure IaaS(Infrastructure as a Services)的全部功能,我們將一步一步帶領你,從企業內部資料中心的私有雲環境連接到 Azure 公有雲環境,並輔以詳細的使用案例以便說明如何建置及管理微軟混合雲運作環境。

從如何設定 Azure Site-to-Site VPN 連接開始,一直到如何手動及自動建立 VM 虛擬主機及網路。本書將教導你如何將企業內部的 Windows Server 及 System Center 連接到 Azure 環境,除了展示 Azure 的功能之外,也將同時說明你所期望的功能以及尚未正式發佈的新功能,以便讓你了解如何透過 Azure讓企業或組織獲得最大效益。

本書所討論的議題包括

  • 了解雲端運算當中,從部署到服務模型的每個層面。
  • 深入了解VM虛擬主機、網路、Azure儲存體。
  • 如何與Azure環境建立安全連線。
  • 管理Azure環境中的 VM 虛擬主機及網路架構。
  • 深入探索如何透過Azure備份企業內部的VM虛擬主機,並在需要時進行災難復原流程。
  • 遷移實體主機、VMware、Hyper-V、Amazon VM虛擬主機至Azure運作環境。
  • 了解及學習即將推出的Azure新功能。


網路購書


本書導讀

  • 第 1 章、簡介雲端運算,介紹雲端運算的概念並且比較雲端環境中各種應用情境及使用案例。
  • 第 2 章、簡介微軟雲端解決方案,概述微軟雲端解決方案中建立混合雲的部分。
  • 第 3 章、了解 Microsoft Azure 運作架構, 在本章中將詳細說明 Azure 雲端服務的底層運作架構,以及相關的組成元件及運作原理。
  • 第 4 章、在 Microsoft Azure 上建立基礎架構, 將說明在 Azure 運作環境中,如何建立你的第 1 台 VM 虛擬主機、儲存體、虛擬網路環境。
  • 第 5 章、連接至 Microsoft Azure, 將企業內部運作環境與 Azure 資料中心進行連接。
  • 第 6 章、管理微軟混合雲架構, 在本章中將向你展示如何針對 Azure Active Directory 進行管理,並介紹如何透過 PowerShell 達成自動化任務。
  • 第 7 章、使用 Microsoft Azure 達成高可用性、保護及災難復原, 說明如何透過 Azure 相關機制,達成保護企業內部及運作在 Azure 環境中的伺服器及服務。
  • 第 8 章、遷移至 Microsoft Azure, 說明如何順利遷移伺服器至 Azure 運作環境等實用工具。
  • 第 9 章、總結,展望不久的將來,總結本書並展望未來的 Azure。
  • 附錄-組態配置最大值,提供 Microsoft Azure 運作環境中組態配置最大值資訊。

VMware China vForum 2015 簡報開放下載

$
0
0

前言

日前,在 China 舉辦的 VMware China vForum 2015簡報已經開放下載了,有興趣的朋友可以參考看看。

資料下載

10月28日

分会场一 » 自动化云管理

分会场二 » IT转型

分会场三 » 关键应用虚拟化

分会场四 » 企业移动化管理

分会场五 » 桌面转型

分会场六 » 软件定义的数据中心

10月29日

分会场一 » 自动化云管理

分会场二 » IT转型

分会场三 » 关键应用虚拟化

分会场四 » 企业移动化管理

分会场五 » 桌面转型

分会场六 » 软件定义的数据中心

Hyper-V 虛擬化實戰課程 - 基礎 / 進階

$
0
0

活動簡介

透過新一代 Hyper-V 3.0 R2 虛擬化技術,建置一套具備 高可用性、可隨時動態遷移、彈性化虛擬架構其實很簡單,但是要建置完整的虛擬化架構仍有許多方面需要考量例如 完整機房環境、穩定可靠的備援電力、機房空調溫濕度、虛擬化技術軟體授權費用…等因素,在本課程當中也都適時的提醒學員。

為了使學員能夠實作出各項進階內容,本課程將特別說明及演練如何藉由「Nested Virtualization」的概念,搭建出「Hyper-V in a Box」多層虛擬化運作環境(VM 再生出 VM),因此只要一台 PC主機便可實作出所有進階內容例如  即時遷移(Live Migration)、儲存即時遷移(Live Storage Migration)、無共用儲存即時遷移(Shared-Nothing Live Migration)、SMB 3.0、Hyper-V 複本異地備援(Hyper-V Replica)、重複資料刪除 (Data Deduplication)…等,在本課程中都有詳盡的說明及實作,以方便您評估新一代 Hyper-V 3.0 R2 虛擬化技術平台。


活動資訊

時間: 09:00 ~ 17:00
地點:資策會 - 資訊技術訓練中心 (台中市公益路二段 51 號 20 樓)
日期:


課程大綱

基礎班

  • Hyper-V 虛擬化平台最佳硬體規劃
  • 虛擬化實作環境建置(Nested VMs、TechNet Virtual Lab)
  • Windows Server 2012 R2 運作模式切換
  • 新世代 VM 虛擬主機特色新功能
  • 計畫性停機解決方案
  • 即時遷移 (Live Migration)
  • 儲存即時遷移 (Live Storage Migration)
  • 無共用儲存即時遷移 (Shared-Nothing Live Migration)
  • 異地備援解決方案
  • 測試容錯移轉
  • 計畫性容錯移轉
  • 非計畫性容錯移轉
  • 延伸複寫
  • 重複資料刪除
  • 備份/還原 VM 虛擬主機

進階班

  • Hyper-V 虛擬化平台最佳硬體規劃
  • 建立 IP Storage(以 iSCSI Target 為例)
  • 設定 iSCSI Initiator 多重路徑 MPIO 機制
  • 建置容錯移轉叢集(Failover Cluster)
  • 啟用叢集共用磁碟區快取(CSV Cache)
  • 啟用共用虛擬硬碟(Shared VHDX Disk)
  • 計畫性停機解決方案
  • 即時遷移(Live Migration)
  • 儲存即時遷移(Live Storage Migration)
  • 無共用儲存即時遷移(Shared-Nothing Live Migration)
  • 非計畫性停機解決方案
  • 受保護的網路(Protected Network)
  • 快速遷移(Quick Migration)
  • 異地備援解決方案
  • 延伸複寫
  • 測試容錯移轉
  • 計畫性容錯移轉
  • 非計畫性容錯移轉
  • 監控應用程式健康狀態(VM Monitoring)
  • 叢集感知更新(CAU)
  • VM 虛擬主機反關聯性(Anti-Affinity)

118 期 - VMware vSphere 6.0 效能調校最佳實務

$
0
0

網管人雜誌

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

文章目錄

1、前言
2、實體伺服器(Hardware Server)
          CPU - 硬體輔助虛擬化(VT-x / AMD-V)
          Memory - 硬體輔助虛擬化(EPT / NPT)
          IO - 硬體輔助虛擬化(VT-d / AMD-Vi)
          實體記憶體(Memory)
          儲存設備(Storage)
          網路卡(Network Adapter)
          BIOS 設定
3、ESXi / VM 基礎效能調校
          ESXi – 電力配置優化
          ESXi – 啟用 CBRC 讀取快取機制
          VM – 啟用硬體輔助虛擬化技術
          VM – 啟用 vNUMA
          VM – 安裝 VMware Tools
4、結語

1、前言

VMware 官方在 2001年 3 月時,發佈 VMware ESX Server 1.0企業級虛擬化平台。經過 14 年的演變時至今日,VMware 於 2015年 3 月正式推出最新版本 VMware vSphere ESXi 6.0

在 2004 年所發表,最知名的 VMotion 即時遷移技術(在 vSphere 4.1 版本後改稱為 vMotion),演化至今除了能夠跨越不同的 vCenter Server 伺服器之外,更可以跨越地域的限制,只要執行遷移的網路環境,能支援封包延遲時間在 100ms之內,那麼就能達成跨越地域限制的 vMotion 即時遷移。

圖 1、VMware vSphere 跨越 Cluster 遷移運作示意圖

雖然,VMware vSphere ESXi 虛擬化平台不斷改善,可支援非常大的硬體資源。但是,當採用了硬體架構規劃不當的實體伺服器,除了耗損不必要的功率之外也將造成效能不佳的結果。

因此,本文將以最新版本的 VMware vSphere 6.0為運作架構進行探討,從底層實體伺服器的規劃開始,該如何選擇 CPU、Memory、Storage、Network等虛擬化資源四大元件,接著逐步深入到 ESXi 虛擬化平台及 VM 虛擬主機...等,以期達到建構硬體效能最佳實務。

2、實體伺服器(Hardware Server)

在企業或組織要採購擔任虛擬化平台的實體伺服器之前,應該先參考 VMware HCL 硬體相容性指南網站,以便了解所採購的實體伺服器是否正確支援 ESXi 虛擬化平台,確保後續實作進階功能,例如,VMware vMotion、DRS、DPM、Fault Tolerance...等能順利運作,不會因為原生硬體功能不支援而無法實作的困境。

首先,請選擇具備更多定址空間的 64 位元 CPU 及更高容量的 L2/L3/L4 快取。同時,若運作在 ESXi 虛擬化平台上的 VM 虛擬主機,並非強調 2D/3D繪圖功能 VDI 虛擬桌面的話,那麼在採購時便不需要追求處理器的「時脈(Clock Rate)」部分,而應該著重在 CPU 處理器的「核心(Cores)」數量方面,以便有效承載更多 VM 虛擬主機提高伺服器合併比率。

此外,除了應該確保硬體資源是否符合最低運作需求之外,在採購的實體伺服器到貨後在正式上線服務前,至少應燒機 72 小時以確保伺服器各項硬體元件皆運作正常。

CPU - 硬體輔助虛擬化(VT-x / AMD-V)

雖然 VMware 原生就支援「二進位轉譯(Binary Translation,BT)」技術,所以即便實體伺服器不支援「硬體輔助虛擬化技術(Hardware-assisted Virtualization,HV)」,仍然能在虛擬化平台上運作VM虛擬主機,但是僅限運作 32 位元作業系統並且將會影響運作效能。

因此,在選購擔任虛擬化平台的實體伺服器時,請選擇支援 CPU 硬體輔助虛擬化技術的中央處理器,以便透過硬體輔助虛擬化技術直接運作 VMM(Virtual Machine Monotor),有效率的提供給 VM 虛擬主機相對應的工作負載。

  • Intel 處理器:VT-x(Virtualization Technology)
  • AMD 處理器:AMD-V(Virtualization)


圖 2、Intel VT-x 硬體輔助虛擬化技術運作示意圖

Memory - 硬體輔助虛擬化(EPT / NPT)

解決虛擬化平台 CPU 工作負載的難題後,接著便是解決實體伺服器記憶體區塊、虛擬化平台記憶體區塊、VM 虛擬主機記憶體區塊,這三者之間快速對應且減少耗損的難題。

因此,在選擇實體伺服器的 CPU 處理器時,應挑選支援 MMU(Memory Management Unit)硬體輔助虛擬化技術。簡單來說,支援 MMU 硬體輔助虛擬化技術的 CPU 處理器,運作在虛擬化環境時將會透過 TLB(Translation Lookaside Buffer)機制,讓 VMM(ESXi)採用「陰影分頁技術(Shadow Page Tables)」機制,將 VM 虛擬機器的記憶體區塊對應到實體伺服器的記憶體區塊,有效減少 vSphere ESXi 虛擬化平台維護實體/虛擬記憶體區塊的工作負載,進而提升主機整體工作效率。

  • Intel 處理器:EPT(Extended Page Tables)
  • AMD 處理器:NPT(Nested Page Tables)或 RVI(Rapid Virtualization Indexing)


圖 3、Intel VT-x 硬體輔助虛擬化技術運作示意圖

IO - 硬體輔助虛擬化(VT-d / AMD-Vi)

最後,則是解決 I/O 快速對應且減少耗損的難題。因此,在選擇實體伺服器的 CPU 處理器時,應挑選支援 I/O MMU 硬體輔助虛擬化技術。

簡單來說,支援 I/O MMU 硬體輔助虛擬化技術的 CPU 處理器,運作在虛擬化環境時能夠有效處理 I/O DMA 傳輸及裝置中斷作業,也就是讓VM虛擬主機可以「直接存取(Direct Access)」伺服器硬體資源,例如,網路卡(VT-d、SR-IOV)...等,讓 VM 虛擬主機達到「原生(Native)」般的效能。

  • Intel 處理器:VT-d(Virtualization Technology for Directed I/O)
  • AMD 處理器:AMD-Vi(I/O Virtualization)或 IOMMU


圖 4、未支援 I/O 虛擬化(左圖)、Intel VT-d 硬體輔助虛擬化技術運作示意圖(右圖)

實體記憶體(Memory)

首先,應該要選擇支援 NUMA(Non-uniform memory access)架構的實體伺服器,以避免 CPU 處理器與實體記憶體之間的資料存取行為,因為跨越 NUMA 節點存取發生匯流排頻寬不足的問題導致存取發生瓶頸。

值得注意的是,當你採用支援 NUMA 運作架構的實體伺服器時,應該要將實體記憶體平均分配給每個 NUMA 節點,以避免因為某個 NUMA 節點記憶體空間不足,再次發生 CPU 處理器需要跨 NUMA 節點進行記憶體空間的存取。

圖 5、NUMA 架構運作示意圖

此外,VMware 虛擬化平台雖然擁有 TPS(Transparent Page Sharing)、Memory Ballooning、Memory Compression...等記憶體優化機制。但是,當您將為數眾多的 VM 虛擬主機運作在虛擬化平台上,且 ESXi 虛擬化平台記憶體優化機制都用盡但記憶體資源仍不足時,此時便會執行「Swapping」的動作(就像是 Windows 作業系統執行 Pagefile 的動作一樣),雖然暫時能因應記憶體空間的不足,讓 VM 虛擬主機能保持運作,但是將直接影響 VM 虛擬主機的運作效能。

因此,從 vSphere ESXi 5.0版本開始,您可以規劃將 ESXi SWAP File 儲存在效能接近記憶體的 SSD 固態硬碟當中(支援 PCIe Flash Card、SAS/SATA SSD),同時還能結合 vFRC(vSphere Flash Read Cache)機制協同運作,以便虛擬化平台即使因記憶體資源不足產生 SWAP 時,仍能保持高效能的運作效率(請參考 VMware KB 2059285KB 2051647KB 2058983)。

圖 6、vFRC(vSphere Flash Read Cache)機制運作示意圖

儲存設備(Storage)

四大實體資源(CPU、Memory、Storage、Network),我們已經規劃好 CPU 及 Memory 的部分,接著另一個重要的環節就是「儲存設備(Storage)」。

目前,伺服器支援多種硬碟種類 SATA、NL-SAS、SAS、SSD、NVMe,而硬碟轉速也有 7200、10,000、15,000 RPM 等差別,磁碟陣列類型也有 RAID10、5、6...等,這些環節都會影響儲存資源整體的 IOPS(Input/Output Operations Per Second)效能表現。

簡單來說,儲存資源 IOPS 便是總合了 Random Read/Write以及 Sequential Read/Write的整體表現,在測試 IOPS 效能數據時 Sequential 的結果會比較亮眼,但是在實務上應用程式的資料存取行為通常為 Random Read/Write

此外,IOPS 效能並非只有硬碟介面及磁碟陣列模式會影響,還有包含其它快取機制在內,舉例來說,當伺服器安裝的磁碟陣列卡(RAID Card),加裝「快取(RAID Card Memory)」及「智慧型電池 (Battery Backup Unit,BBU)」之後,便能開啟資料「寫入快取 (Write Cache with BBU)」機制,這樣的快取機制能有效降低磁碟陣列模式,所導致的資料寫入效能處罰影響。

經過實務測試的結果,同一台實體伺服器同一片磁碟陣列卡,在加裝快取及BBU智慧型電池之後,啟用或停用寫入快取(Write Cache with BBU)後,在 IOPS 效能表現上大約會有「5倍」的差距。

圖 7、啟用或停用寫入快取,在 IOPS 效能表現上大約有 5 倍的差距

在儲存設備的選購上,應該選擇採購支援 vSphere Storage APIs(VAAI 及 VASA)功能,也就是具備硬體加速功能的儲存設備。

VAAI(vSphere Storage APIs-Array Integration)的部分,透過「Full Copy / Copy Offload」機制,可以有效減少 ESXi 在資料複製作業上的工作負載,例如,Storage vMotion,而 Block Zeroing 機制除了可以加快 Eager Thick Disk 的產生時間之外,對於 Lazy Thick Disk 及 Thin Disk 虛擬磁碟來說,可以有效提升 Write I/O的效能表現。

VASA(vSphere Storage APIs-Storage Awareness)的部分,當 VM 虛擬主機儲存在支援VVols(Virtual Volumes)技術的儲存設備時,若需要進行複製作業的話系統便會透過 VASA API,執行 cloneVirtualVolume的硬體式卸載動作進行處理。

此外,VAAI 及 VASA 卸載機制可以互相協同運作。舉例來說,當需要把啟用 VAAI 的 VMFS Datastore 內的資料,複製到 VVols(Virtual Volumes)當中進行資料交換時,將會使用 XCOPY VAAI 卸載機制來加速整個資料複製作業。

圖 8、VAAI、VASA 運作架構示意圖

網路卡(Network Adapter)

針對虛擬化環境中使用的網路卡方面,應盡量挑選可降低實體伺服器 CPU 工作負載的網路卡,例如,支援 Checksum Offload、TSO(TCP Segmentation Offload)、LRO(Large Receive Offload)、RSS(Receive Side Scaling)...等卸載功能。

圖 9、網路卡支援 LRO 技術 VM 虛擬主機可傳輸更大的網路流量

在網路卡選擇上應該選單埠(Single Port)、2 埠(Dual Port)或 4 埠(Quad Port)? 若實體伺服器 PCIe Slot 足夠的情況下,建議採用單埠(Single Port)的比較適合,並且當採用單埠 10Gb/s 網路卡時,應安裝在 PCIe x8 或 PCI-X 266 的插槽上,若採用雙埠 10Gb/s 網路卡時,則應該安裝在 PCIe x16,若採用 40Gb/s 網路卡則至少要安裝在 PCI Gen3 x8/x16 插槽上,這樣規劃的主要原因便為了避免傳輸瓶頸卡在 PCIe Slot 匯流排。

值得注意的是,應該要避免使用 Bridge Chip的情況,例如,將 PCI-X 轉換為 PCIe,或將 PCIe 轉換為 PCI-X。因為這樣的轉換動作,將會造成屆時運作效能降低。

在網路卡與網路交換器之間的傳輸線材也值得注意,以前企業或組織網路環境中常用的 10/100/1000Base-T 線材 Cat 5e,最大傳輸只能達 1Gbps 而已(請注意 !! Cat 5線材只能到達 100Mbps)。因此,若需要提升至 10Gbps 網路環境的話,除了實體伺服器的網路卡及網路交換器之外,傳輸線材也至少應採用 Cat 6aCat 7 等級的纜線(請注意 !! Cat 6並無法符合 10Gbase-T 環境需求),才能達成在 10Gbase-T 網路環境中 100 公尺的最大理論傳輸距離。

BIOS 設定

首先,你應該先跟購買硬體伺服器的廠商確認,目前載入硬體伺服器中的 BIOS 版本已經是最新且穩定的版本。同時,若是升級 BIOS 版本的話則應該要再次檢查 BIOS 設定,因為很可能因為升級的關系導致 BIOS 設定被「重設(Reset)」了。

在實體伺服器 CPU 處理器的部分,我們已經選購支援硬體輔助虛擬化技術(VT-x、AMD-V、EPT、NPT),但是在 BIOS 當中也必須「啟用(Enabled)」特色功能才行,以採用 Intel CPU 的伺服器來說,通常在 BIOS 設定畫面中會看到「Virtualization Technology」項目,若採用 AMD CPU 的伺服器則為「AMD Virtualization」項目。

圖 10、BIOS 啟動硬體輔助虛擬化技術(VT-x / EPT / AMD-V / NPT)

若採用的實體伺服器 CPU 處理器支援 I/O 硬體輔助虛擬化技術(VT-d、AMD-Vi),也請在 BIOS 中「啟用(Enabled)」特色功能,以採用 Intel CPU 的伺服器來說,在 BIOS 設定畫面中將看到「Intel VT-d」項目,若採用 AMD CPU 的伺服器則會看到「AMD-Vi (IOMMU)」項目。

圖 11、BIOS 啟動硬體輔助虛擬化技術(VT-d、AMD-Vi)

HT(Hyper-Threading)」項目則視虛擬化運作環境需求後,由管理人員自行決定是否啟用或停用,因為 HT 機制雖然會將目前的核心數量提升一倍,但因為並非真正的運算核心(僅為邏輯運作),所以當多線程的應用程式要進行 SMP 平行運算時,可能會流生反效果讓運作效能更差。建議若運作的 VM 虛擬主機為企業服務(例如,SQL Server、Exchange Server),則應該「停用(Disabled)」HT 功能,但若是運作 VDI 虛擬桌面的話則建議「啟用(Enabled)」HT 功能。

圖 12、管理人員視虛擬化運作環境需求自行決定是否啟用或停用 HT 功能

若想要讓 ESXi 虛擬化平台保持在最高效率的運作狀態上,請將 BIOS 當中的 Intel Turbo Boost AMD Core Performance Boost項目進行「啟用(Enabled)」。

圖 13、啟用 CPU 加速機制以保持最高效率的運作狀態

同樣的,當實體伺服器支援 NUMA 運作機制,除了實體記憶體應該平均分配之外,在 BIOS 中設定名稱為「Node Interleaving」,不同的是此項目必須設定為「停用(Disable)」才是啟用 NUMA 機制,該項目若設定為啟用(Enabled)反而是停用 NUMA 機制。

圖 14、將 Node Interleaving 項目設定為 Disabled 以啟用 NUMA 機制

在 BIOS 的電力設定部份,建議設定為「最高效能(High Performance)」,以保持實體伺服器在最高效率的運作狀態,或者設定為「OS Controlled Mode」將電力控制權交給 ESXi 虛擬化平台。

圖 15、電力設定調整為 High Performance 以保持最高效率的運作狀態

最後,則將實體伺服器上通常用不到的週邊裝置,直接在 BIOS 層級就停用以避免不必要的硬體資源浪費:

  • COM / LPT Ports
  • Floppy / CD / DVD Drives
  • USB controllers / USB Network Interfaces


3、ESXi / VM 基礎效能調校

在實體伺服器方面,我們選擇支援硬體輔助虛擬化技術後,當 VMware vSphere ESXi 虛擬化平台安裝完畢後,便能同時運作多台 VM 虛擬主機並有效率的共享底層硬體資源,並且也能將實體伺服器的虛擬化技術,傳遞給其上運作的 VM 虛擬主機例如,vNUMA、硬體輔助虛擬化技術...等。

ESXi – 電力配置優化

我們已經將實體伺服器的 BIOS 電力設定為最高效能,但是預設情況下 VMware vSphere ESXi 虛擬化平台的電源設定為「平衡(Balanced)」,也就是自動在運作效能及電力損耗之間取得一個平衡點。

因此,我們應該要將 ESXi 主機的電源計劃調整為「高效能(High Performance)」,此時便會觸發實體伺服器的 Intel Turbo BoostAMD Core Performance Boost 硬體加速技術,讓實體伺服器維持在最佳效率狀態(詳細資訊請參考 VMware KB 1018206)。

圖 16、將 VMware vSphere ESXi 電源計劃調整為高效能(High Performance)

ESXi – 啟用 CBRC 讀取快取機制

事實上,從VMware vSphere ESXi 5.0版本開始,便原生支援 ESXi Host Caching 機制「CBRC(Content-Based Read Cache)」,此快取機制是從實體伺服器中切出一塊實體記憶體空間(最大支援至 2 GB),達成降低 ESXi 儲存資源的 Read I/O Requests工作負載。

請開啟 vSphere Web Client 連接至 vCenter Server 後,依序點選【Hosts and Clusters > ESXi Hosts > Manage > Settings > System > Advanced System Settings】項目,便可以進行 CBRC 快取機制的設定。

在 CBRC 讀取快取機制設定視窗中,相關欄位的參數值設定及項目說明如下:

  • CBRC.DCacheMemReserved:預設值為 400(單位為 MB),此欄位為設定從 ESXi 主機中,切出多少實體記憶體空間給 CBRC 讀取快取機制使用,最小數值為 100 最大則為 2048。
  • CBRC.DCacheSize:預設值為 2048(單位為 MB),設定 CBRC Data Cache 總空間大小。
  • CBRC.DigestJournalBootInterval:預設值為 10(單位為分鐘),在不影響 VM 虛擬主機啟動(Power On)作業情況下將延遲 10 分鐘後,才會啟動 Digest Journal 機制(保持預設值即可)。
  • CBRC.Enable:預設值為 false,決定是否要「啟用(True)」Digest Reserved Cache Memory 快取機制。


圖 17、啟用 CBRC 讀取快取機制及設定 CBRC 快取空間大小

VM – 啟用硬體輔助虛擬化技術

當實體伺服器支援硬體輔助虛擬化技術後,那麼在 ESXi 虛擬化平台上的 VM 虛擬主機,若有需要的話也可以透過 ESXi 傳遞硬體輔助虛擬化技術進行使用。

請開啟 vSphere Web Client 連接至 vCenter Server 後,依序點選【Hosts and Clusters > VM Settings > Virtual Hardware > CPU > CPU/MMU Virtualization】項目,便可以進行傳遞硬體輔助虛擬化技術給 VM 虛擬主機的動作。

圖 18、傳遞硬體輔助虛擬化技術給 VM 虛擬主機

VM – 啟用 vNUMA

同樣的,當實體伺服器採購支援 NUMA 架構時,在虛擬化平台上的 VM 虛擬主機也可以正確感知 NUMA 架構,進而將 vCPU/vRAM 運作在同一個 NUMA 節點當中,以便增強運作效能。

在 vNUMA 設定的 vCPU 數量,則應該參考實體伺服器的核心數以倍數進行設定,舉例來說,假設實體伺服器每顆 CPU 處理器具備 6 Cores 的話,那麼 vCPU 的設定便以 6 為倍數進行設定,例如,6 vCPUs、12 vCPUs、18 vCPUs、24 vCPUs...等。

請開啟 vSphere Web Client 連接至 vCenter Server 後,依序點選【Hosts and Clusters > VM Settings > VM Options > Advanced > Configuration Parameters > Edit Configuration】項目,便可以進行 vNUMA 及 vCPU 數量設定。(請注意!! 當 VM 虛擬主機啟用 vNUMA 機制後,那麼 Hot Add vCPU/Memory的功能將會自動停用。)

圖 19、VM 虛擬主機啟用 vNUMA 機制及設定 vCPU 數量

VM – 安裝 VMware Tools

在 VMware vSphere ESXi 虛擬化平台上運作的 VM 虛擬主機,都應該安裝 VMware Tools,除了將相關虛擬裝置進行最佳化之外,也與 ESXi Hypervisor 進行最緊密的結合。

圖 20、VM 虛擬主機應安裝並確保 VMware Tools 正常運作

4、結語

希望透過本篇文章的說明及討論,能為企業或組織在評估導入虛擬化平台之前,在實體伺服器的硬體元件規格及特色功能的選擇方面能提供良好建議。同時,針對 ESXi 虛擬化平台及 VM 虛擬主機方面,也提供基礎效能調校的建議方針,期望為讀者帶來虛擬化架構在規劃上及優化調校方面上的概念。

翻譯 - Active Directory 環境的 PowerShell 活用指南

$
0
0

書籍簡介

本書是專為管理 Windows Active Directory 基礎架構的 IT 專業人士所寫。書中內容,對於管理 Active Directory 基礎架構的營運團隊,以及支援中心的技術服務人員來說非常有用。透過本書深入淺出的 PowerShell 範例演練,將有助於你輕鬆掌握目前所管理的 AD 基礎架構。此外,即便你是系統管理的初學者,也可以透過本書輕鬆學習到,如何使用 PowerShell 管理 Active Directory 運作環境的相關技巧。

雖然,大部分的 Windows 系統管理人員,可能習慣以 GUI 圖形化操作介面管理 Active Directory 運作環境,然而面對大量且自動化的需求時圖形化操作便顯得不足,舉例來說當你需要快速建立 100 個使用者帳戶及群組時,如何在極短時間內建立完成?如何快速重設多位使用者帳戶密碼?如何快速搜尋網域中停用的使用者帳戶?如何快速搜尋 AD 內空的群組?如何快速比對兩個群組中重複的成員?這些需求都將在本書中,以 PowerShell 實際展示何謂更有效率和智慧的管理方式。

誰適合閱讀此書

如果,你正在尋找如何透過 PowerShell 模組,管理 Active Directory 重複性工作任務的話,那麼本書便是專為你而寫的。此外,閱讀本書最大的好處是,你將會直接獲得作者多年深厚且豐富的 PowerShell 實戰管理經驗。


網路購書



你將會從本書中學習到:

  • 使用 PowerShell 管理使用者帳戶及電腦帳戶。
  • 使用 PowerShell 管理群組成員、刪除群組成員、大量建立使用者帳戶及群組。
  • 使用 PowerShell 以快速且高效率的方式,查詢在 Active Directory 環境中的使用者、電腦、群組……等物件的詳細資訊。
  • 使用 PowerShell 設定及管理網域、組織、站台、子網路、樹系。
  • PowerShell 的進階管理技巧,例如,升級/降級網域控制站、檢查 Active Directory 複寫機制、建立更細緻的密碼原則、FSMO 五大角色的轉移/取回……等詳細資訊。
  • 使用 PowerShell 管理 DNS 客戶端,以及 DNS 伺服器如建立/修改/刪除 DNS 記錄。
  • 使用 PowerShell 設定及管理 DFS-N 及 DFS-R 運作環境。


本書導讀

  • 《第 1 章、讓我們開始吧》,本章將說明使用 PowerShell 管理 Active Directory 環境時,所需要的元件、軟體、模組等概觀,除了給予你閱讀及使用本書的方向之外,也讓你開始走向自動化工作任務的旅程。
  • 《第 2 章、管理使用者及電腦物件》,幫助你使用 PowerShell 管理使用者帳戶及電腦帳戶。閱讀完本章之後,你將會了解到如何透過 PowerShell 指令碼,管理 Active Directory 當中的帳戶並進行自動化工作任務。
  • 《第 3 章、了解 Active Directory 群組及成員關係》,本章將著重在建立、修改、查詢 Active Directory 環境中,安全性群組以及成員關係的部分。
  • 《第 4 章、設定群組原則(GPO)》,閱讀完本章之後你將學習到如何透過 PowerShell,在 Active Directory 運作環境中建立 GPO 群組原則、如何連結它們、如何解除連結、如何執行它們…等,並且你將能夠確定什麼樣內容的群組原則,可以正確套用到使用者、電腦、遠端主機上。
  • 《第 5 章、管理網域、組織、站台、子網路》,本章將告訴你如何使用 PowerShell,來管理網域、組織、站台、IP子網路。閱讀完本章節之後,你將會了解到如何在你的 Active Directory 運作環境中,管理網域、組織、站台和 IP 子網路。
  • 《第 6 章、使用 PowerShell 進階管理 AD》,閱讀完本章之後,你將會了解到有關 Active Directory 的進階管理技巧,例如,升級和降級 Active Directory 網域控制站、復原 AD 物件、透過 PowerShell 執行複寫資料作業…等。
  • 《第 7 章、使用 PowerShell 管理 DFS-N 及 DFS-R》,本章將實際演練如何透過PowerShell,建立、設定、查詢「分散式檔案系統命名空間」(DFS-N),以及「分散式檔案系統複寫」(DFS-R)運作機制。閱讀完本章之後,你將會學習到如何透過 PowerShell,管理 DFS-N 及 DFS-R 的複雜運作環境。
  • 《第 8 章、使用 PowerShell 管理 Active Directory DNS》,本章將幫助你學習如何使用 PowerShell 管理 AD DNS 伺服器,例如,清除快取、建立及修改 DNS 域中的記錄…等,類似的管理作業也都將在本章一一說明。閱讀完本章之後,你將會學習到如何透過 PowerShell,建立 Active Directory 的 DNS 伺服器,並且執行建立、修改、刪除記錄等 DNS 伺服器的維運工作。
  • 《第 9 章、進一步學習其它指令碼及相關資源》,在本章當中將提供給你,如何透過 PowerShell 管理 Active Directory 的相關學習資訊,並提供一些需要經常性執行的 Active Directory 管理作業參考程式碼。在本書的最後一章當中,你將會知道哪裡還有進一步深入學習的相關資源。

VMware NSX 筆記 (3) - VXLAN 及 Logical Switch

$
0
0

Ethernet 基礎

先回味一下 OSI 七層架構,其中 Frame、HUB/Switch屬於 Layer2層級,而 Packets、Router則屬於 Layer3層級 (Packets 其實到 L2 時,就會分割成 Frames 後再進行傳送)。在乙太網路當中,先從 Layer2 的 MAC Address 開始談起,了解 Ehernet 封包、MAC Address 定址、Type 表示方式。同時了解 MAC Table 功用,以及靜態及動態 MAC 記錄的差別。

接著,回味一下 HUB/Switch/Router功能性,同時辨別 Broadcast DomainCollision Domain的差別。

事實上,網路封包從 Layer2 到 Layer4 層級時都會幫 Frame、Packet 加上Header。了解 IPv4 (Layer3、IP Packet) 的封包內容,以及 TCP (Layer4) 的封包內容。

圖片來源: Wikipedia - OSI model



了解 ARP的運作原理 (ARP Request、ARP Reply、ARP Cache、ARP Broadcast),在實體網路中送出 ARP Request 遇到實體 Switch,就會產生 ARP Broadcast 來詢問 Switch 中所有的 Port。但是,此時若是在 NSX 網路虛擬化環境中,便能透過 ARP Table直接回覆ARP Request,而不會ARP Broadcast封包在實體網路中亂竄。

ARP (Address Resolution Protocol)運作原理及相關參考影片:

vDS 基礎

NSX網路虛擬化環境中所採用的 Logical Switch,其實是架構在原有的 vDS 分佈式交換中,加上其它增強功能所組成。vDS 從 vSphere 5.5版本開始,對於 LACP(802.3ad)的功能支援已經很全面,若採用 LACP 功能的話,需要注意的部份是實體交換器也必須啟用功能。此外,因為 NSX 採用的是 vDS,所以能直接採用簡單方便的 Load-Based Teaming來簡化設定。

下列為採用 VXLAN 的原因:
  • 2 的 12 次方 (4096)-> VLAN (理論上可能會不夠用)
  • 2 的 24 次方 (1,600 萬)-> VXLAN (理論上不會再不夠用)


了解 NSX Plane(Management、Data)在 vDS 中所座落的位置。事實上 ESXi Host負責 Data Plane,也就是實際「處理流量」的部份,而 Control Plane控制」的部份由 NSX Controller處理,而 Management Plane管理」的部份由 NSX Manager處理。


在 ESXi 5.5 版本中,關於 vDS 網路功能的增強部份:
  • 完全支援所有 LACP特色功能
  • 支援 Mellanox 40GB網卡
  • 採用 Traffic Filtering 及 ACL機制,達成 Enable/Drop Traffic 及 Change Tag
  • 完全支援 Layer 2的 CoS (Class of Service)
  • 完全支援 Layer 3的 DSCP (Differentiated Services Code Point)


打造 NSX 虛擬化網路環境時的設計考量:
  • SDDC 中,伺服器最吃重的的硬體資源是「Memory」不是 CPU。
  • 建議每台伺服器至少 10 張 1 Gbps 網卡,或 1 張 10Gbps 網卡。
  • …等


LACP(IP-Hash),有個嚴重的缺點就是並非真正合併頻寬,當「來源及目的 IP 都不變時」,那麼經過演算法處理之後,即使有「多條路」可以走,但實際上還是「只有一條路可以走」(常見的例子 NFS、VSAN…等),且實體交換器還要進行額外的組態設定。


Load-Based Teaming優點是實體交換器不用設定,並且「每 30 秒」會自動檢查網路卡流量,當網路流量不平衡時便會採取自動平衡機制。若要與 NSX 整合,此 Teaming 機制必須在「NSX 安裝前」處理完畢。


每一台 vCenter Server 可以部署 128 台 vDS


Link Aggregation

在實體網路環境當中,最常用來防止 Loop 的機制 STP(Spanning Tree Protocol),也就是 IEEE 802.1D。但是在 NSX網路虛擬化環境中,其實並「不會」參與實體交換器的 STP 動作,所以 Layer2 環境還是必須保持開啟


STP (Spanning Tree Protocol) 參考影片:


LACP(Link Aggregation Control Protocol),可以把多個網路介面綁定在一起 (Port Aggregation)。重點在於,會通知 STP 說只有「1 條連結存在」,所以啟用 LACP 功能後並不會被 STP 誤以為 Loop 而進行 Blocking 的動作。

vSphere 5.5版本開始,增加 20 種關於 LACP 的演算法。現在,每台 ESXi Host 及 vDS 都支援 64 組 LAG (Link Aggregation Groups),且可以同時運作不同的 LACP 演算法。


LACP(Link Aggregation Control Protocol) 參考影片:

VLAN、VXLAN、Logical Switch

VLAN

VLAN簡單來說,可以過濾 Broadcast、提供安全性、流量管理,只有 Router 才能「橋接不同的 VLAN」使之互通。預設情況下,Switch 每一個 Port 就是 Single Broadcast Domain,透過 802.1Q 的 Trunk (Tag)機制,便可以達成 L2 Segments的功用。當然,建立 VLAN 之後,同一個網段的主機發送的 ARP Request / Broadcast,便只會在同一個 VLAN 中傳送,而不會影響到其它網段及 VLAN。

VLAN12 bit也就是 4096,所以大架構環境(公有雲)可能會不夠,才會發展出 VXLAN,並且會把 L2 層的 Ethernet Frame擴大成 1522 bytes。下列為 VLAN ID 4096 中,在 VMware 網路環境中的應用場景及說明:
  • EST, vSwitch VLAN ID 0
  • VLAN ID 1通常保留給 Physical Switch 的 Default VLAN (或稱 Native VLAN)
  • VST, Trunk Port, vSwitch VLAN ID 2 ~ 4094
  • VGT, Trunk Port, vSwitch VLAN ID 4095


VLAN 參考影片:

VXLAN(Virtual Extensible LAN)

用於 Ethernet中的 IP Overlay技術,它將 Layer 2 當中的 Frame 封裝在 UDP Packet 當中(所以封包增加 50~54 bytes),傳送至 Transport Network (Layer 4)內。所以它其實是擴充了原本的 Layer2 功能,並且可以跨到 Layer3 的技術。在 MTU 方面建議「最小設為 1600」,以便完全支援 IPv4 / IPv6 網路環境。此外,從 2013 年 4 月開始 IANA 制定 UDP Port 4789用於 VXLAN



VNI (VXLAN Number Identifier)

等同於 VLAN ID 一樣的道理,而 VXLAN24bit也就是 16,777,216 (理論上不太可能會不夠用),且多個 VNI 是可以在同一個 Transport Zone當中存在。在 VMware NSX 網路虛擬化環境中,VNI 習慣從 5000 之後開始使用。事實上,VXLAN ID 只有 ESXi Host 看得到,VM 虛擬主機是看不到 VXLAN ID 的。

VTEP (Virtual Tunnel End Point)

簡單來說,它是將 VXLAN Frame進行「封裝 (encapsulated)」或「解封裝 (de-encapsulated)」的動作,同時負責轉送的行為(由 ESXi Host 當中的 VMkernel 介面負責處理)。VTEP Proxy透過 UTEP 及 MTEP,複製它所收到的 Frame 並轉送,簡單來說就是負責把遠端的 VTEP 轉送到本地 VTEP。


Transport Zone

定義 VXLAN Overlay 或 VTEP 成員。原則上,Cluster 可以共用同一個 Transport Zone 及 VNI,但是當你要建立多租戶環境時,可以建立不同的 Transport Zone 及 VNI 給不同的租戶。



Multicast

其功能是來源端只要發送單一封包,便可以同時發送給多個目的端(即使跨不同網段)。簡單來說,就是避免廣播行為在網路中亂竄。Multicast 最常見的應用場景是多媒體傳輸、IPTV…等。在 VXLAN 環境中非常依賴 Multicast,最好的是雙向式的運作模式更好 Bidirectional PIM (Protocol-Independent Multicast)

NSX網路虛擬化環境中,它支援 Multicast, Unicast, Hybrid等三種模式。其中 Multicast 必須要 Layer2 IGMPLayer3 Multicast Routing,且記得 MTU 都要設為 1600


情境一、當選擇 Unicast Mode,且 VM1VM3不同台 ESXi Host時:


1. VM1 與 VM3 雖然處於同一個 VXLAN 5001中,但是處於不同的 Cluster 當中。此時,VM1 會發出 ARP Request 給 Logical Switch

2. ARP Broadcast 發送到同一台 Logical Switch 中的所有 VM 虛擬主機。此時,Switch Security Module 透過 Management Network,去 Query NSX Controller當中的 ARP Table內容,查詢 VM3 的 ARP 記錄。

3. 因為 NSX Controller 當中的 ARP Table 內容,並沒有 VM3 的 ARP 記錄。此時,Broadcast 會透過 Proxy VTEP 轉送封裝成 Unicast,從 VM1本地端的 VTEP1發給所有同一組的 VTEP。

4. VM3透過本地端的 VTEP3的封裝,發送 Unicast ARP ReplyVM1。最後,VTEP 學習到 VM3 的 MAC Address,後續 VM1 及 VM3 便能順利溝通。


情境二、當選擇 Hybrid Mode,且 VM1 及 VM3 在「不同台」 ESXi Host時:


1. VM1 及 VM3 身處於同一個 VXLAN 5001,當 VM1 嘗試與 VM3 溝通時,首先發出 ARP Request 給 Logical Switch。

2. ARP Broadcast 發送到接於該 Logical Switch 中的所有 VM 虛擬主機。此時,Switch Security Module 透過 Management Network,去 Query NSX Controller 當中的 ARP Table 內容,查詢 VM3 的 ARP 記錄。

3. 因為 NSX Controller當中的 ARP Table 內容,並沒有 VM3 的 ARP 記錄。此時,Broadcast 會採用 Multicast的方式,通知所有本地端的 VTEP,而 Proxy VTEP的部份則採用 Unicast

4. Logical Switch發送 Unicast ARP Reply 給 VM1,之後 VM1 便能順利與 VM3 溝通。

情境三、當選擇 Hybrid Mode,且 VM1 及 VM2 在「同一台」 ESXi Host 時:


1. VM1 及 VM2 身處於同一個 VXLAN 5001,當 VM1 嘗試與 VM2 溝通時,首先發出 ARP Request (在同一台 ESXi Host 當中)。

2. ARP Broadcast 發送到同一台 ESXi Host 當中,接於該 Logical Switch 中的所有 VM 虛擬主機。此時,Switch Security Module 透過 Management Network,去 Query NSX Controller 當中的 ARP Table 內容,查詢 VM2 的 ARP 記錄。

3. 因為 VM1 與 VM2 接在同一台Logical Switch,在 VM2 發出 ARP Reply 之前,NSX Controller 會先回應 Switch Security Module
i. 若 VM2 沒有 DHCP 資訊或執行過 ARP Reply 動作,那麼 NSX Controller 內也沒有相關資訊。
ii. Switch Security Module 更新 Local ARP Table內容,並且通知 NSX Controller 更新它的 ARP Table 內容(關於 VM2 的資訊)。

4. Logical Switch 發送 Unicast ARP Reply 給 VM1,之後 VM1 便能順利與 VM2 溝通。

在同一台 ESXi Host 的運作情境中,並不會產生「VXLAN 封裝」的情況。因為此情況選擇的是 Unicast / Hybrid Mode,若是在 Transport Zone 中選擇的是 Multicast Mode,那麼 ARP Request Broadcast 會轉送 VXLAN 封裝給其它所屬 Multicast Group 當中的 VTEP。


情境四、當選擇 Multicast Mode,且 VM1 及 VM3 在「不同台」ESXi Host 時:


1. VM1 及 VM3 身處於同一個 VXLAN 5001,當 VM1 嘗試與 VM3 溝通時,首先發出 ARP Request 給 Logical Switch。

2. ARP Broadcast 發送到接於該 Logical Switch 中的所有 VM 虛擬主機。此時,Switch Security Module 透過 Management Network,去 Query NSX Controller 當中的 ARP Table 內容,查詢 VM3 的 ARP 記錄。

3. 因為 NSX Controller 當中的 ARP Table 內容,並沒有 VM3 的 ARP 記錄。此時, Broadcast會採用 Multicast的方式,通知所有本地端的 VTEPProxy VTEP

4. Logical Switch 發送 Unicast ARP Reply 給 VM1,之後 VM1 便能順利與 VM3 溝通。


小結! 在 NSX 網路虛擬化環境中,只要 VM 虛擬主機在不同台 ESXi Host 的話,那麼不管是在同一個 Cluster 或不同 Cluster,其實 MAC 學習的流程是一樣的。

QoS Tagging

事實上 QoS Tagging機制,與 VLANvSphere網路環境的設定概念相同,可以 Guest OS 設定、vSwitch 設定、實體 Switch 設定等三種運作方式。


當 QoS Tagging 機制設定完成後,在資源搶奪的情況發生時,便可以讓需要優先通過的網路流量,可以順利的到達目的地。


再次說明 NSX 相關元件的設定流程:


1. 部署 NSX Manager並與 vCenter Server配對。

2. 透過 vSphere Web Client 或 NSX API,配置 Logical SwitchDistributed Logical Router。當配置完成後,發佈給 NSX Controller 知悉,並決定哪台 NSX ControllerActive

3. NSX Controller 與 ESXi Host 當中的 UWA進行溝通,並且更新相關資訊。在 VXLAN (Logical Switch) 的部份,確認 VM 連接到哪個 VNI 之後便可以啟動電源準備上線服務。此時,UWA 會同步資訊給 VTEP 並且回報給 NSX Controller (更新 ARP Table 資訊)

4. Distributed Firewall的相關組態設定,則是透過 Message Bus直接發送給 ESXi Host

5. 事實上,在 NSX 網路虛擬化環境中的 ESXi Host,除了以往傳統負責的 Compute Resource 之外,現在還擔任 UWA, VTEP, Logical Switch, Router, Firewall等任務。

VMware vExpert 2016 開放申請

$
0
0

前言

往年大約 2 ~ 4 月份時,便會開放申請 VMware vExpert 的活動。而明年,也就是 VMware vExpert 2016 的活動也開始了申請開放的活動,VMware vExpert 其實是個類似 Microsoft MVP 的技術頭銜也是採「申請制」,簡單來說就是提交你認為對該產品有哪些貢獻,之後交由原廠審核並認同你是否真的值得獲得此技術頭銜。

因為 VMware vExpert 技術頭銜活動,並不如 Microsoft MVP 技術頭銜活動來得歷史悠久,所以人數還很少,截至 2015年為止全球的 vExpert人數也才 913 人而以 (Microsoft MVP 全球約 5,000 人)。

下列為歷年獲選為 VMware vExpert 技術頭銜的全球人數:

申請成為 VMware vExpert 的路徑

你可以依照不同的貢獻程度,分成三種不同路徑的申請機制:

技術傳播者路徑 (Evangelist Path)
選擇此申請路徑者,通常為 書籍作者 (Book Authors)、部落客 (Bloggers)、工具建立者 (Tool Builders)、公開演說者 (Public Speakers)、VMTN 貢獻者 (VMTN Contributors)...等,簡單說就是透過個人途徑把技術發享出去。

使用者路徑 (Customer Path)
選擇此申請路徑者,通常是 VMware 企業客戶的 Leaders,透過建置 VMware 的成功經驗讓其它客戶當參考,或者是 VMUG (VMware User Group) Leaders...等,都可以申請。

VMware 合作夥伴路徑 (VMware Partner Network Path)
選擇此申請路徑者,通常是 VMware 合作夥伴透過 教學影片、研討會 方式將技術發享出去...等,都可以申請。

所以,決定好之後就可以填寫申請表格 vExpert 2016 Application are open 然後靜待消息公佈吧  :)


申請 vExpert 2016 注意事項

    1. 申請 VMware vExpert 技術頭銜,在往年都是「一年」才開放申請一次。去年 (2015) 則為「半年」開放申請一次 (2015 年有 Q1、Q3)。但是,今年 (2016) 目前尚未清楚說明下一次的申請期間。
     2. 如果你已經是「現任 vExpert (vExpert 2015)」 的話,可以直接走 Current vExpert Fast Track 路徑,可以少填許多表格。
     3. vExpert 開放申請的時間至 2015/12/18 止 (請注意是以 PST 時區為準),申請結果將於 2015/02/05 時公佈。參選詳細資訊請參考 VMware Blogs - vExpert 2016 applications are open


獲選 VMware vExpert 的好處?

若申請後獲選為 VMware vExpert 的話有哪些好處呢? 你可以獲得 Private Beta 的測試機會、VMware Free Licenses (365 Days)、免費存取 VMworld 會議資料...等。

站長是從 2012年第一次申請 VMware vExpert 技術頭銜,並且努力並沒有白費,成功獲選成為 VMware vExpert 2012 並接受採訪刊登於 VMTN Blog - vExpert Spotlight: Wei-Ren Wang,然後於成功連任 VMware vExpert 2013、2014、2015

此外,除了與其它國家 vExpert 有交流的機會之外,還會有許多廠商提供許多很不錯的禮物、贈品、軟體...等。舉例來說 ,站長當選 vExpert 2015 就拿到了 Tintri 所提供的優質 ShirtTrainSignal 免費使用一年份帳號...等。


VMware NSX 筆記 (4) - NSX Routing

$
0
0

VMware NSX 學習筆記


NSX Routing(OSPF, IS-IS, BGP)

NSX Routing (在 vCloud 環境的話則是使用 vShield Edge)。首先,了解 OSPF (Open Shortest Path First)、IS-IS (Intermediate System to Intermediate System)、BGP (Border Gateway Protocol)等動態路由的運作流程。簡單來說 OSPF常用於「內部路由」的部份,而 IS-IS則是決定「最佳路由」的部份,而 BGP則是「外部路由」的部份。

OSPF

AS (Autonomous System) 自治系統區 (Default Area 0, 51),一般來說相同的 AD 會採用 OSPF,不同 AS 則採用 BGP。預設情況下每 10 秒鐘,透過 hello packets 機制(發送用Multicast),尋找附近(鄰居, 身體同一網段共用同 Area ID) Router 的狀態。OSPF 採用  Dijkstra 演算法,來找到最佳路由路徑或最低路由成本 (NSX 支援 OSPF v2)。

OSPF Packet 的 Header 為 24 bytes,包含 OSPF 版本、RID(Router ID)、Area ID…etc。預設的 OSPF Area Type 大致三大類 Normal Area, Stub Area, NSSA(Not so Stubby Area),每個 Area 自行維護 Link-State Database。
  • Normal Area:處於 Non-Backbone Area,從 Backbone 接收「Full Routing」資訊。
  • Stub Area:處於 Non-Backbone Area,從 Backbone 接收「Default Route」資訊。
  • NSSA:處於 Non-Backbone Area,從 Backbone 接收「Default Route」資訊。可以導入外部路由並送至 Stub Area,但無法從其它 Area 獲得 AS 外部路由。

IS-IS

其實與 OSPF 機制很像有二種 Level,分別是 Level 1 對應到 OSPF 非骨幹部份,以及 Level 2  對應到 OSPF 骨幹部份。用在大型路由區域的動態路由協定,它座落在 Layer2 所以可以路由「Non-IP Traffic」。

BGP

支援 iBGP / eBGP,且 BGP Peer 之間透過 TCP Port 179進行溝通。

NSX Logical Router

Distributed Logical Router運作在 VMkernel當中,負責 Data Plane 東西向的流量,可以優化路由及 Data path 且支援單一租戶或多租戶環境。

NSX Controller集中「部署、管理」Logical Router,每台 Distributed Logical Router 可以有 1000 Interface,NSX 架構中最多可以有 1200 台 Distributed Logical Router,每台 ESXi Host 最多 100 台 Distributed Logical Router。


以往當 VM 虛擬主機在不同的二台 ESXi 主機要互相溝通時,網路流量一定會流出 Layer2 實體層,這種非最佳流量的傳送行為稱之為「Hairpinning」。


現在,在 NSX 網路虛擬化環境中,當處於不同 VXLAN 的 VM 虛擬主機要互相溝通時,透過 NSX Edge Gateway轉介,在 Layer3就處理好整個傳輸流程如下:


1. 雖然二台 VM 虛擬主機身處於同一台 ESXi 主機,但是卻處於不同的 VXLAN 5001/5002
2. VXLAN 5001 中的 VM 發送 Frame 到 Logical Switch 至 vDS,因為 VM 處於不同 VXLAN 所以 ESXi 將 Frame 轉送到 Default Gateway (也就是 NSX Edge Gateway)。
3. 運作 NSX Edge Gateway 的 ESXi 主機,收到遠端 ESXi 主機傳來的 Frame。
4. 運作 NSX Edge Gateway 的 ESXi 主機,將收到的 Frame 傳給其上運作的 NSX Edge Gateway。
5. NSX Edge Gateway 確認路由路徑後,發回應 Packet 給剛才遠端的 ESXi 主機,一樣到 vDS 然後到 VXLAN 5002 的 Logical Switch。
6. 確認後,傳送 Frame 給 VXLAN 5002 的 VM。
7. VXLAN 5001 的 VM 順利與 VXLAN 5002 的 VM 進行溝通。

Distributed Logical Router

它座落在 VMkernel 層級 (Kernel Module) 中,並且可以處理 VXLAN -> VLXAN 或 VLAN -> VLAN的流量,也可以處理實體或虛擬網路的路由 (VXLAN -> VLAN 是稍後會介紹的 Layer 2 Bridge 功能)。


如同上述範例所說的溝通情境,當二台 VM 虛擬主機在同一台 ESXi 主機,但是卻身處於不同 VXLAN 時,流量到了 ESXi VMkernel 層 (Data Plane)之後,就可以直接路由流量了(記憶體網路流量),而必出去問 NSX Edge Gateway 再回來。



由 NSX Controller Cluster 當中的三台來負責分發,LR Control VM 所學習到的路由 (跨 ESXi 主機) 給 Distributed Logical Router。

Distributed Logical Router 擁有 LIFs (Logical Interfaces),你可以想成是實體 Router 的網路介面,它包含了 IP Address、ARP Table,且每台 Distributed Logical Router 可以配置多個 LIFs (最多 1000),分別連接到 Logical Switch 或 vDS Port Group。

在 LIF 當中的 MAC Address 稱為 vMAC(virtual MAC),所有的 VM vMAC 不會儲存到 Layer2 Switch 當中,因為這些 vMAC 是在 VXLAN 當中的,因此實體網路其實看不到 VM,且 VM 會以 vMAC 當成 Default Gateway 的 MAC Address。而 pMAC(physical MAC) 則是對應到 uplink,用來處理 VLAN LIF 以連接到實體網路。
  • VXLAN LIF: Distributed Logical Router 用來介接 Logical Switch,採用 vMAC。
  • VLAN LIF: Distributed Logical Router 用來介接 vDS Port Group,或其它更多 VLAN,採用 pMAC。


每個 VLAN LIF 中存在一個 Designated Instance,負責解析 ARP 並回應給主機,當 ARP Request 封包送到 vDS Port Group 時,就是由 Designated Instance 負責。NSX Controller會在所有主機中選舉,然後推送 Designated Instance 給勝出的那台主機,當發生故障事件時,NSX Controller 會在存活的主機中再次選舉,然後更新資訊給其它存活主機知悉。

Logical Router Control VM (其實就是 vShield Edge),也是從 NSX Manager 挖 Logical Router Control VM 的 OVA 出來部署,它的 HA 機制是採用 AutoStart Manager 來處理,會再長一台 VM 出來,共二台來達成 Active-Standby,同時在 Firewall 內會多規則 169.254.1.1/30、169.254.1.2/30 來進行 Heartbeat 行為。值得注意的部份是,當啟用/關閉 HA 機制,會暫時無法運作!!
  • vCenter *1 (VM)
  • NSX Manager *1 (VM, Management Plane)
  • NSX Controller *3 (VM, Control Plane, 由 NSX Manager 挖 OVA 部署)
  • Logical Router Control VM (VM, Control Plane, 由 NSX Manager 挖 OVA 部署)
  • Logical Router is On Daemon (ESXi Kernel Module, Data Plane)


所以 Management, Control, Data Plane,這三個層級之間的網路流量到底是如何進行傳送? 詳見下圖


了解後,我們來看看一些典型部署模型。首先,是比較簡單的「One-Tier」架構。


接著來看看比較複雜的架構「Two-Tier」。


現在,有了 Distributed Router 之後,當 VM 虛擬主機需要互相溝通時,在同一台 ESXi Host 網路流量的流向。簡單來說,當 ARP封包到 Distributed Router 後,因為在同一台便直接查到 ARP Table,所以直接回覆網路流量並進行後續溝通 (記憶體流量)。


即使二台 VM 位於不同台 ESXi Host,流量也不會跑到實體 Layer2 層,而是在 VXLAN Transport Network層就處理好。


Layer 2 Bridging

Layer 2 Bridging 簡單來說,是為了「VXLAN <-> VLAN」之間能夠互通。Layer 2 Bridging 必須要搭配 Distributed Router 才行,若是 VXLAN <-> VXLAN 及 VLAN <-> VLAN則必須要 Layer3 Routing設備才能夠互通。


簡單來說,很重要的原則是,只要是可以在虛擬環境交換的流量都會使用 VXLAN,只有需要到實體網路時才會採用 VLAN 流量。此外,Layer 2 Bridging 的 Data path 完全在 VMkernel 進行交換,在 vDS 的 dvPort Type 中稱為 Sink Port,以進行引導封包的橋樑。請注意!! Distributed Routing 及 Layer2 Bridging 「不可」同時運作於 Logical Switch 中。

Bridge Instance 會將學習到的VM虛擬主機 MAC Address,傳送給 NSX Controller(更新 ARP Table)。但是,NSX Controller 只會「選定一台 ESXi」來擔任,也就是把 Bridge Instance是跑在 Control VM Active 當中的那台 ESXi 主機上 (以避免過多的 Broadcast 流量影響網路環境)。所以,發生故障事件後,此時 Standby 主機便立即接手成 Active 角色。


現在,讓我們來看看 VXLAN <-> VLAN之間,網路流量的的 Flow 流向。從 VXLAN -> VLAN 的 ARP 流程,首先說明 ARP RequestVXLAN -> VLAN當中的運作:


1. VM1 發送 ARP Request。
2. 因為 VM1 所在的 ESXi 主機,並不知道目的地端的 VM 虛擬主機 MAC Address(IP3, MAC3)。所以,ESXi 主機便詢問 NSX Controller 目的地 MAC Address。
3. NSX Controller 也不知道目的地 MAC Address,所以 VM1 所在的 ESXi 主機,便送出 Broadcast 給 VXLAN 5001 中所有的 ESXi 主機 (VTEP)。
4. VXLAN 5001 中所有的 ESXi 主機收到 Broadcast 之後,轉發給其上運作的 VM 虛擬主機。
5. 與原有的 ARP 行為一樣,當 VM2 收到後請求封包後,因為跟它無關所以就 Drops Frame。
6. Bridge Instance 同樣的也收到請求封包,因為身上有 VXLAN 5001 及 VLAN 100。
7. 因此將 Broadcast 轉送到 VLAN 100 的實體網路去。
8. 實體交換器收到 Broadcast 後,便針對 VLAN 100 所屬的 Port 號進行封包廣播的動作。
9. VM3 主機收到,並確認自已就是 VM1 要找的機器,進入 ARP Response 的回應動作。

接著,來看看 ARP ResponseVLAN -> VXLAN 當中的運作:


1. VM3 送出ARP Response,變成來源端是 MAC3 而目的地端是 MAC1。
2. ARP 回應封包從 VM 虛擬主機,至運作 VM3 的實體主機及實體交換器的 Port。
3. 將 ARP 回應封包,回給剛才送 ARP 請求的 Port。
4. Bridge Instance 的 VLAN 100 介面,收到 ARP Response 封包。
5. Bridge Instance 記錄學習到的 MAC 後,把 ARP Response 封裝後送給處於 VXLAN 5001 的 VM1。
6. ARP 回應封包,到達 VM1 所在的 ESXi 主機,接收學習後轉送給其上運作的 VM1。
7. VM1 虛擬主機,順利收到 VM3 的回應封包,二台主機後續便可順利溝通。

透過 Bridge Instance 運作機制,順利橋接二邊 (VLAN <-> VXLAN) 之後,接著便採用 Unicast的方式,進行後續的溝通處理作業。


1. VM1(VXLAN 5001) 及 VM3(VLAN 100) 的二台虛擬主機,已經完成了 ARP 查找流程。
2. VM1 的 ESXi 主機,已經把學習到的 MAC(VM3),記錄在本身的 MAC Address Table 當中。
3. VM1 的 ESXi 主機,直接把網路流量傳給 Bridge Instance (不用向之前還要 Broadcast 整個 VXLAN)。
4. Bridge Instance 收到後,因為剛才的 ARP 查找流程中,也已經學習到 MAC(VM3)。因此,便可以直接進行轉發作業。
5. Bridge Instance 轉發封包給 VLAN 100 的 Switch。
6. VM3 所在的 ESXi 主機收到封包。
7. VM3 順利收到 VM1 傳來的封包。

後續,從 VLAN 端發起的 ARP Request,以及 VXLAN 回應的 ARP Response,其實與剛才所述內容相同,只是方向不一樣而以。

NSX Edge Services Gateway

NSX Edge Gateway (也是 vShield Edge VM),負責南-北向 Plane 的溝通作業,所以會有二隻腳串連上下層 (vDS 及 Logical Switch)。此外,它的 HA 機制也是 AutoStart Manager (Active-Standby HA 機制)。

接著,讓我們來看看 NSX Edge 可以擔任的項目,其中它的 Firewall 功能是指「整體」的(網段...etc),而非 Data Plane 中每台 VM 前的 Distributed Firewall。


由前面的範例情境中,你可以了解到 NSX Edge Gateway,擔任的工作負載也很吃重。所以必須要給序適當的硬體資源,比較特別的部份是當給的資源太少時,系統會「自動補足」成最低的需求 (給超過當然沒問題!!)


此外,先前提到 NSX 網路虛擬化環境支援動態路由機制,這部份的工作負載便是由 NSX Edge Gateway 來負責,支援的動態路由有 OSPF, IS-IS, BGP。最後,針對剛才所述的 NSX Edge Gateway 功能,可能還是覺得很籠統。讓我們來看看它詳細的功能項目:

  • Firewall
  • NAT (Network Address Translation)
  • DHCP
  • Routing
  • Load Balancing
  • Site-to-Site VPN
  • SSL VPN
  • L2VPN
  • High Availability
  • DNS / Syslog

VMware NSX 筆記 (5) - NSX Edge Gateway

$
0
0

VMware NSX 學習筆記


NSX Edge Gateway

本章將說明 NSX Edge Gateway所能任的角色,例如,NAT、Load Balancing、VPN以及本身所具備的 HA(High Availability)高可用性…等特色功能。

NAT(Network Address Translation)

簡單來說,你可以讓 NSX Edge Gateway 搖身一變成為 NAT 裝置,它支援 Source NAT / Destination NAT等機制,它其實就是採用 Linux Kernel (NetFilter)也就是 IPTables來處理 NAT 的部份。下列為 Source NAT的應用情境。


Destination NAT 的應用部份,其實就等同於是 Mapping IPPort Forwarding等機制的應用。


LB (Load Balancing)

NSX Edge Load Balancing 的負載平衡機制,支援二種模式分別是「One-arm Mode (Layer7, HTTP/HTTPs)」及「Inline Mode (Layer4, TCP)」。


One-arm Mode
One-Arm Mode 也常稱為 Proxy Mode,此方式的負載平衡優點是架構設計簡單且容易部署。但是,缺點是你必須要有負載平衡的每個網段,可以整合「HTTP X-Forwarded-For」機制來重新導向 IP 位址。


Inline Mode
Inline Mode 也常稱為 Transparent Mode,此架構的優點在於不用做 Source NAT 的動作,可以有效降低負載平衡的工作負載。但是,不能與 Distributed Router 共用,因為後端的 Web Server 必須要把 NSX Edge 設定為 Default Gateway。


HA (High Availability)

NSX Edge Gateway 本身的 HA 機制 (同樣以 EMC AutoStart Manager機制建立),二台主機之間的 Heartbeat 及資料同步,都是採用 Internal Port Group 來達成 (169.254.1.x)。心跳偵測的部份是由 Active Node 送出 Heartbeat 訊號,預設 Dead Timer 是 15 秒 (最少可調整為 6 秒),當 Active 死掉時「Session 會中斷必須重連」,因為是 Standby 接手所以 Session 要重連。此外,啟動 HA 機制之後,系統會「自動」產生 Anti-Affinity 規則。


當啟動或停用 HA 機制時,持續 ping 時會發現掉 2 個 ping 封包,若啟用 HA 機制時「不填」 Management IP 的話,跟 Control VM 一樣,就會自已產生 169.254.1.x 處理,若是觸發 HA 事件切換時則是會掉 3 個 ping 封包,它不會 Failback (原來的 Active 回來後不會搶回去)。可以透過指令「shows service high availability」來確認,目前哪一台是 Active 哪台是 Standby 及運作狀態。


VPN

NSX Edge Gateway 支援的 VPN 種類有三種,分別是 Site-to-Site, L2, SSL…等。值得注意的部份是,如果伺服器的 CPU 有支援 AES-NI的話(CPU 從 Westmere世代開始就支援 AES-NI),屆時可以加速加解密的效率,可提升約 30% ~ 40%


IPSec VPN的部份,最多支援 64 Tunnels 及 10 Sites,支援的加密演算法有 AES (預設值)、AES256、TripleDES。在 Site-to-Site 之間的溝通,採用常用的 IKEv1(phase1, phase2)、ESP。


在 GUI 設定畫面中「internal (指的就是 local)」、「uplink (指的就是 peer)」。


SSL VPN 的部份,支援 25 個使用者帳號及相關認證機制。

VMware NSX 筆記 (6) - NSX Security

$
0
0

VMware NSX 學習筆記


NSX Edge Firewall

NSX Edge Firewall 擔任如同傳統硬體防火牆,也就是擋著「外 -> 內」的攻擊。NSX Edge Firewall 其實就是 vShield Edge VM,因為它是高度客製化的 Linux(VM),所以其實防火牆功能就是 NetFilter (IPTable)

預設情況下 Firewall Policy為「外 -> 內 Deny」,採取 Rules First-Match的防火牆規則讀取方式,最多支援 2,000 筆規則,連線數的部份則跟部署的資源有關。

Firewall Rules 中有 Default, Internal, User三種類型:
  • Default:就是預設規則(可以多條或多組)。
  • Internal: User Define Chain (服務分類的概念),這樣的設計的目的是可以「降低規則比對次數,提升運作效能」,但只有系統自已使用,管理者無法手動建立此規則。
  • User:實際執行的 Rules,GUI 設定只能是 User。

此外,比較特別的部份是可以識別 vSphere 相關物件如 Cluster, Resource Pool...等,且內建多種常用服務如 Exchange...etc,你可以選一堆組成 Service Group,以因應內部的 VM 服務。Incoming角度是從 Edge 來看 (外 -> 內 VM),Outgoing角度是從 Edge 來看 (內 VM -> 外)。

Distributed Firewall

以往的防火牆,只能擋住外到內的部份,主機之間的攻擊行為防護只能依靠 Guest OS 內建防火牆,但是在管控上並不方便且會影響效能。因此,不同於以往的設計 Distributed Firewall 是擋在「每台 VM」前面的 Firewall (所以 Guest OS Firewall 可以關閉)。



Distributed Firewall,它是內嵌在 VMkernel當中(座落於 vNIC Level)。原則上可以處理 L2 ~ L4 (L2 MAC、L3 IP、L4 TCP/UDP/Port),在優先權上,L2 的 Rules 會優先處理。在 GUI 設定介面中「Ethernet」其實就是 L2 Rules,而「General」就是 L3,L4 Rule,簡單來說,Distributed Firewall會先比對 L2 Rule 後,再比對 L3,L4 Rule 最後比對 Default Rule。此外 Distributed Firewall Rules 會「跟著 VM 走」,所以不用怕 vMotion 之後防火牆規則會跑掉的問題。


在規則管理上由 vSphere Web Client 統一進行規則設定的動作,透過 NSX Manager 把防火牆規則派送到每一台所屬的 ESXi Host 當中 (NSX Controller 不負責這部份)。


在防火牆規則中的 SECTION 只是「容器」的概念(管理用途),跟先前提到 NSX Edge Firewall 的 Internal 不同。現在,透過 NSX 網路虛擬化的 Distributed Firewall 功能,除了能定義 VM 與 VM 之間是否能互通之外,即使不同網段的 VM 也能進行定義。


雖然 Distributed Firewall 防火牆規則看似複雜,但其實每台 VM 的 Distributed Firewall,只會載入必要的也就是跟自身有關的防火牆規則,跟自身無關的規則並不會載入。



Flow Monitoring

Flow Monitoring 功能,主要是看 NSX 物件相關流量以及除錯之用。同樣的,你可以透過 vSphere 的相關物件,來進行流量過濾的動作以便於你找出問題的根本原因。

Role-Based Access Control

Role-Based Access Control 驗證機制,可以支援 LDAP, Windows AD, NIS...等驗證方式。當然,在權限的部份也會有「繼承 (Inheritance)」的特性。

Service Composer

Service Composer 是一種 Template 的概念,它可以整合 3-Party 到 NSX 環境中如 IDS/IPS, Anti-Virus...等。匯入後,首先就是要跟 NSX Manager 進行介接的動作 (Register 的概念)。


舉例來說,當你導入防毒機制後,會進行 VM 掃描動作,若發現病毒則會將該 VM 移至「隔離區 (Quarantine)」,當威脅排除後才能回到正常工作區域。


Other Monitoring Options

除了剛才介紹的 Flow Monitoring 機制之外,你也可以使用 Syslog機制來幫助你除錯並了解系統資訊。此外,也可以整合 vCenter Log Insight機制。

學習資源

Virtual Domain Controller 注意事項

$
0
0

前言

以往在建置 Microsoft Hyper-V 虛擬化環境時,通常會習慣至少有一台實體主機來擔任「網域控制站 (Domain Controller)」的任務,並且在預設情況下網域控制站「不能」或「不建議」與其它角色安裝在一起:
  • DC 絕對能與 Exchange、SQL Database 角色裝在同一台主機。
  • DC 建議與 Hyper-V 角色裝在同一台主機。
  • DC 建議整合在 Windows Server 2003, 2008, 2008 R2 容錯移轉叢集運作環境中。
  • DC 支援整合在 Windows Server 2003, 2008, 2008 R2 的 Exchange/SQL容錯移轉叢集運作環境中。
  • RODC 支援整合在 Windows Server 2003, 2008, 2008 R2 容錯移轉叢集運作環境中。
  • ADDS 支援整合在 Windows Server 2012 容錯移轉叢集運作環境中。但是,RODC 可以運作於 Windows Server 2012 容錯移轉叢集運作環境中。


Virtual Domain Controller (vDC)

現在,在 Windows Server 2012 R2 版本中,具備「Active Directory Detached Cluster」機制,不用再像過往版本要考慮 CNO(Cluster Name Object)VCOs(Virtual Computer Objects)的問題,因為都已經把 CNO、VCOs 建立在 DNS 當中。此外,Intra-Cluster仍使用 Kerberos驗證,但 CNO的部份則採用 NTLM驗證。

此外,從 Windows Server 2012 版本開始,在「容錯移轉叢集 (Failover Cluster)」當中,多出了「BootStrapping」特色功能。簡單來說,它能允許容錯移轉叢集相關服務在啟動時「無須賴 Physical DC」,所以你可以「把 vDC 運作在 Hyper-V Cluster」運作環境中。

因此,當 Hyper-V Cluster 節點主機,通過 vDC 的身份驗證機制之後便會儲存一份「Cached Credentials」在本機當中,當無法連絡 vDC 時便會用這份快取驗證來運作。

經過實作確實是可行的,也就是先在實體主機上啟動 Hyper-V 角色,接著建立一台 VM 虛擬主機並提升為網域控制站,然後將 Hyper-V 實體主機加入運作在 VM 虛擬主機當中的網域,接著 Hyper-V 實體主機便可以建立 Hyper-V Cluster。



vDC 的注意事項

但是,將 DC 運作在 VM 虛擬主機時,仍須避免執行下列動作以防止發生將 USN 混亂的情況發生 (因為,USN 會追蹤 AD Object Replication 進而導致 RID Pool 發生問題):
  • 不可建立檢查點 (CheckPoint),舊稱為「快照 (Snapshot)」。
  • 不可以針對運作 DC 的 VM 虛擬主機進行復原動作 (不管是 Host 或 Storage Level 的備份) 。
  • 不可以單純的針對運作 DC 的 VM 虛擬主機進行「Copy/Clone」作業。


參考資源

Storage Spaces Direct - 深入探討 Software Storage Bus 機制

$
0
0

前言

本文,要向大家介紹微軟的「軟體定義儲存 (Software-Defined Storage,SDS)」技術,它是從 Windows Server 2016 TP2技術預覽版本開始內建,並且是由 Windows Server 2012 R2 當中的「Storage Space」技術演化而來,在 Windows Server 2016 當中稱之為「Storage Spaces Direct (S2D)」。

事實上,目前的微軟 SDS 技術名稱 Storage Spaces Direct,在 Windows Server vNext 開發時期稱之為「Storage Spaces Shared Nothing」。接下來,要向大家介紹在 Microsoft S2D 技術當中,最重要的底層運作機制「SSB(Software Storage Bus)」。



SSB (Software Storage Bus) 簡介

  • 負責在 S2D Cluster 當中,串起所有伺服器儲存資源的「虛擬儲存匯流排 (Virtual Storage Bus)」運作機制。
  • 它可以讓「每台」叢集節點,彼此之間能夠互相看到在此叢集當中「所有」的硬碟。
  • 在 S2D Cluster 當中,每台叢集節點有二個主要運作元件 ClusPortClusBlft,其中「ClusPort」元件達成 Virtual HBA的功能,允許叢集當中每台叢集節點互相連接彼此的硬碟。而「ClusBlft」元件則是整合每台叢集節點的硬碟及 Enclosures,並與 ClusPort 協同運作



S2D 採用 SMB 3 協定進行資料傳輸

  • 在 S2D 叢集當中,採用SMB 3 協定進行 S2D 運作環境的資料傳輸用途,並且搭配 SMB MultichannelSMB Direct (RDMA) 機制達到傳輸流量負載平衡及容錯移轉,同時還能降低主機工作負載。
  • 採用「具名執行個體 (Named Instance)」機制,分隔 S2D 叢集當中的每台叢集節點,同時結合 CSVFS 機制提供給 SMB Client 進行存取及額外的彈性。
  • 整合 SMB MultichannelSMB Direct機制進行資料傳輸,其中「SMB Multichannel」機制為整併多張網路介面卡,以提供更高的吞吐量及彈性(負載平衡及容錯移轉),而「SMB Direct (RDMA)」支援 iWARP / RoCE,以降低 CPU 在處理網路 I/O 的工作負載,同時降低整個硬碟裝置的延遲時間


SSB 頻寬管理機制

SSB 採用下列三種不同的演算法機制,達成叢集中每台叢集節點能夠平均取得資源,同時在 IO 表現上也相對突出的目的。
  • SSB 採用「公平存取演算法 (Fair Access Algorithm)」,確保每台叢集節點都可以存取儲存資源,避免某台叢集節點運作異常影響叢集中其它節點的運作。
  • SSB 同時也採用「IO 優先順序演算法 (IO Prioritization Algorithm)」,確保 VM 虛擬主機當中「應用程式 IO (Application IO)」能夠優先於「系統 IO (System IO)」。
  • SSB 採用「去隨機化 IO 演算法 (De-randomizes IO Algorithm)」,簡單來說,在 VM 虛擬主機當中的 IO 工作負載,雖然都是「隨機 IO (Random IO)」的工作負載居多,但是此演算法會儘量將 Random IO 轉換成「循序 IO 模式 (Sequential IO Pattern)」,以便在某些程度上能提升整體 IO 效能。


SSB 快取機制

SSB 的快取機制稱之為「SBC (Storage Bus Cache)」,必須在「叢集 (Cluster)」當中啟用,當順利啟用成功後便會在「每台 (per Node Cache)」叢集節點當中運作。

SBC 機制與系統中定義的 Storage Pools 及 Virtual Disks 機制並不相干。因為,SBC 機制座落在 Virtual Disk 之下因此可以提供容錯機制,並且透過「複製寫入資料」給其它叢集節點達到提供快取機制的彈性。

SBC 機制會辨別在叢集節點當中,哪些儲存裝置為「快取裝置 (Caching Devices)」哪些為「儲存裝置 (Capacity Devices)」。其中,快取裝置 (Caching Devices) 顧名思義便是擔任儲存裝置的快取,簡單來說就是建立成「混合式磁碟 (Hybrid Disks)」的運作模式。



當 SBC 機制定義好,哪些儲存裝置為快取及儲存空間用途之後,便會將儲存裝置以「輪詢 (Round-Robin)」的方式綁定到快取裝置上。日後,當快取裝置發生故障損壞事件時,便會重新進行儲存裝置對應及綁定的動作。

從下列表格中可以了解到,當 SBC 機制運作在「混合式環境 (SSD + HDD)」時,那麼 SBC 便會負責資料的「Read / Write Cahce」,若是採用「All Flash 環境 (NVMe SSD + SATA SSD)」的話,那麼 SBC 便會負責資料的「Write Cahce Only」。但是,若環境為「All NVMe」或「All SATA SSD」的話,那麼必須要「停用 (Disable)」SBC 機制。


預設情況下,被 SBC 機制辨別為快取裝置的磁碟,將會建立一個「32 GB」的特殊分割區,其餘可用空間則成為 SBC 的快取空間,這 32 GB 的分割區是用來儲存「Storage Pool 及 Virtual Disk」的「中繼資料 (Metadata)」之用。

此外,每當 SBC 機制管理「1 TB」的快取空間時,便需要消耗該台叢集節點「10 GB」的記憶體空間。舉例來說,當一台叢集節點擁有「4 顆 800 GB SSD 固態硬碟」時,便需要消耗該台叢集節點「32 GB」的記憶體空間。

參考資源

Windows Server 2016 TP4 - S2D 新功能剖析

$
0
0

前言

Windows Server 2016 TP4 版本當中的 Storage Space Direct 多了兩項新功能,分別是「Multi-Resilient Virtual Disks」及「ReFS Real-Time Tiering」。

首先,透過這兩項新的特色功能,將可以有效解決以往在 Windows Server 2012 / 2012 R2 當中 Storage Space 的兩大問題:

1. 以往採用「Parity」的方式時,只能用於「備份 (Backup) / 歸檔 (Archival)」用途而已,其它的工作負載便不太合使用,例如,運作 VM 虛擬主機。

2. 使用「Tiering」機制時,只能透過「排程 (Scheduled)」優化作業後,才能將「冷 (Cold) / 熱 (Hot)」資料,分別移動到各自所屬的儲存裝置當中。預設情況下,排程「每天執行 1 次」若希望每天執行多次,則建議每次優化作業的執行間隔「不得低於 6 小時」。

Multi-Resilient Virtual Disks

新的「Multi-Resilient Virtual Disks」仍然是 Virtual Disk,但不同的是在這個 Virtual Disk 當中分成二個部分,其中一部分是「Mirror Tier」另一部分則是「Parity Tier (採用 Erasure Coded 機制處理)」。



因此,在 Windows Server 2016 TP4 版本中實作 S2D 技術時,記得要幫機械式硬碟 HDD 透過 -ResiliencySettingName參數建立「Mirror Tier 及 Parity Tier」。

至於空間大小的計算部分,舉例來說,若是建立的 Mirror Tier 100GBParity Tier 900GB時,那麼該 Volume 便為 1TB。此外,有關 Mirror Tier 及 Parity Tier 在資料讀寫的部分,則會交由 ReFS檔案系統來處理,這也是在 Windows Server 2016 TP4 版本當中,第二項特色功能 ReFS Real-Time Tiering

在上述說明的範例環境中,若是採用 3-Way Mirror 的話那麼這個 Virtual Disk 佔用空間為 100GB *3,加上 900 GB *1.57 (for 4+3 erasure coding),因此 Virtual Disk 大小約為 1.7TB。而非在 Windows Server 2012 R2 若是採用 3-Way Mirror 時,Virtual Disk 大小為 3TB (1TB *3)。

ReFS Real-Time Tiering

了解 Windows Server 2016 TP4 版本中 Mirror Tier 及 Parity Tier 的功用後,接著我們來看看 ReFS 是如何操作這兩個資料讀取及寫入的部分。首先,ReFS 總是會將資料「寫入 (Write)」到「Mirror Tier」,當寫入到 Mirror Tier 的資料比存在於 Parity Tier 還要「新 (Up to Date)」的時候,那麼儲存在 Parity Tier 當中的「舊資料 (Old Data)」便會為無效的狀態。

這樣的資料處理方式,可以確保資料「總是」會將資料優先寫入到 Mirror Tier,並且這樣的資料寫入效能是最好的,除了可以降低主機的 CPU 工作負載之外,當運作如 VM 虛擬主機這種「隨機 IO (Random IO)」的工作負載時,表現將比以往舊有的機制更佳。

資料的寫入作業,將會交由座落在 Virtual Disk 及 File System 之下的「SBC (Storage Bus Cache)」機制來執行,此運作架構的設計優點在於 Mirror Tier 與「快取裝置 (Cache Device)沒有一定比例」的固定關系。因此,不會發生因為空間相較不對稱的情況下,而產生效能表現不如預期的副作用。

ReFS會將 Mirror Tier 當中「較大連續區塊 (Larger Sequential Chunks)」的部分,透過「Erasure Coding」機制演算之後,將該資料區塊由 Mirror Tier 透過「資料旋轉 (Data Rotation)」的方式至 Parity Tier




此外,在處理較大連續區塊時,將會「略過」回寫式快取機制 (Write-Back Cache,WBC) 直接寫入到「儲存裝置 (Capacity Devices)」當中,原因在於「儲存裝置 (也就是機械式硬碟)」擅長處理「循序 IO (Sequential IO)」。同時,因為是寫入到 Parity Tier 當中,因此不再需要進行「Read-Modify-Write」處理程序,有效確保資料寫入效能。

參考資源

保留 OneDrive 30GB 免費空間

$
0
0


前言

在上個月 (2015/11) 時,在 OneDrive Blog上突然發佈要降低免費用戶的空間,從原本的 15 GB變成 5 GB,並且連同手機上傳照片功能贈送的 15 GB空間也要取消。
Free OneDrive storage will decrease from 15 GB to 5 GB for all users, current and new. The 15 GB camera roll storage bonus will also be discontinued. These changes will start rolling out in early 2016.

補償措施

今天開始,你可以連結到「https://preview.onedrive.com/bonus/」網址,然後點選「Keep your free storage」鈕之後,就可以保留原本的 15 GB以及手機上傳照片功能贈送的 15 GB空間。
Click below and your account will not be affected when the amount of free storage changes from 15 GB to 5 GB and the +15 GB camera roll bonus is discontinued.*

圖片來源: OneDrive 網站

119 期 - 微軟最新 SR 儲存複本機制,實戰伺服器間同步複寫

$
0
0

網管人雜誌

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

文章目錄

1、前言
2、同步複寫機制
3、非同步複寫機制
4、儲存複本功能整理
5、實作 Server to Server 同步複寫機制
          先決條件
          初始環境組態設定
          安裝 Storage Replica 功能
          環境測試
          建立儲存複本機制 – 新增複寫合作夥伴
          查詢儲存複寫資訊 – 複寫群組
          查詢儲存複寫資訊 – 複寫合作夥伴
          查詢儲存複寫資訊 – 磁碟複寫
          查詢儲存複寫資訊 – 複寫事件
          監控儲存複寫效能數據
          反轉複寫方向
          移除儲存複寫機制
6、結語

1、前言

在微軟下一代 Windows Server 作業系統,先前開發代號為 Windows Server vNext,目前則稱為 Windows Server 2016的新式儲存機制當中,有一項新的儲存特色功能稱之為「SR(Storage Replica)」。

它是一種與傳統儲存設備種類(DAS/NAS/SAN)無關,屬於「區塊層級(Block Level)」的儲存複本機制,支援採用「同步(Synchronous)」及「非同步(Asynchronous)」兩種不同的資料複寫方式,以 SMB 3通訊協定來進行資料的複寫傳送。

它並非是資料備份的解決方案,而是「災難備援(Disaster Recovery,DR)」的解決方案,透過 SR 儲存複本機制將資料複寫到另外的伺服器或叢集當中,除了提升企業或組織的「服務等級協議(Service Level Agreements,SLA)」之外,更能有效降低「復原時間目標(Recovery Time Objective,RTO)」及「復原點目標(Recovery Point Objective,RPO)」。

此外,SR(Storage Replica)儲存複本機制,可以跟 Hyper-V、Storage Spaces Direct、Cluster、SOFS(Scale-Out File Server)、Deduplication 等特色功能協同運作,並且支援採用 ReFS / NTFS / CSVFS 等新舊檔案系統。並且 Storage Replica 在使用案例上,又可以區分出「Server to Server」、「Stretch Cluster」、「Cluster to Cluster」等不同的應用情境。

事實上,Storage Replica儲存複本特色功能,也支援單台實體伺服器「自我複寫(Server-to-Self Replication)」機制,也就是可以單台伺服器中多個磁碟區進行資料複寫的動作,但這樣仍有 SPOF 單點失敗的風險。

圖 1、Storage Replica 使用案例運作架構示意圖

2、同步複寫機制

當採用「同步(Synchronous)」複寫機制時,系統將會保證每次的資料 IO 作業完成之前,都會將資料寫入至少兩個不同的位置之後,才會回覆給上層的應用程式已完成 IO 作業。所以,當來源端節點主機發生故障損壞事件時,便可以進行容錯備援的切換動作,接著讓應用程式使用目的端節點主機的資料快速恢復運作。因此,它適合應用於需要高可用性及災難復原,也就是「零資料損失(Zero Data Loss)」的營運服務。

下列為採用同步複寫機制時,兩端主機之間資料複寫的動作如下:

1. 應用程式發出寫入資料需求。
2. 來源端節點主機將資料寫入至本地端儲存資源「日誌(Log)」當中,同時透過 SMB 3協定將資料傳輸至目的端節點主機。
3. 目的端節點主機,將所收到的資料寫入至本地端儲存資源「日誌(Log)」當中。
4. 目的端節點主機寫入完成後,回覆給來源端主機已完成 IO 動作。
5. 來源端節點主機回覆應用程式確認已完成 IO 動作。

最後,當回覆給上層應用程式完成 IO 動作之後,來源端及目的端節點主機才會真正透過日誌磁碟區中的確認資料,執行更新寫入磁碟區資料的動作。

圖 2、Storage Replica「同步(Synchronous)」複寫機制運作架構示意圖

3、非同步複寫機制

當採用「非同步(Asynchronous)」複寫機制時,系統會在本地端完成 IO 作業後便立即回覆給上層的應用程式,之後才將資料複寫到另一個位置。所以,這樣的資料複寫機制仍然有資料遺失的風險存在,只能達成「近乎零資料損失(Near Zero Data Loss)」的運作環境,因此並不適合用於需要高可用性的運作環境中(例如,容錯移轉叢集)。

下列為採用非同步複寫機制時,兩端主機之間資料複寫的動作如下:

1. 應用程式發出寫入資料需求。
2. 來源端節點主機將資料寫入至本地端儲存資源「日誌(Log)」當中。
3. 來源端節點主機回覆應用程式確認已完成 IO 動作。
4. 透過 SMB 3 協定將資料傳輸至目的端節點主機。
5. 目的端節點主機,將所收到的資料寫入至本地端儲存資源「日誌(Log)」當中。
6. 目的端節點主機寫入完成後,回覆給來源端主機已完成 IO 動作。

圖 3、Storage Replica「非同步(Asynchronous)」複寫機制運作架構示意圖

4、儲存複本功能整理

在下列表格當中,我們將儲存複本功能的特色功能進行概要整理:


5、實作 Server to Server 同步複寫機制

此實作為儲存複本機制中「Server > Server」方式,目前在 Windows Server 2016 技術預覽當中,針對此使用情境的部分,並沒有GUI 圖形化工具可以進行組態設定作業,因此將統一採用 PowerShell 進行實作。

這兩台進行儲存複寫的單機伺服器,它們可以位於同一個站台或是不同站台皆可。本次實作環境中,兩台主機將位於同一個站台同一個網域當中,但是擺放在不同樓層的實體位置,以期能夠因應故障損壞事件。

圖 4、Server to Server 儲存複本運作架構示意圖

先決條件

下列項目為實作儲存複本機制時,每台實體伺服器所應採用及注意的先決條件事項,後續在進行實作之前我們也會使用 Test-SRTopology指令,來進行儲存複本實作前的環境檢查作業:

  • 支援採用的儲存資源種類有 SAS JBODs、Fibre Channel SAN、iSCSI Target、DAS…等。
  • 在儲存資源中的硬碟種類,應該要包含一般機械式硬碟(用來存放資料),以及 SSD 固態硬碟(用來存放日誌)。
  • 在網路傳輸的部分,至少應該有 1 條專用的 1GbE 傳輸線路,或是 10GbE、RDMA(RoCE、iWARP、InfiniBand),並且平均 ≤5ms 的來回延遲時間。
  • 在防火牆規則的部分,在來源端及目的端的節點主機當中,都需要允許 ICMP、SMB(Port 445、5445)、WS-MAN(Port 5985)流量可以進行雙向通訊。

初始環境組態設定

了解實作儲存複本的環境需求後,接著便可以進行初始環境的設定作業了。在此次的實作環境中,將會有三台實體伺服器,一台主機擔任網域控制站的角色,另外二台主機(SR-SRV01、SR-SRV03)則是實作儲存複本 Server to Server 機制。

首先,實作儲存複本機制的主機,採用的 Windows Server 2016必須為 DataCenter版本才行,在官方的規劃中 Standard 版本並不支援儲存複本機制。安裝好 Windows Server 2016 作業系統後,組態設定好 IP 位址及電腦名稱並且加入網域後重新啟動主機。

圖 5、實作儲存複本機制的主機順利加入網域

確認實作儲存複本機制的二台主機所採用的儲存資源種類(JBOD / iSCSI / FC SAN / DAS),此實作環境中二台主機採用 DAS(Direct-Attached Storage),也就是實體伺服器的本機硬碟來擔任儲存資源。如果,採用 JBOD、iSCSI、FC SAN 等儲存資源時,應該採用儲存設備廠商所提供最新最穩定的 Firmware及驅動程式。

此外,在實作伺服器方面,除了也應採用最新最穩定的 BIOS/UEFI Firmware版本之外,其它如主機板、網路卡、晶片組…等驅動程式也應採用最新穩定版本。在 BIOS 設定的部分,建議停用 C-State節省電力設定,並啟用 QPI Speed、NUMA、High Performance…等設定,以便讓伺服器保持在最佳效能狀態。

選擇好採用的儲存資源後,在實作儲存複本機制之前仍有相關注意事項如下:

  • 至少要建立兩個磁碟區,一個磁碟區用於儲存資料,另一個磁碟區則用於儲存日誌
  • 用於儲存複本機制的兩個磁碟區,僅能採用新式的 GPT 進行初始化而非舊式的 MBR
  • 實作儲存複本機制的兩台伺服器,不管是資料磁碟區或日誌磁碟區其儲存空間大小必須一致
  • 日誌磁碟區,至少要 8GB的儲存空間,並且視複寫的資料磁碟區空間大小而相對應增加空間,同時建議採用反應快速的儲存資源,例如,SSD 固態硬碟進行儲存。
  • 資料磁碟區,最大支援至 10TB的儲存空間,可以採用一般機械式硬碟、SSD 固態硬碟,也支援採用 RAID 1、10、5、50,也支援內建的 Storage Space(Tier、Mirror、Parity)等 Virtual Disk。
  • 進行儲存複本的磁碟區,應該包含系統磁碟區(System Volume)、分頁檔案(Page File)、傾印檔案(Dump Files)。

在本文的實作環境中,為兩台伺服器增加二顆硬碟,分別是 100GB用來擔任資料磁碟區,並且給予 D磁碟機代號及 SR-Data的磁碟標籤,以及 10GB用來擔任日誌磁碟,並且給予 L磁碟機代號及 SR-Log的磁碟標籤以利識別。

圖 6、兩端主機分別新增 100GB 資料磁碟區及 10GB 日誌磁碟區

安裝 Storage Replica 功能

完成兩台伺服器的初始化設定後,便可以接著為兩台伺服器安裝相關角色及功能。請開啟伺服器管理員後,安裝「File Server」角色以及「Storage Replica」功能(包含管理工具)。

圖 7、安裝 File Server 角色及 Storage Replica 功能

你也可以採用 PowerShell指令「Install-WindowsFeature –Name Storage-Replica,FS-FileServer –IncludeManagementTools –Restart」,進行角色及功能的安裝作業。

環境測試

在開始真正進行儲存複寫的動作以前,建議先進行環境測試作業,以便再次確認所建立的儲存複本運作環境屆時能運作無誤。

簡單來說,環境測試作業便是使用 Test-SRTopology指令,模擬執行儲存複本作業並產生報表檔案以便確認,但若只是單純模擬執行但卻沒有實際資料 IO 的話,那麼產生的報表檔案便不具備參考價值。因此,我們可以下載 DISKSPD工具,幫助我們產生資料 IO 工作負載,並配合模擬執行儲存複本作業即可達成環境測試的目的。

在執行 Test-SRTopology 指令進行儲存複本環境測試作業之前,我們將會以下列 DISKSPD 指令產生資料 IO 工作負載持續 5 分鐘(300 秒)。值得注意的是,因為此次實作環境中我們的資料磁碟區是在「D 槽」,因此 DISKSPD 指令產生的資料 IO 工作負載便寫入至 D 槽。
Diskspd.exe –c1g –d300 –W5 –C5 –b8k –t2 –o2 –r –w5 –h d:\io.dat

接著,便可以執行 Test-SRTopology指令進行儲存複本環境測試作業,指令的參數都非常直覺也就是指定來源端及目的端節點主機相關資訊,例如,電腦名稱、資料磁碟區、日誌磁碟區、測試時間、測試間隔...等。最後,我們指定環境測試的報表檔案產生在 C:\tmp資料夾內,檔案名稱將為「TestSrTopologyReport-<日期>-<時間>.html」。
Test-SRTopology -SourceComputerName SR-SRV01 -SourceVolumeNames D: -SourceLogVolumeName L: -DestinationComputerName SR-SRV03 -DestinationVolumeNames D: -DestinationLogVolumeName L: -DurationInMinutes 5 -IntervalInSeconds 1 -ResultPath C:\tmp

圖 8、儲存複本環境測試報表檔案概觀

從環境測試報表檔案內容中可以看到,通過所有的環境測試作業及建議值,以此次實作環境來看系統建議的日誌磁碟區只要採用預設的「8 GB」即可,並且兩台主機之前的網路環境平均延遲時間也在「5 ms」之內。

圖 9、儲存複本環境測試報表: 先決條件測試結果及初始化同步效能測試結果

建立儲存複本機制 – 新增複寫合作夥伴

順利通過儲存複本的環境檢查及測試作業後,接著我們就可以著手建立儲存複本機制。事實上,建立儲存複本機制的 New-SRPartnership指令,與剛才的 Test-SRTopology測試指令相當類似,不同的是有其它進階參數可以使用。

  • -ReplicationMode:指定儲存複寫模式,預設值為「同步(Synchronous)」複寫,可依環境需求指定採用「非同步(Asynchronous)」複寫(目前僅支援 Server > Server)。
  • -Seeded:資料衝突的處理方式,預設值為「False」也就是來源端資料直接「覆蓋」目的端磁碟區的資料,可依環境需求指定採用「True」也就是「合併」來源端與目的端磁碟區的資料。
  • -LogSizeInBytes:日誌磁碟區大小,至少指定 8GB大小,並參考 Test-SRTopology 指令的測試結果建議值。

圖 10、建立儲存複本機制-新增複寫合作關係

查詢儲存複寫資訊 – 複寫群組

順利建立儲存複本機制之後,可以使用「Get-SRGroup」指令查詢複寫群組資訊。事實上,複寫群組儲存著複寫合作夥伴的組態設定內容,並且每個複寫群組可以包含「一個或多個」磁碟區。

圖 11、查詢複寫群組資訊

查詢儲存複寫資訊 – 複寫合作夥伴

你可以使用「Get-SRPartnership」指令,來查詢儲存複本的複寫合作夥伴資訊,以便了解來源端主機及目的端主機,以及複寫群組等相關資訊。

圖 12、查詢複寫合作夥伴資訊

查詢儲存複寫資訊 – 磁碟複寫

你可以使用「(Get-SRGroup).Replicas」指令,搭配指定的來源端主機或目的端主機的電腦名稱,即可查詢磁碟複寫資訊,例如,資料磁碟區、複寫模式...等。

圖 13、查詢磁碟複寫資訊

查詢儲存複寫資訊 – 複寫事件

此外,你也可以開啟事件檢視器後,依序點選「Applications and Services Logs > Microsoft > Windows > StorageReplica > Admin」查看相關事件,在「來源端主機」中你將會看到 Event ID 1237、2200、5001、5002、5004、5015...等事件,在「目的端主機」中你將會看到 Event ID 1237、2200、5001、5005、5009、5015...等事件。

圖 14、查詢複寫事件

或者,你也可以在 PowerShell 視窗中鍵入「Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica –max 10」指令,顯示最新 10筆事件,然後搭配過濾參數及 Event ID 的方式,來檢視指定 Event ID 的複寫事件。

圖 15、以 PowerShell 查詢儲存複寫事件

監控儲存複寫效能數據

事實上,當你為主機安裝 Storage Replica 功能之後,系統便會新增二項效能監控項目分別是「Storage Replica Partition I/O Statistics」及「Storage Replica Statistics」。你可以分別加入監控這二個項目,以便了解儲存複寫的相關效能表現。

圖 16、監控儲存複本機制資料複寫效能數據

反轉複寫方向

事實上,在儲存複本的運作機制當中,當來源端主機與目的端主機建立複寫合作夥伴關係之後,目的端主機的資料磁碟區(此實作為 L 槽),便會取消磁碟機代號以及磁碟標籤,同時檔案系統也從原本的 NTFS轉變為 RAW,以避免儲存複寫當中的資料磁碟區被不當寫入資料。

圖 17、建立複寫合作夥伴關係之後,磁碟區將轉變為 RAW 避免被不當寫入資料

此外,目前在 Windows Server 2016 TP3 版本中,並沒有指令可以輕鬆驗證目的端主機的資料磁碟區當中,存放與來源端主機資料磁碟區一模一樣的檔案。因此,最簡單的驗證方式,便是反轉複寫方向即可進行驗證。

首先,於來源端主機中執行「Sync-SRGroup –Name SR-RG01 –Force」指令,讓來源端主機當中的複寫群組,將手上所擁有的所有資料磁碟區,再次強迫複寫資料至目的端主機。接著,便可以使用「Set-SRPartnership」指令,指定新的來源端主機及複寫群組名稱,以及新的目的端主機及複寫群組名稱,便可以進行反轉複寫方向的動作。最後,再執行「Get-SRPartnership」指令,確認是否真正完成反轉複寫方向的動作。

圖 18、反轉複寫方向

順利反轉複寫方向之後,原本的目的端主機(SR-SRV03)現在變成來源端主機,所以你可以切換至該主機查看資料磁碟區,現在 SR-SRV03 主機的 D 槽便可以順利看到檔案,不再是先前避免寫入的鎖定狀態 RAW,同時進入 D 槽後便可以看到剛才進行資料複寫的相關檔案。

移除儲存複寫機制

最後,如果你希望移除儲存複寫機制的話,那麼請先使用「Get-SRPartnership」指令確認目前的儲存複寫資訊。接著,切換到「來源端」主機上執行「Get-SRPartnership | Remove-SRPartnership」指令,然後在「來源端及目的端」主機上執行「Get-SRGroup | Remove-SRGroup」指令,即可順利移除儲存複寫機制。

圖 19、移除儲存複寫機制

6、結語

透過本文的說明及實作演練,讀者應該了解 Windows Server 2016 儲存複本的強大功能。在本文中因為篇幅的關系,僅實作儲存複本機制中 Server to Server 的部分,在後續的文章當中將為大家進一步實作,整合 Hyper-V 及 Storage Space Direct 的進階 Stretch Cluster Cluster to Cluster部分。

VMware Taiwan vForum 2015 簡報開放下載

$
0
0

前言

日前 (2015.12.9),在 Taiwan 舉辦的 VMware Taiwan vForum 2015 議程簡報已經開放下載了,有興趣的朋友可以參考看看。

簡報下載

主題演講



分會場 1、資料中心虛擬化



分會場 2、網路暨安全虛擬化



分會場 3、儲存虛擬化



分會場 4、雲端基礎架構管理



分會場 5、行動終端應用管理



分會場 6、Cloud Native Application for DevOps

更新 Mellanox CX3 Firmware

$
0
0

前言

因為要採用 Mellanox ConnectX-3來測試  SMB Direct (RDMA)的一些功能,但遭遇到一些問題所以試試更新 Firmware 版本試試,為了避免下次忘記所以寫個筆記錄一下吧  :)

更新 Mellanox ConnectX-3 Firmware 版本

下載及安裝 WinMFT (Mellanox Firmware Tools)


執行下列指令,確認目前 OCP Mezz 的 PCI Device Name 及 Firmware version。
C:\Program Files\Mellanox\WinMFT> mlxfwmanager.exe --query

目前手邊的 Firmware 有 2 個更新檔案,必須依序往上升級,最後版本為 2.33.5140。
C:\Program Files\Mellanox\WinMFT> flint -d mt4103_pci_cr0 -i C:\tmp\mx1.bin -allow_psid_change -nofs burn
C:\Program Files\Mellanox\WinMFT> flint -d mt4103_pci_cr0 -i C:\tmp\mx2.bin -allow_psid_change -nofs burn


上述指令中相關參數說明如下:
  • -d Device: flash is connected to.
  • -i Image: Binary image file. Commands affected: burn, verify.
  • -allow_psid_change: Allow burning a FW image with a different PSID (Parameter Set ID) than the one currently on flash. Note that changing a PSID may cause the device to malfunction. Use only if you know what you are doing.
  • -nofs: Burns image in a non failsafe manner.

更新後再次查看 Firmware 資訊如下

實作 Hyper-V Nested Virtualization

$
0
0

前言

在 Hyper-V 虛擬化化平台舊版本中,要實作出 Nested Virtualization環境非常困難。現在,從 Windows Server 2016 TP4 (10565 之後) 版本,開始支援「Nested Virtualization in Windows Server Hyper-V」機制,往後要建置 Lab 環境將更加容易了。

簡單來說,若是舊版的 Hyper-V 虛擬化化平台,便僅支援 Level 0、Level 1這樣的運作架構。


現在,可以在 Hyper-V Hypervisor (Level 1) 當中,再產生出一層 Hyper-V Hypervisor (Level 2),並且能夠運作 Guest OS。


下列為目前 Hyper-V Nested Virtualization 的環境需求:
  • Nested VM 至少要指派 4GB虛擬記憶體空間。
  • VM 虛擬主機必須啟用 vCPU 的 Virtualization Extensions 功能。
  • VM 虛擬主機必須啟用 MAC Address Spoofing功能。
  • Level 1的 Hyper-V Hypervisor 及 Level 2的 Hyper-V Hypervisor,應該要採用相同的版本。簡單來說,都採用 Windows Server 2016 TP4 版本即可,值得注意的是,目前支援 Hyper-V Hypervisor而已,還支援其它 Hypervisor。

下列為 Level 2 上運作的 VM (Nested VM) 的相關限制:
  • 上層母體的 Device Guard機制無法套用。
  • 上層母體的 VBS (Virtualization Based Security)機制無法套用。
  • 必須要停用 VM 動態記憶體功能。
  • Runtime Memory Resize機制會失敗。
  • 套用 Checkpoint時會失敗。
  • Live Migration 動作會失敗。
  • Save / Restore 動作會失敗。

實作 Hyper-V Nested Virtualization

首先,我們可以看到在 Level 1Hyper-V Host 中,所建立的 VM 虛擬主機採用 Coreinfo檢查後可以發現,目前的 VM 虛擬主機「尚未感知」到母體的虛擬化功能。


請在 Level 1 的 Hyper-V Host 中,執行下列指令將 Hyper-V Host 的硬體輔助虛擬化技術「傳遞」給 VM 虛擬主機 (此實作該 VM 的名稱為 TestVM)。 (當然,前提是 Hyper-V Host支援 Intel VT-x / EPT硬體輔助虛擬化技術)。
PS C:\tmp> Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile ~/Enable-NestedVm.ps1
PS C:\tmp> ~/Enable-NestedVm.ps1 -VmName "TestVM"



執行後,在啟用 Nested VM 機制的指令碼中,將會詢問是否啟用 TestVM虛擬主機的「vCPU Virtualization Extenstions」及「MAC Address Spoofing」功能,請鍵入 Y確認啟用。


此時,開啟 TestVM 後再度使用 Coreinfo檢查後可以發現,目前的 TestVM 已經可以「感知」到 Hyper-V Host 所傳遞過來的硬體輔助虛擬化技術。


因此,便可以放心安裝 Hyper-V 伺服器角色了。


Hyper-V Nested Virtualization 達成!!


參考資源

SSD - NVMe、SAS、SATA 介面

$
0
0

前言

簡單來說,現在 Windows Server 2016 SDS 軟體定義儲存技術,不同於以往僅支援 SAS SSD,現在更支援「NVMe SSD」、「SATA SSD」,那麼這三者之間的介面有何不同,順手作個記錄吧。

NVMe / SAS / SATA

那麼廢話不多說,直接來看看這三種介面有何不同,至於詳細資訊請參考下列相關連結即可:



Viewing all 596 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>