ADSM-L

Re: update server roles

2006-10-09 05:10:56
Subject: Re: update server roles
From: Matthew Warren <Matthew.Warren AT DIGICA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 9 Oct 2006 10:09:19 +0100
Hi,

Ah, I didn't realise TSM1 had a LIB1. For some reason though, I had got
stuck on the idea that storage agents don't go direct to libraries, they
go through the library client, which is wrong.

Although, now if STA1 is sending backups to LIB1 on TSM1 I'm even less
sure of how /why STA1 is connecting to TSM1 and causing an update to
occurr on TSM2 that affects STA2 even if they do have the same names. 

Matt.


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 
> On Behalf Of BEYERS Kurt
> Sent: 06 October 2006 19:06
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] update server roles
> 
> Matt,
>  
> > 'Else I
> > don't understand how the STA of TSM1 can end up on TSM2'
> 
> I guess the problem description was not yet complete. The 
> desired setup is as follows
>  
> Each TSM server has it's own library (LIB1 for TSM1 and LIB2 
> for TSM2):
>  
> The backups taken by the STA1 on the CLIENT are sent to the 
> library LIB1 of TSM1.
> The backups taken by the STA2 on the CLIENT are sent to the 
> library LIB2 of TSM2
> The database backup of TSM1 is sent to the library LIB2 of 
> TSM2 by means of the library client (TSM1) and manager (TSM2).
>  
> best regards,
> Kurt 
>  
> 
> ________________________________
> 
> Van: ADSM: Dist Stor Manager namens Matthew Warren
> Verzonden: vr 6/10/2006 17:38
> Aan: ADSM-L AT VM.MARIST DOT EDU
> Onderwerp: Re: [ADSM-L] update server roles
> 
> 
> 
> Apologies.  It actually works opposite to how I thought;
> 
> When the Tivoli Storage Manager server (data manager server) 
> is also the
> library manager for the devices where data is stored by the storage
> agent, then the storage agent communicates requests to this Tivoli
> Storage Manager server. When the Tivoli Storage Manager server (data
> manager server) is another library client, then the storage agent
> communicates requests for itself or the metadata server 
> directly to the
> library manager.
> 
> 
> So all I have done is confuse the issue.
> 
> Ignore me :)
> 
> Matt.
> http://tsmwiki.com/tsmwiki/
> 
> 
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> > On Behalf Of BEYERS Kurt
> > Sent: 06 October 2006 15:28
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] update server roles
> >
> > Matt,
> > 
> > The server name of the Linux STA is the same on both TSM
> > servers, although they are listening on different TCP/IP
> > ports of course.
> > 
> > Indeed when the STA to TSM1 is started, it ends up talking to
> > TSM2 too through the library client on TSM1 to TSM2. Else I
> > don't understand how the STA of TSM1 can end up on TSM2, the
> > setstorageserver is correct: different TSM server names,
> > different TCP/IP admin ports for the TSM servers, different
> > TCP/IP ports for the STA servers and different shared memory
> > ports for the backup.
> > 
> > And if I start the STA of TSM2 on the CLIENT, nothing is
> > logged in the activity log of TSM1. It is only the other way around.
> > 
> > An easy workaround would be to use different server names (eg
> > CLIENT_1 and CLIENT_2 on TSM1 and TSM2 instead of CLIENT).
> > But would ask some work (30 STA clients and everything is
> > installed/updated through scripting from a Linux CSM server)
> > 
> > But if possible, I would like to restrict the STA of TSM1 to
> > talk only with TSM1 and not end up with TSM2 (through the
> > library sharing role?). And understand better how the
> > communication is going from TSM1 to TSM2. I know we have a
> > rather unique setup.
> > 
> > best regards,
> > Kurt
> > 
> > 
> >
> > ________________________________
> >
> > Van: ADSM: Dist Stor Manager namens Matthew Warren
> > Verzonden: vr 6/10/2006 15:18
> > Aan: ADSM-L AT VM.MARIST DOT EDU
> > Onderwerp: Re: [ADSM-L] update server roles
> >
> >
> >
> >
> > I could be missing something, but I cant off the top of my
> > head understand(remember?) why TSM1 is communicating to TSM2
> > to update a storage agent/server definition at all? Even
> > though TSM1 is a library client to TSM2, I don't think TSM2
> > needs to know anything about the storage agent defined to
> > TSM1, as TSM1 will take mount requests from the storage
> > agent, manage them with TSM2 and then pass back the device
> > info to the storage agent when TSM2 has allocated a drive.
> >
> >
> >
> > Matt.
> > http://www.tsmwiki.com/
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> > > On Behalf Of BEYERS Kurt
> > > Sent: 06 October 2006 10:11
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: [ADSM-L] update server roles
> > >
> > > Hello,
> > >
> > >
> > >
> > > In the output of a server definition in TSM (TSM server
> > > 5.3.2.4, TSM BA client 5.3.2 and STA 5.3.2.1), multiple roles
> > > are defined:
> > >
> > >
> > >
> > > ?'q server SERVER  f=d'
> > >
> > >
> > >
> > >                                   Server Name: SERVER
> > >
> > >                                  Comm. Method: TCPIP
> > >
> > >                            High-level Address: xxx.yyy.rrr.tttt
> > >
> > >                             Low-level Address: 1502
> > >
> > >                                   Description:
> > >
> > >                             Allow Replacement: No
> > >
> > >                              .......
> > >
> > >                               Role(s): Storage Agent Event
> > > Logging Library Sharing
> > >
> > >
> > >
> > > Is it possible to limit those server roles? Eg only a storage
> > > agent or library sharing?
> > >
> > >
> > >
> > > The problem I'm having is the following:
> > >
> > >
> > >
> > > A TSM client (CLIENT) is defined to two TSM servers (TSM1 and
> > > TSM2) and has two Storage Agents for each TSM server (using
> > > other TCP/IP ports and shared memory ports).
> > >
> > >
> > >
> > > Further on, TSM1 is a library client of the library manager
> > > running on TSM2. The TSM1 database backup goes to this
> > > library so that the tapes must be vaulted only from 1 library
> > > instead of two libraries.
> > >
> > >
> > >
> > > But if I start the STA for TSM1 on the client, the server
> > > definition on TSM2 is being updated (changing the TCP/IP port):
> > >
> > >
> > >
> > > ?
> > >
> > > ?ANR0408I Session 35078 started for server CLIENT
> > > (Linux/x86_64) (Tcp/Ip) for server registration.
> > >
> > > ANR1662I Server CLIENT updated.
> > >
> > > ?ANR0409I Session 35078 ended for server CLIENT (Linux/x86_64).
> > >
> > >
> > >
> > > Which results that the STA for TSM2 can no longer communicate
> > > with the TSM server TSM2.
> > >
> > >
> > >
> > > I can prohibit this with 'set crossdefine off', but I end
> > > then with yet another warning in the activity log that can be
> > > discarded.
> > >
> > >
> > >
> > > ?ANR0408I Session 35087 started for server CLIENT
> > > (Linux/x86_64) (Tcp/Ip) for server registration.
> > >
> > > ANR0457W Session for server CLIENT  refused - crossdefine is
> > > not allowed on this server.
> > >
> > > ANR0409I Session 35087 ended for server CLIENT (Linux/x86_64).
> > >
> > >
> > >
> > > Or must I define two different servers on the CLIENT, one for
> > > TSM1 and one for TSM2?
> > >
> > >
> > >
> > > Thanks in advance for any feedback.
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Kurt
> > >
> > > ?
> > >
> > > <mailto:kurt.beyers AT vrt DOT be>
> > >
> > >
> > >
> > > *** Disclaimer ***
> > >
> > > Vlaamse Radio- en Televisieomroep
> > > Auguste Reyerslaan 52, 1043 Brussel
> > >
> > > nv van publiek recht
> > > BTW BE 0244.142.664
> > > RPR Brussel
> > > http://www.vrt.be/disclaimer
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > This email is confidential and may be privileged. If you are
> > not the intended recipient please notify the sender
> > immediately and delete the email from your computer.
> >
> > You should not copy the email, use it for any purpose or
> > disclose its contents to any other person.
> > Please note that any views or opinions presented in this
> > email may be personal to the author and do not necessarily
> > represent the views or opinions of Digica.
> > It is the responsibility of the recipient to check this email
> > for the presence of viruses. Digica accepts no liability for
> > any damage caused by any virus transmitted by this email.
> >
> > UK: Phoenix House, Colliers Way, Nottingham, NG8 6AT UK
> > Reception Tel: + 44 (0) 115 977 1177
> > Support Centre: 0845 607 7070
> > Fax: + 44 (0) 115 977 7000
> > http://www.digica.com
> >
> > SOUTH AFRICA: Building 3, Parc du Cap, Mispel Road,
> > Bellville, 7535, South Africa
> > Tel: + 27 (0) 21 957 4900
> > Fax: + 27 (0) 21 948 3135
> > http://www.digica.com
> >
> >
> > *** Disclaimer ***
> >
> > Vlaamse Radio- en Televisieomroep
> > Auguste Reyerslaan 52, 1043 Brussel
> >
> > nv van publiek recht
> > BTW BE 0244.142.664
> > RPR Brussel
> > http://www.vrt.be/disclaimer
> > 
> >
> >
> > 
> >
> 
> 
> *** Disclaimer ***
> 
> Vlaamse Radio- en Televisieomroep
> Auguste Reyerslaan 52, 1043 Brussel
> 
> nv van publiek recht
> BTW BE 0244.142.664
> RPR Brussel
> http://www.vrt.be/disclaimer
>  
> 
> 
>  
> 

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