Product Documentation

Ajustar las operaciones de XenMobile

El rendimiento y la estabilidad de las operaciones de XenMobile implican muchas configuraciones en XenMobile y dependen de la configuración de NetScaler y la base de datos de SQL Server. Este artículo se centra en los parámetros que definen con mayor frecuencia los administradores, relacionadas con los ajustes y la optimización de XenMobile. Citrix recomienda que evalúe cada una de las configuraciones en este artículo antes de implementar XenMobile.

Importante:

En estas pautas se asume que la CPU y la RAM del servidor XenMobile corresponden con la cantidad de dispositivos. Para obtener más información acerca de la escalabilidad, consulte Escalabilidad y rendimiento en la documentación de XenMobile.

Las siguientes propiedades de servidor se aplican globalmente a operaciones, usuarios y dispositivos en toda la instancia de XenMobile. Un cambio en algunas propiedades de servidor requiere un reinicio de cada nodo del servidor XenMobile. XenMobile le notifica cuando es necesario un reinicio.

Estas indicaciones de ajustes se aplican a entornos agrupados en clúster y no agrupados.

hibernate.c3p0.idle_test_period

Esta propiedad del servidor XenMobile, una clave personalizada (Custom Key), determina el tiempo de inactividad, en segundos, antes de que se valide automáticamente una conexión. Configure la clave de este modo. El valor predeterminado es 30.

  • Clave: Clave personalizada
  • Clave: hibernate.c3p0. idle_test_period
  • Valor: 30
  • Nombre simplificado: hibernate.c3p0. idle_test_period
  • Descripción: Periodo de prueba para el tiempo de espera antes de hibernar

hibernate.c3p0.max_size

Esta clave personalizada determina la cantidad máxima de conexiones a la base de datos de SQL Server que puede abrir XenMobile. XenMobile utiliza el valor que se especifica para esta clave personalizada como el límite máximo. Las conexiones se abren solo si las necesita. Debe establecer sus parámetros en función de la capacidad del servidor de la base de datos.

Tenga en cuenta la siguiente ecuación en una configuración en clúster. La conexión c3p0 multiplicada por la cantidad de nodos equivale a su cantidad máxima real de conexiones a la base de datos de SQL Server que XenMobile puede abrir.

En configuraciones agrupadas en clúster o sin clústeres, establecer el valor demasiado alto con un SQL Server demasiado pequeño puede causar problemas de recursos en el lado de SQL durante la carga máxima. Establecer un valor demasiado bajo puede derivar en que no aproveche los recursos SQL disponibles.

Configure la clave de este modo. El valor predeterminado es 1000.

  • Clave: hibernate.c3p0.max_size
  • Valor: 1000
  • Nombre simplificado: hibernate.c3p0.max_size
  • Descripción: Conexiones de base de datos a SQL

hibernate.c3p0.min_size

Esta clave personalizada determina la cantidad mínima de conexiones a la base de datos de SQL Server que puede abrir XenMobile. Configure la clave de este modo. El valor predeterminado es 100.

  • Clave: hibernate.c3p0.min_size
  • Valor: 100
  • Nombre simplificado: hibernate.c3p0.min_size
  • Descripción: Conexiones de base de datos a SQL

hibernate.c3p0.timeout

Esta clave personalizada determina el tiempo de espera de inactividad. Si usa la conmutación por error en los clústeres de la base de datos, Citrix recomienda agregar esta clave personalizada y definirla para reducir el tiempo de inactividad. El valor predeterminado es 120.

  • Clave: Clave personalizada
  • Clave: hibernate.c3p0.timeout
  • Valor: 120
  • Nombre simplificado: hibernate.c3p0.timeout
  • Descripción: Tiempo de espera de inactividad que tiene la DB

Intervalo de latido de Push Services

Esta configuración determina la frecuencia con la que un dispositivo iOS verifica si una notificación APNs se ha entregado en el intervalo. Aumentar la frecuencia de latidos del APNs puede optimizar las comunicaciones de la base de datos. Un valor demasiado grande puede agregar una carga innecesaria. Esta configuración solo se aplica a dispositivos iOS. El valor predeterminado es 20 horas.

Si tiene una gran cantidad de dispositivos iOS en su entorno, el intervalo de latidos puede generar una carga mayor de la necesaria. Las acciones de seguridad, como el borrado selectivo, el bloqueo y el borrado completo, no dependen de este latido. Esto se debe a que se envía una notificación APN al dispositivo cuando se ejecutan estas acciones. Este valor determina la rapidez con la que se actualiza una directiva después de que cambien los miembros de los grupos de Active Directory. Como tal, a menudo es conveniente aumentar este valor a entre 12 y 20 horas para reducir la carga.

Tamaño de la agrupación de conexiones APNS de iOS MDM

Una agrupación de conexiones APNs que es demasiado pequeña puede afectar negativamente al rendimiento de las actividades APNs si dispone de más de 100 dispositivos. Los problemas de rendimiento incluyen una implementación más lenta de aplicaciones y directivas en los dispositivos y un registro más lento de los dispositivos. La configuración recomendada es 10 o hasta la cantidad máxima de servidores APNs para su ubicación geográfica. El valor predeterminado es 10.

auth.ldap.connect.timeout

Para compensar las respuestas LDAP lentas, Citrix recomienda que agregue propiedades de servidor a la siguiente clave personalizada.

  • Clave: Clave personalizada
  • Clave: auth.ldap.connect.timeout
  • Valor: 60000
  • Nombre simplificado: auth.ldap.connect.timeout
  • Descripción: Tiempo de espera de la conexión LDAP

auth.ldap.read.timeout

Para compensar las respuestas LDAP lentas, Citrix recomienda que agregue propiedades de servidor a la siguiente clave personalizada.

  • Clave: Clave personalizada
  • Clave: auth.ldap.read.timeout
  • Valor: 60000
  • Nombre simplificado: auth.ldap.read.timeout
  • Descripción: Tiempo de lectura de la conexión LDAP

Otras optimizaciones de servidor

     
Propiedad de servidor Configuración predeterminada ¿Por qué cambiar esta configuración?
Implementación en segundo plano 1440 minutos La frecuencia de las implementaciones de directivas en segundo plano, en minutos. Se aplica solo a las conexiones permanentes de dispositivos Android. Aumentar la frecuencia de las implementaciones de directivas reduce la carga del servidor. La configuración recomendada es 1440 (24 horas).
Inventario de hardware en segundo plano 1440 minutos La frecuencia del inventario de hardware en segundo plano, en minutos. Se aplica solo a las conexiones permanentes de dispositivos Android. Aumentar la frecuencia del inventario de hardware reduce la carga del servidor. La configuración recomendada es 1440 (24 horas).
Intervalo de verificación de usuarios eliminados de AD 15 minutos El tiempo de sincronización estándar para Active Directory es 15 minutos. El valor 0 impide que XenMobile verifique si hay usuarios eliminados de Active Directory. La configuración recomendada es 15 minutos.
MaxNumberOfWorker 3 La cantidad de subprocesos que se utiliza cuando se importa una gran cantidad de licencias VPP. El valor predeterminado es 3. Si necesita mayor optimización, puede aumentar la cantidad de subprocesos. No obstante, con una mayor cantidad de subprocesos (por ejemplo, 6), una importación VPP consume mucha CPU.

Optimizar la programación de implementación para dispositivos Android

Puede programar implementaciones para dispositivos Android utilizando Firebase Cloud Messaging de Google (FCM, anteriormente conocida como Google Cloud Messaging).

Habilitar FCM en su entorno XenMobile permite notificaciones casi en tiempo real a dispositivos Android, de forma similar a las notificaciones APNs para dispositivos iOS. Con FCM configurado, cuando XenMobile necesita conectarse a un dispositivo para una actualización de directiva, borrado selectivo, etc., el servidor XenMobile envía un mensaje de notificación al servidor FCM para reenviar la solicitud al dispositivo cliente. Después de que el dispositivo reciba la notificación desde FCM, el dispositivo se conecta de nuevo a XenMobile para obtener más instrucciones. Tenga en cuenta que este método se basa en servidores de terceros (Google) y, por lo tanto, está sujeto a interrupciones del servicio que su departamento de TI o Citrix Support no pueden controlar.

Para obtener información sobre cómo registrarse en el servicio FCM, consulte XenMobile and Firebase Cloud Messaging (FCM) Configuration.

Si utiliza FCM para Android, tenga en cuenta las siguientes propiedades del servidor XenMobile. En las propiedades aún se usa el acrónimo anterior de Google Cloud Messaging, GCM.

  • Clave API de GCM: La clave creada en Google Developers Console.
  • ID de remitente de GCM: El “número de proyecto” en Google Developers Console.
  • Tiempo de vida del ID de registro de GCM: La demora, en días, antes de renovar el ID de registro GCM del dispositivo. El valor predeterminado es 10.
  • Intervalo de latido de GCM: El valor predeterminado es 6 horas.

Cómo comprobar interbloqueos en una BD SQL y eliminar datos históricos

Cuando detecte interbloqueos, ejecute la siguiente consulta para verlos. A continuación, un administrador de bases de datos o un equipo de Microsoft SQL puede confirmar la información.

Consulta 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

Para limpiar la base de datos

Importante:

Realice una copia de seguridad de la base de datos antes de modificar las tablas.

  1. Ejecute la siguiente consulta para comprobar los datos históricos.

    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. Elimine los datos de las tres tablas anteriores.

    Nota:

    Es posible que no vea datos históricos en una tabla. En tal caso, omita la ejecución de la consulta truncate para dicha tabla.

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    
  3. Desbloquee las consultas SELECT que se bloquearon con los interbloqueos. Este paso se encarga de posteriores interbloqueos.

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    
  4. De forma predeterminada, la limpieza de la base de datos se realiza cada siete días para conservar datos de retención de sesión y de retención de auditoría, un valor elevado para muchos usuarios. Cambie el valor de limpieza a 1 o 2 días. En las propiedades del servidor, realice el siguiente cambio:

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