HADR simulator

1 like Updated 12/10/13 3:09 AM by zhugeTags: None

Back to HADR Home

IBM DB2 High Availability Disaster Recovery (HADR) Simulator

Table of Contents

  

Introduction

HADR (High Availability Disaster Recovery) is a DB2 feature that provides high availability and disaster recovery protection. When enabled, transaction log records from the primary database are shipped to the standby database in real time as the records are written to disk on the primary database. The standby database continuously replays the received logs, thus staying in synch with the primary database. Should the primary fail, the standby takes over to provide continued service.



HADR is easy to use. It is fully integrated in DB2. Setup only requires a few database configuration parameters. It uses standard TCP interface to connect the primary and standby databases. It requires no special hardware or software.



With IBM DB2 High Availability Disaster Recovery (HADR) Simulator, HADR planning and deployment is even easier. You can estimate HADR performance under various conditions without even starting any database. HADR simulator simulates DB2 log write and HADR log shipping. It can

  • Estimate HADR performance under different sync modes.
  • Measure disk performance.
  • Measure network performance using HADR specific workload.
  • Experiment with hypothetical disk speed.
  • Experiment with various network tuning options.

The simulator helps the user to plan, measure and diagnose HADR quickly. The simulator is very light weight. It consists of one process running on the primary host and one process running on the standby host. No setup or installation is needed. All configuration is passed as command line argument. The simulator itself is a standalone executable. No installation of DB2 or any other software packages is needed. You can run it on any machine and get result in seconds, without even starting the database.



The simulator arguments closely match HADR configuration, using parameters like local host, local port, remote host, remote port, tcp socket send/recv buffer. Tuning result from the simulator can be straight forward applied to real HADR.

Together with DB2 Log Scanner and HADR Calculator, you can quantitatively compute HADR performance based on your workload. See step by step guide on using these tools for HADR performance tuning.

Download

IBM DB2 HADR Simulator and db2flushsize script are provided free of charge to current and potential IBM customers. They are provided as is, with no explicit or implicit warranty. Read licensing terms at IBM Software License before you proceed. Download only if you agree on the license terms.



The HADR simulator executable (simhadr) is stand-alone. It does not need any DB2 libraries. You can run it on machines without DB2 installation. Binaries for selected platforms are pre-built. The OS version listed here is the version where the binary is built. Generally, the binary can also run on newer OS versions, but not older versions. If you need the simulator on other platforms, email db2hadr@wwpdl.vnet.ibm.com

 

File name OS  OS version   Bit size   Architecture 
simhadr_aix AIX 6.1 64 powerpc
simhadr_aix53 AIX 5.3 64 powerpc
simhadr_hpia HP-UX 11.31 64 IA64
simhadr_linux Linux 2.6 64 x86_64
simhadr_linux32 Linux 2.6 32 x86
simhadr_linux_z Linux 2.6 64 s390x
simhadr_linuxppc Linux 2.6 64 powerpc
simhadr_sun SunOS 5.10 64 sparc
simhadr_sunx86 SunOS 5.10 64 x86
simhadr_win.exe Windows (N/A) 32 x86
simhadr_win64.exe Windows (N/A) 64 x86



You may also find simhadr file listing on IBM developerWorks file sharing using the simhadr tag.

Version history

  • 2012 Version 2.1, support superAsync mode and add testing both disk read and write.
  • 2008 Version 2. Initial public release

Running simhadr with no argument will return version number, bit size, and help messages.

 

Running the Simulator

This section describes how to run the simulator for various HADR configurations. For details on all command line options. See next section "Command line options".

Simulating Single Standby Systems

On the primary host, run simhadr as primary via "-role primary" option. On the standby host, run with "-role standby". Starting either process first is fine. The two processes will connect to each other and start log shipping. You may use -n (number of flushes) or -t (number of seconds) on primary to specify the length of the run. You can also interrupt a run any time by sending an "interrupt signal" (SIGINT, usually sent via control-C on keyboard) to the primary process. Upon end of run (including interrupted runs), both primary and standby will print out performance statistics to stdout.

Simulator only accepts numerical port numbers. It does not accept service names. This applies to -lport and -rport options.

For -lhost and -rhost options, both host name and IP address (such as 1.2.3.4) are accepted, just like real HADR.

Example:

- primary host is portland.ibm.com, HADR port is 4000

- standby host is sanfrancisco.ibm.com. HADR port is 5000.

- Sync mode is ASYNC (default is NEARSYNC)

- Run length is 60 seconds (default is 4 seconds)

On primary host portland.ibm.com, run:

simhadr_linux -lhost portland.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5000 -role primary -syncmode ASYNC -t 60



On standby host sanfrancisco.ibm.com, run:

simhadr_linux -lhost sanfrancisco.ibm.com -lport 5000 -rhost portland.ibm.com -rport 4000 -role standby

Simulating Multiple Standbys

To simulate multiple standbys (supported in DB2 starting V10.1), start multiple pairs of primary-standby concurrently, with all primary processes on the primary host. In real HADR, each standby is served by a dedicated thread in the primary database. So the simulation is realistic in terms of data flow. In simulator, the primary processes are independent of each other. Each must be assigned a different local port. The standbys can have the same port because they run on different hosts. In real HADR, only one primary thread listens on the hadr_local_svc port of the primary database. All standbys connect to this port. After connection, the listener thread passes the connection over to the dedicated HADR thread (this is common TCP server design).

It is important to run the pairs concurrently to test if the primary can ship logs to multiple standbys at the same time. It is possible that one pair gets a lot more share of network bandwidth than the other. You may use -target option to limit the bandwidth a pair uses.

Multiple standby example:

- primary host is portland.ibm.com, HADR port is 4000 and 4001

- standby 1 host is sanfrancisco.ibm.com. HADR port is 5000. Sync mode is NEARSYNC

- standby 2 host is newyork.ibm.com. HADR port is 6000. Sync mode is SUPERASYNC.

On primary host portland.ibm.com, run:

simhadr_linux -lhost portland.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5000 -role primary -syncmode NEARSYNC -t 60

and

simhadr_linux -lhost portland.ibm.com -lport 4001 -rhost newyork.ibm.com -rport 6000 -role primary -syncmode SUPERASYNC -t 60

On standby 1 host sanfrancisco.ibm.com, run:

simhadr_linux -lhost sanfrancisco.ibm.com -lport 5000 -rhost portland.ibm.com -rport 4000 -role standby

On standby 2 host newyork.ibm.com, run (note that it connects to port 4001 on primary):

simhadr_linux -lhost newyork.ibm.com -lport 6000 -rhost portland.ibm.com -rport 4001 -role standby

Simulating pureScale Systems

To simulate HADR on pureScale systems (supported in DB2 starting V10.5), start multiple pairs of primary-standby concurrently, with each primary processes on a pureScale member host and all standby processes on the standby replay member host. In real HADR, all primary members connect to the standby replay member, where a dedicated thread serves each primary member. This is like the reverse of multiple standbys (multiple standby: one to many log shipping. pureScale: many to one log shipping).

It is important to run the pairs concurrently to test if the standby can receive logs from multiple primary members at the same time. It is possible that one pair gets a lot more share of network bandwidth than the other. You may use -target option to limit the bandwidth a pair uses.

pureScale example:

- primary member 0 host is portland_0.ibm.com, HADR port is 4000

- primary member 1 host is portland_1.ibm.com, HADR port is 4000

- standby replay member host is sanfrancisco.ibm.com. HADR port is 5000 and 5001.

- Sync mode is ASYNC

On primary host portland_0.ibm.com, run:

simhadr_linux -lhost portland_0.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5000 -role primary -syncmode ASYNC -t 60

On primary host portland_1.ibm.com, run:

simhadr_linux -lhost portland_1.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5001 -role primary -syncmode ASYNC -t 60

On standby replay host sanfrancisco.ibm.com, run:

simhadr_linux -lhost sanfrancisco.ibm.com -lport 5000 -rhost portland_0.ibm.com -rport 4000 -role standby

and

simhadr_linux -lhost sanfrancisco.ibm.com -lport 5001 -rhost portland_1.ibm.com -rport 4000 -role standby

32 vs. 64 Bit Binary

DB2 HADR simulator can be compiled into either 32 or 64 bit applications. The bit size is shown in simhadr help message. Normally, there is little performance difference between the bit sizes. For best result, it is recommended that you run simhadr with the same bit size as your DB2 installation.

OS and Endian Compatibility

Real HADR requires the primary and standby host machines to be of the same OS type and machine architecture. The simulator has no requirement on OS type, or machine architecture (primary and standby can be on machines of different endian). This allows you to experiment on mixed platforms.

 

Command Line Options

See Command line options

 

Interpreting simulator output

See HADR simulator output

 

Simulation Parameters and Scenarios

Flush size, Sync mode, Disk speed, Send and receive buffer sizes, etc.

See HADR simulator parameters

 

HADR Configuration and Performance Tuning

Together with DB2 Log Scanner and HADR Calculator, you can quantitatively compute HADR performance based on your workload.

See step by step guide on using these tools for HADR performance tuning.

 

About the author

HADR simulator and its documentation was written by Yuke Zhuge. Yuke is the HADR development team lead at IBM. He is a leading expert on HADR. He has been working on HADR since its creation. Over the years, he has lead the team through many HADR features. He can be reached at db2hadr@wwpdl.vnet.ibm.com