我们希望实施一个iSCSI SAN，而且我们所有的testing都表明，我们可以很便宜地实施这个（Starwind目标，翻新的HP存储arrays）。
我担心的是交换机本身的吞吐量/延迟问题，因此提出了一些问题：
谢谢，
里克。
我完全同意ynguldyn的回答 – 大多数情况下，任何旨在用于服务器机房\数据中心的现代交换机都应该足够满足您的需求，并且在您的环境中保持一致性可能对您来说更重要支持\可pipe理性的angular度。
这就是说，如果你真的想充分利用你的iSCSI设置使用开关，具有：
足够的每端口缓冲存储器 。 理想情况下，每个端口> 512k，但这里有一个权衡。 有些交换机使用较大的缓冲区来掩盖较差的交换速度，因此您需要寻找更多。 缓冲内存太less会导致重负载下的数据包丢失，并且TCP层将不得不重新发送数据包，这将使速度变慢。
足够的每端口处理能力 。 这可能很难build立 – 寻找的最佳指标是切换速度。 一个具有100微秒切换速度的交换机只能处理10k数据包/秒，不能以线速切换GigE，一个3微秒的交换速度（理论上）可以处理高达300k数据包/秒，这很好。 低于12microsec的任何东西都可能足够好。 越快越好，但价格上涨幅度相当大，因为这个数字低于个位数。
支持硬件stream量控制（802.3x） 。 如果你的服务器网卡和arrays不支持这个function，那么这将是无用的，但是如果他们这么做的话，你的iSCSInetworking可以在第2层更有效地处理stream量控制，而不是依靠更高级别的拥塞控制，比如TCP的拥塞避免algorithm将显着降低效率。 这表示很难find一个不适合今天的正确的开关。
支持巨型帧 。 如果您的iSCSIarrays，服务器硬件和操作系统也支持巨型帧，这也只会是有益的。 在最基本的级别，巨型帧减less了协议开销，可以将吞吐量提高10-20％，但这些收益高度依赖于stream量模式。 对于扩展的高带宽数据传输，9k巨型帧可以将arrays，服务器（和交换机）的CPU开销降低80％。 由于初始CPU开销可能相对较低，因此在您的环境中这可能也可能不重要。 低端交换机有时会声称支持巨型帧，但不支持9k巨型帧，这是GigE公认的最佳尺寸，因此请先检查。 如果你的arrays不支持巨帧，显然不需要担心。
高带宽交换和堆叠能力 。 对于GigE，您应该将每个端口的速率设置为> 1Gbps，理想情况下为2Gbps，以处理所有端口的线速全双工通信量。 对于一个24端口的交换机，你希望它能够在内部交换48Gbps，并且如果你使用多个交换机的话，能够以相当大的百分比进行堆叠/上传。 对于某些iSCSI架构（例如HP Lefthand和Dell Equallogic），您需要支持所有arrays上所有端口之间的高带宽stream量，并且总体交换速度变得非常重要。 对于支持混合1GigE和10GigE的交换机，相应地进行调整，总交换带宽应覆盖全双工模式下全速运行的所有端口。
生成树。 如果您的iSCSI环境足够简单且与其他任何环境隔离，或希望其能够支持快速生成树\端口快速\边缘端口，您可以select性地禁用特定端口上的完整生成树行为。
GigE是一种老旧稳定的技术，现代交换机的处理能力足以应付，尤其是当它只是一个目标和less数发起者的时候。 您应该期待任何体面的交换机（20美元的小盒子，那个开发人员，当然不包括他们的办公桌到生气的系统pipe理员），在SAN环境中没有时间和性能问题。 相关function集在所有这些function集中都是相同的，包括巨型帧，stream量控制，VLAN以及您可能需要的所有其他function。
相反，你应该把重点放在预算，现有的供应商关系，安装的硬件和内部的专业知识上：得到你可以承受的和你最了解的东西，并坚持使用你已经使用的品牌（原因有两个：手册阅读的手段较less更深入地了解你所拥有的知识，避免互操作性问题）。 思科，ProCurve，北电，高端网件应该都是好的。
iSCSI只是一个像其他协议一样的协议; 要查找的主要问题是，您可能需要正确支持巨帧的交换机。