On Thu, 2008-01-10 at 13:35 +0100, Matej Knopp wrote: > > > > Ideally, NodeB ought to "catch up" when it joins the cluster by > > > > syncing the content in the disk page stores at that time. I > think > > > > it's a flaw we should track and fix at some point. > > > > > > > > Nice job, Matej! > > > > Well, I'm afraid as Igor said this is not possible to do without > having container specific code. So when currently a new node catch up > it only gets the last page for each pagemap. > > > On Wed, 2008-01-09 at 22:35 -0800, Igor Vaynberg wrote: > > > this cant be accomplished transparently. we would need our own > network > > > connection, node discovery, blah blah blah. loses a bit of appeal. > Yeah. This is actually not that difficult to do, there are frameworks > such as tribes that do this quite nicely. The main problem is that we > don't know the topology. We don't know which node is backed by which > node, so we would do lot of unnecearry copying. I don't see any easy > way to implement this. > > > I'm intending to stir the pot a bit, but why are we kicking this further? > > Igor is absolutely right.. For something simple, currently in the linux > > kernel try > > > > drbd [1] > > > > 1) Nodes can catch up/sync > > 2) It'll be faster than anything you can do inside java > > 3) transparent to the application > > 4) debugged and proven to work inside a production env > > 5) means you can revert your changes and we don't have to worry/test > > anything > > ----------------------------------- > > > > To be honest you may be on the right path long term and I don't currently > > have a better suggestion, but we are really reinventing the wheel here > > which leads me to be highly cautious. > > Reinventing the wheels? How does drbd handle the topology. Does it > know which nodes are backed by which node? Usually in more > sophisticated environment each node in cluster is backed by one other > node forming a ring and the container can be in charge of forming the > topology. How does drbd handle scenario like that?
I'm being lazy and uncreative in my response.. So here are a few quotes from the site.. "DRBD is a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid-1." "Each device (DRBD provides more than one of these devices) has a state, which can be 'primary' or 'secondary'. " I understand your description and I'm wondering what you're using for the fencing/quorum device or monitoring if you're handling this entirely in java. Lets be honest that adding transparent clustering support to wicket will be a multi-phased roll-out. Stable single node under duress two node cluster N node.. and then increase by a factor of 10 working out bottlenecks as we go.. Focusing on just the two-node HA use case I think is a first step. For me this is especially important in that I primarily work with ASP/SAAS companies where maintaining a quality SLA and a single point of failure just isn't reasonable. (The way wicket lets you roll out complex applications quickly makes it a sweet spot in terms of frameworks for them.) All with a grain of salt.. ./C --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
