IBM zSeries Scholars Program

WAS for z/OS V5:

Network Deployment

© Copyright IBM Corporation 2005

3.3.1
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Unit Objectives
IBM zSeries

After completing this unit, you should be able to:

 Build a functional Network Deployment cell, and incorporate existing
base application server nodes into it

© Copyright IBM Corporation 2005 2

Building a Network Deployment Environment
IBM zSeries

Building a Network
Deployment Environment

© Copyright IBM Corporation 2005 3

Topic Objectives: Network Deployment
IBM zSeries

After completing this topic, you should be able to:

 Describe the change in component structure and functionality when a
base application server is migrated to Network Deployment mode
 Evaluate the advantages of making this migration
 Design a Network Deployment structure for WebSphere for z/OS
 Use the WebSphere tools supplied to migrate a base application
server to a Network Deployment environment

© Copyright IBM Corporation 2005 4

Consider a Two-System Sysplex
IBM zSeries
Imagine you have two application servers configured on each system. Your desire is
to administer this centrally as one logical whole. How is this accomplished?

MVS System or LPAR MVS System or LPAR

Server Server
A C
CR SR CR SR

Server Server
B D
CR SR CR SR

SYSA SYSB
CF
HFS HFS

First we need to introduce something called the "Deployment Manager" ...

© Copyright IBM Corporation 2005 5
Introducing the Deployment Manager
IBM zSeries
The Deployment Manager is a special kind of application server instance.
The administrative application runs in the Deployment Manager:
MVS System or LPAR MVS System or LPAR

D
M Browse
CR A
r

Server Server
A C
CR SR CR SR

Server Server
B D
CR SR CR SR

SYSA SYSB
CF
HFS HFS

Before the Deployment Manager can manage application servers, those

application servers need to be grouped into something called “nodes" ...
© Copyright IBM Corporation 2005 6
Nodes and Node Agents
IBM zSeries
"Nodes" are a grouping of 1 to n servers; "Node Agents" are special single-CR
servers that the DM communicates with to manage the app servers in the node:

MVS System or LPAR MVS System or LPAR

D
M Browse
CR A r

Node Server Node Server

Agent A Agent C
CR CR SR CR CR SR

Server Server
B D
CR SR CR SR
Node 1 Node 2
SYSA SYSB
CF
HFS HFS

Nodes must stay within a system or LPAR ... they can't span boxes. Each
application server node managed by a DM must have a Node Agent server.
© Copyright IBM Corporation 2005 7
The DM Has Its Own Node
IBM zSeries
The Deployment Manager server has its own node structure. It doesn't need a
Node Agent because there are no applications servers in the node, just the DM:

MVS System or LPAR MVS System or LPAR

D
M Browse
CR A r

Node Server Node Server

Agent A Agent C
CR CR SR CR CR SR

Server Server
B D
CR SR CR SR
Node 1 Node 2
SYSA SYSB
CF
HFS HFS

This is the first hint that multiple nodes are permitted per system or LPAR.
More on multiple nodes per box later.
© Copyright IBM Corporation 2005 8
The "Cell" Now Spans Systems
IBM zSeries

When the DM is managing servers, the "cell" expands to include all the application
servers and nodes being managed. Cells may span boxes, as illustrated here:
MVS System or LPAR MVS System or LPAR

D
M Browse
CR A r

Node Server Node Server

Agent A Agent C
CR CR SR CR CR SR

Server Server
B The Cell D
CR SR CR SR
Node 1 Node 2

SYSA SYSB
CF
HFS HFS

Now we start to see the purpose of the "cell" structure.

© Copyright IBM Corporation 2005 9
Bring the Daemon Server into Picture
IBM zSeries
The rule of thumb is this: one daemon server per cell per system or LPAR. Here
we have one cell, but two systems ... so two daemon servers are required:
MVS System or LPAR MVS System or LPAR

Daemo D Daemo
n M Browse n
CR CR A r CR

Node Server Node Server

Agent A Agent C
CR CR SR CR CR SR

Server Server
B The Cell D
CR SR CR SR
Node 1 Node 2

SYSA SYSB
CF
HFS HFS

The daemon server is a special single-CR server. Recall that each Base Application
Server required a daemon ... "one daemon per cell per system"
© Copyright IBM Corporation 2005 10
Key Point: Cell Marks Admin Domain
IBM zSeries
The Deployment Manager is managing this whole environment. The cell boundary
marks the boundary of the administrative domain.
MVS System or LPAR MVS System or LPAR

Daemo D Daemo
n M Browse n
CR CR A r CR

Node Server Node Server

Agent A Agent C
CR CR SR CR CR SR

Server Server
B The Cell D
CR SR CR SR
Node 1 Node 2

SYSA SYSB
CF
HFS HFS

This suggests that when isolated environments are needed -- for example, Test
and Production -- then separate cells are called for...
© Copyright IBM Corporation 2005 11
Multiple Cells Per Sysplex? Yes!
IBM zSeries
SYSA SYSB

DM Node Daemo Daemo

A n n
Admin

Node Server
Cell A Node Server
Agent A PROD Agent C

Server Server
B D
Node Node

DM Node Daemo Daemo DM Node

A n n A Admin
Admin
Node Server Node Server
Agent E Agent G

Server Server
Cell B Cell C
F H
TEST Node Node QA
CF
© Copyright IBM Corporation 2005 12
Single Box, Test and Production? Yes!
IBM zSeries
SYSA  DM cells may span systems in Sysplex,
but don't have to
Daemo DM Node  Cells may enjoy complete separation
n A Admin from one another:
– Separate address spaces
Node Server – Separate HFS mount points and file
Agent A
systems
– Separate JNDI naming
Server
B – Separate administrative interfaces;
Node Cell Prod separate administrative domains
 If all you need is a small "sandbox"
environment, consider "Base Application
Daemo DM Node Server" described earlier
n A Admin – Recall that a Base App Server node
is itself a cell
Node Server
Agent G

Server
H
Node Cell Test
© Copyright IBM Corporation 2005 13
Let's Make This "Real"
IBM zSeries
 The past several charts introduced the
following concepts:
Concept – The Deployment Manager
– Nodes
Concept
– Cells
 Let's now see how a multi-system cell is
Concept constructed, and show "real" things like
the HFS and JCL procedures

© Copyright IBM Corporation 2005 14

How Is Deployment Manager Created?
IBM zSeries
1 Load security domain

ISPF 2 System locations CNTL ƒ jobs

Customization System environment
Dialogs 3 ƒ scripts
customization
DATA ƒ parameters
4 Server customization

The DM starts out as its own cell and node

BBOCCINS
Cell
Node HFS
Instructions: Daemo Deploym
Update n ent
Copy ... CR Manager WebSphere
CR A configuration
Run job ...
ƒ Directory
Run job ...
structure created
and populated
with XML and
JCL Start JCL Start JCL Start properties files
Procedure Procedure Procedure
Virtually identical in concept to how the Base Application Server Node was created
© Copyright IBM Corporation 2005 15
The Deployment Manager HFS
IBM zSeries
Deployment Manager
HFS /<DM mount point> <Cell Name>
<Node Name>
<DMC1>.<DMN1>.<DMS1>
Daemo
n <Server Name>
/Daemon
CR
/DeploymentManager CR SR
/config
/cells
/<DM Cell Name>
cell.xml
/applications
/clusters ƒ The HFS structure of the
/nodes Deployment Manager is
/<DM Node Name> very close to that
created for Base App
node.xml
Server
Symbolic Link serverindex.xml
ƒ Deployment manager is
/servers really a special-
/<DM Server Name> purpose application
was.env server
© Copyright IBM Corporation 2005 16
Starting the Deployment Manager
IBM zSeries

HFS /<DM mount point>

z/OS console
<DMC1>.<DMN1>.<DMS1>
/Daemon S V5DMCR,JOBNAME=DM1,ENV=DMC1.DMN1.DMS1
/DeploymentManager
JCL
/config //V5DMCR PROC ENV= <CS>.<NS>.<SS> ,...
// SET ROOT='/<DM server root>
/cells
:
/<DM Cell Name> //BBOENV DD PATH='&ROOT/&ENV/was.env'
cell.xml
/applications
/clusters
/nodes ƒ Could re-use Base App
/<DM Node Name> Server CR JCL if DM and
node.xml Base App are defined in
same HFS
Symbolic Link serverindex.xml
ƒ Virtually identical to
/servers how the Base App
/<DM Server Name> Server is started. Only
difference: BBOENV DD
was.env points to DM Server's
was.env
© Copyright IBM Corporation 2005 17
Can't Create Nodes through DM Admin
IBM zSeries

Browser

MVS System or LPAR MVS System or LPAR

Daemo D Daemo
n M n
CR CR A CR

Node Server Node Server

Agent A Agent C
CR SR CR How are CR SR CR
these
Server created? Server
B D
SR CR SR CR
Node 1 Node 2

SYSA SYSB

© Copyright IBM Corporation 2005 18

"Federating" a Base App Node into Cell
IBM zSeries
Base App Nodes may be "federated" (joined) into a Deployment Manager cell
with the "addNode" shell script. Several key things happen:
ISPF "Node Agent" structure created in HFS
Administrative application in federated Base App Server is disabled
Cell name of your Base App Node changed to match DM's cell name
Various XML files are updated to reflect the merging of two cells

Cell C1 Node
Cell C1 Node Deployment
Daemo
Daemo Deployment Manager
n
n Manager CR
CR CR A
CR A
Previous cell for base app
node absorbed into DM cell

Daemo Cell B1 "addNode"

n Node
CR shell script Agent
CR
Node
Node Server Note how this Server
D cell's daemon D
CR A is no longer CR SR
needed
© Copyright IBM Corporation 2005 19
addNode Utility
IBM zSeries

 addNode.sh <cell host> <cell port> [options]

– Mandatory parameters: Deployment Manager host and port
 Application handling during addNode
– By default applications not propagated to cell
– Therefore they are no longer configured
for the newly managed servers addNode
 -includeApps option
Deployment
– addNode attempts to include existing Manager
App
applications from the new node Server
– If application with the same name XML multi-node
already exists in the cell Config
• a warning is printed Stand-alone
Node Node Node
• application will not be installed in cell Agent Agent

App App
Server Server
XML XML
Config Config

© Copyright IBM Corporation 2005 20

addNode Utility – Security Considerations
IBM zSeries

 Newly added node inherits security settings from the cell

– Add a secure Node to an unprotected Cell
• Node will be unprotected
– Add secure Node to secure Cell
• Use addNode with -username and -password options
• Differences in security configuration settings from Cell override settings of Node
– Add unsecured Node to secure Cell
• Use addNode with -username and -password options
• Node will be secure
 Steps to enable security on ND after nodes added:
– Ensure you have your RACF definitions correctly setup (z/OS only)
– Change the configuration and synchronize config files with nodes
– Stop the Deployment Manager and restart it (so it starts up in secure mode)
– Stop and restart each of the Nodes (so they switch to using the new security
config)
– Complete documentation in InfoCenter

© Copyright IBM Corporation 2005 21

removeNode: Detach Node from a Cell
IBM zSeries

 Execute command line utility "removeNode.sh" from any node to

detach itself from a cell
– Stops all running server processes in the node
– Backed-up original base configuration will be restored
– Lose all configuration changes done after joining a cell
– Uninstall will also makes use of the same command
– Syntax: removeNode.sh [options] removeNode
 Alternative to avoid loss of Deployment
configuration information: Node
Manager

– Don’t execute removeNode Agent

– Set server's standalone property multi-node
App
to true Server
– AppServer will retain the existing XML Node Node
configuration Config Agent Agent
– It will no longer participate in the
App App
distributed Admin network Server Server
XML XML
Config Config
© Copyright IBM Corporation 2005 22
Changes to the Base App HFS
IBM zSeries

/<Mount point> Symbolic link for

HFS server updated to
<DMC1>.<N1>.<S1>
reflect DM cell's
<DMC1>.<N1>.<NA1> short name
/Daemon
/AppServer New symbolic
/config link for Node
/cells Agent server
/<DM Cell Name>
cell.xml
Directory name /applications
changed from /clusters Plus changes to the XML
old Base App
cell name to DM
/nodes inside the XML files
cell name /<Node Name>
Message: federating a Base
node.xml
App Server Node into a
serverindex.xml
Deployment Manager cell
/servers implies changes to the HFS to
/<Server Name> reflect the DM cell name
New directory and was.env
files for new Node
Agent server /<Node Agent Name>
was.env
© Copyright IBM Corporation 2005 23
DM and Base: Separate or Common HFS?
IBM zSeries

ISPF
Customization
Dialogs

DM Cell Base App Cell

DM Node Base App Node
Daemo DM Daemo Base
n Server n Server
CR CR
CR SR CR SR

/<DM Mount Point> /<Common Mount Point>

HFS HFS
/<DM sym link> /<DM sym link>
/Daemon /<Base App sym link>
/DeploymentManager /Daemon
/DeploymentManager
/<Base App Mount Point>
HFS /AppServer
/<Base App sym link> Both possible. Pros/cons relate to:
/Daemon
Size of HFS
/AppServer
Common or separate JCL
© Copyright IBM Corporation 2005 24
How to Construct Multi-Node Cell
IBM zSeries

ISPF
Customization
Dialogs
1
MVS System or LPAR MVS System or LPAR

Daemo D
n M
2 CR CR A

4
addNode.sh 3 5 addNode.sh

Daemo Server Daemo Server

n A n A
CR CR SR CR CR SR

SYSA SYSB

The construction of a multi-node DM cell

Use the ISPF customization dialog to build DM and Base Application Servers
Federate the Base App Servers into the DM Cell.
© Copyright IBM Corporation 2005 25
Adding Instances After Federation
IBM zSeries
Browser /<server root>
HFS <symbolic for Server A
<symbolic for Server B
Deploym
ent <symbolic for Server n
Daemo
Manager
n
CR CR A /AppServer
/config
/cells
Node Server A
Agent /<DM Cell Name>
CR CR SR
/nodes
original
Base Server B /<Node Name>
App /servers
Server
CR SR
ƒ One set of JCL for all /<Server A>
CR
created servers. was.env
through ƒ Parameters make
SR /<Server B>
Admin Server n JCL specific to the
Console was.env
instance.
CR SR Server may be /<Server n>
started/stopped from was.env
DM Admin Console!
© Copyright IBM Corporation 2005 26
Manual Work for Additional Servers
IBM zSeries
 What the administrative program does
Browser
for you:
– Creates new server HFS directories
Deploym – Creates XML files and was.env file
Daemo ent – Creates symbolic link to server's
Manager was.env file
n
CR CR A
 What you must do manually:
– Create RACF STARTED profile
Node Server A (unless you want to use existing)
Agent – Create JCL (unless you use existing)
CR CR SR
– Create WLM application environment
original
Base Server B
App
Server
CR SR

new server
created with
Admin Console

© Copyright IBM Corporation 2005 27

Revisit JCL Start Procedures
IBM zSeries
Assume whole Deployment Manager cell is under the same HFS mount point:
Key assumption- all servers are under
Daemon the same "root"
Deploym ƒ PROC SET PATH= value names mount
Proc ent
Daemo point - command line override is not
JCL V5DMN Manager
n
CR CR A possible
PGM=BBODAEMN "Generic"
Node Server A Servant Proc
Agent JCL V5ASR
CR CR SR
"Generic"
Controller PGM=BBOSR
Proc Server B

JCL V5ACR CR SR PROC ENV= value

ƒ specific pointer to was.env file
PGM=BBOCTL
for each server
 PROC JOBNAME= value
Server n
ƒ gives started job a unique name.
CR SR WLM invokes servant proc with
ENV= parameter
ƒ Appl Env named in was.env

© Copyright IBM Corporation 2005 28

Federate Multiple Nodes on a Box?
IBM zSeries
MVS System or LPAR
Only one shared
Daemon because D Node Cell
Daemo
DM node and n M
both AppServer CR CR A
nodes are all in
the same cell on Yes, this is allowed.
the same image Node Server
Agent A You can federate different
CR CR SR
base application server
Server nodes on same system or
B LPAR into a Deployment
CR SR
Node Manager cell.
Not a good approach for
Server
Node "Test" and "Production"
Agent C
CR CR SR configurations.

Server
D
CR SR
Node

© Copyright IBM Corporation 2005 29

Clustering of Servers in Cell
IBM zSeries
MVS System or LPAR MVS System or LPAR
1. Cluster
servers B D
and D M
CR A
Browse
r
Daemo Server Daemo Server
n A n C
CR CR SR CR CR SR
2. Install
application
Server Server
into cluster
B Cluster D
CR SR CR SR

HFS HFS
APP APP
SYSA CF
SYSB
A cluster is a grouping of two or more servers within a cell into a logical entity
Clusters cannot span cells.
They may span systems in a Sysplex, but only if the cell also spans those systems.
Applications are then installed into the cluster; WebSphere will automatically deploy
the app into all the servers in the cluster
© Copyright IBM Corporation 2005 30
Different Ways to Cluster Servers
IBM zSeries
MVS System/LPAR MVS System/LPAR
Servers are clustered
Daemo Daemo through the
n Cell A n
administrative interface.
DM Node Any given server may be
A a member of only one
cluster at a time.
Node Node You can't have Server_C be a
Node Node
Agent Agent member of two different clusters,
for example.

"Vertical" Hybrid of vertical and

Server
Cluster Server horizontal is permitted.
A D

Server Server
B E

"Horizontal"
Server Server Cluster
C F

CF
© Copyright IBM Corporation 2005 31
Failover and Load Balancing
IBM zSeries
MVS System or LPAR MVS System or LPAR
D
M
CR A SYSA CF
SYSB

Daemo Server A Daemo

n JNDI n
CR CR SR CR
LOOKUP

Server B Server
Cluster D
CR SR CR SR

Network
ƒ WebSphere Edge Server
ƒ WebSphere Affinity Plugin
External balancing via a device like WebSphere Edge Server
Internal balancing and failover on JNDI lookups (clustered objects deployed with cluster
JNDI name, WebSphere will automatically resolve)
© Copyright IBM Corporation 2005 32
Base App Node Cell versus DM Cell
IBM zSeries

Deployment Manager
Base App Node Cell
Cell
Initial cell configuration through
Each base app node cell requires
ISPF panels. Nodes added through
Configuration: ISPF panels. Additional servers
federation. Additional servers and
within node via admin console
clustering through admin console

Min: 6 (Daemon, DM CR, DM SR,

Min: 3 (Daemon, CR, SR)
Address Spaces: Node Agent, CR, SR)
Max: limited only by resources
Max: limited only by resources

Each standalone server a Each DM cell an isolated domain.

Administrative
separate administrative domain Nodes, servers within DM cell are
Isolation
from others within the same admin domain
Servers may be started and
Servers may be started and
stopped independently. Some
Operational stopped independently. No JNDI
JNDI conflicts possible.
Isolation naming conflicts; no application
Application name conflicts
name conflicts with other servers
possible.
Multiple Server Only if administrative application
Yes
Regions not present

Clustering None Yes

© Copyright IBM Corporation 2005 33
Unit Summary
IBM zSeries

Having completed this unit, you should be able to:

 Describe the change in component structure and functionality when a
base application server is migrated to Network Deployment mode
 Evaluate the advantages of making this migration
 Design a Network Deployment structure for WebSphere for z/OS
 Use the WebSphere tools supplied to migrate a base application
server to a Network Deployment environment

© Copyright IBM Corporation 2005 34