Configuring advanced options for cluster classic virtual system patterns

You can configure advanced options for cluster classic virtual system patterns.

1. Define clusters.
   Use this option to configure the number of clusters and application servers on the deployment manager part. You can configure messaging, session persistence, and global security.
   Using the define clusters option provides the following features, all of which you can change:

   • An application cluster with the default name prefix HVWebCluster
   • A default number of clusters
   • A default number of servers per node

   The server names are in the prefix + cluster index + node name + server index format, as shown in the following example:

   HVWebCluster_1_myNode_1

2. Enable messaging.
   Use this operation to perform additional message engine configuration on the deployment manager part. Messaging engines point to WebSphere® Derby on the deployment manager. On the classic virtual system instance, start Derby or configure the deployment manager to use another database.

   Important: You must have the Define clusters option selected to work with messaging.

   For more information about advanced configuration for WebSphere Application Server clustered messaging engines or a sample authentication alias for databases, see the related links. Use the following options to configure messaging with the system:

   Standard messaging engine configuration

   When configuring the standard Java™ Message Service (JMS), the system provides the following functions:

   • An application cluster with the default name prefix HVMsgCluster (can be changed).
   • A default number of clusters (can be changed).
   • A default number of servers per node (can be changed).
   • A Service Integration Bus (SIBus), the name of which has the HVSIBUS prefix, is created for each message cluster.
   • A messaging engine (ME) is defined on each member of the cluster, because each message cluster is added to the SIBus.
   • A Derby Java Database Connectivity (JDBC) provider and Derby data source are defined for use by the messaging engine or engines defined. For more information about configuring advanced messages for databases, see the related links.
   • An example authentication alias provides configuration options for the messaging engine to a database other than Derby.
   • Activation in only one of the members as the messaging cluster members are started.

   Highly available messaging engine configuration

   Processed over standard Java Message Service (JMS) support, this option provides messaging engine failover. For high availability messaging WebSphere Application Server configuration, a messaging engine is running for each SIBus. The messaging engine can run in multiple application servers, specifically the other members of the messaging cluster. If the server in which it is currently running becomes unavailable, it is activated in another of the servers of the messaging cluster with which the messaging engine is associated. All messages are preserved because the messaging engine state is saved in Derby. Messaging engines are activated in different application servers. The advanced configuration scripts create both the appropriate schemas and the high availability group OneOfNPolicy core group policies for messaging engine election and activation.

   Note: Multiple messaging engines can run in an application server.

   Scalable messaging engine configuration

   Processed over standard Java Message Service (JMS) support, this option enables multiple messaging engines to run in a WebSphere Application Server SIBus at a time. Therefore, the message flows for the various JMS applications can be divided or partitioned across the different messaging engines. Scalable messaging provides a greater number of messages that are processed by the WebSphere Application Server JMS support and therefore a scalable implementation.

   The advanced configuration scripts create multiple messaging engines for the SIBus, specifically one for each member of each HVMsgCluster. The default is one cluster and two members. Then, multiple messaging engines are activated when HVMsgCluster members are started. The OneOfNPolicy core group policies are created for each messaging engine to ensure that the messaging engine maps correctly to cluster members.

   The appropriate schemas and high availability group policies for messaging engine election and activation are also created.

   Note: Multiple messaging engines can run in an application server.

   Highly available and scalable messaging engine configuration

   Provides multiple messaging engines to run in multiple cluster members for each SIBus. The provided scripts handle the schema definitions, core group policies, and message engine to member mappings. With this configuration, messaging traffic can be divided across multiple messaging engines. If an application server goes down, any messaging engines are activated in the remaining cluster members.

   Note: Multiple messaging engines can run in an application server.

   Enable MQ messaging

   In addition to these messaging options, the Enable MQ messaging option provides some of the traditional WebSphere MQ configuration options available with WebSphere Application Server. It provides additional WebSphere MQ link configuration on the deployment manager part.

   Note: Newer features in WebSphere Application Server that use WebSphere MQ as an external Java message service (JMS) provider are available. These features are based on how you create your JMS application resources. However, if your messaging application does not support this approach, the system provides features based on server configuration. For details, see the information about configuring JMS resources for WebSphere MQ messaging provider in the WebSphere Application Server Knowledge Center.

   The following options provide configuration for two servers:

   MQ link configuration

   Select the WebSphere MQ link configuration option to perform the following functions:

   • Create new transport chains for the WebSphere MQ link and associate them with each messaging engine. These transport chains are basic if no security exists or SSL if security is enabled.
   • Create the WebSphere MQ link
   • Create the foreign bus and associate it with the WebSphere MQ link

   When defining the WebSphere MQ link there are items that use WebSphere MQ configuration attributes. You must adjust these attributes, for example the sample host, port, and user IDs, to reflect your actual WebSphere MQ environment.

   MQ server configuration

   Select the WebSphere MQ server configuration option to perform the following functions:

   • Create new transport chains for the WebSphere MQ server and associate them with each messaging engine. These transport chains are basic if no security exists or SSL if security is enabled.
   • Create the WebSphere MQ server
   • Add the WebSphere MQ server to the SIBuses

   When defining the WebSphere MQ server there are items that use WebSphere MQ configuration attributes. You must adjust these attributes, for example the sample host, port, virtual queue manager name, and user IDs, to reflect your actual WebSphere MQ environment.

3. Enable session persistence.
   HVWebCluster or application clusters are created with associated replication domains. Therefore, you can use the hyper text transfer protocol (HTTP) session replication. If the replication domain is defined, no resources are created or used unless session replication is configured. You can use the Enable session persistence option and then one of the following options to use HTTP session persistence:

   Memory-memory implemented session persistence

   The HTTP session memory bit is set on all the HVWebCluster servers.

   Database implemented session persistence

   On the classic virtual system instance, the JDBC data source created must be updated on the deployment manager with valid host, port, user name, and password values. The appropriate client drivers for your database, for example .jar and library files, must be installed on your WebSphere systems.

   To use this option on the classic virtual system instance, the JDBC data source created must be updated on the deployment manager. JDBC data source must have valid host, port, user name, and password values. The appropriate client drivers for your database, for example .jar and library files, must be installed on your WebSphere Application Server systems. Cloud Pak System Software for Power® performs the following operations:

   • Creates a DB2® JDBC provider
   • Creates a sample DB2 data source, with dummy values for the host, port, ID, and password
   • Sets up a session manager on each HVWebCluster server to do HTTP session to the database, by using the sample data source and dummy connection values

   For information about supplying a database that an HTTP session over the database supports with session persistence, see the related links.

4. Enable global security:
   • Set the global security admin bit.
   • Use the WIM user registry that is provided with the product.
   • Use both LTPA and BasicAuth for authentication (BasicAuth is needed for stand alone clients).
   • Use an SSL-allowed policy for CSIv2.
   • Turn off single signon interoperability.
   • Configure secure file transfer between the deployment manager and the node agents.
   • Use the high availability manager for the secure DCS channel.

   Using global security provides the option to use secure messaging. Use secure messaging to perform the following function:

   • Set the security bit on the SIBus.
   • Reduce the set of users that can connect to the SIBus. Only the WebSphere Application Server ID created with the CB UI can connect. The default value for that ID is virtuser.
   • Disable the InboundBasicMessaging transport for the messaging engines.
   • Add the virtuser ID to the sender role for foreign buses for MQLink configurations.