Revisitando uma configuração mais antiga do vSphere com dois Dell 1950s e 4 NICs por host:
esxi1 e esxi2 para simplificar.
O SAN é um Dell MD3000i, dois controladores, dois NICs por controlador:
rc00 e rc01 ; rc10 e rc11
Apenas um LUN 0 / disco virtual configurado agora; RAID 10, 300GB SAS 15K, 6 eixos. Controladores / canais são os seguintes:
rc00 : 192.168.130.101/24
rc01 : 192.168.131.101/24
rc10 : 192.168.130.102/24
rc11 : 192.168.131.102/24
Os comutadores ( sw-1 e sw-2 ) são do Dell PowerConnect 5424s; A "otimização" (QoS) do iSCSI não é ativada, pois não há nenhum outro tráfego nos dois comutadores. Jumbo Frames habilitado, 9000 MTU, controle de fluxo ativado, MDIX auto.
Queria fazer alguns benchmarking enquanto esta configuração está vazia e eu tenho algum tempo em minhas mãos.
Não foi possível lembrar como configurar os multipathing como há algum tempo, pesquisando e lendo alguns dos mais antigos white papers 4.1 da Dell e VMware, estou vendo realmente duas maneiras de fazer isso:
um vSwitch com várias portas VMKernel e NICs físicas:
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
... ou dois vSwitches com uma porta VMKernel e uma NIC física:
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
Pergunta # 1: Existem diferenças práticas no desempenho ou uma razão para escolher uma sobre a outra? Tudo o mais parece ok?
Pergunta # 2: Eu realmente balancei as portas VMKernel através dos controladores NIC de modo que uma das portas NICs físicas / físicas (eth1) do VMKernel esteja vinculada a uma das placas de rede Broadcom e a outra (eth2) vinculado a uma das NICs da Intel.
Eu percebi que se um dos controladores NICs / NIC fosse para o sul, ainda haveria um caminho disponível através do segundo controlador NIC / NIC. No entanto, você está se perguntando se isso causará problemas de desempenho de vários caminhos ou escoriações gerais; Não vi nada lá fora para indicar um caminho ou outro.
Talvez eu esteja antecipando uma falha que provavelmente nunca falhará "muito bem" (ou seja, se houver uma falha na placa de rede, é provável que o host simplesmente surte de qualquer maneira).
OBSERVAÇÃO: o método "one vSwitch, multiple VMKernel Ports" parece realmente enlouquecer o host ESXi. Leva um tempo anormalmente longo para reinicializar, algumas vezes os caminhos / LUNs não estão mostrando E / S ativa / ativa ou aparecendo, exigindo uma nova verificação e / ou up / down do VMKernel para fazer com que ele veja os LUNs novamente . Parece estranho para uma configuração de qualquer maneira como você está colocando duas sub-redes diferentes no mesmo domínio vSwitch / broadcast, e acredito que o vSwitches funcionar como um switch de camada 2.
Referência 1: isso não parece terrível?
Executando o Ubuntu 10.04.2 LTS com configurações "típicas" (1 vCPU, 1024 MB de RAM, 8 GB de disco, padrões para sistema de arquivos, ext4 com LVM) e 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
Tome 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
Take 3: com --iops=3 definido em 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