oracle hsm 6.1 & 6.1.1 new featureskonferenz-nz.dlr.de/pages/samfs2017/present/1....

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |

Oracle HSM 6.1 & 6.1.1 New Features

Brad Blasing Senior Principal Software Engineer June 22, 2017

Oracle Confidential - Internal and NDA only


Oracle HSM Recent Release History Many releases in last 5 years

Version Release Date

6.1-01 3 Mar 2017

6.1 6 Apr 2016

6.0-01 6 Aug 2015

6.0 3 Mar 2015

5.4-02 3 Mar 2015

5.4-01 10 Oct 2014

5.4 1 Aug 2014

5.3-03 20 Apr 2015

5.3-02 5 Nov 2013

5.3-01 1 Mar 2013

5.3 27 Jun 2012


Oracle HSM Recent Release History Focus on recent changes

Version Release Date

6.1-01 3 Mar 2017

6.1 6 Apr 2016

6.0-01 6 Aug 2015

6.0 3 Mar 2015

5.4-02 3 Mar 2015

5.4-01 10 Oct 2014

5.4 1 Aug 2014

5.3-03 20 Apr 2015

5.3-02 5 Nov 2013

5.3-01 1 Mar 2013

5.3 27 Jun 2012


Oracle HSM 6.1 New Features

5

Released 6 April 2016

Solaris 11 only – S11.0 thru S11.3

LTO-7 LBP (Logical Block Protection, called DIV in HSM)

ACSLS 8.4 support

IBM TS3500/TS4500 library and TS1150 tape drive support

Large LUN support (128 TiB), for a 32 PiB total file system size

Fixity

Automated Media Migration

Small extended attribute optimization (on metadata)


Oracle HSM 6.1.1 (patch 1) New Features

6

Released 3 March 2017

Oracle Storage Cloud Support


In Depth on New features

7

Oracle HSM 6.1 & 6.1.1

Large LUNs

Fixity

Media Migration

Oracle Storage Cloud


Large LUNs


Fixity


In Depth

128 TiB LUN

16 TiB LUN


Large LUNs

– What you see: • Simple, LUNs greater than 128 TiB usable • Single file system size 4 PB 32 PB.

– What we see inside:

• Some number of moving parts • Block pointers 3 bits larger, two pieces • samu changes to view block pointers • Code is a bit more complex

16 TiB LUN

128 TiB LUN


Large LUNs

• An option bit is set in the file system super block when a large LUN is used • Prevents mounting, or samfsck’ing on any previous version • This is for safety


Large LUNs


Fixity


In Depth


Media Migration In Depth Easy?

Not that easy…


Media migration methods prior to Oracle HSM 6.1 CPU and personnel intensive

Method Challenges Use the Recycler to move data off old media • Rearchive request per file; many requests to

handle

Custom scripts to select files, sort by volume, issue rearchive requests

• Rearchive request per file; many requests to handle

Add a new copy, later remove old copy

• Archive request per file, later unarchive request per file

For all above methods, migration has to go through the file system (stage/rearchive)

• Need sufficient space to handle migration • Alters the state of the file system (what is

online, released)


Solve Migration Challenges with Oracle HSM Automated Media Migration

14

Migration Challenges

Oracle HSM Automated Media Migration

1. Policy-based migration 2. Eliminates data staging 3. Enables parallel migration 4. Reduces resource burden 5. Fastest path to single format

• Time: months or years to complete

• Cost: hardware, network, and personnel

• Complexity: manage multiple formats


Oracle HSM 6.1 Automated Media Migration Two Modes Supported

Memory-Assisted Copy

• Data is copied tape to tape through the metadata server, not through the disk cache

• Repack: tar files on tape are copied only if an active file is in the tar file

StorageTek Direct Copy

• Data is copied directly from source drive to T10000D

• Oracle HSM handles drive allocation and tape mounts

• Repack: tar files on tape are copied only if an active file is in the tar file

• Copy to EOD mode. Same as above, but all data, from first active tar file, is copied from source to destination


Accelerate Migration with Oracle HSM Automated Media Migration

16 16

• Copy to disk and then to tape • Resource-intensive migration

Traditional migration

• Copy directly from tape to tape • Bypass disk and host for fastest migration • Migrate unlimited parallel streams

T10000A/B/C/D LTO3/4/5/6/7 TS1130/40/50

T10000D

HSM ctrl

data

Oracle HSM StorageTek Direct Copy

Oracle HSM Memory-Assisted Copy

• Copy to memory and then to tape • Bypass disk for faster migration • Migrate multiple streams

File system ctrl

data

ctrl

data

ct

rl da

ta

ctrl

data

ct

rl da

ta

HSM


Oracle HSM 6.1 supports StorageTek Direct Copy

– Drives must be fibre channel connected, on the same fabric and zone – T10000D must be the destination drive – Any supported drive can the source – Tape block size must be the same; note that LTO typically may have smaller block size

than T10000D

Requirements to use StorageTek Direct Copy


Migrate All Data or Repack a Portion of Data

18

• Repack only active source tar files sequentially to a single cartridge

• Migrate entire contents of multiple cartridges to a single cartridge

Migrate Repack

Active

Expired Active

Expired Active

Expired

Active Active Active

scsi/

stat

us

data

Active

Expired Active

Expired Active

Expired

Active

Expired Active

Expired Active

Expired




Oracle HSM 6.1 Automated Media Migration

• No need to stage data • Coexists with normal HSM activity

– Runs in the background – Does not affect other Oracle HSM daemons or interrupt production activity

• Does not affect the file system – Additional free space and file system bandwidth not needed – File system state not altered (what is online or released)

Benefits of migration daemon (sam-migrationd)

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 20

How does Oracle HSM handle automated media migration?

Logging

File System Scan

Tape Copy

Tar Header Check

Inode Update

Oracle HSM media migration splits its

work into five phases


Five phases of automated media migration

Text here

Text here

Text here

Text here

Text here

Logging

File System Scan

Tape Copy

Tar Header Check

Inode Update

• All configured file systems are checked to see that they are mounted

• All inodes are scanned on all configured file systems

• Database of inodes is created for each file system

• Database used to identify active tar files, and later update inodes



Text here

Text here

Text here

Text here

Text here

Logging

File System Scan

Tape Copy

Tar Header Check

Inode Update

• Source tapes are marked read-only, copying proceeds according to policy

• Can utilize Oracle HSM Server Copy or StorageTek Direct Copy mode Tape copying proceeds either through the metadata server (Oracle HSM Server Copy), or directly from source to destination



Text here

Text here

Text here

Text here

Text here

Logging

File System Scan

Tape Copy

Tar Header Check

Inode Update

• After each volume is copied, selected tar files are re-read and headers checked to ensure data integrity.

• This process checks tar headers for the first, middle and last written position on the destination tape.



Text here

Text here

Text here

Text here

Text here

Logging

File System Scan

Tape Copy

Tar Header Check

Inode Update

• After each volume is copied, inodes in the file system are updated for migrated files

• The updated inode fields are

• media type

• vsn

• position

• changed time

• copy creation time



Text here

Text here

Text here

Text here

Text here

Text here

Text here

Text here

Text here

Text here

Logging

File System Scan

Tape Copy

Tar Header Check

Inode Update

• After each volume is copied, status of migration is logged

• Migrated files are logged

• Logs can/should be kept as a record of activity (similar to archiver log)


Configuring Oracle HSM Automated Media Migration

• /var/opt/SUNWsamfs/migrationd.cmd – Main configuration file

• samcmd migconfig, check log file for errors – When ready, samcmd migstart

• Sample migrationd.cmd configuration file: run_time = always

xcopy = on

logdir = /var/tmp/miglog

dbdir = /var/tmp/migdb

bufsize = li 128

max_drives = library 20 4 library 30 4

max_copy = 4

max_scan = 4

vsnpool = pool1 library 20 li SRC120 SRC121 SRC122

vsnpool = pool2 library 30 ti DST200 DST201 ^TTP

migrate = from li LIT300 LIT301 to li LIT900

migrate = from pool1 to pool2

Configuration


How do I control Oracle HSM automated media migration?

• samcmd migstart/migidle/migresume manual control • Time of day controls in migrationd.cmd • Max number of active copies/drives

Controlling


Monitoring Oracle HSM automated media migration

• Log file – tail -f /var/opt/SUNWsamfs/sammig/logfile

• samu – x display, show active migrations – y display, list all source and destination vsns – v display, show all vsns


Automated Media Migration samu “x” display – current migration status


Automated Media Migration samu “y” display – all source and destination VSNs


Automated Media Migration Media migration log example


Before Running Oracle HSM 6.1 Automated Media Migration

• Administrators can – Manually idle and resume – Run by time of day policy – Limit number of drives – Resume after system shutdown/restart – The migration daemon will resume where it left off in case of a planned or unplanned

system interruption

– Note: Migration will idle if source volume is needed for a stage and resume later

Considerations


After running automated media migration

1. What to do with the old media

2. Media migration daemon will update inodes, but not any existing samfsdump files – Old samfsdumps will point to the old volumes

3. Need to keep old media until oldest dump expires – Although may not need to keep it in library

4. “Occasional” lost file reloads may need old media – After a small reload and stage, unarchive the files and rearchive

5. May have custodial obligations with old media – May need to degauss before disposal – Encryption with Oracle Key Manager may help here – throw away the key

Considerations


Large LUNs


Fixity


In Depth


File Fixity

From Wikipedia: https://en.wikipedia.org/wiki/File_Fixity

File Fixity is a digital preservation term referring to the property of a digital file being fixed, or unchanged. Fixity checking is the process of verifying that a digital object has not been altered or corrupted.

During transfer, a repository may run a fixity check to ensure a transmitted file has not been altered en route. Within the repository, fixity checking is used to ensure that digital files have not been affected by data rot or other digital preservation dangers.

By itself, fixity checking does not ensure the preservation of a digital file. Instead, it allows a repository to identify which corrupted files to replace with a clean copy from the producer or from a backup.

In practice, a fixity check is most often accomplished by computing checksum or cryptographic hash function values for a file and comparing them to a stored value or through digital signatures.

Was ist es?

https://en.wikipedia.org/wiki/File_Fixity


Fixity

• 128-bit checksum of file • Optional, generated on archive, checked on staging • If the checksum did not compare, another copy is staged, or error • Algorithm proprietary, computationally intensive • Not cryptographically strong

Legacy capabilities


Fixity

37

New Needs

Need cryptographically strong hash/checksum

Need the capability to bring in a hash with a file, and verify that no change has happened

Need faster computation of hash/checksum

Need some optional method of ensuring that the file does not change


New fixity features

• MD5 (128-bit) • SHA-1 (160-bit) • SHA-2 family:

– SHA-256 – SHA-384 – SHA-512

• Original legacy checksum still supported

New Algorithms


New fixity features

• New algorithms can be calculated in hardware – Much faster than legacy algorithm – Hardware assist with X86_64 Xeon, or SPARC T4 or later

Hardware assist


New fixity features

• -a <algorithm> added – Supported algorithms: MD5, SHA-1, SHA-256, SHA-384, SHA-512, LEGACY – Applicable to regular files only

• -h <hash> added – Used to specify a known hash for a file – Must use new non-legacy –a algorithm – Command returns error if hash specified does not match

• -G Used with –h above to generate and check hash immediately

ssum command changes


New fixity features

• sls – show hash value (-h) and algorithm type (-D output) • sfind – added search options to search based on algorithm type and fixity

attribute • sam_ssum() – access new fixity features from C library libsam • RPC API – likewise changes from RPC library • New man page fixity(7) describing changes

Additional changes


New fixity feature

# ssum -g -u -a SHA-256 testf # sls -D testf testf: mode: -rw-r--r-- links: 1 owner: root group: root length: 19298887 admin id: 0 inode: 1558.3 project: user.root(1) access: Jun 18 16:19 modification: Jun 18 16:19 changed: Jun 18 16:19 attributes: Jun 18 16:19 creation: Jun 18 16:19 residence: Jun 18 16:19 checksum: generate use algorithm: SHA-256

Example


New fixity feature

# sls -Dh testf testf: mode: -rw-r--r-- links: 1 owner: root group: root length: 19298887 admin id: 0 inode: 1558.3 project: user.root(1) archdone; copy 1: ------ Jun 18 16:20 77.1 cl bblasing20_0000002 access: Jun 18 16:19 modification: Jun 18 16:19 changed: Jun 18 16:20 attributes: Jun 18 16:19 creation: Jun 18 16:19 residence: Jun 18 16:19 checksum: generate use validated algorithm: SHA-256 hash: 5e12f888d99e7bd78b527395423a6762123d693c14f0f88e58bd7a0907b801a5

Example, after archive done


New fixity features

• Room in inode for new algorithm numbers • New hashes are long; no room in file inodes for them • New algorithms use extended attributes to store the hash

– Hash is stored in “SUNWsamfs_digest” extended attribute for each file

• Small extended attributes now stored on metadata, preferably on flash

Internal implementation


Fixity new features – fixity option

45

Need

Oracle HSM Fixity option

1. Import checksum 2. Verify checksum 3. Mark file immutable,

unchangeable

• Know that files have not changed

• Verify with cryptographic hash


New fixity features

• Specifying “-F” on ssum generates and checks supplied hash • After hash is checked, file is marked “immutable”

– Immutable files (Solaris feature) cannot be written/changed, removed, or renamed. – Achtung! – not even by super-user – As file is released and staged, checksum hash is checked as usual – File is protected from accidental or intentional changing or removing

Individual file fixity feature


Large LUNs


Fixity


In Depth



• See https://cloud.oracle.com/storage for more details • Oracle HSM supports both the “Object Service” and “Archive Service” • Different pricing schedules for the two services • Different service levels for the two services • Multiple global data centers • Access via dedicated connection or public internet • REST interface, OpenStack Swift based

Basics

https://cloud.oracle.com/storage


Oracle Storage Cloud Global Datacenters

Chicago Amsterdam

UK

Virginia

Live


Oracle HSM Support for Oracle Storage Cloud Just another tier of storage

ORACLE Storage Cloud

Disk Storage

Tape Storage

50

Oracle HSM


HSM Oracle Storage Cloud

• No different from user point of view • POSIX file system view is not changed • OHSM administrator sets it up as another archive copy • Typical to put it as the last copy


• Typical 1-4 copies on tape

Archiving Flexibility with Oracle Storage Cloud

Tape Archive Only

52

• No on-premise tape equipment

• Perhaps first copy is to object service

Object & Archive Cloud

• First copy to tape, 2nd copy to cloud

• Recall/stage speed of tape, economical

Hybrid Tape & Cloud

• Two copies to tape as typical

• Additional safety copy to cloud

Hybrid 2 Tape & Cloud

Object Archive Archive Archive


Cloud Implementation in Oracle HSM Nomenclature

Oracle HSM Name Cloud Terminology Library Cloud account and login credentials Tape volume or VSN Container Tape block Object Tape drive Stream to/from cloud



• Don’t need to add volumes to library – they are created as needed • 1 TB in size, but flexible – no limit • Archiving does not overflow from one container to the next

– Container size will increase to accommodate the last file

Tape Volumes / Containers in Cloud



• 16 MB object size / tape block size • File aggregation using tar format; identical to tape format

– No tape labels – tape label information is put in cloud container metadata

Tape Volumes / Containers in Cloud


HSM Oracle Storage Cloud - Examples

mcf file: /etc/opt/SUNWsamfs/Chicago-Cloud_Brad 100 cr bblasing20 - Cloud config file (Chicago-Cloud_Brad): name = bblasing20 #type = oracle-object type = oracle-archive url = https://a450176.storage.oraclecloud.com domain_id = Storage-a450176 username = [email protected] password_file = /root/cloud_password_cloud_chicago_brad drives = 4

Cloud Configuration

https://a450176.storage.oraclecloud.com

mailto:[email protected]



Cloud Library Activity samu 6.1.samqfs61-clone 15:18:10 Jun 18 2017 Cloud Library eq# 100 : bblasing20 Connection status : Connected/Ready Cloud library message : running Active streams : 0 reading, 3 writing, 1 idle I/O rates : 0.0 MB/sec reading (idle) : 77.2 MB/sec writing #>---#>---#>--- to cloud Retry counts/sec : 0.0 (read), 0.0 (write)

samu “z” display



Cloud Library Activity samu 6.1.samqfs61-clone 15:18:10 Jun 18 2017 Cloud Library eq# 100 : bblasing20 Connection status : Connected/Ready Cloud library message : running Active streams : 0 reading, 3 writing, 1 idle I/O rates : 0.0 MB/sec reading (idle) : 77.2 MB/sec writing #>---#>---#>--- to cloud Retry counts/sec : 0.0 (read), 0.0 (write) Drive Status VSN MB/sec Retry/s 101 Write bblasing20_0000002 24.6 0.0 102 Idle 103 Write bblasing20_0000000 26.8 0.0 104 Write bblasing20_0000001 25.7 0.0

samu “z” display with streams shown (hit tab key)



Robot VSN catalog by slot : eq 100samu 6.1.samqfs61-clone 15:25:15 Jun 18 2017 slot access time count use flags ty vsn 0 2017/06/18 15:15 3 23% -il---b----- cl bblasing20_0000000 1 2017/06/18 15:16 1 20% -il---b----- cl bblasing20_0000001 2 2017/06/18 15:16 1 10% -il---b----- cl bblasing20_0000002 3 none 0 0% -il-o-b----- cl bblasing20_0000003

samu “v” display showing cloud containers (vsns)



# sls -D test.230 test.230: mode: -rw-r--r-- links: 1 owner: root group: root length: 34652249 admin id: 0 inode: 1305.2 project: user.root(1) archdone; copy 1: ------ Jun 18 15:17 0.37b335 cl bblasing20_0000001 access: Jun 18 15:15 modification: Jun 18 15:15 changed: Jun 18 15:15 attributes: Jun 18 15:15 creation: Jun 18 15:15 residence: Jun 18 15:15

sls –D on a cloud archived file



• Files can be staged with stage(1), archived with archive(1) • Archive/release policy set with usual configuration commands • sls –D shows the status of files • Unarchive/rearchive can be used on files • All typical user and administrative commands work on the cloud

Standard OHSM commands used with cloud


HSM Oracle Storage Cloud – Cloud Dashboard Cloud view



cloud01-mn$ cat file-000001.000001 [{"hash":"28f19545f98ab5933808761a69df6ef3","last_modified":"2017-05-12T12:10:09.000000", "bytes":16777216, "name":"/bblasing11.data@bblasing11_0000000/block.000000","content_type":"*/*"}, {"hash":"667230f64c5baa1e87a6049dccc91fcb","last_modified":"2017-05-12T12:10:10.000000", "bytes":16777216, "name":"/bblasing11.data@bblasing11_0000000/block.000001","content_type":"*/*"}, {"hash":"001930b587e8b90f9d64b174c69c0a4b","last_modified":"2017-05-12T12:10:09.000000", "bytes":16777216, …

Metadata example



cloud01-mn$ cat file-000001.000001 [{"hash":"28f19545f98ab5933808761a69df6ef3","last_modified":"2017-05-12T12:10:09.000000", "bytes":16777216, "name":"/bblasing11.data@bblasing11_0000000/block.000000","content_type":"*/*"}, {"hash":"667230f64c5baa1e87a6049dccc91fcb","last_modified":"2017-05-12T12:10:10.000000", "bytes":16777216, "name":"/bblasing11.data@bblasing11_0000000/block.000001","content_type":"*/*"}, {"hash":"001930b587e8b90f9d64b174c69c0a4b","last_modified":"2017-05-12T12:10:09.000000", "bytes":16777216, …

Each block is MD5 hashed – generated and checked by cloud and OHSM


Oracle HSM Resources

• Product main page: – http://www.oracle.com/goto/hsm

• External Wiki/Community space: – https://community.oracle.com/community/server_%26_storage_systems/systems-

io/oracle-tape-storage/oracle_HSM – WWWW (What Works With What) here – important information resource – Release history – Tape drive and library support – Documentation library pointers

Summary

oracle hsm 6.1 & 6.1.1 new featureskonferenz-nz.dlr.de/pages/samfs2017/present/1....

Documents