PJ
ADSM.ORG Senior Member
I see - you compare VTL to physical tape rather than file.
PJ
PJ
-
-
Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)
Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.
VTL Solutions Used
- Thread starter dhcolesj
- Start date
THE_WIPET
ADSM.ORG Senior Member
we are activating our VTL (EMC 4106) in the next 2days We are in the same situation as Josh597... cant wait to have it in prod... The file dev class is really interesting with the possibility to have multiple node accessing the file with 5.5... but after studies.. we think a 100TB VTL was the way to go.
scottarcher
ADSM.ORG Member
VTL vs SETA
Our management has the VTL buzzword caught in their brain cell.
We currently have about 90TB of primary tape storage pool with 24hours worth of seta disk landing pool. So far (with the exception of Sepaton's dedup software) I don't see any advantage for buying 100TB of VTL over 100TB of seta. Setting up 100TB of SETA as the primary pool and only using tape for the offsite copy pool solves most of our reclaim/migration/tape drive/restore time/backup time problems.
Can anybody tell me why 100TB VTL would be preferred over 100TB landing/primary pool? Costs seem to be fairly equal.
Another question I never really get a straight answer on is: Don't VTLs still read each virtual tape sequentially to get to the file they need to restore?
TIA,
Scott
Our management has the VTL buzzword caught in their brain cell.
We currently have about 90TB of primary tape storage pool with 24hours worth of seta disk landing pool. So far (with the exception of Sepaton's dedup software) I don't see any advantage for buying 100TB of VTL over 100TB of seta. Setting up 100TB of SETA as the primary pool and only using tape for the offsite copy pool solves most of our reclaim/migration/tape drive/restore time/backup time problems.
Can anybody tell me why 100TB VTL would be preferred over 100TB landing/primary pool? Costs seem to be fairly equal.
Another question I never really get a straight answer on is: Don't VTLs still read each virtual tape sequentially to get to the file they need to restore?
TIA,
Scott
st4rdr
Newcomer
- Joined
- Apr 7, 2008
- Messages
- 1
- Reaction score
- 0
- Points
- 0
I was under the impression that Dedup wasn't available until v6 (current GA is 5.6) and that IP replication was even further down the road.I love to wrk with NETAPP VTL becos" DEDUP" /IP replication (new features)
PJ
ADSM.ORG Senior Member
@scott
Does that price include dedup and you're talking about something like 10TB physical disk? If not, I don't see how a VTL could come to the same pricepoint as the disks alone (it sure didn't in our case - but then our buying department is well known for its ruthless negotiating tactics ;-) )
@wipet
I wonder what those studies looked like.
Don't get me wrong - I don't mean to be thick or anything but I just don't get the point about VTLs with TSM except in very, very special circumstances which none of you guys really seem to have.
PJ
Btw. TSM never reads through sequential media to pick an object. It knows where it starts and skips to that position. Physical tape, VTL, sequential file - doesn't matter.
Does that price include dedup and you're talking about something like 10TB physical disk? If not, I don't see how a VTL could come to the same pricepoint as the disks alone (it sure didn't in our case - but then our buying department is well known for its ruthless negotiating tactics ;-) )
@wipet
I wonder what those studies looked like.
Don't get me wrong - I don't mean to be thick or anything but I just don't get the point about VTLs with TSM except in very, very special circumstances which none of you guys really seem to have.
PJ
Btw. TSM never reads through sequential media to pick an object. It knows where it starts and skips to that position. Physical tape, VTL, sequential file - doesn't matter.
THE_WIPET
ADSM.ORG Senior Member
PJ all depends of how you see thing... reclamation was not the starting point for the VTL studies The main point is e-vaulting with our DR sites. some system need to be up in less than 8 hours so we started to look for system that could help us We've look a active datapool etc.. And our DS4100 40TB diskpool was getting EOL. The VTL will sure help our reclamation and it's step one before adding the second VTL in a couple of month in the other sites. and add the deduplication from EMC
Last edited:
PJ
ADSM.ORG Senior Member
Ok, so you, too, just looked at VTL vs. physical tape and never compared sequential file?
PJ
PJ
scottarcher
ADSM.ORG Member
PJ
ADSM.ORG Senior Member
Yes it does - only much, much faster. Same with sequential file.
PJ
PJ
THE_WIPET
ADSM.ORG Senior Member
Nope... we've look at sequential file... the battle was really hard between the 2 of them.. But the VTL are already dedup compatible and waiting for TSM 6 with DB2 and Dedup was not part of the plan.
I agree with you with more time before the implementation. We could go with sequential file with the same type of hardware as the VTL
I agree with you with more time before the implementation. We could go with sequential file with the same type of hardware as the VTL
ALT-G
ADSM.ORG Member
Excusing my ignorance, I still cannot see why anyone would want a VTL over a SAN device utilizing the FILE dev class. With a VTL your reclaims and associated task threads are limited to the number of drives that the VTL can emulate thus making these tasks a real challenge, especially if you have retention which results in alot of short term expiration. With the File dev class on a SAN device, such as our EMC Clariion we are able to make up to 256 mounts per stg pool, thus eliminating this restraint. What am I missing?
~Rick
~Rick
lidra
ADSM.ORG Member
Vtl
I dont know if I am the only one here with a situation that makes VTL necessary and not just a nice toy.
We have a huge TSM shop with 5000+ nodes backing up daily and monthly (yeap 2 nodes per server). We manage to do this by having over 20 TSM servers, and quite a number of libraries. As you can imagine, we have HUGE amount of data that we backup every day, and that can not be accommodated by just a few TSM servers, even 20 its a small number.
For years we used normal libraries, and we use heavily Library manager/Library Client architecture, and LAN Free backups.
I totally agree with the fact LAN free from big DBs need to go to the last LTO available technology. There is no way for a VTL to coupe with that. But out of 5000+ nodes I only have a little over 20 servers that can get benefits from LAN Free.
But what do you do when you have 10+ TSM servers, using the same library that has only 20 drives? My tape drives run 24/7. During the night for LAN Free, during the day for migration, TSM database backups, and if I get some spare time maybe reclamation.
Since each servers backups 5 to 10 TB every night that needs to go to tape daily. In this infrastructure collocation makes me laugh. Nice concept, no way to be implemented more than by groups (even if I would have the library 10 times bigger it is now). So some of the servers backups were spread over hundreds of tapes imagine recovering one out of it.
Migration runs for ages for each server. Reclamation never ends. Expiration runs for days.
So for us any bit of speed we can get its a plus, and can make a difference between meeting or not our SLAs. Since we have a budget, we need to be very careful on what we spend.
Using a VTL we solved a few problems in one go:
- Since TSM nodes do backups directly to VTL STG, I don't have a complicated SAN architecture (multiple SANs not needed).
- Collocation can finally be used, since mounting a volume does not take minutes, it takes seconds.
- Reclamation runs faster, and since I use small virtual tapes, it takes less time.
- I can use all my tape drives in the library for STG backup and offsite reclamation.
- I dont need a huge library on the back, as all the tapes are ejected everyday and sent away. All I need is a fast one. Not to mention a VTL has a smaller foot print on DC.
- Since I keep active STG on VTL, and we do backupsets on the fly, I can do full restores in hours for huge servers, and I can restore any data that was deleted from any of my servers, even that it was discovered missing after days. De-duplication helps us a lot with backupsets storage, since its same data as in active STG.
In my shop, doing FILE device on a SAN, its not a solution I am afraid, and I have to say VTL solved a lot of problems.
For anybody else, probably look at the FILE device on SAN, its less money same benefits.
Now, I have to say I don't work for any of the VTL providers, so I didn't just invented the situation to prove a concept.
I dont know if I am the only one here with a situation that makes VTL necessary and not just a nice toy.
We have a huge TSM shop with 5000+ nodes backing up daily and monthly (yeap 2 nodes per server). We manage to do this by having over 20 TSM servers, and quite a number of libraries. As you can imagine, we have HUGE amount of data that we backup every day, and that can not be accommodated by just a few TSM servers, even 20 its a small number.
For years we used normal libraries, and we use heavily Library manager/Library Client architecture, and LAN Free backups.
I totally agree with the fact LAN free from big DBs need to go to the last LTO available technology. There is no way for a VTL to coupe with that. But out of 5000+ nodes I only have a little over 20 servers that can get benefits from LAN Free.
But what do you do when you have 10+ TSM servers, using the same library that has only 20 drives? My tape drives run 24/7. During the night for LAN Free, during the day for migration, TSM database backups, and if I get some spare time maybe reclamation.
Since each servers backups 5 to 10 TB every night that needs to go to tape daily. In this infrastructure collocation makes me laugh. Nice concept, no way to be implemented more than by groups (even if I would have the library 10 times bigger it is now). So some of the servers backups were spread over hundreds of tapes imagine recovering one out of it.
Migration runs for ages for each server. Reclamation never ends. Expiration runs for days.
So for us any bit of speed we can get its a plus, and can make a difference between meeting or not our SLAs. Since we have a budget, we need to be very careful on what we spend.
Using a VTL we solved a few problems in one go:
- Since TSM nodes do backups directly to VTL STG, I don't have a complicated SAN architecture (multiple SANs not needed).
- Collocation can finally be used, since mounting a volume does not take minutes, it takes seconds.
- Reclamation runs faster, and since I use small virtual tapes, it takes less time.
- I can use all my tape drives in the library for STG backup and offsite reclamation.
- I dont need a huge library on the back, as all the tapes are ejected everyday and sent away. All I need is a fast one. Not to mention a VTL has a smaller foot print on DC.
- Since I keep active STG on VTL, and we do backupsets on the fly, I can do full restores in hours for huge servers, and I can restore any data that was deleted from any of my servers, even that it was discovered missing after days. De-duplication helps us a lot with backupsets storage, since its same data as in active STG.
In my shop, doing FILE device on a SAN, its not a solution I am afraid, and I have to say VTL solved a lot of problems.
For anybody else, probably look at the FILE device on SAN, its less money same benefits.
Now, I have to say I don't work for any of the VTL providers, so I didn't just invented the situation to prove a concept.
dhcolesj
ADSM.ORG Member
- Joined
- Jun 18, 2006
- Messages
- 103
- Reaction score
- 1
- Points
- 0
- Location
- Nashville, TN
- Website
- Visit site
Scott,
Answer to first question: Depends on what you want to do after it gets there. There are pros and cons on both sides and its really up to how much you want to manage it. A VTL such as Sepaton's can allocate space in a way that uses space more affectively, and they can compress the data. I haven't seen compression (server side) on file based pool.
Second question: No. According to a couple of reps I've spoken to the VTL emulates sequential tape to the TSM server, but is random on the back end. According to what I can remember more than one Client can have the same volume open at the same time. (still don't know about this one, seems fishy to me as I don't think TSM would allow this).
I'm going to be meeting with a Sepaton rep next week, so I'll ask some of these questions.
There's one thing I really don't understand : why would someone want to use a VTL when TSM FILE devclass IS a VTL emulation ?
The only advantage of VTL over File devclass is that it can compress data, but you can use deduplication devices like DATADOMAIN which allows file devclasses over a deduplicated filesystem.
The advantages of files are numerous :
No need to define any drive or library (I had a lot of issues with a Netapp VTL on which I had to provide the slot number for every virtual tape drive) With a file storage pool, it's just a parameter on the device class.
Since TSM 5.5, two nodes can access a single file for reading (which is not very important most of time anyway)
The main advantage is that you don't have to manage any mount point or virtual tape, everything is done automatically by TSM.
On VTL, things are more difficult to manage.
Anyway, most of VTL's features are made to allow other backup softwares to do things that TSM can do natively.
The only advantage of VTL over File devclass is that it can compress data, but you can use deduplication devices like DATADOMAIN which allows file devclasses over a deduplicated filesystem.
The advantages of files are numerous :
No need to define any drive or library (I had a lot of issues with a Netapp VTL on which I had to provide the slot number for every virtual tape drive) With a file storage pool, it's just a parameter on the device class.
Since TSM 5.5, two nodes can access a single file for reading (which is not very important most of time anyway)
The main advantage is that you don't have to manage any mount point or virtual tape, everything is done automatically by TSM.
On VTL, things are more difficult to manage.
Anyway, most of VTL's features are made to allow other backup softwares to do things that TSM can do natively.
schulerta
ADSM.ORG Member
My sentiments exactly egtegt
Jeff_Jeske
ADSM.ORG Senior Member
We have dual EMC DL720 CDLs with loaded 85TB uncompressed each. One is located at the home office and the other is located at the DR site connected via dedicated fiber. Also storage pool copies go accross the fiber to DR site.
These CDLs have been in production for about 3 years and have been painless to manage. They handle about 90% of our backup data. We are a 1000 server shop with about 100TB of prod and 80TB of test data.
We have 10 - IBM 3584 libraries with 12 drives each defined at each location. This configuration is painless to present to a new TSM servers and simple to recover to a DR server. The CDLs offer failover protection, better compression than we see from the agent on SATA, excellent drive space usage due to 20% recl settings, and MUCH faster restore speeds than tape.
We use these CDLs for busy servers with a large number of small files. Large DB servers are still backed up to tape on physical 3584 libraries.
I do prefer working with the CDL more than TAPE. I like have many more drives available and instant seek time for restores. Aside from the semi annual patching we do on the backend the CDL is pretty much hands free.
We also have SATA available to TSM. I'm not sure if I like working with SATA as much as the CDL but its TCO is less for sure. I haven't worked with it enough to run into any issues but I prefer the historical look and feel of a VTL to the large chunk of storage offered by SATA.
These CDLs have been in production for about 3 years and have been painless to manage. They handle about 90% of our backup data. We are a 1000 server shop with about 100TB of prod and 80TB of test data.
We have 10 - IBM 3584 libraries with 12 drives each defined at each location. This configuration is painless to present to a new TSM servers and simple to recover to a DR server. The CDLs offer failover protection, better compression than we see from the agent on SATA, excellent drive space usage due to 20% recl settings, and MUCH faster restore speeds than tape.
We use these CDLs for busy servers with a large number of small files. Large DB servers are still backed up to tape on physical 3584 libraries.
I do prefer working with the CDL more than TAPE. I like have many more drives available and instant seek time for restores. Aside from the semi annual patching we do on the backend the CDL is pretty much hands free.
We also have SATA available to TSM. I'm not sure if I like working with SATA as much as the CDL but its TCO is less for sure. I haven't worked with it enough to run into any issues but I prefer the historical look and feel of a VTL to the large chunk of storage offered by SATA.
gyuzik
ADSM.ORG Member
My $.02 on an old thread...
It is much easier to power and cool my 3584 tape library with 4 active drives at 30% usage, than having over 400 750GB SATA disks spinning 24x7.
It is much easier to power and cool my 3584 tape library with 4 active drives at 30% usage, than having over 400 750GB SATA disks spinning 24x7.
Mikey D
ADSM.ORG Member
Most of the EDL/VTL solutions now offer settings to spin the drives down as part of the green trend. Some of them are now offering 5400rpm vs 7200rpm SATA drives as well for further power savings.
