Optimisation des opérations XenMobile

Les performances et la stabilité des opérations XenMobile impliquent de nombreux paramètres sur XenMobile et dépendent de votre configuration de base de données NetScaler et SQL Server. Cet article se concentre sur les paramètres liés à l’optimisation de XenMobile les plus souvent configurés par les administrateurs. Citrix vous recommande d’évaluer chacun des paramètres de cet article avant de déployer XenMobile.

Important :

Ces instructions supposent que l’UC et la RAM de XenMobile Server sont adaptés au nombre d’appareils. Pour plus d’informations sur la montée en charge, consultez la section Capacité à monter en charge et performances.

Les propriétés de serveur suivantes s’appliquent globalement aux opérations, utilisateurs et appareils sur une instance XenMobile entière. La modification de certaines propriétés de serveur nécessite un redémarrage de chaque nœud de serveur XenMobile. XenMobile vous informe lorsqu’un redémarrage est requis.

Ces instructions d’optimisation s’appliquent à la fois aux environnements en cluster et sans cluster.

hibernate.c3p0.idle_test_period

Cette propriété XenMobile Server, une clé personnalisée, détermine le temps d’inactivité en secondes avant qu’une connexion soit automatiquement validée. Configurez la clé comme suit. La valeur par défaut est 30.

  • Clé : Clé personnalisée
  • Clé : hibernate.c3p0. idle_test_period
  • Valeur : 120
  • Nom d’affichage : hibernate.c3p0. idle_test_period
  • Description : Période d’inactivité prolongée de test

Hibernate.C3P0.max_size

Cette clé personnalisée détermine le nombre maximal de connexions que XenMobile peut ouvrir pour la base de données SQL Server. XenMobile utilise la valeur que vous spécifiez pour cette clé personnalisée en tant qu’une limite supérieure. Les connexions s’ouvrent uniquement si vous en avez besoin. Basez vos paramètres sur la capacité de votre serveur de base de données.

Notez l’équation suivante dans une configuration en cluster. Votre connexion c3p0 multipliée par le nombre de nœuds est égale au nombre maximum de connexions que XenMobile peut ouvrir à la base de données SQL Server.

Dans une configuration en cluster et sans cluster, la définition d’une valeur trop élevée avec un serveur SQL Server sous-dimensionné peut entraîner des problèmes de ressources côté SQL pendant la charge de pointe. Si vous définissez une valeur trop faible, vous ne pourrez peut-être pas tirer parti des ressources SQL disponibles.

Configurez la clé comme suit. La valeur par défaut est 1000.

  • Clé : hibernate.c3p0.max_size
  • Valeur : 1000
  • Nom d’affichage : hibernate.c3p0.max_size
  • Description : Connexions de base de données à SQL

hibernate.c3p0.min_size

Cette clé personnalisée détermine le nombre minimal de connexions que XenMobile ouvre pour la base de données SQL Server. Configurez la clé comme suit. La valeur par défaut est 100.

  • Clé : hibernate.c3p0.min_size
  • Valeur : 100
  • Nom d’affichage : hibernate.c3p0.min_size
  • Description : Connexions de base de données à SQL

hibernate.c3p0.timeout

Cette clé personnalisée détermine le délai d’inactivité. Si vous utilisez le basculement de cluster de base de données, Citrix vous recommande d’ajouter cette clé personnalisée et de la définir pour réduire le délai d’inactivité. La valeur par défaut est 120.

  • Clé : Clé personnalisée
  • Clé : hibernate.c3p0.timeout
  • Valeur : 120
  • Nom d’affichage : hibernate.c3p0.timeout
  • Description: Délai d’inactivité de la base de données

Intervalle de pulsation des services Push

Ce paramètre détermine la fréquence à laquelle un appareil iOS vérifie si une notification APNs n’est pas fournie entre temps. L’augmentation de la fréquence de pulsation APNs peut optimiser les communications de la base de données. Une valeur trop grande peut ajouter une charge inutile. Ce paramètre s’applique uniquement aux appareils iOS. La valeur par défaut est de 20 heures.

Si vous avez un grand nombre d’appareils iOS dans votre environnement, l’intervalle de pulsation peut entraîner une charge plus importante que nécessaire. Les actions de sécurité, telles que l’effacement sélectif, le verrouillage ou l’effacement complet, ne reposent pas sur cette pulsation, une notification APNs étant envoyée à l’appareil lorsque les actions sont exécutées. Cette valeur détermine la rapidité de mise à jour d’une stratégie après la modification de l’appartenance au groupe Active Directory. Par conséquent, il est souvent approprié d’augmenter cette valeur entre 12 et 20 heures pour réduire la charge.

Taille du pool de connexions APNS iOS MDM

Un pool de connexions APNs trop petit peut affecter négativement les performances de l’activité APNs lorsque vous avez plus de 100 appareils. Les problèmes de performances incluent un déploiement plus lent des applications et des stratégies sur les appareils et un ralentissement de l’enregistrement des appareils. La valeur par défaut est 1. Nous vous recommandons d’augmenter cette valeur de 1 pour tous les 400 appareils, jusqu’à une valeur maximale de 15.

auth.ldap.connect.timeout

Pour compenser les réponses LDAP lentes, Citrix recommande d’ajouter des propriétés de serveur pour la clé personnalisée suivante.

  • Clé : Clé personnalisée
  • Clé : auth.ldap.connect.timeout
  • Valeur : 60000
  • Nom d’affichage : auth.ldap.connect.timeout
  • Description : Délai d’expiration de la connexion LDAP

auth.ldap.read.timeout

Pour compenser les réponses LDAP lentes, Citrix recommande d’ajouter des propriétés de serveur pour la clé personnalisée suivante.

  • Clé : Clé personnalisée
  • Clé : auth.ldap.read.timeout
  • Valeur : 60000
  • Nom d’affichage : auth.ldap.read.timeout
  • Description : Délai d’expiration de la lecture LDAP

Autres optimisations de serveur

     
Propriété du serveur Paramètre par défaut Pourquoi modifier ce paramètre ?
Déploiement en arrière-plan 1440 minutes Fréquence des déploiements de stratégie en arrière-plan, en minutes. S’applique uniquement aux connexions permanentes pour les appareils Android. L’augmentation de la fréquence des déploiements de stratégies réduit la charge du serveur. Le paramètre recommandé est 1440 (24 heures).
Inventaire matériel en arrière-plan 1440 minutes Fréquence de l’inventaire matériel en arrière-plan, en minutes. S’applique uniquement aux connexions permanentes pour les appareils Android. L’augmentation de la fréquence d’inventaire matériel réduit la charge du serveur. Le paramètre recommandé est 1440 (24 heures).
Intervalle pour vérifier l’utilisateur Active Directory supprimé. 15 minutes L’heure de synchronisation standard pour Active Directory est 15 minutes. La valeur 0 empêche XenMobile de rechercher les utilisateurs Active Directory supprimés. Le paramètre recommandé est 15 minutes.
MaxNumberOfWorker 3 Nombre de threads utilisé lors de l’importation d’un grand nombre de licences VPP. La valeur par défaut est 3. Si vous avez besoin d’une plus grande optimisation, vous pouvez augmenter le nombre de threads. Toutefois, notez qu’avec un nombre important de threads, tels que 6, une importation VPP entraîne une utilisation d’UC élevée.

Optimisation de la planification du déploiement pour les appareils Android

Vous pouvez planifier des déploiements pour les appareils Android à l’aide des paramètres Google Firebase Cloud Messaging (FCM, précédemment appelé Google Cloud Messaging).

L’activation de FCM pour votre environnement XenMobile permet des notifications en temps quasi réel sur les appareils Android, similaires aux APNs pour les appareils iOS. Lorsque FCM est configuré et que XenMobile doit se connecter à un appareil pour une opération telle qu’une mise à jour de stratégie ou un effacement sélectif, le serveur XenMobile envoie un message de notification au serveur FCM pour transférer la demande à l’appareil client. Une fois que l’appareil a reçu la notification de FCM, l’appareil se connecte à XenMobile pour obtenir des instructions supplémentaires. Gardez à l’esprit que cette méthode repose sur des serveurs tiers (Google) et qu’elle est donc soumise à des interruptions de service hors du contrôle de votre département informatique ou du support Citrix.

Pour plus d’informations sur l’enregistrement au service FCM, consultez la section Configuration de XenMobile et Firebase Cloud Messaging (FCM).

Si vous utilisez FCM pour Android, tenez compte des propriétés du serveur XenMobile suivantes. Les propriétés utilisent toujours l’acronyme antérieur de Google Cloud Messaging, GCM.

  • Clé API de GCM : clé de l’API GCM créée dans Google Developers Console.
  • ID de l’expéditeur de GCM : numéro de projet dans Google Developers Console.
  • Durée de vie de l’ID d’enregistrement de GCM : délai, en jours, avant le renouvellement de l’ID d’enregistrement FCM de l’appareil. La valeur par défaut est 10.
  • Intervalle de pulsation de GCM : la valeur par défaut est 6 heures.

Vérification des blocages dans une base de données SQL et suppression des données historiques

Lorsque vous rencontrez des blocages, exécutez la requête suivante pour les afficher. Un administrateur de base de données ou l’équipe Microsoft SQL pourra ensuite confirmer les informations.

Requête 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

Nettoyer la base de données

Important :

Sauvegardez votre base de données avant d’apporter des modifications aux tables.

  1. Exécutez la requête suivante pour vérifier les données historiques.

    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;
    
  2. Supprimez les données des trois tables précédentes.

    Remarque :

    Vous pouvez ne pas voir les données historiques dans une table. Si c’est le cas, passez l’exécution de la requête de troncature pour la table en question.

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    
  3. Débloquez les requêtes SELECT qui ont été bloquées en raison des blocages. Cette étape prend en charge les autres blocages.

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    
  4. Par défaut, le nettoyage de la base de données est de sept jours pour la conservation de la rétention de la session et les données de rétention d’audit, ce qui est élevé pour un grand nombre d’utilisateurs. Modifiez la valeur de nettoyage à 1 ou 2 jours. Dans les propriétés du serveur, effectuez les modifications suivantes :

    zdm.dbcleanup.sessionRetentionTimeInDays = 1 day
    zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day
    zdm.dbcleanup.auditRetentionTimeInDays=1 day
    

Nettoyer les orphelins dans la table KEYSTORE

Si les performances des nœuds XenMobile ne sont pas satisfaisantes, vérifiez que la table KEYSTORE ne soit pas trop grande. XenMobile stocke les certificats d’inscription dans les tables ENROLLMENT_CERTIFICATE et KEYSTORE. Lorsque vous supprimez ou réinscrivez des appareils, les certificats de la table ENROLLMENT_CERTIFICATE sont supprimés. Les entrées de la table KEYSTORE sont conservées, ce qui peut entraîner des problèmes de performances. Effectuez la procédure suivante pour nettoyer les orphelins de la table KEYSTORE.

Important :

Sauvegardez votre base de données avant d’apporter des modifications aux tables.

  1. Exécutez la requête suivante pour vérifier les données historiques.

    select COUNT(*) from KEYSTORE
    
  2. Recherchez les orphelins dans la table KEYSTORE avec la requête suivante.

    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;
    
  3. Effacez les orphelins à l’aide de la requête suivante.

    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'
        );
    
  4. Ajoutez un index à la table KEYSTORE pour améliorer l’efficacité de la recherche.

    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");