Wmq wmb dist migration v1 030310

Migration to WebSphere MQ V7.0.1 and WebSphere Message Broker V7.0 Version 1.0 February 26, 2010 Authors: Ian Vanstone Sue Bayliss Richard Jacks Table of Contents TOC quot;
1-3quot;
1.Introduction PAGEREF _Toc254961390 3 1.1.About this project PAGEREF _Toc254961391 3 1.2.About this team PAGEREF _Toc254961392 4 2.ESB Overview PAGEREF _Toc254961393 4 2.1.The ESB PAGEREF _Toc254961394 4 2.2.What’s new in WebSphere MQ and WebSphere Message Broker? PAGEREF _Toc254961395 5 3.Planning the migration PAGEREF _Toc254961396 8 3.1.Architecture PAGEREF _Toc254961397 8 3.2.Process and functional considerations PAGEREF _Toc254961398 10 3.3.Planning the migration PAGEREF _Toc254961399 14 4.Creating a new test environment PAGEREF _Toc254961400 16 4.1.Creating a new test queue manager PAGEREF _Toc254961401 16 4.2.Creating a new test WebSphere Message Broker PAGEREF _Toc254961402 17 5.Migrating WebSphere MQ PAGEREF _Toc254961403 18 5.1.Install WebSphere MQ Explorer tooling PAGEREF _Toc254961404 18 5.2.Migrate a test queue manager PAGEREF _Toc254961405 18 5.3.Migrate the production queue managers PAGEREF _Toc254961406 21 6.Migrating WebSphere Message Broker PAGEREF _Toc254961407 21 6.1.Installing WebSphere Message Broker tooling PAGEREF _Toc254961408 21 6.2.Migrate a test broker PAGEREF _Toc254961409 28 6.3.Migrate the production brokers PAGEREF _Toc254961410 40 7.Considerations for integration with other products PAGEREF _Toc254961411 40 7.1.WebSphere Message Broker Version 6.1 considerations PAGEREF _Toc254961412 41 7.2.DB2 Version 9.1 for z/OS® considerations PAGEREF _Toc254961413 41 7.3.DB2 Version 9.1 for Linux, UNIX and Windows considerations PAGEREF _Toc254961414 41 7.4.WebSphere Service Registry and Repository considerations PAGEREF _Toc254961415 41 7.5.OMEGAMON® XE for Messaging considerations PAGEREF _Toc254961416 42 7.6.WebSphere Process Server considerations PAGEREF _Toc254961417 43 7.7.WebSphere Business Monitor considerations PAGEREF _Toc254961418 43 7.8.WebSphere MQ File Transfer Edition considerations PAGEREF _Toc254961419 43 Appendix A.Related information PAGEREF _Toc254961420 44 Appendix B.Notices PAGEREF _Toc254961424 45 Disclaimer PAGEREF _Toc254961425 45 Trademarks PAGEREF _Toc254961426 45 Appendix C.WebSphere MQ notes PAGEREF _Toc254961427 46 Stopping a cluster queue manager PAGEREF _Toc254961428 46 Appendix D.WebSphere MQ backups PAGEREF _Toc254961429 47 Appendix E.WebSphere Message Broker backups PAGEREF _Toc254961430 47 Introduction This document covers the migration of IBM ® WebSphere MQ from Version 6.0 to Version 7.0.1 and the migration of WebSphere Message Broker from Version 6.1 to Version 7.0. This section discusses the goals of the MPS project and the teams involved in the project. About this project The migration was completed as part of the Mixed Platform Stack (MPS) project. The MPS project is based on a customer scenario used to perform integration testing of a variety of IBM software products. The scenario is based on Lord General Insurance (LGI), a fictitious insurance company that provides insurance quotes and policies to consumers through Web applications. This document can be used in conjunction with the WebSphere MQ and WebSphere Message Broker Information Centers to provide examples, considerations, and best practices for migration. Further information about the LGI environment can be found in the MPS Redbook: The Mixed Platform Stack Project: Deploying a Secure SOA Solution into z/OS and Mixed z/OS and AIX Environments. Additional white papers written by the MPS team can be found on IBM Techdocs by searching for “Mixed Platform Stack.” You can also contact the Federated Integration Test (FIT) Mixed Platform Stack team directly by emailing the team at fit@us.ibm.com. In the scenario, the LGI company is migrating to WebSphere MQ for Version 7.0.1 and WebSphere Message Broker for Version 7.0 to gain the following business value: Maintain the software environment at a recent supported version Reduce software operation and maintenance costs Use new and updated functionality See Section 2.2 for more information on the capabilities of the new products. The WebSphere MQ queue managers and WebSphere Message Broker brokers in this scenario form LGI’s Enterprise Service Bus (ESB). All major transactions flow through the ESB. The company is therefore highly dependent on the ESB and has imposed the following restrictions on the migration: Maintain availability of service to consumers. Minimize disruption of in progress transactions to consumers. In this scenario WebSphere MQ and WebSphere Message Broker interact and integrate with many other products. See Section 7 for more information on these additional products. About this team This project is a collaborative project involving teams from IBM Software Group (SWG) and IBM Systems and Technology Group (STG). The SWG FIT team is a worldwide team whose mission is to test the integration of IBM products and to provide feedback to IBM product teams, customer-facing teams, and customers. The FIT team uses realistic, customer-like scenarios to perform integration testing on stacks of products. The STG z/OS Integration Test team, also known at zPET, is responsible for the final phase of IBM System z® product testing. The team’s mission is to validate z/OS functionality in an environment that closely simulates realistic production workloads and focuses on typical customer tasks. ESB Overview At the core of LGI’s systems is the Enterprise Service Bus (ESB) built with WebSphere MQ and WebSphere Message Broker. This section describes the strengths and usage of each product and recent enhancements. The ESB WebSphere MQ WebSphere MQ provides a messaging backbone to connect the major components of LGI’s service-oriented architecture (SOA), including front-end Web applications, back-end transaction processing services, business process management services, and the message broker. WebSphere MQ is chosen because of its platform support, reliability, scalability, high performance, simple programming and administration model, and it offers flexibility for the wide and evolving needs of the LGI business. For more information on WebSphere MQ, see http://www-01.ibm.com/software/integration/wmq/. WebSphere Message Broker The key features and benefits of WebSphere Message Broker are: Universal connectivity which simplifies application connectivity to provide a flexible and dynamic infrastructure Message routing and message transformation from anywhere, to anywhere Simple programming and easy to use tooling Powerful tools for operational management and performance For more information on WebSphere Message Broker, see http://www-01.ibm.com/software/integration/wbimessagebroker/. In the scenario, LGI requires high value integration services in addition to those delivered by the WebSphere MQ messaging backbone. These additional services are required to improve business agility and to reduce costs. The LGI company is the result of a merger of two businesses. LGI uses composite services designed and built as part of the original separate businesses. Many service interfaces originally designed for use in one of the original businesses do not match those in the other business. WebSphere Message Broker provides a powerful set of features to transform and route data so that existing services can be used without lengthy and costly modification. WebSphere Message Broker also provides: Easy-to-use tooling High-performance runtime Functions vital to the SOA (including integration with WebSphere Service Registry and Repository). These features provide a powerful and flexible platform for future ESB enhancements. What’s new in WebSphere MQ and WebSphere Message Broker? The migration from WebSphere MQ from Version 6.0 to Version 7.0.1 and of WebSphere Message Broker from Version 6.1 to Version 7.0 provides LGI with many new capabilities. Both products have delivered new capabilities in recent major releases and fix packs. What’s new in WebSphere MQ? WebSphere MQ Version 7.0 and subsequent Version 7.0.0.x service releases have enhanced the product in the following areas: Enhanced Java Message Service (JMS): As the emerging API of choice, the WebSphere MQ product was re-architected to provide a more integrated, higher performing JMS provider. Enhanced Publish-and subscribe: Publish-and-subscribe was added to WebSphere MQ for z/OS and enhanced on other platforms. Extended MQI verbs. Enhanced MQ clients to increase throughput resilience and availability. Web 2.0 support to help create richer user experience. Service Definition Wizard allows users to easily describe MQ applications in Web Services Description Language (WSDL) for better governance. Continued performance enhancements Many SupportPac™ updates: For example, MS81 (MQIPT), Performance Reports, and various Cat2 packages: MS03, MA01, MS0P, MO71, MO72. For further information, see the WebSphere MQ V7.0 Features and Enhancements Redbook. WebSphere MQ Version 7.0.1 added many more major enhancements, including: Enhanced availability options on distributed platforms (for example, multi-instance queue managers and automatic client reconnect) Keeping pace with industry evolution (for example, Secure Socket Layer (SSL) Online Certificate Status Protocol (OCSP) support and Windows Communication Framework support) IBM portfolio exploitation, and extension of reach, for Version 7 features Ongoing performance, consumability, and serviceability enhancements What’s new in WebSphere Message Broker? WebSphere Message Broker Version 6.1 and the subsequent Version 6.1.0.x service releases have enhanced the product in the following areas: Simplicity, consumability and productivity Enhanced SOA Support Universal connectivity Administration, security, and dynamic operational management Performance and platform coverage WebSphere Message Broker Version 7.0 continues to focus on these important areas, adding the following enhancements: Simplicity and productivity Radically streamlined product prerequisites and components means faster deployment and simplified, lower cost operation and maintenance Simplified connectivity solution development using IBM pre-supplied patterns Impact analysis to manage development artifact changes including extended SQL (ESQL), Maps and Message sets WebSphere Message Broker Explorer for dedicated administration tooling SCA nodes for WebSphere Process Server interoperability Universal connectivity for SOA Extended & integrated publish-subscribe: common management & security with new WebSphere MQ capabilities PHP nodes for Web 2.0 support Enhanced SAP, Siebel, PeopleSoft packaged application support New sequence and re-sequence nodes Dynamic operational management New operational facilities for audit and monitoring, including WebSphere Business Monitor integration features Resource statistics to understand broker performance, including memory usage Enhancements for WebSphere Service Registry and Repository processing Support and exploit WebSphere MQ multi-instance queue managers for high availability Platforms, environments, and performance Exclusively 64bit broker support Performance monitoring tools and reduced memory footprint For further information, see What's new in WebSphere Message Broker V7. Planning the migration This section gives an overview of the original and migrated architectures, introduces migration processes and product features to be considered before the migration, and provides guidance on the migration plan. Architecture We recommend that, when you make a large system change, such as a migration, you must document the original environment, the change process, and the new environment in detail. The sections below give an overview of LGI’s original and new environments. The original environment The LGI Web site provides insurance quotes and policies. The front-end Web site is built with a set of Web applications running on WebSphere Application Server. The front-end applications interact with back-end transaction and data processing services running on CICS® and WebSphere Application Server. An ESB links the front-end and back-end systems in order to transform messages, route messages, and carry out a variety of other tasks (for instance, interface with the service registry). All major software and systems are monitored with Tivoli® products. At the core of the ESB is WebSphere Message Broker. LGI uses two brokers for high availability. The brokers run on WebSphere MQ queue managers which are configured in a WebSphere MQ cluster. WebSphere MQ clusters provide a level of availability, but do not provide continuous availability to messages. For example, if a queue manager machine fails, the messages on the queue manager will be unavailable until the queue manager can be restarted. The cluster also includes queue managers at the front and back ends. The use of WebSphere MQ clustering for workload balancing and for simplified connectivity is a common ESB usage pattern. Figure 1-1 illustrates the architecture of the ESB runtime environment. This simplified diagram does not include all components (for example, WebSphere Service Registry and Repository and DB2 are not included). In addition to the runtime components, the following tooling and configuration components are also deployed in the environment: WebSphere Message Broker Toolkit Version 6.1 on Windows WebSphere Message Broker Version 6.1 configuration manager on Windows WebSphere MQ Version 6.0 Explorer on Windows WebSphere Message Broker Explorer (SupportPac IS02) on Windows Figure SEQ Figure ARABIC 1-1 Simplified view of the ESB runtime environment Further details on the entire LGI scenario environment can be found in the Redbook: The Mixed Platform Stack Project: Deploying a Secure SOA Solution into z/OS and Mixed z/OS and AIX Environments. New WebSphere Message Broker environment This document discusses the migration of brokers from WebSphere Message Broker V6.1 to WebSphere Message Broker V7.0. WebSphere MQ V7.0.1 is a prerequisite of WebSphere Message Broker V7.0, and therefore WebSphere MQ is a major focus of the migration process. Although WebSphere Message Broker Version 7.0 requires WebSphere MQ Version 7.0.1, WebSphere Message Broker prerequisites and components have been greatly simplified compared to previous releases. This makes the product easier to deploy and manage in a wide range of processing environments. In order to keep the migration as simple as possible, products are only updated if required to support WebSphere Message Broker for Version 7.0. This results in the following installations: WebSphere Message Broker Version 7.0 WebSphere Message Broker Toolkit Version 7.0 on Windows WebSphere Message Broker Version 7.0 Explorer on Windows WebSphere MQ Version 7.0.1 WebSphere MQ Version 7.0.1 Explorer on Windows In the LGI environment WebSphere Message Broker is integrated with several other products. For details on considerations for other products, see Section 7. The new capabilities of WebSphere Message Broker, WebSphere MQ, and associated products are not exploited as part of the LGI migration project. The exploitation of new features will be carried out separately, outside of the scope of the migration project, after the successful migration. Process and functional considerations This section introduces migration processes and product features that must be considered before the migration. Security As with any change, it is important to consider security when carrying out a migration. The following areas must be considered: Existing security policies and configuration. For example: For example, WebSphere Message Broker access control lists and file permissions Security enhancements in new products. For example: There is now a single security model for administration, which is the WebSphere MQ Object Access Manager Updating security policies to secure new features. For example: Creating new policies and profiles for new WebSphere MQ publish-subscribe artifacts Migrating existing Configuration Manager access control lists Removing identities and authorities associated with the broker system database Detailed information on security considerations and configuration is beyond the scope of this document. See the security sections of the product information centers for more information. Testing the migration process As with any major system change, it is prudent to test the change process. There are several benefits to testing the migration process: Allows you to gain experience with the migration process Helps you to determine whether any problems are introduced by the new version or the migration process Results in systems useful for testing new product capabilities To test the migration process, it is best to use a test environment identical to the production environment (for example, using the same product levels, applications, and configuration). Although an exact match between the production environment and test environment is not always practical, there must be as few differences as possible and any differences must be documented. The production environment migration should only be carried out once the migration of the test environment is complete. At that point, you are confident that your applications function correctly at the new product levels, and that the production migration process will run smoothly. Staged migration The LGI Web site must be kept available and fully functional at all times, even during system and service outages. Maintenance tasks (including product migrations) are carried out in a staged manner so that at least one component at each level of the architecture is always available to process workload. A staged migration of WebSphere MQ and WebSphere Message Broker is possible because of the following: The LGI environment employs redundancy at each level of the architecture (for example, using two brokers that perform equivalent function). WebSphere MQ allows queue managers running at different versions to connect via channels, using a cluster, or using a queue sharing group. Also, WebSphere MQ clients and queue manager managers can interoperate even when running at different versions of WebSphere MQ. During a staged migration, there will be times when a broker is unavailable (or a broker and a queue manager are both unavailable). In the LGI environment, all broker workload is initiated by WebSphere MQ messages, so while one queue manager or broker is unavailable, all messages are sent to the available queue manager and broker. The WebSphere MQ clustering technology of WebSphere MQ is used to improve service availability. If one queue manager is unavailable, WebSphere MQ cluster workload balancing automatically sends all messages to the available queue manager. No special action is required to workload-balance request messages when taking a queue manager offline (because they have no affinity to a particular queue manager). Reply messages do have an affinity with a particular queue manager because they are addressed to a reply-to queue manager specified in the request message. Messages with an affinity to a particular queue manager cannot be workload balanced and will therefore be sent to the specified queue manager, even if that queue manager is unavailable. Messages sent to an unavailable remote queue manager are queued (on the transmit queue) until the remote queue manager is available again.. Queued messages can pose a problem for messages that are related to customer Web requests because Web users expect fast response times and also because Web requests timeout. For the LGI scenario, in order to reduce the risk of Web requests timing out (or users losing patience), we manage the cluster so that reply messages are not routed to a stopped queue manager. See Appendix C for details on the process of stopping and restarting a cluster queue manager. Note: Bind-not-fixed cluster workload balancing is used to reduce affinities and therefore enhance availability. Although a staged migration is used to minimize service outages, there is a higher risk of service outages during the migration (for example, because all traffic flows through a single system). Therefore, it is prudent to carry out the migration at a time when the load on the system is at its lowest or use more than two systems. Capacity planning is also very important so that the available systems are capable to process the workload while other systems are unavailable. Other WebSphere Message Broker considerations Configuration manager The WebSphere Message Broker configuration manager has been removed in WebSphere Message Broker Version 7.0. Removal of the configuration manager simplifies the deployment and lowers operational and maintenance costs. For some installations, (for example, those using access control lists) there will be migration tasks associated with the removal of the configuration manager as documented in the WebSphere Message Broker V7.0 Information Center. For LGI, the only migration task related to the removal of the configuration manager is to remove the configuration manager queue manager and associated artifacts (for example, monitoring and security profiles). User name server There is no user name server component in WebSphere Message Broker V7.0. This reduction in prerequisite components simplifies the deployment of WebSphere Message Broker Version 7.0 brokers and lowers operational and maintenance costs. Databases Unlike WebSphere Message Broker Version 6.1 brokers, WebSphere Message Broker Version 7.0 brokers do not require a system database. This reduction in prerequisite components simplifies the deployment of WebSphere Message Broker Version 7.0 brokers and lowers operational and maintenance costs. Note: User data is not affected by the removal of the broker system database. For LGI, the broker still accesses insurance policy data from a database. Tooling The WebSphere Message Broker Toolkit Version 7.0 offers development tooling and basic administration tooling. WebSphere Message Broker Version 7.0 Explorer offers administration tooling. The Broker Administration perspective in the WebSphere Message Broker Toolkit Version 6.1 has been replaced by limited administration functionality in the new Brokers view, and by more advanced functionality in the new WebSphere Message Broker Version 7.0 Explorer. The WebSphere Message Broker Version 7.0 Explorer and the WebSphere Message Broker Toolkit Version 7.0 function with WebSphere Message Broker Version 7.0 brokers, but do not function with brokers running at previous versions. The WebSphere Message Broker Toolkit Version 7.0 supports coexistence so that multiple versions of the toolkit can be installed on the same machine. This simplifies migration because the tooling required to support brokers running on different versions can be installed on the same machine. Applications You can deploy broker archive files (BAR files) that you have created in WebSphere Message Broker Toolkit Version 6.1 to WebSphere Message Broker Version 7.0 brokers. You cannot deploy resources that you have created in the WebSphere Message Broker Toolkit Version 7.0 to brokers that are at Version 6.1 or Version 6.0. Publish and subscribe In WebSphere Message Broker Version 7.0, publish and subscribe is controlled from WebSphere MQ. See Migrating publish/subscribe information to WebSphere MQ Version 7.0.1 in the WebSphere Message Broker V7.0 Information Center for an overview of how to migrate publish and subscribe information from WebSphere Message Broker Version 6.1 to WebSphere MQ Version 7.0.1. Note: LGI does not use publish and subscribe and therefore publish and subscribe migration is not described in the document. Planning the migration Before beginning the migration is it important to create a detailed migration plan which includes: Detailed product hardware and software requirements planning, as detailed on the following IBM Web site pages: HYPERLINK quot;
http://www-01.ibm.com/software/integration/wmq/requirements/quot;
quot;
WebSphereMQV70/701quot;
WebSphere MQ V7.0.1 requirements WebSphere Message Broker V7.0 requirements Detailed migration steps A fallback plan to be executed in the event of a problem – including the factors that might lead to the initiation of the plan Steps and considerations for integrating other products. See Section 7 for considerations for integrating other products during the WebSphere Message Broker migration. In practice, the required and optional steps to migrate WebSphere MQ and WebSphere Message Broker can be carried out in many different ways, so each deployment will have a unique detailed migration plan. Important migration documentation resources There are many documentation resources that are useful when creating the WebSphere MQ Version 7.0.1 migration plan, including: WebSphere MQ and MQSeries product READMEs WebSphere MQ V7.0.1 Information Center Migrating from an earlier version in the appropriate Quick Beginnings for your chosen platform Installing a WebSphere MQ Server section in the appropriate Quick Beginnings for your chosen platform The Migration section WebSphere MQ V7.0 Features and Enhancements Redbook Text in relevant APARs and Technotes There are many documentation resources that are useful when creating the WebSphere Message Broker Version 7.0 migration plan, including: IBM WebSphere Message Broker Version 7.0 Readme WebSphere Message Broker V7.0 Information Center Migrating section WebSphere MQ V7.0.1 Information Center What's new in WebSphere Message Broker V7 Problems and solutions when migrating to WebSphere Message Broker 6.0, 6.1 and 7.0 The high-level migration process The high level plan for migrating from WebSphere MQ Version 6.0 to WebSphere MQ Version 7.0.1 and from WebSphere Message Broker Version 6.1 to WebSphere Message Broker Version 7.0 includes the following stages: Create a new test environment Before carrying out a migration, it is a good idea to become familiar with the new products and to test existing applications. The first stage is to create and test a new environment: Create new WebSphere MQ Version 7.0.1 queue managers. Create new WebSphere Message Broker Version 7.0 brokers. Migrate WebSphere MQ The WebSphere MQ migration is carried out as follows: Migrate an existing WebSphere MQ Version 6.0 test queue manager to WebSphere MQ Version 7.0.1. Migrate the existing WebSphere MQ Version 6.0 production queue managers to WebSphere MQ Version 7.0.1. Migrate WebSphere Message Broker After the WebSphere MQ migration is complete, the WebSphere Message Broker migration is carried out as follows: Migrate an existing WebSphere Message Broker Version 6.1 test broker to WebSphere Message Broker V7.0. Migrate the existing WebSphere Message Broker Version 6.1 production brokers to WebSphere Message Broker Version 7.0. The following sections contain details of the three stages. Creating a new test environment There are several benefits to creating a new test environment as part of your migration: It allows you to gain experience with the new version of the product. It gives you an environment to test that your existing applications work correctly. It helps you to determine whether any problems are introduced by the new version or the migration process. Creating a new test queue manager This stage involves installing and testing WebSphere MQ Version 7.0.1 in a new test environment. To create a new test WebSphere MQ Version 7.0.1 queue manager, follow these steps: Make appropriate updates to products to be integrated with WebSphere MQ. Review the current information in the appropriate WebSphere MQ V7.0.1 Readme for related products and apply recommended maintenance. See Section 7 for more information. Install WebSphere MQ Version 7.0.1. Apply relevant service to products. Review the current Recommended Fixes for WebSphere MQ and apply any recommended maintenance to WebSphere MQ Version 7.0.1. Follow the steps to create a queue manager in the Creating a queue manager section of the WebSphere MQ V7.0.1 Information Center. Install the WebSphere MQ Version 7.0.1 Explorer on a Windows machine and connect it to the new queue manager. Test the new queue manager: Run your existing WebSphere MQ tests. Test and verify existing applications. Optionally, use and test new product features. Creating a new test WebSphere Message Broker To install and test WebSphere Message Broker Version 7.0 in a new test environment, follow these steps: Make appropriate updates to products to be integrated with WebSphere Message Broker. Review the current information in the WebSphere Message Broker 7.0 readme for related products and apply recommended maintenance. See Section 7 for more information. Install WebSphere Message Broker Version 7.0. Review the current Recommended fixes for WebSphere Message Broker and apply any recommended maintenance to WebSphere Message Broker. Note: At the time of writing, there were no recommended fixes available for WebSphere Message Broker V7.0. Install WebSphere Message Broker Toolkit Version 7.0 on a Windows machine. Install WebSphere Message Broker Version 7.0 Explorer on a Windows machine. Create a new broker using the Default Configuration wizard. Alternatively, use the WebSphere Message Broker Explorer wizard to create a new broker or follow the Creating a broker advice in the WebSphere Message Broker V7.0 Information Center. Connect the WebSphere Message Broker Toolkit Version 7.0 to the new broker. Test the new broker. Run your existing broker tests. Test and verify existing flows. Optionally, use and test new product features. Migrating WebSphere MQ WebSphere MQ and WebSphere Message Broker are migrated separately to minimize outages and risks or problems. This section describes how to migrate queue managers in a test and production environment. When you migrate from a previous version of WebSphere MQ, resources are automatically migrated on first start of the queue manager at the new version. This means that you can continue to use your existing queue managers without carrying out any special migration tasks. In practice, some resources require backup and configuration processes for availability reasons. Install WebSphere MQ Explorer tooling For the LGI scenario, before migrating any of the queue managers, we install the WebSphere MQ V7.0.1 Explorer. The WebSphere MQ Version 7.0.1 Explorer can administer previous versions of WebSphere MQ so it is acceptable to replace all WebSphere MQ Version 6.0 Explorers with WebSphere MQ Version 7.0.1 Explorers before migrating queue managers. Migrate a test queue manager For LGI, we first carry out the migration in a test environment. The process is similar to that of the migration in a production environment; however, backward migration is always carried out in the test environment and is only carried out in the production environment in the event of a problem. Prepare WebSphere MQ Version 6.0 In preparation for your migration it is recommended that you backup queue managers before attempting migration. You should backup all queue managers on each system that will be migrated to the new release. If any errors occur during the migration process you will have to revert to WebSphere MQ Version 6.0. To do this you will have to uninstall the new release of the product, reinstall WebSphere MQ Version 6.0 and then restore your queue manager backups before restarting the WebSphere MQ Version 6.0 queue managers. See Appendix D for further information about queue manager backups. Preparing WebSphere Message Broker Version 6.1 In order that WebSphere Message Broker V6.1 functions correctly with WebSphere MQ Version 7.0.1, WebSphere Message Broker V6.1 Fix Pack 6.1.0.5 is required. Apply the fix pack before starting any broker queue managers at WebSphere MQ Version 7.0.1. The high level steps to apply this maintenance are: Stop all brokers on the machine you will apply maintenance to. Install WebSphere Message Broker Version 6.1 Fix Pack 6.1.0.5. Start all brokers that were stopped in the first step. Preparing WebSphere MQ Version 7.0.1 This section describes how to install WebSphere MQ Version 7.0: In the LGI scenario, WebSphere MQ is integrated with other products, some of which require changes before migrating WebSphere MQ. Review the current preventive service planning (PSP) information for related products and apply recommended APARs. See Section 7 for more information. If you use JMS or Java applications, please review the WebSphere MQ classes for JMS and classes for Java considerations in the WebSphere MQ V7.0.1 Information Center. Also note the information on JMS resources. Stop all WebSphere MQ related processes on the system where you are carrying out the migration. It is advisable to suspend any queue manager that is part of a WebSphere MQ cluster. See Appendix C for further details. Install WebSphere MQ Version 7.0.1. Apply relevant service to products. Review the current Recommended Fixes for WebSphere MQ and apply any recommended maintenance to WebSphere MQ Version 7.0.1. Migrating a queue manager to WebSphere MQ Version 7.0.1 We recommend a staged migration (for example, migrate one queue manager at a time) in order to minimize the impact of potential migration problems. The following steps should be carried out once for each queue manager: Start the queue manager. The queue manager will automatically migrate to WebSphere MQ Version 7.0.1 as it starts. You must not start any listeners until after you have successfully started the associated queue manager. Note: Do not resume the cluster queue manager until the migration is complete. Verify the WebSphere MQ installation. Carry out a full test of the queue manager using your existing tests. Test WebSphere Message Broker Version 6.1 brokers and existing broker flows function correctly on the WebSphere MQ Version 7.0.1 queue manager. Restoring a queue manager to a previous version While testing the migration process, it is important to test that a queue manager can be restored to a previous version. During the migration of production systems, restoring to a previous version should only be carried out if migration problems are encountered. The following steps describe how to backward migrate from to WebSphere MQ Version 7.0.1 to WebSphere MQ Version 6.0. The process for each queue manager is: Stop the WebSphere MQ Version 7.0.1 queue manager (for example, using the command endmqm QM1) Note: Do not resume the cluster queue manager until the migration is complete. Uninstall WebSphere MQ Version 7.0.1. Reinstall WebSphere MQ Version 6.0 at the exact maintenance level (and any additional fixes) in use at the point when the queue manager was backed up. Restore the WebSphere MQ Version 6.0 queue manager from backups. Start the WebSphere MQ Version 6.0 queue manager. Test the queue manager to ensure that it has been successfully restored at WebSphere MQ Version 6.0. After the queue manager has been successfully restored at WebSphere MQ Version 6.0, the queue managers should be migrated to WebSphere MQ V7.0.1 again. If the restore to WebSphere MQ Version 6.0 was carried out due to production system migration problems, the problems must be investigated and fixed before migrating to WebSphere MQ Version 7.0.1 again. Post migration tasks The following tasks must be carried out after a successful migration: Check for any post migration tasks that are specific to the operating system on which you are performing the migration. See Platform-specific information in the WebSphere MQ V7.0.1 Information Center for further details. NOTE: Not all supported operating systems have post migration tasks. Resume the cluster queue manager so that other cluster queue managers send it messages. See Appendix C for the process of resuming a cluster queue manager. Migrate the production queue managers Carrying out the migration of queue managers in a test environment helps to refine the migration process. When you are confident in the migration, you can carry out the migration in the production environment. The process is similar to migration in a test environment, with two significant differences: Refinements have been made to the migration process based on experiences during the migration of queue managers in a test environment. Backward migration is always carried out in the test environment and only carried out in the production environment in the event of a problem. Migrating WebSphere Message Broker Independent migrations of WebSphere MQ and WebSphere Message Broker minimize the risk of outages and simplify problem determination in the event of a migration problem. At this stage all queue managers should be running at WebSphere MQ Version 7.0.1 as described in the previous section. This section describes how to migrate WebSphere Message Broker; first in a test environment and then in production. Installing WebSphere Message Broker tooling We recommend installing the WebSphere Message Broker Toolkit Version 7.0 and the WebSphere Message Broker Version 7.0 Explorer before migrating any of the runtime brokers, as described below. Installing the Toolkit The WebSphere Message Broker Toolkit Version 7.0 can coexist on the same machine as the previous Version 6.1 Toolkit which eliminates the need for additional hardware during migration. Note: The WebSphere Message Broker Toolkit Version 7.0 does not function with WebSphere Message Broker Version 6.1 brokers. The following tasks must be carried out to install the Toolkit: Take appropriate workspace and broker application resource backups. See Appendix E for information on WebSphere Message Broker Toolkit backups. Install the WebSphere Message Broker Toolkit Version 7.0 using the IBM Installation Manager installer provided. Start the WebSphere Message Broker Toolkit Version 7.0. On startup, you are prompted to specify a workspace. In situations where support for both Version 6.1 and Version 7.0 is required, it is recommended to use a new workspace. This also simplifies any backward migration to V6.1. In situations where support for just Version 7.0 is required, it is acceptable to specify the existing Version 6.1 workspace (which will be automatically migrated). For the LGI scenario, we specified a new workspace. Export projects from WebSphere Message Broker Toolkit Version 6.1 and import the projects to WebSphere Message Broker Tooklkit Version 7.0. For each project, carry out the following steps: Open the WebSphere Message Broker Toolkit Version 6.1. Open the Broker Application Development perspective. Right click on a project in the Broker Development pane and select Export. Select Project Interchange and click Next. Select the project, enter a path and name of the zip file, and click Finish. Switch to the WebSphere Message Broker Toolkit Version 7.0. Click the File menu and select Import. Expand the Other folder, select Project Interchange, and click Next. Enter the zip file name, select the project, and click Finish. The WebSphere Message Broker Toolkit Version 7.0 cannot deploy applications to the existing WebSphere Message Broker Version 6.1 brokers, but it does offer samples and tutorials. To access the samples and tutorials, follow these steps: Open the WebSphere Message Broker Toolkit Version 7.0. Click the Help menu, select Samples and Tutorials, and select WebSphere Message Broker Toolkit – Message Broker. Install the Explorer The WebSphere Message Broker Version 7.0 Explorer can coexist on the same machine as the earlier versions of the WebSphere Message Broker Explorer (supplied in SupportPac IS02), which simplifies the migration progress. Install the WebSphere Message Broker Version 7.0 Explorer to those machines already hosting either the WebSphere Message Broker Explorer (supplied in SupportPac IS02) or the WebSphere Message Broker Toolkit Version 6.1 (administration perspective). Note: The WebSphere Message Broker Version 7.0 Explorer cannot administer WebSphere Message Broker Version 6.1 brokers. Migrate a test broker For the LGI scenario, we first carry out the migration in a test environment to test the migration process. Migration of a broker in a test environment is similar to migration of a broker in a production environment. The test environment can also be used to test backward migration. Backward migration is only carried out in the production environment in the event of a problem. Preparing WebSphere Message Broker Version 7.0 This section includes installing WebSphere Message Broker Version 7.0 with appropriate maintenance. Note: The WebSphere Message Broker Version 7.0 Information Center contains separate sections depending on whether you are migrating from WebSphere Message Broker Version 6.0 or Version 6.1. The following must be carried out once per install: Review your system security requirements and the security advice in the WebSphere Message Broker V7.0 Information Center. Migration information is regularly updated on the WebSphere Message Broker support Web page with the latest details available in the Problems and solutions when migrating to WebSphere Message Broker 6.0, 6.1 and 7.0 Technote. Make appropriate updates to products to be integrated with WebSphere Message Broker. Review the current information in the WebSphere Message Broker 7.0 readme for related products and apply recommended maintenance. See Section 7 for more information. For example, APARs PK83072, PK99362, and PK70958 to DB2 Version 9.1 for z/OS. See Section 7 for more information. If you have existing broker flows which do publish and subscribe read the Migrating publish/subscribe information to WebSphere MQ V7.0.1 section in the WebSphere Message Broker Version 7.0 Information Center. Install WebSphere Message Broker Version 7.0. Review the current Recommended fixes for WebSphere Message Broker and apply any recommended maintenance to WebSphere Message Broker. Note: At the time of writing, there were not recommended fixes available for WebSphere Message Broker V7.0. Migrating a WebSphere Message Broker broker For the LGI scenario, we staged the migration of brokers in order to minimize the impact of potential migration problems. We performed the migration of the second broker after we successfully completed the migration of the first broker. The following steps must be carried out once for each broker: Take appropriate broker backups (see Appendix E). Suspend the broker queue manager from the cluster. See Appendix C for information relating to suspending queue managers in order to send all messages on the other broker. Stop the WebSphere Message Broker Version 6.1 broker. Initialize the WebSphere Message Broker Version 7.0 environment by running the mqsiprofile command. See Command environment: Linux and UNIX systems in the WebSphere Message Broker V7.0 Information Center. If your broker connects to any application databases, configure the appropriate ODBC database driver manager initialization file for your environment. See Updating ODBC definitions when migrating in the WebSphere Message Broker V7.0 Information Center. Run the mqsimigratecomponents command. This job migrates the registry, queue, and broker database; connection to the broker database of the previous broker is required to complete this action. The WebSphere Message Broker Version 7.0 broker does not require a system broker database. After migration, all information in the broker system database is stored in an internal repository. See mqsimigratecomponents command in the WebSphere Message Broker V7.0 Information Center. Note: The LGI brokers use a database to store application data. Start the broker. The verification program runs automatically as part of broker startup. Check the broker job log for errors. Connect the WebSphere Message Broker Toolkit V7.0 to the broker. Start the Toolkit. Right click on the Brokers root and select Connect to a Remote Broker. Enter the details for the broker queue manager and click Next. Check that the channel details are correct and click Finish. Note: The channel already exists because it has been configured and used when running at the previous version. Check that broker appears in the broker tree. Connect the WebSphere Message Broker V7.0 Explorer to the broker. Start the Explorer. Right click on the Brokers root and select Connect to a Remote Broker. Enter the details for the broker queue manager and click Next. Check that the channel details are correct and click Finish. Note: The channel already exists because it has been configured and used when running at the previous version. Check that broker appears in the broker tree. Resume the broker queue manager back into the cluster. See Appendix C for information relating to resuming queue managers in order to send messages to both of the brokers. If the migration was successful, the broker flows that were running before stopping the Version 6.1 broker are automatically started. Check that broker flows are running. Note: You do not have to perform specific tasks to migrate your development and deployment resources, such as message flow files, message set definition files, ESQL files, XML Schema files, and broker archive files. You can immediately start using these resources with WebSphere Message Broker Version 7.0. Check that flows are deployed and running. Test the flows. Optionally, deploy and test the existing BAR files built with WebSphere Message Broker Toolkit Version 6.0. Optionally, deploy and test BAR files built with WebSphere Message Broker Toolkit Version 7.0. Carry out a full test of the broker using your existing tests. Restoring to a previous version of a broker While testing the migration process, it is important to test that backward migration works correctly. In a production environment, backward migration should only be carried out if migration problems are encountered. Note: You can only restore brokers to the pre-migration state; changes that you have made to them after migration, such as updated properties, are lost. Note: Because you do not migrate configuration manager or user name server components, you do not have to restore these. If you have not deleted them, they retain their existing configuration, and can be reused with brokers that you restore to a previous version. The process for each broker is: Take appropriate broker backups. See Appendix E for information….. Suspend the broker queue manager from the cluster. See Appendix C for information relating to suspending queue managers in order to send all messages through the other broker. Follow the instructions on the Restoring components and resources to Version 6.1 in the WebSphere Message Broker V7.0 Information Center. Resume the broker queue manager back into the cluster. See Appendix C for information relating to resuming queue managers in order to send messages through both brokers. Test the broker to ensure that the backwards migration has been successful. When a successful backwards migration has been achieved, the brokers should be migrated forward to WebSphere Message Broker Version 7.0 again. If the backwards migration was carried out due to production system migration problems, the problems should be investigated and fixed before migrating forward to WebSphere Message Broker Version 7.0 again. Post migration tasks The following tasks must be carried out after a successful migration: Reviewing the Post-migration tasks section of the WebSphere Message Broker V7.0 Information Center. Stop and delete the WebSphere Message Broker Version 6.1 components (configuration manager, user name server, and brokers that you have replaced but not migrated). This includes associated artifacts (for example, monitoring and security profiles). Remove the installed code for WebSphere Message Broker Version 6.1. Delete the WebSphere Message Broker Version 6.1 broker system database. This includes associated artifacts (for example, monitoring and security profiles). Note: The LGI broker continues to use a DB2 database to hold insurance policy data. Migrate the production brokers Carrying out the migration of brokers in a test environment helps to refine the migration process. When you are confident with the migration, you can carry out the migration in the production environment. The process is similar to migration in a test environment, with two significant differences: Refinements have been made to the migration process based on experiences during the migration of queue managers in a test environment. The backward migration process has been tested in the test environment. Backward migration should only be carried out in the production environment in the event of a problem. Considerations for integration with other products This section contains considerations for products involved in the migration of WebSphere MQ and WebSphere Message Broker in the LGI environment. It lists requirements in order to integrate the new versions of WebSphere MQ and WebSphere Message Broker with other products, as well as enhancements in the new versions of products. Our work with the scenario only includes the main products from the LGI environment and does not represent a full list of products that integrate with WebSphere Message Broker. Many of the products function with the new versions of WebSphere MQ and WebSphere Message Broker without the need for updates or modification. Only required or optional changes are documented in this section. WebSphere Message Broker Version 6.1 considerations WebSphere Message Broker requires WebSphere MQ. Requirements for WebSphere MQ Version 7.0.1 Depending on requirements (for example, new features, maintenance schedules, and other requirements) you might choose to migrate to WebSphere MQ Version 7.0.1 and to continue to run at WebSphere Message Broker Version 6.1. You must run the broker at WebSphere Message Broker Version 6.1 Fix Pack 6.1.0.3 or above. DB2 Version 9.1 for z/OS® considerations In the LGI environment, WebSphere Message Broker integrates with DB2 for z/OS. Requirements for WebSphere Message Broker Version 7.0 LGI’s WebSphere Message BrokerVersion 6.1 uses DB2 Version 9.1 for z/OS for the user database to store application data relating to insurance policies In order to integrate WebSphere Message Broker Version 7.0 with DB2 9.1, the following DB2 APARs must be applied before the migration of WebSphere Message Broker: PK83072, PK99362, and PK70958. DB2 Version 9.1 for Linux, UNIX and Windows considerations In the LGI environment WebSphere Message Broker integrates with DB2 for Linux, UNIX and Windows. Requirements for WebSphere Message Broker for Version 7.0 LGI’s WebSphere Message BrokerVersion 6.1 uses DB2 Version 9.1 for the broker system database. WebSphere Message Broker Version7.0 stores system data on the file system. A broker database is no longer required. After a successful migration to WebSphere Message Broker Version 7.0, the old broker system database and associated artifacts (for example, monitoring components, security profiles, and other features) must be removed from the system. WebSphere Service Registry and Repository considerations WebSphere MQ Service Definition is standard for documenting WebSphere MQ applications as services (using Web Services Description Language (WSDL) and Uniform Resource Identifier (URIs)) which can be stored in a service registry, such as WebSphere Service Registry and Repository. Service definitions simplify the reuse of WebSphere MQ applications in SOAs. By describing applications as services, using the same formats as traditional Web services, applications can be managed in the same way as services. This promotes reuse and enables integration with standard service tooling. WebSphere Message Broker has included RegistryLookup and EndpointLookup nodes since WebSphere Message Broker Version 6.1. These can be used to query information, such as service endpoints, from WebSphere Service Registry and Repository. Enhancements WebSphere MQ Version 7.0.1 Explorer includes the WebSphere MQ Service Definition Wizard, which provides graphical tooling to create service definitions from WebSphere MQ objects. OMEGAMON® XE for Messaging considerations In the LGI environment, WebSphere MQ and WebSphere Message Broker are monitored by Omegamon XE for Messaging. Omegamon XE for Messaging and other Tivoli® monitoring products are integrated with IBM Tivoli Monitoring as part of an integrated solution to manage operating systems, databases and servers in distributed and host environments. Requirements for WebSphere MQ Version 7.0.1 Support for WebSphere MQ Version 7.0, including new features (for example, attributes of the queue manager, channels, queues, and events) is available from Omegamon XE for Messaging Version 7.0. OMEGAMON XE for Messaging Version 7.0 FP02 provides the toleration support for WebSphere MQ Version 7.0.1 (see http://www-01.ibm.com/support/docview.wss?uid=swg21416848). OMEGAMON XE for Messaging Version 6.0.0 FP0001 IF0004 provides the toleration support for WebSphere MQ V7.0.1 (see http://www-01.ibm.com/support/docview.wss?uid=swg21390806). Requirements for WebSphere Message Broker Version 7.0 OMEGAMON XE for Messaging Version 7.0 FP02 provides the toleration support for WebSphere Message Broker Version 7.0 (see http://www-01.ibm.com/support/docview.wss?rs=3032&uid=swg24025494&loc=en_US&cs=UTF-8&lang=en). WebSphere Process Server considerations The LGI environment integrates WebSphere MQ with WebSphere Process Server Version 6.2. Enhancements WebSphere Message Broker Version 7.0 adds five new built-in message flow nodes to improve the interaction between WebSphere Message Broker and WebSphere Process Server Version 6.2 by using Web Services (SOAP over HTTP) or WebSphere MQ bindings. The nodes are the SCAInput, SCAReply, SCARequest, SCAAsyncRequest, and SCAAsyncResponse nodes. For more information, see Service Component Architecture (SCA) overview. WebSphere Business Monitor considerations Enhancements WebSphere Message Broker Version 7.0 adds significant capabilities for auditing and monitoring. You can now generate comprehensive audit and monitoring events from message flows, either at design time or operationally, for new and existing message flows. These events can be consumed by a diverse range of applications and systems, including WebSphere Business Monitor, WebSphere MQ and JMS applications, and vendor applications. In addition to business monitoring, you can use these events for business intelligence, and audit scenarios. For more information, see Business-level monitoring. WebSphere MQ File Transfer Edition considerations The LGI environment integrates WebSphere MQ with WebSphere MQ File Transfer Edition. Requirements for WebSphere MQ Version 7.0.1 In order to run WebSphere MQ File Transfer Edition on WebSphere MQ Version 7.0.1, you must use WebSphere MQ File Transfer Edition Version 7.0.2 or above. For more information, see WebSphere MQ File Transfer Edition System Requirements. Related information Use the following information to find out more about the IBM products and solutions referenced by this document, as well as related offerings: IBM Redbooks MQSeries Backup and Recovery: http://www.redbooks.ibm.com/abstracts/sg245222.html?Open WebSphere MQ Version 7.0 Features and Enhancements http://www.redbooks.ibm.com/abstracts/sg247583.html?Open Migrating to WebSphere Message Broker Version 6.0: http://www.redbooks.ibm.com/abstracts/sg247198.html?Open MQSeries Backup and Recovery Redbook: http://www.redbooks.ibm.com/abstracts/sg245222.html?Open IBM Redpapers DB2 9 for z/OS: Backup and Recovery I/O Related Performance Considerations An IBM Redpaper: http://www.redbooks.ibm.com/abstracts/REDP4452.html?Open Online resources WebSphere MQ: http://www-01.ibm.com/software/integration/wmq/ WebSphere Message Broker: http://www.ibm.com/software/integration/wbimessagebroker/ WebSphere MQ Version 7.0.1 Information Center: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp WebSphere Message Broker Version 7.0 Information Center: http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp Migrating WebSphere MQ queue manager clusters from WebSphere MQ Version 6 to Version 7: http://www.ibm.com/developerworks/websphere/library/techarticles/0910_beardsmore/0910_beardsmore.html Technote: Important information relating to migration or installation of WebSphere MQ for z/OS Version 7.0. Includes highlights of new function. http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg21312983 Notices Disclaimer Information in this document is provided ‘AS IS’ without warranty of any kind. Mention or reference to non-IBM products is for informational purposes only and does not constitute an endorsement of such products by IBM. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here. Trademarks The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both: AIX®System z®CICS®Tivoli®DB2®WebSphere®OMEGAMON®z/OS®Parallel Sysplex® The following terms are trademarks of other companies: Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others. WebSphere MQ notes Stopping a cluster queue manager There are two main types of messages flowing in the LGI scenario: Request messages are workload balanced from the front-end queue manager to one of the broker queue managers and then on to a back-end queue manager. Reply messages are routed from the back-end queue managers to the same broker queue manager that processed the corresponding request. Before a broker queue manager is stopped, it is suspended it from the cluster. This results in new request messages being routed to the other queue manager, while reply messages already in the system can be processed by either queue manager. After a few seconds all request and reply messages are flowing through the other queue manager (which is not suspended) and then it is safe to stop the suspended queue manager. The stop cluster queue manager process is as follows: Suspend the queue manager (for example, using the command SUSPEND QMGR CLUSTER(LGI.Z.CLUSTER)). Wait until all message traffic is flowing through the other queue manager. Stop the queue manager (for example, using the command endmqm QMGR). The start cluster queue manager process is as follows: Start the queue manager (for example, using the command strmqm QMGR). Optionally, verify that the queue manager is working correctly. Resume the queue manager (for example, using the command RESUME QMGR CLUSTER(LGI.Z.CLUSTER)). Check that message traffic is flowing through both queue managers. WebSphere MQ backups Before any major system change (and at regular intervals) it is important to take backups so that queue manager can be recovered in the event of loss of data. The following resources should be backed up: Logs Log control file System wide ini file The queue manager ini file and objects The conversion / ccsid tables For more information on WebSphere MQ backups, see Queue Manager Resources to Protect/Backup in the MQSeries Backup and Recovery Redbook. WebSphere Message Broker backups Before any system major change (and at regular intervals) it is important to take backups so that brokers and tooling can be recovered in the event of loss of data. The following resources should be backed up: Applications data: Toolkit workspaces, project interchange files, and BAR files. To back up these resources simply use the Toolkit to save copies. Runtime data: Broker configuration and associated resources. This is much simpler job at WebSphere Message Broker Version 7.0, which does not require DB2 or a configuration manager. The mqsibackupbroker command is used to backup a broker. For details, see Backing up the broker.

Wmq wmb dist migration v1 030310

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Wmq wmb dist migration v1 030310

Similar to Wmq wmb dist migration v1 030310 (20)

Recently uploaded

Recently uploaded (20)

Wmq wmb dist migration v1 030310