高速 高可用性 DB ソリューション MySQL + iodrive2 + LifeKeeper 検証結果について
アジェンダ 1. 高速 高可用性 DB ソリューション 2. MySQL + iodrive2 + LifeKeeper 検証結果 3. まとめ 2
高速 高可用性 DB ソリューション 3
ハードウェアの技術革新 ハードウェアの技術革新 高速化が進む CPU Quad Dual Core Core Many Core ネットワークの大容量化 Infiniband, 10G Ethernet ストレージボトルネックの解消 半導体テクノロジー サーバーサイドフラッシュ という手法が流行 4
盛り上がるサーバーサイドフラッシュ サーバーサイドフラッシュとは? PCIe カード型 のフラッシュストレージを使い データの I/O 性能を上げる事例が増えている サーバーにフラッシュメモリーを直結するため サーバーサイド フラッシュ とも呼ばれる手法 ストレージに SSD ( ソリッド ステート ドライブ ) を搭載する手法に比べ レイテンシー ( 遅延 ) を 3 桁改善できる 先行ユーザー : 多くのクラウドサービス ウェブサービス企業で導入されている 主要ベンダー : Fusion-io 社をはじめとするハードウェアベンダーから提供されている 5
サーバーサイドフラッシュの課題 可用性をどのように担保するか? 6
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 は超高速ストレージであるため 同期レプリケーションであっても 高パフォーマンスを実現
Fusion-io iodrive のメリット サーバー統合率の向上 サーバー統合により 電源 冷却コストの削減 アプリケーション性能の向上 I/O ボトルネックを解消し アプリケーションの性能を大幅に向上 実績と信頼性 市場のリーダー ほぼすべての大手サーバーベンダーから OEM 製品で供給 iodrive2 広範囲にわたり安定した超低レイテンシ性能を提供し 信頼性の高い革新的機能によってエンタープライズ データベース アプリケーション 仮想化 クラウド環境の性能を最大化します 8
iodrive を活用したデータベースベンチマーク圧倒的な処理速度の差 TPS 3000 2500 2000 1500 1000 iodrive は 同時実行数が増えても パフォーマンスが頭打ちにならず 処理可能 SAS iodrive2 500 0 16 32 48 64 80 同時実行数 TPS =1 秒当たりの処理数同時実行数 = 同時に実行する数 サイオスによる検証結果 9
MySQL 最新情報 MySQL 5.6.8 RC ( リリース候補版 ) InnoDB : 強化ポイントの1つ パフォーマンスとスケーラビリティを向上 半導体ストレージに対する強化を実施 古いmutexを排除 CPUキャッシュの共有 スレッドの改良と同時実効性の向上 参照専用トランザクションによる参照性能の向上 運用や開発の柔軟性を向上 表領域 ( データファイル ) をOSコマンドでコピー NoSQL, InnoDBへのキー バリュー型でのアクセス 10
MySQL + iodrive2 + LifeKeeper 検証結果 11
検証の目的 LifeKeeper による同期レプリケーションを MySQL の最新 RC 版である v5.6.7 及び iodrive2 の環境下で性能測定することにより 高速 高可用性データベースソリューションとして実用的な性能を発揮できるかどうか検証する 12
検証の概要 汎用データベース負荷テストツール jdbcrunner を使った RDBMS に対する OLTP ベンチマーク検証を実施 TPC-C を簡易実装したトランザクションを実行 テスト用テーブルのレコード数は 600( 実データサイズ約 100GB) 検証環境 Red Hat Enterprise Linux 6.2 64bit iodrive2 に ext4 ファイルシステムを作成しデータレプリケーション領域とする OS およびシステムファイルは内蔵 SAS HDD に配置 物理メモリ 32GB データレプリケーション用の通信パスに 10Gbps Ethernet を使用 13
ハードウェア構成 負荷生成サーバ 1 号機 CPU :Xeon E5504 2.00GHz * 2 MEM :12GB HDD :SAS 10000rpm 147GB 2 負荷生成サーバ 2 号機 CPU :Xeon E5504 2.00GHz * 2 MEM :12GB HDD :SAS 10000rpm 147GB 2 SWITCH L2SW DB サーバ 1 号機 (Active) CPU :8C E5-2690 2.90GHZ * 2 MEM :32GB HDD :SAS 15000rpm 146GB 3 (RAID0) 追加 NIC : 2port 10GbE NIC 10Gb Cable DB サーバ 2 号機 (Standby) CPU :8C E5-2690 2.90GHZ * 2 MEM :32GB HDD :SAS 15000rpm 146GB 3 (RAID0) 追加 NIC : 2port 10GbE NIC iodrive : iodrive2 2.4TB MLC iodrive : iodrive2 2.4TB MLC 14
ソフトウェア構成 / データ配置 負荷生成サーバ 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.6.7 + iodrive2 MySQL5.6.7 + iodrive2 + LK 8.0 MySQL5.5 + iodrive2 1000 800 MySQL5.5 のレプリ無しと比較しても上回っている! MySQL5.5 + iodrive2 + LK 8.0 600 400 200 0 MySQL5.5 と 5.6.7 の比較では約 20% スループットが改善している ( 同時実行数 64 の場合 ) MySQL5.6.7 での同期レプリケーション時は 無しの場合と比較して約 11% 程度の低減 ( 同時実行数 64 の場合 ) 16 32 48 64 同時実行数 16
チューニングポイント iodrive2 を使用することにより I/O ネックが解消されると 新たなボトルネックに遭遇するケースが多い CPU メモリ ネットワーク OS DBMS アプリケーション etc iodrive2 の高速 I/O 性能を十分に活かすためにはボトルネックを作らないことが重要 17
チューニングポイント (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
チューニングポイント (1)LifeKeeper 1 Bitmap ファイルを iodrive2 上に作成する ( つづき ) 1. iodrive2 上に Bitmap ファイル用のパーティション 及びファイルシステムを作成する パーティションのサイズは 100MB で十分とお考えください 例 ) レプリケーション対象ボリューム 500GB チャンク サイズが 64KB の場合 Bitmap ファイルは約 1MB となります 2. データレプリケーション用のリソース作成ウィザードにおいて Bitmap ファイルの配置先として 1. で作成した場所を指定する 19
チューニングポイント (1)LifeKeeper 2 Bitmap のチャンク サイズを拡張する チャンク サイズとは メモリ上で更新された情報をファイルシステムに書き戻す ( フラッシュする ) 際の大きさを表します LKDR_CHUNK_SIZE=4096 デフォルト値は 64KB で 設定値は 4096KB=4MB に相当します 3 再同期時のデータ転送速度を設定する LKDR_SPEED_LIMIT=1500000 LKDR_SPEED_LIMIT_MIN=200000 単位は KB/s デフォルト値は 50000 20000 設定値はそれぞれ 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.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
チューニングポイント (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.htm#cshid=datakeeper %2Finstallation_configuration%2Fclustering_with_fusion_io.htm StartTopic=Content% 2Fdatakeeper%2Finstallation_configuration%2Fclustering_with_fusion_io.htm SkinNa me=silverskin 23
iodrive2に関する留意点 iodrive2のドライバを最新のものにする 今回の検証ではVSL3.1.5を使用 使用するドライバは各OEMベンダ もしくはfusion-io社のサイトから調 査いただいてから導入してください iodrive2を初期化する fio-format によりioDrive2を初期状態に一度リセットします fio-format で初期化する際にユーザ使用可能領域を小さくし 強制的に 空き容量を確保します* (オーバープロビジョニング) * 今回は書き込み負荷が高いベンチマークテストのために実施 24
MySQL に関する設定 半導体ストレージ (iodrive) を意識した設定 シーケンシャルアクセスの利点がないため 周辺ページを I/O しないように設定する innodb_flush_neighbors = false innodb_random_read_ahead = false innodb_read_ahead_threshold = 0 その他 5.6.7 でのチューニングポイント innodb_checksum_algorithm = 'crc32' innodb_page_size = 16K 25
まとめ 26
まとめ 今回ご紹介した MySQL + iodrive2 + LifeKeeper の構成で 高速 高可用性データベースソリューションとして十分な環境をご提供できます iodrive の高速 I/O 性能を十分に活かすためにはボトルネックを作らないことが重要です MySQL5.6.7 では 5.5 と比較してパフォーマンスもスケーラビリティも向上しています 27