ESXi を iSCSI SAN と共に使用する場合は、問題を回避するために VMware が提供する推奨事項に従ってください。

ストレージ システムが Storage API - Array Integration ハードウェア アクセラレーション機能をサポートしているかどうかを、ストレージの担当者にご確認ください。サポートしている場合には、ベンダーのドキュメントを参照して、ハードウェア アクセラレーションのサポートをストレージ システム側で有効にしてください。詳細については、vSphere のストレージ ハードウェア アクセラレーションを参照してください。

iSCSI SAN の問題発生の防止

ESXi を SAN と併用する場合、SAN の問題を回避するためのガイドラインを遵守してください。

次の点に注意してください。

  • 各 LUN には、VMFS データストアを 1 つのみ配置します。
  • パス ポリシーの変更について熟知していない場合は、システムで設定されているパス ポリシーをそのまま使用します。
  • すべてを文書化します。これには、構成、アクセス コントロール、ストレージ、スイッチ、サーバと iSCSI HBA の構成、ソフトウェアとファームウェアのバージョン、およびストレージ ケーブル計画に関する情報を記載します。
  • 障害に対する計画を立てます。
    • トポロジ マップの複製をいくつか作成します。エレメントに障害が発生した場合の SAN への影響をエレメントごとに検討します。
    • 設計上の重大な障害を見落とさないように、さまざまなリンク、スイッチ、HBA、およびその他のエレメントを確認します。
  • iSCSI HBA が、スロットとバス速度を基準として、ESXi ホストの正しいスロットにインストールされていることを確認します。サーバで使用可能なバス間で、PCI バスの負荷を分散します。
  • ESXi パフォーマンス チャート、イーサネット スイッチ統計情報、ストレージ パフォーマンス統計情報など、ストレージ ネットワークのさまざまな監視ポイントに精通しておきます。
  • LUN ID の変更は、LUN にデプロイされている VMFS データストアで、いずれの仮想マシンも実行されていないときにのみ行ってください。ID を変更すると、VMFS データストアで実行中の仮想マシンが停止します。

    LUN の ID を変更したあとで、再スキャンを実行してホストの ID をリセットする必要があります。再スキャンについては、ESXi ストレージの再スキャン操作を参照してください。

  • iSCSI アダプタのデフォルトの iSCSI 名を変更する必要がある場合には、入力する名前が世界中で一意であり、適切にフォーマットされていることを確認します。ストレージ アクセスの問題を回避するには、異なるホスト上でも、同じ iSCSI 名を異なるアダプタに決して割り当てないでください。

iSCSI SAN ストレージ パフォーマンスの最適化

一般的な SAN 環境の最適化には、いくつかの要因があります。

ネットワーク環境が適切に構成されている場合、iSCSI コンポーネントは優れたスループットを発揮し、iSCSI イニシエータおよびターゲットの待ち時間は十分短くなります。ネットワーク輻輳が発生し、リンク、スイッチ、またはルータが飽和した場合、iSCSI のパフォーマンスが低下し、ESXi 環境に適さなくなることもあります。

ストレージ システムのパフォーマンス

ストレージ システムのパフォーマンスは、iSCSI 環境全体のパフォーマンスに影響する主要な要因の 1 つです。

ストレージ システムのパフォーマンスに問題が発生した場合、これに関連する情報はストレージ システム ベンダーが提供するドキュメントを参照してください。

LUN を割り当てるときは、複数のホストから各共有 LUN にアクセスでき、各ホストで複数の仮想マシンを実行できる点に注意してください。ESXi ホストで使用される 1 つの LUN が、異なるオペレーティング システムで実行される多様なアプリケーションからの I/O を提供する可能性があります。このような場合はさまざまなワークロードが発生するため、ESXi を I/O の頻繁なアプリケーションに使用していない別のホストの LUN を、ESXi LUN のある RAID グループに含めないでください。

読み取りキャッシュおよび書き込みキャッシュを有効にします。

ロード バランシングは、サーバの I/O 要求を使用可能なすべての SP およびそれに関連付けられているホスト サーバ パスに分散するプロセスです。目的は、スループットの観点からパフォーマンスを最適化することにあります (1 秒あたりの I/O 数、1 秒あたりのメガバイト数、またはレスポンス タイム)。

SAN ストレージ システムには、I/O がすべてのストレージ システム パスの間でバランスがとられるように、継続的な再設計と調整が必要です。この要件を満たすために、すべての SP 間で LUN へのパスを分散し、最適なロード バランシングを提供します。詳細な監視によって、手動で LUN の分散を再調整する必要がある時期が示されます。

静的にバランスがとられたストレージ システムの調整は、特定のパフォーマンス統計情報 (1 秒あたりの I/O 処理数、1 秒あたりのブロック数、応答時間など) を監視し、LUN のワークロードをすべての SP に分散して行います。

iSCSI でのサーバ パフォーマンス

ESXi ホストの最適なパフォーマンスを確保するために、いくつかの要因を考慮します。

各サーバ アプリケーションは、次の条件を満たしながら、目的のストレージにアクセスできる必要があります。

  • 高い I/O レート (1 秒あたりの I/O 処理数)
  • 高いスループット (1 秒あたりのメガバイト数)
  • 最小限の待ち時間 (応答時間)

アプリケーションごとに要件は異なるため、ストレージ システムの適切な RAID グループを選択することで、これらの目標を達成できます。

パフォーマンスの目標を達成するには、次のガイドラインを実行します。

  • 各 LUN を、必要なパフォーマンス レベルを提供する RAID グループに配置する。割り当てられた RAID グループにあるほかの LUN のアクティビティおよびリソースの使用を監視します。I/O を行うアプリケーションが多すぎる高性能 RAID グループは、ESXi ホストで実行されるアプリケーションで要求されるパフォーマンス目標を達成できないことがあります。
  • ピーク期間中にホスト上のすべてのアプリケーションで最大のスループットを実現するために、十分なネットワーク アダプタまたは iSCSI ハードウェア アダプタをインストールします。I/O を複数のポートに分散させることで、それぞれのアプリケーションでスループットが向上し、待ち時間が短くなります。
  • ソフトウェア iSCSI の冗長性を確保するために、iSCSI 接続に利用するすべてのネットワーク アダプタにイニシエータが接続されていることを確認する。
  • ESXi システムに LUN または RAID グループを割り当てるときは、そのリソースが複数のオペレーティング システムで使用および共有されることを念頭に置く。ESXi ホストで必要になる LUN のパフォーマンスは、通常の物理マシンを使用する場合よりも大幅に高くなる場合があります。たとえば、I/O の多いアプリケーションを 4 つ実行しようとする場合は、ESXi LUN に 4 倍のパフォーマンス キャパシティを割り当てます。
  • vCenter Server で複数の ESXi システムを使用すると、ストレージ パフォーマンスの要件が増加する。
  • ESXi システムで実行されるアプリケーションが要求する未実行 I/O 数を、SAN で処理できる I/O 数と一致させる必要がある。

ネットワーク パフォーマンス

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

次の図は、複数のコンピュータ システムがイーサネット スイッチ経由でストレージ システムに接続している状況を示しています。この構成では、各システムはそれぞれ 1 つのイーサネット リンクを経由してスイッチに接続されています。このスイッチから 1 つのイーサネット リンクを経由してストレージ システムに接続されています。

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

システムがストレージからデータを読み取るとき、ストレージからのレスポンスでは、ストレージ システムとイーサネット スイッチとの間のリンクを最大限に使ってデータが送信されます。1 台のシステムまたは仮想マシンがネットワーク スピードを占有してしまう可能性はほとんどありません。しかし、複数のシステムが 1 つのストレージ デバイスを共用する場合、次の状況が想定されます。

ストレージにデータを書き込むとき、複数のシステムまたは仮想マシンがリンクを利用しようとします。これが原因で、システムとストレージ システムとの間にあるスイッチが、ネットワーク パケットをドロップする場合があります。通常、データのドロップが発生するのは、ストレージ システムに送信されるトラフィックが 1 つのリンクで転送できる容量を超えているためです。スイッチが送信できるデータ量は、そのスイッチとストレージ システムとの間のリンク速度に制限されます。

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

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

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

ほとんどのイーサネット スイッチはデータをバッファに格納(つまり一時保存)することができます。データの送信を試みるすべてのデバイスには、この手法により、宛先に到達する機会が均等に与えられます。この転送データを一部バッファできる点と、多くのシステムで未処理のコマンド数を制限しているため、トラフィックのバーストは小さくなります。複数のシステムで発生したバーストは、順番にストレージ システムに送信されます。

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

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

*: 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 ビット/秒で、ケーブル速度の半分未満です。ポートは受信パケットをバッファしますが、一部のパケットをドロップしています。このインターフェイスの最終行にある概要情報を見ると、IQD 列で、このポートではすでに約 10,000 の受信パケットがドロップされているとわかります。

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

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

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

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

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

イーサネット スイッチ統計情報の確認

多くのイーサネット スイッチには、スイッチの健全性を監視するさまざまな手段が備わっています。

稼働時間の大部分でスループットが最大限に近い状態のポートのあるスイッチでは、最大のパフォーマンスは発揮できません。最大限近くで稼働しているポートが使用中の iSCSI SAN にあれば、負荷を減らしてください。そのポートが ESXi システムや iSCSI ストレージに接続されている場合、手動ロード バランシングを利用することで負荷を軽減できます。

そのポートが複数のスイッチまたはルータ同士を接続している場合、それらのコンポーネント間にリンクを追加して処理量を増やすことも検討してください。イーサネット スイッチは通常、転送エラー、キュー状態のパケット、およびドロップされたイーサネット パケットに関する情報も通知します。iSCSI トラフィックで利用しているポートがこのような状態であるとスイッチが頻繁にレポートする場合、iSCSI SAN のパフォーマンスは低くなります。