+

Search Tips   |   Advanced Search

Cluster member settings

Use this page to manage the members of a cluster. A cluster of application servers are managed together and participate in workload management.

A copy of the first cluster member that we create is stored as part of the cluster data and becomes the template for all additional cluster members that we create.

Any individual configuration change that we make to a cluster member does not affect the configuration settings of the cluster member template. We can use wsadmin commands to modify the cluster member template, or we can click Servers > Clusters > WebSphere application server clusters > cluster_name > Clusters members > Templates. Any change that we make to the template does not affect existing cluster members. To view this console page, click Servers > Clusters > WebSphere application server clusters > cluster_name.

On the Configuration tab, we can edit fields. We can also click Installed applications. to view the status of applications that are running on this server. On the Runtime tab, which only appears when the cluster member is running, we can look at information about this cluster member. However, the information that displays on this page is read-only. We must return to the Configuration tab to change any of the settings that display.


Member name

Name of the application server in the cluster. On most platforms, the name of the server is the process name. The member name must match the name of one of the servers listed on the application servers page.


Node name

Name of the node on which the cluster member is running.


Weight

Controls the number of requests directed to the application server. Even though specified a value of 0 to 20 as the weight of a server, the weight assigned to the server is a proportion, in which, the weight assigned to the server is the numerator, and the sum of the weights of all members of the cluster is the denominator.

When we add a new member to a cluster, the number of client, or application requests sent to each server in the cluster decreases, assuming the number of requests coming into the cluster stays the same. Similarly when you remove a new member from a cluster, the number of client or application requests sent to each server in the cluster increases, assuming the number of requests coming into the cluster stays the same.

For example, if we have a cluster that consists of members A, B, and C with weights 2, 3, and 4, respectively, then 2/9 of the requests are assigned to member A, 3/9 are assigned to member B, and 4/9 are assigned to member C. If a new member, member D, is added to the cluster and member D has a weight of 5, then member A now gets 2/14 of the requests, member B gets 3/14 of the requests, member C gets 4/14 of the requests, and member D gets 5/14 of the requests.

(zos) On z/OS , weight is used to balance some of the workload types, but others are balanced by the z/OS system.

Information Value
Data type Integer
Range 0 to 20


Unique ID

Numerical identifier for the application server that is unique within the cluster. The ID is used for affinity.

Information Value
(dist)(iseries) Data type (dist)(iseries) Integer
(zos) Data type (zos) Hexadecimal


(zos) Short name

Short name for this cluster member. This field only displays if you are running on z/OS.

The short name is the default z/OS job name and identifies the cluster member to the native facilities of the operating system, such as Workload Manager (WLM), Automatic Restart Manager, SAF (for example, RACF ), started task control, and others.

If we specify a short name for a cluster member, the name:

If we do not specify a short name, the system assigns a default short name that is automatically unique within the cell. We can change the generated short name to conform with the naming conventions.

Information Value
Data type String


Run in development mode

Enable this option may reduce the startup time of an application server. This might include JVM settings, such as disabling bytecode verification and reducing Just in Time (JIT) compiler compilation costs. Do not enable this setting on production servers. This setting is only available on application servers that are running in Version 6.0 and or higher cells.

(iseries) This option is not supported in an IBM i environment.

Specifies to use the JVM settings, -Xverify and -Xquickstart, on startup. After selecting this option, save the configuration and restart the server to activate development mode.

The default setting for this option is false, which indicates that the server is not started in development mode. Setting this option to true specifies that the server is started in development mode, using settings that decrease server startup time.

Information Value
Data type Boolean
Default false


Parallel start

Whether to start the server on multiple threads. When you start the server on multiple threads, the server components, services, and applications start in parallel rather than sequentially, which might shorten the startup time.

The default setting for this option is true, which indicates that the server uses multiple threads when it starts. Setting this option to false specifies that the server uses a single thread when it starts, which might lengthen startup time.

The order in which applications start depends on the weight we assign to each application. The application with the lowest starting weight starts first. Applications with the same starting weight start in parallel. Use the Starting weight field on the Applications > Application Types > WebSphere enterprise applications > application_name > Startup behavior page of the console to set the starting weight for an application.

Information Value
Data type Boolean
Default true


Start components as needed

Select this field if we want the cluster member components started as they are needed by an application running on this cluster member.

When this property is selected, cluster member components are dynamically started as they are needed. When this property is not selected, all of the cluster member components are started during the cluster startup process. Therefore, selecting this option can improve startup time, and reduce the memory footprint of the cluster members, because fewer components are started during the startup process.

Start components as they are needed is most effective if all of the applications, that are deployed on the cluster, are of the same type. For example, using this option works better if all of the applications are web applications that use servlets, and JSP (JSP). This option works less effectively if the applications use servlets, JSPs and EJB.

Avoid trouble: To ensure compatibility with other WebSphere products, the default setting for this option is deselected. Before selecting this option, verify that any other WebSphere products, that you are running in conjunction with this product, support this functionality.gotcha


(zos) Run in 64 bit JVM mode

The application server runs in 64-bit mode, which is the default setting. Running in 64-bit mode provides additional virtual storage for user applications. This field only displays if you are running on z/OS.

We can deselect this setting if we need to run the application server in 31-bit mode.

There is no interdependence between the modes in which we are running different servers. Therefore, we can run some of the servers in 64-bit mode and some of the servers in 31-bit mode. However, you should eventually convert all of the servers to run in 64-bit mode because support for running servers in 31-bit mode is deprecated.


Access to internal server classes

Whether the applications that are running on this server can access many of the server implementation classes.

If we select Allow, then, applications can access most of the server implementation classes. If we select Restrict, then applications cannot access server implementation classes. The applications get a ClassNotFoundException error if they attempt to access these classes.

Usually, you should select Restrict for this property, because most applications use the supported APIs, and do not need to access any of the internal classes. However, if the application requires the use of one or more of the internal server classes, then select Allow as the value for this property.

The default value for this property is Allow.


Class loader policy

Whether there is a single class loader that loads all of the applications, or a different class loader loads each application.


Class loading mode

Whether the class loader searches in the parent class loader, or in the application class loader first to load a class. The standard for Developer Kit class loaders and product class loaders is Classes loaded with parent class loader first.

This field only applies if set the Class loader policy field to Single.

If we select Classes loaded with local class loader first (parent last), the application can override classes contained in the parent class loader, but this action can potentially result in ClassCastException, or linkage errors, if we have mixed use of overridden classes and non-overridden classes.


Process ID

Native operating system process ID for this server.

The process ID property is read only. The system automatically generates the value.


Cell name

Name of the cell in which this server is running.

The Cell name property is read only.


Node name

Name of the node in which this server is running.

The Node name property is read only.


State

Runtime state for this server.

The State property is read only.


Related concepts

  • Clusters and workload management


    Related tasks

  • Add members to a cluster
  • Configure application startup
  • Modify cluster member templates