↧
[站長開講] Dell Technologies Forum 2019 (簡報已上傳)
↧
波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽
波耶尼切 (Bojnice)
早安，波耶尼切 (Bojnice)，一早醒來依照慣例拉開窗簾，看看這美好早晨的波耶尼切 (一張是早晨，一張是太陽已經露臉了)，稍後準備參觀今天第一個景點「波耶尼切城堡」。
美好早晨的波耶尼切，當然要用環場記錄這一刻了。
波耶尼切城堡 (Bojnice Castle)
從飯店步行前往「波耶尼切城堡」 (Bojnice Castle) 的途中，經過的公園充滿現代裝置藝術，當然不會放過這樣的景色，並且經過同團大哥的指導下，在薰衣草下遠照波耶尼切城堡取景，簡簡單單即可照出一幅美景 (這就是專業跟玩家的分別了，但話說我連玩家等級都稱不上😂)
通過充滿裝置藝術的公園後，終於來到了波耶尼切城堡的護城河 (已經沒有水了) 和入口，準備帶著興奮的心情參觀波耶尼切城堡。
環場記錄波耶尼切城堡外圍。
「波耶尼切城堡」 (Bojnice Castle) ，是興建於 12 世紀的一座中世紀時期古堡，雖然波耶尼切城堡乍看之下是一座羅馬式建築的城堡，然而它其實融合了哥德式和文藝復興式建築的氣息在裡面。在我們進入波耶尼切城堡後，馬上聽到敲敲打打的聲音，原來是有小販正在敲打各式紀念品。另外，有趣的是偶然抬頭一看，剛好因為陽光折射的關係在城堡屋頂處出現彩虹，當然馬上記錄這一刻了。
環場記錄波耶尼切城堡入口處。
待領隊與館方協調好導覽員之後，我們順利進入波耶尼切城堡內部參觀。進入後，雖然這幾天已經看過不少中古世紀的城堡，但還是被波耶尼切城堡內部的華麗給迷上。同時，除了看到一般的貴族起居室之外，還參觀到了娛樂室，真有趣。😚
環場記錄波耶尼切城堡內部。
環場記錄波耶尼切城堡內部。
環場記錄波耶尼切城堡內部。
參觀完波耶尼切城堡主要建築後，我們下樓前往第二個主要建築繼續參觀。
在波耶尼切城堡的第二個主要建築內部，還順便參觀到當時廚房的佈景，想像當時貴族仕紳們在交誼廳，而波耶尼切城堡的廚師們則在這裡忙進忙出的。
參觀完第二座建築後，我們來到波耶尼切城堡的後花園參觀。
最後，我們還參觀波耶尼切城堡地下的鐘乳石洞景觀，非常有趣。
環場記錄波耶尼切城堡地下的鐘乳石洞景觀。
斯洛伐克牛排餐
參觀完波耶尼切城堡後，已經到了午餐時間，今天的午餐是「斯洛伐克牛排餐」，整個用餐環境非常迷人，在現代化的建築內經常有傳統的巧思在裡頭。
用餐完畢正在閒逛時，突然發現這裡有販賣領隊在車上讓我們看的電影《茜茜公主》（Sissi）的酒。雖然，我不喝酒但是覺得有紀念價值，並且一瓶才 6 歐元而已不算貴，於是就大膽向櫃台詢問後購買 (後續，有團友看到後也覺得不錯進而買回去送人 😁)。有興趣深入了解「伊莉莎白皇后」(也就是她的小名 Sissi) 的朋友，就請自行參考維基百科內容和觀看該部電影吧。😊
最後，在我們離開前，領隊告訴我們這家餐廳有個很利害的古蹟，據說這是在 1759 年時羅馬軍團在馬爾馬里亞戰爭期間，刻下的碑文宣告戰爭獲得勝利，這也是在多瑙河北部最重要的羅馬書法紀念碑。
梅洛維廣場 (Mierové námestie)
享用完午餐後，我們來到昔日羅馬帝國最北邊的東歐軍營「勞加利西」(Leugaricio)。我們步行來到了下午的景點「梅洛維廣場」(Mierové námestie)，這裡是舊城區市中心的所在地，在梅洛維廣場的四周為過去居民所蓋的文藝復興式建築，廣場中央則是 1712 年歐洲黑死病紀念柱，從廣場中央可以遠眺特倫欽古堡 (很可惜，因為時間的關係，我們無法登上古堡)。
環場記錄步行至特倫欽梅洛維廣場。
環場記錄梅洛維廣場以及黑死病紀念柱。
步行一小段時間後，來到其中一個噴水藝術的地方，當然有水的地方就是小孩快樂的遊玩場地了。
環場記錄梅洛維廣場的噴水藝術。
環場記錄梅洛維廣場的搶食鴿子。
回程時，看到特倫欽的紀念金幣販賣機，同樣是二歐元即可入手，當然不能放過啦。
布拉提斯拉瓦 (Bratislava)
傍晚時分，我們來到斯洛伐克的首都「布拉提斯拉瓦」 (Bratislava)。由於，在晚餐前還有一點時間，所以入住飯店後領隊讓我們自由活動，當然我一定是往大賣場去逛逛了。今天晚餐同樣是享用飯店內三道式的精緻料理。
是的，飯店旁邊就是「多惱河」(Donau)，享用完晚餐後正是美麗的黃昏時分，一定要出去看看這美好的黃昏時分多惱河。
用環場來紀錄黃昏時分的多惱河才是最棒的。
嗯，逛完多惱河之後，雖然肚子不會餓，但是聽到同團友人剛才在逛商場時有發現美食，所以進去逛逛後就不小心手滑加菜了。😂
波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)
- 波波斯之旅 - 啟程
- 波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
- 波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
- 波波斯之旅 - Day03 - 拉脫維亞 / 里加
- 波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮
- 波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡
- 波波斯之旅 - Day06 - 立陶宛 / 維爾紐斯 / 波蘭 / 華沙
- 波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮
- 波波斯之旅 - Day08 - 波蘭 / 克拉科夫
- 波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營
- 波波斯之旅 - Day10 - 波蘭 / 塔特拉山
- 波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡
- 波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡
- (本文) 波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽
- 波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦 (撰寫中...)
- 波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)
↧
↧
網管人 164 期 - 實戰 vCenter Server 6.7 U2 亮點功能一次搜羅
網管人雜誌
本文刊載於 網管人雜誌第 164 期 - 2019 年 9 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。文章目錄
前言儲存功能亮點-支援 Apache Pass 技術
ROBO 授權功能再放寬-適用小型或分公司的 DRS-MM 模式
實戰 vCenter Server 6.7 Update 2
PSC 部署模式轉換工具
備份和還原支援更多通訊協定
不斷強化的 vSphere HTML 5 Client
更全面的健康狀態檢查機制
程式碼擷取和 API Explorer
vSphere Client Plug-ins
VM 虛擬主機最多支援至 256 vCPU
結語
前言
日前 2019 年 4 月 11 日時，VMware 官方正式發佈全新 vSphere 6.7 Update 2版本，同時也將 VMware SDDC 軟體定義資料中心內，相關解決方案版本同步推升到 Update 2 版本，例如，ESXi 6.7 Update 2 虛擬化平台、vCenter Server 6.7 Update 2 管理平台。當然，管理人員必須注意的是，舊版的 vSphere ESXi 5.5版本已經正式於 2018 年 9 月 19 日，進入「結束標準支援階段」（End Of General Support，EOGS），緊接著 vSphere ESXi 6.0 也將於 2020 年 3 月 12 日進入 EOGS 結束標準支援階段（如圖 1 所示）。
圖 1、VMware 產品生命週期表格
因此，企業或組織倘若仍使用舊有 vCenter Server 6.0 管理平台的話，應盡速執行版本升級計劃，否則將無法管理新版 ESXi 6.5 和 6.7 虛擬化平台（如圖 2 所示）。
圖 2、VMware 產品版本互動性操作表格
儲存功能亮點 - 支援 Apache Pass 技術
在最新的 vSphere 6.7 U2 版本中，支援 Intel Optane DC Persistent Memory 技術「Apache Pass」的二種模式，分別是「App-Direct」和「Memory」運作模式（如圖 3 所示），並且當配置 Persistent Memory 的 ESXi 虛擬化平台，採用「二顆」CPU 處理器時最高可支援至「6 TB」儲存空間，採用「四顆」CPU 處理器時最高可支援至「12 TB」儲存空間。注意! 請先透過「VMware 相容性指南」（VMware Compatibility Guide，VCG）網站，確認採用的伺服器支援配置 Persistent Memory，並且必須搭配 vSphere Enterprise Plus 軟體授權版本，才能支援和使用 Persistent Memory 特色功能。
圖 3、Persistent Memory 技術 App-Direct 和 Memory 運作模式示意圖
當配置的 Intel Optane DC Persistent Memory 採用 App-Direct 運作模式時，除了最大化使用 Persistent Memory 儲存空間之外，對於營運環境中支援的第三方應用程式，能夠提供耐用性和持久性的優點，一般情況下 VMware 建議採用此運作模式。
至於採用 Memory 運作模式時，由於此運作模式適用於需要大量記憶體容量的特殊運作環境，所以採用此運作模式之前，企業和組織必須先取得 VMware 技術支援的同意後才能啟用此運作模式。
雖然，在 ESXi 虛擬化平台的部份，可以支援最多 12 TB 的 Persistent Memory 儲存空間，然而在 VM 虛擬主機的部份，無論採用 App-Direct 或 Memory 運作模式，最多僅支援至「6 TB」vRAM 或 vNVDIMM 的儲存空間。
值得注意的是，即便採用目前最新版本的 vSAN 6.7 U1，仍尚未支援將 App-Direct 運作模式的儲存空間，用於 vSAN 的快取層級或容量層級中。然而，只要獲得 VMware 技術支援的允許，可以讓 vSAN 運作環境支援 Memory 運作模式。
ROBO 授權功能再放寬 - 適用小型或分公司的 DRS-MM 模式
在過去的 vSphere 版本中，企業和組織在建構遠端辦公室或分公司環境時，可以購買 vSphere ROBO（Remote Office Branch Office）軟體授權，即可輕鬆建構虛擬化環境並因應相關工作負載需求。但是，當採用 vSphere ROBO 軟體授權建構的 vSphere 叢集，必須進入維護模式以便執行升級或安全性更新時，並未具備 DRS 自動化遷移 VM 虛擬主機的特色功能，必須管理人員介入手動遷移 VM 虛擬主機後，才能讓 ESXi 叢集節點成員主機順利進入維護模式。
現在，最新的 vSphere 6.7 U2版本中新增 ROBO Enterprise 軟體授權，支援 DRS-MM（DRS in Maintenance Mode）和 VM 虛擬主機加密等特色功能。
值得注意的是，DRS-MM 模式與典型的 vSphere DRS 機制有些許不同，在標準的 vSphere 叢集中啟用 DRS 機制後，無論 ESXi 虛擬化平台是否進入維護模式，只要工作負載觸發 DRS 門檻值之後，便會自動遷移線上運作的 VM 虛擬主機。
然而，DRS-MM 則僅適用於 ROBO vSphere 叢集環境中，ESXi 叢集節點成員主機「進入維護模式」時，才會觸發 DRS 機制透過 vSphere vMotion 功能遷移線上運作的 VM 虛擬主機（如圖 4 所示）。
請注意! VMware 建議盡量避免在啟用 DRS-MM 的運作環境中，啟用 Affinity 或 Anti-Affinity 等關聯性原則，以避免屆時無法自動遷移 VM 虛擬主機。
圖 4、DRS-MM 機制-自動將 VM 虛擬主機遷出維護模式的 ESXi 主機運作示意圖
當啟用 DRS-MM 機制的 ROBO vSphere 叢集環境，ESXi 叢集節點成員主機完成升級或安全性更新的程序後，離開維護模式時便會再次觸發 DRS-MM 機制，將剛才進入維護模式自動遷移的 VM 虛擬主機，再次遷移回原本運作的 ESXi 叢集節點成員主機中（如圖 5 所示）。
圖 5、DRS-MM 機制-自動將 VM 虛擬主機遷移回離開維護模式的 ESXi 主機運作示意圖
實戰 vCenter Server 6.7 Update 2
由於，VMware 官方已經正式宣佈主流的 vSphere 6.7 版本，將會是最後一版 vCenter Server 管理平台中，支援「External」PSC（Platform Services Controller）部署模式的版本，所以日後發行的新版本 vCenter Server 管理平台，將僅支援採用「Embedded」PSC 部署模式。有關 vCenter Server 管理平台棄用 External PSC 部署模式，全面改採 Embedded PSC 部署模式的詳細資訊，請參考 VMware KB 60229知識庫文章內容。
因此，在 vCenter Server 6.7 U2 版本的部署流程中，除了在 External PSC 部署模式旁加上「即將棄用」（Deprecating soon）的提醒文字之外，倘若管理人員仍然選擇採用 External PSC 部署模式時，在部署流程視窗中便會顯示警告資訊（如圖 6 所示），同時顯示警告說明資訊和 VMware KB 文章連結，避免管理人員在新建置 vCenter Server 管理平台中，不小心採用即將被棄用的 External PSC 部署模式。
圖 6、選擇即將棄用的 External PSC 部署模式時，系統將顯示警告資訊和 VMware KB 文章連結
PSC 部署模式轉換工具
事實上，為了因應企業和組織棄用 External PSC 部署模式，VMware 在發佈 vSphere 6.7 U1 版本時，便同時推出「匯整轉換工具」（Converge Tool），然而管理人員僅能透過 vCenter Server CLI 指令，或是搭配 JSON 範本檔案，才能將原本建置的 External PSC 部署模式，由原本分散式的 PSC 運作架構，匯整後轉換為 Embedded PSC 部署模式。現在，最新發行的 vSphere 6.7 U2 版本中，管理人員可以輕鬆透過 vSphere HTML 5 Client 圖形管理介面，執行 External PSC 轉換為 Embedded PSC 部署模式的工作任務，並且在完成轉換部署模式作業後，執行棄用 External PSC 的動作。
請在 vSphere HTML 5 Client 管理介面中，依序點選「Menu > Administration > Deployment > System Configuration」項目，點選採用 External PSC 部署模式的 vCenter Server 主機，然後按下「Converge To Embedded」項目。
首先，系統將會彈出警告訊息，說明稍後進行轉換程序時 vCenter Server 服務將會重新啟動，造成 vCenter Server 產生停機時間，確認繼續執行轉換作業請按下「Proceed」鈕，接著在 Converge to embedded 視窗中，鍵入 SSO 管理者帳號和密碼後按下「Converge」鈕（ 如圖 7 所示），此時，該台 vCenter Server 主機將會開始安裝所需的 RPMs 套件，並且組態設定「複寫」（Replication）機制，當 SSO Domain 也完成作業程序後，便可以準備執行棄用 External PSC 部署模式的動作。
請注意，當 vCenter Server 可以存取 Internet 時，將會自動從 VMware Online Repository 下載所需套件，否則管理人員則必須採用離線安裝的方式進行。
圖 7、執行 External PSC 轉換為 Embedded PSC 部署模式的工作任務
完成轉換作業之後，同樣在 System Configuration 管理頁面中，點選準備退役的 External PSC 主機，然後按下「Decommission PSC」項目，此時系統再度彈出警告訊息，說明進行 PSC 主機退役程序時，將會造成 vCenter Server 服務重新啟動，導致 vCenter Server 產生停機時間，確認繼續執行轉換作業請按下「Proceed」鈕，接著在 Decommission PSC 視窗中，鍵入 SSO 管理者帳號和密碼後按下「Decommission」鈕（ 如圖 8 所示），系統便立即在 vCenter Server 管理平台中，執行「取消註冊」（Unregister）的動作，然後將 External PSC 部署模式執行退役的工作任務。
圖 8、執行 External PSC 部署模式退役的工作任務
備份和還原支援更多通訊協定
在過去的 vCenter Server 管理平台版本中，執行內建的 File-Based 備份和還原作業時，僅支援「FTP（s）、HTTP（s）、SCP」通訊協定，這對於採用 NAS 儲存架構的企業和組織來說，無論是執行備份和還原作業時都會造成不便。現在，最新版本的 vCenter Server 6.7 U2版本中，針對 vCenter Server 執行備份和還原作業通訊協定的部份，除了原有的通訊協定之外，額外新增支援「NFSv3、SMBv2」通訊協定（如圖 9 所示），讓管理人員可以更容易的將 vCenter Server 備份或還原檔案，直接存放於 NAS 儲存設備當中。
請注意，File-Based 備份和還原功能僅支援 vCSA（vCenter Server Appliance），不支援即將棄用的 Windows vCenter Server。
圖 9、採用新增支援的 SMB 通訊協定，進行 vCenter Server 組態設定備份作業
除了支援更多通訊協定之外，最新的 File-Based 備份和還原工作流程，新增支援「告警」（Alarms）和「備份任務狀態」（Backup Job Status）機制。在備份任務狀態的部份，只要在管理介面中依序點選「vCenter Server > Monitor > Tasks and Events > Enents」項目，即可查看到備份工作任務的執行狀態（如圖 10 所示），協助管理人員輕鬆掌握定期備份作業執行結果。
圖 10、透過新增的備份任務狀態機制，協助管理人員輕鬆掌握定期備份作業執行結果
同時，透過新增支援的備份工作任務狀態告警機制，只要在管理介面中依序點選「vCenter Server > Configure > More > Alarm Definitions > Backup job status > Edit」項目，便可以組態設定當備份作業失敗時，傳送告警信件通知管理人員，或至是送出 SNMP Traps 或執行某個 Script 腳本（如圖 11 所示）。
圖 11、組態設定當備份作業失敗時，傳送 Mail 或送出 SNMP Traps 或執行 Script
不斷強化的 vSphere HTML 5 Client
對於熟悉 vSphere Client 管理工具的朋友，一定不陌生這個管理工具的演進，早期採用 C#所開發雖然連線速度快，但是版本無法向下相容並且管理工具的儲存空間，演變到後期竟然比 ESXi 虛擬化平台映像檔還大。隨後出現採用 Flash 技術的 vSphere Web Client 管理工具，此管理工具的主要缺點在於管理介面回應速度過慢，並且 Flash 經常會衍生安全性問題的疑慮。最新採用 HTML 5技術的 vSphere HTML 5 Client 管理工具，原本是在 VMware Flings 網站中的一項計劃，不斷演變改進後直接內建至 ESXi 虛擬化平台中，並且 vCenter Server 也直接採用此管理工具，舉例來說，在 Fling 4.0 時除了能夠相容於舊版本之外，同時支援管理介面暗黑（Dark）主題模式（如圖 12 所示）。
此外，在 Fling 4.1 版本中新增「程式碼擷取」（Code Capture）和 API Explorer 功能，最新的 Fling 4.2 版本中，甚至讓程式碼擷取特色功能並僅能夠轉譯成 PowerCLI 程式碼，甚至搭配 vRealize Orchestrator 也能轉譯成 Python 和 Javascript 程式碼。
圖 12、Fling 4.0 版本相容舊版並支援暗黑主題模式
更全面的健康狀態檢查機制
在過去的 vSphere 叢集運作環境中，當 vSphere 叢集發生問題時，必須依靠管理人員過往故障排除經驗，才能夠快速找出問題點並迅速排除問題。因此，在 2018 年 4 月 VMware 推出 vSphere 6.7 版本時，便新增 vSphere Health健康狀態偵測機制，協助 vSphere 管理人員能夠快速發現問題發生的根本原因，並且透過 Ask VMware 機制直接開啟對應的 VMware KB 文章內容。最新的 vSphere 6.7 U2 針對 vSphere Health 健康狀態偵測機制，新增「告警」（Alarms）和「類別」（Categories）功能。首先，當 vSphere 叢集發生問題時，將會觸發 vSphere Health Alarms 機制，在管理介面中便會出現類似 vCenter Server Alarms 資訊條（如圖 13 所示），管理人員可以在排除問題後選擇「確認」（Acknowledge）或「重置為健康狀態」（Reset to Green），以便清除管理介面中出現的 vSphere Health Alarms 資訊條。
圖 13、vSphere Health 健康狀態偵測機制，發現系統健康狀況出現問題的警告資訊條
在類別的部份，現在 vSphere Health 將健康狀態劃分為多個類別，請在管理介面中依序點選「vCenter Server > Monitor > Health」項目（如圖 14 所示），即可看到 Online Health Availability、Compute、Network、Storage、General 等多項健康狀態偵測類別，幫助管理人員很容易便一眼看出，目前發生問題的根本原因是哪個資源發生問題。
圖 14、透過 vSphere Health 健康狀態類別機制，快速找出發生問題的資源
程式碼擷取和 API Explorer
最新的 vSphere 6.7 U2 版本中，新增「程式碼擷取」（Code Capture）和「API Explorer」適用於開發人員的特色功能。在過去的 vSphere 版本中，管理人員必須建立測試環境，然後手動從頭到尾撰寫 PowerCLI 程式碼，已達成大量管理或半自動化或全自動化管理的目標。首先，在程式碼擷取的部分，在管理介面中依序點選「Menu > Developer Center > Code Capture」項目，然後點選「Enable Code Capture」選項啟用啟動程式碼擷取特色功能，此時在管理介面右上角登入帳號的左邊，便會出現錄影的紅色圓圈圖示（如圖 15 所示）。
圖 15、啟用啟動程式碼擷取特色功能
然後，管理人員只要按下「Start Recording」鈕之後，在管理介面中執行希望轉換成 PowerCLI 程式碼的操作步驟，並在完成手動操作步驟後按下「Stop Recording」鈕，當系統停止程式碼擷取的動作之後，便會立即將剛才 GUI 圖形介面的手動操作步驟，透過 Code Capture 轉譯功能轉換為 PowerCLI 程式碼內容。
舉例來說，在我們按下 Start Recording 鈕之後，手動執行建立名稱為「Test Network」的連接埠群組，並且 VLAN ID 為「100」，當按下 Stop Recording 鈕之後，系統便立即將這些手動操作步驟轉譯為 PowerCLI 程式碼內容（如圖 16 所示），可以按下「Copy」鈕將內容複製到剪貼簿中，或是按下「Download」鈕直接下載內容為「power-cli-script.ps」的 PowerCLI 程式碼檔案。
圖 16、將手動建立連接埠群組的操作步驟轉譯為 PowerCLI 程式碼內容
在過去舊版的 vSphere 6.5 版本時，允許管理人員連結 https://<vCenterServer-FQDN>/apiexplorer 網址，並於通過身分驗證程序之後，即可呼叫 vSphere API 與 vCenter Server 管理平台進行互動。
現在，最新 vSphere 6.7 U2 版本中，可以直接在 vSphere HTML 5 Client 管理介面中，透過 API Explorer 功能並使用 REST API 進行互動，不僅省去需要額外進行身分驗證步驟的程序，還提供關鍵字過濾功能幫助開發人員快速搜尋 vSphere REST API 中可用的服務和方法，舉例來說，我們在過濾欄位鍵入「backup」的關鍵字，此時系統便僅會顯示與 backup 關鍵字有關的 REST API 項目（如圖 17 所示）。
圖 17、系統僅顯示與 backup 關鍵字有關的 REST API 項目
當過濾出開發人員尋找的 REST API 項目後，可以展開 REST API 項目查看簡要說明和回應的 Code 及原因，並且可以按下「Execute」鈕直接執行呼叫 REST API 的動作，並在下方 Response 區塊顯示呼叫 REST API 的結果（ 如圖 18 所示），管理人員可以按下「Copy JSON」鈕，將 JSON 內容複製到剪貼簿中，或是按下「Download」鈕直接下載名稱為「response-body.json」的 JSON 檔案。
圖 18、按下 Execute 鈕直接執行呼叫 REST API 的動作
vSphere Client Plug-ins
在過去的 vSphere 版本中，當管理人員安裝 Client Plug-in 出現問題時，必須自行翻找系統日誌檔案內容進行故障排除作業。現在，最新的 vSphere 6.7 U2 版本中，管理人員可以輕鬆透過 vSphere HTML 5 Client 管理介面，直接查看 Client Plug-in 的部署情況和相關資訊，無論是安裝失敗或不相容等部署情況，都將會詳細顯示並直接看到問題發生的原因。在管理介面中依序點選「Menu > Administration > Solutions > Client Plug-Ins」項目，舉例來說，可以看到「VMware vSAN Web Client Plugin」的部署狀態為「不相容」（Incompatible），只要點選該項目系統便會顯示不相容的原因（如圖 19 所示），此 Plugin 不相容的原因為僅支援 vSphere Web Client 管理介面。
圖 19、了解 Plugin 部署結果為不相容的原因說明
倘若，需要 Plug-in 更完整更詳細的錯誤或警告資訊時，請在管理介面中依序點選「Menu > Tasks」項目，即可查看 Plug-in 的詳細錯誤或警告資訊內容（如圖 20 所示）。
圖 20、查看 Plug-in 的詳細錯誤或警告資訊內容
VM 虛擬主機最多支援至 256 vCPU
在過去的 vSphere 虛擬化平台版本中，建立的 VM 虛擬主機在 vCPU 虛擬硬體的組態設定中，最多僅支援至 128 vCPU。現在，採用最新的 ESXi 6.7 U2版本，即可建立支援最多達 256 vCPU的 VM 虛擬主機。這種超大型硬體資源類型的 VM 虛擬主機，主要設計用於滿足大型商用軟體對運算資源的需求，例如，SAP HANA（High-Performance Analytic Appliance）便有這樣的需求。簡單來說，當 VM 虛擬主機運作 SAP HANA 環境時，採用的 vCPU 數量越多即可讓 HANA 的運算速度更快。
值得注意的是，在建立這類型 VM 虛擬主機的流程中，在步驟 5「Select compatibility」時，記得在相容性下拉式選單中選擇「ESXi 6.7 Update 2 and later」項目，才會使用僅 ESXi 6.7 U2 版本支援的最新「VM Compatibility 15」（如圖 21 所示），屆時 VM 虛擬主機才能配置最多 256 vCPU 虛擬處理器，以及最多 6 TB vRAM虛擬記憶體資源。
影響 VM 虛擬主機硬體資源最大值配置的版本，過去稱為「Virtual Hardware version」，從 vSphere 6.7 U2 版本開始改稱為「VM Compatibility」。
圖 21、僅 ESXi 6.7 U2 版本才支援的最新 Virtual Hardware version 15
結語
透過本文的深入剖析和實作演練之後，相信讀者已經了解最新發行的 vSphere 6.7 U2 版本中，各式新增的特色功能機制，將如何幫助企業和組織的 IT 管理人員，如何更省力更快速的管理 vSphere 虛擬化資料中心。↧
波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦
聖伊麗莎白教堂 (Kostol svätej Alžbety)
早安，布拉提斯拉瓦 (Bratislava)，享用完飽肥早餐之後，今天第一個景點是有「藍色教堂」之稱的「聖伊麗莎白教堂」 (Kostol svätej Alžbety)，它座落在斯洛伐克首都布拉提斯拉瓦東部的一座天主教教堂。至於，為何會稱為藍色教堂？ 因為整個教堂外觀和內裝都大量使用藍色調完成因而得名。
可惜的是，我們似乎來早了，藍色教堂還尚未開放參觀，所以只能隔著門外的玻璃窗領略藍色教堂內部的美。
今天很幸運的天公作美，藍天白雲下的藍色教堂更顯魅力，當然一定要環境記錄下這美麗的布拉提斯拉瓦 - 聖伊莉莎白教堂。
參觀完藍色教堂，走回飯店的途中，領隊帶我們順道參觀附近公園內知名的「鴨子噴泉」。
步行回飯店途中，又發現昨天飯店旁的商場門口有現代裝置藝術。
斯拉溫二戰紀念碑 (Slavín)
建於 1960 年的「斯拉溫二戰紀念碑」 (Slavín)，為了紀念在第二次世界大戰期間，從德國軍隊手中解放布拉提斯拉瓦時陣亡的蘇聯紅軍士兵。每每參觀這些歷史傷痛地點，都只能再次期望世界和平啊 🙏
環場紀錄布拉提斯拉瓦 - 斯拉溫二戰紀念碑。
由於斯拉溫二戰紀念碑建於山丘上，所以這裡也是欣賞布拉提斯拉瓦和小卡爾巴阡山風光的絕佳地點，而且從這裡就可以直接遠眺布拉提斯拉瓦城堡。
環場記錄從斯拉溫二戰紀念碑山上遠眺布拉提斯拉瓦城堡。
布拉提斯拉瓦城堡 (Bratislavský hrad)
下山後，我們來到了首都布拉提斯拉瓦的知名地標「布拉提斯拉瓦城堡」 (Bratislavský hrad)，它曾經是凱爾特人城鎮的衛城、羅馬帝國邊牆的一部分、斯拉夫人的防禦居民點，以及達摩拉維亞的政治、軍事和宗教中心。可惜，我們今天來的時間點剛好政府單位有重要會議舉行中，所以無法入內參觀只能從外部感受了。
環場記錄布拉提斯拉瓦城堡。
今天午餐享用的是傳統中式菜，用完午餐後出來偶然看到一棟建築的塗鴨非常有趣，索性就立即照下來了，可惜的是有路燈和電線擋路啊。😆
布拉提斯拉瓦舊城區
今天下午的重頭戲就是參觀布拉提斯拉瓦舊城區。首先，參觀舊城區的第一個景點就是「聖馬丁主教座堂」(Katedrála sv. Martina)，它是布拉提斯拉瓦最古老的教堂之一，並且曾經用於匈牙利王國的加冕教堂而聞名於世。聽著當地導遊拿著旅遊書向我們介紹聖馬丁教堂，以及當時匈牙利王國加冕儀式舉辦時的盛況，此外，在聖馬丁教堂旁邊則同樣有黑死病紀念柱。
環場記錄布拉提斯拉瓦舊城區聖馬丁教堂。
接著，我們步行深入布拉提斯拉瓦舊城區內，除了感受舊城區的氛圍之外，這裡也是許多知名音樂家造訪之地，例如，沃夫岡·阿瑪迪斯·莫札特 (Wolfgang Amadeus Mozart)、李斯特·費倫茨 (Liszt Ferenc)……等。
環場記錄布拉提斯拉瓦舊城區搜奇。
來到這棟舊城區建築物前，領隊請大家看看這棟建築物有什麼不同 (彩蛋在哪裡)，你看清楚了嗎？ 第二張特寫應該更清楚了吧! 😁
答案就是，在古時戰爭時，有顆「未爆的炮彈」在這棟建築物上 (在中央畫作的左上方)，同時這棟建築物還能逃過第二次世界大戰，讓今日參觀的我們能夠親眼看到這個奇觀。
接著，我們算是來到舊城區的中心，大家看出來了嗎？ 在當時，以這裡為中心的話，指向不同的方向並說明前往目的地的距離，例如，往 羅馬 (Roma) 需要 783 km。
接著，我們步行來到舊城區的「聖三位一體教堂」(Kostol trinitárov)，全名馬薩的聖約翰和韋羅斯的聖費利克斯教堂，是舊城區內的一座巴洛克式風格教堂。
環場記錄布拉提斯拉瓦舊城區的聖三位一體教堂。
步行來到曾經是主教府邸現在是市政廳的粉紅色巴洛克式建築，進入市政廳內部參觀時，剛好遇到世界兒童日活動非常熱鬧。
環場記錄布拉提斯拉瓦舊城區市政廳。
環場記錄布拉提斯拉瓦舊城區世界兒童日活動。
此外，在布拉提斯拉瓦舊城區內最有趣的部份是，除了途中古色古香的舊城區街道加上各種中世紀哥式德和巴洛克式建築群盡收眼底之外，還有許多現代裝置藝術和幽默銅像。
環場記錄布拉提斯拉瓦舊城區。
波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)
- 波波斯之旅 - 啟程
- 波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
- 波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
- 波波斯之旅 - Day03 - 拉脫維亞 / 里加
- 波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮
- 波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡
- 波波斯之旅 - Day06 - 立陶宛 / 維爾紐斯 / 波蘭 / 華沙
- 波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮
- 波波斯之旅 - Day08 - 波蘭 / 克拉科夫
- 波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營
- 波波斯之旅 - Day10 - 波蘭 / 塔特拉山
- 波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡
- 波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡
- 波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽
- (本文) 波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦
- 波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣 (撰寫中...)
↧
波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣
奧地利-維也納機場 (Vienna International Airport)
在前一天斯洛伐克首都布拉提斯拉瓦的最後深度巡禮之後，我們來到「奧地利-維也納機場」 (Vienna International Airport)，準備飛往伊斯坦堡轉機回台。
伊斯坦堡新機場 (İstanbul Havalimanı)
經過 2.5 小時的飛行後，我們來到「伊斯坦堡新機場」 (İstanbul Havalimanı)，準備轉機進行 11 小時的飛行時間回台，結束滿滿 15 天的波波斯之旅。
環場記錄伊斯坦堡新機場。
環場記錄伊斯坦堡新機場準備起飛。
環場記錄，在返回台灣的飛行途中，由於太陽光折射的關係，在雲上剛好可以看到飛機的樣子，非常有趣。
旅行的意義之我見
好快! 這 15 天的波波斯之旅，時間說長不長說短不短，然而可以肯定的是，在我的人生旅遊地圖上又新增一筆記錄了。其實，我們每個人生長在這個地球村當中，相信許多人可能跟我之前的觀念一樣要過別人眼中的「直線人生」，也就是每天工作的目標只為了「提升生活品質 > 趕快繳清房貸 > 退休 > 環遊世界……等」。但是，事實上真的是如此嗎？ 難保過程中不會有任何意外發生嗎？ 或者等到年老時有錢有閒 (其實也不一定有錢？) 還有足夠的體力能夠環遊世界嗎？ (現在的我對於每每要經歷長途飛行，其實已經感到相當疲憊和痛苦了)那麼，為何我會在這幾年之間突然看開且脫離直線人生呢？ 其實，只要能夠體會到人生無常這件事，相信你也很容易能夠看開某些原本在意的事情 (舉例來說，突然有好朋友或前輩離開這人世間，或者是努力打拼一輩子卻每天悶悶不樂的長輩，或者是到醫院急診室了解人生無常的無奈……)。
我想要表達的是，你應該盡情過好你所選擇的每一天!! 思考後發現，我在有生之年最想要做的事情就是踏遍世界，所以我努力工作和生活的最終目標都是為了往「地球村走一回」努力。因此，對於我來說「旅行」就是我盡情放鬆重新再出發的最好動力，你呢？ 你最佳放鬆再出發的方式是什麼？
波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)
- 波波斯之旅 - 啟程
- 波波斯之旅 - Day01 - 台灣 / 伊斯坦堡 / 塔林
- 波波斯之旅 - Day02 - 愛沙尼亞 / 塔林
- 波波斯之旅 - Day03 - 拉脫維亞 / 里加
- 波波斯之旅 - Day04 - 拉脫維亞 / 倫達爾宮
- 波波斯之旅 - Day05 - 立陶宛 / 十字架山 / 特拉凱水中古堡
- 波波斯之旅 - Day06 - 立陶宛 / 維爾紐斯 / 波蘭 / 華沙
- 波波斯之旅 - Day07 - 波蘭 / 維拉努夫宮
- 波波斯之旅 - Day08 - 波蘭 / 克拉科夫
- 波波斯之旅 - Day09 - 波蘭 / 維利奇卡地下鹽礦城 / 奧斯維辛集中營
- 波波斯之旅 - Day10 - 波蘭 / 塔特拉山
- 波波斯之旅 - Day11 - 斯洛伐克 / 斯皮什基古堡
- 波波斯之旅 - Day12 - 斯洛伐克 / 奧拉瓦城堡
- 波波斯之旅 - Day13 - 斯洛伐克 / 特倫欽
- 波波斯之旅 - Day14 - 斯洛伐克 / 布拉提斯拉瓦
- (本文) 波波斯之旅 - Day15 - 維也納 / 伊斯坦堡 / 台灣
↧
↧
[站長開講] Cloud Native Forum 2019
活動簡介
Cloud Native 可以説是一系列 Cloud 技術、企業管理方法的集合，包含微服務 (Microservices)、容器化應用 (Containerization)、容器協作 (Container Orchestration)、DevOps、CI/CD、多種程式語言 (polyglot programming) 與框架 (framework)共存、Declarative API互動、Stateless and Stateful Services、不可變的及敏捷的基礎設施 《immutable and agile infrastructure》、及自動化 (automation) 等時下最為熱門的趨勢和議題。CNCF 官方首次授權台灣正式活動! 透過活動，期許我們可以認識來自世界各地不同的高手，互相交流，得到靈感，提升自己與企業的競爭力。Cloud Native 的目的是為了提高速度，增加擴展性，降低花費採購主機的成本，進而增加利潤。透過 Cloud Native 的應用， 可以幫助企業達到 IT 轉型，進而加快產業轉型的速率，帶動整個國家經濟提升。
企業 IT 產業新趨勢，世界各地企業將 Kubernetes 叢集作為正式環境的企業比例，在過去的幾年中，越來越多的企業及組織採用 Cloud Native 相關技術，單單去年3月為止，使用雲端應用的企業比例已經成長了 135%，而根據 CNCF 的調查，在亞洲地區使用 11-50 個 Kubernetes 叢集的企業，於 2018 年成長了 154% 。在這次還有 CNCF 官方一同來共襄盛舉，列為官方亞洲區正式活動，還在等甚麼? 快來一起跟上世界潮流吧!
- CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200% - Cloud Native Computing Foundation
- CNCF Survey: Cloud Usage in Asia Has Grown 135% Since March 2018 - Cloud Native Computing Foundation
活動資訊
- 日期： 2019 年 10 月 9 日 (星期三)
- 時間： 8:30 ~ 17:00
- 地點： 台灣台北信義區信義路五段1號 (TICC 101會議室)
- 報名： 活動報名
活動內容
- 議程列表
- 站長議程： 想要輕鬆入手 Kubernets 叢集？ 試試史上最輕量級的 K3S 吧！
↧
網管人 165 期 - 了解儲存體複本機制，遠端複寫免建構一致環境
網管人雜誌
本文刊載於 網管人雜誌第 165 期 - 2019 年 10 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。文章目錄
前言儲存體複本部署模式
伺服器對伺服器
延展式叢集
叢集對叢集
Azure 相同區域叢集對叢集
Azure 跨地區叢集對叢集
儲存體複本資料複寫機制
同步複寫
非同步複寫
儲存體複本軟體授權
實戰演練 - 儲存體複本機制
安裝儲存體複本伺服器功能
複寫磁碟區規劃
執行儲存體複本環境測試工作任務
建立伺服器對伺服器複寫機制
透過 WAC 管理儲存體複本機制
結語
前言
過去，當企業和組織需要針對儲存資源中存放的資料進行遠端複寫時，除了採用的儲存裝置必須支援之外，還必須要注意許多事項，舉例來說，本地端和目的端兩者的儲存裝置必須同一廠牌，並且儲存裝置型號通常也必須相同或更高等級……等，所以採用傳統儲存裝置在建構遠端資料複寫機制時，除了部署架構較為複雜之外，所花費的 IT 預算通常也所費不貲。從 Windows Server 2016 版本開始，新增「儲存體複本」（Storage Replica，SR）特色功能，這項儲存體複本機制與傳統儲存設備（DAS / NAS / SAN）無關，屬於「區塊層級」（Block Level）的遠端資料複寫儲存特色功能，並且支援「同步」（Synchronous）和「非同步」（Asynchronous）兩種不同的遠端資料複寫方式，並採用 SMB 3 通訊協定進行遠端資料複寫機制。
儲存體複本部署模式
Windows Server 儲存體複本機制支援多種不同的部署模式，例如，伺服器對伺服器（Server-to-Server）、叢集對叢集（Cluster-to-Cluster）……等，以便因應企業和組織多樣化的遠端資料複寫需求。伺服器對伺服器
採用「伺服器對伺服器」（Server-to-Server）儲存體複本部署模式時，在 Active Directory 網域環境中的二台伺服器，無論單台伺服器採用 JBOD、SAN、iSCSI 或是本機 SAS/SATA 儲存資源，都可以透過儲存體複本機制，將二台伺服器的儲存資源進行資料複寫處理（如圖 1 所示）。請注意，倘若其中一台伺服器為公有雲 Azure VM 虛擬主機時，企業內部執行儲存體複本的伺服器，必須透過 Express Route 或 Site-to-Site VPN，與公有雲 Azure VM 虛擬主機進行連線。
圖 1、儲存體複本伺服器對伺服器部署模式示意圖
值得注意的是，二台伺服器應該建立至少「二個磁碟」，其中一個磁碟區負責儲存體複本機制「日誌檔」（Logs）用途，另一個磁碟區則是主要進行「資料複寫」（Replicated Data）用途。同時，這二個磁碟區不可以使用包含 Windows 作業系統的磁碟區（通常為 C 槽）。
延展式叢集
採用「延展式叢集」（Stretch Cluster）儲存體複本部署模式時，與前一個伺服器對伺服器部署模式最大的不同，在於管理人員可以在延展式叢集架構中，在不同的二個站台內形成一個邏輯的容錯移轉叢集（如圖 2 所示），同時在個別站台內，依然維持傳統容錯移轉叢集使用共用儲存資源的運作架構，然後再透過儲存體複本機制同步二個站台中儲存資源的內容。
圖 2、儲存體複本延展示叢集部署模式示意圖
在運作環境需求方面，與前一個使用案例伺服器對伺服器大致相同，值得注意的部份是，二個站台必須為「同一個」Active Directory 網域樹系內，並且單一站台中的容錯移轉叢集內，至少需要「二台」成員節點主機（最多可支援至 64 台成員節點主機）。
叢集對叢集
採用「叢集對叢集」（Cluster-to-Cluster）儲存體複本部署模式時，與延展式叢集部署模式最大的不同點，在於二個不同的資料中心站台內擁有個別的容錯移轉叢集。同時，在儲存資源方面除了支援傳統共用儲存設備之外，也支援新一代的 S2D 超融合基礎架構儲存資源（如圖 3 所示）。
圖 3、儲存體複本叢集對叢集部署模式示意圖
在運作環境需求方面，與前一個使用案例延展式叢集大致相同，除了二個站台必須為同一個 Active Directory 網域樹系內，並且單一站台中的容錯移轉叢集內至少需要「二台」成員節點主機之外，當採用傳統共享儲存設備時，仍可支援最多 64 台成員節點主機，倘若採用新興的 S2D 超融合基礎架構，則最多支援至 16 台成員節點主機。
Azure 相同區域叢集對叢集
企業和組織也可以將儲存體複本機制，套用於 Microsoft Azure 公有雲環境中，由於採用 Azure 公有雲環境會有「區域」（Region）的差異。首先，我們可以在「同一個區域」（The same region）的 Azure 公有雲環境中（如圖 4 所示），透過儲存體複本機制輕鬆達成叢集對叢集的資料複寫目的。
圖 4、Azure 公有雲「相同」區域叢集對叢集儲存體複本部署模式示意圖
在運作環境需求方面，由於採用 Azure 公有雲相同區域，所以應部署至相同的資源群組和虛擬網路環境，確保相同區域的二個容錯移轉叢集，能夠透過虛擬網路互相存取，進而達成儲存資源執行儲存體複本的目標。
Azure 跨地區叢集對叢集
在 Microsoft Azure 公有雲環境中，當企業和組織希望將容錯移轉叢集部署在「跨區域」（Cross Region）的 Azure 資料中心，並且達成跨區域之間叢集對叢集的資料複寫目標時，儲存體複本仍然可以無縫支援（如圖 5 所示）。
圖 5、Azure 公有雲「跨」區域叢集對叢集儲存體複本部署模式示意圖
在運作環境需求方面，由於採用 Azure 公有雲跨區域的關係，所以二個區域的虛擬網路必須特別注意，例如，「虛擬網路閘道」（Virtual Network Gateway）的部份，必須確保二個區域之間可以互相到達和連通，同時二個區域之間的網路安全性群組也必須放行相關網路流量允許通過……等，屆時才能達到儲存資源執行儲存體複本的目標。
儲存體複本資料複寫機制
在儲存體複本資料複寫機制方面，支援「同步」（Synchronous）和「非同步」（Asynchronous）兩種不同的遠端資料複寫方式，以便因應企業和組織不同的網路頻寬需求和資料可用性等級。在資料複寫傳輸方面採用「伺服器訊息區塊」（Server Message Block，SMB）和「SMB Direct（SMB over RDMA）」通訊協定，所以管理人員在建置儲存體複本資料複寫機制時，必須允許「SMB Port 445」和「WS-MAN Port 5985」網路流量通行，倘若啟用 RDMA 機制還必須允許「SMB Direct Port 5445」網路流量通行。
同步複寫
簡單來說，管理人員採用「同步複寫」的儲存體複本機制時，當應用程式寫入資料在儲存體複本「來源端」時，系統並不會立即確認資料 IO 動作已完成，必須等到資料複寫至「遠端目的地」並傳回 IO 確認動作後，才會回覆給上層應用程式完成資料 IO 的動作（如圖 6 所示）。下列，為同步複寫模式的資料 IO 詳細運作步驟：1. 上層應用程式發出資料寫入 IO 需求。
2. 來源端伺服器將資料寫入至本地端儲存資源「日誌」磁碟區內，同時透過 SMB 通訊協定將資料複寫至遠端目的地伺服器。
3. 遠端目的地伺服器，完成複寫資料寫入至本地端儲存資源日誌磁碟區的動作。
4. 目的端伺服器完成資料寫入動作後，回覆來源端伺服器已完成資料 IO 動作。
5. 來源端伺服器回覆上層應用程式已完成資料 IO 動作。
請注意! 採用同步複寫模式，伺服器之間的網路頻寬必須滿足資料 IO 寫入工作負載之外，網路環境的延遲時間至少必須為「5 ms」的平均數值。否則，可能會發生應用程式效能降低的風險。
圖 6、儲存體複本機制同步複寫模式運作架構示意圖
因此，採用儲存體複本的同步複寫模式時，倘若來源端儲存資源故障損壞，此時管理人員可以將應用程式容錯移轉至遠端站台，繼續存取複寫至遠端目的地的儲存資源，並且不會有任何資料遺失的情況發生。
非同步複寫
至於採用「非同步複寫」的儲存體複本機制時，當應用程式寫入資料在儲存體複本「來源端」時，系統不會等待「遠端目的地」傳回 IO 確認動作，便立即回覆給上層應用程式已經完成資料 IO 的動作，然後才執行將資料複寫至遠端目的地伺服器的動作（如圖 7 所示）。下列，為非同步複寫模式的資料 IO 詳細運作步驟：1. 上層應用程式發出資料寫入 IO 需求。
2. 來源端伺服器將資料寫入至本地端儲存資源「日誌」磁碟區內。
3. 來源端伺服器回覆上層應用程式已完成資料 IO 動作。
4. 來源端伺服器透過 SMB 通訊協定將資料複寫至遠端目的地伺服器。
5. 遠端目的地伺服器，完成複寫資料寫入至本地端儲存資源日誌磁碟區的動作。
6. 目的端伺服器完成資料寫入動作後，回覆來源端伺服器已完成資料 IO 動作。
採用非同步複寫模式時，微軟官方並沒有建議的網路延遲時間。
圖 7、儲存體複本機制非同步複寫模式運作架構示意圖
由於，非同步複寫模式在災難事件發生時，可能會有資料來不及複寫至遠端目的地伺服器造成資料遺失的風險。因此，一般都將非同步複寫模式用於「跨地理位置」資料中心的 DR 解決方案中。
儲存體複本軟體授權
在軟體授權方面，原則上無論採用 Windows Server 2019 標準版或資料中心版，都可以使用儲存體複本機制，值得注意的是，採用 Windows Server 2019 標準版時，執行複本抄寫的單一磁碟區空間大小的最大上限為「2 TB」（如圖 8 所示），若是採用 Windows Server 2019 資料中心版則無限制磁碟區空間大小。
圖 8、採用 Windows Server 2019 標準版儲存體複本單一磁碟區空間最上大限 2 TB
實戰演練 - 儲存體複本機制
在本文實作環境中，實作儲存體複本機制的兩台伺服器，將採用 Windows Server 2019 資料中心版本，至於伺服器的實體擺放位置，則是分別擺放在企業總部內不同樓層的資料中心機房內，以便因應其中一個樓層的資料中心發生災難事件，並且這兩台伺服器處於同一個網域當中。安裝儲存體複本伺服器功能
請為實作儲存體複本機制的兩台伺服器，安裝「檔案伺服器」（File Server）角色及「儲存體複本」（Storage Replica）功能（如圖 9 所示）。事實上，檔案伺服器角色只有在稍後執行儲存體複本環境測試時才需要使用，並且會開啟必要的防火牆連接埠進行測試工作任務。
圖 9、為實作儲存體複本機制伺服器，安裝檔案伺服器角色和儲存體複本功能
複寫磁碟區規劃
在本文的實作環境中，為實作儲存體複本機制的兩台伺服器分別配置二顆硬碟，分別是 10 GB用途為擔任日誌磁碟，並且給予 L磁碟機代號和 SR-Log磁碟標籤以利識別，以及 500 GB 用途為擔任資料磁碟區，並且給予 D磁碟機代號和 SR-Data磁碟標籤以利識別（如圖 10 所示）。
圖 10、為實作儲存體複本機制的兩台伺服器分別配置二顆硬碟
此外，在規劃設計儲存體複本機制磁碟時，必須注意下列項目：
- 日誌磁碟和資料磁碟，必須採用「GPT」（GUID Partition Table）而非 MBR 進行初始化。
- 實作儲存體複本機制的兩台伺服器，「日誌」磁碟儲存空間大小必須相同，並且至少要有 9 GB的儲存空間，同時建議採用 SSD 固態硬碟等儲存效能較佳的儲存裝置。
- 實作儲存體複本機制的兩台伺服器，「資料」磁碟儲存空間大小必須相同，支援 HDD、SSD 或 RAID 等儲存裝置。
執行儲存體複本環境測試工作任務
完成儲存體複本運作環境前置作業後，便可以執行 Test-SRTopology指令進行儲存複本環境測試作業，以便系統能夠根據目前的運作環境，判斷是否符合儲存體複本運作需求。管理人員可以看到測試指令的參數非常直覺，即指定來源端及目的端節點主機相關資訊，例如，電腦名稱、資料磁碟區代號、日誌磁碟區代號、測試時間、測試間隔...…等（如圖 11 所示）。下列為本文實作環境，以及執行儲存複本環境測試相關參數和參數值：- -SourceComputerName ：SR-Node01，來源端主機電腦名稱。
- -SourceVolumeName ：D 槽，來源端主機資料磁碟區代號。
- -SourceLogVolumeName：L 槽，來源端主機日誌磁碟區代號。
- -DestinationComputerName：SR-Node02，目的地主機電腦名稱。
- -DestinationVolumeName ：D 槽，目的地主機資料磁碟區代號。
- -DestinationLogVolumeName：L 槽，目的地主機日誌磁碟區代號。
- -DurationInMinutes ：5 分鐘，儲存體複本運作環境測試作業持續時間。
- -ResultPath：C:\tmp，儲存體複本環境測試報告產生路徑。
在正式營運環境時，測試時間建議至少需要 30 分鐘以上為佳。
圖 11、執行 Test-SRTopology 指令進行儲存複本環境測試作業
完成測試作業後，將會在指定的路徑產生名稱為「TestSrTopologyReport」加上日期和時間的 HTML 報表檔案，內容包括儲存體複本運作環境的 20 項測試作業結果、初始化同步效能測試、複本抄寫效能測試 …… 等內容（如圖 12 所示）。
圖 12、儲存體複本運作環境初始化同步效能測試結果
建立伺服器對伺服器複寫機制
現在，我們可以在儲存體複本運作環境中來源端伺服器，執行建立儲存複本機制的 New-SRPartnership 指令。同樣的，管理人員可以看到建立伺服器對伺服器複寫機制指令非常直覺，即指定來源端及目的端節點主機相關資訊（如圖 13 所示）。下列為本文實作環境，建立伺服器對伺服器複寫機制的相關參數和參數值：- -SourceComputerName： SR-Node01，來源端主機電腦名稱。
- -SourceRGName： SR-RG01，來源端主機的複寫群組名稱。
- -SourceVolumeName： D 槽，來源端主機資料磁碟區代號。
- -SourceLogVolumeName： L 槽，來源端主機日誌磁碟區代號。
- -DestinationComputerName： SR-Node02，目的地主機電腦名稱。
- -DestinationRGName： SR-RG02，目的地主機的複寫群組名稱。
- -DestinationVolumeName： D 槽，目的地主機資料磁碟區代號。
- -DestinationLogVolumeName： L 槽，目的地主機日誌磁碟區代號。
預設情況下，將會在日誌磁碟區內建立 8 GB 的日誌檔，管理人員也可以參考儲存體複本測試結果，搭配 -LogSizeInBytes 參數來指定日誌檔大小。
圖 13、建立伺服器對伺服器複寫機制
順利建立伺服器對伺服器複寫機制後，接著執行 Get-SRGroup 指令查詢複寫狀態，可以看到 ReplicationStatus 欄位狀態，由一開始的「WaitingForDestination」轉變為「InitialBlockCopy」，表示兩台伺服器之間正在進行資料區塊互相同步作業，並且透過工作管理員可以看到，正在進行資料磁碟區同步作業（如圖 14 所示）。
管理人員可以在目的地伺服器，執行「（Get-SRGroup）.Replicas | Select-Object numofbytesremaining」指令，查詢剩餘多少 Bytes 需要進行初始複製。
圖 14、兩台伺服器之間正在進行資料區塊互相同步作業
當兩台伺服器之間完成資料區塊互相同步作業後，管理人員可以使用「（Get-SRGroup）.Replicas」指令，搭配指定來源端或目的端伺服器的電腦名稱，即可查詢磁碟複寫資訊，例如，資料磁碟區、複寫模式...…等，並且看到 ReplicationStatus欄位狀態，由先前的「InitialBlockCopy」轉變為「ContinuouslyReplicating」表示資料區塊同步作業完成（如圖 15 所示）。
此時，管理人員將會發現目的地伺服器的資料磁碟區，將會呈現卸載狀態。
圖 15、二台伺服器之間已經完成資料區塊同步作業
透過 WAC 管理儲存體複本機制
事實上，管理人員也可以透過新一代的管理平台 WAC（Windows Admin Center），來建立和管理儲存體複本機制。現在，我們已經建立完成伺服器對伺服器運作環境，透過 WAC 管理平台登入其中一台伺服器，在 Storage Replica 項目中，即可看到建立的儲存體複本和詳細資訊（如圖 16 所示）。
圖 16、透過 WAC 管理平台建立和管理儲存體複本機制
結語
透過本文的深入剖析和實戰演練，相信讀者已經了解儲存體複本機制的優點和適用情境。事實上，儲存體複本機制還能與 Hyper-V、S2D 超融合基礎架構、容錯移轉叢集、重複資料刪除……等特色功能協同運作，並且支援 NTFS/ReFS/CSVFS 等檔案系統，在後續的文章中我們也將會各位一一深入剖析。↧
[站長開講] OpenInfra Days Taiwan 2019
活動簡介
在去年 OpenInfra Days 2018的活動中，以「開放架構的智慧、技術融合的創新」為核心，針對AI、機器學習、邊緣運算、5G 物聯網等領域進行討論。今年 OpenInfra Days 2019年，雖然全球科技產業動盪，但是 OpenStack 技術發展仍然持續向前，除了核心的 Container、多雲環境、軟體定義一切…等議題之外，近期熱門的 5G、AI、資安、Cloud Native等最新趨勢，都將成為 OpenInfra Days 2019活動的關注焦點，期待您的加入，與業界菁英一起共創發展。
活動資訊
- 日期： 2019 年 11 月 12 日 (星期二)
- 時間： 8:30 ~ 16:55
- 地點： 台北市信義區信義路五段1號 (TICC 台北國際會議中心)
- 報名： 活動報名
活動內容
- 議程列表
- 站長議程： Ironic - API-driven with bare metal infrastructure for Kubernetes
↧
網管人 166 期 - 實作 vSphere 6.7 最佳化高效與高安全性兼備
網管人雜誌
本文刊載於 網管人雜誌第 166 期 - 2019 年 11 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。前言
BIOS 組態設定最佳化
ESXi 主機網路組態設定最佳化
新增 SCAv2 調度選項有效改善執行效能
阻擋 L1TG 漏洞的安全性邊界防護機制
如何採用新式 SCAv2 調度程序
增強 DRS 調度工作負載
增強初始化放置機制
增強主機維護模式
支援採用 vPMem 和 vPMemDisk 的虛擬主機
增強資源集區預留機制
結語
前言
雖然，企業和組織已經將內部資料中心上雲，並且採取搭配多個雲端供應商的策略，為企業和組織的營運服務提供最佳的可用性。然而，在企業內部的資料中心內，或多或少仍有工作負載運作在虛擬環境上，或是尚未上雲的企業在內部的工作負載大多運作在虛擬化環境中。根據 Flexera 最新的 2019 State of the Cloud Report 市調結果顯示，企業和組織已經有高達 94 %的比例使用相關雲端技術，其中高達 91 % 的比例為採用公有雲，而採用私有雲的企業和組織也仍然有 72 %比例之多（如圖 1 所示）。
圖 1、企業和組織使用公有雲 / 私有雲 / 混合雲的比例統計
從調查結果可知，仍然有許多企業和組織在內部資料中心內，透過虛擬化技術運作各種營運服務的工作負載。然而，虛擬化環境是否最佳化，將會大大影響運作於其上的 VM 虛擬主機，以及 VM 虛擬主機內執行的應用程式效能和回應速度。
因此，本文將針對目前企業和組織中，主流使用的 VMware 虛擬化環境提供多種最佳化使用技巧，除了確保營運服務能夠提供高效能之外，更能因此運作更多的工作負載在虛擬化環境中。
BIOS 組態設定最佳化
首先，在硬體伺服器的 BIOS 組態設定方面，建議依照下列組態設定值，以確保安裝 ESXi 虛擬化平台的硬體伺服器，在運作效能方面能夠保持最佳化，舉例來說，在硬體伺服器的 BIOS 層級上，便將 C States 和 C1E 等節省電源的組態設定停用，避免無謂的省電措施影響屆時 VM 虛擬主機的運作效能和回應速度。- Power Management：建議調整為 OS Controlled或 High Performance。
- Hyperthreading：建議調整為 Enabled。
- Turbo Boost：建議調整為 Enabled。
- C States：建議調整為 Disabled。
- C1E：建議調整為 Disabled。
- Intel VT technology：建議調整為 Enabled。
- QPI Power Management：建議調整為 Disabled。
- Execute Disable Bit：建議調整為 Enabled。
- Node Interleaving：建議調整為 Disabled。
ESXi 主機網路組態設定最佳化
針對 ESXi 主機網路組態設定的部份，我們將會採用 esxcli（vSphere command-line interface）管理指令，進行 ESXi 主機網路組態設定最佳化的工作任務。首先，請透過「esxcli network nic list」指令，確認目前 ESXi 主機中實體網路卡數量以及相關資訊，例如，MTU 為標準的 1500或是已開啟 Jumbo Frame的 9000。接著，透過「esxcli network nic get -n vmnic0」指令，查看指定實體網路卡的名稱的詳細組態設定內容（如圖 2 所示）。
圖 2、查詢 ESXi 主機中實體網路卡數量和詳細組態設定內容
啟用 TSO 卸載功能
啟用實體網路卡卸載功能，除了最大化網路傳輸效能之外，也能避免 ESXi 主機的 CPU 運算資源無謂的開銷，確保屆時營運服務能夠獲得最充足的 CPU 運算資源。
首先，為 ESXi 主機的 VMkernel 啟用TSO（TCP Segmentation Offload）網路卸載功能，確保網路卡能夠以較大的網路封包（最大至 64 KB）進行傳送，以減少 ESXi 主機處理 TCP/IP 網路封包的 CPU 工作負載。
請透過「esxcli network nic tso get」指令，確認 ESXi 主機的實體網路卡支援 TSO 卸載功能，接著執行「esxcli system settings advanced set -o /Net/UseHwTSO -i 1」指令，在 ESXi kernel 進階組態設定中，將 TSO 卸載功能組態設定為啟用，然後執行「esxcli system settings advanced list -o /Net/UseHwTSO」指令，確保 Int Value 欄位值為「1」即表示啟用 TSO 卸載成功（如圖 3 所示）。
有關啟用和停用 TSO 網路卸載機制的詳細資訊，請參考 VMware KB 2055140文章內容。
圖 3、為 ESXi 主機的 VMkernel 啟用 TSO 網路卸載功能
啟用 CSO 總和檢查碼卸載功能
在網路封包 TCP Header 中包含 16-bit 的總和檢查碼機制，以便驗證網路封包的完整性，透過啟用CSO（Checksum Segment Offload）網路卸載機制，可以讓計算和驗證網路封包完整性的工作任務，由實體網路卡處理以減少 ESXi 主機的 CPU 工作負載。
請透過「esxcli network nic cso set -n vmnic0 -e 1」指令，為 ESXi 主機的實體網路卡啟用 CSO 網路卸載機制後，執行「esxcli network nic cso get」指令，確保指定的實體網路卡是否已經啟用 CSO 網路卸載機制（如圖 4 所示）。
圖 4、為 ESXi 主機的實體網路卡啟用 CSO 網路卸載機制
停用 LRO 大型接收卸載功能
雖然，透過 LRO（Large Receive Offload）網路卸載機制，可以將接收的網路封包重新組合為更大的緩衝區後，將大型且數量較少的網路封包進行傳送，以達到減少 ESXi 主機 CPU 工作負載的好處。然而，對於「網路延遲敏感」（Network Latency-Sensitive）的營運服務來說，會有回應速度變慢的情況，針對這類型的營運服務我們建議停用 LRO 網路卸載機制。
請透過「esxcli system settings advanced set -o /Net/TcpipDefLROEnabled -i 0」指令，為 ESXi 主機的實體網路卡停用 LRO 網路卸載機制後，執行「esxcli system settings advanced list -o /Net/TcpipDefLROEnabled」指令，確保指定的實體網路卡是否已經停用 LRO 網路卸載機制（如圖 5 所示）。
有關啟用和停用 LRO 網路卸載機制的詳細資訊，請參考 VMware KB 2055140文章內容。
圖 5、為 ESXi 主機的實體網路卡停用 LRO 網路卸載機制
新增 SCAv2 調度選項有效改善執行效能
在最新 VMware vSphere 6.7 U2版本中，新增不同的「調度選項」（Scheduler Options），除了能夠保護 VM 虛擬主機免於遭受採用 Intel 處理器的 L1TF 漏洞攻擊之外，新的工作負載調度選項能夠針對不同的工作負載，在避免安全性攻擊的同時維持過往高運作效能的表現。有關 VMware 虛擬化環境修補 L1TF 漏洞的詳細資訊，請參考 VMSA-2018-0020安全建議和 KB 55806文章內容。
主要原因在於，在新的調度選項尚未發佈之前，依照 VMware 安全建議內的修補程序進行調整後，將會採用「SCAv1」（Side-Channel Aware Scheduler）調度機制，避免 VM 虛擬主機受到 L1TF 漏洞的影響產生安全性疑慮。
然而，啟用 SCAv1 運作機制後，每個 CPU 處理器的實體核心將僅能處理「一個執行緒」而已，雖然能夠解決 L1TF 漏洞產生的安全性疑慮，卻導致 vSphere ESXi 虛擬化平台的運作效能「下降 30 %」。因此，在最新 VMware vSphere 6.7 U2版本中，推出新的「SCAv2」調度選項允許同時處理多個執行緒，讓 VM 虛擬主機的工作負載效能提升。
如圖 6 所示，在上半部圖中可以看到當單台 VM 虛擬主機運作時，無論採用舊有 SCAv1 或新式 SCAv2 調度選項，都會在分配單一 vCPU 至底層 CPU 處理器的實體核心上。
然而，在下半部圖中可以看到，當多台 VM 虛擬主機同時運作的情況下，採用預設未修補的調度選項，可能會讓同一個底層 CPU 處理器的實體核心，運作來自不同台 VM 虛擬主機的 vCPU 而遭受 L1TF 漏洞攻擊，而採用「舊式的 SCAv1」調度選項時，雖然可以確保同一個底層 CPU 處理器的實體核心，僅會運作來自同一個 VM 虛擬主機的 vCPU，但是只能處理「一個執行緒」而已，然而採用「新式的 SCAv2」調度選項時，除了兼顧 VM 虛擬主機安全性之外，更可以處理多個執行緒有效提升 VM 虛擬主機運作效能。
圖 6、預設調度程序和 SCAv1 及新式 SCAv2 調度程序運作示意圖
那麼舊式的 SCAv1 和新式的 SCAv2 工作負載調度選項，在各種不同的工作負載中效能表現的差異究竟有多少？ 從 VMware 的測試結果中可以看到，以 SQL Server on Windows with HammerDB 項目來看，相較於舊式的 SCAv1 工作負載調度選項，新式的SCAv2 提升「32 % ~ 54 %」的運作效能（如圖 7 所示）。
圖 7、SCAv1 和 SCAv2 工作負載調度選項效能測試表格
阻擋 L1TG 漏洞的安全性邊界防護機制
事實上，由於 L1TF 漏洞是落在底層的 CPU 處理器層級，因此在 vSphere 虛擬化平台以及其上運作的 VM 虛擬主機，必須針對不同的層級進行防護，才能有效確保 VM 虛擬主機的機敏資料不會外洩。整體來說，針對 L1TF 漏洞的防護層級有三個安全性邊界的部份，分別是「ESXi 主機、VM 虛擬主機、vCPU 處理器」。首先，針對 vSphere ESXi 虛擬化平台提供「主機安全性邊界」（Host Security Boundary）防護機制（如圖 8 所示），可以針對 ESXi 虛擬化平台和其上運作的 VM 虛擬主機，視為整個安全性邊界進行防護，然而僅採用主機安全性邊界防護機制時，倘若 ESXi 主機被感染而遭受 L1TF 漏洞時，那麼攻擊者將可以透過被感染的 ESXi 主機，獲得其上運作所有 VM 虛擬主機的機敏資訊，包括，網域憑證、加密金鑰 …… 等。
預設情況下，ESXi 主機的工作負載調度選項為「hyperthreadingMitigation = FALSE」時，便是啟用主機安全性邊界防護機制。
圖 8、主機安全性邊界運作架構示意圖
接著，針對 VM 虛擬主機提供「VM 虛擬主機安全性邊界」（VM Security Boundary）防護機制（如圖 9 所示），可以針對同一台 ESXi 虛擬化平台上，不同的二台 VM 虛擬主機之間提供攻擊防護。當 ESXi 主機的工作負載調度選項，組態設定為「hyperthreadingMitigation = TRUE」和「hyperthreadingMitigationIntraVM = FALSE」時，便是啟用 VM 虛擬主機安全性邊界防護機制。簡單來說，採用 VM 虛擬主機安全性邊界防護機制後，除了獲得主要的安全性防護功能外更兼顧運作效能。
圖 9、VM 虛擬主機安全性邊界運作架構示意圖
最後，管理人員可以針對 VM 虛擬主機中，運作的執行程序提供「執行程序安全性邊界」（VM Security Boundary）防護機制（如圖 10 所示），當 ESXi 主機的工作負載調度選項，組態設定為「hyperthreadingMitigation = TRUE」和「hyperthreadingMitigationIntraVM = TRUE」時，便會啟用執行程序安全性邊界防護機制。簡單來說，採用執行程序安全性邊界防護機制後，可以為 VM 虛擬主機提供最高的安全性等級，但是必須犧牲 VM 虛擬主機大量的運作效能來換取最佳安全性。
圖 10、執行程序安全性邊界運作架構示意圖
如何採用新式 SCAv2 調度程序
那麼，管理人員應該如何組態設定 ESXi 主機的工作負載調度機制，採用新版 vSphere 6.7 U2 才開始支援的 SCAv2 工作負載調度選項，以便兼顧 VM 虛擬主機的安全性和運作效能。在下列表格中，為各位讀者整理工作負載調度機制組態設定一覽表：工作負載調度機制和參數值 | hyperthreadingMitigation | hyperthreadingMitigationIntraVM |
預設值（未進行防護） | FALSE | TRUE 或 FALSE |
SCAv1 | TRUE | TRUE |
SCAv2 | TRUE | FALSE |
管理人員可以登入 vCenter Server 管理介面後，依序點選「Datacenter > Cluster > ESXi Host > Configure > System > Advanced System Settings」項目，組態設定「VMkernel.Boot.hyperthreadingMitigation = true」和「VMkernel.Boot.hyperthreadingMitigationIntraVM = false」後（如圖 11 所示），重新啟動該台 ESXi 主機以便套用生效，採用新式的 SCAv2 工作負載調度選項。
請注意 !必須採用 vSphere ESXi 6.7 U2（13006603）或後續版本，才能支援新式的 SCAv2 工作負載調度選項，其餘舊版 ESXi 6.0、6.5、6.7 僅支援舊式 SCAv1工作負載調度選項。
圖 11、組態設定 ESXi 主機採用新式的 SCAv2 工作負載調度選項
倘若，管理人員習慣使用指令管理 ESXi 主機組態設定時，請採用下列「esxcli system settings kernel <set | list>」指令（如圖 12 所示），組態設定 ESXi 主機採用新式的 SCAv2 工作負載調度選項，並再確認組態設定值無誤後，重新啟動以便套用生效。
圖 12、採用 esxcli 指令組態設定 ESXi 主機採用新式的 SCAv2 工作負載調度選項
增強 DRS 調度工作負載
事實上，從新版 vSphere 6.7 版本開始，在 DRS（Distributed Resource Scheduler）的部份便增強原有機制，讓 DRS 在調度 VM 虛擬主機工作負載方面能夠更彈性更靈活。增強初始化放置機制
在過去的 vSphere 版本中，當 vSphere Cluster 啟動 DRS 分佈式資源調度機制之後，除了可能耗用更多的 vCenter Server 硬體資源之外（如圖 13 所示），在某些情況下也無法快速的啟動和放置 VM 虛擬主機，舉例來說，在多個同時併發的高工作負載運作環境下，新版 vSphere 6.7 的 DRS 運作環境將能更快的啟動 VM 虛擬主機，並且能更平均的擺放 VM 虛擬主機至每台 ESXi 叢集節點主機中。
圖 13、新版 DRS 分佈式資源調度機制有效節省 vCenter Server 硬體資源的耗用
增強主機維護模式
在 vSphere 虛擬化環境中，當管理人員透過 vUM 更新管理機制結合 DRS 進行版本升級作業時，必須依靠 DRS 智慧演算法建議可以進入維護模式的 ESXi 節點主機，並且將其上運作的 VM 虛擬主機，透過 vMotion 線上遷移機制進行工作負載疏散的動作。然而，在過去的 DRS 版本中，將會「同時」對所有運作中的 VM 虛擬主機進行 vMotion 線上遷移作業，造成大量併發的 vMotion 網路流量，有可能產生不可預期的錯誤和隱憂。現在，DRS 透過增強的主機維護模式，將會針對 VM 虛擬主機進行分批遷移的動作（每次僅遷移 8 台 VM 虛擬主機），同時受惠於分批遷移機制讓遷移後的 VM 虛擬主機，能夠更平均的分佈於 Cluster 當中的每台 ESXi 叢集主機上繼續運作。
支援採用 vPMem 和 vPMemDisk 的虛擬主機
新一代的 NVM（Non-Volatile Memory）持續性記憶體儲存裝置，由於提供類似 DRAM 的超低延遲時間和極大傳輸頻寬，而被企業和組織開始應用於關鍵性的營運服務中。當 ESXi 虛擬化平台配置 PMEM（Persistent Memory）儲存裝置時，支援下列二種 VM 虛擬主機掛載應用方式（如圖 14 所示）：- vPMemDisk：透過此運作模式，可以將 PEME 儲存資源掛載至 VM 虛擬主機成為 vDisk 虛擬磁碟。因此，VM 虛擬主機內的作業系統和應用程式無須進行任何修改，即可使用 PMEM 儲存資源。
- vPMem：將 PMEM 儲存資源以 NVDIMM 儲存裝置提供給 VM 虛擬主機，大部份新版的作業系統，例如，Windows Server 2016、RHEL 7.4……等，皆支援 NVDIMM 儲存裝置。
圖 14、vSphere PEME 運作架構示意圖
值得注意的是，當管理人員為 VM 虛擬主機掛載使用 vPMemDisk 時，在 VM 虛擬主機組態設定方面，請確保該 vDisk 虛擬磁碟中的 VM Storage Policy 必須設定為「Host-local PMem Default Storage Policy」，當 VM 虛擬主機掛載使用 vPMem 時，則必須先新增 NVDIMM 儲存控制器後，再新增「NVDIMM 儲存裝置」（如圖 15 所示）。
圖 15、為 VM 虛擬主機新增 vPMemDisk 或 vPMem 儲存裝置
了解 vMotion 線上遷移機制的管理人員應該了解，當 VM 虛擬主機採用標示為本地端的儲存資源時，必須搭配採用 Storage vMotion 機制才能夠遷移 VM 虛擬主機。現在，新版 DRS 分佈式資源調度機制，已經直接支援掛載使用這些新式儲存裝置的 VM 虛擬主機，因此無論是 VM 虛擬主機的自動化 vMotion 線上遷移（如圖 16 所示），進行 ESXi 節點主機工作負載平衡，或是 VM 虛擬主機啟動時的自動放置作業等都能完全支援。
圖 16、新版 DRS 分佈式資源調度機制，已完全支援使用新式儲存裝置的 VM 虛擬主機
圖片來源： VMware Blogs - Live Migration of SAP HANA 2.0 SP3 Deployed on Persistent Memory on vSphere 6.7
增強資源集區預留機制
在新版 DRS 分佈式資源調度機制中，採用新的「兩階段演算法」（Two-Pass Algorithm），來處理「資源集區」（Resource Pool）分配資源給 VM 虛擬主機的部份。簡單來說，新的演算法在第一階段時，先在資源集區中根據 VM 虛擬主機的需求分配資源，在第二階段時依據預留和限制等組態設定值，分配相對應的資源給 VM 虛擬主機。舉例來說，我們在新舊版本的 DRS 分佈式資源調度機制中，建立一個資源集區並指派 4 台 VM 虛擬主機於其中，同時在資源集區中記憶體的部份組態設定預留 10 GB（如圖 17 所示）。
圖 17、建立資源集區並組態設定記憶體預留 10GB
可以看到舊版的 DRS 分佈式資源調度機制中，因為會根據需求將資源集區預留給子項目，所以 VM 虛擬主機能夠從資源集區中獲得的資源較少，而新式 DRS 分佈式資源調度機制中的 VM 虛擬主機，則可以充分獲得資源集區中所有分配的硬體資源（如圖 18 所示）。
圖 18、新舊 DRS 分佈式資源調度機制 VM 虛擬主機獲得硬體資源比例示意圖
結語
透過本文的深入剖析和實際進行最佳化組態設定後，相信讀者已經了解如何從一開始硬體伺服器的 BIOS 組態設定，到 ESXi 主機網路組態設定最佳化，並且採用新版 vSphere 6.7 U2 才支援的 SCAv2 調度選項，確保企業和組織的 vSphere 虛擬化資料中心，能夠擁有高安全性環境的同時仍然保有極佳的運作效能。↧
↧
Microsoft Azure Training Day Fundamentals 筆記
簡介
今天來參加 Microsoft Azure Training Day: Fundamentals實體教育訓練課程，學習有關 Microsoft Azure 雲端服務和基礎知識，例如，公有雲、私有雲、混合雲、基礎架構即服務（IaaS）、平台即服務（PaaS）、軟體即服務（SaaS），以及 Microsoft Azure 服務與解決方案，例如，安全性、隱私權、符合法規、信任、定價、支援方案。下列為相關參考網址：筆記
下列為各章節的筆記以及參考網址：Module 1 - Cloud Concepts
Cloud Concepts - Principles of cloud computing- Introduction
- What is cloud computing ?
- Benefits of cloud computing
- Compliance terms and requirements
- Economies of scale
- Capital expenditure (CapEx) versus operational expenditure (OpEx)
- Cloud deployment models (Public / Private / Hybrid)
- Types of cloud services (IaaS / SaaS / PaaS)
- Knowledge Check
- Summary
圖、Virtual Machines, Containers, Serverless 示意圖
圖片來源： What is cloud computing?
圖、CapEx 模組示意圖
圖、On-Premises, IaaS, PaaS, SaaS 示意圖
圖片來源： Types of cloud services
Module 2 - Core Azure Services
Core Azure Architectural Components
Core Cloud Services - Explore Azure architecture and service guarantees- Introduction
- Understand Datacenters and Regions in Azure
- Understand Geographies in Azure
- Understand Availability Zones in Azure
- Understand Region Pairs in Azure
- Understand Service-Level Agreements for Azure
- Compose SLAs across services
- Improve your app reliability in Azure
- Summary
圖、Microsoft Azure Region
圖、Availability Zone 示意圖
圖、Region Pair 示意圖
圖、SLA Level 表格
圖、每項服務的 SLA Level 示意圖
Core Azure Services and Products
Core Cloud Services - Introduction to Azure compute- Introduction
- Essential Azure compute concepts
- Explore Azure Virtual Machines
- Explore Containers in Azure
- Explore Azure App Service
- Explore Serverless computing in Azure
- Summary
圖、Availability Set 運作架構示意圖
圖、遷移 Apps 至 Containers 流程示意圖
圖、Functions 與 Logic Apps 功能差異比較表
Azure Network Services
Core Cloud Services - Introduction to Azure networking- Introduction
- Deploy your site to Azure
- Scale with Azure Load Balancer
- Reduce latency with Azure Traffic Manager
- Summary
圖、N-tier Architecture 運作架構示意圖
圖、Azure Load Balancer 運作架構示意圖
圖、Azure Application Gateway 運作架構示意圖
圖、Azure Traffic Manager 運作架構示意圖
Azure Storage Services
Core Cloud Services - Azure data storage options- Introduction
- Benefits of using Azure to store data
- How Azure data storage can meet your business storage needs
- Comparison between Azure data storage and on-premises storage
- Knowledge check
- Summary
圖、Azure Files 運作架構示意圖
圖、On-Premises Storage 和 Azure Data Storage 差異比較表
Azure Management Tools
Core Cloud Services - Manage services with the Azure portal- Introduction
- Azure management options
- Navigate the portal
- Exercise - Work with panes
- Exercise - Use the Azure portal
- Azure Portal dashboards
- Exercise - Customize the dashboard
- Access public and private preview features
- Summary
圖、Azure mobile app 示意圖
圖片來源： Azure management options
圖、Azure Advisor 操作畫面示意圖
圖片來源： Navigate the portal
圖、Services pane 操作畫面示意圖
Module 3 - Security, Privacy, Compliance and Trust
Security, responsibility, and trust in Azure- Introduction
- Cloud security is a shared responsibility
- Get tips from Azure Security Center
- Identity and access
- Encryption
- Overview of Azure certificates
- Protect your network
- Protect your shared documents
- Azure Advanced Threat Protection
- Understand Security Considerations for Application Lifecycle Management Solutions
- Summary
圖、了解安全性威脅
圖、RBAC (Role-Based Access Control) 指派層級示意圖
圖片來源： Identity and access
圖、文件傳輸加密示意圖
圖片來源： Encryption
圖、Azure DDoS Protection 運作架構示意圖
圖片來源： Protect your network
圖、開啟加密文件示意圖
圖、Azure ATP (Advanced Threat Protection) 示意圖
Module 4 - Azure Pricing and Support
Predict costs and optimize spending for Azure- Introduction
- Purchase Azure products and services
- Factors affecting costs
- Exercise - Estimate costs with the Azure pricing calculator
- Exercise - Predict and optimize with Cost Management and Azure Advisor
- Exercise - Estimate the Total Cost of Ownership with the Azure TCO calculator
- Save on infrastructure costs
- Save on licensing costs
- Summary
圖、 Azure billing zones 資料中心列表
圖片來源： Factors affecting costs
圖、Azure Cost Management 畫面示意圖
圖、Azure TCO Report 示意畫面
圖、了解計費差異
圖、Azure Hybrid Benefit for SQL Server licenses 差異
圖片來源： Save on licensing costs
↧
網管人 167 期 - 依需求客製化映像 SQL Server 容器輕鬆部署
網管人雜誌
本文刊載於 網管人雜誌第 167 期 - 2019 年 12 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。前言
實戰 – Windows Server 2019 容器環境
下載和部署 SQL Server Express 容器
透過 Windows Admin Center 管理容器
客製化 SQL Server Express 容器
部署 Linux Based 的 SQL Server 容器
結語
前言
隨著容器風潮及微服務架構的興起，企業和組織對於容器調度平台的需求也不斷上升。事實上，容器管理技術之所以受到大家熱烈歡迎的重要原因之一，在於能夠有效解決過去困擾開發人員與維運人員的難題，也就是如何快速建立完整的開發和測試環境甚至是正式營運環境，舉例來說，未採用容器技術時，當開發人員需要特定的研發和測試環境，維運人員便要依照需求建立 VM 虛擬主機、安裝客體作業系統、組態設定網路環境、開通防火牆規則……等，將作業系統層級處理完畢後，再交給開發人員安裝應用程式和載入函式庫……等應用程式層級的部份，此時才算準備好開發環境並可能花費幾天的作業時間，然而容器技術的出現正好能夠快速解決這個困擾已久的問題。然而，企業和組織的管理人員應該已經發現，雖然容器技術能夠有效縮短運作環境建立的難題，但是在後續維運管理上卻為企業和組織帶來更多的挑戰和難題，舉例來說，在企業和組織既有虛擬化基礎架構中的 VM 虛擬主機，當底層實體伺服器需要進行硬體維運作業時，可以透過 Live Migration 即時遷移機制，線上不中斷的將 VM 虛擬主機遷移至別台實體伺服器上繼續運作，但是在容器運作環境中，針對容器的部份並沒有所謂即時遷移工作負載的概念，因為容器的基本運作概念就是螞蟻雄兵式分散整個大型工作負載，和一般維運人員習慣的高可用性機制並不相同。
此外，容器原生最適合的運作環境為「無狀態」（Stateless），但是企業和組織過去在 VM 虛擬主機上運作的工作負載則通常多為「有狀態」（Stateful），這在維運管理的習慣上也必須要進行調整。
因此，目前大家所公認的解決方案，便是在既有的虛擬化基礎架構中，將容器分批運作在不同的 VM 虛擬主機當中，如此一來便能將 VM 虛擬主機和容器這兩者的長處互相結合（如圖 1 所示）。
圖 1、VM 虛擬主機和容器協同運作架構示意圖
本文，將採用最新 Windows Server 2019 作業系統為實戰環境，並搭配啟用「容器」（Containers）的伺服器功能後，實作演練部署和運作 SQL Server 容器，以及當官方釋出的 SQL Server 容器映像檔不符合需求時，應該如何自行打包出客製化的 SQL Server 容器映像檔。
實戰 – Windows Server 2019 容器環境
在本文實作環境中，我們為採用 Windows Server 2019 作業系統的主機，安裝 「Windows 套件管理工具」（Windows PackageManagement）（如圖 2 所示），以便管理人員後續可以透過 PowerShell Cmdlet 指令，輕鬆為 Windows Server 2019 主機進行安裝、移除、查詢 …… 等軟體套件的管理作業。Windows 套件管理工具舊有名稱為 「OneGet Provider PowerShell Module」。現在，微軟已經正式重新命名為「Windows PackageManagement」。
圖 2、Windows PackageManagement 運作架構示意圖
請在透過管理者執行權限開啟的 PowerShell 視窗中，執行安裝 Docker Microsoft 套件管理提供者指令後，系統將會自動至 PowerShell Gallery 下載所需的軟體套件，並啟用 Windows Server 2019 主機的「容器」（Containers）伺服器功能後，為主機安裝 Docker 引擎和 Docker 用戶端。
接著，當 Docker Microsoft 套件管理機制安裝完成後，便會自動下載和安裝最新 Docker EE 企業版本的動作，在安裝程序中系統將會詢問是否信任此 PowerShell 封裝來源，請鍵入 Y 或 A 之後繼續安裝程序，當安裝作業完成後，系統將會提醒管理人員應該重新啟動主機以便套用生效，此時請鍵入「Restart-Computer -Force」指令重新啟動主機即可（如圖 3 所示）。
圖 3、透過 Windows PackageManagement 套件管理機制安裝最新 Docker EE 企業版本
當 Windows Server 2019 主機安裝的工作任務完成並重新啟動後，首先請確認主機是否多出一項名稱為「Docker Engine」（如圖 4 所示），並組態設定為自動啟動的系統服務。同時，主機也將多出名稱為「vEthernet（nat）」的網路卡，網路組態設定資訊 IP 位址為「172.x.x.x」子網路遮罩則是「255.255.240.0」，這將是屆時容器主機在部署和運作容器時，用於介接容器虛擬網路時使用。
確認主機 Docker Engine 系統服務順利啟動，並且網路功能運作正常後，管理人員便可以使用「docker info」和「docker version」指令，確認 Docker 容器的版本和運作資訊。
圖 4、確認 Docker 容器運作環境資訊和版本
下載和部署 SQL Server Express 容器
過去，在企業和組織的研發測試環境中，當需要小型 SQL Server 資料庫環境時，經常會採用 SQL Server Express 免費版本的資料庫，然而無論採用實體主機或 VM 虛擬主機，原則上都只能運作「單個」SQL Server Express 執行個體。現在，我們已經為 Windows Server 2019 主機準備好容器運作環境，接著便能透過運作 SQL Server Express 容器，輕易在單台主機中運作「多個」SQL Server Express 執行個體，因此後續無論要新增 SQL Server Express 執行個體，或是打掉測試環境重新建立 SQL Server Express 運作環境，相較於傳統實體主機或 VM 虛擬主機環境，除了更容易建構環境之外更節省許多建置時間。
首先，請在 PowerShell 視窗中執行「docker pull microsoft/mssql-server-windows-express」指令（如圖 5 所示），容器主機便會連線至 Docker Hub 網站中，下載由 Microsoft 官方打包建立的 SQL Server Express 容器映像檔 ，屆時這個 Windows 類型的 SQL Server Express 容器，可以部署和運作在 Windows Server 2016 或後續版本，以及 Windows 10 Professional/Enterprise 等容器主機環境中。
順利下載 SQL Server Express 容器映像檔之後，可以鍵入「docker images」指令查看容器映像檔資訊。
圖 5、下載 Microsoft 官方打包建立的 Windows SQL Server Express 容器映像檔
在下載 SQL Server Express 容器映像檔期間，我們在 Windows Server 2019 容器主機上，下載並安裝最新版本的 SSMS（SQL Server Management Studio）管理工具，以便稍後能夠透過 SSMS 管理工具連線並管理 SQL Server Express 容器。
在本文實作環境中，下載並安裝最新版本的 SSMS 18.3.1管理工具，不僅支援 Azure SQL DB和 Azure SQL DW之外，也同時支援管理最新的 SQL Server 2019運作環境。
請在 PowerShell 指令視窗中鍵入「docker run -d -p 1433:1433 --name sqlserver -e sa_password=Weithenn@168 -e ACCEPT_EULA=Y -v c:\sqlcontainerdb:c:\sqldb microsoft/mssql-server-windows-express」指令（如圖 6 所示），以便部署並運作 SQL Server Express 容器，下列為部署和運作容器的指令參數詳細說明：
- docker run ：部署和運作新的容器。
- -d ：將部署的容器運作在「背景」（Background）模式，並且顯示其容器 ID 。
- -p 1433:1433 ：將部署容器的服務連接埠和容器主機的本機連接埠進行對應。
- --name sqlserver ：組態設定所部署容器的名稱。
- -e sa_password=Weithenn@168 ：組態設定部署的 SQL Server Express 容器時，預設 sa 帳號的管理者密碼。
- -e ACCEPT_EULA=Y ：組態設定部署 SQL Server Express 容器時，直接同意終端使用者授權協議，以便 SQL Server Express 容器能夠順利啟動。
- -v c:\sqlcontainerdb:c:\sqldb ：組態設定 SQL Server Express 容器中「C:\sqldb」儲存路徑，對應至容器主機的「C:\sqlcontainerdb」本機路徑。
- microsoft/mssql-server-windows-express ：部署此容器所採用的容器映像檔名稱。
請注意，倘若「未」加上 -v參數組態設定 SQL Server Express 容器，與容器主機進行儲存路徑對應的話，那麼屆時儲存於 SQL Server Express 容器中的資料庫內容，將會因為刪除 SQL Server Express 容器而一起被刪除。
圖 6、部署和運作 SQL Server Express 容器
由於，本文實作環境中，容器主機採用最新 Windows Server 2019 作業系統版本，然而微軟官方最後釋出的 SQL Server Express 容器中，底層採用 Windows Server 2016 作業系統版本。因此，若採用預設的「Windows Server Container」機制部署 SQL Server Express 容器時，便會因為作業系統版本不一致，而導致出現上述「The container operating system does not match the host operating system.」的錯誤訊息（如圖 6 所示）。
有關部署 SQL Server Express 容器時，遭遇不相符版本錯誤的詳細資訊，請參考 Microsoft Docs – Windows Container version compatibility 文章內容。
此時，請先為 Windows Server 2019 容器主機安裝 Hyper-V 伺服器角色後，便可以在部署 SQL Server Express 容器時，加上「--isolation=hyperv」參數，採用「Hyper-V Container」機制來部署和運作 SQL Server Express 容器（如圖 7 所示）。
在 Windows 容器運作環境中支援兩種不同的類型，分別是與 Linux 容器環境類似的「Windows Server Container」，以及具備更高安全性和隔離性的「Hyper-V Container」，有關這兩者容器類型的詳細說明，請參考 【 網管人雜誌第 139 期 - 共用系統核心資源，玩轉 Windows Server 容器 】文章內容。
圖 7、採用 Hyper-V Container 機制部署 SQL Server Express 容器
順利部署和運作 SQL Server Express 容器後，首先我們在 PowerShell 指令視窗中鍵入「docker logs sqlserver」指令，查看 SQL Server Express 容器的日誌內容，確認 SQL Server Express 資料庫服務是否已經啟動完成，接著鍵入「docker exec sqlserver ipconfig」指令，查詢 SQL Server Express 容器採用的 IP 位址（如圖 8 所示），以便稍後採用 SSMS 管理工具進行連線管理的動作。
管理人員只要鍵入「docker exec sqlserver systeminfo」，即可確認 SQL Server Express 容器所採用的作業系統版本。
圖 8、查看 SQL Server Express 容器日誌內容和 IP 位址
請在開啟的 SSMS 管理工具「Server Name」欄位中，鍵入 SQL Server Express 容器的 IP 位址（本文實作環境為「172.24.135.172」），以及剛才部署和運作 SQL Server Express 容器時，指定的 sa 管理者密碼後，按下 Connect 鈕即可連線至由 SQL Server Express 容器運作的資料庫服務（如圖 9 所示）。
圖 9、透過 SSMS 管理工具連線管理 SQL Server Express 容器運作的資料庫服務
在 SSMS 管理工具介面中，我們可以在 New Query 視窗中執行「SELECT @@VERSION」指令，查看目前採用的 SQL Server Express 容器的版本資訊，可以看到採用的是 Microsoft SQL Server 2017 版本（如圖 10 所示）。
圖 10、查詢 SQL Server Express 容器的 SQL Server 版本資訊
接著，我們透過 SSMS 管理工具嘗試建立新的資料庫，請依序點選「Databases > New Database」，在 New Database 視窗中，於 Database name 欄位鍵入新增的資料庫名稱（本文實作環境為「db01」），並指定將新增的資料庫存放於跟容器主機所對應的「C:\sqldb」儲存路徑，待新增資料庫建立完畢後切換回容器主機的「C:\sqlcontainerdb」本機路徑，確認是否在 SQL Server Express 容器中，所新增建立的資料庫和記錄都直接對應存放至容器主機上（如圖 11 所示），以避免屆時刪除 SQL Server Express 容器時，一併將建立的資料庫和記錄一起刪除。
圖 11、新增資料庫並存放於容器主機所對應的儲存路徑
透過 Windows Admin Center 管理容器
在 Windows Admin Center 1903 版本時，推出「容器」（Containers）的預覽功能，並在 Windows Admin Center 1904 版本時，正式脫離預覽狀態並納入至擴充功能中。因此，管理人員只要在容器主機的 Windows Admin Center 管理介面中，依序點選「Settings > Extensions > Available extensions > Containers > Install」，即可為容器主機安裝 Windows Admin Center 的容器擴充功能。待容器擴充功能安裝完成後，管理人員便可以透過 Windows Admin Center ，查看和管理容器主機上所部署的容器，例如，查看容器主機上部署的容器概要資訊、運作的容器和日誌資訊、容器映像檔、容器網路、容器磁碟區……等（如圖 12 所示）。
圖 12、透過 Windows Admin Center 查看和管理容器
客製化 SQL Server Express 容器
在前面的實作中可以看到，目前在 Docker Hub 網站中， Microsoft 官方所打包的 Windows Based SQL Server Express 容器，採用的底層作業系統版本為 Windows Server 2016 ，並且後續沒有釋出採用最新 Windows Server 2019 作業系統版本的容器映像檔。因此，企業或組織倘若需要這樣的運作環境容器映像檔時，目前只能手動自行打包 SQL Server Express 容器映像檔，所幸在 GitHub 中 Microsoft 官方已經準備好 dockerfile 範本，管理人員只要下載 Dcokerfile 範本後，將內容中「FROM」來源由原本的「microsoft/windowsservercore」，修改為採用「mcr.microsoft.com/windows/servercore:ltsc2019」，也就是指定採用 Windows Server 2019 LTSC 作業系統版本，當成 SQL Server Express 容器底層作業系統版本。
準備好 Dockerfile 檔案以及官方提供的 start.ps1 檔案後，即可執行「docker build -t weithenn/sql-ws2019 .」指令（如圖 13 所示），建立採用 Windows Server 2019 Server Core 為底層作業系統的 SQL Server Express 容器。
有關自行打包客製化 SQL Server Express 容器的詳細資訊，以及 Dockerfile 範例檔案和 start.ps1 檔案內容，請參考 GitHub 網站 Microsoft 官方 mssql-docker 專案網頁。
圖 13、自行打包採用 Windows Server 2019 Server Core 為底層作業系統的 SQL Server Express 容器
順利打包客製化的 SQL Server Express 容器後，首先請執行「docker images」指令，查看容器主機上容器映像檔資訊，即可看到剛才所建立的「weithenn/sql-ws2019」容器映像檔，然後再次執行「docker run」指令並搭配剛才所建立的「weithenn/sql-ws2019」容器映像檔（如圖 14 所示），以便部署和運作客製化的 SQL Server Express 容器，接著執行「docker ps」指令確認部署的容器已正常運作。
圖 14、部署和運作客製化 SQL Server Express 容器
順利部署和運作客製化 SQL Server Express 容器後，同樣先在 PowerShell 指令視窗中鍵入「docker logs sqlserver2019」指令，查看 SQL Server Express 容器的日誌內容，確認 SQL Server Express 服務是否已經啟動完成，接著鍵入「docker exec sqlserver2019 systeminfo」指令，查詢 SQL Server Express 容器所採用作業系統版本（如圖 15 所示），是否為我們所客製化採用的 Windows Server 2019 Datacenter 作業系統版本。
圖 15、確認客製化 SQL Server Express 容器的底層作業系統版本資訊
部署 Linux Based 的 SQL Server 容器
過去談到 SQL Server 資料庫服務時，企業和組織的既定印象便是只能運作在 Windows Server 主機上，然而從 SQL Server 2017 版本開始，微軟便開始支援將 SQL Server 運作在 Linux 作業系統當中。因此，在部署和運作 SQL Server 容器時，除了選擇採用 Windows Based 的 SQL Server 容器之外，管理人員也可以選擇採用新一代的 Linux Based SQL Server 容器。值得注意的是，在預設情況下 Windows Server 2019 的容器功能，僅支援運作 Windows Based 容器，這是由於在容器技術中， Windows 和 Linux 作業系統在底層核心方面就有根本上的不同。因此，倘若管理人員嘗試直接下載 Linux Based 的 SQL Server 容器映像檔時，系統便會回應嘗試下載的容器映像檔為「Linux」，無法支援目前這個作業系統的訊息（如圖 16 所示）。
圖 16、預設情況下， Windows Server 2019 容器主機並不支援下載和部署 Linux 容器
當然， Windows 和 Linux 容器混合運作的環境， Microsoft 已經有考慮到，所以推出「LCOW（Linux Container on Windows）」機制（如圖 17 所示），只要啟用 LCOW 功能並搭配 Hyper-V Container 機制，即可為 Windows Server 2019 容器主機，開啟支援運作 Linux 容器的功能，達成在單台容器主機上，同時運作 Windows 和 Linux 容器的目的。
圖 17、LCOW（Linux Container on Windows） 運作架構示意圖
首先，在環境變數的部份，請組態設定「LCOW_SUPPORTED」參數值為「1」（如圖 18 所示），接著組態設定 Docker 系統服務的「daemon.json」組態設定檔，最後下載和解壓縮 最新版本的 LCOW（本文實作環境為 v4.14.35-v0.3.9 版本），以便部署的 Linux 容器能夠有完整的 Linux 核心檔案以便順利運作。
請注意，組態設定 Windows Server 2019 容器主機支援 LCOW 功能後，必須重新啟動主機才能夠套用生效。
圖 18、組態設定 Windows Server 2019 容器主機支援 LCOW 功能
在正式部署和運作 Linux Based 的 SQL Server 容器之前，我們先測試 Windows Server 2019 容器主機，是否能夠順利部署和運作 Linux 容器，請鍵入「docker run -it --platform=linux centos」指令，快速部署和運作底層為 CentOS 作業系統的 Linux 容器。如圖 19 所示，可以看到 Windows Server 2019 容器主機，順利部署和運作採用 CentOS 8.0 作業系統的 Linux 容器。
當 Windows Server 2019 容器主機啟用 LCOW 功能後，在部署和運作 Linux 容器時，請加上「--platform=linux」參數。
圖 19、部署和運作採用 CentOS 8.0 作業系統的 Linux 容器
現在，我們可以正式部署和運作 Linux Based 的 SQL Server 容器，在本文實作環境中，我們部署最新版本的 SQL Server 2019 on Ubuntu 容器，然而管理人員可能會發現， Linux Based 的 SQL Server 容器部署完成後，狀態卻直接顯示為「Exited」無法順利運作，查看 SQL Server 容器日誌內容，可以發現「sqlserver : This program requires a machine with at least 2000 megabytes of memory.」錯誤訊息（如圖 20 所示）。
圖 20、無法順利運作 Linux Based 的 SQL Server 容器
請在部署和運作 Linux Based 的 SQL Server 容器指令中，加上「--memory=2G」參數進行使用記憶體的限制（如圖 21 所示），即可順利運作 Linux Based 的 SQL Server 容器。當 SQL Server 容器順利啟動後，可以看到底層採用的作業系統為 Ubuntu 16.04.6 LTS 版本，搭配最新 Microsoft SQL Server 2019 CTP Developer Edition 。
預設情況下， SQL Server on Linux 容器將會採用 Developer 版本，管理人員可以搭配「-e MSSQL_PID」參數指定版本，例如， Express、Standard、Enterprise、EnterpriseCore……等。
圖 21、部署和運作 Linux Based 的 SQL Server 容器，並確認作業系統和 SQL Server 版本資訊
結語
透過本文的深入剖析和實戰演練後，相信讀者已經了解採用 SQL Server 容器，確實能夠有效縮短建構研發和測試環境，並且在新一代的 Windows Server 2019 作業系統中，還能夠同時執行混合 Windows 和 Linux 容器的運作環境。此外，當官方容器映像檔不符合企業和組織需求時，也能夠自行依照需求打包客製化的容器映像檔。↧
[站長開講] VMware vForum Taiwan 2019
活動簡介
vFORUM 2019 精選了重大的技術應用趨勢，呈現在您的面前，幫助您加速雲端歷程，全方面支援業務發展需求。同時，協助您與企業推動網路與安全性的轉型，達到速度與彈性的要求；並提供數位工作區，實現令人驚豔的行動體驗。所有您需要知道的答案、最佳解決方案與工具，都能透過 vFORUM 2019 獲得解答與協助，讓您能夠帶領團隊重新塑造 IT，將技術實力提升到新的境界，協助您獲致成功。邀請您一起動起來，超越眾人對於 IT 的期望，照亮未來發展的路途！歡迎加入這個能夠不斷創下新紀錄的 IT 世界，vFORUM 2019 獻上至誠，期盼您的蒞臨。
活動資訊
日期： 2019 年 12 月 10 日 (星期二)時間： 8:15 ~ 17:15
地點： 台北市中山區樂群二路199號 (台北萬豪酒店)
報名： 活動報名
議程： 大會議程
↧
VMware vExpert 2020 開放申請
前言
過去，在每一年的年初和年中時，VMware 官方便會開放一年一度申請 VMware vExpert的活動。今年，也就是 VMware vExpert 2020 的活動已經開始開放申請，VMware vExpert其實是個類似 Microsoft MVP的技術頭銜也是採「申請制」。簡單來說，請提交你認為對該產品有哪些貢獻，之後交由原廠審核並認同你是否真的值得獲得此技術頭銜。目前，截至 2019 年底為止全球的 vExpert 人數為 1,862 位 (台灣連同站長共有 6 位獲選)。
申請 vExpert 2020 注意事項
今年，開放申請期間至「2020 年 1 月 10 日 (PDT 時區)」，並且預計在 2 月底 3 月初進行公佈獲選人員名單。參選詳細資訊請參考 VMware vExpert Blog - vExpert 2020 Applications are Open!。申請成為 VMware vExpert 的路徑
請可以依照個人的貢獻程度，透過下列不同路徑進行 VMware vExpert 2020的申請：- 技術傳教士路徑 (Evangelist Path)：選擇此申請路徑者，通常為 書籍作者 (Book Authors)、部落客 (Bloggers)、工具建立者 (Tool Builders)、公開演說者 (Public Speakers)、VMTN 貢獻者 (VMTN Contributors)...等，簡單說就是透過個人途徑把 VMware 技術發享出去。
- 使用者路徑 (Customer Path)：選擇此申請路徑者，通常是 VMware 企業客戶的 Leaders，透過建置 VMware 的成功經驗讓其它客戶當參考，或者是 VMUG (VMware User Group) Leaders...等，都可以申請。
- VMware 合作夥伴路徑 (VMware Partner Network Path)：選擇此申請路徑者，通常是 VMware 合作夥伴透過 教學影片、研討會 方式將技術發享出去...等，都可以申請。
- VCDX 路徑 (VCDX Path)：選擇此申請路徑者，只適用於你已經持有 VCDX 證照才能申請。
因為，我是負責 APJ 區域的 vExpert PRO，倘若你有興趣申請 VMware vExpert 但是參考上述說明後，仍然有任何不了解的地方，歡迎大家找我討論或者到 VMUG Taiwan Community與大家討論你的疑惑。
獲選 VMware vExpert 的好處
當你申請後獲選為 VMware vExpert 的話有哪些好處呢？ 你可以獲得 Private Beta 的測試機會、VMware Free Licenses (365 Days)、免費存取 VMworld 會議資料...等，如下列所示：- Invite to our private #Slack channel
- vExpert certificate signed by our CEO Pat Gelsinger.
- Private forums on communities.vmware.com.
- Permission to use the vExpert logo on cards, website, etc for one year
- Access to a private directory for networking, etc.
- Exclusive gifts from various VMware partners.
- Private webinars with VMware partners as well as NFRs.
- Access to private betas (subject to admission by beta teams).
- 365-day eval licenses for most products for home lab / cloud providers.
- Private pre-launch briefings via our blogger briefing pre-VMworld (subject to admission by product teams)
- Blogger early access program for vSphere and some other products.
- Featured in a public vExpert online directory.
- Access to vetted VMware & Virtualization content for your social channels.
- Yearly vExpert parties at both VMworld US and VMworld Europe events.
- Identification as a vExpert at both VMworld US and VMworld EU.
↧
↧
關於站長 (2019 年度自我回顧)
關於本站
本網站所引用他人商標或圖示均屬該來源網站或其合法權利人所有，本站內容多為個人研究心得，其所寫之實作筆記內容多為參考網路上資料並實際操作後所記錄完成，歡迎分享網站內容並標示出處及作者但僅限於非商業用途連結，且禁止改作(若你重混、轉換本素材，或依本素材建立新素材，則你不得散布改作後的素材!!) [本網站內容受 創用 CC 授權 3.0保護]，本網站若有任何地方侵犯到您權利的地方，請 Mail 給我 將會立刻處理謝謝您。Weithenn 摸索 IT 世界回顧：
- 職涯第 1 個 10 年： 2002 年、2003 年、2007 年、2010 年、2011 年
- 職涯第 2 個 10 年： 2012 年、2013 年、2014 年、2015 年、2016 年、2017 年、2018 年、2019 年 ~ Coming Soon👻
2019 年
12 月：
擔任 VMware vForum Taiwan 2019議程講師。
11 月：
擔任 OpenInfra Days Taiwan 2019議程講師。
10 月：
擔任 Cloud Native Forum 2019 議程講師。
9 月：
(1) 擔任 Dell Technologies Forum 2019議程講師。
(2) 擔任 Kubernetes Summit 2019 議程講師。
7 月：
(1) 第 8 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。
(2) 擔任 聖約翰科大 - ABC 高科技人工智慧碩士學分班業界講師。
(3) 完成人生中 第 19 本 著作 (英文翻譯書) VMware vSAN 6.7 U1 Deep Dive 中文版
6 月：
(1) 擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。(2) 擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。
(3) 地球村走一回，今年插旗的國家是 波波斯之旅 (波羅的海三小國 / 波蘭 / 斯洛伐克)。
5 月：
擔任 Cloud & Edge Summit 2019議程講師。
3 月：
(1) 第 8 度當選 VMware vExpert 2019 技術專家 VMware vExpert Information - Wei-Ren Wang，在 2018 年全球共有 1,731 位 VMware vExpert (Taiwan 共 5 位獲選)。
(2) 擔任 Windows Server 2019 成就多雲資料中心現代化議程講師。
2018 年
10 月：
(1) 首度當選 VMware vExpert PRO 技術專家 VMware vExpert Information - Wei-Ren Wang，這是由 2018 年全球 1536 位 VMware vExpert 2018 成員中再度選出 46 位獲選為 vExpert PRO。
(2) 擔任 Acer / Microsoft - Tech 2019 New Future - Windows Server 2019議程講師。
9 月：
(1) 擔任 台灣微軟 Windows Server 高峰會 - 認識 Windows Server 2019 超融合架構 議程講師。
(2) 擔任網管人主辦 2018 企業資安實務策略論壇 - 拒絕成為馬奇諾防線 - Windows Security Hardening議程講師。
8 月：
擔任 OpenInfra Days Taiwan 2018 - Openstack Containerization - Deploy OpenStack in Minutes議程講師。
7 月：
第 7 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。
6 月：
擔任 iThome Kubernetes Summit 2018 - OpenFaaS on Kubernetes - 1 分鐘建構好你的 Serverless 平台議程講師。
4 月：
(1) 擔任 聖約翰科技大學「雲端，人工智慧，物聯網暨大數據之生態與展望，產品行銷策略技術與管理」課程的業師，與該校 40 位老師/教授分享我在 SDDC 軟體定義資料中心的一些經驗談。(2) 擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。
5 月：
(1) 擔任 iThome Cloud Summit 2018 - 打造 VM / Container / Serverless 三位一體的軟體定義資料中心 議程講師。
(2) 擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。
(3) 擔任 國立台北商業大學 - Microsoft S2D - HCI 超融合規劃與建置實務班講師。
3 月：
(1) 與台灣微軟合作，錄製 六分鐘學會在 Azure VM 中啟用巢狀虛擬化 Nested Virtualization影片，幫助您實際操作了解如何在 Azure VM 啟用巢狀虛擬化技術。
(2) 擔任 Serverless All-Star 研討會講師。
2 月：
第 7 度當選 VMware vExpert 2018 技術專家 VMware vExpert Information - Wei-Ren Wang，在 2018 年全球共有 1,536 位 VMware vExpert (Taiwan 共 5 位獲選)。
2017 年
12 月：
(1) 擔任 國立台北商業大學 - 私有雲規劃與建置實務班 - Hyper-V 課程講師。(2) 擔任 法務部 - Windows Server Container 教育訓練課程講師。
(3) 網管人雜誌專訪 軟體定義儲存也要嚴選，東森得易購導入微軟 S2D。
(4) 擔任 Dell/Microsoft - IT 未來新能量 研討會講師。
(5) 出版人生中 第 18 本 著作 (英文翻譯書) Windows Server 容器技術。
10 月：
(1) 擔任 國立台北商業大學 - Docker 容器技術實務應用班 課程講師。9 月：
(1) 擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。(2) 擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。
(3) 擔任 DevOpsDays Taipei 2017 - 打造 Infrastructure Agility: Mode 2 的基石 - SDS 軟體定義儲存 議程講師。
8 月：
(1) 擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲規劃與建置之最佳化調校實務班課程講師。(2) 首度當選 VMware vExpert 2017 - VSAN，這是由全球 1514位 VMware vExpert 2017成員中再度選出 vExpert VSAN，2017 年全球只有 74位獲選。
(3) 出版人生中 第 17 本 著作 (個人著作) 微軟 S2D 軟體定義儲存技術實戰。
7 月：
(1) 第 6 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。(2 ) 擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲之SDS軟體定義儲存實務班 課程講師。
(3) 出版人生中 第 15、16 本 著作 (英文翻譯書) VMware vSphere 6 企業級專家手冊。
6 月：
擔任 iThome Cloud Summit 2017 - Bimodal IT 打造 SDDC 軟體定義資料中心 議程講師。4 月：
擔任 國立臺北商業大學 - 私有雲規劃與建置 Hyper-V 實務班 課程講師。3 月：
擔任 打造 Infrastructure Agility Mode 2 的基石 – Docker / Container 議程講師。2 月：
第 6 度當選 VMware vExpert 2017 技術專家，VMware vExpert Information - Wei-Ren Wang。
2016 年
11 月：
(1) 擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。(2) 擔任 中華電信學院 - VMware vSphere 建置與維護實作進階班 講師。
8 月：
(1) 擔任 資策會 - VMware vSphere ESXi 桌面虛擬化實戰課程講師。(2) 擔任 Community Open Camp活動講師。
7 月：
(1) 第 5 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。(2) 擔任 105 年度資訊應用服務人才培訓計畫 - 企業私有雲之規劃與建置 (實務班、進階班) - 以 Microsoft Hyper-V 為例 課程講師。
(3) 擔任 財團法人中興工程顧問社 VMware Horizon VDI 虛擬桌面 內部教育訓練講師。
6 月：
(1) 出版人生中 第 14 本 著作 (英文翻譯書) Hyper-V 最佳實踐：快速建置虛擬化解決方案。
(2) 擔任 聖約翰科技大學 - VMware 虛擬化技術培訓課程 講師。
4 月：
出版人生中 第 13 本 著作 (英文翻譯書) VMware vSphere 最佳化效能調校。
5 月：
擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。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 軟體定義網路
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
1 月：
與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：[Compute] Windows Server 2016 攻略 (一) - 新世代虛擬化平台 Hyper-V
[Compute] Windows Server 2016 攻略 (二) - 為雲端而生的極簡平台 Nano Server
[Compute] Windows Server 2016 攻略 (三) - 整合雲端元素的容錯移轉叢集
2015 年
11 月：
出版人生中 第 12 本 著作 (英文翻譯書) Active Directory 環境的 PowerShell 活用指南。
10 月：
(1) 與 MSDN 部落格合作翻譯 微軟正式宣布推出 PowerShell DSC for Linux Version 1.1 以及新的 Linux 資源文章。(2) 出版人生中 第 11 本 著作 (英文翻譯書) 實戰 Azure 混合雲｜基礎架構 x 高可用性 x 災難復原。
9 月：
(1) 擔任 資策會 Hyper-V 虛擬化實戰系列課程講師。(2) 於 Microsoft Techdays Taiwan 2015 舉辦期間，擔任 3場(ITM305、ECI309、ECI303) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2015。
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。
6 月：
擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2015) 講師。
5 月：
(1) 擔任 微軟 EMS 全方位企業雲端解決方案 講師。
(2) 受邀 iThome 雜誌採訪，分享 全面透視虛擬環境網路效能的瓶頸觀點。
(3) 擔任 104 年度資訊應用服務人才培訓計畫 - 企業私有雲實戰講堂 - 以 VMware 為例 課程講師。
(4) 貢獻 虛擬化環境導入評估工具 MAP、Storage Space 存放集區、 Azure RemoteApp 應用程式虛擬化 等文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。
(5) 與 TechNet 部落格合作翻譯 針對軟體定義資料中心而生的 - 新世代儲存機制 、企業級虛擬化及新世代應用程式平台 文章。
(6) 出版人生中 第 10 本 著作 (技術審校書) SDN 軟體定義網路。
4 月：
(1) 出版人生中 第 9 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 叢集雲端架構實戰 (高級篇)。
2 月：
第 4 度當選 VMware vExpert 2015，VMware vExpert Information - Wei-Ren Wang。
2014 年
12 月：
貢獻 MVMC 2.0、Windows Server 2012 R2 運作模式切換 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。11 月：
出版人生中 第 8 本 著作 (英文翻譯書) VMware Virtual SAN 管理手冊。
9 月：
於 Microsoft Techdays Taiwan 2014 舉辦期間，擔任 四場(PCIT306、DCIM309、PCIT305、DCIM402) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2014、MVA - TechDays Taiwan 2014。
8 月：
貢獻 Windows Server 2012 升級至 2012 R2 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。7 月：
(1) 出版人生中 第 7 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 虛擬化環境實戰 (初級篇)。
6 月：
(1) 擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2014) 講師。當天所有議程簡報 2014 台灣微軟 IT 管理高峰會簡報下載。
(2) 參加 Microsoft 主辦雲端戰士團，獲得 2014 年第三屆金翅級認證。
當天活動新聞訊息 自由電子報 3C科技 - 台灣微軟匯聚雲端戰士團。
5 月：
(1) 擔任 集英信誠 - 與大師對談技術論壇講師。當天所有議程簡報 與大師對談活動簡報。
當天我的議程簡報 VMware 及 Hyper-V最佳虛擬化平台硬體規劃。
(2) 受邀擔任 雙和區資訊組長研習 - HyperV 3.0 R2 新功能研討研習 講師。
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 - 王偉任。
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 新功能展示。
2 月：
貢獻 Windows Server 2012 R2 - 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。2013 年
12 月：
(1) 擔任 雙和區資訊組長研習 - Hyper-V 3.0與 VMware vSphere 5.5 虛擬化新功能比較講師。(2) 擔任 元智大學 - 雙 V 駭客，架設高可用的服務主機 (Hyper-V 上午場)、(VMware 下午場)研習活動講師。
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 桌面虛擬化及軟體雲應用研討會講師，當天議程簡報 虛擬桌面最佳化調校。
10 月：
(1) 擔任 艾鍗學院 - 職訓課程 - 網管工程師類 - 私有雲與虛擬化系統工程師養成班講師。(2) 貢獻 Microsoft Virtual Machine Converter文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。
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。
8 月：
(1) 擔任 雙和區資訊組長研習 - 虛擬化應用與基礎電腦病毒安全防護 (A場)、(B場)講師。(2) 擔任 特新光電 - Windows Server 2008 R2 教育訓練 內部教育訓練講師。
7 月：
(1) 第 2 度當選 Microsoft MVP - Virtualization Virtual Machine 項目 Microsoft MVP Profile - Wei-Ren Wang。(2) 貢獻 Windows Server 2012 MPIO 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。
6 月：
(1) 第 2 度當選 VMware vExpert 2013，VMware vExpert Information - Wei-Ren Wang。
(2) 擔任 雙和區資訊組長研習 - VMware vSphere/Microsoft Hyper-V 虛擬化技術平台之 CentOS Webmin 應用講師。
(3) 受邀採訪並刊登於 商業週刊第1334期 - 這家公司 讓微軟恨、林百里愛。
5 月：
(1) 出版人生中 第 5 本 著作 (個人著作) 24 小時不打烊的雲端服務－專家教你用 Windows Server 2012 Hyper-V3.0 實戰虛擬化技術。
(2) 擔任 2013 微軟 MVP 實戰課程日講師。
當天議程簡報Hyper-V 3.0 實戰 - 打造你的完美伺服器虛擬化平台。
當天活動簡報台灣微軟 - 研討會與活動簡報下載 - 微軟實戰課程日。
當天活動錄影台灣微軟 - 實戰課程日回顧篇。
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 - 王偉任。
3 月：
擔任 Microsoft TechNet - 邁向雲端虛擬化的全方位攻略 - Hyper-V 與 VMware 大不同課程講師。當天議程簡報Hyper-V 與 VMware 大不同。
當天議程錄影Hyper-V 與 VMware 大不同 (上)、Hyper-V 與 VMware 大不同 (下)。
1 月：
擔任 WebConf Taiwan 2013講師，當天議程簡報無廢話 DRBD + Heartbeat 實戰，當天議程錄影無廢話 DRBD + Heartbeat 實戰。WebConf Taiwan 2013 懶人包、WebConf Taiwan 2013 Day 1 - 活動照片、WebConf Taiwan 2013 Day 2 - 活動照片。
2012 年
12 月：
(1) 擔任 雙和區資訊組長研習 - Windows Server 2012 新功能技術研討講師。(2) 出版人生中 第 4 本 著作 (技術審校書) MySQL+PHP初心者的學習殿堂：資料庫×動態網頁設計實務養成(附CD)。
11 月：
(1) 擔任 板橋區資訊組長研習 - VMware vSphere ESXi 5.1 實作講師。(2) 擔任 Acer Infrastructure & Virtualization 技術會議 內部教育訓練講師。
(3) 受邀採訪並刊登於 網管人雜誌 第 81 期 資訊這條路 ─ 從無到有十年苦功 王偉任嶄露頭角。
9 月：
(1) 出版人生中 第 3 本 著作 (技術審校書) 世界連在一起，搜尋引擎的核心秘密。
(2) 受邀推薦 iThome 2012 年 iT 人必看的好書 - 系統與網路管理類。
(3) 於 Microsoft Techdays Taiwan 2012舉辦期間，在 Windows Server 2012 攤位擔任 問專家。
8 月：
(1) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server Blog - 部份文章審校。(2) 參加 Windows Server 2012 (Hyper-V 3) 好文比賽獲得 分享獎。
7 月：
(1) 當選 Microsoft MVP - Virtualization Virtual Machine項目 Microsoft MVP Profile - Wei-Ren Wang。(2) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server 2012 實戰影片審校。
6 月：
(1) 擔任 雙和區資訊組長研習 - Hyper-V Server 2008 R2 進階技術研習講師。(2) 跟 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Microsoft Technet Blog - 文章審校。
5 月：
(1) 擔任 雙和區資訊組長研習 - FreeNAS 進階技術研習講師。(2) 出版人生中 第 2 本 著作 (技術審校書) 企業級的網路安全架構：終極防駭技術大剖析。
4 月：
(1) 擔任 雙和區資訊組長研習 - CentOS HA 高可用性進階技術研習講師。(2) 成為 台灣第 1 位獲選 VMware vExpert 殊榮的人 VMware vExpert Information - Wei-Ren Wang，並受邀採訪刊登於 VMware VMTN Blog: vExpert Spotlight: Wei-Ren Wang。
3 月：
(1) 擔任 雙和區資訊組長研習 - VMware vSphere ESXi 進階技術研習講師。(2) 參加 Microsoft 所主辦的虛擬化戰士團，獲得 2012 年第一屆金翅級認證，微軟伺服器虛擬日 V-Day 虛擬化戰士頒獎典禮。
2011 年
12 月：
(1) 出版人生中 第 1 本著作 24小時不打烊的雲端服務：專家教你用 CentOS 架設萬年不掛的伺服器。感謝大家熱情支持，此著作已經登上 博客來 2012 年度排行榜 - 電腦類 TOP 50。
11 月：
(1) 擔任 慶聯有線電視 - HP/Dell/IBM 伺服器及 CentOS 作業系統基礎設定 內部教育訓練講師。(2) 受邀推薦 iThome 2011 年 IT 好書 100 - 系統與網路管理類。
2010 年
10 月：
受邀採訪並刊登於 iThome 第 480 期 iT 人甘苦談 ─ 架 Wiki 做筆記，IT 人分享學習心得。5 月：
遇見了 VMware vSphere 虛擬化技術的良師 Johnny。2007 年
3 月：
想開了!! 開始到世界各地走走，開始記錄遊山玩水的點點滴滴。2003 年
8 月：
第 2 份工作中，遇見 Clive開始接觸 FreeBSD便一腳陷入惡魔的世界 (BSD Committer TW 之一 Clive 的電腦世界回顧與展望)。4 月：
第 1 份工作時，在 Bruce 的鼓勵下考取生平第一張證照 CCNA。2002 年
11 月：
網路工程師班結訓後，第一份工作學習到有關 Cisco、3Com 網路設備...等技術 ，並且創立本站。8 月：
懷著一份對電腦世界的興趣及崇拜，因而參加網路工程師班，並認識了良師 George 及益友 Mandy、Tony...等技術同好。6 月：
憲兵退伍，連主要分割區是什麼東東也不知的人不自量力的想進入所謂的 IT 界工作。其它
- Weithenn PGP Keyid： 0xCD39063B
- Weithenn Twitter： @weithenn
- 壁紙清單： 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。
↧
網管人 168 期 - 升級 vCenter 管理平台無痛變更命名及網路組態
網管人雜誌
本文刊載於 網管人雜誌第 168 期 - 2020 年 1 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。前言
vSphere 6.7 Update3 新增特色功能
VM 虛擬主機支援多 NVIDIA vGPU
支援 AMD EPYC Gen2 處理器
Skyline 新式健康檢查機制
vSAN 6.7 Update3 新增特色功能
適用雲端原生環境的儲存資源
增強和簡化儲存資源使用資訊
更智慧的 I/O 管理機制有效提升效能
vSAN Stretched Cluster 支援 WSFC 共享磁碟
行動監控 vSAN 叢集運作資訊
實作演練 vCenter Server 變更 PNID
變更 vCenter Server FQDN 的前置作業
確認目前 vCenter Server 的 FQDN
變更 vCenter Server 的 FQDN
結語
前言
在 2019 年 8 月 13 日時，VMware 官方正式發佈全新 vSphere 6.7 Update 3版本，同時 VMware SDDC 軟體定義資料中心內，各項解決方案版本也同步推升至 Update 3 版本，例如，vSphere ESXi 6.7 Update 3 虛擬化平台、vCenter Server 6.7 Update 3 管理平台、vSAN 6.7 Update 3超融合解決方案。值得注意的是，在企業和組織的資料中心內，倘若仍採用舊有的 vSphere 6.0 版本，例如，vSphere ESXi 6.0、vCenter Server 6.0、vCenter Update Manager 6.0、vSphere Replication 6.0/6.1……等，以及對應到 vSAN 為 6.0、6.1、6.2 版本，都將於「2020 年 3 月 12 日」正式進入 EOGS 結束標準支援階段（如圖 1 所示）。
圖 1、VMware 產品生命週期表格
因此，企業和組織應儘快準備版本升級程序至 vSphere 6.5 或 6.7 版本，倘若在 2020 年 3 月 12 日進入 EOGS 結束標準支援階段時仍無法升級版本的話，則應購買「延伸支援」（Extended Support）服務，最多可以延長支援服務至「2022 年 3 月 12 日」。
在本文中，將深入剖析最新 vSphere 6.7 Update 3 和 vSAN 6.7 Update 3 版本亮眼新功能，以及實作演練 vCenter Server 6.7 Update3 新增特色功能，變更 vCenter Server FQDN 和 IP 位址網路組態設定的部份。
vSphere 6.7 Update3 新增特色功能
VM 虛擬主機支援多 NVIDIA vGPU
從最新的 vSphere 6.7 Update 3 版本開始，每台 VM 虛擬主機新增支援多個 NVIDIA vGPU（GRID virtual GPU）特色功能（如圖 2 所示），以便因應 VM 虛擬主機處理圖形和運算密集的工作負載，舉例來說，採用這種類型的 VM 虛擬主機，將能夠最大化加快機器學習的運算速度。每台 VM 虛擬主機，最多可以支援多達「四個」NVIDIA vGPU。
值得注意的是，倘若採用 vGPU 技術的 VM 虛擬主機有 vMotion 遷移需求時，管理人員必須確認 vCenter Server 和 ESXi 均採用最新 vSphere 6.7 Update 3版本之外，還必須在進階設定中加上「vgpu.hotmigrate.enabled = true」組態設定值，屆時才能順利針對採用 vGPU 技術的 VM 虛擬主機，進行 vMotion 線上遷移至別台 ESXi 虛擬化平台的動作。
圖 2、VM 虛擬主機新增支援多個 NVIDIA vGPU 特色功能示意圖
支援 AMD EPYC Gen2 處理器
從最新的 vSphere 6.7 Update 3 版本開始，支援 x86 硬體伺服器採用新式 AMD EPYC Gen2 處理器，並且在後續的 vSphere ESXi 虛擬化平台版本中，針對 AMD EPYC Gen2 處理器的新式安全性，例如，安全記憶體加密（Secure Memory Encryption，SME）、安全加密虛擬化（Secure Encrypted Virtualization，SEV）將有更全面的整合和支援。然而，目前企業和組織的資料中心內主流的 x86 硬體伺服器，大多採用 Intel Xeon 處理器，那麼管理人員該如何將原有運作於 Intel Xeon 處理器的 VM 虛擬主機，遷移至採用新式 AMD EPYC Gen2 處理器的 VMware Cluster 運作環境中呢？
或許，有 IT 管理人員會說，可以嘗試啟用 EVC（Enhanced vMotion Compatibility）機制，為 VM 虛擬主機進行遷移，但事實上為 VMware Cluster 啟用 EVC 特色功能後，僅能針對「同一家廠商」也就是僅能都是 Intel 或都是 AMD 處理器的運作環境（如圖 3 所示），並無法支援 Intel 和 AMD 處理器混合運作環境。
有關 EVC 運作機制的詳細資訊，請參考 VMware KB 1003212、VMware KB 1005764。
圖 3、Intel-Based 處理器啟用 EVC 機制後，支援遷移的處理器世代清單
事實上，我們可以透過「冷遷移」（Cold Migration）的方式（如圖 4 所示），將原本運作於 Intel Xeon 處理器的 VM 虛擬主機，遷移至新式 AMD EPYC Gen2 處理器運作環境中繼續運作，並且透過冷遷移的特性，VM 虛擬主機無須共享儲存資源，也可以將 Datastore 儲存資源進行遷移。
請注意，為 VM 虛擬主機進行冷遷移時，由於 VM 虛擬主機必須關機才能執行，所以將會造成服務發生「停機時間」(Downtime)。
下列便是採用冷遷移的執行步驟：
1. 在開始進行冷遷移執行步驟之前，請先將來源端伺服器（Intel-Based）上欲進行遷移的 VM 虛擬主機「關機」（Powered Off）。
2. 在準備執行冷遷移前，當 VM 虛擬主機採用 64 位元的作業系統版本時，vCenter Server 將會透過 CPU 相容性機制，檢查目標伺服器是否支援 64 位元作業系統版本。
3. 當遷移的 VM 虛擬主機包含儲存資源時，那麼 vCenter Server 將會把該台 VM 虛擬主機的組態設定文件、NVRAM 組態設定檔（BIOS 設定）、vDisk 虛擬磁碟……等，進行儲存資源遷移的動作。
4. vCenter Server 在目的端伺服器（AMD EPYC）中，註冊 VM 虛擬主機並執行「開機」（Powered On）的動作。
5. 當冷遷移步驟執行完畢後，vCenter Server 將會把來源端伺服器中的舊版本 VM 虛擬主機，執行刪除的動作。
圖 4、採用冷遷移執行步驟示意圖
圖片來源： HPE Technical White Paper - Migrate virtual machines from Intel- to AMD-based server platforms
Skyline 新式健康檢查機制
在過去的版本中，管理人員透過 vSphere Health 和 vSAN Helath 健康檢查機制，除了能夠快速了解叢集的健康情況之外，在叢集發生問題時也能夠透過健康檢查機制快速進行故障排除作業。在後續的版本中，原有的 vSphere Health 和 vSAN Helath 健康檢查機制，將會併入新式的 Skyline 健康檢查機制中，並且推出更進階的 Skyline Advisor 健康檢查機制，以便支援更多的 VMware 產品，例如，NSX-V 網路虛擬化、Horizon 虛擬桌面……等運作環境。如圖 5 表格所示，將簡要說明原有的 vSphere Health 和 vSAN Helath，以及新式的 Skyline 健康檢查機制在功能性方面有何不同：
圖 5、vSphere Health、vSAN Helath、Skyline Advisor 健康檢查機制功能比較表
可惜的是，由於新式 Skyline Health 健康檢查機制仍處於技術預覽階段（如圖 6 所示），所以在目前最新的 vSphere 6.7 Update3 和 vSAN 6.7 Update3 版本中仍尚未整合，VMware 官方預計在下一個版本中才會提供整合。
圖 6、新式 Skyline Health 健康檢查機制操作示意圖
vSAN 6.7 Update 3 新增特色功能
在過去的 vSAN 超融合環境中，針對 VM 虛擬主機的工作負載和儲存資源的部份，已經透過「儲存原則」（Storage Policy）的方式，輕鬆幫助 IT 管理人員進行高可用和靈活管理。適用雲端原生環境的儲存資源
針對新興的「容器」（Container）工作負載的部份，在新版 vSAN 6.7 Update3 運作環境中，已經透過 vSphere CSI（Container Storage Interface）驅動程式（如圖 7 所示），與 Kubernetes 容器管理平台整合，讓管理人員在管理容器的儲存資源時，就像過去管理 VM 虛擬主機的儲存資源一樣方便。
圖 7、vSphere CSI（Container Storage Interface）運作架構示意圖
因此，即使在 vSAN 超融合基礎架構環境中，同時運作 VM 虛擬主機和容器的混合型工作負載，在管理儲存資源方面，針對容器使用的「持續性磁碟區」（Persistent Volumes）的部份，管理人員仍然可以透過熟悉的 vSphere HTML5 Client 管理介面（如圖 8 所示），為容器提供持續性的可用儲存資源，不會因為容器短暫的生命週期，而影響到重要資料的儲存。
圖 8、透過 vSphere HTML5 Client 管理介面提供容器持續性可用儲存資源
增強和簡化儲存資源使用資訊
在過去的 vSAN 超融合運作環境中，針對儲存資源使用率資訊的部份都是以 VM 虛擬主機為主軸，然而企業和組織新興的應用方式已經改變，除了 VM 虛擬主機之外還會搭配容器等工作負載。因此，vSAN 針對儲存資源使用率的呈現方式進行增強（如圖 9 所示），例如，透過不同顏色的方式，讓管理人員更容易進行識別，並針對不同工作負載和用途的使用量進行呈現，以便管理人員更容易掌握儲存資源的使用情況和剩餘空間。舉例來說，倘若管理人員忽略剩餘儲存空間，造成「磁碟群組」（Disk Group）儲存空間佔滿，則 vSAN 將會暫停重新同步作業，以避免 VM 虛擬主機發生 I/O 中斷的情況。因此，管理人員應隨時注意儲存空間使用情況，並視需求考量是否增加 vSAN 節點主機至 vSAN 叢集中。
圖 9、增強後的 vSAN 儲存資源使用率統計圖表
更智慧的 I/O 管理機制有效提升效能
在新版 vSAN 6.7 Update3 版本中，針對資料 I/O 管理機制採用更智慧的運作方式，能夠在同樣的 vSAN 超融合基礎架構中提供更佳的儲存效能，舉例來說，當 vSAN 從快取層級的寫入緩衝區中，將資量寫入至容量層級時，提供能夠預測的應用程式效能，除了降低資料寫入的延遲時間之外，還增加資料吞吐量以便減少重建工作任務的時間，進而為 VM 虛擬主機和容器等工作負載提供更佳的儲存效能（如圖 10 所示）。
圖 10、更智慧的資料 I/O 管理機制運作示意圖
vSAN Stretched Cluster 支援 WSFC 共享磁碟
在過去的 vSAN 版本中已經透過 iSCSI 運作機制，提供 VM 虛擬主機快速建立「Windows 容錯移轉叢集運作」（Windows Server Failover Clustering，WSFC）環境，在新版 vSAN 6.7 Update3 版本中，更支援 SCSI-3 PR（Persistent Reservations）機制，達到應用程式無須中斷，即可動態調整 iSCSI LUN 儲存空間大小的增強功能。除了更全面支援 WSFC 容錯移轉叢集運作環境之外，對於其它無共享儲存資源的叢集架構，例如，Exchange CCR（Cluster Continuous Replication）、DAG（Database Availability Group）也都已經支援。
有關支援 WSFC、CCR、DAG 的詳細資訊，請參考 VMware KB 2147661知識庫文章內容。
此外，在新版 vSAN 6.7 Update3 版本中，vSAN Stretched Clusters 延伸叢集運作架構，也已經全面支援 WSFC 容錯移轉叢集運作環境（如圖 11 所示）。因此，企業和組織可以透過原有的 vSphere HA 和 DRS 機制，達成 Host Level 和 VM Level 的高可用性服務，搭配 vSAN Stretched Clusters 延伸叢集和 WSFC 容錯移轉叢集機制，達成 Application Level 的高可用性服務，讓企業和組織正式營運服務的 SLA 提升至另一個層級。
圖 11、vSAN Stretched Clusters 延伸叢集支援 WSFC 容錯移轉叢集示意圖
行動監控 vSAN 叢集運作資訊
在過去的 vSAN 版本中，當管理人員需要查看 vSAN 超融合基礎架構運作資訊時，必須透過桌上型電腦或筆記型電腦，連結至 vSphere HTML5 Client 管理介面，才能夠查看 vSAN 運作資源。然而，在行動商務的風潮中，如此傳統的管理方式已經漸漸顯得不合時宜，所以 VMware 官方推出「vSAN Live Mobile Client App」應用程式，讓管理人員能夠透過智慧型手機隨時隨地，輕鬆且快速的查看 vSAN 運作環境資訊，包括，vSAN 叢集、健康情況、運作效能、儲存空間使用率……等。
目前的 vSAN Live Mobile Client App 為 1.0 版本，管理人員的智慧型手機必須先確保能夠以 VPN 的方式存取 vSAN 叢集，並且在安裝好 App 應用程式連接至 vCenter Server 後，將下載和安裝連線憑證至智慧型手機內即可。此外，VMware 官方將會在後續 App 版本中，提供無須使用 VPN 的安全性連接方式。
VMware 官方同時提供，適用於 Apple iOS和 Google Android的 vSAN Live Mobile Client App 應用程式。
當管理人員為智慧型手機安裝整 vSAN 行動 App 應用程式後，只要 VPN 安全連線建立完成，並通過 vCenter Server 身份驗證程序後，即可順利連接至 vSAN 叢集查看相關運作資訊，包含 Info、Health、Performance、Capacity等四大項目（如圖 12 所示），讓管理人員方便透過行動裝置隨時查看 vSAN 叢集運作資訊。
圖 12、透過 vSAN Live Mobile Client App 應用程式查看 vSAN 叢集運作資訊
實作演練 vCenter Server 變更 PNID
近來管理人員對於 vCenter Server 特別需要的功能，便是 vCenter Server 能夠「變更」FQDN（Full Qualified Domain Name）和 IP 位址，這並非指的是 vCenter Server 的 VM 虛擬主機名稱，而是 vCenter Server 當中的「PNID（Primary Network ID）」名稱，在最新的 vCenter Server 6.7 Update3 版本中，已經正式支援此特色功能。為何管理人員會需要重新命名 vCenter Server 的 FQDN 呢？ 主要原因在於，每當升級 vCenter Server 版本，或者是從 Windows vCenter Server 遷移至 Linux vCenter Server Appliance 時，由於舊版的 vCenter Server 並不支援重新命名 vCenter Server 的 FQDN，所以只能延用舊有的 FQDN 或主機名稱，因此便會造成 vCenter Server 命名標準不符合公司政策的情況，同時也會造成名稱識別度上的困難。
變更 vCenter Server FQDN 的前置作業
在開始執行變更 vCenter Server FQDN 的動作之前，我們先確認運作環境符合要求。首先，必須採用最新的 vCenter Server 6.7 Update 3版本，才能夠支援變更 FQDN 也就是 PNID 的動作，同時必須擁有 SSO 網域管理者帳號和密碼，例如，Administrator@vsphere.local，並且應考慮下列事項：- 目前變更 vCenter Server FQDN 機制，僅支援採用「Embedded」運作模式的 vCenter Server。
- 在變更 vCenter Server FQDN 以前，請先執行 SSO 網域中所有的 vCenter Server 的備份作業，以避免變更過程發生不可預期的錯誤時，能夠透過備份進行還原作業。
- 在變更 vCenter Server FQDN 以前，必須在 vCenter Server 中先取消註冊其它產品，待 vCenter Server FQDN 變更完成後，再重新進行產品註冊的動作。
- 在變更 vCenter Server FQDN 以前，先將 vCenter HA 運作機制摧毀，待 vCenter Server FQDN 變更完成後，再重新組態設定和啟動 vCenter HA 高可用性機制。
- 採用舊有 vCenter Server FQDN 產生的 SSL 憑證，待 vCenter Server FQDN 變更完成後，必須搭配新的 FQDN 重新產生新的 SSL 憑證。
- 倘若有採用 Hybrid Linked Mode 機制時，待 vCenter Server FQDN 變更完成後，Cloud vCenter Server 必須重新建立 Hybrid Linked Mode 機制。
- 當 vCenter Server FQDN 變更完成後，vCenter Server 必須重新加入 Active Directory。
- 確認新的 vCenter Server FQDN，具備正確的 DNS 正向解析和反向解析記錄。
確認目前 vCenter Server 的 FQDN
變更 vCenter Server FQDN 前置作業準備完成後，首先請連結至 vCenter Server 的 VAMI（Virtual Appliance Management Interface）管理介面，在本文實作環境中 URL 為「https://vcsa67.weithenn.org:5480」，並以 vCenter Server 管理者帳號「root」和密碼登入。請確保登入 vCenter Server VAMI 管理介面（Port 5480），而非 vSphere HTML 5 Client 管理介面（Port 443），進行 vCenter Server FQDN 變更作業。
通過身份驗證程序登入 vCenter Server VAMI 管理介面後，首先請點選「Time」項目，確認目前 vCenter Server 時區設定，與 Active Directory、DNS 伺服器、ESXi 虛擬化平台採用同一個時間，本文實作環境採用的時區為「Asia/Taipei」，接著點選「Summary」項目，即可看到目前 vCenter Server FQDN 名稱為「vcsa67.weithenn.org」（如圖 13 所示）。
圖 13、確認目前 vCenter Server FQDN 名稱
變更 vCenter Server 的 FQDN
接著，確認 vCenter Server 指向的 DNS 伺服器，已經能夠正確解析新的 vCenter Server FQDN 之後，本文實作環境為「vcsa67u3.weithenn.org」之後，請在 vCenter Server VAMI 管理介面中，依序點選「Networking > Edit」項目。請確保新的 vCenter Server FQDN，在 DNS 正向解析（DNS 記錄對應 IP 位址）和反向解析（IP 位址對應 DNS 記錄）均能正確運作。
在彈出的 Edit Network Settings 精靈互動視窗中，首先 Select Network Adapter 頁面中，倘若 vCenter Server 有配置多張網路卡時，請確認選擇至「NIC 0（Management Network）」項目的網路卡，確認後按 Next 鈕繼續。
在 Edit Settings 頁面中，請在 Hostname and DNS 欄位中，填入新的 vCenter Server FQDN 名稱，本文實作環境為「vcsa67u3.weithenn.org」（如圖 14 所示），由於新的 vCenter Server FQDN 名稱同時搭配新的 vCenter Server 管理 IP 位址，在本文實作環境中 DNS 伺服器正向解析，已經新增對應的 IP 位址為「10.10.75.25」，因此請展開 NIC 0 項目選擇「Obtain Ipv4 settings automatically」項目即可，確認後按 Next 鈕繼續。
圖 14、填入新的 vCenter Server FQDN 名稱
在 SSO Credentials 頁面中，請填入 vCenter Server 管理平台中 SSO 管理憑證，本文實作環境管理者帳號為「Administrator@weithenn.org」（如圖 15 所示），確認後按 Next 鈕繼續。
請注意，這裡填入的是登入 vSphere HTML5 Client 管理介面的 SSO 管理憑證，而非登入 vCenter Server VAMI 管理介面的「root」管理者帳號。
圖 15、填入 vCenter Server 管理平台中 SSO 管理憑證
在 Ready to complete 頁面中，請再次檢視新的 vCenter Server FQDN 名稱是否正確，並勾選「I acknowledge」項目和檢視 Next Steps 項目內容，確認無誤後按下 Finish 鈕，便正式執行變更 vCenter Server FQDN 的動作。
系統將會開始執行「Network update in progress」程序，首先將會停止 vCenter Server 相關管理服務，然後執行 vCenter Server 網路組態設定的變更作業，包括新的 FQDN 和 IP 位址等網路組態設定，當所有變更作業完成後重新啟動相關管理服務。
此時，系統將會提醒倒數 10 秒後，自動重新導向至新的 vCenter Server VAMI 管理介面，本文實作環境為「https://vcsa67u3.weithenn.org:5480」，請使用 vCenter Server 管理者帳號「root」和密碼登入後，點選 Summary 和 Networking 項目（如圖 16 所示），確認新的 vCenter Server FQDN 和 IP 位址已經套用生效。至此，變更 vCenter Server FQDN 作業順利完成。
圖 16、確認新的 vCenter Server FQDN 和 IP 位址已經套用生效
結語
透過本文的深入剖析後，幫助讀者快速了解新版 vSphere 6.7 Update3 和 vSAN 6.7 Update3 亮眼特色功能，並且實作演練 vCenter Server Update3 新功能，也就是變更 vCenter Server FQDN 和 IP 位址，以便因應企業和組織升級版本或更換 vCenter Server 平台時，變更名稱和網路組態設定的需求。↧
VMware 即將更改 CPU 授權模式
前言
在 2020 年 2 月 3 日時，VMware 官方公佈即將變更的 CPU 授權模式，簡單來說，為了因應新的 AMD EYPC 這種多 Cores 運算核心，日後每顆 CPU 處理器「超過 32 核心」時，便需要「多買 1 個 CPU 授權」，這個新的 CPU 授權模式將在 2020 年 4 月 2 日起生效，而企業和組織可以在 2020 年 4 月 30 日前購買並部署的話，仍然可以享受到單一 CPU 處理器無限制運算核心數量。新的 CPU 授權模式
簡單來說，從 2020 年 4 月 30 日之後購買的 CPU 處理器授權，只要超過 32 核心便需要加買 CPU 處理器授權。舉例一
- 一台 1 U 伺服器配置 1 顆 CPU 處理器 (具備 28運算核心)，新的 CPU 授權模式仍只要購買 1 顆 CPU 處理器授權。
- 一台 1 U 伺服器配置 1 顆 CPU 處理器 (具備 64運算核心)，新的 CPU 授權模式必須購買總共 2 顆 CPU 處理器授權。
舉例二
- 一台 2 U 伺服器配置 2 顆 CPU 處理器 (每顆 CPU 處理器具備 32運算核心)，新的 CPU 授權模式同樣購買 2 顆 CPU 處理器授權即可。
- 一台 2 U 伺服器配置 2 顆 CPU 處理器 (每顆 CPU 處理器具備 64運算核心)，新的 CPU 授權模式必須購買總共 4 顆 CPU 處理器授權。
圖、新的 CPU 處理器授權購買示意圖
↧
S2D - Hyperscale for Hyperconverged
前言
很可惜，今年因故微軟取消 Microsoft Ignite The Tour - Taipei活動，原本已經準備好跟大家分享的「S2D (Storage Spaces Direct) - 超大型規模 HCI 超融合架構」議程，只好在部落格中與大家分享，有機會再詳細跟大家分享實作細節。下列是原本預計在今年Microsoft Ignite The Tour - Taipei 活動中，站長要與大家分享的四個技術議程：(後續，再找機會跟大家分享了 😁)
- Azure Security Fundamentals
- Azure Identity Fundamentals
- Storage Spaces Direct - Hyperscale for Hyperconverged
- ASDK (Azure Stack Development Kit) on Azure
Cluster Set
簡單來說，透過 Cluster Set 機制，可以將多個容錯移轉叢集把運算/儲存/網路等硬體資源融合在一起，建構出一個採用「統一儲存命名空間」(Unified Storage Namespace)的超大型融合式容錯移轉叢集。那麼採用 Cluster Set 有什麼好處？ 舉例來說，倘若有兩個不同儲存資源的 S2D HCI 超融合容錯移轉叢集，其中一個 HCI 叢集採用 Hybrid(SSD+HDD)儲存資源，另一個 HCI 叢集採用 All-Flash(NVMe+SSD) 儲存資源，那麼便可以將正式營運環境或需要大量儲存資源的 VM 虛擬主機，運作在 All-Flash 儲存資源的 HCI 叢集上，而第二線營運服務或測試用途的 VM 虛擬主機，則運作在 Hybrid 儲存資源的 HCI 叢集即可。
圖、Cluster Set 運作架構示意圖
實戰 Cluster Set
在本文實戰環境中，有三個容錯移轉叢集，分別是管理叢集「MGMT-Cluster」，以及兩個成員叢集「MBR-Cluster01、MBR-Cluster02」，其中成員叢集採用 S2D 超融合建構，並且每個成員叢集中有兩台叢集節點主機。
建立兩個 Fault Domain 並加入 Availability Set 當中。
註冊兩台 VM 虛擬主機至 Cluster Set 當中，可以看到部署的兩台 VM 虛擬主機處於不同的容錯網域和更新網域中。
執行「跨」S2D 成員叢集線上遷移 VM 虛擬主機。
最後，千言萬語不如看個二分鐘的實作展示影片吧。👻
參考資料
↧
↧
葡萄牙之旅 - 啟程
啟程
今年的地球村之旅，前往 葡萄牙 (Portugal)進行滿滿 13 天的深度之旅，波多古城、萊羅書店、科英布拉大學、巴塔哈修道院、佩納宮、貝倫塔、里斯本……我來了。 😍葡萄牙 (Portugal)，這個 Portugal 源自於拉丁語的 Portus Cale，意思為「加里人的港口」，加里人是當時定居於杜羅河的古代部族，在公元前 140 年左右，羅馬人征服葡萄牙時便將杜羅河河口地區所命名，之後被西哥特人和蘇維匯人所征服時，這個河口地區「Portus Cale」命名逐漸演變為「Portucale」，在 9 世紀時，Portucale 這個地區名稱擴大為杜羅河和米紐河流域之間的地區。最後，從 11 世紀開始，「Portugal」的用法固定下來至今。
旅程
「旅行」對於我來說，是一個能夠讓我 眼界開闊、心境轉換、釋放負能量、補充正能量……等。同時，我的旅行習慣是跟團，因為我喜歡有人在陌生的國度，可以預先幫我打點好旅途中的 吃 / 住 / 行，而我只需要盡情放鬆好好享受這個難得的假期，同時聽著導遊/領隊說明這個國家的人文、歷史、地理、特色……等即可。👻其實，不管你是跟團或者自助行甚至不用出國也行，重點是找到專屬於你自己能夠放鬆再出發方式就好，對吧!! 😁
此次的行程，我們選擇參加 晴天旅遊 － 葡萄牙－璞華藍瓷、品釀饗宴 行程。整趟行程下來，很幸運能夠由專業且認真負責的 晴天玩家領隊 Brian，讓整個南歐葡萄牙 13 天深度之旅留下難忘的回憶 (領隊/導遊，對於每次旅遊的品質及回憶影響真的非常大!)。下列，為此次南歐葡萄牙 13 天深度之旅的旅程地圖及相關參考連結：
圖片來源： 晴天旅遊 － 葡萄牙－璞華藍瓷、品釀饗宴
葡萄牙之旅
- (本文) 葡萄牙之旅 - 啟程
- 葡萄牙之旅 - Day01 - 台灣 / 荷蘭 / 葡萄牙
- 葡萄牙之旅 - Day02 - 波多 / 聖本篤車站 / 萊羅書店 / 證券交易所宮
- 葡萄牙之旅 - Day03 - 基馬拉什 / 山上仁慈耶穌朝聖所
- 葡萄牙之旅 - Day04 - 阿維羅 / 科英布拉大學
- 葡萄牙之旅 - Day05 - 巴塔哈修道院 / 法蒂瑪聖母朝聖地
- 葡萄牙之旅 - Day06 - 奧比都斯 / 洛可岬
- 葡萄牙之旅 - Day07 - 辛特拉 / 佩納宮 / 雷加萊拉莊園
- 葡萄牙之旅 - Day08 - 里斯本大耶穌像 / 艾芙拉羅馬神廟 / 人骨禮拜堂
- 葡萄牙之旅 - Day09 - 熱羅尼莫斯修道院 / 貝倫塔 / 發現者紀念碑 / 法朵音樂
- 葡萄牙之旅 - Day10 - 里斯本懷舊電車 / 阿法瑪區 / 聖露西亞瞭望台
- 葡萄牙之旅 - Day11 - 葡萄牙 / 荷蘭 / 台灣
↧
網管人 169 期 - 建立 Bastion 堡壘主機管理 Azure 雲端更安心
網管人雜誌
本文刊載於 網管人雜誌第 169 期 - 2020 年 2 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。前言
實戰 – Azure Bastion 安全性機制
建立 Bastion 堡壘主機
連線至 Windows 虛擬主機
連線至 Linux 虛擬主機
VM 虛擬主機工作階段已過期？
監控和管理 Bastion 安全連線工作階段
查看 Bastion 診斷日誌資訊
結語
前言
過去，當企業和組織在 Azure 公有雲環境中，採用 IaaS（Infrastructure as a Service）解決方案的 VM 虛擬主機時（如圖 1 所示），IT 管理人員將可以完全獲得 VM 虛擬主機作業系統層級以上的掌控權，以便滿足企業和組織對於營運服務的客製化環境運作需求，例如，客製化組態設定 IIS 網頁伺服器、SQL Server 資料庫伺服器。
圖 1、採用 Azure 公有雲 IaaS 基礎架構即服務中的 VM 虛擬主機解決方案示意圖
然而，當企業或組織在地端資料中心內，並未與 Azure 公有雲建立 S2S（Site-to-Site）VPN 安全性通道，或是採用 Express Route 專線連接解決方案，將公司地端資料中心網路環境和 Azure 公有雲虛擬網路環境連接時，就必須為 Azure 公有雲上的 VM 虛擬主機指派「公用 IP 位址」（Public IP Address），並且開啟遠端管理連接埠號，才能夠進行 VM 虛擬主機的遠端連線管理工作任務。
舉例來說，採用 Windows 虛擬主機時便需要開啟 RDP（Port 3389），而採用 Linux 虛擬主機時便需要開啟 SSH（Port 22），以便管理人員能夠透過網際網路的公用 IP 位址，遠端連線進行管理 VM 虛擬主機的工作任務。但是，一旦為 VM 虛擬主機指派採用公用 IP 位址時，便會讓 VM 虛擬主機直接曝露在充滿安全性威脅的網際網路上（如圖 2 所示），無謂的增加安全性風險。
圖 2、為 VM 虛擬主機指派公用 IP 位址，將會讓 VM 虛擬主機曝露在充滿安全性威脅的網際網路上
當然，管理人員可以採用 NSG 網路安全性群組機制（如圖 3 所示），針對管理流量的來源 IP 位址和來源連接埠，以及前往的目的地 IP 位址和目的地連接埠，和採用的通訊協定進行存取管控，並且搭配 JIT（Just-In-Time）安全性機制，有效降低因為 VM 虛擬主機曝露在網際網路上而遭受攻擊的風險。
圖 3、Azure NSG 網路安全性群組運作架構示意圖
此外，有些管理人員，為了能夠在方便管理和有效隔離之間達到平衡，便會索性自己建立一台 VM 虛擬主機擔任跳板機的工作任務，也就是為擔任跳板機的 VM 虛擬主機指派公用 IP 位址，而其它台 VM 虛擬主機則僅採用私有 IP 位址，達到與網際網路隔離的效果，然後在後續的管理作業中先連線至此台跳板機 VM 虛擬主機，然後再透過這台跳板機遠端連線至其它 VM 虛擬主機進行管理作業。
事實上，這樣的作法雖然能夠讓其它 VM 虛擬主機，不致於直接曝露在充滿安全威脅的網際網路上，達到一定程度的安全性效果，然而管理人員必須要完全確保這台跳板機的安全性，因為這台跳板機上除了可以連線至其它 VM 虛擬主機之外，可能也存放許多連線主機的機敏資訊，所以一旦這台跳板機被惡意使用者攻陷之後，那麼受影響的將會是這台跳板機曾經連線過的所有 VM 虛擬主機。
因此，由上述情況可知雖然有許多各種不同的因應作法，可以降低 VM 虛擬主機遭受網際網路攻擊的安全性風險，然而卻會大大的增加管理人員在維運管理上的負擔。
現在，管理人員可以透過部署 Azure Bastion 堡壘主機後（如圖 4 所示），同樣無須為 VM 虛擬主機指派公用 IP 位址，達到無須曝露在網際網路上而遭受攻擊的風險，並且在管理人員主機與 Bastion 堡壘主機之間，將會建立 SSL 安全性連線後，再採用 RDP 和 SSH 與 VM 虛擬主機進行連線管理作業，同時在管理人員主機中無須安裝額外的管理用戶端程式，而 VM 虛擬主機也無須安裝任何代理程式。
或許，有些管理人員已經意識到，Bastion 堡壘主機的運作架構跟剛才提到的跳板機非常類似，那麼 Bastion 堡壘主機和傳統 IT 管理人員規劃的跳板機有何不同？ 首先，由於 Bastion 堡壘主機並非 IaaS 服務而是 PaaS 服務，所以管理人員無須擔心 Bastion 堡壘主機底層作業系統的安全性，因為 Azure 會隨時更新和維持 Bastion 堡壘主機的最新穩定狀態。
此外，因為 Bastion 堡壘主機是透過私有 IP 位址連線至 VM 虛擬主機，所以管理人員可以無須設定 NSG 網路安全性群組，倘若管理人員仍希望進一步提升安全性時，可以在 NSG 網路安全性群組的防護規則中，允許僅針對 Bastion 堡壘主機的虛擬網路開啟 RDP 和 SSH 通訊協定即可。
圖 4、Azure Bastion 安全性機制運作架構示意圖
實戰 – Azure Bastion 安全性機制
在本文中，我們將帶領讀者一步一步實戰建立 Azure Bastion 安全性機制。首先，我們在 Azure 公有雲環境中的「日本東部」Azure 資料中心內，分別建立一台 Windows 和 Linux 虛擬主機，但是在建立 VM 虛擬主機的過程中（如圖 5 所示），除了未指派任何公用 IP 位址之外，在 NSG 網路安全性群組的部份也未開啟遠端連線管理通訊埠，例如，RDP 的 Port 3389 和 SSH 的 Port 22，並且地端的資料中心也未與 Azure 公有雲環境，建立 S2S（Site-to-Site）VPN 或 Express Route 等安全性通道。因此，在這樣的運作環境中，管理人員並沒有任何方法可以連線到這二台 VM 虛擬主機。
圖 5、建立 VM 虛擬主機時，未指派公用 IP 位址和開啟遠端連線管理通訊埠
建立 Bastion 堡壘主機
在開始部署 Bastion 堡壘主機之前，管理人員必須了解在 Azure 公有雲環境中，部署 Bastion 堡壘主機時，將會採用「虛擬網路」（Virtual Network）為單位，與屆時所要連接管理的 VM 虛擬主機的虛擬網路進行連線，而非採用訂閱帳戶或是 VM 虛擬主機為單位。因此，在本文實作環境中的日本東部資料中心內，我們在虛擬網路環境中建立二個虛擬網路，分別是規劃給 VM 虛擬主機使用的「10.0.1.0/24」虛擬網路，以及規劃給 Bastion 堡壘主機使用的「10.0.2.0/24」虛擬網路（如圖 6 所示）。
圖 6、規劃給 VM 虛擬主機和 Bastion 堡壘主機使用的虛擬網路
由於，我們已經在日本東部資料中心建立 Windows 和 Linux 虛擬主機，所以只要登入 Azure 入口網站，並且點選其中一台 VM 虛擬主機後，依序點選「Connect > Bastion > Use Bastion」選項（如圖 7 所示），即可在現有運作環境中部署 Bastion 堡壘主機，並且系統會自動將組態設定對應至目前採用的 VM 虛擬主機和虛擬網路。
請注意，目前 Bastion 堡壘主機僅支援部署在六個 Azure 資料中心，分別是美國西部、美國東部、美國中南部、西歐、澳洲東部、日本東部。
圖 7、準備在現有運作環境中部署 Bastion 堡壘主機
在部署 Bastion 堡壘主機畫面中，管理人員只要填入下列五項資訊即可進行部署作業：
- 名稱： 部署的 Bastion 堡壘主機名稱，本文實作環境為「Bastion-for-JapanEast」。
- 虛擬網路名稱： 部署 Bastion 堡壘主機採用的虛擬網路名稱，至少要採用的子網路遮罩必須為「/27」或更大的子網路，同時不包含任何 NSG 網路安全性群組、路由表和委派。本文實作環境為「AzureBastionSubnet」。
- 公用 IP 位址： 指派給 Bastion 堡壘主機採用的公用 IP 位址，屆時便是透過這個指派的公用 IP 位址和管理人員的主機，建立 SSL（Port 443）安全性通道後以 RDP 和 SSH 遠端連線管理 VM 虛擬主機。值得注意的是，這個公用 IP 位址必須與所要防禦的資源處於相同的 Azure 資料中心內。本文實作環境為選擇「Create new」，指派一個新的公用 IP 位址給即將部署的 Bastion 堡壘主機使用。
- 資源群組： 指定部署 Bastion 堡壘主機所要採用的資源群組。本文實作環境為選擇「RG-JapanEast」，採用與 Bastion 堡壘主機所要防禦的資源同一個資源群組。
請注意，部署 Bastion 堡壘主機的虛擬網路名稱，必須以「AzureBastionSubnet」命名，才能夠讓 Azure 服務正確理解，要將 Bastion 堡壘主機部署和防禦哪個虛擬網路。
當部署 Bastion 堡壘主機完成後，管理人員便可以享受到下列管理好處：
- HTML 5 瀏覽器進行管理作業： 管理人員只要透過現代化的 HTML 5 瀏覽器（例如，Microsoft Edge 或 Google Chrome），登入至 Azure 入口網站後，即可直接在瀏覽器中開啟 RDP 和 SSH 工作階段，連線至 VM 虛擬主機進行管理作業。
- SSL 安全通道遠端工作階段： 當管理人員透過 HTML 5 瀏覽器 Web 用戶端，與 VM 虛擬主機建立 RDP 和 SSH 工作階段後，系統將會自動與管理人員的主機透過 SSL（Port 443）建立安全通道，因此管理人員無須為此管理作業在地端資料中心，額外開啟防火牆放行規則。
- VM 虛擬主機無須公用 IP 和代理程式： 由於，管理人員只要透過 Bastion 堡壘主機，即可連線至 Azure 公有雲環境中的 VM 虛擬主機，所以無須再為 VM 虛擬主機指派公用 IP 位址，並且也無須安裝任何代理程式即可進行管理。此外，由於 VM 虛擬主機無須指派公用 IP 位址，所以能有效避免 VM 虛擬主機曝露在網際網路上，遭受外部惡意使用者進行連接埠掃描攻擊。
- 避免遭受零時差攻擊： 由於 Bastion 堡壘主機為 PaaS 服務，因此 Azure 平台會隨時強化和維持 Bastion 堡壘主機在最新穩定狀態，並且它位於 VM 虛擬主機中虛擬網路的前端周邊網路，所以當零時差攻擊出現時，管理人員無須擔心必須馬上針對每台 VM 虛擬主機進行強化保護，有效避免遭受零時差攻擊。
連線至 Windows 虛擬主機
當 Bastion 堡壘主機部署作業完成後，管理人員即可在 Azure 入口網站中，點選要透過 Bastion 堡壘主機連線管理的 Windows 虛擬主機後，在 Bastion 頁籤中鍵入遠端連線管理的使用者帳號和密碼後（如圖 8 所示），按下 Connect 鈕即可進行連線管理作業。管理人員必須具備 VM 虛擬主機和 Bastion 堡壘主機資源的「讀取者角色」（Reader Role），才能順利透過 Bastion 堡壘主機連線管理 VM 虛擬主機。
圖 8、準備透過 Bastion 堡壘主機連線管理 Windows 虛擬主機
由於，在剛才的連線管理畫面中，預設情況下已經自動勾選「Open in new windows」項目，所以瀏覽器將會在新的頁面中開啟連線工作階段，並且採用 Microsoft IT TLS CA 1所簽發的 SSL 憑證，與管理人員主機建立 SSL 安全性通道，然後再透過 RDP（Port 3389）連線至 Windows 虛擬主機（如圖 9 所示）。
圖 9、順利透過 Bastion 堡壘主機，RDP 遠端連線管理 Windows 虛擬主機
有時，管理人員在管理 Windows 虛擬主機的過程中，可能需要鍵入大量的管理指令，此時透過 Bastion 堡壘主機的遠端工作階段中，管理人員可以按下畫面最左邊中間位置的箭頭圖示，即可展開剪貼簿，將管理人員主機上已經複製的管理指令內容貼至剪貼簿中，一旦貼入剪貼簿後便會自動傳送至 VM 虛擬主機的剪貼簿中（如圖 10 所示）。相反的，倘若需要從 VM 虛擬主機複製相關指令或文字，回到管理人員主機上時，一旦 VM 虛擬主機執行複製指令或文字的動作後，相關的指令或文字便會出現在箭頭圖示內的剪貼簿方框中。
請注意，透過 Bastion 堡壘主機 RDP 連線至 Windows 虛擬主機後，目前僅支援「文字」複製貼上功能，尚未支援「檔案傳輸」功能，微軟已經預計後續將會擴充相關功能。
圖 10、使用 Bastion 堡壘主機提供的剪貼簿功能
連線至 Linux 虛擬主機
同樣的，管理人員在 Azure 入口網站中，只要點選欲透過 Bastion 堡壘主機連線管理的 Linux 虛擬主機後，在 Bastion 頁籤中鍵入遠端連線管理的使用者帳號和密碼後（如圖 11 所示），按下 Connect 鈕即可進行連線管理作業。
圖 11、準備透過 Bastion 堡壘主機連線管理 Linux 虛擬主機
由於，在連線管理畫面中預設已經勾選「Open in new windows」項目，所以瀏覽器將會在新的頁面中開啟，並且採用 Microsoft IT TLS CA 1 所簽發的 SSL 憑證，與管理人員主機建立 SSL 安全性通道後，再透過 SSH（Port 22）連線至 Linux 虛擬主機（如圖 12 所示）。
圖 12、順利透過 Bastion 堡壘主機，SSH 遠端連線管理 Linux 虛擬主機
VM 虛擬主機工作階段已過期？
請注意，當管理人員欲採用 Bastion 堡壘主機安全性機制，遠端連線管理受保護的 VM 虛擬主機時，必須先登入 Azure 入口網站，然後透過 Azure 入口網站啟動 Bastion 堡壘主機安全連線機制，才能順利建立 SSL 安全性通道遠端連線管理 VM 虛擬主機。倘若，管理人員直接在另一個瀏覽器中，嘗試採用相同的 URL 開啟遠端連線工作階段時，便會發生工作階段已經過期的錯誤訊息，並且系統會提示必須先登入 Azure 入口網站，才能啟用 Bastion 堡壘主機安全連線機制（如圖 13 所示）。
圖 13、必須先登入 Azure 入口網站，才能啟用 Bastion 堡壘主機安全連線機制
監控和管理 Bastion 安全連線工作階段
由於連線至 VM 虛擬主機的工作階段，都是透過 Bastion 堡壘主機發起的安全性連線，所以管理人員可以切換至 Bastion 堡壘主機中，查詢遠端連線 VM 虛擬主機工作階段的資訊，包括使用者連線時間、連接的 VM 虛擬主機名稱、遠端連線管理的使用者帳號、遠端連線通訊協定……等資訊。當然，管理人員可以隨時管理 Bastion 堡壘主機上的 VM 虛擬主機工作階段，倘若管理人員希望強制中斷連線中的 VM 虛擬主機工作階段時，只要在 Bastion 堡壘主機工作階段頁面中，點選欲中斷連線的 VM 虛擬主機工作階段，然後選擇「Delete」項目即可（如圖 14 所示），而使用者將會在 VM 虛擬主機工作階段頁面中，看到「Disconnected」中斷連線的訊息。
圖 14、管理 Bastion 堡壘主機上的 VM 虛擬主機工作階段
查看 Bastion 診斷日誌資訊
除了透過 Bastion 堡壘主機管理 VM 虛擬主機工作階段外，也可以為 Bastion 堡壘主機啟用診斷日誌功能，以便記錄和診斷 VM 虛擬主機工作階段的詳細資訊，幫助管理人員在連線 VM 虛擬主機發生問題時進行故障排除。請切換至 Bastion 堡壘主機管理頁面中，點選「Diagnostics settings > Add diagnostic setting」項目，填入 Bastion 堡壘主機診斷日誌的名稱以及採用的 Azure 儲存體帳戶（如圖 15 所示），即可為 Bastion 堡壘主機啟用診斷日誌功能。
圖 15、啟用 Bastion 堡壘主機診斷日誌功能
當 Bastion 堡壘主機診斷日誌建立完成後，管理人員即可隨時切換至建立時所指定的 Azure 儲存體帳戶中，點選「Blob service > Containers」項目，即可看到 VM 虛擬主機的啟動診斷日誌，以及剛才建立的 Bastion 堡壘主機診斷日誌（如圖 16 所示），管理人員便可以依照「年 / 月 / 日 / 小時 / 分鐘」查詢診斷日誌內容，進行 VM 虛擬主機的故障排除作業。
圖 16、查詢 VM 虛擬主機的啟動診斷日誌和 Bastion 堡壘主機診斷日誌
結語
透過本文的深入剖析和實戰演練後，讀者應該已經了解 Azure Bastion 堡壘主機的功能和優點，它能夠有效幫助中小企業降低營運管理成本，讓原本編制就不多的 IT 管理人員，可以無須費心建立 Site-to-Site VPN 安全性通道，或是採用昂貴的 Express Route 專線費用，也無須為了方便管理而指派公用 IP 位址給 VM 虛擬主機，埋下遭受網際網路惡意使用者攻擊的風險。同時，微軟官方也已經預告 Azure Bastion 堡壘主機的未來功能藍圖，包括與 Azure Active Directory 整合，達成 SSO 使用者單一帳號登入和多因素身份驗證，以及加入遠端連線管理的錄影功能，方便管理者審核連線以及使用者操作行為。
↧
葡萄牙之旅 - Day01 - 台灣 / 荷蘭 / 葡萄牙
台灣 > 阿姆斯特丹史基浦機場
由於，此次葡萄牙 13 天的深度之旅，沒有從台灣直飛至葡萄牙的班機，所以我們第一段航程必須先從台灣長途飛行 13 小時 20 分之後，來到荷蘭的「阿姆斯特丹史基浦機場」 (Amsterdam Airport Schiphol)，然後再專機至葡萄牙第二大城波多機場。
這次旅程搭乘的是荷蘭皇家航空 (KLM)，最有趣的是在旅程的後半段，會拿出他們最經典的「荷航代爾夫特藍陶小屋」讓你選擇 (有選擇障礙的人真的很難決定啊! 😅)，這個荷航代爾夫特藍陶小屋，除了每一間小屋模型都是模擬真正的荷蘭建築之外，在每個代爾夫特藍陶小屋內都會裝有荷蘭杜松子酒 (也就是琴酒)。
阿姆斯特丹史基浦機場是荷蘭首都阿姆斯特丹的主要機場，也是整個荷蘭國門主要的進出門戶。先前在查詢阿姆斯特丹史基浦機場時，意外發現機場有提供優惠卷，也就是當你在阿姆斯特丹史基浦機場內商店購買 香水/化妝品/太陽鏡/酒/巧克力……等，消費金額達到 25 歐元，在結帳時出示這個優惠卷即可享有 5 歐元的折扣，雖然可能用不上索性也填一下資料，稍後就會在 E-Mail 中收到折扣卷了。
阿姆斯特丹史基浦機場 > 葡萄牙-波多機場
從阿姆斯特丹史基浦機場再飛行 2 小時 35 分來到葡萄牙-波多機場，經過總飛行時間 15 小時 55 分鐘後，我們終於來到葡萄牙第二大城「波多機場」(Porto Airport)，這個機場又有個別名「費爾南多·薩·卡內羅機場」(Aeroporto Francisco Sá Carneiro)。事實上，現在波多機場的名稱是紀念一位葡萄牙總理，因為他在乘機前往此機場時失事遇難所命名。
波多歷史中心 (Historic Centre of Oporto)
「波多」 (Porto)，葡萄牙語的意思為「溫暖的海港」，波多位處於葡萄牙北部並且是面向大西洋的一個海港城市，波多為葡萄牙的第一大港口和第二大城市 (第一大城市為首都里斯本)。下列為前往波多古城時，杜羅河在陽光的照射下閃閃發光，天公作美感覺真好。事實上，在公元四世紀時波多就已經有人居住，並且在公元五世紀開始建城，可惜的是在公元七世紀時因為遭受外來勢力入侵導致逐漸沒落，在公元十二世紀時，葡萄牙王國的萊昂王國宣佈獨立之後，波多便是葡萄牙的中心發展地區，同時波多也逐漸成為現在大家所看到的樣貌，整個城市分為上層的文化區和下層的商業區。從公元十四世紀開始，由於大航海時代的熱潮開始讓波多成為造船港口，並且在波多杜羅河谷所生產的葡萄酒開始銷往世界各地並聞名於世 (現在，整個波多的舊城區和周邊產酒區皆為世界文化遺產)。在西元 1703 年時，葡萄牙與英國簽訂條約開始建立貿易關係，更讓波多成為整個葡萄牙西北部重要經濟中心。下列是波多歷史中心在 1996 年入選為 UNESCO 世界文化遺產時的評價：
波爾圖市沿山勢而建，可以眺望杜羅河入海口，此地舉世無雙的城市景觀已有千年曆史。波爾圖的發展與海洋息息相關（羅馬人把它叫做伯特斯，即港口），城中眾多 各式各樣的古蹟都向我們說明了這一點，無論是帶有羅馬風格唱詩班席的大教堂，還是新古典主義的證券交易所，以及典型的葡萄牙紐曼爾式聖克拉拉教堂。
由於抵達波多古城的時間已經中午，用過午餐後領隊貼心的讓我們先回到飯店放下行李 (是的，我們住宿的飯店就在波多古城內)，就在走回飯店的途中，突然看到「葡式蛋塔店」，當然先買個二顆蛋塔 (一顆 1 歐元) 來認識一下再說。😁
杜羅河遊船
「杜羅河」(Douro)，源頭來自於西班牙索里亞省由東向西流經過葡萄牙波多，整個杜羅河長約 897 公里，最後在波多以南 3 公里處再注入大西洋。來到波多最簡單且快速了解波多古城的方式，便是搭乘杜羅河的仿古遊船，這也是今天的第一個行程，我們搭乘仿古遊船延著杜羅河飽覽整個波多沿岸，同時欣賞沿岸上高低交錯的彩色房屋，並且在遊船的過程中還會經過知名的「路易一世鐵橋」(葡萄牙語：Ponte Dom Luís I)，這個路易一世鐵橋是由當時師承巴黎鐵塔設計師艾菲爾的徒弟的得意之作，路易一世鐵橋串聯著波多古城和舊城區與加亞酒莊區，並且鐵橋的設計非常有趣，在鐵橋上層為輕軌和人行步道使用，鐵橋下層則是車輛行駛使用。
搭乘仿古遊船活動結束，在杜羅河岸加亞酒莊區上岸準備前往酒莊，在捕抓杜羅河畔的美景時，剛好看到個人蠻喜歡的一位旅遊專家眭澔平，看起來他似乎剛好也在深入遊覽波多古城中 (身邊只站著另一位當地導遊)，很親切的獲得他的同意後跟他合照並且握手致意，為這趟波多古城巡禮增加意外的驚喜。
波多酒 (Vinho do Porto)
葡萄牙在杜羅河畔丘陵與河谷種植葡萄，釀製出品質卓越的波多酒，並且深受世界各國的青睞和喜愛。因此，在杜羅河左岸可以看見一整列的酒莊展售區，當然這次的行程中也安排來到一家酒莊進行導覽，聽聽波多酒的製造歷史最後試喝波多酒 (可惜的是我不喝酒，頂多就沾一下體驗波多酒的歷史 😎)。
波多纜車 (The Gaia Cable Car)
波多古城中的波多纜車位於杜羅河的左岸，從 2011 年 4 月正式開始運作和營運，波多纜車連接杜羅河岸加亞酒莊區與路易一世鐵橋，搭上波多纜車可以從制高點緩緩經過底下波多酒莊區，並且看到酒莊區眾多房子的紅色屋頂非常壯觀，搭乘波多纜車到整個波多古城的制高點時，除了欣賞「皮拉爾修道院」(Mosteiro da Serra do Pilar) 之外，還可以同時俯瞰整個路易一世鐵橋與杜羅河右岸，我們登上制高點的時間剛好是黃昏時分，整個杜羅河畔顯示出高低層次顏色多彩非常的美麗。
葡式海鮮粥
今天晚餐是葡式海鮮粥，為今天波多古城巡禮劃下一個美麗的句點。用完晚餐準備步行回飯店時，看到杜羅河、
葡萄牙之旅
- 葡萄牙之旅 - 啟程
- (本文) 葡萄牙之旅 - Day01 - 台灣 / 荷蘭 / 葡萄牙
- 葡萄牙之旅 - Day02 - 波多 / 聖本篤車站 / 萊羅書店 / 證券交易所宮
- 葡萄牙之旅 - Day03 - 基馬拉什 / 山上仁慈耶穌朝聖所
- 葡萄牙之旅 - Day04 - 阿維羅 / 科英布拉大學
- 葡萄牙之旅 - Day05 - 巴塔哈修道院 / 法蒂瑪聖母朝聖地
- 葡萄牙之旅 - Day06 - 奧比都斯 / 洛可岬
- 葡萄牙之旅 - Day07 - 辛特拉 / 佩納宮 / 雷加萊拉莊園
- 葡萄牙之旅 - Day08 - 里斯本大耶穌像 / 艾芙拉羅馬神廟 / 人骨禮拜堂
- 葡萄牙之旅 - Day09 - 熱羅尼莫斯修道院 / 貝倫塔 / 發現者紀念碑 / 法朵音樂
- 葡萄牙之旅 - Day10 - 里斯本懷舊電車 / 阿法瑪區 / 聖露西亞瞭望台
- 葡萄牙之旅 - Day11 - 葡萄牙 / 荷蘭 / 台灣
↧