Hi Justin, in short:
Yes, you are right. A storage pool always covers only one library and that has a simple reason (beside the device class bound to a library name): How could TSM put a volume from the first (physical) library in a drive in a second (physical) library if this volume is needed by some operation in this storage pool? The answer is obviously, it wouldn't work without manual intervention. Ok, there a physical libraries that can be partioned into multiple virtual libraries and in that case TSM could theoretically put the volume into the other drive. But this feature would require some changes to TSM and the tape library firmware/software and isn't realized right now. Maybe you should put this as a requirement on the ADSM-R mailing list? You have to change the device class of the storage pool to the new library or use the Move Data command. For a separation of data and copies you should use specific optical libraries for your copy storage pool(s) only and other libraries just for the primary storage pools. So you can split the data and its copies between the libraries automatically. BTW: Which 3995 models will you use? IMO you shouldn't attach nine 3995 libraries to just one 6H1... (I wonder if it would be possible at all or supported by IBM with all the SCSI channels you will need). Try to minimize the number of libraries by choosing the largest model (C68) and use dual channel SCSI controllers if possible (see the "PCI Adapter Placement Reference" at http://www-1.ibm.com/servers/eserver/pseries/library/hardware_docs/sa38/380538.pdf for more information about maximum number and position of SCSI adapters in a 6H1). Mit freundlichen Gr��en, Met vriendelijke groeten, With best regards, Bien amicalement, CU/2, Dirk Billerbeck Dirk Billerbeck CC CompuNet AG & Co. oHG Enterprise Computing Solutions Am Jaegersberg 20, 24161 Altenholz (Kiel), Germany Phone: +49 (0) 431 / 3609 - 117, Fax: +49 (0) 431 / 3609 - 190, Internet: [EMAIL PROTECTED] This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this mail in error, please tell us immediately by return email and delete the document. Justin Derrick <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 11.03.2003 13:36:31 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: REPOST: Scratch Vols & Moving Volumes -------------------------------------------------------------------------- This message was originally sent March 4th, and received no replies. I've received messages from others on the list asking me to share the answer with them if one was received. Any input would be greatly appreciated. -JD. Hi TSMers. =) My customer is asking me some interesting questions I can't say I know how to answer - regarding moving volumes and allocation of scratch volumes across multiple libraries. The system uses IBM's Content Manager OnDemand product to archive documents -- which relies on TSM for long-term storage and storage management. The questions are fairly straightforward, and any information the group could bestow would be greatly appreciated. The questions are quite general, but just to be clear... I'm running AIX 4.3.3 on p/Series (6H1) with TSM 4.2.3.0. Connected to the server is one LTO library, and currently one 3995 Optical Jukebox with about 100 optical platters in it. In the very near future, a second and third optical jukebox will be added. Due to the legal requirements, all data stored on Write-Once (WORM) media. When the second library is added, the question quickly becomes: Can we move optical platters out of one library into another, to spread out the distribution of data, and 'load balance' retrievals across the additional 6 drives? My first inclination is to say 'No' because a device class includes the library as part of it's definition. Would checking out a volume from one jukebox and checking it into another jukebox change it's device class, or merely update the 'library' field in the volume's record? I'd try this out now, but I don't have that second jukebox yet. I know that the obvious solution is to 'move data' from a number of volumes to the newly installed jukebox -- and this would be my recommended solution, if the data weren't stored on expensive WORM media which apparently cost 80GBP each. The follow up to that question is this: If each library has a number of scratch volumes, and a new volume is required, how are the scratch volumes allocated to storagepools? Will a storagepool only claim a scratch volume from it's own library? If there are no scratch volumes in the current library, will it use one from another library? What is the best way to manage this without having to micromanage each jukebox? We're also trying to ensure that a copy storagepool for data stored on opticals does *not* reside in the same jukebox, for redundancy and availability reasons. There is potential for this system to include up to 9 optical jukeboxes in the near future. What questions need to be asked and decisions need to be made to ensure that the future is maintainable by mere humans? As always, thanks in advance for all your assistance and insight. I've been a subscriber to ADSM-L for over two years now, and find the collective skills of the list an exceptionally friendly resource for my toughest questions. In short... Thank You. =) -JD.
