米国エネルギー省クリティカル物質戦略のmric.jogmec.go.jp/wp-content/old_uploads/reports/...米国エネルギー省クリティカル物質戦略の需給予測 74
[D35]...
-
Upload
insight-technology-inc -
Category
Technology
-
view
1.521 -
download
2
description
Transcript of [D35]...
© 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パーティションが互いに影響を及さず、スケールアウトによる高い性能、拡張性を実現可能
• アプリケーションからは1つのデータベースとしてアクセス
データ ログ データ ログ データ ログ データ ログ
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