I have loadbalanced radius (cisco acs) in my previous positions with no
issues. If a switch is in snmp mode, since a trap is unidirectional you
just round robin the traps to the servers behind the lb. Once the trap is
received and processed it is up the the server to initiate the conversation
with the switch to do gets/sets. I agree that moving more config to the db
or even better moving it to a combination of redis/memcached with syncing
to disk/db. The problem comes with external service config files like
radius, etc. The options would need to be stored in a db and then trigger
the regeneration of the config file and a hup/reload of the process.
HA is a big deal to corporations, PF already offers the best device
coverage I have seen out of any solution. Making it active/active would
make it even more attractive.
I didnt realize that traps were used for IPC. I have used Redis::Fast with
queues and key/val sets for IPC. I have tested perl ithreads, the threads
fork module, memcached and a few others for IPC. Redis is by far the
easiest and fastest.
I am decent at web development, but my passion is in backend/ performance.
I would really like to contribute to this project and I am looking for the
best place for me to start.
On Wed, Jun 11, 2014 at 4:00 PM, Jason Frisvold <xenoph...@godshell.com>
wrote:
> Louis Munro wrote:
> >> 4. Can someone please outline the challenges in implementing and
> >> active/active setup? From what I can think of we would need an
> >> external loadbalancer, external database (could replicate as
> >> well), and some way to sync configuration.
> > TIMTOWTDI. There are also I suppose many ways to do it wrong :-)
> > I wish those who are actually working on it would chime in (hint…) but I
> > think your assumptions are mostly correct.
>
> I've thought a bit about this, but mostly as an exercise of interest
> rather than need. Packetfence on a single server is performing quite
> sufficiently for our needs.. :)
>
> BUT.. Just as an exercise.. Yes, and external load balancer, external
> or replicated database, and a way to sync the config. Though if the
> majority of the config were put into the database *COUGH* that would
> help quite a bit as well.
>
> > Other thing to consider are DHCP, DNS and SNMP (if required).
>
> DHCP and DNS are incredibly easy to make active/active with just two
> servers. SNMP might be interesting, though.. Which server would you
> need to send a trap to? Would it matter?
>
> Other interesting thoughts include how to handle the periodic cleanup
> routines, no real need to run them twice. And how are messages from
> switches handled? Do you load balance radius, or alternate configs on
> the switches, swapping radius IPs back and forth? Are there any other
> situations where duplicate messages would hit packetfence?
>
> > Regards,
> > --
> > Louis Munro
>
> --
> ---------------------------
> Jason 'XenoPhage' Frisvold
> xenoph...@godshell.com
> ---------------------------
>
> "Any sufficiently advanced magic is indistinguishable from technology.\"
> - Niven's Inverse of Clarke's Third Law
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> PacketFence-devel mailing list
> PacketFence-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/packetfence-devel
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
PacketFence-devel mailing list
PacketFence-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-devel
