Comments 50
Отлично! а то платный bng надоел.
Спасибо!
Спасибо!
Спасибо! Из статьи не понял, каким маршрутом пакеты убегают обратно. Внешний канал такой конфигурации будет равен внешнему каналу директора или сумме внешних каналов всех серверов?
При DR пакеты убегают минуя директор, так что на директоре не виден исходящий трафик. Если воткнуть NAT, то побегут через директор конечно.
а куда именно они убегают?
насколько я понимаю, схема выглядит примерно так:
1) пришел запрос на директор (установилось соединение)
2) директор прокинул запрос на внутрисеть (установил соединение, переслал запрос, получил ответ)
3) внутрисетевой сервер получил запрос (установилось соединение), отработал и…
4а) в моем понимании: отдал результат директору, который отдал его клиенту
4б) в Вашем понимании: отправил данные куда-то (куда?)
насколько я понимаю, схема выглядит примерно так:
1) пришел запрос на директор (установилось соединение)
2) директор прокинул запрос на внутрисеть (установил соединение, переслал запрос, получил ответ)
3) внутрисетевой сервер получил запрос (установилось соединение), отработал и…
4а) в моем понимании: отдал результат директору, который отдал его клиенту
4б) в Вашем понимании: отправил данные куда-то (куда?)
А не нарушает ли это само понятие маршрутизации? ведь если смоттреть со стороны gateway'a (rfr описано комментариями выше), получается. что шлюз отправил порт на один IP (в примере из статьи — 192.168.100.100 (я правильно понял?)), а ответ получает — от одного из реальных серверов, тоесть от 192.168.100.2 или .3
Например, при варианте, когда на шлюзе стоит нат, такой расклад не прокатит.
Да и при стандартной конфигурации шлюза тоже не будет работать, так как клиент ждет ответа от другого компьютера (порты не совпадут).
Объясните, пожалуйста, более подробно, где я не прав?
Например, при варианте, когда на шлюзе стоит нат, такой расклад не прокатит.
Да и при стандартной конфигурации шлюза тоже не будет работать, так как клиент ждет ответа от другого компьютера (порты не совпадут).
Объясните, пожалуйста, более подробно, где я не прав?
Надо глянуть tcpdump. По-моему клиент получает ответ все от того же 192.168.100.100.
значит это где-то на клиенте должно быть прописано, или трафик все-таки ходит через директора…
Трафик ходит не через директора. Мы же специально создаем loopback, чтобы реальный сервер ловил пакет. Т.е. так как машина считает этот адрес своим, она видимо и отвечает от этого же имени.
Понаблюдаю завтра, если вам так интересно. Вообще про это в HOWTO должно быть расписано.
Понаблюдаю завтра, если вам так интересно. Вообще про это в HOWTO должно быть расписано.
Получилось что-нибудь выяснить по данному вопросу?
Кроме того, меня интересует, что будет с сессиями?
К примеру, клиент устанавливает TCP-сессию c сайтом на бэкендах.
Балансер не порвет эту сессию разбросав пакеты по разным серверам в бэкенде, в случае метода DR?
Кроме того, меня интересует, что будет с сессиями?
К примеру, клиент устанавливает TCP-сессию c сайтом на бэкендах.
Балансер не порвет эту сессию разбросав пакеты по разным серверам в бэкенде, в случае метода DR?
И все же, трафик ходит через директора!
Потому что в случае DR используется на самом деле Destination NAT, и, само собой, происходит обратная подстановка при ответе.
Потому что в случае DR используется на самом деле Destination NAT, и, само собой, происходит обратная подстановка при ответе.
нда, ошибся.
В общем DR — это L2 балансировка.
А вот и ответ: Как работает такая балансировка?
На балансировщик, имеющий этот IP-адрес и отвечающий на ARP, приходит, допустим, первый пакет соединения. Мы определяем, что он первый. Нужным алгоритмом отправляем его на интересующий нас сервер, меняя MAC-адрес на место назначения (англ. destination). Записываем его в некоторую таблицу соединений.
Если у нас это не первый пакет, то мы просто смотрим по таблице соединений, каким сервером обрабатывается это соединение, и отправляем его туда.
Т.е. это очень напоминает L2-proxy или L2-NAT ))
В общем DR — это L2 балансировка.
А вот и ответ: Как работает такая балансировка?
На балансировщик, имеющий этот IP-адрес и отвечающий на ARP, приходит, допустим, первый пакет соединения. Мы определяем, что он первый. Нужным алгоритмом отправляем его на интересующий нас сервер, меняя MAC-адрес на место назначения (англ. destination). Записываем его в некоторую таблицу соединений.
Если у нас это не первый пакет, то мы просто смотрим по таблице соединений, каким сервером обрабатывается это соединение, и отправляем его туда.
Т.е. это очень напоминает L2-proxy или L2-NAT ))
А существует ли аналогичный функционал в FreeBSD?
Простой и доступный метод.
Всегда поражался какими костылями делают это при создании кластеров.
Кто своё ПО городит, готовые прокси ставит…
Всегда поражался какими костылями делают это при создании кластеров.
Кто своё ПО городит, готовые прокси ставит…
Экономные делают LVS или Nginx (но этот не все умеет балансить), чуть более извращенные ставят к примеру HAProxy, более извращенные и богатые ставят Cisco ASA и ему подобные
ASA в целом надежнее получается. Кроме нее есть Cisco CCS и аналогичные решения от Juniper. Преимущества — производительность и надежность. Конфигурируется часто проще (есть подробная документация) Недостаток — цена
А можете рассказать, как такое реализовать на ASA?
Я их использую только как фаервол на данный момент.
Я их использую только как фаервол на данный момент.
Метод на самом деле не такой уж простой, ибо имеет много подводных камней с собственно 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.
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?
Теоретически, модуль ядра должен давать лучшею производительность. Но хотелось бы услышать ваше мнение.
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 — анализ заголовков.
Если рассуждать более общими категориями, то L4-роутер на уровне ядра должен быть в разы быстрее L7-роутера и гораздо лучше масштабироваться. Но соответственно вы теряете все преимущества L7 — анализ заголовков.
Познавательно. Про UltraMonkey читал не так давно.
В качестве балансировщика именно для HTTP под виндой можно обойтись NLB.
Немного не понятно, зачем использовать LVS, если есть HAProxy.
Также хотелось бы узнать о средствах балансировки нагрузки именно RDP-трафика. Я встречал только платные решения типа 2XLoadBalancer.
В качестве балансировщика именно для HTTP под виндой можно обойтись NLB.
Немного не понятно, зачем использовать LVS, если есть HAProxy.
Также хотелось бы узнать о средствах балансировки нагрузки именно RDP-трафика. Я встречал только платные решения типа 2XLoadBalancer.
спасибо. отличная статья. сам использую для балансироски CSS
Спасибо. Просто и лаконично! Добавил в мемориз.
спасибо
а как быть с субд?
Кстати, при 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 получит в три раза больше трафика чем первый.
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 получит в три раза больше трафика чем первый.
UFO just landed and posted this here
Да парни, я уже 7 лет сижу на balance-ng — и бед не знаю…
Сессии шарятся, у серверов есть весовые коэф. и работает безотказно.
Не скажу что много трафика проходит — ну в среднем 100 мегабит в пике 300-400 это при 100 мегабитных картах и 8 веб серверах на отдачу.
Сессии шарятся, у серверов есть весовые коэф. и работает безотказно.
Не скажу что много трафика проходит — ну в среднем 100 мегабит в пике 300-400 это при 100 мегабитных картах и 8 веб серверах на отдачу.
Простите за возможно глупый вопрос, я не силен в сетях.
1) Подскажите, как физически соединены Director и Real Server'ы в сеть? У director'а два сетевых ethernet'а, один из которых — для внешнего IP, а другой — в коммутатор с real-серверами?
2) Одинакова ли будет топология сети (физическая) в схемах DR и NAT или нет?
3) Правильно ли я понимаю, вопрос ограничения ~64К открытых портов для данной схемы не актуален?
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, следующая моя статья была как раз про него.
2) В DR исходящие пакеты уходят от серверов напрямую, в NAT же все исходящие пакеты идут назад через директор. В этом случае директор выступает в роли роутера в обе стороны.
3) Честно говоря не задумывался над проблемой. Входящих портов действительно будет не больше ~64К, с исходящими портами не уверен, но вроде бы предпосылок для ограничений нет, кроме очевидного ~64K на сервер.
Кстати для организации HA вместо UltraMonkey рекомендую Pacemaker, следующая моя статья была как раз про него.
Sign up to leave a comment.
Балансировка нагрузки с LVS