{"id":419,"date":"2009-05-13T07:48:58","date_gmt":"2009-05-12T21:48:58","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=419"},"modified":"2009-05-13T07:48:58","modified_gmt":"2009-05-12T21:48:58","slug":"basics-adding-new-clients-in-7-4-4-and-higher","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/05\/13\/basics-adding-new-clients-in-7-4-4-and-higher\/","title":{"rendered":"Basics – Adding new clients in 7.4.4 and higher"},"content":{"rendered":"

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.<\/p>\n

I have to say, and I’ll be blunt here, I find the policy change reasonably inappropriate.<\/p>\n

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<\/em> setting, being too high, in a modern environment; you can imagine then what I thought when I found the new default<\/em> setting was 12.<\/p>\n

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<\/a> I devote to discussing how to plan client parallelism settings. In short, client parallelism settings are typically not<\/em> 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<\/em> start with a parallelism of 1 and work your way up as a result of clear and considered performance testing.<\/p>\n

Given the amount of effort that’s been put into the latest NetWorker releases for VMware integration \u2013 i.e., the Virtual Client Connection license, etc. \u2013 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.<\/p>\n

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.<\/p>\n

What the real solution is<\/h3>\n

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).<\/p>\n

For example, you might have options where you can specify the following defaults for any new client:<\/p>\n

    \n
  • Parallelism<\/li>\n
  • Priority*<\/li>\n
  • Group<\/li>\n
  • Schedule<\/li>\n
  • Browse Policy<\/li>\n
  • Retention Policy<\/li>\n
  • Remote Access<\/li>\n
  • etc.<\/li>\n<\/ul>\n

    These all have their own<\/em> 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<\/em> 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<\/strong>.<\/p>\n

    This would reduce the amount of work administrators have to do when creating new resources \u2013 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.<\/p>\n

    —
    \n* Adding priority to this might suggest a need to have the priority<\/em> field work better than it has of late…<\/p>\n","protected":false},"excerpt":{"rendered":"

    One of the policy changes made in NetWorker 7.4.4 (and which applies to 7.5.x as well) is that of client…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[4,6,13,16,17],"tags":[223,1057],"class_list":["post-419","post","type-post","status-publish","format-standard","hentry","category-aside","category-basics","category-general-thoughts","category-networker","category-policies","tag-client-parallelism","tag-usability"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t