NetWorker 9.0 SP1

NetWorker 9.0 SP1 (aka “9.0.1”) was released at the end of June. I meant to blog about it pretty much as soon as it came out, but the Australian Federal election distracted me last weekend, and then on the Monday night I came down with yet another cold* which has left me floored most of the week. (In fact, I’ll be recovering for the rest of the weekend.)

But, the show must go on, as they say, and with the dawning of Friday the aches and pains, coughing and sneezing had subsided enough that I could sit at my desk for a while and upgrade my home lab to NetWorker 9.0.1. (Some people make chicken soup while they’re sick, I upgrade NetWorker servers. There you go.)

So it’s time to talk a little bit about the latest member of the NetWorker family.

Upgrade

First thing I have to call out is that the excellent enhancements done to nsrwatch in NetWorker 8.2 SP3 have been rolled forward into NetWorker 9.0 SP1 – though it looks like it didn’t get a mention in the release notes. So, in all its glory:

nsrwatch NSR9

I love this version of nsrwatch. There’s so much more functionality to it. If you’re a command line junkie like me you’ll love it too; and if you’re not, you should give it a go from time to time to give your mouse a break.

But NetWorker 9.0 SP1 is not just about nsrwatch so I’ll continue. I’ll be following the flow of the release notes (which you can access here for any further clarification), which will hopefully serve as a good reminder of what I need to cover given my slightly illness-addled thoughts.

Data Domain Enhancements

9.0 SP1 includes support for various DDOS 5.7 features including Boost over Fibre Channel for Solaris 10 and 11, as well as the DDOS 5.7 high availability mode. The Boost over FC for Solaris 10 and 11 is a welcome feature for organisations with spare fibre-channel networking, but there’s another performance enhancement that’ll be a boon for organisations with 10Gbit networking in particular, and that’s AMS.

AMS, or Automated Multi-Streaming allows NetWorker/Data Domain to automatically segment larger savesets (>3.5GB) to be copied between two Data Domains via Clone Controlled Replication (CCR) into ~2GB chunks, speeding up the processing. Consider for instance a ‘typical’ clone operation for a 10GB saveset:

Cloning Conventional

Now that cloning is still going to be efficient – only the unique segments will be sent between the two Data Domains, but the entire file has to be processed sequentially to work out what does or does not need to be sent. This data walk will take time, but is effectively single-streamed for the individual saveset. Yet we know Data Domain systems can handle potentially large numbers of simultaneous streams – so why not boost our stream utilisation and automatically speed up the processing of that replication?

AMS Enhanced Cloning

With automated multi-streaming enabled, that 10GB saveset will be split into up to 5 chunks (I’ve kept it simple, remember that’s an approximate size split), with each chunk concurrently processed for deduplicated replication, with the replicated components stitched together on the destination Data Domain.

(According to the NetWorker/Data Domain integration guide this feature does require 10Gbit connectivity.)

Keep in mind the AMS feature is not automatically enabled; currently it has to be turned on using an nsrcloneconfig file created in the nsr/debug directory on the NetWorker server. The details for this are covered in the NetWorker/Data Domain integration guide, updated for 9.0.1, but the example file given in the guide looks as follows:

racdd098:/nsr/debug # cat nsrcloneconfig
max_total_dd_streams=256
ams_enabled=yes
ams_slice_size_factor=31
ams_preferred_slice_count=0
ams_min_concurrent_slice_count=1
ams_max_concurrent_slice_count=20
max_threads_per_client=256
ams_force_multithreaded=yes

NDMP

Network Data Management Protocol, if you’re not familiar with it, is used to backup NAS appliances where a traditional agent can’t be installed. NetWorker 9.0 SP1 adds support for Isilon multi-streaming, speeding up backups from industry-leading scale-out NAS storage. Verbose logging has been added for file recoveries, and there’s been support added for token based backups on Hitachi NAS systems. (Token based backups or TBB is where file selection can be done based on previously established backup tokens – effectively allowing for faster incremental backups, if the array supports it. NetWorker already supports TBB on a variety of other platforms.)

Storage Array Snapshot Management

NetWorker Snapshot Management (NSM) has been expanded to also support ProtectPoint for VMAX3, ProtectPoint for RecoverPoint and XtremIO, enhancing again NetWorker’s ability to fold array snapshot and high speed database protection snapshots into data protection policies.

CloudBoost Enhancements

NetWorker with CloudBoost now supports backup as well as cloning, with a current emphasis on in-Amazon backup functionality. CloudBoost v2.1 appliances can also work with Linux clients for ClientDirect, distributing the backup process more smoothly in those scenarios.

This functionality will be particularly useful for those environments where part of the infrastructure workload is already sitting in Amazon’s cloud services. A NetWorker server can now be deployed alongside the infrastructure, with a CloudBoost appliance stood up as well, and clients can backup via CloudBoost into Amazon S3 storage, thus achieving the sort of data protection enterprises need without having to consume expensive Amazon block storage.

REST API

Remember that post I made a few months ago about automation? At the time I wrote the post, someone contacted me privately and suggested to me that NetWorker automation is a bit of a red-herring without REST API support. Well, having spent the last 20 years automating NetWorker I’d happily argue that’s an incorrect assumption in the first place, but part of the reason I wrote that post was because I knew the NetWorker REST API was on the way.

With NetWorker 9.0 SP1, businesses can now work on bundling NetWorker services into their DevOps service portals written in and relying on REST APIs.

With the API comes both an API getting started guide and an API command reference, too. So if you’re keen to get NetWorker included into your service portals, there’s plenty of documentation available to assist. The guides include details not only on what you can do, but how to connect to and authenticate with the NetWorker server. A very basic example I’ve grabbed from the getting started guide is as follows:

REST API Example

The REST API getting started guide is replete with these sorts of examples, by the way. It gives the conventional way of scripting a particular action or function, then provides the means of invoking the same action/function via the REST API.

Other Enhancements

VMware vVol support has been added for VMAX3 and Unity arrays as well.

Finally, the jobs database has been updated – be sure to check the release notes and understand the implications prior to upgrading.

Wrapping Up/The Update

As I said at the start of this article, I upgraded by lab server this morning from NetWorker 9 (actually, 9.0.0.7) to NetWorker 9.0.1 before I started blogging.

Since I deployed VBA into my environment, that also included running the EBR Upgrade for VBA as well, and if you’re using VBA for VMware backups in your environment as an increasing number of NetWorker environments are, then you should make sure you plan to upgrade your VBA systems and redeploy any external proxies as part of the upgrade process.

The upgrade process was relatively smooth – as you can imagine the longest part of the upgrade process was actually the VBA upgrade package processing, so you will want to make sure you allocate enough time for your upgrade to ensure the VBA systems are upgraded and new external proxies deployed prior to your next backup windows starting.

This marks the first significant NetWorker 9.x update since 9.0 was released last year, but sets us on the path for some fantastic coming features. If you’ve been holding off on NetWorker 9 until SP1 came out, now’s the time to upgrade. Otherwise, be sure to review the release notes, test in your labs if necessary, and start your upgrade engines. (If you need a refresher on the rest of NetWorker 9, check out my original post on it here.)

____
* That’s four this season. I’m not amused at all at the moment.

7 thoughts on “NetWorker 9.0 SP1”

  1. Hi Preston,

    thanks for your blog. However, at the moment I would be very carefully to upgrade – it did neither work from 8.2.3.3 nor from 9.0.0.7 on a tiny test server with 2 additional clients and less than 10 save sets.

    EMC support told me not to upgrade as ‘… we have found some issues with that version.’ So be careful.

    Regards, Carsten

    1. Hi Carsten,

      I certainly didn’t have any problems with my upgrade from 9.0.0.7 to 9.0.1.0 – you do however bring me to a good point though – it’s always worthwhile logging a support case prior to upgrading in case there’s any last minute information, or simply to have a pre-emptively opened case if there is an issue.

      Cheers,
      Preston.

  2. Hi Rick,

    you are very euphoric about the REST-API have you even tried the examples of the manuals?
    If, how have you managed to generate the authorisation phrase? It isn’t mentioned anywhere!

    I tried a base64 coding like it is mentioned in Avamar, but the only result I get is:

    “Invalid user or password”

    Regards Uwe

  3. Carsten,

    My name is Michael Arnold and I’m one of the Product Managers for NetWorker. I have been involved in this escalation since hearing about your post late last week. I have discussed this escalation with support management and heard they will be working with you on this over WebEx tomorrow to troubleshoot this further.

    EMC stands by and supports upgrades to NetWorker 9.0.1 and aware of many successful implementations. However, we have been able to reproduce your noted issue on only Windows 2008 systems thus far. We are working to address this as quickly as possible and I will continue to update the community. Thanks for your continued support!

    -Michael

  4. protectpoint for vmax3 was already supported in nw9.0.0 according to the release notes of nw9.0.0. “but now also supported for xtremIO and recoverpoint” would have been a better statement I guess.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.