網管人 157 期 - 借力 SMS 遷移無難事新舊系統順利交接帳戶 IP

March 8, 2019, 9:17 am

≫ Next: [站長開講] Windows Server 2019 成就多雲資料中心現代化

≪ Previous: Storage Replica 使用 100GbE iWARP RDMA 運作效能

網管人雜誌

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

文章目錄

前言
SMS 基礎運作架構
SMS 遷移工作流程
SMS 安全性需求
實戰 SMS 遷移機制
前置作業、準備 WAC 及協調流程伺服器
SMS 遷移步驟 1、建立 SMS 遷移工作任務
SMS 遷移步驟 2、傳輸資料至目的地伺服器
SMS 遷移步驟 3、目的地伺服器接手電腦帳戶及 IP 位址
驗證是否順利接手
結語

前言

雖然，微軟最新 Windows Server 2019雲端系統已經於 2018 年 10 月正式發佈，但是由業界知名的 Spiceworks 網站統計結果來看，企業及組織中仍舊有許多 Windows Server 2003 R2、Windows Server 2008 R2、Windows Server 2012 R2……等作業系統還在服役中（如圖 1 所示）。

請注意!! Windows Server 2003 R2作業系統延伸支援服務早已經於 2015 年 7 月 14 日結束支援，而 Windows Server 2008 R2作業系統也預計於 2020 年 1 月 14 日結束支援。

圖 1、企業及組織地端資料中心內採用的作業系統比例示意圖

圖片來源： Spiceworks - 2016 Server OS Market Share and Virtualization Trends

因此，企業及組織中的 IT 管理人員，或許對於 Windows Server 2019 雲端作業系統新增的各項特色功能或增強機制感到滿意並希望能夠嘗試導入，但是如何將舊有作業系統輕鬆且快速移轉至 Windows Server 2019 雲端作業系統上繼續運作，卻往往令 IT 管理人員頭痛不已甚至卻步。

本文將深入剖析及實作演練，期望幫助 IT 管理人員能夠輕鬆透過 SMS（Storage Migration Service）遷移機制，將 Windows Server 2003 R2、Windows Server 2008 R2、Windows Server 2012 R2……等舊有作業系統，轉移至新式 Windows Server 2016 或 Windows Server 2019 雲端作業系統中，而無須再花費心力維護老舊失修的作業系統。

SMS 基礎運作架構

在開始使用 SMS（Storage Migration Service）遷移機制之前，我們必須先了解整個 SMS 機制的基礎運作架構，才能讓後續的遷移作業得以順利且快速的移轉完成。

在 SMS 基礎運作架構中，將有 4 個工作角色分別是「Source Server、Destination Server、Orchestrator Server、Windows Admin Center」：

Source Server：來源端伺服器，也就是管理人員希望進行「遷移」（Migrate）工作任務的舊有主機，支援的作業系統版本為 Windows Server 2003 / 2003 R2 / 2008 / 2008 R2 / 2012 / 2012 R2 / 2016 / 2019 。
Destination Server：目的地伺服器，通常是管理人員希望移轉工作任務的新版主機，支援的作業系統版本為Windows Server 2012 R2 / 2016 /2019。一般來說目的地伺服器的 Windows Server 作業系統版本通常較新，但 SMS 機制也支援來源端伺服器採用新版 Windows Server 2019 作業系統版本，遷移至 Windows Server 2012 R2 / 2016 相較之下較舊的作業系統版本，只是必須要注意的是雖然遷移後應用程式或服務仍可正常運作，但是執行效能可能會減少 50% 。
Orchestrator Server：協調流程伺服器，必須運作在 Windows Server 2019 作業系統版本中，倘若遷移工作任務繁多時建議採用單獨的協調流程伺服器以確保遷移流程順暢無誤。
Windows Admin Center：WAC 管理主控台，管理人員必須在 WAC 管理頁面中安裝及啟用 SMS 機制，值得注意的是必須採用 WAC 1809 或後續版本才支援安裝及啟用 SMS 遷移機制。

圖 2、SMS 遷移機制基礎運作架構示意圖

圖片來源： Microsoft Docs - Storage Migration Service overview

SMS 遷移工作流程

了解上述 SMS 機制 4 種不同的工作角色之後，接著便是了解整個 SMS 遷移工作流程。事實上， SMS 遷移流程非常簡要快速並且只需要下列 3 項工作任務流程即可：

Inventory Servers：當管理人員為 WAC 管理主控台安裝及啟用 SMS 遷移機制後，便可以執行「Add and scan devices」的動作，也就是告訴 SMS 遷移機制準備轉換的「來源端伺服器」（Source Server）是哪台主機，指定後 SMS 遷移機制便會進行掃描作業，例如，該台來源端伺服器有幾個磁碟機、磁碟機儲存空間大小、磁碟機儲存空間使用情況 …… 等。完成來源端伺服器的掃描及檢查作業後，接著針對「目的地伺服器」（Destination Server）進行 SMS 遷移機制掃描作業，例如，確認該台目的地伺服器有幾個磁碟機、磁碟機儲存空間大小、磁碟機儲存空間使用情況……等。
Transfer（Copy）：由於在上一個工作流程中 SMS 遷移機制，已經掃描及檢查完成來源端伺服器及目的地伺服器的儲存資源結構，所以在這個工作流程中將開始針對來源端伺服器，將指定的檔案「傳輸/複製」（Transfer / Copy）至目的地伺服器中。
Cut over to the new servers：這是 SMS 遷移機制的最後一項工作流程，當完成由來源端伺服器傳輸複製檔案至目的地伺服器後，此時 SMS 遷移機制會進行由目的地伺服器接管來源端伺服器的動作，也就是由目的地伺服器接手來源端伺服器在 Windows 網域中的「電腦帳戶」（Computer Account）及「IP 位址」（IP Address），以便使用者端能夠無須更改任何組態設定便可以直接存取原有的服務，並且 SMS 遷移機制在確認目的地伺服器接手作業完成後，會將來源端伺服器進入維護狀態。

SMS 安全性需求

在 SMS 遷移機制運作架構及工作流程中，必須進行檔案傳輸複製作業以及電腦帳戶和 IP 位址的接管作業。因此，管理人員在實作前務必要滿足來源端伺服器及目的地伺服器的相關安全性需求：

管理者帳號權限：由於屆時目的地伺服器將會接手原本來源端伺服器的電腦帳戶，因此管理人員除了必須具備來源端及目的地伺服器的管理者帳號權限之外，當然也必須擁有 Windows 網域管理權限才行。
協調流程伺服器：擔任協調流程伺服器角色的主機，必須在主機防火牆規則中啟用「Inbound – File and Printer Sharing（SMB-In）」並允許相關網路流量能夠通過。雖然，當 Windows Server 2019 主機安裝 Storage Migration Service Proxy Service 後，系統便會自動為 Windows Server 2019 主機開啟該防火牆規則，但是管理人員應該在安裝服務完成後再次檢查確認防火牆規則是否開啟，以避免屆時 SMS 遷移作業因為防火牆規則未正確運作產生錯誤而中斷遷移作業。
來源端 / 目的地伺服器：管理人員在進行 SMS 遷移作業之前，必須確保來源端 / 目的地伺服器是否已經啟用「File and Printer Sharing（SMB-In）、Netlogon Service（NP-In）、Windows Management Instrumentation（DCOM-In）、Windows Management Instrumentation（WMI-In）」防火牆規則並放行相關網路流量，否則將會影響屆時的 SMS 遷移作業。
處於同一網域：雖然，在技術上可以達成跨網域進行 SMS 遷移作業，但是在進行接手作業時來源端伺服器與目的地伺服器，仍必須處於「同一網域」運作環境中才能夠順利進行切換及接手作業。

實戰 SMS 遷移機制

了解 SMS 遷移機制的運作架構、工作原理、安全性需求後，那麼我們便可以實作演練 SMS 遷移機制。在本文實作演練環境中，我們將一台原本由 Windows Server 2012 R2伺服器主機運作的 IIS 網頁服務（來源端伺服器），透過 SMS 遷移機制將 IIS 網頁相關檔案傳輸及複製至 Windows Server 2019 主機（目的地伺服器），然後進行電腦帳戶及 IP 位址的接手作業，最後由使用者端驗證是否無須進行任何修改便能存取由新的 Windows Server 2019 主機，存取原本由 Windows Server 2012 R2 主機所提供的 IIS 網頁服務。

前置作業、準備 WAC 及協調流程伺服器

在開始進行來源端 / 目的地伺服器的 SMS 遷移工作任務之前，我們先準備 WAC 管理主控台及協調流程伺服器，由於本文為小型的 SMS 遷移機制實作演練環境。因此，由「同一台」Windows Server 2019 主機，同時擔任 WAC 管理主控台及協調流程伺服器的角色。

實務上，倘若 SMS 遷移工作任務繁多時，建議採用單獨的協調流程伺服器以確保遷移流程工作效率。

首先，請為 Windows Server 2019 主機安裝目前最新的「Windows Admin Center 1809」版本，安裝作業完成後請確認 Windows Server 2019 系統服務中，是否多出「Windows Admin Center」項目並且為「Running」的運作狀態（如圖 3 所示），同時 Windows Server 2019 主機是否也開啟 WAC 預設採用的「Port 443」連接埠。

有關 Windows Admin Center 安裝及使用的詳細資訊，請參考本刊《第 153 期–新版 WAC 免費易用輕鬆管理主機和容錯移轉叢集》。

圖 3、WAC 安裝完成後 Windows Server 2019 主機是否運行 Windows Admin Center 系統服務

確認 Windows Server 2019 主機，順利安裝及運行 Windows Admin Center 系統服務後，便可以透過瀏覽器登入 WAC 管理介面，並請切換到 Windows Admin Center 設定中 Extensions 頁面，確認是否有「Windows Server Storage Migrations Service」項目（如圖 4 所示）。

請注意!! 必須採用最新釋出的 Windows Admin Center 1809或後續版本，才支援使用 Storage Migrations Service。

圖 4、確認是否有 Windows Server Storage Migrations Service 擴充模組項目

確認具備 Windows Server Storage Migrations Service 擴充模組後，請依序點選「Server Manager > WAC Host > Storage Migration Service」項目，然後按下 Install 鈕為該台 Windows Server 2019 主機安裝 Storage Migration Service ，安裝作業完成後便能夠看到 Storage Migration Service 儀表板內容，例如，Inventory、Transfer、Cutover 等相關工作任務數量（如圖 5 所示）。

圖 5、為 Windows Server 2019 主機安裝 Storage Migration Service

SMS 遷移步驟 1、建立 SMS 遷移工作任務

在開始進行 SMS 遷移工作任務之前，倘若你的「目的地伺服器」為 Windows Server 2019 作業系統版本的話，請為 Windows Server 2019 主機安裝「Storage Migration Service Proxy」伺服器功能，因為此舉可以讓屆時 SMS 遷移工作流程中，在進行傳輸及複製檔案作業時有效縮短至少「50 %」的傳送時間。

請在 Windows Server 2019 主機中開啟伺服器管理員，然後依序點選「Manage > Add Roles and Features > Features」項目後，勾選「Storage Migration Service Proxy」伺服器功能項目進行安裝（如圖 6 所示）。

圖 6、為目的地伺服器安裝 Storage Migration Service Proxy 伺服器功能以加快傳輸速度

在新增 SMS 遷移工作任務之前，請再次確認來源端 / 目的地伺服器是否已經啟用及放行下列 4 項防火牆規則，否則稍後的 SMS 遷移工作任務將會因為被防火牆阻擋而發生錯誤造成遷移作業中斷：

File and Printer Sharing（SMB-In）
Netlogon Service（NP-In）
Windows Management Instrumentation（DCOM-In）
Windows Management Instrumentation（WMI-In）

請切換到 WAC 管理主控台的 Storage Migration Service 頁面中，按下「New job」建立 SMS 遷移工作任務並給予名稱，在本文實作環境中建立的工作任務名稱為「WS2012IISto2019」，在「Enter credentials」頁面中，請鍵入具備「來源端伺服器」管理者權限的使用者帳號及密碼後按下 Next 鈕。

在「Add and scan devices」頁面中，請按下「Add a device」後鍵入「來源端伺服器」的主機名稱，本文實作環境來源端伺服器主機名稱為「WS2012-IIS」，然後按下「Start scan」鈕進行來源端伺服器的掃描及檢查作業，並於掃描及檢查作業結束後歸類出「Shares、Configuration、Network adapters、Volumes」等 4 大項目（如圖 7 所示），讓管理人員能夠確認待遷移的來源端伺服器相關資訊是否正確。

圖 7、針對來源端伺服器進行掃描及檢查作業

SMS 遷移步驟 2、傳輸資料至目的地伺服器

完成來源端伺服器的資源掃描及檢查作業後，便可以進入 SMS 遷移工作任務的第 2 個步驟。首先，在 Transfer data 步驟 2 的「Enter credentials」頁面中，請鍵入具備「目的地伺服器」管理者權限的使用者帳號及密碼後按下 Next 鈕。

在「Add a destination device and mappings」頁面中，請鍵入「目的地伺服器」的主機名稱，本文實作環境目的地伺服器主機名稱為「WS2019-IIS」，然後按下「Scan device」鈕進行目的地伺服器的掃描及檢查作業，當掃描及檢查作業完成後將會出現來源端 / 目的地伺服器的 Volume 資訊，此時管理人員可以選擇準備將來源端伺服器中的哪個磁碟區，傳輸資料至目的地伺服器中的哪個磁碟區。

在「Adjust settings」頁面中，可以調整屆時傳輸作業的相關組態設定值，例如，最大傳輸時間為 10080 秒、傳輸作業失敗時的重新嘗試次數……等。

在「Validate devices」頁面中，請按下「Validate」鈕讓 SMS 遷移服務再次檢查相關組態設定值及運作環境參數是否正確，包括，來源端 / 目的地伺服器是否能順利使用 SMB 連線、目的地伺服器是否安裝 Storage Migration Service Proxy 伺服器功能……等，管理人員可以按下 Validation 欄位中的「Pass」圖示查看驗證項目詳細資訊（如圖 8 所示）。

圖 8、SMS 遷移服務再次檢查相關組態設定值及運作環境參數是否正確

在「Start the transfer」頁面中，管理人員便可以按下「Start transfer」鈕將相關檔案由來源端伺服器傳輸至目的地伺服器，管理人員可以看到來源端 / 目的地伺服器的檔案數量、傳輸檔案開始和結速時間……等資訊（如圖 9 所示）。倘若，管理人員希望了解整個傳輸檔案的細節，可以按下「Transfer detail」鈕下載傳輸資訊 CSV 檔案，內容包括此次傳輸作業的檔案清單、檔案名稱、檔案路徑……等資訊。

圖 9、將相關檔案由來源端伺服器傳輸至目的地伺服器

SMS 遷移步驟 3、目的地伺服器接手電腦帳戶及 IP 位址

待資料傳輸作業完成後便進入 SMS 遷移工作任務的最後階段，由目的地伺服器接手來源端伺服器的電腦帳戶及 IP 位址。首先，在「Enter credentials」頁面中，請鍵入具備「目的地伺服器」管理者權限的使用者帳號及密碼後按下 Next 鈕。

在「Configure cutover」頁面中，左側的「Source network adapters」將會顯示來源端伺服器的網路卡及 IP 位址資訊（本文實作環境為 10.10.75.12），在下方則是屆時目的地伺服器接手來源端伺服器的 IP 位址後所使用的新 IP 位址為何，在本文實作環境中指定新的 IP 位址採用「DHCP」，至於右側的「Destination network adapters」則是目的地伺服器所要使用的網路卡及目前使用的 IP 位址（本文實作環境為 10.10.75.19）。

至於 Configure cutover 頁面下方的「Rename the source device after cutover」區塊中，則是針對來源端伺服器屆時被目的地伺服器接手後所要採用的新電腦帳戶名稱為何，預設值「Use randomly generated name for source computer」選項，則是由 SMS 遷移機制為來源端伺服器隨機產新一個新的電腦帳戶，或是管理人員可以選擇「Choose a new name for source computer」選項，自行鍵入來源端伺服器屆時新電腦帳戶名稱，本文實作環境便是選擇此項目並鍵入新的電腦名稱為「WS2012-IIS-Orig」（如圖 10 所示）。

圖 10、準備來源端 / 目的地伺服器的電腦帳戶及 IP 位址接手資訊

在「Adjust settings」頁面中，可以調整屆時電腦帳戶及 IP 位址接手作業的組態設定值，預設接手作業的逾時時間為「2880 分鐘」。

在「Validate devices」頁面中，請按下「Validate」鈕讓 SMS 遷移服務再次檢查相關組態設定值及運作環境參數是否正確，包括，是否能夠順利連接至來源端 / 目的地伺服器、模擬測試目的地伺服器是否能接手來源端伺服器……等，管理人員可以按下 Validation 欄位中的「Pass」圖示查看驗證項目詳細資訊（如圖 11 所示）。

圖 11、SMS 遷移服務再次檢查相關組態設定值及運作環境參數是否正確

在「Start the cutover」頁面中，管理人員便可以按下「Start cutover」鈕進行接手作業，整個由來源端伺服器切換到目的地伺服器的流程如下：

重新啟動來源端伺服器。
變更來源端伺服器電腦帳戶及 IP 位址。
再次重新啟動來源端伺服器以便套用生效。
重新啟動目的地伺服器。
接手原本來源端伺服器的電腦帳戶及 IP 位址。
再次重新啟動目的地伺服器以便套用生效。

.
由上述接手作業流程可以看到，來源端伺服器及目的地伺服器分別都會「重新啟動 2 次」，並且當接手作業完成後原本的來源端伺服器便會採用新的電腦帳戶及 IP 位址，而原本的目的地伺服器將會接手來源端伺服器的電腦帳戶及 IP 位址（如圖 12 所示）。

圖 12、目的地伺服器接手來源端伺服器的電腦帳戶及 IP 位址

驗證是否順利接手

順利由 Windows Server 2019 主機，接手原本運作在 Windows Server 2012 R2 主機上的 IIS 網頁服務後，由於連同 Windows Server 2012 R2 主機的電腦帳戶及 IP 位址也一併接手，所以使用者無須進行任何額外的組態設定便能夠存取到原本的 IIS 網頁服務（如圖 13 所示）。

圖 13、Windows Server 2019 主機順利接手原本 Windows Server 2012 R2 的 IIS 網頁服務

結語

透過本文深入剖析的說明及實戰演練，相信讀者已經了解透過 SMS 遷移機制，可以幫助管理人員輕鬆將老舊作業系統上的檔案傳輸至新作業系統上。同時，最令管理人員頭痛和困擾的老舊作業系統電腦帳戶及 IP 位址接手的問題，也可以透過 SMS 遷移機制自動且快速幫助管理人員轉移完成。

↧

[站長開講] Windows Server 2019 成就多雲資料中心現代化

March 16, 2019, 9:20 am

≫ Next: 網管人 158 期 - 建構高效靈活 vCenter 提升企業營運服務 SLA 層級

≪ Previous: 網管人 157 期 - 借力 SMS 遷移無難事新舊系統順利交接帳戶 IP

活動簡介

在混合雲與 AI 等技術急速發展的今天，各國新法規也與時俱進的修訂產生如歐盟個資法 (GDPR) 等，期望企業以更完備的智慧安全防護來面對新型態資安攻擊。根據 2018 年 Dell EMC 對台灣企業所做的數位轉型調查顯示，66 % 的客戶表示因應轉型所需未來 1 - 3 年計畫投資於網路資安的建構，超過 1/3 的企業將投資多雲環境。可見資安與彈性兼具的混合雲已成最新趨勢，也是企業擁抱數位轉型、邁向雲端運算時代的當務之急。

全新 Windows Server 2019 已於去年 10 月 2 日在全球正式推出，提供業界首創的混合雲資料中心，可助企業將資料中心擴展到 Azure 雲端，取得更多混合雲功能與安全防護。而進一步要以更高效、更具彈性的方式，一站完美部署超融合基礎架構，則可以選擇經由 WSSD 認證的 Dell EMC S2D Ready Node 來建構企業軟體定義資料中心，全新管理介面強化了 IT 人員在部署、管理超融合基礎架構與叢集群組的能力，並支援 Dedup 功能，大幅提升應用效能。

活動資訊

日期： 2019 年 3 月 22 日 (星期五)
時間： 13:00 ~ 16:10
地點：台灣微軟 M 1908 會議室 (台北市信義區忠孝東路五段 68 號 19 樓 - 國泰置地廣場)
報名：活動報名

活動內容

站長議程： Dell EMC S2D Ready Node 超融合架構與應用剖析

↧

網管人 158 期 - 建構高效靈活 vCenter 提升企業營運服務 SLA 層級

March 26, 2019, 8:17 am

≫ Next: Azure Stack HCI 正式推出

≪ Previous: [站長開講] Windows Server 2019 成就多雲資料中心現代化

網管人雜誌

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

文章目錄

前言
vCHA 高可用性運作架構
vCHA 硬體資源及軟體版本需求
vCHA 部署模式
實戰 vCHA 高可用性機制
準備 vCHA 部署環境
組態設定 vNetwork 虛擬網路環境
啟用 vCHA 高可用性機制
vCHA 高可用性機制的維運管理
結語

前言

在企業及組織資料中心內的 VMware vSphere 虛擬化架構中，vCenter Server 管理平台的重要性相信是不言而喻的，當 vCenter Server 管理平台發生故障損壞事件而無法正常提供管理服務時，對於 vSphere 虛擬化架構在運作上並不會產生立即的影響，但是管理人員將無法進行任何的 vSphere 虛擬化架構管理工作任務，例如，部署 VM 虛擬主機、調整 vSwitch 虛擬網路交換器，vMotion 線上遷移 VM 虛擬主機……等。

雖然，只要啟用 vSphere Cluster 當中的 vSphere HA 高可用性機制後，即可讓 vCenter Server 在短暫的停機時間後恢復正常運作，以便因應企業及組織的資料中心發生非計劃性災難事件時，能夠盡量縮短 vCenter Server 管理平台無法正常服務的時間，但是仍然會影響企業及組織當中營運服務的 SLA。

因此，在 2016 年 11 月發佈的 VMware vSphere 6.5版本中，VMware 正式推出專門為 vCenter Server 管理平台量身打造的高可用性機制「vCHA（vCenter High Availability）」（如圖 1 所示）。

在過去的 vCSA（VMware vCenter Server Appliance）版本中，VMware 並沒有推出針對 vCSA 的高可用性機制，僅能搭配 vSphere Cluster 內建的 vSphere HA 高可用性機制，達成 vCSA 管理平台服務高可用性的目的。

圖 1、vCenter High Availability 高可用性運作架構示意圖

圖片來源： VMware Feature Walkthrough – Enabling vCenter HA - Basic

在本文中，將深入剖析及實作演練 vCenter High Availability 高可用性運作架構，以便協助管理人員了解 vCenter High Availability 高可用性的最佳建議作法，有效提升企業及組織當中營運服務的 SLA。

vCHA 高可用性運作架構

在管理人員動手建構及組態設定 vCHA 高可用性機制之前，應該先了解整個 vCHA 高可用性的運作架構及環境需求，舉例來說，採用的 vCSA 管理平台是採用「Embedded 或 External」方式進行部署、在啟用 vCHA 高可用性機制的 vSphere Cluster 中至少必須有 3 台 ESXi 6.5 的成員主機……等。

首先，在 vCHA 高可用性機制運作架構中，其實是由「Active、Passive、Witness」這 3 種不同節點的成員角色所組成（如圖 2 所示），當 vCHA 高可用性機制建立完成後，便會建構出「Active-Passive」的容錯移轉機制。

事實上，Passive、Witness 這 2 個角色，是由系統將擔任 Active 角色的 vCSA 進行「複製」（Clone）後，分別運作在其它 2 台 ESXi 虛擬化平台上。

下列便是條列不同角色的成員節點主機所負責的工作任務及功能：

Active Node：運作 vCSA 主要執行個體，同時使用 vCSA 對外服務共用 IP 位址。
Passive Node：運作 vCSA 備援執行個體，透過複寫機制不斷從 Active Node 接收變更內容及狀態，一旦 Active Node 發生災難事件時便會立即接手相關服務及共用 IP 位址。
Witness Node：擔任 vCHA 高可用性架構中的仲裁角色，當 Active Node 及 Passive Node 發生網路分區或中斷事件時，能夠有效避免 vCHA 高可用性機制發生「腦裂」（Split-Brain）的情況。值得注意的是，在 vCHA 高可用性運作架構中，僅負責仲裁的工作任務並不會接手 Active Node 及 Passive Node 的角色。

圖 2、vCHA 高可用性機制運作角色示意圖

圖片來源： VMware vCenter Server 6.7 Update1 – vSphere Availability

因此，當擔任「vCenter（Active）」角色的 vCSA 所在的底層 ESXi 虛擬化平台發生災難事件時，便會觸發 vCHA 高可用性機制容錯移轉功能，由擔任「vCenter（Passive）」角色的 vCSA 接手原本的服務，並且繼承原本 vCenter（Active）角色所使用的 IP 位址。

由於 vCHA 高可用性機制是屬於「Active-Passive」的容錯移轉解決方案，所以災難事件發生時透過 API 存取的使用者在 2 分鐘內便可以繼續使用，透過 UI 存取的使用者在 4 分鐘便可以繼續存取，原則上 vCHA 高可用性機制的 RTO 通常在「5 分鐘」之內便可完成所有容錯移轉作業，當然實際上還必須視底層硬體資源的工作負載情況而定。

vCHA 硬體資源及軟體版本需求

在組態設定 vCHA 高可用性機制之前，管理人員必須確保採用的是支援 vCHA 機制的 vCenter Server 及 ESXi 版本，並且也必須符合最低硬體資源需求，例如，擁有足夠的 CPU 及 Memory 運算資源。

ESXi 虛擬化平台：至少採用 ESXi 6.0 或後續版本，並且 vSphere Cluster 建議至少擁有 3 台 ESXi 主機，並且讓每個 vCHA 角色分別運作在不同的 ESXi 主機上以確保高可用性。同時，建議為 vSphere Cluster 啟用 vSphere DRS 負載平衡機制。
vCenter Server Appliance：至少採用 vCSA 6.5 或後續版本，同時為了滿足基本的 RTO 需求，所以 vCSA 部署大小至少需要採用「Small（4 vCPU 及 16GB vRAM）」或更大規模。此外，vCHA 高可用性機制，支援管理人員將 vCSA 部署在「VMFS、NFS、vSAN Datastore」儲存資源中。請注意，在 VMware 最佳建議作法中，請勿在營運環境中部署最小型的 vCSA「Tiny（2 vCPU 及 10GB vRAM）」規模大小，因為這樣的 vCSA 硬體資源將無法滿足屆時基本的 RTO 需求。
採用隔離且專用的良好網路環境：因為在 vCHA 高可用性機制運作架構中，Active Node 及 Passive Node 之間，必須不斷同步 PostgreSQL 資料庫的資料及相關運作資訊，倘若 2 台節點主機之間的網路頻寬無法達到資料同步要求時，那麼 vCHA 高可用性機制將會退化為「非同步」狀態，同時導致 PostgreSQL 資料庫內容相異。因此，除了必須採用與 vCSA 管理網路不同的子網路之外，在 Active、Passive、Witness 節點主機之外，必須採用小於「10 ms」延遲時間的網路環境（如圖 3 所示）。

圖 3、vCSA 高可用性機制採用隔離且專用的良好網路環境示意圖

圖片來源： VMware vSphere Blog – vCenter High Availability Deep Dive – Part 1

除了上述 vCHA 高可用性機制的硬體資源及軟體版本需求之外，管理人員還應注意下列 2 項最佳建議作法，以確保 vCHA 高可用性機制的運作效能及穩定性：

於離峰時間啟用 vCHA 機制：事實上，管理人員可以在任何時間啟用 vCHA 高可用性機制，但根據 VMware 最佳建議作法則是應在離峰時間再進行啟用。主要原因是，一旦啟用 vCHA 高可用性機制之後，系統將會立即執行 Active Node 及 Passive Node 的 PostgreSQL 資料庫同步作業，此時在處於工作負載的高峰時間時，有可能會導致 Passive Node 的 PostgreSQL 資料庫無法即時同步，造成後續容錯移轉時發生非預期的錯誤。
僅容許單台節點發生故障：由於目前的 vCHA 高可性機制為 Active-Passive 容錯移轉架構，所以容許故障的節點主機數量無法超過「單台」。因此，每台節點主機的角色應部署在不同的 ESXi 虛擬化平台上，以避免單一 ESXi 虛擬化平台發生災難事件時直接影響所有角色的運作。此外，每台 vCHA 節點主機也應部署在獨立且隔離的 Datastore 儲存資源中，避免將 3 台 vCHA 節點主機都部署在同 1 個 Datastore 儲存資源中，導致發生 SPOF 單點失敗的問題進而影響 vCHA 高可用性機制。

vCHA 部署模式

vCHA 高可用性機制，可以搭配 vCSA「embedded 或 external」的 Platform Services Controller 部署模式。值得注意的是，倘若 vCSA 採用「external Platform Services Controller」部署模式時，那麼必須要置於負載平衡設備「後面」，以便 Platform Services Controller 發生災難事件能夠進行容錯移轉。

首先，我們來看看採用「vCSA Embedded」部署模式時，管理人員建立 vCHA 高可用性機制的流程：

1. 採用 vCSA Embedded 部署模式建立 vCSA 管理平台。

2. 登入 vCSA 管理平台管理介面並啟用「vCenter HA」機制。

3. 啟用 vCHA 高可用性機制後，系統將會以 Active Node 為來源複製出 Passive Node 及 Witness Node。

4. 確保 Active Node 與 Passive Node 完成「資料同步」作業，包括，PostgreSQL 資料庫、Platform Services Controller 及其它服務（如圖 4 所示）。

5. 當 Active Node 發生災難事件時，Passive Node 將使用同步後的所有資料及服務和原本 Active Node 的「服務 IP 位址」。

圖 4、vCSA Embedded 部署模式啟用 vCHA 高可用性機制運作架構示意圖

圖片來源： VMware vCenter Server 6.7 Update1 – vSphere Availability

當採用「vCSA External」部署模式時，管理人員必須確保 Platform Services Controller 受到負載平衡設備的保護。下列為建立 vCHA 高可用性機制的流程：

1. 採用 vCSA External 部署模式建立 vCSA 管理平台，請管理人員確保至少部署 2 個 External Platform Services Controller 執行個體。

2. 管理人員組態設定 vCSA 管理平台，指向至受到負載平衡設備保護的 Platform Services Controller（相關資訊請參考 VMware KB2147014、KB2147038、KB2147046）。

3. 啟用 vCHA 高可用性機制後，系統將會以 Active Node 為來源複製 Passive Node 及 Witness Node，此時 Platform Services Controller 及負載平衡資訊也會一併複製。

4. 確保 Active Node 與 Passive Node 完成「資料同步」作業，包括，PostgreSQL 資料庫、Platform Services Controller 及其它服務（如圖 5 所示）。

5. 當 Platform Services Controller 發生災難事件時，負載平衡設備會重新導向至備援用途的 Platform Services Controller，以便進行身份驗證及它服務。

圖 5、vCSA External 部署模式啟用 vCHA 高可用性機制運作架構示意圖

圖片來源： VMware vCenter Server 6.7 Update1 – vSphere Availability

實戰 vCHA 高可用性機制

了解 vCHA 高可用性機制的基礎架構及最佳作法後，接著便是進行 vCHA 高可用性機制的實作演練。下列為整個建構 vCHA 高可用性機制的流程：

1. 準備 vCHA 部署環境。

2. 組態設定 vNetwork 虛擬網路環境。

3. 啟用 vCHA 高可用性機制。

4. vCHA 高可用性機制的維運管理。

準備 vCHA 部署環境

在本文實作環境中，將依據 VMware 最佳建議作法準備 3 台 ESXi 虛擬化平台，並且部署 1 台 vCenter Server 至其中 1 台 ESXi 虛擬化平台上，另外 2 台 ESXi 虛擬化平台屆時則部署 vCenter Server Passive 角色及 Witness 角色。此外，將採用 vCSA Small Size 及 Embedded 部署模式啟用 vCHA 高可用性機制（如圖 6 所示）。

圖 6、採用 vCSA Small Size 及 Embedded 部署模式

組態設定 vNetwork 虛擬網路環境

在本文實作環境中 vCenter Server 管理網路環境採用的網段為「10.10.75.0/24」，同時規劃 vCenter HA Network專用的網段為「192.168.75.0/24」，並且分別採用不同的 vSwitch 虛擬網路交換器及 Port Group。

登入 vCenter Server 管理介面後，依序點選「ESXi Host > Configure > Networking > Virtual Switches > Add Networking > Virtual Machine Port Group for a Standard Switch > New standard switch > vmnic1」，接著在 Connection settings 視窗中 Network label 欄位填入名稱「vCHA HA Network」，這便是本文實作環境專用於 vCenter Server HA 虛擬網路的 Port Group 名稱（如圖 7 所示）。

圖 7、新增專用於 vCenter Server HA 虛擬網路的 Port Group

啟用 vCHA 高可用性機制

請在 vCenter Server 管理頁面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Set Up vCenter HA」項目。首先，在 Resource settings 頁面中，請按下「Browse」選擇剛才新增專用於 vCenter Server HA 虛擬網路的「vCHA HA Network」，並確認「Automatically create clones for Passive and Witness nodes」項目已勾選（如圖 8 所示）。

接著，分別為 Passive Node 及 Witness Node 選擇運作環境，本文實作環境中將 Passive Node 部署至第 2 台 ESXi 虛擬化平台，而 Witness Node 則部署至第 3 台 ESXi 虛擬化平台。值得注意的是，Witness Node 在 vNetwork 虛擬網路的部分，只要選擇 vCHA HA Network 即可而無須管理網路。

圖 8、啟用 vCenter HA 高可用性機制，組態設定管理網路及 HA 同步專屬網路

在 Set Up vCenter HA 第二階段中，將組態設定 Active Node、Passive Node、Witness Node的 HA 同步專屬網路 IP 位址，本文實作環境依序為「192.168.75.31、192.168.75.32、192.168.75.33」（如圖 9 所示）。

圖 9、組態設定 vCenter HA 同步專屬網路 IP 位址

待系統複製完成 Passive Node 及 Witness Node，並且組態設定 vCenter HA Cluster 之後，vCHA 高可用性機制便正式成形且運作無誤（如圖 10 所示）。

圖 10、順利啟用 vCenter HA 高可用性機制

順利啟用 vCenter HA 高可用性機制後，我們可以「手動」進行 vCenter Server 容錯移轉，以便確認 vCenter HA 容錯移轉機制運作正常，或後續需要進行 Active / Passive 角色切換時使用。請在 vCenter Server 管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Initiate Failover」項目即可，值得注意的是在切換期間 vCenter Server 及 vSphere Client 和其它服務，會有幾分鐘停止服務的空窗期（如圖 11 所示）。

在 Initiate vCenter HA failover 視窗中，「不」建議勾選 Force the failver to start immediately 選項，原因是強制立即執行容錯移轉的動作有可能會造成 vCenter Server 資料尚未同步完成，而導致資料遺失或發生不可預期的錯誤。

圖 11、管理人員手動進行 vCenter Server 容錯移轉

經過幾分鐘的 vCenter Server 容錯移轉程序後，可以看到 vCenter Server 高可用性機制重新運作，並且原本擔任 Passive Node 角色的主機成為 Active Node 角色，並且接手 vCenter Server 管理 IP 位址「10.10.75.31」（如圖 12 所示）。

.圖 12、原本 Passive Node 角色順利接手 Active Node 角色及管理用途 IP 位址

vCHA 高可用性機制的維運管理

分散運作在不同台 ESXi 主機

在正式營運環境中，除了確保 vCHA 高可用性機制運作正常且能夠順利切換之外，也應搭配 vSphere Cluster DRS 規則，確保 Active、Passive、Witness 角色這 3 台主機不會運作在「同一台」ESXi 虛擬化平台上。

請在 vCenter Server 管理介面中，依序點選「Cluster > Configure > Configuration > VM/Host Rules > Add」項目，在彈出的 Create VM/Host Rule 視窗中首先填入此規則名稱，本文實作名稱為「vCHA Separate」，在 Type 下拉式選單中請選擇至「Separate Virtual Machines」項目，以確保此規則套用後 Active、Passive、Witness 角色不會運作在同一台 ESXi 主機上，最後按下 Add 鈕加入 Active、Passive、Witness 角色主機即可（如圖 13 所示）。

圖 13、新增 Separate Virtual Machines 規則，確保 vCHA 主機不會運作在同一台 ESXi 主機上

vCenter HA 進入維護模式

當 vCenter Server 需要進行相關維運作業時，為了避免系統誤判而導致觸發 vCenter Server 容錯移轉機制，我們可以在進行 vCenter Server 維運作業前將 vCenter HA 機制進行「維護模式」（Maintenance Mode）。

請在 vCenter Server 管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Edit」項目，在彈出的 Edit vCenter HA 視窗中選擇至「Maintenance Mode」項目即可。此時，可以管理介面中看到 vCenter HA 的 Mode 由原本的 Enable 轉換成「Maintenance」，並且系統也顯示「Automatic failover」機制已停用，但是管理人員仍然可以進行手動容錯移轉（如圖 14 所示）。

圖 14、組態設定 vCenter HA 高可用性機制進入維護模式

備份和還原 vCenter Server

即便建立 vCenter Server 高可用性機制，定期備份 vCenter Server 仍是必須的，下列便是建立 vCenter HA 高可用性機制後的備份還原注意事項：

1. 僅備份擔任 Active Node 角色的 vCenter Server 即可，無須備份 Passive Node 及 Witness Node。

2. 當災難事件發生必須執行還原作業時，請先關閉並刪除所有 vCenter HA 角色的節點主機。

3. 執行還原 Active Node 角色的 vCenter Server 即可，還原後為單台的 vCenter Server（如圖 15 所示）。

4. 重新組態設定 vCenter HA 高可用性機制。

圖 15、執行還原 Active Node 角色的 vCenter Server

因應各種災難情境

事實上，vCHA 高可用性機制針對不同的資料屬性採用不同的同步方式，以便保持 Active Node 及 Passive Node 節點主機狀態的一致性。首先，在 vCenter Server 資料庫部分預設採用內嵌「PostgreSQL 資料庫」，直接透過 PostgreSQL 資料庫原生的「複寫」（Replication）機制，保持 Active Node 及 Passive Node 節點主機資料庫同步及內容的一致性，在「組態設定檔」的部分則使用 Linux 作業系統中原生的「Rsync」複寫機制，達到 Active Node 及 Passive Node 節點主機組態設定檔內容一致性。

因為採用 PostgreSQL 資料庫原生複寫機制隨時保持資料一致性，所以發生災難事件時不會有資料遺失的情況發生（RPO=0）。

此外，在 vCHA 高可用性機制的運作架構下，當發生不同的災難事件時（例如，硬體、軟體、網路環境……等），如何才會觸發 Passive Node 接手 Active Node 服務及叢集共用 IP 位址，並且繼續回應客戶端送出的請求。

下列，我們將列舉當 vCHA 高可用性機制發生各種災難事件時，系統將如何進行因應措施：

Active Node 發生災難故障時：只要 Passive Node 與 Witness Node 能夠互相通訊，那麼 Passive Node 將會提升自己的角色為 Active Node，接手相關服務及管理 IP 位址並開始回應客戶端提出的請求。
Passive Node 發生災難故障時：只要 Active Node 與 Witness Node 能夠互相通訊，那麼 Active Node 將繼續保持 Active Node 的角色，繼續回應客戶端提出的請求。
Witness Node 發生災難故障時：只要 Active Node 與 Passive Node 能夠互相通訊，那麼 Active Node 將繼續保持原來的角色，並繼續回應客戶端提出的請求。同時，Passive Node 將會繼續偵測 Active Node 是否正常運作，以便隨時準備進行容錯移轉作業。
多台節點發生故障或發生網路隔離：表示 Active、Passive、Witness 這 3 台節點主機彼此無法互相通訊。此時，vCHA 叢集無法正常運作並且高可用性也受到影響，因為在 vCHA 高可用性機制的設計中並無法容許同時發生多項故障。
節點隔離行為：當單台節點主機發生網路中斷事件，在經過間歇性網路故障偵測程序及所有重試機制都耗盡後，系統才會將該台節點主機判定為隔離狀態，同時進入隔離狀態的節點主機將會自動停止所有服務。舉例來說，倘若 Active Node 發生隔離狀態時，那麼 Active Node 將會從叢集中移出並停止所有服務，以便確保 Passive Node 能夠接手角色成為 Active Node，並開始回應客戶端提出的請求。

結語

透過本文的說明及實作演練相信讀者已經了解，在最新 vSphere 6.7 Update 1 版本中 vCenter HA 高可用性機制及運作架構，以及如何搭配 VMware 最佳建議作法建構出高效能和高靈活性的 vCenter Server。

↧

Azure Stack HCI 正式推出

March 27, 2019, 7:34 pm

≫ Next: 網管人 159 期 - 活用 WAC 管理平台輕鬆管理 S2D 叢集

≪ Previous: 網管人 158 期 - 建構高效靈活 vCenter 提升企業營運服務 SLA 層級

簡介

簡單來說，在 Windows Server 2019 S2D (Storage Spaces Direct)技術，搭配各家硬體供應商的解決方案終於推出，正式名稱為「Azure Stack HCI」。

圖片來源： Build your hybrid strategy with Azure Stack and Azure Stack HCI - YouTube

圖片來源： HCI Solutions - Azure Stack | Microsoft Azure

有興趣的朋友，可以參考 Jeff Woolsey 及 Vijay Tewari 針對 Azure Stack HCI 解決方案的說明影片。

參考資源

↧

網管人 159 期 - 活用 WAC 管理平台輕鬆管理 S2D 叢集

April 25, 2019, 7:49 am

≫ Next: [站長開講] Cloud Summit 2019

≪ Previous: Azure Stack HCI 正式推出

網管人雜誌

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

文章目錄

前言
Windows Server 2019 S2D 新增特色功能
支援更大型的運作規模
最適用於邊緣運算環境的仲裁機制
儲存裝置延遲異常檢測機制
儲存效能加倍的 Mirror-Accelerated Parity
S2D 實戰–叢集節點主機硬體需求
建立 S2D 網域環境
安裝伺服器角色及功能
vSwitch 虛擬網路交換器
驗證 S2D 容錯移轉叢集
建立 S2D 容錯移轉叢集
啟用 Storage Spaces Direct 機制
Windows Admin Center 管理平台
結語

前言

根據 Gartner 市調機構的研究結果顯示，在 2017 年時全球大型企業中便已經有高達 75 % 的比例，建構名為「Bimodal IT」的雙重 IT 基礎架構分別是 Mode 1 及 Mode 2（如圖 1 所示）。簡言之，在傳統 Mode 1 資料中心內的工作負載、技術架構、執行流程和部署模式已經行之有年無須再驗證，然而新興的 Mode 2 資料中心則與傳統 Mode 1 資料中心大不相同。

圖 1、Bimodal IT 雙重 IT 基礎架構示意圖

圖片來源： Gartner 官方網站- What is Bimodal IT? See Gartner's IT Glossary For The Answer

同時，在該份 Gartner 調查報告中也指出，從 2016 年開始便已經有 2/3 以上的企業及組織，開始建構及整合稱為「基礎架構敏捷化」（Infrastructure Agility）的 Mode 2 敏捷式 IT 基礎架構，由 Mode 2 所建構的資料中心，它所強調的便是「敏捷性」（Agility）與「可擴充性」（Scalability），以便協助企業及組織能夠快速推出各種服務以便因應不斷快速變化的商業數位化需求。

過去，在企業及組織中傳統式的 Mode1 資料中心內，運算資源及儲存資源總是各司其職各自獨立，然而 IT 管理人員應該不難發現市場上的解決方案，已經從幾年前的「融合式基礎架構」（Converged Infrastructure），演變為新興的「超融合基礎架構」（Hyper-Converged Infrastructure，HCI），便是希望能夠解決傳統式 Mode1 資料中心內運算及儲存資源整合及擴充方面的困擾，進而打造出高可擴充性且靈活性高的 Mode 2 基礎架構敏捷化的目標（如圖 2 所示）。

圖 2、基礎架構敏捷化發展歷程

圖片來源： HPE recognized as a leader by Gartner in new Magic Quadrant for Hyperconverged Infrastructure

事實上，微軟在 2016 年 10 月推出 Windows Server 2016 作業系統版本時，IT 管理人員便可以透過標準的 x86 硬體伺服器，搭配 Windows Server 2016 內建的 S2D（Storage Spaces Direct）機制，手動為企業及組織打造出 HCI 超融合基礎架構，而無須購買相對昂貴且又有硬體綁定問題的 HCI 超融合基礎架構解決方案。

隨著微軟在 2018 年 10 月推出最新一代 Windows Server 2019 雲端作業系統，也將原本 SDS 軟體定義儲存方案的 S2D（Storage Spaces Direct）推升至第 2 世代。在本文中，我們將說明及實作演練，採用最新 Windows Server 2019 雲端作業系統打造的 S2D 軟體定義儲存方案，與前一代 Windows Server 2016 所打造的 S2D 軟體定義儲存方案有哪些不同之處。

Windows Server 2019 S2D 新增特色功能

在 Windows Server 2019 雲端作業系統中，第 2 世代的 S2D 軟體定義儲存解決方案，除了新增多項亮眼功能之外，原有的特色功能及運作規模和相關支援度也都再度提升，舉例來說，在 Windows Server 2016版本所建構的 S2D 超融合基礎架構，最大儲存空間支援至「1 PB」，現在透過 Windows Server 2019所打造的 S2D 超融合基礎架構，最大儲存空間可支援高達至「4 PB」。

支援更大型的運作規模

隨著硬碟供應商因應大量儲存需求而不斷提升硬碟儲存容量，現在主流的硬碟儲存空間已經來到單顆硬碟「14 TB」的儲存空間。因此，這也是為什麼新一代 Windows Server 2019 所打造的 S2D 超融合基礎架構，需要支援更大型運作規模的原因之一。

過去，在 Windows Server 2016版本所建構的第 1 世代 S2D 超融合基礎架構中，單一 S2D 叢集最大儲存空間支援上限為「1 PB」、每台 S2D 節點主機儲存空間支援上限為「100 TB」、單一 Volume 儲存空間支援上限為「32 TB」。

現在，透過 Windows Server 2019版本所打造的第 2 世代 S2D 超融合基礎架構，單一 S2D 叢集儲存空間最大可支援至「4 PB」、每台 S2D 節點主機儲存空間支援上限提升至「400 TB」、單一 Volume 儲存空間支援上限提升為「64 TB」（如圖 3 所示）。

圖 3、Windows Server 2019 支援更大型運作規模的 S2D 超融合基礎架構

圖片來源： Storage at Microsoft – Here`s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit

最適用於邊緣運算環境的仲裁機制

事實上，無論 IT 管理人員採用市面上哪種 HCI 超融合基礎架構解決方案，都必須要搭配「仲裁/見證」（Quorum / Witness）機制，以便因應 HCI 超融合基礎架構發生災難或故障事件時能夠保持高可用性。過去，在 Windows Server 2016 版本中，當管理人員建構好 S2D 超融合基礎架構後，仲裁機制方面僅支援「File Share Witness」及「Cloud Witness」等 2 種仲裁機制。

現在，新一代 Windows Server 2019 版本所建構的 S2D 叢集，已經支援將仲裁機制指向至「USB 隨身碟」（如圖 4 所示）。因此，當企業及組織在分支機構或邊緣運算等小型運作環境時，無須其它硬體伺服器、VM虛擬主機、Active Directory、網際網路……等，也仍然能夠順利運作 S2D 叢集並啟用仲裁機制。

圖 4、組態設定 Windows Server 2019 USB Witness 流程示意圖

圖片來源： Storage at Microsoft – Here`s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit

儲存裝置延遲異常檢測機制

在建置 S2D 超融合基礎架構時，相信管理人員已經採用微軟的最佳建議作法，為每一台 S2D 叢集節點主機配置相同型號且高效能高耐久性的儲存裝置。然而，即便是企業等級的儲存裝置，也有可能因為儲存裝置中的某個硬體元件不良或即將損壞而導致效能低落，那麼管理人員如何在 S2D 叢集內眾多的儲存裝置中找出效能低落的儲存裝置？

在 Windows Server 2019 S2D 叢集中新增儲存裝置延遲異常檢測機制（如圖 5 所示），這項新增機制的靈感來自於 Microsoft Azure 公有雲環境檢測儲存裝置異常的作法。現在，Windows Server 將會記錄每個儲存裝置每次資料「讀取/寫入」（Read / Write）的結果以及延遲時間，因此當儲存裝置發生資料讀寫效能低落，甚至是資料讀寫失敗的情況時，管理人員可以輕鬆透過 WAC（Windows Admin Center）管理平台或 PowerShell Cmdlet 快速找出有問題的儲存裝置。

圖 5、儲存裝置延遲異常檢測機制示意圖

圖片來源： Storage at Microsoft – Here`s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit

儲存效能加倍的 Mirror-Accelerated Parity

事實上，不管採用哪種 HCI 超融合基礎架構，在「效能/儲存空間/資料可用性」這 3 方面是很難同時面面俱到的，舉例來說，為了考量資料可用性將資料複寫 3 份以便因應儲存裝置故障損壞時，仍然能夠保有資料可用性，然而卻也因為資料複寫 3 份而導致消耗大量的儲存空間。

因此，在 S2D 叢集中便推出整合 RAID-1 資料可用性，以及 RAID-6 節省儲存空間特性的 Volume 稱之為「Mirror-Accelerated Parity」。簡單來說，在此 S2D Volume 中快取層級將會採用效能最佳的 3-Way Mirror 處理資料讀寫，至於資料儲存層級則是採用能夠節省儲存空間的 Dual Parity 來處理，希望讓管理人員能夠在運作效能及儲存空間的節省方面取得平衡點。

現在，Windows Server 2019 S2D 叢集中，針對 Mirror-Accelerated Parity 儲存效能表現的部份，提供相較於舊版 Windows Server 2016 S2D 叢集成長 1 倍（如圖 6 所示），讓管理人員在享有節省儲存空間的同時，又能享有更好的儲存運作效能。

圖 6、Windows Server 2019 S2D Mirror-Accelerated Parity 儲存效能表現示意圖

圖片來源： Storage at Microsoft – Here`s what you missed – Five big announcements for Storage Spaces Direct from the Windows Server Summit

S2D 實戰–叢集節點主機硬體需求

當企業或組織的 IT 管理人員，希望在內部資料中心建置 S2D 軟體定義儲存技術時，建議可以採用下列硬體規格及基本需求硬體元件：

叢集節點主機：在 S2D 叢集中，最小運作規模必須由「2 台」叢集節點主機組成，最大運作規模則支援至「16 台」叢集節點主機，並且應採用同一家硬體伺服器製造商及型號。
CPU 處理器：建議至少採用 Intel Nehalem 及 AMD EPYC 或後續新推出的 CPU 處理器。
硬碟控制器：每台叢集節點主機，必須採用SATA Connected或SAS HBA Connected硬碟控制器，不支援採用內建的ACHI Controller硬碟控制器，或是RAID Controller磁碟陣列卡。
硬碟數量：採用 Hybrid 架構時，每台叢集節點主機的快取層至少需要 2 顆儲存裝置而資料層則至少需要 4 顆儲存裝置。採用 All-Flash 架構時，每台叢集節點主機至少需要 4 顆儲存裝置。
網路卡：每台叢集節點主機，建議採用 25 GbE 網路卡或更高速度，並且應選用支援 RDMA 特色功能（RoCE、iWARP）的網路卡。

建議可以直接瀏覽微軟官方網站（Microsoft.com/WSSD），查詢並選擇通過 WSSD（Windows Server Software-Defined）硬體驗證的伺服器，可以有效解決管理人員在挑選硬體伺服器各項硬體元件及 Firmware 版本的困擾。

建立 S2D 網域環境

在本文實作環境中，我們將建立 4 台 Windows Server 主機，其中 1 台擔任 Domain Controller 網域控制站另外 2 台則擔任 S2D 叢集節點主機，最後 1 台則是安裝及擔任 Windows Admin Center 管理平台的工作任務，這 4 台 Windows Server 主機皆安裝最新 Windows Server 2019 雲端作業系統（如圖 7 所示）。

圖 7、安裝 Windows Server 2019 雲端作業系統

值得注意的是，當管理人員要將單機環境的 Windows Server 2019 提升為 DC 網域控制站時，存放 AD 資料庫、記錄檔及 SYSVOL 分割區必須採用傳統的「NTFS」檔案系統才行，因為 AD 資料庫並不支援存放於新式的「ReFS」檔案系統。

在 S2D 叢集節點主機的部份，建立 2 台 S2D 叢集成員伺服器，並將電腦名稱分別命名為「Node01 及 Node02」，每台 S2D 叢集節點主機除了作業系統硬碟之外，皆額外配置「4 顆」300GB 的 SSD 固態硬碟（如圖 8 所示），最後所有的 S2D 叢集節點主機都必須加入「同一個」Windows AD 網域才行。

圖 8、每台 S2D 叢集節點主機額外配置 4 顆 300GB 的 SSD 固態硬碟

安裝伺服器角色及功能

完成 S2D 網域環境及 S2D 成員伺服器加入網域的動作後，接著請為每台 S2D 叢集節點主機安裝所需的伺服器角色及功能。請開啟 PowerShell 指令視窗中，執行「Install-WindowsFeature -Name "Hyper-V"，"Failover-Clustering"，"Data-Center-Bridging"，"RSAT-Clustering-PowerShell"，"Hyper-V-PowerShell"，"FS-FileServer"」指令，所安裝的伺服器角色及功能如下：

Hyper-V ：安裝 Hyper-V 伺服器角色，以便 S2D 叢集節點主機成為 Hyper-V 虛擬化平台。
Failover-Clustering ：安裝容錯移轉叢集伺服器功能。
Data-Center-Bridging ：安裝 DCB（Data Center Bridging）伺服器功能，當採用 RoCE v2 的網路卡時此伺服器功能為必要安裝選項，倘若採用 iWARP 網路卡時則可選擇性安裝。
RSAT-Clustering-PowerShell ：安裝用於管理容錯移轉叢集的 PowerShell 模組。
Hyper-V-PowerShell ：安裝用於管理 Hyper-V 虛擬化平台的 PowerShell 模組。
FS-FileServer ：安裝檔案伺服器角色，以便後續 S2D 能夠提供 SOFS 高可用性檔案伺服器服務。

圖 9、為每台 S2D 叢集節點主機安裝所需的伺服器角色及功能

vSwitch 虛擬網路交換器

事實上，在 Windows Server 2012作業系統版本時，便已經開始支援 RDMA 功能的網路卡，但是有項限制便是 RDMA 網路卡「無法」建立 vSwitch 虛擬交換器及 NIC Teaming，也就是說 RDMA 網路卡只能專用於儲存網路而缺少維運管理上的彈性。

雖然，這項限制已經從 Windows Server 2016作業系統版本開始便徹底解除，但是在建立 Hyper-V vSwitch 虛擬網路交換器時，必須採用搭配 RDMA 網路卡的「SET（Switch-Embedded Teaming）」機制（如圖 10 所示），而非一般 vSwitch 虛擬網路交換器。

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

圖片來源： Windows Server 2016 and 2019 RDMA Deployment Guide

此外，目前主流的 RDMA 通訊協定為 RoCE 及 iWARP，倘若 S2D 叢集節點主機配置的 RDMA 網路卡為「RoCE」時，那麼除了 S2D 叢集節點主機必須安裝 DCB 伺服器功能之外，所連接的實體網路交換器也必須支援及啟用 DCB 功能，並組態設定 ETS（Enhanced Transmission Service）和 PFC（Priority Flow Control）功能才行。倘若，S2D 叢集節點主機配置的 RDMA 網路卡為「iWARP」時，則無須依賴實體網路交換器的 DCB 功能及組態設定 ETS 和 PFC 功能即可運作。

目前，RDMA 網路卡中主要支援 iWARP 協定的供應商為 Chelsio 及 Intel，主要支援 RoCE 協定的供應商則是 Broadcom 和 Mellanox，甚至 Cavium（Marvell）供應商則同時支援 iWARP 和 RoCE 協定。

驗證 S2D 容錯移轉叢集

在建立 S2D 容錯移轉叢集之前，請先執行「叢集驗證」（Cluster Validation）的動作，確認目前每台 S2D 叢集節點主機已經符合各項需求，以避免稍後建立 S2D 容錯移轉叢集發生非預期的錯誤。

在本文實作環境中，2 台 S2D 叢集節點主機的電腦名稱為「Node01 和 Node02」，請在其中 1 台主機上開啟 PowerShell 指令視窗，鍵入「Test-Cluster –Node Node01，Node02 –Include "Storage Spaces Direct"，"Inventory"，"Network"，"System Configuration"」指令進行叢集環境的驗證動作（如圖 11 所示）。

圖 11、驗證 S2D 叢集節點主機確保符合建立 S2D 叢集的各項需求

建立 S2D 容錯移轉叢集

當 S2D 叢集節點主機通過容錯移轉叢集驗證程序後，在建立 S2D 容錯移轉叢集之前，請先確保每台 S2D 叢集節點主機沒有任何硬碟已經被「宣告」（Claimed）使用，例如，硬碟初始化為 MBR/GPT、格式化為 ReFS 檔案系統……等。

倘若，不確認硬碟是否已經初始化或格式化過的話，可以採用 Diskpart 指令確認硬碟編號，然後使用 PowerShell 的 Clear-Disk 指令清除硬碟中所有內容，舉例來說，本文實作環境共有 4 顆 300GB 的 SSD 固態硬碟且編號為 1 ~ 4，便可以執行「Clear-Disk –Number 1,2,3,4 –RemoveData –RemoveOEM」指令清除硬碟中所有內容。

請注意，硬碟若已經被宣告使用後，稍後啟用 Storage Spaces Direct 機制時，將無法順利將儲存裝置加入至 S2D 儲存資源池當中。

現在，管理人員可以放心建立 S2D 容錯移轉叢集。在本文實作環境中，S2D 叢集名稱為「wsfc」，而容錯移轉叢集 IP 位址為「10.10.75.30」，請鍵入「New-Cluster –Name wsfc -Node Node01，Node02 –NoStorage –StaticAddress 10.10.75.30」PowerShell 指令建立容錯移轉叢集（如圖 12 所示）。

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

啟用 Storage Spaces Direct 機制

在為 S2D 叢集啟用 Storage Spaces Direct 機制之前，請再次確認 S2D 叢集任意 1 台 S2D 叢集節點主機，是否可以看到本機硬碟以及 S2D 叢集中其它叢集節點主機的硬碟數量，舉例來說，本文實作環境中每台 S2D 叢集節點主機除了作業系統之外，還額外配置 4 顆 300GB 的 SSD 硬碟，因此任意 1 台 S2D 叢集節點主機都應該看到總數「8 顆」300GB 的 SSD 硬碟才正確（如圖 13 所示）。

圖 13、確認 S2D 叢集節點主機皆可看到本機及其它台叢集節點主機的硬碟數量

確認 S2D 叢集中總硬碟數量無誤後，便可以在 PowerShelld 指令視窗中執行「Enable-ClusterStorageSpacesDirect」指令，進行啟用 Storage Spaces Direct 機制的動作。

順利為 S2D 叢集啟用 Storage Spaces Direct 機制後，管理人員可以在容錯移轉叢集管理員視窗中，依序點選至「Storage > Pools」項目，即可看到目前 S2D 儲存資源池的空間大小，在本文實作環境中共採用 8 顆 300GB 的 SSD 固態硬碟，建立後的 S2D 儲存資源池儲存空間大小便是 2.33TB（如圖 14 所示）。

圖 14、順利為 S2D 叢集啟用 Storage Spaces Direct 機制

Windows Admin Center 管理平台

現在，管理人員可以透過新世代的 WAC 管理平台進行 S2D 超融合基礎架構的管理作業。在本文實作環境中，安裝最新的 Windows Admin Center 1809版本，當安裝程序完畢後管理人員便可以採用 Microsoft Edge 或 Google Chrome 瀏覽器，連接 WAC 管理平台並在順利通過使用者身份驗證程序登入後，會先看到 WAC 管理介面簡易的導覽資訊，管理人員可以按下 Next 了解導覽資訊或按下 Skip Tour略過導覽程序，便會立即進入 WAC 管理介面（如圖 15 所示）。

事實上，WAC 管理平台除了支援新世代 Windows Server 2019 建構的 S2D 叢集之外，也支援管理舊版 Windows Server 2016 所建構的 S2D 叢集環境。

圖 15、採用最新 Windows Admin Center 1809 版本的 WAC 管理介面

請在 WAC 管理介面中，依序點選「All Connections > Add > Add Hyper-Converged Cluster Connection」項目，然後在「Cluster name」欄位鍵入希望納管的 S2D 超融合基礎架構叢集名稱，在本文實作環境中名稱為「wsfc.s2d.weithenn.org」（如圖 16 所示），當 WAC 管理平台成功納管 S2D 超融合基礎架構叢集後，將會自動連同所有 S2D 叢集節點成員主機也一併加入至納管的主機清單中。

圖 16、WAC 管理平台順利探索到 S2D 叢集及所有 S2D 叢集節點成員主機

此時，管理人員便可以輕鬆看到 S2D 超融合基礎架構叢集工作負載情況，包括，S2D 叢集節點數量、IOPS 儲存效能、Latency 延遲時間、Throughput 傳輸速率、儲存資源剩餘空間、VM虛擬主機運作數量……等（如圖 17 所示）。

圖 17、透過 WAC 管理平台管理及查詢 S2D 超融合基礎架構運作環境

結語

透過本文的深入剖析及實作演練，相信讀者已經了解新世代 Windows Server 2019 雲端作業系統中，在 SDS 軟體定義儲存技術方面有哪些新增及增強的亮眼特色功能，同時管理人員只要透過 Windows Admin Center 管理平台，更可以達到輕鬆且快速管理 S2D 叢集的目標。

↧

[站長開講] Cloud Summit 2019

April 25, 2019, 8:08 am

≫ Next: 網管人 160 期 - HCIBench 壓測改善有依據 vSAN 架構營運擴充更平順

≪ Previous: 網管人 159 期 - 活用 WAC 管理平台輕鬆管理 S2D 叢集

活動簡介

在 2019 年，眾所矚目的 5G 陸續商轉，勢必促使邊緣運算快速成熟，正式揭開 AIoT 智慧時代的序幕，從這一刻起，許多極具顛覆性的創新產品與服務，可望密集地應運而生。因應「邊起雲湧」下的劇烈變局，您更需要駕馭雲端技術，以雲端為基礎，迅速淬鍊數位競爭力，「2019 iThome 臺灣雲端大會」是您不容錯過的求知殿堂。

2018 年 5 月，我們在「雲霧運算合璧，打造數位贏家」基調下，舉辦一場臺灣最盛大的企業雲端技術盛會，不僅探討私有雲、公有雲及混合雲，更將關注範圍擴展至 Cloud Native、NGDC、IoT、AI、Blockchain、Machine Learning、Container、Serverless、DevOps、Edge Computing…等等領域，力求全面涵蓋企業營運與業務雲端化的每一個環節。

如今，數位轉型浪潮更加波瀾壯闊，逐漸從過去幾年的「概念驗證 (PoC)」層次，進一步邁向價值驗證 (PoV) 的里程碑；換言之，企業的數位化進程，不宜繼續圍繞在關心、探討、研究、評估、小量測試…等等進程，必須開始展現商業價值。

因此，2019 年無疑是企業數位轉型的關鍵之年，真正「直球對決」、而非「迂迴纏繞」！

在此關鍵時刻，企業需要更懂得如何合併運用多種數位科技，產生組合式效果，加速開創突破式創新局面。有鑑於此，我們秉持過往初衷，幫助各位洞察趨勢、孕育更多的商業可能性，繼續在 2019 年舉辦雲端盛會，覆蓋更豐富的科技趨勢主題，提供更精闢的專題演講，讓您獲得啟發，加速完成數位轉型的最後拼圖。

活動資訊

日期： 2019 年 5 月 15 日 (星期三)
時間： 8:00 ~ 16:30
地點：台北國際會議中心 (TICC)
報名：活動報名

活動內容

↧

網管人 160 期 - HCIBench 壓測改善有依據 vSAN 架構營運擴充更平順

May 17, 2019, 9:08 am

≫ Next: 波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

≪ Previous: [站長開講] Cloud Summit 2019

網管人雜誌

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

文章目錄

前言
HCIBench 儲存效能壓測工具
HCIBench 運作元件及架構
實戰 HCIBench 儲存效能壓測工具
HCIBench 部署前置作業
部署 HCIBench Virtual Appliance
存取 Controller VM Web UI 管理介面
組態設定運作環境及壓測參數
壓測前再次驗證 vSAN 運作環境
執行儲存資源壓力測試作業
查看 HCIBench 壓力測試報表
結語

前言

當企業或組織的 IT 管理人員，將 VMware vSAN 超融合基礎架構建置完成後，相信在營運服務上線之前應該會進行相關的容錯及壓力測試，例如，拔線測試 NIC Teaming 容錯移轉機制、部署 VM 虛擬主機估算所需花費的時間……等。

然而，對於建構好的 vSAN 超融合基礎架構能夠提供多少儲存資源運作效能，是否能夠以更精確且量化的數據來進行佐證，以便屆時營運服務上線後能夠針對 vSAN 節點主機擴充進行正確的評估，舉例來說，建置時 vSAN 儲存資源效能測試結果為 30 萬 IOPS，日後營運時當儲存資源效能已高達 25 萬 IOPS的工作負載平均值時，管理人員便應開始考慮擴充 vSAN 節點主機，以便增加 IOPS 儲存效能及儲存空間。

圖 1、採用 vSAN All-Flash 架構，單台 vSAN 節點主機可提供高達 15 萬 IOPS 儲存效能

圖片來源： VMware 官網- vSAN 產品概觀

本文，將說明及實作演練透過在 VMware Labs Fling中，擁有極高評價的 HCIBench超融合基礎架構儲存效能壓測工具，針對 vSAN 超融合基礎架構進行各項儲存效能壓力測試。

在 VMworld 2018大會中，有關 vSAN 儲存效能壓力測試的議程中，也都採用 HCIBench進行壓測及報表分析作業。

HCIBench 儲存效能壓測工具

HCIBench（Hyper-Converged Infrastructure Benchmark）儲存效能壓測工具，是由 vSAN 上海研發團隊中的工程師所開發。簡單來說，HCIBench 是一款專門針對 vSAN 超融合基礎架構的儲存效能測試工具，管理人員可以透過 Virtual Appliance 的方式進行運作環境的部署作業，後續便可以透過 HCIBench Controller VM 虛擬主機，針對 vSAN 叢集產生大量的 VM 虛擬主機，然後同時併發執行儲存效能壓力測試。

值得一提的是，HCIBench 儲存效能壓力測試工具，在 VMware Labs Fling 中免費提供給管理人員使用。因此，企業及組織無須花費額外的費用，即可透過 HCIBench 針對 vSAN 超融合基礎架構，進行儲存效能壓力測試並產生測試報表。

HCIBench 運作元件及架構

在 HCIBench 運作架構中（如圖 2 所示），具備兩個不同的角色分別是擔任管理工作任務的 Controller VM虛擬主機，以及負責儲存效能壓力測試的 Vdbench Guest VM虛擬主機。

當管理人員透過 OVA 格式的 Virtual Appliance 虛擬設備，進行部署 Controller VM 虛擬主機的工作任務，並且在部署完成 Controller VM 虛擬主機和順利啟動後，將會運作下列四個核心元件：

RVC（Ruby vSphere Console）： HCIBench 壓測工具的核心引擎，屆時將由此運作元件主導部署 Vdbench Guest VM 壓測虛擬主機、在壓測虛擬主機內部執行 Vdbench 壓測工具、透過 vSAN Observer 工具監控及收集儲存效能壓測力測試結果。
vSAN Observer：當啟動儲存效能壓力測試工作任務時，負責監控 vSAN 叢集和 vSAN 節點主機的儲存效能表現。
Automation Bundle：由 Ruby 和 Bash Script 所組成的自動化腳本，負責自動化部署 Vdbench Guest VM 壓測虛擬主機，包括壓測虛擬主機的 VMDK 虛擬磁碟初始化、屆時在壓測虛擬主機內部執行 Vdbench 壓測工具。
Configuration files：在 HCIBench 運作架構中，負責儲存各式壓力測試及部署作業的組態設定檔。
Linux 壓測虛擬主機範本檔：屆時大量部署 Vdbench Guest VM 壓測虛擬主機的範本檔案。

圖 2、HCIBench 運作元件及運作架構示意圖

圖片來源： VMware Labs Flings – HCIBench User Guide

實戰 HCIBench 儲存效能壓測工具

在本文實作環境中，已經建置好 vSAN 6.7 Update 1 超融合基礎架構，接著將實際部署 HCIBench 儲存效能壓測工具，以便觀察 vSAN 超融合環境對於各式各樣儲存資源工作負載的效能表現。

有關建置 vSAN 超融合基礎架構的詳細資訊，請參考本雜誌《第 154 期-了解 Update 1 增強版，動手打造 vSAN 6.7 叢集》。

HCIBench 部署前置作業

當管理人員準備好 vSAN 超融合環境，在部署 HCIBench 儲存效能壓測工具之前，請確認已經完成下列前置作業項目：

確保 vSAN 叢集及 vSAN 節點主機已正常運作。
建議管理人員將 HCIBench 壓測工具中，負責管理任務的 Controller VM虛擬主機部署到 vSAN 叢集中。雖然，支援將 Controller VM 虛擬主機部署到「單機」的 ESXi 虛擬平台主機上，但是該台 ESXi 虛擬平台主機必須能夠存取 vCenter Server 管理平台才行。
屆時，部署的大量 Vdbench Guest VM 壓測虛擬主機虛擬網路環境中，必須要有 DHCP Server 負責配發 IP 位址給壓測虛擬主機。倘若，該虛擬網路並沒有 DHCP Server 時，則可以配置與 Controller VM 虛擬主機使用同一段虛擬網路，它將會提供 DHCP Server 特色功能來配發 IP 位址。
管理人員除了從 VMware Flings 網站上，下載 HCIBench OVA 檔案之外，還需要額外下載開放原始碼中，負責產生 Disk I/O 工作負載的指令碼工具壓測執行檔 Vdbench檔案。

部署 HCIBench Virtual Appliance

在本文實作環境中，採用最新的 HCIBench 1.6.8.7 版本進行部署作業，預設情況下部署的 HCIBench Virtual Appliance 虛擬設備，便是 HCIBench 運作架構中負責管理任務的 Controller VM，部署完成後相關的虛擬硬體配置及已安裝的軟體套件資訊如下：

虛擬硬體配置： 8 vCPU、8GB vRAM、16GB vDisk。
作業系統版本： Photon OS 1.0
安裝軟體套件： Ruby 2.3.0、Rubygem 2.5.1、Rbvmoni 1.8.2、RVC 1.8.0、sshpass 1.05、Apache 2.4.18、Tomcat 8.54、JDK 1.8u102

請管理人員登入 HTML 5 管理介面後，依序點選「vCenter Server > Datacenter > Cluster > Actions > Deploy OVF Template」項目，在 Select an OVF template 頁面中，請點選 Choose Files 鈕後選擇「HCIBench_1.6.8.7.ova」檔案。

在 Select a name and folder 頁面中，請為此台 HCIBench 虛擬主機命名（本文為 HCIBench），並選擇所要存放的 vSphere Datacenter。接著，在 Select a compute resource 頁面中，選擇 HCIBench 虛擬主機所要運作的 vSAN 叢集和 vSAN 節點主機。

在 Review details 頁面中，將會再次顯示 HCIBench 虛擬主機的相關資訊，以便管理人員確認繼續進行部署作業（如圖 3 所示）。

圖 3、再次檢視部署 HCIBench 虛擬主機的組態設定

在 License agreements 頁面中，請勾選「I accept all license agreements」項目，以便同意使用者授權條款。在 Select storage 頁面中，請選擇要將 HCIBench 虛擬主機存放於哪個 Datastore 儲存資源中，本文選擇存放於 vsanDatastore 儲存資源中。

在 Select networks 頁面中（如圖 4 所示），需要選擇 Controller VM 虛擬主機所要採用的虛擬網路環境，其中「VM Network」虛擬網路為屆時 Vdbench Guest VM 壓測虛擬主機的虛擬網路環境，這段虛擬網路應該具備 DHCP Server 以便配發 IP 位址，倘若實作環境中並沒有架設 DHCP Server 的話，則可以配置與 Controller VM 虛擬主機同一段虛擬網路，由 Controller VM 虛擬主機提供 DHCP Server 服務。至於「Management Network」虛擬網路，則是屆時管理人員存取 Controller VM 虛擬主機 Web UI 圖形介面的網路環境。

圖 4、選擇 Controller VM 虛擬主機採用的虛擬網路環境

在 Customize template 頁面中（如圖 5 所示），請配置 Controller VM 虛擬主機的網路資訊，例如，預設閘道、IP 位址、DNS 伺服器、子網路遮罩。同時，請在 Root Credential 欄位中，填入 Controller VM 虛擬主機的管理者密碼。

圖 5、組態設定 Controller VM 虛擬主機的網路資訊及管理者密碼

最後，在 Ready to complete 頁面中，再次檢視部署 HCIBench Controller VM 虛擬主機的資訊無誤後，即可按下 Finish 鈕立即進行部署作業。

存取 Controller VM Web UI 管理介面

當 HCIBench Controller VM 虛擬主機部署作業完畢後，管理人員便可以開啟瀏覽器於網址列鍵入「https://HCIBench_IP:8443」（本文實作環境為 https://hcibench.vsan.weithenn.org:8443），即可存取 Controller VM Web UI 管理介面（如圖 6 所示），預設管理者登入帳號為「root」，管理者密碼則是剛才部署時所設定的 Root Credential。

當管理人員需要登入 Controller VM 虛擬主機的 Console 時，也請採用相同的管理者帳號及密碼登入。

圖 6、登入 Controller VM Web UI 管理介面

組態設定運作環境及壓測參數

順利登入 Controller VM Web UI 管理介面後，在管理介面中共有五大組態設定項目，包含，vSphere 環境組態設定、vSAN 叢集組態設定、Vdbench 壓測 VM 虛擬主機組態設定、Vdbench 壓測設定檔、Vdbench 組態設定檔產生器。

vSphere 環境組態設定
首先，在 vSphere 環境組態設定的部份（如圖 7 所示），管理人員必須填入 vSphere 虛擬環境相關組態內容：

vCenter Hostname/IP：請填入 vCenter Server 管理平台的 FQDN 名稱或 IP 位址，本文實作環境為「vcsa.vsan.weithenn.org」。
vCenter Username：請填入 vCenter Server 管理平台的管理者帳號，本文實作環境為「Administrator@vsan.weithenn.org」。
vCenter Password：請填入 vCenter Server 管理平台的管理者密碼。
Datacenter Name：請填入 vSphere 架構中 Datacenter 名稱，本文實作環境為「Datacenter」。
Cluster Name： 請填入 vSphere 架構中叢集名稱，本文實作環境為「Cluster」。
Resource Pool Name：請填入 vSphere 架構中資源集區名稱，本文實作環境未建立資源集區所以可不填。
VM Folder Name：請填入 vSphere 架構中 VM 虛擬主機資料夾名稱，本文實作環境未建立 VM 虛擬主機資料夾所以可不填。
Network Name：請填入 Vdbench Guest VM 壓測虛擬主機的虛擬網路連接埠名稱，未指定的話將採用預設值「VM Network」，本文實作環境為「MGMT-DPortGroup」。預設情況下，部署的 Vdbench Guest VM 壓測虛擬主機，將會透過 DHCP Server 自動取得動態配發的 IP 位址，倘若管理人員希望 Vdbench Guest VM 壓測虛擬主機採用「固定 IP 位址」的話，請勾選「Set Internal Static IP for Vdbench Client VMs」選項。
Datastore Name：指定部署 Vdbench Guest VM 壓測虛擬主機的 Datastore 儲存資源。倘若，管理人員希望壓測虛擬主機能夠同時部署到「多個」Datastore 儲存資源時，可以每行填入一個 Datastore 名稱即可，屆時系統便會平均部署到多個 Datastore 儲存資源，舉例來說，組態設定 2 個 Datastore 儲存資源並部署 100 台壓測虛擬主機時，便會分別部署 50 台壓測虛擬主機至每個 Datastore 儲存資源中。
Storage Policy：指定部署的 Vdbench Guest VM 壓測虛擬主機，要採用哪個 vSAN SPBM 儲存原則管理機制，未指定的話將採用預設值「vSAN Default Storage Policy」。
Clear Read/Write Cache Before Each Testing：當管理人員勾選此項目後，系統於 Vdbench 測試作業執行前，會先執行清空 vSAN 快取內容的動作。

圖 7、vSphere 環境組態設定

vSAN 叢集組態設定
在 vSAN 叢集組態設定的部份（如圖 8 所示），管理人員必須填入 vSAN 叢集及節點主機相關組態內容：

Deploy on Hosts：預設情況下，系統將會針對 vSAN 叢集中的所有 vSAN 節點主機進行部署作業，倘若管理人員希望僅將 Vdbench Guest VM 壓測虛擬主機，部署於特定 vSAN 節點主機的話請勾選此項目。
Hosts：當管理人員勾選「Deploy on Hosts」項目後，必須於此欄位指定 vSAN 節點主機的 FQDN 或 IP 位址，以便稍後將 Vdbench Guest VM 壓測虛擬主機，部署於這些指定的 vSAN 節點主機上。值得注意的是，倘若指定的 vSAN 節點主機數量超過「5 台」時，為了避免部署時產生大量的 vSAN 網路流量，系統一次只會在 5 台 vSAN 節點主機進行部署作業。
Host Username：指定 vSAN 節點主機的管理者帳號。
Host Password：指定 vSAN 節點主機的管理者密碼。
EAST RUN：此選項專為 vSAN 超融合基礎架構環境設計，系統將會採用多種儲存資源工作負載進行壓力測試。
Re-Use The Existing VMs If Possible：此選項勾選後，若下一次的壓力測試參數選項跟此次的測試條件符合時，便保留所有已經部署的 Vdbench Guest VM 壓測虛擬主機，否則便會刪除並重新部署 Vdbench Guest VM 壓測虛擬主機。

圖 8、vSAN 叢集組態設定

Vdbench 壓測 VM 虛擬主機組態設定
在 Vdbench 壓測 VM 虛擬主機組態設定部份（如圖 9 所示），管理人員必須填入 Vdbench 壓測 VM 虛擬主機相關組態內容。值得注意的是，倘若剛才勾選「EASY RUN」選項的話，此組態設定頁面將被取代：

VM Name Prefix：指定 Vdbench Guest VM 壓測虛擬主機的命名規則。
Number of VMs：指定部署 Vdbench Guest VM 壓測虛擬主機的數量。
Number of Data Disk：指定部署 Vdbench Guest VM 壓測虛擬主機時，每台壓測虛擬主機需要掛載的 VMDK 虛擬磁碟數量，預設值為 8 個。
Size of Data Disk：指定壓測虛擬主機掛載的 VMDK 虛擬磁碟空間大小，預設值為 10GB。

圖 9、Vdbench 壓測 VM 虛擬主機組態設定

Vdbench 壓測設定檔
在 Vdbench 壓測設定檔部份（如圖 10 所示），管理人員必須填入此次壓測的相關組態內容：
Test Name：指定此次儲存資源壓力測試名稱，此測試名稱將會在 Controller VM 中的「/opt/output/results」路徑下，建立測試名稱資料夾。倘若，未指定將會採用預設值名稱「resultsTIMESTAMP」。

Select a Vdbench parameter file：此下拉選單中，將會顯示過去曾經測試過的儲存資源壓力測試項目。
Generate Vdbench Parameter File by Yourself：建立儲存資源壓力測試相關參數組態設定檔，例如，資料讀取及寫入比例、Disk I/O 資料區塊大小……等。
Upload a Vdbench parameter file：若管理人員已經有組態設定檔，即可進行上傳後直接使用。
Prepare Virtual Disk Before Testing：此下拉選單中，管理人員可以選擇是否要針對 Vdbench Guest VM 壓測虛擬主機，所掛載的 VMDK 虛擬磁碟進行初始化的動作，預設值為「NONE」。倘若，選擇「ZERO」選項時，由於將會預先初始化 VMDK 虛擬磁碟，所以能夠有效避免第一次進行資料寫入的效能懲罰。當 vSAN 叢集啟用重複資料刪除功能時，則建議採用「RANDOM」選項。
Testing Duration（seconds）：指定儲存資源壓力測試時間，單位為「秒」。
Clean up VMs：當管理人員希望儲存資源壓力測試完畢後，便刪除所有 Vdbench Guest VM 壓測虛擬主機的話，請勾選「Clean up VMs after testing」項目。

圖 10、Vdbench 壓測設定檔

Vdbench 組態設定檔產生器
最後，在 Vdbench 組態設定檔產生器部份（如圖 11 所示），管理人員必須在「Upload the Vdbench File」區塊中，按下 Choose File 鈕並上傳 Vdbench 執行檔，最後按下「Save Configuration」鈕以便儲存此次壓測參數設定及內容。

圖 11、上傳 Vdbench 執行檔並儲存此次壓測參數

壓測前再次驗證 vSAN 運作環境

順利完成上述儲存資源壓力測試多項參數後，便可以按下「Validate」鈕，進行壓力測試前的環境驗證工作任務（如圖 12 所示），以便確保稍後的壓力測試能夠順利執行。

此時，管理人員可以切換至 vCenter Server 管理介面，將會發現 HCIBench 依據剛才填寫的參數，嘗試連接至 vCenter Server 並部署 Vdbench Guest VM 壓測虛擬主機，並且於完成驗證運作環境後刪除壓測虛擬主機。

圖 12、壓測前再次驗證 vSAN 運作環境

執行儲存資源壓力測試作業

現在，管理人員可以按下「Test」鈕，讓 HCIBench 立即執行儲存資源壓力測試作業（如圖 13 所示）。此時，系統便會依據剛才管理人員組態設定的儲存壓力測試參數，產生 Vdbench Guest VM 壓測虛擬主機，並透過 Vdbench 執行檔進行不同工作負載的儲存資源壓力測試作業。

圖 13、HCIBench 執行儲存資源壓力測試作業

此時，管理人員可以切換到 vCenter Server 管理介面，依序點選「Cluster > Monitor > vSAN > Performance」項目，便可以查看 HCIBench 執行儲存資源壓力測試作業，對於 vSAN 叢集產生多少的儲存資源工作負載及效能表現，例如，IOPS、Throughput、Latency、Congestions、Outstanding IO（如圖 14 所示）。

圖 14、HCIBench 執行儲存資源壓力測試作業時，vSAN 叢集工作負載及效能表現

查看 HCIBench 壓力測試報表

當 HCIBench 執行儲存資源壓力測試作業完畢後，管理人員便可以開啟瀏覽器於網址列鍵入「http://hcibench.vsan.weithenn.org/results」，依序點選剛才「壓測名稱」的路徑後，便可以查看 HCIBench 此次的儲存資源壓力測試報表內容，例如，產生多少台 Vdbench Guest VM 壓測虛擬主機、vSAN 叢集此次壓測的 IOPS 儲存效能表現、壓測時網路延遲時間、資料讀取及寫入的延遲時間……等（如圖 15 所示）。

圖 15、查看 HCIBench 儲存資源壓力測試報表

繼續深入點選 result 路徑中資料夾及檔案，當點選至「stats.html」檔案時，便可以觀看 vSAN Observer 的詳細分析圖表（如圖 16 所示）。

圖 16、觀看 vSAN Observer 的詳細分析圖表

結語

透過本文的說明及實作演練相信讀者已經了解，如何透過 HCIBench 儲存效能壓力測試工具，評估企業或組織所建構的 vSAN 超融合基礎架構，針對不同的儲存工作負載能有怎樣的儲存效能表現，以便日後營運服務上線時，能夠正確評估何時該擴充 vSAN 叢集中的 vSAN 節點主機。

↧

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

June 3, 2019, 9:31 am

≫ Next: 波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林

≪ Previous: 網管人 160 期 - HCIBench 壓測改善有依據 vSAN 架構營運擴充更平順

啟程

這次規劃的 15 天假期，將要前往波羅的海三小國 (愛沙尼亞 Estonia / 拉脫維亞 Latvia / 立陶宛 Lithuanua)、波蘭 (Poland)、斯洛伐克 (Slovakia)中歐五國深度之旅。

因為「愛沙尼亞、拉脫維亞、立陶宛」這三個國家，在地理位置和過往歷史上都具有非常大的相似性，並且這三個國家經常在眾多政府和組織內，進行區域層面上的各項整體合作及交流，所以在國際上便經常一起稱呼為「波羅的海三小國」。

雖然，稱之為波羅的海三小國，但每個國家的地理面積可是都比台灣還大哦!

旅程

「旅行」對於我來說，是一個能夠讓我 眼界開闊、心境轉換、釋放負能量、補充正能量……等。同時，我的旅行習慣是跟團，因為我喜歡有人在陌生的國度，可以預先幫我打點好旅途中的 吃 / 住 / 行，而我只需要盡情放鬆好好享受這個難得的假期，同時聽著導遊/領隊說明這個國家的人文、歷史、地理、特色……等即可。👻

其實，不管你是跟團或者自助行甚至不用出國也行，重點是找到專屬於你自己能夠放鬆再出發方式就好，對吧!! 😁

此次的行程，我們選擇參加 晴天旅遊－波蘭、波羅的海、斯洛伐克－中歐秘境、塔特拉山之旅行程。整趟行程下來，很幸運能夠由專業且認真負責的晴天玩家領隊 Nana-Joanna，讓整個中歐五國 15 天深度之旅留下難忘的回憶 (領隊/導遊，對於每次旅遊的品質及回憶影響真的非常大!)。下列為此次中歐五國 15 天深度之旅的旅程地圖：

圖片來源：晴天旅遊－波蘭、波羅的海、斯洛伐克－中歐秘境、塔特拉山

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

(本文) 波波斯之旅 - 啟程
波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林 (撰寫中...)
波波斯之旅 - Day02 - 愛沙尼亞 / 塔林 (撰寫中...)
波波斯之旅 - Day03 - 拉脫維亞 / 里加 (撰寫中...)
波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮 (撰寫中...)
波波斯之旅 - Day05 - 立陶宛 / 十字架山 (撰寫中...)
波波斯之旅 - Day06 - 波蘭 / 華沙 (撰寫中...)
波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮 (撰寫中...)
波波斯之旅 - Day08 - 波蘭 / 克拉科 (撰寫中...)
波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營 (撰寫中...)
波波斯之旅 - Day10 - 波蘭 / 塔特拉山 (撰寫中...)
波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡 (撰寫中...)
波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡 (撰寫中...)
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽 (撰寫中...)
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)

↧

波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林

June 5, 2019, 7:50 am

≫ Next: 波波斯之旅 - Day02 - 愛沙尼亞 / 塔林

≪ Previous: 波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

台灣 > 伊斯坦堡新機場

此次中歐 15 天深度之旅，必須先從台灣長途飛行 12 小時 15 分之後，來到集「歐洲 / 亞洲」於一身的國家土耳其 - 伊斯坦堡 (Istanbul)轉機。

這次旅程中，搭乘的是土耳其航空，倘若有搭過的朋友便知道，土耳其航空的 檸檬汁 (Lemonade)還小有名氣的，所以當然要選檸檬汁來喝搭配美食啊。

事實上，土耳其檸檬汁非常特別而且極度好喝嗎？其實，跟我們印象中的檸檬汁有些微的差異沒錯，但是我相信是因為加上出國旅遊的好心情之後，整個美味度立馬提升吧 😋。

到達伊斯坦堡機場之後，發現跟之前印象中的伊斯坦堡機場好像有點不一樣？原來，過去印象中的伊斯坦堡機場為「伊斯坦堡阿塔圖克機場」(İstanbul Atatürk Havalimanı)，已經從 1924 年啟用至今，然後就剛好在 2019 年 4 月 6 日，土耳其航空的所有航班以及國際機場航班，都轉移至新建的「伊斯坦堡新機場」(İstanbul Yeni Havalimanı)。

因此，這次旅程的轉機就是在「伊斯坦堡新機場」，所以當然跟之前印象中的伊斯坦堡機場不一樣了。

土耳其花費 116 億美金興建的伊斯坦堡新機場，擁有四座航廈及六條跑道和五百個停機坪，預計每一年可以處理 1.5 億名旅客，整個機場完工後將會成為全球最大的機場。

在等待轉機時間中，剛好有機會到處逛逛，就看看還有哪些好吃美食等待我去發現。😝

在閒逛的過程中，突然發現隨身行李暫放的保管箱，怎麼有一點像是放名牌包專櫃的錯覺。

伊斯坦堡新機場 > 塔林機場

經過 2 小時短暫的等待轉機時間後，再次搭上班機飛行 3 小時 20 分之後，便到達期待已久的波羅的海三小國首站「愛沙尼亞」(Estonia)。😭

位於愛沙尼亞首都塔林的國際機場，正式名稱為「倫納特 - 梅里塔林機場」(Lennart Meri Tallinna lennujaam)一般通稱為「塔林機場」(Tallinna lennujaam)。

愛沙尼亞從 2009 年 3 月 29 日開始，將塔林機場正式命名為「倫納特 - 梅里塔林機場」，是為紀念愛沙尼亞獨立運動領袖和第二任總統倫納特-梅里而命名。

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

波波斯之旅 - 啟程
(本文) 波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
波波斯之旅 - Day02 - 愛沙尼亞 / 塔林 (撰寫中...)
波波斯之旅 - Day03 - 拉脫維亞 / 里加 (撰寫中...)
波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮 (撰寫中...)
波波斯之旅 - Day05 - 立陶宛 / 十字架山 (撰寫中...)
波波斯之旅 - Day06 - 波蘭 / 華沙 (撰寫中...)
波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮 (撰寫中...)
波波斯之旅 - Day08 - 波蘭 / 克拉科 (撰寫中...)
波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營 (撰寫中...)
波波斯之旅 - Day10 - 波蘭 / 塔特拉山 (撰寫中...)
波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡 (撰寫中...)
波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡 (撰寫中...)
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽 (撰寫中...)
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)

旅程

「旅行」對於我來說，是一個能夠讓我 眼界開闊、心境轉換、釋放負能量、補充正能量……等。同時，我的旅行習慣是跟團，因為我喜歡有人在陌生的國度，可以預先幫我打點好旅途中的 吃 / 住 / 行，而我只需要盡情放鬆好好享受這個難得的假期，同時聽著導遊/領隊說明這個國家的人文、歷史、地理、特色……等即可。👻

其實，不管你是跟團或者自助行甚至不用出國也行，重點是找到專屬於你自己能夠放鬆再出發方式就好，對吧!! 😁

此次的行程，我們選擇參加 晴天旅遊－波蘭、波羅的海、斯洛伐克－中歐秘境、塔特拉山之旅 行程。整趟行程下來，很幸運能夠由專業且認真負責的 晴天玩家領隊 Nana-Joanna，讓整個中歐五國 15 天深度之旅留下難忘的回憶 (領隊/導遊，對於每次旅遊的品質及回憶影響真的非常大!)。下列，為此次中歐五國 15 天深度之旅的旅程地圖及相關連結：

圖片來源：晴天旅遊－波蘭、波羅的海、斯洛伐克－中歐秘境、塔特拉山

↧

波波斯之旅 - Day02 - 愛沙尼亞 / 塔林

June 10, 2019, 9:15 am

≫ Next: 網管人 161 期 - 實作 vCenter 內嵌部署模式輕鬆掌握 PSC 同步狀態

≪ Previous: 波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林

卡德里奧宮 (Kadrioru loss)

今天「塔林」(Tallinn)深度行程的第一站，我們前往人稱「彼得大帝」(Пётр Вели́кий) 的沙皇彼得一世建造的夏季行宮，這個夏季行宮正式名稱為「卡德里奧宮」(Kadrioru loss)。

圖片來源：彼得大帝 - 維基百科，自由的百科全書

在前往「卡德里奧宮」(Kadrioru loss) 的路上，會先經過卡德里奧公園，可以看到這座公園已經變成大家閒暇時間，休閒放鬆的好去處。

步行一段時間之後，終於來到了卡德里奧宮，印入眼簾的是一座巴洛克式風格的宮殿加上花園和水池的搭配。當地導遊，帶領我們到卡德里奧宮內的制高點，以方便大家更容易拍出美美的卡德里奧宮全景照。

在離開卡德里奧宮之前，來個卡德里奧宮全景環場影片吧。

由於住宿的飯店距離塔林古城區非常接近，導遊和領隊索性讓大家先把行李放到飯店，進入房間內窗簾一拉開，哇!! 從房間就可以直接看到塔林古城和「歐拉夫斯大教堂」(St. Olaf's Church)。

塔林古城歷史中心 Historic Centre (Old Town) of Tallinn

那麼，開始塔林古城巡禮吧! 一般通稱的塔林古城，全名為「塔林古城歷史中心Historic Centre (Old Town) of Tallinn」，在 1997 年時入選 UNESCO 世界文化遺產。下列是 UNESCO針對塔林古城給予的評價：

塔林的起源可追溯到 13 世紀，當時的條頓騎士團的十字軍騎士們在這裡建造了一個城堡，後來，這裡又發展成為「漢斯同盟」 (Hanseatic League)的主要中心。在後來的幾個世紀，這裡屢遭戰火，但許多建築還是較為完好地保留了下來，公共建築（特別是教堂）之豪華以及商店內部裝璜之考究充分展示了當時這裡的繁榮和富裕。

亞歷山大涅夫斯基教堂 (Alexander Nevsky Cathedral)

「亞歷山大涅夫斯基教堂」(Alexander Nevsky Cathedral)，是一座位於塔林古城座堂山山頂典型俄羅斯風格的東正教教堂，也是塔林最大和最高的圓頂東正教教堂，主要是紀念聖人「亞歷山大-涅夫斯基」(Александр Невский)，在 1242 年時於愛沙尼亞邊境贏得「楚德湖戰役」(Schlacht auf dem Peipussee)。

在離開亞歷山大涅夫斯基教堂之前，來個全景環場影片吧。

聖母瑪麗亞教堂 (St Mary's Cathedral)

「聖母瑪麗亞教堂」(St Mary's Cathedral)，是在十七世紀大火之後唯一倖存的建築，所以它是塔林和愛沙尼亞最古老的一座教堂。

在離開聖母瑪麗亞教堂之前，來個全景環場影片吧。

帕特庫利觀景台 (Patkuli viewing platform)

在步行幾分鐘之後，在到達「帕特庫利觀景台」(Patkuli viewing platform)之前，看到小賣店以及來到歐洲會吸引我的中古世紀盔甲，當然要拍下來紀念一下了。

來到「帕特庫利觀景台」(Patkuli viewing platform)之後，便可以從制高點俯瞰整個塔林古城，並且看到醒目的「歐拉夫斯大教堂」(St. Olaf's Church)。

在離開帕特庫利觀景台之前，來個全景環場影片吧。

塔林古城牆 (Tallinna linnamüür)

在步行幾分鐘之後來到「塔林古城牆」(Tallinna linnamüür)，比較醒目的是看到三尊修士像分別代表「守護、奉獻、保佑」 (坦白說，一開始看到還以為是什麼魔法師之類的 😅)。

上城區 / 下城區

在塔林古城區中分為「上城區 / 下城區」，簡單來說，宗教階層和貴族都會聚集在上城區，而其它士農工商則集於下城區。透過這個簡易的關口，即可從下城區到上城區，我們通過這個關口準備前往「長腿街」(Pikk Jalg)。

來到「長腿街」(Pikk Jalg)，這個長腿標誌便是最醒目的招牌了，告訴你目前身處於長腿街。

此外，在長腿街上還看到有趣的提示牌，提醒遊客要小心自己的隨身包包 (真貼心啊 👍)。

歐拉夫斯大教堂 (St. Olaf's Church)

「歐拉夫斯大教堂」(St. Olaf's Church)，這座教堂的尖頂已經被閃電擊中至少八次，而整個教堂燒毀也發生過三次。同時，曾經是世界最高建築，所以在塔林遠處的海上就可以看見這座商業城市。

三姐妹居 (The Three Sisters)

「三姐妹居」(The Three Sisters)，這是典型的中世紀商人住宅，這三棟房子目前已經改建成旅館，有興趣的朋友可以瀏覽這個旅館的官方網站 The Three Sisters Hotel，還可以看到 1880 年、1926 年、1939 年、1950 年、2003 年、2009 年三姐姊居逐漸改建的樣貌。

在離開帕特庫利觀景台之前，來個全景環場影片吧。

聖靈教堂 (Püha Vaimu kirik)

「聖靈教堂」(Püha Vaimu kirik)，是一座中世紀時期建造的路德教派教堂。此教堂著名的，應該是教堂外世洛克式的木雕古鐘，時至今日都還準確運作當中。

塔林市政廳 (Tallinna raekoda)

最後，來到塔林古城的中心「塔林市政廳」(Tallinna raekoda)廣場。

今天逛了許多塔林古城的著名景點，晚餐就在美好的淡菜義大利麵料理中劃下美好的句點。

由於，住宿飯店的 B1 就是個商場，所以在回房間休息前，前往我旅途中最喜歡逛的地方「超級市場」。😁

回到房間後，拉開窗簾仍然可以遠眺塔林古城和「歐拉夫斯大教堂」(St. Olaf's Church)，在旅途中能夠有這樣的美景一同入眠，相信往後每每回味時仍然會興奮不已 (這才是人生!!)

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

波波斯之旅 - 啟程
波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
(本文) 波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
波波斯之旅 - Day03 - 拉脫維亞 / 里加 (撰寫中...)
波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮 (撰寫中...)
波波斯之旅 - Day05 - 立陶宛 / 十字架山 (撰寫中...)
波波斯之旅 - Day06 - 波蘭 / 華沙 (撰寫中...)
波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮 (撰寫中...)
波波斯之旅 - Day08 - 波蘭 / 克拉科 (撰寫中...)
波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營 (撰寫中...)
波波斯之旅 - Day10 - 波蘭 / 塔特拉山 (撰寫中...)
波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡 (撰寫中...)
波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡 (撰寫中...)
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽 (撰寫中...)
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)

↧

網管人 161 期 - 實作 vCenter 內嵌部署模式輕鬆掌握 PSC 同步狀態

June 15, 2019, 9:41 am

≫ Next: 波波斯之旅 - Day03 - 拉脫維亞 / 里加

≪ Previous: 波波斯之旅 - Day02 - 愛沙尼亞 / 塔林

網管人雜誌

本文刊載於網管人雜誌第 161 期 - 2019 年 6 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。

文章目錄

前言
External 部署模式 – 架構複雜不易維護
棄用 External 部署模式
轉換 External 至 Embedded 部署模式
增強型 Embedded 部署模式 – 架構簡單易維護
實戰 vCenter Embedded Linked Mode
部署第一台 vCenter Server
部署第二台 vCenter Server
單台 vCenter Server 需要技術支援時
管理憑證
查詢 Embedded PSC 同步狀態
結語

前言

對於導入 VMware vSphere 虛擬化技術的企業和組織來說，vCenter Server 管理平台的重要性不言而喻。過去，當 vSphere 管理人員，在規劃和部署 vCenter Server 管理平台時，第一項規劃重點便是選擇 vCenter Server 作業系統類型，需要採用 Windows Server 或 SUSE Linux 作業系統。

請注意! VMware 官方已經正式宣佈，現行主流的 vSphere 6.7 版本，將是最後一版vCenter Server for Windows，後續版本僅會推出由 SUSE Linux 作業系統，更改為 Photon OS 的 vCSA（vCenter Server Appliance）管理平台。

第二項規劃重點則是選擇部署模式（如圖 1 所示），一般來說中大型規模 vSphere 叢集環境，建議採用運作角色分離的「External Deployment」模式，也就是將 PSC（Platform Services Controller）角色，和 vCenter Server角色，分開部署和運作在不同主機上。倘若，為小型規模 vSphere 叢集環境時，則建議採用運作角色集中的「Embedded Deployment」模式，便於管理和進行維護作業。

在 vSphere 叢集運作環境中，已經支援「混合環境」（Mixed Environment），除了可以將 vCenter Server 和 PSC 角色，分別運作在實體伺服器或 VM 虛擬主機之外，也可以分別運作在 Windows Server 或 vCSA 作業系統中。

圖 1、vCenter Server 運作角色示意圖（Embedded 和 External 部署模式）

圖片來源： VMware vSphere Blog - Upgrading your vCenter Server Appliance from 6.5 to 6.7

External 部署模式 – 架構複雜不易維護

事實上，在過去的 vCenter Server 5.x版本中，由於 vCenter Server 核心服務過多的關係，因此隨著企業和組織建構的規模不斷成長時，必須將 vCenter Server 核心服務拆開運作，以便因應大型規模運作環境，導致 vCenter Server 服務可能必須分別運作在「六台」主機上，包括，vCenter Server 資料庫、vUM 安全性更新管理員……等角色。

因此，從 vCenter Server 6.0 版本開始，核心服務集中為僅有 vCenter Servre 和 PSC 角色，所以企業和組織，只要將 vCenter Server 和 PSC 角色，分別運作在「兩台」主機上，即可因應中大型規模運作環境的需求。

如上所述，在中大型 vSphere 叢集環境時，部署模式必須採用 External Deployment運作模式，以便將 vCenter Server 和 PSC 角色，分別部署在兩台不同的主機上，因應中大型規模運作環境的需求。然而，考量企業和組織正式營運環境的 SLA 水準，勢必需要為 vCenter Server 管理平台和 PSC 角色，建立 HA（High Availability）高可用性機制（如圖 2 所示），以便因應故障損壞或災難事件的發生。

圖 2、External Deployment 部署模式 HA 高可用性運作架構示意圖

圖片來源： VMware vSphere Blog - vCenter Server 6 Deployment Topologies and High Availability

同時，採用中大型 vSphere 叢集規模的企業和組織，通常也有跨越全球多個站台的運作需求。因此，vSphere 管理人員必須規劃和部署，多個站台以及 vCenter Server 和 PSC 的 HA 機制，並且搭配 SSO Domain 身份驗證機制（如圖 3 所示），以便 vSphere 管理人員可以跨越多個站台，同時管理不同的 vCenter Server 和 PSC 運作架構。

圖 3、External Deployment 部署模式多個站台運作架構示意圖

圖片來源： VMware vSphere Blog - vCenter Server 6 Deployment Topologies and High Availability

如上所述，管理人員可以看到，隨著 vSphere 叢集運作規模逐漸擴大，同時導入 HA 高可用性機制和多個站台之後，除了整體 vSphere 運作架構複雜性不斷增加之外，還必須額外建立網路流量的負載平衡機制，確保 HA 高可用性機制能夠正常運作，上述種種對於企業和組織來說，不管在 IT 預算或維運人力上都逐漸形成困擾。

棄用 External 部署模式

因此，VMware 官方收集到大量使用者意見反應後，在 2018 年 11 月時正式發佈，External PSC 部署模式將會被「棄用」（Deprecated），同時表示後續新版本的 vCenter Server，將不會再有 External PSC 的部署選項。

請注意! VMware 官方已經宣佈，現行主流的 vSphere 6.7 版本，將是最後一版 vCenter with External PSC in Enhanced Linked Mode，後續新版僅有 vCenter with Embedded PSC in Enhanced Linked Mode。詳細資訊，請參考 VMware KB 60229知識庫文章內容。

轉換 External 至 Embedded 部署模式

那麼，原本已經採用 External 部署模式，建立 vSphere 叢集環境的企業和組織，應該如何轉換或遷移，架構簡單且容易維護的 Embedded 部署模式？事實上，當 VMware 宣佈棄用 External 部署模式時，便同時發佈「Converge Tool」轉換工具。

然而，在採用 Converge Tool 轉換工具之前，有相關注意事項必須考慮。首先，Converge Tools 不支援 Windows vCenter Server 管理平台，同時採用的 vSphere 版本，至少為 vSphere 6.5 Update 2d 或 vSphere 6.7 Update 1 或更高版本，才能夠使用 Converge Tool 轉換工具，將 External 部署模式轉換為 Embedded 部署模式（如圖 4 所示）。

圖 4、透過 Convergence Tool 轉換 External 至 Embedded 部署模式

圖片來源： VMware vSphere Blog - Understanding the vCenter Server Converge Tool

第二個注意事項，當管理人員在執行轉換作業之前，必須先分析目前採用的 SSO Domain 中，有哪些 VMware 解決方案，已經在 SSO Lookup Service 進行註冊的動作，例如，NSX、SRM（Site Recovery Manager）……等，因為當部署模式轉換作業執行完成後，管理人員需要手動將這些解決方案，重新組態設定到 Embedded 部署模式的 vCenter Server 中。

倘若，管理人員無法確認哪些 VMware 解決方案，已經向 SSO Lookup Service 進行註冊的話，可以開啟 vCenter Server 的 SSH 連線功能，採用管理者帳號登入後，執行「python /usr/lib/vmidentity/tools/scripts/lstool.py list --url http://localhost:7080/lookupservice/sdk」指令，即可顯示 SSO Lookup Service 的註冊服務清單。

有關查詢指令的詳細資訊，請參考 VMware KB 2043509知識庫文章內容。

此外，管理人員倘若無法確認，vCenter Server 主機指向哪台 PSC 的話，可以分別透過兩種方式進行確認。首先，在 vSphere HTML5 Client 管理介面中，依序點選「vCenter Server > Configuration > Settings > Advanced Settings」項目，然後在 vCenter Server 進階組態設定清單中，查看「config.vpxd.sso.admin.url」欄位，便是 vCenter Server 主機指向的 PSC 角色主機資訊（如圖 5 所示）。

圖 5、透過 GUI 圖形模式，查詢 vCenter Server 主機指向的 PSC 角色主機資訊

管理人員若希望透過 CLI 指令模式，查詢 vCenter Server 主機指向的 PSC 角色主機資訊，請開啟 vCenter Server 的 SSH 連線功能，並採用管理者帳號登入後，先執行「hostname」指令，確認目前的 vCenter Server 主機名稱，接著執行「/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost」指令，即可查詢 vCenter Server 主機指向的 PSC 角色主機資訊（如圖 6 所示）。

圖 6、透過 CLI 指令模式，查詢 vCenter Server 主機指向的 PSC 角色主機資訊

完成上述前置作業後，管理人員即可執行 Converge Tool 轉換工具，將 External 部署模式轉換為 Embedded 部署模式。

增強型 Embedded 部署模式 – 架構簡單易維護

因此，從 vSphere 6.5 Update 2 版本開始，VMware 在整合多台 vCenter Server 的「連結模式」（Linked Mode）機制中，開始支援運作架構簡單且容易維護的部署模式，稱之為「vCenter Embedded Linked Mode」或「vCenter with Embedded PSC in Enhanced Linked Mode」。

簡單來說，可以將多台採用 Embedded 部署模式的 vCenter Server，在同一個網域中互相串聯起來，並且這樣的運作架構完全支援中大型運作規模。值得注意的是，vCenter Embedded Linked Mode 運作架構，不支援 Windows vCenter Server。下列便是 vCenter Embedded Linked Mode 的優點：

無須 External PSC 角色，除了減少主機數量之外，整體的部署和運作架構更為簡單。
透過 File-Based 機制，即可輕鬆達成 vCenter Server 的備份和還原的目的。
無須額外建置負載平衡機制，簡化整體架構中的 HA 高可用性機制。
支援 vSphere SSO（Single Sign-On）機制，除了達成更高的管理靈活性之外，在單一 vSphere SSO Domain中，最多可連結 15 台 vCenter Server 主機（如圖 7 所示），並且集中於單一管理視窗中。
支援 VAMI（vSphere Appliance Management Interface）管理介面，搭配整合的 UX Guidelines、HTML/CSS Framework、Angular…… 等技術，讓管理人員透過 Clarity UI 管理介面，輕鬆維護 vCSA 資源管理工作任務。

圖 7、vCenter Embedded Linked Mode 運作架構示意圖

圖片來源： VMware Docs - vCenter Embedded Linked Mode for a vCenter Server Appliance with Embedded Platform Services Controller

實戰 vCenter Embedded Linked Mode

在本文實戰環境中，我們將採用二台 vCenter Server 管理平台，並且安裝最新 vCSA 6.7 Update 1版本，實作 vCenter Embedded Linked Mode，並且 SSO Domain 名稱為「vsphere.weithenn.org」，搭配管理人員習慣的最新管理工具，vSphere HTML 5 Client 管理工具。

倘若，管理人員習慣使用 CLI 文字介面進行部署作業，部署第一台 vCenter Server 時，請採用 Embedded_vCSA_on_ESXi.json檔案，部署第二台 vCenter Server 時，請採用 embedded_vCSA_replication_on_ESXi.json即可。

部署第一台 vCenter Server

事實上，在 vCenter Embedded Linked Mode 運作架構中，部署第一台 vCenter Server 管理平台的方式，與一般部署 vCenter Server Embedded 模式相同。因此，我們僅針對安裝流程中，需要管理人員注意的地方進行說明。

在 vCenter Server 安裝流程中，請於部署流程 Stage1 的第三個步驟，在 Select deployment type 頁面中，請選擇採用「Embedded Platform Services Controller」模式（如圖 8 所示），進行 vCenter Server 的部署作業。

圖 8、採用 Embedded 模式部署第一台 vCenter Server

在 Stage1 部署流程中，第一台 vCenter Server 的相關組態設定資訊，在本文實作環境中 VM 虛擬主機名稱為「vCSA01」、FQDN 名稱為「vcsa01.vsan.weithenn.org」、IP 位址為「10.10.75.67」。

在 Stage2 部署流程中，首先，由於屆時 vCenter Embedded Linked Mode 運作架構，為多台 vCenter Server 互相連結並同步相關資訊，因此請確保 vCenter Server 套用 NTP 時間校時機制。在第三個步驟 SSO Configuration 頁面時，請選擇「Create a new SSO domain」項目，並採用「vsphere.weithenn.org」為 SSO Domain 名稱（如圖 9 所示）。

圖 9、第一台 vCenter Server 選擇 Create a new SSO domain 選項

部署完第一台 vCenter Server 後，確認是否能夠採用 SSO Domain 加上管理者帳號，登入 vSphere HTML 5 Client 管理介面，本文實作環境採用「Administrator@vsphere.weithenn.org」登入後，建立資料中心名稱為「Datacenter01」，以及叢集名稱為「Cluster01」（如圖 10 所示），以便稍後與第二台 vCenter Server 運作環境，能夠比較差異並進行識別。

圖 10、第一台 vCenter Server 部署完成，建立 Datacenter 和 Cluster

部署第二台 vCenter Server

確認第一台 vCenter Server 順利運作，並且透過建立的 SSO Domain 登入 vSphere 環境後，接著便可以部署第二台 vCenter Server 管理主機。

同樣的，絕大部分的部署流程與組態設定，都與一般部署 vCenter Server Embedded 模式相同。因此，我們僅針對安裝流程中，需要管理人員注意的地方進行說明。在第二台 vCenter Server 安裝流程中，請於部署流程 Stage1 的第三個步驟，於 Select deployment type 頁面中，同樣選擇採用「Embedded Platform Services Controller」模式，進行 vCenter Server 的部署作業。

在 Stage1 部署流程中，第二台 vCenter Server 的相關組態設定資訊，在本文實作環境中 VM 虛擬主機名稱為「vCSA02」、FQDN 名稱為「vcsa02.vsan.weithenn.org」、IP 位址為「10.10.75.68」（如圖 11 所示）。

圖 11、部署第二台 vCenter Server 管理平台 Stage1 安裝流程

在 Stage2 部署流程中，首先，請確保第二台 vCenter Server 管理主機，已經套用 NTP 時間校時機制，以避免在 vCenter Embedded Linked Mode 運作架構中，多台 vCenter Server 互相連結時，因為主機時間不同步造成非預期的錯誤發生。

在第三個步驟 SSO Configuration 頁面時，請選擇「Join an existing SSO domain」項目，並鍵入第一台 vCenter Server 管理主機資訊，以及所建立的 SSO Doamin 資訊。在本文實作環境中，Embedded PSC 欄位，為第一台 vCenter Server 主機「vcsa01.vsan.weithenn.org」，至於 SSO Domain 名稱欄位，請填入「vsphere.weithenn.org」即可（如圖 12 所示）。

圖 12、部署第二台 vCenter Server 時，加入已建立的 SSO Domain

部署完第二台 vCenter Server 後，確認是否能夠採用同樣的 SSO Domain 加上管理者帳號，登入 vSphere HTML 5 Client 管理介面，本文實作環境採用「Administrator@vsphere.weithenn.org」登入後，建立資料中心名稱為「Datacenter02」，以及叢集名稱為「Cluster02」。

如圖 13 所示，可以在 vSphere HTML 5 Client 管理介面中，同時看到二台 vCenter Server 管理主機，所管理的資料中心、叢集、資源集區、VM 虛擬主機 …… 等，表示 vCenter Embedded Linked Mode 已部署完成，並且依序點選「vCenter Server > Linked vCenter Server Systems」項目，可以看到二台 vCenter Server 管理主機互相連結，當然後續若更多 vCenter Server 主機加入連結，便可以看到更多台 vCenter Server 主機。

圖 13、vCenter Embedded Linked Mode 部署完成

單台 vCenter Server 需要技術支援時

由於，vCenter Embedded Linked Mode 運作架構已經成形，所以在 vSphere HTML 5 Client 管理介面中，可同時管理不同 vCenter Server 運作環境。然而，當某個 vCenter Server 和管理站台，發生難以排除的故障事件，需要請求 VMware 技術支援時，該如何匯出個別 vCenter Server 主機資訊，以利 VMware 技術人員進行故障排除。

登入管理介面後，請依序點選「Menu > Administration > Deployment > System Configuration」項目，即可看到 vCenter Embedded Linked Mode 中，所有加入連結的 vCenter Server 主機，包括 vCenter Server 部署模式、版本、主機名稱 …… 等資訊，接著只要點選希望匯出資訊的 vCenter Server，再點選「Export Support Bundle」項目（如圖 14 所示），在彈出視窗中勾選所要匯出的項目，即可下載 vCenter Server 主機技術支援資訊檔案（.zip）。

圖 14、匯出指定的 vCenter Server 主機技術支援資訊

管理憑證

同樣的，在不同 vCenter Server 所管理的運作環境中，主機之間的連線和相關通訊，預設情況下採用不同的憑證，當管理人員需要管理個別 vCenter Server 憑證時，請於登入管理介面後，依序點選「Menu > Administration > Certificates > Certificate Management」項目，然後依序填入希望管理的 vCenter Server 主機資訊，包括 FQDN 或 IP 位址、管理者帳號、管理者密碼，按下「Login and Manage Certificates」鈕。

順利登入憑證管理頁面後，將會顯示目前登入的是哪一台 vCenter Server 主機，以及所採用的管理者帳號和憑證資訊，管理人員可以依據需求，查看不同用途憑證的內容，或是針對安全性憑證進行管理作業，例如，Renew 或 Replace 的動作（如圖 15 所示）。

圖 15、管理不同 vCenter Server 主機的安全性憑證

查詢 Embedded PSC 同步狀態

除了在管理介面查看相關資訊之外，倘若管理人員希望透過 CLI 文字介面，查詢 Embedded PSC 同步資訊，可以透過 SSH 連線方式，登入同一個 SSO Domain 中的任意 vCenter Server 主機，即可進行相關資訊的查詢作業。

在本文實作環境中，透過 SSH 登入第一台 vCenter Server 主機（vcsa01.vsan.weithenn.org），通過身份驗證程序之後，請鍵入「shell」才會切換成 Bash 文字管理模式，鍵入「vdcrepadmin -f showservers」指令，搭配連線主機名稱、管理者帳號、管理者密碼，即可顯示目前同一個 SSO Domain 中，已經互相連結和同步 PSC 的 vCenter Server 主機資訊。

鍵入「vdcrepadmin -f showpartners」指令，則是顯示同一個 SSO Domain 中，此台 vCenter Server 主機中，PSC 角色的另一個合作夥伴資訊。由於，我們在第一台 vCenter Server 主機執行，所以顯示的合作夥伴資訊，為第二台 vCenter Server 主機（vcsa02.vsan.weithenn.org）。

最後，鍵入「vdcrepadmin -f showpartnerstatus」指令，顯示同一個 SSO Domain 中，與其它 PSC 角色合作夥伴之間，PSC 資料的「同步狀態」（Replication Status），其中 change number 欄位顯示的數值，表示「更新順序號碼」（Update Sequence Number，USN），也就是 PSC 角色之間的運作資訊的同步狀態（如圖 16 所示）。

有關 vdcrepadmin 指令的詳細資訊，請參考 VMware KB 2127057知識庫文章內容。

圖 16、查詢 PSC 角色之間的運作資訊的同步狀態

結語

透過本文的說明及展示後相信讀者已經了解，在建構 vCenter Server 管理平台時，採用 External 和 Embedded 部署模式有哪些差異，值得注意的是，由於 External 部署模式已經正式棄用，所以管理人員在建立新的 vCenter Server 時，應採用架構簡單容易維護的 Embedded 部署模式才對。

最後，實作演練如何在多台 vCenter Server 環境中，建立 vCenter Embedded Linked Mode，以便在單一管理介面中，即可同時管理多台 vCenter Server 運作環境，並且透過指令查詢 PSC 角色之間的同步狀態。

↧

波波斯之旅 - Day03 - 拉脫維亞 / 里加

June 18, 2019, 5:39 pm

≫ Next: 波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮

≪ Previous: 網管人 161 期 - 實作 vCenter 內嵌部署模式輕鬆掌握 PSC 同步狀態

準備離開塔林

一早醒來後，當然是先拉開窗簾看看清晨的塔林古城和「歐拉夫斯大教堂」(St. Olaf's Church)，用過早餐後，我們將要前往波羅的海第二個國家「拉脫維亞」(Latvija)。

用過早餐後離開「愛沙尼亞」(Estonia) 的首都塔林，準備前往「拉脫維亞」(Latvia) 第一座國家公園「高哈國家公園」(Jauja National Park)。在中間休息站時，總要解決人生三急的時候，來歐洲的朋友應該都知道，上洗手間是需要付費的，然而這家休息站很佛心的是，只要購買休息站商品超過 0.5 歐元即可免費上洗手間，當然就順手買了一包愛沙尼亞的「卡列夫」(Kalev) 巧克力餅干。

雖然是在鄰國，但前往「拉脫維亞」(Latvia) 也不可能中間只停一次休息站就可以到達，第二家休息站相對起來規模更大，這個休息站不收上洗手間的費用，所以就順手買了杯咖啡之外也逛一下休息站的小商場。

在這次的旅程中，常常在公路上看到一大片的油菜花，數大便是美，當然就來個影片記錄一下了。

在抵達「拉脫維亞」(Latvija)邊界時，領隊貼心的讓我們順道下車看看「波羅的海」(Baltic Sea)。事實上，波羅的海三小國甚至是波蘭都緊臨波羅的海，簡單來說它是中歐和北歐之間的陸間海。

圖片來源：波羅的海 - 維基百科，自由的百科全書

在離開波羅的海之前，來個全景環場影片吧。

在參觀下午的行程之前，已經來到中午用餐時間了。今天的午餐是「拉脫維亞燉肉餐」，餐廳是一家很有風味的木頭式建築，搭配著美好的天氣和用餐環境。😋

希古達中世紀城堡 (Sigulda Medieval Castle)

用過午餐後，來到今天行程的第一個景點「希古達中世紀城堡」 (Sigulda Medieval Castle)，建於 1207 年的希古達城堡，早期主要功能是防禦類型的城堡後來被重建成為修道院，在 18 世紀戰爭期間城堡毀壞，直到 1962 年才開始進行古堡的研究和修復作業。現在，每年夏天時節常常會舉辦露天音樂廳傳統歌劇等節目。

拐杖公園 (Spieķu parks)

在「拉脫維亞」(Latvija)的希古達小鎮，可以看到許多彩色的拐杖，當然逛完希古達城堡之後一定要來知名的「拐杖公園」 (Spieķu parks)拍照一下了。

好人洞穴 (Gutmanis Cave)

事實上，在「拉脫維亞」(Latvija)的高哈國家公園內有許多溶洞，其中最知名的便是「好人洞穴」 (Gutmanis Cave)，它是拉脫維亞最古老的觀光遺址，從下列照片中可以看到，大家簽名到此一遊的歷史之久遠 (當然，現在不可能再讓你簽名了 😁)。此外，還有一段關於「圖雷達玫瑰」(Rose of Turaida)殉情的故事，有興趣的朋友可以深入了解一下故事內容。

在離開好人洞穴之前，來個全景環場影片吧。

在步行至好人洞穴的途中，有經過一處在販賣拉脫維亞當地甜點的小販，當去好人洞穴之前非常熱情的招呼我們試吃，回程時就順手買了一些甜點來試試看 (貪吃為最高指導原則! 😚)

圖雷達城堡 (Turaidas Castle)

來到今天行程的重頭戲「圖雷達城堡」 (Turaidas Castle)，建於 13 世紀據說是以「上帝的花園」來命名的，一開始為木造城堡後來逐漸加上城牆成為防禦性城堡，在 1776 年時城堡遭受大火，直到 20 世紀時才開始古堡的重建和研究工作，並且開放給一般遊客可以進行參觀。

可以登上塔樓! 當然，三步當成二步快馬爬上去了，登高望遠，心曠神怡。

當然，也要來個圖雷達城堡塔樓登頂環場，讓往後回憶時還能感受到塔樓的感覺。

里加 (Riga)

離開圖雷達城堡之後，來到「拉脫維亞」(Latvija)的首都「里加」(Riga)。抵達後，我們今天住宿的飯店，是一家非常有古城感覺又融合現代化的飯店。

放下行李後，我們進到里加舊城區，享用今天的晚餐「豬肋排餐」，結束今天的旅程。

明天就會進行里加老城區深度旅遊了，今天先在里加老城區廣場來個環場後就去享用晚餐吧。

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

波波斯之旅 - 啟程
波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
(本文) 波波斯之旅 - Day03 - 拉脫維亞 / 里加
波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮 (撰寫中...)
波波斯之旅 - Day05 - 立陶宛 / 十字架山 (撰寫中...)
波波斯之旅 - Day06 - 波蘭 / 華沙 (撰寫中...)
波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮 (撰寫中...)
波波斯之旅 - Day08 - 波蘭 / 克拉科 (撰寫中...)
波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營 (撰寫中...)
波波斯之旅 - Day10 - 波蘭 / 塔特拉山 (撰寫中...)
波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡 (撰寫中...)
波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡 (撰寫中...)
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽 (撰寫中...)
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)

↧

波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮

June 20, 2019, 5:50 pm

≫ Next: vSAN 6.7 Update 1 的 RSS Engine 問題導致 PSOD

≪ Previous: 波波斯之旅 - Day03 - 拉脫維亞 / 里加

倫達爾宮 (Rundale Palace)

今天行程的第一個重要景點就是「倫達爾宮」 (Rundale Palace)，它是拉脫維亞最華麗且典型的巴洛克和洛可可式風格的大型宮殿，建造期間為 1736 ~ 1768 年。

由於，在查「倫達爾宮」 (Rundale Palace)資料時，發現維基百科這張鳥瞰圖實在太棒了，我是無法拍出這樣的照片 (~~即便我有空拍機也無法吧~~)，所以也讓大家欣賞一下從空中鳥瞰倫達爾宮。

圖片來源： Rundāle Palace - Wikipedia

從停車場下車後，步行一小段距離並經過倫達爾宮前的小型花園後，來到倫達爾宮的大門口了，真的是非常典型的歐洲華麗宮殿。

在等待進入倫達爾宮前，大家都注意到倫達爾宮門口屋頂上，有鸛鳥 (Ciconiidae)築巢生活中，記得牠們發出的聲音非常特別，因為跟打石機非常像。(先前去摩洛哥和埃及時，也經常會看到鸛鳥)。

在進入倫達爾宮之前，來個環場影片吧。

在等待領隊和導遊安排好參觀倫達爾宮之前，在等待到處逛逛，意外發現可以捐款給倫達爾宮的小型捐獻箱。那麼，開始參觀倫達爾宮吧。

過去，貴族們雖然住在大型宮殿內，並且有眾多僕人們服待生活起居，但是大家都知道歐洲的冬天非常冷，那麼貴族們的暖爐們是什麼，答案就是這張圖啦。

首先，我們來到倫達爾宮的金廳，果然金碧輝煌啊。

離開倫達爾宮的金廳之前，來個環場影片吧。

穿過倫達爾宮長廊時，在長廊的展示櫃中收藏許多精美的扇子。當然，在眾多具有歐洲風格的扇子中，吸引我目光的就是中國風格的扇子了。

接著，來到倫達爾宮另一個華麗的白廳，雖然不像金廳那樣金碧輝煌，但仍然可以感受到濃濃的貴族風格。

離開倫達爾宮的白廳之前，來個環場影片吧。

來到貴族的書房逛逛，感受一下書香氣息。

接下來的玻瑰屋，雖然不像金廳和白廳那樣霸氣華麗，但仍然可以感受到非常精緻。

事實上，我們現在看到內部美倫美奐的倫達爾宮，躲過無情戰爭摧毀並且一路保持華麗到現在嗎？當然不是，要維持一座大型宮殿的運作是非常不容易的，從圖中可以看到，每個廳堂我們所看到的華麗雕像和畫作，早就隨著時間而凋零失色，多虧藝術家們的巧手修復後，我們才有機會再看到和感受到古時貴族的華麗宮殿。

各位，有看過古代貴族高級的衛浴設備 (浴缸和馬桶) 嗎？一起開開眼界吧。😎

陸續又參觀臥房、飯廳、娛樂室……等。大家應該已經發現，古代貴族的臥房雖然華麗，但是床怎麼那麼小？難道古代貴族身形很小嗎？都不高嗎？當然不是，因為古代的貴族們有個迷信，如果躺平睡覺的話就跟重病或往生者一樣的姿勢，所以都是坐著睡覺。因此，古代貴族的床才會這麼小。

參觀完倫達爾宮的內部後，剩下一點時間參觀後花園的部份。

在結束參觀倫達爾宮之後，離開這個景點前來個後花園的環場影片吧。

結束華麗的倫達爾宮行程後，在回里加老城區的路途中，休息一下順便享用今天的午餐「里加鮮魚料理」。

里加中央市場 (Rīgas Centrāltirgus)

貼心的領隊和導遊，讓我們在午餐飯後來逛逛「里加中央市場」(Rīgas Centrāltirgus)，並且在進入市場之前，不忘再次提醒我們注意自己的重要身外物，免得壞了遊玩的好興緻。

如果，你問我都吃飽午餐了來逛逛市場有什麼好玩的，我只能回答你，難道不知道正餐跟甜點的胃是分開的嗎？ 😂 想當然耳，除了買草莓之外也還買了一些餅乾和麵包 (即便現在塞不進胃裡，稍待一會就可以了，對吧! 😋)。

里加 (Riga)

那麼，從下午開始就是里加古城巡禮吧! 一般通稱的里加古城，全名為「里加歷史中心 Historic Centre of Riga」，在 1997 年時入選 UNESCO 世界文化遺產。下列是 UNESCO 針對里加古城給予的評價：

里加是「漢薩同盟」(Hanseatic League)的一個主要中心，它與中歐和東歐的貿易在13世紀至15世紀時期一度非常繁榮。儘管大部分的早期建築受到火災和戰爭的破壞，但是中世紀中期的城市建築仍然能反映出當時的繁榮。在 19 世紀時里加成為重要的經濟中心，中世紀城鎮的市郊已經建成，風格從開始的古典木製建築逐漸轉入「新藝術」風格。里加也是公認為歐洲最精美的「新藝術」建築風格的中心。

瑞典門 (Zviedru vārti)

走進里加古城後，第一個知名景點就是「瑞典門」(Zviedru vārti)，是在 1698 年興建里加城牆時的一部份，當時的人必須通過此門才能通往城牆外的瑞典軍營而稱之，是目前里加古城中唯一保留下來的城門。

這位是今天陪伴我們的當地導遊 Jennifer，正在細心的跟大家說明里加古城和瑞典門的由來。

在里加城牆後，突然有個「The Ghost」雕像，可以從說明中看到是 2015 年才加上此雕像，應該也是響應「新藝術」建築風格所加入的元素。

火藥塔 (Pulvertornis)

「火藥塔」(Pulvertornis)，原本是屬於里加城牆防禦體系中的一部份，在 1621 年時瑞典入侵拉脫維亞的戰爭中，火藥塔遭到摧毀只剩下地基的部份，後續則在 1650 年時採用原本留下的地基進行重建。

在離開火藥塔之前，來個環場影片感受一下吧。

在離開火藥塔後的下一個馬路口，偶然看到這片牆上佈滿貴族家徽。在世界歷史上，主要採用家徽的國家只有日本和歐洲天主教國家，但是這兩者之間的家徽並沒有任何關聯且各自發展。

自由紀念碑 (Brīvības piemineklis)

自由紀念碑 (Brīvības piemineklis)，是為了紀念拉脫維亞獨立戰爭期間英勇犧牲的軍人而建立的，也是象徵拉脫維亞「自由、獨立、主權」的重要精神象徵。

這是有什麼特殊意義的景點嗎？是的，就是拉脫維亞知名的巧克力品牌「LAIMA」😆。

波羅的海之路 (Baltijas ceļš)

這個腳印是什麼？大家仔細聆聽當地導遊 Jeniffer 細細道來，它是「波羅的海之路」(Baltijas ceļš) 的參與者腳印。由於，在 1989 年 8 月 23 日的一次和平示威，共有超過 200 萬人加入這場活動，從波羅的海三小國 (愛沙尼亞、拉脫維亞、立陶宛)，大家手牽手拉成一個長度超過 600 公里的隊伍，希望世界能夠關心波羅的海三小國共同的歷史遭遇，也就是追求脫離蘇聯的統治。

圖片來源：波羅的海之路 - 維基百科，自由的百科全書

在前往聖彼得教堂的途中，漫步在里加古城區，好好享受經過的每條街道每個路口，這都是日後回憶的重要養份。

聖彼得教堂 (St. Peter's Church)

建於 1209 年的「聖彼得教堂」 (St. Peter's Church)，在第二次世界大戰之前是歐洲最高的木造建築，然而在戰爭無情的摧毀下，造成屋頂和鐘樓都毀大火當中。現在，我們所看到的聖彼得教堂是在 1746 年後才重新修復完工的。

在聖彼得教堂旁有個動物雕像，我想這不用多說，但凡在歐洲只要看到雕像並且哪裡亮就往那裡摸就對了，肯定會帶來好運!! 😁

從昨天下午進入里加古城後，一直看到的聖彼得教堂，終於能夠從正面拍下它的美。

當然，離開聖彼得教堂之前，一定要來個環場影片紀錄下來。

黑人頭兄弟會 (Melngalvju nams)

黑人頭兄弟會 (Melngalvju nams)，最早是興建於 14 世紀初期，是由里加未婚的德國商人組建的行會，為什麼看起來這麼新？因為，它在第二次世界大戰期間，遭到德國飛機轟炸後變成廢墟了，目前這個新建築是在 1995 ~ 1999 年重建的，我們的導遊 Jennifer也有參與捐助這個黑人頭兄弟會的重建作業。😍

當然要給黑人頭兄弟會來個環境影片，一定要來個環場影片紀錄下來。

事實上，黑人頭兄弟會前的廣場，是當時的市政廳廣場，在廣場中央的是「羅蘭雕像」 (Roland Statue)。

在離開前，找了個不錯的角度，可以把聖彼得教堂、黑人頭兄弟、羅蘭雕像一起收錄下來。

當然站在市政廳廣場前感受時，不忘來個環場影片紀錄下來。

三兄弟屋 (Trīs brāļi)

跟我們在波波斯之旅 - Day02 - 愛沙尼亞 / 塔林遊記中，看到的「三姐妹居」(The Three Sisters)概念相同，這是拉脫維亞的「三兄弟屋」 (Trīs brāļi)，其中最右手邊馬薩比爾森街 17 號的房屋歷史最悠久，是建於 15 世紀的哥德式建築，大家可以發現它的窗戶非常的小，主要原因是當時會課徵「窗戶稅」(Windows Tax)，也就是「窗戶越多 / 窗戶越大」課的稅就會越重，所以才會導致窗戶這麼小。

離開三兄弟屋之前，肯定要錄個環場影片記錄下來。

天主教教堂

事實上，今天里加古城的景點行程已經結束了，就當大家還在漫步享受這最後的里加古城氣氛時，在經過的天主教教堂中，似乎有個重要儀式即將舉行所以鐘聲不斷，在不打擾到儀式進行的情況下，很幸運的能夠拍攝到這一刻。

在不打擾到儀式進行的情況下，很幸運的能夠錄下這一刻。

今天，真的很高興有當地導遊 Jennifer詳細且精采的解說，在她離開前也跟我們專業的 Joanna 領隊 (兼全程導遊) 一起來張合照留念。

距離晚餐時間還有一小段時間，要去哪裡呢？當然，到昨天看到飯店附近的小店逛逛了，剛好也看到拉脫維亞知名的巧克力品牌「LAIMA」，並且一定要挑選我最愛的 % 數 (87% 不能再多了)。😝

晚餐，就在大家一片熱鬧的情況下結束，好好休息後準備明天精采的行程。

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

波波斯之旅 - 啟程
波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
波波斯之旅 - Day03 - 拉脫維亞 / 里加
(本文) 波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮
波波斯之旅 - Day05 - 立陶宛 / 十字架山 (撰寫中...)
波波斯之旅 - Day06 - 波蘭 / 華沙 (撰寫中...)
波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮 (撰寫中...)
波波斯之旅 - Day08 - 波蘭 / 克拉科 (撰寫中...)
波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營 (撰寫中...)
波波斯之旅 - Day10 - 波蘭 / 塔特拉山 (撰寫中...)
波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡 (撰寫中...)
波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡 (撰寫中...)
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽 (撰寫中...)
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)

↧

vSAN 6.7 Update 1 的 RSS Engine 問題導致 PSOD

June 23, 2019, 7:03 pm

≫ Next: Splunk 攻略

≪ Previous: 波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮

Question

vSAN 6.7 Update1發生 PSOD 事件，查看下列 PSOD 死當畫面，發現有 RSS Engine 和 RSS Plug Cleanup等關鍵字。

Answer

導致此問題的根本原因是 Load-Based NetQueue Balancer Module 所引起，當 ESXi 無法清理 RSS Engine Private Data 時就會引起 PSOD 事件 (詳細資訊請參考 VMware KB 58874 - RSSPlugCleanupRSSEngine purple diagnostic screen on ESXi 6.7)。

簡單來說，有下列二種解決方式 (擇一即可)：

解決方法一、更新 ESXi 6.7 Update 1 -> Update 2

將 ESXi 6.7 Update 1 更新至 ESXi 6.7 Update 2即可解決。詳細資訊請參考 VMware ESXi 6.7 Update 2 Release Notes - PR 2219661: An ESXi host might fail with a purple diagnostic screen if RSS is enabled on a physical NIC。

解決方法二、無法更新時的暫時作法

倘若，無法在短時間內將 ESXi 6.7 Update 1 更新至 ESXi 6.7 Update 2 時，可以先採用下列暫時的作法，將 ESXi 實體伺服器的 RSS 功能關閉，以避免發生 PSOD 事件。

esxcli network nic queue loadbalancer set --rsslb=false -n vmnicX

↧

Splunk 攻略

June 23, 2019, 11:16 pm

≫ Next: Splunk 基礎架構和運作元件

≪ Previous: vSAN 6.7 Update 1 的 RSS Engine 問題導致 PSOD

前言

因為工作關係，開始要學習 Splunk 的使用，那麼就依照慣例記錄學習 Splunk 的點點滴滴吧。在開始之前，如果你想了解 ELK (Elasticsearch / Logstash / Kibana)與 Splunk的差異，可以參考這篇文章 Splunk 和 ElasticSearch 深度对比解析- GitHub。

下列影片，是最新 Splunk Enterprise 7.3 版本的新功能介紹：

【簡介 / 安裝】

Splunk 基礎架構和運作元件
建立 Splunk 運作環境

【官網資源】

【官網免費線上課程】

↧

Splunk 基礎架構和運作元件

June 24, 2019, 12:08 am

≫ Next: 波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡

≪ Previous: Splunk 攻略

前言

在生活上不管食衣住行，都會產生許多資料無論是「結構化」(Structured) 或「非結構化」(Unstructured)，這在 Splunk 來說稱之為「機械資料」(Machine Data)。因此，Splunk 主要任務便是將這些資料收集後，希望達成透過收集/過濾/視覺化呈現/趨勢預測……等目標。

運作元件

在 Splunk 的基礎架構中，主要有三個運作元件「Indexer、Search Head、Forwarder」：

圖片來源：Splunk Free Courses - Splunk Infrastructure Overview

Indexer：主要負責 Indexing，接收到 Machine Data 之後轉換成 Event 然後存放於 Splunk Index 當中，屆時再由 Search Head 來搜尋和過濾出 Splunk Index 當中的有用資料。

圖片來源：Splunk Free Courses - Splunk Infrastructure Overview

Search Head：主要負責 Search Management，屆時 Splunk User 送出搜尋需求後，Search Head 去 Splunk Index 搜尋並過濾後，回應相關資訊給 Splunk User 並且可以透過視覺化呈現。

圖片來源：Splunk Free Courses - Splunk Infrastructure Overview

Forwarder：主要負責 Data Input，轉送資料給 Indexer 主機，最常見的應用是安裝在 Windows / Linux 主機上，轉送各種應用程式或服務資料至 Indexer 主機。例如，安裝在 Linux Web Server 主機上，然後轉送 Web Log 至 Indexer 主機。

圖片來源：Splunk Free Courses - Splunk Infrastructure Overview

事實上，除了「Indexer、Search Head、Forwarder」這三個主要角色之外，還有另外三個角色以後也會用到分別是「Deployment Server、Cluster Master、License Master」，後續有機會再了解吧。

圖片來源：Splunk Free Courses - Splunk Infrastructure Overview

部署架構

那麼要部署 Splunk 運作架構有哪幾種選擇，簡單來說，大概有下列三種選擇：

Single-Instance Deployment：All-in-One的架構，將 Input、Parsing、Indexing、Searching 等工作任務，全部安裝在同一台主機上，適合用於 POC、個人學習/測試...等環境。
Small Enterprise Deployment：將「Input」和「Parsing、Indexing、Searching」分開，簡單來說 Input 就是多台 Forwarder，搭配一台 Indexer / Search Head主機，通常處理 20GB per day的資料量，以及小於 20 位使用者進行搜尋任務。倘若，可以再將 Indexer 分散成建立三台 Indexers的話，那麼可以處理 100GB per day資料量，以及小於 100 位使用者進行搜尋任務。
Distributed Deployment：中大型架構，依據 Input、Parsing、Indexing、Searching 等工作任務需求，進行每個角色的主機台數擴充，甚至為了確保資料一致性和可用性，可以建立 Index Cluster。

圖片來源：Splunk Free Courses - Splunk Infrastructure Overview

參考資源

↧

波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡

June 25, 2019, 6:05 pm

≫ Next: Splunk Journey (02) - 建立 Splunk 運作環境

≪ Previous: Splunk 基礎架構和運作元件

離開拉脫維亞

一早起來用過豐盛的早餐 (~~飽肥早餐~~😁) 後，在踏出住宿旅館準備搭上遊覽車時，還能夠看看最後一眼「聖彼得教堂」 (St. Peter's Church)。

同樣的，雖然波羅的海三小國緊鄰在一起，但還是需要一點拉車時間才能到達。這次中途休息站，同樣沒有收上洗手間的費用，所以買了一些甜點和餅乾，到休息站外準備上車之前，還是忍不住走上前拍了一下非常大片的油菜花田。

離開休息站之前，忍不住想記錄一下休息站旁數大便是美的油菜花田。

十字架山 (Hill of Crosses)

「十字架山」 (Hill of Crosses)，位於立陶宛北部希奧利艾以北12公里處的一個朝聖地，真正的起源似乎已不可考，但公認的起源是與二次起義有關，在 1831 年和 1863 年分別起義反抗俄國但都未能成功，由於家人無法找到起義反抗者的屍體位置，他們便開始在十字架山放置十字架，逐漸演變成立陶宛人民「為和平、為國家、為立陶宛獨立戰爭」期間失去的親人祈禱的地方。直至 2006 年時，十字架山的十字架數量已經超過 10 萬個。

在步行至十字架山時，邊走邊錄環場影片感受一下現場氣氛。

離開十字架山時，在遊覽車旁又是一大片的油菜花田。

立陶宛國菜 - 齊柏林飛船

今天午餐要來嚐嚐知名的「立陶宛國菜 - 齊柏林飛船」(Cepelinai)，這道齊柏林飛船是用馬鈴薯和乳酪混合而成的外皮，裡面則是包裏著肉餡。那麼，為什麼要叫齊柏林飛船？原因是它的外型，跟德國的齊柏林飛船外型非常類似而得名的。

這家餐廳在我們前往立陶宛首都「維爾紐斯」(Vilnius) 的路途上，餐廳環境非常悠閒自在，所以吃完午餐之後便到餐廳後院走走，順便記錄這一刻悠閒。

特拉凱水中古堡 (Trakai Castle)

來到今天行程的重頭戲「特拉凱水中古堡」 (Trakai Castle)，它是立陶宛的國家歷史文物園區，也是「立陶宛大公國」(Lietuvos Didžioji Kunigaikštystė)主要中心之一，是在 14 世紀時由科斯圖提斯公爵所興建，可惜的是在 17 世紀時因為戰爭而被摧毀逐漸失修，所幸在 19 世紀時開始進行重建。

步行至特拉凱水中古堡的途中，邊走邊記錄這一刻。

步行五分鐘左右，來到特拉凱水中古堡的大門口，在等待領隊溝通導覽員的時間時，記錄一下特拉凱水中古堡雄偉外觀。

官方為了保持導覽的品質，所以有管制人員總數，所以我們在特拉凱水中古堡入口處，稍微再等待一下，便要開始進行特拉凱水中古堡的深度導覽。

等待進入特拉凱水中古堡導覽期間，記錄一下特拉凱水中古堡入口處。

當然，在進入古代的城堡之前一定都會先經過的護城河，那麼開始一層一層的了解特拉凱水中古堡歷史吧。

經過導覽員深入介紹特拉凱水中古堡的歷史，雖然在戰爭期間城堡毀壞許多文物遺失，但所幸在 19 世紀的重建，讓我們還是能夠一窺特拉凱水中古堡當時的氛圍。

經過深度導覽特拉凱水中古堡洗禮後，便要離開今天的景點行程，前往立陶宛首都「維爾紐斯」(Vilnius) 。

在準備離開特拉凱水中古堡之前，再來個環場影片記錄這一刻的美好。

正要上車之前，偶然看到鴨媽媽帶著 12 隻小鴨的情境非常可愛，很幸運的也記錄了這一刻。

傍晚，順利到達立陶宛首都「維爾紐斯」(Vilnius) ，今天的晚餐是住宿飯店的牛排餐非常不錯，吃完後晚餐後，當然還是習慣性的到住宿飯店附近的超市逛一逛。

逛歐洲的超市最讓我感到有趣的是，一般等級的「酒」常常會比可樂或水來的便宜 (雖然，我不喝酒)。😎

波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)

波波斯之旅 - 啟程
波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
波波斯之旅 - Day03 - 拉脫維亞 / 里加
波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮
(本文) 波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡
波波斯之旅 - Day06 - 波蘭 / 華沙 (撰寫中...)
波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮 (撰寫中...)
波波斯之旅 - Day08 - 波蘭 / 克拉科 (撰寫中...)
波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營 (撰寫中...)
波波斯之旅 - Day10 - 波蘭 / 塔特拉山 (撰寫中...)
波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡 (撰寫中...)
波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡 (撰寫中...)
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽 (撰寫中...)
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)

↧

Splunk Journey (02) - 建立 Splunk 運作環境

June 30, 2019, 10:56 pm

≫ Next: Ansible 攻略

≪ Previous: 波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡

前言

在前一篇文章中，大致了解 Splunk 基礎架構和運作元件後，接著就是建立 Splunk 測試環境了，你可以有各種方式建立 Splunk 測試環境，例如，安裝在實體伺服器、安裝在 VM 虛擬主機、安裝在 Container 當中……等。

詳細安裝資訊請參考下列官方文件，本文，將會採用 Splunk Enterprise on Azure 來建立測試環境。

圖片來源： Splunk Enterprise architecture and processes - Splunk Documentation

Splunk Enterprise on Azure

登入 Azure Portal 之後，只要點選「Create a resource」然後鍵入關鍵字「Splunk Enterprise」，即可找到 Azure Marketplace 中的 Splunk Enterprise，然後按下「Create」即可進入 Splunk Enterprise on Azure 工作流程。

在「1、Basics」建立流程中，請依序鍵入選擇 VM 虛擬主機名稱、管理密碼、Azure 訂閱、資源群組、資料中心…等，下列為本文實作環境：

VM 虛擬主機名稱： splunk-hol
VM 虛擬主機密碼： Weithenn$1688
資源群組： RG-EastAsia-SplunkHOL
Azure 資料中心： East Asia

在「2、Network Settings」建立流程中，請規劃 Splunk 運作環境的虛擬網路和網段，下列為本文實作環境：

虛擬網路名稱： splunkVnet
虛擬網路位址空間： 10.0.0.0/16
Search Head 子網路名稱： shsubnet
Search Head 位址空間： 10.0.0.0/24
Index 子網路名稱： idxsubnet
Index 位址空間： 10.0.1.0/24

在「3、Nodes Settings」建立流程中，請選擇 Splunk 的部署模式，在 Splunk Enterprise on Azure 環境中支援二種部署模式，分別是「Single Node」或「Cluster」差異如下：

Single Node：部署單台 VM 虛擬主機，並採用「Single-Instance Deployment」，將所有角色安裝於同一台 VM 虛擬主機中。
Cluster: 將會部署「Indexer Peers x 3、Cluster Master x1、Cluster Search Head x1」，並且每個 Indexer 將會配置「1 TB (Standard) x8」並建立 RAID-0，以便提供 3,000 IOPS 的儲存效能。這樣的部署模式可以處理「100GB per day」的資料量，並保留 7 個月的歷史資料 (如下圖所示)。

圖片來源： Announcing Splunk Enterprise in Microsoft Azure Marketplace

由於本文只是建立 Splunk Enterprise 的測試環境，所以選擇「Single Node」的部署模式，至於 VM Size 方面預設採用「Standard D5 v2」，請依需求自行選擇適合的 Azure Linux VM Size。

在「4、Solution Access」建立流程中，選擇 Splunk 運作環境的 Public IP、Domain Name、Splunk Web Administrator 管理密碼……等，下列為本文實作環境：

Splunk Public IP名稱： splunkIP
公開網域名稱：weithenn-splunk.eastasia.cloudapp.azure.com
Splunk Web Administrator 管理密碼： Weithenn@1688
IP Range to SSH from： 0.0.0.0/0
IP Range to receive data from： 0.0.0.0/0

在「5、Summary 和 6、Buy」建立流程中，再次檢視相關組態設定值，確認無誤後便準備部署 Splunk Enterprise 運作環境。

在本文實作環境中，花費「5 分 42 秒」即建立完成 Splunk Enterprise (Single Node) 運作環境。

建立完成的 Splunk Enterprise 運作環境，首先看看 NSG 預設允許的防火牆規則為「Port 22、443、8000、8088、8089、9997」。

在 vDisk 虛擬硬碟方面，建立「1 TB (Standard HDD) x8」。

現在，可以開啟瀏覽器鍵入剛才設定的「https://weithenn-splunk.eastasia.cloudapp.azure.com」網址，即可看到 Splunk Web Administrator 管理畫面，並採用預設的管理者帳號「admin」，以便剛才建立流程中所設定的密碼即可登入。