ADSM-L

Re: Multiple FileSpaces on Cluster

2006-01-19 13:02:08
Subject: Re: Multiple FileSpaces on Cluster
From: Andrew Ferris <AFerris AT MRL.UBC DOT CA>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Jan 2006 10:00:04 -0800
Here's a bit more on top of Jim's good explanation on NetWare clusters.
The cluster nodes are actually virtual servers with their own IPs. We
were seeing the exact same thing as you Louw as the NetWare TSM client
manual is a little confusing about clusters. We're running uniquely
named DSMCADs off of each cluster node now, i.e. dsmcad-node1,2,3... .
Here's what a typical cluster node would have in its DSM.opt file to
mark it as a cluster resource:

NODENAME              admin_server [TSM node name]
DOMAIN          ADMIN:  [cluster node volume name as NetWare sees it]
CLUSTERNODE     YES  [this is what keeps one consistent file space]
HTTPPORT        1582  [ports should be unique for cluster resources]

Hope that helps,
>>> jim_armstrong AT STANDARDLIFE DOT COM 1/19/2006 6:24 am >>>
I've never tried this, but the EXPORT NODE command has a
mergefilespaces=yes parameter. Might be worth testing?


On 19/01/2006 11:51:07 "ADSM: Dist Stor Manager" wrote:

>Hi Jim,
>
>O thx Jim for your input, it really helped me.
>Now do you know if I can merge the 3 FileSpaces?
>
>Regards
>Louw Pretorius
>_______________________________
>Informasie Tegnologie
>Stellenbosch Universiteit
>
>There are only 10 kinds of people in the world: Those who understand
>binary and those who don't
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
>Jim Armstrong
>Sent: Thursday, January 19, 2006 13:00
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: [ADSM-L] Multiple FileSpaces on Cluster
>
>Hi Louw
>
>It's not actually a Netware disk that moves between Netware clustered
>servers, it's a Netware Partition which can contain multiple disks.
Just
>to confuse you, the TSM manual that describes how to set up Netware
>Cluster aware backups talks about a "cluster group" when they really
>mean a Netware Partition.
>
>The key to getting this to work successfully seems to be to allocate
a
>dsm.opt file on a disk in that partition, and  define the partition
to
>TSM as a uniquely named node, that is, do not use the same node name
as
>any of the physical clustered servers. We do this for a couple of
>clustered disks and all seems to work fine.
>
>If you can provide details of how your dsm.opt file is set up I might
be
>able to help more, but one problem is that our standards are that
every
>clustered disk lives in its own Netware partition, and I can't
remember
>how much of our documentation is disk specific and how much is
partition
>specific. (Understanding the TSM manual was heavy going)
>
>
>Jim
>
>
>On 19/01/2006 10:02:27 "ADSM: Dist Stor Manager" wrote:
>
>>Hi,
>>
>>We have a Netware 6.5 Cluster and I find that TSM generates multiple
>>FileSpaces when migrating the Volumes to other Cluster nodes.
>>I will have ie.
>>Server1\Home,
>>Server2\Home and
>>Server3\Home FileSpaces on Server.
>>
>>1. I find that I cannot restore files that have been backed up to
the
>>other "Filespace", unless I migrate the volume back...
>>
>>TSM 5.2.3.5
>>Client 5.02.04
>>
>>Options File:
>>Nodename Server1-Home
>>Domain: Home
>>
>>We load multiple dsmcad instances on each server to define Cluster
>>Volume-nodes and normal server-nodes
>>
>>Regards
>>
>>Louw Pretorius
>>
>>_______________________________
>>
>>Informasie Tegnologie
>>
>>Stellenbosch Universiteit
>>
>>
>>
>>There are only 10 kinds of people in the world: Those who understand
>>binary and those who don't
>>
>>
>
>
>
>
>For more information on Standard Life, visit our website
>http://www.standardlife.com/
>
>The Standard Life Assurance Company, Standard Life House, 30 Lothian
>Road, Edinburgh EH1 2DH, is registered in Scotland (No. SZ4) and
>regulated by the Financial Services Authority. Tel: 0131 225 2552 -
>calls may be recorded or monitored. This confidential e-mail is for
the
>addressee only. If received in error, do not retain/copy/disclose it
>without our consent and please return it to us. We virus scan and
>monitor all e-mails but are not responsible for any damage caused by
a
>virus or alteration by a third party after it is sent.
>
>This e-mail is confidential, if you are not the intended recipient,
do
>not retain/disclose it and please return it to us. We virus scan and
>monitor all e-mails but are not responsible for any damage caused by
a
>virus/alteration of our e-mail by a third party after sending.
>
>For more information on Standard Life, visit our website
>http://www.standardlife.co.uk/
>
>The Standard Life Assurance Company, Standard Life House, 30 Lothian
>Road, Edinburgh EH1 2DH, is registered in Scotland (No. SZ4) and is
>authorised and regulated by the Financial Services Authority. Tel:
0131
>225 2552 - calls may be recorded or monitored.




For more information on Standard Life, visit our website
http://www.standardlife.com/

The Standard Life Assurance Company, Standard Life House, 30 Lothian
Road,
Edinburgh EH1 2DH, is registered in Scotland (No. SZ4) and regulated by
the
Financial Services Authority. Tel: 0131 225 2552 - calls may be
recorded or
monitored. This confidential e-mail is for the addressee only. If
received
in error, do not retain/copy/disclose it without our consent and
please
return it to us. We virus scan and monitor all e-mails but are not
responsible for any damage caused by a virus or alteration by a third
party
after it is sent.

This e-mail is confidential, if you are not the intended recipient, do
not
retain/disclose it and please return it to us. We virus scan and
monitor
all e-mails but are not responsible for any damage caused by a
virus/alteration of our e-mail by a third party after sending.

For more information on Standard Life, visit our website
http://www.standardlife.co.uk/

The Standard Life Assurance Company, Standard Life House, 30 Lothian
Road,
Edinburgh EH1 2DH, is registered in Scotland (No. SZ4) and is
authorised
and regulated by the Financial Services Authority. Tel: 0131 225 2552
-
calls may be recorded or monitored.


Andrew Ferris
Network Support Analyst
iCAPTURE Research Centre
University of British Columbia

<Prev in Thread] Current Thread [Next in Thread>