Linux application development: create WebSphere (3)

Article title: Linux Application Development fuel: create WebSphere (3 ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
In step 2, create a clone named clone1 on node TP2. Set the weight to 2 and select Generate Unique Http Ports and Create Replication Entry in this Server. Use the default application server template and click Apply.
　　
　　 Figure 17. create a new cluster server
　　 　
Repeat step 2 to create a clone named clone2 on node TP2. Set the weight to 2 and select Generate Unique Http Ports and Create Replication Entry in this Server. Use the default application server template and click Apply.
　　
Repeat step 2 again and create a clone named clone3 on node TP2. Set the weight to 4 and select Generate Unique Http Ports and Create Replication Entry in this Server. Use the default application server template and click Next.
　　
Check the summary to confirm that three clones with correct attributes exist in the cluster. Click Finish to save the changes.
　　
During the cluster creation process, you have created a Replication Domain for the cluster, which can be used to copy http sessions between clones to support failover. Therefore, you need to configure the application server clone1 and clone2 to use this service. On the Administrative Console, choose Application Servers> clone1> Web Container> Session Management> Distributed Environment Settings. Select Memory to Memory Replication. Repeat this process to set clone2.
　　
Now you have created a cluster definition. The next step is to install an enterprise application. In this exercise, ultapplication. ear is located in the/installableApps directory installed by WebSphere Application Server. Use the Deployment Manager Administrative Console to install the application. The process of installing an enterprise application to a cluster is the same as that of installing it on an independent application server. only one exception is that in the "map a module to an application server" step, you must select cluster1 for all modules. See the example in Figure 18 below. (The detailed installation steps for enterprise applications are not included in this article .)
　　
　　 Figure 18. map a module to an application server
　　 　
During cluster setup, each of the three clones uses a unique HTTP port. This means that the HTTP listener of the internal server running in each application has a specific value. The algorithm used by the management process to create a new port. use the default value (HTTP transmission uses 9080) for each defined new server and increment it to the next unused value.
　　
In this example, after you have installed WebSphere Application Server, an independent Server named server1 is created. When this node is added to the Deployment Manager, server1 will also be migrated to the hosted server. Server 1 uses port 9080 for HTTP transmission. On TP2, the created clone1 uses port 9081, and clone2 uses port 9082. When DefaultApplication. ear is installed, the Web module uses the default_host virtual host. By default, default_host only accepts requests from Port 9080. Therefore, you need to configure this VM so that it can accept requests from Port 9081 and Port 9082.
　　
In the Administrative Console, Environment> Virtual Hosts> default_host> Host Aliases is used to add additional port support for the default Host. Click New to add a New alias. Use * as the host name (* represents any host name) and 9081 as the Port value. Repeat this process to set Port 9082, as shown in Figure 19.
　　
　　 Figure 19. Additional port of default_host
　　 　
Make sure that Synchronize changes with Nodes has been selected and save the configuration.
　　
Now that you have installed an application in the cluster, test it. There are three types of processes in our runtime: Deployment Manager, Node Agent, and Application Server. Each of them is an independent system-level Java process.
　　
You can use the Administrative Console of Deployment Manager to start or stop a cluster. Before that, each Node must be running the Node Agent. You can use the commands in Table 1 to control the Deployment Manager and Node Agent installed.
　　
Table 1. commands for controlling Deployment Manager and Node Agent
　　 　
From the previous execution of the addNode command, the Node Agent should still be running. In the Administrative Console, use System Administration> Node Agent to check whether the Node Agent of TP1 and TP2 is running. Then, check the status of the nodes TP1 and TP2. If the Node Agent on one of the computers is unavailable, start it on the command line of that computer. After all Node agents are started, you can start the cluster through the Administrative Console, as shown in Figure 20. Depending on your hardware configuration, the startup process may take several minutes.
　　
　　 Figure 20. start a cluster
　　 　
Before testing workload management, it is necessary to check whether each clone is working separately. Open a browser and access the following URL:
　　
Http: // tp2: 9081/hello-check whether clone1 is working.
Http: // tp2: 9082/hello-View clone2.
Http: // tp1: 9081/hello-View clone3.
　　 Figure 21. confirm that the server is running
　　 　
If the three URLs return the results shown in Figure 21, all servers in the cluster are working and the ports used are correct. Close your browser.
　　
　　 Test workload management
The HTTP server plug-in manages the workload of Web applications. The ibm http Server is also installed when WebSphere Application Server is installed on TP1. By default, the plug-in uses the plugin-cfg.xml profile under the/opt/WebSphere/AppServer/config/cells directory. Use Environment> Update Web Server Plugin in the Administrative Console to generate plug-in configurations.
　　
The files generated by the Administrative Console are stored in the/opt/WebSphere/DeploymentManager/config/cells directory. Therefore, you need to manually copy the generated file to a directory that can be found by the HTTP server plug-in, such as the/opt/WebSphere/AppServer/config/cells directory.
　　
Snoop servlet in DefaultApplication. ear is suitable for testing workloads. It displays the name of the process used to execute the request. Open a browser and enter this URL: http: // tp1/snoop (the ibm http server is installed on TP1 ).
　　
　　 Figure 22. Test workload
　　
Refresh your browser several times to check the clone execution request. You should get a sequence of 1233 and 1233, which reflects the relative weight specified during cloning configuration.
　　
Note: If you always see the same clone id, close the browser and re-open it. In this way, the cookie used by WebSphere Application Server for session affinity can be deleted.