 |
Index for
Section 4 |
|
 |
Alphabetical
listing for C |
|
 |
Bottom of
page |
|
clua_services(4)
NAME
clua_services - Defines sockets, protocols, and connection attributes for
Internet services that use cluster aliases
SYNOPSIS
/etc/clua_services
DESCRIPTION
The cluster alias subsystem provides a mechanism to associate a network
address with a cluster alias (a hostname) without associating the address
with a physical network interface. Client systems can invoke a network
service on one or cluster nodes without explicit regard to which nodes are
up or which nodes are running the service.
Note
Each cluster has a default cluster alias, the name of the
cluster, which is assigned a network address when the cluster is
created. Other aliases are created as needed using the cluamgr
command.
Many applications running in a cluster can operate without knowledge that
they are in a cluster, and still be reached at a cluster alias address.
Other applications will benefit from being made cluster aware. A cluster
aware application might need to bind explicitly to a cluster alias address:
for example, to send a reply using the same network address over which it
received a request (using the library routines clua_getaliasaddress() or
clua_getdefaultalias()).
Applications that bind to dynamic network ports and use the port mapper to
enable clients to find them can use the clusvc_getcommport() or
clusvc_getresvcommport() functions to permit multiple copies of the
application to run on different cluster nodes using the same dynamic
network port.
The /etc/clua_services file is a static configuration file in which you
register services that use well-known ports for connections through a
cluster alias address. When registering a service, you also specify
attributes that govern the service's behavior under the alias. A service is
treated as one that:
· Runs on one member at a time (in_single).
Note that there could be several member running the service in the
cluster; however, the alias subsystem will deliver requests or
messages only to one member.
· Runs on multiple members simultaneously (in_multi).
· Rejects messages addressed to a cluster alias (in_noalias).
· Rejects messages addressed to a specific member of the cluster
(in_nolocal).
· Uses the default cluster alias IP address as its source address
(out_alias).
· Registers its port so that the port cannot be assigned as a dynamic
port (static).
By default, the /etc/clua_services file contains a subset of the services
defined in the /etc/services file. You can add user-defined services to
/etc/clua_services. If you modify the clua_services file, run cluamgr-f on
each cluster member in order for the modifications to take effect.
The entry for a service consists of a single line of the following form:
ServiceName PortNumber/ProtocolName Options
Fields are separated by spaces or tabs. Comments begin with a # (number
sign) and continue to the end of the line.
The fields contain the following information:
ServiceName
The official Internet service name.
PortNumber/ProtocolName
The socket port number used for the service and the transport
protocol used for the service. These are the same numbers and
names used in /etc/services.
Options A comma-separated list of cluster alias options.
The following list describes the available Options:
in_multi Indicates a service that can run concurrently on two or more
cluster members.
For TCP, the cluster alias software distributes connection
requests from clients using a round-robin algorithm. Each
connection is bound to a single alias member, but different
connections to the service from the same client might be
established on different alias members.
For UDP, the cluster alias software distributes messages using a
round-robin algorithm. Each packet might go to a different alias
member.
See cluamgr(8) for information on parameters that affect the
round-robin algorithm.
You must register a multiple-instance service, either in the
/etc/clua_services file or by calling the clua_registerservice()
function.
in_single Indicates a service that can run on only one cluster member at a
time, but can fail over to another instance of the service on
another member when the active service goes away. (Active, in
this context, relates only to messages addressed to the cluster
alias. All instances of a service are always active for their
node's local IP address(es) unless the in_nolocal attribute is
set.) As each service binds to the single-instance port, the
first is flagged as active for the alias, and the others flagged
as inactive. If the active service fails, one of the inactive
daemons is marked as active.
in_single is the default alias attribute for TCP ports. This
means that if a service is not explicitly listed in
/etc/clua_services as an in_multi service, the cluster alias
subsystem will treat the service as an in_single service.
in_noalias
Indicates a port that will not receive inbound alias messages.
out_alias When a connection is made to a port flagged as out_alias, the
default cluster alias address is used as the source address
whenever this port is used as a destination. Normally, outbound
connections (or UDP messages) use the local IP address of the
cluster member on which the client is running. (Note that
cluster-aware applications can bind explicitly to any cluster
alias address.)
It is important to remember that out_alias applies only when a
TCP connection or an outbound UDP send originates from the
cluster; that is, the cluster is the client. If a process running
on a cluster member initiates an outbound connection, and the
destination port (the port representing that half of the
connection that is not in the cluster) is flagged in the
cluster's /etc/clua_services file as out_alias, the connection
will use the default alias as its source address.
The same logic holds true when the outbound traffic is a UDP
send, because each send can be viewed as a micro-connection.
Consider the following example. An application running on a
member A in cluster B connects to a service on non-cluster node C
using port xxx. If port xxx is in /etc/clua_services with the
out_alias attribute set, the connection to node C comes from node
B (the default cluster alias). Otherwise, the connection to node
C comes from node A (the cluster member).
It is often beneficial to use the cluster alias address as the
source address for outbound traffic from the cluster (for
example, to simplify authorization). For example, the default
/etc/clua_services file assigns out_alias to the login service.
Therefore, if you decide to modify a /.rhosts file on a client to
allow non-password-protected logins and remote shells from the
cluster, use the default cluster alias as the host name, not the
host name of an individual cluster member.
The out_alias attribute has no bearing whatsoever on the port
associated with the cluster half of a connection. Assume that you
have more than one alias: the default cluster alias (deli) and
one that addresses a subset of cluster members (another-alias).
A client outside the cluster connects via TCP to a service port
using the IP address of another-alias. All return traffic within
the context of that connection will use the IP address of
another-alias as the source address. (Otherwise, there would be
no connection because a connection is uniquely identified by its
source address/port and its destination address/port. If a client
initiates a connection using another-alias as the address, the
cluster must respond using another-alias as the address.)
The following example shows the use of out_alias as a way to
apply single-system semantics to X applications displayed from
cluster members.
In /etc/clua_services, the out_alias attribute is set for the X
server port (6000). A user on a system outside the cluster wants
to run an X application on a cluster member and display back to
his or her system. Because the out_alias attribute is set on port
6000 in the cluster, the user must specify the name of the
default cluster alias when running the xhost command to allow X
clients access to his or her local system. For example, for a
cluster named deli, the user would run the following command on
the local system:
$ xhost +deli
This use of out_alias allows any X application from any cluster
member to display on that user's system. A cluster administrator
who wants users to allow access on a per-member basis could
either comment out the Xserver line in /etc/clua_services, or
remove the out_alias attribute from that line (and then run
cluamgr -f on each cluster member to make the change take
effect.)
in_nolocal
Indicates that the port will not honor connection requests to
non-alias addresses. For TCP, the port will not accept
connections; for UDP, the port will drop messages.
static Indicates that the port cannot be assigned as a dynamic port. The
port cannot be globally locked (dedicated to a single node) by
the cluster alias subsystem.
Dynamic (ephemeral) ports are automatically handed out by the
system in response to wildcard bind requests. Extending the
range of ephemeral ports beyond port 5000 to accommodate more
concurrent outbound connections results in overlaying the port
address space that was previously reserved for user well-known
ports. (The upper limit of the user range is determined by the
value of the sysconfigtab attribute ipport_userreserved.)
An application using a well-known port in this extended range
runs the risk of having that port assigned as an ephemeral port
before the application has a chance to bind to it (especially if
the service does not start when the system boots). To avoid this,
mark the port as a static port to make sure that it will never be
dynamically assigned a port number.
The same principle holds for the well-known reserved (privileged)
ports between 512-1024. An application is using a well-know
reserved port marked static should start at boot time, for
example through a mechanism like inetd.conf. Otherwise, an
application trawling for a reserved port might get the port even
though it is marked static. (There is no way to differentiate
between an application that is searching for a reserved port and
one that knows which well-known port it wants.)
Specifying a port as static also prevents a port from being
globally locked (dedicated to a single node) by the cluster alias
subsystem. This lets unmodified applications binding to a well-
known port run on several nodes in the cluster. Note that unless
in_multi is also set, the first application run will always be
selected by the round-robin algorithm.
Administrators should keep entries marked static synchronized
with the actual applications running on the system. If not
running an application whose port is marked static, comment out
that port entry in clua_services. Conversely, make sure that
static port entries for running applications are uncommented.
The in_multi, in_single, and in_noalias options are mutually exclusive.
The in_nolocal and in_noalias options are mutually exclusive.
Note
Applications can use the clua_registerservice() function as an
alternative to adding an entry to the clua_services file.
The strings used in the /etc/clua_services file have a 1:1 mapping to the
CLUASRV_* flags used by clua_registerservice(). Some of these strings/flags
also have a relationship with the cluster alias setsockopt() options. The
following table shows these relationships.
______________________________________________________________
clua_services clua_registerservice() setsockopt()
______________________________________________________________
in_multi CLUASRV_MULTI
in_single CLUASRV_SINGLE
in_noalias CLUASRV_IN_NOALIAS SO_CLUA_IN_NOALIAS
out_alias CLUASRV_OUT* SO_CLUA_DEFAULT_SRC**
in_nolocal CLUASRV_IN_NOLOCAL SO_CLUA_IN_NOLOCAL
static CLUASRV_STATIC
SO_REUSEALIASPORT
______________________________________________________________
* The CLUASRV_OUT flag forces the default cluster alias as the source
address only if the destination port for the service has the out_alias
attribute set in the clua_services file.
** The SO_CLUA_DEFAULT_SRC option does not check the attributes associated
with the destination port. (Note that neither CLUASRV_OUT nor
SO_CLUA_DEFAULT_SRC will override the manual setting of an address. These
two options set the source address to the default cluster alias only if the
address is not yet set.)
EXAMPLES
The following example shows sample entries in the clua_services file. The
login, who, and Xserver entries are explained after the example.
echo 7/tcp in_multi
echo 7/udp in_multi
discard 9/tcp in_multi
discard 9/udp in_multi
daytime 13/tcp in_multi
daytime 13/udp in_multi
netstat 15/tcp in_single
quote 17/udp in_multi
chargen 19/tcp in_multi
chargen 19/udp in_multi
ftp 21/tcp in_multi
telnet 23/tcp in_multi,out_alias
smtp 25/tcp in_multi
time 37/tcp in_multi
time 37/udp in_multi
.
.
.
login 513/tcp in_multi,out_alias,static
who 513/udp in_noalias,static
.
.
.
# Xserver is the X Windows server port. The following line lets a
# user on a workstation outside the cluster give display access to the
# default cluster alias using the xhost +<default_alias> command.
# Giving access to the cluster alias lets any cluster member display
# to that workstation. If you prefer that users authorize each
# cluster member individually with the xhost command, comment out the
# following line.
Xserver 6000/tcp out_alias,static # X Windows Server
Because the login service has the in_multi attribute set, the alias
subsystem will distribute login requests among members of the default
cluster alias. This means that if you log in to the cluster using the
cluster name rather than the host name of an individual member, the login
request will go to whichever cluster member is next on the alias
subsystem's list of eligible members.
The out_alias attribute ensures that login requests originating from a
cluster member will use the default cluster alias as the source address.
The static attribute means that port 513 will not be assigned as a dynamic
port. Note that both protocols using port 513 have the static attribute
set.
Because the who service has the in_noalias attribute set, the alias
subsystem will reject who requests made to a cluster alias. A who request
must be made directly to a member of the cluster.
Because the Xserver service has the out_alias attribute set, all X Window
applications displayed from the cluster will use the default cluster alias
as the source address. For example, you cannot treat xterm differently from
dxaccounts; setting out_alias for a service like an X server affects all
applications that use the service.
FILES
/etc/clua_services
Static configuration file where services using well-known ports
are registered for cluster alias connections.
SEE ALSO
Commands: cluamgr(8), clua_active(8), aliasd(8)
Functions: clua_error(3), clua_getaliasaddress(3), clua_getaliasinfo(3),
clua_getdefaultalias(3), clua_isalias(3), clua_registerservice(3),
clusvc_getcommport(3)
Files: clu_alias.config(4), exports.aliases(4)
|
Index for
Section 4 |
|
|
Alphabetical
listing for C |
|
 |
Top of
page |
|