Gostaria de adicionar algum tipo de gerenciamento de tráfego à nossa linha de Internet. Depois de ler muita documentação, acho que HFSC é muito complicado para mim (não entendo todas as coisas de curvas, tenho medo de nunca acertar), CBQ não é recomendado e basicamente HTB é o caminho para vá para a maioria das pessoas.
Nossa rede interna tem três "segmentos" e eu gostaria de compartilhar a largura de banda de forma mais ou menos igual entre eles (pelo menos no começo). Além disso, devo priorizar o tráfego de acordo com pelo menos três tipos de tráfego (tráfego em tempo real, tráfego padrão e tráfego em massa). O compartilhamento de largura de banda não é tão importante quanto o fato de que o tráfego em tempo real deve sempre ser tratado como tráfego premium sempre que possível, mas é claro que nenhuma outra classe de tráfego pode passar fome.
A questão é: o que faz mais sentido e também garante melhor rendimento em tempo real:
Criando uma classe por segmento, cada uma tendo a mesma taxa (a prioridade não importa para classes que não têm licenças de acordo com o desenvolvedor do HTB) e cada uma dessas classes possui três subclasses (folhas) para os 3 níveis de prioridade (com prioridades diferentes e taxas diferentes).
Ter uma classe por nível de prioridade no topo, cada uma com uma taxa diferente (novamente, a prioridade não importa) e cada uma com 3 subclasses, uma por segmento, enquanto todas as 3 na classe em tempo real têm o prio mais alto e o prio mais baixo no volume aula, e assim por diante.
Tentarei deixar isso mais claro com a seguinte imagem artística ASCII:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
Caso 1 Parece que a maioria das pessoas faria isso, mas, a menos que eu não leia os detalhes de implementação do HTB corretamente, o Caso 2 pode oferecer uma priorização melhor.
O manual do HTB diz que se uma classe atingir sua taxa, ela poderá pedir emprestado ao seu pai e, ao pedir emprestado, as classes com maior prioridade sempre receberão a largura de banda oferecida primeiro. No entanto, também diz que as classes que possuem largura de banda disponível em um nível de árvore inferior são sempre preferidas àquelas em um nível de árvore superior,independentemente da prioridade.
Vamos supor a seguinte situação: O segmento C não está enviando tráfego. O segmento A envia apenas tráfego em tempo real, o mais rápido possível (o suficiente para saturar apenas o link) e o segmento B envia apenas tráfego em massa, o mais rápido possível (novamente, o suficiente para saturar apenas o link completo). O que vai acontecer?
Caso 1:
Segmento A->High Prio e Segmento B->Low Prio ambos possuem pacotes para enviar, já que A->High Prio tem maior prioridade, ele sempre será agendado primeiro, até atingir sua taxa. Agora tenta tomar empréstimo do Segmento A, mas como o Segmento A está em um nível superior e o Segmento B->Low Prio ainda não atingiu sua taxa, esta classe agora é atendida primeiro, até que também atinja a taxa e queira tomar empréstimo de Segmento B. Depois que ambos atingirem suas taxas, ambos estarão no mesmo nível novamente e agora o Segmento A->High Prio vai vencer novamente, até atingir a taxa do Segmento A. Agora ele tenta tomar emprestado do root (que tem bastante tráfego sobrando, já que o Segmento C não está usando nenhum de seu tráfego garantido), mas, novamente, ele tem que esperar que o Segmento B-> Baixo Prio também atinja o nível raiz. Quando isso acontecer, a prioridade será levada em consideração novamente e desta vez o Segmento A->High Prio obterá toda a largura de banda que sobrou do Segmento C.
Caso 2:
Alto Prio-> Segmento A e Baixo Prio-> Segmento B ambos têm pacotes para enviar, novamente Alto Prio-> Segmento A vencerá, pois tem a prioridade mais alta. Uma vez atingida sua taxa, ele tenta tomar emprestado do High Prio, que tem largura de banda sobrando, mas estando em um nível mais alto, ele tem que esperar pelo Low Prio->Segment B novamente para também atingir sua taxa. Assim que ambos atingirem a sua taxa e ambos tiverem de pedir emprestado, High Prio-> Segmento A vencerá novamente até atingir a taxa da classe High Prio. Quando isso acontece, ele tenta pegar emprestado do root, que novamente tem bastante largura de banda restante (toda a largura de banda do Normal Prio não está sendo utilizada no momento), mas tem que esperar novamente até que Low Prio-> Segmento B atinja o limite de taxa do Classe Low Prio e também tenta pegar emprestado do root. Finalmente, ambas as classes tentam pegar emprestado da raiz, a prioridade é levada em consideração e High Prio-> Segmento A obtém toda a largura de banda que sobra da raiz.
Ambos os casos parecem abaixo do ideal, já que, de qualquer forma, o tráfego em tempo real às vezes tem que esperar pelo tráfego em massa, mesmo que haja bastante largura de banda restante que poderia ser emprestada. No entanto, no caso 2 parece que o tráfego em tempo real tem que esperar menos do que no caso 1, uma vez que só tem que esperar até que a taxa de tráfego em massa seja atingida, que é provavelmente menor que a taxa de um segmento inteiro (e no caso 1 essa é a taxa pela qual ele deve esperar). Ou estou totalmente errado aqui?
Pensei em configurações ainda mais simples, usando uma qdisc prioritária. Mas as filas prioritárias têm o grande problema de causar fome se não forem limitadas de alguma forma. A fome não é aceitável. É claro que pode-se colocar um TBF (Token Bucket Filter) em cada classe de prioridade para limitar a taxa e assim evitar a fome, mas ao fazer isso, uma única classe de prioridade não pode mais saturar o link por si só, mesmo que todas as outras classes de prioridade estão vazios, o TBF impedirá que isso aconteça. E isso também é abaixo do ideal, pois por que uma classe não obteria 100% da largura de banda da linha se nenhuma outra classe precisa dela no momento?
Algum comentário ou ideia sobre esta configuração? Parece tão difícil fazer isso usando qdiscs tc padrão. Como programador, seria uma tarefa muito fácil se eu pudesse simplesmente escrever meu próprio agendador (o que não tenho permissão para fazer).
Responder1
Se bem entendi o htb, então a taxa é "garantida". Isso significa que vocêterideias sobre a taxa de tráfego "em tempo real". Somente se essa taxa for ultrapassada é que ele tomará emprestado. Se várias turmas quiserem tomar empréstimo, o pré-empréstimo deverá entrar em vigor. As taxas garantidas deverão somar o limite físico. Caso contrário, é muito incômodo.
IMHO, o Caso A nunca funcionará realmente, pois você precisa ter prioridade ou limitação de taxa no nível raiz. As prioridades/taxas nos diferentes segmentos não se conhecem e serão tratadas igualmente.
O que você provavelmente quer é: Colocar a "taxa" para prio baixo e normal em 0 ou próximo a ele e adicionar "teto" para o resto da largura de banda, para prio alto você garante uma taxa de 100% do físico.