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

網管人 207 期 - 第二版視窗子系統 Linux，二刀流無縫順暢運行

April 24, 2023, 3:54 am
$
0
0


網管人雜誌

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





本文目錄






前言

過去，在 Windows 主機上要能夠運作 Linux 作業系統時，管理人員可以透過 Dualboot 機制，在同一台硬體主機中，將 Linux 作業系統安裝在另一個開機磁碟區中，達到使用同一台硬體但運作 Linux 作業系統的目的，或者在 Windows 主機上啟用 Hyper-V 虛擬化技術，建立 VM 虛擬主機然後安裝 Linux 作業系統，又或者在 Windows 主機上安裝 VMware Player 或 VirtualBox 等，客戶端虛擬化軟體，然後再建立 VM 虛擬主機並安裝 Linux 作業系統。很顯然的，這幾種方式，對於不熟悉系統運作架構的管理人員來說並不方便，並且會花費一定程度的手動管理時間。

因此，微軟著手打造並推出「Windows 子系統 Linux」（Windows Subsystem for Linucx，WSL）。簡單來說，管理人員可以在 Windows 系統中，無須進行複雜的修改和組態設定，直接透過底層的 Windows 核心提供資源和主要設定，並且在 Microsoft Build 2019 大會上展示，這就是第一代的 WSL 1（如圖 1 所示）。

圖 1、WSL 1 運作架構示意圖
圖片來源： The new Windows subsystem for Linux architecture: a deep dive - BRK3068

新版的 WSL 2 運作架構，則是從原有的底層 Windows 核心管理和提供資源，改為整合 Hyper-V 虛擬化技術，但管理人員無須管理傳統 Hyper-V VM 虛擬主機，例如，vNetwork 虛擬網路、vSwitch 虛擬交換器……等組態設定，即可輕鬆建立和運作 Linux 執行個體（如圖 2 所示）。

圖 2、WSL 2 運作架構示意圖
圖片來源： The new Windows subsystem for Linux architecture: a deep dive - BRK3068

值得注意的是，原有的 WSL 1 和 WSL 2 運作環境，主要支援運作在 Windows 10 和 Windows 11 客戶端作業系統中，在 2022 年 5 月時， 微軟官方正式發佈最新的 WSL 2 運作環境，正式支援運作在最新 Windows Server 2022 雲端作業系統中。





新版 WSL 2 特色功能

簡單來說，新版的 WSL 2 運作架構，除了底層由原本的 Windows 核心主導，改為整合 Hyper-V 虛擬化之外，最大的重點在於能夠於 Windows 系統中執行 ELF64 Linux 二進位檔，達到增加 Linux 檔案系統效能，以及完整的系統呼叫相容性，同時管理人員能夠組態設定，運作的 Linux 執行個體要啟動在舊有的 WSL 1 環境，或是新版的 WSL 2 運作環境，達到相同的使用者操作體驗。

傳統的 Hyper-V 虛擬化架構下，倘若未良好規劃底層網路架構和儲存資源時，建立的 VM 虛擬主機可能發生運作緩慢，並且耗用大量資源的情況，並且還需要管理人員手動管理，而使用 WSL 2 運作環境則無須擔心這些情況及管理成本。

因此，雖然 WSL 2 運作架構是使用 VM 虛擬主機，但採用的是由微軟客製化過後的輕量型 VM 虛擬主機，所以除了提供 WSL 1 運作架構的優點，例如，無縫整合 Windows 和 Linux 異質作業系統、開機時間極短、更低的資源使用量、無須管理和設定 VM 虛擬主機……等。所以，WSL 2 架構雖然使用 VM 虛擬主機，但是由系統在幕後自動進行管理及執行，讓管理人員擁有跟 WSL 1 相同的操作體驗。

在 WSL 2 運作架構中的 Linux 核心來源，是由微軟在 kernel.org 取得的最新穩定分支所建立的，然後針對 WSL 2 架構進行微調和效能最佳化，以便在 Windows 主機上提供最佳的 Linux 操作體驗。此外，這個微調和最佳化後的 Linux 核心，將會由 Windows Update 提供後續的更新服務，所以管理人員無須手動進行管理，便能自動獲得最新的安全性修正程式和 Linux 核心改良功能。

此外，在 WSL 2 運作架構中的 Linux 執行個體，相較於 WSL 1 具備更佳的檔案 IO 效能，舉例來說，管理人員在執行相關操作，例如，git clone、npm install、apt upgrade……等動作時，相較於舊版的 WSL 1 來說大約可以提升「2 ~ 5 倍」的效能，而在解壓縮 tarball 時執行速度更可高達「20 倍」之多（如圖 3 所示）。

圖 3、WSL 2 運作架構和 Linux 執行個體檔案交換示意圖
圖片來源： The new Windows subsystem for Linux architecture: a deep dive - BRK3068



WSL 1 vs WSL 2

預設情況下，系統將會採用最新的 WSL 2 運作環境，來執行管理人員所需的 Linux 執行個體，主因在於 WSL 2 運作架構，執行的 Linux 執行個體將會採用「受控 VM 虛擬主機」（Managed VM）架構，支援完整的 Linux 核心，以及完整的系統呼叫相容性，所以在跨 Linux 和 Windows 作業系統時的運作效能更佳（如圖 4 所示）。

圖 4、WSL 1 和 WSL 2 特色功能支援比較表
圖片來源： 比較 WSL 版本 | Microsoft Learn





實戰 – WSL 2 on Windows Server 2022

在 Windows 10 和 Windows 11 客戶端作業系統中，管理人員可以很輕鬆的透過 Microsoft Store 商店，直接安裝 最新版本的 WSL 1.0，並且未來也無須再擔心版本更新的問題，因為後續 Microsoft Store 應用程式，一旦發現 WSL 發佈更新版本時，便會自動安裝 WSL 更新版本。

在本實戰演練小節中，則是於最新 Windows Server 2022 雲端作業系統中，安裝最新發佈版本的 WSL。值得注意的是，在部署 WSL 運作環境之前，必須確保運作 Windows Server 2022 的主機，在伺服器硬體底層已經啟用硬體輔助虛擬化技術，並確保主機支援安裝和運作 Hyper-V 虛擬化技術，並且確認已經安裝 KB5014021 安全性更新。
簡單來說，Windows Server 2022 主機，至少要安裝 2022 年 5 月或之後的整合安全性更新即可。


部署 WSL 運作環境

在本文實作環境中，已經在伺服器底層啟用硬體輔助虛擬化技術，並且為 Windows Server 2022（21H2）主機，安裝最新安全性更新後 Build number 為「20348.1487」。

確保 Windows Server 2022 雲端作業系統中，已經符合上述運作條件後，即可在 PowerShell 或命令提示字元中，鍵入「wsl --install」指令後，系統便會自動執行相關動作，例如，啟用必要的 WSL 和虛擬主機選擇性元件、下載並安裝最新的 Linux 核心、將 WSL 2 組態設定為預設值、安裝預設的 Ubuntu Linux 發行版本……等，當所有的下載和安裝啟用動作執行完畢後，系統提示必須重新啟動主機，確保套用所有變更（如圖 5 所示）。

圖 5、為 Windows Server 2022 主機安裝 WSL 運作環境

此外，管理人員倘若希望在 Windows Server 2019 主機中安裝 WSL 運作環境，則必須確認為 1709 或後續版本，並在 PowerShell 視窗中執行「Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux」 指令，並重新啟動主機後，執行下載和安裝 Linux 發行版本的動作即可。
倘若，安裝過程中發生 0x8007007e 錯誤訊息時，則表示該系統版本不支援 WSL 運作環境，請確認 Build number 為 16215 或後續版本。


組態設定 Linux 管理員帳號和密碼

重新啟動主機後，在預設情況下，登入 Windows 系統後便會自動下載和執行 Ubuntu Linux 執行個體，當系統成功啟動 WSL 運作環境，並啟動 Ubuntu Linux 執行個體後，第一個動作便是要求管理人員為這個 Ubuntu Linux 執行個體，組態設定登入的管理者帳號及密碼，鍵入管理者帳號及二次確認密碼後，便順利登入 Ubuntu Linux 作業系統（如圖 6 所示）。

圖 6、組態設定 Ubuntu Linux 作業系統管理者帳號及密碼

值得注意的是，這個 Ubuntu Linux 作業系統管理者帳號及密碼，並不會影響 Windows 系統中原有的使用者帳號，所以也無須和 Windows 系統採用相同的管理帳號及密碼。此外，這個鍵入的管理者帳號，將會直接視為 Linux 系統管理員帳號，所以能夠執行「sudo」指令，成為 Linux 作業系統中的超級使用者。
後續新增或重新安裝 Linux 發行版本時，都必須為「每個」Linux 發行版本組態設定管理帳號和密碼。

一般情況下，進入 Linux 發行版本環境後，倘若需要變更使用者密碼，只要鍵入「passwd」指令即可進行密碼變更作業。

然而，在 WSL 運作環境中，管理人員可能會開啟和運作多個不同的 Linux 發行版本環境，並且管理人員必須為每一個運作的 Linux 發行版本，組態設定管理員帳號和密碼，因此就有可能發生忘記密碼的情況。此時，只要在 PowerShell 視窗中，執行「wsl -u root」 指令，接著執行「passwd <使用者帳號>」，即可修改預設 Ubuntu Linux 發行版本中，使用者帳號為 Weithenn 的密碼（如圖 7 所示），倘若要修改密碼的環境並非預設 Ubuntu Linux 執行個體時，則加上「-d <發行版本名稱>」，例如，「wsl -d CentOS -u root」即可。

圖 7、重新設定預設 Ubuntu Linux 執行個體中管理員 Weithenn 帳號的密碼



管理及更新 WSL 版本

確認 WSL 環境運作正常後，管理人員可以透過幾個簡單的指令，查詢管理並更新 WSL 運作環境。首先，在 PowerShell 指令視窗中執行「wsl --version」指令，即可查詢目前運作的 WSL 和相關元件版本，在本文實作環境中採用最新的 WSL 1.0.3.0 安裝版本，執行「wsl --status」指令，查詢預設採用的 Linux 發行版本和 WSL 版本，執行「wsl --update」 指令，預設將會至 Microsoft Store 網站，確認是否有更新的 WSL 版本，管理人員也可以加上「--web-download」參數，改為從 GitHub 網站確認是否有更新的 WSL 版本（如圖 8 所示）。
請注意  !這裡的 WSL 1.0.3.0 安裝版本，請勿和 WSL 1 及 WSL 2 運作環境版本搞混。
圖 8、查詢 WSL 版本並檢查更新

從剛才的查詢結果得知，運作的 WSL 環境預設採用較新的「WSL 2」 版本，倘若管理人員希望調整預設執行的 WSL 版本，請執行「wsl --set-default-version <WSL 版本號碼>」指令，即可組態設定預設的 WSL 版本。

倘若，管理人員希望指定個別 Linux 執行個體，所採用的 WSL 版本時，請執行「wsl --set-version <Linux 發行版本名稱> <WSL 版本號碼>」指令，即可為個別的 Linux 執行個體，指定採用的 WSL 運作環境版本。



安裝和運作其它 Linux 發行版本

預設情況下，系統已經在 WSL 運作環境中，安裝和運作 Ubuntu Linux 執行個體。事實上，WSL 運作環境預設已經支援許多 Linux 發行版本，管理人員只要執行「wsl --list --online」指令，即可查詢目前內建支援哪些 Linux 發行版本，例如，Debian、SUSE Linux、Oracle Linux……等，執行「wsl --list --verbose」指令，查詢目前 WSL 運作環境中安裝和運作哪些 Linux 執行個體（如圖 9 所示）。

圖 9、查詢 WSL 環境內建支援哪些 Linux 發行版本和目前運作的 Linux 執行個體

確認 Linux 發行版本的名稱後，管理人員只要執行「wsl --install <Linux 發行版本名稱>」，例如，「wsl --install SLES-12」指令，系統便會立即執行下載安裝和啟動 SUSE Linux Enterprise Server 的動作，倘若管理人員不希望在安裝 SUSE Linux 發行版本後，自動啟動 SUSE Linux 運作環境的話，可以加上「--no-launch」參數即可。同樣的，先前提到每當安裝新的 Linux 發行版本時，也需要為這個 Linux 發行版本，組態設定管理員帳號和密碼，組態設定完成後便順利登入系統（如圖 10 所示）。

圖 10、新增並運作 SUSE Linux 發行版本至 WSL 運作環境中

目前的 WSL 運作環境中，預設執行的 Linux 執行個體為 Ubuntu，倘若管理人員希望將其它的 Linux 發行版本，組態設定為 WSL 運作環境的預設值時，只要執行「wsl --set-default <Linux 發行版本名稱>」指令即可，例如，本文實作環境中，將剛才安裝好的 SUSE Linux 發行版本，透過「wsl --set-default SLES-12」指令，組態設定為 WSL 運作環境的預設值（如圖 11 所示）。

圖 11、組態設定 SUSE Linux 發行版本為 WSL 運作環境的預設值



透過 Windows Terminal 同時操作

在目前的情況下，可以透過個別的 Linux 發行版本 Shell 指令視窗，進行組態設定和操作管理。然而，這樣的操作方式缺點在於，一旦有多個Linux 發行版本需要同時操作時，管理人員便需要不停切換不同的 Linux 發行版本 Shell 指令視窗，那麼 Windows 有沒有內建的工具可以方便的處理此問題 ？

管理人員可以採用，微軟官方建議的 Windows Terminal 工具，來使用和管理 WSL 運作環境。首先，在 Windows Server 2022 主機中，採用內建的 Edge 瀏覽器，連結至 GitHub - Microsoft/Terminal頁面，選擇下載最後穩定版本，本文實作環境為「Windows Termianl v1.16.1026」版本，或執行 PowerShell 的「Invoke-WebRequest –Uri <下載網址>」指令進行下載。

下載 MSIX 安裝套件完成後，在 PowerShell 指令視窗中，執行「Add-AppxPackage –Path <MSIX 安裝套件路徑>」指令後，會發生「0x80073CF3」錯誤訊息，系統提示必須要安裝 C++ Runtime Framework for Desktop Bridge（Microsoft.VCLibs.140.00.UWPDesktop）套件才行，下載完成後先安裝 C++ Runtime Framework 套件，即可順利安裝 Windows Terminal，安裝完成後無須重新啟動主機，即可在開始選單中發現新增的 Windows Terminal（如圖 12 所示）。

圖 12、為 Windows Server 2022 主機安裝 Windows Terminal

預設情況下，當系統順利啟用 WSL 運作環境後，便會自動在 Windows Terminal 中產生關聯，在本文實作環境中，已經在 WSL 運作環境中啟動 3 個不同的 Linux 執行個體，所以在 Windows Terminal 視窗中，點選向下圖示時，便能夠看到 3 個不同的 Linux 執行個體可供開啟，或是使用組合鍵快速開啟（如圖 13 所示）。

圖 13、透過 Windows Terminal 同時開啟 WSL 環境中多個 Linux 執行個體

除了可以在同一個視窗中，開啟多個 Linux 發行版本頁籤之外，Windows Terminal 也支援在同一個畫面中分割窗格操作，舉例來說，管理人員可以先開啟 Windows Terminal 的 PowerShell 視窗，然後再開啟 WSL 環境的 Ubuntu Linux 發行版本時，按住「Alt」鍵進行開啟，系統便會自動在原有視窗中分割窗格，並且登入至 WSL 環境的 Ubuntu 作業系統中，同樣的操作再開啟 SUSE Linux 和 Oracle Linux 後，便在同一個視窗中可以快速在不同的分割窗格中，操作不同的 Linux 作業系統環境（如圖 14 所示）。

圖 14、同一個視窗中不同的分割窗格操作不同的 Linux 作業系統環境



匯入其它 Linux 發行版本

雖然，預設的 WSL 運作環境，已經內建支援多套 Linux 發行版本，但是管理人員習慣的 Linux 發行版本可能未包含在內。此時，便可以透過取得 Linux 發行版本的二進位 tar 檔案，執行匯入 WSL 運作環境的動作，後續便可以在 WSL 運作環境中，啟動剛才匯入的 Linux 發行版本。

首先，當 Linux 發行版本有提供二進位 tar 檔案時，只要下載後執行匯入 WSL 運作環境的動作即可，舉例來說，在 Alpine Linux 發行版本官網當中，管理人員可以直接下載「Mini Root Filesystem」 中的檔案即可使用，在本文實作環境中，下載 Mini Root Filesystem 類別下的「x86_64」 項目的 tar.gz 檔案。

將 tar.gz 檔案解壓縮後，得到「alpine-minirootfs-3.17.1-x86_64.tar」 檔案，開啟 PowerShell 指令視窗，鍵入「wsl –import <Linux 發行版本名稱 > <Linux 作業系統磁碟存放路徑> <Tar 檔路徑>」，在本文實作環境中為「wsl --import Alpine C:\tmp\Alpine\ .\alpine-minirootfs-3.17.1-x86_64.tar」，指定將屆時的 Alpine Linux 發行版本磁碟，存放於「C:\tmp\Alpine」 資料夾內。

匯入動作執行完成後，切換到剛才指定存放 Alpine Linux 磁碟的資料夾中，可以發現系統已經自動建立名為「ext4.vhdx」 檔案，這就是在 WSL 運作環境中，Alpine Linux 作業系統 vDisk 虛擬磁碟，採用 .vhdx 副檔名的檔案，表示這是 Hyper-V 虛擬化平台的 vDisk 虛擬磁碟檔案類型。

鍵入「wsl --list --verbose」指令，即可發現已經順利將 Alpine Linux 發行版本，匯入至 WSL 運作環境中，但是目前為「Stopped」未啟動狀態，只要執行「wsl --distribution Alpine」指令，便立即啟動 Alpine Linux 作業系統並登入其中，再次鍵入「wsl --list --verbose」指令，可以發現 Alpine Linux 發行版本為「Running」運作中的狀態（如圖 15 所示）。

圖 15、匯入 Alpine Linux 發行版本至 WSL 運作環境並啟動它



存取 Windows 主機資源

在預設情況下，WSL 運作環境已經自動將 Windows 主機的磁碟機，自動掛載至啟動 Linux 發行版本中的「/mnt/<drive>」下，舉例來說，Windows 主機的 C : 槽，便會自動掛載至 Linux 發行版本中的「/mnt/c」路徑。

因此，當 WSL 運作環境中的 Linux 發行版本，需要和 Windows 主機進行資料交換時，透過 WSL 內建跟檔案系統的運作機制，便能輕鬆達成資料交換的目的。

舉例來說，管理人員可以在 Windows 主機中，建立「C:\testmount」資料夾，裡面存放剛才實作匯入的 Tar 檔案，以及一個名稱為 test.txt 的文字檔案，接著切換到 Ubuntu Linux 作業系統環境中，查看「/mnt/testmount」路徑，即可看到在 Windows 主機建立和複製的檔案，同樣的在 Ubuntu Linux 作業系統中，建立一個名稱為 test02.txt 的文字檔案，切回 Windows 主機的 PowerShell 視窗中，同樣能夠看到 test02.txt 文字檔案的內容（如圖 16 所示）。

圖 16、測試 WSL 運作環境跨 Windows 和 Linux 檔案系統功能



停止並取消註冊 Linux 發行版本

預設情況下，一旦啟動 Linux 發行版本後，便會持續運作直到管理人員執行停止運作指令。舉例來說，剛才匯入並運作的 Alpine Linux 發行版本，當管理人員測試完畢希望清理它時，先執行「wsl --terminate Apline」指令，再執行「wsl --list --verbose」指令，可以發現 Alpine Linux 由原本的「Running」 運作中狀態，改變為「Stopped」停止運作狀態。

接著，鍵入「wsl --unregister Alpine」指令後，再次執行「wsl --list --verbose」指令，可以發現已經將 Alpine Linux 發行版本，從原本 WSL 運作環境清單中刪除（如圖 17 所示）。值得注意的是，這個取消註冊 Linux 發行版本的動作，將會把所有相關聯的資料、組態設定、軟體……等都移除，所以管理人員執行這個指令之前，務必確認清楚再執行。

圖 17、在 WSL 運作環境中停止並取消註冊 Alpine Linux 發行版本



一次停止所有 Linux 執行個體

在剛才小節中，管理人員可以透過「wsl --terminate」指令，針對「單一」運作中的 Linux 發行版本，執行停止運作的動作。倘若，在 WSL 運作環境中，同時運作多個 Linux 發行版本時，要逐一停止運作便顯得麻煩。

此時，管理人員可以透過「wsl --shutdown」指令，一次將 WSL 運作環境中「所有」的 Linux 執行個體全部停止（如圖 18 所示）。

圖 18、一次停止 WSL 運作環境中所有 Linux 執行個體





結語

透過本文的深入剖析和實作演練後，管理人員除了理解舊版的 WSL 1，和新版 WSL 2 的功能差異之外，在實戰演練小節中，直接在 Windows Server 2022 雲端作業系統中，安裝和運作最新整合 Hyper-V 虛擬化技術的 WSL 1.0 版本，實際運作和管理不同的 Linux 執行個體，並且和 Windows 主機進行檔案交換作業，讓企業和組織中的管理人員和開發人員，能夠透過最小成本的情況下，輕鬆打造出研發和測試環境。
↧
Search

[站長開講] Cloud Summit Taiwan 2023

May 5, 2023, 8:34 am
$
0
0


活動簡介

很多企業都聽過「在 AI 時代，數據就是新石油」之說，而且不只聽、已化為實際行動；但現今仍有不少企業，自承還未能純熟分析資料、萃取智慧。這些企業主，眼前近年世局變遷無常，自知若不趕緊利用科技賦能、強化敏捷與韌性，恐難因應接踵而來的挑戰，因而有「AI 用時方恨少」危機感。

與其自己以有限的經費、人才與時間，拼命追逐 AI／ML、大數據等技術卻始終欠缺臨門一腳，倒不如藉由雲端，開啟數位科技應用的任意門，順勢突破轉型升級的門檻和阻礙，加速淬鍊資料素養與決策智慧。

因此，iThome 誠摰邀請企業內部負責設定 IT「戰略」的高階主管，需要理解 IT「戰術」的中間幹部，或必須不斷精進 IT「戰技」的基層同仁，都能踴躍參與「2023 iThome 臺灣雲端大會」，順著本次活動的「Empowering the Future：Cloud ·AI · Data」主軸，讓人人皆獲得關鍵的啟發與成長，幫助企業鞏固未來生存與發展的基石。





活動資訊

  • 日期：   2023 年 7 月 19 日 (三)
  • 時間：   08:30 - 17:00
  • 地點：   南港展覽二館
  • 報名：   活動報名
  • 議程：   大會議程表





站長議程

在本次研討會中，站長分別有「議程」和「實戰工作坊」，所以有興趣的朋友，可以先聽完議程，接著來參加實戰工作坊，相信可以讓你在短短時間當中，除了理解  Azure Stack HCI Single-Node 運作原理和特色功能之外，還能動手實際進行操作。

在本議程中，將深入分析並實際展示，在 Microsoft Build 2022 大會中，所發佈的「Azure Stack HCI Single-Node」技術。簡單來說，透過 Azure Stack HCI 雲端作業系統，讓企業和組織只需要使用最小規模「1 台」，便能建構出 HCI 超融合叢集，達到 MVP 最小可行性產品的目標，非常用於新創或分公司環境。此外，企業和組織可以依據專案需求或營運成長，隨時擴充 HCI 超融合叢集運作規模，以便提供上層 VM 虛擬主機、容器、微服務……等內的應用程式，能夠無後顧之憂效能最大化。






站長實戰工作坊

在本實戰工作坊中，將會以 Azure 公有雲為實機操作環境，並提供與會者每人一台 Azure VM 虛擬主機啟用「巢狀式虛擬化」(Nested Virtualization) 機制，以便說明和實際展示並手把手帶領與會者，體驗在 Microsoft Build 2022 大會中，所發佈的「Azure Stack HCI Single-Node」技術。



↧
↧

小型 vSAN Cluster 如何正確關閉

May 11, 2023, 8:23 am
$
0
0


前言

在一個小型的 VMware vSAN 7 Cluster 環境中，只有 4 台 vSAN Node，並且 vCenter Server 也運作在這個 vSAN Cluster 當中。當機房需要進行電力維護作業，而必須關閉 vSAN Cluster 時該怎麼正確關閉呢？ 應該先關閉 vCenter Server 才關閉 vSAN Node 嗎？ 然而，一旦關閉 vCenter Server 的話，那麼 vSAN Node 能否正確關閉？ 但是，若直接關閉 vSAN Node 的話，而 vCenter Server 又運作於其中，該如何正確關閉呢？ 本文便是剖析和實作演練此狀況。

簡單來說，在這樣可能產生「雞生蛋，蛋生雞」的情況下，管理人員還是可以使用 vSAN 7 Update 3 的「叢集感知智慧啟動和關閉工作流」（Intelligent Cluster Aware Shutdown and Start-up Workflows）機制。詳細資訊請參考站內文章：
vSAN 叢集感知智慧工作流運作機制示意圖
圖片來源： vSAN 7 Technology Overview – Simplified vSAN cluster shutdown and power-up





Shutdown vSAN Cluster

首先，登入 vCenter Server 後，依序點選「vSAN Cluster > Monitor > vSAN > Resyncing Objects」，確認 vSAN Cluster 並沒有需要同步資料的情況。


確認後，便可以切換至「vSAN Cluster > Configure > vSAN > Services」後，點選「Shutdown Cluster」選項。


此時，系統彈出的 Shutdown pre-check 視窗中，可以看到系統偵測到 vCenter Server 部署在 vSAN Cluster 當中，但是本環境中已經沒有其它 ESXi  可以運作 vCenter Server，並且可以按下 Next 鈕繼續。


系統告知並顯示，稍後 vSphere Client 管理介面將會顯示無法存取的情況。因為，在此情況下系統會將 vCenter Server 先關機! 你可能會感到疑惑，那麼後續是怎麼達到關閉 vSAN Cluster 呢？ 答案就是本視窗的最後一行注意事項，系統說明目前 vCenter Server 將會先關閉，並且由原本 vCenter Server 所運作的 vSAN Node 擔任「Orchestration Host」，由這台主機來協調整個 vSAN Cluster 的關閉工作任務，在本實作環境是 vSAN Node02。


接著確認真正要執行 Shutdown vSAN Cluster 的工作任務，並選擇這次關閉的理由，本文實作由於機房電力維護，所以選擇「Scheduled maintenance」項目，然後按下 SHUTDOWN鈕。


事實上，這時還可以在 vCenter Server 管理畫面中，看到短暫的 Shutdown vSAN Cluster 執行程序，稍後就會出現無法存取網頁了。


切換到 Orchestration Host 也就是本文實作環境中的 vSAN Node02 後，可以看到 vCenter Server 確實正在關閉中。


本文實作環境中，採用的是 Cisco UCS 伺服器，所以連接到 4 台 vSAN Node 的 Cisco CIMC 畫面，開啟 vKVM 進行查看，在 ESXi Console 畫面搭配「Alt + F12」，查看 VMkernel log 可以看到正準備進入維護模式和關閉作業程序。


待另外 3 台 vSAN Node 都關機完畢後，最後擔任 Orchestration Host 的 vSAN Node 02 也進入維護模式並執行關機程序。








重新啟動 vSAN Cluster

待機房電力維護作業完畢後，首先，開啟 4 台 vSAN Node，接著至擔任 Orchestration Host 的 vSAN Node 02 中，將 vCenter Server 開機，待 vCenter Server 中所有的服務啟動完畢後，登入 vCenter Server 管理介面，並依序點選「vSAN Cluster > Configure > vSAN > Services」，點選「RESTART」鈕，準備啟動 vSAN Cluster。


同樣的，系統會再次檢查是否能夠順利啟動，確認無誤後按下 「RESTART」鈕即可。


順利啟動 vSAN Cluster 後，可以看到 vSAN Services 恢復正常運作。


當然，管理人員可以透過 vSAN Skyline Health 和 Cluster Services 來確認 vSAN Cluster 的健康情況。



↧

vSAN 8 新儲存架構開工，實戰 ESA 超融合叢集 | 網管人 208 期

May 20, 2023, 4:43 am
$
0
0


網管人雜誌

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





本文目錄

          RAID-5/6 vs RAID-1
          增強壓縮機制





前言

隨著最新舉辦的 VMware Explore 2022 大會中，正式發佈最新的 vSphere 8 和 vSAN 8 版本。全新的 vSAN 8 版本最大改變，便是新增支援 vSAN ESA（Express Storage Architecture）儲存架構，而過去管理人員熟悉的 vSAN 超融合技術，則為 vSAN OSA（Original Storage Architecture）儲存架構。

新增支援的 vSAN ESA 儲存架構，僅支援高效能的 NVMe 儲存裝置，至於其它 SATA 或 SAS SSD 固態硬碟儲存裝置則不支援，在 vSAN 儲存網路部份則建議至少配置 25Gbps 傳輸速率。

或許，管理人員會有這樣的疑惑，過去的 vSAN 架構也支援採用 NVMe 儲存裝置，建構出 All-Flash 模式的 vSAN 超融合叢集，那麼新增支援的 vSAN ESA 儲存架構究竟有何不同？

簡單來說，傳統的 vSAN OSA 儲存架構，先將儲存裝置區分為「快取層」（Cache Tier）和「容量層」（Capacity Tier），並將快取層和容量層組合為「磁碟群組」（Disk Group），其中快取層僅用於資料快取和寫入使用，並無法真正納入儲存容量，而新式的 vSAN ESA 儲存架構，則採用單一儲存層級並導入「儲存集區」（Storage Pool）機制，所有 NVMe 儲存裝置容量都能使用（如圖 1 所示）。

圖 1、傳統 vSAN OSA 和新式 vSAN ESA 儲存架構比較示意圖
圖片來源： Announcing VMware vSAN 8 | VMware Virtual Blocks Blog

值得注意的是，企業和組織必須使用至少「vSAN Advanced」或更高的軟體授權版本，才能夠支援使用新式的 vSAN ESA 儲存架構，倘若僅採購 vSAN Standard 軟體授權時，雖然使用最新的 vSAN 8 版本，也僅支援建構傳統 vSAN OSA 儲存架構的超融合叢集。詳細軟體授權和功能支援資訊，請參考 VMware vSAN Licensing Guide文件。

雖然，vSAN 8 推出新式 ESA 儲存架構，但是針對傳統的 OSA 儲存架構也有所提升。在過去的 vSAN OSA 儲存架構中，每個磁碟群組的「寫入緩衝大小」（Write Buffer Size）為「600 GB」，表示每個磁碟群組中，最多僅能宣告使用 600 GB 儲存空間，所以大於此限制的快取層儲存空間便無法有效利用。

現在，最新的 vSAN 8 版本 OSA 儲存架構，將寫入緩衝大小提升至「1.6 TB」，這表示 OSA 儲存架構能夠更提升資料讀取和寫入效能，因為可以儲存的讀取快取和寫入緩衝區的資料量變多了，同時也能夠減少容量層的 I/O 需求，以及 vSAN 元件的重新同步時間（如圖 2 所示）。

圖 2、vSAN 8 OSA 儲存架構寫入緩衝大小由 600 GB 提升至 1.6 TB
圖片來源： Increased Write Buffer Capacity for the vSAN 8 Original Storage Architecture | VMware





vSAN 8 ESA 儲存架構亮眼特色功能

事實上，最新版本的 vSAN 8 ESA 儲存架構，並非僅是支援 NVMe 儲存裝置和採用儲存集區而已，而是從底層許多技術進行增加和改進，和傳統 vSAN OSA 儲存架構相較下，更能充分發揮 NVMe 儲存裝置的效能。



RAID-5/6 vs RAID-1

在傳統 vSAN OSA 儲存架構中，倘若希望節省儲存空間則採用 RAID-5/6 容錯機制，保護 VM 虛擬主機工作負載的 vSAN 元件，缺點則是儲存效能稍嫌不足，而若是希望獲得較高的儲存效能，可以採用 RAID-1 容錯機制，但缺點則是消耗較多的儲存空間，而新式 vSAN ESA 儲存架構，則是採用 RAID-5/6 容錯機制，但能提供不輸給 RAID-1 的儲存效能，充分在儲存效能和節省儲存空間之間達到最大化。

此外，同樣採用 RAID-5 容錯機制，傳統 vSAN OSA 儲存架構和新式 vSAN ESA 儲存架構，在儲存空間節省方面也所有不同。在傳統 vSAN OSA 儲存架構中，提供 3+1 的 RAID-5容錯機制，這表示保護資料的方式，是由 3 個「資料位元」（Data bits）加上 1 個「同位位元」（Parity bit）組成，所以至少必須要跨越「4 台」vSAN 叢集節點主機，才能達到資料保護的目的，並且能夠容忍單台 vSAN 叢集節點主機發生故障，儲存容量則是主要資料的「1.33 倍」，倘若 VM 虛擬主機的 VMDK 硬碟大小為 100 GB 時，則需要耗用 133GB 的 vSAN 儲存空間（如圖 3 所示）。

圖 3、傳統 vSAN OSA 儲存架構 3+1 的 RAID-5 容錯機制示意圖
圖片來源： Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8 | VMware

而新式的 vSAN ESA 儲存架構，則提供 2 種不同的 RAID-5 容錯機制，倘若 vSAN 叢集節點主機數量較少時，可以採用 FTT=1 的 2+1 RAID-5容錯機制，也就是 2 個「資料位元」（Data bits）加上 1 個「同位位元」（Parity bit）組成，只要跨越「3 台」vSAN 叢集節點主機就能達到資料保護的目的，儲存容量則是主要資料的「1.5 倍」，倘若 VM 虛擬主機的 VMDK 硬碟大小為 100 GB 時，則需要耗用 150 GB 的 vSAN 儲存空間（如圖 4 所示）。

圖 4、新式 vSAN ESA 儲存架構 FTT=1 的 2+1 RAID-5 容錯機制示意圖
圖片來源： Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8 | VMware

倘若 vSAN 叢集節點主機數量較多時，可以採用 FTT=1 的 4+1 RAID-5容錯機制，也就是 4 個「資料位元」（Data bits）加上 1 個「同位位元」（Parity bit）組成，必須跨越「5 台」vSAN 叢集節點主機才能達到資料保護的目的，儲存容量則是主要資料的「1.25 倍」，倘若 VM 虛擬主機的 VMDK 硬碟大小為 100 GB 時，則僅需要耗用 125 GB 的 vSAN 儲存空間（如圖 5 所示）。

圖 5、新式 vSAN ESA 儲存架構 FTT=1 的 4+1 RAID-5 容錯機制示意圖
圖片來源： Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8 | VMware



增強壓縮機制

在最新 vSAN 8 ESA 超融合技術中，針對資料壓縮機制重新設計並增強處理效能，在資料寫入壓縮方面，只需要針對主要資料壓縮一次即可，而非每個資料副本也要進行壓縮，此舉除了有效降低 CPU 處理器的工作負載之外，同時也降低寫入資料量和 vSAN 儲存流量，而在資料讀取方面則直接讀取壓縮狀態的資料，無須解壓縮後進行讀取，同樣減少 vSAN 叢集節點主機之間的 vSAN 儲存流量。

具體來說，新的壓縮機制將資料大小的壓縮單元縮小到 4 KB，整體壓縮比達到 8:1，和傳統 vSAN OSA 儲存架構相比提升了 4 倍（如圖 6 所示）。

圖 6、新式 vSAN 8 ESA 儲存架構壓縮機制運作示意圖
圖片來源： vSAN 8 Compression - Express Storage Architecture | VMware



智慧調整 vSAN 網路流量

在傳統的 vSAN OSA 儲存架構中，倘若 vSAN 儲存流量發生資源爭奪的情況，例如，VM 虛擬主機 I/O 工作負載，和重新同步元件的 Resync I/O 工作負載同時發生時，便很有可能因為資源爭奪的情況，造成 vSAN 儲存效能降低，甚至影響 VM 虛擬主機的工作負載。

新式的 vSAN ESA 儲存架構，新增智慧型 vSAN 網路流量調整機制，在 vSAN 儲存流量沒有發生資源爭奪時，每種類型的 vSAN 流量都可以盡可能使用網路頻寬，一旦發生資源爭奪的情況時，便會自動檢測並限制優先層級較低的 vSAN 流量。

因此，同樣發生上述的 vSAN 儲存流量發生資源爭奪時，新式的 vSAN ESA 儲存架構，將會把重新同步元件的 Resync I/O 工作負載，限制在使用網路頻寬不超過 20%，而讓優先層級較高的 VM 虛擬主機 I/O 工作負載，能夠使用 80% 的網路頻寬（如圖 7 所示）。

圖 7、新式 vSAN ESA 儲存架構智慧型 vSAN 網路流量調整機制示意圖
圖片來源： Adaptive Network Traffic Shaping with the vSAN Express Storage Architecture | VMware



B-Tree 高效能快照機制

過往的 vSAN 版本中，雖然針對 VM 虛擬主機工作負載的「快照」（Snapshot）不斷改善，例如，vSAN 5.5 版本的 VMFS 快照，以及 vSAN 6.0 的 vsanSparse 快照機制，都是為了增強和改善快照效能，然而長時間儲存的快照合併作業一直是個難解的問題（如圖 8 所示）。

圖 8、傳統 vSAN 儲存架構快照機制運作示意圖
圖片來源：Scalable，High-Performance Native Snapshots in the vSAN Express Storage Architecture | VMware

新式 vSAN ESA 儲存架構，處理快照時並非採用傳統 vDisk 虛擬硬碟的互相參照機制，而是改為採用 B-Tree 的方式處理，相較於過去傳統的快照機制，在刪除快照時間上 B-Tree 新式機制比傳統快上「100 倍」，有效改善快照處理時間（如圖 9 所示）。

圖 9、新式 vSAN ESA 儲存架構改採用 B-Tree 機制處理快照示意圖
圖片來源： Scalable，High-Performance Native Snapshots in the vSAN Express Storage Architecture | VMware





實戰演練 – vSAN 8 ESA 超融合叢集

在實戰小節中，將實作演練最新 vSAN 8 ESA 超融合儲存架構，除了採用最新 vCenter Server 8 管理平台之外，共有 3 台 vSAN 叢集節點主機，每台 vSAN 叢集節點主機，除了安裝 ESXi 虛擬化平台系統的硬碟，額外配置 4 顆 600 GB NVMe 儲存裝置。



手動建立 DataCenter 和 Cluster

在本文實作環境中，不會採用 Cluster QuickStart 自動化部署機制，而是改為採用手動操作逐一建立的方式，例如，手動建立 DataCenter、Cluster、vDS 分佈式虛擬交換器、vSAN VMkernel Port……等，以便帶領讀者能夠一步一步打造出 vSAN ESA 超融合叢集。

首先，登入 vCenter Server 8 管理平台後，建立 vSAN 8 ESA 超融合叢集使用的 DataCenter 和 Cluster，值得注意的是在建立 vSAN Cluster 時，先建立空的叢集而不要啟用任何進階特色功能，例如，vSphere DRS、vSphere HA、vSAN，等到後續運作環境完備後，再啟用這些叢集等級的進階特色功能（如圖 10 所示）。

圖 10、建立 vSAN-Cluster 但先不啟用叢集等級的進階特色功能

在管理介面中，依序點選「vCenter Server > DataCenter > vSAN-Cluster > Actions > Add Hosts」，鍵入第 1 台 vSAN 叢集節點主機的連線資訊後，按下 Add Host 鈕，然後勾選上方的「Use the same credentials for all hosts」，表示採用相同的管理者帳號及密碼，納管 3 台 vSAN 叢集節點主機，按下 Next 鈕後，系統將會自動彈出這 3 台 vSAN 叢集節點主機的 SHA1 指紋檔內容，按下 OK 鈕接受後至下一個納管步驟。

在 2. Host Summary 納管步驟中，確認 vSAN 叢集節點主機資訊無誤後按下 Next 鈕，在 3. Import Image 納管步驟中，採用預設值 Don’t import an image 選項即可，最後在 4. Review 步驟中確認無誤後，按下 Finish 鈕，即可將 3 台 vSAN 叢集節點主機，加入至 vSAN-Cluster 叢集中（如圖 11 所示）。預設情況下加入的 vSAN 叢集節點主機，將會自動進入「維護模式」（Maintenance Mode），管理人員可以將其設定為離開維護模式即可。

圖 11、將 3 台 vSAN 叢集節點主機加入至 vSAN-Cluster 納管



組態設定 vSAN VMkernel Port

在 vSAN 超融合運作架構中，每台 vSAN 叢集節點主機，必須規劃專用於 vSAN 儲存流量的 VMkernel Port，確保 vSAN 超融合叢集中每台 vSAN 叢集節點主機，都能夠透過這個專用的 vSAN 儲存流量 VMkernel Port，彼此交換和儲存相關 vSAN 元件。

點選「vSAN8-N01」，本文實作環境中規劃的第 1 台 vSAN 叢集節點主機，依序點選「Configure > Networking > VMkernel adapters > Add Networking」選項，在彈出視窗中選擇「VMkernel Network Adapter」項目後按下 Next 鈕，在 2. Select target device 頁面中，先選擇將 vSAN VMkernel Port，建立在預設現有的 vSS 標準式虛擬交換器 vSwitch0 上，稍後將會建立 vDS 分佈式虛擬交換器，並且將 vSAN VMkernel Port 遷移至 vDS Port Group 中，請選擇「Select an existing standard switch > vSwitch0」選項後，按下 Next 鈕。

在 3. Port properties 頁面中，在 Network label 欄位中填入「vSAN-VMkernel」名稱，以利後續管理上辨別用途，接著在下方 Enabled services 選項中勾選「vSAN」項目，確保啟用 vSAN 儲存流量並按下 Next 鈕（如圖 12 所示）。

圖 12、命名為 vSAN-VMkernel 並勾選 vSAN 選項確保啟用 vSAN 儲存流量

在 4. IPv4 settings 頁面中，組態設定此 vSAN VMkernel Port 的 IP 位址，本文實作採用「192.168.1.31/24」，按下 Next 鈕。在 5. Ready to complete 頁面中，檢視相關資訊確認無誤後按下 Finish 鈕即可。

接著，請採用相同的操作步驟，為 vSAN8-N02 和 vSAN8-N03 組態設定 vSAN VMkernel Port，並且指派採用「192.168.1.32、192.168.1.33」的 IP 位址（如圖 13 所示）。

圖 13、組態設定另外 2 台 vSAN 叢集節點主機的 vSAN VMkernel Port



建立 vSAN 專用 vDS 分佈式虛擬交換器

雖然，採用 vSS 標準式虛擬交換器，也能夠建構和部署 vSAN 超融合叢集，然而對於後續維運管理和組態設定的便利性則稍嫌不足，並且針對 vSAN 超融合叢集的可擴充性考量，倘若採用 vSS 標準式虛擬交換器，當後續需要加入新的 vSAN 叢集節點主機至 vSAN 超融合叢集時，將會多出許多額外的組態設定工作，浪費管理人員寶貴的時間。

因此，在建構和部署 vSAN 超融合叢集初期，便建立 vSAN 專用的 vDS 分佈式虛擬交換器為佳。請在 vCenter Server 管理介面中，依序點選「Home > Networking > vCenter Server > Datacenter > Actions > Distributed Switch > New Distributed Switch」選項，在彈出的精靈視窗中，首先於 Name 欄位鍵入「vSAN-DSwitch」後，按下 Next 鈕。

在 2. Select version 頁面中，選擇 vDS 分佈式虛擬交換器採用的版本，在本文實作環境中採用最新的「8.0.0」版本（如圖 14 所示），實務上管理人員則必須視管理的 vSphere 虛擬化環境版本選擇，舉例來說，倘若原有運作的 vSphere 叢集中，採用 7.0.2 版本並且尚未升級至新版，那麼管理人員應該為了相容性考量，同樣採用舊版的 7.0.2 版本，後續再找機會進行 vDS 版本升級作業。
管理人員想查看每個版本的特色功能概要時，可以點選 Features per version 字樣旁的 Information 圖示。
圖 14、採用最新 8.0.0 vDS 分佈式虛擬交換器版本

在 3. Configure settings 頁面中，大部份選項皆採用系統預設值即可，管理人員在 Port group name 欄位中，鍵入「vSAN-DPortGroup」名稱以利後續維運管理時進行辨別，在 4. Ready to complete 頁面中，確認相關資訊無誤後按下 Finish 鈕即可。

vDS 分佈式虛擬交換器建立完成後，便可以將 3 台 vSAN 節點主機加入，以及進行 vSAN VMkernel Port 遷移作業。請在 vCenter Server 管理介面中，依序點選「Networking > Datacenter > vSAN-DSwitch > Actions > Add and Manage Hosts」選項，在彈出的精靈視窗 1. Select task 頁面中，選擇「Add hosts」選項後按下 Next 鈕，在 2. Select hosts 頁面中，將會列出 DataCenter 中所有的 ESXi 主機，請僅勾選 3 台 vSAN 叢集節點主機即可，按下 Next 鈕。

在 3. Manage physical adapters 頁面中，本文實作中的每台 vSAN 叢集節點主機，共配置 2 張 10Gb 網路卡，其中 vmnic0 用於管理和遷移等流量，而 vmnic1 則配置為專用於 vSAN 儲存網路，所以請在 vmnic1 的 Assign uplink 下拉選單中選擇「Uplink1」，當確認選擇 vmnic1 為 Uplink1 時，則原有 In use by switch 欄位值，將從原本的 3 hosts / 0 switches 轉變為「This switch」，表示 vmnic1 實體網路卡，已經指派給 vDS 分佈式虛擬交換器使用。

在 4. Manage VMkernel adapters 頁面中，顯示每台 vSAN 叢集節點主機的 VMkernel Port，在本文實作中，每台 vSAN 叢集節點主機有 2 個 VMkernel Port，vmk0 用於管理和遷移用途，而 vmk1 則是剛才建立，專用於 vSAN 儲存流量的 VMkernel Port，管理人員可以點選 vmk1 進行再次確認，確認後點選 Destination port group 欄位中的 ASSIGN PORT GROUP 文字，系統便會跳至是否將 vmk1 指派至 vDS 分佈式虛擬交換器中的 vSAN-DPortGroup，按下 ASSIGN 確認指派，回到頁面中 vmk1 的 In use by switch 欄位值為「This switch」，而 Destination port group 欄位則是「vSAN-DPortGroup」，也就是將原本在 vSwitch0 標準式虛擬交換器中的 vSAN VMkernel Port，遷移至 vDS 分佈式虛擬交換器中的 vSAN-DPortGroup（如圖 15 所示）。

圖 15、將 vSAN VMkernel Port 從 vSS 標準式虛擬交換器遷移至 vDS 分佈式虛擬交換器

在 5. Migrate VM networking 頁面中，因為目前的 vSAN 超融合叢集中並沒有任何 VM 虛擬主機網路，所以無須遷移任何 VM 虛擬主機網路設定，請按下 Next 鈕。在 6. Ready to complete 頁面中，確認相關組態設定資訊無誤後，按下 Finish 鈕完成組態設定作業。



啟用 vSAN ESA 超融合叢集

vSAN 叢集節點主機和運作環境前置作業完成後，請在 vCenter Server 管理介面，依序點選「vSAN-Cluster > Configure > vSAN > I need a local vSAN datastore > Standard vSAN cluster > Configure」選項。

在彈出的精靈視窗 1. vSAN ESA 頁面中，首先請啟用上方的「vSAN ESA」選項，在這個程序中系統將進行二個項目的檢查作業，首先是採用的 NVMe 儲存裝置是否為 VMware certified，第二項檢查則是確認 vSAN 叢集節點主機，採用的網路卡傳輸速率，在 VMware vSAN 最佳建議作法中，專用於 vSAN 儲存網路的網路卡傳輸速率，建議至少為「25 Gbps」。

在 2. Service 頁面中，倘若 vSAN 叢集節點主機採用的網路卡，支援 RDMA 特色功能時記得勾選 RDMA support 項目。在 3. Cliam disks 頁面中，因為本文實作採用的 NVMe 儲存裝置型號，尚未取得 VMware certified，所以 vSAN ESA Compatible 相容性檢查欄位值為「Incompatible」，但是並不影響實作演練的進行，請勾選「Cliam」項目表示使用所有 vSAN 叢集節點主機中的 NVMe 儲存裝置，勾選後上方便會顯示 vSAN Capacity 7.03TB，表示 3 台 vSAN 叢集節點主機，共 12 顆 600GB NVMe 儲存裝置，皆正確無誤宣告給 vSAN 超融合叢集使用（如圖 16 所示）。
實務上，請一定要採用通過 VMware certified 的 NVMe 儲存裝置。

圖 16、成功宣告所有 NVMe 儲存裝置給 vSAN 超融合叢集使用


在 4. Create fault domains 頁面中，採用系統預設值即可。在 5. Review 頁面中，確認相關組態設定資訊無誤後，按下 Finish 鈕完成組態設定作業。

管理人員可以從下方 Recent Tasks 工作列中，看到系統建構 vSAN 超融合叢集的工作流程，其中 Reconfigure vSAN cluster 項目是整個建構進度百分比，中間會有許多組態設定程序，例如，Reconfigure cluster 和 Update vSAN configuration，最後則是將每台 vSAN 叢集節點主機中的 NVMe 儲存裝置，加入至 vSAN ESA 超融合叢集中的儲存集區 Add disk（s）to storage pool…… 等工作項目。

當 vSAN ESA 超融合叢集建構完成後，管理人員可以切換至「vSAN-Cluster > Monitor > vSAN > Skyline Health」，查看系統針對 vSAN ESA 超融合叢集的健康檢查情況，可以看到通過所有的健康檢查項目（如圖 17 所示）。

圖 17、順利建構 vSAN ESA 超融合叢集並通過所有健康檢查項目



建立 VM 虛擬主機和 vSAN 網路測試

順利建構 vSAN ESA 超融合叢集後，在正式上線營運並提供服務之前，建議管理人員可以採用內建的「主動測試」（Proactive Tests）功能，測試 vSAN ESA 超融合叢集在建立 VM 虛擬主機工作負載，以及在 vSAN 儲存網路方面是否符合需求。

請在 vCenter Server 管理介面中，依序點選「vSAN-Cluster > Monitor > vSAN > Proactive Tests > VM Creation Test > Run Test」，此時系統將會彈出視窗，說明建立 VM 虛擬主機工作負載測試程序的一些事宜，確認開始測試後按下 Run 鈕。

此時，可以在下方工作列中，看到系統自動在每台 vSAN 叢集節點主機中，建立 VM 虛擬主機然後再刪除 VM 虛擬主機，通過測試後便會在頁面中，顯示每台 vSAN 叢集節點主機的測試情況為 success，以及整體測試情況為通過測試的 Passed（如圖 18 所示）。

圖 18、每台 vSAN 叢集節點主機皆通過建立和刪除 VM 虛擬主機工作負載測試

接著，展開 Network Performance Test 項目後，同樣按下 Run Test 鈕進行 vSAN 儲存網路測試，系統將會彈出視窗，說明 vSAN 儲存網路測試程序的一些事宜，確認開始測試後按下 Run 鈕。從測試結果中可以看到，vSAN 叢集節點主機之間的 vSAN 儲存網路傳輸速率和測試情況（如圖 19 所示）。

圖 19、每台 vSAN 叢集節點主機皆通過 vSAN 儲存網路測試





結語

透過本文的深入剖析和實作演練後，相信管理人員除了理解最新發佈的 vSAN 8 版本，具備哪些亮眼特色功能之外，也充份理解如何從無到有建構出最新發佈的 vSAN ESA 超融合叢集，輕鬆為企業和組織部署高效能高穩定性高擴充性的 vSAN 超融合叢集。
↧

如何申請 GCP 免費試用 | Google Cloud

May 27, 2023, 3:38 am
$
0
0


緣起

簡單來說，最近要開始玩 GCP (Google Cloud Platform)。那麼，就讓我們從最基礎的部份開始吧! 因為，不想要跟原有使用的 Gmail 帳號綁在一起 (避免到時失手發生悲劇 😅)，所以先從申請另外的 Gmail 帳號開始吧。





申請 Gmail 帳號

有關申請 Gmail 帳號的詳細資訊，請參考官方文件即可，下列將會簡單描述整個申請 Gmail 帳號的流程。

首先，系統將會請你填入申請這個新的 Gmail 帳號的姓氏和名字。

選擇出生日期和性別 (不想透露性別也可以!)。


系統會根據剛才填寫的姓氏和名字，給予建議的 Gmail 位址。當然，不滿意可以自行修改，只要不跟已經存在的帳號發生衝突即可。


填入 Gmail 帳戶的密碼，即使是測試使用，仍然建議使用強式密碼，畢竟稍後申請 GCP 免費試用時，需要填入信用卡詳細資訊，所以保護好帳號密碼也是很重的 💪。


系統為了驗證，這個註冊 Gmail 帳號的你不是網路機器人，所以必須要填入手機電話號碼，以便稍後進行驗證。


此時，手機應該會收到驗證碼，填入後即可繼續下一個註冊流程。


看個人需求是否要新增備援電子郵件位址。


順利完成註冊 Gmail 帳號。






申請 GCP 免費試用

有了 Gmail 帳號之後，便能夠很方便的申請 GCP 免費試用。簡單來說，申請 GCP 免費試用後，就可以有 90 天的免費試用期和 US $300 抵用額度 (看兩者哪一個先用完)，和使用一些免費方案，詳細資訊請參考官方文件說明。

只要開啟瀏覽器到「https://cloud.google.com/free」頁面，並且在 Gmail 帳號登入的情況下，直接按下 Get started for free鈕即可開始申請 GCP 免費試用程序。


在申請 GCP 免費試用程序中，可以看到 90 天的免費試用期和 US $300 抵用額度資訊，以及為何需要提供信用卡資訊，並提醒未來到試用到期後，只要不手動升級至付費帳號，那就不會被扣款 (據說以及到期後，沒取消的話就會開始扣款了!)。


填寫驗證付款資訊，避免你要是把這個帳號拿去做壞事的話，那麼就可以追到你 (因為等一下要填信用卡資訊)。


你是不是想說，反正我信用卡資訊，其中一個數字不小心填錯了，應該也會過吧 😏？ 這種事情當然不可能發生，它會驗證並確保你所填寫的信用卡資訊是否正確，到時真要扣款也才能順利進行請款作業。


接著選擇你申請 GCP 免費試用的一些資訊即可 (不想填可略過)。


申請 GCP 免費試用，成功! 可以看到有 NT $9,215 (也就是 USD $300 抵免額)，以及到期日 2023 年 8 月 26 日。事實上，我到時也打算在試用到期後，連同這個 Gmail 帳號一起刪除，畢竟一開始申請的用意便是為了試用 GCP，到時也可以將信用卡資訊一併刪除掉。


↧
↧

Google Cloud 入門導覽 | Qwiklabs GSP282

June 2, 2023, 6:30 pm
$
0
0


簡介

在上一篇 如何申請 GCP 免費試用文章中，我們已經成功申請用於測試的 Gmail 帳號和 GCP 免費額度 (90 天 / US $300)。但是，在不熟悉 GCP 雲端環境的情況下，很有可能馬上就把錢燒完了，所幸可以透過 Google Cloud Skills Boost 計畫，幫助我們快速熟悉操作環境、運作原理、實戰演練……。



Qwiklabs

簡單來說，在 2012 年成立的 Qwiklabs 雲端學習平台，在 2016 年時被 Google 買下，用來教育訓練使用者熟悉 Google Cloud 所有產品。





A Tour of Google Cloud Hands-on Labs

我們先從這個最簡單的導覽課程開始吧! 進入  Google Cloud Skills Boost 計畫後，可以挑選你想要上的課程，當然如果你像我也一樣是英文苦手的話，也可以選擇語系為「繁體中文」。


進入後，可以看到課程說明確實都變成正體中文了。準備開始的話，就按下左邊的「Start Lab」鈕即可。


此時，系統將會開始倒數，原則上學習時間一定是夠用的，並且可以在左側看到幾個實作時會使用到的資訊，包括：
  • Open Google Console： 開啟 GCP 的控制面板。
  • Username： 登入學習 GCP 學習環境的暫用帳號。
  • Password： 登入學習 GCP 學習環境的暫用密碼。
  • Project ID： 在 GCP 學習環境中的資源容器。

按下 Open Google Console 系統另開新視窗之後，便可以在登入畫面中，複製並填入剛才顯示的暫用使用者帳號和密碼進行登入。


順利登入後，便自動顯示 Google Console 畫面。


倘若，希望 Google Console 操作畫面採用不同語系時，可以依序點選切換選擇為正體中文語系的操作介面。


順利將 Google Console 操作介面切換為正體中文語系。


在 Qwiklabs 運作環境中，預設情況下 「Qwiklabs Resource」包含暫用的相關檔案、資料集和機器映像檔，而且可以從每個 Google Cloud 研究室環境存取。值得注意的是「Qwiklabs Resource」與所有線上練習的使用者共用 (唯讀)，也就是說你無法刪除或修改該資源。


最後，要注意的是，一開始在 Dislogflow API 的部份，因為想說只是知道怎麼開啟就好，就沒真的去操作，一路上也都正確回答相關問題，但是結束時系統卻顯示沒有完成這個課程。此時，可以點選右上角進度去進行檢查作業，系統便會說明是哪個部份還未完成，可以看到原來是因為沒有真的去操作啟用 Dislogflow API 部份所導致，順利操作後便完成這個課程。



↧

Microsoft Learn Cloud Skills Challenge 2023

June 4, 2023, 7:13 pm
$
0
0


簡介

雲端技術是現在和未來不可阻擋的趨勢，倘若你想要在這個領域發展，你需要能夠不斷學習並更新雲端知識和技能。然而，如何才能有效的學習雲端技術呢？ 有沒有既有趣又有價值的方式來提升雲端技能呢？ 答案是有的! 就是The Microsoft Learn Cloud Skills Challenge !

在近幾年中，每當 Microsoft Build 大會開始時，便會同時舉辦的一個活動，讓有興趣的朋友可以透過微軟學習平台（Microsoft Learn）來學習和實作各種雲端技術，從基礎到進階，從開發到維運，從人工智慧到資料庫，應有盡有。

活動從 2023 年 5 月 23 日開始到 2023 年 6 月 20 日結束。在這段期間，你可以選擇參加其中一個或多個挑戰，每個挑戰都包含了一系列的微軟學習模組，讓你可以依照自己的節奏和興趣來學習。完成任何一個挑戰後，將能獲得一次免費的微軟認證考試，讓你可以證明你的雲端技能並提高你的職場競爭力。







挑戰詳情

  • Microsoft Learn Cloud 技能挑戰賽將於世界標準時間 2023 年 5 月 23 日下午 4:00（16:00）開始，並於世界標準時間 2023 年 6 月 20 日下午 4:00（16:00）結束。
  • 在註冊 Microsoft Learn 雲技能挑戰賽期間，您需要提供電子郵件地址。我們將通過您提供的電子郵件地址與您聯繫，並提供免費的認證詳細信息。
  • 通過完成 Microsoft Learn Cloud 技能挑戰中的一項挑戰，符合條件的個人將有權參加一次免費的 Microsoft 認證考試。





優惠詳情

  • 無論您完成多少挑戰，您每人只能申請一份優惠。
  • 在兌換您的免費認證考試之前，政府僱員必須與他們的雇主核實，以確保他們的參與是被允許的，並且符合適用的政策和法律。
  • 可以兌換此考試優惠以參加一 (1) 次 Microsoft 認證考試，該考試將於 2023 年 9 月 27 日之前在授權的 Pearson Vue 考試中心或通過 Pearson Vue 在線監考網站進行​​。
  • 此考試優惠是特定於考試的，並且只能兌換特定的 Microsoft 考試。雖然您可以參加任何選定的符合條件的考試，但請查看下面與每項考試相對應的挑戰。符合條件的考試包括
  • 參加考試沒有先決條件。但是，要獲得 Microsoft 認證，您必須首先滿足先決條件。如果您在先決條件之前參加並通過了專家考試，那麼您將無法獲得 Microsoft 認證，直到您滿足該 Microsoft 認證的所有要求。
  • 此考試優惠兌換窗口從 2023 年 6 月 30 日開始，到 2023 年 9 月 27 日到期，包括預訂和參加考試。
  • 在任何情況下都不能延長此考試報價的到期日期。
  • 此考試優惠只能兌換一次。
  • 此考試優惠不可兌換或兌換成現金、積分或退款。
  • 此考試優惠不可轉讓，如果您以任何方式更改、修改或轉讓，則該優惠無效。
  • 您必須年滿 14 歲才能參加 Microsoft Learn 技能挑戰賽。如果 Microsoft 確定您未達到最低年齡，您將無權參加免費的 Microsoft 認證考試，並且 Microsoft 保留對您採取法律行動的權利。
↧

如何在 GCP 中建立 Linux VM | Qwiklabs GSP001

June 9, 2023, 5:00 pm
$
0
0


簡介

在本文實作練習中，將會透過 Creating a Virtual Machine | Qwiklabs GSP001主題，學習如何在 GCP 雲端環境中建立 Linux VM 虛擬主機。






啟用 Cloud Shell (gcloud)

本次實作時間給予 1 小時，算是非常充裕。同樣的，啟動實作環境後，系統提供暫用的使用者帳號、密碼、Project ID…等資訊。


在 Cloud Console 畫面中，點選右上角圖示後，準備啟用 Cloud Shell(gcloud)，稍後也會使用到。簡單來說，Cloud Shell 是個已經載入了開發工具的極小型 VM 虛擬主機，並且提供 5 GB 儲存空間，以便管理人員可以透過 Cloud Shell 對 Google Cloud 資源進行存取等管理動作。


順利啟用 Cloud Shell 之後，可以嘗試執行「gcloud auth list」、「gcloud config list project」指令，了解目前運作環境的相關系統資訊。詳細資訊請參考 gcloud CLI overview  |  Google Cloud CLI Documentation 官方文件。






透過 Cloud Console 部署 Linux VM

現在，切換回 Cloud Console 畫面中，依序點選「Compute Engine > VM instances」準備透過 Cloud Console 部署 Linux VM 虛擬主機。


在部署 Linux VM 的畫面中，依照文件給予相關欄位設定值：

往下捲，檢查並確認勾選 Allow HTTP traffic 項目，確保稍後部署的 Linux VM 虛擬主機，GCP 防火牆允許 HTTP (Port 80) 的流量通行。
  • Boot disk Type： New balanced persistent disk，Linux VM 虛擬硬碟類型。
  • Boot disk Size： 10GB，Linux VM 的啟動硬碟空間。
  • Boot disk Image： Debian GUN/Linux 11 (bullseye)，部署 Linux VM 的映像檔。
  • Firewall： 勾選 Allow HTTP traffic項目，確保 Internet 上的網路流量，可以通過防火牆到達 Linux VM 的 HTTP (Port 80)。

開始部署後，不到 1 分鐘的時間便將 Linux VM 虛擬主機部署完成了! 同時，在 Cloud Console 可以看到該台 Linux VM 拿到的內部跟外部 IP 位址，管理人員可以點選 SSH，系統便會自動彈出 SSH-in-browser 視窗，並且直接連線到剛才部署的 Linux VM。


接著，依照實作頁面所說明，為這台 Linux VM 執行 Update OS、安裝 NGINX 網頁伺服器、確認 NGINX 服務啟動等動作。
sudo apt-get update
sudo apt-get install -y nginx
ps auwx | grep nginx
確認 NGINX 服務啟動後，便可以開啟瀏覽器，並在 URL 列鍵入 Linux VM 外部 IP 位址，本文實作為 35.243.223.132，即可看到 NGINX 歡迎頁面，代表順利從 Internet 連到這台 Linux VM 的 HTTP (Port 80) 網頁服務。






透過 gcloud 部署 Linux VM

使用 Cloud Console 部署少量 VM 虛擬主機時非常方便，倘若以後有需求要部署大量 VM 虛擬主機時，就可以改為透過 Cloud Shell來進行部署，到時只要加上迴圈功能即可達成。

只要切換到 Cloud Shell 視窗，鍵入「gcloud compute instances create gcelab2 --machine-type e2-medium --zone」指令，便可以快速部署一台 Linux VM 虛擬主機。


同樣的，部署第二台 Linux VM 虛擬主機的速度也非常快，很快就出現在 Cloud Console 畫面中。


當然，除了透過 SSH-in-browser  方式連線到 Linux VM 之外，管理人員也可以直接使用 Cloud Shell 來連線 Linux VM 虛擬主機，例如，本文實作中鍵入「gcloud compute ssh gcelab2 --zone」即可。


至此，就完成這個部署 Linux VM 虛擬主機的練習。



↧
Search

如何在 GCP 中建立 Windows VM | Qwiklabs GSP093

June 16, 2023, 5:00 pm
$
0
0


簡介

在本文實作練習中，將會透過 Compute Engine: Qwik Start - Windows | Qwiklabs GSP093主題，學習如何在 GCP 雲端環境中建立 Windows VM 虛擬主機。






啟用 Cloud Shell (gcloud)

本次實作時間給予 1 小時，算是非常充裕。同樣的，啟動實作環境後，系統提供暫用的使用者帳號、密碼、Project ID…等資訊。



在 Cloud Console 畫面中，點選右上角圖示後，準備啟用 Cloud Shell(gcloud)，稍後也會使用到。簡單來說，Cloud Shell 是個已經載入了開發工具的極小型 VM 虛擬主機，並且提供 5 GB 儲存空間，以便管理人員可以透過 Cloud Shell 對 Google Cloud 資源進行存取等管理動作。

順利啟用 Cloud Shell 之後，可以嘗試執行「gcloud auth list」、「gcloud config list project」指令，了解目前運作環境的相關系統資訊。詳細資訊請參考 gcloud CLI overview  |  Google Cloud CLI Documentation 官方文件。






透過 Cloud Console 部署 Windows VM

現在，切換回 Cloud Console 畫面中，依序點選「Compute Engine > VM instances > Create Instance」準備透過 Cloud Console 部署 Windows VM 虛擬主機。


在部署 Windows VM 的畫面中，依照文件給予相關欄位設定值：

往下捲，在 Boot disk 區塊中按下 CHANGE 鈕，選擇部署 Windows VM 虛擬主機所要採用的映像檔。其實，在這個實作環境中，官方文件請我選擇 Windows Server 2012 R2 Datacenter映像檔，但是我改為選擇最新的 Windows Server 2022 Datacenter映像檔，反正部署失敗的話再採用官方文件所說的即可。😏
  • Boot disk Type： New balanced persistent disk，Windows VM 虛擬硬碟類型。
  • Boot disk Size： 50GB，Windows VM 的啟動硬碟空間。
  • Boot disk Image： Windows Server 2022 Datacenter，部署 Windows VM 的映像檔。

開始部署後，不到 1 分鐘的時間便將 Windows VM 虛擬主機部署完成了! 


雖然，Windows VM 虛擬主機已經部署完成，但可能還無法順利 RDP 遠端連線至該主機。此時，可以透過 Cloud Shell 執行「gcloud compute instances get-serial-port-output instance-1」指令進行確認，當執行結果出現「gcloud compute instances get-serial-port-output instance-1」即表示可以 RDP 遠端連線至 Windows VM 虛擬主機。本文實作環境，我共執行了三次指令後才確認可以 RDP 遠端連線訊息。



確認可以 RDP 遠端連線後，同樣可以透過 Cloud Shell 組態設定 Windows VM 的管理者帳號及密碼，請執行「gcloud compute reset-windows-password [instance] --zone [zone] --user [username]」，即可進行設定，例如，執行「gcloud compute reset-windows-password instance-1 --zone us-central1-b --user weithenn」，系統便會自行幫你隨機密碼。


當然，你也可以使用 Google Console 重新設定管理者密碼。



一切準備就緒後，就可以順利 RDP 遠端桌面連線至剛才部署的 Windows VM 虛擬主機。


↧
↧

GCP 攻略 - 系列文章 (更新: 如何在 GCP 中建立 Windows VM)

June 19, 2023, 7:52 am
$
0
0


簡介

簡單來說，在不熟悉 GCP 雲端環境的情況下，很有可能馬上就把試用申請的 GCP 免費額度 (90 天 / US $300)燒完 😆，所幸可以透過 Google Cloud Skills Boost 計畫，幫助我們快速熟悉操作環境、運作原理、實戰演練……。那麼，就一起透過 Google Cloud Skills Boost 計畫，學習吧! 😎






↧

如何使用 Cloud Shell 和 gcloud 指令 | Qwiklabs GSP002

June 22, 2023, 7:30 am
$
0
0


簡介

在本文實作練習中，將會透過 開始使用 Cloud Shell 和 gcloud | Google Cloud Skills Boost主題，學習如何在 Cloud Shell 環境中，透過 gcloud 指令工具連線至託管於 Google Cloud 的運算資源。






啟用 Cloud Shell (gcloud)

本次實作時間給予 1 小時 10 分，算是非常充裕。同樣的，啟動實作環境後，系統提供暫用的使用者帳號、密碼、Project ID…等資訊。


在 Cloud Console 畫面中，點選右上角圖示後，準備啟用 Cloud Shell (gcloud)，稍後也會使用到。簡單來說，Cloud Shell 是個已經載入了開發工具的極小型 VM 虛擬主機，並且提供 5 GB 儲存空間，以便管理人員可以透過 Cloud Shell 對 Google Cloud 資源進行存取等管理動作。

順利啟用 Cloud Shell 之後，可以嘗試執行「gcloud auth list」、「gcloud config list project」指令，了解目前運作環境的相關系統資訊。詳細資訊請參考 gcloud CLI overview  |  Google Cloud CLI Documentation官方文件。






設定採用的 Region 和 Zone

在開始實作之前，應該先了解有哪一些 Google Compute Engine 資源，可供使用。簡單來說，「區域」(Region)是執行資源的特定地理位置，每個區域當中則會有一或多個「可用區」(Zone)。舉例來說，「us-central1」表示美國中部區域，在這個區域中有「us-central1-a、us-central1-b、us-central1-c 和 us-central1-f」 多個可用區。有關 Region 和 Zone 的詳細資訊，請參考 Regions and zones  |  Compute Engine Documentation  |  Google Cloud官方文件。下表列出各個可用區和所屬區域：


透過下列指令，可以組態設定 Region 為「us-central1」，並將 Zone 設定為「us-central1-b」，組態設定完成後，記得透過指令確認組態設定是否套用生效。


在 Google Console 操作畫面中，可以很輕鬆的查看 Project ID。當然，透過 gcloud 指令「gcloud config get-value project」也可以很方便進行查詢。倘若，要查看 Project ID 詳細資訊請執行「gcloud compute project-info describe --project $(gcloud config get-value project)」指令即可。


當然，在 CLI 指令操作介面中，需要更行雲流水的操作時，可以透過組態設定環境變數來達成。可以透過下列三個指令分別組態設定環境變數：
  • 建立儲存 Project  ID 的環境變數： export PROJECT_ID=$(gcloud config get-value project)
  • 建立儲存 Zone 的環境變數： export ZONE=$(gcloud config get-value compute/zone)
  • 確認環境變數是否套用生效： echo -e "PROJECT ID: $PROJECT_ID\nZONE: $ZONE"

透過 gcloud 指令建立 VM 虛擬主機，請執行「gcloud compute instances create gcelab2 --machine-type e2-medium --zone $ZONE」指令，即可建立 VM 虛擬主機，下列為指令的相關參數說明：
  • gcloud compute： 用於管理 Compute Engine 資源。
  • instances create： 建立新的執行個體，在這裡為建立新的 VM 虛擬主機。
  • gcelab2： 建立的 VM 虛擬主機名稱。
  • --machine-type： 指定採用「e2-medium」機器類型。
  • --zone： 指定在哪個 Zone 當中建立 VM 虛擬主機。倘若，省略 --zone 參數時，gcloud 指令將會採用預設值，也就是先前查詢 Project ID 詳細資訊內所顯示的預設值。





透過 gcloud 查詢特定資訊

透過「gcloud compute instances list」指令，可以查詢 Project ID 中所有的執行個體，或使用「gcloud compute instances list --filter="name=('gcelab2')"」指令，查詢特定執行個體的資訊。


透過「gcloud compute firewall-rules list」指令，查詢 Project ID 當中所有的防火牆規則，或使用「gcloud compute firewall-rules list --filter="network='default'"」指令，查詢防火牆規則中 Network 欄位為 default 的防火牆規則，或使用「gcloud compute firewall-rules list --filter="NETWORK:'default' AND ALLOW:'icmp'"」指令，查詢防火牆規則中 Network 欄位為 default 且允許 ICMP 的防火牆規則。






透過 gcloud 連線至 VM 虛擬主機

管理人員可以透過「gcloud compute ssh gcelab2 --zone $ZONE」指令，連線至剛才所部署建立名稱為 gcelab2 虛擬主機，可以看到預設採用 Debian 11 作業系統的 VM 虛擬主機。


由於，在這個實作當中，會為 VM 虛擬主機安裝 Nginx 網頁伺服器，然而預設情況下防火牆規則並不會允許 HTTP Port 80、HTTPs Port 443 網路流量通過。因此，管理人員可以透過「gcloud compute instances add-tags gcelab2 --tags http-server,https-server」指令，新增 Tag 名稱，使用「gcloud compute firewall-rules create default-allow-http --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=http-server」指令，更新防火牆規則以便放行 TCP Port 80 的網路流量，執行「gcloud compute firewall-rules list --filter=ALLOW:'80'」指令，確認允許的防火牆規則是否套用生效。

最後，透過「curl http://$(gcloud compute instances list --filter=name:gcelab2 --format='value(EXTERNAL_IP)')」指令，確認能否正確瀏覽 gcelab2 的 Nginx 預設網頁內容。






查看系統日誌

管理人員可以隨時透過「gcloud logging logs list」指令，查看所有類型的系統日誌，執行「gcloud logging logs list --filter="compute"」指令，僅查看 Compute 資源的系統日誌，執行「gcloud logging read "resource.type=gce_instance" --limit 5」指令，僅查看資源類型為「gce_instance」的系統日誌。


同樣的，在完成實作練習結束前，記得確認是否通過所有的檢查程序，才能確保獲得這個實作課程的積分，往下一個實作前進。

↧

部署 Azure Stack HCI 體驗 SDN 軟體定義網路 | 網管人 209 期

June 23, 2023, 2:50 am
$
0
0


網管人雜誌

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





本文目錄






前言

在過去的環境中，管理人員要在地端資料中心內，部署 Microsoft HCI 超融合以及 SDN 軟體定義網路環境時，雖然有許多部署方式可供選擇，但是需要投入的 IT 人力和預算並不低，因此對於 IT 人力和預算原本就不足的中小企業或組織來說，想要體驗這部份的技術就顯得有點距離。

然而，現在透過 Azure 公有雲環境，中小企業或組織的管理人員，可以透過申請 Azure 免費訂閱帳號，或是花費極低的金額，便能夠快速體驗建構和部署微軟 HCI 超融合以及 SDN 軟體定義網路環境（如圖 1 所示）。

圖 1、SDN 軟體定義網路運作架構示意圖
圖片來源： Plan a Software Defined Network infrastructure - Azure Stack HCI | Microsoft Learn





新版 SDN 特色功能

SDN 網路控制器

在 SDN 軟體定義網路環境中，「網路控制器」（Network Controller）的重要性不言而喻，  無論是地端資料中心內，集中管理和組態設定網路及服務，例如，虛擬交換器、軟體路由器、負載平衡機制……等，都可以透過 SDN 網路控制器進行動態建立，以及保護傳統網路架構難以防禦的「東 - 西」（East-West）向網路惡意攻擊（如圖 2 所示）。

圖 2、網路控制器防禦東西向網路攻擊的資料中心防火牆機制運作示意圖
圖片來源： Overview of Datacenter Firewall in Azure Stack HCI and Windows Server - Azure Stack HCI | Microsoft Learn

簡單來說，網路控制器具備高可用性和擴充性，並提供兩個 API 應用程式設計介面，首先是「South Bound API」提供網路控制站與網路設備進行通訊，而「North Bound API」則是讓管理人員能夠與網路控制站進行通訊。因此，管理人員可以透過 PowerShell 或 RESTful API，達到管理實體網路交換器、路由器、軟體式防火牆、VPN 閘道、軟體式負載平衡器……等（如圖 3 所示）。

圖 3、SDN 網路控制器運作架構示意圖
圖片來源： Network Function Virtualization | Microsoft Learn



SDN 軟體式負載平衡

在過去的版本中，管理人員必須採用 PowerShell 指令碼，或是透過 SDN Express的協助下，才能建構 SDN 軟體定義網路環境的主要運作元件。然而，從 2021 年 11 月份，最新的 WAC 版本釋出後，管理人員便可以輕鬆的透過 WAC 管理平台，在 HCI 超融合叢集運作環境中，部署 SDN 主要運作元件，包括，SDN 網路控制器、SDN 軟體式負載平衡、SDN 閘道。
請注意! 必須搭配 WAC 中最新的擴充模組 SDN Infrastructure v1.32.0或後續版本才行。

那麼 SDN 軟體式負載平衡，具備哪些功能並且能夠為企業或組織帶來什麼好處呢 ？首先，它是適用於 第四層（Layer 4）的網路負載平衡服務，所以能夠處理南北向和東西向的 TCP/UDP 網路流量，並且在 VLAN 和 Hyper-V 虛擬網路環境中，支援「動態 IP 位址」（Dynamic IP address，DIP）。

管理人員可以將前端的「虛擬 IP 位址」（Virtual IP address，VIP），透過 SDN 軟體負載平衡機制，組態設定與後端負載平衡集區成員的 VM 虛擬主機 DIP 進行綁定作業，如此一來當使用者需要存取服務時，便會由前端 VIP 接收後傳送給後端的 DIP 進行服務的承接任務（如圖 4 所示）。

圖 4、SDN 軟體式負載平衡 DIP 和 VIP 運作架構示意圖
圖片來源： Software Load Balancer（SLB）for SDN in Azure Stack HCI and Windows Server - Azure Stack HCI | Microsoft Learn

此外，當後端的 DIP 負載平衡集區成員 VM 虛擬主機發生故障時，而前端的 VIP 服務能夠即時知悉，並避免將服務請求傳送給故障的主機，所以 SDN 軟體式負載平衡，也支援兩種不同的健康狀態偵測機制，分別是「TCP 連接埠偵測」以及「URL 和 HTTP 連接埠偵測」，確保後端 DIP 負載平衡集區成員 VM 虛擬主機的健康狀態（如圖 5 所示）。

圖 5、SDN 軟體式負載平衡運作架構示意圖
圖片來源： 描述 Azure Stack HCI 上的軟體負載平衡器 - Training | Microsoft Learn

此外，在 SDN 軟體式負載平衡運作機制中，還支援「伺服器直接回傳」（Direct Server Return，DSR）機制。簡單來說，傳統的網路流量去回的路徑是同一條，也就是從前端 VIP 負載平衡機制，將請求流量導給後端 DIP 處理後，將回應請求的網路封包再回傳給 VIP 後再回給請求端。然而，這樣的運作架構，有可能最後的瓶頸會是卡在 VIP 負載平衡端點上。

而 DSR 伺服器直接回傳機制，在處理請求封包時，同樣是從前端 VIP 負載平衡給後端的 DIP 處理，然而當後端的 DIP 處理完畢後，便直接將回應請求的網路封包直接回傳給請求端，而不會由原本的路徑回到前端 VIP 再回給請求端，因此在回應請求上除了更快更有效率外，也能避免瓶頸卡在前端 VIP 端點上（如圖 6 所示）。

圖 6、DSR 伺服器直接回傳機制運作示意圖
圖片來源： Software Load Balancer in Azure Stack HCI - Microsoft Community Hub



輕鬆易用的微分段安全機制

在傳統網路架構中，防火牆是座落在保護南北向網路流量的位置（如圖 7 所示），但是傳統的網路架構並無法阻擋新型態的惡意攻擊，例如，東西向惡意攻擊網路流量。

圖 7、傳統網路架構防火牆僅能阻擋南北向網路的惡意攻擊行為
圖片來源： Tag based Segmentation with Azure Stack HCI - Microsoft Community Hub

在 SDN 軟體定義網路環境中，則能輕易透過 Tag based 機制，實作出「微分段」（Micro-Segmentation）安全性機制，等於是在每台 VM 前方都有一台防火牆，能夠輕易阻擋傳統網路架構難以阻擋的東西向惡意攻擊網路流量，舉例來說，眾多 VM 虛擬主機在同一個網路環境，其中一台遭受惡意攻擊成功後，卻無法感染同一個網段中的其它台 VM 虛擬主機（如圖 8 所示）。

圖 8、微分段機制有效阻擋東西向惡意攻擊示意圖
圖片來源： Tag based Segmentation with Azure Stack HCI - Microsoft Community Hub





實戰 – 部署 SDN 至 Azure Stack HCI 超融合環境

在實戰小節中，將會帶領管理人員，如何在沒有硬體設備的情況下，透過 Azure 公有雲環境體驗部署和建置 Azure Stack HCI 超融合，以及 SDN 軟體定義網路運作環境。

首先，將會在 Azure 公有雲環境中，部署一台支援巢狀式虛擬化技術的 VM 虛擬主機，該台 VM 虛擬主機採用最新 Windows Server 2022 雲端作業系統，在啟用 Hyper-V 巢狀式虛擬化技術  後，將會建立三台 VM 虛擬主機，第一台 VM 虛擬主機將安裝 Windows Server 2019 作業系統，並且擔任 Active Directory 網域控制站、DNS 名稱解析伺服器、DHCP 伺服器和 WAC（Windows Admin Center）管理平台，另外二台則是安裝 Azure Stack HCI 21H2 版本，建構和部署 Azure Stack HCI 超融合叢集，同時部署 SDN 軟體定義網路的基礎架構（如圖 9 所示）。

圖 9、Azure Stack HCI 超融合和 SDN 軟體定義網路運作架構示意圖
圖片來源： 評估 Azure Stack HCI | Microsoft Learn



部署 Azure 巢狀式 VM 運作環境

首先，將在 Azure 公有雲環境中，部署一台支援巢狀式虛擬化技術的 VM 虛擬主機，預設將會採用 Standard_E16s_v4 規格的 VM 虛擬主機，配置的虛擬硬體為 16 vCPU 和 128 GB vMemory，支援最多掛載 32 顆資料硬碟。

因此，管理人員必須確認擁有實作的 Azure 訂閱帳號，是否支援部署此規格的 VM 虛擬主機。倘若，管理人員並沒有 Azure 訂閱帳號時，則可以註冊 Azure 免費訂閱帳號後，將免費訂閱帳號升級為「隨用隨付」（Pay-as-you-go），便能取得 USD 200 美金的額度，同時順利建立 Standard_E16s_v4 規格的 VM 虛擬主機，只要記得在實作完成後關閉和刪除相關雲端資源，便能夠在免費額度的情況下完整實作本文環境。

在部署 Azure VM 頁面中，按下 Deploy to Azure鈕，便會開啟新的頁面並轉導至 Azure Portal 介面，請管理人員依據需求調整下列項目（如圖 10 所示）：
  • Subscription： 選擇建立此台 VM 虛擬主機的 Azure 訂閱帳號。
  • Resource Group： 選擇裝載此台 VM 虛擬主機和相關資源元件的「資源群組」（Resource Group），本文實作名稱為「RG-EastAsia-AzSHCI-Lab」。
  • Region： 選擇運作此台 VM 虛擬主機的 Azure 資料中心，本文實作選擇「東亞」（East Asia）資料中心。
  • Virtual Machine Name： 填入此台 VM 虛擬主機的電腦名稱，本文實作為「AzSHCIHost」。請注意，這裡的電腦名稱超過 15 個字元，或包含特殊符號的話將會導致部署失敗。
  • Virtual Machine Size： 選擇部署此台 VM 虛擬主機採用的規格，採用預設值 Standard_E16s_v4 即可。
  • Data Disk Size： 指定每個資料硬碟的大小，採用預設值 256GB 時，屆時系統將會採用 256GB x8 顆進行組合，也就是屆時 VM 虛擬主機將會看到 2TB 空間大小的儲存空間。
  • Admin Username： 指定預設登入 VM 虛擬主機的管理帳號，本文實作為 Weithenn。
  • Admin Password： 指定預設登入 VM 虛擬主機的管理密碼。請注意，這裡的管理密碼僅打一次，所以請務必注意不要打錯字造成稍後無法登入 VM 虛擬主機的情況。
  • Auto Shutdown Status： 系統預設啟動自動關機組態設定，但由於我們將會快速部署和測試後關閉，所以將自動關機組態設定停用，避免影響實作。
圖 10、在 Azure 公有雲環境中部署巢狀式 VM 虛擬主機

確認無誤後，按下「Review + create」鈕，系統將會檢查相關組態設定值是否正確，例如，採用的 Azure 訂閱帳號是否支援部署此規模 VM 虛擬主機、VM 虛擬主機的電腦名稱是否超過 15 個字元和包含特殊符號、選擇的 Azure 資料中心是否仍有資源提供部署……等。

系統檢查無誤後，將會出現「Validation Passed」的驗證通過訊息，請按下 Create 鈕便開始進行部署巢狀式 VM 虛擬主機的動作，在本文實作部署過程中，花費約「50 分鐘」便順利部署完成。

部署完成後，當管理人員嘗試透過下載的 RDP 遠端桌面連線設定檔連線時，將會發現無法連線至 VM 虛擬主機的情況。事實上，因為安全性的考量，所以系統預設網路安全性 NSG 的組態設定部份，已經先將 RDP（Port 3389）的連線規則進行阻擋，所以導致無法連線的情況。

只要在 Azure Portal 頁面中，進入 VM 虛擬主機選項，點選「Settings > Networking > Inbound port rules」，便能看到系統將 RDP Port 3389 的連線行為設定為「Deny」，只要選擇修改為「Allow」允許放行即可順利連線（如圖 11 所示）。

圖 11、將 NSG 預設阻擋 RDP Port 3389 的防火牆規則，調整為 Allow 允許放行即可



巢狀式 VM 虛擬主機基本組態設定

順利登入 Azure VM 虛擬主機後，檢查後可以發現採用的是最新 Windows Server 2022 Datacenter Azure Edition（21H2）版本，時區方面則是採用標準的 UTC 格林威治時間，請將時區調整為符合我們當地時區的「UTC + 08 :00 - Taipei」。

此外，查看後可以發現已經安裝和啟用 Hyper-V 虛擬化技術，以便稍後可以部署三台 VM 虛擬主機。開啟磁碟管理員，可以看到系統中擁有一個 2 TB大小的磁碟區，並且使用「V :」磁碟機代號，這也是屆時存放 VM 虛擬主機和相關檔案的儲存空間（如圖 12 所示）。

圖 12、由 8 顆 256GB 資料硬碟組成的 2TB 儲存空間



部署 Azure Stack HCI 超融合環境

基本組態確認完成後查看桌面時，管理人員將會看到名稱為「New-AzSHCISandbox」的圖示，這便是稍後幫助管理人員，快速建構和自動化部署 Azure Stack HCI 超融合環境的指令碼。倘若，在桌面上未看到 New-AzSHCISandbox圖示的話，那表示 DSC（Desired State Configuration）工作程序，仍在背景執行中尚未完成，請等待一段時間待 DSC 工作程序執行完畢後，桌面上便會自動出現 New-AzSHCISandbox 圖示。

事實上，管理人員可以在執行部署之前，進行微調客製化組態設定，以便建構和部署出客製化環境，舉例來說，預設情況下將會建立名稱為「contoso.com」的網域名稱，而管理密碼則是「Password01」的運作環境，以及稍後部署 SDN 軟體定義網路的相關網段資訊。

倘若，管理人員不想採用預設值而需要客製化環境時，請至切換至「C:\AzHCI_Sandbox\AzSHCISandbox-main」資料夾下，編輯「AzSHCISandbox-Config.psd1」檔案內容，便可以將 SDNAdminPassword 指定的管理密碼，由預設的「Password01」修改為管理人員習慣的管理密碼，將 SDNDomainFQDN 欄位值，由預設的「contoso.com」修改為客製化的網域名稱，例如「lab.weithenn.org」，而 DCName 欄位值由預設的「contosodc」，修改為客製化的主機名稱，例如「labdc」，其它欄位值也都可以則視管理人員需求調整即可。

組態設定檔客製化內容修改完畢後，為了確保稍後部署過程中，可以了解整理的部署項目和進度，請點選桌面上的 New-AzSHCISandbox 圖示，點選右鍵後選擇內容，將捷徑設定的 Target 欄位值修改為「PowerShell -NoExit C:\AzHCI_Sandbox\AzSHCISandbox-main\New-AzSHCISandbox.ps1」，後按下 OK 鈕，那麼稍後執行時 PowerShell 指令視窗，便不會消失轉為背景執行而是留在桌面上以便觀察，倘若部署過程中發生錯誤的話，才能方便管理人員進行除錯。

現在，管理人員可以點選二下桌面上的 New-AzSHCISandbox 圖示，開始執行部署作業，管理人員也可以開啟 Hyper-V 管理員，稍後便能看到系統自動化進行部署作業，並且依序建立三台 VM 虛擬主機，分別是名稱為 AzSMGMT 的 DC 網域控制站，以及二台 AzSHOST1 和 AzSHOST2 超融合節點主機（如圖 13 所示）。

圖 13、系統開始自動部署 Azure Stack HCI 超融合及 SDN 軟體定義網路運作環境

在本次實作環境中，自動化部署的工作任務花費「1 小時 52 分」順利部署完成，在 PowerShell 指令碼視窗中，可以看到「Successfully deployed the Azure Stack HCI Sandbox」訊息，以及工作任務執行時間（如圖 14 所示）。

圖 14、本次部署 Azure Stack HCI 超融合及 SDN 軟體定義網路花費時間



管理 Azure Stack HCI 超融合環境

當部署完成後，系統將會在桌面上建立另一個 RDP 遠端連線捷徑，名稱為「AdminCenter」，方便管理人員直接連線至 AzSMGMT 管理主機，倘若管理人員採用系統預設值的話，請鍵入「Contoso\Administrator」管理者帳號，以及「Password01」管理者密碼即可登入管理主機。

順利登入 AzSMGMT 管理主機後，可以看到桌面上已經有許多管理工具的捷徑，例如，DNS 管理員、容錯移轉叢集管理員、Hyper-V 管理員以及 WAC（Windows Admin Center）。請按二下桌面上的Windows Admin Center 捷徑，同樣的，倘若管理人員未採用客製化組態設定的話，請鍵入預設的「Contoso\Administrator」管理者帳號，以及「Password01」管理者密碼，登入 WAC 管理平台。

登入 WAC 管理平台後，預設情況下將會看到目前採用的 WAC 為最新的 v2211 版本，並且系統將開始自動更新相關擴充模組，全部更新完成後，系統會出現「Successfully updated your extensions」的提示訊息，表示所有擴充模組已經更新完畢，按下 OK 鈕後，將會重新載入 WAC 管理頁面。請點選右上角齒輪圖示，點選 Gateway 下的 Extensions 項目，查看 SDN 軟體定義網路相關擴充模組及版本（如圖 15 所示）。

圖 15、查看 SDN 軟體定義網路相關擴充模組及版本

回到 WAC 主要頁面，請依序點選「All connections > Cluster Manager > Add」項目，在 Add cluster 頁籤下的 Cluster name 欄位，請鍵入「AzStackCluster.contoso.com」預設 HCI 超融合叢集名稱，系統正確辨別叢集名稱後，便會自動勾選也要將 AzSHOST1 和 AzSHOST2，這二台 HCI 超融合叢集節點主機加入，確認後按下 Add 鈕即可。

順利納管 HCI 超融合叢集，可以看到 HCI 超融合叢集的各種工作負載資訊，例如，HCI 超融合叢集節點主機數量、儲存裝置數量、管理 vSwitch 虛擬網路交換器、HCI 超融合叢集的各項硬體資源使用資訊、IOPS 儲存效能、Latency 網路延遲時間、Throughput 傳輸速率……等（如圖 16 所示）。

圖 16、查看 HCI 超融合叢集系統資源儀表板



啟用 SDN 軟體定義網路基礎架構

目前，在 WAC 管理介面中，可以看到 Networking 項目下，只有 Virtual switches 和 SDN Infrastructure 項目，請點選 SDN Infrastructure 項目後，系統將會自動安裝 RSAT-NetworkController 伺服器功能管理工具，並確認已自動安裝 SDN 網路控制器的 REST 憑證，確認後系統將出現「SDN infrastructure was detected and validated」訊息，請按下 Continue 鈕。

此時，系統將會出現 Connect to Network Controller 視窗，請管理人員鍵入 SDN 網路控制器的主機名稱，採用預設值的管理人員可以鍵入「nc01.contoso.com」後，按下 Continue 鈕後，便會順利連結至 SDN 網路控制器，同時系統提示按下 F5 鈕重新載入 WAC 管理介面。

順利重新載入頁面後，可以看到 Networking 項目下，多了許多 SDN 軟體定義網路管理項目，包括，Load balancer、Logical networks、Gateway connections、Network security group……等（如圖 17 所示）。

圖 17、啟用和連結 SDN 網路控制器並查看 SDN Infrastructure 摘要資訊



查看 SDN 網路控制器

點選 Network Controller 項目，可以看到 SDN 網路控制器的運作資訊和執行狀態，例如，REST URL 資訊、SDN 網路控制器版本、SDN 網路控制器服務狀態……等（如圖 18 所示）。

圖 18、查詢 SDN 網路控制器的運作資訊和執行狀態



查看 SDN 軟體負載平衡

點選 Load Balancer 項目，可以看到系統預設已經指派「30.30.30.1」，為 SDN 軟體負載平衡的管理 IP 位址，以及 Outbound NAT IP 位址。同時，可以看到 HCI 超融合叢集的成員主機，AzSHOST1 和 AzSHOST2 都運作著負載平衡代理程式，和目前 Public IP Pool 和 Private IP Pool 的使用情況，以及 Mux 負載平衡機制主機的工作負載資訊（如圖 19 所示）。

倘若，管理人員希望新增其它的軟體負載平衡，請點選「Networking > Load balancers > Inventory > New」即可新增，若要新增其它軟體負載平衡的 Public IP 位址，請點選「Networking > Public IP addresses> Inventory > New」即可新增。

圖 19、查詢 SDN 軟體負載平衡運作資訊和執行狀態



查看 SDN 閘道

點選 Gateway 項目，可以看到 SDN 閘道的運作狀態和工作負載，在管理畫面中看到 gw01.contoso.com主機，狀態為「Uninitialzed」警告訊息請不用擔心，請將畫面往下捲即可看到，SDN 閘道主機共有兩台並且互為備援的 Active/Standby機制，所以目前 gw02.contoso.com主機狀態為「Active」，所以 gw01.contoso.com 主機運作狀態為「Redundant」，而組態設定狀態為「Uninitialzed」（如圖 20 所示）。

圖 20、查詢 SDN 閘道運作資訊和執行狀態



部署 VM 虛擬主機並套用 SDN 規則

管理人員可以在 Networking 項目中，針對運作環境進行組態設定，例如，新增相關 Logical networks 和 subnet……等網路環境，後續在新增 VM 虛擬主機時，便能夠在部署階段中的 Network 項目，選擇套用 SDN 軟體定義網路的相關組態設定。

舉例來說，在本文實作環境中，建立名稱為「VM vNetwork」的邏輯網路，以及網段為「10.10.168.0/24」，此外還套用名稱為「NSG-WebApp」的網路安全群組原則，確保部署的這台 VM 虛擬主機受到微分段安全機制的保護，避免受到東西向網路惡意攻擊的威脅（如圖 21 所示）。

圖 21、部署 VM 虛擬主機並套用 SDN 軟體定義網路安全性保護原則





結語

透過本文的深入剖析和實作演練後，管理人員除了理解整合 SDN 軟體定義網路，至原有 HCI 超融合叢集中具備哪些優點之外，即便是 IT 預算不足的中小型企業或組織，在沒有任何硬體設備的情況下，也能透過免費的 Azure 訂閱或花費少許費用，便能立即體驗和實際操作 HCI 超融合叢集整合 SDN 軟體定義網路的運作環境。
↧

在 Google Cloud 上快速入門 Kubernetes Engine | Qwiklabs GSP100

June 30, 2023, 7:39 am
$
0
0


簡介

在本文實作練習中，將會透過 Kubernetes Engine：Qwik Start | Google Cloud Skills Boost主題，學習如何在 GCP 雲端環境中，部署和建立 GKE (Google Kubernetes Engine) 叢集環境，以便管理容器化應用程式並調度資源，並練習透過 GEK 叢集平台建立容器及部署應用程式。






啟用 Cloud Shell (gcloud)

本次實作時間給予 1 小時也是非常充裕。同樣的，啟動實作環境後，系統提供暫用的使用者帳號、密碼、Project ID…等資訊。


在 Cloud Console 畫面中，點選右上角圖示後，準備啟用 Cloud Shell (gcloud)，稍後也會使用到。簡單來說，Cloud Shell 是個已經載入了開發工具的極小型 VM 虛擬主機，並且提供 5 GB 儲存空間，以便管理人員可以透過 Cloud Shell 對 Google Cloud 資源進行存取等管理動作。

順利啟用 Cloud Shell 之後，可以嘗試執行「gcloud auth list」、「gcloud config list project」指令，了解目前運作環境的相關系統資訊。詳細資訊請參考 gcloud CLI overview  |  Google Cloud CLI Documentation官方文件。





設定採用的 Region 和 Zone

在開始實作之前，應該先了解有哪一些 Google Compute Engine 資源，可供使用。簡單來說，「區域」(Region) 是執行資源的特定地理位置，每個區域當中則會有一或多個「可用區」(Zone)。舉例來說，「us-west1」表示美國西部區域，在這個區域中有「us-west1-a、us-west1-b」 可用區。有關 Region 和 Zone 的詳細資訊，請參考 Regions and zones  |  Compute Engine Documentation  |  Google Cloud 官方文件。下表列出各個可用區和所屬區域：


透過下列指令，可以組態設定 Region 為「us-east1」，並將 Zone 設定為「us-east1-b」，組態設定完成後，記得透過指令確認組態設定是否套用生效。






部署 GKE 叢集

在每一個 GKE 叢集中，至少要包含一個「叢集主要執行個體」主機，或是數個稱為「叢集節點」的工作站主機。簡單來說，「叢集節點」就是 Compute Engine 虛擬機器 (VM) 執行個體，裡面會執行必要的 Kubernetes 程序後，才能順利加入 GKE 叢集中。值得注意的是，GKE 叢集名稱須以英文字母開頭，以英數字元結尾，並且長度不得超過 40 個半形字元。

執行下列指令部署 GKE 叢集，並於 GKE 叢集部署成後，取得驗證憑證後續才能與 GKE 叢集互動。

gcloud container clusters create --machine-type=e2-medium --zone=assigned_at_lab_start lab-cluster
gcloud container clusters get-credentials lab-cluster






部署應用程式至 GKE 叢集

完全 GKE 叢集部署作業並取得憑證後，現在可以將容器化的應用程式部署至 GKE 叢集。在本文實作環境中，將會在叢集中部署 hello-app 容器化應用程式。


在 GKE 叢集中，將會透過 Kubernetes 物件來建立及管理 GKE 叢集資源。Kubernetes 提供 Deployment 物件來部署無狀態的應用程式，例如，網路伺服器。而 Service 物件則會定義從網際網路存取應用程式時的規則和負載平衡。

首先，執行 kubectl create 指令，以便從 hello-app 容器映像檔建立新 Deployment hello-server。接著，執行 kubectl expose 指令，以便 Kubernetes Service 將會對外部流量公開應用程式的 Kubernetes 資源，例如，本文就是對應到 Port 8080。最後，透過 kubectl get 指令，檢查 hello-server Service 的運作情況，其中 EXTERNAL-IP 欄位將會從原本的 pending，變成如本文的 35.190.161.248 公用  IP 位址 (大約花費 1 分鐘左右) ，然後就可以開啟瀏覽器，嘗試看看能否存取到 hello-app 容器建立的網頁內容。

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0
kubectl expose deployment hello-server --type=LoadBalancer --port 8080
kubectl get service






刪除 GKE叢集

執行「gcloud container clusters delete lab-cluster 」指令，即可刪除 GKE 叢集，並且 GKE 叢集將會在幾分鐘之內刪除完畢，詳細資訊請參考 Deleting a cluster  |  Google Kubernetes Engine (GKE)  |  Google Cloud 官方文件。


同樣的，在完成實作練習結束前，記得確認是否通過所有的檢查程序，才能確保獲得這個實作課程的積分，往下一個實作前進。


結束前，再回顧一下怎麼建立和部署 GKE 叢集以及容器。







↧
↧

如何在 GCP 中建立 L4 或 L7 負載平衡機制 | Qwiklabs GSP007

July 8, 2023, 9:07 pm
$
0
0


簡介

在本文實作練習中，將會透過 Set Up Network and HTTP Load Balancers | Google Cloud Skills Boost主題，學習如何在 GCP 雲端環境中，了解「網路負載平衡器」(Network Load Balancer) 也就是 Layer 4 (TCP)層級的負載平衡器，以及「HTTP 負載平衡器」(HTTP Load Balancer) 也就是 Layer 7 (HTTP) 層級的負載平衡器，這兩者之間有什麼差異，以及如何為 Compute Engine 虛擬主機 (VM) 中執行的應用程式，組態設定使用 L4 (TCP) 或 L7 (HTTP) 負載平衡器。






啟用 Cloud Shell (gcloud)

本次實作時間給予 1.5 小時也是非常充裕。同樣的，啟動實作環境後，系統提供暫用的使用者帳號、密碼、Project ID…等資訊。


在 Cloud Console 畫面中，點選右上角圖示後，準備啟用 Cloud Shell (gcloud)，稍後也會使用到。簡單來說，Cloud Shell 是個已經載入了開發工具的極小型 VM 虛擬主機，並且提供 5 GB 儲存空間，以便管理人員可以透過 Cloud Shell 對 Google Cloud 資源進行存取等管理動作。

順利啟用 Cloud Shell 之後，可以嘗試執行「gcloud auth list」、「gcloud config list project」指令，了解目前運作環境的相關系統資訊。詳細資訊請參考 gcloud CLI overview  |  Google Cloud CLI Documentation 官方文件。






設定採用的 Region 和 Zone

在開始實作之前，應該先了解有哪一些 Google Compute Engine 資源，可供使用。簡單來說，「區域」(Region) 是執行資源的特定地理位置，每個區域當中則會有一或多個「可用區」(Zone)。舉例來說，「asia-east1」表示東亞區域，在這個區域中有「asia-east1-a、asia-east1-b、asia-east1-c」 可用區。有關 Region 和 Zone 的詳細資訊，請參考 Regions and zones  |  Compute Engine Documentation  |  Google Cloud 官方文件。下表列出各個可用區和所屬區域：


透過下列指令，可以組態設定 Region 為「us-west4」，並將 Zone 設定為「us-west4-c」，組態設定完成後，記得透過指令確認組態設定是否套用生效。






部署 3 台 VM 虛擬主機並擔任網頁伺服器

在實作負載平衡機制之前，先部署 3 台 Compute Engine VM 虛擬主機，並安裝 Apache 網頁伺服器服務。在下列指令中，可以看到部署的 VM 虛擬主機名稱為 www1、www2、www3。
gcloud compute instances create www1 \     --zone= \     --tags=network-lb-tag \     --machine-type=e2-medium \     --image-family=debian-11 \     --image-project=debian-cloud \     --metadata=startup-script='#!/bin/bash       apt-get update       apt-get install apache2 -y       service apache2 restart       echo "<h3>Web Server: www1</h3>" | tee /var/www/html/index.html'
gcloud compute instances create www2 \     --zone= \     --tags=network-lb-tag \     --machine-type=e2-medium \     --image-family=debian-11 \     --image-project=debian-cloud \     --metadata=startup-script='#!/bin/bash       apt-get update       apt-get install apache2 -y       service apache2 restart       echo "<h3>Web Server: www2</h3>" | tee /var/www/html/index.html'
gcloud compute instances create www3 \     --zone= \     --tags=network-lb-tag \     --machine-type=e2-medium \     --image-family=debian-11 \     --image-project=debian-cloud \     --metadata=startup-script='#!/bin/bash       apt-get update       apt-get install apache2 -y       service apache2 restart       echo "<h3>Web Server: www3</h3>" | tee /var/www/html/index.html'


接著，透過指令「gcloud compute firewall-rules create www-firewall-network-lb --target-tags network-lb-tag --allow tcp:80」新增 HTTP 流量，並允許傳送至這 3 台網頁伺服器的防火牆規則。然後執行「gcloud compute instances list」指令，列出 3 台網頁伺服器使用的 EXTERNAL_IP。


確認每台網頁伺服器的 Public IP 位址之後，使用 curl 指令確認網頁伺服器服務正常運作。






組態設定 Layer 4 (TCP) 負載平衡機制

在組態設定 L4 負載平衡服務時，VM 虛擬機器會收到預定傳送至您所設定的靜態外部 IP 位址的封包，並透過 Compute Engine 映像檔建立的執行個體會自動設定為處理這個 IP 位址。詳細資訊請參考 External passthrough Network Load Balancer overview  |  Load Balancing  |  Google Cloud 官方文件。

依序執行下列指令，建立 Layer 4 (TCP) 負載平衡機制：
  • 為 L4 負載平衡器建立靜態外部 IP 位址
    • gcloud compute addresses create network-lb-ip-1 --region  us-west4
  • 建立目標集區 www-pool 並啟用健康狀態檢查功能
    • gcloud compute target-pools create www-pool --region us-west4 --http-health-check basic-check
  • 將 3 台網頁伺服器加入集區 www-pool 當中
    • gcloud compute target-pools add-instances www-pool --instances www1,www2,www3
  • 新增 HTTP 封包轉送規則
    • gcloud compute forwarding-rules create www-rule --region us-west4 --ports 80 --address network-lb-ip-1 --target-pool www-pool





測試封包轉送規則是否正確運作

現在，L4 負載平衡服務已經設定完成。先執行「gcloud compute forwarding-rules describe www-rule --region us-west4」指令，確認 L4 負載平衡服務的 Public IP 位址，本文實作為「34.125.40.173」。

接著，定義名稱為 IPADDRESS 的變數，內容為「IPADDRESS=$(gcloud compute forwarding-rules describe www-rule --region us-west4 --format="json" | jq -r .IPAddress)」，定義完成後先執行「echo $IPADDRESS」，確認是否顯示為 L4 負載平衡服務的 Public IP 位址，然後使用 curl 指令「while true; do curl -m1 $IPADDRESS; done」存取 L4 負載平衡服務的 Public IP 位址。

此時，便可以看到隨機傳回 3 台網頁伺服器的 IP 位址，表示 L4 負載平衡服務封包轉送規則正確運作，按下 Ctrl + C 組合鍵即可停止測試。值得注意的是，若一開始發生回應失敗情況的話，請等待 30 秒之後再次測試。


事實上，也可以從 Google Console 管理介面，查看 L4 負載平衡服務的組態設定內容。








組態設定 Layer 7 (HTTP) 負載平衡機制

在 Google Cloud 運作架構中，Layer 7 (HTTP) 負載平衡機制，是由 GFE (Google Front End) 所負責。GFE 遍布全球各地，透過 Google 的全球網路和控制層互相搭配運作，所以管理人員可以設定網址規則，將部分網址轉送至某一組 VM 虛擬主機，並將其他網址轉送至其他 VM 虛擬主機。

GFE 一律會將網頁請求轉送至距離使用者最近的 VM 虛擬主機群組，但前提是該群組已經具備足夠的處理能力且適合該要求。倘若距離最近的群組處理能力不足，系統會將要求傳送至距離較近且具備充足處理能力的群組進行回應。因此，當管理人員需要組態設定 L7 負載平衡服務時，VM 虛擬主裝必須先屬於某個執行個體群組，然後群組內的 VM 虛擬主機必須運作網頁伺服器擔任後端伺服器才行。

首先，執行下列指令建立 Layer 7 (HTTP) 負載平衡機制範本，透過 MIGs (Managed Instance Groups)機制，管理人員可以自動調度資源、自動修復、區域 (多可用區) 部署以及自動更新等自動化 MIG 服務，讓工作負載具有可擴充性和高可用性。有關 MIGs 的詳細資訊請參考 Instance groups  |  Compute Engine Documentation  |  Google Cloud官方文件。

gcloud compute instance-templates create lb-backend-template \ --region=us-west4 \ --network=default \ --subnet=default \ --tags=allow-health-check \ --machine-type=e2-medium \ --image-family=debian-11 \ --image-project=debian-cloud \ --metadata=startup-script='#!/bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

依據上述建立的範本，建立名稱為「lb-backend-group」的 MIGs，並建立名稱為「fw-allow-health-check」的防火牆規則。其中，在 Ingress的部份允許來自 Google Cloud 健康狀態檢查系統的流量 (130.211.0.0/22 和 35.191.0.0/16)

gcloud compute instance-groups managed create lb-backend-group \ --template=lb-backend-template --size=2 --zone=us-west4
gcloud compute firewall-rules create fw-allow-health-check \ --network=default \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80


現在，請依序執行下列指令，建立 Layer 7 (HTTP) 負載平衡機制：
  • 組態設定全域靜態外部 IP 位址
    • gcloud compute addresses create lb-ipv4-1 --ip-version=IPV4 --global
    • gcloud compute addresses describe lb-ipv4-1 --format="get(address)" --global
  • 建立健康狀態檢查機制
    • gcloud compute health-checks create http http-basic-check --port 80
  • 建立後端服務
    • gcloud compute backend-services create web-backend-service --protocol=HTTP --port-name=http --health-checks=http-basic-check --global
  • 將 VM 虛擬主機加入至後端服務
    • gcloud compute backend-services add-backend web-backend-service --instance-group=lb-backend-group --instance-group-zone=us-west4-c --global
  • 建立網址對應，以便將連線請求轉送至後端服務
    • gcloud compute url-maps create web-map-http --default-service web-backend-service
  • 建立目標 HTTP Proxy 將連線請求轉送至網址對應
    • gcloud compute target-http-proxies create http-lb-proxy --url-map web-map-http
  • 建立全域轉送規則，將連線請求轉送至 HTTP Proxy
    • gcloud compute forwarding-rules create http-content-rule  --address=lb-ipv4-1 --global --target-http-proxy=http-lb-proxy --ports=80






測試封包轉送規則是否正確運作

現在，L7 負載平衡機制已經設定完成。同樣的，管理人員可以透過 Google Console 管理介面，查看 L7 負載平衡服務的組態設定內容。


查看 lb-backup-group後端服務的組態設定內容和運作狀態。


確認後端服務運作正常後，開啟瀏覽器進行測試，成功連線的話可以看到後端服務回應的主機是哪一台。


同樣的，在完成實作練習結束前，記得確認是否通過所有的檢查程序，才能確保獲得這個實作課程的積分。


由於這個實作是 Google Cloud Essentials 系列的最後一個實戰項目，所以系統回應你已經完成並取得 Google Cloud Essentials Badge。


↧

The TCP backlog setting of 511 cannot be enforced | Redis

July 12, 2023, 10:17 am
$
0
0


Question: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

在部署並啟動 Ansible AWX 時，其中的 awx_redis 容器在狀態的部份，一直呈現「Restarting」狀態而非「Up」，如下圖錯誤訊息


透過「docker logs awx_redis」指令，查看 awx_redis 容器的 Logs 內容時，發現一行關鍵錯誤訊息。
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.






Answer:

簡單來說，必須放大錯誤訊息中所說的「/proc/sys/net/core/somaxconn」系統預設值。所以，請至 docker-compose.yml 內，將 redis 容器的部份加上「sysctls: - net.core.somaxconn=65535」，然後再嘗試重新啟動即可。



    ↧
    Search

    Fatal: Can't initialize Background Jobs | Redis

    July 19, 2023, 10:21 am
    $
    0
    0


    Question: Fatal: Can't initialize Background Jobs.

    在上一篇文章中，看似解決 Redis 容器啟動問題。然而，解決 TCP backlog setting 問題後，卻又出現「Fatal: Can't initialize Background Jobs.」如下圖錯誤訊息






    Answer:

    簡單來說，這個問題似乎是 Redis 7.0.11 版本才會有，查看相關討論後改為採用「Redis 7.0.10」版本，便能順利啟動 Redis 容器並正常運作了。相關討論請參考：



    ↧

    vSphere 8 U1 亮點巡禮，試玩 vCP 組態設定檔機制 | 網管人第 210 期

    July 22, 2023, 8:52 pm
    $
    0
    0


    網管人雜誌

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





    本文目錄






    前言

    在 2022 年 10 月時 VMware 官方發佈最新 vSphere 8 版本，經過六個月之後，在 2023 年 4 月正式發佈 vSphere 8 Update 1 版本。管理人員應該可以發現，在最新的 vSphere 8 Update 1 版本中，並非僅是現有功能增強或臭蟲更新，而是包含了多項新增特色功能。在本文中，將為讀者逐一剖析各式亮眼特色功能，並且實戰演練最新發佈的 vCP 組態設定檔機制。





    vSphere 8 U1 亮眼特色功能

    新世代 vSphere 組態設定檔機制

    隨著企業和組織內各項專案和服務不斷成長，必須建立更多的 VM 虛擬主機和容器，以便提供高效能和高可用性的營運服務。因此，vSphere 叢集和 ESXi 節點主機數量也逐漸增加，然而維持 vSphere 叢集，與其下每台 ESXi 節點主機組態設定一致性，卻是一件令管理人員困擾的事情。

    雖然，在過去的 vSphere 版本中，針對此項管理需求推出 Host Profiles 機制，但是並無法完全解決管理人員的困擾。因此，在前一版 vSphere 8 版本中，推出「vSphere 組態設定檔」（vSphere Configuration Profiles，vCP）技術預覽版本，而在最新 vSphere 8 Update 1版本中則是正式推出完整版本（如圖 1 所示）。

    圖 1、新世代 vCP（vSphere Configuration Profiles）組態設定檔機制運作示意圖
    圖片來源： Introducing vSphere 8 Update 1 - VMware vSphere Blog

    簡單來說，雖然舊版的 Host Profiles與新式的 vSphere Configuration Profiles 機制有點類似，但新世代 vCP 組態設定檔機制支援度和範圍更全面，並且支援管理人員將現有 Host Profiles 機制，轉換為新世代的 vCP 組態設定檔機制，協助管理人員順利過渡到新式 vCP 組態設定檔機制。
    請注意! 目前 vCP 並不支援 VMware NSX 環境。



    vLCM 正式支援獨立主機

    在過去的 vSphere 版本中，vLCM 生命週期管理員機制，僅支援 vSphere 叢集和 ESXi 節點主機，並不支援尚未納入 vSphere 叢集的「獨立主機」（Standalone Host）。

    現在，最新的 vSphere 8 U1 版本中，vLCM 生命週期管理員機制透過 vSphere API，與 vCenter Server 管理平台進行溝通，進而支援獨立主機。因此，過往在 vSphere 叢集和 ESXi 節點主機環境中，進行映像檔、修復、檢查合規性……等工作任務，現在也都可以針對 ESXi 獨立主機進行套用（如圖 2 所示）。

    圖 2、vLCM 生命週期管理員機制正式支援獨立主機
    圖片來源： vSphere Lifecycle Manager for Standalone Hosts | VMware



    單個 GPU 支援不同工作負載

    在過去的 vSphere 版本中，ESXi 主機在組態設定 NVIDIA vGPU 工作負載時，必須使用相同的 vGPU 組態設定和記憶體大小。

    現在，最新的 vSphere 8 U1 版本中，支援同一個 GPU 當中，可以組態設定不同類型的 NVIDIA vGPU 工作負載，舉例來說，Profile-B 為針對 VDI 虛擬桌面的工作負載，Profile-C 為針對 ML 機械學習的工作負載，Profile-Q 為針對圖形密集型應用的工作負載（如圖 3 所示）。

    圖 3、單一 GPU 支援組態設定不同類型的 NVIDIA vGPU 工作負載
    圖片來源： Host different GPU workloads on a single GPU | VMware



    支援 NVIDIA NVSwitch

    在最新 vSphere 8 U1 版本中，全面支援 NVIDIA 最新推出的 NVSwitch 技術，當企業或組織需要多個 GPU 並行運算，例如，HPC、AI 深度學習、科學模擬……等便非常需要此項技術。

    主要原因在於，過去許多 AI 人工智慧和 HPC 高效能運算應用，受到硬體伺服器內部總傳輸速率的頻寬限制，而產生效能不彰的情況。因此，NVIDIA 建立名稱為 NVSwitch 的技術，允許最多「8 個 GPU」並且以極快的傳輸速度進行互相通訊。

    簡單來說，NVLink 和 NVSwitch 的主要區別在於，NVLink 是 NVSwitch 的後端協議，其中 NVLink Bridge 點對點連接，因為採用 Hopper 運作架構，能夠提供極高的傳輸頻寬連接多個 GPU，當連接「2 個 GPU」時可以提供雙向傳輸 450 GB/s傳輸頻寬，連接「4 個 GPU」時提供 900 GB/s 總傳輸頻寬。然而，當需要連接的 GPU 超過 4 個時，便需要改為採用 NVSwitch 技術（如圖 4 所示）。

    圖 4、NVIDIA NVLink 和 NVSwitch 運作架構示意圖
    圖片來源： Nvidia NVSwitch Support | VMware



    VM DirectPath I/O 正式支援熱插拔

    在過去的 vSphere 版本中，當 VM 虛擬主機需要新增或刪除 VM DirectPath IO 設備時，VM 虛擬主機必須處於「關機」（Power Off）狀態才行。

    現在，最新的 vSphere 8 U1 版本，在 vSphere 虛擬化層級中，已經支援 VM DirectPath IO 設備能夠「熱新增」（Hot-Add），以及「熱移除」（Hot-Remove）機制，只要搭配採用的底層硬體伺服器，通過 PCIe Native Surprise Hot Plug 認證，便能全面支援 VM DirectPath IO 設備，讓 VM 虛擬主機能夠在「運作中」（Power On）的情況下，熱新增和熱移除 VM DirectPath IO 設備，例如，NVMe 裝置（如圖 5 所示）。

    圖 5、VM DirectPath IO 設備支援熱新增和熱移除運作示意圖
    圖片來源： VM DirectPath I/O Hot-Plug for NVMe | VMware



    vSphere with Tanzu 再進化

    在 vSphere 8 U1 版本中，除了 VM 服務之外，當管理人員建立 vSphere with Tanzu 環境後，安裝和管理 Supervisor 服務時，也能夠順利使用 vSphere vDS 分佈式虛擬網路交換器的網路堆疊功能（如圖 6 所示），如此一來 DevOps 工程師，便能使用 API 在 Kubernetes 命名空間中，透過 Supervisors 建立容器並使用 vDS 網路堆疊功能。

    圖 6、Supervisor 服務支援使用 vSphere vDS 網路堆疊功能示意圖
    圖片來源： Supervisor Services with vSphere Distributed Switch | VMware

    此外，VM 服務已經增強並支援 VM 映像檔，以便 DevOps 工程師能夠建立和部署 Cloudinit 或 vAppConfig 映像檔。同時，DevOps 工程師現在可以使用 kubectl 指令，輕鬆存取他們所部署的 VM 虛擬主機 Console，以便進行遠端連線故障排除作業，並且 vSphere 管理人員無須指派和設定 vSphere Client 權限。

    因為，透過 kubectl 指令產生的 VM 網路控制台，將向執行指令的使用者提供一次性且限制 2 分鐘的 URL 網址，接著使用者便能夠透過該安全性 URL 網址，連線至 VM 網路控制台進行故障排除作業，即便該台 VM 虛擬主機已經無法使用 SSH 遠端連線（如圖 7 所示）。

    圖 7、透過 kubectl 產生安全性連線的 Web Console VM 網路控制台示意圖
    圖片來源： VM Consoles for DevOps | VMware



    支援 Okta 識別身份同盟機制

    在現今充滿各式網路威脅和惡意攻擊的時代，使用者身份驗證管理和多因素身份驗證機制，是目前網路安全中不可缺少的一環。

    從 vSphere 8 U1 版本開始，vCenter 管理平台的使用者身份驗證機制，正式支援 Okta 識別身份同盟機制，一旦導入後 vSphere 便永遠看不到使用者身份憑證，此舉能夠有效提升安全性以及合規性，並且運作方式和現今大部份的 Web 身份驗證服務一樣，當需要進行使用者身份驗證時便會重新導向至該服務，一旦通過身份驗證機制的審核後再重新導向回登入頁面並執行登入作業（如圖 8 所示）。

    圖 8、導入 Okta 使用者身份驗證同盟機制示意圖
    圖片來源： Okta Identity Federation for vCenter | VMware



    TPM 安全性和快速啟動完全整合

    在 vSphere 6.7 版本時，VMware 推出「ESXi 快速啟動」（ESXi Quick Boot）機制，能夠有效縮短 ESXi 主機重新啟動所花費的時間，然而整合 TPM 2.0 安全性機制的主機，在舊版 vSphere 運作環境中並不相容。

    現在，新版 vSphere 8 U1 版本，安裝並啟用 TPM 2.0 安全性機制的 ESXi 主機，已經和快速啟動機制完全相容，協助企業和組織在享有安全啟動和認證並檢測惡意軟體時，也能整合快速啟動機制有效縮短重新啟動時間（如圖 9 所示）。

    圖 9、整合 TPM 2.0 安全性和快速啟動機制操作畫面示意圖
    圖片來源： ESXi Quick Boot for Secure Systems | VMware



    Fault Tolerance 支援 vTPM 安全性機制

    在新世代的作業系統中，經常需要使用 TPM 安全性機制，因此當 VM 虛擬主機內的客體作業系統，需要使用 TPM 安全性機制時，能夠透過 vTPM 機制讓客體作業系統也擁有 TPM 安全性機制，例如，Windows 主機便能啟用 Device Guard、Credential Guard、Secure Boot、OS Attestation……等安全性機制。

    然而，在過去的 vSphere 版本中，啟用 FT（Fault Tolerance）的 VM 虛擬主機並不相容所以無法使用 vTPM。現在，從最新的 vSphere 8 U1 版本開始，啟用 FT 機制的 VM 虛擬主機，能夠完全相容使用 vTPM 安全性機制，讓 VM 虛擬主機層級的高可用性和高安全性兼具（如圖 10 所示）。

    圖 10、啟用 FT（Fault Tolerance）的 VM 虛擬主機也能使用 vTPM 操作示意圖
    圖片來源： vSphere Fault Tolerance with vTPM | VMware





    實戰演練 – 新世代 vSphere 組態設定檔機制

    在實戰小節中，將實戰演練最新 vSphere 8 Update 1 版本中，推出的「vSphere 組態設定檔」（vSphere Configuration Profiles，vCP）機制。值得注意的是，在實作之前管理人員必須確保運作環境符合下列需求：
    • vSphere 叢集中各項元件的生命週期，必須使用 vLCM（vSphere Lifecycle Manager）進行管理，例如，ESXi 主機映像檔、ESXi 版本、Firmware、驅動程式……等。
    • vSphere 叢集中的 ESXi 節點主機，必須採用 ESXi 8.0 或後續版本。
    • vSphere 叢集必須採用 Enterprise Plus 版本軟體授權。

    簡單來說，vCP 組態設定檔機制是透過 JSON 檔案的形式，儲存 vSphere 叢集中 ESXi 節點主機的組態設定內容，然後以參考主機為主要來源後，檢查 vSphere 叢集中其它 ESXi 節點主機的組態設定是否「合規」(Compliance)，倘若不符合時便可以執行「修復」（Remediate）作業，將不符合的部份套用建議設定後使其合規（如圖 11 所示）。

    圖 11、新世代 vCP 組態設定檔機制工作流程圖
    圖片來源： Configuration Management using vSphere Configuration Profiles | VMware



    建立新的 vSphere 叢集

    在本文實作環境中，採用最經典的應用情境，管理人員準備建立一個新的 vSphere 叢集，相關映像檔的生命週期由 vLCM 管理，而組態設定的部份則由 vCP 組態設定檔機制進行管理。

    管理人員登入後，在 vCenter Server 管理介面中，依序點選「vCenter Server > Datacenter > Actions > New Cluster」，在建立新的 vSphere 叢集對話窗中，設定 vSphere 叢集名稱為「vCP-Cluster」，並勾選「Manage all hosts in the cluster with a single image」選項，表示採用 vLCM 機制管理映像檔生命週期，勾選「Manage configuration at a cluster level」選項，表示針對 vSphere 叢集啟用 vCP 組態設定檔機制（如圖 12 所示）。
    請注意 !  vSphere 叢集無法僅啟用 vCP 組態設定檔機制。
    圖 12、建立新的 vSphere 叢集並啟用 vLCM 和 vCP 組態設定檔機制

    在選擇 ESXi 映像檔頁面中，請選擇屆時加入此 vSphere 叢集的 ESXi 節點主機版本。在本文實作環境中，採用最新的 ESXi 8.0 U1 版本（如圖 13 所示），值得注意的是，必須選擇至少 ESXi 8.0 版本，才能完整且正確支援 vCP 組態設定機制。後續，皆採用系統預設值，即可輕鬆建立啟用 vLCM 和 vCP 組態設定機制的 vSphere 叢集。

    圖 13、選擇採用的 ESXi 節點主機版本



    組態設定參考來源主機

    在本文實作環境中，共有三台 vSphere 主機，管理人員可以選擇其中一台擔任屆時的參考來源主機，本文選擇「vsphere8-n01」擔任屆時的參考主機。

    首先，組態設定參考主機使用 NTP Server 時間校對機制，請依序點選「vsphere8-n01 > Configure > System > Time Configuration > Add Service > Network Time Protocol」後，填入 NTP 時間伺服器的 IP 位址或 FQDN。

    接著，點選「vsphere8-n01 > Configure > Hardware > Overview > Power Management > Edit Power Policy」，將電力選項由預設的 Balanced 調整為「High performance」。

    回到 vSphere Cluster 層級後，點選「Configure > Desired State > Configuration > Settings >Extract from reference host」，在選擇參考主機頁面中，選擇剛才進行組態設定的「vsphere8-n01」主機（如圖 14 所示）。

    圖 14、選擇 vsphere8-n01 主機為組態設定參考來源主機

    在下一步 Download Configuration 頁面中，系統檢查作業完成後將會顯示組態設定檔案為準備下載狀態，按下 Download 鈕便會自動下載 JSON 檔案格式的組態設定檔。開啟 JSON 檔案格式後，可以看到內容有設定 NTP 時間校對伺服器的 IP 位址，以及組態設定電力選項為 High Performance，在最後「host-specific」區段，則是看到 vsphere8-n01 的組態設定內容，管理人員可以將這個區段複製後貼上，然後調整為 vsphere8-n02 的資訊（如圖 15 所示），其中 ESXi UUID 的內容，可以切換至「vsphere8-n02 > Configure > Hardware > Overview > System > Tag」內容得知。
    在 vsphere8-n01 組態設定內容最後的大括號結尾，記得加上「逗號」後，才將 vsphere8-n02 的內容貼上，屆時 JSON 檔才能正確執行匯入作業。
    圖 15、在 JSON 組態設定檔案內容中，加上 vsphere8-n02 主機資訊



    執行合規檢查作業

    完成 JSON 組態設定檔的修改動作後，回到 vCP-Cluster 層級中，依序點選「Configure > Desired State > Configuration > Import」，在彈出的匯入組態設定檔案視窗中，按下 Browse 鈕選擇剛才修改的 JSON 組態設定檔後，按下 Import 鈕進行匯入組態設定的動作。

    匯入動作執行後，系統將會自動進行「合規性」（Compliance）檢查作業，當匯入作業完成後，在 Settings 視窗中，可以點選「esx > system > system_time」項目，看到該項目的值為「Configured」，這就是剛才匯入參考來源主機 vsphere8-n01，組態設定 NTP 時間校對伺服器的部份（如圖 16 所示）。

    圖 16、查看匯入 JSON 組態設定檔內容和組態設定項目



    執行修復作業

    切換到 Compliance 頁籤中，可以看到 vsphere-n02主機目前的狀態並不符合規組態設定內容，例如，系統提示 Cluster value 在電源設定的部份為「High Performance」，但是 Host value 的部份則顯示空白或 Not Configured，表示尚未設定。

    此時，可以按下「Remediate」鈕，系統在彈出的 Remediate 視窗中，將會自動執行 Pre-check 作業，確認 Pre-check 工作程序執行完成後，按下 Next 鈕進入下一個程序。

    在 Review Impact 視窗中，點選 Host-Level Details 選項，可以看到 vsphere8-n02 稍後會執行的修復作業項目，例如，Power 電源組態設定、NTP 時間校對組態設定……等（如圖 17 所示），確認無誤後按下 Remediate 鈕便會進行修復作業。

    圖 17、查看 vsphere8-n02 稍後會執行的修復作業項目

    稍待一段時間後，系統將會顯示「Remediation completed successfully.」，表示修復作業已經執行完成，此時在 Compliance 視窗中，可以看到 vsphere8-n02 主機的組態設定已經合規（如圖 18 所示）。

    圖 18、修復作業完成 vsphere8-n02 節點主機已經合規



    vSphere 叢集新增 ESXi 節點主機

    隨著企業和組織的專案增加，勢必會在 vSphere 叢集中新增 ESXi 節點主機，以便承載更多的 VM 虛擬主機和容器等工作負載，透過 vCP 組態設定檔機制，可以讓加入的 ESXi 節點主機，能夠在最短的時間內進行合規檢查並套用設定，而非管理人員逐一手動設定和進行檢查作業。

    請在 vCenter 管理介面中，依序點選「vCP-Cluster > Actions > Add Host」項目，將 vsphere8-n03 節點主機加入。同樣的，當新的 ESXi 節點主機加入時，系統將自動進行合規性檢查作業，將會發現系統無法進行合規性檢查，主要是剛才匯入的 JSON 組態設定檔內容中，並沒有包括 vsphere8-n03 節點主機資訊，所以系統提示「1 hosts have unknown status」，有一台 ESXi 節點主機為未知狀態，並且錯誤訊息為「Check compliance is skipped」，表示省略合規檢查作業（如圖 19 所示）。

    圖 19、新加入的 ESXi 節點主機由於狀態未知所以略過合規性檢查

    此時，請同樣開啟剛才修改的 JSON 檔案資訊，將 vsphere8-n03 節點主機的 IP 位址和主機名稱加入（如圖 20 所示），並且記得前一段的 vsphere8-n02 節點主機內容中，最後一個大括號的結尾加上逗號，確保稍後 JSON 組態設定檔內容能順利匯入。
    管理人員也可以將 JSON 組態設定內容，複製後貼上至線上檢查 JSON 語法的網站，例如，jsonlint.com 進行內容正確性檢查。
    圖 20、修改 JSON 組態設定檔內容，加上 vsphere8-n03 節點主機資訊

    完成 JSON 組態設定檔的修改動作後，回到 vCP-Cluster 層級中，依序點選「Configure > Desired State > Configuration > Import」，在彈出的匯入組態設定檔案視窗中，按下 Browse 鈕選擇剛才修改的 JSON 組態設定檔後，按下 Import 鈕進行匯入組態設定的動作。

    同樣的，當匯入作業完成後，系統自動執行合規性檢查作業，切換到 Compliance 頁籤中，可以看到 vsphere-n03 節點主機目前的狀態並不符合規組態設定內容，例如，系統提示在 Setting 為 ntp_config 中 Cluster value 的部份為「Configured」，但是 Host value 的部份則顯示 Not Configured，表示 vsphere-n03 節點主機尚未設定 NTP 時間校對（如圖 21 所示）。

    圖 21、vsphere-n03 節點主機合規性檢查結果

    此外，也可以看到在安裝 vsphere-n03 節點主機時，由於人為疏忽而誤將 DNS 伺服器的 IP 位址「10.10.75.10」，設定錯誤為該台節點主機的 IP 位址「10.10.75.33」，在合規性檢查作業中也檢查出來，所以 vCP 組態設定檔機制，不僅能確保組態設定一致性，更能確保人為疏忽造成的組態設定錯誤。

    確認進行修復作業，請按下「Remediate」鈕，系統在彈出的 Remediate 視窗中，將會自動執行 Pre-check 作業，一旦 Pre-check 工作程序順利執行完成後，按下 Next 鈕進入下一個程序。在 Review Impact 視窗中，點選 Host-Level Details 選項，可以看到 vsphere8-n03 節點主機稍後執行的修復作業項目，和剛才修復 vsphere8-n02 節點主機稍有不同，包括，進入維護模式、Power 電源組態設定、NTP 時間校對組態設定、DNS 伺服器 IP 位址……等（如圖 22 所示），確認無誤後按下 Remediate 鈕便會進行修復作業。

    圖 22、查看 vsphere8-n03 節點主機準備執行的修復作業項目

    事實上，vCP 組態設定檔機制，將會視需要修復的作業項目採取相對應的動作，舉例來說，此次 vsphere8-n03 節點主機需要修復的項目，便需要將主機進入維護模式後才進行修改作業，並且在修改作業完成後自動離開維護模式，稍待一段時間修復作業後，在 Compliance 視窗中，可以看到 vsphere8-n03 主機的組態設定已經合規（如圖 23 所示）。

    圖 23、修復作業完成 vsphere8-n02 節點主機已經合規





    結語

    透過本文的深入剖析和實作演練後，相信管理人員除了理解最新 vSphere 8 U1 版本，推出哪些亮眼特色功能之外，也能經由實作 vCP 組態設定檔管理機制，幫助企業或組織在管理 vSphere 叢集和 ESXi 節點主機時，輕鬆確保 ESXi 主機間組態設定一致性，同時避免人為疏忽造成的組態設定錯誤和故障排除時間。
    ↧
    ↧

    如何在 Outlook 中設定 Mail Forwarding | Microsoft 365

    July 23, 2023, 1:45 am
    $
    0
    0


    簡介

    簡單來說，最近需要能即時查看個人 Microsoft Outlook 的郵件，但是我並不常登入 Microsoft Outlook 去查看郵件。因此，透過簡單 Outlook Mail Forwarding 組態設定，把寄送到個人 Microsoft Outlook 的郵件，直接轉送一份到我常用的 Mail 位址即可達到目的。





    組態設定 Outlook Mail Forwarding

    首先，登入到 Microsoft Outlook Web 介面後，依序點選「Settings > Mail > Forwarding」項目，然後勾選「Enable forwarding」選項，並在 Forward my email to: 欄位，填入希望接收 Microsoft Outlook 郵件的 E-Mail 位址。

    此外，因為怕漏接時還可以回來 Microsoft Outlook 查看郵件，所以勾選「Keep a copy of forwarded messages」選項。簡單來說，這個選項勾選後，除了幫你轉送郵件之外，也會在 Microsoft Outlook 留一份，不勾選的話就直接轉送不留在 Microsoft Outlook 內，到時漏信的話回來也看不到了。詳細資訊請參考 Turn on automatic forwarding in Outlook - Microsoft Support官方文件。






    測試 Mail Forwarding 機制

    組態設定完畢後，從 Gmail 寄送測試信件到 Microsoft Outlook。首先，可以看到 Microsoft Outlook 已經收到郵件。


    然後，切換到剛才組態設定轉送郵件的 E-Mail 位址 (本文測試是 Gmail)，除了看到剛才測試的郵件之外，剛好也有一封 MSN 台灣的信件轉送過來了。


    ↧

    unsafe legacy renegotiation disabled | VSCode

    July 23, 2023, 3:30 pm
    $
    0
    0


    Question: unsafe legacy renegotiation disabled

    最近，在幫朋友看他的 VSCode問題，當他嘗試要對 Repo 進行 Sync 動作時，便會出現如下圖所示的錯誤訊息。





    Answer:

    一開始直覺可能是密碼的部份有問題，後來經過重新組態設定 Repo 和帳號密碼…等動作都無效之後，朋友說他其實很久沒有開啟 VSCode 了。因此，索性建議他把那個有問題的 Repo 資料夾直接刪除，然後重新 Git Clone後，問題就解決了!
    ↧

    開源人年會 | COSCUP 2023

    July 24, 2023, 7:23 pm
    $
    0
    0


    活動簡介

    COSCUP 是由台灣開放原始碼社群聯合推動的年度研討會，起源於 2006 年，是台灣自由軟體運動 (FOSSM) 重要的推動者之一。活動包括有講座、攤位、社團同樂會等，除了邀請國際的重量級演講者之外，台灣本土的自由軟體推動者也經常在此發表演說，會議的發起人、工作人員與講者都是志願參與的志工。COSCUP 的宗旨在於提供一個聯結開放原始碼開發者、使用者與推廣者的平台。希望藉由每年一度的研討會，來推動自由及開放原始碼軟體 (FLOSS)。由於有許多贊助商及熱心捐助者，所有議程都是免費參加。

    開放原始碼 (Open source) 是在 1998 年出現的名詞，大家早已耳熟能詳。這種在網路上已經進行二、三十年的軟體開發模式之所以能成功，有許多原因。其中一個極為關鍵的因素，就是開發者與使用者的直接接觸。無屏障的交流加速了問題的回報和修補機制，而當這個機制被網路效應放大到極限時，Linus 定律就出現了：「臭蟲難逃眾人法眼」(With enough eyeballs, all bugs are shallow)，軟體品質因此顯著提昇。在開放原始碼的模式中，開發者和使用者中間的人不再是銷售員或客服，而是讓軟體更容易被接受的推廣者 (Promoters)，他們打包套件讓軟體更好裝、寫說明文件讓軟體更易學、辦推廣活動讓更多人接觸到好軟體、在網路上回答問題解決使用者的疑惑，而且不會把開發者藏在背後產生資訊的不對稱。

    開發者 (Coders)、使用者 (Users) 和推廣者 (Promoters) 是讓自由及開放原始碼軟體發光發熱的三大支柱，這個研討會就是專為這三種人舉辦的：你可以是 A 軟體的開發者、B 軟體的推廣者、C 軟體的使用者，不論你是已經踏入自由及開放原始碼軟體領域，還是一直站在門口不知如何入門，歡迎你來參加 COSCUP — Conference for Open Source Coders, Users and Promoters!





    活動資訊

    • 日期：   2023 年 7 月 29 - 30 日 (六、日)
    • 時間：   08:30 - 17:00
    • 地點：   國立臺灣科技大學
    • 議程：   大會議程表





    站長議程

    在本次大會中，站長共有二個議程分別是「Cloud Native - GKE 容器平台 101」，和大家聊聊 Google Cloud 的 GKE 容器平台，以及「Infrastructure Architect 養成技能樹」和大家分享職涯上個人的一些選擇、學習、試錯等心得。


    ↧
    Viewing all 591 articles
    Browse latest View live
    Search
    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>