Hi Louis, Thank you for your reply.
Since writing this email I have found out more information and now I have more questions :-) Now I know that our wireless controllers can have up to 17 RADIUS server entries, so we have decided that we will be doing the load balancing by staggering the order of the pf servers in the controllers. All the pf servers will be VMWare guest, so we can scale the CPU and memory are required. I will start with double the minimum specs. We are authenticating against AD, I don't have any control of the AD infrastructure, but I was told it will be able to handle any load that pf will place on it. The group that is responsible for it will make it so. We are using 802.1x for authentication, based on what I have observed in my lab the clients keep authenticating all the time. I'm assuming that the load is going to be constant and proportional to the number of client devices. Currently anticipating 50K. So as the load increases I would be spinning up more guests. Now I'm coming to my main question. Should I have a db running on each pf instance or should I have one db server. The main advantage of having a db on each pf is avoiding a single point of failure. If I have one db server then the redundancy would be provided by VMware HA of this db server. This is what my manager is leaning to. What am I giving up by having a distributed db over a centralized db (keeping in mind that all the pf is doing is authenticating 802.1x sessions)? Hope I'm not asking stupid questions, Tracy On Wed, June 10, 2015 10:25 am, Louis Munro wrote: > Hi Tracy, > Scaling packetfence requires some knowledge of not only the number of > requests but also things such as database and authentication source > latency. > > You may well be constrained more by ntlm_auth times (if using > Active-Directory for instance) than by the specs of the PacketFence > servers themselves. > > While LVS can be used as a load balancer, PF 5 includes an active/active > mode that would at least load balance the radius traffic on its own. > > So while 4 server may be enough, its impossible to say if it is right for > you. There are too many variables. > How much RAM/CPU will each of them have? > How is your load spread (does it spike at specific times of the day or is > that constant)? > What authentication sources and rules are you using in the backend? AD > authentication rarely goes much faster than 30 auths/seconds while pure > LDAP is much faster. > > I suggest you benchmark your setup as you build it. > Try to see at how many auth/s does your radius start to eat all the CPU > (which means it is waiting for an authentication backend and queries are > piling up). > > Each large PacketFence installation is different in its own way. > > Regards, > -- > Louis Munro > [email protected] :: www.inverse.ca > +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 > Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence > (www.packetfence.org) > > On Jun 9, 2015, at 10:53 , Tracy Adams <[email protected]> wrote: > >> Hi All, >> >> I'm planning for deployment of about 4 packetfence servers. The servers >> will be doing authentication of WiFi clients. Not inline. >> My manager wants me to use LVS as the load balancer in front of the pf >> servers. Is this a good option, or does pf have a build in form of load >> balancing. I can put only 2 RADIUS servers IP into my wireless >> controllers. >> >> Also I expect about 50K devices during peek times, is 4 pf servers >> enough >> or should I have more. >> >> Thanks, >> Tracy >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> PacketFence-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/packetfence-users > > ------------------------------------------------------------------------------ > _______________________________________________ > PacketFence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users > ------------------------------------------------------------------------------ _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
