Advanced DBA – High Availability for MUF

World®
’16
Advanced DBA –
High Availability for MUF
Kevin Shuma VP, Product Management
CA Technologies
MFX64E
MAINFRAME AND WORKLOAD AUTOMATION

2 © 2016 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
Abstract
This session describes the available options for sites that need
to keep their CA Datacom environments (MUFs) operational for
extended periods of time. This include functionality to cover
IPLs, systems outages and even CA Datacom software upgrades.
This session will primarily cover the new features available in
the CA Datacom®/DB processing that allows the CA Datacom
environment (MUF) to migrate from one address space to
another without a noticeable outage to the end users.
Kevin Shuma
CA Technologies
VP, Product
Management

Agenda
WHAT IS HIGH-AVAILABILITY FOR DATABASE ENVIRONMENTS
DATA SHARING SHADOW TECHNOLOGY
ACTIVE-QUERY (ACTIVE-ACTIVE ARCHITECTURE)
SUMMARY
1
2
3
4

What is high-availability?
“High availability is a characteristic of a system,
which aims to ensure an agreed level of
operational performance, usually uptime, for a
higher than normal period.”
“If a user cannot access the system, it is - from the
users point of view – unavailable. Generally, the
term downtime is used to refer to periods when a
system is unavailable.”
According to Wikipedia
24x7

What is high-availability for database environments
§ The ability for the Datacom environment
(MUF) to remain up or migrate from one
address space top another without a
noticeable outage to the end-user
– Do not interrupt user data access for
§ MUF failures
§ IPLs
§ Software maintenance
§ Software upgrades (new releases)
§ Just about everything a SYSPROG “needs” to do to keep a system running
From a CA Datacom perspective

Data sharing shadow technology

§ CA Datacom supports 3 different data sharing techniques
§ The Shadow MUF is the recommended and most used
technique
– Provides 24x7 fail over
– Provides migrate capabilities for use during IPLs
– Provides capabilities for implementing software maintenance
– (V15.0) Provides capabilities for implementing a new release
A special form of Data Sharing
Shadow Technology

§ Primary MUF – is the MUF instance up
and enabled at that moment of time
§ Shadow MUF – is the second instance of
the MUF that is considered not enabled
but running on same LPAR or a different
LPAR on the same SYSPLEX
§ Both MUFs share the same set of
databases (DASD)
Primary
Shadow
Shadow Technology (cont’d)

§ XCF is used as the message service
between the shadow and the primary MUF
§ If XCF service is stopped or abends
– Possible loss of communication between
the Primary and Shadow MUF is possible
– Shadow MUF cannot take over, must
be forced to takeover
– This is very rare in today’s world
Primary
Shadow

§ XCF messages
– Primary MUF DSNZMFM1
DSNZMFM1:MUFM1:DB02330W - SHADOW START,
JOB=DSNZMFM2 SYSTEM=CA31
– Shadow MUF DSNZMFM2
DSNZMFM2:*:DB02301I - XES GROUP JOINED (QAPLEX1,SHADOW$$071)
DSNZMFM2:*:DB02325I - SHADOW MUF NOW WAITING
Primary
Shadow

§ Unplanned outage
– Primary MUF fails
– LPAR fails
§ Planned outage
– Scheduled IPL
– Need to change MUF start-up options
– Scheduled software maintenance
– Scheduled release upgrade (V14 to V15)
Primary
Shadow

Shadow Technology – Unplanned outage
§ Unplanned Shadow MUF
– No CF Structures
– Only one MUF up at a time, no intersection
of two MUF instances can occur
– No worries about MRDF, CBS and PXX
being shared
Primary
Shadow

§ Application regions use “access
anywhere” to connect to primary
MUF
§ Shadow MUF is started (same or
different LPAR)
§ XCF is used to SYNC MUFs
§ Shadow “watches” primary
§ Shadow opens all MUF datasets,
but does not do request processing
LPAR 1
CICSPLEX
BATCH
CICSPLEX
XCF
LPAR 2
CICS TOR
CICS TOR
DSNZMFM1
DSNZMFM2
Remote Shadow
Shadow MUFPLEX
Allocation/Open
only
Full Access
XMEM
Shadow Technology – Unplanned outage

§ Primary MUF (MUFPLX1) fails
§ Existing transactions notified
of MUF failure
§ Remote Shadow automatically
detects failure
§ Remote Shadow begins clean-up
of failed MUF
§ New requests can be told to “wait”
§ Remote Shadow becomes MUFPLX1
Shadow Technology – Unplanned outage (cont’d)LPAR 1
CICSPLEX
BATCH
CICSPLEX
XCF
LPAR 2
CICS TOR
CICS TOR
DSNZMFM1
BATCH
New DB req wait New DB req wait
Full access/begin
clean-up and new
work
XMEM
Shadow MUFPLEX
DSNZMFM2
Remote Shadow

§ Applications with reconnect
capabilities re-establish
connections and continue
processing
§ Brief pause in service, but not an
outage
§ Site restarts failed MUF region and
it automatically detects that it is
now the Shadow
LPAR 1
CICSPLEX
BATCH
CICSPLEX
XCF
LPAR 2
CICS TOR
CICS TOR
Shadow MUFPLEX
New BATCH
Full Access
XMEM
Allocation/Open
only
DSNZMFM1
Remote Shadow
DSNZMFM1
Shadow Technology – Unplanned outage (cont’d)

§ Planned Shadow MUF
– CF structure required
– Two MUFs can be up so the rules for full data sharing
are now enforced
– Can use the Migrate command or do the process
manually
– If either MUF instance fails during this process, must
restart the MUF instance that failed ASAP
– EOJ of either MUF instance removes the aspects of full
data sharing
– Time line for two MUF instances being up at the same
time should be considered to be brief
Shadow Technology – Planned outage
Primary
Shadow

§ Issue MIGRATE command to
convert Remote Shadow into a
full data sharing MUF
§ Coupler Facility used to
synchronize two member MUFs
§ Both MUFs now full participants
Shadow Technology – Planned outageLPAR 1
CICSPLEX
BATCH1
CICSPLEX
XCF
LPAR 2
CICS TOR
CICS TOR
Shadow MUFPLEX for IPL
Coupler
XMEM
Full Access Full Access
DSNZMFM1
DSNZMFM2
Active MUF

§ All applications now running on
LPAR2
§ Stop MUF on LPAR1
§ Use of coupler stops
§ IPL LPAR1
§ Once complete restart Shadow on
LPAR1
§ Could issue MIGRATE to revert to
original state
§ Could use Shadow on LPAR3 while
LPAR1 IPL’d
Shadow Technology – Planned outage (cont’d)
SVC
LPAR 1
CICSPLEX
BATCH1
CICSPLEX
LPAR 2
CICS TOR
CICS TOR
MUFPLX1
Shadow MUFPLEX for IPL
Coupler
BATCH2
BATCH3
EOJ
EOJ
EOJ
EOJ
Full Access
DSNZMFM2
Active MUF

§ Upgrade from 14.0 to 15.0
– Recommend the code only be done at this time
– One MUF instance can be 14.0
– Other MUF instance can be 15.0
– Recommend not leaving both MUF instances up
very long
– DBID Format 3 and DBID Format 2 messages will
be occurring in both MUFs
Primary
Shadow

§ Recommend you bring down the 14.0 MUF
instance as soon as you can
§ Then restart the Shadow MUF as 14.0 for
fallback
§ This upgrade process is supported, but it is not
the path we expect the clients to take
– Upgrade path should not be done with two MUFs up
Primary
Shadow

Shadow Technology – Other Considerations
§ Products such as CA 7 and CA 11 have the built-in logic to
recognize a MUF failure and automatically reconnect to the
Shadow without loss of information
§ CA Datacom provides a suite of “online” utilities so that items
like data reorganization are supported while the data is in use
– These functions are not allowed when running data sharing mode for
two or more MUF instances at the same time

Shadow Technology – Other Considerations (cont’d)
§ How Are Clients Using Shadow?
– Large number of sites have not implemented this
– For the ones who have, probably over 90% use the unplanned version
of Shadow (no CF structure)
– The remaining 5-10% use the planned outage of the Shadow MUF
(requires CF structure)

Active-Query (Active-Active Architecture)

Remote Replication Technology
§ Active-Standby
§ Active-Query
§ Active-Active
Active Architecture

Remote Replication Technology – Active Standby
§ Primary image runs in full update mode
– User transactions are directed by a router to
the current “primary” data manager
– Dynamic switching can occur to shift workload
if the primary data manager fails
– Secondary “standby” image does not process
any user work
– All users issue data requests on the primary
image
– Data changes are replicated in a timely fashion
from the primary to the standby image
Active Architecture

Remote Replication Technology – Active Query
§ Primary image runs in full update mode
– User update transactions are directed by a
router to the current “primary” image
– Dynamic switching can occur to shift
workload if the primary image fails
– User query transactions can be directed to
the “query” image which allows work to be
processed
– Data changes are replicated in a timely
fashion from the primary to the query
data management image
Active Architecture

Remote Replication Technology
§ Components Used
§ Prerequisites
§ MQTS Overview
§ Operational Overview
§ Sample Output
Active Query – Datacom V14.02

Remote Replication Technology - Components
§ Change Data Capture (CDC)
– Built in facility to capture changes for selected tables
– Changes stored in a Datacom database as TSN and MNT rows
§ MQ Transport Service (MQTS) - Part of IPC 15.0
– New IPC facility to enable Datacom components to interact
with IBM MQ
§ New CDC Remote Replication component
– New Datacom deliverables that move the data from the CDC
across MQ to a target MUF
Active Query – Datacom V14.02 / IPC V15.0

Remote Replication Technology - Prerequisites
§ Source MUF environment
§ Target MUF environment synchronized to source MUF
§ MQ subsystems for each environment
– MQ queues defined for sending from source to target system
§ IPC 15.0 installed (MQTS)
§ CDC remote replication services installed
– RO81655 for R14
– RO81529 for R15

Remote Replication Technology - MQTS
§ Operates on IBM MQ queues
– Requires MQ setup, part of IPC 15.0 (compatible with DB 14.0 and 15.0)
§ MQTS uses a workload ID to construct the MQ queue names
– CAMQTS.queue.workloadID
– Where queue is:
§ SOD – Source, outgoing, data (connects with remote’s TID)
§ SID – Source, incoming, data (connects with remote’s TOD)
§ TOD – Target, outgoing, data (connects with remote’s SID)
§ TID – Target, incoming, data (connects with remote’s SOD)
§ XQ – Transmission queue

Remote Replication Technology – MQTS (cont’d)
§ MQTS to MQ Channels
§ MQTS uses the workload ID to construct the MQ channel
names
– CAMQTS.channel.workloadID
– Where channel is:
§ HA – System A to B communication
§ HB – System B to A communication
§ Remote’s channel names must match local’s channel names

Remote Replication Technology – MQ Overview
Example: WRKLD03
MQ Queue Relationships for Workload

Remote Replication Technology – MQ Overview
Remote Replication Operational Overview

§ DBCDSPR- The Sender
– Provide control statements to give:
§ CDC DBID to process
§ The MQTS Workload ID
§ Other parameters to control buffer
sizes, wait limits, retry counts, etc.
– Connects to the source MUF
– Connects to MQ via MQTS SEND
– Sends changed data to the receiver via MQ
– Responds to console commands

§ DBCDRPR – The Receiver
– Provide control statements to give:
§ The MQTS Workload ID
§ Other parameters
– Connects to the target MUF
– Connects to MQ via MQTS
– Generates URTs for the target MUF
– Receives MQ data via MQTS RECEIVE
– Applies updates to the target MUF
– Responds to console commands

Sample Output Sender

Sample Output Sender (cont’d)
Sender throughput
statistics, response to
STATUS command

Sample Output Receiver
Receiver messages at startup

Sample Output Receiver (cont’d)
Receiver throughput
statistics, response to
STATUS command

Remote Replication Technology - Summary
§ New MQ Transport Service provides
– MQ wrapper so that sender/receiver don’t have to have MQ knowledge
§ CDC used to capture changes at source
§ Sender used to package source changes and send to receiver
– Once sent deletes changes from source CDC
§ Receiver used to take packaged changes from MQ and apply to
target MUF
– Once applied deletes package from MQ

Summary
A Few Words to Review
Experiences
Various sites has used these
functions to keep their
database environment
available 24x7 for a number of
years.
Key Topics
In today’s world, database
environments must be able to
provide 24x7 access.
Findings
CA Datacom Shadow MUF
delivers high-availability while
the new Remote Replication
feature sets the base for
continuous availability.

@CAWORLD #CAWORLD © 2016 CA. All RIGHTS RESERVED.42 @CAWORLD #CAWORLD © 2016 CA. All RIGHTS RESERVED.42
Mainframe and Workload Automation
For more information on Mainframe and Workload Automation,
please visit: http://cainc.to/9GQ2JI

Recommended Sessions
SESSION # TITLE DATE/TIME
MFX92S Strategy and Vision for CA Datacom and CA Ideal 11/16/2016 at 12:45 pm
MFX93S What’s new in CA Datacom 11/16/2016 at 1:45 pm
MFX94S Reducing TCO with Datacom Compression (Presspack) 11/16/2016 at 3:00 pm
MFX95SA Modernizing the CA Datacom data – SQL Access Part I 11/16/2016 at 3:45 pm
MFX95SB Modernizing the CA Datacom data – SQL Access Part II 11/16/2016 at 4:30 pm
MFX96S CA Datacom/AD Installation/Upgrade and Maintenance 11/17/2016 at 12:45 pm
MFX97S
CA Datacom/AD Report Utilization, and
information gather for Support
11/17/2016 at 1:45 pm
MFX98S
Using Sysview to monitor and measure your CA Datacom
environment – AD and DB
11/17/2016 at 3:00 pm
MFX99S Birds of a Feather/Stump the Techie! 11/17/2016 at 3:45 pm

Questions?

Thank you.
Stay connected at communities.ca.com

© 2016 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.
The content provided in this CA World 2016 presentation is intended for informational purposes only and does not form any type of
warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.
For Informational Purposes Only
Terms of this Presentation

Advanced DBA – High Availability for MUF

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (14)

Similaire à Advanced DBA – High Availability for MUF

Similaire à Advanced DBA – High Availability for MUF (20)

Plus de CA Technologies

Plus de CA Technologies (20)

Dernier

Dernier (20)

Advanced DBA – High Availability for MUF