• [アーティクル]

モビリティの容量計画

 

トピックの最終更新日: 2011-12-05

モビリティで必要とされる容量を決定するには、モビリティの使用率の見積もり、現在の容量の測定、追加容量の計画、および主なパフォーマンス指標の監視の一連の処理を反復します。以下の図は、容量計画に関連するフェーズ、および各フェーズに関連する要因を示しています

モビリティの容量計画ワークフロー

015701c0-77a2-4622-9c01-76576dea0140

このセクションでは、モビリティの使用率を見積もる場合に考慮する必要のある各要因について説明し、モビリティの展開に必要なサイズの決定に関するガイドラインを示します。

使用率およびパフォーマンス指標の監視の詳細については、以下を参照して下さい。

高パフォーマンスの Mobility Service を構成する方法の詳細については、「高いパフォーマンスを実現する Mobility Service の構成」を参照して下さい。

容量に影響する要因

Microsoft Lync Server 2010 Mobility Service を実行するフロントエンド サーバーの容量計画に影響を与える要因は 3 つあります。

  • ユーザー モデル

  • モバイル デバイスの特性

  • 使用可能な RAM

ユーザー モデル

このセクションで説明するユーザー モデルは、モビリティの容量計画の測定値および推奨事項の基礎となります。

ユーザーごとの平均連絡先数

連絡先のカテゴリ ユーザーごとの平均数

すべての連絡先

80

企業の連絡先

64

フェデレーションの連絡先

8

PIC 連絡先

6

配布グループ

2

最も頻繁に使用されている連絡先

15

最近使用されている連絡先

10

ユーザーごとの日常活動

日常活動 業務時間中における回数 業務時間外における回数

モバイル アプリケーションへのサインイン

10

2

電話での通話 (数)

10

2

電話での通話 (時間)

通話ごとに 2 分

通話ごとに 2 分

電話会議

週ごとに 1 回

0

電話会議ごとの参加者

<10

0

状態メモの変更

1

0

連絡先カードの表示

6

1

連絡先リストの表示

9

1

連絡先リストのスクロール

3

0

グローバル アドレス一覧 (GAL) の検索

5*

-

手動によるプレゼンス更新

0.5

0

連絡先ごとのプレゼンス更新の合計

6

0

着信転送

0.5

0

インスタント メッセージング (IM) セッション (数)

3

1

IM セッション (時間)

セッションごとに 6 分、30 秒ごとに 1 メッセージ

セッションごとに 6 分、30 秒ごとに 1 メッセージ

予定表の参照 (Exchange Web サービスへの接続)

11

3

* GAL 検索の数 = 日ごとに 1 回の手動検索 + 送信インスタント メッセージおよび通話の片側での自動検索。つまり、1 + 2 (インスタント メッセージ) + 2 (通話) = 5。

モバイル デバイスの特性

モビリティがサポートされるモバイル デバイスでは、さまざまなオペレーティング システムが実行されます。ユーザーが別のアプリケーションに切り替えるときにオペレーティング システムがアプリケーションを管理する方法は、容量計画に影響します。オペレーティング システムは、容量計画に関する以下の 2 つのカテゴリに分けられます。

  • バックグラウンド対応   ユーザーが Apple および Windows Phone モバイル デバイス上で別のモバイル アプリケーションに切り替えると、Lync 2010 モバイル アプリケーションはバックグラウンドに移動し、Lync Server 2010 への接続を失います。モバイル アプリケーションは、プッシュ通知によって再アクティブ化されるか、ユーザーがアプリケーションを手動でフォアグラウンドに移動したときに再アクティブ化されます。

  • 常時接続   ユーザーが Android および Nokia モバイル デバイス上で別のモバイル アプリケーションに切り替えても、ユーザーがサインインしている限り、Lync 2010 モバイル アプリケーションは Lync Server 2010 への接続を維持します。

Android および Nokia モバイル デバイスでは、ユーザーがモバイル アプリケーションを活発に使用しなくてもサーバーへの接続が維持されるため、サーバーの負荷が大きくなります。

使用可能なメモリ

このセクションの後で説明するサイジングのガイドラインは、モビリティで必要なメモリ容量を定義するのに役立ちます。サーバーで使用可能な物理メモリの容量を決定するには、[Memory, Available Mbytes] パフォーマンス カウンターを使用します。このパフォーマンス カウンターは、プロセスを実行するために使用できる物理メモリの容量をメガバイト単位で示します。プロセスを実行するために使用できるメモリの容量が合計物理メモリの 5% を下回る場合、サーバーのメモリが不十分な状態です。この状態では、ページングが増加する可能性があります。

サイジングのガイドライン

Mobility Service では、フロントエンド サーバーで追加のメモリ、プロセッサ リソース、およびネットワーク リソースが使用されます。容量を計画する場合、フロントエンド プールに対するモビリティの負荷の影響を把握し、モビリティの負荷に対して追加のハードウェアが必要かどうかを決定する必要があります。以下の表のサイジング例を使用して、追加のハードウェアが必要かどうかを決定したり、必要な追加のハードウェアの規模を決定したりするのに役立ててください。

表内の例は、いくつかの式と前提に基づきます。この式と前提では以下の定義が使用されます。

  • AC は、ユーザー モデル内で常時接続されたモバイル アプリケーションの数を表します。

  • BE は、ユーザー モデル内でバックグラウンドが有効にされたモバイル アプリケーションの数を表します。

式と前提は以下のとおりです。

  • メガバイト単位の目標メモリ (TM) = 164 + (AC * 534 + BE * 400) / 1024。

    TM は最低限必要なメモリです。

  • 前述のユーザー モデルでは、フロントエンド プールへの接続数は、AC * 2 + BE * .20 です。

  • サーバーでメモリ不足がない場合、測定されるメモリは大きくなる (エンドポイントごとに最大で 1 MB) 場合があります。また、より多くの音声/ビデオ (A/V) 通話または連絡先がある場合など、積極的なユーザー モデルの場合は、目標メモリが大きくなる可能性があります。

  • 1 秒間に作成される接続数は、1,000 ユーザーにつき 30/秒以下です。この数は、ロード バランサー機器での接続プーリング設定、およびキープアライブ設定に依存します。

以下の表に、ユーザー モデル内に 50% の常時接続ユーザーがいる場合のサイジング例を示します。

サイジング例

ユーザー数 メモリ (MB) 平均 CPU 最大 CPU

1,000

620.05

1%

2.5%

2,000

1076.11

6%

8%

3,000

1532.16

14%

18%

4,000

1988.22

14%

18%

5,000

2444.27

14%

18%

シナリオ例

以下の例は、架空の大規模企業および 2 台のサーバーを含むフロントエンド プールに対してサイジング ガイドラインをどのように適用するかを示しています。

大規模企業

Contoso は、75,000 ユーザーを 3 つのプールにわたって展開しており、各プールには 4 つのフロントエンド サーバーがあります。Contoso は、30,000 ユーザーに対してモビリティ サービスを有効にすることを計画しています。

計画フェーズで、Contoso の管理者は以下のデータを取得しました。

  • 各フロントエンド サーバーに 3 GB の使用可能メモリがある。

  • CPU 使用率が 60% 未満である。

  • すべてのユーザーが iPhone または Windows Phone モバイル デバイスを持っている。

  • Contoso のユーザー モデルは、前述の容量計画ユーザー モデルに似ている。

各サーバーで最低限必要なメモリは、164 + 2500 * 400 / 1024 = 1133 MB です。使用可能なメモリがある場合、より多くのメモリをモバイル アプリケーションに割り当てることができます。メモリは 2.7 GB まで必要に応じて解放されるためです。どちらの場合も、Contoso は、フロントエンド サーバー ハードウェアをアップグレードする必要はありません。

note注:
モビリティの CPU 使用率の目標は、平均を 10% とすることです。サーバー制限である 70% に近づいた場合、Contoso は CPU プロセッサ時間を監視する必要があります。

2 台のサーバーが含まれるフロントエンド プール

Contoso は、8,000 ユーザーを、2 台のサーバーが含まれるフロントエンド プールに展開しています。Contoso は、すべてのユーザーに対してモビリティ サービスを有効にすることを計画しています。

計画フェーズで、Contoso の管理者は以下のデータを取得しました。

  • 各フロントエンド サーバーに 2.5 GB の使用可能メモリがある。

  • CPU 使用率が 60% 未満である。

  • すべてのユーザーが Nokia または Android モバイル デバイスを持っている。

  • Contoso のユーザー モデルは、前述の容量計画ユーザー モデルに似ている。

各サーバーで最低限必要なメモリは、164 + 4000 * 534 / 1024 = 2242 MB です。理論的に、サーバーは負荷に対応できます。ただし、2 台のサーバー間でフェールオーバーが発生した場合、サーバーは負荷に対応できません。また、モビリティの CPU 使用率は 10% を上回り、サーバーは 70% CPU 制限に達する見込みです。

このシナリオでは、プールに 1 台のサーバーを追加することをお勧めします。新しい負荷分散は、フロントエンド サーバーにつき 2667 (つまり、8000/3) ユーザーになります。追加のモビリティ コストは、2667 * 534 / 1024 = 1390 MB です。

サーバーを追加すると、サーバーの障害が発生した場合に、プール内の 3 台の各サーバーで 1,300 の追加ユーザーが受け入れられます。また、負荷の増加は 600 MB になります。新しい負荷分散によって、CPU の使用率も 70% のサーバー制限未満に抑えられます。