PDF形式、4200KB - 北九州e-PORT

<写真欄>
グリッドコンピューティングと
ＤＲソリューション
日本オラクル株式会社
2006年8月1日
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。
また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは
できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン
ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ
い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい
ては、弊社の裁量により決定されます。
Agenda
y
y
y
y
システム全体最適化とOracle Grid
Oracle Gridとディザスタリカバリ
Oracle Grid事例
まとめ
Copyright© 2006, Oracle. All rights reserved.
3
システム全体最適化とOracle Grid
Copyright© 2006, Oracle. All rights reserved.
企業におけるIT化ステージングの状況
組織改革
顧客視点
の徹底
社外との連携
統合・
標準化
電子計算機
の導入
「企業」の壁
EC導入
EDI導入
情報技術による企業
プロセスの標準化
業務のIT化
「経営」の壁
バックオフィスの
IT化
企業役割の変革
「システム」の時代
コミュニケーション
の最適化
「経営」 の時代
ステージ④
共同体最適化企業群
ステージ③
組織全体最適化企業群
ステージ②
ステージ①
部門内最適化企業群
IT不良資産化企業群
IT不良資産化企業群
5.7%
67.8%
24.2%
2.4%
平成17年8月 野村総合研究所アンケート調査
出展「CIOの機能と実践に関するベストプラクティス懇談会」報告書 経済産業省商務情報政策局 平成17年12月
ステージ② ⇒ ステージ③
全体最適化のための基盤インフラ構築
グリッドによる共通基盤構築
セキュリティ・ＩＤ統合
運用管理サービス
ステージ③ ⇒ ステージ④
ＩＴに付加価値を与えるソリューション提案
SOAによるプロセス標準化
ビジネスの可視化のためのBI
統合されたコンテンツ管理・検索
Copyright© 2006, Oracle. All rights reserved.
5
従来型ITインフラの課題
個別最適化されたシステム
y個別最適されたシステム
会計業務
人事業務
調達業務
APサーバ A
APサーバ B
APサーバ C
DBサーバ A
DBサーバ B
DBサーバ C
OS A
OS B
OS C
SI A社
SI B社
SI C社
–最大負荷に合わせた設計
–99%
以上の可用性
–乏しい拡張性
–分散して存在するデータ
–バラバラなセキュリティ・ポリシー
y増大するコスト
y複雑になる運用管理
y求められる多くのスキル・セット
y連携に強く依存するシステム構成
運用管理・システム・ライフサイクル
Copyright© 2006, Oracle. All rights reserved.
6
全体最適化における共通基盤の役割
個別最適化されたシステム
会計業務
アプリ
人事業務
アプリ
全体最適化によるシステム統合
SI A社
SI B社
会計業務
アプリ
人事業務
アプリ
SI X社
調達業務
アプリ
APサーバ A
APサーバ B
APサーバ C
DBサーバ A
DBサーバ B
DBサーバ C
･･･
調達業務
アプリ
標準管理フレームワーク
標準APサーバ
OS A
SI A社
OS B
SI B社
OS C
標準DBサーバー
標準OS
SI C社
共通基盤 （共通運用環境）
Copyright© 2006, Oracle. All rights reserved.
7
ビジネスの変化に柔軟に対応できる、
安定したITシステム基盤を
適正なコストで実現すること
運用管理の自動化/簡素化
リソースの仮想化・共有化
高度な安定性と拡張性
サービス・レベルの保証
Oracle Gridとディザスタリカバリ
Copyright© 2006, Oracle. All rights reserved.
Oracle Gridにおけるシステム停止防止機能
システム障害
計画外
停止
データの損害
& 災害
人的ミス
ストレージ 障害
Real Application Clusters
アプリケ－ションの可用性を確保
データガード（DB/AS）
データのロス、ゼロを実現
フラッシュ・リカバリー
ユーザーの人的ミスを自動修正可能
自動ストレージ管理(ASM)
Diskの自動ミラーリング
計画
停止
システム
チェンジ
ローリングアップグレード
データ変更
オンライン再定義
自動的に必要なパッチを適用
テーブル再定義をOnlineで実現
Copyright© 2006, Oracle. All rights reserved.
10
Oracle Data Guard
データロスのない災害対策ソリューション
予備システムを構築し、いざというときに切り替えて事業を継続
通常時
障害時
本番サイト
本番サイト
スタンバイ・サイト
スタンバイ・サイト
コピー
通常時は本番サイトに接続
障害発生時にはスタンバイ・サイトに接続
Copyright© 2006, Oracle. All rights reserved.
11
アプリケーションサーバー層とデータベース層
における高可用性の追求
ロード・バランサ
プライマリ・サイト
フェイルオーバー
スタンバイ・サイト
ASGuard
Oracle Application Cluster
スイッチオーバー
Data Guard
Oracle Real Application Clusters
Copyright© 2006, Oracle. All rights reserved.
12
Oracle Grid事例
Copyright© 2006, Oracle. All rights reserved.
BIGLOBE様におけるシステム要件
＜システムの概略＞
会員数が1300万人を超える国内トップクラスの総合インターネットサービス事業者。また、
法人向けビジネスとしてストリーミング、ホスティング、 Eマーケティング等のサービスにも
力を入れている。BIGLOBEの提供するBIGLOBEサービス用DB基盤の標準構成として
Oracleを採用している。
＜BIGLOBE様の課題＞
• 高品質で信頼性の高いサービス提
供
• 迅速なサービスの立ち上げ
• サービスを提供する基盤の柔軟性
• ITリソースの効率化
＜基盤データベースに
求められる要件＞
• 迅速なサービス展開
¾拡張性
• 耐障害性の向上
¾高可用性
• データの保全性
¾信頼性
• データベースの安定運用
¾運用性
Copyright© 2006, Oracle. All rights reserved.
14
Oracle Database 10g Release2の導入ポイント
—Oracle Real Application Clustersの採用
— サーバーを連携させ性能と信頼性を高めるグリッド機能。
— スモールスタートかつ迅速なサービス立ち上げで、1サービスあたり単
価コストを削減。
— サービスの負荷が高まると迅速なスケールアウト。
—Oracle Data Guardの採用
— ローリングアップグレードによりパッチ適用、バージョンアップも停止時
間最小限で実現。
—Oracle Enterprise Managerの採用
— データベース管理の簡便化およびメンテナンスの一元化を実現。
— ワークロード管理機能でリソース配分制御し、 早急に高負荷のサービ
ス検知と別サーバへの再配置を行う。
— 負荷分析やサービスイン前の開発、テスト段階でチューニングが可能。
Copyright© 2006, Oracle. All rights reserved.
15
BIGLOBEサービス用DB基盤
サービスA
サービスB
ログ転送
NASストレージ
・・・
データベース運用者
データベース運用者
・EnterpriseManagerにより、DB全体の一括管
Managerにより、DB全体の一括管
・Enterprise
理を実現。
理を実現。
DBサーバ
DBサーバ
・2CPUブレードサーバ×4台
・2CPUブレードサーバ×4台
(今後の負荷(サービス)増加により増設予定)
(今後の負荷(サービス)増加により増設予定)
・RedHatEnterprise
EnterpriseLinux
Linux
・RedHat
・OracleReal
RealApplication
ApplicationClusters10g
Clusters10g
・Oracle
・DataGuard(本番同等構成)サイトを用意し、
Guard(本番同等構成)サイトを用意し、
・Data
ローリングアップグレードを実現。
ローリングアップグレードを実現。
ストレージ＆バックアップサーバ
ストレージ＆バックアップサーバ
・ストレージのSnapShot機能で高速バックアップ
・ストレージのSnapShot機能で高速バックアップ
・NASを採用し、ディスク容量の拡張に柔軟に対
・NASを採用し、ディスク容量の拡張に柔軟に対
応
応
Copyright© 2006, Oracle. All rights reserved.
16
Data WarehousingへのGrid適用例
FIN
SCM HR
業務システム
FIN
SCM HR
Oracle
Warehouse
Builder
ETL
DWH
各々の最大ピーク時にあわせたリソース投資が必
要なため、非効率、高コスト
業務システム
Oracle
Warehouse
Builder
ETL
DWH
Grid環境により、ピーク時の異なるBIシステムの負荷
を分散、CPU資産の有効活用と低コスト、堅牢なイン
フラを実現
Copyright© 2006, Oracle. All rights reserved.
17
Amazon.com:
世界最大のLinux DWH
サプライ
チェーン
企画・プラ
ン
経理分析
商品配送セ
ンター
カスタマー
ウェブ
サーバー
DWH
パートナー
社内
ユーザー
パーソナライズ
キャンペーン
コンテンツ
サービス
Copyright© 2006, Oracle. All rights reserved.
Eメール
サーバー
Amazon.com
増大するDWHパフォーマンス要件
ＤＢサイズ
データサイズ
ユーザー数
検索件数 /1日
% < SLA
2000 2001 2002 2003 2004
~1 TB 3.5 TB 10 TB 15 TB 20 TB
~1 TB 2.3 TB 9 TB 13 TB 18 TB
330
512
800 830 830
630 1000 4200+ 6,000 7,000
63% 77% 80%+ 80%+ 80%+
Redbrick
8i
9i R1
9i R2
2005
25 TB
23 TB
830
8,000
80%+
2006
61 TB
51 TB
830+
10,000
80%+
10g R1
6年間で:
- 50倍超のデータ量
- 16倍超の検索件数
- 3倍以上のユーザー数
- ショップでの取り扱い製品カテゴリの増加
- レポートの種類の増加
サービスレベルの維持と、プライス・パフォーマンスの向上
Copyright© 2006, Oracle. All rights reserved.
Amazon.com
システム構成
1. 業務システ
2. データ統合、
3. データ検索・
4. データアクセ
ムからの抽出
移行、非正規化
分析
ス・配信
ステージング
DB (7TB)
データ抽出
サーバー
8ノード4cpu
HP DL580
ADS(Atomic Data Store)
ClickStream
(61TB)
16ﾉｰﾄﾞ 4 CPU
HP DL580
ETL
Manager
ステージング
DB (7TB)
8ノード4cpu
HP DL580
ADS(Atomic Data Store)
ClickStream
(61TB)
16ﾉｰﾄﾞ 4 CPU
HP DL580
Copyright© 2006, Oracle. All rights reserved.
ユーザー
検索
パーソナライズ
Datanet
Server
Oracle RAC 10g on ASM
•70,000 DSS検索/週
•61TB DB Size
(data size 51TB, Storage Size 100TB)
「利益率向上」を目的に開始した Oracleの
“ Global Single Instance ” プロジェクト
業務サーバ数
プロセスもデータも各国
ごとバラバラ
102台
データセンター
各国各拠点に散在・・・
業務プロセス一元化、業務データ
1インスタンスに
9台
オースティン他、世界3ヵ所に集約
IT部門スタッフ
1,523名 (‘99)
844名 (‘03)
$500M超 (‘99)
$229M (’03)
$39M (’99)
$25M (’02)
業務
コスト（運用）
コスト（ｻｰﾊﾞ購入）
Copyright© 2006, Oracle. All rights reserved.
21
GSIにおける復旧要件
復旧要件：
• プライマリの最大REDO率 = 8MB/sec
• プライマリのサイト障害からの保護
• サイト間の距離 = 1,000マイル（=1,600km）
• ネットワーク遅延時間(RTT) = 25msec ～ 35msec
• データ障害からの保護
• RPO = 最大で5分以内
• RPO = Recovery Point Objective = 目標復旧時点
• RTO = 最大で1時間
• RTO = Recovery Time Objective = 目標復旧時間
• 最小限のデータベース管理者
Copyright© 2006, Oracle. All rights reserved.
22
GSI スタンバイ・サイトの構成
1600 km
Austin Data Center
Internet Load Balancing
BigIP
Intranet Load Balancing
BigIP
Network / BigIP / DNS
Colorado Springs
Data Center
Internet Load Balancing
BigIP
Intranet Load Balancing
BigIP
Giga Ethernet
Giga Ethernet
Application Code
( ストレージ・ミラー )
Giga Ethernet
Giga Ethernet
DR1
RAC1
RAC2
RAC3
DR2
DR3
DR4
RAC4
Database
( Data Guard )
Copyright© 2006, Oracle. All rights reserved.
TEST1 TEST2 TEST3 TEST4
DR
TEST
23
GSI スタンバイ・サイトの構成内容
y 異なるローケーションにスタンバイ・サイトを構築
y スタンバイ・サイトでもH/W構成は冗長化
y 同期/フェイルオーバーに使用する機能
–
–
–
クライアント層
⇒ DNSによる振り分け
アプリケーション層 ⇒ ストレージ・ミラー
データベース層
⇒ Data Guard（フィジカル・スタンバイ）
y スタンバイ・サイトはテスト目的でも利用
–
スタンバイ用とテスト用でドメイン分割
y データ障害から保護するために、スタンバイへの適用は、
4時間遅延させる
–
Flashback Databaseを利用することで、遅延適用は利用せずに済
むようになる
Copyright© 2006, Oracle. All rights reserved.
24
「コスト削減」と「ガバナンス強化」を
両輪で実現する結果に
Single Instanceの実現による
プラスアルファの効果
データ可視化
データ可視化
内部統制実現
内部統制実現
プロセス可視化
プロセス可視化
コンプライアンス向上
コンプライアンス向上
アクセスコントロール
アクセスコントロール
災害対策
災害対策
当初の主目的
コスト削減
コスト削減
コストを削減し利益率
を改善
施策
サーバ/データ統合
サーバ/データ統合
業務プロセス統合
業務プロセス統合
Copyright© 2006, Oracle. All rights reserved.
さらなるコスト削減
さらなるコスト削減
効果
• 全組織にて1,000億円（$1
billion）超をコスト削減
• 決算発表を短縮
• データの正確性/可視性/リアル
タイム性向上
25
Oracle Data Guardの導入実績（一部）
スタンバイ方式
REDO転送方式
ロケーション
プライマリ スタンバイ
A社様
フィジカル
ARCH転送
東京
東京
3node
2node
B社様
フィジカル
LGWR非同期転送
関東
関西
Single
Single
C社様
フィジカル
LGWR非同期転送
N/A
N/A
2node
1node
D社様
ロジカル
LGWR非同期転送
東京
関東
Single
Single
E社様
フィジカル
LGWR非同期転送
大阪
大阪
Single
Single
F社様
フィジカル
ARCH転送
東京
中部
Single
Single
G社様
フィジカル
LGWR非同期転送
東京
大阪
4node
2node
H社様
フィジカル
ARCH転送
東京
大阪
2node
2node
I社様
フィジカル
ARCH転送
東京
東京
2node
2node
事例検索サイト
国内事例
http://www.oracle.co.jp/showcase/index.html
海外事例
http://www.oracle.com/customers/products/database.html
Copyright© 2006, Oracle. All rights reserved.
26
まとめ
Copyright© 2006, Oracle. All rights reserved.
急激に変化するビジネスに対する
有効なシステム基盤
標準・安定・柔軟性
システム基盤は全体最適化
全体最適化によるDRの効率化
Copyright© 2006, Oracle. All rights reserved.
28
日本オラクル株式会社 無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。
日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を
負いかねます。
Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその
子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標の可能性があります。