Cluster member settings
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. Use wsadmin commands to modify the cluster member template, or we can click Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members > Templates. Any change that we make to the template does not affect existing cluster members.
From the admin console, 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 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 that are directed to the application server. Even though we specify a value of 0 to 20 as the weight of a server, the weight that is 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.
- For HTTP requests, weights are used to distribute HTTP traffic between the web server plug-in and the controller handling the clustered application server. Assign a higher weight value to the application server that should receive the HTTP traffic.
- For web services calls, information is transferred from a servant in one application server to a controller in another application server. The application server that receives the call has the highest weight value.
- Weight has no affect on Internet Inter-ORB Protocol (IIOP) requests. IIOP requests are distributed to the correct application server using the sysplex distributor.
Information Value Data type Integer Range 0 to 20
Unique ID
Nameumerical identifier for the application server that is unique within the cluster. The ID is used for affinity.
Information Value Data type Integer (ZOS) Data type (ZOS) Hexadecimal
(ZOS) Short name
Short name for this cluster member. This field only displays if we 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:
- Must be one to eight characters in length. By default, when we are running the product on z/OS, the product assumes we are using a 7-character server short name (JOBNAME). If our naming standards require 8 characters, we can lengthen the 7-character server short name to 8 characters.
- Must contain only uppercase alphanumeric characters
- Cannot start with a number.
- Must be unique in the cell.
- Cannot be the same as the value specified on the ClusterTransitionName custom property of any non-clustered server. Do not specify a cluster transition name for a server that is part of a cluster.
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 your 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 running in v6.0 and or higher cells.
(iSeries) This option is not supported in an IBM i environment.
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
Specifies whether to start the server on multiple threads. When we 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 administrative 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 needed by an application running on this cluster member.
When this property is selected, cluster member components are dynamically started as needed. When 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.
Starting components as needed is most effective if all of the applications, 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 JavaServer Pages (JSP). This option works less effectively if the applications use servlets, JSPs and EJB.
To ensure compatibility with other WebSphere products, the default setting for this option is deselected. Before selecting this option, verify any other WebSphere products, that we are running in conjunction with this product, support this functionality.
(ZOS) Run in 64 bit JVM mode
That 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 we are running on z/OS.
Access to internal server classes
Specifies whether the applications 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, we 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
Specifies whether there is a single class loader that loads all of the applications, or a different class loader loads each application.
Class loading mode
Specifies 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 we 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:
Clusters and workload management Add members to a cluster Configure application startup Modifying cluster member templates Cluster member collection