How can TSM pilot VTL Replication

[Bartdo]

I noticed that the IBM TS7650 VTL (ProctecTIER) supports replication between two VTL appliances. I have checked the redbook that has a chapter on replication (SG24-7652-01), but I have not determined how TSM is able to tell the VTL what volumes to replicate. In TSM, we manage StgPools, and it seems that you must tell the TS7650 what cartridges to replicate (in the GUI, I believe, not via an API). My understanding of the situation is as follows, maybe someone can corroborate it, or offer other remarks.
What we need is a feature in TSM that denotes what StgPools are eligible for replication, so that an instruction can be sent from TSM to the VTL for each volume in that StgPool to be replicated. As replication in the VTL because widespread, TSM should be looking into how to achieve this, though it is not obvious, since VTLs do not have a standard mechanism for specified what to replicate. In the meantime, we are stuck with the all or nothing approach – all data in the VTL is replicated, since we don’t know how to do this conveniently at any other level. Or nothing is replicated by the VTL, and we do it via TSM with Copy StgPools.

 

[mccleld]

An approach I'm taking with a customer to segregate replicated and non-replicated data within the same TSM Server instance, albeit with a Data Domain appliance rather than ProtecTIER, is to create two distinct virtual libraries and define these to the TSM Server.

Replication in Data Domain units is at the directory level under the covers: a directory when using the VTL mode is a collection of virtual tapes (a 'pool'), and the best way I can figure to control what data goes to which pool from within TSM is to define two separate libraries. I'm open to suggestions if anyone else is doing this differently.

It'd be great if were were a way of managing this from within TSM at a Storage Pool level, but I'd be surprised if it were to appear (unless if it were part of a standard across all VTLs).

/David Mc
London, UK

 

[GregE]

Bartdo, I don't think that replication is an all or nothing proposition. Doesn't ProtecTier replicate only changes? Why would it replicate everything each time?

TSM would play no role in this but as you say it would be nice if it could. Mccleld mentioned DataDomain, which I've been researching. Replication is between DataDomain boxes. TSM knows nothing about that replication. If you have a Primary storage pool and you use your VTL replication, you are replicating to another Primary storage pool, you are not creating a TSM copy pool. You would have to use normal TSM storage pool backups for that. I agree that it would be VERY nice if TSM could do the storage pool backup and keep the VTL data deduped. It would be extremely fast, just as the VTL appliance replication is very fast since it's only replicating deduped data.

 

[Bartdo]

Yes, I agree that the ProtecTIER VTL will surely replicates only the changes. But some situation may warrant to replicate only certain StgPools, not all of them.
Another topic is - when are the replicas used ? Only in case of a real disaster, or can they be used when the primary tape volume has a media error ? If so how is this done ?

 

[GregE]

I understand now. I don't know how ProtecTIER replicates only certain storage pools. Mccleld described DataDomain and it may be similar. I'm not familiar with ProtectTIER.

Because replication is happening at the VTL level, unknown to TSM completely, I don't think you could use them for what you are wanting. You would have to use the TSM copy pool data. You're thinking on the same lines as I was a few weeks ago, and it was bugging me. DataDomain documentation had a diagram mentioning its replication of primary to copy pool, but no way that's correct because TSM would know nothing about copy pool in that scenario. Drove me nuts.

I'm basing it on TSM having no knowledge of the VTL replication. The same would apply to random disk or FILE device class if TSM backs up to those. If disk storage appliance/array/etc is replicating the data, TSM knows nothing about that replicated data.

I'm currently researching similar information. Replicating onsite primary storage to offsite primary storage (TSM knows nothing about this), then let TSM do its normal stgpool backup of onsite primary pools to offsite copy pools. Offsite, there is no running TSM server (it would be there, ready to bring online). It would be brought online with same naming, IP, etc as the primary TSM server, in the case of disaster recovery so all of the storage pools at the DR site will look the same as they do at the primary site.

 

[Bartdo]

The point that bothers me is that the redbook (sg247652) is advertising a higher level of control. Here is a quote:
ProtecTIER's replication is designed to provide the user with great flexibility, to work
seamlessly with any of the leading backup applications, and to fit easily within the overall tape operations paradigm. Replication is policy based, allowing users to define several different
policies for replicating cartridges from one system to another. The granularity of the
replication policies allows users to set policies for an individual cartridge, a pool of cartridges,
or an entire virtual tape library.

Is all that just hot wind ?
Hey IBM, if you are listening, can you show us how well your two products fit together ?

 

[mccleld]

If the ProtecTIER is similar to the Data Domain, a 'pool' as defined at the VTL level (i.e. a collection of virtual tapes within a barcode range) is different to a 'storagepool' at the TSM level - hence my defining two virtual library instances to my TSM server to align them in order to segregate replicated and non-replicated data. Not a big deal, and on paper it should work just fine to meet my customer's requirements.

If there's an easier way, such as you're mooting, let me at it.

/David Mc
London, UK

 

[lapfrank]

I've just implemented a TS7650G with replication between the primary site and the secondary (DR) site.

I confirm that it does not use the copy storage pool command from TSM. Actually, TSM now sees only primary storage pools. I deleted the copy pools and on the ProtecTIER, I've set up a replication policy that simply replicates all the cartdriges to the DR site.

When you need to recover, everything is done through the ProtecTIER. I've attached a presentation from IBM that is actually really useful to understand how it works (if you know a bit about the ProtecTIER VTL).

You can find that document with sound also on the web... which is really useful!
I couldn't attach it, because of the size (35 megs).

 

[mccleld]

Same with the Data Domain appliances: the primary storage pool virtual tape volumes (essentially just flat files) are replicated to another Data Domain appliance. In the event of a DR, you kill replication between the DDRs and virtually check-in the virtual tapes to the DR site's VTL - this may include your TSM Server's database backup which enables you to recovery the TSM server database. Any recoveries now take place essentially from primary (virtual) storage pool tape volumes.

Big win with this approach: not having to spend a chunk of your TSM admin day running BACKUP STGPOOL command.

__________________
/David Mc
London, UK

 

[GregE]

Big win with this approach: not having to spend a chunk of your TSM admin day running BACKUP STGPOOL command.

So you are relying completely on primary-to-primary replication? No copy pools? I was under the impression that to protect from corruption, you'd have a copy pool at the DR site, backed up from the primary pool at the primary site.

 

[lapfrank]

So you are relying completely on primary-to-primary replication? No copy pools? I was under the impression that to protect from corruption, you'd have a copy pool at the DR site, backed up from the primary pool at the primary site.

Well, the notion of "copy pool" is just a name. It is still a valid copy of all the cartdriges. The only difference is that TSM does not know about it.

Copy pools do not protect you any more from corruption, if I understand correctly

It is all outside of it's scope. It's actually way easier to manage, since you do not have to update all primary volumes to access=destroyed, then restore them to primary ones (all in case of a real disaster), because TSM in the DR environment will see all the same volume names, etc. including the TSM database.

 

[bkupmstr]

Have you thought at all about what your reusedelay parameters are?

With the replication technique you are utilizing, will you have data around if you need to recover the TSM database back a few days?

 

[lapfrank]

yeah, I did think about the reuse delay. I've always used the same number for the primary storage pools that I did for the copy pools so that wasn't really an issue. I know that a lot of people use 1 or 0 days for their primary storage pools though, while keeping more for the copy pools. This would really need to be changed in a protecTIER IP replication scenario.

I keep 5 days of database backups, so I'm using 5 days there. I really think it should be set to at least 3 days to account for replication delays.

I've also created a second virtual tape library (to which I've set a different replication policy) only for my database backups, to make sure they are replicated asap.

 

[mccleld]

@backupmstr Yes, that's a good point and the REUSEDELAY certainly is considered carefully alongside how far back the TSM Server database backups are retained.

@grege Yup, primary to primary replication all the way. Corruption? I'd sure value people's input on the perceived risks of this in a VTL environment.

@lapfrank I've done a few DRs now with this technique and it's a whole lot less messy for sure. Interested on what you mean wrt to the TSM Server DB though.
__________________
David McClelland
London, UK