All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ragnar Kjørstad" <kernel@ragnark.vestdata.no>
To: Chuck Wu <wu@cnds.jhu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Two-machine cluster efficient approach(?) Comment? Thanks.
Date: Fri, 25 May 2001 02:18:42 +0200	[thread overview]
Message-ID: <20010525021840.C29754@vestdata.no> (raw)
In-Reply-To: <Pine.BSI.4.05L.10105241825270.25527-100000@commedia.cnds.jhu.edu>
In-Reply-To: <Pine.BSI.4.05L.10105241825270.25527-100000@commedia.cnds.jhu.edu>; from Chuck Wu on Thu, May 24, 2001 at 06:32:10PM -0400

On Thu, May 24, 2001 at 06:32:10PM -0400, Chuck Wu wrote:
> Two machines want to be accessed by the same IP address and
> share workload. Can not change the router. Can only change 
> local linux system. Will the following approach work? Thanks.

You should check out Linux Virtual Server; it does something simular
(only it doesn't reply to arp-requests with broadcast-address, but with
one of the servers' ethernet-address).

> Solution:
> ---------
> 1. Reserve an unused IP as the to be publicized "Server IP", actually no
>    machine takes it. So, it is kind of "virtual IP".
> 2. Alias the NIC of those two work stations to this "virtual IP" so they
>    can accept packets to this "virtual IP".
> 3. For ARP request packet to this "virtual IP", those two work stations
>    will return the MAC broadcast address. Then, all the packets to the
>    "virtual IP" will be broadcast to this subnet and those two machines
>    will get such packtes.
> 4. Before such packets gets into the TCP/IP stack, use a hash function
>    to filter the packets. Say, workstation A will accept packets whose
>    source IP is an odd number and discard the packets with even-number
>    source IP.

If this work, a useful addon would be to use something a little more
advanced, to allow it to scale to more than 2 servers.

> 5. For the outgoing packets from those two workstations, change the source
>    IP address to be the "virtual IP".
> 6. Have another thread keep ping each other, once another workstation
>    crashes, change my hash function to accept all the packets to the
>    "virtual IP". Whenever another workstation resumes, switch back to
>    the original hash function.
> 
>    Do you think if this approach will work? There is also a question I
> am not quite sure, can two machines's NICs be aliased to the same "virtual
> IP"? Will it cause some conflicts? And, it seems I need to change the
> linux kernel source code. I am not pretty sure where is the location of
> the source code related to the above operations. Like, can you tell me the
> location of the linux kernel source code to answer an ARP request packet,
> to build a hash function to filter the incoming IP packets before it
> enters the TCP/IP stack?


--
Ragnar Kjørstad
Big Storage

      reply	other threads:[~2001-05-25  0:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-24 22:32 Two-machine cluster efficient approach(?) Comment? Thanks Chuck Wu
2001-05-25  0:18 ` Ragnar Kjørstad [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010525021840.C29754@vestdata.no \
    --to=kernel@ragnark.vestdata.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wu@cnds.jhu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.