Сравнительный анализ методов балансировки трафика

[Saffron]

А как называется такая балансировка, когда нет выделенного балансировщика? Запущенные сервера поддерживают список живых нод и делят работу поровну. Если им приходит чужая работа, они перенаправляют клиента на нужный адрес.

[ramax]

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

Я называю это балансировкой на уровне приложения. Такой метод следует применять очень осторожно: сервер может быть перегружен настолько, что redirect отправить клиенту не сможет.

[xcore78]

Вы имеете в виду именно балансировку траффика или арбитраж кворума?
Если первое, то, как написали до меня, вам придется хорошо защитить систему от «перелива», и в какой-то момент вы всё же начнёте выносить управляющую логику из worker'ов.
Если второе, Paxos вам в помощь.

[Saffron]

Ещё, кстати, интересно. Как можно балансировать трафик, отдаваемый, например, через TOR или i2pc? Вон фейсбук открыл же представительство в TOR. Там же явно не получится обойтись через балансировку на уровне ethernet/ip, надо что-то более высокоуровневое.

[xcore78]

Я не знаю, как работает TOR-инкапсуляция, но балансировка инкапсулированного траффика возможна без persistence на декапсулирующие шлюзы, а оттуда потребуется какая-то маршрутизация на фронт-энд.

Что такое балансировка на уровне ethernet и где она применяется, к сожалению, прокомментировать никак не могу.

[Saffron]

Ну в статье приводился пример с поддельными MAC адресами и другой магией. Проблема с TOR и прочими сетями интересна тем, что я легко могу представить балансировку на уровне приложения, когда клиенты перекидываются между нодами, но не могу придумать юникаста на транспортном уровне.

[ValdikSS]

Все просто — устанавливаете несколько нод с Tor или I2P-роутерерами с одинаковыми ключами сервиса (домена, упрощенно говоря), и трафик между ними балансируется автоматически.

[ramax]

приведены несколько роутеров марки Cisco — для первых двух одновременно поддерживается восемь одинаковых маршрутов, а для последнего поддерживается до 32-х одинаковых маршрутов.

Сразу видно, что человек темой не занимался. Пусть на Sup2T попробует сделать больше 16 ECMP, а я буду ржать в сторонке.

[ramax]

мы являемся провайдером SDN

Это скорее всего, ошибка при расшифровке. Думаю, имелся в виду CDN.

[nckma]

Я вот чего не понимаю… Ну вот раздал балансировщик запросы разным серверам, но ведь база то общая? Понятно, что статический контент можно скопировать на винты всех серверов, хотя опять же вопрос — как сделать это синхронно на все серверах, скажем при апдейте контента сайта.
А что делать с динамическим контентом? Например, интернет магазин, и осталась в продаже одна штука товара.
Два пользователя на разных серверах одновременно хотят ее купить. Как делается общая база данных для всех серверов? Она на отдельном сервере? А его не нужно балансировать?

[dezconnect]

Контент да хоть бы через тот же Ansible.
Базы данных, кластеризируются.

[Saffron]

Это уже вопрос про алгоритмы кластеризации и массово распределённые системы. Есть способы, не без недостатков, правда. CAP теорема, которая не теорема, линеаризуемость, eventual consistency и много других страшных слов помогут найти в гугле релевантную информацию. Если коротко, всё очень сложно, но на практике можно заставить работать.

[bluetooth]

Статический контент можно держать на SAN. Тогда все сервера в кластере будут иметь доступ к одному и тому же статическому контенту.

[phantasm1c]

Хочу добавить, что минус «отсутствие server-affinity при ECMP» применителен далеко не ко всем роутерам.
Juniper серии MX имеет опцию load-balance per-flow, которая как раз обеспечивает этот самый server-affinity:

https://www.juniper.net/techpubs/en_US/junos16.1/topics/concept/routing-policy-security-ecmp-flow-based-forwarding-understanding.html

[gorodnev]

Ремарка на счет решений от интеграторов: Cisco ACE давно похоронили, не выдержал конкуренции со стороны F5.

[xcore78]

Почему-то нет описания проблемы/решения главной задачи балансировщика: минимизация потери пользовательского траффика.

[Sork]

просто для новой презентации :)

— Циска закрыла линейку Cisco ACE и GSS, большинство моделей заканчивают жизнь в этом году, какие-то будут поддерживаться для существующих клиентов до 2019 и ни одну купить уже нельзя (http://www.cisco.com/c/en/us/products/collateral/application-networking-services/ace-4700-series-application-control-engine-appliances/eol_C51-728976.html http://www.cisco.com/c/en/us/products/collateral/application-networking-services/ace-gss-4400-series-global-site-selector-appliances/eol_C51-728977.html
— Cisco CSS это предыдущее поколение балансировщиков перед Cisco ACE и ни CSS ни ACE не умеют выполнять балансировку на уровне DNS. Cisco CSS не поддерживается и не продается уже очень давно.
— для балансировки на уровне DNS у циски был продукт Cisco GSS (Global Site selector), но он тоже закрыт и поддерживается только до 2019 года.

​они рекомендуют переходить на Citrix NetScaller, ​который умеет все в одной коробке/виртуалке.

[AstorS1]

Точно так, но почему-то о Citrix Netscaler у автора вообще нет упоминаний. Может, статья готовилась в годы расцвета CSSов, которые Cisco прикупила уже и не помню в какие времена?