Considerations for Networker deduplication are similar to other dedupe considerations for EMC products. It's best to have clients with less than 20% daily change rate, and longer retention periods find better commonality. The type of data comes into play again, and more frequent backup make more efficient deduplication as well.
The two options for dedupe with NetWorker are to integrate with Avamar or to Data Domain.
When integrating with Avamar, changing the dedupe node requires a new initial backup, and if dedupe node is not available, a dedupe backup will fail. Networker allows multiple backup from a single client using the client parallelism attribute. Each backup stream would use its own cache files.
Non-Avamar storage device is required to store metadata on Networker storage node. It's essential to data recovery - need data and hash. Best practice is to clone metadata for additional protection from loss, and should be dedicated to dedupe clients.
Networker module backup can be sent to deduplication nodes.
Integrating with Data Domain, DD Boost is used to dedupe on storage node and will significantly reduce data sent to the system. The DD Boost consists of the DD Boost API which allows Networker to talk to the Data Domain system, and the Distributed Segment Processing that enables dedupe at the storage node.
With Networker 8.0, each device is read/write, while pre-8.0 each device has a read/write and a read only instance. There is no recommended limit to the number of devices. Max concurrent sessions for each DD is 60 with Networker 7.6 SP2 and 10 with Networker 7.6 SP1. Each device is a sub-folder of a DD storage unit folder.
Client Direct dedupe allows client-side deduplication to store directly to the DD device and bypass the Networker storage node, reducing bandwidth. Data can also be restored from that device directly, and will revert to a traditional storage node if client can't access the storage device. Client direct supports specific application modules and is supported for filesystem with Networker 8.0+.
DD can be monitored through the Networker Management Console. DD Device is created using a wizard in the NMC. Data Domain retention lock is not supported with Networker.
Sizing is a little different than normal. DDBoost clients should have at least 4 GB RAM, as each DD Boost uses 24 MB of RAM initially, and each save session requires additional 24 MB. A storage node should have at least 8GB RAM when hosting Networker Data Domain devices.
When backup on a DD expires, the references are removed but data not removed until cleanup takes place, which is once a week. It can be done manually, but not recommended. If space fills during a Networker backup, the backup fails immediately. It does not pause or wait for space to be made available.
By default, the wizard creates 1 SU (Storage Unit) per Networker datazone. This is an MTree. Each DD Boost device should be associated with only one Networker storage node.
Optimum save stream performance is achieved when there are at least eight concurrent save streams because the number of active devices is reduced.
No comments:
Post a Comment