Is a veritos cluster expensive? I know we are using that here with Oracle
8i, but I am not sure if that is outrageous in price, and if it works with
all db's, or if its specific. Also, does Oracle, IBM DB2, and so on support
clustering by themselves..or does it require 3rd party software to make this
work?
> -----Original Message-----
> From: David Kinnvall [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 11, 2000 2:37 PM
> To: Orion-Interest
> Subject: RE: HARDWARE FOR J2EE apps
>
>
> 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----------------------
> -------------
>
