Host Group

From Sun Ray User Group Wiki

A host group (aka failover group or FOG for short) consists of two or more Sun Ray servers grouped together to provide Sun Ray services for a population of Sun Ray DTUs.

• The failover part of the failover group refers to the availability of service for a DTU. It does not mean that your actual desktop session (i.e. Gnome, CDE, CAM) will move to another server should one fail. In fact there is no real failover functionality in a so-called failover group, which is why the SRSS documentation uses the term Sun Ray host group (or just host group). Even so, the failover group term is in widespread use. Apparently the FOG acronym is just too catchy to resist.

• Members of a Sun Ray host group share a common group signature. The authenticity of the signature is verified by the Sun Ray group management protocol. This protocol is responsible for discovering the presence of other servers, establishing the membership of host group, tracking the connectivity between servers, hotdesking existing sessions within the group, and placing new sessions within the group.

• A server's group signature is managed by the utgroupsig command

• The Sun Ray group management protocol depends on multicast packet transmissions by default. Some switches have trouble propagating (or deliberately block) multicast traffic, so SRSS can be configured to use broadcast instead. This is done by editing /etc/opt/SUNWut/auth.props and setting the enableMulticast property to false. All members of the group must be configured to use the same mechanism.

• Because of these real-world multicast shortcomings SRSS officially requires that all members of a host group must share at least one common subnet, so that the broadcast-based protocol is always viable. If you choose to deploy without a common subnet then you must ensure that your routers will pass multicast traffic and you will need to adjust the MulticastTTL value in /etc/opt/SUNWut/auth.props to a value that allows all members to exchange packets. The TTL must be at least one greater than the maximum number of routers between any two members of the group.

• The current limit is 100 servers in a group, although they seldom get that large due to geographic networking limitations

• The health of the group is displayed by the utgstatus command

A host group exists independently of the Sun Ray Data Store (abbreviated SRDS, or just DS). However, if you choose to activate the DS (via the utconfig command) in order to take advantage of SRSS features that require it then you should arrange for the DS content to be replicated across all of the members of the group. Since the DS holds Sun Ray policy settings, configuration records and user preferences this group-wide replication provides consistent SRSS behaviour and a consistent experience for the Sun Ray users.

• DS replication requires one server to act as the 'primary' and the remaining servers to act as 'secondaries'. Updates are always performed against the primary and are then replicated to the secondaries. (Update commands may be executed on a secondary, but under the hood the update is quietly redirected to the primary.)

• Data Store replication, including the assignment of primary and secondary roles, is configured by the utreplica command

• A host group can operate while the DS primary is down, but updates like creating new registrations or adding users to the DS will not work.

• If you have more than four servers in a host group, it is a best practice to have a dedicated DS primary (a machine that does not offer Sun Ray sessions) for the following reasons:

• Adding or removing secondary servers requires a services restart on the primary server; if the primary hosts no sessions then no sessions are disrupted by the restart.

• In large groups the utdsd and utpushd DS processes may place significant short-term CPU and network load on the primary server.

• Runaway processes from user applications on the primary can degrade DS replication across the entire group.

• A dedicated DS primary need not be a large machine. Availability is the most important factor.

• The easiest way to construct a dedicated DS primary is to install and configure SRSS just as you would on any other Sun Ray server, except that you do not run any utadm commands on this machine.