Japan IBM Storage User Group

 View Only

ストレージ移行後のパフォーマンスダウンについて考える

By Keitaro Imai posted Fri May 08, 2020 04:44 AM

  
ストレージを新しいストレージに移行したが遅くなった!
と相談されることが結構あります。今回は、この理由について考察してみたいと思います。


・スペックシートに頼った見積もり
スペックシートのパフォーマンスデータを見て問題ないと判断される場合がありますが、スペックシートのデータなどは限られた環境で最大値を出すために
ガチガチのチューニングや限定された負荷をかけているので、良い値が出る傾向にあります。
実際の環境では負荷はかなり異なり、スペックシートほどのパフォーマンスは殆ど出ません。
スペックシートよりは以下のSPC(Storage Performance Council)というサイトのデータのほうがより正確性は高いと思います。
https://spcresults.org/
ミッドレンジのディスクから高いエンタープライズのディスクに移行したんだから早くなる!というわけでもありませんのであしからず。



・実際の負荷とは異なる負荷で見積もっている
現行の環境のパフォーマンスデータを取得せずに、Online Transaction Processing(OLTP)
のような一般的な負荷を想定して見積もりを行っているケースが良くありますが、これも実際の負荷とかけ離れている場合がありますので注意が必要です。
ちなみにOLTPは一般的にはRead:Write=7:3、4KBもしくは8KBのブロックサイズの負荷になります。



・そもそもパフォーマンスが出ない構成になっている
よくあるのは現行の環境よりも稼働するHDDの数が少なくなっているという構成です。
最近では1玉あたりの容量が大きくなっていることから、移行元よりも少ない数で容量要件が満たせる構成が出来てしまいます。
しかしながらパフォーマンスの最大値は一般的には同時に稼働するHDDの数に比例します。
従って容量は異なるが速さが同じHDDがあるという場合は、同じ数でようやく同等のパフォーマンスが出るということになります。
同じパフォーマンスならば同じ数用意するというのが基本です。数が少なくなると当然遅くなります。
ちなみにFlashの場合は、1ドライブでも容量が多いほうが複数のモジュールが同時に稼働するので、速い傾向にあります。
高いキャッシュヒットが見込まれる環境では、搭載するキャッシュの量なども重要でしょう。
サーバー側でもストレージ用のデバイス・ドライバーのチューニングや、ミドルウェアのチューニングなどが適切になされていないこともありえます。



・キャッシュヒットしない
現行の環境ではずっと使い倒してきているので、ある程度必要なデータはサーバー及び、ストレージのキャッシュに乗っています。
しかしながら新規のシステムではキャッシュ上にデータはないので、初めの方は直接ディスクにアクセスが行くため遅いということがあります。
この場合は、使っていくに連れてパフォーマンスは改善していくでしょう。



・そもそもかけている負荷が異なる
移行した後も全く負荷が同じとは限りません。例えばデータの容量が増えているのであれば、その増えた分負荷が増えるというのはよくあることでしょう。
また、例えば夜中の12時からのバッチ処理と、朝9時からの日常業務処理などは通常全く負荷が異なりますので、そういった異なる負荷の時間を比較するのはナンセンスです。
比べるなら同じ時間の負荷を比べましょう。
接続されるサーバーが増えて、あるサーバーの負荷が高くなり他のサーバーのパフォーマンスを遅延させてしまうということもありますし、
バックアップや災対運用などが加わったり変わったりするとこれも要因になりえます。



・ストレージの能力を活かしきれていない
ストレージ装置の能力は高いのに負荷をかける側が適切な負荷をかけていないケースもあります。
例えば、アプリケーションのジョブがシングルジョブだと高い並列処理が可能なストレージの場合は、能力を活かしきれません。
並列処理に変更が可能なものは、並列処理をするように設定することで劇的にパフォーマンスを改善することが見込めます。



これだけが理由ではないですが、よくあるのはこういう理由です(思い出したら追加したいと思います)。





移行してもパフォーマンスを落とさないためには、まず確度の高い見積もりが必要でしょう。
現行のパフォーマンスデータを取得した上で、IBM製品であればDisk Magicや以下に紹介されているStorMで新規構成のストレージにそのパフォーマンスデータをプロットして見積もるというのが基本です。

Storage Modeller (StorM)
https://community.ibm.com/community/user/imwuc/blogs/keigo-matsubara1/2020/05/08/storage-modeller-storm?CommunityKey=263553fb-0049-44b0-995c-dfaa0195a27f&tab=recentcommunityblogsdashboard

どうしてもパフォーマンスデータが取れないという場合はOLTPなどで見積もりますが、正確な見積もりではないという注意書きが必要です。
また、移行先での環境、構成変更に伴う負荷の変化も見込んでおく必要があります。
合わせて、そのままサーバーやアプリを乗っけるのではなく、そのストレージに合わせた適切なチューニングを行うことも検討してください。




 

#performance-simulation
#storm
0 comments
6 views

Permalink