VMware Identity Manager 3.2로 업그레이드한 후에 특정 설정을 구성해야 할 수 있습니다.

Elasticsearch

업그레이드가 완료되면 Elasticsearch에서 처리되는 기존 감사 및 검색 레코드를 새 형식으로 마이그레이션하기 위한 백그라운드 작업이 시작됩니다. 이 프로세스의 시작은 업그레이드가 완료된 이후 최대 1시간까지 지연될 수 있습니다. 일단 시작되면 일반적으로 빠르게 완료되지만, 레코드의 수에 따라 1-2시간까지 걸릴 수 있습니다.

마이그레이션 진행률에 관련된 메시지는 /opt/vmware/horizon/workspace/logs 디렉토리에 있는 analytics-service.log 파일에서 확인할 수 있습니다.

  • 마이그레이션이 시작되면 메시지 최신 감사 스키마 버전은 4입니다.가 로깅됩니다.

  • 각 날짜의 데이터가 마이그레이션되면 받은 문서 다시 색인화로 시작하는 메시지가 로깅됩니다.

  • 마이그레이션이 완료되면 메시지 감사 스키마 검사가 완료되었습니다.가 로깅됩니다.

마이그레이션이 완료될 때까지 이전 레코드는 전혀 사용할 수 없거나 일부만 사용할 수 있으므로, 대시보드 및 감사 보고서는 이전 레코드를 표시하지 않으며, 검색 및 자동 완성이 작동하지 않습니다. 그러나 새 감사 레코드는 마이그레이션과는 별개로 생성 및 처리되므로 대시보드 및 감사 보고서에 새 로그인 등이 표시됩니다. 새 감사 레코드가 감사 보고서에 표시되지 않으면 elasticsearch 클러스터의 상태를 확인합니다.

elasticsearch 클러스터의 상태를 확인하려면:

  1. 노드 중 하나로 ssh를 수행하고 다음 명령을 실행합니다.

    curl http://localhost:9200/_cluster/health?pretty

    "status" 필드가 "yellow" 또는 "green"인 경우 analytics-service 로그에 오류가 있는지 확인합니다. "status" 필드가 "red"인 경우 마스터 노드를 다시 시작해야 합니다.

  2. 마스터 노드를 다시 시작하려면:

    1. 다음 명령을 실행하여 마스터 노드를 확인합니다.

      curl http://localhost:9200/_cluster/state/master_node,nodes?pretty

    2. "master_node" 필드 값을 찾은 후 노드 목록에서 일치하는 값을 찾아 해당 IP 주소를 확인합니다. 예를 들어, 샘플 출력에서 마스터 노드는 IP 주소가 "1.1.1.2""Gq-ITVBKRJKz1816XqrRKw"입니다.

      {
         "cluster_name" : "horizon",
         "master_node" : "Gq-ITVBKRJKz1816XqrRKw",
         "nodes" : {
            "mzWHVMZuTXyFsO61NLpHnA" : {
               "name" : “Node1”,
               "transport_address" : “1.1.1.1:9300",
               "attributes" : { }
         },
         "Gq-ITVBKRJKz1816XqrRKw" : {
               "name" : “Node2”,
               "transport_address" : “1.1.1.2:9300",
               "attributes" : { }
         },
         "pkREX2D9R1a-lqf69PQMKQ" : {
               "name" : “Node3”,
               "transport_address" : “1.1.1.3:9300",
               "attributes" : { }
         }
      }
    3. 마스터 노드에 대해 ssh를 수행하고 elasticsearch를 다시 시작합니다.

      service elasticsearch restart

    4. elasticsearch가 다시 시작되면 클러스터 상태를 다시 확인합니다.

      curl http://localhost:9200/_cluster/health?pretty

      이 명령을 실행하면 처음에는 "yellow" 상태가 표시될 수 있습니다. “green” 상태가 표시될 때까지 이 명령을 다시 실행합니다.

역할 기반 액세스 제어

VMware Identity Manager 3.2에서는 역할 기반 액세스 제어가 도입되었습니다. 알려진 문제에 대해서는 VMware Identity Manager 3.2 릴리스 정보를 참조하십시오.

Citrix 통합

VMware Identity Manager 3.2의 Citrix 통합에서는 모든 외부 커넥터가 버전 2018.1.1.0(3.2 릴리스의 커넥터 버전)이어야 합니다.

또한 Integration Broker 3.2로 업그레이드해야 합니다. VMware Identity Manager 3.2 및 커넥터 2018.1.1.0에는 Integration Broker 3.2가 필요합니다.

이전 릴리스의 변경 사항

버전 3.1의 변경 사항

  • 버전 3.1부터는 사용자 그룹이 동기화되는 방식을 변경하는 새로운 기능이 도입되었습니다. 업그레이드 전에 이미 추가한 모든 사용자 그룹의 경우 VMware Identity Manager 3.1 이상으로 업그레이드한 후에 사용 권한이 할당되어 있는지 확인합니다. 업그레이드 후에 추가된 새 사용자 그룹은 리소스에 대한 권한이 부여되거나, 액세스 정책 규칙에 추가되거나, 버전 3.2부터는 그룹의 그룹 > 사용자 페이지에서 수동으로 동기화되기 전까지는 VMware Identity Manager 서비스와 동기화되지 않습니다.

    사용 권한이 모든 사용자로 설정되면, 업그레이드 후에 생성된 새 그룹의 사용자는 아직 동기화되지 않았으면 포함되지 않습니다. 새 그룹에 대한 사용 권한을 추가합니다.

    자세한 내용은 VMware Identity Manager 3.1로 업그레이드한 후 그룹 동기화 작동 방식을 참조하십시오.

  • Citrix 게시된 리소스를 VMware Identity Manager 3.1에 통합하는 경우 Integration Broker 3.1로 업그레이드합니다. VMware Identity Manager 3.1 및 VMware Identity Manager Connector 2017.12.1.0(3.1 릴리스의 Connector 버전)에는 Integration Broker 3.1이 필요합니다.

버전 3.0의 변경 사항

  • Citrix 게시된 리소스를 VMware Identity Manager에 통합하는 경우 Integration Broker 3.0으로 업그레이드합니다. VMware Identity Manager 3.0 및 VMware Identity Manager Connector 2017.8.1.0(3.0 릴리스의 Connector 버전)은 이전 버전의 Integration Broker와 호환되지 않습니다.

    표 1. 지원되는 버전

    VMware Identity Manager 또는 Connector 버전

    지원되는 Integration Broker 버전

    VMware Identity Manager 3.0

    3.0

    VMware Identity Manager Connector 2017.8.1.0(VMware Identity Manager 3.0 릴리스의 Connector 버전)

    3.0

    VMware Identity Manager 2.9.1 또는 이전 버전

    2.9.1 또는 이전 버전

    VMware Identity Manager Connector 2.9.1 또는 이전 버전

    2.9.1 또는 이전 버전

  • VMware Identity Manager에서 Horizon 데스크톱 및 애플리케이션을 통합하고 VMware Identity Manager 클러스터를 배포한 경우 Horizon 통합을 다시 구성해야 합니다.

    • Horizon 리소스를 저장 및 동기화한 기본 커넥터에서 모든 Horizon 포드를 제거했다가 다시 추가하고 저장 및 동기화를 클릭합니다.

    • Horizon 리소스 구성을 저장한 다른 커넥터에서 모든 Horizon 포드를 제거했다가 다시 추가하고 저장을 클릭합니다.

3.0 이전의 릴리스 변경 사항

  • VMware Identity Manager 2.9.1 이상의 대량 동기화 변경 사항

    이전 버전에서는 bulkSyncThreadLimitPerCPU=4라는 데이터베이스의 글로벌 구성 매개 변수를 통해 CPU당 4개의 스레드로 대량 동기화가 처리되었습니다.

    버전 2.9.1부터 대량 동기화 처리를 위한 스레드 수는 CPU를 기준으로 하지 않습니다. 이 수는 절대 수로, 기본적으로 노드의 CPU 수와 같습니다.

    많은 수의 사용자 및 그룹을 동기화하며, 업그레이드 후에 동기화가 느려지는 것이 느껴질 경우 bulkSyncSharedThreadCount라는 글로벌 구성 매개 변수를 설정하여 스레드 수를 지정할 수 있습니다.

    다음 REST API를 사용하여 데이터베이스에서 스레드 값을 설정한 후 노드를 다시 시작하여 변경 사항을 적용합니다.

    HTTP 요청:

    Operation: PUT
    URI: bulkSyncSharedThreadCount

    HTTP 헤더:

    Content-Type: application/vnd.vmware.horizon.manager.systemconfigparameter+json
    Accept: application/vnd.vmware.horizon.manager.systemconfigparameter+json
    Authorization: HZN <operator token>

    요청 본문(예로 8개 스레드 포함):

    {
        "name": "bulkSyncSharedThreadCount",
        "values": {
            "values": [
                "8"
            ]
        }
    }

  • 새 포털 사용자 인터페이스를 사용하도록 설정합니다.

    1. 관리 콘솔에서 카탈로그 탭의 화살표를 클릭하고 설정을 선택합니다.

    2. 왼쪽 창에서 신규 최종 사용자 포털 UI를 선택하고 새 포털 UI 사용을 클릭합니다.

  • 2개의 노드가 있는 페일오버용 VMware Identity Manager 클러스터를 설정한 경우 세 개의 노드로 업데이트하는 것이 좋습니다. 이는 VMware Identity Manager 장치에 포함된 검색 및 분석 엔진인 Elasticsearch의 제한 때문입니다. 두 개의 노드를 계속 사용할 수 있지만 Elasticsearch와 관련된 몇 가지 제한 사항을 알아야 합니다. 자세한 내용은 VMware Identity Manager 설치 및 구성에서 “장애 및 이중화 구성”을 참조하십시오.

  • TLS(전송 계층 보안) 프로토콜 1.0은 VMware Identity Manager에서 기본적으로 사용하지 않도록 설정됩니다. TLS 1.1 및 1.2는 지원됩니다.

    외부 제품 문제는 TLS 1.0이 사용되지 않도록 설정되어 있을 때 발생하는 것으로 알려져 있습니다. TLS 1.1 또는 1.2를 사용하도록 기타 제품 구성을 업데이트하는 것이 좋습니다. 그러나 이러한 제품이 TLS 1.0에 종속되는 경우 기술 자료 문서 2144805의 지침에 따라 VMware Identity Manager에서 TLS 1.0을 사용하도록 설정할 수 있습니다.