First thoughts – NetWorker 7.5 SP3 AFTD Enhancements

 NetWorker  No Responses »
Aug 232010
 

On the weekend it came out, being your typical backup geek, I downloaded NetWorker 7.5 SP3, installed a new virtual machine, and started kicking the tyres on the new release. My primary focus was on the AFTD changes. These, as you may recall, compromise some core changes that EMC had previously touted for 7.6 SP1.

I’m quite glad these were pushed down into 7.5 SP3.

The change that was introduced was to give NetWorker a new volume selection algorithm for AFTD devices. Up until 7.5 SP3, NetWorker’s volume selection criteria for AFTD has been:

  • If a new backup starts and a device is currently writing (or “writing, idle”):
    • If that device’s target sessions have not been met, write to that device.
    • If that device’s target sessions has been met, move onto the device that has mounted the least recently labelled volume and start writing there.
  • If a new backup starts and no device is currently writing:
    • Pick the device whose volume was least recently labelled, and start writing to that.

The net result of this of course is what I like to call the AFTD-data-shuffle. Administrators invariably found that certain disk backup devices within their environment would fill sooner than others, and as a result of this, they’d either continually have to stage from those frequently hit AFTDs to other AFTDs, or stage that data out to tape.

Like the changes announced for 7.6 SP1, 7.5 SP3 now applies a more intelligent volume selection criteria, instead picking the volume that has the least data written to it.

This is, of course, a VGT enhancement – or without the TLA, it’s a Very Good Thing.

There was one minor catch, which prevented me from doing this blog piece. As a result of this change, there was an unanticipated reversal in the volume selection criteria for physical tape – i.e., when there’s no tape with data that is still appendable, NetWorker will pick the most recently labelled tape to write to, rather than the least recently labelled tape to write to.

The good news though is that this is fixed in NetWorker 7.5 SP3 cumulative release 1 (7.5.3.1), which was released last week. So, if you’re after an enhanced volume selection algorithm for AFTD that doesn’t impact physical volume selection, you’ll want to check out 7.5.3.1.

 Posted by at 17:57  Tagged with: , , , , , , ,

appliances vs Appliances

 Architecture, Backup theory, Support  No Responses »
Aug 182010
 

We all have appliances, right? Teapots and toasters and microwaves and automatic coffee machines, etc. They’re all appliances. So are clock radios, electric razors, heaters and fans.

They’re appliances.

VTLs, SANs and NASs are not appliances, despite what any vendor would try to tell you. As soon as you’ve got an OS + software layer, you’re moving beyond “appliance” into “black box”. Or maybe we’re talking the difference between an appliance and an Appliance. If a vendor wants to tell you otherwise, they’re not telling you the whole story.

There’s a simple test on whether you’re being sold an appliance, or an Appliance – a simple yes/no question:

Is there a training course for the unit or an instruction manual with more than 1 page of instructions per language?

If the answer is “no”, then congratulations, you’ve got an appliance; if the answer is yes, then despite whatever your vendor wants to tell you, you’ve got an Appliance.

Now, there’s nothing wrong with having an Appliance within your organisation, and in fact I’d suggest that frequently they add a lot of value. VTLs, SANs and NASs, to use the example I previously provided, are all capable of greatly extending the storage and data protection options within your environment and should of course be considered in many architectures.

Knowing that they’re Appliances rather than appliances though means that you can treat them appropriately. I personally don’t care about backing up my toaster, or keeping a close eye on the logs from my microwave. As the appliance complexity increases, I pay more attention – so for instance the most critical appliance in my home is arguably the automatic espresso machine, and since it has blinking lights that can tell me whether I’m able to get a cup of coffee from it or not, I pay attention to it.

Extending this process, when you move from having appliances in your organisation to having Appliances, it’s critical that they are treated as full blown systems that require the same level of support, administration and consideration when it comes to problem resolution. Or another way to consider it, from a support perspective – if there’s an error happening in your environment, don’t ignore the “black boxes” when it comes to problem diagnosis. This means being aware of at least the following:

  • How to view basic status;
  • How to extract logs;
  • Any caveats to reading logs (e.g., are they time/date stamped using a different GMT offset to your environment?);
  • How to review the logs;
  • How to escalate requests to the Appliance vendor.

Once you’ve been working with Appliances for a while, all of these start to come naturally. The big trick for beginners in the Appliance realm though is to ignore the “black box” you’ve been sold and instead be aware of the components and how to access the diagnostic information for the unit. If you can’t, you’ve created a “black hole” – and that’s not something you’ll get a lot of satisfaction from.

 Posted by at 07:47  Tagged with: , , , , ,

NetWorker and CentOS

 Linux, NetWorker  7 Responses »
Aug 062010
 

A common question I get asked by Linux customers is “Can I run my NetWorker server on CentOS?”

Up until a short while ago, I always had to give an answer that differentiated between can and supported. Thankfully a while ago, EMC started supporting NetWorker clients running on CentOS, but servers and storage nodes were a bit of a hold out.

This morning I did a bit of a happy-geek dance (not really, but that description certainly fits my mood) when I read the latest software compatibility guide and saw:

NetWorker support for CentOS

For people who need to run Linux, but dislike the licensing costs of the commercial distributions (or like me, question the quality of support you get from such distributions), this will be a big help.

I’d like to think this is part of a growing trend amongst enterprise vendors – CentOS is in every way an enterprise distribution (and especially appreciated by many administrators thanks to the Yum package management system).

 Posted by at 16:24  Tagged with: , ,

Basics – Specifying a default Jukebox

 Basics, NetWorker, Scripting  No Responses »
Aug 052010
 

If you’ve got multiple jukeboxes within a NetWorker environment, but primarily work with one of them, you may find ‘nsrjb’ to be a bit of a pain any time you forget to specify the jukebox name. If you’re not familiar with this, here’s how nsrjb reacts in this situation:

[root@tara ~]# nsrjb
1:	VTL1 	[enabled]
2:	VTL2 	[enabled]
No jukebox selected.
Please select a jukebox to use:? [1] _

(Slight aside: never assume the numbered list is the same; NetWorker doesn’t guarantee the order being the same between executions – in fact, I actually only put in an RFE about this a couple of days ago, as I’m hoping it could at least be alphabetically ordered at all times…)

If you want to avoid the jukebox-prompt from nsrjb, one of the easiest ways is to specify the jukebox name as part of the command – e.g.,

[root@tara ~]# nsrjb -j VTL1

That’s fine of course, but if the vast majority of the time you perform operations on a single jukebox, you can specify a default jukebox as an environment variable (NSR_JUKEBOX) and streamline your processes. For example, on Linux, using the bash, this might look as follows:

[root@tara ~]# export NSR_JUKEBOX=VTL1
[root@tara ~]# nsrjb
Jukebox VTL1: (Ready to accept commands)
slot  volume         pool           barcode   volume id        recyclable
1: 800840L4       ClientTesting  800840L4  3814088325       no
2: 800841L4       ClientTesting  800841L4  3797311146       no
3: 800842L4       ClientTesting  800842L4  3847642669       no
4: 800843L4       ClientTesting  800843L4  3780533937       no
5: 800844L4       ClientTesting  800844L4  3763756765       yes
6: 800845L4       ClientTesting  800845L4  3864419885       yes
<snip>

Being an environment variable, this is something you can choose to set locally – say, on a per storage-node basis, when you have multiple storage nodes. It’s relatively common for instance to have a tape library on one or more storage nodes, so for the appropriate logins (or even at a system level) on each storage node it would be possible to set the local jukebox as the default, thereby streamlining usage of the units.

As an example, here’s a lab storage node with the setting in use:

[root@fawn ~]# export NSR_JUKEBOX="rd=fawn:VTL3"
[root@fawn ~]# nsrjb -s tara
Jukebox rd=fawn:VTL3: (Ready to accept commands)
<snip>

For something that can take you less than 30 seconds to set, the environment variable NSR_JUKEBOX can certainly be a big time saver if you have multiple jukeboxes in your environment and (like me) you’re a command line junkie.

 Posted by at 05:03  Tagged with: , , ,
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha