© 2013 IBM Corporation

日本アイ・ビー・エム株式会社 ソフトウェア事業 ITスペシャリスト

苧阪 浩輔

B37: 今ミッション・クリティカル環境で求められる データベース・クラスタリング技術とは？

おさか こうすけ

1

© 2013 IBM Corporation

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

アジェンダ

1. ミッション・クリティカル環境でのデータベース要件

• 事業継続のためのシステムリスク

• 一般的なデータベース・クラスタリング技術

2. ミッション・クリティカル環境で真価を発揮するDBクラスタ

• メインフレームから生まれた強固なクラスタリング技術

• H/W,S/W(pureScale),サービスの全てがセットのPureData

3

© 2013 IBM Corporation

高い拡張性と可用性を実現可能なソリューションが必須

急激なトランザクション増加と求められる事業継続性

ゼロ・ダウンタイムでの事業継続ニーズ – インターネットの拡大によりサービス停止

は即ビジネス・ロス。機会損失のビジネス・リスクは3年前の約5倍になりました。

– 止まらないグローバル化。夜間・休日のサービス停止は益々困難になりました。

ローカル・データベースのグローバル展開 – 企業のグローバル展開や企業間の統合併

などにより、扱うデータやトランザクションが急激に増加

– ITインフラは急速な変化を必要とします

4

© 2013 IBM Corporation

1日を争うビジネスニーズ

アプリケーションの変更コストが高い – アプリケーション変更を伴う拡張は無い場合

に比べ、約10倍の作業時間が必要です。拡張されたインフラにアプリケーションを最適に変更したり、インフラのチューニングが必要になります。

ビジネスへの変化の強さは企業のアドバンテージ ビジネスの変化にクイックに対応するITインフラが必須です。ITインフラは常にオーバー・プロビジョニング可能なように構成し、予測を超えるトランザクションを受けた場合でも品質を落とさないよう、サービスを継続する必要があります。

変化への柔軟な対応と、変化に対するリスク削減

5

© 2013 IBM Corporation

近年求められているデータベース要件

拡張性

• 大規模データを扱うことの出来る機能

可用性

• 集約されたデータを守る高い信頼性

効率性

• リソースを有効かつ動的に利用可能な機能

スケーラビリティがない（サーバー追加しても。。）

ビジネスを徐々に広げるスモールスタートがなかなかできない

障害・メンテナンス時にリカバリーまでの間、停止を伴う

6

新しいデータベース・インフラ技術

© 2013 IBM Corporation

事業継続のためのシステムリスクの切り分け

計画停止

計画外停止

障害

災害

処理増加

人為ミス

障害対策 一部コンポーネントの障害発生時

にも、業務処理を持続可能とする

システム

災害対策 災害発生時に業務処理の速やか な

回復を可能とするシステム

防止・復旧 人的ミスを防止し、ミス発生時にも

迅速に対応できるシステム

オペレーション対応 変更・保守・バックアップ処理時にも

業務処理継続を可能とするシステム

キャパシティ管理 想定外のトランザクション量の

急増でも停止させないシステム

大容量データの管理

可用構成（クラスタ構成） HA構成

シェアードディスク

レプリケーション

ディザスタ・リカバリ構成

DBログ転送

論理レプリケーション

ストレージ遠隔コピー機能

オートノミック機能 監査機能

DB2ローリングアップグレード

データロード、パーティション表

MDCロールアウト

スケールアップ（リソース増強） HWの仮想化機能との連携 ワークロード管理 パフォーマンス管理

7

事業停止

© 2013 IBM Corporation

一般的なDBMSで実現するクラスタ構成

• 一般的なアクティブ－スタンバイ構成

• HAクラスターSWによる障害検知と待機系への引継ぎ

• 障害切り替え時、スタンバイ側はDBプロセス停止のため、切り替えに時間がかかる

DBログ転送方式でのアクティブ – スタンバイ構成

シェアード・ナッシングでのアクティブ・アクティブ構成

・ ログシッピングによるレプリカのスタンバイ機へのDB複製（同期/非同期/ディレード）

・障害切り替え時、スタンバイ側はすでにDBは起動しており、切り替えは比較的高速

・ シェアード・ナッシング

・ 大規模DBの高速並列処理

・ 高い拡張性

・ アクティブ-アクティブ構成

シェアード・ディスクでのアクティブ・アクティブ構成

・ シェアード・ディスク

・ 大規模OLTPに対する

連続可用性と拡張性

・ アクティブ－アクティブ構成

8

© 2013 IBM Corporation

•DB2インスタンスホームディレクトリー

•データベースディレクトリー

•表スペース

•ログ

DB2 HA構成 アクティブ-スタンバイ構成

アプリケーション

HAクラスター・ソフトウェア

（構成情報）

LOG

Database

crash

recovery

HAクラスター・ソフトウェア

（構成情報）

IP address

9

© 2013 IBM Corporation

DBログ転送方式でのアクティブ・スタンバイ構成(1/2)

• ログ転送を元にしたデータレプリケーション機能

• 本番DBからスタンバイDBにサーバーのバッファー間でTCP/IP経由でのログ転送

• スタンバイDBではログを元にトランザクションを適用

• 万一の障害時に高速なフェールオーバー機能

• ストレージ領域、IPアドレスのフェールオーバー処理の必要なし

• 災害対策としてリモートサイト間にも対応

• クライアント・リルートの機能と組み合わせ可能

• パッチ適用時の停止時間を最小限に抑える

災害対策としても有効

障害対策

ログ転送

本番

DBサーバー

ｽﾀﾝﾊﾞｲ

DBサーバー 本番

HTTP & App. サーバー

ｽﾀﾝﾊﾞｲ

HTTP & App.

サーバー

東京 大阪

ｸﾗｲｱﾝﾄ

ログ転送

本番 DB

サーバー

ｽﾀﾝﾊﾞｲ DB

サーバー

ｱﾌﾟﾘｹｰｼｮﾝ･ｻｰﾊﾞｰ

クライアント・リルート

10

© 2013 IBM Corporation

バッファ

表 索引

表 索引

ログ ログ ログ ログ

バッファ プール

ログ バッファ

TCP層

log writer log reader

HADR ﾊﾞｯﾌｧ

log reader

バッファ

DB2エンジン DB2エンジン

TCP/IP

本番DB リモートサイト

クライアントからの接続

代替の接続 (クライアント・リルート)

1

2

4

5

5

6

7

3

5

5

※

※

同期

近同期 非同期

1. データ更新処理を受け取る 2. ログ･バッファに書き込む 3. データ･バッファ上で更新処理 4. コミットを受け取る 5. ログ・バッファの内容をディスクに書き込むと同時に

TCPレイヤーにログ・ページを転送 （→7：非同期） スタンバイのHADRバッファへ書き込む （→6：近同期） ディスクに書き込む (→6：同期)

6. 完了通知をプライマリに返す 7. コミット終了をユーザーへ返す（同期）

バッファ プール

Replay Master

Shredder Redo Master Redo Workers

スタンバイDB

11

DBログ転送方式でのアクティブ・スタンバイ構成(1/2)

© 2013 IBM Corporation

シェアード・ナッシング アーキテクチャの特徴

• 各DBパーティションは、独立した処理エンジン、資源を保持しています 各DBパーティションが別々に処理エンジンを持つ

データやログ、ロック、キャッシュなど全てを別々に管理

各DBパーティションが互いに影響を及さず、スケールアウトによる高い性能、拡張性を実現可能

• アプリケーションからは１つのデータベースとしてアクセス

データ ログ データ ログ データ ログ データ ログ

SELECT * FROM T1

各DBパーティションに処理要求を配信し、結果をマージ

コーディネーター・プロセス

ワーカー・プロセス

データベース

DBパーティション

シェアード・ナッシングでのアクティブ・アクティブ構成

12

© 2013 IBM Corporation

一般的なデータベース・クラスタ技術

適用エリア 中～大規模 OLTP/DWH 中規模OLTP/DWH 大規模DWH

構成 DB2 HADR DB2 HA構成 DB2 Database Partitioning

アーキテクチャー

DBログ転送による物理レプリケーション アクティブ-準アクティブ型

通常アクティブ-スタンバイ型 シェアード・ナッシングでの アクティブ-アクティブ型

概要

シンプルな構成。高い可用性とパフォーマンスを確保。ログ転送のみによる二重化のためパフォーマンス劣化が少ない

シンプルな基本構成。 大量データの分析処理やロード処理に対して極めて高いパフォーマンスを提供

耐障害性 ○テークオーバー中は全体停止。 復旧時間目標は数十秒から1分程度

△テークオーバー中は全体停止。 復旧時間目標は1分以上

○N-1/Nのデータに連続アクセス可。 障害サーバーの復旧時間目標は1分前後

24365対応 ◎片系ずつのメンテナンスが可能。 テークオーバー処理が高速

○片系ずつのメンテナンスが可能だが、テークオーバーの考慮が必要

○片系ずつのメンテナンスが可能だが、テークオーバーの考慮が必要

スケーラビリティ

○スケールアップ ○スケールアップ ◎スケールアウト・スケールアップ

パフォーマンス

◎シンプルにパフォーマンスを向上 ◎シンプルにパフォーマンスを向上 ○ノード間通信削減を考慮した設計が必要

13

© 2013 IBM Corporation

過去のミッションクリティカルなシステムにおけるデータベースの課題

スケーラビリティがない

単に拡張性を求めるならシェアードナッシング型データベースが良いが、アプリ開発が難しい。

シェアードディスク型はアプリ開発は容易だが、拡張性が低い。

障害に弱い

障害は起きるものだが、システムは障害によって止めてはいけない。

しかし、データベースは機能上リカバリが必要となり、システムが大規模になるほど停止時間が大きくなる。

効率性が低い

拡張性がなくかつ止まるデータベースは、ハードウェアを増強して回避することになる。

その結果、ハードウェアコスト・ソフトウェアライセンスコスト・保守コストが高くなる。

スマート（理想的）なデータベースサーバとは

スケーラビリティがある

障害に強い（可用性が高い）

効率性が高い

シェアードナッシング型DB

シェアードデータ型DB

pureScale開発背景 スマート(理想的)なデータベースとは

14

© 2013 IBM Corporation

DB2 for z/OSデータシェア 他社の尊敬を集めるアーキテクチャーがモデル

• スケーラビリティと高可用性におけるゴールド・スタンダードとして、 だれもがDB2 for z/OS を認めています。

Oracle社のCEO ラリー・エリソン

「わたしは、いろいろなデータベースをけなしている。ただし、メインフレーム版のDB2を除いて。 メインフレーム版のDB2は、第一級の技術だ。」

理由

– z/OS全体でカップリング・ファシリティ(CF)を使用

• ロックとキャッシュの集中管理により、優れたスケーラビリティと可用性を実現

pureScaleはソフトウェア・テクノロジーでCFを実装

pureScale開発背景 pureScaleは何をモデルに？

15

© 2013 IBM Corporation

ノード間通信

シングル・データベース・ビュー

クライアント （APサーバ)

Data

CS CS CS CS

CS

CS

Member

CF

正 DB2エンジン（メンバー）はそれぞれのノードで稼動

– メンバー間でデータベースを共有し一貫性を保持

データシェアリング・アーキテクチャー

– データベースへの共有アクセス

Member Member Member

CS

CF

副

クラスター・サービス

– 障害検知, 自動リカバリー

CF (キャッシングファシリティ)

– ロックと更新ページをメモリ上に集中管理しボトルネックを軽減、二重化し可用性を確保

高速なノード間通信

– RDMAノード間通信を活用 (Infiniband) 他ノードのメモリを直接活用できる仕組み

クライアント(APサーバー) - どのサーバにも接続可能、一つのデータベースとして利用 - 自動ロードバランシングを実現

pureScaleの全体構成

16

© 2013 IBM Corporation 17

高い拡張性の理由 CFによるロックとキャッシュの一元管理

解決策：CFでロックとキャッシュを一元管理

– データを各サーバーに論理分割せず、CFがロックとキャッシュを一元管理

– 全てのデータが全てのサーバーから等しくアクセス可能で、サーバー間通信量が少なくボトルネックとなりにくい

– パーティショニングの必要なし

課題：各サーバーでロックとキャッシュを分散管理

– データは各サーバーに論理分割され、各データのマスターサーバーがロックとキャッシュを分散管理

– マスターでないデータへのアクセスには、サーバー間通信量が増えボトルネックとなりやすい

– パーティショニングを行い、通信量を低減

他DBクラスターの場合

pureScaleの場合

サーバー 1 にマスターされるデータ

サーバー 3 サーバー 2 サーバー 1

サーバー 2 にマスターされるデータ

サーバー 3 にマスターされるデータ

サーバー 3 サーバー 2 サーバー 1

CF

© 2013 IBM Corporation

他社DB

国内他社検証 pureScale 検証結果 （スケーラビリティ）

pureScale throughput

82.2

242.5

327.8

0

100

200

300

400

pureScale

1member

pureScale

3member

pureScale

5member

transaction/sec

0

25

50

75

100

CPU [%]

tps

DB CPU%

A社テスト

B社テスト

IBM Confidential

pureScaleと他社クラスターに、ノード追加した場合のスケーラビリティの性能検証結果です。

18

© 2013 IBM Corporation

障害に強い理由 障害からの即時復旧

pureScale の設計の要

障害範囲の極小化

– 障害サーバー以外はアクセスを継続

• 障害サーバーへの接続は稼動中のサーバーに再分配

– 障害サーバーが更新中のデータ以外は全面的にアクセス可能

全面復旧までの時間を短縮

– 障害が発生したサーバーで実行中のトランザクションも、問題の検知も含めて短時間で復旧させることが目標

Log

データ

Log

Log

Log

CF

DB2 DB2 DB2 DB2

CF

Time (~seconds)

利用できるデータの割合

(%) 回復中にはインフライトデータののみをロック

データベースサーバーの障害

100

50

pureScaleの設計方針は、①障害範囲を極小化し、②全面復旧までの時間を短縮すること。

19

© 2013 IBM Corporation

他社DB

国内他社検証 pureScale 障害対策 検証結果

IBM Confidential

pureScaleと他社クラスターの、ノード障害時の連続稼働テストの結果です。

pureScale

全体停止することなく業務を継続

全体停止時間が発生

20

© 2013 IBM Corporation 21

• サーバーの負荷情報を元に自動ワークロードバランスを実現 • 接続単位・トランザクション単位のロードバランス

• 全メンバーの負荷情報を定期的にクライアントに通知

• 次の接続を負荷が最小のメンバーに自動転送

クライアント

クライアント

高い効率性の理由 透過性なワークロード・バランスの実現

© 2013 IBM Corporation

DB2 pureScale 他社クラスタ

構成特徴 ロック情報と更新データをCFで一元管理 サーバー間通信にRDMAを採用(約10マイクロ秒)

ロック情報と更新データを各サーバーで分散管理 サーバー間通信にUDP/ソケットプロトコルを採用

①スケーラビリティ スケーラビリティが高い

データアクセス競合がある場合にもスケーラビリティあり

スケーラビリティが低い

データアクセス競合がある場合よりスケーラビリティが落ちる

②可用性 ノード障害時にも全面停止にならない ノード障害時に全面停止時間がある

③効率性 ワークロードバランシング性能が高い

ノード追加に際してアプリの変更見直しも不要

ノードごとにデータ分割設定が推奨

そのためノード追加に際してアプリの手直しいが必要

国内他社検証 pureScaleと他社クラスタの違い

node1 node2 node3 node4 CF2

更新 ﾃﾞｰﾀ

ﾛｯｸ

CF1

更新 ﾃﾞｰﾀ

ﾛｯｸ

ノード間通信（RDMA）

FC接続

node1

更新 ﾃﾞｰﾀ

ﾛｯｸ

node2

更新 ﾃﾞｰﾀ

ﾛｯｸ

node3

更新 ﾃﾞｰﾀ

ﾛｯｸ

node4

更新 ﾃﾞｰﾀ

ﾛｯｸ

ノード間通信（TCPIP）

FC接続

22

© 2013 IBM Corporation

一般的なデータベース・クラスタ技術

適用エリア 大規模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

設計段階から 最適に統合 ハードウェアとソフトウェアを 徹底的に統合、チューニング ワークロードに合わせて 最適化されたシステムが すぐに利用可能

専門家の 知見を実装 専門家の持つ

高度な知見を実装し 自動化

インフラストラクチャー・ パターンから

アプリケーション・パターンまで

シンプルなエクスペリエンスを実現 IT ライフサイクルを通じて各種作業の煩雑性を軽減

システム全体の統合管理と、最適化されたソリューションによるオープンで幅広いエコシステムを実現

2012年4月、IBMは新しい製品ファミリーであるエキスパート・インテグレーテッド・ システムを発表

専門家の知見を実装した、クラウド用に構築されたシステム

© 2013 IBM Corporation 24

© 2013 IBM Corporation

PureData for Transactions(TX) の特徴

PureData for TX は、以下を集約したデータベース・プラットフォームです。

①PureFlexテクノロジー

②DB2 pureScale テクノロジー

③エキスパートの知見

+ + ➙

統合 100のデータベースをシングルシステムに統合し、リソースを共有しながら性能とコストを最適化

最適化 HWとSWの設計、構成を事例と知見を元に最適化

迅速化 DB構築までを1時間以内に迅速化し、サービス提供までの時間を削減

25

© 2013 IBM Corporation

エキスパート・ インテグレーテッド・

システム

汎用 コンポーネント

カスタム・ビルド・ システム

現在の課題: 汎用コンポーネントのチューニングに費やす時間と労力が増大

ソリューション: IT プロジェクトのライフサイクル全体を簡略化

リードタイム、コスト、およびリスクを削減

設計 / 導入 管理 / 保守

設計 管理 デプロイ 保守

よりシンプルに、より速く、より低コストなシステムを実現するPureSystems

26

© 2013 IBM Corporation

Flex System シャーシ

V7000 Storage

TOR ネットワークスイッチ

計算ノード

（Compute Node）

HDDとSSDを バランスよく活用（SSD:HDD=1:3)

外部へのネットワーク Dual 10Gb Ethernet Switches

PureSystem™ Manager

ハードウェア構成

© 2013 IBM Corporation

構成 Small (¼ Rack)

Medium (½ Rack)

Large (Full Rack)

ブレード(計算ノード)の数

(16core / ノード)

6 12 24

CPU Cores 96 192 384

Memory 1.5 TB 3.1 TB 6.1 TB

V7000 Storage Unit (each unit has: 18 x 900GB HDD, 6 x 400

GB SSD)

1 2 4

V7000 Storage Expansion (each unit has: 18 x 900GB HDD, 6 x 400

GB SSD)

1 2 4

ストレージキャパシティ Raw SSD Storage

Raw HDD Storage

18.6 TB 4.8 TB

32.0 TB

37.2 TB 9.6 TB

64.0 TB

74.4 TB 19.2 TB

128.0 TB

最大インスタンス数 (DB数) ※1インスタンス4ノード以上とする場合

1 (10)

3 (30)

6 (60)

Upgrade Upgrade

** IBM Internal Use Only **

PureData for TXの3つのモデルとキャパシティ

PureData for TXには3つのモデル(Small, Medium, Large)があり、段階拡張が可能です。

28

© 2013 IBM Corporation

PureData for TX 構築作業の流れ

HWの搬入、結線

OSの設計、導入

ストレージの設計、構築

HA構成(DB2 pureScale)

インスタンスの作成

データベースの作成

パラメータの設計、変更

運用設計、構築

テスト

設計、構成済みで変更の余地無し

最小限の設計ドキュメント

インスタンスとデータベースはコンソール画面の操作で作成

パラメータはOLTPワークロードに最適化済みだが、変更も可能

表スペースの作成

表、索引の作成

権限の設定

データの投入

PDTXでは不要な作業項目

PDTXで軽減される作業項目

PDTXでも変わらない作業項目

PDTXが提供する運用機能の、お客様運用への適合性について評価が必要

アプライアンスとして機能が検証済みのため、障害テストなどデータベース・サーバとしての単体テストは大幅に軽減される。システム全体として実施する結合テスト以降はこれまでと同様

データベース・オブジェクトの作成以降は通常のDB2と同様に実施する

見積り、サイジング

計算ノード数以外の構成は決定済みのため、キーとなる要素（インスタンス数、DB数、CPU 、データ量）を充足するサイズを選択するのみ

29

© 2013 IBM Corporation 30

まとめ

• pureScaleはじめ、様々なRDBMSのクラスタ技術を組み合わせて、適材適所のアーキテクチャ適応が重要（全てpureScaleであればよいわけではない）

• H/W, S/W(pureScale), サービス全て込み込みのPureDataの登場

• クラウド基盤に耐えうる拡張性、可用性そして効率性

ミッション・クリティカル環境に耐えうるデータベース基盤に求められる要件

• （拡張性）拡張性に優れ、ユーザーやデータの増加に柔軟に対応

• （可用性）集約されたデータを守る高い可用性と計画停止時間を最小限にする オンライン・メンテナンス

• （効率性）多様なトランザクションに対応可能な、 ワークロード・バランスによる、効率的なリソース配分

© 2013 IBM Corporation 31