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