Filepro Clustering ?

[Fairlight]

The honourable and venerable Doug Luurs spoke thus:
> Is there any plans in the future to allow Filepro database clustering ?
> (or is there even such a thing for SCO Unix Filepro)
>
> I define clustering (in this case) has having a couple of servers
> (Blades) running Filepro and having some databases on one server and some
> on another to spread out the I/O over different servers, but all the
> databases can be accessed by the other servers.  Then having users telnet
> into different servers all together to remove the load from the database
> servers.
>
> More of a Load Balancing operation then anything or am I dreaming ?

It doesn't exist in the transactional sense, to my knowledge.  This has
come up with several people in the past that I've dealt with.  All the
solutions are less than ideal.

-If- you had NFSv3 (I wouldn't try this at all under v2), then you could
mount the relevant directories from all involved systems and control the
data location entry points via the PFDATA/PFDIR type variables.  

This, however, assumes that filePro on one of the client servers doesn't
have processing that needs data from both server A and Server B at the same
time during the same run.  If that's necessary, then I know of no way to
switch in mid-processing which source your data is coming from.

It also assumes running fP across NFS is a good idea.  It isn't.  It can
be done, and I've seen people do it.  But I'd personally never do it in
production if I were the designer.  Even assuming "hard" is used as an
option for mounting, I don't want to think about the potential lock
contention when a server becomes unavailable after disappearing for
whatever reason.  And using sync -really- degrades performance.  As an
example, at one point I was working with NFS for something else and we had
to manipulate 13GB of data.  With sync off, it took well under an hour on
100mbit.  With sync on, it took over seven hours and still wasn't done.
There's some risk leaving sync off, but if you keep it on you really take a
huge, huge performance hit.  Everything is ACK'd synchronously, doubling
your traffic, and also slowing down the throughput more than that for
reasons of other overhead associated with doing it.

Honestly, the fP architecture was designed well before clustering was
mainstream, and it's not currently conduscive to it.  I probably wouldn't
hold my breath waiting for it to be made available.

I can think of ways to deal with this via specially written processing and
using apache and CGI, sure.  It'd be a lot of coding and development to
implement, and a lot of current processing (most of it) would go out the
window in terms of where it's currently implemented--it'd have to be
relocated.  You'd have to handle every case and make a generic handler to
which you put your data on each system.  Each would make the relevant
request (add, delete, update), etc.  Update in particular is difficult, as
you have to have the logic there to determine that there's something to
update, and by what criterion you need to select a particular record.  A
unique key would seem to be in order, although filePro doesn't mandate one.
I wouldn't recommend @rn, of course.  But basically you'd have to tell it
which server, which table, which record, and if it wasn't a delete, which
records get what data.  Considering the lack of interest, this is why I
abandoned the RSS clustering idea I had a few years back and posted about.
Different transport mechanism at the time, but same internal logistical
problems--it's a complex task to build a transactional system meant to work
with a non-transactional architecture.  You can impose the necessary rules,
even retroactively.  Implementing it is going to be a bloody nightmare to
do generically.

The transport itself (SOAP, CGI, whatever else someone might use)
isn't important.  The actual logic in handling the meat of the
transactionalisation is a beast.

What really wants writing is a client/server dispatch system where you can
designate as many servers as you want for a request and the dispatcher
holds onto them until every one of the destinations has been updated.  You
could send it multiple updates to multiple datasources each.  That's only
half the problem though; what happens when you try to READ data from a
datasource and it's not available, but the rest of the data is?  Do you
present some of it, present none of it and throw a fault, or what?

Generally I'll look at the most complex ways to do something sometimes, and
overlook something really obvious.  However, the NFS solution falls down in
spectacular fashion even if it's stable and fast when you need multiple
data sources at once.  That's about as simple as it could get and I'd never
trust it in production.  I'm not even sure if SCO is NFSv3 compliant yet,
but even if it were--that's really dicey.  And again, what if one system
goes down and you're looking at multiple data sources--what do you do when
it spins looking?  It's holding a lock on a segment on one server
indefinitely while it waits on another.  Not good.

fP really isn't built for this, IMHO.  And it's not really worth writing.
I'd think about it if someone put up $100k or more, but not before then.  I
don't really think it would be worth it from a cost:benefit standpoint for
fP-Tech to implement it either, having just talked about it with someone.
How many people actually need this functionality?  My own personal opinion
is that if you need HA systems defined as clustering and five 9's for
everything, you're already using the wrong database in the first place.

The real question I have is, what are you doing that's so resource
intensive that you need to split the workload.  It's not like fP is a huge
resource hog unless you're rebuilding indexes on huge table after huge
table.

Looked at the link Howie sent, btw.  I don't think it's applicable to your
outlined scenario.

mark->