Auth. session limit

Hi,

Please take a look of this link where similar issue is been reported

https://community.emc.com/thread/116265

Thanks

Shivakiran

Hi Shivakiran

Thanks...have checked that out but different issue

Hi Thierry,

I've been noticing this same error since yesterday night.

nsrd Auth. session limit greater than 32 for mmd# 1 on device dd_backleg_lsu1/_AF_readonly.

I set the target and max session to 10 and 32 on both the readonly and the rw devices.

Thierry, you ever found out what was causing this ?

Anyone else has any idea ?

Thanks!

Francois

Restart nsr daemon. Check if the error still persists.

nope..still same and seeing it

We have noticed it during cloning when you get single session reads, but perhaps when multiple reads are going we get the same - I never paid attention to that.  I do not think we are in the same bus because we started using DD with SP4 which supports multiple reads (tested) for DD dev type devices and during those tests no issue has been seen.

I'm surprised to read that multiple reads are working in SP4+. I'm running SP5 and it still won't allow more than 1 read.

If a clone is running on a DD device and then I launch a recover from the same DD, it will still say "busy" until the clone is killed off or finishes. Oh and it will also throw those "auth session limit greater than ..".

For me, it happens every time more than one recover and/or clone session is trying to read from an AFTD device, which is a limitation of NW 7.x (only one recover/clone session on AFTP at a time).

LOL...but nope

I can bet half of my ass that you have nsrmmd core dumps when that happens

lapfrank1234 wrote: I'm surprised to read that multiple reads are working in SP4+. I'm running SP5 and it still won't allow more than 1 read. If a clone is running on a DD device and then I launch a recover from the same DD, it will still say "busy" until the clone is killed off or finishes. Oh and it will also throw those "auth session limit greater than ..".

That's not what we see.  We use Linux media servers and all reads are done from them (cloning and restores). Further, since we use DD Boost DFA, streams are read from DD directly so this might be part which enables us to use multiple reads. One of the reasons why we tested this was also because during nsrim check, we would see locks on device and no restore would be able to run - this is also fixed since SP4 (again, at least when using DD type of devices).

Slight distraction from discussion

If DFA works on specific module only...how ndmp_dsa can be configured to use DFA (excerpt from 7.6.3 admin guide)

Data write technologies

The nsrdsa_save program, on execution, establishes a save session with the

NetWorker server and listens on a port number. After a DSA receives data from the

NDMP client, there are three different technologies that a DSA can use to write the

data to a NetWorker storage device.

◆ Immediate save technology

The DSA reads the data by using TCP/IP into shared memory. The nsrmmd

program writes the data to a storage device from shared memory. Virtually all the

data from the NDMP client goes directly to nsrmmd.

◆ Direct file access (DFA) technology for a backup to disk

DFA directly writes the data directly to disk, bypassing the storage node

(nsrmmd program). The storage node only plays a role in loading the volume.

This is a highly efficient and high performance approach.

◆ Nonimmediate save technology (or remote save)

The DSA reads the data by using TCP/IP into a local buffer and transmits it to the

nsrmmd program that is also using TCP/IP. The nsrmmd program writes it to the

storage device. This approach is inefficient and has slow performance.

Yes, DFA in NW7 can be used only with specific module.  These are vast majority of my backups (and restores). I believe storage node itself is using DFA connection to DD and in that way is allowing multiple reads to kick in in SP4 and SP5.  The way we did a test was rather simple: we did two big backups and then run restore in loop for both - and both would run ok all the time - no issues.  Indeed, nw8 adds DFA to client backups, but I don't need that at the moment as databases and logs are 80% of the backup volume I have.  Going back to multiple reads, if you have multiple requests for reads, then media server itself will use DFA to pull back data and from there you get two indepedent streams to the different clients - my guess is, this is how they did it.

I don't think DD's DFA can be applied to any NDMP backup (unless perhaps VNX if they have DDBoost library, but to my knowledge this ain't officially there yet). So, NDMP backup will always go through nsrmmd unless it knows how to communicated with Boost device and that's possible only if local ndmpd will have a clue of that API (of course, you could always do a trick with 3rd party ndmpd server which runs on open system server and which has ddboost library, but I would not call that direct save). Now, around EMC World time things get announced and timing seems to be right for NW 8.1 (which kicks with official beta next month) so whether this will be in at the end or not - who knows. But we may already learn about this somewhere in May.