2.0 Administrator Guide

Solaris ™ OS, HP-UX™, AIX™

i

Preface Purpose

This manual explains the outline, configuration and operational procedures of Softek TDMF, Open

Systems Edition (referred to as Softek TDMF henceforth) on Solaris™ operating system, HP-UX™

and AIX™.

Audience

This manual is intended for system administrators responsible for managing and maintaining

business critical applications and its related data.

Organization

This manual is organized as follows

• Chapter 1 Softek TDMF Outline

This chapter outlines the Softek TDMF product.

• Chapter 2 Softek TDMF Architecture

This chapter describes details necessary while using Softek TDMF

• Chapter 3 Softek TDMF Features

This chapter describes features available in Softek TDMF.

• Chapter 4 Softek TDMF Configuration

This chapter explains the procedures and steps to follow for configuring a basic environment.

• Chapter 5 Softek TDMF Operation Patterns

This chapter describes the various operation patterns possible with Softek TDMF and the

configuration required.

• Chapter 6 Softek TDMF Administration

This chapter describes the procedure required for smooth operation of Softek TDMF and

troubleshooting procedures.

• Chapter 7 Configuration Tool

This chapter describes how to use the configuration tool provided with Softek TDMF

• Chapter 8 Monitoring Tool

This chapter explains the usage of the various monitoring tools available in Softek TDMF.

• Chapter 9 Softek TDMF Commands

This chapter explains the commands provided with Softek TDMF

• Chapter 10 Softek TDMF Operation Considerations

This chapter describes considerations when using Softek TDMF

• Appendix A Configuration File

This appendix explains the configuration file of Softek TDMF

• Appendix B Throttle Reference

This appendix explains throttles in Softek TDMF.

• Appendix C Tunable Parameters

This appendix explains tunable parameters available in Softek TDMF.

ii

• Appendix D Production Operation Examples

This chapter describes some production examples using Softek TDMF.

Related Manuals

The set of manuals related to Softek TDMF are as follows:

• Softek TDMF Open Systems Edition Installation Guide

This manual explains the process of installation and configuration of Softek TDMF.

• Softek TDMF Open Systems Edition Administrator Guide (this manual)

This manual explains the process disk mirroring during normal operations of Softek TDMF.

• Softek TDMF Open Systems Edition Messages Guide

This manual explains the messages of Softek TDMF.

A Note Regarding Descriptions

Softek TDMF Open Systems Edition is referred to as Softek TDMF.

Trademarks

• UNIX is a registered trademark exclusively licensed for X/Open Company Limited.

• Solaris, Sun, Sun Microsystems, Java and all other items related to Java along with the logo are

registered trademarks of Sun Microsystems, inc. in the United States and other countries.

• HP-UX is a registered trademark of the Hewlett-Packard Company.

• AIX is a registered trademark of International Business Machines Corporation in the United States

and other countries.

• ORACLE is the registered trademark of Oracle Corporation

• VxVM is the registered trademark of VERITAS.

• PRIMECLUSTER, SafeCLUSTER, SafeDISK are registered trademarks of Fujitsu Limited.

• All other mentioned services and/or products are registered trademarks of other companies as the

case maybe.

COPYRIGHT

Copyright (C) 2002-2005 FUJITSU LIMITED. All rights reserved.

Copyright (C) 2004-2005 Softek Storage Solutions Corporation. All rights reserved.

The information contained in this manual is the licensed property of FUJITSU LIMITED and Softek

Storage Solutions Corporation.

iii

CONTENTS Chapter 1 Softek TDMF Outline ·········································································································································1

1.1 What is Softek TDMF?························································································································································· 1

1.1.1 Product Highlights························································································································································· 1

1.1.2 Softek TDMF Implementations ································································································································ 1

1.2 System Configuration of Softek TDMF······················································································································· 2

1.3 Softek TDMF – Position Vis-à-vis Operating System ························································································· 3

1.4 Mirroring Configurations······················································································································································ 4

1.4.1 Basic Configuration ······················································································································································ 4

1.4.2 Loopback Configuration ·············································································································································· 4

1.4.3 Symmetric Configuration············································································································································ 5

1.4.4 1:n Configuration···························································································································································· 5

1.4.5 Chaining Configuration ················································································································································ 6

1.5 Supported Platforms ···························································································································································· 7

Chapter 2 Softek TDMF Architecture ·····························································································································9

2.1 Mirroring Architecture ························································································································································· 9

2.2 Components···········································································································································································10

2.2.1 Softek TDMF Master Daemon: in.dtc ··················································································································10

2.2.2 PMD (Primary Mirror Daemon)·······························································································································10

2.2.3 RMD (Remote Mirror Daemon) ······························································································································11

2.2.4 dtc device Driver ·························································································································································11

2.2.5 BAB（Big Asynchronous Buffer）··························································································································11

2.2.6 Pstore (Persistent Store) ········································································································································12

2.2.7 Logical Group································································································································································12

2.2.8 Local Data Device·······················································································································································13

2.2.9 dtc device·······································································································································································13

2.2.10 Mirror Device······························································································································································13

2.2.11 Journal File Directory ·············································································································································13

2.2.12 Configuration File······················································································································································14

2.2.13 Throttles·······································································································································································14

2.3 Operating Modes··································································································································································15

2.3.1 PASSTHRU MODE ·····················································································································································15

2.3.2 NORMAL MODE···························································································································································15

2.3.3 TRACKING MODE·······················································································································································16

2.3.4 REFRESH MODE ·························································································································································16

2.3.5 BACKFRESH MODE···················································································································································18

Chapter 3 Softek TDMF Features·································································································································· 19

3.1 Logical Group ········································································································································································19

3.2 Mirroring Modes····································································································································································20

iv

3.2.1 Asynchronous Mode················································································································································· 20

3.2.2 Synchronous Mode··················································································································································· 20

3.2.3 Near Synchronous Mode········································································································································ 20

3.3 Checkpoint············································································································································································· 21

3.4 Chaining ·················································································································································································· 23

3.5 Tuning······················································································································································································ 24

3.5.1 Network Bandwidth Consumption ······················································································································ 24

3.5.2 Size of Network Data Transmitted ···················································································································· 24

3.5.3 Data Compression ···················································································································································· 24

3.6 Throttles················································································································································································· 25

3.7 Configuration Tool ······························································································································································ 25

3.8 Monitoring Tool ···································································································································································· 26

3.8.1 Performance Monitoring Tool ································································································································ 26

3.8.2 Operation and Status Display Tool ····················································································································· 26

3.8.3 Definition Information and Status Display ········································································································ 26

3.9 Data Synchronization Feature······································································································································· 27

3.9.1 Full Refresh··································································································································································· 27

3.9.2 Smart Refresh······························································································································································ 27

3.9.3 Backfresh······································································································································································· 28

Chapter 4 Softek TDMF Configuration························································································································· 29

4.1 Confirming the License Key·········································································································································· 30

4.2 Starting the Configuration Tool····································································································································· 30

4.2.1 Setting up the BAB Size ········································································································································· 31

4.2.2 How to Define a Logical Group ····························································································································· 33

4.2.3 Defining Primary/Secondary Systems··············································································································· 35

4.2.4 How to Define dtc devices ····································································································································· 38

4.2.5 How to Define Throttles ·········································································································································· 41

4.2.6 How to Define Tuning Parameters ······················································································································ 41

4.3 Distributing the Configuration Files····························································································································· 42

4.4 Starting Softek TDMF······················································································································································· 43

4.5 Checking dtc device Status············································································································································ 44

4.6 Creating the Initial Mirror ················································································································································ 45

4.6.1 Creating an Initial Mirror when Data Exists ····································································································· 45

4.6.2 Creating an Initial Mirror when No Data Exists ······························································································ 47

4.7 Stopping Mirroring ······························································································································································ 48

4.8 Restarting Mirroring ··························································································································································· 50

4.9 Automatic Mount of File Systems································································································································ 51

4.10 Configuring Softek TDMF with an RDBMS ············································································································ 53

4.10.1 Database is Created after Installing Softek TDMF··················································································· 53

4.10.2 In Case the Database is already Created····································································································· 54

v

Chapter 5 Softek TDMF Operation Patterns ············································································································· 57

5.1 Mirroring Patterns······························································································································································57

5.2 Disaster Recovery Operation Pattern·························································································································57

5.2.1 1:1 Configuration··························································································································································58

5.2.2 n:1 Configuration··························································································································································60

5.2.3 Symmetric Configuration··········································································································································61

5.3 Backup Operation Pattern ···············································································································································62

5.3.1 Mirror Device to Tape Backup Operation ·········································································································62

5.3.2 1:N Mirror Device Backup Operation···················································································································64

5.3.3 Using the Chaining Feature to Backup the Mirror Device··········································································67

5.4 Checkpoint Operation························································································································································71

5.4.1 Checkpoint Processing············································································································································71

5.4.2 Checkpoint Shell Scripts ········································································································································75

5.4.3 Considerations, Limitations and Tips·················································································································80

5.5 Loopback Configuration ····················································································································································81

5.6 Defining/Using Throttles ··················································································································································82

5.6.1 Creation of Throttles ·················································································································································82

5.6.2 Applying Throttles·······················································································································································87

5.6.3 Updating/Deleting Throttles ···································································································································88

5.6.4 Throttle Examples ·······················································································································································88

Chapter 6 Softek TDMF Administration······················································································································· 89

6.1 Updating Environment Settings ····································································································································89

6.1.1 Update the BAB Size·················································································································································89

6.1.2 Deletion of Logical Groups ······································································································································90

6.1.3 Addition/Update of dtc device ······························································································································91

6.1.4 Removing the dtc Devices·······································································································································91

6.1.5 Relocation of Pstore ··················································································································································92

6.1.6 Resizing the Journal File Directory······················································································································92

6.1.7 Changing Tunable Parameters ·······························································································································93

6.1.8 Changing the Port Number······································································································································95

6.1.9 Clearing the Pstore ····················································································································································96

6.2 Recovery·················································································································································································97

6.2.1 Primary System Down···············································································································································97

6.2.2 Secondary System Down/Network Failures·····································································································98

6.2.3 BAB Overflow ·······························································································································································99

6.2.4 Failing Over to the Secondary System, Restoring the Primary System···············································99

6.2.5 Data Device Failures··············································································································································· 100

Chapter 7 Configuration Tool·········································································································································101

7.1 Starting the Configuration Tool································································································································· 101

7.2 Screen Layout ·································································································································································· 101

vi

7.3 File Bar ················································································································································································ 102

7.3.1 New Logical Group··················································································································································· 102

7.3.2 Select Logical Group··············································································································································· 103

7.3.3 Reset Logical Group················································································································································ 103

7.3.4 Save Changes ···························································································································································· 103

7.3.5 Exit ················································································································································································· 103

7.4 System Bar ········································································································································································ 104

7.4.1 BAB ·············································································································································································· 104

7.4.2 TCP················································································································································································ 104

7.5 View Bar·············································································································································································· 105

7.5.1 Systems Screen························································································································································ 105

7.5.2 dtc Devices Screen ················································································································································· 107

7.5.3 Throttles Screen······················································································································································· 109

7.5.4 Tunable Parameters Screen ································································································································ 110

Chapter 8 Monitoring Tools ············································································································································113

8.1 dtcperftool ··········································································································································································· 113

8.1.1 Step I： Chart Setup··············································································································································· 114

8.1.2 Step II: Measurements Shown in Chart ··········································································································· 114

8.1.3 Step III: Chart Display············································································································································· 116

8.1.4 Performance Monitoring Files······························································································································ 116

8.2 dtcmonitortool···································································································································································· 117

8.2.1 Status Message Area·············································································································································· 117

8.2.2 Error and Warning Messages································································································································ 117

8.2.3 Logical Group/ dtc Device Status Area·········································································································· 118

8.2.4 Modification and Update Controls ····················································································································· 119

8.3 dtcinfo ··················································································································································································· 119

Chapter 9 Softek TDMF Commands ···························································································································121

9.1 killbackfresh ········································································································································································ 123

9.2 killdtcmaster········································································································································································ 124

9.3 killpmds ················································································································································································· 124

9.4 killrefresh·············································································································································································· 125

9.5 killrmds ·················································································································································································· 125

9.6 launchbackfresh································································································································································· 126

9.7 launchdtcmaster································································································································································ 126

9.8 launchpmds·········································································································································································· 127

9.9 launchrefresh······································································································································································ 128

9.10 dtcbackfresh····································································································································································· 129

9.11 dtccheckpoint ·································································································································································· 130

9.12 dtcconfigtool····································································································································································· 130

vii

9.13 dtcdebugcapture····························································································································································· 132

9.14 dtchostinfo········································································································································································ 132

9.15 dtcinfo················································································································································································· 133

9.16 dtcinit ·················································································································································································· 134

9.17 dtckillbackfresh ······························································································································································· 134

9.18 dtckillpmd ·········································································································································································· 135

9.19 dtckillrefresh ···································································································································································· 135

9.20 dtclicinfo ············································································································································································ 136

9.21 dtcmonitortool ································································································································································· 136

9.22 dtcoverride········································································································································································ 137

9.23 dtcperftool ········································································································································································ 138

9.24 dtcrefresh·········································································································································································· 139

9.25 dtcrmdreco ······································································································································································· 140

9.26 dtcset·················································································································································································· 141

9.27 dtcstart ·············································································································································································· 142

9.28 dtcstop ··············································································································································································· 143

Chapter 10 Softek TDMF Operation Considerations·····························································································145

10.1 Operating System Considerations ························································································································· 145

10.2 Pstore Device ································································································································································ 145

10.3 Journal File Directory Space ··································································································································· 145

10.4 Considerations for Using Checkpoint on HP-UX····························································································· 146

10.5 Consideration for VxVM on Solaris ······················································································································· 146

10.6 Consideration for JFS on AIX ································································································································· 146

Appendix A. Configuration File ······································································································································147

Appendix B. Throttle Refrence······································································································································149

B.1 Throttle Format ································································································································································ 149

B.2 Measurement Keywords ················································································································································ 150

B.3 Actions ················································································································································································· 151

B.4 Action Directives ····························································································································································· 151

B.5 Tunable Action Parameters ········································································································································· 152

B.6 Action Message Substitutions ···································································································································· 152

Appendix C. Tunable Parameters ·································································································································155

C.1 CHUNKDELAY ·································································································································································· 155

C.2 CHUNKSIZE ······································································································································································· 155

C.3 COMPRESSION································································································································································ 155

C.4 MAXSTATFILESIZE ························································································································································ 155

C.5 NETMAXKBPS·································································································································································· 156

C.6 STATINTERVAL······························································································································································· 156

viii

C.7 SYNCMODE········································································································································································ 156

C.8 SYNCMODEDEPTH························································································································································· 156

C.9 SYNCMODETIMEOUT···················································································································································· 157

C.10 TRACETHROTTLE························································································································································ 157

C.11 JOURNAL········································································································································································· 157

Appendix D. Production Operation Examples···········································································································159

D.1 Database Migration Example········································································································································ 159

D.1.1 Migration from Local Data Device to dtc Device························································································ 159

D.1.2 Migration from dtc Device to Mirror Device ································································································· 159

D.2 Migration of a SafeFILE System Example (Solaris) ···························································································· 160

Glossary ··················································································································································································161

1

Chapter 1 Softek TDMF Outline This chapter explains in brief regarding Softek TDMF.

1.1 What is Softek TDMF?

Softek TDMF is a network-based disk mirroring product for AIX, HP-UX, and Solaris that enables

data exchange and synchronization in support of local applications, data sharing among remote sites,

and disaster recovery.

In an outage scenario, Softek TDMF provides a recoverable copy of coherent application data –

that is, a copy of that can be accessed and used – on the secondary system.

This product mirrors disk-based data from devices on the primary system to disk devices on a

secondary system, across any reliable network connection supporting TCP/IP. Data is duplicated in

near real time to ensure integrity between the two systems in the event of hardware failure, natural

disaster, or human intervention. Softek TDMF accomplishes this through time-sequenced transfers of

data from the primary system to the secondary system over the network..

If a failure occurs on the primary system, the secondary system can provide immediate access to

contemporary business-critical data. Both the primary and secondary systems should have sufficient

amounts of disk storage, and adequate network bandwidth to accommodate the flow of data.

Softek TDMF allows you to begin mirroring the existing data by simply incorporating the devices or

volumes where this data is stored into the Softek TDMF configuration. You do not need to repartition

or reformat disks, to reinitialize the file systems, or to export/import data.

1.1.1 Product Highlights

Softek TDMF has the following highlights

Requires no additional hardware, providing there is sufficient physical memory and disk space for

your mirrored data.

Provides continous data mirroring over LAN or WAN, or locally through a loopback connection.

Maintains data coherence on primary and secondary systems.

Significantly reduces data loss during outages.

Recovers automatically from network outages.

Supports planned events such as database migration, “hot” backups, normal system maintenance

such as upgrading operating systems.

1.1.2 Softek TDMF Implementations

This product is uniquely applicable as a data management solution for both planned and unplanned

events. This section gives a brief description of a few relevant features.

Disaster Planning and Recovery

Softek TDMF’s ease of integration into existing environments and the flexibility of configuration

make it the right choice for disaster planning and recovery. Softek TDMF ensures user access to

mission critical data even when the primary system goes down by providing a continously updated

copy of data on the secondary system. Softek TDMF’s approach to continous mirroring of data across

the network drastically reduces data loss in the event of a disaster, and greatly simplifies recovery

operations.

Data Migration When upgrading or moving your data center, it is common to install and prepare a new server while

the existing server continues to provide service. Even with parallel systems, the downtime can be

lengthy when copying, transferring and restoring data from an old server to a new one. This

2

downtime is significantly reduced by Softek TDMF to create a mirror and continously send changes

to the new server until you are ready for a switch over.

Backup Softek TDMF complements tape backups. By using a secondary data set on a remote server,

business critical resources at the primary location are kept available while a tape backup is performed

on the secondary site. Checkpointing is a mechanism for implementing a hot backup environment. For

more information refer to [3.3 Checkpoint].

System Maintenance Softek TDMF can be used to relocate data and applications to a secondary system while the

primary system receives normal system maintenance, such as upgrading the operating system or

application software, adding additional storage and memory, or even replacing the primary system with

a newer model.

1.2 System Configuration of Softek TDMF

Softek TDMF is installed on all systems in the configuration.

In Softek TDMF, the mirror source is called the local device and the mirror target is called the

mirror device. The system containing the local device is called the primary system and the system

containing the mirror device is called the secondary system.

Softek TDMF can also be configured with both the primary and the secondary on the same system

(loopback configuration). For the various kinds of configurations please refer to [1.4 Mirroring

Configurations].

Softek TDMF uses a kernel memory-based buffer cache - called the BAB (Big Asynchronous

Buffer) - on the primary system to track all updates made to the local data device. Softek TDMF

also uses disk based space – called the Pstore(Persistent Store) – to store status information, data

update information etc.

On the secondary system disk based space – called the Journal – is used.

For details please refer to [Chapter 2 Softek TDMF Architecture].

Fig 1.1 System Configuration

NOTE To use Softek TDMF, the operating system version on the primary and the secondary systems should be the

same. For example mirroring between a Solaris 7 and Solaris 8 system, or mirroring between Solaris and AIX

platforms is not possible.

BAB

Pstore

Journal

Local Data Device Mirror Device

Mirroring

LAN/WAN

Primary System Secondary System

Softek TDMF Softek TDMF

3

1.3 Softek TDMF – Position Vis-à-vis Operating System

On the primary system, Softek TDMF installs a dtc device driver between the File System or

Application and the Disk driver or Volume Management software.

On starting Softek TDMF, a dtc device name is created for the device defined as the target for

mirroring. Mirroring is possible when data is written to this dtc device via the dtc driver. For further

details on mirroring please refer to [Chapter 2 Softek TDMF Architecture].

Fig 1.2 Position of the dtc device driver

NOTE If the dtc device is used, mirroring is possible. If dtc device is not used, mirroring is not possible.

Primary System

Disk Device Driver

Dtc device driver

File System

・ ・ ・

Dtc Device Dtc Device

Volume Mgmt. Device Driver

Application Application Application Application

Storage

Mirrored Not mirrored Not mirrored

4

1.4 Mirroring Configurations

Various mirroring configurations are possible in Softek TDMF. Below is an explanation of the

representative mirroring configurations.

Basic configuration

Loopback configuration

Symmetric configuration

1:n configuration

Chaining configuration

1.4.1 Basic Configuration

This is the basic configuration for mirroring devices between systems. Mirroring is performed between

the primary system device (local data device) and the secondary system device (mirror device).

Fig 1.3 Basic Configuration

1.4.2 Loopback Configuration

Since mirroring is performed on a device within the same primary system, this configuration is called

Loopback configuration.

The settings in the case of Loopback configuration are almost similar to that for Basic configuration.

Fig 1.4 Loopback configuration

BAB

Pstore

Journal

Local Data Device Mirror Device

Mirroring

LAN/WAN

Primary System Secondary System

BAB

Pstore

Journal

Local Data Device Mirror Device

Mirroring

Primary/Secondary

5

1.4.3 Symmetric Configuration

This configuration involves configuring a Basic configuration between the systems in a reciprocal

manner. Both the primary and the secondary systems can peform each other’s roles.

Fig 1.5 Symmetric Configuration

1.4.4 1:n Configuration

In this configuration, there is 1 local data device being mirrored to multiple mirror devices.

Fig 1.6 depicts mirroring to multiple mirror devices.

All I/Os on the local data device are mirrored to each mirror device.

The 1:n configuration can also be realized, either using a loopback configuration with multiple mirror

devices or using 1 secondary system with multiple mirror devices.

Fig 1.6 1:n Configuration

BAB

Pstore Journal

Local Data Device Mirror Device

Mirroring

LAN/WAN

Local Data DeviceMirror Device

Mirroring

BAB

Pstore

Primary/Secondary Primary/Secondary

Journal

Journal

Mirror Device

Mirroring

LAN/WAN

Mirror Device

Primary System

Secondary System

Journal

BAB

Pstore

Local Data DeviceLAN/WAN

Secondary System

6

1.4.5 Chaining Configuration

In this configuration, the mirror device of one mirroring configuration acts as the local data device in

another mirroring configuration.

For example, if a device on System A is mirrored to System B, and System B is mirrored to System

C , then the data flows from System A to System B to System C, in that order.

Figure 1.7 depicts a Chaining configuration on the Secondary system. Figure 1.8 depicts Chaining with

a secondary and a 3rd system.

To understand the merits and the uses of Chaining configuration please refer to

[Chapter 5 Softek TDMF Operation Patterns].

Fig 1.7 Chaining Configuration – Pattern 1

Fig 1.8 Chaining Configuration – Pattern 2

Mirror DeviceLocal Data Device

Mirroring

Mirror Device

Primary System Primary/Secondary

Journal

BAB

Pstore

Local Data Device

LAN/WAN

Mirroring

BAB

Pstore

Journal

Mirror Device

Mirroring

LAN/WAN

Mirror Device Local Data Device

Primary/Secondary

Primary/Secondary

Journal

BAB

Pstore

Local Data Device

LAN/WAN

Mirroring

Secondary System

BAB

Pstore

7

1.5 Supported Platforms The versions and other software supported by Softek TDMF on Solaris, HP-UX and AIX are

outlined as below.

[Table 1.1 Solaris Platform]

Category Supported Range Remarks

OS Version Solaris 7,8,9

File System UFS,VxFS

Volume Manager PRIMECLUSTER 4.1 or avove,

SafeDISK,VxVM

DBMS Oracle

Cluster Systems

PRIMECLUSTER 4.1 or above,

SafeCLUSTER 2.0 or above,

Sun Cluster

Regarding

PRIMECLUSTER and

SafeCLUSTER only

1:1standby operation

is supported

Disk Path Manager GRMPD

[Table 1.2 HP-UX Platform]

Category Supported Range Remarks

OS Version 11.0,11i

File System HFS,VxFS

Volume Manager VxVM

DBMS Oracle

Cluster Systems MC/ServiceGuard

Disk Path Manager

[Table 1.3 AIX Platform]

Category Supported Range Remarks

OS Version 5.1(32bit/64bit),5.2(32bit/64bit)

File System JFS,VxFS

Volume Manager VxVM

DBMS Oracle

Cluster Systems HACMP

Disk Path Manager

NOTE To use Softek TDMF, the operating system version on the primary and the secondary systems should be the

same. For example mirroring between a Solaris 7 and Solaris 8 system, or mirroring between Solaris and AIX

platforms is not possible.

8

9

Chapter 2 Softek TDMF Architecture In this chapter, the mirroring architecture of Softek TDMF is explained.

2.1 Mirroring Architecture

All I/Os arising from an application or otherwise on the local data device, pass via the dtc device

driver to the local data device (via the disk device driver) and at the same time is also stored in time

order in the BAB.

The data stored in the BAB is sent via the PMD (Primary Mirror Daemon) to the RMD (Remote

Mirror Daemon) over the network..

The data received by the RMD on the secondary system is written to the mirror device.

Softek TDMF performs mirroring in the above manner.

The detailed explanation for dtc device driver, BAB, PMD and RMD is given in [2.2 Components].

Fig 2.1 Mirroring Architecture

RMD

Primary System

dtc device driver

BAB PMD

Disk Device Driver Disk Device Driver

Data I/O

Secondary System

Local Data Device Mirror Device

LAN/WAN

Mirroring

：Data Flow

10

2.2 Components

Softek TDMF is made up of the following components on the primary and secondary systems.

Explanations for the components follow.

Softek TDMF Master Daemon(in.dtc)

PMD(Primary Mirror Daemon)

RMD(Remote Mirror Daemon)

dtc device driver

BAB(Big Asynchronous Buffer)

Pstore(Persistent store)

Logical Group

Local Data Device

Mirror Device

dtc device

Journal

Configuration File

Throttle

2.2.1 Softek TDMF Master Daemon: in.dtc

The in.dtc is a user mode background program running on both the primary and the secondary

systems and is launched during the installation process. in.dtc establishes and manages PMD and

RMD processes defined for each logical group.

This daemon also launches the process that manages and evaluates throttles for each logical group

of devices. For further details please refer to [3.6 Throttles] and [5.6 Defining/Using Throttles].

2.2.2 PMD (Primary Mirror Daemon)

The PMD is a background process running on the primary system. One PMD for each logical group

is started automatically by the master daemon as part of the system bootscript or using the

launchpmds command.

The PMD drains entries out of the BAB and sends them to the corresponding RMD on the

secondary system.

There is an independent PMD process for each logical group defined on the primary system, so

each logical group can have a connection to a unique secondary system.

Fig 2.2 PMD/RMD

PMD RMD

Basic Configuration

PMD RMD

Multiple Secondary System Configuration

RMD

RMD

PMD

PMD

11

2.2.3 RMD (Remote Mirror Daemon)

The RMD is a background process running on the secondary system launched by in.dtc. The RMD

writes data received over the network from the primary system to the mirror devices.

An RMD is automatically stopped when the corresponding PMD is killed. It can also be stopped using

the killrmds command on the secondary system.

2.2.4 dtc device Driver

As figure 2.3 shows, the dtc driver is installed just above the actual disk device drivers or volume

management device drivers, but below file systems or applications. The dtc device driver supports

both block and special character devices.

Block device drivers are usually limited to transferring blocks of a fixed size and use the buffer

cache as an interface between the driver and the user application or file system.

The special character device allows the dtc device driver to be addressed in units smaller or larger

than the device block. These transfers are performed independently of the file system or buffer

cache, and allow the kernel to transfer data directly to or from the underlying device.

Fig 2.3 Position of the dtc device driver and it’s relationship to data devices

2.2.5 BAB（Big Asynchronous Buffer）

In Softek TDMF, if an I/O is performed on the dtc device, then along with writing the I/O to the

local data device, the data is also written into a large kernel buffer called the BAB. This buffer resides

in the physical kernel memory, owned by the operating system, and must be allocated to Softek TDMF

during the initial configuration. The data written in the BAB (entry) is sent to the secondary system

over the network.

The BAB size must be setup during the initial configuration. It can also be changed later on. For

further details on setting the BAB size please refer to [1.3.3 How to Size the BAB] of the [Softek

TDMF Installation Guide].

BAB

User Mode

Kernel Mode

READ WRITE READ WRITE ioctl

Filesystems

bdevsw

Buffer Cache Buffer Cache

Dtc Device Driver

Local Data Device

12

2.2.6 Pstore (Persistent Store)

Pstore is a disk volume that you specify on the primary system and it stores state information,

tunable parameter definitions, and tracking data. During configuration, you can define one pstore for all

logical groups or one for each logical group.

The minimum required size is 40MB. The maximum required size is 140 MB. Pstore larger than 140 MB

is unnecessary.

It is recommended to create a Pstore of maximum size 140 MB.

2.2.7 Logical Group

As the following figure shows, you can tell Softek TDMF to treat a collection of dtc devices as a

coherent unit, called a logical group. Each logical group operates with it’s own independent PMD/RMD

daemon pair. Logical groups allow time-ordered writing between member dtc devices, and complete

operational and state independence.

Fig 2.4 Logical Group Configuration

Upto a maximum of 1000 logical groups can be defined, with their numbers ranging from 0-999.

Some applications, especially databases, can work with several disk devices at the same time . It is

essential that chronological coherence be maintained between all the dtc devices so that they are in the

same state. You can maintain chronological coherence of I/O transfers by organizing the dtc devices

into a logical grooup.

You may want to define multiple logical groups for the following reasons:

Logical groups can utilize independent network connections to the secondary system, thus

creating an aggregated throughput greater that that of any single network connection.

The failure of one logical group does not affect the operation of the others.

: Local Data Device : Mirror Device

dtc0 dtc1 dtc0 dtc1 dtc0 dtc1

Logical Group: 0 Logical Group : 1 Logical Group : 2

Softek TDMF

13

2.2.8 Local Data Device

A local data device is the mirror source on the primary system. A local data device is defined during

configuration and associated with a corresponding mirror device on the secondary system. The data

on the local data device is sent over the network and finally stored on the mirror device.

2.2.9 dtc device

The dtc device is the means by which applications or file systems interact, access, or store

information within Softek TDMF. A dtc device provides the mapping to and management of a specific

local data device and the corresponding mirror device(s).

During configuration, you give each dtc device instance a unique name within a logical group – for

example, dtc0, dtc12, dtc93. Device names usually begin with 0 and are incremented by 1.

Dtc devices appear as volumes to the kernel, so a dtc device accepts and handles any request that

can be made to a normal volume or fixed-size volume, such as create and mount a file system, or

allocate DBMS tablespace.

Dtc devices are not shared by the primary and the secondary systems. Rather, data is mirrored

across the network from the local data devices to the mirror devices. If you want the secondary

system to assume all activities if the primary system fails, then install application software on both

systems. In a standard Softek TDMF configuration, applications on the secondary system must not be

executed until the system is prepared to act as the application server. The exception is when

checkpoint is active. For more details on preparing for a changeover to the secondary system, please

refer to [5.2.1 1:1 Configuration].

2.2.10 Mirror Device

A mirror device is specified as a special character device (but pertains to both the special

character and corresponding block mode devices) on the secondary system. You must have a mirror

device on the secondary system for each local data device on the primary system. The mirror device

must be the same size or larger than the corresponding local data device.

During normal operation, the mirror devices contain a coherent – that is, usable – copy of the

datastored on the primary system. You can checkpoint the data on these devices, and applications

other than Softek TDMF can open mirror devices in read-only mode. For more information on

checkpoint, please refer to [3.3 Checkpoint].

2.2.11 Journal File Directory

The journal file directory (also referred to as journal), is created on the secondary system, and is

used to store updated data temporarily in the following cases:

• Checkpoint ON state

• Smart Refresh

The journal file directory contains files with the following naming conventions:

j###.###.c（I/O on the local data device during Smart Refresh or Checkpoint ON state）

j###.###.i（Data transmitted during Smart Refresh）

j###.###.p（To indicate that the state is Checkpoint ON state）

The “j” above indicates that this is a journal file. The next 3 numbers indicate the logical group to

which this journal file belongs. The next 3 numbers indicate the order in which the data for the

relevant logical group is received. For example:

j001.002.c （The journal file belongs to Logical Group 1 and this is the 2nd file of consistent

14

data）

Checkpoint ON State

During checkpoint ON state, if there are I/Os on the local data device, these I/Os are transmitted

to the the secondary system and stored in the journal.

During checkpoint ON state, all updated data is accumulated in the journal, and when checkpoint

ON state is removed, the data contained in the journal is applied to the mirror device.

Smart Refresh

Smart Refresh can be set to either use the journal or not use it. It is possible to configure the

usage of journal for each logical group. The default option is to not use the journal. For detail on how

to set up journal usage, please refer to [7.5.4 Tunable Parameters Screen].

In case the journal has been set to be used, then during Smart Refresh the data transmitted is

stored in the journal. Also if there are I/Os on the local data device during Smart Refresh then this

data is transmitted to the secondary and stored in the journal. (The I/Os are treated separately from

the data which is transmitted during Smart Refresh)

During Smart Refresh, the data transmitted to the secondary is accumulated in the journal. When

the transmission of the data is complete, the data in the journal files are applied to the mirror device

one by one. After applying the transmitted data, the I/Os during Smart Refresh are applied to the

mirror disk.

When all the accumulated data has been applied to the mirror device, the mirror device is said to be

in a consistent state.

In the case where the journal is not used, the data transmitted by the Smart Refresh operation is

directly applied to the mirror device. In case of any I/Os on the local data device during Smart

Refresh, this data instead of being transmitted to the secondary system, is recorded in the Pstore.

For further details please refer to [2.3.4 REFRESH MODE].

2.2.12 Configuration File

The configuration file, which stores information regarding the logical group, Pstore and journal

directories, is referred to by Softek TDMF during startup.

The configuration file is created by the Configuration tool. Since the configuration file is created

only on the primary system, the files must be copied to the secondary system. For further details on

how to copy these files to the secondary system please refer to [4.3 Distributing the Configuration

Files].

2.2.13 Throttles

Throttles help you to automate the administration of Softek TDMF. During configuration, you can

define a throttle to alert you to system trends or problems. Throttles help keep a machine operating

within a defined range.

Throttle definitions are defined for each logical group. Softek TDMF evaluates throttles

periodically,based on a tunable parameter, and performs the specified actions.

You can define an unlimited number of throttles for each logical group. Each throttle can have up to

16 ACTIONS executed when the throttle evaluates TRUE. In addition, there can be up to 16 clauses,

or linked tests, in the throttle definition.

For further details on throttle, please refer to [5.6 Defining/Using Throttles].

15

2.3 Operating Modes Softek TDMF, has the following operating modes for each logical group when mirroring:

PASSTHRU

NORMAL

TRACKING

REFRESH

BACKFRESH

Each operating mode and their state transitions are shown in Figure 2.5.

Fig 2.5 Operating Modes and State Transitions

2.3.1 PASSTHRU MODE

The first time the dtc device is started after defining the dtc device, the logical group is in

PASSTHRU mode. In PASSTHRU mode, read/write requests are fulfilled by Softek TDMF devices, but

the dtc device writes only to the local data device. Updates are not transmitted to the BAB and no

data is mirrored to the secondary system.

In this mode mirroring cannot be started and hence to move from PASSTHRU mode to NORMAL

mode a full refresh must be executed.

2.3.2 NORMAL MODE

NORMAL mode indicates that mirroring is being performed normally. The dtc devices handle

read/write requests; updates are applied to local data devices and written to the BAB for normal

transfer to the mirror devices on the secondary system, through the PMD/RMD daemons. In this

mode, Softek TDMF performs continous mirroring to have a coherent, recoverable copy of data on the

secondary system.

NOTE In case the local data device and mirror device are not consistent, use the launchrefresh command to achieve

consistency. In this case using the dtcoverride command and bringing the logical group to TRACKING mode

and then moving it to NORMAL mode, will not give the desired results.

*1: Bypass Refresh to move to NORMAL mode

PASSTHRU TRACKING

NORMAL BACKFRESH

Initial state after dtc

device has been defined

Full Refresh

*1 ・Network failure

・Secondary failure

・Stopping PMD etc

Backfresh Instruction

REFRESH・Full Refresh

・Smart Refresh

・Checksum Refresh

16

2.3.3 TRACKING MODE

TRACKING mode reduces the need for a full refresh in the case of network outage or loss of

communication with the secondary system’s mirror devices. In TRACKING mode, Softek TDMF directs

reads and writes to the dtc devices but entries are not written to the BAB, and mirroring is not

performed. However the updated data information is recorded in the Pstore.

To bring the logical group to NORMAL mode from TRACKING mode, the updated data which is

recorded in the Pstore needs to be transmitted to the secondary. This is done using Smart Refresh.

NOTE In case the logical group goes into TRACKING mode because of network failure or the secondary system

going down etc, and if the mirroring environment is set up correctly, Smart Refresh will be executed

automatically, and the logical group will move to NORMAL mode. However if by using the killpmds command

the logical group is moved intentionally to TRACKING mode manually, then it is necessary to execute Smart

Refresh manually to bring the logical group back to NORMAL mode.

NOTE In the interval after the logical group has moved to TRACKING mode and mirroring being stopped by using the

dtcstop command, if there are any I/Os on the local data device, then these I/Os will not get reflected to the

mirror device. It is necessary, that the next time mirroring is started that the launchrefresh command be

executed so that the updated data gets reflected to the mirror device.

2.3.4 REFRESH MODE

The REFRESH mode represents either Full Refresh, Smart Refresh or Checksum Refresh.

It is possible to access the local data device during the REFRESH mode (both read and write access).

In case the logical group is in PASSTHRU mode or when the PMD/RMD has been stopped, it is

necessary to execute the launchrefresh command to move from the TRACKING mode to the

NORMAL mode.（Please refer to 「9.9 launchrefresh」）

If launchrefresh command is executed, then after the logical group exits the REFRESH mode, it moves

to the NORMAL mode. The launchrefresh command checks if the refresh process is already running

before starting the refresh operation.

During NORMAL mode if the BAB becomes full, the logical group automatically moves to the

REFRESH mode. In this case, Softek TDMF automatically goes into TRACKING mode and then moves to

the REFRESH mode. In the REFRESH mode, data updates are not written into the BAB but are sent

directly to the secondary system over the network.

When the refresh operation is completed, the system moves to NORMAL mode. It is possible to stop

the refresh operation using the killrefresh command.

NOTE If the refresh operation is stopped before completion, then the primary and the secondary system data will

not match.

Full Refresh

A full refresh mirrors every block on the designated local data device(s) to the secondary

system. You use this method to create an initial mirror.

Data updates on the local data device during a full refresh operation are not transmitted to

the secondary but are recorded in the Pstore.

Data is transmitted to the secondary system during a full refresh operation, and is applied

directly to the mirrror devices. If there is a problem during the full refresh operation, the

mirror device will not be in sync with the local data device. Hence the data is coherent only

when the full refresh is complete.

Smart Refresh

17

A smart refresh (the default refresh method) mirrors only those blocks on the local data

device that have changed. It identifies the changed blocks on the local data device based on

the information recorded in the Pstore.

When the BAB becomes full, the system automatically transfers to TRACKING mode and

then to REFRESH mode. When the smart refresh completes, the system goes back to

NORMAL mode.

During a smart refresh operation, if data is updated on the local data device, it is

transmitted to the secondary system.

Based on whether the journal is being used or not, the data transmitted to the secondary

( data transmitted by the smart refresh operation and the data updates on the local data

device) is applied as follows:

• When journal is not used(default)

The data transmitted by the smart refresh operation and the data updates on the local

data device are applied directly to the mirror device.

• When the journal is used

The data transmitted by the smart refresh operation and the data updates to the

local data device are accumulated in the journal.

Once the changed blocks are transmitted by the smart refresh operation and the

journal file accumulation is completed, the accumulated data in the journal is applied

one by one to the mirror device. Once the data has been applied to the mirror

device, the data updates to the local data device during smart refresh which have

been accumulated in the journal are applied.

Again, if during application of the journal there are data updates to the local data

device, these are accumulated in the journal, and once accumulation is completed

this data is applied to the mirror device.

NOTE The coherency of the data cannot be ascertained wither during Smart Refresh or during

the application of the journal files to the mirror device. In case when the journal is not used,

at the completion of the smart refresh process the coherency of the data can be

ascertained. In case when the journal is being used, at the point where the journal is

completely applied to the mirror device the coherency can be ascertained.

Checksum Refresh

A checksum refresh compares all blocks on the local data device with the mirror device,

using a checksum method to identify deltas. Only blocks that have been modified (that is,

those for which the checksum varies) are sent to the secondary system. The data

transmitted to the secondary, as in the case of Smart Refresh, is applied based on whether

the journal is used or not.

18

2.3.5 BACKFRESH MODE

BACKFRESH mode synchronizes the primary system back from the secondary system. Backfresh is

useful when you are performing maintenance on the primary system. A backfresh operation moves all

the blocks of data on the secondary mirror devices that differ from those on the local data devices to

their corresponding locations on the primary system. Softek TDMF compares the blocks on the

primary system with those of the secondary system to detect changes, using a checksum method.

NOTE Backfresh is to be used for maintenance only. During Backfresh, the local data device is not coherent and if any problem occurs, the consistency of the data will be lost and hence it cannot be used. The consistency of the data is achieved when Backfresh operation is completed. During the Backfresh operation, both the mirror device and the local data device cannot be accessed by the application.

NOTE Generally, it is better to perform a full refresh in the reverse configuration to restore the primary system.

19

Chapter 3 Softek TDMF Features This chapter describes the features available in Softek TDMF.

3.1 Logical Group

In Softek TDMF, mirroring is performed per Logical Group (LG).

In a logical group, one or many dtc devices can be registered. ( A dtc device is a pair comprising a

local data device and a mirror device)

In Softek TDMF, start/stop of mirroring, defining and updating configuration information is all

performed at the Logical Group level.

A maximum of 1000 logical groups can be defined with the numbers ranging from 0 to 999.

It is necessary to use unique numbers for logical groups across related system groups.

Fig 3.1 Logical Group Configuration and Numbers

System A System B System C

Logical Group : 0

Logical Group : 1

Logical Group : 2

Logical Group : 3

Logical Group : 4

System D System E

Logical Group: 0

: Local Data Device

: Mirror device

Related System Group

Related System Groups

: Mirroring Flow

20

3.2 Mirroring Modes

Softek TDMF supports the following 3 mirroring modes:

Asynchronous

Synchronous

Near synchronous

3.2.1 Asynchronous Mode

By default, Softek TDMF operates in the Asynchronous mode (Async mode in short).

In Async mode, the disk updates to the local data device are accumulated in the BAB and is

independent of the the transmission of these entries to the secondary system.

The data update request to the local data device is completed after the write to the local data disk

and the acccumulation of the data in the BAB is completed.

3.2.2 Synchronous Mode

In Synchronous mode (Sync mode in short), Softek TDMF does not return control to the application

until after a disk update has been committed to both the primary system’s local data device and the

secondary system’s mirror device. While it is true that in Sync mode, the secondary system always

maintains an exact copy of the primary, it is important to consider the transmission of the data before

trying to compare the data. Also depending on the state of the network, the performance of the

system may deteriorate considerably.

3.2.3 Near Synchronous Mode

Near Synchronous mode is a middle ground between Async and Sync. In Near Synchronous mode ,

disk updates accumulate in the BAB asynchronously until they reach the limite allowed, at which time

I/O operations are blocked by the application to allow updates to be written to the secondary system,

until the entries in the BAB fall below this tunable limit.Not only does Near Sync mode improve on the

Sync mode performance, but it also ensures that data on the secondary system’s mirror device(s) is

no more than a fixed number of disk updates behind the primary system.

NOTE If network bandwidth cannot be guaranteed or if Softek TDMF is planned for disaster recovery purposes

please do not select Synchronous mode as the mirroring operation.

21

3.3 Checkpoint A checkpoint is a frozen snapshot of a data set at a specific point in time.

A checkpoint allows you to take the secondary mirror off-line from Softek TDMF and make it

available for read-only access by other applications. In the NORMAL mode, it is not possible to

access the secondary device. Once the checkpoint state is removed, accessing the secondary device

is not allowed.

In order to take a snapshot, it is necessary to ensure that all data updates to the local data devicea

are written to the disk. It is better to flush all data which remains in memory to disk for applications

such as file systems or databases. (In case of file systems an unmount operation will flush data to

the disk. For databases, depending on the vendor, appropriate tools can be used to flush data to the

disk.)

After executing the checkpoint command, it is possible to resume access to the local data device

on the primary side. (In case a file system has been unmounted, the file system can be remounted and

the business application can be restarted)

During checkpoint, if there are any data updates to the local data device then these are transmitted

via the BAB and accumulated in the journal on the secondary system. After the usage of the mirror

device on the secondary has been completed and the checkpoint state has been turned off, the data

accumulated in the journal is applied to the mirror device and the logical group returns to the original

NORMAL mode.

Starting checkpoint is called as Checkpoint ON and to stop checkpoint is called as Checkpoint OFF.

Checkpoint ON can be implemented only if the state of the logical group is NORMAL. If the logical group

is in REFRESH mode, then until the mode does not move into NORMAL mode, checkpoint cannot be

started.

By using checkpoint, the mirror device on the secondary system can be backed on tape while the

mirroring can continue unstopped.

To understand the usage and settings for checkpoint, please refer to [5.4 Checkpoint Operation].

Fg 3.2 Operation Using Checkpoint

Backup ServerApplication Server Application Server

Mirroring Mirroring

Local Data Device Local Data DeviceMirror Device

BackupBackup

22

Fig 3.3 Checkpoint Process

Primary System Secondary System

LAN/WANSoftek TDMF Softek TDMF

Local Data Device Mirror Device

Inaccessible

Primary System Secondary System

LAN/WANSoftek TDMF Softek TDMF

Local Data Device Mirror Device

Accessible

Journal

Journal

Data

Data Data

Data DataData

Data

Data

: Data Flow

Primary System Secondary System

LAN/WANSoftek TDMF Softek TDMF

Local Data Device Mirror Device

Inaccessible

Journal

Data DataData Data Data

Checkpoint ON

Checkpoint

NORMAL Mode

NORMAL Mode

Checkpoint OFF

23

3.4 Chaining

The chaining feature can be used to supplement configurations using the Checkpoint functionality.

In a 1:1 mirroring configuration, if data is updated during checkpoint ON state, the data is

accumulated in the journal at the secondary system. In this period if the local data device encounters

an error for some reason, the data updates during checkpoint will be lost. (The data upto the point

when checkpoint was started will remain valid.) Or again if the primary system goes down, then after

the primary system is recovered, it will become necessary to execute a full refresh.

If the chaining configuration is used, the above problems can be resolved, by providing a continous

mirror and also providing access (read-only) to the mirror device.

For example a chain exists between System A -> System B -> System C. System B is the mirror

for System A and System C is the mirror for System B. Even if a checkpoint is executed between

System B and System C, the mirror between System A and System B continues uninterrupted. At

the same time System C’s mirror device can be accessed in read-only mode.

Fig 3.4 Chaining

NOTE The number of devices required are in proportion to the length of the chain in the Chaining

configuration.

An example of an application using a Chaining configuration is given in Fig 3.5. For the actual

settings required please refer to [Chapter 5 Softek TDMF Operation Patterns].

Fig 3.5 Operation Using Chaining Configuration (Tape Backup)

Device A (Local Data Device)

Device B (Mirror/Local Data Device)

Device C Mirror device

Mirroring(Normal) Checkpoint ON

Data updates Read-only accessMaintain mirror for A

Backup ServerApplication Server

Mirroring

Local Data Device (Device A)

LAN/WAN

Checkpoint ON

(Create Snapshot)

Checkpoint OFF

(Mirroring)

Backup

Mirror Device(Device B)

Mirror Device (Device C)

24

3.5 Tuning

In Softek TDMF, the following parameters, related to network data transfer between the primary

system and the secondary system, can be tuned.

Network bandwidth consumption

Size of network data transmitted

Data compression when transmitting

The above parameters, can be set using either the configuration tool or the dtcset command, at the

logical group level. For further details on usage, please refer to [Appendix C. Tunable Parameters].

3.5.1 Network Bandwidth Consumption

The network bandwidth load arising from the transmission of accumulated data in the BAB via the

PMD to the RMD, can be adjusted in the following two ways:

Set a limit to the maximum network bandwidth consumption

Adjust the timing at which the data is sent

Set a Limit to the Maximum Network Bandwidth Consumption

This feature, when used, does not allow the rate of data transmission (KB/sec) to exceed the set

value, thereby limiting the consumption of the network bandwidth used by Softek TDMF.

This feature can be implemented by setting the parameter NETMAXKBPS using the dtcset

command. For further details on how to set this parameter using the dtcset command please refer to

[Chapter 9 Commands].

Adjust the timing at which the data is sent

This functionality, when used, reduces the network bandwidth consumption by introducing a fixed

time delay at which the PMD will extract data from the BAB and transmit.

This functionality can be implemented by setting the tuning parameter CHUNKDELAY. For further

details on how to set this parameter please refer to [Chapter 7 Configuration Tool].

3.5.2 Size of Network Data Transmitted

It is possible to adjust the amount of data sent in each transmission by the PMD, when it extracts

data from the BAB and transmits to the RMD.

The size of the data sent by Softek TDMF in each transmission, as a default, is 2048KB.

NOTE If the actual I/O data size is larger than the set value, there is a possibility of BAB overflow.

This functionality can be implemented using the tuning parameter CHUNKSIZE.. For further

detailson how to set this parameter, please refer to [Chapter 7 Configuration Tool].

3.5.3 Data Compression

It is possible to compress the data sent in each transmission of the PMD, which it extracts from

the BAB and transmits to the RMD.

As a default, Softek TDMF compresses trivial zero filled blocks before transmitting it.

If this feature is used, then even data apart from continous null data blocks can be compressed.

After PMD has extracted the data from the BAB, it compresses the data and then transmits it to

the RMD. The RMD uncompresses this data and applies it to the mirror device. In case the journal is

being used the behaviour is the same.

This functionality can be implemented by using the tuning parameter COMPRESSION. For further

details on how to set this parameter, please refer to [Chapter 7 Configuration Tool].

25

3.6 Throttles

Throttles are a collection of statements which when defined can help to administer Softek TDMF in

the most suitable manner. Using throttles, we can monitor different elements of Softek TDMF, measure

important parameters and based on their values peform appropriate actions.

Throttles is a feature where logical groups can be monitored for certain parameters and when these

parameters reach a certain value, a prescribed action can be executed.

For further details regarding creation and usage of throttles please refer to [5.6 Defining/Using

Throttles].

3.7 Configuration Tool

Using the configuration tool, the mirroring environment and its components can be defined in Softek

TDMF.

For further details regarding usage of the configuration tool please refer to[Chapter 4 Softek TDMF

Configuration] and [Chapter 7 Configuration Tool].

Using the configuration tool the following environmental parameters and components can be defined.

BAB Size

Create/Update/Deletion of Logical Groups

Create/Update/Deletion of dtc devices

Setting up of tunable parameters

Set up of throttles

Set up of the master daemon port number

26

3.8 Monitoring Tool

Using the monitoring tool one can monitor the system in real time. The following three types of

tools are provided as monitoring tools

Performance monitoring tool (dtcperftool command)

Operation and status display tool (dtcmonitortool command)

Definition information and status display tool (dtcinfo command)

3.8.1 Performance Monitoring Tool

The performance monitoring tool measures the following performance parameters along with

providing diagrams and ability to save the data in files.

The actual data transmitted over the network

The number of BAB entries waiting to be transmitted

The % of entries awaiting transmission in the BAB

The % of data transmitted during (back) refresh.

The rate at which data is read from the local data device

The rate at which the data is written to the local data device

3.8.2 Operation and Status Display Tool

With this tool the information regarding the current operation and the status of the logical groups of

Softek TDMF can be confirmed.

Device definitions, initialization information, message history and logical group/dtc device

information can be confirmed.

3.8.3 Definition Information and Status Display

With this tool, the BAB size information and the operating modes of the dtc devices can be

confirmed.

27

3.9 Data Synchronization Feature

This feature is used to synchronize data between the local data device and the mirror device.

Softek TDMF, provides the following three types of data synchronization methods to create/maintain

the mirror. For further details of each of the methods below, please refer to [2.3.4 REFRESH MODE].

Full Refresh

Smart Refresh

Backfresh

3.9.1 Full Refresh

Full Refresh is a feature in which the all the data blocks on the local data device are copied to the

mirror device to synchronize data.

This feature can be implemented when a –f option is used with the launchrefresh command.

When Full Refresh is executed, all the data blocks on the local data device are transmitted to the

secondary mirror device and are applied to the mirror device. It is possible to access the local data

device during a Full Refresh.

This functionality is used during the following cases:

• For a newly created logical group (dtc device) to create the initial mirror.

• After the data on the mirror device is updated, it becomes necessary to synchronize data with

the local data device

(For example, during checkpoint, the mirror device gets updated when it is mounted.)

3.9.2 Smart Refresh

Smart Refresh is a feature in which only the different data blocks that have been updated are

transmitted to the secondary system to synchronize data.

Difference in data blocks arises when the system moves from NORMAL mode to TRACKING mode

or when the system is in checkpoint mode and there are data updates to the local data device.

(Depending on the timing, even data updates to the local data device during NORMAL state can be

included.)

Data synchronization can be achieved by transmitting only the different data blocks from the

primary to the secondary. In cases where Smart Refresh can be used it is a much faster method to

achieve data synchronization as compared to the Full Refresh method.

This functionality can be implemented with the launchrefresh command.

Smart Refresh can synchronize data, either by Softek TDMF automatically launching the process or

by the manual execution of the process. Under the following cases it is possible to synchronize data

using the Smart Refresh feature.

[Automatic launching of the Smart Refresh process]

• When network connection is lost and after restoration of the network

• When the secondary system goes down and after it is booted up successfully

• When the BAB overflows (If BAB overflow retry is exceeded then it is not launched)

[Manual launching of the Smart Refresh process]

• When the primary system goes down and after it is booted up successfully.

• After the PMD is stopped (by executing the killpmds command)

• After restarting (dtcstart) a logical group which was stopped (dtcstop)

• After the number of retries for a BAB overflow are exceeded

28

3.9.3 Backfresh

Backfresh is a feature in which only the different data blocks on the mirror device are copied to the

local data device in order to achieve data equivalence.

The different data blocks are detected using the checksum method to compare each data block on

the local and mirror data device.

During backfresh, both the local and mirror data devices are locked and it is not possible to access

them.

29

Chapter 4 Softek TDMF Configuration In this chapter, configuration of Softek TDMF and the steps upto the point of starting Softek TDMF

operation are described. The example and description in this chapter is based on the example for a Basic

Configuration required for mirroring explained in [1.4.1 Basic Configuration]. For the other configurations

please refer to [Chapter 5 Softek TDMF Operation Patterns].

Before starting the configuration process described in this chapter, it is necessary to have installed

Softek TDMF as per the [Softek TDMF Open System Edition Installation Guide].

The basic steps and flow to be followed after installing Softek TDMF is described as below.

Fig 4.1 Configuration – Steps and Flow

4.2 Startup of the Configuration tool

4.1 Confirmation and setup of license key

4.2.1 Setup of BAB Size (required initially)

4.2.4 Registering the dtc device

4.2.5 Setup for throttles (optional) NOTE: Possible to setup and update later

4.2.6 Setup of Tuning Parameters (required) NOTE: Possible to use default values

4.3 Distribution of the configuration files (required)

4.6 Creating the initial mirror

4.7 Stopping mirroring

4.8 Restarting the mirror

4.2.3 Registering the primary and secondary ・Host name or IP Address (required)

・Pstore and Journal directory setup (required)

・ Port number setup (default:575)

・Setup for Chaining (default:No)

Using the Configuration Tool

(A part of it can be done by

commands)

Manual setup

Manual Setup

Executed using commands

4.2.2 Creating the Logical Group

4.4 Starting Softek TDMF

4.5 Confirming dtc device status

30

4.1 Confirming the License Key

A license key is required to perform mirroring using Softek TDMF. To confirm if the correct license

key is installed please run the following command.

To apply for and setup the license key, please refer to the details in [Softek TDMF Open Systems

Edition Installation Guide].

[Solaris/HP-UX]

/opt/SFTKdtc/bin/dtclicinfo

［AIX]

/usr/dtc/bin/dtclicinfo

If the correct license is installed the following message will be displayed.

Permanent license is valid for this system

If a message other than the above message is displayed, the correct license key has not been

installed. Please arrange to setup the correct license key (an application is required in case license key

has not been received).

To apply for and setup the license key, please refer to the details in [Softek TDMF Open Systems

Edition Installation Guide].

4.2 Starting the Configuration Tool

To start the mirroring operation using Softek TDMF, it is required to first configure the environment

and its components.

The configuration is performed on the primary system using the configuration tool. This

configuration process creates a configuration file. The following environmental parameters and

components can be setup (create/update/delete).

• BAB Size

• Primary/Secondary systems

• Logical Groups

• Dtc devices

• Throttles

• Tuning Parameters

To start the configuration tool execute the following command on a system prompt.

[Solaris、HP-UX]

/opt/SFTKdtc/bin/dtcconfigtool

[AIX]

/usr/dtc/bin/dtcconfigtool

NOTE Please run the configuration tool only on the primary system.

31

4.2.1 Setting up the BAB Size

The first time dtcconfigtool is run, it displays an informational message shown in Figure 4.2 that

explains the BAB size needs to be defined.

From the second time onwards this message is not displayed and instead Figure 4.5 is shown when

the configuration tool is started.

Fig 4.2 Initial Message Displayed by dtcconfigtool

1. On click of OK, Figure 4.3 is displayed.

2. Allocate memory for the BAB by using the up and down arrows, or simply position the cursor in

the box and enter a new value. The default BAB size is 512 MB. It is preferable to set the BAB

size to at least at 32 MB and below the actual physical memory available.

Please refer to [1.3.3 How to Size the BAB] of [Softek TDMF Open Systems Edition

Installation Guide] to determine the appropriate BAB size.

Fig 4.3 Defining BAB Size

NOTE If a value greater than the actual physical memory is chosen, then a message as shown in Figure

4.4.is displayed. The message describes that since the size set is greater than actual memory

available the configuration tool will forcibly select the appropriate value. (In Figure 4.4, a size of 512 MB was setup, but this has been changed to 204 MB.)

32

Fig 4.4 Changing BAB Size Forcibly

3. On click of OK Figure 4.5 is displayed.

This screen is also displayed when the configuration tool is started from the second time

onwards. In case the BAB size needs to be changed, select System -> BAB from the menu to

get Figure 4.3 where the BAB size can be changed.

Fig 4.5 System Setup Screen （Initial State）

33

4.2.2 How to Define a Logical Group

In order to mirror, it is necessary to create a logical group.

When the configuration tool is first started, it opens in the edit mode for logical group 0.

Figure 4.5 is a screen for logical group 0.

To create a logical group other than 0, please perform the following operation.

1. Select File -> New Logical Group.

Fig 4.6 Selecting New Logical Group

2. Use the arrow keys to select the logical group for editing.

On click of OK button Figure 4.8 is displayed.

Fig 4.7 Setup Screen For New Logical Group

34

The screen below is the dialog box for the logical group to be created or updated. It is possible to

define information for each corresponding logical group. To define information regarding each logical

group please refer from [4.2.3 Defining Primary/Secondary Systems] to [4.2.6 How to Define Tuning

Parameters].

Fig 4.8 Defining Primary and Secondary Systems

35

4.2.3 Defining Primary/Secondary Systems

The following information is required to define the primary and secondary systems for a created logical

group as shown in Figure 4.8

Host name or IP address of the primary system

Pstore

Host name or IP Adddress of the secondary system

Journal file directory

Port number

Chaining option

Host Name or IP Address of the Primary System

In the Hostname or IP Address: text box in the Primary System area, the hostname of the machine

on which the configuration tool is currently running is automatically displayed. (In case of defining a

new logical group)

Either use this name as is, or enter a valid host name or IP Address.

For a loopback configuration (where the mirroring takes place on the same machine) please enter

the following:

• In case hostname is used : localhost

• In case IP Address is used: 127.0.0.1

NOTE In case of a loopback configuration, always use either localhost or 127.0.0.1.

NOTE In case of a loopback configuration, even the hostname or IP Address for the secondary system should be set as localhost or 127.0.0.1.

Pstore

In the Persistent Store Device text box of the Primary System area, enter the slice or volume name

for the Pstore. A dedicated slice is required for Pstore use.

The Pstore can be defined by either entering the device name or by using the drop down list

provided which gives a list of devices present on the primary system.

The drop down list gives a list of slices(disks) that are available on the system. It also provides

information on which slices(disks) are currently in use (mounted by some other applications or

being used by Softek TDMF) by displaying an INUSE. Please do not select a slice(disk) with a INUSE.

One Pstore can be defined for each logical group or one Pstore can be defined for all logical groups.

NOTE If an INUSE slice is used to define the Pstore, there is a chance that the data on this slice might

corrupted. Hence always ascertain that the slice is not being used before defining it as a Pstore slice.

NOTE Do not use a slice with cylinder starting at 0 for the Pstore. In case such a slice is selected, the

entire disk may get corrupted.

36

Fig 4.9 Defining Pstore

Host Name or IP Address of the Secondary System

In the Hostname or IP Address text box in the Secondary System area enter either the host name

or IP Address of the secondary system.

In case of a loopback configuration, please enter the following values:

• In case host name is used :localhost

• In case IP Address is used : 127.0.0.1

NOTE In case of a loopback configuration, for both the primary and secondary systems, either localhost

or 127.0.0.1 is set.

Journal File Directory

In the text box Journal Directory, please enter a directory on the secondary system which can be

used as the journal directory.

37

Port Number

In case a port number other than 575 needs to be used on the secondary system, enter the new

port number in the Port text box. This is the port number used by all the logical groups to

communicate with the secondary system.

This port number is the same as the port number referred to in section [7.4.2 TCP] for the in.dtc

master daemon.

Chaining Option

In case it is necessary, the defined secondary systems can be updated to support Chaining.

(Default is no chaining). For further details regarding chaining, please refer to [5.3.3 Using the

Chaining Feature to Backup the Mirror Device].

Fig 4.10 Defining the Secondary System

38

4.2.4 How to Define dtc devices

The dtc device is defined in the newly created logical group.

The definition of the dtc device is a pair comprising of the local data device and the mirror device.

1. Please select the dtc Devices tab as indicated in the figure below.

Fig 4.11 Definition of dtc device

2. The default name for the dtc devices start from dtc0. It is not necessary that the dtc devices

should be numbered in order. However it is necessary that the dtc device name be of the format

dtc + number.Using the up and down arrow keys, select a number to attach to the dtc device

name. Or directly place the cursor in the text box and enter the number desired.

NOTE The dtc device name is incremented by 1 when a new device is added. However this name can be

changed. It is necessary that the dtc device name within the same logical group have a unique

name. However the same dtc device name can be used across logical groups.

39

Fig 4.12 Selecting Local Data Devices

3. The Data Device can be selected from the drop down list. In the drop down list for both the local

data devices and the mirror devices, all started volumes and dtc devices can be referenced.

NOTE In the case of Volume Managers like SafeDISK(Solaris), it is necessary to register the raw device

name as the dtc device. In case the drop down list does not contain the raw device name, it can be

entered directly in the text box for Data Device. After clicking the Commit Device button, a dialog asking for confirmation will be displayed. Click on the Force Commit button.

4. From the drop down list select the mirror device.

NOTE Each mirror device should be of at least the same size as that of the corresponding local data

device. In the case of Volume Managers like SafeDISK(Solaris), it is necessary to register the raw

device name as the dtc device. In case the drop down list does not contain the raw device name, it

can be entered directly in the text box for Mirror Device. After clicking on the Commit Device button, a dialog asking for confirmation will be displayed. Click on the Force Commit button.

40

5. In case the definition of the local data device and mirror device is completed, please click on

Commit Device.

Fig 4.13 Registration of the dtc device

6. In case a new dtc device needs to be added to the current logical group, please click on Create

New Device.

7. The above steps are to be repeated till all dtc devices for the logical group are defined. Once the

definitions are completed the dtcconfigtool can be closed. Before exiting the dtcconfigtool a

message confirming whether changes made are to be saved will pop up.

NOTE Softek TDMF does not copy the 0th sector of physical disk. This is because the 0th sector

contains the disk label and the VTOC information.

41

4.2.5 How to Define Throttles

Setting up throttles is an optional part of the configuration. Regarding the creation of throttles

please refer to [3.6 Throttles] and [5.6 Defining/Using Throttles].

4.2.6 How to Define Tuning Parameters

Tuning parameters is an optional part of Softek TDMF configuration. For the setting of different

parameters please refer to [Appendix C. Tunable Parameters].

Fig 4.14 Defining Tuning Parameters

42

4.3 Distributing the Configuration Files

After defining or updating the logical groups using the configuration tool, it is necessary to

distribute the created/updated configuration files to the secondary system.

In Softek TDMF, the logical group information is used by both the primary and the secondary

systems.

The configuration file uses the following naming convention:

[p | s]###.cfg

p and s are used to represent primary and secondary systems respectively.

### represents the logical group number.

All configuration related files with p###.cfg are copied to the secondary system and are

renamed as s###.cfg.

1. The configuration files are copied to the same directory location on the secondary system as

that of the primary system. (using either ftp or rcp)

The configuration files are created under the following directory on the primary system.

[Solaris/HP-UX]

/etc/opt/SFTKdtc

［AIX]

/etc/dtc/lib

2. The files copied to the secondary system should be renamed to s###.cfg.

For example (Solaris or HP-UX)

Primary system: /etc/opt/SFTKdtc/p000.cfg

Secondary system: /etc/opt/SFTKdtc/s000.cfg

For the distribution of files for the Chaining or symmetrical configurations please refer to

[Chapter 5 Softek TDMF Operation Patterns].

NOTE In case of an update to the configuration file on the primary system, it is necessary to distribute the updated

file to the secondary system. After copying the file, it is necessary to restart the logical group.

NOTE The dtcstart command refers to the .cfg file and it is at this point that the updated contents become valid.

The tuning parameters are not stored in the .cfg file. Hence changing these does not necessitate copying the

file to the secondary.

NOTE During normal operation of Softek TDMF, the configuration file is referred to often. (For example when the

dtcinfo command is used or when the PMD daemon is launched using the launchpmds command.)

NOTE To ensure that all the components of Softek TDMF use the same information as that of the dtc device driver,

when the logical group is started a copy of the file is created. Since this contains the current configuration

information, the file is created with a .cur extension.

NOTE Only the dtcstart command refers to the .cfg file during processing. The rest of the commands refer to

the .cur file. When the group is stopped, the .cur file is deleted and it is at this point that changes can be

reflected to the .cfg file. Based on this, configuration can be updated for optional logical groups and these

changes can be made valid at a defined time.

43

4.4 Starting Softek TDMF

After distributing the configuration files to the secondary, Softek TDMF can be started. However in

case it is necessary, please cleart the Pstore before starting Softek TDMF.

Clearing the Pstore may be necessary in the following cases:

• The corresponding logical groups that are using the Pstore have not been started even once.

• In case a logical group or dtc device has been deleted.

(It is necessary to stop all corresponding logical groups that are using the Pstore.)

For further details regarding clearing of the Pstore, please refer to [6.1.9 Clearing the Pstore] and

[9.16 dtcinit」

Executing the following command will start the logical groups.

[Solaris/HP-UX]

/opt/SFTKdtc/bin/dtcstart -a

[AIX]

/usr/dtc/bin/dtcstart -a

The above command will start all the dtc devices for all logical groups. Specific logical groups can

also be started. For further details , please refer to [9.27 dtcstart].

When Softek TDMF is started the dtc device is created. If I/O occurs on these created dtc devices

then mirroring is performed by Softek TDMF.

The created dtc device names are as follows (Logical Group: 10 dtc device: 0)

Block Device Name ：/dev/dtc/lg10/dsk/dtc0

Character Device Name：/dev/dtc/lg10/rdsk/dtc0

Based on the logical group number and the dtc device number, the underlined portion above

changes.

When a newly created dtc device is started for the first time it is in the PASSTHRU mode.

In the PASSTHRU mode since mirroring has not yet been established all data writes to the dtc device

will be written to the local data device only.

When the initial mirror is created, the mode changes from PASSTHRU to NORMAL. For details

regarding the PASSTHRU and NORMAL modes please refer to [2.3 Operating Modes].

44

4.5 Checking dtc device Status

The current status of the dtc device can be checked using either the dtcinfo command or by using

the dtcmonitortool.

The dtcinfo command can be used (only if the dtcstart command has already been executed) to

check the status of the running dtc device. In case the dtcstop command has been executed and the

dtc device is not running then the dtcinfo command can not be used to check the status of the dtc

device.

For further details regarding the dtcinfo command, please refer to [9.15 dtcinfo].

If the dtcmonitortool command is executed, then the dtcmonitortool screen is displayed and the

status of the dtc device can be confirmed. For further details refer to [8.2 dtcmonitortool」 and [9.21

dtcmonitortool].

Figure 4.15 displays the status of a newly created logical group after dtcstart command has been

executed.

Fig 4.15 Status of a Newly Created Logical Group After Executing dtcstart

45

4.6 Creating the Initial Mirror

After Softek TDMF has been started, and if the dtc device is in a PASSTHRU mode, to synchronize

data it is necessary to create the initial mirror.

Creating the initial mirror brings the logical group to a NORMAL mode and mirroring (data I/Os on

the local data device are applied to the mirror device) can take place using Softek TDMF.

Creating the initial mirror is an operation that synchronizes data between the local data device and

the mirror device.

This operation can vary based on the state of the local data device.

In case data already exists on the local data device

No data exists (or an unformatted disk etc)

Existing data refers to user data, control or management data of the device or the file system.

4.6.1 Creating an Initial Mirror when Data Exists

In case data already exists on the local data device, it is necessary to create an initial copy of the

data on the mirror device.

In this case the following 2 methods can be used.

Perform a full refresh using the launchrefresh command. (recommended)

Courier Transport Method(CTM)

Using the launchrefresh command

The steps to be are followed are described below.

1. On the primary system execute the following command

launchrefresh -fa

The command, transmits all data blocks of all data devices to the mirror device where they

are applied.

2. It is possible to start using the local data device (dtc device) while the full refresh is being

executed. (It is possible to read/write to the dtc device)

NOTE The mirror device cannot be used until the full refresh completes.

3. If during full refresh, if any of the systems (primary or secondary) go down, on successful reboot

of the system the full refresh restarts.

4. By using the dtcinfo command, or dtcmonitortool or the dtcperftool the progress of the full

refresh operation can be monitored.

After full refresh is completed, the dtc device changes to NORMAL mode.

46

Using the Courier Transport Method(CTM)

This method is most valid when the data to be synchronized is very large and the estimated time

for the full refresh operation to complete is very long. Please follow the steps below.

1. On the primary system using the following command bring Softek TDMF to NORMAL mode.

dtcoverride -a state normal

2. On the primary system using the following command bring Softek TDMF to TRACKING mode.

dtcoverride -a state tracking

At this point the application can be started.

3. On the secondary system the following command is executed.

dtcrmdreco -a

4. On the primary system, a backup image of the local data device is taken on tape. For example

the following command is used.

dd if=<Local Data Device Name> of=<Tape Device Name> bs=32k

NOTE Make certain that the backup is not file based but disk based.

5. Restore the tape backup on the secondary system, using the following command. (In case the dd

command was used in step 4)

dd if=<Tape Device Name> of=<Mirror Data Device Name> bs=32k

6. After the data has been applied to the mirror device, execute the following command on the

secondary.

dtcrmdreco -ad

7. Next execute the smart refresh operation. This will release the logical group from TRACKING

mode and start the transmission of data to the secondary system. The data transmitted to the

secondary are I/Os to the local data device from Step 2 onwards where the logical group is

moved to TRACKING mode.

launchrefresh -a

After the data is transmitted to the secondary, Softek TDMF moves to NORMAL mode and normal

mirroring can be started.

47

4.6.2 Creating an Initial Mirror when No Data Exists

In cases where no data exists on the disk, such as when the disk has just been added to the

system, the dtcoverride command can be used to create the initial mirror.

Usage of dtcoverride

Create the initial mirror as follows:

1. Using the dtcoverride command the logical group is moved to NORMAL mode. The PMD is

started automatically.

dtcoverride -a state normal

NOTE With this method, data synchronization is more a matter of administrative settings and the actual

physical data on disk do not match. After setting the system to a data synchronized state, newly created

or updated data is mirrored from the local data device to the mirror device. However physical blocks

which do not contain file data does not match. If the blocks on the local data device and mirror device

are compared they will not match. If the physical blocks need to be compared please do not use this

method to achieve data synchronization.

48

4.7 Stopping Mirroring

Normally, mirroring by Softek TDMF is done when the system is in NORMAL mode. However in

case of planned shutdowns/maintenance, it is necessary to shutdown mirroring safely.

The following describes the procedure for shutting down mirroring with Softek TDMF.

1. Shutdown all applications using the dtc devices.

2. Unmount the file systems mounted on the dtc devices.

3. To ascertain that all the data has been copied to the mirror device, execute the following

command.

dtccheckpoint -on -a

If the above command completes normally, the following message will be displayed in the

messages area of the dtcmonitortool screen. (### represents the logical group number)

DTC： [INFO / CPON]： logical group [RMD_###] is in checkpoint mode

4. To release the checkpoint enforced in step 3, execute the following command.

dtccheckpoint -off -a

If the above command completes normally, the following message will be displayed in the

messages area of the dtcmonitortool screen. (### represents the logical group number)

DTC： [INFO / CPOFF]： logical group [RMD_###] successfully transitioned out of checkpoint mode

5. Execute the following command to stop mirroring for all logical groups.

killpmds -a

6. The dtcmonitortool screen will change as follows. The logical groups will be in TRACKING mode

at this time.

Fig 4.16 dtc device Status After killpmds command is executed

49

7. By executing the following command, all logical groups are brought to a complete stop.

dtcstop -a

8. The information related to all the logical groups will be removed from the dtcmonitortool screen.

Fig 4.17 dtc device Status After dtcstop command is executed

50

4.8 Restarting Mirroring

In this section, the procedure to restart mirroring if it was stopped as per [4.7 Stopping Mirroring]

is described.

1. By executing the following command the logical groups are restarted. The example describes the

procedure for starting each logical group individually.

dtcstart -g <group#>

2. The dtcmonitortool will change as follows and the logical group will be in TRACKING mode.

Fig 4.18 dtc device Status After dtcstart command is executed

3. Using the following command the local data device and mirror device are synchronized.

launchrefresh –g <group#>

4. The dtcmonitortool will change as follows and the logical group will move to NORMAL mode.

Fig 4.19 dtc device Status After launchrefresh command is executed

5. Start the applications using the dtc devices on the primary systems. (Mounting of file systems

etc)

4.9 Automatic Mount of File Systems

Each operating system has a file which defines the mount information.

[Solaris]

/etc/vfstab

[HP-UX]

/etc/fstab

[AIX]

/etc/filesystems

Using the above files it is possible to mount file systems automatically when the system starts up.

For Softek TDMF, if in the above files the dtc device name is defined, it is possible to automatically

mount the dtc devices file systems. In case the file already contains the device name which will be

used as a dtc device, then it is necessary to change it’s name to that of the dtc device. In case it is

required to mount during system startup define the dtc device mount information in the above

mentioned files.

In the case of defining the dtc device information for Solaris, please prefix the information with a

#DTC#. This is a keyword which is used by Softek TDMF to detect dtc devices to be mounted on

Solaris. At the time of system startup Softek TDMF will read this file and search for the above

keyword and mount any dtc devices found. Again, at the time of normal system shutdown, Softek

TDMF will read this file and unmount all dtc devices detected.

Please refer to the following examples

[Solaris]

[

[

/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 yes -

#DTC# /dev/dtc/lg0/dsk/dtc0 /dev/dtc/lg0/rdsk/dtc0 /test1 ufs 5 yes -

#DTC# /dev/dtc/lg1/dsk/dtc0 /dev/dtc/lg1/rdsk/dtc0 /test2 ufs 5 yes -

HP-UX]

AIX]

/dev/vg00/rvol5 /data hfs defaults 0 2

/dev/dtc/lg0/dsk/dtc0 /test1 hfs defaults 0 2

/dev/dtc/lg1/dsk/dtc0 /test2 hfs defaults 0 2

/DATA:

dev = /dev/data

vfs = jfs

log = /dev/data_log

mount = true

check = true

options = rw

account = false

/TDMFTEST:

dev = /dev/dtc/lg1/dsk/dtc0

vfs = jfs

log = /dev/dtc/lg1/dsk/dtc1

mount = true

check = true

options = rw

account = true

51

52

NOTE In case the dtc device definition is not commented for Solaris, then at the time of system startup, the

system may go into single user mode.

Please ensure that when the dtc device information is updated or removed, the corresponding system file

should be changed accordingly.

In case a file system is being mirrored by Softek TDMF, the device to be mounted for the file

system will be the dtc device. The dtc device is created when the logical group is started and hence it

becomes necessary to start the logical group before attempting to mount the file system using the

dtc device.

Softek TDMF provides a startup script which executes during system startup. In this shell script, all

logical groups that were running during the time of system shutdown, are started up at the time of

system startup. After this, the system file containing the mount information is read, and if a dtc

device is defined in the file, the file system is mounted and the logical group is moved to NORMAL

mode.

53

4.10 Configuring Softek TDMF with an RDBMS

In this section, configuring Softek TDMF with an RDBMS is explained.

Many production database environments install the database on top of raw disk partitions rather

than on top of file systems. These raw disk partitions may actually be volumes created either by

VxVM or volume managers.

When the databsae is created, it stores the paths to these raw disk devices as part of the database

itself. This is a challenge for Softek TDMF, or for any disaster recovery scheme that needs to

restore the database on another computer whose disk layout may not be identical to the disk layout

of the original machine.

The configuration that is required in Softek TDMF to handle RDBMS situations as above, is

explained below.

4.10.1 Database is Created after Installing Softek TDMF

The solution is to specify a symbolic link path rather than the actual path to the raw disk or volume

when creating the database. The method is illustrated in the following example.

[Example]

The example considers a database created on raw disk devices that are actually striped volumes.

The normal specification to the RDBMS software would be:

TABLESPACE A：/dev/vx/rdsk/sybasedg/vol01

TABLESPACE A：/dev/vx/rdsk/sybasedg/vol02

TABLESPACE A：/dev/vx/rdsk/sybasedg/vol03

Sybase is used in this example, but this applies to Oracle or other RDBMS packages as well. Use

the following procedure instead:

1. Create symbolic link definitions to these volumes and give those paths to the database.

mkdir /dev/devlinks

ln -s /dev/vx/rdsk/sybasedg/vol01 /dev/devlinks/tblspA

ln -s /dev/vx/rdsk/sybasedg/vol02 /dev/devlinks/tblspB

ln -s /dev/vx/rdsk/sybasedg/vol03 /dev/devlinks/tblspC

TABLESPACE A：/dev/devlinks/tblspA

TABLESPACE A：/dev/devlinks/tblspA

TABLESPACE A：/dev/devlinks/tblspA

2. Create and popluate the database as you would normally.

3. Shut down the database.

4. Install Softek TDMF and configure it to mirror these volumes; change the symbolic links to point

to the created dtc devices instead of the original raw disks or volumes.

5. Follow the usual steps for creating dtc devices. Do not start the PMDs yet.

6. Create the symbolic links.

rm /dev/devlinks/tblspA

ln -s /dev/dtc/lg0/rdsk/dtc0 /dev/devlinks/tblspA

rm /dev/devlinks/tblspB

ln -s /dev/dtc/lg0/rdsk/dtc0 /dev/devlinks/tblspB

rm /dev/devlinks/tblspC

ln -s /dev/dtc/lg0/rdsk/dtc0 /dev/devlinks/tblspC

7. Start Softek TDMF for the target logical group.

dtcstart -g 0

54

8. To bring the logical group to NORMAL mode execute the following command.

launchrefresh -f -g 0

9. Monitor whether the group has moved to NORMAL mode or not using the dtcmonitortool.

10. Most RDBMS must own the raw device against which they perform I/O. Therefore, you must

change the ownership of the actual dtc devices involved as follows:

killpmds -g 0

chown -R sybase:sybase /dev/dtc/lg0

launchrefresh -g 0

11. Now you can bring up the database so that it accesses its data through the dtc devices, and all

updates are mirrored to the secondary system.

NOTE Most RDBMS systems configured for client/server operations capture system identification for the RDBMS

server in configuration files or in the database itself. Attempting to bring up the RDBMS on the secondary

system after a switch-over without correcting this server’s identification, results in warnings or fatal errors.

A RDBMS should never be run on a secondary system without a legal right to do so under the licensing

terms from the database vendor.

4.10.2 In Case the Database is already Created

You many encounter a situation in which a database uses the absolute path to the raw disk

devices.For example, the database is created on the 3 devices as below.

Device 1: /dev/dsk/c1t0d0s4

Device 2: /dev/dsk/c1t0d0s5

Device 3: /dev/dsk/c1t0d0s6

In order to start mirroring on a database created as described above, the following steps must be

followed:

1. Shutdown the database

2. Using the mv command change the path names.

mv /dev/dsk/c1t0d0s4 /dev/dsk/vol1

mv /dev/dsk/c1t0d0s5 /dev/dsk/vol2

mv /dev/dsk/c1t0d0s6 /dev/dsk/vol3

mv /dev/rdsk/c1t0d0s4 /dev/rdsk/vol1

mv /dev/rdsk/c1t0d0s5 /dev/rdsk/vol2

mv /dev/rdsk/c1t0d0s6 /dev/rdsk/vol3

3. Install Softek TDMF and configure the above volumes so that they can be mirrored. In this case

the name of the local data device is the updated name in Step 2.

4. Start Softek TDMF logical group.

dtcstart -g 0

5. Create the following symbolic links.

ln -s /dev/dtc/lg0/dsk/dtc0 /dev/dsk/c1t0d0s4

ln -s /dev/dtc/lg0/dsk/dtc1 /dev/dsk/c1t0d0s5

ln -s /dev/dtc/lg0/dsk/dtc2 /dev/dsk/c1t0d0s6

ln -s /dev/dtc/lg0/rdsk/dtc0 /dev/dsk/c1t0d0s4

ln -s /dev/dtc/lg0/rdsk/dtc1 /dev/dsk/c1t0d0s5

ln -s /dev/dtc/lg0/rdsk/dtc2 /dev/dsk/c1t0d0s6

6. Move the logical group to NORMAL mode by executing the following command.

55

launchrefresh -f -g 0

7. Monitor if the logical group has moved to NORMAL mode using the dtcmonitor tool.

8. Start the database. The database will now access the data via the dtc device and all the contents

of the database will be mirrored to the secondary system.

57

Chapter 5 Softek TDMF Operation Patterns

This chapter explains the various patterns available for mirroring Softek TDMF’s along with their

setup and operational methods.

5.1 Mirroring Patterns

The following mirroring patterns can be realized with Softek TDMF.

Disaster Recovery Operation

In case some trouble occurs at the primary system site, it is possible to continue

operations on the secondary system.

Backup Operation

In case the local data device has some problems or the data is lost, a backup of the mirror

device is arranged, where the data from the mirror device is backed up to a tape.

Distributed Data Operation

An operation, where data is distributed from one system to many systems is possible.

Data Migration Operation

Change in storage devices etc which leads to data migration is also possible.

In Softek TDMF, in addition to the above operations, Checkpoint and Chaining features can be

combined to provide a reduced chance of data loss, guarantee data safety clearly, and realize

automated operations.

From the next section onwards, the operating pattern, the method for configuring the environment

and operating procedures will be explained.

5.2 Disaster Recovery Operation Pattern

As a part of Disaster Recovery operation, in case the primary system suffers some damage,

(including system down, system trouble etc) the procedure to continue operations on the secondary

system is described. In case further details regarding recovery of the operations on the primary

system are required (without transferring operations to the secondary), please refer to

[6.2 Recovery].

As examples of Disaster Recovery operations, the following three patterns are available. However

these are all basically similar to the 1:1 configuration and hence their operating procedures are

similar to a 1:1 configuration.

• 1:1 Configuration

This is a 1:1 configuration between the primary and the secondary system.

• n:1 Configuration

Multiple primary systems mirror to a single secondary system.

• Symmetric Configuration

Two systems, mutually mirror to each other as a Disaster Recovery solution.

58

5.2.1 1:1 Configuration

System Configuration

In this configuration, the business application is run on the primary system under normal

circumstances. In case of disaster or primary system suffering damages, the business application is

run on the secondary system.

Fig 5.1 1:1 Disaster Recovery Configuration

Configuring the Environment

For details regarding the procedure of building the environment, please refer to[Chapter 4 Softek

TDMF Configuration].

Operating Procedures

Under normal circumstances, the business application is run on the dtc device of the primary

system.

In case of disaster or primary system suffering damages, using the following procedure, the business

application can be run on the secondary system.

1. To protect the mirror device, execute the following command on the secondary system. For

further details please refer to [9.25 dtcrmdreco].

dtcrmdreco -g <group#>

2. Using the command below, RMD is stopped. The RMD is normally shut down automatically

when it detects that the primary system has gone down. However since the detection takes

some time, it is better to make sure that the mirroring is stopped by executing the command

below. In case the RMD is already stopped, an error message is output which can be ignored.

killrmds -g <group#>

3. In case the mirror devices are to be mounted on file systems, execute the fsck command for

these mirror devices.

4. In case of file systems, mount them.

5. Start the application..

Recovery Procedure

When the primary system is recovered, and in case the application needs to be run on the primary

system again, the data on the mirror device of the secondary system needs to be migrated to the

primary system.

To recover the data on the primary system, the operations on the secondary system must be

stopped.

Mirroring

Mirror Device

Primary System Secondary System

Journal

BAB

Pstore

Local Data Device

LAN/WAN

Application Application

dtc device

59

The data can be recovered, either by using a tape backup, or by transferring the data over the

network, or by using Softek TDMF.

In case Softek TDMF is used, the system configuration and procedures are explained below.

Fig 5.2 Data Recovery System Configuration

1. Recover the primary system. In case the system had to be recreated, re-install Softek TDMF.

2. Make the secondary system’s mirror device as the local data device and the primary

system’s local data device as the mirror device and create a separate logical group.

(Corresponds to logical group 1 in Figure 5.2)

Set up the logical group using the configuration tool.

3. Shutdown the secondary system’s operations. (Shutdown the business application and/or

unmount file systems)

4. On the secondary system execute the following command to start Softek TDMF.

dtcstart -g <group#>

5. On the secondary system execute the following command and copy all the data using full

refresh.

launchrefresh -fg <group#>

6. During the full refresh it is possible to restart the secondary system operations. If the

operations are started, make sure that the dtc devices are being used so that mirroring is

effective.

7. After full refresh is completed, confirm that the logical group is in NORMAL mode. In case

the business application has been restarted on the secondary, choose a suitable time to

shutdown the application.

8. On the secondary system, execute the following command, and stop the logical group (dtc

device).

killpmds -g <group#>

dtcstop -g <group#>

9. In case Softek TDMF was re-installed on the primary system, it will become necessary to

create the logical group. (Corresponding to logical group 0 in Figure 5.2)

The logical group is created using the configuration tool. Overwrite the configuration file

Mirroring

Primary System Secondary System

JournalBAB

Pstore

LAN/WAN

dtc device

BAB

Pstore

Journal

dtc device

Logical Group: 0

Logical Group : 1 Mirroring

Normal Mirroring

Data Recovery

60

created on the secondary system.

10. On the secondary system execute the following command.

dtcrmdreco -d -g <group#>

11. On the primary system, run the following command and start the logical group.

dtcstart -g <group#>

12. On the primary system run the following command and bring the logical group to NORMAL

mode.

dtcoverride -g <group#> state normal

13. In case of file systems, mount the dtc device and restart the business application.

NOTE The logical group created in Step 9 above (corresponding to logical group 0 in Figure 5.2) can also be

created in advance. However when the primary system is recovered, and if Softek TDMF needs to be

re-installed, or if the previously used dtc devices are changed, then creating the logical group in advance

may render it invalid.

5.2.2 n:1 Configuration

System Configuration

In this configuration, the business application runs on multiple primary systems, and if each of these

primary systems fail, then the business application is run on one secondary system.

Fig 5.3 n:1 Disaster Recovery System Configuration

Mirroring Mirror Device

Primary System Secondary System

Journal

BAB

Pstore

Local Data Device

LAN/WAN

Application Application

dtc device

Primary System

BAB

Pstore

Local Data Device

Application

dtc device

Mirror Device Mirroring

61

Configuring the Environment

Follow the procedure for creating a 1:1 configuration for each primary system.

Operating Procedure

It is the same as that for 1:1 configuration.

Recovery Procedure

Execute the same procedure as for 1:1 configuration for the primary system in need of recovery.

5.2.3 Symmetric Configuration

System Configuration

In this configuration, the primary and the secondary reciprocate as each other’s disaster recovery

backup.

Fig 5.4 Symmetric Disaster Recovery System Configuration

Configuring the Environment

The procedure is the same as that for 1:1 configuration and must be performed on both the

systems.

Operating Procedure

It is the same as that of 1:1 configuration. However only the target logical groups are operated on.

Recovery Procedure

It is the same as that for 1:1 configuration for the concerned logical groups.

Mirroring

Mirror

Primary/Secondary System Primary/Secondary System

JournalBAB

Pstore

Local Data Device

LAN/WAN

Application 1 Application 1

dtc device

Mirror Device Local Data Device

BAB

Pstore

Journal

Application 2Application 2 Mirroring

62

5.3 Backup Operation Pattern

Using Softek TDMF, the mirror device can be backed up (generations) and saved. Again, the mirror

device can also be backed up to tape using a tape device.

Softek TDMF can be used for backup operation in the following three ways.

• Mirror device to tape backup operation

• 1:n mirror device backup operation

• Mirror device backup operation using the Chaining option

5.3.1 Mirror Device to Tape Backup Operation

System Configuration

This is the configuration where the mirror device on the secondary system is backed up to a tape.

Even in a loopback configuration, the tape backup can be performed. The procedure is the same for

loopback configuration also.

Fig 5.5 Mirror Device to Tape Backup Operation

Configuring the Environment

For details on building the environment please refer to [Chapter 4 Softek TDMF Configuration].

Operating Procedure

The data that is required to be backed up to tape from the mirror device is first committed. In order

to commit the data to be backed up, if the application is running on the primary system it is shutdown

or if the file system is in a mounted state, it is umounted and the data is flushed to the disk.

After this, using either of the methods below, data updates to the mirror device are stopped.

• Move from NORMAL mode to TRACKING mode

Execute the following command to move from NORMAL mode to TRACKING mode.

killpmds -g <group#>

Once in TRACKING mode, the data updates to the local data device will not be transmitted

to the mirror device, but the updated information will be stored in the Pstore.

• Implementation of Checkpoint

Execute the following command to implement checkpoint. Even though checkpoint is

implemented, the operating mode continues to remain in NORMAL mode.

dtccheckpoint -g <group#> -on

In the Checkpoint ON state, the I/Os on the local data device are transmitted to the

secondary and are accumulated in the journal. This is not applied to the mirror device.

For further details regarding checkpoint, please refer to [5.4 Checkpoint Operation].

Mirroring

Mirror Device

Primary System Secondary System

Journal

BAB

Pstore

Local Data Device

LAN/WAN

dtc device

Backup

63

Using either of the above methods data updates on the mirror device can be stopped, and the

mirror device can be mounted as a file system. During this state the data on the mirror device can be

backed up to a tape.

NOTE Please use the mirror device in the read-only mode. In case the data on the mirror device is updated then

the data between the local data device and the mirror device will not be in sync.

Once the tape backup is completed, the mirror device is umounted, and the usage of the mirror

device is brought to an end.

Next, we return to the previous mirroring state (NORMAL mode). The recovery method is different

depending on the method chosen to stop data updates to the mirror device as described above. For

each method an explanation is provided below.

• In case the logical group is in TRACKING mode

By executing the following command, the logical group can be moved from TRACKING to

NORMAL.

launchrefresh -g <group#>

The data updates that occurred during TRACKING mode are applied to the mirror device

and data is synchronized.

• In case Checkpoint ON is implemented

By executing the following command, the checkpoint OFF state can be realized.

dtccheckpoint -g <group#> -off

When the Checkpoint is turned OFF, the data accumulated in the journal is applied to the

mirror device and data is synchronized.

For further details regarding checkpoint please refer to [5.4 Checkpoint Operation].

If using checkpoint, it is possible to execute a script which will set checkpoint to ON, perform the

backup and set checkpoint to OFF. For further details regarding this script please refer to [5.4

Checkpoint Operation].

64

5.3.2 1:N Mirror Device Backup Operation

System Configuration

This configuration consists of mirroring from 1 local data device on the primary system to multiple

mirror devices on the secondary system.

It is possible to save the backup of each mirror device as a generation. In this section, the

procedure to save one generation has been explained. In case multiple generations need to be saved

multiple generation mirror devices need to be added.

Fig 5.6 1:n Mirror Device Backup Operation

Configuring the Environment

For details regarding the setup of the environment please refer to [Chapter 4 Softek TDMF

Configuration].

For this system environment, the logical groups are created as follows. While actually creating the

devices please change the names Device A, Device B1 and Device B2 with the actual names of the

devices being used.

Table 5.1 1:n Configuration

Logical Group

No

dtc device Local Data Device Mirror Device

lg0 dtc0 Device A Device B1

lg1 dtc0 lg0-dtc0(Device A) Device B2

Mirroring

Mirror Device

Primary System Secondary System

Journal

BAB

Pstore

Local Data Device

LAN/WAN

dtc device

Mirroring

GenerationDevice A

Device B1

Device B2

lg0-dtc0 is the dtc device created in logical group lg0.

Fig 5.6.1 1:N Logical Group Configuration

lg0

lg1 Device A

Device B2

Device B1

dtc0

dtc0

Write

When a write is performed on dtc0 of lg1, the data is written to device A, device B1 and device B2.

65

To create the logical groups, first logical group lg0 is created. Next the dtc device registered in

logical group lg0, is treated as a local data device for the creation of logical group lg1.

The following is the procedure.

1. Start the configuration tool

2. Create logical group lg0.

3. Create logical group lg1. The local data device should be defined as the dtc device of logical

group lg0.

The dtc device of the logical group lg0 will not be displayed in the drop down list of devices.

Hence directly enter the device name as follows.

/dev/dtc/lg0/rdsk/dtc0

4. Distribute the configuration files on the secondary. For further details please refer to [Chapter 4

Softek TDMF Configuration].

5. Start the logical group lg0. Let the logical group lg0 remain in PASSTHRU mode.

dtcstart -g 0

6. Start the logical group lg1.

dtcstart -g 1

7. Execute the following command to create the initial mirror for logical group lg1.

launchrefresh -g 1 -f

8. Execute the following command to create the initial mirror for logical group lg0.

launchrefresh -g 0 -f

9. Creation or mount of the file system should be done for the dtc device dtc0 of the logical group

lg1.

/dev/dtc/lg1/[r]dsk/dtc0

NOTE If the logical group lg1 is started before the logical group lg0 is started up correctly, it will lead to an error.

This is because the local data device of logical group lg1, is the dtc device of the logical group lg0.

A dtc device is created when the logical group is started (dtcstart).

Operating Procedure

Once the environment is configured, the business application can be started using the dtc device.

Creation of the file system or data reads/writes should be performed with respect to the dtc device

of logical group lg1.

The backup is taken keeping one of the logical groups in the NORMAL mode with mirroring

proceeding uninterrupted, while the other logical group is moved to either TRACKING mode or

checkpoint ON mode and backup of the device belonging to this logical group is performed.

When the backup is implemented next, reverse the logical groups and perform the backup.

The procedure to take the backup is explained below.

66

[Creation of the First Generation Backup]

1. The business application running on the primary system is stopped and all data in memory is

flushed to the disk. (In case of file systems, an unmount operation will flush all data to the

disk.)

2. Move the logical group lg0 to either TRACKING mode or in checkpoint ON mode. With this

operation the backup is completed.

• Setting the group to TRACKING mode

Executing the following command move the logical group from NORMAL to TRACKING

mode.

killpmds -g <group#>

In TRACKING mode, the I/Os on the local data device are not transmitted to the

secondary, but instead are tracked in the Pstore.

• Setting checkpoint ON

Executing the following command, move the logical group to checkpoint ON mode.

Even though the checkpoint is ON, the logical group will continue to be in NORMAL

mode.

dtccheckpoint -g <group#> -on

In the checkpoint ON state, the I/Os on the local data device are transmitted to the

secondary and are accumulated in the journal. However these are not applied to the

mirror device.

For further details regarding checkpoint feature please refer to [5.4 Checkpoint

Operation].

[Creation of the Second Generation Backup (In case First Generation is destroyed)]

3. Move the logical group lg0 back to NORMAL mode or put the logical group to checkpoint

OFF state and synchronize data.

• Moving back to NORMAL mode

By executing the following command, the logical group moves from TRACKING to

NORMAL mode.

launchrefresh -g <group#>

The data updates during TRACKING mode, are applied to the mirror device, and the

group moves to NORMAL mode synchronizing data.

• Setting Checkpoint OFF

By executing the following command the checkpoint OFF status can be set.

dtccheckpoint -g <group#> -off

When the checkpoint is set to OFF, the data accumulated in the journal on the

secondary system is applied to the mirror device and the data is synchronized.

For further details regarding checkpoint feature please refer to [5.4 Checkpoint

Operation].

4. The business application running on the primary system is stopped and all data in memory is

flushed to the disk. (In case of file systems, an unmount operation will flush all data to the

disk.)

5. Perform Step 2 with respect to logical group 1.

6. After this to take the backup for either of the logical groups please perform Steps 3 to 5 .

67

5.3.3 Using the Chaining Feature to Backup the Mirror Device

System Configuration

In this configuration, the first mirror (device A -> device B) is between the primary system (local

data device) and the secondary system and the second mirror is between the secondary system,

where the mirror device is used as the local data device, and other mirror devices (device B -> device

C). The second mirror is used as the backup.

If this configuration is used, the network bandwidth used is lesser compare to a 1:n configuration. In

a 1:n configuration, the network bandwidth used is the [I/Os on the local data device X number of

mirror devices]. However in this configuration, the network bandwidth used amounts only to the

I/Os on the local data device.

Fig 5.7 Backup of Mirror Device Using Chaining

Configuring the Environment

To configure this environment, first the second mirror is configured (device B -> Device C1, C2, C3)

and then the first mirror is configured (device A -> device B).

For details regarding starting and using the configuration tool please refer to [Chapter 4 Softek

TDMF Configuration].

In this configuration, the logical groups are created as follows.

[Table 5.2 Logical Groups for the Second Mirror(Configuration on System Y)]

Logical Group No Dtc device Local Data Device Mirror Device

lg100 dtc0 Device B Device C1

lg101 dtc0 lg100-dtc0(Device B) Device C2

lg102 dtc0 lg101-dtc0(Device B) Device C3

Mirroring

Mirror Device (Generation Backup)

Primary System (System X) Secondary System (System Y)

Journal

BAB

Pstore

Local Data Device

LAN/WAN

dtc device

Mirroring

Mirror and Local Data Device

BAB

Pstore

dtc device

Device C1 Device C2 Device C3

Device B

Device A

lg100-dtc0(Device B) is the dtc device created for logical group lg100.

lg101-dtc0(Device B) is the dtc device created for logical group lg101.

68

[Table 5.3 Logical Groups for the First Mirror(Configuration on System X) ]

Logical Group No Dtc device Local Data Device Mirror Device

lg0 dtc0 Device A lg102-dtc0(Device B)

To c

lg101

The

[Co

1.

2.

3.

4.

5.

6.

Wr

lg102-dtc0(Device B) is the dtc device created for logical group lg102

Fig 5.7.1 Logical Group Configuration for Chaining

reate the logical groups, first create the logical groups on the secondary system i.e lg100,

and lg102 and then create the logical group lg0 on the primary system.

procedure is as explained below.

nfiguring the Second Mirror (Setting of Device B -> Device C1, C2, C3)]

Start the configuration tool on the secondary system.

Create the logical group lg100 with the local data device as device B and the mirror device as

device C1.

Create the logical group lg101 with the local data device as the dtc device created for lg100.

The dtc device for lg100 will not be displayed in the drop down list and hence directly enter the

device name in the text box.

/dev/dtc/lg100/rdsk/dtc0

Create the logical group lg102 with the local data device as the dtc device created for lg101.

The dtc device created for lg101 will not be displayed in the drop down list and hence directly

enter the device name in the text box.

/dev/dtc/lg101/rdsk/dtc0

Distribute the configuration files. For further details please refer to [Chapter 4 Softek TDMF

Configuration].

Start the logical group lg100. Keep the logical group in the PASSTHRU mode.

If a write is performed on dtc0 of lg0, then this is transmitted to device A, device B and device C1 to C3.

lg100

Device B

Device C1

lg101

Device C2

dtc0 (lg100)

dtc0 (lg101)

lg102

Device C3

ite

dtc0 (lg102)

Device A

lg0

dtc0 (lg0)

69

dtcstart -g 100

7. Start the logical group lg101. Keep the logical group in the PASSTHRU mode.

dtcstart -g 101

8. Start the logical group lg102. Keep the logical group in PASSTHRU mode.

dtcstart -g 102

[Configuring the First Mirror (Setup of Device A -> Device B)]

9. Start the configuration tool on the primary system.

10. Create the logical group lg0. At this point select the Yes option for the Allow Chaining feature in

the Systems tab of the screen. The mirror device is defined as the dtc device for logical group

lg102. In case the logical group lg102 is not started then the device name will not be displayed in

the drop down list. In this case directly enter the device name.

/dev/dtc/lg102/rdsk/dtc0

11. Distribute the configuration files. For further details please refer to [Chapter 4 Softek TDMF

Configuration].

12. Star the logical group lg0. It is necessary for the logical groups lg100 to lg102 on the secondary

system to be started and be in PASSTHRU mode.

dtcstart -g 0

13. On the primary system, execute the following command to create the initial mirror.

launchrefresh -g 0 -f

14. On the secondary system, execute the following command to create the initial mirror for lg102.

launchrefresh -g 102 -f

15. On the secondary system, execute the following command to create the initial mirror for lg101.

launchrefresh -g 101 -f

16. On the secondary system, execute the following command to create the initial mirror for lg100.

launchrefresh -g 100 -f

17. Creating or mounting the file system should be performed for the dtc device dtc0 of the logical

group lg0.

/dev/dtc/lg0/[r]dsk/dtc0

18. On the secondary system, keep one of the logical groups in the NORMAL mode (in this case

lg100) and the others in either the TRACKING or the checkpoint ON state. (in this case lg102,

lg101)

killpmds -g 102 or dtccheckpoint -on -g 102

killpmds -g 101 or dtccheckpoint -on -g 101

NOTE If the logical group lg0 is started before the logical groups lg100 to lg102, then this will result in an error.

This is because the mirror device of lg0 is the dtc device of lg102. A dtc device is not created unless the

logical group is started.

70

The environment indicated below can be configured as per the procedure above.

Fig 5.8 Initial State of the Backup Operation Using Chaining

Operating Procedure

Under normal circumstances, the mirroring between Device A and Device B will be in NORMAL

mode.

The mirror between Device B and Device C1 to C3, will, depending on the timing of the backup, be

in either TRACKING mode or in checkpoint ON state. The procedure to create the backup is as

follows.

[Creation of the First Generation Backup]

1. The business application running on the primary system is stopped and all data in memory is

flushed to the disk. (In case of file systems, an unmount operation will flush all data to the

disk.)

2. Confirm that all the data has been applied to device B.

3. Move the logical group lg100 on the secondary to either TRACKING mode or to checkpoint

ON mode. With this operation the backup is completed.

• Setting the group to TRACKING mode

By executing the following command move the logical group from NORMAL to

TRACKING mode.

killpmds -g <group#>

• Setting checkpoint ON

By executing the following command move the logical group to checkpoint ON mode.

Even though the checkpoint is ON, the logical group will continue to be in NORMAL

mode.

dtccheckpoint -g <group#> -on

For further details regarding checkpoint, please refer to [5.4 Checkpoint Operation].

4. Restart the business application on the primary system.

5. On the secondary system, move the logical group lg101 to NORMAL mode or set checkpoint

to OFF.

[Creation of the Second Generation Backup]

6. Perform steps 1 to 5. In step 3, the logical group is lg101. The logical group in step 5 is lg102.

NORMAL Mode NORMAL Mode

Checkpoint: ON

TRACKING Mode

Device A Device B Device C1

Device C2

Device C3

Primary System Secondary System

OR

71

5.4 Checkpoint Operation

A checkpoint is a frozen snapshot of a data set at a specific point in time. For further details

regarding the checkpoint feature please refer to [3.3 Checkpoint].

A checkpoint allows you to take the secondary mirror device off-line from Softek TDMF and make

it available for read-only access by other applications.

If the checkpoint feature is used, it can be automated using the checkpoint shell scripts.

In this section the following is explained.

• Checkpoint Processing

• Checkpoint Shell Scripts

• Considerations, Limitations and Tips

5.4.1 Checkpoint Processing

The dtccheckpoint command is used to activate the checkpoint feature. If the –on option is used

with the dtccheckpoint command, then the logical group goes into checkpoint ON state and a

snapshot of the data can be taken. If the –off option is used with the dtccheckpoint command the

checkpoint state is released. During checkpoint ON state, the mirror device can be used in read-only

mode. For further details regarding the dtccheckpoint command please refer to [9.11 dtccheckpoint].

Before bringing the logical group to a checkpoint ON state, it is necessary to stop the application

and flush all data to the disk. (In case the data remains in the operating system or file system memory,

it becomes necessary to unmount the file system and flush the data to the disk.). After the logical

group moves to checkpoint ON state, mount the file system and/or restart the application.

During checkpoint ON state, any I/Os on the local data device are transmitted to the secondary

and this data is accumulated in the journal. The data is not directly applied to the mirror device. The

data on the mirror device after the checkpoint ON state is achieved, can be guaranteed to be in sync.

Once the checkpoint is turned OFF, the accumulated data in the journal gets applied to the mirror

device on completion of which the data on the local data device and the mirror device are in sync.

NOTE The dtccheckpoint command can be executed from either the primary or the secondary system.

In case the mirror device is mounted as a file system during checkpoint ON state, it should be done

so in read-only mode. Also in case fsck command is run, it should be done in report-only and non-

modifying mode.

[Solaris]

# fsck -n <Device Name> # mount -o ro <Device Name> <mount point>

[HP-UX]

# mount -F <File System Type> -r <Device Name> <Mount Point>

［AIX]

# fsck -n <Device Name> # mount -V jfs -o ro -o log=<Device Name> <Mount Point>

Figure 5.8.1 explains the checkpoint operation and process flow.

72

Fig 5.8.1 Procedure for Checkpoint Operation

[Explanation]

1. Stop access to the local data device and flush the data in the memory cache to the disk.

(Flushing of data)

2. Set to checkpoint ON state and take a snapshot of the data.

When the dtcccheckpoint command is used with the –on option, the checkpoint ON token is set

in the BAB, and this gets transmitted to the secondary. The data updates are recorded in the

BAB and are sent in time order to the secondary.

Primary System Secondary System

2. Execute checkpoint ON

dtccheckpoint -on -g <group#>

4. Confirm checkpoint status

1. Stop access to the dtc device and flush

all data in memory to the disk.

7. Start using the mirror device (Mount the file system and/or backup the device and/or start an application)

Checkpoint -on token 3. Recognize checkpoint -on token

6. Restart access to the dtc device (Mount the file system and/or restart the application)

8. End using the mirror device (Unmount the file system etc)

9. Release the checkpoint

dtccheckpoint -off -g <group#>

10. Recognize checkpoint -off token

～

～

5. Confirm checkpoint status

checkpoint -off token

11. Apply journal data to mirror device

・The numbers indicate the order of the process. However 4, 5 and 6, 7 can be executed in parallel.

・The dotted portions 3, 10 and 11 are processes executed by Softek TDMF.

・The other text boxes represent the actions to be taken by the administrator.

・Operation 2 which is normally performed after Operation 1 and hence executed on the primary system, can

also be executed on the secondary.

・Operation 9 which is normally performed after the usage of the mirror device is completed and hence

executed on the secondary system, can also be executed on the primary.

73

3. The secondary recognizes the checkpoint ON token.

After the secondary acknowledges the checkpoint ON token, all the data sent is accumulated in

the journal. The data is written to the journal till the secondary receives the checkpoint OFF

token.

4. After confirming the checkpoint ON state, operation 6 is executed.

After the secondary acknowledges the checkpoint ON token, the system goes into a checkpoint

ON state. To check whether the system is in checkpoint ON state, either of the methods below

can be used.

• Using the monitor tool

When the system is in checkpoint ON state, the following message is displayed in the

messages area of the monitor tool. (### represents the logical group number)

DTC： [INFO / CPON]： logical group [RMD_###] is in checkpoint mode

• Using the /var/opt/SFTKdtc/dtcerror.log

When the system is in checkpoint ON mode the following message is output to the error.log..

DTC： [INFO / CPON]： logical group [RMD_###] is in checkpoint mode

5. After confirming the checkpoint ON state, operation 7 is executed.

When the secondary receives the checkpoint ON token, the file below is created under the

journal directory. Depending on whether this file is created we can decide if the system is in

checkpoint ON mode.

j###.###.p The first “###”represents the logical group number and the

next”###”represent the numerical order of the journal file.

6. Restart the business application on the primary system (mount the file system and/or restart the

application)

Once the secondary has acknowledged the checkpoint ON token, the business application on

the primary system can be restarted (mount the file system and/or restart the application).

7. The mirror device is used in read-only mode

The mirror device on the secondary is used in the read-only mode. For example, if the device is

mounted as a file system for purposes of backup, then it should be mounted in read-only mode

and the backup tool should be run.

8. End using the mirror device

In case the file system is mounted, unmount the file system.

9. Set to checkpoint OFF state

Once the mirror device has been used, to release the checkpoint ON state, use the –off option

with the dtccheckpoint command.

If the checkpoint OFF command is executed, the checkpoint OFF token is sent to the

secondary.

10. The secondary acknowledges the checkpoint OFF token.

11. Apply the journal to the mirror device.

Once the secondary system acknowledges the checkpoint OFF token, the data accumulated in

74

the journal is applied to the mirror device. From this point on the data sent to the secondary is

directly applied to the mirror device.

75

5.4.2 Checkpoint Shell Scripts

The checkpoint process as described in Figure 5.8.1 can be automated by using specific checkpoint

shell scripts at the time when either dtccheckpoint ON or OFF is executed.

Each shell script, with a specified name, and created per logical group must be created in order to

run with normal operations. The shell scripts are placed under the following directories of the

systems on which they run.

[Solaris/HP-UX]

/etc/opt/SFTKdtc/

[AIX]

/etc/dtc/lib/

Table 5.1describes the rules for shell script names for each type of shell script.

[Table 5.1 Types of Checkpoint Scripts]

System Shell Script Name Execution Time Contents of the script

cp_pre_on_p###.sh Before the system goes into

checkpoint ON state (The

secondary is yet to

acknowledge the checkpoint

ON token)

Stop access to the dtc device,

unmount the file systems etc

Primary

cp_post_on_p###.sh Restore access to the dtc device,

mount the file system, restart the

application etc.

cp_post_on_s###.sh

When the system is in

checkpoint ON state (When

the secondary has

acknowledged the checkpoint

ON token) Mount the mirror device as a file

system or start the backup tool.

Secondary

cp_pre_off_s###.sh Before the system is

released from the

dtccheckpoint OFF state

(The secondary is yet to

acknowledge the checkpoint

OFF token)

Unmounting the mirror device,

stopping access to mirror device

etc

Each shell script corresponds to one or more steps in Figure 5.8.1. Indicated below is the

correspondence between the shell scripts and the steps.

• cp_pre_on_p###.sh: Step 1

• cp_post_on_p###.sh: Step 4, 6

• cp_post_on_s###.sh: Step 5, 7

• cp_pre_off_s###.sh: Step 8

The scripts which execute on the primary system have a p prefixed before the logical group number and the

scripts on the secondary have an s prefixed before the logical group number.

The ### represent the logical group number. For example, in the case of logical group number 12, the script

will be named as cp_pre_on_p012.sh.

76

cp_pre_on_p###.sh

This is the script which gets called when the dtccheckpoint command with the –on option is

executed. The dtccheckpoint command checks if for the specified logical group any script exists. If it

does it executes the corresponding script.

In this script the steps and preparation required before taking a snapshot are performed. In this

script one can specify stopping the application or unmounting the file system thereby automating this

process.

If no preparation is required before taking the snapshot, this script is not required.

An example is given below in Figure 5.9

Fig 5.9 An Example of the cp_pre_on_p###.sh Script

#!/bin/sh

# ***** /etc/opt/SFTKdtc/cp_pre_on_p###.sh *****

echo ---------`date`----------->> /tmp/xpoint.log

echo starting cp_pre_on_p###.sh >> /tmp/xpoint.log

echo pre_on script run >> /tmp/xpoint.log

exit 0

In this part, in order to stop access to the dtc device, inst

for stopping the application or unmounting file systems o

another shell script can be written.

・In

file

・Th

pe

・##

・Th

ructions

r

the example, the information that this script has started is output to the /tmp/xpoint.log

e dotted portion represents the processing that is required as per the operations to be

rformed.

# represents the logical group number for which this shell script is used.

e script should exit with a 0 at the end i.e exit 0

cp_post_on_p###.sh

This script is called after the logical group is in checkpoint ON state due to the successful

execution of the dtccheckpoint command. This script is called after the secondary system

acknowledges the checkpoint ON token and is executed on the primary system.

The dtccheckpoint command checks to see if any script corresponds to the logical group and if a

script exists, the dtccheckpoint command runs the corresponding script.

With this script one can automate the restart of the application, mounting of the file system etc

which were stopped or unmounted before the dtccheckpoint ON state was reached.

An example of this script is given in Figure 5.10

Fig 5.10 An Example of the cp_post_on_p###.sh Script

file

#!/bin/sh

# ***** /etc/opt/SFTKdtc/cp_post_on_p###.sh *****

echo ---------`date`----------->> /tmp/xpoint.log

echo starting cp_post_on_p###.sh >> /tmp/xpoint.log

echo post_on script run >> /tmp/xpoint.log

exit 0

In this portion restart of the application or mounting of the

system or calling another shell script can be specified.

・In the example, the information that this script has started is output to the /tmp/xpoint.log

file

・The dotted portion represents the processing that is required as per the operations to be

performed.

・### represents the logical group number for which this shell script is used.

・The script should exit with a 0 at the end i.e exit 0

77

78

cp_post_on_s###.sh

This is the script which runs on the secondary system immediately after the secondary

acknowledges the checkpoint ON token. From this point onwards the data received by the secondary

is accumulated in the journal.

If this script is used, operations like backup of the mirror device, mounting of a file system (in read-

only mode) or starting an application can be automated.

If operations like backup or starting applications are written in this script, based on their completion,

releasing of the checkpoint state can also be automated. This is step 9 in Figure 5.8.1 in which the

dtccheckpoint –off command is executed.

In such cases, if a file system needs to be unmounted, then this should be done before executing the

dtccheckpoint –off command. The unmounting of file systems is normally done in the

cp_pre_off_s###.sh scripts. However if it is done in the cp_post_on_s###.sh script then the

cp_pre_off_s###.sh script is not needed.

In the manner described above, a chain of events can be sequenced and automated.

An example of this script is given in Figure 5.11

Fig 5.11 An Example of the cp_post_on_s###.sh script

#!/bin/sh

# ***** /etc/opt/SFTKdtc/cp_post_on_s###.sh *****

echo ---------`date`----------->> /tmp/xpoint.log

echo starting cp_post_on_s###.sh >> /tmp/xpoint.log

echo post_on script run >> /tmp/xpoint.log

/opt/SFTKdtc/bin/dtccheckpoint -g <group#> -off

exit 0

In this part start of a backup operation, startup of application or

another shell script can be executed.

・In the example, the information that this script has started is output to the /tmp/xpoint.log

file

・The dotted portion represents the processing that is required as per the operations to be

performed.

・### represents the logical group number for which this shell script is used.

・The script should exit with a 0 at the end i.e exit 0

・In the example above it is assumed that the processing in the dotted portion is completed

before the underlined portion (release of the checkpoint ON state) is executed. (In case of

backup operation, the backup operation should have completed.)

Again for AIX the underlined portion will read as /usr/dtc/bin/dtccheckpoint -g <group> -off

79

cp_pre_off_s###.sh

This script is called when the dtccheckpoint command with the –off option is executed. The

dtcccheckpoint command checks for the existence of the script for the specified logical group. In

case it exists the script is executed.

In this script, to release the checkpoint state, post usage operations for the mirror disk can be

written (unmounting of the file system).

In cases where the post processing for the used mirror device are executed in the

cp_post_on_s###.sh script, the cp_pre_off_s###.sh script is not required. However operations such as

confirming the unmounted state of the file system or that the application has been stopped can be

confirmed in this script.

An example of this script is provided in Figure 5.12.

Fig 5.12 An Example of the cp_pre_off_s###.sh script

NOTE In case the mirror device is updated by the application during the checkpoint ON state, the mirror device

may get corrupted and it will become necessary to restore the same using manual intervention. It may

become necessary to perform a full refresh, back fresh or restore data from the tape in order to achieve

valid data on the mirror device.

#!/bin/sh

# ***** /etc/opt/SFTKdtc/cp_pre_off_s###.sh *****

echo ---------`date`----------->> /tmp/xpoint.log

echo starting cp_pre_off_s###.sh >> /tmp/xpoint.log

echo pre_off script run >> /tmp/xpoint.log

exit 0

In this part post processing of the used mirror device or

confirmation that the application has been stopped is specified.

In the example, the information that this script has started is output to the /tmp/xpoint.log

file

・The dotted portion represents the processing that is required as per the operations to be

performed.

・### represents the logical group number for which this shell script is used.

・The script should exit with a 0 at the end i.e exit 0

80

5.4.3 Considerations, Limitations and Tips

The following considerations, limitations and tips should be kept in mind when using the checkpoint

operation.

• The script to be executed on the primary system must have a p prefixed before the logical group

number. Similarly the script on the secondary system must have an s prefixed before the logical

group number.

• Script files must have the x executable attribute set.

• All scripts must end with exit 0 or the dtccheckpoint command fails and the operation is aborted.

• Define only the checkpoint scripts that you need. You need not define all four scripts.

• Checkpoint operations are not immediate. The checkpoint –on token is queued in the BAB on the

primary with data update transactions. Only after the RMD receives token does the checkpoint go

into effect. When the amount of data in the BAB awaiting transfer is large, there may be a

noticeable delay before the checkpoint takes effect.

• If a failure occurs on the primary system or an explicit dtcstop is entered for a logical group with a

pending checkpoint token in the BAB, the token is lost when the logical group is

rebooted/restarted and the checkpoint operation is cancelled.

• The dtccheckpoint command is valid only when it is executed for a logical group in NORMAL mode.

• If the BAB fills up and forces the logical group into TRACKING or REFRESH mode while the

checkpoint token is queued for transfer, the operation is cancelled. Note that, if defined, the

cp_pre_on_p###.sh script has been run at this point. Therefore, you must manually execute the

cp_post_on_p###.sh script on the primary to place applications in a pre-checkpoint state.

• Softek TDMF examines the secondary journal area for the logical group to determine whether the

secondary system is in a checkpoint state. The presence of any files with a .p file extension

indicates that checkpoint is active.

• Should your application modify the mirror devices while in checkpoint mode, a full refresh is

required. There is no way around this.

81

5.5 Loopback Configuration

Softek TDMF supports a loopback configuration, that is, a configuration in which both primary and

secondary systems are on the same system. This can be useful for a variety of needs, such as testing

or employing checkpointing to create point-in time snapshots of data sets. To define a loopback

configuration:

1. Launch dtcconfigtool. For further details please refer to [4.2 Starting the Configuration Tool].

2. Under the Systems tab, specify either localhost or 127.0.0.1 for both primary and secondary systems. For further details please refer to [4.2.3 Defining Primary/Secondary Systems].

3. Define dtc devices as usual. For further details please refer to [4.2.4 How to Define dtc devices].

4. The migration steps are the same as that explained in [Chapter 4 Softek TDMF Configuration].

82

5.6 Defining/Using Throttles

A throttle is a set of statements you can define to optimize Softek TDMF, by monitoring

elements,measuring variables, and performing actions based on evaluations.

Throttles can be defined using the configuration tool and can be created/edited per logical group.

The throttle information is stored in the .cfg file.

In this section, throttles created using the configuration tool is explained. For further details

regarding items that can be defined for throttles please refer to [Appendix B Throttle Refrence].

5.6.1 Creation of Throttles

A throttle is created using Throttle Builder and the following items are defined in the order below.

• Schedule

• Expressions

• Action (process to be executed)

The above three items combined make one throttle.

The Throttle Builder is executed as per the following steps.

1. Start the configuration tool.

2. From the File menu, select the logical group for which the Throttle Editor will be applied.

3. Select the Throttles tab.

4. If you are building throttles for the first time, select the Throttle Builder button.

Fig 5.15 Throttle Editor

83

Schedule

Define the time at which the throttles are to be evaluated.

Below the procedure to define the schedule is explained.

1. On clicking the Throttle Builder button the Evaluation Time screen is displayed.

In this screen the active time for the throttle is defined. The default is Always. If Always is

selected then the throttle will be active at all times.

Fig 5.16 Throttle Builder Initial Screen

2. In case the active time of the throttle needs to be changed, select Only On.

In case Only On is selected, to set the active time for the throttle, select the time and date or

week of day as shown in the next figure.

Next, specify a From and To time of day for the throttle to be active using the HH:MM:SS format

by placing the cursor in the field and entering the appropriate hour (HH), minute (MM) and

second (SS) values. Accepting the “-“symbol by default makes the throttle active continuously

during the days that are selected in step 2.

84

Fig 5.17 Setting the Evaluation Time Through the Throttle Builder

85

How to Build Expressions

Variables and conditions defined, are used by throttles to measure and monitor Softek TDMF.

Variables are selected from a list which is provided by Softek TDMF. For further details please refer

to [Appendix B Throttle Refrence].

The procedure to build expressions is as defined below.

1. In the Evaluation Time screen select the Next button to display the Build Expressions screen.

2. Choose a Variable from the drop down list. This is the element to be measured or monitored by

the throttle.

3. Choose an Operand from the drop down list. This element defines the relationship between the

Variable and the Value.

4. In the Value field, enter an appropriate value.

5. Click the Add to Expression button. On performing this operation, the expression is displayed in

the blank text box.

6. In case of compound expressions, select the applicable Boolean Operator from the drop down

list (OR/AND) and click on the Add to Expression button.

Repeat steps 2 to 5 to complete defining Variable, Operand and Value. It is possible to create a

compound expression with a maximum of 16 clauses.

7. If the expression displayed is correct, click on the Next button and proceed to set the Actions.

In case the expression is incorrect, click on the Clear Expression button to clear the expression.

NOTE Please note that Add to Expression button exists in 2 places. One is in the expression builder

portion and the other is in the pool operation area of the compound expression.

NOTE In case there is a mistake in the throttle expression, use the [Clear Expression] button, and reset

the editor.

Fig 5.18 Throttle Expression

86

Action (Process to be Executed)

Once the expression has been built correctly, the action to be performed is defined. The items to

be defined are Action, Variable and Argument.

Action can be selected from the list provided by Softek TDMF. For further details please refer to

[Appendix B Throttle Refrence].

The procedure to define the action is as follows.

1. On the Build Expressions screen click on the Next button to display the Build Actions.

2. Choose an Action from the drop down list.

3. In case a tuning parameter needs to be set, choose a Variable from the drop down list, to select a

tuning parameter.

The tuning parameter is valid only if the Action selected is set, incr or decr.

For other cases it will be set to blank.

4. Enter an Argument in the field. For details regarding the contents please refer to [Appendix B

Throttle Refrence].

5. Click on the Add To Action List button to register the action. On performing this action, the

registered action will be displayed in the blank text box.

6. In case many actions need to be defined in one throttle, repeat steps 2 to 5 above.

7. Once all the actions have been defined, click on the Done button. The initial Throttle screen is

displayed with the defined throttle visible in the Throttle Editor window.

8. From the File menu select the Save Changes to apply the newly created throttle to the

configuration files. If this action is not performed, the changes made will not be saved.

Fig 5.19 Building Throttle Actions with the Throttle Builder

87

Fig 5.20 A Throttle Created using the Throttle Builder

5.6.2 Applying Throttles

In order for the newly created throttles to take effect, it is necessary to stop access to the dtc

devices of the corresponding logical groups, and to stop/restart the logical groups.

The explanation below describes the procedure.

1. Terminate user applications and unmount any file systems accessing the dtc devices in the

affected logical group.

2. By executing the following command, stop the PMD for the corresponding logical group.

killpmds -g <group#>

3. Execute the following commands.

dtcstop -g <group#>

dtcstart -g <group#>

4. By executing the following command, restart the PMD.

launchpmds -g <group#>

5. Start any user applications or mount file systems using devices in the logical group.

88

5.6.3 Updating/Deleting Throttles

In case the throttle definition needs to be updated or deleted, open the Throttle Editor as shown in

Figure 5.20 and directly edit or remove the contents. Once the changes have been made select

Save Changes from the File menu and save the changes to the configuration file.

To apply the changes made for the corresponding logical group please refer to [5.6.2 Applying

Throttles] .

5.6.4 Throttle Examples

This section includes throttle examples to illustrate the value of throttles in a Softek TDMF

production environment. These throttle examples are provided for illustration purposes only. When

defining throttles, you must balance all critical business factors that may affect applications and apply

appropriate throttle conditional tests and actions to cover all situations that might arise. Carefully

research and test throttles before implementing them in a production environment.

The throttle shown in the Figure 5.21 is arranged to restrict maximum network utilization to

300KBps during the standard business day, but lift the restriction outside these hours.

Fig 5.21 Throttle to Regulate Maximum Network Bandwidth During Peak Business Hours

89

Chapter 6 Softek TDMF Administration In this chapter, details regarding procedure to update environment settings and troubleshooting

steps are explained.

6.1 Updating Environment Settings

After mirroring on Softek TDMF is started, the following actions can be performed to change the

environment settings.

Update BAB size

Deletion of Logical Group

Addition/Update of dtc device

Deletion of dtc device

Relocation of the Pstore

Changing the size of the Journal File Directory

Update of Tuning Parameters

Clearing the Pstore

6.1.1 Update the BAB Size

To change the BAB size, it is necessary to stop all the dtc devices and to stop Softek TDMF

completely and then restart.

NOTE To change the BAB size it is necessary to reload the dtc device driver.

To change the BAB size we can either use the configuration tool (dtcconfigtool) or use the dtcinit command. However if dtcinit command is used then the restart of the operating system is required.

The procedure is as explained below.

1. Stop all processes accessing the dtc devices and unmount the dtc device in case it is mounted

as a file system.

2. Executing the killpmds command, the PMDs of all the logical groups are stopped. (In case they

were in NORMAL mode they will move to TRACKING mode)

killpmds -a

3. Executing the dtcstop command stop all the dtc devices.

dtcstop -a

4. In case the Configuration Tool is used

Start the configuration tool and update the BAB size. For further details regarding the

procedure for using the configuration tool please refer to [Chapter 7 Configuration Tool]. In

case additional memory cannot be allocated by the system, the operating system will need to

be rebooted.

dtcconfigtool

5. In case dtcinit command is used

(1) Execute the killdtcmaster command to stop all the daemons of Softek TDMF.

killdtcmaster

(2) The BAB size is updated using the dtcinit command.

90

dtcinit -b <BAB Size Value(MB)>

(3) Restart the operating system.

(4) Run the launchdtcmaster command.

launchdtcmaster

NOTE Using the dtcinfo command check if the BAB size has changed.

6. Executing the dtcstart command start the dtc devices.

dtcstart -g <group#>

7. Execute the launchrefresh command and bring the dtc devices within the logical group to

NORMAL mode.

launchrefresh -g <group#>

8. Mount the file system(s) and restart the application(s).

NOTE If the BAB size is kept small, then during refresh operation there is a chance that the BAB may overflow. In this case, either the launchrefresh command can be executed which will restart the logical group or if the BAB overflow occurs frequently then increasing the BAB size and the network bandwidth may help. The message below is output when the BAB overflows. RFDOFLOW BAB exhausted during a refresh operation <processname>. Run launchrefresh for

the group

6.1.2 Deletion of Logical Groups

In case the logical group needs to be deleted, the following procedure is followed.

1. Stop all processes accessing the dtc devices to be deleted and unmount the dtc device in case

it is mounted as a file system.

2. Executing the killpmds command, the PMDs of the logical groups to be deleted are stopped. (In

case they were in NORMAL mode they will move to TRACKING mode)

killpmds -g <group#>

3. Executing the dtcstop command stop the dtc devices to be deleted.

dtcstop -g <group#>

4. The configuration files corresponding to the logical groups to be deleted are removed. Examples

are as given below

[Solaris、HP-UX]

rm /etc/opt/SFTKdtc/p001.cfg

[AIX]

rm /etc/dtc/lib/p001.cfg

The next time the system is rebooted, the block device that was being used by the deleted logical

group can be used for other purposes.

91

6.1.3 Addition/Update of dtc device

1. Start the dtcconfigtool.

2. From the File menu, select either New Logical Group or Select Logical Group.

3. Click on the dtc Devices tab.

4. Choose the dtc device to be modified from the device list on the left hand side of the screen. The selected device is highlighted and the device information is displayed in the fields to the right.

5. Select a new device from the drop down list or enter a new value.

6. To add a new dtc device, click the Create New Device button and enter the local data device and mirror device definitions.

7. From the File menu select Save Changes.

8. Copy the configuration files to the secondary and rename them.

9. Execute the killpmds -g <group#> command.

10. Unmount any file systems and stop any application from accessing the dtc devices in the logical group.

11. Run dtcstop -g <group#> command.

12. Run dtcstart -g <group#> command.

NOTE Remember that the configuration files are only processed by the dtcstart command. Changes

to the configuration do not take effect until the logical group is stopped and restarted.

13. In case a new device has been added to the logical group, execute the launchrefresh -g <group#> -f command.

14. Mount file systems or start applications.

6.1.4 Removing the dtc Devices

1. Run dtcconfigtool on the primary system.

2. Select the logical group for modification from the File menu.

3. Select the dtc Devices tab.

4. Choose the dtc device to be deleted from the device list window.

5. Click on Delete Device.

6. From the B menu, click on Save Changes.

7. Copy the updated configuration files from the primary to the secondary system.

8. Execute the killpmds -g <group#> command.

9. Unmount any file systems and stop any application from accessing the dtc devices in the logical group.

10. Execute the dtcstop -g <group#> command.

11. Execute the dtcstart -g <group#> command.

NOTE The changes to the logical group do not take effect until the group has been stopped and

restarted - when dtcstart creates a new .cur file.

12. Execute the launchrefresh -g <group#> command.

13. Mount the file systems or start application.

92

6.1.5 Relocation of Pstore

To relocate the Pstore volume, run the dtcconfigtool and select a new Pstore volume from the

drop-down list for each logical group, for which the Pstore is being modified.

1. Stop all processes accessing the dtc devices and unmount the dtc device in case it is mounted

as a file system.

2. Execute the killpmds command for each group affected by the Pstore modification.

killpmds -g <group#>

3. Execute the dtcstop command for each group affected by the Pstore modification.

dtcstop -g <group#>

4. Start dtcconfigtool.

5. Select the System tab, and choose a new Pstore volume from the drop down list.

6. From the File menu, select Save Changes.

7. Execute the dtcstart command for each modified group.

dtcstart -g <group#>

8. Restart the groups with the launchrefresh command.

launchrefresh -g <group#>

9. Remount file system(s) and restart applications.

6.1.6 Resizing the Journal File Directory

In case the journal file directory has become full, or when wanting to switch over to a directory of

larger size, follow the procedure below to resize the journal file directory

1. On the primary system, execute the killpmds command for the target logical groups (groups for which the journal file directory needs to be changed).

killpmds -g <group#>

2. On the primary system, execute the dtcstop command for the target logical groups.

dtcstop -g <group#>

3. Start the configuration tool and modify the journal file directory for the target logical groups. Regarding the setting for journal file directory and the usage of configuration tool please refer to [Chapter 4 Softek TDMF Configuration] and [Chapter 7 Configuration Tool] respectively.

4. Distribute the configuration files to the secondary. For further details regarding distribution of files please refer to [4.3 Distributing the Configuration Files].

5. On the primary system, execute the dtcstart command for the target logical groups.

dtcstart -g <group#>

6. On the primary system, execute the launchrefresh command for the target logical groups.

launchrefresh -g <group#>

In Softek TDMF, Smart Refresh is started automatically, thereby synchronizing data between the

primary and the secondary. Next the new journal file is applied to the mirror device and during the

Smart Refresh the journal is updated. After this the the logical group moves into NORMAL mode.

93

6.1.7 Changing Tunable Parameters

The tuning parameter values are set in the Pstore. These values can be using the dtcconfigtool or

the dtcset command.

Using dtcset

Note that you must run killpmds before and launchpmds after changing the following tunable

parameters:

• CHUNKSIZE

• COMPRESSION

• NETMAXKBPS

Note that you must run dtcstop before and dtcstart after changing the following tunable

parameters:

• SYNCMODE

• SYNCMODEDEPTH

• SYNCMODETIMEOUT

Execute dtcset -g <group#> <tunable=value>

Using dtcconfigtool 1. Run dtcconfigtool command.

2. Select the logical group to update from the File menu.

3. Select the Tunable Parameters tab as shown in the following figure.

Fig 6.1 Tunable Parameters Tab in dtcconfigtool

94

4. Edit definitions.

5. From the File menu, click on Save Changes and Exit.

6. Execute the killpmds -g <group#> command.

7. Unmount any file system and stop any applications accessing the dtc devices in the logical group.

8. Run dtcstop -g <group#>, followed by the dtcstart -g <group#> command.

9. Restart the PMDs with the launchrefresh command.

10. Remount the file system and restart applications.

6.1.8 Changing the Port Number

In Softek TDMF, the port number is used for two communication purposes.

• Communication between the master daemon (in.dtc) on the primary and the secondary system.

• Data transmission for each logical group

Communication Between Master Daemon(in.dtc) on Primary and Secondary System

For the communication between the master daemons, a port is used on the primary and the

secondary system. The default port number is 575. In case a port number other than 575 needs to be

used, the port number can be updated as per the procedure explained below. But this port number

should be the same on both the primary and the secondary system.

1. Confirm whether the port number selected to be set is free.

[Primary System]

2. On the primary system run the dtcconfigtool.

dtcconfigtool

3. Select TCP Settings from the System menu.

4. In the Listen Port enter the port number. If necessary, the Socket Buffer Size can also be updated. For further details regarding this please refer to [7.4.2 TCP].

5. From the File menu select Save Changes and Exit to save the information.

6. Close the configuration tool.

7. Distribute the configuration files to the secondary system. For further details please refer to [4.3 Distributing the Configuration Files].

8. Execute the following commands and stop all the logical groups.

killpmds -a

dtcstop -a

9. Execute the following commands and restart the master daemon.

killdtcmaster

launchdtcmaster

[Secondary System]

10. Make the following entry in the /etc/services file.

11. To

12. S

13. E

[Primar

14. E

in.dtc 575/tcp # SFTKdtc master daemon

95

he port number entered in the above file should be the same as the port number set in step 4 n the primary system.

ave the file

xecute the following commands and restart the master daemon.

killdtcmaster launchdtcmaster

y System]

xecute the following commands and start the logical groups and bring them to NORMAL mode.

dtcstart -g <group#>

launchrefresh -g <group#>

96

Data Transmission For Each Logical Group

For the data transmission between the primary and the secondary system, the port on the

secondary side is used. The default port number is 575. In case a port number other than 575 needs

to be used please follow the procedure as below.

1. Confirm if the port number selected to be set is free.

2. Execute the following commands and confirm that the logical groups are stopped.

killpmds -g <group#>

dtcstop -g <group#>

3. On the primary system start the configuration tool.

dtcconfigtool

4. Select Select Logical Group from the File menu to select the target logical group.

5. The port number is set in the Secondary System –Port field of the Systems screen. For further details refer to [7.5.1 Systems Screen].

6. Select Save Changes from the File menu and save the information.

7. Close the configuration tool.

8. Distribute the configuration files to the secondary system. For further details please refer to [4.3 Distributing the Configuration Files].

9. Execute the following commands and start the target logical groups and bring the groups to NORMAL mode.

dtcstart -g <group#>

launchrefresh -g <group#>

6.1.9 Clearing the Pstore

After defining the logical group, when the corresponding logical group is started, the Pstore is

formatted to store the information. In case multiple logical groups use the same Pstore, the Pstore is

formatted only in the case of the first start up of the logical groups.

Once the format is completed and if a new logical group is defined now, free space in the Pstore will

be allocated for this logical group. This allocated space will be preserved as is unless the Pstore is

not cleared.

In cases where for testing purposes logical groups were created but are now not being used, just

before creating the actual logical groups to be used, it is recommended that the Pstore be cleared.

To clear the Pstore execute the following command. For further details please refer to [9.16

dtcinit].

dtcinit -p <Pstore Device>

NOTE Be clearing the Pstore (dtcinit -p), the entire Pstore is set to 0 values. In case multiple groups are being

used, and if the Pstore is cleared, all related groups will lose their information. Hence it is important to stop

all logical groups before clearing the Pstore and to necessarily perform a full refresh for the remaining

logical groups once the Pstore has been cleared.

97

6.2 Recovery

In this section, the troubles that may occur during mirroring and the recovery procedures available

thereof in Softek TDMF are discussed.

For further details regarding Softek TDMF’s original purpose of data recovery when the system

goes down (disaster) or when there is a problem with the data device etc, please refer to [Chapter 5

Softek TDMF Operation Patterns]. In this section, recovery that is required when the system goes

down temporarily or when a network problem occurs is explained.

The diffirent problems that could occur are as follows:

Primary system down

Secondary system down/network failures

BAB Overflow

Failing over to the Secondary System, Restoring the Primary System

Data Device Faults

6.2.1 Primary System Down

If the primary system goes down temporarily owing to system reboot etc, on recovering the primary

system it is possible to restart the business application. Once the primary system has recovered it is

necessary to recover the mirroring operation.

For Softek TDMF, after the primary system has recovered (successful system reboot), following the

procedure below we can recover the mirroring operation.

1. On the primary system, execute the following command for the target logical groups.

dtcstart -g <group#>

2. On the primary system, execute the following command for the target logical groups.

launchrefresh -g <group#>

98

6.2.2 Secondary System Down/Network Failures

In case of secondary system or network failure, the Connection field in the dtcmonitortool changes

to red, and displays the Accumulate status.

Fig 6.2 dtcmonitortool Window

In case the Connection field shows PMD ONLY then based on the recovery of the secondary

system or the network, Smart Refresh is started automatically and data is synchronized (NORMAL

mode) and the group returns to CONNECTED status.

During the checkpoint ON state, it the secondary system goes down or the network fails, then the

Connection field will show PMD ONLY. Once the secondary system or network is restored please

ensure that a full refresh is executed (launchrefresh –f).

In case after the secondary system or the network have been restored, and the Connection field

displays ACCUMULATE, then it will become necessary to bring the group to NORMAL mode manually.

99

6.2.3 BAB Overflow

In normal operations, when the BAB overflows for one of the logical groups, the following message

is output to the dtcmonitortool and the dtcerror.log.

BABOFLOW BAB exhausted during normal operation <processname>.

This group will go into TRACKING mode temporarily. Next the PMD will extract the entries from the

BAB and a smart refresh will be executed for the group. Once the refresh is completed the group will

move back to NORMAL mode. User intervention is not required.

In case of a double BAB overflow, where the BAB overlfows once again when the group is either in

the TRACKING or the REFRESH mode, the following message is displayed.

RFDOFLOW BAB exhausted during a refresh operation <processname>. Run launchrefresh for the

group.

In case of a double BAB overflow, the group will be placed in the TRACKING mode. Unless the

following command is not executed, the group will continue to remain in this mode.

launchrefresh -g <group#>

Once the smart refresh operation is completed the group will move back to NORMAL mode. In case

the journal mode is being used, once all the journals have been applied to the mirror device, the

primary and the secondary system will achieve data equivalence.

In case of a double BAB overflow, it may be necessary to increase the size of the BAB. For further

details on increasing the BAB size, please refer to [6.1.1 Update the BAB Size].

6.2.4 Failing Over to the Secondary System, Restoring the Primary System

Assume that you had a disaster on the primary system and want to relocate operations to a

secondary system using the mirrored data.

1. Execute the dtcrmdreco -g <group#> command on the secondary system.

2. If necessary, mount mirror devices. Then start applications on the secondary system.

Now your primary system is back in order and you want to move operations back to the primary system. Synchronize the primary system with the more recent data on the secondary data devices as follows:

1. Halt applications and unmount the devices on the secondary system in preparation for restoring the primary.

2. Execute the dtcrmdreco -g <group#> -d command on the secondary system.

3. On the primary system execute the launchbackfresh -g <group#> command.

When the backfresh completes, Softek TDMF shifts into NORMAL mode, the PMDs and RMDs are connected, and you can resume mirroring data to the secondary system.

NOTE Backfresh is an operation to be performed in maintenance mode only. Do not access or update local or

mirror data devices until the backfresh is complete. Another method to synchronize data is to use the

secondary system as a primary system and perform the refresh operation. One of the features of the

refresh operation is that data devices can be updated during the progress of this process. For further

details please refer to [Chapter 5 Softek TDMF Operation Patterns].

100

6.2.5 Data Device Failures

You can detect a device failure on one of your systems using a tool such as a Volume Manager.

The device appears grayed if it has failed. You may also see a Softek TDMF message to this effect in

dtcerror.log.

In this case take the following steps.

1. If you are using file systems, unmount the dtc devices in the affected logical group.

2. Execute the killpmds -g <group#> command.

3. On the primary system, stop the logical groups affected by the device failure using the dtcstop -g <group#> command.

4. Add or replace the device on the system.

5. Using dtcconfigtool, modify the affected logical group definitions so that they refer to the new device. Remember to copy the new .cfg file to the secondary system.

6. Restart the logical groups with the dtcstart -g <group#> command.

7. If the device failed on the primary system, execute the following command:

launchbackfresh -g <group#>

If the device failed on the secondary system , execute the following command:

launchrefresh -f -g <group#>

101

Chapter 7 Configuration Tool This chapter explains regarding the Configuration Tool contained in Softek TDMF.

7.1 Starting the Configuration Tool The configuration tool can be started using the following command:

[Solaris/HP-UX]

/opt/SFTKdtc/bin/dtcconfigtool

[AIX]

/opt/dtc/bin/dtcconfigtool

7.2 Screen Layout The configuration tool screen is organized around the Menu Bar and various setting screens. The

following is a list of options and sub-options available in the Menu bar.

- File Bar

・New Logical Group(New DTC Logical Group Screen)

・Select Logical Group(Select Group Screen)

・Reset Logical Group

・Save Changes

・Exit

- System Bar

・BAB(Set BAB Size Screen)

・TCP Settings.(TCP Settings Screen)

- View Bar

・Systems(Systems Screen)

・DTC Devices(dtc Devices Screen)

・Throttles(Throttles Screen)

・Tunable Parameters(Tunable Parameters Screen)

・Configuration Errors(Softek TDMF Configuration Errors Screen)

・About Softek TDMF

When the configuration tool is started the following screen is displayed. (On starting the

configuration tool immediately after installation, an initial screen different from the one below is

shown. For further details regarding this screen please refer to [4.2.1 Setting up the BAB Size])

102

Fig 7.1 Startup Screen of the Configuration Tool

7.3 File Bar

The File bar options are as explained below.

Fig 7.2 File Bar

7.3.1 New Logical Group

It is selected when a new logical group is to be created.

When this option is selected the following screen is displayed. Set the logical group number desired.

Fig 7.3 New DTC Logical Grroup Screen

103

7.3.2 Select Logical Group

In case a logical group other than the one which is being displayed by the monitor tool needs to be

updated this option is used.

Fig 7.4 Select Logical Grroup Screen

7.3.3 Reset Logical Group

In case one needs to reset the information for a logical group, this option can be used.

7.3.4 Save Changes

When the changes made to the logical group need to be saved. In case the configuration tool is

closed without using this option, the changes made to the logical group will be discarded.

7.3.5 Exit

In case one needs to close the configuration tool after usage.

104

7.4 System Bar

BAB size settings and TCP information settings are available in the System Bar.

Fig 7.5 System Bar

7.4.1 BAB

In case BAB size needs to be changed this option is selected.

If this option is selected the following screen is displayed. The BAB size can either be entered

directly or can be selected using the arrow keys. If the arrow keys are used the following values can

be selected: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 1547.

Fig 7.6 Set BAB Size Screen

NOTE In case the BAB size needs to be changed, it is necessary that all logical groups be stopped. In case

the logical groups are running when the OK button is clicked then this will result in an error and the

size set will become invalid. In this case, stop all logical groups and then redo the settings.

7.4.2 TCP

In case the port number of the master daemon (in.dtc) needs to be changed, use this option. The

same port number is used by both the primary and the seconadary system. The default number is

575.

If necessary, the Socket Buffer Size can be changed. This parameter represents the buffer size for

the TCP/IP packages set in bytes.

In case the port number is changed, both the primary and secondary master daemons need to be

restarted.

Fig 7.7 TCP Settings Screen

105

7.5 View Bar

Using the View bar, one can refer to the various defined parameters for a selected logical group,

refer to errors that may have occurred at the time of configuration or view the version of Softek

TDMF.

Fig 7.8 View Bar

7.5.1 Systems Screen

In this screen, the primary and secondary system information for a logical group is set.

At the bottom part of the screen, the logical group number for which the changes are being made is

displayed. In case another logical group needs to be changed, please select the logical group from

the File menu bar.

Fig 7.9 Systems Screen

106

Primary System - Hostname or IP Address

Either the IPAddress or the host name of the primary system is set. In case of a loopback

configuration, 127.0.0.1 is set.

Primary System - Persistent Store Device

The device to be used for the Pstore is set.

Secondary System - Hostname or IP Address

Either the IP Address or the host name of the secondary system is set. In case of a loopback

configuration, 127.0.0.1 is set.

Secondary System - Journal Directory

Set the Journal File Directory. Please create this directory on the secondary in advance.

Secondary System - Port

This is the port number used by the RMD on the secondary system to communicate with the PMD

on the primary system.. The default value is 575.

Secondary System - Allow Chaining

In a Device A-> Device B-> Device C type of Chaining configuration, this is checked for

Device A->Device B. For further details please refer to [5.3.3 Using the Chaining Feature to Backup

the Mirror Device].

Notes

Enter any comments or remarks. These are saved in the configuration file (p###.cfg).

107

7.5.2 dtc Devices Screen

In this screen, the local data device and mirror device for the logical group are defined, and a dtc

device is created.

Fig 7.10 dtc Devices Screen

DTC Devices Display Column

The dtc device being defined is displayed.

dtc Device

The dtc device to be set up is selected using the arrow keys. For DTC Devices which have already

been created the dtc device can be selected from the DTC Devices Display column and the settings

can be changed. In case a new dtc device needs to be created, either click on the Create New

Device button or enter a new dtc device number.

On Primary System - Data Device

To create a new local data device, either enter the device name or select an available device from

the drop down list. In case of an existing dtc device the set local data device is displayed.

The device list of the primary system is displayed in the drop down device list. From this list one

can select the data device to be used as the local data device.

108

On Secondary System - Mirror Device

To create a new mirror device, either enter the device name or select an available device from the

device list. In case of an existing dtc device, the device name will be displayed.

The device list displays the list of devices on the secondary system. The device can be selected

from this list. However in cases where communication with the secondary system is not possible, the

device cannot be selected from this list. In such cases, directly enter the device name. When the

secondary system connection is restored, click the Refresh Device Lists button to update the device

information and display the device list.

Refresh Device Lists Button

When this button is displayed the device lists of the primary and the secondary system are

refreshed and the latest information is displayed.

Create New Device Button

When this button is clicked, the dtc device number is automatically incremented by one higher than

the maximum device number displayed in the DTC Devices display column. For example, if dtc0 and

dtc2 are existing devices and the Create New Device button is clicked, then a new dtc device with

device number dtc3 is displayed.

Commit Device Button

After setting the dtc device information, if this button is clicked then the dtc device information is

set. In case of a newly created dtc device, it gets displayed in the DTC Devices display column.

Delete Device Button

Select the dtc device in the DTC Devices display column and then click on this button to remove a

dtc device.

109

7.5.3 Throttles Screen

This screen is used to create and define throttles.

For details regarding creating throttles, please refer to [5.6 Defining/Using Throttles].

Fig 7.11 Throttle Screen

Throttle Tracing Check Button

In case this is set to On, then at the time of execution of the throttle action, messages will be

output to the syslog and the files mentioned below. In case it is set to Off, no output will be sent to

these files. The default value is Off.

[Solaris、HP-UX]

/var/opt/SFTKdtc/dtcerror.log

[AIX]

/var/dtc/dtcerror.log

Throttle Builder Button

If this button is clicked the tool used to create the throttle will be started. For further details please

refer to [5.6 Defining/Using Throttles].

110

7.5.4 Tunable Parameters Screen

In this screen the settings for the tunable parameters as mentioned below can be performed. The

other tunable parameters can be set either using the dtcset command or within the throttle. For

further details regarding the dtcset command please refer to [9.26 dtcset] and for further details

regarding Throttles please refer to [5.6 Defining/Using Throttles].

Fig 7.12 Tunable Parameters Screen

Synchronous Mode

In case either the Sync mode or the Near Sync mode needs to be used, this value is set to On. The

default is Off which represents the Async mode.

In case this is set to On, the parameters Depth and Timeout need to be set.

Depth

This option sets the number of I/Os that can accumulate in the BAB before Sync mode is

triggered. For example, if this value is set to 10, then the entries that will be accumulated in

the BAB are 10 and Softek TDMF works in Async mode. Once the entries exceed 10, Softek

TDMF will work in Sync mode. (This is Near Sync mode)

For Sync mode operation this value is set to 1. For Near Sync mode, a value of 2 or more

can be set.

Timeout

This parameter establishes the amount of time, in seconds, that the dtc device driver waits

for a Sync mode update to complete before returning control to the application, just as if the

acknowledgement of the mirror device update has been received.

111

Compression

This parameter sets data compression when the data is sent from the PMD to the RMD. If set to

On, then the data is compressed before being transferred and decompressed before being written to

the journal or mirror device on the secondary system. The default is Off, which indicates that the data

being transferred is in its original, non-compressed state.

Journal

This parameter represents whether the journal should be used or not in case of the Refresh

operation (Smart Refresh and Checksum).

In case it is set to Off, then the journal is not used. In case it is set to On then the journal is used.

The default option is Off.

In case where the journal is not used, the data sent to the secondary because of the Refresh

operation and the I/Os on the local data device during the Refresh operation, are both directly applied

to the mirror device.

In case where the journal is used, the data sent to the secondary because of the Refresh operation

and the data updates on the local data device during the Refresh operation, are both accumulated in

the journal. Once the data has been completely transferred, the data accumulated in the journal is

applied directly to the mirror device.

In the case where the journal is used, there are times when the data transferred as a result of the

Refresh operation may be very high which may lead to the possibility of journal directory space

running out. In such cases it becomes necessary to execute the Full Refresh operation.

In the case where the journal is not used, even if the data transferred is high, since the journal is

not used during the Smart Refresh operation, the possibility of the journal directory space running out

does not exist.

Statistics Generation - Update Interval

This parameter sets the frequency at which performance data created by the performance tool

should be output. The interval is defined in seconds.

Statisiics Generation - Maximum Stat File Size

This is the maximum size of the file which contains the collected performance data.

This is the same as the tuning parameter MAXSTATFILESIZE.

Network Usage Threshold

This indicates whether Softek TDMF should be limited to using the network bandwidth.

In case it is set to On, then the maximum transmission rate in Kbyte/sec is set. In case the

transmission rate is exceeded, Softek TDMF will not transfer the data.

In case it is set to Off, Softek TDMF will not consider the load on the network while transferring

data to the mirror device on the secondary system.

113

Chapter 8 Monitoring Tools In Softek TDMF, there are three tools using which the system can be monitored real time. Using

these tools one can observe the effect that tuning parameters or throttles have on the system. With

these tools one can also monitor any problems that may arise when the Softek TDMF environment is

expanded or during the initial configuration of Softek TDMF.

8.1 dtcperftool

dtcperftool is used to display charts of various Softek TDMF performance metrics. You can view

multiple charts at one time, and modify, delete, or print them. dtcperftool lets you observe Softek

TDMF performance and trends over time, and create printouts.

Moreover, you can run dtcperftool on the primary system, secondary system, or both. Thus, you can

monitor data being sent and received. If primary and secondary configuration files exist on the

system when dtcperftool is run, use the optional –p or –s arguments to determine whether the

primary and secondary configuration files are queried. The only difference in using the tool on the

systems is what performance metrics you can observe. To start the performance monitoring tool,

enter dtcperftool from the command line.

The dtcperftool screen is divided into three sections, or steps, corresponding to the steps you

follow to generate a performance monitoring chart.

Fig 8.1 dtcperftool Screen

114

8.1.1 Step I： Chart Setup

1. If you are creating a new chart, select Define New Chart to clear all the fields.

2. Specify the following:

Title

Title for the chart you are creating – upto 60 characters.

Chart Type

How you want the data displayed. Select one of the following chart types from the drop-

down menu.

Line Chart

Bar Chart

Stacked Bar Chart Number of Samples

The number of samples to be shown in the chart. The PMD writes performance statistics

to an ASCII file. Be default, this file is updated every 10 seconds. This a 21-sample

analysis reflects the 210 seconds of operation.

8.1.2 Step II: Measurements Shown in Chart

3. Specify the following items to show in the chart.

Select a Measurement and click Add to Chart. Select as many measurements as you wish.

The combination of logical group, dtc device, and measurement type is displayed in the box

beneath the Add to Chart button.

Logical Group

The logical group(s) you want monitored. Select one of the currently defined logical

groups from the drop-down menu.

DTC Device

The dtc device(s) you want monitored. Select a dtc devices defined for the logical group

you have selected.

Measurement

The data item(s) you want displayed. Choose as many types of data as you want from the

Measurement drop-down menu. The measurements you can select for the primary

system are:

Net Actual – The actual number of Kbytes of data sent over the network.

Net Effective – If you have compression activated with the COMPRESSION

tunable parameter, the effective KBps is the pre-compression data rate being

transferred over the network.

Entries in BAB – The current total number of entries in the BAB awaiting

transmission.

Percent BAB full – The percentage of BAB in use by pending entries awaiting

transfer.

Percent done – The percentage of data from the dtc devices transmitted over the

network during a refresh or backfresh operation.

Read KBps - The local data device read I/O rate for applications accessing the

dtc device.

Write KBps – The local data device write I/O rate for applications accessing the

dtc device.

The measurements you can select for the secondary system are:

Net Actual – The actual number of Kbytes of data sent over the network.

Net Effective – If you have compression activated with the COMPRESSION

tunable parameter, the effective KBps is the pre-compression data rate being

115

transferred over the network.

Entry age recvd – The age of the oldest entry received in seconds.

Click the Modify Measurement or Remove From Chart buttons to make changes.

116

8.1.3 Step III: Chart Display

4. When you have made all the necessary choices to define the chart that you want, click the

Display Chart button to display the chart on the screen.

NOTE Because of the fixed width of the chart label at the bottom of the display, if you size the chart

and make it too narrow, the display becomes corrupted. Click the border of the chart window

and drag the window larger to correct the problem.

Modifying a Chart

At this point, you can still change what’s displayed in the chart. There are two ways to edit a chart:

• Left click anywhere on the chart

The background color of the chart flashes briefly to yellow.

• Right-click anywhere in the chart

The Chart Options Menu is displayed. Select Edit Chart.

Modify the chart definition as desired and then select Display Chart to see the new version.

Other Chart Functions

You can display multiple charts at one time. Each chart is defined separately.

To delete a chart, print a chart, or save it in a file, use the Delete Chart, Print Chart, or Print Chart

to File option from the Chart Options Menu. You can also delete a chart by selecting it to edit and

then selecting Delete Chart in dtcperftool.

The Performance Tool displays error messages in red in the upper left area.

8.1.4 Performance Monitoring Files

dtcperftool obtains current performance information from a set of ASCII files created by throtd

(RMDs). These files are called performance monitoring files or performance tracking files. These files

are written in row/column format and are suitable for use by other applications such as spreadsheets

or databases. They are located at:

[Solaris、HP-UX]

/var/opt/SFTKdtc/p###.prf

/var/opt/SFTKdtc/p###.prf.1（previous generation file for this logical group）

/var/opt/SFTKdtc/p###.phd（column descriptions for.prf files）

[AIX]

/var/dtc/p###.prf

/var/dtc/p###.prf.1（previous generation file for this logical group）

/var/dtc/p###.phd（column descriptions for.prf files）

Related Tunable Parameters

The following tunable parameters for throtd affect the performance monitoring files:

STATINTERVAL

MAXSTATFILESIZE

As throtd takes new performance snapshots, the latter are appended to the end of the appropriate

performance monitoring file. Thus, a performance monitoring file records observations moving from the

oldest at the top of the file to the most recent at the bottom of the file.

117

8.2 dtcmonitortool

dtcmonitortool provides a comprehensive picture of Softek TDMF activity and state information. It

should be run only on the primary system.

Fig 8.2 dtcmonitortool Screen

As the Figure 8.2 shows this utility displays the following items:

8.2.1 Status Message Area

This area is at the very top of the window. If no Softek TDMF devices have been defined or

initialized on the primary system, this status message area displays a message to that effect. The

status message area displays Updating…..while the status update information is being obtained.

8.2.2 Error and Warning Messages

Under the Status Message Area is a window that contains the Softek TDMF error and warning

messages listed from oldest at the top to the newest at the bottom. Each update cycle obtains new

error or warning messages from the primary and the secondary systems associated with it. Each

message shows:

• The date and time that the message was generated.

• Function name where the message originated

• Message level, message ID, message text

Messages are shown as follows:

• Fatal error messages – red

• Warning error messages – black

The size of this scrolling list is 200 messages by default; you can change it with the dtcmonitortool command line argument:

dtcmonitortool –messages count

118

8.2.3 Logical Group/ dtc Device Status Area

Below the Error and Warning Messages area is the Logical Group/dtc Device Status area. If this

area of the window is not big enough to hold the status groups and status bars, then it automatically

becomes a scrollable window.

Each logical group defined on the primary system is shown in a bordered box as shown in the

following figure. The top line indicates the group number (for example, Group 010) followed by the field

descriptor.

Fig 8.3 Logical Group and Device Status Area of dtcmonitortool

The fields shown for the logical group display the following values

• Connection – The state of the logical group’s connection.

CONNECTED - （Green）

PMD and RMD daemons for this logical group are connected and active and transfer

any entries in the BAB.

ACCUMULATE - （Red）

Neither the PMD or RMD daemons for this logical group are present. Entries added

to the local device are accumulating in the BAB.

PMD ONLY - （yellow）

The PMD daemon alone is active and is attempting to create a connection with the

RMD on the secondary system. Entries added to the local device are accumulating

in the BAB.

RMD ONLY - （Yellow）

The RMD daemon for the logical group on the secondary system is active without a

PMD on the primary system and should timeout and die within 30 seconds from

the appearance of this indicator.

• Mode % Done – Softek TDMF’s current operating state and percentage completion for refresh

operations.

REFRESH - % Done

TRACKING

NORMAL

BACKFRESH - % Done

PASSTHRU

• Local Read、Loc.Write – Local reads and writes in KB per second.

• Net Actual、Net Effect – The actual rate of data flow (amount of data flow without compression)

and the effective data rate (amount of data flow with compression and smart refresh taken into

consideration) over the network.

• Entries、% BAB used – The number of entries in the BAB for each device and the percentage of

BAB the device entries are consuming.

Gray – No entries in the BAB.

Green – Percentage in use is between 1 and 50.

Yellow – Percentage in use is between 51 and 80.

119

Red – Percentage is 80 or more.

Under the Group status is a status line for each dtc device defined in the logical group. On the

figure 8.3, the shown status line is for dtc0. The items displayed are the same as those displayed for

the logical group, but the values may vary.

8.2.4 Modification and Update Controls

At the bottom of dtcmonitortool are the Notification controls:

You can set these controls to occur if any indicators go into a red state, including receiving Fatal

error messages.

8.3 dtcinfo

The dtcinfo command generates an ASCII report for one or more dtc devices indicating Softek

TDMF operating mode and performance metrics specific to the BAB.

Run the dtcinfo command on the primary system only. The following figure shows a sample of the

dtcinfo output.

Fig 8.4 dtcinfo Output Example

Requested BAB size ................ 536870912 (~ 512 MB)

Actual BAB size ................... 213909504 (~ 204 MB)

Free BAB size ..................... 213909504 (~ 204 MB)

Logical Group 10 (tdmf01 -> 1.2.3.4)

Mode of operations.............. Normal

Entries in the BAB.............. 0

Sectors in the BAB.............. 0

Sync/Async mode................. Async

I/O delay....................... 0

Persistent Store................ /dev/dsk/c0t0d0s5

Device /dev/dtc/lg10/rdsk/dtc0:

Local disk device number........ 0x80000d

Local disk size (sectors)....... 8391880

Local disk name................. /dev/rdsk/c0t1d0s5

Remote mirror disk.............. 1.2.3.10:/dev/rdsk/c0t0d0s5

Read I/O count.................. 0

Total # of sectors read......... 0

Write I/O count................. 0

Total # of sectors written...... 0

Entries in the BAB.............. 0

Sectors in the BAB.............. 0

121

Chapter 9 Softek TDMF Commands This chapter describes the commands available in Softek TDMF.

All command described in this chapter must be executed with root authority.

NOTE To investigate the results and effects of the executed command, please use the monitor tool.

Table 9.1, lists all the commands and their brief outline. The right hand column gives the page

number where the detailed explanation can be found. The detailed explanation gives the construction

of the command, options that can be used and one example of usage.

Table 9.1 Softek TDMF Command List

Command Description Section

killbackfresh Shell script that stops the backfresh operation. 9.1

killdtcmaster Shell script that stops the PMD, RMD, in.dtc and throtd

processes.

9.2

killpmds Shell script that stops a running PMD. 9.3

killrefresh Shell script that stops the execution of the refresh

operation.

9.4

killrmds Shell script that stops a running RMD. 9.5

launchbackfresh Shell script that starts the backfresh operation. 9.6

launchdtcmaster Shell script that starts the in.dtc and throtd daemons. 9.7

launchpmds Shell script that starts the PMD process. 9.8

launchrefresh Shell script that starts the Refresh operation. 9.9

dtcbackfresh Starts the backfresh operation for 1 or more logical groups. 9.10

dtccheckpoint Starts/Stops the checkpoint operation. 9.11

dtcconfigtool Starts the configuration tool. 9.12

dtcdebugcapture Collects debug information when a problem occurs. 9.13

dtchostinfo Outputs the network host name and IP Address of the

system.

9.14

dtcinfo Outputs the dtc device and status information for 1 or

more logical groups.

9.15

dtcinit Initializes or updates the BAB size. 9.16

dtckillbackfresh Stops the backfresh process. 9.17

dtckillpmd Stops the PMD. 9.18

dtckillrefresh Stops the refresh process. 9.19

dtclicinfo Reports the license information of Softek TDMF for the

current system.

9.20

dtcmonitortool Displays the values for various parameters and displays

the messages output by the primary and secondary

9.21

122

systems.

dtcoverride Forcibly clears the BAB or changes the operating mode. 9.22

dtcperftool Starts the tool which displays the performance data. 9.23

dtcrefresh Starts the refresh operation for 1 or more logical groups. 9.24

dtcrmdeco Transfers the data ownership to the secondary system and

stops mirroring, and commits the pending state.

9.25

dtcset Sets or reports the values of the tuning parameters 9.26

dtcstart It activates the dtc devices defined in the .cfg files of the

logical groups.

9.27

dtcstop It stops the set logical group and deactivates the dtc

device.

9.28

123

9.1 killbackfresh

Shell script that runs dtckillbackfresh; terminates any backfresh operation currently running on the

system.

killbackfresh provdes the following additional functionality beyond that provided by dtckillbackfresh.

• The script checks to see if any logical group PMDs are running.

• If PMDs are running, then dtckillbackfresh is started.

If command line arguments are specified, they are passed to dtckillbackfresh.

If no command line arguments are specified, then dtckillbackfresh is run with the –a

argument, which terminates all logical group PMDs that are currently in BACKFRESH mode.

A message is written to the console stating that the backfresh operations have been

terminated.

• If there are no PMDs running, then a message is written to the console saying that there are no

PMDs running, and the script exits.

Options

-g <group#>

Terminates backfresh daemons for the logical group <group#>. This option can be repeated for

multiple logical groups.

killbackfresh -g 3 -g 12

-a

Terminates all backfresh daemons.

Sample Input

myserver# killbackfresh -a

Output

If the script completes and the command is executed, there is no output. If there are no PMDs

running, a message indicating this is written to the console and the script exits.

124

9.2 killdtcmaster

Shell script that terminates any PMD, RMD, in.dtc or throtd processes that are currently running

on the system. Use this script for maintenance activities such as stopping any logical groups with the

dtcstop command, or removing Softek TDMF from a system prior to a software upgrade.

Options

None

Sample Input

myserver# killdtcmaster

Sample Output

in.dtc master Softek TDMF daemon has been shutdown

throtd Softek TDMF throttle daemon has been shutdown

NOTE In case an option is set it will be ignored.

9.3 killpmds

Shell script that runs dtckillpmd, terminating PMDs currently running on this system. When PMDs

are terminated, their corresponding RMDs on the secondary systems are terminated as well.

killpmds provides the following additional functionality beyond the that provided by dtckillpmd:

• The script checks to see if any logical group PMDs are running.

• If PMDs are running, then dtckillpmd is started.

If command line arguments are specified, they are passed to dtckillpmd.

If no command line arguments are specified, then dtckillpmd is run with the –a argument,

which terminates all PMDs.

• If there are no PMDs running, then a message is written to the console saying that there are no

PMDs running, and the script exits.

Options

-g <group#>

Terminates PMD daemons for logical group <group#>. This option can be repeated for multiple

groups.

killpmds -g 12 -g 0

-a

Terminates all PMD daemons.

Sample Input

myserver# killpmds

Output

If the command is executed, there is no output. If there are no PMDs running, a message indicating

this is written to the console and the script exits.

125

9.4 killrefresh

Shell script that runs dtckillrefresh; terminates any refresh operations currently running on this

system.

killrefresh provides the following additional functionality beyond that provided by dtckillrefresh:

• The scrip determines whether any logical group refresh operations are running.

• If refresh operations are running, then dtckillrefresh is started.

If no command line arguments are specified, then dtckillrefresh is run with the –a argument,

which terminates all logical group refresh operations.

• If there are no refresh operations running, then a message is displayed that there are no refresh

operations running, and the script exits.

Options

-g <group#>

Terminates REFRESH mode for logical group <group#>. This option can be repeated for multiple

logical groups.

killrefresh -g 2 -g 10

-a

Terminates REFRESH mode for all logical groups.

Sample Input

myserver# killrefresh -a

Output

If the script comnpletes and the command is executed, there is no output. If no refresh operations

are running, a message indicates that this is written to the console and the script exits.

9.5 killrmds

Shell script that terminates all RMDs currently running on this system. Enter the command on the

secondary system.

Once RMDs have all been killed, you can restart them by either killing (killpmds) and relaunching

(launchpmds) the associated PMD on the primary system.

Options

-g <group#>

Terminates RMDs for logical group <group#>. This option can be repeated for multiple logical

groups.

killrmds -g 2 -g 10

-a

Terminates RMDs for all logical groups on this secondary system.

Sample Input

myserver# killrmds

Output

None

NOTE If the options are omitted, the command will work the same as when the –a option used.

126

9.6 launchbackfresh

Shell script that runs dtcbackfresh to start backfresh operations. Recall that backfresh

synchronizes the primary system with the secondary system using the mirrored data.

NOTE BACKFRESH mode is a maintenance only mode. Do not access or update local or mirror data devices

until the backfresh is complete.

launchbackfresh provides the following functionality beyond that provided by the dtcbackfresh

command:

• The script launches the PMDs if they are not already running. It validates system license

information and then starts backfresh.

• If no command line arguments are specified, then dtcbackfresh is run with the –a argument,

which puts all logical groups and all devices into BACKFRESH mode.

For further details on using this command for data recovery please refer to[6.2 Recovery].

Options

-a

Indicates all logical groups.

-g <group#>

Selects one or more logical groups designated by the <group#>.

Sample Input

myserver# launchbackfresh -a

Output

None

9.7 launchdtcmaster

Shell script that starts the master Softek TDMF daemon (in.dtc) and Softek TDMF throttle daemon

(throtd). This is a convenience utility to reestablish the Softek TDMF daemon environment after

system maintenance when you entered the killdtcmaster command. The Softek TDMF master daemon

and throttle daemon are launched automatically during installation and after reboot. You do not

normally use this command except for system maintenance activities.

Sample Input

myserver# launchdtcmaster

Output

None

127

9.8 launchpmds

Shell script that starts PMDs for the designated groups. This is the preferred method of starting

the daemons.

The launchpmds script provides the following additional functionality:

• The script checks that a valid license file (DTC.lic) is present on the system.

• The script checks to see if the PMDs are already running.

− If the PMD is running, a message that it is running is written to the console, and the script

exits.

− If the PMD is not running, then it is started

Options

-g <group#>

Starts PMDs for logical group <group#>. This option can be repeated for multiple logical groups.

-a

Starts PMDs for all logical groups.

Sample Input

myserver# launchpmds

128

9.9 launchrefresh

Shell script that starts dtcrefresh, which causes the product to transition to REFRESH mode and

synchronize the local data device contents with the mirror devices. This is the preferred method for

starting dtcrefresh.

launchrefresh provides the following additional functionality beyond that provided by dtcrefresh:

• If no command line arguments are specified, then dtcrefresh is run with the –a argument,

which starts a smart refresh operation on all logical groups.

• If a full refresh is required, use the –f option.

Options

-g <group#>

Puts all dtc devices in logical group <group#> into REFRESH MODE. This option can be repeated

for multiple groups.

launchrefresh -g 1 -g 21

-a

Puts all dtc devices into REFRESH MODE.

-c

Initiates a checksum refresh in which all blocks on the local data device are compared with the

blocks on the mirror device using a checksum method to identify delta areas. Only blocks that

have been modified (that is, those for which the checksum varies) are sent to the secondary

system. A checksum refresh writes mirror data to the journal file system, not directly to the

mirror device.

-f

Forces a full refresh of all data blocks from the data devices to the mirror devices on the

secondary system.

Sample Input

myserver# launchrefresh -a

Output

None

129

9.10 dtcbackfresh

This command initiates a backfresh operation as a means to synchronize data on the primary

system with more up-to-date data on the secondary one.

NOTE BACKFRESH mode is a maintenance mode only. Do not access or update local or mirror data devices

until the backfresh is complete.

Options

-a

Indicates all logical groups.

-g <group#>

Selects one or more logical groups to place into BACKFRESH Mode.

Sample Input

myserver# dtcbackfresh -g 101

Output

None

130

9.11 dtccheckpoint

This command turns checkpointing of the mirror devices on or off. When checkpointing is on, Softek

TDMF relinquishes its exclusive lock on the mirror device(s) and allows other applications to access

the device(s) in read-only mode.

The dtccheckpoint command looks in the following directories for the optional, user-defined

checkpoint scripts.

Primary Scripts:

• /etc/opt/SFTKdtc/cp_pre_on_p###.sh

• /etc/opt/SFTKdtc/cp_post_on_p###.sh

Secondary Scripts:

• /etc/optSFTKdtc/cp_post_on_s###.sh

• /etc/opt/SFTKdtc/cp_pre_off_s###.sh

NOTE For AIX, it searches for these scripts under /etc/opt/dtc.

If these scripts are implemented on the primary and the secondary systems, they are executed

when the command is entered. For further details regarding checkpointing, please refer to [5.4

Checkpoint Operation].

-a

Indicates all logical groups.

-g <group#>

Selects one or more logical groups.

NOTE The -p and -s options for the dtccheckpoint command are only valid in a complex configuration: when

the system is set up to act as both primary and secondary systems.

-p

Causes the system on which the dtccheckpoint command is entered to act like a primary

system and run the appropriate scripts.

-s

Causes the system on which the dtccheckpoint command is entered to act like a secondary

system and run the appropriate scripts.

-on/off

Turns checkpointing on or off.

Sample Input

myserver# dtccheckpoint -g 101 -on

Output

None

9.12 dtcconfigtool

This command starts the utility for viewing, editing, or defining logical group configuration files,

including primary and secondary systems, tunable PMD parameters, dtc devices, and throttles.

131

Options

-rmdtimeout t

Sets the time (in seconds) during which the dtcconfigtool should wait for the RMD to return a

list of disk partition devices and volumes defined on each secondary system. The default is 15.

-noconfigchk

Bypasses consistence and collision checking of component devices for dtc device definitions in

each of the logical group configuration files when dtcconfigtool is brought up.

-nohelp

Suppresses the help messages that pop up after 2 seconds when the pointer is placed on a

control or entry.

Sample Input

myserver# dtcconfigtool

Sample Output

132

9.13 dtcdebugcapture

This command collects system and software information that can be used for diagonizing problems

with your Softek TDMF environment.

The information is saved in a file named nodename1.tar.Z.uu – for example, onefish1.tar.ZZ.u – in

directory /tmp. Save this file and send it to Technical Support.

Options

None

NOTE In case an option is set it will be ignored.

9.14 dtchostinfo

This command runs a utility that returns the networked hostnames and IP Addresses for a system,

and the host id of the system where the command is run.

You can run this command on either primary or secondary system to obtain local host information.

From the primary system, you can also run the command with the secondary host name to obtain

secondary system information.

Options

hostname

Specifies an optional hostname. Defaults to the current hostname.

-i

Specifies an optional IP Address.

Sample Input

myserver# dtchostinfo onefish

myserver# dtchostinfo <secondaryhostname>

（from the primary system only）

Sample Output

193.91.182.100 onefish

hostid : 0x82425e9b

NOTE In case an invalid option is specified, the command will assume the wrong host name and run.

133

9.15 dtcinfo

This command displays state information for one or more logical groups and their dtc devices . It

must be run on the primary system.

The following state information can be displayed:

• BAB memory size requested and BAB memory actually allocated.

• Logical Group operating mode (for example, NORMAL or PASSTHRU)

• dtc device information

• Version of the product installed on a system.

Options

-g <group#>

Displays information for all devices within the specified group. This option may be repeated to

include more than one logical group.

-a

Displays information for all dtc devices.

-v

Displays the version of the product installed on the system. This option can be used on the

secondary system.

Sample Input

myserver# dtcinfo -g 10

Sample Output

Requested BAB size ................ 536870912 (~ 512 MB)

Actual BAB size ................... 213909504 (~ 204 MB)

Free BAB size ..................... 213909504 (~ 204 MB)

Logical Group 10 (tdmf01 -> 1.2.3.4)

Mode of operations.............. Normal

Entries in the BAB.............. 0

Sectors in the BAB.............. 0

Sync/Async mode................. Async

I/O delay....................... 0

Persistent Store................ /dev/dsk/c0t0d0s5

Device /dev/dtc/lg10/rdsk/dtc0:

Local disk device number........ 0x80000d

Local disk size (sectors)....... 8391880

Local disk name................. /dev/rdsk/c0t1d0s5

Remote mirror disk.............. 1.2.3.10:/dev/rdsk/c0t0d0s5

Read I/O count.................. 0

Total # of sectors read......... 0

Write I/O count................. 0

Total # of sectors written...... 0

Entries in the BAB.............. 0

Sectors in the BAB.............. 0

134

9.16 dtcinit

This command initializes or resizes the BAB. Using this command is the only way to specify a size

other than the standard size available in the Configuration Tool dialog box.

Options

-b <bab_size_MB>

Resizes the BAB and changes the .cfg file to reflect the designated size.

-p <Pstore device>

Clears the set Pstore. Please close all logical groups using this Pstore before using this option.

Sample Input

myserver# dtcinit -b 512

Output

None.

9.17 dtckillbackfresh

This command terminates the BACKFRESH mode for one or more logical groups.

dtckillbackfresh moves the target logical groups out of BACKFRESH mode and into NORMAL mode.

This action takes place whether the PMD is running or not.

If the target PMD is not running but is in BACKFRESH mode (that is, if the PMD was in

BACKFRESH mode and the killpmds command was entered for it), then when it is restarted with the

launchpmds command, it is restarted in NORMAL mode.

Options

-g <group#>

Terminates backfresh daemons for logical group <group#>. Can be repeated to include multiple

logical groups.

-a

Terminates all backfresh daemons.

Sample Input

myserver# dtckillbackfresh –g 10 –g 100

Output

None

135

9.18 dtckillpmd

This command terminates one or more active PMD daemons.

NOTE If any target PMD is in BACKFRESH mode when dtckillpmd is entered for it, then Softek TDMF will

remember that; when the PMD is restarted, Softek TDMF restarts it in BACKFRESH mode where it left

off. The only way to take the PMD out of BACKFRESH mode is with the killbackfresh command.

Options

-g <group#>

Terminates PMD daemons for logical group <group#>. This option can be repeated to affect

multiple groups.

-a

Terminates all PMD daemons.

Sample Input

myserver# dtckillpmd –g 10 –g 100

Output

None.

9.19 dtckillrefresh

This command terminates REFRESH mode in one or more logical groups.

Options

-g <group#>

Terminates REFRESH mode for logical group <group#>. Can be repeated to include multiple

logical groups.

-a

Terminates REFRESH mode for all logical groups.

Sample Input

myserver# dtckillrefresh –g 10 –g 100

Output

None.

136

9.20 dtclicinfo

This command reports the state of the Softek TDMF licenses on this system. It also alerts you if

the license is missing or expired.

Options

None

Sample Input

myserver# dtclicinfo

Sample Output

Permanent license is valid for this system

9.21 dtcmonitortool

This command starts a tool for displaying Softek TDMF performance statistics in real time.

dtcmonitortool must be run on the primary, and only monitors logical groups that have been started. It

displays current values for a variety of parameters, error messages from both primary and secondary

systems, and alerts the operator of potentially fatal errors.

Options

-timeout seconds

Sets the number of seconds during which dtcmonitortool waits for a connection to be

established to a primary or secondary system to get the latest error messages and daemon

status. Default: 30.

-messages count

Sets the maximum number of retained error and warning messages. Default: 30.

-help

Displays the command line argument help message and exits.

Sample Input

myserver# dtcmonitortool

Sample Output

137

9.22 dtcoverride

The dtcoverride command clears the BAB or Pstore or forces a transition between Softek TDMF

operating modes.

NOTE Use caution when issuing this command, since it may cause a loss of synchronization between the

systems in Softek TDMF.

Options

-a

Validates all logical groups to be affected by the state forced change of state.

-g<group#>

Selects one or more logical groups to be affected by the state forced change of state.

clear [bab|LRT|HRT]

The BAB option clears the BAB. The LRT and HRT options clear the tracking bitmaps.

state [mode]

Forces a change of state for the designated logical groups. The modes you can specify are:

passthru

normal

tracking

Note that if specify a state of TRACKING on the dtcoverride command, the PMD associated with

the logical group is killed (if it is running) before the change of state takes effect.

Sample Input

myserver# dtcoverride -g 101 state normal

Output

None.

138

9.23 dtcperftool

This command starts the graphical charting tool for displaying Softek TDMF performance data.

Options

If primary and secondary configuration files are present on the system when dtcperftool is run, use

one of the following arguments to determine which files are queried:

-p

Specifies that dtcperftool should look for primary configuration files.

-s

Specifies that dtcperftool should look for secondary configuration files only.

Sample Input

myserver# dtcperftool

Sample Output

139

9.24 dtcrefresh

This command places one or more logical groups in REFRESH mode to synchronize the secondary

system’s mirror devices with the contents of the primary system’s local data devices. Use dtcrefresh

to:

• Establish an initial remote mirror during a new Softek TDMF installation.

• Reestablish a remote mirror if the BAB fills and automatically moves the logical groups into

TRACKING mode on the primary system by transferring only the changed data (smart refresh).

• Reestablish the mirror after a remote mirror device is replaced due to hardware failure.

NOTE Use the -f option to perform a full, sector by sector synchronization of the systems.

Options

-g <group#>

Places all the devices in logical group <group#> in REFRESH mode. Can be repeated.

-a

Places all the dtc devices in REFRESH mode.

-c

Initiates a checksum refresh in which all blocks on the local data device are compared with the

blocks on the mirror device using a checksum method to identify delta areas. Only blocks that

have been modified (that is, those for which the checksum varies) are sent to the secondary

system. A checksum refresh writes mirror data to the journal file system, not directly to the

mirror device.

-f

Forces a full refresh of all data blocks from the data devices to the mirror devices on the

secondary system.

Sample Input

myserver# dtcrefresh -a

Output

None

140

9.25 dtcrmdreco

This command should be used only when you are switching data ownership over to the secondary

system. It is a recovery utility that ensures the mirror devices are in a coherent and recoverable state

by flushing data from the journal file(s) to the corresponding mirror device(s).

The dtcrmdreco command creates a /etc/opt/SFTKdtc/s###.off file for each logical group. When

the primary system comes back online or when a new system is added to the configuration, the logical

group’s RMD detects the s###.off file and does not start mirroring operations. This keeps the mirror

devices from being corrupted before you perform a backfresh/refresh.

NOTE On AIX, the dtcrmdreco command will create a s###.off file in the /etc/dtc/lib directory.

Options

-g <group#>

Recovers data for logical group <group#>.

-a

Recovers data from all logical groups.

-d

Deactivates the recovery mode.

NOTE The -d option must only be used AFTER the recovery has been performed for the group. Using the -d

option before will generate the following error:

Couldn’t unlink file /etc/opt/SFTKdtc/s###.off The system cannot find the file specified.

Sample Input

myserver# dtcrmdreco -a Place the mirror devices of all logical groups in recovery mode

myserver# dtcrmdreco -d -g <group#> Releases the recovery mode for logical group#.

Sample Output

None.

141

9.26 dtcset

This command sets tunable parameters for each designated logical group. You can also use it to

view the current setting of a specific tunable parameter, or all parameters for a logical group. Run it

on the primary system only.

Note that you must run killpmds before and launchpmds after changing the following tunable

parameters:

• CHUNKSIZE

• COMPRESSION

• NETMAXKBPS

You must also run dtcstop and dtcstart after changing the following tunable parameters:

• SYNCMODE

• SYNCMODEDEPTH

• SYNCMODETIMEOUT

Options

-g <group#> <keyword>=<value>

Sets value of designated tunable parameters for each logical group. If you only specify a

keyword, Softek TDMF shows you current parameter setting. If you do not specify a keyword or

value, Softek TDMF shows you all tunable parameter values for the logical group.

Sample Input

myserver# dtcset -g 6 netmaxkbps=500

Sample Output

myserver# dtcset -g 10 netmaxkbps=500

myserver# dtcset -g 10

CHUNKSIZE: 2048

CHUNKDELAY: 0

SYNCMODE: off

SYNCMODEDEPTH: 1

SYNCMODETIMEOUT: 30

NETMAXKBPS: 500

STATINTERVAL: 10

MAXSTATFILESIZE: 64

TRACETHROTTLE: off

COMPRESSION: off

JOURNAL: off

myserver#

142

9.27 dtcstart

The dtcstart command processes the configuration file (.cfg) for the logical group(s) specified and

activates the dtc devices defined within the group. As the command processes each file, it creates a

copy that it renames with .cur extension. The .cur file is an exact copy of the group’s configuration file

when it was started and is referenced by all Softek TDMF commands during operations.

Configuration files (.cfg) are only processed by dtcstart, so when a group is stopped and restarted a

new .cur file is created. This allows you to make modifications to the .cfg files (for example, edit

throttle definitions) and have precise control over those changes when they are implemented. Also,

the .cur file ensures that all components of Softek TDMF have a consistent view of the configuration.

Starting a logical group make its dtc devices become available in the dropdown menus in the

Configuration tool.

NOTE Running dtcstart on a logical group with a large number of dtc devices can be slow.

Options

-g <group#>

Starts a specified logical group and its dtc devices.

-a

Starts all logical groups and their dtc devices.

-b

(For boot scripts only) restarts previously logical groups and their dtc devices that were active

prior to a system crash or that were stopped with the dtcstop –s option.

Sample Input

myserver# dtcstart -a

Output

None.

143

9.28 dtcstop

This command stops one or more logical groups and corresponding dtc device definitions. The

tracking bitmaps are written to the Pstore and the dtc device definitions associated with the logical

groups(s) are removed from the /dev/dtc device tree, making them no longer available for active use.

Options

-g <group#>

Stops a specified logical group and removes its dtc devices. This option can be repeated to

include multiple groups.

-a

Stops all logical groups and removes their dtc devices.

-s

(Fro boot scripts only) Stops the previously started logical groups but marks them enabled for

restart when the system is next booted.

Sample Input myserver# dtcstop -a

Output None.

145

Chapter 10 Softek TDMF Operation Considerations This chapter lists down some considerations while operating Softek TDMF.

10.1 Operating System Considerations

To arrange mirroring using Softek TDMF, both the operating system and the version number should

be the same on both Primary and Secondary.

10.2 Pstore Device

Please use a standard device for the Pstore. In case a device other than a standard is used (for

example a SafeDISK device or a device using a Multi-Path device driver), there may be chances of

system panic.

Some possible devices that can be used for the Pstore

[Solaris]

/dev/dsk Standard system device

Volumes created using GDS4.1A20/PRIMECLUSTER™GDS4.1.A20 and above.

[HP-UX]

Volumes created using LVM

Volumes created using CVM

Volumes created using VxVM

[AIX]

Volumes created using MKLV

10.3 Journal File Directory Space

In case of refresh operation (where the option to use the journal is set to ON) or during checkpoint,

the data updates to the local data device are accumulated under the journal file directory.

If the journal file directory space usage was not estimated correctly, or for that matter data

updates were much more than that expected, there may be cases when the journal file directory gets

filled up.

If such a case occurs please recover using the steps below. To change the journal file directory size,

please refer to [6.1.6 Resizing the Journal File Directory].

1. In case this occurs during Checkpoint ON state, release the checkpoint. In case the journal file

directory fills up during the Refresh process, the Refresh process will end in an error.

2. Delete all the files under the journal file directory on the secondary system.

3. Launch a full refresh for all the logical groups which are affected by the journal file directory filling

up.

Execute the following command:

launchrefresh -f -g<group #>

4. Confirm that the logical group has returned to NORMAL mode.

146

10.4 Considerations for Using Checkpoint on HP-UX

On HP-UX when the checkpoint is set to ON, and the dtc device of the primary system is in a

mounted state, and if you try to mount the mirror device on the secondary system, the operating

system will request an fsck. (In case the –r option of the read-only was used with the mount

command fsck will not be requested.).

This happens because the mirror device contains the primary device information and one of these is

that the device is already mounted. Hence trying to mount the mirror device again leads to the

operating system asking for an fsck to be run.

The fsck basically clears the above information, and this should not affect the normal operation of

the system.

Execute the fsck command as follows to clear the information that the device is already mounted.以

fsck -F FileSystem DeviceName

10.5 Consideration for VxVM on Solaris

When VxVM is used on Solaris ™, and if the mirror device is tried to be mounted, an fsck will be

requested. Running fsck does not have any effect on the system.

10.6 Consideration for JFS on AIX

In AIX, just mounting a JFS volume updates the device information. This is because JFS stores the

number of times a device was mounted or the last datetime of accessing the device, in the device.

Due to the above, if the mirror device is mounted on the secondary, the local data device and the

mirror device will become inconsistent. Hence after mounting the mirror device, even if the device

was mounted in the read-only mode or even if there were no data updates to the local data device, a

full refresh needs to be run after unmounting the mirror device.

147

Appendix A. Configuration File

Appendix FigureA.: An Example of a Primary Logical Group Configuration File

#===============================================================

# Softek TDMF Configuration File: /etc/opt/SFTKdtc/p010.cfg

# Softek TDMF Version 2.0.0

#

# Last Updated: Fri May 27 10:07:06 JST 2005

#===============================================================

#

# Primary System Definition:

#

SYSTEM-TAG: SYSTEM-A PRIMARY

HOST: tdmf01

PSTORE: /dev/dsk/c0t1d0s0

#

# Secondary System Definition:

#

SYSTEM-TAG: SYSTEM-B SECONDARY

HOST: 1.2.3.4

JOURNAL: /tmp

#

#

# Device Definitions:

#

PROFILE: 1

PRIMARY: SYSTEM-A

DTC-DEVICE: /dev/dtc/lg10/rdsk/dtc0

DATA-DISK: /dev/rdsk/c2t4d0s4

SECONDARY: SYSTEM-B

MIRROR-DISK: /dev/rdsk/c5t4d0s4

#

#

# -- End of dtc Configuration File: /etc/opt/SFTKdtc/p010.cfg

149

Appendix B. Throttle Refrence

B.1 Throttle Format

The general throttle format of Softek TDMF is shown below:

Throttle Format

THROTTLE[:] <dow-dom> <from-time> <to-time> <throttle-tests>

ACTIONLIST[:]

<action>

ENDACTIONLIST[:]

The colon is optional.

You can break up long lines in throttles into multiple, more readable lines by placing a “\” character

by itself at the end of a line that is continued on the next line.

For example:

THROTTLE: - - - PCTCPU > 30 AND \

ACTUALKBPS > 1000

The throttle fields are as follows:

<dow-dom> = “-“ means no day-of-week or day-of-month sensitivity

or

<dow-dom> = one or more comma separated items (no spaces allowed) consisting of days of the

month or two character days of the week of the mnemonics (for example, mo, tu, we, th, fr, sa, su), or

an “em” mnemonic, which always maps to the last day of the current month, or any or all of these in

specific order. These mnemonic values are case-insensitive and duplicates are allowed.

For example:

mo,tu,we,th,fr

1,15,em

1,mo,EM,15,4,15,SU,we

<from-time> = “-“ no time sensitivity for this throttle

or

<from-time> = a time specified in HH:MM:SS format before which the throttle may be evaluated.

For example:

01:00:00

12:59:00

18:15:00

<to-time> = “-“ no time sensitivity for this throttle

150

or

<to-time> = a time specified in HH:MM:SS format before which the throttle may be evaluated. <to-time> must be later than <from-time>.

For example:

01:00:00

12:59:00

22:45:00

<throttle-tests> = one or more test clauses expressed in terms of a measurement name, a

relational operator, and a value. If more than one test clause is given, a logical operator of either

“AND” or “OR” must be specified between the test clauses.

If these test clauses evaluates to TRUE, the subsequent ACTIONLIST is executed. If the test

clause evaluates to FALSE, then the subsequent ACTIONLIST is not executed.

The test clauses are evaluated from left to right. Up to 16 test clauses linked by logical operators in

a throttle test are allowed. The measurement keywords are case insensitive.

For example:

EFFECTKBPS T> 500

DRIVEMODE == 1 AND NETCONNECTFLAG != 1

B.2 Measurement Keywords

The following are the supported throttle measurement keywords:

NETKBPS – network throughput in KByte/sec. This is the same as EFFECTKBPS.

PCTCPU – percentage of system CPU that the PMD for this logical group is using.

PCTBAB – percentage of BAB that this logical group has in use. This is the same as

PERCENTBABINUSE.

NETCONNECTFLAG – set to “1” if the PMD is connected to the RMD for this logical group, “0” otherwise.

PID – process id (as returned by the ps command) for the PMD for this logical group (or “1” if PMD

is not running)

CHUNKSIZE – maximum size of a single data packet that the PMD sends to the RMD. Default is

2048 KB, with a maximum allowed of 10240 KB.

STATINTERVAL – number of seconds between each performance update calculation and throttle

evaluation. The default is 10.

MAXSTATFILESIZE – number of kilobytes that a performance file is allowed to grow to. The default

is 64 KB.

STATTOFILEFLAG – if set to “1” (on), performance information is added to the performance files. If

set to “0” (off), the performance files are not updated. The default is “1”.

TRACETHROTTLE – if set to “1” (on), every throttle that evaluates to TRUE and the

corresponding ACTION executed is logged to syslog and the Softek TDMF error log. If set to “0” (off),

these are not logged. The default is “0”.

151

SYNCMODE – if set to “0” (off), this logical group is in asynchronous transfer mode. If set to “1” (on), this logical group is in synchronous, or semi-synchronous transfer mode. The default is “0”.

SYNCMODEDEPTH – the depth of I/O updates that may accumulate in synchronous mode before

the dtc device driver will block the application. If this is set to “1”, then this logical group is in

synchronous mode. If this value is greater than “1”, then this logical group is in semi-synchronous

mode.

SYNCMODETIMEOUT – the number of seconds that the dtc device driver will allow a synchronous

or semi-synchronous update to be sent to the secondary system, and wait for an acknowledgement of

committed update by the RMD before moving on to the next update pending.

COMPRESSION – if set to “1” (on), moderately effective compression is applied to updates sent by

the PMD to the RMD. If set to “0” (off), only trivial zero-filled block discard compression is employed.

The default is “0”.

NETMAXKBPS – limit imposed on the PMD as to how many kilobytes per second (on average) will

be allowed to occupy the network bandwidth between the primary and secondary systems.

CHUNKDELAY – the number of milliseconds the PMD sleeps after sending a packet of data to the

RMD. This is a tunable parameter for moderating CPU utilization and is separate from the

NETMAXKBPS regulating mechanisms in the PMD, but affects the network throughput realized.

DRIVERMODE – may assume one of the following values.

0 = NORMAL mode – coherent update collection/transmission

1 = TRACKING mode – collecting changed block pointers for a smart REFRESH

2 = PASSTHRU mode – all operations directed to local data devices only

3 = REFRESH mode – performing a refresh on TRACKING mode data and collecting new updates

coherently.

4 = BACKFRESH mode – updating the local data devices from the mirror devices on the secondary

ACTUALKBPS – the number of actual physical kilobytes sent from the PMD to the RMD per

second over the network.

EFFECTKBPS – the effective kilobytes per second by the PMD to the RMD over the network

(decompressed).

PERCENTDONE – the percentage that a refresh or backfresh operation has completed for a logical

group.

ENTRIES – the number of I/O updates received by the dtc device driver awaiting transmission to

the secondary system.

PERCENTBABINUSE – the percentage of occupation of the BAB by entries awaiting transmission

to the secondary system.

B.3 Actions

Specify throttle actions with the following keywords.

<action> = a directive to do something with optional values or messages.

You can include up to 16 actions in an ACTIONLIST.

B.4 Action Directives

The following is a list of possible action directives you can use in throttles:

152

ACTION[:] do console < message >

Send a message to the primary system’s console

ACTION[:] do mail < to-whom> <message>

Send mail message

ACTION[:] do exec <program-or-script> <arguments>

Execute an external program or script

ACTION[:] do log < message >

Log a message in the syslog and in the dtcerror.log file.

ACTION[:] set <tunable> <value>

Set a tunable parameter to a specific value

ACTION[:] incr <tunable> <amount-value>

Increament a tunable parameter value by an amount.

ACTION[:] decr <tunable> <amount-value>

Decrement a tunable parameter value by an amount.

B.5 Tunable Action Parameters

You can set the following tunable parameters using a throttle:

CHUNKDELAY

CHUNKSIZE

STATINTERVAL

MAXSTATFILESIZE

TRACETHROTTLE

SYNCMODE

SYNCMODEDEPTH

SYNCMODETIMEOUT

COMPRESSION

B.6 Action Message Substitutions

Action message substitutions must be in uppercase within ACTION statements and must be

specified with a leading “%%” and trailing “%%”. They must not be embedded in another word. An

example of an action message substitution is: “do mail root effective kbps = %%EFFECTKBPS%%”.

PID PMDs process id (as from the ps command)

GROUPNO Current logical group number

CFGFILE Path to the configuration file for logical group

CPU CPU % consumed by the PMD process

KBPS Effective kilobytes per second transmitted

153

PCTWL Percent of the BAB currently in use

SLEEP Current setting for CHUNKDELAY

TIME Current time as “hh:mm:ss”

DATE Current date as “mmm dd, yyyy”

NETCONNECTFLAG 1=PMD is actively in communication with the RMD

CHUNKSIZE Maximum size of packets sent to secondary system

STATINTERVAL Number of seconds between throttle evaluations

MAXSTATFILESIZE Maximum size performance files will grow in KBs

STATTOFILEFLAG 1=log performance information, 0=do not log performance

information

TRACETHROTTLE Write message to syslog/dtcerror.log for executing

actions

SYNCMODE 1=sync or semi-sync mode, 0=async mode

SYNCMODEDEPTH 1=sync mode, > 1= semi-sync mode maximum growth

SYNCMODETIMEOUT Seconds in which sync mode is honored for each update

sent

COMPRESSION 1=best compression employed, 0=trivial compression

employed

NETMAXKBPS Maximum kilobytes per second (average) allowed over

net.

CHUNKDELAY Milliseconds slept between packets sent over network

DRIVERMODE NORMAL, TRACKING, PASSTHRU, REFRESH or

BACKFRESH

ACTUALKBPS Physical kilobytes sent over the network per second

EFFECTKBPS Decompressed kilobytes received by the RMD

PERCENTDONE Percentage the refresh or backfresh has completed

PERCENTBABINUSE Percentage of BAB with data awaiting transfer

155

Appendix C. Tunable Parameters This appendix describes the tunable parameters and their functionality.

For the following parameters the killpmds command must be executed before and the launchpmds

command must be executed after updating their values.

CHUNKSIZE

COMPRESSION

NETMAXKBPS

For the following parameters, the dtcstop command must be executed before and the dtcstart

command must be executed after updating their values.

SYNCMODE

SYNCMODEDEPTH

SYNCMODETIMEOUT

C.1 CHUNKDELAY

This parameter sets the amount of time, in milliseconds, that the PMD waits before attempting to

send a chunk of entries from the BAB across the network.

CHUNKDELAY is simply a method to regulate the performance of a PMD. Consider using this

parameter to regulate the amount of network bandwidth consumed by Softek TDMF. Setting

CHUNKDELAY to a value greater than 0 causes the PMD to wait the designated amount of time

before attempting to transfer data. The default is 0.

C.2 CHUNKSIZE

This parameter sets the amount of information, in Kbytes, that the PMD reads from the BAB at a

time and sends across to the RMD.

The CHUNKSIZE parameter can help optimize disk access while Softek TDMF is performing a

refresh. Each operation reads the amount of data defined by CHUNKSIZE. The default is 2048 KB.

Be aware when setting this parameter, that an I/O operation that writes a data amount greater than

the value of CHUNKSIZE may cause the BAB to overflow.

C.3 COMPRESSION

This parameter sets data compression. The default is OFF, which indicates that data being

transferred is in its original, non-compressed state. If set to ON, then data is compressed before

being transferred and decompressed before being written to the journal or mirror device on the

secondary system. Compression is a means to optimize network throughput.

C.4 MAXSTATFILESIZE

This parameter governs the size, in kilobytes, for the performance file when LOGSTATS is set to

“Y”. Once a performance file reaches the size set by this parameter, the file is closed and renamed

with a .1 suffix. Only one generation of files is saved. Then the original file is emptied and readied to

collect new performance metrics.

This parameters allows you to establish the amount of disk space for these performance

156

statistics.The frequency at which these files are updated is determined by STATINTERVAL(please

refer to [C.6 STATINTERVAL]), so in a round about way, MAXSTATFILESIZE also allows you to save

a large number of statistics, spread out over a long period of time (by increasing the value of this

parameter) – if the goal is to decipher trends over a long operating period. Or the operator can

choose to limit the statistics (by reducing the value of this parameter) to only a short period of time.

The default is 64 KB.

C.5 NETMAXKBPS

This setting regulates the network bandwidth, in kilobytes per second, Softek TDMF uses. The

following figure shows an example of how this tunable parameter can be set up in a throttle to control

over network bandwidth during specific hours. The default is -1 (OFF).

Figure C.1: Example of Network Bandwidth Throttle

C.6 STATINTERVAL

This parameter defines the frequency, in seconds, at which Softek TDMF evaluates throttles,

tunable parameters and performance metrics. The default is 10 seconds.

C.7 SYNCMODE

This parameter determines whether the dtc devices in a logical group require a synchronous and

acknowledged update from the secondary mirror device with each I/O update to the local data

device.When set to Y, all I/O operations are performed on both the local data and mirror devices disks

at all times. Setting this parameter to Y affects application performance because of round trip

network time added to each I/O. Setting this parameter to N allows transfers to be made

asynchronously. The default is N.

C.8 SYNCMODEDEPTH

This option sets the number of I/Os that can accumulate in the BAB before Synchronous mode is

triggered. If SYNCMODEDEPTH is set to 1 and SYNCMODE is set to Y, then dtc devices in the

logical group are in full Synchronous mode. If SYNCMODEDEPTH is set to to a value larger than 1,

157

then the logical group is in Asynchronous mode, but the mirror devices on the secondary are no

more than the specified number of entries (set by this parameter) behind the local data devices. The

default is 1.

C.9 SYNCMODETIMEOUT

This parameter establishes the amount of time, in seconds, that the dtc device driver waits for a

Synchronous mode update to complete before returning control to the application, just as if the

acknowledgement of the mirror device update has been received. This does not indicate that Softek

TDMF has switched to Asynchronous mode, but rather this parameter keeps the application from

freezing up if there is a high load burst on either the network or the secondary. The default is 30

seconds.

C.10 TRACETHROTTLE

This parameter determines whether throttle information is written to the syslog

(/var/adm/ras/errorlog) and to the error log file (/var/opt/SFTKdtc/dtcerror.log) when a throttle

evaluates TRUE. If this parameter is set to either “on”, “ON”, or “1”, then each ACTION in the

ACTIONLIST for the throttle is written out to these files along with the current values of variables

included in the throttle definition. This provides the operator with a method of verifying that a throttle

executed properly. The default is OFF.

Please note that for AIX, the path for the error log is /var/dtc/dtcerror.log

C.11 JOURNAL

This parameter represents whether the journal should be used or not in case of the Refresh

operation (Smart Refresh and Checksum).

In case it is set to Off, then the journal is not used. In case it is set to On then the journal is used.

The default option is Off.

In case where the journal is not used, the data sent to the secondary because of the Refresh

operation and the data updates on the local data device during the Refresh operation, are both

directly applied to the mirror device.

In case where the journal is used, the data sent to the secondary because of the Refresh operation

and the data updates on the local data device during the Refresh operation, are both accumulated in

the journal. Once the data has been completely transferred, the data accumulated in the journal is

applied directly to the mirror device.

In the case where the journal is used, there are times when the data transferred as a result of the

Refresh operation may be very high which may lead to the possibility of journal directory space

running out. In such cases it becomes necessary to execute the Full Refresh operation.

In the case where the journal is not used, even if the data transferred is high, since the journal is

not used during the Smart Refresh operation, the possibility of the journal directory space running out

does not exist.

159

Appendix D. Production Operation Examples This appendix explains how Softek TDMF can be used in various production scenarios.

D.1 Database Migration Example

To migrate data stored in a disk, using Softek TDMF, the device name needs to be changed twice.

(1) To use the dtc device and access the data, the original device name needs to be changed

to the dtc device name.

(2) Once the data is synchronized, and if the operation needs to switch over to the mirror

device, the dtc device name should be changed to the mirror device name.

In the case of databases, the RDBMS stores the device name, and hence for database migration

follow the steps below.

D.1.1 Migration from Local Data Device to dtc Device

Please refer to section [4.10.2] for migration of data from local data device to the dtc device.

D.1.2 Migration from dtc Device to Mirror Device

If the local data device and mirror device are synchronized, and the database is using the dtc

device, with both devices being accessible, then the steps to migrate to an environment using only the

mirror device.

The following devices are used as an example for mirror devices.

Mirror Device 1: /dev/dsk/c2t0d0s4

Mirror Device 2: /dev/dsk/c2t0d0s5

Mirror Device 3: /dev/dsk/c2t0d0s6

1. Shut down the database.

2. Execute the following command, and shut down the target logical groups.

killpmds –g <Logical Group Number>

dtcstop –g <Logical Group Number>

3. Using the rm command, delete the physical devices that were set up at the time of database

creation.

rm /dev/dsk/c1t0d0s4

rm /dev/dsk/c1t0d0s5

rm /dev/dsk/c1t0d0s6

rm /dev/rdsk/c1t0d0s4

rm /dev/rdsk/c1t0d0s5

rm /dev/rdsk/c1t0d0s6

4. Create a symbolic link for the mirror devices using the path names that were used during the

creation of the database.

ln –s /dev/dsk/c2t0d0s4 /dev/dsk/c1t0d0s4

ln –s /dev/dsk/c2t0d0s5 /dev/dsk/c1t0d0s5

ln –s /dev/dsk/c2t0d0s6 /dev/dsk/c1t0d0s6

160

ln –s /dev/rdsk/c2t0d0s4 /dev/rdsk/c1t0d0s4

ln –s /dev/rdsk/c2t0d0s5 /dev/rdsk/c1t0d0s5

ln –s /dev/rdsk/c2t0d0s6 /dev/rdsk/c1t0d0s6

5. Start the database. The database will now access the data via the mirror device.

D.2 Migration of a SafeFILE System Example (Solaris)

The following procedure explains how multiple devices using SafeFILE can be accessed using one

file system. In the production environment, please consider that the following multiple devices are

being used.

SafeFILE Device 1: /dev/dsk/c1t0d0s3

SafeFILE Device 2: /dev/dsk/c1t0d0s4

The mirror devices are as follows:

Mirror Device 1: /dev/dsk/c2t0d0s5

Mirror Device 2: /dev/dsk/c2t0d0s6

The following conditions must be met for migration

SafeFILE Device 1 and Mirror Device 1 must have the same capacity

SafeFILE Device 2 and Mirror Device 2 must have the same capacity.

The mirror devices should not be under the SafeFILE system.

The following is the procedure

1. Stop access to SafeFILE devices 1 and 2.

2. Configure the logical group such that SafeFILE Device 1 mirrors to Mirror Device 1 and SafeFILE Device 2 mirrors to Mirror Device 2. dtc devices should be created based on the above and the PMD should be started.

3. Start full refresh by executing the launchrefresh –af command.

4. Using either the dtcmonitortool or the dtcperftool, the completion of the refresh operation can be monitored.

5. Using the commands below please create the SafeFILE system for the mirror devices.

sfxadm /dev/rdsk/c2t0d0s5, /dev/rdsk/c2t0d0s6

sfxnode /dev/rdsk/c2t0d0s5, /dev/rdsk/c2t0d0s6

NOTE If the primary and the secondary systems are different, then in the sfxnode command, the secondary’s

host name and host id are required. For further details regarding the sfxnode command please refer to

the SafeFILE manual [SafeFILE Explanation Guide].

161

Glossary A Accumulate

The Softek TDMF mode in which the PMD and the RMD are not operating for the logical group, and the

updates to Softek TDMF devices are accumulating in the BAB.

Action

A directive in a throttle definition to do something with optional values and messages.

ACTIONLIST

The component of a throttle which lists the actions defined for that throttle.

Actual KBps

The actual amount of data, in KBps, sent over the network reported by dtcperftool.

Aggregated Throughput

A group of network connections whose throughput is considered as a whole.

Automatic Recovery

Softek TDMF’s action of going into Tracking Mode and then launching a smart refresh when the BAB

exceeds its limits.

B BAB

The buffer cache in physical memory used to store transactions waiting to be mirrored to the secondary

system.

Backfresh Mode

The maintenance mode in which data is being copied from the current secondary system to the current

primary system. dtcconfigtool during Softek TDMF configuration. These files are processed by dtcstart.

All .cfg files need to be copied over the secondary system and renamed.

Chaining

A configuration option in which systems appear to be connected in a sequential manner, such as A to B to

C.

Checkpoint Scripts

Optionally implemented scripts for automating pre- and post- checkpoint tasks.

Checkpointing

The act of taking a snapshot image of data on the mirror devices and making this data accessible in a

read-only mode to applications other than Softek TDMF.

CHUNKDELAY

A parameter that defines, in milliseconds, determined by the operator, which designates the length of time

the PMD is idle between transfers of data.

CHUNKSIZE

A parameter that defines the amount of data, in KBytes, that is sent across the network during a transfer.

162

.cur Files

These are copies of the .cfg (logical group configuration files), which dtcstart creates when it processes

a .cfg file. These files are accessed and referenced by all other Softek TDMF commands during operations.

The dtcstop command deletes the .cur file for specified logical groups.

D Data Coherence

The integrity of information written to dtc devices.

Data Migration

The periodic passing of data between primary and secondary systems.

Dynamic Allocation

The as needed method of distribution of the memory assigned to the BAB between logical groups.

E Effective KBps

The amount of data being transferred across the network without compression.

F Full Refresh

The process in which each block of data on the local data device is copied to the mirror device.

I in.dtc

The master Softek TDMF daemon process running on all primary and secondary systems in the company,

which is responsible for launching and managing all other processes.

Incoherent State

The data that is lacking continuity or is in an inconsistent state. In the context of Softek TDMF, this is a

temporary state from which data can be recovered.

Initial Mirror

The untouched copy of the original data set on the secondary system.

J Journal File Directory

The user-defined directory or directories on the secondary system where journal files are written.

Journaling

The act of recording current updates in a log file (journal) on the secondary system rather than writing the

data directly to the mirror device.

L License Key

A 24 character alphanumeric string placed in the license file (DTC.lic) that unlocks the daemon processes

and allows Softek TDMF to be operational.

Local Data Device

A disk partition or managed volume on a primary system that stores all or a portion of the original data set.

A local data device is the primary system side of the dtc device.

163

Logical Group

A virtual, not physical, grouping of dtc devices into a cohesive unit across which data coherence is

maintained.

LOGSTATS

A tunable parameter indicating whether performance statistics should be logged in the performance files.

The default is “Y”.

M MAXSTATFILESIZE

A tunable parameter that designates the maximum size (in KBytes) for the file of performance metrics, if

statistics are being logged. The default is 65 KB.

Mirror Device

A device configured on the secondary system, on which an exact replica of the original data set is stored.

N NETMAXKBPS

A tunable parameter that designates the maximum amount of data, in KBytes per second, to be transferred

across the network. This is a means of controlling how much bandwidth Softek TDMF consumes.

Normal Mode

A healthy operational state in which all typical network data mirroring elements are functional.

O .off File

A file placed in the /etc/opt directory by the dtcrmdreco command that prohibits mirroring to the secondary

mirror devices. Typing a dtcrmdreco -d command deletes this file.

Original Data Set

The data set residing on the primary system.

P p###.cfg Files

Logical group configuration files created by dtcconfigtool during configuration. These files are processed by

dtcstart.

p###.cur Files

Copies of the .cfg files created by dtcstart.These files are referenced by all Softek TDMF commands during

normal operations.

Passthru Mode

A transitional mode of operation in which data is not being mirrored to the secondary system. Softek

TDMF operates in this mode initially after installation.

PMD

The primary mirror daemon (PMD) is a background process on the primary system responsible for

establishing a connection with the secondary system, and transferring data from the BAB to the

appropriate mirror device.

Primary System

System(s) in Softek TDMF in which the original data set resides, local data devices are configured and

164

applications are active.

Pstore

The persistent storage (pstore) is allocated during configuration for state information and contains tunable

parameter definitions.

R Recoverable State

The condition of data at a point in time when it cannot be accessed and used without re-establishing the

usability of the data. For example, data on the mirror devices is in a recoverable state during a refresh

operation, or while entries are being copied from the journal files to the mirror devices.

Refresh Mode

An operational mode in which the data on the mirror devices is being renewed from the local data devices.

RMD

The remote mirror daemon (RMD) is the background process on the secondary system that handles the

writing of data to the mirror devices or to the journals.

S Secondary System

A system in Softek TDMF that stores a mirror copy of the original (primary) data set to be accessed

during planned or unplanned outages for the purpose of disaster recovery or maintenance.

Smart Refresh

The process of transferring only blocks of data that have recently changed from the local data device to

the mirror device.

s###.off Files

Files created by the dtcrmdreco command that prohibit mirroring to the mirror devices on the secondary

system.

STATINTERVAL

A parameter that defines the time, in seconds, that elapses before the throttle process calculates

performance metrics and evaluates all throttles. The default is 10 seconds.

Synchronization

The process that ensures that all systems in the company are loaded with identical sets of contemporary

data.

SYNCMODE

A tunable parameter that governs whether a synchronous and acknowledged update is required from each

secondary system with every I/O.

SYNCMODEDEPTH

A tunable parameter that determines the number of entries allowed to accumulate asynchronously in the

BAB before being transferred and acknowledged by the secondary system. If this value is set to a

number greater than 1, the dtc devices are in semi-synchronous mode.

T throtd

The Softek TDMF daemon process responsible for evaluating and executing throttles.

165

Throttle

An optional user-defined gauge that can fine-tune certain Softek TDMF functions by monitoring elements,

measuring variables, and performing actions.

Throttle Editor

The function in dtcconfigtool where you define or edit throttle definitions.

Time Sequenced Transfers

A method through which Softek TDMF ensures data coherence by preserving the order of consecutive

updates to the local data device as they are written to the BAB and later transferred to the mirror device.

TRACETHROTTLE

A tunable parameter that monitors the execution of throttles and writes each ACTION and current variable

values to the syslog and the error log file. The default is “N”.

Tracking Mode

The operational mode in which updates to the local data device are not written to the BAB, but are rather

recorded in a disk map.

Tunable Parameters

The optional user-defined variables, stored in the pstore, that allow fine-tuning of certain Softek TDMF

components.

Typical Operations

Tasks representative of Softek TDMF network data mirroring, such as writing simultaneously to the BAB

and the local data device, and reading entries from the BAB and sending them to the appropriate mirror

device.

U Unplanned Outage

An inadvertent loss of one or more components in the data mirroring enterprise that disrupt normal

activity.

2