MIMIX Introduction

7/24/2019 MIMIX Introduction

1/44

Unit 1: HA Introduction

Copyright, Vision Solutions, 2011

1:1

M I M I X O p e r a t io n s

Hello. 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, common terms, interface choices and a bit about various jobs you will find on your systems.


2/44



1:2


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 you have two

interface options as you manage MIMIX on a day to day basis: Vision Solutions Portal, our browser based interface,

and the traditional 5250 emulation environment. Well show you the primary features of both options.


3/44



1:3


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.


4/44



1:4


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.


5/44



1:5


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 thenintegrated into the CRTJRN command.


6/44



1:6


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. Visionrecommends 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.


7/44



1:7


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.


8/44



1:8


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


9/44



1:9


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.


10/44



1:10


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.


11/44



1:11


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.


12/44



1:12


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.


13/44



1:13


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 thusnot 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.


14/44



1:14


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.


15/44



1:15


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.


16/44



1:16


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


17/44



1:17


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.


18/44



1:18


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.


19/44



1:19


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


20/44



1:20


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 changesare 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 (_DBRDR) will read through the entries and insert any pertinent data into a MIMIX log space. Next

the MIMIX apply job (_DBAPY) will then retrieve the change data from the log space and apply the change to the

file on the backup server.

Note: represents the three character Short Data Group name used by MIMIX.


21/44



1:21


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.


22/44



1:22


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.


23/44



1:23


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, iscomplete 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. Thisprocess 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 controlprocess 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 isretrieved 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 objectsend process.

There is another job (OBJRTV) that does the packaging, then CNRSND will send it. OBJSND job does both journal scrape andqueuing from one process to the next on the source system.

represents the three character short name for a data group.


24/44



1:24


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.


25/44



1:25


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.


26/44



1:26


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.


27/44



1:27


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.


28/44



1:28


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.


29/44



1:29


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 youwill 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.


30/44



1:30


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.


31/44



1:31


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 repleicated

through a user journal, into the configuration by looking at object entries rather than manually creating each entry.


32/44



1:32


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.


33/44



1:33


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.


34/44



1:34


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.


35/44



1:35


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.


36/44



1:36


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 foldersfrom the implementation.


37/44



1:37


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.


38/44



1:38


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).


39/44



1:39


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.


40/44



1:40


Application Groups are comprised of a collection of related resources that are controlled as a group. For example, startingan application group will start or activate all resource groups associated with the application group. Resource Group entriesidentify 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.


41/44



1:41


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 withthe 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 replicateNODEA 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.


42/44



1:42


Here is a graphic that helps depict the hierarchy of AGs and how they play in the 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.


43/44



1:43


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.


44/44


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.

MIMIX Introduction

Documents

Transcript of MIMIX Introduction