IASPs:
WHAT THEY ARE AND WHY
YOU NEED THEM ON IBM i
Agenda
•
•
•
•
•
•
What are they?
Why use them?
Role in PowerHA
Work Management Considerations
Database Considerations
ISV Implementations
Single Level Storage and Disks
Single Level Storage and Disks
Single Level Storage and Disks
IBM i Address Space with IASPs
Addresses for objects not in an IASP
Addresses for objects in an IASP
IASP Terminology
Types of ASPs
•
•
Basic ASP
– ASP numbers 2−32
– Linked to system ASP
– Cannot be independent varied on or off
– Will overflow into system ASP
– Primarily used to isolate journal receivers from the data in the system ASP
Independent ASP (IASP)
– Can be independently varied on and off
– Switchable between systems
– Identified by ASP number (33–255) and also by device description
– Three types of IASP
• UDFS
• Primary
• Secondary
Types of ASPs
• Basic ASP
– Can contain any IBM i objects
– All objects in the ASP are in the address space
• UDFS IASP
– Can only contain IFS objects
• Primary IASP
– Can contain IFS and library objects
– Accessed via SETASPGRP
– May have 0 or more secondary IASPs linked to it
• Secondary IASP
– Can contain IFS and library objects
– Linked to one Primary IASP
– Varied on and off with the Primary IASP
– Used to isolate journal receivers from the data
(similar to a Basic ASP)
What is an IASP?
• An IASP is a set of disk units which contain a collection of user objects
that can be taken offline or brought online independent of system activity
or other IASPs
• Availability of the IASP is controlled through varying on/off the
associated device description and “attaching” jobs/threads to the IASP
• IASP capability for IFS and IBM i objects included in the base operating
system since V5R2
• An IASP group is a Separate DB2 Database Instance
• IASPs can contain
– User-defined file systems (IFS)
– User libraries (some object types not supported, less each release)
– Duplicate library names with other IASPs (not SYSBAS)
Library Name Space
IASPs: Foundation for Long-Term, Scalable HA/DR
Independent ASPs (IASPs) offer:
– Uptime
• Shorter IPLs, leave non-critical IASPs offline
• Reclaim Storage (RCLSTG) by IASP
– Security
• Data and path encryption by ASP
– Archive
• Storage performance and cost by IASP
– Consolidation
• Meet compliance needs for isolation
• SaaS (Software as a Service)
• Reduce software licensing fees (single OS)
• Reduce number of OS upgrades
Foundation for all PowerHA and ACS* solutions
•
•
•
•
Switched IASPs
External Storage LUN Level Switching
IBM i PowerHA Geographic Mirror
PowerHA external storage copy services
Hess 2010
* Advanced Copy Services
Why use IASPs?
• Data Resiliency: HA/DR/Offline Backups
– Fundamental building block of hardware and OS-based high availability and
disaster recovery solutions
– Offline backups from replicated copy
– Replicated copies for testing or development
• Isolate or Consolidate: Multiple IASPs per system
– Multiple applications
– Multiple versions of same application
– Server consolidation
– Data archive
• Common
– Isolation of data associated with specific applications
– Increased granularity of management scope
IASPs in a Single System Environment
•
Can be any server
•
•
•
Isolate low-use data; bring online only
when needed
Reduce system start time
•
Manage save/restore by IASP
•
Reclaim storage by IASP
•
•
•
Divide data between multiple
databases
Isolate data
•
Isolate affects of disk failures
•
Application maintenance does not
affect entire system
Isolating Applications & Multiple Versions of Application
IBM i 7.1 PowerHA SystemMirror for i
An end-to-end solution for management of IBM i 6.1 and 7.1, DS6000,™
and DS8000® resiliency and replication technologies for HA, DR, and backups.
End-to-End Solution
PowerHA SystemMirror for i
(5770-HAS) – 7.1
IBM i Cluster Resource Services
HA Switchable Resources – IBM i option 41
DSCLI DS Command Line Interface
Switched
IASPs
• Internal or
external
storage
• IOA or
Tower **
Geographic
Mirroring
• Synch
• Any
storage
• Direct,
VIOS,
IBM I
hosted
storage
®
Geographic
Mirroring
• Asynch
• Any
storage
• Direct,
VIOS,
IBM i
hosted
storage
*** Switchable towers limited to POWER6 and prior hardware - avoid
Metro
Mirror
• Synch
DS6000
DS8000
only
• NPIV
Hess - 2010
Global
Mirror
• Asynch
• DS6000
DS8000
only
• NPIV
Flash
Copy®
• Snapshot
• DS6000
DS8000
only
• Space
efficient
• NPIV
LUN Level
Switching
• IASP is
located
inside DS
• DS6000
DS8000
only
IASP Benefits vs. Full System Replication
•
•
•
•
•
•
•
•
•
•
Faster switching, no IPL
No replicating OS, microcode, temp space
Target system is online—just switch the data
Better recovery—just data recovery steps
Reduced bandwidth requirement
Integrated with clustering
Improved flexibility and masking planned outages
Much simpler, automated switch process
Consolidate workloads using separate IASPs
Less impact for planned outages (PTF and OS upgrades)
Considerations
• Processes will need to be in place for synchronizing necessary
SYSBAS objects and settings
• May need changes to processes such as change management,
user and security management, system monitoring, etc.
Additional Characteristics of IASPs
• Each ASP group represented as a separate DB2 database instance
• Duplicate library names allowed within different ASP groups on the same system
• Duplicate library names not allowed between SYSBAS (ASPs 1-32) and any IASP
on the system
• Each job or thread always has visibility to objects in SYSBAS but is “attached”
to, at most, one ASP group at a time
• IASPs not available after an IPL, they must be varied on
• IFS for an IASP mounted to the root as /<IASPNAME> at vary on
• RDBDIRE for IASP DB activated at vary on
Most of the work associated with IASP enablement
involves getting users and jobs “attached” to the appropriate IASP.
IASP Supported Objects Types as of IBM i 6.1 and 7.1
*ALRTBL
*DTAQ
*JRNRCV
*PAGDFN
*SPLF
*BLKSF
*FCT
*LIB
*PAGSEG
*SQLPKG
*BNDDIR
*FIFO
*LOCALE
*PDG
*SQLUDT
*CHRSF
*FILE
*MEDDFN
*PGM
*SRVPGM
*CHTFMT
*FNTRSC
*MENU
*PNLGRP
*STMF
*CLD
*FNTTBL
*MGTCOL
*NODGRP
*SVRSTG
*CLS
*FORMDF
*MODULE
*PSFCFG
*SYMLNK
*CMD
*FTR
*MSGF
*QMFORM
*TBL
*CRQD
*GSS
*MSGQ
*QMQRY
*USRIDX
*CSI
*IGCDCT
*NODGRP
*QRYDFN
*USRQ
*DIR
*JOBD
*NODL
*SBSD
*USRSPC
*DTAARA
*JOBQ
*OUTQ
*SCHIDX
*VLDL
*DTADCT
*JRN
*OVL
*SPADCT
*WSCST
ASP Unsupported Object Types as of IBM i 7.1
Security Objects: objects affecting security remain in SYSBAS
Legacy Objects: Non-strategic objects (i.e *36 must remain in SYSBAS)
Configuration Objects: System configuration objects have no use on another system
*AUTHLR
*DDIR
*IMGCLG
*NWSD
*AUTL
*DEVD
*IPXD
*PRDAVL
*CFGL
*DOC
*JOBSCD
*PRDDFN
*CNNL
*DSTMF
*LIND
*PRDLOD
*COSD
*EDTD
*MODD
*SOCKET
*CRG
*EXITRG
*M36
SSND
*CSPMAP
*FLR
*M36CFG
*S36
*CSPTBL
*IGCSRT
*NTBD
*RCT
*CTLD
*IGCTBL
*NWID
*USRPRF
Objects Monitored and Replicated by PowerHA
SystemMirror for i
•
Authorization list (*AUTL)
•
Classes (*CLS)
•
Ethernet line descriptions (*ETHLIN)
•
•
Independent disk pools device descriptions
(*ASPDEV)
Job descriptions (*JOBD)
•
Network attributes (*NETA)
•
Network server configuration for connection
security (*NWSCFG)
Network server configuration for remote systems
(*NWSCFG)
Network server configurations for service
processors (*NWSCFG)
Network server descriptions for iSCSI connections
(*NWSD)
•
•
•
•
•
Network server descriptions for
integrated network servers (*NWSD)
Network server storage spaces
(*NWSSTG)
Network server host adapter device
descriptions (*NWSHDEV)
Optical device descriptions (*OPTDEV)
•
Printer Device (*PRTDEV)
•
Subsystem descriptions (*SBSD)
•
•
System environment variables
(*ENVVAR)
System values (*SYSVAL)
•
Tape device descriptions (*TAPDEV)
•
Token-ring line descriptions (*TRNLIN)
•
TCP/IP attributes (*TCPA)
•
User profiles (*USRPRF)
•
•
Creating an IASP
1. Select Configuration and Service from IBM System Director Navigator
2. Select Disk Pools
3. From the Select Actions menu, select New Disk Pool
4. Follow the wizard’s instructions to name disk pool, select disk pool type,
and add disk units to a new disk pool
5. Record the relationship between the independent disk pool name and
number
IASP Enablement Considerations
The majority of changes needed
to support IASPs are work
management oriented.
IASP migration can generally be
transparent to most end-users
and application developers.
• Location of application objects
– Data, journals, journal receivers
– IFS objects
– Programs and environment definition objects
• If three tier product, preferably Apps in SYSBAS
• If not three tier product, preferably Apps in IASP (for upgrade and ease of use)
– Considerations for object types not supported in IASPs
• Work Management related changes
• Application run time considerations
– Database connectivity—DDM, JDBC, ODBC
– Commitment control scope, join logical files
• Additional considerations for multiple IASPs on a system
Location of Application Objects
*SYSBAS
• Objects needed at system startup, or when an IASP is offline
– Startup program
– Objects referenced in most system values and network attributes,
including QSYSLIB & QSYSLIBL
– Exit programs
– System monitoring software
– System management utilities
• Objects referenced by a subsystem not attached to an IASP
– JOBQs, routing programs, and JOBDs
Location of Application Objects
*SYSBAS
• Some objects referenced by USRPRFs
– JOBD
– MSGQ
– Attention program
• Objects supported in an IASP, but not usable there
– SBSD
– CLS and JOBD for interactive jobs or jobs in SBS not attached to IASP
Location of Application Objects
IASP
• Database objects & application data
– Files, journals, journal receivers
– Journals and receivers must be in same ASP group as objects being journaled
– Permanent SQL objects cannot span IASP boundaries
– The less database objects in SYSBAS, the better for performance and ease of
management
Location of Application Objects
IASP
• Application IFS objects and directories
– INLASPGRP on JOBD, and SETASPGRP command do not affect IASP
IFS visibility
– Access via hierarchical structure
– Single IASP: create symbolic links in old *SYSBAS IFS location,
pointing to new location in IASP
– Multiple IASPs: Make application “root agnostic” and set environment
variable for application root directory
– Check any symbolic links remaining in SYSBAS to ensure they
reference the correct location
– Change references to IFS objects moved to the IASP if symbolic
links not created, i.e. /QSYS.LIB/…
Location of Application Objects
• Program objects in *SYSBAS or in IASP?
– Single or multiple IASPs on system?
– Shared copy of application or single?
– Unsupported object types for IASP?
– No duplicate library names in IASP and SYSBAS
• Create new companion libraries for library content to be
split between *SYSBAS and IASP
Work Management Changes Required
•
Certain system values cannot reference objects in an IASP
– QACGLVL, QATNPGM, QAUDCTL, QCFGMSGQ, QCONSOLE, QCTLSBSD, QIGCCDEFNT,
QINACTMSGQ, QPRBFTR, QPRTDEV, QPWDVLDPGM, QRMTSIGN, QSRTSEQ, QSTRUPPGM,
QUPSMSGQ, QUSEADPAUT
•
These network attributes cannot reference objects in the IASP
– ALRFTR, DDMACC, DFTMODE, MSGQ, OUTQ, PCSACC
•
All objects referenced in user profiles must exist in *SYSBASE, except
– Initial programs or initial menus
– Output queues
•
JOBDs needed by the system should be moved to *SYSBAS
–
–
–
–
•
•
Remove library qualified references
Make any needed updates to INLLIBL
JOBDs needed by the system should not have INLASPGRP set
JOBDs accessing IASP data should have INLASPGRP set
JOBQ and SBSD can exist in IASP, but should be copied to *SYSBAS
QSYSLIBL & QUSRLIBL cannot contain libraries in an IASP
IASP Database Considerations
• Views, tables cannot span IASP boundary
– No join logicals over physicals in different IASPs or IASP and
SYSBAS
• Commit block cannot span IASP boundary
– If connected to IASP DB, cannot commit changes against both IASP
and *SYSBAS (except QTEMP)
– V5R4 and earlier – commit definition scoped to IASP
– IBM i 6.1 – commit definition scoped to IASP or SYSBAS but not both,
based on object of first commit action
– If connected to IASP, can use remote DRDA connection to SYSBAS
and 2-phase commit but not between IASPs
IASP Database Considerations
• RDB name for IASP
– Single IASP on system, may want to give the old *LOCAL RDB name
to the IASP instead
• DDM files
– Configure to use RMTLOCNAME(*RDB) and RDB(iasp DB name)
• New permanent libraries or collections for application:
– CRTLIB LIB(library-name) ASP (*ASPDEV) ASPDEV (asp-device-name)
– Create collection – default for ASPDEV is the current database
IASP Database Considerations
• Static SQL with multiple IASPs
– When a static SQL program is run, an access plan is created and stored
with the program. If the SQL program is located in *SYSBAS, a job/thread
with IASP1 in its namespace will create an access plan for data in IASP1.
When a job/thread with IASP2 in its namespace runs the SQL program,
the existing access plan is invalid, so a new access plan will be created
and stored in the program
– Create separate static SQL applications /packages in each IASP for best
performance.
IASP Database Considerations
• JDBC, ODBC, FTP connectivity
– Use JOBD of USRPRF to set INLASPGRP where possible
– JDBC and ODBC have parameters to specify the Database connection to allow
for connection to an IASP
• FTP - Use the "quote rcmd xxxxx" to SETASPGRP for jobs that cannot have the
*JOBD set the namespace
• JDBC - parameter in the i Java Toolbox to connect to IASP database
– DriverManager.registerDriver(new AS400JDBCDriver());
AS400JDBCDataSource ds = new AS400JDBCDataSource(“SYS1");
ds.setUser("xxxxxxxx");
ds.setPassword("yyyyyyyy");
ds.setNaming("sql");
ds.setDatabaseName(“IASP1");
IASP Database Considerations
• ODBC – i Access for Windows ODBC driver parameter to connect to IASP
database
SQLAllocHandle(…);
SQLSetEnvAttr(…);
SQLAllocHandle(…);
SQLDriverConnect(hdbc, NULL,
"DSN=myDSN;DATABASE=IASP1;UID=myUID;PWD=myPWD;",
SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT) ;
Other Considerations for Multiple IASPs
• Can use DRDA and DUW to connect to data in one IASP from programs in
another IASP
• Remember, each environment will share SYSBAS!
– Shared QUSRSYS, QGPL
– Shared LPPs
– Shared QSYSOPR
• A uniquely-named library for each IASP should be created in *SYSBAS for:
– JOBDs, SBSDs, CLSs, etc.
• Place library in front of QGPL in the user's library list
Typical IASP Migration Project Outline
• Proof-of-concept on subset of applications
• Education on IASP enablement considerations
• Set up test environment where IASP enablement changes will be performed
and tested
• Perform and test all process, application, and work management changes for IASPs
• Integrate most changes into non-IASP production system
• Determine production migration strategy based on available hardware and
replication options
• Test migration process on sandbox environment, if possible
• Perform any necessary education to support personnel and users on process
change, etc.
• Execute production migration
IBM i IASP Related Enhancements
• Support JOBQs in IASP
– Allows applications to run with IASP with fewer changes
– Job queue entries not persistent
• Support for associating an IASP with a subsystem description
– Parameter added to subsystem description object
– IASP must be available for subsystem to be active
• Support for pure SYSBAS transaction under commitment control when
connected to IASP
• Encryption support
• Support for commitment control for a transaction that uses files in both
SYSBAS and the IASP
• Ability to start/stop encryption on an existing IASP
Quiesce Function
• Suspends transactions & operations to ensure that as much in-flight data as possible is
written to disk
– Places transactions at database boundaries if possible
– Use commitment control for maximum effectiveness
• Operates against individual IASPs or *SYSBAS
• Useful prior to FlashCopy of *SYSBAS, FlashCopy of IASP, detaching of mirror copy,
switching of mirror copy
• Command or API support
– CHGASPACT
*SUSPEND,
*RESUME, *FRCWRT
– QYASPCHGAA API –
Change ASP Activity
Performing a FlashCopy: http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/index.jsp?topic=/rzaig/rzaigmanageiasp.htm
Customers Using IASPs
• Many, many successful IASP implementations worldwide
– Most for HA solutions
– Most have single ASP group per system/partition
• Wide variety of industries and sizes
– Major financial institutions worldwide
– Various international government holdings
– Telecommunications corporations worldwide
– Major transportation and shipping companies
– Infrastructure and facilities providers
• More customers are doing this every day!
• IASP enablement can take a few days or a few months depending
on architecture of applications, configuration options, testing,
documentation, etc.
Sample of ISVs with Announced IASP Support
•
Help/Systems (specific by module,
contact product support for further
details)
•
RJS Software Systems
•
SAP
•
Shield Advanced Solutions
•
DDL Systems
•
SilverBlaze Solutions
•
Entrack
•
Silverlake
•
F. Logic
•
Soft Landing
•
INITECHS, LLC
•
SPSS
•
Lawson M3
•
Vision Solutions
•
Manhattan
•
•
Oracle – JD Edwards World and
Enterprise One
Many others have been implemented in
clients (MAPICS, IBS, GMI, etc.)
•
Quadrant Software
IASPs Resources
• Publications: www.redbooks.ibm.com
– IBM i 6.1 Independent ASPs A Guide to Quick Implementation of Independent
ASPs – SG24-7811
– Implementing SAP Applications on the IBM System i with IBM i5/OS - SG247166-00
• Websites:
– PowerHA Website: www.ibm.com/systems/power/software/availability/
– Infocenter: http://publib.boulder.ibm.com/iseries/
• Education & Workshops: http://www.ibm.com/servers/eserver/iseries/service/itc
– AS541 / OV541: High Availability Clusters (PowerHA) and Independent Disk
Pools for IBM I (4 days)
– IASP for ISV Workshop (1.5 days)
Resource: Formal Education
• IBM PowerHA for i
Clustering and Independent Disk Pools Implementation (4 days)
– AS541 Classroom
– OS541 Instructor led online
• Visit http://ibm.com/training/us
• Search for OS541 or AS541 in course catalog to enroll
Learn to:
- Create disk pools (IASP) and place highly available objects
into them Use the methods that allow users to access
information in a disk pool
- Manage an environment with multiple disk pools (server
consolidation)
- Define an availability Environment using 5761-HAS
PowerHA for i
- Compare and contrast the different options available for
implementation under 5761-HAS PowerHA for i: using
- Geographic Mirroring, Metro Mirror using IBM System Storage
- Copy Services, and Global Mirror using IBM System Storage
www.ibm.com/servers/eserver/iseries/service/itc
- Copy Services
- Make data and applications continuously available
- Create and manage an i family cluster
- Use the fundamentals of problem determination and
correction in an i cluster
- Create a geographic mirror disk pool
- Establish and manage an environment with highly available
application objects using a geographic mirror disk pool
- Maintain consistent copies of key system objects like user
profiles through operating system cluster resource services
IASP Workshop: Customized Migration Assistance
• IASP Enablement Workshop
– Lab Services personnel will assist you with loading, evaluating, modifying, and testing
your own application in an IASP sandbox environment
– Use IBM i partitions in Rochester, at your own site, or at a customer’s site
– Usually 4.5 days in length
– Combination of formal education and hands-on enablement activities—working with
your application!
– Objective is to provide sufficient education and experience to size and scope the
complete IASP-enablement project for your application while getting a head start on
the process
• Additional IASP enablement assistance available
• Contact Lab Services to schedule a customized workshop
Questions?
PRESENTATION RECAP:
•
•
•
•
•
•
What are they?
Why use them?
Role in PowerHA
Work Management Considerations
Database Considerations
ISV Implementations
FlashCopy for IBM i
Agenda
• FlashCopy Defined
• How FlashCopy Works
• FlashCopy Options
• FlashCopy Space Efficiencies
• Automation Opportunities
What is FlashCopy?
• A function that occurs within a SAN storage device
• Provides a point-in-time copy of the contents of disk volumes
• Can be a full system or an IASP
• Many options for the copy process available
• Differences between V7000 and DS8000
Save While Active
Before starting a discussion of FlashCopy, let’s review a more familiar
point-in-time copy: Save While Active
1.When a Save While Active is started, a sync point is reached before
the save operation starts (this may take some time)
2.The objects to be saved are marked for processing by the save
3.Users may begin to use the objects being saved
4.If an object is changed, before it has been saved, the original
information is moved to a shadow area
5.When the save operation reaches the changed information,
the original information is saved from the shadow area
FlashCopy Basics
• A FlashCopy takes place within a single storage unit—you cannot flash
from one storage device to another
• FlashCopy is a physical copy of the disk unit—the storage unit has no
concept of objects
• Logical saves (SAVOBJ, SAVLIB, etc.) can be taken from the FlashCopy units
• There are many different options when you take a DS8000 FlashCopy
• A system or IASP may be quiesced in order to reach a sync point
(usually a matter of seconds)—highly recommended
• Two basic forms of FlashCopy
– FlashCopy with copy
– FlashCopy no copy
FlashCopy with Copy
The contents of all disk units in the FlashCopy operation are copied
from source volumes to target volumes.
Source Volumes
Target Volumes
FlashCopy with Copy
Force all changes from main storage to the source volumes and issue the
FlashCopy command. A bitmap with all zeroes is generated by the DS.
Source Volumes
Bitmap
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy with Copy
Each track is copied from the source volumes to the target volumes. As the
tracks are copied, the corresponding bit in the mask is changed from 0 to 1.
Source Volumes
Bitmap
1111111111
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy with Copy
Since both the source and target volumes are available for use, the bitmap directs
users of the target volumes to the location of the information being used:
•
•
1 = use the target volume
0 = use the source volume
Source Volumes
Bitmap
1111111111
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy with Copy
Since the source volumes are in use, what happens when a track that
hasn’t been copied is changed in the source volumes?
Source Volumes
Bitmap
1111111111
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy with Copy
Before the change is written to the source volume, the original track
is copied to the target volume and the corresponding bit is set to 1.
Source Volumes
Bitmap
1111111111
0000000000
0000000000
0000000000
0000100000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy with Copy
Since the bit of the changed track is set to 1, the users of the target volumes
know that the correct data is in the target—kind of like Save While Active
knowing to use the shadow area.
Source Volumes
Bitmap
1111111111
0000000000
0000000000
0000000000
0000100000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy with Copy
Eventually, all tracks are copied from the source to the target. At this point, the
default FlashCopy operation is complete and the bitmap is removed. There is
no longer a relationship between the source and target volumes.
Source Volumes
Bitmap
1111111111
1111111111
1111111111
1111111111
1111111111
1111111111
1111111111
1111111111
Target Volumes
FlashCopy with Copy
Now you have a full copy of the original source volumes to use!
Source Volumes
Target Volumes
FlashCopy with Copy
What happens when a track that hasn’t been copied is changed in the
target? The change is written to the target volume and the bit is set to 1.
The track will not be copied from the source to the target.
Source Volumes
Bitmap
1111111111
0000000000
0000000000
0000000000
0000100000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy no Copy
Only the contents of changed tracks on disk units in the FlashCopy
operation are copied from source volumes to target volumes.
Source Volumes
Target Volumes
FlashCopy no Copy
Force all changes from main storage to the source volumes and issue the
FlashCopy command. A bitmap with all zeroes is generated by the DS.
Source Volumes
Bitmap
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy no Copy
No background copy of source tracks to target tracks is performed.
Source Volumes
Bitmap
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy no Copy
When a track in the source volumes is being changed, the track is copied
to the source, and the corresponding bit is set to 1.
Source Volumes
Bitmap
0000000000
0000000000
0000000000
0000000000
0001000000
0000000000
0000000000
0000000000
0000000000
Target Volumes
FlashCopy no Copy
Only the original contents of changed tracks are moved to the targets.
Source Volumes
Bitmap
0000000000
0010000000
0000000010
0000000000
0001000000
0000000000
0000000000
0000100000
0000000000
Target Volumes
FlashCopy no Copy
Changes to the target system cause the copy bit to be set to 1. This will
prevent a change to the source from overwriting the target change with
original data.
Source Volumes
Bitmap
0000000000
0010000000
0000000010
0000000000
0001000000
0000000000
0000000001
0000100000
0000000000
Target Volumes
FlashCopy no Copy
• The relationship between the source and target remains in place until
all source tracks have been changed (highly unlikely).
• Usually the flash copy relationship is explicitly removed when the user
has finished using the targets.
• This form of FlashCopy is typically used to save objects on a partition
that is different from the production partition.
• Since few of the tracks are likely to change during the save operation,
there may be contention for access to the source volumes—usually the
interference is not noticeable.
FlashCopy V7000
• Source and target volumes are specified using a mapping operation
• Target volumes must be identical in size to the source volumes
• Multiple volumes may be placed in a consistency group
– Similar to a DS FlashCopy of multiple volumes
– Provides a point-in-time copy for all volumes in the consistency group
• Rather than copying tracks, V7000 copies “grains”
– User specifies the size of a grain
– May be 64K – 256K
– Default is 256K
• FlashCopy on V7000 is with copy
Other DS8000 FlashCopy Options
• Persist: keep a FlashCopy relationship in place
• Record: keep track of changes made since the last point in time
copy
– Often used in conjunction with the persist option
• Target inhibit: prevent writing to the target volumes
– Do not use with IBM i
Using Persist and Record
• Most often used to update target volumes copied using
FlashCopy with copy
• At the completion of the full copy from source to target,
the bitmap between source and target is retained
• Because record is also specified, a second bitmap is used to
record the changes on the source volumes and target volumes
• At the next instance for FlashCopy, a variation called
Resync flash is used
Resync Flash
• Changes to tracks in both sets of volumes are recorded in the bitmap
• Remember that our original flash was a point-in-time flash of the
source volumes
Source Volumes
Bitmap
0010000000
0010000000
0000000010
0000000100
0001000000
0000000001
0000000000
0000100000
1000000000
Target Volumes
Resync Flash
In order to restore the changed tracks in the target to the values in the original
FlashCopy, the changes will be “backed out” using the unchanged pages in
the source.
Source Volumes
Bitmap
0010000000
0010000000
0000000010
0000000100
0001000000
0000000001
0000000000
0000100000
1000000000
Target Volumes
Resync Flash
• Full copy of source volumes must be completed
• When a resync flash is issued, a second bitmap of all zeroes
is created
• Changes that occur while the resync flash is taking place are
recorded in the second bitmap
– Changes to a track in a source volume will cause the original track
to be written to the target
– Changes to a track in a target volume are more complicated
Resync Flash—Changes to Target Volumes
Condition 1 – the track is not scheduled to be copied during the resync flash
•The change is made to the target volume and the corresponding bit in the change recording
bitmap for the next resync is set to 1.
•The track will not be copied from the source volume to the target volume.
Condition 2 – the track is scheduled for resync and has already been copied from the source
•The track on the target is changed.
•The corresponding bit in the change recording bitmap for the next resync is set to 1.
Condition 3 – the track is scheduled for resync but has not yet been copied from the source
•The track on the target is changed and the corresponding bit in the change recording bitmap
for the next resync is set to 1.
•The track will not be copied from the source volume to the target volume.
Why Use FlashCopy
• Clone an IASP or system using FlashCopy with copy
• Use the target volumes for save operations
– IPL the full system flash with special handling
• System name
• IP addresses
– Vary on a FlashCopy IASP
• In the event that the source volumes become mucked,
the target volumes provide a quick recovery to the point
in time of the FlashCopy
Saving Objects from a FlashCopy
• The save is taking place on a different system
• An IBM i has an operating system option for saving from a full system
– The production system will not have the date of last save changed
– IBM i will adjust the catalog to “spoof” a save from the production system
• Saving from an IASP attached to a different partition is much easier
– The save is still done on a different system/partition
– IBM i has an option to update the last saved information in the source IASP
• Lab Services Toolkit provides an automated process for both full
system and IASP FlashCopy
Space Efficient FlashCopy
• To this point, the target volumes in either a DS8000 or a V7000 have
been the same size as the source volumes (fully provisioned).
• Do we need fully provisioned targets?
– FlashCopy no copy will not copy everything
– Often times, target volumes have a short life span, e.g., they exist only until a
save operation is complete
• In a DS8000, we can use targets that are smaller than the source
volumes (thin provisioning).
Space Efficient FlashCopy
The DS8000 targets are configured differently.
Source Volumes
Space is allocated for the target volumes.
Allocated space is a percentage of the space for the source volumes.
Choose a percentage that will not overflow during the save operation.
Space Efficient FlashCopy
The DS8000 targets are configured differently.
Source Volumes
Target Volumes
“Virtual” target volumes are defined
to be the same size as the source
volumes.
There is a mapping between the
tracks of the target volumes and the
actual disk space used for the
FlashCopy.
Space Efficient FlashCopy
The DS8000 targets are configured differently.
Source Volumes
Target Volumes
A change to a track in the source
causes the original track to be
written to the allocated area.
The bitmap between source and
target indicates that the original
page is in the “virtual” target disk.
Space Efficient FlashCopy
The DS8000 targets are configured differently.
Source Volumes
Target Volumes
When a user of the target volumes
accesses the changed page, the
bitmap directs the read to the target
volume.
The changed track in the target
volume is mapped to original
information in the allocated area.
FlashCopy Summary
• Contained within a single storage unit
• A fast way to establish a point-in-time image of volumes
(disk units) in IBM i
• Copies are physical, not logical i.e., there is no way to restore
individual objects from a FlashCopy
• Can make full system or IASP copies
• Save operations can be performed on the target units
• Space efficient FlashCopy reduces storage requirements
Resources
• Redbooks
–
–
–
–
–
SG24-7938 Overview of the IBM Storwize V7000
SG24-8886 IBM System Storage DS8000: Architecture and Implementation
SG24-7120 IBM i and IBM System Storage
SG24-7103 IBM System Storage Copy Services and IBM i
SG24-6788 IBM System Storage DS8000 Copy Services for Open Systems
• IBM Education
– AS541 IBM PowerHA for IBM i, Clustering, and IASP Implementation (4 days)
– OS830 System Storage DS6000 and DS8000 on I (3 days)
• STG Lab Services
– IASP Copy Services Toolkit (2 versions)
– Full System FlashCopy Toolkit
Questions?
PRESENTATION RECAP:
•
FlashCopy Defined
•
How FlashCopy Works
•
FlashCopy Options
–
With and without copy
–
Resync flash
–
Persist and record
–
Running saves
•
FlashCopy Space Efficiencies
•
Robot automation opportunities
IASP and FlashCopy for IBM i
Review of IASP with FlashCopy
IBM i
Production Partition
IBM i Partition for Backups
IASP Source Volumes
IASP Target Volumes
Using the IASP Target Volumes
• Target volumes are not immediately useable in a
second partition
• The production partition and backup partition must be in
• An IBM i cluster
• The same device domain in the cluster
A cluster consists of two or more systems that are capable
of ‘sharing’ resources
A device domain allows the resources to use ‘shared’
resources
In this implementation, the IASP is the ‘shared’ resource
Using IASP with FlashCopy
Cluster
Device
Domain
IBM i
Production Partition
IBM i Partition for Backups
IASP Source Volumes
IASP Target Volumes
Using IASP with FlashCopy
Cluster
Device
Domain
IBM i
Production Partition
IBM i Partition for Backups
IASP Source Volumes
IASP Target Volumes
Using IBM i Commands with IASP with FlashCopy
• Run the ADDASPCPYD command to identify the source
and target volumes in the DS
• On the production partition run the command CHGASPACT
to force pages to the disk
• On the partition used for backups:
• Run the STRASPSSN to initiate the FlashCopy
• Vary on the IASP
• Backup your information
• Run the CHGASPSSN to detach the source and target
volumes
• For future FlashCopy operations repeat steps two and 3,
but replace the STRASPSSN command with a
CHGASPSSN command to reattach the source and target
volumes
Using Lab Services Toolkit with IASP with FlashCopy
• Define Source and Target volumes using the toolkit
interface
• Define the type of FlashCopy to perform
• Run the toolkit command on the backup partition –
many of the manual commands used in the IBM i
command implementation are done for you by the
toolkit
• Specify default responses to any toolkit messages