[D35] 今ミッション・クリティカル環境で求められるデータベース・クラスタリング技術とは？ by Kousuke Osaka
•
5 gefällt mir•3,008 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (10)
Mehr von Insight Technology, Inc.
Mehr von Insight Technology, Inc. (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
[D35] 今ミッション・クリティカル環境で求められるデータベース・クラスタリング技術とは？ by Kousuke Osaka
- 1. B37: 今ミッション・クリティカル環境で求められる データベース・クラスタリング技術とは？ 日本アイ・ビー・エム株式会社 ソフトウェア事業 ITスペシャリスト おさか こうすけ 苧阪 浩輔 1 © 2013 IBM Corporation
- 2. Please note ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反 映したものです。それらは情報提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導 や助言を意図したものではなく、またそのような結果を生むものでもありません。本講演資料に含まれている情報につい ては、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保 証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる 損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライ ヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規 定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結果を生むものでもありませ ん。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれら が使用可能であることを暗示するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場 機会またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将 来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含まれている内容 は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示する ことを意図したものでも、またそのような結果を生むものでもありません。 パフォーマンスは、管理された環境において 標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォー マンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処 理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで 述べられているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成 した結果の実例として示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があ ります。 IBM、IBM ロゴ、ibm.com、DB2、およびPureDataは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。 他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。 現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。 2 © 2013 IBM Corporation
- 3. アジェンダ 1. ミッション・クリティカル環境でのデータベース要件 • 事業継続のためのシステムリスク • 一般的なデータベース・クラスタリング技術 2. ミッション・クリティカル環境で真価を発揮するDBクラスタ • • 3 メインフレームから生まれた強固なクラスタリング技術 H/W,S/W(pureScale),サービスの全てがセットのPureData © 2013 IBM Corporation
- 4. 急激なトランザクション増加と求められる事業継続性 ローカル・データベースのグローバル展開 – 企業のグローバル展開や企業間の統合併 などにより、扱うデータやトランザクシ ョンが急激に増加 – ITインフラは急速な変化を必要とします 高い拡張性と可用性を実現可能なソリューションが必須 ゼロ・ダウンタイムでの事業継続ニーズ – インターネットの拡大によりサービス停止 は即ビジネス・ロス。機会損失のビジネス ・リスクは3年前の約5倍になりました。 – 止まらないグローバル化。夜間・休日のサ ービス停止は益々困難になりました。 4 © 2013 IBM Corporation
- 5. 1日を争うビジネスニーズ ビジネスへの変化の強さは企業のアドバンテージ ビジネスの変化にクイックに対応するITインフラが必 須です。ITインフラは常にオーバー・プロビジョニン グ可能なように構成し、予測を超えるトランザクショ ンを受けた場合でも品質を落とさないよう、サービス を継続する必要があります。 変化への柔軟な対応と、変化に対するリスク削減 アプリケーションの変更コストが高い – アプリケーション変更を伴う拡張は無い場合 に比べ、約10倍の作業時間が必要です。拡張 されたインフラにアプリケーションを最適に 変更したり、インフラのチューニングが必要 になります。 5 © 2013 IBM Corporation
- 6. 近年求められているデータベース要件 拡張性 スケーラビリティがない（サーバー追加しても。。） • 大規模データを扱うことの出来る機能 可用性 障害・メンテナンス時にリカバリーまでの間、停止を伴う • 集約されたデータを守る高い信頼性 効率性 ビジネスを徐々に広げるスモールスタートがなかなかできない • リソースを有効かつ動的に利用可能な機能 新しいデータベース・インフラ技術 6 © 2013 IBM Corporation
- 8. 一般的なDBMSで実現するクラスタ構成 • 一般的なアクティブ－スタンバイ構成 • HAクラスターSWによる障害 検知と待機系への引継ぎ • 障害切り替え時、スタンバイ 側はDBプロセス停止のため 、切り替えに時間がかかる シェアード・ナッシングでのアクティブ・ア クティブ構成 ・ ・ ・ ・ 8 シェアード・ナッシング 大規模DBの高速並列処理 高い拡張性 アクティブ-アクティブ構成 DBログ転送方式でのアクティブ – スタンバイ構成 ・ ログシッピングによるレプ リカのスタンバイ機へのDB 複製（同期/非同期/ディレ ード） ・障害切り替え時、スタンバ イ側はすでにDBは起動して おり、切り替えは比較的高 速 シェアード・ディスクでのアクティブ・ア クティブ構成 ・ シェアード・ディスク ・ 大規模OLTPに対する 連続可用性と拡張性 ・ アクティブ－アクティブ構成 © 2013 IBM Corporation
- 9. DB2 HA構成 アクティブ-スタンバイ構成 アプリケーション IP address HAクラスター・ソフトウェア （構成情報） HAクラスター・ソフトウェア （構成情報） •DB2インスタンスホームディレクトリー •データベースディレクトリー •表スペース •ログ 9 LOG Database crash recovery © 2013 IBM Corporation
- 10. DBログ転送方式でのアクティブ・スタンバイ構成(1/2) • ログ転送を元にしたデータレプリ ケーション機能 • 本番DBからスタンバイDBにサーバー のバッファー間でTCP/IP経由でのログ 転送 クライアント・リルート ｸﾗｲｱﾝﾄ • スタンバイDBではログを元にトランザ クションを適用 本番 DB サーバー • 万一の障害時に高速なフェールオー バー機能 • ストレージ領域、IPアドレスのフェール オーバー処理の必要なし 障害対策 大阪 東京 • 災害対策としてリモートサイト間にも対 応 • クライアント・リルートの機能と組み合 わせ可能 • パッチ適用時の停止時間を最小限 に抑える ログ転送 ｽﾀﾝﾊﾞｲ DB サーバー ｱﾌﾟﾘｹｰｼｮﾝ･ｻｰﾊﾞｰ ログ転送 本番 HTTP & App. サーバー 本番 DBサーバー ｽﾀﾝﾊﾞｲ ｽﾀﾝﾊﾞｲ DBサーバー HTTP & App. サーバー 災害対策としても有効 10 © 2013 IBM Corporation
- 11. DBログ転送方式でのアクティブ・スタンバイ構成(1/2) 1. 2. 3. 4. 5. クライアントからの接続 1 4 DB2エンジン 3 バッファ プール 2 6. 7. 7 代替の接続 (クライアント・リルート) 本番DB 5 リモートサイト DB2エンジン バッファ ログ バッファ HADR ﾊﾞｯﾌｧ TCP層 非同期 log writer TCP/IP バッファ プール 近同期 6 log reader ログ ログ 5 log reader 5 表 索引 ログ スタンバイDB バッファ 5 ※ データ更新処理を受け取る ログ･バッファに書き込む データ･バッファ上で更新処理 コミットを受け取る ログ・バッファの内容をディスクに書き込むと同時に TCPレイヤーにログ・ページを転送 （→7：非同期） スタンバイのHADRバッファへ書き込む （→6：近同期） ディスクに書き込む (→6：同期) 完了通知をプライマリに返す コミット終了をユーザーへ返す（同期） Replay Master Shredder Redo Master Redo Workers ※ 表 索引 ログ 同期 11 © 2013 IBM Corporation
- 12. シェアード・ナッシングでのアクティブ・アクティブ構成 シェアード・ナッシング アーキテクチャの特徴 • 各DBパーティションは、独立した処理エンジン、資源を保持しています 各DBパーティションが別々に処理エンジンを持つ データやログ、ロック、キャッシュなど全てを別々に管理 各DBパーティションが互いに影響を及さず、スケールアウトによる高い性能、拡張性を実現可能 • アプリケーションからは１つのデータベースとしてアクセス 各DBパーティションに処理要求 を配信し、結果をマージ SELECT * FROM T1 DBパーティション コーディネーター・プロセス ワーカー・プロセス データ ログ データ ログ データ ログ データ ログ データベース 12 © 2013 IBM Corporation
- 13. 一般的なデータベース・クラスタ技術 適用エリア 中～大規模 OLTP/DWH 中規模OLTP/DWH 大規模DWH 構成 DB2 HADR DB2 HA構成 DB2 Database Partitioning アーキテク チャー シンプルな構成。高い可用性とパ フォーマンスを確保。ログ転送のみによ る二重化のためパフォーマンス劣化が 少ない シンプルな基本構成。 概要 耐障害性 ○テークオーバー中は全体停止。 復旧時間目標は数十秒から1分程度 △テークオーバー中は全体停止。 復旧時間目標は1分以上 ○N-1/Nのデータに連続アクセス可。 障害サーバーの復旧時間目標は1 分前後 24365対応 ◎片系ずつのメンテナンスが可能。 テークオーバー処理が高速 ○片系ずつのメンテナンスが可能だ が、テークオーバーの考慮が必要 ○片系ずつのメンテナンスが可能だ が、テークオーバーの考慮が必要 スケーラビリ ティ ○スケールアップ ○スケールアップ ◎スケールアウト・スケールアップ パフォーマン ス 13 DBログ転送による物理レプリケーション アクティブ-準アクティブ型 ◎シンプルにパフォーマンスを向上 ◎シンプルにパフォーマンスを向上 ○ノード間通信削減を考慮した設 計が必要 通常アクティブ-スタンバイ型 シェアード・ナッシングでの アクティブ-アクティブ型 大量データの分析処理やロード処 理に対して極めて高いパフォーマンス を提供 © 2013 IBM Corporation
- 14. pureScale開発背景 スマート(理想的)なデータベースとは 過去のミッションクリティカルなシステムにおけるデータベースの課題 シェアードナッシング型DB スケーラビリティがない 単に拡張性を求めるならシェアードナッシング型データベースが良いが、アプ リ開発が難しい。 シェアードデータ型DB シェアードディスク型はアプリ開発は容易だが、拡張性が低い。 障害に弱い 障害は起きるものだが、システムは障害によって止めてはいけない。 しかし、データベースは機能上リカバリが必要となり、システムが大規模にな るほど停止時間が大きくなる。 効率性が低い 拡張性がなくかつ止まるデータベースは、ハードウェアを増強して回避するこ とになる。 その結果、ハードウェアコスト・ソフトウェアライセンスコスト・保守コストが高く なる。 スマート（理想的）なデータベースサーバとは スケーラビリティがある 障害に強い（可用性が高い） 効率性が高い 14 © 2013 IBM Corporation
- 15. pureScale開発背景 pureScaleは何をモデルに？ DB2 for z/OSデータシェア 他社の尊敬を集めるアーキテクチャーがモデル • スケーラビリティと高可用性におけるゴールド・スタンダードとして、 だれもがDB2 for z/OS を認めています。 Oracle社のCEO ラリー・エリソン 理由 「わたしは、いろいろなデータベースをけなしている。ただし、メインフ レーム版のDB2を除いて。 メインフレーム版のDB2は、第一級の技術だ。」 – z/OS全体でカップリング・ファシリティ(CF)を使用 • ロックとキャッシュの集中管理により、優れたスケーラビリティと可用性を実現 pureScaleはソフトウェア・テクノロジーでCFを実装 15 © 2013 IBM Corporation
- 16. pureScaleの全体構成 クライアント(APサーバー) - どのサーバにも接続可能、一つのデータベースとして利用 - 自動ロードバランシングを実現 クライアント （APサーバ) シングル・データベース・ビュー 正 DB2エンジン（メンバー）はそれぞれのノードで稼動 副 CS – メンバー間でデータベースを共有し一貫性を保持 CS CF CF CF (キャッシングファシリティ) – Member CS Member Member CS CS Member CS ロックと更新ページをメモリ上に集中管理しボトルネック を軽減、二重化し可用性を確保 高速なノード間通信 – RDMAノード間通信を活用 (Infiniband) 他ノードのメモリを直接活用できる仕組み ノード間通信 クラスター・サービス – 障害検知, 自動リカバリー Data データシェアリング・アーキテクチャー – 16 データベースへの共有アクセス © 2013 IBM Corporation
- 17. 高い拡張性の理由 CFによるロックとキャッシュの一元管理 他DBクラスターの場 合 課題：各サーバーでロックとキャッシュ を分散管理 pureScaleの場合 解決策：CFでロックとキャッシュを一元 管理 – データは各サーバーに論理分割され、 各データのマスターサーバーがロック とキャッシュを分散管理 – データを各サーバーに論理分割せず、 CFがロックとキャッシュを一元管理 – マスターでないデータへのアクセスに は、サーバー間通信量が増えボトル ネックとなりやすい – 全てのデータが全てのサーバーから等 しくアクセス可能で、サーバー間通信 量が少なくボトルネックとなりにくい – パーティショニングを行い、通信量を 低減 – パーティショニングの必要なし サーバー 1 サーバー 2 サーバー 3 サーバー 1 サーバー 2 サーバー 3 CF サーバー 1 にマスターさ れるデータ 17 サーバー 2 にマスターさ れるデータ サーバー 3 にマスターさ れるデータ © 2013 IBM Corporation
- 18. 国内他社検証 pureScale 検証結果 （スケーラビリティ） pureScaleと他社クラスターに、ノード追加した場合のスケーラビリティの性能検証結果です。 B社テスト 他社 DB tps DB CPU% pureScale throughput 400 100 A社テスト 300 75 242.5 200 100 50 82.2 CPU [%] transaction/sec 327.8 25 0 0 pureScale pureScale pureScale 1member 3member 5member 18 IBM Confidential © 2013 IBM Corporation
- 19. 障害に強い理由 障害からの即時復旧 pureScaleの設計方針は、①障害範囲を極小化し、②全面復旧までの時間を短縮すること。 pureScale の設計の要 障害範囲の極小化 DB2 DB2 DB2 DB2 – 障害サーバー以外はアクセスを継続 • 障害サーバーへの接続は稼動中のサーバーに再 分配 – 障害サーバーが更新中のデータ以外は全面的 にアクセス可能 Log CF 19 Log Log CF データ データベースサーバーの障害 利用できるデータの割合(%) 全面復旧までの時間を短縮 – 障害が発生したサーバーで実行中のトランザク ションも、問題の検知も含めて短時間で復旧さ せることが目標 Log 回復中にはインフライトデータののみをロック 100 50 Time (~seconds) © 2013 IBM Corporation
- 20. 国内他社検証 pureScale 障害対策 検証結果 pureScaleと他社クラスターの、ノード障害時の連続稼働テストの結果です。 pureScale 全体停止することなく業務を継続 他社DB 全体停止時間が発生 20 IBM Confidential © 2013 IBM Corporation
- 21. 高い効率性の理由 透過性なワークロード・バランスの実現 • サーバーの負荷情報を元に自動ワークロードバランスを実現 • 接続単位・トランザクション単位のロードバランス • 全メンバーの負荷情報を定期的にクライアントに通知 • 次の接続を負荷が最小のメンバーに自動転送 クライアント 21 クライアント © 2013 IBM Corporation
- 23. 一般的なデータベース・クラスタ技術 適用エリア 大規模OLTP 中～大規模 OLTP/DWH 中規模OLTP/DWH 大規模DWH 構成 DB2 pureScale DB2 HADR DB2 HA構成 DB2 Database Partitioning シェアード・ディスク型 アクティブ-アクティブ型 DBログ転送による物理レプリケーション アクティブ-準アクティブ型 極めて高い可用性と拡張性を提 供。メインフレームのCFのアーキテク チャーをSWの機能で実現 シンプルな構成。高い可用性とパ フォーマンスを確保。ログ転送のみによ る二重化のためパフォーマンス劣化が 少ない 耐障害性 ◎更新中のページ以外のデータに 連続アクセス可。 全体の復旧時間目標は数十秒 ○テークオーバー中は全体停止。 復旧時間目標は数十秒から1分程 度 △テークオーバー中は全体停止。 復旧時間目標は1分以上 ○N-1/Nのデータに連続アクセス可。 障害サーバーの復旧時間目標は1 分前後 24365t対応 ◎片系ずつのメンテナンスと連続ア クセスが可能 ◎片系ずつのメンテナンスが可能。 テークオーバー処理が高速 ○片系ずつのメンテナンスが可能だ が、テークオーバーの考慮が必要 ○片系ずつのメンテナンスが可能だ が、テークオーバーの考慮が必要 スケーラビリ ティ ◎スケールアウト・スケールアップ ○スケールアップ ○スケールアップ ◎スケールアウト・スケールアップ パフォーマンス ○複数メンバーによる更新を考慮 した設計が必要 ◎シンプルにパフォーマンスを向上 ◎シンプルにパフォーマンスを向上 ○ノード間通信削減を考慮した設 計が必要 アーキテク チャー 概要 23 通常アクティブ-スタンバイ型 シンプルな構成。高いパフォーマンス を確保。 シェアード・ナッシング型 アクティブ-アクティブ型 大量データの分析処理やロード処 理に対して極めて高いパフォーマンス を提供 © 2013 IBM Corporation
- 24. 2012年4月、IBMは新しい製品ファミリーであるエキスパート・インテグレーテッド・ システムを発表 専門家の知見を実装した、クラウド用に構築されたシステム 専門家の 知見を実装 設計段階から 最適に統合 専門家の持つ 高度な知見を実装し 自動化 ハードウェアとソフトウェアを 徹底的に統合、チューニング ワークロードに合わせて 最適化されたシステムが すぐに利用可能 インフラストラクチャー・ パターンから アプリケーション・パターン まで シンプルなエクスペリエンスを実現 IT ライフサイクルを通じて各種作業の煩雑性を軽減 システム全体の統合管理と、最適化されたソリューションに よるオープンで幅広いエコシステムを実現 24 © 2013 IBM Corporation © 2013 IBM Corporation
- 25. PureData for Transactions(TX) の特徴 PureData for TX は、以下を集約した データベース・プラットフォームです。 ①PureFlexテクノロジー ②DB2 pureScale テクノロジー ③エキスパートの知見 統合 100のデータベースをシングルシステムに統合し、リ ソースを共有しながら性能とコストを最適化 最適化 HWとSWの設計、構成を事例と知見を元に最適化 迅速化 DB構築までを1時間以内に迅速化し、サービス提供 までの時間を削減 + + ➙ 25 © 2013 IBM Corporation
- 26. よりシンプルに、より速く、より低コストなシステムを実現するPureSystems 現在の課題: 汎用コンポーネントのチューニングに費やす時間と労力が増大 設計 / 導入 管理 / 保守 汎用 コンポーネント カスタム・ビルド・ システム ソリューション: IT プロジェクトのライフサイクル全体を簡略化 リードタイム、コスト、およびリスクを削減 設計 デプロイ 管理 保守 エキスパート・ インテグレーテッド・ システム 26 © 2013 IBM Corporation
- 27. ハードウェア構成 TOR ネットワークスイッチ V7000 Storage Flex System シャーシ 外部へのネットワーク Dual 10Gb Ethernet Switches HDDとSSDを バランスよく活用（ SSD:HDD=1:3) 計算ノード （Compute Node） PureSystem™ Manager © 2013 IBM Corporation
- 28. PureData for TXの3つのモデルとキャパシティ PureData for TXには3つのモデル(Small, Medium, Large)があり、段階拡張が可能です。 Upgrade 構成 Upgrade Small Medium Large (¼ Rack) (½ Rack) (Full Rack) ブレード(計算ノード)の数 (16core / ノード) 6 12 24 CPU Cores 96 192 384 1.5 TB 3.1 TB 6.1 TB 1 2 4 1 2 4 18.6 TB 37.2 TB 74.4 TB 4.8 TB 32.0 TB 9.6 TB 64.0 TB 19.2 TB 128.0 TB 1 (10) 3 (30) 6 (60) Memory V7000 Storage Unit (each unit has: 18 x 900GB HDD, 6 x 400 GB SSD) V7000 Storage Expansion (each unit has: 18 x 900GB HDD, 6 x 400 GB SSD) ストレージキャパシティ Raw SSD Storage Raw HDD Storage 最大インスタンス数 (DB数) ※1インスタンス4ノード以上とする場合 28 ** IBM Internal Use Only ** © 2013 IBM Corporation
- 29. PureData for TX 構築作業の流れ 見積り、サイジング HWの搬入、結線 OSの設計、導入 ストレージの設計、構築 HA構成(DB2 pureScale) インスタンスの作成 データベースの作成 計算ノード数以外の構成は決定済みのため、キーとなる要素（インスタンス数、 DB数、CPU 、データ量）を充足するサイズを選択するのみ 設計、構成済みで変更の余地無し 最小限の設計ドキュメント インスタンスとデータベースはコンソール画面の 操作で作成 パラメータはOLTPワークロードに最適化済みだ が、変更も可能 PDTXが提供する運用機能の、お客様運用への適合性について評 価が必要 アプライアンスとして機能が検証済みのため、障害テストなどデータ ベース・サーバとしての単体テストは大幅に軽減される。システム全 体として実施する結合テスト以降はこれまでと同様 パラメータの設計、変更 運用設計、構築 表スペースの作成 データベース・オブジェクトの作成 以降は通常のDB2と同様に実施 する 表、索引の作成 テスト 権限の設定 PDTXでは不要な作業項目 PDTXで軽減される作業項目 データの投入 29 PDTXでも変わらない作業項目 © 2013 IBM Corporation
- 30. まとめ ミッション・クリティカル環境に耐えうるデータベース基盤に求められる要件 • （拡張性）拡張性に優れ、ユーザーやデータの増加に柔軟に対応 • （可用性）集約されたデータを守る高い可用性と計画停止時間を最小限にする オンライン・メンテナンス • （効率性）多様なトランザクションに対応可能な、 ワークロード・バランスによる、効率的なリソース配分 • pureScaleはじめ、様々なRDBMSのクラスタ技術を組み合わせて、適材適所 のアーキテクチャ適応が重要（全てpureScaleであればよいわけではない） • H/W, S/W(pureScale), サービス全て込み込みのPureDataの登場 • クラウド基盤に耐えうる拡張性、可用性そして効率性 30 © 2013 IBM Corporation
- 31. 31 © 2013 IBM Corporation