iSCSIストレージの調整
これは、参考として使用できる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、およびリンクが-でない限り、ほとんどの環境で単純な802.3xイーサネットフロー制御を有効にしないでください- iSCSIトラフィック専用 ほかは何もありません。リンクに他のトラフィックがある場合（SMBまたはNFSファイル共有、クラスター化ストレージまたはVMwareのハートビート、NICチーム化制御/監視トラフィック、など）単純な802.3xフロー制御はポート全体をブロックし、他の非iSCSIトラフィックもブロックされるため、使用しない必要があります。パフォーマンスの向上多くの場合、イーサネットフロー制御は最小限または存在しないため、OS/NIC /スイッチ/ストレージの組み合わせ全体で現実的なベンチマークを実行して、実際のメリットがあるかどうかを判断する必要があります。
サーバーの観点からの実際の質問は次のとおりです。NICまたはネットワークがオーバーランしている場合はネットワークトラフィックを停止しますか、それともパケットのドロップと再送信を開始しますか？フロー制御をオンにすると、バッファーが可能になります。 NICは受信側で空になりますが、送信側のバッファに負荷がかかります（通常、ネットワークデバイスはここでバッファします）。
TCP輻輳制御（RFC 5681）
TOE（TCP/IPオフロードエンジン）
iSOE（iSCSIオフロードエンジン）
LSO（TCPセグメンテーション/大規模送信オフロード）
ネットワーク分離
ISCSIの一般的なベストプラクティスは、イニシエーターとターゲットの両方を他の非ストレージネットワークトラフィックから分離することです。これにより、セキュリティ、管理性、および多くの場合、ストレージトラフィックへのリソースの割り当てという点でメリットがあります。この分離にはいくつかの形式があります。
1.）物理的な分離-すべてのイニシエーターには、iSCSIトラフィック専用のNICが1つ以上あります。これは、問題のハードウェアの機能と特定の組織内の特定のセキュリティおよび運用要件に応じて、専用のネットワークハードウェアを意味する場合とそうでない場合があります。
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マシンの1つの管理者が、 VMwareデータストアとして別のサーバーで実際に使用されています。