重新审视较旧的 vSphere 设置，其中有两台 Dell 1950，每台主机 4 个 NIC：
esxi1为了esxi2简单起见。
SAN 是 Dell MD3000i，两个控制器，每个控制器两个 NIC：
rc00和rc01；rc10和rc11
目前仅配置了一个 LUN 0/虚拟磁盘；RAID 10、300GB SAS 15K、6 个主轴。控制器/通道如下：
rc00地址：192.168.130.101/24
rc01地址：192.168.131.101/24
rc10地址：192.168.130.102/24
rc11地址：192.168.131.102/24
交换机（sw-1和sw-2）是 Dell PowerConnect 5424s；由于两台交换机上没有其他流量，因此未启用 iSCSI“优化”（QoS）。启用巨型帧，9000 MTU，开启流量控制，MDIX 自动。
当这个设置是空的并且我有一些时间的时候，想做一些基准测试。
由于时间过去很久了，我记不清如何设置多路径了，于是，通过谷歌搜索并阅读了戴尔和 vmware 的几份旧版 4.1 白皮书，我发现实际上有两种方法可以做到：
一个具有多个 VMKernel 端口和物理 NIC 的 vSwitch：
rc00:192.168.130.101--- sw-1---- esxi1:vSwitch1:vmk1:eth1:192.168.130.11
rc01:192.168.131.101--- sw-2----esxi1:vSwitch1:vmk2:eth2:192.168.131.11
...或两个带有一个 VMKernel 端口和一个物理 NIC 的 vSwitch：
rc00:192.168.130.101--- sw-1---- esxi1:vSwitch1:vmk1:eth1:192.168.130.11
rc01:192.168.131.101--- sw-2----esxi1:vSwitch2:vmk1:eth2:192.168.131.11
问题 1：性能上是否存在实际差异，或者选择其中一个的理由是什么？其他一切看起来都还好吗？
问题 2：我实际上已将 VMKernel 端口交错排列在 NIC 控制器上，以便其中一个 VMKernel 端口/物理 NIC（eth1）绑定到其中一个内置 Broadcom NIC，而另一个（eth2）绑定到其中一个 Intel NIC。
我认为如果其中一个 NIC/NIC 控制器出现故障，则仍然有一条路径可通过第二个 NIC/NIC 控制器使用。但我想知道这是否会导致多路径性能问题或一般不稳定；没有看到任何迹象表明这种情况。
也许我预计故障可能永远不会“很好地”失败（即，如果出现 NIC 故障，则主机很可能会发疯）。
注意：“一个 vSwitch，多个 VMKernel 端口”方法实际上似乎让 ESXi 主机崩溃。重新启动需要异常长的时间，有时路径/LUN 不显示主动/主动 I/O 或根本不显示，需要重新扫描和/或启动/关闭 VMKernel 才能再次看到 LUN。无论如何，这看起来很奇怪，因为您将两个不同的子网放在同一个 vSwitch/广播域上，我相信 vSwitch 充当第 2 层交换机。
基准＃1：这看起来不是很糟糕吗？
运行具有“典型”设置（1 vCPU、1024 MB RAM、8 GB 磁盘、文件系统默认、带有 LVM 的 ext4）的 ubuntu 10.04.2 LTS 并且bonnie++：
gravyface@testubu:~$ bonnie++ -f -d /tmp
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
testubu 2G 96131 57 33783 16 98930 17 444.6 13
Latency 623ms 645ms 111ms 503ms
Version 1.96 ------Sequential Create------ --------Random Create--------
testubu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 16509 79 +++++ +++ 25608 88 19044 86 +++++ +++ 25079 86
Latency 10289us 1398us 8288us 509us 442us 12159us
采取 2：
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
testubu 2G 97240 54 32974 17 93371 17 420.6 14
Latency 291ms 1421ms 1266ms 616ms
Version 1.96 ------Sequential Create------ --------Random Create--------
testubu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 14410 71 +++++ +++ 22082 86 18109 88 +++++ +++ 22054 88
Latency 108ms 1324us 2400us 814us 88us 4835us
1.96,1.96,testubu,1,1336168050,2G,,,,97240,54,32974,17,,,93371,17,420.6,14,16,,,,,14410,71, +++++,+++,22082,86,18109,88,+++++,+++,22054,88,,291ms,1421ms,,1266ms,616ms,108ms,1324us,2400us,814us,88us,4835us
采取 3：使用--iops=3来自esxcli
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
testubu 2G 115663 61 35594 18 103602 21 440.0 17
Latency 285ms 571ms 52049us 477ms
Version 1.96 ------Sequential Create------ --------Random Create--------
testubu -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 14206 73 +++++ +++ 22753 90 18424 91 +++++ +++ 22367 90
Latency 108ms 1951us 1827us 6200us 326us 6127us
1.96,1.96,testubu,1,1336168752,2G,,,,115663,61,35594,18,,,103602,21,440.0,17,16,,,,,14206,73,+++++,+++,22753,90,18424,91,+++++,+++,22367,90,,285ms,571ms,,52049us,477ms,108ms,1951us,1827us,6200us,326us,6127us
答案1
Q1：通常的做法是每个 vmkernel 端口一个 vSwitch，但我不知道如果以其他方式操作是否会出现问题。vSphere 5 有一个非常严格的合规性测试，您必须通过该测试才能将适配器绑定到 iSCSI 启动器，如果您使用单个 vSwitch，则可能会失败。但这些只是我的想法，而不是实际事实 :)
问题 2：我还为每个 vmkernel 使用不同的 NIC，因为我以前见过 NIC 出现故障的情况。您确实不希望丢失与存储的所有连接。但话又说回来，发生这种情况的可能性并不大。在 FC 环境中，使用双单端口 HBA 而不是单个双端口 HBA 也很常见。谨慎总比后悔好？
无论哪种方式 - 您都不应该遇到任何性能问题，因为所有现代 NIC 都内置了卸载功能。我实际上猜测使用双 NIC 可以获得更好的性能，因为您可以获得不同的中断和单独的 PCIe 通道。