[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成

目指せExadata!! Oracle DB 高速化を目指した構成 宇佐美 茂正 2014/11/26

自己紹介 • • • • P2 氏名：宇佐美 茂正（うさみ しげまさ） 勤務先：ヤフー株式会社 職種：DBA 業務 – DB環境構築 – 運用業務 – チューニング – DB監査 – Oracle関連の業務を主に担当 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

このセッションの概要 ExadataはストレージデバイスにSSD、ノード間通信、ストレー ジ間通信にInfiniBand、そしてストレージノード側に独自のシ ステム Exadata Smart Scanを搭載し最強、最高のパフォー マンスを謳っています。 しかしその導入コストは非常に高く、敬遠しているユーザー も多いのが現状です。 弊社では、このExadataに迫るパフォーマンスのDB システム 構成を検討し、今年の２月に導入に至っています。 このセッションでは、弊社のOracle高速DBシステムの構成と、 行ってきた検証や性能比較、そして問題点は何処に有るの かを明らかにしたいと思います。 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P3

アジェンダ P4 • 弊社のRDB運用状況の紹介 • SSD x InfiniBandの構成 – 具体的な構成、使っている技術 etc… • パフォーマンス比較 -HDD x 10G、ODA、Exadataとの比較 • 問題点 – 経験した障害とその原因 • 今後 – 更なる性能改善 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

弊社のRDB運用状況の紹介 運用体制、規模感、etc… Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

「全社DB」と呼ばれるプロジェクトがあります • 全社DB 社内のRDBを統括管理するプロジェクト 弊社の各サービスの為にDB関連業務を行っています。 DB環境構築、チューニング、運用、監査、etc… • 目的 – コスト削減 • 複数のサービス用DBを集約して運用 • DBサーバ、ストレージ等の機器の共有 – 工数削減 • サービス、開発側はDB環境構築、運用に携わらなくていい – セキュリティ • DBアクセスの監査 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P6

全社DBプロジェクトで運用しているDB 運用DB数 582 DBサーバ数 330 • DB数 187 • バージョン Oracle 11.2.0.2、 11.2.0.4 • DB数 395 • バージョン MySQL 5.1、 5.5 利用サービス 広告、ヤフオク!、Yahoo!ショッピング Yahoo!ニュース、Yahoo!トラベル Yahoo!天気、Yahoo!スポーツ Yahoo!知恵袋、Yahoo!ブログ Yahoo!きっず、etc… Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P7

PCI-SSD x InfiniBandの構成 具体的な構成、使っている技術、etc… Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

システム構成の概要図 IB HCA IB HCA IB HCA P9 IB HCA IB HCA DB node 2 DB node 1 IB HCA DB node 3 InfiniBand Switch InfiniBand Switch Network 01(56Gbps) IB HCA Storage node 5 PCI-SSD PCI-SSD Storage node 6 • データベース用のストレージデバイスは全てSSD • データベースシステム内での通信は全てInfiniBand Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 IB HCA LUN PCI-SSD IB HCA LUN Storage node 4 PCI-SSD IB HCA LUN PCI-SSD IB HCA LUN Storage node 3 PCI-SSD IB HCA LUN PCI-SSD IB HCA LUN Storage node 2 PCI-SSD IB HCA LUN PCI-SSD Verident PCI-SSD IB HCA LUN Storage node 1 PCI-SSD IB HCA LUN PCI-SSD Verident PCI-SSD IB HCA LUN LUN LUN PCI-SSD IB HCA Network 02(56Gbps)

ハードウェアとソフトウェアの構成 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

PCI-SSDに関して P11 • Virident FlashMaxIIを採用 HGST社製のSSD製品 • 特徴 Readの性能がかなり速い カード自身にガベージ・コレクションの機能が入っておりサー バ側のCPU負荷を抑える • RDBとの相性 Write性能は他社製品のFusion-ioの方が優れていた。 大半のDBではReadの割合が多いためReadの性能を重視 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

InfiniBand Switch に関して P12 • Mellanox製 InfiniBand Switchを採用 製品名 SX6036（エッジスイッチ） • 特徴 • 1Uスイッチに36 FDR ( 56Gbps ) ポート • InfiniBandとEthernet接続をサポート • IPoIBで通常のEthernetと同じように通信も可能 • 4.032Tb/s のスイッチング能力 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

DBノードのOS & ハードウェア構成 • DBサーバ機器 Fujitsu RX200 S8 • 構成 • CPU : E5-2667 ( 6コア 12スレッド ) x 1 • メモリ : 128GB • NIC : 1Gbps Eth x 4 Bonding用 • 富士通製 FDR InfiniBand HCA (Dual Port) • 56Gb/s • ドライバはMellanox製のOFED • OS ＆ Oracle Software OS : Oracle Linux 6.4 Oracle Database : 11.2.0.4 Grid Infrastructure : 11.2.0.4 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P13

ストレージノードのOS & ハードウェア構成 • ストレージサーバ機器 Fujitsu RX200 S8 • 構成 • CPU : E5-2630L ( 6コア 12スレッド ) x 1 • メモリ : 32GB • NIC : 1Gbps Eth x 2 • 富士通製 FDR InfiniBand HCA (Dual Port) • 56Gb/s • ドライバはMellanox製のOFED • Virident FlashMaxⅡ(2.2 TB) x 2 • OS Oracle Linux 6.4 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P14

InfiniBandネットワークでの通信 利用プロトコルとその内容 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

本システムでのInfiniBand通信 IB HCA IB HCA IB HCA IB HCA IB HCA DB node 2 DB node 1 P16 IB HCA DB node 3 InfiniBand Switch InfiniBand Switch Network 01(56Gbps) IB HCA Storage node 5 • DBサーバ間で発生するOracle Interconnect 通信 PCI-SSD IB HCA LUN PCI-SSD IB HCA LUN Storage node 4 PCI-SSD IB HCA LUN PCI-SSD IB HCA LUN Storage node 3 PCI-SSD IB HCA LUN PCI-SSD IB HCA LUN Storage node 2 PCI-SSD IB HCA LUN PCI-SSD Verident PCI-SSD IB HCA LUN Storage node 1 PCI-SSD IB HCA LUN PCI-SSD Verident PCI-SSD IB HCA LUN LUN LUN PCI-SSD IB HCA Network 02(56Gbps) PCI-SSD Storage node 6 • IPoIB • DBサーバとストレージサーバ間で発生するSSDデバイスへのI/O通信 • iSER Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

IPoIB (IP over InfiniBand)の概要 P17 • InfiniBand上にIPネットワーク層を構成するサービス • InfiniBand HCAの各ポートにIPを割り振ることが出来る • Ethernetと同様に通信可能 • InfiniBandネットワーク経由でIP指定でEthernetと同様に処理 が行えます • 例えばSSHやSCPコマンドも使えます • 但しこの使い方ではInfiniBand特有の低レイテンシな通 信は得られません • ただの帯域が広いEthernetと言う感じの使い方 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

iSER (iSCSI Extensions for RDMA)の概要 P18 • iSCSIとはリモートサーバのLUNを自分のローカルデバイ スのように見せてI/Oすることが出来るプロトコルです。 • iSCSI上でRDMA通信を利用可能にしているのがiSER • iSCSIのターゲット側の設定を変更する事で簡単に利用 可能です • パラメータ「default-driver = iser」を設定するのみ • オペレーションや各種設定はiSCSIとほぼ同様に可能 • 通常のiSCSIに比べて低レイテンシーなI/Oが可能となる Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

RDMA(Remote Direct Memory Access)通信 アプリケーション1 User Kernel OS P19 アプリケーション2 バッファ1 バッファ1 バッファ1 バッファ1 OS バッファ1 NIC RDMA over InfiniBand Hardware IB HCA NIC バッファ1 IB HCA TCP/IP Node 01 • • • • Node 02 TCP/IP通信はノード内の各レイヤーでのバッファのコピーが必要 それに比べRDMA通信は直接送信先メモリへ転送することが可能 通信に必要なスタックが減り低レイテンシーが実現 また、スタックが減る為CPUの使用率低下にも期待できる Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

ストレージの設定 SSDデバイスをASMに登録するまでの流れ Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

DM-Multipath の概要 Server P21 Mapping Device device 1 device 2 HBA 1 HBA 2 SAN 1 SAN 2 Controler 1 Controler 2 Storage Raid Group LUN • デバイスマッパーマルチパッシング • 異なる経路で認識させた独立したデバイスを統合可能 • パスの多重化による可用性とパフォーマンスの向上が期待できる Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

新構成のストレージデバイス設定(概要図) dm-01 (MULTIPATH DEVICE) DB node IB HCA P22 ×N IB HCA iSER iSER IB Switch IB Switch Network 02 Network 01 56Gbps Storage node 56Gbps IB HCA IB HCA Partition PCI-SSD • 2つのInfiniBandネットワークは独立させています • これを利用してSSDデバイスをマルチパスでDBノードに認識させます • Active/Activeでパスを利用し且つ可用性も担保する事を狙った構成です。 • 56Gbps x 2 で 112GbpsのI/O帯域となります Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

ASMに登録する P23 ASM Disk Group Storage Node 02 Storage Node 01 FAIL GROUP 01 Storage Node 03 FAIL GROUP 02 ※ディスクグループ作成 ( 例 ) data1 mirror FAIL GROUP 03 data1 CREATE DISKGROUP <Disk Group Name> data2 data2 NORMAL REDUNDANCY mirror FAILGROUP ST01 DISK ‘/dev/ST01_DISK01'data3 NAME ST01_DISK01 data3 FAILGROUP ST01 DISK ‘/dev/ST01_DISK02'mirror NAME ST01_DISK02 FAILGROUP ST02 NAME ST02_DISK01 Disk1 Disk5 Disk3 Disk2 DISK ‘/dev/ST02_DISK01' Disk6 Disk4 ～ 全ディスクを羅列 ～ • 作成したマッピングデバイス群でASMを構成 ATTRIBUTE 'compatible.asm' = '11.2.0.0.0', • ストレージレベルの障害を考慮して障害グループを設定 'compatible.rdbms' = '11.2.0.0.0', • ストレージノード毎にグルーピングしたDisk群で障害グループを構成 'compatible.advm' = '11.2.0.0.0'; Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

システム構成の全体像 P24 Oracle Grid Infrastructure High Performance • Storage • SSD • 112Gb/s • RDMA • Interconnect • 112Gb/s DB Instance 2 DB Instance 1 RAC DB Oracle ASM (Auto Storage Manager) IB HCA IB HCA IB HCA IB HCA IB HCA DB node 2 DB node 1 IB HCA DB node 3 InfiniBand Switch InfiniBand Switch Network 01(56Gbps) IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 1 High Availability • Storage • Multipath • ASM Mirror • Interconnect • IB NW x 2 DB Instance 3 IB HCA Partition 1 PCI-SSD Network 02(56Gbps) IB HCA Partition 1 PCI-SSD Storage node 2 IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 3 IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 4 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 5 IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 6

障害時の動作テスト サーバやIBスイッチの障害を想定したテスト Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

実施した障害テスト一覧 大分類 テスト内容 P26 想定の動作 ストレージサーバのIB NW 2重障害 ASMテスト (ストレージ関連の障害) ストレージサーバ DOWN 対象ストレージのDiskがOFFLINEとなる tgtd プロセス障害 ASM プロセス障害 対象DBサーバのASM, DBインスタンスで 再起動が発生する サービス NW 2重障害 生存DBノードにVIPのフェイルオーバー 対象DBサーバのDB ServiceはDOWNする DBサーバの IB NW 2重障害 RACテスト 対象DBサーバがクラスタから切り離される DBサーバ DOWN IBスイッチ テスト DB インスタンス プロセス障害 対象DBインスタンスの再起動が発生 IBスイッチ 片系障害 マルチパスの対象パス切り離される DBサーバダウンは発生しない Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

障害テストで想定外の挙動となった点 P27 • マルチパスのパス障害時の挙動 – 特定ストレージノードのDOWN • 想定 – 対象ストレージノードのDisk OFFLINEが発生 • 実際 – Disk GroupがDismountされ全クラスターダウン – IBスイッチの片系障害 • 想定 – パスの切り離しが発生するがクラスターは稼動を続ける • 実際 – Disk GroupがDismountされ全クラスターダウン Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

パスの切り離しがうまく行かなかった原因 • ASMのメタデータ更新に失敗 – 11.2.0.4ではASMのメタデータ更新のタイムアウトが15秒 – これが出来なかった場合、対象Disk GroupはDismountされる – パスの障害検知はこの時間内に完了させる必要がある • マルチパス障害検知に関わる設定 – iSCSI • 死活監視間隔 5秒 – node.conn[0].timeo.noop_out_interval = 5 • 死活監視がエラーと判断するまでの待ち時間 5秒 – node.conn[0].timeo.noop_out_timeout = 5 • 復旧待ち時間 120秒 – node.session.timeo.replacement_timeout = 120 iSCSIセッションが切れた際にエラーと判断されるまでに、126～130秒 – Multipath • パスのチェック間隔 5秒 – polling_interval = 5 • パスチェック時のリトライ 0回 – no_path_retry = 0 パスの障害と判断されるまでに、1～5秒 パスの経路障害と判断されるまでに、127～135秒掛かる Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P28

パフォーマンスの比較 • • • • HDD x 10G ODA Exadata SSD x IB Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

HDD x 10G P30 DB node 1 【機器】 • DBサーバ • 台数 : 3台 • 機種 : HP DL360 G7 Storage Network • CPU : E5-2643(4コア)x2 10G Ethernet • メモリ : 72GB DB Storage 01 • OS : Oracle Linux 5.9 • DB • • • DB node 3 DB node 2 Interconnect Network 1G Ethernet DB Storage 02 Storage : NetApp 台数 : 3台 機種 : FAS 3270 構成Disk : SAS HDD (15K rpm) x 51 【ネットワーク】 • ストレージ間ネットワーク(SAN)： 10G Ethernet (10BASE-SR) • ノード間通信ネットワーク(Interconnect NW)： 1G Ethernet Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 DB Storage 03

ODA ( Oracle Database Appliance) P31 Oracleのアプライアンス製品 【機器】 • DBサーバ • 台数 : 2台 • CPU : E5-2697(12コア) x 2 • メモリ : 256GB • DB Storage • 機種 : 製品付属のストレージシェルフ • 構成Disk • SAS HDD (10K rpm) x 20 ( データファイル 格納用 ) • SSD x 4 ( Redo 格納用 ) 【ネットワーク】 • ストレージ間ネットワーク(SAN)： 6Gb/s (SAS-2 HBA) • ノード間通信ネットワーク(Interconnect NW)： 1G Ethernet (クロスケーブル) Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

Exadata (X2-2 Full RAC) Oracleのアプライアンス製品 【機器】 • DBサーバ • 台数 : 8台 • CPU : X5670(6コア) x 2 • メモリ : 96GB • DB • • • Storage 機種 : 製品付属のストレージサーバ群 台数 : 14台 構成Disk • SAS HDD (15K rpm) x 28 ( データファイル ＆ REDO 格納用 ) • Flashデバイス ( Oracle DB 2次キャッシュ用 ) 【ネットワーク】 • ストレージ間ネットワーク(SAN)兼 ノード間通信ネットワーク(Interconnect) • InfiniBand QDR 40Gb/s Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 P32

IO性能比較 秒間 I/O, 転送量, レイテンシ Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

IO性能の測定方法

P34

• CALIBRATE_IOプロシージャー を利用
• DBシステムのストレージ性能の測定が可能
• システムが耐えられる 秒間 I/Oリクエスト
• システムが耐えられる 秒間 I/O MB
• MAX I/O時のレイテンシ
SET SERVEROUTPUT ON
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (8, 10, iops, mbps, lat);

DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/
Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

MAX MBPS (最大秒間 転送量) P35 MAX MBPS 25000 19771 20000 17516 15000 10000 5000 4587 3085 0 ODA HDD x 10G Exadata Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 SSD x IB

MAX IOPS (最大秒間 I/O リクエスト) P36 MAX IOPS 1400000 1153229 1200000 1000000 800000 600000 400000 268875 200000 111338 17112 0 ODA HDD x 10G Exadata Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 SSD x IB

MAX IOPS時の平均待機時間(ミリ秒) P37 LATENCY 9 8 8 8 7 6 5 4 3 レイテンシ 1ミリ秒以下 2 レイテンシ 1ミリ秒以下 1 0 0 ODA HDD x 10G 0 Exadata Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 SSD x IB

SQLの性能比較 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

SQLパフォーマンスの比較方法 P39 • Swingbench • 概要 • Oracleに擬似的に負荷を掛けるアプリのように動作する • Java動作 • テーブルとデータの作成、スループットの表示をやってくれる • ベンチマークの種類 下記のテンプレートが用意されている カスタマイズも可能 名前 説明 Read/Write 割合 Max size Order Entry TCP-C(OLTP系) 6:4 100GB Calling Circle Oracle版 OLTP ベンチマーク 7:3 100GB Stress Test 単純な負荷を掛ける ストレステスト 5:5 - Sales History TCP-Hベース(DWH系) 10 : 0 1TB ※ この測定に関してはExadata(X2-2)環境では取得できていません Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

秒間トランザクションの比較 (TPS) P40 TPS 9000 8000 7880 7932 7000 6821 6000 5000 4000 3756 3710 966 981 3000 2539 2000 1000 0 2030 649 870 293 10 100 300 Session Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 500 ODA HDD x 10G SSD x IB

検証時のCPU使用率(%) P41 CPU 100 100 100 100 70 70 90 80 70 60 60 50 40 60 50 40 ODA HDD x 10G SSD x IB 40 30 20 20 10 10 0 10 100 300 Session Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 500

平均レスポンスタイム(ミリ秒) P42 Average Responce Time 10,000 1153 1,000 689 219 100 10 68 36 33 11 13 106 95 49 4 1 10 100 300 Session Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 500 ODA HDD x 10G SSD x IB

TOP5 待機イベントの割合(10 Session時) direct path enq: KO read fast object checkpoint gc current block 2way db file parallel read ODA gc buffer busy acquire log file sync P43 read by other session HDD x 10G DB CPU db file gc current sequential block 2-way read gc cr grant SSD 2-way db file sequential read x IB ■ ODA db file sequential read のWaitが多い log file sync DB CPU db file sequential read ■ HDD x 10G db file sequential read のWaitが多い ■ SSD x IB db file sequential read のWaitの割合が減少 CPU処理時間が50% Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

TOP5 待機イベントの平均待機時間(ms) P44 10 Session 時 ODA HDD x 10G SSD x IB db file sequential read 7 db file sequential read 3 DB CPU - DB CPU - log file sync 1 db file sequential read 0 enq: KO – fast object checkpoint 9 gc current block 2-way 0 log file sync 0 direct path read 7 gc buffer 3 busy acquire gc cr grant 2-way 0 read by other session gc current block 2-way 0 db file 10 parallel read 5 SSD x IBの構成は処理における各イベントの待機時間が少なくなっています Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

TOP5 待機イベントの平均待機時間(ms) P45 100 Session 時 ODA HDD x 10G db file sequential read 15 db file sequential read direct path read 143 enq: KO – fast object checkpoint DB CPU Log file sync 3 gc buffer 8 busy acquire DB CPU - 167 enq: TX – row lock content 11 Db file sequential read 1 - log file sync 1 gc cr grant 2-way 0 read by other session 11 gc current block 2-way 0 db file 27 parallel read 8 SSD x IB 10セッション時と同様に、 SSD x IBの構成は処理における各イベントの待機時間が少なくなっています Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

新構成へ移行したDBの性能 HDD x 10G ⇒ SSD x IB Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

SQLの実行時間とI/O時間の比較 対象SQL SQLその１ SQLその2 P47 比較項目 従来構成 HDD x 10G 新構成 SSD x IB 実行時間(s) 10.63 0.10 I/O時間 10.41 0.07 DB CPU(%) 0.6 32.1 I/O(%) 97.9 70.6 実行時間(s) 20.29 0.13 I/O時間 20.18 0.09 DB CPU(%) 0.5 33.1 I/O(%) 99.5 70.6 • パフォーマンスが問題となっていたSQLの性能を比較しました • SQLその１ • 実行時間が10秒掛かっていたものが0.1秒に減少 • I/Oに掛かっていた時間が大幅に減少した為 • SQLその２ • 実行時間が20秒掛かっていたものが0.1秒に減少 • I/Oに掛かっていた時間が大幅に減少した為 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

待機クラスの比較 Wait Class User I/O Commit Cluster DB CPU • • • • • P48 項目 従来構成 HDD x 10G 新構成 SSD x IB DB Time(%) 79.3 3.5 Avg Wait(ms) 53 0 DB Time(%) 4.3 0.2 Avg Wait(ms) 83 1 DB Time(%) 3.7 0.4 Avg Wait(ms) 12 0 DB Time(%) 13.7 56.3 Avg Wait(ms) - - 移行前の環境で上位に来ていた待機クラスで比較 User I/Oの待機クラスの割合が80%を占めていたが移行後は3.5%に減少 Commitの待機クラスも減少 Cluster ( クラスタ関連処理 ノード間通信 etc…)も減少 他の待機クラスが減りDB処理時間の割合はCPUが大半を占めるようになった Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

性能比較のまとめと価格面のメリット P49 【パフォーマンス】 • 速い！ – SQL実行時間が平均で10倍速い – 物理読込が多いSQLでは100倍程速かった – IO関連の待機イベントが大幅に減っている – Cluster系の待機イベントに関しても多少改善 が見られた 【価格】 • 弊社の従来構成とほぼ同額で導入可能 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

問題点 経験した障害とその原因 Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

ストレージ間通信の失敗による障害 IB HCA IB HCA IB HCA DOWN I/O Error DB node 1 IB HCA IB HCA DB node 2 P51 IB HCA DB node 3 InfiniBand Switch InfiniBand Switch Network 01(56Gbps) Network 02(56Gbps) IB HCA Storage node 2 PCI-SSD IB HCA LUN PCI-SSD Verident PCI-SSD IB HCA LUN Storage node 1 PCI-SSD IB HCA LUN PCI-SSD Verident PCI-SSD IB HCA LUN LUN LUN PCI-SSD IB HCA PCI-SSD Storage node 3 • I/Oの失敗が続きOracleの自発的パニックリブート発生 ※Voting DiskへのI/Oやノード間通信が規定時間以上途絶えると Oracleの自発的パニックリブートが発生します Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

InfiniBand通信の設定が原因 アプリケーション1 User P52 アプリケーション2 バッファ1 バッファ1 RDMA通信 Hardware IB HCA IB HCA IP over InfiniBand Node 01 Node 02 • 通信時のバッファが連続領域で確保されていました • IPoIBの設定が絡んでいます • メモリが枯渇すると通信に失敗する可能性が高まります • 設定を変える事でこれは回避できる ※メラノックス製InfiniBandスイッチ、ドライバの不具合ではありません Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

今後 更なる性能改善を狙ってみたい Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

RDS over InfiniBand IB HCA IB HCA DB node 1 IB HCA P54 IB HCA DB node 2 IB HCA DB node 3 InfiniBand Switch InfiniBand Switch Network 01(56Gbps) IB HCA Oracle Interconnect UDP ↓ RDS Network 02(56Gbps) • Oracleのインターコネクト通信ではUDPと「RDS」が利用可能 • RDS(Reliable Datagram Socket) – InfiniBand上でRDMA通信が可能 • 導入するとCluster関連の待機イベントの改善が期待できる Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

Smart Flash Cacheの利用 P55 DB Instance Datafiles Flash Cache Oracle ASM (Auto Storage Manager) DB node 1 DB node 2 DB node 3 • PCI-SSD x InfiniBandで構成したDiskグループをOracle の二次キャッシュ領域として利用 • 設定は容易（DBパラメータ） • DB_FLASH_CACHE_FILE ( ASM or OS上でパスを指定 ) • DB_FLASH_CACHE_SIZE ( サイズを指定 ) • 二次キャッシュの方が性能が出るのではないか？ Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

最後に Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

I/O性能が改善される事によるメリット P57 【従来構成】 • 従来構成ではI/O処理がかなりネックになっていた • これはDBシステムが理想とする本来の姿ではない • CPUライセンスを払っているのに実際ネックになっているのはI/O • CPUリソースを使い切る前にI/Oが限界を迎えてしまう • 増設や移行計画はCPUリソースを使い切った末に検討されるのが理想 【新構成】 • 新構成ではI/Oがネックになっていた部分が解消された • その結果DB処理時間の大半がCPU実行時間に変わっています • CPUリソースを使い切る理想的なシステム構成になった • 高いOracleのポテンシャルを最大限に発揮できるようになった Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

ご清聴ありがとうございました