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

vSAN HCI Mesh - Failed to run the remote datastore mount pre-checks

$
0
0


Question: Failed to run the remote datastore mount pre-checks

準備部署 vSAN HCI Mesh環境,在執行 Mount Remote Datastore 動作的 Check compatibility 階段時,卻出現「Failed to run the remote datastore mount pre-checks」錯誤訊息?




Answer:

簡單來說,這是因為 vSAN 超融合叢集中的 vSAN 節點主機「停用 IPv6」所導致的問題。雖然,vSAN HCI Mesh支援 IPv4 / IPv6 網路環境,並且本文的實作環境並不會用到 IPv6,但是這個 Mount Remote Datastore 操作步驟的 Check compatibility 階段,只要系統偵測到 vSAN 節點主機未啟用 IPv6 的話便會發生這個錯誤。

順利將 vSAN 超融合叢集中所有 vSAN 節點主機都「啟用 IPv6」之後,再次執行 Mount Remote Datastore 的 Check compatibility 階段便順利通過檢查作業,並且連接和掛載遠端 vSAN Datastore 成功。


在本文實作環境中,vSAN-Cluster-A 超融合叢集本地端為 vsanDatastore-A 儲存資源,而另一個 vSAN-Cluster-B 超融合叢集本地端為 vsanDatastore-B 儲存資源。如下圖所示,可以看到 vSAN-Cluster-A 超融合叢集,已經透過 vSAN HCI Mesh機制,順利連接和掛載 vSAN-Cluster-B超融合叢集本地端的 vsanDatastore-B儲存資源。



網管人 188 期 - vSphere 7 U2 新功能八大亮點

$
0
0


網管人雜誌

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





本文目錄






前言

隨著 VMware vSphere 7 在 2020 年 4 月正式發佈後,VMware 官方也同步將發佈週期調整為 6 個月,所以在 2020 年 10 月推出 vSphere 7 Update 1更新版本,並且在 2021 年 3 月正式發佈 vSphere 7 Update 2更新版本。

同樣的,雖然 vSphere 7 Update 2 看似為小版本更新,實際上此更新版本中無論在容器技術,或者是 AI 人工智慧和 ML 機器學習支援度方面大幅提升之外,更新增許多亮眼特色新功能,幫助企業和組織快速建構現代化應用程式的基礎架構平台。

VMworld 2020 大會上,VMware 和 NVIDIA 共同宣佈提供 AI-Ready Enterprise Platform(如圖 1 所示),透過端到端的雲端原生 AI 工具和框架套件,直接在 vSphere 虛擬化基礎架構上執行,同時搭配 NVIDIA GPUDirect RDMA 和 vSphere DRS 分佈式資源調度機制,最佳化 AI 基礎架構和工作負載,避免發生效能瓶頸的情況。

圖 1、AI-Ready Enterprise Platform 運作架構示意圖





vSphere 7 Update 2 亮眼特色功能

不斷增強的 vGPU 機制

在新版 vSphere 7 Update 2 版本中,除了支援最新一代 NVIDIA Ampere GPU之外,採用 A100 GPU時能夠提供比上一代多達 20 倍的效能,並且無論是 vSphere vMotion 和 vSphere DRS 機制,都能完整支援使用 NVIDIA MIG vGPU 機制的 VM 虛擬主機(如圖 2 所示),簡化 vSphere 基礎架構在擴充和版本升級時的難題。
對於運作 ML 機器學習工作負載來說,VM 虛擬主能夠透過 MIG(Multi-Instance GPUs)機制,大幅提升效能並有效縮短模型訓練時間。
圖 2、MIG(Multi-Instance GPUS)機制運作架構示意圖

事實上,在過去的 vSphere vGPU 版本中,主要採用「共享」GPU 資源的運作機制,所以當管理人員組態設定 VM 虛擬主機時,可以針對支援的 VM 虛擬主機指派適當的「Framebuffer Memory」,也就是 VM 虛擬主機屆時能夠共享使用的 GPU 記憶體資源,例如,為 VM 虛擬主機配置「5 GB」的 GPU 記憶體資源(如圖所示)。
在 NVIDIA GRID vGPU Profile 下拉式選單中,每個項目中結尾「c」前面的數字,便是指派多少 GPU 記憶體空間的 GB 數值。
圖 3、傳統 vGPU 共享機制,設定 VM 虛擬主機使用 5GB 的 GPU 記憶體資源

現在,新版的 MIG vGPU 採用硬體層級隔離機制,除了支援過去採用共享 GPU 資源的方式之外,也支援將多個或所有的 GPU 資源,全部指派給單一或特定的 VM 虛擬主機使用,例如,管理人員可以選擇「grid_a100-7-40c」項目(如圖 4 所示),讓 VM 虛擬主機可以獨佔整個 A100 的 GPU 資源,以便 VM 虛擬主機需要大量運算各種演算法和訓練模型時,能夠有效縮短整體時間。

圖 4、新式 MIG vGPU 機制,支援共享和獨佔 GPU 記憶體資源



vSphere with Tanzu 再增強

從 vSphere 7 Update2 版本開始,管理人員可以在 vSphere with Tanzu 的 Supervisor 叢集中,搭配 SEV-ES 安全加密虛擬化機制,建立具備高安全性的 vSphere Pod 和容器運作環境(如圖 5 所示)。當管理人員啟用和部署高安全性 vSphere Pod 之後,除了能夠防止 Hypervisor 直接存取 CPU 暫存器內的資訊之外,還能阻擋外部對 CPU 暫存器的惡意修改行為,有效保護 vSphere Pod 和容器內的機敏資訊。
啟用和部署高安全性 vSphere Pod 之後,在 vSphere Client 管理介面中,可以看到 Encryption mode 欄位顯示為「Confidential Compute」。
圖 5、在 vSphere with Tanzu 的 Supervisor 叢集中,啟用和部署高安全性 vSphere Pod

事實上,在 vSphere 7.0 版本推出時,vSphere with Tanzu 運作環境,必須搭配 NSX 部署整個 SDN 軟體定義網路才能運作,在 vSphere 7.0 Update 1 版本中,新增支援部署開放源始碼的 HAProxy,以便擔任外部負載平衡器的角色,讓沒有部署 NSX 的企業和組織,也能輕鬆建構 vSphere with Tanzu 運作環境。

雖然,HAProxy 提供企業和組織快速建構容器環境的負載平衡機制,然而對於正式營運環境來說還是有些限制。現在,最新的 vSphere 7.0 Update 2 版本,直接提供適合正式營運環境的 NSX ALB(Advanced Load Balancer)Essentials,同樣讓沒有部署 NSX 的企業和組織,也能為 vSphere with Tanzu 運作環境輕鬆建構負載平衡機制。
NSX ALB(Advanced Load Balancer),為 VMware 併購 Avi Networks 公司之後,演化而來的負載平衡技術,無須部署 NSX SDN 環境即可運作。
當管理人員部署 NSX ALB 負載平衡機制後,即可支援 Supervisor 叢集、TKG(Tanzu Kubernetes Grid)叢集,以透過分配一個虛擬 VIP 的方式,來存取 Supervisor 叢集中的 Kubernetes API,同時在嘗試存取 API 的流量時,會平均分佈至 Supervisor 叢集中的 3 個 Kubernetes Controller 。

此外,當開發人員建立 TKG 叢集時,系統也會自動分配新的 VIP,以便 VIP 與 TKG 叢集之前的流量也能進行負載平衡。最後,當開發人員部署應用程式至 TKG 叢集時,指定部署的類型為 LoadBalancer 的 Kubernetes 服務後,這些應用程式的 Kubernetes 服務便會自動分配到一個 VIP,讓開發人員可以存取應用程式,並自動達成應用程式的負載平衡機制(如圖 6 所示)。

圖 6、NSX ALB(Advanced Load Balancer)負載平衡運作架構示意圖



vMotion 自動偵測傳輸頻寬

vSphere vMotion 線上遷移機制,從一開始的 VC 1.0(ESX 2.0)時代開始亮相(如圖 7 所示)。在當時的 VMworld 大會上展示時,便讓企業和組織開始相信,虛擬化技術已經不僅僅限於使用在研究和測試環境,而是真正可以用於正式營運當中的技術。

圖 7、vSphere vMotion 線上遷移機制版本演進示意圖

隨著時代演變和技術的推進,vSphere vMotion 線上遷移機制的功能也不斷強化。在過去的 vSphere 版本中,由於企業和組織的資料中心內,主流的乙太網路傳輸速率為 10 GbE,即便採用新式的 25 GbE、40 GbE、50 GbE、100 GbE傳輸速率,只要手動搭配相關的組態設定後,即可在高頻寬的網路環境下發揮 vSphere vMotion 傳輸效能。

因為,在預設情況下,vMotion 採用「Single Stream」傳輸機制,並且使用的網路頻寬大約在「15 GbE」左右,所以採用 10 GbE 網路環境時,無須進行任何調整也能發揮 vMotion 最大傳輸效能,所以一旦網路環境超過 10 GbE 網路環境時,管理人員必須手動調整相關進階設定,例如,vMotion Stream、TCP/IP VMkernel、更新網路卡驅動程式……等,才能讓 vMotion 發揮最大傳輸效能。
每個 vMotion Single Stream,由三個部份所組成分別是 Completion helper、Crypto helper、Stream helper,其中佔用最多網路頻寬的便是 Stream helper
然而,企業和組織的資料中心內,10GbE 乙太網路傳輸速率已不在是主流,那麼每次新加入 ESXi 主機至 vSphere 叢集時,便還要記得手動去調整 vMotion 進階設定,才能 vMotion 發揮最大傳輸效能便太過麻煩。

因此,從 vSphere 7 Update 2 版本開始,預設啟用「vMotion 自動縮放」(vMotion Auto Scaling)機制(如圖 8 所示),當 ESXi 主機配置使用 vMotion 流量的網路卡頻寬超過 10 GbE 時,系統中的 vMotion 執行程序,將會在偵測網路卡頻寬後自動增加 vMotion Stream 數量,無須管理人員在手動調整 vMotion 進階組態設定。原則上,每 15 GbE網路頻寬會建立「1 個」Single Stream,所以不同的網路頻寬便會依序建立多個 vMotion Stream :
  • 25 GbE :2個 vMotion Stream 。
  • 40 GbE :3個 vMotion Stream 。
  • 50 GbE :4個 vMotion Stream 。
  • 100 GbE :7個 vMotion Stream 。
請注意,倘若之前手動組態設定 vMotion 進階設定,請確保恢復設定內容至預設值,以避免影響新版 vMotion Auto Scaling 機制的運作。
圖 8、vMotion Auto Scaling 運作架構示意圖



針對 AMD EPYC 工作負載最佳化

在新版 vSphere 7.0 U2 版本中,已經在 ESXi 虛擬化平台「CPU 調度程序」(CPU Scheduler)中,針對 AMD EPYC 處理器進行工作負載最佳化。簡單來說,新版中的 CPU 調度程序,會充份利用 AMD EPYC 處理器的 LLC(Last-Level Caches)、CCXs(Two Core Complexes)、CCDs(Core Complex Dies)機制,讓具備多 vCPU 的 VM 虛擬主機,能夠盡量使用同一個 CCD 的運算資源,進而達到 VM 虛擬主機工作負載最佳化的目的(如圖 9 所示)。

圖 9、新式 CPU 調度程序最佳化 VM 虛擬主機工作負載示意圖

根據 VMware 官方測試結果,新式 CPU 調度程序針對不同的工作負載,相較於前一版本 vSphere 7.0 U1 環境,在工作負載效能表示上都能有所提升(如圖 10 所示),最多甚至能夠提升至「50 %」的運作效能。

圖 10、新式 CPU 調度程序對於 TKG Cluster 工作負載效能提升情況



vTPM 正式支援 Linux 虛擬主機

TPM(Trusted Platform Module)機制,在現代化作業系統中已經是基本的必須功能,舉例來說,在微軟最新的 Windows 11 作業系統中,必須先確認硬體已經支援 TPM 機制才能進行安裝。

然而,在過去的 vSphere 版本中,雖然支援 vTPM(Virtual Trusted Platform Module)機制,讓 VM 虛擬主機工作負載能夠直接使用 TPM,但是僅限於採用 Windows 客體作業系統的 VM 虛擬主機。現在,最新版本的 vSphere 7.0 U2 版本,vTPM 機制正式支援採用 Linux 客體作業系統的 VM 虛擬主機(如圖 11 所示)。

圖 11、vTPM 運作架構示意圖



大量減少 ESXi 開機時間

在 vSphere 虛擬化基礎架構中,管理人員在日常維運中,無論是 ESXi 主機的安全性更新或版本升級,或者是 ESXi 發生硬體故障必須更換料件的情況下,都必須為 ESXi 主機進行重新啟動的動作。雖然,在 ESXi 主機上運作的 VM 虛擬主機,可以透過 vSphere vMotion/DRS 機制,線上遷移至其它 ESXi 主機繼續運作,但是 ESXi 主機的重新啟動和恢復時間倘若能夠縮短,對於整體維運時間和資料中心的 SLA 品質將能有效提升。

因此,在新版中新增支援「暫停至記憶體」(Suspend to Memory,STM)機制(如圖 12 所示)。簡單來說,管理人員可以透過原有的 Quick Boot 機制,搭配 STM 機制將無須線上遷移的 VM 虛擬主機,例如,測試或研發用途的 VM 虛擬主機,將其狀態儲存至 ESXi 虛擬化平台的記憶體當中,後續便能快速恢復 VM 虛擬主機的運作狀態。
請注意,STM 必須搭配 Quick Boot 機制才能運作,並且 vSphere 叢集必須啟用 vLCM 進行管理才行。詳細資訊請參考 VMware KB 52477知識庫文章內容。
圖 12、啟用 STM(Suspend to Memory)機制組態設定示意圖



vSphere DRS/HA 機制支援 Persistent Memory

管理人員對於 vSphere HA 高可用性機制應該不陌生。簡單來說,VM 虛擬主機工作負載能否被 vSphere HA 高可用性機制所保護,非常重要的前提在於,VM 虛擬主機的儲存資源必須存放於共享 Datastore 儲存資源中,因此發生災難事件時,vSphere 叢集中的另一台 ESXi 主機,才能接手共享 Datastore 儲存資源中 VM 虛擬主機的檔案,達成重新啟動 VM 虛擬主機的目的。

因此,在過去的 vSphere 版本中,倘若 VM 虛擬主機為了高儲存效能的考量下,例如,SAP HANA 虛擬主機,將 VM 虛擬主機儲存資源存放於 Persistent Memory 中,那麼此類型的 VM 虛擬主機便無法被 vSphere HA 高可用性機制所保護(如圖 13 所示)。

圖 13、舊版 vSphere 的 VM 虛擬主機,採用 Persistent Memory 時無法被 vSphere HA 機制保護

現在,最新版本的 vSphere,已經支援 VM 虛擬主機採用 Persistent Memory 時,仍然能夠被 vSphere HA 高可用性機制所保護(如圖 14 所示)。值得注意的是,VM 虛擬主機必須採用虛擬硬體版本「19」,並且不能使用 vPMemDisks 機制的 VM 虛擬主機,才能順利被 vSphere HA 高可用性機制所保護。

圖 14、新版 vSphere 的 VM 虛擬主機,採用 Persistent Memory 時也能被 vSphere HA 機制保護



VMware Tools 支援更全面

在最新版本中的 VMware Tools 支援許多特色功能,舉例來說,從 VMware Tools 11.2.0 版本開始,便會將 Carbon Black Plugin 一同安裝。另外,在 Windows 網域環境中非常重要的時間校對,也可以在安裝 VMware Tools 時,勾選「VMware Time Provider」項目進行安裝(如圖 15 所示),讓 Windows 虛擬主機只要透過 VMware Tools,也能夠輕鬆達成時間校對的目的。
請注意,VMware Time Provider 預設並不會安裝,必須在安裝 VMware Tools 時選擇 Custom 項目後,選擇「Will be installed on local hard dirve」項目才會進行安裝。
圖 15、安裝 VMware Tools 並一同安裝 VMware Time Provider





實戰 – VMware Tools GuestStore

在本文實戰演練小節中,將實作最新發佈的 VMware Tools GuestStore 機制,這是一項 VMware 官方針對眾多使用者提出的意見回饋功能請求,所實作出來讓 VM 虛擬主機能夠安全且直接存取資料的一種新方式。

簡單來說,在 vSphere 虛擬化基礎架構中運作的 VM 虛擬主機,在確認已經安裝 VMware Tools 之後,即可透過 VMware Tools GuestStore 機制,快速存取由管理人員集中管理和準備的各種類型檔案,例如,VMware Tools、代理程式、二進位檔案、組態設定檔 …… 等,達成安裝、更新、升級……等動作(如圖 16 所示)。
請注意,目前 GuestStore 僅支援 Windows 作業系統的 VM 虛擬主機,安裝 VMware Tools 的 Linux 作業系統虛擬主機暫不支援。此外,雖然支援各種類型檔案存放於 GuestStore 內,但是每個檔案大小必須「小於 512 MB」才行。
圖 16、GuestStore 運作架構示意圖



GuestStore 運作架構

在深入解析 VMware Tools GuestStore 主要元件和運作架構之前,管理人員必須了解 GuestStore 機制的重要運作概念,就是在 GuestStore 的運作框架中,系統並不會將集中管理的檔案內容主動「推送」(Push)給 VM 虛擬主機,而是 VM 虛擬主機的管理人員自行評估需求後,手動將存放於 GuestStore 內的檔案內容「拉取」(Pull)回 VM 虛擬主機內使用。

下列為 GuestStore 運作架構中(如圖 17 所示),各項主要運作元件的角色和功能說明:
  • GuestStore Client :運作在 Windows 虛擬主機內的執行程序,以便屆時存取 GuestStore 內容。
  • GuestStore Plugin :當 Windows 虛擬主機安裝 VMware Tools 時,系統便會一同安裝 GuestStore Plugin 至虛擬主機內,並負責處理 Windows 虛擬主機存取 GuestStore 的連線請求。同時,為了避免 VMX GuestStore Module 發生工作過載的情況,所以一次僅接受和處理一個連線請求,其它額外連線請求則必須排入等待佇列中,待一個連線請求消化後才處理另一個等待佇列中的連線請求。
  • VMX GuestStore Module :在 GuestStore 運作架構中擔任代理伺服器的角色,將 GuestStore Plugin 主機端傳送過來的連線請求,轉送給 GuestStore Daemon 系統服務進行處理。
  • GuestStore Daemon :這是在 vSphere 7.0 Update 2 版本中新增的系統服務,負責接收來自 VMX GuestStore Module 的連線請求之後,下載 GuestStore 內容後送回給 GuestStore Client 。同時,下載過的內容將會建立快取內容,以便其它 GuestStore Client 存取重複內容時,無須再次下載 GuestStore 內容,即可直接由快取內容回覆給 GuestStore Client 即可,有效提升回應速度和傳輸效率。
圖 17、VMware Tools GuestStore 主要元件和工作流程運作示意圖



組態設定 GuestStore Repository 路徑

了解 VMware Tools GuestStore 運作架構後,便開始著手為 ESXi 虛擬化平台,組態設定 GuestStore Repository 存放機制。首先,管理人員必須在 VM 虛擬主機,稍後所要存取的共用 Datastore 儲存資源中,建立資料夾並放置相關檔案。在本文實作環境中,於共用的 NFS Datastore 儲存資源中,建立名稱為「tools」的資料夾,並在「Edge」子目錄中,放置 Windows Server 預設未安裝的 Microsoft Edge 瀏覽器離線安裝檔案。
最新版本的 Windows Server 2022 作業系統,已經內建 Microsoft Edge 瀏覽器。
目前,因為 VMware Tools GuestStore 機制,尚未整合至 vSphere Client 管理介面中,所以管理人員必須為某一台 ESXi 主機開啟 TSM-SSH 服務後,透過 SSH Client 軟體登入該 ESXi 主機進行組態設定。值得注意的是,這台開啟 SSH 服務的 ESXi 主機,必須能夠存取準備分享的共用 Datastore 儲存資源才行。

順利登入 ESXi 主機後,首先確認共用資料夾路徑和相關檔案是否存在。在本文實作環境中,共用 NFS Datastore 的系統路徑為「/vmfs/volumes/NFS-Datastore/tools」,同時確認已經子目錄 Edge 內,存放好 Microsoft Edge 瀏覽器離線安裝檔案,確認無誤後請執行「esxcli system settings gueststore repository set --url」指令,搭配共用NFS Datastore 系統路徑「/vmfs/volumes/NFS-Datastore/tools」,建立 GuestStore Repository 分享路徑,接著執行「esxcli system settings gueststore repository get」指令,確認剛才建立的 GuestStore Repository 分享路徑是否已經套用生效(如圖 18 所示)。

圖 18、為共用 NFS Datastore 儲存資源,組態設定 GuestStore Repository 分享路徑



Windows 虛擬主機拉取檔案

當共用 NFS Datastore 儲存資源,組態設定 GuestStore Repository 機制完成後,便可以切換至 Windows 虛擬主機,準備從 GuestStore Repository 內拉取相關檔案至本機端。在開始拉取 GuestStore Repository 內相關檔案之前,必須確認 Windows 虛擬主機符合相關條件才行,否則稍後將會無法拉取相關檔案並遭遇錯誤。

首先,嘗試拉取 GuestStore Repository 內檔案的 Windows 虛擬主機,必須運作在 vSphere 7.0 U2或後續版本的 ESXi 虛擬化平台上,並且 Windows 虛擬主機必須安裝 VMware Tools 11.2.5或後續版本,屆時才能順利從 GuestStore Repository 拉取相關檔案。
本文實作的 Windows Server 2019 虛擬主機,安裝最新 VMware Tools 11.2.5(17337674)版本。
確認 Windows 虛擬主機符合條件後,即可開啟命令提示字元,並切換至「C:\Program Files\VMware\VMware Tools」資料夾,鍵入「VMwareToolboxCmd.exe gueststore getcontent」指令,搭配 GuestStore Repository 分享路徑中,所要拉取的檔案路徑「/Edge/MicrosoftEdgeEnterpriseX64.msi」,最後指定拉取的檔案,要存放於 Windows 虛擬主機的本機路徑「C:\tmp\Edge64.msi」,確認無誤後按下 Enter 鍵,即可立即從 GuestStore Repository 分享路徑中,拉取 Windows 虛擬主機所需的檔案(如圖 19 所示)。
倘若指定的 GuestStore Repository 路徑錯誤或檔案不存在時,系統將會出現「getcontent failed,GuestStore client library error : Content not found」的錯誤訊息。
圖 19、Windows 虛擬主機,順利從 GuestStore Repository 內拉取需要的檔案

實作至此,可能有許多管理人員會有困惑,這樣存取檔案的方式與傳統 NAS 存取方式相較之下,似乎也沒有比較便利或安全啊 ?事實上,當 Windows 虛擬主機執行指令,嘗試拉取 GuestStore Repository 內的相關檔案時,並非像存取傳統 NAS 儲存資源採用乙太網路傳輸的方式,而是透過 Windows 虛擬主機內的 VMware Tools,直接和底層的 ESXi 虛擬化平台溝通並執行拉取檔案的動作。

因此,管理人員可以再次進行測試,在 Windows 虛擬主機再次拉取 GuestStore Repository 內相關檔案之前,先將 Windows 虛擬主機的網路卡進行停用,確認無法透過乙太網路進行資料傳輸後,再次執行拉取 GuestStore Repository 路徑中檔案的動作,管理人員可以發現仍然能夠順利拉取檔案(如圖 20 所示)。

圖 20、即便網路卡停用,仍然能夠拉取 GuestStore Repository 路徑中的檔案

透過上述實作演練後,管理人員應該可以理解,為何說 VMware Tools GuestStore 機制,是一種安全且直接存取資料的新方式。因為,這樣的應用方式在某些極度封閉且強調高安全性的運作環境中,能夠在持續封閉且不失高安全性的情況下,同時又能達到交換檔案的一種新方式。
後續,管理人員可以在 ESXi 主機中查看「/var/logs/gstored.log」,在 Windows 虛擬主機中查看「C:\Windows\Temp\vmware-vmsvc-SYSTEM.log」,以便觀察 GuestStore 運作和檔案存取的日誌內容。





結語

透過本文的深入剖析和實作演練後,相信讀者已經了解最新發佈的 vSphere 7.0 Update 2 版本中,有哪些亮眼新功能和運作架構及原理,讓企業和組織可以評估哪些功能適合導入至新專案當中。此外,帶領讀者實作演練新版本當中,最新發佈的 VMware Tools GuestStore 功能,提供給 VM 虛擬主機安全且直接存取資料的方式,讓企業和組織內部資料中心中某些極度封閉且高安全性的環境,能夠在不失高安全性的情況下又能達到交換檔案的目的。

網管人 189 期 - 架設微軟 RDS 遠端桌面,速成遠距辦公友善環境

$
0
0


網管人雜誌

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





本文目錄






前言

隨著 COVID-19 疫情反覆不斷,企業和組織必須準備讓員工隨時能夠遠端工作的作業環境,以便因應 COVID-19 疫情升溫,員工必須分流上班或是全員「在家工作」(Work from home)的情況。

相信對於 IT 預算和資訊人員充足的中大型企業來說(如圖 1 所示),建構員工遠端工作環境並不難,甚至早已經建置完成以便滿足,IT 資訊人員在例假日或休假時期,必須遠端登入和臨時支援相關問題的查修和故障排除等需求。

圖 1、中大型企業建構的高可用性 RDS 遠端桌面服務運作架構示意圖

然而,對於 IT 預算和資訊人員較為不足的小型企業來說,有沒有簡單快速的方式,便能建構出讓員工能夠遠端工作的環境? 有的。在本文中,將會深入剖析和實戰演練,如何透過 Microsoft「遠端桌面服務」(Remote Desktop Service,RDS)技術,快速建構遠端桌面工作階段的運作環境,讓在家工作的員工只要撥上企業和組織的 VPN 環境之後,即可輕鬆獲得如同在辦公室一樣的工作環境。





RDS 部署模式和角色

在 Microsoft RDS 遠端桌面服務中,共有兩種標準的運作架構分別是「基本部署」(Basic Deployment)和「高可用性部署」(Highly Available Deployment)(如圖 2 所示)。採用基本部署的運作架構,管理人員只要建立承載 RDS 運作環境的基礎即可,倘若企業和組織需要確保 RDS 遠端桌面服務具備高可用性,那麼相關基礎架構的角色至少必須二個以便互相備援之外,相關角色例如 RDSH 連線階段伺服器,可能必須更多台以便達到負載平衡的目的。

圖 2、Microsoft RDS 遠端桌面服務,基本部署和高可用性部署示意圖

在 RDS 遠端桌面服務運作架構中,共有五個主要的運作角色,分別負責不同的工作任務:
  • 遠端桌面工作階段主機:RDSH(Remote Desktop Session Host),保留使用者工作階段的應用程式和桌面連線,支援二種運作模式分別是 VM 虛擬主機模式(VM Based),和連線階段模式(Session Based)
  • 遠端桌面連線代理人:RDCB(Remote Desktop Connection Broker),當使用者建立遠端桌面工作階段時,負責將這些使用者連線工作階段負載平衡至不同的 RDSH 主機。原則上,每台 RDCB 主機可以同時處理超過 10,000 個使用者連線工作階段。
  • 遠端桌面閘道:RDGW(Remote Desktop GateWay),當使用者連線必須從外部網際網路,連線至內部 RDSH 主機時才需要建置。
  • 遠端桌面 Web 存取: RDWeb(Remote Desktop Web access),透過入口網站的方式驗證使用者身份之後,提供使用者存取桌面和相關應用程式。
  • 遠端桌面授權:RDLS(Remote Desktop Licensing Server),提供 RDS 遠端桌面服務存取使用權。





實戰 – RDS 遠端桌面服務

在本文實作環境中,著重於建構出滿足小型企業需求的遠端桌面服務。因此,除了網域控制站和網域環境「lab.weithenn.org」之外,搭配一台 Windows Server 2019 主機,透過「工作階段型虛擬化」(Session-Based Virtualization)機制,建構出符合小型企業工作需求的多重工作階段運作環境。



快速部署 RDS 遠端桌面服務

在本文實作環境中,我們將 RDS 遠端桌面服務 RDSH/RDCB/RDWeb這三個角色,安裝於一台 Windows Server 2019 主機中(後續簡稱為 RDS 主機),以便快速和最小化建構出工作階段型虛擬化運作環境。
請注意,最小化建構 RDS 遠端桌面服務,並不具備高可用性和災難快速復原機制。

請在 RDS 主機中,開啟伺服器管理員後依序點選「Manage > Add Roles and Features」,在彈出視窗中 Select installation tyep 階段時,請選擇「Remote Desktop Services installation」項目,以便部署工作階段型桌面環境(如圖 3 所示)。

圖 3、準備部署工作階段型桌面環境

在 Select deployment type 部署階段時,預設值為 Standard deployment 項目,適合用於部署中大型 RDS 虛擬桌面運作架構,將 RDS 遠端桌面服務的角色分別安裝在不同的伺服器。在本文中,請改為選擇「Quick Start」項目(如圖 4 所示),將 RDSH/RDCB/RDWeb 這三個 RDS 遠端桌面服務角色,安裝在同一台 RDS 主機中。
系統將會依據管理人員選擇不同的部署類型,自動化改變部署階段的安裝流程。管理人員,可以在選擇不同部署項目時,仔細觀察互動視窗左方部署階段項目的變化。
圖 4、準備將 RDSH/RDCB/RDWeb 遠端桌面服務角色,安裝在同一台主機中

在 Select deployment type 部署階段時,當選擇 Virtual machine-based desktop deployment 項目時,必須確保 RDS 伺服器主機已經啟用硬體輔助虛擬化,以及支援運作 Hyper-V 虛擬化運作環境,才能順利部署以 VM 虛擬主機為主的遠端桌面服務運作架構。在本文中,請選擇「Session-based desktop deployment」項目,部署工作階段型桌面環境。

在 Select a server 部署階段時,請選擇要為哪台主機部署 RDSH/RDCB/RDWeb 遠端桌面服務角色,在本文中選擇「RDS.lab.weithenn.org」主機。在 Confirm selections 部署確認視窗中,系統再次詢問是否要同時部署多個遠端桌面服務角色在一台主機中,並請勾選下方「Restart the destination server automatically if required」項目後,才能按下「Deploy」鈕執行部署的動作。
當系統部署 RDSH 遠端桌面服務角色後,便會自動重新啟動主機,並且在重新啟動完成後自動接續安裝 RDCB 和 RDWeb 角色。

當 RDS 主機部署完成自動重新啟動後,系統在自動接續部署 RDCB 和 RDWeb 角色的期間,在 RDS 主機右下方資訊列,將會彈出 RDS 遠端桌面服務試用期間通知資訊,告知 IT 管理人員系統開始倒數「120 天」的 RDS 遠端桌面服務試用期(如圖 5 所示)。後續,企業和組織只要購買 RDS 遠端桌面授權,並建置 RDLS 授權伺服器角色,即可持續使用 RDS 遠端桌面服務。

圖 5、系統開始倒數 120 天的 RDS 遠端桌面服務試用期

後續,管理人員可以透過「Invoke-WmiMethod」的 PowerShell 指令,搭配查詢「GetGracePeriodDays」內容,即可看到 RDS 遠端桌面服務試用期間還剩下多少天(如圖 6 所示)。
倘若,管理人員已經建置 RDLS 授權伺服器後才查詢,則查詢結果中的 DaysLeft 天數欄位將為 0 天
圖 6、透過 PowerShell 指令查詢 RDS 遠端桌面服務試用期間還剩下多少天

經過一段部署時間後,系統顯示成功部署 RDSH/RDCB/RDWeb 遠端桌面服務角色,並且在視窗下方顯示 RDWeb 入口網站伺服器的 URL 網址,本文實作環境為「https://RDS.lab.weithenn.org/rdweb」(如圖 7 所示)。

圖 7、成功部署 RDSH/RDCB/RDWeb 遠端桌面服務角色

現在,即可開啟瀏覽器在網址列鍵入「https://rds.lab.weithenn.org/rdweb」,即可看到 RDWeb 入口網站伺服器的登入頁面(如圖 8 所示)。預設情況下,在網域環境中屬於「Domain Users」群組的成員,都可以登入 RDWeb 入口網站伺服器,後續管理人員可以調整 Collections 內容中的 User Group 設定,便可組態設定可進行登入的群組和使用者帳號。

圖 8、預設 Domain Users 群組的成員即可登入

IT 管理人員只要依序點選「Server Manager > Remote Desktop Services > Overview」,即可看到簡易的 RDS 遠端桌面服務部署示意圖,以及部署 RDS 角色的主機清單(如圖 9 所示)。
由於採用 Quick Start 部署項目,所以系統將會自動新增「QuickSessionCollection」。倘若,採用 Standard deployment 部署項目,則必須由 IT 管理人員依照需求手動建立 Collections 。
圖 9、查看 RDS 遠端桌面服務部署示意圖和主機清單



管理和組態設定 RDS 登入環境

在 RDS 遠端桌面服務運作架構中,組態設定使用者 RDS 登入環境的機制稱為「Collections」,由於部署時採用「Quick Start」項目,所以系統會自動建立「QuickSessionCollection」項目,在 QuickSessionCollection 項目內共有四大區塊,管理人員可以依照相關需求進行調整。

首先,請依序點選「Server Manager > Remote Desktop Services > Collections > QuickSessionCollection > Properties > Tasks > Edit Properties」項目,詳細的組態設定項目和說明如下:
  • General:管理人員可以調整此 Collections 的名稱,以便符合公司原有的命名規則。
  • User Groups:組態設定哪些使用者帳號或群組(如圖 10 所示),可以透過登入 RDWeb 入口網站伺服器,載入此 Collections 內的組態設定值和運作環境。
  • Session:組態設定和管理使用者連線資訊,舉例來說,透過 Idle Session Limit 組態設定值,可以定義使用者連線階段「閒置」(Idle)時間,超過組態設定值之後便強制中斷該使用者連線階段。
  • Security:組態設定使用者連線階段的安全性層級和加密層級。
  • Load Balancing:顯示此 Collections 有多少台 RDSH 連線階段伺服器,並且設定每台伺服器的負載平衡權重,以及最大可承載的使用者連線階段數值。
  • Client Settings:組態設定使用者連線階段重新導向項目,例如,勾選 Clipboard 的話,則允許使用者可以在連線 RDSH 連線階段伺服器之後,仍然能夠使用剪貼薄功能。
  • User Profile Disks:預設情況下,登入成功的使用者連線階段,採用的是暫存的使用者設定檔,管理人員可以結合儲存設備,並且啟用 UPD(User Profile Disks)機制,將使用者連線階段的使用者設定檔,重新導向存放至儲存設備當中,並且能夠設定使用者設定檔的最大使用儲存空間。
圖 10、組態設定 Session Collection 相關內容

在 RemoteApp Programs 區塊中,預設建立的 QuickSessionCollection,已經自動發佈三個應用程式分別是 Calculator、Paint、WordPad,管理人員可以選擇「Tasks > Publish RemoteApp Programs」,額外選擇安裝在 RDS 主機當中的應用程式,舉例來說,公司若有 HR 人資系統、CRM 顧客關係管理系統、ERP 進銷存系統 …… 等能夠安裝在 RDS 主機上時,便能透過 RDS 遠端桌面服務當中的 RemoteApp 應用程式虛擬化技術,讓使用者無須在個人電腦中安裝應用程式即可使用。

那麼,使用者該如何判斷執行的應用程式,是在本機電腦中還是遠端 RDS 主機中的應用程式呢? 當使用者執行的是 RemoteApp 應用程式時,那麼該應用程式的圖示便會多出遠端執行的圖示,舉例來說,使用者登入 RDWeb 入口網站執行小畫家應用程式,可以看到工作列中的小畫家應用程式多出了遠端執行的圖示(如圖 11 所示)。

圖 11、透過 RemoteApp 應用程式虛擬化技術執行小畫家應用程式

在 Host Servers 區塊中,管理人員可以查看,目前有多少台 RDSH 連線階段伺服器,點選「Tasks > Add RD Session Host Servers」或「Tasks > Remove RD Session Host Servers」時,可以在此 Collections 當中加入或移除 RDSH 連線階段伺服器。

此外,當 RDSH 連線階段伺服器需要關機或重新啟動進行維護時,例如,更換損壞的記憶體或主機板必須關機時,或者是進行 Windows Update 安全性更新必須重新啟動時,管理人員可以點選欲進行維護的 RDSH 連線階段伺服器,在右鍵選單中選擇「Do not allow new connections」(如圖 12 所示),那麼該台 RDSH 連線階段伺服器,便不會接受新的使用者連線階段,便可以準備進行關機或重新啟動的維護作業。
請注意,雖然不會接受新的使用者連線階段,但是舊有已經連線的使用者連線階段仍然存在,可以搭配下個組態設定區塊,通知使用者改為採用別台 RDSH 連線階段伺服器,或強制登出或中斷使用者連線階段,以便進行維護作業。
圖 12、管理和組態設定 RDSH 連線階段伺服器

最後,在 Connections 區塊中,管理人員除了能夠即時查看哪些使用者,登入哪一台 RDSH 連線階段伺服器和連線資訊之外,在每個使用者連線階段的右鍵選單中,具有四種管理使用者連線階段功能:
  • Disconnect:強制將指定的使用者連線階段進行「中斷」(Disconnect)作業。
  • Send Message:針對指定的使用者連線階段傳送系統維護訊息,例如,告知正在連線的使用者,RDSH 連線階段伺服器因為安全性更新的關係,將於 10 分鐘後重新啟動主機(如圖 13 所示)。
  • Shadown:倘若使用者連線階段操作過程需要管理人員幫忙時,管理人員可以透過 Shadow 選項中的「Remote Session - View」,即時觀看使用者連線階段的操作畫面,甚至選擇「Remote Session - Control」項目,還能遠端控制使用者連線階段的操作畫面,幫助使用者進行操作或故障排除。
  • Log Off:強制將指定的使用者連線階段進行「登出」(Log Off)作業。
圖 13、針對指定的使用者連線階段傳送系統維護訊息



部署 RDWeb 入口網站 SSL 憑證

預設情況下,系統會為 RDWeb 入口網站建立「六個月」的自簽 SSL 憑證(如圖 14 所示)。管理人員可以視企業或組織的需求,為 RDWeb 入口網站建立正式簽署的 SSL 憑證。在本文實作環境中,將透過 DC 網域控制站建立 Enterprise Root CA 後,在由 RDWeb 入口網站透過 IIS Manager 產生 SSL 憑證申請後,部署網域內部使用的簽署 SSL 憑證。

圖 14、系統預設將為 RDWeb 入口網站建立六個月的自簽 SSL 憑證

首先,確認在 DC 網域控制站當中,已經透過 GPO 群組原則機制,將 Root CA 推送到網域環境中的每台成員伺服器中,舉例來說,管理人員可以登入 RDS 主機中,執行「gpupdate /force」強制重新載入 GPO 群組原則後,查看憑證中的「Trusted Root Certification Authorities > Certificates」項目,確認是否已存在 Root CA(如圖 15 所示)。
倘若,沒有看到 Root CA 的話,請再次執行 gpupdate /force 指令後,重新啟動主機以便再次載入 GPO 群組原則中的電腦設定項目。
圖 15、確認 Root CA 已透過 GPO 群組原則,推送至網域環境中的所有成員伺服器

請登入 RDWeb 入口網站伺服器(本文為 RDS 主機),開啟 IIS Manager 之後,依序點選「Connections > RDS > IIS > Server Certificates」項目後,可以看到目前採用的六個月效期自簽 SSL 憑證。

請按下右方「Actions > Create Domain Certificate」項目,在彈出的 Create Certificate 視窗中,Common name 欄位請正確填入 RDWeb 入口網站伺服器的 FQDN,本文實作環境為「rds.lab.weithenn.org」,在 Online Certification Authority 頁面中,請按下 Specify Online Certification Authority 中的 Select 鈕,選擇剛才已經透過 GPO 群組原則匯入的網域環境 Root CA,並在下方的 Friendly name 欄位填入識別名稱,本文實作填入「Weithenn Lab – RDS SSL Certificate」後,按下 Finish 鈕完成網域環境的 SSL 簽署憑證(如圖 16 所示)。
透過此方式建立的網域環境 SSL 簽署憑證有效期間為「2 年」。

圖 16、完成 RDWeb 入口網站伺服器的網域環境 SSL 簽署憑證

請點選剛才建立的網域環境 SSL 簽署憑證,按下右方的「Actions > Export」,選擇將 SSL 簽署憑證匯出為 .pfx 格式(本文實作為 rds_ssl.pfx),並鍵入二次保護此 .pfx 格式憑證的密碼後,按下 OK 鈕執行憑證匯出作業。

切換回伺服器管理員伺服中,點選「Deployment Overview > Tasks > Edit Deployment Properties」項目,在彈出的 Configure the deployment 視窗中點選 Certificates 項目,可以看到目前 RDCB 和 RDWeb 的憑證狀態都是「未設定」(Not Configured),點選下方的「Select existing certificate」鈕,選擇剛才匯出的 rds_ssl.pfx 憑證,並鍵入保護 .pfx 格式憑證的密碼後,按下 OK 鈕執行憑證匯入作業(如圖 17 所示)。
由於,本文實作環境 RDCB 與 RDWeb 為同一台主機,因此匯出的 rds_ssl.pfx 憑證也可以匯入 RDCB 項目。
圖 17、將匯出的 rds_ssl.pfx 憑證匯入至 RDWeb 入口網站角色中

同樣的,再次透過 GPO 群組原則,將「rds.lab.weithenn.org」憑證推送至網域環境中的所有成員伺服器後,再次於客戶端的主機瀏覽 RDWeb 入口網站伺服器時,便會發現網址列從原本的「Not Secure」,轉變為綠色鎖頭並且為「Connection is secure」狀態,查看憑證資訊即可看到,該憑證是由 Root CA 簽發給 RDS 主機(如圖 18 所示),並且有效期間為二年

圖 18、成功透過 GPO 群組原則推送 RDWeb 入口網站伺服器憑證



RDWeb 入口網站重新導向

有維護過 IIS 網站伺服器的管理人員,應該已經發現到一個問題,倘若使用者鍵入的 RDWeb 入口網站伺服器網址,不是預設登入畫面的「https://rds.lab.weithenn.org/rdweb」網址,而是「https://rds.lab.weithenn.org/」網址時,系統並未自動重新導向至 RDWeb 入口網站頁面,而是顯示 IIS 網站伺服器的預設歡迎頁面(如圖 19 所示)。

圖 19、未自動重新導向至 RDWeb 入口網站頁面,而是 IIS 預設歡迎頁面

請至 RDWeb 入口網站伺服器開啟 IIS Manager,依序點選「Connections > RDS > Sites > Default Web Site > IIS > HTTP Redirect」項目後,首先勾選「Redirect requests to this destination」項目,並在下方鍵入「RDWeb/Pages」重新導向的路徑,接著在 Redirect Behavior 區塊中,勾選「Only redirect requests to content in this directory(not subdirectories)」項目(如圖 20 所示),最後按下右方的「Actions > Apply」,當系統出現「The changes have been successfully saved.」資訊時,表示重新導向的組態設定已經套用生效。

圖 20、組態設定 IIS 預設網址重新導向至 RDWeb 入口網站

現在,當使用者鍵入「https://rds.lab.weithenn.org/」網址時,IIS 網站伺服器將會執行自動重新導向的動作,將使用者重新導向至 RDWeb 入口網站頁面「https://rds.lab.weithenn.org/rdweb」,而非先前因為未執行自動重新導向而看到的 IIS 預設歡迎頁面。



RDWeb 入口網站客製化設定

IT 管理人員可以依照公司需求,客製化設定 RDWeb 入口網站的文字和圖示。預設情況下,RDWeb 入口網站的左上方首要橫幅文字為「Work Resources」,管理人員可以登入至 RDCB 伺服器中(本文為 RDS 主機),執行「Set-RDWorkspace -Name "Weithenn Lab – RDS Portal"」的 PowerShell 指令,即可更改左上方首要橫幅文字的顯示內容(如圖 21 所示)。

圖 21、變更 RDWeb 入口網站的左上方橫幅文字內容

預設情況下,RDWeb 入口網站右上方橫幅文字為「RD Web Access」,而左上方次要橫幅文字為「RemoteApp and Desktop Connection」,管理人員可以登入至 RDWeb 入口網站伺服器中(本文為 RDS 主機),編輯「%windir%\web\rdweb\pages\<language-code>」資料夾內的「RDWAStrings.xml」檔案內容,修改第 10 行「HeadingRDWA」和第 11 行「HeadingApplicationName」內容即可(如圖 22 所示)。

圖 22、修改 RDWeb 入口網站右上方和左上方次要橫幅文字

修改完成並儲存後,切換至使用者端瀏覽器重新整理頁面,即可看到更改後 RDWeb 入口網站右上方和左上方次要橫幅文字。本文實作中,將右上方文字更改為「RDS Portal」,而左上方次要橫幅文字修改為「RemoteApp for HR, CRM, and ERP systems.」(如圖 23 所示)。

圖 23、成功修改 RDWeb 入口網站右上方和左上方次要橫幅文字

在同樣的資料夾路徑中,管理人員可以修改「login.aspx」檔案內容中,第 43 行「L_TSWATimeoutLabel_Text」內容,即可達到修改 RDWeb 入口網站下方一長串的說明文字的目的(如圖 24 所示)。

圖 24、修改 RDWeb 入口網站下方一長串的說明文字

此外,我們也可以將 RDWeb 入口網站中的 Logo 圖案,更換為企業或組織的 Logo 圖案。首先,請將企業或組織的 Logo 圖案儲存名稱為「logo_02.png」之後,複製到 RDWeb 入口網站伺服器中的「%windir%\web\rdweb\pages\images」路徑下,取代原有的 logo_02.png 圖檔,即可達成更換 RDWeb 入口網站中 Logo 的目的(如圖 25 所示)。
右上角橫幅圖示則是 logo_01.png,管理人員可視需求進行更換。
圖 25、更換 RDWeb 入口網站中的 Logo 圖示





結語

透過本文的深入剖析及實戰演練,希望幫助讓原本 IT 預算和資訊人員較為不足的小型企業,也能透過 Microsoft RDS 遠端桌面服務,快速建構出讓員工能夠在家工作的運作環境。

[站長開講] 臺灣雲端大會 Cloud Edge Summit Taiwan 2021

$
0
0


活動簡介

過去一年,我們深陷於此生少見的動盪、驚惶和焦慮;原本大家害怕在疫情籠罩下,地表上一切都被按下無盡的休止符,豈料疫情不僅沒有拖慢我們的步伐,還注入數位轉型催化劑,觸動許多企業營運模式的翻轉,連帶開啟全球商業新競局。

顯而易見,現今處在競局領先群的許多企業,普遍能展現又快又準的決策力和執行力,來自於他們懂得利用雲端與邊緣運算資源,一步到位駕馭先進數位科技,得以花費最低的成本與時間代價,不斷進行「選題、驗證、放大(或放棄)」的試錯循環,加速實現最小可行產品(MVP),進而加速佈建到全球市場,也加速輾壓了商業對手。

新的一年,疫情依舊、轉型持續,讓我們再次擁抱雲邊科技,建立豐沛的數位力,力求守穩變局、突圍致勝!

精彩內容,不容錯過,即刻報名「2021 iThome 臺灣雲端大會」!





活動資訊

  • 日期:   2021 年 11 月 16 日 (星期二)
  • 時間:   08:00 ~ 16:30
  • 地點:   台北國際會議中心
  • 報名:   活動報名





議程內容



[站長開講] DevOpsDays Taipei 2021

$
0
0


活動簡介

DevOpsDays Taipei是由臺灣在地技術社群發起,結合社群、企業共同舉辦之年度 DevOps 盛會。DevOpsDays 由 DevOps 之父 Patrick Debois 發源自比利時,經過全球社群的共同響應,如今在全球,每年皆有多個城市舉辦以城市掛名的 DevOpsDays。

根據 iThome 的報導,不論是國內外的知名企業例如台積電、金士頓、趨勢科技、國泰金控等皆早已擁抱 DevOps,引領企業持續改善、邁向新一波的 IT 數位轉型。DevOps 作為同時蘊含技術與文化轉型雙主軸的 IT 熱門關鍵字,其影響力已不僅是 IT 圈內人人皆知,更擴展至企業組織的各個層面。 

DevOpsDays Taipei 2021 即將在 2021/5/28 於臺北文創盛大舉辦,Agile Community.tw、DevOps Taiwan Community、HashiCorp User Group Taipei 以及 iThome 再次攜手合作,期盼再創屬於臺灣在地的 DevOps 高峰盛會。





活動資訊

  • 日期:   2021 年 11 月 24 日 (星期三)
  • 時間:   09:00 ~ 17:00
  • 地點:   臺北文創大樓
  • 報名:   活動報名





議程內容

網管人 190 期 - 實戰部署 HCI Mesh 架構,最大化 vSAN 資源使用

$
0
0


網管人雜誌

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






本文目錄






前言

從 VMware vSphere 7 版本開始,VMware 官方便公佈後續版本的發佈週期為「6 個月」。最新的 vSAN 7 Update 2 版本,已經在 2021 年 3 月正式發佈,與 vSphere 7 Update 2 相同的是,雖然看似為小版本更新,但是實際上在整個 vSAN 超融合叢集運作架構中,除了原本特色功能的提升之外,更新增許多亮眼特色新功能,幫助企業和組織打造更穩定和強大的 vSAN 超融合叢集基礎架構。

舉例來說,過去版本的 vSAN 超融合叢集環境,無法在小型規模的 2-Nodes vSAN 叢集,以及中大型規模的「延伸叢集」(Stretched Cluster)中,整合新增的 vSAN File Services 特色功能。現在,最新版本的 vSAN 7 Update 2,無論 2-Nodes vSAN 叢集或延伸叢集,都已經完全整合並支援 vSAN File Services 特色功能(如圖 1 所示)。

圖 1、新版 vSAN 7 Update 2 延伸叢集支援 File Services 功能運作架構示意圖





vSAN 7 Update 2 亮眼特色功能

正式支援 RDMA 低延遲機制

事實上,從 vSphere 6.7 版本開始,VMware 官方便開始逐漸支援各種 RDMA 的應用情境。然而,透過 vSAN 技術所搭建 HCI 超融合基礎架構環境中,影響 VM 虛擬主機儲存效能關鍵的 vSAN 網路流量,卻遲遲尚未正式支援 RDMA 低延遲機制,仍然採用傳統的 TCP/IP 進行 vSAN 網路流量的傳輸作業。

現在,最新的 vSAN 7 Update 2 版本,已經正式支援 RoCE(RDMA over Converged Ethernet)RoCE v1RoCE v2版本,簡單來說,RoCE v1 版本屬於 Layer 2資料連結層級,而 RoCE v2版本則為 Layer 3支援路由機制的網路層級(如圖 2 所示)。
請注意,目前僅支援 RDMA 中整合 UDP 協定的 RoCE 技術,尚未支援整合 TCP 協定的 iWARP(Internet Wide-area RDMA Protocol)技術。

因此,和過去採用傳統 TCP/IP 的 vSAN 叢集相較之下,採用 RDMA 技術的 vSAN 超融合叢集,更能提供低延遲高吞吐量和高 IOPS 儲存效能,同時還能有效降低每個讀取和寫入的 I/O 操作,導致 vSAN 節點主機 CPU 運算資源的額外開銷。

原則上,在 vSAN 超融合叢集架構中,vSAN 節點主機只要配置支援 RoCE v2 的 RDMA 網路卡(如圖 3 所示),並且搭配支援 RoCE v2 的網路交換機,即可在 vSphere Client 管理介面中,一次性針對所有的 vSAN 節點主機網路功能啟用 RDMA support 機制(如圖 4 所示),倘若有 vSAN 節點主機 RDMA 運作異常,導致 RDMA 無法順利運作時,則 vSAN 叢集會自動恢復成原有傳統的 TCP/IP 網路進行傳輸。
啟用 RDMA 機制後,管理人員可在 Skyline Health 中,透過 RDMA Configuration Health 項目,查看 RDMA 機制的健康情況。
圖 3、為 vSAN 節點主機配置支援 RoCE 技術的 RDMA 網路卡

圖 4、一次性針對所有的 vSAN 節點主機網路功能啟用 RDMA support 機制



共享式 vSAN Datastore 儲存資源

在前一版 vSAN 7 Update 1 版本中,vSAN HCI Mesh 僅支援 Server Cluster 和 Client Cluster 機制,也就是只能在不同的 vSAN 超融合叢集之間,互相使用對方的 vSAN Datastore 儲存資源(如圖 5 所示),而企業和組織資料中心內,原有已經建置的傳統 vSphere 叢集,則無法享受 vSAN HCI Mesh 技術所帶來的好處。

圖 5、在 vSAN 7 Update 1 版本中,僅支援 Server Cluster 和 Client Cluster 機制

現在,新版 vSAN 7 Update 2 運作架構中,除了原有 Server Cluster 和 Client Cluster 支援度增強以外,更支援整合傳統 vSphere 叢集,也能使用遠端 vSAN Datastore 儲存資源。簡單來說,傳統 vSphere 叢集可以將遠端 vSAN Datastore 儲存資源,當成過去連接和掛載傳統硬體儲存設備一樣,不同的是能夠充分享受到 vSAN 儲存原則的優點,讓 VM 虛擬主機能夠使用傳統 vSphere 叢集的運算資源,在儲存資源方面則是套用具備彈性的 vSAN 儲存原則(如圖 6 所示)。
HCI Mesh Compute Cluster 只須購買傳統的 vSphere 軟體授權,無須額外購買 vSAN 軟體授權,便能直接使用遠端 vSAN Datastore 儲存資源。
圖 6、vSAN HCI Mesh Compute Cluster 整合 vSAN 儲存原則示意圖



網路流量監控再升級

隨著 vSAN 超融合叢集功能不斷提升,除了支援 RDMA 低延遲技術之外,新版 vSAN HCI Mesh 機制,更讓傳統 vSphere 叢集也能直接使用 vSAN Datastore 儲存資源。可想而知,這一切都必須仰賴良好且穩定和高速傳輸的網路環境,倘若網路環境不理想時,輕者可能造成 VM 虛擬主機運作效能不佳,嚴重時則可能會不當觸發 vSphere HA 中的 Datastore with APD 機制,導致 VM 虛擬主機發生非預期的關機或重新啟動事件。

因此,在 vSAN 7 Update 2 版本中,針對網路流量監控的部份新增多項指標和檢查機制,例如,CRC error、transmit error、receive error、ARP drops、TCP zero frames……等監控指標和檢查機制(如圖 7 所示),幫助管理人員更快速找出網路環境中出問題的環節在哪裡。
有關上述監控指標和檢查機制的詳細資訊,請參考 VMware KB2144493知識庫文章內容。
圖 7、新增多項指標和檢查機制,幫助管理人員更快速找出問題環節

這些新增的監控指標,除了隨時顯示在效能圖表當中方便查找,並讓管理人員可以匯出各種格式製作異常報告之外,更能針對各項異常的監控指標建立告警門檻值(如圖 8 所示),以便網路傳輸異常數據升高超過設定的門檻值時,自動觸發告警機制通知管理人員即時進行處理。
目前,效能圖表支援匯出的格式有 JPEG、PNG、SVG、CSV 等四種格式。
圖 8、針對各項異常的監控指標建立告警門檻值



不斷增強的 Stretched Cluster

隨著 vSAN 超融合叢集功能不斷演進,「延伸叢集」(Stretched Cluster)功能同樣也不斷增強。在新版 vSAN 7 Update 2 運作環境中,除了延伸叢集中主要站台和次要站台,每個站台支援最多擴充至 20 台 vSAN 節點主機的規模之外,延伸叢集已經完整支援 vSphere DRS 負載平衡機制。

由於延伸叢集的架構複雜性,除了必須考慮各種故障情況之外,還必須考慮災難復原後的最佳運作機制。現在,新版 vSAN 7 Update 2 將「資料放置」(Data Placement)機制,與 vSphere DRS 負載平衡機制完全整合,以便延伸叢集發生災難事件並修復完成後,vSphere DRS 能夠先將 VM 虛擬主機保持在同一個站台,直到所有物件和資料已經重新同步完成之後,才透過 vSphere DRS 的負載平衡規則,將 VM 虛擬主機遷移至適當的站台,確保物件和資料在重新同步期間,不會進行無謂的 VM 虛擬主機負載平衡作業,有效減少不同站台之間跨 ISL(Inter-Site Link)的讀取操作,並讓物件和資料重新同步時間大幅縮短(如圖 9 所示)。

圖 9、新版 vSAN 7 Update 2 延伸叢集整合 vSphere DRS 運作架構示意圖





實戰 – vSAN HCI Mesh

在開始實戰演練 vSAN HCI Mesh 運作環境之前,先了解運作 vSAN HCI Mesh 的環境需求和相關限制,避免後續實作時未滿足需求或踩到限制而遭遇到非預期的錯誤。

首先,在「Client Cluster」和「Server Cluster」的部份,分別支援最多「5個」vSAN Datastore 儲存資源(如圖 10 所示)。連接 vSAN Datastore 儲存資源主機數量的部份,在 vSAN 7 Update 1 版本時最多支援 64 台 vSAN 節點主機,在新版 vSAN 7 Update 2 版本中,提升至最多支援「128 台」vSAN 節點主機。
使用」遠端 vSAN Datastore 儲存資源的叢集稱為 Client Cluster,「提供」本地端 vSAN Datastore 儲存資源給遠端叢集使用稱為 Server Cluster。
圖 10、vSAN HCI Mesh 和 Server Cluster 及 Client Cluster 架構支援度示意圖

值得注意的是,套用於 VM 虛擬主機的「儲存原則」(Storage Policy),必須以 Server Cluster 採用的 vSAN 儲存原則為準(如圖 11 所示),而非使用遠端 vSAN Datastore 儲存資源的 Client Cluster 進行套用,舉例來說,VM 虛擬主機套用 RAID-6 FTT=2的儲存原則時,代表 Server Cluster 叢集中至少包含 6 台以上的 vSAN 節點主機。

圖 11、vSAN HCI Mesh 整合 vSAN 儲存原則運作架構示意圖



暫時停用 vSphere HA

在組態設定 vSAN HCI Mesh 機制之前,建議先將 vSAN 叢集中的 vSphere HA 高可用性機制暫時停用(如圖 12 所示),以避免在組態設定過程中不慎觸發 vSphere HA 高可用性機制,產生非預期的高工作負載量,並可能中斷和影響 VM 虛擬主機中持續運作的服務或應用程式。

圖 12、暫時停用 vSphere HA 高可用性機制,避免組態設定 vSAN HCI Mesh 機制時影響穩定性



專屬的 vSAN VMkernel Port

在 vSAN HCI Mesh 運作架構中,無論採用 Server Cluster 或 Client Cluster 或者 Compute Cluster,建議管理人員都必須為這些 vSAN 節點主機或 ESXi 主機,組態設定專用於連接和掛載用途,遠端 vSAN Datastore 儲存資源的 vSAN VMkernel Port 。
vSAN HCI Mesh 架構的跨叢集流量為「RDT over TCP/IP」,和原有傳統 vSAN 叢集的網路流量,採用近乎完全相同的 TCP/IP 網路協定堆疊架構。

由於 vSAN HCI Mesh 為跨叢集架構,建議部署 NIC Teaming 容錯機制,採用專屬的 vDS Switch 分佈式交換器,並搭配 NIOC 網路流量管理機制之外,為了避免因為跨叢集之間的網路延遲,影響 VM 虛擬主機運作效能,至少應採用 10 Gbps網路卡建議則是 25 Gbps網路卡。
當網路延遲時間超過 5 ms時,將會觸發系統的告警機制。

此外,除了原有建議採用的 Layer 2 資料連結層之外,也支援 Layer 3 具備路由機制的網路層。因此,管理人員在新增專屬用於 vSAN HCI Mesh 的 VMkernel Port 時,可以勾選「override default gateway for this adapter」項目,並指定所要採用的預設閘道 IP 位址,即可支援 Layer 3 具備路由機制的網路層(如圖 13 所示)。
從 vSAN 7 Update 1 版本開始,便支援 vSAN HCI Mesh 整合 Layer 3具備路由機制的網路層。
圖 13、組態設定 vSAN HCI Mesh 專屬 VMkernel Port 時,啟用 Layer 3 路由機制



掛載遠端 vSAN Datastore 儲存資源

在本文實作環境中,除了 vCenter Server 管理用途專用的「MGMT-Cluster」之外,還建立二個 vSAN 超融合叢集,分別是「vSAN-Cluster-A」和「vSAN-Cluster-B」(如圖 14 所示),建立的 vSAN Datastore 儲存資源,分別為「vsanDatastore-A」和「vsanDatastore-B」。

圖 14、管理用途叢集和 vSAN 超融合叢集運作環境示意圖

當 vSAN 叢集環境部署完成後,依序點選「Datacenter > vSAN Cluster > Configure > vSAN > Remote Datastores」,即可看到 vSAN Datastore 儲存資源相關資訊,在目前的 vSAN-Cluster-A 叢集中,可以看到只有本地端的「vsanDatastore-A」儲存資源(如圖 15 所示)。
請注意,部署的 vSAN 叢集環境必須為 vSAN 7 Update 1 和後續版本,才能在 vSAN 叢集設定中看到「Remote Datastores」組態設定子項目。
圖 15、準備連接和掛載遠端 vSAN Datastore 儲存資源

確認無誤後,按下「Mount Remote Datastore」連結,系統將會彈出 Select datastore 視窗,在本文實作環境中,請選擇另一個 vSAN 叢集「vSAN-Cluster-B」的儲存資源「vsanDatastore-B」後(如圖 16 所示),按下 Next 鈕繼續 Client Cluster 組態設定流程。
請注意,目前 vSAN HCI Mesh 運作機制,尚未支援跨不同 vCenter Server 管理主機,因此系統僅會顯示受到同一台 vCenter Server 所管理的其它 vSAN 叢集。
圖 16、選擇準備連接和掛載的遠端 vSAN 叢集儲存資源

在 Check compatibility 頁面中,系統將會針對上一個步驟選擇的遠端 vSAN Datastore 儲存資源,進行多個項目的相容性檢查(如圖 17 所示),例如,遠端 vSAN Datastore 儲存資源是否為支援格式的版本、vSAN 叢集是否已經達到 5 個 Client Cluster 的掛載上限……等,確保能夠順利掛載和使用選擇的遠端 vSAN Datastore 儲存資源。
倘若 vSAN 節點主機「停用 IPv6」網路堆疊,那麼系統將無法進行相容性檢查作業,並且顯示「Failed to run the remote datastore mount pre-checks」錯誤訊息。
圖 17、通過系統相容性檢查,確保順利掛載和使用遠端 vSAN Datastore 儲存資源

至此,管理人員可以在 Remote Datastore 視窗中,看到多出「vsanDatastore-B」儲存資源(如圖 18 所示),並且 Server Cluster 為提供遠端 vSAN 儲存資源的「vSAN-Cluster-B」叢集,而 Client Cluster 則是使用遠端 vSAN 儲存資源的「vSAN-Cluster-A」叢集。

圖 18、vSAN-Cluster-A 叢集順利掛載遠端 vSAN-Cluster-B 儲存資源

同樣的,管理人員可以為 vSAN-Cluster-B 叢集,組態設定使用 vSAN-Cluster-A 叢集儲存資源。此時二個 vSAN 叢集的角色將互相對換,多出「vsanDatastore-A」儲存資源(如圖 19 所示),並且 Server Cluster 為提供遠端 vSAN 儲存資源的「vSAN-Cluster-A」叢集,而 Client Cluster 則是使用遠端 vSAN 儲存資源的「vSAN-Cluster-B」叢集。

圖 19、vSAN-Cluster-B 叢集順利掛載遠端 vSAN-Cluster-A 儲存資源

完成 vSAN HCI Mesh 的組態設定作業後,管理人員可以重新啟用 vSphere HA 高可用性機制。值得注意的是,在啟用 vSphere HA 高可用性機制時,因為整合 HCI Mesh 機制的 vSAN 叢集並非一般普通叢集。簡單來說,當本地端 vSAN 叢集和遠端 vSAN 叢集之間連線發生失敗時,將會讓 VM 虛擬主機受到影響,進而觸發「所有路徑關閉」(All Paths Down,APD)機制。

因此,管理人員應該在啟用 vSphere HA 高可用性機制時,調整 Datastore with APD 組態設定值,在一般 vSAN HCI Mesh 運作環境中,建議採用「Power off and restart VMs – Conservative restart policy」選項即可(如圖 20 所示)。
有關 Datastore with APD 組態設定內容的詳細資訊,請參考 VMware KB2004684KB2032934KB2032940知識庫文章內容。
圖 20、啟用 vSphere HA 高可用性機制並組態設定 Datastore with APD



遷移 VM 虛擬主機

部署 vSAN HCI Mesh 架構後,管理人員可以接著測試遷移 VM 虛擬主機資源,例如,將運算資源和儲存資源拆開在不同的叢集,或者直接遷移運算和儲存資源至另一個叢集。首先,在 vSAN-Cluster-A 叢集中,分別建立 VM-A01 和 VM-A02 虛擬主機,並且配置使用本地端的 vSAN Datastore 儲存資源(如圖 21 所示)。

圖 21、建立 VM-A01 和 VM-A02 虛擬主機,並使用本地 vSAN Datastore 儲存資源

在稍後的線上遷移工作任務中,測試將 VM-A01 虛擬主機的運算和儲存資源拆開,讓 VM-A01 虛擬主機使用 vSAN-Cluster-B 的運算資源,但是儲存資源則維持使用原本 vSAN-Cluster-A 的 vsanDatastore-A 。至於 VM-A02 虛擬主機,則將運算和儲存資源都遷移至 vSAN-Cluster-B 叢集。

管理人員在點選 VM-A01 虛擬主機的 Migrate 項目後,於彈出的 Select a migration type 視窗中,選擇「Change compute resource only」項目,在 Select a compute reousrce 頁面中,選擇 vSAN-Cluster-B 叢集中的 vSAN 節點主機,並確保下方相容性檢查結果為「Compatibility checks succeeded」,其它則和傳統 vMotion 線上遷移 VM 虛擬主機流程相同。

當 vMotion 線上遷移流程執行完畢後,管理人員可以看到 VM-A01 虛擬主機,在運算資源方面使用 vSAN-Cluster-B 叢集,至於儲存資源方面則是整合 vSAN HCI Mesh 機制,使用原有 vSAN-Cluster-A 的 vsanDatastore-A 儲存資源(如圖 22 所示)。

圖 22、整合 vSAN HCI Mesh 機制將 VM-A01 虛擬主機運算和儲存資源拆開

同樣的,點選 VM-A02 虛擬主機的 Migrate 項目後,在彈出的 Select a migration type 視窗中,選擇「Change both compute resource and storage」項目,在 Select a compute reousrce 頁面中,選擇 vSAN-Cluster-B 叢集中的 vSAN 節點主機,並在 Select storage 頁面中選擇「vsanDatastore-B」儲存資源,其它則和傳統 vMotion 遷移 VM 虛擬主機流程相同。

當 vMotion 遷移流程執行完畢後,管理人員可以看到 VM-A02 虛擬主機,在運算資源方面使用 vSAN-Cluster-B 叢集,至於儲存資源方面則從原本 vSAN-Cluster-A 的 vsanDatastore-A 儲存資源,遷移至 vSAN-Cluster-B 的 vsanDatastore-B 儲存資源(如圖 23 所示)。
目前,尚未支援 VM 虛擬主機儲存資源跨 vSAN Datastore,舉例來說,VM 虛擬主機配置二顆硬碟,管理人員無法設定第一顆硬碟存放在 vsanDatastore-A,而第二顆硬碟存放在 vsanDatastore-B 儲存資源。
圖 23、同時遷移 VM-A02 虛擬主機的運算和儲存資源



部署 vSAN HCI Mesh Compute Cluster

在本文實作環境中,建立一個傳統的 vSphere 叢集,並準備掛載和使用遠端 vSAN Datastore 儲存資源。請在 vSphere Client 管理介面中,依序點選「Datacenter > vSphere Cluster > Configure > vSAN > Services > Configure vSAN」項目,在彈出的 Select vSAN configuration 視窗中,選擇「vSAN HCI Mesh compute cluster」項目(如圖 24 所示),在 Review 頁面中確認無誤後按下 Finish 鈕完成組態設定作業。

圖 24、準備為傳統 vSphere 叢集啟用 vSAN HCI Mesh Compute Cluster 功能

順利啟用 vSAN HCI Mesh Compute Cluster 功能後,便會在 vSAN 組態設定選項中,出現 Remote Datastores 子項目,管理人員便能執行掛載遠端 vSAN Datastore 儲存資源的工作任務,與之前組態設定的操作步驟相同,連接和掛載遠端「vsanDatastore-A」和「vsanDatastore-B」儲存資源(如圖 25 所示)。

圖 25、傳統 vSphere 叢集連接和掛載遠端 vSAN Datastore 儲存資源



部署或遷移 VM 虛擬主機儲存資源

現在,傳統 vSphere 叢集無論部署新的 VM 虛擬主機,或現有 VM 虛擬主機需要執行 Storage vMotion 工作任務,遷移 VM 虛擬主機的儲存資源時,都能選擇已經連接和掛載完成的遠端 vSAN Datastore 儲存資源,並且套用具備彈性的 vSAN 儲存原則。

在本文實作環境中,於傳統 vSphere 叢集「vSphere-Cluster」中,部署一台 VM-C 虛擬主機並在選擇儲存資源時,選擇已經掛載完成的遠端 vSAN Datastore 儲存資源「vsanDatastore-A」,當 VM-C 虛擬主機部署完成後,管理人員即可查看 VM-C 虛擬主機採用的 vSAN 儲存原則(如圖 26 所示),以及 VM 虛擬主機的 vSAN 儲存物件分佈情況,再次達成 VM 虛擬主機運算和儲存資源拆開的目的。

圖 26、將傳統 vSphere 叢集中的 VM 虛擬主機運算和儲存資源拆開





結語

透過本文的深入剖析和實戰演練後,相信管理人員理解 vSAN HCI Mesh 運作架構,以及環境需求和相關限制之後,能夠輕鬆部署 vSAN HCI Mesh 機制,將 vSAN 超融合叢集和傳統 vSphere 叢集進行整合,達到將 VM 虛擬主機或容器的工作負載,有效分配運算資源和儲存資源達到資源使用最大化的目標。

vSAN Cluster - Distributed Switch and associated Distributed Port Groups are missing

$
0
0


Question: Distributed Switch and associated Distributed Port Groups are missing

採用手動組態設定的方式建立 vSAN Cluster 後 (而非 vSAN Cluster QuickStart),透過 Skyline Health 進行 vSAN Cluster 健康情況檢查時,卻出現下列二項警告和錯誤訊息:
VDS compliance check for hyperconverged cluster configuration.
Host compliance check for hyperconverged cluster configuration.



Answer:

因為,這二項 Skyline Health檢查項目,是針對採用 vSAN Cluster Quickstart方式建立的檢查項目,而本文環境是採用「手動」方式,一步一步把 vSAN Cluster 超融合環境建立起來,所以便發生這樣的情況。

簡單來說,倘若你是採用 vSAN Cluster Quickstart 方式建立後,透過 Skyline Health 機制檢查出這二項有問題的話,請依照下列 VMware KB 建議進行逐步排除和解決:

本文實作環境採用「手動」方式建立,所以依照 VMware 官方建議,可以放心把這二個警告關閉提醒。請到 Skyline Health 頁面,針對這二項點選「Silence Alert」即可。


點選 Silence Alert 之後,再次檢查即可發現除了那二項其餘都通過測試,確保 vSAN Cluster 環境健康頭好壯壯。倘若,後續想要恢復的話檢查這二項的話,只要點選「Restore Alert」即可。


當然,若是切換到 Quickstart 頁面,也可以看到這二項檢查是關閉的。


CentOS 7 - You could try using --skip-broken to work around the problem

$
0
0


Question: You could try using --skip-broken to work around the problem

執行 yum -y update 指令時,遇到如下圖錯誤訊息:
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest



Answer:

有試過網路上大部份提到的解法「sudo yum clean all」和「sudo rpm --rebuilddb」,但是在本文環境中的主機上是無效的。

檢查這台主機的 /etc/yum.conf設定檔內容,發現有「exclude=*.i?86 *.i686」設定,註解後再次執行 yum -y update 指令便沒問題了。

CentOS 7 - SSH key pair 無法正常運作?

$
0
0


Question: SSH key pair 無法正常運作?

最近,幫忙看一台 CentOS 7 的主機症狀是這樣的,使用者已經建立好 SSH key pair,並且已經處理好目標主機的「.ssh/authorized_keys」。但是,嘗試 SSH 登入目標主機時,還是發現必須鍵入密碼才能登入?



Answer:

簡單來說,這次的 CentOS 7 主機中,目標主機的 .ssh 資料夾權限不對所造成的。可能使用者在某些原因下,把 .ssh 資料夾的權限設定成 777了,但是 .ssh 資料夾僅能設定成「700」或「755」,只要設定成其它權限的話,就會造成上述 SSH Key-based 登入方式失效的情況。

有興趣了解其它更詳細資訊的朋友,請參考下列網址:

Ansible - Authentication or permission failure

$
0
0


Question: Authentication or permission failure

在 Ansible AWX 執行 playbook 時,出現如下圖錯誤訊息
Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in tmp.



Answer:

事實上,錯誤訊息中已經說明問題發生的原因。這次的有問題的主機狀況是,執行 playbook 的帳號,並沒有目標主機的相關資料夾權限所導致。

管理人員可以直接修改「ansible.cfg」內容,或是像本文中,將「ansible_remote_tmp: /tmp」暫時參數加上即可解決。


有關 「ansible_remote_tmp: /tmp」 參數作用的詳細資訊,請參考下列官方連結:

CentOS 7 - CIFS VFS: cifs_mount failed w/return code = -22

$
0
0


Question: CIFS VFS: cifs_mount failed w/return code = -22

在 CentOS 7 主機執行指令,嘗試透過 CIFS 去掛載遠端 volume 時,系統出現「No such file or directory」的掛載失敗錯誤訊息,並且查看系統 dmesg 資訊時,出現如下圖所示錯誤訊息
CIFS VFS: cifs_mount failed w/return code = -22



Answer:

這個問題其實查蠻久的浪費不少時間 😤。最後,突然想到會不會是使用者執行掛載的指令上出問題,(謎之音:使用者總是說,一直以來都是執行這個指令且沒遇到任何問題),然後仔細一查發現,是目標端 CIFS volume 的路徑「打錯字」了 👎,中間多了個符號 (經典的 Fat-finger error),當然排除錯字後就解決了。

網管人 191 期 - 善用 Azure 實驗室服務,動手打造雲端化電腦教室

$
0
0


網管人雜誌

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





本文目錄






前言

過去,企業和組織或學校的內部教育訓練場所,為了達到講師和學員的運作環境能夠一致,以便後續教育訓練時,能夠讓講師和學員專注在上課內容中,而非花費時間解決 PC/NB 硬體環境的差異或問題上(如圖 1 所示)。因此,通常會建立 PC/NB 硬體環境一致的電腦教室,對於企業和組織來說,通常規模和數量上較為小型,並且有企業和組織的 IT 人員協助處理,所以在電腦教室管理方面上並不會造成太大的困擾。


然而,對於學校來說,不僅需要建置多間電腦教室,以便滿足校內師生授課的需求之外。同時,為了因應不同老師的教學環境需求,每間電腦教室內的 PC 主機硬體也會有所差異。舉例來說,當老師的授課內容為 Microsoft Office、MATLAB……等,常見或無特殊需求的應用程式時,那麼只需要一般 PC 主機硬體即可滿足,然而授課內容為 SolidWorks 這種運算密集度高的應用程式時,倘若 PC 主機硬體未配置 GPU 的情況下,將會導致老師在授課上以及學生在操作學習上產生困擾。

此外,為了讓電腦教室能夠更有效運用和彈性調配,常見的作法就是在電腦教室的 PC 主機硬體中,將該學期老師開課會使用到的所有應用程式,全部一股腦的安裝在電腦教室的 PC 主機硬體內。如此一來,雖然達到電腦教室有效運用和彈性調配的目的,但是 PC 主機硬體即便硬體效能再強,在安裝數量眾多的應用程式後,輕者可能只是執行效能降低,最怕的是眾多應用程式之間發生資源衝突,造成應用程式無法開啟或容易發生崩潰的情況,並且隨著 COVID-19 疫情反覆不斷,實體的電腦教室也因為有群聚的風險而暫緩使用。

因此,在本文中將深入剖析和實戰演練,透過「Azure 實驗室服務」(Azure Lab Service),為企業和組織及學校輕鬆打造雲端化的電腦教室。以上述學校電腦教室環境為例,透過 Azure 實驗室服務,為學生建立具備 GPU 的 VM 虛擬主機,以便因應 SolidWorks 授課需求,另外建立的普通 VM 虛擬主機,則用於授課內容為 MATLAB 和其它普通應用程式的課程(如圖 2 所示),即可達到快速將不同的資源分派給適用的師生上課,同時也能有效避免眾多應用程式之間發生資源衝突的情況。

圖 2、實體電腦教室轉換為雲端化的 Azure 實驗室服務示意圖





Azure 實驗室服務運作架構

在實作演練 Azure 實驗室服務之前,先概要了解整體運作架構,以便後續管理和使用上發生問題時,能夠迅速找出問題可能發生的原因。下列便是 Azure 實驗室服務中,相關的技術名詞和運作架構示意圖(如圖 3 所示):
  • Azure 訂閱帳戶(Azure Subscription): 在企業或組織及學校中,IT 管理人員可以透過 Azure 訂閱帳戶,管理和使用 Azure 資源及相關服務。
  • 資源群組(Resource Group): 在 Azure 訂閱帳戶中,可以建立一個或多個資源群組進行邏輯分組。值得注意的是,後續建立的 Azure 實驗室帳戶和共用映像檔時,一旦和選定的資源群組綁定後便無法變更,必須要刪除後重新建立才行。
  • Azure 實驗室訂閱帳戶(Azure Lab Services Subscription): 在 Azure 實驗室訂閱帳戶中,可以建立一間或多間實驗室,每間實驗室內可以建立不同用途和規模的 VM 虛擬主機。簡單來說,管理人員可以把每一間實驗室,當成是一間電腦教室的概念。
  • 實驗室(Classroom Lab): 在實驗室內將會運作多台 VM 虛擬主機,這些 VM 虛擬主機是採用共用映像檔的方式進行大量部署,並且不同的實驗室都將配置不同的虛擬網路。舉例來說,管理人員可以建立具備 GPU 的 VM 虛擬主機,提供教師對於 SolidWorks 課程的授課需求,另一間實驗室建立一般用途的 VM 虛擬主機,提供教師對於 MATLAB 和其它普通應用程式的課程。
  • 共用映像檔倉庫(Shared Image Gallery): 提供實驗室建立 VM 虛擬主機時的共用映像檔,這些共用映像檔就是不同的作業系統範本,也就是教師所要授課的運作環境範本。簡單來說,教師在建立實驗室準備部署大量的 VM 虛擬主機時,可以為 VM 虛擬主機選擇要套用的共用映像檔,達成快速部署並且運作環境一致的目的。
圖 3、Azure Lab Service 實驗室服務運作架構示意圖





實戰 – Azure Lab Services 實驗室服務

建立 Azure 實驗室服務(管理人員)

在 Azure 實驗室服務運作架構中,首先要建立具備管理整體實驗室架構的管理人員帳戶,後續當然也可以依據需求,將相關管理人員加入至管理權限名單中。
一般來說,會先讓擁有 Azure 訂閱帳戶的管理人員,建立實驗室服務後再指派相關管理人員即可。

登入 Azure Portal 管理介面後,依序點選「Home > Create a resource > Categories > DevOps > Lab Services > Create」後,便會引導至建立實驗室訂閱帳戶的頁面資訊,管理人員可以依據需求填寫和選擇下列欄位(如圖 4 所示):
  • Lab Account Name: 鍵入此 Azure 實驗室訂閱帳戶名稱,在本文實作環境中鍵入的名稱為「okd-101-lab」。
  • Subscription: 選擇建立實驗室訂閱帳戶所要使用的 Azure 訂閱帳戶,本文實作環境為「Weithenn Labs - MSDN」。
  • Resource group: 鍵入此實驗室訂閱帳戶所要使用的資源群組名稱,本文實作環境為「RG-OKD-101-Lab」。
  • Location: 選擇實驗室訂閱帳戶和資源群組,以及後續部署電腦教室和 VM 虛擬主機時,所要使用的 Azure 資料中心,本文實作環境選擇採用「Korea South」資料中心。
圖 4、建立 Azure 實驗室服務和實驗室訂閱帳戶

鍵入和選擇建立實驗室訂閱帳戶的相關資訊後,管理人員可以依據需求調整進階選項,或針對其它選擇採用預設值直接按下「Review + Create」鈕,再次檢查相關組態設定值內容無誤後,按下 Create 鈕,便立即建立實驗室訂閱帳戶和資源群組。

當實驗室訂閱帳戶和資源群組建立完成後,頁面將會顯示「Your deployment is complete」訊息,並按下「Go to resource」鈕,即可將頁面導向至實驗室訂閱帳戶管理頁面。

當實驗室訂閱帳戶建立完畢後,後續需要加入額外的管理人員帳戶時,只要將該使用者帳戶加入至該實驗室訂閱帳戶中,並且指派具備「實驗室建立者」(Lab Creator)角色即可。

請在實驗室訂閱帳戶管理頁面中,依序點選「Access control(IAM)> Add > Add role assignment(Preview)> Role」,在 Role 角色頁面中勾選「Lab Creator」項目後按下 Next 鈕,然後在 Members 成員頁面中,點選 Select members 後選擇要加入 Lab Creator 角色的使用者帳號,檢視無誤後按下「Review + assign」鈕即可(如圖 5 所示)。
此時,IT 管理人員便可以指派給講師具備管理權限,以便後續講師可以自行建立雲端電腦教室,以及部署學員所要使用的 VM 虛擬主機。
圖 5、為實驗室訂閱帳戶加入其它管理人員帳戶



建立及管理雲端電腦教室(講師)

當 IT 管理人員,為講師指派具備實驗室訂閱帳戶的管理權限後,便可以依據課程需求建立雲端電腦教室,並且部署教育訓練時需要的 VM 虛擬主機運作環境,再指派給相關學員以便登入存取上課環境。

登入實驗室訂閱帳戶管理介面後,依序點選「Overview > Create a lab」項目,此時將會另開新的瀏覽頁面,並自動導向至「Azure 實驗室服務網站」(labs.azure.com),在通過使用者身份驗證程序後,便順利登入 Azure 實驗室服務網站。

在 Azure 實驗室服務網站中,按下「Create lab」鈕準備建立實驗室,也就是建立一間雲端電腦教室的概念。在建立實驗室的視窗中,首先,請鍵入和選擇這間雲端電腦教室的相關資訊(如圖 6 所示):
  • Name you lab: 鍵入這間雲端電腦教室的名稱,以便學員登入時方便識別使用的是哪間雲端電腦教室,本文實作環境鍵入的名稱為「OKD 101 Lab Classroom」。
  • Which virtual machine image do you want to use: 選擇稍後部署範本 VM 虛擬主機時,所要採用的映像檔,在本文實作環境中選擇採用「CentOS-based 8.3」作業系統範本。
  • Which virtual machine size do you need: 選擇部署 VM 虛擬主機時的運作規模大小,從最小規模 2 Cores/3.5 GB RAM 的一般用途 VM 虛擬主機,至最大 12 Cores/112 GB RAM 具備 GPU 的 VM 虛擬主機都有,在本文實作環境中,選擇支援巢狀式虛擬化的大型規模 VM 虛擬主機「Large,8 Cores,32 GB RAM」,並且預估每小時的費用為「$ 0.84」。
眼尖的 IT 管理人員應該已經發現,部署在實驗室內的 VM 虛擬主機,每小時所花費的費用方面,比起一般正常的 Azure VM 虛擬主機要便宜許多。
圖 6、準備建立雲端電腦教室並部署上課用的範本 VM 虛擬主機

在部署第二階段 Virtual machine credentials 頁面中,請為稍後部署的大量 VM 虛擬主機,組態設定採用相同的「使用者帳號」(Username)「密碼」(Password),並確認下方「Use same password for all virtual machines」選項為啟用狀態(如圖 7 所示),倘若未啟用預設密碼機制的話,屆時每位學員第一次登入 VM 虛擬主機時,系統便會彈出需要重新設定密碼的視窗。
請注意,鍵入的預設登入密碼必須符合複雜性原則,也就是密碼必須包含「數字」、「英文大小寫」、「特殊符號」才行。
圖 7、組態設定 VM 虛擬主機的使用者帳號和登入密碼

在部署第三階段 Lab policies 頁面中,請在「Lab hours available to each user outside of scheduled events」欄位,組態設定學員在排定的上課時間之外,還有額外多少小時能夠使用 VM 虛擬主機。預設為 10 小時,本文實作環境調整為「1 小時」,確認無誤後按下 Finish 鈕便開始建立雲端電腦教室,在建立頁面中可以看到系統提示最多可能需要花費 20 分鐘,才能將雲端電腦教室建立完畢(如圖 8 所示)。
講師後續可以隨時調整學員能夠額外使用的時數。
圖 8、開始建立雲端電腦教室和範本 VM 虛擬主機

當範本 VM 虛擬主機部署完成後,預設情況下為「停止」(Stopped)運作的狀態。此時,請在 Template 頁面中啟動該台範本 VM 虛擬主機,當狀態轉換為「運作中」(Running)時,請先點選「Connect to template」鈕,確認是否能夠透過 RDP 連線至 Windows 虛擬主機,或是透過 SSH 連線至 Linux 虛擬主機,舉例來說,本文實作環境為 SSH 連線至 Linux 虛擬主機,當按下 Connect to template 鈕時,系統便會彈出視窗讓管理人員複製 SSH 連線相關指令和參數,讓管理人員方便連線至該台範本 VM 虛擬主機。
基於安全性考量,可以發現 SSH 連線至範本 Linux 虛擬主機時,並非採用預設的 Port 22 而是隨機的連接埠號,例如,本文實作環境為 Port 60175。

順利連線至範本 VM 虛擬主機後,接著是為範本 VM 虛擬主機安裝相關應用程式或是軟體套件,以及客製化的組態設定,以便稍後可以利用此範本 VM 虛擬主機,達到快速部署且運作環境一致的目標。在本文實作環境中,將範本 VM 虛擬主機 Linux 系統中預設啟用的 SELinux 安全機制關閉,在完成範本 VM 虛擬主機的客製化組態設定後,便可以按下「Stop template」鈕(如圖 9 所示),將範本 VM 虛擬主機進行關機的動作。
請注意,範本 VM 虛擬主機在運作時將會花費成本,所以管理人員應該確保客製化設定完成後,關閉範本 VM 虛擬主機,以避免產生不必要的費用支出。
圖 9、完成範本 VM 虛擬主機的客製化組態設定後,記得關機以避免產生不必要的費用支出

現在,請按下範本 VM 虛擬主機上的「Publish」鈕,於彈出的 Publish template 視窗中,在 Set the maximum number of machines in the lab 欄位,鍵入要大量部署給學員使用的 VM 虛擬主機數量,本文實作鍵入數字「3」表示部署 3 台 VM 虛擬主機。
後續學員人數倘若有增減的情況,講師也可以隨時調整部署的 VM 虛擬主機數量。

待 VM 虛擬主機部署作業完成後,請點選「Virtual machine pool」項目,便可以查看部署給學員的 VM 虛擬主機狀態和相關資訊。目前,這些部署的 VM 虛擬主機尚未指派給學員存取,並且運作狀態也處於關機的情況,講師可以在管理介面中按下「Start all」鈕(如圖 10 所示),預先幫所有學員啟動 VM 虛擬主機,或是屆時學員存取成功後自行啟動 VM 虛擬主機。

圖 10、成功部署給學員使用的 VM 虛擬主機

如同管理傳統電腦教室一樣,在學校未開放時間或是例假日時,通常會將電腦教室內的 PC 主機關機,以避免不必要的電力浪費。在公有雲上的雲端電腦教室也是同樣的管理概念,因為在公有雲的環境中,只要 VM 虛擬主機處於運作狀態下就會使用資源並進行計費,然而學員可能在練習後忘了關機,或其它因素導致 VM 虛擬主機處於運作狀態,造成不必要的雲端費用支出。

因此,講師可以透過 Azure 實驗室的「排程」(Schedule)機制,讓部署在雲端電腦教室中的 VM 虛擬主機,可以在講師指定的上課時間自動開機,以及下課時間自動關機的動作。此外,為了提供給學員下課後仍然能夠持續練習的時間,在建立雲端電腦教室前講者組態設定的使用者配額,就是提供學員在下課時間時,仍然能夠使用 VM 虛擬主機的時間額度。

請依序點選「Schedule > Add scheduled event」,在排程組態設定視窗中,選擇和提供雲端電腦教室開放給學員連線 VM 虛擬主機的時間資訊(如圖 11 所示):
  • Event type: 提供 Standard、Stop only、Start only 等三種方式,其中 Stardard 便是包含自動開機和關機的設定,Stop only 為提供自動關機設定,Start only 為提供自動開機設定。
  • Date: 選擇排程機制執行的開始時間,預設採用當天日期。
  • Start time: 選擇雲端電腦教室內 VM 虛擬主機自動開機時間,例如,早上 8 點。
  • Stop time: 選擇雲端電腦教室內 VM 虛擬主機自動關機時間,例如,中午 12 點 30 分。
  • Time zone: 選擇排程機制所要套用的時區,例如,Taipei。
  • Repeat: 選擇要重複套用排程機制的時間,例如,套用排程時間至每週一、三、五,並且直到 2021 年 12 月 31 日止。
圖 11、排程設定雲端電腦教室開放時間

講師要做的最後一件事,就是指派哪些學員可以存取這間雲端電腦教室的 VM 虛擬主機。Azure 實驗室支援兩種機制,分別是「Azure AD(Azure Active Directory)」和「電子郵件」的方式,讓學員能夠存取雲端電腦教室。在 Azure AD 方面,講師只要依序點選「Users > Sync from group」,接著在彈出的視窗中選擇要同步的 Azure AD 群組即可。
請注意,必須要在使用者清單是「空的」情況下,才能執行 Azure AD 群組同步的動作,倘若已經手動新增使用者之後,管理介面中便不會出現 Sync from group 項目。

另一種新增學員名單的方式,請按下「Users > Add users manually」,在彈出的視窗中可以採用「Add by email address」選項,由講師將學員的電子郵件位址鍵入,或是選擇「Upload CSV」選項,透過上傳 CSV 檔案的方式,一次性大量新增為數眾多的學員電子郵件位址。完成新增學員名單的動作後,按下「Invite all」鈕(如圖 12 所示),在彈出視窗中鍵入邀請學員加入這間雲端電腦教室的資訊後,按下 Send 鈕便送出邀請學員存取雲端電腦教室的電子郵件。
請注意,Azure 實驗室服務,預設採用「Microsoft 帳戶」進行登入,倘若使用非 Microsoft 帳戶嘗試登入時,必須在執行註冊程序時,將非 Microsoft 帳戶與 Microsoft 帳戶進行連結綁定的動作,否則學員將無法登入和存取雲端電腦教室。
圖 12、新增雲端電腦教室的存取學員名單並送出電子郵件邀請

順利寄出電子郵件邀請後,學員便會收到註冊雲端電腦教室的邀請郵件(如圖 13 所示)。此時,學員只要按下邀請郵件中的「Register for the lab」鈕,並通過 Microsoft 帳戶使用者身份驗證程序,便能存取雲端電腦教室。

圖 13、學員收到註冊雲端電腦教室的邀請郵件



存取及使用雲端電腦教室(學員)

當學員順利通過註冊程序後,便會看到講師為學員建立的雲端電腦教室。此時,倘若 VM 虛擬主機狀態為「關機」(Stopped)的話,那麼學員可以自行啟動 VM 虛擬主機,倘若是在講師指定上課時間登入的話,那麼 VM 虛擬主機應該為「運作中」(Running)狀態(如圖 14 所示)。

圖 14、學員順利登入雲端電腦教室並看到講師所配發的 VM 虛擬主機

同樣的,學員只要按下右下角的「Connect to virtual machine」圖示鈕,即可得到 SSH 至上課用 VM 虛擬主機的連線方式。成功登入後,可以看到在剛才講師製作範本 VM 虛擬主機時,將 CentOS 作業系統中預設啟用的 SELinux 安全性機制關閉,所以大量部署出來的學員用 VM 虛擬主機,如同範本 VM 虛擬主機一樣,都已經將 SELinux 安全性機制關閉(如圖 15 所示)。
可以看到學員登入 Linux 虛擬主機時,並非採用預設的 Port 22 而是隨機的連接埠號,例如,本文實作環境為 Port 60402。
圖 15、學員順利登入講師客製化準備的上課用 VM 虛擬主機



管理雲端電腦教室(講師)

事實上,當講師發出邀請電子郵件給學員,而學員也點選 Register for the lab 鈕完成註冊動作後,講師便可以在「users」項目中,查看學員名單中的 Status 欄位,由 Not registered 轉換為 Registered 即表示註冊成功。同時,也可以在這裡為個別學員調整課外使用雲端電腦教室的時間,只要點選「Adjust quota」並鍵入延長時數,即可為個別學員增加額外使用雲端電腦教室的時數。

在「Virtual machine pool」項目中,除了可以看到 VM 虛擬主機的虛擬 IP 位址和使用時間之外,也可以幫忙學員的 VM 虛擬主機,進行開機或關機甚至強制「重新啟動」(Reset)的動作(如圖 16 所示),同時也可以連線至學員的 VM 虛擬主機幫忙進行除錯的動作。

圖 16、管理學員的 VM 虛擬主機

最後,講師可以在「Dashboard」頁面中,快速看到雲端電腦教室的使用概況,包括範本 VM 虛擬主機、學員的 VM 虛擬主機數量、學員存取清單數量、排程時間……等,以及根據講師設定的排程時間和允許下課後存取時間,進行統計後整體雲端電腦教室的費用估算(如圖 17 所示)。

圖 17、講師查看雲端電腦教室的使用情況和費用估算





結語

透過本文的深入剖析及實戰演練,相信能夠幫助企業和組織或學校,快速建立全面雲端化的電腦教室環境,甚至相關研討會和活動,例如,「黑客松」(Hackathon)或「工作坊」(Workshop)……等,也都非常適合使用 Azure 實驗室服務,達到快速建立和部署教學使用環境的目的。

Tanzu - Repo name tce already exists

$
0
0


Question: Repo name tce already exists

在 Windows 環境中,嘗試安裝 Tanzu CLI 時,卻發生下列錯誤訊息?
Error: repo name "tce" already exists
Error: repo name "core-admin" already exists



Answer:

本文實作環境的問題根本原因在於,先前有安裝 TKG (Tanzu Kubernetes Grid) CLI 環境所導致。因為,最近嘗試開始玩 TCE(Tanzu Community Edition),所以在安裝 TCE 版本的 Tanzu CLI時就會遇到此問題。

簡單來說,只要採用 TCE 版本的 Tanzu CLI安裝程式執行 uninstall.bat後,即可將相關檔案和關聯刪除,然後再次執行 install.bat安裝指令即可。


Tanzu - unable to create Tanzu Standalone Cluster client

$
0
0


Question: unable to create Tanzu Standalone Cluster client

準備好 Tanzu CLI 環境後,執行「tanzu standalone-cluster create --ui」指令後,發現下列錯誤訊息,並且無法繼續?
Error: unable to create Tanzu Standalone Cluster client
Cause: unable to ensure prerequisites: unable to ensure tkg BOM file: failed to download TKG compatibility file from the registry: failed to list TKG compatibility image tags: Get "https://projects.registry.vmware.com/v2/": x509: certificate signed by unknown authority
Error: exit status 1



Answer:

簡單來說,請將「%USERPROFILE%\.config\tanzu\tkg\config.yaml」檔案內容,修改成如下內容後,再次執行「tanzu standalone-cluster create --ui」指令,便不會出現錯誤。
release:
    version: ""
TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: true

Tanzu - unable to initialize providers control-plane-kubeadm

$
0
0


Question: unable to initialize providers control-plane-kubeadm

嘗試部署 TCE (Tanzu Community Edition) Standalone Cluster 至 vSphere時,卻發生下列錯誤訊息?
Failed waiting for at least one provider, check logs for more detail.
unable to set up standalone cluster, : unable to initialize providers: error waiting for provider components to be up and running: pods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system'
Shutting down...



Answer:

在本文實作環境中,造成這個問題的根本原因是 Tanzu CLI 主機的 SSH Key Pair 處理有問題導致的。在本文實作中,採用 Windows 10 主機當成 Tanzu CLI 主機 (或是文件中稱之為 bootstrap machine),電腦名稱為「Tanzu-CLI」,透過「ssh-keygen -t rsa -b 4096」指令建立 SSH Key Pair。

接著,這應該也是很多人漏掉的地方,因為安裝文件也沒有描述清楚這段 😱。簡單來說,必須過 ssh-agent指令,將 SSH Private Key儲存在 Windows 安全性內容中,並且和 Windows 登入使用者帳號產生關聯,後續需要 SSH Private Key 進行驗證時,ssh-agent就會自動擷取儲存的 SSH Private Key 內容,並且傳遞給 SSH Client 進行驗證。

請透過下列指令,將 ssh-agent 服務啟動後,再透過 ssh-add指令,將產生的 SSH Private Key 新增至 ssh-agent 的 Windows 安全性內容中。

處理好 SSH Key Pair 和 SSH Private Key 之後,再次執行 TCE Standalone Cluster on vSphere 部署作業便順利成功了。




關於站長

$
0
0



關於本站

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





Weithenn 摸索 IT 世界回顧:






2021 年

11 月: 

         (1) 擔任 臺灣雲端大會 Cloud Edge Summit Taiwan 2021  議程講師。  
         (2) 擔任 DevOpsDays Taipei 2021 議程講師。 




7 月: 




3 月: 

         (1) 擔任 台北資策會 - VMware vCenter Server HA 高可用性實戰班   課程講師。  
         (2) 擔任 台北資策會 - Microsoft Hyper-V 伺服器虛擬化實戰班   課程講師。 
         (3) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。 


2 月: 

         第 10 年 當選 VMware vExpert 2021 技術專家 VMware vExpert Information - Wei-Ren Wang






2020 年

9 月: 

         擔任 Taiwan Cloud Edge Summit 2020議程講師。




7 月: 

         (1) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。 
         (2) 第 9 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang



4 月: 

         (1) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。
         (2) 擔任 Taiwan Global Azure 2020議程講師。




3 月: 

         (1) 擔任 台中資策會 - Microsoft Azure IaaS 實戰班 課程講師。
         (2) 擔任 台北資策會 - VMware vSphere 伺服器虛擬化實戰班  課程講師。
         (3) 第 9 度當選 VMware vExpert 2020 技術專家 VMware vExpert Information - Wei-Ren Wang


         (4) 擔任 2020 儲存趨勢論壇 (StorTrends 2020) 議程講師。



2 月: 

         地球村走一回,今年插旗的國家是 葡萄牙之旅



1 月: 

          (1) 擔任 台中資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。
          (2) 和 VMware Taiwan 共同舉辦第一次 Taiwan VMUG (VMware User Group) 聚會






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,這是由全球 1514VMware 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) 貢獻 虛擬化環境導入評估工具 MAPStorage 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) 與 Channel 9 Taiwan 合作「建立 Microsoft Azure IaaS 雲端基礎建設」線上課程,進行字幕及簡報的翻譯及審校。

2 月: 

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






2014 年

12 月: 

          貢獻 MVMC 2.0Windows 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 2014MVA - 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 虛擬化環境實戰 (初級篇)

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


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

6 月: 

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

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


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

5 月: 

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

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

4 月: 

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

          (2) 第 3 度當選 VMware vExpert 2014VMware 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 2013VMware 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 界工作。

    Unable to Power off a Virtual Machine in an ESXi host

    $
    0
    0


    Question: Unable to Power off a Virtual Machine in an ESXi host

    這台 VM 虛擬主機為 Windows 作業系統,採用 RDP 已經無法連線,從 VMware Remote Console 無論是執行 Shutdown 或 Power Off 的動作,都會得到「Another task is already in progress」的錯誤訊息,無法順利將 VM 虛擬主機關機。



    Answer:

    在本文環境中,即便連接至 VM 虛擬主機運作的 ESXi 主機,透過 vSphere Host Client 介面仍然無法關機,並且得到一樣的錯誤訊息。

    接著,採用 VMware KB 1014165中提到的另一種方式,透過 ESXi esxcli指令便解決了。詳細資訊請參考:
    首先,將 ESXi 主機開啟 SSH 服務,登入後透過「esxcli vm process list | grep -B6 <VM_Name>」,找出該台 VM 虛擬主機的 World ID,然後使用「esxcli vm process kill --type=[soft,hard,force] --world-id=WorldNumber」,其中 soft參數就是 graceful 關機程序,而 hard參數則是 immediate shutdown,至於 force參數則是暴力關機了。很幸運的,本文環境採用 soft參數就順利把 VM 關機了 😁。


    Tanzu Community Edition 初探

    $
    0
    0


    前言

    簡單來說,TCE (Tanzu Community Edition) 是個功能齊全、易於管理的 Kubernetes 平台,並且可以免費使用和社群支援的開放源始碼計劃,透過 Cluster API達到支援 K8s 叢集的管理和維護的目標。

    下列為相關參考資源:



    TCE 版本比較表

    事實上,VMware Tanzu 是個產品就像 VMware vSphere 一樣,所以容器管理這部份共有四種版本,其中三種商業版本「Tanzu Basic / Standard / Advanced」和社群版本「Tanzu Community Edition」。下列便是這四種版本的功能比較表,可以看到社群版本和 Tanzu Standard 版本功能差不多,甚至支援的功能超過 Tanzu Basic 版本。 




    TCE 功能簡介

    對於管理人員來說,在建構和管理K8s叢集時,最困擾的部份便是相關需求和解決方案該採用哪個套件。在 TCE 運作架構中,已經為管理人員準備好,在管理和維運 K8s 叢集時會需要的相關解決方案,例如,處理容器虛擬網路的 Antrea 和 Calico、存放容器印象檔的 Harbor、運作 Serverless 架構的 Knative、資料數據圖形化的 Grafana……等。




    TCE 入門教學影片

    下列影片由 VMware Tanzu 團隊製作的 TCE 架構入門,看完後應該可以對 TCE 有個整體的初步了解。


    網管人 192 期 - 升級 vSphere 7 U3 新版機敏資訊保護更周全

    $
    0
    0


    網管人雜誌

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





    本文目錄






    前言

    隨著最新 VMworld 2021 大會拉開序幕,VMware 官方也同步發佈最新版本 vSphere 7 Update 3vSAN Update 3。首先,在容器運作效能方面,VMware 官方宣佈在 vSphere with Tanzu 容器平台上,運作的容器數量和其它主流容器平台及裸機架構相較之下,不僅運作數量多出「6.3 倍」之外(如圖 1 所示),並且容器運算節點也未發生不穩定或效能不佳的情況。

    圖 1、vSphere with Tanzu 和其它容器平台相較之下,可運作多達 6.3 倍的 Pod 數量

    除了在容器數量勝出其它容器平台之外,也同時與 GPU/vGPU 技術進行整合(如圖 2 所示)。因此,企業和組織內的資料科學家針對 AI/ML 等工作負載時,都可以達到更快速的開發週期和縮短模型訓練時間。

    圖 2、NVIDIA 和 VMware 合作的 AI-Ready Enterprise Platform 運作架構示意圖





    vSphere 7 Update 3 亮眼特色功能

    vCenter Server 雲端更新機制落地

    在過去的 vSphere 版本中,當 vCenter Server 必須執行重大安全性更新或版本升級時,由於 vCenter Server 管理平台,必須執行部署新版本的目的端 vCSA、停止來源端 vCSA 系統服務、安裝安全性更新、安裝 Binary 檔案、執行相關自動化腳本、關閉來源端 vCSA、目的端 vCSA 啟動系統服務……等動作,除了一開始部署新版本的目的端 vCSA 動作之外,其餘的動作將會讓 vCenter Server 管理平台產生「停機時間」(Downtime),導致版本升級的整體停機時間過長。

    在最新的 vSphere 7 U3 版本中,VMware 官方將原有 VMware Cloud 公有雲環境的「vCenter Server RDU(Reduced Downtime Upgrade)」機制,正式落地到企業和組織的地端資料中心內。簡單來說,透過 RDU 的 API-Driven 機制可以讓 vCenter Server 管理平台,在執行定期安全性更新或升級版本的工作任務時,將「停機時間」(Downtime)縮短到最低。
    RDU 的 API-Driven 機制,為 VMC on AWS 公有雲和 Project Arctic 專案所演化而來的技術。

    下列為透過新版 RDU 機制,幫 vCenter Server 管理平台進行版本升級時的流程(如圖 3 所示):
    • 階段一: 建立和部署新版本的目的端 vCSA 主機。
    • 階段二: 將來源端 vCSA 主機中,資料庫和組態設定檔內容複製到目的端 vCSA 主機。
    • 階段三: 當系統判定來源端和目的端 vCSA 主機,在資料庫和組態設定檔內容皆同步且一致時,才執行「切換」(Switch Over)的動作。整個流程只有在執行切換動作時,才會對 vCenter Server 管理平台造成短暫的停機時間。
    • 階段四: 目的端 vCSA 主機完成接手 vCenter Server 管理平台服務,系統執行關閉和清除來源端 vCSA 主機的動作。
    圖 3、vCenter Server 透過 RDU 機制執行版本升級流程示意圖

    雖然,透過 RDU 機制能夠有效避免 vCenter Server 管理平台,因為進行更新或升級版本的工作任務時導致系統損壞的情況。然而,它並不能夠取代企業或組織原有的 vCenter Server 備份機制,這點是管理人員容易忽略的部份。



    vMMR 機制增強記憶體監控範圍

    了解和管理過 vSphere 虛擬化環境的管理人員便知,記憶體資源在 vSphere 基礎架構中的重要性。事實上,即便配置在多的記憶體資源都會發現不足,當然記憶體資源的預算佔比過高也是導致資源無法充足的原因之一,根據統計 DRAM 記憶體資源的預算花費,約佔每台伺服器的 50~60%,倘若拉高規格配置至 1 TB DRAM時,更會佔用每台伺服器 75%的預算費用。

    因此,近年來開始流行導入「PMem(Persistent Memory)」技術,市場上大約有 NVDIMM-N 和 DCPMM 等二種主流類型。簡單來說,傳統上 DRAM 雖然速度最快,但是最大的缺點在於伺服器一旦關機後,儲存於其中的資料便消失殆盡,而 PMem 雖然速度不如 DRAM,但是最大優點在於當伺服器關機後,資料仍然能夠儲存於其中不會消失,並且在價格上也較 DRAM 便宜,同時在速度和效能方面又優於任何傳輸介面的 SSD 固態硬碟(如圖 4 所示)。
    DCPMM(Intel Optane DC Persistent Memory),雖然延遲時間高於 DRAM 但差距僅在「奈秒」(nanoseconds),並且可以直接使用硬體伺服器的 DDR4 記憶體插槽。
    圖 4、記憶體和儲存裝置效能及價格差異示意圖

    在應用方面 DCPMM 支援多種不同運作模式,包括,App Direct Mode、Memory Mode、Mixed Mode、vPMem、vPMemDisk 等,方便管理人員針對不同的效能需求和層級使用 DCPMM 資源。
    • App Direct Mode : 應用程式直連模式,通常用於改善 VM 虛擬主機中應用程式的 I/O 儲存效能,例如,SAP HANA、Oracle、MSSQL、Redis……等資料庫。但是,必須針對應用程式進行調整,例如,允許客體作業系統能夠使用 PMem 持久性儲存,才能有效提升儲存效能減少 I/O 瓶頸。
    • Memory Mode : 記憶體模式,透過 PMem 更便宜且容量更大的特性,將 PMem 資源轉化為 DRAM 給 vSphere 使用,並且關閉 PMem 持久性儲存的特色。簡單來說,可以使用更低的成本大幅提升 vSphere 的 DRAM 記憶體資源,並且 VM 虛擬主機和應用程式無須任何調整即可使用。
    • Mixed Mode: 混合模式,允許管理人員針對 PMem 資源配置使用百分比,例如,配置 35% 為 App Direct Mode,而剩下的 65% 為 Memory Mode。
    • vPMem 和 vPMemDisk : 讓 VM 虛擬主機,能夠直接使用 NVDIMM-O 資源,或是將 PMem 資源配置成為 VM 虛擬主機的虛擬硬碟(如圖 5 所示)。
    圖 5、在 vSphere 運作架構中的 PMem 資源使用示意圖

    透過 PMem 資源的 Memory Mode 機制,能夠在有限的 IT 預算之內最大化 vSphere 記憶體資源,舉例來說,在 ESXi 主機配置 256GB 的傳統 DRAM,加上新式的 512GB PMem 並開啟 Memory Mode 後,管理人員便可以在 vCenter Server 操作介面中,依序點選「Configure > Hardware > Overview > Memory」,即可看到 Memory 分層資訊,並確保 PMem 資源正確採用為 Memory Mode(如圖 6 所示)。

    圖 6、確認 PMem 資源採用 Memory Mode

    然而,即便再耐用的 DRAM 和 PMem 資源,都將因為運作時間拉長而可能產生故障,造成 VM 虛擬主機、應用程式、容器……等工作負載效能異常或低落。因此,最新 vSphere 7 U3 版本中,新增支援「Host Level / VM Level」這二個層級在 DRAM 和 PMem 記憶體資源方面的監控和修復機制(如圖 7 所示),所以無論是 ESXi 主機或 VM 虛擬主機層級,在 DRAM 和 PMem 效能發生問題時都會發出告警,當然管理人員也可以自行定義相對事件發生時觸發告警機制。

    圖 7、新版 vSphere 7 U3 支援監控和修復 DRAM 和 PMem 記憶體資源



    更智慧的 vCLS 調度機制

    在過去的 vSphere 版本中,管理人員並無法針對 vCLS 調整進階組態設定,所以有可能會影響其它工作負載造成潛在問題。因此,在新版 vSphere 7 U3 版本中,同樣將 VMC on AWS 雲端環境中,智慧型的運算工作負載原則落地到地端資料中心內。
    有關 vCLS 組態設定 Smarter Affinity 機制的詳細資訊,請參考 VMware KB79892KB80472知識庫文章。

    此外,新版中針對自動化產生的 vCLS 虛擬主機的隨機名稱,改為用 UUID 取代之外(如圖 8 所示),也取消過去採用的「空格」和「括號」等名稱規則,避免自動化腳本發生非預期性的問題。

    圖 8、新版中針對自動化產生的 vCLS 虛擬主機隨機名稱改為用 UUID 取代





    vSphere 安全加強 – 保護機敏資訊

    在虛擬化浪潮的推波助瀾下,企業和組織在地端資料中心內將工作負載虛擬化的比例不斷提升,雖然在 VM 虛擬主機作業系統內,已經有許多安全性機制保護內部應用程式和機敏資料。然而,許多管理人員卻可能忽略最根本的安全性防護機制,也就是 vSphere 虛擬化基礎架構的保護。

    因此,下列將根據最新發佈的 VMware CyberSecurity Awareness Month 2021建議要點,提醒管理人員務必檢查和審視 vSphere 虛擬化基礎架構中,容易被忽略的基礎安全性設定,在著重工作負載和效能調校的同時,也應注意根本的安全性設定有效提升 vSphere 整體防護層級。



    確保誰能存取 vCenter Server

    在企業和組織內的管理人員,常常身兼數職之外還必須處理日常工作事務,例如,哪台 VM 虛擬主機當機需要重新啟動、哪台 VM 虛擬主機效能不佳、誰的密碼過期需要重新設定……等。同時,有可能管理人員的調動或離職,在過渡期間未即時停用或刪除該帳號造成安全性漏洞,甚至心生怨恨的員工透過這樣的正常存取管道,連回公司刪除重要商務資料犯下大錯的新聞也時有耳聞。

    首先,在管理介面中依序點選「Administration > Single Sign On > Users and Groups > Groups > Administrators」,即可看到具備 vSphere 架構中最大管理權限 Administrators 群組中有誰,在一般管理思維情況下,通常會採用使用者群組的方式,例如,vSphere Admins,將相關管理人員加入群組以方便管理。然而,這樣的管理架構缺點在於,當 Windows AD 團隊和 vSphere 團隊不同管理人員時,就有可能發生上述過渡期間安全性漏洞的問題,因為在 vSphere 管理介面中,是無法查看使用者群組內詳細的使用者帳號清單的,所以面對這種情況時的管理思維,應該單獨將具備管理權限的使用者帳號加入,例如,Weithenn,以避免 Windows AD 和 vSphere 管理團隊落差的情況(如圖 9 所示)。

    圖 9、檢查並審視 vSphere Administrators 群組管理人員帳號



    停用 SSH 通訊協定

    在 vSphere 運作架構中,vCenter Server 和 ESXi 虛擬化平台,透過啟用 SSH 通訊協定進行故障排除和其它維護工作任務,例如,管理人員需要從 ESXi 主機複製 VM 日誌檔案……等。值得注意的是,執行完故障排除和維護工作任務之後,應該立即將 SSH 通訊協定進行停用,然而許多時候管理人員可能一時疏忽,或是正要準備停用 SSH 通訊協定時被其它事情打斷而忘記,這便是造成安全性風險的情況。

    因為,一旦 ESXi 開啟 SSH 通訊協定,任何登入到 Shell 環境的人員,基本上相當於在 Linux 作業系統中獲得「root」帳號和權限,雖然在 Shell 環境下的所有操作都會同步記錄到系統日誌當中,但稍有資訊安全的管理人員便知,所有惡意程式一旦掃描到主機有開啟 SSH 通訊協定時,便會嘗試使用 root 帳號搭配常用密碼,甚至使用暴力破解密碼的方式登入,造成安全性漏洞的產生。

    這就是為何一旦為 ESXi 開啟 SSH 通訊協定後,在 vCenter Server 管理介面中(如圖 10 所示),該台 ESXi 主機便會出現警告圖示,並且點選 Summary 頁籤時,系統會提醒管理人員該台 ESXi 主機,已經啟用 SSH 通訊協定的主要原因。

    圖 10、系統提示 ESXi 主機已經啟用 SSH 通訊協定

    當企業和組織的 vSphere 虛擬化架構中,有多台 ESXi 虛擬化平台時,上述透過 GUI 圖形化介面的檢查方式便不切實際,管理人員可以透過下列 PowerCLI,一次檢查指定的 vCenter Server 中所有的 ESXi 主機,是否啟用和執行 SSH 通訊協定並且關閉 SSH 通訊協定。
    Get-VMHost | Get-VMHostService | Where-Object {$_.Key -eq 'TSM-SSH' -and $_.Running -eq 'True'}
    Get-VMHost | Get-VMHostService | Where-Object {$_.Key -eq 'TSM-SSH'} | Set-VMHostService -Policy Off
    Get-VMHost | Get-VMHostService | Where-Object {$_.Key -eq 'TSM-SSH'} | Stop-VMHostService

    值得注意的是,有些管理人員可能會開啟 SSH 通訊協定,卻又不希望 ESXi 主機顯示警告圖示和系統提示訊息,所以透過調整「UserVars.SuppressShellWarning」進階參數的方式,隱藏警告圖示和提醒訊息(如圖 11 所示),這樣的系統管理方式並未受到 VMware 官方的推薦,管理人員應該採用預設值開啟警告提示功能,這才是 VMware 官方建議的方式。
    有關啟用 SSH 通訊協定,卻又想隱藏警告圖示和提醒訊息的詳細資訊,請參考 VMware KB2003637知識庫文章。
    圖 11、透過調整進階參數的方式,隱藏系統的警告圖示和提醒訊息

    此外,在 vCenter Server 啟用 SSH 通訊協定的部份,也常常被管理人員所遺忘。因為,在安裝 vCenter Server 過程中,系統會提示需要建立 vCenter Server HA 高可用性機制時,必須為 vCenter Server 啟用 SSH 通訊協定才行,所以有些管理人員為了確保後續可以順利建立 vCenter Server HA 機制,便在安裝過程中不經意的為 vCenter Server 啟用 SSH 通訊協定,然而在目前的 vCenter Server 管理介面中,卻不會提醒管理人員 vCenter Server 已經啟用 SSH 通訊協定。

    因此,管理人員可以登入至 vCenter Server Management 管理介面中,依序點選「Access > Access Settings > Edit > Enable SSH Login」,即可停用 vCenter Server 的 SSH 通訊協定(如圖 12 所示)。

    圖 12、停用 vCenter Server 的 SSH 通訊協定

    同樣的,管理人員也可以透過下列 PowerCLI,為 vCenter Server 停用 SSH 通訊協定。
    Invoke-GetAccessSsh
    $AccessSshSetRequestBody = Initialize-AccessSshSetRequestBody -Enabled $false
    Invoke-SetAccessSsh -AccessSshSetRequestBody $AccessSshSetRequestBody



    啟用 Lockdown Mode 安全機制

    有經驗的 vSphere 管理人員便知,當 ESXi 虛擬化平台被 vCenter Server 納入管理之後,便應該只透過 vCenter Server 管理和維護 ESXi 主機,而非透過 vSphere Host Client 去連結「單台」ESXi 主機,因為此舉可能會造成該台 ESXi 主機的組態,和 vCenter Server 資料庫中的組態設定不一致導致非預期的錯誤產生。

    因此,管理人員可以透過啟用 ESXi 主機的「Lockdown Mode」機制,來避免當 ESXi 主機已經被 vCenter Server 納入管理,卻又有新手管理人員透過 vSphere Host Client 管理和維護 ESXi 主機的情況產生。事實上,啟用 Lockdown Mode 機制非常簡單,在管理介面中依序點選「Datacenter > Cluster > ESXi > Configure > System > Security Profile > Lockdown Mode > Edit」,即可啟用和選擇採用 Lockdown Mode 的哪種運作模式(如圖 13 所示)。
    有關啟用 Lockdown Mode 的詳細資訊,請參考 VMware KB1008077知識庫文章。
    圖 13、為 ESXi 主機啟用和選擇採用哪種 Lockdown Mode 運作模式

    在正式啟用 ESXi 主機 Lockdown Mode 之前,管理人員應先了解 Lockdown Mode 的三種運作模式和差異:
    • Disabled: 已停用模式,此運作模式為預設值,也就是允許管理人員可以透過各種機制連線和管理 ESXi 主機,例如,vSphere Host Client、SSH、ESXi Shell、DCUI(Direct Console User Interface)、vCenter Server……等。
    • Normal正常模式,管理人員僅能透過 vCenter Server 或 DCUI 機制連線和管理 ESXi 主機,嘗試透過 vSphere Host Client、SSH、ESXi Shell 連線 ESXi 主機時,將會得到拒絕連線的訊息(如圖 14 所示)。此模式也是 VMware 建議管理人員採用的運作模式。
    • Strict嚴格模式,管理人員僅能透過 vCenter Server 連線和管理 ESXi 主機,嘗試採用其它機制連線 ESXi 主機時,都會得到拒絕連線的訊息(如圖 15 所示)。
    圖 14、採用 Normal 運作模式時,無法透過 vSphere Host Client 連線和管理 ESXi 主機

    圖 15、採用 Strict 運作模式時,甚至連 DCUI 機制都無法登入 ESXi 主機

    此時,可能有管理人員會問,倘若 vCenter Server 為 VM 虛擬主機並且運作在 ESXi 主機內,當地端資料中心因為災難或歲休而關閉 vCenter Server 時,那麼該如何登入 ESXi 主機並 Power On vCenter Server 呢?

    根據 VMware 的建議,採用 Lockdown Mode – Normal運作模式時,雖然僅允許 vCenter Server 或 DCUI 機制連線和管理 ESXi 主機,然而當發生上述情況時,管理人員可以先透過 DUCI 機制登入 ESXi 主機,將 Lockdown Mode 機制關閉(如圖 16 所示),然後再透過 vSphere Host Client 登入 ESXi 主機並啟動 vCenter Server,待 vCenter Server 恢復正常運作後,再次為 ESXi 主機開啟並採用 Lockdown Mode – Normal 運作模式。

    圖 16、透過 DCUI 暫時關閉 Lockdown Mode 機制

    值得注意的是,有些管理人員可能已經注意到 Lockdown Mode 機制,可以組態設定「例外使用者」(Exception Users),也就是在例外人員清單中的使用者帳號(如圖 17 所示),不會受到 Lockdown Mode 運作模式的影響,但這並非 VMware 所建議的安全性設定,因為此舉同樣讓 ESXi 主機暴露在攻擊風險中,因為系統安全性和操作便利性一直以來便是互相的兩個拉扯點,從來沒有系統管理人員在操作上非常便利,同時系統安全層級也維持在高安全性的機制,唯有操作上越麻煩在系統遭受攻擊時,才同樣會讓攻擊者不易侵入系統的安全性機制。

    圖 17、組態設定 Lockdown Mode 例外人員清單

    同樣的,管理人員可以透過下列 PowerCLI,一次為大量的 ESXi 主機組態設定啟用 Lockdown Mode – Normal 運作模式。倘若,希望採用 Lockdown Mode – Strict 運作模式的話,可將 PowerCLI 內容中「lockdownNormal」關鍵字修改為「lockdownStrict」,希望加入例外使用者時,只要將 PowerCLI 內容中「$NULL」關鍵字,修改為例外使用者帳號即可,例如,root。
    $Hosts = Get-VMHost
    foreach($ESXi in $Hosts){
    $view =(Get-VMHost $ESXi | Get-View)
    $accessmanager =(Get-View $view.ConfigManager.HostAccessManager)
    $accessmanager.ChangeLockdownMode("lockdownNormal")
    $accessmanager.UpdateLockdownExceptions($NULL)
    }



    啟用 VIB 安裝管控機制

    在 Windows 作業系統中有 MSI(Microsoft Installer),在 Linux 作業系統中常見有 RPM(Redhat Package Manager)等套件安裝和管理機制,在 VMware vSphere 虛擬化架構中則稱為 VIB(vSphere Installable Bundle)

    當管理人員手動為 ESXi 安裝更新或其它支援套件時,應該先確認這個 VIB 的「接受等級」(Acceptance Level)之後,再判斷是否進行安裝的動作,否則有可能會影響 ESXi 虛擬化平台的效能和穩定性,舉例來說,管理人員為 ESXi 主機安裝由某個 VMware 社群所發佈的 VIB,由於該 VIB 並未通過 VMware 審核的測試計畫,當然不受 VMware 官方和合作夥伴的技術支援。

    簡單來說,VMware 官方針對不同類型的 VIB 共有四種接受等級:
    • VMwareCertified: 受到 VMware 最嚴格的要求並完整通過所有測試項目,例如,IOVP(I/O Vendor Program),等同於該 VIB 套件受到 VMware 內部品質測試保證,所以 VMware 將接受該 VIB 套件的所有技術支援。
    • VMwareAccepted: 僅通過相關測試項目而非全面測試,例如,CIM providers、PSA plug-ins,VMware 合作夥伴會先執行測試後,再交給 VMware 官方驗證結果並發佈,所以 VMware 會把該 VIB 套件的技術支援轉交給該合作夥伴。
    • PartnerSupported: 由 VMware 合作夥伴所發佈並通過相關測試,例如,Infiniband、SSD driver,通常合作夥伴在 VMware 環境中啟用新技術或支援非主流技術時使用,同樣的 VMware 會把該 VIB 套件的技術支援轉交給該合作夥伴。
    • CommunitySupported: 未通過任何一項 VMware 測試項目,所以不受 VMware 官方和合作夥伴的技術支援。

    管理人員可以先確認 ESXi 主機預設採用的接受等級,然後再檢查所要安裝的 VIB 套件接受等級為何。請在管理介面中,依序點選「Datacenter > Cluster > ESXi > Configure > System > Security Profile > Host Image Profile Acceptance Level > Edit」,即可調整 ESXi 主機預設採用的接受等級(如圖 18 所示)。
    管理人員也可以透過「esxcli software acceptance get」指令,檢查 ESXi 主機的接受等級。
    圖 18、即可調整 ESXi 主機預設採用的接受等級

    此外,管理人員也可以透過「esxcli software vib list」指令,查詢目前 ESXi 虛擬化平台中,已經安裝哪些 VIB 套件和接受等級為何(如圖 19 所示),確保 ESXi 虛擬化平台的安全性和穩定性。倘若,發現有安裝 CommunitySupported 接受等級的 VIB 套件,也可以使用「esxcli software vib remove -n <VIB_Name>」指令進行移除。
    有關 esxcli 指令安裝 VIB 套件的詳細資訊,請參考 VMware KB2008939知識庫文章。
    圖 19、查詢目前 ESXi 虛擬化平台中已經安裝哪些 VIB 套件和接受等級





    結語

    透過本文的深入剖析和實戰演練基本安全性設定後,相關管理人員已經了解最新發佈的 vSphere 7 Update 3 的亮眼新功能,能夠幫助企業和組織解決哪些困擾已久的問題。此外,透過基本安全性組態設定,提醒管理人員在著重調校各項效能數據時,也別忘了鞏固 vSphere 虛擬化基礎架構的安全性,確保企業和組織機敏資料不外洩。

    A vmkernel nic for the connection point already exists

    $
    0
    0


    Question: A vmkernel nic for the connection point already exists

    原本建立的 VMkernel Port (vSAN / vMotion) 因為種種原因,導致在 vCenter Server 管理介面中已經看不到了,剩下管理用途的 VMkernel Port (Management)。


    嘗試再次建立 VMkernel Port (vSAN / vMotion) 時,卻出現「A vmkernel nic for the connection point already exists」錯誤訊息?




    Answer: 

    簡單來說,就是 ESXi 上的 VMkernel Port 和 vCenter Server 資料庫內的記錄已經不同步所導致。請在目標 ESXi 主機上開啟 SSH 登入後,透過指令「esxcli network ip interface list」列出此台 ESXi 主機上的 VMkernel Port 清單。可以看到,確認還記錄著 vmk1 / vmk2 (但是 vCenter Server 管理介面中看不到 😩)。


    透過「esxcli network ip interface remove --interface-name=<VMkernel_Port_Name>」指令,把 vCenter Server 管理介面中,已經看不到的 VMkernel Port 裝置名稱移除,本文實作環境為「vmk1 / vmk2」。然後,再次執行「esxcli network ip interface list」指令,可以看到 ESXi 主機僅列出「vmk0」裝置名稱,狀態已經跟 vCenter Server 管理介面看到的一致。


    此時,回到 vCenter Server 管理介面,再次嘗試新增 VMkernel Port 便能建立成功 😁。


    Viewing all 591 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>