WebSphere Product Packages

Note in the preceding diagram that the App Server exists in a WebSphere node. Even though we defined a node as a logical collection of app servers on the same physical computer system, even a single app server is in a node – a node of one.

With the WebSphere Application Server product package, you can define as many single servers as you need on the same physical machine. If you have more than one app server installed, each one is independent and administered separately. In other words, they are not centrally administered. For example, two single servers defined on the same physical system would each host their own copy of the Admin console application, each controlled through a separate browser connection:

You might start to wonder how to effectively administer a large number of app servers. You'd probably say we were crazy if we suggested that administering each app server through a separate browser connection was the only solution! Fortunately, we're not that crazy. This is where WebSphere Network Deployment comes in.

The purpose of the WebSphere Network Deployment product package is twofold:

• To enable administration of multiple WebSphere nodes, and the app servers they contain, through a single browser connection

• To enable the configuration of servers into clusters for application scale and availability

When you install WebSphere Network Deployment, at first all you get is a single, specialized app server, called the Network Deployment Manager. At first it appears really no different from any other app server, except for its name :

We'll soon see, however, that it plays a unique role within a group of WebSphere nodes, which we call a cell .

Another thing to note about the Deployment Manager is that it always exists in its own dedicated node. It is not possible to define other app servers in the Deployment Manager's node. It has its own node largely for isolation purposes because in the WebSphere implementation, server configurations are physically isolated on a per-node basis. We'll talk more about that in just a little bit.

In the following diagram, we see that the Deployment Manager node can be co-located on the same physical computer system as other app server nodes:

The fact that the Deployment Manager may exist on the same physical computer system as other app servers is evidence that nodes are only logical – in fact you can configure multiple app server nodes on the same physical computer system, too. You might wonder why on earth one would do that. One of the best reasons will not occur until we release the next version of WebSphere – call it WebSphere version X.0. If you had a business reason to run both v5.0 and vX.0 on the same physical system, you would have to separate them by node. You see, each node is essentially a separate installation of WebSphere Application Server.

Naturally, the Deployment Manager can exist on its own physical computer system:

This is our recommendation for increased availability – a point that should become clearer as we describe the organization of a cell.

A cell is a collection of nodes, organized into the same administrative domain. Cells are created by federating base server nodes with the Deployment Manager's node. This is done through either a utility program called AddNode or through the Admin console application running in the Deployment Manager. Both of these techniques for adding an existing node to a cell are discussed in greater detail in Chapter 14.

It is important to recognize that a base server is transformed when its node is federated with the Deployment Manager's node. Upon taking this action, the Deployment Manager becomes responsible for providing administrative access to the servers on the newly federated node. The base servers on that node are no longer standalone: no longer separately administered. In fact, the Admin console on each base server is uninstalled . In its place, a Node Agent is activated. Through the Admin console in the Deployment Manager you can access any server in the cell. The Admin function in the Deployment Manager is aware of the other servers in the cell and coordinates administrative actions through each node's Node Agent.

It is because the Deployment Manager is responsible for providing administrative access to all nodes and servers within the cell, that we recommend running the Deployment Manager on its own physical computer system. In a production environment, app server nodes are typically far busier than the Deployment Manager node. This greater activity on an app server node increases the opportunity for failure. Therefore isolating the Deployment Manager to its own physical computer system naturally increases its availability.

OK, so let's consider what our cell would look like after federating our first base server node. The following diagram depicts this trivial cell:

The benefit of grouping servers into cells is that the entire cell can be administered from a single point. This can substantially decrease administrative complexity and facilitates the coordination of administrative actions across a set of app servers.

You can increase the size of your cell by adding additional nodes and app servers. Note that you cannot administratively create a new node. You can only create a new node by installing WebSphere Application Server. If we added another node to our cell, it would look like this:

The presence of additional app server nodes makes it possible for us to build a cluster . The motivation for configuring a cluster is scale and availability. A cluster is a collection of homogenous servers, with each server having the same configuration and hosting the same applications. When servers are configured into a cluster, WebSphere automatically knows how to distribute work among the servers within that cluster, so from the point of view of the outside world, the cluster appears as a single, logical server. The app servers that compose a cluster may reside on the same node or on different nodes. All nodes must be in the same cell.

The following diagram depicts a server cluster: