softek tdmf open system edition admin guide · 2016-09-19 · softek tdmf is a network-based disk...
TRANSCRIPT
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