Hints for a successful hfs to zfs migration

IBM Systems and Technology Group

Hints for a Successful HFS to zFS Migration

Ann Totten
atotten@us.ibm.com
Session 2255
Wednesday August 26, 2009

SHARE Denver 8/10/2009 © 2003 IBM Corporation

2255 Hints for a successful HFS to zFS Migration
Trademarks
The following are trademarks of the International Business Machines Corporation in the United States and/or other countries.

DFSMSdfp IBM* Language Environment* SystemPac*
DFSMSdss IBM eServer On demand business logo System z9
DFSMShsm IBM e(logo)server* OS/390* VTAM*
DFSMSrmm IBM logo* Parallel Sysplex* z/Architecture
RACF* z/OS*
RMF zSeries*
S/360
S/370
S/390

* Registered trademarks of IBM Corporation
The following are trademarks or registered trademarks of other companies.
Intel is a trademark of the Intel Corporation in the United States and other countries.
Linux is a trademark of Linux Torvalds in the United States, other countries, or both.
Java and all Java-related trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.
Microsoft, Windows and Windows NT are registered trademarks of Microsoft Corporation.
UNIX is a registered trademark of The Open Group in the United States and other countries.
* All other products may be trademarks or registered trademarks of their respective companies.
Notes:
Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will
experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here.
IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply.
All customer examples cited or described in this presentation are presented as illustrations of the manner in which some customers have used IBM products and the results they may have achieved. Actual
environmental costs and performance characteristics will vary depending on individual customer configurations and conditions.
This publication was produced in the United States. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without
notice. Consult your local IBM business contact for information on the product or services available in your area.
All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.
Information about non-IBM products is obtained from the manufacturers of those products or their published announcements. IBM has not tested those products and cannot confirm the performance,
compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
Prices subject to change without notice. Contact your IBM representative or Business Partner for the most current pricing in your geography.
This presentation and the claims outlined in it were reviewed for compliance with US law. Adaptations of these claims for use in other geographies must be reviewed by the local country counsel for
compliance with local laws.

2 SHARE Denver 8/10/2009 © 2003 IBM Corporation


Topics

Setting up zFS
Defining your first zFS
Migrating your Filesystems
Dynamic Replacement of Sysplex Root
Automount Migration Aids
Backing up the filesystems


zFS Statement of Direction Multi-filesystem aggregates

z/OS V1.7 is planned to be the last release to allow mounting zSeries File
System (zFS) file systems contained in multi-file system aggregates that
are to be shared across systems in a sysplex. IBM already recommends
that these multi-file system aggregates not be shared in a sysplex
environment. Once this support has been removed in the release after
z/OS 1.7, attempts to mount zfS file systems contained in multi-file
system aggregates will fail in a UNIX System Services shared file system
environment. Mounting zFS compatibility mode aggregates, which have a
single read-write file system per data set, will continue to be supported in
all environments.

In a future release, support for zSeries File Systems (zFS) multi-file
system aggregates will be withdrawn. When this support is withdrawn,
only zFS compatibility mode aggregates will be supported. (A zFS
compatibility mode aggregate has a single read-write file system per data
set.)



Setting up zFS



3 ways to grant Authority to do Filesystem Administration
1. Assign all administrators UID(0)
altuser chaight omvs(uid(0))
2. Provide READ access to the BPX.SUPERUSER Facility Profile
RDEFINE FACILITY BPX.SUPERUSER UACC(NONE)
PERMIT BPX.SUPERUSER CLASS(FACILITY) ID(CHAIGH1) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
3. Provide access to the UNIXPRIV profiles
SUPERUSER.FILESYS.PFSCTL AND
SUPERUSER.FILESYS.MOUNT
SETROPTS CLASSACT(UNIXPRIV)
SETROPTS RACLIST(UNIXPRIV)
RDEFINE UNIXPRIV SUPERUSER.FILESYS.PFSCTL UACC(NONE)
PERMIT SUPERUSER.FILESYS.PFSCTL CLASS(UNIXPRIV) ID(CHAIGH2)
ACCESS(READ)
RDEFINE UNIXPRIV SUPERUSER.FILESYS.MOUNT UACC(NONE)
PERMIT SUPERUSER.FILESYS.MOUNT CLASS(UNIXPRIV) ID(CHAIGH2)
ACCESS(UPDATE)
SETROPTS RACLIST(UNIXPRIV) REFRESH



Defining zFS in the BPXPRMxx member
Create a new BPXPRMxx member with the
following FILESYSTYPE statement in it.
/* FILESYSTYPE DEFINITION FOR DEFINING ZFS */
/* USING SETOMVS RESET=(ZF) */
FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM)
ASNAME(ZFS,'SUB=MSTR') PARM('PRM=(ST,&SYSNUMB)')

The ASNAME statement indicates the name of
the procedure to start and that it should not run
under JES control.
The PARM statement allows us to specify the
IOEFSPRM member as a true PARMLIB member.



Creating the zFS PROC
Copy the sample proc from IOE.SIOEPROC in to your PROCLIB.
You do not need to use the STEPLIB since you previously put the
LOADLIB in LINKLIST.

//ZFS PROC REGSIZE=0M
//*
//ZFZGO EXEC PGM=BPXVCLNY,REGION=&REGSIZE,TIME=1440
//*
//*STEPLIB DD DISP=SHR,DSN=hlq.SIOELMOD <--ZFS LOADLIB
//*IOEZPRM DD DISP=SHR,DSN=SYS4.PVT.PARMLIB(IOEFSPRM) <--ZFS PARM FILE
//*



Creating the zFS PROC

Use a system qualifier symbolic in the dataset name for the
IOEZPRM DD statement so you can use the same proc to
start zFS on every system while maintaining system unique
parameters.

//ZFS PROC REGSIZE=0M
//ZFSGO EXEC PGM=BPXVCLNY,REGION=&REGSIZE,TIME=1440
//* can step lib below to pickup zfs/smb/dfs from somewhere else

//*STEPLIB DD DISP=SHR,DSN=D10.OE.SIOELMOD,UNIT=3390,VOL=SER=D83OE4
//IOEZPRM DD DISP=SHR,DSN=USER.PLX2.PARMLIB(IOEFSP&SYSNUMB)
//* END


IOEFSPRM. What is it? Where is it? Why should you set
it up?

The IOEPRMxx is a list of processing options that
allow you to tune and configure zFS.
You can copy the IOEFSPRM from IOE.SIOESAMP in
to your parmlib concatenation or to the location you
specified in your zFS proc.
Using the PARM parameter of the FILESYSTYPE
statement is the preferred format.
You should set this up to:
1. Establish a location for zFS tuning parameters across IPLs.


IOEFSPRM options
• Sample IOEFSPRM file contents:
adm_threads=7
aggrfull(90,2)
aggrgrow=on
log_cache_size=10M
meta_cache_size=80M
sync_interval=45
user_cache_size=1000M
vnode_cache_size=10000
debug_settings_dsn=USER.PLX2.PARMLIB(IOEDEBUG)
trace_dsn=OMVS.PRV.TRACEOUT.S1
trace_table_size=32M

• F ZFS,QUERY,SETTINGS

IOEFSPRM options 2
• adm_threads - How many zFS tasks to use to
perform admin commands
• aggrfull – Controls when zFS reports that an
aggregate is low on space.
• aggrgrow – Indicates if dynamic grow on
• log_cache_size – Size of log file cache
• meta_cache_size – Size of metadata cache
• sync_interval – Number of seconds between
syncs


IOEFSPRM options 3
• user_cache_size – size of the cache used to store
the contents of user files.
• vnode_cache_size – number of files that can be
cached in zFS.
• debug_settings_dsn – name of dataset that
contains debug settings to debug errors
• trace_dsn – name of dataset that zFS should
write the in-memory trace contents to.
• trace_table_size – size of in-core trace table



Start zFS for the First time

From the console, issue one of the following
command:
SETOMVS RESET=(XX) or SET OMVS=(xx)
Note: xx equals the name of the BPXPRMxx that was set up previously

This will read the BPXPRMxx member and start the zFS
address space.
By adding this statement to your existing
BPXPRMxx member, zFS will start the next time
OMVS is restarted or the next time you IPL.



Defining your first zFS
Filesystem



Creating a Compatibility Mode Aggregate

There are two steps to create an aggregate
– Allocate a VSAM Linear Dataset
– Format the Dataset as a compatibility mode aggregate
and create a filesystem in the aggregate
3 ways to achieve the above steps
– Use JCL to allocate the dataset with IDCAMS then use
the IOEAGFMT to format the filesystem.
– Use zfsadm define and zfsadm format
– Use ISHELL



Mounting your new zFS filesystem

4 Ways to mount the filesystem
– Add the mount statements to BPXPRMxx
– Use the ISHELL mount command.
– Use the /usr/sbin/mount command in the shell.
– TSO Mount command
• MOUNT Filesystem(‘USSZFS.SHARE.ZFS’)
TYPE(ZFS) MODE (RDWR) MOUNTPOINT(‘/SHARE’)


ROOT and MOUNT statements in BPXPRMxx
Available
in z/OS 1.7
zFS can now be used as the root filesystem.
– ROOT
FILESYSTEM('OMVSSPA.SVT.SYSPLEX.ZFS')
TYPE(ZFS) MODE(RDWR) MKDIR(‘share')
– MOUNT FILESYSTEM(‘USSZFS.SHARE.ZFS')
TYPE(ZFS) MODE(RDWR)
MOUNTPOINT('/share')


Mounting the filesystem using ISHELL



Ready To Migrate



A Couple of Considerations before Migrating

1. Need to have DASD space available to
accommodate both the old and new filesystem
during the migration
2. Need to make the source filesystem unavailable
for updates during the migration.



Basic HFS to zFS Migration Steps

Define a new zFS aggregate
Create temporary directories (Mount points)
Mount both the HFS and zFS filesystems
Use pax to copy the HFS contents to the zFS
Unmount the filesystems
Remove the temporary mount points
Rename the filesystems as appropriate


Tools to migrate HFS data to zFS
Available
in z/OS 1.7

Enhancements to pax
– Modified to keep sparse files sparse when they are
copied
– Report errors reading a source file and then continue to
the next file to be copied
HFS will now be considered a generic file system
type that can mean either HFS or ZFS.
A new migration tool will be provided in the form
of an ISPF dialog.



My Example

4 filesystems
– USSZFS.SHARE.F1.HFS
– USSZFS.SHARE.FS.HFS
USSZFS.SHARE.F1.HFS is mounted on /share and is a 14G
Multi-Volume file system spanning 2 mod 9s
USSZFS.SHARE.F2.HFS is mounted on /share/erahs
USSZFS.SHARE.F3.HFS is not mounted
USSZFS.SHARE.FS.HFS is mounted on /share/nomig and we
will not be migrating it.


Start the tool by issuing BPXWH2Z –cv from TSO



Migrating the Sysplex Root


Migrating the Sysplex Root
Dynamic Replacement of Sysplex Root
– The replacement is initiated with an operator command on
any system in the shared file system configuration
– The sysplex root file system is dynamically replaced while it
is in use without disruption to active workloads
Benefit
– Migration of sysplex root file system to zFS file system
– Replacement of sysplex root file system PFS to the same or
different PFS (HFS or zFS)
Value
– Dynamic migration without a sysplex-wide IPL
– Transparent to applications and users on any systems in
sysplex

Migrating the Sysplex Root Cont.
Restrictions
– All systems in the sysplex must be at the V1R10 level.
– The current sysplex root file system PFS, and the new sysplex
root file system PFS, must be up on all the systems in the
shared file system configuration.
– The current sysplex root file system must be mounted as a read-
only file system.
– The systems that do not meet the requirements for this
migration action cannot join the sysplex during the sysplex root
file system migration processing, but they can join the sysplex
after the sysplex root migration has completed.
– The current sysplex root and the new sysplex root must be
either HFS or zFS in any combination. If the new sysplex root is
zFS, then it must be HFS-compatible.


Constraints Contd…
– The sysplex root or any directories on it cannot have been
exported by the DFS™ or SMB server.
– Remote NFS mounts of the sysplex root or any directories
on it are considered active use of the current sysplex root
file system.
– During the migration, the new zFS sysplex root file system
must not be HSM-migrated, mounted, or in use.
– Mount parameters are preserved during the migration or
replacement of the sysplex root file system of the same file
system type (PFS). They are dropped if the file system type
is different.
– Directories, data, files, and links are not copied from one
file system to another.


Migration Steps:
1. Ensure Current sysplex Root is mounted Read Only with No
Function Shipping Clients.
a. D OMVS,F,NAME=your.sysplex.root.name
2. Allocate and set up the new zFS sysplex root file system
a. Create a new zFS file system to be used as the new sysplex root
file system.
i. The UID, GID and the permission bits of the root directory in the new
sysplex root file system must be same as the root directory in the
current sysplex root file system.
b. Set up the active mount points and the symbolic links
a. 2 ways Manually or using the pax command
I. Mount new filesystem on temp mount point
II. cd /
III. pax -wr -pe -XCM ./ /newroot
IV. Unmount new file system

3. On any system in the shared file system configuration,
issue:
F OMVS,NEWROOT=new.root.file.system.name,COND=<Yes|No>
– The following values are accepted:
• COND=Yes - Proceed conditionally
– If the sysplex root contains any objects more than mount points and
symlinks that are in use, report the activities using BPXF245I
message and abort the processing. (Default)
• COND=No - Proceed unconditionally
– A disruptive operation. Report the activities using BPXF245I
message, and continue processing.
4. Update the TYPE parameter and name of the sysplex
root file system in the BPXPRMxx member of
SYS1.PARMLIB.



Migrating Automount File
Systems



HFS to zFS migration aids related to automount

• Support available Since z/OS Release 5:
• Automount was changed to set the file system type to either HFS or ZFS when either of
those is specified based on the type of data set that is being mounted.

• Support added in z/OS Release 7:
• Capability to specify the file system name with substitution place holders
was added. The place holder is /// and represents the string HFS or ZFS as
appropriate. Where ///is used, mount processing will first substitute ZFS and
check to see if the dataset exists and is not an HFS dataset. If this is the
case it will proceed with the name and direct the mount to ZFS. Otherwise
mount processing will substitute HFS.

• Note: To be able to use a single automount policy to manage both HFS and
zFS file systems, the zFS file system must be a compatibility mode zFS.
zFS multi-file system aggregates will not work with this function.


Automount generic entry example
The following is an example of a generic entry:
------ /etc/auto.master ------
/u /etc/u.map
------ /etc/u.map ---------
name *
type ZFS
filesystem OMVS.///.USER.<uc_name>
mode rdwr
duration 30
delay 10
parm FSFULL(50,5)



Backing up your Filesystems


Backup and Recovery

All file systems (HFS and zFS) can be backed up using ADRDSSU
– DFDSS backup of zFS is on an aggregate basis
Customers should not be using full volume dumps to backup file systems.
– Full volume dumps do not quiesce file systems. This dump process will run
asynchronous to file system write activity.
Rather, customers should use logical data set level dumps to ensure file
system integrity
– For HFS - can be dumped from any system in sysplex
– For zFS – must be dumped from owning system. Solved in Release 7.


Publications References
z/OS Distributed File Service zSeries File System Administration (SC24-5989)
zFS Concepts and zfsadm command
z/OS Distributed File Services Messages and Codes (SC24-5917)
IOEZxxxt messages and X’EFxxrrrr’ reason codes for zFS
z/OS UNIX System Services Planning (GA22-7800)
General Administration of z/OS UNIX file systems
z/OS UNIX Command Reference (SA22-7802)
confighfs command for HFS
z/OS MVS System Messages Volume 9 (IGF-IWM)
IGWxxxt messages for HFS
z/OS UNIX System Services Messages and Codes (SA22-7807)
X’5Bxxrrrr’ reason codes for HFS
z/OS Distributed File Service zSeries File System z/OS V1R7 Implementation (SG24-
6580)
– Redbook available at
– http://www.redbooks.ibm.com/redbooks/SG246580.html
– http://www.redbooks.ibm.com/redbooks/pdfs/sg246580.pdf

z/OS V1R10.0 Migration (GA22-7499-13)



Back up Material



HFS-compat Aggregate
• Every aggregate contains
a log file (size specified at
format time)
• Has exactly one r/w file
my.hfs.compat system
• Optionally can have a
clone of r/w file system

Log file • File system name matches
dataset name
my.hfs.compat • Initial quota is size of
Aggregate – (size of log
my.hfs.compat.bak file plus some control
structures)
• Specify at format time

zFS Cloning
a clone operation makes a point-in-time read/only backup of a zFS file
system in the same aggregate
– zfsadm clone OMVS.PRV.FS1
– IOEZ00225I File system OMVS.PRV.FS1 successfully cloned.
only metadata is copied, not user data
backup file system has the name of the read/write file system with
".bak" appended
later, when the read/write file system is modified, a new page is
allocated to maintain the backup
Deleting file systems (such as backups)
– zfsadm delete OMVS.USER.PAT.bak

metadata metadata
/
abc def


zFS Logging and Fast Mount Conversion (R7)
zFS is a logging file system
After system failure, next mount replays log to bring file system into consistent
state
IOEZ00397I recovery statistics for OMVSSP.SHARE.ZFS:
IOEZ00391I Elapsed time was 1505 ms
IOEZ00392I 135 log pages recovered consisting of 11091 records
IOEZ00393I Modified 119 data blocks
IOEZ00394I 9980 redo-data records, 2 redo-fill records
IOEZ00395I 13 undo-data records, 0 undo-fill records
IOEZ00396I 0 not written blocks
IOEZ00400I 0 blocks zeroed
R/O mount can fail if log needs to be replayed, but can be avoided
Must be mounted R/W, unmounted and then mounted R/O
Add romount_recovery=on to your IOEFSPRM
Conversion to fast-mount format (z/OS 7)
IOEZ00500I Converting MY.COMPAT for fast mount processing
IOEZ00518I Converting filesystem MY.COMPAT for fast mount



zFS Kernel Address Space
zFS kernel runs as
colony address space
USS zFS creates multiple
dataspaces to contain
contents of user files
zFS Log file buffers stored in
vnode a dataspace
User cache
metadata Main zFS address
space contains all other
Log cache
structures and
metadata cache



Modify Commands (Performance Stats)
• Query commands – show zFS performance
F ZFS,QUERY,ALL
F ZFS,RESET,ALL

• zfsadm command can be used for granularity
zfsadm query –system J40 –metadata

Metadata Caching Statistics
Buffers (K bytes) Requests Hits Ratio Updates
------------ ------------ -------------- ----------- -------- ------------
4096 32768 376849 342429 90.8% 87698
• RMF shows zFS kernel performance (z/OS 7)


Hints for a successful hfs to zfs migration

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Hints for a successful hfs to zfs migration

Semelhante a Hints for a successful hfs to zfs migration (20)

Mais de satish090909

Mais de satish090909 (7)

Último

Último (20)

Hints for a successful hfs to zfs migration