Yesterday I’ve posted Part 1 of this series, talking about Capacity Estimation. Today I will describe the Power Management schedule policies. PCM use these policies to determine how many servers should be powered down, how sessions will consolidate or spread among the online servers, and when to power on additional servers to handle unexpected load.
The load policies for a workload vary during the day – you need more capacity during working hours than over the weekend. PCM configurations are entered over a weekly table period. Each entry has a start time four settings described below.
You will find this configuration on the PCM console. Select any workload, and then the “Schedule” tab. Each entry configures the following policies:
Minimum session capacity (Min Capacity): specify how many sessions, connected or not, should be on-line. The minimum session capacity is probably the easiest policy to understand and define. It describes the typical session utilization of that workload over time. For example, if you expect 1000 users connected to a workload during the day, and 250 over night, you will configure Min Capacity to 1000 from 8 to 5, and 250 from 5 to 8. It’s that simple.
PCM will start as many servers as needed to support the Min Capacity policy. Servers are selected randomly, although you may control the selection order using the server tiers – I will cover tiers in more details at another post.
The session capacity is the sum of the estimated capacity of each online server in that workload. See Part 1 for in-depth description of load estimation.
Min Capacity is ignored if “Power Management” is disabled for that workload.
Minimum available servers (Min Servers): specify how many servers will handle logon requests. At first glance this seems similar to Minimum session capacity, but there’s more to it.
PCM works its magic by setting the IMA load index to 20,000 value, indicating to IMA load balancer that the server is not available to take additional sessions. In the PCM console, you can see each servers selection state – select a workload and the “Servers” tab. At the left side of the “Sessions” column, you will find a small icon that can be:
- Circle: Load consolidation has disabled logons on this server. The IMA load index is set to 20,000.
- Green Triangle: Load consolidation has enabled logons on this server. The IMA load index is calculated based on the Load Evaluator.
- Yellow Triangle: Load consolidation has enabled logons on this server, but the load is higher than the optimal load. The IMA load index is still calculated based on the Load Evaluator.
The Min Servers policy defines how many servers with “green triangles” you will see in that workload – servers with enabled logons and under the optimal load. In the picture, I have Min Servers set to 1. Server 1 is draining, Server 2 is accepting logons, and Server 3 is above the optimal load (of 70%).
The value of this parameter should be related to expected user logon concurrency. If you set this value too low, then a small number of servers have to process too many logon requests, increasing the average logon time. If you set Min Servers too high, then sessions will spread to too many servers.
As a rule of thumb, you should set Min Servers to a higher number just before a shift starts – say, at 7:00AM – and reduce it after the logon peak has passed.
But how should I estimate this value? Well, you may start with a conservative high number and work your way back until user logons are impacted. Edgesight is a terrific way to get this data. Another way is to calculate the expected concurrent logons per server, based on peak logon rate and the logon time. For example, if average logon time is 30 seconds, and peak logon rate is 2 users/second, you should expect 15 concurrent logons if Min Servers is set to 1 (30 seconds/logon divided by 2 users/second). If you want to limit servers to process at most 5 concurrent logons, you will need Min Servers set to 3.
Min Servers policy is ignored if you disable load consolidation in the workload.
Online session reserve (Session Reserve): specify how many sessions should be available at on-line servers. Available sessions are calculated as “Session Capacity” minus connected sessions. For example, if a server has session capacity of 100 and 30 sessions, available sessions would be estimated as 70.
PCM counts all server sessions, including console and disconnected sessions.
Session reserve is used to create a buffer of available sessions for unexpected session influx. Servers take a while to boot, therefore you need to start powering on servers before the workload is fully loaded.
When the session reserve policy is violated, PCM will start sufficient number of servers to bring the policy back to compliancy.
Session Reserve can be estimated based on server power on time, and the maximum unexpected connections influx you have to support via SLA. For example, let’s say your servers take 5 minutes to power on, and your DR strategy requires the workload to take up to 60 users/minute if a site fails. Your session reserve has to be set to 300 – the expected number of sessions before the 1st offline server can become available.
In the example above, PCM may issue additional power-on commands before the 1st server comes online. Let’s say each offline server can take 100 sessions. When the number of available session falls under 300, the 1st server is started. If connections continue to come in, and available sessions fall under 200, the 2nd server is started, since the 1st server alone wouldn’t be sufficient to get the session reserve policy back into compliancy.
Online session reserve is ignored if you disable power management in the workload.
Maximum session capacity (Max Capacity): specify a high water mark for capacity in the workload. This is an advanced setting, most workloads won’t have to bother (default is “infinite”). This is used if you want to specify a session reserve, but stop adding servers after a certain point.
For example, assume your servers have session capacity of 100. A workload has 400 sessions at peak utilization. You have an SLA to support up to 600 sessions during DR events. You also have 7 servers assigned to this workload, but you can only power on 6 at a time due to power constraints – the 7th is there in case any other breaks. In this case, you may define Maximum session capacity as 600. Even if the session load gets above 500 (breaching the Session Reserve policy) PCM will not start the 7th server as it would violate the maximum capacity policy.
OK, that completes the PCM weekly schedule policy configuration. Next, in Part 3, I will talk about sites, tiers, and computer managers.