Key Topography Terms

To facilitate our discussion, let's introduce a few new terms to create a working vocabulary.

The WebSphere Application Server product introduces these terms:

• App Server
  A single WebSphere application server, which is sometimes referred to as a "base server".

• Admin Console
  This is a special J2EE application that is pre-installed in your WebSphere environment. It provides a browser-based interface through which your app servers and applications are managed. Please note we will discuss the presence of the Admin Console in this chapter, but will defer an explanation of its functions until Chapter 14.

The WebSphere Network Deployment product introduces these additional terms:

• Node
  A logical group of app servers, configured together on the same physical computer system. Note that multiple WebSphere nodes can be configured on the same physical computer system.

• Node Agent
  An administrative process, executing on the same physical computer system as the node it supports. A single Node Agent supports all app servers running on the same node.

• Cell
  A logical group of nodes, configured together in the same network for administrative purposes.

• Cluster
  A logical app server comprising multiple instances of the same app server, usually spanning multiple nodes, and acting as a single unit providing reliability and load balancing.

• Network Deployment Manager
  An app server running an instance of the Admin console that provides administrative control over all other app servers configured together into the same cell.

To illustrate the concepts these terms represent, let us consider some diagrams. Please note we will describe the organization and purpose of these topographical elements in this chapter, but we will defer explanation of how to configure these elements until Chapter 14.

Let's look at a base server first. This is what you get when you install the WebSphere Application Server product. This configuration consists of a single app server installed on some physical computer system. This app server hosts its own instance of the Admin console application, enabling it to be administered through a standard Internet browser. The Admin console is installed automatically in the app server and is used to manage only the app server in which it is installed. The following diagram depicts this configuration:

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.

Note

For ease in understanding, we have used the term "physical computer system" to represent a collection of hardware operated by a single instance of some operating system. For example, an Intel box operated by Linux or Windows 2000, a Sun server operated by Solaris, etc. Certain hardware platforms, such as IBM P-Series and Z-Series, offer a function commonly referred to as "logical partitioning", which allows a single physical computer system to be sub-divided into multiple logical computer systems, with each logical computer system being operated by a separate operating system instance. A WebSphere node always exists within the boundaries of a computer system, whether that computer system is physical or logical.

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.

Important

Please note that the Deployment Manager hosts only administrative applications, such as the Admin Console – you cannot target this server for your own applications.

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:

Now that we've built up a basic vocabulary, we're ready for the topography overview coming up later in this chapter, but let's first take that detour we mentioned, inside the application server.