(RADIATOR) Platypus 3.0 + SQL 7 Cluster & Replication Foo

[Robert G. Fisher]

Hey guys, this is addressed to 3 separate groups...


1)  Hugh & others on Radiator support list, this
    deals primarily with concerns of maintaining
    stable and high availability DB systems to
    work with Radiator 2.18.2 (or higher)...so,
    while a lot of this deals with the DB back end,
    I still would appreciate the voice of experience
    and understanding of how the product handles
    configurations to know how some things might be
    done.

2)  Support people of Boardtown for Platypus software,
    you guys have always been excellent so I'm really
    hoping someone can give me some insights here.

3)  My friends from the geek-list...Any SQL Server
    Gurus out there...if so, I'll buy you a beer or
    whatever you drink if you can give me the right
    answer -- heck, that's offer good for anyone who
    gives me a solution.  :)

I'm having to manage our silly billing system that
on the back end is hosted on a MS SQL Server 7 on
a NT4 server.  Catch is, we're integrating e-mail
and RADIUS into the system via IPSwitch's IMail and
OpenSystem's Radiator respectively -- which means,
that it's even more critical for that data to always
be available.  All of which we are doing so that we
can integrate and automate our systems with our nifty
Platypus 3.0 billing system from Boardtown. ;)

What I am trying to envision is to have a way in which 
the entire core db is part of a server cluster, with
possible load balancing but at the very least -- fail
over capability in which the IP address is assumed by
the new machine so that to the outside clients, nothing
has changed in the IP used for the ODBC DSNs...Then, in
addition to that, I'd like to see replication on a 
transactional basis of specific tables/articles that
are necessary for authentication and replication out
to a series of database servers that are set in READ-Only
mode for remote POPs to use for authentication information
for e-mail and dial-up so as to isolate their auth traffic
to their internal networks, and to give them some measure
of backup in case the link between the central site and 
their location went down...although, not sure how long
any replicated data might stay before it expired out of
the remote server.

My big problem:  I've NEVER touched Replication or Clustering,
and my boss expects me to figure this out by tomorrow -- where
can I find good information on how something like this can be
done, or if there is a better way.

	A)  Not all of the tables apparently have unique 
	    indexes...

	B)  Some of the tables reflecting RADIUS accounting
	    data have triggers associated with them which
	    can lead to issues with replication.

	C)  The table into which RADIUS accounting data is
	    used receives literally hundres of inserts per
	    second and that number will continue to grow as
	    POPs and thusly additional NAS's are added...
	    
	    	c1)  How best to isolate problems associated
		     from filesize growth of this table and 
		     the growth from the transaction logs.

		c2)  How to work with replication on this
		     considering volume of transactions and
		     keeping item B in mind since Accounting
		     data on Stop and Start requests is necessary
		     to maintain a sessions table for use with
		     determining multiple logins across different
		     radius servers.

	 * I wonder if it's possible to isolate the radius
	 * accounting tables on the cluster server and only
	 * have the session interface from Radiator come to
	 * this ODBC handle, and set a timeout for the session
	 * database/table.

My Goal:  To have a set of systems that allows for hardware
redundancy so in the event of a system failure, or in times
when maintenence must be done, such as installing service 
packs or hotfixes, that I can begin work on one machine in
the cluster while the other assumes the role of the DB server
so that work and client's services are not disrupted...and
that data is sent out to remote POPs so that in the event of
a problem either with the central database cluster or the
connection to the cluster that there will be local data for
which the users at that POP can authenticate and use for
the processing of e-mail (IMail can retrieve user information 
from an ODBC source which is how we integrate this with the
DB system.)

-- 
Robert G. Fisher                  Sitestar.net, Inc. 
Senior System Engineer            (540) 666-9533 x 116
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.