XenMobile Server:最新リリース

XenMobileの動作の調整

XenMobileの動作のパフォーマンスと安定性にはXenMobile全体にわたる多くの設定が関連しており、Citrix ADCとSQL Serverデータベースの構成によっても異なります。この記事では、XenMobileの調整と最適化に関連した代表的な構成を管理する設定に注目します。XenMobileを展開する前に、この記事の各設定を評価することをお勧めします。

重要:

これらのガイドラインでは、デバイス数に対してXenMobile ServerのCPUとRAMが適切であることを想定しています。スケーラビリティの詳細については、「 スケーラビリティとパフォーマンス」を参照してください。

次のサーバープロパティは、XenMobileインスタンス全体の動作、ユーザー、およびデバイスにグローバルに適用されます。一部のサーバープロパティを変更すると、XenMobile Serverの各ノードの再起動が必要になります。再起動が必要なときにXenMobileによって通知されます。

これらの調整のガイドラインは、クラスター環境と非クラスター環境の両方に適用されます。

hibernate.c3p0.idle_test_period

この「カスタムキー」というXenMobile Serverプロパティでは、接続が自動的に検証されるまでのアイドル時間を秒単位で指定します。このキーは次のように構成します。デフォルトは30です。

  • キー:カスタムキー
  • キー:hibernate.c3p0. idle_test_period
  • 値:120
  • 表示名:hibernate.c3p0. idle_test_period
  • 説明:Hibernate idle test period

hibernate.c3p0.max_size

このカスタムキーでは、XenMobileでSQL Serverデータベースに対して開くことのできる最大接続数を指定します。XenMobileでは、このカスタムキーに指定した値が上限として使用されます。接続は必要な場合のみ開かれます。値は、データベースサーバーの処理能力に合わせて設定します。

クラスター構成では、次の式に注意してください。c3p0接続にノード数を掛けた値は、XenMobileがSQL Serverデータベースに対して開くことができる実際の最大接続数と等しくなります。

クラスター構成と非クラスター化構成では、小型のSQL Serverに対してこの設定値が大きすぎると、ピーク負荷時にSQL側でリソースの問題が発生する場合があります。設定値が小さすぎると、使用可能なSQLリソースを利用できなくなる場合があります。

このキーは次のように構成します。デフォルト値は1000です。

  • キー:hibernate.c3p0.max_size
  • 値:1000
  • 表示名:hibernate.c3p0.max_size
  • 説明:DB connections to SQL

hibernate.c3p0.min_size

このカスタムキーでは、XenMobileがSQL Serverデータベースに対して開く最小接続数を指定します。このキーは次のように構成します。デフォルトは100です。

  • キー:hibernate.c3p0.min_size
  • 値:100
  • 表示名:hibernate.c3p0.min_size
  • 説明:DB connections to SQL

hibernate.c3p0.timeout

このカスタムキーでは、アイドル状態のタイムアウトを指定します。データベースクラスターフェールオーバーを使用する場合は、このカスタムキーを追加し、アイドルタイムアウトの時間が短くなるように設定することをお勧めします。デフォルトは120です。

  • キー:カスタムキー
  • キー:hibernate.c3p0.timeout
  • 値:120
  • 表示名:hibernate.c3p0.timeout
  • 説明:Database idle timeout

プッシュ サービスのハートビート間隔

この設定では、APNs(Appleプッシュ通知サービス)通知が一時的に配信されない場合に、iOSデバイスでチェックする頻度を指定します。APNsのハートビートの頻度を増やすと、データベース通信が最適化される場合があります。値が大きすぎると、不必要な負荷が加わる場合があります。この設定は、iOSにのみ適用されます。デフォルトは20時間です。

ご使用の環境に多数のiOSデバイスがある場合、ハートビートの間隔により必要以上に負荷が高くなる場合があります。選択的なワイプ、ロック、完全なワイプなどのセキュリティ操作はこのハートビートに依存しません。これらの操作が実行されると、APNs通知がデバイスに送信されるためです。

この値は、Active Directoryグループのメンバーシップが変更された後、ポリシーをどれだけ早く更新するかを管理します。そのため、多くの場合、負荷を軽減するにはこの値を12〜20時間に増やすのが適しています。

iOS MDM APNS接続プールのサイズ

APNs接続プールが小さすぎると、100を超えるデバイスを使用する場合、APNsアクティビティのパフォーマンスに悪影響を及ぼすことがあります。パフォーマンスの問題としては、アプリやポリシーのデバイスへの展開が遅くなったり、デバイスの登録が遅くなったりするといった問題があります。デフォルトは1です。デバイスが約400台が追加されるごとに、この値を1増やすことをお勧めします。

auth.ldap.connect.timeout

LDAPの反応が遅い場合に対処するには、次のカスタムキーのサーバープロパティを追加することをお勧めします。

  • キー:カスタムキー
  • キー:auth.ldap.connect.timeout
  • 値:60000
  • 表示名:auth.ldap.connect.timeout
  • 説明:LDAP接続のタイムアウト

auth.ldap.read.timeout

LDAPの反応が遅い場合に対処するには、次のカスタムキーのサーバープロパティを追加することをお勧めします。

  • キー:カスタムキー
  • キー:auth.ldap.read.timeout
  • 値:60000
  • 表示名:auth.ldap.read.timeout
  • 説明:LDAP読み取りのタイムアウト

その他のサーバーの最適化

     
サーバープロパティ デフォルト設定 この設定を変更する理由
バックグラウンド展開 1,440分 バックグラウンドポリシーの展開の頻度(分)。Androidデバイスの常時接続にのみ適用されます。ポリシー展開の頻度を増やすと、サーバーの負荷が軽減されます。推奨の設定値は 1440(24時間)です。
バックグラウンド ハードウェア インベントリ 1,440分 バックグラウンドハードウェアインベントリの頻度(分)。Androidデバイスの常時接続にのみ適用されます。ハードウェアインベントリの頻度を増やすと、サーバーの負荷が軽減されます。推奨の設定値は 1440(24時間)です。
削除されたActive Directoryユーザーのチェック間隔 15分 Active Directoryの標準同期時間は15分です。値0を指定すると、XenMobileは削除されたActive Directoryユーザーをチェックしません。推奨の設定値は15分です。
MaxNumberOfWorker 3 多数の一括購入ライセンスをインポートするときに使用するスレッド数です。デフォルトは3です。さらに最適化が必要な場合は、スレッド数を増やすことができます。ただし、スレッド数を大きくする(6など)と、一括購入ライセンスのインポートによりCPU使用率が非常に高くなります。

SQL DB内のデッドロックをチェックし、履歴データを削除する方法

デッドロックが発生したら、次のクエリを実行してデッドロックを確認してください。その後、データベース管理者またはMicrosoft SQLチームがその情報を確認できます。

SQLクエリ

SELECT

db.name DB_Service,

tl.request_session_id,

wt.blocking_session_id,

OBJECT_NAME(p.OBJECT_ID) BlockedObjectName,

tl.resource_type,

h1.TEXT AS RequestingText,

h2.TEXT AS BlockingTest,

tl.request_mode

FROM sys.dm_tran_locks AS tl

INNER JOIN sys.databases db ON db.database_id = tl.resource_database_id

INNER JOIN sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address

INNER JOIN sys.partitions AS p ON p.hobt_id = tl.resource_associated_entity_id

INNER JOIN sys.dm_exec_connections ec1 ON ec1.session_id = tl.request_session_id

INNER JOIN sys.dm_exec_connections ec2 ON ec2.session_id = wt.blocking_session_id

CROSS APPLY sys.dm_exec_sql_text(ec1.most_recent_sql_handle) AS h1

CROSS APPLY sys.dm_exec_sql_text(ec2.most_recent_sql_handle) AS h2

GO
<!--NeedCopy-->

データベースのクリーンアップ

重要:

テーブルに変更を加える前にデータベースをバックアップしてください。

  1. 次のクエリを実行して履歴データを確認します。

    select COUNT(*) as total_record from dbo.EWDEPLOY_HISTO;
    select COUNT(*) as total_record from dbo.EWSESS;
    select COUNT(*) as total_record from dbo.EWAUDIT;
    <!--NeedCopy-->
    
  2. 上記の3つのテーブルからデータを削除します。

    注:

    履歴データがテーブルに表示されないことがあります。その場合は、その特定のテーブルでのTRUNCATEクエリの実行をスキップします。

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    <!--NeedCopy-->
    
  3. デッドロックが発生したためにブロックされたSELECTクエリのブロックを解除します。この手順ではさらに、そのほかのデッドロックも処理されます。

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    <!--NeedCopy-->
    
  4. デフォルトのデータベースクリーンアップ設定では、セッションおよび監査ログの保持データは7日間保持されます。これは、多くのユーザーにとって長すぎます。そのため、クリーンアップ値を1日または2日に変更します。サーバープロパティで、次の変更を行います:

    zdm.dbcleanup.sessionRetentionTimeInDays = 1 day
    zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day
    zdm.dbcleanup.auditRetentionTimeInDays=1 day
    <!--NeedCopy-->
    

KEYSTOREテーブルの孤立したファイルのクリーンアップ

XenMobileノードのパフォーマンスが低い場合は、KEYSTOREテーブルが大きすぎないかを確認します。XenMobile Serverは、登録証明書をENROLLMENT_CERTIFICATEテーブルおよびKEYSTOREテーブルに保存します。デバイスを削除または再登録すると、証明書がENROLLMENT_CERTIFICATEテーブルから削除されます。一方、KEYSTOREテーブルのエントリは保持され、パフォーマンスの問題を引き起こす可能性があります。次の手順を実行して、KEYSTOREテーブルの孤立したファイルをクリーンアップします。

重要:

テーブルに変更を加える前にデータベースをバックアップしてください。

  1. 次のクエリを実行して履歴データを確認します。

    select COUNT(*) from KEYSTORE
    <!--NeedCopy-->
    
  2. 次のクエリを使用して、KEYSTOREテーブル内で孤立したファイルを確認します。

    WITH cte(KEYSTORE_ID)
    AS (SELECT KEYSTORE_ID
        FROM ENROLLMENT_CERTIFICATE
        UNION
        SELECT CA_KEYSTORE_ID
        FROM LDAP_CONFIG
        UNION
        SELECT CLIENT_KEYSTORE_ID
        FROM LDAP_CONFIG
        UNION
        SELECT KEYSTORE_ID
        FROM SAML_SERVICE_PROVIDER
        UNION
        SELECT KEYSTORE_ID
        FROM SERVER_CERTIFICATE)
    SELECT keystore.id
    FROM keystore
        LEFT JOIN cte ON keystore.id = cte.KEYSTORE_ID
    WHERE KEYSTORE_ID IS NULL;
    <!--NeedCopy-->
    
  3. 次のクエリを使用して、孤立したファイルをクリアします。

    WITH cte(KEYSTORE_ID)
        AS (SELECT KEYSTORE_ID
            FROM ENROLLMENT_CERTIFICATE
            UNION
            SELECT CA_KEYSTORE_ID
            FROM LDAP_CONFIG
            UNION
            SELECT CLIENT_KEYSTORE_ID
            FROM LDAP_CONFIG
            UNION
            SELECT KEYSTORE_ID
            FROM SAML_SERVICE_PROVIDER
            UNION
            SELECT KEYSTORE_ID
            FROM SERVER_CERTIFICATE)
        DELETE FROM keystore
        WHERE id IN
        (
            SELECT keystore.id
            FROM keystore
                LEFT JOIN cte ON keystore.id = cte.KEYSTORE_ID
            WHERE KEYSTORE_ID IS NULL AND keystore.TYPE = 'X_509'
        );
    <!--NeedCopy-->
    
  4. 検索効率が向上するように、KEYSTOREテーブルにインデックスを追加します。

    DROP INDEX "KEYSTORE_NAME_IDX" ON "KEYSTORE";
    ALTER TABLE "KEYSTORE" ALTER COLUMN "NAME" NVARCHAR(255) NULL;
    CREATE INDEX "KEYSTORE_NAME_IDX" ON "KEYSTORE"("NAME") INCLUDE ("ID", "TYPE", "CONTENT", "PASSWORD", "PUBLICLY_TRUSTED", "DESCRIPTION", "ALIAS", "MODIFICATION_DATE");
    <!--NeedCopy-->
    
XenMobileの動作の調整