もう少しブログのエントリーを書かないと、と思いつつ、ついつい…1ヶ月が経過してました。前回のエントリーはこちら。
さて、前回はネットワークロードバランシング機能(NLB)について書きましたので、今回のエントリーでは残りの2つのうち、容量ロードバランス機能(Capacity / CLB)について書いていきたいと思います。3つ目の自動パフォーマンスロードバランシング機能(APLB)とまとめて書こうと思っていたのですが、ちょっと長くなってしまいそうですので。
仮想化されたストレージでは、動的なデータの配置が行われます。最初は1台の筐体で構成されていたストレージシステムに対して、2台目、3台目と動的に追加し、サービスを停止することなくストレージの容量を拡張できることが求められます。そのためには、サーバ側に認識されるボリュームは物理的な筐体、さらにはRAIDに紐付られることなく配置され、拡張できる必要があります。もちろん逆に、3台で構成されていたシステムから、1台の筐体を取り除くことについても動的にできることも重要です(使用容量などの理由で取り除けない場合もあり得ますが)。
EqualLogicはサブボリュームの集合としてボリュームを構成しています。統合的に管理されているEqualLogicが1台の場合は、当然すべてのサブボリュームが1台の筐体内に配置されていますが、2台目が増設された時点で、自動的にサブボリュームは2台目のEqualLogicにも分散配置されます*1。この動作はサーバからは透過的に処理されており、サーバからのI/O処理を優先する形でサブボリュームの再配置(つまりは筐体間のサブボリュームの移動)が行われています。また、前回のエントリーで書いた通り、EqualLogicはGroup IPというかたちで仮想IPアドレスをサーバに対する窓口としているため、筐体が増えてもサーバ側では何の設定変更・追加も必要ありません。
ただし、EqualLogicの筐体が増設に伴ってどこまででもサブボリュームが分散配置されるかというと、そうではありません。EqualLogicは通常、3台の筐体までの範囲でサブボリュームを分散配置します。ここで誤解しないで頂きたいのは、では3台以上のEquaulLogicでGroupを構成してもパフォーマンス的なスケールはしないということではありません。たとえば、筐体A,B,C,D,Eの5台のEqualLogicで統合されたGroupを構成していた場合、Volume1はA,B,C、Volume2はC,D,Eといったように配置されるようなこともありますので、全体としてはパフォーマンスはスケールしていくこととなります。また、3台のEqualLogicでは必要容量が確保できない場合などでは、4台以上のEqualLogicのサブボリュームが分散されることもあります。
EqualLogicはRAIDをあくまでもサブボリュームを保護する仕組みとしてしか使用していないため、ボリュームの容量やパフォーマンスとRAIDは直接的には結び付きません*2。もちろん、RAID50よりもRAID10の方がパフォーマンス(特に書き込み…といってもランダムI/Oだと話は難しいところですし、コントローラのキャッシュもありますが…)がよいですし、リビルド時のパフォーマンスインパクトやリビルド所要時間などにも違いがありますので、さまざまな観点に基づいてRAIDレベルは考慮する必要はあります。EqualLogicは自律的にサブボリュームの配置を最適化しますので、基本的にはボリュームの配置は自動的な調整に任せてしまうことが最適となります。
サブボリューム単位のサイズをどの程度とするかについては、ストレージシステム設計におけるバランスを考慮して考えられています。サブボリュームのサイズが小さいとどのブロックがどのサブボリュームにあるのかについての管理テーブルが肥大化してしまうため、CPUやメモリにかかる負荷が大きくなってしまいます。逆に、サブボリュームのサイズが大きいとストレージの仕様効率は低下しますが管理しなければならないサブボリュームの数を減らすことができます。当然のことながら、コストはCPUやメモリの方がコストは高いリソースですので、ある程度の大きさのサブボリュームサイズとされる場合が多いでしょう。具体的なサイズについては、ストレージベンダー毎のノウハウと言える部分もあるため、公開されていない製品が多いかと思います。
容量のロードバランスはボリュームの構成時にサブボリュームの配置を行っておしまい、というわけではありません。ストレージが使用されていく中で、読み書きが頻繁なサブボリュームや、ほとんどI/Oの発生しないサブボリュームなどが出てきますので、それらの配置が最適となるように再配置のプランニングが行われ、自動的に最適化が行われます。再配置の処理中は一時的にサブボリュームの配置はアンバランスとなることがありますが、基本的には各筐体の論理容量に基づく比率に従ってサブボリュームは分散配置されます。
また、パフォーマンスの最適化のためとは別に、各筐体の空き容量に基づく再配置の処理も行われることがあります。複数の筐体の中で空き容量が一定以下となった筐体ができた場合、サブボリュームの再配置はパフォーマンスの最適化よりも優先して処理されます。もちろん、筐体の増設などによりGroup全体の容量が拡張された際には、改めてパフォーマンスに基づく最適化が処理されます。
こうした容量に対するロードバランスはもちろんトランザクション処理として実行されており、サブボリュームの再配置とメタデータの書き換えの両方が完了したことを確認したうえで、移動元側のサブボリュームのデータが削除されます。
次回は最後のロードバランス機能、自動パフォーマンスロードバランス機能(Auto Performance / APLB)について書きたいと思いますが、すでにこのエントリーでも一部のパフォーマンスロードバランスに触れてしまっていますね(^_^;)。
さて、仮想化ストレージの真骨頂は最後のロードバランス機能、自動パフォーマンスロードバランス、です。これについては、また次回。1ヶ月後にならないようにしたいと思います…。
