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: dirk.billerbeck AT computacenter DOT com
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 <jderrick AT CANADA DOT COM>@VM.MARIST.EDU> on 11.03.2003
13:36:31
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
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.
|
