EMC isilon as a TSM Backup

1© Copyright 2014 EMC Corporation. All rights reserved.© Copyright 2014 EMC Corporation. All rights reserved.
ISILON AS A
TSM BACKUP TARGET
<Presenter>
Isilon Storage Division

Download this Slide
http://ouo.io/H9mJ1k

Agenda
Market Dynamics
Networking Best Practices
Advantages & Challenges of Backup to Disk
The Isilon Solution
Summary
Isilon Node Types and Sizing for TSM
Special thanks to Dr. Stefan Radtke

Virtualization Life Sciences FinanceGovernment
Media &
Entertainment
Isilon Key Market Verticals
Video
Surveillance
Manufacturing Internet Healthcare
Video
Surveillance
Video
Surveillance
Backup/Archive

DataStorage Needs Are Evolving
Applications
Storage
infrastructure
5
SECURESIMPLE
EFFICIENTSCALABLE
Enterprise
@Scale
File Shares, Home Directories
and Data Repositories
AnalyticsMobile
Cloud

Unstructured Data Growth
Total Capacity Shipped, Worldwide Unstructured Data
80%
74%
67%
71 EB 133 EB37 EB
2013 2015 2017
Source: IDC

Unstructured Data Propels Move to File
0
20
40
60
80
100
120
140
160
180
200
2013 2014 2015 2016 2017
Exabytes
File: 53. 1% CAGR
Block: 28.9% CAGR
• Analysts expect data on file
storage to grow at twice the
rate of block storage
• Unstructured data is the
overwhelming type of data
fueling the move to file
• Growth drivers include:
• Media rich applications
• Big Data
• Cloud services
• Mobile devices
• Social Networking
• 2nd and 3rd generation platforms
Source: IDC 2013
Unstructured Data

Driving Enterprises toSwitch toDisk Backup
0.0
0.5
1.0
1.5
2.0
2.5
3.0
2009 2010 2011 2012 2013 2014 2015 2016
VTL NAS SAN DAS
CAGR 45.6%
CAGR 22.0%
CAGR 21.9%
CAGR -4.2%
Exabytes

Backup Software Market Share
Source: IDC July 2013

Agenda
Market Dynamics
The Isilon Solution
Summary
Isilon Nodes and Sizing for TSM

Advantages of Backup to Disks
 Faster backup & restore for unstructured data
 Faster reclamation
 Less secondary workload (avoids migrations)
 But most importantly
– Predictable recovery times for SLAs
– Not depending on available number of tape drives
– Less dependent on number of clients to recover
 Lower TCO in many cases
– Depends on use cases, capacity, frequency of access etc.
– No SAN required

The Traditional TSMChallenge with B2D
 Filesystems could not easily be shared among
TSM Servers
 Filesystems cannot grow to accommodate any size
without manually reshuffling and rebalancing tons
of data through TSM
 Management complexity:
– Separate SAN adapters
– Storage controllers
– Device drivers
– Array definitons
– LUN definitions
– LUN masking
– SAN zoning
– Volume Groups, Logical Volume, Filesystem
management
– Device class definitions
 Requires performance and capacity management
 Is not scaleable beyond a PB or so
TSM Clients TSM Servers

RAID
Aggregate /
LUN / SAN
Volume
File System
Administrators complain most about load balancing, managing users and
data across silos and islands as well as upgrading new hardware.
 Different
utlization
 Unbalanced
on capacity
and
performance
Traditional NAS don‘t change the game
The traditional NAS Challenge

Agenda
Market Dynamics
The Isilon Solution
Summary
Isilon Node Types and Sizing for TSMTSM

Isilon Solution
 No Compromise Scale-Out Efficiency
 Single volume spans all nodes
– Directories and files striped across the
cluster
 Storage efficiency inherently optimized
at 80+%
 Auto-balance of capacity and
performance
 No Data Migrations
– No manual intervention, reconfiguration,
server or client mount point or application
changes

Gain New Levels of Efficiencyfor TSM
• Migrates content to new storage nodes
while system is online and in production
• NO manual intervention
• NO reconfiguration
• NO server or client mount point or
application changes
• Eliminates “Hot Spots”EMPTY
EMPTY
EMPTY
EMPTY
EMPTY
FULL
FULL
FULL
FULL
BALANCED
BALANCED
BALANCED
BALANCED
BALANCED
AutoBalance
Automated data balancing across nodes reduces
costs, complexity, and risks for scaling storage

SimplifiedTSM + Isilon Setup
TSM
Clients
TSM
Servers
/ifs/tsm1
/ifs/tsm2
/ifs/tsm3
Isilon provides extremely efficient TSM
Backup to disk
 TSM servers can share a single scalable
filesystem
 Flexible protection level at much higher
efficiency than RAID
 Extremely easy to manage
 Extremely cost effective with NL nodes
 Allows to achieve predicatble SLAs
 Adding capacity is a 60 second task.
OneFS autobalances data. No action
required at TSM level.
 HSM functionality gets outstanding recall
times
 Eliminates need for SAN
 Allows making TSM servers to move around
as VMs
L
A
N

Simple is Smart
Isilon HW-Topology
 Isilon has integrated RAID, Volume Manager and
Filesystem layers into OneFS!
 The resulting HW-Architecture is therefore
MUCH simpler
 Uses internal Storage rather than Storage-
Server/Storage Controllers / Storage Enclosoures
and SAN in between
 Data Protection is very flexible:
- /tmp can have other protection as
/data/tsm
TSM
Server
TSM
Server
LAN
TSM
ServerTSM
Server
TSM
ServerTSM
Server
Isilon Node
GB/10GB
Ethernet
Isilon
SAS
Isilon Node
SAS
Isilon Node
SAS
Infiniband
…

Issues with typical legacy solutions
The RAID Data Protection Challenge
Legacy scale up systems are still dependent on traditional data protection
Typically use traditional RAID which consume up to 30%+ of
the available disk capacity
Time to rebuild a RAID group after a drive failure continues to
increase with drive capacity increasing risk of data loss
Archives also need to survive major disasters
Data loss susceptible to 2 disk failures/2 controller failures

 Data is striped across the nodes
– Not across disks
– FEC not RAID
 Data breakdown:
– 8 KB blocks
– 16 blocks per stripe unit
– 128 KB stripe width
per drive
OneFS DataLayout
TSM
Server
File
Write
Data Stripe
Unit
Data Stripe
Unit
Data
stripe
unit
Data
stripe
unit
Parity
stripe
unit
File

D
1
D
2
D
3
D
4
P
0
P
1
D
5
D
6
D
7
D
8
P
0
P
1
D
9
D
1
1
D
1
2
D
1
0
P
0
P
1
Node1 Node2 Node3 Node4 Node5 Node6
Protection
Group
Protection
Group
Protection
Group
Isilon Data Protection
 Isilon automatically stripes all data accross
all Nodes
 Data protection is done with Error Correction
code rather than RAID
 You can set a cluster default, a pool default as
well as a directory and even file level
protection level
 Rebuild time much faster than with RAID
 No need to take care about RAID Level, LUN,
Segement Size, LUN size, failure groups, …
 Data is balanced automatically!
 No dedicated physical hot spares required
D
6
D
7
D
8
D
9
D
1
0
D
1
1
D
1
2
D
1
D
2
D
3
D
4
D
5
Data Stripes of 128kB

OneFS ProtectionExamples
Node 1 Node 2 Node 3 Node 4 Node 5
128K
Parity
Parity
128K
128K
Parity
128K
128K
128K
128K
Parity
128K
128K
Parity
Parity
Parity
128K
128K
128K
128K
Parity
128K
128K
128K
128K
128K
128K
128K
128K
128K
Parity
128K
128K
Data Stripe
Data Stripe
Data Stripe
Data Stripe
N+2
N+2:1
N+3:1

Protection Levels
 N+M:B =
– N = number of nodes
– M = number of disk failures
– B = number of node failures
 A protection group will stripe across multiple drives in a node
 Simulates a larger number of nodes
 OneFS protection levels can be set
– Per pool
– Per directory and/or
– Per file

Typical overhead for 5+ Node config (5+2:1) < 20%
DataProtection Overhead
Number of
Nodes
+1 +2:1 +2 +3:1 +3 +4
3 2+1 (33%) 4+2 (33%) 3x -- -- --
4 3+1 (25%) 6+2 (25%) 2+2 (50%) 9+3 (25%) 4x --
4+1 (20%) 8+2 (20%) 3+2 (40%) 12+3 (20%) 4x 5x
6 5+1 (17%) 10+2 (17%) 4+2 (33%) 15+3 (17%) 3+3 (50%) 5x
7 6+1 (14%) 12+2 (14%) 5+2 (29%) 15+3 (17%) 4+3 (43%) 5x
8 7+1 (13%) 14+2 (12.5%) 6+2 (25%) 15+3 (17%) 5+3 (38%) 4+4 (50%)
9 8+1 (11%) 16+2 (11%) 7+2 (22%) 15+3 (17%) 6+3 (33%) 5+4 (44%)
10 9+1 (10%) 16+2 (11%) 8+2 (20%) 15+3 (17%) 7+3 (30%) 6+4 (40%)
12 11+1 (8%) 16+2 (11%) 10+2 (17%) 15+3 (17%) 9+3 (25%) 8+4 (33%)
14 13+1 (7%) 16+2 (11%) 12+2 (14%) 15+3 (17%) 11+3 (21%) 10+4 (29%)

Highly resilient, clustered architecture
Unmatched Data Protection and Availability
100%
100%
100%
100%
100%
100%
100%
100%
FAILED
FAILED
With N+2, N+3, and
N+4 protection,
data is 100% available
if multiple drives or
nodes fail
With N+1 protection,
data is 100% available
even if a single drive
or node fails
And with Isilon, the
more nodes in the
cluster, the faster
drive rebuild time

SnapshotIQ
 Can be taken per Cluster, Directory or Subdirectory
 Snapshot types (OneFS pics automatically)
– Point in Time Copy (large sequential writes and deletes)
– Copy on Write (Small changes and inodes + directories)
 Limits
– Default limit 20000
– Can be increased
– Best practices is
1024 per directory
End-user
/ifs/data/foo/bar.txt
/ifs
0800_snap 0900_snap
/ifs/data/foo/.snapshot/0900_snap/bar.txt
8:00 9:00
9:10
File Deleted
9:14
File Restored

SyncIQ: ParallelReplication
 Designed ground-up for scale-out storage
 Aggregate throughput scales with capacity
 Maintain consistent RPO over growing data sets
 Underlying FS knowledge
– Snapshot integration
– Block-level deltas
– Rich meta-data transfer
 Automated Data Failover/Failback

Agenda
Market Dynamics
Isilon Node Types and Sizing for TSM
Summary
The Isilon Solution

EMC Isilon
Scale-out NAS Product Family
Linear Scaling Of Performance And Capacity
Purpose-built for IOPS-
intensive, random access
file-based applications
S-Series
Purpose-built for
cost-effective, large
capacity storage
NL-Series
A flexible solution for
highly concurrent and
sequential throughput
applications
X-Series
Capacity
Performance
Highest Density storage
for deep archive
applications
HD-Series

 High Density Platform 2.5X Increase in Cluster Capacity
to 50PB
 3.2PB Capacity per Rack and 10x supported internode
distance
HD400
High Density
Deep Archiving Platform
 50% Lower Operational Expenses with a Consolidation of
More Data In Data Lake
 Platform Ideal For Deep Archiving with a smaller data center
footprint

NL400 – Archive/Backup platform
Base platform
Intel Nehalem CPU
8 cores (2x4 cores)
36 x 3.5” Drive slots
4U Form factor
NVRAM: 512MB
Scales 3 nodes to 144 nodes
= 108 TB to 20 PB
Memory
configurations
12GB
24GB
48GB
Disk configurations
Data only
36x1TB SATA
36x2TB SATA
36x3TB SATA
36x4TB SATA … 144 TB Raw
per 4U
No SSD Disks
- SSDs only available on S and
X-Nodes
Network
configurations
4x1GbE
2x1GbE +
2x10GbE

Isilon NL& HD36,72, 108,144SpecificationforTSMdisk poolSmall,Medium, Large,Very LargeandHuge
SMALL
3xNL400-36
Min: 3x36TB = 108 TB
Max: 144x36TB = 5,1 PB
Throughput:
3 Nodes ~ 1200 MB/s
144 Nodes ~ 57 GB/s
Medium
3xNL400-72
Min: 3x72TB = 216 TB
Max: 144x72TB = 10,3 PB
Large
3xNL400-108
Min: 3x108TB = 324 TB
Max: 144x108TB = 15,5 PB
XXL
3xNL400-144
NL400
Min: 3x144TB = 432 TB
Max: 144x144TB = 20,7 PB
All raw capacity
Capacity
Cost
HD400
Min: 3x360TB = 1 PB
Max: 144x360TB = 52 PB
XXL
3xHD400-144

TSM/Isilon Capacity Considerations
 Typically all primary TSM data (disk, file and tape) can be replaced with ISILON
 Only the copy pools and possibly long-term, rarely accessed archive data may
remain on physical tape
 Pools of type „activedata“ can be ignored since they‘re no longer required with
ISILON
 Overall, currently required size in Megabytes can be obtained by issuing
select sum(logical_mb) from occupancy where stgpool_name in (select
stgpool_name from stgpools where pooltype='PRIMARY')
on all TSM servers and summing it up. Add 20% for partly used volumes (reclaim
threshold usually set to „10“ with pools on ISILON). Add usual reserve capacity for
short term growth.

TSM/Isilon ThrougputConsiderations
 Obtain the average throughput required for primary data movement (client backup, archive, restore,
retrieve, space management etc.) over a sufficiently long period of time. If in doubt, issue something
like this:
select sum(bytes)/1024/1024/x from summary where entity in (select node_name from nodes) and
start_time >= current_timestamp - x days
 Where „x“ is the number of days you want to have included in the analysis, counting backwards from
today. Make sure x < “Activity Summary Retention Period” (q status) in your TSM server(s).
 Divide that number by the hours you want your daily backup window to have. Divide by 3600 for MB/s.
Sum up across all TSM servers. Add sufficient reserve for peak activities and growth (multiplying by 2 may
be a good start).
 Divide the result by 500 (or 400 for more conservative approach) to come up with the number of ISILON
NearLine nodes required to achieve the desired throughput.
 Make sure there is enough network bandwidth available from your individual TSM servers (number of
1GB/10GB Adapters) to the ISILON for calculated throughput.

Agenda
Market Dynamics
The Isilon Solution
Summary

NetworkingBest Practice
 Use 10 GB Ethernet
 Connect all nodes with at least one
10 GBE interface to the LAN
 Make sure the TSM-Server has
enough CPU power (typical system
gets almost 100% utilized by a
single 10 GBE connection
 Use SmartConnect to balance
connection (see separate discussion
for Linux/Unix)
 If you use SynIQ to replicate the
data to another Isilon system, use
a separate 10 GBE connection on
each node.
TSM
Clients
TSM
Servers

Some General Considerations
 All TSM Volumes can potentially reside in a single directoy. Different
TSM instances will not overwrite volumes.
 You may however consider creating a seaprate directory under /ifs
for each TSM server to keep things ‚understandable‘ for the human
admin
 NFS mount using hard,sync options, read and write size=256k
 Don‘t use SMB permanent mounts (volume label) rather than the
UNC path to the cluster: Smart-Connect-IPshare in the device
definition.
 There is no requirement for TSM volume sizes but for better
managability you should make them larger than 100GB

Networking best Practice for Windows
 For TSM Servers running on Windows,
you can create a single directory like
/ifs/data/tsm to store the TSM
volumes
 Do not mount it permanently to a drive
letter. Use UNC pathname to the share
instead like Cluster-Nametsm
 This guarantees a dynamic load
balancing when using SmartConnect
 Data traffic as well as capacity gets
distributed automatically.
TSM
Clients
TSM
Servers

Networking Best Practice for Linux/Unix
 Linux/Unix mounts are permanent. If the server starts,
there would be only one mount point and the
SmarConnect load balancing is static.
 To leverage the full parallel throughput of all Isilon nodes
for each TSM Server we need a mount each node
separately.
 We should create and mount as many target diretories as
we have nodes in the cluster:
mount node1:/ifs/tsm /tsm/n1
 And put all of them into the device class:
define devclass ...
dir=/tsm/n1,/tsm/n2,/tsm/n3
 In case of a node failure, SmartConnect will fail over the
IP-address and operation continues.
 But….see next page
TSM
Clients
TSM
Servers

Agenda
Market Dynamics
The Isilon Solution
Summary

Summary
 Isilon delivers massive scale and performance for TSM
– Reduce backup windows
– Allows to meet SLAs
– Outstanding recall times for restore and HSM
 Isilon minimizes TSM management
– Extremely easy to manage
– Adding capacity is a 60 second task. OneFS autobalances data.
– All TSM instances share a single filesystem
– Enhance capacity without touching TSM
– Can now run TSM in Virtual Machines
 Isilon lowers TCO
– Flexible protection level at much higher efficiency than RAID
– No shared disks on SAN, completly eliminates SAN
– Extremly minimized management
– Attractive €/GB price point

EMC isilon as a TSM Backup

Recomendados

Recomendados

Más contenido relacionado

Más de solarisyougood

Más de solarisyougood (20)

Último

Último (20)

EMC isilon as a TSM Backup