Hello Antonio - The question of providing SQL database High Availability comes up on this mailing list from time to time, and I thought a few comments might be in order. First let me say that neither Mike nor I are experts in providing SQL database High Availability, and my comments in particular are framed in the context of overall network engineering. In the general sense, in looking at a system involving Radius and SQL, one has to ask the question "which protocol is easier to deal with?". The answer, I feel, is that Radius as a protocol is *much* easier to deal with, as it is extremely simple (UDP based) and already has alternate host and multiple retries built in. Therefore, my approach always tends towards multiple Radius hosts and a single SQL database. Radiator does provide SQL database failover with multiple DBSource lines, however, Radiator does not provide any means of maintaining coherency between multiple SQL databases. Therefore, running multiple SQL databases will rely on whatever "Replication" functionality is provided by your database. Keep in mind that the network overhead (not to mention security implications) in doing this sort of thing is likely to be very high, especially compared to Radius packet overhead. Also keep in mind that database replication is by definition a very hard thing to do and not all databases support it anyway. My approach therefore tends towards light-weight Radiator hosts either directly in POP locations, or possibly in intermediate aggregation locations, with pre-processing such as DNIS handling, proxy and roaming support provided by those light-weight Radiator hosts. Then, all customer requests are proxied to a main location with some small number of Radiator hosts front-ended by a load balancer. These central-site Radiator hosts would be configured to talk to a single SQL server, which itself would be a very solid server box connected to something like a RAID array. High availability can be provided by keeping local copies of accounting records on flat files on the remote Radiator hosts. Note that the next release of Radiator will also include a caching option that will allow you to configure Radiator to cache Access-Accepts, and if there is no response to an Access-Accept, Radiator will then check its internal cache for a match. BTW - if anyone has experience with database replication in this context could they post a description to the list? I myself would be very interested in any feedback, either positive or negative. thanks for your attention regards Hugh On Wed, 02 Aug 2000, Antonio Coloma wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Hugh, > > We want to put Radius on HA. We want to put some Radius > machines load balanced with an alteon. The problem here is the > sessiondatabase. We have a Mysql sessionDB, and we want to know how > to put this Mysql db in HA. > If Mysql dies, or Radius gets a timeout from Mysql > database, what happens? Could our customers authentificate without > sessiondb? > > Thanx a lot. > > PD: I have no messages from radiator mailing list since 31 / 07 . Is > there any problem? > __________________________________________________ > Wanadoo Espa�a > Direcci�n I+D / Servicios IP > Antonio Coloma Brotons / [EMAIL PROTECTED] > TEL: +34 (9)6 5040045 - FAX: +34 (9)6 5040047 > http://www.wanadoo.es > __________________________________________________ > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> > > iQA/AwUBOYfqlfmFtUnPAF8XEQLGRwCg0YfxfM7UBwx2j5yRgYNY6/EoZC8AoL2I > 28nWE/m8xkI98vnd34LyUHEf > =DGNw > -----END PGP SIGNATURE----- -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
