ターミナルサーバーのリソース計算方法：実用的なサイズ決定方法

ターミナルサーバーの計算機は、文字通りの計算機であることはほとんどありません。ほとんどの中小企業（SMB）やマネージドサービスプロバイダー（MSP）の環境では、ユーザーが不満を言い始める前に、ターミナルサーバーが必要とするCPU、RAM、ストレージ、および余裕を見積もるために使用される計画手法です。キーワードの背後にある本当の質問は実用的です：ターミナルサーバーのリソースをどのように計算すれば、信頼を持って展開し、過剰支出を避けることができるのでしょうか。 パフォーマンスのボトルネックのリスクを軽減する ?

ターミナルサーバー計算機は実際に何を計算すべきですか？

有用なターミナルサーバー計算機は、「サーバーあたりのユーザー数」以上を見積もるべきです。管理者として、CPU、RAM、ストレージパフォーマンス、プロファイルストレージ、および現実的な同時使用における容量マージンを計画するのに役立つべきです。MicrosoftのRemote Desktopセッションホストに関するガイダンスは、ワークロードタイプとvCPUあたりの推奨ユーザー数に基づいてサイズを決定することを示しています。一般的な一律の接続制限に基づくものではありません。

ユーザー数だけではターミナルサーバーのリソースを計算するには不十分な理由は何ですか？

セッションの使用状況

同じ数のユーザーを持つ2つの環境が非常に異なる結果を生み出す可能性があることを考慮してください。あなたのインフラにアクセスするユーザーの数はすでに把握していると仮定していますので、持っていることが重要です。 ライセンスとCALを考慮した 実務作業を開始できます。

15人のユーザーが1つの業務アプリケーションを開くことでホストに軽い負荷がかかる様子を想像してみてください。一方で、15人のユーザーがブラウザ、Officeアプリケーション、PDFツール、印刷、バックグラウンド同期を使用してフルリモートデスクトップを実行すると、はるかに重い負荷がかかります。サイズモデルは、軽、中、重のマルチセッションワークロードを分けることでその違いを反映しています。

区別は重要です。なぜなら「30ユーザー」はそれ自体では容量の数値ではないからです。定義しない限り、意味を持ちません。 ユーザーが何をしているのか、何を使っているのか ピーク時に。

サーバーの使用状況

また、非常に重要な区別を覚えておいてください：ラボや小規模オフィスの場合、同時ユーザーセッションが少なくなるため、単一のサーバーを計画するかもしれませんが、生産環境の場合は、ファームを計画する可能性が高いです。実際、パフォーマンスを向上させ、トラブルシューティングを簡素化し、セキュリティを強化するためには、別々の役割が必要ですので、一般的な分割は次のようになります：

• ブローカー、ウェブ、ライセンス用の1台のサーバー
• 1台以上のサーバーをセッションホスト用に
• 1 RD Gatewayを外部アクセス用の独自サーバーで。

さらに一歩進むと、サーバーの種類、メモリなどが関係してくることがわかるでしょう。あなたはおそらく、欲しいと思うかもしれません。 大規模なセットアップにSSDを含める 例えば。これは可能性を認識させるための言及に過ぎません。

リソース計画を形成する4つの入力は何ですか？

次に、ハードウェアの数値を直接飛び越えるよりも信頼性の高い、カウントを開始する前に収集すべき4つの入力があります。この上流作業は、誰が接続できるか、そしてどのMicrosoftのルールの下で接続できるかに関するライセンスの質問との重複を避けます。ここでの中心的な懸念は、セッションホストが応答を維持するためにどれだけのリソースを必要とするかです。前回の記事では取り上げました。 ライセンスとサーバー容量 ここで、すべてを体系的に数える方法の実用性を開発し、正しく計画できるようにします。

したがって、合計する必要があります：

同時アクティブユーザー

この重要な数値を含める必要があります。なぜなら、並行して実行されるセッションの数がサーバーのパフォーマンスに確実に影響を与えるからです。なお、同時カウントは総カウントとは独立している場合があります。

ユーザーグループごとのワークロードクラス

ユーザーまたはユーザーのセットがどれだけリソースを消費するかを評価することは、最初の現実チェックです。特定のグループや個人は、実行するタスクによって必然的により多くを消費します。したがって、ヘビーユーザーを特定する必要があります。

アプリケーションとセッションの種類

特定のアプリケーションを特定することも非常に役立ちます。特定のユーザーは、実行するアプリケーションに応じて大量のリソースを独占するためです。

ピーク、成長およびフェイルオーバーマージン

この入力リストを最大使用量を考慮してまとめ、予想される短期的な成長の余地を残し、フェイルオーバーバッファマージンを組み込んでください。

ターミナルサーバーのリソースはどのように計算しますか？

中小企業の管理やその他の文脈で役立つことを願っている実用的な計算方法をここに示します。これは、少なくとも計画を簡素化し、準備を構造化することを目的としています。その後、パイロット期間以降も信頼できるように洗練させることができるはずです。

ステップ1: 同時ユーザーをカウントし、総ユーザー数ではありません

同時にアクティブなユーザーの数から始めます。これはサーバーの負荷を引き起こす数です。50人の名前付きユーザーを持つビジネスは、ピーク時に同時に接続されるのは18人から25人だけかもしれません。セッションホストのサイズを決定する際には、同時セッション数が総ユーザー数よりもはるかに有用です。

負荷の下で持続可能な実世界の容量をテストする前に、計画は見積もりに挑戦する必要があります。

ステップ2：ワークロードを軽、中、または重に分類する

次に、グループユーザーを作業負荷でソートします。マイクロソフトの 現在のセッションホストガイダンス マルチセッション環境のための以下の基本密度範囲を提案しており、HPや他の情報源も同意しています。

• vCPUあたり最大6人のライトユーザー
• vCPUあたり4人の中程度のユーザーと
• vCPUあたり2人の重度ユーザー、

それぞれ8 vCPU、16 GB RAM、32 GBストレージの最小VM例をこれらのワークロードバンドにわたって持つこと。推奨事項には、より良いキャパシティリターンのためにマルチセッションVMサイズをおおよそ4から24 vCPUの間に保つことも含まれています。

中小企業の計画のためのシンプルな作業負荷マップは、したがって、ソートのガイドとなるでしょう。

• ライト： 1つのビジネスアプリ、制限されたブラウザ使用、短いセッション
• 中程度: オフィスアプリ、ブラウザタブ、PDFツール、適度なマルチタスク
• 重い: ERP、大きなExcelファイル、ブラウザの常時使用、印刷、一日中複数のアプリを開く

これらは基本的な計画バンドであり、保証ではありません。目的は、作業負荷の動作に基づいた出発点を選ぶことです。

ステップ3：CPU容量の見積もり

ユーザーがグループ化されると、ユーザーあたりのvCPUアプローチでCPUを推定します。たとえば、24人の同時ユーザーが主に中程度のユーザーである場合、Microsoftの基準である約4ユーザーあたりのvCPUは、6 vCPUから始めることを示唆しており、その後、バーストの余裕を持たせた実用的なホストサイズに丸めます。短期的なCPU需要の急増時により良いバースト容量を提供したい場合は、通常よりも低いコアあたりのユーザー比率を計画してください。

明らかになったかもしれませんが、CPUのサイズ設定は数学的な最小値で止まるべきではありません。ログインのバースト、ウイルス対策の活動、レポート作成のジョブ、短期間の同時アプリケーション起動を考慮する必要があります。

ステップ4：RAM要件の見積もり

RAMは、オペレーティングシステム、コアサービス、セッションオーバーヘッド、およびユーザーごとのアプリケーションメモリ使用量のニーズを満たす必要があります。上記のように、現在のMicrosoftのマルチセッションベースラインは、8 vCPUの出発点に対して最低16 GBのRAMを必要とする軽量、中程度、重いワークロードの例を組み合わせています。これはあくまでベースラインに過ぎませんが、見積もりのための具体的な出発点を提供します。

中小企業での実用的な方法は次の通りです：

1. OSおよびプラットフォームサービスのためのメモリを予約します。
2. ユーザークラスごとのセッションごとのメモリ推定、
3. 同時セッションで乗算する、
4. その後、安全マージンを追加します。

PeteNetLiveは提供します 意図的に広範な経験則 ユーザーごとのRDセッションホストRAMプランニングのための2GBから8GBの範囲。このことは、正確な数値がテストで洗練されなければならない場合でも、重いセッションを過小評価しないための注意として役立ちます。

ステップ5: ストレージとプロファイルのオーバーヘッドを確認する

ストレージは、ターミナルサーバーの計画においてしばしば過小評価されます。遅い詰まったストレージは、CPUとRAMがまだ許容範囲に見える場合でも、ログオン、プロファイルの読み込み、一時ファイル、アプリケーションの起動、印刷スプーリングに悪影響を及ぼす可能性があります。

• プロファイルストレージ
• OSストレージ
• ログ：セキュリティやその他の目的のために

この最後のカテゴリは、インフラストラクチャのサイズや必要な監視および保護のタイプに応じて急速に膨張する可能性があるため、見積もる価値があります。

PeteNetLiveの役割ごとのプレゼンテーションは、セッションホストが通常リソースの圧力が最初に現れる場所であることを思い出させる有用なものであり、他のRDSの役割は比較的小さなフットプリントを持つことが多いです。これは、会社の使用推進能力の指標を探しているときに考慮してください。これは、計画のサイズを決定する際に役立ちます。

ステップ6：ピーク、成長、フェイルオーバーのための余裕を追加する

ターミナルサーバーの計算機は「必要十分」な数値で終わるべきではありません。余裕を持たせてください:

• 朝のサインインの急増
• パッチ適用とAVスキャン
• 月次報告のピーク
• 期待されるユーザーの成長
• マルチサーバーデザインにおけるホスト障害

最後に、単一ホストを超える環境に移行する際の良い運用アドバイスは、サーバーやハイパーバイザーの損失に備えて追加のホストを考慮に入れることです。

中小企業およびマネージドサービスプロバイダー向けのシンプルなターミナルサーバー計算機メソッド

この計算機のロジックは意図的にシンプルです。これは、最終的なベンチマークではなく、弁護可能な最初の見積もりを生成することを目的としており、それに応じて適応するためのものです。

迅速な計画の公式

このシーケンスを使用してください:

1. カウント 同時ユーザー .
2. それらを並べ替えます 軽、中、重 グループ。
3. 見積もり CPU vCPUあたりのユーザー比率を基準に使用しています。
4. 見積もり RAM OSオーバーヘッドとセッションごとの需要から。
5. チェック ストレージ プロファイル、テンポ、起動パフォーマンスのため。
6. 追加 20から30パーセントの余裕 その後、フェイルオーバーのニーズを確認します。

これは、一般的にサイズ設定がどのように構成されるかの本質を反映しています：最初に作業負荷、次に比率、観察後に洗練です。そして今、なぜ[の先行プレビューを取得しないのですか] それがどのような形を取ることができるか 正確な見積もりを取得し、潜在的なインフラをマッピングしますか？予算を計画する際の重要なツールです。

例1: 15人のライトオフィスユーザー

15人の同時ユーザーが公開されたビジネスアプリにアクセスし、軽いブラウザ使用を加えます。

推奨される軽量ベースラインを使用すると、生のCPU推定値は約3 vCPUです。実際には、バースト容量にはそれが厳しすぎるため、プランナーはエッジに構築するのではなく、より実用的なホストプロファイルにステップアップします。アドバイスは、8 vCPU、16 GB RAMをマルチセッションワークロードの標準ベースラインプロファイルとして、4から24 vCPUのより広いサイズ範囲を支持することがわかります。

RAMについては、OSとサービスのために容量を確保し、その後各ユーザーのセッションメモリを追加します。環境が安定していてアプリの使用が限られている場合、これは控えめなホストに快適に収まる可能性がありますが、パイロット使用中に検証する必要があります。

例2：30の混合オフィスおよびERPユーザー

仮定:

• 18人の中程度のユーザー
• 12人の重度ユーザー

計画のショートカットは、中程度のグループを約4ユーザー/ vCPU、重いグループを約2ユーザー/ vCPUとして扱います。これは、中程度のグループに約4.5 vCPU、重いグループに6 vCPUが必要であることを示唆しています。オーバーヘッドと余裕を考慮する前に、実際には、これは単一の軽量ホストから離れ、余裕のある大きなホストまたは複数のセッションホストに分割する方向を指し示しています。

サーバーリソースの計画をするというアドバイスが意味を持つ場所です。 With an ERP 企業の文脈においても、目標は単にユーザーをどこかに適合させることではありません。 ユーザーをどこかに収容することが目的ではありません。目的は、最も忙しい時間帯に応答時間を許容範囲内に保つことです。

ユーザーを複数のホストに分割するタイミング

計算が限られたバースト容量を持つ密なホストを生成すると、より良い答えは垂直スケーリングではなく、アーキテクチャ的なものである可能性があります。セッションホストは重い作業を行うように設定でき、RD接続ブローカー、ゲートウェイ、ライセンスなどの役割には異なるリソースプロファイルを与えることができます。複数のホストにユーザー負荷を分散させることで、レジリエンス、メンテナンスの柔軟性、フェイルオーバープランニングが改善される可能性があります。

MSPにとって、これはしばしばターミナルサーバー計算機が単一サーバーの議論ではなく、ファームサイズの議論になる転換点です。

一般的なサイズ設定の誤りは、通常、ターミナルサーバーのパフォーマンスをどのように損なうのか？

サイズの誤りは通常、数学だけが原因ではありません。誤った仮定から生じます。

ライセンスをパフォーマンス容量と混同する

ライセンスは、アクセスがどのように割り当てられ、構成されるかを示します。サーバーが許容可能なパフォーマンスでサポートできる同時ユーザー数については示しません。

ブラウザに負荷がかかるセッションや印刷に負荷がかかるセッションを無視する

多くの環境では、現代のブラウザの使用、PDFの処理、印刷がセッションホストにどれだけの負荷をかけるかを過小評価しています。これらの活動は、ビジネスアプリケーション自体が控えめであっても、ユーザーグループを軽負荷から中負荷、または中負荷から重負荷にシフトさせる可能性があります。

平均負荷のためのサイズ設定のみ

平均負荷は、ユーザーが不満を訴える瞬間ではほとんどありません。不満は、ログオンの嵐、同時ファイルオープン、レポート実行、または朝のピーク時に発生します。Microsoftは、ユーザーあたりのコア比が低い場合にバースト容量が重要であると指摘しており、最大密度を目指すのではなく、余裕を持たせることをサポートします。

RDSスタックの残りを忘れる

セッションホストは主なリソース消費者ですが、環境内の唯一の役割ではありません。PeteNetLiveの役割の内訳は、展開が小さな単一ホストのセットアップを超えるときに、接続ブローカー、ゲートウェイ、Webアクセス、およびライセンスを別々に考慮するための便利なリマインダーです。

なぜ監視があなたのサイズ見積もりを検証すべきなのか？

ターミナルサーバー計算機は、計画の基準を提供します。証明は提供しません。証明には、使用状況を監視する必要があります。

ベースラインから証明まで：必須としての監視

以前の記事では、持続可能なユーザーキャパシティが実用的な監視の問題である理由を説明しました。ここでは、展開前にそのキャパシティの最初のバージョンを推定する方法を示すことが目的です。監視は、私たちが言及した多くのカウントを取得します。想定されるニーズを評価するために、ラボ環境でテストすることをお勧めします。

TSplus Server Monitoringはどこで違いを生み出しますか？

TSplusサーバーモニタリング フィットします サイズ見積もりが展開された後、それがCPUの飽和、メモリの圧力、ストレージのボトルネック、または使用の急増が計画に使用された仮定と一致するかどうかを確認するのに役立ちます。これは、ホストのサイズ変更、ユーザーの再配分、または別のサーバーの追加を行う前に証拠が必要な中小企業のIT管理者やMSPにとって特に便利です。

リソースをプロジェクトする方法を知ることを超えて、監視システムを通じて計算が正しかったかどうかを知る方法は他に何がありますか？ Server Monitoringは、リアルタイムの監視と、マーカーが設定した閾値に達したときに通知を受けるためのアラートを提供します。 .

TSplusソフトウェアは、アプリケーションとデスクトップの安全な持続的配信のためのものです。

TSplus Remote Accessは、より広いストーリーの配信レイヤーとして位置づけられ、Advanced Securityはアプリケーションサーバーを保護するために特別に設計されています。さらに、TSplus Remote Supportは、これらのサーバーやその他のトラブルシューティングとメンテナンスのための必需品キットを、どこからでも提供します。環境が適切にサイズ設定されると、TSplus Remote Accessは、Citrixよりも簡単にデスクトップやアプリケーションを公開し、予算を超えることなく実現します。ウェブアクセスや集中配信などの機能をテストすることで、アドホックなRDPアクセスを超えて移行する方法を体験できます。

結論

ターミナルサーバーの計算機は魔法の答えを約束すべきではありません。今、ターミナルサーバーのリソースを段階的に計算する時です：同時ユーザーから始め、作業負荷の強度を分類し、現実的なセッションの動作からCPUとRAMを推定し、ストレージを確認し、ピーク、成長、フェイルオーバーのためのマージンを追加します。

システム管理者、SMB IT管理者、またはMSPとして、これは実用的な最初の見積もりを提供します。そこから、本当の課題は検証です。慎重に計画し、保守的に展開し、その後、監視データを使用してホストが確認されるかどうかを確認します。 ホストファーム ユーザーエクスペリエンスを維持できます。