LINUX.ORG.RU
ФорумAdmin

Как настроить равномерную балансировку трафика между HaProxy нодами?


0

3

Как настроить равномерную балансировку трафика между HaProxy нодами? Тоесть, если существует несколько фронтенд-нод HaProxy(балансирующих трафик на какие-либо бекенд-сервисы), образующих единый виртуальный ip адрес и которые работают например в режиме master-slave, используя keepalived или heartbeat(как обнаружитель недоступности и переключатель), когда виртуальный адрес HaProxy и другие ресурсы одновременно держит только одна нода(master) и переключает ресурсы и адрес на slave только при условии недуступности master'а.

Вот вопрос заключается в том, чтобы балансировать трафик между этими двумя фронтовыми HaProxy-нодами одновременно и равномерно. Какие решения обычно для этого используются? Как вариант, использовать еще одну HaProxy-ноду перед этими двумя HaProxy узлами, или использовать VRRP, таким образом расширяя схему горизонтально, может есть еще какие-то варианты?

★★

Последнее исправление: ChAnton (всего исправлений: 1)

1. DNS Round Robin плюс keepalived.

Поднимаешь два виртуальных айпи адреса, каждая из 2 нод является мастером для своего адреса. Нагрузка балансируется через DNS, а если нода падает то вторая будет держать оба адреса.

2. VRRP не позволяет балансировать нагрузку, это умеет только GLBP от цыски.

blind_oracle ★★★★★
()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

1. DNS Round Robin плюс keepalived.

Это хороший вариант. Но если представить ситуацию с долгим кешем? Часть трафика же может на какое-то время просто пропасть... Даже если учитывать минимально возможные значения TTL для трансфера зон.

ChAnton ★★
() автор топика
Ответ на: комментарий от ChAnton

А с чего ему пропасть? Я тебе сверху написал схему. У тебя днс указывает на два-три-десять виртуальных адресов, которые держат фронтэнды в режиме мастер-слейв. Если любой из них упадёт, то айпи адреса будет держать его оставшийся слейв - все запросы через ДНС пойдут на него. Потери не будет.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

А если упадет одна связка master-slave целиком, тоесть один или несколько из виртуальных адресов одномоментно окажется недоступным? Ну например вывалился полностью сегмент маршрутизации, или даже AS. Да все что угодно. Я понимаю что DNS по roundrobin будет разбрасывать соединения по оставшимся виртуальным адресам. Но закешированная часть отвалившегося адреса будет потеряна на время. В каких-то сегментах сетей.

ChAnton ★★
() автор топика
Ответ на: комментарий от ChAnton

А если из-за землетрясения ДЦ уйдёт под землю? :)

Отказоустойчивостью автономных систем и сопутствующего роутинга занимаются совсем другие девайсы и протоколы (BGP сотоварищи).

К нашему вопросу это не относится, да и сделать с этим ничего нельзя.

В любом случае, если это HTTP, то современные браузеры при невозможности соедениться с одним из IP адресов из ДНС пробуют другие автоматически.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

К нашему вопросу это не относится, да и сделать с этим ничего нельзя.

О! А вот это уже конкретный ответ) Не примите за издевку, это не так. К нашему вопросу это как раз относиться напрямую. Поскольку меня как раз интересует возможность/невозможность провернуть такую штуку как раз с одним адресом, без привлечения сторонних сервисов типа DNS в данном случае. Желательно. По целому ряду причин, таких как например четкое управление балансировкой нагрузки и прочее.

В любом случае, если это HTTP, то современные браузеры при невозможности соедениться с одним из IP адресов из ДНС пробуют другие автоматически.

Вот хотелось бы получить результат без привлечение(доходжения) клиента до обращения к DNS. Сами понимаете почему)

ChAnton ★★
() автор топика
Ответ на: комментарий от blind_oracle

Кстати говоря, подрыв или разрушение ДЦ в результате внешнего воздействия вполне себе объективная рисковая составляющая политики обеспечения отказоустойчивости(доступности) и безопасности вцелом.

ChAnton ★★
() автор топика
Ответ на: комментарий от ChAnton

Я бы советовал оценивать реальные риски, а не теоретические.

И не недооценивать использование round-robin DNS, за примерами далеко ходить не надо:

# host yandex.ru
yandex.ru has address 77.88.21.11
yandex.ru has address 87.250.250.11
yandex.ru has address 93.158.134.11
yandex.ru has address 213.180.193.11
yandex.ru has address 213.180.204.11

# host google.com
google.com has address 74.125.232.64
google.com has address 74.125.232.70
google.com has address 74.125.232.78
google.com has address 74.125.232.68
google.com has address 74.125.232.73
google.com has address 74.125.232.69
google.com has address 74.125.232.66
google.com has address 74.125.232.72
google.com has address 74.125.232.65
google.com has address 74.125.232.71
google.com has address 74.125.232.67
Как говорится - рекомендации лучших собаководов.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Не бывает «теоретических» рисков. Как показывает практика-все риски являются вполне реальными.

И не недооценивать использование round-robin DNS, за примерами >далеко ходить не надо

Никто не собирается недооценивать преимущества и функциональность технологии roundrobin, но у каждого решения есть своя область применения, нюансы и ограничения. Некоторые уже были озвучены.

Как говорится - рекомендации лучших собаководов.

Ну у этих «собаководов» помимо roundrobin dns существует масса иных, дополнительныз решений для осуществления избыточности. К тому же и технологические и технические возможности намного более широкие и гибкие) В том числе и при использовании rdns) В том числе и манипулирование BGP трафиком, и наличие собственных выделенных и арендованных магистральных каналов и так далее...

А вот если все-таки отбросить вообще использование dns или манипуляции с ним...

ChAnton ★★
() автор топика
Ответ на: комментарий от ChAnton

Бывают риски, которыми можно пренебречь при решении реальных задач. Не стоит спорить на эту тему, я думаю. Практически никто, кроме вояк и очень крупных корпораций не планирует HA системы с расчетом на падение на ДЦ метеорита. Давай закончим с этим.

у у этих «собаководов» помимо roundrobin dns существует масса иных, дополнительныз решений для осуществления избыточности. К тому же и технологические и технические возможности намного более широкие и гибкие) В том числе и при использовании rdns) В том числе и манипулирование BGP трафиком, и наличие собственных выделенных и арендованных магистральных каналов и так далее...

Какие у них есть средства, недоступные «тебе» в лице не такой большой компании? Регистрируй AS, это стоит смешных денег, ставь роутер с BGP, делай пиринг с 2+ провайдерами. И манипулируй этим BGP сколько угодно. Но это опять таки отдельная тема, в которой уже давно всё разжевано. И толстые книги написаны про ускорение сходимости BGP.

Если отталкиваться от фронтэндов, то тут больше ничего сделать нельзя, т.к. это фундаментальные ограничения текущих технологий. Если без RRDNS, то точка входа - единственный IP адрес, который либо реальный, либо виртуальный на VRRP и т.п. что накладывает эти ограничения.

blind_oracle ★★★★★
()
Ответ на: комментарий от ChAnton

почему с твоим единственным айпи не может случиться описанная тобой же ситуация? =)

образующих единый виртуальный ip
например вывалился полностью сегмент маршрутизации, или даже AS

с единым айпи проблемы будут точно те же, что и с несколькими.
или я во что-то не врубился?

Komintern ★★★★★
()
Ответ на: комментарий от blind_oracle

Бывают риски, которыми можно пренебречь при решении реальных >задач. Не стоит спорить на эту тему, я думаю. Практически >никто, кроме вояк и очень крупных корпораций не планирует HA >системы с расчетом на падение на ДЦ метеорита. Давай закончим с >этим.

Еще раз. Нет таких рисков, которыми бы следовало пренебрегать. Это не спор, а очевидный факт. А также требования всех без исключения стандартов безопасности. При чем тут спор? Почитайте их. И не надо рассказывать, все кто планирует более-менее серьезные решения направленные на организацию схем высокой доступности, планирует весь спектр мер и мероприятий по обеспечению такой надежности. Это не выдуманный, а вполне объективный факт. А кто не думает о таких мерах, или как выразились принебрегает ими, тот не способен к принятию подобных решений по обеспечению безопасности инфраструктуры. Это называется сами знаете как. Так что не закончим. Потому как в том числе такие вот якобы «перестраховочные»(а на самом деле вполне нормальные и правильные с точки зрения информационной безопасности любой деятельности) решения меня интересуют в первую очередь. Если не думать о метеоритах, тогда можно вообще не задумываться об отказоусточивой инфраструктуре. Вы видимо никогда не сталкивались с такими проблемами, раз столь самоуверены.

Тоесть меня как раз интересует не рассуждения на тему надо/не надо, а технические решения, исходя из того факта, что по-умолчанию НАДО!)

Какие у них есть средства, недоступные «тебе» в лице не такой >большой компании? Регистрируй AS, это стоит смешных денег, >ставь роутер с BGP, делай пиринг с 2+ провайдерами. И >манипулируй этим BGP сколько угодно. Но это опять таки >отдельная тема, в которой уже давно всё разжевано. И толстые >книги написаны про ускорение сходимости BGP.

Это тоже одно их решений. Но опять таки, завязанное на глобальную сеть, также как и служба DNS.

Если отталкиваться от фронтэндов, то тут больше ничего сделать >нельзя, т.к. это фундаментальные ограничения текущих >технологий. Если без RRDNS, то точка входа - единственный IP >адрес, который либо реальный, либо виртуальный на VRRP и т.п. >что накладывает эти ограничения.

Да, я вот пока тоже ничего другого не придумал и не представил(

Спасибо вам большое за ваше мнение.

ChAnton ★★
() автор топика
Ответ на: комментарий от Komintern

с единым айпи проблемы будут точно те же, что и с несколькими.
или я во что-то не врубился?

Видимо «не врубился»))) Шутка. Почитайте внимательно о чем конкретоно речь.

Дело в том, что виртуальных IP должно быть много. Тоесть ферма из виртуальных IP (на каждом из которых по несколько хостов жеоательно в балансировке), и внутри это фермы из нескольких виртуальных IP должна быть также балансировка трафика.

ChAnton ★★
() автор топика
Ответ на: комментарий от ChAnton

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

Komintern ★★★★★
()
Ответ на: комментарий от Komintern

ферма виртуальных айпи.. в балансировке.. внутри фермы еще >виртуальные айпи и еще балансировка..

Примерно так, тоесть ферма реальных узлов с одним виртуальным IP. Таких ферм(тоесть по-сути виртуальных IP-адресов) много. И необходимо построить ферму из нескольких таких ферм узлов с виртуальными IP, с балансировкой трафика между виртуальными IP адресами(тоесть группами ферм с реальными хостами).

А почему в теории? Ни вижу никаких причин в невозможности работать такой схеме на практике.

ChAnton ★★
() автор топика
Ответ на: комментарий от blind_oracle

К нашему вопросу это не относится, да и сделать с этим ничего нельзя.

Если есть своя аска и много апстримов - то можно :)

tazhate ★★★★★
()
Ответ на: комментарий от tazhate

Да, AS одно из приемлемых решений, наряду с RDNS, можно реализовывать комплексно, в совокупности решений.

ChAnton ★★
() автор топика
Ответ на: комментарий от blind_oracle

И не недооценивать использование round-robin DNS, за примерами далеко ходить не надо:

Только вот если одна из айпишек ляжет, в списке она останется ;)

tazhate ★★★★★
()
Ответ на: комментарий от ChAnton

По целому ряду причин, таких как например четкое управление балансировкой нагрузки и прочее.

Поллер на heartbeat меняешь на более адекватный, а именно в бесконечный notify (раз в 100-10мс) со стороны таргет-ноды на «центр управления» и тогда эта схема заработает.

Однако, искать серебрянную пулю как ты сам понял - бесполезно. Используй доступные средства и не морочь голову.

gh0stwizard ★★★★★
()
Ответ на: комментарий от tazhate

современные браузеры при невозможности соедениться с одним из IP адресов из ДНС пробуют другие автоматически

Komintern ★★★★★
()
Ответ на: комментарий от Komintern

современные браузеры при невозможности соедениться с одним из IP адресов из ДНС пробуют другие автоматически

Не у всех современные браузеры.

tazhate ★★★★★
()
Ответ на: комментарий от Komintern

современные браузеры при невозможности соедениться с одним из >IP адресов из ДНС пробуют другие автоматически

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

А также, кроме WEB есть и другие приложения, например работающие через тот же haproxy. Если вообще DNS на время исключить из обсуждения.

ChAnton ★★
() автор топика
Ответ на: комментарий от tazhate

А с чего бы ей лечь? Если айпишка виртуальная, то её можно поддерживать даже из разных датацентров. Если один ДЦ ляжет, то VRRP переключит активную ноду на другой, а BGP аплинка после потери пиринга с этим ДЦ перестроится на второй. Это, конечно, займёт какое-то время, но большинство клиентов этого даже не заметят.

blind_oracle ★★★★★
()
Ответ на: комментарий от ChAnton

AS не даст тебе распределения нагрузки по фронтэндам, ты мешаешь мух с котлетами. AS+VRRP - отказоустойчивость, RRDNS - распределение нагрузки и, в какой-то мере, тоже отказоустойчивость.

blind_oracle ★★★★★
()
Ответ на: комментарий от ChAnton

Так их и надо комплексно применять, как жеж иначе то?

blind_oracle ★★★★★
()
Ответ на: комментарий от tazhate

Только вот если одна из айпишек ляжет, в списке она останется ;)

в случае rrdns, обычно, отключают днс кэш на клиенте/фронт-энде ;)

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

в случае rrdns, обычно, отключают днс кэш на клиенте/фронт-энде >;)

А если где-то в других кешах застрянет?

ChAnton ★★
() автор топика
Ответ на: комментарий от ChAnton

А если где-то в других кешах застрянет?

если в цепи задействован неподконтрольный dns, то так и будут долбить по первому адресу. а так на своём dns сервере прописываешь stub zone где все ноды dns мастеры и будет счастье.

EvgGad_303 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.