This section provides information about configuring a failover group in a network configuration when using a private network or when using a Sun Ray server as a DHCP server.
If you have Sun Ray dedicated interconnects, all services required by Sun Ray clients should be provided by multiple, redundant servers to ensure continuity of Sun Ray service in the case of a network or system failure. For example, you must configure DHCP (IP address assignment and configuration) or DNS (name resolution) on all servers.
The failover feature cannot work properly if the IP addresses and DHCP configuration data are not set up properly when the interfaces are configured. In particular, if any Sun Ray server's interconnect IP address is a duplicate of any other server's interconnect IP address, the Sun Ray Authentication Manager will fail to operate properly.
A failover group can consist of servers in either a common, dedicated interconnect or servers within a LAN. However, the servers in a failover group must still be able to reach one another, using multicast or broadcast, over at least one shared subnet. Servers in a group authenticate (or "trust") one another using a common group signature. The group signature is a key used to sign messages sent between servers in the group. This key must be configured to be identical on each server.
When a dedicated interconnect is used, all servers in the failover group should have access to, and be accessible by, all the Sun Ray Clients on a given sub-net. Routers should not be attached to a dedicated interconnect. The failover environment supports the same interconnect topologies that are supported by a single-server Sun Ray environment; however, switches should be multicast-enabled.
If multicast does not work in your network, you may use
broadcast instead. To disable multicast, use the
enableMulticast property in the
auth.props file. In special cases, you may
configure an explicit list of group servers using
utgmtarget. For example, you would use
utgmtarget to integrate servers on a
different subnet into a failover group. Communication to these
servers use unicast. Note that adding such a server to the
group will require a restart of the entire server group.
Figure 20.4, “Simple Failover Group” shows a simple failover group setup.
When a server in a failover group fails for any reason, each Sun Ray Client connected to that server reconnects to another server in the same failover group. The failover occurs at the user authentication level: the client connects to a previously existing session for the user's token. If session exists, the client connects to a server selected by the load-balancing algorithm. This server then presents a login screen to the user, and the user must relogin to create a new session. The state of the session on the failed server is lost.
Figure 20.5, “Redundant Failover Group” shows an example of a redundant failover group.
The redundant failover group, shown in the illustration
above, can provide maximum resources to a few Sun Ray
Clients. The server sr47 is the primary Sun Ray server, and
sr48 is the secondary Sun Ray server; other secondary
servers (sr49, sr50,
and so on) are not shown.
You can use the utadm command to set up a DHCP server. The default DHCP setup configures each interface for 225 hosts and uses private network addresses for the Sun Ray interconnect. For more information, see the utadm man page.
Before setting up IP addressing, you must decide upon an addressing scheme. The following examples discuss setting up class C and class B addresses.
The loss of a server usually implies the loss of its DHCP service and its allocation of IP addresses. Therefore, more DHCP addresses must be available from the address pool than the number of Sun Ray Clients. Consider the situation of 5 servers and 100 Sun Ray Clients. If one of the servers fails, the remaining DHCP servers must have enough available addresses so that every "orphaned" Sun Ray Client is assigned a new working address.
Table 20.5, “Configuring 5 Servers for 100 clients” lists configuration settings used to configure 5 servers for 100 Sun Ray Clients, accommodating the failure of two servers (class C) or four servers (class B).
Table 20.5. Configuring 5 Servers for 100 clients
|
CLASS C (2 Servers Fail) |
CLASS B (4 Servers Fail) | |||
|---|---|---|---|---|
Servers | Interface Address | Client Address Range | Interface Address | Client Address Range |
|
|
192.168.128.1 |
192.168.128.16 to 192.168.128.49 |
192.168.128.1 |
192.168.128.16 to 192.168.128.116 |
|
|
192.168.128.2 |
192.168.128.50 to 192.168.128.83 |
192.168.129.1 |
192.168.129.16 to 192.168.129.116 |
|
|
192.168.128.3 |
192.168.128.84 to 192.168.128.117 |
192.168.130.1 |
192.168.130.16 to 192.168.130.116 |
|
|
192.168.128.4 |
192.168.128.118 to 192.168.128.151 |
192.168.131.1 |
192.168.131.16 to 192.168.131.116 |
|
|
192.168.128.5 |
192.168.128.152 to 192.168.128.185 |
192.168.132.1 |
192.168.132.16 to 192.168.132.116 |
The formula for address allocation is: address range (AR) = number of clients/(total servers - failed servers). For example, in the case of the loss of two servers, each DHCP server must be given a range of 100/(5-2) = 34 addresses.
Ideally, each server would have an address for each client. This setup requires a class B network. Consider these conditions:
If AR multiplied by the total number of servers is less than or equal to 225, configure for a class C network
If AR multiplied by the total number of servers is greater than 225, configure for a class B network
If all available DHCP addresses are allocated, a Sun Ray Client could request an address and still not find one available, perhaps because another unit has been allocated IP addresses by multiple servers. To prevent this condition, provide each DHCP server with enough addresses to serve all the Sun Ray Clients in a failover group.
Server IP addresses assigned for the Sun Ray interconnect should all be unique. Use the utadm tool to assign them.
When the Sun Ray Client boots, it sends a DHCP broadcast request to all possible servers on the network interface. One or more servers respond with an IP address allocated from its range of addresses. The client accepts the first IP address that it receives and configures itself to send and receive at that address.
The accepted DHCP response also contains information about the IP address and port numbers of the Authentication Managers on the server that sent the response.
The client then tries to establish a TCP connection to an Authentication Manager on that server. If it is unable to connect, it uses a protocol similar to DHCP, in which it uses a broadcast message to ask the Authentication Managers to identify themselves. The client then tries to connect to the Authentication Managers that respond in the order in which the responses are received.
For the broadcast feature to be enabled, the broadcast address (255.255.255.255) must be the last one in the list. Any addresses after the broadcast address are ignored. If the local server is not on the list, Sun Ray Clients cannot attempt to contact it.
Once a TCP connection to an Authentication Manager has been established, the client presents its token. The token is either a pseudo-token representing the individual client (its unique Ethernet address) or a smart card. The Session Manager then starts an X Window/X server session and binds the token to that session.
The Authentication Manager then sends a query to all the other Authentication Managers on the same subnet and asks for information about existing sessions for the token. The other Authentication Managers respond, indicating whether a session for the token exists and the last time the token was connected to the session.
The requesting Authentication Manager selects the server with the latest connection time and redirects the client to that server. If no session is found for the token, the requesting Authentication Manager selects the server with the lightest load and redirects the token to that server. A new session is created for the token.
The Authentication Manager enables both implicit (smart card) and explicit switching.
In a large IP network, a DHCP server distributes the IP addresses and other configuration information for interfaces on that network.
The Sun Ray DHCP server can coexist with DHCP servers on other subnets, provided that you isolate the Sun Ray DHCP server from other DHCP traffic. Verify that all routers on the network are configured not to relay DHCP requests, which is the default behavior for most routers.
If the IP addresses and DHCP configuration data are not set up correctly when the interfaces are configured, the failover feature cannot work properly. In particular, configuring the Sun Ray server's interconnect IP address as a duplicate of any other server's interconnect IP address may cause the Sun Ray Authentication Manager to issue "Out of Memory" errors.
If the Sun Ray server has multiple interfaces, one of which is the Sun Ray interconnect, the Sun Ray DHCP server should be able to manage both the Sun Ray interconnect and the other interfaces without cross-interference.
Log in to the Sun Ray server as superuser and, open a shell window. Type:
# /opt/SUNWut/sbin/utadm -a
interface_namewhere
interface_nameis the name of the Sun Ray network interface to be configured; for example,hme[0-9],qfe[0-9], orge[0-9]. You must be logged on as superuser to run this command. The utadm script configures the interface (for example,hme1) at the subnet (in this example, 128).The script displays default values, such as the following:
Selected values for interface "hme1" host address: 192.168.128.1 net mask: 255.255.255.0 net address: 192.168.128.0 host name: serverB-hme1 net name: SunRay-hme1 first unit address: 192.168.128.16 last unit address: 192.168.128.240 auth server list: 192.168.128.1 firmware server: 192.168.128.1 router: 192.168.128.1 |
The default values are the same for each server in a failover group. Certain values must be changed to be unique to each server.
When you are asked to accept the default values, type
nAccept as is? ([Y]/N): n
Change the second server's IP address to a unique value, in this case 192.168.128.2:
new host address: [192.168.128.1] 192.168.128.2 |
Accept the default values for netmask, host name, and net name:
new netmask: [255.255.255.0] new host name: [serverB-hme1]
Change the client address ranges for the interconnect to unique values. For example:
Do you want to offer IP addresses for this interface? [Y/N]: new first Sun Ray address: [192.168.128.16] 192.168.128.50 number of Sun Ray addresses to allocate: [205] 34
Accept the default firmware server and router values:
new firmware server: [192.168.128.2] new router: [192.168.128.2]
The utadm script asks if you want to specify an authentication server list:
auth server list: 192.168.128.1 To read auth server list from file, enter file name: Auth server IP address (enter <CR> to end list): If no server in the auth server list responds, should an auth server be located by broadcasting on the network? ([Y]/N):
These servers are specified by a file containing a space-delimited list of server IP addresses or by manually entering the server IP addresses.
The newly selected values for interface
hme1are displayed:Selected values for interface "hme1" host address: 192.168.128.2 net mask: 255.255.255.0 net address: 192.168.128.0 host name: serverB-hme1 net name: SunRay-hme1 first unit address: 192.168.128.50 last unit address: 192.168.128.83 auth server list: 192.168.128.1 firmware server: 192.168.128.2 router: 192.168.128.2
If these are correct, accept the new values:
Accept as is? ([Y]/N): y
Stop and restart the server and power cycle the clients to download the firmware.
Table 20.6, “utadm Available Options” lists the options available for the
utadm command. For additional
information, see the utadm man page.
Table 20.6. utadm Available Options
Option | Definition |
|---|---|
| Create a framework for the Sun Ray interconnect. |
| Remove all Sun Ray interconnects. |
| Configure the subnetwork specified as a Sun Ray sub-network. This option only configures the DHCP service to allocate IP address and/or to provide Sun Ray parameters to Sun Ray clients. It also will automatically turn on support for LAN connections from a shared subnetwork. |
|
Add |
| Delete the subnetwork specified form the list of configured Sun Ray subnetworks. |
|
Delete
|
| Print the current configuration for all the Sun Ray subnetworks, including remote subnetworks. |
| Print the current configuration. |
| Take a server offline |
| Bring a server online |
| Print the current configuration in a machine-readable format |
Fill out Table 20.7, “Sun Ray Server Failover Group Worksheet” and Table 20.8, “First and Last Unit Address in a Failover Group”, so that the information is readily available during the actual configuration process.
Values that are provided in italics are only examples and should not be used.
Values provided in normal font are defaults and can be used.
Superscripted numbers (#) refer to footnotes at the end of each section.
The blank rows in the worksheets are provided for you to add additional information about your environment if you choose to print the worksheets.
If you are configuring for a failover group, fill in this portion of the worksheet:
Table 20.7. Sun Ray Server Failover Group Worksheet
Aspect or Variable | Default Value, Example, or (Other) | Your Primary Server Value | Your Secondary Server Value |
|---|---|---|---|
Configuring the Sun Ray server hierarchy using utreplica (required for failover groups) | (Provide the start time) | ||
Primary Sun Ray server host name (1) | primary-server | ||
Secondary Sun Ray server host name (1) | secondary-server |
(1) These values are different for each Sun Ray server, even if that server is part of a failover group.
Table 20.8. First and Last Unit Address in a Failover Group
Server | First Unit Address | Last Unit Address |
|---|---|---|
Primary Secondary Secondary Secondary | 192.168.128.16 192.168.128.56 192.168.128.96 192.168.128.136 | 192.168.128.55 192.168.128.95 192.168.128.135 192.168.128.175 |
If you forget the address range, use utadm -l to list the addresses you specified or utadm -p to print them.
