From owner-freebsd-cluster Mon Jul 15 2:23:51 2002 Delivered-To: freebsd-cluster@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E84AD37B400 for ; Mon, 15 Jul 2002 02:23:47 -0700 (PDT) Received: from gate.nentec.de (gate2.nentec.de [194.25.215.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9203C43E64 for ; Mon, 15 Jul 2002 02:23:46 -0700 (PDT) (envelope-from sporner@nentec.de) Received: from nenny.nentec.de (root@nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.11.3/8.9.3) with ESMTP id g6F9NjA00868; Mon, 15 Jul 2002 11:23:45 +0200 Received: from nentec.de (andromeda.nentec.de [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g6F9NgZ23684; Mon, 15 Jul 2002 11:23:43 +0200 Message-ID: <3D32949E.8040500@nentec.de> Date: Mon, 15 Jul 2002 11:23:42 +0200 From: Andy Sporner User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:0.9.8) Gecko/20020204 X-Accept-Language: de-at, de, en, en-us MIME-Version: 1.0 To: Clifton Royston Cc: aaron g , freebsd-cluster@FreeBSD.ORG Subject: Re: SPREAD clusters References: <20020709212404.16403.qmail@operamail.com> <3D2D483E.4040100@nentec.de> <20020711084338.B18402@lava.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-cluster@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Clifton Royston wrote: >>the last 4 years and have never had a chance to commit it to a >>document. I suppose it is probably about time to do so. I even came >>up with a way that network applications can survive a node move as >>well, though it requires a special protocol and a front-end device to >>achieve this. For the sake of the front-end device and potential >>single points of failures, we have phase-1 of the clustering >>software, but ultimately, phase-2 should completely replace phase-1 >>for everything else. >> > > I assume this will be targeted at the current -current track (5.x >release) to take advantage of the major rewrite of kernel scheduling >there? > Yes, absolutely. >This sounds like a great project. I'm in agreement with both your >goals and the stages you're talking about to reach it. I've had >daydreams of trying to hammer together something similar, but don't >have the experience with clustering that you've brought to the project. >Addressing basic application failover in a structured way as you've >done does seem like the best place to start, and then go for the big >issues of moving processes, interacting with other kernels, etc. I >agree that it wouldn't make much sense sinking too much effort into >load-balancing the *front* end (network connections) in software at >this stage, when there are hardware products out there that will do it >at a reasonable price. > Well our device starts about 15K (but you get 32 10/100's ports and 4 Gb ports full line speed switching--and High availability--gee I wonder where this comes from ;-)) > > If you don't mind, maybe this sketch of the project you just gave >could be committed to the documentation as a starting point. > Yep. I will write a paper about phase-2. It should be easy if I grab all of the fragments of things I said before. > > > On the storage front, do you think it would be worthwhile to also >address in an upcoming phase the failover of shared storage access, >using something like the "Tertiary Disk project" node design at: > > I had an idea to extend Vinum in a way to provide "Remote Raw Disks", which might be similar to Tertiary Disk Project. Have you interest in taking this a working point? Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-cluster" in the body of the message