[MASOCH-L] Escabilidade Hotspot

[Rubens Kuhl]

2009/3/15 Gustavo Santos <gustkiller at gmail.com>:
> Rubens,
>
> Enquanto aguardo aprovação na masoch-l , respondo por aqui a sua mensagem ,
> quando for liberado copio pra lista.

Ok, enquanto isso eu vou alimentando a thread pela minha assinatura...


> Já vi hotspot com mais de 1300 usuarios simultâneos, o maior problema de
> escalabilidade não é nem como sistema de captive portal, mas sim com as

Eu vi uma apresentação em http://www.mikrotikrouter.com (um integrador
que vende um x86 com 7 GigE) citando 1400, já ouvi falar de 2 mil, mas
eu tinha como meta números bem mais altos...

> queues. A escalabilidade vai depender de como você pretende utilizar ou se
> vai utilizar queues individuais para cada usuario logado no hotspot , ou se
> você vai utilizar outra forma de controle de banda.

Humm, eu desconfiava disso, interessante ter confirmação. Porque para
a escalabilidade do processo de hotspot, seria possível substituir
pelo DHCP do Mikrotik com arp=reply-only e adição de cada IP oferecido
pelo DHCP numa simple queue, mas ainda sim haveriam tantas queues
quanto usuários.

Há sim necessidade de controlar banda conforme oferta de serviço, que
é diferente para cada assinante.


> A maquina em questão é um HP ml 110 xeon dual core 2.66 ( já com arquitetura
> do Intel C2D). E utilizando versão do Mikrotik 3.13, pois acima desta versão
> até onde testei , quando se utiliza hotspot / radius = dor de cabeça e
> travamentos. A ultima que testei foi a 3.15 e ainda não tinham corrigido o
> problema.

Pois é, mas só da 3.19 em diante resolveram um bug de clock com
dual-core... o Wiki da Mikrotik sugere >=3.19 para máquinas Dell R200,
por exemplo.

> Sugiro se for utilizar  o PCQ para controle de banda, pois neste servidor
> quando se utilizava queues dinamicas via Radius, a CPU chegava a 80%
> utilizando PCQ caiu para 30% com a quantidade de clientes que falei
> simultâneos e aproximadamente 30mbits de tráfego.

Isso sugere uma alternativa usando PCQ e criação de regras por plano
de serviço ao invés de por usuário.


Rubens