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

[站長開講] SecuForum 2018

$
0
0

活動簡介

重大資安及外洩事故層出不窮,面對駭客集團挾犯罪獲利持續強化威脅手段,以往深溝高壘的被動防禦模式早已失效。在企業藉由新興資訊科技的力量,贏得下一波數位化時代的競爭力之際,更須同步進行資安轉型,以合理有效的措施降低數位風險,將是邁向成功的關鍵。


資安防線必須從傳統的單點式阻斷,延伸擴展至全面性整合防禦,以不同領域的威脅情資訊息為基礎,整合運用既有資源,採取化被動為主動的方式建立聯合防禦體系,才有機會與現代攻擊手法相抗衡。本次由《網管人》雜誌舉辦的「2018 企業資安實務策略論壇」中,以情資力、聯防力、主動力為主軸,邀請您參與共同探討實際可行的反制之道。





活動資訊

  • 日期: 2018 年 9 月 11 日 (星期二)
  • 時間: 8:30 ~ 16:40
  • 地點: 台北 張榮發國際會議中心 801會議室(台北市中山南路11號8樓)
  • 報名活動報名





活動內容





[站長開講] Windows Server 高峰會

$
0
0

活動簡介

Windows Server 2019即將於 10/1正式開賣,美國也將於九月下旬正式宣布 Windows Server 2019 GA。台灣微軟領先於 9/21 舉辦 Windows Server 高峰會,邀請三位業界大神級講師 – 曹祖聖、保哥以及王偉任來講述 Windows Server 2019 四大重點,同時提供豐富的技術展示。


此外,從 Windows Server 2019 開始,與 Azure Hybird 整合將是一大重點,我們將展示 Windows Server 如何輕鬆整合 Azure 簡化整個 IT 營運管理 – 包含與 Azure 整合打造出低成本高效率 HA File server。

同時,隨著 Windows Server 2008/R2 EOS日期接近,我們也將展示如何利用 Azure Migrate 快速針對線有環境進行分析, ROI 分析, 以及快速移轉到 Azure。這是一場 Windows Server 2019 + Azure Better together 的絕對技術展示,可以讓您感受到微軟 Windows Server 領先業界之絕佳技術。






活動資訊

  • 日期: 2018 年 9 月 21 日 (星期五)
  • 時間: 9:00 ~ 18:00
  • 地點: 台灣微軟 MPR123 會議室(台北市信義區忠孝東路五段 68 號 19 樓)
  • 報名活動報名





活動內容


WAC - 解決納管 S2D HCI 時無法識別叢集名稱

$
0
0

Q.Can`t verify whether "S2D_ClusterName" is online?

Error Message:
嘗試使用 WAC (Windows Admin Center) 納管 S2D HCI (Hyper-Converged Infrastructure) 叢集時,卻出現下列錯誤訊息,說明 WAC Host 無法識別 S2D HCI 叢集?




Ans:
在本文實作環境中,採用 Windows Server 2016建立 S2D HCI (Hyper-Converged Infrastructure)叢集架構,所以必須確認下列事項:


由於,已經符合上述條件但還是無法讓 WAC 順利納管 Windows Server 2016 S2D HCI Cluster,所以嘗試到 Windows Server User Voice去回報這個問題。

發現問題的原因,在於 Windows Server 2016 S2D HCI Cluster 節點主機中,有部分節點主機沒有 S2DCacheBehavior及 S2DCacheDesiredState屬性值所導致。導致這樣的原因,是因為當時 Windows Server 2016 S2D HCI Cluster 建立時便是由 3 台節點主機所搭建,而經過半年後才又加入 2 台節點主機。

如下圖可以看到,在 S2D HCI Cluster 環境中有 5 台節點主機,但是屬性值卻只有前 3 台節點主機有。


至機碼路徑「HKEY_LOCAL_MACHINE\Cluster\Nodes」可以看到,跟剛才 PowerShell 所查詢的結果相同,節點主機 SDS14、SDS15 沒有 S2DCacheBehavior 及 S2DCacheDesiredState 屬性值所導致。


知道原因後,我們便可以新增機碼項目及值即可:
New-Item -Path 'HKLM:\Cluster\Nodes\4\Parameters'
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\4\Parameters' -Name S2DCacheDesiredState -PropertyType DWORD -Value 2
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\4\Parameters' -Name S2DCacheBehavior -PropertyType QWORD -Value 88



新增後,再次至機碼路徑重新整理後,便可以看到順利新增機碼項目及值 (S2D Node 無須重新啟動)。


同樣的動作,為 SDS15 節點主機新增機碼項目及值:
New-Item -Path 'HKLM:\Cluster\Nodes\5\Parameters'
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\5\Parameters' -Name S2DCacheDesiredState -PropertyType DWORD -Value 2
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\5\Parameters' -Name S2DCacheBehavior -PropertyType QWORD -Value 88




此時,便可以看到在 Windows Server 2016 S2D HCI Cluster 節點主機中,所有節點主機都有 S2DCacheBehavior 及 S2DCacheDesiredState 屬性值。


但是,上述的動作只有為 Windows Server 2016 S2D HCI Cluster 眾多節點主機中「其中一台」修復此問題而已,你必須要為 S2D HCI Cluster 中「所有」的節點主機修復這個問題才行。因此,我們可以透過下列 PowerShell 為 S2D HCI Cluster 所有的節點主機修復這個屬性缺少的問題:
$S2D_Nodes = ("SDS11","SDS12","SDS13","SDS14","SDS15")

icm $S2D_Nodes {
Get-ClusterNode | Get-ClusterParameter
}

icm $S2D_Nodes {
New-Item -Path 'HKLM:\Cluster\Nodes\4\Parameters'
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\4\Parameters' -Name S2DCacheDesiredState -PropertyType DWORD -Value 2
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\4\Parameters' -Name S2DCacheBehavior -PropertyType QWORD -Value 88
New-Item -Path 'HKLM:\Cluster\Nodes\5\Parameters'
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\5\Parameters' -Name S2DCacheDesiredState -PropertyType DWORD -Value 2
New-ItemProperty -Path 'HKLM:\Cluster\Nodes\5\Parameters' -Name S2DCacheBehavior -PropertyType QWORD -Value 88
}



順利為 S2D HCI Cluster 所有的節點主機修復這個屬性缺少的問題後 (S2D Node 無須重新啟動),即可透過 WAC 順利連接並管理 S2D HCI Cluster。




參考資源

網管人 152 期 - 新版 vSphere 6.7 大躍進功能強化新增一次說分明

$
0
0

網管人雜誌

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





文章目錄

前言
全面改用 HTML 5 vSphere Client
最後一版 Windows vCenter Server
ESXi 虛擬化平台再進化
          vSphere Quick Boot
安全性功能增強
          ESXi 虛擬化平台支援新式 TPM 2.0
          vTPM 2.0 擴大保護範圍至 VM 虛擬主機
舊有 VMFS 3 檔案系統正式停用
          LUN/Path 擴充性再提升
          支援新式 4Kn 儲存裝置
          原生支援 Intel VMD 技術
          支援新式 PMem NVDIMM 儲存裝置
正式支援 RDMA
          SW-FCoE 內建於 vSphere
結語





前言

在日前 2018 年 4 月 17 日時,VMware 官方正式發佈全新 vSphere 6.7 軟體定義資料中心解決方案,同時也發佈 SDDC 軟體定義資料中心內,最重要的 vCenter Server 6.7 管理平台、SDS 軟體定義儲存解決方案 vSAN 6.7 版本……等(如圖 1 所示)。雖然,只是從 vSphere 6.5 更新為 vSphere 6.7 的小版本更新,卻已經相隔約一年半後才推出。
前一版 vSphere 6.5軟體定義資料中心解決方案,於 2016 年 11 月 15 日發佈。
圖 1、VMware 最新發佈 VMware vSphere 6.7 打造 SDDC 軟體定義資料中心解決方案

雖然,只是 vSphere 6.x 的小版本更新,然而相關硬體資源支援度同樣再次倍數提升。在下列表格中,條列出企業及組織使用的主流版本 vSphere 6.0、6.5 及最新 vSphere 6.7 版本,在硬體資源支援度上有哪些提升(詳細資訊請參考 VMware KB 1003497 – ESXi Configuration Maximums)。
請注意,倘若企業或組織仍使用舊版 vSphere ESXi 5.5 及 vCenter Server 5.5 版本的話,那麼將於「2018 年 9 月 19 日」進入「終止支援(End Of Support,EOS)」,所以企業及組織應儘快進行版本升級的動作。





全面改用 HTML 5 vSphere Client

在過去舊版的 vSphere 運作環境中,管理人員皆是採用 vSphere Web Client(Flash)管理工具(如圖 2 所示)。在最新 vSphere 6.7 版本中,VMware 官方已經宣佈舊有 Flash-based的 vSphere Web Client 將為「最後一版」管理工具。

圖 2、舊有 Flash-based 的 vSphere Web Client 管理工具示意圖

因此,管理人員應該開始改為使用全新 HTML5-based的 vSphere Client 管理工具(如圖 3 所示),因為在新版 vSphere 6.7 當中的 HTML 5 vSphere Client 管理工具,其整體功能完整性已經達到「90% ~ 95%」,可以順利管理 vSAN、NSX、Storage Policies、Host Profile、vDS vSwitch……等,並且 VMware 官方預計於 2018 年秋天推出完整功能的 HTML 5 vSphere Client 管理工具。
有關 HTML 5 vSphere Client 管理工具,2018 年秋天推出完整功能的詳細資訊,請參考 VMware vSphere Blog - Fully Featured HTML5-based vSphere Client Coming in Fall 2018文章內容。
圖 3、新版 HTML5-based 的 vSphere Client 管理工具示意圖





最後一版 Windows vCenter Server

在新版 vSphere 6.7 運作架構中,vCSA(vCenter Server Appliance)管理平台已經是「預設」的部署選項。最新版本的 vCSA 6.7 管理平台,除了已經包含 PSC(Platform Services Controller)、Linked Mode……等功能外,透過新增的新式 API 相較於舊版 vCSA 6.5 管理平台在操作效能上提升 2 倍、記憶體資源使用量減少 3 倍、執行自動化遷移 VM 虛擬主機的 DRS(Distributed Resource Scheduler)機制遷移速度提升 3 倍……等(如圖 4 所示)。

圖 4、新版 vCSA 6.7 管理平台執行效率提升資源損耗下降示意圖

現在,管理人員可以透過新版 vCSA 6.7 管理平台,管理任何規模大小的 vSphere 虛擬化基礎架構,下列便是新版 vCSA 6.7 管理平台新增或增強的特色功能:
  • 所有 vCenter Server 服務在「單一執行個體」中運作。
  • 新增 Enhanced Linked Mode 至 Embedded PSC 運作架構中。
  • 無須建置負載平衡機制,即可輕鬆建立 vCSA HA 高可用性機制。
  • 支援 vSphere SSO(Single Sign-On)機制達成更高的靈活性,並在 vSphere SSO Domain 中允許進行 15 次的部署作業(如圖 5 所示)。
  • 完整支援 vSphere 大型運作規模。
  • 減少不必要的管理和維護節點主機數量。
  • 底層作業系統由 SUSE Linux 更改為 Photon OS,以便更容易達成 Rollback 機制。

圖 5、vSphere SSO Domain with Enhanced Linked Mode 運作示意圖

由於,vCSA 6.7 管理平台已經能完全取代 Windows vCenter Server 管理平台,因此隨著最新版本 vCSA 6.7 管理平台版本的發佈,VMware 官方也正式宣佈在 vSphere 6.7 版本中 vCenter Server for Windows 管理平台,為「最後一版」的 Windows vCenter Server 管理平台版本,這表示後續推出的新版 vCenter Server 版本中,VMware 官方將只會發佈 vCSA(vCenter Server Appliance)管理平台。

然而,企業或組織當中可能已經建立 Windows vCenter Server 管理平台,那麼該如何將 Windows vCenter Server 管理平台,遷移至最新 vCSA 6.7 管理平台? 有鑑於此,VMware 官方推出 VMware Migration Assistant 遷移工具(如圖 6 所示),幫助企業及組織將 Windows vCenter Server 管理平台,無縫遷移至最新 vCSA 6.7 管理平台。

值得注意的是,倘若為舊版 vSphere 5.5 的 Windows vCenter Server 管理平台,那麼必須先升級至 vSphere 6.x 版本才行,下列便是版本升級建議:
  • vCenter Server 6.0 / 6.5 版本,可直接升級至最新 vCSA 6.7 版本。
  • vCenter Server 5.5 版本必須先升級至 vCenter Server 6.0 / 6.5 版本後,才能升級至最新 vCSA 6.7 版本。

有關 VMware Migration Assistant 遷移工具的詳細操作資訊,請參考本雜誌《第 150 期 – vSphere 管理平台大搬風,趁早無痛遷移 vCSA 6.7》文章內容。
圖 6、VMware Migration Assistant 遷移工具操作畫面示意圖

此外,VMware 官方針對 vCSA 管理平台,推出 VAMI(vSphere Appliance Management Interface)系統管理介面,搭配整合 UX Guidelines、HTML/CSS Framework 和 Angular 技術的 Clarity UI 協同運作,讓管理人員能夠擁有最佳的 vCSA 資源管理操作體驗。

現在,管理人員只要開啟瀏覽器,鍵入 vCSA 6.7 管理平台的 FQDN 或 IP 位址搭配「Port 5480」連接埠,即可看到 vCSA 管理平台的 VAMI 系統管理登入畫面,順利登入後即可看到 vCSA 管理平台的硬體資源情況,包含 CPU 工作負載、記憶體使用情況、vCSA 資料庫、儲存資源……等健康資訊(如圖 7 所示)。
VAMI 系統管理介面已經支援多國語系,例如,日語、法語、正體中文……等。
圖 7、透過 Clarity UI 技術打造的 VAMI 管理介面,快速掌握 vCSA 管理平台硬體資源健康情況





ESXi 虛擬化平台再進化

在新版 vSphere 6.7 運作架構中,再次增強並加速 ESXi 主機的生命週期以節省管理人員的維運時間,除了採用新式 HTML 5 vSphere Client 管理介面之外,在 VUM(vSphere Update Manager)管理介面的部分也同步翻新,讓管理人員在升級 vSphere ESXi 虛擬化平台的動作可以輕鬆完成。

在新式 VUM 管理介面中(如圖 8 所示),除了預先檢查 ESXi 虛擬化平台是否需要安裝修補程序或版本升級之外,在後續版本還將支援其它特色功能,例如,升級 VMware Tools 版本、硬體相容性檢查……等。

圖 8、新式 VUM 管理介面預先檢查 ESXi 虛擬化平台示意圖



vSphere Quick Boot

過去,當管理人員執行 ESXi 虛擬化平台版本升級作業時,通常 ESXi 虛擬化平台需要重新啟動數次(通常 2 ~ 3 次),同時現代化 x86 硬體伺服器配備的實體記憶體越來越大(數百 GB 甚至高達 TB),這樣的巨大硬體資源所需的初始化及檢查時間也將花費數分鐘,待硬體伺服器檢查程序完成後進入 vSphere Hypervisor 虛擬化管理程序時,又需要花費數分鐘進行初始化及檢查作業,導致 ESXi 虛擬化平台整體停機時間拉長許多。

在新版 vSphere 6.7 當中,透過新式的「vSphere Quick Boot」機制,進行 ESXi 虛擬化平台版本升級作業時除了「重新啟動 1 次」(Single Reboot)即可完成之外,同時無須執行硬體伺服器初始化及檢查作業,有效縮短 ESXi 虛擬化平台停機時間。

此外,過去管理人員需要重新啟動 vSphere Hypervisor 虛擬化管理程序時,只能透過重新啟動 ESXi 虛擬化平台的連動方式達成。現在,透過新版 vSphere Quick Boot 快速啟動機制,無須重新啟動 ESXi 虛擬化平台,即可達成重新啟動 vSphere Hypervisor 虛擬化管理程序的目的,此舉再次有效縮短 ESXi 虛擬化平台停機時間。

如圖 9 所示,左邊 Remote Console 的 ESXi 虛擬化平台,採用新式 vSphere Quick Boot 快速啟動機制,已經進入 vSphere Hypervisor 虛擬化管理程序,而右邊 Remote Console 的 ESXi 虛擬化平台,採用傳統的 Standard Reboot 機制仍在 x86 硬體伺服器初始化及檢查作業中。

圖 9、新式 vSphere Quick Boot 與傳統 Standard Reboot 開機速度比較示意圖





安全性功能增強

在目前混合及多雲的運作環境中,如何保護企業及組織的機敏資料更顯重要。因此,在新版 vSphere 6.7 中,ESXi 虛擬化平台正式支援 TPM 2.0(Trusted Platform Module),能夠儲存加密金鑰、憑證、雜湊……等資料,同時透過 vTPM 2.0機制更可以將保護範圍擴大到 VM 虛擬主機。
事實上,ESXi 虛擬化平台已經支援多年 TPM 1.2。值得注意的是,舊版 TPM 1.2 及新版 TPM 2.0 無法相容,因此舊有 TPM 1.2 的裝置驅動程式及 API 必須重新開發。



ESXi 虛擬化平台支援新式 TPM 2.0

在新版 vSphere 6.7 的運作架構中,當 ESXi 虛擬化平台採用的 x86 硬體伺服器,配置 TPM 2.0 安全性模組後,那麼 ESXi 虛擬化平台便能啟用「安全啟動」(Secure Boot)機制,透過底層硬體保護 ESXi 虛擬化平台的 UEFI Firmware、Boot Loader、VMKernel 等初始化及開機程序(如圖 10 所示)。

簡單來說,ESXi 虛擬化平台將安全性資訊儲存於 TPM 2.0安全性模組當中,而 vCenter Server 管理平台將會讀取相關資訊,例如,ESXi Event Log、VIB Metadata……等,並且與受管理的 ESXi 虛擬化平台進行匹配比較,確保 ESXi 虛擬化平台只會運作通過驗證的程式碼免於遭受攻擊。
事實上,在 vSphere 6.5 版本時便已經支援 Secure Boot,但當時僅能使用舊版 TPM 1.2 安全性模組進行實作,詳細資訊請參考 VMware vSphere Blog - Secure Boot for ESXi 6.5 – Hypervisor Assurance文章內容。
圖 10、Secure Boot 機制有效保護 ESXi 虛擬化平台初始化及開機程序



vTPM 2.0 擴大保護範圍至 VM 虛擬主機

當 ESXi 虛擬化平台配置 TPM 2.0 安全性模組後,便能啟用 vTPM 2.0機制並將加密金鑰、憑證、雜湊等機敏資料保護機制擴大到 VM 虛擬主機。

啟用 vTPM 2.0 機制的 VM 虛擬主機,在客體作業系統中將會如同實體主機一樣看到普通的 TPM 2.0 安全性模組,當管理人員需要進行加密金鑰、憑證、雜湊等機制保護機敏資料時,便會將相關資料寫入 VM 虛擬主機當中的 NVRAM 檔案內,同時採用 VM Encryption 機制保護該檔案,並且同時支援 Windows VBS(Virtualization-Based Security)安全性機制協同運作(如圖 11 所示)。

此外,啟用 vTPM 2.0 保護機制的 VM 虛擬主機,當遷移或匯出至其它資料中心或雲端環境時,倘若該資料中心或雲端環境未支援或使用 KMS(Key Management System),仍然可以透過原有的 vTPM 2.0 保護機制確保機敏資料無法被惡意人士所碰觸。

圖 11、TPM / vTPM 支援 Windows VBS 安全性機制示意圖





舊有 VMFS 3 檔案系統正式停用

在前一版 vSphere 6.5 當中,僅能支援讀取舊有的 VMFS 3 檔案系統但無法建立。在最新 vSphere 6.7 版本中,舊有的 VMFS 3檔案系統將正式 EOL(End of Life)停止使用(如圖 12 所示),所以管理人員倘若未將 VMFS 3 升級至 VMFS 5 檔案系統版本的話,那麼屆時將不會自動掛載 VMFS 3 檔案系統,屆時也將無法在 VMFS 3 檔案系統中建立或開啟檔案。
舊有 VMFS 3 檔案系統僅能升級至 VMFS 5 版本,再從 VMFS 5 升級至最新 VMFS 6 檔案系統,並不支援直接由 VMFS 3 升級至 VMFS 6 檔案系統版本。詳細資訊請參考 VMware KB2003813 - Frequently Asked Questions on VMware vSphere 5.x for VMFS-5文件內容。
圖 12、新版 vSphere 6.7 運作環境中,將正式停止支援舊有 VMFS 3 檔案系統



LUN/Path 擴充性再提升

在 vSphere 6.0 版本運作環境中,儲存資源 LUN 的最大支援數量為 256傳輸路徑 1,024,在 vSphere 6.5 時則提升為 LUN 最大支援數量 512傳輸路徑 2,048。在最新發佈的 vSphere 6.7 版本中,則再次將運作規模提升至 LUN 最大支援數量「1,024」傳輸路徑「4,096」。

此外,在 VM 虛擬主機的部分 VMDK 虛擬磁碟的數量,也從過去的 16 個增加至支援最多「64 個」,這表示當 VM 虛擬主機採用 PVSCSI 硬碟控制器時,可以掛載的虛擬磁碟總數多達「256 個」。

因此,過去在 vSphere 虛擬化運作環境中,當 VM 虛擬主機欲建置 Microsoft WSFC(Windows Server Failover Cluster)運作環境時,在 pRDM 的部分會有最大支援「45 個 vDisk / LUNs」的限制,現在則可以將其中 1 個 PVSCSI 硬碟控制器用於管理,另外 3 個 PVSCSI 硬碟控制器各自支援最多「64 個 vDisk / LUNs」,因此在 Microsoft WSFC 環境可擴大支援至總數「192 個 vDisk / LUNs」(如圖 13 所示)。

圖 13、新版 vSphere 6.7 擴大 VM 虛擬主機 vDisk/LUNs 支援數量



支援新式 4Kn 儲存裝置

在 vSphere 6.5 版本中,是採用 512e 來模擬 4Kn 的方式支援 4K Byte Sector 儲存裝置。現在,新版 vSphere 6.7 運作環境中,採用 4Kn SWE(Software Emulation)來支援 4K Byte Sector 儲存裝置(如圖 14 所示)。
一般來說 2011 年 1 月後出廠的硬碟,大多採用 4K Byte Sector進階格式,而非舊有傳統的 512 Byte Sector 格式。

值得注意的是 4Kn SWE 機制有一些使用上的限制,目前僅支援 ESXi 虛擬化平台中本機 SAS 及 SATA 機械式硬碟,同時必須格式化為最新的 VMFS 6檔案系統,並且必須採用 UEFI啟動方式才行。
目前的 4Kn SWE 機制,支援 SSD、NVMe 儲存裝置及 RDM、GOS 儲存資源。
圖 14、4Kn SWE(Software Emulation)儲存堆疊架構示意圖



原生支援 Intel VMD 技術

Intel VMD(Volume Management Device)技術,除了能夠匯整 NVMe PCIe SSD 底層的 Root Port 之外,還提供錯誤管理、熱插拔、LED 管理等特性達到 NVMe 儲存裝置的可維護性。

在新版 vSphere 6.7 運作環境中因為原生支援 Intel VMD 技術,所以安裝在 ESXi 虛擬化平台中的 DAS NVMe 儲存裝置可直接使用,而無須再額外安裝相關的 VIBs 套件後才能順利驅動,同時也能夠無縫與 vSAN 軟體定義儲存技術整合。現在,當 vSAN 或 DAS NVMe 發生升級問題或故障時,能夠直接更換「單個」NVMe 儲存裝置。

值得注意的是,必須採用最新的 Intel Xeon Scalable處理器(如圖 15 所示),並且安裝支援 Intel VMD 技術的 NVMe 驅動程式,同時執行 Intel VMD LED 管理功能指令的 ESXi 虛擬化平台版本,必須是 ESXi 6.0 U36.5或最新 6.7才支援該 Shell 指令。

圖 15、Intel VMD 技術運作架構示意圖



支援新式 PMem NVDIMM 儲存裝置

在新版 vSphere 6.7 運作環境中,支援新式 PMem(Persistent Memory)儲存裝置(如圖 16 所示)。簡單來說,PMem 為 NVDIMM(Non-Volatile DRAM)儲存裝置,具備 DRAM 高速傳輸但不會因為失去電力而遺失已儲存的資料。

圖 16、PMem(Persistent Memory)NVDIMM 儲存裝置示意圖

簡單來說,PMem NVDIMM 儲存裝置具備接近 DRAM 的高速特性,當 CPU 處理器進行存取作業時就像存取 DRAM 一樣。因此,資料存取速度相較於目前主流的 SSD 快閃儲存來說至少快上「100 倍」以上(如圖 17 所示)。

圖 17、主流 SSD 與新式 PMem 儲存裝置運作架構示意圖

值得注意的是,採用 vNVDIMM 儲存資源的 VM 虛擬主機,除了必須採用 Virtual Hardware version 14之外,在客體作業系統的部分也必須支援才行,例如,Windows Server 2016RedHat 7.4……等。此外,雖然支援大部分的 vSphere 虛擬化功能,但套用 vNVDIMM 儲存資源的 VM 虛擬主機,目前「不支援」快照及 HA 高可用性保護機制。





正式支援 RDMA

事實上,在 vSphere 6.5 虛擬化平台版本中,便已經開始支援 RDMA(Remote Direct Memory Access)RoCE(RDMA over Converged Ethernet),以便於達到「Kernel Bypass、Zero Copy、CPU Offloading」的目的,有效降低 ESXi 虛擬化平台處理大量網路封包的工作負載。
vSphere 6.5版本中,僅支援 RoCE v1 並且支援 InfiniBand 及 iWARP。

在新版 vSphere 6.7 運作環境中,全面支援 RDMA(InfiniBand、iWARP、RoCE v2)之外,更增強vSphere Kernel / Hypervisr / RDMA 之間的協同運作的部分(如圖 18 所示),讓整體運作效能更加提升。值得注意的是,倘若 VM 虛擬主機採用的 RDMA 為「Passthruogh Mode」時,雖然可以得到最大化的運作效能,但是將會限制 VM 虛擬主機的靈活性,例如,無法接受 DRS 自動化機制的調度(無法 vMotion 遷移至其它 ESXi 虛擬化平台)。

圖 18、RDMA – Kernel Bypass 運作機制示意圖

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


同時,當 VM 虛擬主機採用 vRDMA 機制時,在資料傳輸上將會有下列 3 種情境(如圖 19 所示),以便管理人員判斷 vRDMA 機制運作與否:
  • Memcpy:當 VM 虛擬主機之間在「同一台」ESXi 主機時,將採用 ESXi 虛擬化平台記憶體複製機制即時傳輸。
  • RDMA:當 VM 虛擬主機之間跨越「不同台」ESXi 主機時,且兩端 ESXi 主機皆安裝支援的 RDMA 介面卡時,將會透過 RDMA 進行快速傳輸。
  • TCP:當 VM 虛擬主機之間跨越「不同台」ESXi 主機,且其中一台 ESXi 主機「」安裝支援的 RDMA 介面卡時,將採用傳統的 TCP/IP 進行傳輸。

圖 19、vRDMA 機制運作與否情境示意圖

此外,在新版 vSphere 6.7 運作環境中,更將 RDMA 特色功能擴大服務使用範圍新增支援 iSER(iSCSI Extension for RDMA)機制。簡單來說,透過整合 RDMA 的 iSER 機制,可以讓企業及組織常用的 iSCSI 網路傳輸作業,從傳統的 TCP Transport通訊協定增強為 RDMA Transport(如圖 20 所示),進而降低 ESXi 虛擬化平台的 CPU 處理器工作負載,同時也全面支援原有的 iSCSI 管理功能,例如,Discovery、Naming、Security、Error-Recovery、Boot……等。

圖 20、iSER(iSCSI Extension for RDMA)運作架構示意圖



SW-FCoE 內建於 vSphere

在過去的 vSphere 版本中,ESXi 虛擬化平台「必須」配置硬體式 FCoE(Fiber Channel over Ethernet),才能夠啟用 SW-FCoE(Software FCoE)機制。

現在,在最新發佈的 vSphere 6.7 運作環境中,ESXi 虛擬化平台「無須」配置硬體式 FCoE 介面卡即可啟用 SW-FCoE機制(如圖 21 所示),除了可以省去配置昂貴的硬體式 FCoE CAN 介面卡之外,同時能夠與支援 DCB(Data Center Bridging)功能的 Layer 2網路卡協同運作,因此 SW-FCoE 能夠支援多種傳輸速率,例如,10 Gb、25 Gb、40 Gb、100Gb,並且還支援 Vn2Vn(Virtual node to virtual node)連線機制。

圖 21、新版 vSphere 6.7 運作環境中 SW-FCoE 運作架構示意圖





結語

透過本文的說明及展示後相信讀者已經了解,在最新發行的 vSphere 6.7 版本中舊有功能增強的部分,以及各式新增的特色功能機制,在後續的文章中將針對企業及組織關心的特色功能進行深入剖析及實作演練。

CentOS 7.5 透過 Helm 安裝 OpenStack Queens

$
0
0

前言

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

簡單來說,我們可以透過 OpenStack 中的 OpenStack-Helm,在 Kubernetes 容器調度環境中搭配  Helm 機制,部署 OpenStack Queens 運作元件達到快速佈建 OpenStack Queens運作環境的目的。





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

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

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

圖、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖

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

圖、Nested Virtualization in Azure

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

由於本文並非著重於 Microsoft Azure 議題,所以如何建立 CentOS 虛擬主機就不詳述。請透過下列的 Azure CLI 指令,先在東南亞的資料中心建立資源群組,然後再建立具備 Nested Virtualization 機制的 CentOS 7.5 虛擬主機。
# Create Resource Group in Azure SouthEast Asia DataCenter
$ az group create --name RG-OpenStackHelmLab --location southeastasia

# Create CentOS 7.5 Virtual Machine
$ az vm create \
--resource-group 
RG-OpenStackHelmLab \
--name vm-helmqueens \
--image OpenLogic:CentOS:7.5:latest \
--size Standard_D16s_v3 \
--admin-username weithenn \
--admin-password OpenInfraDaysTaiwan2018


# Open CentOS 7.5 NSG port 3389 traffic
$ az vm open-port --port 3389 --priority 1200 --resource-group RG-OpenStackHelmLab --name vm-helmqueens


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

圖、建立 CentOS 7.5 虛擬主機

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





CentOS 7.5 基礎設定

有關 CentOS 的基礎設定就不再贅述,有興趣的朋友可以參考站內文章 CentOS 7.4 攻略 - 基礎設定系列文章。順利建立 CentOS 虛擬主機可以透過 SSH 登入,也可以從 Azure Cloud Shell進行登入 (但是,必須注意 20 分鐘 Idle 自動登出的情況),請執行下列指令進行安裝桌面環境 (屆時,才方便透過瀏覽器連結 Kubernetes Dashboard):
$ sudo yum -y update
$ sudo yum -y install epel-release
$ sudo yum -y groupinstall "Xfce"


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


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


在連接至 CentOS 7.5 虛擬主機之前,除了 CentOS 主機本身的防火牆之外,因為本文實作環境採用 Microsoft Azure 公有雲環境,所以記得確認這台 CentOS 7.5 虛擬主機已經允許「TCP Port 3389」流量能夠通過 NSG 防火牆。本文實作 CentOS 7.5 虛擬主機的 FQDN 為「openstackhelmlab.southeastasia.cloudapp.azure.com」。

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

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

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





Kubernetes 環境基礎設定

由於,在稍後的自動化安裝流程中,將會有某些 Python 套件版本相依性導致自動化安裝流程中斷,所以我們可以先執行相關套件版本安裝及升級的動作。
$ sudo pip install -U six
$ sudo pip install PyYAML --ignore-installed PyYAML
$ sudo pip install requests --ignore-installed requests
$ sudo pip install ipaddress --ignore-installed ipaddress


圖、執行相關套件版本安裝及升級

請執行下列指令,以便執行「Clone the OpenStack-Helm Repos」的動作。
$ git clone https://git.openstack.org/openstack/openstack-helm-infra.git
$ git clone https://git.openstack.org/openstack/openstack-helm.git

圖、執行 Clone the OpenStack-Helm Repos 的動作

順利透過 git 指令下載 OpenStack-Helm Repos 之後,切換到 OpenStack-Helm Repos 資料夾,執行部署 Kubernetes 及 Helm的動作。
$ cd openstack-helm
$ ./tools/deployment/developer/common/010-deploy-k8s.sh

圖、執行部署 Kubernetes 及 Helm 的動作

圖、部署 Kubernetes 及 Helm 的動作完成

執行安裝 OpenStack-Helm的動作。
$ ./tools/deployment/developer/common/020-setup-client.sh
圖、執行安裝 OpenStack-Helm 的動作

執行部署 Ingress Controller的動作。
$ ./tools/deployment/developer/common/030-ingress.sh
圖、執行部署 Ingress Controller 的動作





佈署 OpenStack Queens 運作環境

請執行下列 Script 依序部署 NFS、MariaDB、RabbitMQ、Memcached、Keystone、Heat、Horizon、Glance、OpenvSwitch、Libvirt、Nova、Neutron、Gateway (for the public network)
$ ./tools/deployment/developer/nfs/040-nfs-provisioner.sh
$ ./tools/deployment/developer/nfs/050-mariadb.sh
$ ./tools/deployment/developer/nfs/060-rabbitmq.sh
$ ./tools/deployment/developer/nfs/070-memcached.sh
$ ./tools/deployment/developer/nfs/080-keystone.sh
$ ./tools/deployment/developer/nfs/090-heat.sh
$ ./tools/deployment/developer/nfs/100-horizon.sh
$ ./tools/deployment/developer/nfs/120-glance.sh
$ ./tools/deployment/developer/nfs/140-openvswitch.sh
$ ./tools/deployment/developer/nfs/150-libvirt.sh
$ ./tools/deployment/developer/nfs/160-compute-kit.sh
$ ./tools/deployment/developer/nfs/170-setup-gateway.sh

圖、部署 NFS

圖、部署 MariaDB

圖、部署 RabbitMQ

圖、部署 Memcached

圖、部署 Keystone

圖、部署 Heat

圖、部署 Horizon

圖、部署 Glance

圖、部署 OpenvSwitch

圖、部署 Libvirt

圖、部署 Nova 及 Neutron

圖、部署 Gateway (for the public network)





檢查 OpenStack Queens 環境

順利部署 OpenStack-Helm 之後,便可以執行下列指令開始使用 OpenStack Client 建立 OpenStack 範例運作環境:
$ ./tools/deployment/developer/common/900-use-it.sh
圖、建立 OpenStack 範例運作環境

執行「helm list」指令,查看透過 Helm 機制所部署的 OpenStack 運作元件。

圖、查看透過 Helm 機制所部署的 OpenStack 運作元件

執行「docker ps」指令,查看目前運作的容器清單。

圖、查看目前運作的容器清單

執行下列 Kubernetes 指令,查看 Kubernetes Namespace、Pods 等資訊。
$ kubectl get ns
$ kubectl get pods -n openstack --field-selector=status.phase=Running
$ kubectl get pods -o wide --all-namespaces --field-selector=status.phase=Running

圖、查看 Kubernetes Namespace、Pods 資訊

圖、查看 Kubernetes Namespace、Pods 資訊

執行下列指令,透過 python-openstackclient CLI啟用 auth 使用者身份驗證機制。
$ export OS_CLOUD=openstack_helm
$ export OS_USERNAME='admin'
$ export OS_PASSWORD='password'
$ export OS_PROJECT_NAME='admin'
$ export OS_PROJECT_DOMAIN_NAME='default'
$ export OS_USER_DOMAIN_NAME='default'
$ export OS_AUTH_URL='http://keystone.openstack.svc.cluster.local/v3'
$ openstack service list
$ openstack stack list

圖、透過 python-openstackclient CLI 啟用 auth 使用者身份驗證機制





使用 OpenStack Queens 環境

佈署作業完成後,請開啟瀏覽器連結至「http://localhost:31000」網址,即可看到 OpenStack Horizon Dashboard登入畫面。然後鍵入下列 Domain、User Name、Password 等欄位資訊
Domain: default
User Name: admin
Password: password

圖、連結至 OpenStack Horizon 登入畫面

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





安裝 Kubernetes Dashboard 運作環境

由於本文實作環境有結合 Kubernetes 容器調度平台,所以我們也安裝 Kubernetes Dashboard 運作環境來協助我們了解整體環境及相關資訊。
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
$ kubectl describe svc kubernetes-dashboard -n kube-system
$ kubectl get services kubernetes-dashboard -n kube-system
$ kubectl proxy

圖、安裝 Kubernetes Dashboard 運作環境

圖、登入 Kubernetes Dashboard

圖、透過 Kubernetes Dashboard 查看相關資訊





刪除 OpenStack Queens 測試環境

當測試作業完畢或環境玩爛需要打掉重練時,由於本文是在 Microsoft Azure公有雲環境上進行實作,其實可以透過簡單的 Azure CLI 快速刪除整個測試環境。
# Delete OpenStack-Helm Queens environment
$ az group delete --name RG-OpenStackHelmLab --yes --no-wait
$ : > /home/weithenn/.ssh/known_hosts

圖、刪除 Azure VM 測試環境





參考資源

[站長開講] Tech 2019 New Future

$
0
0

活動簡介

2019 新未來即將到來,在本場研討會上午場次不僅讓您知道還讓您用到,微軟已推出的最貼近現代工作情境、每天都可使用的 Office 裡的 AI 神器,聚焦「工作效能」與「團隊協作」兩大層面,一次搞定 AI、大數據開創工作新型態。

下午場次將展示 Windows Server 2019 新世代雲端作業系統,如何輕鬆整合 Microsoft Azure 公有雲並簡化 IT 營運管理。一網打盡向您介紹下列四大領域: Hybrid 混合雲架構、Security 新世代安全機制、Application Platform、HCI (Hyper-Converged Infrastructure) 超融合架構混合雲架構及案例情境再搭配 Smart Migration Tool,幫助您工作更得心應手!

面對全球化、數位化所帶來快速變局的您, 與其擔心 AI 取代您的工作,不如開始運用 AI 為您工作。2019 讓我們一起站在 AI 的肩膀上,邁向新未來。





活動資訊

  • 日期: 2018 年 10 月 3 日 (星期三)
  • 時間: 9:10 ~ 16:40
  • 地點: 台北維多麗亞酒店 (104 台北市敬業四路 168 號 3 樓)
  • 報名活動報名





活動內容

  • 站長議程: Windows Server 2019 Everywhere 混合雲架構 (Hybrid)、新世代安全機制 (Security)
  • 站長議程: Windows Server 2019 Application Platform、超融合架構 HCI (Hyper-Converged Infrastructure)

CentOS 7.5 透過 RDO 安裝 OpenStack Queens

$
0
0

前言

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

簡單來說,我們可以透過 RDO Project - OpenStack, packaged for and tested on CentOS 機制,在 CentOS 7.5 主機中搭配 Puppet工具,達到快速部署 OpenStack Queens 運作元件及運作環境的目的。

圖、RDO Packaging 運作架構示意圖

圖、Evaluating OpenStack Single-Node 運作架構示意圖





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

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

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

圖、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖

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

圖、Nested Virtualization in Azure

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

由於本文並非著重於 Microsoft Azure 議題,所以如何建立 CentOS 虛擬主機就不詳述。請透過下列的 Azure CLI 指令,先在東南亞的資料中心建立資源群組,然後再建立具備 Nested Virtualization 機制的 CentOS 7.5 虛擬主機。
# Create Resource Group in Azure SouthEast Asia DataCenter
$ az group create --name RG-RDOLab --location southeastasia

# Create CentOS 7.5 Virtual Machine
$ az vm create \
--resource-group 
RG-RDOLab \
--name rdo-queens \
--image OpenLogic:CentOS:7.5:latest \
--size Standard_D16s_v3 \
--admin-username weithenn \
--admin-password OpenInfraDaysTaiwan2018


# Open CentOS 7.5 NSG port 3389 traffic
$ az vm open-port --port 3389 --priority 1200 --resource-group RG-RDOLab --name rdo-queens


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

圖、建立 CentOS 7.5 虛擬主機





CentOS 7.5 基礎設定

有關 CentOS 的基礎設定就不再贅述,有興趣的朋友可以參考站內文章 CentOS 7.4 攻略 - 基礎設定系列文章。順利建立 CentOS 虛擬主機可以透過 SSH 登入,也可以從 Azure Cloud Shell進行登入 (但是,必須注意 20 分鐘 Idle 自動登出的情況),請執行下列指令進行安裝桌面環境 :
$ sudo yum -y update
$ sudo yum -y install epel-release
$ sudo yum -y groupinstall "Xfce"


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


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


在連接至 CentOS 7.5 虛擬主機之前,除了 CentOS 主機本身的防火牆之外,因為本文實作環境採用 Microsoft Azure 公有雲環境,所以記得確認這台 CentOS 7.5 虛擬主機已經允許「TCP Port 3389」流量能夠通過 NSG 防火牆。本文實作 CentOS 7.5 虛擬主機的 FQDN 為「openstackhelmlab.southeastasia.cloudapp.azure.com」。

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

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

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

由於,屆時建立的 OpenStack Networking 機制,與 CentOS 7.5 主機內建的 NetworkManager 網路功能互斥,所以必須先把 NetworkManager 功能停用,然後請確保 CentOS 主機的 network 網路功能啟動及運作中。 (詳細資訊,請參考 RedHat - Evaluating OpenStack: Single-Node Deployment文章內容)
$ sudo systemctl disable NetworkManager
$ sudo systemctl stop NetworkManager
$ sudo systemctl status NetworkManager
$ sudo systemctl status network


圖、確保停用 NetworkManager 網路功能服務

圖、確保 network 網路功能服務運作中





安裝 OpenStack Queens

接下來,便是透過 Packstack 安裝 OpenStack Queens 的動作,詳細資訊請參考 Packstack: Create a proof of concept cloud官方文件內容 (最後,packstack --allinone的動作,本文實作環境約 30 分鐘後部署完畢)。
$ sudo yum install -y centos-release-openstack-queens
$ sudo yum update -y
$ sudo yum install -y openstack-packstack
$ sudo packstack --allinone


圖、安裝 centos-release-openstack-queens

圖、執行 YUM Update

圖、安裝 openstack-packstack

圖、建立及啟動 OpenStack Queens 運作環境

圖、建立及啟動 OpenStack Queens 完成

順利運作 OpenStack Queens 運作環境後,便可以查看登入 OpenStack 頁面的相關資訊。
  • keystonerc_admin: 管理者帳號密碼資訊
  • keystonerc_demo: 展示用途帳號密碼資訊

圖、查看帳號密碼資訊

圖、執行環境參數設定

圖、登入 OpenStack

圖、順利登入 OpenStack






刪除 OpenStack Queens 測試環境

當測試作業完畢或環境玩爛需要打掉重練時,由於本文是在 Microsoft Azure公有雲環境上進行實作,其實可以透過簡單的 Azure CLI 快速刪除整個測試環境。
# Delete OpenStack-Helm Queens environment
$ az group delete --name RG-RDOLab --yes --no-wait







參考資源

網管人 153 期 - 新版 WAC 免費易用輕鬆管理主機和容錯移轉叢集

$
0
0

網管人雜誌

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






文章目錄

前言
WAC(Windows Admin Center)
          Windows Admin Center 運作架構
          支援安裝 WAC 管理工具的作業系統
          WAC 管理工具可納管的作業系統
實戰演練 – 建構 WAC 管理主機
          安裝 WAC 管理工具
          登入 WAC 管理介面
          WAC – 管理 Windows Server 主機
          WAC – 管理容錯移轉叢集
          WAC – 管理 HCI 超融合基礎架構
          WAC – 擴充功能
結語





前言

在目前使用 Windows Server 的企業及組織中,內部私有雲的管理工具通常會採用 System Center 監控解決方案,或是在 Microsoft Azure 公有雲環境中建構 OMS(Operations Management Suite)監控解決方案(如圖 1 所示),達成遠端管理及監控 Windows Server 主機的目的。
有關 OMS 監控解決方案的詳細資訊,請參考本刊《第 123 期 - 混合雲運行監控利器,用微軟 OMS 緊盯內外環境》。

圖 1、OMS 監控解決方案示意圖

然而,對於中小型運作規模及 IT 人員有限的中小型企業來說,無論採用地端的 System Center 或雲端的 OMS 監控解決方案,在 IT 預算方面和硬體資源的準備都顯得負擔太過沈重。因此,在 Microsoft Ignite 2015 年度技術大會上,Powershell 之父 Jeffrey Snover 在大會上正式宣佈,推出採用新興「HTML 5」技術開發的圖形化管理工具 SMT(Server Management Tools)
有關 SMT 管理工具的詳細資訊,請參考本刊《第 127 期 - 用圖形化 RSMT 遠端工具極精簡伺服器維運超順手》。

雖然,SMT 管理工具擁有方便且容易使用的特色,並能協助管理人員輕鬆管理 Windows Server Core 及 Nano Server 主機的優點,還能同時管理 Microsoft Azure 公有雲環境達到混合雲管理的目的。但是,多數管理人員對於 SMT 管理工具的主要抱怨,便是 SMT 管理工具只能」佈署在 Microsoft Azure 公有雲環境中,這表示 SMT 管理工具無法在無網際網路或封閉網路的環境中管理 Windows Server。

微軟在收集眾多 Windows Server 管理人員的意見反應後,正式在去年的 Ignite 2017 大會上推出「Project Honolulu」管理工具技術預覽版本(如圖 2 所示)。簡單來說,Project Honolulu 管理工具便是由先前的 SMT 管理工具演化而來,但是最大的差別在於能夠在「無網際網路」或「封閉網路」的環境中,達到管理 Windows Server 主機的目的。同時,當 Honolulu 主機能夠接觸網際網路的話也能夠與Microsoft Azure 公有雲環境協同運作,達成混合雲環境管理的目的。
有關 Project Honolulu 管理工具的詳細資訊,請參考本刊《第 145 期 - 建置 Honolulu 主機輕鬆管理 Windows Server》。
圖 2、Project Honolulu 操作介面示意圖





WAC(Windows Admin Center)

在 2018 年 4 月時,微軟正式推出 Honolulu 管理工具版本,並且將產品名稱重新命名為「WAC(Windows Admin Center)」,除了修正 Project Honolulu 管理工具在技術預覽階段時的許多臭蟲之外,同時也新增或增強許多亮眼功能,最重要的是企業及組織可以繼續「免費使用」WAC 管理工具。
有關微軟正式推出 Windows Admin Center 管理工具的詳細資訊,請參考官方部落格 Windows Server Blog – Announcing Windows Admin Center:Our reimagined management experience文章內容。



Windows Admin Center 運作架構

Windows Admin Center 現代化管理工具採用「HTML 5」設計架構,因此屆時管理人員只要採用支援 HTML 5 的瀏覽器,便能連接至 Windows Admin Center 操作介面進行管理作業。簡單來說,Windows Admin Center 具備下列容易建構及使用的功能特色:

  • 透過 Remote PowerShellWMI over WinRM(Port 5985)運作機制,可快速納管 Windows Server 主機,受管理的 Windows Server 無須安裝任何代理程式即可納管,達到現代化管理機制的「無代理程式」(Agentless)運作架構(如圖 3 所示)。
  • 管理人員只要採用支援 HTML 5 技術的現代化瀏覽器,即可輕鬆透過 Windows Admin Center 管理 Windows Server 伺服器。
  • 建構 Windows Admin Center 管理平台主機,無須安裝及組態設定 IIS 網頁伺服器或 SQL Server 資料庫伺服器,只要執行 MSI 安裝執行檔即可順利運作。

圖 3、Windows Admin Center 管理工具運作架構示意圖



支援安裝 WAC 管理工具的作業系統

IT 管理人員可以將 WAC 管理工具,安裝在 Windows 10、Windows Server 2016、Windows Server 2019 等作業系統版本。值得注意的是,倘若在 Windows 10 主機上安裝 WAC 管理工具,那麼 WAC 將會採用「桌面模式」(Desktop Mode)運作,也就是透過這台主機連線至 WAC Gateway 主機進行管理作業。
Windows 10必須採用 Fall Creators Update(1709)或更新版本,才支援安裝 WAC 管理工具。

因此,倘若希望 WAC 管理主機採用「閘道模式」(Gateway Mode)運作架構時(如圖 4 所示),請將 WAC 管理工具安裝在 Windows Server 2016 及 Windows Server 2019 作業系統版本。
事實上,先前技術預覽版本的 Project Honolulu 管理工具,支援安裝在 Windows Server 2012 / 2012 R2 作業系統中,但正式版本的 WAC 管理工具則支援。
圖 4、Windows Admin Center 佈署模式示意圖及說明



WAC 管理工具可納管的作業系統

當 WAC 管理工具安裝完成後,可納管 Windows 10、Windows Server 2008 R2 / 2012 / 2012 R2 / 2016 / 2019 等作業系統版本,以及 Hyper-V Server 2012 R2 / 2016 / 2019 虛擬化平台。

值得注意的是,WAC 管理工具是透過 PowerShell 及 WMI over WinRM 機制進行管理作業,但 Windows Server 2008 R2 / 2012 / 2012 R2 作業系統並未內建包括此機制,因此需要在納管這些作業系統版本的主機之前,先行安裝 WMF(Windows Management Framework)運作元件(至少為 WMF 5.1 或更新版本),屆時才能順利被 WAC 管理工具遠端管理。
在安裝 WMF 5.1運作元件之前,請先確保Windows Server 主機已安裝 .NET Framework 4.5.2或更新版本,否則可能會發生關鍵功能運作失敗的情形。

原則上,管理人員應該採用 1 台全新安裝的 Windows Server 來擔任 WAC 管理主機的角色,倘若企業及組織資料中心環境中,無法新增 1 台全新主機擔任 WAC 管理主機的話,也應該避免採用 Domain Controller、Exchange Server、Skype Server、Lync Server、System Center 伺服器擔任 WAC 管理主機,因為 WMF 5.1 運作元件在這些伺服器主機上有可能發生意外衝突的錯誤情況(如圖 5 所示)。

圖 5、WAC 管理工具無法安裝在 DC 網域控制站主機上





實戰演練 – 建構 WAC 管理主機

在本文實作環境中,我們將會安裝 1 台全新的 Windows Server 2016 Server Core 主機,以便充份利用 Server Core 精簡設計、運作效能良好、啟動系統服務較少、開啟連接埠較少、安全性更新較少的 Windows Server 2016 Server Core 版本,來擔任 WAC 管理主機的角色。

Windows Server 2016 Server Core 主機安裝完畢後,除了基本系統組態設定,例如,IP 位址、主機時區及系統時間、電腦名稱、加入網域……等工作項目之外,請在開啟的 PowerShell 指令視窗中,執行「powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c」PowerShell 指令(如圖 6 所示),將 Windows Server 2016 Server Core 主機電力選項調整為「High Performance」,以便 WAC 主機能夠發揮最大運作效能。

圖 6、調整 Windows Server 2016 Server Core 主機電力選項為 High Performance

然後,執行「Remove-WindowsFeature -Name FS-SMB1」指令,將 Windows Server 2016 Server Core 作業系統版本中,預設已安裝的 SMB v1 伺服器功能移除並請重新啟動主機以便套用生效(如圖 7 所示)。
在最新 Windows 10 Fall Creators Update(1709)版本,以及 Windows Server 2016(RS3 - version 1709)版本中,預設已經移除 SMB v1 伺服器功能。詳細資訊請參考 Microsoft KB 4034314知識庫文章。

圖 7、移除 Windows Server 2016 作業系統中預設已安裝的 SMB v1 伺服器功能



安裝 WAC 管理工具

目前,WAC 管理工具正式 GA 版本為「1804.25」,而本文撰寫時最新預覽的 WAC 管理工具版本則是「1807」,管理人員可以視需求採用不同的版本,舉例來說,WAC 管理工具則 1806 版本之後,才開始支援管理 Windows Server 2008 R2 主機。

本文實作環境,將安裝最新預覽的 WAC 管理工具 1807 版本,請在 WAC 管理主機上執行 MSI 安裝執行檔(WindowsAdminCenterPreview1807.msi),進入精靈視窗互動式安裝流程,或者直接開啟命令提示字元,執行「msiexec /i WindowsAdminCenterPreview1807.msi」指令,搭配「SME_Port」參數指定 WAC 管理工具連接,及搭配「SSL_CERTIFICATE_OPTION」參數指定採用的 SSL 憑證。

在 WAC 管理工具互動式安裝流程中,將會請管理人員指定屆時 WAC 管理工具網頁服務的「連接埠號」及「SSL 憑證」。在本文實作環境中,採用預設的「443」連接埠號及自我簽署的 SSL 憑證,企業及組織也可以考慮採用企業內部的 SSL 憑證。同時,請勾選「Redirect HTTP port 80 traffice to HTTPS」,那麼屆時管理人員採用支援 HTML 5 技術瀏覽器連接 WAC 管理主機時,只要連接至 HTTP Port 80 時便會自動重新導向至 HTTPS Port 443(如圖 8 所示)。

值得注意的是,倘若管理人員在 Windows 10主機安裝 WAC 管理工具的話,那麼預設情況下將會採用「6516」連接埠號提供 WAC 管理工具服務。
採用 WAC 管理工具自我簽署 SSL 憑證,預設情況下 SSL 憑證將於「60 天」後過期。

圖 8、安裝 WAC 管理工具並指定管理介面連接埠號

WAC 管理工具安裝完成後,請在 WAC 管理主機上開啟 PowerShell 指令視窗,執行「Get-Service ServerManagementGateway | Format-List」指令,可以看到在安裝 WAC 管理工具後將會在 Windows Server 2016 Server Core 主機上,新增 1 項名稱為「ServerManagementGateway」的系統服務(如圖 9 所示),並且目前該系統服務的運作狀態為「執行中」(Running)。

圖 9、WAC 管理工具安裝完成後自動新增至系統服務

此時,管理人員可以採用支援 HTML 5 技術的瀏覽器連接至 WAC 管理介面,順利連接 WAC 管理介面後系統將會彈出使用者身分驗證視窗,請鍵入具備 WAC 管理主機權限的使用者帳號及密碼即可順利登入。

值得注意的是,原則上 WAC 管理介面支援任何 HTML 5 技術的瀏覽器進行連接,但微軟目前主要測試的瀏覽器為「Microsoft Edge、Google Chrome」,其它支援 HTML 5 技術的瀏覽器則尚未進行完整測試。

當管理人員採用不支援 HTML 5 技術的瀏覽器連接 WAC 管理頁面,例如,IE(Internet Explorer)瀏覽器嘗試連接 WAC 管理頁面時,將會出現 WAC 管理頁面不支援此瀏覽器的錯誤訊息(如圖 10 所示)。

圖 10、使用不支援 HTML 5 技術的瀏覽器將無法連接 WAC 管理頁面



登入 WAC 管理介面

當管理人員採用 Microsoft Edge 或 Google Chrome 瀏覽器,連接 WAC 管理介面並順利通過使用者身份驗證程序登入後,首先 WAC 管理介面將會顯示簡易的導覽資訊,管理人員可以按下 Next 了解 WAC 管理工具導覽資訊或按下 Skip Tour 略過導覽程序,接著便進入 WAC 管理介面(如圖 11 所示)。

圖 11、通過使用者身份驗證程序登入 WAC 管理介面

順利登入 WAC 管理介面後,預設將會看到 WAC 管理主機的主機名稱、運作狀態、登入的管理者帳號……等資訊。此外,WAC 管理介面已經支援多國語系,但預設 WAC 管理介面語系將以連接的 HTML 5 瀏覽器語系組態設定值為主,管理人員可以點選 WAC 管理介面右上方「設定」圖示,進行組態設定頁面調整語系(如圖 12 所示)。

圖 12、調整 WAC 管理介面使用的語系

順利切換 WAC 管理工具語系後,可以直接點選 WAC 主機項目進入 WAC 主機的管理介面,在「概觀」頁面中可以一目了然的看到 WAC 主機各項資訊,包括,電腦名稱、作業系統版本、磁碟空間、記憶體空間……等,甚至是 CPU 處理器、記憶體、乙太網路等工作負載情況,也以圖表加上數值的方式呈現(如圖 13 所示)。

圖 13、查看 WAC 管理主機系統資訊



WAC – 管理 Windows Server 主機

在 WAC 管理工具主要頁面中,請按下所有連線區塊下的「+ 新增」圖示,系統便會在 WAC 管理頁面右側顯示新增連線視窗,管理人員可以看到共有 4 種連接選項分別是「伺服器、Windows 電腦、容錯移轉叢集、超融合叢集」。

當管理人員希望納管遠端的 Windows Server 主機時,請選擇「新增伺服器連線」選項,在Add Server鍵入希望納管的 Windows Server 主機名稱,在本文實作環境中鍵入的主機名稱為「dc.weithenn.org」(如圖 14 所示),當 WAC 管理主機順利解析到鍵入的主機名稱後,便會顯示「需要認證」資訊提示管理人員必須通過使用者身分驗證機制,才能透過 WAC 管理工具遠端管理該台主機,請在下方鍵入具備該台 Windows Server 主機管理權限的使用者帳號及密碼,然後按下「以認證提交」鈕以便納管遠端 Windows Server 主機。
當遠端 Windows Server 主機為「工作群組」或「非同網域主機」時,那麼 WAC 管理主機必須組態設定「TrustedHosts」機制,才能夠順利納管遠端 Windows Server 主機。

圖 14、透過 WAC 管理工具納管遠端 Windows Server 主機

當鍵入的使用者帳號及密碼通過遠端納管主機的身分驗證程序後,此時 WAC 管理主機便可以開始管理遠端 Windows Server 主機,因為管理的是「單台」Windows Server 主機,所以在 WAC 管理頁面中上方解決方案列將會停留在「伺服器管理員」項目(如圖 15 所示)。

圖 15、透過 WAC 管理工具納管遠端 Windows Server 主機



WAC – 管理容錯移轉叢集

WAC 管理工具,除了能夠遠端管理「單台」Windows Server 主機之外,也能夠管理「容錯移轉叢集」(Failover Cluster)運作環境,並且成功納管容錯移轉叢集後將會連同叢集成員主機一併納入管控。

請在 WAC 管理工具主要頁面中,依序點選「所有連線 > 新增 > 新增容錯移轉叢集連線」項目,然後在「叢集名稱」欄位鍵入希望納管的容錯移轉叢集名稱,在本文實作環境中名稱為「wsfc.weithenn.org」,當 WAC 管理主機順利解析到鍵入的容錯移轉叢集名稱後,由於先前已經通過使用者身分驗證程序,請勾選後續所有連線階段都採用相同具備管理權限的使用者帳號及密碼,所以能直接通過使用者身分驗證程序。

順利納管容錯移轉叢集後,預設情況下 WAC 管理工具將會同時納管容錯移轉叢集中,所有成員主機也一併加入至納管的主機清單中,此時 WAC 管理主機便可以開始管理容錯移轉叢集及所有成員主機,同時因為管理的是「容錯移轉叢集」,所以在 Honolulu 管理頁面中上方解決方案列將會停留在「容錯移轉叢集管理員」項目。

順利納管容錯移轉叢集後,管理人員應該已經發現左側工具項目數量相較於剛才管理「單台」Windows Server 主機較少,當管理人員點選「虛擬機器」項目後,便可以直接查看在容錯移轉叢集當中,整個硬體資源的工作負載情況,例如,CPU 處理器及記憶體等運算資源,以及使用這些運算資源前幾名的 VM 虛擬主機清單……等資訊(如圖 16 所示)。

圖 16、透過 WAC 管理工具查看容錯移轉叢集中硬體資源工作負載情況



WAC – 管理 HCI 超融合基礎架構

從 Windows Server 2016 版本開始,已經支援將 Hyper-V 虛擬化技術及 S2D(Storage Spaces Direct)軟體定義儲存技術整合,將「運算」及「儲存」資源同時合併,這也是目前新興的「超融合基礎架構」(Hyper-Converged Infrastructure,HCI)應用方式。在 WAC 管理工具中,除了能夠管理單台 Windows Server 主機及容錯移轉叢集之外,也支援管理 HCI 超融合基礎架構。

事實上,WAC 管理工具正式 GA 時,僅支援管理由 Windows Server 2019技術預覽版本,所建立的 S2D 超融合基礎架構運作環境,並「未支援」由 Windows Server 2016所建立的 S2D 超融合基礎架構運作環境。

然而,微軟在聽取眾多使用者的意見回覆後,決定讓 WAC 管理工具也能支援管理,由 Windows Server 2016 所建立的 S2D 超融合基礎架構運作環境,但管理人員應該會發現仍無法透過 WAC 管理工具,管理 S2D 超融合基礎架構運作環境(如圖 17 所示)。

圖 17、未安裝更新,所以 WAC 管理工具仍無法管理 S2D 超融合基礎架構運作環境

因為,S2D 超融合基礎架構運作環境中的 Windows Server 2016 主機,至少必須安裝「2018 年 5 月 Windows Server 2016 累積更新(KB4103723)」或後續累積更新,並且執行「Add-ClusterResourceType -Name "SDDC Management" -dll "$env:SystemRoot\Cluster\sddcres.dll" -DisplayName "SDDC Management"」PowerShell 指令,為 S2D 超融合基礎架構運作環境新增「SDDC Management」叢集資源(如圖 18 所示),如此一來 WAC 管理工具才能順利進行管理作業。

圖 18、S2D 超融合基礎架構運作環境新增 SDDC Management 叢集資源

請在 WAC 管理工具主要頁面中,依序點選「所有連線 > 新增 > 新增超融合叢集連線」項目,然後在「叢集名稱」欄位鍵入希望納管的 S2D 超融合基礎架構叢集名稱,在本文實作環境中名稱為「wsfc.weithenn.org」。同樣的 WAC 管理工具會將納管的 S2D 超融合基礎架構叢集中,所有叢集成員主機也一併加入至納管的主機清單中,順利納管後便可以輕鬆看到 S2D 超融合基礎架構叢集工作負載情況(如圖 19 所示)。

圖 19、透過 WAC 管理工具查看 S2D 超融合基礎架構運作環境



WAC – 擴充功能

WAC 管理工具,針對特色功能的部分採用「擴充功能」(Extensions)的方式,它是使用現代化 Web 技術,包括,HTML5、CSS、Angular、TypeScript 和jQuery 所建置。舉例來說,管理人員可以嘗試預計在 Windows Server 2019 中,提供的新增功能 Storage Migration Service 或 System Insights。

請在 WAC 管理介面中,依序點選「設定>延伸模組>可用的延伸模組」,即可看到 Storage Migration Service 及 System Insights 擴充功能,點選後按下「安裝」鈕即可(如圖 20 所示)。
安裝 WAC 管理工具擴充功能時,WAC 管理主機必須要能存取網際網路資源,否則將無法安裝擴充功能。

圖 20、安裝 Windows Server System Insights 擴充功能

雖然,順利為 WAC 管理工具安裝 System Insights 擴充功能,但是倘若納管的主機並非 Windows Server 2019 作業系統的話,那麼系統將會顯示「此作業系統無法使用系統見解」的資訊(如圖 21 所示)。

圖 21、Windows Server 2016 作業系統並未支援 System Insights 特色功能





結語

透過本文的說明及實作演練,相信讀者已經完全了解 WAC 管理工具的運作機制和佈署架構,以及如何建置 WAC 管理主機和運作環境,最後透過 WAC 管理主機輕鬆管理單台 Windows Server 主機,或容錯移轉叢集和 S2D 超融合基礎架構運作環境。

VMware vSphere 6.7 Journey (5) - TPM / vTPM / Windows VBS

$
0
0

前言

在目前混合及多雲的運作環境中,如何保護企業及組織的機敏資料更顯重要。因此,在新版 vSphere 6.7 中,ESXi 虛擬化平台正式支援 TPM 2.0(Trusted Platform Module),能夠儲存加密金鑰、憑證、雜湊……等資料,同時透過 vTPM 2.0機制更可以將保護範圍擴大到 VM 虛擬主機。


事實上,ESXi 虛擬化平台已經支援多年 TPM 1.2。值得注意的是,舊版 TPM 1.2 及新版 TPM 2.0 無法相容,因此舊有 TPM 1.2 的裝置驅動程式及 API 必須重新開發。





ESXi 虛擬化平台支援新式 TPM 2.0

在新版 vSphere 6.7 的運作架構中,當 ESXi 虛擬化平台採用的 x86 硬體伺服器,配置 TPM 2.0 安全性模組後,那麼 ESXi 虛擬化平台便能啟用「安全啟動」(Secure Boot)機制,透過底層硬體保護 ESXi 虛擬化平台的 UEFI Firmware、Boot Loader、VMKernel 等初始化及開機程序。

簡單來說,ESXi 虛擬化平台將安全性資訊儲存於 TPM 2.0安全性模組當中,而 vCenter Server 管理平台將會讀取相關資訊,例如,ESXi Event Log、VIB Metadata……等,並且與受管理的 ESXi 虛擬化平台進行匹配比較,確保 ESXi 虛擬化平台只會運作通過驗證的程式碼免於遭受攻擊。
事實上,在 vSphere 6.5 版本時便已經支援 Secure Boot,但當時僅能使用舊版 TPM 1.2 安全性模組進行實作,詳細資訊請參考 VMware vSphere Blog - Secure Boot for ESXi 6.5 – Hypervisor Assurance文章內容。
圖、Secure Boot 機制有效保護 ESXi 虛擬化平台初始化及開機程序

影片、TPM 2.0 Trusted Platform Module for vSphere 6.7

影片、vSphere 6.7 Support for ESXi and TPM 2.0





vTPM 2.0 擴大保護範圍至 VM 虛擬主機

當 ESXi 虛擬化平台配置 TPM 2.0 安全性模組後,便能啟用 vTPM 2.0機制並將加密金鑰、憑證、雜湊等機敏資料保護機制擴大到 VM 虛擬主機。

啟用 vTPM 2.0 機制的 VM 虛擬主機,在客體作業系統中將會如同實體主機一樣看到普通的 TPM 2.0 安全性模組,當管理人員需要進行加密金鑰、憑證、雜湊等機制保護機敏資料時,便會將相關資料寫入 VM 虛擬主機當中的 NVRAM 檔案內,同時採用 VM Encryption 機制保護該檔案,並且同時支援 Windows VBS(Virtualization-Based Security)安全性機制協同運作。

此外,啟用 vTPM 2.0 保護機制的 VM 虛擬主機,當遷移或匯出至其它資料中心或雲端環境時,倘若該資料中心或雲端環境未支援或使用 KMS(Key Management System),仍然可以透過原有的 vTPM 2.0 保護機制確保機敏資料無法被惡意人士所碰觸。

圖、TPM / vTPM 支援 Windows VBS 安全性機制示意圖

影片、vSphere 6.7 support for Virtual TPM 2.0

影片、vSphere 6.7 support for VBS and Credential Guard





參考資源






VMware vSphere 6.7 攻略 - 系列文章

VMware vSAN 6.7 攻略

$
0
0

前言

日前 (2018/10/12),VMware 官方正式發佈 vSAN 第七代 VMware vSAN 6.7 Update 1 Release Notes資訊。簡單來說,VMware vSAN 為「超融合」(Hyper-Converged Infrastructure,HCI) 的解決方案,也是 VMware SDDC 當中的 SDS 軟體定義儲存的基礎架構。


如果,您還不熟悉什麼是 HCI 超融合的話,可以參考下列影片:


有關過去每一代 vSAN 版本的新增特色功能資訊,請參考站長歷來撰寫的 vSAN 專欄文章:



接下來,站長將會不定期針對第七代的 vSAN 6.7 U1 深入剖析各項特色功能:

【簡介】(Introduction)






【安全性】(Security)

  • Coming Soon...





【管理】(Management)

  • Coming Soon...





【部署】(Deployment)

  • Coming Soon...





    【可用性】(Availability)

    • Coming Soon...





    【效能】(Performance)






    【軟體授權】(Software Licensing)

    • Coming Soon...





      【VMworld 2018 vSAN Session】

      • Coming Soon...





      【官網資源】

      VMware vSAN 6.7 Journey (01) - 新功能簡介

      $
      0
      0

      前言

      日前 (2018/10/12),VMware 官方正式發佈 vSAN 第七代 VMware vSAN 6.7 Update 1 Release Notes資訊。本文,將簡要說明第七代 vSAN 有哪些新功能,後續再針對每個項目深入剖析。



      圖、vSAN 解決方案示意圖





      簡化部署流程 - vSAN Cluster Quickstart

      在過去 vSAN 版本中,當企業及組織的IT管理人員在進行 vSAN 部署和叢集建立時,倘若對於 vSphere 虛擬化架構及 vSAN 部署流程沒有一定熟悉程度的話,那麼可能無法輕鬆部署或擴充 vSAN 軟體定義儲存運作架構。舉例來說,下列項目便是建構 vSAN Cluster 所需的部署項目及配置:
      • 建立 vSphere Cluster 並組態設定 vSphere HA、vSphere DRS、vSAN。
      • 組態設定 vSAN 部署類型,例如,All Flash 或 Hybrid。
      • 組態設定每台 vSAN 節點主機網路環境,例如,vDS 分散式虛擬交換機。
      • 組態設定 vSAN 磁碟群組,例如,每台 vSAN 節點主機採用多少顆快取裝置及儲存容量裝置。
      • 組態設定 vSAN 資料服務,例如,資料重複刪除和壓縮及加密等機制。

      現在,IT 管理人員可以透過最新提供「叢集快速入門」(Cluster Quickstart)的 Step-by-Step 流程,即可讓建立 vSAN 軟體定義儲存架構的繁雜流程進行簡化,幫助 IT 管理人員輕鬆建立及配置符合正式營運環境的 vSAN Cluster。

      圖、vSAN Cluster Quickstart 操作流程示意圖





      正式支援 TRIM / UNMAP 儲存空間回收機制

      自動化支援 UNMAP 機制,有助於 Guest OS 儲存空間回收。事實上,在過去的 vSAN 版本中並沒有在 Volume / Datastore 層級進行儲存空間回收,因為 vSAN 會追蹤所有 Objects,當 vSAN 刪除 Objects 時才會回收/重新使用該空間。

      現在,當 Guest OS 運作一段時間且 VMDK 儲存空間不斷增加,只要 Guest OS 刪除後便會立即啟動 UNMAP 機制,讓 vSAN 可以回收該儲存空間。因此,現在 vSAN 搭配 VDI 環境更能節省儲存空間,相關詳細資訊請參考官方文件 VMware StorageHub - UNMAP/TRIM Space Reclamation on vSAN

      圖、vSAN TRIM / UNMAP 儲存空間回收機制示意圖





      更深入整合 VUM

      VUM (vSphere Update Manager) 與 vSAN 環境整合度更加緊密。現在,可以透過 VUM 為每台 vSAN Host 進行升級 (進入維護模式 > 更新/升級 > 重新啟動 > 離開維護模式)。

      同時,在 vSAN 6.7 U1 中更將 Storage Controllers 的 Firmware Level Update 包含在 VUM workflows 當中。雖然,目前僅支援相容清單中部份的 Storage Controllers 但後續會慢慢增加。

      圖、vSphere Update Manager整合驅動程式及韌體更新機制運作架構示意圖





      vSAN Host 維護更安全

      vSAN 6.6版本中,針對 vSAN Host Decommissioning 及維護模式的工作流程進行改善,以便確保 capacity constraints or object unavailability depending 能夠不影響資料可用性。

      vSAN 6.7 U1 版本中,會先執行「模擬 vSAN Host 進入維護模式的結果」,例如,當 vSAN Host 進入維護模式,但導致 vSAN Cluster 會沒有足夠的儲存空間來 Re-Protect / Rebuild 所有 Objects 時,那麼進入維護模式結果為失敗並給出失敗原因。其它增強功能:
      • 確認 vSAN Cluster 中其它 vSAN Host 是否處於維護模式
      • 確認 vSAN Cluster 是否有 Rebuild / Resync 工作任務仍在執行中
      • 當 Rebuild 作業超時 (預設 CLOM repair delay 為 60 分鐘),現在可以透過 vSphere Client 進行調整 (Configure > vSAN > Services > Advanced Options),而非像舊版要針對單台 ESXi Host 進行調整。

      圖、vSAN Host 模擬進入維護模式示意圖





      主動式網路效能測試

      vSAN 6.7 U1 版本中,「主動式網路效能測試」(New Proactive Network Performance Test) 機制,主要是針對從 vSAN 6.6 開始的 Unicast Traffic (而非舊版的 Multicast Traffic) 而設計。

      簡單來說,此機制可以驗證 Network Infrastructure 是否能夠處理及承載 vSAN network traffic。當 vSAN Cluster 部署在 Layer 3 網路環境時,這個測試方式可以提供更多幫助及驗證。同時,包括 Network Diagnostics 功能,確認 vSAN Host 之間是否有足夠的網路頻寬 (至少需要 850 Mbps) 來運作 vSAN Cluster。

      圖、主動式網路效能測試示意圖





      儲存空間消耗趨勢

      從過往的歷史記錄,預測未來儲存空間的消耗趨勢,以便 vSAN 管理員更容易判斷是否需要進行 Scale-In/Out 作業。重點是,可以選擇 vSAN Policy 針對儲存空間來進行儲存空間的消耗趨勢,不管採用的是 RAID-1, RAID-5, RAID-6 都可以。

      圖、查看儲存空間消耗趨勢

      圖、查看儲存空間消耗趨勢

      圖、查看儲存空間消耗趨勢





      支援混合使用 Jumbo Frame 網路環境

      在 vSAN Cluster 運作架構中,我們已經知道為 vSAN 網路環境開啟 Jumbo Frame提升傳輸封包大小,將有助於提升 vSAN Cluster 的儲存效能表現。

      但是,在過去的 vSAN 版本中當採用 vSAN Stretched Clusters 運作架構時,因為 vSAN Cluster 與 vSAN Witness 之間溝通的網路流量並不適合開啟 Jumbo Frame,因為一旦開啟 Jumbo Frame 雖然可以獲得儲存效能提升,但有可能會遭遇到潛在的網路問題

      現在,最新的發佈的 vSAN 6.7 Update 1支援採用不同 MTU Size 的運作環境,所以在 vSAN Stretched Clusters之間可以開啟 Jumbo Frame(MTU = 9,000),以便提升 vSAN Cluster 的儲存效能表現,而 vSAN Cluster 與 vSAN Witness 之間溝通的網路流量,則採用標準的 MTU = 1,500的封包大小避免遭遇到潛在的網路問題,有效在提升效能與運作穩定性方面得到良好的平衡。

      圖、vSAN Cluster 支援混合 Jumbo Frame 網路環境





      VMware vSAN 影片

      文字說明太廢? 話不多說,直接看官方影片最快:







      參考資源






      VMware vSAN 6.7 攻略 - 系列文章

      針對 Windows Server 2016 S2D 的 KB4462928

      $
      0
      0

      VMware vSAN 6.7 Journey (02) - 支援 RDMA?

      $
      0
      0

      前言

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


      圖、RDMA 運作示意圖

      在新版 vSphere 6.7運作環境中,開始全面支援 RDMA (InfiniBand / iWARP / RoCE) 之外,更增強 vSphere Kernel / Hypervisr / RDMA之間的協同運作的部分,讓整體運作效能更加提升。有關 vSphere 6.7 支援 RDMA 的詳細資訊,請參考站內文章 VMware vSphere 6.7 Journey (3) - RDMA

      圖、vSphere 6.7 全面支援 RDMA (InfiniBand / iWARP / RoCE)





      vSAN 6.7 是否支援 RDMA?

      雖然,在新版 vSphere 6.7 運作環境中已經全面支援 RDMA。但是,在 VMware vSAN 6.7 Release NotesVMware vSAN 6.7 Update 1 Release Notes當中,並沒有看任何支援 RDMA 技術的相關說明?

      這個問題的答案,終於在今年的  VMworld US 2018 - HCI2476BU - Tech Preview: RDMA and Next-Gen Storage Technologies for vSAN 議程中獲得解答。簡單來說,即便是目前最新的 vSAN 6.7 U1尚未支援 RDMA,但是 VMware 已經預計在下一版 vSAN 中便開始整合 RDMA。

      圖、vSAN 預計下一版開始支援 RDMA

      由於 RDMA 具有Kernel Bypass、Zero Copy、CPU Offloading的特性,因此整合至 vSAN 當中將可以提到提升 vSAN Traffic 的「Throughput、IOPS」並降低「Network Latency」的好處。下列便是 VMworld US 2018 - HCI2476BU - Tech Preview: RDMA and Next-Gen Storage Technologies for vSAN 議程中的測試環境及測試結果,可以看到整合 RDMA 後的 vSAN Traffic 比現有傳統的 TCP/IP 在各方面都有更好的效能表現。

      圖、vSAN over RDMA 測試環境

      圖、RDMA vs TCP/IP over vSAN - Throughput

      圖、RDMA vs TCP/IP over vSAN - IOPS

      圖、RDMA vs TCP/IP over vSAN - Network Latency

      此外,隨著新世代儲存 PMem (Persistent Memory)的推出 vSAN 當然也支援,並且 VMware 也預估未來的儲存趨勢,將會改由 PMem (Persistent Memory)來擔任「快取層」(Caching Tier) 的任務,而目前主流的 NVMe則改為擔任「資料儲存層」(Persistence Tier) 的任務。

      圖、 Next-Gen Storage Devices Vision for vSAN

      最後,如果你對 vSAN 創新技術有興趣想加入技術預覽版測試行列的話,只要加入 vSAN Private Beta 計畫即可。

      圖、vSAN Private Beta





      VMware vSAN 6.7 攻略 - 系列文章

      網管人 154 期 - 了解 Update 1 增強版動手打造 vSAN 6.7 叢集

      $
      0
      0

      網管人雜誌

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






      文章目錄

      前言
      vSAN 與 Storage Appliance 的差別
      vSAN 6.7 Update 1 新增特色功能
                簡化 vSAN 部署流程
                透過 Update Manager 更新驅動程式及韌體
                增強儲存空間使用率報表
                正式支援 TRIM/UNMAP
                支援混合型 Jumbo Frame 網路環境
                增強健康狀態檢查機制
      實戰 vSAN Cluster 6.7 叢集架構
                2 Node 的 vSAN 運作架構
                建立資料中心及叢集
                建立 vDS 分散式交換器
                叢集啟用 vSAN 軟體定義儲存機制
                啟用重複資料刪除及壓縮機制
                高可用性測試
      結語





      前言

      在 VMware 所擘劃的 SDDC 軟體定義資料中心願景中,負責 SDS 軟體定義儲存解決方案的角色便是VMware vSAN(Virtual SAN)。新一代的 vSAN 軟體定義儲存解決方案,在 2018 年 4 月時正式發佈 VMware vSAN 6.7,並在 2018 年 8 月 VMworld 2018 舉辦時推出 VMware vSAN 6.7 Update 1增強版本,同時也發佈新的 vSAN Private Beta計畫,這個計畫將讓 vSAN 更專注於資料保護、檔案服務及雲原生儲存資源等層面。

      那麼 VMware vSAN 軟體定義儲存運作架構,對於企業及組織來說有什麼幫助? 簡單來說,在過去傳統運作架構中「運算及儲存」資源是互相分離的,負責運算資源的通常是 x86 硬體伺服器,而負責儲存資源的則是硬體式專用儲存設備,並且在 x86 硬體伺服器及儲存設備之間還必須採用 SAN 儲存網路以確保高效率運作。

      現在,企業及組織只要透過 VMware vSAN 軟體定義儲存技術,便可以將多台安裝 ESXi 虛擬化平台 x86 硬體伺服器中,所有「本機硬碟」(LocalHardDisk)儲存空間匯整(例如,NVMe 快閃儲存、SSD 固態硬碟、HDD 機械式硬碟……等),建構出高可用性高效能的共享儲存資源集區(如圖 1 所示)。因此,企業及組織在建構 VMware vSAN 軟體定義儲存環境後,便能同時解決建置「運算和儲存」2大資源的難題,這也是目前非常熱門的「超融合式架構」(Hyper-Converged Infrastructure,HCI)應用情境。
      在每台擔任 vSAN 角色的 x86 硬體伺服器中,可以配置「1 ~ 5 個」快取儲存裝置(例如,NVMe 快閃儲存或 SSD 固態硬碟),以及「1 ~ 7 個」容量儲存裝置(例如,HDD 機械式硬碟)。
      圖 1、VMware vSAN Disk Group 運作示意圖

      當企業及組織需要得到最大化儲存效能時,可以採用「All Flash」的 vSAN 運作架構(如圖所示),例如,NVMe 快閃儲存搭配 SSD 固態硬碟,在 All Flash 的運作架構中「快取層級」(Cache Tier)只會負責資料「寫入」的部份。

      倘若,企業及組織需要得到的是兼顧儲存效能及空間時,則可以採用「Hybrid」的 vSAN 運作架構,例如,SSD 固態硬碟搭配 HDD 機械式硬碟,在 Hybrid 的運作架構中「快取層級」(Cache Tier)則會同時負責資料「寫入及讀取」的部份(如圖 2 所示),並且在預設情況下將會以快取層級的儲存裝置中,以「70 %」的快取空間存放資料「讀取」的部分,而「30 %」的快取空間則存放資料「寫入」的部分。

      圖 2、VMware vSAN 快取層級及容量層級運作示意圖





      vSAN 與 Storage Appliance 的差別

      那麼 VMware vSAN 與其它 Storage Appliance 解決方案的差別為何? 一般來說,在 Storage Appliance的運作架構中,必須在「每台」ESXi 虛擬化平台中採用「專用」的 CPU 和記憶體等運算資源,以避免虛擬化平台工作負載繁忙時發生資源爭奪的情況,導致提供的儲存資源效能不佳。

      同時,Storage Appliance 在整個儲存堆疊架構中,將會有額外的存取動作導致延遲時間拉長進而影響到運作效能。舉例來說,在 Storage Appliance 儲存堆疊架構中,當 VM 虛擬主機需要使用儲存資源時,整個 Storage Appliance 儲存堆疊架構的操作步驟便需要六個動作才能完成(如圖 3 所示)。

      圖 3、Storage Appliance 儲存堆疊架構路徑存取運作示意圖

      VMware vSAN則是原生內建在 vSphere Hypervisor 層級中,所以無須在每台 ESXi 虛擬化平台中安裝或部署 Appliance,並且 vSAN 使用的運算資源通常在每台 ESXi 虛擬化平台中佔用不到「10 %」,最後當 VM 虛擬主機需要使用 vSAN 儲存資源時,在 vSAN 儲存堆疊架構中只需要三個動作的操作步驟即可完成,提供最短存取路徑及延遲時間進而提升整體儲存效能表現(如圖 4 所示)。

      圖 4、VMware vSAN 儲存堆疊架構路徑存取運作示意圖





      vSAN 6.7 Update 1 新增特色功能

      了解 VMware vSAN 基礎和傳統 Storage Appliance 的差異後,我們來看看在 VMworld 2018 大會中,最新發佈的第 7 代 VMware vSAN 6.7 Update 1增強版本有哪些亮眼特色功能。



      簡化 vSAN 部署流程

      在過去 vSAN 版本中,當企業及組織的 IT 管理人員在進行 vSAN 部署和叢集建立時,倘若對於 vSphere 虛擬化架構及 vSAN 部署流程沒有一定熟悉程度的話,那麼可能無法輕鬆部署或擴充 vSAN 軟體定義儲存運作架構。舉例來說,下列項目便是建構 vSAN Cluster 所需的部署項目及配置:
      • 建立 vSphere Cluster 並組態設定 vSphere HA、vSphere DRS、vSAN。
      • 組態設定 vSAN 部署類型,例如,All Flash 或 Hybrid。
      • 組態設定每台 vSAN 節點主機網路環境,例如,vDS 分散式虛擬交換機。
      • 組態設定 vSAN 磁碟群組,例如,每台 vSAN 節點主機採用多少顆快取裝置及儲存容量裝置。
      • 組態設定 vSAN 資料服務,例如,資料重複刪除和壓縮及加密等機制。

      現在,IT 管理人員可以透過最新提供「叢集快速入門」(Cluster Quickstart)的 Step-by-Step 流程(如圖 5 所示),即可讓建立 vSAN 軟體定義儲存架構的繁雜流程進行簡化,幫助 IT 管理人員輕鬆建立及配置符合正式營運環境的 vSAN Cluster。

      圖 5、vSAN Cluster Quickstart 操作流程示意圖



      透過 Update Manager 更新驅動程式及韌體

      在過去的 vSAN 版本中,處理 ESXi 虛擬化平台「驅動程式」(Driver)「韌體」(Firmware)更新的工作任務,一直是由「Configuration Assist」機制進行處理。現在,最新的 vSAN 6.7 Update 1 版本中,已經將驅動程式及韌體更新作業程式整合至 vUM(vSphere Update Manager)當中(如圖 6 所示)。

      此外,透過 vUM 更新機制還能整合 OEM 供應商的 ISO 映像檔,以便幫 ESXi 虛擬化平台進行驅動程式及韌體更新作業。因此,即便在無法連接至網際網路的 vSAN 運作環境中,仍能輕鬆透過 vUM 更新機制,幫 vSAN 節點主機進行驅動程式及韌體更新作業。

      圖 6、vSphere Update Manager 整合驅動程式及韌體更新機制運作架構示意圖



      增強儲存空間使用率報表

      相信 IT 管理人員對於 vSAN 提供的高可用性及高儲存效能感到滿意,但是要如何對 vSAN 提供的儲存空間以及使用情況進行預估,以便因應未來適時提出增加 vSAN 節點主機的需求。

      現在,除了可以在 HTML 5 管理介面中,直接看到 vSAN 儲存容量資訊及儲存原則的套用情形之外,還可以透過增強儲存空間使用率報表機制,來查看 vSAN 儲存空間使用情況的歷史資訊,包含,資料重複刪除以及隨著時間及使用空間不斷變化的資料壓縮率(如圖 7 所示)。

      圖 7、透過 HTML 5 管理介面查看 vSAN 儲存空間使用情況的歷史資訊



      正式支援 TRIM/UNMAP

      在過去的 vSAN 版本中,雖然也可以達到「TRIM/UNMAP」的目的,也就是當 Guest OS 釋放出儲存空間時,能夠透過 TRIM/UNMAP 空間回收機制將 Guest OS 釋放的儲存空間,能夠回歸到 vSAN Datastore 儲存資源中,但有些部分必須要 IT 管理人員介入處理才行。

      現在,最新 vSAN 6.7 Update 1 當中 TRIM/UNMAP 儲存空間回收機制,已經能夠「自動化」運作 IT 管理人員無須再人為介入處理即可回收儲存空間,並且能夠支援各種 Guest OS 客體作業系統及虛擬硬體類型(如圖 8 所示)。

      圖 8、TRIM/UNMAP 儲存空間回收自動化機制運作示意圖



      支援混合型 Jumbo Frame 網路環境

      在 vSAN Cluster 運作架構中,我們已經知道為 vSAN 網路環境開啟 Jumbo Frame 提升傳輸封包大小,將有助於提升 vSAN Cluster 的儲存效能表現。

      但是,在過去的 vSAN 版本中當採用 vSAN Stretched Clusters 運作架構時,因為 vSAN Cluster 與 vSAN Witness 之間溝通的網路流量並不適合開啟 Jumbo Frame,因為一旦開啟 Jumbo Frame 雖然可以獲得儲存效能提升,但有可能會遭遇到潛在的網路問題。

      現在,最新的發佈的 vSAN 6.7 Update 1 支援採用不同 MTU Size 的運作環境,所以在 vSAN Stretched Clusters之間可以開啟 Jumbo Frame(MTU = 9,000),以便提升 vSAN Cluster 的儲存效能表現(如圖 9 所示),而 vSAN Cluster 與 vSAN Witness 之間溝通的網路流量,則採用標準的 MTU = 1,500的封包大小避免遭遇到潛在的網路問題,有效在提升效能與運作穩定性方面得到良好的平衡。

      圖 9、vSAN Stretched Clusters 支援不同 MTU Size 運作架構示意圖



      增強健康狀態檢查機制

      建構 vSAN 軟體定義儲存運作架構,除了必須確認 vSAN 節點主機硬體配件及軟體組態設定正確之外,IT 管理人員也必須時刻關心 vSAN Cluster 的健康情況,以確保 vSAN Cluster 擁有最佳運作效能及最高可用率,然而該如何檢查 vSAN Cluster 的健康情況則視 IT 管理人員的熟悉度而定。

      現在,透過新版 vSAN 的增強健康狀態檢查機制,便可以自動依照 vSAN 最佳建議作業進行 vSAN Cluster 運作環境的檢測,同時給予健康狀態檢查的最終結果讓 IT 管理人員知道應該如何進行改善作業(如圖 10 所示)。

      圖 10、vSAN 增強健康狀態檢查機制運作示意圖



      實戰 vSAN Cluster 6.7 叢集架構

      由於本文實作撰寫時,VMware 官方網站下載中心內仍未釋出最新 vSAN 6.7 Update 1 映像檔,所以本文實作將採用 vSAN 6.7 版本進行實作。在建構 vSAN 軟體定義儲存叢集架構時,最值得注意的部分便是在於 vSAN 節點主機的硬體組態配置,舉例來說,倘若管理人員希望在測試環境嘗試建構 vSAN 叢集架構時,那麼 ESXi 主機的記憶體資源至少需要「8 GB」才行。

      實務上,企業及組織在建構正式營運環境 vSAN 叢集架構時,倘若採用「vSAN Ready Node」的話則無須擔心硬體組態配置,若是自行配置時則必須要注意由 vSAN 軟體定義儲存所管理的儲存裝置,必須要採用「HBA 控制器(Passthrough 或 RAID 0 Mode)」才行(如圖 11 所示),這個部分是初次建置 vSAN 叢集架構時,IT 管理人員最容易忽略的部分。

      圖 11、自行配置 vSAN 節點主機硬體組態參考架構



      2 Node 的 vSAN 運作架構

      對於中小型規模的企業及組織來說,可能一開始的 vSAN Cluster 運作規模無須太大。因此,VMware 官方從第 5 代 vSAN 6.5 版本開始,便正式支援在 vSAN 叢集運作架構中最小運作「2 台」vSAN 節點主機即可,並且這 2 台 vSAN 節點主機可直接透過「交叉式纜線」(Crossover Cables)的方式進行連接(如圖 12 所示),無須透過 10 Gbps 網路交換器即可進行 vSAN 節點主機的資料交換作業,有效降中小型規模的企業及組織 vSAN 運作規模的整體 IT 預算。
      根據 VMware 官方的分析調查結果顯示,透過交叉式纜線的方式可以有效降低約 20 %的投資成本。
      在組態設定部分,根據 VMware 官方最佳作法除了將儲存及遷移流量分開,也就是應該要將「vSAN 儲存流量」「vMotion 遷移流量」分開在不同的 10 Gbps 纜線進行傳輸,以避免儲存或遷移流量互相干擾的情況發生。此外,也應該要組態設定為互相備援機制以便故障情況發生時,能夠有另 1 個 10 Gbps 纜線進行網路流量的容錯移轉。
      VMware 官方建議,當 vSAN 運作架構採用「Hybrid」儲存組態時,在儲存網路流量的部分應規劃 10 Gbps網路頻寬,當 vSAN 運作架構採用「All-Flash」儲存組態時,在儲存網路流量的部分應規劃 25 Gbps 或 40 Gbps網路頻寬。
      圖 12、2 台 vSAN 節點主機透過交叉式纜線連接網路流量規劃組態配置示意圖

      值得注意的是,當企業及組織採用 2 台 vSAN 節點主機的叢集架構時,則必須要有「vSAN Witness」的仲裁機制才行,並且負責 vSAN 叢集運作架構的見證虛擬設備(vSAN Witness Appliance),「不」可運作在 2 台 vSAN 節點主機之上以避免誤判的情況發生,並且在 VMware 的最佳建議作法當中,建議 vSAN Witness 的網路流量也應該規劃獨立網路環境以避免互相干擾的情況發生(如圖 13 所示)。

      圖 13、2 台 vSAN 節點主機叢集架構 vSAN Witness 網路流量規劃運作架構示意圖



      建立資料中心及叢集

      事實上,從 vSphere 6.7 版本開始針對管理工具的部分,已經全面改為採用 HTML 5 技術的 vSphere HTML Client(HTML5-Based),過去的 vSphere Web Client(Flash-Based)管理工具將全面棄用,本文實作環境也將全部以 HTML 5 管理介面進行說明及實作。
      在 2017 年 8 月時,VMware 便在官方部落格中正式宣佈下一版 vSphere 6.7 當中,便會以 vSphere HTML Client 為主要管理工具,並且不再有舊式的 vSphere Web Client 管理工具,詳細資訊請參考 VMware vSphere Blog - Goodbye,vSphere Web Client!
      在本文實作環境中共有「3 台」vSAN 節點主機,當管理人員安裝好 vCSA 6.7 及 vSAN 節點主機後,請建立「資料中心」(Datacenter)「叢集」(Cluster),然後將 3 台 vSAN 節點主機加入至 vSAN 叢集中。

      順利將 3 台 vSAN 節點主機加入叢集後,在本文實作環境中每台 vSAN 節點主機,除了安裝 ESXi Hypervisor 的儲存裝置之外,還額外配置「200 GB *2」的 SSD 固態硬碟(如圖 14 所示)。

      圖 14、每台 vSAN 節點主機皆額外配置 2 個 200 GB 容量的 SSD 固態硬碟



      建立 vDS 分散式交換器

      在 VMware 官方的 vSAN 網路環境建議作法中,針對 vSAN 網路環境建議採用「vDS 分散式網路交換器」(vNetwork Distributed Switch)為佳。

      現在,請為 vSAN 節點主機組態設定 vDS 分散式網路交換器,請在 vSphere HTML Client 管理介面中,依序點選【Menu > Networking > Datacenter > Actions > Distributed Switch > New Distributed Switch】。

      在彈出的 New Distributed Switch 精靈視窗中,請指定建立的 vDS 分散式網路交換器名稱及位置,在本文實作環境中 vDS 分散式網路交換器命名為「vSAN-DSwitch」,接著選擇 vDS 分散式網路交換器版本,因為本文實作環境中並沒有新舊版本混合的 vSAN 節點主機所以採用最新「6.6.0」版本,最後在設定組態頁面中,除了連接埠群組名稱改為「vSAN-DPortGroup」之外其餘採用系統預設值即可(如圖 15 所示)。

      圖 15、建立 vDS 分散式網路交換器及連接埠群組

      順利新增 vDS 分散式網路交換器及連接埠群組之後,請將 vSAN 節點主機中用於 vSAN 儲存流量的網路卡,加入至剛才所建立的 vDS 分散式網路交換器及連接埠群組當中。請在 vSphere HTML Client 管理介面中,依序點選【Menu > Networking > Datacenter > vSAN-DSwitch > Actions > Add and Manage Hosts】。

      在彈出的 Add and Manage Hosts 精靈視窗中,於步驟 1 選取工作頁面中請選擇「Add hosts」項目,在步驟 2 選取主機頁面中按下「New hosts」鈕後將 3 台 vSAN 節點主機全數加入,在步驟 3 管理實體介面卡頁面中請將 vSAN 節點主機中,配置用於 vSAN 儲存流量傳輸用途的網路卡加入,請點選「vmnic1」網路卡後點選「Assign uplink」鈕,將選定為 vSAN 儲存流量傳輸用途網路卡,指派為 vSAN-DSwitch 的 Uplink(如圖 16 所示)。

      圖 16、將選定為 vSAN 儲存流量傳輸用途網路卡指派為 vSAN-DSwitch 的 Uplink

      在步驟 4 管理 VMkernel 網路介面卡頁面中,請先點選「vmk1」然後按下「Assign port group」鈕,選擇採用「vSAN-DPortGroup」連接埠群組,並且勾選「Apply this port group assignment to all other hosts」項目,以便一次組態設定好 3 台 vSAN 節點主機(如圖 17 所示)。

      圖 17、指派 vSAN 儲存流量用途網路卡採用 vSAN-DPortGroup 連接埠群組

      完成指派 vSAN 儲存流量的工作任務後,再次確認 vSAN-DSwitch 及 vSAN-DPortGroup 是否指派完成且正確無誤(如圖 18 所示),以避免稍後為啟用 vSAN 特色功能時發生不可預期的錯誤。

      圖 18、再次確認 vSAN-DSwitch 及 vSAN-DPortGroup 是否指派完成且正確無誤



      叢集啟用 vSAN 軟體定義儲存機制

      現在,請透過 vSphere HTML Client管理工具,為 vSphere 叢集啟用 vSAN 軟體定義儲存機制,請依序點選【Menu > Hosts and Clusters > vSAN-Cluster > Configure > vSAN > Services > Configure】,在彈出的組態設定 vSAN 精靈視窗中,由於我們是「第一個」vSAN 叢集站台,所以請點選「Single site cluster」項目。

      在步驟 2 服務頁面中,將詢問是否啟用「重複資料刪除及壓縮」及「加密」功能,在步驟 3 宣告儲存裝置頁面中(如圖 19 所示),請為每台 vSAN 節點主機,指派 1 顆 SSD 固態硬碟為「快取層」(Cache Tier),另 1 顆 SSD 固態硬碟則指派為「容量層」(Capacity Tier),步驟 4 則是容錯網域的組態設定。
      有關 Hybrid 及 All Flash 的 vSAN 磁碟群組的組態設定詳細資訊,請參考 VMware Docs – Claim Storage Devices for a vSAN Cluster文件內容。
      圖 19、vSAN 叢集 All Flash 磁碟群組宣告指派快取層和容量層

      順利為 vSphere 叢集啟用 vSAN 軟體定義儲存機制後,請在管理介面中依序點選【vSAN-Cluster > Monitor > vSAN > Health】,查看目前 vSAN Cluster 的各項健康狀態及效能狀態等資訊(如圖 20 所示)。

      圖 20、查看目前 vSAN Cluster 的各項健康狀態及效能狀態等資訊



      啟用重複資料刪除及壓縮機制

      在 vSAN 叢集運作架構中採用 All Flash 類型時,便能啟用「重複資料刪除及壓縮」機制,一旦啟用後 vSAN 叢集中的壓縮演算法,將會把資料區塊壓縮到 2 KB甚至更少後才寫入至容量層,倘若某些類型的資料區塊無法壓縮時,則會以完整 4 KB的資料區塊寫入至容量層。

      請在 HTML 5 管理介面中,依序點選【vSAN-Cluster > Configure > vSAN > Services > Deduplication and compression > Edit】項目,然後啟用「Deduplication and Compression Services」項目後按下「Apply」鈕即可套用生效。

      完成組態設定後,請依序點選【vSAN-Cluster > Monitor > vSAN > Capacity】項目,即可看到啟用重複資料刪除及壓縮機制的相關資訊,例如,儲存空間節省多少和儲存空間節省比例等資訊(如圖 21 所示)。

      圖 21、查看重複資料刪除及壓縮機制相關資訊



      高可用性測試

      預設情況下,當 vSAN 叢集具備至少「3 台」vSAN 節點主機時,那麼即便沒有佈署 vSAN Witness 仲裁機制,也能容許「1 台」vSAN 節點主機發生故障損壞時仍能正常運作,簡單來說這樣的運作架構已經具備高可用性。
      倘若,在 vSAN 叢集架構中只有「2 台」vSAN 節點主機時,那麼「必須」要佈署 vSAN Witness仲裁機制才能確保高可用性。值得注意的是,運作 vSAN Witness 的 ESXi 主機「不能」加入至 vSAN 叢集中,並且該台 ESXi 主機「必須」要能接觸到 vSAN 儲存網路才行。

      IT 管理人員可以在 vSphere HTML Client 管理工具中,依序點選【vSAN-Cluster > Configure > vSAN > Fault Domains】選項,可以看到目前 vSAN 叢集容許「1 台」vSAN 節點主機故障(如圖 22 所示),表示 vSAN 叢集已經具備高可用性。

      圖 22、目前 vSAN 叢集可容許 1 台 vSAN 節點主機故障

      同時,請為 vSAN 叢集「啟用 vSphere HA」高可用性機制,以便某 1 台 vSAN 節點主機發生故障損壞事件時,其上運作的 VM 虛擬主機能夠自動在其它存活的 vSAN 節點主機上重新啟動。現在,運作在 vSAN 叢集當中的 VM 虛擬主機,預設情況下儲存物件和元件將會分別存放在不同台 vSAN 節點主機中(如圖 23 所示)。

      圖 23、VM 虛擬主機儲存物件將會分別存放在不同台 vSAN 節點主機中

      即便某 1 台 vSAN 節點主機,因為安全性更新需要重新啟動或發生故障損壞事件(如圖 24 所示),在 vSAN 叢集當中的 VM 虛擬主機仍然能夠正常運作提供服務達到高可用性的目的。

      圖 24、某 1 台 vSAN 節點主機重新啟動或故障損壞時 VM 虛擬主機仍能正常運作





      結語

      透過本文的說明及實作相信讀者已經了解,在最新第 7 代的 vSAN 6.7 Update 1 版本中有哪些新增特色功能,同時在本文也進行 vSAN Cluster 6.7 運作架構的實戰演練,期望能夠幫助企業及組織快速建構,具備高靈活和高擴充性及高可用性的 vSAN 軟體定義儲存運作環境。

      VMware vSAN 6.7 Journey (03) - vSAN 與 Storage Appliance 的差別

      $
      0
      0

      前言

      首先,當企業及組織採用 VMware vSAN 軟體定義儲存運作架構時,對於企業及組織來說到底有什麼幫助? 簡單來說,在過去傳統運作架構中「運算及儲存」資源是互相分離的,負責運算資源的通常是 x86 硬體伺服器,而負責儲存資源的則是硬體式專用儲存設備,並且在 x86 硬體伺服器及儲存設備之間還必須採用 SAN 儲存網路以確保高效率運作,同時 IT 管理人員還必須處理 LUN MaskingZoning等繁雜的流程後才能順利使用儲存資源。





      vSAN 與 Storage Appliance 的差別

      此外,VMware vSAN 與其它 Storage Appliance解決方案有何差別? 一般來說,在 Storage Appliance 的運作架構中,必須在「每台」ESXi 虛擬化平台中採用「專用」的 CPU 和記憶體等運算資源,以避免虛擬化平台工作負載繁忙時發生資源爭奪的情況,導致提供的儲存資源效能不佳。

      同時,Storage Appliance在整個儲存堆疊架構中,將會有額外的存取動作導致延遲時間拉長進而影響到運作效能。舉例來說,在 Storage Appliance 儲存堆疊架構中,當 VM 虛擬主機需要使用儲存資源時,整個 Storage Appliance 儲存堆疊架構的操作步驟便需要 6 個動作才能完成。

      圖、Storage Appliance 儲存堆疊架構示意圖

      反觀 VMware vSAN則是原生內建在 vSphere Hypervisor 層級中,所以無須在每台 ESXi 虛擬化平台中安裝或部署 Appliance,並且 vSAN 使用的運算資源通常在每台 ESXi 虛擬化平台中佔用不到「10 %」,最後當 VM 虛擬主機需要使用 vSAN 儲存資源時,在 vSAN 儲存堆疊架構中只需要 3 個動作的操作步驟即可完成,提供最短存取路徑及延遲時間進而提升整體儲存效能表現。

      圖、vSAN 儲存堆疊架構示意圖





      vSAN - Server with Local Storage

      因此,企業及組織只要透過 VMware vSAN 軟體定義儲存技術,便可以將多台安裝 ESXi 虛擬化平台 x86 硬體伺服器中,所有「本機硬碟」(LocalHardDisk)儲存空間匯整(例如,NVMe 快閃儲存、SSD 固態硬碟、HDD 機械式硬碟……等),建構出高可用性高效能的共享儲存資源集區。因此,企業及組織在建構 VMware vSAN 軟體定義儲存環境後,便能同時解決建置「運算和儲存」2大資源的難題,這也是目前非常熱門的「超融合式架構」(Hyper-Converged Infrastructure,HCI)應用情境。

      在每台擔任 vSAN 角色的 x86 硬體伺服器中,可以配置「1 ~ 5 個快取儲存裝置(例如,NVMe 快閃儲存或 SSD 固態硬碟),以及「1 ~ 7 個容量儲存裝置(例如,HDD 機械式硬碟)。

      圖、vSAN 快取/容量儲存裝置示意圖

      當企業及組織需要得到最大化儲存效能時,可以採用「All Flash」的 vSAN 運作架構,例如,NVMe 快閃儲存搭配 SSD 固態硬碟,在 All Flash 的運作架構中「快取層級」(Cache Tier)只會負責資料「寫入」的部份。

      倘若,企業及組織需要得到的是兼顧儲存效能及空間時,則可以採用「Hybrid」的 vSAN 運作架構,例如,SSD 固態硬碟搭配 HDD 機械式硬碟,在 Hybrid 的運作架構中「快取層級」(Cache Tier)則會同時負責資料「寫入及讀取」的部份(如圖所示),並且在預設情況下將會以快取層級的儲存裝置中,以「70 %」的快取空間存放資料「讀取」的部分,而「30 %」的快取空間則存放資料「寫入」的部分。

      圖、vSAN Disk Group 運作架構示意圖





      VMware vSAN 6.7 攻略 - 系列文章


      網管人 155 期 - WS 2019 正式登場新特色功能快速剖析

      $
      0
      0


      網管人雜誌

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





      文章目錄

      前言
      安裝 Windows Server 2019
                最低硬體資源需求
                就地升級作業系統版本
                VM 虛擬主機 AVMA 軟體授權金鑰
                標準版 vs 資料中心版
      新世代雲端作業系統
                Hybrid 混合雲架構
                Security 新世代安全機制
                全方位應用程式平台
                HCI 超融合基礎架構
      結語





      前言

      隨著日前在 Orlando 舉行的 Microsoft Ignite 2018 年度大會上,除了發佈許多 Azure 公有雲上的新增功能之外,同時也針對地端的部分發表最新一代 Windows Server 2019 雲端作業系統

      事實上,喜歡嘗鮮的 IT 管理人員,應該已經在 Windows Server 2019 雲端作業系統正式發佈前,便已經加入 Windows Insiders 技術預覽的計劃中,同時在測試各項新增特色功能時,倘若有更好的建議或意見便可以透過反饋的方式,提供給微軟以便微調成更符合 IT 人員管理需求的特色功能。

      在本文中,我們將深入剖析新一代 Windows Server 2019 雲端作業系統中,主要著重的四大領域(如圖 1 所示):

      • Hybrid:混合雲架構,透過全新 HTML 5 技術打造並且完全免費的 Windows Admin Center 管理工具,可以輕鬆協助 IT 管理人員整合單台伺服器、容錯移轉叢集、HCI 超融合基礎架構、Azure Backup、Azure Site Recovery、Azure IaaS……等混合雲管理作業。
      • Security:新世代安全機制,隨著時間的推移駭客攻擊企業及組織的方法也持續不斷演變及翻新。因此,企業及組織可以透過 Windows Server 2019 新世代安全機制,例如,Windows Defender ATP(Advanced Threat Protection)、Defender Exploit Guard、Shielded VMs……等,避免企業或組織中 VM 虛擬主機中的機敏資料外洩,同時降低被攻擊層面並進行惡意探索機制的防護。
      • Application Platform: 與 Kubernetes 容器調度緊密結合的新世代應用程式平台,在前一代的 Windows Server 2016 版本中,微軟已經與 Docker Swarm 容器調度系統緊密結合。現在,全新的 Windows Server 2019 新世代雲端作業系統,除了為 Server Core 及 Nano Server 儲存空間再度瘦身之外,同時也與主流 Kubernetes 容器調度系統進行緊密結合,達到同時支援調度 Linux 及 Windows 容器的目的。
      • HCI(Hyper-Converged Infrastructure):超融合基礎架構,全新的 Windows Server 2019 新世代雲端作業系統中,最大儲存空間提升至支援「4 PB」、每台 S2D 節點主機的儲存空間提升為「400 TB」、最大 Volume 儲存空間提升為「64 TB」。

      圖 1、新世代 Windows Server 2019 雲端作業系統四大領域示意圖





      安裝 Windows Server 2019

      事實上,企業及組織當中仍然有許多主流應用服務,運作在舊有的 Windows Server 2008 及 2008 R2 作業系統版本中,然而它們的支援結束時間即將在「2020 年 1 月」到期。因此,企業及組織的 IT 管理人員,應該儘早規劃舊有 Windows Server 2008 / 2008 R2 的升級和遷移作業。



      最低硬體資源需求

      原則上,採用舊有通過微軟硬體相容性檢測的 x86 伺服器,或企業及組織中舊有已安裝 Windows Server 2012 R2 及 Windows Server 2016 的硬體伺服器,應該可以順利安裝 Windows Server 2019 雲端作業系統(如圖 2 所示),但實際上會根據系統組態配置及安裝的應用程式和功能而有所不同。下列為安裝 Windows Server 2019 雲端作業系統中,x86 硬體伺服器的最低硬體資源需求:

      • CPU 處理器:至少為 1.4 GHz 的 64 位元處理器,除了應支援 NX / DEP / LAHF / SAHF 之外,倘若需要運作 Hyper-V 虛擬化平台,則必須支援第二層位址轉譯 EPT 或 NPT 等硬體輔助虛擬化功能。
      • RAM 記憶體:至少需要 512 MB 的記憶體空間,倘若採用桌面體驗安裝模式時則至少需要 2 GB 的記憶體空間,同時應採用支援 ECC 機制的實體記憶體,以便確保 Windows Server 2019 系統運作的穩定性。
      • 硬碟控制器及儲存空間需求:至少需要 32 GB 的可用儲存空間,同時這只是確保安裝程序能夠成功執行的最小儲存空間需求。值得注意的是,Windows Server 2019 不支援採用舊式 ATA / PATA / IDE / EIDE 擔任啟動磁碟,也不支援用於存放分頁檔及資料。
      • 網路卡:至少應採用單埠 Gigabit 的乙太網路卡,並且應符合 PCI Express 規範及支援 PXE 網路啟動執行環境。
      • 其它:倘若需要啟用新式安全性機制,例如,Secure Boot 等。則應採用 UEFI 2.3.1 及 TPM 2.0 安全晶片。

      圖 2、Windows Server 2019 安裝流程示意圖



      就地升級作業系統版本

      倘若,IT 管理人員希望採用原有的硬體資源,僅希望將作業系統版本進行升級的動作,那麼可以採用「就地升級」(In-Place Upgrade)機制。值得注意的是,就地升級作業系統版本的動作,並無法「一次」就把舊有作業系統版本升級至最新作業系統版本。

      舉例來說,舊有的 Windows Server 2008 R2 可透過就地升級機制,升級至最新的 Windows Server 2019,但是必須分為「多階段」進行就地升級作業系統版本的動作才行,必須先升級至 Windows Server 2012 R2 作業系統版本,然後再升級至 Windows Server 2016 作業系統版本,最後才升級至最新的 Windows Server 2019 作業系統版本(如圖 3 所示)。

      圖 3、Windows Server 作業系統版本就地升級階段示意圖



      VM 虛擬主機 AVMA 軟體授權金鑰

      隨著 SDDC 軟體定義資料中心的逐漸普及,在虛擬化環境中運作 Windows Server 作業系統的機會非常普遍。因此,微軟從 Windows Server 2012 作業系統版本開始,提供「虛擬主機自動啟用」(Automatic Virtual Machine Activation,AVMA)軟體授權啟用機制。

      當然,在新世代的 Windows Server 2019 中同樣支援此機制,但必須注意必須採用最新的 Hyper-V 虛擬化平台,才能夠支援啟用所有 Windows Server 作業系統版本的軟體授權,舉例來說,採用 Windows Server 2019 Hyper-V虛擬化平台,可以透過 AVMA 機制為安裝 Windows Server 2012 R2 / 2016 / 2019的 VM 虛擬主機啟用軟體授權,倘若採用 Windows Server 2016 Hyper-V 虛擬化平台,便僅能啟用安裝 Windows Server 2012 R2 / 2016 的 VM 虛擬主機啟用軟體授權,而無法為安裝 Windows Server 2019 的 VM 虛擬主機啟用軟體授權。



      標準版 vs 資料中心版

      事實上,從 Windows Server 2012 作業系統版本開始,便只有「標準版」(Standard Edition)「資料中心版」(DataCenter Edition),這 2 種版本特色功能一模一樣,唯一的差別僅在於 VM 虛擬主機「軟體授權數量」不同。

      在新世代的 Windows Server 2019 中,原則上 2 種版本支援的特色功能絕大部分相同,但仍有部分的伺服器角色或功能有不同的支援程度,因此 IT 管理人員在規劃時必須特別注意,舉例來說,標準版不支援安裝「網路控制器」(Network Controller)伺服器角色,標準版不支援安裝「儲存複寫」(Storage Replica)伺服器功能。
      有關標準版及資料中心版的伺服器角色及功能的支援程序差異詳細資訊,請參考 Microsoft Docs - Comparison of Standard and Datacenter editions of Windows Server 2019官方文件內容。





      新世代雲端作業系統

      事實上,微軟在打造新世代 Windows Server 2019 雲端作業系統初期時,並不打算再提供 GUI 圖形介面操作模式,而僅提供運作效能更佳安全性更高的文字介面 Server Core 安裝模式。

      然而,在收到許多 IT 管理人員的意見反應後,桌面體驗 GUI 圖形介面又正式回到 Windows Server 2019,並且跟前一代的 Windows Server 2016 同樣的安裝體驗,在安裝程序中 IT 管理人員,可以選擇僅有文字介面的 Server Core 安裝模式,或是支援 GUI 圖形介面的桌面體驗安裝模式。
      在 Windows Server 的 1709、1803、1809 版本中,僅有文字介面的 Server Core 安裝模式,而沒有 GUI 圖形介面的桌面體驗安裝模式。

      那麼,倘若微軟維持原有計劃僅提供文字介面 Server Core 安裝模式時,IT 管理人員該如何輕鬆且快速的管理 Windows Server 及相關服務呢? 答案,當然就是透過全新 HTML 5 技術所打造的 WAC(Windows Admin Center)管理平台(如圖 4 所示)。
      有關WAC(Windows Admin Center)管理平台的運作架構及詳細資訊,請參考本刊《第 153 期 - 新版 WAC 免費易用,輕鬆管理主機 / 容錯移轉叢集》
      圖 4、全新 HTML 5 技術所打造的 WAC(Windows Admin Center)管理平台



      Hybrid 混合雲架構

      在過去的 Windows Server 管理環境中,當 IT 管理人員要建構 Hybrid 混合雲環境時,必須要切換多個不同的管理介面才能達成,現在只要採用新一代的 WAC 管理平台即可輕鬆達成。

      舉例來說,過往當 IT 管理人員需要為地端 VM 虛擬主機,建構備援至 Microsoft Azure 公有雲運作環境,以便因應企業及組織地端資料中心內的 VM 虛擬主機,因為天然災害或不可抗力因素而無法正常服務且快速復原時,便可以透過 Hybrid 架構的 Azure Site Recovery 機制,將平時複寫至 Microsoft Azure 公有雲的 VM 虛擬主機啟動並繼續提供企業服務。

      然後,組態設定 Azure Site Recovery 機制時,IT 管理人員必須在地端採用 Hyper-V 管理員及容錯移轉叢集管理員,同時還要登入 Microsoft Azure 入口網站進行相關組態設定才行。現在,只要透過 WAC 管理平台即可快速完成整個 Azure Site Recovery機制的組態設定(如圖 5 所示)。

      圖 5、透過 WAC 管理平台即可快速完成整個 Azure Site Recovery 機制的組態設定



      Security 新世代安全機制

      過去,雖然企業及組織在整個資料中心及 IT 基礎架構中,已經部署許多增強安全性的相關運作機制或硬體設備,除了確保線上營運服務不停止之外也同時保護企業機敏資料不外洩,然而隨著時間的推移駭客攻擊企業及組織的方法也不斷演變及翻新,惡意攻擊的方式也從過往正面對決改採潛伏並轉而朝向最弱環節下手。

      簡單來說,相較於企業及組織內強調高安全性高效能的線上營運伺服器來說,惡意攻擊方式則改為朝向安全防護相對薄弱的使用者端電腦下手。有鑑於此,在 Windows Server 2019 雲端作業系統中,新增許多新世代安全防護機制,例如,Windows Defender ATP Exploit Guard、Windows Defender Application Control……等(如圖 6 所示)。

      圖 6、Windows Defender ATP 儀表板示意圖

      除了,新增許多新世代安全防護機制之外也增強原有的安全防護機制,舉例來說,在 Windows Server 2016 時,便支援 Shielded VMs 安全防護機制,它可以有效避免企業或組織內 VM 虛擬主機中的機敏資料外洩。但是,在 Windows Server 2016運作環境中,Shielded VMs 安全防護機制僅支援 Windows 客體作業系統的 VM 虛擬主機。

      現在,Windows Server 2019雲端作業系統中的 Shielded VMs 安全防護機制,也同時支援 Linux 客體作業系統的 VM 虛擬主機。因此,企業及組織中常用的 Ubuntu、Red Hat Enterprise Linux、SUSE Linux Enterprise 等 Linux 作業系統,現在也可以受到 Shielded VMs 安全防護機制的保護(如圖 7 所示)。

      圖 7、Shielded VMs 安全防護機制運作流程示意圖



      全方位應用程式平台

      隨著容器風潮及微服務架構的興起,企業及組織對於容器調度平台的需求不斷上升,根據 Allied Market Research 研究報告指出,2016 年全球應用容器市場已達 6.98 億美元,並預估到 2025 年時將會到達 82 億美元(如圖 8 所示)。

      圖 8、企業及組織對於在容器中運作各項服務的需求不斷提升

      事實上,在去年初容器調度平台其實還處於戰國時代百家爭鳴的情況,例如,Docker Swarm、Mesosphere DC/OS、Kubernetes……等,但是從今年開始已經可以明顯感覺 Kubernetes 容器調度平台已經勝出,其中一個主要因素便是可以同時調度 Windows 及 Linux 異質容器環境。

      因此,除了各家公有雲服務供應商提供的容器服務,皆採用 Kubernetes 容器調度平台之外,企業及組織地端的資料中心內,運作容器環境時採用 Kubernetes 容器調度平台也已經是大勢所趨。

      現在,在 Windows Server 2019 雲端作業系統中,內建便支援運作 Kubernetes 容器調度平台,並且可以在同一個 Docker Daemon 當中,「同時」運作 Windows 及 Linux 容器環境,達到異質容器環境同時運作及調度的目的,為企業及組織提供更高的靈活性。
      目前主流的異質容器運作環境,通常是由 Linux 主機負責運作 Linux 容器環境,而 Windows 主機則負責運作 Windows 容器環境。

      其實,在 Windows Server 2016 版本推出時便已經支援 Windows 容器環境,但是並無法原生運作 Linux 容器環境。此外,在容器調度平台方面,則是跟當時火紅的 Docker Swarm 容器調度平台結合,倘若想要建構 Kubernetes 容器調度平台則需要額外的組態設定,並且在容器網路方面還要進行額外的調整才行。

      現在,微軟為了更深度與 Kubernetes 容器調度平台進行整合,首先併購了 Deis公司並積極開發 Helm 開放源始碼套件管理機制,以便讓 IT 管理人員更容易安裝及升級,在 Kubernetes 容器調度平台中的應用程序及服務。

      在容器虛擬網路方面,微軟也與 Tigera 合作準備建構 Calico CNI 容器虛擬網路的解決方案,以便提供動態路由(BGP)和 IPAM 位址管理等機制。此外,在 Windows Server 2019 當中的 Kubernetes 容器調度平台,也可以採用 CoreOS 的 Flannel CNI 路由管理機制,以便因應運作容器時虛擬網路的各項需求。
      微軟除了支援 Kubernetes 容器調度平台之外,目前也與 RedHat 合作以便提供同樣以 Kubernetes 為基礎所打造的 Red Hat OpenShift容器調度平台。
      值得注意的是,雖然 Windows Server 2019 已經完全支援運作 Kubernetes 容器調度平台,但是目前最新推出的 Kubernetes 1.12 版本,並未完全與 Windows Server 2019 整合,必須採用下一版預計推出的 Kubernetes 1.13版本(如圖 9 所示),才能夠完全與 Windows Server 2019 整合運作,打造異質容器環境調度平台。

      圖 9、Kubernetes on Windows Server Roadmap



      HCI 超融合基礎架構

      根據知名市調機構 Gartner 的研究結果指出,在 2017 年時全球大型企業中有高達 75 % 的比例,將建構 Mode 1 及 Mode 2 雙重 IT 基礎架構稱之為「Bimodal IT」。傳統 Mode 1 資料中心內的工作負載、技術、流程、部署模式已經行之有年無須再驗證,但是新興的 Mode 2 資料中心在根本上就與 Mode 1 不同,它強調的是「敏捷性」(Agility)「可擴充性」(Scalability),以便協助企業及組織快速推出各種服務的一種方式。

      同時在 Gartner 調查結果中顯示,從 2016 年開始有「2/3 以上」的企業及組織,開始建構及整合「Mode 2」的敏捷式 IT 基礎架構,所謂「基礎架構敏捷化」(Infrastructure Agility),便是著重於 IT 基礎架構中「Mode 2」的部分以便因應商業數位化的需求。

      然而,在企業及組織的傳統資料中心內,過往運算及儲存資源總是各司其職各自獨立,然而從前幾年的融合式基礎架構,到最新的「超融合基礎架構」(Hyper-Converged Infrastructure,HCI),幫助解決傳統資料中心內運算及儲存資源的困擾,進而整合及協同運作達成基礎架構敏捷化的目標(如圖 10 所示)。

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

      在 Windows Server 2016 版本推出時,IT 管理人員便可以透過標準的 x86 硬體伺服器,搭配 Windows Server 2016 內建的 S2D(Storage Spaces Direct)機制,為企業及組織打造 HCI 超融合基礎架構。
      有關採用 Windows Server 2016 作業系統,搭配 S2D 機制打造 HCI 超融合基礎架構的詳細資訊,請參考本刊《 第 129 期 - 微軟最新軟體定義儲存,公有雲端立馬實作 S2D》

      在 Windows Server 2019 雲端作業系統中,將 S2D 運作機制及特色功能再度增強,舉例來說,在 Windows Server 2016 版本中建構的 S2D 超融合基礎架構,最大儲存空間支援至「1 PB」、每台 S2D 節點主機的儲存空間為「100 TB」、最大 Volume 為「32 TB」。現在,透過 Windows Server 2019 所打造的 S2D 超融合基礎架構,最大儲存空間提升至支援「4 PB」、每台 S2D 節點主機的儲存空間提升至支援「400 TB」、最大 Volume 提升至支援「64 TB」(如圖 11 所示)。

      圖 11、Windows Server 2019 全面提升 S2D 超融合基礎架構支援度

      此外,在 Windows Server 2016 版本中,建立 S2D 超融合基礎架構之後的 S2D Cluster,在仲裁機制方面僅支援「File Share Witness」及「Cloud Witness」等 2 種機制。

      在 Windows Server 2019 當中的 S2D Cluster,支援將仲裁機制指向至「USB 隨身碟」(如圖所示 12)。因此,仲裁機制可以無須由其它硬體伺服器、VM 虛擬主機、Active Directory……等即可建立,讓企業及組織在建立小型的 S2D 超融合基礎架構時更加方便。
      最小型的 S2D 超融合基礎架構,只要「2 台」S2D 節點主機即可建構完成。
      圖 12、Windows Server 2019 USB Witness 運作示意圖

      此外,在 Windows Server 2016 所打造的 S2D Cluster 中,建立的 Volume 儲存空間倘若需要啟用「重複資料刪除」(Data Deduplication)時,僅支援針對「NTFS」檔案系統的 Volume 儲存空間啟用,倘若採用新式的 ReFS 檔案系統則無法支援啟用重複資料刪除機制。

      現在,採用 Windows Server 2019 所打造的 S2D Cluster Volume 儲存空間,除了同時支援「NTFS 和 ReFS」檔案系統啟用重複資料刪除機制之外,在啟用重複資料刪除機制的 Volume 儲存空間支援最大至 64 TB,並且單一檔案大小可支援最大至 1 TB

      還記得嗎? IT 管理人員可以透過新世代的 WAC 管理平台進行管理作業,即便是 S2D 超融合基礎架構也可以輕鬆管理,同時 WAC 管理平台除了支援新世代 Windows Server 2019 的 S2D Cluster 之外,也支援管理採用 Windows Server 2016 所建構的 S2D Cluster 。

      IT 管理人員透過 WAC 管理平台便可以輕鬆了解,目前 S2D Cluster 的 IOPS 儲存效能、Latency 延遲時間、Throughput 傳輸速率、儲存資源剩餘空間、VM 虛擬主機運作數量……等(如圖 13 所示)。
      有關透過 WAC 管理平台輕鬆管理 S2D 超融合基礎架構的詳細資訊,請參考本刊《第 153 期 - 新版 WAC 免費易用,輕鬆管理主機 / 容錯移轉叢集》
      圖 13、透過 WAC 管理平台輕鬆管理 S2D 超融合基礎架構





      結語

      透過本文的深入說明及剖析,相信讀者已經了解新世代 Windows Server 2019 雲端作業系統中,有哪些新增及增強的亮眼特色功能,後續也將不定期為各位讀者深入剖析及實作演練各項進階功能,以便協助企業及組織內的 IT 管理人員快速整合新世代 Windows Server 2019 雲端作業系統。

      [站長開講] VMware vSphere 伺服器虛擬化實戰班

      $
      0
      0

      活動資訊

      日期: 2018 年 11 月 16 日 ~ 12 月 16 日
      時間: 09:00 ~ 17:00
      地點:資策會 (台中市南屯區公益路二段51號20樓)
      報名:資策會課程 - VMware vSphere 伺服器虛擬化實戰班








      課程大綱

      VMware 虛擬化平台最佳硬體規劃

      虛擬化實作環境建置(Nested VMs)

      建置 VMware 虛擬化平台

      • 安裝及初始化 ESXi 虛擬化平台
      • 安裝及管理 vCenter Server
      • 建立 DataCenter、Cluster
      • 納管 ESXi 主機

      建置虛擬網路環境

      • vSwitch、Port Group、Network Policy、VMkernel Port、NIC Teaming

      VM 虛擬主機管理

      • 虛擬磁碟線上擴充(Disk Online Extend)
      • 記憶體空間熱新增(Memory Hot Add)
      • CPU熱新增(CPU Hot Add)
      • 備份及還原
      • P2V及V2V轉換

      計畫性停機解決方案

      • 即時遷移(vMotion / DRS)
      • 儲存即時遷移(Storage vMotion / Storage DRS)
      • 無共用儲存即時遷移(vMotion Enhancements)

      非計畫性停機解決方案

      • 高可用性(vSphere HA / Fault Tolerance)

      VMware vExpert 2019 開放申請

      $
      0
      0


      前言

      每一年的年初時,VMware 官方便會開放一年一度申請 VMware vExpert的活動。今年,也就是 VMware vExpert 2019的活動已經開始開放申請,VMware vExpert 其實是個類似 Microsoft MVP的技術頭銜也是採「申請制」,簡單來說就是提交你認為對該產品有哪些貢獻,之後交由原廠審核並認同你是否真的值得獲得此技術頭銜。目前,截至 2018 年底為止全球的 vExpert 人數為 1536位 (台灣連同我共有 5 位獲選)。



      申請 vExpert 2019 注意事項

      今年,開放申請期間至「2019 年 2 月 8 日 (PDT 時區)」,並且預計在 2 月底 3 月初進行公佈獲選人員名單。參選詳細資訊請參考 VMware vExpert Blogs - vExpert 2019 Applications are Open!



      申請成為 VMware vExpert 的路徑

      請可以依照個人的貢獻程度,透過下列不同路徑進行 VMware vExpert 2019 的申請

      • 技術傳教士路徑 (Evangelist Path):選擇此申請路徑者,通常為 書籍作者 (Book Authors)、部落客 (Bloggers)、工具建立者 (Tool Builders)、公開演說者 (Public Speakers)、VMTN 貢獻者 (VMTN Contributors)...等,簡單說就是透過個人途徑把 VMware 技術發享出去。
      • 使用者路徑 (Customer Path):選擇此申請路徑者,通常是 VMware 企業客戶的 Leaders,透過建置 VMware 的成功經驗讓其它客戶當參考,或者是 VMUG (VMware User Group) Leaders...等,都可以申請。
      • VMware 合作夥伴路徑 (VMware Partner Network Path):選擇此申請路徑者,通常是 VMware 合作夥伴透過 教學影片、研討會 方式將技術發享出去...等,都可以申請。
      • VCDX 路徑 (VCDX Path):選擇此申請路徑者,只適用於你已經持有 VCDX 證照才能申請。


      因為,我是 APJ 區域的 vExpert PRO,倘若你有興趣申請 VMware vExpert 但有任何不了解的地方,可以跟我討論。




      獲選 VMware vExpert 的好處

      當你申請後獲選為 VMware vExpert 的話有哪些好處呢? 你可以獲得 Private Beta 的測試機會、VMware Free Licenses (365 Days)、免費存取 VMworld 會議資料...等,如下列所示:

      • Invite to our private #Slack channel
      • vExpert certificate signed by our CEO Pat Gelsinger.
      • Private forums on communities.vmware.com.
      • Permission to use the vExpert logo on cards, website, etc for one year
      • Access to a private directory for networking, etc.
      • Exclusive gifts from various VMware partners.
      • Private webinars with VMware partners as well as NFRs.
      • Access to private betas (subject to admission by beta teams).
      • 365-day eval licenses for most products for home lab / cloud providers.
      • Private pre-launch briefings via our blogger briefing pre-VMworld (subject to admission by product teams)
      • Blogger early access program for vSphere and some other products.
      • Featured in a public vExpert online directory.
      • Access to vetted VMware & Virtualization content for your social channels.
      • Yearly vExpert parties at both VMworld US and VMworld Europe events.
      • Identification as a vExpert at both VMworld US and VMworld EU.

      網管人 156 期 - 學會 Horizon 7.6 VDI 虛擬桌面快速部署上線

      $
      0
      0

      網管人雜誌

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






      文章目錄

      前言
      新版 Horizon 7.6 特色功能
      實戰 Horizon 7.6 基礎架構組態設定
                建立 Windows AD 網域環境
                建構 vSphere 虛擬化平台
                建構 SQL Server 資料庫
                建構 Composer 伺服器角色
                建構 Connection 伺服器角色
                新增 Horizon 7 軟體授權
                新增 vCenter / Composer 伺服器角色
                組態設定 Event 資料庫
      結語





      前言

      VMware 官方在 2018 年 9 月,發佈桌面和應用虛擬化平台的最新版本 Horizon 7.6。在最新版本中,除了企業及組織地端資料中心所需的 VDI 虛擬桌面功能強化之外,隨著公有雲應用的趨勢日漸增溫,管理人員也可以選擇將 Horizon 部署在 Amazon AWS、IBM Cloud、Microsoft Azure 等雲端環境中。
      VMware VDI 虛擬化桌面的最初版本,為 2008 年發佈的 VMware View Manager 3

      簡單來說,當管理人員希望部署 Horizon VDI 虛擬桌面解決方案時,可以選擇「自行部署」或「Horizon Cloud Service」這二大部署模式(如圖 1 所示)。

      圖 1、VMware Horizon VDI 虛擬桌面解決方案部署模式示意圖

      首先,「自行部署」的部分可以在企業及組織內部的資料中心內,自行建置傳統的 VMware Horizon 虛擬桌面運作環境,另一種選擇則是採用「VMware Cloud on AWS」雲端部署模式,管理人員可以在 Amazon AWS 雲端環境中部署及管理 Horizon 虛擬桌面環境。

      至於「Horizon Cloud Service」部署模式,則分別支援「Horizon Cloud on IBM Cloud」及「Horizon Cloud on Microsoft Azure」等二種雲端部署模式,讓使用者可以直接在這二家雲端供應當運作環境中使用 VDI 虛擬桌面及應用服務。

      此時,管理人員應該會感到納悶,將 Horizon 虛擬桌面環境運作在 AWS、IBM Cloud、Azure這三者有何不同? 簡單來說,採用 VMware Cloud on AWS 雲端部署模式時(如圖 2 所示),管理人員就像管理地端資料中心的傳統 Horizon 虛擬桌面環境一樣,將能夠擁有「充分」的管理及部署權限。

      至於,採用 Horizon Cloud Service 部署模式時,則 Horizon 虛擬桌面環境將由「VMware 負責主要管理」,因此對於管理人員來說在組態設定及管理部署時將會受限而缺少靈活性。

      圖 2、VMware Cloud on AWS 運作架構示意圖





      新版 Horizon 7.6 特色功能

      那麼,讓我們來看看最新發佈的 VMware Horizon 7.6 版本中,有哪些新增亮眼特色功能或增強哪些原有特色功能:
      • 增強的 Horizon Connection Server: 除了新增支援 vSphere 6.5 U2 虛擬化平台版本,以及 vMotion 也可遷移啟用 vGPU 的虛擬桌面之外,現在管理人員可以透過 Horizon 7 Cloud Connector 機制,來管理 VMware Horizon Cloud Service 上代管的訂閱服務。
      • Horizon Agent for Linux: 除了支援新版 Ubuntu 18.04、RHEL / CentOS 6.10、RHEL / CentOS 7.5 版本之外,建立的 RHEL 7 及 CentOS 7 Linux 虛擬桌面已經支援 True SSO 機制,達到真正 SSO 單一登入的目。此外,從 RHEL 7.1 及後續版本開始支援 Instant-Clone 機制,幫助管理人員更快部署大量 Linux 虛擬桌面。
      • Horizon Agent on RDS Host: 現在當管理人員在 RDS 主機上安裝 Horizon Agent 時,可以啟用重新導向「Serial Port」及「地理位置」的功能,值得注意的是必須搭配 Horizon Client 4.9 for Windows 的版本才行。
      圖 3、Horizon 7.6 邏輯架構運作示意圖





      實戰 Horizon 7.6 基礎架構組態設定

      了解最新發佈的 Horizon 7.6 虛擬桌面運作架構及特色功能後,在開始進行 Horizon 7.6 基礎架構的組態設定作業之前,管理人員必須先知道在 VMware Horizon 基礎運作架構中,需要建構的角色有 ESXi 虛擬化平台、vCenter Server、Windows AD 網域環境(DNS / DHCP / Certificate Authority)、Identity Manager、View Connection Server、View Composer Server、AirWatch、App Volume、vSAN、Unified Access Gateway……等。

      事實上,建置 VMware Horizon 虛擬桌面基礎架構,擔任各項應用服務的伺服器角色並沒有絕對的建置先後順序,不過一般來說在建構 Horizon 基礎架構時建議採用下列流程:

      1. 建立 Windows AD(Active Directory)網域環境,並且新增 VDI 虛擬桌面的使用者帳號和群組以及管理者帳號和群組。
      2. 建構及組態設定 vSphere 虛擬化基礎架構,包含 ESXi 虛擬化平台及 vCSA 管理平台。
      3. 安裝及組態設定 SQL Server 資料庫。
      4. 安裝及組態設定 View Composer 伺服器角色,並且設定 Composer 資料庫連接事宜。
      5. 安裝及組態設定 View Connection 伺服器角色,並且設定 Event 資料庫。
      6. 建立 Full-Clone 或 Linked-Clone 或 Instant-Clone 虛擬桌面資源池。
      7. 安裝及組態設定 RDSH 伺服器角色,並且設定遠端使用者所需應用程式。
      8. 建立 RDSH 用途虛擬桌面資源池或應用程式資源池。
      9. 授權使用者或群組使用指派的虛擬桌面資源池或已發佈的應用程式,同時建立及組態設定其它管理員帳號,以便針對特定對象組態設定不同層級的存取權限。
      10. 在使用者端為他們的連線裝置安裝及組態設定 Horizon Client,以便存取虛擬桌面資源池或已發佈的應用程式。
      11. 組態設定 GPO 群組原則,以便管控使用者或群組存取虛擬桌面資源池或已發佈的應用程式的行為。
      12. 當企業及組織允許由外部網路存取虛擬桌面資源池或已發佈的應用程式時,考量安全性建議應整合 Smart Card 身份驗證機制或 RADIUS 雙因素身份驗證機制。

      圖 4、Horizon 7.6 基礎架構運作示意圖



      建立 Windows AD 網域環境

      事實上,使用者身份驗證的機制非常多樣化,然而一般來說企業及組織達成 SSO 單一登入最普遍的機制便是採用 Windows Active Directory,因此在本文實作環境中也將建置 Windows AD 網域環境,以便透過 Windows AD 網域的網域控制站 DC(Domain Controller),達成使用者身份的「驗證(Authentication) / 授權(Authorization)」機制,後續也可以搭配 Horizon True SSO 機制。

      建議採用的 Windows DC 網域控制站版本及資源配置如下:
      • Windows Server 2016 或後續版本。
      • VMware Virtual Hardware 13 或後續版本。
      • 2 vCPU、6 GB vRAM、1 vNIC(VMXNET 3)、40 GB vDisk(LSI Logic SAS)。

      圖 5、Windows AD 搭配 True SSO 使用者身份驗證及授權邏輯架構運作示意圖

      在 Windows 網域環境中,為了確保使用者登入時操作環境的一致性通常會透過使用者設定檔的方式來達成,在 Windows 使用者設定檔中共有 3 種類型,分別是強制使用者設定檔(Mandatory User Profiles)、本機使用者設定檔(Local User Profiles)、漫遊使用者設定檔(Roaming User Profiles)

      在 Horizon VDI 虛擬桌面運作環境中,保持使用者登入時操作環境一致性的部分,通常不適合使用「強制使用者設定檔」和「本機使用者設定檔」,而是採用「漫遊使用者設定檔」(Roaming User Profiles)的方式,以便確保使用者登入 Horizon VDI 虛擬桌面時能有一致的操作環境。

      圖 6、使用者操作環境配置策略架構示意圖

      此外,基於管理考量也會為 Horizon VDI 虛擬桌面運作環境建立額外的 OU 容器,在本文實作環境中建立名稱為「Horizon-VDI」的 OU 容器,並且再建立名稱為「VDI Users、VDI Computers」的 2 個子 OU 容器,用於存放 Horizon VDI 虛擬桌面的使用者帳號和群組及 VDI 虛擬桌面電腦帳戶,以便屆時能夠針對 VDI 虛擬桌面環境套用 GPO 群組原則。

      圖 7、針對 Horizon VDI 虛擬桌面建立專用的 OU 容器以利後續管理需求



      建構 vSphere 虛擬化平台

      vCenter Server 管理平台

      在 Horizon VDI 正式營運環境中,VMware 建議應該將擔任「管理」用途的 VM 虛擬主機,以及擔任 VDI 虛擬桌面的 VM 虛擬主機,分別採用「不同台」vCenter Server 進行分拆管理,原因在於避免 vSphere 基礎架構複雜化之外,在管理思維上也可以避免 SPOF 單點失敗的影響,舉例來說,倘若管理 VDI 虛擬桌面環境的 vCenter Server 發生故障損壞事件,短期之間難以修復時可以先讓管理環境的 vCenter Server 暫時接手管理作業達到備援的效果。

      雖然,在 Horizon VDI 運作架構「每個 Pod」可以承載「20,000 Sessions」,倘若採用 CPA(Cloud Pod Architecutre)架構將多個 Pod 串連時,更可以承載高達「140,000 Sessions」。然而,有鑑於組態配置及高可用性管理需求,VMware 最佳作法中「每個 Block」當中每台 vCenter Server,在管理 VDI 虛擬桌面數量方面建議為 4,000 ~ 5,000 台。
      有關 Horizon 運作架構規模大小的詳細資訊,請參考 VMware KB2150348 - VMware Horizon 7 sizing limits and recommendations文章內容。
      有關 vCenter Server 建議採用的版本及資源配置如下:
      • vCenter Server 6.5(SUSE Linux Enterprise 12)或後續版本。
      • VMware Virtual Hardware 13 或後續版本。
      • 8 vCPU、24 GB vRAM、1 vNIC(VMXNET 3)、300GB vDisk(LSI Logic Parallel)。

      圖 8、Horizon Pod 及 Block 運作架構示意圖

      ESXi 虛擬化平台

      本文實作環境中,將採用最新發佈的 vSphere ESXi 6.7.0 Update 1 版本,以便提供最新穩定的虛擬化平台,並且運作的 Horizon VDI 虛擬桌面也因為採用最新 ESXi 虛擬化平台,得以使用最新虛擬硬體版本以便獲得最大硬體資源及延展性。

      圖 9、採用最新 vSphere ESXi 6.7.0 Update 1 虛擬化平台版本

      此外,管理人員應該好奇如何估算每台 ESXi 主機能夠運作多少台 VDI 虛擬桌面? 舉例來說,倘若我們希望每台 ESXi 主機,能夠同時承載 40 台 VDI 虛擬桌面時應該如何估算,假設我們為每台 VDI 虛擬桌面配置 2 vCPU,並且使用 500 MHz 的 CPU 運算資源,同時預估 vCPU 額外工作負載為 10 %。

      在 ESXi 主機 CPU 硬體資源的部分,配置 2 顆 Intel Xeon E5-2699v4 高效能 CPU 處理器且每顆處理器擁有 22 個運算核心,每個運算核心的時脈為 2.2GHz,所以每顆 CPU 擁有 48.4 GHz 的運算能力,每台 ESXi 主機擁有 96.8 GHz的運算能力,扣除 ESXi 主機額外工作負載 10 % 的運算資源,保留 90 % 的運算資源後為「87.12 GHz」。因此,每台 ESXi 主機在 CPU 運算資源方面,可以運作的 VDI 虛擬桌面為「87 台」。

      同樣的,我們估計每台 VDI 虛擬桌面,運作 Windows 10 作業系統(64位元)配置 16 GB 虛擬記憶體,每台 VDI 虛擬桌面的 vRAM 額外工作負載為 143.98 MB,並且未設定「Memory Reservation」記憶體空間預先保留機制。

      在 ESXi 主機記憶體硬體資源的部分,配置 768 GB 記憶體空間扣除額外工作負載 10 % 後,保留 90 % 的記憶體資源為「691.2 GB」。因此,每台ESXi主機在Memory記憶體資源方面,可以運作這樣的VDI虛擬桌面為「41台」。

      圖 10、VM 虛擬主機虛擬記憶體額外工作負載資訊

      vSphere Cluster(Block)

      在 Horizon VDI 虛擬桌面運作架構中,針對 vSphere Cluster 的部分建議將「管理」(Management)用途及「VDI 虛擬桌面」(Desktop)用途分開建立,並且由「不同台」vCenter Server 主機進行管理。

      舉例來說,建立第 1 個 vSphere Cluster 名稱為「Management」,此 vSphere Cluster 除了由多台 ESXi 主機組成,並運作所有管理工作任務的 VM 虛擬主機,例如,Connection Server、Composer Server……等。同時,除了應用服務建立高可用性機制之外,此 vSphere Cluster 也必須啟用「vSphere HA」及「vSphere DRS」機制,以確保管理用途的 VM 虛擬主機提供的服務具備高可用性。

      接著建立第 2 個 vSphere Cluster 名稱為「Desktop」,此 vSphere Cluster 由多台 ESXi 主機組成並運作數百台 VDI 虛擬桌面。值得注意的是,此 vSphere Cluster 中通常只會啟用「vSphere DRS」機制,以便針對 VDI 虛擬桌面進行工作負載自動平衡機制即可,「不」建議啟用 vSphere HA 高可用性機制,原因在於每台 ESXi 主機已經運作數量眾多的 VDI 虛擬桌面,倘若啟用 vSphere HA 高可用性機制,當某台 ESXi 成員主機發生故障損壞的情況時,將會因為 vSphere HA 高可用性機制的緣故,造成其它台 ESXi 主機的工作負載瞬間加重,因此這個 vSphere Cluster 不建議開啟 vSphere HA 機制。

      圖 11、Horizon 7.6 vSphere Cluster 運作架構規劃示意圖

      Networking

      在 Horizon VDI 虛擬桌面運作架構中,建議採用分佈式交換器 vDS(vNetwork Distributed Switch),搭配 vDS 分佈式交換器中的 NIOC(Network I/O Control)網路流量管控機制。舉例來說,在每台 ESXi 主機上配置 2 張單一連接埠的 10 Gbps 網路卡,並分別連接到不同台實體網路交換器上,以避免 10 Gbps 網路卡或實體網路交換器發生故障損壞事件造成 SPOF 單點失敗的問題,同時依據流量用途規劃出「4 種」Port Group,以利管理人員能輕鬆掌握各種網路流量的傳輸情況及方便進行故障排除作業:
      • Management: 負責 ESXi 主機的管理流量,建議組態設定網路流量共享層級為「Normal」共享數值為「50」。
      • Virtual Machine: 管理用途的 VM 虛擬主機以及 VDI 虛擬桌面對外提供服務的流量,建議組態設定網路流量共享層級為「High」共享數值為「100」。
      • vSAN: vSAN(或傳統 iSCSI MPIO)儲存網路傳輸流量,建議組態設定網路流量共享層級為「Normal」共享數值為「50」。
      • vMotion: 用於 vSphere vMotion 線上即時遷移 VM 虛擬主機的傳輸流量,建議組態設定網路流量共享層級為「Normal」共享數值為「50」。

      圖 12、Horizon VDI 虛擬桌面網路流量規劃示意圖



      建構 SQL Server 資料庫

      在 Horizon VDI 虛擬桌面運作架構中,SQL Server 資料庫用途為存放「Connection Server Event、Composer Server、Identity Manager、App Volumes」等組態設定資料。建議採用的 SQL Server 版本及資源配置如下:
      • Windows Server 2016 或後續版本。
      • SQL Server 2016 或後續版本。
      • VMware Virtual Hardware 13 或後續版本。
      • 2 vCPU、8 GB vRAM、1 vNIC(VMXNET 3)、40 GB / 50 GB vDisk(LSI Logic SAS)。

      在本文實作環境中採用 SQL Server 2016 SP2 版本,並且分別建立 Composer Server 使用的「Composer-DB」資料庫,以及後續存放 Connection Server 中 VDI 虛擬桌面事件用途的「Event-DB」資料庫。

      圖 13、建立 Composer Server 及 Event 用途的資料庫




      建構 Composer 伺服器角色

      在 Horiozn 運作架構中,透過 Composer Server「連結複製」(Linked Virtual Machine Clones)的運作機制,為每台 VDI 虛擬桌面主機建立「唯一指標」(Unique Pointers),因此每台 VDI 虛擬桌面主機所佔用的空間只會有「差異」的部份而已,與 Master Image 佔用空間相較之下通常可以減少 50 % ~ 70 %的空間大小。建議採用的 View Composer Server 版本及資源配置如下:

      • Windows Server 2016 或後續版本。
      • VMware Virtual Hardware 13 或後續版本。
      • Horizon 7 Composer Server 7.3.2 或後續版本。
      • 4 vCPU、12 GB vRAM、1 vNIC(VMXNET 3)、40 GB vDisk(LSI Logic SAS)。

      在本文實作環境中,採用最新 Horizon 7.6 的 View Composer Server 版本。值得注意的是,為了能夠順利將 Composer Server 的資料庫,指向至剛才所建立專用的 SQL Server 資料庫主機,所以必須先為 Composer Server 組態設定 ODBC,稍後才能將 Composer Server 資料庫指向至剛才所規劃的「Composer-DB」資料庫中。

      圖 14、為 Composer Server 組態設定 ODBC 資料庫連線工作任務



      建構 Connection 伺服器角色

      在 Horiozn 運作架構中 Connection Server,為負責擔任 VDI 虛擬桌面「代理人」(Broker)的角色,因為 VDI 虛擬桌面中的「代理程式」(Agent),隨時會將目前的運作狀態回報給 Connection Server,所以 Connection Server 可以得知每台 VDI 虛擬桌面的運作狀態,例如,桌面目前狀態為可用、更新中、重新啟動中……等。

      在 VMware 最佳作法中,建構 Connection Server 負載平衡或高可用性運作架構時,建議採用「N + 1」的方式進行規劃。下列為「每台」Connection Server 建議採用的版本及資源配置如下:
      Windows Server 2012 R2或之後的版本。

      • VMware Virtual Hardware 11或之後的版本。
      • Horizon View 7.0或之後的版本。
      • 4 vCPU、12 GB vRAM、1 vNIC(VMXNET 3)、40 GB vDisk(LSI Logic SAS)。

      有關 Connection Server 負載平衡運作架構的詳細資訊,請參考 VMware KB2146312 – Load Balancing for VMware Horizon View文章內容。
      圖 15、高可用性 Connection Server 負載平衡運作架構示意圖

      在本文實作環境中,採用最新 Horizon 7.6 的 Connection Server 版本,在安裝流程中於安裝選項頁面時,請選擇「Horizon 7 Standard Server」並勾選「Install HTML Access」項目,以便屆時也可以透過 HTML 網頁連接至 VDI 虛擬桌面,最後請確認採用「IPv4」通訊協定即可。

      圖 16、安裝 Horizon 7 Connection Server

      安裝完成後,雖然整個 Horizon VDI 虛擬桌面運作架構還在建構當中,但是因為 Connection Server 已經安裝完畢,所以可以先確認及登入至 Horizon Administrator 管理平台,以便確認 Connection Server 及相關服務正常運作。

      圖 17、登入 Horizon Administrator 管理平台



      新增 Horizon 7 軟體授權

      登入 Horizon 7 管理介面後,首先必須要新增 Horizon 7 軟體授權才行,否則後續將無法使用 Horizon 相關特色功能,例如,Composer、Instant Clone……等。請在 Horizon 管理介面中,依序點選「View 組態 > 產品授權及使用 > 編輯授權」後,填入你所擁有的 Horizon 7 軟體授權即可。

      圖 18、新增 Horizon 7 軟體授權



      新增 vCenter / Composer 伺服器角色

      當管理人員新增完 Horizon 7 軟體授權後,便可以準備新增 vCenter 及 Composer 伺服器資訊,以利後續 VDI 虛擬桌面的佈建作業。請在 Horizon 管理介面中,依序點選「View Configuration > Server > vCenter Server > Add」,在彈出的新增 vCenter Server 視窗中,填入 vCenter 伺服器管理者資訊。

      通過 vCenter 伺服器的驗證程序後,接著填入 Composer 伺服器的管理資訊,此實作環境中因為 Composer 伺服器,並未跟 vCenter 伺服器安裝在同一台主機中,因此選擇「Standalone View Composer Server」選項。最後,在儲存空間頁面中詢問勾選是否啟用相關特色功能,例如「Reclaim VM disk space」或「Enable View Storage Accelerator」,請管理人員依照運作架構環境需求勾選即可。

      圖 19、新增 vCenter 及 Composer 伺服器資訊



      組態設定 Event 資料庫

      在 Horizon 運作架構中,系統運作狀態及組態設定和 VDI 虛擬桌面運作資源,都會記錄於 Horizon Event 資料庫當中。然而,當你點選 Horizon View Administrator 管理介面中的「事件」項目時,將會發現無法看到任何事件記錄於其中,原因是必須先指定 Event DB 事件資料庫之後才行。在目前 Horizon 事件資料庫中,支援 Microsoft SQL Server 及 Oracle 資料庫。

      在本文實作環境中採用 Microsoft SQL Server 2016 SP2 所建構的資料庫環境。請於 Horizon 管理介面中,依序點選「View Configuration > Event Configuration > Event Database > Edit」,此時將彈出編輯事件資料庫視窗,請填入資料庫伺服器主機名稱或 IP 位址、連接埠、資料庫名稱……等資訊,設定事件資料庫完成後,此時再度點選「事件」項目便可以看到相關事件,以幫助你進行故障排除任務。

      圖 20、組態設定 Horizon Event 事件組態資料庫

      此外,管理人員也可以在 Horizon 7 Administrator 管理介面上方按下「Horizon Console」,便會開啟新的「Horizon Console UI」管理介面,後續也可以透過新的管理介面建立及監控 VDI 虛擬桌面資源池及應用程式資源池。

      圖 21、新的 Horizon Console UI 管理介面





      結語

      透過本文的說明及實作相信讀者已經了解,在最新 Horizon 7.6 VDI 虛擬桌面解決方案有哪些特色功能,能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 VDI 虛擬桌面運作環境,同時也剖析如何規劃 Horizon 7.6 運作架構及資源管理的部分,最後進行實戰演練以便協助管理人員更深入了解整個運作架構及建置流程。

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

      $
      0
      0

      前言

      先前,我們已經討論過在 Windows Server 2016 所建構的 S2D 環境中,採用 100GbE iWARP 時的儲存效能及輸送量,以及整合 Storage Replica 時的運作效能。相關內容請參考下列站內文章:

      我們已經知道在 S2D (Storage Spaces Direct) 軟體定義儲存環境中,採用 RDMA (RoCE / iWARP / infiniband) 可以獲得  ultra-low latency, low-CPU, low-memory, high throughput SMB and workload performance 好處 。

      因此,在這樣的運作架構中,由 SMB Direct (SMB 3.1.1) 機制搭配實體支援 RDMA 技術的網路介面卡,在都可以在 S2D HCI 超融合運作架構中受惠:
      • Storage Spaces Direct
      • Storage Replica
      • Hyper-V Live Migration
      • Windows Server and Windows 10 Enterprise client SMB operations
      那麼本文要討論的重點是什麼?





      Storage Replica 2016 vs 2019

      在本文中,將討論在 Chelsio iWARP RDMA 運作環境,採用 Storage Replica 機制時可以獲得怎麼樣的運作效能。下列便是本文的測試環境:
      • OS: Windows Server 2016 RTM、Windows Server 2019 build 17744
      • System Model: 2x Supermicro Servers
      • CPU: Intel(R) Xeon(R) CPU E5-2687W v4 @ 3.00GHz (2 sockets, 24 cores) per node
      • RAM:128GB per node
      • INTEL NVME SSD Model: SSDPECME016T4 (1.6TB) – 5x in source node
      • Micron NVME SSD Model: MTFDHAX2T4MCF-1AN1ZABYY (2.4TB) – 5x in destination node
      • RDMA NIC: 2x Chelsio T62100-CR 100Gb iWARP RNICs
      圖、Chelsio T62100-CR 100Gb iWARP RNICs





      Storage Replica 效能測試

      在本文測試環境中,建立 1TB Volume進行 Storage Replica 效能測試,可以看到在單一 100Gb iWARP 環境中,由於傳輸速率高達 94Gb 所以整個同步過程才花費 95 秒即完成,並且在同步過程中並不會影響 S2D Host CPU/Memory 工作負載 (100% Read on the Source Host, 100% Write on the Destination Host)。倘若,有多個 100Gb iWARP 再搭配 SMB MultiChannel 機制的話,相信整個傳輸流量會更為下降。

      圖、同步 1TB Volume 傳輸流量高達 94Gb

      圖、同步 1TB Volume 僅花費 95 秒

      簡單來說,在新一代 Windows Server 2019 (RS5)雲端作業系統中,針對儲存效能及傳輸速率的部分再度提升,與舊有 Windows Server 2016 (RS1)相較之下提升「2 ~ 3 倍」之多。

      圖、Windows Server 2016 (RS1) / 2019 (RS5) 儲存效能及傳輸速率比較表





      參考資源

      Viewing all 590 articles
      Browse latest View live


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