Балансировка на ферму серверов - посоветуйте

ЗЫ: Модеры, перенесите в Технические вопросы, пожалста...

 

Нужно реализовать балансировку потока 10 ГБит (преимущественно HTTP) на кластер серверов (до 10 штук). С учетом всех требований High Availability и поддержки BGP (важно).

 

Предварительно вкусно выглядит серия 3750-X (или 4948) у Циско, лицензия IP Services для BGP.

 

Планируется стекировать два коммутатора (для надежности) и зарулить HTTP/HTTPS трафик на ферму через правила PBR, а также задействовать IP SLA HTTP для мониторинга серверов.

 

В нормальном режиме весь трафик размазывается по серверам фермы, в случае если сервер горит / подвисает, маршрут на него деактивируется, и трафик перенаправляется на живые сервера.

 

Также как вариант можно попробовать решить эту задачу на более высокоуровневом железе серии ASR 1000.

 

 

 

Хотелось бы услышать мнение по самой схеме реализации (может есть более интересное решение), и по выбору железа для него. С точки зрения цифирок в дата-шитах, все указанные железки вроде гарантированно тянут условия задачи, но всегда есть нюансы... о которых хотелось бы услышать от практиков :-)

Изменено пользователем Einstein

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

как вариант, подойдет балансировщик от Brocade ADX в даташите все написано, на что способен, и да, его перед покупкой можно на тест взять и проверить потянет или нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

как вариант, подойдет балансировщик от Brocade ADX

 

Насколько распространен в России? Это важно, т.к. популярные девайсы проще доставить, найти модули, спросить совета на форуме по настройке...

 

У Циско есть специализированный балансировщик уровня приложений ACE 4710 - но судя по отсутствию обсуждений на форумах, им никто здесь не пользуется, отсюда мы сразу отбросили все варианты с его использованием.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую.

 

В вопросах балансировки я теоретик, но c Cisco Ace (сервисный модуль для 6500) игрался.

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

 

Einstein, я что-то не понял как балансировать с помощью PBR. Опишите схему.

Может быть, посмотреть в сторону DNS?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Einstein, я что-то не понял как балансировать с помощью PBR. Опишите схему.

Может быть, посмотреть в сторону DNS?

 

С помощью PBR планируется завернуть на кластер поток HTTP-пакетов. Балансировку веб-трафика по серверам затем предполагается возложить на протоколы динамической маршрутизации. Или это не будет работать?

 

Про DNS также поясните, как именно предлагается балансировать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Einstein, я что-то не понял как балансировать с помощью PBR. Опишите схему.

Может быть, посмотреть в сторону DNS?

 

С помощью PBR планируется завернуть на кластер поток HTTP-пакетов. Балансировку веб-трафика по серверам затем предполагается возложить на протоколы динамической маршрутизации. Или это не будет работать?

 

Про DNS также поясните, как именно предлагается балансировать?

 

PBR вам там не нужен.

ну так, для примера http://brocade-ip.blogspot.ru/2010/09/brocade.html http://dreamcatcher.ru/2013/03/19/%D0%9A%D1%80%D0%B0%D1%82%D0%BA%D0%B8%D0%B9-how-to-%D0%BF%D0%BE-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B5-brocade-adx-1000/

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В нормальном режиме весь трафик размазывается по серверам фермы, в случае если сервер горит / подвисает, маршрут на него деактивируется, и трафик перенаправляется на живые сервера.

 

Это идеализация. В самом деле, куда более вероятно, что у вас начнёт тормозить один из веб-серверов(или даже подвиснет веб-сервис, но не упадёт), при этом, естественно, маршрут не деактивируется, но для ваших сабскрайберов это будет выглядеть как "раз через два тормозит открытие странички". Методика балансировки, перебалансировки между серверами и т.п. должна быть несколько более сложно, многокритериальной.

 

А простой резерв http/https можно элементарно обеспечить с помощью DNS и TTL=60 секунд. Т.е. делается несколько A-записей на один dns name, если один сервер умирает(или фиксируется, что он не отвечает/тормозить), то из DNS просто удаляется эта запись. В самом деле, если говорить о веб(и это не статика), то основная "проблема" в резервировании БД(не все БД умеют master-master, ну и некоторые другие нюансы)

Изменено пользователем srg555

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Почему Вы так решили? Для ISP этот модуль не нужен. Хостинговых ДЦ в России довольно мало, да и там не сильно нужен этот модуль

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Почему Вы так решили? Для ISP этот модуль не нужен. Хостинговых ДЦ в России довольно мало, да и там не сильно нужен этот модуль

 

для ISP - аппаратный NAT.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот интересно, как реализовать подобную (http) схему с High Availability и BGP, но когда ферм несколько и они территориально удалены друг от друга. Имеется в виду чтобы и балансировка работала между ними равномерно и в случае проблемы с одной фермой, она исключалась.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В приципе для решения этих задач используют:

- http://www.f5.com/products/big-ip/big-ip-local-traffic-manager/overview/

- http://www.brocade.com/products/all/application-delivery-switches/index.page

- http://www.radware.com/Products/ApplicationDelivery/Alteon/default.aspx

Это лидеры рынка.

Достаточно много людей использют в россии все эти решения, просто в основном это Over-the-TOP провайдеры

или люди, для которых http/https front-end критичен.

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

 

Off-TOP

А почему топик в разделе работа, а не в проводных решениях?

Изменено пользователем pers123

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не понимаю: вы готовы вбухать огромную кучу денег в дорогостояющую фигню, но при этом вы не решите другую проблему: ваш ДЦ отключили. Экскаватор ковшом перерубил оба кабеля питания с трубой в которой вся оптика.

Или ваш апстрим с маршрутами намудрил и все ваши десятки и сотни тысяч долларов на бессмысленное железо, которое только самолюбие тешит, идут прахом.

 

Стоит подумать о том, как жить в двух ДЦ сразу =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не понимаю: вы готовы вбухать огромную кучу денег в дорогостояющую фигню, но при этом вы не решите другую проблему: ваш ДЦ отключили. Экскаватор ковшом перерубил оба кабеля питания с трубой в которой вся оптика.

Или ваш апстрим с маршрутами намудрил и все ваши десятки и сотни тысяч долларов на бессмысленное железо, которое только самолюбие тешит, идут прахом.

 

Стоит подумать о том, как жить в двух ДЦ сразу =)

Вы не понимаете - решения есть для любых задач.

В том числе и по георгафически распределенному резервированию и load sharing-у между географически разнесенными площадками.

Вопрос стоит в том, какую задачу решаем.

Можно решать задачу горизонтального масштабирования, можно рашать задачу повышения надежности.

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

Денег стоит любое решение.

Вопрос расчета business impact сбоя и стоимости рисков/простоя, а потом выбора решения адекватного по стоимости реализации со стоимостью простоя -

это относительно простой анализ.

Это не вопрос для обсуждения на форуме.

Изменено пользователем pers123

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С помощью PBR планируется завернуть на кластер поток HTTP-пакетов.

 

Этот момент совершенно непонятен. Задача у вас переправлять запросы от пользователей на некий IP на ферму серверов по какому-нибудь алгоритму (Балансировка на 3-4 уровне, как делает, например cisco ace). На мой взгляд, PBR тут не помощник.

 

 

 

А вот интересно, как реализовать подобную (http) схему с High Availability и BGP, но когда ферм несколько и они территориально удалены друг от друга. Имеется в виду чтобы и балансировка работала между ними равномерно и в случае проблемы с одной фермой, она исключалась.

 

 

Посмотрите в сторону anycast.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я бы, на месте автора начал с nginx), а так Brocade ADX/ServerIron, но, вот мы, к примеру, не используем ServerIron, хотя он на полке лежит, потому что нам nginx-а хватает пока для решения задач липкой балансировки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это идеализация. В самом деле, куда более вероятно, что у вас начнёт тормозить один из веб-серверов(или даже подвиснет веб-сервис, но не упадёт), при этом, естественно, маршрут не деактивируется, но для ваших сабскрайберов это будет выглядеть как "раз через два тормозит открытие странички". Методика балансировки, перебалансировки между серверами и т.п. должна быть несколько более сложно, многокритериальной.

 

Для этого планируется задействовать IP SLA, судя по докам достаточно сложные проверки деградации сервиса можно проверять :-)

 

Этот момент совершенно непонятен. Задача у вас переправлять запросы от пользователей на некий IP на ферму серверов по какому-нибудь алгоритму (Балансировка на 3-4 уровне, как делает, например cisco ace). На мой взгляд, PBR тут не помощник.

 

Почему не помощник? Задачу верно расписали, на серверах крутятся прозрачные прокси.

 

Я бы, на месте автора начал с nginx), а так Brocade ADX/ServerIron

 

Это другой ценовой диапазон :-) Пока смотрим еще и в сторону железок, которые имеют фичи Server Load Balancing (Cisco ASR, Juniper MX)

Изменено пользователем Einstein

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

попробуйте haproxy на двухсокетном E5-2680 c двумя 10GbE (i82599).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0