10 Replies Latest reply: Dec 3, 2013 12:01 AM by VYATKAFLEX RSS

Агрегация каналов и странность балансировки трафика по ip со стороны NetApp

VYATKAFLEX
Currently Being Moderated

Дано:

  • FAS 2240-4 HA (8.1.3P3) - 2 головы по 4 1гбит линка
  • 2 сервера с VMware ESXi, в каждом 4 выделенные сетевые карточки по 1Гб для связи с хранилищем
  • 2 гигабитных свича в стеке (HP 2920)

 

Хочется задействовать всю доступную полосу пропускания и имеющиеся интерфейсы серверов и СХД. Т.е. сервер 1 работает преимущественно с ВМ расположенными на голове А, сервер 2 с ВМ на голове Б, у всех по 4 интерфейса, ВМ разбиты на 4 группы, все поделено равномерненько и по честному.

Далее (для упрощения) описаны манипуляции с одной головой, одним сервером и протоколом nfs...

 

Основываясь на tr-3749, tr-3802 и tr-3839 сделано следующее:

  • 2 линка контроллера подключил в один свич, 2 в другой
  • на стороне свича настроен multichassis LACP с балансировкой по IP
  • на свиче для портов контроллера установлен Flowcontrol = on
  • на контроллере для всех портов установлен Flowcontrol = send
  • 4 линка по 1Гб на стороне контроллера объединены в один LACP с балансировкой по IP
  • поверх vif (ifgrp) создан vlan и ему присвоен IP, дополнительно созданы 3 алиаса (адреса выданы последовательно)
  • созданы 4 volume, в каждом volume создан qtree, volume экспортированы по nfs
  • на сервере esxi создан vSwitch с 4 интерфейсами с балансировкой по IP
  • на этом vSwitch создан порт vmkernel в той же IP подсети и том же vlan, в котором располагается основной ip и алиасы контроллера
  • jumbo фреймы включены по всей цепочке (netapp, свич, vlan на свиче, vSwitch, порт vmkernel)
  • в esxi добавлены 4 nfs датастора, все с разных ip адресов (т.е. задействованы и основной ip и все алиасы контроллера)
  • развернуты 4 VM vmware-io-analyzer-1.5.1.ova на разные nfs датасторы

 

После этого проведены тесты полосы пропускания (паттерн Max-throughput в vmware-io-analyzer) на чтение и на запись.

 

Сначала выводы тестов....

 

После запуска генерации линейной записи на всех 4 VM и соответственно на 4 nfs cтораджах для создания максимальной нагрузки на линии связи на чтение был получен следующий результат:

  • трафик в направлении esxi сервер - свич распределяется равномерно между всеми 4 интерфейсами интерфейсами
  • трафик в направлении свич - netapp распределяется равномерно между всеми 4 интерфейсами

 

После запуска генерации линейного чтения на всех 4 VM и соответственно 4 nfs cтораджах для создания максимальной нагрузки на линии связи был получен следующий результат:

  • трафик в направлении свич - esxi сервер распределяется равномерно между всеми 4 интерфейсами
  • трафик в направлении netapp - свич распределяется НЕ равномерно между интерфейсами. Один интерфейс контроллера практически незагружен исходящим трафиком.

 

Из этого следует, что 2 датастора при чтении с СХД делят между собой один физический линк контроллера.

 

Во избежание классического "лечения" сразу скажу, что про то, что в среднем ни одна ВМ гигабит не прогружает знаю. Мало того, я от большинства не отличаюсь, у меня тоже так. Но бывают моменты (например резервное копирование/восстановление баз данных), когда упираешься в полосу 1Гб. Да это бывает не часто, но разработчики могут делать эти действия днем и не по разу, поэтому нужна уверенность. что продуктивная база и базы разработчиков, располагаясь на разных датасторах не будут использовать один физический линк. Ну и вообще не нравится не понимать принципы работы...

 

Исходя из бестпрактикс и собранной схемы в процессе тестирования ожидалось увидеть, что трафик каждой VM идет по своему линку, так как по формуле (Адрес_Источника XOR Адрес_Получателя) % ЧислоЛинков , из бестпрактикс данный вид нагрузки должен идеально распределятся по интерфейсам. Расчеты балансировки по ip ниже...

 

Последний октет ip адреса esxi - 12, у контроллера соответственно 30, 31, 32, 33

12 xor 30 = 18, 18 % 4 = 2 линк

12 xor 31 = 19, 19 % 4 = 3 линк

12 xor 32 = 44, 44 % 4 = 0 линк

12 xor 33 = 45, 45 % 4 = 1 линк

 

Видно, что балансировка по теории отличная.

 

Фрагменты настройки netapp

san01a> rdfile /etc/rc
#Create Alexgo Sep  8 17:51:08 MSK 2013
hostname san01a
ifgrp create lacp vif1 -b ip e0d e0b e0c e0a
vlan create vif1 53
ifconfig e0a flowcontrol send up
ifconfig e0b flowcontrol send up
ifconfig e0c flowcontrol send up
ifconfig e0d flowcontrol send up
ifconfig e0M `hostname`-e0M netmask 255.255.255.0 broadcast 10.10.10.255 flowcontrol full partner 10.10.40.11 mtusize 1500 trusted wins up
ifconfig e0P `hostname`-e0P netmask 255.255.252.0 broadcast 192.168.3.255 flowcontrol full up
ifconfig vif1-53 `hostname`-vif1-53 netmask 255.255.255.0 partner vif1-53 mtusize 9000 trusted -wins up
ifconfig vif1-53 alias 10.10.53.31 netmask 255.255.255.0 up
ifconfig vif1-53 alias 10.10.53.32 netmask 255.255.255.0 up
ifconfig vif1-53 alias 10.10.53.33 netmask 255.255.255.0 up
route add net default 10.10.10.3 1
routed on
options dns.domainname vtflex.ru
options dns.enable on
options nis.enable off
savecore

san01a> rdfile /etc/hosts
#Create Alexgo Sep  8 17:51:08 MSK 2013
127.0.0.1    localhost    localhost-stack
127.0.10.1   localhost-10 localhost-bsd
127.0.20.1   localhost-20 localhost-sk
10.10.40.10   san01a san01a-e0M
192.168.1.185   san01a san01a-e0P
10.10.53.30     san01a-vif1-53

san01a> exportfs
/vol/vol_filerA_nfsA    -sec=sys,rw,nosuid
/vol/vol_filerA_nfsB    -sec=sys,rw,nosuid
/vol/vol_filerA_nfsC    -sec=sys,rw,nosuid
/vol/vol_filerA_nfsD    -sec=sys,rw,nosuid

san01a> qtree
qtree: This command is deprecated; using qtree status.
Volume   Tree     Style Oplocks  Status
-------- -------- ----- -------- ---------
rootvol           unix  enabled  normal
vol_filerA_nfsA          unix  enabled  normal
vol_filerA_nfsA qtree_filerA_nfsA unix  enabled  normal
vol_filerA_nfsB          unix  enabled  normal
vol_filerA_nfsB qtree_filerA_nfsB unix  enabled  normal
vol_filerA_nfsC          unix  enabled  normal
vol_filerA_nfsC qtree_filerA_nfsC unix  enabled  normal
vol_filerA_nfsD          unix  enabled  normal
vol_filerA_nfsD qtree_filerA_nfsD unix  enabled  normal

 

К VMware ESXi подключены следующие датасторы

ds_filerA_nfsA 10.10.53.30:/vol/vol_filerA_nfsA/qtree_filerA_nfsA
ds_filerA_nfsB 10.10.53.31:/vol/vol_filerA_nfsB/qtree_filerA_nfsB
ds_filerA_nfsC 10.10.53.32:/vol/vol_filerA_nfsC/qtree_filerA_nfsC
ds_filerA_nfsD 10.10.53.33:/vol/vol_filerA_nfsD/qtree_filerA_nfsD

 

Запускаю генерацию линейного чтения на всех 4 VM и соответственно 4 nfs cтораджах для создания максимальной нагрузки на линии связи

Вижу следующую картину на сторадже

 

san01a> ifgrp stat vif1 10
Interface group(trunk) vif1
        e0b                 e0a                 e0c                 e0d
  Pkts In   Pkts Out  Pkts In   Pkts Out  Pkts In   Pkts Out  Pkts In   Pkts Out
  14225k    13673k    15542k    249k      13838k    11690k    15544k    7809k
  46075     38052     90911     7         45882     37666     90812     37704
  46953     37735     91581     4         46506     37613     91777     37625
  46822     38016     91409     7         45498     37589     91670     37687
  46906     38046     91514     6         45469     37591     91495     37588
  46600     37737     91308     4         46554     37538     91514     37610
  46792     37929     91371     7         45803     37532     91261     37508
  46845     37831     91228     8         46307     37517     91450     37587

san01a> ifstat -a

-- interface  e0a  (3 hours, 30 minutes, 53 seconds) --

RECEIVE
Frames/second:    9147  | Bytes/second:      916k | Errors/minute:       0
Discards/minute:     0  | Total frames:    16347k | Total bytes:     73753m
Total errors:        0  | Total discards:      0  | Multi/broadcast:     0
No buffers:          0  | Non-primary u/c:     0  | Tag drop:            0
Vlan tag drop:       0  | Vlan untag drop:     0  | Vlan forwards:       0
Vlan broadcasts:     0  | Vlan unicasts:       0  | CRC errors:          0
Runt frames:         0  | Fragment:            0  | Long frames:         0
Jabber:              0  | Alignment errors:    0  | Bus overruns:        0
Xon:                 0  | Xoff:                0  | Jumbo:            8359k
TRANSMIT
Frames/second:       1  | Bytes/second:       87  | Errors/minute:       0
Discards/minute:     0  | Total frames:      249k | Total bytes:      7674m
Total errors:        0  | Total discards:      0  | Multi/broadcast:  1006
Queue overflows:     0  | No buffers:          0  | Max collisions:      0
Single collision:    0  | Multi collisions:    0  | Late collisions:     0
Xon:                 0  | Xoff:                0  | Jumbo:             239k
LINK_INFO
Current state:       up | Up to downs:         2  | Speed:            1000m
Duplex:            full | Flowcontrol:       none


-- interface  e0b  (3 hours, 30 minutes, 53 seconds) --

RECEIVE
Frames/second:    4678  | Bytes/second:      467k | Errors/minute:       0
Discards/minute:     0  | Total frames:    14637k | Total bytes:     73533m
Total errors:        0  | Total discards:      0  | Multi/broadcast:     0
No buffers:          0  | Non-primary u/c:     0  | Tag drop:            0
Vlan tag drop:       0  | Vlan untag drop:     0  | Vlan forwards:       0
Vlan broadcasts:     0  | Vlan unicasts:       0  | CRC errors:          0
Runt frames:         0  | Fragment:            0  | Long frames:         0
Jabber:              0  | Alignment errors:    0  | Bus overruns:        0
Xon:                 0  | Xoff:                0  | Jumbo:            8352k
TRANSMIT
Frames/second:    3773  | Bytes/second:      123m | Errors/minute:       0
Discards/minute:     0  | Total frames:    14007k | Total bytes:     57209m
Total errors:        0  | Total discards:      1  | Multi/broadcast:  1531
Queue overflows:     1  | No buffers:          0  | Max collisions:      0
Single collision:    0  | Multi collisions:    0  | Late collisions:     0
Xon:                 0  | Xoff:                0  | Jumbo:            2756k
LINK_INFO
Current state:       up | Up to downs:         2  | Speed:            1000m
Duplex:            full | Flowcontrol:       none


-- interface  e0c  (3 hours, 30 minutes, 53 seconds) --

RECEIVE
Frames/second:    4630  | Bytes/second:      461k | Errors/minute:       0
Discards/minute:     0  | Total frames:    14243k | Total bytes:     69574m
Total errors:        0  | Total discards:      0  | Multi/broadcast:     0
No buffers:          0  | Non-primary u/c:     0  | Tag drop:            0
Vlan tag drop:       0  | Vlan untag drop:     0  | Vlan forwards:       0
Vlan broadcasts:     0  | Vlan unicasts:       0  | CRC errors:          0
Runt frames:         0  | Fragment:            0  | Long frames:         0
Jabber:              0  | Alignment errors:    0  | Bus overruns:        0
Xon:                 0  | Xoff:                0  | Jumbo:            7800k
TRANSMIT
Frames/second:    3756  | Bytes/second:      123m | Errors/minute:       0
Discards/minute:     0  | Total frames:    12022k | Total bytes:       189g
Total errors:        0  | Total discards:      0  | Multi/broadcast:  1003
Queue overflows:     0  | No buffers:          0  | Max collisions:      0
Single collision:    0  | Multi collisions:    0  | Late collisions:     0
Xon:                 0  | Xoff:                0  | Jumbo:            6283k
LINK_INFO
Current state:       up | Up to downs:         2  | Speed:            1000m
Duplex:            full | Flowcontrol:       none


-- interface  e0d  (3 hours, 30 minutes, 53 seconds) --

RECEIVE
Frames/second:    9127  | Bytes/second:      915k | Errors/minute:       0
Discards/minute:     0  | Total frames:    16349k | Total bytes:     73554m
Total errors:        0  | Total discards:      0  | Multi/broadcast:     0
No buffers:          0  | Non-primary u/c:     0  | Tag drop:            0
Vlan tag drop:       0  | Vlan untag drop:     0  | Vlan forwards:       0
Vlan broadcasts:     0  | Vlan unicasts:       0  | CRC errors:          0
Runt frames:         0  | Fragment:            0  | Long frames:         0
Jabber:              0  | Alignment errors:    0  | Bus overruns:        0
Xon:                 0  | Xoff:                0  | Jumbo:            8339k
TRANSMIT
Frames/second:    3748  | Bytes/second:      123m | Errors/minute:       0
Discards/minute:     0  | Total frames:     8140k | Total bytes:     62385m
Total errors:        0  | Total discards:      0  | Multi/broadcast:  1213
Queue overflows:     0  | No buffers:          0  | Max collisions:      0
Single collision:    0  | Multi collisions:    0  | Late collisions:     0
Xon:                 0  | Xoff:                0  | Jumbo:            2413k
LINK_INFO
Current state:       up | Up to downs:         2  | Speed:            1000m
Duplex:            full | Flowcontrol:       none

 

по интерфейсу e0a трафик практически не отправляется

Данные со свича (свич усредняет данные за период в несколько минут, потому утилизация лишь 80%, а не почти 100%)

Status and Counters - Port Utilization

                                 Rx                           Tx
Port      Mode     | --------------------------- | ---------------------------
                   | Kbits/sec   Pkts/sec  Util  | Kbits/sec  Pkts/sec   Util
-------- --------- + ---------- ---------- ----- + ---------- ---------- -----

контроллер

1/11-Trk10 1000FDx   | 5000       0          00.50 | 23088      7591       02.30
1/12-Trk10 1000FDx   | 814232     12453      81.42 | 19576      3979       01.95
2/11-Trk10 1000FDx   | 810920     12276      81.09 | 20528      3938       02.05
2/12-Trk10 1000FDx   | 811232     12280      81.12 | 23024      7596       02.30

сервер
1/17-Trk22 1000FDx   | 23000      7594       02.30 | 810848     12275      81.08
1/18-Trk22 1000FDx   | 23072      7592       02.30 | 410320     6242       41.03
2/17-Trk22 1000FDx   | 19504      3982       01.95 | 408952     6235       40.89

2/18-Trk22 1000FDx   | 20544      3940       02.05 | 811184     12281      81.11

 

Выделенные жирным цифры соответствуют загрузке линий контроллера и сервера соответственно. Подчеркнуто отсутствие утилизации одного из портов контроллера. При этом видно, что 2 датастора делят один линк контроллера.

 

При запуске генерации линейной записи на всех 4 VM и соответственно 4 nfs cтораджах балансировка трафика от netapp не зависит, поэтому картина ожидаемая.

 

Получается, что NetApp при агрегации каналов с балансировкой по IP использует не все доступные линии, как должно быть по теории, а только 3 из 4-х. При этом все остальные участники (свич и esxi) балансируют правильно по всем 4-м линиям. Трафик 2-х датасторов от нетапа до свича идет в одном линке, а от свича до esxi уже по двум.

Аналогичную картину наблюдаю при работе по протоколу iSCSI. Один из 4-х линков NetApp на исходящую связь практически незагружен (5-10 пакетов за 10 секунд). Проверял на втором контроллере и другом сервере ситуация аналогичная.

 

Собственно вопросы:

  • с чем связано такое поведение системы
  • нормально ли это
  • можно ли что-нибудь сделать для равномерного распределения нагрузки

 

Если нельзя, то хочется понимать как работает балансировка,  для того, чтобы настроить систему таким образом, чтобы датасторы не делили линию между собой в нормальной ситуации. Пока получается, что при настройке по бестпрактикс нет уверенности, что одна группа VM с одного датастора не будет влиять на производительность доступа к дискам группы VM с другого датастора.

 

UPDATE:

 

Проблема решена, ip подобраны.

 

На некоторых виртуальных машинах бывает нагрузка, которая по характеру близка к линейной записи/чтению и упирается она в канал. Поэтому хочется быть уверенным в том, что эта нагрузка не попадет в один канал с продуктивной нагрузкой, для которой важна латентность канала.

 

Поэтому исходные цели можно сформулировать так:

  • один nfs экспорт должен быть подключен ко всем хостам vmware esxi по одинаковому ip адресу для того, чтобы vmware воспринимала его как один datastorage, а не как разные (для iSCSI такого требования нет, для каждого сервера можно указывать разные ip таргетов, WWN у них будет одинаковый)
  • трафик (входящий и исходящий) от одного сервера до разных datastorage должен идти по разным линкам сервера и netapp
  • трафик (входящий и исходящий) от разных серверов до одного datastorage должен идти по разным линкам netapp

 

Экспериментальным путем получается слишком долго. Поэтому вариант с перебором, в принципе логичен. Именно его я и попробовал. Крупная трудность, в том, что алгоритм использует побитовые сдвиги над знаковым 32битным целым и операции сложения над ними же (переполненния отбрасываются). Поскольку скриптовые языки нынче слабо ориентированы на фиксированную битность чисел, то добиться нормального расчета на python не удалось. Пришлось написать на C маленькую программу расчета по всему диапазону, а потом использовать результаты в переборе.

 

Еще ньюанс... NetApp нумерует интерфейсы в vif не в алфавитном порядке, а в порядке добавления.

Например, если vif создан такой командой "ifgrp create lacp vif1 -b ip e0d e0b e0c e0a", то e0d будет 0-ым интерфейсом, e0b - 1, e0a - 3.

 

Ниже даны варианты выбора ip адресов netapp при условии наличия 3-х серверов (с ip адресами заканчивающимися на 21, 22 и 23 и количеством интерфейсов к системе хранения 3, 4 и 4 соответственно).

Расчет делался для двух сетей ХХ.YY.52.ZZ/24 и ХХ.YY.53.ZZ/24. Подбирались ip адреса для netapp, удовлетворяющие вышеописанным условиям.

 

Как пользоваться табличкой....

При обмене трафиком между сервером c IP ХХ.YY.52.22 и алиасом NetApp ХХ.YY.52.35 трафик:

  • от NetApp до свича (стоблец NetApp Out, 22) пойдет по интерфейсу с номером 2 по нумерации NetApp
  • от свича до NetApp (стоблец NetApp In, 22) пойдет по интерфейсу с номером 1 по нумерации свича
  • от свича до сервера и от сервера до свича (стоблец Server InOut, 22) пойдет по порту 1 в нумерации сервера и свича соответственно (не факт, что считают они одинаково)

 

Видно, что для каждого сервера трафик с разными алиасами на одной голове будет идти по разным интерфейсам. Аналогично трафик с разных серверов на один IP NetApp пойдет по разным интерфейсам.

 

---------------------------------------------------------------------------------------

|                         Filer |      NetApp Out |       NetApp In |    Server InOut |

---------------------------------------------------------------------------------------

|       name |      IP |        |  21 |  22 |  23 |  21 |  22 |  23 |  21 |  22 |  23 |

---------------------------------------------------------------------------------------

|            |         | if cnt |   3 |   4 |   4 |   3 |   4 |   4 |   3 |   4 |   4 |

=======================================================================================

|    filer_a |   52.35 |      4 |   0 |   2 |   3 |   2 |   1 |   0 |   0 |   1 |   0 |

|    filer_a |   52.74 |      4 |   3 |   1 |   0 |   3 |   0 |   1 |   2 |   0 |   1 |

|    filer_a |  52.144 |      4 |   2 |   0 |   1 |   1 |   2 |   3 |   1 |   2 |   3 |

|    filer_a |  52.161 |      4 |   1 |   3 |   2 |   0 |   3 |   2 |   0 |   3 |   2 |

---------------------------------------------------------------------------------------

|    filer_b |   52.46 |      4 |   0 |   3 |   1 |   3 |   0 |   1 |   2 |   0 |   1 |

|    filer_b |   52.65 |      4 |   1 |   2 |   0 |   0 |   3 |   2 |   0 |   3 |   2 |

|    filer_b |   52.71 |      4 |   2 |   0 |   3 |   2 |   1 |   0 |   1 |   1 |   0 |

|    filer_b |  52.176 |      4 |   3 |   1 |   2 |   1 |   2 |   3 |   0 |   2 |   3 |

---------------------------------------------------------------------------------------

 

---------------------------------------------------------------------------------------

|                         Filer |      NetApp Out |       NetApp In |    Server InOut |

---------------------------------------------------------------------------------------

|       name |      IP |        |  21 |  22 |  23 |  21 |  22 |  23 |  21 |  22 |  23 |

---------------------------------------------------------------------------------------

|            |         | if cnt |   3 |   4 |   4 |   3 |   4 |   4 |   3 |   4 |   4 |

=======================================================================================

|    filer_a |   53.32 |      4 |   0 |   3 |   2 |   1 |   2 |   3 |   2 |   2 |   3 |

|    filer_a |   53.94 |      4 |   2 |   1 |   0 |   3 |   0 |   1 |   0 |   0 |   1 |

|    filer_a |   53.99 |      4 |   1 |   2 |   3 |   2 |   1 |   0 |   1 |   1 |   0 |

|    filer_a |  53.173 |      4 |   3 |   0 |   1 |   0 |   3 |   2 |   1 |   3 |   2 |

---------------------------------------------------------------------------------------

|    filer_b |   53.37 |      4 |   3 |   2 |   0 |   0 |   3 |   2 |   0 |   3 |   2 |

|    filer_b |   53.42 |      4 |   1 |   0 |   2 |   3 |   0 |   1 |   0 |   0 |   1 |

|    filer_b |   53.71 |      4 |   0 |   3 |   1 |   2 |   1 |   0 |   1 |   1 |   0 |

|    filer_b |  53.128 |      4 |   2 |   1 |   3 |   1 |   2 |   3 |   2 |   2 |   3 |

---------------------------------------------------------------------------------------

 

Добавлено решение  Message was edited by: Alexander Gordienko

More Like This

  • Retrieving data ...