Einstein Опубликовано 20 мая, 2013 (изменено) · Жалоба ЗЫ: Модеры, перенесите в Технические вопросы, пожалста... Нужно реализовать балансировку потока 10 ГБит (преимущественно HTTP) на кластер серверов (до 10 штук). С учетом всех требований High Availability и поддержки BGP (важно). Предварительно вкусно выглядит серия 3750-X (или 4948) у Циско, лицензия IP Services для BGP. Планируется стекировать два коммутатора (для надежности) и зарулить HTTP/HTTPS трафик на ферму через правила PBR, а также задействовать IP SLA HTTP для мониторинга серверов. В нормальном режиме весь трафик размазывается по серверам фермы, в случае если сервер горит / подвисает, маршрут на него деактивируется, и трафик перенаправляется на живые сервера. Также как вариант можно попробовать решить эту задачу на более высокоуровневом железе серии ASR 1000. Хотелось бы услышать мнение по самой схеме реализации (может есть более интересное решение), и по выбору железа для него. С точки зрения цифирок в дата-шитах, все указанные железки вроде гарантированно тянут условия задачи, но всегда есть нюансы... о которых хотелось бы услышать от практиков :-) Изменено 20 мая, 2013 пользователем Einstein Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 20 мая, 2013 · Жалоба как вариант, подойдет балансировщик от Brocade ADX в даташите все написано, на что способен, и да, его перед покупкой можно на тест взять и проверить потянет или нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Einstein Опубликовано 20 мая, 2013 · Жалоба как вариант, подойдет балансировщик от Brocade ADX Насколько распространен в России? Это важно, т.к. популярные девайсы проще доставить, найти модули, спросить совета на форуме по настройке... У Циско есть специализированный балансировщик уровня приложений ACE 4710 - но судя по отсутствию обсуждений на форумах, им никто здесь не пользуется, отсюда мы сразу отбросили все варианты с его использованием. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EDA_SPB Опубликовано 20 мая, 2013 · Жалоба Приветствую. В вопросах балансировки я теоретик, но c Cisco Ace (сервисный модуль для 6500) игрался. Уверен, на этом форуме есть много людей, которые используют его в боевых условиях. Einstein, я что-то не понял как балансировать с помощью PBR. Опишите схему. Может быть, посмотреть в сторону DNS? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Einstein Опубликовано 20 мая, 2013 · Жалоба Einstein, я что-то не понял как балансировать с помощью PBR. Опишите схему. Может быть, посмотреть в сторону DNS? С помощью PBR планируется завернуть на кластер поток HTTP-пакетов. Балансировку веб-трафика по серверам затем предполагается возложить на протоколы динамической маршрутизации. Или это не будет работать? Про DNS также поясните, как именно предлагается балансировать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 20 мая, 2013 · Жалоба 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/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 21 мая, 2013 (изменено) · Жалоба В нормальном режиме весь трафик размазывается по серверам фермы, в случае если сервер горит / подвисает, маршрут на него деактивируется, и трафик перенаправляется на живые сервера. Это идеализация. В самом деле, куда более вероятно, что у вас начнёт тормозить один из веб-серверов(или даже подвиснет веб-сервис, но не упадёт), при этом, естественно, маршрут не деактивируется, но для ваших сабскрайберов это будет выглядеть как "раз через два тормозит открытие странички". Методика балансировки, перебалансировки между серверами и т.п. должна быть несколько более сложно, многокритериальной. А простой резерв http/https можно элементарно обеспечить с помощью DNS и TTL=60 секунд. Т.е. делается несколько A-записей на один dns name, если один сервер умирает(или фиксируется, что он не отвечает/тормозить), то из DNS просто удаляется эта запись. В самом деле, если говорить о веб(и это не статика), то основная "проблема" в резервировании БД(не все БД умеют master-master, ну и некоторые другие нюансы) Изменено 21 мая, 2013 пользователем srg555 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 21 мая, 2013 · Жалоба Уверен, на этом форуме есть много людей, которые используют его в боевых условиях. Почему Вы так решили? Для ISP этот модуль не нужен. Хостинговых ДЦ в России довольно мало, да и там не сильно нужен этот модуль Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
caz Опубликовано 21 мая, 2013 · Жалоба Уверен, на этом форуме есть много людей, которые используют его в боевых условиях. Почему Вы так решили? Для ISP этот модуль не нужен. Хостинговых ДЦ в России довольно мало, да и там не сильно нужен этот модуль для ISP - аппаратный NAT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 21 мая, 2013 · Жалоба А вот интересно, как реализовать подобную (http) схему с High Availability и BGP, но когда ферм несколько и они территориально удалены друг от друга. Имеется в виду чтобы и балансировка работала между ними равномерно и в случае проблемы с одной фермой, она исключалась. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pers123 Опубликовано 21 мая, 2013 (изменено) · Жалоба В приципе для решения этих задач используют: - 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 А почему топик в разделе работа, а не в проводных решениях? Изменено 21 мая, 2013 пользователем pers123 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 21 мая, 2013 · Жалоба Я не понимаю: вы готовы вбухать огромную кучу денег в дорогостояющую фигню, но при этом вы не решите другую проблему: ваш ДЦ отключили. Экскаватор ковшом перерубил оба кабеля питания с трубой в которой вся оптика. Или ваш апстрим с маршрутами намудрил и все ваши десятки и сотни тысяч долларов на бессмысленное железо, которое только самолюбие тешит, идут прахом. Стоит подумать о том, как жить в двух ДЦ сразу =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pers123 Опубликовано 21 мая, 2013 (изменено) · Жалоба Я не понимаю: вы готовы вбухать огромную кучу денег в дорогостояющую фигню, но при этом вы не решите другую проблему: ваш ДЦ отключили. Экскаватор ковшом перерубил оба кабеля питания с трубой в которой вся оптика. Или ваш апстрим с маршрутами намудрил и все ваши десятки и сотни тысяч долларов на бессмысленное железо, которое только самолюбие тешит, идут прахом. Стоит подумать о том, как жить в двух ДЦ сразу =) Вы не понимаете - решения есть для любых задач. В том числе и по георгафически распределенному резервированию и load sharing-у между географически разнесенными площадками. Вопрос стоит в том, какую задачу решаем. Можно решать задачу горизонтального масштабирования, можно рашать задачу повышения надежности. Если говорить о надежности, то надо говорить о рисках, от которых пытаешься застраховаться, когда хочешь повысить надежность. Денег стоит любое решение. Вопрос расчета business impact сбоя и стоимости рисков/простоя, а потом выбора решения адекватного по стоимости реализации со стоимостью простоя - это относительно простой анализ. Это не вопрос для обсуждения на форуме. Изменено 21 мая, 2013 пользователем pers123 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EDA_SPB Опубликовано 21 мая, 2013 · Жалоба С помощью PBR планируется завернуть на кластер поток HTTP-пакетов. Этот момент совершенно непонятен. Задача у вас переправлять запросы от пользователей на некий IP на ферму серверов по какому-нибудь алгоритму (Балансировка на 3-4 уровне, как делает, например cisco ace). На мой взгляд, PBR тут не помощник. А вот интересно, как реализовать подобную (http) схему с High Availability и BGP, но когда ферм несколько и они территориально удалены друг от друга. Имеется в виду чтобы и балансировка работала между ними равномерно и в случае проблемы с одной фермой, она исключалась. Посмотрите в сторону anycast. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 22 мая, 2013 · Жалоба Я бы, на месте автора начал с nginx), а так Brocade ADX/ServerIron, но, вот мы, к примеру, не используем ServerIron, хотя он на полке лежит, потому что нам nginx-а хватает пока для решения задач липкой балансировки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Einstein Опубликовано 22 мая, 2013 (изменено) · Жалоба Это идеализация. В самом деле, куда более вероятно, что у вас начнёт тормозить один из веб-серверов(или даже подвиснет веб-сервис, но не упадёт), при этом, естественно, маршрут не деактивируется, но для ваших сабскрайберов это будет выглядеть как "раз через два тормозит открытие странички". Методика балансировки, перебалансировки между серверами и т.п. должна быть несколько более сложно, многокритериальной. Для этого планируется задействовать IP SLA, судя по докам достаточно сложные проверки деградации сервиса можно проверять :-) Этот момент совершенно непонятен. Задача у вас переправлять запросы от пользователей на некий IP на ферму серверов по какому-нибудь алгоритму (Балансировка на 3-4 уровне, как делает, например cisco ace). На мой взгляд, PBR тут не помощник. Почему не помощник? Задачу верно расписали, на серверах крутятся прозрачные прокси. Я бы, на месте автора начал с nginx), а так Brocade ADX/ServerIron Это другой ценовой диапазон :-) Пока смотрим еще и в сторону железок, которые имеют фичи Server Load Balancing (Cisco ASR, Juniper MX) Изменено 22 мая, 2013 пользователем Einstein Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bifit Опубликовано 22 мая, 2013 · Жалоба попробуйте haproxy на двухсокетном E5-2680 c двумя 10GbE (i82599). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...