Product Documentation

XenMobileのスケーラビリティとパフォーマンス

Aug 02, 2016

XenMobileインフラストラクチャの規模を理解することはXenMobileを展開し構成する方法を決定するうえで重要な役割を果たします。 このトピックでは、小規模から大規模のエンタープライズ展開の要件を判断するうえでよくある質問に対する回答を提供します。

パフォーマンスとスケーラビリティのガイドライン

このトピックのデータは、XenMobile 10.3.6インフラストラクチャのパフォーマンスとスケーラビリティを判断するためのガイドラインとして使用することを想定しています。 サーバーとデータベースのスケーラビリティを構成する方法を判断するための2つの重要な要素は、スケーラビリティ(最大ユーザー数/デバイス数)とログオン数です。
  • スケーラビリティは定義済みのワークロードを実行する同時ユーザーの最大数として定義されます。 XenMobileインフラストラクチャをロードするために使用されるフローについて詳しくは、「ワークロード」を参照してください。
  • ログオン数は新規ユーザーのオンボーディングと既存ユーザーの認証の数として定義されます。
    • オンボーディング数は環境に初めて登録できる最大デバイス数です。 このトピックでは初回使用またはFTUと呼ばれます。このデータポイントはロールアウト戦略を調整するうえで重要です。
    • 既存ユーザー数は環境に対して認証される最大ユーザー数です。このユーザーは既に登録済みで自分のデバイスで接続したことがあります。 以下のテストには、登録済みユーザーに対するセッションの作成およびWorxMailとWorxWebアプリの実行が含まれます。

以下の表に、対応するXenMobile環境のテスト結果に基づくスケーラビリティのガイドラインを示します。

スケーラビリティ最大45,000デバイス
ログオン数オンボーディング(FTU)毎時最大833デバイス
既存ユーザー毎時最大2,812デバイス
構成NetScaler GatewayMPX 20500
XenMobile Enterprise Edition6ノードで構成されるXenMobileサーバークラスター
データベースMicrosoft SQL Server外部データベース

Important

このレポートを自動化するには、デバイス数が1,000~60,000である必要があります。 デバイス数が60,000を超える場合の要件については、このレポートの範囲外です。

プロファイル設定のテスト

このセクションでは、Active Directoryの構成、XenMobileポリシーの数、アプリケーションの数や種類、ユーザーアクションのシミュレーション、および各ハードウェア構成に対して使用されるテストプロファイルと、この記事でテスト結果を導き出すために使用されるワークロードの、管理者アクションのシミュレーションについて説明します。

注意

このテストプロファイルは、XenMobileの以前のバージョンでスケーラビリティをテストするために使用されたプロファイルより多くのリソースを使用するように設計されています。 このため、これらのテスト結果は、以前のバージョンのスケーラビリティの結果と直接的には比較できません。

Active Directory(AD)構成:

  • 100,000人の一意のADユーザー
  • 200,000の一意のADグループ
  • ADグループに対しては5階層レベル
  • ADグループあたり200ユーザー
デリバリーグループ:
  • 20のデリバリーグループ
  • デリバリーグループに50のアプリケーションを割り当て
  • デリバリーグループあたり10のADグループ
XenMobileデバイスポリシー:
  • 300のデバイスポリシー
  • ユーザーごとに20のデバイスポリシー
アプリケーション:
  • 1つの公開ストアから200のネイティブアプリケーション
  • 50のネイティブのエンタープライズ配布アプリケーション
  • 100のWebおよびSoftware as a Service(SaaS)アプリケーション
  • ユーザーあたり50のアプリケーション
XenMobileユーザーのアクション:
  • 50の合計構成済みアクション
  • Worx Storeは次のものを起動します:
    • 新規ユーザー(FTU):4
    • 既存ユーザー(RU):1
  • アプリケーションは次のものを起動します:
    • MDX:1
    • Web/SaaS:1
  • ユーザーあたり150のSTA検証
XenMobile管理者操作:
  • デバイスの列挙(ヘルプデスク電話シナリオのシミュレーション):8時間あたり32の操作(15~20分ごとに1つ)。
  • レポートの生成:8時間あたり2回。

システム構成およびテスト結果

このセクションでは、使用したハードウェア構成と、オンボーディング(FTU)ワークロードおよび既存ユーザーワークロードのスケーラビリティテストの実行結果について説明します。

以下の表は、1,000-60,000デバイスのXenMobile環境に推奨されるハードウェアおよび構成を示します。 これらのガイドラインはテスト結果および関連するワークロードに基づいています。 推奨事項は、「終了基準」に定義する許容可能なエラー発生の余地を考慮に入れたものです。 

テスト結果の解析により、以下の結論が導かれました。

  • ログオン数はシステムのスケーラビリティを判断するうえで重要な要素です。 初回ログオンに加えて、ログオン数は環境に構成されている認証タイムアウト値に左右されます。 たとえば、認証タイムアウト値が低すぎると、ユーザーはより頻繁にログオン要求を実行する必要があります。 したがって、タイムアウト値が環境に与える影響を明確に理解する必要があります。
  • NetScalerでのユーザーセッションあたりの接続数は重要な検討項目です。
  • 最大のスケーラビリティを得るため、XenMobileにCPUおよびRAMのリソースを追加しました。
  • 検証された最大の構成は6ノードのクラスター構成です。 6ノードを超える規模拡大にはXenMobileを追加で導入する必要があります。

次の表は、XenMobile構成、NetScaler Gatewayアプライアンス、クラスタ設定、およびデータベースに基づく、推奨されるオンボーディングおよび既存ユーザーのログオン数を示しています。 この表のデータを使用して、新しい展開、および既存の展開に対する既存ユーザー/デバイス数に最適な登録スケジュールを立てます。 構成のセクションは、登録とログオンのパフォーマンスデータと、推奨される適切なハードウェアの関係を示します。

予想されるデバイス数

1,000

10,000

30,000

45,000
実際のデバイス数1,0009,99829,97744,991

ログオン数

 

オンボーディング(FTU)

250

625

833833

既存ユーザー数(Worxのみ)

1,000

1,6663,750883

構成

 

参照環境

VPX-XenMobileスタンドアロン

MPX-XenMobileスタンドアロン

MPX-XenMobileクラスター(3)

MPX-XenMobileクラスター(6)

NetScaler Gateway

2GBのRAMを搭載したVPX

2つの仮想CPU

MPX-10500

MPX-11500MPX-11500

XenMobile - モード

スタンドアロン*スタンドアロン*

クラスター

クラスター

XenMobile - クラスター

-

-

3

6

XenMobile - 仮想アプライアンス

8GBのRAMおよび4つの仮想CPU

8GBのRAMおよび4つの仮想CPU

16GBのRAMおよび6つの仮想CPU

16GBのRAMおよび8つの仮想CPU
Active Directory(AD)8GBのRAMおよび4つの仮想CPU8GBのRAMおよび4つの仮想CPU16GBのRAMおよび4つの仮想CPU16GBのRMおよび4つの仮想CPU

データベース

外部

外部 -

Microsoft SQL Server

メモリ = 16GB

仮想CPU = 12

外部 -

Microsoft SQL Server

メモリ = 32GB

仮想CPU = 12

外部 -

Microsoft SQL Server

メモリ = 48GB

仮想CPU = 16

MPX-XenMobileクラスター(3)

クラスター

クラスター

クラスター

クラスター

8GBのRAMおよび4つの仮想CPU

8GBのRAMおよび4つの仮想CPU

* スタンドアロン展開は、ユーザーに対する可用性が高くなければならないアプリケーションにはお勧めできません。 大部分のお客様には、高可用性のクラスタ展開をお勧めします。

:システム規模に対して推奨される数を超過する登録やログオンがあったりハードウェアの性能が不足していたりすると、以下の事象が発生します。 

次の情報は記録された追加のデータポイントを提供します。これらのデータポイントは前の表の結果に
影響を及ぼします。

  • 登録またはログオンの遅延(ラウンドトリップ時間)
    • 平均遅延時間の合計:0.5~1.5秒
    • NetScaler Gatewayログオンの平均遅延時間:120~440ミリ秒
    • WorxStore要求の平均遅延時間:2~3秒
  • スケーラビリティの制限に達すると、インフラストラクチャコンポーネントにCPUおよびメモリの消費のような物理的なパフォーマンスの低下が見られます。
    • NetScaler GatewayおよびXenMobileアプライアンス上での無効な応答
    • 高負荷状態でのXenMobileコンソールの応答時間の遅延
localized image
localized image

上の図のエラー率には各操作に対応する要求に対して発生する全体的なエラーが含まれており、ログオンに限定したものではありません。 「終了基準」に定義するとおり、エラー率は各実行テストの1%という許容可能な範囲に収まっています。

次の図は、小規模な展開のリファレンスアーキテクチャを示しています。 これはスタンドアロンアーキテクチャで、10,000デバイスまでをサポートします。

 

localized image

次の図は、エンタープライズ展開のリファレンスアーキテクチャを示しています。 これはクラスターアーキテクチャで、HTTP経由のMAMに対するSSLオフロードが有効です。10,000デバイス以上をサポートします。

localized image

テスト方法

ベンチマークを確立するため、XenMobile Enterpriseに対してテストを実行しました。 小規模および大規模な展開の両方を対象とし、測定には1,000~60,000デバイスを使用しました。

実世界のユースケースをシミュレートするためワークロードを作成しました。 これらのワークロードを各テストで実行し、登録およびログオン数への影響を調査しました。 テストの目標は、「終了基準」に定義する許容可能なエラー発生の余地に収まる最適なログオン数を得ることでした。 ログオン数は、インフラストラクチャコンポーネントのハードウェア構成に対する推奨事項を判断するうえで重要な要素です。

オンボーディング(FTU)ワークロードのログオン要求には、自動検出、認証、およびデバイス登録の操作が含まれました。 アプリケーションのサブスクリプション、インストール、および起動操作は、テスト期間を通じて均等に分散されました。 これにより、実世界のユーザー行動のシミュレーションが提供されました。 テストの最後にセッションはログアウトされました。 既存ユーザーワークロードのログオン要求には、認証要求のみが含まれました。

ワークロード

ユーザーワークロードは以下のように定義されます。
 
ユーザーセッション/デバイス各セッションのNetScaler Gatewayログオン、列挙、デバイス登録などが含まれます。
Worx Storeの起動ユーザーがWorx Storeを複数回起動し、そのたびに、モバイルアプリ(Web/SaaS/MDX)かWindowsアプリ(HDX)かを問わず、複数のアプリをサブスクライブつまりインストールします。
デバイスあたりのWeb/SaaSアプリのSSOXenMobileでSSOが完了して実際のアプリのURLを返すまでの、Web/SaaSアプリの起動シーケンスです。 実際のアプリにトラフィックは送信されませんでした。
デバイスあたりのMDXアプリのダウンロードMDXアプリのダウンロード数です(これはWorx Storeの起動中いつでも発生する可能性があります)。 iOSの場合、Apple ITMSからのアプリの自動インストールが含まれます。これにより、NetScaler Gateway上で新しいトークン/tmsサービスAPIが活用されます。
 

注記と前提

 

以下のシナリオはスケーラビリティテストの対象外となります。 これらのシナリオは、今後のスケールテストの機能拡張で検討されます。

  • パッケージの展開がテストされません。
  • Windowsプラットフォームがテストされません。
ポリシーのプッシュは、iOSおよびAndroidデバイスでテストされています。

各XenMobileは最大10,000の接続を同時にサポートします。

テストは、ネットワーク遅延の問題を無視できるように、理想的なLANの条件で行われています。 実際のシナリオでは、特にアプリケーションのダウンロードに関して、スケーラビリティは利用可能なユーザーの帯域幅によっても大きく変わります。

再接続テスト

再接続テストは初回使用テストと既存ユーザーシナリオテストで個別に行われています。

再接続テストが最大15,000のデバイスに対して実行されました。

Androidでサポートされている再接続率は1秒あたり17デバイスです。 iOSの再接続率は1秒あたり8デバイスです。 これを実現するために、/opt/sas/tomcat/conf/server.xmlファイルのmaxThreadカウントは1000に設定しました。

要追加:推奨デバイス再接続ポリシーに関する情報

 
オンボーディング(FTU)ワークロード
オンボーディング(FTU)ワークロードは、XenMobile環境へのユーザーによる初めてのアクセスと定義されます。 このワークロードに含まれる操作は以下のとおりでした。
  • 自動検出
  • Enrollment
  • Authentication
  • デバイス登録
  • アプリケーションの検出(Web、SaaS、およびモバイルMDXアプリ)
    • アプリケーションのサブスクリプション(画像とアイコンのダウンロードを含む)
    • サブスクライブされたMDXアプリのインストール
  • デバイスの状態の確認を含むアプリケーションの起動(Web、SaaS、およびモバイルMDXアプリ)
  • ポリシーのプッシュ(iOS)
  • 最小限のWorxMailおよびWorxWeb接続(VPNトンネル) — 2接続
  • XenMobile経由の必須アプリのインストール
次の表は、ワークロードのパラメーターの定義です。
 

Devices

デバイス登録

列挙

デバイスあたりのアプリの列挙

デバイスあたりのWorxStoreの起動

デバイスあたりのWeb/SaaSのSSO

デバイスあたりのMDXアプリのダウンロード

XenMobileサーバーによってトリガーされる必須アプリのダウンロード

デバイスあたりのプッシュされるポリシー(iOS)

1000

1000

1000

50

4

40

10

2

20

10000

10000

10000

50

4

40

10

2

20

30000

30000

30000

50

4

40

10

2

20

60000

60000

60000

50

4

40

10

2

20

Worxへの接続のみを使用する既存ユーザーのワークロード

次の表は、既存ユーザー(Worxへの接続のみを使用)のワークロードです。 このワークロードにより、WorxMailおよびWorxWebアプリを使用する1人のユーザーがシミュレートされました。 このシミュレーションを使用して、XenMobile構成内のNetScaler Gatewayのスケーラビリティを測定しました。  この測定が可能になるのは、これら2つのWorxアプリのみを使用することでネットワークの負荷が最小限になるからです。 WorxWebアプリについては、ユーザーは内部Webサイトにアクセスしています。この場合XenMobileサーバーのSSOはトリガーされません。  このモードで含まれる操作は以下のとおりです。

  • 認証(NetScaler GatewayとXenMobile)
  • WorxMailおよびWorxWeb接続(VPNトンネル) — 4接続

以下の表は既存ユーザーのワークロードパラメーターを示します。

Devices

列挙

デバイスあたりのアプリの列挙

デバイスあたりのVPNトンネル1

1000

1000

50

3

10000

10000

50

3

30000

30000

50

3

60000

60000

50

3

1. VPNトンネルの数は、WorxMailおよびWorxWebの接続の数に対応します。

次の表は、WorxMailおよびWorxWebの接続プロファイルの概要です。

デバイス接続接続の種類セッションあたりの送信データ1セッションあたりの受信データ1
WorxMail接続 #1タイプ124.1MB4.1MB
WorxMail接続 #2タイプ16.3MB12.5MB
WorxWeb接続 #1タイプ235.2MB15.7MB
WorxWeb接続 #2タイプ24.1MB3.4MB
セッションあたりの転送バイト合計1~19.7MB~40.7MB

 

1.セッションあたり:8時間

タイプ1:長時間の非対称な送信および受信接続(Microsoft Exchangeのメールボックスに対するWorxMailの接続)。

タイプ2:閉じてしばらく待った後で再び開く、非対称な送信および受信接続(WorxWeb接続)

これらの推奨事項は、「中程度」のワークロードを自動化するためのWorxMailおよびWorxWebのプロファイルに基づいて
設定されています。 接続の詳細を変更すると解析結果に影響があります。 たとえば、ユーザーあたりの接続数を増やす場合、サポートされるNetScaler Gatewayセッションの数は減少する可能性があります。

WorxMailおよびWorxWebのプロファイル

各アプリで使用するプロファイルは、「非常に高負荷の」ワークロードを自動化することを目的としています。次の表は、WorxMailおよびWorxWebのプロファイルの詳細です。

中程度のワークロードのWorxMailプロファイル

1日あたりの送信メッセージ20
1日あたりの受信メッセージ80
1日あたりの読み取りメッセージ80
1日あたりの削除メッセージ20
平均メッセージサイズ(KB)200

中程度のワークロードのWorxWebプロファイル

起動Webアプリ数10
手動で開くWebページ数10
Webアプリあたりの平均要求-応答ペア数100
要求の平均サイズ(バイト)300
応答の平均サイズ(バイト)1000

 

構成とパラメーター

以下の構成を使用してスケーラビリティテストを実行しました。

  • NetScaler Gatewayおよび負荷分散(LB)仮想サーバーを同じNetScaler Gatewayアプライアンスに共存させました。
  • NetScalerのセッションタイムアウトを60分に設定しました。
  • SSLトランザクションにNetScaler Gateway上の2048ビットキーを使用しました。

終了基準

この解析の基礎はログオン数です。 ログオン数によって、インフラストラクチャコンポーネントおよびコンポーネントそれぞれの構成のガイドラインが提供されます。 ログオン数は、以下のようなエラー発生の余地を考慮に入れたものであることに留意してください。

  • 無効な応答
    • ステータスコードが200ではなく401/404の応答は無効とみなされます。
  • 要求のタイムアウト
    • 120秒以内に応答があることが期待されます。
  • 接続エラー
    • 接続がリセットされます。
    • 接続が突然終了されます。

全体的なエラー率が任意のデバイスから送信される要求数の合計の1%未満であれば、ログオン数は許容可能です。 エラーには、各個別のワークロード操作に対応するエラーはもちろん、CPUやメモリの消費のようなインフラストラクチャコンポーネントの物理的なパフォーマンスにかかわるものも含まれます。

ソフトウェアおよびハードウェアの詳細

以下の表は、これらのテストに使用されたXenMobileインフラストラクチャのソフトウェアを示します。

コンポーネントバージョン
NetScaler Gateway

11.0-62.10.nc

10.5-57.7.n

XenMobile10.3.0.824
外部データベースMicrosoft SQL Server 2014

以下のテーブルに示すXenServerプラットフォーム上で、スケーラビリティテストを実行しました。

ベンダーGenuine Intel
ModelIntel Xeon CPU — E5645 @ 2.40GHz(CPU数24)

これにはインフラストラクチャの中核的なサービス(Active Directory、Windowsドメインネームサービス(DNS)、証明機関、Microsoft Exchangeなど)とXenMobileコンポーネント(XenMobile仮想アプライアンスおよび該当する場合はNetScaler Gateway VPX仮想アプライアンス)が含まれます。