Understanding IBM i HA Options

1 | Understanding IBM i HA Options
Understanding
IBM i HA Options
Becky Hjellming, Director, Product Marketing
John Dunn, Senior Product Manager

• Technical differences between hardware replication and
journal-based replication
• Practical differences between hardware replication and
journal-based replication
• Considerations to keep in mind when considering cloud-
hosted DRaaS
• How to increase confidence in your HA solution
• Questions to ask when considering HA options
Today’s Topics
All the HA claims sound
the same. What’s the
difference?
On-prem or cloud-
hosted? How do I
choose?
What can I do to
be sure we are
switch ready?
| Understanding IBM i HA Options2

Hardware and Journal-Based
Replication Technology

Technology Considerations
1. Underlying architecture
2. Replication and recovery point
3. Bandwidth usage
4. Online or offline target
5. Application and data requirements
6. Damaged object replication
7. Access path recovery
8. Topology flexibility
Weighing HA
Options

Underlying Architecture
• IBM storage provides the underlying mechanism for
SAN to SAN replication
• Sectors written to the source SAN are replicated to
the tightly coupled target SAN
• Only applications and data in IASPs are replicated
• Switching is done by attaching storage to a secondary
server and recovering to that server
Storage Replication
SAN SAN

Underlying Architecture
• IBM storage provides the underlying mechanism for
SAN to SAN replication
• Sectors written to the source SAN are replicated to
the tightly coupled target SAN
• Only applications and data in IASPs are replicated
• Switching is done by attaching storage to a secondary
server and recovering to that server
• IBM Journaling provides the underlying replication
mechanism for Journal-Based Replication solutions
• Replication is done server to server
• Supports internal, external or mixed storage
• Switching is done to a live target without recovery
steps
Storage Replication Journal-Based Replication
Server Server
SAN SAN

Replication and Recovery Point
• IBM i OS uses memory as a cache
• Data may be either in memory or on disk
• Data is not protected until written to disk
• Unknown time after transaction completes
• Results in non-zero, unpredictable RPO
• Journaling is required with Storage Replication
• Journaling saves data to disk before transactions complete
• Provides transaction integrity and near-zero RPO
Storage Replication
Server
Storage
No memory to memory
transfer
Disk sectors
Server
Storage

Replication and Recovery Point
• IBM i OS uses memory as a cache
• Data may be either in memory or on disk
• Data is not protected until written to disk
• Unknown time after transaction completes
• Results in non-zero, unpredictable RPO
• Journaling is required with Storage Replication
• Journaling saves data to disk before transactions complete
• Provides transaction integrity and near-zero RPO
• Journaling eliminates issues associated with
delayed disk writes due to memory caching
• Journaling saves data to disk and replicates it before
the end of each transaction
• Asynchronous and synchronous options support
near-zero or zero RPO
Server
Storage
No memory to memory
transfer
Disk sectors
Server
Storage
Journal EntriesServer
Storage
Server
Storage

Bandwidth Usage
• The bandwidth needed for SAN replication is
over twice that needed by logical replication
• Journaled data is replicated
• All sectors (files, objects and temporary files) are
replicated again when written to disk
• Initial synchronization and any re-sync processes are
also bandwidth intensive
Storage Replication
journals
data
Sector Replication
Server
SAN
Server
SAN

Bandwidth Usage
• The bandwidth needed for SAN replication is
over twice that needed by logical replication
• Journaled data is replicated
• All sectors (files, objects and temporary files) are
replicated again when written to disk
• Initial synchronization and any re-sync processes are
also bandwidth intensive
• Journaling replicates only changed data
• Bandwidth can be further reduced through
• Filtering non-critical data from replication
• Journal optimizations
• RJ filtering (Option 42 – HA Journal Performance)
• JRNMINDTA
• Hardware compression
journals
data
Sector Replication
Server
SAN
Server
SAN
objects
Logical Replication
Server Server

Online or Offline Target
• SAN to SAN replication does not support
a live backup server
• IASP must be varied on to a server to be used
• Some users add flash technology to storage
replication
• Provides only a point-in-time copy of the data
• Must be varied on to a server to be used
• Quickly becomes stale as flashes are no real time
Storage Replication
Server SAN SAN
Server

Online or Offline Target
• SAN to SAN replication does not support
a live backup server
• IASP must be varied on to a server to be used
• Some users add flash technology to storage
replication
• Provides only a point-in-time copy of the data
• Must be varied on to a server to be used
• Quickly becomes stale as flashes are no real time
• The backup server is always current and live in a
journal-based replication solution
• The backup server may be used to off-load work
from the production server, including
• Reporting
• BI
• Testing
• Tape saves
• More
Server SAN SAN
Server
Server Server

Application and Data Requirements
• Applications must run in an IASP to be protected by
Storage Replication
• Effort to convert and test applications can be substantial
• Application data must also reside in an IASP to be
protected by Storage Replication
• Application data in SYSBAS is not protected
• Admin Domain does not fully protect SYSBAS
Storage Replication

Application and Data Requirements
• Applications must run in an IASP to be protected by
Storage Replication
• Effort to convert and test applications can be substantial
for some applications
• Application data must also reside in an IASP to be
protected by Storage Replication
• Application data in SYSBAS is not protected
• Admin Domain does not fully protect SYSBAS
• No application changes required
• Journal-Based Replication is independent of the
underlying storage configuration
• Journal-Based Replication can replicate to and
from SYSBAS, ASP, IASP or mixed environments
• Applications for every vertical are supported (e.g.
banking, retail, logistics, health, etc.)

Damaged Object Replication and Repair
• Objects damaged on the source system’s storage will
be propagated to the target
• Damaged objects detected during the IPL or vary on
are marked by the OS
• Damaged objects will require recovery from backup
media, negatively impacting both RTO and RPO
Storage Replication

Damaged Object Replication and Repair
• Objects damaged on the source system’s storage will
be propagated to the target
• Damaged objects detected during the IPL or vary on
are marked by the OS
• Damaged objects will require recovery from backup
media, negatively impacting both RTO and RPO
• Journal-Based Replication cannot propagate
damaged objects from the source to the target
• Journal-Based Replication audits ensure objects
damaged on either the source or target are
detected, repaired and reported
• Live target data is always ready for switch without
added object recovery steps

Access Path Recovery
• Recovery from unplanned failure may require access
paths to be rebuilt
• Time to rebuild access paths varies based on storage,
system, file and the access path itself – can be a
lengthy process
• If access paths are invalidated during a switch
process’ vary-on, the application cannot start until
keyed access paths have been rebuilt
Storage Replication

Access Path Recovery
• Recovery from unplanned failure may require access
paths to be rebuilt
• Time to rebuild access paths varies based on storage,
system, file and the access path itself – can be a
lengthy process
• If access paths are invalidated during a switch
process’ vary-on, the application cannot start until
keyed access paths have been rebuilt
• There is no exposure to rebuilding access paths
during a Journal-Based Replication switch
• Journal-Based Replication solutions can audit
access paths to verify their integrity
• Journal-Based Replication cannot replicate
invalidated access paths from the source to target
• Journal-Based Replication allows you to minimize
downtime by switching to the target during a long
access path recovery on the production server

Topology Flexibility
• Storage Replication replicates SAN to SAN
• Source and target SAN hardware must be similar
• Source and target OS and levels must be similar
• Storage Replication replicates from IASP to IASP
• Distance limitations must be understood for Storage
Replication options
Storage Replication

Topology Flexibility
• Storage Replication replicates SAN to SAN
• Source and target SAN hardware must be similar
• Source and target OS and levels must be similar
• Storage Replication replicates from IASP to IASP
• Distance limitations must be understood for Storage
Replication options
• Journal-Based Replication is storage-independent.
Replication is supported in SAN, internal storage,
or mixed storage environments.
• Journal-Based Replication is OS-independent.
Replication between source and target servers
with different OS versions, TR and PTF levels is
supported.
• Supports replication between ASP, IASP and
SYSBAS
• No distance limitations enables replication
between on-premises and cloud servers
• Broadcast to multiple targets is supported

Hardware and Journal-Based
Practical Considerations

Behavior in Common Scenarios
1. Initial synchronization
2. Unplanned switch
3. Planned switch
4. Reporting
5. Target integrity validation
6. Recovery from network issues
7. Operating system upgrade
8. Storage event management
9. Workload distribution
Weighing Your
HA Options

Scenario 1 – Initial Synchronization
• SAN solutions require a full storage sync before
steady state replication can begin
• All storage sectors are sent across the network
• Limitations must imposed on the quantity of data
going across the wire or synchronization may
never complete
Sectors
SAN SAN
All storage
SYSBAS
IASP
SYSBAS
IASP
Storage Replication

Scenario 1 – Initial Synchronization
• SAN solutions require a full storage sync before
steady state replication can begin
• All storage sectors are sent across the network
• Limitations must imposed on the quantity of data
going across the wire or synchronization may
never complete
• Journal-Based Replication solutions provide many
options for the initial sync
• Save and restore from tape
• Storage copy
• Physical drive swap
• Audit over time
• Object sync commands
• And more
• Reduces impact on network
Sectors
SAN SAN
All storage
SYSBAS
IASP
SYSBAS
IASP
Objects audited over time
Initial object replication
Tape
Selected objects

Scenario 2 - Unplanned Switch
• To switch, the target system must go through a vary
on process to recover transaction integrity – similar
to an abnormal IPL
• A vary on has 34 steps – most of which are recovery
steps of indeterminate length
• Some steps may result in invalidated access paths,
damaged objects, etc.
• Damaged objects detected during vary on require
manual intervention
Storage Replication

Scenario 2 - Unplanned Switch
• The target system is a hot standby with journal-
based replication solutions
• No vary-on process required
• Data has been audited for integrity
• No need to rebuild access paths
• Solutions may provide automation around the
switch from source to target that
• Runs switch steps in parallel when possible
• Provides visibility into progress of each step
• No post-switch recovery steps necessary
• To switch, the target system must go through a vary
on process to recover transaction integrity – similar
to an abnormal IPL
• A vary on has 34 steps – most of which are recovery
steps of indeterminate length
• Some steps may result in invalidated access paths,
damaged objects, etc.
• Damaged objects detected during vary on require
manual intervention
Diagram on next slide

Scenario 2 - Unplanned Switch Timeline
Switch
Vary On
(“IPL” of IASP)
Application
Restart
Switch
Application
Restart
Complete Applies
System Crash1. Waiting for devices - none present
2. Cluster vary job submission
3. Waiting for devices - not all present
4. DASD checker
5. Storage management recovery
6. Synchronization of mirrored data
7. Synchronization of mirrored data-2
8. Scanning DASD pages
9. Directory recovery - perm directory
10. Authority recovery
11. Context rebuild
12. Journal recovery
13. Database recovery
14. Journal synchronization
15. Commit recovery
16. Database initialization
17. Journal cleanup
18. Commit initialization
19. User profile creation
20. Database, journal, commit-1
21. Identifying interrupted DDL ops
22. Recovering system managed jrnls
23. POSIX directory recovery
25. Commit recovery - 2
26. Cleaning up journal receivers
27. Cleaning up cross-reference files
28. UID/GID mismatch correction
29. Database access path recovery
30. Database cross-reference file merge
31. SPOOL initialization
32. Image catalog synchronization
33. Command analyzer recovery
34. Catalog validation
Post Vary On
Recovery
System Crash
• Damaged object recovery
• Access path rebuild
Time
Think Time
Vary On
recovery
time
cannot be
predicted
recovery
Journal-Based Replication delivers a
significantly lower recovery time for
unplanned outages
27

Scenario 3 - Planned Switch
• Storage Replication solutions require a vary off
before the switch
• Requires 34-step vary on after the switch
• Vary on can be impacted by configuration issues,
such as duplicate library names and UID/GID
mismatches
Storage Replication

Scenario 3 - Planned Switch
• Storage Replication solutions require a vary off
before the switch
• Requires 34-step vary on after the switch
• Vary on can be impacted by configuration issues,
such as duplicate library names and UID/GID
mismatches
• Target system is a hot standby
• No vary on process required
• Solutions may regularly audit target data for integrity
• Solutions may provide automation around the switch
from source to target that
• Runs switch steps in parallel when possible
• Provides visibility into progress of each step
Diagram on next slide

Scenario 3 - Planned Switch Timeline
Switch
Application
Restart
Switch
Application
Restart
Application
Shut Down
Vary On
(“IPL” of IASP)
1. Waiting for devices - none present
2. Cluster vary job submission
3. Waiting for devices - not all present
4. DASD checker
5. Storage management recovery
6. Synchronization of mirrored data
7. Synchronization of mirrored data-2
8. Scanning DASD pages
9. Directory recovery - perm directory
10. Authority recovery
11. Context rebuild
12. Journal recovery
13. Database recovery
14. Journal synchronization
15. Commit recovery
16. Database initialization
17. Journal cleanup
18. Commit initialization
19. User profile creation
21. Identifying interrupted DDL ops
22. Recovering system managed jrnls
23. POSIX directory recovery
25. Commit recovery - 2
26. Cleaning up journal receivers
27. Cleaning up cross-reference files
28. UID/GID mismatch correction
29. Database access path recovery
30. Database cross-reference file merge
31. SPOOL initialization
32. Image catalog synchronization
33. Command analyzer recovery
34. Catalog validation
Vary Off
Time
Application
Shut Down
Journal-Based Replication delivers a
lower recovery time for
planned outages
30

Scenario 4 – Reporting
• Data on the target SAN is not accessible until varied
on to a server
• Other than point-in-time storage flashes, Storage
Replications solutions cannot support reporting
from the target
sectors
Server
SAN
Server
SAN
Storage Replication

Scenario 4 – Reporting
• Data on the target SAN is not accessible until varied
on to a server
• Other than point-in-time storage flashes, Storage
Replications solutions cannot support reporting
from the target
• Reports can be run from any target
• Broadcast replication can feed multiple targets for
queries and reports (as well as additional HA/DR
servers)
• Vendors may provide solutions that simplify
management and switching of multi-node
environments.
sectors
Server
SAN
Server
SAN
Remote
DR Server
Reporting
Server
Primary
HA Server

Scenario 5 – Target Integrity Validation
• With Storage Replication, the target SAN cannot be
audited for integrity
• If the target SAN becomes out of sync, a partial or
full resynch of the storage image is required
• Corruption introduced by dirty networks may be
undetectable until the data is read
No audits of target SAN
SAN SAN
SYSBAS
IASP
SYSBAS
IASP
Storage Replication

Scenario 5 – Target Integrity Validation
• With Storage Replication, the target SAN cannot be
audited for integrity
• If the target SAN becomes out of sync, a partial or
full resynch of the storage image is required
• Corruption introduced by dirty networks may be
undetectable until the data is read
• Journal-based replication solutions may offer
methods for validating the live target
• Self-healing audits
• Continuous monitoring of target data
• Solutions may offer virtual switch features to enable
switch testing without production server impact
• Remote Journaling offers validity check to detect
network corruption
No audits of target SAN
SAN SAN
SYSBAS
IASP
SYSBAS
IASP Object comparison
Audits

Scenario 6 – Recovery from Network Issues
• Depending on the extent of the outage, a partial or
full synchronization of stored sectors may be
required
• SAN is not protected until the full or partial resync is
complete
Sectors
SAN SAN
SYSBAS
IASP
SYSBAS
IASP
Storage Replication

Scenario 6 – Recovery from Network Issues
• Depending on the extent of the outage, a partial or
full synchronization of stored sectors may be
required
• SAN is not protected until the full or partial resync is
complete
• After communication resumes, Journal-Based
replication solutions will catch up with journal entries
• Remote Journaling will repackage journal entries into
large block transfers to quickly catch up
• HA/DR protection is in effect as soon as the transfers
catch up
Sectors
SAN SAN
SYSBAS
IASP
SYSBAS
IASP Journal entries

Scenario 7 – Operating System Upgrade
• Once you switch to the upgraded target server, you
cannot switch back to the original production server
until the upgrade completes successfully
• There is no option to go back to a lower OS level
after switching to a higher OS level
Upgrade the target
server to the new OS
version and validate.
Production
Server
Target
Server
1. Switch to the target server. The IASP
image will be upgraded as part of
Vary On. This is non-reversible and
must complete successfully.
1. Upgrade original
production server to
the same level as the
target. Switch back.
SAN
SYSBAS
IASP
SAN
SYSBAS
IASP
Storage Replication

Scenario 7 – Operating System Upgrade
• Once you switch to the upgraded target server, you
cannot switch back to the original production server
until the upgrade completes successfully
• There is no option to go back to a lower OS level
after switching to a higher OS level
• Journal-Based Replication solutions fully support
replication from higher to lower OS levels
• Journal-Based solutions enable an “upgrade, test and
switch” process that removes risk and downtime from
an OS upgrade
• A 3rd node can remove risk of outage during upgrade
Upgrade the target
version and validate.
Production
Server
Target
Server
1. Switch to the target server. The IASP
image will be upgraded as part of
Vary On. This is non-reversible and
must complete successfully.
1. Upgrade original
production server to
the same level as the
target. Switch back.
SAN
SYSBAS
IASP
SAN
SYSBAS
IASP
Production
Server
Target
Server
Secondary
Target
1) Upgrade the target server to
the new OS version and
validate. Switch to the target
server.
1. Upgrade the production
version. Switch back to
the production server.
1. Replication to a secondary
target is recommended to
protect against outages
during the upgrade.

Scenario 8 – Storage Event Management
• Source and target storage images are tightly coupled
(bit by bit copy)
• Single system storage events or storage image issues
can require production downtime
• For example, Reclaim Storage (RCLSTG) events create
protection downtime
SAN SAN
Storage Replication

Scenario 8 – Storage Event Management
• Source and target storage images are tightly coupled
(bit by bit copy)
• Single system storage events or storage image issues
can require production downtime
• For example, Reclaim Storage (RCLSTG) events create
protection downtime
• Journal-Based Replication is isolated from the storage
layer by IBM local or remote journaling
• Storage events can be addressed with little impact on
production operations
• For example, can switch to target while doing
Reclaim Storage (RCLSTG) on production
Server Server
SAN SAN

Scenario 9 – Workload Distribution
• With Storage Replication the target SAN is locked
and cannot be read from or written to
• Workloads run entirely on the source and cannot be
balanced between the two systems
• Some Storage Replication users add flash solutions
to offload work to a snapshot; however, it is point in
time and requires more resources
Write: No
Read: No
Write: ACTIVE
Read: ACTIVE
SAN SAN
SYSBAS
IASP
SYSBAS
IASP
Storage Replication

Scenario 9 – Workload Distribution
• With Storage Replication the target SAN is locked
and cannot be read from or written to
• Workloads run entirely on the source and cannot be
balanced between the two systems
• Some Storage Replication users add flash solutions
to offload work to a snapshot; however, it is point in
time and requires more resources
• Journal-Based Replication solutions support multiple
replication topologies (e.g.1-to-1, broadcast, cascade,
bidirectional)
• Standard 1-to-1 HA/DR by default would use a
readable target that cannot be written
• Active-active solutions with collision handling enables
workload distribution between two servers working
on the same customer data and a near-zero RTO
Write: No
Read: No
Write: ACTIVE
Read: ACTIVE
SAN SAN
SYSBAS
IASP
SYSBAS
IASP
Write: ACTIVE
Read: ACTIVE
Application
Data
Write: ACTIVE
Read: ACTIVE
Bi-Directional
Replication
Application
Data
Write: No
Read: ACTIVE
or

• How will the initial sync be accomplished and what bandwidth is required?
• What bandwidth is required for steady-state replication?
• What RTO/RPO will I be able to achieve?
• Will I have visibility into my ability to meet RTO/RPO at any particular point?
• Can I speak to current customers about their experiences with planned and
unplanned switches?
• How can I know that no corruptions are being introduced into my target data
that will impact my switch time? Can I test without production impact?
• How much flexibility do I have for replication topologies? Can I have nodes for
HA, DR and reporting? Can I workload balance with bidirectional replication?
• When I need to upgrade to the next version of the IBM i OS, what does that
process look like?
• What is the total cost of all software and hardware components required?
• Can I offload reporting or other maintenance tasks to my target server? If so,
will the data be current?
Questions to Ask
How much bandwidth is
required?
What RTO are
customers like me
achieving?
How do I validate
my switch
readiness?

Considerations for DRaaS
in the Cloud

• Reduces cost of obtaining a second system or access to a
secondary site or data center
• Reduces complexity of managing all aspects of a full solution
internally
• Delivers flexibility in ground and cloud configurations and allows
applications to be added or removed from protection as needs
evolve
• Saves time to implement a solution by leveraging a hosting
provider’s infrastructure
• Provides a comprehensive HA/DR solution if you’re ready to step
up from a solution that doesn’t meet your RPO/RTO needs
Reasons to Consider DRaaS

Ask for details about your MSP’s infrastructure,
their policies and SLAs, and the DRaaS solution they
employ. Not all DRaaS solutions deliver the same results!
1. Recovery point and recovery time SLAs
2. DR center locations and infrastructure capacity to handle
DR workloads and failover
3. Onboarding process and migration to MSP’s cloud
4. Privacy and security of your data
5. Issue response times & your ability to participate in
HA/DR monitoring and management
5 Questions to Ask Potential
DRaaS Providers

10 Must-Have Features in a
DRaaS Solution
| Understanding IBM i HA Options
1. Flexible topologies and platform support
2. Replication that meets RPO/RTO goals
3. Efficient bandwidth consumption
4. Ensured data integrity
5. Support for failover into the cloud
6. Built-in HA/DR testing
7. Scalability
8. Easy, automated operation
9. Partner and customer friendly monitoring
and reports
10. Flexible licensing options
47

Syncsort Can Help!
✓ Syncsort’s HA/DR portfolio has grown rapidly through
acquisition
✓ Syncsort is the market leader in IBM i HA/DR
solutions
✓ Syncsort has solutions that meet any downtime
prevention need for your IBM i – from entry-level to
the most aggressive enterprise requirements
✓ Syncsort can help keep your operations running
and your data available!

iTERA
Quick-EDDMIMIX
Syncsort’s
Data Availability
Product Lines
Bring together industry leading
IBM i HA/DR brands that serve
1000s of customers worldwide.
OMS/ODS

IBM PowerHA Add-Ons
Extends and enhances IBM
PowerHA to ensure that all data
and applications are replicated
and ready to switch and enable
multi-node topologies
Disaster Recovery
Ensure rapid recovery of
operations and protection from
lost data in the event of regional
disaster, site failure, hardware
failure or human error
High Availability
Assure continuous availability of
IBM i systems, applications and
data to customers, supply chain
partners and staff
Syncsort Can Help
with All Your
Downtime
Prevention Needs
Managed and Professional
Services
Offload IBM i server migration,
optimization and daily HA/DR
management on a temporary or
long-term basis

• Storage and journal-based replication are fundamentally
different technologies
• Knowing those differences helps you understand how the
two technologies perform common HA tasks
• DRaaS solutions are becoming more common but you must
understanding the underlying solution and SLAs
• Ensure switch readiness by choosing technology that
prevents corruption, ensures target data integrity and
enables regular switch testing
• Be prepared to ask questions!
• Syncsort is here to help
Recap
Learn more at
www.syncsort.com/en/assure

Understanding IBM i HA Options

Understanding IBM i HA Options

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to Understanding IBM i HA Options

Similar to Understanding IBM i HA Options (20)

More from Precisely

More from Precisely (20)

Recently uploaded

Recently uploaded (20)

Understanding IBM i HA Options