Jumping VDI

After introducing the general architecture I do the same exercise again, but with way more focus on the individual parts. Again, we look at the architecture diagram from right to left, with the initial focus on the client access.

Okay, the fact that Sun Ray units can connect to the Sun VDI stack is not brand new. This was also part of Sun VDI 2, if you did configure Sun Ray Server Software (SRSS) for the use with the Virtual Desktop Connector (VDC). The only difference is, that the remote protocol ALP is now built into the solution by default. Each Sun VDI 3 installation will have this ability out-of-the-box.

The really new part is, that Sun VDI 3 mimics also to be Terminal Services (RDP server) by exporting standard RDP to external RDP clients such as Windows Remote Connection or Sun Secure Global Desktop (SGD). Note, you could even redirect RDP traffic to an external Sun Ray Server.

This is done by implementing RDP redirection at the session broker level. Incoming RDP requests will be resolved by a lookup of the user's virtual desktop based on the given user ID as part of the initial RDP request. The lookup will find the user's last used desktop or his default desktop, will startup the desktop if necessary, and will redirect the RDP traffic to the virtual desktop.

How the redirection is done depends on two facts. If xVM VirtualBox is used as the hypervisor, by default the RDP traffic will be directed to the RDP server sitting on top of the VirtualBox host, that executes the user's desktop. The RDP server will render which ever desktop the user has access to, independent of the guest OS. But it is also possible to use the VM's built-in RDP server. This is useful if multimedia accelerations are important. For VMware ESX there is only the option to use the guest inbuilt RDP server. The remote access is limited to Windows XP or Windows Vista.

The approach of RDP redirection has various advantages:

1. Within a LAN environment there is no additional infrastructure needed to access a remote desktop. Each PC or even thin clients other than Sun Ray can access a virtual desktop, which could even be running a Linux or Solaris Guest OS.
2. SGD is completely decoupled from the Sun VDI architecture. This means SGD sees Sun VDI just as yet another Windows Terminal Server. This makes the configuration very simple and straightforward. And it also removes any product dependencies away.
3. RDP Redirection will work with RDP loadbalancers. This has the direct advantage of removing a single point of failure in the architecture. RDP traffic to multiple VDI nodes can be balanced.
4. RDP traffic doesn't put any load on the VDI node. It is completely handled by the third tier and makes sizing very predictable for the RDP client access case.

-Dirk

« previous | next »

When talking about Sun VDI 3, we talk about something completely new designed for better scalability and manageability, built on a complete Sun stack. Of course, customers will also be able to select VMware as their preferred virtualization layer. Below you find the architecture overview of the Sun VDI 3 product.

Generally speaking, the model hasn't changed since Sun VDI 2.0. But the components therein have. From right to left you see the three tiers involved. On the right hand side are the clients. These can be either clients that use the Sun Ray protocol ALP or, and this is new, RDP clients, such as the Windows Remote Connection or Sun Secure Global Desktop.

In the middle you find the Sun VDI building block, which is the desktop broker with embedded Sun Ray Server Software plus the Sun Ray Windows Connector. Altogether they build the session broker that connects users and their client devices with the virtualization tier running the user's desktops. The management of desktops for users incorporates access to a user directory such as Active Directory or LDAP.

And finally you find the virtualization tier on the left hand side. Either VMware Virtual Infrastructure or Sun xVM VirtualBox are the engines for the user desktops. The architecture around VMware Infrastructure access hasn't change significantly. For VirtualBox we came up with a completely different design leveraging Sun's core storage assets based on ZFS. ZFS is the interface to do the storage management meaning managing the virtual disks, while iSCSI is the access protocol to virtual disks. The visualization is handled through RDP. For the VirtualBox backend we use the inbuilt RDP server, that allows us to display any hosted desktop, including Linux or Solaris.

Further blog entries will detail the architecture and the used technologies. Differences in comparison to the Sun VDI 2.0 architecture will also be highlighted.

- Dirk

« previous | next »