Fusion-io ioDriveの検討資料～運用設定編～

前回に続いて古いメモの公開です。

ioDriveを運用する上での環境設定や、MySQLで利用する場合の検討事項を紹介します。

このメモを公開するにあたって、現在を踏まえてある程度編集していますが、基本的には２年前の内容になっているので、あくまで参考程度に留めてください。これから広まるであろう ioDrive2 になると、考え方が異なったり、無用になる知識も含んでいます

リンク集

検証

古いので新しいのを探したほうがよさそうです

公式Knowledge Base

ログインが必要です。

Fusion-io Knowledge Base

General Tuning Techniques

Programming Using Direct IO

Tuning Techniques for Writes

Verifying Linux System Performance

運用

サーバ筐体

コネクタは PCI Express x16 ですが、必ずサーバベンダー経由の購入のため、どの筐体で利用するかはベンダーと相談することになります。

寿命検知

SNMP

SNMP/SMI-S を利用して、予備領域の残量やこれまでの読み書き量の監視ができます。

ioManager

GUIツールでの状態確認もできます。

デバイス・ファイルフォーマットの流れ

デバイスの認識

iomemory-vsl パッケージを入れるとDuoなら /dev/fct0, /dev/fct1 として認識されます

ioDriveの論理フォーマット

ブロックサイズ4Kbyteとしています。-s オプションで実効容量をいじれますが、普通は不要です。

fio-format -b 4k -y /dev/fct0
fio-format -b 4k -y /dev/fct1

1 2	fio-format -b 4k -y /dev/fct0 fio-format -b 4k -y /dev/fct1

ソフトウェアRAID

/dev/fio* ができてるので、ソフトウェアRAIDでストライピングします。

mdadm --create /dev/md0 /dev/fioa /dev/fiob --level 0 --num-devices 2

1	mdadm --create /dev/md0 /dev/fioa /dev/fiob --level 0 --num-devices 2

ファイルシステムを作成

フォーマットして、マウントして /etc/fstab に書けば完了です。

mkfs.xfs -s size=4096 -b size=4096 /dev/md0

mkdir /fio
mount -t xfs /dev/md0 /fio -o defaults,noatime,nobarrier

vim /etc/fstab

mkfs.xfs -s size=4096 -b size=4096 /dev/md0

mkdir /fio

mount -t xfs /dev/md0 /fio -o defaults,noatime,nobarrier

vim /etc/fstab

チューニング

サポート

FusionIO社では様々な環境でのパフォーマンスを測定しており、MySQLもその１つです。売りっぱなしにするのではなく、相談事にも応じてもらえます。

ioDriveに直接関わるポイント

ioDriveの論理フォーマットセクタサイズ(fio-format)

RAID構成の有無(mdraid)

ファイルシステムの作成パラメータ(mkfs)

ファイルシステム

並列アクセスが可能なため、それが得意な XFS が最もパフォーマンスが出るようです。

容量とパフォーマンス

SSD全般の話として、容量が小さいほどパフォーマンスが出るというものがあります。ioDriveでも無理矢理小さい容量で認識させて速くしようとできますが、あまりメリットはありません。

パフォーマンスモード

パフォーマンスモードというもので容量などを犠牲にして並列アクセス数を増やしたりと計測値を増やすことはできるそうです。

ですが実際の運用ではノーマルモードをおすすめしています。

実運用での注意点

ボトルネックの移動

これまで確実にIOPSが最短のボトルネックだったのが、CPUやネットワークトラフィック、はたまたメモリ容量やディスク容量になるかもしれません。

それらが均衡するのがかなり現実的なため、最短ボトルネックの見極めがかなり重要になります。

ずっとIOPSボトルネックの解決に躍起になってたせいで、次の様々なボトルネック対応は斬新でした。それについては別の機会に・・・

サービスの質

ハードの性能が上がるとコーディングの質が下がる恐れがあり、最低限の質をいかに保つかが重要になります。

HDDだと１クエリでサービスが破壊されていたものが、ioDriveだとそれなりに動いてしまったりします。そういったクエリを許容して放置していると結局破滅に向かうので、クエリの質を保つ何かしらの開発の仕組み・ルールが必要です。

仮想環境と物理環境

ioDriveは物理環境で利用することが推奨されています。これはパフォーマンスを最大に発揮するためですが、仮想環境で使うことも当然可能です。

Xenの場合、可能な限り準仮想化をお勧めします。完全仮想化と比べ性能が高いためです。

仮想環境にした場合、アクセスレイテンシが確実に増えますが、ioDrive自体のIOPSが劣化するわけではありません。もし仮想環境が必須もしくは便利な場合で、性能劣化が許容範囲なのであれば、仮想環境で使うことも選択肢になりえます。

予備領域とパフォーマンス

320GBの製品の場合、デフォルトの実行領域が 320GB 、予備領域が 80GB となります。これは総領域の 20％、実行領域の 25％となっています。

実行領域が狭くなるほどパフォーマンスは上がる実験結果があり、総量域の 50％あたりが最も良好という結果になっています。50％にすると実行領域が 200G になるため、場合によってはディスク容量が要件に満たないかもしれません。

その場合、迷わずデフォルトの割合にして問題無いです。実行領域を減らしてまで上げたパフォーマンスは、おそらく不要である場合がほとんどだからです。

ブロックサイズとメモリ使用量

320GBのioDriveの場合、平均的なブロックサイズ(4KB)では3GB程度消費します。
（Xen/KVMの場合は、ドライバを導入した管理OSのメモリを消費します）

また、この値は扱うデータの平均ブロックサイズにより変動します。

参考資料：ココの ibm_doc_highiop_2.2.3-5.4.2011_linux_user-guide.pdf

MySQL＋ioDrive

XFSは bs=4K 、InnoDBは bs=16K、トランザクションログは 512K とポイントは色々ありますが、MySQL＋ioDriveとしては 4Kbyteが最も良好な性能を記録しているため、4Kbyteでフォーマットすることがよさそうです。

IBM linux_user_guide よりメモ

Sufficient system memory (RAM).
The amount of RAM the VSL requires varies according to the average block size written to the device. 
Using the average block size table below, you can estimate the amount of system memory needed. 
You can reduce worst-case memory use by formatting your IBM High IOPS Adapter 
  with a 4K sector size and thereby force the average written block size to be 4K or greater.
Note however, that for many systems, even those formatted with 512 byte sectors, 
  actual memory utilization typically tracks with I/O operations on 4k or larger chunks of data.
At various block sizes, the following table shows the upper limit of RAM that may be required of your system 
  for every 80 GB of IBM High IOPS Adapter storage space used.

Sufficient system memory (RAM).

The amount of RAM the VSL requires varies according to the average block size written to the device.

Using the average block size table below, you can estimate the amount of system memory needed.

You can reduce worst-case memory use by formatting your IBM High IOPS Adapter

with a 4K sector size and thereby force the average written block size to be 4K or greater.

Note however, that for many systems, even those formatted with 512 byte sectors,

actual memory utilization typically tracks with I/O operations on 4k or larger chunks of data.

At various block sizes, the following table shows the upper limit of RAM that may be required of your system

for every 80 GB of IBM High IOPS Adapter storage space used.

容量80GB当りのブロックサイズとメモリ使用量の表

Average Written Block Size (bytes)	RAM Usage (MB) per 80GB of storage space
8192	225
4096 (Most common)	425
2048	825
1024	1600
512	3175

計算例

1GB当りに直して利用領域分をかけています。ブロックサイズ4Kbyteで実効容量640GBの場合です。

(425 MB of RAM / 80 GB) x (640 GB) = 3,400 MB (or around 3.32 GB) 

of system RAM for use by the IBM High IOPS Duo Adapter driver.

(425 MB of RAM / 80 GB) x (640 GB) = 3,400 MB (or around 3.32 GB)

of system RAM for use by the IBM High IOPS Duo Adapter driver.

MySQLでの利用

InnoDBの基本的な設定例

関連部のみです。少々押さえ気味の数値になっています。

innodb_flush_method        = O_DIRECT
innodb_write_io_threads    = 16
innodb_read_io_threads     = 8
innodb_adaptive_flushing   = 1
innodb_log_files_in_group  = 2
innodb_log_file_size       = 2G
innodb_io_capacity         = 10000
innodb_thread_concurrency  = 0

innodb_flush_method = O_DIRECT

innodb_write_io_threads = 16

innodb_read_io_threads = 8

innodb_adaptive_flushing = 1

innodb_log_files_in_group = 2

innodb_log_file_size = 2G

innodb_io_capacity = 10000

innodb_thread_concurrency = 0

MySQLのログ

ioDrive以外に、HDDのパーティションもあるのが普通ですが、

binlog

relaylog

transaction log

の全てをioDriveに収めることを推奨します。

どれをHDDに出そうとも、iowaitとなって足を引っ張ることになります。

性能を引き出すためには色々検討する必要がありますが、速い・壊れないところは本当に間違いない代物ですので、急いで解決したい場合はとりあえず入れて後から調整を頑張る、というのもあながち間違いじゃないです。

価格面は出しませんでしたが、サーバ全体をみたら結果的に安くなるというのも本当です。
そこにサービス稼働率も含めるともっと効果が顕著になります。

ただ、やはり触らないと納得しがたい代物でありますし、最近だとクラウドでioDriveを提供しているところも増えているので、サクッとHDDとの比較ベンチマークをとったり、単純にブッ壊しにかかるつもりで負荷をかけてみると楽しくなることうけあいです。