Download as pdf or txt
Download as pdf or txt
You are on page 1of 44

MIMIX Operations

Welcome to the first unit of MIMIX Operations High Availability Introduction. In this module we will discuss the basic
principals of HA with respect to MIMIX. You will gain an understanding of how MIMIX accomplishes its replication,
introduction to journaling on the IBM i systems, and an overview of MIMIX configuration.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:1

MIMIX Operations

In this section we will discuss fundamental concepts associated with MIMIX HA environment. Included in the
fundamentals is an introduction to journal concepts and an overview of remote journaling. As an operator it will be
helpful for you to also understand the various terms associated with MIMIX configuration we will briefly introduce
concepts of configuration.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:2

MIMIX Operations

MIMIX logical replication is based on journaling. On the system i there are two types of journals: the system journal
and user journals. The difference in these two types of journals is primarily the kinds of information that is captured in
the journal.
The system journal captures information at the object level and is event-based. Activities such as object creates,
moves, and access all create journal entries in the system journal.
User journals typically capture data-specific changes. User journals can be used to capture data level changes to files,
data areas, data queues and/or IFS objects. User journal entries will capture activities such as record inserts, updates
and deletes. IBM is constantly enhancing what information will be journaled, especially for objects that were not
traditionally journaled such as data areas, data queues and IFS objects.
MIMIX will use the information contained in the system journal and the user journals to replicate activity from the
production system to the backup (target) system.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:3

MIMIX Operations

Both System and User Journaling are an absolute requirement in a MIMIX environment. Shut down Journaling put
MIMIX on the shelf.
The System Journal, known as QAUDJRN, is a function of the Operating System and is controlled by two System
Values and by an Audit Value on each individual object.
The User Journal(s), also know as Data Base journals, are created by the user to satisfy replication requirements or
other user requirements.
Both of the above journals can be used to recover a system in the event a system failure and to provide the foundation
for logical replication to a second copy of the objects and database on a second system.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:4

MIMIX Operations

New systems delivered from the factory are shipped without any journals. These must be created by the user.
When creating a new journal environment, the Receiver and the Message Queue must be created first and then
integrated into the CRTJRN command.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:5

MIMIX Operations

The User Journal, also known as a Data Base Journal, is created by the user to satisfy specific requirements of the user.
The User Journal object, the receivers, and the message queue, can reside anywhere on the system. Vision
recommends that the User Journals and associated objects be placed in a library that begins with a # sign or an @ sign
(e.g. #JRNLIB) so that this library is restored first prior to the database libraries.
There are only two options that can be used to configure a user journal - 1) Images - either *BOTH (Before and After),
or *AFTER only, and 2) Include Open and Close entries.
Images - For MIMIX replication, only *AFTER images are required. For environments that support Commitment
Control, *BOTH images are required.
Include Open and Close Entries - Unless required by auditing or other security reasons, set this parameter to
*EXCLUDE.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:6

MIMIX Operations

You can have multiple user journals on a system. There is no restriction to the naming of the journals or their location.
MIMIX by default will place the journals and receivers in the #MXJRN library and default the name of the journal to the
same name as the data group definition. Placing the journals and receivers in a library that starts with the #sign will help
insure the journaling environment is restored before the data base files incase a restore from tape is necessary.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:7

MIMIX Operations

When you associate a file with a journal and a change happen to that file the change is recorded in the journal receiver.
When a receiver is currently receiving entries from the journal it is considered the attached receiver. You can have older
receivers on the they are considered to be part of the receiver chain. You must be careful not to have the current
receiver reach its maximum size as journaling will be turned off by the operating system

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:8

MIMIX Operations

For each change that can happen to a file or record there is a unique journal code and type combination for that change
that is recorded in the receiver. The changes are recorded in the receiver in the same sequence as they occurred in the
file. The operations systems uses a sequence number to track the changes.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:9

MIMIX Operations

The System Journal (otherwise known as the Security Journal or the Object Journal), is the journal that is used to record
object level events.
The Journal object must reside in QSYS, the placement of the receivers and the message queue is at the discretion of
the user.
There can only be one System Journal for the whole entire system.
It is controlled by two separate System Values, QAUDCTL and QAUDLVL. Basically, QAUDCTL turns object auditing on
and off for the entire system, and QAUDLVL controls the types of transactions that will be recorded. MIMIX requires a
minimum of 7 different types of activity (Creates, Deletes, etc). be recorded for proper object replication. Many, many,
more types can be specified depending on user requirements. In fact, the list of activities was recently expanded beyond
the capacity of the data area that contains the information, so a second System Value, QAUDLVL2, was added by IBM
in a recent version of the OS.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:10

MIMIX Operations

The system journal records events that happen at the object level. You can only have one system journal on the system.
The journal name has to be QAUDJRN and reside in QSYS. The name and location of the receivers has no restriction
but MIMIX defaults to AUDRCV for the receiver prefix name and QUSRSYS for the library. The systems value
QAUDLVL determine the amount of information to capture.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:11

MIMIX Operations

MIMIX needs the QAUDLVL set to *CREATE, *DELETE, *OBJMGT, *SAVRST, and *SECURITY to be able to replicate
the changes objects. The QAUDCTL value must also be set to *ON. MIMIX will check these values when it starts and if
not set correctly it will add the needed values with our removing an other existing entries the customer may have set.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:12

MIMIX Operations

Beside the system values the Objects auditing level must also be set. The object auditing level tell the system what
information to capture for that specific object. The default value for MIMIX is *CHANGE. This will capture all of the object
existence changes as well has authority and attribute changes. A value of *None is like turning off auditing for that
specific object. When set to none to transaction that occur for that object will be recorded in the system journal and thus
not be replicated by MIMIX. The *ALL value give you the addition of recording the accessing of the object. For most
situations this is not needed by replication as replication is concerned with the changing of the object not who is
accessing it.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:13

MIMIX Operations

The System journal will record changes to the objects on the system. Like User journal the System journal there is a
unique journal code and type combination for a type of transaction that can occur and is recorded in the receiver. The
changes are recorded in the receiver in the same sequence as they occurred in the file. The operations systems uses a
sequence number to track the changes.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:14

MIMIX Operations

To work the data captured by journaling you can use the DSPJRN command for both User journals and the System
journal. The command lets you see what files/objects are being changed and who is changing them. You have options to
look into the journal entry for the specific information and can also see which receiver the entry resides in.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:15

MIMIX Operations

There are also option you can take to see what is being journaled to the journal.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:16

MIMIX Operations

To work with the attributes of a User journal or a System journal you can use the WRKJRNA command. This will let you
see how the journal is configured, what is the current receiver and you can see the list of all the receivers on the system
for this journal.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:17

MIMIX Operations

Remote journal environments actually consist of a pair of journals, a source journal created on the source system and a
target journal on the target system.
When an application modifies, inserts, deletes application data and since these data files are journaled these activities
create journal entries in the source journal. Each record that is inserted, deleted or changed will create an individual
journal entry. The source and target journals maintain a communications link that is used to send journal entries from
the source journal to the target journal. All journal entries are stored in a special journal object called a receiver.
Remote journal environments can be configured using one of two methods: asynchronous or synchronous. When RJ
is configured asynchronously then:
Journal entries are sent to the remote journal receiver (system) at the same time as they are deposited in the local
journal receiver.
There is minimal to no impact on application performance when using Async RJ configuration.
It is suitable for longer transmission distances, such as when the target system is located in a different location.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:18

MIMIX Operations

When RJ environments are configured as synchronous:


Journal entry is deposited in the remote journal receiver (memory) before it is deposited in the local journal
receiver.
Guarantees the target system is current with production.
Can impact application:
- Applications must wait until the entry is deposited in the local receiver and a confirmation message is
received on the source system before they can move on to next transaction.
Not suitable for long transmission.
Switch processing slightly different than with asynchronous

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:19

MIMIX Operations

Lets take a look at the basic process used by MIMIX to replicate data through a user journal.
On the Primary server we have users and applications that are changing, adding and deleting data. These changes
are being recorded in a local user journal that has been set up to use remote journaling. As changes are made on the
primary server journal entries are stored in the local journal receiver attached to the journal. Since there is an RJ link,
these journal entries are sent to the remote journal receiver on the backup or target system. The MIMIX database
reader job (<sdn>_DBRDR) will read through the entries and insert any pertinent data into a MIMIX log space. Next
the MIMIX apply job (<sdn>_DBAPY) will then retrieve the change data from the log space and apply the change to the
file on the backup server.
Note: <sdn> represents the three character Short Data Group name used by MIMIX.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:20

MIMIX Operations

Here is an example of replicating a newly created file using the STRJRNLIB support. When the file is created on the
source system the Operating System will start journaling of the file to the journal specified on the STRJRNLIB
command. The STRJRNLIB command is issued by MIMIX.
The creation of the file is recorded in the journal and will be sent to the target system by remote journal. On the target
system the MIMIX Database apply will get the create journal entry and will be able to create the file on the target
system with the information in the journal entry. This process will not require doing a save and restore of the object
making the process much quicker to replicate new files.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:21

MIMIX Operations

As we noted earlier, a pair of journal definitions make up one remote journal link. For a switchable data group there will
be four journal environments required: one pair of source and target journals for each possible direction of replication.
In the example here we have journal environments defined for a data group called MFG which has been configured to
use remote journaling and to be a switchable data group. Two pairs of journals are created. You will see a *SRC
journal on system A that is linked to a *TGT remote journal on system B. Another pair where the *SRC journal is on
system B which is linked to the *TGT remote journal on system A. When MIMIX is allowed to name the journal
environments, the remote journal definition is named by using the source journal name and appending @R to the
name. In our example, the two remote journal definitions are named MFG@R.
Lets take a look at the basic replication process when using RJ. On the source we have files that are being journaled.
When changes are made to the data, journal entries are created and stored in the MFG *SRC journal on system A.
The remote journal process then sends those journal entries from the *SRC journal to the remote journal MFG@R on
system B. The MIMIX apply job(s) then read the remote journal entries to replicate the data changes on the target
system B. Since the MFG data group is a switchable data group the data files that are journaled on the source
should also be journaled on the target system. This is because we need to be able to capture changes to the date in
the event of a switch and users are actively entering data on system B. The replication activities create journal entries
in the MFG *SRC on system B.
Generally speaking, you should only have the RJ link active in the direction of replication. In our example the RJ link is
active from MFG *SRC on system A to MFG@R *TGT on system B. The link for the other pair is inactive.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:22

MIMIX Operations

STSSND STSRCV -They are their own pair - their purpose is to flow status update (like going PA to CP) back to the source system.
The replication path in MIMIX Object Replicator uses the following processes:
Object send process: alternates between identifying objects to be replicated and transmitting control information about objects
ready for replication to the target system.
Object receive process: receives control information and waits for notification that additional source system processing, if any, is
complete before passing the control information to the object apply process.
Object retrieve process: if any additional information is needed for replication, obtains it and places it in a holding area. This
process is also used when additional processing is required on the source system prior to transmission to the target system.
Container send process: transmits any additional information from a holding area to the target system and notifies the control
process of that action.
Container receive process: receives any additional information and places it into a holding area on the target system.
Object apply process: replicates objects according to the control information and any required additional information that is
retrieved from the holding area.
Status send process: notifies the source system of the status of the replication.
Status receive process: updates the status on the source system and, if necessary, passes control information back to the object
send process.
There is another job (OBJRTV) that does the packaging, then CNRSND will send it. OBJSND job does both journal scrape and
queuing from one process to the next on the source system.
<sdn> represents the three character short name for a data group.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:23

MIMIX Operations

The various configuration items associated with MIMIX work together much like the pieces of a jigsaw puzzle. If you
are missing a piece the puzzle, or your replication environment, will not be complete.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:24

MIMIX Operations

With MIMIX each system has a configuration role. It is either a Management system or a Network system. The
configuration of MIMIX must be done on a management system. Once the initial configuration is done and sent to the net
system. You will only be able to view the configuration from the network system.
With MIMIX Professional and Enterprise you can only replicate data between a Network System and a Management
system or a Management system and a Network system. If you have a more complex environment with multiple nodes
you can go to a MIMIX Global level and have more flexibility in replicating between management systems with the Multi
Management support.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:25

MIMIX Operations

System definitions describe the i5 environment that should be used by MIMIX. The most important information
included with the system definition are the details associated with the transfer of data. You may assign a primary and
a secondary transfer (communication) definition in your system definitions.
To work with your system definitions you can either select option 1 from the Configuration Menu or enter the work
system definition (WRKSYSDFN) command.
You must create one system definition for each system i that will be participating in the implementation.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:26

MIMIX Operations

To work with your transfer definitions you can either select option 2 from the Configuration Menu or enter the work
transfer definition (WRKTFRDFN) command.
The transfer definition is used to describe the communication details between two systems. Key information that is
included in the transfer definition are communication protocol, host name or IP address associated with each system,
and other network specific details.
You must define at least one primary transfer definition for each system i communication path you will need for the
implementation. You may also define a secondary transfer definition which MIMIX will use when the primary transfer
method is unavailable.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:27

MIMIX Operations

To work with your journal definitions you can either select option 3 from the Configuration Menu or enter the work
journal definition (WRKJRNDFN) command.
The journal definitions are used to describe the journal environment to be used to replicate your data, files, objects,
etc. The easiest and quickest way to create your journal environment is to first create your data group definitions and
then have the journal definitions created automatically when the data group is created. Once created you can access
and modify the definitions from the Work with Journal Definitions screen.
The build journal environment (BLDJRNENV) command (option 14) will create all of the necessary journal objects for
the environment: Journal, receiver and threshold message queue.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:28

MIMIX Operations

You must have at least one data group definition in order to perform replication.
Data group definitions are used to define the default replication characteristics for this set of data. In the definition you
will find many parameters that can be used to fine tune the data group for your replication needs. In general, the
default parameter values will work in most environments.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:29

MIMIX Operations

Data group entries are used to describe the types of files, objects, folders, etc. that should be included or excluded
from the current data group. Each data group can have from 1 to nn data group entries.
By default, many data group entry parameters will use the default value set in the data group definition. This allows
you to only define the exceptions in the data group entries. Be cautious of this method because if you change the data
group definition to a different default value the next time you load objects based on the data group entries you may
have different values than you intended.
For example, if the data group is initially set to replicate user profiles as *DISABLED and the data group entry has the
User Profile Status set to *DGDFT the user profiles will be replicated as disabled. However, should you change the
data group definition so that user profiles are replicated as *ENABLED by default, the next time you load file entries
your user profile entries will be set to replicate the profiles as enabled. This may, or may not be what you want.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:30

MIMIX Operations

Data group object entries are used to define library based objects for replication. Object entries can be used to include
or exclude objects from replication.
As an example, you may have a library that contains several hundred files/objects which all need to be replicated. You
can create one object entry which defines to MIMIX that all objects within the library should be replicated. This is
much simpler than defining one object at a time.
Additionally object tracking entries can be used to load detailed tracking entries, necessary for objects replicated
through a user journal, into the configuration by looking at object entries rather than manually creating each entry.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:31

MIMIX Operations

Data group file entries are the list of actual files that will be replicated. If you have created a data group object entry
such as MYLIB/*ALL *INCLUDE, the command load data group file entry (LODDGFE) will create one file entry for
each object in the library.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:32

MIMIX Operations

Data group Object Tracking entries specify data areas and data queues that are to be replicated at the data level
with a User journal. The object tracking entries are generated based on the data group object entries that have the
cooperate with database flag set for cooperating with database.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:33

MIMIX Operations

Data group IFS entries define which IFS paths (directories) and objects are to be replicated. If you want these IFS
objects to be replicated through journaling than you will need to ensure that you select *YES to cooperate with the
database. More on that in a later presentation.
Similar to Object entries, you can define IFS entries that will either include or exclude objects from the implementation.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:34

MIMIX Operations

Data group IFS Tracking entries specify IFS directories/files that are to be replicated at the data level with a User
journal. The IFS tracking entries are generated based on the data group IFS entries that have had the cooperate
with database flag set to yes.
All IFS objects that are to be replicated through journal entries will need to have an associated IFS tracking entry.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:35

MIMIX Operations

Data group DLO entries define which DLO folders and documents are to be replicated.
Again, like object and IFS entries, you can define DLO entries that will either include or exclude documents and folders
from the implementation.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:36

MIMIX Operations

Application group is a means of tying the application and the data replication flows together. The
benefit is it allows you to control the application and data replication and get combined status data in
one place. It will contain information about the application, the recovery domains which are the nodes
that can be the primary for that data, and the data that makes up the application.
The goal is that by grouping them together you have one place to manage and to control them. For
example I could have ten data groups and tie all ten into one application group. From that application
group I can start, stop, and see the status of the entire application group. With WRKDG if you have ten
data groups you view the first eight on one screen and then page down to see the status of the last
two.
One caveat is that within application groups all the nodes that are associated with application group
must be the same and have the same roles.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:37

MIMIX Operations

A node is basically a system or partition. At a high level a node can participate in more than one
instance but can only participate in one IBM Cluster. Nodes are basically the same as systems and
mostly will be used interchangeably. In the interfaces moving forward node will be emphasized more
than system for terminology.
The primary theoretical difference is that Nodes have a role definition. They can either be a Primary,
backup or replicate. A system is just a system with not a particular role. A second difference A node
has to have a system database (SYSBAS).

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:38

MIMIX Operations

A recover domain is a subset of nodes that are group together for a common purpose. Each
application group will have a recovery domain that means if that application or node fails who is my
new primary. It could be 128 different nodes to fail to. 128 is the number of nodes that IBM supports. It
basically means where can this application start up from.
Within an application group the nodes will be defined either as a primary, secondary, or backup node.
There can be any number of backup nodes. There is also a concept of a replicate node which is only
for cluster which defines the node as only receiving data and never can be a primary node. Another
concept is a peer node which also is only for cluster. A peer node from a MIMIX standpoint is a
bidirectional environment where all of the data resides on both systems and both systems can change
the data.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:39

MIMIX Operations

Application Groups are comprised of a collection of related resources that are controlled as a group. For example, starting
an application group will start or activate all resource groups associated with the application group. Resource Group entries
identify resources for which data protection activity, such as MIMIX replication, is monitored and managed as a single unit.
There are different types of Resource Group Entries that can be defined to MIMIX.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:40

MIMIX Operations

There are different types of Resource Group Entries that can be defined to MIMIX.
Data RGE used to control data replication as defined through your data groups. A Data RGE can have one to many
data groups associated with it.
If you have a two node environment then each of your Data RGEs will have just one data group associated with
the RGE.
If there are multiple data groups in a Data RGE those data groups are replicating the same data to different systems.
For example:
You may have three nodes defined to your environment and the data groups within a given Data RGE replicate
NODEA NODEB, NODEA NODEC, and NODEB NODEC.
All three data groups have been defined to replicate the same data, but the source/target designations are different,
and not all data groups are active at any given time.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:41

MIMIX Operations

Here is a graphic that helps depict the hierarchy of AGs and how they relate to other MIMIX concepts. System Manager
remains as the main control and Application Groups are the next level control. Each application group will have nodes
that define the recovery domain, and you will have resource groups that will control the data groups.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:42

MIMIX Operations

In this module we have discussed several topics to help you better understand MIMIX high availability environment.
First we looked at some of the basic concepts associated with HA. Then we looked at some very basic journal
concepts and how they apply to MIMIX replication. Next we reviewed several terms that will be helpful as you begin to
use MIMIX. This was followed by a discussion of your two interface choices for managing your MIMIX operations.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:43

MIMIX Operations

This concludes our introduction to MIMIX High Availability. If you have questions regarding this module you can post
your questions to the MIMIX Operations discussion group within the VSU learning center. Thank you.

Unit 1: HA Introduction
Copyright, Vision Solutions, 2013

1:44

You might also like