DB2 pureScale テクノロジーオーバービュー © 2011 IBM Corporation アジェンダ クラウド時代 クラウド時代の 時代のビジネスの ビジネスの背景 pureScaleアーキテクチャ アーキテクチャ pureScaleの の特長 ① スケーラビリティー ② アプリケーションからの透過性 ③ 高可用性 pureScaleと と他社クラスタ 他社クラスタとの クラスタとの違 との違い pureScaleの のシステム構成 システム構成 4 © 2011 IBM Corporation 既存の 既存のテクノロジーの テクノロジーの限界を 限界を超える 経営者・技術者の期待 1 爆発的な 爆発的なトランザクション増加 トランザクション増加への 増加への 備え 1 サーバ追加 サーバ追加で 追加で思ったとおりスケー ったとおりスケー ルしない スピーディかつ低 かつ低コストな コストなサービ 2 スピーディかつ アプリ・データ分割 データ分割で 分割でチューニング 2 アプリ・ しなければスケール しなければスケールしない スケールしない ス拡張 サービスレベルを落とさない 3 サービスレベルを 運用 他社ディスク・シェア型 アーキテクチャーの限界 障害・メンテナンス時 メンテナンス時にリカバリー 3 障害・ までの間 までの間、停止を 停止を伴う 「ノンストップ」、「 ノンストップ」、「スケーラビリティ 」、「スケーラビリティ」、「 スケーラビリティ」、「スピード 」、「スピード」 スピード」を追求した 追求した 新しいデータベース しいデータベース・ データベース・インフラ技術 インフラ技術 5 © 2011 IBM Corporation クラウドコンピューティングの 基盤へ クラウドコンピューティングのDB基盤 基盤へ IBMメインフレームの メインフレームのテクノロジーを テクノロジーを吸収した 吸収した超 した超スケーラブルな スケーラブルなDB基盤 既存の 既存のスケールアウトテクノロジーの スケールアウトテクノロジーの限界を 限界を超えた シェアード型 シェアード型 pureScaleを発表 DB2 pureScale (Linuxサポート) 2010年 年8月 月27日 日 2009年 年11月 月12日 日 DB2 pureScale発表(AIX) DB2 9.7発表 2009年 年5月 月21日 日 V9.5 2007年 年 大規模DB対応強化 データ・ガバナンス強化 高可用性の強化、H/W連携 トランザクショナルXML pureXML® Support V9 オートノミック機能の強化 開発生産性の向上 2004年 年 V8.2 高可用性の強化 オートノミック機能の強化 ・ 2006年 年 Enterprise Linux ・ 1973年 年 System R開発開始 開発開始 1970年 年 E.F,Codd RDBで で確立した 確立したデータ 重要さ したデータ一貫性 データ一貫性の 一貫性の重要さ 6 © 2011 IBM Corporation 高い可用性を 可用性を実現する 実現するDB2 するDB2の DB2のクラスター技術 クラスター技術 比較のポイント pureScale Infosphere Warehouse(DPF) HADR アーキテクチャ アクティブ-アクティブ型 シェアードディスク型 アクティブ-アクティブ型 シェアードナッシング型 アクティブ-ホットスタンバイ型 概要 メインフレームのCFのアーキテク チャをSWの機能で実現し、可 用性と拡張性を向上 主に大規模情報系で活用 大量データを並列的に高速に 処理できる シンプルに可用性を向上 ログ転送のみによる二重化のた めパフォーマンス劣化が少ない 計画停止対策・ロー リングアップグレード 片系ずつの適用をアプリケー ションの停止なしに可能 片系ずつの適用が可能だが、 テークオーバーの考慮が必要 片系ずつの適用が可能。 テークオーバー処理が高速 障害対策 障害時に更新中のページ以 外のデータにアクセス可能 障害サーバーの復旧時間目 標は数十秒 N-1/Nのデータにアクセス可能。 障害サーバーの復旧時間目標 は1分前後 テークオーバー中は全体停止。 復旧時間目標は数十秒から1 分程度 大規模OLTP 大規模OLTP 統合DB 統合DB 高信頼性 高信頼性 7 大規模DWH 大規模DWH （大規模OLTP） （大規模OLTP） 汎用的な 汎用的な OLTP/DWH OLTP/DWH © 2011 IBM Corporation DB2 pureScale の特長 クラウド基盤にも 基盤にも適 にも適する超大規模 する超大規模スケール 超大規模スケール 1 クラウド基盤 アプリケーション サーバーを追加した分、パフォーマンスが向上する 初期は必要なキャパシティだけ購入しビジネスの成長にあわせて拡張 アプリケーション変更 変更の の無い即時拡張 2 アプリケーション変更 シングルデータベース アプリケーションの変更と停止をせずに容易に拡張できる DB2 DB2 DB2 クラスター構成のためのアプリケーション変更のリスクとコストを低減 障害時、メンテナンス時 メンテナンス時もノンストップ 3 障害時、 ノード間通信 ノード間通信 CF 障害時・メンテナンス時も稼動し続ける データシェア 安定したパフォーマンスで連続的なデータアクセスを提供 業界をリードするIBMメインフレームのデザインをオープン系プラットフォームで踏襲 他社の クラスター、 他社のHAクラスター クラスター、スケールアウト・ スケールアウト・ソリューションの ソリューションの限界を 限界を超えるデザイン えるデザイン スケールアウトソリューションの管理コストを大幅に削減 8 © 2011 IBM Corporation pureScaleは は何をモデルに モデルに？ DB2 for z/OSデータシェア データシェア 他社の 他社の尊敬を 尊敬を集めるアーキテクチャー めるアーキテクチャー スケーラビリティと スケーラビリティと高可用性における 高可用性におけるゴールド スタンダードとして、 におけるゴールド・ ゴールド・スタンダードとして として、 だれもがDB2 for z/OS を認めています。 だれもが めています。 Oracle社のCEO ラリー・エリソン 「わたしは、いろいろなデータベースをけなしている。 ただし、メインフレーム版のDB2を除いて。 メインフレーム版のDB2は、第一級の技術だ。」 理由 – z/OS全体でカップリング・ファシリティ(CF)を使用 • ロックとキャッシュの集中管理により、優れたスケーラビリティと可用性を実現 pureScaleは はソフトウェア・ を実装 ソフトウェア・テクノロジーで テクノロジーでCFを 9 © 2011 IBM Corporation アーキテクチャ pureScale の全体構成 クライアント アプリケーションはどこにでも アプリケーションはどこにでも接続 はどこにでも接続 – 一つのデータベースとして利用 – 自動的なワークロードバランス シングル・データベース・ビュー DB2エンジン エンジン(メンバー で稼動 エンジン メンバー)は メンバー は筐体/LPARで 筐体 – AIX on Power6・Power7 – SUSE Linux on System X メン バー CF-2nd-ary メンバー メンバー メンバー をサポート （2011年6月時点） CF- Primary 統合された 統合されたクラスター されたクラスター・ クラスター・サービス CS CS CS CS CS CS – 障害検知, 自動リカバリー, クラスター・ファイルシステム – Tivoli System Automation (TSA)、GPFS™ サーバー間通信 接続（Fiber） SAN ログ ログ ログ ログ 超高速サーバー 超高速サーバー間通信 サーバー間通信 – RDMAサーバー間通信を最大限に活用 (Infiniband) Cluster caching facility (CF) – ロックとバッファー管理を最適化 – セカンダリ への同期2重化により可用性を確保 データ データシェアリング・ データシェアリング・アーキテクチャー – データベースへの共有アクセス – General Parallel File System (GPFS) 10 © 2011 IBM Corporation アーキテクチャ pureScale 拡張性と 拡張性と連続稼動性の 連続稼動性のベースとなる ベースとなるテクノロジー となるテクノロジーの テクノロジーの追求 1. CFで で集中管理された 集中管理されたロック されたロックと ロックとキャッシュにより キャッシュにより スケーラビリティ・ スケーラビリティ・可用性を 可用性を最大化・ 最大化・アプリの アプリのチューニング低減 チューニング低減 – pureScaleはロック情報と更新データをCFに一元管理しスケーラビリティを向上 – 障害時には CFのメモリー上の情報を元にリカバリー処理を実行し全体停止なし 2. 超高速サーバー 超高速サーバー間通信 サーバー間通信により 間通信により 低負荷・ 低負荷・高いスケーラビリティを スケーラビリティを発揮 – – サーバー間通信にRDMA/uDAPLを採用 CF DB2 DB2 DB2 更新データ 更新データ ロック 各サーバーからRDMA経由で他のサーバーの メモリーを直接更新可能 3. ロックモードの ロックモードの最適化により 最適化により DB2 RDMA通信 通信 データベース 低負荷・ 低負荷・高いスケーラビリティを スケーラビリティを発揮 •RDMA・・・Remote Direct Memory Access •uDAPL・・・User Direct Access Programming Library 11 © 2011 IBM Corporation ①スケーラビリティ 他社クラスタ 他社クラスタの クラスタの4倍のスケーラビリティ pureScale vs. Oracle RAC Projected Transaction Scalability pureScaleと と他社クラスタ 他社クラスタの クラスタのスケーラビリティ Estimated Transactoins per Minute スループット(トランザクション/分) 16,000,000 95%のスケール 95%のスケール 14,000,000 $1.28/tpm $1.24/tpm 12,000,000 $1.20/tpm 10,000,000 $1.15/tpm $1.10/tpm 8,000,000 6,000,000 4,000,000 DB2 pureScale on Power Systems Oracle RAC on 他社クラスタ 他社クラスタ Nehalem $1.06/tpm $1.05/tpm $1.67/tpm 2,000,000 $1.41/tpm $1.08/tpm 65%のスケール 65%のスケール 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #サーバー数 Cluster Members Price per tpm includes 3-year total cost of acquisition of hardware, software, maintenance Price does not include storage or networking 12 © 2011 IBM Corporation ①スケーラビリティ 驚異的な 驚異的なスケーラビリティを スケーラビリティを発揮する 発揮するアーキテクチャ するアーキテクチャ pureScaleの の場合 他社クラスタ 他社クラスタの クラスタの場合 拡張性の 拡張性の課題① 課題① 高い拡張性の 拡張性の理由① 理由① – 更新ページとロックを各 サーバーで管理 – 更新ページとロックをCF で一元管理 拡張性の 拡張性の課題② 課題② 高い拡張性の 拡張性の理由② 理由② – ソケット通信によるオー バーヘッド・CPUコスト増 – RDMAによる超高速メモ リー間通信 • ミリ秒の通信処理 CF • 10～15マイクロ秒の通 信処理 拡張性の 拡張性の課題③ 課題③ – 冗長なロックモデル • 更新意図をもったスキャ ンのタイミングでページ・ ロックを取得 サーバー追加 サーバー追加で 追加で思ったとおりスケール ったとおりスケールしない スケールしない 13 高い拡張性の 拡張性の理由③ 理由③ – ロックモデルの最適化 • 該当行の更新を実行す る時点のみページ・ロック を取得 サーバー追加 サーバー追加で 追加でスケール © 2011 IBM Corporation ①スケーラビリティ 高い拡張性の によるロック 拡張性の理由 CFによる によるロックと ロックとキャッシュの キャッシュの一元管理 pureScaleの の場合 他社クラスタ 他社クラスタの クラスタの場合 課題： 課題：各サーバーで サーバーでロックと ロックとキャッシュを キャッシュを分散管理 解決策： でロックと 解決策：CFで ロックとキャッシュを キャッシュを一元管理 – データは各 各サーバーに サーバーに論理分割され 論理分割され、各デー され タのマスターサーバーがロックとキャッシュを分 散管理 – データを各サーバーに論理分割せず、CFが が ロックと ロックとキャッシュを キャッシュを一元管理 – マスターでないデータへのアクセスには、サー サー バー間通信量 バー間通信量が 間通信量が増えボトルネックとなりやすい ボトルネック – 全てのデータが全てのサーバーから等しくアクセ ス可能で、サーバー サーバー間通信量 サーバー間通信量が 間通信量が少なくボトル なく ネックとなりにくい – パーティショニングを パーティショニングを行い、通信量を低減 – パーティショニングの パーティショニングの必要なし 必要なし サーバー 1 サーバー 2 サーバー 3 サーバー 1 サーバー 2 サーバー 3 CF サーバー 1 にマスターさ マスターさ れるデータ れるデータ 14 サーバー 2 にマスターさ マスターさ れるデータ れるデータ サーバー 3 にマスターさ マスターさ れるデータ れるデータ © 2011 IBM Corporation ②アプリケーションからの透過性 アプリケーションの アプリケーションの変更と 変更と停止を 停止を低減 性能向上のための 性能向上のためのアプリパーティショニング のためのアプリパーティショニングは アプリパーティショニングは必 要なし サーバー追加時 サーバー追加時の 追加時のメンテナンス作業 メンテナンス作業を 作業を低減 – サーバー追加のために、アプリケーションやイ ンフラの変更や停止作業を低減 負荷分散のための 負荷分散のための配慮 のための配慮を 配慮を低減 – サーバー間での自動ロードバランシングを実 現 – アプリケーションはサーバーを意識することなく、 自動的に最適なサーバーで処理を行える 管理者は 管理者は再チューニングをすることなく チューニングをすることなく処理能力 をすることなく処理能力を 処理能力を追加可能 開発者は 開発者はクラスター構成 クラスター構成であることを 構成であることを意識 であることを意識する 意識する必要 する必要なし 必要なし 15 © 2011 IBM Corporation ②アプリケーションからの透過性 アプリケーションから アプリケーションから透過性 から透過性な 透過性なワークロードバランスの ワークロードバランスの実現 サーバーの サーバーの負荷情報を 負荷情報を元に自動ワークロードバランス 自動ワークロードバランスを ワークロードバランスを実現 – 接続単位・トランザクション単位のロードバランス • 全メンバーの負荷情報を定期的にクライアントに通知 • 次の接続を負荷が最小のメンバーに自動転送 フェイルオーバー・ フェイルオーバー・フェイルバック – 障害が発生したメンバーのアプリは、障害が発生していないメンバーに均等に自動分配 – 障害が発生したメンバーがオンラインに戻ると、逆の動きを実行 クライアント 16 クライアント © 2011 IBM Corporation ②アプリケーションからの透過性 負荷状況に 負荷状況に応じた適切 じた適切な 適切なワークロードバランス WAS#1、DB#1でCPUが占有されている状況でも、各レイヤーの負荷分散機 WAS#1、DB#1でCPUが占有されている状況でも、各レイヤーの負荷分散機 能により、トランザクション処理全体への影響を軽微に抑えて、サーバー経路 能により、トランザクション処理全体への影響を軽微に抑えて、サーバー経路 の最適化が行われていることを確認。 の最適化が行われていることを確認。 トランザクション処理量の推移 WAS #1 DB #1 WAS #2 DB #1 CPU DB #1 WAS#1、DB#1 CPU高負荷 1200 WAS #1 DB #2 WAS #2 DB #2 CPU WAS #1 100% WAS#2 DB#2 ODR 80% 70% ョ C P U 50% 使 用 40% 率 60% ン 600 処 理 数 400 （ ） DB#1 90% ト 1000 ラ ン ザ ク 800 シ 毎 秒 WAS#1 30% 20% 200 10% 0 17 0 0 : 0 4 : 1 1 0 3 : 0 4 : 1 1 0 0 : 1 4 : 1 1 0 3 : 1 4 : 1 1 0 0 : 2 4 : 1 1 0 3 : 2 4 : 1 1 0 0 : 3 4 : 1 1 0 3 : 3 4 : 1 1 0 0 : 4 4 : 1 1 0 3 : 4 4 : 1 1 0 0 : 5 4 : 1 1 0 3 : 5 4 : 1 1 0 0 : 6 4 : 1 1 0 3 : 6 4 : 1 1 0 0 : 7 4 : 1 1 0 3 : 7 4 : 1 1 0 0 : 8 4 : 1 1 0 3 : 8 4 : 1 1 0 0 : 9 4 : 1 1 0 3 : 9 4 : 1 1 0 0 : 0 5 : 1 1 0 3 : 0 5 : 1 1 0 0 : 1 5 : 1 1 0 3 : 1 5 : 1 1 0 0 : 2 5 : 1 1 0 3 : 2 5 : 1 1 0 0 : 3 5 : 1 1 0 3 : 3 5 : 1 1 0 0 : 4 5 : 1 1 0 3 : 4 5 : 1 1 0% © 2011 IBM Corporation ③高可用性 計画停止の 計画停止の影響の 影響の最小化 1) 稼動中の 稼動中のシステム 停止サーバー 停止サーバーの サーバーの確認 DB2 DB2 DB2 2) “Quiesce” 実行 3) メンテナンスの メンテナンスの実行 Quiesceが が完了後 HW、 、SWパッチ パッチの パッチの適用 計画停止 新しいトランザクション しいトランザクションを トランザクションを他 サーバーに サーバーに配分 既存の 既存のトランザクション完了 トランザクション完了 DB2 DB2 DB2 DB2 DB2 DB2 システムは システムは連続稼動 実行中の 実行中のトランザクションの トランザクションの強制終了や 強制終了やロールバックはなし ロールバックはなし 18 © 2011 IBM Corporation ③高可用性 障害からの即時復旧 pureScale の設計の 設計の要 DB2 DB2 DB2 DB2 障害範囲の 障害範囲の極小化 – 障害サーバー以外はアクセスを継続 Log • 障害サーバーへの接続は稼動中のサーバーに 再分配 CF 利用できるデータの割合(%) – 障害が発生したサーバーで実行中のトランザ クションも、問題の検知も含めて短時間で復 旧させることが目標 Log データ – 障害サーバーが更新中のデータ以外は全面 的にアクセス可能 全面復旧までの 全面復旧までの時間 までの時間の 時間の高速化 Log Log CF データベースサーバーの データベースサーバーの障害 回復中には 回復中にはインフライトデータ にはインフライトデータののみを インフライトデータののみをロック ののみをロック 100 50 Time (~seconds) 19 © 2011 IBM Corporation ③高可用性 障害ケース 障害ケースと の対応 (1/2) ケースとpureScaleの 障害ケース 障害ケース DB2 メンバー DB2 DB2 他のメンバーは メンバーは 稼動し 稼動し続けるか DB2 DB2 CF プライマリ CF DB2 DB2 DB2 自動復旧できるか 自動復旧できるか メンバーの役割は透過的に他のメン バーに引き継がれる DB2 CF CF セカンダリ CF DB2 DB2 DB2 DB2 CF CF 20 CF © 2011 IBM Corporation ③高可用性 障害ケース の対応 (2/2) 障害ケースと ケースとpureScaleの 障害ケース DB2メンバー プロセス障害 対応 回復時間 (目標値) 自サーバーでプロセス をリスタートしクラッシュ リカバリー 数秒 DB2メンバー 他サーバーでクラッシュ ~ 15 秒 サーバー障害 リカバリーを実行 可用性レベル •他のメンバーは継続処理が可能。 •障害メンバーに接続するアプリケー ションは自動的に他のメンバーに再 接続される。仕掛かり中のトランザ クションはエラーとともにロールバック される。 •障害メンバーによって更新中だった ページのみがリカバリー処理される。 （その他のデータはすべてアクセス可 能） プライマリ CF 障害 セカンダリCFがプライマ リCFに切り替わる ~5秒 •全アプリケーションにエラーを返さず 継続処理可能 •瞬間的にCFへの要求がWAIT 21 © 2011 IBM Corporation ③高可用性 他社クラスタ 他社クラスタの クラスタのリカバリー処理 リカバリー処理の 処理の違い DB2 pureScale DB2 DB2 DB2 更新データ 更新データ ロック RDMA通信 通信 データベース 利用できるデータの割合(%) CF 他社DB 他社 データベース サーバーの サーバーの 障害 他社DB DB2 pureScale 他社DB 他社DB 他社DB 他社DB 更新データ 更新データ 更新データ 更新データ 更新データ 更新データ 更新データ 更新データ ロック ロック ロック ロック TCPIP通信 通信 データベース 時間 (~秒) DB2は は障害サーバー 障害サーバーが サーバーが更新中だった 更新中だった一部 だった一部 のデータのみを データのみをロック のみをロック 他社DBは 他社 は全サーバーの サーバーの整合性確認のため 整合性確認のため IOを をフリーズし フリーズし部分停止、 部分停止、あるいは全体停止 あるいは全体停止 DB2 pureScale の設計の 設計の要は、 障害範囲を 障害範囲を極小化し 極小化し、全体復旧までの 全体復旧までの時間 までの時間を 時間を高速化することである 高速化することである 22 © 2011 IBM Corporation pureScaleと と他社クラスタ 他社クラスタの クラスタの違い DB2 pureScale CF DB2 DB2 他社クラスタ DB2 更新データ 更新データ ロック 他社DB 他社DB 他社DB 他社DB 更新データ 更新データ データ 更新データ 更新データ 更新 更新データ 更新データ 更新データ ロック ロック ロック ロック RDMA通信 通信 データベース 構成特徴 ○ サーバー間通信量、ロック管理負荷が小さい サーバー間通信が高速 (RDMA) ②アプリケーション・メンテナンス ○ 負荷 サーバー追加時にアプリケーションの変更必要なし 23 データベース ロック情報と更新データをCFで で一元管理 ロック情報と更新データを各 各サーバーで サーバーで分散管理 サーバー間通信にRDMAを採用(約10マイクロ秒) サーバー間通信にUDP/ソケットプロトコル ソケットプロトコルを採用 ソケットプロトコル ①スケーラビリティ ③可用性 TCPIP通信 通信 ○ 全面停止時間がない 全体の復旧時間が高速 △ サーバー間通信量、ロック管理負荷が大きい サーバー間通信が低速 (UDP、ソケットプロトコル) △ サーバー追加時にアプリケーション・パーティショニング 変更 △ 全面停止時間がある 全体の復旧に時間がかかる場合がある © 2011 IBM Corporation pureScaleの の活用シナリオ の基盤 活用シナリオ 統合DBの 統合 5年後 年後の 年後のシステムを システムを想定した 想定した統合 した統合DBのあるべき 統合 のあるべき姿 のあるべき姿 統合DBの 統合 の メリット 同じデータを利用するシステムを統合すると、データの重複がなくバッチ処理も効率的 必要により接続ノードをシステム毎に分割できるため独立性を担保できる 信頼性・可用性が高いアーキテクチャのため複数業務のDBの統合が可能 システム間のデータ連携が不要 業務A APサーバー 業務B APサーバー 業務C APサーバー 業務D APサーバー Active Active Node Node Active Active Node Node Active Active Node Node Active Active Node Node DBMS DBMS DBMS DBMS Cluster Cluster Cluster Cluster 業務E APサーバー 接続ノードを分けることで 相互影響を低減が可能 CF Node CFNode Node CF CF Node DBMS DBMS イメージ （サンプル） サンプル） DB設計においてアプリケーション特性に よって特殊な設計を必要としない。 業務エリアで統合するこ とで、個別システムでの バッチ作成負荷を低減 データ連携 DWHなど ・・・ ・構築負荷軽減 ・Disk共有による容量効率化 ・バックアップ等の運用構築負荷削減 統合DB 統合 DB 基盤 としての 利用 検討 統合DB DB基盤 基盤としての としての利用 利用が が検討できる 検討できる できる 統合DB基盤 DB基盤としての 基盤としての利用 としての利用が 利用が 検討できる 24 © 2011 IBM Corporation システム構成 [AIX] pureScaleサポート サポート機器 サポート機器 Server HCA 1 or 2 POWER 710 POWER 730 (*1) 枚まで搭載可能 HCA 2 POWER 720 POWER 740 POWER 750 枚以上搭載可能 POWER 770 POWER 780 POWER 795 Storage [IBM GPFSをサポートする サポートするStorage (*2) を使用した 使用したSAN接続] （GPFSに加え、SCSI-3 Persistent Reserveを対応することが強く推奨される） DS3400 Others DS4700 DS3950 DS5020 InfiniBand HCA card IBM GX++ HCA Card for InfiniBand GX Dual-port 12x Channel Attach - DDR InfiniBand Channel Adapter POWER6 550 : (Feature Code 5609) POWER6 595 : (Feature Code 1816) POWER7 750 : (Feature Code 5609) POWER7 770 or POWER7 780 : (Feature Code 1808) DS5100 DS5300 DS8100 DS8300 DS8700 InfiniBand Network switch IBM 7874-024 - 1U, 24-port 4x DDR InfiniBand Edge Switch IBM 7874-040 - 4U, 48-port 4x DDR InfiniBand Director Switch IBM 7874-120 - 7U, 120-port 4x DDR InfiniBand Director Switch IBM 7874-240 - 14U, 240-port 4x DDR InfiniBand Director Switch InfiniBand cable InfiniBand cables - 12x to 4x Channel conversion cable (Feature Code 1854) ->1865,64 (*1) http://publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.sd.doc/doc/r0054850.html (*2) http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=/com.ibm.cluster.gpfs.doc/gpfs_faqs/gpfsclustersfaq.html. 25 © 2011 IBM Corporation システム構成 [AIX] サンプル構成 サンプル構成 （本番環境例） 本番環境例） メンバーx4＋ に メンバー 独立 した 配置 サーバー メンバーx4＋ ＋CFx2 CFx2 を を独立した 独立した したLPARに に配置し 配置し した た、、２ ２サーバー構成 サーバー構成 構成 メンバー ＋ 独立したLPARに した 配置し サーバー構成 スイッチ・ を スイッチ アダプタ などを 二重 スイッチ・ アダプタなどを などを二重 二重化 化し し、、SPOFを SPOFを を排除 排除 スイッチ・・アダプタなどを アダプタなどを二重 などを二重化 二重化 必要に 追加・ 必要 じて メンバー 追加 メンバー 追加 必要に に応 応じて各 じて各 各メンバーの メンバーの のCPU追加 CPU追加 追加・ メンバー追加 追加を を実施可能 実施可能 必要に じて各 メンバーの 追加・・メンバー追加 メンバー追加を 追加を Clients HMC MemberとCFを別LPARで構成 CF 1-2core CF 1-2core Member 1-4core Member 1-4core Member 1-4core Member 1-4core Power 770 Power 770 SAN24B-4 DS5020 26 7874-024 HMC-LPAR管理 管理LAN 管理 pureScale+GPFS LAN InfiniBand (Inter Connect) Fiber Channel (SAN) © 2011 IBM Corporation システム構成 [AIX] サンプル構成 サンプル構成 （テスト環境例 テスト環境例） 環境例） pureScaleを を 稼働 させる ための pureScaleを を稼働させる 稼働させる させるための ための最小構成 最小構成 稼働させるための させるための最小構成 ための最小構成 メンバーx2＋ を サーバー構成 メンバー 独立 した 構成 サーバー メンバーx2＋ ＋CFx2 CFx2 を を独立した 独立した したLPARを を構成し 構成し した た、、2サーバー 2サーバー サーバー構成 構成 メンバー ＋ 独立したLPARを した 構成し サーバー構成 スイッチの の スイッチ 二重化 など 排除 考慮 スイッチの の二重化など 二重化など など、 SPOFの の排除は 排除は は考慮されていない 考慮されていない されていない スイッチの 二重化など、 など、、SPOFの 排除は 考慮されていない Clients HMC MemberとCFを別LPARで構成 CF 1core CF 1-2core Member 1-4core Member 1-4core Power 720 Power 720 SAN24B-4 DS5300 27 7874-024 HMC-LPAR管理 管理LAN 管理 pureScale+GPFS LAN InfiniBand (Inter Connect) Fiber Channel (SAN) © 2011 IBM Corporation システム構成 [Linux] pureScaleサポート サポート機器 サポート機器 （サポート対象を順次追加予定） (*1) Server OS - SUSE Linux Enterprise Server (SLES) 10 Service Pack (SP) 3, kernel 2.6.16.60-0.66.1-smp and the matching kernel source System x3650 M3 System x3690 X5 System x3850 X5 Storage [IBM GPFSをサポートする サポートするStorage (*2) を使用した 使用したSAN接続] （GPFSに加え、ノード障害検知を高速に行うために、SCSI-3 Persistent Reserveをサポートする機種が強く推奨される） DS3400 InterConnect Network DS5020 InfiniBand Network InfiniBand Adapter - MHQH29B-XTR : Mellanox IB Card, ConnectX-2 VPI adapter, dual-port QSFP, IB 40GBs （Adapterの仮想化は 仮想化は未サポート） サポート） 10G Ethernet （SUSEのみ） のみ） Network Adapter - MNPH29C-XTR : Mellanox 10 Gigabit Ethernet network card, IBM81Y1540 ConnectX-2 EN Dual-port 10GbEx8 PCI-E 2.0 Adapter または 28 DS5100 DS5300 InfiniBand Switch -MIS5030Q-1SFC : Mellanox IB Switch (36 ports), InfiniScale IV QDR InfiniBand Switch, 36 QSFP ports. - FabricIT EFM - InfiniBand Fabric Management InfiniBand Cable MCC4Q30C-002 MCD4Q26C-005 MFP4R12CB-010 Network Switch, Cable - Priority-based flow control（IEEE 802.1Qbb）をサ ポートする ポートする10GigE Network SwitchおよびCable (*1) http://publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.sd.doc/doc/r0057441.html© 2011 IBM Corporation (*2) http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=/com.ibm.cluster.gpfs.doc/gpfs_faqs/gpfsclustersfaq.html. よくある質問 よくある質問 (1) DB2 pureScaleの のライセンスはどの ライセンスはどのサーバー はどのサーバーに サーバーに課金されますか 課金されますか？ されますか？ – DB2メンバーのサーバーに、pureScaleのライセンスが課金されます。 – CFサーバーには、pureScaleのライセンスは課金されません。 DB2 pureScaleを を使用するために 使用するために必要 するために必要な 必要なライセンスは ライセンスは？ – DB2 Advanced Enterprise Server Edition + DB2 pureScale Feature – DB2 Enterprise Server Edition + DB2 pureScale Feature – DB2 Workgroup Server Edition （クラスターの全サーバーで合計4CPUソケットまで） – DB2 Database Enterprise Developer Edition DB2 pureScaleとは とは別 やTSAの の購入が とは別に、GPFSや 購入が必要ですか 必要ですか？ ですか？ – いいえ、必要ありません。 DB2 pureScaleにGPFSやTSAのライセンスおよびモジュールが含まれます。 DB2 pureScaleを導入するとGPFSやTSAが同時に導入されます。 DB2 pureScaleと と組み合わせて使用 の追加オプション わせて使用できる 使用できるDB2の できる 追加オプションは オプションは？ – DB2 Storage Optimization Feature (圧縮) – DB2 Advance Access Control Feature (LBAC) 29 © 2011 IBM Corporation よくある質問 よくある質問 (2) DB2 9.7の のOracle互換 互換モード と組み合わせて使用 互換モードは モードはpureScaleと わせて使用できますか 使用できますか？ できますか？ – Oracle互換モード（Oracle対応PL/SQL、SQL、トリガー、ファンクション、データ型など） はpureScaleと組み合わせて使用できます。 出荷時点の 出荷時点の制約は 制約は？ – 現時点で、以下機能はpureScaleと組合わせて使用できません。機能向上として今後随 時追加される予定です。 • • • • • • • • • 30 MDC（多次元クラスター表） テーブルパーティション（レンジパーティション） 差分/増分バックアップ、表スペースバックアップ オンラインでの表・索引の再編成（インプレース再編成） オンラインでのDB2のFix Pack適用 自動ストレージ以外のコンテナー（従来のSMS、DMSコンテナー） HADR [参考：災害対策としてレプリケーション機能が使用可能] フェデレーション機能（外部DBを透過的に見せる機能） DB2 Text Search / Net Search Extender / Spatial Extender © 2011 IBM Corporation
© Copyright 2024 ExpyDoc
