TSMAdmin: Favorites

Showing posts with label Favorites. Show all posts

Thursday, February 14, 2008

Migrating To A Library Controller Instance

For those of you who use a shared library environment, but do not have a dedicated TSM library controller instance, now is the time to make the change. I know many of you figured it was to hard or risky to try but that is no longer the case. IBM has just release a Redpaper that will help you move your library controller to a dedicated instance. The new Redpaper is called:

IBM Tivoli Storage Manager: How to Migrate the Library Manager Function

I made the switch years ago and it was the best thing I ever did. Have to control the library with a production instance was a headache. If the servers came down the time it would take to come back up due to log cleanup made it frustrating and problematic for other instances that could come up more quickly. Now with a dedicated library controller instance I don't have to worry about production servers waiting for the library to come back up since the library controller is small and fast when restarting. Check out the paper it even provides scripts to help ease some of the headache involved.

Thursday, February 7, 2008

REPOST: ACSLS Shared Library Checkout Script

For those with a shared ACSLS TSM library looking for a checkout script, I thought I would repost this so it would be easier to find.

Here is a basic rundown of what the script does.

On each library client DRM checks the tapes out with a REMOVE=NO option and creates a file with a list of the tapes.
On the library manager the tapes are checked back into the library.
The Library manager then checks every library clients DRM tapes out.

I know it sounds complex but it's not. It also is not perfect so you will need to keep on top of it, but don't worry it is not so bad that it's a headache. Some explaination is required also; In my environment I have 7 TSM instances and the firsts is just a library controller. This is why the following script starts at TSMSERV2 and stops the loop after TSMSERV7. Also note that the pipe sysmbol will not show up for some reason so you need to add it before the grep statements. Before you use the script you will also notice that it uses a TSM macro. Create the file by putting the following command into a macro called move_drmedia.mac.

move drm * so=dbb wherestate=mo tostate=vault remove=no CMD=&VOL CMDFILE=/usr/tivoli/tsm/client/ba/bin/Vol_List APPEND=YES WAIT=YES
move drm * so=dbb wherestate=vaultr tostate=onsiter

=-=-=-=-= Below Starts Checkout Script =-=-=-=-=

#!/bin/ksh

cd /usr/tivoli/tsm/client/ba/bin

OFFSITE=/usr/tivoli/tsm/client/ba/bin/OFFSITE/offsite.txt
RETRIEVE=/usr/tivoli/tsm/client/ba/bin/OFFSITE/retrieve.txt
ADSMID=`cat /usr/local/scripts/ADSMID`
ADSMPASS=`cat /usr/local/scripts/ADSMPASS`
I=2

cp $OFFSITE "$OFFSITE.BAK"
cp $RETRIEVE "$RETRIEVE.BAK"
cp /usr/tivoli/tsm/client/ba/bin/Vol_List /usr/tivoli/tsm/client/ba/bin/Vol_List.bak

cat /dev/null > /usr/tivoli/tsm/client/ba/bin/Vol_List

printf "Use this list to determine tapes that are to go offsite report any discrepancies to the Recovery Services Team.\n\n" > $OFFSITE
printf " \n\n" >> $OFFSITE
printf "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n\n" >> $OFFSITE
printf " Tapes to be sent offsite\n\n" >> $OFFSITE
printf " Current as of: `date`\n\n" >> $OFFSITE
printf "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n\n" >> $OFFSITE

printf "Use this list to determine tapes that are to come back onsite from Iron Mountain for reuse. Report any discrepancies to the Recovery Service Team.\n\n" > $RETRIEVE
printf " \n\n" >> $RETRIEVE
printf "********************************************************\n\n" >> $RETRIEVE
printf " Tapes to be brought back onsite from Iron Mountain\n" >> $RETRIEVE
printf " and placed back into TSM library for scratch.\n\n" >> $RETRIEVE
printf " Current as of: `date`\n\n" >> $RETRIEVE
printf "********************************************************\n\n" >> $RETRIEVE

while [ $I -lt 8 ]
do
S=TSMSERV-$I

dsmadmc -id=$ADSMID -password=$ADSMPASS -servername=$S -dataonly=yes "select volume_name from drmedia where state='MOUNTABLE' " grep L[0-3] >> $OFFSITE

dsmadmc -id=$ADSMID -password=$ADSMPASS -servername=$S -dataonly=yes "select volume_name from drmedia where state='VAULTRETRIEVE' " grep L[0-3] >> $RETRIEVE

dsmadmc -id=$ADSMID -password=$ADSMPASS -servername=$S 'macro move_drmedia.mac'

sleep 120

I=$(( $I + 1 ))
done

dsmadmc -id=$ADSMID -password=$ADSMPASS -servername=TSMSERV-1 'CHECKIN LIBVOL TSMLIB search=yes stat=private checklabel=no vollist=FILE:/usr/tivoli/tsm/client/ba/bin/Vol_List'

sleep 180

dsmadmc -id=$ADSMID -password=$ADSMPASS -servername=TSMSERV-1 'CHECKOUT LIBVOL TSMLIB vollist=FILE:/usr/tivoli/tsm/client/ba/bin/Vol_List'

mail -s "TDC Daily Tape Checkout" $HN tape_rpt < $OFFSITE
mail -s "TDC Daily Tape Return" $HN tape_rpt < $RETRIEVE

Saturday, October 27, 2007

ACSLS Shared Library DRM Checkout

I was recently asked by a reader if I would show them how I do the checkout of my DRM tapes in an shared ACSLS library. If you are not aware, ACSLS does not really support true DRM checkout within a shared library environment. Unfortunately, what occurs when you run the checkout is that ACSLS tries to check the tapes out one at a time; prompting for a request response before checking out the next tape. I found this out when we implemented our STK L5510 library and the checkout process was broken. So I went searching for some kind of answer to the situation and found APAR IC45537 which states the problem has been known since March of 2005. IBM has not resolved the issue within TSM but has relied on a local fix to resolve this issue. So I decided to post the script I created here to help those people out who have an ACSLS library and are looking to share it between multiple TSM instances and don't want to have to deal with Gresham's software.

Here is a basic rundown of what the script does.

On each library client DRM checks the tapes out with a REMOVE=NO option and creates a file with a list of the tapes.
On the library manager the tapes are checked back into the library.
The Library manager then checks every library clients DRM tapes out.

Tuesday, May 23, 2006

LAN-Free In A Shared Library Environment

I had to setup a LAN-Free client recently and ran into some trouble with the tape environment.  As you all know I use a shared library environment where multiple TSM servers share a single large library through a library controller TSM instance.  This works great since it allows for a shared scratch pool and TSM can be bounced faster since the DB is less than 2GB.  The problem arises when trying to setup a LAN-Free agent in this complex environment.  If you have ever read the directions for LAN-Free you’ll notice they can be quite confusing since they switch the client port to 1502 to accommodate the LAN-Free agent’s default of 1500.  Now understand 1500 makes sense because the LAN-Free agent is really just a stripped down TSM server. Since the TSM server uses 1500 by default so does the agent.  I decided to use port 1502 for the agent but forgot to change it in the dsmsta.opt file. This kept me from being able to connect to the agent from the client since it was looking at port 1502 and the agent was still using port 1500.

Another issue the directions don’t fully explain is where to point the LAN-Free agent when setting it up.  I will explain how here and hopefully make it easy to understand.

1. Setup the dsm.sys client file with the following lines

ENABLELANFREE           YES
LANFREECOMMMethod       TCPIP
LANFREETCPServeraddress <loopback, DNS name, or IP>
LANFREETCPPort          1502

2. Define the agent to the node’s TSM server and the library controller as a server

define server storagent serverpassword=passw0rd hladdress=<loopback, DNS name, or IP> lladdress=1502

Also don’t forget to register the node if not registered already.

register node <nodename> <password> domain=<domain name>

3.  On the TSM library controller instance path the drives seen by the node/LAN-Free agent machine.  I am assuming you have connected the client node to the SAN environment and zoned a number of drives to the node.  When seen in the OS you can define the path. Make sure you map the paths correctly. In AIX this can be done by running the lscfg –vp | more command and noting the drive serials and noting them to their corresponding drive in TSM.

DEFine PATH STORAGENT <Drive Name> SRCType=SERVER AUTODetect=YES DESTType=DRIVE LIBRary=<Library Name> DEVIce=/dev/rmtX ONLine=YES

Note:   For ACSLS libraries more configuration parameters need to be set. I am showing an IBM hardware example since I would never use anything else!

4. On the client node go to the storage agent’s folder and update the dsmsta.opt file with the following

     tcpport 1502

5. Now from that storage agent directory run the following command

dsmsta setstorageserver myname=storagent mypassword=passw0rd myhladdress=<loopback,DNS name, or IP> servername=<node’s tsm server IP or DNS name> lladdress=1500 <or port used by node’s tsm server>

Note:  Notice I am pointing the agent to the node’s TSM server. Even though it is a library client and does not control the drives, by defining the agent to both the client TSM server and the controller instance a handoff from the library client to the library controller will occur automatically.  If you do not define the LAN-Free agent to the library controller the agent will fail.

You should now be able to test the configuration by starting the dsmsta in the foreground and then from another telnet window start a TSM command line client and run a backup(if using Windows open a dsmc client). If setup correctly you’ll see the agent contact the controller for a drive and mount a tape and commence a LAN-Free backup.

Monday, March 13, 2006

How To Setup A Library Manager Instance (Revised)

I had to revise this as I left out the checkin of the tapes before the audit.  I had to do this process this weekend as we moved to a new library and library manager and I realized I left out the tape checkin.

I was recently asked how to setup a dedicated TSM Library Manager instance to resolve issues with using a production backup instance as the manager. There are definite benefits to using a dedicated instance like performance and manageability. Performance wise TSM has DB issues and when large tasks are running all around performance is impacted. This impact affects library usage and so having the dedicated library manager allows for a smaller DB and no heavy tasks to bog down all the mount requests. Manageability is increased in that all you need to worry about are the drives and their paths.  That’s right, no backups to worry about (except the DB) and even if you lost the systems DB backup and had to start from scratch the other servers sharing this instance could easily reconcile their inventory and you would not lose any server data (so it’s also a lot safer to use than relying on a production TSM instance). If this instance is on a dedicated server also, do not backup the server to the library manager, back it up to one of the other instances. NO BACKUPS OR ARCHIVES SHOULD BE DONE TO THIS INSTANCE. The key to the dedicated instance is keeping the DB as small as possible and this is easily done if nothing else in run on the instance. When creating our library manager instance I was unsure how large to make the DB so I made it 2GB, and it currently is 4.6% utilized. The instance starts fast and cycling it for updates or when problems occur keeps downtime to a minimum. Ok so here are the steps to setup the instance, just remember there will be an outage needed on the current TSM library manager as you remove drives and paths.

Step 1: Create the dedicated instance

You can create the instance fairly quickly by creating a subdirectory on the TSM server like so:

mkdir /usr/tivoli/tsm/libserv/bin

Copy the dsmserv.opt and if planning to use the old web interface the dsmserv.idl file to this new directory.  Then define a DB and Log volume either using raw logical volumes or us dsmfmt to format one. Depending on your library size I would make it 500MB to be safe.  At that size its space should not be too much of a premium.  The log can be half that and still function fine.  If you want to be extra careful you can be like me and make it 1-2GB but again my DB is barely used at that size. Once you have created the volumes then you need to run dsmserv format to initialize the instance. If the instance is going to be on a server with other TSM instances you’ll need to export TSM variables so they point to the new /usr/tivoli/tsm/libserv/bin directory.  Export the following variables before running the dsmserv format command:

export DSMSERV_CONFIG =/usr/tivoli/tsm/libserv/bin/dsmserv.opt
export DSMSERV_DIR=/usr/tivoli/tsm/server/bin
export DSMSERV_ACCOUNTING_DIR=/usr/tivoli/tsm/libserv/bin

Now you can run dsmserv format and the instance will be initialized and ready to be used. In the ../libserv/bin directory you should now have a dsmserv.dsk file that lists this instance’s DB and Log files. You can at this point either use the instance as is or load the old web interface definitions so that they are available to those who prefer it over the ISC. Once ready to use you can now start the instance and setup its settings for Server-to-Server communication. Remember the other TSM instances have to be able to talk to this instance. Make sure you set the HL and LL address, set the server password, set the server name, the URL, and don’t forget to set crossdefine to ON.

Note: The next step can be done ahead of time if you can allow for a longer library outage.

Once you have set the parameters you feel are necessary, whether for security or event and actlog retention, you can then move over to the current TSM library manager and begin removing the paths and then the drives (in that order). TSM does not like conflicts so don’t try to define the drives on the new Library Manager ahead of time as you could cause serious problems with the library. Delete all paths and drives then delete the library path and finally delete the library itself. You can no longer use this library definition since it is an automated library and when sharing the library the non-library manager TSM instances use a Shared library definition.

Step 2: Define server to server communication for all servers sharing the library

This is quite easy and I wont cover this much as this is fairly straightforward. On all servers that will be sharing the library make sure you have set their server name, server password, HL and LL address, URL, and set crossdefine to ON. Then (using the old web interface) on the servers that will be library clients select Object View -> Server -> Other Servers. Here you can see the servers defined and define new servers. Select Define Server from the drop down menu and then put in the new library managements info into the corresponding fields. Make sure you crossdefine and then your ready to setup the library.

Step 3: Define drives and paths on new library manager

Back on the new library manager instance you can now define the library and the drives and paths. Make sure when defining the new automated library you select the shared option to allow the library to be shared by other instances otherwise it will be accessible only to this instance.

DEFINE LIBRARY ATL01 LIBTYPE=SCSI SHARED=YES AUTOLABEL=YES

Now that the library is defined you need to define the library path and all the drives and their respective paths, this includes the path definitions for every other TSM server that will be using this library. Remember no drive or path definitions are made on the library clients. The only definitions for the library clients are paths on the library manager. Once the drives and paths are defined you will need to checkin the tapes and audit the library. The library manager should see the tapes in the library when you decide to check them in and now you can progress to the next step. If you have tapes that are moving from another library check them in at this time. You have to make a decision at this point to either checkin the tapes now or wait until the other servers have completed Step 4. When you check them in you should check them in as private then after each TSM server reacquires its tapes you can update the private tapes not owned by any TSM server to scratch.  This can be seen when you do a Q LIBVOL and the easiest way to do this is to use a select call to create a list then run the list against a shell script to update each tape.

Here is the select command:

SELECT VOLUME_NAME FROM LIBVOLUMES WHERE OWNER IS NULL

Here is the shell script I use:

echo PROCESSING.........

while read LINE
do
  dsmadmc -id=<admin id> -pa=<admin password> upd libvol <library name> $LINE status=scratch
  echo $LINE updated
done < $1

Step 4: Define shared library and update device classes

Now that the library clients can communicate with the new library manager you will need to define a new library definition. Know that you can reuse the name from the old library settings you deleted if you like. Here we will be setting up a shared library definition (again from the old web admin interface); select Object View -> Server Storage -> Libraries and Drives -> Shared Libraries. From the drop down menu select Define Shared Library and fill out the needed information of Library Name and Primary Library Manager. The primary library manager info should point to the server name you defined for the new library manager instance. Since the server name you defined has all the TCP/IP and port settings it is important you use the same name as the name given to the new library manager.  Once the library definition is created you will need to update the device classes on each library client to use the new library. You can use the old web admin interface selecting Object View -> Server Storage -> Device Classes then select the device class type that was in use (i.e. LTO device class) and update each device class by selecting each one then selecting the drop down menu and choose Update Device Class. Update the library name field and if needed set the mount limit if you don’t want this server to be able to use all the drives in the library. Setting the mount limit is an easy way to pseudo-partition the library when its shared. I highly recommend using the mount limit option to allow each system some dedicated access to drives without having to designate specific drives using set path definitions for each library client.

Step 5: Run AUDIT LIBRARY on each TSM library client

Now that the library clients can see the library manager they need to reconcile the library inventory so they can use their tapes. This can be done by running the audit library command AUDIT LIBRARY <SHARED LIBRARY> CHECKLABEL=YES. This will allow each library client to contact the TSM Library Manager and tell it to reassign its tapes back. This audit should be done periodically to make sure each TSM server sees correct volhistory information. If once the volumes have been reconciled for all TSM library clients and you do not see any scratch, you can run a check-in to allow the scratch volumes to be recognized. One thing to be aware of, on the old TSM library manager you will need to delete all volumes listed as remote. This will free up tapes to go to scratch otherwise you’ll have “phantom” tapes that have no data, are not used in any storage pool for any servers, but will show assigned to the old library manager instance. You can run the following command to delete them from your volume history, unfortunately there is no blanket command that seems to work to remove them all at once:

DELete VOLHistory TODate=TODAY Type=REMOTE VOLume=NT1904 FORCE=Yes

What you will want to do is generate a list of volumes from the old library manager that are in REMOTE status and then run that list through this command to delete the volumes from its volume history file allowing them to go back to scratch status when needed.

I hope you have all found this helpful and if I missed a step please feel free to add your input.