What a busy few weeks, Citrix Synergy already feels like a distant memory. We had a great trip and were dumbfounded by the interest and excitement shown by enthusiasts, customers and vendors around our ThinIO solution, with quite a few people insisting on seeing the inner mechanics and trying to break our demo’s to ensure the figures they saw were legit!
For those unfortunate enough to miss synergy or our Webinar with Erik over at XenAppBlog, here’s a little blog post you will find interesting as I walk you through the inners of ThinIO and why it’s so simple to deliver disk access with RAM speeds without any of the complexity.
What is ThinIO?
ThinIO is a filter driver which operates at a block level, inline between the windows and the disk.
ThinIO sits in the operating system layer and can be used on windows desktop operating systems or server based computing models.
ThinIO delivers a greatly reduced IO footprint on your storage, while also speeding up core items like boot times and login times. ThinIO also helps standardize the peaks your storage will get hit by at busy periods during the day. Ultimately this allows you to size your storage for an average, as opposed to sizing for the worst case scenario during peaks.
How does it work?
When ThinIO starts up, it allocates a configurable cache of reserved RAM to perform its optimisations.
Being the last filter in the stack, ThinIO can still allow windows to perform it’s own optimisation on IO, delivering value by catching the read and write IO’s just as they hit the disk.
ThinIO interacts with block data as read’s and writes traverse the cache. As a read is observed it is retrieved from disk and subsequently stored for future use, meaning any subsequent read will be served directly from cache.
But read’s a boring, and everyone has a solution for read caching. ThinIO also treats this RAM cache as a storage area for write IO. Write IO is committed nearly instantly to the cache and no IO is sent down to the disk while free space is available in the cache.
“But what about if the machines run out of RAM?”
Well I’m glad you asked! The cache in ThinIO is hard set at a value you configure, so RAM will never be taken from the cache to service other processes. But in the situation where the cache has become 100% volatile write, ThinIO will then begin to spill over to the local disk allowing the Virtual Machine continue to operate.
There’s more, ThinIO actively manages cache contents to ensure it’s as relevant as possible. As the cache begins to fill, ThinIO’s Lazy Page Writer can identify and flush out blocks that have not been frequently used. This allows you to use a relatively small cache size while still deliver the big numbers we’ll discuss later.
Designed to be fool proof:
ThinIO’s GUI is fool proof, it’s intuitive and gives you a really quick view of ThinIO Realtime. ThinIO provides graphical representations of stats on reads, writes and cache usage, as well as an immediate view of the benefit ThinIO has created for the desktop.
The ThinIO console can also remotely connect to machines to ensure you don’t have to disturb the user while checking performance.
When the cache is enabled, ThinIO also has a realtime statistics window to help you identify disk patterns and cache performance
Boot and application launch time optimization:
ThinIO has some really clever technology built in to optimise the windows boot process and user experience.
During early testing, we observed just how inefficiently windows uses its disk resources during the boot process. Regularly the same files are requested over and over again on boot, if these blocks are non-contiguous, seek times are inherent. Busy servers were requesting up to 80,000 read IOPS during boot and process start.
ThinIO’s Read Ahead feature allows you to teach windows to be less of a storage monster. As the ThinIO cache is already aware of all blocks needed to boot, or even serve the users first launch of their applications, Read Ahead allows you to boot the machine, with a preloaded cache of required blocks, sorted contiguously.
When ThinIO starts up, it identifies the ‘Read Ahead’ configuration file and pauses windows while it reads the required blocks once, in a contiguous pattern around the disk. Once finished, windows continues to boot retrieving the majority of its block data directly from cache.
By doing this, ThinIO was delivering roughly 30% improved boot times while also reducing boot IOPS by over 80% in our testing. In the below graphs, we did a side by side comparison of the windows start-up process with and without ThinIO.
In the Gui below you will see a machine with the ThinIO cache enabled but no read ahead configured, we achieve a good 40% reduction of IOPS on boot and login, which is not bad on it’s own, but we knew we could make it better:
So after configuring a ‘Read Ahead’ configuration by booting a machine, logging in, opening the core set of applications and committing the file we see the following, large improvement of IOPS saving and cache hit rate on read:
So there you have it. By taking an additional 3-4 minutes with your golden image, you reduce nearly 30,000 IOPS to roughly 5,000 IOPS while also reducing boot times. Not only have you taken alot of pressure off your storage, if you launched your users applications core files as part of the read ahead configuration, your user’s login speeds will receive a really good boost while making their application launch times near instant.
Once the read ahead is complete, the driver will then start to use the data which is no longer needed for more chatty blocks of read or write, so configuring read ahead has zero impact on cache usage in the longer term.
Deploy, size, done.
Out of box, ThinIO takes less than 5 minutes to install and configure delivering you immediate benefits. No hoping, trusting or praying the hardware vendor’s figures are correct. No SAN or LUN type requirement, no hardware lead time, no hypervisor requirements and no change needed to your architecture. Whether you are doing on premises or even cloud SaaS / DaaS, ThinIO installs without any change.
ThinIO will ship with a 30 day grace period for you to test to your heart’s content without any commitment. If ThinIO is not for you, it’s just a matter of uninstalling it! Keeping in the spirit of the community, ThinIO will even have a free version available!
Ultimately, designing and deploying virtual desktops is difficult, we really wanted to write a product that both delivers and is simple and easy to deploy. We feel we’ve absolutely hit the mark on this and we look forward to opening the program to full deployment in the coming weeks.
Sounds great, how do I learn more?
Head on over to the ThinScale Technology web page and read more or register for the private beta.
That was an AWESOME day! well worth the early flight and late flight in one day.
I had the pleasure and privilege to present a session on Thin Clients, debunking the myth’s associated and also talking about the industry as a whole with none other than the rockstar that is Shawn Bass.
In our session, as two consultants in the virtual desktop industry who have spent quite a bit of time in the trenches with Thin Clients recently, we tried to document some of the myth’s, falsities and pitfalls related to choosing and deploying the correct thin client.
Below you will find a link to the slide deck and the rough flow chart I made to consider using as a template and further building upon, particularly when your customers (or sales people) decide to try to implement Thin Clients. This flow chart is not gospel and you will note the reoccurring theme throughout the presentation is as follows:
- There is no nirvana device.
- Agree and commit to the dependencies up front before even considering a model / operating system.
- Don’t treat the decision of what client to deploy lightly.
- Don’t trust everything you have heard.
- Watch out for the typical pitfalls that have burned us or our customers before.
Thank you very much to BriForum, Shawn and TechTarget for an awesome day. I will definitely be attending and recommending BriForum in future to both customers and consultants.
Well we’ve been busy! Very, very busy. In the next week you will see the culmination of two years work on a product we’re about to release called ThinIO.
Cast your mind back if you will to some ramblings and napkin math I devised some time ago in my series on IOPS negation strategies:
In these post’s a bunch of community guys ( Barry Schiffer, Iain Brighton, Ingmar Verheij, Kees Baggerman, Remko Weijnen and Simon Pettit) devised a cunning plan during E2EVC to see if we could counter the monotony of IOPS and their devastating impact on Virtual Desktop implementations. We threw together a loose test scenario where we could demonstrate how technology from Microsofts Windows Embedded Standard functionality EWF (Extended Write Filter) and Citrix’s XenServer intellicache with explosive performance and IO reduction statistics.
This blog series got way more attention than we possibly hoped and judging by citrix’s response by adding ram caching and disk overflow in Citrix provisioning services… we were definitely listened to. At the end of the series, I elluded to a technology that could be leveraged to achieve some of this, while right, it has taken along time to get right! With the help of our newest collaborator David Coombes, this technology is very much alive and ready for use.
Here’s the kicker:
Next week at Citrix Synergy, we’re dropping some big news for this market, we’re releasing a product that will deliver insanely fast IOPS to any storage utilising inexpensive RAM. With our product, no architecture change is required, no san volume dependencies, no expensive hardware upgrades and no hypervisor gotcha’s. ThinIO works with all major desktop virtualisation products like XenApp, XenDesktop, VDI in a Box, Microsoft Remote Desktop technologies and even VMware Horizon View!
ThinIO is just a simple installation and off you go. Not only will this product reduce, standardise and improve the speed of IOPS, it will also optimise and reduce boot storms dramatically.
Register for XenAppBlogs webinar here where we’ll discuss how ThinIO works for the first time or come visit us in Citrix Synergy (Booth 513) to celebrate the culmination of 2 years of work and learn how ThinIO is performant, reliable and an extremely cost effective method to deliver lightning fast experience to your users while protecting your disk storage from grinding to a halt.
Watch this space.
With the release of XenDesktop / XenApp 7.5, Citrix Storefront has brought back a very sought after feature, Single sign on for local credentials to the storefront site!
Citrix Storefront SSO can be the default configuration or a choice can be given to the user if you select more than one authentication type as below:
Desktop appliance site: (Slight deviation, bear with me).
An interesting addition to storefront in 2.5 is a desktop appliance site is installed by default. Richard covers what a desktop appliance site really well in this article for the current release of storefont here. It’s worth noting the desktop appliance site is running the older storefront code base and does not currently support single sign on, strangely.
Back on topic!
Below is a quick guide on how to get it working and any interesting features along the way, I’ve broken this piece down into three parts:
XenDesktop Delivery controller configuration:
on each delivery controller accessible by the storefront site, run the following two commands:
(Shawn Bass did alot of the hardwork here for me, so a thank you for that!)
when installing the client, you can enable the single sign on features with the following command line:
CitrixReceiver.exe /includeSSON /ENABLE_SSON=Yes /silent STORE0="Store;https://yourservername.yourdomain.com/Citrix/Store/discovery;on;Store"
Once this is complete, add the storefront url to the trusted sites for the user, then add the following setting to the trusted sites zone:
Once complete, open group policy on the local machine (or active directory group policy) and import the icaclient.adm file, the typical path is below for convenience:
C:\Program Files\Citrix\ICA Client\Configuration\icaclient.adm
C:\Program Files (x86)\Citrix\ICA Client\Configuration\icaclient.adm
Once you have imported this adm file, configure the following values in the LOCAL MACHINE configuration*
*the policies dont work in user mode, oddly.
Configure the authentication policy:
Configure the web interface authentication ticket settings also:
Now reboot the machine and log in, ensuring SSONSVR.exe is running in task manager.
I’m going to go ahead and assume you’ve already installed storefront, so lets start from there.
Make your way down to the ‘Authentication’ tab choose add/remove methods and select domain pass-through as an authentication type:
Note the warning, the receiver for web will also need some configuration, so that’s our next step:
Make your way down to your ‘receiver for web’ tab and select ‘Choose Authentication Methods’:
As you can see above, domain pass-through is now an option, with a nice little warning:
Note: if you don’t want SSO to be optional, don’t publish additional authentication types on this storeweb.
The quickest way to test is to go right ahead now and use the storefront in anger, but if you’re the cautious type Storefront 2.5 includes a subdirectory called DomainPassthroughAuth/test.aspx. if you browse to this site from a configured machine, you should see the following screen.
if you are prompted as below, or see any of the following errors, go back a few steps and check what you missed:
and the following error’s mean you’ve gotten the configuration wrong on the client side:
and that’s it, happy sso’ing!
When checking the bandwidth requirement of multimedia sites, checking how much additional bandwidth video conferencing is going to require or even troubleshooting WAN capacity issues, it’s extremely useful to have a visible interpretation of realtime bandwidth consumption from your virtual desktop.
I wrote a tool quite some time ago called watcher2 while troubleshooting a similar issue. I finally took the time to refactor that tool for use with XenApp 6.5 , XenDesktop and VMware View and they are finally available to download! Both watcher utilities also include a latency counter which was a request that came in over and over.
HDX and PCOIP watcher by default dock to the top of the screen and can be moved left or right as below:
They can now also be completely un docked:
How do they work?
The tool finds your username in the performance monitor counters for session bandwidth, once it finds this entry it reads your performance monitor data once every second and reports on it.
In the case of PCOIP watcher, it reads the PCOIP counters from performance monitor.
what do the values mean?
All values are in either Kilobits per second or Megabits per second.
In = Traffic from the client to the virtual, this may spike during large copy / paste jobs,web cams or copying data from a usb key to the session:
Out = Traffic from the virtual desktop to the client, mainly audio or video traffic causes this to spike.
Latency = The delay between your client and the virtual desktop.
Can I Configure it?
Two thresholds are available, a yellow warning and a red warning, currently . These default values can be written to HKCU\software\sessionmonitor or HKLM\software\sessionmonitor. E.G:
Do they have any dependencies?
.net framework 3.5
if you are running XenApp 6.5 or XenDesktop 5.6, ensure you have the latest hot-fixes installed or the counters may be incorrect.
How do I launch it?
Allow the user to run it manually, or place the executable in their start-up folder or login script.
Where Can I download it?
What’s coming next:
- Native Microsoft RDP Counters.
- Realtime graphs and recording.
- source code is available on request.
I recently delivered a presention to the Dutch Citrix User Group and E2EVC on the new technology release by Citrix called ‘Local App Access’.
In this post you will find the presentation deck and two utilities I have written for this technology to help empower the user to configure settings.
As I mentioned in my presentation, this technology is really cool, but it needs work. For a 1.0 it’s very promising but we need to use it in anger and log the bugs with Citrix to get them fixed. This technology alike Citrix remote PC is not a silver bullet, but it is a very useful utility in your toolbox for concentrating on the low hanging fruit during a migration.
Don’t let a single user or application in a department hold up user migrations by using this technology to keep the application local until you have time to come back to it.
Question: “You mentioned there’s a work around for getting ‘local app access’ to work without requiring desktop viewer?”
Yes, I’m a complete eejit, in both sessions I told you I would show you a way to get around this…. Then completely forgot! To get this working without needing desktop viewer, rename the cdviewer.exe executable in the ica client program folder to something else!
Reverse seamless VDI helper:
with the reverse seamless VDI helper tool, you can present this application to users In their virtual desktop to allow them to manage which applications are presented to their virtual desktop without having to lead the user through the registry.
Revere Seamless local desktop helper:
with the reverse seamless local desktop helper tool, you can distribute this tool out to your users to control which folders from which shortcuts are brought up to the virtual desktop.
Because life is about education, here’s the source code if you want to expand it yourself: