Student University <studen...@gmail.com> wrote: > > each node (FR+MySQL) is connected to different NAS server like this : > > Cisco NAS1 --> Node1 (FR+MySQL) <==> Node2(FR+MySQL) <-- Cisco NAS2 > > This is what we need to deploy exactly , > Yes, but what do you do with the MySQL database? authentication? authorization? Record just log/accounting information? > so does the master-master replication is suited enough to accommodates our > needs or there is any better recommendations . > To be honest, we have not had the need for HA SQL; as we only use it for logging, we use LDAP for authentication/authorization (LDAP is trivial to deploy in an HA configuration).
We have a single PostgreSQL database between two active-active FreeRADIUS servers. Various network/power failures here have tempered our configuration to skip logging in the right places and not block/hang the entire campus if the SQL server is unreachable as our priorities swing towards getting the user/workstation connected rather than recording everything. Over the year, for our university (~4000 students and ~600 staff), the SQL server has probably be down only for power reasons (active-active MySQL will not save you there unless you can put a good physical kilometer and L3 separation between the boxes). If the RADIUS blocks (as they are waiting for a non-existent backend[1]) you are in a lot more trouble... I recommend you design a system/service that *expects* failure in it's components and gracefully fails where possible. People who go straight for active-active SQL servers and try to prevent failure and have themselves no operation experience with deploying a FreeRADIUS service are possibly lining themselves up for a tough ride. As advice from someone how has made the mistake (we all have), although the chance of a failure might be less, the actual occasions when failures occur are typically much nastier. Look at your priorities, and before asking for advice you have to list your *requirements* otherwise we simply cannot help. Cheers [1] there is actually a 'bug' in FreeRADIUS I keep meaning to submit a patch for to avoid this (add ' connect_timeout=3' to the end of your PgSQL password to see the effect[2] on an unpatched system) [2] http://www.postgresql.org/docs/7.3/static/libpq-connect.html -- Alexander Clouter .sigmonster says: You auto buy now. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html