Horizon Cloud Pod - 維護和更新

本說明文件頁面說明一些當您在維護包含已部署 Horizon Cloud Pod 的 VMware 軟體元件時，需要瞭解的重要事項。

簡介

系統的維護活動，包括自動更新網繭的軟體元件以納入新功能、修正和改善服務的可支援性與恢復能力。

為了在接近零停機時間情況下，完成網繭和閘道應用裝置的更新，系統會使用使用者工作階段計數。當只有少數使用者連線至具有作用中工作階段的環境時，系統會使用工作階段計數，來判斷完成更新的最佳時間。

將現有網繭更新為較新資訊清單的維護活動會從雲端平面的系統起始，以在系統決定的日期和時間執行。

若要具體指出您想要讓任何此類系統維護活動應在星期幾的幾點鐘開始執行，則可以使用主控台來指定每個網繭偏好的維護時段。

若某個網繭未在主控台中指定偏好的維護時段，表示 VMware 可將該網繭的維護排程於任何便於執行的時間。

備註：如本說明文件頁面中所述，從 2022 日曆年年初開始，本服務增強了升級代碼，以便能以程式設計方式使用 VMware 在 Azure Marketplace 中提供的 VMware 產品。當升級預先檢查確定訂閱中禁止以程式設計方式使用這些 VMware 產品時，您必須完成該說明文件頁面中所描述的動作，以解決升級遭到封鎖的錯誤。

例如，如果與用於網繭及其閘道組態的訂閱相關聯的 Horizon Cloud 服務主體使用自訂角色 (非典型)，請確定該自訂角色包含這兩項權限。增強的升級 API 代碼必須具有這些權限，才能從 Marketplace 擷取產品清單並取得 VMware 產品。如果自訂角色尚未包含這兩項權限，請先為該自訂角色新增這兩項權限，之後再進行網繭和閘道升級程序。

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

當已部署網繭中使用的軟體元件更新為新版本時，網繭的資訊清單號碼會增加至較高的版本號碼，例如 2632.0。如果有對網繭可維護性和支援作業來說很重要的改進，VMware 可能會建立屬於點版本的新資訊清單，例如 2632.1。主控台會在 [容量] 頁面上顯示網繭的資訊清單。

從低於 3328 的資訊清單來更新網繭時的重要相關資訊

從 2022 年 2 月開始，網繭管理員虛擬機器的 NIC 遵循與 Unified Access Gateway 虛擬機器 NIC 相同的基礎結構設計模式。

在自此以後的新網繭部署中，以及當從低於 3328 的資訊清單進行網繭更新時，部署工具會將支援執行網繭以及後續更新所需的所有必要網路具現化。網繭的資源群組現在將擁有 8 個 NIC：

4 個 NIC，會保留網繭管理子網路中的 4 個 IP 位址
4 個 NIC，會保留網繭主要虛擬機器子網路 (過去稱為租用戶子網路) 中的 4 個 IP 位址。

這 8 個網繭 NIC 將持續存在，並在網繭的生命週期內繼續保留指派給它們的 IP 位址。

此設計可實現更快、更具彈性的網繭更新。在此設計之前，網繭更新時，需要在綠色網繭組建過程中建立新的 NIC，並在更新期間，從網繭子網路中取得這些 NIC 的 IP 位址。使用這種設計時，Azure 中可能會發生逾時並中斷更新程序。

在這種設計中，部署工具會預先將所有必要的網路具現化，且會保留管理子網路和虛擬機器 (租用戶) 子網路中的 NIC 及其 IP 位址，以便在後續網繭更新中使用。這種設計與用於 Unified Access Gateway 執行個體的模式一致。

如果網繭的資源群組中尚未具有 8 個 NIC，且該網繭是排定在資訊清單 3328 或更新版本才會更新，您必須執行這些動作。

更新該網繭之前，請確定網繭管理子網路的 IP 位址和主要虛擬機器 (租用戶) 子網路的 IP 位址只有 Horizon Cloud on Microsoft Azure 所建立及設定的項目才能取得

管理子網路 - 只有 Horizon Cloud on Microsoft Azure 部署中由網繭部署工具所建立及設定的特定 NIC，才應使用網繭管理子網路中的 IP 位址。這些 NIC 是網繭管理員的 NIC 以及網繭 Unified Access Gateway 執行個體的 NIC。網繭的管理子網路不得附加任何非網繭部署的資源或項目，也不能從中取得 IP 位址。
租用戶子網路 - 只有 Horizon Cloud on Microsoft Azure 部署中由網繭部署工具所建立及設定的特定 NIC 和負載平衡器，才應使用網繭租用戶子網路中的 IP 位址。網繭的租用戶子網路不得附加任何非部署資源或項目，也不能從中取得 IP 位址。

《部署指南》明確指出，除了網繭部署的資源之外，網繭使用的子網路不應附加任何其他資源。如果已手動建立資源，並將網繭的管理或租用戶子網路中的 IP 位址指派給這類其他資源，則在執行網繭更新之前，必須將這些 IP 位址從這些資源中移除。否則，網繭更新會失敗，而需要尋求「VMware 支援」。

更新網繭後，請確定已將網繭資源群組中部署工具所建立之 NIC 所保留的所有 IP 位址，新增到執行更新之前已實施的防火牆規則中

您可能已有一些現有的防火牆規則，來控管來自網繭管理員虛擬機器 NIC IP 位址的流量。在網繭更新後，為了使流量通訊能夠如更新前運作如常，您必須確定在更新後，網繭資源群組中 NIC 所保留的所有 8 個 IP 位址都會反映在防火牆規則中。

關於網繭維護的須知事項

維護包含已部署 Horizon Cloud Pod 的 VMware 軟體元件是必要的作業，以維護該網繭所佈建虛擬桌面和應用程式的健全狀況和穩定性。如 VMware Horizon Cloud Service - 其他服務詳細資料 (87894) 知識庫中所述，VMware 須負責維護位於網繭上以及從控制平面下載至網繭的軟體元件。本知識庫文章附帶的 VMware Horizon Cloud Service - 其他服務詳細資料 PDF 會說明：

VMware 在變更管理程序方面須承擔哪些角色和責任，以維護下載至網繭之軟體元件的健全狀況。維護活動包括更新網繭的軟體元件。
客戶 (您) 在變更管理程序方面的角色和責任，包括在需要排程或緊急維護時與 VMware 合作。

VMware Horizon Cloud Service - 其他服務詳細資料文件中會有一項定義指出排定的維護、維護時段和緊急維護。請參閱該文件以取得詳細資料。如果本說明文件頁面的內容與 VMware Horizon Cloud Service - 其他服務詳細資料文件的內容之間有任何差異，應以 VMware Horizon Cloud Service - 其他服務詳細資料文件為準。

小心：在更新網繭之前，您必須確定網繭的映像虛擬機器、伺服器陣列虛擬機器和 VDI 桌面虛擬機器皆具有可供網繭使用的最新代理程式。如果您未在網繭更新之前將其更新為最新的代理程式，則在網繭更新後，這些代理程式可能會執行不相容的代理程式版本，而使網繭進入不受支援的狀態。如何判斷是否需要更新任何代理程式？在主控台中，查看映像或指派旁邊是否有任何藍點。如果您看見任何藍點，則應在網繭更新之前使所有藍點從主控台中消失。請參閱 Horizon Cloud Pod 更新 — 延續代理程式相容性和支援的步驟。

指定網繭偏好的維護時段

若要具體指出您想要讓網繭上的任何維護活動在星期幾的幾點鐘開始執行，則可以使用主控台為該網繭指定所謂偏好的維護時段。從 [容量] 頁面導覽至網繭詳細資料頁面中的維護索引標籤。尋找偏好的維護時間標籤，然後依照畫面上的控制項選擇當日的工作日名稱和時間 (UTC)。您僅能從顯示的內容中選擇系統預先定義的預設值。

在主控台中，分別從每個網繭的詳細資料頁面指定各個網繭偏好的維護時間。

備註：若某個網繭未在主控台中指定偏好的維護時段，表示您允許 VMware 視方便將該網繭的維護排程於任何時間。

系統會讀取您在主控台中指定的工作日和時間，並將該資料納入其排程演算法中。當新的網繭資訊清單在雲端平面中設定為預設值時，系統的排程器將會依其判斷計算出可在您網繭機群中每個網繭上執行更新的實際更新日期和時間。雖然系統會盡可能採用在該網繭的維護索引標籤中指定偏好的維護開始時間，但並不保證系統一定能夠為特定的更新作業採用這個偏好的維護開始時間。

在撰寫本文件時，系統的排程器會為維護活動配置四 (4) 小時的持續時間。一般網繭更新所花費的時間少於此配置的持續時間。

維護警示和通知

當系統已排程特定日期和時間讓指定網繭的特定維護作業執行時，系統會發出警示並通知您租用戶環境的管理員。這些警示和通知包括下列內容：

在主控台內

位於主控台頂端的持續性橫幅。橫幅中的時間為維護時間，即您檢視主控台時以瀏覽器時區為準的當地時間。下列螢幕擷取畫面是一個範例：網繭的更新排程為在美國東部時間 2020 年 7 月 7 日下午 4 點執行。您可以使用檢視按鈕點選進入網繭的詳細資料頁面，並查看與網繭的維護索引標籤上的排程維護有關的詳細資訊。
在網繭的稽核記錄索引標籤和主控台的活動 > 稽核記錄中，稽核記錄會指出 VMware 營運團隊已排程網繭的升級作業。稽核記錄行將包含網繭的 UUID。
在網繭的維護索引標籤上，排程的維護區段會顯示排程維護的相關資訊。

電子郵件

系統會將網繭維護的相關電子郵件傳送給租用戶環境的管理員 — 此管理員指定於主控台的一般設定 > My VMware 帳戶設定中。其中包括系統已設定排程維護的特定日期和時間時所傳送的電子郵件。舉例來說，此類電子郵件包括在該排程的日期和時間之前的數天和數週傳送，以及在維護活動開始時和完成時傳送的定期提醒。

備註：如果您想要重新排程已排程的維護日期和時間，則必須連絡 VMware 支援。

執行網繭維護之前的系統預先檢查

如果您收到通知電子郵件，指出某個網繭發生網繭更新錯誤，或您看到主控台報告了網繭的網繭更新錯誤，則必須執行相關動作以修正該狀況。如果發生此狀況，請依照主控台畫面上的指引或電子郵件的指示操作。此類錯誤的解決方法，通常是透過 Microsoft Azure 入口網站在該網繭的訂閱中執行相關步驟。如需與常見網繭更新錯誤的補救措施有關的其他資訊，請參閱Horizon Cloud Pod — 修復常見預先檢查失敗。

這些預先檢查的目的為何？網繭更新的維護活動會在網繭的 Microsoft Azure 訂閱和資源群組中執行。在系統為指定網繭的特定更新排程特定日期和時間的前一刻，系統會執行預先檢查作業，以判斷是否存在任何會妨礙網繭成功更新的狀況。舉例來說，在其中的一項預先檢查中，系統會檢查您的 Microsoft Azure 訂閱是否有適當的虛擬機器系列和足夠的虛擬核心數以滿足更新的需求。如果其中一項預先檢查失敗，且您需要採取動作予以修正，則會發生下列情況：

系統會傳送通知電子郵件以針對這項事實向您發出警示，並詳細說明修正錯誤所需採取的動作。
主控台會顯示視覺警示，指出您必須執行相關動作以修正該網繭的預先檢查錯誤。

重要：如果您收到任何關於網繭升級錯誤的通知，請採取指定的動作以及時修復錯誤。請務必把握時間。若未能及時採取 VMware 要求的動作來解決這些錯誤，網繭將因為無法修復網繭更新程序而進入不受支援的狀態。

網繭更新 — 高階概觀

如果維護活動是將網繭更新為較新的資訊清單版本，則系統會將網繭目前的基礎結構元件適當地移至更高的軟體資訊清單層級。基礎結構元件主要是網繭管理員虛擬機器，以及任何針對網繭所設定的 Unified Access Gateway 虛擬機器。例如，一個網繭更新可能包括網繭管理軟體或 Unified Access Gateway 軟體的更新，或同時包含兩者的更新。

網繭更新程序會模仿稱為藍綠部署的軟體產業技術。現有要更新的網繭元件會被視為藍色元件。

雖然網繭更新在多數情況下會遵循業界的藍綠模式，但與正式藍綠更新仍有些許差異。在綠色組建中，網繭更新不會 100% 複製每個單一藍色資源。部分現有的藍色資源會重複使用於新的綠色組建中，例如將 NIC 用於 Unified Access Gateway 執行個體。另一項差異為，在網繭更新程序中，當較新的執行個體與現有的執行個體建立在一起時，較新的執行個體會開啟電源並保持執行，直到網繭徹底移轉到新的執行個體為止。此外，在系統將網繭移轉至綠色組建，並驗證該網繭已成功執行於新的資訊清單版本之後，較舊的藍色虛擬機器將會從資源群組中刪除。(正式藍綠更新通常會在切換至綠色組建後保留較舊的藍色構件，讓較舊的構件保持閒置狀態。)

要更新的現有網繭元件 (例如，網繭管理員虛擬機器和 Unified Access Gateway 虛擬機器) 會被視為藍色元件。
服務會自動為 Microsoft Azure 訂閱中的網繭建置必要的一組綠色元件 — 新的綠色網繭管理員虛擬機器、Unified Access Gateway 虛擬機器，以及閘道連接器虛擬機器 (如果您的外部閘道部署在其本身的 VNet 上)。
在綠色組建中新建立的元件，會與藍色元件一起建立於相同的資源群組中。
在建立綠色組建的過程中並不會導致任何停機時間或資料遺失，且並行虛擬機器並不會影響到網繭的作業。
綠色集為準備就緒的並行環境，等待排程的維護活動將藍色切換為綠色。系統在網繭上排程維護活動的方式如前幾節中所述。
這些綠色虛擬機器在啟動後會持續執行，直到將藍色移轉至綠色的排程維護活動完成為止。
移轉至綠色組建的排程維護活動完成，且網繭成功執行於新的執行個體之後，系統即會從網繭的資源群組中刪除藍色虛擬機器。某些資源 (如 Unified Access Gateway 執行個體的 NIC) 會持續保留下一次網繭更新時所需的組態值。

備註：您必須避免在 Microsoft Azure 入口網站和網繭的訂閱中，進行會對系統綠色元件組建或系統網繭更新和維護程序造成影響的變更。

維護活動順序

此順序說明移轉至綠色組建的程序 — 在網繭更新中從藍色切換為綠色。

系統會檢查您在主控台中指定的網繭偏好的維護時段，並在其排程器演算法中使用該項資訊，以排程網繭維護活動的實際日期和時間。
系統的排程器會選擇執行維護的實際日期和時間。如以上幾節中所述，主控台會以視覺方式顯示排程的日期和時間，且會向租用戶管理員傳送電子郵件。
重要：執行排程的維護之前：
- 必須確定網繭的映像虛擬機器、伺服器陣列虛擬機器和 VDI 桌面虛擬機器皆具有可供網繭使用的最新代理程式。如果您在主控台中看見任何藍點，則應在執行網繭更新之前使所有藍點從主控台中消失。請參閱Horizon Cloud Pod 更新 — 延續代理程式相容性和支援的步驟
- 移除 Microsoft Azure 中您可能已在任何網繭的虛擬機器 (VM) 上設定的任何管理鎖定。任何虛擬機器只要名稱中包含類似於 vmw-hcs-podID 的部分，(其中，podID 是網繭識別碼值)，即屬於網繭。Microsoft Azure 可讓使用者透過 Microsoft Azure 入口網站鎖定資源，以防止資源遭到變更。這樣的管理鎖定可套用於整個資源群組或個別資源上。如果您或您的組織已在網繭的虛擬機器上套用管理鎖定，則在執行更新前必須先移除這些鎖定。否則，更新程序將無法成功完成。您可以在 [容量] 頁面中，從網繭的詳細資料頁面找出網繭的識別碼值。
若組織有需要，您可以在排程的維護時間之前隨時連絡 VMware 支援，以要求不同的排程維護日期。

重要：顯示於主控台中的排程時間即為瀏覽器時區的當地時間。
在排定的維護時段內，服務會啟動更新活動。對於同時具有外部和內部 Unified Access Gateway 組態的網繭，整個程序從開始到完成，通常需要 20 到 30 分鐘。
備註：在完成這項程序的 20 到 30 分鐘期間，主控台會阻止您對正在更新的網繭執行管理工作。例如，在網繭管理員應用裝置通知雲端平面更新完成之前，您無法按一下網繭詳細資料頁面中的編輯動作來變更該網繭的特性。

關於 Unified Access Gateway 應用裝置上的使用者工作階段和更新活動

在整個維護活動時間內，為了讓使用者工作階段能達成接近零的停機時間，系統會使用應用裝置上的使用者工作階段計數，來判斷完成這些應用裝置更新的最佳時間。
完成時間已最佳化，而會選在只有少數使用者連線至具有作用中工作階段的環境時達成。

在這種接近零的時段內，具有作用中工作階段的使用者會中斷這些工作階段的連線。而在幾分鐘後，這些使用者就可以重新連線。

除非在伺服器陣列和 VDI 桌面指派中，針對逾時處理設定了立即選項，否則，資料並不會遺失。在該案例中，如果在使用者的作用中工作階段中，針對逾時處理使用立即選項，則根據該項設定，會立即中斷該使用者的連線，且會立即登出這些工作階段。在這種情況下，任何進行中的使用者工作都會遺失。為了避免進行中的使用者資料在此案例下遺失，在維護活動開始之前，請將伺服器陣列和 VDI 桌面指派中的登出已中斷連線的工作階段設定調整為適當值，讓那些使用者有時間可儲存其工作。然後，在更新完成後，您可以將該設定變更回原有的值。

此外，在這個接近零的時段內，如果使用者尚未建立工作階段，以從網繭連線至其虛擬桌面或遠端應用程式，當其嘗試連線時，則將無法連線，必須等該程序完成才行。
維護活動完成後，系統會刪除不再需要的元件 (例如：綠色組建中未重複使用的藍色元件)，例如：網繭管理員虛擬機器和 Unified Access Gateway 虛擬機器。某些構件 (例如：網繭管理員執行個體和 Unified Access Gateway 執行個體的特定 NIC) 會持續保留下一次維護時所需的組態值。

維護活動之後

維護活動完成後，您可以在網繭上執行管理工作。若要檢視網繭目前執行的軟體版本，請選取設定 > 容量，然後按一下該網繭以開啟其摘要頁面。頁面會顯示目前執行中的軟體版本。

在網繭更新後，請確定所有現有的映像、伺服器陣列和 VDI 指派中的代理程式皆已更新為最新的可用版本。如果這些虛擬機器安裝的代理程式未更新，網繭將會採用不受支援的組態。維護程序不會自動更新這些已安裝的代理程式。如果您在主控台中看到映像或指派有任何藍點，表示代理程式需要更新。Horizon Cloud Pod 更新 — 延續代理程式相容性和支援的步驟。
如果從 3328 之前的資訊清單進行這項更新，請在更新網繭後，確定已將網繭資源群組中部署工具所建立之 NIC 的所有 IP 位址新增到防火牆規則中。您可能已有一些現有的防火牆規則，來控管來自網繭管理員虛擬機器 NIC IP 位址的流量。在這項網繭更新和後續的更新之後，為了使流量通訊能夠如這項更新前運作如常，您必須確保在這項更新後，網繭資源群組中 NIC 所保留的所有 8 個 IP 位址都會反映在防火牆規則中。
如果您設定的雙因素驗證伺服器部署在相同的 VNet 中，則在維護活動之後，您必須更新雙因素驗證伺服器上的設定，以針對新的內部 Unified Access Gateway 虛擬機器接受新的私人 IP 位址。只有在首次更新時才需要在網繭上進行一次，網繭後續進行更新時就不需要再重複進行。請參閱使用必要的閘道資訊來更新雙因素驗證系統。
從 2019 年 9 月的季度服務版本開始，網繭架構已進行更新，可支援具有高可用性 (HA) 的功能。即使未啟用高可用性功能，支援 HA 的新架構仍包含位於網繭管理員虛擬機器前方的 Microsoft Azure 負載平衡器。將網繭更新為資訊清單 1600 後，如果您的網繭設定為直接連線，您應重新對應 DNS 設定，以指向將在已更新網繭之詳細資料頁面中顯示的網繭管理員 Azure 負載平衡器 IP 位址。更新 DNS 對應之前，即使那些直接使用者連線仍可正常運作，如果作用中網繭管理員虛擬機器關閉，則那些連線將不會具備已啟用 HA 的網繭設計所要提供的高可用性容錯移轉。在此使用案例中，您可以將 FQDN 對應到在網繭詳細資料頁面上顯示於網繭管理員負載平衡器 IP 欄位中的 IP 位址，如在網繭管理員虛擬機器上直接設定 SSL 憑證，例如將 Workspace ONE Access Connector 應用裝置與 Microsoft Azure 中的 Horizon Cloud Pod 整合時，讓連接器可以信任與網繭管理員虛擬機器的連線中所述。在網繭資訊清單 1600 之前，該 IP 是指派給租用戶子網路上網繭管理員虛擬機器 NIC 的 IP。從網繭資訊清單 1600 或更新版本開始，要對應的網繭 IP 位址應為用於網繭管理員虛擬機器之 Microsoft Azure 負載平衡器的私人 IP 位址。對於已更新為此版本的資訊清單版本的現有網繭，如果您已設定 DNS 名稱以指向資訊清單 1493.1 或更早版本的租用戶應用裝置 IP 位址，則應重新對應 DNS 設定，以指向在已更新網繭之詳細資料頁面中針對網繭管理員負載平衡器 IP 標籤顯示的 IP 位址。
在 2474.x 資訊清單之前，系統不會在已登錄的 Active Directory 伺服器中檢查時間誤差。在 2474.x 中，引入了時間誤差檢查。現在，如果您登錄的 Active Directory 伺服器在任何時間出現同步問題 (clockSkew > 4 minutes)，則在將網繭升級到 2474.x 或更新版本後，將在該網繭上開始執行此系統驗證。因此，在解決時間誤差問題之前，Active Directory 伺服器探索可能啟動失敗，並且失敗的探索將會影響使用者對該網繭的桌面連線要求。