| SRSS 3.1.1 Administrator's Guide for Linux |    
|
| SRSS 3.1.1 Administrator's Guide for Linux |
|
| C H A P T E R 1 |
|
Sun Ray System Overview |
Although thin client computing has been discussed and attempted for many years, Sun Ray is the first implementation to offer both workstation-like user functionality and sufficient speed and reliability to be suitable for mission-critical applications. The latest generation of Sun Ray Server Software now supports many USB peripheral devices, LAN and low-bandwidth WAN deployment. Originally developed on Sun's Solaris
Operating System, Sun Ray Server Software is now also supported on two Linux variants: Red Hat Enterprise Linux Advanced Server 4 and SuSE Linux Enterprise Server 9.
The Sun Ray system employs a network-dependent model in which all computing is performed on a server, with input and output data passed back and forth between the Sun Ray server and the Sun Ray Desktop Units (DTUs). Nearly any Sun server with sufficient capacity can be configured as a Sun Ray server so long as it runs a supported version of the Solaris operating system or one of the supported flavors of Linux.
Various models of Sun Ray DTU are available, differing primarily with respect to size and type of screen; however, all Sun Ray DTUs also include a smart card reader, a keyboard, and a mouse. Sun Ray DTUs have no local disks, operating systems, or applications; they are therefore considered stateless. This is what makes them true, or "ultra" thin clients, and it is what makes them inexpensive to maintain as well as extremely secure, both from an intellectual property perspective and for government work. Although USB mass storage devices are supported in the latest release, the ability to use them is administered centrally so that sites with security requirements can easily remove the sort of risk imposed by PCs and other fat clients that allow the theft of data in case a physical device is stolen.
Because effective client-server network traffic often relies on the rapid movement of large numbers of packets, an optimal Sun Ray implementation requires a well-designed network. Most large implementations include at least one failover group to ensure uninterrupted service whenever a server goes off-line.
Once a failover group is set up, Sun Ray Server Software provides automatic load balancing to optimize performance by spreading the computing load among the servers in the group. If a server is taken out of service, the Group Manager on each remaining server tries to distribute that server's sessions evenly among the remaining servers. The load balancing algorithm takes into account each server's load and capacity (number and speed of its CPUs) so that larger or less heavily loaded servers host more sessions. These concepts are addressed in Chapter 10 and in the Sun Ray Server Software 3.1.1 Installation and Configuration Guide.
User sessions--groups of services controlled by the Session Manager and associated with a user through an authentication token--reside on a server and are directed to a Sun Ray DTU. Because Sun Ray DTUs are stateless, a user session can be redirected to any Sun Ray DTU on the appropriate network or subnetwork when a user logs in or inserts a smart card.
While the session continues to reside on a server, it appears to follow the user to the new DTU. This functionality, called session mobility, is the key architectural feature that enables hotdesking--the ability of users to access their sessions from any DTU on their network. In early versions of Sun Ray Server Software, mobile sessions were possible only with smart cards. It is now possible to enable hotdesking with or without smart cards. In addition, regional hotdesking now lets users access their sessions from increasingly remote locations.
The Sun Ray system consists of Sun Ray DTUs, servers, server software, and the physical networks that connect them.
The Sun Ray desktop unit (DTU) delivers and may exceed the full functionality of a workstation or a multimedia PC. The key features include:
compliance
The DTU acts as a frame buffer on the client side of the network. Applications run on the server and render their output to a virtual frame buffer. Sun Ray server software formats and sends the rendered output to the appropriate DTU, where the output is interpreted and displayed.
From the point of view of network servers, Sun Ray DTUs are identical except for their Ethernet MAC addresses. If a DTU ever fails, it can easily be replaced.
IP addresses are leased to each Sun Ray DTU when it is connected and can be reused when the DTU is disconnected. IP address leasing is managed by the Dynamic Host Configuration Protocol (DHCP). In cases where they already exist on a network that will support Sun Ray DTUs, separate DHCP servers may be useful for tasks such as assigning IP addresses and network parameters to the DTUs. The use of separate DHCP servers is not required; however, because they require static IP addresses, Sun Ray Servers cannot be DHCP clients. These questions are discussed in Chapter 8.
Sun Ray Server Software supports the use of multiple displays connected to a single keyboard and pointer. This functionality is important for users who need extra screen real estate, for instance, to monitor many applications or systems simultaneously or to accommodate a single application, such as a large spreadsheet, across multiple screens. To use multiple screens, the administrator sets up multihead groups, consisting of two or more DTUs, for those users who need them. Administration of multihead groups is explained in Chapter 9.
A small firmware module in each Sun Ray DTU can be updated from the server. The firmware module checks the hardware with a power-on self test (POST) and initializes the DTU. The DTU contacts the server to authenticate the user, and it also handles low-level input and output, such as keyboard, mouse, and display information. If there is a problem with the DTU, the module displays an on-screen display (OSD) icon to make it easier to diagnose. OSD icons are described in Appendix B.
Sun Ray server software allows the administrator to configure network connections, select an authentication protocol, administer users, define desktop properties, monitor the system, and troubleshoot a wide variety of administration problems.
Sun Ray server software includes:
Sun Ray server software enables direct access to all Linux X11 applications. Third-party applications running on the Sun Ray server can provide access to Microsoft Windows NT applications and a variety of legacy (mainframe) applications.
The Authentication Manager implements the chosen policies for identifying and authenticating users on Sun Ray DTUs. The Authentication Manager uses pluggable components called modules to implement various site-selectable authentication policies.
The Authentication Manager also verifies user identities and implements site access policies. It can also be used to supply an audit trail of the actions of users who have been granted administrative privileges over Sun Ray services. The Authentication Manager is not visible to the user.
The interaction between the Authentication Manager and the DTU works as follows:
2. The DTU sends the user's token information to the Authentication Manager and requests access. If a smart card is presented to the DTU, the smart card's type and ID are the token. If not, the DTU's Ethernet address is sent.
3. If the Authentication Manager runs through the entire list of modules and no module takes responsibility for the request, the user is denied.
4. If the user is accepted, the Authentication Manager starts an X Windows session for the user, which takes the user to the login screen. Solaris implementations use the dtlogin screen; Linux implementations use GDM.
Normally, the Sun Ray DTU looks for the AuthSrvr DHCP option and contacts that address. If that field has not been supplied, or if the server does not respond, the DTU sends a broadcast request for any authentication manager on its subnet.
As an alternative, the administrator can supply a list of servers. If the authentication list is specified, only addresses on the list are checked. The Authentication Manager addresses are tried in order until a connection is made.
The site administrator can construct a combination of the different modules and their options to implement a policy tailored to the site's needs.
Any type of token is accepted. Users are automatically passed through to the login window. This module is designed primarily for implementations in which Sun Ray DTUs replace workstations or PCs.
The token is accepted only if the token has been registered in the Sun Ray administration database and the token is enabled. If the token does not meet these conditions, it is rejected. If accepted, the user is passed through to the login window. This module is designed for sites that want to restrict access to only certain users or DTUs.
Users can be registered in two ways, reflecting two possible policy decisions for the administrator:
The administrator assigns smart cards and/or DTUs to authorized users and registers users' tokens in the Sun Ray administration database.
Users register themselves in the Sun Ray administration database. If this mode is enabled and the Authentication Manager is presented with an unregistered token, the user is prompted with a registration window. In this case, the user provides the same information a site administrator would request.
If self-registration is enabled, users can still be registered centrally. If a token has been registered but disabled, the user cannot re-register the token; the user must contact the site administrator to re-enable the token.
A session consists of a group of services controlled by the Session Manager.
The session is associated with a user through an authentication token. A service is any application that can connect directly to the Sun Ray DTU. This can include audio, video, X servers, and device control of the DTU. For example, dtmail is not a service because it is accessed through an X server.
The Session Manager interacts with the Authentication Manager and directs services to the user. The Session Manager is used at start up for services, for managing screen real estate, and as a rendezvous point for the Authentication Manager.
The Session Manager keeps track of sessions and services by mapping services to sessions and binding and unbinding related services to or from a specific DTU. The Session Manager takes authentication only from authorized Authentication Managers listed in the /etc/opt/SUNWut/auth.permit file.
The steps below describe how the process starts and ends:
1. After a user's token is authenticated, the Authentication Manager determines whether a session exists for that token. If a session does not exist, the Authentication Manager asks the Session Manager to create a session and then starts the appropriate service(s) for the session according to the policy decisions taken by the administrator. Creating a session usually involves starting an Xserver process for the session.
2. When services are started, they explicitly join the session by contacting the Session Manager.
3. The Authentication Manager informs the Session Manager that the session associated with the token is to be connected to a specific Sun Ray DTU. The Session Manager then informs each service in the session that it should connect directly to the DTU.
4. The Authentication Manager determines that the session associated with a token should be disconnected from a DTU. The Authentication Manager notifies the Session Manager which, in turn, notifies all the services in the session to disconnect.
5. The Session Manager mediates control of the screen real estate between competing services in a session and notifies the services of changes in screen real estate allocation.
|
Tip - Use xhost username@system to enable only those people you specify to access the display and the user's DTU. |
The Session Manager is consulted only if the state of the session changes or if other services are added. When a user's token is no longer mapped to a DTU (for example, when a card is removed), the Session Manager disconnects the services from the DTU, but the services remain active on the server. For example, programs attached to the X server continue to run although their output is not visible. The Session Manager daemon must continue running all the time.
|
Note - To verify that the Session Manager daemon is running, use the ps command and look for utsessiond. |
If the Authentication Manager quits, the Session Manager disconnects all the sessions it authorized and tells them that they have to be re-authenticated. The services are disconnected but still active. If the Session Manager is disrupted, it restarts automatically. Each service contacts the Session Manager to request reattachment to a particular session.
Sun Ray Server Software has both a command-line interface (CLI) and a graphical user interface for administrative functions. The CLI is the recommended interface for enabling assistive technologies; the Sun Ray Administration Tool (Admin GUI) is provided for convenience.
Sun Ray Server Software 3.1.1 provides a private data store service, the Sun Ray Data Store (SRDS). The SRDS provides group-wide access to SRSS administration data.
In addition to the servers, server software, DTUs, smart cards, and peripheral devices, such as local printers, the Sun Ray system needs a well-designed network, configured in one of several possible ways, including:
Various types of network configuration are discussed in depth in Chapter 8.
Early Sun Ray implementations relied on dedicated interconnects, using physically dedicated Ethernet networks or logically dedicated networks. Sun Rays can now be deployed on existing Local Area Network (LAN) infrastructure, eliminating the requirement for a dedicated interconnect.
The Sun Ray interconnect fabric is based on 10/100BASE-T Ethernet technology, using layer-2 or layer-3 switches and Category 5 wiring. Each Sun Ray DTU is attached to the interconnect fabric through its built-in 10/100BASE-T interface.
The following sections illustrate some conservative methods of providing good desktop performance to Sun Ray users at a low cost. Many other network scenarios are possible.
VLANs logically partition a single physical interconnect into two or more broadcast domains. VLANs are commonly configured to implement virtual subnets in a shared physical interconnect. However, because VLANs must share backplane and link bandwidth, they are not true dedicated interconnects.
Implementing a Sun Ray interconnect through VLANs creates a logically dedicated connection, but can also mean sharing physical resources with uncontrolled, non-Sun Ray traffic. These resources could be the limited backplane bandwidth within a switch or on a link that carries multiple VLANs between switches (see FIGURE 1-3). If these resources are consumed by other devices, significant amounts of Sun Ray DTU traffic might be dropped and the results seen as horizontal bands or blocks on the user's display.
Since switch manufacturers configure their products differently, please refer to the documentation provided with your switch and refer all questions relating to setting up or configuring VLANs to your switch manufacturer.
Implementing the interconnect with a physically dedicated and isolated set of Ethernet switches was recommended because it is easy and reliable. For instance:
With Sun Rays deployed on a LAN, users can exercise session mobility across a much larger "domain"--a huge convenience. For basic instructions on configuring different types of networks for Sun Ray implementation, see Basic Network Topology of the Sun Ray Server Software 3.1.1 Installation and Configuration Guide. For a more detailed discussion of network taxonomy and configuration, see Deployment on Shared Networks.
The physical connection between the Sun Ray server and Sun Ray clients relies on standard switched Ethernet technology.
To boost the power of the interconnect and shield Sun Ray DTU users from the network interaction taking place at every display update, 100 Mbps switches are preferred.
There are two basic types of 100 Mbps switches:
Either type of switch can be used in the interconnect. They can be managed or unmanaged; however, some managed switches may require basic configuration to be used on a Sun Ray network.
Server-to-switch bandwidth should be scaled based on end-user multiplexing needs so that the server-to-switch link does not become overly saturated. Gigabit uplink ports on the switch provide high-bandwidth connections from the server, thus increasing the number of supportable clients. The distance between the server and the switch can also be extended using gigabit fiber-optic cabling.
The interconnect may be completely dedicated and private, or a VLAN, or it may be part of the corporate LAN. For private interconnects, the Sun Ray server uses at least two network interfaces: one for the corporate LAN, the other for the Sun Ray interconnect.
Even in a LAN deployment, two server network interfaces are recommended: one to connect to the general LAN and one to connect the server to back-end services, such as file servers, compute grids, and large databases.
There is no physical or logical limit to the ways that a Sun Ray system can be configured. The following sections offer some typical examples.
For smaller deployments, such as those with between five and 50 Sun Ray DTUs, the Sun Ray server uses a single 100BASE-T card to connect to a 100BASE-T switch. This switch, in turn, connects to the Sun Ray DTUs. With five or fewer DTUs, a wireless interconnect works acceptably at 10 Mbytes.
For example, in FIGURE 1-2 a Sun Enterprise server with a Sun 10/100BASE-T card and a 24-port 10/100BASE-T switch can easily support 23 users performing standard desktop activities.
For larger departments with groups consisting of hundreds or thousands of Sun Ray DTUs, the Sun Ray server uses a gigabit Ethernet card to connect to large 10/100BASE-T switches. Especially with the low-bandwidth enhancements to SRSS, there is no performance need to have more than one gigabit link from the server to the Sun Ray DTU's network.
A 100-user departmental system, for example, consisting of a Sun Enterprise server, one gigabit Ethernet card, and two large (48-port and 80-port) 10/100BASE-T switches delivers services to the 100 Sun Ray DTUs (see FIGURE 1-4).
Sun Ray servers can be bound together to create failover groups. A failover group, comprising two or more servers, provides users with a higher level of availability in case one servers become unavailable due to a network or system failure.
When a server in a failover group goes down, whether for maintenance, a power outage, or any other reason, each Sun Ray DTU connected to it reconnects to another server in the failover group. The DTU connects to a previously existing session for the current token, if there is one, on another server; if there is no existing session, the DTU connects to a server selected by the load balancing algorithm. This server presents a login screen to the user, who must log in again to create a new session. The session on the failed server is lost. Failover groups are discussed in Chapter 10 as well as in the Sun Ray Server Software 3.1.1 Installation and Configuration Guide.
In addition, enterprises with multiple failover groups and users who move from one location to another -- such as between corporate headquarters and various branch offices -- may wish to configure regional hotdesking. This feature allows users to access their sessions across a wider domain and longer distance than simply using different DTUs within a single failover group.
Using switched network gear for the last link to the DTUs makes it hard for a malicious PC user or network snooper at one of the network ports to obtain unauthorized information. Because switches send packets only to the proper output port, a snooper plugged into another port receives no unauthorized data. If the server and wiring closet are secure, the last step is switched, and the DTU is plugged directly into the wall jack, then it is very difficult to intercept communications between the server and the DTU. SRSS encryption features also help to protect sensitive data by providing the options to encode keyboard input and display traffic.
| SRSS 3.1.1 Administrator's Guide for Linux | 819-6686 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.
