Sun Ray Primer - Part 1
By KlausR on Aug 23, 2011
Before we start to dive into the details of the VDI architecture, it is necessary to get an understanding of the object and computing model behind this, so that we all use and understand the same terminology. Thus I decided to post a series of articles that deal with the fundamentals starting first with an overview of the Sun Ray architecture. Readers that already have a decent understanding of the Sun Ray architecture can naturally skip this part. It just covers what I consider the Sun Ray basics.
Naturally, there is an official Sun Ray documentation out there, but I personally prefer to read through a one-pager overview first, before looking into the product details. So here we go with a brief overview of the Sun Ray architecture that introduces the essentials that we will later refer to when talking about VDI.
The Sun Ray system provides customers with an interoperable desktop computing solution that reduces the maintenance, upgrade, and operational costs associated with most PC-based fat client environments. The system employs a network-dependent model in which thin clients, called Sun Ray Desktop Units (DTUs) or more generic Sun Ray Clients, connect to Sun Ray servers. All desktop applications, such as office productivity suites, Web browsers, and the desktop itself, are executed on the servers, while the DTUs simply act as frame buffers, displaying the desktop and forwarding user input to the servers. Sun Ray clients use a special protocol, called Appliance Link Protocol (ALP), to talk to the servers. The protocol is optimized regarding network bandwith usage and provides a reasonable user experience even on WAN connections with high latencies.
Sun Ray DTUs have no local disks or locally installed applications or operating systems and are therefore considered stateless. This makes them easy to exchange, inexpensive to maintain, and extremely secure. Various models of Sun Ray DTUs are available, differing primarily with respect to size, type, and supported resolution of the connected (or integrated) monitor. A software version of a Sun Ray client, called Oracle Virtual Desktop Client (OVDC), is also available. An Oracle virtual desktop client runs on an ordinary PC or laptop computer and provides a Sun Ray session in a desktop window. Recently we also added an OVDC iPad version.
Nearly any server with sufficient capacity can be configured as Sun Ray server so long as it runs a supported version of the Solaris operating system or one of the supported flavors of Linux (such as Oracle Linux). To ensure uninterrupted service, several Sun Ray servers can be configured as a failover group, so that whenever a server goes down, the affected Sun Ray clients automatically re-connect to the next available Sun Ray server in the failover group. A load balancing algorithm ensures that the client connections are equally distributed among the remaining servers, taking into account the current load and capacity of each server. It is important to understand that this model does not include any automatic transfer of a running desktop session to a different server. Any user data or session state that has not been saved will be lost if the original server becomes unavailable. The Sun Ray failover group model ensures high availability in the sense that a user can immediately start a new desktop session (on a different server) without any further outages.
A failover group consists of a primary server and one or more secondary servers. Servers in a group authenticate (or learn to trust) one another by using a common group signature, a key used to sign messages sent between servers in the group. Each Sun Ray server hosts its own local Sun Ray data store used for retrieving/storing data about the Sun Ray clients, tokens (see below), etc. However, only read access is permitted on the local data stores. Any data changes (write access) are first written on the primary server and later replicated on the secondary servers' Sun Ray data stores. If the primary server goes down, then it is no longer possible to store any data changes. However, this just affects a very limited part of the Sun Ray functionality as the vast majority of operations will just require datastore read access. Thus the Sun Ray system stays functional, regardless if a primary server or any secondary server is down.
As the Sun Ray server software is only available for Solaris and Linux a desktop session per default means a Gnome desktop (or more generic Xserver session) with corresponding Unix applications (web browser, office suite, etc.) all executed on the Sun Ray server. The Sun Ray architecture uses tokens to associate a desktop session with a user. A token is just a string that consists of a token type and an identifier. Typically, the token is presented on a smart card that the user inserts into the DTU's card reader. In this case the card's type and identifier are used as the token (for example mondex.9998007668077709). If the user is not using a smart card, the token type "pseudo" and the DTU's identifier (MAC address) are supplied as the token (for example pseudo.080020861234).
Desktop sessions can be in connected or disconnected state. If a user removes the smart card, then the session becomes disconnected. Such sessions (and all corresponding applications) are still executed on a Sun Ray server but are not connected to any Sun Ray client and, consequently, are not displayed anywhere. However, a user can reconnect to a disconnected session, for example by inserting a smart card containing the appropriate token into the card reader of any Sun Ray client on the network. If a session associated with the presented token is already running on a different Sun Ray server, the client is automatically redirected to that server, and the user's most recent session is displayed (the session becomes connected again). While the session continues to reside on the server, it appears to follow the user from one Sun Ray client to another. This functionality, called hotdesking or session mobility, enables users to access their sessions from different locations using different Sun Ray clients.
What is next?
As stated this was a very brief high-level overview of the Sun Ray architecture and how it is used to serve Unix-based desktops. However, most end-users actually want a Windows desktop and typically do not want to get in touch with any different operating system. Thus part 2 of this article series will explain how to connect Sun Ray clients with the Windows world. Stay tuned for more and please be patient. We just entered the water and more complex stuff will come - I promise ;-)