Best Practices. Achieving high availability and scalability with IBM InfoSphere MDM Server. IBM InfoSphere Master Data Management Server

Transcription

1 IBM InfoSphere Master Data Management Best Practices Achieving high availability and scalability with IBM InfoSphere MDM Nick Kanellos MDM Product Architect Dennis Shi MDM Infrastructure Specialist Managing Consultant

2 Achieving high availability and scalability with IBM InfoSphere MDM Page 2 Executive summary Master data, by its nature, is mission critical. Critical information such as customer names and addresses, accounts, customer assets, contact information, product definitions and descriptions, customer or supplier demographics, customer relationships, marketing assets, and so on, are all considered master data, and IBM InfoSphere Master Data Management (MDM) is the hub that stores and maintains the integrity of this data. The multitude of IT applications that an organization relies on such as customer relationship management, marketing, payroll, accounting, and billing systems might all rely on InfoSphere MDM for at least a portion of the data that they need to function correctly. The loss of InfoSphere MDM capabilities could have a significant impact on the operation of an organization, the quality of service that it offers its customers, and its profitability. This document describes the strategies you can use to ensure that IBM InfoSphere Master Data Management is available when it is needed. It describes various IBM components that you can use together to ensure that InfoSphere MDM remains available to meet its commitments to provide timely, accurate, mission-critical data within an organization. The key to achieving high availability (HA) is to ensure redundancy. IBM WebSphere Network Deployment Edition (WebSphere Network Deployment) provides this redundancy with its ability to cluster many servers so that they behave as one. Redundancy ensures that, if any server fails, the system as a whole can continue functioning. This document introduces the key concepts and terms related to the ability of WebSphere Network Deployment to create and maintain clusters. InfoSphere MDM is a Java Enterprise Edition (JEE) application. It contains both EJB and web application components and is designed to be deployed onto WebSphere clusters. This document describes how to deploy InfoSphere MDM onto a cluster and also describes the clustering strategies available to you. These include horizontal and vertical clustering, the deployment of InfoSphere MDM components onto clusters dedicated to each component, the use of IBM HTTP to provide clustering support of the InfoSphere MDM web components, and the configuration of InfoSphere MDM resources to take full advantage of the clusters. The deployment of IBM HTTP onto its own cluster is discussed briefly as well. Clients that access InfoSphere MDM for their data must also be built with the clustering, or high availability requirements of the system, in mind. This document provides coding examples that illustrate how you can access InfoSphere MDM in a cluster and how you can build robust code that recognizes when a server on a cluster might not be operational and how you can take appropriate action. Finally, because high availability is a broad topic, additional references are provided at the end of this document.

3 Achieving high availability and scalability with IBM InfoSphere MDM Page 3 Table of contents Executive summary... 2 Table of contents... 3 Introduction: High availability, fault tolerance, and workload balancing... 5 Introduction to clustering with WebSphere and HTTP... 6 WebSphere and clusters... 6 Overview... 6 Vertical or horizontal clustering... 7 Accessing EJBs on a cluster... 9 Installing an application on a cluster... 9 A client accessing the EJBs on a cluster with workload management and failover Accessing web content or web services on a cluster Accessing web content or web services directly Accessing web content or web services by using IBM HTTP Java Message Service Database high availability Deploying InfoSphere MDM onto a cluster InfoSphere MDM architecture and components InfoSphere MDM Java EE components Deploying InfoSphere MDM onto a cluster Overview Our cluster strategy Installing InfoSphere MDM onto our cluster Installing the non-java EE components of InfoSphere MDM Postinstallation configuration steps Pointing client applications to the InfoSphere MDM on the cluster Updating the Configuration Management Component repository Updating the config/bootstrap.properties file Other scenarios Converting InfoSphere MDM from a stand-alone instance to a cluster Configuring the IBM HTTP s to access InfoSphere MDM web services and web content Testing the installation for high availability Overview Using the Installation Verification Tool Using the Batch Processor Testing the web user interfaces Testing the web services Writing clients that access InfoSphere MDM components on a cluster Accessing the Enterprise JavaBeans Accessing web services and web applications Building fault tolerance applications that access MDM Services Enterprise JavaBeans Web services Best Practices... 38

4 Achieving high availability and scalability with IBM InfoSphere MDM Page 4 Conclusion Appendix 1 - Converting InfoSphere MDM from a stand-alone server to a cluster Overview Postinstallation configuration Appendix 2 Further reading WebSphere network deployment high availability DB2 high availability Notices Trademarks... 51

5 Achieving high availability and scalability with IBM InfoSphere MDM Page 5 Introduction: High availability, fault tolerance, and workload balancing A system is highly available when it achieves no unwanted downtime. Downtime is the time that a system spends not servicing its users or clients and not meeting its commitments. A system can be down for any number of reasons. The computers on which it operates might be down. The system might have experienced a fault that caused it to stop functioning and responding to client requests. Or the system might be experiencing such a heavy volume of service requests by its clients that it is unable to service any more. A system is fault tolerant if it can keep operating in spite of having experienced a fault. A fault is an event that a system does not expect or cannot handle. It might arise from errors in programming, receiving incorrect instructions from clients, receiving corrupt data, or being unable to access some of the resources on which it depends (such as computer memory, processor capacity, databases, networks, and so on). A system can achieve high availability without being fault tolerant if it can be built in such a way that it never experiences any faults. But that is never going to happen, and so high availability and fault tolerance go hand in hand. One cause of system downtime is that the system is simply not big enough to handle the load placed on it by its users and clients. That is, it does not scale to the needs of its clients and users. There are two ways to rectify such a limitation. You can make the system bigger (that is, put it on bigger computers with more memory, more CPU capacity, more disk capacity, higher network bandwidth, and so on) or you can spread the work around. Computers get exponentially more expensive the bigger they get; and if your system is largely a transactional one that handles large volumes of small, relatively straightforward, independent transactions, you do not need large, complex computers with massive processing capacity. A more cost-effective approach might be to install your system on more than one computer and share the workload among them to make your system available to more users and clients. This approach is called workload balancing. 1 1 Workload balancing, strictly speaking, is not in the domain of high availability. It generally falls into the domain of scalability whereby, as the load on a system grows, the IT infrastructure is able to grow proportionally. But as you will see, the strategies that you employ to achieve high availability also confer scalability, and vice versa. So if your goal is high availability, you get scalability for free; and if your goal is scalability, you get high availability for free. Consequently, this document discusses both.

6 Achieving high availability and scalability with IBM InfoSphere MDM Page 6 Introduction to clustering with WebSphere and HTTP WebSphere and clusters Overview As we have discussed, high availability is itself a goal that is achieved through fault tolerance and workload balancing. The best way to achieve both fault tolerance and workload balancing is by introducing redundancy to your system (no, we are not recommending that you make your system itself redundant). Redundancy in this sense means crafting a system in such a way that no one component of the system is critical to the operation of the overall system itself. If any one component of a system were to fail, the remaining components can continue to work, enabling the system to continue to meet its commitments. With InfoSphere MDM running as a Java Platform, Enterprise Edition (Java EE) application within WebSphere, the simplest way to achieve HA is to install InfoSphere MDM onto a WebSphere cluster. A cluster is a group of application servers that all behave as a single server. The workload of the cluster is shared among the individual servers that make up the cluster. If one server experiences a fault and is disabled, the other servers can take over and redistribute the load. The overall system remains available. Clients accessing the system might never even know that a server has experienced any difficulties. If you want to set up WebSphere clusters, you have to use WebSphere Network Deployment edition (WAS ND). The Base edition does not support clusters. The WebSphere Network Deployment documentation provides more details. In this document we only briefly introduce the various components that make up WebSphere Network Deployment, the terms that describe them, and how they are employed by InfoSphere MDM to achieve high availability. Refer to Appendix 2 for additional reading material about this topic. The following diagram illustrates the basic components that make up WebSphere Network Deployment: a cell, cluster, node, and an application server.

7 Achieving high availability and scalability with IBM InfoSphere MDM Page 7 Figure 1: WebSphere Network Deployment components consist of, at a minimum, a cell, a cluster, a node, and an application server. In WebSphere Network Deployment, a cell is a collection of nodes that are jointly managed. A node is the equivalent of a WebSphere Network Deployment application server profile. An application server profile is a runtime environment in which actual application servers run. The application server profile is what you see manifested on a computer after you install WebSphere Network Deployment. Inside the directory where you installed WebSphere is a profiles directory. Each new profile that you create on that computer will get its own directory. Inside that directory will be the executable and configuration components that are required to make a runtime environment. An application server can generally be equated to the Java virtual machine (JVM), the EJB container and web container in which all Java and Java EE applications, such as InfoSphere MDM, run. An application server runs within the context of a node. A cluster is a logical grouping of application servers. The application servers that belong to a cluster are called its members. A cluster can encompass as its members the application servers of many nodes. The application servers continue to run within the runtime environment of the node, however they operate jointly within the cluster as a single, virtual, distributed application server. A deployment manager is a type of node (application server profile) that is used to manage the other nodes in a cell. For example, through the deployment manager and its user interface console, you can add or remove application servers from a cell, create clusters, add or remove application servers to or from clusters, start or stop application servers or nodes, federate more nodes into a cell, remove nodes from a cell, deploy applications onto application servers or clusters, and so on. Vertical or horizontal clustering There are two strategies that you can employ when deciding how to configure a WebSphere Network Deployment cluster: Vertical clustering or horizontal clustering. You can also use a combination of both. When you install WebSphere Network Deployment on a computer, the installer usually generates an application server profile

8 Achieving high availability and scalability with IBM InfoSphere MDM Page 8 and creates a single application server within that profile 2. You can create more. The following illustration shows a cell in which four application nodes are installed on three computers: Node Computer Node Cluster Computer Node Computer Deployment Manager Computer Node Cell Figure 2: This depiction of a WebSphere cluster consists of 7 application servers (also known as members) deployed onto 4 nodes installed on 3 separate computers. The deployment manager is installed as its own node on a fourth computer. All 4 computers are managed within a single cell. In the preceding illustration the deployment manager is installed on a fourth computer. The deployment manager is used to manage the cell. In the cell, one cluster consists of seven application servers (also known as cluster members) configured on the four nodes. Each node has two application servers 3. The illustration shows that it is possible to spread a cluster across more than one computer and to configure more than one node on a computer. It is also possible to configure more than one application server on a single node. The practice of adding more computers to a cluster is known as horizontal clustering. This type of clustering spreads the cluster out broadly across many computers horizontally. The practice of deploying many application servers on a single node is known as vertical clustering because you stack the application servers onto a single computer vertically. 2 You can also choose other installation options. You can choose to install a cell that includes a deployment manager profile along with an application server profile (application node). Or, you can choose to install a custom application server profile with no application servers installed. 3 Note that on one application node, an application server is not part of the cluster. Although it is managed as part of the cell, it is a stand-alone server. It might be used to deploy non-critical applications or it might belong to another cluster. We include it to illustrate all the possibilities available to you when you configure your server topology.

9 Achieving high availability and scalability with IBM InfoSphere MDM Page 9 Guideline: Horizontal clustering increases the fault tolerance of an application that runs on the cluster. In the event of a hardware failure on a single computer, the remaining computers remain unaffected. It also increases the scalability of the system by distributing the processing across many CPUs. When people think of clustering, they generally think of horizontal clustering. Vertical clustering also can be useful. You might do implement this type of cluster if you have sufficiently powerful computers and you are not getting the throughput that you want. Sometimes the JVM itself can be the bottleneck, and because each application server is its own JVM, the simplest way to increase throughput is to have more JVMs running. Also, because system faults are not always due to hardware problems, having more than one application server on each computer further increases your system s fault tolerance (and hence its availability) without additional investment in hardware. Recommendation: A combination of vertical and horizontal clustering can be the most effective approach. The precise mix-and-match of horizontal and vertical clustering will require testing in your environment. Accessing EJBs on a cluster Let s take a quick look at a cluster from the standpoint of an application running on the cluster and a client accessing the EJBs within the application. Installing an application on a cluster When you install an EJB application or a web application onto a cluster, you are simultaneously installing it on all the application servers that make up that cluster. The following diagram illustrates:

10 Achieving high availability and scalability with IBM InfoSphere MDM Page 10 Node Computer Node Cluster JEE EJB EJB EJB EJB EJB EJB EJB Computer Node Computer Computer Deployment Manager Node Cell Deploying a JEE application onto a cluster effectively deploys it simultaneously onto all the application servers in the cluster. Figure 3: Java EE application on a cluster. When a Java EE application is installed onto a cluster, the executables for that application are deployed onto each application server on that cluster. By installing a Java EE application onto the cluster, we have effectively installed it onto seven application servers within the cluster. You cannot control that, because it is automatic. That is what it means to access an EJB on a cluster. A client accessing the EJBs on a cluster with workload management and failover The following diagram illustrates how a client application accesses the EJBs that are running on a cluster:

11 Achieving high availability and scalability with IBM InfoSphere MDM Page 11 Computer 1 Node Node Cluster Computer 2 Node Computer 0 Deployment Manager Computer Node Cell A client application can access the EJBs of a JEE application from any cluster member WLM Pluggin ORB EJB Client Figure 4: Client application accessing EJBs on a cluster. A client application, outside the cluster, can use an Object Request Broker with a workload management plug-in to access the EJBs of the JEE application. A client accesses an EJB by locating it on any one of the servers running on the cluster using RMI over IIOP protocols. The client application does not do it by itself. It uses an Object Request Broker (ORB) with a workload management (WLM) plug-in. The WebSphere run time provides the infrastructure, and it is transparent to the client application (we discuss writing clients to access EJBs in a cluster in Writing clients that access InfoSphere MDM components on a cluster later in this document). The client must know the DNS name or the IP address of any computer in the cluster. It also must know the port number of any application server on that computer. This is known as the bootstrap port. WebSphere Network Deployment assigns a unique bootstrap port number to each application server on a computer. The syntax that a client uses to access an application server on a cluster looks like this example: corbaloc:iiop:<hostname>:<bootstrap port number> It does not matter to which application server the client goes. The application servers that make up a cluster all know about each other and which are operating. To learn more, refer to the WebSphere Network Deployment documentation about clusters and high availability listed in Appendix 2. Any application server in the cluster that the client accesses will return to the WLM plug-in the addresses of all the other application servers in the cluster that are also functioning.

12 Achieving high availability and scalability with IBM InfoSphere MDM Page 12 Having a list of the application servers in a cluster, the ORB does not limit itself to the application server it first accessed. It uses an algorithm that is specified in the cluster to access a different application server for each invocation of an EJB method, even if it is accessing the same method. That is how the workload is distributed among all the members of a cluster. If one of the cluster members fails, the other members will soon detect it and update their list of active cluster members. Any clients that access the cluster will receive an updated list of active servers. Any clients that already have a list, might end up calling the failed cluster member for some of their transactions. Those transactions will fail. The client can try again, and the likelihood is high that it will access a different server. Eventually that client will receive an updated list of active cluster members and will bypass the failed one altogether. Accessing web content or web services on a cluster Accessing web content or web services directly So far we have discussed how a client might access EJBs in a cluster. A different approach is required to access web applications or web services. Instead of using an Object Request Broker, web and web services clients access a web container directly. Also, instead of using RMI, web clients use HTTP. Like the bootstrap port number for ORB, WebSphere Network Deployment also assigns a port number used by HTTP clients to access web content or web services. This is known as the WC_defaulthost port number. The same port number is used for both web content and web services. Because it is HTTP, the syntax is familiar: DNS name or IP address>:<wc_defaulthost number>/<name Web Content or web Service> Like for the EJBs described earlier, you can access the web content or the web services on any application server in the cluster. Unlike what happens for EJBs, there is no WLM-like plug-in that enables you to switch from application server to application server based on an algorithm. After an application client has established a session with a particular cluster member, it cannot change members. If that cluster member fails, so does the application accessing it. The client itself is responsible for maintaining a list of all the cluster members hosting that web service or web content. The following diagram illustrates how an application client accesses web content or web services on a cluster member.

13 Achieving high availability and scalability with IBM InfoSphere MDM Page 13 Computer 1 Node Node Cluster JEE application Web Content Web Service Web Service Computer 2 Node Computer 0 Deployment Manager Computer >:9812/<Web Service Name> Cell A client application can access the web content or web services on JEE application from any cluster member Node Web Services HTTP Client Figure 5: client accessing web content or web services on a cluster member. A client application, outside the cluster, uses HTTP to access the web service of a JEE application or web content from a web server. Accessing web content or web services by using IBM HTTP You can use the IBM HTTP or any other web server with a supported WebSphere plug-in. This document focuses on IBM HTTP. Refer to the WebSphere documentation to make sure that there is a plug-in for your web server. You can configure IBM HTTP with the WebSphere plug-in to route requests to WebSphere Network Deployment and to distribute the load to all the members of the WebSphere cluster. You need to install IBM HTTP and the corresponding WebSphere plug-in. You also need to copy some files to the WebSphere Network Deployment deployment manager bin directory. Follow the instructions accompanying the installation programs for the IBM HTTP and the WebSphere plug-in for HTTP. They are detailed and thorough. After you install IBM HTTP and the WebSphere plug-in for IBM HTTP, you can also configure WebSphere so that you can start and stop the IBM HTTP from the WebSphere administrative console. Do this by clicking the s Web s menu items in the administrative console, and then click the NEW button at the top of the list. Follow the instructions in the wizard.

14 Achieving high availability and scalability with IBM InfoSphere MDM Page 14 After IBM HTTP is installed and running, and the plug-in has been installed and configured, you can access the web content and web services installed on the cluster through the HTTP. How does the IBM HTTP know to which computers it can route the requests? And how does it recognize which requests it must route and which it must service on its own (that is, normal web pages)? The answer lies in a plug-in configuration file named, as one might guess, plugin-cfg.xml. This file is created when the plug-in is installed and configured. If you configured your WebSphere console to access the web server, you can view the contents of the file from the console. Click the s Web s menu item, and then click the web server that you configured. Then click the Plug-in Properties link. In the resulting pane, click the View button next to the textbox containing plugin-cfg.xml, to view the contents of the file. It seems as though the HA chain has a weak link. What happens if IBM HTTP experiences a problem and stops operating? To ensure that you maintain HA, you can add several computers running IBM HTTP in a cluster (note that this is not a WebSphere Network Deployment cluster). Describing IBM HTTP clusters is beyond the scope of this document, so we will not go into details here. Here is a picture of how our hypothetical cluster might now look: Computer 1 Node Node Cluster JEE application Web Content Web Service Web Service Computer 2 Node Computer 0 Deployment Manager Computer Node Computer 4 Computer 5 IBM HTTP WAS Plug-in IBM HTTP WAS Plug-in Virtual IP Address Cell Web Client Web Services Client Figure 6: IBM HTTP. By adding IBM HTTP, web clients and web services clients can enjoy a degree of high availability similar to JEE clients. HTTP can redirect an HTTP request to any application server on the cluster. A virtual IP address can abstract a cluster of HTTP s to further enhance high availability.

15 Achieving high availability and scalability with IBM InfoSphere MDM Page 15 Guideline: Accessing web services or web content directly in a cluster offers neither workload balancing nor failover. Consequently, you cannot achieve high availability for your applications without handling both workload balancing and failover explicitly in your application. IBM HTTP enables you to achieve workload balancing and failover with WebSphere clusters. By setting up an IBM HTTP cluster, you complete your HA topology and ensure that all the components in your system have backups. Java Message Service In addition to using RMI and web services, InfoSphere MDM allows you to access services by using Java Message Service (JMS). Additionally, the InfoSphere MDM notification framework uses JMS to issue notifications of events and transactions that other applications can consume. A key consideration when employing messaging for InfoSphere MDM is to assure that after you post a message onto the queue, it will be processed successfully. There is a risk that a server in the cluster will pick up the message from the queue and fail. You will not know that your queue message was not successfully processed. Ensure that your messaging engine provides the ability to persist messages, and to remove them from the queue only after they have been successfully processed. Two JMS implementations are available: WebSphere Network Deployment embedded JMS provider and IBM WebSphere MQ. While it is beyond the scope of this document to describe WebSphere MQ in detail, it is recommended that you use WebSphere MQ as your JMS provider.

16 Achieving high availability and scalability with IBM InfoSphere MDM Page 16 Database high availability Database high availability is an extensive topic by itself. It is beyond the scope of this document to describe IBM DB2 high availability in detail. Here we briefly survey the significant features offered by DB2. To achieve high availability for IBM DB2 for Linux, UNIX and Windows, Version 9.5 and 9.7, the following features are available: DB2 high availability disaster recovery is a database replication feature that protects against data loss and provides failover ability to its client applications by replicating data from a source database, called the primary database, to a target database, called the standby database. Updates to the standby database are made by sending the log records to the standby database. The HADR standby database continuously replays all the log records to keep in sync with the primary database. Automatic client reroute is a database feature that allows you to provide an alternate server location that clients can redirect requests to if the primary database server fails. DB2 high availability feature enables the integration between the IBM Data and cluster management software, which automates the process of monitoring the system and the failover process if the database server goes down. Other features that are available for IBM DB2 on z/os are listed in Appendix 2.

17 Achieving high availability and scalability with IBM InfoSphere MDM Page 17 Deploying InfoSphere MDM onto a cluster InfoSphere MDM architecture and components InfoSphere MDM is a large, sophisticated application with components spanning the three tiers of an enterprise application. The following diagram illustrates the significant components of InfoSphere MDM : Java EE Client MDM Batch Processor RMI Java EE Client MDM Event Manager Client RMI Java EE Client MDM Config Management Console RMI JMS MDM JMS Adapter MDM JMS JMS Get name of deployment module Get name of deployment module MDM EJBs MDM Admin EJBs MDM Event Manager MDBs MDM Notification Framework MDM Config Repository MDM Web Services Data Steward -ship UI Admin UI EJB Container Web Container Figure 7: InfoSphere MDM consists of these main components: the MDM JEE application, the Data Stewardship UI, and the Admin UI. InfoSphere MDM Java EE components Note: In this document the term InfoSphere MDM refers to the InfoSphere MDM product. MDM refers to the EJB application, a component of InfoSphere MDM, which is installed onto the cluster. InfoSphere MDM consists of three main components that are deployed onto an application server. It consists of the MDM which is the core business application. It is the application that other applications will access to store and retrieve their master data. InfoSphere MDM also consists of two web-based UI applications: the Data Stewardship UI and the Administration UI.

18 Achieving high availability and scalability with IBM InfoSphere MDM Page 18 MDM is the enterprise server application that contains the EJBs and web services that comprise the core of InfoSphere MDM capabilities. In addition to the EJBs and web services, it also includes the InfoSphere MDM notification framework that enables JMS-based communication with external applications; the InfoSphere MDM JMS adapter that enables JMS-based communications with InfoSphere MDM ; the administration EJBs that enable the maintenance of the InfoSphere MDM code tables and the configuration of its business parameters; and InfoSphere MDM Configuration Management Component that enables the configuration of InfoSphere MDM behavior and the enabling or disabling of various features. The Data Stewardship UI is used by the data stewards of an organization to manage the data stored within InfoSphere MDM. Activities performed within the DataSteward UI include editing parties (people or organizations), managing duplicates, and so on. The Business Administration UI is used by InfoSphere MDM system administrators to configure InfoSphere MDM, including configuring code tables, enabling or disabling behavioral extensions, and so on. The Data Stewardship UI and the Business Administration UI are web applications that are also clients to the MDM EJB application. They use RMI to connect to MDM and follow the same HA mechanism as external Java clients that access MDM EJB components. InfoSphere MDM also consists of several components that run outside MDM and access the MDM application as Java EE clients. They include the Batch Processor, the Event Manager Client, and Configuration Management Component. The Event Manager client is a Java EE client application used to control the time-based events within Event Manager. The Configuration Management Component is used to edit configuration items in the InfoSphere MDM configuration repository. The Batch Processor is used to perform bulk operations such as bulk loads or bulk updates in InfoSphere MDM. The Installation Verification Tool is a test client that you can use to validate the InfoSphere MDM installation. You can also use it to validate your XML-based transactions as you develop them. Deploying InfoSphere MDM onto a cluster Overview As mentioned earlier, a WebSphere Network Deployment cluster is like a large, distributed, virtual server spanning many application servers (and likely spanning several computers). When you install InfoSphere MDM onto a cluster, you are physically installing it on several computers simultaneously. Fortunately, WebSphere Network Deployment does all the work for you. All you need to do is specify the cluster (or clusters) and let WebSphere Network Deployment do the rest. Furthermore,

19 Achieving high availability and scalability with IBM InfoSphere MDM Page 19 the InfoSphere MDM installer allows you to specify whether you want to install InfoSphere MDM and its components on a cluster. Guideline: Where possible, install InfoSphere MDM directly onto a cluster. Avoid the complexities of installing InfoSphere MDM on a single WebSphere server, and then converting it to a cluster. Our cluster strategy InfoSphere MDM consists of three Java EE applications: MDM, the EJB server; the Data Stewardship user interface; and the Business Administration user interface. These conform to the Model-View-Controller design pattern of Java EE by separating the business logic from the user interface. Being separate applications, they might be subject to different frequencies of updates or patches. Consequently, it is advisable to separate the applications from each other onto separate clusters. Guideline: After you install and configure WebSphere Network Deployment on the computers you will use to run InfoSphere MDM, create at least two clusters: one for MDM and one for the Data Stewardship user interface application 4. Guideline: Employ a mix of vertical and horizontal clustering as your hardware capability warrants. The following diagram provides an overview of a hypothetical deployment of InfoSphere MDM with four computers (named Pickerel, Pike, Sturgeon, and Rockbass): 4 Note that InfoSphere MDM consists of a third application, the Business Admin UI. This application is used to perform configuration functions for MDM such as changing the code in a code table. These functions are quite infrequent and are carried out by a relatively small number of people. Consequently, clustering the Business Admin UI for HA is not vital. We leave it up to you.

20 Achieving high availability and scalability with IBM InfoSphere MDM Page 20 InfoSphere MDM Three Tiers Architecture Scenario on Rockbass, Sturgeon, Pike, and Pickerel Pickerel Sturgeon AdminUI _21 DataStewardUI _21 MDM_21 IBM IHS Plug-in AdminUI _22 DataStewardUI _21 MDM_22 Laptops Node Agent Node Agent Pike Rockbass Database MDMSVCS1 Schema: rocsvcs1 AdminUI _11 DataStewardUI _21 MDM_11 Laptops IBM IHS Plug-in Deployment Manager Node Agent Node Agent For simplicity, we have not drawn lines between AdminUI and InfoSphere MDM or show the WebSphere MQ. Figure 8: Example deployment of InfoSphere MDM on four computers. Two computers run IBM HTTP and form the front end to InfoSphere MDM server. Two computers run a cluster that runs InfoSphere MDM and the InfoSphere MDM UIs. Following the recommendations that we made earlier, we will create two clusters: MDM Cluster, onto which we will install InfoSphere MDM, and DataStewardUI_Cluster, onto which we will install the data stewardship web applications. For consistency and symmetry for our example, we will also create a third cluster, the AdminUI_Cluster, onto which we will install the MDM Business Admin UI web application. The following diagram shows the three clusters configured and running in the WebSphere Network Deployment administrative console.

21 Achieving high availability and scalability with IBM InfoSphere MDM Page 21 Figure 9: This screen capture shows how cluster names and status are displayed in the WebSphere administrative console We will follow our recommendations and implement both a vertical and horizontal clustering strategy. Our cluster will span two computers: Rockbass and Sturgeon (horizontal clustering). Our IT department informed us that Sturgeon is a more powerful computer and so, for each of our three clusters, we will create two application servers (vertical clustering) on it and a single application server on Rockbass. These six application servers, along with the deployment manager and two node agents make up the DefaultCoreGroup to provide high availability. We will also install IBM HTTP and the WebSphere plug-in on the Pike and Pickerel computers. By creating a cluster of the IBM HTTP, we will use a single virtual IP address between both. The default computer in the cluster is Pike. If Pike fails, Pickerel will take over; however, our clients will continue to address Pike because both Pike and Pickerel share the same virtual IP address. Installing InfoSphere MDM onto our cluster After preparing the cluster environment, we can install InfoSphere MDM, the BusinessAdmin web application, and the DataStewardship web application. During installation, for each of the three InfoSphere MDM Java EE applications, you must specify that you want to install it onto a cluster. You do this by selecting a check box as shown in the following illustration:

22 Achieving high availability and scalability with IBM InfoSphere MDM Page 22 Figure 10: Installing Java EE applications onto a cluster. After you pick the computer on which Deployment Manager is installed, the MDM installer lists the clusters that are managed by that deployment manager. After you specify that you want to install InfoSphere MDM on a cluster, you can select the cluster from the list, as shown in the preceding illustration. The same is true for the other InfoSphere MDM Java EE applications as shown in the following illustrations: Figure 11: Selecting a cluster. As this illustration shows, if you created separate clusters for the InfoSphere MDM UIs, you can select the appropriate cluster, depending on whether you are installing the InfoSphere MDM JEE application or the Admin or Data Stewardship UIs. In this instance, the cluster for the Admin UI is selected during the installation of the Admin UI component.

23 Achieving high availability and scalability with IBM InfoSphere MDM Page 23 Figure 12: Selecting a cluster. As this illustration shows, if you created separate clusters for the InfoSphere MDM UIs, you can select the appropriate cluster, depending on whether you are installing the InfoSphere MDM JEE application or the Admin or Data Stewardship UIs. In this instance, the cluster for the Data Stewardship UI is selected during the installation of the Data Stewardship UI component. After the installation, you will see all applications are deployed onto the cluster, instead of on separate application servers. All resources, including JDBC data sources, Queue connection factories, Queue destinations, Topic connection factories, Topic destinations, Activation specifications (if you use WebSphere default messaging provider for InfoSphere MDM ) defined for InfoSphere MDM are defined at the cluster level by default. This ensures that they are available to all the members of the cluster. Also, if you change one of those resources, the changes will apply to all the members of the cluster. Installing the non-java EE components of InfoSphere MDM These components can be installed anywhere you like. They can be installed on client computers or other server computers. After you install them, you have to configure them so that they know on which computers the Java EE components are installed. This topic is discussed more fully in the next section. Postinstallation configuration steps Pointing client applications to the InfoSphere MDM on the cluster For each client component, you have to update a properties file to ensure that the client component can find the InfoSphere MDM application on the cluster where it is installed. Each client component has a properties file that includes an entry named NAME_SERVER_URL, or Configuration.provider_url, or java.naming.provider.url. The applications use that entry to locate the bootstrap port address for the EJBs that make up the MDM Java EE application. For the cluster that we created, we will update the components as follows:

24 Achieving high availability and scalability with IBM InfoSphere MDM Page 24 corbaloc:iiop:rockbass:2811,:sturgeon:2811,2812 where rockbass and sturgeon are the computer DNS names and the numbers 2811 and 2812 are the bootstrap port numbers for the application servers in the cluster named MDM_Cluster. The following list shows the InfoSphere MDM client components and the entry in each of the properties files for the bootstrap locations of the InfoSphere MDM application: Install Verification Tool (verify.sh): NAME_SERVER_URL=corbaloc:iiop:rockbass:2811,:sturgeon:2811,2812 BatchProcessor (Batch.properties): Configuration.provider_url = corbaloc:iiop:rockbass:2811,:sturgeon:2811,2812 eventmanagerclient (EventManagerClient.properties)) ProcessControllerInternal.PROVIDER_URL= corbaloc:iiop:rockbass:2811,:sturgeon:2811,2812 BusinessAdmin web application (mdmuiconfiguration.properties within propertiesui.jar) java.naming.provider.url= corbaloc:iiop:rockbass:2811,:sturgeon:2811,2812 DataStewardship web application (mdmuiconfiguration.properties within propertiesui.jar) java.naming.provider.url= corbaloc:iiop:rockbass:2811,:sturgeon:2811,2812 Guideline: In order for the client applications to take full advantage of InfoSphere MDM running on a cluster, update the provider URLs to ensure that they point to all the servers on the cluster on which InfoSphere MDM is running. This step ensures that there is no single point of failure when a client application attempts to obtain the initial context of an EJB from a single cluster member that might not be operational. Updating the Configuration Management Component repository The Configuration Management Component stores configuration items that govern the behavior of InfoSphere MDM in its repository. One of the behaviors that it governs is the generation of primary keys for each of the business tables in the InfoSphere MDM database. To ensure that InfoSphere MDM running on separate cluster members doe not inadvertently create identical primary keys for different rows in the same business table, the configuration management component can be used to stipulate separate application instances and the instance ID to the primary keys that each one creates. We do this by running the following SQL on the Configuration Management database (Note: Your values might be different based on the data that is already in your tables): insert into appinstance (INSTANCE_ID,DEPLOYMENT_ID,NAME,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'instance01',current_timestamp,null); insert into appinstance (INSTANCE_ID,DEPLOYMENT_ID,NAME,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'instance02',current_timestamp,null); insert into appinstance (INSTANCE_ID,DEPLOYMENT_ID,NAME,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'instance03',current_timestamp,null); insert into configelement (ELEMENT_ID,DEPLOYMENT_ID,NAME,VALUE,VALUE_DEFAULT,INSTANCE_ID,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'/ibm/coreutilities/keygeneration/instancepkidentifier','01','', ,current_timestamp,null); insert into configelement (ELEMENT_ID,DEPLOYMENT_ID,NAME,VALUE,VALUE_DEFAULT,INSTANCE_ID,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'/ibm/coreutilities/keygeneration/instancepkidentifier','02','', ,current_timestamp,null);

25 Achieving high availability and scalability with IBM InfoSphere MDM Page 25 insert into configelement (ELEMENT_ID,DEPLOYMENT_ID,NAME,VALUE,VALUE_DEFAULT,INSTANCE_ID,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'/ibm/coreutilities/keygeneration/instancepkidentifier','03','', ,current_timestamp,null); insert into configelement (ELEMENT_ID,DEPLOYMENT_ID,NAME,VALUE,VALUE_DEFAULT,INSTANCE_ID,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'/ibm/dwlcommonservices/keygeneration/instancepkidentifier','01','', ,current_timestamp,null); insert into configelement (ELEMENT_ID,DEPLOYMENT_ID,NAME,VALUE,VALUE_DEFAULT,INSTANCE_ID,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'/ibm/dwlcommonservices/keygeneration/instancepkidentifier','02','', ,current_timestamp,null); insert into configelement (ELEMENT_ID,DEPLOYMENT_ID,NAME,VALUE,VALUE_DEFAULT,INSTANCE_ID,LAST_UPDATE_DT,LAST_UPDATE_USER) values( , ,'/ibm/coreutilities/keygeneration/instancepkidentifier','03','', ,current_timestamp,null); The DEPLOYMENT_ID in the SQL shown in the preceding example can be retrieved from the deployment table. Guideline: To ensure that the primary keys that InfoSphere MDM generates for its business tables are unique, you must add an entry to the APPINSTANCE table for each member of the cluster on which MDM is installed. Updating the config/bootstrap.properties file On each cluster member, you must update the config/bootstrap.properties file in the properties.jar file. The file is in the MDM application EAR file. The following example illustrates a command for extracting the file from the application server profile on the Rockbass computer: ws7admin:rockbass:/usr/ibm/websphere7/app/profiles/demoappsrv01/installedapps/rockbasscell0 1/MDM-App.ear> ws7admin:rockbass:/usr/ibm/websphere7/app/profiles/demoappsrv01/installedapps/rockbasscell0 1/MDM-App.ear> jar -tvf properties.jar config 0 Tue Apr 20 23:21:08 EDT 2010 config/ 9635 Thu Apr 22 18:35:18 EDT 2010 config/bootstrap.properties ws7admin:rockbass:/usr/ibm/websphere7/app/profiles/demoappsrv01/installedapps/rockbasscell0 1/MDM-App.ear> In our case we have two cluster members running MDM on MDM_Cluster. We will do the updates as follows: For cluster member one, Rockbass: # # Runtime Instance Name # # # Specifies the name of the application runtime instance. # The meaning of this name depends on the edition of the application. # J2EE : name of the cluster node on which the instance runs # J2SE : convention-based name to reflect the purpose of running the instance # # An instance name is not typically required and can be left empty. #

26 Achieving high availability and scalability with IBM InfoSphere MDM Page 26 # Examples: # instance.name=server-01 # instance.name=monthly instance.name=instance01 The name in instance.name must match the name of the instance that was created in the APPINSTANCE table in the Configuration Management repository. Restart each cluster member after you update the properties file. We have now finished installing and configuring InfoSphere MDM to operate on our clusters. Guideline To ensure that InfoSphere MDM generates unique primary keys across all cluster members, you must update the config/bootstrap.properties file in the properties.jar file for InfoSphere MDM on each cluster member with a unique instance name. Other scenarios Converting InfoSphere MDM from a stand-alone instance to a cluster The scenario described here assumes that the cluster has been configured before you install InfoSphere MDM. This is the recommended approach. However, if you find that you need to redeploy InfoSphere MDM from a single server instance onto a cluster, we present an approach in Appendix 1 - Converting InfoSphere MDM from a stand-alone server to a cluster. Configuring the IBM HTTP s to access InfoSphere MDM web services and web content After installing MDM and the web-based user interfaces on InfoSphere MDM, you can configure IBM HTTP. Recall that in the preceding diagram IBM HTTP and the WebSphere plug-in are installed on two additional computers: Pike and Pickerel. Recall from our earlier discussion that IBM HTTP uses a file named plugincfg.xml. That file contains a list of the URLs of all the web content, web services, and the associated host computers to which the IBM HTTP will have access. Recall that you can view the contents of the plugin-cfg.xml file from the WebSphere administrative console by navigating to s Web s menu item, and then clicking the web server that you configured. Then click the Plug-in Properties link. In the resulting pane, click the View button next to the text box containing plugin-cfg.xml to view the contents of the file. It will contain the URLs and port numbers of the Data Stewardship UI, the Business Administration UI, and the InfoSphere MDM Web Services endpoints.

27 Achieving high availability and scalability with IBM InfoSphere MDM Page 27 Testing the installation for high availability Overview After the deployment and configuration of InfoSphere MDM is completed, it is a good practice to verify that the failover and workload balancing are indeed functioning. InfoSphere MDM provides the Installation Verification Tool (IVT) for testing. It invokes simple transactions on InfoSphere MDM. You can also use the InfoSphere MDM Batch Processor as a test tool. It performs high volume operations that will enable you to confirm that WebSphere is correctly balancing the load across all the servers in the cluster. Finally, you have to test that you can access InfoSphere MDM web services and the InfoSphere MDM web applications (the Data Stewardship UI and the Business Administration UI. In a later section we describe how to write code to access InfoSphere MDM components. You can adapt the examples to write your own applications that test and stress test InfoSphere MDM on a cluster. Using the Installation Verification Tool This is a simple test. The Installation Verification Tool (IVT) invokes a single transaction on InfoSphere MDM. You can use the WebSphere Network Deployment administrative console to alternately shut down one of the servers on the MDM_Cluster. You can then use the IVT to execute InfoSphere MDM services, such as adding a party or an organization. If everything is configured and running correctly, InfoSphere MDM returns a SUCCESS status to the IVT. You can run the test repeatedly while alternating which servers have been shut down. Using the Batch Processor This is a more sophisticated test. This test can be used for both fault tolerance and workload balancing for MDM operating on the MDM_Cluster. The InfoSphere MDM Batch Processor is designed to load large volumes of data into InfoSphere MDM quickly. Consequently it is an excellent tool to verify the workload balancing and fault tolerance of an HA topology. It works by reading an input file consisting of MDM transactions formatted according to an MDM XML-based API, and executing each one sequentially. It can also be configured to invoke the MDM transactions in parallel. You can control the number of parallel threads by specifying the number of submitters in the Batch.properties file that is in the directory into which you installed the Batch Processor. For example, to set up the Batch Processor to invoke two streams, you can set the number of submitters to 2 as follows: Submitter.number = 2