目錄
Banner for article "How to Calculate Resources on a Terminal Server: A Practical Sizing Method" with article title, illustration, TSplus Server Monitoring logo and website URL.

終端伺服器計算器很少是字面上的計算器。在大多數中小企業和管理服務提供商環境中,它是一種規劃方法,用於估算終端伺服器在用戶開始抱怨之前需要多少 CPU、RAM、存儲和餘地。關鍵字背後的真正問題是實際的:如何足夠準確地計算終端伺服器上的資源,以便自信地部署,避免過度支出。 降低性能瓶頸的風險 ?

終端伺服器計算器應該計算什麼?

一個有用的終端伺服器計算器應該估算的不僅僅是“每個伺服器的用戶數”。作為管理員,它應該幫助您計劃 CPU、RAM、存儲性能、配置存儲和在現實的並發使用下的容量邊際。微軟對遠端桌面會話主機的指導圍繞工作負載類型和建議的每個 vCPU 用戶數進行大小調整,而不是圍繞通用的一刀切連接限制。

為什麼僅僅用用戶數量來計算終端伺服器上的資源是不夠的?

會話使用情況

請記住,兩個擁有相同用戶數的環境可能會產生非常不同的結果。我們假設您已經知道將有多少用戶訪問您的基礎設施,因此擁有 考慮授權和 CALs 實際工作可以開始。

想像一下,十五名用戶同時打開一個業務應用程序可能會對主機造成適度的負載。與此同時,十五名用戶運行完整的遠程桌面,使用瀏覽器、Office 應用程序、PDF 工具、打印和背景同步,則可能會產生更重的負載。尺寸模型通過將輕型、中型和重型多會話工作負載分開來反映這一差異。

區分很重要,因為「30個用戶」本身並不是一個容量數字。只有在你定義之後,它才有意義。 那些用戶做什麼和使用什麼 在高峰時期。

伺服器使用情況

同時記住一個重要的區別,這非常重要:對於實驗室或小型辦公室,您可能計劃一台單一伺服器,因為它將運行較少的同時用戶會話,而對於生產環境,您可能會計劃一個伺服器群。事實上,需要分開的角色來提高性能、簡化故障排除和加強安全性,因此常見的劃分是:

  • 1 台伺服器用於經紀人、網頁和授權
  • 1 台或多台伺服器作為會話主機
  • 1 RD Gateway 在其自己的伺服器上用於外部訪問。

為了更進一步,您還會發現伺服器類型、記憶體等因素將會發揮作用,您可能想要 在較大的設置中包含SSD 例如。這只是提及以讓您了解可能性。

哪四個輸入影響資源規劃?

接下來,比直接跳過硬體數字更可靠的是,在開始計算之前,這裡有四個輸入需要收集。這項上游工作避免了與有關誰可以連接以及根據哪些微軟規則的許可問題重疊。這裡的主要關注點是會話主機需要多少資源才能保持響應。我們之前的文章涵蓋了 授權和伺服器容量 因此,我們可以在這裡系統地發展計算一切的實用性,以便正確規劃。

因此,您需要總結:

同時活躍用戶

我們仍然需要包括這個重要的數字,因為並行運行的會話數量肯定會影響伺服器性能。請注意,並發計數可以獨立於總計數。

每個用戶組的工作負載類別

評估一個用戶或一組用戶將消耗多少資源是第一個現實檢查。某些群體或個人不可避免地會消耗更多他們執行的任務。因此,需要識別重度用戶。

應用程式和會話類型

這也非常有助於確定特定的應用程式,因為某些用戶會根據他們運行的應用程式佔用大量資源。

高峰、增長和故障轉移利潤

將此輸入列表整理完畢,考慮到最大使用量,留出預期短期增長的空間,並建立故障轉移緩衝邊際。

如何計算終端伺服器上的資源?

這裡有一個實用的計算方法,我們希望它能在中小企業管理以及其他情境中派上用場。它旨在至少簡化規劃和結構的準備工作。然後,它應該能夠進一步完善,以便您可以在試點期間及以後依賴它。

步驟 1:計算同時使用者,而非總使用者

從同時活躍的用戶數開始。這是驅動伺服器負載的數字。擁有50個指定用戶的企業在高峰時段可能只有18到25個用戶同時連接。在為會話主機進行規模設計時,同時會話數量比總人數更有用。

在負載下測試可持續的現實世界容量之前,規劃需要挑戰估算。

步驟 2:將工作負載分類為輕型、中型或重型

接下來,按工作負載對群組用戶進行排序。微軟的 當前會話主機指導 建議多會話環境的基線密度範圍,HP 和其他來源也一致認同:

  • 每個 vCPU 最多可支持 6 位輕量用戶,
  • 每個 vCPU 可支援 4 名中等用戶和
  • 每個 vCPU 2 位重度使用者,

具有分別為 8 vCPU、16 GB RAM、32 GB 存儲的最小虛擬機範例,涵蓋這些工作負載範疇。建議還包括將多會話虛擬機的大小保持在大約 4 到 24 vCPU 之間,以獲得更好的容量回報。

一個簡單的工作負載地圖用於中小企業規劃,將指導排序:

  • 光: 一個商業應用程式,有限的瀏覽器使用,短暫的會話
  • 中等: 辦公室應用程式、瀏覽器標籤、PDF 工具、適度的多任務處理
  • 重型: ERP, 更大的 Excel 檔案, 持續使用瀏覽器, 列印, 整天開啟多個應用程式

這些是基準規劃範疇,而非保證。其目的是選擇一個基於工作負載行為的起始點。

步驟 3:估算 CPU 容量

一旦用戶被分組,使用每個 vCPU 的用戶數方法來估算 CPU。例如,如果 24 名同時用戶大多是中等用戶,微軟的基準約為每個 vCPU 4 名用戶,建議從 6 個 vCPU 開始,然後四捨五入到具有突發冗餘的實際主機大小。如果您希望在短期 CPU 需求激增期間提供更好的突發容量,則計劃的每個核心用戶比率應低於您可能會考慮的比率。

如您所見,CPU 的大小不應僅停留在數學上的最低限度。它應考慮到登錄高峰、殺毒活動、報告任務以及短暫的同時應用啟動期間。

步驟 4:估算 RAM 需求

RAM 應該能滿足操作系統、核心服務、會話開銷和每位用戶的應用程序內存使用需求。如上所述,目前的 Microsoft 多會話基準將其輕型、中型和重型工作負載示例與最低 16 GB RAM 配對,作為 8 vCPU 的起始點。雖然這僅僅是一個基準,但它仍然為估算提供了一個具體的起始點。

在小型或中型企業中,一個實用的方法是:

  1. 為操作系統和平台服務保留內存,
  2. 按用戶類別估算每次會話的內存,
  3. 同時會話數量乘以
  4. 然後添加安全邊際。

PeteNetLive 提供了一個 故意寬泛的經驗法則 每位用戶的 RD 會話主機 RAM 規劃為 2 到 8 GB。這對於防止低估繁重會話非常有用,即使確切的數字必須在測試中進行調整。

步驟 5:檢查存儲和配置檔開銷

在終端伺服器規劃中,儲存經常被低估。緩慢的擁塞儲存可能會影響登錄、配置檔加載、臨時檔案、應用程式啟動和列印暫存,即使 CPU 和 RAM 看起來仍然可接受。

  • 個人資料儲存
  • 作業系統儲存
  • 日誌:用於安全和其他類似目的

這最後一類值得估算,因為它可能會迅速膨脹,具體取決於您的基礎設施的大小以及您所需的監控和保護類型。

PeteNetLive 的角色逐一介紹提醒我們,會話主機通常是資源壓力最先出現的地方,而其他 RDS 角色的影響通常相對較小。在尋找公司使用推動能力的指標時,請記住這一點,因為它可以幫助評估計劃的規模。

第 6 步:為高峰、增長和故障轉移留出餘地

沒有任何終端伺服器計算器應該以“剛好足夠”的數字結束。請增加餘地以便於:

  • 早晨登錄高峰
  • 修補和防病毒掃描
  • 每月報告高峰
  • 預期用戶增長
  • 多伺服器設計中的主機故障

最後,對於任何超越單一主機的環境,一些良好的操作建議是考慮額外的主機,以防伺服器或虛擬機監控程式損失。

簡單的終端伺服器計算器方法,適用於中小企業和管理服務提供商

這個計算器的邏輯故意簡單。它旨在產生一個可辯護的初步估算,而不是最終基準,並讓您根據需要進行調整。

快速規劃公式

使用此序列:

  1. 計數 同時使用者 .
  2. 將它們分類為 輕、中和重 群組。
  3. 估算 中央處理器 使用基準每個 vCPU 的用戶比率。
  4. 估算 隨機存取記憶體 從操作系統開銷加上每個會話的需求。
  5. 檢查 儲存 用於配置文件、臨時和啟動性能。
  6. 新增 20% 到 30% 的餘地 然後檢查故障轉移需求。

這反映了一般情況下如何框定大小的本質:首先是工作負載,其次是比例,觀察後再進行精煉。那麼,為什麼不提前預覽一下呢? 它可能會採取什麼形狀 ,獲得精確的估算並規劃您的潛在基礎設施?在預算規劃時的關鍵工具。

15 位輕量辦公室用戶

假設有 15 位同時使用者訪問一個已發布的商業應用程式,並輕度使用瀏覽器。

使用建議的輕量基準,原始 CPU 估算約為 3 vCPU。實際上,這對於突發容量來說太緊湊,因此規劃者會選擇更實用的主機配置,而不是建構到邊緣。您會發現建議偏向於更廣泛的 4 到 24 vCPU 尺寸範圍,8 vCPU 和 16 GB RAM 作為多會話工作負載的標準基準配置。

對於 RAM,為操作系統和服務保留容量,然後為每個用戶添加會話內存。如果環境穩定且應用程序使用範圍狹窄,這可以在一個適度的主機上舒適地運行,但仍應在試點使用期間進行驗證。

範例 2:30 名混合辦公室和 ERP 用戶

假設:

  • 18 中型用戶
  • 12 位重度使用者

一個規劃捷徑將中等組別視為每個 vCPU 約 4 名用戶,而重型組別則視為每個 vCPU 約 2 名用戶。這意味著中等組別大約需要 4.5 個 vCPU,重型組別則需要 6 個 vCPU,這還不包括開銷和餘地。在實際操作中,這已經指向不再使用單一輕型主機,而是朝向具有餘量的更大主機或分散在多個會話主機之間。

這就是「規劃伺服器資源」建議變得有意義的地方。 有一個 ERP 就像在任何企業環境中一樣,目標不僅僅是將用戶放在某個地方。 目標不僅僅是將用戶放置在某個地方。目標是在一天中最繁忙的時段內保持響應時間在可接受的範圍內。

範例 3:何時將用戶分配到多個主機上

一旦計算產生了具有有限突發容量的密集主機,更好的解決方案可能是架構性而非垂直擴展。會話主機可以設置為承擔重任,而像 RD 連接代理、網關和許可證等角色則可以分配不同的資源配置。將用戶負載分散到多個主機上可能會提高韌性、維護靈活性和故障轉移計劃。

對於MSP來說,這通常是終端伺服器計算器成為農場規模討論而不是單伺服器討論的轉折點。

哪些常見的大小錯誤通常會影響終端伺服器的性能?

尺寸錯誤通常不是僅由數學引起的。它們來自不正確的假設。

混淆授權與性能容量

授權告訴您如何分配和配置訪問。它不告訴您一個伺服器將支持多少個同時用戶以達到可接受的性能。

忽略瀏覽器負擔重和列印負擔重的會話

許多環境仍然低估了現代瀏覽器使用、PDF 處理和列印對會話主機所增加的負載。這些活動可以使一個用戶組從輕度轉變為中度,或從中度轉變為重度,即使業務應用程序本身是適度的。

僅針對平均負載進行大小調整

平均負載很少是用戶抱怨的時刻。抱怨通常發生在登錄高峰、同時打開文件、報告運行或早晨高峰期間。微軟指出,在較低的每核心用戶比率下,更好的突發容量變得重要,因為它支持留出空間而不是針對最大密度。

忘記其餘的 RDS 堆疊

會話主機是主要的資源消耗者,但它並不是環境中唯一的角色。PeteNetLive 的角色劃分是一個有用的提醒,當部署超過小型單主機設置時,應分別考慮連接代理、網關、網頁訪問和授權。

為什麼監控應該驗證您的尺寸估算?

終端伺服器計算器為您提供了一個規劃基準。它不提供證據。要獲得證據,您需要監控使用情況。

從基線到證明:監控作為一項必需品

在我們之前的文章中,我們解釋了為什麼可持續的用戶容量是一個實際的監控問題。在這裡,目標是展示如何在推出之前估算該容量的第一個版本。監控將為您獲得我們提到的許多計數。我們建議您在實驗室環境中進行測試,以評估您預期的需求。

TSplus 伺服器監控在哪裡有所不同?

TSplus 伺服器監控 合適 在大小估算部署後。它有助於驗證 CPU 飽和、內存壓力、存儲瓶頸或使用高峰是否符合規劃中使用的假設。這對於需要證據才能重新調整主機、重新分配用戶或添加另一台伺服器的中小企業 IT 管理員和管理服務提供商特別有用。

除了知道如何分配資源,還有什麼方法可以知道計算是否正確,除了通過監控系統?伺服器監控為您提供實時監控和警報,讓您在標記達到設定的閾值時保持知情。 .

TSplus 軟體用於安全持續交付應用程式和桌面

TSplus Remote Access 作為更廣泛故事中的交付層,而 Advanced Security 則是專門為保護應用伺服器而設計。此外,TSplus Remote Support 提供了一套基本工具,用於故障排除和維護這些伺服器及其他設備,無論身在何處。一旦環境正確配置,TSplus Remote Access 將比 Citrix 更簡單地發布桌面和應用程序,且不會超出預算。測試網頁訪問和集中交付等功能將讓您體驗如何超越臨時的 RDP 訪問。

結論

終端伺服器計算器不應該承諾一個神奇的答案。現在是時候分階段計算終端伺服器資源:從同時用戶開始,分類工作負載強度,根據現實的會話行為估算 CPU 和 RAM,檢查存儲,然後為高峰、增長和故障轉移添加邊際。

作為系統管理員、中小企業 IT 管理員或管理服務提供商,這將為您提供一個實際的初步估算。從那裡,真正的學科是驗證。仔細規劃,保守部署,然後使用監控數據來確認主機,或 主機農場 可以維持您所期望的用戶體驗。

TSplus 遠端存取免費試用

終極的 Citrix/RDS 替代方案,用於桌面/應用程式訪問。安全、具成本效益、內部部署/雲端

進一步閱讀

back to top of the page icon