Comments
Description
Transcript
DB2 DB2 pureScale pureScale の
DB2 pureScale の基本構造と 基本構造と スケールアウトを スケールアウトを実現するしくみ 実現するしくみ © 2011 IBM Corporation アーキテクチャー Agenda DB2 pureScale の基本コンポーネント 基本コンポーネント – DB2メンバー – Cluster caching facility （CF) – DB2 Cluster Service – 相互接続 – クライアント 複数メンバー 複数メンバー間 メンバー間で整合性を 整合性を維持する 維持する仕組 する仕組み 仕組み DB2 pureScaleと と他社クラスタ 他社クラスタの クラスタの違い 2 © 2011 IBM Corporation DB2 pureScaleの基本コンポーネント 3 © 2011 IBM Corporation アーキテクチャー DB2 pureScale の全体構成 クライアント クライアントはどこにでも クライアントはどこにでも接続 はどこにでも接続、 接続、 一つのデータベース つのデータベースとして データベースとして利用 として利用 自動的な 自動的なワークロードバランス シングル・データベース・ビュー Secondary Primary CS CS CF CF Member CS Member Member CS Member CS メンバー間でデータベースを共有 – データベースアクセスの一貫性を提供するように連携 Cluster caching facility (CF) GPFS – 効率的なグローバル・ロッキングとバッファー管理 – セカンダリーへの同期２重化により可用性を確保 超高速ノード 超高速ノード間通信 ノード間通信 – SAN LOG – CS Cluster Interconnect LOG DB2エンジン エンジン（ エンジン（メンバー） メンバー）はそれぞれのノード はそれぞれのノードで ノードで稼動 RDMAノード間通信を最大限に活用 (Infiniband) 統合された 統合されたクラスター されたクラスター・ クラスター・サービス – LOG 障害検知, 自動リカバリー(Tivoli System Automation) LOG データシェアリング・ データシェアリング・アーキテクチャー Database 4 – データベースへの共有アクセス – GPFS © 2011 IBM Corporation アーキテクチャー DB2 pureScale を構成する メンバー 構成する要素 する要素1 要素 DB2メンバー DB2エンジン エンジン – – クライアントからの接続を受け付ける db2syscプロセスやスレッド – 非データ共用環境でのDB2インスタンスに相当 – db2sysc process db2 agents & other threads db2sysc process db2 agents & other threads ログファイルはGPFS上に配置され、障害時は他 メンバーからアクセス可能 log buffer, dbheap, & other heaps log buffer, dbheap, & other heaps メンバーは メンバーはデータを データを共有 – – Member 1 各メンバーがメモリー区画やバッファープール、 ログファイルを保持する • Member 0 bufferpool(s) bufferpool(s) すべてのメンバーは同じ共有データベースにア クセス メンバー追加時のデータ分散は不要 メンバーは メンバーは論理的で 論理的で、以下のような 以下のような構成 のような構成 も可能 – マシンかLPARあたり、1メンバー (推奨） – マシンかLPARあたり、1つ以上のメンバー (非 推奨) Log Log Shared database (Single database partition) 5 © 2011 IBM Corporation アーキテクチャー DB2 pureScale を構成する 構成する要素 する要素2 要素 Cluster caching facility (CF) 複数メンバー 複数メンバー間 メンバー間でのデータ でのデータ整合性 データ整合性を 整合性を保持する 保持する ための鍵 ための鍵となる要素 となる要素 – db2 agents & other threads System z 並列シスプレックスとカップリングファ シリティのテクノロジーに由来 – DB2 pureScaleでは、ソフトウェア・ベース で実装され、AIX上で稼働する db2 agents & other threads CF上 上に保持される 保持されるエリア されるエリア log buffer, dbheap, & other heaps log buffer, dbheap, & other heaps bufferpool(s) bufferpool(s) – グループ・バッファープール(GBP) – グローバル・ロック・マネージャー（GLM) – シェアード・コミュニケーションエリア(SCA) メンバーは をプライマリーと メンバーはGBP, GLM, SCAを プライマリーと セカンダリーの セカンダリーの両方に 両方に反映 – 同期的に実施 – 二重化は必須ではないが、推奨 – 標準で自動的に設定される Primary Log Log GBP GLM SCA Secondary Shared database (Single database partition) 6 © 2011 IBM Corporation DB2 pureScale を構成する 構成する要素 する要素3 要素 DB2 Cluster Service DB2 Cluster Serviceの の構成要素 – IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP) Member 0 Member 1 db2 agents & other threads db2 agents & other threads – IBM Reliable Scalable Clustering Technology (RSCT) – IBM General Parallel File System (GPFS) log buffer, dbheap, & other heaps pureScaleクラスター クラスターの クラスターの協調動作を 協調動作を制御 – 非計画停止時の自動的な回復 bufferpool(s) log buffer, dbheap, & other heaps bufferpool(s) CS CS – 計画停止時の「透過的」なメンテナンス 障害の 障害の検知と 検知と対応 – ハートビートによる自動的な障害検知 • 障害の検知後、自動的に復旧を開始 Primary – 障害検知時の動き • 残ったメンバーに障害の発生を通知 • 障害メンバーをGPFSから切り離し • 障害メンバーのリスタートを開始 クラスターファイルシステムの クラスターファイルシステムの提供 CS Secondary Log Log Shared database (Single database partition) 7 © 2011 IBM Corporation DB2 pureScale を構成する 構成する要素 する要素4 要素 クラスター内部 クラスター内部の 内部の相互接続 3種類 種類の 種類の相互接続 – クライアント 各メンバー及びCFはすべての相互接続を使用する SAN (Storage Area Network) – 共有DISKへのアクセス経路 – CFはデータベースやログファイルへのアクセスは行 わないが、Tiebreakerへアクセスする – 障害発生時のメンバー切り離しにSCSI-3コマンドを 使用するため、VIOS経由のパスは不可 InfiniBand – 低レイテンシ、広帯域の相互接続。RDMA (Remote Direct Memory Access)を用いた割り込みの発生し ないデータ転送を実現 – メンバー、CF間の主たるデータ転送経路として使用 される Ethernet – サービス提供用ネットワーク • – Ethernet Member 0 log buffer, dbheap, & other heaps log buffer, dbheap, & other heaps bufferpool(s) bufferpool(s) InfiniBand Primary CF Secondary 各メンバーの負荷状況に応じた透過的な接続先の割り 振りが行われる SAN 管理コマンド実行時やDB2 pureScale導入時にも使 用される Log 8 Member 1 Shared database (Single database partition) Log © 2011 IBM Corporation DB2 pureScale を構成する 構成する要素 する要素5 要素 クライアント クライアント DB2 pureScaleに に接続可能な 接続可能なクライアント – DB2 V9.1以降に同梱されるDB2クライアントもしくはUniversal JDBCド ライバ – フル機能を使用する場合、DB2 V9.7 FP1以降を使用 • Transaction level WLB、Client Affinityなど 2種類 種類の 種類の接続モード 接続モード – クライアントが ） クライアントが接続先メンバー 接続先メンバーを メンバーを自動選択（ 自動選択（WLB） • メンバーから受け取る負荷情報（Server list）を元に、負荷が均衡す るように接続先や処理の振り先を決定する Member 0 db2 agents & other threads Member 1 db2 agents & other threads –Transaction level WLBでは、トランザクションの境界で処理対 象のメンバーが切り替わる • メンバー障害時の切替先メンバーも、負荷情報に基づいて自動的 に選択される – 明示的に ） 明示的に指定した 指定したメンバー したメンバーに メンバーに接続（ 接続（Client Affinity） log logbuffer, buffer, dbheap, dbheap,&& other otherheaps heaps log buffer, dbheap, & other heaps • アプリケーションの接続先を明示的に制御する場合に選択 メンバー メンバー障害 メンバー障害の 障害の発生時は 発生時はクライアント・ クライアント・リルートが リルートが行われる – – 9 bufferpool(s) bufferpool(s) 他メンバーへ再接続し、アプリケーションにはSQL30108N（接続は失敗 しましたが、再確立されました。）を返却する トランザクションはロールバックされるため、アプリケーションでハンドリン グして再実行やエラーの表示を行う © 2011 IBM Corporation アーキテクチャー ブランク・ ブランク・ページ 10 © 2011 IBM Corporation 複数メンバー間で整合性を維持する仕組み 11 © 2011 IBM Corporation クラスターの クラスターの整合性を 整合性を維持する 維持するCF する DB2 pureScaleは はデータ整合性 データ整合性を 整合性を維持した 維持したスケールアウト したスケールアウトを スケールアウトを提供 – コミットされた更新は、同期的に共有バッファープールに伝播される。 – 同じデータへの更新競合時は、pureScaleが並行性制御を行う GBP (Group Buffer Pool) – クラスター全体にわたって最新のデータを保持 GLM (global Lock Manager) – クラスター全体にわたってのロック情報を保持 SCA (Shared Communication Area) – クラスター全体のメタ情報を保持 Primary CF GBP GLM SCA Secondary CF GBP GLM SCA 12 © 2011 IBM Corporation CF上 上のストラクチャー1 ストラクチャー - GBP GBPの の構造 – GBP data element Primary CF • GBP上に保持されるデータページの実体 GBP Secondary CF data element Directory entry – GBP directory entry GBP data element Directory entry • GBP/LBPのデータページを管理するためのメタデータ • クロス・インバリデーション時などに使用される • Secondary CFはdirectory entryを持たず、Primary Roleに切り替わった時点で再構築する GBPの の主な役割 – 各メンバーから共通にアクセスできるキャッシュを提供する – クラスター全体にわたってデータページの整合性を保証する • 更新・コミットされたデータページの最新バージョンを保持する • 各メンバーがローカルに保持するデータページが最新であることを保証する GBPの の構成 – DB2 pureScaleの構成時に自動的に定義される • GBPはクラスター/データベース全体で一つのみ – 「GBPを作成する」という操作は必要ない • 一つのGBPで4KBから32KBまで、すべてのページサイズのLBPをサポートする – GBPのサイズはデータベース構成パラメーター CF_GBP_SZで定義する • デフォルトはAUTOMATIC 13 © 2011 IBM Corporation CF上 上のストラクチャー1 続き ) ストラクチャー - GBP(続 GBPと とLBPの の関係 – メンバーが保持するBuffer Poolは、GBPと の関係からLBPと呼ばれる – GBP上のデータページは、db2agentが直接 参照するのではなく、リクエストに応じてLBP にコピーされる – – Member 1 Member 0 db2 agents db2 agents ①100 Logical Reads LPB上に存在するデータページはすべて GBPのdirectory entryに登録されている LBP メンバーはGBPからのみデータページを取 得し、他メンバーと直接データページを授受 することはない LBP ②5 GBP Logical Reads ③4 return page; 1 does’nt データページ取得時 データページ取得時の 取得時の流れ ①100ページの読み取りをLBPに対して行う ②5ページ分がLBPに存在しなかった場合、 GBPにリクエストを行う（RAR） ⑤1 page returned from disk ④1 GBP Physical Read GBP ③4ページがGBPに存在したため取得でき、1 ページは存在しなかった ④残った1ページの読み取りをDISKへ行う ⑤DISKから1ページを取得 14 © 2011 IBM Corporation CF上 上のストラクチャー1 続き ) ストラクチャー - GBP(続 データページ参照時 データページ参照時の 参照時の流れ – – 2つのメンバーから同じページを参照 GBP,LBPとも対象ページを持っていない ①メンバー1にSQLが発行され、EMP=Yのレコー ドが要求される。データページAの取得が必要 となる。 ②メンバー1はページAを持たないため、GBPに 対してRead and Registerを発行する。このタ イミングで、Directory EntryにM1がページAを 保持していることが登録される。 Select from EMP Where Emp=Y Select from EMP Where Emp=Y Select from EMP Where Emp=Y M1 LBP M2 A Disk Read DISK Disk Read A LBP A ③GBPにはページAがキャッシュされていなかっ たため、DISKからページAを取得する。 ④次に、メンバー2にも同じSQLが発行され、ペー ジAの取得が必要となる。 Read & Register (RAR) RAR ⑤メンバー2からもRARによるページAの取得要 求が発行される。メンバー2がページAを保持 することが登録される。 ⑥GBPはページAを保持していないため、メン バー2はDISKから取得する。 ⑦メンバー2が再度ページAを参照する場合は、 LBP上のページAを参照可能 GBP GLM SCA Directory Entry Primary CF SA M1 M2 15 © 2011 IBM Corporation CF上 上のストラクチャー1 続き ) ストラクチャー - GBP(続 データページ更新時 データページ更新時の 更新時の流れ – – – 前ページの処理が完了後の状態 GBPはページAを持っていない メンバー1,2はページAをLBPに保持する ①メンバー1で更新処理が実行され、ページAが 更新される。 ②メンバー1でコミットが発行され、ページAの更新 が確定する。 M1 LBP M2 A' A A' A DISK ③メンバーAからWrite And Register (WAR)が発 行され、GBPにページA’ ’が書き込まれる ④メンバー2の保持するページAに対して無効化 （クロス・インバリデーション）が行われる。同時 にDirectory Entryからメンバー2の登録が削除 される。 ⑤WAR完了の応答が返る。 Select from EMP Where Emp=Y Update EMP Set Salary=X Where Emp=Y COMMIT A Write & Register (WAR) LBP XI RAR ⑥コミット完了の応答が返る。 ④メンバー2が再度ページAを必要とした場合、改 めてRARを発行する。 ⑤GBPからメンバー2にページAが書き込まれる。 同時にDirectory Entryも更新される。 GBP GLM SCA A' Directory Entry Primary CF SA M1 M2 16 © 2011 IBM Corporation CF上 上のストラクチャー1 続き ) ストラクチャー - GBP(続 クロス・ クロス・インバリデーションの インバリデーションの動き – – GBP上に存在するdirectory entryの情報を元に、LBPのXIベクターに無効フラグを立てる XIベクターはLBPのBPD (Buffer Pool Descriptor)中に存在する GBP Page Registration List M1,M2,M3 1-bit RDMA XI sent to each member in the page registration list Member 1 Local Bufferpool XI Vector 17 Member 2 Local Bufferpool New page sent to the CF XI Vector Member 3 Local Bufferpool XI Vector © 2011 IBM Corporation CF上 上のストラクチャー1 続き ) ストラクチャー - GBP(続 更新された 更新されたページ されたページの ページの書き込み GBPから からDISKへの への更新 から への更新ページ 更新ページ出力 ページ出力は 出力は「キャストア ウト」 ウト」と呼ばれる – 非データ共用環境でのページ・クリーニング と同様の処理 キャストアウトは キャストアウトは、各メンバー上 メンバー上の「キャストアウト・ キャストアウト・ エンジン」 エンジン」が実施する 実施する – キャストアウトのトリガーは、非データ共用環 境と同様SOFTMAXで決定される – GBP中のダーティ・ページ比率が上昇した際 にもトリガー条件が満たされる M1 LBP M2 A' A DISK Castout engine A' A LBP A' A A' ①キャストアウトのトリガー条件が満たされる ②各メンバーでキャストアウト・エンジンが処理対 象のダーティ・ページを特定する ③GBPからメンバーにダーティ・ページを取得する GBP GLM SCA A' ④DISK上のテーブルスペースに対して出力する Directory Entry Primary CF SA M1 M2 18 © 2011 IBM Corporation CF上 上のストラクチャー1 続き ) ストラクチャー - GBP(続 GBPへの へのオペレーション へのオペレーションのまとめ オペレーションのまとめ – Read and Register (RAR) • 要求するデータページの最新版をGBPにリクエストする • 同時に、リクエストしたメンバーのLBPにそのページが読み込まれる事を登録する – そのページに対してXI（クロス・インバリデーション）を実行する際の対象アドレスを登録しておく • GBPがそのデータページを保持していない場合、登録のみが行われる – Write and Register (WAR) • メンバーが保持する最新の更新ページをGBPへ書き込む • 下記のタイミングで実行される – 更新処理のコミット – ローカルで更新されたページを他メンバーが参照・更新する必要がある場合 – その他 • Write and Register Multiple (WARM) – WAR処理を複数のページに対して実行する • クロス・インバリデーション (XI) – あるページが更新された際に、他メンバー上にあるそのページの古いバージョンを無効化 （Invalidation）する • キャストアウト – GBP上のダーティ・ページをDISKへと書き込む – DB2メンバーから実行される 19 © 2011 IBM Corporation CF上 上のストラクチャー2 ストラクチャー - GLM クラスター全体 クラスター全体で 全体でロック情報 ロック情報を 情報を共有する 共有するキャッシュ するキャッシュを キャッシュを提供 – 各メンバーが保持するロックのリストを保持 GLMの の構成 – GLMにアサインするメモリー量はCF_LOCK_SZ DB構成パラメーターで定義 • デフォルトはAUTOMATICで、CF_MEM_SZの一定割合がアサインされる。 GLMは はクラスター全体 クラスター全体で 全体で処理の 処理の一貫性が 一貫性が保たれることを保証 たれることを保証 – 例1：メンバーAで更新中の列はメンバーBから更新できない • GLM上のグローバル・ロックで並行性を制御 – 例2：複数のメンバーが同じページを更新する際に、GBPを経由して最新バー ジョンのページをやりとりする仕組みを提供 • これまでのLogical Lockに加えて、DB2 pureScale特有のPhysical Lockを使用する。 • Physical Lockとは、非データ共用環境でのラッチに似たしくみ • 必要に応じてコミット前でも解放することが可能 20 © 2011 IBM Corporation CF上 上のストラクチャー2 続き) ストラクチャー - GLM(続 複数メンバー 複数メンバーでの メンバーでの更新処理 での更新処理の 更新処理の調停 – メンバー1,2はページAをLBPに保持する Update EMP Set Salary=X Where Emp=Y Update EMP Set Salary=X Where Emp=Z ①メンバー1で更新処理が発行される。 ②CFに対してページAの P-Lock（排他モード）を 要求する M1 ③メンバー1にページA P-Lock(排他モード）が与 えられる。 LBP M2 A' A DISK ④LBP上でページの更新を実施する。 ⑦CFはメンバー1に対してP-Lockの解放を依頼 する ⑧メンバー1はP-Lockを解放し、WARを発行する ことでページA'をGBP書き込む ⑨CFはメンバー2にP-Lockを付与し、GBP上に書 き込まれたページA'をメンバー2に書き込む ⑩メンバー2のLBP上で更新が実行される。 21 LBP A ⑤メンバー2でページAの別 別の行を更新するSQL が発行される。 ⑥メンバー2がCFに対してページAのP-Lock（排 他モード）を要求する A'' A' A Write & Register (WAR) Put page A Release request GBP Lock request Lock request GLM A' Directory Entry M1 A-X M2 A-X M1 M2 M2 SCA Primary CF SA © 2011 IBM Corporation CF上 上のストラクチャー3 ストラクチャー - SCA SCA (Shared Communication Area)の の主な役割 – データページ以外の情報を共有するために提供される – データベース・ヒープをクラスター単位に拡張したような存在 下記の 下記の様なオブジェクトを オブジェクトをシェアする シェアする – TCBs - ：テーブル・コントロールブロック – IXCBs - ：索引コントロールブロック – POOLCBs ：バッファープール・コントロールブロック メンバー間 メンバー間でログの ログの整合性を 整合性を持たせるための情報 たせるための情報を 情報を保持 22 © 2011 IBM Corporation DB2 pureScaleと他社クラスタの違い 23 © 2011 IBM Corporation ①スケーラビリティ②アプリメンテナンス 他社クラスタ 他社クラスタ なぜアプリパーティショニング なぜアプリパーティショニングが アプリパーティショニングが必要？ 必要？ データはノード間に論理的に分割され、各データのマスターノードが決まる あるノードが‘マスター’ でないデータブロックにアクセスする場合は、グローバル・キャッシュ・ サービスにリクエストする必要がある – 要求されたノードが‘マスター’ でないデータブロックへのアクセスには、データの受け渡し のためノード間通信が必要となる (パフォーマンスのボトルネックの主な原因) ノード 1 ノード 2 ノード 3 ノード間通信ネットワーク DB2 pureScale ではこの“ ではこの“マスタリング” マスタリング” が不要 ノード 2 ノード 3 ノード 1 にクラスターから マスターさ にマスターさ さ マスターさ から等 マスター可能 にマスターさ さ が全てのクラスター マスター 全 てのデータ てのデータが データ ての クラスター から等しくアクセス しくアクセス可能 アクセス れるデータ れるデータ れるデータ れるデータ れるデータ れるデータ 他社 データベース 24 © 2011 IBM Corporation ①スケーラビリティ②アプリメンテナンス 他社クラスタ 他社クラスタ なぜアプリパーティショニング なぜアプリパーティショニングが アプリパーティショニングが必要？ 必要？ 3ノードの他社クラスターの例で、クライアントがアクセスしたノードがマスターノードでない可能 性は67% => ノード間通信が発生 – 4 ノードのクラスター = 75%の可能性でノード間通信が発生 – 8 ノードのクラスター = 88%の可能性でノード間通信が発生 – 16ノードのクラスター = 94%の可能性でノード間通信が発生 RACではノード間通信を低減させるために、アプリケーションおよびデータのパーティショニングが推奨 – メンテナンス負荷増大やアプリケーション開発コスト・リスク増大につながる ノード 1 ノード 2 ノード 3 ノード間通信 ネットワーク DB2 pureScale は クラスターの の台数に クラスター 台数に関係なく 関係なく Node 2 Node 3 Node 1 同様な な データアクセスと と スケールアウトが が 可能 さ 同様 データアクセス スケールアウト にマスターさ にマスターさ マスターさ マスター にマスターさ マスターさ れるデータ れるデータ れるデータ れるデータ れるデータ れるデータ 他社 データベース 25 © 2011 IBM Corporation DB2 pureScaleの のメッセージフロー 2メンバー メンバーから メンバーから同 から同じページの ページの異なる行 なる行を更新 UPDATE T1 SET C3 = 111000 WHERE C1 = 1 Member Member11 Valid = N Page 1001 P-Lock 1 Eaton 109351 111000 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SW Release P-Lock and pull page SLS X_row1 P_1001 CF CF RaR 1001 RaR 1001 Member Member22 Page 1001 1 Eaton 111000 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SW Page 1001 P-Lock 1 Eaton 111000 109351 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SE SW Page 1001 Member 1 Member 2 SLS X_row4 P_1001 UPDATE T1 SET C4 = SE WHERE C1 = 4 26 © 2011 IBM Corporation Oracle RACの のメッセージフロー 2メンバー メンバーから メンバーから同 から同じページの ページの異なる行 なる行を更新 UPDATE T1 SET C3 = 111000 WHERE C1 = 1 Instance Instance11 Page X lock I’d like page 1001 for Update Page 1001 1 Eaton 109351 111000 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SW Send page 1001 to Node 2 I’d like page 1001 for Update Got it Read it from disk Instance Instance33––master masterfor forpage page1001 1001 Got it Instance Instance22 Page X lock Page 1001 1 Eaton 111000 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SW Send page 1001 to Node 1 Got it I’d like page 1001 for Update UPDATE T1 SET C4 = SE WHERE C1 = 4 27 © 2011 IBM Corporation Oracle RACの のメッセージフロー 2メンバー メンバーから メンバーから同 から同じページの ページの異なる行 なる行を更新 UPDATE T1 SET C3 = 111000 WHERE C1 = 1 Instance Instance11 Page X lock I’d like page 1001 for Update I’d like page 1001 for Update I’d like page 1001 for Update Send page 1001 to Node 2 Send page 1001 to Node 2 I’d like page 1001page 1001 to NodeGot Send 2 it for Update Send page 1001 to Node 2 Got it Got it Got it Read it from disk Page 1001 1 Eaton 109351 111000 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SW Instance Instance33––master masterfor forpage page1001 1001 Got it Instance Instance22 Page X lock Page 1001 1 Eaton 111000 NE 2 Zikopoulos 450321 SW 3 Sachedina 849291 NW 4 Huras 398122 SW UPDATE T1 SET C4 = SE WHERE C1 = 4 28 Send page 1001 to Node 1 Send page 1001 to Node 1 Send Got it page 1001 to Node 1 Send Got it page 1001 to Node 1 Got it I’d like page Got 1001it for Update I’d like page 1001 for Update I’d like page 1001 for Update I’d like page 1001 for Update © 2011 IBM Corporation スケーラビリティの スケーラビリティの違い DB2 pureScaleでは では、 では、メンバー間 メンバー間のコミュニケーションを コミュニケーションを最小限に 最小限に抑えるこ とにより、 とにより、アプリケーション・ アプリケーション・パーティショニングに パーティショニングに依存しない 依存しないスケーラビリ しないスケーラビリ ティを ティを確保 – Oracle RACでは、更新意図を持ったスキャンの際に必ずページロックを 取得 – DB2 pureScaleでは、行を実際に更新する時点のみページロックを取得 29 © 2011 IBM Corporation まとめ DB2 pureScaleの の主要コンポーネント 主要コンポーネント – メンバー、CF（Cluster caching facility) – DB2 Cluster Service、GPFS、InfiniBand CFが が保持する 保持するストラクチャー するストラクチャー – データページを共有するためのGBP – ロック情報を共有するためのGLM – 各種コントロールブロックなどを共有するSCA DB2 pureScaleが がスケールする スケールする理由 する理由 – RDMAによる低レイテンシ・低コストなデータ転送 – ロックモデルの最適化によりメンバー間コミュニケーションを最小化 30 © 2011 IBM Corporation