On Jan 12, 2008 1:04 PM, C. Bergström <[EMAIL PROTECTED]> wrote: > > > 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? >
The thing is, we don't really care what the topology is. The only requirement is that the session gets immediately deserialized once it is replicated to other node, which should be either default or at least configurable on most containers. So we let the container manage the replication topology. All we need is to be notified when the session is replicated (pagemap serialization and deserialization). All other approaches would require container specific code. -Matej > 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] > > -- Resizable and reorderable grid components. http://www.inmethod.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
