Как использовать pfSense для балансировки нагрузки веб‑серверов

Кратко

Кроваво просто: настроить pfSense 2.0 как балансировщик HTTP‑трафика между двумя и более Apache‑серверами. В статье показаны требования, пошаговая настройка мониторинга, пула серверов и виртуального IP, тесты приёмки, сценарии отказа и рекомендации по отказоустойчивости.

Введение

В этой инструкции описано, как настроить pfSense 2.0 для распределения входящего веб‑трафика между несколькими Apache‑серверыми. Предполагается, что у вас уже есть рабочий pfSense и минимум два Apache (виртуальные или физические), а также базовое понимание интерфейса pfSense.

Краткое определение: балансировщик нагрузки — сетевой компонент, который распределяет входящие запросы между несколькими серверами, уменьшая нагрузку на отдельные узлы и повышая доступность приложения.

Требования

• Один сервер/коробка с pfSense 2.0 (если это ваш пограничный файрвол, рекомендуется физическая машина).
• Минимум два Apache2‑сервера (можно виртуальные).
• Механизм синхронизации файлов веб‑сайта между серверами (rsync, shared storage, репликация). Это важно для того, чтобы все узлы обслуживали одинаковый контент.

Важно: IP‑адреса, используемые для виртуального сервера (VIP), должны быть свободны в вашей сети и рутиться/доступны клиентам.

Основная идея и модель рассуждения

Модель: pfSense получает входящий запрос на виртуальный IP и порт (обычно 80 для HTTP) и по правилам пула выбирает один из реальных серверов (backend) для обработки запроса. pfSense периодически опрашивает реальные серверы с помощью конфигурируемого монитора (health check) и исключает недоступные узлы.

Правило большого пальца: всегда проверяйте монитор и синхронизацию контента — чаще всего проблемы связаны с неконсистентностью данных или неверными проверками здоровья.

Пошаговая настройка pfSense

1. Создаём монитор (Monitor)

1. В веб‑GUI pfSense перейдите Services → Load Balancers → Monitor.
2. Нажмите кнопку «+» (Добавить). Заполните поля:
   • Name (Имя): ApacheClusterMon
   • Description (Описание): Монитор для Apache‑кластера
   • Type (Тип): HTTP
   • Host (Хост): укажите свободный IP (виртуальный IP, который позже будет использоваться для проверки и привязки)
   • HTTP Code (HTTP‑код): оставьте 200 OK
3. Сохраните изменения и примените конфигурацию.

Примечание: при типе «HTTP» pfSense делает GET‑запрос и ожидает указанный код ответа. Убедитесь, что на серверах нет перенаправлений, меняющих код ответа.

2. Создаём пул серверов (Pools)

1. Перейдите Pools → нажмите «+».
2. Заполните:
   • Name (Имя): ApacheSrvPool
   • Mode (Режим): Load Balance
   • Port (Порт): 80 (или другой порт вашего приложения)
   • Monitor: выберите ApacheClusterMon
   • Добавьте IP‑адреса всех реальных серверов (backend) с их портами.
3. Сохраните и примените.

Совет: для HTTPS используйте соответствующие проверки (HTTPS/SSL) и убедитесь, что сертификаты на реальных серверах настроены корректно или выполняйте SSL‑терминацию на pfSense/другом балансировщике.

3. Создаём виртуальный сервер (Virtual Server)

1. Перейдите Virtual Servers → нажмите «+».
2. Заполните:
   • Name (Имя) и Description (Описание)
   • IP Address (IP‑адрес): используйте заранее избранный свободный IP (VIP)
   • Port (Порт): 80
   • Virtual Server Pool: ApacheSrvPool (пул, созданный ранее)
3. Сохраните и примените изменения.

После этого pfSense начнёт принимать запросы на VIP и распределять их между реальными серверами согласно выбранной политике.

Тестирование и критерии приёмки

Критерии приёмки:

• Клиент может получить страницу по VIP на порту 80.
• Запросы распределяются между реальными серверами (проверяется логами Apache или заголовками ответа).
• При отключении одного из реальных серверов pfSense исключает его из пула и трафик перенаправляется на оставшиеся узлы.
• Если все реальные серверы недоступны, VIP либо возвращает ошибку (в зависимости от конфигурации), либо трафик не обслуживается — это ожидаемое поведение.

Тест‑кейсы:

• Простая проверка: curl http:/// — получить 200 и содержимое.
• Нагрузочный тест: прогоните последовательные запросы (ab или wrk) и наблюдайте распределение.
• Отказ одного бэкенда: остановите Apache на одном сервере и проверьте, что он помечается как Down в списке пула.

Когда это не сработает / ограничений и подводные камни

• Монитор настроен неправильно: если на сервере используется редирект (301/302) или другой код, монитор не увидит 200 и посчитает сервер недоступным.
• Несинхронизированный контент: если на узлах разные версии сайта, пользователи будут получать разные ответы.
• Сессии: при использовании сессионного stateful‑хранения без общего хранилища (sticky sessions) пользoватели могут потерять сессию при переключении между узлами.

Рекомендация: используйте механизм sticky‑сессий (если нужно) или выносите сессии в централизованное хранилище (Redis, Memcached, БД).

Альтернативные подходы

• DNS Round Robin — просто, но не учитывает состояние серверов.
• HAProxy на отдельной машине или пакете pfSense (плагин) — более гибкий балансировщик с поддержкой SSL, проксирования и расширенных health checks.
• LVS (Linux Virtual Server) — для высокопроизводительных сетевых балансировок на уровне ядра.

Выбор зависит от требований к функционалу (SSL, sticky, Layer 7), производительности и управляемости.

Рекомендации по отказоустойчивости и план отката

Рекомендации:

• Настройте репликацию/синхронизацию контента (rsync, shared NFS, репликация БД).
• Настройте мониторинг pfSense и уведомления при падении реального сервера.
• Рассмотрите кластеризацию pfSense (CARP) для обеспечения доступности VIP при отказе pfSense.

План отката (Rollback):

1. Если новая конфигурация вызывает ошибки, верните предыдущую конфигурацию через Backup → Restore в GUI pfSense.
2. Если VIP не работает, временно переключите DNS на один работоспособный backend или включите запись A на реальный сервер.
3. Проведите анализ логов и исправьте конфигурацию монитора/пула.

Контроль безопасности и приватности

• Ограничьте доступ к интерфейсу администрирования pfSense по IP и используйте HTTPS для доступа к GUI.
• Закрывайте ненужные порты на реальных серверах и ограничьте доступ к административным сервисам.
• Если передаётся чувствительная информация, используйте HTTPS и корректно управляйте сертификатами.

Быстрый чек‑лист для развертывания (роль‑ориентированный)

• Сетевой администратор:
  • Проверить маршрутизацию VIP и доступность IP из внешней сети.
  • Настроить правила firewall, разрешающие трафик на VIP порты.
• Системный администратор (backend):
  • Убедиться, что Apache возвращает 200 для корневого URL.
  • Настроить синхронизацию файлов и сессий.
• Операции/DevOps:
  • Настроить мониторинг и алерты на недоступность бэкенда.
  • Прогнать нагрузочные тесты и измерить поведение.

Короткое резюме

Вы настроили монитор, пул и виртуальный сервер в pfSense, чтобы распределять HTTP‑запросы между несколькими Apache‑серверными. Проверьте монитор, синхронизацию контента и протестируйте поведение на отказ. Для продвинутых сценариев рассмотрите HAProxy или CARP для высокой доступности.

Важно: если ваши backend‑серверы не возвращают 200 OK при проверке здоровья, pfSense пометит их как недоступные, и пул будет частично или полностью недоступен. Настройте корректный health check и синхронизацию контента.

Дополнительные материалы и примеры команд

• Протестировать VIP с клиента: curl -I http://
• Проверить статус пула в GUI pfSense: Services → Load Balancers → Pools
• Быстрый запуск rsync (пример): rsync -avz –delete /var/www/html/ user@backend:/var/www/html/

Ссылки для дальнейшего изучения: официальная документация pfSense, руководство по HAProxy и примеры CARP‑конфигураций.

Ключевые шаги: настроить монитор, создать пул с реальными серверами, создать виртуальный сервер и протестировать поведение при отказе. Учитывайте синхронизацию контента и стратегию сессий.