Data Protection Hub

All things Data Protection

Posts

Basics – Understanding NetWorker Architecture I'm also over at : Mastodon ([email protected]).

 November 14, 2016  Preston de Guise  Leave a comment

With the NetWorker 9 architecture now almost 12 months old, I thought it was long past time I do a Basics post covering how
Data Protection: Ensuring Data Availability
the overall revised architecture for data protection with NetWorker functions.
(2nd Edition)
The second edition of Data Protection: Ensuring Data
There are two distinct layers of architecture I’ll cover off – Enterprise and Operational. In theory an entire NetWorker
Availability is now available. It’s not just an update to
environment can be collapsed down to a single host – the NetWorker server, backing up to itself – but in practice we will
existing content, there’s significant new information in
typically see multiple hosts in an overall NetWorker environment, and as has been demonstrated by the regular NetWorker
this new edition. Buy here.
Usage Surveys, it’s not uncommon nowadays to see two or more NetWorker servers deployed in a business.

Enterprise Layer
The Enterprise Layer consists of the components that technically sit ‘above’ any individual NetWorker install within your Dell Technologies Webinars
environment, and can be depicted simply with the following diagram:
Did you know Dell Technologies runs regular webinars?
You can watch recordings of completed webinars and
register for upcoming ones at the Dell Technologies
 Webinars Homepage. (There are some great data
protection sessions in these!)

Search…

Search …

Subscribe to updates
Email Address*

First Name

Last Name

The key services that will typically be run within the Enterprise Layer are the NetWorker License Server, and the NetWorker
Management Console Server (NMC Server). While NetWorker has previously had the option of running an independent * = required field
license server, with NetWorker 9 this has been formalised, and the recommendation is now to run a single license server for all
NetWorker environments within your business, unless network or security rules prevent this.
Subscribe

The License server can be used by a single NetWorker server, or if you’ve got multiple NetWorker servers, by each NetWorker
unsubscribe from list
server in your environment, allowing all licenses to be registered against a single host, reducing ‘relicensing’ requirements if
NetWorker server details change, etc. This is a very light-weight server, and it’s quite common to the license services run
powered by MailChimp!
concurrently on the same host as the NMC Server.

Like many applications, NetWorker has separated the GUI management from the core software functionality. This has multiple
architectural advantages, such as:
 The GUI and the Server functionality can be developed with more agility Data Prot…
The GUI can be used to administer multiple servers 1.3K followers

The functional load of providing GUI services does not impact the core Server functionality (i.e., providing backup and
recovery services).
Follow Page

While you could, if you wanted to, deploy a NMC Server for each NetWorker Server, it’s by no means necessary, and so it’s
reasonably common to see a single NMC Server deployed across multiple NetWorker servers. This allows centralised
reporting, management and control for backup administrators and operators.
Sprache auswählen

Operational Layer
Powered by Google Übersetzer

At the operational layer we have what is defined as a NetWorker datazone. In fact, at the operational layer we can have as many
datazones as is required by the business, all subordinate to the unified Enterprise Layer. In simple parlance, a
NetWorker datazone is the collection of all hosts within your environment for which a single NetWorker server provides backup
and recovery services. A high level view of a NetWorker datazone resembles the following:

Archives
Select Month

Tags

7.6 ADV_FILE Architecture archive avamar Backup Basics

The three key types of hosts within a NetWorker datazone are as follows: data domain data protection deduplication
Disaster Recovery disk backup documentation DPA EMC Index Linux
Server – A host that provides backup and recovery services (with all the associated management functions) for
systems within your environment. There will either be (usually) a single NetWorker server in the datazone, or (in less Mac OS X mminfo NAS NetWorker NMC nsradmin
common situations), a clustered pair of hosts acting as an active/passive NetWorker server.
nsrmmd Oracle performance PPDM Recovery Security
 Client – Any system that has backup and recovery services managed by a NetWorker Server survey tape update upgrade Virtualisation VMware VTL
Storage Node – A host with access to one or more backup devices, either providing device mapping access to clients zero error policy
(I’ll get to that in a moment) or transferring backup/recovery to/from devices on behalf of clients. (A NetWorker
server, by the way, can also function as a storage node.) A storage node can either be a full storage node, meaning it
can perform those actions previously described for any number of clients, or a dedicated storage node, meaning it
provides those services just to itself.

With such a long pedigree, NetWorker (as described above) is capable of running in a classic three-tier architecture – the server
managing the overall environment with clients backing up to and recovering from storage nodes. However, NetWorker is equally
able to ditch that legacy mode of operation and function without storage nodes thanks to the benefits of
distributed deduplication in tightly integrated systems such as Data Domain and CloudBoost and ClientDirect. That being said,
NetWorker still supports a broad range of device types ranging from simple tape through to purpose built backup appliances
(Data Domain), Cloud targets, VTL and plain disk. (In fact, I remember years ago NetWorker actually supporting VHS as a tape
format!)

ClientDirect, which I mentioned previously, is where clients can communicate directly with network accessible devices such
as Data Domain deduplication storage. In these cases, both the NetWorker server and any storage node in the environment
is removed from the data path – making for a highly efficient and scalable environment when distributed deduplciation is taking
place. (For a more in-depth understanding of the architectural implications of Client Direct, I suggest you review this earlier
post.)

Within this operational layer, I’ve drawn the devices off to the side for the following reasons:

Devices can (and will) provide backup/recovery media to all layers in the NetWorker datazone – server, storage nodes
(if deployed) and individual clients
Devices that support appropriate multi-tenancy or partitioning can actually be shared between multiple NetWorker
datazones. In years gone by you might have deployed a large tape library with two or more NetWorker servers
accessing virtualised autochangers from it, and more recently it’s quite easy to have the same Data Domain system for
instance being accessed by multiple NetWorker servers if you want to.

Wrapping Up
The NetWorker architecture has definitely grown since I started using it in 1996. Back then each datazone required completely
independent licensing and management, using per-OS-type GUI interfaces or CLI, and it was a very flattened architecture –
clients and the server only. Since then the architecture has grown to accommodate the changing business landscape. My
largest NetWorker datazone in 1996 had approximately 50 clients in it – these days I have customers with well over 2,000
clients in a single datazone, and have colleagues with customers running even larger environments. As the NetWorker Usage