Horizon Cloud Pod - 維護和更新

本說明文件頁面說明在維護包含已部署Horizon Cloud網繭的軟體元件時，需要瞭解的重要事項。

簡介

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

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

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

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

若某個網繭未在主控台中指定偏好的維護時段，則表示Horizon Cloud團隊可以在方便時隨時排程該網繭的維護。

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

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

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

當已部署網繭中使用的軟體元件更新至新版本時，網繭的資訊清單號碼會增加至較高的版本號碼，例如 2632.0。如果有對網繭可維護性和支援作業來說很重要的改進，我們可以建立屬於點版本的新資訊清單，例如 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 位址只有 Microsoft Azure 上的 Horizon Cloud 所建立和設定的項目才能取得

  • 管理子網路 - 只有在網繭部署工具建立及設定Microsoft Azure 部署的特定 NIC 上，Horizon Cloud應使用網繭管理子網路中的 IP 位址。這些 NIC 是網繭管理員的 NIC 以及網繭的 Unified Access Gateway 執行個體的 NIC。網繭的管理子網路不得附加任何非網繭部署的資源或項目，也不能從中取得 IP 位址。
  • 租用戶子網路 - 只有在網繭部署工具建立及設定Microsoft Azure 部署的特定 NIC 和負載平衡器上的Horizon Cloud，才應使用網繭租用戶子網路中的 IP 位址。網繭的租用戶子網路不得附加任何非部署資源或項目，也不能從中取得 IP 位址。 《部署指南》明確指出，除了網繭部署的資源之外，網繭使用的子網路不應附加任何其他資源。如果您已手動建立資源，並將網繭的管理或租用戶子網路中的 IP 位址指派給這類其他資源，則在執行網繭更新之前，必須將這些 IP 位址從這些資源中移除。否則，網繭更新將會失敗，而需要Horizon Cloud支援。

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

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

關於網繭維護的須知事項

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

• 我們 （Omnissa） 在變更管理程序方面的角色和責任，以維護下載至網繭的軟體元件的健全狀況。維護活動包括更新網繭的軟體元件。
• 客戶（您）在變更管理程式方面的角色和責任，包括在需要定期或緊急維護時與我們合作。

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

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

指定網繭偏好的維護時段

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

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

注： 若某個網繭未在主控台中指定偏好的維護時段，表示您允許我們在方便時隨時排程該網繭的維護作業。

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

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

維護警示和通知

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

• 在主控台內

  • 位於主控台頂端的持續性橫幅。橫幅中的時間為維護時間，即您檢視主控台時以瀏覽器時區為準的當地時間。下列螢幕擷取畫面是一個範例：網繭的更新排程為在美國東部時間 2020 年 7 月 7 日下午 4 點執行。使用 檢視 按鈕點選進入網繭的詳細資料頁面，並在網繭的 維護 索引標籤上查看有關排程維護的詳細資訊。

    

  • 在網繭的 稽核記錄 索引標籤和主控台 的活動>稽 核 記錄中，稽核記錄會指出 作業已排程網繭的升級。稽核記錄行將包含網繭的 UUID。

  • 在網繭的 維護 索引標籤上， 排程的維護 區段會顯示排程維護的相關資訊。

• 電子郵件

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

注： 如果您想要重新排程已排程的維護日期和時間，必須連絡Horizon Cloud支援。

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

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

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

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

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

網繭更新 — 高階概觀

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

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

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

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

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

維護活動順序

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

1. 系統會檢查您在主控台中指定的網繭偏好的維護時段，並在其排程器演算法中使用該項資訊，以排程網繭維護活動的實際日期和時間。
2. 系統的排程器會選擇要進行維護的實際日期和時間。如以上幾節中所述，主控台會以視覺方式顯示排程的日期和時間，且會向租用戶管理員傳送電子郵件。
3. 重要： 執行排定的維護之前：

• 確定網繭的映像虛擬機器、伺服器陣列虛擬機器和 VDI 桌面虛擬機器皆具有可供網繭使用的最新代理程式。如果您在主控台中看見任何藍點，則應在進行網繭更新之前使所有藍點從主控台中消失。請參閱 Horizon Cloud網繭更新 — 延續代理程式相容性和支援的步驟

• 移除 Microsoft Azure 中您可能已在任何網繭的虛擬機器 （VM） 上設定的任何管理鎖定。任何名稱中包含字串 （例如 hcs-podID） （其中 podID 是網繭的識別碼值） 的虛擬機器即屬於網繭。Microsoft Azure 提供了使用 Microsoft Azure 入口網站鎖定資源以防止對其進行變更的功能。此類管理鎖定可套用於整個資源群組或個別資源上。如果您或您的組織已在網繭的虛擬機器上套用管理鎖定，則執行更新前必須先移除這些鎖定。否則，更新程序將無法成功完成。您可以在 [容量] 頁面的網繭詳細資料頁面中找到網繭的 ID 值。 若組織有需要，您可以在排程的維護時間之前隨時連絡Horizon Cloud支援，以要求不同的排程維護日期。

  重要： 顯示在主控台中的排程時間即為瀏覽器時區的當地時間。

4. 在排定的維護時段內，服務會啟動更新活動。對於同時具有外部和內部 Unified Access Gateway 組態的網繭，整個程序從開始到完成通常需要 20 到 30 分鐘。

   注： 在完成該程序的 20 到 30 分鐘期間，主控台會阻止您對正在更新的網繭執行管理工作。例如，在網繭管理員應用裝置通知雲端平面更新完成之前，您無法按一下網繭詳細資料頁面中的 編輯 動作來變更該網繭的特性。

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

     為了讓使用者工作階段在整個維護活動時間內能達成接近零的停機時間，系統會使用應用裝置上的使用者工作階段計數，來判斷完成這些應用裝置更新的最佳時間。

     完成時間已經過最佳化，當只有少數使用者連線到具有作用中工作階段的環境時發生。

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

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

     此外，在這個接近零的時段內，如果使用者尚未建立工作階段，以從網繭連線至其虛擬桌面或遠端應用程式，當其嘗試連線時，則將無法連線，必須等該程序完成為止。

5. 維護活動完成後，系統會刪除不再需要的元件 （例如，綠色組建中未重複使用的藍色元件），例如網繭管理員虛擬機器和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 憑證中所述，例如將 Access Connector 應用裝置與 Microsoft Azure 中的 Horizon Cloud 網繭整合時。 以便該連接器可以信任與網繭管理員虛擬機器的連線。在網繭資訊清單 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伺服器探索可能會開始失敗，並且失敗的探索將會影響對該網繭的使用者桌面連線要求。