Existe uma maneira de classificar as conexões de limite com o HAProxy usando vários limites

Question

Implementei a limitação de taxa simples usando o HaProxy de maneira semelhante à maneira como o StackExchange o faz com HaProxy. Estou tentando torná-lo um pouco mais avançado para que haja vários limites de limite de taxa.

Por exemplo, limite os clientes que solicitam:

• 15/minute

• 60/hour

• 360/day

Parece que preciso de várias tabelas para armazenar os mesmos dados com taxas de amostragem diferentes. A documentação declara:

There is only one stick-table per proxy. At the moment of writing this doc, it does not seem useful to have multiple tables per proxy. If this happens to be required, simply create a dummy backend with a stick-table in it and reference it.

Infelizmente, estou tentando descobrir como armazenar os dados nas tabelas de back-end falsas.

Também estou aberto a outros métodos, o HaProxy simplesmente parecia uma estrada promissora e, como já o temos no ambiente, fazia sentido. Qualquer sugestão é apreciada.

    

Answer 1

Eu só estava tentando fazer isso sozinho, não estava tendo sorte, e decidi recorrer ao meu google-fu. O principal resultado para mim ao procurar por vários níveis de limitação de taxa foi este, e fiquei muito animado. Então eu vi que não tinha respostas e inicialmente caiu em um poço existencial de desespero. Depois de me desenterrar, continuei hackeando e, por algum golpe de sorte, parece que descobri como fazer pelo menos o que eu precisava. Talvez funcione para você também.

O haproxy é muito, muito legal, e estou animado para começar a usá-lo no lugar da nossa solução atual de balanceamento de carga, mas as mesas de apoio são um pouco monstruosas para envolver sua mente. Naquela frente, eu encontrei um princípio geral que parece estar me ajudando, e isso é explicitamente se referir a cada tabela do bastão pelo nome quando você está tentando fazer uma configuração com várias tabelas de bastão. O comportamento padrão, onde o nome é implícito (assumido como sendo o backend em que você está), é ótimo ... exceto quando você começa a tentar ficar chique com várias tabelas. Então é por isso que na minha configuração abaixo, algumas delas são mais verbosas do que tem que ser. Eu só acho mais fácil seguir a lógica dessa maneira. De qualquer forma, aqui vai (note que isto está contando baseado em cookies para uma aplicação Moodle, não o IP, e está usando v1.5.11 de 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

Então, o que isso está fazendo é definir um contador para gravar a taxa por 10s e outro para registrar a taxa por 60s. Observe que ele não está realmente usando esses contadores para limitar qualquer taxa ainda. Mas você pode verificar via:

echo "show table dynamic" | socat /var/run/haproxy/admin.sock stdio
echo "show table dynamic_60" | socat /var/run/haproxy/admin.sock stdio

Que os contadores de taxas estão sendo mantidos separadamente.

Eu queria descobrir a configuração mínima necessária para que esses contadores realmente aumentassem, e é por isso que você vê "FALSE" no final da instrução "tcp-request content reject". Apenas definir os acls com os contadores não os fará incrementar. Você tem que realmente usar o acl. Colocar "FALSE" no final simplesmente me permite usar o acl sem nunca satisfazer a condição para realmente rejeitar o pedido. Eu provavelmente vou tirar o "FALSE" assim que eu decidir sobre alguns números para esses acls.

A verdadeira chave para fazer funcionar várias tabelas stick parece estar fazendo o "stick on", "track-sc {0 | 1 | 2}" e definições acl usando "sc {0,1,2} _inc_gpc0 "no backend onde você realmente está lidando com o pedido. Mover qualquer um deles para o backend dynamic_60 causou a contagem para que isso parasse de funcionar. Acho que o raciocínio é que não faz sentido rastrear ou aplicar acls a um back-end que não atenda a solicitações, porque na verdade elas não têm solicitações para obter informações. Dito isto, tenho certeza que os outros terão melhores explicações. Eu sou muito novo no haproxy.

A próxima pergunta que fiz foi: estou limitado a apenas rastrear 3 coisas (como as configurações de "track-sc" vão de 0-2). Eu acredito que, sim, você só pode rastrear as três coisas. Mas, mais importante, são 3 coisas por backend que realmente atendem a um pedido. Assim, por exemplo, se você quiser limitar a taxa de conteúdo estático de modo diferente do conteúdo dinâmico, pode decidir se deseja ir para um back-end "estático" ou "dinâmico" em seu front-end, com base em algo do tipo pedido. Então, no backend "estático", você define track-sc0 e track-sc1 nos back-ends "static" e "static_60" (se você estava seguindo um esquema de nomenclatura semelhante para a configuração que eu coloquei acima). Em seguida, você terá 4 tabelas de palitos a serem usadas para tomar decisões limitadoras de taxa. Taxas de 10s e 60s para conteúdo dinâmico e estático. Use o terceiro contador, e eu acho que você poderia obter seus 3 níveis, mas acho que seria o limite.