Как стать автором
Обновить

Комментарии 50

Отлично! а то платный bng надоел.
Спасибо!
Спасибо! Из статьи не понял, каким маршрутом пакеты убегают обратно. Внешний канал такой конфигурации будет равен внешнему каналу директора или сумме внешних каналов всех серверов?
При DR пакеты убегают минуя директор, так что на директоре не виден исходящий трафик. Если воткнуть NAT, то побегут через директор конечно.
а куда именно они убегают?
насколько я понимаю, схема выглядит примерно так:
1) пришел запрос на директор (установилось соединение)
2) директор прокинул запрос на внутрисеть (установил соединение, переслал запрос, получил ответ)
3) внутрисетевой сервер получил запрос (установилось соединение), отработал и…
4а) в моем понимании: отдал результат директору, который отдал его клиенту
4б) в Вашем понимании: отправил данные куда-то (куда?)
все, понял куда они убегают:
— запрос на директор пришел через внешний gateway
— ответ от конечного сервера ушел прямо на этот внешний gateway
Именно
А не нарушает ли это само понятие маршрутизации? ведь если смоттреть со стороны gateway'a (rfr описано комментариями выше), получается. что шлюз отправил порт на один IP (в примере из статьи — 192.168.100.100 (я правильно понял?)), а ответ получает — от одного из реальных серверов, тоесть от 192.168.100.2 или .3
Например, при варианте, когда на шлюзе стоит нат, такой расклад не прокатит.
Да и при стандартной конфигурации шлюза тоже не будет работать, так как клиент ждет ответа от другого компьютера (порты не совпадут).
Объясните, пожалуйста, более подробно, где я не прав?
Надо глянуть tcpdump. По-моему клиент получает ответ все от того же 192.168.100.100.
значит это где-то на клиенте должно быть прописано, или трафик все-таки ходит через директора…
Трафик ходит не через директора. Мы же специально создаем loopback, чтобы реальный сервер ловил пакет. Т.е. так как машина считает этот адрес своим, она видимо и отвечает от этого же имени.

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

Кроме того, меня интересует, что будет с сессиями?
К примеру, клиент устанавливает TCP-сессию c сайтом на бэкендах.
Балансер не порвет эту сессию разбросав пакеты по разным серверам в бэкенде, в случае метода DR?
И все же, трафик ходит через директора!
Потому что в случае DR используется на самом деле Destination NAT, и, само собой, происходит обратная подстановка при ответе.
нда, ошибся.
В общем DR — это L2 балансировка.

А вот и ответ: Как работает такая балансировка?
На балансировщик, имеющий этот IP-адрес и отвечающий на ARP, приходит, допустим, первый пакет соединения. Мы определяем, что он первый. Нужным алгоритмом отправляем его на интересующий нас сервер, меняя MAC-адрес на место назначения (англ. destination). Записываем его в некоторую таблицу соединений.
Если у нас это не первый пакет, то мы просто смотрим по таблице соединений, каким сервером обрабатывается это соединение, и отправляем его туда.

Т.е. это очень напоминает L2-proxy или L2-NAT ))
А существует ли аналогичный функционал в FreeBSD?
CARP, как мне кажется наиболее близок…
Пример настройки так же здесь
Простой и доступный метод.
Всегда поражался какими костылями делают это при создании кластеров.
Кто своё ПО городит, готовые прокси ставит…
Экономные делают LVS или Nginx (но этот не все умеет балансить), чуть более извращенные ставят к примеру HAProxy, более извращенные и богатые ставят Cisco ASA и ему подобные
ASA в целом надежнее получается. Кроме нее есть Cisco CCS и аналогичные решения от Juniper. Преимущества — производительность и надежность. Конфигурируется часто проще (есть подробная документация) Недостаток — цена
А можете рассказать, как такое реализовать на ASA?
Я их использую только как фаервол на данный момент.
А можете рассказать, как такое реализовать на ASA?
Я их использую только как фаервол на данный момент.
К сожалению (или к счастью) мы ее не используем, хотя в и планировали. Ввиду отсутствия персонала шарящаго в Cisco отдали связку ASA/CCS сетевикам, они их превратили в «обычный» роутер. Вообще же для балансировки обычно используют CSS, а ASA больше как firewall и немного как HA свитч
HA Router/Firewall (иногда VPN) — для этого и используем их… надо почитать можно ли как ЛБ их юзать
Метод на самом деле не такой уж простой, ибо имеет много подводных камней с собственно TCP/IP. В общем в реализации скорее всего придется посидеть и с tcpdump и многократно покурить ман…
Однозначно статью в избранное, мало того что она трушная, дак еще и на все 100% относится к тематике хабра, а не «как запустить far в linux под wine» =)
Фактически это L4-роутер (я бы сказал что L3, но авторы настаивают на L4)
Не, реально L4. Свичинг не по IP, а по сочетанию IP:port
Ну авторы на этот счет шутят:

Layer 4 Switching: Determining the path of packets based on information available at layer 4 of the OSI 7 layer protocol stack. In the context of the Internet, this implies that the IP address and port are available as is the underlying protocol, TCP/IP or UCP/IP. This is used to effect load balancing by keeping an affinity for a client to a particular server for the duration of a connection.

This is all fine except

Nevo Hed nevo (at) aviancommunications (dot) com 13 Jun 2001
The IP layer is L3.

Alright, I lied. TCPIP is a 4 layer protocol and these layers do not map well onto the 7 layers of the OSI model. (As far as I can tell the 7 layer OSI model is only used to torture students in classes.) It seems that everyone has agreed to pretend that tcpip uses the OSI model and that tcpip devices like the LVS director should therefore be named according to the OSI model. Because of this, the name «L4 switch» really isn't correct, but we all use it anyhow.
Спасибо, познавательно. Было бы интересно понять преимущества этого решения в сравнение с другими.

1) Если мы говорим о балансировке HTTP трафика, то кой профит по сравнению с Nginx? Балансер Nginx так же имеет единую точку отказа. Но, я так понял, что и LVS решает это проблему, только в сочетание с другими инструментами.

2) Если говорить о TCP трафике в целом, то что дает LVS в сравнение с HAProxy?

Теоретически, модуль ядра должен давать лучшею производительность. Но хотелось бы услышать ваше мнение.
Насколько я понял из habrahabr.ru/blogs/sysadm/104621/#comment_3269451, при гигабитных сетевых картах в серверах и необходимости раздавать к примеру 4 гигабита, вам не придется ставить 4 фронтенда/балансера, между которыми снова таки нужно разбрасывать запросы.
Честно говоря не особо вникал в HAProxy, ибо, как мне показалось, он больше заточен на L7 и HTTP. Хотя судя по документации он умеет почти тоже самое что и LVS-NAT. Когда я обратился к этой теме, мне нужно было решение для прозрачного роутинга ssh на менее загруженную машину. И тут LVS, на мой взгляд, достаточно.

Если рассуждать более общими категориями, то L4-роутер на уровне ядра должен быть в разы быстрее L7-роутера и гораздо лучше масштабироваться. Но соответственно вы теряете все преимущества L7 — анализ заголовков.
Познавательно. Про UltraMonkey читал не так давно.

В качестве балансировщика именно для HTTP под виндой можно обойтись NLB.

Немного не понятно, зачем использовать LVS, если есть HAProxy.

Также хотелось бы узнать о средствах балансировки нагрузки именно RDP-трафика. Я встречал только платные решения типа 2XLoadBalancer.
Win2008, вроде, умеет создавать ферму терминальных серверов из коробки. Или речь не об этом?
Да, Win2008 вроде умеет.
Интересует балансировка именно на Win2003
NLB+Session Directory немного не то
Точно умеет. Для win2k3 из работоспособного ничего бесплатнее Citrix за много лет так и не нашли.
К сожалению с RDP помочь не могу. У нас ssh и X11…
спасибо. отличная статья. сам использую для балансироски CSS
Спасибо. Просто и лаконично! Добавил в мемориз.
а как быть с субд?
Смотреть в сторону реплакции, я думаю. LVS пожалуй поможет для фермы read-only слэйвов.
Вообще тема сложная и мной (пока) не изученная.
Кстати, при DNS-RR можно кривенько балансировать нагрузку создавая разное количество RR для каждого из серверов. Т.е. если
www IN A 1.1.1.1
www IN A 1.1.1.2
www IN A 1.1.1.2
www IN A 1.1.1.2
То сервер 1.1.1.2 получит в три раза больше трафика чем первый.

А если нагрузку надо перераспределять каждые минут 10? А если в качестве DNS-сервера выступает контроллер домена на винде? :)
Думаю это решаемо скриптом с шедулером. Насколько я знаю, у виндового ДНС есть апи.
Но опять же могут возникнуть проблемы с кэшированием ответов… В общем вроде бы так никто не делает, хотя могу и ошибаться.
это не работает, идентичные A записи игнорируются.
BIND 9.6
НЛО прилетело и опубликовало эту надпись здесь
Да парни, я уже 7 лет сижу на balance-ng — и бед не знаю…
Сессии шарятся, у серверов есть весовые коэф. и работает безотказно.
Не скажу что много трафика проходит — ну в среднем 100 мегабит в пике 300-400 это при 100 мегабитных картах и 8 веб серверах на отдачу.
с 4-мя гигабитами не взлетит, например
Простите за возможно глупый вопрос, я не силен в сетях.
1) Подскажите, как физически соединены Director и Real Server'ы в сеть? У director'а два сетевых ethernet'а, один из которых — для внешнего IP, а другой — в коммутатор с real-серверами?
2) Одинакова ли будет топология сети (физическая) в схемах DR и NAT или нет?
3) Правильно ли я понимаю, вопрос ограничения ~64К открытых портов для данной схемы не актуален?
1) Формально они все могут иметь по одной сетевой карте и воткнуты в один и тот же коммутатор. Директором в этом случае будет тот сервер, у которого сейчас VIP, который, в свою очередь, всего лишь alias. 2 сетевые карты на директоре может потребоваться в сценарии NAT.
2) В DR исходящие пакеты уходят от серверов напрямую, в NAT же все исходящие пакеты идут назад через директор. В этом случае директор выступает в роли роутера в обе стороны.
3) Честно говоря не задумывался над проблемой. Входящих портов действительно будет не больше ~64К, с исходящими портами не уверен, но вроде бы предпосылок для ограничений нет, кроме очевидного ~64K на сервер.

Кстати для организации HA вместо UltraMonkey рекомендую Pacemaker, следующая моя статья была как раз про него.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории