Browse Prior Art Database

Consolidated Management of Vertical and Horizontal Scaling of Cluster Topologies in the Administration Console Disclosure Number: IPCOM000167302D
Original Publication Date: 2008-Feb-06
Included in the Prior Art Database: 2008-Feb-06
Document File: 4 page(s) / 93K

Publishing Venue



This article describes how a consolidated management of vertical and horizontal scaling of cluster topologies is achieved in the administrative console. It outlines how an administrator can see in a consolidated view the number of configured clusters, their functional role, the assigned nodes and for each node the number of cluster members. It shows the consolidated status for each functional role in the topology. This article describes how the administrator can easily add/remove nodes and clusters from a single place.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 4

Consolidated Management of Vertical and Horizontal Scaling of Cluster Topologies in the Administration Console

In a clustered environment such as WebSphere Enterprise Service Bus or WebSphere Process Server, typical business integration applications have particular requirements about their deployment environments. Typical requirements are, but are not limited to, the types of prerequisite components that need to be configured, the amount of clusters, and how they relate to each other. Often in a business integration environment, more than one cluster needs to be configured to need horizontal and vertical scalability in the realm of its support applications and its messaging needs.

The proposed solution allows the user to see the current management as a whole. The user can assess how the current topology is tuned in terms of vertical and horizontal scaling across the clusters in the topology and can take appropriate actions to tune the scaling on demand. The view shows the relevant pieces such as the topology roles and the physical machines (nodes) that are associated to each role.

Without the proposed solution, the administrator of the topology would have to constantly monitor each piece separately to ensure that the whole is working as designed. In addition, the administrator would have to know in detail which cluster is addressing which topology role in order to make the right scaling decision. The proposed solution has three novel aspects to it that can be seen in the sample screenshot below:


Page 2 of 4

1. Topology Role Status

The topology role status in the status line shows the consolidated status of each topology role of concern. Each topology has topology roles that have a meaning to an administrator. In this example, the topology has an application deployment target, a messaging and a support role that map to the corresponding aspects of the business integration application that is running on this topology. The administrator is now able to see with a blink of an eye the status of the topology roles in already familiar icons as they are used to represent similar states in other parts of the WebSphere Application Server. Not shown in the screenshot below is the topology state that aggregates the topology role states and combines it with its topology state. As such, the administrator is able to quickly see whether the whole unit is running or not. In the example above, the topology state would be in partial running state.


[This page contains 1 picture or other non-text object]

Page 3 of 4

The following generic status icons are used in the topology configuration. The meaning of these states is the same as for cluster/single server or node states.

Status Icon Description

Unknown The entity's state is unknown. Unavailable The entity has been configured, but it is unavailable. Stopped The entity is stopped...