Troubleshoot application placement

Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Troubleshoot application placement

Occasionally, you might encounter application placement behavior that is not expected. This topic describes some common things to look for when application placement is not working, or not working the way that you expect.

Administrative roles

Depending on your administrative role, you are allowed specific privileges when configuring the autonomic managers. The following list shows the administrative roles and privileges for configuring the autonomic managers:

Monitor

Can view the information.

Operator

Can view the information on the configuration tab.

Can change the settings on the runtime tab.

Configurator

Can change the configuration but not the runtime settings.

Administrator

Has all privileges.

Application placement changes are not occurring when you expect
If you find your application placement changes are occurring in an unexpected fashion, use the following course of action:

Verify that the placement controller is enabled. In the administrative console, click Operational policies > Autonomic managers > Application placement controller. Verify that the placement controller is enabled.
Verify that the subject cluster or clusters are dynamic clusters. The application placement controller acts upon dynamic clusters only. In the administrative console, click Servers > Dynamic clusters. Check that the Operational Mode field for each of the subject clusters is Automatic. If not, select the dynamic clusters and click Automatic. After you select automatic for your dynamic clusters, click Set Mode.
Verify that the configured minimum time between placement change parameters is not set too high. In the administrative console, click Operational policies > Autonomic Managers > Application placement controller. Set the value in the Minimum time between placement changes field to a suitable value. Acceptable values range from 1 minute to 24 hours.
Verify that the configured application placement controller cycle is not too long. To modify that setting from the administrative console, click Operational policies > Autonomic controllers > Application placement controller > Custom properties. Add a custom property, by clicking New. In the Name field, enter minControlCycleLength and in the Value field, provide a suitable time value in minutes, such as 1.

If the problem still persists after making these suggested changes and restarting the cell, verify the following problems.

Dynamic cluster members are not inheriting properties from the template

You must save dynamic clusters to the master repository before making changes to the server template. If you have dynamic cluster members that do not inherit the properties from the template, the server template probably incurred changes in an unsaved workspace. To fix this issue, delete the dynamic cluster, then recreate it.
Save your changes to the master repository. You can ensure that your changes are saved to the master repository after clicking Finish, by clicking Save in the message window in the top frame. Click Save again in the Save to Master Configuration window. Click Synchronize changes with nodes.

Not enough active servers in a dynamic cluster
If you encounter problems where not enough servers are running in the dynamic cluster, try the following actions:

When the nodes in the node group are not highly utilized, verify the service policy is met. At times the policy might not be defined clearly and although the system is able to meet them, although not to your expectations. To check or change a service policy in the administrative console click Operational policies > Service policies > Select an existing policy. Check the goal type, goal value, and importance of the policy, and make any necessary changes.
When the nodes in the node group are highly utilized, compare the service policy goals of this cluster to service policy goals of other active clusters. If the traffic that belongs to this cluster has lower importance or looser target service goals relative to the other clusters, it is more likely that the system instantiates fewer servers for this cluster. To check or change a service policy in the administrative console, click Operational policies > Service policies > Select an existing policy.
When the node group seems to have some extra capacity, but your service policies are not met, check the configuration settings on the dynamic cluster. There might be too few instances of the dynamic cluster created as a result of the maxInstances policy setting.

Application placement controller logs
apc.log

The application placement controller logs information regarding application placement decisions the apc.log file. You can submit this file when you contact IBM support so that decisions that are made by the application placement controller can be understood.
You can enable the application placement controller logs with the apc.log.enablePlacementLog custom property. To change the size and number of log files, edit the apc.log.LogFileSize and apc.log.numHistoricalFiles custom properties.

SystemOut.log
You can look for DCPC400 messages in the SystemOut.log file of the node that runs the application placement controller. These messages contain information regarding the input and result of a placement cycle. This information can be useful in understanding the decisions made by the placement controller. For example,
[7/23/08 10:42:12:086 EDT] 0000006f APCXDMapHelpe I   DCPC400I: Application Placement Controller Input is
Cluster name is dc1:
        Cluster's properties: Type=DYNAMIC, Operational Mode=AUTOMATIC, Minimum Instances=2, Maximum Instances=2, 
          Isolation Preference=None, Vertical Stacking Number=Disabled, Lazy Start Time=Disabled, Idle Stop Time=Disabled, 
          Current Memory Size=371.2 MB, Maximum Heap Size=256.0 MB
        Cluster's Demands: CPU Demand=0.0, Memory Demand=0.0
        Cluster's Utility: {UtilityFunctionLinear extantDemand=0.0, utility=1.0}
        Cluster's Node Membership: jpcammar01Cell01/elara11Node01, jpcammar01Cell01/elara11Node02,
        Cluster's Members: jpcammar01Cell01/elara11Node01/dc1_elara11Node01, jpcammar01Cell01/elara11Node02/dc1_elara11Node02,
        Cluster's Placements: None
[7/23/08 10:42:12:090 EDT] 0000006f APCXDMapHelpe I   DCPC400I: Application Placement Controller Output is
Cluster name is dc1:
        Cluster's properties: Type=DYNAMIC, Operational Mode=AUTOMATIC, Minimum Instances=2, Maximum Instances=2, 
          Isolation Preference=None, Vertical Stacking Number=Disabled, Lazy Start Time=Disabled, Idle Stop Time=Disabled, 
          Current Memory Size=371.2 MB, Maximum Heap Size=256.0 MB
        Cluster's Demands: CPU Demand=0.0, Memory Demand=0.0
        Cluster's Utility: {UtilityFunctionLinear extantDemand=0.0, utility=1.0}
        Cluster's Node Membership: jpcammar01Cell01/elara11Node01, jpcammar01Cell01/elara11Node02,
        Cluster's Members: jpcammar01Cell01/elara11Node01/dc1_elara11Node01, jpcammar01Cell01/elara11Node02/dc1_elara11Node02,
        Cluster's Placements: elara11Node02/dc1_elara11Node02, elara11Node01/dc1_elara11Node01,
If you look at the first DCPC400 message, you can see important information about the clusters:

Cluster's properties: Displays cluster configuration information.
Cluster's Demands: Displays the cluster demands on processor and memory.
Cluster's Utility: Displays the cluster capacity calculation.
Cluster's Node Membership: Displays the nodes on which a cluster member can reside.
Cluster's Members: Displays the members of the cluster.
Cluster's Placements: Displays the current placements of the cluster.
By comparing the first DCPC400 message, which is the application placement controller input, to the second DCPC400 message, which is the application placement controller output, you can determine that the application placement controller started instances of the dc1 dynamic cluster on the elara11Node02 node and the elara11Node01 node. This conclusion was determined from the following data:

From the Cluster's properties value in the first message, the minimum and maximum number of cluster instances is set to 2.
From the Cluster's placements value on the first message, you can conclude that no instances are running. Because no instances are running, a breach of the minimum and maximum number of cluster instances has occurred. As a result, two instances are started.
From the Cluster's placements value on the second message, you can see that two instances were started: one instance on the elara11Node1 node and one instance on the elara11Node2 node. The instance names are in the format of node_name/server_name.

Related tasks

Configure dynamic application placement

Related reference

Administrative roles and privileges
Application placement custom properties