Long Term Service Release (LTSR). It doesn’t happen often. And here’s why this is a big deal!
The Wait is OVER – XenApp and XenDesktop LTSR 7.15
Aside from “should I use PVS and MCS?” the most common question I have been getting this year is, “When is the next LTSR being released?”
When no announcement was made at Synergy, I think people started thinking they would be waiting for “the Citrix” for-ev-er.
Understanding Releases- CR and LTSR
Very briefly if you don’t know already- Citrix XenApp and XenDesktop (yes, one product line with multiple license types, a discussion for another day) has two streams of releases:
- CR – Current Release. Roughly every 3-9 months or so, as new features are developed they are released into the ‘wild’. CR has a shorter lifecycle of support but you always have the latest features. It’s a great fit for environments that care about being on the cutting edge.
- LTSR – Long Term Service Release. Roughly every 2-3 years a new version is released. This “Locks in” a feature set and only security and stability patches are released. Those that are paying attention will note that Microsoft and other vendors are doing the same thing, and it’s important in the Enterprise.
Why Care About a Long Term Service Release (LTSR)?
There’s a lot of reasons to care about LTSR. Here’s my top 5:
- Proven Stability. LTSR has been simply huge in high-availability 24-hr verticals like Healthcare because you can predict what it will do. A longer lifespan means more predictability. LTSR is the Honda Accord of Citrix releases. You just know it’s going to work the same way 3 years from now as it does today. You know it because literally hundreds of customers are using the same version.
- 10 Year Support Possible. This is because with less changes being made, the support lifecycle is longer. This means in some cases an almost 10 year support lifespan (not that you would, but you could!) Given the amount of XenApp 5.0 and 6.0 farms I’m still seeing out there, I’m reminded that not everyone upgrades often. If it ain’t broke, don’t fix it, right?
- App Vendors Like it. Sure, new features are great but there are times when the development lifecycle for an application is longer than the features of the underlying delivery. An LTSR release lets you specify a standard way of doing things knowing it will be easier to support in the long run.
- Better ROI. I have to say this again- Return on Investment only applies if your Operational costs are lower. A standardized release means more people will learn how to administer the environment and get better at it over time. In fact- certifications are now aligning towards LTSR releases.
- Better and Faster Support. Not just from Citrix, but from partners and application vendors and even web searches. Let’s face it- for all the reasons above you’ll get better quality and faster support using an LTSR than a CR.
So What’s the Problem?
Well- 1.6 years ended up being a long time to wait for a lot of people. After all, there have been a LOT of useful features in the 7 releases that have come between LTSRs. So, what I have been seeing is a lot of ‘inbetween’ adoption of versions to get a certain feature that have had consequences in the areas I note above. A full comparison of feature sets can be found here. Needless to say, a full 2 or even 3 years just wasn’t going to work. Too many people were clamoring for features that they couldn’t get in LTSR and making compromises in Enterprise environments, which totally goes against the whole purpose!
Key Features I’ve been waiting for in LTSR
There are a LOT of key features I’ve been waiting to see – the list is long but distinguished (DON’T say it…):
- HDX Enlightened/Adaptive Transport (note, 7.6 locked in the last great advancement in ICA. This is the next and the single most common reason I’ve seen the switch to CR this year. Solved.)
- HTML5 Redirection, Framehawk and H.264 SuperCodec if you’re into such things
- Windows 10 support
- Application Groups
- Local App Access
- Local Host Cache. This may be the missing feature others were quick to use CR. Me, I say you still want to have a good SQL structure regardless but at least this makes a more assured stable environment.
- MCS for Server OS. I’ll admit it. I’d rather see some image management than none. PVS is not always appropriate despite it’s UTTER AND COMPLETE SUPERIORITY. Bonus points to have access to RAM caching to further reduce the hit to IOPS for writes. [Edit 9/19/17: I noticed today that support for HyperV Gen2 VMs is now included with 7.15! Hello 2016!]
- Federated Services and SAML.
- Web Password reset
- Azure and Nutanix Acropolis support!
- Linux Desktops AND LINUX ON FREAKIN PVS!!!
Anything Missing in LTSR 7.15?
- WebInterface Support. I try not to giggle, but the reality is that a lot of people are still stuck on WI instead of StoreFront. Some even have legit reasons. And for that I am sorry. But if you are in that very exclusive club, do NOT upgrade to 7.15 LTSR. You will not find WebInterface support follows you. Time to increase those consulting budgets!
- Common Criteria Certification and FIPS Compliance. FIPS may actually have a leg to stand on with 7.15 LTSR, but Common Criteria is notably missing. I’m not yet sure why but… if you need to be sure, stay with 7.6 LTSR.
- Multiple license editions per farm. Sadly- still missing since sometime around the 6.5 days 🙁
- SA Licensing. In a move I’m sure will cause a backlash, only CRs are currently eligible under SA. You must have Customer Success Services active to get the new licenses. Sorry, holdouts. It’s the future.
- Mixed component versioning. As with LTSR 7.6 – you must maintain all components at the same LTSR version to get support for the full timeframe.
Read More about the release here: XenApp & XenDesktop 7.15 LTSR – The Blockbuster Release of the Summer | Citrix Blogs
With XenApp 6.5 going End of Life in… less than a year… (June 30th, 2018… or August 24th, 2016 if you broke your active SA agreement- long story but do you really want to take the chance of calling support and finding you have none?) I’d say it’s probably time to upgrade, and this is the release that should make it practical!
Unfortunately this release has come at a busy time for me but… I downloaded it yesterday (8/14/2017) and am looking forward to getting this live!
Interested in help with your migration? Questions about licensing? My team at Accordant Technology can help or contact me below.
So, how about it? Will you be upgrading this Fall?
(note- this website is not maintained by Accordant Technology, it’s where I work 😉 )
And, how about some celebration music?
(Buy this song on our affiliate Amazon: http://amzn.to/2fJtPqi)
It may be time to take another look at XenServer, folks.
The new PVS Accelerator feature caches the PVS stream, drastically reducing the CPU and Bandwidth required. For XenDesktop PVS-based VDI… this would solve a lot of boot-storm issues and makes the “Pod” configuration a great option.
Goodbye hypervisor tax, in other words.
Source: What’s New in XenServer 7.1 – Part III | Citrix Blogs
My advice- always go with the Hypervisor you know you can support, but if you have a large scale deployment of VDI- it may be very much worth your time to learn how to support XenServer in addition to vSphere ESX.
Why? Because you can put your “Control” layer, now including your PVS servers, on your hardened and HA VMware cluster… and deploy cheaper XenServer pods for your VDI- which doesn’t require HA and would now not really need to have PVS servers on the same XenServer cluster since the data being accessed could be cached. The implications of this in a multi-datacenter or Cold Recovery DR environment are actually really big.
This. Is. Awesome.
Gotta boost the signal on this. My friend Nick Rintalan from Citrix Consulting has put together a new ‘best practice’ (or leading practices for the lawyers) update that I feel it’s important for people to see!
Nick Rintalan, Lead Architect at Citrix Consulting
New Best Practice(s)?
Here are some of the highlights of the article, sorted here by what I feel is most important for you to read:
- PVS and Memory Buffers. Yes, yes, for the love of all that is holy, yes. I haven’t yet deployed for validated the Write Cache features now in MCS, but I can tell you from experience that XenApp with 2-4 GB of RAM cache with failover to disk has been giving roughly 20-30% faster logons and overall better experience for most of my customers.
- Protocols (as in HDX). One of my primary frustrations for quite some time now is that Citrix XenDesktop ships by default with a protocol that has a good experience on LAN but tends to be problematic at distance. H.264 is great for video, but frankly I hate it everywhere else. I think it almost singlehandedly ruined things for Citrix since PCoIP can perform better than this hog (my opinion). Thinwire and even the legacy encoder, however- actually deliver on the promises and need to be investigated in nearly every single use case I see. So I agree with Nick- use the policy templates included with 7.6 u3 and above (including LTSR) as a starting point. Odds are good you won’t be disappointed. When I say ‘use’ here what I mean is remember that you can apply these codecs on a per user basis, connection basis or even per delivery group- meaning filters are your friend! It is perfectly acceptable to have multiple codecs going for various use cases. One size nearly NEVER fits all, so test these out!
- vSphere Cluster Sizing. Number 3 on my list right now. You need a dedicated resource cluster for Enterprise workloads- but honestly- for XenApp workloads, consider more hosts per cluster. You should be using bigger VMs anyway, so the number of managed VMs is about the same- just more computing power. CCS is seeing 24+ hosts per cluster be just fine in XenApp. For XenDesktop with more than 5000 VMs- I will add here that a dedicated vCenter may save you a lot of pain… my opinion, and of course… you guessed it. TEST!
- XenApp CPU Over-Subscription. Seriously. The “1.5x” thing needed an update so I’m glad to see some clarification here. In all things- I still encourage practical testing instead of just implementing something because “Citrix said to.”
- PVS Ports and Threads. Those of you who know me know I bang this drum a lot- so here’s some backup for what I’m saying. The defaults are not good enough. Good design is still required!
- Farm Design. You’re probably like me and are coming along kicking and screaming from XenApp 6.5, which most would agree has been the “Windows XP” of the Citrix world. It just hasn’t been this good yet, and I still feel 7.9 doesn’t have true feature parity… but as Nick describes, they are getting there. As always… TEST, TEST and then TEST some more before you implement zones with FMA!!!!
- XenMobile Optimizations. I guess we have to talk about it. XenMobile is here to stay, so best to not take the ‘out of the box’ experience there either.
READ: “New” Citrix Best Practices 2.0 | Citrix Blogs
Give it a read and let me know your thoughts… but most importantly- don’t forget to share this!
PVS (Provisioning Services) or MCS (Machine Creation Services, aka linked clones)? This is a long-standing debate that I’m hoping to have the time to address after Citrix Synergy. But I did appreciate this breakdown since I continue getting this question all the time: Should I choose PVS or MCS for my deployment?
Well, in our debate-obsessed culture (US Elections, Batman vs Superman, Captain America vs Iron Man… the list is endless), this one is heating up. In some ways- it’s like having to chose the less of multiple evils…
But in all honesty- how do you make the decision?
Well- of course it depends- but one thing you may want to consider first from Dan Feller’s recent blog- which bottleneck will you be experiencing?
PVS vs MCS – Part 2: Scalability | Ask the Architect
In a nutshell- if your storage is awesome (super fast with good deduplication capability) but your network may not be… MCS is an easy win.
If you plan to deploy to the cloud- MCS is an easy win.
If you need it deployed quick for a POC- MCS is an easy win.
Considering the real network consumption to boot a VM is less than 300 MB, and that PVS makes diskless or near-diskless configurations possible…
PVS is still my reference standard, even for smaller environments. Here’s why:
- PVS has a proven track record and an ability to deploy a single image to multiple hypervisor pools. MCS struggles with requiring copies of the master VM to each storage. While this has gotten better, PVS is still epic in this regard.
- Networks have evolved and is barely ever a bottleneck that makes PVS struggle. Even a single 1Gbit connection can boot and maintain several hundred target VMs. Given that most VMs are operating at more than 10Gbit in the enterprise today and the load can be spread to multiple PVS servers… this factor barely exists any longer.
- PVS has always reduced IOPS requirements overall, but in the past 4 years has seriously jumped forward because of two things:
- Your .vhdx file is read and cached into RAM, so subsequent reads for target device requests come from RAM. This means you can scale nearly endlessly with virtually no IOPS impact from reading the base vDisk.
- Write Cache in RAM with Failover to Hard Disk, while the longest description ever is perhaps one of the single most epic bits of Citrix technology to be deployed in the past 10 years. Reducing the amount of storage IOPS for Write, which used to be almost 90% of the overall IOPS required for PVS targets is now lessened because the writes are cached in RAM and in some cases don’t even hit the disk at all!
- PVS makes a pod-based architecture viable, lowering downtimes significantly. With the right design, you can have an entire rack of servers go offline and your users won’t even know. You can design in ways that allows you to mix storage and hypervisor pools that MCS has trouble maintaining. So when I say it scales “better” I am rarely talking about quantity but operational quality. Of course, it all depends on good design but if you want to hear more about that, I’d love to discuss it!
- PVS prevents the SAN battle. Nearly every time I go into a deployment of XenDesktop the team managing the SAN storm into the conference room with a unified front ready to say ‘no.’ But I tell them we may not need them at all (local storage really is possible for PVS targets) or that our IOPS will be less than 1 per user… their shoulders drop down, they smile and tell me to have a nice day. And, I do. Because they said “yes”- because I’ve made their life easier.
- PVS can track versioning and rollback images with much more speed and efficiency than every other technology out there I have ever seen.
Now, does PVS represent a learning curve- absolutely, which is I think the other thing that needs to be further discussed. I continue to see bad practices out there… but first I want to hear from you: What experiences have you had between MCS and PVS, and what are your thoughts? What kind of questions do you have? Comment below!
But if you want my advice in most cases, subject to a whole bucket of ‘it depends’ here it is:
- POC with MCS
- Small deployments and cloud-based deployments with MCS
- Go to Production with PVS
- Put on your gloves and get ready for a fight
Good luck! Share this with your colleagues – I’d love to hear more from people before I start the Citrix Imaging topic in a few weeks!