Host Groups

Multiple servers with common authentication and storage resources can be targeted by clients for load-balancing and fail-over.  Server host groups are utilized by providing a client with a list of servers to consider.  The client will rapidly query the group and choose the most appropriate server.

This section contains details about Host Group syntax and usage.  For a broader discussion of load balancing, active-active, and active-passive server strategies see Tech Note 0034.

Syntax

Servers may be grouped as singletons, peers, and fallbacks.

A singleton is one server host, specified by DNS name or IP address plus an optional port number.  The following examples show valid singleton hosts:

192.0.2.1 192.0.2.1+8080 example.com example.com+8080

Graphical clients may also accept URL style port numbers, delimited with a colon.  Command line clients will not accept colons for port numbers as they use colons to separate the host from the path name.

example.com:8080 192.0.2.1:8080

A peer group is a list of one or more singletons which will all be queried at the same time.  The client will choose the best available server from the list.  Peer groups allow transactions from many clients to be evenly spread amongst multiple servers.  If one of the servers in a peer group becomes unreachable, loads automatically shift to the others.  Hosts in a peer group are separated by commas:

exp1.example.com,exp2.example.com+8000,192.0.2.1

A fallback group is a list of one or more peer groups which will be queried in the order given.  Peer groups later in the list will only be used if no servers are reachable in an earlier group.  This can be used to specify servers which should only be used in case of disaster, such a those with limited resources or DR restricted licenses.  Fallback groups are separated by semicolons:

exp1.example.com,exp2.example.com;dr1.example.com,dr2.example.com

In the example above, transactions will be evenly distributed amongst "exp1" and "exp2".  The fallback servers "dr1" and "dr2" will only be used if both "exp1" and "exp2" are unreachable.  Note that the semi-colon is a reserved character in many command shells, so command-line clients may require you to escape arguments containing them with quotes or backslashes.  For example:

movedat "user@exp1.example.com,exp2.example.com+8000;dr.example.com:/path/file" /tmp/

Requirements

Host groups are specified and managed entirely by individual clients.  The servers do not need any special configuration to participate in a group.  However, all servers in a host group must share the following properties:

• All must accept the given username and password.
• For downloading transactions, all must have the requested file available at the given path.
• For uploading transactions, all must have the target directory available.

Because the client may fail-over to a different server in the middle of a session, all servers in a host group should be as identical as possible.

When evaluating servers in a peer group, the server with the most available capacity is chosen.  In case of a tie, the server with the lowest network delay is chosen.  Bandwidth is not considered.  It is best if all servers in a peer group have the same capacity and bandwidth.

The maximum number of servers allowed in a peer group may vary depending on the number of servers you have licensed and their capacity, but is always at least 16.  The maximum number of servers for all peer and fallback groups is at most 64.  Some client applications may limit the length of the host group string.  For example, ExpeDat Desktop limits its server field to 256 bytes.

Timing

Clients will typically wait up to 3 seconds for all servers in a peer group to respond.  If a server is down, it may take up to 3 seconds per fallback group to find a reachable server.  This delay may be reduced by ensuring that the network permits ICMP traffic to travel between the clients and servers.  Some clients will remember successes and failures for a short time to minimize such delays.