В этой статье мы рассмотрим, как обеспечить высокую доступность (отказоустойчивость) фермы из веб серверов IIS (Internet Information Services) на Windows Server с помощью Microsoft Application Request Routing (ARR) и Network Load Balancing (NLB).
Итак, наша конфигурация отказоустойчивой фермы IIS будет выглядеть следующим образом:
-
web.contoso.com
(192.168.13.222) – DNS имя отказоустойчивого веб сервера, к которому должны обращаться клиенты. Это IP адрес будет доступен через кластер Microsoft NLB. В нашем случае NLB обеспечивать высокую доступность и балансировку нагрузки на веб сервера IIS; -
web1.contoso.com
(192.168.13.20) – первый сервер веб фермы IIS -
web2.contoso.com
(192.168.13.21) – второй сервер нода веб фермы IIS
Подготовка инфраструктуры для настройки высокой доступности сайтов IIS
Создайте в DNS запись для web.contoso.com и IP адреса. Можно создать DNS запись с помощью PowerShell:
Add-DnsServerResourceRecordA -Name web -IPv4Address 192.168.13.222 -ZoneName contoso.com
Установите роль IIS на обоих серверах в необходимой конфигурации, настройте ваш сайт/приложение. В нашем примере я использую IIS в минимальной конфигурации, достаточной для отдачи статической HTML страницы.
На обоих веб серверах я создал файл
c:\intepub\iis_ha.html
с простым HTML кодом. Для демонстрации высокой доступности и проверки переключений, HTML файл на каждом сервере содержит имя хоста, на котором он расположен (в продуктивной среде будет использоваться одинаковая конфигурация).
Затем я создал SSL сертификат для имени web.contoso.com и импортировал его в IIS на обоих серверах (в целях тестирования я использую самоподписанный сертификат, созданный с помощью PowerShell).
Данный сертификат привязан к сайтам на обоих серверах IIS на порту 443.
Установка ARR и URL Rewrite на IIS в Windows Server
Теперь нужно установить компонент ARR (Application Request Routing) на обоих серверах.
Скачайте Microsoft Application Request Routing 3.0 (x64) и запустите установку
requestRouter_amd64.msi
на обоих серверах (https://www.microsoft.com/web/downloads/platform.aspx).
Также скачайте и установите модуль IIS URL Rewrite 2.1. (https://www.iis.net/downloads/microsoft/url-rewrite).
Перезапустите консоль IIS. Теперь нужно создать ферму веб серверов IIS. Щелкните правой кнопкой по Server Farm и выберите Create Server Farm.
Задайте имя фермы
web.contoso.com
и добавьте в нее хосты
web1
и
web2
.
IIS предложит автоматически создать правила URL Rewrite для вашей фермы. Согласитесь с этим.
В настройках фермы IIS:
- В разделе Caching отключите кэширование (Enable disk cache=
False
); - В разделе Proxy измените значение Response buffer threshold на
0
; - В разделе Routing rules включите Use URL Rewrite и отключите Enable SSL offloading;
- На вкладке Health test укажите URL адрес для проверки
_http://web.contoso.com/
и установите Interval (seconds) =5
Теперь нужно создать правила перенаправления IIS. Перейдите в раздел URL Rewrite в IIS manager. Одно правило для фермы уже создано (
ARR_web.contoso.com_locadbalance_SS
L).
Добавьте новое условие (condition):
- Condition input:
{HTTP_HOST}
-
Matches the pattern
- Pattern:
web.contoso.com
Настройка общей конфигурации IIS
Теперь нужно сделать общую конфигурацию IIS для двух серверов. Для этого создайте общую сетевую папку на любом другом сервере (не используйте для размещения этой SMB шары сервера вашей фермы, в целях высокой доступности рекомендуется разместить эту папку на отказоустойчивом файловом кластере или DFS). Создайте сервисную учетную запись в AD (в нашем примере это
contoso\shared_iis
) и предоставьте ей полные права на эту папку.
Можно создать сетевую папку и назначить права с помощью PowerShell:
New-SmbShare -Name IISshared -Path D:\IISshared -FullAccess contoso\spb_admins -ChangeAccess contoso\shared_iis
На сервере, на котором вы настраивали ферму, перейдите в раздел IIS -> Shared Configuration. Выберите Export Configuration.
Укажите UNC путь к вашей сетевой папке и пароли для доступа шифрования (нужно использовать стойкий пароль). Нажмите Connect as и укажите учетные данные (contoso\shared_iis) для доступа к этой папке.
После того, как вы экспортировали вашу конфигурацию, нужно настроить оба сервера IIS на использовать общей конфигурации из сетевой папки.
Включите опцию Enable shared configuration, укажите UNC путь и учетные данные пользователя. Нажмите Apply. Если все прошло успешно, перезапустите IIS и аналогично настройте shared configuration на втором сервере.
Настройка NLB в Windows Server
Теперь нужно установить компонент NLB на обоих серверах и настроить кластер. Установите роли с помощью PowerShell:
Add-WindowsFeature nlb -IncludeManagementTools
Запустите консоль Network Load Balancing Manager (
nlbmgr.exe
) и создайте новый кластер для IP адреса 192.168.13.222.
Выберите Multicast режим для кластера.
Добавьте правило для порта TCP/443. Выберите:
- Filtering mode: Multiple host
- Affinity: Single
Добавьте второй сервер в NLB кластер.
Убедитесь, что у обоих хостов статус изменился Converged.
Также проверьте, как обрабатывают смену MAC адреса ваши физические коммутаторы.
Теперь можно проверить доступность сайта _https://web.contoso.com/iis_ha.html с клиентов. Если вы все настроили правильно, эта страница должна быть доступна.
В моем случае все сразу не взлетело. При переходе на целевую веб страницу, пул DefaultAppPool в IIS стал останавливаться с ошибкой Event ID 2307 от IIS-W3SVC-WP
The worker process for application pool 'DefaultAppPool' encountered an error 'Cannot read configuration file ' trying to read configuration data from file '\\?\<EMPTY>', line number '0'. The data field contains the error code.
Для решения проблемы пришлось выполнить такие команды на обоих серверах:
net stop WAS /y
rmdir /s /q C:\inetpub\temp\appPools
net start W3SVC
Также, отключите стандартное правило для IIS , что исправить ошибку:
HTTP Error 502.4 - Bad Gateway No appropriate server could be found to route the request.
В такой конфигурации веб сервис будет доступен для пользователей при недоступности любой из нод фермы IIS. В этом можно убедиться наглядно, потому что в зависимости от сервера, который обрабатывает вашу сессию вы будете получать свою веб страницу (мы в начале специально сделали разные файлы iis_ha.html).
Если отключить или приостановить один из целевых серверов, то ARR после выполнения Health Check (задержка 5 секунд) перенаправит вас на другой веб сервер.
Такая конфигурация обеспечит высокую доступность веб сервисов IIS, позволить автоматически перенаправить трафик в случае недоступности одного из серверов. Также благодаря NLB вы можете обеспечить распределение и балансировку нагрузки на сайты.
а что во всём этом решении делает ARR? Ведь NLB в принципе достаточно, что бы получить отказоустойчивость и robin round балансировку. Имеет смысл описать за что именно отвечает каждый компонент решения.
Я думаю, в такой конфигурации когда есть два сервера IIS на NLB заворачивать их ещё в ARR смысла нет никакого. По идее должна быть другая конфигурация. В Internal несколько IIS серверов, количество которых можно увеличивать под нагрузку, с внешним ресурсом на схд. В DMZ два сервера IIS в NLB c ARR, в котором указаны IIS сервера из Internal. Тогда получаем и отказоустойчивость в DMZ и балансировку в Internal, плюс повышенную безопасность.
ARR выполняет тестирование доступности страницы (health test). Представьте ситуацию, когда ваш IIS на одном из хостов упал и показывает какую-то ошибку. NLB про эту ошибку ничего не значает и продолжает отправлять пользователей на проблемный хост.
Статья не понравилась, увы. По сути контент типа next-next-next-ok. А на данном ресурсе хотелось бы более подробное погружение в суть технологий ARR и вероятно упоминание тонкостей NLB немножко глубже, чем «убедитесь, что Ваши свитчи поддерживают». А также их совмещения.
Тут тогда война и мир получится :). и так статья заняла прилично времени.
Мне было интересно рассмотреть принципиалные возможности.
«Также, отключите стандартное правило для IIS , что исправить ошибку»
Что за стандартное правило?
правило редиректа, которое создается автоматом
Пытаюсь сделать высокую доступность для серверов RDWeb, но не получается. По отдельности 2 сервера работают, но как только их объединяю в ферму, то при переходе по адресу открывается пустая страница с одной строкой из иероглифов. Не могу понять в чем дело. Вернул всё обратно, настроил оба сервера одинаково без объединения в ферму, и поднял NLB. В итоге всё работает, при недоступности одного сервера, перебрасывает на другой. Работоспособная ли это схема и чем она принципиально отличается от описанной в этой статье?
Зависит от того, на какой вопрос нужен ответ.
«Работоспособная ли это схема» — Да, раньше терминальные сервера так и объединяли через NLB кластер.
«Чем она принципиально отличается» — Всем, совсем другая архитектура.
Я бы задумался над тем, что ты теряешь при текущей схеме. Из основного на поверхности 1) У тебя в кластере только два сервера в режиме актив-пассив, а ферму можно масштабировать и все узлы работают в режиме актив-актив, сессии параллелятся. 2) в кластере тебе не нужна роли брокера, так как нечего параллелить. 3) в кластере тебе не нужна роль внешнего файлового сервера с профилями vhdx. Профили у тебя либо разные на серверах, либо через перенаправление профиля/папок. 4) для новой задачи с другим ПО/ресурсами/правами тебе придётся создать новый кластер, а в ферме добавить коллеrцию. 5) нет централизованного управления и мониторинга. 6) не будет ps скриптов по управлению всеми узлами через брокер.
Интересно, в статье https://learn.microsoft.com/en-us/iis/extensions/configuring-application-request-routing-arr/achieving-high-availability-and-scalability-arr-and-nlb для случая Active/Active выдан такой пассаж:
For the Affinity setting, select None. As mentioned above, the recommendation is to not use affinity in NLB since it will result in a better load distribution.
По сути точка отказа переходит с IIS на NLB и с точки зрения отказоустойчивости ничего не меняется. А как сделать NLB отказоустойчивым?
NLB обеспечиват доступность IIS при недоступности любого из хостов в группе. Почему это не будет отказоустойчивым решением?
Что будет, если NLB станет недоступен?
Если используется два NLB, стало быть есть две DNS A-записи, которые указывают на каждый из них. Чем это отличается от двух IIS на которые так же ссылается две DNS A-записи?
Вы не совсем поняли, как работает NLB.
Задача NLB обеспечить HA для MAC адреса и IP кластера (он же адрес сайта). Если один сервер недоступен, адрес будет активен на втором.
Авторы статьи опускают тонкости и моменты, что если есть уже готовые сайты, то для реализации технологии нужно чтобы одинаковые файлы хранились на обоих серверах, причём одинаковые в прямом смысле, а как быть с динамическим сайтом и его отображением. Более того у меня данная схема зависла на применении настроек, и я долго не мог понять почему, а оказывается, потому что я делал попытку создать ферму не с нуля, а уже на работающем веб сервере, где даже были публикации 1С. Что же касается последних, то там вообще при такой реализации начались мраки и лаги системы. Разумеется, спас бэкап, но печально, что в статье даются только поверхностные данные без углубления и рассмотрения возможных проблем.