Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

GridStor (Alternate Data Paths)

Status
Not open for further replies.

rdphill

Technical User
Dec 17, 2007
20
US
I am trying to explain to my manager the benefits of purchasing GridStor. I have worked in an environment in the past that had it installed from the very start. Now I work in a 6.1 SP4 setup where it was not purchased.

We do a descent amount of data (roughly 100TB a month) and have seven media agents and plans to expand.

We are using a IBM TS3500 w/3592 tapes that hold ~1GB compressed. We are always out of tapes. Never are there scratch available without me manually pruning data.

Retention is 28/1 cycle.

What would you say in the biggest advantage to implementing GridStor? How would you explain to a lead that doesn't have a lot of history with Commvault, why spending a sizable amount of money is worth it and will ease our media pain point?

Thanks
 
28/1 dang that seems excessive
I do daily - 7 days, Weekly - 30 days and so on....

As far as gridstor goes....

The real benefit is load balancing and fail-over paths.
out of your 7 media agents how many have control of your library? are you using any Maglib space?

Having gridstore allowed me to consolidate my Storage policies into a single policy for Tape data.
If you do not have Gridstor then you have to have a policy for each path right? so 7 policies for 7 media agents.
Would you not want to have 1 policy for 7 media agents and do failover or load balancing?


I backup about 370TB a month and we have Gridstor. I have only 4 Media Agents doing it. and only 2 of those have access to the tape library (Rest are Maglib)

Shared index cache and having a failover library path eliminate single point of failure. and it allows your other MA to pickup where the failed one left off.

Plus you can do load balancing or Spill & Fill across your media agents.

I would recommend getting it.
If only as a efficiency improvement.


I would think that Birky could give you the salesman type pitch for selling it to management :) I think he has probably given it a few times before.

 
Thanks Frbutler,

All the MAs have access to the library. We have tried to make our largest SAN attached clients MAs so as to take that traffic off the LAN.

I have one mag lib that holds data for 7 days and aux copies to tape for 28/1. Also, a virtual tape facility that basically does the same thing.

The problem I see is we have way too many storage policies. Sixteen total. So if I understand it correctly, each SP takes X number of tapes and holds onto it. Without GS, no other storage policy can use media from that SP.

Also, we can't failover data paths, so if MAs are available to move data, they can't unless that are specifically defined to do so...

Can you think of how I might better use existing media without GridStore? At this poiint we don't routinely offsite anything which is a problem in itself. our default is 28 days unless a dept ask for something special. Given that most of the tapes stay in the lib, what about cycles? is 28/1 the best way to acheive about a months worth of archive?

Thanks!
 
Correct

If you have a job on SP "A" and it writes 20mb to a tape
and you have no more scratch in the library.
SP "B" cannot write to the tape even though there is free space

I would see how receptive your management is to adjusting the retention cycles. There is currently no clear answer for you with the number of SP's you are using and no gridstor.

Because you do not have shared index cache you cannot consolidate your SP's into a single one unless you want Network traffic....
You could create 4 new storage policies and select 4 of your fastest MA's.... then move clients over to those evenly...but then you would be wasting the MA license $$

That was my problem also.... when I arrived at this jobs the first 6 months were spent implementing gridstor (they had it already but were not using it lol) and consolidating SP's into a single 1 for tape.

Talk with your sales rep and see if he will credit you some $$ for trading a few MA's in for Gridstor. (Tell him you are thinking of switching to NBU hehehe)

You will make up the efficiency on the back end and the cost will be about the same for maint.
We have a lot of SAN clients also but we elected to go the GB ethernet dedicated backup lan instead of making all large client MA's. MA's are big $$ and high maint $ also.



 
Hi Frbutler,

I have 6 media agents (with the Commserve being the only one which controls the tape library). I am using the shared index cache, fill and spill directly to magnetic. 5 of my media agents each have a secondary disk copy, daily and offsite tape copy. The secondary disk copy goes to the mag library attached to the commserve, and each tape copy goes from there to the library. Is there a more efficient method of getting everything to tape. In other words, can I consolidate to a single daily, offsite and quarterly tape copy that would include all of my clients?

Thanks.
 
Alright - so I went to lunch and I think I got my head around this - please correct me if I'm wrong. What I need to do is simply associate all of my subclients to one particular media agent (that media agent having load balanced additional data paths) and then create my tape copies from there, correct? One thing I am concerned about, and I will check the documents, is that I may be limited to the number of streams associated with the one storage policy rather than the sum of all the datapath streams for backup.
 
Not quite

You should associate all the subclients to a common storage policy(s). This storage policy(s) you associate to all media agents, then in a spill& fill setup you will be load balancing across all mount paths. You may wish to overide data paths at the subclient level.

Remember you can continue backup to the alternate data path with Gridstor deployed (providing you have setup the shared indexcache correctly) but you cant recover from a data path if the owning MA is down.

regards
 
Thats exactly how I set it up. I meat to say one storage policy rather than one media agent. The storage policy is load balanced (spill and fill) across the remaining media agents and magnetic library as additional data paths. I then have a secondary disk copy which automatically runs, and then finally my tape copies from there. The whole system seems to be much more efficient, and there are no wasted streams or resources as a result of not utilizing an available media agent. For example, I have a ton of SQL databases and had originally set it up so that all of the databases were backed up by a particular media agent. I found that I had 4 other media agents with magnetic libraries that were not being utilized, and that many of the databases would be waiting for an available stream to back up. Now that all of the media agents are set up as alternate paths for each other and the index cache is shared, all of the backups complete much faster and the resources are distributed and utilized evenly.
 
Don’t forget with GridStor you could end up with a client’s cycle split across several MediaAgents. If this scenario occurs all is well unless disaster strikes on one of these MediaAgents, then you could end up in a situation where you can’t recover the particular client’s backups. An idea would be to define preferred data paths on the more critical systems so that this separation is avoided where recoverability is more critical.
 
Good point and I will keep that in mind. All of my secondary disk copies and subsequent tape copies are made from the Commserve, which is also a media agent. I treat the primary magnetic media as a spool copy more or less, although I don't have it configured that way. So, worst case scenario, I can always recover from secondary disk, or 2 tape copies that are made every day as well. At least with my Commserve, I can get it back online pretty fast in the event of a disaster.
 
I only use Spill and fill on Maglib media agents
For instance I have 2 media agents with 4 mount paths each to SAN storage. Each is 1TB and each is a data path for that media agent.
I have it setup to fill and spill on these (Mostly SQL and Exchange brick lvl backups)

My tape library is set to just failover data paths with 3 media agents having the ability to host the drives.
But only 1 is the default

Most of my maglib jobs are set to 0 retention so it starts the aux copy within 20 mins of completing the backup to disk.
Then wipes it out for the next day's jobs
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top