本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。
本記事の原文はVirtual Datacenter scaling problems with traditional shared storage - part 2で閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
多重化率
ほとんどの仮想化データセンタのアーキテクチャではESXiホストはグループを形成し、ネットワーク経由で中心のストレージアレイに接続されています。ストレージエリアネットワークの設計は大抵コアーエッジトポロジーを成しています。このネットワークトポロジーでは、少数の大きな収容量をもつコアスイッチがその中心に置かれます。ESXiホストはコアスイッチに直接接続されることもありますが、大抵の場合はエッジのスイッチに接続されます。スイッチ同士の接続がコアスイッチとエッジスイッチを結ぶのです。ストレージアレイについても同様の設計が行われています。直接コアスイッチに接続するか、エッジスイッチに接続されるかのいずれかです。
このネットワークトポロジーはネットワークの観点からは容易な拡張性を実現します。エッジスイッチ(ディストリビューションスイッチと呼ばれることもあります)はポート数の拡張に利用されます。コアスイッチは非常に強力ですが、それでもポート数に制限があります。されに、ネットワークトポロジーのそれぞれのレイヤーは設計上の役割を継承しています。エッジーコアトポロジーによって引き起こされる問題の一つとして、多重化率が挙げられます。これはいくつのエッジスイッチのポートが1つのコアの接続に利用されているかという数字です。システムの配置の設計によってこの問題は始まり、マルチホップになることでレイテンシを大きくしていきます。
レイテンシを下げるためにはホップの数を小さくする必要がありますが、これはポートの数に影響します(そして、接続するホストの数にも)。スイッチのポート数には限りがあるため、これによって利用可能な帯域に影響が出てきます。スイッチを追加してポート数を増やすことは、デバイスの配置の問題に跳ね返ってきます。レイテンシはアプリケーションのパフォーマンスに非常に大きく影響するため、ほとんどのストレージエリアネットワークは可能な限りフラットであるべきであると設計されています。ストレージレイヤーとホストのレイヤーが1つのスイッチレイヤーで接続されているようなケースも有ります。それではコンピューティングリソースのスケールアウトについてと、これによるネットワークトポロジーがどのようにストレージパフォーマンスに影響するのかを詳しく見て行きましょう:
ストレージエリアネットワークのトポロジー
このアーキテクチャはホストが2台がスタートです。2つの10GB NICで33K IOPSを提供可能なストレージにつながっています。ストレージエリアネットワークは10GBで、それぞれのストレージコントローラーには2つの10GBポートがあります。可能な限りレイテンシを下げるため、ESXiホストとストレージコントローラーのポートは単一の冗長化されたスイッチのレイヤで結ばれています。以下の様な状態です:
この状態でのスイッチとストレージコントローラーの多重化率は1:1です。ネットワーク接続の消費者とネットワーク接続のリソースは等しくなっています。更にコンピューティングリソースが必要になるような新しいワークロードが追加されます。ストレージチームはスピンドル数を増やし、キャパシティとパフォーマンスをストレージレベルで増加させます。
コンピューティングリソースとストレージリソースの両方が増えていますが、ストレージコントローラーへの接続には新しくラインが追加されているわけではありません。多重化度は増え、単一のESXiホストのの10Gbの接続は潜在的に他の5ホストと共有される可能性が出てきます。答えは明らかで、スイッチとストレージコントローラー間の接続数を増やす必要があるのです。しかし、ほとんどのストレージコントローラーはネットワークのポートを拡張できるようにはなっていません。この設計はストレージが少数の単一のアプリケーションを実行するホストにだけ接続されていた時代からのものです。これに加えて、非同時のアクティビティを考えに入れる必要があります。すべてのアプリケーションが同時に、そして同じ重要度で動作するということはありえないのです。
仮想化によるワークロードのグループ化はパワフルなサーバによって複数のアプリケーションの実行を可能としました。統合率は増えていく一方です。多くのワークロードの平均化によってI/O操作は一定のストリームとなっています。ワークロードは変わりました。毎日どんどん多くのデータが処理され、それらのアプリケーションによって生じたI/Oは1本のパイプにつめ込まれていきます。帯域の要件が天井に達することもありますが、多くのストレージエリアネットワークの設計は仮想化時代よりも前のベストプラクティスをベースにしています。多くのベンダーが多重化率を低くしようと試みていますが、ストレージコントローラーのポートの制限が、この制約を外すことを難しくしています。
上のシナリオでは私はESXiホストを6台だけ利用していますが、殆どの場合、これ以上のESXiホストが同じ共有ストレージアレイに接続されており、多重化度を圧迫しています。基本的にどんどん増えていくI/Oをとても小さな漏斗に対して注ぎ込んでいる状態です。そして、これはレイテンシと帯域のパフォーマンスに影響を与えます。
しばしば、従来型のストレージアーキテクチャの拡張性の問題を説明する際に、ホストごとのIOPSの平均値をストレージ側でのIOPSの総計をホスト数で割ることで計算します。私の今回のシナリオではコンピューティングリソースの追加と一緒にストレージの追加も行っていますので、IOPSの平均値は16.5K IOPSのまま(33÷2 もしくは 100÷6)です。ストレージの提供については(パート1でも説明しました)ストレージアレイはストレージの寿命の最後においてもピークのパフォーマンスを想定して構成されています。
最初のホストが接続された時には、帯域とパフォーマンスは(おそらくは)問題になりません。新しいワークロードが追加されると統合率が高くなり、それによって新しいコンピューティングリソースの追加が行われるため、統合率はある一定のパフォーマンスと可用性の要求から一定の値を推移します。これによってホストごとの帯域とIOPSは削減されますが、もしサイジングが適切に行われていたとしても問題はとどまりません。問題は、ワークロードが増え、その振る舞いが大抵は期待とは異なることです。アーキテクトの油断のすきを突いて、もしくは単にビジネスのニーズが変わったことで新しいアプリケーションに期せずして取り組む必要が出てくるのです。ストレージリソースの消費や上限への到達についての適切な分析がなされているケースはあまりありません。組織がパフォーマンスの問題に直面するのがワークロードの振る舞いを適切に可視化できていないため、というケースは珍しくはないのです。これを避けるために、ストレージアレイにはキャパシティとパフォーマンスの要求を満たすようなさらなるキャパシティが追加されています。しかし、これはこの2つのレイヤーの真ん中に位置する問題を解決することはできないのです。この方法はストレージコントローラーのポートへの接続の多重化率から起こる漏斗の問題を無視しているからです。
ストレージコントローラーのポートの数がこの問題に関連しますが、もうひとつの問題は帯域の総量を使いきってしまうということです。アプリケーションの稼働とコンピューティングレイヤー内の仮想マシンが分散の具合がストレージのパフォーマンスに影響を及ぼします。ワークロードはストレージコントローラーが接続されているのと同じように分散しないからです。シリーズのパート3ではこの問題にフォーカスを当てます。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
