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

VMware vSphere 6.7 Journey (1) - 新功能簡介

May 21, 2018, 8:31 pm
$
0
0

前言

VMware 官方在 2018 年 4 月 17 日，正式發佈全新 VMware vSphere 6.7 軟體定義資料中心解決方案。








更簡單更高效能的管理機制

在前一版 vSphere 6.5 的基礎之上，再次增強整體的管理性及高效能。在新版 vSphere 6.7當中，基於 SUSE Linux 打造的 vCSA (vCenter Server Appliance)管理平台，除了已經包含 PSC (Platform Services Controller)、Linked Mode……等功能外，相較於舊版 vCSA 6.5 操作效能上提升 2 倍、記憶體使用量減少 3 倍、執行 DRS 的速度提升 3 倍……等。因此，vCSA 已經可以完全取代 Windows vCenter Server 管理平台。
VMware 官方已經宣佈，在新版 vSphere 6.7當中將是「最後一版」包含 Windows vCenter Server 的版本。
圖、vCSA 運作示意圖
圖片來源： Introducing VMware vSphere 6.7! - VMware vSphere Blog





vSphere Quick Boot

過去，當管理人員在進行 ESXi 主機主要版本升級作業時，通常會重新啟動 ESXi 主機多次 (有可能 2 ~ 3 次)。在新版 vSphere 6.7 當中，主要版本升級作業只要「1 次」(Single Reboot)即可完成，有效縮短 ESXi 主機的停機時間。

此外，過去要重新啟動 ESXi Hypervisor 虛擬管理程序時，只能透過重新啟動 ESXi 主機的方式達成。現在，透過新版 vSphere 6.7當中的 vSphere Quick Boot機制，無須重新啟動 ESXi 主機即可達成重新啟動 ESXi Hypervisor 虛擬管理程序，同樣有效縮短 ESXi 主機的停機時間。






HTML5-based vSphere Client 管理工具

下一代的管理工具 HTML 5 vSphere Client，在新版 vSphere 6.7當中已經完成 90% ~ 95%的功能性。現在，管理人員可以透過 HTML 5 vSphere Client 管理 NSX, vSAN, VUM 等運作環境。

此外，VMware 官方已經發佈資訊預計在 2018 年秋天，將會推出完整功能的 HTML 5 vSphere Client 管理工具版本。詳細資訊請參考 Fully Featured HTML5-based vSphere Client Coming in Fall 2018 - VMware vSphere Blog。

圖、HTML5 vSphere Client 管理工具
圖片來源： Introducing VMware vSphere 6.7! - VMware vSphere Blog





全方位的安全性保護

在新版 vSphere 6.7 當中，除了支援 TPM 2.0 (Trusted Platform Module)之外，還支援 vTPM 2.0 (Virtual TPM) 功能。因此，整個安全性的守備範圍可以深入到 Guest OS 層面，達到更全方位的安全性保護。






Universal Application Platform

在新版 vSphere 6.7 運作環境中，支援各項工作負載如  3D Graphics、Big Data、HPC、Machine Learning、In-Memory、Cloud-Native……等。同時，針對 Nvidia GRID™ vGPU的部分更增強相關功能。

此外，也支援新一代儲存資源及機制，例如，PMem (Persistant Memory)、Native 4Kn disk support、RDMA、Intel VMD for NVMe……等。

圖、儲存資源比較示意圖
圖片來源： Introducing VMware vSphere 6.7! - VMware vSphere Blog





混合雲管理體驗

在新版 vSphere 6.7 運作環境中，針對 vCenter Server 管理平台新增多項新功能和機制，例如，vCenter Server Hybrid Linked Mode、Cross-Cloud Cold and Hot Migration、Per-VM EVC (Enhanced vMotion Compatibility)、Cross-vCenter、Mixed-version Provisioning (例如，vMotion、Full Clone、Cold Migrate…等)。

圖、vCenter Server 混合雲管理體驗示意圖
圖片來源： Introducing VMware vSphere 6.7! - VMware vSphere Blog





參考資源






VMware vSphere 6.7 攻略 - 系列文章

↧
Search

VMware vSphere 6.7 Journey (2) - vCenter Server

May 22, 2018, 8:39 pm
$
0
0

前言

在新版 vSphere 6.7當中 vCSA (vCenter Server Appliance) 管理平台，現在已經是「預設」的部署選項。基於 SUSE Linux 打造的 vCSA (vCenter Server Appliance)管理平台，除了已經包含 PSC (Platform Services Controller)、Linked Mode……等功能外，相較於舊版 vCSA 6.5 操作效能上提升 2 倍、記憶體使用量減少 3 倍、執行 DRS 的速度提升 3 倍……等。


事實上，在新版 vSphere 6.7 當中，傳統的 vSphere Web Client (Flash)也是最後一版，vSphere 管理人員應該開始使用全新 HTML 5 vSphere Client管理工具，因為整體功能完整性已經達到 90% ~ 95% 的功能性 (已可管理 vSAN, Storage Policies、Host Profile、vDS Topology Diagram……等功能和組態設定)。

此外，VMware 官方已經發佈資訊預計在 2018 年秋天，將會推出完整功能的 HTML 5 vSphere Client 管理工具版本。詳細資訊請參考 Fully Featured HTML5-based vSphere Client Coming in Fall 2018 - VMware vSphere Blog。

圖、HTML 5 vSphere Client 管理工具





vCSA 6.7 新增/增強功能

現在，管理人員可以透過 vCenter Server Appliance 6.7 管理任何規模的 vSphere 虛擬化架構。下列為新版 vCSA 6.7 新增/增強功能：

  • 新增 Enhanced Linked Mode至 Embedded PSC 當中。
  • 無須建置負載平衡機制，即可輕鬆建立 vCSA HA 高可用性機制。
  • SSO Site機制達成更高的靈活性。
  • 支援大型 vSphere 運作規模。
  • 在 vSphere SSO Domain 中允許進行 15 次的部署。
  • 減少不必要的管理和維護節點數量。
  • 底層作業系統由 SUSE Linux更改為 Photon OS，以便更容易達成 Rollback 機制。





遷移至 vCSA 6.7 管理平台

因為新版 vCSA 6.7 管理平台，已經可以完全取代 Windows vCenter Server 管理平台。所以，VMware 官方已經宣佈，在新版 vSphere 6.7當中將是「最後一版」包含 Windows vCenter Server 的版本。同時，VMware 官方也推出遷移工具幫助企業及組織，將現有 Windows vCenter Server 遷移至 vCSA 管理平台。遷移過程可參考 VMware 官方資源 Migration from vCenter Server 6.0 Embedded to VCSA 6.5。

圖、遷移 Windows vCenter Server 至 vCSA 管理平台

值得注意的是，倘若是舊版 vSphere 5.5 必須先升級至 vSphere 6.x 才行，下列便是版本升級建議：
  • vSphere 6.0 / 6.5可直接升級至 vSphere 6.7。
  • vSphere 5.5必須先升級至 vSphere 6.0 / 6.5才能升級至 vSphere 6.7。
  • vSphere 5.5 End of General Support 至 2018/9/19 (詳請參考 VMware Lifecycle Product Matrix)。






vCSA 6.7 監控和管理機制

vSphere 管理人員，現在可以連結至 vCSA 6.7 管理平台的 Port 5480，即可透過由 Clarity UI建構的 VAMI (vSphere Appliance Management Interface) 維運  vCSA 6.7 管理平台，包含看到 vCSA 的 CPU、Memory、Network、Database 使用率……資源使用情況。

圖、VAMI 管理介面






參考資源






VMware vSphere 6.7 攻略 - 系列文章

↧
↧

Python Journey (3) - Numbers / Strings / List

May 24, 2018, 6:43 pm
$
0
0

前言

開始 Python 的 資料型態 (Datatype)基本練習，本文針對簡單的 數字 (Numbers)、字串 (Strings)、序列 (List)進行練習。






數值型態 (Numeric Type)

加減乘除

數值型態中，最簡單就是「整數」(Integers)，例如，174 這個數值就是整數。另一個常見的就是「浮點數」(Floating point numbers)，例如，174.87 這個數值就是浮點數。其它更詳細的數值型態資訊，請參考官方文章：

最簡單的數值練習便是「加 (+),  減 (-), 乘 (*), 除 (/)」，同時也可以配合「括號 ()」進行處理，數值想要處理成「次方」也只要使用「**」即可。值得注意的是預設情況下，採用「/」(Division)會返回浮點數 (Float)，也就是當數值無法整除時會有小數點的數值。此外：
  • 希望除法的數值為「整數」而非浮點數的話可以使用「//」，但是若採用整數與浮點數搭配的話，還是會得到浮點數。
  • 希望除法的數值為「取餘數」的話，可以使用「%」即可。
圖、數值型態練習





字串型態 (String Type)

簡單來說，只要使用「單引號」single quotes ('...')或「雙引號」double quotes ("...")，便是告訴 Python 這中間的字符為字串型態，其它更詳細的字串型態資訊，請參考官方文章：

下列為字串型態在使用上的注意事項：
  • 需要在字串中間真實呈現單引號或雙引號時，請使用「跳脫字元」(\)即可。
  • 需要字串能夠「換行」時，請使用「\n」即可。或者，也可以使用「3 個」單引號或雙引號，那麼便可以真實呈現字串內容。
  • 需要字串能夠呈現「\」時，請在單引號或雙引號「之前」加上「r」即可。
  • 需要字串能重複出現，只要搭配「*」即可。
  • 需要「接續」二個字串內容時，只要搭配「+」即可。
  • 透過 [ ]指定索引，可以取得字串中某個字元 (記得從 0開始，若是負數則是從尾算起)。
圖、字串型態練習





序列型態 (Sequence Type)

簡單來說，有時你可能需要一連串的「數字或字串」當需要時取出它們，或者在操作的過程中還需要改變它們的內容，這些需求都可以透過 List來達成。倘若，希望這些物件內容是不可變時，就請改為採用 Tuple。其它更詳細的序列型態資訊，請參考官方文章：

圖、List 練習





內建函式 (Built-in Function)

針對數值型態及字串型態，本文中使用到的內建函式如下所示，其它更詳細的數值型態資訊，請參考官方文章 2. Built-in Functions — Python 3.6.5 documentation：

  • len ()： 用來計算字串或數值「長度」(Length)。
  • str ()： 告訴 Python 該物件為「字串」(String)。
  • print ()： 告訴 Python 印出「物件」(Objects)。
  • type ()： 告訴 Python 印出 Objects 的「類型」(Types)。
  • append ()： 告訴 Python 物件後加入「項目」(Item)。





參考資源






Python 系列文章

↧

VMware vSphere 6.7 Journey (3) - RDMA

May 24, 2018, 11:31 pm
$
0
0

前言

事實上，在前一版 vSphere 6.5當中便已經開始正式支援 RDMA (Remote Direct Memory Access)當中的 RoCE (RDMA over Converged Ethernet)，以便於達到「Kernel Bypass、Zero Copy、CPU Offloading」的目的。有關 vSphere 6.5支援 RDMA 的相關資訊，請參考站內文章 vSphere 6.5 支援 RDMA (RoCE v1 及 RoCE v2)。


圖、RDMA 運作示意圖
圖片來源：  vSphere 6.7 Core Storage - RDMA support in vSphere





全面支援 RDMA (InfiniBand / iWARP / RoCE)

在新版 vSphere 6.7運作環境中，全面支援 RDMA (InfiniBand / iWARP / RoCE) 之外，更增強 vSphere Kernel / Hypervisr / RDMA之間的協同運作的部分，讓整體運作效能更加提升。
在 vSphere 6.5版本中，並不支援InfiniBand及 iWARP。
圖、vSphere 6.7 全面支援 RDMA (InfiniBand / iWARP / RoCE)
圖片來源：  vSphere 6.7 Core Storage - RDMA support in vSphere

值得注意的是，倘若 VM 虛擬主機採用的 RDMA 為「Passthruogh Mode」時，雖然可以得到最大化的運作效能，但是將會限制 VM 虛擬主機的靈活性，例如，無法接受 DRS 自動化機制的調度 (無法 vMotion 至其它 ESXi 主機)。

因此，倘若希望 VM 虛擬主機希望具備 RDMA 的運作效能及靈活性 (例如，DRS / vSphere vMotion……等)，應該要採用 PVRDMA (Para-Virtual Remote Direct Memory Access) 機制才對。目前，必須符合下列相關條件才能順利運作 PVRDMA功能 (詳細資訊請參考官網資訊 VMware Docs - PVRDMA Support)：
  • 採用 vSphere ESXi 6.5 或 6.7 / vCenter Server 6.5 或 6.7。
  • 採用 vDS (vSphere Distributed Switch)。
  • VM 虛擬主機必須採用 Virtual Hardware Version 13 或 14。

此外，當 VM 虛擬主機採用 vRDMA 機制時，在資料傳輸上大約會有下列圖解 3 種情境：
  • Memcpy：當 VM 虛擬主機之間在「同一台」ESXi Host 時。
  • RDMA：當 VM 虛擬主機之間跨越「不同台」ESXi Host 時。
  • TCP：當 VM 虛擬主機之間跨越「不同台」ESXi Host，且其中一台 ESXi Host 未安裝支援 RDMA 介面卡時。
圖、vRDMA 資料傳輸情境
圖片來源：  vSphere 6.7 Core Storage - RDMA support in vSphere





支援 iSER

在新版 vSphere 6.7 運作環境中，除了全面支援 RDMA (InfiniBand / iWARP / RoCE) 之外，還新增支援 iSER (iSCSI Extension for RDMA)機制。

簡單來說，透過整合 RDMA 的 iSER 機制，可以讓 iSCSI 傳輸作業從傳統的 TCP Transport Protocol改為 RDMA Transport，進而降低 ESXi Host 的 CPU 工作負載，同時還能支援全面的 iSCSI 管理功能，例如，Discovery、Naming、Security、Error-Recovery、Boot……等。

圖、iSER 運作架構示意圖
圖片來源： vSphere 6.7 Core Storage - iSER (iSCSI Extensions for RDMA) support in vSphere

圖、iSER 將的建立 2 個邏輯裝置 (vmnic / vmrdma)
圖片來源： vSphere 6.7 Core Storage - iSER (iSCSI Extensions for RDMA) support in vSphere





vSAN 6.7 是否支援 RDMA？

雖然，在新版 vSphere 6.7 運作環境中已經全面支援 RDMA。但是，在 VMware vSAN 6.7 Release Notes當中，並沒有看任何支援 RDMA 技術的相關說明？ 倘若，有前輩或朋友知道相關資訊的話，還煩請不吝指導。 👴





參考資源






VMware vSphere 6.7 攻略 - 系列文章

↧

[站長著作] 微軟 S2D 軟體定義儲存技術實戰 (博客來限時特價 299 元)

May 28, 2018, 7:01 am
$
0
0

[博客來 - 限時特價 299 元]

即日起至 2018 年 7 月 11 日止，博客來針對本書推出特價活動 (1 本才 299 元)，有興趣的朋友可以參考看看。 💪




書籍簡介

還在為了規劃儲存設備規模大小而苦惱嗎？

實作微軟 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 現代化資料中心示意圖
圖片來源： Gartner 官網 – Data Center Modernization and Consolidation Key Initiative Overview



第 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 儲存效能
圖片來源： Channel 9 – DiscoverStorage Spaces Direct, the ultimate software-defined storage for Hyper-V（BRK3088）



第 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 儲存架構資料快取示意圖
圖片來源： Microsoft Docs – Understanding the cache in Storage Spaces Direct



第 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 儲存架構配置示意圖
圖片來源： Microsoft Docs – Choosing drives for Storage Spaces Direct



第 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 叢集仍然能夠正常運作資料仍可持續存取
圖片來源： Microsoft Docs - Fault tolerance and storage efficiency in Storage Spaces Direct



附錄、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 軟體定義儲存技術硬體伺服器清單
圖片來源： Channel 9 – Discover Storage Spaces Direct, the ultimate software-defined storage for Hyper-V (BRK3088)
↧
↧

[站長開講] Microsoft S2D - HCI 超融合規劃與建置實務班

May 28, 2018, 7:11 am
$
0
0

課程簡介

還在為了規劃儲存設備規模大小而苦惱嗎？

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







課程資訊

日期： 2018/06/23 ~ 2018/08/11 (每週六)
時間： 09:00 ~ 12:00、13:30 ~ 16:30
地點：國立臺北商業大學 (臺北市中正區濟南路一段321號)
網址： Microsoft S2D - HCI 超融合規劃與建置實務班




↧

Windows Server Summit 2018

June 3, 2018, 8:17 pm
$
0
0

前言

IT Pro 們，是不是覺得目前的各種 IT 研討會大部分都只與開發相關，而很少在談基礎架構及底層的 Windows Server？ 今年是 Windows Server 在市場上的第 25 年，微軟預計在今年底推出 Windows Server 2019，在此之前你可以參加這場線上會議 Windows Server Summit 2018，以便多了解相關資訊。






Windows Server Summit 2018 議程

你可以到 Windows Server Summit 2018網站上註冊，以便屆時可以參加這場線上會議。在這場線上會議中，將會有下列 4 種不同的 Track 可供選擇：

  • Hybrid：介紹如何在 Azure 公有雲環境中運作 Windows Server，同時展示如何透過 Azure 服務來管理公有雲環境，以及地端的 Windows Server 工作負載。
  • Security： 介紹許多新增及增強的安全性功能。
  • Application Platform：介紹 Windows Server 中新增功能，例如，針對容器平台的增強。以便充分支援在 Azure 公有雲環境及地端資料中心，順利運作現代化應用程式。
  • Hyper-Converged Infrastructure：在屆時新推出的 Windows Server 2019，將會再增強 Windows Server 2016 S2D 的管理體驗。







參考資源

↧

[站長開講] Microsoft Azure IaaS 實戰班

May 3, 2018, 2:30 am
$
0
0

活動資訊

日期： 2018 年 6 月 9 日 ~ 6 月 10 日
時間： 09:00 ~ 17:00
地點：資策會 (台中市南屯區公益路二段51號20樓)
報名：資策會課程 - Microsoft Azure IaaS 實戰班







課程大綱

Microsoft Azure 簡介
  • 全球資料中心
  • Portal 入口網站
  • 帳戶權限 & RBAC 委派管理
Microsoft Azure IaaS - 虛擬主機 (Virtual Machine)
  • 建立 VM 虛擬主機
  • 建立高可用性及負載平衡的 VM 
  • 建立 Windows / Linux VM (Depot) 虛擬主機
  • 上傳自行客製化的 VHD 檔進行部署
Microsoft Azure IaaS - 儲存體 (Blob Storage)
  • Page Blob / Block Blob
  • File 
  • Table
  • Queue
Microsoft Azure IaaS - 虛擬網路 (Virtual Network)
  • Site to Site VPN 及 Point to Site VPN
  • ExpressRoute
  • Traffic Manager
Microsoft Azure IaaS - 目錄服務 (Active Directory)
Microsoft Azure Backup 雲端備份
Microsoft Azure Site Recovery 雲端異地備援
↧
Search

[站長開講] Kubernetes Summit 2018

June 7, 2018, 7:23 am
$
0
0

活動簡介

隨著全球重要的雲端業者和虛擬化廠商全都支持之後，Kubernetes 已經變成新的基礎架構標準，一場兼具深度與廣度的 Kubernetes Summit 更是台灣跟上國際腳步的必須場域。


AWS

AWS 在 2017 AWS re:Invent 中正式推出 Kubernetes 代管服務 AKS。據雲端原生運算基金會 2017 年調查統計，全球有 63％ 的 Kubernetes 工作負載部署在 AWS 上。

Microsoft

微軟在 Azure 上釋出容器服務 AKS，除了能在公雲執行調度任務，也可以靠 Azure Stack 在私有環境執行容器調度。

Google

一手催生 Kubernetes 的 Google，在容器引擎 GKE 的升級速度搶先群雄，除了能最快速支援新版 Kubernetes，還能整合 GCP 上的大數據分析工具。

IBM

向來主攻企業應用市場的 IBM，將 Kubernetes 視作次世代的 PaaS 平臺，同步在自家公有、私有容器雲平臺支援。

VMware

VMware 在 2017 年 VMworld 上跨出關鍵一步，正式押寶 Kubernetes，與 Pivotal 及 Google 聯手推出 Pivotal 容器服務，與自家 SDDC 架構結合。

Red Hat

紅帽以 PaaS 平臺 OpenShift 為核心，將其定位為企業級 Kubernetes 平臺。

Oracle

甲骨文在 2017 年急起直追，鎖定容器原生應用程式開發平臺、擁抱開源新技術。

Dell

Dell 在 2017 年 3 月成為 CNCF 白金會員，也與社群密切合作，想要加強 Kubernetes 對於外部儲存設備的支援。

CISCO

思科除了是 CNCF 白金會員，也開始與 Google 結盟，讓思科私有雲環境可以介接 Google 公有雲環境使用 Kubernetes。





活動資訊

  • 日期： 2018 年 6 月 14 日 (星期四)
  • 時間： 9:00 ~ 17:00
  • 地點： 台大醫院國際會議中心 4 樓 (台北市中正區徐州路 2 號 4 樓)
  • 報名： 活動報名





活動內容

活動首頁、講者介紹、大會議程、站長議程 (OpenFaaS on Kubernetes - 1 分鐘建構好你的 Serverless 平台)。


↧
↧

149 期 - Docker Swarm 容器管理規畫部署一次傾囊相授

June 7, 2018, 6:28 pm
$
0
0

網管人雜誌

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





前言
Docker Swarm 是什麼？
          Docker Swarm 叢集運作架構
          Docker Swarm 叢集最佳建議作法
實戰 – Docker Swarm on Windows
          Windows Server 2016 安裝 Docker 環境
          建置 Docker Swarm 叢集
          加入其它 Docker Swarm 叢集節點主機
          轉換 Docker Swarm 節點主機角色
          部署 Docker Swarm 叢集服務
          支援 Routing Mesh 負載平衡機制
結語





前言

根據知名市調機構 RightScale，在最新一期的 2018 State of the Cloud Report調查報告中指出，目前在企業及組織當中使用的容器技術，主要是以 Docker 做為主要的容器管理技術，至於在容器「調度」（Orchestration）方面，則是以 K8S（Kubernetes）為首要同時 K8S 也是成長最快速的容器調度平台（如圖 1 所示）。
雖然 Docker 公司創辦人 Solomon 已經於 2018 年 3 月 28 日，在 Docker Blog中正式發佈離開 Docker 並辭去 CEO/CTO 職位的消息，但是並不影響 Docker 容器管理技術的發展。

圖 1、RightScale 市調統計結果，企業用於管理容器技術的優先順序
圖片來源： RightScale - 2018 State of the Cloud Report





Docker Swarm 是什麼？

簡單來說，當企業及組織的 IT 管理人員要使用容器技術時，只要透過 Docker 容器管理技術即可使用，然而隨著企業及組織使用容器的數量逐漸變多時，便需要有個能夠管理及調度眾多容器的平台，而 Docker Swarm就是 Docker 公司所推出原生的容器調度管理平台。

雖然，在目前市場上主流的容器調度平台為 Google 推出的 K8S（Kubernetes），但是 Docker Swarm 擁有 Docker 原生及組態設定較為簡單的優勢，所以在市場上的容器調度管理平台中仍佔有一席之地，下列便是 Docker Swarm 容器調度管理平台的特色功能：

  • 原生內建：從 Docker 1.12 版本之後，在 Docker Engine 中便直接原生內建 Docker Swarm Mode（免費使用的 Docker CE 社群版本也支援）。只要透過 Docker Engine CLI / API 即可建立及管理Docker Swarm 叢集，無須額外安裝及組態設定才能建立容器叢集。
  • 分散式設計：在小架構規模中可以在 1 台 Docker Host 上，同時運作 Docker Swarm Services 及 Standalone Container 角色。在中大型架構及規模當中，可以在 Docker Swarm 叢集中規劃 Manager / Worker 角色，即便運作環境中沒有共享儲存資源也沒有問題。
  • 宣告式服務模組：在 Docker Swarm 叢集運作架構中，Docker Engine 將會透過此方式來定義應用程式堆疊。
  • 容器規模縮放機制： 管理人員可以透過 Swarm Managers 管理機制，視容器的工作負載需求隨時調整容器的運作規模大小（增加或減少運作中的容器數量）。
  • 預期狀態調節：在 Docker Swarm 叢集運作架構中，將會透過 Docker Host 上的 Swarm Managers 管理機制，持續監控叢集的運作狀態並調度容器。舉例來說，在 Swarm Worker 角色中總共運作 10 個容器，但其中有 2 個容器因為 Swarm Worker 主機發生故障而停止服務，此時 Swarm Managers 管理機制，將會在其它「存活」的 Swarm Worker 主機上再啟動 2 個容器。
  • 跨主機網路環境：透過內建的 Docker Overlay Network 網路機制，在 Docker Swarm 叢集運作架構中，達成跨多台 Docker Host 主機互相溝通的網路機制。
  • 自動探索服務機制：在 Docker Swarm 叢集運作架構中，內建會為「每項服務」分配唯一的 Unique DNS Name，以便將使用者的服務請求工作負載平均分配至每個容器。管理人員也可以視工作負載需求，搭配外部負載平衡機制將服務請求工作負載平均分配給每個容器。
  • 預設啟用 TLS 安全機制：在預設情況下，每台 Docker Swarm 節點主機之間會採用 TLS 相互認證及加密（如圖 ２ 所示），管理人員也可以搭配 --external-ca 參數指定採用公開 Root CA 或自簽 CA 。同時，當 Docker Swarm 叢集初始化完成後，系統將會自動產生 Manager Token 及 Worker Token 以便後續新加入的 Docker Swarm 節點主機使用。值得注意的是，採用預設的 TLS 憑證將會「每3個月」更新憑證，管理人員可以透過參數「docker swarm update --cert-expiry <TIME PERIOD>」調整更新憑證的時間週期，或使用「swarm join-token --rotate」指令產生新的 Token，以避免 Token 洩漏產生安全性疑慮。
  • 滾動式更新：透過滾動式更新機制，管理人員可以輕鬆的更新容器映像檔版本，並且在發生問題時能夠恢復到先前運作良好的版本。

圖 2、Docker Swarm 叢集架構中 Manager / Worker 透過 TLS 加密機制通訊示意圖
圖片來源： Docker Documentation - Manage swarm security with public key infrastructure（PKI）



Docker Swarm 叢集運作架構

首先，在 Docker Swarm 容器叢集運作架構中，將有 ２ 種角色分別是「Manager」及「Worker」（如圖 ３ 所示），其中擔任 Manager角色的 Docker Swarm 節點主機，將會透過 Raft Consensus Algorithm 機制在節點主機之間互相通訊，同時負責維護 Orchestration Service、Cluster Management、Service Swarm Mode HTTP API Endpoints……等資源調度服務。
至於擔任 Worker角色的 Docker Swarm 節點主機，最主要的工作任務就是負責「運作容器」，而不會參與上述 Manager 角色所負責的資源調度工作任務。
管理人員，可以隨時透過「docker node promote」指令，將擔任 Worker 角色的 Docker Swarm 節點主機提升為 Manager 角色，或者透過「docker node demote」指令，將擔任 Manager 角色的 Docker Swarm 節點主機降級為 Worker 角色，或者讓 Docker Swarm 節點主機「同時」擔任 2 種角色。
值得注意的是，當企業及組織在規劃建置 Docker Swarm 容器叢集環境時，在 Docker Swarm 節點主機之間必須開啟相關防火牆連接埠及通訊協定（如下列所示），否則屆時 Docker Swarm 節點主機之間將因為無法順利通訊，導致 Docker Swarm 容器叢集環境發生不可預期的錯誤：

  • TCP Port 2377 ：用於 Docker Swarm 叢集管理服務。
  • UDP Port 4789 ：用於 Docker Swarm 叢集 Overlay Network 跨主機網路流量。
  • TCP/UDP Port 7946 ：用於 Docker Swarm 叢集節點主機互相通訊。
  • IP Protocol 50（ESP）：用於 Docker Swarm 叢集 Overlay Network 跨主機網路流量進行加密時使用。

圖 3、Docker Swarm 叢集運作架構示意圖
圖片來源： Docker Documentation - How nodes work



Docker Swarm 叢集最佳建議作法

那麼，當企業及組織的 IT 管理人員在規劃 Docker Swarm 叢集架構時該如何規劃呢？ 應該要多少台 Docker Swarm 節點主機擔任 Manager 及 Worker 角色呢？ 原則上，在 Docker Swarm 叢集架構中，對於 Manager 及 Worker 角色的 Docker Swarm 節點主機數量並沒有限制，那麼到底要建立多少台數量的 Docker Swarm 節點主機才是適當，便是我們接下來所要討論的重點。

首先，在 Docker Swarm 叢集運作架構中，因為擔任 Manager 角色的 Docker Swarm 節點主機，主要是透過 Raft 一致性演算法來管理 Docker Swarm 叢集運作狀態。因此，當新增的 Docker Swarm 節點主機加入 Docker Swarm 叢集時，或是有 Docker Swarm 節點主機退出 Docker Swarm 叢集時，所有擔任 Manager 角色的 Docker Swarm 節點主機，便需要執行同步、確認、更新、複寫……等 Docker Swarm 叢集運作狀態的工作任務。

但是，當擔任 Manager 角色的 Docker Swarm 節點主機數量「過少」時，有可能因為 Manager 主機故障損壞，進而導致 Docker Swarm 叢集崩潰，然而 Manager 角色 Docker Swarm 節點主機數量「過多」時，則會因為叢集維運工作任務的往返網路流量過大而導致同步及更新狀態的寫入效能降低。
在 Docker Swarm 叢集架構中，即便所有 Manager 角色主機全數故障損壞無法運作，仍然不影響在 Worker 角色主機上運作的容器。但是，整個 Docker Swarm 叢集將無法進行新增 / 更新 / 移除……等維運及資源調度的工作任務。
簡單來說，在 Docker 官方的最佳建議作法當中，擔任 Manager 角色的 Docker Swarm 節點主機數量應為「奇數」，最主要是考量 Docker Swarm 叢集中「仲裁」（Quorum）及「容錯」（Fault Tolerance）機制。

因此，整個 Docker Swarm 叢集的最佳建議作法中，最小規模應建置「3 台」擔任 Manager 角色的 Docker Swarm 節點主機，此時可以容許「1 台」Manager 角色主機發生故障損壞事件，並且不影響 Docker Swarm 叢集的運作（如圖 ４ 所示）。

同理，倘若 Docker Swarm 叢集中，建置「5 台」擔任 Manager 角色的 Docker Swarm 節點主機時，將能容許「2 台」Manager 角色主機發生故障且不影響 Docker Swarm 叢集的運作。
倘若建置「偶數」Manager 角色主機，則容錯數量則與奇數主機相同。舉例來說，建置「4 台」Manager 角色主機，仍只能允許「1 台」Manager 角色主機發生故障，建置「6 台」仍只能允許「2 台」Manager 角色主機發生故障。
圖 4、Docker Swarm 叢集 Manager 角色節點主機數量建議表
圖片來源： Docker Documentation - Administer and maintain a swarm of Docker Engines



實戰 – Docker Swarm on Windows

在本文實作環境中，我們將準備「3 台」Windows Server 2016 主機，在下載及安裝 Docker 容器環境後，接著建置 Docker Swarm 叢集環境，而這 3 台 Windows Server 2016 Docker 主機，將會「同時擔任」Docker Swarm 叢集環境中 Manager 及 Worker 角色。這 3 台主機的基礎設定資訊如下：

 主機名稱
IP 位址
Docker Swarm 角色
SwarmHost01
10.10.75.21
Manager / Worker
SwarmHost02
10.10.75.22
Manager / Worker
SwarmHost03
10.10.75.23
Manager / Worker



Windows Server 2016 安裝 Docker 環境

管理人員只要透過 OneGet Provider 機制，即可輕鬆安裝 PowerShell 中的 Docker 模組，順利讓 Windows Server 2016 主機運作 Docker 容器環境。

請開啟 PowerShell 指令視窗，依序鍵入「Install-Module -Name DockerMsftProvider -Repository PSGallery -Force」、「Install-Package -Name docker -ProviderName DockerMsftProvider -Force」指令後，最後鍵入「Restart-Computer -Force」指令重新啟動Windows Server 2016主機。
有關 Windows Server 2016 安裝 Docker 容器環境的詳細資訊，請參考本刊《第 139 期-共用系統核心資源，玩轉 Windows Server 容器》。
待 3 台 Windows Server 2016 主機重新啟動後，確認是否已經順利運作 Docker 環境，請在 PowerShell 指令視窗中執行「docker version」指令，可以看到在本文實作環境中所安裝的 Docker引擎及 Docker 用戶端版本為「17.06.2-ee-7」（如圖 ５ 所示）。

圖 5、確認 Windows Server 2016 主機 Docker 運作環境版本資訊



建置 Docker Swarm 叢集

順利為 3 台 Windows Server 2016 安裝好 Docker 運作環境後，在開始建置 Docker Swarm 叢集之前，請確保 3 台 Windowsd Server 2016 主機，已經開啟好 Docker Swarm 叢集相關防火牆連接埠，管理人員可以透過 PowerShell 指令，「New-NetFirewallRule -DisplayName 'Docker Swarm' -Profile @（'Domain'，'Private'，'Public'）-Direction Inbound -Action Allow -Protocol TCP -LocalPort @（'2377'，'7946'）」及「New-NetFirewallRule -DisplayName 'Docker Swarm' -Profile @（'Domain'，'Private'，'Public'）-Direction Inbound -Action Allow -Protocol UDP -LocalPort @（'4789'，'7946'）」，快速開啟相關防火牆連接埠（如圖 ６ 所示）。

圖 6、透過 PowerShell 開啟 Docker Swarm 叢集相關防火牆連接埠

由於在本文實作環境中，並沒有建置 DNS 名稱解析伺服器，所以請修改 3 台 Docker Swarm 節點主機的 hosts 名稱解析設定檔，檔案路徑為「C:\Windows\System32\drivers\etc\hosts」，在 hosts 名稱解析設定檔內容中加上 3 筆 Docker Swarm 節點主機解析記錄。完成組態設定修改的動作後，請執行 ping 指令確認 DNS 名稱解析動作正確無誤（如圖 ７ 所示）。

圖 7、組態設定 3 台 Docker Swarm 節點主機的 hosts 名稱解析設定檔

在本文實作環境中，我們將採用「SwarmHost01（10.10.75.21）」主機，當成 Docker Swarm 叢集中「第 1 台」初始化的 Docker Swarm 節點主機。請在 PowerShell 指令視窗中，鍵入「docker swarm init --advertise-addr=10.10.75.21 --listen-addr 10.10.75.21:2377」指令，讓 SwarmHost01 主機執行 Docker Swarm 叢集初始化工作任務。

當 Docker Swarm 叢集初始化的動作完成後，可以執行「docker node ls」指令進行確認，可以看到目前在 Docker Swarm 叢集中只有 1 台主機，也就是剛才執行初始化動作的 SwarmHost01 主機（如圖 ８ 所示）。
管理人員也可以執行「docker info」指令，查看有關 Docker Swarm 叢集相關運作資訊。
圖 8、SwarmHost01 主機執行 Docker Swarm 叢集初始化工作任務

此時，我們可以觀察到 SwarmHost01 主機，在建立 Docker Swarm 叢集之後主機發生哪些變化。在主機網路方面，將會看到 SwarmHost01 主機原本的「實體網路卡」，也就是剛才指定 10.10.75.21 IP 位址的網路卡，將會轉變成「HNSTransparent」，並且在 Docker 網路環境中將會產生名稱為「ingress」的「overlay」網路（如圖 ９ 所示）。
此時，管理人員使用「netstat -na」指令，將會發現 SwarmHost01 主機開始使用 Docker Swarm 叢集相關連接埠，例如，Port 2377，7946。
圖 9、Docker Swarm 叢集初始化完成後 SwarmHost01 主機運作環境的轉變



加入其它 Docker Swarm 叢集節點主機

當 SwarmHost01 執行初始化作業順利建立 Docker Swarm 叢集之後，管理人員應該有發現系統回應後續加入 Docker Swarm 叢集節點主機所使用的「Token」。

預設情況下，Docker Swarm 叢集僅會顯示「Worker 角色」所使用的 Token，而不會顯示 Manager 角色所要加入 Docker Swarm 叢集時的 Token 。同時，管理人員倘若忘記將剛才加入的 Token 記錄下來時，也都可以隨時使用 Docker 指令重新顯示 Manager/Worker 角色所使用的 Token。

請在 PowerShell 指令視窗中，執行「docker swarm join-token worker」指令即可顯示，Docker Swarm 節點主機所要加入 Docker Swarm 叢集時，擔任 Worker 角色所使用的指令以及 Token，而執行「docker swarm join-token manager」指令，則是顯示擔任 Manager 角色所使用的指令以及 Token（如圖 10 所示）。
倘若，只希望系統回應使用的 Token 內容而非完整指令時，只要在執行指令結尾加上「--quiet」參數即可。
圖 10、顯示 Docker Swarm 節點主機加入 Docker Swarm 叢集時使用的 Token

在本文實作環境中，整個 Docker Swarm 叢集只有 3 台 Docker Swarm 節點主機，為了確保 Docker Swarm 叢集運作的穩定性，所以另外 2 台加入叢集的 Docker Swarm 節點主機，也會擔任 Manager 的角色。

請登入另外 2 台 Docker Swarm 節點主機（本文實作環境為 SwarmHost02、SwarmHost03），執行加入 Docker Swarm 叢集且擔任 Manager 角色的指令，當 Docker Swarm 節點主機順利加入 Docker Swarm 叢集時，系統將會顯示「This node joined a swarm as a manager」資訊。
倘若，系統顯示「Error response from daemon ：Timeout was reached before node was joined.」訊息，請再次確認 Docker Swarm 節點主機的防火牆規則是否已經開啟。
此時，我們可以再次執行「docker node ls」指令，查看目前 Docker Swarm 叢集的節點主機資訊，可以看到目前的 Docker Swarm 叢集中共有 3 台主機，至於 HOSTNAME 欄位前顯示「*」，表示目前執行 Docker 指令的所在主機（如圖 11 所示）。

圖 11、將另外 2 台 Docker Swarm 節點主機加入 Docker Swarm 叢集中



轉換 Docker Swarm 節點主機角色

在前述說明 Docker Swarm 容器叢集運作架構時，我們已經說明叢集中有 2 種角色分別是「Manager」及「Worker」。當 Docker Swarm 節點主機加入 Docker Swarm 叢集後，倘若管理人員需要調整 Docker Swarm 節點主機角色時，可以在擔任「Manager」角色的 Docker Swarm 節點主機上，執行 Docker 指令「docker node promote/demote」，即可轉換 Docker Swarm 節點主機的角色。

如圖 12 所示，我們登入 SwarmHost03 主機執行「docker node ls」指令，可以看到目前 3 台 Docker Swarm 節點主機皆為 Manager 角色，接著執行「docker node demote SwarmHost02」指令，將 SwarmHost02 主機角色降級為 Worker 角色，然後再執行「docker node promote SwarmHost02」指令，將 SwarmHost02 主機角色再次升級為 Manager 角色。

圖 12、轉換 Docker Swarm 節點主機的叢集角色



部署 Docker Swarm 叢集服務

至此，我們已經順利建置好 Docker Swarm 叢集運作環境，接下來便可以進行部署「服務」（Services）的動作。值得注意的是，在「單機」的 Docker 容器運作環境中，管理人員可以透過「docker run」指令來建立容器，然而在 Docker Swarm 叢集環境中則必須執行「docker service create」指令，那麼建立的容器才會順利部署至 Docker Swarm 叢集高可用性環境中（如圖 13 所示）。

圖 13、Docker Swarm 叢集部署容器服務運作流程示意圖
圖片來源： Docker Documentation - How services work

了解 Docker Swarm 叢集部署容器服務運作流程後，管理人員也必須了解 Docker Swarm 叢集運作的幾個技術名詞，分別是「服務」（Services）、「任務」（Tasks）、「容器」（Containers）代表的意義為何。

首先，當管理人員執行「docker service create」指令後，會在 Docker Swarm 叢集中建立「容器服務」，接著依據 Docker 指令所設定的「複本」（Replica）數量，決定要在 Docker Swarm 叢集中建立多少的「任務及容器」（如圖 14 所示）。

圖 14、Docker Swarm 叢集服務，任務，容器運作示意圖
圖片來源： Docker Documentation - How services work

請在 Docker Swarm 叢集中任意 1 台 Manager 角色主機上，執行「docker service create --name=iis --replicas 3 --publish mode=host,published=80,target=80 --endpoint-mode dnsrr -d microsoft/iis」指令部署 IIS 容器服務（如圖 15 所示），此行 Docker 指令相關參數意義如下：

  • --name=iis：指定此 Docker Swarm 叢集服務名稱為 iis 。
  • --replicas 3：指定此 Docker Swarm 叢集服務任務數量為 3，因此將會建立總數為 3 個的 IIS 容器，本文實作環境中共 3 台 Docker Swarm 節點主機，所以屆時每台主機上將會運作 1 個 IIS 容器。
  • --publish mode=host,published=80,target=80：指定運作後的 IIS 容器及 Docker Swarm 節點主機，互相對應的連接埠關係，本文實作環境中將會採用主機的 Port 80 對應到 IIS 容器的 Port 80 。
  • --endpoint-mode dnsrr：採用 DNS Round Robin 負載平衡機制，處理 IIS 容器的網路流量。
  • -d microsoft/iis：下載完 microsoft/iis 容器映像檔後，採用背景執行的方式運作 IIS 容器。

圖 15、在 Docker Swarm 叢集中部署 IIS 容器服務

此時，在使用者端開啟瀏覽器後，不管是連接到哪一台 SwarmHost 主機的 IP 位址，都會重新導向至內部運作的 IIS 容器網頁服務當中。同時，由於 IIS 容器服務是部署至高可用性的 Docker Swarm 叢集中，因此當 IIS 容器因為任何因素而停止運作時（本文實作環境，由管理人員手動執行指令直接停止其中 1 個 IIS 容器），那麼 Docker Swarm 叢集也會「自動」再次產生新的 IIS 容器（如圖 16 所示）。

圖 16、Docker Swarm 叢集高可用性機制，偵測有 IIS 容器停止運作後自動產生新的 IIS 容器

此外，倘若考量 IIS 容器工作負載的關係，管理人員需要擴充或縮減運作的 IIS 容器數量時，那麼透過 Docker Swarm 叢集運作機制也是非常容易達成的。管理人員只要執行「docker service scale < 服務名稱及複本數量 >」指令，舉例來說，在本文實作環境中執行「docker service scale iis=1」指令後，那麼 IIS 容器數量將由一開始部署的「3 個」IIS 容器縮減為「1 個」IIS 容器（如圖 17 所示）。

圖 17、透過 Docker Swarm 叢集線上擴充或縮減運作的 IIS 容器數量



支援 Routing Mesh 負載平衡機制

熟悉 Docker Swarm 叢集運作架構的管理人員可能會有個疑問，在 Windows Server 2016 RTM（版本 1609）中所建立的 Docker Swarm 叢集環境，似乎無法順利使用 Docker Swarm 內建的「Routing Mesh 負載平衡」機制 ？

是的，在 Windows Server 2016 RTM（版本 1609）中所建立的 Docker Swarm 叢集環境，目前僅支援採用「DNS Round Robin 負載平衡」機制，必須採用「Windows Server 2016（版本 1709）」建立的 Docker Swarm 叢集環境，才能夠支援 Docker Swarm 內建的「Routing Mesh 負載平衡」機制（如圖 18 所示）。詳細資訊請參考微軟官方部落格文章內容 Virtualization Blog - Docker routing mesh available with Windows Server version 1709。

圖 18、Docker Swarm on Windows Server 支援 Routing Mesh 負載平衡機制示意圖
圖片來源： Virtualization Blog - Docker routing mesh available with Windows Server version 1709





結語

透過本文的說明及實作練習，管理人員應該能夠感受到透過 Windows Server 2016 所建構的 Docker Swarm 叢集環境，能夠很容易的在 Windows Server 容器環境中，線上擴充或縮減容器的運作規模，同時在容器因為任何因素而停止運作時，Docker Swarm 叢集將會自動產生新的容器，確保容器所提供服務具備高可用性，以幫助企業及組織降低維運成本，同時也能降低資料中心維運人員的管理負擔。
↧

Windows Server 2016 安裝 Minikube

June 11, 2018, 11:08 pm
$
0
0

文章目錄

前言
建立支援 Nested Virtualization 的 VM 虛擬主機
          基礎設定 - 調整時區為 UTC +8
          基礎設定 - 關閉 IE ESC 安全性設定
          安裝 Hyper-V 及相關管理工具
          建立 Hyper-V NAT vSwitch
          安裝及組態設定 DHCP Server
透過 PowerShell PSGallery 機制安裝 kubectl
安裝 Minikube
建立 Minikube VM (Kubernetes Cluster)
          Kubernetes Cluster 運作環境
          Kubernetes Dashboard
          建立第 1 個 Pod 和 hello-minikube 容器
          登入 Minikube VM
          刪除測試用途的 Pod 及容器
          刪除 Minikube VM
參考資源







前言

簡單來說，在學習/測試/研發環境中，我們可以透過「單台」主機結合 Minikube機制，即可輕鬆快速的建立 Kubernetes Cluster運作環境。本文中，所有的 PowerShell 指令請參考 GitHub Weithenn/powershell - minikube_on_ws2016.ps1。

本文，將實作在 Windows Server 2016運作環境中安裝 Minikube，當然這台 Windows Server 2016 主機可以在「地端」也可以在「雲端」環境中。值得注意的是，這台 Windows Server 2016 主機必須要支援「巢狀式虛擬化技術」(Nested Virtualization)，屆時才能順利建立 Minikube 運作環境。

有關地端 Windows Server 2016 主機啟用 Nested Virtualization 機制的詳細資訊，請參考站內文章 網管人雜誌 133 期 - 實作 Hyper-V 巢狀虛擬化測試研發效率大提升。

圖、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖
圖片來源： Virtualization Blog - Windows Insider Preview： Nested Virtualization

有關 Microsoft Azure 雲端 Windows Server 2016 主機啟用 Nested Virtualization 機制的詳細資訊，請參考站內文章 ASDK Journey (2) - 實戰 Azure Stack Development Kit on Azure。當然，倘若考慮整體執行效能及穩定性和完整性，你可以直接使用 Microsoft Azure 的 AKS (Azure Kubernetes Service)服務，以便快速建立 Kubernetes Cluster 運作環境 (但是燒錢也更快速 😝)。

圖、Nested Virtualization in Azure
圖片來源： Nested Virtualization in Azure | Blog | Microsoft Azure





建立支援 Nested Virtualization 的 VM 虛擬主機

在 Microsoft Azure 雲端環境中，需要支援 Windows Server 2016 主機啟用 Nested Virtualization 機制時，請記得選擇的 VM 虛擬主機必須是「Dv3 或 Ev3」系列才行。舉例來說，本文採用 D8s v3系列的 VM 虛擬主機。

圖、建立 D8s v3 系列的 VM 虛擬主機



基礎設定 - 調整時區為 UTC +8

預設情況下，在 Microsoft Azure 雲端環境建立的 VM 虛擬主機時區為格林威治時間，可以透過下列 PowerShell 指令，將 Windows Server 2016 主機的時區調整為台灣的「UTC + 8」。
Set-TimeZone -Name "Taipei Standard Time"
Get-TimeZone
圖、調整 Windows Server 2016 主機的時區調整為台灣的 UTC + 8



基礎設定 - 關閉 IE ESC 安全性設定

預設情況下，Windows Server 2016 主機將會啟用 IE ESC 安全性設定，可以透過下列 PowerShell 指令，將 Windows Server 2016 主機的 Administrators管理者群組 IE ESC 安全性設定關閉 (Off)，以方便稍後可以順利開啟 Kubernetes Dashboard 頁面。
$AdminIEOff = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}"
Set-ItemProperty -Path $AdminIEOff -Name "IsInstalled" -Value 0
Stop-Process -Name Explorer
圖、關閉 Administrators 管理者群組的 IE ESC 安全性設定



安裝 Hyper-V 及相關管理工具

接著，請透過下列 PowerShell 指令，幫 Windows Server 2016 主機安裝 Hyper-V及相關管理工具 (當然，你要透過 Server Manager 安裝也行)，安裝完畢將會重新啟動主機。
Add-WindowsFeature Hyper-V -IncludeManagementTools -Restart
圖、安裝 Hyper-V 及相關管理工具



建立 Hyper-V NAT vSwitch

請透過下列 PowerShell 指令，在 Azure VM 中建立 NAT vSwitch，以便屆時 Minikube VM 環境能夠出 Internet (因為 Azure VM 的上層是 Azure 無法用 MAC Address Spoofing機制來處理)。下列 PowerShell 執行後，將會建立的 NAT 網段為 10.10.75.0/24 至於 Gateway IP則是 10.10.75.1。
New-VMSwitch -Name "Minikube-NATSwitch" -SwitchType Internal
New-NetNat -Name "Minikube-ContainerNAT" -InternalIPInterfaceAddressPrefix "10.10.75.0/24"
Get-NetAdapter "vEthernet (Minikube-NATSwitch)" | New-NetIPAddress -IPAddress 10.10.75.1 -AddressFamily IPv4 -PrefixLength 24
圖、在 Hyper-V 環境中建立 NAT vSwitch

圖、在 Hyper-V 環境中建立 NAT vSwitch

圖、在 Hyper-V 環境中建立 NAT vSwitch



安裝及組態設定 DHCP Server

雖然，我們已經在 Hyper-V 環境中建立 NAT vSwitch，但是屆時的 Minikube VM 預設會透過 DHCP Client 機制取得 IP 位址，當 Minikube VM 所處的運作環境沒有 DHCP Server 時，屆時 Minikube VM將會運作失敗。

然而，剛才建立的 NAT vSwitch 雖然可以處理 Minikube VM 連接網際網路的需求，但是必須要「手動」指派固定 IP 位址才行，這樣會卡住 Minikube VM 的運作流程。所以，還是在 Hyper-V 主機上啟用 DHCP Server 比較快。詳細資訊請參考官網文章 DHCP Server Cmdlets in Windows PowerShell。

在下列的 PowerShell 指令中，將會安裝 DHCP Server 並且進行下列組態設定：
  • DHCP IP Range： 10.10.75.51 ~ 200
  • Gateway： 10.10.75.1
  • DNS： 8.8.8.8
Install-WindowsFeature DHCP -IncludeManagementTools
Add-DhcpServerV4Scope -Name "Minikube-Lab" -StartRange 10.10.75.51 -EndRange 10.10.75.200 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -DnsServer 8.8.8.8 -Router 10.10.75.1 -ScopeId 10.10.75.0
Get-DhcpServerV4Scope
Restart-service dhcpserver
圖、安裝及組態設定 DHCP Server

圖、查看 DHCP Server 組態設定





透過 PowerShell PSGallery 機制安裝 kubectl

在 Windows Server 2016 運作環境中，我們可以很容易透過 PowerShell PSGallery機制安裝 kubectl。詳細資訊請參考官網文章 Install and Set Up kubectl - Kubernetes。

在下列的 PowerShell 指令中，將會安裝 kubectl 並將 kubectl.exe 執行檔下載於 C:\tmp 資料夾內：
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 -DownloadLocation C:\tmp
圖、透過 PowerShell PSGallery 機制安裝 kubectl

為了後續執行 kubectl 指令的方便性，我們可以將 kubectl.exe複製到系統預設的環境變數路徑「C:\Windows\system32」資料夾下即可。
Copy-Item "C:\tmp\kubectl.exe" -Destination "C:\Windows\System32\"
圖、將 kubectl.exe 複製到系統預設的環境變數路徑

此時，便可以執行「kubectl version」指令，確認採用的 kubectl 指令版本資訊。從指令結果可以看到，目前只會顯示 Client 版本 (因為 Server 部分尚未建立，所以無法順利顯示)。

圖、確認採用的 kubectl 指令版本資訊





安裝 Minikube

最新版本的 Minikube 請參考 Releases · kubernetes/minikube，本文實作時最新版本為 Minikube v0.27.0，倘若手動下載的話請將下載後的 minikube-windows-amd64.exe改名為 minikube.exe，同樣的為了後續執行 minikube 指令的方便性，也請複製 minikube.exe到系統預設的環境變數路徑「C:\Windows\system32」資料夾下，然後便可以執行「minikube version」指令，確認採用的 minikube 版本資訊。詳細資訊請參考官網文章 Install Minikube - Kubernetes。
Invoke-WebRequest -Uri https://storage.googleapis.com/minikube/releases/v0.27.0/minikube-windows-amd64.exe -OutFile "C:\tmp\minikube.exe"
Copy-Item "C:\tmp\minikube.exe" -Destination "C:\Windows\System32\"
minikube version
圖、安裝及確認 Minikube 版本





建立 Minikube VM (Kubernetes Cluster)

環境準備完畢後，便可以執行下列 PowerShell 指令，執行建立 Minikube VM也就是建構「單機 Kubernetes Cluster」運作環境的動作。值得注意的是，我依據使用的 Windows Server 2016 資源情況，調整 Minikube VM 的硬體資源配置為「4 vCPU、16 GB vRAM、50 GB vHDD」，倘若未調整的話預設硬體資源配置為「2 vCPU、2 GB vRAM、20 GB vHDD」。
Get-VMSwitch
minikube start --cpus=4 --memory=16384 --disk-size=50g --vm-driver="hyperv" --hyperv-virtual-switch="Minikube-NATSwitch"
圖、建立 Minikube VM

順利在 Windows Server 2016 的 Nested Virtualization 環境中建立 Minikube VM之後，可以看到 Minikube VM 開機後取得我們剛才所配發的 DHCP IP「10.10.75.51」，並且著手建立 Kubernetes Cluster 環境中。

圖、Minikube VM 順利取得 DHCP IP

圖、Minikube VM 順利取得 DHCP IP

在本文實作環境中，建立 Minikube VM 後約「3分鐘」便初始化完成並建立好 單機 Kubernetes Cluster 環境。

圖、順利建立單機 Kubernetes Cluster 環境

事實上，在建立 Minikube VM 及單機 Kubernetes Cluster 環境的過程中，系統會自動在「C:\Users\Weithenn\.minikube」路徑中建立相關資料夾目錄結構，例如，存放建立 Minikube VM 的 ISO 映像檔、Kubernetes Cluster 使用的憑證檔案……等。

圖、查看 Minikube 組態設定資料夾結構


此外，在「C:\Users\Weithenn\.kube」路徑中也會產生「config」組態設定檔，便是指定單機 Kubernetes Cluster 環境資訊。

圖、產生單機 Kubernetes Cluster 環境組態設定檔



Kubernetes Cluster 運作環境

現在，可以分別執行「kubectl version」、「kubectl cluster-info」、「kubectl get nodes」、「kubectl get namespaces」指令，確認 Kubernetes Cluster 運作環境資訊。

圖、確認 Kubernetes Cluster 運作環境資訊



Kubernetes Dashboard

現在，也可以執行「minikube status」、「minikube service list」確認 Kubernetes Cluster 運作環境資訊，確認 Kubernetes Dashboard 服務運作後，便可以執行「minikube dashboard」指令，系統便會自動開啟預設的瀏覽器連接至 Kubernetes Dashboard 頁面。

圖、連接至 Kubernetes Dashboard 頁面



建立第 1 個 Pod 和 hello-minikube 容器

確認 Kubernetes Cluster 運作環境正確無誤後，便可以著手測試「部署」(Deployment) 第 1 個測試用途的 Pod 及容器，然後透過 Expose機制把 Pod 及容器對應至外部網路，之後可以開啟瀏覽器或使用 curl 指令確認是否正確運作。
kubectl run hello-minikube --image=gcr.io/google_containers/echoserver:1.4 --port=8080
kubectl expose deployment hello-minikube --type=NodePort
Kubectl get pods
minikube service list
curl $(minikube service hello-minikube --url)
圖、建立第 1 個 Pod 和容器



登入 Minikube VM

管理人員可以使用「minikube ip」指令，確認 Minikube VM 所使用的 IP 位址，以及使用「minikube docker-env」指令，了解 Minikube VM 使用的容器環境資訊。甚至想要登入 Minikube VM 的話，只要執行「minikube ssh」即可 (離開請使用 exit 指令)，登入 Minikube VM 後，可以看到剛才部署的 hello-minikube 容器資訊。

圖、登入 Minikube VM



刪除測試用途的 Pod 及容器

測試完畢後，便可以分別執行「kubectl get deployment」、「kubectl delete deployment hello-minikube」、「kubectl get pods」指令，將剛才測試用途的 Pod 及容器刪除。

圖、刪除測試用途的 Pod 及容器



刪除 Minikube VM

倘若，需要刪除 Minikube VM (單機 Kubernetes Cluster) 運作環境的話，那麼可以先執行「minikube stop」指令，即可將 Minikube VM 進行關機的動作，然後執行「minikube delete」指令即可刪除 Minikube VM。當然，若要徹底清除運作環境的話，建議將「C:\Users\Weithenn\.minikube」、「C:\Users\Weithenn\.kube\config」也刪除。

圖、關閉 Minikube VM

圖、刪除 Minikube VM





參考資源

↧

CentOS 7.5 安裝 Minikube

June 26, 2018, 11:35 pm
$
0
0

文章目錄

前言
建立支援 Nested Virtualization 的 CentOS 7.5 虛擬主機
          基礎設定
安裝 Kubectl
安裝 KVM2
安裝 Minikube
          Kubernetes Dashboard
          建立第 1 個 Pod 和 hello-minikube 容器
          登入 Minikube VM
          刪除測試用途的 Pod 及容器
          刪除 Minikube VM
參考資源






前言

簡單來說，在學習/測試/研發環境中，我們可以透過「單台」主機結合 Minikube機制，即可輕鬆快速的建立 Kubernetes Cluster運作環境。

本文，將實作在 CentOS 7.5 運作環境中安裝 Minikube，當然這台 CentOS 7.5 主機可以在「地端」也可以在「雲端」環境中。值得注意的是，這台 CentOS 7.5 主機必須要支援「巢狀式虛擬化技術」(Nested Virtualization)，屆時才能順利建立 Minikube 運作環境。

有關地端主機啟用 Nested Virtualization 機制的詳細資訊，請參考站內文章 網管人雜誌 133 期 - 實作 Hyper-V 巢狀虛擬化測試研發效率大提升。

圖、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖
圖片來源： Virtualization Blog - Windows Insider Preview： Nested Virtualization

有關 Microsoft Azure 雲端主機啟用 Nested Virtualization 機制的詳細資訊，請參考站內文章 ASDK Journey (2) - 實戰 Azure Stack Development Kit on Azure。當然，倘若考慮整體執行效能及穩定性和完整性，你可以直接使用 Microsoft Azure 的 AKS (Azure Kubernetes Service)服務，以便快速建立 Kubernetes Cluster 運作環境 (但是燒錢也更快速 😝)。

圖、Nested Virtualization in Azure
圖片來源： Nested Virtualization in Azure | Blog | Microsoft Azure





建立支援 Nested Virtualization 的 CentOS  7.5 虛擬主機

在 Microsoft Azure雲端環境中，需要支援 CentOS 7.5主機啟用 Nested Virtualization 機制時，請記得選擇的 VM 虛擬主機必須是「Dv3 或 Ev3」系列才行。舉例來說，本文採用 D8s v3系列的 VM 虛擬主機。

圖、採用的虛擬主機範本為 CentOS-based 7.5

圖、建立 D8s v3 系列的 VM 虛擬主機





基礎設定

有關 CentOS 的基礎設定就不再贅述，有興趣的朋友可以參考站內文章 CentOS 7.4 攻略 - 基礎設定系列文章。順利建立 CentOS 虛擬主機並透過 SSH 登入後，執行下列指令進行安裝桌面環境 (屆時，才方便透過瀏覽器連結 Kubernetes Dashboard)：
# yum -y update
# yum -y install epel-release
# yum -y groupinstall "Xfce"

完成後，記得在使用者家目錄新增「.Xclients」檔案，以便屆時 xrdp能夠在連接時知道採用 Xfce 桌面環境：
# cat ~/.Xclients
#!/bin/bash
XFCE="$(which xfce4-session 2>/dev/null)"
exec "$XFCE"
# chmod +x ~/.Xclients

接著，安裝相關套件、組態設定 SELinux、啟用相關服務，以便稍後可以透過 Remote Deskop 連接至 CentOS 7.5 虛擬主機：
# yum -y install xrdp tigervnc-server firefox
# chcon --type=bin_t /usr/sbin/xrdp
# chcon --type=bin_t /usr/sbin/xrdp-sesman
# systemctl enable xrdp && systemctl start xrdp
# systemctl enable xrdp-sesman && systemctl start xrdp-sesman
# netstat -tunpl | grep xrdp

圖、安裝相關套件、組態設定 SELinux、啟用相關服務

在連接至 CentOS 7.5 虛擬主機之前，除了 CentOS 主機本身的防火牆之外，因為本文實作環境採用 Microsoft Azure 公有雲環境，所以記得幫這台 CentOS 7.5 虛擬主機開啟允許「TCP Port 3389」流量能夠通過 NSG 防火牆。

圖、允許 TCP Port 3389 流量能夠通過 NSG 防火牆

圖、透過 Remote Desktop 連結至 CentOS 7.5 虛擬主機

順利透過 Remote Desktop 連結至 CentOS 7.5 虛擬主機後，鍵入使用者帳號及密碼後準備登入剛才安裝的 Xfce 桌面環境。

圖、鍵入使用者帳號及密碼

倘若，無法順利登入 Xfce 桌面環境的話，請檢查「/var/log/xrdp.log」內容看哪裡出錯以利排除障礙。


圖、透過 Remote Desktop 連結 CentOS 主機 xrdp.log 日誌內容

順利通過使用者身分驗證後，即可登入剛才所安裝的 Xfce 桌面環境，並且在剛才安裝相關套件時有安裝 Firefox 套件，所以可以嘗試開啟看看是否能夠順利運作。


圖、登入 Xfce 桌面環境並開啟 Firefox 瀏覽器





安裝 Kubectl

在開始安裝 Kubectl 之前，我們先透過「cat /proc/cpuinfo | grep vmx」指令，再次確認 CentOS 7.5 虛擬主機支援啟用 KVM機制，以便稍後能夠順利建立及啟動 Minikube 主機。


圖、再次確認 CentOS 主機支援啟用 KVM 機制

請依序執行下列相關指令，以便為 CentOS 主機安裝 kubectl。詳細資訊請參考官網文章 Install and Set Up kubectl - Kubernetes。
# cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# yum install -y kubectl

順利安裝完畢後便可以執行「kubectl version、kubectl cluster-info」指令，確認採用的 kubectl 指令版本資訊。從指令結果可以看到，目前僅會顯示 Client 版本 (因為 Server 部分尚未建立，所以無法順利顯示)。

圖、確認採用的 kubectl 指令版本資訊

因為，後續我們常常需要鍵入 kubectl 等相關指令，所以啟用 CentOS Bash Shell 指令自動完成功能，除了減少打錯字之外也提高鍵入指令的速度。詳細資訊請參考官網文章 Install and Set Up kubectl - Enabling shell autocompletion - Kubernetes。
# yum -y install bash-completion
# source <(kubectl completion bash)
# echo "source <(kubectl completion bash)">> ~/.bashrc





安裝 KVM2

請依序執行下列指令，為 CentOS 主機安裝 KVM2 Driver。詳細資訊請參考官網文章 kubernetes/minikube - kvm2 driver。
# yum -y install libvirt libvirt-daemon-kvm qemu-kvm
# wget https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2
# install docker-machine-driver-kvm2 /usr/bin/docker-machine-driver-kvm2
# usermod -a -G libvirt $(whoami)
# newgrp libvirt
# systemctl enable libvirtd && systemctl start libvirtd





安裝 Minikube

最新版本的 Minikube 資訊請參考 Releases · kubernetes/minikube，安裝完畢後便可以執行「minikube version」指令，確認採用的 minikube 版本資訊。詳細資訊請參考官網文章 Install Minikube - Kubernetes。

當 Minikube 運作環境準備完畢後，便可以執行下列指令建立 Minikube VM 也就是建構「單機 Kubernetes Cluster」運作環境的動作。值得注意的是，依據實作的 CentOS 7.5 主機的硬體資源情況，調整 Minikube VM 的硬體資源配置為「4 vCPU、16 GB vRAM」，倘若未調整的話預設硬體資源配置為「2 vCPU、2 GB vRAM、20 GB vHDD」。
# wget https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
# install minikube-linux-amd64 /usr/bin/minikube
# minikube version
# minikube start --cpus=4 --memory=16384 --vm-driver=kvm2
# kubectl version
# kubectl cluster-info
# kubectl get all

圖、安裝 Minikube on CentOS 7.5 with KVM



Kubernetes Dashboard

在開啟 Kubernetes Dashboard 之前，我們透過 xdg-mime指令組態設定 Xfce 桌面環境的預設瀏覽器為剛才安裝的 Firefox。
# mkdir -p ~/.local/share/applications
# xdg-mime default firefox.desktop x-scheme-handler/http
# xdg-mime default firefox.desktop x-scheme-handler/https
# xdg-mime query default x-scheme-handler/http
# xdg-mime query default x-scheme-handler/https
# xdg-open http://centos.org

圖、組態設定 Xfce 桌面環境的預設瀏覽器為 Firefox

現在，我們可以執行「minikube status」、「minikube service list」確認 Kubernetes Cluster 運作環境資訊，確認 Kubernetes Dashboard 服務運作後，便可以執行「minikube dashboard」指令，系統便會自動開啟預設的瀏覽器連接至 Kubernetes Dashboard 頁面。
# minikube status
# minikube service list
# minikube dashboard

圖、連接至 Kubernetes Dashboard 頁面



建立第 1 個 Pod 和 hello-minikube 容器

確認 Kubernetes Cluster 運作環境正確無誤後，便可以著手測試「部署」(Deployment) 第 1 個測試用途的 Pod 及容器，然後透過 Expose 機制把 Pod 及容器對應至外部網路，之後可以開啟瀏覽器或使用 curl 指令確認是否正確運作。
# kubectl run hello-minikube --image=gcr.io/google_containers/echoserver:1.4 --port=8080
# kubectl expose deployment hello-minikube --type=NodePort
# kubectl get pods
# minikube service list
# curl $(minikube service hello-minikube --url)

圖、建立第 1 個 Pod 和容器



登入 Minikube VM

管理人員可以使用「minikube ip」指令，確認 Minikube VM 所使用的 IP 位址，以及使用「minikube docker-env」指令，了解 Minikube VM 使用的容器環境資訊。甚至想要登入 Minikube VM 的話，只要執行「minikube ssh」即可 (離開請使用 exit 指令)，登入 Minikube VM 後，可以看到剛才部署的 hello-minikube 容器資訊。
# minikube ip
# minikube docker-env
# minikube ssh
$ docker ps

圖、登入 Minikube VM



刪除測試用途的 Pod 及容器

測試完畢後，便可以分別執行「kubectl get deployment」、「kubectl delete deployment hello-minikube」、「kubectl get pods」指令，將剛才測試用途的 Pod 及容器刪除。
# kubectl get deploymenbt
# kubectl delete deployment hello-minikube
# kubectl get pods

圖、刪除測試用途的 Pod 及容器



刪除 Minikube VM

倘若，需要刪除 Minikube VM (單機 Kubernetes Cluster) 運作環境的話，那麼可以先執行「minikube stop」指令，即可將 Minikube VM 進行關機的動作，然後執行「minikube delete」指令即可刪除 Minikube VM。
# minikube status
# minikube stop
# minikube delete
# minikube status
# kubectl version --short

圖、刪除 Minikube VM





參考資源

↧

Windows Server 2019 S2D 新功能預覽

June 27, 2018, 8:19 pm
$
0
0

前言

今年是 Windows Server 在市場上的第 25 年，微軟預計在今年底推出 Windows Server 2019，倘若你錯過先前 Windows Server Summit 2018 這場線上會議，除了可以線上觀看影片了解相關資訊之外，也可以參考本文概述在 Windows Server 2019雲端作業系統當中，有關 S2D (Storage Spaces Direct)的新增或增強的特色功能。






4 PB per S2D Cluster

在 Windows Server 2016環境中所打造的 S2D Cluster，最大儲存空間支援至「1 PB」。屆時，透過新一代的 Windows Server 2019所打造的 S2D Cluster，最大儲存空間支援至「4 PB」。

圖、4 PB per Windows Server 2019 S2D Cluster
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft

此外，在 Windows Server 2016 環境中，最佳建議是每台 Node 主機的儲存空間為「100 TB」及最大 Volume 為「32 TB」，而在 新一代的 Windows Server 2019 環境中，則提升為「400 TB」及「64 TB」，下列便是整理的 Larger maximum scale 表格：

圖、Windows Server 2016 / 2019 S2D Cluster 規模比較表
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft





USB Witness

在 Windows Server 2016 環境中所打造的 S2D Cluster 環境中，在 Quorum / Witness 的部分支援「File Share Witness」、「Cloud Witness」這 2 種方式。

新一代的 Windows Server 2019 所打造的 S2D Cluster 環境中，新增支援「USB Witness」仲裁機制 (without another server or VM, without Internet, and even without Active Directory)。

圖、Windows Server 2019 S2D Cluster 支援 USB Witness
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft

圖、Windows Server 2019 S2D Cluster 支援 USB Witness
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft





Drive Latency 異常偵測

新一代的 Windows Server 2019 所打造的 S2D Cluster 環境中，導入 Microsoft Azure 針對儲存裝置的「異常偵測」(Outlier Detection) 機制。

因此，預設情況下會記錄每個儲存裝置的 讀取 / 寫入 的「結果 (成功 / 失敗)」及「延遲時間」，並且支援透過 PowerShell或 WAC (Windows Admin Center)查看這些儲存裝置的 I/O 資訊。

圖、Windows Server 2019 S2D Cluster 支援儲存裝置異常偵測
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft

當 Windows Server 2019 的 S2D Cluster，偵測到儲存裝置發生存取異常時，便會在儲存裝置的運作狀態中加上「Abnormal Latency」標記。

圖、偵測到儲存裝置發生存取異常時加上標記
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft





增強 Mirror-Accelerated Parity IOPS

新一代的 Windows Server 2019 所打造的 S2D Cluster 環境中，增強 Mirror-Accelerated Parity IOPS儲存效能 (相較於 2016 增強 1 倍的 IOPS)，所以當企業或組織對於 IOPS 儲存效能的需求為「中等」，而希望獲得更多儲存空間時可以考慮採用。

圖、Mirror-Accelerated Parity IOPS 儲存效能增加 1 倍
圖片來源： Here’s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit | Storage at Microsoft



↧
↧

關於本站

July 9, 2018, 8:53 am
$
0
0

關於本站

本網站所引用他人商標或圖示均屬該來源網站或其合法權利人所有，本站內容多為個人研究心得，其所寫之實作筆記內容多為參考網路上資料並實際操作後所記錄完成，歡迎分享網站內容並標示出處及作者但僅限於非商業用途連結，且禁止改作(若你重混、轉換本素材，或依本素材建立新素材，則你不得散布改作後的素材!!) [本網站內容受 創用 CC 授權 3.0保護]，本網站若有任何地方侵犯到您權利的地方，請 Mail 給我 將會立刻處理謝謝您。



Weithenn 摸索 IT 世界回顧：

2002 年

6 月：

          憲兵退伍，連主要分割區是什麼東東也不知的人不自量力的想進入所謂的 IT 界工作。

8 月：

          懷著一份對電腦世界的興趣及崇拜，因而參加網路工程師班，並認識了良師 George 及益友 Mandy、Tony...等技術同好。

11 月：

          網路工程師班結訓後，第一份工作學習到有關 Cisco、3Com 網路設備...等技術 ，並且創立本站。



2003 年

4 月：

          第 1 份工作時，在 Bruce 的鼓勵下考取生平第一張證照 CCNA。

8 月： 

          第 2 份工作中，遇見 Clive開始接觸 FreeBSD便一腳陷入惡魔的世界 (BSD Committer TW 之一 Clive 的電腦世界回顧與展望)。



2007 年

3 月：

          想開了!! 開始到世界各地走走，開始記錄遊山玩水的點點滴滴。



2010 年

5 月：

          遇見了 VMware vSphere 虛擬化技術的良師 Johnny。

10 月：

          受邀採訪並刊登於 iThome 第 480 期 iT 人甘苦談 ─ 架 Wiki 做筆記，IT 人分享學習心得。



2011 年

11 月：

          (1) 受邀擔任 慶聯有線電視 - HP/Dell/IBM 伺服器及 CentOS 作業系統基礎設定 內部教育訓練講師。

          (2) 受邀推薦 iThome 2011 年 IT 好書 100 - 系統與網路管理類。

12 月：

          (1) 出版人生中 第 1 本著作 24小時不打烊的雲端服務：專家教你用 CentOS 架設萬年不掛的伺服器。感謝大家熱情支持，此著作已經登上 博客來 2012 年度排行榜 - 電腦類 TOP 50。




2012 年

3 月： 

          (1) 受邀擔任 雙和區資訊組長研習 - VMware vSphere ESXi 進階技術研習講師。

          (2) 參加 Microsoft 所主辦的虛擬化戰士團，獲得 2012 年第一屆金翅級認證，微軟伺服器虛擬日 V-Day 虛擬化戰士頒獎典禮。


4 月： 

          (1) 受邀擔任 雙和區資訊組長研習 - CentOS HA 高可用性進階技術研習講師。

          (2) 成為 台灣第 1 位獲選 VMware vExpert 殊榮的人 VMware vExpert Information - Wei-Ren Wang，並受邀採訪刊登於 VMware VMTN Blog: vExpert Spotlight: Wei-Ren Wang。


5 月： 

          (1) 受邀擔任 雙和區資訊組長研習 - FreeNAS 進階技術研習講師。

          (2) 出版人生中 第 2 本 著作 (技術審校書) 企業級的網路安全架構：終極防駭技術大剖析。


6 月： 

          (1) 受邀擔任 雙和區資訊組長研習 - Hyper-V Server 2008 R2 進階技術研習講師。

          (2) 跟 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Microsoft Technet Blog - 文章審校。

7 月： 

          (1) 當選 Microsoft MVP - Virtualization Virtual Machine項目 Microsoft MVP Profile - Wei-Ren Wang。


          (2) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server 2012 實戰影片審校。

8 月： 

          (1) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server Blog - 部份文章審校。

          (2) 參加 Windows Server 2012 (Hyper-V 3) 好文比賽獲得 分享獎。

9 月： 

          (1) 出版人生中 第 3 本 著作 (技術審校書) 世界連在一起，搜尋引擎的核心秘密。


          (2) 受邀推薦 iThome 2012 年 iT 人必看的好書 - 系統與網路管理類。

          (3) 於 Microsoft Techdays Taiwan 2012舉辦期間，在 Windows Server 2012 攤位擔任 問專家。



11 月：

          (1) 受邀擔任 板橋區資訊組長研習 - VMware vSphere ESXi 5.1 實作講師。

          (2) 受邀擔任 Acer Infrastructure & Virtualization 技術會議 內部教育訓練講師。

          (3) 受邀採訪並刊登於 網管人雜誌 第 81 期 資訊這條路 ─ 從無到有十年苦功 王偉任嶄露頭角。

12 月：

          (1) 受邀擔任 雙和區資訊組長研習 - Windows Server 2012 新功能技術研討講師。

          (2) 出版人生中 第 4 本 著作 (技術審校書) MySQL+PHP初心者的學習殿堂：資料庫×動態網頁設計實務養成(附CD)。




2013 年

1 月： 

          擔任 WebConf Taiwan 2013講師，當天議程簡報無廢話 DRBD + Heartbeat 實戰，當天議程錄影無廢話 DRBD + Heartbeat 實戰。WebConf Taiwan 2013 懶人包、WebConf Taiwan 2013 Day 1 - 活動照片、WebConf Taiwan 2013 Day 2 - 活動照片。


3 月： 

          擔任 Microsoft TechNet - 邁向雲端虛擬化的全方位攻略 - Hyper-V 與 VMware 大不同課程講師。
          當天議程簡報Hyper-V 與 VMware 大不同。
          當天議程錄影Hyper-V 與 VMware 大不同 (上)、Hyper-V 與 VMware 大不同 (下)。

4 月： 

          (1) 擔任 第二屆 - 虛擬化戰士 Hyper-V 3.0 培訓計畫助教。

          (2) 貢獻 Hyper-V 2.0 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

          (3) 貢獻 Hyper-V 3.0 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

5 月： 

          (1) 出版人生中 第 5 本 著作 (個人著作) 24 小時不打烊的雲端服務－專家教你用 Windows Server 2012 Hyper-V3.0 實戰虛擬化技術。


          (2) 擔任 2013 微軟 MVP 實戰課程日講師。
                當天議程簡報Hyper-V 3.0 實戰 - 打造你的完美伺服器虛擬化平台。
                當天活動簡報台灣微軟 - 研討會與活動簡報下載 - 微軟實戰課程日。
                當天活動錄影台灣微軟 - 實戰課程日回顧篇。

6 月： 

          (1) 第 2 度當選 VMware vExpert 2013，VMware vExpert Information - Wei-Ren Wang。


          (2) 受邀擔任 雙和區資訊組長研習 - VMware vSphere/Microsoft Hyper-V 虛擬化技術平台之 CentOS Webmin 應用講師。

          (3) 受邀商業週刊採訪 商業週刊第1334期 - 這家公司　讓微軟恨、林百里愛。

7 月： 

          (1) 第 2 度當選 Microsoft MVP - Virtualization Virtual Machine 項目 Microsoft MVP Profile - Wei-Ren Wang。


          (2) 貢獻 Windows Server 2012 MPIO 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

8 月： 

          (1) 受邀擔任 雙和區資訊組長研習 - 虛擬化應用與基礎電腦病毒安全防護 (A場)、(B場)講師。

          (2) 受邀擔任 特新光電 - Windows Server 2008 R2 教育訓練 內部教育訓練講師。

9 月： 

          於 Microsoft Techdays Taiwan 2013舉辦期間，擔任 虛擬化平台最佳選擇: Windows Server 2012 R2 (Hyper-V 3.0 R2) vs VMware vSphere 5.1 及進行Vmware 無痛移轉之工具及建議議程講師。當天活動錄影及簡報 Channel 9 - Techdays Taiwan 2013。


10 月： 

          (1) 受邀擔任 艾鍗學院 - 職訓課程 - 網管工程師類 - 私有雲與虛擬化系統工程師養成班講師。

          (2) 貢獻 Microsoft Virtual Machine Converter文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

11 月： 

          (1) 出版人生中 第 6 本 著作 (英文翻譯書) 打造雲端工作站 VMware View 5 建置與維護。


          (2) 受邀擔任 威盛電子 - Windows Server 2012 R2 虛擬化平台最佳選擇 內部教育訓練講師。

          (3) 貢獻 Windows Server 2012 即時遷移文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

          (4) 擔任 102學年度全國大專校院 - 資訊行政主管研討會 - 淡江大學軟體雲建置實例分享議程講師，當天議程簡報 淡江大學軟體雲建置實例分享(PDF)。

          (5) 擔任 VMware 桌面虛擬化及軟體雲應用研討會講師，當天議程簡報 虛擬桌面最佳化調校。


12 月： 

         (1) 受邀擔任 雙和區資訊組長研習 - Hyper-V 3.0與 VMware vSphere 5.5 虛擬化新功能比較講師。

         (2) 受邀擔任 元智大學 - 雙 V 駭客，架設高可用的服務主機 (Hyper-V 上午場)、(VMware 下午場)研習活動講師。




2014 年

2 月： 

          貢獻 Windows Server 2012 R2 - 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

3 月： 

          (1) 貢獻 Windows Server 2012 R2 - Hyper-V 10 大特色功能、Windows Server 2012 R2 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

          (2) 擔任 2014 微軟技術關卡破解日 講師。
               當天所有議程錄影 Channel 9 - MVP 微軟技術關卡破解日。
               當天議程錄影及簡報 虛擬化平台最佳選擇 - Windows Server 2012 R2 Hyper-V 新功能展示。


4 月： 

          (1) 擔任 春源鋼鐵 - VMware Horizon View 虛擬桌面 內部教育訓練講師。

          (2) 第 3 度當選 VMware vExpert 2014，VMware vExpert Information - Wei-Ren Wang。

       
          (3) 貢獻 Windows Server 2012 R2 虛擬桌面部署建議文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

5 月： 

          (1) 受邀擔任 集英信誠 - 與大師對談技術論壇講師。
               當天所有議程簡報 與大師對談活動簡報。
               當天我的議程簡報 VMware 及 Hyper-V最佳虛擬化平台硬體規劃。

          (2) 受邀擔任 雙和區資訊組長研習 - HyperV 3.0 R2 新功能研討研習 講師。

6 月： 

          (1) 擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2014) 講師。
               當天所有議程簡報 2014 台灣微軟 IT 管理高峰會簡報下載。

          (2) 參加 Microsoft 主辦雲端戰士團，獲得 2014 年第三屆金翅級認證。
               當天活動新聞訊息 自由電子報 3C科技 - 台灣微軟匯聚雲端戰士團。


          (3) 擔任 文藻外語大學 - VMware Horizon View 虛擬桌面 內部教育訓練講師。

7 月： 

          (1) 出版人生中 第 7 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 虛擬化環境實戰 (初級篇)。

          (2) 第 3 度當選 Microsoft MVP - Hyper-V 項目 Microsoft MVP Profile - Wei-Ren Wang。


          (3) 擔任 北區農會電腦共用中心 - VMware / Hyper-V 伺服器及桌面虛擬化基礎 內部教育訓練講師。

8 月： 

          貢獻 Windows Server 2012 升級至 2012 R2 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

9 月： 

          於 Microsoft Techdays Taiwan 2014 舉辦期間，擔任 四場(PCIT306、DCIM309、PCIT305、DCIM402) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2014、MVA - TechDays Taiwan 2014。


11 月： 

          出版人生中 第 8 本 著作 (英文翻譯書) VMware Virtual SAN 管理手冊。


12 月： 

          貢獻 MVMC 2.0、Windows Server 2012 R2 運作模式切換 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。



2015 年

2 月： 

          第 4 度當選 VMware vExpert 2015，VMware vExpert Information - Wei-Ren Wang。


4 月： 

          (1) 出版人生中 第 9 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 叢集雲端架構實戰 (高級篇)。


        (2) 與 Channel 9 Taiwan 合作「建立 Microsoft Azure IaaS 雲端基礎建設」線上課程，進行字幕及簡報的翻譯及審校。

5 月： 

          (1) 受邀擔任 微軟 EMS 全方位企業雲端解決方案 講師。


          (2) 受邀 iThome 雜誌採訪，分享 全面透視虛擬環境網路效能的瓶頸觀點。

          (3) 受邀擔任 104 年度資訊應用服務人才培訓計畫 - 企業私有雲實戰講堂 - 以 VMware 為例  課程講師。

          (4) 貢獻 虛擬化環境導入評估工具 MAP、Storage Space 存放集區、 Azure RemoteApp 應用程式虛擬化  等文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

          (5) 與 TechNet 部落格合作翻譯 針對軟體定義資料中心而生的 - 新世代儲存機制 、企業級虛擬化及新世代應用程式平台 文章。

          (6) 出版人生中 第 10 本 著作 (技術審校書) SDN 軟體定義網路。



6 月： 

         擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2015) 講師。
               當天所有影片及議程簡報 2015 台灣微軟 IT 管理高峰會簡報下載。


7 月： 

        (1) 與 Channel 9 Taiwan 合作「深入探討網路儲存及災難備援議題」線上課程，進行字幕及簡報的翻譯及審校。

        (2) 與 Channel 9 Taiwan 合作「充分使用 Open Source 加速解決方案」線上課程，進行字幕及簡報的翻譯及審校。

        (3) 與 Channel 9 Taiwan 合作「使用 Azure 優化工作負載架構和管理能力」線上課程，進行字幕及簡報的翻譯及審校。

        (4) 第 4 度當選 Microsoft MVP - Hyper-V 項目 Microsoft MVP Profile - Wei-Ren Wang。


9 月： 

         (1) 受邀擔任 資策會 Hyper-V 虛擬化實戰系列課程講師。

         (2) 於 Microsoft Techdays Taiwan 2015 舉辦期間，擔任 3場(ITM305、ECI309、ECI303) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2015。



10 月： 

          (1) 與 MSDN 部落格合作翻譯 微軟正式宣布推出 PowerShell DSC for Linux Version 1.1 以及新的 Linux 資源文章。

          (2) 出版人生中 第 11 本 著作 (英文翻譯書) 實戰 Azure 混合雲｜基礎架構 x 高可用性 x 災難復原。


11 月： 

          出版人生中 第 12 本 著作 (英文翻譯書) Active Directory 環境的 PowerShell 活用指南。




2016 年

1 月： 

          與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：
               [Compute] Windows Server 2016 攻略 (一) - 新世代虛擬化平台 Hyper-V
               [Compute] Windows Server 2016 攻略 (二) - 為雲端而生的極簡平台 Nano Server
               [Compute] Windows Server 2016 攻略 (三) - 整合雲端元素的容錯移轉叢集

2 月： 

          (1) 第 5 度當選 VMware vExpert 2016技術專家，VMware vExpert Information - Wei-Ren Wang。


          (2) 與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：
               [Storage] Windows Server 2016 攻略 (四) - SDS 軟體定義儲存
               [Storage] Windows Server 2016 攻略 (五) - 資料備援新選擇 Storage Replica
               [Storage] Windows Server 2016 攻略 (六) - 儲存資源品質管控機制 Storage QoS

3 月： 

         (1) 貢獻多篇技術文章至 Microsoft TechNet 技術文件庫：
                Windows Server vNext 新技術預覽
                WDS 部署服務
                Microsoft SDS 軟體定義儲存技術
                Microsoft 資料保護最後一哩 Storage Replica
                新世代伺服器 Nano Server

          (2) 與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：
               [Network] Windows Server 2016 攻略 (七) - 新世代虛擬網路交換器 SET ( Switch Embedded Teaming )
               [Network] Windows Server 2016 攻略 (八) - SDN 軟體定義網路

4 月： 

          出版人生中 第 13 本 著作 (英文翻譯書) VMware vSphere 最佳化效能調校。


5 月： 

         受邀擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。

6 月： 

         (1) 出版人生中 第 14 本 著作 (英文翻譯書) Hyper-V 最佳實踐：快速建置虛擬化解決方案。    


         (2) 受邀擔任 聖約翰科技大學 - VMware 虛擬化技術培訓課程 講師。

7 月： 

        (1) 第 5 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。


        (2) 受邀擔任 105 年度資訊應用服務人才培訓計畫 - 企業私有雲之規劃與建置 (實務班、進階班) - 以 Microsoft Hyper-V 為例  課程講師。

        (3) 受邀擔任 財團法人中興工程顧問社 VMware Horizon VDI 虛擬桌面 內部教育訓練講師。

8 月： 

        (1) 受邀擔任 資策會 - VMware vSphere ESXi 桌面虛擬化實戰課程講師。

        (2) 受邀擔任 Community Open Camp活動講師。


11 月： 

       (1)  受邀擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。

       (2)  受邀擔任 中華電信學院 - VMware vSphere 建置與維護實作進階班 講師。



2017 年

2 月： 

         第 6 度當選 VMware vExpert 2017 技術專家，VMware vExpert Information - Wei-Ren Wang。


3 月： 

         受邀分享 打造 Infrastructure Agility Mode 2 的基石 – Docker / Container 議程講師。

4 月： 

        受邀擔任 國立臺北商業大學 - 私有雲規劃與建置 Hyper-V 實務班 課程講師。

6 月： 

        受邀擔任 iThome Cloud Summit 2017 - Bimodal IT 打造 SDDC 軟體定義資料中心 議程講師。

7 月： 

        (1) 第 6 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。


        (2 ) 受邀擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲之SDS軟體定義儲存實務班  課程講師。

        (3) 出版人生中 第 15、16 本 著作 (英文翻譯書) VMware vSphere 6 企業級專家手冊。


8 月： 

        (1) 受邀擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲規劃與建置之最佳化調校實務班課程講師。

        (2) 首度當選 VMware vExpert 2017 - VSAN，這是由全球 1514位 VMware vExpert 2017成員中再度選出 vExpert VSAN，2017 年只有 74位獲選。


        (3) 出版人生中 第 17 本 著作 (個人著作) 微軟 S2D 軟體定義儲存技術實戰。


9 月： 

        (1) 受邀擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。

        (2) 受邀擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。

        (3) 受邀擔任 DevOpsDays Taipei 2017 - 打造 Infrastructure Agility: Mode 2 的基石 - SDS 軟體定義儲存 議程講師。


10 月： 

        (1) 受邀擔任 國立台北商業大學 - Docker 容器技術實務應用班 課程講師。

12 月： 

        (1) 受邀擔任 國立台北商業大學 - 私有雲規劃與建置實務班 - Hyper-V 課程講師。

        (2) 受邀擔任 法務部 - Windows Server Container 教育訓練課程講師。

        (3) 網管人雜誌專訪 軟體定義儲存也要嚴選，東森得易購導入微軟 S2D。


        (4) 受邀擔任 Dell/Microsoft - IT 未來新能量 研討會講師。

        (5) 出版人生中 第 18 本 著作 (英文翻譯書) Windows Server 容器技術。




2018 年

2 月： 

         第 7 度當選 VMware vExpert 2018 技術專家 VMware vExpert Information - Wei-Ren Wang，在 2018 年全球共有 1,536 位 VMware vExpert (Taiwan 共 5 位獲選)。


3 月： 

         (1) 與台灣微軟合作，錄製 六分鐘學會在 Azure VM 中啟用巢狀虛擬化 Nested Virtualization影片，幫助您實際操作了解如何在 Azure VM 啟用巢狀虛擬化技術。


         (2) 受邀擔任 Serverless All-Star 研討會講師。



4 月： 

         (1) 受邀擔任 聖約翰科技大學「雲端，人工智慧，物聯網暨大數據之生態與展望，產品行銷策略技術與管理」課程的業師，與該校 40 位老師/教授分享我在 SDDC 軟體定義資料中心的一些經驗談。

         (2) 受邀擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。

5 月： 

         (1) 受邀擔任 iThome Cloud Summit 2018 - 打造 VM / Container / Serverless 三位一體的軟體定義資料中心 議程講師。


         (2) 受邀擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。

         (3) 受邀擔任 國立台北商業大學 - Microsoft S2D - HCI 超融合規劃與建置實務班講師。

6 月： 

         (1) 受邀擔任 iThome Kubernetes Summit 2018 - OpenFaaS on Kubernetes - 1 分鐘建構好你的 Serverless 平台議程講師。



7 月： 

        (1) 第 7 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。




其它

  • Weithenn PGP Keyid： 0xCD39063B
  • Weithenn Twitter： @weithenn
  • 最有價值專家： Microsoft MVP 2012 ~ 2017、VMware vExpert 2012 ~ 2018
  • 壁紙清單： CCNA, NSPA, JNCIA-JUNOS, JNCIA-ER, JNCIA-EX, JNCIA-Sec, MCP, MCSA, MCTS, MCITP, RHCT, RHCSA, RHCE, VSP4, VTSP4, VCP4, VSP5, VTSP5, VCP5-DCV, VCA-Cloud、VCA-DCV、VCA-WM、VCP-Cloud、VCP5-DT。
↧

150 期 - vSphere 管理平台大搬風趁早無痛遷移 vCSA 6.7

July 10, 2018, 7:10 pm
$
0
0

網管人雜誌

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





前言
考量 Windows vCenter Server 遷移至 vCSA 管理平台
          Embedded 部署模式遷移至 vCSA
          External 部署模式遷移至 vCSA
          vCenter Server 5.5 無法遷移至新版 vCSA 6.7
實戰 - Windows vCenter Server 6.0 遷移至 vCSA 6.7 管理平台
          執行 VMware Migration Assistant
          遷移階段 1、部署 vCSA 6.7 虛擬主機
          遷移階段 2、匯出 / 匯入 vCenter Server 資料庫及組態設定
          採用 HTML5 或 FLEX 管理介面？
          VAMI 和 Clarity UI 提供良好 vCSA 管理體驗
結語





前言

VMware 官方在 2018 年 4 月 17 日時，正式推出新一代 SDDC 軟體定義資料中心解決方案 VMware vSphere 6.7版本。同樣的，整個 VMware vSphere 虛擬化基礎架構中，相關重要的運作元件及各式平台也同步推升至 6.7 版本，包括 vSphere ESXi 6.7 虛擬化平台、vCenter Server 6.7 管理平台、vSAN 6.7 軟體定義儲存、VMware Cloud on AWS 混合雲解決方案……等（如圖 1 所示）。

圖 1、VMware vSphere 6.7 Hybrid Cloud 運作示意圖
圖片來源： VMware 官網– Introducing vSphere 6.7

值得注意的是，隨著新一代管理平台 vCenter Server 6.7 版本的釋出，VMware 也在官方部落格中正式宣佈，在 vSphere 6.7 版本中的 vCenter Server for Windows管理平台，將會是「最後一版」的 Windows vCenter Server 版本，這表示在後續的 vSphere 版本中，VMware 將只會釋出採用 SUSE Linux作業系統，所打造的 vCSA（vCenter Server Appliance）管理平台（如圖 2 所示）。

圖 2、vSphere 6.7 將是最後一版包含 vCenter Server for Windows 的版本
圖片來源： VMware vSphere Blog - Which vCenter Server platform should I use - Appliance or Windows ?

那麼，企業或組織當中的 VMware vSphere 管理平台，倘若已經建構在 Windows Server 作業系統平台上，是否有方式可以將現有 Windows vCenter Server 管理平台中的資料，例如，資料庫檔案、VM 虛擬主機效能資訊、vSwitch 虛擬交換器組態設定……等，無縫式的遷移至 VMware 官方所建議的 vCSA（vCenter Server Appliance）管理平台上呢？

本文所要說明及實作的重點，便是著重於如何將企業及組織中「現有」的 Windows vCenter Server，無縫式的遷移至新一代的 vCSA 6.7 管理平台當中。





考量 Windows vCenter Server 遷移至 vCSA 管理平台

首先，管理人員必須要先確認，現有的 Windows vCenter Server 運作版本及部署模式，是早期的 5.5 版本還是較新的 6.x（6.0 或 6.5）版本，部署模式為採用所有運作角色 All-in-One 的「Embedded」模式，還是各種角色分散運作的「External」模式。

當管理人員確認 Windows vCenter Server 運作版本及部署模式後，那麼才能夠確認後續要執行遷移至 vCSA 管理平台的操作步驟有哪些（如圖 3 所示）。

圖 3、Windows vCenter Server 遷移至 vCSA 管理平台步驟示意圖
圖片來源： VMware Docs - Overview of Migration from vCenter Server on Windows to an Appliance



Embedded 部署模式遷移至 vCSA

當管理人員確認原有的 Windows vCenter Server 部署模式，為所有運作角色集中運作於「同 1 台」主機上的「Embedded」模式時，那麼只要執行 2 個遷移步驟（Migration Assistant 及 Migration Tool），即可完成遷移至 vCSA 管理平台的工作任務。

值得注意的是，從 VMware vSphere 6.0 版本開始，擔任 vSphere 虛擬化基礎架構管理平台角色的 vCenter Server，運作架構由早期 vSphere 5.x 版本四大角色 Inventory Service、Web Client、SSO（Single Sign-On）、vCenter Server，從新版 vSphere 6.0開始統一為 PSC（Platform Services Controller）及 vCenter Server這二大角色而已。

因此，倘若採用的是 vCenter Server 5.5管理平台時，那麼遷移至新版 vCSA 6.5 管理平台後，將會轉為使用新版 PSC（Platform Services Controller）運作架構。倘若採用的是 vCenter Server 6.0管理平台時，那麼除了原有 PSC 運作架構之外最大的不同便是底層的作業系統，由 Windows Server 遷移至 vCSA 管理平台所採用的 SUSE Linux 作業系統（如圖 4 所示）。

圖 4、Embedded 部署模式- vCenter Server 5.5 及 6.0 遷移至 vCSA 管理平台示意圖
圖片來源： VMware Docs - GUI Migration of vCenter Server with an Embedded vCenter Single Sign-On or Platform Services Controller to an Appliance



External 部署模式遷移至 vCSA

倘若原有的 Windows vCenter Server 部署模式，為運作角色分散於「不同台」主機上的「External」模式時。那麼，當運作架構採用早期 vCenter Server 5.5版本四大角色 Inventory Service、Web Client、SSO（Single Sign-On）、vCenter Server 的話，就必須先透過 Migration Assistant 遷移工具，將 SSO（Single Sign-On）運作角色遷移至新版 PSC（Platform Services Controller）當中，然後再將其它三大角色 Inventory Service、Web Client、vCenter Server 進行遷移作業。

同樣的，採用的是 vCenter Server 6.0管理平台時，最大的不同便是底層的作業系統，由 Windows Server 遷移至 vCSA 管理平台所採用的 SUSE Linux 作業系統（如圖 5 所示）。

圖 5、External 部署模式- vCenter Server 5.5 及 6.0 遷移至 vCSA 管理平台示意圖
圖片來源： VMware Docs - GUI Migration of vCenter Server with an External vCenter Single Sign-On or Platform Services Controller to an Appliance



vCenter Server 5.5 無法遷移至新版 vCSA 6.7

此外，管理人員除了必須確認原有的 Windows vCenter Server 管理平台，採用的是 Embedded 或 External 部署模式之外，還必須注意 Windows vCenter Server 管理平台的「版本」才行。

因為，當企業或組織採用的是舊版 Windows vCenter Server 5.5 管理平台時，將「無法」直接遷移至最新版本 vCSA 6.7管理平台，必須先遷移至 vCSA 6.0 或 vCSA 6.5 版本的管理平台後，才能升級至新版 vCSA 6.7 管理平台。

當然，若企業或組織採用的是 Windows vCenter Server 6.0或 6.5版本的管理平台時，不管採用的是 Embedded 或 External 部署模式，都可以直接遷移至最新版本 vCSA 6.7管理平台（如圖 6 所示）。

圖 6、Windows vCenter Server 6.0 或 6.5 版本可直接遷移至新版 vCSA 6.7
圖片來源： VMware Docs - Example Migration Paths from vCenter Server for Windows to vCenter Server Appliance 6.7





實戰 - Windows vCenter Server 6.0 遷移至 vCSA 6.7 管理平台

在本文實作環境中，我們採用已經建置好的 Windows vCenter Server6.0版本，並且受管理的虛擬化平台也採用 vSphere ESXi 6.0版本（如圖 7 所示）。同時，在建置 Windows vCenter Server 6.0 管理平台時，採用的是所有運作角色集中於同 1 台主機的「Embedded」模式，稍後將逐步實作遷移至新版 vCSA 6.7管理平台。

圖 7、現有 Windows vCenter Server 6.0 管理平台運作環境



執行 VMware Migration Assistant

首先，必須在「來源端」vCenter Server 主機上執行 VMware Migration Assistant 遷移工具，在本文實作環境中便是在 Windows vCenter Server 6.0 主機上執行。

請在 Windows vCenter Server 6.0 主機上，掛載 vCSA 6.7 ISO 映像檔之後，執行「D:\migration-assistant\VMware-Migration-Assistant.exe」遷移工具執行檔（本文實作環境光碟機為 D 槽）。

此時，VMware Migration Assistant 遷移工具，將會檢查此台 Windows vCenter Server 運作環境是否能執行遷移作業，舉例來說，在遷移工作任務中會使用 C Runtime功能，所以倘若 Windows Server 未具備這樣的運作環境時，則會提醒應該安裝相關 KB 後再次執行。在本文實作環境中，遷移工具便提示應該安裝 KB 2999226之後（如圖 8 所示），再次執行 VMware Migration Assistant 遷移工具。

圖 8、VMware Migration Assistant 遷移工具將預先檢查是否能執行遷移作業

Windows vCenter Server 遷移環境準備好之後，再次執行 VMware Migration Assistant 遷移工具，系統將會請你鍵入預設 Administrator@vsphere.local管理者帳號的密碼，通過身分驗證程序後便正式進行遷移流程環境檢查作業。

此時，VMware Migration Assistant 遷移工具將會顯示相關資訊，例如，來源端 vCenter Server 版本（本文實作環境為 Windows vCenter Server 6.0）、目的端 vCenter Server 版本（本文實作環境為 vCSA 6.7）、遷移組態設定（本文實作環境 vCenter Server 的 FQDN 為 vCenter.vsphere.weithenn.org）、遷移步驟……等（如圖 9 所示）。

圖 9、VMware Migration Assistant 遷移工具運作環境檢測完畢

當 VMware Migration Assistant 遷移工具檢測完畢後，將會顯示「Waiting for migration to start...」資訊。此時，管理人員便可以執行遷移 vCenter Server 的下一項工作任務，透過 VMware Migration Tools 開始遷移資料。



遷移階段 1、部署 vCSA 6.7 虛擬主機

當來源端的 Windows vCenter Server 6.0 管理平台完成遷移檢測後，請在 vSphere 虛擬化環境中「另一台」工作站主機掛載 vCSA 6.7 ISO 映像檔，同時這台工作站主機必須要能夠存取 Windows vCenter Server 6.0 管理平台及 vSphere ESXi 虛擬化平台，後續才能順利執行遷移任務。
為何不直接在 Windows vCenter Server 主機上，而必須在另一台工作站主機上執行 VMware Migration Tools？ 因為，在遷移過程中當 vCSA 6.7 管理平台欲取代 Windows vCenter Server 時，將會把 Windows vCenter Server 關機，所以必須於另一台工作站主機上執行 VMware Migration Tools，以避免屆時遷移工作任務執行中斷。
此外，考量屆時遷移 Windows vCenter Server 資料庫及組態設定資料量龐大，在網路傳輸的部份建議至少有專屬 1 Gbps網路環境，倘若具備 10 Gbps 網路頻寬更可有效降低整體的遷移時間（如圖 10 所示）。同時，在儲存資源方面也建議來源端及目的端的 vCenter Server，能夠「分開」使用不同的 Datastore 儲存資源，以避免因為遷移作業產生的大量 IOPS 讓儲存資源吃緊。

圖 10、vCenter Server 管理平台遷移運作示意圖
圖片來源： VMware KB2147711 - Estimating the time for migration of vCenter Server 5.5 or 6.0 to vCenter Server Appliance 6.5

順利掛載 vCSA 6.7 ISO 映像檔後，請執行「D:\vcsa-ui-installer\win32\installer.exe」（本文實作環境光碟機為 D 槽）。此時，系統將會開啟 vCenter Server Appliance Installer 精靈視窗，在本文實作環境中是將原有的 Windows vCenter Server 管理平台，遷移至 vCenter Server Appliance 管理平台，因此請選擇「Migrate」項目（如圖 11 所示）。
事實上，VMware Migrate Tools 操作介面支援多國語系，例如，日語、法語、正體中文……等。但本文實作環境皆採用英文語系，所以保持預設的英文語系操作介面即可。
圖 11、在另一台主機上執行 VMware Migration Tools 準備實際執行遷移作業

在遷移階段 1 的工作任務中，遷移工具共有 9 個選項必須與管理人員進行互動，第 1 項為系統再次說明 vCSA 6.7 的遷移工具僅支援 vCenter Server 6.0 與 6.5 管理平台版本，第 2 項則是 EULA 使用者授權條款。

第 3 項，則是連接至來源端 Windows vCenter Server 6.0 主機的相關資訊，例如，vCenter Server 的 FQDN 名稱、指定運作中的 Migration Assistant 連接埠、預設的 Administrator@vsphere.local 管理者帳號及密碼（如圖 12 所示），順利通過檢查作業後將會顯示 vCenter Server 的 SSL 憑證指紋資訊。

圖 12、來源端 Windows vCenter Server 6.0 主機相關資訊

第 4 項則是新版 vCSA 6.7 管理平台，屆時要部署在哪台 ESXi 虛擬化平台上，以及該台 ESXi 虛擬化平台的管理者帳號及密碼和 HTTPS 連接埠。在本文實作環境中，屆時新版 vCSA 6.7 管理平台將會部署於名稱為「esxi6-01.vsphere.weithenn.org」的 ESXi 虛擬化平台上（如圖 13 所示），同樣的通過檢查作業後將會顯示 ESXi 虛擬化平台的 SSL 憑證指紋資訊。

圖 13、新版 vCSA 6.7 管理平台將部署於 esxi6-01.vsphere.weithenn.org 虛擬化平台上

第 5 項，為指定部署的 vCSA 6.7 管理平台虛擬主機名稱及管理者密碼，在本文實作環境中指定 vCSA 6.7 管理平台虛擬主機名稱為「vCSA67」。第 6 項，則是指定 vCSA 所要採用的規模大小，舉例來說，當 vCSA 所要管理的 vSphere 虛擬化基礎架構，ESXi 主機在 100 台以內而 VM 虛擬主機在 1,000 台以內時，那麼建議採用 4 vCPU 及 16GB vRAM 配置的 Small 規格即可。在本文實作環境中，為研發測試環境所以採用 2 vCPU 及 10GB vRAM 配置的最小規格「Tiny」即可。
有關 vCSA 硬體資源需求的詳細資訊，請參考 VMware KB2106572 - Minimum requirements for the VMware vCenter Server 6 Appliance即可。
第 7 項，指定將 vCSA 6.7 管理平台部署於哪個 Datastore 儲存資源中。第 8 項，則是指定 vCSA 6.7 管理平台的網路組態，例如，要連接至哪個 vSwitch 虛擬交換器的 Port Group 。值得注意的是，這裡指定 vCSA 6.7 使用的 IP 位址為「臨時」使用的 IP 位址（本文實作環境指定為 10.10.75.67），也就是只有在遷移過程中使用而已，待屆時遷移作業完成後將直接使用並取代原有 Windows vCenter Server 6.0的 IP 位址（本文實作環境為 10.10.75.30）。最後，相關資訊確認無誤後按下 Finish 鈕，執行第 1 階段的 vCenter Server 遷移工作任務（如圖 14 所示）。

圖 14、執行第 1 階段的 vCenter Server 遷移工作任務

此時，系統將會依據剛才遷移流程中與管理人員互動的選項內容，執行部署 vCSA 6.7 管理平台的工作任務，待 vCSA 6.7 管理平台部署作業執行完畢後（如圖 15 所示），便會通知管理人員準備執行遷移流程的第 2 階段，匯出舊有 Windows vCenter Server 資料並遷移至 vCSA 6.7 管理平台。

圖 15、第 1 階段遷移任務執行完畢 vCSA 6.7 管理平台部署完成



遷移階段 2、匯出 / 匯入 vCenter Server 資料庫及組態設定

順利完成第 1 階段遷移任務部署好 vCSA 6.7 管理平台後，接著便是進入第 2 階段將現有 Windows vCenter Server 資料進行遷移。

在遷移階段 2 的工作任務當中，遷移工具共有 5 個選項必須與管理人員進行互動，第 1 項也是再次說明 vCSA 6.7 的遷移工具僅支援 vCenter Server 6.0 與 6.5 管理平台版本。第 2 項，則是指定要「匯出」資料的 Windows vCenter Server 6.0管理平台資訊，例如，vCenter Server 的 FQDN 名稱、Migration Assistant 連接埠、Administrator@vsphere.local 管理者帳號及密碼（如圖 16 所示）。

圖 16、指定要匯出資料的 Windows vCenter Server 6.0 管理平台資訊

因為遷移工具偵測到來源端的 Windows vCenter Server 6.0 管理平台，處於 Windows AD 網域環境並且為成員伺服器，所以新增第 3 項為 vCSA 管理平台指定網域資訊（如圖 17 所示）。值得注意的是，在此選項中鍵入的網域帳號必須具備加入 vCSA 主機至 Windows AD 網域的權限之外，在網域管理者帳號的部分「只需」鍵入使用者帳號即可，而無須在使用者帳號前加上 NetBIOS 網域名稱。
此時，遷移工具與管理人員的互動選項總數，將會由原本的 5 項變更為 6 項。
圖 17、鍵入的網域帳號必須具備加入 vCSA 主機至 Windows AD 網域的權限

第 4 項，為指定 Windows vCenter Server 6.0 管理平台要匯出哪些資料（如圖 18 所示），值得注意的是一旦選擇僅遷移及匯出部分資料的話，後續倘若需要其它資料時則無法進行遷移。舉例來說，假設僅選擇匯出「組態設定」（Configuration）資料，雖然可以有效縮短匯出及進行遷移的時間，但是後續若需要 VM 虛擬主機運作效能歷史資料時將無法進行遷移。
倘若，Windows vCenter Server 6.0 歷史資料過多導致資料量龐大，可以考慮清除舊有資料後再執行匯出和遷移工作任務，詳細資訊請參考 VMware KB1025914 - Purging old data from the database used by vCenter Server文章。
圖 18、建議匯出並遷移現有 Windows vCenter Server 所有資料

第 5 項，詢問管理人員是否要加入 VMware CEIP 使用者體驗計畫中。最後，在第 6 項中除了顯示剛才所有的互動選項內容之外，系統也再次提醒管理人員是否已經「備份」來源端 Windows vCenter Server 所有資料，相關資訊確認無誤後請按下 Finish 鈕，執行第二階段 Windows vCenter Server 資料遷移工作任務（如圖 19 所示）。

圖 19、執行第二階段 Windows vCenter Server 資料遷移工作任務

當遷移工具，順利將來源端 Windows vCenter Server 所有資料匯出並遷移後，此時便會將來源端的 Windows vCenter Server進行「關機」（Shutdown）的動作（如圖 20 所示），這就是遷移工具不應在來源端 Windows vCenter Server 上執行的原因。

圖 20、所有資料匯出並遷移後將 Windows vCenter Server 關機

當第 2 階段 Windows vCenter Server 資料遷移工作任務執行完成後，系統便會顯示連線至新版 vCSA 6.7 管理平台的網址（如圖 21 所示），可以看到跟原本的 Windows vCenter Server 主機 FQDN 相同（同時，IP 位址也已經進行取代）表示遷移完成。
那麼匯出並遷移 Windows vCenter Server 資料究竟需要多久時間 ？原則上，必須視 vCenter Server 資料量、網路傳輸速度、儲存資源及儲存效能 IOPS……等諸多因素而定，詳細資訊請參考 VMware KB2146420 - Estimating vCenter Server 5.5 to vCenter Server Appliance 6.0 migration time、VMware KB2147711 - Estimating the time for migration of vCenter Server 5.5 or 6.0 to vCenter Server Appliance 6.5文章。
圖 21、順利將 Windows vCenter Server 6.0 遷移至新版 vCSA 6.7 管理平台



採用 HTML5 或 FLEX 管理介面？

點選新版 vCSA 6.7 管理平台網址後，將會看到系統提示管理人員欲使用哪個管理介面，倘若點選「vSphere Web Client（FLEX）」選項，表示使用舊有 Flash 技術的管理介面，若點選「vSphere Client（HTML5）」選項，則是採用新興 HTML5 技術所開發的管理介面（如圖 22 所示）。

圖 22、採用舊有 Flash 技術或新興 HTML5 技術所開發的管理介面

管理人員倘若尚未熟悉新興 HTML5技術所開發的管理介面，仍然可以使用舊有 Flash 技術的管理介面繼續管理 VMware vSphere 虛擬化架構。然而，在最新的 vSphere 6.7版本當中，VMware 官方已經正式宣佈這是最後一版包含 vSphere Web Client（Flash）的版本，表示後續推出的 vSphere 新版僅有新興 HTML5 技術所開發的管理介面，所以管理人員理應趁早熟悉 HTML5 管理介面才是（如圖 23 所示）。
在新版 vSphere 6.7版本當中，HTML 5 管理介面的功能性已經達到 90% ~ 95%的完整性，後續推出的新版本中將能夠完全管理 VMware vSphere 虛擬化基礎架構。
圖 23、採用新興 HTML5 技術所開發的管理介面



VAMI 和 Clarity UI 提供良好 vCSA 管理體驗

事實上，某些企業及組織當中的管理人員，由於不熟悉 SUSE Linux 作業系統所以才未部署 vCSA 管理平台，因此 VMware 官方也開始針對 vCSA 管理平台，推出專用的 VAMI（vSphere Appliance Management Interface）管理介面，搭配整合 UX Guidelines、HTML/CSS Framework 和 Angular 技術的 Clarity UI協同運作，讓管理人員能夠有最佳的 vCSA 資源管理操作體驗。

只要管理人員開啟瀏覽器，鍵入 vCSA 6.7 管理平台的 FQDN 及 VAMI 管理介面的「Port 5480」連接埠，便可以看到 vCSA 管理平台的 VAMI 管理介面，在登入頁面中鍵入 vCSA 管理平台的管理者帳號及密碼即可登入。

登入後，在 VAMI 管理介面中，管理人員便可以立即看到 vCSA 管理平台的硬體資源情況，包含 CPU、Memory、資料庫、儲存資源……等健康資訊（如圖 24 所示）。
VAMI 管理介面同樣也支援多國語系，例如，日語、法語、正體中文……等。
圖 24、透過 VAMI 管理介面輕鬆掌握 vCSA 管理平台硬體資源健康情況





結語

透過本文的說明及實作演練相信讀者已經了解，要將現有已經建置的 Windows vCenter Server 管理平台，如何遷移至新一代採用 SUSE Linux 作業系統的 vCSA 管理平台，並且輕鬆透過 VAMI 管理介面掌握 vCSA 管理平台硬體資源健康情況。
↧
Search

VMware vSphere 6.7 Journey (4) - Persistent Memory / NVDIMM

July 11, 2018, 8:49 pm
$
0
0

前言

在新版 vSphere 6.7當中，開始支援新的儲存裝置「PMem (Persistent Memory)」或稱「NVDIMM (Non-Volatile Dual In-line Memory Module)」。

圖、PMem / NVDIMM
圖片來源：  vSphere 6.7 Core Storage - PMem (Persistant Memory) NVDIMM support in vSphere

簡單來說，透過 PMem / NVDIMM 新式儲存裝置，能夠提供介於 DRAM 與 SSD之間的儲存效能，並且儲存的資料不會因為伺服器失去電力而消失。

圖、PMem / NVDIMM 儲存效
圖片來源： VMware vSphere Blog - Introducing vSphere 6.7 for Enterprise Applications

PMem / NVDIMM 近乎於 DRAM 的速度 (至少比 SSD 快 100 倍)，因此 CPU 處理器在存取時就像存取 DRAM 一樣。

圖、SSD 與 PMem / NVDIMM 運作架構示意圖
圖片來源：  vSphere 6.7 Core Storage - PMem (Persistant Memory) NVDIMM support in vSphere





支援 Persistent Memory / NVDIMM 

現在，當 ESXi 虛擬化平台配置 Persistent Memory / NVDIMM高效能儲存資源後，將能得到下列優點：
  • vSphere 可以直接將 PMem / NVDIMM 格式化為 Datastore儲存資源，然後配置給 VM 虛擬主機使用。
  • VM 虛擬主機 (Guest OS) 無須調整/更改作業系統或應用程序，便能直接獲得超高速儲存資源 (Ultra-Fast Disk)。
  • 使用 vPMem / vNVDIMM 儲存資源的 VM 虛擬主機仍不失靈活性，仍然可透過 vSphere vMotion / DRS隨意遷移在不同 ESXi Host 之間。
圖、PMem / NVDIMM 格式化為 Datastore 儲存資源
圖片來源：  vSphere 6.7 Core Storage - PMem (Persistant Memory) NVDIMM support in vSphere

圖、PMem / NVDIMM 格式化為 Datastore 儲存資源
圖片來源：  vSphere 6.7 Core Storage - PMem (Persistant Memory) NVDIMM support in vSphere





VM 虛擬主機使用 vPMem / vNVDIMM 注意事項

雖然，VM 虛擬主機 (Guest OS) 無須調整/更改作業系統或應用程序，便能直接使用由 ESXi Host 將 PMem / NVDIMM 格式化的 Datastore 儲存資源。但是，在使用時還是有下列相關限制需要注意：

  • VM 虛擬主機必須採用 Virtual Hardware version 14或後續版本。
  • Guest OS必須支援 PMem / NVDIMM 儲存資源，例如，Windows Server 2016、RedHat 7.4……等。
  • VM 虛擬主機支援 vSphere vMotion / DRS 進行遷移，但是「不支援」HA及 Snapshots機制。
  • 當 ESXi Host 進入 Maintenance Mode 時，VM 虛擬主機 (包含 Power-Off VM)都必須「遷移」至其它 ESXi Host。同時，確保 PMem Datastore 清空並刪除所有 Namespaces，此時才能將 Maintenance Mode ESXi Host 關機，待 ESXi Host 重新啟動並離開 Maintenance Mode 之後再遷移 VM 虛擬主機回來。
圖、VM 虛擬主機使用 vNVDIMM 儲存資源
圖片來源：  vSphere 6.7 Core Storage - PMem (Persistant Memory) NVDIMM support in vSphere

圖、ESXi Host 進入維護模式，PMem / NVDIMM 儲存資源必須清空
圖片來源：  vSphere 6.7 Core Storage - PMem (Persistant Memory) NVDIMM support in vSphere





參考資源






VMware vSphere 6.7 攻略 - 系列文章

↧

[站長開講] OpenInfra Days Taiwan 2018

July 19, 2018, 9:08 pm
$
0
0

活動簡介

台灣開源領域每年一度的盛會 OpenStack Day Taiwan，從 2018 年即將呈現一個嶄新的面貌— “OpenStack” 蛻變為 ”OpenInfra”！

過去，OpenStack 開源架構在雲端世界成長茁壯、成果輝煌。 現在，OpenInfra 將承襲 OpenStack 精神與架構，涵括更廣泛的開源技術夥伴。 在 OpenInfra Days Taiwan 2018活動中，將以「開放架構的智慧、技術融合的創新」為核心，聚焦多雲架構與佈署、容器開發、分散式儲存、軟體定義等議題。並針對 AI、邊緣運算、5G 物聯網等領域，進行案例分享與技術交流，期望為台灣產業及新創領域帶來無限擴展的可能方向！





活動資訊

  • 日期： 2018 年 8 月 7 日 (星期二)
  • 時間： 9:00 ~ 17:00
  • 地點： 南港展覽館 5樓(台北市南港區經貿二路1號)
  • 報名： 活動報名





活動內容


↧
↧

CentOS 7.5 安裝 Docker 18.06 容器環境

August 9, 2018, 2:48 am
$
0
0


前言

簡單來說，「Docker」本來是 dotCloud公司內部的一個業餘專案，並採用 Google 的 Go 語言進行實作的產品。後來 dotCloud 公司將此專案加入 Linux 基金會並在 GitHub 上進行維護，迅速受到開發人員的喜愛，甚至 dotCloud 公司改名為 Docker Inc。


有關 Docker 的一些歷史及觀念介紹因為《Docker — 從入門到實踐­》已經很清楚的說明，請參考下列相關連結即可：

Docker 簡介
         什麼是 Docker
          為什麼要使用 Docker？
Docker 基本概念
          映像檔 (Image)
          容器 (Container)
          倉庫 (Repository)
Docker 底層技術
          基本架構
          命名空間 (NameSpaces)
          控制組 (Control Groups)
          Union 檔案系統 (Union File Systems)
          容器格式
          網路


那麼讓我們開始玩 Docker 吧，以下是其它的一些重點摘要：
  • 在開始玩 Docker Lab 之前，建議註冊 Docker Hub、GitHub等帳號以便後續實作。
  • Container 目前尚未支援如 VM 的快照功能，但 Container 建立產生快速所以原則上並不需要快照功能。
  • Container 是指 Running 時的狀態，若是靜態的話則稱之為 Images。
  • Container 的概念，就是每個「服務」個別打包成「1 個」Container，例如，過往的 LAMP 在 Container 的運作概念中，就是分拆成 Apache Container, MySQL Container, PHP Container。





OS 需求

為了方便進行 Docker 環境的測試作業，我採用 Microsoft Azure 建立 CentOS 7.5 虛擬主機。因為本文並非著重於 Microsoft Azure 議題，所以如何建立 CentOS 虛擬主機就不多說明了。

在 CentOS 運作環境中，為了確保可以順利安裝及執行 Docker 容器環境，請確認採用「CentOS 7 - 64 位元」版本。首先，透過「uname -a」指令確認目前採用的 Linux 版本為 64 位元，接著執行「cat /etc/redhat-release」 指令，從執行結果中可以看到版本為 CentOS 7.5  符合 Docker 容器環境運作要求。






安裝 Docker 容器環境

完整且詳細的作法，請參考 Docker 官網提供的正規作法 Get Docker for CentOS - Docker。因為在 CentOS 7 版本中「CentOS-Extras」庫存中已經內建 Docker 套件，所以只要執行「sudo yum -y install docker」便可以安裝完成 (但是，你將會發現所安裝的 Docker 並非最新版本的 Docker，例如，目前最新為 18.06 但是透過 CentOS-Extras 所安裝則是舊版的 1.13)。


所以，本文還是採用最簡單並取得最新 Docker 版本的安裝方式透過 curl 指令去安裝。並且，從 CentOS 7 開始，管理服務的部分已經從傳統的 Runlevel (/etc/rc.d/init.d)，改為新一代的「systemd  (/etc/systemd/system)」，所以在安裝作業完成後，我們使用「systemctl start docker」指令來啟動 docker 服務，接著透過「systemctl enable docker」設定 CentOS 主機重新啟動後，仍然能夠自動啟動 docker 服務。接著，我們仍可以透過傳統的「ps aux |grep docker」來確認 Docker Daemon 是否啟動，或採用新一代的指令「systemctl status docker」來確認目前 Docker Daemon 的執行狀態、PID……等資訊。

$ sudo yum -y update
$ sudo curl -sSL https://get.docker.com | sh
$ sudo systemctl enable docker
$ sudo systemctl start docker
$ sudo ps aux |grep docker
$ sudo systemctl status docker

請執行下列指令，將實作的使用者帳戶 (weithenn)加入到「docker」群組當中，避免後續執行 docker client 指令都還要打 sudo。完成後，確認 dockerlab 這個使用者帳號已經加入到 docker 群組當中後，記得「登出再登入」以便套用生效。
$ sudo usermod -aG docker $(whoami)
$ sudo grep "docker:" /etc/group
exit





基礎操作

透過「docker info」可以查看 Docker 容器環境的運作資訊，例如，Server Version: 18.06.0-ce。


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






永遠的範例 Hello-World

那麼，讓我們開始使用 Docker 容器環境吧，不免俗的第 1 個範例就是透過 Docker 容器環境執行列出字串「Hello-World」吧。

其實在執行「docker run hello-world」指令後，在第 1 行資訊中 (Unable to find image 'hello-world:latest' locally) 可以看到，系統發現目前並沒有「Hello-World」這個 Images，所以就透過預設的系統設定去 Docker Hub 下載 Hello-World 這個容器映像檔 (所以自動執行「docker pull」的動作)，最後執行它。其實在結果中看到回應的 4 點訊息，已經完全說明這個動作的流程。
$ docker run hello-world

接著，可以透過「docker images」查看目前系統中的 Docker Images 清單。此外，你也可以觀察一下 Docker Images 的預設資料夾「/var/lib/docker/*」下相關的變化。 初步練習就先到這裡，後續再慢慢深入吧。  💪






參考資源

↧

CentOS 7.5 安裝 OpenStack Queens

August 13, 2018, 2:00 am
$
0
0

前言

本文為日前在 OpenInfra Days Taiwan 2018大會上，進行線上實際展示的 SOP 實作內容，有興趣的朋友可以參考看看，或參考 OpenStack Docs: Kolla-Ansible Quick Start 官方文件說明。

簡單來說，我們可以透過 OpenStack 中的 Kolla Project，透過 Kolla / Kolla-Ansible將 OpenStack 運作元件打包成 Container的方式，然後搭配 Ansible 進行自動化佈署的動作，達到快速佈建 OpenStack Queens運作環境的目的。





建立支援 Nested Virtualization 的 CentOS  7.5 虛擬主機

本文，將實作在 CentOS 7.5 主機中安裝 OpenStack Queens 運作環境，當然這台 CentOS 7.5 主機可以在「地端」也可以在「雲端」環境中。值得注意的是，這台 CentOS 7.5 主機必須要支援「巢狀式虛擬化技術」(Nested Virtualization)，屆時才能順利建立 OpenStack Queens運作環境。

有關地端主機啟用 Nested Virtualization 機制的詳細資訊，請參考站內文章 網管人雜誌 133 期 - 實作 Hyper-V 巢狀虛擬化測試研發效率大提升。

圖、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖
圖片來源： Virtualization Blog - Windows Insider Preview： Nested Virtualization

有關 Microsoft Azure 雲端主機啟用 Nested Virtualization 機制的詳細資訊，請參考站內文章 ASDK Journey (2) - 實戰 Azure Stack Development Kit on Azure。

圖、Nested Virtualization in Azure
圖片來源： Nested Virtualization in Azure | Blog | Microsoft Azure

在 Microsoft Azure雲端環境中，需要支援 CentOS 7.5主機啟用 Nested Virtualization 機制時，請記得選擇的 VM 虛擬主機必須是「Dv3 或 Ev3」系列才行。舉例來說，本文採用 D16s v3系列的 VM 虛擬主機。

由於本文並非著重於 Microsoft Azure 議題，所以如何建立 CentOS 虛擬主機就不詳述。請透過下列的 Azure CLI 指令，先在東南亞的資料中心建立資源群組，然後再建立具備 Nested Virtualization 機制的 CentOS 7.5 虛擬主機，並且給予「kollaopenstackqueens.southeastasia.cloudapp.azure.com」的 DNS 名稱，以便屆時方便登入 OpenStack Horizon 頁面。
# Create Resource Group in Azure SouthEast Asia DataCenter
$ az group create --name RG-KollaDemo --location southeastasia

# Create CentOS 7.5 Virtual Machine
$ az vm create \
--resource-group RG-KollaDemo \
--name Kolla-OpenStackQueens \
--image OpenLogic:CentOS:7.5:latest \
--size Standard_D16s_v3 \
--public-ip-address-dns-name kollaopenstackqueens \
--admin-username weithenn \
--admin-password OpenInfraDaysTaiwan2018

# Open CentOS 7.5 NSG port 80 traffic
$ az vm open-port --port 80 --resource-group RG-KollaDemo --name Kolla-OpenStackQueens

圖、在 Azure 東南亞資料中心建立資源群組

圖、建立 CentOS 7.5 虛擬主機

圖、組態設定 CentOS 7.5 虛擬主機的 NSG 允許 Port 80 流量





CentOS 7.5 基礎設定

有關 CentOS 的基礎設定就不再贅述，有興趣的朋友可以參考站內文章 CentOS 7.4 攻略 - 基礎設定系列文章。順利建立 CentOS 虛擬主機可以透過 SSH 登入，也可以從 Azure Cloud Shell進行登入 (但是，必須注意 20 分鐘 Idle 自動登出的情況)：
$ : > /home/weithenn/.ssh/known_hosts
$ ssh weithenn@kollaopenstackqueens.southeastasia.cloudapp.azure.com
$ sudo yum -y update
$ curl -sSL https://get.docker.com | sh
$ systemctl start docker
$ systemctl enable docker
$ usermod -aG docker $(whoami)
$ docker version

圖、透過 Azure Cloud Shell 登入 CentOS 7.5 主機進行操作

事實上，採用 Kolla-Ansible也會自動幫 CentOS 主機安裝 Docker，只是會採用舊版的 Docker 1.13，所以我先手動幫 CentOS 主機安裝最新版本的 Docker 18.06。有關 CentOS 安裝 Docker 的詳細作法，請參考站內文章 CentOS 7.5 安裝 Docker 18.06 容器環境。

圖、CentOS 7.5 主機安裝最新版本 Docker 18.06





安裝 Ansible 及相關 Dependencies

請執行下列相關指令，以便為 CentOS 7.5 主機安裝 Ansible及 Dependencies，其它詳細資訊請參考 OpenStack Docs: Quick Start - Install dependencies官方文件。
$ yum -y install epel-release
$ yum -y install python-pip
$ pip install -U pip
$ yum -y install python-devel libffi-devel gcc git openssl-devel libselinux-python
$ yum -y install ansible
$ pip install -U ansible

圖、安裝 Ansible 及相關 Dependencies

接著，修改 Ansible 組態設定檔「/etc/ansible/ansible.cfg」，在 [defaults]下加上 3 個參數選項。
[defaults]
host_key_checking=False
pipelining=True
forks=300

圖、修改 Ansible 組態設定檔





安裝及組態設定 Kolla-Ansible

請執行下列相關指令，以便為 CentOS 7.5 主機安裝 Kolla-Ansible。其它詳細資訊請參考 OpenStack Docs: Quick Start - Install Kolla-ansible官方文件。
# Install Kolla-Ansible
$ cd /opt ; git clone https://github.com/openstack/kolla-ansible -b stable/queens
$ pip install -r kolla-ansible/requirements.txt --ignore-installed
$ cd /opt/kolla-ansible ; python setup.py install

# Configuration Files: global.yml, passwords.yml
$ cp -r /opt/kolla-ansible/etc/kolla /etc/kolla/

# Inventory Files: all-in-one, multimode
$ cp /opt/kolla-ansible/ansible/inventory/* /etc/kolla/

圖、為 CentOS 7.5 主機安裝 Kolla-Ansible

預設情況下，記錄各項 OpenStack 運作元件的密碼為空值，在測試環境中我們可以使用指令「kolla-genpwd」快速產生各項隨機密碼，在本文實作環境中將稍後登入 Horizon 密碼修改為「OpenInfraDaysTaiwan2018」。其它詳細資訊請參考 OpenStack Docs: Quick Start - Kolla Passwords官方文件。
# Generator Kolla passwords - /etc/kolla/passwords.yml
$ kolla-genpwd
$ vi /etc/kolla/passwords.yml
keystone_admin_password: OpenInfraDaysTaiwan2018

圖、手動指定 OpenStack Horizon 登入密碼

接著，調整 Kolla-Ansible 的通用組態設定檔「/etc/kolla/globals.yml」，請依照你的運作環境進行相對應的調整，其它詳細資訊請參考 OpenStack Docs: Quick Start - Kolla globals.yml官方文件。
# Required to deploy Kolla-Ansible - /etc/kolla/globals.yml
$ cd /etc/kolla ; cp globals.yml globals.yml.orig
$ sed -i 's,#kolla_base_distro: "centos",kolla_base_distro: "centos",g' /etc/kolla/globals.yml
$ sed -i 's,#kolla_install_type: "binary",kolla_install_type: "source",g' /etc/kolla/globals.yml
$ sed -i 's,#openstack_release: "",openstack_release: "queens",g' /etc/kolla/globals.yml
$ sed -i 's,kolla_internal_vip_address: "10.10.10.254",kolla_internal_vip_address: "10.0.0.4",g' /etc/kolla/globals.yml
$ sed -i 's,#docker_registry: "172.16.0.10:4000",docker_registry: "",g' /etc/kolla/globals.yml
$ sed -i 's,#docker_namespace: "companyname",docker_namespace: "kolla",g' /etc/kolla/globals.yml
$ sed -i 's,#network_interface: "eth0",network_interface: "eth0",g' /etc/kolla/globals.yml
$ sed -i 's,#neutron_external_interface: "eth1",neutron_external_interface: "docker0",g' /etc/kolla/globals.yml
$ sed -i 's,#enable_haproxy: "yes",enable_haproxy: "no",g' /etc/kolla/globals.yml
$ egrep "^[^#]" /etc/kolla/globals.yml

圖、依照運作環境調整 OpenStack 通用組態設定檔





佈署 OpenStack Queens

前置作業完成後，接著就是重頭戲透過 Kolla-Ansible執行佈署 OpenStack Queens了，請執行下列指令進行「Bootstrap Servers」的動作，此動作大約花費 1 分鐘的時間。其它詳細資訊請參考 OpenStack Docs: Quick Start - Deployment官方文件。
# Bootstrap Servers (1 min, ok=39, changed=21)
$ kolla-ansible -i all-in-one bootstrap-servers

圖、執行 OpenStack Bootstrap Servers 的動作

圖、執行 OpenStack Bootstrap Servers 的動作

請執行下列指令進行「Pre-Deployment Checks」的動作，此動作大約花費 1 分鐘的時間。其它詳細資訊請參考 OpenStack Docs: Quick Start - Deployment 官方文件。
# Pre-deployment checks (1 min, ok=58, changed=1)
$ kolla-ansible -i all-in-one prechecks

圖、執行 OpenStack Pre-Deployment Checks 的動作

請執行下列指令進行「Download Docker Images」的動作，此動作大約花費 10 ~ 15 分鐘的時間，完成後可以看到 CentOS 主機已經下載許多 Kolla on CentOS 上的 Docker Images。其它詳細資訊請參考 OpenStack Docs: Quick Start - Deployment 官方文件。
# Download docker images (10~15 min, ok=26, changed=11)
$ kolla-ansible -i all-in-one pull
$ docker images

圖、執行 Download Docker Images 的動作

圖、確認已下載相關 Docker Images

請執行下列指令進行「OpenStack Queens Deployment」的動作，此動作大約花費 10 ~ 15 分鐘的時間，完成後可以看到啟動許多 OpenStack 運作元件容器，並且這些容器的虛擬網路都是採用 Docker Host。其它詳細資訊請參考 OpenStack Docs: Quick Start - Deployment 官方文件。
# OpenStack Queens deployment (10~15 min, ok=225, changed=141)
$ kolla-ansible -i all-in-one deploy
$ docker ps ; docker network ls ; docker volume ls
$ docker inspect mariadb | grep NetworkMode

圖、執行 OpenStack Queens 佈署作業

圖、確認相關 OpenStack 運作元件容器已運作

圖、查詢 OpenStack 運作元件容器虛擬網路及儲存資源





使用 OpenStack Queens

佈署作業完成後，便可以進行 OpenStack Queens 運作環境的初始化作業及開始使用。請開啟瀏覽器連結至「http://kollaopenstackqueens.southeastasia.cloudapp.azure.com」網址，即可看到 OpenStack Horizon Dashboard登入畫面。其它詳細資訊請參考 OpenStack Docs: Quick Start - Using OpenStack官方文件。
# Install basic OpenStack CLI clients, openrc file
$ pip install python-openstackclient python-glanceclient python-neutronclient
$ kolla-ansible post-deploy
$ . /etc/kolla/admin-openrc.sh

# Create example networks, images
$ . /opt/kolla-ansible/tools/init-runonce

# OpenStack Horizon dashboard
Horizon 網址： http://kollaopenstackqueens.southeastasia.cloudapp.azure.com
登入帳號： admin
登入密碼： OpenInfraDaysTaiwan2018

圖、OpenStack 初始化作業

圖、連結至 OpenStack Horizon 登入畫面

圖、順利登入 OpenStack Horizon 管理環境

圖、查看 OpenStack 虛擬網路環境





刪除 OpenStack Queens 測試環境

當測試作業完畢或環境玩爛需要打掉重練時，可以透過 Kolla-Ansible內建的相關管理 Script 來處理運作環境。舉例來說，執行 stop-containers可將所有容器停止運作、執行 cleanup-containers刪除停止的容器、執行 cleanup-images刪除下載的容器映像檔、執行 cleanup-host為刪除 CentOS 主機上相關組態設定。
# Destroy OpenStack Queens environment
$ docker ps
$ /opt/kolla-ansible/tools/stop-containers
$ docker ps -a
$ /opt/kolla-ansible/tools/cleanup-containers
$ docker images
$ /opt/kolla-ansible/tools/cleanup-images --all
$ /opt/kolla-ansible/tools/cleanup-host

圖、停止所有 OpenStack 運作元件容器

圖、清理所有 OpenStack 運作元件容器

圖、刪除所有 所有 OpenStack 運作元件容器映像檔

圖、清理主機上 OpenStack 相關組態設定

由於本文是在 Microsoft Azure公有雲環境上進行實作，最後也可以透過簡單的 Azure CLI 刪除整個測試環境。
# Delete Kolla OpenStack Queens environment
$ az group delete --name RG-KollaDemo --yes --no-wait
$ : > /home/weithenn/.ssh/known_hosts

圖、刪除 Azure VM 測試環境





參考資源

↧

網管人 151 期 - K8S 雲端快速試玩動手打造容器叢集

August 18, 2018, 7:10 am
$
0
0

網管人雜誌

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




文章目錄

前言
K8S（Kubernetes）是什麼？
          Kubernetes 叢集運作架構
Kubernetes 叢集實戰
          啟用 AKS 預覽功能
          建立資源群組
          建立 Kubernetes 叢集
          連線至 Kubernetes 叢集
          新增 Kubernetes 部署和服務
          擴充和縮小運作規模
          Kubernetes 儀表板
          刪除 Kubernetes 叢集環境
結語





前言

「容器」（Container）技術，在這幾年時間已經被大多數開發人員及 IT 管理人員所熟知，然而跟所有技術相同，一旦管理人員面對數量越來越多的容器及互相依存的應用程式時，便需要尋找一套方便好管理並且具備高可用性機制的「調度」（Orchestration）平台。

同時，容器調度平台已經從先前百家爭嗚的戰國時代至目前大致底定，從 Google 搜尋熱度的趨勢變化結果可以看到，在近五年的關鍵字搜尋熱度中 K8S（Kubernetes）容器管理調度平台，已經躍升為第一名並遠遠超過其它容器管理調度平台（如圖 1 所示）。

圖 1、Google 搜尋熱度的趨勢變化-容器管理調度平台
圖片來源： Google 搜尋趨勢 - Kubernetes，Docker Swarm，Apache Mesos，Openshift，OpenStack

此外，根據知名市調機構 RightScale，在最新一期的 2018 - State of the Cloud Report 調查報告結果也顯示，不管是公有雲供應商或企業及組織內使用的容器技術，雖然仍以 Docker 做為主要的容器底層技術，然而在容器管理調度平台方面則開始以 K8S（Kubernetes）為主，同時 K8S 也是成長最快速的容器調度平台（如圖 2 所示）。

圖 2、RightScale 市調統計結果，企業用於管理容器技術的優先順序
圖片來源： RightScale - 2018 State of the Cloud Report





K8S（Kubernetes）是什麼？

首先，管理人員一開始接觸 K8S（Kubernetes）容器管理調度平台時，一定對於這個技術名稱縮寫有點好奇。事實上，Kubernetes 名字起源為希臘語意思是指掌舵手或飛行員，而 K8S 的由來只是將完整的 Kubernetes 名稱中，保留「開頭 K」及「結尾 S」的英文字母，至於中間的英文字母數量剛好是「8 個英文字」，這就是 Kubernetes> K8S縮寫的由來。

簡單來說，當企業及組織的 IT 管理人員開始使用 Docker 容器技術（如圖 3 所示），並且隨著享受到 Docker 容器技術的好處後，在資料中心內的容器數量不斷成長的情況下，便需要有個方面管理及調度眾多容器的平台，而 K8S（Kubernetes）為 Google 在 2014 年進行開源的容器管理調度平台，融合 Google 多年的容器管理調度經驗，漸漸成為大家喜愛的容器管理調度平台。

圖 3、傳統部署於主機上的應用程式vs新興部署於容器中的應用程式
圖片來源： What is Kubernetes? - Kubernetes

K8S 容器調度管理平台改版速度非常快速，那麼管理人員該如何判斷新增服務是否適合企業及組織使用？ 一般來說各種新增功能的步調會是先推出「Alpha」版本，待後續推出新版 K8S 版本時視功能成熟度轉換為「Beta」版本，最後則是變成「GA」穩定版本並成為 K8S 的正式功能。

早期的 K8S 版本與其它大部分的容器調度管理平台相同，「僅」能管理 Linux 容器運作環境。然而，從 K8S 1.05 版本開始，便能夠「同時」支援 Windows 及 Linux 容器運作環境。下列項目，為 2018 年最新發佈的 K8S 1.10 版本容器調度管理平台特色功能簡介：

  • 儲存：在前一版 K8S 1.09 版本時，推出的「容器儲存介面」（Container Storage Interface，CSI）及「本機持續性磁碟區」（Local Persistent Volumes）這 2 項儲存功能為「Alpha」版本，在最新 K8S 1.10 版本中皆更新為較成熟的「Beta」版本。其中，CSI 容器儲存介面可以讓安裝 Volume Plugins 的動作就像部署 Pod 一樣簡單，並且在預設的情況下便會啟用此功能，而無須像 K8S 1.09 版本必須管理人員手動啟用此功能，至於持續性本機磁碟區機制，則是幫助管理人員輕鬆讓主機的本機磁碟區成為持續性的儲存資源供容器使用。CSI 容器儲存介面功能，預計在後續的 K8S 1.12 版本時將會成為 GA 正式版本。
  • 安全：從 K8S 1.09 版本開始，提供 CCM（Cloud Controller Manager）特色功能（如圖 4 所示），在新版 K8S 1.10 版本中則提供「外部 kubectl 憑證提供者」的「Alpha」版本功能，以便使用雲端供應商提供的 IAM 身分驗證服務。
  • 網路：提供在安裝程序中，將 DNS 服務切換為「CoreDNS」的「Alpha」版本功能。
  • 其它：從 K8S 1.10 版本開始，將「持續性磁碟區宣告」（Persistent Volume Claim，PVC）更新為 Beta版本，以便避免儲存資源因為被綁定在 Pod 中而被誤刪的情況發生。同時，在 K8S 1.10 版本中也推出新增功能 Local raw block volumes 的 Alpha 版本。

圖 4、Kubernetes - CCM（Cloud Controller Manager）運作架構示意圖
圖片來源： Kubernetes - Concepts Underlying the Cloud Controller Manager

此外，在 2016 年時 Docker 將 Runtime 主要運作元件 Containerd 以開源的方式釋出。在 2018 年 5 月時，K8S 也正式支援最新釋出的 Containerd 1.1版本，讓 Kubelet 能夠直接與 Containerd 溝通與協同運作（如圖 5 所示），有效改善 Pod 運作效能及降低啟動延遲。

圖 5、Kubernetes 正式支援 Containerd 1.1 版本運作示意圖
圖片來源： Kubernetes Blog - Kubernetes Containerd Integration Goes GA



Kubernetes 叢集運作架構

首先，在 K8S（Kubernetes）叢集運作架構中，有 ２ 種運作角色分別是「Kubernetes Master」及「Kubernetes Nodes」（如圖 6 所示），其中擔任 Master 角色的 Kubernetes 主機，將會負責協調 Kubernetes 叢集中所有管理工作任務，例如，調度應用程式、維護應用程式的期望狀態、擴充應用程式運作規模、執行滾動式更新作業……等。

至於擔任 Nodes 角色的 Kubernetes 主機，除了可以採用實體伺服器或 VM 虛擬主機之外，最主要的工作任務就是負責「運作容器」，並且都會有 Kubelet 管理程序及運作容器軟體（例如，Docker 或 rkt），同時透過代理程式及 Kubernetes API 與擔任 Master 角色的 Kubernetes 主機溝通。
在 Kubernetes 叢集運作架構中，擔任 Nodes 角色的 Kubernetes 節點主機數量，建議至少應配置「3 台」為佳。
圖 6、Kubernetes 叢集運作架構示意圖
圖片來源： Kubernetes Documentation - Using Minikube to Create a Cluster

那麼，我們來看看在 Kubernetes 叢集運作架構中，主要負責溝通協調及調度管理重任的 Kubernetes Master 主機（如圖 7 所示），以及專責運作「容器和應用程式」的 Kubernetes Node節點主機中，分別運作哪些重要的運作元件：

Kubernetes Master

  • kube-apiserver：在 Kubernetes 叢集中負責驗證及 API 的控制平台前端，主要用途為提供 Kubernetes API 與 Kubernetes Nodes 節點主機溝通運作，以及進行運作規模「水平擴充」（Scale-Out）等工作任務。
  • etcd：在 Kubernetes 叢集中，負責處理及存放所有資料的儲存資源。
  • kube-scheduler：負責監控和調度及管理 Kubernetes Node 節點主機中的 Pod 等工作任務。
  • kube-controller-manager：負責管理在 Kubernetes 叢集中各項控制器的協同運作，例如，Node Controller、Replication Controller、Endpoints Controller、Service Account & Token Controller 等。
  • cloud-controller-manager：這是從 K8S 1.06 版本開始新增的 Alpha 運作元件，以便 Kubernetes 叢集能夠與各家雲端供應商提供的控制器協同運作，例如，Node Controller、Route Controller、Service Controller、Volume Controller 等。

Kubernetes Node

  • kubelet：每台 Kubernetes Node 節點主機皆會運作此代理程式，並且在 Kubernetes 叢集中的最小單位 Pod 中運作容器及應用程式。
  • kube-proxy：當 Kubernetes Node 節點主機順利建立 Pod 並運作容器和應用程式後，接著便是透過 kube-proxy 處理網路環境進而對外提供「服務」（Service）。
  • container runtime：在 Kubernetes Node 節點主機中負責運作容器的軟體，目前 Kubernetes 支援  Docker、rkt、runc 及符合 OCI runtime-spec 規範的容器技術。

圖 7、Kubernetes 叢集運作元件架構示意圖
圖片來源： Kubernetes Documentation - Building High-Availability Clusters





Kubernetes 叢集實戰

事實上，在目前的 Windows Server 2016 運作環境中，倘若要建置 Kubernetes 叢集仍然相對複雜，舉例來說，必須要採用 Windows Server 2016（1709 版本），才能夠支援運作 Kubernetes 1.09 版本。

此外，雖然 Kubernetes 叢集可以同時運作及管理 Windows 和 Linux 容器，但是擔任 Kubernetes Master 角色的主機，目前仍然「僅支援 Linux 作業系統」進行建構及運作相關元件的工作任務。
請注意，Windows Server 2016 RTM 為 1607版本，並未支援建構 Kubernetes 1.09 叢集環境。此外，微軟預計在 2018 下半年度推出 Windows Server 2019 雲端作業系統，將會對於 Kubernetes 叢集環境有更高的支援度及整合度。
因此，本文為避免 Kubernetes 初學者，在建構 Kubernetes 叢集環境時便遭遇太大的困難，所以本文實作環境將在 Microsoft Azure 公有雲環境，透過 AKS（Azure Kubernetes Service）機制快速建構 Kubernetes 叢集環境，並且建立 Pod 並運作容器和應用程式。
事實上，微軟 Azure 公有雲一開始推出的容器服務為 ACS（Azure Container Service），並同時支援 Docker Swarm、Mesosphere DC/OS、Kubernetes 等多種容器管理調度平台。然而，容器管理調度平台已經大勢底定以 Kubernetes為首選，所以在 2017 年 10 月微軟將 ACS 容器服務，改名為 AKS並專注於 Kubernetes管理平台。



啟用 AKS 預覽功能

在本文撰寫階段微軟 Azure 公有雲中，專注於 Kubernetes 叢集的 AKS（Azure Kubernetes Service）服務仍處於「預覽」（Preview）階段。因此，管理人員在建立 Kubernetes 叢集之前，請先透過 Azure Cloud Shell 或 Azure CLI執行啟用「Azure 服務提供者」（Azure Service Providers）的動作，以便啟用 AKS 預覽機制。
Microsoft AKS 於 2018 年 6 月 13 日正式 GA，詳細資訊請參考 Azure Kubernetes Service (AKS) GA – New regions, more features, increased productivity | Blog | Microsoft Azure。

如圖 8 所示，請透過「az provider register」指令啟用相關 Azure 服務提供者，以便順利啟用 AKS 預覽機制，後續才能夠快速且順利的建構 Kubernetes 叢集架構。

圖 8、執行 az provider register 指令啟用相關 Azure 服務提供者



建立資源群組

請執行「az group create」指令，在 Microsoft Azure 公有雲環境中建立「資源群組」（Resource Group）。值得注意的是，由於目前的 AKS 服務仍處於預覽階段，所以全球只有部分的資料中心支援此服務，目前僅加拿大中部（canadacentral）、加拿大東部（canadaeast）、美國中部（centralus）、美國東部（eastus）、西歐（westeurope）等五座資料中心支援 AKS 預覽服務。

如圖 9 所示，執行「az group create --name RG-USEast --location eastus」指令後，將會指定在「美國東部」（eastus）的資料中心內，建立名稱為「RG-USEast」的資源群組。

圖 9、指定在美國東部資料中心內建立名稱為 RG-USEast 的資源群組



建立 Kubernetes 叢集

請執行「az aks create」指令以便建立 Kubernetes 叢集，在下列所執行的「az aks create --resource-group RG-USEast --name K8SCluster --node-count 3 --generate-ssh-keys」指令中，將會在剛才於美國東部資料中心內所建立的 RG-USEast 資源群組中，建立名稱為「K8SCluster」的 Kubernetes 叢集。

此外，在這個 Kubernetes 叢集當中，將會建立「1 台」擔任管理和調度角色的 Kubernetes Master 主機，以及建立「3 台」擔任運作容器和應用程式角色的 Kubernetes Node 節點主機（如圖 10 所示）。
在本次實作環境中，執行建立指令約 15 分鐘後 Kubernetes 叢集便建立完成。

圖 10、建立具備 1 台 Master 主機及 3 台 Node 節點主機的 Kubernetes 叢集



連線至 Kubernetes 叢集

現在，管理人員可以開始透過 kubectl 這個 Kubernetes 用戶端指令來管理 Kubenetes 叢集。首先，請執行「az aks get-credentials」指令以便下載憑證並組態設定 Kubernetes CLI 以便使用，在下列所執行的「az aks get-credentials --resource-group RG-USEast --name K8SCluster」指令中，將會於美國東部資料中心內 RG-USEast 資源群組中，所建立的 K8SCluster 的 Kubernetes 叢集下載憑證。
倘若，未正確下載驗證 Kubernetes 叢集憑證的話，屆時嘗試查詢 Kubernetes 叢集節點主機資訊時，將會出現 Unable to connect to the server 及 no such host 的錯誤資訊。

順利通過 Kubernetes 叢集驗證程序後，便可以執行「kubectl get nodes」指令，列出 Kubernetes 叢集中 Node 節點主機資訊。如圖 11 所示，可以看到在 Kubernetes 叢集共有 3 台 Node 節點主機，並且採用 K8S v1.9.6 版本。
倘若，採用的 Azure CLI 指令工具無法順利執行 kubectl 指令，請執行「az aks install-cli」指令進行安裝即可。
圖 11、下載 Kubernetes 叢集驗證用途的憑證後，接著查詢 Node 節點主機資訊



新增 Kubernetes 部署和服務

在 Kubernetes 叢集運作架構中，建立容器與執行應用程式的方式與管理 Docker 容器大同小異。在本文實作環境中，我們將會先建立 1 個名稱為「azure-vote.yaml」的資訊清單檔案，在這個 YAML 檔案中將會定義使用的容器及相關物件，在「Kubernetes 部署」（K8S Deployments）的部份將會部署 2 個，首先是用於投票用途的 Python 應用程式，另 1 個則是快取用途的 Redis 執行個體。

Kubernetes 部署的部分宣告完畢後，接著在「Kubernetes 服務」（K8S Services）的部份也是 2 個，首先是負責外部服務投票用途的 Python 應用程式為前端（服務名稱為 azure-vote-front），至於快取用途的 Redis 執行個體則會後端（服務名稱為 azure-vote-back）。

下列為 azure-vote.yaml 檔案內容，詳細資訊請參考 Quickstart - Azure Kubernetes cluster for Linux | Microsoft Docs官方文件內容。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      containers:
      - name: azure-vote-back
        image: redis
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      containers:
      - name: azure-vote-front
        image: microsoft/azure-vote-front:v1
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

完成 azure-vote.yaml 資訊清單檔案的編寫作業後，便可以執行「kubectl apply -f azure-vote.yaml」指令採用剛才定義的 azure-vote.yaml 檔案，進行 Kubernetes 部署及新增服務的工作任務。如圖 12 所示，可以看到 Kubernetes 叢集順利新增 2 項 Kubernetes 部署及 Kubernetes 服務，名稱分別是 azure-vote.yaml 資訊清單檔案內，所定義的 azure-vote-front 及 azure-vote-back。

圖 12、Kubernetes 叢集順利新增 2 項 Kubernetes 部署及 Kubernetes 服務

負責外部服務的前端 Python 應用程式建立後，我們可以執行「kubectl get service azure-vote-front --watch」指令，來即時觀察前端 Python 應用程式的運作狀態。一開始執行時，可以看到負責外部服務的 IP 位址欄位「EXTERNAL-IP」狀態為「pending」（如圖 13 所示），表示此時 Kubernetes 叢集仍在初始化 azure-vote-front 服務中，稍待片刻便可以看到欄位狀態轉變為「外部 IP 位址」（本文實作環境為 40.121.14.165）。
當 azure-vote-front 前端服務順利初始化完成取得外部 IP 位址之後，便可以使用「Ctrl + C」組合鍵中斷即時監看狀態。
圖 13、確認前端 Python 應用程式的運作狀態，是否已經能夠對外提供服務

此時，便可以開啟瀏覽器鍵入剛才前端 Python 應用程式的外部 IP 位址，來驗證範例用途的投票應用程式是否已經能夠對外提供服務。如圖 14 所示，皆可以順利執行投票作業並且重置投票結果。

圖 14、透過瀏覽器驗證範例用途的投票應用程式是否已經能夠對外提供服務



擴充和縮小運作規模

隨著時間的推移，企業及組織在 Kubernetes 叢集中所建立及運作的容器和應用程式，有可能需要因為專案需求或其它因素而擴充或縮小運作規模，Kubernetes 叢集提供非常簡便且線上不中斷的方式，讓管理人員可以隨時擴充或縮小 Node 節點主機數量，或者是運作容器及應用程式的 Pods 數量。

舉例來說，在本文的實作環境中 Kubernetes 叢集內有「3 台」Node 節點主機，管理人員可以透過「az aks scale --resource-group RG-USEast --name K8SCluster --node-count 8」指令，將 Kubernetes 叢集內原有的 Node 節點主機，擴充為「8台」節點主機的運作規模，完成後再次執行「kubectl get nodes」指令查詢 Kubernetes 叢集中 Node 節點主機資訊（如圖 15 所示）。
倘若，需要縮小 Node 節點主機運作規模，只需要調整「--node-count」參數的數值即可。

圖 15、擴充 Kubernetes 叢集 Node 節點主機的運作規模

除了擴充及縮小 Kubernetes 叢集中 Node 節點主機運作規模之外，也支援擴充和縮小運作容器和應用程式的 Pod 。舉例來說，剛才所部署的 azure-vote-front 前端及 azure-vote-back 後端，都只有「1 個 Pod」而已，同樣的管理人員可以透過「kubectl scale --replicas=5 deployment/azure-vote-front」指令，將 Pod 數量由原本的 1 個擴充為「5 個Pod」，完成後再次執行「kubectl get pods」指令查詢 Kubernetes 叢集中 Pod 資訊（如圖 16 所示）。
倘若，需要縮小 Pod 運作規模，只需要調整「--replicas」參數的數值即可。
圖 16、擴充 Kubernetes 叢集 Pod 的運作規模

除了管理人員手動調整 Pod 的運作規模之外，Kubernetes 叢集還支援根據資源使用量，例如，CPU 使用率達到指定的門檻值後「自動」擴充 Pod 的運作規模。舉例來說，管理人員可以透過「kubectl autoscale deployment azure-vote-front --cpu-percent=50 --min=3 --max=10」指令，指定當 CPU 使用率「超過 50%」時，Kubernetes 叢集便自動擴充 Pod 的運作規模最多新增至「10 個 Pod」，倘若沒什麼工作負載時 Kubernetes 叢集便縮小 Pod 的運作規模最小至「3 個 Pod」。

如圖 17 所示，可以看到剛才手動擴充 Pod 的運作規模至「5 個 Pod」，然而組態設定自動調整 Pod 運作規模機制後，透過「kubectl get hpa」指令可以看到，因為 CPU 工作負載低於 50% 的門檻值，所以 Kubernetes 叢集便自動縮小 Pod 運作規模至最小的「3 個 Pod」。

圖 17、組態設定 Kubernetes 叢集自動調整 Pod 的運作規模



Kubernetes 儀表板

至此，我們已經成功建構 Kubernetes 叢集運作環境，並且部署容器及範例用途的投票應用程式。最後，管理人員可以透過 Kubernetes 叢集內建提供的儀表板功能，輕鬆監控 Kubernetes 叢集各項運作元件及容器的健康情況。

請執行「az aks browse --resource-group RG-USEast --name K8SCluster」指令，那麼系統便會在 CLI 主機與 Kubernetes API 之間建立 Proxy（如圖 18 所示）。

圖 18、執行 CLI 主機與 Kubernetes API 之間建立 Proxy 的動作

如圖 19 所示，系統將會自動開啟 CLI 主機的瀏覽器後，透過與 Kubernetes API 之間建立的 Proxy 連結至 Kubernetes 儀表板。除了透過 Kubernetes 儀表板監看 Kubernetes 叢集工作負載，例如，Kubernetes 部署、Kubernetes 服務、Pods、Replica Sets……等，也可以透過 Kubernetes 儀表板部署容器及應用程式。

圖 19、透過 Kubernetes 儀表板監看 Kubernetes 叢集工作負載



刪除 Kubernetes 叢集環境

最後，當管理人員不再測試 Kubernetes 叢集環境功能，希望能夠刪除 Kubernetes 時，只要執行「az group delete --name RG-USEast --yes --no-wait」指令，便可以一次刪除整個 Kubernetes 叢集環境，包含 Kubernetes 部署、Kubernetes 服務、Pods……等。





結語

透過本文的說明及實作練習，管理人員應該能夠感受到建構 Kubernetes 叢集運作環境後，能夠很容易的線上擴充或縮減容器的運作規模，同時在容器因為任何因素而停止運作時，Kubernetes 叢集也將會自動產生新的容器，確保容器所提供服務具備高可用性，以幫助企業及組織降低維運成本，同時也能降低資料中心維運人員的管理負擔。
↧
Viewing all 590 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>