Product Documentation

XenMobile 작업 조정

XenMobile 작업의 성능 및 안정성은 XenMobile의 많은 설정과 관련되며 NetScaler 및 SQL Server 데이터베이스 구성에 따라 달라집니다. 이 문서에서는 XenMobile의 조정 및 최적화와 관련하여 관리자가 가장 자주 구성하는 설정을 중점적으로 설명합니다. XenMobile을 배포하기 전에 이 문서의 각 설정을 평가하는 것이 좋습니다.

중요:

다음 지침은 XenMobile 서버 CPU 및 RAM이 장치 수에 적합하다고 가정합니다. 확장성에 대한 자세한 내용은 확장성 및 성능을 참조하십시오.

다음 서버 속성은 전체 XenMobile 인스턴스의 작업, 사용자 및 장치에 글로벌로 적용됩니다. 일부 서버 속성을 변경하려면 각 XenMobile 서버 노드를 다시 시작해야 합니다. 다시 시작이 필요한 경우 XenMobile이 알림을 제공합니다.

다음 조정 지침은 클러스터된 환경과 클러스터되지 않은 환경에 모두 적용됩니다.

hibernate.c3p0.idle_test_period

XenMobile Server 속성인 사용자 지정 키는 연결 유효성이 자동으로 검사되기까지의 유휴 시간(초)을 결정합니다. 다음과 같이 키를 구성합니다. 기본값은 30입니다.

  • 키: 사용자 지정 키
  • 키: hibernate.c3p0. idle_test_period
  • 값: 30
  • 표시 이름: hibernate.c3p0. idle_test_period
  • 설명: Hibernate 유휴 테스트 기간

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
  • 설명: SQL에 대한 DB 연결

hibernate.c3p0.min_size

이 사용자 지정 키는 XenMobile에서 SQL Server 데이터베이스에 대해 여는 최소 연결 수를 결정합니다. 다음과 같이 키를 구성합니다. 기본값은 100입니다.

  • 키: hibernate.c3p0.min_size
  • 값: 100
  • 표시 이름: hibernate.c3p0.min_size
  • 설명: SQL에 대한 DB 연결

hibernate.c3p0.timeout

이 사용자 지정 키는 유휴 시간 초과를 결정합니다. 데이터베이스 클러스터 장애 조치(failover)를 사용하는 경우 이 사용자 지정 키를 추가하고, 유휴 시간 초과를 낮추도록 설정하는 것이 좋습니다. 기본값은 120입니다.

  • 키: 사용자 지정 키
  • 키: hibernate.c3p0.timeout
  • 값: 120
  • 표시 이름: hibernate.c3p0.timeout
  • 설명: 데이터베이스 유휴 시간 초과

푸시 서비스 하트비트 간격

이 설정은 iOS 장치에서 중간에 APNs 알림이 전송되지 않았는지를 확인하는 빈도를 결정합니다. APNs 하트비트 빈도를 늘리면 데이터베이스 통신을 최적화할 수 있습니다. 값이 너무 크면 불필요한 부하가 추가될 수 있습니다. 이 설정은 iOS에만 적용됩니다. 기본값은 20시간입니다.

환경에 iOS 장치가 많은 경우 하트비트 간격으로 인해 필요 이상의 부하가 발생할 수 있습니다. 선택적 초기화, 잠금 및 전체 초기화 같은 보안 동작은 이 하트비트를 사용하지 않습니다. 이러한 동작이 실행될 때는 APNs 알림이 장치로 전송되기 때문입니다. 이 값은 Active Directory 그룹 구성원 자격이 변경된 후 정책을 업데이트하는 속도를 제어합니다. 그러므로 부하를 줄이려면 이 값을 12~20시간 사이의 값으로 늘리는 것이 적절합니다.

iOS MDM APNS 연결 풀 크기

장치 수가 100대 이상인 경우 APNs 연결 풀이 너무 작으면 APNs 작업 성능에 부정적인 영향을 미칠 수 있습니다. 앱 및 정책이 장치에 느리게 배포되고 장치 등록이 느려지는 등의 성능 문제가 발생할 수 있습니다. 권장되는 설정은 10 이상이고 지리적 위치의 APNs 서버의 최대 수 이하입니다. 기본값은 10입니다.

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 많은 수의 VPP 라이센스를 가져올 때 사용되는 스레드 수입니다. 기본값은 3입니다. 추가 최적화가 필요한 경우 스레드 수를 늘릴 수 있습니다. 그러나 예를 들어 6과 같이 스레드 수가 커지면 VPP를 가져올 때 CPU 사용량이 높아진다는 점에 유의하십시오.

Android 장치의 배포 예약 최적화

Google FCM(Firebase 클라우드 메시징, 이전의 Google Cloud Messaging)을 사용하여 Android 장치에 대한 배포를 예약할 수 있습니다.

XenMobile 환경에서 FCM을 사용하면 iOS 장치의 APNs와 유사하게 Android 장치에서 실시간에 가까운 알림을 사용할 수 있습니다. FCM을 구성하면 XenMobile이 정책 업데이트, 선택적 초기화 등의 작업을 수행하기 위해 장치에 연결해야 하는 경우 XenMobile 서버가 FCM 서버로 알림 메시지를 보내 요청을 클라이언트 장치로 전달합니다. 장치에 FCM의 알림이 수신되면 장치가 추가 지침을 위해 다시 XenMobile에 연결합니다. 이 방법에는 타사 서버(Google)가 사용되므로 회사의 IT 부서 또는 Citrix 지원에서 제어할 수 없는 서비스 중단이 발생할 수 있습니다.

FCM 서비스에 등록하는 방법에 대한 자세한 내용은 XenMobile and Firebase Cloud Messaging (FCM) Configuration(XenMobile 및 FCM(Firebase 클라우드 메시징))을 참조하십시오.

Android에서 FCM을 사용하는 경우 다음 XenMobile 서버 속성에 유의하십시오. 다음 속성에는 Google Cloud Messaging의 이전 약어인 GCM이 사용됩니다.

  • GCM API Key(GCM API 키): Google Developers Console에서 만들어진 키입니다.
  • GCM Sender ID(GCM 보낸 사람 ID): Google Developers Console의 프로젝트 번호입니다.
  • GCM Registration ID TTL(GCM 등록 ID TTL): 장치 FCM 등록 ID를 갱신하기 전의 지연 기간(일)입니다. 기본값은 10입니다.
  • GCM Heartbeat Interval(GCM 하트비트 간격): 기본값은 6시간입니다.

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

데이터베이스를 정리하려면

중요:

테이블을 변경하기 전에 데이터베이스를 백업합니다.

  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;
    
  2. 이전의 3개 테이블에서 데이터를 삭제합니다.

    참고:

    기록 데이터가 테이블에 표시되지 않을 수 있습니다. 이 경우 실행을 건너뛰고 특정 테이블에 대한 쿼리를 잘라냅니다.

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    
  3. 교착 상태로 인해 차단되었던 SELECT 쿼리를 차단 해제합니다. 이 단계에서 추가 교착 상태가 처리됩니다.

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    
  4. 기본적으로 데이터베이스 정리는 세션 보존 및 감사 보존 데이터 유지를 위해 7일로 설정되며 사용자가 많은 경우 값이 증가합니다. 정리 값을 1일 또는 2일로 변경합니다. 서버 속성에서 다음 변경을 수행합니다.

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