Archive
#Citrix #PVS vs. #MCS Revisited – #Nutanix, #Sanbolic
Another good blog post from Citrix and Nick Rintalan around the famous topic whether to go for PVS or MCS! If your thinking about this topic then don’t miss this article. Also ensure that you talk to someone who have implemented an image mgmt/provisioning service like this to get some details on lessons learnt etc., also with the change in the hypervisor layer and the cache features this is getting really interesting…
AND don’t forget the really nice storage solutions that exists out there like Nutanix and Melio that really solves some challenges out there!!
http://go.nutanix.com/rs/nutanix/images/TG_XenDesktop_vSphere_on_Nutanix_RA.pdf
Melio Solutions – Virtual Desktop Infrastructure
Back to the Citrix blog post:
It’s been a few months since my last article, but rest assured, I’ve been keeping busy and I have a ton of stuff in my head that I’m committed to getting down on paper in the near future. Why so busy? Well, our Mobility products are keeping me busy for sure. But I also spent the last month or so preparing for 2 different sessions at BriForum Chicago. My colleague, Dan Allen, and I co-presented on the topics of IOPS and Folder Redirection. Once Brian makes the videos and decks available online, I’ll be sure to point people to them.
So what stuff do I want to get down on paper and turn into a future article? To name a few…MCS vs. PVS (revisited), NUMA and XA VM Sizing, XenMobile Lessons Learned “2.0″, and Virtualizing PVS Part 3. But let’s talk about that first topic of PVS vs MCS now.
Although BriForum (and Synergy) are always busy times, I always try to catch a few sessions by some of my favorite presenters. One of them is Jim Moyle and he actually inspired this article. If you don’t know Jim, he is one of our CTPs and works for Atlantis Computing – he also wrote one of the most informative papers on IOPS I’ve ever read. I swear there is not a month that goes by that I don’t get asked about PVS vs. MCS (pros and cons, what should I use, etc.). I’m not going to get into the pros and cons or tell you what to use since many folks like Dan Feller have done a good job of that already, even with beautiful decision trees. I might note that Barry Schiffer has an updated decision tree you might want to check out, too. But I do want to talk about one of the main reasons people often cite for not using MCS – it generates about “1.6x or 60% more IOPS compared to PVS“. And ever since Ken Bell sort of “documented” this in passing about 2-3 years ago, that’s sort of been Gospel and no one had challenged it. But our CCS team was seeing slightly different results in the field and Jim Moyle also decided to challenge that statement. And Jim shared the results of his MCS vs. PVS testing at BriForum this year – I think many folks were shocked by the results.
What were those results? Here is a summary of the things I thought were most interesting:
- MCS generates 21.5% more average IOPS compared to PVS in the steady-state (not anywhere near 60%)
- This breaks down to about 8% more write IO and 13% more read IO
- MCS generates 45.2% more peak IOPS compared to PVS (this is closer to the 50-60% range that we originally documented)
- The read-to-write (R/W) IO ratio for PVS was 90%+ writes in both the steady-state and peak(nothing new here)
- The R/W ratio for MCS at peak was 47/53 (we’ve long said it’s about 50/50 for MCS, so nothing new here)
- The R/W ratio for MCS in the steady-state was 17/83 (this was a bit of a surprise, much like the first bullet)
So how can this be?!?
I think it’s critical to understand where our initial “1.5-1.6x” or “50-60%” statement comes from – that takes into account not just the steady-state, but also the boot and logon phases, which are mostly read IOPS and absolutely drive up the numbers for MCS. If you’re unfamiliar with the typical R/W ratios for a Windows VM during the various stages of its “life” (boot, logon, steady-state, idle, logoff, etc.), then this picture, courtesy of Project VRC, always does a good job explaining it succinctly:
We were also looking at peak IOPS and average IOPS in a single number – we didn’t provide two different numbers or break it down like Jim and I did above in the results, and a single IOPS number can be very misleading in itself. You don’t believe me? Just check out my BriForum presentation on IOPS and I’ll show you several examples of how…
Continue reading here!
//Richard
Demystifying Citrix Excalibur Architecture – via @kbaggerman
A great blog post by Kees Baggerman! 🙂
For all XenApp admins and consultants out there Project Avalon will bring a big change as we are used to having XenApp servers running on the (what seemed to be) everlasting Citrix Independent Management Architecture and we’re heading to Citrix FlexCast Management Architecture (already included in XenDesktop at this moment) and will be included in the Citrix Excalibur Architecture.
IMA
When looking up IMA in the eDocs you’ll find:
Independent Management Architecture (IMA) is the underlying architecture used in XenApp for configuring, monitoring, and operating all XenApp functions. The IMA data store stores all XenApp configurations.
Basically IMA exists to manage the XenApp or Presentation Server farms by enabling the communications between servers. As stated it transfers information about all XenApp functions like licenses, policies, sessions and server loads. All management tooling within these versions of Citrix’s PS/XA rely on this service for information.
According to Communication ports used by Citrix Technologies IMA uses the following ports:
| Ports | Source | Prot. | Comment |
| 2512 | Common Citrix Communication Ports | TCP | Independent Management Architecture (IMA) |
| 2513 | Access Gateway 5.0 Controller administration | TCP | IMA-based Communication |
As we can see IMA uses 2512 (by default) to communicate with other servers and the Access Gateway Controller uses 2513 (by default) for IMA-based communication. The port IMA uses can be changed or queried via the commandline tool IMAPORT.
Brian Madden did a blogpost way back in 2007 but it’s definition of IMA is still current:
Independent Management Architecture is:
- A data store, which is a database for storing MetaFrame XP server configuration information, such as published applications, total licenses, load balancing configuration, MetaFrame XP security rights, and printer configuration.
- A protocol for transferring the ever-changing background information between MetaFrame XP servers, including server load, current users and connections, and licenses in use
FMA
With the introduction of XenDesktop we got a new architecture called Flexcast Management Architecture. This new architecture has got an agent-based setup where we can install the operating system including the basic applications that need to be installed and after that we can install an agent. This agent registers itself to a controller and is offered through StoreFront to the end user.
This will be delivered by two different types of agents, one to support Windows Server OS’s and one for Windows Desktop OS’s.
Andrew Wood did an article on Excalibur and used this diagram to explain the architecture:
Citrix FlexCast Management Architecture
- Receiver provides users with self-service access to published resources.
- StoreFront authenticates users to site(s) hosting resources and manages stores of desktops and applications that users access – Web Interface as a platform is essentially resting, but it will cease to be.
- Studio is a single management console that enables you to configure and manage your deployment, a dramatic reduction over the 23 consoles you could well have today. Studio provides various wizards to guide you through the process of setting up an environment, creating workloads to host applications and desktops, and assigning applications and desktops to users.
- Delivery Controller distributes applications and desktops, manages user access, and optimizes…
Continue reading here!
//Richard
#Citrix #XenApp 6.5 Hosted Shared Desktop Sizing Example
Great Citrix blog post series from Andy Baker!
In this blog series I’m taking a look at scalability considerations for XenApp 6.5 Hosted Shared Desktops, specifically:
- How to estimate XenApp 6.5 Hosted Shared Desktop scalability
- What’s the optimal XenApp 6.5 VM specification?
- XenApp 6.5 Hosted Shared Desktop sizing example
My last post provided guidance on the optimal XenApp virtual machine specification. Now in the last post of the series, I’m going to walk through an example sizing exercise.
Scenario
Company ABC recently completed a user segmentation exercise. The following table includes 8 user groups that have been identified as good candidates for a Hosted Shared Desktop. None of these user groups requires the ability to install applications or the ability to customize their desktop beyond profile based changes. Three separate Provisioning Services images will be created due to application compatibility conflicts identified by Citrix AppDNA.
With Hosted Shared Desktops, it is important to consider the ‘Maximum Number of Concurrent Users’ column rather than the ‘Total Number of Users’ column. Sizing the environment for concurrency rather than the total number of users will help to reduce infrastructure costs without affecting performance or availability.
Sufficient redundancy should be incorporated into the sizing estimate so that a single XenApp server or virtualization host failure does not affect the total number of concurrent users that can be supported (n+1).
Company ABC wishes to use their standard hardware specification…
Continue reading here!
//Richard
Another great blog : Virtualizing XenApp Hosted Shared Desktops on Hyper-V
Thanks a lot for this blog post!
“My latest adventure into density testing for Citrix solutions centers on XenApp (XA) Hosted Shared desktops. For those unfamiliar with the XA Hosted Shared model, it combines application and session virtualization, relying on a single OS instance on a Citrix XA server to publish familiar Windows desktops and applications. The Hosted Shared model centralizes application delivery and management (securing data and applications in the data center), and it scales well to support large user densities. It is designed to provide a locked-down, streamlined, and standardized environment with a core set of applications, making it ideally suited for task workers where personalization is less of a focus. While the XA server can be hosted directly on a bare-metal server on Windows Server 2008 R2, my recent testing explores the densities you can achieve when XA runs in a virtualized environment.”
Continue to read here!
//Richard
The IT Melting Pot! 