David Currie

I thought I’d post a few notes based on some experiences installing a network deployment environment of WebSphere ESB Version 6.1.

Version 6.1 introduced the idea of a deployment environment pattern which defines the functions that particular servers should take in a topology. These functions are the application (module) deployment target, supporting infrastructure (e.g. CEI server) and messaging infrastructure (application, system and CEI bus messaging engines). Three different deployment environment patterns are provided out of the box: single cluster, remote messaging, and remote messaging and remote support. In the last of these patterns there are three clusters, one for each function, to give maximum scalability. In the remote messaging pattern, the application and support target roles are combined in to one cluster with the messaging engines running in another. Single cluster, as the name suggests, combines all three roles in to a single cluster which, whilst simplest to configure, is only suitable for modules using synchronous communication. Fortunately this was all that was needed in the scenario that we were setting up.

The first installation and creation of the deployment manager profile went smoothly as did the addition of the latest critical fixes. However, when creating the first managed node, the profile creation failed due to lack of synchronization with the clock on the deployment manger box. (In fact, both showed the same time but one was on EST and the other on CET.) So, my first tip is to ensure that system clocks are synchronized across all of the nodes before you begin installation! They must be within five minutes of each other.

It was at this point that we discovered that the graphical profile management tool is not supported on the platform that we were using, or in fact, any of the 64 bit platforms (except i5/OS) or Linux for zSeries. The fact that there weren’t any binaries in the ProfileManagement directory was a big hint here! Now, the tool simply provides a graphical interface on to the manageprofiles command but, as you’ll see from the InfoCenter, this has a myriad of options. We therefore found it very useful to go through the creation steps with the GUI in a 32 bit VMware image that I had and then take a look at the <profile_name>_create.log file in the logs/manageprofiles directory. Here you’ll find an entry for the invokeWSProfile method that lists the parameters the GUI passed. For example, the following entry resulted from the creation of a deployment manager profile. You can see that it specifies that the CondensedSync topology pattern should be used which is the single cluster version.

<record>
<date>2008-01-22T08:52:12</date>
<millis>1200991932951</millis>
<sequence>15910</sequence>
<logger>com.ibm.wsspi.profile.WSProfileCLI</logger>
<level>INFO</level>
<class>com.ibm.wsspi.profile.WSProfileCLI</class>
<method>invokeWSProfile</method>
<thread>10</thread>
<message>Incoming command line is: { “-create” ,”-dbServerPort” ,”1527″ ,”-templatePath” ,”/home/wesb/61/profileTemplates/dmgr.esbserver” ,”-profileName” ,”Dmgr03″ ,”-dbDelayConfig” ,”false” ,”-dbType” ,”DERBY_NETWORKSERVER” ,”-dbCommonForME” ,”false” ,”-dbHostName” ,”localhost” ,”-hostName” ,”localhost” ,”-enableAdminSecurity” ,”true” ,”-adminPassword” ,”****************” ,”-dbName” ,”WPRCSDB” ,”-dbPassword” ,”****************” ,”-portsFile” ,”/home/wesb/61/logs/manageprofiles/_portdef.props” ,”-ndtopology” ,”true” ,”-cellName” ,”wesbcell” ,”-nodeName” ,”dmgrnode” ,”-dbUserId” ,”derbyuser” ,”-dbCreateNew” ,”true” ,”-adminUserName” ,”wsadmin” ,”-profilePath” ,”/home/wesb/61/profiles/Dmgr03″ ,”-topologyPattern” ,”CondensedSync” }</message>
</record>
<record>
<date>2008-01-22T08:52:12</date>
<millis>1200991932981</millis>
<sequence>15911</sequence>
<logger>com.ibm.ws.profile.cli.WSProfileCLIModeInvoker</logger>
<level>INFO</level>
<class>com.ibm.ws.profile.cli.WSProfileCLIModeInvoker</class>
<method>getArgumentValue</method>
<thread>10</thread>
<message>templatePath was resolved to /home/wesb/61/profileTemplates/dmgr.esbserver</message>
</record>

As the eagle eyed will notice, the profile was created to use Network Derby as the database. This was not a production environment nor were we actually intending to use CEI, database logging or asynchronous messaging. This was the first time I’d used Network Derby though and it took me a while to realise that you need to start it manually using the startNetworkServer command in the derby/bin/networkServer directory and, more importantly, that you need to specify the -h option to enable connections from outside of localhost. A value of 0.0.0.0 will permit connections from any server.

This entry was posted on Thursday, January 24th, 2008 at 9:15 pm and is filed under WebSphere ESB. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.