Comments
Description
Transcript
DB2 pureScale の の高可用性 高可用性
DB2 pureScale の高可用性 © 2011 IBM Corporation アーキテクチャー Agenda DB2 pureScaleの の可用性 障害ケース 障害ケースと ケースとリカバリー・ リカバリー・アクション – ノード障害 – CF障害 負荷分散と 負荷分散とクライアント・ クライアント・リルート log buffer, dbheap, & other heaps DB2 pureScaleと と他社クラスタ 他社クラスタの クラスタの違い 2 © 2011 IBM Corporation DB2 pureScaleの の可用性 DB2 pureScale可用性 可用性の 可用性のデザイン – 高速な障害検知とリカバリー自動化 – 全体リカバリー処理の高速化 – 障害発生からリカバリー完了までの間 のサービス影響を極小化 DB2 Log メンバー・ノードに障害が発生した際、リカバ リーが完了するまで、障害ノードの更新中 (インフライト)のデータだけをロックする – 上記以外のデータは全面的にアクセス が可能 – 障害ノード以外は通常通り稼動 障害が発生したノードで実行中のトランザク ションも自動的に正常なノードに割り振られ る。 統合的な障害検知と回復処理の自動化によ り、サービスの可用性を最大化 CF Log DB2 Log 共有データ 利用できるデータの割合(%) DB2 DB2 Log CF データベースノードの データベースノードの障害 回復中には 回復中にはインフライトデータ にはインフライトデータのみを インフライトデータのみを ロック 100 50 Time (~seconds) 3 © 2011 IBM Corporation DB2 Cluster Services による自動障害対応 による自動障害対応 DB2 コンポーネントとして統合 – TSA (Tivoli System Automation)による障害検知、自動対応 DB2 インストールの一環としてインストールされる – DB2 Fix Pack の適用によってアップデート DB2 CS Event Notification & Handling DB2 DB2 DB2 CFp CFs DB2 DB2 Cluster Services – Cluster Manager DB2 Cluster Services - Cluster File System 4 © 2011 IBM Corporation 障害ケースとリカバリー・アクション 5 © 2011 IBM Corporation 障害ケース 障害ケースと ケースとリカバリー・ リカバリー・アクション 障害ケース DB2 Member プロセス障害 リカバリー・アクション 可用性レベル 自ノードでプロセスをリス タート（クラッシュ・リカバ リー） 障害発生メンバーによって更新中に保持さ れたデータがロックされる。（その他のデータ はすべてアクセス可能） DB2 Member ノード障害 他ノードでクラッシュリカ バリーを代行 プライマリ CF 障害 セカンダリCFがプライマリ CFに切り替わる 障害メンバーへの接続は自動的に他のメン バーにリルート（再接続される） アプリケーションからは透過的 瞬間的にCFへの要求がWAIT セカンダリ CF 障害 セカンダリーへの二重化 を停止 アプリケーションからは透過的 瞬間的にCFへの要求がWAIT 6 © 2011 IBM Corporation メンバー障害 7 © 2011 IBM Corporation メンバープロセス障害 メンバープロセス障害 : 自ノード上 ノード上で回復処理 ‘kill -9’を を誤ってメンバー ってメンバーに メンバーに発行 DB2クラスター クラスター・ クラスター・サービスは サービスは、メンバーがいなくなったことを メンバーがいなくなったことを検 がいなくなったことを検 知、自動的に 自動的に回復アクション 回復アクションを アクションを実施 – – – 他のメンバー、CFサーバーに伝える Single Database View もともと稼動していたホストでメンバーの再起動と回復処理を開始 メンバーのリスタートはクラッシュリカバリーのような処理になるが より高速 • • Clients インフライトのトランザクションのみをRedo CFのメモリー上にキャッシュされたページを活用 kill -9 この間 この間、クライアント接続 クライアント接続は 接続は透過的に 透過的に正常な 正常なメンバーへ メンバーへリルー トされる DB2 CS 他のメンバーは メンバーはオンラインリカバリー中 オンラインリカバリー中も完全に 完全に利用可能 – “Online Failover” – 他メンバーは障害メンバーによる更新アクセスのためにロックさ れたデータ以外に参照・更新を継続することが可能。 8 Log Log Secondary CF Pages Log CF CS CF CS メンバー回復処理 メンバー回復処理が 回復処理が終了 – DB2 CS Log Records Updated Pages Global Locks DB2 CS プライマリCFは障害発生時にメンバーが持っていた更新ロックを 保持（リテインド・ロック） Log – DB2 CS Shared Data Updated Pages Global Locks Primary CF リテインド・ロックが解放されすべてのデータがアクセス可能 © 2011 IBM Corporation メンバーの 障害 : 他ノードで light) メンバーのHW障害 ノードでメンバー回復処理 メンバー回復処理(Restart 回復処理 アクシデントで アクシデントで電源コード 電源コードが コードが抜けた Clients クラスター・ クラスター・サービスの サービスのハートビートが ハートビートが途絶え 途絶え、メン バー・ バー・ノードが ノードがダウンしたことを ダウンしたことを検知 したことを検知 – – – 他のメンバー、CFに通知 障害メンバーをログとデータから”Fence”する 自動的にメンバーのリスタートを他のノードで実行（Restart Light) • – 回復専用プロセスとして事前に割り当てられたメモリーを使用 メンバーのリスタートはクラッシュリカバリーのような処理にな るがより高速 • • Single Database View インフライトのトランザクションのみをRedo CFのメモリー上にキャッシュされたページを活用 この間 この間、クライアント接続 クライアント接続は 接続は透過的に 透過的に正常な 正常なメンバーへ メンバーへ リルートされる リルートされる DB2 CS DB2 CS DB2 CS Fe nc e 他のメンバーは メンバーはオンラインリカバリー中 オンラインリカバリー中も完全に 完全に利用 可能 – “Online Failover” Log 9 リテインド・ロックが解放されすべてのデータがアクセス可能 Log Log Pa CS Updated Pages Global Locks メンバー回復処理 メンバー回復処理が 回復処理が終了 – Log s ec R – プライマリCFは障害発生時にメンバーが持っていた更新ロッ クを保持（リテインド・ロック） 他メンバーは障害メンバーによる更新アクセスのためにロック されたデータ以外に参照・更新を継続することが可能。 DB2 g Lo – DB2 CS Secondary Shared Data ge s CS Updated Pages Global Locks Primary © 2011 IBM Corporation 補足： 補足： 障害検知 DB2自体 自体が プロセスの 自体がwatchdog プロセスによって プロセスによってDB2プロセス によって プロセスの障害検知を 障害検知を行う – DB2メンバー（プロセス）に障害が発生するとwatchdogに通知される。 – Watchdogプロセスがクラスターマネージャに リカバリーを開始するよう 割り込み要求を行う。 – 障害検知時間はほんの数秒 スプリット･ スプリット･ブレインから ブレインからデータ からデータを データを守る – SCSI-3 Persistent Reserve によるI/O Fencing • – スプリット･ブレインを防ぐために強制停止する仕組み（STONITH). DB2 クラスター・ クラスター・マネージャは マネージャはロー･ ロー･レベルで レベルで実行される 実行される – 10 クラスターから切り離されたノードから共有データ、ログへのI/Oをフェンスする。 迅速に障害を検知、少ないシステムリソース利用 © 2011 IBM Corporation メンバーの メンバーの復旧 電源が 電源が入り、システムが システムがリブート DB2クラスター クラスター・ クラスター・サービスにより サービスによりノード によりノードが ノードが利用可 能な状態であることを 状態であることを自動的 であることを自動的に 自動的に検知 – 他のメンバーやCFサーバーに伝える – I/Oのブロックを解放する – 元のホストでメンバーが起動する Clients Single Database View クライアントは クライアントは使用可能となった 使用可能となったメンバー となったメンバーに メンバーに自動 的に接続される 接続される DB2 CS DB2 CS DB2 CS DB2 CS DB2 Log Log Log CS CS Updated Pages Global Locks Secondary 11 Log Shared Data Updated Pages Global Locks Primary © 2011 IBM Corporation 補足： とは・・・ 補足： Restart “Light”とは とは・・・ プロセス再起動 プロセス再起動が 再起動が失敗する 失敗する場合 する場合、 場合、サーバー障害 サーバー障害の 障害の場合 – 他のホスト上でリカバリーを実施 – リカバリー専用のプロセスが障害メンバーのログを利用してリカバリーを実施（restart light） – メンバー起動時に”skelton” プロセスが事前に起動 – リカバリー実施に必要な最小限のリソースを事前に割り当てる。 • RSTRT_LIGHT_MEM 構成パラメータで制御 Restart Light が完了後も 完了後も、guest member は存在し 存在し続けるが、 けるが、接続を 接続を受け付けることはない。 けることはない。 – もともと起動していたサーバーが回復し、そのサーバー（home host)上でプロセス起動が完了す ると、通常通り接続を受け入れることができる。 ■ インスタンス・プロセスと、Restart light 用のSkeltonプロセス 12 db2sdin1 573634 737426 117 16:07:11 - 13:25 db2sysc 0 db2sdin1 696440 827622 0 16:06:26 - 0:00 db2sysc (idle) db2sdin1 721040 647252 0 16:06:26 - 0:00 db2sysc (idle) db2sdin1 839834 454862 0 16:06:27 - 0:00 db2sysc (idle) © 2011 IBM Corporation 参考： トランザクションの 参考： アプリケーションへの アプリケーションへの影響 への影響 (トランザクション トランザクションの挙動) 挙動 ① 障害メンバー 障害メンバーで メンバーでトランザクション実行途中 トランザクション実行途中の 実行途中の場合： 場合： • エラー検知後、正常なメンバーに再接続し、アプリケーションにエラーを通知する。 • 実行中のトランザクションがサーバー側でRollbackされたことをアプリに伝達するた め。 ② 障害メンバー 障害メンバーに して新規の トランザクションを開始する 開始する場合 メンバーに対して新規 新規のトランザクションを する場合 • エラー検知後、正常なメンバーに再接続し、SQLを再実行する。 • アプリケーションにはメンバー障害が発生したことは通知されない。 ※ ワークロード･バランス(データソースプロパティ：sysplesEnableWLB)利用を前提とする。 ①障害メンバー 障害メンバーで メンバーでトランザクション実行中 トランザクション実行中 1. トランザクション実行中 トランザクション実行中 クライアント Member #1 1. トランザクション開始 トランザクション開始 db2sysc 0 CS 2. エラー検知 エラー検知 3. 再接続を 再接続をtry ②障害メンバー 障害メンバーに メンバーに対して新規 して新規の 新規のトランザク ションを ションを開始 クライアント db2sysc 1 4. 再接続の 再接続の完了と 完了とトランザク ションの のRollbackを通知 ション （SQLCODE=-4498/-30108） 13 db2sysc 0 CS 2. エラー検知 エラー検知 3. 再接続を 再接続をtry Member #2 Member #1 Member #2 db2sysc 1 CS 4. 再接続完了後、 再接続完了後、失敗した 失敗したSQL を再実行して 再実行して結果 して結果を 結果を返却 CS トランザクションの最初のSQLステートメントについても再実行される（データ ソース設定：enableSeamlesFailover） © 2011 IBM Corporation 参考： テスト結果 参考： アプリケーションへの アプリケーションへの影響 への影響 (テスト テスト結果) 結果 Member #1 1. トランザクション実行中 トランザクション実行中 db2sysc 0 CS 2. エラー検知 エラー検知 クライアント 3. 再接続を 再接続をtry プロセス障害時のアプリケーションの動き（２メンバー構成） Member0 のプロセス障害を発生させる。 Member0は自動的に再起動が行われる。 Member #2 db2sysc 1 4. 再接続の 再接続の完了と 完了とトランザク ションの のRollbackを通知 ション （SQLCODE=-4498/-30108） CS Java program received SQL exception com.ibm.db2.jcc.am.ClientRerouteException: [jcc][t4][2027][11212][3.58.82] 接続は失敗しましたが、再 確立されました。 ホスト名または IP アドレスは "pvc92" で、サービス名またはポート番号は 50,001 です。 特殊レジスターのやり直しは可能なことも不可能なこともあります (理由コード = 1)。 ERRORCODE=-30108, SQLSTATE=08506 <以下省略> member0をkillした スループットの遷移 TPSの推移 6000 5000 4000 3000 2000 1000 0 17:32:41 14 17:32:58 17:33:16 17:33:33 17:33:50 17:34:07 17:34:25 ※ テストケースはRead１００％の結果 © 2011 IBM Corporation CF障害 15 © 2011 IBM Corporation プライマリCF障害 プライマリ 障害 アクシデントで アクシデントで電源コード 電源コードがぬけた コードがぬけた Clients DB2クラスター クラスター・ クラスター・サービスの サービスのハートビート が途絶えたことにより 途絶えたことにより、 えたことにより、プライマリーの プライマリーのダ ウンを ウンを検知 Single Database View – メンバーとセカンダリーに通知 – CFサービスは瞬間的にブロックされる – 以下のDBアクティビティは可能 • Eg. バッファープール内のページアクセス, 既に 取得済みロック, ソート処理, 集約, etc DB2 CS セカンダリーは セカンダリーは、プライマリーデータとの プライマリーデータとの 誤差分を 誤差分をメンバーから メンバーから取得 から取得 DB2 CS DB2 CS DB2 CS – Eg.読み取り専用ロック セカンダリーが セカンダリーがプライマリーになる プライマリーになる – CF サービスを中断したところから継続す る – アプリケーションにはエラーは返らない 16 Log Log Log CS CS Updated Pages Global Locks Secondary Primary Log Shared Data Updated Pages Global Locks Primary © 2011 IBM Corporation プライマリCFの プライマリ の復旧 電源が 電源が入り、システムが システムがリブート DB2クラスター クラスター・ クラスター・サービスが サービスがシステムが システムが使 えることを自動検知 えることを自動検知 Clients – 他のメンバーやプライマリーに伝える Single Database View 新しいシステム しいシステムは キャッチアップ’状態 システムは‘キャッチアップ キャッチアップ 状態の 状態の セカンダリーとなる セカンダリーとなる – メンバーはCF2重化を再開する – メンバーは、ロックやその他の情報をセカ ンダリーに非同期に送る DB2 CS キャッチアップが キャッチアップが完了 DB2 CS DB2 CS DB2 CS – セカンダリーがピアー状態になる (プライ マリーと同じロックやページ状態をもって いる。) Log Log Log CS CS Updated Pages Global Locks Primary Log Shared Data Updated Pages Global Locks Secondary (Catchup (Peer state) state) 17 © 2011 IBM Corporation 参考： テスト結果 参考：プライマリCFの プライマリ のプロセス障害 プロセス障害 (テスト テスト結果) 結果 CF(primary)プロセスがkillされると、secondaryがprimaryとして稼動するようになった。db2instance -listの出力は以 下の通り。 Mon Dec 14 14:33:01 JST 2009 ID TYPE ----128 CF 129 CF Mon Dec 14 14:33:04 JST 2009 ID TYPE ----128 CF 129 CF STATE ----PRIMARY PEER STATE ----RESTARTING PRIMARY 18 HOME_HOST --------pvc61 pvc62 CURRENT_HOST -----------pvc61 pvc62 リスタートが終わると「CATCHUP」ステータスになる STATE ----CATCHUP PRIMARY <省略> Mon Dec 14 14:34:02 JST 2009 ID TYPE ----128 CF 129 CF CURRENT_HOST -----------pvc61 pvc62 セカンダリCFサーバーが「primary」に切り替わる <省略> Mon Dec 14 14:33:29 JST 2009 ID TYPE ----128 CF 129 CF HOME_HOST --------pvc61 pvc62 HOME_HOST --------pvc61 pvc62 CURRENT_HOST -----------pvc61 pvc62 最後は「PEER」ステータスになる STATE ----PEER PRIMARY HOME_HOST --------pvc61 pvc62 CURRENT_HOST -----------pvc61 pvc62 © 2011 IBM Corporation CF 障害 （詳細） 詳細） CF二重化構成では、プライマリCF障害が発生しても、クラスター障害にはならない。セカンダリCF がプライマリーの役割を引き継ぐ（TSA クラスターマネージャによって自動化） セカンダリCFがプライマリへと切り替わる前に「リビルド」処理が必要。すべてのCF構造を2重化し ているわけではないため リビルドとは？ – 読み取りロック情報の再構築 プライマリCF障害からの復旧で実施されるステップ(DB2クラスター・サービスによって自動化） 1. 障害検知 2. 「Departure notifications」がDB2メンバーに対して送られ、プライマリCFが使用不可能であることを 通知する。障害発生CFに対する通信を停止する。 3. セカンダリCFの再構築 プライマリ・ロール引継ぎの準備をする。 4. プライマリ CF の 「arrival notifications 」を DB2 メンバーに送り、新しいCFが利用可能になったこと を通知する。 19 セカンダリCF障害はほとんど影響を与えないが、CF片系で稼動している間にプライマリ障害が発 生すると、「グループ・リスタート」が必要となる。 © 2011 IBM Corporation グループ・ グループ・リスタート (Group Crash Recovery: GCR) Clients DB2 CF DB2 DB2 DB2 CF Single Database View プライマリ、セカンダリ CFが同時に落ちた場 合 – – セカンダリがＰＥＥＲ状態でない時にプライマリ がおちるケースでも同様 直近の整合性の取れたページのコピーが存 在しないため、リカバリーが必要 DB2 CS – DB2 Cluster Services がＧＣＲを担当メ ンバーを選出する – – 20 Log Records GCR は シングルＤＢでのクラッシュリ･リカ バリーに相当 – Log CS ディスクに書かれていない更新のRedoと Undoを実施 それぞれのメンバーのログをマージしてリプレ イ。（最初に起動したメンバーで実施） 完了するまでアクセス不可 DB2 CS Updated Pages Global Locks Secondary Log Records Log DB2 CS Log Records Log Pages DB2 CS Log Records Log CS Shared Data Updated Pages Global Locks Primary © 2011 IBM Corporation サマリー (単一障害 単一障害) 単一障害 障害モード 障害モード DB2 他のメンバーは メンバーは 稼動し 稼動し続けるか DB2 DB2 DB2 Member CF Primary PowerHA pureScale 接続は透過的に他メンバーに引 き継がれる。 CF DB2 DB2 DB2 アプリケーション から透過的 から透過的か 透過的か 障害メンバー上でしかかり中で あったトランザクションは別 のメンバーへと再接続 障害メンバー上でインフライトで あったデータのみ一時的に ロックが残るがそれ以外の データは生存メンバーから アクセス可能 瞬間的に CFへの要求はWAIT メンバーからは透過的。 (インフライトのCFへの要求は 通常より数秒完了に時 間がかかる。) DB2 CF コメント CF Primary Secondary PowerHA pureScale DB2 CF DB2 DB2 瞬間的に CFへの要求はWAIT メンバーからは透過的 (インフライトのCFへの要求は 通常より数秒完了に時 間がかかる。) DB2 CF Secondary 21 © 2011 IBM Corporation サマリー (重複障害 重複障害) 重複障害 障害モード 障害モード DB2 DB2 DB2 他のメンバーは メンバーは 稼動し 稼動し続けるか 接続は透過的に他メンバーに引 き継がれる。 CF DB2 DB2 CF Primary CF Secondary 22 DB2 DB2 障害メンバー上でインフライトで あったデータのみ一時的に ロックが残る。 リカバリーは並行実施 メンバー障害と同一 DB2 CF DB2 コメント DB2 CF DB2 アプリケーション から透過的 から透過的か 透過的か 接続は透過的に他メンバーに引 き継がれる。 瞬間的に PowerHA CFへの要求はWAIT メンバー障害と同一 DB2 CF 接続は透過的に他メンバーに引 き継がれる。 瞬間的に PowerHA CFへの要求はWAIT © 2011 IBM Corporation 負荷分散とクライアント･リルート 23 © 2011 IBM Corporation Automatic Workload Balancing & Client Routing 実行中の 実行中の負荷情報を 負荷情報を利用して 利用して自動的 して自動的に 自動的にクラスター内 クラスター内で負荷分散 (System z sysplex 同様) 同様 – – – 障害時 – 全メンバーの負荷情報はそれぞれのメンバーが持つ 最も負荷の少ないメンバーに接続を割り振る アプリケーションからは透過的に接続割り振りが行われる 障害発生メンバーの負荷は利用可能なメンバーへと均等に割り振られる 回復時 – 障害メンバーが回復すると、負荷分散を図りながら割り振りを再開する Clients 24 Clients © 2011 IBM Corporation 参考： 参考： serverlist クライアントがどのメンバーに接続可能かのリストを、サーバーが持っている。 確認するには、db2pd –db DB名 –serverlist（db2 –serverlist –alldbsも可）コマンドを使用する。 $ db2pd –db SMAPLE -serverlist Database Member 0 -- Active -- Up 0 days 00:19:31 Server List: Time: Wed Dec 16 10:48:28 Database Name: SAMPLE Count: 2 Hostname pvc91 pvc92 Port 50001 50001 Priority 70 29 例えばpvc91がプロセス障害などでダウンしている際には以下のような出力になる。 $ db2pd –db SMAPLE -serverlist Database Member 1 -- Active -- Up 0 days 00:19:46 Server List: Time: Thu Dec 10 11:56:07 Database Name: SAMPLE Count: 1 Hostname pvc92 25 Port 50001 Priority 100 © 2011 IBM Corporation DB2 pureScaleと他社クラスタとの違い 26 © 2011 IBM Corporation DB2 pureScaleと と他社クラスタ 他社クラスタの クラスタの違い DB2 pureScale CF DB2 DB2 他社クラスタ 他社DB DB2 更新データ 更新データ ロック 他社DB 他社DB 他社DB 更新データ 更新データ データ 更新データ 更新データ 更新 更新データ 更新データ 更新データ ロック ロック ロック ロック RDMA通信 通信 TCPIP通信 通信 データベース 構成特徴 ロック情報と更新データをCFで一元管理する ノード間通信にRDMAを採用(約10マイクロ秒) ①スケーラビリティ ○ 27 ロック情報と更新データを各ノードで ノードで分散管理する ノード間通信にUDP/ソケットプロトコルを採用 △ ノード間通信量、ロック管理負荷が小さい ノード間通信量、ロック管理負荷が大きい ノード間通信が高速 (RDMAにより他ノードのメモリに直接書 ノード間通信が低速 (UDPおよびRDS(ソケットプロトコル)によ き込みができる) る通信) ②アプリケーションのメンテナンス負 ○ 荷 ノード追加時にアプリケーションの変更は必要なし ③可用性 データベース ○ △ ノード追加時にアプリケーションのパーティショニングの変更が 必要 △ 全面停止時間がない。(障害ノードによる更新データ以外はア 全面停止時間がある。(全ノードのロック再構成と更新データ・ クセス可能) リカバリー処理のため) 全体の復旧時間が高速 全体の復旧に時間がかかる © 2011 IBM Corporation DB2 pureScaleと と他社クラスタ 他社クラスタの クラスタのリカバリー処理 リカバリー処理の 処理の違い DB2 pureScale の設計の要は、障害が発生した際 リカバリー処理中の可用性を最大化し、かつリカバリー処理を高速化することである CF DB2 DB2 DB2 更新データ 更新データ ロック 他社DB 他社DB 他社DB 他社DB 更新データ 更新データ データ 更新データ 更新データ 更新 更新データ 更新データ 更新データ ロック ロック ロック ロック RDMA通信 通信 TCPIP通信 通信 利用できるデータの割合(%) データベース 28 データベース データベースノードの障害 DB2は回復中には障害ノードが更新中 だった一部のデータのみをロック 他社DB DB2 pureScale 他社DBは全ノードの整合性確認のためIOを フリーズし部分停止、あるいは全体停止 Time (~seconds) © 2011 IBM Corporation 他社クラスタ 他社クラスタ なぜ全面停止 なぜ全面停止になる 全面停止になる？ になる？ 障害ノードが保持していたロック情報を再配分している間、 すべてのロック要求とI/O処理が抑止される Global Resource Directory (GRD) Redistribution インスタンス1が インスタンス がクラッシュ Instance 1 GRD Instance 2 GRD Instance 3 GRD リカバリーの リカバリーの必要な 必要な ブロックが ブロックがロックされ ロックされ るまですべてのI/O るまですべての 要求と 要求とロックが ロックが抑止 される すべてのI/O要求 すべての 要求が 要求が抑止される 抑止される 29 © 2011 IBM Corporation 他社クラスタ 他社クラスタ なぜ全面停止 なぜ全面停止になる 全面停止になる？ になる？ リカバリーブロックが リカバリーブロックが他ノードからわからないため ノードからわからないためログ からわからないためログから ログから探索 から探索。 探索。 その間 処理が その間もすべてのロック もすべてのロック要求 ロック要求と 要求とI/O処理 処理が抑止される 抑止される redo log redo log redo log リカバリーインスタンスが 障害ノードのログを読む インスタンス1が インスタンス がクラッシュ Instance 1 Instance 2 GRD GRD Instance 3 GRD I/Oが が解放される 解放される前 される前に ログと ログとリカバリーブロックを リカバリーブロックを 読まなければならない すべてのI/O要求 すべての 要求が 要求が抑止される 抑止される x x x x x x リカバリーインスタンスがリカバリーの必要な全ブロックをロック 30 © 2011 IBM Corporation DB2 pureScale なぜ全面停止 なぜ全面停止にならない 全面停止にならない？ にならない？ CFの の情報により 情報によりリカバリーブロック によりリカバリーブロックが リカバリーブロックが全ノードから ノードから明確 から明確にわかるため 明確にわかるため、 にわかるため、 正常ノード 正常ノードはまったく ノードはまったく影響 はまったく影響されることなく 影響されることなく処理 されることなく処理を 処理を継続 CF が更新中の 更新中のブロックを ブロックを 常に把握 メンバー1が メンバー がクラッシュ Member 1 Member 2 Member 3 CF x x x x x x I/O 処理を 処理を継続 Central Lock Manager x x x x x x CFは、どのノードがダウンしたときにどのブロックにリカバリーが必要なのかを常に意識 31 © 2011 IBM Corporation まとめ pureScale可用性 可用性 – 高速な障害検知とリカバリー自動化 • TSAとの統合 • DB2 Cluster Serviceによる総合的なリカバリ・アクショ ンの自動化 – 高速かつ安全なリカバリー処理 • CFキャッシュの利用 • Restart light – 障害発生からリカバリー完了までの間のサービス影 響を極小化 • クラスター全体停止時間の極小化 • 仕掛更新ページに対するロックのみ保持される 32 © 2011 IBM Corporation