Часть 17. Сервер балансировки нагрузки 

  †Оглавление†

<<< Предыдущая Глава | Следующая Глава >>>

 

В pfSense доступны два типа функциональности балансировки нагрузки: шлюз и сервер. Шлюз балансировки нагрузки обеспечивает распределение интернет трафика через несколько WAN-соединение. Дл яполучени ядополнительной информации по данному типу балансировки нагрузки, обратитесь к главе 11, "Множественные WAN-соединени ".

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

Хотя pfSense япозволяет заменить высокотехнологичные и дорогостоящие коммерческие средства балансировки нагрузки, в том числе BigIP, Cisco LocalDirector и другие, в серьёзных производственных средах, pfSense 1.2.x далеко не такой мощный и гибкий, как указанные решени . яОн не предназначен дл яразвёртываний, которые требуют гибкого мониторинга и конфигурировани ябалансировки. Дл ямониторинга TCP, pfSense просто проверяет, что указанный порт открыт. В случае web-сервера, сервер не может вернуть любой HTTP-ответ, или ошибку, и нет никакого способа определени яданной ситуации. Дл якрупных и сложных развёртываний вам потребуетс яболее мощное решение. Однако дл яудовлетворени яосновных функциональных возможностей, pfSense может оказатьс яболее чем достаточным. В настоящее врем ямы рассматриваем варианты расширени явозможностей балансировки нагрузки в версии 2.0.

17.1. Разъяснение параметров конфигурации

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

17.1.1. Пул виртуальных серверов

Для настройки пула виртуальных серверов, перейдите на страницу Services -> Load Balancer. Нажмите [+] для добавлени янового пула. Кажда яиз опций этой страницы рассматривается дальше.

• Name - Введите в это поле им япула. Это им ябудет использоватьс япозже, при конфигурировании виртуальных серверов использующих этот пул.

• Description - При необходимости, введите в это поле подробное описание пула.

• Type - по умолчанию должно быть установлено Server, что и требуетс ядл нашей конфигурации.

• Behavior (поведение) - Выберите Load Balancing дл ябалансировки нагрузки между всеми серверами входящими в пул, или Failover дл яиспользовани япервого сервера в пуле, и в случае его неисправности перехода к использованию последующих серверов.

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

• Monitor - Определяет используемый тип мониторинга, который используетс ядл выявлени ясостояни ясерверов. Выбор TCP определит соединени ябалансировки по ранее указанному порту (поле Port), и если подключитьс як данному порту не возможно, сервер будет считатьс яне действующим. Выбор ICMP позволяет контролировать определённые сервера использу ping-ядиагностику, и отмечать их как не действующие если они не отвечают на пингование.

• Monitor IP - Это поле не используетс яв режиме сервера балансировки нагрузки и отмечено серым цветом (не активно).

• Server IP Address - Здесь заполняютс явнутренние IP адреса серверов входящих в пул. Введите их по одному за раз, нажав кнопку Add.

• List - Поле отображает список серверов добавленных в пул. Вы можете удалить сервер из пула, нажав на его IP-адрес и щёлкнув на кнопке Remove from pool.

После заполнени явсех полей, нажмите кнопку Save. Теперь перейдите к конфигурировани явиртуальных серверов данного пула, щёлкнув на вкладке Virtual Servers.

17.1.1.1. Виртуальные сервера

На данной странице вам необходимо определить IP-адрес и слушаемый порт дл направлени ятрафика на ранее сконфигурированный пул. Нажмите [+] дл ядобавлени нового сервера. Кажда яопци яданной страницы обсуждаетс яниже.

• Name - Введите в это поле им ядл явиртуального сервера.

• Description - При желании введите подробное описание виртуального сервера.

• IP Address - Поле ввода IP-адреса на котором будет слушать виртуальный сервер. Обычно это ваш WAN IP или виртуальный IP на WAN. Это должен быть статический IP-адрес. Вы можете использовать CARP VIP дл янастройки высокой доступности балансировки нагрузки. Дл яполучени ябольшей информации о высокой доступности и CARP VIP, обратитесь к главе 20, "Избыточность брандмауэра/высока ядоступность".

• Port - порт на котором будет слушать виртуальный сервер. Он может отличатьс от внутреннего порта.

• Virtual Pool Server - В этом поле вы можете выбрать ранее сконфигурированный пул. Соединение к IP Address и Port, определённые на этом экране, будет направлятьс яна IP-адрес и порт сконфигурированного пула. 

• Pool Down Server - Здесь определяетс ясервер к которому направляютс яклиенты в случае, если все сервера вашего пула не действуют. Следует ввести в это поле какой то адрес. Если у вас нет альтернативного сервера дл яотправки запросов, вы можете ввести один из IP-адресов сервера вашего пула, хот яэто не принесёт результата, если все сервера пула отключены. После заполнени ясоответствующих полей нажмите кнопку Save, а затем примените изменени (Apply Changes).

17.1.1.2. Правила брандмауэра

Последний шаг заключаетс яв настройке правил брандмауэра, позволяющих трафик в пул. Подобно сценарию NAT, правила брандмауэра должны разрешать трафик на внутренние частные IP-адреса серверов, и внутренний порт на котором они слушают. Вам необходимо создать алиасы дл ясерверов в пуле, и создать правило брандмауэра на интерфейсе где инициируетс ятрафик предназначенный дл япула (как правило интерфейс WAN), позволив соответствующему источнику (как правило any) следовать к назначению алиаса созданного дл япула. Конкретный пример приведён в разделе 17.2.4, "Настройка правил брандмауэра". Дл яполучени ябольшей информации о правилах брандмауэра, обратитесь к главе 6, "Брандмауэр".

17.1.2. Липкие соединения (Sticky connections)

Существует ещё одна опци яконфигурировани ядл ясервера балансировки нагрузки, доступна яв меню System -> Advanced. Под Load Balancing, в найдёте Use sticky connections (Использовать липкие соединени ). яУстановка этого флага предоставит клиентам с активным подключением к пулу постоянное направление к тому же серверу что и в предыдущих соединениях. После закрыти яклиентом всех активных соединений и закрыти ятаймаута состояний, липкое соединение теряетс . яЭто бывает желательно дл некоторых конфигураций балансировки нагрузки web-серверов, где запросы конкретного клиента должны поступать только на один сервер за сессию, либо по другим причинам. Обратите внимание, что данна ясхема не являетс ясовершенной, поскольку если браузер клиента закрывает все TCP соединени як вашему серверу после загрузки страницы и сидит там 10 минут или больше перед загрузкой следующей страницы, следующа страница может быть обслужена другим сервером. Обычно это не являетс япроблемой, поскольку большинство браузеров не закрывают соединение сразу и состояние существует достаточно долго, чтобы не создать проблемы. Однако, если вам строго необходимо, чтобы клиент никогда не получал данные с другого сервера пула, независимо от времени не активности браузера, вам придётс яискать иное решение балансировки нагрузки.

17.2. Пример конфигурования сервера балансировки нагрузки для обслуживания web

Этот раздел показывает, как с начала до конца конфигурировать балансировку нагрузки дл ядвух web-серверов в среде балансировки нагрузки.

17.2.1. Пример сетевой среды

Рисунок 17.1. Пример сети с сервером балансировки нагрузки

Рисунок 17.1, "Пример сети с сервером балансировки нагрузки", показывает схему среды настраиваемой в этом разделе. Она состоит из одного брандмауэра, использующего свой WAN IP дл япула с двум web-ясерверами в сегменте DMZ.

17.2.2. Конфигурирование пула

Для настройки пула, перейдите на страницу Services -> Load Balancer и нажмите [+]. Рисунок 17.2, "Конфигурирование пула", показывает конфигурацию пула нагрузки дл ядвух web-серверов с использованием TCP мониторинга. После заполнени явсех полей, нажмите кнопку Save.

17.2.3. Конфигурирование виртуального сервера

Вернитесь на экран Load Balancer Pool, нажмите закладку Virtual Server и нажмите [+] дл ядобавлени янового виртуального сервера. Рисунок 17.3, "Конфигурирование виртуального сервера", показывает конфигурирование виртуального сервера слушающего на WAN IP (10.0.66.25) на порту 80 и направляющего трафик на IP и порт к серверам определённым в пуле WebServers. дл Pool Down Server, яэта конфигураци использует один IP-адрес сервера из пула WebServers, поскольку отсутствуют иные варианты. В данном случае, если оба сервера недоступны, виртуальный сервер так же недоступен. После заполнени яполей, нажмите Submit, а затем Apply Changes.

17.2.4. Конфигурирование правил брандмауэра

Рисунок 17.4. Алиас для web серверов

Теперь необходимо настроить правила брандмауэра таким образом, чтобы позволить доступ к серверам в пуле. Правила должны позволять трафик к внутренним IP-адресам и используемому порту, и нет никаких необходимых правил дл явнешнего IP-адреса и порта, используемых виртуальными серверами. Желательно использовать алиас, включающий все сервера пула, чтобы можно было разрешить доступ с использованием всего лишь одного правила брандмауэра. Перейдите на страницу Firewall -> Aliases и нажмите [+] дл ядобавлени яалиаса. Рисунок 17.4, "Алиас дл web ясерверов", показывает алиас, используемый дл яданной конфигурации и включающий два web- сервера. После ввода алиаса нажмите кнопку Save, а затем Apply Changes.

Перейдите на страницу Firewall -> Rules и на вкладке интерфейса на котором будет инициироватьс ятрафик клиента (в данном случае WAN) нажмите [+]. Рисунок 17.5, "Добавление правила брандмауэра дл web-ясерверов", показывает фрагмент правила брандмауэра добавленного дл яэтой конфигурации. Не показанные опции слева имеют значени япо умолчанию, за исключением пол Description.

Рисунок 17.6, "Правило брандмауэра дл web-ясерверов", показывает правило после его добавлени .

Рисунок 17.5, "Добавление правила брандмауэра для web-серверов"

Рисунок 17.6, "Правило брандмауэра для web-серверов"

17.2.5. Просмотр статуса балансировки нагрузки

Теперь, когда балансировка нагрузки настроена, дл япросмотра её статуса, перейдите на страницу Status -> Load Balancer и нажмите закладку Virtual Servers. Здесь вы увидите статус дл якаждого сервера в пуле. (как показано на рисунке 17.7, "Статус виртуального сервера"). Если статус изменилс яв online в течение последних пяти минут с первой становки балансировки нагрузки, вы увидите надпись "Online" подсвеченную жёлтым цветом. После прошестви япяти минут, статус должен изменитьс яна зелёный.

Рисунок 17.7, "Статус виртуального сервера"

Если вы остановите сервис на одном из web-серверов или отключите сервер от сети, при использовании ICMP мониторинга вы увидите что статус изменилс яна Offline и сервер будет удалён из пула.

17.2.6. Проверка балансировки нагрузки

Для проверки балансировки нагрузки, лучшим вариантом являетс curl, якоторый использует кеш web-браузера, а постоянные соединени яне влияют на результат тестировани . curl ядоступен дл явсех мыслимых ОС и может быть загружен с сайта curl - [http://curl.haxx.se]. Дл яиспользовани янеобходимо просто выполните curl http://mysite, заменив mysite на IP-адрес или им яхоста вашего сайта. Тестирование необходимо выполнять вне вашей сети. Следующий пример иллюстрирует тестирование с помощью curl на стороне WAN.

# curl http://10.0.66.25

<html>

<head>

<title>.12</title>

</head>

<body>

<p> 192.168.33.12 - Server 2 </p>

</body>

</html>

При первоначальном тестировании балансировки нагрузки, вам необходимо настроить каждый сервер на возврат страницы указывающей им яхоста, IP-адрес или оба этих параметра, что позволит узнать какой сервер вы используете. Если у вас не включены липкие соединени , ято каждый раз, при запросе страницы с curl, вы будете получать ответ от другого сервера (исключа яситуацию описанную в разделе 17.3.2, "Неравна балансировка").

17.3. Устранение проблем с сервером балансировки нагрузки

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

17.3.1. Подключения не балансируются

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

Другой распространённой проблемой являетс якэш браузера, когда браузер не запрашивает страницу снова. В данном случае предпочтительно использовать для тестировани яинструменты командной строки, такие как curl, поскольку он гарантирует, что вы не испытаете проблем связанных со спецификой web-браузера - они не используют кэш и каждый раз открывают новое соединение к серверу. Более подробную информацию о curl можно найти в разделе 17.2.6, "Тестирование балансировки нагрузки".

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

17.3.2. Неравная балансировка

Из-за особенностей функционировани ПО, в условиях низкой нагрузки балансировка будет неравной. Базова яслужба мониторинга slbd сбрасывает якорь pf на каждом контролируемом интервале - примерно каждые 5 секунд. Это означает, что каждые 5 секунд последующее соединение будет следовать на первый сервер в пуле. При обслуживании очень низкой нагрузки, с частотой одно или меньше соединений каждые 5 секунд, вы будете наблюдать крайне малую балансировку. У вас есть возможность полного перехода на другой ресурс при сбое одного из серверов. На самом деле эта проблема самоустраняема - якогда нагрузка увеличитс ядо некоторого значени , япри котором балансировка станет важным фактором, балансировка станет равномерной. В рабочих условиях, при обработке тысяч пакетов в секунду, балансировка между серверами равнозначна .

17.3.3. Недоступный сервер не маркируется как Offline

Если сервер не доступен, но не помечаетс якак offline, это происходит по той причине, что с точки зрени ямониторинга проводимого pfSense, сервер доступен. При использовании TCP мониторинга, это означает что TCP порт принимает соединени . Сервис на данном порту может быть нарушен различными методами, но по прежнему отвечать на TCP соединени . яДл ICMP ямониторинга, эта проблема усугубляетс , ятак как серверы могут иметь кучу сервисов, которые по прежнему будут отвечать на ping.

17.3.4. Живой сервер не маркируется как Online

Если сервер находитс яв online, но не маркируетс якак Online, это происходит по причине того, что с точки зрени ябрандмауэра сервер не доступен. Сервер должен отвечать на используемом TCP порту или отвечать на ping полученный с IP интерфейса на интерфейсе брандмауэра в сторону сервера. Например, если сервер находитс яв LAN, он должен отвечать на запросы инициированные LAN IP брандмауэра. Чтобы убедитьс в этом, дл ICMP ямониторинга, перейдите на страницу Diagnostics -> Ping и пропингуйте IP сервера через интерфейс на котором находитс ясервер. Дл TCP мониторинга, войдите на брандмауэр с помощью SSH или с консоли и выберите раздел меню 8. в командной строке используйте telnet-соединение на слушающий порт сервера. Например, дл ятестировани web-ясервера описанного в данной главе, выполните команду telnet 192.168.33.11 80. Успешное соединение должно произойти немедленно, в то врем якак ошибочное будет висеть на открытие. Ниже приведён пример неудачного соединени :

# telnet 192.168.33.12 80

Trying 192.168.33.12...

telnet: connect to address 192.168.33.12: Operation timed out

telnet: Unable to connect to remote host

А вот пример успешного соединения:

# telnet 192.168.33.12 80

Trying 192.168.33.12...

Connected to 192.168.33.12.

Escape character is '^]'.

При обнаружение неудачного соединения необходимо устранить проблемы на сервере.

 

<<< Предыдущая Глава | Следующая Глава >>>

†Оглавление†