E-Business Clustering and High Availability

Transcription

1 On demand business solutions White paper Clustering and high availability in an enterprise service bus. February 2005

2 Page 2 Contents 2 Introduction 2 What is an ESB? 3 Services on an ESB 4 Why should you want an ESB? 6 An ESB based on IBM products 6 ESBs and clustering and high availability 8 Defining high availability and clustering 10 Typical clustering and high-availability scenarios 11 Why and when are high availability and clustering desirable? 12 Providing high-availability for ESBs 13 Delivering high availability and clustering 15 High availability 17 Broker backup and recovery 19 Clustering in an ESB 22 Conclusion 23 For more information Introduction This paper explores clustering and high-availability considerations when operating an enterprise service bus (ESB). It examines what an ESB is, including why you might need an ESB. It also includes some typical clustering and high-availability scenarios to help illustrate these points. What is an ESB? An ESB is an architectural pattern that enables you to optimize the distribution of information between different types of applications across multiple locations. The ESB pattern is founded on and unifies message-oriented, event-driven and service-oriented approaches to integration. The core characteristics of an ESB (all of which should be oriented toward a service-based infrastructure) provide: Standards-based application integration Support for Web services, message-based transport and publish-and-subscribe (event-based) integration Transformation Intelligent routing At its most basic level, an ESB is an architectural construct that links services provided within an enterprise. It supports open standards, as well as a selection of communications models. Together, these enable: Web services to communicate with other Web services Messaging applications often using application programming interfaces (APIs), like Message Queue Interface (MQI) or Java Message Service (JMS) to communicate with each other Support for differing communications models, such as publish-and-subscribe or event-style communications

3 Page 3 From this set of capabilities, you can understand why the term bus is used. Information is transported between many different destinations between originators and receivers who might be using different communications models and data formats. For this reason, an ESB is an artifact designed to support interoperation between different sources and destinations such as JMS to Web services, Web services to IBM CICS systems, publish-andsubscribe to point-to-point integration and so on. A distinct advantage of an ESB is the flexibility it can provide. You (the user) can decide which of the different capabilities of an ESB you want to use. For example, you might want to specialize on just point-to-point style or publishand-subscribe communications. Or you can exploit extended ESB capabilities like transformation of messages, dynamic routing, message enrichment and so on to derive even greater value. Services on an ESB When considering an ESB, you should understand that it is an enterprise service bus. Many services are provided, even if not all services are necessarily exposed externally. For example, ESBs are often regarded as a key step in delivering a service-oriented architecture (SOA). In an SOA, the objective is to provide a logical infrastructure that enables applications to have their interfaces exposed as services that can then be accessed through the ESB (see Figure 1). At the same time, when a message arrives on an ESB, it might invoke some internal ESB service such as a transformation service which can take one format and turn it into another that is acceptable to a different application. In other words, an ESB uses services as a means to work with external sources and destinations. Yet an ESB also has services that it can provide internally (over the bus), like transformation, routing, encryption and enrichment.

4 Page 4 Portal service Simple Object Access Protocol (SOAP) service request Business-tobusiness (B2B) interactions Enterprise service bus Common run-time environment Service flow Data Existing applications New service logic Figure 1. A conceptual view of an ESB Why should you want an ESB? An ESB is the logical next step in the evolution of messaging and of integration technologies. If you think of an SOA as providing consistent ways to describe the endpoints in an enterprise, an ESB offers the mechanism to achieve an SOA. But an ESB can do more. It can provide a mechanism to map and then view the available resources within your organization. Any ESB must be able to provide seamless management capability across an enterprise, as well as heterogeneous communications between services running on the many different types of platforms that are common in most enterprises. This richness and increased transparency means, at one level, that it should take less effort to integrate heterogeneous environments. On another level, the ability to describe and exploit enterprise resources opens up new options for interoperation, while requiring fewer skills to deliver both development and day-to-day operations.

5 Page 5 In reality, ESBs can be used quite differently by different types of organizations. Endpoint users can leverage the ESB s capabilities to gain easy access to the bus to invoke other services. Specialist users can build an organization s ESB and extend it to match that enterprise s specific requirements. This latter group can map and configure what is achieved with an ESB. Specialist users can put into practice what an SOA charts out: define the flows between what comes in and what goes out over the ESB, create the libraries for transformations and routing logic, and so on. The important thing to remember is that there are two separate sets of logic: external applications logic and internal (to the ESB) logic (shown in Figure 2). Requester ESB Integration services Provider Figure 2. Illustrating external and internal (to the ESB) logic Part of the value that an ESB offers is its ability to specialize. Different skills are required for those providing the internal logic. One measure of an ESB s success is how little developers creating external application logic need to know about the details of working with other applications. And this introduces yet another benefit. Development can occur in a decoupled form: the different development groups external source application developers, ESB specialists and external destination application developers do not need to wait for others to complete work to make progress on their individual tasks.

6 Page 6 An ESB based on IBM products IBM WebSphere MQ can provide the base for an ESB with point-to-point messaging, some publish-and-subscribe capability and clustering function. IBM WebSphere MQ Everyplace complements these capabilities with reduced-footprint messaging for small devices like personal digital assistants (PDAs). Higher in the ESB function stack, IBM WebSphere Business Integration Event Broker and IBM WebSphere Business Integration Message Broker provide value-add services such as routing, transformation and rules-definition handling, as well as fan-in and fan-out capabilities. If you need tight links to the Java development and run-time environments, IBM WebSphere Application Server can provide this function, as well as more-advanced Web-services capabilities. ESBs and clustering and high availability Conceptually, an ESB is a logical construct made up of multiple physical instances (and even multiple products) that combine to deliver ESB capabilities. You might choose to have one ESB with several instances of the software in one location (like a giant hub), while another organization might prefer to have many instances distributed around the enterprise or organization. Either is possible, as are a variety of combinations in between. As a result, it is conceivable that you might choose to begin with a relatively simple ESB with only a limited set of functions. This ESB might include only one communications style Web services, point-to-point or publish-andsubscribe, for example. Or you might want to exercise the capabilities of your ESB to the fullest and need the widest range of capabilities from the start including content-based routing, transformation, enrichment, encryption and so on. Regardless of the scope of your ESB, the common factor among ESBs is that they rapidly become mission critical (see Figure 3). They are buses (or hubs, depending on how you prefer to draw the topology) through which data flows. If these focal points fail, so can the processes that connect to and depend on them. This is directly analogous to a telephone exchange or switch. If one exchange fails, all those attached to it, upstream and downstream, are affected (even if in differing ways with differing consequences).

7 Page 7 Retek ESB SAP Manugistics i2 Ariba MatrixOne IBM Figure 3. The mission-critical nature of an ESB Therefore, the communication infrastructure associated with an ESB is a critical dimension. You cannot conduct business if your infrastructure is not working. Availability is critical. Indeed, a point that is often missed until it is thought about in detail is that an ESB needs a higher level of availability than the applications it connects. For this reason, it is vital that your ESB works when it is needed, and that it can cope with the workloads placed on it. When it is mission-critical that an ESB continues to operate, clustering and high availability can provide a solution. In fact, it is reasonable to argue that implementing an ESB that cannot deliver high availability (by whatever means) is inadequate for an enterprise environment.

8 Page 8 Defining high availability and clustering High availability refers to the ability of a software and hardware solution to recover from unpredictable interruptions, including: Failure of a piece of hardware, such as a processor Failure within a piece of software, such as when a bug causes the program to crash in an unrecoverable way A system that cannot cope with a piece of information being processed (because no error-handling case is defined) The most extreme example of failure is where an entire site, where systems are running, is destroyed by fire or flooding, for example. The ability to recover from disasters both large and small and continue to operate is the objective of high availability. With high availability, a system can detect failures and automatically initiate a recovery process that results in the system being restarted either on the same hardware, or on backup equipment (See Figure 4). Local disk Local disk Shared disks Queue manager data Queue manager logs Figure 4. Illustration of the high-availability concept

9 Page 9 Clustering goes one step farther in delivering high availability by enabling multiple equivalent systems to operate in parallel, so that if any one should fail, the remaining systems seamlessly step in to accommodate new work. In other words, clustering can be thought of as providing continuous availability (see Figure 5). Queue manager 1 Queue manager 2 Qa Qb Qb Local disk Local disk Figure 5. Illustration of the use of clustering Most often, clustering and high availability are combined (see Figure 6), so that a system that fails within a cluster is restarted by the high-availability setup. This is important, because it can prevent work in progress from being stranded in the system when a failure occurs. After the system has failed, you have no way to determine the precise status of the work in progress. For this reason, you must be able to initiate appropriate recovery steps.

10 Page 10 High availability is used to recover the work in progress from the failed system by using, for example, shared storage. Shared storage where the status of work in progress is kept can be accessed by another machine in a high-availability configuration. Queue manager 1 Queue manager 2 Qa Qb Qb Local disk Local disk Local disk Local disk Shared disks Shared disks Queue manager data Queue manager data Queue manager logs Queue manager logs Figure 6. Combining clustering and high availability Typical clustering and high-availability scenarios Clustering is typically used to provide continuous availability for a critical part of an organization s infrastructure applications that support the core business processes that deliver service and support to customers and business partners. That infrastructure is likely to include an ESB, because an ESB can provide the connection between most of the applications and systems within the organization. A cluster can be implemented over multiple sites, so that a failure of any one of the key systems does not affect the overall operation. The cluster can also have a high-availability dimension, so that the system failure can be recovered and any work in progress in the system at the time of failure can be restarted.

11 Page 11 High availability is typically used without clustering when a service needs to be available but short outages can be tolerated. A high-availability-only scenario, without clustering, can usually be found in situations where an organization s key infrastructure is replicated at a disaster-recovery site. In the event of a catastrophe at the prime site, the recovery site can automatically take over and systems can resume operation within a relatively short period of time. In this type of scenario, you can assume that the catastrophe would be significant enough to disrupt other aspects of the business. IT infrastructure is unlikely to be the only issue on the critical path to restoring the business to operational status again. Why and when are high availability and clustering desirable? By definition an ESB can link practically every system in an enterprise and enable information to flow in real time. By releasing previously trapped information and distributing it to the people who need it, you can improve the responsiveness and accuracy of decision making. In this central role, an ESB must provide a service level superior to that of the systems it connects. For this reason, its availability must be at least as good as, or better than, all of the connected systems. This availability is particularly important if an ESB has been designed to trade off availability against performance. If you assume that an information flow is never going to be interrupted by a failure, you can choose to optimize the way the information is passed through the bus. That is, you can choose to keep information in memory (which is fast to access) and avoid storing the information on disks (which, by comparison, is slow). For this assumption to hold true, the systems that make up your ESB must always be available. Clustering and high availability can help ensure this availability, and give you confidence that a failure can be avoided.

12 Page 12 Aside from avoiding unexpected interruptions to service, continuous availability is useful for a number of other reasons. Sometimes you need to take systems offline to perform routine maintenance or to install new hardware. You might also need to back up systems and data, or upgrade, test or apply maintenance to software. Your ability to perform these activities without disrupting overall service makes planning easier and helps ensure that the business is not affected. For example, your staff would be far less likely to have to work weekends or nights to fit the work into off-peak times. Clustering also enables multiple systems to share work, so you can balance workloads more effectively. For example, high-priority work might normally be assigned to the most powerful machine. Taken to the next level, clustering can be used dynamically and flexibly to respond to changing priorities. If a cutoff time exists for certain types of transactions, you can (prior to the cutoff) make other resources available to help handle the increased workload. And at other times, you can adjust the priority to reflect other usage patterns. Providing high-availability for ESBs When you consider how to provide robustness for your ESB, you should consider the several different dimensions that can be provided at different levels. You can start by taking into account how applications connect to your ESB. Applications must always be able to connect to the ESB, even if a failure has originated from a component within the ESB. WebSphere MQ users can configure a WebSphere MQ client so that it selects the first available WebSphere MQ queue manager to which it can connect. Through this configuration, an application can always connect to an entry point on the ESB. And you can know that after it has connected, the persistence capability of WebSphere MQ will not lose any messages.

13 Page 13 You must also consider the availability of the WebSphere MQ queue manager, and the resources that it owns. A queue manager owns the queues and associated files and the logs that it needs to run. In many cases, the need for high availability means that alternate backup or mirroring capabilities are required so that resources can be recovered quickly. In most cases, some form of hot-standby capability is used. Within an ESB, other considerations also apply. When a message is being routed through an ESB, the message must be routed around failing components within that ESB, without losing the message (if this is a requirement). One reason for implementing multiple ESB instances that communicate closely with each other is to provide alternate processing options or paths if these are needed to help ensure that messages reach their intended destinations. Implicit in this approach is that an ESB has the capability, if necessary, to help ensure that anything arriving on an ESB is not lost even if an instance of an ESB fails. Assured once-and-once-only delivery might not be needed by every user of an ESB. However, it is important to consider your needs for this capability early on, because adding it after the loss of a US$500 million transfer, for example, could not repair that loss. For those messages that require absolute reliability, the ESB must take absolute care of them. Equally, messages that do not need such care can be discarded with minimal ill effects when failures occur. Delivering high availability and clustering Applications that are external to your ESB must find an available queue manager to connect to (if using a client connection). Alternatively, these applications might use a specifically designated queue manager. In this case, you might prefer a High-Availability Cluster Multiprocessing (IBM HACMP ) solution to help ensure that hot-standby systems are available when you need them.

14 Page 14 After an application is connected and the messages it is sending are being accepted, the issue turns to how you feed the data in the messages to the components of the ESB, as required. One way to help ensure availability is to have multiple instances of the ESB function available, either within an ESB instance or through numerous ESB instances. For example, if you have a straight-through processing (STP) request, which is going from a requesting application to a receiving application, you can use WebSphere MQ clustering. WebSphere MQ clustering can have multiple instances of the receiving application running so that if one fails, another instance can automatically take up the work. Clustering is equally applicable to functions within the ESB. For example, if your ESB includes a broker function to provide transformation and routing within the ESB, multiple instances of that broker function can be configured so that the message can be routed to a broker that is available (see Figure 7). Publishers WebSphere MQ cluster Broker and queue manager Subscribers Publisher queue manager Subscriber queue manager Broker and queue manager Figure 7. Broker clustering example

15 Page 15 These instances can be located on one or many machines. If an ESB instance fails altogether, all the work on it must be recovered. But if you ve planned carefully, the failure of one instance with the work that it is performing need not impair your organization s ability to complete other workloads while the system that failed is recovered. The differences between these approaches are: The activity before a message arrives on an ESB and after it leaves The period when the message is actually on the ESB Using clustering can materially assist the handling of the first approach to provide both performance and high availability. Before hitting a specific instance of the ESB, you can redirect messages to another ESB instance. In the second approach, high-availability approaches like hot-standby HACMP are probably more relevant. After a message has been accepted onto the ESB, it is usually preferable to recover that instance (because you want to avoid unintended duplication or reprocessing). High availability High availability in an ESB involves using a combination of product and operating-system facilities to help ensure the recovery of data following an unexpected failure. An ESB is a distributed solution that typically runs on multiple machines. For this reason, ESB-relevant high-availability capabilities can be implemented in several places (see Figure 8). First, applications that connect to an ESB can run on a machine that might be covered by high-availability recovery. Applications that take advantage of the store-and-forward capabilities of WebSphere MQ access a queue manager, which is responsible for keeping messages until they can be safely passed on. To provide a high-availability solution, WebSphere MQ supports operatingsystem facilities that permit a queue manager to be restarted on an alternative machine. For example, if your primary machine fails, you can restart the application and queue manager on a failover machine.

16 Page 16 Applications that use a queue manager on a separate machine can connect using a client that supports a lookup table. You can specify a number of different queue managers in the lookup table, and a connection is automatically made to the first available queue manager. This method makes the queue manager transparent to the application it is connecting to. This assumes that multiple equivalent queue managers are available, which is where clustering comes into play. Publishers WebSphere MQ cluster Broker and queue manager (under high availability) Subscribers Publisher queue manager (under high availability) Broker and queue manager (under high availability) Subscriber queue manager (under high availability) Figure 8. ESB exploiting high availability and clustering High-availability subscribers In contrast, applications that use lightweight protocols to connect to an ESB such as IBM WebSphere MQ Real-Time Transport do not use queue managers to store and forward messages. Instead, they take advantage of facilities in the TCP/IP networking infrastructure to switch automatically to alternative addresses if connections fail. Alternatively, with WebSphere MQ Everyplace, applications can use rules defined in the WebSphere MQ Everyplace configuration to implement automatic failover to an alternative broker in the event of a failure.

17 Page 17 Second, the brokers that constitute an ESB usually run on separate machines. Because each broker runs on top of a queue manager, the high-availability techniques described before for applications can be applied. The broker can be covered by high-availability facilities that enable it to be restarted on a failover machine. Broker backup and recovery For a full picture of broker backup and recovery, you must understand that a complete broker system consists of three parts (illustrated in Figure 9): The broker itself, where the work is performed. A configuration manager that can handle one or more brokers. The system configuration options (for example, the number of processes and threads to run in the broker) and deployment topologies (broker collectives) are located in the configuration manager. The tool set, with a repository for the definitions of the work to be performed. The two types of definitions of work to be performed include: Message sets, which describe the structure of the information that the broker processes. Message flows, which describe the processing activities to be performed on the information. Compiled messages flows and sets Broker Toolkit users Configuration manager Broker Broker Figure 9. ESB broker and configuration manager

18 Page 18 The configuration manager and the tool set (and its repository) are not directly used after a broker has been configured and starts running. For this reason, it is not necessary to have high availability involved with automatic restarts of these components so your broker can continue to work. However, you should also consider another level of availability how to recover an ESB in the event of an unexpected failure. This process uses many of the same facilities as high-availability solutions, but does not extend to provide automated recovery. The methods for handling such instances involve backing up and recovering running systems to a consistent state following a failure. Queue managers enable a snapshot of a running system to be taken. You can archive the snapshot onto near-line or offline storage and use it in the event of a disaster to re-create the queue manager. Similarly, brokers that are part of an ESB can have their configurations archived using facilities of the database (IBM DB2, Oracle and so on) that is used to store their configurations. In much the same way, the WebSphere Business Integration Message Broker configuration manager uses an embedded database (a version of DB2) that can be archived using database facilities. The repository that underpins the tool set, where broker message flows and message-set definitions are stored, should possess some form of source code management system, such as that provided by IBM Rational ClearCase software. These systems tend to have their own backup and recovery facilities.

19 Page 19 Clustering in an ESB The objective of clustering, as described before, is to provide continuous availability. For an ESB, this means that systems connected to an ESB can continue to connect to the ESB, and to exchange information with other connected systems, without disrupting service. Clustering is achieved by configuring multiple equivalent systems, so that in the event of a failure in one system, at least one other system is able to take on new work in place of the failed system. In this context, an ESB is made up of several components. The first place to consider clustering is with WebSphere MQ queue managers. WebSphere MQ can support clusters of queue managers. Each queue-manager cluster is an operational and administrative unit. Queue managers within a cluster can run on a variety of hardware and operating systems and yet perform equivalent work. To make this happen, each queue manager has its own resources, including queues where messages are stored. In the event of a failure, the messages being handled by particular queue manager are inaccessible by any other queue manager because they are in an indeterminate state. You can overcome this problem in two ways. First, you can use high-availability facilities to restart a queue manager on an alternate machine and so recover that queue manager s resources. Alternatively, if you are using the IBM z/os operating system, you can exploit the shared-queue facility. Shared queues exist in the z/os coupling facility and can be accessed simultaneously by multiple queue managers running on different machines within an IBM Parallel Sysplex environment. In this case, even if a machine or queue manager fails, the resources are still available.

20 Page 20 The second place to consider clustering is with the brokers that form the backbone of an ESB. In this case, you can use clustering to make a set of brokers appear as a single broker to applications. Brokers can perform a number of tasks within an ESB, including routing and transformation of messages. Dynamic routing definitions are essentially based on interests registered by applications, referred to as subscriptions. When an application registers a subscription with a broker, it indicates that it wants to receive information based on a set of selection criteria that defines the scope of its interests. Brokers use the selection criteria specified in subscriptions to determine where to send each piece of information that passes through. Brokers can also provide a facility to automatically clone subscriptions, so that if one broker fails, another can automatically carry on in its place. This facility is normally used with queue-manager clustering to help ensure that failure of a broker can be counteracted by another queue manager and broker within a cluster taking on new work. A related concept with brokers and subscriptions is called broker collectives (see Figure 10). Broker collectives allow allow a group of brokers to share work based on split responsibilities. An example of how this might be implemented is with an ESB providing a backbone for information distribution within a worldwide organization. The brokers forming the ESB could be designated to each handle a particular geographic area, so systems would connect to the broker for their area. By configuring all of the ESB brokers in a collective, you can help ensure that systems connected to the ESB receive information wherever it may originate.

21 Page 21 Broker domain Collective Collective Collective Collective Collective Collective Figure 10. Broker collectives improve availability. For example, an application connected to a broker covering the U.S. might publish information that is of interest to an application connected to a broker covering Japan. The important feature here is that applications do not need to be aware of the topology of the brokers within the ESB because the brokers automatically share subscription information. Thus, the broker in Japan can automatically register an interest with the U.S. broker on behalf of its application. And any information published by a U.S. application can be routed through to applications connected to the broker in Japan.

22 Page 22 The mediation function of such a broker is defined by the message flows that the broker implements. Message flows define a series of actions that the broker performs on the information as it passes through the broker. Typically, this can involve changing the order of fields within a message, augmenting the message with information from a database or changing the encoding of the data within a message. Message flows are designed using the tool set described earlier and deployed to a broker using a configuration manager. As a result, message flows are more static in nature than subscriptions, which can dynamically change as applications create, update or delete subscriptions. Creating brokers within a cluster that have the same message-flow definitions is possible using a configuration manager. In this way, the behavior of any broker within a cluster configuration can be replicated on one or more failover brokers within the cluster, so that work can be automatically redirected in the event of a failure. Conclusion An ESB is an architectural pattern that enables you to optimize the distribution of information between different types of applications across multiple locations. The ESB pattern is founded on and unifies message-oriented, event-driven and service-oriented approaches to integration. High availability in an ESB involves using a combination of product and operating-system facilities to help ensure the recovery of data following an unexpected failure. Clustering goes one step farther by enabling multiple equivalent systems to operate in parallel, so that if one should fail, the remaining systems can seamlessly step in. For an ESB, this means that systems connected to the ESB can continue to exchange information with other connected systems without disrupting service. In practice, most enterprises need a combination of clustering (to provide the continuous delivery of service for new work) and high availability (to recover the existing work that is on a particular queue manager or ESB instance).

23 Page 23 The benefits of high-availability and clustering arise because an ESB must provide a high level of service to all the applications and systems connected to it. If an ESB supports business-critical processes where information must flow in a timely fashion, investing in high availability and clustering from a time-and-effort perspective and from a hardware-software perspective can be justified and should be considered. For more information To learn more about the enterprise service bus, visit: ibm.com/software/integration/esb

24 Copyright IBM Corporation 2005 IBM Corporation Software Group Route 100 Somers, NY U.S.A. Produced in the United States of America All Rights Reserved CICS, ClearCase, DB2, Everyplace, HACMP, IBM, the IBM logo, the On Demand Business logo, Parallel Sysplex, Rational, WebSphere and z/os are trademarks of International Business Machines Corporation in the United States, other countries or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries or both. Other company, product and service names may be trademarks or service marks of others. This information contained in this document is provided AS IS. Any person or organization using the information is solely responsible for any and all consequences of such use. IBM accepts no responsibility for such consequences. All statements regarding IBM future direction or intent are subject to change or withdrawal without notice and represent goals and objectives only. G