I would reconsider implementing such low-level functionality. the deeper
you dig into it, the more little things you will discover that have the
potential to break your neck. It's probably not that hard to this stuff up
and running. the problem is to get it really stable. we're currently
planning on the following setup.
2 rather powerful dual processor machines, that run orion and interbase 6
on linux with heartbeat for ip-address takeover. one is running as a hot
standby and they are syncronized using the IBReplicator product that was
already mentioned in this thread (http://www.synectics.co.za/). the
performance of the syncronization that's described in the docs is enough
for our application to believe it will basically be real-time (something
like 200 updates per second over a 10Mbit link and pentium 200s).
of course this only takes care of availability and doesn't do any load
balancing but for us the performance we can achieve by using good caching
algorithms at the application level and fast dual processor machines is
enough. for a really scalable solution I'd probably look at sybase (the
commercial versions, the free version doesn't support clustering). of
course, if the database is not the bottleneck one could use the standby
solution for the database only and put a real cluster of orion servers in
front.
robert
At 23:37 11.10.00 , you wrote:
>Hi!
>
>On Wed, 11 Oct 2000, Robert Krueger wrote:
>
>[description of budget-friendly Orion setup - snip]
>
> > sounds very nice but what about the database? how do you cluster that
> > without spending an arm and a leg? our experience is, that it's not that
> > hard to set up clustered web services with static pages and servlets but
> > the really expensive part is, when you want that high availability for
> your
> > database. it doesn't buy you much if you have highly available ejbs when
> > the database server goes down. many people use clustered apache/jserv on
> > linux and cheap pc-hardware for high volume transactional websites but
> have
> > a large enterprise sun running oracle in the back. anyone out there
> running
> > a configuration with orion that includes a database with failover that
> > doesn't blow up the budget too much (compared to other components)?
>
>Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden,
>and considering Orion as app server we are also contemplating what
>non-arm-and-a-leg-spending ways there are to enable a database for
>failover and load-balancing functionality.
>
>We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah,
>I know) as our database. We have not seen any currently freely available
>solutions for failover for either of those (anybody?). So, we are thinking
>about implementing something by ourselves. Nothing definite so far, but:
>
>- The synchronizing of data will be done on the application-level, not
> by the database servers themselves. See below.
>- We'll avoid numeric sequences for record keys to make this easier.
> We will implement some unique key-generation scheme based on whatever
> is needed to make keys unique but still not rely on strict monotone
> numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ).
>- We'll code a DB-abstraction layer that takes care of executing
> all update queries against all configured database servers and
> all read queries against one of them known to be alive and lightly
> loaded (or not recently accessed, or some other scheme).
>- I guess that if we need database-specific stuff such as stored
> procedures or similar we need to use the same database software
> for all failover machines.
>- If we stay away from database-specifics we could possibly allow
> failover between different database products. Would be cool.
> Using straight, standard SQL, could make this feasible.
>
>These are very premature thoughts, we are getting closer to the
>planning and design stage, but we haven't actually started yet.
>Any thoughts? Ridiculously naive? Or possible to pull off?
>
> > robert
>
>/David
>
>--------------------------------Reach me by--------------------------------
>- Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ -
>----------------------------------/David-----------------------------------
>
(-) Robert Krüger
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
