Comments 15
Имея образование в области автоматизации и управления, забавно было вдруг наткнуться в докладе на своего рода П-регулятор. Вообще много теоретических работ по поводу распределения нагрузки в многоагентной системе. Тем кто занимается такими проблемами стоит на них обратить внимание.
Соглашусь. Многие недоученные (уж простите, но сам такой был в институте, мат. аппарат «гулял», но усиленно изучал компьютеры, в итоге всё равно пришлось всё выучить) ITшники любят изобретать велосипед.
В данном случае прекрасно бы подошёл PID регулятор с обратной связью для настройки весов + нейросеть для хранения старых коэффициентов.
Идея с нейросетью конечно, «на вскидку», но по-другому учитывать множество факторов влияющих на сиюминутную загрузку будет просто неудобно и трудоёмко.
В данном случае прекрасно бы подошёл PID регулятор с обратной связью для настройки весов + нейросеть для хранения старых коэффициентов.
Идея с нейросетью конечно, «на вскидку», но по-другому учитывать множество факторов влияющих на сиюминутную загрузку будет просто неудобно и трудоёмко.
Я конечно не закончил институт, но это не играет особой роли. Здесь не нужны никакие нейросети и прочее, это пустая трата времени. Вся система подгонки весов была написана за пару часов и не требует хранения предыдущего состояния, поэтому очень проста в эксплуатации. В этом случае ваше образование вам бы скорее помешали достигнуть цели, чем помогли.
Я прошу прощения, вы меня сейчас троллите называя снобом?
Вы же выложили материал претендующий на серьёзный подход (слова типа production и enterprise, нужное подчеркнуть), но сами говорите, что написали за пару часов систему для внятной балансировки кластера из нескольких тысяч серверов?
На мой взгляд у вас уже на уровне GTM — bottleneck и высокий риск потери availability.
Вы меня конечно извините, но сейчас ваша статья больше похожа на рекламу сервиса знакомств, чем на руководство к действию для серьёзных интернет площадок с высокой нагрузкой.
Вы же выложили материал претендующий на серьёзный подход (слова типа production и enterprise, нужное подчеркнуть), но сами говорите, что написали за пару часов систему для внятной балансировки кластера из нескольких тысяч серверов?
На мой взгляд у вас уже на уровне GTM — bottleneck и высокий риск потери availability.
Вы меня конечно извините, но сейчас ваша статья больше похожа на рекламу сервиса знакомств, чем на руководство к действию для серьёзных интернет площадок с высокой нагрузкой.
Да, в докладе речь шла про распределение нагрузки по серверам внутри ДЦ. На уровне датацентров полной отказоустойчивости в данный момент нет, но и датацентров не так уж много.
Алгоритм действительно был запущен и протестирован за пару часов и я не вижу здесь ничего плохого. После запуска он был немного доработан путем выставления лимитов на максимальный/минисальный вес на ядро процессора, чтобы можно было задать адекватный начальный вес и чтобы система не слишком сильно разбалансировалась, когда нарушается обратная связь. Я понимаю, что вам обидно, что в основе лежит простейший п-регулятор, который мы сами изобрели за пару часов и все прекрасно работает в продакшене под нагрузкой и решает все поставленные задачи. Это не повод писать снобисткие комментарии про «неучей», а скорее наоборот. Нужно понимать, что наличие профильного образования для решения этой задачи не требуется и решить ее можно своими силами. Не забывайте, что проблем в крупных системах великое множество, и это лишь одна из них. Нужно уметь думать своей головой и тогда вы сможете быстро и адекватно решать задачи, которые перед вами встают. Безусловно, статья этому не учит, она лишь показывает ход мысли, который нас привел к построению такой системы. Конкретно часть про АСУ на самом деле занимает лишь половину доклада, а вторая часть уже специфична для хайлоада. К ней почему-то ни у кого претензий нет, хотя существует множество способов даже просто реализовать weighted round-robin и они дают сильно различные результаты, которые влияют на распределение нагрузки сильнее, чем «колебания», вызванные п-регулятором.
Алгоритм действительно был запущен и протестирован за пару часов и я не вижу здесь ничего плохого. После запуска он был немного доработан путем выставления лимитов на максимальный/минисальный вес на ядро процессора, чтобы можно было задать адекватный начальный вес и чтобы система не слишком сильно разбалансировалась, когда нарушается обратная связь. Я понимаю, что вам обидно, что в основе лежит простейший п-регулятор, который мы сами изобрели за пару часов и все прекрасно работает в продакшене под нагрузкой и решает все поставленные задачи. Это не повод писать снобисткие комментарии про «неучей», а скорее наоборот. Нужно понимать, что наличие профильного образования для решения этой задачи не требуется и решить ее можно своими силами. Не забывайте, что проблем в крупных системах великое множество, и это лишь одна из них. Нужно уметь думать своей головой и тогда вы сможете быстро и адекватно решать задачи, которые перед вами встают. Безусловно, статья этому не учит, она лишь показывает ход мысли, который нас привел к построению такой системы. Конкретно часть про АСУ на самом деле занимает лишь половину доклада, а вторая часть уже специфична для хайлоада. К ней почему-то ни у кого претензий нет, хотя существует множество способов даже просто реализовать weighted round-robin и они дают сильно различные результаты, которые влияют на распределение нагрузки сильнее, чем «колебания», вызванные п-регулятором.
А можно с этого места
«На мой взгляд у вас уже на уровне GTM — bottleneck и высокий риск потери availability.»
поподробнее?
«На мой взгляд у вас уже на уровне GTM — bottleneck и высокий риск потери availability.»
поподробнее?
Такую же задачу много раз решал на том же оборудовании. В каждом случае использовались разные методы.
Когда нужно было управлять весами членов пула, я реализовал всю логику на самом LTM с помощью iCall.
В другом случае, со стороны сервера управления через iControl REST (rest api) подавались команды на смену весов. И да, в тот раз я наткнулся на проблему с тем, что веса не могут быть выше сотни)
Еще была история, когда веса выставлялись исключительно штатными средствами с помощью WMI или SNMP монитора, а серверы были распределены по разным Priority Group. Поэтому в работе всегда было лишь необходимое количество серверов.
Часто, даже встроенные в LTM методы балансировки Predictive и Observed показывают хорошие результаты.
Не всегда есть возможность заранее угадать какой метод окажется более приемлем. Тратить время на исследование или сразу провести эксперимент — чаще второе менее трудозатратно.
В зависимости от контекста, типа трафика и прочей специфики, разные методы показывают разную эффективность. В статье, и в самом выступлении, хорошо отображены навыки и умение использовать привычные инструменты для решения бизнес задач. Кому-то нейронные сети и pid-регуляторы — у всех разныеинструментывелосипеды.
Когда нужно было управлять весами членов пула, я реализовал всю логику на самом LTM с помощью iCall.
В другом случае, со стороны сервера управления через iControl REST (rest api) подавались команды на смену весов. И да, в тот раз я наткнулся на проблему с тем, что веса не могут быть выше сотни)
Еще была история, когда веса выставлялись исключительно штатными средствами с помощью WMI или SNMP монитора, а серверы были распределены по разным Priority Group. Поэтому в работе всегда было лишь необходимое количество серверов.
Часто, даже встроенные в LTM методы балансировки Predictive и Observed показывают хорошие результаты.
Не всегда есть возможность заранее угадать какой метод окажется более приемлем. Тратить время на исследование или сразу провести эксперимент — чаще второе менее трудозатратно.
В зависимости от контекста, типа трафика и прочей специфики, разные методы показывают разную эффективность. В статье, и в самом выступлении, хорошо отображены навыки и умение использовать привычные инструменты для решения бизнес задач. Кому-то нейронные сети и pid-регуляторы — у всех разные
Спасибо за доклад. Как раз решаю похожую проблему, только у меня ситуация на порядок сложнее :). А можно узнать какая нагрузка балансируется? Ну какой лоад держит например 1 инстанс (количество реквестов, сеть, диск). Так же не увидел ничего про хранение состояния (данные сессии) между серверами. Можно немножко больше подробностей тут?
Нагрузка в среднем измеряется десятками тысяч RPS. Один сервер держит пару сотен RPS и тратит порядка 100 мбит/сек.
Сессии хранятся в отдельных демонах, постепенно эти демона заменяются на тарантул.
Сессии хранятся в отдельных демонах, постепенно эти демона заменяются на тарантул.
gtm да, проблема в этой схеме, как и межДЦ резервирование. Но то до первого инцидента. Мы избавились от gtm полностью. Странная железка, за деньги.
Все остальное, соглашусь с докладчиком, тривиально и не требует знания PID-регуляторов + нейросетей. На изучение api участвующих в балансировке компонент уйдет полдня, + пара часов на написание скрипта с подробным логированием. + несколько дней на наблюдение, дебаг и правки. И институт для таких вещей и даром не нужен)
Все остальное, соглашусь с докладчиком, тривиально и не требует знания PID-регуляторов + нейросетей. На изучение api участвующих в балансировке компонент уйдет полдня, + пара часов на написание скрипта с подробным логированием. + несколько дней на наблюдение, дебаг и правки. И институт для таких вещей и даром не нужен)
Картинка «И вот как стал выглядеть график после». Долго не мог понять, почему вы радуетесь тому, что сделали только хуже, пока не понял, что это сравнение месячного графика с дневным.
Only those users with full accounts are able to leave comments. Log in, please.
Как мы сделали ровную балансировку нагрузки на фронтенд-кластере