Hi Baker, As Glen and other have alluded, I believe you are unlikely to find a OS level replication technology that will work adequately, unless there is a way to force writes to the OS level immediately, which in turn is likely to have performance implications.
We "cheat" with Visage.DRS - we don't force you to operate via a middleware layer, so it will simply "plug in" to an existing application without the need for any changes. If your application already uses transaction boundaries, that is great, but our data replication service doesn't need them. I thought UV had an inbuilt solution already though .... I seem to remember seeing a demo at a spectrum exhibition a few years ago, and I thought it looked OK? Not sure it necessarily allowed replication to multiple servers, but on the surface it looked as though the basics probably worked (then again, D3 Hotbackup looked good on the surface, but we had to write DRS when our largest client failed an IT disaster recovery audit) We haven't ported Visage.DRS to UV - hasn't been any demand we could see, but if there IS a need (translation: makes financial sense to invest resources) then it could be done Ross Ferris Stamina Software Visage > Better by Design! >-----Original Message----- >From: [email protected] [mailto:u2-users- >[email protected]] On Behalf Of Baker Hughes >Sent: Tuesday, 27 July 2010 2:14 AM >To: 'U2 Users List' >Subject: Re: [U2] 24 X 7 MV systems > >Glen, > >Thank you for the good observations, and suggestion to ping Ross, which >I will do. It is the MV db paradigm which in this case is hampering us, >which drives the solution to either the OS level or some middle ware >solution. Pausing the db to flush memory is what keeps us just seconds >from a full solution. > >Thank you. >-Baker > > >-----Original Message----- >From: [email protected] [mailto:u2-users- >[email protected]] On Behalf Of Glen Batchelor >Sent: Monday, July 26, 2010 10:03 AM >To: 'U2 Users List' >Subject: Re: [U2] 24 X 7 MV systems > > >Hey Stranger, > > The best way you'll get there is with a transaction/request based >redundancy setup. Does U2 have anything that isn't trigger related? Even >a >block-level DRDB config won't help with databases since transactions in >memory aren't committed to disk promptly enough for the replicator to >get >all of the new data pieces as the fault happens. I've been looking for a >remote hosted failover solution myself (not for U2). A truly fault >tolerant >setup requires that the incoming requests be replicated to multiple >machines >before anything happens inside. You might think of the user app as a web >service consumer that makes requests to a proxy. That proxy mux's the >requests to multiple machines, compares all of the responses and then >passes >back the response of one machine based on failover priority. If one of >the >responses aren't the same then an error is sent to the admin. >Unfortunately, >this spits in the eye of MV which is designed to be a stand-alone >central >data store. Maybe you can do it with your own TCP packets, but if you >don't >use an encrypted media you may get into security trouble. Web services >are >horribly bloated, but the security layer is already in there. You should >bug >Ross Ferris and pick his brain about his DRS product versus other >options >for U2. DRS supposedly uses a small amount of bandwidth but it isn't >encrypted AFAIK. > >Regards, > >---------------------------------------- >Glen Batchelor >IT Director/CIO/CTO >All-Spec Industries > phone: (910) 332-0424 > fax: (910) 763-5664 >E-mail: [email protected] > Web: http://www.all-spec.com > Blog: http://blog.all-spec.com >---------------------------------------- > > >This communication, its contents and any file attachments transmitted >with it are intended solely for the addressee(s) and may contain >confidential proprietary information. >Access by any other party without the express written permission of the >sender is STRICTLY PROHIBITED. >If you have received this communication in error you may not copy, >distribute or use the contents, attachments or information in any way. >Please destroy it and contact the sender. >_______________________________________________ >U2-Users mailing list >[email protected] >http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
