Настройка после обновления

После обновления VMware Identity Manager до версии 3.2.0.1, возможно, потребуется настроить определенные параметры.

Программа улучшения качества программного обеспечения

Данный продукт участвует в Программе улучшения качества программного обеспечения от VMware («CEIP»). Дополнительная информация о собранных в CEIP данных и целях их использования для VMware изложена в разделе Trust & Assurance Center на странице https://www.vmware.com/ru/solutions/trustvmware/ceip.html.

После обновления VMware Identity Manager до версии 3.2.0.1 и входа в консоль администрирования на баннере появится параметр Присоединиться к программе улучшения качества программного обеспечения VMware. Если вы предпочитаете не участвовать в CEIP от VMware для данного продукта, то снимите флажок ниже и нажмите кнопку ОК.

Баннер будет отображаться, пока вы не нажмете кнопку ОК или не закроете его. Вы можете присоединиться к программе CEIP или отказаться от участия в ней в любое время. Для этого перейдите на страницу Настройки устройства > Телеметрия.

Перенос Elasticsearch

Примечание:

Данная информация относится к обновлению с предыдущих версий до версии 3.2.x и неприменима при обновлении с версии 3.2 до 3.2.0.1.

Механизм поиска и анализа Elasticsearch внедрен в VMware Identity Manager и используется для аудита, создания отчетов и поиска. В VMware Identity Manager 3.2.x входит Elasticsearch 2.3.5, в то время как предыдущие версии включали Elasticsearch 1.75. При обновлении VMware Identity Manager до версии 3.2.x записи Elasticsearch переносятся в новую версию.

По завершении обновления VMware Identity Manager запустится фоновое задание по переносу существующих записей аудита и поиска, которые выполняются с помощью Elasticsearch, в новый формат. Запуск этого процесса можно отложить максимум на один час с момента завершения обновления. Запущенный процесс обычно быстро завершается, но может занять и 1–2 часа в зависимости от количества записей.

Сообщения о ходе выполнения переноса можно просмотреть в файле analytics service.log, который находится в каталоге /opt/vmware/horizon/workspace/logs.

• После запуска переноса сообщение The latest Audit schema version is 4. будет занесено в журнал.

• Каждый раз при переносе данных в журнал будут заноситься сообщения, начинающиеся с текста Re-indexing documents from .

• После завершения переноса сообщение Audit schema check completed. будет занесено в журнал.

До завершения переноса записи будут недоступны или будут доступны только некоторые старые записи. Поэтому на панели управления и в отчете аудита не будут отображаться старые записи, а также не будут работать поиск и автозаполнение. Однако новые записи аудита будут создаваться и обрабатываться вне зависимости от выполнения переноса, поэтому на панели управления и в отчете аудита должны отображаться новые имена для входа и т. д. Если новые записи аудита не отображаются в отчете аудита, проверьте работоспособность кластера 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-адрес. Например, в этом случае главным является узел "Gq-ITVBKRJKz1816XqrRKw" с IP-адресом "1.1.1.2":

      {
         "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” .

Конфликты сопоставления Elasticsearch

Elasticsearch 2.3.5 в VMware Identity Manager 3.2.x не запускается, если в каких-либо индексах имеются конфликты сопоставления. Если индексы, имеющие конфликты сопоставления, не удалены перед обновлением, следуя инструкциям в процедуре Проверка наличия конфликтов сопоставления Elasticsearch, Elasticsearch не запустится.

В файле журнала Elasticsearch (/opt/vmware/elasticsearch/logs/horizon.log) содержится следующее сообщение для затронутых индексов.

[2018-04-24 13:13:41,722][ERROR][bootstrap                ] Guice Exception: java.lang.IllegalStateException: unable to upgrade the mappings for the index [v3_2018-03-16], reason: [Mapper for [tenantId] conflicts with existing mapping in other types:

Чтобы устранить эту проблему, удалите индексы вручную со всех узлов VMware Identity Manager.

1. Убедитесь, что служба Elasticsearch остановлена на всех узлах.

   service elasticsearch stop

2. На всех узлах удалите с диска файлы индексов.

   rm -rf /db/elasticsearch/horizon/nodes/0/indices/<INDEX_NAME>

3. Перезапустите подсистему Elasticsearch на всех узлах.

   service elasticsearch start

Поиск не работает после обновления

Если после обновления отчеты аудита создаются и панели мониторинга работают, но поиск не осуществляется, индекс поиска может быть неверен.

Во время обновления все пользователи, группы и приложения повторно индексируются с новым индексом поиска. В случае возникновения проблем, связанных с Elasticsearch, таких как ошибка конфликтов сопоставления, повторная индексация может быть выполнена не надлежащим образом.

Чтобы устранить эту проблему, вручную принудительно выполните повторную индексацию либо с нулевым параметров времени простоя, используя значение файла cookie HZN, либо с помощью параметра времени простоя, изменив значение непосредственно в базе данных.

Чтобы вручную принудительно повторно индексировать с помощью нулевого параметра времени простоя, выполните следующие действия.

1. Войдите в службу VMware Identity Manager в качестве администратора, то есть администратора по умолчанию, который создается в системном домене при первой установке VMware Identity Manager.

2. Получите значение файла cookie HZN из кэша файлов cookie в браузере.

   Например, в Firefox:

   1. Перейдите на вкладку Настройки > Приватность и защита.

   2. В разделе История щелкните ссылку удалить отдельные куки.

   3. В диалоговом окне «Куки» найдите HZN.

   4. Выберите файл cookie HZN в результатах поиска, а затем скопируйте его значение в поле Содержимое.

3. SSH в любой из узлов VMware Identity Manager и сделайте следующий вызов REST, заменив <cookie_value> значением HZN файла cookie, полученным из браузера.

   /usr/local/horizon/bin/curl -k -XPUT -H "Authorization:HZN <cookie_value>" -H "Content-Type: application/vnd.vmware.horizon.manager.systemconfigparameter+json" https://localhost/SAAS/jersey/manager/api/system/config/SearchCalculatorMode -d '{ "name": "SearchCalculatorMode", "values": { "values": ["REINDEX"] } }'

Чтобы вручную принудительно повторно индексировать с помощью параметра времени простоя, выполните следующие действия.

1. Остановите службу VMware Identity Manager на всех узлах.

   service horizon-workspace stop

2. Выполните следующую команду на всех узлах.

   hznAdminTool reindexSearchData

3. Перезапустите службу VMware Identity Manager на всех узлах.

   service horizon-workspace start

Чтобы убедиться, что индексация запущена повторно, в файле /opt/vmware/horizon/workspace/logs/horizon.log должно сообщение, подобное приведенному ниже.

com.vmware.horizon.search.SearchCalculatorLogic - Keep existing index. Search calculator mode is: REINDEX

Повторная индексация завершится в течение нескольких минут.

Файлы конфигурации Log4j

Если какие-либо файлы конфигурации log4j были изменены в экземпляре VMware Identity Manager, новые версии этих файлов не устанавливаются автоматически во время обновления. После обновления журналы, управление которыми выполняется через эти файлы, не будут работать.

Чтобы устранить эту проблему, выполните следующие действия.

1. Выполните вход на виртуальное устройство.

2. Найдите файлы log4j с суффиксом .rpmnew.

   find / -name "**log4j.properties.rpmnew"

3. Для каждого найденного файла скопируйте новый файл в соответствующий старый файл log4j без суффикса .rpmnew.

Настройка службы кэширования на устройствах резервных центров обработки данных

Если настроить резервный центр обработки данных, то для экземпляров VMware Identity Manager в нем будет настроен доступ только для чтения с записью "read.only.service = true" в файле //usr/local/horizon/conf/runtime-config.properties. После обновления такого устройства, служба не будет запускаться.

Чтобы устранить эту проблему, выполните следующие действия.

1. Выполните вход на виртуальное устройство.

2. Добавьте следующую строку в файл /usr/local/horizon/conf/runtime-config.properties.

   cache.service.type = ehcache

3. Перезапустите службу.

   service horizon-workspace restart

Управление доступом на основе ролей

Функция управления доступом на основе ролей была представлена в VMware Identity Manager 3.2. Дополнительные сведения по известным проблемам см. в разделе Информация о версии VMware Identity Manager 3.2.

Интеграция с Citrix

Для интеграции с Citrix в VMware Identity Manager 3.2 все внешние соединители должны быть версии 2018.1.1.0 (версия соединителя в выпуске 3.2) или более поздней версии.

Кроме того, необходимо обновить Integration Broker до версии 3.2 или более поздней версии.

Изменения в предыдущих версиях

Изменения в версии 3.1

• Начиная с версии 3.1, добавлена функция, меняющая способ синхронизации групп пользователей. После обновления VMware Identity Manager до версии 3.1 или более поздней версии убедитесь в том, что для всех групп пользователей, которые были добавлены до обновления, назначены права. Новые группы пользователей, добавленные после обновления, не синхронизируются со службой VMware Identity Manager, пока группе не будут предоставлены права на использование ресурса, добавленного в правило политики доступа, или, начиная с версии 3.2, синхронизируются вручную на странице Группа > Пользователи.

  Если права заданы для ВСЕХ ПОЛЬЗОВАТЕЛЕЙ, пользователи новых групп, которые созданы после обновления, не будут включены, если эти пользователи еще не были синхронизированы. Добавьте права для новых групп.

  Дополнительные сведения см. в разделе Как работает синхронизация групп после обновления до VMware Identity Manager 3.1.

• При интеграции опубликованных ресурсов Citrix с VMware Identity Manager 3.1 выполните обновление Integration Broker до версии 3.1. Эта версия требуется для VMware Identity Manager 3.1 и соединителя VMware Identity Manager 2017.12.1.0 (версия соединителя в выпуске 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) не совместимы с более ранними версиями Integration Broker.

  Таблица 1. Поддерживаемые версии

  Версия VMware Identity Manager или соединителя	Поддерживаемая версия Integration Broker
  VMware Identity Manager 3.0	3.0
  VMware Identity Manager Connector 2017.8.1.0 (версия соединителя в выпуске VMware Identity Manager 3.0)	3.0
  VMware Identity Manager 2.9.1 или более ранних версий	2.9.1 или более ранних версий
  Соединитель VMware Identity Manager Connector 2.9.1 или более ранних версий	2.9.1 или более ранних версий

• При интеграции компьютеров и приложений Horizon с VMware Identity Manager и развертывании кластера VMware Identity Manager необходимо настроить интеграцию Horizon заново.

  • Для основного соединителя удалите все модули Horizon из локации, куда сохранялись и синхронизировались ресурсы Horizon, добавьте их заново и нажмите Сохранить и синхронизировать.

  • Для остальных соединителей удалите все модули Horizon из локации, куда сохранялась настройка ресурсов Horizon, добавьте их заново и нажмите Сохранить и синхронизировать.

Изменения в выпусках до версии 3.0

• Изменение массовой синхронизации в VMware Identity Manager 2.9.1 и более поздних версиях

  В более ранних версиях массовая синхронизация обрабатывалась четырьмя потоками в каждом процессоре с использованием глобального параметра конфигурации в базе данных bulkSyncThreadLimitPerCPU=4.

  Начиная с версии 2.9.1, количество потоков при массовой синхронизации не основывается на процессоре. Это абсолютное число, совпадающее с числом процессоров, по умолчанию используемых на узле.

  Если во время синхронизации большого количества пользователей и групп вы заметили, что скорость синхронизации снизилась после обновления, можно указать количество потоков путем настройки глобального параметра конфигурации с именем 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. Выберите Новый пользовательский интерфейс портала для конечных пользователей в области слева и щелкните Включить пользовательский интерфейс нового портала.

• Если настроен кластер VMware Identity Manager для аварийного переключения с двумя узлами, рекомендуется обновить его до версии с тремя узлами. Это связано с ограничением Elasticsearch (подсистемы поиска и анализа, встроенной в устройство VMware Identity Manager). Можно продолжать использовать два узла, но при этом следует учитывать ряд ограничений, связанных с Elasticsearch. Дополнительные сведения см. в разделе «Настройка аварийного переключения резервирования» в руководстве по установке и настройке VMware Identity Manager.

• По умолчанию в VMware Identity Manager протокол TLS 1.0 отключен. В этой версии поддерживаются протоколы TLS 1.1 и 1.2.

  Известно, что при отключенном протоколе TLS 1.0 возникают проблемы с внешними продуктами. Рекомендуется обновить конфигурации других продуктов, чтобы в них использовался протокол TLS 1.1 или 1.2. Однако если для этих продуктов используется протокол TLS 1.0, можно включить TLS 1.0 в VMware Identity Manager, следуя инструкциям, приведенным в статье базы знаний 2144805.