2017-01-22 - Re: [GRASE-Hotspot] guidance for medium large installation

Header Data

From: Gianluca Filippini <gi***4@gmail.com>
Message Hash: 5de76a5e1d7defad32cbcc57148743d1d99823207bda349cb64fbbdd652d26a2
Message ID: <d91fa586-2e4e-4e3b-b96d-73000186b3c2@grasehotspot.org>
Reply To: <CAESLx0JpWB_JJjE0qi9RKJ4=e0rC=GBQ=qzTTxGrYeocjsiR4A@mail.gmail.com>
UTC Datetime: 2017-01-22 15:52:07 UTC
Raw Date: Sun, 22 Jan 2017 14:52:07 -0800

Raw message 

Hi Tim,
thanks a lot for your reply, I always appreciate your accurate answers on 
the forum.

this hw is a machine from 3y ago that has been running 24/7 with a grase 3.7

I had few issues .. sometimes freeradius seems to get stuck, sometimes I 
think coova-chilli is the culprit (users cannot connect anymore) but since 
I could not debug easily I admin I always went for the brute force approach 
added a reboot every 2days or so.
now I have the time to upgrade the installation and I would like to get 
something more stable.

this is a DELL T320 with a Xeon(R) CPU E5-2407 0 @ 2.20GHz (4 cores) and 
16G of ram (plus a sata disk which is 60% free) and two Broadcom gigabit 
eth.
I think this should be plenty of hw for ~200 users on a 50Mbit/s peak of 
traffic, average of 30Mbit/s

one of the things that I investigated a while ago is the number of threads 
in squid.
the current system is running squid 3.1 and cannot go multithread, but I've 
seen that in 3.3 I can confugure for many threads.
I think that would be an interesting set to tweak by default.

regarding mysql, I've seen around that people suggest to double the default 
number of sockets when a lot of frequent connections to the db are 
needed... bah..

for freeradius I;ve seen this link, which seems interesting to test 
http://freeradius.org/features/scalability.html

thanks for the info on 16.04 ... I was not aware this is not yet a 
production release for GRASE.
I'll be waiting for that so I can upgrade with an LTS.

thanks




On Sunday, January 22, 2017 at 9:58:02 PM UTC+1, timwhite88 wrote:
>
> Hi Gianluca
>
> Firstly, 16.04 isn't yet supported. I'm in the process of building new 
> packages that support it (actually, they are built), and now need to test. 
> Due to some package changes in 16.04, I'm having to change how the 
> repositories work, so we can target specific distributions. This is great, 
> as it'll be clearer what is supported and (somewhat) tested. It also allows 
> us to get rid of some packaging oddities we've had to work with.
> The supported list of distributions will be Ubuntu Xenial (16.04), Trusty 
> (14.04), and Debian Jessie. I'm in the testing phase of the new 
> repositories, and once I can confirm that they work, will release 
> instructions to get others testing the newly built packages. With 3 
> distributions, and up to 4 architectures (32bit, 64bit, ARMHF and ARMEL on 
> Debian), there are lots of combinations to test, and not much time or 
> hardware.
>
>
> 1) is there some parameter for freeradius that I should tweak from the 
>> default install? I reading about the num_threads but I did not test it 
>> before, yet it seems likely something that I should increase...
>>
>
> None that I'm aware of. As you get more connections going through, you may 
> want to decrease the accounting interval (definteriminterval) for Coova 
> Chilli. The default is 5 minutes, but with more connections, an easy way to 
> reduce the freeradius load is to increase that interval. 
>
>>
>> 2) mysql num of connections : seems another param to be increased with 
>> 200 users to track ..
>>
>
> I'm guessing you'd want this to match the number of threads of Freeradius. 
> Current default is 5 I believe. 
>
>>
>> 3) for 3.8 I don;t want to keep more than 2 weeks of history in my 
>> session database, is there a way I can automatically prune the database? 
>> I've seen few few emails with some scripts from Tim, are those ready to be 
>> used in production?
>>
>
> I'm not sure. The ones floating around I've not looked at in depth. It'll 
> depend on if the users are "expired" or used up their quota. If so, some of 
> the built in scripts will help. Although 2 weeks is very short. The 
> sessions table is used to manage limits, so if you are emptying it 
> regularly, you need scripts that take into account how much data a user has 
> used, before removing them from the table.
>  
>
>>
>> 4) firewall: is there a way to disable the internal firewall on GRASE? I 
>> just need access control, all port filtering is done from the fw/router in 
>> front of the grase machine itself.
>>
>
> Not easily. We currently NAT connections, so a firewall is required. 
> However, it's a minimal firewall, mostly there for the NAT and transparent 
> squid proxying. Linux firewalls are very efficient, so I doubt turning it 
> off would give you much performance improvement. You'll find that 
> CoovaChilli is a bigger drain of resources, as it needs to track all the 
> active connections, rate limit them, report traffic flows, etc. CoovaChilli 
> has a kernel module now, to help with this, but I've done 0 testing with 
> it, and I doubt I'll get to testing it for a long time as it's not as easy 
> to build and setup.
>
> From the sounds of it, you really need to ensure you have adequate 
> hardware to handle your setup.
>
> Looking forward to seeing progress.
>
> Tim
>

Thread