Dell Unity. Изменение алгоритма балансировки нагрузки магистрали LACP или связки (исправляется Dell)
Summary: Трафик протокола управления агрегированием каналов (LACP) сбалансирован для записи в процессоры СХД Unity по магистрали или связке LACP, но неравномерно сбалансирован при отправке ответов на запросы на чтение. ...
Symptoms
При определенных сетевых условиях и средах алгоритм по умолчанию может использовать один интерфейс.
Примеры:
Если исходный MAC-адрес один и тот же (например, при использовании маршрутизатора), MAC-адрес всегда будет одним и тем же, а порт, используемый для передачи, всегда будет одним и тем же.
Кроме того, в особых обстоятельствах разные MAC также могут привести к одному и тому же значению.
Например, если MAC-адреса всегда заканчиваются четным числом (0,2,4,6,8,A,C или E) и в магистрали LACP или связке имеется два порта, то при вычислении хэша трафик будет каждый раз направляться через один и тот же порт.
Магистральные каналы или связи LACP показывают, что трафик не сбалансирован и используется один интерфейс, а не все интерфейсы равномерно.
Это можно проверить в производственной сети (с помощью системных администраторов сетевого коммутатора) или просмотрев графическое изображение экрана сети в Unisphere в разделе ПРОИЗВОДИТЕЛЬНОСТЬ СИСТЕМЫ>.
netstat -i' в оболочке сервиса.
Cause
Протокол LACP в Unity использует уровень 2 в качестве xmit_hash_policy по умолчанию.
Использование уровня 2+3 в качестве «xmit_hash_policy» предназначено для обеспечения более сбалансированного распределения трафика, чем только уровень 2, особенно в средах, где для достижения большинства пунктов назначения требуется устройство шлюза уровня 3.
Справка: https://www.kernel.org/doc/Documentation/networking/bonding.txt
Layer2 использует XOR MAC-адресов оборудования и поле идентификатора типа пакета для создания хэша.
Формула выглядит следующим образом:
hash = source MAC XOR destination MAC XOR packet type ID slave number = hash modulo slave count.
Layer2+3 использует комбинацию информации протоколов layer2 и layer3 для создания хэша.
Хэш генерируется с использованием комбинации XOR MAC-адресов оборудования и IP-адресов.
Формула выглядит следующим образом:
hash = source MAC XOR destination MAC XOR packet type ID hash = hash XOR source IP XOR destination IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) And then hash is reduced modulo slave count.
Уровни 2 и 2+3 совместимы со стандартом 802.3ad.
Resolution
Для Unity OE Code 4.3 и более поздних версий:
Измените параметр xmit_hash_policy с помощью svc_network_bond команда.
Семейство Dell Unity™ версии 4.3: Технические указания к сервисным командам , стр. 74.
Употребление:
svc_network_bond [-h|--help] -d <device> {-s -o <option> -v <value>} {-g [-o <option>]}
Синтаксис будет аналогичен приведенному ниже примеру:
service@(none) spb:~> svc_network_bond -s -d bond23 -o xmit_hash_policy -v 2
Допустимые значения для xmit_hash_policy ар:
0 или уровень 2 Значение
по умолчанию Этот параметр использует XOR аппаратных MAC-адресов для создания хэша.
1 или layer3+4 Для создания хэша используется информация протокола верхнего уровня (если доступна).
Это позволяет трафику к определенному одноранговому узлу сети охватывать несколько ведомых устройств, хотя одно соединение не будет охватывать несколько ведомых устройств.
2 или layer2+3 Использует комбинацию информации протоколов уровней 2 и 3 для создания хэша. Алгоритм Mode 2 или Layer2+3 совместим со стандартом 802.3ad.
Для Unity OE Code 4.2.3.9670635 и более ранних версий:
Обратитесь в службу поддержки клиентов Dell и приведите номер этой статьи базы знаний.
Для Unity OE Code 5.3.x или выше
Для внесения изменений не требуется Service Shell, и перезагрузка не требуется.
Ниже приведен пример настройки массива Unity в xmit_hash_policy нашей лаборатории.
Для этого массива Unity настроена LACP-магистраль, известная как bond22.
Подключитесь по SSH к массиву Unity с помощью сервисной учетной записи.
Сначала проверьте, какое значение установлено xmit_hash_policy.
# svc_network_bond --get --device bond22 -o xmit_hash_policy INFO: Selected device: bond22 INFO: Option to show: xmit_hash_policy INFO: Execution code: 0 xmit_hash_policy=0 #
Затем установите xmit_hash_policy на 2
# svc_network_bond --set --device bond22 -o xmit_hash_policy -v 2 INFO: Selected device: bond22 INFO: Option to modify: xmit_hash_policy INFO: Requested value: 2 WARNING: Do you want to proceed? [yes/no]: yes <<<<<< sometimes y works and sometimes it fails on the first attempts. Retry then. INFO: Execution code: 0 INFO: Option 'xmit_hash_policy' has been successfully changed. #
# svc_network_bond --get --device bond22 -o xmit_hash_policy INFO: Selected device: bond22 INFO: Option to show: xmit_hash_policy INFO: Execution code: 0 xmit_hash_policy=2 #
Additional Information
netstat и arp Требуется включить Service Shell.
Пример 'netstat -i' Вывод, который показывает элементы связки и может быть использован для определения того, хешируется ли трафик.
В данном примере bond20 (LACP-связка) состоит из интерфейсов eth20 и eth21.
Обратите внимание на разницу в столбце «TX-OK», где представлен исходящий трафик из Unity.
21:12:03 service@(none) spb:~> netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond20 9000 0 101724658 0 11 0 126087418 0 0 0 BMmRU cmin0 9000 0 14341258 0 0 0 11301712 0 0 0 BMRU eth2 1500 0 0 0 0 0 0 0 0 0 BMU eth3 1500 0 0 0 0 0 0 0 0 0 BMU eth10 1500 0 0 0 0 0 0 0 0 0 BMU eth11 1500 0 0 0 0 0 0 0 0 0 BMU eth12 1500 0 0 0 0 0 0 0 0 0 BMU eth13 1500 0 0 0 0 0 0 0 0 0 BMU eth20 9000 0 52249885 0 1 0 38317 0 0 0 BMsRU eth21 9000 0 49474773 0 10 0 126049101 0 0 0 BMsRU eth22 1500 0 0 0 0 0 0 0 0 0 BMU eth23 1500 0 0 0 0 0 0 0 0 0 BMU eth_int 9000 0 14341055 0 0 0 11301598 0 0 0 BMRU eve_br0 1500 0 16 0 0 0 3656 0 0 0 BMRU lo 65536 0 963282566 0 0 0 963282566 0 0 0 LRU mgmt 1500 0 1405994 0 64 0 360538 0 0 0 BMRU mgmt_vdev 1500 0 356150 0 64 0 326216 0 0 0 BMRU srm 1500 0 135650 0 64 0 5 0 0 0 BMRU vetheve1 1500 0 16 0 0 0 3647 0 0 0 BMRU
Пример вывода команды «arp» в оболочке службы, который показывает MAC-адреса (HWaddress) для каждого IP-адреса.
Они должны быть разными, чтобы протокол LACP точно распределял нагрузку трафика между несколькими физическими портами.
Существует несколько интерфейсов, которые необходимо отфильтровать по используемому интерфейсу.
Используется,
'ip addr' Чтобы найти значок «Iface», который назначается IP-адресу, который вы хотите исследовать.
19:23:33 service@(none) spa:~> arp Address HWtype HWaddress Flags Mask Iface 10.98.25.61 ether 00:25:b5:02:01:fc C bond20 10.98.25.60 ether 00:25:b5:02:00:1c C bond20 10.98.25.70 ether 00:25:b5:02:00:dc C bond20 10.98.25.63 ether 00:25:b5:02:01:8c C bond20 10.98.25.65 ether 00:25:b5:02:01:6c C bond20 10.98.25.62 ether 00:25:b5:02:01:dc C bond20 10.98.25.64 ether 00:25:b5:02:01:9c C bond20 10.98.25.67 ether 00:25:b5:02:01:0c C bond20 10.98.25.66 ether 00:25:b5:02:01:7c C bond20 10.98.25.59 ether 00:25:b5:02:00:0c C bond20 peer ether 8e:92:80:4d:2d:02 C eth_int 10.98.25.69 ether 00:25:b5:02:00:fc C bond20 10.98.25.1 ether 00:08:e3:ff:fd:90 C bond20 10.98.25.68 ether 00:25:b5:02:01:1c C bond20