В первой части CISCO ACE — балансировка приложений мы немного окунулись в мир балансировки приложений и сетевых ресурсов. Познакомились с характеристиками, предназначением и возможностями семейства таких устройств. Рассмотрели основные сценарии внедрения и преимущества, которые нам приносит использование балансировщиков.
Вероятно многие поймали себя на мысли о том, что это очень дорого и не увидели преимуществ, которые именно им может предоставить промышленный балансировщик. В посте я уделю внимание именно этому моменту и постараюсь показать, что сервисом может воспользоваться большинство.
В первой части мы рассмотрели случай балансировки приложений (балансировки между серверами), которые непосредственно находятся в одном ЦОД. Можно даже сказать — в одном L2 домене. Предположим, что Вы заинтересовались описанными преимуществами и хотите получить данный сервис. В большинстве публичных ЦОД такое оборудование отсутствует, так как пользователю необходимо предоставить сервер за 50-100 долларов в месяц. В корпоративный ЦОД Вас с Вашим серверов никто не пустит (учитывается не только момент физического размещения, но и существующая политика информационной безопасности).
Указанные причины не едины. Если Ваш проект растет, то хорошим вариантов является размещение дополнительного сервера в другом ЦОД для повышения доступности сервиса. А в случае набирающего популярность информационного рейдерства, вариант является даже необходимым. Достижим ли для Вас этот сервис? Да, Вы также можете воспользоватся существующим функционалом.
Итак, остановимся на том, что CISCO ACE (или любой другой приличный балансировщик) способен распределить нагрузку не только между непосредственно подключенными серверами, но и между удаленными ресурсами. Такой режим называется Routed One-Arm-Mode (или On-a-Stick).
В архитектуре данного режима нет ничего особенного, просто вместо Destination NAT (на хосты фермы), балансировщик производит дополнительный Source NAT. Ну и все остальные функции никто не отменял. Предлагаю рассмотреть пример демонстрирующий возможности.
В этом случае весь Ваш трафик направляется на виртуальный адрес (VIP). Этот адрес закреплен за балансировщиком. Обрабатывая запросы, он перенаправляет их на удаленные сервера. Все сервера входят в одну структурную группу — серверную ферму. Произведем небольшую настройку. Во многом она будет повторять структуру, рассмотренную в первой статье.
1. Создадим сервера
В нашем случае три сервера, с адресами указанными в топологии:
rserver host SERVER-1
description SERVER-1 ip address 1.1.1.1 inservice
rserver host SERVER-2
description SERVER-2 ip address 2.2.2.2 inservice
rserver host SERVER-3
description SERVER-3 ip address 3.3.3.3 inservice
2. Опишем правила определения доступности сервисов (пусть будет ВЕБ сервер)
probe http HTTP_PROBE
interval 5 passdetect interval 10 passdetect count 2 request method head url /index.html expect status 200 210 header User-Agent header-value "LoadBalance"
probe icmp ICMP_PROBE
interval 10 passdetect interval 60 passdetect count 4 receive 1
Какие параметры и для чего предназначены — описано в первой статье.
3. Объеденим устройства в ферму
serverfarm host FARM
probe HTTP_PROBE
probe ICMP_PROBE
rserver SERVER-1
inservice
rserver SERVER-2
inservice
rserver SERVER-3
inservice
4. Создадим виртуальный адрес и опишем политику балансировки
Так как сервера будут получать запросы непосредственно от балансировщика, то адреса клиентов для них останутся загадкой. Вы догадались, что нужно сделать, добавить заголовок X-Forwarded-For.
class-map match-all SERVER-VIP
2 match virtual-address 193.109.8.163 any
policy-map type loadbalance first-match LB-POLICY
class class-default
serverfarm FARM
insert-http X-Forwarded-For header-value "%is"
Здесь мы указали, что балансировать будем в ферму FARM.
5. Создадим политику для интерфейса, который будет принимать входящий трафик
policy-map multi-match FARM-POLICY
class SERVER-VIP
loadbalance vip inservice
loadbalance policy LB-POLICY
loadbalance vip icmp-reply
nat dynamic 10 vlan 100
Следует обратить внимание на последнюю строку политики. Она указывает балансировщику как необходимо преобразовать адрес отправителя, то есть собственный адрес.
Ну и сама конфигурация интерфейса. Пусть будет Interface Vlan 100.
interface vlan 100
ip address 10.10.10.10 255.255.255.0 service-policy input FARM-POLICY nat-pool 10 10.10.10.11 10.10.10.11 netmask 255.255.255.255 pat no shutdown
ip route 0.0.0.0 0.0.0.0 10.10.10.1
6. Что получаем в результате?
6.1. Запись в DNS: domain.org IN A 10.10.10.5.
6.2. Клиенты отправляют запросы на балансировщик.
6.3. Балансировщик распределяет запросы между активными серверами, изменяя адрес назначения на реальный адрес сервера, а адрес источника — на тот, который указан в конфигурации (10.10.10.11).
6.4. Сервера получают все запросы от 10.10.10.11, но имеют заголовок X-Forwarded-For. Сервера отвечаю балансировщику.
6.5. Балансировщик возвращает полученные ответы клиентам ресурса.
Со стороны клиента необходимо предоставить список адресов серверов и произвести изменение записи в DNS. Естественно, количество функционирующих серверов может увеличиваться-уменьшаться. Вообщем функционал не страдает.
Есть у этого функционала одна интересная особенность, которую можно выгодно использовать
Мы рассмотрели случай когда ACE имеет один интерфейс. Давайте посмотрим на вариант с двумя интерфейсами. Причем, одним интерфейсом он подключен к одному провайдеру, вторым — к другому. Или у Вас есть своя AS, парочка префиксов, подключение к двум провайдерам (дальше поймете почему столько условий) и Вы можете сделать так, что трафик в одну подсеть поступает через одного провайдера, во вторую — через другого. (Некоторые интересные моменты управления трафиком BGP рассмотрены в BGP: некоторые особенности поведения трафика).
Давайте разберем, что происходит в такой ситуации.
1. Клиенты осуществляют доступ к виртуальному адресу (благодаря записи в DNS).
2. Трафик проходит через провайдера №1 и загружает его канал.
3. На пути от провайдера №1 до балансировщика мы можем произвести «очистку» трафика. Благодаря поведенческому и сигнатурному анализу отсечь DDoS и всяческого рода сканирования/вторжения.
4. Балансировщик передает запросы на сервера используя провайдера №2. Его канал (ISP-2) остается не загруженный DDoS'ом.
5. Сервер обрабатывает только легитимные запросы и передает ответы балансировщику, а от возвращает их клиентам.
Естественно, схема предусматривает наличия оборудования защиты от DDoS (Arbor Peakflow, CISCO Detector/Guard). Также не помешает хороший IPS.
Такая себе защита от DDoS on-demand. В случае необходимости, или на постоянной основе, клиенту необходимо всего-лишь произвести изменения в DNS.
Для реализации схемы необходимо произвести небольшие дополнительные настройки балансировщика. В случае атаки, загрузке подвергается канал с провайдером №1. Канал с провайдером №2 остается «чистым». Тонкости и особенности управления трафиком — это отдельная тема, идея заключалась в демонстрации того, как это возможно реализовать.
Успехов!
Автор: dovecot
