ThinIO Public Beta is go!

Lets get right to it!

Warm up your labs or fire up your golden images ladies and gents, we’re delighted to announce ThinIO’s brief public beta will begin today!

This project has taught us some really interesting things about Windows IO, how Windows behaves and how the hypervisor and storage can behave. This project really felt like a David vs. Goliath task as we (members of our community with a desire to simplify this issue) attempted to tackle one of the largest issues in our industry, storage bottlenecks and Windows desktops.

What’s really unique about our approach is there are no hardware lead times, no architecture changes needed and no external dependencies. ThinIO can be installed in seconds and the benefits are seen immediately.

ThinIO, taking a peak under the covers.

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.

 

Licensing:

 

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.

Briforum 2014: Thin Client myth debunking and general discussion.

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.

Download Link.

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.

ThinIO, here comes something incredible.

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:

IOPS, Shared Storage and a Fresh Idea. (Part 1)
IOPS, Shared Storage and a Fresh Idea. (Part 2)
IOPS, Shared Storage and a Fresh Idea. (Part 3)

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.

Register for Xenappblogs webinar with ThinScale Technology for the official launch of ThinIO

Citrix Storefront 2.5 and Single Sign on:

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:

 

Client Configuration:

 

(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:

x86:

C:\Program Files\Citrix\ICA Client\Configuration\icaclient.adm

x64:

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.

 

Storefront Configuration:

 

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.

 

Testing:

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!