This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
This document is solely for the use of Sony Pictures Entertainment (SPE) personnel. No part of it may be circulated, quoted, or reproduced for distribution outside the SPE organization without prior written approval from IBM.
Review of assumptions and figures from our last meetingIntroduction and discussion of proposed approach to file managementReview and discussion of impact new requirements will have on server and storage infrastructureLTO Library Capacity Requirements
Data FROM LTO Library to DBB = 86MB/sData FROM CW = 330MB/sData FROM other sources = 100MB/s
DBB TO LTO = 430MB/sData TO CW = 100MB/sData TO other sources = 100MB/sData TO other Destinations = 200MB/s
Total WRITE = 516MB/s
It was mentioned that there may be a desire to have two copies of everything on tape and/or send a second copy through compression for storage to LTO off site. Assuming we need to keep up with ‘constant ingest’ this will add an additional 430MB/s for DR.
Total System Bandwidth = 1,776MB/s
DBB TO LTO2 (DR) = 430MB/s
Other Base Assumptions:o 1 Week = 6 dayso 1 Day = 24 hourso Data Retention (DBB) will vary but is assumed to be 18 monthso CW Scanner Generate 25TB/day (150TB/week)o CW Lib Masters and Digital Cam shots add another 50TB/week o CW File Size can be between 10 and 110MBo “Other” sources to DBB will provide 50M files/year at 20MB/file
and 70TB/week/weeko Original workflow called for all content to go to BB and then be
“MOVED” to tape. Selected sequences would be called via a list from Sony and “COPIED” back from Tape to Disk.
o There may be alternative workflows which are more efficient.o Sufficient Network infrastructure exists within the DBBo Other assumptions related to file management and works are
included in deck
10/14/09
430MB/sSpecified at 20% = 86
Imageworks DBB
330MB/s 100MB/s
Data TO CW = Undefined – Assuming 100MB/s
86MB/s READ from LTO (20% specified)
Total READ = 830MB/s
70TB/week1
200TB/6-day week (35TB/day)1
Volumes:CW to DBB = 210TB/Week (35TB/day specified)Other Sources to DBB = 70TB/WeekTotal expected volume to DBB (and therefore LTO)
= 280TB/Week1Note:1. Assuming 330MB/s over 24 hours yields 28.5TB NOT the 35TB specified2. Assuming 100MB/s over 24 hours yields 8.6TB NOT the 12TB specified
High speed tape accessA group of files are written as a single object on tape.A smaller number of larger tape objects is more efficient.A reduction in the number of objects in the tape storage system results in a smaller tape object database.Larger objects are written to tape at a faster rate.The map between tape objects and disk files is stored with the files, both on disk and on tape, and can also be saved independently.Individual files can be retrieved without retrieving the entire group.Greater flexibility in what protocols locations may be enabled for LTO read/writeImproved organization of files on LTOEase of recovery from system problems Integrated with standard TSM and GPFS products
GPFS data Archived to tape in aggregated format, source files REMAIN– Tapes will be valid for future phases, no migration will be needed– Immediate aggregation benefit
Sony Applications may still access GPFS for recalled dataCustom applications select files to archive by directory
Pre-Reqs
TSM Archive Aggregation code completed– Mapper
– Selects directories to be archived– Creates the Mapfile for each directory, saved in that directory
– Archiver– Locates directories with Mapfiles and data files, invokes PRouter to archive
them– PRouter - TSM API archive application
– Aggregates a directory of files (including the mapfile) and stores in TSM
Backbone Assumptions 1. The backbone will have disk storage and tape storage2. There will be a single file system view which unifies file searching and access regardless
of the actual file location3. Files are copied to the backbone, or copied from the backbone. They are NEVER
updated directly while on the backbone.4. If a file is changed while off the backbone, it will be returned to the backbone under a
different name.a. i.e. there will only ever be a single version of each file on the backbone, though it
can be in multiple locations, disk, tape.b. Each file will have a unique combination of path and name. i.e. names can repeat
but must be in different subdirectories, There is no support for overwrite.5. All files arriving on the backbone disk will be copied to tape, resulting in 2 copies of the
file, 1 on disk, 1 on tapea. The copy to tape will be asynchronous as capacity allowsb. The copy on tape may be suitable for DR c. Optional policies will create copies on 2 different tapes for redundancy
6. Files on disk may be deleted per policy, leaving only a single copy on tape7. Files on tape will be deleted via manual processes on a project basis8. Requests for access to a file on tape will cause the file to be copied from tape to the client
locationa. The file is NOT returned to the disk area of the backbone since the presumption is that
the files will be changed and return under a different name.b. File delivery will be highly asynchronous due to request queues, tape, and tape drive
access limitations9. Directory naming conventions will help optimize performance
a. directory names will isolate projects from each other i. facilitate tape reclamationii. map to TSM constructs, e.g. tape pools
b. directory arrangements will group together data likely to be accessed together (e.g. frames with the same minute) i. minimize tape mounts required for file recall
Use GPFS as the Index for all files– Directly if the file is on disk
– Indirectly via a Mapfile if the file is on Tape–~1500X reduction in GPFS and TSM objects
Mapfile is an aggregation of stubsCustom code enables Aggregation– Aggregate files to TSM
– Partial object restore for efficient recall
This document is solely for the use of Sony Pictures Entertainment (SPE) personnel. No part of it may be circulated, quoted, or reproduced for distribution outside the SPE organization without prior written approval from IBM.
Data FROM LTO Library to DBB = 86MB/sData FROM CW = 330MB/sData FROM other sources = 100MB/s
DBB TO LTO = 430MB/sData TO CW = 100MB/sData TO other sources = 100MB/sData TO other Destinations = 200MB/s
Total WRITE = 516MB/s
It was mentioned that there may be a desire to have two copies of everything on tape and/or send a second copy through compression for storage to LTO off site. Assuming we need to keep up with ‘constant ingest’ this will add an additional 430MB/s for DR.
Total System Bandwidth = 1,776MB/s
DBB TO LTO2 (DR) = 430MB/s
Other Base Assumptions:o 1 Week = 6 dayso 1 Day = 24 hourso Data Retention (DBB) will vary but is assumed to be 18 monthso CW Scanner Generate 25TB/day (150TB/week)o CW Lib Masters and Digital Cam shots add another 50TB/week o CW File Size can be between 10 and 110MBo “Other” sources to DBB will provide 50M files/year at 20MB/file
and 70TB/week/weeko Original workflow called for all content to go to BB and then be
“MOVED” to tape. Selected sequences would be called via a list from Sony and “COPIED” back from Tape to Disk.
o There may be alternative workflows which are more efficient.o Sufficient Network infrastructure exists within the DBBo Other assumptions related to file management and works are
included in deck
10/14/09
430MB/sSpecified at 20% = 86
Imageworks DBB
330MB/s 100MB/s
Data TO CW = Undefined – Assuming 100MB/s
86MB/s READ from LTO (20% specified)
Total READ = 830MB/s
70TB/week1
200TB/6-day week (35TB/day)1
Volumes:CW to DBB = 210TB/Week (35TB/day specified)Other Sources to DBB = 70TB/WeekTotal expected volume to DBB (and therefore LTO)
= 280TB/Week1Note:1. Assuming 330MB/s over 24 hours yields 28.5TB NOT the 35TB specified2. Assuming 100MB/s over 24 hours yields 8.6TB NOT the 12TB specified
Assumptions:2 MB block sizeVaried throughput till one of the system components began to be stressed
Measures:Internal FC utilizationExternal Host Adapter utilization This is where most bottlenecks occurredHard Drive utilizationProcessor UtilizationPCI Bus utilization
Loop optimizationsDS4800 performs best with disk drawers in even multiples of 4DS5000 performs best with disk drawers in even multiples of 8
Performance optimizationsIncreasing quantity and speed of Host Adapters had biggest impact, as would be expected for a large block size workloadSATA disk drives provide sufficient bandwidth if present in sufficient quantity
Other WorkloadsGPFS metadata and TSM/VFS database should be on separate, high performance Fiber channel subsystems
This document is solely for the use of Sony Pictures Entertainment (SPE) personnel. No part of it may be circulated, quoted, or reproduced for distribution outside the SPE organization without prior written approval from IBM.