tc prio qdisc para priorização do tráfego do mysql

Question

Eu estou lutando com o qdisc do tc prio por algumas horas agora. Eu li a Documentação, Exemplos e HowTos do lartc, mas essa coisa toda é meio nova para mim e um tanto confusa:)

Então esse é o meu cenário: Alguns servidores de arquivos que atendem a um grande volume de tráfego http e ftp. Eu preciso priorizar o tráfego mysql, porque muitas vezes quando os links estão cheios o tráfego sql fica lento e / ou distorcido, levando a erros de conexão, timeouts e assim por diante.

Isso é o que eu tenho até agora:

# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 3306 0xffff flowid 1:1
# tc filter add dev eth0 parent 1: prio 3 protocol all u32 match u32 0 0 flowid 1:3
# tc -s qdisc ls dev eth0
qdisc prio 1: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 125836067 bytes 87549 pkt (dropped 0, overlimits 0 requeues 347) 
backlog 0b 0p requeues 347 

Se eu não estou enganado pelos documentos lartc, isso deve colocar o tráfego ssh e mysql na banda prio 1 e tudo mais na banda prio 3, de acordo com os docs, o prio qdisc tem 3 bandas por padrão, bandas mais baixas devem ter prioridade mais alta

Alguém pode confirmar ou negar isso ou você tem outras ideias? Eu não quero testar isso nos sistemas de produção antes de ter certeza absoluta de que funcionará. Fico desconcertado com as estatísticas, pois elas não mostram uma clara separação do tráfego

edite: Acabei de fazer mais alguns testes com essa configuração, fazendo um ping no servidor, carregando os links, o ping vai de 40ms para 170ms. Fazendo isso:

# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1

Ping desce para 40ms, então isso pode estar funcionando já:)

edit2: depois de mais alguns testes, eu me lembrei do seguinte:

tc qdisc add dev eth0 root handle 1: prio
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 3306 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1

para correspondência com "qualquer outro tráfego" que possa ser usado:

tc filter add dev eth0 protocol ip parent 1: prio 2 u32 match ip src 0/0 flowid 1:2

ou

tc filter add dev eth0 parent 1: prio 2 protocol all u32 match u32 0 0 flowid 1:2

mas achei que não especificar um filtro "catch all" funcionou também, parece que a banda padrão do prio já é baixa.

    

Answer 1

Apenas para concluir, aqui está a solução simples para ter tráfego de prioridade com base em qualquer parâmetro sem sobrecarregar a largura de banda

tc qdisc add dev eth0 root handle 1: prio 
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 3306 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1

Explicação:

1. crie um qdisc de prio chamado 1:
2. adicione uma porta de correspondência de filtro 22 - > banda 1
3. adicione outro filtro que corresponda à porta 3306 - > banda 1
4. e outro protocolo de correspondência de filtro 1 (icmp) - > banda 1

Você pode ter "u32 match src" ou especificar um esporte ou qualquer protocolo

    

Answer 2

O qdisc pfifo_fast padrão já deve ser capaz de fazer o que você procura, obedecendo aos bits ToS. Então, outra solução, sem mexer no tc, seria apenas configurar seus daemons ssh e MySql para configurar os bits ToS em seu tráfego.