High Availability for WebSphere Message Broker V6.1 using Microsoft Cluster Service (MSCS) on Windows

(1)

High Availability

for WebSphere Message Broker V6.1

using Microsoft Cluster Service (MSCS)

on Windows

A step by step guide to install, apply fix packs and configure

WebSphere Message Broker V6.1 with its subcomponents

WebSphere MQ V6.0 and DB2 V9.1 for high availability on Windows

Server platform using Microsoft Cluster Service (MSCS)

If you are using a business-critical software product you must always

consider the availability requirement to avoid any interruption in the

presence of a failure, crash or disaster. High availability can be

achieved by clustering the servers to enable applications to be

distributed across and moved between these servers which are

generally controlled by cluster software. By using WebSphere

Message Broker, WebSphere MQ, DB2 and Microsoft Cluster Service

(MSCS) together, it is possible to further enhance the availability of a

WebSphere

Message

Broker

system

in

Windows

Server

environments.

Arden Agopyan

Software IT Specialist, IBM CEEMEA [email protected]

Ali Beklen

Software IT Architect, IBM Turkey [email protected]

(2)

Authors

Arden Agopyan, Software IT Specialist, IBM CEEMEA [email protected], http://www.ardenagopyan.com Arden Agopyan is a WebSphere Application Infrastructure Community of Practice working for IBM Central & Eastern Europe, Middle East & Africa (CEEMEA). He is experienced on planning, design, implementation, and problem

determination of WebSphere Infrastructure and Integration solutions. Arden holds a Computer Engineer degree from Galatasaray University in Istanbul (Turkey).

Ali Beklen, Software IT Architect, IBM Turkey [email protected], http://www.alibeklen.com

Ali Beklen is a Software IT Architect working for IBM Turkey. He is experienced on designing integration solutions and he is Open Group Certified IT Specialist on collaboration

solutions. Ali holds a Master of Computer Engineer degree from Maltepe University in Istanbul (Turkey).

(3)

Section 1. Before you start

If you are using a business-critical software product you must always consider the availability requirement to avoid any interruption in the presence of a failure, crash or disaster.

High availability can be achieved by clustering the servers to enable applications to be distributed across and moved between these servers which are generally controlled by cluster software.

WebSphere Message Broker (WMB) provides services based on message brokers to route, transform, store, modify and publish messages from WebSphere MQ and other transports. WebSphere Message Broker can store its broker and configuration data in databases like DB2.

Microsoft Cluster Service (MSCS) is software designed to allow servers to be clustered in a Windows Server environment.

By using WebSphere Message Broker, WebSphere MQ, DB2 and Microsoft Cluster Service (MSCS) together, it is possible to further enhance the availability of a WebSphere Message Broker system in Windows Server environments.

Objectives

In this complete step-by-step tutorial, learn how to:

• Install software:

o_{WebSphere Message Broker V6.1} o_{WebSphere MQ V6.0}

(4)

• Apply fix packs:

o_{WebSphere Message Broker V6.1.0.3} o_{WebSphere MQ V6.0.2.6}

o_{DB2 Enterprise Server Edition V9.1 Fix Pack 7}

• Configure high availability for WebSphere Message Broker V6.1 and its subcomponents WebSphere MQ V6.0 and DB2 V9.1 on Windows Server 2003 platform using Microsoft Cluster Service (MSCS).

Prerequisites

This tutorial assumes that you’re installing and implementing the high availability configuration on Windows Server 2003 platform and on a cluster which contains two server nodes.

This tutorial requires intermediate level WebSphere Message Broker, WebSphere MQ, DB2 and Windows Server administration knowledge.

System Requirements

To implement this tutorial’s high availability scenario, you will need to install required software and apply fix packs.

Required software:

• WebSphere Message Broker V6.1 • WebSphere MQ V6.0

• DB2 Enterprise Server Edition V9.1 Required fix packs:

• WebSphere Message Broker V6.1.0.3 (or above) • WebSphere MQ V6.0.2.6 (or above)

(5)

• DB2 Enterprise Server Edition V9.1 Fix Pack 7 (or above)

This tutorial assumes that you have already made the following configurations: • Installations of Windows Server 2003 to your server nodes and their basic

configurations. Both nodes must be identically configured with the same operating system levels, patches and fix packs.

• Creation of an administrative user in the domain. This user will have all privileges in cluster, domain, broker and DB2 user groups. For this user, we will use following credentials in our tutorial:

o_{Username: wmbadmin} o_{Password: password}

Warning: This username must not exceed eight characters long.

• Installation and initial configuration of Microsoft Cluster Service (MSCS): o_{Create a cluster named “SAW-ESBCLS” on MSCS.}

o_{Add two nodes named “SAW-ESB1” and “SAW-ESB2” respectively.} o_{Create a Cluster Group containing following resources:}

Name Resource Type Description

Cluster IP Address IP Address IP address of your cluster for administration purposes.

This IP address must be different from WebSphere Message Broker cluster IP address that we will assign later.

Cluster Name Network Name Name for the cluster.

Disk E: Physical Disk A shared disk to store WebSphere MQ data.

Disk F: Physical Disk A shared disk to store DB2 data. Disk Q: Physical Disk Quorum1 disk drive.

Table 1.1 Cluster resources

1_{The quorum disk is used to store cluster configuration database checkpoints and log files that help manage}

(6)

Figure 1.1 Cluster Group with required resources

For more information on setting up a cluster with Microsoft Cluster Service see the following article: “Step-by-Step Guide to Installing Cluster Service” (Microsoft TechNet)

You also need to have WebSphere Message Broker Toolkit V6.1.0.3 Interim Fix 003 or above installed in a separate machine to test connectivity from the development environment and to deploy message flows to the clustered broker system implemented in this tutorial,

Section 2. Tutorial scenario

A cold-standby configuration is the most basic cluster configuration in which one server node performs work while the other server node acts only as standby. The standby node does not perform work and is referred to as idle. The cluster software detects that there is a problem with the active node which can be a hardware or software problem. In this case, the cluster software will:

• Take over the virtual IP address and the shared disks, and move them to the standby machine.

(7)

listener, trigger monitors), and also the database processes on the standby machine.

• Activate the standby machine.

In this tutorial we will configure WebSphere Message Broker, WebSphere MQ and DB2 with Microsoft Cluster Service (MSCS) to achieve the cold-standby configuration shown in Figure 1.2. This configuration is also known as active/passive configuration.

Clustering the Configuration Manager component of WebSphere Message Broker is generally not needed. In our tutorial, we assume that Configuration Manager will be located in a separate machine and will control the cluster. You can connect to this configuration manager from your development environment using WebSphere Message Broker Toolkit.

Hint: If you don’t want to install the Configuration Manager to a separate machine and you want it clustered, you can create a configuration manager configuration in the clustered nodes. In this case you will have to add the queue manager associated with that configuration manager to the cluster. For detailed information, you can see the documents in the Resources section of this tutorial.

(8)

Figure 2.1 Tutorial scenario architecture

Section 3. Installing required software

We will start by installing required software to accomplish our target scenario.

You have to repeat following installation steps in both server nodes (active and standby nodes) of the cluster to create “clone” servers. Software products should be installed into the same directories on each of the nodes.

For the configuration manager machine, you don’t need to install DB2 Enterprise Server. You will only have to install WebSphere Message Broker and WebSphere MQ binaries.

Warning: We will not put any data onto shared disks during the initial installations.

(9)

To install WebSphere Message Broker and its subcomponents:

• Go to the WebSphere Message Broker setup folder. To start the installation, run the launchpad:

o_{\messagebroker_runtime1\mqsilaunchpad.exe}

• In the Express Installation screen, uncheck “WebSphere Message Broker Toolkit, V6.1” because the toolkit must be installed in a separate (development) machine.

Figure 3.1 – Installing WebSphere Message Broker and its subcomponents

(10)

Figure 3.2 – Installing WebSphere Message Broker and its subcomponents

• The wizard will start with the installation of IBM WebSphere Eclipse Platform and will continue by the installations of WebSphere MQ, DB2 Run-Time Client without requiring any other input.

(11)

Figure 3.4 – Installing WebSphere MQ

Figure 3.5 – Installing DB2 Run-Time Client

• In the WebSphere Message Broker 6.1 Installer welcome screen, click “Next”.

(12)

Figure 3.6 – Installing WebSphere Message Broker - Step 1

• Accept the license agreement and click “Next”.

(13)

• Type “C:\WMB” for the installation Directory Name and click “Next”.

(14)

• To start the installation, click “Next”.

(15)

• Do not check the option to launch a command console and click “Next”.

(16)

Figure 3.13 – Completing WebSphere Message Broker installation

• Check in the launchpad that the first four components are installed.

(17)

Attention: You don’t need to perform the steps below for the Configuration Manager machine.

• As we will use DB2 Enterprise Server, before continue, we have to uninstall the DB2 Run-Time Client. Go to the “Add or Remove Programs” section of Windows Server, find the title “DB2 Run-Time Client” and under this title click “Remove”.

o_{Hint: To open the “Add or Remove Programs” section go to “Start} Menu > Run…”, type “appwiz.cpl” and click “OK”.

Figure 3.15 – Uninstalling DB2 Run-Time Client

• In the launchpad screen, go to the “Advanced Installation” tab, find and expand the “DB2 Enterprise Server Edition” installation option and click “Install DB2 Enterprise Server Edition”.

(18)

Figure 3.16 – Installing DB2 Enterprise Server Edition – Step 1

• In the DB2 Setup wizard welcome screen, click “Next”.

(19)

(20)

• Select the third option to save your installation settings in a response file for a later use. Click “Next”.

(21)

• Leave the directory path as default Click “Next”.

(22)

• Type “DB2COPY1” for DB2 Copy Name and click “Next”.

(23)

• Leave the location of the DB2 Information Center on the IBM Web site and click “Next”.

• In the user information screen, type the WMB Administrator user credentials for DB2 Administration Server user.

o_{Domain: your.domain.com} o_{User name: wmbadmin} o_{Password: password}

Warning: If your domain is not listed in the “Domain” dropdown list or if DB2 installation wizard doesn’t recognize your domain, you can type a local user’s credentials in the “Domain” field. In this case, when you finish the installation, you will have to move the ownership of all DB2 and DB2 Administration Server Windows services to your domain user.

(24)

• Select “Create the default DB2 instance” and click “Next”.

(25)

• In the instance configuration screen, to accept the default settings, click “Next”.

(26)

• Do not check “Set up your DB2 server to send notifications” option and click “Next”.

(27)

• Check the “Enable operating system security” option and click “Next”.

• You will get a warning indicating the existence of DB2 administrators and users groups because they were created by DB2 Run-Time installation previously. Click “OK” to dismiss the warning.

(28)

• Review your settings and click “Finish” to start the installation.

(29)

Figure 3.33 – Completing DB2 Enterprise Server Edition installation

• Check in the launchpad that DB2 Enterprise Server Edition is installed.

(30)

• Check your system tray for DB2 and WebSphere MQ tray icons.

Figure 3.35 – Checking the system tray

• Right click to the WebSphere MQ system tray icon and select “WebSphere MQ”. Check that the software Version is 6.0.0.

Figure 3.36 – Checking WebSphere MQ

• Go to the “Services” section of Windows Server and check that all DB2 services are started successfully and owned by the user “wmbadmin”.

o_{Hint: To open the “Services” section go to “Start Menu > Run…”,} type “services.msc” and click “OK”.

(31)

Figure 3.37 – Checking DB2 services

Congratulations! You have successfully installed WebSphere Message Broker and its subcomponents.

Section 4. Applying fixes

As we correctly installed required software, it’s now time to apply latest fix packs.

Like the installation process, you have to repeat following steps in both server nodes (active and standby nodes) of the cluster.

For the configuration manager machine, you will only have to apply WebSphere Message Broker and WebSphere MQ fix packs.

Applying fix pack for WebSphere MQ

We will start by applying fix pack for WebSphere MQ.

Optional: If you are installing to a 64-bit (x64) platform, you have to install “Microsoft Visual C++ 2005 Redistributable Package (x64)” supplied with the fix pack installation files.

(32)

• To install Microsoft Visual C++ 2005 Redistributable Package (x64), go the directory containing fix pack installation files and run:

o_{vcredist_x64.exe}

• In the Microsoft Visual C++ 2005 Redistributable Package (x64) installation screen, to accept the license terms, click “Yes”.

Figure 4.1 – Installing Visual C++ 2005 RP for x64

• The wizard will install Microsoft Visual C++ 2005 Redistributable Package (x64) automatically.

(33)

• Go to the “Add or Remove Programs” section of Windows Server. Check that Microsoft Visual C++ 2005 Redistributable (x64) is installed correctly.

Figure 4.3 – Checking the installation of Visual C++ 2005 RP for x64

• Before starting WebSphere MQ fix pack installation, shut down all WebSphere MQ queue managers, related processes and also the system tray agent.

• To install WebSphere MQ fix pack V6.0.2.6 go the directory containing fix pack installation files and run:

o_{WebSphereMQMDV6.0.2.6EnUs.exe}

Warning: If you get an error indicating that some files are in use, you can start the installation wizard by entering the following command in the Windows Command Prompt:

o_{WebSphereMQMDV6.0.2.6EnUs.exe -a MQPINUSEOK=1}

(34)

Figure 4.4 – Installing fix pack for MQ – Step 1

• In the next screen, select the first option and click “Next”.

(35)

• WebSphere MQ installation wizard will check the process and the files. This may take a while.

• Accept the default Backup Folder and click “Install” to start the installation.

Figure 4.6 – Installing fix pack for MQ – Step 3

• Wait until the wizard finishes the installation and click “Finish”.

Figure 4.7 – Completing fix pack installation for MQ

• Go to the “Services” section of Windows Server and start the “IBM MQSeries” service.

(36)

Figure 4.8 – Starting MQ Service

• Open a Windows Command Prompt and run:

o_{C:\Program Files\IBM\WebSphere MQ\bin\dspmqver}

• Check that the WebSphere MQ Version is 6.0.2.6.

Figure 4.9 – Checking WebSphere MQ

Applying fix pack for WebSphere Message Broker

(37)

• Before starting WebSphere Message Broker fix pack installation, shut down all WebSphere Message Broker related processes.

• To install WebSphere Message Broker V6.1.0.3, run: o_{6.1.0-WS-MB-WINIA32-FP0003.exe}

Figure 4.10 – Installing fix pack for WebSphere Message Broker – Step 1

• In the WebSphere Message Broker 6.1 Installer welcome screen, click “Next”.

(38)

• Type “C:\WMB” for the installation Directory Name and click “Next”.

(39)

• To start the installation, click “Next”.

(40)

• Click “Finish” to exit the installation wizard.

(41)

Applying fix pack for DB2 Enterprise Server

Finally, we will apply fix pack for DB2 Enterprise Server.

• Before starting DB2 fix pack installation, shut down all DB2 related services and processes.

• Start the DB2 Setup Launchpad.

• In the launchpad, go to the “Install a Product” tab. Under “DB2 Enterprise Server Edition”, click “Install Now”.

Figure 4.17 – Starting fix pack installation for DB2

• Select “DB2COPY1” as the existing DB2 copy and click “Launch DB2 Setup wizard”.

(42)

Figure 4.18 – Installing fix pack for DB2 – Step 1

• In the DB2 Setup wizard welcome screen, click “Next”.

(43)

• The wizard will automatically install the fix pack. Click “Finish” to exit the wizard.

Figure 4.20 – Completing fix pack installation for DB2

• To avoid the operating system to reboot, click “No”.

Figure 4.21 – Completing fix pack installation for DB2

• Run a DB2 Command Window using the command: o_{C:\Program Files\IBM\SQLLIB\BIN\ DB2CW.bat}

• In the DB2 Command Window, run: o_db2level

(44)

• Check that the DB2 Fix Pack is “7”.

Figure 4.22 – Checking DB2

• Reboot your server for the changes to take effect.

Congratulations! You have successfully installed all required fix packs.

Section 5. Configuring components for high availability

In this section, we will configure Microsoft Cluster Service (MSCS), WebSphere MQ, DB2 Enterprise Server and WebSphere Message Broker for high availability.

Warning: Some configurations must be made in both nodes and some in only one of the nodes. These configurations will be indicated in the steps.

Configuring MSCS

We will start by creating a new Cluster resource group for WebSphere Message Broker and its related processes.

• Open Windows Cluster Administrator. Right click on “Groups” and select “New > Group”.

(45)

Figure 5.1 – Creating a new cluster group

• Open Windows Cluster Administrator. Right click on “Groups” and select “New > Group”. For group name, use “WMB Group”. Add your two server nodes as preferred owners and click “Finish” to create the group.

(46)

• Right click on “WMB Group” and select “New > Resource”.

Figure 5.3 – Creating the IP address

• Type “WMB IP Address” for the “Name” of the resource. Select “IP Address” as the “Resource Type” and “WMB Group” as the “Group”. Click “Next”.

(47)

• In the Possible Owners window, add all nodes in the cluster as the owners. Click “Next”.

(48)

• In the next screen, type the “IP Address” that you want to use for your WebSphere Message Broker cluster and its “Subnet mask”. Choose “PUBLIC” for the “Network”. Check the “Enable NetBIOS for this address” option and click “Finish”.

• Right click on “WMB Group” and select “New > Resource”.

• Type “WMB Network Name” for the “Name” of the resource. Select “Network Name” as the “Resource Type” and “WMB Group” as the “Group”. Click “Next”.

(49)

Figure 5.7 – Creating the network name

• Add “WMB IP Address” to the “Resource dependencies” and click “Next”. With this configuration, the Network Name will not be online until the IP Address is online.

(50)

• Type the name that you want to give to your WebSphere Message Broker in the “Name” field. In our example, we used “SAW-WMB”. Check “DNS Registration Must Succeed” and click “Finish”.

Figure 5.9 – Creating the network name

• Now we will move previously created resources to our new “WMB Group”. Open the “Cluster Group”. Right click on the shared disk “Disk E:” and select “Take Offline”. Repeat this procedure for “Disk F:”.

(51)

Figure 5.10 – Take Disk E: offline

Figure 5.11 – Take Disk F: offline

Figure 5.12 – Disk E: and Disk F: are offline

• Right click on the shared disk “Disk E:” and select “Properties”. Go to the “Dependencies” tab and click “Modify”.

(52)

Figure 5.13 – Modify properties

• Remove the “Cluster IP Address” dependency and click “OK”. Click “OK” in the “Disk E: Properties” window.

Figure 5.14 – Remove dependencies

• Repeat the same steps to remove the “Cluster IP Address” dependency from “Disk F:”

(53)

• Drag and drop “Disk E:” from “Cluster Group” to “WMB Group”. Click “Yes” to dismiss the “Move Resources” confirmation dialog.

Figure 5.15 – Move resources confirmation dialog

• Drag and drop “Disk F:” from “Cluster Group” to “WMB Group”. Click “Yes” to dismiss the “Move Resources” confirmation dialog.

Figure 5.16 – Move resources confirmation dialog

(54)

Figure 5.17 – Bring WMB Group online

• Check that all resources of the “WMB Group” are online.

Figure 5.18 – WMB Group online

• From the Windows Command Prompt, ping your network name to check its availability:

(55)

After creating these required resources, we can continue with the configurations of the installed components.

WebSphere MQ on MSCS

As the broker depends on a queue manager, this queue manager needs to be under MSCS control. In this step, we will configure WebSphere MQ to run with MSCS.

• Before starting, check that the user “wmbadmin” is in the “MQM” user group.

• We will now create a Queue Manager on the first node only. Open the WebSphere MQ Explorer. Right click on the Queue Managers and select “New > Queue Manager”.

Figure 5.19 – Creating an MQ queue manager – Step 1

• Type “BRK01_QM” for the “Queue manager name”. Do not make it the default queue manager. Click “Next”.

(56)

• In the next screen, accept the default local “Log path” and click “Next”. We will move this data to the shared disk later.

(57)

• Check the option to start the queue manager and click “Next”.

• Check the option to create a listener for TCP/IP. Note the “Listen on port number” which is 1414 as default.

(58)

• In the following screen, to complete the queue manager creation, click “Finish”.

• Check that BRK01_QM is listed under “Queue Managers” and is running.

(59)

• Right click on BRK01_QM which is listed under “Queue Managers” and select “Stop”.

Figure 5.26 – Stopping the queue manager – Step 1

• Select “Controlled” and click “OK”.

Figure 5.27 – Stopping the queue manager – Step 2

(60)

Figure 5.28 – Checking the queue manager’s status

• Right click on BRK01_QM and select “Properties”.

Figure 5.29 – Queue manager properties

(61)

Figure 5.30 – Changing queue manager’s startup type

• Change the “Startup” to “Manual” and click “OK”.

It’s now time to play with queue manager data and do some new MSCS configurations for WebSphere MQ.

• Check that the:

o_{Queue manager files are locally created under:}

(62)

Figure 5.31 – Queue manager files

o_{Log files are locally created under:}

C:\Program Files\IBM\WebSphere MQ\log\BRK01_QM\

Figure 5.32 – Queue manager log files

• Open the Windows Registry Editor and go to:

o_{HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVer} sion\Configuration\QueueManager\BRK01_QM\

(63)

Hint: To open the Registry editor go to “Start Menu > Run…”, type “regedit” and click “OK”.

• Check that the data for the name “Prefix” is your local path.

Figure 5.33 – Checking the registry

• In the Windows Registry Editor go to:

o_{HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVer} sion\Configuration\QueueManager\BRK01_QM\Log\

• Check that the data for the name “LogPath” is your local log path.

• You will need to create a directory in the shared disk. Open a Windows Command Prompt and run:

(64)

• In the Windows Command Prompt, run the following command to move your queue manager (BRK01_QM) data and logs onto shared “Disk E:”:

o_{hamvmqm /m BRK01_QM /dd E:\MQDATA /ld E:\MQDATA}

Figure 5.35 – Move MQ data to the shared disk

• Check that the:

o_{Queue manager files are now located in:}

E:\MQDATA\Qmgrs\BRK01_QM

o_{Log files are now located in:}

E:\MQDATA\BRK01_QM

Figure 5.36 – Checking moved files

• Open the Windows Registry Editor and go to:

o_{HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVer} sion\Configuration\QueueManager\BRK01_QM\

(65)

• In the Windows Registry Editor go to:

o_{HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVer} sion\Configuration\QueueManager\BRK01_QM\Log\

• Check that the data for the name “LogPath” is now “E:\MQDATA\BRK01_QM”.

• As we moved the queue manager data and logs to a shared disk. We need to check that the queue manager is still running. Open a “WebSphere MQ Explorer”. Right click on “BRK01_QM” under “Queue Managers”” and select “Start”.

(66)

Figure 5.39 – Checking the queue manager

• Check that the queue manager BRK01_QM is started successfully.

Figure 5.39 – Queue manager running

• Right click on “BRK01_QM” under “Queue Managers”” and select “Stop”. In the following dialog, click “OK” to end the queue manager.

(67)

• Now, we have to define first the WebSphere MQ MSCS resource for the cluster. On both nodes, open a Windows Command Prompt and run:

o_{haregtype /r}

Figure 5.40 – Defining MQ MSCS resource type

• Reboot both nodes to avoid the problem: "Event id 5079: An error occurred attempting to read properties for the 'IBM MQSeries MSCS' resource", or a reported error 126 (0000007e)”.

• Open the Windows Cluster Administrator again, expand your cluster tree and under “Cluster Configuration” find “Resource Types”. Check that “IBM MQSeries MSCS” is added.

(68)

Figure 5.41 – Defining MQ MSCS resource type

• We need to add our queue manager to our MSCS group as a resource. Right click on “WMB Group” and select “New > Resource”.

Figure 5.42 – Adding the queue manager as a resource

• Type “WMB BRK01_QM” for the “Name” of the resource. Select “IBM MQSeries MSCS” as the “Resource Type” and “WMB Group” as the “Group”. Check the “Run this resource in a separate Resource Monitor” option. Click “Next”.

(69)

Figure 5.43 – Adding the queue manager as a resource

• Add “Disk E:” and “WMB IP Address” to the “Resource dependencies” and click “Next”. With this configuration, the queue manager will not be online until the IP Address and the shared disk holding MQ data are online.

Figure 5.44 – Adding dependencies

• Type “BRK01_QM1” into the “QueueManagerName” field and click “Finish”.

(70)

Figure 5.45 – Configuring the queue manager

• Check that the “WMB BRK01_QM1 resource is added successfully and is offline.

Figure 5.46 – Resource is added and is offline

• Open Windows Services and find “IBM MQSeries”. Right click and select “Properties”. Change the startup type to “Manual” and click “OK”.

(71)

Figure 5.47 – Changing startup type for the MQSeries service

• In the Cluster Administrator right click “WMB BRK01_QM” resource under “WMB Group” and select “Bring Online”.

Warnings:

• If the resource fails while bringing it online, restart both nodes and try again.

• If you encounter any authorization errors while starting the resource, run following command on both nodes to set the queue manager admin authority:

o_{C:\Program Files\IBM\WebSphere MQ\bin\amqmsrvn –user} your.domain.com\wmbadmin –password password

(72)

Figure 5.48 – All resources are online

Its now time to test the cluster software configuration for the high availability of WebSphere MQ!

• Right click on the “WMB Group” and select “Move Group”. With this action we are simulating a failure in the first node.

• Check that all resources are online on the second node. MSCS detected the failure and moved all resources to the second and brought them online.

(73)

Figure 5.49 – All resources are online on the second node

• Right click on the “WMB Group” and select “Move Group”.

• Check that all resources are online on the first node again.

Figure 5.50 – All resources are online on the first node again

(74)

As the broker data will be stored in a DB2, this database needs to be under MSCS control. In this step, we will configure DB2 Enterprise Server to run with MSCS.

• Before starting, check that the user “wmbadmin” is in the “DB2ADMNS” and “DB2USERS” user groups.

You have to perform following steps on both nodes:

• Open a DB2 Command Window and get the DB2 instance list by running: o_db2ilist

• You will see the default instance, “DB2” in the instance list. Drop this instance by running:

o_{db2idrop db2}

Figure 5.51 – DB2 instance list

• Create a new DB2 instance named “DB2WMB” by running: o_{db2icrt DB2WMB –s ESE –u wmbadmin}

• Get the DB2 instance list again by running: o_db2ilist

(75)

Figure 5.52 – DB2 instance create and list

If you open the Windows Services, you should see a new created service that represents the instance.

In the case of an:

• Enterprise Server Edition (ESE) instance, the name of the service has the suffix:

“<INSTANCE-NAME>-<NODE NUMBER>”, for example, “DB2-DB2WMB-0”.

• Workgroup Server Edition (WSE) instance, the name of the service has suffix

<INSTANCE-NAME>”. If we have created a WSE instance, the service would be like “DB2-DB2WMB”.

This name is very important, as it will be the Windows Registry Key Name of the service. This means that the following entries must exist in the Windows registry:

• ESE instance: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\D B2WMB-0 • WSE instance: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\D B2WMB

Warning: The cluster software looks to this entry to start a highly available DB2 instance. This is usually the most common problem in setting up DB2 with

(76)

Windows Cluster. When creating a DB2 resource in MSCS, if you name it with a name that is different from this entry, the resource will not find the DB2 server and will not start. Renaming the resource will not solve the problem and you will have to recreate it.

In the next steps we will be configuring the DB2 instance in MSCS.

You have to perform following steps from the first node.

• We will start by adding the DB2 resource type to MSCS. Open a DB2 Command Windows and run following command:

o_{db2wolfi –i}

Figure 5.53 – Adding the DB2 resource type to MSCS

• Open the Windows Cluster Administrator, expand your cluster tree and under “Cluster Configuration” find “Resource Types”. Check that “DB2 Server” is added.

(77)

Figure 5.54 – Checking the DB2 resource type

• You will need to create a directory in the shared disk to hold DB2 profiles. Open a Windows Command Prompt and run:

o_{mkdir F:\DB2PROFS}

• In a DB2 Command Window, run the following command to move the instance “DB2WMB” to our cluster “SAW-WMB” and to place the DB2 instance profile directory in the directory “F:\DB2PROFS“:

o_{db2iclus MIGRATE /i:DB2WMB /p:DB2WMB /p:F:\DB2PROFS} /c:SAW-WMB

• Get the DB2 instance list and check that the instance is moved to the cluster.

(78)

Figure 5.55 – Moving the DB2 instance to the cluster

• On the second node, get the DB2 instance list and check that the instance “DB2WMB” is existing and local.

• On the first node, we will use “db2iclus” command again with “ADD” clause to create references to the instance in the second node. Run:

o_{Instdb2iclus ADD /i:DB2WMB /m:SAW-ESB2 /c:SAW-WMB} /u:wmbadmin

(79)

Figure 5.56 – Referencing the second node

• On the second node, get the DB2 instance list and check that the instance is moved to the cluster.

Figure 5.57 – DB2 instance list

Perform following steps on both nodes.

• Run following commands in a DB2 Command Window: o_{db2set db2instdef=DB2WMB}

This command will set the default instance to “DB2WMB”. o_{db2 get instance}

This command will list the default instance, “DB2WMB”. o_{db2systray +auto}

(80)

This command will place a DB2 system tray icon for the default instance.

o_{db2 update dbm cfg using dftdbpath F:\}

This command will set the default database path to the shared disk, “F:\”.

Figure 5.58 – DB2 commands

• Open “Windows System Properties > Advanced > Environment Variables”. Check that the “DB2INSTANCE” variable is not set to “DB2WMB”:

(81)

Figure 5.59 – The DB2INSTANCE environment variable

• Select the “DB2INSTANCE” variable and click “Edit”. Change the variable value to “DB2WMB”.

Figure 5.60 – The DB2INSTANCE environment variable

We will now perform steps to create the highly available DB2 instance resource.

• From the first node, open the Windows Cluster Administrator. Under “Groups”, right click on “WMB Group” and select “New > Resource”.

• The resource name must be exactly the same as the last part of the Windows service name of the DB2 instance. Type “DB2WMB-0” in the

(82)

Name field, select “DB2 Server” as Resource Type and select “WMB Group” from the Group dropdown box. Click “Next”.

Figure 5.61 – Adding the DB2 resource to the cluster group

• In the next window, add “Disk F:” and “WMB IP Address” to the “Resource dependencies” and click “Next”. With this configuration, the database resource will not be online until the IP Address and the shared disk holding its data are online. Click “Finish”.

(83)

Figure 5.62 – Adding dependencies

• Open Windows Services, find “DB2-DB2COPY1-DB2WMB-0” and change its startup to “Manual”. Check that the service is owned by “wmbadmin”.

Figure 5.63 – DB2 Windows Service

• From the Cluster Administrator, bring the “DB2WMB-0” resource online.

(84)

Figure 5.64 – All resources are online on the first node

(85)

Hint: You can use the “db2mscs” utility to automate most of the steps of creating a highly available instance in MSCS. This command uses a configuration file that defines the user and password to create the services, the name and value of the resources like IP Addresses and network names, and so on. For further information about the usage of this utility, check the documents listed in the Resources section of this tutorial.

Optional: To check the data integrity of the shared disk, you can create a database (for example, “TESTDB”) with some test data, from the first node in the shared disk (for example, “F:\”). Then you can move the cluster group to the second node and connect to that database from the second node. Check that if you can successfully retrieve your sample data.

(86)

WebSphere Message Broker on MSCS

As we have created required WebSphere MQ and DB2 component resources for the WebSphere Message Broker, it’s now time to create the broker and put it under MSCS control.

The message broker relies on a broker database and in this tutorial this database is running under DB2. We will start by creating the database instance which the broker will use.

• To create the broker database, open a WebSphere Message Broker console and type:

o_{mqsicreatedb BRK01DB -u wmbadmin -e DB2}

• Check that the broker database files are located under the shared disk F:\. (You can also move the cluster to the second node and try to connect to the database from the second node.)

Figure 5.66 – Broker database files

• In both nodes go to “Windows Control Panel > Administrative Tools > Data Sources” and check that the “IBM DB2 ODBC DRIVER” named BRK01DB is created. If it’s not, create it manually.

(87)

Figure 5.67 – Data sources

Figure 5.67 – Add data sources

Warning: As we are using 32-bit DB2 binaries, if your system has a 64-bit architecture, your system may create the data source but may not list or register it. In this case you have to run the following command in both nodes, in a Windows Command Console to fix this problem:

(88)

o_{C:\Windows\SysWOW64\odbcad32.exe}

As we have created the broker database and checked the data sources, we can now create the broker.

• To create the broker, open a WebSphere Message Broker console and run:

o_{mqsicreatebroker BRK01 -i wmbadmin -a password -q BRK01_QM} -n BRK01DB -u wmbadmin -p password -w E:\MQDATA

Hint: The “–w” parameter here, will move the log and trace files to the shared disk. If you don’t supply this parameter for the broker creation you cannot change this property later. In this case you will have to recreate the broker.

Warning: If the ODBC Data Source Name is different from your broker database name (here, BRK01DB), you have to add “–n YourDataSourceName” parameter to this command.

• Go to the “Services” section of Windows Server and check that “IBM WebSphere Message Broker component BRK01” service is added and change the startup type of this service to “Manual”.

Figure 5.68 – The broker service

• Open the Windows Registry Editor, and check the following path: For 32-bit Windows Server systems:

(89)

o_{HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphereMQIntegr} ator\2\BRK01\

For 64-bit Windows Server systems:

o_{HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\} IBM\WebSphereMQIntegrator\2\BRK01\

Figure 5.69 – Broker’s registry record

Now, it’s time to put our broker under MSCS control.

• Open the Windows Cluster Administrator from the first node, right click on “WMB Group” and select “New > Resource”.

• Type exactly “MQSeriesBrokerBRK01” for the resource Name. Select “Generic service” as the Resource type, and “WMB Group” for the Group. Click “Next”.

(90)

Figure 5.70 – Adding broker resource to MSCS

• Add “DB2WMB-0” and “WMB BRK01_QM” to the “Resource dependencies” and click “Next”.

(91)

Figure 5.71 – Adding resource dependencies

• Type the exact service name of the broker service in the “Service name” field. Here, “MQSeriesBrokerBRK01”.

Figure 5.72 – Configuring Generic Server Parameters

• In the “Registry Replication” window, Add the registry key you previously checked as “Root registry key”. Click “Finish”.

(92)

Figure 5.73 – Configuring Registry Replication

• Bring the “MQSeriesBrokerBRK01” resource online.

• Check that all resources are online on the first node.

(93)

• Check that all resources are online on the second node.

Congratulations! You have successfully configured all WebSphere Message Broker components under MSCS control for high availability.

Creating and connecting the Configuration Manager

Our next step is to create a Configuration Manager which will control our broker instance (and other broker instances if you are creating multiple brokers).

In our tutorial the Configuration Manager is not a high available component. To create this component:

(94)

• On the separate machine that you installed and reserved for the Configuration Manager, create a queue manager named “CMGR01_QM” under the WebSphere MQ installation. This queue manager is will not be clustered and its data will not be stored in the shared disk.

• Open a WebSphere Message Broker Command Console and run:

o_{mqsicreateconfigmgr CMGR01 -i wmbadmin -a password -q} CMGR01_QM

Before trying to connect the Configuration Manager to your high available broker, check that all systems can ping other systems in the network.

Hint: To accomplish this, add IP/Hostname combination entries to each server’s host files located at “C:\WINDOWS\system32\drivers\etc\hosts”.

We have to establish WebSphere MQ connections between Configuration Manager and broker queue managers to enable messages to be exchanged. To accomplish this:

• Open a Windows Command Console in the Configuration Manager machine. Run the MQSC command line by typing:

o_{Runmqsc CMGR01_QM}

• In the MQSC command line, run following commands respectively:

o_{define qlocal('BRK01_QM') usage(XMITQ) maxmsgl (104857600)} replace

This command will define a transmission queue.

o_{define channel('CMGR01_TO_BRK01') chltype(sdr) trptype(tcp)} conname(‘SAW-WMB(1414)') xmitq('BRK01_QM') maxmsgl (104857600) replace

(95)

o_{define channel('BRK01_TO_CMGR01') chltype(rcvr) trptype(tcp)} maxmsgl (104857600) replace

This command will define a receiver channel. o_end

This command will end the MQSC command line.

• Open a Windows Command Console in one of the broker nodes. Run the MQSC command line by typing:

o_{Runmqsc BRK01_QM}

• In the MQSC command line, run following commands respectively: o_{define qlocal('CMGR01_QM') usage(XMITQ) replace}

This command will define a transmission queue.

o_{define channel('BRK01_TO_CMGR01') chltype(sdr) trptype(tcp)} conname(‘SAW-CMGR(1414)') xmitq('CMGR01_QM') maxmsgl (104857600) replace

This command will define a sender channel.

o_{define channel('CMGR01_TO_BRK01') chltype(rcvr) trptype(tcp)} maxmsgl (104857600) replace

This command will define a receiver channel. o_end

This command will end the MQSC command line.

Optional: If you want, you can define a server-connection channel on the high available broker queue manager to receive messages from other systems using WebSphere MQ Client. To accomplish this, in the MQSC command line, run following commands respectively:

o_{runmqsc BRK01_QM}

o_{DEFINE CHANNEL(CLIENT.SVRCONN) CHLTYPE(SVRCONN)} TRPTYPE(TCP) DESCR('Server-connection to Client’)

(96)

Figure 5.75 – Defining the server-connection channel

• By opening the WebSphere MQ Explorer on each node, check that appropriate channels are created successfully under “IBM WebSphere MQ > Queue Managers > BRK01_QM > Advanced > Channels”. Right click on each channel and select “Start”.

• Check that all channels are in “Running” states and “CLIENT.SVRCONN” channel is in “Inactive” state. (The server-connection channel is activated when a WebSphere MQ Client makes a connection to it.)

Congratulations! You have successfully configured your Configuration Manager to connect to your high available broker.

Section 6. Testing the configuration

To test the configuration you have made in the previous sections, you will need to have WebSphere Message Broker Toolkit installed.

(97)

• Run the WebSphere Message Broker Toolkit and create a clean workspace. In this tutorial, “\testws”.

Figure 6.1 – Selecting the workspace

• Change your perspective to “Broker Administration” perspective.

Figure 6.2 – Changing the perspective

• Under “Broker Administration Navigator”, right click on “Domain Connections” and select “New > Domain Connection”.

(98)

Figure 6.3 – Creating a new domain connection – Step 1

• In the “Domain Connection” windows, type “CMGR01_QM” for the “Queue Manager Name”, your Configuration Manager’s hostname, “SAW-WMB” for the “Host” and leave other values as default. Click “Next”.

• In the next window, type “DOMCONN” for the “Connection name. Click “Finish”.

(99)

• In the next windows, type “DOMCONN” for the “Connection name. Click “Finish”.

• In the “Domains” window, check that “CMGR01” is added successfully. Right click and select “Connect”.

(100)

• When connected, right click on the “CMGR01” and select “New > Broker Reference”.

Figure 6.7 – Creating a new Broker Reference – Step 1

• In the “Broker Reference” window, type “BRK01” for the “Broker name” and “BRK01_QM” for the “Queue Manager Name”. Click “Finish”.

(101)

You are now ready to deploy your Message Flows and Broker Archives (bar) to your high available broker using the WebSphere Message Broker Toolkit through the Configuration Manager component.

Section 7. Summary

In this tutorial, you have learned how is it possible to enhance the availability of a WebSphere Message Broker system in Windows Server environments by configuring WebSphere Message Broker, WebSphere MQ, DB2 and Microsoft Cluster Service (MSCS) together.

(102)

Resources

Learn:

• WebSphere Message Broker: Learn more about WebSphere Message Broker.

• “WebSphere Business Integration Message Broker and high availability environments” (developerWorks, Mar 2004): Find architectural overview and guidelines on creating high available WebSphere Message Broker systems.

• “IC91: High Availability for WebSphere Message Broker on Distributed Platforms” (IBM SupportPac, Sep 2008): Find documentation and scripts to assist in configuring WebSphere Message Broker on several High Availability products – HACMP, Veritas Cluster Server and MC/ServiceGuard.

• “WebSphere Message Broker V6.1 Infocenter”: Find detailed technical information and support on WebSphere Message Broker V6.1.

• “Setting up WebSphere MQ on Microsoft Cluster Server” (IBM Support, Dec 2006): Learn how to create a high available WebSphere MQ cluster on MSCS.

• “WebSphere MQ System Administration Guide V6.0” (IBM Support Docs, Mar 2007): See “Chapter 13. Supporting the Microsoft Cluster Service (MSCS)” for detailed information on clustering WebSphere MQ with MSCS.

• “High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows” (Redbooks, Feb 2009): See “Chapter 10. DB2 with Microsoft Windows Server Cluster” for detailed information on clustering DB2 with MSCS.

• “Setting Up MSCS for DB2 Using VMWare” (White Paper, Dec 2006): Find additional information on clustering DB2 with MSCS.

• “Introducing Microsoft Cluster Service (MSCS) in the Windows Server 2003 Family” (MSDN, Nov 2002): Learn more about Microsoft Cluster Service on Windows Server 2003.

• “Step-by-Step Guide to Installing Cluster Service” (Microsoft TechNet): Find step-by-step instructions to install MSCS.

(103)

Get product and technologies:

• “Trial download: IBM WebSphere Message Broker V6.1”: Try WebSphere Message Broker for 90 days free.

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was

published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX 5L™ AIX® Build Forge® CICS® ClearCase MultiSite® ClearCase® ClearQuest® DataPower® DB2 Connect™ DB2® developerWorks® Domino® HACMP™ i5/OS® IBM® Informix® iSeries® Language Environment® Lotus® OMEGAMON® Parallel Sysplex® POWER® PR/SM™ Processor Resource/Systems Manager™ RACF® Rational Rose® Rational® Redbooks® Redbooks (logo) ® RequisitePro® System i® System z® Tivoli® VTAM® WebSphere® z/OS® zSeries®

(104)

The following terms are trademarks of other companies:

AMD, AMD Opteron, the AMD Arrow logo, and combinations thereof, are trademarks of Advanced Micro Devices, Inc.

ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

Novell, SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other countries.

Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates.

SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries.

EJB, Enterprise JavaBeans, J2EE, J2SE, Java, JavaBeans, Javadoc, JavaScript, JavaServer, JDBC, JDK, JMX, JNI, JRE, JSP, JVM, Solaris, Sun, Sun Java, ZFS, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Active Directory, ActiveX, Microsoft, SQL Server, Windows Server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel Itanium, Intel Pentium, Intel, Itanium, Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.