SAP-IBM Competence Center Japan
© 2009 IBM Corporation
次世代データーセンターにおけるSAP on
AIX/Oracleの活用
・PowerVM Virtualization
~ Live Partition Mobility ~
・Nシリーズ ストレージによる
SAPインスタンスのクローン作成
・Oracle Index圧縮
データセンターにおける現行SAPシステムの課題
データセンター
SAP on AIX/Oracle
日々増え続けるデータ容量
- ディスク増設の手間
止められないシステム
- 24時間/365日のシステム稼動
運用の硬直化
-新ランドスケープ構築の手間
現行の運用ではコスト削減に
限界を感じていませんか？
手段
IBM Systems/Oracleの機能を活用し課題解決
Oracleの機能
H/Wの
機能
© 2009 IBM Corporation
3
PowerVM Virtualization
∼Live Partition Mobility∼
仮想化における IBM のリーダーシップ
・ POWER5 プロセッサー搭載のサーバーですでに業界一との評価
– “Among today’s microprocessors, POWER is the clear leader in the depth and breadth of its virtualization facilities.” THE GHOST IN THE MACHINE, Microprocessor Report March 12, 2007
POWER6 プロセッサー搭載サーバーではさらなる新機能 – Live Partition Mobility
OS、アプリケーションを止めることなく、LPAR を他の筐体に移動可能 計画停止時間ゼロ、動的なシステム拡張 Hypervisor を 開発（後にメイ ンフレームの VM となる） 物理分割を行 なう初のコンピ ューターを発表 メインフレーム での LPAR を 発表 POWER LPAR の設計 に着手
1967
1967
1973
1973
1987
1987
POWER4/AIX ベースのシステ ムに LPAR 機能 を導入 Advanced POWER Virtualization 出荷開始2004
2004
2001
2001
1997
1997
© 2009 IBM Corporation 5 Virtual I/O の経路
マイクロ・パーティショニング
複数の区画でプロセッサーを共有 区画あたり最小で 1/10プロセッサー AIX V5.3 / V6 Linux仮想 I/O サーバー (VIOS)
共有 Ethernet 共有 SCSI と共有ファイバー・チャネル Integrated Virtualization ManagerMultiple Shared Processor Pool
筐体内で複数のプロセッサー・プールを サポート
プロセッサー・プール毎に、 最大値/最小値/優先度を指定
Shared Dedicated Capacity
占有プロセッサー区画で余ったCPU資源を uncappedの共用プロセッサー区画で 利用可能
Live Partition Mobility
POWER Hypervisor
Linux
AIX
V5.2
動的にリサイズ可能2コア
1コア
AIX
V5.3
2コア
4コア
L
in
u
x
A
IX
V
5
.3
A
IX
V
5
.3
A
IX
V
5
.3
A
IX
V
5
.3
A
IX
V
6
.1
L
in
u
x
Micro-Partitioning
共有 Ethernet仮想 I/O
サーバー
区画
共有 ストレージHMC
POWER6 の先進的仮想化機能 - PowerVM
Lx86
POW
ER6
Only
!
PowerVMの特徴
①低オーバーヘッド
→高パフォーマンス
②高セキュリティ、堅牢性
→高信頼性
③リソースを有効活用できる柔軟性
→高い統合効果
• ベンダー固有実装となるた め、サポートOSが限定され ることがある • 信頼性/柔軟性は仮想マシ ンモニターに依存 • 特にI/Oバウンドな処理で は仮想化オーバヘッド大 • 仮想化オーバーヘッドが大 きい • 資源配分の柔軟性に欠け る • H/W構成により実装可能な 仮想サーバー数が制限 デメリット ファームウェア(マイクロコー ド)による仮想化 仮想化専用S/Wにより物理 リソースを仮想化 ホストOSと仮想化S/Wによ り複数のゲストOSを稼動 ボード単位などで電気的に 分離 特長 • VMware Server
• Microsoft Virtual Server • 比較的容易に仮想サー
バーを実現
ホストOSによる仮想化
• System z LPAR • System p/i LPAR
(POWER Hypervisor)
• Hitachi サーバー仮想化機 構
• VMware ESX Server • z/VM • HP Integrity VM • HP vPar • Xen, Hyper-V • System x PPAR • HP nPar • SUN DSD • Fujitsu XPAR 代表的な実 装例 • 柔軟性と高信頼性を実現 • 仮想化オーバーヘッドが小 さい • 仮想サーバーへの柔軟な リソース配分 • パーティション間の独立性 が完璧に近い (オーバー ヘッドの考慮必要なし） メリット イメージ H/Wによる仮想化 専用S/Wによる仮想化 物理分割 OS APPL. OS APPL. ボード ボード ハードウェア ホストOS+仮想化S/W OS APPL. OS APPL. ハードウェア 仮想マシンモニター OS APPL. OS APPL. ハードウェア ファームウェア OS APPL. OS APPL.
【ご参考】サーバー仮想化の実装パターン
© 2009 IBM Corporation
7
Live Partition Mobilityとは
Live Partition Mobility on IBM Power Systems / AIX
POWER6を搭載したIBM Power Systems & AIXサーバーでは、サーバーの筐体間を
またがってシステムを停止することなく、稼動中のシステム区画の移動が可能です。
Live Partition Mobilityの機能を使用することで、次のことが可能になります。
本番業務を停止させることなく、ハードウェアの保守、メンテナンスが可能。
夜間などオンラインを使用しないような時間帯に、一つのサーバーに区画を寄せるこ
とにより、使用しないサーバーの電源を落とすことにより電力の低減が可能。
より大きなシステム資源が必要になった場合でも、ハイスペックのサーバーへの無
停止でのシステム区画の移動が可能。
ハードウェアによる仮想化
論理区画の瞬間移動により、計画停止
さえも削減。筐体の交換・更新の際にも、
アプリケーションを止める必要がありません。
Live Partition Mobilityの前提
SAP AIX/Oracle環境下でのLive Partition Mobilityサポート構成
SAP Note 1102760 - POWER6 Live Partition Mobility) ver. 5 抜粋- Oracle DB 10gR2 (10.2.0.4) - Single Instance only, no RAC - AIX 5.3 TL8 SP4, or
- AIX 6.1 TL2 SP3
AIX環境下でのLive Partition Mobilityサポート構成
最新情報はこちらでご確認ください© 2009 IBM Corporation 9
LPMデモ概要
Power 550 サーバー Power 570 サーバーHMC
DS4500ストレージ HMC HMC画面画面 Power550サーバー内の区画一覧Power 550上の“pvc52”区画に
SAPがインストールされている
pvc52 OS AIX6.1 TL3 DB Oracle10g SAP IDES 6.0LPMによりpvc52区画がPower570上に移動
Power570サーバー内の区画一覧 LPM前 LPM後SAPトランザクション内容
FB50（G/L勘定伝票入力）のバッチインプットを作成して、3万レコードに増やしたものを
SE38（ABAPエディタ）から、バックグラウンドで実行中に、Live Partition Mobilityの機能で
筐体間をクライアント区画が移動する
© 2009 IBM Corporation
11
Nシリーズ ストレージによる
幅広いサポート・プロトコル
– CIFS, NFS (NAS接続) – iSCSI
– FCP(ファイバー・チャネル・プロトコル) – HTTP,FTP
– Fibre Channel over Ethernet (FCoE)
幅広いサポート・プラットフォーム (*1)
– Microsoft Windows, AIX, Linux, HP-UX, Solaris, VMware, NetWare
豊富なソフトウェア機能
– Snapshot, SnapRestore、SnapMirror, SnapVault, SnapLock, LockVault, など
多彩な用途
– プライマリー・ストレージ、アーカイブ・ストレージ、 災害対策ターゲット、参照用データ – FC-HDD : パフォーマンス重視の保管に – SATA-HDD : コスト重視の保管に – SAS-HDD:汎用用途高い可用性
– コンポーネントの冗長化 – ホットスワップ可能なコンポーネント – RAID-DP N3000 / N5000/N7000 (*1) 最新情報は、インターオペラビリティー・マトリックスに公開されています。 http://www-03.ibm.com/systems/storage/product/interop.htmlWindows AIX Linux HP-UX
・・・ ・・・ ・・・ プライマリー ストレージ 参照用データ 災対ターゲット アーカイブ・ストレージ Solaris
IBM System Storage Nシリーズ
FC SAN
NAS
© 2009 IBM Corporation
2005年4月IBMとネットアップは、情報のオンデマンド化を促進し、先進的なストレー
ジ情報管理製品群であるIBMのストレージ・ソリューション拡大を目的に、戦略的提
携を発表しました。
IBMはNetAppストレージ製品ラインナップのOEM契約(IBMロゴ、IBMサービス、
IBM保守での提供)を合意
ハードウェア
–
Nシリーズ アプライアンス = NetApp FASシリーズ
NAS(NFS/CIFS)、FC-SAN & iSCSI ストレージ
–
Nシリーズ ゲートウェイ = NetApp Vシリーズ
既存SANストレージにNAS/iSCSI機能を提供–
ニアライン ストレージソリューション
ディスク to ディスク バックアップ SATAディスク搭載プラットフォーム40を超える各種ソフトウェアライセンス
IBMとNetAppとのアライアンス概要
NetApp
Nシリーズのソフトウェア
Nシリーズはストレージ効率を最大化するため様々なソフトウェア技術を導入
重複削減機能
フルバックアップに対して最大95%、 その他のデータセットに対して25% から55%の重複を削減 最大95%
削減
シンプロビジョニング
(FlexVol
®)
通常20%∼33%の削減 33%複数の機能の組み合わせにより、
データの削減を複数倍に
!
Snapshot
TMコピー
オリジナルのデータセットから 変更のないコピーデータ容量と 同等の削減80%
以上の 削減RAID 6 (RAID-DP
TM)
ミラーデータもしくは、RAID10 に比べて46%の削減 最大46%
仮想クローン
(FlexClone
®)
オリジナルデータセットに対して 変更のかかった分のクローン データとして消費80%
以上の 削減© 2009 IBM Corporation 15
Nシリーズ導入によるメリット
SAPシステムとの高い親和性
SAP インスタンスのクローン環境を数分で作成 本番環境のダウンタイムはゼロ 本番環境への性能影響は最小ディスク管理、ユーザー管理の手順が標準で提供される
Web経由でFilerViewにアクセスし、NAS構成管理が可能 Active Directory、NIS、LDAP にも対応 既存環境にも容易に追加可能 独自のFlexVolを採用 稼動中の容量追加にも柔軟に対応バックアップに関する豊富なソフトウェア群を提供
Snapshot ：ある一時点でのファイルシステムをポインターを利用し瞬時に保管 SnapRestore：Snapshotが取得された時点にファイルシステム全体をリストア データをリストアするのではなく、ポインター情報を復元 SnapVault ：Nシリーズ間で差分情報のみを転送するバックアップソリューション SnapMirror ：ソース領域からターゲット領域にデータを複製 同期モード、非同期モードで差分情報を更新 NDMPにより、一般のアックアップS/Wとも連携しテープにバックアップ【ご参考】NAS−SAN 比較表
ディスクを制御するサーバー側に存在 NAS上に存在 ファイル･システム DBサーバー用ディスク クラスター構成用共用ディスク DBサーバー用ディスク ファイル･サーバー 主な用途 SCSIコマンドを使用 →Block I/Oを行う raw deviceも使用可能 CIFS、NFS、http 等を通じて使用 →ファイルI/Oを行う I/O効率 Fibre Channelケーブルを使用 (通常、敷設工事が必要) Ethernetケーブルを使用 (社内LANも利用できる) 接続ケーブル FCP TCP/IP 通信プロトコル スケーラビリティが高い 距離は最大10Km (中継無し) サーバーやクライアントの設定を変えずに動的 に容量拡大ができる →管理が容易 距離の制約を解消できる その他の特徴 サーバー⇔ディスク間 サーバー⇔クライアント間 サーバー⇔サーバー間 主な使用形態 ディスク共有可能 (同一OS間、要排他処理) ファイル共有は別ソフトが必要 ファイル共有が可能 (OSに依存しない) サーバー間の資源共有 ∼4Gbps (8Gbpsも普及中) ∼10Gbps 帯域 SAN NAS© 2009 IBM Corporation 17
検証環境図 & 検証概要
Public LAN en0 en1 en1 en0 Giga Hub aggr1 aggr0 RA1 (pooh) [Source] IBM Power p520 Aggregate AIX 6.1SAP ERP 6.0 SR3 IDES
AIX 6.1 SAP ERP 6.0 SR3 RA2 (ccdeimos) [Target] IBM Power p520 N5300
(NetApp FAS3040) Aggr0 300GB x3 RAID-DP
227GB
Aggr1 300GB x28 RAID-DP 4.21TB
【NetAppに導入したアドオン・ライセンス】 • FlexClone, SnapRestore, NFS Protocol 【サーバーに導入したアドオン・ライセンス】 • SnapDrive for Unix, SnapManager for SAP
【検証概要】
あらかじめ2台のSAPシステムを用意して、1台を本番環境：ソース、もう1台を検証環境：ターゲットと想
定して、本番環境のSAP/OracleデータをSnapManager for SAPのCloning機能 (FlexClone) を用いて
検証環境へコピーする。
プロトコル：NFS クローニング [Repository] IBM Power Oracle検証手順概要
1. ソースとなるSAPと、ターゲットとなるSAPの準備
今回はソースシステムをERP 6.0 SR3のIDESを導入し、ターゲットにはERP 6.0 SR3を導入。 SAP/Oracleのデータ部分のみをNetAppに格納。接続はNFSを使用。
2. SnapManager for SAP用リポジトリー (Oracle DB)の作成
SAPシステムとは別のOracle DBをリポジトリーとして作成する。
3. Nシリーズ・ソフトウェアの導入 (AIXサーバーへ導入)
SnapDrive for UNIXの導入：AIX用の4.1.1を導入。 SnapManager for SAPの導入：AIX用の3.0.2を導入。
4. SnapManager for SAPからソースとターゲットのプロファイルの作成
5. ソースシステムのバックアップ (Snapshot)
6. ターゲットシステムのクリーンアップ
Init<DBSID>.ora等の削除7. クローニングの実施
8. ポスト処理の実行
ORADBUSR.SQL (SAPノート：50088)sap_follow_up_activities.sh (SnapManager for SAPのサンプル・スクリプト)
© 2009 IBM Corporation 19
検証結果
バックアップ、クローニング前の Aggregate (aggr1) クローニング後の Aggregate (aggr1)【実行時間】
ソースシステムのオフライン・フルバックアップ：
約3分
クローニング処理の実行時間：
約3分
【ディスク容量】
ソースシステムのバックアップ及びクローニングによって増加した容量：
10GB
程度
ソースシステムのデータファイルサイズは約247GBなので、物理コピーした場合と比較すると、
DISKサイズ削減率 (247-10)/247 =
95%
注意事項等
Oracleのコントロール・ファイル
– SAP環境では3つのうちの一つは、sapdata1のディレクトリーに配置されている。NetAppの環境では、デー タとは別のFlexVolumeに配置しなおすことを推奨。クローンされたターゲットのSAPシステムの状況
– ソース側がアーカイブ・モードで稼動していても、ターゲット側はノンアーカイブ・モードで起動される。 – 今回の検証ではクローンされたSAP(IDES環境)が、ターゲットシステムで起動されることの確認及びSU01 等の確認のみでアプリケーション的な検証は未実施。 – SAPのプロファイルはコピーされないので、ソースシステムと言語の環境を合わせるような場合はプロファイ ルの設定・変更が必要。SnapManager for SAPのサンプル・スクリプト
– ターゲットシステムのクリーンアップ cleanup.shをカスタマイズすればクローニング処理と同時に処理することは可能と思われるが、今回は 未実施。 – ポスト処理の実行 ORADBUSR.SQLの処理は、os_db_authentication.shをカスタマイズすればクローニング処理と同時 に処理することは可能と思われるが、今回は未実施。 sap_follow_up_activities.shは、クローニング処理と同時に実行するよう指定してみたが、エラーに なったため、今回は手動で実行。SnapManager for SAPはデフォルトではrootユーザーで実行しに行く ようであるが、このスクリプトは<sid>admユーザーで実行する必要がある。そのようにスクリプトのカス タマイズが必要。
ソースシステムのバックアップ
– 今回はオフライン・バックアップを用いてクローニングを実施。 オンライン・バックアップは現在実施中。
© 2009 IBM Corporation
21
SAPシステムでは大量のディスク領域を索引が使用
SAP ERP（R/3）:
データベースのディスク領域の30∼50%
さらに多いケースも存在
SAP BI（BW）:
データベースのディスク領域の25∼40%
ビットマップ索引を多用すると、比率が低下
Index圧縮
OracleのIndex圧縮をご存知ですか？
Oracle10.2
Oracle10.2
から
から
SAP
SAP
環境での使用が認定されています
環境での使用が認定されています
「SAPノート1109743 - Oracle データベースでの索引キー圧縮の使用」 抜粋
Oracleリリース10.2以降、SAP環境で索引キー圧縮がサポートされます。
既存の B*Tree 索引をデータベースで再構築して索引キー圧縮を使用し、
B*Tree 索引を可能な限り効率的な領域として保存します。
© 2009 IBM Corporation 23
