[博客來 - 購買特價 7 折]💪

即日起至 2017年10月31日止博客來針對這 2 本書推出特價 7折活動 (1 本才 434 元),有興趣的朋友可以參考看看。😁



書籍簡介

在本書中,我們將會指導你如何規劃及調校 VMware vSphere 6.x 的基礎架構。我們將會為你提供相關的專業知識及操作技巧,以便引導你順利建構高可用性、高效能的 VMware vSphere 虛擬化基礎架構。同時,我們將會一步一步帶領你進行操作並輔以畫面截圖。

經由專業認證的 VMware 專業人士,基於各種真實狀況,親自分享實務性的操作步驟以及詳細的概念解釋。使你可以透過本書瞭解 VMware vSphere 6.x 的完整功能,並能夠藉此應付作業環境中的各項挑戰。

本書內容涵蓋從安裝、設定、操作及安全性控制等方面的詳細步驟,協助你克服大型虛擬化環境的管理及自動化難題。藉由對 VMware vSphere 的全方位教學,本書可引令初學者成為虛擬化技術的專家,或是作為資深管理者的重要參考書目。



誰適合閱讀此書

本書是專為希望加強 vSphere 6.0 虛擬化基礎架構,以及進階虛擬化技術的 IT 專業人士所寫。對於剛開始學習虛擬化技術的 IT 管理人員,可以依循本書中每個章節一步一步進行實作,進而學習到完整的虛擬化技術及虛擬化環境管理技巧。不過,讀者仍應先具備以下基礎:
  • 對於網路基礎架構有基本認識。
  • Microsoft Windows 運作環境的操作經驗。
  • DNS 及 DHCP 網路服務的管理經驗。
  • 對於虛擬化環境與傳統實體架構之差異有基本認識。
  • 對標準 x86 及 x64 伺服器硬體架構及軟體元件有基本認識。



網路購書




    本書導讀

    在本書中,我們將會詳盡說明 VMware vSphere 6.0 虛擬化環境的安裝、設定、管理及監控。在本書中除了深入剖析 vSphere 虛擬化產品,以及相關進階技術的特色功能外,更輔以實作,讓你可以詳細了解產品的安裝及組態設定。

    這些組態設定包括 vSphere 虛擬網路及儲存功能,以及 HA 高可用性、容錯移轉和資源使用率⋯⋯等。當完成基礎架構的安裝及組態設定後,我們將會進入 VM 虛擬主機的建立及管理,然後深入到效能監控及故障排除。通讀本書能夠使你了解如何建置一個全新的vSphere 虛擬化環境,或者如果你是一名 IT 專業人員,對虛擬化技術已有所了解,則本書可視為是一部參考書,使你可以藉由書中的提示、訣竅與最佳實踐,來增強自己的技能。

    本書將以提供虛擬化專業技術為導向,幫助你建置、整合、管理、維運企業等級的虛擬化解決方案。

    VMware vSphere 6 企業級專家手冊 (上)

    • 《第 1 章:簡介 VMware vSphere 6》,開始討論有關 vSphere 6.0 虛擬化產品。在本章中,將介紹 vSphere 軟體授權資訊,以及企業及組織採用 vSphere 虛擬化解決方案時的實際使用案例。
    • 《第 2 章:規劃設計及安裝 VMware ESXi》,本章將著重在選擇實體伺服器、VMware ESXi 版本、規劃設計及安裝、以及手動和自動化部署 VMware ESXi 運作環境。
    • 《第 3 章:安裝及組態設定 vCenter Server》,在本章中我們將深入討論如何規劃vCenter Server,以及 vCenter Server 相關運作元件,同時也將討論如何規劃設計、安裝、組態設定 vCenter Server 運作環境。
    • 《第 4 章:vSphere Update Manager 及 vCenter Support Tools》,在本章中將說明規劃設計、安裝及組態配置 vSphere Update Manager。透過 vCenter Update Manager 更新機制,將能確保 vSphere 運作環境擁有最新的安全性更新。
    • 《第 5 章:建立及組態設定 vNetwork 虛擬網路》,在本章中我們將討論虛擬網路的規劃設計、管理及最佳化,同時也將討論相關更新功能如 VDS 分散式交換器,以及協力廠商的虛擬網路交換器。在本章中,我們將討論虛擬網路及實體網路的運作架構整合,以及網路運作環境的安全性,同時提供相關解決方案。
    • 《第 6 章:建立及組態設定 vStorage 儲存資源》,在本章中我們將深入討論 vSphere 儲存架構,包括光纖通道、iSCSI 及 NAS 儲存設備的規劃設計及最佳化,以及相關進階功能的使用如精簡佈建、MPIO 多重路徑和負載平衡。
    • 《第 7 章:確認 HA 高可用性及商務連續性》,在本章中我們將深入剖析商務連續性及災難復原等熱門議題,我將提供有關 VM 虛擬主機建立 HA 高可用性,以及伺服器叢集的詳細資訊。此外,本章也將討論如何建構 vSphere HA(High Availability)及 vSphere FT(Fault Tolerance)等機制,以便為 vSphere 運作環境中的 VM 虛擬主機,提供高可用性及容錯移轉的運作機制,同時也將討論如何透過 vSphere Storage API 進行備份作業。


    VMware vSphere 6 企業級專家手冊 (下)

    • 《第 8 章:VMware vSphere 安全性》,安全性一直是基礎架構的重要組成部分,在本章中我們將討論不同層面的安全性管理機制,例如,管控 ESXi 主機的存取以及透過 Active Directory 整合身分驗證機制。同時,在本章中也將介紹在多層次的運作環境中,如何進行系統管理以及使用者身分驗證機制,同時針對 Windows 使用者及群組和 vSphere 安全性模組進行整合,達到企業等級的部署及權限管理和委派作業。
    • 《第 9 章:建立及管理 VM 虛擬主機》,在本章中將介紹如何透過 vCenter Server 部署 VM 虛擬主機。此外也將介紹多項可節省時間的技巧、VM 虛擬主機最佳化、以及最佳實踐作法,讓 VM 虛擬主機即便隨著時間而不斷增加數量,也能夠簡化管理程序。
    • 《第 10 章:建立範本及 vApp》,在本章中將為你介紹範本的運作概念,以及透過VM 虛擬主機映像檔機制,達到標準化及快速部署 VM 虛擬主機的目的。同時,我們也將討論複製及 vApp 的運作概念,以便在眾多 VM 虛擬主機的運作環境中,建立及使用 vSphere 的多用途容器。此外,我們也將討論 VMware 所採用的 OVF 標準,以便輕鬆匯入並使用協力廠商所提供的 VM 虛擬主機。
    • 《第 11 章:管理資源集區》,在本章中我們將全面審視資源的分配及管理,從單台VM 虛擬主機到 ESXi 主機和叢集,深入探討在 vSphere 運作環境中如何使用資源,以及管理人員如何透過「共享」(Share)、「保留」(Reservations)、「限制」(Limits)等機制,管理及調整資源的使用及分配方式。
    • 《第 12 章:負載平衡資源使用率》,在上一章節中我們已經了解到資源的使用及分配,接著在本章中我們將會探討 vSphere 負載平衡資源使用率的方式。在本章中,你將會了解到 vSphere vMotion、EVC(Enhanced vMotion Compatibility)、vSphere DRS(Distributed Resource Scheduler)、Storage vMotion 以及 Storage DRS。
    • 《第 13 章:監控 VMware vSphere 運作效能》,在本章中我們將透過 vSphere 內建工具,讓管理人員能夠審視及解決基礎架構的效能問題,本章將著重於監控 ESXi 主機及叢集中的 vCenter Server,在 CPU、記憶體、磁碟及網路等硬體資源的使用率,同時你也將學習到有關 vCenter Operations Manager 的部分。
    • 《第 14 章:VMware vSphere 自動化》,在 VMware vSphere 運作環境中,管理人員常常面臨的是重複性的管理作業,我們在本章中所介紹的自動化機制將能有效幫助管理人員,輕鬆建構各種自動化機制的方式,包括 vCenter Orchestrator 及 PowerCLI。
    • 《附錄》,在每一章節的結語當中,我們將針對每項問題提供給管理人員最佳建議作法及解決方案。

    [博客來 - 購買特價 7 折]💪

    即日起至 2017年10月31日止博客來針對本書推出特價 7 折活動 (1 本才 392 元),有興趣的朋友可以參考看看。😁



    書籍簡介

    還在為了規劃儲存設備規模大小而苦惱嗎?
    實作微軟 S2D 軟體定義儲存技術,一次整合運算及儲存資源

    Microsoft S2D 軟體定義儲存技術,最小運作規模只要 2 台 S2D 叢集節點主機,即可建構出不輸中階儲存設備的 IOPS 儲存效能,並且 S2D 單一叢集最大規模 16 台及高達 600 萬 IOPS 儲存效能。同時,整合 S2D HCI 超融合部署架構,能夠一次解決 VM 虛擬主機和 Container 容器及其他工作負載,在運算及儲存資源方面整合的煩惱。


    軟體定義資料中心(Software Defined Data Center,SDDC)

    根據 Gartner 的研究結果顯示,過往 IT 人員所熟知及打造 Mode 1 現代化資料中心(Data Center Modernization)所遭遇的挑戰,主要在於管理及打造企業或組織中有關運算資源、儲存資源、網路資源、硬體設備、虛擬化技術⋯⋯等虛實整合。

    隨著企業及組織朝向商業數位化模式不斷發展,知名的市調機構 Gartner 所屬分析師在 2015 下半年期間,針對 100 位企業及組織中負責領導IT基礎架構的主管調查結果顯示,有 2/3 以上的企業及組織開始建構及整合 Mode 2敏捷式 IT 基礎架構(Infrastructure Agility)

    所謂「基礎架構敏捷化」(Infrastructure Agility),便是著重於IT基礎架構中「Mode 2」的部分也就是因應商業數位化的需求,這些範圍包括:

    • 將敏捷(Agility)最佳實務概念,充分導入至現代化資料中心的IT基礎架構當中,讓工 作流程及技術人員能夠快速因應現在新興的商業數位化需求。
    • 深入了解各項使用案例、決策考量、微服務(Micro-Service)、容器引擎⋯⋯等最佳實務 概念。
    • 將單純的虛擬化運作環境,發展成軟體定義(Software-Defined)的基礎架構以達成敏捷 的目的,也就是打造「軟體定義資料中心」(Software-Defined Data Center,SDDC)。
    • 充份利用彈性的雲端基礎架構部署新世代應用程式(Next-Generation Applications)。 
    • 建構邊緣資料中心(Edge Data Center)平台,以便因應商業數位化及 IoT 物聯網。 
    • 加強巨量資料分析、Web 應用程式、IoT 物聯網⋯⋯等部署作業,以便因應現代化行動至 上的商務模式。

    簡單來說,不管是 Mode 1 的現代化資料中心或是新興 Mode 2 的基礎架構敏捷化,在企業或組織的資料中心內硬體資源的組成,不外乎就是「CPU、記憶體、儲存、網路」等 4 大硬體資源,而這 4 大硬體資源又可以簡單劃分為3大類也就是運算、儲存、網路。

    那麼,接下來我們來看看 Mode 2 基礎架構敏捷化定義中,透過軟體定義(Software-Defined)的運作概念,如何將「運算、儲存、網路」等硬體資源,轉換成 SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路,幫助企業及組織打造成快速因應商業數位化需求的強大IT 基礎架構,最終達成 SDDC 軟體定義資料中心的目標。

    軟體定義運算(Software Defined Compute,SDC)

    軟體定義運算(Software Defined Compute,SDC),與 SDS 軟體定義儲存及 SDN 軟體定義網路技術相較之下,為基礎架構硬體資源當中最為成熟的技術。事實上,許多企業及組織在建構軟體定義式的IT基礎架構時,最先投入的便是 SDC 軟體定義運算的部分。

    然而,談到 SDC 軟體定義運算便無法不談到 x86 伺服器虛擬化(x86 Server Virtualization) 技術,在 x86 伺服器虛擬化技術尚未風行前,企業及組織的應用程式及營運服務便直接運作在 x86 硬體伺服器上,這樣的運作架構雖然讓應用程式及營運服務,可以直接獨佔整台 x86 硬體伺服器所有硬體資源,所以能夠提供良好的工作負載能力。但是,卻容易產生「供應商鎖定」(Vendor Lock-in)的情況,舉例來說,倘若原本的應用程式及營運服務運作於 Dell 硬體伺服器上,但是該台 x86 硬體伺服器發生故障損壞事件時,需要將其上的應用系統或營運服務遷移至它牌硬體伺服器時(例如:HPE 或 Lenovo)是非常困難的。

    事實上,談到虛擬化技術一般 IT 管理人員通常都會聯想到 VM 虛擬主機,然而這個情況從 2013 年 Docker 的出現而發生重大的改變。其實,Docker 並非是「容器」(Container)技術,而是一項用來管理及調度容器環境的技術,讓 IT 管理人員能夠不用費心處理容器的管理作業,便能達到輕量級作業系統虛擬化解決方案的目的。

    微軟官方也在 Windows Server 2016 雲端作業系統中,與 Docker 合作推出 Windows Server Container 及 Hyper-V Container 技術,讓 Hyper-V 虛擬化平台成為同時運作 VM 虛擬主機及 Container 容器的最佳運作環境,輕鬆幫助管理人員達成 Bimodal IT 的雙重 IT 基礎架構,幫助企業及組織在傳統及新興架構之間找到最佳平衡點。

    軟體定義儲存(Software Defined Storage,SDS)

    軟體定義儲存(Software Defined Storage,SDS),為企業及組織帶來儲存資源的潛在好處,便是能夠提升靈活性並降低整體維運成本。因此,企業及組織的 CXO 們應尋找及確認能夠更好提供「總體擁有成本」(Total Cost of Ownership,TCO)的 SDS 軟體定義儲存解決方案,同時選擇的 SDS 解決方案必須具備效率及可擴充性等特性,以便因應不斷增加的資料量並且能夠擺脫儲存設備的硬體限制。

    目前,在 SDS 軟體定義儲存解決方案市場中尚未有明確的市場領導者出現。雖然,SDS 軟體定義儲存解決方案具備可程式性及自動化等好處,但是仍須考量對於「運算」「網路」所造成的影響。同時,所建立的 SDS 儲存資源必須要能夠融入 IT 基礎架構中而非再以孤島的方式運作。

    在微軟新世代 Windows Server 2016 雲端作業系統當中,SDS 軟體定義儲存技術是由 Windows Server 2012 R2 當中的 Storage Spaces 技術演化而來,在 Windows Server vNext 開發時期稱為 Storage Spaces Shared Nothing,在 Windows Server 2016 的正式名稱則為 S2D(Storage Spaces Direct)

    軟體定義網路(Software Defined Network,SDN)

    根據 CIO 的調查結果顯示,有 86% 的企業及組織 CIO 正計畫將內部資料中心及基礎架構進入 Bimodal IT 環境(相較於往年增加 20%),透過將過去 3 層式網路架構遷移至 Spine- Leaf 網路架構讓整體網路環境簡單化,並結合軟體定義網路(Software Defined Network,SDN)技術, 以 SDN Network Control Plane 來管理 Mode 2 的資料中心, 以便因應東-西(East-West)向的網路流量,並採用模組化架構以便輕鬆進行自動化部署,同時結合 Ansible、Puppet、Chef 等自動化組態設定工具,讓企業及組織的網路架構更適合 DevOps 環境,並往基礎架構即程式碼(Infrastructure as Code)的方向進前。

    微軟新世代 Windows Server 2016 雲端作業系統當中,「軟體定義網路」(Software Defined Network,SDN)技術內的重要角色「網路控制器」(Network Controller),以及透過 SDN 技術管理「網路功能虛擬化」(Network Functions Virtualization,NFV)運作環境, 進而幫助企業或組織在資料中心內建構網路虛擬化環境。



    網路購書





    本書導讀

    本書共有 7 個章節,由一開始簡介 SDDC 軟體定義資料中心願景開始,一路從 S2D 簡介及運作環境需求、S2D 底層運作架構、規劃設計最佳化 S2D 運作架構、實戰 S2D 環境建置、IOPS 效能測試、S2D 維運管理免煩惱。




    第 1 章、SDDC 軟體定義資料中心

    了解 SDDC 願景中重要的組成元件,包括 SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路。

    1.1 SDDC 軟體定義資料中心
    1.2 軟體定義運算(SDC)
              1.2.1 x86 虛擬化技術
              1.2.2 全虛擬化技術
              1.2.3 半虛擬化技術
              1.2.4 CPU 硬體輔助虛擬化
              1.2.5 容器技術
              1.2.6 Microsoft SDC 軟體定義運算技術
              1.2.7 伺服器虛擬化技術市場趨勢
              1.2.8 基礎建設的重要性
    1.3 軟體定義儲存(SDS)
              1.3.1 Microsoft SDS 軟體定義儲存技術
    1.4 軟體定義網路(SDN)
              1.4.1 Microsoft SDN 軟體定義網路技術

    圖 1-1、Mode 1 現代化資料中心示意圖



    第 2 章、S2D 簡介及運作環境需求

    深入剖析 S2D 部署模式 HCI 超融合式與融合式運作架構的差別,以及建構 S2D 環境時應該採用 RAID 還是 HBA、採用 SSD 或 HDD、採用一般 TCP/IP 或 RDMA、採用 NTFS 或 ReFS 檔案系統等議題。

    2.1 S2D 運作架構及部署模式
              2.1.1 超融合式架構(Hyper-Converged)
              2.1.2 融合式架構(Converged)
    2.2 Windows Server 2016 版本
              2.2.1 Windows Server 2016 軟體授權
              2.2.2 Windows Server 2016 標準版
              2.2.3 Windows Server 2016 資料中心版
    2.3 如何配置硬體元件
              2.3.1 Microsoft HCL 硬體相容性
              2.3.2 採用 HBA 控制器或 RAID 卡?
              2.3.3 採用 DAS / JBOD / NAS / SAN 儲存設備?
              2.3.4 採用 SSD 固態硬碟或 HDD 機械式硬碟?
              2.3.5 採用 TCP/IP 乙太網路或 RDMA?
              2.3.6 採用 NTFS 或 ReFS 檔案系統?

    圖 2-20、啟用 RDMA 特色功能,可提升 2 倍的 IOPS 儲存效能



    第 3 章、S2D 運作架構

    深入剖析 S2D 底層運作架構元件,例如:SSB 軟體式儲存匯流排、SSB 頻寬管理機制、SBC 儲存匯流排快取機制、Storage Pool、ReFS Real-Time Tiering、SMB Direct、RoCE、iWARP、Infiniband、SMB MultiChannel 等技術內容。

    3.1 S2D 儲存堆疊運作架構
              3.1.1 SSB(Software Storage Bus)
              3.1.2 SBC(Storage Bus Cache)
              3.1.3 Storage Pool
              3.1.4 ReFS Real-Time Tiering
    3.2 SMB 3
              3.2.1 SMB Direct(RDMA)
              3.2.2 RoCE
              3.2.3 iWARP
              3.2.4 Infiniband
    3.3 SMB 多重通道
    3.4 容錯及儲存效率
              3.4.1 鏡像(Mirror)
              3.4.2 同位(Parity)
              3.4.3 混合式復原(Mixed Resiliency)

    圖 3-10、Hybrid 儲存架構資料快取示意圖



    第 4 章、S2D 規劃設計

    一步一步帶領你挑選 CPU 處理器、記憶體、NVMe 快閃儲存、SSD 固態硬碟、HBA 硬碟控制器、RDMA 網路卡、10GbE 網路交換器、了解 SSD 與 HDD 比例原則、S2D 叢集 大/中/小 型運作規模等最佳配置建議。

    4.1 S2D 運作規模大小及限制
    4.2 如何挑選實體伺服器硬體元件
              4.2.1 如何挑選 CPU 處理器
              4.2.2 如何挑選 RAM 規格
              4.2.3 如何挑選 SSD 固態硬碟
              4.2.4 SSD 與 HDD 如何搭配及比例原則
              4.2.5 如何挑選 HBA 硬碟控制器
              4.2.6 如何挑選 RDMA 網路卡
              4.2.7 如何挑選網路交換器
    4.3 實體伺服器環境及數量建議
              4.3.1 小型運作規模
              4.3.2 中型運作規模
              4.3.3 大型運作規模

    圖 4-19、Hybrid 儲存架構配置示意圖



    第 5 章、S2D 安裝及設定

    手把手帶領你建構 S2D 運作環境,包括安裝 Windows Server 2016、設定 10GbE 網路交換器、啟用 DCB/PFC 特色功能、啟用 SMB Direct(RDMA)、啟用 SMB QoS 原則、建立 SET ( Switch Embedded Teaming )、檢查 RDMA 運作狀態、檢查 SMB MultiChannel 運作狀態、建立 S2D 叢集、啟用 Storage Spaces Direct 機制、建立三向鏡像磁碟區、建立雙同位磁碟區、建立雙向鏡像磁碟區、建立單同位磁碟區、建立混合式復原磁碟區、部署 VM 虛擬主機、Storage Pool 最佳化等最佳化組態配置。

    5.1 安裝 Windows Server 2016 作業系統
              5.1.1 系統基礎設定
              5.1.2 安裝相關角色及功能
    5.2 設定 10GbE 網路交換器
              5.2.1 啟用 DCB / PFC 功能
    5.3 啟用 SMB Direct(RDMA)功能
              5.3.1 啟用 SMB 網路 QoS 原則
              5.3.2 建立 SET 網路卡小組
              5.3.3 檢查 RDMA 運作狀態
    5.4 建構 S2D 軟體定義儲存環境
              5.4.1 加入網域
              5.4.2 確保已安裝最新安全性更新
              5.4.3 檢查 SMB Direct 及 SMB MultiChannel 運作狀態
              5.4.4 執行容錯移轉叢集檢查工具
              5.4.5 建立容錯移轉叢集
              5.4.6 設定容錯移轉叢集仲裁機制
              5.4.7 啟用 Storage Spaces Direct 機制
              5.4.8 建立三向鏡像磁碟區
              5.4.9 建立雙同位磁碟區
              5.4.10 建立雙向鏡像磁碟區
              5.4.11 建立單同位磁碟區
              5.4.12 建立混合式磁碟區
    5.5 部署 VM 虛擬主機
    5.6 Storage Pool 最佳化

    圖 5-119、在 S2D 叢集中建立 5 種不同「容錯機制 / 儲存效率 / 容錯網域」需求的磁碟區



    第 6 章、S2D 效能測試

    從了解 IOPS 儲存效能的估算開始,慢慢深入如何進行 IOPS 儲存效能測試,並透過開源工具 VMFleet 進行 S2D 環境 IOPS 儲存效能測試。

    6.1 什麼是 IOPS?
    6.2 儲存效能測試基礎概念
    6.3 VMFleet 效能測試工具
    6.4 IOPS 效能測試

    圖 6-41、採用「三向鏡像」在壓測情境 2 時 S2D 叢集的儲存效能表現



    第 7 章、S2D 維運管理

    深入了解 S2D 如何因應各式各樣硬體故障事件、如何查詢 S2D 運作健康狀態、S2D 叢集節點主機如何進入維護模式、如何整合 CAU 叢集感知更新機制安裝微軟最新安全性更新、實戰水平擴充 S2D 叢集運作規模(2台 → 3台 → 4台)、實戰擴充 CSVFS 磁碟區空間等維運管理議題。

    7.1 S2D 如何因應硬體故障事件
              7.1.1 發生 1 個錯誤網域時
              7.1.2 發生 2 個錯誤網域時
              7.1.3 發生 3 個錯誤網域時
    7.2 S2D 健康狀態
    7.3 S2D 維護模式
              7.3.1 S2D 叢集節點主機進入維護模式
              7.3.2 S2D 叢集節點主機離開維護模式
              7.3.3 CAU 叢集感知更新
    7.4 水平擴充 S2D 叢集運作規模
              7.4.1 擴充 S2D 叢集規模(2 台 → 3 台)
              7.4.2 擴充 S2D 叢集規模(3 台 → 4 台)
    7.5 擴充 CSVFS 磁碟區空間

    圖 7-6、發生 2 個錯誤網域時,S2D 叢集仍然能夠正常運作資料仍可持續存取



    附錄、S2D 解決方案

    最後,我們進一步介紹市場上各家硬體伺服器供應商的 S2D 解決方案。(供應商名稱以英文字母順序排序)。

    A.1 簡介 S2D 解決方案
    A.2 Dell EMC – S2D 解決方案
    A.3 Fujitsu – S2D 解決方案
    A.4 HPE – S2D 解決方案
    A.5 Intel – S2D 解決方案
    A.6 Lenovo – S2D 解決方案
    A.7 QCT – S2D 解決方案
    A.8 Supermicro – S2D 解決方案

    圖 A-1、支援 S2D 軟體定義儲存技術硬體伺服器清單

    網管人雜誌

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



    文章目錄

    前言
    vSAN 技術發展歷史
    vSAN 6.6 新功能
              安全性
              管理
              部署
              可用性
              效能
              vSAN 軟體授權
    結語





    前言

    去年 11 月時,VMware 官方在 VMworld 2016 大會上正式發佈最新版本 VMware vSphere 6.5,並且正式宣佈 VMware Virtual SAN 6.5 一同推出。事實上,在 VMware 所擘劃的 SDDC 軟體定義資料中心未來藍圖當中,負責 SDS 軟體定義儲存解決方案的角色便是 VMware vSAN(Virtual SAN)。

    雖然,距離最新第 5 代的 VMware vSAN 6.5 版本才短短間隔 5 個月的時間,VMware 官方便於 2017 年 4 月正式發佈第 6 代 VMware vSAN 6.6 並且這次發佈的第 6 代 VMware vSAN 6.6 卻總共新增 23 項特色功能。

    簡單來說,透過 VMware vSAN 軟體定義儲存技術,企業及組織可以將多台安裝 ESXi 虛擬化平台的 x86 實體伺服器,透過 VMware vSAN 把所有硬體伺服器上的「本機硬碟」(Local Hard Disk)匯整串連起來(例如,NVMe 快閃儲存、SSD 固態硬碟、HDD 機械式硬碟……等),建構出巨大的儲存資源集區。

    同時,這個巨大的儲存資源集區還能夠運作 VM 虛擬主機及容器等工作負載,因此企業及組織在建構 VMware vSAN 軟體定義儲存環境之後,便能一次解決建置「運算 / 儲存」資源的難題,這也是目前非常熱門稱為「超融合式架構」(Hyper-Converged Infrastructure,HCI)的應用方式。

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





    vSAN 技術發展歷史

    事實上,當市場上都還著重在利用硬體架構打造出 HCI 超融合式架構時,VMware 官方便已經著手發展以軟體定義的方式打造儲存資源,所以第 1 代的 VMware vSAN 版本,便在 2014 年 3 月時隨著 vSphere 5.5 Update 1 版本開始內建,讓企業及組織能夠透過「標準的 x86 硬體伺服器」結合 vSAN 技術,自行打造出 SDS 軟體定義儲存解決方案,而無須購買特定廠商推出的專用硬體式 SDS 軟體定義儲存設備,避免日後發生「供應商鎖定」(Vendor Lock-in)的情況。
    有關第 1 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 110 期《實戰部署 Virtual SAN 套用政策自動化搭配 VM》
    圖 2、第 1 代 VMware vSAN 軟體定義儲存技術

    經過 1 年後於隔年 2015 年 3 月,VMware 官方推出第 2 代 VMware vSAN 版本,並且隨著當時最新虛擬化平台版本 vSphere 6.0 一同發佈,同時讓 vSAN 版本直接與 vSphere 版本對齊成為 vSAN 6.0 版本(因為,原訂 vSAN 新版本號為 vSAN 2.0),避免因為版本不一致導致 IT 管理人員在規劃設計上的困擾。在第 2 代 vSAN 版本當中最重要的特色功能便是支援 All Flash 運作架構,同時 vSAN 叢集規模與 vSphere 叢集一樣可達到 64 台節點主機。
    有關第 2 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 114 期《動手建立 VSAN 6 儲存資源,實戰水平擴充與容錯網域》
    圖 3、第 2 代 vSAN 軟體定義儲存技術開始支援 All-Flash 運作架構

    緊接著半年後於 2015 年 9 月時,VMware 官方推出第 3 代 VMware vSAN 6.1 版本,在這個版本中最具代表性的特色功能便是「延伸叢集」(Stretched Cluster)「支援 2 Nodes」的運作架構。因此,透過 vSAN 延伸叢集運作架構在 2 個站台之間同步資料,有效解決過去傳統 VMware vSphere 叢集單一站台故障損壞的問題,透過支援 2 Nodes 的 vSAN 運作架構,讓企業或組織可以因應 ROBO(Remote Office / Branch Office),例如,遠端辦公室或分支辦公室的小型儲存資源需求。
    有關第 3 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 120 期《VMware VSAN 延伸叢集,實作跨站點同步 HA 複寫》
    圖 4、第 3 代 vSAN 技術開始支援延伸叢集及 2 Nodes 運作架構

    再隔半年後於 2016 年 3 月,VMware 官方推出第 4 代 VMware vSAN 6.2 版本,在這個版本當中最重要的功能特色為 All Flash 運作架構,開始支援「重複資料刪除與壓縮」(Deduplication and Compression)「RAID 5/6 EC 編碼技術」(RAID 5/6 Erasure Coding),讓採用 All Flash 運作架構的企業及組織,能夠透過這 2 項重要的功能特色節省寶貴的快閃儲存空間。
    有關第 4 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 124 期《概覽 VMware VSAN 6.2 新功能加強健康狀態監控》
    圖 5、第 4 代 vSAN 技術開始支援重複資料刪除與壓縮技術

    經過 8 個月後於 2016 年 11 月,VMware 官方在 VMware VMworld 2016 大會正式發佈第 5 代的 vSAN 6.5 版本,在這個版本當中最重要的功能特色為開始支援「iSCSI 目標服務」(iSCSI Target Service),讓企業及組織中必須依靠 iSCSI 啟動器連接儲存資源的傳統服務,也能夠輕鬆使用 vSAN 儲存資源。
    有關第 5 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 134 期《VMware 第五代 SDS 技術 vSAN 6.5 新功能快覽》
    圖 6、第 5 代 vSAN 技術開始支援 iSCSI 目標服務





    vSAN 6.6 新功能

    由於最新第 6 代 VMware vSAN 總共新增 23 項特色功能,因此本文將針對所有特色功能進行概要說明,在後續的專欄中再深入剖析各項特色功能並進行實戰演練。首先,我們可以將這些新增特色功能大致分類,分別為「安全性、管理、部署、可用性、效能」等 5 大類進行說明。



    安全性

    在第 6 代 vSAN 版本當中,關於「安全性」(Security)方面有 2 項新增特色功能,分別是「原生加密」(Native Encryption)「法務遵循」(Compliance)。主要原因在於,VMware 所擘劃的 SDDC 軟體定義資料中心願景當中,VMware vSAN 擔任 SDS 軟體定義儲存的重要角色,可以想見當企業及組織將大量的 VM 虛擬主機運作於 vSAN 環境中,同時 VM 虛擬主機內更存放著大量企業及組織的機敏資訊。

    因此,確保 vSAN 儲存資源的安全性機制將相形重要,在新版 vSAN 6.6 運作環境中 VMware 達成 HCI 超融合基礎架構原生加密解決方案。簡單來說,這個加密解決方案是內建在 vSAN 軟體定義儲存技術內,只要在管理介面中進行相關組態設定後,便可以針對 vSAN Datastore 儲存資源進行「啟用 / 停用」加密機制。

    同時,因為 vSAN 6.6 Native Encryption 加密機制,是座落在「Hypervisor 層級」而非 VM 虛擬主機層級的加密機制,所以 vSAN 6.6 Native Encryption 加密機制與「硬體無關」,因此無須依靠專用且昂貴的「加密磁碟」(Self-Encrypting Drives,SED),就可以輕鬆達成企業機敏資料加密的目的。

    圖 7、新版 vSAN 6.6 達成 HCI 超融合基礎架構原生加密解決方案

    使用 vSAN 6.6 原生加密機制注意事項:
    • vSAN 原生加密機制必須以「vSAN 叢集」為單位,進行 vSAN 原生加密運作機制的啟用及組態設定作業。
    • 當 IT 管理人員對 vSAN 叢集啟用原生加密機制後,系統將會採用「XTS AES 256」加密演算法對 vSAN Datastore 儲存資源中,「快取」(Cache)及「容量」(Capacity)層級的儲存資源進行加密保護。

    圖 8、啟用 vSAN 原生加密運作機制


    • 由於 vSAN 原生加密運作機制,是座落在整體 vSphere 儲存堆疊架構中「裝置驅動層級」(Device Driver Layer)之上,所以不管是 vSAN 延伸叢集、vSAN 重複資料刪除、vSAN 壓縮、Erasure Coding……等特色功能,皆能協同運作不受任何影響。
    • vSAN 原生加密運作機制,與 vSphere 進階特色功能,例如,vSphere vMotion、vSphere DRS(Distributed Resource Scheduler)、vSphere HA(High Availability)、vSphere Replication……等特色功能,皆能協同運作不受任何影響。
    • vSAN 原生加密運作機制,符合「2-Factor Authentication(SecurID and CAC)」驗證機制,同時 vSAN 也是第 1 個通過 DISA / STIG 認可的 HCI 超融合解決方案。
    • 啟用 vSAN 原生加密運作機制的操作步驟,與啟用 vSphere 6.5 當中 VM 虛擬主機加密機制一樣,在運作環境中都必須要有「KMS(Key Management Server)」才行。同時,只要是符合 KMIP 1.1 標準的 KMS 供應商產品即可,例如,HyTrust、Gemalto、Thales e-Security、CloudLink、Vormetric……等。

    圖 9、透過 vCenter Server 管理平台組態設定 KMS 加密伺服器


    • 雖然啟用 vSAN 原生加密運作機制的操作步驟非常簡單,但是當 IT 管理人員啟用 vSAN 原生加密機制之後,快取及容量層級儲存裝置的「磁碟格式」(Disk Format)將需要「重新格式化」,並且在啟用成功後可以透過 ESXi Shell 的「esxcli vsan storage list」指令進行確認,只要看到磁碟格式欄位顯示「Encryption: true」的訊息表示加密作業成功。值得注意的是,不管是「啟用或停用」vSAN 原生加密機制,因為必須將磁碟格式重新格式化,所以 vSAN 儲存資源若儲存資料量非常龐大時,將會花費大量的時間進行資料遷移作業。
    • 由於 vSAN 原生加密運作機制,將會使用 KMIP(Key Management Interoperability Protocol)通訊協定,在 vSAN 叢集節點主機與 KMS 加密伺服器之間進行溝通。因此,VMware vCenter Server 管理平台及 PSC 和其它 VM 虛擬主機,能夠直接在啟用原生加密機制的 vSAN Datastore 儲存資源中持續運作而不會中斷。
    • vSAN 原生加密運作機制,適用於 All-Flash 全快閃儲存及 Hybrid 混合儲存運作架構,並且與 KMIP 1.1 金鑰管理機制整合及協同運作。
    • vSAN 原生加密運作機制,目前僅支援新版第 6 代 vSAN 6.6 的 vSAN Datastore 儲存資源,尚未支援其它舊版 vSAN Datastore(例如,vSAN 6.5…… 等)。
    • 在 IT 業界普遍的資訊安全準則中,通常都需要定期重新產生新的加密金鑰,以降低加密金鑰被進行暴力破解的危害風險。因此,當需要重新產生新的加密金鑰時,IT 管理人員只要登入 vSAN 管理介面,便可以透過簡單的組態設定重新產生新的加密金鑰。

    圖 10、因應法規遵循要求定期重新產生新的加密金鑰



    管理

    在第 6 代 vSAN 版本當中,關於「管理」(Management)的部分共新增 9 項特色功能(如下所示),舉例來說,在過往的 vSAN 版本運作環境中,整個 vSAN 軟體定義儲存架構仍以 vCenter Server 管理平台為主,倘若 vCenter Server 發生故障損壞事件,或 vSphere Web Client 服務無法正常運作時,雖然不致影響運作在 vSAN 儲存資源上的 VM 虛擬主機,但是後續將無法進行任何管理動作,例如,觀看 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


    現在,新版 vSAN 叢集中的 vSAN 叢集節點主機將以分散式的方式運作,同時結合 vSAN 6.6 版本中「Highly Available Control Plane for Health Checks」管理功能,即便 vCenter Server 發生故障損壞事件或 vSphere Web Client 服務無法正常運作時,管理人員仍然可以透過 vSAN 叢集中的「任何 1 台」vSAN 叢集節點主機,使用每台 ESXi 主機都原生內建的 VMware Host Client 管理工具,隨時查看 vSAN 叢集的運作狀態。

    當然,IT 管理人員也可以使用「esxcli vsan」指令,檢查 vSAN 叢集的健康情況以及進行相關組態設定作業,例如,容錯網域(Fault Domains)、儲存原則(Storage Policy)、iSCSI 目標服務(iSCSI Target Service)……等。

    圖 11、透過原生內建的 VMware Host Client 管理工具隨時查看 vSAN 叢集的運作狀態



    部署

    在第 6 代 vSAN 版本當中,關於「部署」(Deployment)的部分共新增 3 項特色功能(如下所示)。過去,在建構舊版 vSAN 軟體定義儲存運作環境時,最令 IT 管理人員感到困擾的便是建構的 vSAN 叢集中,所有 vSAN 叢集節點主機之間必須透過「多點傳送」(Multicast)進行溝通,並未支援企業及組織內部常用的「單點傳送」(Unicast)網路環境。

    • Easy Install
    • Multicast Dependency Removed
    • Extensibility

    圖 12、第 6 代 vSAN 擺脫舊版只能使用 Multicast 的限制

    現在,建構第 6 代 vSAN 軟體定義儲存環境不再強迫採用多點傳送網路環境,可以直接使用企業及組織內部常用的「單點傳送」(Unicast)網路環境,讓 IT 管理人員可以更簡易的建構 vSAN 叢集,甚至是擴充 vSAN 叢集至延伸叢集運作架構都相對容易。

    值得注意的是,倘若企業及組織原有的舊版 vSAN 運作環境,在升級過程中仍必須保持多點傳送網路環境,直到 vSAN 叢集中所有 vSAN 叢集節點主機都順利升級為 vSAN 6.6 版本之後,此時 vSAN 叢集將會自動將網路傳送方式改為單點傳送

    圖 13、新版 vSAN 6.6 採用 Unicast 網路環境



    可用性

    在第 6 代 vSAN 版本當中,關於「可用性」(Availability)的部分共新增 3 項特色功能(如下所示)。雖然,從第 2 代 vSAN 版本開始,vSAN 叢集便已經能夠建立「延伸叢集」(Stretched Cluster)的運作架構,然而新版 vSAN 6.6叢集環境能夠結合本地端故障保護機制,讓 vSAN 叢集站台之間的容錯機制更具彈性,甚至能夠結合親和性規則讓儲存原則的管理更具備靈活性。

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


    現在,新版 vSAN 6.6 所建構的延伸叢集運作環境,可以整合本地端站台內的 RAID 1 或 RAID 5/6 機制,達到本地端站台故障保護同時也可以跨站台進行資料鏡像保護。因此,建構延伸叢集運作環境後,不管哪個站台因為發生外力不可抗拒的嚴重故障損壞事件時,都能確保另一邊的站台擁有完整的資料副本。

    圖 14、延伸叢集本地端故障保護機制運作架構示意圖

    管理人員只要登入 vSphere Web Client 管理介面,切換到儲存原則的組態設定頁面後,在 Storage Type 組態設定區塊中可以看到,預設情況下「Primary level of failures to tolerate」欄位設定值為「1」,表示在 vSAN 延伸叢集中的 2 個站台將會互相執行「鏡像」(Mirror)資料的動作,至於「Secondary level of failures to tolerate」欄位設定值為「1」,表示 vSAN 延伸叢集中 2 個站台所互相鏡像的資料要保留幾份,最後的「Failure tolerance method」欄位設定值為「RAID-5/6(Erasure Coding)」,表示 vSAN 叢集站台為採用 All Flash 的儲存架構配置。

    圖 15、組態設定 vSAN 延伸叢集本地端故障保護機制

    因此,透過 vSAN 原有延伸叢集的運作架構結合新版 vSAN 本地端故障保護機制,有效讓 vSAN 叢集提升叢集配置的彈性並最大化減少意外導致的停機時間,即便站台因為發生外力不可抗拒的嚴重故障損壞事件時,也能有效減少跨站台之間的傳輸流量。

    值得注意的是,在規劃 vSAN 延伸叢集運作架構時,在 2 個資料站台之間的網路環境必須確保在「5 ms RTT」之內,至於 2 個資料站台與 vSAN Witness 站台之間則只要確保在「200 ms RTT」即可,同時這樣的 vSAN 叢集運作架構具備高彈性及高可用性,但是卻無須額外購買其它專用的硬體或軟體即可達成。



    效能

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

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

    圖 16、新版 vSAN 支援 Intel 3D XPoint NVMe 快閃儲存及驚人的儲存效能表現



    vSAN 軟體授權

    倘若,企業及組織使用的是舊有 vSAN 版本的話,那麼可能會發現過需要使用進階版或企業版才能使用 All-Flash 全快閃儲存的運作架構,然而從第 5 代 vSAN 6.5 版本開始,所有 vSAN 軟體授權版本皆可以使用 All-Flash 全快閃儲存的運作架構,即使購買的是 ROBO(Remote Office / Branch Office),這種用於企業或組織遠端辦公室的軟體授權版本也支援,因此,即便是由 2 台 vSAN 節點主機所建構的小型 vSAN 運作環境,也能夠使用 All Flash 的硬體運作架構,為需要高 IOPS 儲存效能的分公司或小型 vSAN 環境提供解決方案。

    然而值得注意的是,雖然開放所有 vSAN 軟體授權版本都支援採用 All-Flash 全快閃儲存架構,但是在 All Flash 運作架構中進階特色功能,例如,「重複資料刪除及壓縮」(Deduplication & Compression)、「RAID5/6 Erasure Conding」特色功能,仍需要採用「進階版或企業版」vSAN 軟體授權才能夠使用。

    倘若,企業或組織希望達到更高可用性的 vSAN 運作架構,需要建置「延伸叢集」並結合「本地端故障保護機制」特色功能時,那麼只有採用「企業版」(Enterprise)的 vSAN 軟體授權才能使用這些進階特色功能。

    圖 17、VMware vSAN 6.6 軟體授權特色功能清單

    原則上,vSAN 軟體授權需要額外購買並以「per-CPU」的方式計價,同時企業或組織購買的 VMware vSphere 或 VMware vSphere with Operations Management 軟體授權,並未包含 vSAN 軟體授權。此外,若採購的是 vSAN for ROBO 軟體授權版本的話,則是以每「25 VM 虛擬主機」為採購單位。

    圖 18、vSAN for ROBO 運作架構示意圖

    倘若,企業或組織需要建購 VDI 虛擬桌面運作架構的話,可以購買 vSAN for Desktop Advanced 軟體授權,因為此版軟體授權將包含 VMware Horizon Advaned 及 vSAN Enterprise 版本,讓企業及組織可以在建構 VDI 虛擬桌面的同時,便於輕鬆導入 vSAN 軟體定義儲存技術。





    結語

    透過本文的說明及實作相信讀者已經了解,在第 6 代最新 vSAN 6.6 版本當中有哪些特色功能,能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 SDS 軟體定義儲存運作環境。並且,在後續的專欄文章中,我們將針對這些新增特色功能進行深入剖析及 Hands-On 實戰演練。

    網管人雜誌

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



    文章目錄

    前言
    Windows 容器類型
    Windows 容器運作環境需求
    實戰架設 Windows Server 容器環境
              下載及安裝 Docker 運作環境
              下載 Windows Server 基礎容器映像檔
              部署第 1 個 Windows Server 容器 - Hello World
              部署第 2 個 Windows Server 容器 - IIS
    客製化 Windows Server 容器
              重新建立新的容器映像檔
              推送容器映像檔至 Docker Hub
              測試客製化的 IIS 容器
    結語





    前言

    在 2013 年時,有家名為 dotCloud 提供 SaaS 服務的公司,在該公司內有項名稱為 Docker 的業餘專案,它是使用 Google 的 Go 語言進行實作。後來,dotCloud 公司讓此專案加入 Linux 基金會並在 GitHub 進行推廣及維護,此專案迅速受到廣大開發人員的喜愛同時也讓 DevOps 議題捲起更大的浪潮,甚至 dotCloud 公司後來直接改名公司名稱為 Docker Inc。

    Docker 容器管理技術如此受歡迎的主要原因之一,在於過去最困擾開發人員與維運人員的部分便是快速建立完備的開發環境,舉例來說,當開發人員需要某些開發環境時,企業或組織的維運人員便依需求建立 VM 虛擬主機、安裝作業系統、組態設定網路環境……等,接著再交由開發人員安裝相關應用程式或載入函式庫……等,此時才準備好整個開發環境,而 Docker 的出現剛好能夠解決這個困擾已久的問題。
    Docker 容器管理技術,已經在 DockerCon 2017 大會上由 Docker 創辦人兼技術長 Solomon Hykes 發佈說明,從今天開始 GitHub 上原有 Docker 專案的程式碼、運作元件……等,都屬於新的開放原始碼專案「Moby」。

    事實上,「容器」(Container)技術早已出現許久,而 Docker 則是讓容器管理這項工作任務便得容易操作及管理。一開始,Docker 容器管理技術普遍只能運作在 Linux 環境中,而微軟自從新任執行長 Satya 上任並大力擁抱開放原始碼之後,也在新一代的 Windows Server 2016 雲端作業系統中與 Docker 公司合作,打造出在 Windows Server 2016 作業系統中原生執行 Docker 引擎的容器管理環境。

    雖然,在 Windows Server 2016 作業系統中已經成功打造 Docker 容器管理環境,但是整個 Docker 容器管理實作技術與 Linux 作業系統環境是完全不同的。簡單來說,Linux 容器映像檔並無法運作在Windows Server Container 容器環境內,而 Windows 容器映像檔也無法運作在 Linux Container 容器環境中,根本原因是採用「不同 API」(Windows API vs Linux API)的運作環境,那麼我們來看看有哪些根本上的不同:

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


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

    圖 1、Linux 與 Windows 容器環境運作架構示意圖
    在 DockerCon 2017 大會上,同時發佈「LinuxKit」這個全容器化的 Linux 技術環境,希望打破不同作業系統平台(Windows 與 Linux)、虛擬化環境(VMware、KVM……等)、雲端環境(Google Cloud、AWS、Azure、Bluemix……等)、硬體(Intel 處理器、ARM 處理器、桌上型主機、筆記型電腦、伺服器、IoT 裝置……等),皆能建立 Docker 容器管理環境。

    此外在 Docker 版本的部分在 2017 年也有重大改變,從 2017 年 3 月開始 Docker 採用新的版本以及版本命名規則。首先,Docker EE(Enterprise Edition)取代舊有的 Docker CS(Commercially Supported)版本,而 Docker 開放原始碼版本重新命名為 Docker CE(Community Edition)。至於版本命名規則與 Ubuntu 的命名規則類似,將以西元的「年 . 月」的方式命名,例如,v17.03、v17.06、v17.09……等。

    圖 2、Docker 版本命名規則示意圖





    Windows 容器類型

    在 Windows 容器環境中,包含 2 種不同的容器類型或稱「執行階段」(Runtimes),分別是「Windows Server 容器」(Windows Server Container)以及「Hyper-V 容器」(Hyper-V Container)

    • Windows Server 容器: 透過程序和命名空間隔離技術提供應用程式隔離功能,讓運作於 Windows Server 容器環境中的容器能夠共用系統核心資源,這樣的運作方式與 Linux 容器環境類似。
    • Hyper-V 容器: 享有獨立系統核心資源,採用經過最佳化程序的 VM 虛擬主機執行容器環境,有效擴充原有 Windows Server 容器所提供的隔離環境。值得注意的是,執行 Hyper-V 容器的 VM 虛擬主機並非傳統的 Hyper-V VM 虛擬主機,而是運作 Windows Server 容器的特殊 VM 虛擬主機,並且具備獨立的系統核心、Guest 運算服務、基礎系統執行程序……等。
    圖 3、Windows Server 容器與 Hyper-V 容器運作架構示意圖





    Windows 容器運作環境需求 

    在 Windows 容器環境需求方面,採用 Windows Server 2016 雲端作業系統建立 Windows 容器環境時,不管採用的是 GUI 圖形介面版本、Server Core 文字介面版本,甚至是最精簡的 Nano Server 版本都同時支援「Windows Server 容器及 Hyper-V 容器」

    但是,倘若採用 Windows 10 桌面端作業系統欲建立 Windows 容器環境時,並不支援建立 Windows Server 容器運作環境,而是僅支援建立「Hyper-V 容器」運作環境,並且只有採用 Windows 10 專業版及企業版,並且安裝及啟用 Hyper-V 角色才提供建立 Hyper-V 容器運作環境。

    此外,在 Windows 容器運作環境中具備 2 種容器映像檔,分別是 Windows Server Core 及 Nano Server 容器映像檔,然而並非所有作業系統版本都同時支援運作這 2 種容器映像檔。在下列表格當中,分別條列作業系統版本支援的 Windows 容器類型以及容器映像檔:

    作業系統版本
    Windows Server 容器
    Hyper-V 容器
    Windows Server 2016 GUI 圖形介面
    Server Core / Nano Server
    Server Core / Nano Server
    Windows Server 2016 Server Core
    Server Core / Nano Server
    Server Core / Nano Server
    Windows Server 2016 Nano Server
    僅支援 Nano Server
    Server Core / Nano Server
    Windows 10 專業版/企業版
    不支援
    Server Core / Nano Server

    值得注意的是,倘若管理人員希望在 Hyper-V 虛擬化平台中的 VM 虛擬主機,能夠同時運作 Windows Server 容器環境及 Hyper-V 容器環境的話,因為先前已經說明 Hyper-V 容器環境是運作特殊的 VM 虛擬主機,所以上層的這台 VM 虛擬主機必須啟用「巢狀式虛擬化」(Nested Virtualization)功能才行。

    簡單來說,管理人員必須確保 Hyper-V 虛擬化平台符合運作巢狀式虛擬化機制,以便將「虛擬化擴充功能」(Virtualization Extensions)也就是底層硬體輔助虛擬化技術,傳遞給 Hyper-V 虛擬化平台上運作的 VM 虛擬主機當中的客體作業系統,達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
    有關 Hyper-V 虛擬化平台建構巢狀式虛擬化環境的詳細資訊,請參考本刊雜誌第 133 期專題報導「實作 Hyper-V 巢狀虛擬化,測試研發效率大提升」

    圖 4、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖





    實戰架設 Windows Server 容器環境

    下載及安裝 Docker 運作環境

    首先,我們透過 OneGet Provider 機制,安裝 PowerShell 的 Docker 模組以便稍後 Windows Server 能夠運作 Docker 運作環境。請開啟 PowerShell 命令視窗,並鍵入「Install-Module -Name DockerMsftProvider -Repository PSGallery -Force」指令,系統便會自動由 PowerShell Gallery 中,下載及安裝 Docker-Microsoft PackageManagement,執行下載及安裝指令後,當 PowerShell 視窗出現「需要 NuGet 提供者才能繼續」的詢問訊息時,請按下「Y 鍵」以便繼續安裝程序。
    Docker 運作環境,是由「Docker 引擎」(Docker Engine)「Docker 用戶端」(Docker Client)所組成。

    接著,請鍵入「Install-Package -Name docker -ProviderName DockerMsftProvider -Force」指令,使用 PackageManagement 中的 PowreShell 模組安裝最新版本的 Docker 運作環境,當安裝程序完成後系統會提示你應該要重新啟動主機,以便 Windows Server 當中的 Docker 運作環境能夠套用生效,請鍵入「Restart-Computer -Force」指令重新啟動 Windows Server 主機。

    圖 5、為 Windows Server 安裝 Docker 運作環境

    當 Windows Server 主機重新啟動後,查詢 Windows Server 主機網路連線的部分,會發現多出「vEthernet(HNS Internal NIC)」的虛擬網路卡,並且 IP 位址為「172.x.x.x / 255.255.240.0」(本文實作環境 IP 為 172.27.144.1)。這個虛擬網路卡便是屆時 Docker 運作環境中容器虛擬網路的部分,後續我們再進行詳細說明。

    圖 6、負責 Docker 運作環境中容器的虛擬網路

    當 Windows Server 下載及安裝 Docker 運作環境後,便可以透過基礎操作指令來了解 Docker 運作環境的相關資訊,舉例來說,管理人員可以鍵入「docker info」指令,系統便會詳細顯示目前 Windows Server 主機的 Docker 運作環境資訊,包含運作中的容器數量、暫停狀態的容器數量、停止狀態的容器數量、容器虛擬網路類型、容器主機記憶體容量……等。倘若,希望查詢目前 Windows Server 主機的 Docker 版本資訊時,只要鍵入「docker version」指令即可,如操作結果所示本文實作環境中 Docker 引擎及 Docker 用戶端版本為「17.03.1-ee-3」

    圖 7、查詢 Windows Server 主機的 Docker 運作環境版本資訊



    下載 Windows Server 基礎容器映像檔

    在 Windows Server 的容器運作環境中,有 2 種不同類型的基礎容器映像檔分別是 Windows Server Core 及 Nano Server。倘若,管理人員希望下載 Windows Server Core 容器映像檔,只要開啟 PowerShell 指令視窗後鍵入「docker pull microsoft/windowsservercore」指令即可,若是希望下載 Nano Server 容器映像檔,只要開啟 PowerShell 指令視窗後鍵入「docker pull microsoft/nanoserver」指令即可。

    圖 8、下載 Windows Server Core 及 Naon Server 容器映像檔

    事實上,當鍵入上述 2 行指令後,本地端的 Windows Server 主機便會至 Docker Hub 網站,下載由 Windows 官方建立的 Windows Server Core 及 Nano Server 容器映像檔,因此管理人員並不用擔心下載到被加入惡意程式的容器映像檔。

    那麼,這 2 個下載的 Windows Server Core 及 Nano Server 容器映像檔將會佔用多少空間呢 ?此時,管理人員只要鍵入「docker images」指令即可查看,在本文實作環境中可以看到 Windows Server Core 容器映像檔為「10.2GB」,而 Nano Server 容器映像檔則是「1.02GB」

    圖 9、查詢 Windows Server Core 及 Naon Server 容器映像檔佔用空間大小



    部署第 1 個 Windows Server 容器 - Hello World

    至此,Windows Server 容器運作環境已經準備完畢,管理人員可以直接從 Docker Hub 下載預先建立好的 Hello World 範例容器,以便部署及執行簡單的 Hello World 應用程式。請在開啟的 PowerShell 指令視窗中,鍵入「docker run hello-world:nanoserver」指令即可。由於,我們剛才已經先行下載好 Windows Nano Server 容器映像檔,所以不用再次下載 Nano Server 容器映像檔,因此你會發現執行這個 Hello World 容器的速度非常快速。

    圖 10、部署及執行第 1 個 Windows Server 容器



    部署第 2 個 Windows Server 容器 - IIS

    在剛才的練習中,我們已經順利運作第 1 個 Windows Server 容器。接著,我們實作練習第 2 個最常使用的 Windows Server 容器「IIS 網頁伺服器」,請鍵入「docker run -d --name MyIIS -p 80:80 microsoft/iis」指令即可,此行指令中「-d」參數表示此執行的 IIS 容器在背景運作,而「--name MyIIS」則是給予此 IIS 容器的名稱,至於「-p 80:80」則表示將 Windows Server 主機的 Port 80,與執行運作的 IIS 容器 Port 80 進行對應的動作。

    由於此 IIS 容器會使用 Windows Server Core 容器映像檔為作業系統基底,所以 Windows Server 主機若沒有 Windows Server Core 容器映像檔的話,便會需要花費額外的下載及安裝時間。在本文實作環境中,我們已經於剛才下載好 Windows Server Core 容器映像檔所以無須等待重下載及安裝時間,部署及執行 IIS 容器的動作完成後可以看到,此 IIS 容器佔用的空間大小為 10.5GB,也就是相較於 Windows Server Core 容器映像檔,加上 300MB 相關組態設定檔案。
    事實上,倘若管理人員希望運作 Hyper-V 容器的話,只要加上「--isolation=hyperv」參數即可,當然前提是 Windows Server 主機已安裝及啟用 Hyper-V 角色。

    圖 11、下載及執行基於 Windows Server Core 運作環境的 IIS 容器

    在開始與剛才執行的 IIS 容器進行互動之前,管理人員可以先執行「docker ps」指令,查詢目前運作中的容器資訊,從執行結果可以看到目前 Windows Server 主機上運作的容器只有 1 個(透過 docker info 指令也能查詢容器運作狀態數量),並且可以看到容器 ID、容器映像檔、執行指令、容器建立時間、運作狀態、連接埠對應、容器名稱……等。

    確認 IIS 容器仍持續運作中,接著執行「docker exec -i MyIIS cmd」指令進入 IIS 容器內執行互動作業,成功進行 IIS 容器互動模式後可以看到指令視窗中的提示字元,由原本的 PowerShell 變成命令提示字元。首先,請執行「del C:\inetpub\wwwroot\iisstart.htm」指令,刪除 IIS 容器內預設的歡迎頁面,然後執行「echo "This IIS Welcome page from Windows Server Container" > C: \inetpub\wwwroot\index.html」指令,將自訂字串訊息寫入 IIS 容器內的 IIS 歡迎頁面中。最後,便可以執行 exit 指令離開 IIS 容器互動模式回到 Windows Server 容器主機。

    圖 12、進入 IIS 容器互動模式並自訂 IIS 歡迎頁面內容

    完成 IIS 容器互動模式並自訂 IIS 歡迎頁面內容的動作後,請先確認 Windows Server 容器主機的防火牆規則中,是否已經允許 TCP Port 80 的網路流量能夠通過防火牆,接著請使用「別台主機」透過瀏覽器連接至 Windows Server 容器主機的 IP 位址,本文實作環境中 Windows Server 容器主機的 IP 位址為「http: //10.10.75.69」。此時,應該可以順利看到剛才我們所自訂的 IIS 歡迎頁面內容。
    請注意,由於 Windows Server 容器虛擬網路 NAT 網路環境的關係,必須以「別台」主機透過瀏覽器才能確認能否瀏覽由 IIS 容器所提供的 IIS 歡迎頁面。倘若,從 Windows Server 容器主機採用「本機」的方式直接開啟瀏覽器,嘗試瀏覽由 IIS 容器所提供的 IIS 歡迎頁面時,將會發現是無法順利瀏覽的。

    圖 13、順利看到剛才我們所自訂的 IIS 歡迎頁面內容

    倘若,管理人員希望「停止」IIS 容器時,只要執行「docker stop < 容器名稱或容器 ID>」即可,後續希望再將 IIS 容器「啟動」時也只要執行「docker start < 容器名稱或容器 ID>」即可,若是希望「重新啟動」IIS 容器時請執行「docker restart < 容器名稱或容器 ID>」即可。
    請注意,當容器的運作狀態為停止時透過「docker ps」指令是無法查詢到容器資訊的。此時,請執行「docker ps -a」便可以查詢到所有運作狀態的容器。

    圖 14、針對容器進行停止、啟動、重新啟動等基本操作





    客製化 Windows Server 容器

    在剛才的實作練習中,我們都是執行官方預先提供的範例容器或下載及執行容器後再進行修改,接著我們將實作練習客製化 Windows Server 容器,依據企業及組織的運作需求自行打造符合內部運作環境的容器。



    重新建立新的容器映像檔

    以剛才我們所練習的 IIS 容器為例,請先執行「docker stop MyIIS」指令將 IIS 容器停止運作,使用「docker ps -a」指令確認 IIS 容器的運作狀態為「Exited」表示已經停止運作後,執行「docker commit MyIIS weithenn/myiis」指令,將剛才我們已經修改過內容的 IIS 容器,重新建立成新的容器映像檔並且客製化名稱為「weithenn/myiis」,重新建立容器映像檔的動作執行完成後,可以使用「docker images」指令進行確認。

    圖 15、重新建立新的 IIS 容器映像檔並且客製化名稱為 weithenn/myiis



    推送容器映像檔至 Docker Hub

    重新建立 IIS 容器映像檔的動作執行完成後,我們可以將這個客製化的 IIS 容器映像檔推送至 Docker Hub,以便後續我們不管在哪一台 Windows Server 容器主機上需要使用此客製化 IIS 容器時,便能夠透過網際網路連線從 Docker Hub 網站下載後使用。

    當然,管理人員必須先至 Docker Hub 網站註冊帳戶以便產生 Repositories 容器存放庫。確認 Docker Hub 帳戶註冊且運作無誤後,請回到 Windows Server 容器主機上執行「docker login」指令進行登入 Docker Hub 網站的動作,成功登入 Docker Hub 網站後執行「docker push weithenn/myiis」指令,將剛才重新建立 IIS 容器映像檔上傳至 Docker Hub 網站上。
    請注意,預設情況下上傳至 Docker Hub 網站的容器映像檔為「公開」(Public),也就是公開給網際網路上的任何人下載使用,倘若管理人員希望這個容器為「私人」(Private)使用的話,請記得至 Docker Hub 網站針對此容器進行權限調整。
    圖 16、上傳客製化的 IIS 容器映像檔至 Docker Hub 網站



    測試客製化的 IIS 容器

    順利將客製化後的 IIS 容器映像檔上傳至 Docker Hub 網站後,接著我們便可以測試是否能夠隨時由 Docker Hub 網站上,下載我們所客製化後的 IIS 容器映像檔並且執行部署的動作。首先,請執行「docker rmi weithenn/myiis」指令,將 Windows Server 容器主機中原有的 weithenn/myiis 容器映像檔刪除,並執行「docker images」指令再次確認 weithenn/myiis 容器映像檔是否已經刪除成功。

    圖 17、將客製化的 IIS 容器映像檔刪除

    確認已經 Windows Server 容器主機中原有的 weithenn/myiis 容器映像檔已經刪除後,便可以執行「docker pull weithenn/myiis」指令,讓 Windows Server 容器主機至 Docker Hub 下載剛才所上傳的 weithenn/myiis 容器映像檔,下載完成後便可以執行「docker run -d -p 80: 80 weithenn/myiis」指令,部署客製化過的 weithenn/myiis 容器映像檔,並執行「docker ps」指令確認 weithenn/myiis 容器是否運作中。

    圖 18、至 Docker Hub 下載剛才所上傳的 weithenn/myiis 容器映像檔並進行部署作業





    結語

    透過本文的說明及實作練習,管理人員應該能夠體會到透過 Windows 容器技術,能夠以 Windows Server 容器提供類似 Linux 的容器環境,倘若需要更佳的容器隔離安全性的話則部署 Hyper-V 容器即可。同時,結合 Docker 容器管理技術,相信可以幫助企業及組織降低維運成本,同時也能降低資料中心維運人員的管理負擔。

    活動簡介

    Devopsdays 是全球性的技術系列盛會,由各地城市組織、發起自己的 Devopsdays,探討包含軟體開發、IT架構維運,以及兩者之間交互的議題。常見的議程包括了自動化、測試、資訊安全以及組織文化。

    DevOpsDays Taipei 在 2017 年 9 月首次舉行,透過在地社群 Agile Community TW、DevOps Taiwan 以及 IT 媒體 iThome 聯手之下,邀集台灣在 DevOps 領域的技術專家,共同推動 DevOps 這波技術與文化的轉型運動,與世界脈動接軌。



    活動資訊




    活動內容