これは、参考として使用できるiSCSI に関する標準的な質問です。

iSCSIは、SCSIコマンドをペイロードとしてTCPネットワークパケットに入れるプロトコルです。そのため、ファイバチャネルなどとは異なる一連の問題が発生します。たとえば、リンクが混雑し、スイッチのバッファがいっぱいになった場合、デフォルトでは、イーサネットはホストに減速を指示する代わりにフレームをドロップします。これにより、再送信が発生し、ストレージトラフィックのごく一部の待ち時間が長くなります。

クライアントのオペレーティングシステムに応じて、ネットワーク設定の変更など、この問題の解決策があります。次のOSのリストでは、最適なiSCSIクライアント構成はどのように見えますか？スイッチの設定を変更する必要がありますか？ストレージはどうですか？

• VMWare 4および5
• Windows Hyper-V 2008および2008r2
• ベアメタル上のWindows 2003および2008
• ベアメタル上のLinux
• AIX VIO
• あなたが偶然関連すると思う他のOS

VMWareに慣れていませんが、Xenserverを使用していて、Hyper-V（R2）を使用しています。

現在のXenserver構成では、次のものがあります。

• 8台のDell Poweredge 29xxサーバー
• 2台のDell Powerconnect 6248スイッチ
• 2 Dell MD3000i SAN（iSCSI）

スイッチをマルチパス構成でセットアップし、iSCSI用に最適化しました：

• スイッチを3つのVLANに分離（iSCSIトラフィック用に2つ、管理用に1つ）
• JumboFramesを使用する
• powerconnectが持つ「iSCSI」最適化の適用

各サーバーには複数のネットワークカードがあり、各スイッチへの接続を提供し、サーバーとiSCSI SAN間のマルチパスを介して冗長性を提供します。iSCSI VLANには、iSCSI以外のトラフィックは含まれていません。

この構成では、Xenserverの「クラスター」が見事に機能することを報告できてうれしいです。

ちなみに、iSCSIによってHP SAN（古いファイルサーバー）に直接接続されたWindows 2008サーバーがあります。以前はWindows 2003を実行していましたが、定期的に接続を切断していました（2003の再インストール後でも）。ただし、Windows 2008にアップグレードしてもすぐに接続されたままになります。

私の設定についての質問に喜んでお答えします。

これは答えではありません...まだです。これは、汎用回答のフレームワークです。時間がある場合は、知っていることをすべて記入してください。特定のハードウェアの構成に関しては、ベンダーごとに個別の回答を投稿してください。そうすれば、その情報を整理して個別に保つことができます。

ポートへのQoSプロファイル、ストーム制御の無効化、MTUの9000への設定、フロー制御の有効化、およびポートのPortFastへの移行

スループットとレイテンシー

更新されたファームウェア、ドライバー、およびその他のシステム

MPIO

ジャンボフレーム/ MTU

ネットワークリンクの速度が上がると、潜在的に生成されるパケットの数も増えます。これにより、パケットの生成に費やされるCPU /割り込み時間がますます増え、送信システムに過度の負荷がかかり、フレーミングで過剰なリンク帯域幅を占有するという影響があります。

いわゆる「ジャンボ」フレームは、標準的な1518バイトの制限を超えるイーサネットフレームです。番号はスイッチベンダーによって異なりますが、オペレーティングシステムとNICの最も一般的なジャンボパケットサイズは9000バイトと9216バイトです（後者が最も一般的です）。およそ6倍のデータを9Kフレームに入れることができるとすると、実際のパケット（および割り込み）の数は、ホスト上で同様の量だけ削減されます。これらのゲインは、大量のデータ（iSCSI）を送信する高速（10GE）リンクで特に顕著です。

ジャンボフレームを有効にするには、ホストとイーサネットスイッチの両方を設定する必要があり、実装前に十分な注意が必要です。いくつかのガイドラインに従う必要があります-

1.）特定のイーサネットセグメント（VLAN）内で、すべてのホストとルーターに同じMTUが構成されている必要があります。適切に設定されていないデバイスは、より大きなフレームをリンクエラー（特に「ジャイアント」）として認識し、ドロップします。

2.）IPプロトコル内で、異なるフレームサイズの2つのホストには、適切な共通フレームサイズをネゴシエートするメカニズムが必要です。TCPの場合、これはパスMTU（PMTU）ディスカバリであり、ICMP到達不能パケットの送信に依存しています。PMTUがすべてのシステムで有効になっており、ACLまたはファイアウォールルールがこれらのパケットを許可していることを確認してください。

イーサネットフロー制御（802.3x）

一部のiSCSIベンダーから推奨されていますが、すべてのスイッチポート、NIC、およびリンクが完全にiSCSIトラフィック専用である場合を除き、ほとんどの環境で単純な802.3xイーサネットフロー制御を有効にしないでください。リンク上に他のトラフィック（SMBまたはNFSファイル共有、クラスターストレージまたはVMwareのハートビート、NICチーミング制御/監視トラフィックなど）がある場合、ポート全体をブロックするため、単純な802.3xフロー制御を使用しないでください。他の非iSCSIトラフィックもブロックされます。イーサネットフロー制御のパフォーマンス向上は多くの場合、最小限または存在しないため、実際のメリットがあるかどうかを判断するには、OS / NIC /スイッチ/ストレージの組み合わせ全体で現実的なベンチマークを実行する必要があります。

サーバーの観点からの実際の質問は、次のとおりです。NICまたはネットワークがオーバーランした場合、ネットワークトラフィックを停止しますか、それともパケットのドロップと再送信を開始しますか？フロー制御をオンにすると、レシーバー側でNICを空にすることができますが、センダー側でバッファーに負荷がかかります（通常、ネットワークデバイスはここでバッファーします）。

TCP輻輳制御（RFC 5681）

TOE（TCP / IPオフロードエンジン）

iSOE（iSCSIオフロードエンジン）

LSO（TCPセグメンテーション/大量送信オフロード）

ネットワーク分離

iSCSIの一般的なベストプラクティスは、イニシエーターとターゲットの両方を他の非ストレージネットワークトラフィックから分離することです。これは、セキュリティ、管理性、および多くの場合、ストレージトラフィックへのリソースの割り当てに関して利点を提供します。この分離にはいくつかの形式があります。

1.）物理的な分離-すべてのイニシエーターには、iSCSIトラフィック専用の1つ以上のNICがあります。これは、問題のハードウェアの機能と、特定の組織内の特定のセキュリティおよび運用要件に応じて、専用のネットワークハードウェアを意味する場合としない場合があります。

2.）論理的分離-主に高速（10GE）ネットワークで見られるイニシエーターには、ストレージと非ストレージのトラフィックを分離するようにVLANタギング（802.1qを参照）が構成されています。

多くの組織では、追加のメカニズムを使用して、iSCSIイニシエーターがこれらの専用ネットワークを介して相互に到達できず、さらにこれらの専用ネットワークが標準データネットワークから到達できないことを保証します。これを達成するために使用される手段には、標準のアクセス制御リスト、プライベートVLAN、およびファイアウォールが含まれます。

ここでもバックプレーンとスイッチングファブリックについての何か。

QoS（802.1p）

vLAN（802.1q）

STP（RSTP、MSTPなど）

トラフィック抑制（ストーム制御、マルチキャスト/ブロードキャスト制御）

セキュリティ

認証とセキュリティ

CHAP

IPSec

LUNマッピング（ベストプラクティス）

次の点について主観的に検討する必要のある検討と研究：

1）マルチパス-SANソリューションとOS、ハイパーバイザーであれベアメタルOSであれ、これが適切に機能するためにはベンダー固有のソフトウェアが必要な場合があります。

2）イニシエーター-ソフトウェアイニシエーターが要求に基づいて十分なパフォーマンスであるかどうかを吟味する必要があります。多くのNICには、スループットを大幅に向上させることができるiSCSIオフロード機能がありますが、特定の古いハイパーバイザーは、賢明なサポートでかなり腹を立てることが知られています。より成熟した製品（ESXi 4.1+）は素晴らしいと思われます。

3）セキュリティ/アクセス許可-どのイニシエーターがどのLUNにアクセスする必要があるかを完全に吟味してください... Windowsマシンのいずれかの管理者がディスク上で「ディスクの初期化」を行うと、ひどいことになりますVMwareデータストアとして別のサーバーで実際に使用されています。