Tivoli-Storage-Manager

I was fighting with our VTL again, and TSM was thinking all the drives were offline. In order to update the drive status, you’d need to go into the ISC and select each drive and set them to ONLINE. Since I’m a bit click-lazy, I wrote a simple nested for-loop, which gives me the output to update all the drives at once: 1 2 3 4 5 for i in 1 2; do for k in $( seq -w 1 32 ); do echo "UPDATE DRIVE VTL$i VTL${i}_DR${k} ONLINE=YES" done done Result is a list like this: ...

Well, I just had another look at our client scheduler services on our Microsoft Cluster. A while back we noticed that those scheduler services were going nuts after some time. Well, as it turns out, I can tell why. Microsoft Cluster Services have a feature called registration replication, which replicates a given key, if changed when the resource is online, to all connected cluster nodes. Now, we added the obvious registry key to the settings of our cluster resources for the scheduler services ( SOFTWAREIBMADSMCurrentVersionBackupClientNodes) and the scheduler service would use the same registry key to store it’s passwords. But it seems we were far off with that assumption. ...

I spent yesterday afternoon upgrading our TS7530, and in my fad I also upgraded TSM to 5.5.3. Now, once I started TSM it quickly started complaining about the paths to the drives. 1 2 3 4 5 6 7 8 9 ANR8873E The path from source TSM1 to destination VTL1_DR03 (/dev/lin_tape/IBMtape03) is taken offline. ANR8873E The path from source TSM1 to destination VTL1_DR03 (/dev/lin_tape/IBMtape03) is taken offline. HBA_LoadLibrary: previously unfreed libraries exist, call HBA_FreeLibrary(). ANR8873E The path from source TSM1 to destination VTL1_DR07 (/dev/lin_tape/IBMtape07) is taken offline. ANR8873E The path from source TSM1 to destination VTL1_DR07 (/dev/lin_tape/IBMtape-07) is taken offline. I thought maybe this is a mere device problem (we have had them before), so I rebooted the boxes. But still no luck and I went home after about an hour of trying without any luck. In the morning, my co-worker called our trustworthy IBM service partner, and the TSM consultant said he had the exact, same problem yesterday. We would have two options: ...

Well, my co-worker just called on my cell (it’s Friday, 16:00), and asked me which start-up script he needed to change in order to restore the database. My first response was, “ummm, that’s gonna be hard, we’re using heartbeat”. Okay, so after a bit of asking I got out of him what he wanted to achieve by changing the start-up script. Apparently he did something to crash Tivoli Storage Manager (or rather repeatedly crash it) and wanted to restore the database. He talked to one of the systems partner we do have (and I’m happy we have them most of the time), who in return told him how to do it, but forgot a minute after he hung up the phone. ...

In the past, I always had problems with SLES and our Tivoli Storage Manager client’s when backing up files with german umlauts. Well, today I looked a bit harder, and quite quickly found a solution. 1 2 sles9 root [0] > env | grep ^LC LC_CTYPE=de_DE.UTF-8 As you can see from the above, SLES9/10 ain’t setting LANG or LC_ALL (which I searched for first), but is setting LC_CTYPE. So, simply changing the LC_CTYPE in the init-script and/or prepending the dsmc command line with a new LC_CTYPE fixes my umlauts problems! ...

As I did some switching today (between the new lin_tape version by IBM and our own lin_tape version), I ended up writing those lines a dozen times. Here is (just for me, if you don’t care .. skip ahead) on how to generate a list of commands: 1 2 3 4 5 6 for i in $( seq -w 1 32 ); do token="${i/0/}" path_prefix="/dev/lt/IBMtape12245775" echo "DELETE PATH TSM1 VTL1_DR$i SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1" echo "DEFINE PATH TSM1 VTL1_DR$i SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL1 DEVICE=$path_prefix$((token+11))A1" done which should get you a list like this: ...

Well, initially I thought writing the OCF resource agent for Tivoli Storage Manager was the hard part. But as it turns out, it really ain’t. The hard part, is getting the resources into the heartbeat agent (or whatever you wanna call it). The worst part about it, is that the hb_gui is completely worthless if you want to do a configuration without quorum. First of all, we need to setup the main Linux-HA configuration file ( /etc/ha.d/ha.cf). Configuring that, is rather simple. For me, as I do have two network devices, over which both nodes see each other (one is an adapter bond of comprising of two simple, plain, old 1G copper ports; the other is the 1G fibre cluster port), the configuration looks like this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 udpport 694 autojoin none crm true use_logd on debug false coredumps false auto_failback on ucast bond0 10.0.0.10 ucast bond0 10.0.0.20 ucast eth2 10.0.0.29 ucast eth2 10.0.0.30 node tsm1 node tsm2 respawn root /usr/lib64/heartbeat/pingd -m 100 -d 5s ping 10.0.0.1 respawn root /sbin/evmsd apiauth evms uid=hacluster,root After configuring the service itself is done, one just needs to start the heartbeat daemon on both nodes. Afterwards, we should be able to configure the cluster resources. I find it particularly easier to just update the corresponding sections with cibadmin (the man-page really has some good examples). So here are my configuration files for two resource groups ( crm_mon doesn’t difference between resources and grouped resources, it’ll just show you that you configured two resources).