Skip To Content

Конфигурация развертывания с одним сервером высокой доступности (active-active)

В этом разделе

Данная конфигурация – вариант развертывания с одним сервером высокой доступности (active-passive), при котором балансировка нагрузки всегда настроена на распределение по всем сайтам. В данной конфигурации нет ожидающих сайтов.

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

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

Развертывание active-active с двумя сайтами
Развертывание active-active с двумя сайтами Администраторы подключаются к каждому сайту отдельно. Сайты имеют одинаковые копии директорий сервера и хранилища конфигураций.

На высшем уровне идея архитектуры active-active с одним компьютером – клонирование сайта с одним компьютером и размещение его независимых экземпляров за балансировщиком нагрузки. Технически эта конфигурация не может быть описана как сайт с несколькими машинами, поскольку каждый из сайтов независим от другого, состоит из одного ГИС-сервера и имеет собственные локальные хранилища конфигурации и директории сервера.

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

ГИС-сервер, директории сервера и хранилище конфигураций

Каждый ГИС-сервер должен иметь собственное локальное хранилище конфигураций, кэши, задания и системные директории. Это приведет к максимальной производительности и сведет к минимуму взаимозависимости. С другой стороны, выходная директория (или директории) должна быть доступна с каждого сайта. Более подробно см. ниже раздел Другие рекомендации.

Данные

Используйте те же соображения, которые изложены в разделе Конфигурация развертывания высокой доступности с одним активным сервером (active-passive).

Обратный прокси-сервер

В этой конфигурации требуется сторонний балансировщик нагрузки. Как минимум, этот компонент будет использоваться для распределения нагрузки по всем сайтам. Балансировщики нагрузки имеют разные настройки распределения нагрузки, например, круговую и с наименьшим числом подключений. Выбор правильного распределения нагрузки отразится на размещаемых сервисах и их способах использования. Балансировщики нагрузки обычно используют различные опции обработки ошибок. К примеру, вы можете применить правила в своем балансировщике нагрузки, которые предотвратят пересылку запросов на компьютер, недоступный из-за ошибки сети или аппаратного обеспечения, или недоступности сервиса ArcGIS Server. При использовании сайтов с одним компьютером, как показано в этой модели, запросы, посылаемые на конкретный компьютер, обрабатываются именно им.

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

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

Использование ArcGIS Web Adaptor не является обязательным и обычно требуется, только если вы хотите получить преимущество аутентификации веб-уровня. Вы можете настроить его на том же компьютере, где и ГИС-сервер, либо на отдельном компьютере. В любом случае, при работе с ArcGIS Web Adaptor необходимо настроить отдельный ArcGIS Web Adaptor для каждого сайта.

Другие соображения

Поддержка синхронности сервисов сайтов

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

Есть несколько способов поддержки синхронизации сервисов ArcGIS Server через основные и резервные сайты:

  • Написание скриптов: ArcGIS Server включает административный REST API, который может использоваться для написания скриптов с административными задачами, такими как публикация сервисов и изменение настроек их безопасности. Вы можете написать собственные скрипты, чтобы внести изменения во все участвующие в развертывании ГИС-серверы.Написание скриптов особенно полезно в случае необходимости внесения небольших улучшений, к примеру, изменения безопасности сервиса или его перезаписывание. Подробнее см. в разделе Написание скриптов администрирования ArcGIS for Server.
  • Виртуализация: Если вы работаете в виртуальной среде, можно создать и использовать для запуска новых сайтов шаблоны виртуальных компьютеров. Каждый шаблон будет иметь копию данных для ГИС-сервисов (если не используется база данных). Шаблон будет также содержать опубликованные и настроенные сервисы. Если необходимы изменения, например, добавления или обновления имеющихся сервисов, можно создать новый шаблон для последующего запуска новых виртуальных машин, которые заменят имеющийся пул ГИС-серверов под балансировщиком загрузки. Шаблоны виртуальных компьютеров могут также использоваться для быстрого восстановления старых ГИС-серверов.

Рекомендуемая процедура применения изменений к сайтам развертывания:

  1. Административные изменения будут вначале применены к сайту, находящемуся в режиме ожидания. Например, вы можете добавить новый сервис и изменить безопасность другого сервиса на сайте, не обрабатывающем запросы. Это обеспечит полное отсутствие влияния на приложения, использующие ваш основной сайт.
  2. Настройте вручную свой балансировщик нагрузки для обработки всех запросов резервным сайтом, для которого были сделаны изменения.
  3. Сделайте ряд изменений в пустом сайте.
  4. Настройте балансировщик нагрузки так, чтобы запросы направлялись обратно на основной сайт и оставьте резервный сайт в режиме ожидания.

Изменения в вашем сайте в описанной выше процедуре можно применить вручную с помощью ArcGIS Server Manager, скриптов и виртуальных образов.

Предоставление доступа к выходной директории

Некоторые сервисные операции ArcGIS Server ссылаются на ресурсы в одной или нескольких выходных директориях. Например, картографические сервисы могут записывать изображения в выходную директорию и ссылаться на данные изображения посредством URL-адреса в ответе на запрос. Для того чтобы клиенты успешно получили изображение, все сайты в конфигурации active-active должны ссылаться на одну выходную директорию. Это может быть достигнуто путем размещения выходных директории на сетевом ресурсе и предоставлением открытого доступа к ним с сайтов.

Далее приведен список операций сервисов, которые будут использовать выходные директории:

Асинхронное выполнение сервисов геообработки

Сервисы геообработки ArcGIS Server поддерживают два режима выполнения: синхронный и асинхронный. Синхронное выполнение следует шаблону запрос-ответ на уровне сети и полностью поддерживается в конфигурации active-active. Асинхронное выполнение следует шаблону запрос-ответ с сохранением состояний и является опцией по умолчанию. Для того, чтобы использовать асинхронное выполнение в конфигурации active-active, вы должны будете рассмотреть следующее:

  • При выполнении задания асинхронной обработки вы получаете ID задания, соответствующий задаче и ее выходным данным. Только сайт ArcGIS Server, принимающий исходный запрос, может распознать этот ID. По этой причине, конфигурация active-active требует определения сходства в балансировщике нагрузки (также известного как липкие сессии) для асинхронного выполнения. Не все балансировщики нагрузки поддерживают липкие сессии. Липкие сессии также требуют использования дополнительной логики от балансировщика нагрузки и потенциально могут препятствовать производительности вашего сайта под очень большой нагрузкой. Всегда обращайтесь к поставщику вашего балансировщика нагрузки, чтобы понять последствия включения липких сессий.
  • Если ваш сервис геообработки не использует картографические сервисы для отображения выходных данных и не определено выходных данных типа 'Файл', то для сервисов геообработки можно выбрать синхронное выполнение. Не требуется никаких липких сессий в балансировщике нагрузки.

Использование безопасности на уровне токенов

При использовании аутентификации на уровне токенов, которую также называют аутентификацией на уровне ГИС, важно, чтобы все сайты конфигурации использовали один и тот же ключ токена. В противном случае токены, созданные для одного компьютера, не подойдут для применения на другом. Чтобы узнать о дублировании общих ключей токенов для нескольких сайтов, обратитесь к разделам О токенах ArcGIS и Редактирование настроек токенов в Manager.

Достоинства

  • Концептуально простой. Минимальные взаимозависимости между ГИС-серверами позволяют легко заменять устаревшие и неисправные машины, применять обновления, добавлять и удалять машины из пула ГИС-серверов по мере необходимости, не прерывая сервисы или запросы.
  • Если листы карты хранятся локально на каждой машине, подобная конфигурация обеспечит неплохое увеличение производительности по сравнению с сайтами с несколькими машинами. На самом деле такая конфигурация идеально подходит, если вашей целью является увеличение вместимости кэшированных картографических сервисов.

Недостатки

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