i think there was mention that the DB is Oracle, which may get cost prohibitive, but you can put Highly Available implementations in place to improve things. Oracle has RAC, Data Guard and Active Data Guard. PostgreSQL has no active/active but you can do HA with primary failover with HA Proxy, ETCd and Patroni. MariaDB has active/active with Galera replication and can be behind an HA Proxy VIP too. so many times on this list i have seen attempts to have FR clobbered, in an attempt to make a different service reliable, when the effort needs to be spent on the other service and not FR. LDAP/AD is another where attempts have been made to have FR make up for a lack of HA design in other infrastructure. i am using BGP to advertise routes to IPs that are not on the wire, and therefore can be anycasted. dns, kerberos, ntp, radius and syslog are all stateless protocols that can be anycasted among several instances, all using the same, single IP. i have 2 FR instances setup to listen on 192.168.254.3 and the router has multiple paths configured with multiple routes to the same IP. the FR instances do not know about each other and simply respond to the events sent to them. i am not using the replicate module between the FR instances. no need... the mariadb that they talk to, or the LDAP instances they talk to, are behind an HA Proxy VIP, and the load balancer routes traffic to the selected instance, based on the balancing method i chose, least connections. the kerberos instance FR talks to is over anycast. by putting HA implementations into the other services, i dont have to worry about FR not having a service instance available because one single instance is down or otherwise unavailable. you might look into some HA options for your database, and point FR at a VIP or anycast IP, as appropriate, and not have to jump through hoops, trying to have FR make up for deficiencies elsewhere. HTH, brendan On 7/19/23 8:37 AM, Anatoliy wrote:
Hi Alan , DB that never goes down - is fantastic. At least while customer is understand that investment in DB (which will never goes down) will never payback.
On Wed, Jul 19, 2023 at 6:04 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jul 19, 2023, at 2:25 AM, Anatoliy <cphlpd@gmail.com> wrote:
With this configuration, I can , for example, mark DB failed , before MW . and this will prevent unnecessary connections to DB that will fail... This helps a little bit, but it doesn't help when connections are blocked.
The only real solution is to not have the DB go down. While this may seem extreme, I would also suggest that it's a little weird to make FreeRADIUS depend on the DB, and then have the DB randomly go away.
The effort should put into making sure the DB doesn't go down. Patching around an unstable DB by poking FreeRADIUS is like putting a tiny bandaid on a large injury. The bandaid may be pretty but it's not going to do a whole lot.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html