[Einstein]

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

 

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

 

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

 

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

 

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

 

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

 

 

 

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

Edited May 20, 2013 by Einstein

[caz]

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

[Einstein]

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

 

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

 

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

[EDA_SPB]

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

 

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

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

 

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

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

[Einstein]

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

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

 

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

 

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

[caz]

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/

[srg555]

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

 

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

 

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

Edited May 21, 2013 by srg555

[srg555]

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

 

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

[caz]

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

 

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

 

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

[Minya]

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

[pers123]

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

- 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

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

Edited May 21, 2013 by pers123

[maxlapshin]

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

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

 

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

[pers123]

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

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

 

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

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

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

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

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

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

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

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

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

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

Edited May 21, 2013 by pers123

[EDA_SPB]

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

 

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

 

 

 

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

 

 

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

[dignity]

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

[Einstein]

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

 

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

 

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

 

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

 

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

 

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

Edited May 22, 2013 by Einstein

[bifit]

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