The utility mmpool is one of those lesser used utilities in NetWorker that you may not necessarily know about, nor would you necessarily always need to use it, but it’s handy to know about it.

Similar to the more well known mmlocate utility, mmpool is designed to list pools on a NetWorker server, and for any pool, list the volumes in that pool. It also has some more “dangerous” options in that it can delete all volumes in a pool, but thankfully it will prompt you about each volume, so you can’t just go blindly destroying media database entries.

The two options I find most useful with mmpool are:

  • -L – List all pools
  • -l pool – List all volumes in the nominated pool.

For example:

# mmpool -L
Staging
Staged Clone
PC Archive Clone
Indexed Archive
Indexed Archive Clone
Default
Full
NonFull
Offsite
Default Clone
Archive Clone
PC Archive
Archive
To review all the volumes in the pool ‘Staged Clone’, you would run:
# mmpool -l "Staged Clone"
volume     pool
Clone.001  Staged Clone
Clone.002  Staged Clone
Clone.003  Staged Clone
Clone.004  Staged Clone
Clone.005  Staged Clone

Again, mmpool is not a utility you’ll find yourself running every day, but it is useful to have available.

 

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…

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha