A while back I did some searching in to NFS file pool for LanFree storge
agents. I figured that since Sanergy was using NFS for setup but sending
data across FC, that TSM should have to support NFS directly. I found a
comment in the TSM manuals (v5.5) that IBM does not support NFS for
LanFree access (even if it works).
Rick
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: 09/26/2011 06:11 PM
Subject: Re: vtl versus file systems for pirmary pool
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Although you can do "server-free" backups over IP without a VTL by
creating a shared "file library".
If you are using a file device class on an NFS system (such as data domain
or the like), you can have storage agents mount the filesystems directly
and write to it without going through the TSM Server. I accidentally
discovered this when I created a File dev class and set "shared=yes". Took
a while to figure out what happened.
If you have 10g NFS connections, might be worth looking into. (I just
accidentally did it, I don't actually use it in production)
Check out the following for more info, about half-way down.:
Storage Manager for AIX Server 5.5> Administrator's Guide > Configuring
and Managing Server Storage > Chapter 9. Defining Device Classes >
Defining and Updating Device Classes for Sequential Media
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
wPrather AT ICFI DOT COM
Sent by: ADSM-L AT VM.MARIST DOT EDU
09/26/2011 04:25 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] vtl versus file systems for pirmary pool
The one drop-dead difference is that if you want to do LAN-Free, the
target has to be a tape (or tape-emulating) device.
Can't use TSM filepools.
If you replicate between VTL's, it's transparent to TSM, but you have to
have the same vendor hardware at both sites.
Dedup may also be faster with a VTL, if your VTL does it in-line.
Also a VTL is often quicker to set up (which doesn't necessarily mean it
is easier to maintain, if you consider firmware updates, multiple
maintenance contracts, etc.)
TSM 6.2 has to dedup as part of the reclaim process,
post-data-landing-there. That isn't necessarily a bad thing, it's just a
different way.
To get replication of the deduped data, you have to set up a second/copy
pool yourself; but it does not have to be the same hardware on both ends.
There is nothing about having a VTL/VTL gateway that inherently means you
can do fewer concurrent backups than with a TSM filepool, depends on your
hardware. You can have a fast VTL or a slow crappy VTL, just depends on
what you pay for...
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Tim Brown
Sent: Monday, September 26, 2011 4:05 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] vtl versus file systems for pirmary pool
What advantage does VTL emulation on a disk primary storage pool have
as compared to disk storage pool that is non vtl ?
It appears to me that a non vtl system would not require the daily
reclamation process
and also allow for more client backups to occur simultaneously.
Thanks,
Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbrown AT cenhud DOT com <<mailto:tbrown AT cenhud DOT com>>
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255
This message contains confidential information and is only for the
intended recipient. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this message
to the intended recipient, please notify the sender immediately by
replying to this note and deleting all copies and attachments.
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that
certain
functions and services for BNP Paribas may be performed by BNP Paribas
RCC, Inc.
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
