一般的な SAN は、スイッチのネットワークを通じてストレージ システムの集合体に接続されたコンピュータの集合体で構成されています。複数のコンピュータが同じストレージにアクセスすることは頻繁にあります。

ストレージへの単一のイーサネット リンクはイーサネット スイッチを介してストレージ システムに接続された複数のコンピュータ システムを示します。この構成では、各システムはそれぞれ 1 つのイーサネット リンクを経由してスイッチに接続されており、スイッチからまた 1 つのイーサネット リンクを経由してストレージ システムに接続されています。ほとんどの構成 (比較的新しいスイッチと標準トラフィックを備えている) では、これで問題はありません。

図 1. ストレージへの単一のイーサネット リンク
この図は、1 つのイーサネット スイッチを通じてストレージ システムと接続しているいくつかのシステムを示しています。

システムがストレージからデータを読み取る場合、ストレージから得られる最大のレスポンスは、ストレージ システムとイーサネット スイッチとの間のリンクで送信できるデータ量です。1 つのシステムまたは仮想マシンがネットワーク スピードを占有してしまう可能性は少ないですが、複数のシステムが 1 つのストレージ デバイスを共用する場合には起こる可能性のある状況です。

ストレージにデータを書き込むとき、複数のシステムまたは仮想マシンがリンクを利用しようとすることがあります。これが発生すると、ドロップされたパケットに示すとおり、システムとストレージ システムとの間のスイッチでデータをドロップせざるを得なくなります。このようなことが発生するのは、ストレージ デバイスへの接続が 1 つしかないにもかかわらず、ストレージ システムへ送信するトラフィックが 1 つのリンクが送信できる容量を超えているためです。この場合、送信可能なデータ量はスイッチとストレージ システムとの間のリンク速度に制限されるので、スイッチがネットワーク パケットをドロップします。

図 2. ドロップされたパケット
この図は、サーバとストレージ システム間でデータをドロップしているスイッチを示しています。

ドロップされたネットワーク パケットをリカバリさせると、パフォーマンスが著しく低下します。データがドロップされたと判別する時間に加え、再送信するときに、次の処理に使えたはずのネットワークのバンド幅を消費します。

iSCSI のトラフィックは、ネットワーク上を TCP (Transmission Control Protocol) で送信されます。TCP は信頼性の高い伝送プロトコルで、ドロップされたパケットを再送信し、確実に最終目的地まで届けます。TCP はドロップされたパケットを回復し、すばやくシームレスに再送信するよう設計されています。ただし、スイッチがパケットを頻繁に廃棄してしまう場合、ネットワークのスループットは著しく低下します。ネットワークはデータ再送信リクエストや再送パケットなどで輻輳し、実際にネットワーク上を円滑に転送されるデータは少なくなります。

ほとんどのイーサネット スイッチはデータのバッファ (つまり一時保存) が可能なため、データを目的地に送信する機会は各デバイスに均等に与えられます。その代わり、この転送データを一部バッファできるという点と、多くのシステムでコマンド残数を制限しているという点で、複数のシステムからストレージ システムに小規模なデータが一斉に送信される可能性があります。

処理が膨大で、かつ複数のサーバが 1 つのスイッチ ポートからデータを送信しようとすると、1 つのリクエストをバッファしつつ別のリクエストを転送するスイッチの容量を超えてしまう場合があります。この場合、スイッチは送信できないデータをドロップし、ストレージ システムはドロップされたパケットの再送信を要求しなければなりません。たとえば、イーサネット スイッチは 32KB しか入力ポートにバッファできないのに、そのスイッチに接続したサーバが 256KB をストレージ デバイスに送信できると判断した場合、一部データがドロップされます。

正しく管理されているスイッチであれば、ドロップしたパケットについて次のような情報を表示します。

*: interface is up IHQ:pkts in input hold queue     IQD:pkts dropped from input queue OHQ:pkts in output hold queue    OQD:pkts dropped from output queue RXBS:rx rate (bits/sec)          RXPS:rx rate (pkts/sec) TXBS:tx rate (bits/sec)          TXPS:tx rate (pkts/sec) TRTL:throttle count
表 1. サンプルのスイッチ情報

インターフェイス

IHQ

IQD

OHQ

OQD

RXBS

RXPS

TXBS

TXPS

TRTL

* GigabitEthernet0/1

3

9922

0

0

476303000

62273

477840000

63677

0

この Cisco のスイッチの例では、使用しているバンド幅が 476,303,000 ビット/秒で、ケーブル速度の半分未満です。それにもかかわらずポートは受信パケットをバッファリングし、多数のパケットをドロップしています。このインターフェイスの最終行にある概要情報を見ると、このポートではすでに約 10,000 の受信パケットがドロップされていると IQD 列からわかります。

この問題を回避するための構成変更としては、複数の入力イーサネット リンクが 1 つの出力リンクに集中しないようにし、結果的にリンクのオーバーサブスクリプションを防止する方法があります。最大容量に近い転送を行う多数のリンクの数を減らすと、オーバーサブスクリプションが発生する可能性があります。

一般的に言って、データの取得や処理を記録するシステムなど、大量のデータをストレージに書き込むアプリケーションやシステムでは、ストレージ デバイスのイーサネット リンクを共用しないほうがよいでしょう。このようなタイプのアプリケーションでは、ストレージ デバイスへの接続を複数にしておくと最高のパフォーマンスを発揮します。

スイッチからストレージへの複数の接続は、スイッチからストレージへの複数接続を示します。

図 3. スイッチからストレージへの複数の接続
この図は、スイッチからストレージに複数の接続が行われている例を示しています。

共有構成でのリンクのオーバーサブスクリプションの問題は、VLAN または VPN を使用しても解決されません。VLAN やその他のネットワーク仮想分割を利用すると、論理的なネットワーク設計は可能になりますが、スイッチ間のリンクやトランクの物理的容量が改善されるわけではありません。VPN のように、ストレージ トラフィックやその他のネットワーク トラフィックが最終的に物理接続を共用する場合、オーバーサブスクリプションおよびパケット消失が起こる可能性があります。スイッチ間のトランクを共用する VLAN にも同じことが言えます。SAN のパフォーマンス設計をする場合、ネットワークの論理的な割り当てではなく、ネットワークの物理的な制限を考慮する必要があります。