Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka

1,919 views

Published on

Published in: Technology
  • Be the first to comment

D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka

  1. 1. © Hitachi, Ltd. 2013. All rights reserved.SSDで挑むOracle超高速化と信頼性の両立株式会社 日立製作所ITプラットフォーム事業本部
  2. 2. © Hitachi, Ltd. 2013. All rights reserved.DB高速化需要の高まり データの増加に伴い、処理時間が増加。これに伴い、データベースシステム要件として、処理時間の短縮=DB高速化が重要になりつつある。DB担当者担当者のDB高速化の悩みは尽きない朝までかかる夜間バッチは、ハードをリプレースするだけで、速くなるだろうか。既存アプリは、今更手を入れるなんてできないからDB自体を速くしないとDWHで抽出してるデータが少な過ぎると言われているが、増やせば時間がかかる1
  3. 3. © Hitachi, Ltd. 2013. All rights reserved.Oracle高速化に必要な条件 オープンで信頼性の高いプラットフォームである多くの実績に基づくIAサーバとSANストレージでのOracle RAC構成。信頼性の高いハードを冗長構成化したLinux/Windowsサーバ。万が一のトラブルでもボリュームコピーバックアップから迅速に戻せる。 データ容量や処理内容に合わせてコスト調整できるCPUコア数、メモリ量、ストレージ容量を予算に応じて調整できる。Oracle EEライセンスを抑えられる様に少ないコア数でも構成できる。コスト極小化の為、Oracle SEライセンスでも使える。 I/Oの多いバッチ処理を高速化できること月末/期末のバッチ処理が短時間で処理でき多重度も増やせる。DWHやBIのデータ抽出処理も高速化できる。もちろんオンライン処理のレスポンスも良くなる。何を速くしたいのか。速ければ何でもよいのか。2
  4. 4. © Hitachi, Ltd. 2013. All rights reserved.1.高速化の話3
  5. 5. © Hitachi, Ltd. 2013. All rights reserved.1-1. DBの高速化を実現する方法簡単なものから難しいものまでいくつかあるソフト的な要因 ハード的な要因CPU メモリー I/OSQL機能パラメータ構造CPU/メモリがボトルネックなら最新サーバへのリプレースで、大きな性能向上が期待できるが、それはまれなケース。IO、ストレージネックの場合は、 それを解消すればCPU/メモリをもっと使え、大きく性能向上の可能性あり。工数をかけずにDBを高速化する鍵はI/OやストレージSQLで性能は大きく変わるが、変えられない(パッケージ利用、技術者不足)技術者がいてもSQL文や構造の見直しは工数が膨大で難しいパラメータチューニングは、実はほとんど効果なしストレージCPU メモリー I/OSQL機能パラメータ 構造 ストレージ性能への効果変更の難易度性能への効果変更の難易度リプレースなら難易度は全て同じ工数大4DBが遅い原因
  6. 6. © Hitachi, Ltd. 2013. All rights reserved.CPUの性能推移とI/Oの性能推移11020相対性能2004 2005 2006 2007 2008 2009 2010515201125304倍10倍HDD回転数1倍4core6core2core28倍10core1-2. H/Wの性能進化の不均衡 CPUの性能の伸びに比べ、I/Oはそれ程伸びていない 特にストレージ性能に寄与するHDD回転数とFC帯域は最悪ストレージI/Oの高速化を行うことにより、性能は劇的に向上する可能性がある ※CPU性能はSAP SDベンチマークをベースにした値5
  7. 7. © Hitachi, Ltd. 2013. All rights reserved.容量年代1-3. ストレージI/Oの高速化には高速化の鍵はFlashメモリー① 半導体なのでリード/ライトが速い 磁気記憶では無く、メモリーチップを使用している為、HDDより桁違いにリード/ライトが速い。 Flashの特徴として、ライトは上書きでは無く別の場所に書き、元の場所を無効化する。ブロック内に無効領域が増えたらガーベッジコレクションしてから消去する。② 容量がHDD並みとなってきた HDD互換のSSDでは数100GB~1TB超のデバイスが製品化されてきており、価格はHDDより割高だが性能が必要な状況で採用される様になってきた。6書込み済空き領域1ブロック(消去単位)
  8. 8. © Hitachi, Ltd. 2013. All rights reserved.1-4. SSDの特性SLCとMLCFlashにはSLCとMLCがあり、MLCの方がビット単価が安く大容量化に向いているが、短寿命等の弱点もある。しかし最近の技術進歩でMLCでも基幹系システムに利用できる信頼性を持つものが出てきている。データ保持時間Flashは電源が無くてもデータを保持する特性があるが、電源が無い状態で長期放置を行うと、微量ながらも電荷が減っていく為、データが失われることがある。MLCの場合は、3ヵ月以内には通電することを推奨。SSDとはHDD互換インターフェース(SATA/SAS)を装備したFlashメモリー。SDカードやUSBメモリーと同じNAND Flashを使用。
  9. 9. © Hitachi, Ltd. 2013. All rights reserved.昼(オンライン) 夜夜(バッチ処理)1-5. ストレージのアクセス種別について業務処理の1日のアクセス状況DB領域全てをSSD化すれば、なにも考えなくても速くなる!業務処理では、昼間はIOPSが必要で夜間は帯域が必要となる。PCIフラッシュ等で一部の領域を高速化する手法も最近の話題。しかしバッチの場合は、どのデータに高速性が求められるかわからない。※グラフはストレージアクセスイメージです。IOPS必要帯域必要8
  10. 10. © Hitachi, Ltd. 2013. All rights reserved.1-6. 高速化に必要なSSD前提システムの要件サーバに必要な条件ストレージに必要な条件サーバからストレージまでのI/Oボトルネックを排除 性能と可用性を両立する為、2ノード以上のOracle RAC構成 I/OはRACで実績多いFCで、SSD帯域合計に負けないポート数での接続 レイテンシーを極小化する為、FCスイッチを介さず直接ストレージに接続 インターコネクトは10GbpsのLANが必要。クロスケーブル接続は禁止 SSDの帯域とIOPSに対応したストレージコントローラを搭載している 搭載しているSSDのバス(SAS)をロスなく伝達できるバックエンドの装備 特定プロセッサネックを発生させない為のプロセッサコアの最適配置機能 LUの優先パスを最適に分散させ偏らない様にするFCパス制御機能9
  11. 11. © Hitachi, Ltd. 2013. All rights reserved.1-7. 検討したハードウェア構成理想の構成はこれだ!ストレージサーバ #0 サーバ #11GNIC1GNIC管理LAN10GNIC10GLANSW10GLANSW10GNIC10GNIC10GNICBonding BondingRAC InterconnectRACインターコネクトは、10GbpsのNICで冗長化もちろんパブリックLANも冗長化必要今後は10G対応でI/O性能を上げるためLUは分けて、ポートと制御CPUにくくりつけるSASインターフェースがボトルネックにならないSSD本数と経路を確保Ctrl0 Ctrl1 Ctrl2 Ctrl38Gbps x 16FCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCP P P P P P P P P P P P P P P P10GNIC10GNICBonding10GNIC10GNICBondingPublic LANLU LULU LULU LULU LUSSD帯域に負けない為FCは16ポートは必要ストレージ直結が良い10
  12. 12. © Hitachi, Ltd. 2013. All rights reserved.ストレージ1-8. 複数LUへのDB配置使い過ぎ少な過ぎFC利用率100%0%OSのI/Oキューの分散の為、LUを分けるのは一般的。理想の構成ではLUにポートを専有させると性能は向上。LUが複数あるとどのデータをどのLUに割り当てるか検討が必要検討不十分だとLUのデータ占有量が不揃いになったり、アクセス頻度が偏る。最悪本番稼働後に配置見直し等を実施しなければならなくなる。高速化構成の副作用LUサーバHBA(FCカード)TableC TableA TableD TableB11
  13. 13. © Hitachi, Ltd. 2013. All rights reserved.1-9. サイズやアクセス頻度の偏りの無いASMLUOracle ASM最高のパフォーマンス複数LUをうまく使うには、Oracle ASMを使用することで対応が可能。複数LUがストライピングされ、全てのLUを均等に利用可能。FC帯域も均等に利用でき、パフォーマンスも向上。遅いLUが混在していると性能が引きずられ、DB全体が遅くなることがある。理想構成では全てSSDで統一しており、最高のパフォーマンスを発揮可能。FC利用率100%0%HBA(FCカード)複数LUをまとめて管理TableA TableB TableC TableD12
  14. 14. © Hitachi, Ltd. 2013. All rights reserved.2.信頼性の話13
  15. 15. © Hitachi, Ltd. 2013. All rights reserved.2-1. データベースシステムには信頼性が重要性能だけでは企業インフラには使えないハードウェア ソフトウェア部位 信頼性のポイントサーバスケールアップでは無く、複数台を独立に動作させるネットワークNICは複数ポート必要できればチップも分けるサーバ/ストレージ間複数FCカード搭載直結で障害時切分け容易ストレージ/LUコントローラ二重化各LUパスの二重化ボリュームコピー機能部位 信頼性のポイントOracleRAC2台を両現用で稼働ネットワークBondingによる冗長化(Teaming/Windows)FCパス制御Active-Activeやロードバランスのパス制御Backupボリュームコピー先の二次バックアップ可用条件は障害時でも業務が継続できること優先で、縮退は許容する。テストではFCパス半減でも動作継続し、性能もあまり落ちないことを確認。14
  16. 16. © Hitachi, Ltd. 2013. All rights reserved.2-2. ネットワークの可用性忘れがちなネットワークも重要 SSDのシステムでは1Gbpsでは不足。10Gが必要RACのインターコネクトは1Gでは不足。1:1通信の場合Bondingでは帯域を増やせない。直結は禁止なので2台のスイッチ(冗長)で接続10G LAN Port数は最低4port。もっと欲しいRACのインターコネクトとPublicで4port。Active DataGuard専用Portも性能に有効管理ネットワークも別セグメントで欲しい いくつ? Public LANの可用性はスパニングツリーで構成するのが良いのか。リンクアグリゲーション(LA)なら相性問題はまずない。複数スイッチでのLA機能(vPC, vLAG, MLAG)が旬。仮想LALA(bond)グループ15
  17. 17. © Hitachi, Ltd. 2013. All rights reserved.DBサーバ正VOL(SSD)ストレージSSDでもボリュームコピーは必要DR機能もあればうれしい162-3. ストレージの可用性確保ストレージコントローラバックアップサーバ ストレージコントローラはDBでは要。ファームウェア更新は無停止が必須。 キャッシュメモリーは実は不揮発性。停電時は電池バックアップだが最近はフラッシュに書き出すものもある。#0系ctrl#1系ctrl ストレージ機能による遠隔データコピーによりDRサイト構築が容易に。 フルバックアップならボリュームコピーは必須。副ボリュームはHDDにしてコストダウン。副VOL(HDD)先後キャッシュメモリーバックアップや非常時の対応が必要停電時FLASHFLASH
  18. 18. © Hitachi, Ltd. 2013. All rights reserved.2-4. SSDの寿命についてSSDの書き込み限界SSDではRAIDの場合、構成本数と書込み量で寿命が決まる全容量1.6TBを1日10回全て書き替えても、5年間使えます。地上デジタル放送(非圧縮1.5MB/s)を121番組同時録画を5年間続ける。どの程度の書き込み量なのか※寿命まで絶対故障しないということではありません装置によっては通知や対応もSSDの書き込み容量が寿命の90%に達すると、通知を出す装置あり。更に99%になるとスペアへデータをコピーし、書き込みを継続するように備える機種も。SSDの寿命とはSSDはデータ書き込み時に電子が移動することで半導体が劣化し、書き込み回数上限を決めている。200GBのSSDの場合3.6PBの書き込みが上限である。※3.6PBは日立採用のSSDの場合17値 備考SSD 1本の書き込み上限 3,600TB/5年 5年でこの値に達すると仮定(2D+1P)*4組での合計書込み上限 28,800TB/5年 200GB×8本分=1.6TB1日で書き込める容量 15,781GB/日1秒で書き込める容量 182MB/s
  19. 19. © Hitachi, Ltd. 2013. All rights reserved.温度・電圧の組合せによる過酷な環境による試験。■複合マージン試験■外観検査通電検査だけでは判らない異常を検出。半田飛散開発検査 量産検査X線透視観察装置2-5. 障害発生頻度を極力減らすには18元々メインフレームでやっていた処理なんだけど...
  20. 20. © Hitachi, Ltd. 2013. All rights reserved.遠隔保守有~ユーザーエリア~IP-VPNサポートセンタ監視通報装置遠隔保守無自動通報 復旧復旧業務のダウン時間を短縮ログ解析 保守作業駆けつけ部品手配電話受付&問診 ログ採取/解析 保守作業部品手配駆けつけ障害切分障害発生ユーザの負担作業障害連絡192-6. 万一の障害発生時に迅速な対応をするにはファイアウォールVPNルータ遠隔保守支援システムが自動通報を
  21. 21. © Hitachi, Ltd. 2013. All rights reserved.2-7. 全てを満たすOracle高速化モデルはこれ!(2ブレード)(×2台)高信頼の日立ハイエンドブレードサーバ10Gイーサネットファブリックスイッチ搭載可能APサーバ、バックアップサーバ等も混載可能サーバ当たり8本のPCI-Eスロットを追加独立した管理プロセッサが状態を監視I/Oケーブル断でもサーバが落ちない可用性SSD搭載前提の高性能コントローラ搭載帯域ネックになりにくい高速バックエンドパスShadowImageやTrueCopyバックアップ機能(筺体内ボリュームコピー) (筺体間コピー)データリードで11GB/sのI/O処理を確認。8Gb/s×16BladeSymphony BS2000I/Oスロット拡張装置 (2ブレード用)200/400/800GB SSD・・・Hitachi Unified Storage 13020
  22. 22. © Hitachi, Ltd. 2013. All rights reserved.3.SSDとOracleの相性の話21
  23. 23. © Hitachi, Ltd. 2013. All rights reserved.3-1. SSD/HDD IO性能基本データSSDはランダムI/Oで抜群の効果。一方でシーケンシャルI/Oでは投資効果が薄い22HDDSSDHDDSSD※性能値は構成/使用条件により異なります。【READ】 【WRITE】SSDHDDシーケンシャルI/O (RAID5:4D+1P, ブロックサイズ:512KB, 多重度:1)ランダムI/O(RAID5:4D+1P, ブロックサイズ:4KB, 多重度:32)SSDHDDHDDSSDHDDSSDSSDHDDSSDHDD【READ】 【WRITE】※HDDは10000rpm, SASディスク。数十倍の性能向上性能差はあまり大きくない
  24. 24. © Hitachi, Ltd. 2013. All rights reserved.3-2. 高速化したい業務は何?Oracle DBで高速化したい業務は何か?Oracleから見たI/Oパターンオンライン バッチ処理 分析系業務ランダムI/O 多い 普通 少ないシーケンシャルI/O あまりない 普通 多いより高速化の要望が強いシーケンシャルリードのSQLを多く擁するバッチ処理や分析系業務ではSSDの効果をどう考えればよいか?23
  25. 25. © Hitachi, Ltd. 2013. All rights reserved.3-3. 分析系SQLのI/Oパターンは?◆ストレージ側が受け取るI/Oパターン(分析系のSQL22個)◆シーケンシャルリードのSQL発行でストレージ側(SSD)が受け取るI/Oパターンを調べてみた。約6~7割がランダムI/Oその理由はOracle Parallel Query(または業務並列化)24Screen Only
  26. 26. © Hitachi, Ltd. 2013. All rights reserved.3-4. パラレルクエリとはシリアル実行では、1つのSQLに1つのコアが割り当てられる。◆オンライン処理の場合※多くのSQLが複数端末から発行されるSQL SQL SQL SQL SQL SQLSQL SQL SQL SQL SQL SQLSQL◆分析系処理の場合※1本の重いSQLが流れるParallelQueryPX PXSQLPX PX PX PX PX PXPXPX PXマルチコアが活用できない。CPUネック。マルチコアを有効活用。CPUネックが解消されディスク速度に依存。マルチコアサーバでバッチ処理や分析系処理を行う場合、Parallel Queryはレスポンス向上に有効。さて、ランダムvsシーケンシャルの話は・・・Parallel Queryでは、I/Oも多重化されて発行される。25PX:Parallel Execution Process
  27. 27. © Hitachi, Ltd. 2013. All rights reserved.3-5. パラレルクエリ+ASMでI/Oはどうなる?Parallel QueryASMRAID分割分割分割Drive(HDD/SSD)1ドライブに対するI/O要求が多重/並列化し、ランダムI/Oとなる。多重FCHUS130 #0LUCtrl0P P P PLUCtrl1P P P PFC FC FCOracleASMDBサーバLU LULU LULU LURAID5RAID5SQL発行パラレル化FCHUS130 #0LUCtrl0P P P PLUCtrl1P P P PFC FC FCOracleASMDBサーバLU LULU LULU LURAID5RAID5SQL発行パラレル化26
  28. 28. © Hitachi, Ltd. 2013. All rights reserved.3-6. SSDとOracleの相性はとてもいい。Oracle DBが発行するI/OパターンとSSDは、業務の性質によらず相性が良い。(もちろん、I/O負荷が高いもの)ランダムI/OではSSDは抜群の効果だから27
  29. 29. © Hitachi, Ltd. 2013. All rights reserved.4.「RAC on SSD」分析系SQLでの検証の話28
  30. 30. © Hitachi, Ltd. 2013. All rights reserved.4-1. 検証構成【サーバ】Blade数: BS2000 × 2BladeCPU: Xeon X5690 3.46GHz 6core×2Memory: 96GBインターフェース: FCFC通信速度: 8Gbps/portFCケーブル: 16本(8本/Blade × 2)【ストレージ】台数: HUS130 × 2台FC通信速度: 8Gbps/portFCケーブル: 16本(8本/台 × 2)【DISK】SSD: 200GB × 28 (14/台 × 2)データベース情報OS:Redhat Enterprise Linux 6.2RDBMS:Oracle Database 11g Release2 (11.2.0.3)DB構成:2ノード RAC構成DBサイズ:150GB, 及び350GBDBブロックサイズ:32KDBキャッシュサイズ:48GBテストツール、およびテスト内容分析系DB処理の一般的なベンチマークテストを使用SQLのレスポンスタイムの合計、及びI/Oスループットを測定同サーバでのHDDを搭載した同等構成と比較する。ハードウェアBS2000HUS130I/Oスロット拡張装置29
  31. 31. © Hitachi, Ltd. 2013. All rights reserved.4-2. 結果概要■ I/Oスループット※dd性能とは、OSのddコマンドにてI/O性能を測定した結果■ SQLレスポンス(IO処理の重い10個)・ 約1/5倍に短縮HDD構成から「RAC on SSD」への置き換えにより、I/Oスループット11倍、レスポンスタイム1/5に短縮024681012HDD(SQL性能) SSD(SQL性能) SSD(dd性能)0.758.4411.0000:0001:2602:5304:1905:4607:1208:38HDD SSD07:4501:34ところで、11GB/sとはどのくらいの性能なのでしょうか・・・?01:3003:0004:3006:0007:3009:00(mm:ss)(GB/s)FCパス14本の帯域を100%使用している状況と同じ、もしくはDVD 1枚を0.4秒で読み込むパフォーマンスです。たとえば1TBの表であれば1分半で読み込み完了します。30
  32. 32. © Hitachi, Ltd. 2013. All rights reserved.4-3. 旧環境(6~7年程度前のUnixモデル)との比較【サーバ】日立UnixサーバCPU:Itanium 2 1.30GHz 1core×2Memory:2 GByteOS:HP-UX Itanium 11.23(64bit)Oracle: Oracle Database 10.2.0.5【FCカード】ポート数:2Port × 1枚転送速度:2Gbps/port【ストレージ】型名:SANRISE9570Vインターフェース:FCポート数: 2Port × 2枚通信速度:2Gbps/port【DISK】DISK数(HDD) :12 (146GB * 12)31SANRISE9570VPort#0 Port#1Ctrl#1Port#A Port#BCtrl#0Port#A Port#B日立Unixサーバ8Gb/s×16測定ケース 旧環境 「RAC on SSD」パラレル度 2 20Partition数 16 24圧縮 無効 有効物理メモリ(搭載) 2GB 96GBメモリ(Oracle割当) 1GB 45GBSQL実行時間合計 3:37:31 00:01:34約138倍高速最新モデルと旧環境では条件が大きく異なるため、単純な比較はできません。ただし、お客様の旧環境も同様に古いH/Wを使用している場合には、実際に大幅な性能向上が期待できます。(旧環境)
  33. 33. © Hitachi, Ltd. 2013. All rights reserved. 325.まとめ
  34. 34. © Hitachi, Ltd. 2013. All rights reserved.5. まとめ33 オープンで信頼性の高いプラットフォームオープンIAサーバを利用した通常のRAC構成。AP移行も安心。通常のLinux/Windowsサーバ。バックアップ、監視ソフトも問題なし。高信頼サーバ/ストレージと、あらゆる箇所の冗長構成でサービスを止めない。 実証された構成、でも柔軟な選択構成選定やH/Wチューニングの手間をかけずに性能と信頼性を両立できる。サーバCPU、メモリ量、SSD容量を処理内容に応じて調整できる。Oracleライセンス/サポートを抑えられる様に少ないコア数でも構成できる。 その鍵はSSDHDD⇒SSDだけでは効果薄、通り道のネックを全部排除してSSDを生かす。OracleDBのI/Oパターンは、SSDと相性がよい。オンラインのみならず、バッチ、分析処理の大幅な高速化を実現できる高速化と信頼性を両立するDB高速化ソリューション
  35. 35. © Hitachi, Ltd. 2013. All rights reserved.• OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標です。• Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。• Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。• その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。• 製品の改良により予告なく記載されている仕様が変更になることがあります。他社商品名、商標等の引用に関する表示34

×