[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ssic-linux-devel
Subject:    re[2]: [SSI] [Design] Cluster wide TCP and LVS Part 2
From:       Greg Freemyer <freemyer () NorcrossGroup ! com>
Date:       2002-04-30 17:05:49
[Download RAW message or body]

 >>  > CLUSTE WIDE  TCIP/IP:

 >>  Let's see if I understand the environment, issues and options.
 >>  There are several kinds of listening daemons we may wish to run in the
 >>  cluster.  All of them no doubt will just do wildcard listens:
 >>  a. daemons that are strictly local and not parallel and
 >>  don't want to be listening on the VIPs (just the local
 >>  physical interfaces;
 >>  b. single instance daemons (not parallel) that might be
 >>  started anywhere in the cluster and mostly want to listen
 >>  on VIP and have a fixed port number.
 >>  c. single instance daemons (not parallel) that might be
 >>  started anywhere in the cluster and mostly want to listen
 >>  on VIP and want to use an ephimeral port number.
 >>  d. parallel instance daemons (like http) that want to run on
 >>  every node and listen on the VIP and local interfaces, with
 >>  VIP traffic being load levelled to them.

 >>  LVS is just fine at handling case a (not involved), case b (somewhat
 >>  degenerate case of d) and d (what LVS was meant for.  Case c is
 >>  a problem because you need a unique port number which the system must
 >>  pick and you need it registered with ldirectord.  Question is, is this
 >>  a very interesting case to worry about.

 >>  Now, the main place that port space is an issue is with those doing
 >>  connects, which often get an ephimeral local port number for the
 >>  socket.  The port space needs only to be unique w.r.t. the ip
 >>  address so this is a clusterwide issue only when we allow 
 >>  binds/connects on VIPs  (normally the program doesn't
 >>  specify an ip address and the system picks the one that it is going
 >>  to route the traffic out on).  If we want to support VIP as
 >>  the address on outgoing connections 

> > ( I suspect no one else does this?),

 >>  we have to provide a clusterwide port space and must register the
 >>  port with ldirector so that the traffic from the remote node can
 >>  be directed to the local node that initiated the connection.
 >>  

Tru64/TruClusters V5 supports using the VIP for outgoing connections.  Since \
TruClusters was based on OpenVMS clusters, I assume it also does this.

In one of the config files you can tell TruClusters whether to use the VIP or not \
based on the _target_ port number. 

The default is not to use it.  IIRC, Telnet is configured to use it.  

i.e. By default on a TruClusters V5 machine any socket opened with a _target_ port of \
23 will have the originating IP set to the VIP.

As I understand it, this was done to allow integration into secure environments to be \
easier.  i.e. firewalls, and other security mechanisms only have to know about the \
VIP, not all of the individual node IPs.


 >>  I think we need to discuss the specific goals a little more before
 >>  going on the implementation.

You should also look into the rather unusual mechanism Java RMI uses for assigning \
port numbers.  (The logic behind it defies me.)

I don't know if Java RMI will qualify as a case c) or not.

I am _not_ a Java RMI expert, but I think the below is accurate. 

FYI: If you get to where you really need to know, I can put a sniffer on and get a \
detailed trace, but it might be better to get a Java RMI expert to explain it.

With JAVA RMI a RMI Registration Process runs as daemon and a well-known port is \
listened to by this daemon.  When a client connects, a new _thread_ is kicked off \
dedicated to that client.  The new thread  requests an ephemeral port and _listens_ \
on it.  The client is notified of the new port on the original socket.  Then the \
client closes the original socket and _connects_ to the new socket.

WIth this bizarre behavior, you conceivably can have problems with both the ephemeral \
port, and also with the IP address on the second listen.

 >>  bruce

Greg Freemyer
Internet Engineer
Deployment and Integration Specialist
Compaq ASE - Tru64
Compaq Master ASE - SAN Architect
The Norcross Group
www.NorcrossGroup.com


_______________________________________________
ssic-linux-devel mailing list
ssic-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel


[prev in list] [next in list] [prev in thread] [next in thread]