{"id":5928,"date":"2016-07-08T12:29:08","date_gmt":"2016-07-08T02:29:08","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5928"},"modified":"2016-07-08T12:29:10","modified_gmt":"2016-07-08T02:29:10","slug":"networker-9-0-sp1","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2016\/07\/08\/networker-9-0-sp1\/","title":{"rendered":"NetWorker 9.0 SP1"},"content":{"rendered":"

NetWorker 9.0 SP1 (aka “9.0.1”) was released at the end of\u00a0June.\u00a0I meant to\u00a0blog about it pretty much as soon as it came out, but the Australian Federal election distracted me last weekend, and then\u00a0on the Monday night\u00a0I 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\u00a0the weekend.)<\/p>\n

But, the show must go on, as they say, and\u00a0with 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\u00a0sick, I upgrade NetWorker servers. There you go.)<\/p>\n

So it’s time to talk a little bit about the latest member of the NetWorker family.<\/p>\n

\"Upgrade\"<\/a><\/p>\n

First thing I have to call out is that the excellent enhancements done to\u00a0nsrwatch<\/em> in NetWorker 8.2 SP3 have been rolled forward into NetWorker 9.0 SP1 \u2013\u00a0though it\u00a0looks like it didn’t get a mention in the release notes. So, in all its glory:<\/p>\n

\"nsrwatch<\/a><\/p>\n

I love this version of nsrwatch<\/em>.\u00a0There’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,\u00a0you should give it a go from time to time to give your mouse a break.<\/p>\n

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

Data Domain Enhancements<\/h3>\n

9.0 SP1\u00a0includes\u00a0support for\u00a0various DDOS 5.7 features\u00a0including Boost over\u00a0Fibre Channel for Solaris 10 and 11, as well as\u00a0the 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\u00a0enhancement that’ll be a boon for\u00a0organisations with 10Gbit networking in particular, and that’s AMS<\/em>.<\/p>\n

AMS<\/strong>, or A<\/strong>utomated M<\/strong>ulti-S<\/strong>treaming allows\u00a0NetWorker\/Data Domain to automatically segment larger savesets (>3.5GB) to be\u00a0copied between two Data Domains via Clone Controlled Replication (CCR) into ~2GB chunks, speeding up the processing.\u00a0Consider for\u00a0instance a ‘typical’ clone operation for a 10GB saveset:<\/p>\n

\"Cloning<\/a><\/p>\n

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

\"AMS<\/a><\/p>\n

With\u00a0automated multi-streaming enabled, that 10GB saveset will be split into up to 5 chunks (I’ve kept it\u00a0simple, remember that’s an approximate size split), with each chunk concurrently processed for\u00a0deduplicated replication, with the\u00a0replicated components\u00a0stitched together on the destination Data Domain.<\/p>\n

(According to the NetWorker\/Data Domain integration guide this feature does require 10Gbit connectivity.)<\/p>\n

Keep in mind the AMS feature is not automatically enabled; currently it has to be turned on using an\u00a0nsrcloneconfig<\/em> file created in\u00a0the\u00a0nsr\/debug<\/em> directory on the NetWorker server.\u00a0The details for this are covered in the NetWorker\/Data Domain integration guide, updated for 9.0.1, but the example file\u00a0given in the guide looks as follows:<\/p>\n

racdd098:\/nsr\/debug # cat nsrcloneconfig<\/strong>\r\nmax_total_dd_streams=256\r\nams_enabled=yes\r\nams_slice_size_factor=31\r\nams_preferred_slice_count=0\r\nams_min_concurrent_slice_count=1\r\nams_max_concurrent_slice_count=20\r\nmax_threads_per_client=256\r\nams_force_multithreaded=yes<\/pre>\n
NDMP<\/h3>\n
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.\u00a0NetWorker 9.0 SP1 adds support for Isilon multi-streaming, speeding up backups\u00a0from industry-leading\u00a0scale-out NAS storage.\u00a0Verbose logging has been added for file\u00a0recoveries, and\u00a0there’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.)<\/p>\n
Storage Array Snapshot Management<\/h3>\n
NetWorker Snapshot Management (NSM) has been expanded to also support ProtectPoint for VMAX3, ProtectPoint for RecoverPoint\u00a0and XtremIO, enhancing again NetWorker’s ability to fold array snapshot and high speed database protection snapshots into data protection policies.<\/p>\n
CloudBoost Enhancements<\/h3>\n
NetWorker with\u00a0CloudBoost now supports backup as well as cloning, with a\u00a0current emphasis on\u00a0in-Amazon backup functionality. CloudBoost v2.1 appliances can also\u00a0work with Linux clients for\u00a0ClientDirect, distributing the backup process more smoothly in those scenarios.<\/p>\n
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\u00a0alongside the\u00a0infrastructure, with a CloudBoost\u00a0appliance stood up as well, and clients can backup via\u00a0CloudBoost into Amazon S3 storage, thus achieving the sort of data protection enterprises need without having to consume expensive Amazon block storage.<\/p>\n
REST API<\/h3>\n
Remember that post I made a few months ago about\u00a0automation<\/a>? At the time I wrote the post, someone contacted me privately and\u00a0suggested 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\u00a0because I knew\u00a0the NetWorker REST API was on the way.<\/p>\n
With NetWorker 9.0 SP1,\u00a0businesses can now work on bundling NetWorker services into their DevOps service portals written in and relying on REST APIs.<\/p>\n
With the API comes both an API getting started\u00a0guide<\/a> and an API command reference<\/a>, too. So if you’re keen to get NetWorker included into your service portals, there’s plenty of\u00a0documentation available to assist. The guides include details not only on what you can do, but how to\u00a0connect to and authenticate with the\u00a0NetWorker server. A very basic example I’ve grabbed from the getting started guide is as follows:<\/p>\n
\"REST<\/a><\/p>\n
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\u00a0means of invoking the same action\/function via the REST API.<\/p>\n
Other Enhancements<\/h3>\n
VMware vVol support has been added for VMAX3 and Unity\u00a0arrays as well.<\/p>\n
Finally, the jobs database has been updated \u2013 be sure to\u00a0check the release notes and understand the implications prior to upgrading.<\/p>\n
Wrapping Up\/The Update<\/h2>\n
As I said\u00a0at the start\u00a0of this article, I upgraded by\u00a0lab server this morning from NetWorker 9 (actually, 9.0.0.7) to NetWorker 9.0.1 before I started blogging.<\/p>\n
Since I deployed VBA into my environment, that also included running\u00a0the EBR Upgrade for VBA as well, and if you’re\u00a0using VBA for VMware backups in your environment as an increasing number of\u00a0NetWorker environments are, then you should make sure you\u00a0plan to\u00a0upgrade your VBA systems and redeploy any external proxies as part of the upgrade process.<\/p>\n
The upgrade process was relatively smooth \u2013 as you can imagine the longest part of the upgrade process was actually the VBA\u00a0upgrade package processing, so you will want to\u00a0make sure you allocate enough\u00a0time for your upgrade to\u00a0ensure the VBA systems are upgraded and\u00a0new\u00a0external proxies deployed prior to your next backup windows starting.<\/p>\n
This marks the first\u00a0significant NetWorker 9.x update since 9.0 was released last year, but sets us on the path for some fantastic coming features.\u00a0If 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\u00a0NetWorker 9, check out my original post on it here<\/a>.)<\/p>\n
____
\n* That’s four this season. I’m not amused at all at the moment.<\/p>\n","protected":false},"excerpt":{"rendered":"
NetWorker 9.0 SP1 (aka “9.0.1”) was released at the end of\u00a0June.\u00a0I meant to\u00a0blog about it pretty much as soon as…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[16],"tags":[1316,1315,879,1207,1053],"class_list":["post-5928","post","type-post","status-publish","format-standard","hentry","category-networker","tag-9-0-sp1","tag-9-0-1","tag-service-pack","tag-sp1","tag-upgrade"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1xC","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/5928","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=5928"}],"version-history":[{"count":6,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/5928\/revisions"}],"predecessor-version":[{"id":5939,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/5928\/revisions\/5939"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=5928"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=5928"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=5928"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}