Почему алгоритм балансировки нагрузки не позволяет выбирать рабочие машины на основе текущего процессора или использования памяти
В настоящее время я изучаю балансировку нагрузки с помощью Apache mod_load_balancer и mod_proxy. Я также буду смотреть на другие балансировщики нагрузки позже, но одна вещь стала ясной. Почему вряд ли кто-либо из балансировщиков нагрузки (если вообще вообще) принимает решения о распределении на основе фактической нагрузки на рабочие машины.
Апач, например, распределяет запросы на основе количества запросов, объема пропускной способности данных и длины очереди запросов. Почему у них нет какого-то механизма для распределения запросов к машине с самым низким использованием процессора или памяти.
Я строю систему, в которой для каждого запроса требуется много ЦП, так что 2 или 3 рабочих компьютера могут обслуживать только 10 или 20 одновременно работающих клиентов до того, как я максимизирую все их ЦП. Некоторые запросы на xml действительно легкие, а другие на "вещи" действительно тяжелые.
Это действительно имеет какое-то значение в схеме вещей? Находит ли кто-нибудь, что даже алгоритм распределения на основе ЦП в конечном итоге приобретает стиль циклического перебора? Добавляет ли это дополнительные накладные расходы, что делает его не стоящим.
Существуют ли другие балансировщики нагрузки, которые предлагают это средство, предлагают ли они его, и никто не использует его по какой-либо причине?
Кажется, что-то, что было бы действительно хорошо, но никто, кажется, не реализует это. Я запутался и мне нужно немного советов по этому вопросу.
2 ответа
Одна из основных проблем балансировки нагрузки на основе ресурсов заключается в том, что информация о нагрузке устареет к тому времени, когда вы примете решение о маршрутизации. Есть статья по теме устарелости, которую вы можете прочитать, под названием " Интерпретация информации о нагрузке состояния". Вы можете получить неприятные побочные эффекты, такие как отправка слишком большой нагрузки в ящик, который кажется недостаточно загруженным, а затем сокрушить его. Короче говоря, балансировка на основе нагрузки кажется на первый взгляд лучшим способом сделать это для всех, но оказывается, что простые методы имеют тенденцию работать лучше на практике.
В большинстве балансировки нагрузки простые алгоритмы обычно хороши, потому что либо транзакции недолговечны, либо вызывают настолько низкую нагрузку, что циклическое или случайное распределение будет достаточно близко к хорошему балансу. Как правило, в любом случае должны быть накладные расходы для поглощения нагрузки от неисправных серверов (если вы близки к максимальному использованию на всех 3, как только один из них умирает, нагрузка будет каскадной, и вы потеряете весь кластер).
Одним из решений может быть создание двух очередей, одна для "тяжелых вещей" и одна для "легких вещей". Я бы назвал балансировку нагрузки "легкие вещи" и планирование работы "тяжелые вещи" - другими словами, они кажутся разными проблемами. Тогда просто ограничьте максимальное количество сеансов для каждого клиента и универсальную очередь для них для планирования заданий. Хотя я не знаю идеального инструмента для этого на макушке.
Как правило, я обнаружил, что "нагрузка" - это очень специфический термин, который происходит от большого числа метрик, которые варьируются от приложения к приложению. Поскольку ни один балансировщик нагрузки внешнего интерфейса не может знать эту деталь (из коробки) и тот факт, что циклический перебор с некоторыми тщательно настроенными пределами соединения в основном работает, это не всегда стоит боли.
В средах, в которых я работаю, где приложения разрабатываются собственными силами, я стараюсь, чтобы страница "монитора" была частью приложения, которое балансировщик нагрузки использует для контроля состояния узла (т. Е. Вверх / вниз). Затем его можно расширить, включив в него целочисленный коэффициент загрузки, который балансировщик нагрузки может использовать для настройки нагрузки на этот узел. Все, что мы определяем, это согласованный интерфейс и то, что это целочисленное значение заставит балансировщик нагрузки делать. Затем приложения и нагрузочное тестирование должны убедиться, что приложение не делает ничего лишнего для загрузки дистрибутива.
Вслед за упоминанием Кайлом Брандтом рабочих очередей один из альтернативных методов балансировки нагрузки заключается в том, что работники извлекают запросы из очереди, а не стандартный балансировщик нагрузки, отправляющий запросы работнику (или в зависимости от обстоятельств)., Примером такой настройки является веб-сервер Mongrel2 ( http://mongrel2.org/), который использует 0MQ ( http://www.zeromq.org//) в качестве механизма распространения для работников приложений. Поскольку машина замедляется из-за интенсивной обработки, она не будет получать новые запросы из очереди. Вы все еще можете столкнуться с множеством "тяжелых" запросов, которые могут быть получены сразу, но проблема становится проще для работников. Было бы довольно тривиально разделить работу на "типизированные" очереди, как предложил Кайл. Это довольно большое изменение для бэкэнд-приложения, поддерживающего получение запросов 0MQ, но если вы начинаете с нуля, то это может быть путь вперед.