ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード Twitter

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2011/11/08 (火)

[]仮想化されたストレージってどういうことだろう?(3)

さて、第3回のエントリーです。

第1回ではネットワークロードバランス機能について、第2回では容量ロードバランス機能について書いてきました。ネットワークロードバランスは、ストレージとサーバ間の通信部分についての最適化を行い冗長性と拡張性を提供するための仕組みです。容量ロードバランスは、ストレージがスケールしたり逆にシュリンクしたりする際にデータの分散配置を最適化するための仕組みです*1

第3回となる今回は、自動パフォーマンスロードバランス機能(Automatic Performance Load Balancer / APLB)について書きます。

前回のエントリーで書いたように、容量ロードバランスに基づいてグループ化されている複数のストレージ筐体に分散して配置されたサブボリュームは、容量の比率配分という意味では最適化されたといえますが、まだこの時点ではパフォーマンス面では最適化されてはいません。いくら容量ベースで分散が行われたとしても、アクセスが頻繁に行われるサブボリュームが特定の筐体に集中的に配置されてしまっていたとすると、いくら筐体を増設してもパフォーマンスはスケールアップしないということになってしまいます。そこでさらにパフォーマンス状態に基づいてサブボリューム配置の最適化を行う機能が、自動パフォーマンスロードバランス機能です。

最もシンプルなパターンとして、同一性能で同一容量のストレージ筐体2台で構成されたストレージシステムの場合を考えてみたいと思います。容量ロードバランス機能によって、2台の筐体に均等に分散配置されたサブボリュームは、その後サーバからのI/O要求が行われることによりアクセス頻度の高い「ホット」なサブボリュームとアクセス頻度の低い「コールド」なサブボリュームがあることがわかります。

f:id:takaochan:20111103225445p:image

この例では、同一仕様のストレージ筐体にあるボリュームを構成するサブボリュームがそれぞれ8個ずつ配置されています。赤いサブボリュームはホット、青いサブボリュームはコールドであることを意味しています。ここでは、左側の筐体にはホットなサブボリュームが3つ、右側の筐体にはホットなサブボリュームが5つ配置される状態となっており、容量としてはバランスしていてもパフォーマンスという意味ではまだバランスしていないということとなります。自動パフォーマンスロードバランス機能は、この状態が確認されると各筐体に均等にホットなサブボリュームが配置されるように、サブボリュームの再配置処理を行います。

f:id:takaochan:20111103225446p:image

なお、基本的にはパフォーマンスの最適化=サブボリュームの再配置はあくまでも容量ロードバランスの比率を維持したままで実行される、という点です。そのため、自動パフォーマンスロードバランスによる最適化が行われても、容量ロードバランスによる配置比率の最適化が崩れてしまうことはありません。

どういう基準でサブボリュームをホットもしくはコールドと判定するのかについてはストレージベンダーの腕の見せ所です。I/Oアクティビティや、レイテンシ状態など、基準とすることができる指標は数多くありますが、あまりにも複雑化すると最適化計算の負荷が高くなってしまいます。また、最適化をどの程度のタイミングで実行するのかもポイントとなります。高頻度に判定を行えばそれだけより最適化されることとなりますが、一時的なI/O要求にもいわば過敏に反応してしまうこととなるため、ムダな再配置処理が行われる比率が高まってしまうこととなります。逆に、最適化頻度の間隔を開ければ長期的な傾向に基づいて判断が行われるためより適切に再配置が行われることとなりますが、最適化されるまでに時間がかかることや、短期的なI/O要求の変化に対しては最適化が対応しないなどのデメリットもあります。

EqualLogicの場合は、筐体内での再配置が必要な一部のモデル*2を除き、基本的にはグループを構成する複数の筐体間での最適化については基本的には各筐体毎のレイテンシ状態だけを基準として比較を行い、一定の基準値*3をトリガーとしてパフォーマンスのロードバランス処理が行われる仕組みとなっています。レイテンシだけを基準としているのは、筐体のモデルやRAIDレベルなどがバラバラの筐体でグループが構成されたとしても1つのルールだけで対応することができるシンプルなアルゴリズムとすることができるためです。また、以前のFirmwareでは長期的な傾向に基づく最適化のみでしたが、現在は短期的なI/O状態に対しても最適化対応できるようになっています。

容量ロードバランスは新しく筐体がストレージに追加された場合や、ボリュームの拡張が行われた場合などだけに実行されるバランス機能ですが、自動パフォーマンスロードバランス機能はボリュームが作られてから削除されるまでのライフサイクル全般にわたって最適化の役割を担い続けるという意味で、最も重要なパフォーマンス最適化機能といえます。

次回は、この自動パフォーマンスロードバランス機能は実質的には階層化、Tieringの仕組みとして使うことができますので、その点にフォーカスを当てて書いてみたいと思います。

*1:このシリーズのエントリーにおいて、EqualLogicに関しての情報はこちらで公開されている技術レポート文章 "DELL EqualLogic PS Series : Load Balancers" を参考にしています。

*2SASSSDの両方が搭載されたハイブリッド筐体の場合はブロックに対するアクセス頻度などに基づいて筐体内での再配置を高頻度に行っています

*3:20msを超える状態