Rapid build and sample usage of a large Liberty server collection

The Liberty aggregates are IBM http://www.aliyun.com/zixun/aggregation/13387.html ">websphere creator that can be configured as part of the same admin domain Server Liberty set of servers. The configuration and state data of the Liberty set are stored in an active operational repository. The Liberty server joins a set by registering with the aggregate controller. These members share their information through the controller's operational repository. Figure 1 shows an example.

Figure 1. Sample collection body (1 to N members)

In addition to building the collection body, you can define the Liberty cluster by specifying the Clustermember attribute in the Server.xml file:

<clustermember name= "Myclusterx"/>

There are many benefits to building a Liberty collection to manage Liberty server collections. Create an administrative control point using a set of clusters to perform server management, cluster management, file transfer, and access to MBean operations. You can perform many operations from a single management point, including:

start and stop the Liberty server. Start and stop the Liberty cluster. Distribute files to Liberty servers or Liberty clusters (this is useful for updating server configurations or application installations). Build the WEB server plug-in. Query collection body member statistics, such as heap and JVM information.

Building and managing a large, highly available set of aggregates

The aggregate controller can be configured as a highly available replica set. The aggregate controllers that belong to the same replica set synchronize their repository information so that the other aggregate controllers in the replica set can continue to accept and process the workload if they are down on any control of the collection body.

The replica set must have at least 3 set-fit controllers to meet the legal number and take advantage of the highly available features of the collection.

To complete the configuration of a replica set, you need to perform the following steps:

IBM WebSphere creator Server Liberty receptacle deployment V8.5.5 Jython client

To manually configure a replica set:

installs the WebSphere creator Server Liberty receptacle deployment. Use this command to create a server:

Server Create <controller name>

uses this aggregate command to convert the Liberty server to a single aggregate controller:

Collective Create <controller name>--keystorepassword=<keystore password>

This aggregate controller will be called the initial controller.

displays a set of output at this time. Copy this output to the Server.xml file of the newly created controller. The exact location may vary, but it is usually located under [Liberty_root]/usr/servers/&lt;server name&gt;. Issue the following command to start the initial controller:

Server Start <controller name>

on another system, deploy the Liberty and issue the following command to create another collection controller:

Server Create <controller name>

If you run this command on the same system, you need to provide a different name than the original controller.

runs the replicate command on the second aggregate controller, for example:

Collective replicate <controller name>--Host=<hostname of initial-controller>--port=<ssl port of initial Controller>--user=<user name of security tabbed in the initial controller>--password=<password of user name Tabbed in the initial controller>--keystorepassword=<keystore password initial

copies and pastes the output of the replicate command into the Server.xml file of the second set-fit controller. Repeat step 6th to 8th on the 3rd controller. On a different machine with Jython installed, download the updaterepositoryconfig.py sample script provided in the Wasdev community. If the Jython client and the initial controller are not on the same system, place the KeyStore from the initial controller in a location that is accessible to Jython clients. Run this command to use the initial controller as the target:

./jython updaterepositoryconfig.py Add––truststore=<path to the trust store of initial controller>-- Truststorepassword=<truststore Password of Initial controller>––host=<hostname of Initial- Port=<ssl Port of initial controller>--user=<user name of security tabbed in the initial controller>-- Password=<password of user tabbed in the initial controller>--endpoint=<hostname and replica port of second Controller>--debug

For example, the actual command might look like this:

./jython updaterepositoryconfig.py Add–truststore=key.jks--truststorepassword=management––host= initialcontroller.ibm.com--port=9443--user=adminuser--password=adminpassword--endpoint=secondcontroller.ibm.com:10010--debug

Repeat step 12th, using the third controller as the endpoint host name.