Shared Index Cache & Shared Mag Libraries 1

[CraigMcGill]

Hi everyone!

Some questions about shared index cache and mag libraries.

We have an overloaded Windows MA and are in the process of adding another to share the load. We have a Gridstor license so are going to share the fibre SAN-attached tape library and all drives with the new MA. No problem so far.

But what about the index cache? We can of course set that shared, but just how does that work? Can two Win MAs share the same SAN LUN? We’ve always been told never to zone a LUN to more than one Windows box as one will scribble all over the other’s data and corruption will occur. But if we share an index cache via the network (ie. a local drive on MA1 but served to MA2 via a network path), then doesn’t MA2’s index cache traffic have to go over the LAN to MA1? Seems a bit inefficient to me, as MA1 is still handling ALL index cache traffic. And if MA1 goes down, then MA2 can’t function at all. We’ve talked about creating another Windows box (VMware virtual machine) that has a LUN for the index cache where BOTH MAs would access it via the network. This eliminates the problem of one MA being rendered useless if the other goes down, but it also seems cumbersome - ALL index cache traffic then has to go over the network. Just what is the most efficient way for 2 Windows MAs to share an index cache (assuming a SAN LUN)? What are the advantages and disadvantages?

Now to mag libraries. Can/should we share them? Presumably there are the same locking issues – when one MA is accessing it (ie. doing a backup to it) can the other one also do so? If each MA has its own mag library, then they are separate. What happens if the full backup of server A happens one day to go through MA1 (so gets written to MA1’s mag library), and the incremental the next night happens to go through MA2 (so gets written to MA2’s mag library)? When a restore or a synthetic full runs, won’t they need BOTH MAs in order to work?

The objective is to get the most fault tolerant arrangement that gets the best throughout.

Thanks people!

 

[JG5]

Hi there. I've been using Gridstor for quite some time now with good results. I'll try to address some of your concerns.

I have 6 media agents, all of which have SAN attached libraries - not shared among each other. My commserve is also a media agent with an LTO library attached - this is where my index cache lives and is shared so that all other magnetic media agents can access it. I have one main media agent which is the primary path for most clients, directing backup traffic across the other media agents (spill and fill methodology). Once I implemented this my performace greatly improved. Specifically with SQL databases. I had a dedicated media agent for the databases before, but noticed that I had 4 other media agents doing nothing while the media agent backing up my databases was waiting on avaiable streams (I have several hundred databases). So if you have your streams and allocation policies set correctly, gridstor can be of great benefit.

I agree, if the media agent housing the index cache goes down, this does little good for the rest of the environment - that's why I located it on the commserve. If my commserve goes down, the index cache location is the least of my concerns. True, it communicates and moves data via the LAN, but it's not an unheard of amount and I have plenty of bandwidth so it has not been an issue for me thus far.

I don't share my tape library. The commserve media agent is the secondary aux copy location (magnetic) as well as severl tape copies that get sent offsite. I like to keep that end of it isolated so I can manage it more efficiently.

Another option I've thought about is to locate my shared index cache to a NAS share. Again, this would depend on how fault tolerant your particular environment would be - I just haven't gotten around to testing it on my end.

Hope this helps.