Power and Capacity Manager (PCM) is a feature of XenApp 5.0 Feature Pack 2. In this multi-part post, I will deep-dive on PCM configuration and trade-offs. I will assume you have basic understanding of the feature, please look here for an introduction.

To use Power and Capacity effectively, you will have to define the power management and load characteristics of your workloads. You have to strike a balance: if you are too aggressive, you may overload servers or cause connection failures. If you are too conservative, you will limit the manageability gain and power cost savings.

All PCM policies are defined per “workload”. A workload is a group of computers that publish the same set of applications. You configure the PCM workload name during the agent installation, and you can modify it editing HKLM:\SOFTWARE\Policies\Citrix\XenAppPCM\WorkloadName

There are two important set of configurations in PCM: the Session Capacity estimation and the Weekly power management schedule. I will describe Capacity Estimation in this post, and the Weekly Power Management schedule in Part 2.

PCM policies are based on “Session Capacity” of each server and workload – i.e., how many sessions each server in a workload can host. The most basic concept in PCM is “Load Consolidation”: instead of spreading sessions to all servers in the workload we load a few servers up to an “optimal load”. Optimal load is defined as a percentage of the server session capacity, so we must estimate the later accurately. Also, most PCM policies reference “session buffers” and “available sessions”, both require server capacity estimation.

Our first attempt was to use the server Load Evaluators to estimate capacity. XenApp uses load evaluators to determine which server will process a connection request. The Load Index varies from 0 (no load) to 10,000 (maximum), so couldn’t we use the load index (divided by 100) as load percentage? Not really. A server with 50 sessions and a load index of 5,000 won’t necessarily behave well with 100 sessions. The key problem is that load index is only used to find the least loaded server, and the session capacity is irrelevant most of the time. Therefore most XA environments stick to the Default Load evaluator (cap at 100 sessions), even though the servers never host more than 30-40 sessions.

We felt that overloading the load evaluator to estimate capacity was dangerous. We wanted a “soft” estimation, that wouldn’t cause problems if it was underestimated. Therefore PCM defines a new configuration called “Typical Session Capacity”, which tells PCM how many sessions to expect for a particular hardware specification.

In the PCM console, select a workload, then the “Capacities” tab. Over there you will see one row per hardware specification – for example, in my XenServer setup I see “VM: Intel Xeon E5345 @ 2.33 GHz, 1 core, 512 MB”. Select the hardware spec, then “Server Profile Properties…” in the actions pane.

You should configure the typical load as the number of sessions you know a server can host without impacting user performance. PCM will force IMA to load a few servers up to an optimal load, so this number has direct impact on how much sessions will consolidate. The safest way to estimate this value is to start with the session high-water mark on your existing servers, and work your way up if you believe the server can handle more.

As an example, let’s say you define typical load at 50 sessions. If you left the default optimal load configuration (70%), PCM will load servers up to 35 sessions before enabling other servers. Once all servers reach the optimal load, the load balance will behave as before – finding the least loaded server. Therefore, there’s little risk in underestimating the typical load – at worst you will be back to pre-PCM load balancing!

OK, but what happens if the IMA load index gets to 10,000 before the server hit the optimal load? Good question! PCM constantly adjust the server capacity based on the IMA load index. For this dynamic estimation, we assume the load index is linear: each session contribute the same way to the index, and that new sessions will continue to do so – i.e, capacity = 10,000 * Current Sessions / IMA Load Index . PCM then use the smallest of the static and dynamic estimations. In the example above, if IMA load index was 5,000 with 10 sessions, PCM would reduce the capacity estimation to 20.

We have also exposed an advanced configuration if you want to use the IMA load index as the primary method to determine server load. This requires a more careful construction of the load evaluator – you have to adjust it so that the load index grows smoothly from 0 to 10,000. You would use this method if the session capacity varies too much – say, it’s usually 100, but sometimes it can go up to 150. You would be wasting the last 50 sessions using the previous approach.

To model such load pattern, go to the “Server Profile Properties” and select the “Advanced” checkbox. Enter the “Estimated Session capacity limit” – it would be 150 in this example. Now PCM will use the Typical session capacity only when the server is off-line or with zero sessions. Otherwise, it will use the IMA load index and the “estimated session capacity limit”.

Why not set the typical session capacity to 150 in the example above? Well, if most of the time servers get loaded at 100, then PCM will over-estimate the server capacity when servers are offline. This will cause some grief during unexpected load events, when servers must be powered on to cover unexpected incoming sessions. So keep the “typical” value to what is the norm, and use the “estimated limit” to get an extra mile adjusting load evaluators.

Stay tuned for Part 2, with a deep-dive on the PCM power management schedule!

 Update: Part 2 (Policies) posted here.

Learn more about Citrix XenApp 5 Feature Pack 2

Follow XenApp on | | |