Random thoughts

I was asked to help out at the LISA conference that was held last week in Baltimore, MD.  I won't waste your time with the subjects that I was asked to present - though I may follow up with an interesting demonstration that we put together.  No, the highlight for Sun Ray was saving a fat client from near collapse on the exhibition floor. One of the demonstrators in the Sun booth was planning to showcase the amazing analytics of our open storage platform using a VPN connected laptop. Basically, the plan was to VPN in to Sun where he could then connect via RDP to a demonstration system up and running in a lab.  The problem with the plan was that the network inside and from the hotel was absolutely horrible.

So, what do you do when you are relying on the network for the lion's share of your demonstration and it is an absolutely dog?  Remove the fat client from the picture and insert a 100% network based computer?  Well, that is just what we did.  We replaced the high end laptop with a Sun Ray 270.  From there we leveraged the VPN capabilities of the device to connect back in to Sun. Once connected, we launched the Windows Connector to his demonstration machine and .... presto, the demo was a success.  The performance of the Sun Ray device was head and shoulders above the week performance turned in by the VPN connected laptop due to the use of the ALP protocol. The adaptive nature of the protocol proved its worth adjusting to congestion on the network and delivering a snappy desktop experience.

While there may be posts from other bloggers on the topic, the question of 'What is a thin client?' continues to confuse many and as such I feel compelled to document a few points on the topic.  The confusion comes because of the marketing done by all who wish to participate in the space - Sun included.  Where do you draw the line on 'Thin client' definitions? Physical footprint? Price? Power draw? Capability at the device?  Each person and organization needs to draw their own line and stay true to that definition.

To me, thin client computing is about operational state, security, management, provisioning and user experience.  To that end - I prefer to use the term Ultra-thin client computing so that I can be very clear on what the expectations are. In most thin-client discussions - the technology players in the area have sufficiently muddied the waters so they can cram in that one capability that no other vendor can deliver - but they stay 'true' to their definition. This is misleading at a minimum.

So a few questions to ponder:

• Does a thin client device have resident storage? If so, how much?


• Does a thin client device cache any data or application state on the end user device?


• If you remove the proposed delivery experience from the architecture - can the device stand on its own and deliver to some other purpose?


• Can the device be used for a purpose outside of the organizations intentions?


• If the device is thin - why are there so many different versions of the same device?
  

To me, if any of the above questions are answered YES - then how thin is the device/model? The last bullet is only present to consider if the answer is other than form factor related.

A stripped down PC can be considered a thin client device because it boots an embedded OS, or over a network, and then communicates with a dedicated server/service (VMware, Citrix, Windows Terminal Services). Is this a thin-client? To some it is - to me, its just a stripped down PC running an application to access a service running at a different location. Is this any different than running a full blown operating system on a PC and using a browser to access a well known search engine to gain access to information? No - it is the same basic architecture. Organizations need clear definitions as to what thin client computing is.

So, is a laptop computer a thin-client? Not in my book. What about a netbook? Nope. If you remove a laptop or netbook from the list of thin-client devices - why did you remove them and using that same criteria - what else should be removed? Running a stateful operating system on the device? Then you need to remove all XP or Linux based thin clients from Wyse, IBM, Chip PC, HP ... . Booting from FLASH RAM? Same list of thin clients to be removed.

As long as you have a stateful device as the access point - you are never as thin, or secure, as you could be with a stateless device. So - define for yourself - What is thin client computing?

I was recently asked to assist in testing the overall scalability of a customer deployment. Of concern was the ability to support the full number of users, concurrently, while running a demonstrative user environment. We already showed the customer that the Sun Ray session servers were dutifully supporting the entire load as all DTU's had been working without fail for some time.

The basic environment consisted of over 1000 DTU's throughout the campus connected back through a series of session servers. Each session server is running a simple kiosk script that presents the users with a menu of user environments to connect to. For this specific example there are two environments; 1) select a Citrix environment using the ICA client to an existing Citrix farm. 2) select a connection to a new Windows Terminal services farm (Windows 2003 64-bit). Since the selection screen works for all DTU's and there have been zero concerns raised on the Citrix farm - they need for us to prove/test that all users can connect to the WTS farm with reasonable performance.

After explaining to the customer that we can do this - but they will need to offline all of their users for the test since we need all DTU's if we are to test the entire system, I embarked on a plan to automate the process. Craig Bender had already done a good bit of the work for me with his work on scalability, and he sent me a pointer to the Auto-It software that would be needed.

I have to say that, again, the easiest part of this equation was to build the kiosk script. Before any comments about my scripting capabilities comes in to play - this was a quick (5 minute) exercise and is light weight enough that I did not care too much about elegance or optimization. The script is here:

#!/bin/csh
set path = (/opt/SUNWuttsc/bin $path)
 if ( ${SUN_SUNRAY_TOKEN} =="" ) then
         exit
 else
     set line=`grep ${USER} /opt/LTE/config`
     set host=`echo ${line}|cut -f3 -d "|"`
     set pass=`echo ${line}|cut -f2 -d "|"`
     set cmd_l=`echo ${line}|cut -f4 -d "|"`
     echo ${pass} | uttsc -m -A 24 -r sound:high -u ${user} -i -a \"c:\\temp\\${cmd_l}.exe\" ${host}
 if ( ${host} == ""blogs.sun.com/images/smileys/wink.gif" class="smiley" alt=";)" title=";)" /> then
        zenity --info --text "This device is not part of the current load test."
 endif
 exit

Yes, there is a big security hole in the middle of the script - an expect script should have been used so the password is not in the clear. However, this is a closed environment and the test was for scale not implementation. The /opt/LTE/config file is a rather simple method to pass in exactly what is desired of each kiosk user and is here for an example:

utku0|Sunray123|192.168.1.248|test1
utku1|Sunray123|192.168.1.247|test2
utku2|Sunray123|192.168.1.249|test3
utku3|Sunray123|192.168.1.248|test4
utku4|Sunray123|192.168.1.247|test5
utku5|Sunray123|192.168.1.249|test1
utku6|Sunray123|192.168.1.247|test2
utku7|Sunray123|192.168.1.248|test3
utku8|Sunray123|192.168.1.249|test4
utku9|Sunray123|192.168.1.248|test5

The file is actually much longer than this - there is an entry for all 1000+ kiosk users. In the file you can see that not only are the users running different tests (thanks again Craig) but I am also able to send different users to different Windows servers. Ideally, this would all be done via some load balancing algorithm or at least a round robin DNS approach. I explicitly called out for the specific server IP address to 1) remove any DNS configuration errors from the mix and 2) force my own balancing of the load as there are at least 3 different hardwire types in the back end Windows farm.

Where this approach is interesting to me is that we can easily run multiple sized tests on the Windows farm while still pushing the session servers for all DTU's. The check for if host="" will fire off the subsequent zenity command if the kiosk user is not one of the users destined for the current test.

Now, try this with a Wyse, Dell or HP 'thin-client' environment. In a matter a few minutes, I changed from production to load test without ever touching a single end user device, without altering anything on the end user device, scripted the entire load with no user involvement and can place it back in to production with three simple mouse clicks. Ultra-thin client is the only way to go for near zero administrative burden.

Today, Sun will release the latest VDI software (in early access). You can pull it from here. I have been working with the software for the past week and have to say that 'I like it'. Instead of building a new VDI platform to compete with itself and others - the folks in engineering took a new approach. There is a VDI tier that you plug in your virtualization platform. Yes, the same VDI kit will work with VMware, as well as xVM VirtualBox. New desktop providers can be created to plug in to the same framework.

 Enough on the marketing - what I found intriguing about the way the product comes together is how everything is just integrated. When delivering VDI services there are a number of things you need to consider for the enterprise - among the top items are: where is the back-end storage for the VM's, how will you identify the user and provision the VM on their behalf, which VDI product should you use, what if we need to change mid-stream, what OS experience does the user need, can I change that experience on a per user basis.... Yes, these are leading questions but they are ones that have been easily addressed with VDI3 EA2.  Provisioning for Windows XP, Windows Vista, Solaris, Any flavor of Linux .... in fact any user environment that will run in xVM VirtualBox is fair game. Support for ActiveDirectory as the identity source (or native LDAP) works out of the box with a click of the mouse. Placing your user environments in NAT'ed environments works ....

In my small lab environment I stood up a V20z as my VDI broker (delivering user environments to any platform that a user connected from - Sun Ray or traditional PC). I built up a x4500 as my storage server running OpenSolaris - the user interface to VDI3 EA2 - connected directly via iSCSI. I then placed my previously used x4600 in as a Desktop Provider running xVM VirtualBox. The result....

 In about 4 hours of real work time - I had the 'system' delivering cloned images to named users. Yes, I connected to the office LDAP server and connected users to VM's with just a button click. I started the cloning using the import desktop feature of the system. I grabbed a VDI file from my laptop and used it as the template for all the work - leveraging absolutely everything I had already done.

There is still a little work to be done - but download the software and see where virtualization of the desktop is headed. Screen shots and diagrams to follow.

Windows 2008 and Hyper-V do not officially support Solaris. In fact, the only non-windows platform supported is SuSE Linux. Being a huge fan of Solaris and also a strong believer in Sun Ray, I had to take on the challenge and see what works and doesn't work. The first challenge was finding the right platform to build on - I have since done what follows on a x6250 blade as well as a x4150 1RU server. The folks at Microsoft were kind enough to provide me  released version of Windows 2008 (x64) and the install was fairly smooth. 

After the install, it was on to the Hyper-V configuration. For starters - it is not there by default. You need to add the role to the server for Hyper-V, and then the reboot. Since I am doing this for a demonstration and need to insure minimum configuration headaches I decided to forego the warning about saving a management network and just used a single (NIC0) network for both the server and the Hyper-V service.  I also decided that I should start with a supported platform prior to branching out into uncharted territories. I loaded a copy of XP (sp3) as my first guest OS with little problems. During the install and subsequent reboots I figured there were bound to be problems down the road so I started using the tools that came with the system. Hyper-V does a very nice job (user interface) of providing some of the core utilities that are critical to this type of environment. Snapshots and exported existing VM's ended up saving me a bunch of time. More on that later.

Now that I had a guest OS that was functioning and capable of talking on the network it was time to roll up the sleeves and get .... 'bloody'. There have been reports of installing OpenSolaris on Hyper-V so I tried it. Sure enough I was able to get it working with little effort. There are also directions on running Sun Ray on OpenSolaris - I have done that too. I wanted to keep this as close to supportable has possible so I decided to stick with Solaris 10 and Sun Ray software that are both available directly from Sun ... with no caveats.

The initial install of Solaris went surprisingly well. No hang ups, the network worked and the install was relatively clean. After the installation reboot - it all changed.  Yes, it boot clean and all appeared to be working well (however the mouse activation to the VM was a bit annoying) given I was in unchartered territory. However, I had no network (Microsoft's live.com to the rescue). While I did not find a clear solution I was able to figure out that the dnet (Decnet 21114) driver did not exist for the 64-bit OS. Reboot into 32-bit mode and the network is found. More to come on network challenges.

The installation of the Sun Ray software also worked (flawlessly) through utinstall, reboot, utconfig, utadm, utrestart. All worked well. So, I connected a Sun Ray 270 to the network and ..... nothing! Absolutely nothing on the wire. All I was trying to see was a login screen, but that was asking too much.

Since Sun Ray is a 100% network play I did what any other engineer would do - jumped in to the network. Ping the broadcast - nothing! Ping localhost - success! Ping the Hyper-V box - nothing! Ping the router - nothing! Hmmmm! Snoop the network while pinging the broadcast ---- data and a successful ping. More testing along this line found that while the dnet interface was up and running, unless snoop was running there was no data being passed. Snoop is a little too much overhead for my liking so I was concerned that I was not going to be able to make it work.

My good friend, Jim Fiori, took a look and in no time gave me a 'snoop light' binary to try. Sure enough it worked with less overhead. Yes, the network is still a bit slow as the binary causes the packets to travel all the way up to the STREAMS module but with no work but with no work being done on the actual packet .... overall a good effort. I placed a start up script in place to run the binary, reboot and the Sun Ray's were working.

From here, I took a quick snapshot of the Solaris VM and also exported it so that I could move it around later if needed.  The rest of the work was somewhat downhill. Exported XP VM's were simply imported as new VM's to build a small stash of available images. Kiosk mode was enabled on the Sun Ray session server (Solaris VM) and I wrote a small wrapper that modified my previous post to deliver a customized desktop based on which user plugged in their smart card.

In the end, well worth the time spent to understand what works and doesn't. The x4150 used is now headed to the Microsoft facility in Reston, VA for their demonstration showcase. I will try to post pictures once it is installed.

My management outfitted me with a shiny new MacBook Pro (dual core Intel) some time ago. It is my primary virtualization playground - VMware Fusion and VirtualBox and demonstration system. I have commented before about demonstrations (Sun Ray showcasing Windows, Linux, Solaris and Trusted Extensions) that I do from the Mac. BTW, if you try to run all of these at once you will need to upgrade the memory to 4GB.

While all of this worked well for me, it just didn't have the pop that I wanted. It may have been the hypervisor and its ability to scale or it may have been the underlying scheduler (MacOS). While not trashing Mac I did figure that I should be relying on a scheduler that I understood and could manipulate using my native OS (Solaris).  

I had loaded OpenSolaris within a VM several times and was impressed with some of the new features that our webites will be bringing to peoples attention (timeslider, IPS, ZFS boot ...) but the performance was a concern. So, the next best step was to load it on bare metal and see how it works. My trusty Macbook was the only 'gear' I had that I could take on the road with me. How hard could it be?

I did not follow the directions here verbatim but anyone wanting to replicate should have little problem following them. Brian Leonard did a great job with pictures and steps to take.

My laptop is now running OpenSolaris 2008.11 and I am in the process of installing all my old demo's on it as I type this. So far VirtualBox seems to run a bit quicker and I no longer have any wasted OS cycles. That is, I do not need a VM just for Solaris to do my Sun Ray work - I just run it native.

All-in-all, not a bad investment of 2 hours this morning.

In my haste I failed to connect my previous post to any conclusion, recommendation or otherwise opinion that could be made from it. I was simply putting something out there and..... well, I forgot to close the loop. The story in the post was about USB devices being connected to computers that quite honestly - they should never have been connected to. That simple statement is incredibly hard to implement across hundreds of thousands of personal computers.  However, if you adopt a centralized management philosophy and deploy truly stateless devices in the user space - you can implement this quite easily.

Yes, I am plugging a Sun product - Sun Ray, but that product is what makes simplification of security possible. With centralized management - the enterprise simply chooses to not allow USB devices to be accessed. The product/technology enforces that decision for you. Is Sun Ray the right solution for every single desktop - absolutely not. That being said, securing the 80% of the desktop computer population that it is appropriate for could be a whole lot easier. Once you know you have that piece secured - you can spend the rest of your time worrying about the 20% that are special cases.

Every few months a story about data loss, compromised laptop computers or some other security issue seems to pop up. To date, almost all of the stories I have seen could have been avoided through the use of truly thin client devices. I am not talking about stripped down PC's that in the end most users end up building back up to where they were before. A commentary on that subject will be posted on another day.

Today, the latest in security threats through the use of personal computers for enterprise use. Unfortunately, this story is not about enterprise computing - it is about mission computing. Take a read here to see what I am talking about.

If you take a look at Interesting combination and Interesting combination II you see that I have been experimenting a bit with VirtualBox. While my day job has me focusing on Sun Ray and different and interesting ways to use the technology, I am a technologist - by nature. What better way to explore than to start with something you know and then expand that to an area you have interest in going? The previous posts show how I scripted an approach to rapidly provisioning compute environments. Taking that as a baseline, I have looked at working on the next problem.

Distributed computing (buzzword CLOUD) is an interesting topic, but one that is not accessible unless you have a budget for hardware, networking, space to stand up a rack (or 10) of hardware and an endless supply of power to run it. And in a time/place where we are constantly trying to do more with less (time) - building a datacenter to experiment is really hard to justify. So, what can I do to simplify the approach since I am really just interested in experimentation - not trying to build an enterprise grade solution? 

VirtualBox allows me different types of network interfaces (NAT, internal, host interface) and then connect them to the physical network interfaces of the platform. This allows me to run my entire 'Cloud' inside the box and allow interfaces to be exposed to allow requests to enter from the outside. This is not unlike a traditional network with firewalls put in place to restrict where a request may go. I can actually shape the request as it goes through the system .... without investing in the larger infrastructure before I prove out the scenario.

My first and very simple test was to stand up a web server in one VM, an application server in a second VM, a database in a third VM and a NAS service in the fourth. Zero aquisition dollars (I already have the server sitting there) and a few hours at night and it ...... just works.  The web server has one host based network interface and a second internal only interface. The application server has two internal network interfaces (different networks for access to database and web server) and is unreachable without first connecting and directing through the web server. Likewise for the database server. The NAS service has access to all internal networks and serves as the data repository for all backend systems using ZFS.

 I can now stand up an entire stack in a matter of minutes without incurring additional costs. While not a technical term - it is an accurate summary ' COOL!'

So, I finally got back to testing a few more aspects of my last post.  My goal was to use the example from the post but to change the destination OS. I stood up an image using an operating system that I knew was not formally supported by the Sun Ray software. Specifically, I continue to run in to customers that ask for those edge case solutions that Sun simply can not stand behind. More on that later.

I installed Red Hat Enterprise 5.2 in a single VM and followed the same approach I did for the Windows approach (cloning, specific port for RDP service...) and it worked. This was not a big surprise as the approach abstracts the OS from the user, the hardware and now the delivery mechanism.  

I now have the same x4600 server running a combination of Windows XP, Windows Vista, multiple versions of Linux and of course Solaris. Why? Quite simple - I can now deliver full screen <insert your OS experience here> desktop to an ultra-thin client that is 100% controlled from the enterprise service. Maintaining the advantages that the ultra-thin client model provides for while increasing the ability to deliver custom desktops.

Back to why Sun can't support all of the different permutations of OS' with the Sun Ray software. Quite simply, the Sun Ray session server is a service delivery platform. That service relies on the interfaces that are well known on the host platform (hardware and software). As the Linux distributions each have their own little quirks and differences the test matrix for building to each of them simply overwhelms the test matrix. So, Sun stands behind well documented, supportable distributions and continues to innovate where value can be added. Given the approach above - which user experience can not be delivered?