FR behavior when DB not available

[Brendan Kearney]

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 at deployingradius.com>
> wrote:
>
>> On Jul 19, 2023, at 2:25 AM, Anatoliy <cphlpd at 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