網管人雜誌
本文刊載於 網管人雜誌第 146 期 - 2018 年 3 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言VMware Photon 容器平台
裸機 vs VM 虛擬主機 vs 容器
Weathervane 效能測試工具
效能測試環境
VM 虛擬主機測試環境
裸機測試環境
效能測試（Docker 容器未最佳化）
Docker 容器最佳化 – VM 虛擬主機
Docker 容器最佳化 – 裸機
效能測試（Docker 容器最佳化）
結語
前言
自從 2013 年 dotCloud 這間原本提供 PaaS 服務的公司，將自家開發用於管理 PaaS 服務的容器技術「Docker」貢獻給開放源始碼，並將所有源始碼內容上傳至 GitHub 之後，由於 Docker 容器管理技術能夠快速且有效解決，過往開發環境在建構 / 測試 / 佈署上的種種困擾及問題。因此，Docker 容器技術便迅速在業界開始廣為流傳，甚至演變成 Docker 就是容器技術的代名詞。
時至今日，Docker 容器管理技術能夠如此迅速發展，並非僅是能夠巧妙的利用「容器」（Container）技術來管理過往開發環境的困擾，主要原因在於 Docker 容器技術在推廣時期，同時也營造出非常良好的生態系統（如圖 1 所示），讓社群、開放源始碼、商業公司……等大家都能夠互惠且互助合作，所以 Docker 容器技術在魚幫水且水幫魚的情況下，短短幾年的時間便改變整個業界佈署應用程式及服務的型態。
圖 1、Docker 生態系統運作示意圖
此外，隨著新興的「微服務」（MicroService）佈署架構的盛行，Docker 容器技術也被許多管理人員推薦為佈署微服務架構的首選。因此，隨著 Docker 容器技術的盛行，企業及組織對於應用程式及服務的建構和佈署模式也隨之改變，管理人員開始思考如何將既有的應用程式及服務「容器化」（Containerization），以便在建構的微服務架構下搭配 Docker 容器技術佈署企業及組織的營運服務。
同時，當企業及組織的 IT 團隊，開始使用 Docker 容器技術管理應用程式及服務後，也能夠讓企業及組織當中的軟體開發人員團隊及 IT 維運管理人員之間的 DevOps 流程更加順暢（如圖 2 所示），並且也讓軟體團隊的「CI/CD 持續整合及發佈」（Continuous Integration / Continuous Delivery）自動化流程更加緊密，讓開發人員能夠更加專注在開發及維護程式碼的品質上，進而打造出提升企業競爭力的產品和服務。
圖 2、CI/CD 持續整合及發佈流程示意圖
VMware Photon 容器平台
有鑑於 Docker 容器技術日漸風行，VMware 官方也在 2015 年 4 月時，推出 Photon OS 及 Project Lightwave 這 2 項開放原始碼專案，並且也上傳到知名的開放原始碼專案平台 GitHub 上，讓所有對於 VMware Photon 容器平台感興趣的管理人員能夠方便下載使用，同時在 2016 年 10 月 VMworld 歐洲大會上也正式發佈 VMware Photon Platform，希望能夠幫助企業及組織輕鬆打造出「雲端原生應用程式」（Cloud Native Applications）的運作環境（如圖 3 所示）。
圖 3、VMware Photon Platform 容器平台運作架構示意圖
簡單來說，在 VMware Photon Platform 容器平台解決方案中，Photon OS 負責擔任輕量級的容器作業系統（儲存空間僅佔用約 300MB），雖然 Photon OS 也是源至於 Linux 作業系統，但是已經移除不必要的 Linux Kernel 程式碼，以及與 vSphere Hypervisor 之間重複的核心快取機制，因此在 VMware vSphere 虛擬化基礎架構中，運作 Photon OS 容器平台將能夠更加充分發揮 Docker 容器的運作效能。此外，Photon OS 容器平台在佈署方面不但能夠與 K8S 容器調度平台協同運作，就連管理人員對容器技術最為在意的安全性方面，甚至能夠直接與 VMware NSX 網路虛擬化技術的「微分段」（Micro-Segmentation）機制協同運作，輕鬆為 Docker 容器加強整體安全性（如圖 4 所示）。
圖 4、Photon Platform 及 NSX 協同運作有效提升容器安全性
裸機 vs VM 虛擬主機 vs 容器
過去，企業及組織佈署營運服務的方式，通常是採用「實體伺服器」直接運作應用程式或服務，或者是以實體伺服器為基礎建立「虛擬化基礎架構」之後，在虛擬化基礎架構之上的 VM 虛擬主機中運作應用程式或服務。目前，由於 Docker 容器技術輕量化的應用方式並搭配新興的微服務架構，因此越來越多企業及組織在佈署營運服務時，開始將 Docker 容器技術的佈署方式加入至營運服務的環節當中。下列，便是目前企業及組織佈署營運服務時主要的 4 種應用情境（如圖 5 所示）：
- 裸機： 直接在 x86 實體伺服器上，安裝應用程式或服務所需的作業系統之後，直接運作相關的應用程式及服務。
- VM 虛擬主機： 以 x86 實體伺服器為基礎在其上建構虛擬化基礎架構（例如，VMware vSphere），為 VM 虛擬主機安裝好 Guest OS 客體作業系統之後，運作所需的應用程式或服務。
- 裸機 + Docker 容器： 在 x86 實體伺服器上安裝作業系統並組態設定 Docker 容器運作環境後，透過 Docker 容器技術運作所需的應用程式和服務。
- VM 虛擬主機 + Docker 容器： 除了採用虛擬化基礎架構建構最佳化的 VM 虛擬主機之外，待 VM 虛擬主機安裝好 Guest OS 客體作業系統之後，組態設定 Docker 容器運作環境後運作所需的應用程式和服務。
圖 5、目前企業及組織佈署營運服務時主要的 4 種應用情境
Weathervane 效能測試工具
那麼企業及組織在佈署營運服務時，究竟是佈署在「裸機、VM 虛擬主機、Docker 容器」三者當中何者的運作效能最佳？ 因此，本文將說明及實作在裸機以及 VMware vSphere 6.5 虛擬化平台上，測試裸機原生運作應用程式及 VM 虛擬主機運作應用程式，和 VM 虛擬主機搭配 Docker 容器環境運作應用程式這三者之間的效能差異。首先，在效能測試工具方面採用開放源始碼 Weathervane 1.0.15 效能測試工具，它能夠模擬典型的拍賣網站工作負載，並且這些工作負載可以佈署在作業系統上或 Docker 容器環境中，在 Weathervane 效能測試項目中包括可擴充的多層 Web 應用程式（如圖 6 所示），主要由下列服務項目所組成：
- Java Application Server： 負責執行拍賣網站工作負載中核心應用程式服務。
- 前端 Web 服務： 負責提供 Web 網頁服務以及網頁請求負載平衡，同時必須支援 HTTP-Level 快取機制以便將前端網頁請求，正確的遞送到後端服務當中。
- 應用程式支援服務： 負責為不同服務之間提供訊息及協調服務。
- 資料服務： 負責提供關聯式資料庫以及 NoSQL 非關聯式資料庫服務。
圖 6、Weathervane 效能測試工具可擴充多層應用程式架構示意圖
效能測試環境
在本文效能測試環境中，採用 4 台實體伺服器進行整個效能測試作業（如圖 7 所示），其中 2 台擔任 Driver Servers 角色，負責運作相關工作負載的 VM 虛擬主機，另外 2 台則是擔任 Test Server 角色，這 2 台當中有 1 台是安裝 VMware vSphere 6.5 虛擬化平台，然後在 VM 虛擬主機中安裝 CentOS 7.3 客體作業系統以提供 Docker 容器環境，另 1 台則是直接裸機安裝 CentOS 7.3 作業系統以提供 Docker 容器環境。
圖 7、Weathervane 效能測試環境示意圖
VM 虛擬主機測試環境
在 Test Server 角色中，其中 1 台 x86 伺服器為安裝 VMware vSphere 6.5 虛擬化平台，第 1 項測試項目直接以 VM 虛擬主機安裝 CentOS 7.3 作業系統後，以「VM 虛擬主機」為單位執行不同的 Weathervane 角色進行效能測試（如圖 8 所示），相關項目如下：- vSphere 6.5 電力選項： 調整為 High Performance。
- CentOS 7.3 客體作業系統： 安裝 VMware Tools 為 open-vm-tools 10.0.5-4.el7_3。
- 硬體資源： 總共建立 13 台 VM 虛擬主機，共使用 32 vCPU 及 150GB vRAM。
在第 2 項測試項目中，vSphere 6.5 及 VM 虛擬主機採用的硬體配置同上，在每台 VM 虛擬主機上僅運作「1 個容器」，也就是以「容器」為單位執行不同的 Weathervane 角色進行效能測試。每台 VM 虛擬主機，安裝 CentOS 7.3 客體作業系統後安裝 Docker 容器運作環境（Docker 版本 17.05.0-ce），在容器虛擬網路的部分則是採用預設跨主機的「Overlay Driver」。
圖 8、VM 虛擬主機和 VM 虛擬主機搭配 Docker 容器的效能測試角色
裸機測試環境
在 Test Server 角色中，另 1 台 x86 伺服器為直接安裝 CentOS 7.3 作業系統，然後安裝 Docker 容器運作環境（Docker 版本 17.10.0-ce），在容器虛擬網路的部分則是採用預設跨主機的「Overlay Driver」，以「裸機」的方式進行 Weathervane 效能測試作業。
圖 9、效能測試環境採用的 Docker 容器技術版本
值得注意的是，在 Weathervane 的 OS Performance 效能選項中，採用「Latency-Performance Profile」選項為根據 Weathervane 最佳建議作法，並且我們在裸機 Docker 運作環境中，運作 13 個 Docker 容器並使用 32 vCPU 及 150 GB vRAM 的硬體資源（如圖 10 所示）。
由於每個 Docker 容器使用的硬體資源不同，因此在執行「docker run」指令運作 Docker 容器時，將會搭配「--cpus 及 --memory」參數選項，定義每個 Docker 容器所能使用的硬體資源。
圖 10、裸機測試環境中 Docker 容器的效能測試角色及硬體資源配置示意
效能測試（Docker 容器未最佳化）
在目前「容器」（Container）的應用情境中，共有 3 種主流應用情境分別是直接將 x86 硬體伺服器使用的「裸機」（Bare-Metal）佈署方式，也就是直接將實體伺服器安裝容器平台之後，直接在其上運作數量眾多的容器以便提供應用程式及服務。第 2 種及第 3 種主流應用情境，則是企業或組織已經建構好整個虛擬化基礎架構，所以透過以 VM 虛擬主機隔離方式提供應用程式及服務，或者是索性在 VM 虛擬主機當中提供容器平台後運作多個容器，以便提供營運需要的應用程式及服務。
圖 11、裸機 vs VM 虛擬主機 vs 容器佈署模式示意圖
或許，讀者在許多網路文章中會看到「容器」（Container）所訴求的輕量級，而認為將應用程式或服務運作在 VM 虛擬主機可能會顯得效能不彰。因此，在本文當中將採用開放源始碼效能測試工具 Weathervane，針對剛才上述 3 種主流佈署應用程式或服務的情境進行效能測試，以便幫助讀者了解應用程式及服務在不同應用情境中的效能表現：
- VM 虛擬主機： 採用 vSphere 6.5 虛擬化平台中的 VM 虛擬主機，直接運作 Weathervane 開放源始碼效能測試工具，並未在 VM 虛擬主機當中運作 Docker 容器。在測試結果中，直接以 VM 虛擬主機運作 Weathervane 效能測試工作負載為最佳表現，最多同時支援 40,062 個使用者，相當於每秒回應 25,000 個 HTTP 服務請求。
- VM 虛擬主機 + Docker 容器： 採用 vSphere 6.5 虛擬化平台中的 VM 虛擬主機，並且在 VM 虛擬主機當中運作 Docker 容器環境後，運作 Weathervane 開放源始碼效能測試工具。採用 VM 虛擬主機搭配 Docker 容器環境後，效能測試工作負載最多同時支援 35,969 個使用者，大約是直接採用 VM 虛擬主機的 90% 的效能表現。
- 裸機運作 Docker 容器： 在裸機運作環境中提供 Docker 容器環境後，運作 Weathervane 開放源始碼效能測試工具，效能測試工作負載最多同時支援 30,657 個使用者，大約是直接採用 VM 虛擬主機的 77% 的效能表現。
圖 12、效能測試– Docker 容器未最佳化
Docker 容器最佳化 – VM 虛擬主機
上述效能測試結果，可能會讓許多管理人員感到困惑，因為對於 Docker 容器技術的印象便是輕量級並且能夠充份使用硬體資源，但是測試結果確是由 VM 虛擬主機直接運作工作負載，反而得到最佳運作效能。事實上，影響 Docker 容器運作效能的因素很多，例如，執行 docker run 及 docker create 建立容器時，應該如何配置 Docker 容器能夠使用的 CPU 及記憶體硬體資源，此外 Docker 容器採用的虛擬網路驅動程式類型，以及 Docker Engine 使用的儲存驅動程式類型，也都會影響 Docker 容器整體的效能表現。
首先，在本文效能測試環境中由於統一採用儲存設備提供儲存資源，所以在 Docker 容器中採用的儲存驅動程式類型，並未影響到效能測試的結果。但是，在「網路」類型方面則是影響效能表現的原因之一，在預設情況下 Docker 容器會採用「Bridge」虛擬網路類型，好處是在「同 1 台」Docker 主機中的容器彼此溝通非常快速，同時外部的存取需求也能透過 TCP/UDP 對應的方式存取容器服務。
但是，在本文效能測試環境中，由於每台 VM 虛擬主機僅會運作 1 個容器，因此容器與容器之間的通訊必須「跨 Docker 主機」，最直接的影響是除了「網路延遲時間拉長」之外，也會增加 Docker 主機的「CPU 工作負載」，所以便會影響 Docker 容器整體的效能表現。
最簡單的效能改善方式，便是讓 Docker 容器採用不同類型的虛擬網路驅動程式類型，將原本預設採用的 Bridge 虛擬網路類型，變更為直接使用 Docker 主機網路堆疊的「host」虛擬網路類型，雖然會有容器使用連接埠對應的限制，但是在本文測試環境中 1 台 VM 虛擬主機只運作 1 個容器，因此並不會受到此限制所影響。
在執行 docker run 指令運作 Docker 容器時，請搭配「--network=host」參數指定 Docker 容器採用 Docker 主機網路堆疊。調整 Docker 容器虛擬網路類型之後，再次進行效能測試可以發現先前採用 Bridge 虛擬網路類型時，最多僅能同時支援 35,969 個使用者，將 Docker 容器更改為 host 虛擬網路類型後，最高同時支援使用者數量提升至 39,109。
圖 13、Docker 容器採用不同虛擬網路類型對於整體效能表現的影響
Docker 容器最佳化 – 裸機
事實上，在先前的效能測試結果中，許多讀者應該會感到困惑的部分在於就一般認知來說，採用裸機的方式運作 Docker 容器和工作負載的效能測試應該最佳才對，但是在效能測試結果中卻反而是表現最差的運作環境。主要原因在於，未經過效能調校的 Docker 容器僅會運作在「單顆」CPU 處理器上，所以整體運作效能會受到限制，然而運作在 VMware vSphere 6.5 虛擬化平台上的 Docker 容器，因為受惠於 vSphere 6.5 的最佳化排程演算法而能充分使用實體伺服器的「多顆」CPU 處理器運算效能。
圖 14、裸機運作環境中，未經過效能調校之前 Docker 容器無法充分利用運算資源
值得注意的是，與剛才在 VMware vSphere 6.5 虛擬化平台上運作的 Docker 容器不同，雖然在裸機運作環境中的 Docker 容器採用預設的 Bridge 虛擬網路類型，但是因為所有的 Docker 容器都運作在「同 1 台」裸機伺服器當中，所以並沒有受到 Bridge 虛擬網路類型的影響，至於儲存資源也因為直接採用硬體儲存設備而未受到任何影響。
所以，在裸機運作環境中 Docker 容器整體的效能表現，主要受到 CPU 處理器運作資源是否能夠妥善利用所影響。首先，我們可以針對每個 Docker 容器在運作時，配置「CPU 親和性」（CPU Affinity）並且搭配使用 NUMA Node 的「記憶體親和性」（Memory Affinity）機制，此舉可以讓裸機運作環境中 Docker 容器的效能表現，由先前最多僅能同時支援 30,625 個使用者，提升至最高同時支援 35,516 個使用者，舉例來說，在透過 Docker 容器技術啟動 PostgreSQL 時請執行下列指令 (建立及運作 Docker 容器時，請搭配 --cpuset-cpus 和 --cpuset-mems 參數使用)：
docker run -d -v /mnt/dbLogs/postgresql:/mnt/dbLogs/postgresql -v /mnt/dbData/postgresql:/mnt/dbData/postgresql -p 5432 --cpus=4.00 --cpuset-cpus=12,32,14,34 --cpuset-mems=0 --memory=16G --name IsoW1I1Db1D localRegistry:5000/weathervane-postgresql:1.0.15倘若，我們在配置 CPU 親和性機制後，再搭配 Docker 容器配置相同數量的邏輯 CPU 處理器，達到 CPU 執行緒數量相同的最佳化配置時，可以讓裸機運作環境中 Docker 容器的效能表現，再提升至最高同時支援 36,952 個使用者，舉例來說，在透過 Docker 容器技術啟動 PostgreSQL 時請執行下列指令 (建立及運作 Docker 容器時，使用的 --cpuset-cpus 參數必須搭配邏輯 CPU 處理器數量)：
docker run -d -v /mnt/dbLogs/postgresql:/mnt/dbLogs/postgresql -v /mnt/dbData/postgresql:/mnt/dbData/postgresql -p 5432 --cpus=4.00 --cpuset-cpus=0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 --cpuset-mems=0 --memory=16G --name IsoW1I1Db1D localRegistry:5000/weathervane-postgresql:1.0.15
圖 15、裸機運作環境中，經過效能調校後 Docker 容器整體效能提升許多
效能測試（Docker 容器最佳化）
從上述 3 種主流應用情境運作 Weathervane 開放源始碼效能測試工具的結果可知，在 VMware vSphere 6.5 虛擬化平台中，採用 VM 虛擬主機直接運作 Weathervane 開放源始碼效能測試工具，或者是採用 VM 虛擬主機加上 Docker 容器環境後，再運作 Weathervane 開放源始碼效能測試工具後，所測試出來的效能結果二者幾乎相同。此外，還可以看到在 VMware vSphere 6.5 虛擬化平台中，不管直接採用 VM 虛擬主機或是 VM 虛擬主機加 Docker 容器環境，相較於裸機運作 Docker 容器的效能表現都要提升約 5% 的效能數據，主要便是受益於 vSphere 6.5 內建的工作負載調度演算法所帶來的好處。
圖 16、3 種主流應用情境運作 Weathervane 開放源始碼效能測試工具的結果
