Несколько дней назад я написал здесь вопрос, но этот вопрос был неоднозначным. Итак, я попробую переписать вопрос, объяснив все детали.
Мое предыдущее сообщение (закрытое сообщение): http://goo.gl/aJqQ2
Что ты пытаешься сделать?
Я пытаюсь понять, как правильно выбрать MAC-адрес, когда я использую связывание в режиме 2 (Balance XOR - параметр по умолчанию layer2).
Работаю со склейкой драйверов. Пытаюсь разобраться в работе всех режимов (Mode 0, 1, 2, 3, 4, 5 и 6). Я понимаю, как работают все режимы, кроме режима 2 (баланс-xor) и 4 (802.3ad). Потому что опция xmit_hash_policy непонятна!
Мой главный вопрос: как я могу выбрать активное ведомое устройство или другое устройство для отправки трафика от однорангового узла к другому узлу?
Теперь я подробно опишу свои сомнения:
В моей частной лаборатории у меня есть 2 компьютера (ПК1 и ПК2, работающие под управлением linux / ubuntu) с 4 сетевыми адаптерами. На каждом компьютере я установил две NIC (сетевые карты).
Mac-адреса на ПК1(bond0):
MAC1(eth1): 62:25:BC:06:4F:A6
MAC2(eth2): 62:25:BC:06:59:E6
Mac-адреса на ПК2(bond0):
MAC4(eth1):62:25:BC:06:5A:1B
MAC3(eth2):62:25:BC:06:59:E9
Итак, когда соединение драйвера загружено, я вижу 3 интерфейса (bond0, eth1 и eth2) на каждом ПК (eth1 и eth2 являются подчиненными). Но моя проблема начинается здесь, потому что я не могу понять, как ядро выбирает интерфейс или другой.
Иногда я замечаю, что весь трафик размещается на одном ведомом (например, с ПК1 на ПК2, весь трафик будет размещен на eth2 ПК2 {MAC = 62:25:BC:06:59:E9} от eth1 ПК1{MAC = 62:25:BC:06:4F:A6}). Таким образом, следуя приведенному выше примеру, если я отключу eth1 на ПК2, трафик будет отправляться, даже если интерфейс отключен.
Не имеет значения, включен ли интерфейс eth1 на ПК2.
Это ожидаемое поведение. Но, какой политике я должен следовать, чтобы правильно выбрать MAC-адрес (eth1 или eth2)? Почему был выбран eth2 на pc2? А почему eth1 на pc2 не был выбран? Я пытаюсь сказать: как я могу узнать, какой интерфейс я использую для отправки трафика с ПК1 на ПК2?
У меня есть формула:
(source MAC XOR destination MAC) modulo slave count
(Эта формула была извлечена из файла bonding.txt - см. Цитату ниже, в конце)
И я знаю хеш-функцию (хочу поблагодарить пользователя @Mark Wagner)
/ * * Хеш для устройства вывода на основе данных уровня 2 * / static int bond_xmit_hash_policy_l2 (struct sk_buff * skb, int count) {struct ethhdr * data = (struct ethhdr *) skb-> data;
if (skb_headlen(skb) >= offsetof(struct ethhdr, h_proto)) return (data->h_dest[5] ^ data->h_source[5]) % count; return 0; }
Согласно приведенному выше примеру (я отправляю трафик с ПК1 на ПК2, используя eth1 на ПК1 и eth2 на ПК2). Таким образом, мои MAC-адреса:
eth1 : 62:25:BC:06:4F:A6 (PC1)
eth2 : 62:25:BC:06:59:E9 (PC2)
Итак, как я могу определить, какой MAC-адрес я должен использовать на ПК2? Почему взял eth2 а не eth1?
Пользователь @Mark Wagner пытался мне помочь и написал следующее объяснение:
Фактическая хеш-функция:
/ * * Хеш для устройства вывода на основе данных уровня 2 * / static int bond_xmit_hash_policy_l2 (struct sk_buff * skb, int count) {struct ethhdr * data = (struct ethhdr *) skb-> data;
if (skb_headlen(skb) >= offsetof(struct ethhdr, h_proto))
return (data->h_dest[5] ^ data->h_source[5]) % count;
return 0;
}
Где h_dest и h_source - это MAC-адреса. Принимая значения по умолчанию, MAC-адрес ваших облигаций - PC1: 62: 25: BC: 06: 4F: A6 и PC2: 62: 25: BC: 06: 5A: 1B. count = 2. Таким образом, хеш-функция возвращает:
0xA6 ^ 0x5A% 2 = 0
Но я не понимаю, как вычислить функцию xor. Может ли кто-нибудь объяснить мне, как это рассчитать?
Спасибо!
**** Приложение:
Формула из файла bonding.txt
слой2
Uses XOR of hardware MAC addresses to generate the hash. The formula is (source MAC XOR destination MAC) modulo slave count This algorithm will place all traffic to a particular network peer on the same slave. This algorithm is 802.3ad compliant.
Таблица истинности XOR: http://www.tomshardware.com/reviews/safer-6-raid-controllers,1199-2.html
Позвольте мне попытаться упростить это для вас. Глядя на xmit_hash_policy, подумайте:
Затем подумайте «один сеанс для каждого слоя». Пример:
Перефразируй:
Обычно, когда вы общаетесь между двумя узлами, у вас есть один MAC и один IP. Таким образом, вы всегда будете видеть только один используемый интерфейс.
Допустим, вы хотите увеличить пропускную способность между двумя серверами с помощью 1GbE. Каждый сервер связан с использованием 4 сетевых адаптеров и одного связанного интерфейса. Этот связанный интерфейс, скажем bond0, имеет один IP и один MAC. В этом сценарии максимальная скорость между двумя серверами составляет 120 МБ / с.
Затем вы добавляете вспомогательный интерфейс. По сути, это виртуальный интерфейс, который дает вам другой IP-адрес. Это приводит к появлению двух IP-адресов на одном и том же связанном интерфейсе. В linux у вас будут, например, bond0 и bond0: 1 в зависимости от того, как вы его настроили.
Если вы «хешируете» на уровне 2, то несколько IP вам ничего не дадут. У вас все еще есть один MAC-адрес источника и один MAC-адрес назначения. Однако, если вы хэшируете на уровне 3, драйвер теперь, более чем вероятно, сбалансирует вашу передачу.
Если у вас есть многопоточное приложение, использующее несколько портов, скажем, TCP-порты, тогда вам нужно хешировать на уровне 4, что еще больше уравновесит нагрузку.
Вы можете проиллюстрировать это с помощью такого инструмента, как netperf. В каждом сценарии вы можете запустить netperf, используя несколько IP-адресов или несколько портов, и вы увидите, что трафик сбалансирован для нескольких портов.
Однако помните, что это только передача. Прием контролируется переключателем. Cisco позволяет настраивать политику хеширования. Переключатели нижнего конца позволяют выполнять уровни 2 и 3, а более высокие - уровни 2, 3 и 4.
Сценарий:
У вас есть сервер резервного копирования, и вы отправляете данные на устройство резервного копирования NAS. Вы используете режим 4 с xmit_hash_policy = layer3 + 4 на резервном сервере и имеете 4 сетевых адаптера 1GbE в связке. Ваше программное обеспечение резервного копирования настроено для отправки данных на IP-адрес устройства резервного копирования, но делает это через несколько портов TCP с несколькими потоками.
С этой конфигурацией данные будут отправлены на все интерфейсы, если у вас достаточно потоков для балансировки. Как он определяет, что куда идет? Я думаю, у вас есть ответ на этот вопрос, но я не буду делать вид, что понимаю, как это сделать. Я знаю только по опыту.
Допустим, теперь у вас есть возможность передавать данные со скоростью 120 МБ / с * 4 (120 МБ / с на интерфейс 1GbE). Но теперь данные попадают в коммутатор, и коммутатор имеет канал etherchannel (группа агрегации), который настроен с политикой хеширования на уровне 3. (в Cisco это может быть src-ip, dst-ip или src-dst-ip). В этом примере мы выберем src-dst-ip. Итак, теперь коммутатор выполняет хеширование на основе IP-адресов источника и назначения, которые всегда одинаковы, и поэтому он всегда будет выбирать только один порт назначения на коммутаторе.
Таким образом, хотя вы можете передавать со скоростью 450+ МБ / с, цель может получать только со скоростью 120 МБ / с.
Если коммутатор может хешировать на уровне 4 (Cisco будет src-port, dst-port или src-dst-port), то теперь у вас есть возможность передавать эти данные с резервного сервера на устройство, используя все 4 порта. Это предполагает, что резервное устройство также подключено.
Но что, если у вас нет дорогого коммутатора Cisco и вы не можете хэшировать на уровне 4? Вы можете создать дополнительные IP-адреса! Затем вы настраиваете свой сервер резервного копирования для выполнения заданий с использованием 4 разных IP-адресов, и он будет сбалансирован, поскольку коммутатор будет хешировать на основе IP-адресов источника и назначения.
У других производителей коммутаторов есть свои собственные алгоритмы хеширования, которые обычно основаны на сочетании IP и MAC (уровни 2 и 3). В прошлом мне приходилось создавать статические записи arp для таких коммутаторов, чтобы было как несколько IP-адресов, так и несколько MAC-адресов.
Надеюсь, это поможет вам лучше понять, как работает xmit_hash_policy, по крайней мере, на практике.