backups starting, but no activity

[jlh16]

Good Morning,

We recently upgraded from Networker 7.1.1 to Networker 7.3.2. We have a server at our production site and a storage node at our dr site. They are both behind a firewall, both run Solaris OS. We run our backups from the crontab using scripts that generate reports. We start our server backup at 18:00 and the storage node backup at 18:05. After the upgrade, the storage node backup gets started at 18:05, but there is no activity until 21:50 or later. Nothing happens at all, no errors or anything. Any ideas? I have a case open with Legato, but am getting impatient.

Thanks

 

[Martin999]

If the storage node is very busy during this time, there may be no activity, failing that, are there any drives free ???

Martin

 

[605]

If this ran already i assume that you need to open the firewall for a few more service ports due to new daemons in NW 7.3.+

Please read Tech Bulletin 388 for further details.

 

[jlh16]

Thanks 605. Pardon my ignorance here, but I don't recall setting the ports in our previous releases. We just used the defaults, service ports 7937-9936 and connection ports 10001-30000. That is what we have opened on the firewalls for all of our clients.

After reading your post, and having remembered doing this for an upgraded client that was failing, I used the nsrports command on the storage node. The service ports returned the correct range, but the connection ports returned 0-0. Hopefully this will solve our problems. I'm wondering how it worked at all! Thanks again.

 

[jlh16]

I should elaborate a little. The server had the service ports set to 7937-9936 and the connection ports set to 10001-30000. We did not do anything to change that after the upgrade. The storage node and some clients had the connection ports set to 0-0. EMC support tells me this should work, but from experience with a failing client, it didn't work. Do you think it wouldn't work with the server set to 10001-30000 and the storage node set to 0-0?

 

[haasemi]

The defined port range is OK. You can reduce the open ports as decribed in the manuals.
I think the problem is the definition of the connection ports: you have set this on the storage node & clients also to 10001-30000. It cannot work without connection ports.

 

[jlh16]

Thank you all, unfortunately setting the connection ports on the storage node did not fix the problem. Back to the drawing board!

 

[605]

0-0 means that the OS will actually assign the ports for you as requested.

-------------------------

Another issue is parallelism. Is it possible that the parallelism is so low that no stream can be openened any more? Please check:
- Server parallelism
- Client parallelism
- Target sessions
- Savegroup parallelism

The installation of a new version should not change anything. But you never know ...

 

[jlh16]

The server parallelism is set to 128, target sessions on each device is set to 6 (there are 12 devices total = 72 ) the client parallelism varies by client. The savegroup parallelsim is 0 for each savegroup. As far as I can tell, that should work. I'm nearly positive the values are the same as before the upgrade.

 

[605]

It might work somehow. The key parameter would be savegroup parallelism. 0 is not limiting anything. If you have multiple groups which overlap, it might be that the first one 'takes all streams' so none will be available when the next groups start.

 

[Martin999]

Stop networker, rm /nsr/res/tmp, restart.

Martin

 

[jlh16]

Can anyone explain the savegrp parallelism function? Ours is set to 0 for each group. I can't seem to find a solid explanation anywhere. Thanks.

 

[jlh16]

I think I found the explanation I was looking for. Please correct me if I'm wrong. We have our server parallelism set to 128, the maximum for our setup. If I want to run both groups at the same time, I should set the group parallelism to 64 for each? It was set to 0 before the upgrade and both groups ran together.

 

[605]

From the nsr_group manpage:

savegrp parallelism (read/write)
If this value is non-zero, then the savegrp program eschews all other parallelism policies and
attempts to keep that number of saves running.

If a new parameter is introduced, it will not change the old behavior. Unfortunately, '0' has been choosen for the unlimited 'alias'.