One of the policy changes made in NetWorker 7.4.4 (and which applies to 7.5.x as well) is that of client parallelism when it comes to new clients.
I have to say, and I’ll be blunt here, I find the policy change reasonably inappropriate.
In a post 7.4.4 world, NetWorker defaults to giving new clients that you create a parallelism of 12. I’d always thought that 4 was a terrible default setting, being too high, in a modern environment; you can imagine then what I thought when I found the new default setting was 12.
There’s a good reason why I find this inappropriate. In fact, it’s implicitly covered in my book by the sheer number of pages I devote to discussing how to plan client parallelism settings. In short, client parallelism settings are typically not something that you should set blindly. Unless you already have very clear ideas of filesystem/LUN layout, processing capabilities, bandwidth, etc., on a client, in my opinion you must start with a parallelism of 1 and work your way up as a result of clear and considered performance testing.
Given the amount of effort that’s been put into the latest NetWorker releases for VMware integration – i.e., the Virtual Client Connection license, etc. – it seems a less than logical choice to increase parallelism settings rather than decrease them (as a default) when you know that over time the number of virtualised hosts being backed up are going to increase.
This is obviously just a small inconvenience, but if you’ve not picked up on this yet, you should be aware of it when you start working with these newer versions of NetWorker.
What the real solution is
For what it’s worth, I actually don’t think the solution is to change the default client parallelism setting to 1, but to start maintaining a “defaults” component within the NetWorker server resource where local administrators can configure default settings for a plethora of new resources to be created (most typically clients, groups and pools).
For example, you might have options where you can specify the following defaults for any new client:
- Parallelism
- Priority*
- Group
- Schedule
- Browse Policy
- Retention Policy
- Remote Access
- etc.
These all have their own defaults, but it’s time to move past the point where NetWorker suggests standard defaults, and have all these default settings modifiable by the administrator. I realise that when the server bootstraps itself, it still needs to fall back on standard defaults, and that’s fine. However, once the server is up and running, being able to modify these defaults would be a Time Saving Feature.
This would reduce the amount of work administrators have to do when creating new resources – let’s face it, most of us spend most of the time in new resource creation changing the “default” settings. It also eliminates the amount of human errors introduced when adding to the configuration in a hurry. This sort of “defaults” component would preferably be run as a wizard in NMC on first install, and administrators would be asked if they want to re-run it upon updates.
—
* Adding priority to this might suggest a need to have the priority field work better than it has of late…
Hi,
I agree that 4 was a bad number and 12 even worse (except for the backup server which now needs it…)
But having been a firm advocate of setting client parallellism to 1 for many years and increase it where appropriate, I have now changed that to 2.
Why 2 one might ask? Simply because with the setting of 1 – one saveset hanging or taking longer than usual may cause the rest of the savesets to fail unnecessarily. Setting client //-ism to 2 will let the client send the rest of the savesets to the backup server. And this usually do not impact the client backup performance much.
It’s probably important to note that I advocate a default setting of 1 only as that – the default setting. That way, it forces administrators to think about what setting they really need. When I’m configuring NetWorker I’ll evaluate what the needs are and discuss with the customer to ensure that each client gets a suitable parallelism setting. E.g., on mid-sized hosts with good disk layouts, this has often meant using settings of 4, and on larger hosts I’ve even used much higher parallelism settings, such as 16 and even 30.