Microsoft PowerPoint - 【3.TSA & UDB + HADR編】 Linux on zSeries 環境における DB2 クラスター機能検証報告書.ppt

Size: px

Start display at page:

Download "Microsoft PowerPoint - 【3.TSA & UDB + HADR編】 Linux on zSeries 環境における DB2 クラスター機能検証報告書.ppt"

せいごろうはなだて
4 years ago
Views:

1 Linux on zseries 環境における DB2 クラスター機能検証報告書 3. TSA & UDB + HADR 連携構成編日本アイビーエムシステムズエンジニアリング株式会社

2 お断り本資料の作成において記載した内容に関しては正式な IBM のテストを受けていませんこちらの情報を参考とした作業に実施に関しては使用者の責任において行われるべきものでありそれらの評価に関しては使用者の判断に依存しています本資料で報告されたパフォーマンスデータ等に関してはある特定の状態において正確である情報であり他環境にて同様の結果が得られる保証はありません当ドキュメントは参考資料として利用し運用を計画実施される場合には必ず製品のマニュアルをご覧になってくださいまた本番使用に際しましては充分な動作テストを行っていただくようお願いいたします資料の内容には正確を期するよう注意しておりますがこの資料の内容は 2004 年 12 月現在の情報であり製品の新しいリリース PTF などによって動作仕様が変わる可能性があるのでご注意下さい 2

3 目次検証概要と検証結果サマリー検証対象システム検証項目と検証結果 3

4 検証概要と検証結果サマリー 4

5 検証対象クラスターデザイン概要 (1) シナリオ 2.TSA + DB2 HADR 連携クラスター HADR Primary Node に Primary instance を HADR Stand-by Node に Standby instance をそれぞれ用意する両ノードにて db2 process を稼動させ HADR Pair を構成する各インスタンスにおいて以下を管理する資源を適用するがディスクや HA IP Address の他ノードへの引継ぎは行わないサービス側ネットワークインターフェースの稼動状態共用ディスクのマウント状態 db2 プロセス (db2sysc) の稼動状態 HADR を管理する資源を定義するこれは以下のポリシーをもつ常に片ノードが HADR Primary instance, 片ノードが HADR Stand-by instance である状態を保つアクティブノードに障害を検知した場合アクティブノードのサービスを停止しスタンバイノード側にてログを回収後これをアクティブノードとして活性化する HADR の Split-Brain 状態 ( 両ノードとも HADR Primary となる状態 ) を検知した場合は片ノードのdb2 プロセスを停止する DB2 Client の Automatic Client Reroute 機能を用いることでクライアントからは透過的に常にアクティブノードとアクセスできる仕組みが提供される本検証においてはログの転送用ネットワークとして Guest LAN を利用する 5

6 検証対象クラスターデザイン概要 (2) TSA + DB2 HADR 連携クラスター概念図通常時障害発生時 db2 instance (primary) log db2 instance (standby) db2 instance (primary) db2 processes Active IP address Automatic Client Rerouting db2 processes Stand-by IP address db2 client Automatic Client Rerouting db2 processes Active IP address db2 client 6

7 検証結果サマリー本検証結果をサマライズすると以下のようになる ( 詳細については検証項目と検証結果詳細項を参照のこと ) Linux on zseries (Under z/vm) 環境における TSA の導入構成に関して問題は発見されなかった DB2 UDB V8.2 に同梱される TSA 用サンプルポリシーを利用し DB2 UDB + HADR 連携クラスターが適正に構築可能であることを確認した上記構成の元ディスク障害を除く各種障害に対して適正に自動検知を行い HADR Active ノードを takeover する等してサービスを継続する事を確認したこれらの構成に関して問題は発見されなかったサンプルポリシーで提供されるスクリプトを利用した場合ディスク障害に対して検知不可能であることが発見された各環境に併せてディスク障害を検知する仕組みを別途導入する必要がある理由については別項の参考資料を参照のこと 7

8 検証対象システム 8

9 検証対象システム (1) Linux on zseries 稼働環境構成 IBM eserver z900 ( ) z/vm V4R4 (Service level 0301) 64bit mode Linux 構成 SUSE Linux Enterprise Server 8.0 ServicePack 3 (31bit) kernel gcc version ディスク構成型 DASD (ESS) FICON 接続ネットワーク構成 OSA-Express 両ノード間で同一 OSA ポートをシェア Guest LAN HiperSockets Emulation Mode を採用 9

10 検証対象システム (2) データベースソフトウェア DB2 Universal Database Enterprise Server Edition V8.2 クラスターソフトウェア Tivoli System Automation for Multiplatform V1.2 FixPack2 10

検証対象システム (3) 検証システム構成図 ( ネットワーク ) z/vm Guest LAN 10.

11 検証対象システム (3) 検証システム構成図 ( ネットワーク ) z/vm Guest LAN / hsi0 hsi0 hostname : zlinux1 VM USER NAME : LXUSER1 eth0 Cluster eth0 hostname : zlinux2 VM USER NAME : LXUSER OSA 各 Linux は Guest LAN, OSA 双方とのインターフェイスを持つ / network 診断用 Server

MByte 各仮想計算機に 768MByte 定義その他 LPAR 検証テスト用 LPAR z/vm V4.

12 検証対象システム (4) 検証システム構成図 ( リソース ) zlinux1 zlinux2 CPU z900 General CPU ( 非 IFL) 検証用 LPAR にて 1CP 占有所有各仮想計算機にて論理 1CP ずつ定義 Memory 検証用 LPAR にて 2048MByte アサイン Central Storage (CS) として 1408 MByte Extended Storage (ES) として 640 MByte 各仮想計算機に 768MByte 定義その他 LPAR 検証テスト用 LPAR z/vm V M LXUSER1 768M virtual storage virtual CP storage paging space LXUSER2 768M virtual storage 640M virtual CP CP 1408M CS 640M ES dedicated CP z900 ( ) 12

13 検証対象システム (5) 検証システム構成図 ( ストレージ構成とデータベース構成 ) シナリオ 2.TSA + DB2 HADR 連携クラスター { ストレージ配置 } primary インスタンス配置用 stand-by インスタンス配置用スペースとしてそれぞれ 12G の LV を構成ファイルシステムとして全パーティションに ext3 を採用 { データベース内容 } OLTP ベンチマークツールを用いて primary 側へ 5GByte のテーブルスペースを作成 DB,DBM のパラメータとして以下を採用 DBHEAP = 1200 LOGBUFSZ = 16 BUFFPAGE = HADR のパラメータとして以下を採用 SOFTMAX=10 SYNCMODE=SYNC HADR ペア間の通信は GuestLAN を指定プライマリ側に 5 GByte データの更新処理を行った状態で各種障害検証を行う 13

14 検証対象システム (6) 検証システム構成図 ( ストレージ構成とデータベース構成 ) シナリオ 2.TSA + DB2 HADR 連携クラスター zlinux1 dasdb1 dasdb1 zlinux2 dasda2 opt opt db2 db2 db2 db2 opt opt dasda2 etc / etc / root root tmp tmp mnt mnt misc misc homep homep instance for primary node LV (12G) /dev/vg1/lv0 db2instp instance for standby node /dev/vg2/lv0 LV (12G) db2insts homes homes etc etc root root tmp tmp mnt mnt misc misc // db2fenc db2fenc TieBreaker 14 dasdc

15 検証対象システム (7) 検証システム構成 (TSA ポリシー定義 ) DB2 UDB V8.2 に同梱されるサンプルポリシーを利用 /opt/ibm/db2/v8.1/ha/salinux/ に配置される以下の資源が作成される db2 プロセス管理用資源 ( プライマリdb 用スタンバイdb 用 ) 共用ディスク管理用資源 ( プライマリdb 用スタンバイdb 用 ) サービスIPアドレス監視用資源 ( プライマリdb 用スタンバイdb 用 ) HADR 管理用資源動作の詳細については参考 2 : TSA & DB2 HADR 連携クラスターの動きを参照のこと 15

16 検証項目と検証結果 16

17 検証項目 Primary Node に関して番号資源と障害内容想定される原因影響を受ける資源検証方法 8 DB2 プロセス障害 DB2 プロセスダウン DB2 アプリケーション資源 db2sysc の停止 9 ディスクのマウント障害 H/W 障害マウント資源 z/vm から DASD のデタッチ 10 OSA 障害 H/W 障害 IP 資源インターフェースダウン 11 Linux 停止 S/W 障害 Linux ノード shutdown -h now 12 Linux ハングアップリソース不足カーネルパニック Linux ノード z/vm から #CPU ALL STOP 13 z/vm 仮想計算機停止 z/vm 障害リソース不足 Linux ノード z/vm 仮想計算機からのログオフ 17

18 検証結果 Primary node に関して番号資源と障害内容検証方法リカバリー結果 8 DB2 プロセス障害 db2sysc の停止 ( 自ノードより Primary Node として復帰 ) 9 ディスクのマウント障害 z/vm から DASD のデタッチ ( 障害を検知できない ) 10 OSA 障害インターフェースダウン ( テイクオーバー発生, スタンバイノードがプライマリ hadr として稼動 ) 11 Linux 停止 shutdown -h now ( テイクオーバー発生スタンバイノードがプライマリ hadr として稼動 ) 12 Linux ハングアップ z/vm から #CPU ALL STOP ( テイクオーバー発生スタンバイノードがプライマリ hadr として稼動 ) 13 z/vm 仮想計算機停止 z/vm 仮想計算機からのログオフ ( テイクオーバー発生スタンバイノードがプライマリ hadr として稼動 ) 18

Microsoft PowerPoint - 【2.TSA & UDB編】Linux on zSeries 環境における DB2 クラスター機能検証報告書.ppt

Microsoft PowerPoint - 【2.TSA & UDB編】Linux on zSeries 環境における DB2 クラスター機能検証報告書.ppt Linux on zseries 環境における DB2 クラスター機能検証報告書 2. TSA & UDB 連携構成編日本アイビーエムシステムズエンジニアリング株式会社お断り本資料の作成において記載した内容に関しては正式な IBM のテストを受けていませんこちらの情報を参考とした作業に実施に関しては使用者の責任において行われるべきものでありそれらの評価に関しては使用者の判断に依存しています