Ric*_*ick 7 networking iscsi switch
我们想要实现一个 iSCSI SAN，我们所有的测试都表明我们可以非常便宜地实现它（Starwind 目标，翻新的 HP 存储阵列）。
我担心的是交换机本身的吞吐量/延迟，所以有待解决的问题：
谢谢，
瑞克。
我完全同意 ynguldyn 的回答 - 在大多数情况下，用于服务器机房\数据中心的任何现代交换机都应该足以满足您的需求，并且在您的环境中保持一致对您来说可能更重要支持\可管理性的观点。
也就是说，如果您真的想充分利用 iSCSI 设置，请使用具有以下功能的交换机：
每个端口有足够的缓冲内存。理想情况下，每个端口 >512k，但这里有一个权衡。一些交换机使用更大的缓冲区来掩盖糟糕的切换速度，因此您需要寻找更多。太少的缓冲内存会导致重负载下的数据包丢失，TCP 层将不得不重新发送数据包，这将大大减慢一切。
足够的每端口处理能力。这可能很难确定 - 要寻找的最佳指标是切换速度。切换速度为 100 微秒的交换机只能处理 10k 数据包/秒，而无法以线速切换 GigE，而具有 3 微秒切换速度的交换机（理论上）可以处理高达 300k 数据包/秒，这很好。任何低于 12 微秒的值都可能足够好。越快越好，但随着该数字趋向于低个位数，价格会大幅上涨。
支持硬件流控制 (802.3x)。如果您的服务器 NIC 和阵列也不支持此功能，这将毫无用处，但如果它们支持，则允许您的 iSCSI 网络在第 2 层更有效地处理流量控制，而不是依赖更高级别的拥塞控制，例如 TCP 的拥塞避免算法。将显着降低效率。也就是说，今天很难找到一个不支持它的合适的开关。
支持巨型帧。同样，如果您的 iSCSI 阵列、服务器硬件和操作系统也支持巨型帧，这将是有益的。在最基本的层面上，巨型帧减少了协议开销，可以将吞吐量提高 10-20%，但这些收益在很大程度上取决于流量模式。对于扩展的高带宽数据传输，9k 巨型帧还将减少阵列、服务器（和交换机）上的 CPU 开销高达 80%。这在您的环境中可能重要也可能不重要，因为初始 CPU 开销可能相对较低。低端交换机有时声称支持 Jumbo 帧，但不支持 9k Jumbo 帧，这是公认的 GigE 最佳大小，因此请先检查一下。如果您的阵列不支持 Jumbo 帧，则显然无需担心这一点。
高带宽交换和堆叠能力。对于 GigE，您的目标应该是每个端口 >1Gbps，理想情况下是 2Gbps，以便在所有端口上以线速处理全双工流量。对于 24 端口交换机，您希望它能够在内部切换 48Gbps，并且如果您使用多个交换机，则能够以相当大的百分比堆叠/上行。对于某些 iSCSI 架构（例如 HP Lefthand 和 Dell Equallogic），您需要在所有阵列的所有端口之间支持非常高的带宽流量，并且聚合交换速度变得非常重要。对于支持混合 1GigE 和 10GigE 的交换机，相应地调整总交换带宽应覆盖在全双工模式下全速运行的所有端口。
生成树。如果您的 iSCSI 环境足够简单并且与其他所有内容隔离，您希望能够完全禁用它，或者让它支持快速生成树\端口快速\边缘端口，您可以在其中有选择地禁用特定端口上的完整生成树行为。