Backup Central

A couple of comments about what Wanda said about collocation and VTL's:

At some point, you do have a finite number of mount points defined for your
VTL. Even if virtual tape "mounts" are near instant, there is still some
overhead. A large number of clients "mounting" virtual tape after virtual
tape after virtual tape will have some sort of negative effect on the
overall throughput of their sessions. I'm not saying it will be
significant, but it could get there, depending on the VTL technology. A
few milliseconds here, a few there, and a controller that gets bogged down
under the mount request queue, you could cause yourself some issues.

And don't forget that virtual tapes are the same as physical tapes in one
major factor - they're sequential! So non-collocated storage pools could
have multiple clients asking for the same virtual tape, so there would be a
wait queue for the virtual tape. A VTL doesn't resolve this type of
contention, as it's at the TSM level.

I would argue that the cost of creating collocated volumes in a VTL is
negligible, and still has benefits on the restore side.

To echo a number of others comments in the thread - if you don't plan it
out right, it's not going to work. That goes for just about anything, from
vacations to VTL's!

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 06/11/2007 01:33 PM
-----

And you don't have to collocate in a VTL, since there is
zero effective tape mount time.=

Richard Rhodes said:

I'd love to have a couple vtl's. When we've priced them out they come
out to be much more costly (several times) that of tape for our
environment. We keep lots of old/stale data around which drives seems
to drive the cost of the VTL way up. I was hoping possibly use a vtl
for only primary data with the new feature of TSM v5.4, but that's not
going to work out.

VTL cost (even after dedupe) will never compare with the cost of tape
media alone, so tape will always be a cheaper medium if you take it out
of the library. When I say that VTLs are close to the price of tape, I
mean close to the price of a similarly-sized, fully-populated-with-media
tape library.

I personal opinion is that VTL's are a stop-gap solution. I think
compression and de-dupe have much wider application within a normal
disk subsystem where it could apply to a much wider range of
situations.

Pretty much everybody who is following the industry believes it will
morph into the "intelligent disk target" industry. VTL will continue to
be a personality they offer, but as other backup software products are
better able to back up to filesystems (TSM does it just fine), more VTL
vendors will offer a filesystem interface. Right now, the only one that
does a filesystem interface and de-dupe is Data Domain. (Copan has a
filesystem interface, but I don't think they're doing de-dupe through it
yet. Any day now.)

This is the bit problem I see with Tape. It seems to me that the
latest generations of tape drives have rated speeds that almost
defy the any ability to supply them with data. I almost which
I could purchase a modern tape drive that actually was slower.

Mmm... LTO-4: 120 MB/s native speed, 180 MB/s typical with
compression. (I'm using 1.5:1 compression, which is what I see most
often as an average actual compression ratio.) So... It wants 180
MB/s, and I've supposed to feed that with a 60-80 MB/s GbE connection.
(The only saving grace of modern tape drives is that they have variable
speeds. The LTO-4, for example, can go as slow as about 40 MB/s plus
compression.)

The problem is capacity. As vendors push capacity, they do so by
pushing the bits closer together. As they do that, the drive gets
faster.

On Tue, 12 Jun 2007 03:20:18 -0400, Curtis Preston <cpreston < at > GLASSHOUSE.COM> said:


Pretty much everybody who is following the industry believes it will
morph into the "intelligent disk target" industry.

I see this trend too. It makes me think of ATM. Remember ATM? Oy,
I sound like an old fart. Sorry. Topical, topical:

The problem I see with the intelligent disk target notion is that, the
smarter you try to get, the more management you have to do, and the
more statistical duplication you have to push under the covers. How
would you feel if you had to map and tune RAID-5 regions between
platters?

And, (and here's the psychological kicker) the more you are out of
control of the actual processes. This does not offend most
administrators of e.g. windows file-service servers: the performance
required is sufficiently modest, and the demand sufficiently diffuse,
that things like "Which platters is this coming from" never arise.

But if you really want to understand your performance and bottlenecks,
then you're in vendor motel land, with extra-price tools to "help"
you. It's a storage cloud, and just trust us, it'll all work out.
ATM.

For administrators accustomed to operating the presented interface,
this is not worrying. For administrators accustomed to understanding
and controlling the underlying behavior, it is disconcerting, and in
the way.

This doesn't mean it won't be a great way to make money. The
advantage to selling restricted and concealing interfaces is that you
can access a market which is incompetent to challenge you, and each
flaw in product version N can be a sales opportunity for N.1. Witness
Windows.


- Allen S. Rout

Hi Everyone!

I have successfully completed the following:

Defined a scsi library: cdlb_dev
Defined a path from the tsm server to the cdl library: define path tsmdev
cdlb_dev srctype=server desttype=library device=/dev/smc0
Define LTO drives for the cdl library: define drive cdlb_dev lto2-27
Define tape paths for the lto2 virtual drives: define path tsmdev lto2-27
srctype=server desttype=drive library=cdlb_dev device=/dev/rmt27
Define a device class for the cdl library: define devclass lto2_cdlb
library=cdlb_dev devtype=lto format=ultrium2 mountlimit=drives
Define a cdl storage pool: define stgpool cdlb_aix lto2_cdlb pool=primary
maxsize=5G maxscratch=100 next=tape_aix hi=90 lo=70 reclaim=50 reclaimpr=1
collocate=no migdelay=30 migpr=1 (I have set the mgdelay to 30 so that we
keep 30 days of backups within the cdl until it moves to onsite tape)
Label virtual volumes: label libvol cdlb_dev search=yes checkin=scratch
volrange=db0000,db00209 labelsource=barcode

In order to start using the cdl and the cdl storage pool cdlb_aix in the
order of: aix (disk pool) --> cdlb_aix (cdl aix primary sequential storage
pool) --> tape_aix (primary sequential storage pool which is physical lto2
tape) --> copy_aix (offsite lto2 tape pool for offsite disaster recovery
purposes)

Would I just have to update the aix disk pool's next storage pool to be:
cdlb_aix? And then the data will stay on the cdl for 30 days since I have
the migdelay set to 30? And what order does it make sense to migrate and
backup the data?

Scenerio 1
Client backup to aix disk pool
Migrate data to cdlb_aix
backup cdlb_aix to copy_aix
backup tape_aix to copy_aix
Migrate cdlb_aix to tape_aix after 30 days
Will I ever need to run a job to backup the aix disk pool to the copy_aix
pool?

Scenerio 2
Client backup to aix disk pool
Backup aix disk pool to copy_aix
Migrate data from aix disk pool to cdlb_aix storage pool
backup cdlb_aix to copy_aix
backup tape_aix to copy_aix
Migrate cdlb_aix to tape_aix after 30 days

Any suggestions are greatly appreciated! Thanks!

********************************
Joni Moyer
Highmark
Storage Systems, Storage Mngt Analyst III
Phone Number: (717)302-9966
Fax: (717) 302-9826
joni.moyer < at > highmark.com
********************************



"Allen S. Rout" <asr < at > UFL.EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
06/12/2007 10:00 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
Re: How to Incorporate a CDL into TSM environment?






On Tue, 12 Jun 2007 03:20:18 -0400, Curtis Preston
<cpreston < at > GLASSHOUSE.COM> said:


Pretty much everybody who is following the industry believes it will
morph into the "intelligent disk target" industry.

I see this trend too. It makes me think of ATM. Remember ATM? Oy,
I sound like an old fart. Sorry. Topical, topical:

The problem I see with the intelligent disk target notion is that, the
smarter you try to get, the more management you have to do, and the
more statistical duplication you have to push under the covers. How
would you feel if you had to map and tune RAID-5 regions between
platters?

And, (and here's the psychological kicker) the more you are out of
control of the actual processes. This does not offend most
administrators of e.g. windows file-service servers: the performance
required is sufficiently modest, and the demand sufficiently diffuse,
that things like "Which platters is this coming from" never arise.

But if you really want to understand your performance and bottlenecks,
then you're in vendor motel land, with extra-price tools to "help"
you. It's a storage cloud, and just trust us, it'll all work out.
ATM.

For administrators accustomed to operating the presented interface,
this is not worrying. For administrators accustomed to understanding
and controlling the underlying behavior, it is disconcerting, and in
the way.

This doesn't mean it won't be a great way to make money. The
advantage to selling restricted and concealing interfaces is that you
can access a market which is incompetent to challenge you, and each
flaw in product version N can be a sales opportunity for N.1. Witness
Windows.


- Allen S. Rout

As I see it, there are two areas where you get performance hits when
restoring from non-collocated volumes:
1) Tapes Mounts: In my experience my VTL makes this problem
insignificant.

2) Spinning Sequential Media: Yes, VTL volumes are sequential and if
you define your tapes as 50GB native and then with compression get 100GB
written to the tape, you may have to spin through 99.9GB of data to
retrieve a 0.1Gb file. However if you define 10GB volumes you only have
to spin through 1/5 of the data to reach your 0.1GB file. Also with
smaller volumes you are more likely to get "natural collocation" because
a client that writes directly to tape is more likely to fill up a tape.
Obviously if you define smaller and smaller volumes at some point you
will have a "tape mount bottle neck".

Just one way to manage the trade offs.

H. Milton Johnson
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Nicholas Cassimatis
Sent: Monday, June 11, 2007 12:45 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Fw: How to Incorporate a CDL into TSM environment?

A couple of comments about what Wanda said about collocation and VTL's:

At some point, you do have a finite number of mount points defined for
your VTL. Even if virtual tape "mounts" are near instant, there is
still some overhead. A large number of clients "mounting" virtual tape
after virtual tape after virtual tape will have some sort of negative
effect on the overall throughput of their sessions. I'm not saying it
will be significant, but it could get there, depending on the VTL
technology. A few milliseconds here, a few there, and a controller that
gets bogged down under the mount request queue, you could cause yourself
some issues.

And don't forget that virtual tapes are the same as physical tapes in
one major factor - they're sequential! So non-collocated storage pools
could have multiple clients asking for the same virtual tape, so there
would be a wait queue for the virtual tape. A VTL doesn't resolve this
type of contention, as it's at the TSM level.

I would argue that the cost of creating collocated volumes in a VTL is
negligible, and still has benefits on the restore side.

To echo a number of others comments in the thread - if you don't plan it
out right, it's not going to work. That goes for just about anything,
from vacations to VTL's!

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 06/11/2007 01:33
PM
-----

And you don't have to collocate in a VTL, since there is zero
effective tape mount time.

I'm not looking at the spinning through the volume to find the file, I'm
focused on the fact that a volume can only be accessed by one client at a
time. You have to read the data to be restored, which takes time. If you
have one client reading the volume, any other access to that volume has to
queue up. With a slow client (or a fast one pulling a large file), you can
develop some access contention, which is a bottleneck that collocation
resolves. That's why I still see collocation playing with VTL's.

It all comes back to "Why do you want a VTL?" which is another way of
asking, "What problem are you trying to solve/avoid?" I'm sure there are
people who are getting VTL's because they have to spend their budget or
they lose it - and the rest of us are jealous of them for that! But, as
with most other technologies, implementing a VTL just moves the
bottleneck/weakest link to another spot, which may not be the best solution
for a given environment.

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 06/12/2007 11:41 AM
-----

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 06/12/2007
11:13:30 AM:

As I see it, there are two areas where you get performance hits when
restoring from non-collocated volumes:
1) Tapes Mounts: In my experience my VTL makes this problem
insignificant.

2) Spinning Sequential Media: Yes, VTL volumes are sequential and if
you define your tapes as 50GB native and then with compression get 100GB
written to the tape, you may have to spin through 99.9GB of data to
retrieve a 0.1Gb file. However if you define 10GB volumes you only have
to spin through 1/5 of the data to reach your 0.1GB file. Also with
smaller volumes you are more likely to get "natural collocation" because
a client that writes directly to tape is more likely to fill up a tape.
Obviously if you define smaller and smaller volumes at some point you
will have a "tape mount bottle neck".

Just one way to manage the trade offs.

H. Milton Johnson=

Yes a virtual tape volume can be accessed only by one client at a time
and if two processes/clients try to access the same volume at the same
time one process/client must wait. Again smaller volume sizes decreases
the chance that a contention would happen and also decrease the
contention duration.

Why a VTL? With us we found that when we out grew our physical library
we would have to have to buy over 30 physical drives in order to be able
to do backups, restores, cut off-site tapes and reclaim on/off site
tapes in the time allowed. That amounted to some serious money, more
than our VTL costs. When you also take into account the costs of the
much larger DISKPOOL a physical tape library requires, growing a
physical tape library in a TSM environment is not cheap. The VTL
footprint is also smaller which also should considered in the total cost
of ownership. Sorry, but we had to justify our VTL purchase.

Thanks,
H. Milton Johnson
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Nicholas Cassimatis
Sent: Tuesday, June 12, 2007 10:55 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Fw: How to Incorporate a CDL into TSM environment?

I'm not looking at the spinning through the volume to find the file, I'm
focused on the fact that a volume can only be accessed by one client at
a time. You have to read the data to be restored, which takes time. If
you have one client reading the volume, any other access to that volume
has to queue up. With a slow client (or a fast one pulling a large
file), you can develop some access contention, which is a bottleneck
that collocation resolves. That's why I still see collocation playing
with VTL's.

It all comes back to "Why do you want a VTL?" which is another way of
asking, "What problem are you trying to solve/avoid?" I'm sure there
are people who are getting VTL's because they have to spend their budget
or they lose it - and the rest of us are jealous of them for that! But,
as with most other technologies, implementing a VTL just moves the
bottleneck/weakest link to another spot, which may not be the best
solution for a given environment.

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 06/12/2007 11:41
AM
-----

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 06/12/2007
11:13:30 AM:

As I see it, there are two areas where you get performance hits when
restoring from non-collocated volumes:
1) Tapes Mounts: In my experience my VTL makes this problem
insignificant.

2) Spinning Sequential Media: Yes, VTL volumes are sequential and if
you define your tapes as 50GB native and then with compression get
100GB written to the tape, you may have to spin through 99.9GB of data

to retrieve a 0.1Gb file. However if you define 10GB volumes you only

have to spin through 1/5 of the data to reach your 0.1GB file. Also
with smaller volumes you are more likely to get "natural collocation"
because a client that writes directly to tape is more likely to fill
up a tape.
Obviously if you define smaller and smaller volumes at some point you
will have a "tape mount bottle neck".

Just one way to manage the trade offs.

H. Milton Johnson

On Tue, 12 Jun 2007 12:16:27 -0400, "Johnson, Milton" <milton.johnson < at > CITI.COM> said:


Why a VTL? With us we found that when we out grew our physical
library we would have to have to buy over 30 physical drives in
order to be able to do backups, restores, cut off-site tapes and
reclaim on/off site tapes in the time allowed. That amounted to
some serious money, more than our VTL costs.


I'm interested in the details on this. The VTL is disk-only, or is it
tape backed? I'm confused about how you need fewer tape-head-hours
when you virtualize processes.

- Allen S. Rout

How come no one has commented on the TSM device type=file as an alternative to VTL? I know it doesn't do de-dup. But doesn't it have a place? please comment this has baffled me since the first VLT hit the market.

We are considering purchasing a CDL 4100 and EMC is telling us we will get 1200MBps performance. Can anyone provide feedback on how their VTL -- specifically EMC DL 4100 is performing? I have spoken to some friends who have implemented one and are getting much lower performance #s... they say 100MB-200MB.

Thanks.

The VTL is a Sepaton S2100-ES and yes it is disk only.

I don't see the benefit that a "tape backed" system would bring, how
does that really differ from a physical tape ATL with TSM providing a
DISKPOOL front end?

"Fewer tape-head-hours": I understand your confusion, there was no way
to reduce the required tape-head-hours, but with a VTL if I need 30
physical tape drives then I configure the VTL as having 45 virtual
drives, more than enough. There is no price difference for configuring
my VTL as having 1 tape drive or 64 tape drives.

Off topic:
Configuration Based Pricing: I pray Sepaton will not start, and other
vendors will not continue, a pricing scheme based up how you configure
the software you PURCHASED. What's next, you have to may extra to your
OS vendor for each file system you create?

Thanks,
H. Milton Johnson
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Allen S. Rout
Sent: Tuesday, June 12, 2007 3:41 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Fw: How to Incorporate a CDL into TSM environment?

On Tue, 12 Jun 2007 12:16:27 -0400, "Johnson, Milton"
<milton.johnson < at > CITI.COM> said:


Why a VTL? With us we found that when we out grew our physical
library we would have to have to buy over 30 physical drives in order
to be able to do backups, restores, cut off-site tapes and reclaim
on/off site tapes in the time allowed. That amounted to some serious
money, more than our VTL costs.


I'm interested in the details on this. The VTL is disk-only, or is it
tape backed? I'm confused about how you need fewer tape-head-hours when
you virtualize processes.

- Allen S. Rout

On Wed, 13 Jun 2007 08:43:43 -0400, "Johnson, Milton" <milton.johnson < at > CITI.COM> said:

The VTL is a Sepaton S2100-ES and yes it is disk only.

I don't see the benefit that a "tape backed" system would bring, how
does that really differ from a physical tape ATL with TSM providing
a DISKPOOL front end?

Well, exactly.

But the distinction I wanted to make clear was: if you've decided to
store all your data on disk, then TSM has all the primitives necessary
to make that disk manageable, and you can discard the intermediate
appliance that makes the disk pretend to be a bunch of tape drives.
That's what everyone's getting at when they talk about FILE
devclasses.

So if you bought 23 TB of slow disk plus a pretend-im-tape-box, then
the tape box was a waste, if you're using TSM. If you're using
something without TSM's volume primitives, it could be extremely
important.


- Allen S. Rout

On Jun 12, 2007, at 6:21 PM, caldwem01 wrote:

How come no one has commented on the TSM device type=file as an
alternative to VTL?

It has been. But people are fixated on VTL.

Richard

In my case 10TB of type=file will store 10TB of data. 10TB of VTL will
store nearly 20TB of data. That is my only reason.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
caldwem01
Sent: Tuesday, June 12, 2007 5:21 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] How to Incorporate a CDL into TSM environment?

How come no one has commented on the TSM device type=file as an
alternative to VTL? I know it doesn't do de-dup. But doesn't it have a
place? please comment this has baffled me since the first VLT hit the
market.

+----------------------------------------------------------------------
|This was sent by caldwemi < at > us.ibm.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments.
Thank you.

In my world I am limited to 800MB to the VTL because I only have four
2GB fiber connections to the VTL. Migrations are limited to 400MB
because I have only two 2GB connections to the disk pools. When the Ins
are going to the right Outs I get close to the above speeds.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
lowneil
Sent: Tuesday, June 12, 2007 5:38 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] How to Incorporate a CDL into TSM environment?

We are considering purchasing a CDL 4100 and EMC is telling us we will
get 1200MBps performance. Can anyone provide feedback on how their VTL
-- specifically EMC DL 4100 is performing? I have spoken to some
friends who have implemented one and are getting much lower performance
#s... they say 100MB-200MB.

Thanks.

+----------------------------------------------------------------------
|This was sent by larry_ohall < at > yahoo.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments.
Thank you.