You keep mentioning configuring the DSM.OPT file with the "addresses". Why
not use a name and let DNS resolution take over. Then to move things around,
just change DNS. You could try out lots of different scenarios without
having to keep changing the DSM.OPT files on all your clients.
Bill Boyer
DSS,Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Thomas Denier
Sent: Friday, August 30, 2002 11:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Mainframe networking
We have a TSM 4.2.1.9 server running under OS/390 Version 2 Release 9.0.
We are in the process of migrating to a new network infrastructure.
The old network has Ethernet connections to Unix and Windows hosts,
an ATM backbone, and an ATM OSA card in the mainframe to provide network
connectivity for TSM. The old network uses 3COM Ethernet switches, routers,
and ATM switches. The new network will use Ethernet throughout, and will
have two Ethernet OSA cards in the mainframe to provide network
connectivity for TSM. Our mainframe does not support gigabit per second
OSA cards. The new network will use Cisco switches and routers.
We are planning to add three new address to the TCP stack supporting the
TSM server: one for each of the new OSA cards and one virtual (VIPA)
address. We will leave the address for the old OSA card in place until
migration is complete. The campus routing infrastructure will treat each
of the three addresses associated with hardware interfaces as routers
capable of forwording packets to the virtual address. We will update
the dsm.opt (Windows) or dsm.sys (Unix and Linux) file on each client
to specify the virtual address as the address of the TSM server. There
is going to be a transitional period when some incoming traffic will
be routed through the ATM card on its way to the virtual address and
other incoming traffic will specify the ATM card as the ultimate
destination. The documentation seems to imply that the card can play
this dual role successfully. Can anyone who has done a similar migration
confirm this? We will eventually end up with all traffic on the two
Ethernet OSA cards. Ideally, the routing infrastructure would split
the flow of inbound packets equally between the two cards. The people
who install and configure the mainframe TCP/IP stack think this will
happen. The people who run the campus network do not. If the latter
group is right we will have to split the dedicated subnet for backup
traffic into two subnets and try to divide the client systems in a
way that splits the packet volume more or less equally. Has anyone
achieved dynamic load splitting between two mainframe network
interfaces, or attempted it and concluded that it was impossible?
|
