WebSphere Reverse Investor: Runtime management High Availability option, Ultimate Edition

In each column, "websphere® contrarian investors" will answer questions, provide guidance and discuss the underlying topics related to the use of WebSphere products, often giving proven recommendations that contradict popular perceptions.

Back to the old topic--and Latin.

Distance I write implementing a highly available infrastructure for IBM WebSphere application Server network deployment without Ering for nearly 7 years, although the program I described at the time is still widely applicable to WebSphere application Server Network Deployment (hereafter referred to as network deployment) v6.x and V7 .0, but some of the updates to network deployment changed some of the details and provided some additional options for network deployment Run-time management of high Availability (HA). Therefore, I think it is time to renovate this topic. Another advantage is that I always try to find a chance to use the high school Latin that I studied many years ago, and to renovate an earlier article so that I could have the opportunity to use the word redux in the title! It is particularly appropriate to revisit the network deployment Management Runtime feature, as the topic is reviving, or is being revived (my Latin teacher will be very proud!). ）。 The final reason is that I am often asked about this topic, so it is entirely for my own consideration, because the discussion of this topic will provide a more widely available resources, and when someone asks me such a question, I can directly let them refer to this article. In this way, everyone is happy!

Before delving into the network Deployment runtime management options and related techniques for HA, let's take a quick look at the network Deployment Application Server architecture. The network Deployment Application Server is designed to achieve a general degree of self-sufficiency while managing the runtime. Each application server has its own:

Web container.

EJB container.

Name Service.

Security services.

The transaction manager service.

The JMS Messaging Engine (which is optional, depends on the configuration).

JCA Connection Manager (provides JDBC and EIS connections).

Java™management Extensions (JMX) Management Server.

High Availability Manager service.

The Web container is actually an "aggregation (converged) container" that hosts components that are accessed through HTTP (S), such as Servlets, JSPs, and portlets, and components that use Session Initiation Protocol (SIP).

By using the services listed above, the failure of the node agent or Deployment Manager will not affect the running Network Deployment Application Server (subject to several issues that we will discuss later) so that the application request can continue to be processed even if a failure occurs.

If you've ever experienced network deployment, then you know that the evolution from v5.x to v6.x removes most run-time dependencies that were once in the node agent and Deployment Manager. Attentive readers may have noticed that I have just mentioned the realization of a general degree of self-sufficiency while managing the runtime, this does not equate to complete self-sufficiency ... because some features still exist in the node agent and Deployment Manager-but these features do not affect the application server that is already running (or the application in which it is running). Of course, if I don't discuss these features that exist separately in the node agent and Deployment Manager, you won't let me off lightly, and I won't blame you, so let's look at these features.