WindowsでSDS ( VPC2007使用)

Virtual PC 2007 を使ってWindows XP 仮想PCによる SDS 環境を作ってみました。
(UPDATED 2007-11-26: この記事の内容について、Guy Bowerman氏から質問を受けました。再確認したところ、一部間違いがありました。以下修正済みです。)

IDS 11.10.TC1 を使用しました。OSは Windows XP SP2 ( Japanese ) です。Virtual PC2007をインストールした後、仮想PCインスタンスを２つ作成し、それぞれの仮想PCにゲストOSとして Window XP SP2をインストールしてください。この２つの仮想PCインスタンスのうち一つが primary機 ( pc1 )、もう一つが secondary ( pc2 ）です。コンピューター名もそれぞれ、pc1, pc2 に設定してください。

1. 事前準備

ここでは、primary機 ( hostname= pc1 ) 上のINFORMIXSERVER名が ol_pc1 だとしましょう。セカンダリー機 ( SDSノード。 hostname= pc2 ) のINFORMIXSERVER名は ol_pc2 ということにしましょう。

(1) 複数の仮想 PC 間のネットワークに MS Lookback adapter を使う

NATを使っても良いのですが、「テスト環境をLANにはつなぎたくない」という方もいると思いますので、ローカルのネットワークを構成してみましょう。

最初に、MS Lookback adapter を ホスト OS 側に追加しておきます。コントロールパネルの「ハードウェアの追加」アイコンを起動し、

「はい、ハードウェアを接続しています(Y)」　次へ (N)
「新しいハードウェア デバイスの追加」 次へ (N)
「一覧から選択したハードウェアをインストールする (詳細))(M)」 次へ (N)
「ネットワーク アダプタ」 次へ (N)
「製造元」の欄で「Microsoft」
「ネットワーク アダプタ:」の欄で「Microsoft Lookback Adapter」 次へ (N)

の順にクリックします。また、この時、ゲスト OS 側のTCP/IP 設定では、静的アドレスを割り当てるように設定します。各仮想マシンの%SYSTEMROOT%\system32\drivers\etc\hosts に、例えば次のように記述します。

192.168.11.1 pc1
192.168.11.2 pc2

(2) 仮想 PC 間の認証回避設定

双方の%SYSTEMROOT%\system32\drivers\etc\hosts.equiv にお互いのホスト名を追記。

(3) 複数の PC で共有できるディスク領域の準備

ここでは、Virtual PC 2007 の共有フォルダー(Shared Folder) 機能を使い、ホスト・オペレーティングシステム側のディスクをそれぞれのPCからアクセスできるようにしました。(UPDATED 2007-11-26: 以前KAIOOFFで問題回避できると書きましたが、関係なかったようです。)
それから、この共有のディスク領域は、それぞれのPCから同じパスで参照できるようにしてください。SDSに限らずInformixのHDRでは、すべてのノードでDB領域のパス ( 例えば ROOTPATH ) を同じにしておく必要があるからです。

(4) ONCONFIG ファイルの準備

Windows 版のサーバー・インスタンス・マネージャーで、2台の仮想PC (pc1, pc2 ) 上に、それぞれol_pc1, ol_pc2 という名前でインスタンスを作ります。後で初期化してしまうので、ディスク構成などはどのように設定しても構いませんが、ROOT DB領域は、先ほど(3)で用意した、双方のPCで共有される領域に置くようにします。その後、pc1上でサーバー・インスタンス・マネージャーが生成した初期状態の　ol_pc1用 ONCONFIG ファイル ( onconfig.ol_pc1)に少し手を加えます。

SDS_ENABLE 0
SDS_TEMPDBS　 ( 値: サーバー pc 1上のローカルディスク上の一時DB領域の指定 )
SDS_PAGING ( 値: サーバー pc 1上のローカルディスク上のpaging 用ファイルのフルパス )

注意: SDS を構成する時、ROOT DB領域は共有のディスク上に置く必要がありますが、SDS_TEMPDBS, SDS_PAGINGは、それぞれのサーバー上のローカルディスク上に置きます。

の各パラメーターを追加します。このファイルを、onconfig.ol_pc2 として、サーバー　pc2上の %INFORMIXDIR%\etc にコピーします。更にPrimaryとSDSそれぞれのインスタンスでINFORMIXSERVER名などが異なりますので、以下のようにそれぞれのファイルを変更してみます。( ここではそれぞれのインスタンスを別マシンで動かすので、SERVERNUM の値は書き換えていません。SERVERNUM の値を primary と SDS で異なる値に設定し、更にSDS_TEMPDBS, SDS_PAGINGも異なる場所に設定すれば、1台のマシン上で HDR のprimaryと SDS を動かすこともできます。)

25,27c25,27
< SDS_ENABLE 0 # to be turned on using onmode -d set SDS..
< SDS_TEMPDBS sdstempdbs,c:\ifmxdata\ol_pc1\sdstempdbs.000,4,0,153600
< SDS_PAGING c:\ifmxdata\ol_pc1\sds_pagefile1,c:\ifmxdata\ol_pc1\sds_pagefile2
---
> SDS_ENABLE 1 # to be turned on using onmode -d set SDS..
> SDS_TEMPDBS sdstempdbs,c:\ifmxdata\ol_pc2\sdstempdbs.000,4,0,153600
> SDS_PAGING c:\ifmxdata\ol_pc2\sds_pagefile1,c:\ifmxdata\ol_pc2\sds_pagefile2
100,101c100,101
< MSGPATH C:\win32app\informix\ol_pc1.log # System message log file path
< CONSOLE C:\win32app\informix\conol_pc1.log # System console message path
---
> MSGPATH C:\win32app\informix\ol_pc2.log # System message log file path
> CONSOLE C:\win32app\informix\conol_pc2.log # System console message path
135c135
< DBSERVERNAME ol_pc1 # Name of default Dynamic Server
---
> DBSERVERNAME ol_pc2 # Name of default Dynamic Server
229,230c229,230
< BAR_ACT_LOG C:\win32app\informix\bar_ol_pc1.log #Path of log file for onbar.exe
< BAR_DEBUG_LOG C:\win32app\informix\bar_ol_pc1.log #Path of the debug log for onbar.exe
---
> BAR_ACT_LOG C:\win32app\informix\bar_ol_pc2.log #Path of log file for onbar.exe
> BAR_DEBUG_LOG C:\win32app\informix\bar_ol_pc2.log #Path of the debug log for onbar.exe
331,332c331,332
< JVPLOGFILE C:\win32app\informix\extend\krakatoa\ol_pc1_jvp.log # VP log file
< JVPPROPFILE C:\win32app\informix\extend\krakatoa\.jvpprops_ol_pc1 # JVP property file
---
> JVPLOGFILE C:\win32app\informix\extend\krakatoa\ol_pc2_jvp.log # VP log file
> JVPPROPFILE C:\win32app\informix\extend\krakatoa\.jvpprops_ol_pc2 # JVP property file

この後、pc1, pc2 上の onconfig ファイルを見比べて、ROOTPATHが同じであること、更に同じ共有ディスク上の場所にセットされていることなどを確認してください。

(5) setnet32を使い、互いの仮想PC上にol_pc1, ol_pc2 の設定を追加する。


2. SDS_ENABLEの初期値

最初のprimary インスタンスを初期化する時には、0 に設定する必要があります。SDS の設定をしない状態で、SDS_ENABLEを 1 にセットしてインスタンスを初期化しようとすると失敗します。

一方、SDS 側では oninit ( starts %INFORMIXSERVER% ) を実行する前に SDS_EABLE　の値を 1 にしておく必要があります。

もし、primary を SDS としても使用するつもりなら、SDS の設定が終わった後、一度 primary のインスタンスを落としてONCONFIG ファイルを修正し、SDS_ENABLEの値を 1 にしておくと良いでしょう。

3. SDS の設定

(1) primary 機 pc1 上での最初の初期化

* ONCONFIG ( onconfig.ol_pc1 ) のパラメーター"SDS_ENABLE がゼロになっていることを確認する
* starts ol_pc1 -iy

(UPDATED 2007-11-26: 初期化に失敗したら、もういちど starts ol_pc1 -iy を実行してください。)

* onmode -d set SDS primary ol_pc1

(2) SDS機 pc2 側での初期化

* ONCONFIG ( onconfig.ol_pc2 ) で"SDS_ENABLE" の設定を1にする。
* starts ol_pc2

以上で、ol_pc1 がprimary、ol_pc2 が SDS の構成でクラスターが動き出す筈です。
(3) primaryと SDS を入れ替える

今SDSとして動いている ol_pc2 を primary に昇格してみましょう。それには SDS 機側で次の操作を実行します。

* onstat -
( この操作は必須ではないですが、現在のモードを確認しておきましょう )
* onmode -d set SDS primary ol_pc2

これで、ol_pc2 が新しい primary になりました。しかし同時に、ol_pc1 がシャットダウンしてしまいましたね。これまでprimaryとして動いていたコンピュータ上でインスタンス ol_pc1を再起動しましょう。

* starts ol_pc1
* onstat -
Read-Only のSDSとして動いていることを確認しておきましょう。

4. 備考：Virtual PC 2007 共有フォルダー上でのチャンク初期化

Virtual PC 2007 が提供する共有フォルダー機能を使って、そこにチャンクを置いて初期化 ( starts %INFORMIXSERVER% -iy ) しようとすると、失敗する場合があります。

14:19:04 IBM Informix Dynamic Server Started.

Mon Aug 20 14:19:04 2007

14:19:04 Warning: ONCONFIG dump directory (DUMPDIR) 'C:\win32app\informix\tmp' has insecure permissions
14:19:05 Booting Language from module
14:19:05 Loading Module
14:19:05 Booting Language from module
14:19:05 Loading Module
14:19:09 DR: DRAUTO is 0 (Off)
14:19:09 DR: ENCRYPT_HDR is 0 (HDR encryption Disabled)
14:19:09 IBM Informix Dynamic Server Version 11.10.TC1 Software Serial Number AAA#B000000
14:19:11 Performance Advisory: The current size of the physical log buffer is smaller than recommended.
14:19:11 Results: Transaction performance might not be optimal.
14:19:11 Action: For better performance, increase the physical log buffer size to 128.
14:19:11 The current size of the logical log buffer is smaller than recommended.
14:19:11 KAIO: error in kaio_READ, kaiocbp = 0xc746810, errno = 0
14:19:11 fildes = 1720 (gfd 3), buf = 0x0C14A000, nbytes = 4096, offset = 61440
14:19:11 Assert Warning: I/O read chunk 1, pagenum 15, pagecnt 1
14:19:11 IBM Informix Dynamic Server Version 11.10.TC1
14:19:11 Who: Session(1, informix@pc1, 0, 00000000)
Thread(6, main_loop(), 0, 1)
File: rsbuff.c Line: 6153
14:19:11 Action: Please notify IBM Informix Technical Support.
14:19:11 stack trace for pid 1168 written to C:\win32app\informix\tmp\af.3ee244f
14:19:16 See Also: C:\win32app\informix\tmp\af.3ee244f
14:19:20 I/O read chunk 1, pagenum 15, pagecnt 1
14:19:22 IBM Informix Dynamic Server Stopped.

エラーを見ると、KAIO が正しく動作していないような内容ですね。UPDATED 2007-11-26: もう一度初期化 ( starts ol_pc1 -ivy ) を実行すると、何故か、以下のとおり正常に初期化します。原因は今のところ不明です。

14:29:19 IBM Informix Dynamic Server Started.

Mon Aug 20 14:29:20 2007

14:29:20 Warning: ONCONFIG dump directory (DUMPDIR) 'C:\win32app\informix\tmp' has insecure permissions
14:29:20 Booting Language from module
14:29:20 Loading Module
14:29:20 Booting Language from module
14:29:20 Loading Module
14:29:24 DR: DRAUTO is 0 (Off)
14:29:24 DR: ENCRYPT_HDR is 0 (HDR encryption Disabled)
14:29:24 IBM Informix Dynamic Server Version 11.10.TC1 Software Serial Number AAA#B000000
14:29:25 Performance Advisory: The current size of the physical log buffer is smaller than recommended.
14:29:25 Results: Transaction performance might not be optimal.
14:29:25 Action: For better performance, increase the physical log buffer size to 128.
14:29:25 The current size of the logical log buffer is smaller than recommended.
14:29:25 IBM Informix Dynamic Server Initialized -- Complete Disk Initialized.
14:29:25 Checkpoint Completed: duration was 0 seconds.
14:29:25 Mon Aug 20 - loguniq 1, logpos 0xd0, timestamp: 0x50 Interval: 2

14:29:25 Maximum server connections 0
14:29:25 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 4, Llog used 1

14:29:25 Dataskip is now OFF for all dbspaces
14:29:25 On-Line Mode
14:29:25 Building 'sysmaster' database ...
14:29:25 Dynamically allocated new virtual shared memory segment (size 8192KB)
14:29:25 Memory sizes:resident:5312 KB, virtual:16384 KB, no SHMTOTAL limit
14:29:25 WARNING! Physical Log size 2000 is too small.
Physical Log overflows may occur during peak activity.
Recommended minimum Physical Log size is 80 times maximum
concurrent user threads.

14:29:34 Btree scanners disabled.
14:29:36 Performance Advisory: Logical log file size might be too small for a
checkpoint to complete.
14:29:36 Results: The size of individual logical log files is too small for
the current workload, resulting in each log file filling very
quickly. If log files fill in less than 30 seconds, the checkpoint
might remain blocked because the last log file fills during the time
needed to perform the checkpoint.
14:29:36 Action: Increase the size of the individual logical log files so
that it takes at least 30 seconds to fill each one. Look at the
online log to determine how quickly the log files are filling, and
then increase the size of the files proportionately.
14:29:36 Logical Log 1 Complete, timestamp: 0xa270.
14:29:36 Logical Log 2 Complete, timestamp: 0xa270.
14:29:36 Logical Log 3 Complete, timestamp: 0xb04b.
14:29:36 Checkpoint Completed: duration was 0 seconds.
14:29:36 Mon Aug 20 - loguniq 4, logpos 0x18, timestamp: 0xb13d Interval: 3

14:29:36 Maximum server connections 1
14:29:36 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 1, Plog used 20, Llog used 1508

14:29:37 Performance Advisory: Based on the current workload, the physical log might be too small to
accommodate the time it takes to flush the buffer pool.
14:29:37 Results: The server might block transactions during checkpoints.
14:29:37 Action: If transactions are blocked during the checkpoint, increase the size of the
physical log to at least 28000 KB.
14:29:37 Performance Advisory: Based on the current workload, the logical log space might be too small to
accommodate the time it takes to flush the buffer pool.
14:29:37 Results: The server might block transactions during checkpoints.
14:29:37 Action: If transactions are blocked during the checkpoint, increase the size of the
logical log space to at least 28000 KB.
14:29:37 Performance Advisory: The physical log is too small for automatic checkpoints.
14:29:37 Results: Automatic checkpoints are disabled.
14:29:37 Action: To enable automatic checkpoints, increase the physical log to at least 28000 KB.
14:29:37 Booting Language from module
14:29:37 Loading Module
14:29:38 Unloading Module
14:29:38 Btree scanners enabled.
14:29:38 Logical Log 4 Complete, timestamp: 0xca69.
14:29:48 Btree scanners disabled.
14:29:49 Logical Log 5 Complete, timestamp: 0x10a47.
14:29:49 Btree scanners enabled.
14:29:58 Loading Module
14:29:59 Performance Advisory: The physical log is running out of room during checkpoint processing.
14:29:59 Results: Transactions are being blocked until the checkpoint is complete.
14:29:59 Action: Increase the physical log size.
14:29:59 Checkpoint Completed: duration was 0 seconds.
14:29:59 Mon Aug 20 - loguniq 6, logpos 0xc776c, timestamp: 0x11796 Interval: 4

14:29:59 Maximum server connections 1
14:29:59 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 285, Llog used 1199

14:29:59 Unloading Module
14:30:00 Logical Log 6 Complete, timestamp: 0x14ea7.
14:30:00 'sysmaster' database built successfully.
14:30:01 'sysutils' database built successfully.
14:30:01 'sysuser' database built successfully.
14:30:06 Btree scanners disabled.
14:30:07 Btree scanners enabled.
14:30:08 Init operation complete - Mode Online Initialized
14:30:10 Building 'sysadmin' database ...
14:30:10 dynamically allocated 2000 locks
14:30:10 Logical Log 7 Complete, timestamp: 0x194f9.
14:30:10 Checkpoint Completed: duration was 0 seconds.
14:30:10 Mon Aug 20 - loguniq 8, logpos 0xb0104, timestamp: 0x19569 Interval: 5

14:30:10 Maximum server connections 1
14:30:10 Checkpoint Statistics - Avg. Txn Block Time 0.007, # Txns blocked 0, Plog used 230, Llog used 977

14:30:11 Loading Module
14:30:11 'sysadmin' database built successfully.
14:30:11 SCHAPI: Started dbScheduler thread.
14:30:11 SCHAPI: Started 2 dbWorker threads.
14:30:12 Logical Log 8 Complete, timestamp: 0x1d2ec.
14:30:12 Logical Log 9 Complete, timestamp: 0x1d2ec.

この件、調べていたら、次のようになりました。

copy zerobytefile rootdbs_dat.000
oninit -ivy ( または starts ol_testpc1 -iy ) --> 失敗 (1)
もういちどoninit -ivy ( または starts ol_testpc1 -iy ) --> 成功 (2)
onmode -ky
oninit -ivy ( または starts ol_testpc1 -iy ) --> 成功 (3)
onmode -ky
oninit -ivy ( または starts ol_testpc1 -iy ) --> 成功 (4)

最初に、長さゼロバイトのチャンクを初期化してサイズをROOTSIZEに拡張する処理中に問題が発生していたようです。ただ、初期化に失敗しても、チャンクに割り当てたファイルのサイズは ROOTSIZE になっています。その後はチャンクの(再)初期化は成功します。上記「成功 (4)」がそれですね。存在しない場所に fseek しようとした時の処理などでローカルのファイルシステムと違いがあるのかも知れません。