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


前言

簡單來說,「Docker」本來是 dotCloud 公司內部的一個業餘專案,並採用 Google 的 Go 語言進行實作的產品。後來 dotCloud 公司將此專案加入 Linux 基金會並在 GitHub 上進行維護,迅速受到開發人員的喜愛,甚至 dotCloud 公司改名為 Docker Inc。有關 Docker 的一些歷史及觀念介紹因為《Docker — 從入門到實踐­》已經很清楚的說明,在此便不再贅述。此外,有時間也可以看一些相關影片:


雖然,在 Windows 作業系統中導入 Docker / Container 容器環境,但是整個實作技術跟 Linux 是完全不同的。簡單來說,Linux Image 是無法運作在 Windows Server Container 當中的,而 Windows Image 也無法運作在 Linux Container 容器環境,因為是採用「不同 API (Windows API vs Linux API)」運作環境,那麼我們來看看有哪些根本上的不同:

Linux Container
  • Control Group: 控制群組,針對共享資源進行隔離並管控硬體資源的使用 (例如,管理記憶體、檔案快取、CPU、磁碟 I/O…等使用率)。
  • Namespaces: 命名空間,確保每個容器都有單獨的命名空間,讓容器之間的運作互相不受影響。
  • AUFS: 檔案系統,不同容器可以共享基礎的檔案系統層,同時實現分層功能並將不同目錄掛載到同一個虛擬檔案系統中。

Windows Container
  • Job Objects: 類似 Linux 的控制群組機制。
  • Object Namespace、Process Table、Networking: 類似 Linux 的命名空間機制。
  • Compute Service: 作業系統層級的運算服務層。
  • NTFS: 每個運作的容器各自擁有 1 份 NTFS 分區表,並搭配虛擬區塊儲存裝置來建立容器多層式檔案系統,接著再利用 Symlink 運作機制把不同層的檔案對應到 Host 環境檔案系統內的實際檔案,以便減少虛擬區塊儲存裝置所占用的儲存空間。


Windows Server Container vs Hyper-V Container
微軟設計 2 種不同的 Container 容器環境,以便因應不同的環境的運作需求。同時,不同的 Windows 作業系統版本支援不同的 Container 容器環境 (例如,Windows 10 並不支援 Windows Server Container,所以用 Windows 10 玩的話必須要先安裝 Hyper-V 功能才行)。


那麼,我們概略了解一下 Windows Server Container 及 Hyper-V Container 有哪些不同:
  • Windows Server Container: 共用系統核心資源 (與 Linux Container 類似)。
  • Hyper-V Container: 獨立系統核心資源。Hyper-V 容器並非傳統的 Hyper-V VM 虛擬主機,而是運作 Windows Server Container 的特殊虛擬主機器,並且具備獨立的系統核心、Guest 運算服務、基礎系統執行程序……等。


為了方便進行 Docker 環境的測試作業,我採用 Microsoft Azure 建立 Windows Server 2016 Datacenter 虛擬主機。因為本文並非要討論 Microsoft Azure 所以如何建立 Windows 虛擬主機就不多說明了。😁






安裝 Docker 容器環境

首先,我們安裝 OneGet Provider PowerShell 模組,然後使用 OneGet 安裝最新版的 Docker (包含安裝 Windows Feature 中的 Container),當 PowerShell 詢問是否要信任封裝來源 'DockerDefault' 時,輸入 Y 或 A 以便繼續安裝程序。當安裝作業完成後,系統也提示你應該重新啟動電腦以便套用生效。
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider
Restart-Computer -Force


裝好 Docker 容器環境並重新啟動後,便會發現多出「vEthernet (HNS Internal NIC)」 網段就是 172.x.x.x / 255.255.240.0,後續在討論 Docker Network 時再來深入了解這部分。






基礎操作

安裝好 Windows Server Container 容器環境後,便可以透過「docker info」指令查看 Docker 容器環境的運作資訊:


透過「docker version」指令,馬上確認目前 Docker 容器環境的 Client / Server 版本。






永遠的範例 Hello-World

那麼,讓我們開始使用 Docker 容器環境吧,不免俗的第 1 個範例就是透過 Docker 容器環境執行列出字串「Welcome to using .NET Core!」吧。在這項練習中,您將從 Docker Hub 登錄下載預先建立的 .NET 範例映像,並部署執行 .Net Hello World 應用程式的簡單容器。
docker run microsoft/dotnet-samples:dotnetapp-nanoserver

同樣的,此時可以透過「docker images」指令查看已經下載的 Docker 映像檔資訊。


在 Windows 運作環境中的容器基礎映像的部分,目前有「Windows Server Core (9.56 GB)」及「Nano Server (925 MB)」。可以透過下列指令從 Docker Hub 下載
docker pull microsoft/windowsservercore
docker pull microsoft/nanoserver








參考資源


活動簡介

根據知名市調機構 Gartner 的統計調查結果,從 2016 年開始有「2/3 以上」的企業及組織,將開始建構及整合「Mode 2」的敏捷式 IT 基礎架構,所謂「基礎架構敏捷化」(Infrastructure Agility),便是著重於 IT 基礎架構中「Mode 2」的部分以便因應商業數位化的需求。

此外,根據 Gartner 的預測,在 2017 年時全球大型企業中將有高達「75 %」的比例,會建立 Mode 1 及 Mode 2 的雙重 IT 基礎架構稱之為「Bimodal IT」。在傳統 Mode 1 當中的工作負載、技術、流程、部署模式已經行之有年無須再驗證,但 Mode 2 是新興的方式並在根本上與 Mode 1 不同,它強調的是「敏捷性」(Agility)「可擴充性」(Scalability)以提高開發人員的生產力,達到快速推出新服務的一種方式,舉例來說,「容器」(Container)技術可以幫助開發人員達到更好的敏捷性。簡單來說,傳統的 Mode 1 運作架構專注於「基礎架構管理」,而新興的 Mode 2 則是專注於「工作負載為中心」。

在本次聚會中將快速與大家討論及實作,如何透過 Microsoft Azure 公有雲環境,快速建立 ubuntu、CentOS、FreeBSD 虛擬主機,並且安裝及建立 Docker 容器測試環境。同時,也將實作及展示 Windows Server 2016 Container 容器環境。



活動資訊



前言

簡單來說 OneNote 可以是個人或團隊內整理資料的萬用筆記本,個人在整理技術筆記上也是使用 OneNote,本文將整理幾個 OneNote 的好用之處有興趣的朋友不妨參考看看,有關 OneNote 的初步認識請參考導覽影片「什麼是 OneNote?」。



使用技巧整理





參考


前言

自從 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





參考資源


前言

自從 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…等。




參考資源


網管人雜誌

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





文章目錄

前言
在 Hyper-V 虛擬化平台上運作 Unix-Like
什麼是 Hyper-V 整合服務?
Unix-Like虛擬主機整合服務
          CentOS 虛擬主機安裝整合服務
          FreeBSD 虛擬主機安裝整合服務
結語





前言

談到微軟作業系統,某些 IT 人員便認為在作業系統的部分一定是只有 Windows。雖然,Windows 偶爾有推出與開放源始碼整合的相關服務,但使用者通常仍覺得整合程度有限,但是這樣的狀況自從微軟 CEO Satya Nadella 上任並喊出 Microsoft Love Linux 之後便一一被打破,甚至最新推出的 Windows Server 2016 作業系統,還能夠原生執行 Container 容器技術。

同時,不光是地面上企業及組織的相關技術支援 Linux,就連微軟公有雲 Azure 也支援 Linux 作業系統的 VM 虛擬主機及相關服務,根據微軟的內部統計目前在 Azure 公有雲的 VM 虛擬主機工作負載當中,有 1/3 是運作 Linux 作業系統另外 2/3 才是運作 Windows 作業系統。

同時在 2016 年 3 月,微軟已經釋出 SQL Server on Linux 的封閉預覽測試版本,並宣佈預定於2017 年 Q2 將正式推出。屆時,在 Linux 作業系統中也可以安裝 Microsoft ODBC Driver for SQL Server,以便 Linux 作業系統能夠順利存取 SQL Server 資料庫服務。

圖 1、SQL Server on Linux 的封閉預覽測試版本

2016 年 4 月,微軟在 Build 開發者大會上正式宣佈,從 Windows 10(Build 14316)作業系統版本開始,將在 Windows 作業系統核心中加入子系統(Windows Subsystem for Linux),以便在 Windows 作業系統中能夠原生支援 Linux 使用者模式,這與舊有透過 Cygwin 模擬的方式完全不同。現在,你可以直接在 Windows 作業系統中原生執行 Ubuntu Bash、apt-get、git……等。

圖 2、運作 Ubuntu 原生 Bash 指令碼環境在 Windows 作業系統中

2016 年 8 月,微軟也宣佈自家的 PowerShell 指令碼工具正式 Open Sourced。現在,可以在多種 Linux 作業系統(例如,Ubuntu 14.04、Ubuntu 16.04、CentOS 7、OS X 10.11……等)中,直接透過 GitHub 下載安裝後運作 PowerShell 指令碼環境。

圖 3、在 CentOS 作業系統中運作 PowerShell 指令碼環境





在 Hyper-V 虛擬化平台上運作 Unix-Like

在 Hyper-V 虛擬化平台上運作 VM 虛擬主機,倘若客體作業系統採用 Windows 時相信 IT 管理人員應該不陌生,舉例來說,在 Windows Server 的部分支援 SBS 2011、2008 SP2、2008 R2、2012、2012 R2 以及最新版本的 Window Server 2016,至於 Desktop 的部分則支援 Vista SP2、7 SP1、8.1 及最新版本的 Windows 10。

那麼,倘若在 Hyper-V 虛擬化平台中要運作 Unix-Like 作業系統(例如,Linux 及 FreeBSD)時,哪些 Unix-Like 版本才有支援?倘若採用不支援的 Unix-Like 作業系統時是否無法運作在 Hyper-V 虛擬化平台上?Hyper-V 虛擬化平台能否運作 Unix(例如,AIX、HP-UX)或者是 Max OS X?

簡單歸納來說,Hyper-V 虛擬化平台無法運作 Unix 及 Max OS X。同時,當採用未支援的 Unix-Like 作業系統版本時,將會因為無法安裝「整合服務」(Integration Service),除了導致運作於 VM 虛擬主機當中的 Unix-Like 作業系統,無法針對相關虛擬硬體裝置安裝驅動程式與 Hyper-V 虛擬化平台進階功能整合之外,也將會影響 VM 虛擬主機的運作效能。

圖 4、Hyper-V 虛擬化平台是否能運作 Unix 及 Unix-Like 作業系統判斷流程示意圖





什麼是 Hyper-V 整合服務?

事實上,不管採用哪一種虛擬化平台都會需要幫其上運作的 VM 虛擬主機安裝適當的 Tools,以使其上運作的 VM 虛擬主機能夠與虛擬化平台進行最緊密的結合(例如,虛擬裝置驅動程式最佳化……等),舉例來說,倘若採用 VMware vSphere 虛擬化平台便需要幫 VM 虛擬主機安裝 VMware Tools,而 Citrix XenServer 虛擬化平台便需要幫 VM 虛擬主機安裝 Xen Tools。

在 Microsoft Hyper-V 虛擬化平台上,則是需要幫其上運作的 VM 虛擬主機安裝「整合服務」(Integration Services),安裝整合服務完畢後在驅動程式部份將會針對 IDE、SCSI、網路 、視訊 、滑鼠 …… 等方面進行最佳化,而在客體服務方面則會整合作業系統關閉(Shutdown)、時間同步化(Time Synchronization)、資料交換(Key/Value Exchange)、活動訊號(Heartbeat)、線上備份(Volume Shadow copy Service,VSS)……等機制,以期 VM 虛擬主機與 Microsoft Hyper-V 虛擬化平台不管是在效能運作上,或者是虛擬裝置驅動程式最佳化方面都能進行完美的結合。

圖 5、Hyper-V運作元件架構示意圖





Unix-Like 虛擬主機整合服務

倘若,您的 VM 虛擬主機安裝「Windows作業系統」的話,那麼在VM虛擬主機的Console視窗中可以直接執行插入整合服務安裝光碟的動作。當安裝「Linux 作業系統」如 RHEL / CentOS 時,Hyper-V 虛擬化平台雖然也支援「Emulated / Specific」2 種虛擬裝置,但是若需要發揮 Linux 作業系統最佳效能,建議您使用 Hyper-V Specific Devices 並配合安裝「LIS(Linux Integration Services)」,也就是專供 Linux 使用的整合服務映像檔並進行安裝才能達到效能最佳化。

專供 Linux 作業系統使用的 LIS 整合服務映像檔,目前最新版本為 4.1 您可至 Microsoft Download Center 下載「Linux Integration Services Version 4.1 for Hyper-V」,所下載整合服務映像檔名稱為「LinuxIC-4.1.2-2.iso」。

圖 6、下載專供 Linux 作業系統使用的 LIS 整合服務映像檔

LIS 4.1 for Hyper-V 整合服務,支援的 Linux 版本以 RHEL / CentOS 為例的話是 5.2 ~ 5.11、6.0 ~ 6.8、7.0 ~ 7.2,並且可以應用在多種Hyper-V虛擬化平台版本上,例如,Hyper-V 2.0(Windows Server 2008 R2)、Hyper-V 3.0(Windows 8 / 8.1 Pro、Windows Server 2012 / 2012 R2)以及最新的 Windows 10 和 Windows Server 2016。

最新的 LIS 4.1 版本中,除了原有整合服務的特色功能之外還支援下列 5 項新增功能:
  • Hyper-V Sockets。
  • 記憶體熱新增及移除。
  • SCSI WWN。
  • lsvmbus 指令。
  • 反安裝 LIS 整合服務指令碼。

安裝整合服務後的Linux虛擬主機,將具備核心(Core)、網路(Networking)、儲存(Storage)、記憶體(Memory)、視訊(Video)、其它(Miscellaneous)……等特色功能或最佳化效能:

核心(Core)

  • 整合式關機: 透過此功能,在開啟的VM Console視窗中便能為客體作業系統執行關機的動作,而無須登入至客體作業系統手動進行關機。
  • 時間同步處理: 確保VM虛擬主機能夠與Hyper-V主機保持時間同步。
  • 準確時間: 整合 Windows Server 2016 準確時間功能,改善主應用程式與時間同步處理的精確度,能夠將時間誤差值縮短在 1 毫秒的範圍內。
  • 多處理器支援: 支援組態配置 VM 虛擬主機多顆 vCPU 虛擬處理器,達到真正使用 Hyper-V主機多顆 CPU 處理器進行 SMP 平行運算。
  • 活動訊號: 以便 Hyper-V 虛擬化平台能夠偵測及追蹤 VM 虛擬主機運作狀態。
  • 整合式滑鼠支援: 滑鼠功能將可正常運作於 VM 虛擬主機的 Console 視窗中,以及自動在Hyper-V 虛擬化平台中正常切換。
  • Hyper-V 特定儲存裝置: 使 VM 虛擬主機擁有高效能及最佳化的 IDE/SCSI 儲存介面卡,有效提升工作負載能力。
  • Hyper-V 特定網路裝置: 使 VM 虛擬主機擁有高效能及最佳化的 Network Controller 介面卡,有效提升工作負載能力。

網路(Networking)

  • Jumbo Frame: 可設定 MTU 數值大於 1500 bytes 以增加網路效能。
  • VLAN Tagging 及 Trunking: 支援單一 VLAN ID 或多個 VLAN ID Trunking 網路環境。
  • 即時遷移: 讓 VM 虛擬主機支援即時遷移(Live Migration)、無共用儲存即時遷移(Shared Nothing Live Migration)、Hyper-V複本(Hyper-V Replica)…… 等進階功能。
  • 靜態 IP 導入: 當 Hyper-V 主機執行複本容錯移轉之後,因為已經複寫 VM 虛擬主機靜態 IP 位址,所以能夠確保網路工作負載能在發生容錯移轉事件後無縫繼續運作。
  • vRSS 虛擬接收端調整: 將 VM 虛擬主機虛擬網路卡的工作負載,平均分散到 VM 虛擬主機中的多個 vCPU 虛擬處理器。
  • TCP 分割和總和檢查碼卸載: 在傳輸網路數據時,從 VM 虛擬主機的 vCPU 虛擬處理器到 Hyper-V 主機的 vSwitch 虛擬網路交換器之間,進行資料分割及總和檢查碼的動作。
  • LRO 大型接收卸載: 透過將多個封包彙總為更大的緩衝區,以便提升高網路頻寬流入的傳輸量,進而降低 CPU 運算資源的開銷。

儲存(Storage)

  • VHDX 調整大小: 系統管理員可以隨時因應需求,線上調整 VM 虛擬主機的 VHDX 磁碟空間。
  • vHBA 虛擬光纖通道: 讓 VM 虛擬主機能夠感知原生光纖通道裝置,進而支援及使用虛擬光纖通道功能。
  • VM 虛擬主機即時備份: 讓 VM 虛擬主機能夠在運作中的情況下進行備份作業。
  • TRIM: 當應用程式不再需要磁碟空間時,協助執行磁碟空間回收的動作。
  • SCSI WWN: Storvsc 驅動程式將會擷取連接埠和連接至 VM 虛擬主機的全球名稱(WWN),以便建立適當的 sysfs 檔案。

記憶體(Memory)

  • PAE 核心支援: 在 Linux 作業系統中透過 PAE 技術,可以讓 32 位元核心存取超過 4 GB 的記憶體位址空間。舉例來說,舊版的 RHEL 5.x 必須個別在核心中啟用 PAE 功能,而較新版的 RHEL 6.x 則核心已經預先啟用 PAE 功能。
  • MMIO: 協助 JeOS(Just Enough Operating Systems)與 Hyper-V 主機實體記憶體區塊進行對應的動作。
  • 記憶體熱新增及移除: 提供 VM 虛擬主機在運作狀態中,線上動態增加及移除記憶體空間的機制。
  • Ballooning: 活化 Hyper-V 主機記憶體空間,以便渡過記憶體空間暫時不足的因應機制。

視訊(Video)

  • 特定視訊裝置: 提供 VM 虛擬主機高效能及高解析的視訊介面卡,但是此裝置並不提供增強的工作階段模式及 RemoteFX 功能。

其它(Miscellaneous)

  • KVP(Key-Value Pair)Exchange: 取得 VM 虛擬主機在資料方面讀取(Read)/ 寫入(Write)等資訊。
  • NMI 非遮罩式插斷: 協助 VM 虛擬主機當中的客體作業系統,因為應用程式漏洞而發生的崩潰情況,再主機重新啟動後有機會分析導致系統發生崩潰的原因。
  • 客體與主機進行檔案複製: 透過客體服務讓 VM 虛擬主機與 Hyper-V 主機之間,在進行檔案複製作業時無須透過網路介面卡進行傳輸。
  • lsvmbus 指令: 透過此指令可以獲得 Vmbus 的相關資訊。
  • Hyper-V Sockets: 透過載入 Hyper-V Sockets 核心模組,讓 VM 虛擬主機與 Hyper-V 主機之間建立專屬的通訊通道。
  • PCI Passthrough: 將安裝於 Windows Server 2016 主機上的 PCI Express 裝置,例如,網路介面卡、GPU 顯示卡……等,以直接傳遞的方式指派給 VM 虛擬主機使用。

那麼在 Hyper-V 虛擬化平台上所運作的 Linux 作業系統,哪種發行套件及版本分別支援上述說明的功能呢,舉例來說,採用新版 CentOS 7.0 雖然核心中已經支援 Hyper-V 裝置最佳化,但是仍無法使用 vRSS 功能,必須要採用更新的 CentOS 7.1 或 7.2 版本才支援,在 Ubuntu Server 也是一樣的情況,你會發現 Ubuntu 12.04 並不支援 vRSS 功能,必須使用新版本的 Ubuntu 14.04、16.04 或 16.10 才支援。

為了避免不必要的篇幅,在此便不將 Hyper-V 虛擬化平台所支援 Linux 發行套件及版本其所對應的功能逐一說明,有興趣的讀者不妨直接瀏覽 Microsoft 官方網站查詢及核對所支援的特色功能項目:
圖 7、RHEL / CentOS 版本及特色功能對應表



CentOS 虛擬主機安裝整合服務

當管理人員為 VM 虛擬主機,安裝舊版 RHEL / CentOS「5.2 ~ 5.8、6.0 ~ 6.3(32 或 64 位元)」時,那麼必須要為 RHEL/CentOS 客體作業系統安裝「Linux Integration Services Version 4.1 for Hyper-V」整合服務。

其它較新版本 RHEL / CentOS「5.9 ~ 5.11、6.4 ~ 6.8、7.0 ~ 7.2(32 或 64 位元)」,因為官方已經直接在該版本的 Linux 核心當中,直接內嵌 Hyper-V 相關虛擬裝置驅動程式。

因此,當 VM 虛擬主機安裝這些新版本的 RHEL/CentOS 客體作業系統版本後,其實可以無須再額外安裝 LIS 4.1 整合服務。除非,你希望使用 LIS 4.1 整合服務所提供的新增功能,例如,在預設情況下 CentOS 7.2 版本內建的整合服務,並未支援 SCSI WWN、lsvmbus 指令、Hyper-V Sockets 等功能。

那麼,當我們為 VM 虛擬主機安裝新版 CentOS 7.2 客體作業系統後,登入 CentOS 客體作業系統鍵入相關指令「uname -a、cat /etc/redhat-release、cat /var/log/dmesg | grep Vmbus」,便可以看到目前採用的 Linux 核心版本為「3.10.0-327.e17.x86_64」,採用的 CentOS 版本為「7.2.1511」,至於 Hyper-V 整合服務所使用的 hv_vmbus 版本則為「3.0」

圖 8、CentOS 7.2 客體作業系統版本資訊,以及內建的 Hyper-V LIS 整合服務資訊

接著,我們從 Hyper-V 虛擬化平台方面,透過 Hyper-V 管理員來驗證此台 VM 虛擬主機是否真的已經支援整合服務了。首先,點選安裝 CentOS 7.2 的 VM 虛擬主機後,在下方 Hyper-V 管理員「摘要」頁籤中,可以看到活動訊號欄位的顯示結果為「良好(無應用程式資料)」,表示 Hyper-V 虛擬化平台可以正確偵測到VM虛擬主機運作狀態。

切換到「記憶體」頁籤後,您可以看到記憶體需求及記憶體狀態欄位為「1036 MB、確定」,表示 Hyper-V 虛擬化平台的動態記憶體功能,與目前 CentOS 客體作業系統已經順利協同運作了。
請注意! 倘若採用舊版 Windows Server 2012 虛擬化平台版本的話,則「尚未」支援 Linux 作業系統動態記憶體功能,必須採用 Windows Server 2012 R2 或新版 Windows Server 2016 虛擬化平台版本,才正式支援動態記憶體功能。

切換到「網路功能」頁籤中,你會看到在狀態欄位的部分顯示結果為「良好(VMQ 作用中)」,表示 CentOS 客體作業系統已經採用內建的整合服務,為 VM 虛擬主機所指派使用的虛擬網路介面卡,安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。

圖 9、新版 CentOS 7.2 已經內建 LIS 整合服務

倘若,你希望測試新版 LIS 4.1 整合服務中 lsvmbus 指令及 Hyper-V Sockets 功能的話,那麼便需要為 CentOS 7.2 安裝 LIS 4.1 整合服務。請為 VM 虛擬主機掛載剛才下載的 Linux Integration Services Version 4.1 for Hyper-V 整合服務映像檔 LinuxIC-4.1.2-2.iso,準備為 CentOS 7.2 作業系統安裝整合服務。

圖 10、為 VM 虛擬主機掛載 LIS 整合服務映像檔

順利掛載 LIS 整合服務映像檔之後,回到 CentOS 7.2 虛擬主機 Console 畫面,請依序鍵入指令「mount /dev/cdrom /media、cd /media/CentOS72、./install.sh」,執行掛載光碟機資源、切換到適合安裝的整合服務 CentOS 版本路徑、安裝整合服務等動作。

圖 11、為 CentOS 7.2 安裝新版 LIS 4.1 整合服務

當新版 LIS 4.1 整合服務安裝完畢後,請將 CentOS 7.2 客體作業系統重新啟動並卸載 LIS 整合服務映像檔。當 CentOS 7.2 客體作業系統重新啟動完畢後,便可以透過「/sbin/modinfo hv_vmbus」指令查看 hv_vmbus 版本,可以從指令執行結果中看到已經採用最新「4.1.2-2」版本。此外,如同剛才所說明的我們可以使用新版 LIS 4.1 整合服務中的「lsvmbus」指令,來查看相關虛擬裝置的 Vmbus ID 資訊。

圖 12、確認 CentOS 客體作業系統,是否採用最新的 hv_vmbs 4.1.2-2 版本
目前有個已知問題值得注意,倘若安裝 CentOS 客體作業系統的 VM 虛擬主機有啟用「安全開機」功能的話,那麼在安裝新版 LIS 4.1 整合服務後必須將安全開機功能「停用」,否則將會發現 CentOS 客體作業系統無法正常啟動或啟動後直接進入安全模式。



FreeBSD 虛擬主機安裝整合服務

雖然,FreeBSD 也是 Unix-Like 作業系統,但是 FreeBSD 的系統核心與 Linux 完全不同。同樣的,微軟官方也採用與 LIS 整合服務同樣的方式,讓運作於 Hyper-V 虛擬化平台中的 FreeBSD 虛擬主機,能夠支援及使用 Hyper-V Specific Devices 高效能虛擬裝置機制,此機制稱之為「BIS(BSD Integration Services)」

圖 13、微軟開發人員協同 FreeBSD 團隊開發 BIS 整合服務,讓系統核心支援 Hyper-V 虛擬化平台

倘若運作舊版 FreeBSD 8.4、9.1 ~ 9.3 的話,必須透過 FreeBSD Ports 套件管理機制,安裝「/head/emulators/hyperv-is」套件即可。在 2012 年 5 月 10 日時,Microsoft TechNet Blog發表一篇 FreeBSD Support on Windows Server Hyper-V 文章,內容便說明 Microsoft 以及合作夥伴 NetApp、Citrix 將在 BSDCan 2012 大會上,正式發表 FreeBSD 核心支援 Hyper-V 虛擬裝置驅動程式。

因此,倘若採用的是 FreeBSD 10.x 或最新版本的 FreeBSD 11,因為在 FreeBSD 核心中已經支援 BIS 整合服務,所以便無須再透過 FreeBSD Ports 套件管理機制進行安裝作業。
請注意,目前 Hyper-V 虛擬化平台中的 FreeBSD,仍無法採用「第二世代」格式的 VM 虛擬主機,同時 BIS 整合服務功能性的部分與 LIS 整合服務相較之下較少,舉例來說,動態記憶體功能尚未完全支援運作。

同樣的,在建立第一世代格式的 VM 虛擬主機並安裝最新版本 FreeBSD 11 之後,我們可以切換到 Hyper-V 管理員視窗中,確認 FreeBSD 虛擬主機的 BIS 整合服務是否順利運作。首先,切換到「摘要」頁籤中,可以看到活動訊號欄位的顯示結果為「良好(無應用程式資料)」,表示Hyper-V虛擬化平台可以正確偵測到VM虛擬主機運作狀態。

切換到「記憶體」頁籤中,您可以看到記憶體需求及記憶體狀態欄位為「空白」,這是因為BIS 整合服務機制尚未支援 Hyper-V 虛擬化平台的動態記憶體功能所致。切換到「網路功能」頁籤中,你會看到在狀態欄位的部分顯示結果為「良好(VMQ 作用中)」,表示 FreeBSD 客體作業系統已經透過 BIS 整合服務,為 VM 虛擬主機所指派使用的虛擬網路介面卡,安裝好虛擬網路卡驅動程式並進行裝置最佳化的動作。

圖 14、新版 FreeBSD 11 已經內建 BIS 整合服務

順利登入 FreeBSD 11 系統後,可以發現系統已經順利辨識到網路介面卡(代號為 hn0),查看系統開機訊息可知 hn0 網路卡為「Hyper-V Network Interface」,也就是已經採用最佳化效能的 Hyper-V Specific Network Adapter,接著鍵入指令「ls /boot/kernel | grep hv」查看 FreeBSD 模組存放資料夾內容可知,協同 Hyper-V 虛擬化平台運作的相關模組檔案也已經存在。
倘若,VM 虛擬主機組態配置傳統網路介面卡時,將網路介面卡代號將為「de0」並模擬「Digital 21140A Fast Ethernet 100 Mbps」網路卡。
圖 15、順利辨識並載入 Hyper-V Specific Network 網路介面卡及相關模組

鍵入指令「dmesg | grep vmbus0」查詢 FreeBSD 開機訊息內容,你會看到 FreeBSD 透過內建的 BIS 整合服務,已經順利載入 Hyper-V 虛擬化平台協同運作的相關服務,例如,Heartbeat、KVP、Shutdown、Time Synch……等服務。

圖 16、FreeBSD 透過內建的 BIS 整合服務載入 Hyper-V 相關客體服務





結語

透過本文的說明及實作演練,當企業及組織的 IT 管理人員需要在 Hyper-V 虛擬化平台上運作 Unix-Like 作業系統時,便能夠正確為 Unix-Like 作業系統採用 LIS / BIS 整合服務,以便確保運作於 Hyper-V 虛擬化平台上的 Unix-Like 作業系統,能夠擁有最佳的工作負載及最大化的運作效能。