If you’ve come from a tape library environment, you’re well aware the only way to share a tape library between multiple NetWorker datazones – i.e., multiple NetWorker servers – is to use library partitioning. Thus, a 1000 slot library might be presented as 1 x 800 slot library and 1 x 200 slot library to the independent servers.
But what happens when you’re using Data Domain? That’s considerably more flexible.
If we look at basic Virtual Tape Libraries (VTLs), the answer is obvious: create as many VTLs as you need and present each one to a different NetWorker server. VTLs though, like their physical counterparts, suffer limitations that can make them impractical to use. You remain hampered by the number of drives provisioned in the library, and (far more importantly with VTL), you still can’t simultaneously write to a virtual tape and read from it. Looking down to specific technologies, VTLs are also severely limited in a NetWorker environment now when you compare them against Boost functionality. You can’t for instance use a Data Domain VTL for instant access or for granular Exchange recoveries. (Check out this post for more details of VTL vs Boost.)
You don’t have to use VTL to share a Data Domain between two or more NetWorker servers. Once you’ve configured Boost on a Data Domain, you can simply add the Data Domain to each NetWorker server you want to use it with, and a new Mtree will be automatically created for each NetWorker server as you create the first device on each.
For instance, this Data Domain system has 3 NetWorker servers communicating with and using it:
sysadmin@squeezebox# ddboost storage-unit show Name Pre-Comp (GiB) Status ------- -------------- ------ centaur 74.5 RW cyclops 181.8 RW medusa 6.6 RW ------- -------------- ------ D : Deleted Q : Quota Defined RO : Read Only RW : Read Write
One obvious advantage of using the same Data Domain system for multiple NetWorker servers is the deduplication still happens globally across all Mtrees. Thus, if you’ve got a production NetWorker environment and a test NetWorker environment, you can share a Data Domain between them and achieve a high deduplication rate, assuming your test environment is populated with copies of systems from your production environment.
(With the new multi-tenancy support in DDOS 5.5 and higher, you’ve got the additional advantage of using potentially multiple Boost accounts, thereby segregating access between the NetWorker servers. While a NetWorker server won’t have access to an Mtree for another NetWorker server, a shared Boost user will. Independent Boost users won’t.)
There are of course a couple of caveats to this approach. Including the need to either use multi-tenancy on the Data Domain or make sure you trust everyone who is simultaneously using it, you’ll need to consider the following:
- Performance:
- You’ll want to make sure the systems are mutually compatible for performance requirements. Two large-scale production NetWorker environments might for instance have a greater risk of causing performance challenges than say, one large scale production environment and small to medium size lab environment.
- Stream count:
- Almost a subset of performance, but it warrants calling out independently – regardless of whether you’ve got one NetWorker server or fifty NetWorker servers using a Data Domain system, you still have to face the recommended hard high limits on stream counts from the Data Domain administration guides for any unit you’re using. With that in mind, you’ll likely want to use NetWorker’s pool based parallelism settings to ensure there are hard limits established to the number of simultaneous savesets NetWorker can write.
Sharing a Data Domain between multiple NetWorker servers won’t be a solution for every environment, but if you’re limited for budget it’s something to keep in mind.