Я реализовал простое ограничение скорости с помощью HaProxy аналогично тому, как StackExchange Является ли с HaProxy. Я пытаюсь сделать его немного более продвинутым, чтобы было несколько пороговых значений ограничения скорости.
Например, ограничьте количество клиентов, которые запрашивают:
15 в минуту
60 / час
360 / день
Похоже, мне нужно несколько стик-таблиц для хранения одних и тех же данных с разными частотами дискретизации. В документации указано:
На каждый прокси есть только один стик-стол. На момент написания этого документа не представлялось полезным иметь несколько таблиц для каждого прокси. Если это необходимо, просто создайте фиктивный бэкэнд с таблицей стикеров в нем и сделайте ссылку на него.
К сожалению, у меня чертовски много времени, пытаясь понять, как сохранить данные в фиктивных таблицах серверной части.
Я также открыт для других методов, HaProxy просто казался многообещающим, и, поскольку он у нас уже есть в среде, это имело смысл. Любые предложения приветствуются.
Я просто пытался сделать это сам, мне не повезло, и я решил прибегнуть к своему гугл-фу. Лучшим результатом для меня при поиске нескольких уровней ограничения скорости было это, и я был очень взволнован. Затем я увидел, что у него нет ответов, и поначалу впал в экзистенциальную яму отчаяния. Выкопавшись, я продолжил взламывать и, по некоторой удаче, похоже, понял, как это сделать, по крайней мере, для того, что мне было нужно. Может быть, это сработает и для вас.
Haproxy действительно, действительно крутой, и я рад начать использовать его вместо нашего текущего решения по балансировке нагрузки, но Stick-таблицы - это что-то вроде монстра, с которым можно обернуться. На этом фронте я нашел один общий принцип, который, кажется, мне помогает, а именно: каждый прикрепите стол по имени, когда вы пытаетесь настроить несколько столов. Поведение по умолчанию, когда имя неявно (предполагается, что это серверная часть, в которой вы находитесь), великолепно ... кроме случаев, когда вы начинаете пытаться пофантазировать с несколькими таблицами Stick. Вот почему в моей конфигурации ниже некоторые из них более подробны, чем должны быть. Мне просто так легче следовать логике. В любом случае, вот оно (обратите внимание, что это подсчет на основе файлов cookie для приложения Moodle, а не IP, и он использует v1.5.11 haproxy):
backend dynamic_60
stick-table type string len 36 size 1m store gpc0_rate(60s)
backend dynamic
stick-table type string len 36 size 1m store gpc0_rate(10s)
stick on cookie(MoodleSession) table dynamic
stick on cookie(MoodleSession) table dynamic_60
tcp-request content track-sc0 cookie(MoodleSession) table dynamic
tcp-request content track-sc1 cookie(MoodleSession) table dynamic_60
acl rate_10s sc0_inc_gpc0(dynamic) gt 0
acl rate_60s sc1_inc_gpc0(dynamic_60) gt 0
tcp-request content reject if rate_10s rate_60s FALSE
Таким образом, мы устанавливаем один счетчик для записи скорости за 10 секунд, а другой - для записи скорости за 60 секунд. Обратите внимание, что на самом деле он еще не использует эти счетчики для ограничения скорости. Но вы можете проверить через:
echo "show table dynamic" | socat /var/run/haproxy/admin.sock stdio
echo "show table dynamic_60" | socat /var/run/haproxy/admin.sock stdio
Что счетчики тарифов обслуживаются отдельно.
Я хотел выяснить минимальную конфигурацию, которая мне нужна, чтобы заставить эти счетчики фактически увеличиваться, поэтому вы видите «FALSE» в конце оператора «tcp-request content reject». Простое определение ACL с помощью счетчиков не приведет к их увеличению. Фактически вы должны использовать acl. Ввод "FALSE" в конце просто позволяет мне использовать acl, даже не выполняя условия для фактического отклонения запроса. Я, вероятно, просто уберу "ЛОЖЬ", как только определюсь с некоторыми действительно числами для этих ACL.
Настоящий ключ к тому, чтобы заставить работать несколько таблиц стикеров, похоже, выполняет определения «stick on», «track-sc {0 | 1 | 2}» и acl с использованием «sc {0,1,2} _inc_gpc0» в бэкэнд, на котором вы фактически обрабатываете запрос. Перемещение любого из них в бэкэнд dynamic_60 привело к тому, что счетчик перестал работать. Я предполагаю, что причина в том, что нет смысла отслеживать или применять ACL к бэкэнду, который не обслуживает запросы, потому что на самом деле у него нет проходящих запросов для получения информации. Тем не менее, я уверен, что у других будут лучшие объяснения. Я новичок в haproxy.
Следующий вопрос, который я задал, был: ограничен ли я отслеживанием только трех вещей (поскольку настройки конфигурации "track-sc" идут только от 0 до 2). Я считаю, что да, вы можете отслеживать только три вещи. Но главное, это 3 вещи на бэкэнд, который действительно обслуживает запрос. Так, например, если вы, как и я, хотите установить другое ограничение скорости для статического контента, чем для динамического контента, вы можете принять решение о том, переходить ли к «статическому» или «динамическому» бэкэнду в свой интерфейс, на основе чего-то в запрос. Затем в «статическом» бэкэнде вы определяете track-sc0 и track-sc1 для «static» и «static_60» бэкэнда (если вы использовали схему именования, аналогичную той, что была указана мною выше). Затем у вас будет 4 палки-стола для принятия решений об ограничении скорости. Ставки 10 и 60 как для динамического, так и для статического контента. Используйте третий счетчик, и я думаю, вы сможете получить свои 3 уровня, но я думаю, что это будет предел.