Skip To Content

Интеграция портала с обратным прокси или балансировщиком нагрузки

Обратный прокси-сервер или балансировщик нагрузки – это устройство, обычно развертываемое в пределах пограничной сети (т.н. демилитаризованной зоны [DMZ] или промежуточной подсети), которое обрабатывает запросы из Интернета и перенаправляет их на компьютеры внутренней сети. Перенаправляя запросы, обратный прокси-сервер маскирует идентичность компьютеров, находящихся за брандмауэром организации, защищая таким образом внутренние компьютеры от прямых атак со стороны пользователей интернета. На обратном прокси-сервере можно реализовать дополнительные функции безопасности, позволяющие еще больше защитить внутреннюю сеть от пользователей извне.

Если вы используете обратный прокси-сервер или балансировщик нагрузки с функцией проверки работоспособности, рекомендуем вам использовать точку доступа проверки работоспособности Portal for ArcGIS, чтобы определить, может ли портал получать запросы. Это используется для быстрого определения наличия на сайте аппаратного или программного сбоя. Дополнительные сведения см. в разделе Проверка работоспособности в ArcGIS REST API.

Внимание:

Специфические настройки, описанные в этом разделе, должны быть применены перед интеграцией любого сайта ArcGIS Server с вашим порталом ArcGIS Enterprise. Добавление псевдонима DNS или обратного прокси-сервера после интеграции сайта ArcGIS Server с порталом не поддерживается. Если необходимо изменить имя хоста в URL организации, свяжитесь с Esri Professional Services или другими консалтинговыми компаниями для получения указаний.

Отмена интеграции сайта ArcGIS Server приведет к ряду существенных изменений, отменить это действие будет затруднительно. Для дополнительной информации см. Администрирование интегрированного сервера.

Типы балансировщиков нагрузки

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

Действия по балансировке нагрузки часто различаются уровнем модели взаимодействия открытых систем (OSI), на котором они работают. При работе над интеграцией существующей технологии балансировки нагрузки важно определить, какой тип будет реализовываться, поскольку от этого зависит общая архитектура развертывания.

Балансировщики нагрузки уровня 3/4 иногда называют балансировщиками нагрузки на уровне сети или пакетов. Эти балансировщики нагрузки обычно не проверяют входящий трафик, а вместо этого направляют входящие пакеты TCP / UDP к внутренним целям. Новые реализации допускают SSL-терминацию на балансировщике нагрузки, но клиентский сеанс SSL обычно устанавливается с внутренним целевым сервером или серверами.

Балансировщики нагрузки уровня 7 иногда называют балансировщиками нагрузки с поддержкой приложений. Эти балансировщики нагрузки проверяют входящие сообщения и могут принимать решения, связанные с маршрутизацией, учитывая несколько факторов, а также изменять содержимое этих сообщений перед их проксированием на конечную цель или конечные объекты. Балансировщики нагрузки уровня 7, использующие HTTPS, прервут SSL-соединение с клиентом и повторно зашифруют этот трафик перед проксированием запросов к внутренним HTTPS-целям.

Подготовка обратного прокси-сервера и балансировщика нагрузки

Перед добавлением Portal for ArcGIS к обратному прокси-серверу организации, необходимо выполнить следующие шаги:

  • Настройте HTTPS (HTTP и HTTPS или только HTTPS) на обратном прокси-сервере. Portal for ArcGIS по умолчанию выполняет коммуникацию по HTTPS. Обратитесь к документации к прокси-серверу, чтобы узнать о настройке HTTPS.
  • Настройте ArcGIS Web Adaptor для работы с порталом, если ваш портал будет использовать Встроенную аутентификацию Windows. Для этого Portal for ArcGIS необходимо использовать ArcGIS Web Adaptor, это позволит обратному прокси-серверу правильно работать с порталом. Подробные инструкции см. в разделе Настройка ArcGIS Web Adaptor.
Примечание:

Portal for ArcGIS не поддерживает протокол SSL-разгрузки через обратный прокси-сервер / балансировщик нагрузки. Поэтому если ваша конфигурация использует обратный прокси-сервер, он должен направить трафик либо к ArcGIS Web Adaptor, либо напрямую к Portal for ArcGIS через HTTPS.

Примечание:

Если вы не используете ArcGIS Web Adaptor в своем развертывании, убедитесь, что имя контекста обратного прокси-сервера переходит только на один уровень URL глубже. Например, у вас может быть адрес URL обратного прокси-сервера, такой как https://proxy.domain.com/enterprise, но у вас не может быть адреса URL обратного прокси-сервера типа https://proxy.domain.com/myorg/enterprise.

Убедитесь, что прокси-сервер поддерживает кодирование gzip и настроен на поддержку заголовка Accept-Encoding. Этот заголовок поддерживает сжатие ответов HTTP 1.1 с помощью кодирования gzip. Например, если заголовок разрешен, запрос загрузки в Map Viewer Classic возвратит в браузер сжатый ответ, имеющий объем, равный 1,4 МБ. Если же заголовок не разрешен или игнорируется, запрос возвратит в браузер несжатый ответ, имеющий объем, равный 6,8 МБ. Если скорость вашей сети невелика, Map Viewer Classic может долго загружаться, если ответы не сжимаются. Esri рекомендует разрешить использование этого заголовка во время настройки обратного прокси-сервера.

Балансировщик нагрузки уровня 3/4

Балансировщик нагрузки должен прослушивать порт HTTPS по умолчанию и передавать трафик ArcGIS Web Adaptor либо непосредственно на машину Portal for ArcGIS, либо на машины через порт 7443. При завершении клиентских SSL-сеансов на внутреннем веб-сервере Portal for ArcGIS убедитесь, что сертификат SSL, предоставленный этим веб-сервером, действителен как для псевдонима DNS, так и для полного доменного имени компьютера или компьютеров на сайте. Это позволит избежать проблем с доверием к сертификату. Этого обычно можно добиться путем использования альтернативных имен субъекта в сертификате SSL.

Примечание:

При использовании ArcGIS Web Adaptor для сайта можно использовать контекст по умолчанию (/arcgis). При интеграции нескольких сайтов Portal for ArcGIS b ArcGIS Server в один и тот же балансировщик нагрузки уровня 3/4 необходимо использовать уникальную запись DNS для каждого сайта и идентификацию имени сервера (SNI), используемую для маршрутизации трафика к соответствующим конечным объектам.

Балансировщик нагрузки уровня 7

В настройках балансировщика задайте заголовок X-Forwarded-Host для имени хоста псевдонима DNS сайта. Portal for ArcGIS ожидает этот параметр в заголовке, посланном обратным прокси-сервером, и возвращает запросы, соответствующие URL-адресу обратного прокси-сервера. Если вы не используете ArcGIS Web Adaptor с порталом, убедитесь, что установлен заголовок Host в соответствии с именем хоста компьютера, на котором установлен Portal for ArcGIS.

Подсказка:

Вы можете использовать точку доступа machines в ArcGIS Portal Administrator Directory для просмотра имени хоста компьютера, где работает Portal for ArcGIS.

Например, запрос к конечной точке Portal for ArcGIS REST (https://dnsalias.domain.com/arcgis/sharing/rest) будет возвращен клиенту как тот же URL. Если это свойство не задано, Portal for ArcGIS может возвратить URL внутреннего компьютера, на который был направлен запрос (например, https://portal.domain.com/arcgis/sharing/rest вместо https://dnsalias.domain.com/arcgis/sharing/rest). Это проблематично, т.к. клиенты не смогут получить доступ к этому URL-адресу (обычно выглядит как ошибка 404 в браузере). Также, клиент получит доступ к некоторым сведениям о внутреннем компьютере.

Вместе с заголовком X-Forwarded-Host, балансировщик нагрузки должен иметь возможность отправлять перенаправления (коды ответов HTTP 301 или 302). Все заголовки Location нужно перезаписать в балансировщике нагрузки, чтобы гарантировать, что полное доменное имя (FQDN) и контекст ответа соответствуют значению WebContextURL портала.

Добавление портала

В следующих разделах описывается, как добавить Portal for ArcGIS к обратному прокси-серверу вашей организации.

Балансировщик нагрузки уровня 3/4: Добавление компьютеров ArcGIS Web Adaptor или Portal for ArcGIS к конфигурации балансировщика нагрузки

Поскольку проксирование трафика к внутренним целям будет происходить через TCP, в конфигурацию балансировщика нагрузки должны быть добавлены компьютер или компьютеры для каждого сайта. При использовании ArcGIS Web Adaptor внутренние целевые объекты должны указывать на порт веб-сервера или серверов (обычно 443 или 8443), на которых размещается веб-адаптер или адаптеры. При проксировании трафика напрямую на Portal for ArcGIS серверные цели должны указывать на порт 7443 на каждом компьютере сайта.

Балансировщик нагрузки уровня 7: добавление компьютеров ArcGIS Web Adaptor и Portal for ArcGIS в директивы прокси-сервера

После настройки ArcGIS Web Adaptor на работу с Portal for ArcGIS, ArcGIS Web Adaptor можно использовать с обратным прокси-сервером вашей организации, добавив эти компоненты непосредственно в директивы прокси. Например, если вы используете Apache в качестве обратного прокси-сервера, вам потребуется добавить ArcGIS Web Adaptor в директивы ProxyPass в файл конфигурации веб-сервера Apache httpd.conf:

ProxyPass /webadaptorname https://webadaptorhost.domain.com/webadaptorname
ProxyPassReverse /webadaptorname https://webadaptorhost.domain.com/webadaptorname

Директивы ProxyPass должны соответствовать имени ArcGIS Web Adaptor (/webadaptorname в примере выше). Если перед Portal for ArcGIS не используется ArcGIS Web Adaptor, добавьте следующие директивы, где /context - это выбранный путь верхнего уровня URL:

ProxyPass /context https://portal.domain.com:7443/arcgis
ProxyPassReverse /context https://portal.domain.com:7443/arcgis

Настройка портала с обратным прокси или балансировщиком нагрузки

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

Задание свойства WebContextURL

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

  1. Откройте веб-браузер и войдите в ArcGIS Portal Directory в качестве участника с ролью администратора по умолчанию в вашей организации портала. Адрес URL имеет формат https://portal.domain.com:7443/arcgis/portaladmin.
  2. Щелкните Система > Свойства > Обновить свойства.
  3. В диалоговом окне Обновить свойства системы вставьте следующий JSON, заменив собственный URL-адрес обратного прокси или псевдоним DNS тем, который видят пользователи за пределами брандмауэра вашей организации.
    {
       "WebContextURL": "https://dnsalias.domain.com/portal"
    }
    Примечание:

    Portal for ArcGIS поддерживает только один DNS.

    Примечание:

    Вы не можете использовать порт, отличный от стандартного (то есть порт, не являющийся 443) при настройке свойства WebContextURL.

  4. Щелкните Обновить свойства.

Повторное выполнение административных задач

Теперь, когда настройка обратного прокси сервера с вашим порталом завершена, вы будете входить на свой портал через URL-адрес обратного прокси-сервера, а не по URL-адресу ArcGIS Web Adaptor. Все, что вам будет доступно на веб-сайте портала или в ArcGIS Portal Directory, вы будете получать через URL обратного прокси-сервера.

Следующие административные задачи необходимо повторить, используя URL обратного прокси-сервера:

Если ранее вы добавили защищенные сервисы как элементы вашего портала, то исходные элементы необходимо удалить и добавить снова. Это необходимо сделать, потому что исходные элементы используют URL-адрес ArcGIS Web Adaptor, а не URL обратного прокси-сервера. Инструкции см. в разделе Подключение к защищенным сервисам.

После настройки обратного прокси-сервера на работу с порталом, может потребоваться дополнительная настройка. Например, если операции или запросы в развертывании не работают с возвратом ошибки, указывающей на превышение времени ожидания, возможно значение времени ожидания на прокси-сервере слишком мало. Для исправления этой ошибки, увеличьте время ожидания, что позволит выполняться длительным запросам, например, интегрированного сервера.