1. EMC Disk Library Two new EDL engines: DL5100 & DL5200
Based on Clariion CX4 array
Up to 10.2 TB per hour
New software revision : 4.0
Similar to 3.3 only new feature is CX4 support
Better CPU, 12GB of RAM, Better compression, 8GB HBA
NetWorker 7.6 &  update mandatory to X, X because of NW114157
4.0 identical to 3.3 but needed for CX4 support
DL5100 : 1 array CX4-240
DL5200 : 2 arrays CX4-960
Cannot upgrade from DL4xxx to DL5xxx due to the new array

2. DataDomain 3 new appliances :
DD670: single quad-core / 3 optional PCI Card
DD860: DD Archiver enables data movement between tiered storage based on time
DD890: TBD
DDOS 5.0 scheduled for Q1 2011
Support up to 96GB of RAM instead of 64GB on DD880/DD890
DD Archiver for externalization
Support for I-series AS400 thru BRMS
LACP & IP-aliasing support
50% of the CLI commands changed compare to 4.x
IPv6 is not supported
the Target sessions value for a device is set to a default value of one.
The Max sessions value is set to a default value of four and cannot be set to a value greater than 10.

3. DataDomain: Replication
CIFS / NFS replication of files will start after 10min of inactivity
VTL replication needs the virtual tape to be unmounted for the replication to starts
Replication can be encrypted if needed
Files due to be replicated will not be affected by GC (cleaning)
If replication is slow, box can fill up
4 types : 128 or 256 / CBC or GCM

4. DataDomain: Best Practices
DDBoost device paralelism:
“Target Session” default is 1
Optimal 4, maximum 10 for performance reasons
Can configure multiple devices per SN.
DDBoost library is used by NetWorker 7.6 SP1
AIX and HP-UX are currently not supported by DD Boost, planned for NW 7.6 SP2
DD VTL device, “target Sessions” and “maximum sessions” needs to be set to 1 to avoid multiplexing which causes poor de-duplication ratios
Hashing is optimized for Intel architectures (performances will be better compared to SPARC)
the Target sessions value for a device is set to a default value of one.
The Max sessions value is set to a default value of four and cannot be set to a value greater than 10.
DD VTL device isn’t set to 1 but 4 as other Vdrive  need to be changed each time !
DDBoost performance will be lower on Solaris because of SPARC architecture
Better to have DD boost on intel based arch and keep Solaris for VTL and NFS shares

5. DataDomain: Best Practices cont.
Amount of sessions / Memory available
Optimized cloning is counted as replication stream
Backup write streams
Backup read streams
Repl Source Streams
Repl Destination Streams
Maximum Concurrent
<=32GB RAM 90 50
<140
>=64GB RAM
180
<180
the Target sessions value for a device is set to a default value of one.
The Max sessions value is set to a default value of four and cannot be set to a value greater than 10.
DD VTL device isn’t set to 1 but 4 as other Vdrive  need to be changed each time !
DDBoost performance will be lower on Solaris because of SPARC architecture
Better to have DD boost on intel based arch and keep Solaris for VTL and NFS shares

6. Storage Node Implementation
Data Domain
save
save
File systems
MMD
(Storage node
Media Daemon) daemon)
Virtual
libddboost
wrapper
dasv
DSA
Proprietary File systems
Via NDMP
Applications
Snapshots, CDP, and CRR

7. Basic Constructs Configuration Savestreams Data Domain Device type
Movement of data
Generates a saveset on the target device
Can represent a System disk, file system, directory (system disk shown),
Data Domain Device type
Logical construct
Each Data Domain Device type uses a unique instance of Boost
Storage unit
Logical construct that Boost uses for target
Max qty of storage units is model dependent
Savestreams
Data Domain
Device Type
Boost
Boost
Storage
Unit
Saveset
Savesets

8. Design considerations
Configuration
/C:
/D:
/C:
/D:
/C:
/D:
/C:
/D:
Design considerations
Multiple Data Domain Devices per storage node
Cannot be shared between multiple storage nodes
Each generates a new Boost footprint
Practical limits
# of devices per storage node
available memory
Multiple Logical Storage units per Data Domain system
Each creates a new folder
Data Domain
Device Type
Boost
Boost
Boost
Storage
Unit

9. Design considerations
Configuration
/C:
/D:
/C:
/D:
/C:
/D:
/C:
/D:
Design considerations
Best practices for savestream multiplexing
Boost is optimized for handling a single stream
Open – read/write – close, move on to next file
Target sessions
‘optimal’ setting for multiplexed savestreams
default = 4, NetWorker will exceed this if workload demands more resources
No benefit in reducing to <4
Max sessions
‘Hard limit’ setting
default is 10, NetWorker will not exceed this
Allocates memory for 10 sessions
Reduce Max sessions to less than 10 to reduce memory allocation
8 savestreams
(sessions) shown
Boost
Storage
Node
w/ Boost

10. Design considerations
Configuration
Design considerations
Best practices for pools
Add devices if savestreams exceed max sessions and if available system resources
Maximize available DD system bandwidth and de- duplication efficiency
Optionally add devices & reduce max sessions
2 devices with MAX SESSIONS = 4 is better than 1 device with MAX SESSIONS = 8
Build pools across multiple systems as a last option
If sessions/bandwidth to the first Data Domain system is maximized
Lose some global de-duplication efficiency
Do not mix Data Domain Device types and any other device type in the same pool
Impacts Clone Controlled Replication operation
Boost
Boost
Storage
Node
w/ Boost

11. Design considerations
Configuration
Design considerations
Best practices for design
Configure a Data Domain Device type to a single storage node
Cannot share a Data Domain Device type between storage nodes
Map multiple storage nodes to a single Data Domain system to maximize system bandwidth
Multiple storage nodes per Data Domain system helps drive available DD bandwidth to saturation
Boost
Boost
Storage
Node A
w/ Boost
Storage
Node B
w/ Boost

12. Design considerations
Configuration
Design considerations
Best practices for design
Configure a Data Domain Storage Unit to a single NetWorker Data Zone
No sharing of storage units across NetWorker Data Zones
Boost
Boost
Data Zone A
w/ Boost
Data Zone B
w/ Boost

13. Design considerations
Configuration
Design considerations
Best practices for design
Do not exceed maximum sessions specification for the Data Domain model
E.g. DD880 = 180 sessions max
10 Data Domain Devices, each with max 10 = 100 potential sessions
5 storage nodes w/
Max sessions
= 50 sessions
Boost
Boost
Boost
Boost
Boost

14. Clone Controlled Replication
Immediate Cloning
Clones begin as soon as the savegroup backup has finished
Pro: Reduces the gap in time between a secure backup and the completed copy
Con: Other savegroups may still be running, creating resource contention
Scheduled cloning
Two approaches with NW 7.6 SP1: NMC and Scripts/scheduler
Objective: Postpone clone process to reduce resource contention with backups
Pro: allows backups to complete as quickly as possible
Con: increases the gap in time between the secure backup and the completed copy

15. Clone Controlled Replication
Comparison of replication types
Directory Replication
Used by existing Data Domain users without backup application control
Replication begins even as the backup is in process
Pro: Reduces the gap in time between a secure backup and the completed copy
Con: The replica is not kept in the backup apps catalog
File replication
Used by customers deploying the NW/DD Boost integration
Replication process is initiated by NetWorker after the backup is completed
Pro: The replica is cataloged by NetWorker
Con: Increases the gap in time between the secure backup and the completed copy T0 T1 T2 T3 T4 T5 T6
Backup
Replication
Backup
Replication T0 T3 T4 T5 T6 T1 T2

16. Clone Controlled Replication
Best Practices
Reduce the gap in time between a secure backup and the completed copy
Use Immediate cloning
Increase granularity of the backup and increase concurrency
Reduce Savegroup size
Use saveset cloning
Reduce saveset size
Savegroup 1
Replication 1 T0 T3 T4 T5 T6 T1 T2
Savegroup 1
Savegroup 2 T0 T1 T2 T3 T4 T5 T6
Replication 2
Replication 1

17. Clone Controlled Replication

18. Clone Controlled Replication
NMC
NW Server
Manages NW
Clone Controlled Replication
One of the most appealing features of the new integrated solution is NetWorker’s ability to manage Data Domain’s replication process. The new feature is called Clone Controlled Replication and the name describes the feature simply: it uses the standard NetWorker cloning to control the replication process. For NetWorker users this means that there are no new tools or processes to learn in order to enhance disaster recovery preparedness. With Clone Controller Replication NetWorker tracks the Data Domain replicas as true copies or clones of the original backup.
The replicas/clones can then be used to support common uses cases like ….
And the entire process or managing data the DR site is scheduled and managed exclusively through NetWorker Management Console. Now with the integrated NetWorker / Data Domain solution, customers are able to optimize the process of creating the remote copy using deduplicated data over a common carrier and use the backup application to manage the process.
Use Clone ID/ or Clone pool
Use remote storage node
Saveset
Remote Site
Data Domain Replication
Storage Node
Clone 1
Clone 2 18

19. Clone Controlled Replication
Remote Clone to tape
Remember to clone from the clone ID/clone pool and not the original saveset (backup)
Remember to use a storage node attached to the tape device(s) at the remote site
Each clone is independently scheduled
First clone is based upon backup
Use immediate or scheduled
Remote clone is created from the first clone
Must be scheduled
Clone of a clone is a separate policy
Data Domain system stream bandwidth is shared
Backups, recoveries, replications
E.g. DD880 – 180 connections max
# backup savestreams + # recoveries + # replications cannot exceed 180

20. Resource Planning
EMC NetWorker with EMC Data Domain Boost Best Practices Planning (in draft)
Storage Node Memory -Boost
Default and minimum memory allocation is 64MB, supporting 4 sessions
Changing target sessions to <4 still allocates 64MB
Each additional session allocates 16MB
Back of napkin calculation for Boost
m = n * (64*s)
m= memory in MB
n= number of Data Domain Devices
s= sessions
Storage Node Memory – Data Domain Device type
Allocates between 200MB and 250MB of memory per device
Includes memory used by the RO device
Design recommendation (not minimums)
8 Data Domain Devices per storage node, no more than 16 max.
4 streams per device, no more than 10 max
8GB RAM

21. Subject to update For reference only Resource Planning
EMC® NetWorker® Data Domain® Deduplication Devices Integration Guide
Page 16: Memory and network considerations
Each read/write device (active nsrmmd process) that takes four save streams requires about 96 MB of RAM on the storage node.
Each read-only device requires about 20 MB, regardless of the number of save streams.
a fully loaded Data Domain system that is running four save streams per device would require about
(96MB x 16 devices) + (20MB x 16 devices) = 2.3 GB, of physical memory on the storage node.
The recommended minimum memory requirement for a storage node is 4 GB of RAM.
preliminary, subject to update in the next revision of document
4GB minimum also reflects purchasing options (increments)
Subject to update
For reference only

22. Resource Planning Storage Node Processor Server
Distributed Segment Processing increases processor utilization on the first backup
Subsequent backups will benefit from
Reduced CPU utilization
Reduced LAN traffic
Server
Encryption (encryptasm) not supported to the Data Domain Device type
Compression (compressasm) not suported with the Data Domain Device type
CheckPoint Restart not supported with the Data Domain Device type
Data Domain retention locks are not supported with this release of NetWorker

23. Distributed Segment Processing
Customer Benefits
Higher aggregate backup throughput
Backup windows shrink considerably
Enables faster DR readiness
Lower CPU usage on the Data Domain system
CPU can be used for other tasks, such as replication, cleaning
Reduced CPU usage on the media server
20-40% lower overhead on the media server
No need to upgrade the media server hardware
Leverage existing 1GbE backup infrastructure
Achieve 10GbE throughput with 1GbE networks
Avoid the need to upgrade media server and network hardware
Failed backups go much faster on retries
Data that is already sent to the Data Domain system need not be sent again
Enables faster backups for retried backups

24. Distributed Segment Processing – Good Fit
Good fit situations
GDA (mandatory)
Network (1 GbE) constrained connectivity to Data Domain system
High stream counts (>8 streams)
DD model dependent; lower –end models see benefits at fewer stream counts

25. Other Considerations Boost license applied to the DD system
Distributed Segment Processing ‘on’
Replicator license applied to the DD system
NetWorker enabler for Data Domain Device type applied
Enables backups to be directed to Boost
Enables Clone Controlled Replication

26. Planning: Support Dependencies
NetWorker 7.6 SP1 Technical Differences
Planning: Support Dependencies
DD Boost License
One per DDR
DD OS
DD OS 4.8 and 4.9
NetWorker Storage Nodes
7.6 SP1 has integrated DD Boost
Windows 2003/2008/2008 R2, Linux (Red Hat 4/5, SuSE 10/11), Solaris 9/10 (SPARC)
NetWorker Server
7.6 SP1
DD Device Type Enabler per raw capacity (except for capacity licensing)
NMC
7.6 SP1 contains DD device management and new device wizard
It is important to use the correct components to attain all of the integration benefits of NetWorker 7.6 SP1 with Data Domain.
The Data Domain Boost license is available for most versions of the Data Domain product as specified in the table. Note: Advanced Load Balancing and Link Failover is not supported for Data Domain Global Deduplication Arrays.
Only DD OS 4.8 and 4.9 are qualified to support DD Boost with NetWorker 7.6 SP1.
The storage node and server must all be using NetWorker 7.6 SP1. The storage node operating systems which have been qualified to support DD Boost include Windows 2003, Windows 2008, Windows 2008 R2, RedHat, and Solaris 9 and 10 on SPARC.
The DD Device Type Enabler, which is new with this release, must be installed on the server, else only generic VTL and NAS usage of the Data Doman system is available. When using NetWorker capacity licensing, this additional enabler is not required.
The running version of the NMC must be 7.6 SP1 to see Data Domain device objects, and to have the New Device wizard available for this device type. A 7.6 SP1 NMC connected to a 7.6 server will not see the DD device objects folder.
Copyright © 2010 EMC Corporation. Do not Copy - All Rights Reserved. 26

27. Installation & Setup Configure DataDomain system
Install DD BOOST license
Install REPLICATION license (optional)
Enable DD BOOST protocol
Create DD BOOST user/password
Create DD BOOST Storage Units (at least one for each StorageNode)
Enable DD BOOST distributed segment processing
Define DD BOOST Interface Group (optional)
Enable/Disable DD BOOST low bandwidth optimization (optional)
Configure SNMP for NMC monitoring (optional)
Configure Networker system
Install Networker 7.6.1
Install DD Device Type Enabler (based on the DD raw disk capacity)
DD system and Networker Storage Node must be IP connected
Create a new DataDomain system
Add credentials for the DD system (user/password)
Create a new Networker device (DataDomain device type)
Configure media pool
Configure SNMP monitoring options (optional)
Configure backup group, cloning policy, etc.