WebSphere eXtreme Scale Best Practices for Operation and Management

Chapter 3. Topology and infrastructure 43

Figure 3-6 Catalog server domain ports

3.5.1 Catalog service domain ports

Catalog servers in a catalog service domain use ports for communication among themselves,

with clients, and with the container servers. These ports are referred to as the

peerPort,

clientPort, and listenerPort. SSL security, if enabled, requires an additional port on every

catalog server, container server, and client. In addition, the Java Management Extensions

(JMX) service port is the interface for administration clients. As for any port, each JVM on a

given host (using a given network interface card) must have a unique value for each of these

ports.

peerPort, haManagerPort

The peerPort is used by the high availability (HA) manager to communicate between peer

catalog servers in a cluster. When the catalog server is a managed server (running in

WebSphere Application Server), this port is referred to as the

haManagerPort. Think of this

port as the “heartbeat” port.

Container server

pe erPort

(haManagerP ort)

listenerPort

Container server

peerPort

(haManager Port)

listenerPort

Container server

peerPo rt

(haManagerPort)

listenerPort

28 09

Client

app

Catalog server

cat 2

peerPort

6601

listenerPort

2809

clien tPort

6600

Catalog server

cat 3

peerPort

6601

listenerPort

2809

clien tPort

6600

Data excha nge

Catalog server

cat1

peerPort

6601

listenerPort

2809

clientPort

6600

JMX service port

1099

HA heartbeat

Admin tool

Admin

44 WebSphere eXtreme Scale Best Practices for Operation and Management

For stand-alone servers, the default for peerPort is 6601.To configure this port in stand-alone

installations, use the -catalogServiceEndpoints command-line option when starting the

catalog server:

startOgServer -catalogServiceEndPoints server:host:clientPort:peerPort,

server:host:clientPort:peerPort, server:host:clientPort:peerPort

In WebSphere Application Server, the peerPort is the same as the

DCS_UNICAST_ADDRESS. In the administrative console, you can see or change this port at

Servers  Server Types  WebSphere application servers  catalog_server  Ports.

clientPort

The clientPort is used by catalog servers to access catalog service data on other catalog

servers. The default is 6600.

To configure the clientPort in stand-alone installations, use the -catalogServiceEndpoints

command-line option when starting the catalog server:

startOgServer -catalogServiceEndPoints server:host:clientPort:peerPort,

server:host:clientPort:peerPort, server:host:clientPort:peerPort

In WebSphere Application Server, configure this port from the administrative console by

selecting System administration  WebSphere eXtreme Scale  Catalog service

domains.

listenerPort

The listenerPort defines the ORB listener port for containers and clients to communicate with

the catalog service through the ORB. The default is 2809.

To configure the listenerPort in stand-alone installations, use the -listenerPort

command-line option when starting the catalog server:

startOgServer -listenerPort port

In WebSphere Application Server, configure this port:

1. Take the default (inherited by the BOOTSTRAP_ADDRESS port configuration).

2. Use the administrative console to override the default:

System administration  WebSphere eXtreme Scale  Catalog service domains

HA manager and core groups: The HA manager and core groups are WebSphere

Application Server features that are used by WebSphere eXtreme Scale for health checks

and for intercommunication among catalog servers. These features are critical to the

operation of the catalog server domains, and so, the jar file for the HA manager is included

with stand-alone WebSphere eXtreme Scale installations.

For managed grids, you can use the normal WebSphere Application Server techniques to

assign servers to core groups. For stand-alone grids, the WebSphere eXtreme Scale code

automatically creates core groups in a completely transparent manner.

For stand-alone, WebSphere eXtreme Scale creates a separate core group for roughly

every 20 servers. You can influence core groups in stand-alone grids by defining zones;

servers in separate zones also are placed in separate core groups.