Date: Tue, 7 Nov 2000 01:22:26 -0600 From: "Michael C . Wu" <keichii@iteration.net> To: Andrew Sporner <andy.sporner@networkengines.com> Cc: freebsd-net@freebsd.org, "'freebsd-hackers@freebsd.org'" <freebsd-hackers@freebsd.org> Subject: Re: High-availability failover software available. Message-ID: <20001107012226.A61671@peorth.iteration.net> In-Reply-To: <8D18C4F9CBA1D311900F00A0C990C97F67CB44@neimail.networkengines.com References: <8D18C4F9CBA1D311900F00A0C990C97F67CB44@neimail.networkengines.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>; from andy.sporner@networkengines.com on Mon, Nov 06, 2000 at 05:59:57PM -0500
X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20
X-PGP-Key-ID: 0x8FA12E20
[Moving to -net, please remove -hackers cc when replying]
On Mon, Nov 06, 2000 at 05:59:57PM -0500, Andrew Sporner scribbled:
| Hi,
|
| Please allow me to introduce myself. I am Andrew Sporner and I have
Hi, :)
| a H/A Failover system that happens to work with BSD. I would like to
| contribute
| this to the FreeBSD project or at a minimum make it available to those who
| What it includes is:
| - Multi-path heartbeat based node failure detection.
How do you determine that a machine/service is "failing"?
Have you considered that the distributed nodes might be very far
away from each other, even across the globe? Lag time can
lead to daemon falsely thinking that a node is down.
Example: condition, Cross pacific link being slow
Node A,B in Lake Tahoe, USA. Node C,D in Maldive Islands, South Pacific
Node C and D have gigabit LAN between each other,
and so does A and B
Lake Tahoe Pacific Ocean Maldive Islands
(A+B) <-------connected via T1-------> (C+D)
Upon lag and/or service requests to (C+D) in India, while the T1 is slow,
(C+D) should take over.
Upon service request in America, B is down, C+D still alive, A is
under high load, no matter how light the load of C+D, the service
request should be routed to A.
bla bla bla.....
(I want to buy houses in these two places one day... 8-P )
Reading your code, I don't think broadcasting over all interfaces is a good
idea. A safer way would be requiring two physical interfaces
on all nodes, building two seperate physical networks. The nodes
communicate information on one network, and do the actual "work"
on the other, more powerful, network. The daemons on the nodes
should broadcast over these two interfaces. In addition,
a comparison between the connectivity of the two physical networks
can provide lots of valuable info.
There is another bad thing about broadcasting over all interfaces,
several types of attacks can be made:
A. spoofing node packets, making controlling daemon believe some
machinese are down.
B. network internal information acquired by people that shouldn't have them.
A great thing to do with this code would be using kqueue.
| - Application failover.
| - Applications can be assigned to two or many nodes in the
| cluster. If the current node that the application runs on
| fails, the next successor picks up the application.
I think there should be a daemon that "routes" service queries, say
a http request, to different nodes as the requests come in.
| - Drag&Drop administration interface (X-11 tcl/tk based
I think this should also include a console-type controller.
Real-life work involves admining remotely, and GUI apps are not
that great remotely.
| The current state is alpha and is being tested by several people now. Beta
| The current source is located at http://www.sporner.com/bsdclusters
Please document what you have done, so we can learn more about
the engineering thinking behind your implementation.
| Please let me know what I should do...
Will this be BSDL or will it be another license? Also, please
include man pages.
| Andy Sporner
| PS. I am not sure how many of you were at BSDCon 2000, but that was some
| very good talks--especially the BIO talk.
I think we missed a great chance to talk to each other, since my
research interest is the same field as your project. Or we may have
met, I'm the Chinese guy that had the shortest hair.
P.S. Please keep lines shorter than 80 characters. :)
--
+------------------------------------------------------------------+
| keichii@peorth.iteration.net | keichii@bsdconspiracy.net |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+------------------------------------------------------------------+
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001107012226.A61671>