MySQL+ioDrive2+LifeKeeper検証結果資料

Size: px

Start display at page:

Download "MySQL+ioDrive2+LifeKeeper検証結果資料"

なおちかめいこ
5 years ago
Views:

1 高速高可用性 DB ソリューション MySQL + iodrive2 + LifeKeeper 検証結果について

2 アジェンダ 1. 高速高可用性 DB ソリューション 2. MySQL + iodrive2 + LifeKeeper 検証結果 3. まとめ 2

3 高速高可用性 DB ソリューション 3

4 ハードウェアの技術革新ハードウェアの技術革新高速化が進む CPU Quad Dual Core Core Many Core ネットワークの大容量化 Infiniband, 10G Ethernet ストレージボトルネックの解消半導体テクノロジーサーバーサイドフラッシュという手法が流行 4

5 盛り上がるサーバーサイドフラッシュサーバーサイドフラッシュとは? PCIe カード型のフラッシュストレージを使いデータの I/O 性能を上げる事例が増えているサーバーにフラッシュメモリーを直結するためサーバーサイドフラッシュとも呼ばれる手法ストレージに SSD ( ソリッドステートドライブ ) を搭載する手法に比べレイテンシー ( 遅延 ) を 3 桁改善できる先行ユーザー : 多くのクラウドサービスウェブサービス企業で導入されている主要ベンダー : Fusion-io 社をはじめとするハードウェアベンダーから提供されている 5

6 サーバーサイドフラッシュの課題可用性をどのように担保するか? 6

iodrive と LifeKeeper を用いた高速高可用性 DB ソリューションサーバーサイドフラッシュソリューション LifeKeeper 採用のメリット iodrive iodrive オプションモジュール (DataKeeper) によりネットワーク越しの RAID 構成が可能 HA + ネットワーク RAID によりデータ二重化サービス切替を同時に実現!

7 iodrive と LifeKeeper を用いた高速高可用性 DB ソリューションサーバーサイドフラッシュソリューション LifeKeeper 採用のメリット iodrive iodrive オプションモジュール (DataKeeper) によりネットワーク越しの RAID 構成が可能 HA + ネットワーク RAID によりデータ二重化サービス切替を同時に実現! ブロックレベルの完全同期レプリケーションで DB 整合性も確保 iodrive 採用時の課題を解決 iodrive とは Fusion-io 社製 NAND フラッシュベース高速半導体ストレージ SSD と比較して数倍のパフォーマンス /10-50 倍の耐久性 PCIe 接続であり RAID コントローラ不要 iodrive + LifeKeeper 連携による効果レプリケーション型の HA 構成となるため共有ディスクの SPOF ( 単一障害点 ) を排除 iodrive は超高速ストレージであるため同期レプリケーションであっても高パフォーマンスを実現

8 Fusion-io iodrive のメリットサーバー統合率の向上サーバー統合により電源冷却コストの削減アプリケーション性能の向上 I/O ボトルネックを解消しアプリケーションの性能を大幅に向上実績と信頼性市場のリーダーほぼすべての大手サーバーベンダーから OEM 製品で供給 iodrive2 広範囲にわたり安定した超低レイテンシ性能を提供し信頼性の高い革新的機能によってエンタープライズデータベースアプリケーション仮想化クラウド環境の性能を最大化します 8

9 iodrive を活用したデータベースベンチマーク圧倒的な処理速度の差 TPS iodrive は同時実行数が増えてもパフォーマンスが頭打ちにならず処理可能 SAS iodrive 同時実行数 TPS =1 秒当たりの処理数同時実行数 = 同時に実行する数サイオスによる検証結果 9

10 MySQL 最新情報 MySQL RC ( リリース候補版 ) InnoDB : 強化ポイントの1つパフォーマンスとスケーラビリティを向上半導体ストレージに対する強化を実施古いmutexを排除 CPUキャッシュの共有スレッドの改良と同時実効性の向上参照専用トランザクションによる参照性能の向上運用や開発の柔軟性を向上表領域 ( データファイル ) をOSコマンドでコピー NoSQL, InnoDBへのキーバリュー型でのアクセス 10

11 MySQL + iodrive2 + LifeKeeper 検証結果 11

12 検証の目的 LifeKeeper による同期レプリケーションを MySQL の最新 RC 版である v5.6.7 及び iodrive2 の環境下で性能測定することにより高速高可用性データベースソリューションとして実用的な性能を発揮できるかどうか検証する 12

13 検証の概要汎用データベース負荷テストツール jdbcrunner を使った RDBMS に対する OLTP ベンチマーク検証を実施 TPC-C を簡易実装したトランザクションを実行テスト用テーブルのレコード数は 600( 実データサイズ約 100GB) 検証環境 Red Hat Enterprise Linux bit iodrive2 に ext4 ファイルシステムを作成しデータレプリケーション領域とする OS およびシステムファイルは内蔵 SAS HDD に配置物理メモリ 32GB データレプリケーション用の通信パスに 10Gbps Ethernet を使用 13

14 ハードウェア構成負荷生成サーバ 1 号機 CPU :Xeon E GHz * 2 MEM :12GB HDD :SAS 10000rpm 147GB 2 負荷生成サーバ 2 号機 CPU :Xeon E GHz * 2 MEM :12GB HDD :SAS 10000rpm 147GB 2 SWITCH L2SW DB サーバ 1 号機 (Active) CPU :8C E GHZ * 2 MEM :32GB HDD :SAS 15000rpm 146GB 3 (RAID0) 追加 NIC : 2port 10GbE NIC 10Gb Cable DB サーバ 2 号機 (Standby) CPU :8C E GHZ * 2 MEM :32GB HDD :SAS 15000rpm 146GB 3 (RAID0) 追加 NIC : 2port 10GbE NIC iodrive : iodrive2 2.4TB MLC iodrive : iodrive2 2.4TB MLC 14

15 ソフトウェア構成 / データ配置負荷生成サーバ 1 号機負荷生成サーバ 2 号機 JDBCRunner Tiny TPC-C JDBCRunner Tiny TPC-C Red Hat Enterprise Linux Red Hat Enterprise Linux DB サーバ 1 号機 (Active) DB サーバ 2 号機 (Standby) Mysql 5.5/5.6 LifeKeeper MySQL ARK data Real Time Replication sync data Mysql 5.5/5.6 LifeKeeper MySQL ARK LifeKeeper v8.0 Protection Suite for Linux ext4 ext4 LifeKeeper v8.0 Protection Suite for Linux Red Hat Enterprise Linux 6.2 Red Hat Enterprise Linux 6.2 Hardware iodrive2 iodrive2 Hardware 15

性能測定結果について tps 1800 1600 1400 1200 jdbrunner Benchmark Result (scalefactor=600) 1 MySQL 5.5 と 5.6.7 の性能測定結果 2 LifeKeeper による同期レプリケーション時 MySQL5.

MySQL5.5 + iodrive2 + LK 8.0 600 400 200 0 MySQL5.5 と 5.6.7 の比較では約 20% スループットが改善している ( 同時実行数 64 の場合 ) MySQL5.

16 性能測定結果について tps jdbrunner Benchmark Result (scalefactor=600) 1 MySQL 5.5 との性能測定結果 2 LifeKeeper による同期レプリケーション時 MySQL iodrive2 MySQL iodrive2 + LK 8.0 MySQL5.5 + iodrive MySQL5.5 のレプリ無しと比較しても上回っている! MySQL5.5 + iodrive2 + LK MySQL5.5 との比較では約 20% スループットが改善している ( 同時実行数 64 の場合 ) MySQL5.6.7 での同期レプリケーション時は無しの場合と比較して約 11% 程度の低減 ( 同時実行数 64 の場合 ) 同時実行数 16

17 チューニングポイント iodrive2 を使用することにより I/O ネックが解消されると新たなボトルネックに遭遇するケースが多い CPU メモリネットワーク OS DBMS アプリケーション etc iodrive2 の高速 I/O 性能を十分に活かすためにはボトルネックを作らないことが重要 17

iodrive Source Volume Async Write Queue Target Volume 1 Bitmap に変更ブロックに対するフラグを書き込みます 2 変更ブロック情報を Queue に書き込みます

18 チューニングポイント (1)LifeKeeper 1 Bitmap ファイルを iodrive2 上に作成この前提として同期レプリケーションの流れを説明します Application (DBMS) HDD 1 Write Request 2 Write Request 1 (complete) IO Copy HighWater LowWater 3 iodrive 5 2 network Bitmap file 4 iodrive Source Volume Async Write Queue Target Volume 1 Bitmap に変更ブロックに対するフラグを書き込みます 2 変更ブロック情報を Queue に書き込みます 3 Target Volume に変更ブロックの書き込みを行います完了後書き込み完了情報を返送します 4 Source Volume に変更ブロックの書き込みを行います 5 同期が完了したフラグを Bitmap から削除します 18

19 チューニングポイント (1)LifeKeeper 1 Bitmap ファイルを iodrive2 上に作成する ( つづき ) 1. iodrive2 上に Bitmap ファイル用のパーティション及びファイルシステムを作成するパーティションのサイズは 100MB で十分とお考えください例 ) レプリケーション対象ボリューム 500GB チャンクサイズが 64KB の場合 Bitmap ファイルは約 1MB となります 2. データレプリケーション用のリソース作成ウィザードにおいて Bitmap ファイルの配置先として 1. で作成した場所を指定する 19

20 チューニングポイント (1)LifeKeeper 2 Bitmap のチャンクサイズを拡張するチャンクサイズとはメモリ上で更新された情報をファイルシステムに書き戻す ( フラッシュする ) 際の大きさを表します LKDR_CHUNK_SIZE=4096 デフォルト値は 64KB で設定値は 4096KB=4MB に相当します 3 再同期時のデータ転送速度を設定する LKDR_SPEED_LIMIT= LKDR_SPEED_LIMIT_MIN= 単位は KB/s デフォルト値は設定値はそれぞれ 1.5GB/s 200MB/s に相当しますこれらの設定については Source/Target の両ノードの /etc/default/lifekeeper に設定したうえでデータレプリケーション用のリソースを作成します 20

チューニングポイント (2) ネットワーク iodrive2 の高速 I/O と 10GbE の高速通信を活かしたデータ転送を行うために以下のコンフィギュレーションを実施 1 TCP/IP 通信に関するコンフィギュレーション /etc/sysctl.conf の以下の項目を追加 ( もしくは修正します ) net.core.rmem_default net.core.wmem_default net.

21 チューニングポイント (2) ネットワーク iodrive2 の高速 I/O と 10GbE の高速通信を活かしたデータ転送を行うために以下のコンフィギュレーションを実施 1 TCP/IP 通信に関するコンフィギュレーション /etc/sysctl.conf の以下の項目を追加 ( もしくは修正します ) net.core.rmem_default net.core.wmem_default net.core.rmem_max net.core.wmem_max net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 0 net.core.optmem_max net.ipv4.tcp_congestion_control = htcp 受信用ウィンドウサイズのデフォルト値送信用ウィンドウサイズのデフォルト値受信用ウィンドウサイズの最大値送信用ウィンドウサイズの最大値データ受信バッファサイズデータ送信バッファサイズパケットにタイムスタンプを付加しない選択的確認応答 (SACK) を無効最大補助用バッファサイズ輻輳制御モジュールとして H-TCP を選択 21

22 チューニングポイント (2) ネットワーク 2 jumbo frame を有効にするためのコンフィギュレーション /etc/rc.d/rc.local に以下を追加します /sbin/ifconfig <interface_name> mtu <MTU 値 > 3 送信パケットキューサイズを拡張するためのコンフィギュレーション /etc/rc.d/rc.local に以下を追加します /sbin/ifconfig <interface_name> txqueuelen <queue_size> 4 プロセッサ毎の入力キューサイズの最大値を設定する /etc/sysctl.conf に以下を追加します net.core.netdev_max_backlog = <max_backlog> 22

(ご参考) Clustering with Fusion-io http://docs.us.sios.com/linux/8.1/lk4l/techdoc/index_left.

23 (ご参考) Clustering with Fusion-io %2Finstallation_configuration%2Fclustering_with_fusion_io.htm StartTopic=Content% 2Fdatakeeper%2Finstallation_configuration%2Fclustering_with_fusion_io.htm SkinNa me=silverskin 23

24 iodrive2に関する留意点 iodrive2のドライバを最新のものにする今回の検証ではVSL3.1.5を使用使用するドライバは各OEMベンダもしくはfusion-io社のサイトから調査いただいてから導入してください iodrive2を初期化する fio-format によりioDrive2を初期状態に一度リセットします fio-format で初期化する際にユーザ使用可能領域を小さくし強制的に空き容量を確保します* (オーバープロビジョニング) * 今回は書き込み負荷が高いベンチマークテストのために実施 24

25 MySQL に関する設定半導体ストレージ (iodrive) を意識した設定シーケンシャルアクセスの利点がないため周辺ページを I/O しないように設定する innodb_flush_neighbors = false innodb_random_read_ahead = false innodb_read_ahead_threshold = 0 その他でのチューニングポイント innodb_checksum_algorithm = 'crc32' innodb_page_size = 16K 25

26 まとめ 26

27 まとめ今回ご紹介した MySQL + iodrive2 + LifeKeeper の構成で高速高可用性データベースソリューションとして十分な環境をご提供できます iodrive の高速 I/O 性能を十分に活かすためにはボトルネックを作らないことが重要です MySQL5.6.7 では 5.5 と比較してパフォーマンスもスケーラビリティも向上しています 27

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc Article ID: NVSI-050110JP Created: 2005/10/19 Revised: - NetVault 仮想テープライブラリのパフォーマンス検証 : dothill SANnetⅡSATA 編 1. 検証の目的ドットヒルシステムズ株式会社の SANnetll SATA は安価な SATA ドライブを使用した大容量ストレージでディスクへのバックアップを行う際の対象デバイスとして最適と言えます