Citrix Workspace和Gateway 服務共同為 Citrix DaaS 資源提供了方便、安全的遠程訪問解決方案。它們通過 Citrix Cloud 作為服務交付!客戶不必維護訪問層基礎設施,部署時間被壓縮,具有固有的多數據中心彈性,等等。
聽起來不錯。你只需輕按一下開關就可以開始了,對吧?大多數情況下是的,但在你按下開關之前,你應該考慮一些事情。
在這篇博文中,我將介紹有關部署 Citrix Cloud 託管訪問層的一些關鍵設計注意事項。有關設計注意事項的完整列表,請查看我們的Citrix Workspace和Gateway 服務產品文檔。
某些用例具有需要 Citrix Workspace(或 StoreFront)的依賴項。例如,加入 Azure AD 的 VDA 和未加入域的 VDA需要工作區和網關服務,適用於 Windows 365 的 HDX Plus 也是如此。但是,Workspace 不支持來自使用 XenApp Services(以前稱為 PNAgent)URL 或高級網頁修改的舊客戶端的連接。在這種情況下,您需要 StoreFront。
除了確定 Workspace 還是 StoreFront 最適合您之外,您還必須針對每個用例確定服務連續性是否足以作為彈性功能(允許使用 Workspace)或是否需要本地主機緩存(LHC)(這需要 StoreFront ). 出於這篇博文的目的,我假設讀者熟悉這兩個功能。
雖然服務連續性不需要客戶管理的 StoreFront 服務器,但需要牢記幾個設計注意事項。我在下面總結了它們,但請查看我們的產品文檔以獲取完整列表。首先,讓我們看看目前不支持的場景:
此外,在中斷期間不支持以下功能:
最後,應牢記以下注意事項:
查看您的要求並確定服務連續性是否適合您。如果您需要 LHC 和/或受上述影響,請注意 Gateway 服務不支持 LHC,您需要部署客戶管理的 StoreFront 和 Gateway。確保仔細收集您的要求並進行相應的設計。請記住,您始終可以同時部署 Citrix Cloud 託管的訪問層和客戶管理的訪問層!
使用網關服務時,默認會話啟動行為是將 HDX/ICA 流量從端點設備路由到 Cloud Connector,再到 VDA。但正如您可能懷疑的那樣,這是一個瓶頸並且無法很好地擴展。
為了消除對通過 Cloud Connector 進行路由的依賴,Citrix 創建了 Rendezvous 協議v1和v2。雖然 Citrix 諮詢建議使用 Rendezvous 協議來簡化啟動過程並減少 Cloud Connector 上的負載,但客戶還應考慮他們使用的防火牆、代理服務器和任何數據包檢測設備。
對於這兩個 Rendezvous 版本,所有 VDA 都必須能夠與必要的 Citrix Cloud URL 進行通信。某些注重安全的客戶可能需要為每個 VDA 設置單獨的防火牆規則例外,這不能很好地擴展。其他客戶可能只是更喜歡為少數 Cloud Connector 而不是 VDA 輕鬆管理防火牆規則。無論如何,不要忽視這些操作注意事項。此外,請注意網關服務不支持數據包解密/檢查,必須創建例外才能正常運行。
第二個考慮與 Zscaler Private Access(或類似解決方案)有關。如果正在使用,我們建議繞過網關服務所需的 URL,以避免增加會話延遲和相應的性能影響。
直接工作負載連接(DWC) 允許內部用戶繞過網關服務並直接連接到 VDA,從而減少延遲。雖然這有其好處,但客戶必須首先確定其內部用戶將連接的網絡的公共 IP 範圍,例如他們的辦公室或分支機構位置。Citrix Cloud 然後使用這些範圍來確定啟動是內部啟動還是外部啟動。
對於地點數量有限的小客戶來說,這似乎不是一個大問題。但對於可能擁有數百個辦事處的大型跨國客戶而言,這可能是一項艱鉅的任務。不要忘記,如果客戶使用防火牆分隔內部網段,則可能還需要更新防火牆規則(請參閱設計注意事項#2)。
一個相關的考慮是確保公司和訪客 Wi-Fi 網絡具有單獨的公共 IP 地址。由於此功能假定用戶具有通向 VDA 的直接網絡路徑,因此對這些網絡使用相同的共享公共 IP 地址將導致 Citrix Cloud 錯誤地假定來賓 Wi-Fi 上的用戶具有通向 VDA 的直接網絡路徑,從而導致發射失敗。
最後一個考慮因素:啟用服務連續性後,DWC 在中斷期間不可用。相應地計劃!
網關服務使用端點設備的 DNS 服務器來確定最近的網關服務接入點 (PoP)。雖然這通常運行良好,但在某些情況下,端點設備被配置為使用遠程 DNS 服務器。例如,離岸客戶端可能配置為使用北美的 DNS 服務器,因為它們使用的是北美公司提供的設備。網關服務通過互聯網將離岸用戶路由到北美 PoP,增加了會話延遲。
客戶應盡可能檢查其端點設備 DNS 配置,並在排除會話延遲時將其考慮在內。使用 VPN 等技術也可能導致路由到意外的 PoP。我們在 Ferroque Systems 的朋友有一篇很棒的博客文章涵蓋了這個問題。
使用網關服務優化音頻流量的最佳方法是使用各自供應商的優化技術(我們在此處和此處介紹)。優化音頻/視頻流量後,Citrix DaaS 會在端點上呈現內容並直接從端點發送相關流量,而不是通過 HDX/ICA 會話來提高性能。
當無法進行這種優化並且必須通過 HDX/ICA 會話發送音頻時,客戶管理的訪問層可能會使用諸如 Audio over UDP 之類的策略來分離音頻流量並確定其優先級,以提高性能。但是,網關服務不支持 UDP 上的音頻。那麼,我們應該怎麼做呢?
首先,使用自適應音頻(默認啟用,需要 Citrix Workspace 應用程序/VDA 2109+),動態調整音頻策略設置並替換舊的音頻壓縮格式以優化用戶體驗。
您應該做的下一件事是使用Enlightened Data Transport (EDT)(Citrix 專有的基於 UDP 的協議)進行測試,以交付整個 HDX/ICA 會話,這可以提供改進的性能。請注意,此功能僅在使用 Rendezvous 協議時可用(請參閱設計注意事項 #2),並且由於操作系統 MTU 限制,僅建議在 Windows 10+ 和 Windows Server 2019+ 上使用此功能。
最後,如果在沒有 Rendezvous 的情況下使用網關服務,由於未優化的音頻流量導致帶寬利用率顯著增加,可能會極大地影響 Cloud Connector 的可擴展性,需要更多 Cloud Connector 才能代理所有會話。
最終,未優化的音頻流量只能作為最後的手段使用。不用說,在大規模部署之前,所有音頻解決方案都應該經過全面測試。
許多客戶目前使用應用程序交付管理 (ADM) 或 ADM 服務與客戶管理的 NetScaler 來收集 HDX Insight 數據,使他們能夠解決用戶延遲問題。網關服務不與 ADM 服務集成,但 Citrix Analytics for Performance 提供以下網關服務指標:連接器名稱、PoP 和連接器性能信息。這些網關服務指標與 Citrix Analytics for Performance 的端點網絡指標(帶寬、往返時間、延遲和 Wi-Fi 信號強度)配合使用時,可以幫助對網絡延遲源進行故障排除。如果客戶絕對需要 HDX Insight 數據,您可以將 ADM 服務與 Citrix Analytics for Performance 集成。請注意,Citrix Analytics for Performance 單獨出售。
在建議從客戶管理的 NetScaler 遷移到 Gateway 服務之前,請權衡此操作考慮因素。對於某些客戶而言,在 ADM 服務和 Citrix Analytics for Performance 中訪問 NetScaler 提供的 HDX Insight 數據比從 Citrix Cloud 管理的訪問層獲得的收益更重要。
Citrix Cloud 託管的訪問層可以通過消除維護訪問層基礎設施的需要來簡化部署,提供固有的多數據中心彈性,並實現更快的部署。您只需要確保您考慮周全 - 或者聘請 Citrix 諮詢服務的聰明人為您做這件事。
文章來源/ Citrix Blog
返回