Fusion-io ioDriveを導入するときに注意すること

こんばんは、佐野です。前回はこんな記事を書きました。最近は窓際で仕事するふりをしています。
2011年3月入社なのでどうやら入社して3年も経ってしまったようです。通算して4回目の登場です...。このエンジニアブログは年イチくらいのペースで書いてることになるのかな...。入社したときは20代だったんですが今はもう立派な三十路戦士です。酒飲むとなかなか酒が抜けません。平日に深酒するといつも後悔します。でも反省はしません。

昨今のウェブサービス開発はスタートアップを中心にクラウドを使うのが主流で、あまり需要がないかもしれませんが...今回は「甘え」と言われることもあるioDriveを導入する際に注意しておくべきポイントについて書かせていただきます。
ioDriveをはじめとするフラッシュストレージは、強力なIO性能をもつこともあってiopsなどの性能指標値ばかりに検証の焦点がいってしまいがちなのですが、プロダクションで運用するには性能以外にも見ておくべきポイントがあります。今回言及するのは熱落ち、電力不足、運用が始まってから気をつけるべきこと、の三点です。前者二点はOEMで提供されているものであっても直面することがあるのでちゃんと検証した方が良いです。

アメーバのFlash事情

まずはコラム的に...弊社ではアメーバピグで導入(2010年～2011年頃)して以来、要所要所でフラッシュを使っていて、導入実績、コストともに、インフラの選択肢の一つとなっています。フラッシュの内訳はFusion-io社のioDrive(ioDrive2)とVirident社のFlashMAXの二本立てで、ioDrive(ioDrive2):FlashMAX=9:1くらいです。他のベンダのものも検証はしていますが、今プロダクションにあるのはこの二つ。用途としては大抵はMySQLのデータ領域として使っています。ちなみにほとんど壊れたことがありません。2年くらい前に買ったやつが2～3個壊れたくらいです。

気をつけることその1: 温度

マシン筐体内部の排熱が滞って熱落ちすることがあります。落ちると言ってもマシンそのものが落ちるわけではなく、ioDriveがマシンから自動的に切り離されます。これは安全のためにこうなる仕様の模様。ただ、サービスが止まることにかわりはありません。

調査方法

ddコマンド、fio、sysbenchなどのベンチマークツールを長時間かけるのが良いでしょう。ioDriveのユーティリティに含まれているfio-statusコマンドで温度が確認できるので、閾値に達していないかを定期的に確認してみます。まぁ、熱落ちするとマウントしたファイルシステムにアクセスできなくなるのでそれで気がついたりもしますが...。

対処方法

ioDriveを刺すPCIeスロットの位置を変えてみます。場所を変えることによって筐体内のエアフローが変化して、この問題が解消することがあります。これでも無理だったらマシンを別の機種や別のベンダのものに変えて同様の検証をしてみましょう。

気をつけることその2: 電力

ラックの電力にも注意ですが、PCIeスロットの供給電力が追いつかなくなる警告が出ることもあります。こんなの↓ね。

!! ---> There are active errors or warnings on this device!  Read below for details.
        ACTIVE WARNINGS:
            Over PCIe power budget alarm triggered.

Fusion-io社のドキュメントでは、"1つのioDrive内に複数のデバイスを搭載したもの(つまりioDrive DuoやioDrive2 Duo)では注意しろ"、という文言がありますが、1マシンにioDriveを二枚刺したときもこの現象に直面したことがあります(まあ、Duoを使ったときと同じ状況になるのかな)。

調査方法

熱落ち問題と同様、ioDriveに十分な負荷を与えて、定期的にfio-statusコマンドを叩いて、上記のような警告が出ていないか確認します。

対処方法

外部電源を使う。もしくはドライバの設定(external_power_overrideオプション)でPCIeスロットへの供給電力のリミットを解除します。ただしこの設定を行う際は、マシンのPCIeスロットが55W以上の電力に対応しているかを確認した方が良いです。

気をつけることその3: 運用

主にMySQLの土台としての用途が多いのでその場合について。サーバ台数が減る、リカバリが高速になる、調査が楽、などいいことがたくさんあります。が、基本的にはフラッシュ導入後もDBAがやることは変わりません。

* 適切なインデックスを貼る

* 適切なクエリを書く

* テーブルの分散を考慮する

今までと同じようにケアしましょう。これらをおろそかにすると普通にスロークエリが発生してサービス影響が出ます。今まで以上に大量のクエリを捌けるようにはなりますが、やはり無敵ではないです。また、想像はつくと思いますがボトルネックはIOからCPUに移ります。

あんま気合い入ってないゆるい記事で申し訳ございません。以上です。

運用エンジニア募集中！！！！

俺を助けて！！！！！！！！！！！！！！！！！！！！