调整iSCSI存储

这是关于iSCSI的规范问题 ,我们可以用作参考。

iSCSI是一种将SCSI命令作为有效负载放入TCPnetworking数据包的协议。 因此,它受到与光纤通道不同的一系列问题的困扰。 例如,如果一个链路拥塞并且交换机的缓冲区已满,以太网将默认丢弃帧,而不是告诉主机减速。 这导致重传,这导致存储stream量的很小部分的高延迟。

有针对此问题的解决scheme,具体取决于客户端操作系统,包括修改networking设置。 对于以下的操作系统列表,最佳的iSCSI客户端configuration是什么样的? 会涉及到更改交换机上的设置? 那储物柜呢?

  • VMWare 4和5
  • Windows Hyper-V 2008和2008r2
  • Windows 2003和2008裸机
  • 裸机上的Linux
  • AIX VIO
  • 你碰巧认为的任何其他操作系统都是相关的

我不熟悉VMWare,但我使用Xenserver,并使用Hyper-V(R2)。

用我目前的Xenserverconfiguration,我有:

  • 8戴尔Poweredge 29xx服务器
  • 2个Dell Powerconnect 6248交换机
  • 2 Dell MD3000i SAN(iSCSI)

我已经在多pathconfiguration中设置了交换机,并通过以下方式对iSCSI进行了优化:

  • 将交换机分成3个VLAN(2个用于iSCSIstream量,1个用于pipe理)
  • 使用JumboFrames
  • 应用powerconnect所具有的“iSCSI”优化

每台服务器都有多个网卡,以便为每台交换机提供连接,从而通过服务器和iSCSI SAN之间的多path提供冗余。 iSCSI VLAN不包含除iSCSI之外的其他stream量。

我很高兴地通过这个configuration报告XenServer“集群”的出色performance。

在一个侧面说明我有一个Windows 2008服务器直接通过iSCSI连接到HP SAN(旧文件服务器)。 它曾经运行Windows 2003,并经常会放弃连接(即使在2003年重新安装后); 但是,只要我升级到Windows 2008它保持连接。

我很乐意回答有关我的设置的任何问题。

这不是一个答案。 这是通用答案的框架。 如果您有时间,请填写您所知道的任何内容。 关于configuration特定的硬件,请为每个供应商发布一个单独的答案,以便我们可以保持这些信息的组织和分离。

端口的QoSconfiguration文件,closures风暴控制,将MTU设置为9000,打开stream量控制,并将端口置入portfast

吞吐量和延迟

更新的固件,驱动程序和其他系统

MPIO

巨型帧/ MTU

随着networking链路速度的增加,可能产生的分组数量也增加。 这产生了越来越多的生成数据包的CPU /中断时间,这既影响发送系统的负担,也占用过多的链路带宽。

所谓的“巨型”帧是超过了规范1518字节限制的以太网帧。 虽然数字可能会根据交换机供应商,操作系统和NIC的不同,最典型的巨型数据包大小是9000和9216字节(后者是最常见的)。 考虑到大约6X的数据可以放入一个9K帧,实际的数据包(和中断)的数量在主机上减less了相似的数量。 这些收益在发送大量数据(即iSCSI)的更高速(即10GE)链路上尤其明显。

启用巨型帧需要configuration主机和以太网交换机,在实施之前应格外小心。 应遵循几个准则 –

1.)在给定的以太网段(VLAN)内,所有的主机和路由器应该configuration相同的MTU。 没有正确configuration的设备会将更大的帧视为链接错误(特别是“巨人”),并将其丢弃。

2.)在IP协议内,具有不同帧大小的两个主机需要一些机制来协商适当的通用帧大小。 对于TCP,这是pathMTU(PMTU)发现,并且依赖于ICMP不可达分组的传输。 确保所有系统上都启用了PMTU,并且任何ACL或防火墙规则都允许这些数据包。

以太网stream量控制(802.3x)

尽pipe被某些iSCSI供应商推荐,但在大多数环境中, 应该启用简单的802.3x以太网stream量控制,除非所有交换机端口,NIC和链路完全专用于iSCSIstream量 。 如果链路上有任何其他stream量(如SMB或NFS文件共享,群集存储或VMware的心跳,网卡绑定控制/监控stream量等),则不应使用简单的802.3xstream量控制,因为它会阻塞整个端口和其他非iSCSIstream量也将被阻止。 以太网stream量控制的性能提升往往很小或根本不存在,应该在整个OS / NIC /交换机/存储组合上进行realistinc基准testing,以确定是否有任何实际的好处。

从服务器的angular度来看,实际的问题是:如果我的网卡或networking超载,或者是否开始丢弃和重新传输数据包,是否停止networking通信? 打开stream量控制将允许缓冲区NIC在接收端清空,但会强调发送端的缓冲区(通常networking设备将在此缓冲)。

TCP拥塞控制(RFC 5681)

TOE(TCP / IP卸载引擎)

iSOE(iSCSI卸载引擎)

LSO(TCP分段/大发送卸载)

networking隔离

iSCSI最常见的做法是将启动器和目标与其他非存储networkingstream量隔离。 这在安全性,可pipe理性以及在许多情况下为存储stream量贡献资源方面提供了好处。 这种隔离可能有几种forms:

1.)物理隔离 – 所有启动器都有一个或多个专用于iSCSIstream量的NIC。 这可能 – 也可能不 – 意味着专用networking硬件,这取决于所讨论的硬件的能力以及给定组织内的特定安全性和操作要求。

2.)逻辑隔离 – 主要在更快的(即10GE)networking中发现,启动器具有configuration为分隔存储和非存储通信的VLAN标记(参见802.1q)。

在许多组织中,还采用了额外的机制来确保iSCSI启动器无法通过这些专用networking相互访问,而且这些专用networking无法从标准数据networking访问。 用于实现这一目的的措施包括标准访问控制列表,专用VLAN和防火墙。

这里也有关于背板和交换结构的东西。

QoS(802.1p)

vLAN(802.1q)

STP(RSTP,MSTP等)

stream量抑制(风暴控制,多播/广播控制)

安全

身份validation和安全

CHAP

安全

LUN映射(最佳实践)

一些考虑和研究,你应该主观地考虑到:

1)多path – 您的SAN解决scheme和您的操作系统,无论是pipe理程序或裸机操作系统可能需要供应商特定的软件,才能正常工作。

2)启动器 – 你需要根据需求来检查软件启动器是否有足够的性能。 许多网卡具有iSCSI卸载function,可显着提高吞吐量,但某些较早的虚拟机pipe理程序在支持它们的情况下会变得非常小心。 更成熟的产品(ESXi 4.1+)似乎很好。

3)安全性/权限 – 确保完全核实哪些启动程序需要访问哪些LUN ……如果某个Windows计算机上的pipe理员在磁盘上执行“初始化磁盘”,那么这将是糟糕的一天被另一台服务器真正用作VMware数据存储。