O administrador Lucas William Bocchi escreu um material muito bom sobre a priorização de tráfego (QOS), problema que atinde muitos provedores de Internet e empresas de todos os portes.
Leia na integra o material.
As aventuras de um Administrador de redes no Mundo do QoS Por Lucas Willian Bocchi lucas d#t bocchi (*) gmail d#t com Este documento está protegido pela licença GPLv2. A distribuição, cópia e alteração está permitida, desde que citadas as fontes e autores originais, tanto deste documento quanto de documentos originados apartir deste. Caros Colegas Depois de muito tempo, decidi dar mais uma contribuição a comunidade. Sem muita enrolação, vamos iniciar! Somente quero deixar claro, desde o começo, que tudo aqui é muito novo para mim. Apesar de trabalhar com redes a um bom tempo, nunca tinha me concentrado muito no assunto de Qualidade de serviço, etc! Portanto, este documento que estou criando não pretende ser a "BÍBLIA" da Qualidade de serviço, e nem ser o "estado da arte" no assunto. Este documento vai mudar com o tempo e com a aprendizagem que vou adquirir durante o decorrer de novas experiências, e espero que seja pelo menos um "facilitador" para que você também possa resolver seus problemas mais rapidamente. CONSULTE AS DOCUMENTAÇÕES ADICIONAIS que estarão espalhadas durante todo o documento. Procure ler e entender melhor o que é o QoS e para quê ele serve. Eu li, e ainda não entendi tudo, portanto, se você ler e entender mais do que eu, não deixe de entrar em contato e me ajudar também! Depois de um bom tempo e de uma boa conversa, consegui convencer o pessoal da nossa empresa a começar a implementar alguns testes de voip com placas digium (TDM410P) e OpenVox. Tudo estava muito bem, indo às mil maravilhas! Para economizar, cometi o "pecado" de instalar as placas Voip nos mesmos servidores que fazem o roteamento e o controle de acessos de nossa rede, bem como (por economia também) utilizar o mesmo link de dados para a voz. Até aí também, tudo bem, porquê temos políticas rígidas de acesso e utilização da rede dentro da empresa, e na maior parte do tempo nossa rede tem quase 0% de utilização. Voip instalado, tudo funcionando (mais ou menos, ainda tenho problemas com eco e linhas que abaixam e sobem o volume misteriosamente), apareceu a dor de cabeça. Alguns fornecedores e também uma consultoria e auditoria externa começaram a trabalhar na empresa, e, logicamente, as "aves que aqui gorgeiam não gorgeiam como lá", portanto, o que vale pros funcionários, não vale para esse pessoal, porque eles precisam da rede para fazer seu trabalho (o que não é totalmente verdade, porquê andei pegando uns pacote p2p no tcpdump, mas vamos fingir que é). A dor de cabeça, que no início era pequena (pequenas reclamações no uso do voip como picotes, dúvidas sobre a velocidade no acesso ao Terminal Services, etc) começou a ficar grande quando nossos colaboradores começaram a ter que enviar dados para servidores externos (planilhas gigantescas, arquivos de powerpoint com apresentações cheias de fotos, enfim). Os consultores também começaram a utilizar o envio de dados para fora da rede de forma intensiva, e o inferno astral começou. Nosso link é um ADSL 800/320. O Download estava satisfatório, mas, como todos sabem, o grande problema de nosso amigo é o upload. Com o "entupimento ininterrupto" do uplink, as reclamações subiram das classes folha para as classes mais internas da nossa árvore hierárquica, e o "puxão de orelha" (pra não usar outros adjetivos) não seguiu o mesmo caminho, vindo direto como uma bomba atômica da raiz da árvore até o nó-folha onde eu estava! Então, a necessidade de implementar um QoS na rede foi inevitável. Comecei a procurar no pai google as informações que precisava. Descobri várias documentações muito boas e muita coisa sobre QoS e Differentiated Services (DiffServ) no linux (vejam mais informações neste link http://www.opalsoft.net/qos/)! Li muito material, e entendi alguma coisa do assunto. Analisando os algoritmos de controle de banda (consulte as documentações adicionais), cheguei a conclusão que deveria usar o que é considerado o melhor de todos para a minha situação em específico, ondem existem serviços interativos que precisam de baixa latência (como Voip, ssh e Terminal Services) e também serviços com grande quantidade de tráfego. Verifiquei, dolorosamente, que apesar de ser um algoritmo muito bom, existe muito pouca documentação sobre o assunto. A maioria do que encontrei foi na lista do Linux advanced Routing & Traffic Control HOWTO (LARTC), onde quero agradecer muito ao Patrick McHardy e ao Andy Furniss por terem entendido a documentação melhor do que eu e esclarecido dúvidas importantes. Para começar a entender o HFSC, você deverá ler este documento (http://linux-ip.net/tc/hfsc.en/), que esclarece, apesar de não explicar muito, o que é o HFSC. Se você quiser realmente entender a fundo como funciona o algoritmo, vocês devem ler este documento (http://www.trash.net/~kaber/hfsc/SIGCOM97.pdf), que possui muito da teoria do mesmo. Não vou dizer que é fácil compreender como ele funciona, e nem me aventurarei a explicar para você também, para fazê-lo de forma errada. Explicarei somente o que entendi e baseado em alguns bons posts da lista do LARTC. Partindo do princípio que você leu os documentos anteriores, e que já entendeu alguma coisa, lá vai o que penso: O HFSC é um algoritmo hierárquico (parecido com o CBQ ou HTB), baseado em várias curvas, que, na verdade, procuram modificar a curva original de uma determinada conexão. Basicamente, pressupõ-se que existem duas curvas: a curva de tempo real, e a de compartilhamento de link. Digamos que você possua uma conexão que inicia em um tempo t. Conforme o tempo vai passando, o uso da banda vai tendendo a utilizar seu link até a banda total disponível. A curva crescerá linearmente, pois iniciará num tempo t e numa banda zero, e em outro tempo t ela chegará ao ápice. O HFSC procura modificar esta curva a fim de assentar, num universo com várias conexões e, consequentemente, com várias outras curvas, uma curva única de conexão que procure atender da melhor forma possível os requisitos das outras curvas. As curvas disponíveis no HFSC são: [tradução de http://marc.info/?l=lartc&m=115928389517811&w=2] LS = (Link-sharing curve) Curva de Compartilhamento de Link: define a relação entre as classes de serviços irmãs. Pode ser usado nas classes intermediárias e folhas. UL = (Upper-limit curve) Curva de limite superior: Limita a LS RS = (Real-time service curve) Curva de tempo real: define as garantias absolutas de um serviço para as classes folha. Pode ser usada, mas não para classes intermediárias. SC = (Service Curve) Curva de Serviço: Seta o LS e o RS para os mesmos valores. É usualmente adicionada nas classes folha no lugar da RS. As partes destas curvas são: m1: O primeiro segmento da curva d: O tempo de duração desta curva m2: O segundo segmento da curva Para definir corretamente os valores do algoritmo, existem duas formas possíveis. Na definição padrão para o linux (m1/d/m2), o algoritmo transmitirá os seus dados na taxa m1 no intervalo de tempo d, então após isto na taxa m2. m1 é a primeira parte da curva, d é o tempo respectivo da duração desta curva, e m2 é a segunda parte da curva. No novo modelo (umax/dmax/rate), m2 será igual a taxa, m1 e d serão automaticamente calculados através do dos parâmetros umax e dmax, respectivamente. Existem alguns cálculos para se definir corretamente os valores de m1/d/m2. Eu não entendi como se faz, e por isso tentei trabalhar no meu script de controle de banda com o que entendi. Procurei não utilizar estes cálculos, já que, para se montar um script básico de QoS, não se faz necessário entender a fundo (e o tc nem exige) estes parâmetros. Se um dia alguém entender, e quiser me explicar, eu agradeço. Matemática nunca foi meu forte! Vou citar um exemplo aqui: [http://marc.info/?l=lartc&m=115435331720594&w=2] Digamos que na minha conexão eu precise de uma classe que transmita dados a 100kbit/s (uma aplicação típica de voip, por exemplo). O delay de envio de um pacote nesta minha conexão é de 37.30 ms. Obtenho esta conta de forma simples: um pacote no ADSL tem um MTU de 1492 bytes. Se multiplicarmos o MTU da interface por 8, teremos então o valor de 11.936 bits, que configuram o tamanho de um pacote. Dividindo-se este valor pelo do uplink (320.000 bits/s), teremos então que, para enviar um pacote de dados por este link, teremos o atraso de 37.30ms. Para uma classe de 100kbit de tamanho, sabemos que enviaremos 8.38 pps (100000 bits/s / (8 bits * 1492 mtu)). O tempo de envio, então, para os pacotes desta classe será de 119.36 ms ((320000 bits/s / 100000 bits/s) * 37.30 ms, e o tempo máximo de enfileiramento deste pacote na rede será de 156.66 ms (119.36 ms + 37.30 ms). Digamos, então, que você tenha outro link de 1Mbit de uplink, uma taxa de 500kbit com um pacote de 1500 bytes de tamanho e você defina um delay máximo de 30ms. A taxa de latência de um pacote de 1500 bytes de tamanho a 500kbit é 24ms. Você define então 30ms tendo então 6ms de "folga" onde será feito uma curvatura de tempo onde você ficará 6ms sem transmitir nenhuma informação e depois disso transmitirá a 500kbit. Para estes cálculos, desenvolvi um pequeno programa em C que está no rodapé do nosso tutorial. [http://www.mail-archive.com/
/msg07964.html] Continuando, temos então as seguintes combinações possíveis para as curvas de link: Real-time Link-sharing Real-time + Link-sharing Link-Sharing + Upper-limit Real-time + Link-sharing + Upper-limit Quando múltiplas curvas são utilizadas, devem seguir o seguinte padrão: rt <= ls <= ul Para entender por quê são duas curvas diferentes, você deve saber que o algoritmo de enfileiramento (scheduling) do HFSC é baseado em dois critérios: o Tempo real, que garante que as garantias das classes folhas são cumpridas e o critério do compartilhamento de link, que tenta satisfazer a curva de serviços das classes intermediárias e distribuir a banda excedente de forma harmônica. A razão do porquê são dois critérios está no modelo de compartilhamento de link "Fair Service", modelo no qual o HFSC tenta se aproximar e não é sempre possível garantir o serviço para todas as classes simultâneamente em todo o tempo (com curvas de serviço não-lineares). O HFSC escolhe garantir as curvas de serviço Real-time das classes-folha (porque apenas deixa transportar os pacotes), e usa o critério de Link-sharing para diminuir a discrepância entre o serviço atual o serviço definido no modelo de compartilhamento de link "Fair Service". A curva Upper-limit é usada para limitar a curva de compartilhamento de link LS. Sem uma curva UL, os pacotes serão retirados da fila na capacidade máxima que o dispositivo puder enviar! Algumas considerações: - O HFSC não suporta prioridades como o HTB. - Se você apenas especificar uma curva RS, esta classe não participará do compartilhamento de link. Isto significa que você somente poderá enviar pacotes na sua taxa máxima. A diferença entre um modelo com LS+UL é que este serviço será garantido. - Se você especificar somente uma curva de compartilhamento de link, não haverá nenhuma garantia para este serviço. - A soma de todas as curvas de tempo real não podem ultrapassar 100% (para verificar use o comando tc -s -d qdisc ls dev <device>) - A banda designada para as classes LS não importam, somente as diferenças relativas entre as classes irmãs são importantes. [http://www.mail-archive.com/
/msg08159.html] - O resultado final de uma classe com RS+LS é que uma classe enviar-se-à até sua taxa definida, com uma curva LS começa a existir uma conservação de trabalho e se enviará novamente a taxa definida na curva UL. [http://www.mail-archive.com/
/msg08160.html] - Utilizar o kernel com o timer setado para 1000HZ e utilizar o scheduled PSCHED_CPU no kernel, devido a baixa resolução do escalonador JIFFIES O script que criei, e que melhor resolveu meu problema, foi o seguinte: #!/bin/bash tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: hfsc default 15 # Classe raiz tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 320kbit ul rate 320kbit # Classe interativa (ssh, ping) tc class add dev eth0 parent 1:1 classid 1:11 hfsc sc rate 14kbit ul rate 320kbit # Classe interativa para o voip tc class add dev eth0 parent 1:1 classid 1:12 hfsc rt rate 56kbit ls rate 64kbit ul rate 320kbit # Classe interativa para serviços como vnc, terminal services, etc tc class add dev eth0 parent 1:1 classid 1:13 hfsc rt rate 28kbit ls rate 48kbit ul rate 320kbit # Classe para aplicação de transmissão de dados em UDP tc class add dev eth0 parent 1:1 classid 1:14 hfsc ls rate 56kbit ul rate 320kbit # Classe onde vai todo o tráfego tc class add dev eth0 parent 1:1 classid 1:15 hfsc ls rate 138kbit ul rate 320kbit # Caso você queira "auxiliar" seu controle de banda, você pode inserir, dentro de sua classe # folha, uma fila classless como a RED para fazer enviar notificações de Congestionamento # (ECN) para as máquinas na rede, fazendo com que as mesmas transmitam os dados a velocidade # definida na mesma. Eu não recomendo você fazer isso, porquê poderá ter o descarte # não desejado de pacotes #tc qdisc add dev eth0 parent 1:15 red min 8533 max 25600 limit 204800 avpkt 1000 burst 14 ecn # Direcionando o tráfego SSH para sua classe tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip sport 22 0xffff flowid 1:11 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip dport 22 0xffff flowid 1:11 # Pacotes ICMP tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip protocol 1 0xff flowid 1:11 # Direcionar o voip para o tráfego de média prioridade, já que os de alta prioridade são poucos` # Pacotes voip com o TOS setados tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip tos 0x60 0xff flowid 1:12 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip tos 0xb8 0xff flowid 1:12 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip tos 0xc0 0xff flowid 1:12 # Terminal Services tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 match ip sport 3390 0xffff flowid 1:13 tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 match ip sport 3389 0xffff flowid 1:13 # Portas utilizadas pelo VNC tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip sport 5900 0xffff flowid 1:13 tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip dport 5500 0xffff flowid 1:13 tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip dport 5600 0xffff flowid 1:13 tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip dport 5700 0xffff flowid 1:13 tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip dport 5800 0xffff flowid 1:13 # Aplicação UDP para a transmissão de dados tc filter add dev eth0 parent 1:0 prio 4 protocol ip u32 match ip sport 4000 0xffff flowid 1:14 # Direcionar todo o tráfego para a prioridade mais baixa na lista de prioridades # Desnecessária por enquanto por causa do default do htb # tc filter add dev eth0 parent 1:0 prio 8 protocol ip u32 match ip dst 0.0.0.0/0 flowid 1:30 # tc filter add dev eth0 parent 1:0 prio 8 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:30 Fontes do programa para cálculo dos valores de latência, etc #include <stdio.h> #include <unistd.h> int main(int argc, char * argv[]) { unsigned int multiplicador; unsigned int uplink; unsigned int vlruplink; unsigned int mtu; unsigned int taxa; double mtups; double pps; double delaypacote; double tempoenvio; double delaymaximo; double latenciaclasse; // Verifica o numero de parametros if (argc > 4) { // Contas multiplicador = atoi(argv[1]); uplink = atoi(argv[2]); mtu = atoi(argv[3]); taxa = atoi(argv[4]); vlruplink = 0; vlruplink = multiplicador * uplink; mtups = 0; mtups = 8 * mtu; delaypacote = 0; if (vlruplink > 0) { delaypacote = mtups/(double)vlruplink; delaypacote = delaypacote * 1000; } else delaypacote = -1; printf("Delay de envio de um pacote: %.2f ms ((8 bits * %d mtu) / %d bits/s) * 1000 ms)\r\n",delaypacote,mtu,vlruplink); pps = 0; taxa = taxa * multiplicador; pps = (taxa / (double)mtups); printf("Pacotes por segundo para esta classe: %.2f pps (%d bits/s / (8 bits * %d mtu))\r\n",pps,taxa,mtu); tempoenvio = 0; if (taxa > 0) { tempoenvio = (vlruplink / (double)taxa); tempoenvio = tempoenvio * delaypacote; } // end if else tempoenvio = -1; printf("Tempo de envio de pacotes desta classe: %.2f ms ((%d bits/s / %d bits/s) * %.2f ms\r\n",tempoenvio,vlruplink,taxa,delaypacote); delaymaximo = tempoenvio + delaypacote; printf("Tempo máximo de enfileiramento do pacote: %.2f ms (%.2f ms + %.2f ms)\r\n",delaymaximo,tempoenvio,delaypacote); latenciaclasse = (vlruplink / (double)(vlruplink - taxa)) * delaypacote; printf("A latência para o restante da banda é %.2f ms ((%d / (%d - %d)) * %.2f)\r\n",latenciaclasse,vlruplink,vlruplink,taxa,delaypacote); } // end if else { printf("Uso: %s <multiplicador (para definir o valor em bits/s) (1000 para kbit, 1000000 para mbit, etc)> <uplink> <mtu> <taxa da classe>\r\n",argv[0]); } // end else } // end main
