Возвращаясь к старой установке vSphere с двумя Dell 1950-х годов, 4 сетевыми картами на хост: esxi1 и esxi2 для простоты.
SAN - это Dell MD3000i, два контроллера, две сетевые карты на контроллер: rc00 и rc01; rc10 и rc11
Только один LUN 0 / виртуальный диск настроен прямо сейчас; RAID 10, 300 ГБ 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 5424; «Оптимизация» iSCSI (QoS) не включена, так как на двух коммутаторах нет другого трафика. Jumbo Frames включены, 9000 MTU, управление потоком включено, MDIX автоматически.
Хотел провести сравнительный анализ, пока эта установка пуста, а у меня есть время.
Не могу точно вспомнить, как настроить многопутевость, так как это было некоторое время, поэтому, погуглил и прочитав пару старых официальных документов 4.1 от Dell и vmware, я на самом деле вижу два способа сделать это:
один vSwitch с несколькими портами VMKernel и физическими сетевыми адаптерами:
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 и одним физическим сетевым адаптером:
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 на контроллерах сетевых адаптеров так, чтобы один из портов VMKernel / физических сетевых адаптеров (eth1) был привязан к одному из встроенных сетевых адаптеров Broadcom, а другой (eth2) был привязан к одному сетевых адаптеров Intel.
Я подумал, что если один из контроллеров NIC / NIC идет на юг, значит, путь через второй контроллер NIC / NIC все еще доступен. Интересно, вызовет ли это проблемы с производительностью работы с несколькими путями или общую нестабильность; не видел ничего, что указывало бы на тот или иной путь.
Возможно, я предвижу сбой, который, вероятно, никогда не выйдет из строя так «хорошо» (то есть, если произойдет сбой сетевой карты, скорее всего, хост все равно просто сойдет с ума).
ПРИМЕЧАНИЕ: метод «один vSwitch, несколько портов VMKernel» действительно пугает хост ESXi. Для перезагрузки требуется ненормально много времени, иногда пути / LUN не показывают активный / активный ввод-вывод или не отображаются вообще, требуется повторное сканирование и / или и / или вверх / вниз VMKernel, чтобы он снова увидел LUN . В любом случае это выглядит странно для конфигурации, поскольку вы помещаете две разные подсети в один и тот же домен vSwitch / broadcast, и я считаю, что vSwitches функционируют как коммутатор уровня 2.
Тест №1: не кажется ли это ужасным?
Запуск ubuntu 10.04.2 LTS с "типичными" настройками (1 виртуальный ЦП, 1024 МБ ОЗУ, 8 ГБ диск, значения по умолчанию для файловой системы, ext4 с LVM) и 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: Один vSwitch на порт vmkernel - это обычный способ сделать это, но я не уверен, что что-то будет дергаться, если вы сделаете это каким-либо другим способом. vSphere 5 имеет довольно строгий тест на соответствие, который необходимо пройти, чтобы привязать адаптер к инициатору iSCSI, и он может выйти из строя, если вы используете один vSwitch. Но это всего лишь мои мысли, а не реальные факты :)
Q2: Я также использую разные сетевые адаптеры для каждого vmkernel, так как я видел, как сетевые адаптеры выходили из строя раньше ... вы действительно не хотите терять все подключения к вашему хранилищу ... но опять же, вероятность того, что что-то подобное произойдет, не т точно большой. В средах FC также довольно часто используется двойной однопортовый HBA вместо одинарного двухпортового HBA. Береженого Бог бережет?
В любом случае - вы не должны испытывать никаких проблем с производительностью, поскольку все современные сетевые адаптеры имеют встроенную разгрузку. Я бы предположил, что вы получите лучшую производительность с двумя сетевыми адаптерами, поскольку вы получаете разные прерывания и отдельную полосу PCIe ..