Product Documentation

XenMobileの展開規模

Oct 25, 2016

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

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

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

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

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

Important

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

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

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

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

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

  • ログオン数はシステムのスケーラビリティを判断するうえで重要な要素です。 初回ログオンに加えて、ログオン数は環境に構成されている認証タイムアウト値に左右されます。 たとえば、認証タイムアウト値が低すぎると、ユーザーはより頻繁にログオン要求を実行する必要があります。 したがって、タイムアウト値が環境に与える影響を明確に理解する必要があります。
  • NetScalerでのユーザーセッションあたりの接続数は重要な検討項目です。
  • 128GBのRAM、300GBのディスクスペース、および24の仮想CPUを伴う外部データベース(SQL Server)を使用してテストを行いました。この仕様は実稼働環境にも推奨されます。
  • 最大のスケーラビリティを得るため、XenMobileにCPUおよびRAMのリソースを追加しました。
  • 検証された最大の構成は10ノードのクラスター構成です。 10ノードを超える規模拡大にはXenMobileを追加で導入する必要があります。

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

予想されるデバイス数

1,000

10,000

30,000

60,000

100,000

実際のデバイス数

1,000

9,997

29,976

59,831

99,645

ログオン数

オンボーディング(FTU)

125

1,250

2,500

2,500

2,777

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

1,000

2,500

7,500

15,000

16,667

構成

参照環境

VPX-XenMobileスタンドアロン

MPX-XenMobileスタンドアロン

MPX-XenMobileクラスター(3)

MPX-XenMobileクラスター(6)

MPX-XenMobileクラスター(10)

NetScaler Gateway

2GBのRAMを搭載したVPX

2つの仮想CPU

MPX-10500

MPX-20500

XenMobile - モード

スタンドアロン

スタンドアロン

クラスター

XenMobile - クラスター

-

-

3

6

10

XenMobile - 仮想アプライアンス

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

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

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

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

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

データベース

外部

外部 -

Microsoft SQL Server

メモリ = 16GB

仮想CPU = 12

外部 -

Microsoft SQL Server

メモリ = 16GB

仮想CPU = 12

外部 -

Microsoft SQL Server

メモリ = 32GB

仮想CPU = 12

外部 -

Microsoft SQL Server

メモリ = 32GB

仮想CPU = 16

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

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

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

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

XenMobile Enterprise Editionのリソース増加によるスケールテスト

このテスト結果により、ノード数が比較的少ない状況で、XenMobile Enterprise Editionがより多くの
デバイスをサポートするための展開戦略を考察できます。 このテストは、スケールアップ機能の測定を目的として、
各XenMobileサーバーノードのハードウェアコンポーネント(中央処理装置とメモリ)のリソースを増やして実行されました。 その結果、標準のリソースを使用して同じノード数でテストを実行した場合と比較して、XenMobileサーバーノードによってサポートされるセッションおよびデバイスの最大数が増加しました。

スケーラビリティ

実際のデバイスの最大数

16,433

55,194

83,421

ログオン数

導入時の初回使用 - 新規ユーザーの追加

2,054

2,299

2,317

構成

 

参照環境

VPX-XenMobileスタンドアロン

MPX-XenMobileクラスター3

MPX-XenMobileクラスター6

NetScaler Gateway

MPX-10500

MPX-10500

MPX-20500

XenMobile - モード

スタンドアロン

クラスター

クラスター

XenMobile - クラスター

-

3

6

XenMobile - 仮想アプライアンス

メモリ - 32GB

仮想CPU - 12

メモリ - 32GB

仮想CPU - 12

メモリ - 32GB

仮想CPU - 12

Device Managerデータベース

外部 –S

SQL Server

メモリ - 16GB

仮想CPU - 12

外部 -

SQL Server

メモリ - 32GB

仮想CPU - 12

外部 - SQL Server

メモリ - 32GB

仮想CPU - 16

Active Directory

メモリ - 8GB

仮想CPU = 4

メモリ - 16GB

仮想CPU - 4

メモリ - 16GB

仮想CPU - 4

localized image
localized image

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

 

localized image

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

localized image

テスト方法

ベンチマークを確立するため、XenMobile Enterpriseに対してテストを実行しました。 小規模および大規模な展開の両方を対象とし、測定には1,000~100,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が活用されます。
 

注記と前提

XenMobileのデバイスを30,000台以上に拡張するには、以下のサーバーパラメーターを調整する必要があります。

Configファイル - /opt/sas/sw/tomcat/inst1/webapps/ROOT/WEB-INF/classes/push_services.xml

 Configファイル - /opt/sas/sw/tomcat/inst1/webapps/ROOT/WEB-INF/classes/ew-config.properties

  • ios.mdm.apns.connectionPoolSize=15
  • hibernate.c3p0.max_size=1000

すべてのXenMobileノードでこれらの変更を行ってから、サーバーを再起動する必要があります。

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

  • Androidに接続されたデバイスがテストされません。
  • パッケージの展開がテストされません。
  • Windowsプラットフォームがテストされません。

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

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

 
オンボーディング(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

14

4

4

2

2

2

10000

10000

10000

14

4

4

2

2

2

30000

30000

30000

14

4

4

2

2

2

60000

60000

60000

14

4

4

2

2

2

100000

100000

100000

14

4

4

2

2

2

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

14

4

10000

10000

14

4

30000

30000

14

4

60000

60000

14

4

100000

100000

14

4

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アプライアンスに共存させました。
  • 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仮想アプライアンス)が含まれます。