802.3ad, EtherChannel и прочие....

А я правильно понимаю, что все виды агрегирования двух (и более) Ethernet-ов в один логический линк - они распределяют трафик по отдельным линкам исходя из адресов (MAC или IP) конкретного пакета?

То бишь стандартов я не читал, естественно, но читал википедию и читал интеловский текст про teaming, в обоих местах написано примерно это.

Никаких стандартных способов раскидать по двум линкам пакеты от одного TCP-соединения нету?

А счастье было так близко.....

P.S. Нет, я знаю что у FreeBSD-шного lagg есть round-robin, проблема в том что у меня с другой стороны работают или LACP или EtherChannel, а имеющийся там же LoadBalance работает как-то удивительно.... (это Realtek Ethernet Teaming, если интересно). Но похоже, даже если интеловскими средствами пользоваться (поменять сетевую карту и так далее...), которые более человечные, запихать один TCP-коннект в две трубы - не выйдет.

Comments

А разве аггрегирование -- это не 801.11ap? (Или я что-то с чем-то из прошлого века путаю?)

Не, ap - это "Backplane Ethernet (1 and 10 Gbit/s (125 and 1,250 MB/s) over printed circuit boards)"

http://en.wikipedia.org/wiki/IEEE_802.3

Никаких стандартных способов раскидать по двум линкам пакеты от одного TCP-соединения нету?

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

Ну теорию я понимаю. Но, казалось бы, производитель железа (ну тот же Intel) может попытаться сделать усилие по поддержанию порядка. Ну там тегировать пакеты или еще как, опять же если tcp checksum считается аппаратно, то значит в tcp заголовки карта умеет лазить.

Для всяких схем с репликацией (где поток данных строго один), казалось бы, должно быть очень востребованно.

С другой стороны, 10G уже стоит $500 за карту, подешевеют еще вдвое и можно брать. Ну и USB3 тоже вот есть :)

Ну теорию я понимаю. Но, казалось бы, производитель железа (ну тот же Intel) может попытаться сделать усилие по поддержанию порядка. Ну там тегировать пакеты или еще как, опять же если tcp checksum считается аппаратно, то значит в tcp заголовки карта умеет лазить.

а с другой стороны агрегации кто будет востанавливать порядок? хранить, задерживать и накапливать очередь пакетов, прилетевших поперед задержавшегося? интел для свичей драйвера напишет?

С другой стороны, 10G уже стоит $500 за карту, подешевеют еще вдвое и можно брать.
бери медные на плате -- оно уже должно быть по 100 за пару.

Ну и USB3 тоже вот есть :)
текущая мода -- 100G

Казалось бы - на картах есть буфера. Поэтому можно делать "максимум возможного" - пока в буфере есть место, придерживаем пакет пришедший вне порядка, кончилось место - ну значит не судьба. В обычном интернете тоже может out of order быть.

Что касается 100 за пару - не вижу я таких. Гугл находит в 10 раз дороже...

Казалось бы - на картах есть буфера.
причем тут карты? я тебе про свичи талдычу

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

Что касается 100 за пару - не вижу я таких. Гугл находит в 10 раз дороже...
я же сказал -- онбордные.
а насчет в 10 -- гугл сходу показывает 700 за X520-t2, но он не онбордный.

странно, мне казалось что у интелов они на материнке уже должны быть.

LOM-чипы-то уже давно анонсированны и именно по цене 100 за два порта.
вопрос кто первый на мать припаяет.

Что мне до свитчей, если меня интересует end-to-end. Уж на концах, казалось бы, можно потерпеть и порядок немного восстановить.

У солярки есть такая фича (IPMP), но я реализации для винды не нашел. Я то хочу быстро-быстро к самбе ходить, 1G я насыщаю без проблем, но на рабочей станции есть второй порт, на сервере - тоже.

А онбордные - да, наверное в серверах появятся скоро. Но мне они для дома низачем.

iSCSI умеет ходить по нескольким линкам сразу, я экспериментировал -- с винды на FreeBSD работало и эффект был виден. Меня не устраивает для дома архитектура iSCSI -- том не разделить между несколькими клиентами -- но может у тебя не так?

А iSCSI виндовый умеет ходить по нескольким линкам к одной target? А как?

Ну, там есть такая фича. Я на своей XP ставил доп. пакет (но от MS, не 3rd-party) и там специально завявлен multipath, и в advanced-настройках можно добавлять новые points. Но подробностей я не помню, это я больше года назад пробовал, а сейчас уже настроек не сохранилось и, главное, target деконфигурирован.
А вот target был вроде не из портов, а какой-то патченный, его какой-то японец во FreeBSD'шных списках рассылки анонсировал

вот эти ребята?

Вот этот японец: http://old.nabble.com/Tester-wanted-for-multipath-failover-iSCSI-target-...
?

Ага, похоже, очень похоже. И дата с моими воспоминаниями совпадает.

Кстати, а какая винда и на каком железе у тебя упирается по самбе в гигабит?
Я как ни бьюсь -- не может у меня винда больше 45-50MiB/s считать с самбы, пишет 75-80. iperf показывает с винды на сервер и обратно 950-960Mbit/s (при больших окнах, но я вроде вовсю да винде их прописал), т.е. дело не в тупой карточке (хотя на винде таки тупая -- Atheros гигабитный, но ipref-то может!)...

Я то хочу быстро-быстро к самбе ходить, 1G я насыщаю без проблем

а можно детали? какой сервер, какая нагрузка, ...

я думал, что сегодня 1G для файл-сервера достаточно в 95% случаев

Семерка. Железо хорошее :)
112-120 Mb/sec на чтение, сотка на запись.
Jumbo frames очень помогают. Остальное никак не тюнил на винде, на freebsd - обычные настройки: окна побольше и все такое.

Правда я сейчас перевесил на юниксе с em0 на igb0 и вроде стало чуть помедленнее, но систематически проблему никак не изучал.

Ну, у меня тут Q9650, 8GiB RAM... Сервер E4500, но там процессор на 85% IDLE при передаче, не думаю что это что-то ограничивает.

Только LOM от Atheros на клиенте. Jumbo Не помогают вообще -- процентов на 5.

Свитч -- HP ProCurve, к нему претензий нет...

Ну и локально на сервере в /dev/null читается со скоростью 195-200MiB/s, так что затык явно не тут.

Надо, надо Win7 поставить. Я уже даже лицензионную купил -- вон коробка стоит. А руки всё не доходят.

Ну у меня было 50-60Mb/sec до недавнего времени и я был доволен. А потом тома рейдовые перебирал, терабайты туда-сюда и занялся вплотную. Выяснил следущее

1) Сервер упирался в процессор. У меня был Core2 на 1.6 (1.83 даунклоченый летом, а то жарко было), оверклок сильно помог, в результате я его поменял на 2.93 и до 3.5 разогнал (попутно пришлось и корпус поменять, в старом перегревалось).
В результате "меньше 100" Mb/sec на ZFS стало 180 на запись и 280 на чтение (меньше 100 было на трех дисках, сейчас их, правда, 4).

2) Far - очень плохая тулза для копирования по сети. Только Windows Explorer.

3) После шагов 1-2 - стало в районе 75-80Mb/sec, перешел на jumbo frames и из какого-то форума не думая взял комплект sysctl (оба - одновременно, отдельно эффект не изучал) - стало 95-100 на запись и 112-120 на чтение. На чем я и успокоился.

1) Это видно по какой-то статистике? всякие sys & interrupt times у меня там смешные. Но нет ZFS.

2) У старого FAR есть плагин который обгоняет эксплорер раза в полтора в моих условиях. Он делает это параллельно через кольцевой буфер. Дефолтовое F5 -- да, работает в 2-3 раза медленней. Именно из-за него я не перехожу на far2.

3) sysctls не покажешь? У меня там тоже пачка, хочу сравнить.

У меня system была ~50% и я думал что ZFS - не многопоточная (что ошибка). Но конкретно для ZFS - поднимаешь частоту горшка - растет скорость чтения одного и того же файла.

Про Far - я знаю этот плагин и его пользую для копирований на диске. Но по сети он быстрее 50-60Mb/sec у меня не разгоняется. Может быть размер чтения неудачный, может еще что.

Да, замена igb0 обратно на em0 обратно - ничего не дала.

Пачки sysctl:
1) По следам рассказа Сысоева о видеосервере:
kern.ipc.maxsockets=2048000
kern.ipc.somaxconn=4096
kern.maxfiles=204800
kern.maxfilesperproc=200000
kern.ipc.nmbclusters=204800
kern.ipc.nmbjumbop=192000
net.inet.tcp.recvspace=131072
net.inet.tcp.recvbuf_auto=1
net.inet.tcp.recvbuf_inc=131072
net.inet.tcp.recvbuf_max=1048576
net.inet.tcp.sendspace=131072
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.sendbuf_inc=131072
net.inet.tcp.sendbuf_max=1048576
net.inet.tcp.maxtcptw=102400
net.inet.ip.intr_queue_maxlen=2048

2) Из форума по запросу "samba performance"
kern.ipc.maxsockbuf=2097152
net.inet.tcp.recvspace=262144
net.inet.tcp.sendspace=262144
# mss for jumbo
net.inet.tcp.mssdflt=8800
net.inet.udp.recvspace=65535
net.inet.udp.maxdgram=65535
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535

(mss увеличен из пролетарского самосознания).

Но вот чую фигню какую-то, у меня на прошлой материнке (я сервер домашний целиком заменил, кроме памяти) размер пакетов на em0 получался 16k (при MTU 9000), а сейчас - 8800. Надо еще следствие наводить....

А, да, свитча никакого нет.

А, волшебное место кажется еще вот тут:

smb.conf:
socket options = TCP_NODELAY SO_RCVBUF=655360 SO_SNDBUF=655360

Всё знакомо, да. У меня джамбы ограничены 7K просто Atheros'ом (и ~9K em'ом на сервере)...

А вот ТАКИЕ буфера у самбы (там ниже ты пишешь) -- это шок. Я больше 128K Не пробовал и искал оптимум бинарным поиском от 1024 до 128k -- получилось ~96K...

Впрочем, я так и не нашёл как заставить винду растить окошки дальше 128к -- даже столько оно открывает не всегда, хотя реестр, конечно, пропатчен. Надо, надо таки 7'ку поставить.

Ну там 64к прямо в примере в конфиге. Я на пробу дописал нолик - стало быстрее. Бинарным поиском уже не стал ничего искать.

Так как на чтение оно явно насыщается (только на больших файлах, конечно), а на запись - близко к тому, то дальше я не стал упражняться.

Кстати, для копирования я находил какой-то графический виндовый утиль, который сам играл размерами буферов на первых мегабайтах и находил оптимум, он работал ЧУТЬ быстрее, но был ЧУДОВИЩНО неудобным. И, да, меня, конечно, в первую очередь волнует не копирование, а открытие фотошопом.

И я тут на работе попробовал фотошоп на Win7 при примерно том же железе (по числам рабочий i5-750 который на работе непринципиально быстрее домашнего Q9650, памяти одинаково по 8 гигов, и винты из одного поколения) -- так он гораздо шустрее именно файлами ворочает, даже на внешнем USB-диске...

Меня 10-20% туда-сюда вообще не волнуют, ну только ради прикола.
Но вот 100 (эксплорером) и 50-60 (фаром) - это же полтора-два раза.

iSCSI - посмотрел в конфиг (пример из порта...), ВООБЩЕ НИЧЕГО НЕ ПОНЯЛ, буду изучать....

О да, там всё мутно. Но это -- экспорт "блочного устройства" в любом случае (в терминологии старых юниксов), т.е. надо экспортировать пустой файл и его форматировать на винде в NTFS.

До этого я допер.

А растить его на ходу - никак не получится, правильно?

не то, чтобы я был очень огорчен, но вообще мне концепция одного ведра (ZFS) очень нравится, невозможно сделать больше одной ошибки с capacity planning.

Как я понимаю -- не получается, по крайней мере у тех примитивных target'ов, что есть у нас во FreeBSD... Кстати, солярка вроде как умеет прямо пулы ZFS без создания лишних сущностей в виде фапйлов, забитых нулями, экспортировать... Но не уверен, что всё правильно понял.

Да, солярка это умеет. И по SMB умеет экспортировать, но (в интернете) говорят что глючит и лучше пользоваться самбой.

Но я так и не осилил идею перехода на солярку, под FreeBSD все такое удобное и родное...

+100500
Я же даже раутер себе домой, сильно переплатив (по сравнению со всякими open-wrt capable), взял хоть и в формате soap box, но i386'ой, что бы фряха. Это сейчас -CURRENT на ARM/MIPS громоздят...

Да наверное достаточно.
Просто обидно - ethernet-порты свободные есть, патч-корд - есть, а использовать разумно - не могу.

Может не в тему, но ихмо наверняка должны быть решения этих задач на базе vpn, но конкретно названия не знаю. Конечно будет overhead, но по-идеи должно получиться больше 1Gb

Ну вот я ничего конкретного не нашел. VPN в этом месте странен тем, что там шифрование будет (почти обязательно) т.е. производительность просядет очень сильно....

КСТАТИ! Я идиот, да, сразу бы мог придумать -- конечно всё что угодно PPP-based Умеет мультилинк. PPPoE, L2TP -- всё должно уметь. И шифрования там легко может и не быть.
читать доку на mpd5 на стороне FreeBSD.

Сходу не нашел, чтобы Windows в этом месте умела бы multilink/multipath.

Но буду изучать.

Можно извратиться и поставить в виртуальную машину freebsd. Вот только я не знаю какая у них скорость обмена с хостом (по-идее большая, но вот что на практике).

UPD: Нечто похожее: http://www.dslreports.com/forum/r21725250-Singlelink-MLPPP-on-Windows-wi...

PPTP/L2TP VPN есть галкка Negotiate multi-link for single link connection, т.е. точно как-то можно включить multi-link. Но не видно где.

С другой стороны есть такая тулзень у MS, позволяющая создать сложные настройки VPN и потом их быстро ставить (тот самый disk from your internet-provider) -- я точно не помню, что там было вообще, но там точно было настроек раза в 3 больше чем в интерфейсе самой виныд, включая статик-рауты и прочее, чего в интерфейсе винды НЕТ ВООБЩЕ. Можно посмотреть нет ли там и мультилинка.

А PPTP/L2TP кстати, умеют пакетироваться в jumbo-frame'ы, а не только в стандартные 1500?

Offtopic. Удивительно всё же, до какой степени тесен мир и интернет в частности. :) Привет, Лев, ещё раз. 2:5030/661 ещё жива? ;)

Ну, вообще L2TP работает поверх TCP/UDP -- должен. Кстати, опция эта в винде означает, что можно использовать full MTU мне вот подсказывают...

Нет, около года назад я свернул всю FIDO'шность, когда меня погнали с очередной телефонной линиии. В IP-only ноде не вижу смысла ([jтя несколько последних лет не было телефонных звонков вообще, но это ведь не важно, правда?).

Да и кстати, если задача ускорить только samba с конкретной машиной, можно извратится следующим образом:

На win машине запустить VM с чем-нибудь консольным и лёгким.
Эта VM будет эмулировать samba сервер путём небольшого скрипта.
На стороне NAS'а тоже будет такой скрипт, но он уже будет эмулировать клиента.
Эти скрипты должны уметь общаться по нескольким портам/ip - multilink (нужно разделять на пакеты, и нумеровать их). Соответственно эти скрипты и будут гнать весь трафик по сети.
Вот только надо посмотреть сколько портов нужно для win smb чтобы передать файлы, может придётся скрывать оригинальный samba и т.п.

Тот ещё костыль, но по-идее пишется не так долго и можно оптимизировать конкретно под samba.

А с чего это переупорядочивания не должно быть? TCP на это же и заточен. Я как-то не видел, что бы стек отключал пересборку только потому что пакет пришёл по ehternet. Ведь у стека нет никаких гарантий, что до ethernet'а не было чего-то ещё...
В общем, как-то аргумент ``у нас нарушится порядок'' кажется мне совершенно невалидным.

На больших пакетах и стандартном окне очень легко добиться необходимости дропать.

нет, можно еще:
- не распределять (standby)
- разбросать по адресу порта

да, идеологически некорректно разбрасывать пакеты одной tcp сессии по разным трубам приблудой, сделанной для балансирования _множества_ сессий

Gor
P.S. HP APA можно заставить делать честный round-robin _только_ при общении двух серверов между собой мимо свитчей...
P.P.S. но есть стандартый трюк - поднять на loopback интерфейсе gated - и будет тебе счастье....

Про gated поподробнее, это же что-то такое около bgp-шное, насколько я из прошлого века помню..... Быстро-быстро вращать роутинг?

У меня проблема скорее на виндовой стороне (запись).

у тебя есть сервер. в него воткнуты две карточки. ты имеешь на них два интерфейса - lan0 и lan1 (для примера)
lan0 - 192.168.0.1/24
lan1 - 192.168.1.1/24

зачем-то тебе хочется:
а - отказоустойчивости
б - балансировки нагрузки

ты поднимаешь свой настоящий (внешний серверный) IP на lo1 10.0.0.7/16 и поднимаешь на каждом из серверов gated. на внешних цисках ты занимаешься той же фигней... OSPF

очевидно, что клиентских машин это не касается - у них только одна карточка и одна внешняя сеть - 10.0.x.x/16

Gor
P.S. собственно, идея не моя - а заказчика (в теле письма заменена CU)
-=-
Почему мы отдаем предпочтение OSPF при подключении систем HP-UX и IBM к локальной сети CU:

1. Протокол обеспечивает использование всех существующих физических интерфейсов хоста. Обеспечивается балансировка нагрузки по маршрутам. Обеспечивается доступность хоста при отказах как сетевых адаптеров (кроме последнего), так и всего коммутатора (кроме последнего) .
Все интерфейсы активны. Каждый интерфейс отдельный маршрут. При отсутствии связи по одному из маршрутов, работают оставшиеся, хост не доступен только при отказе всех маршрутов.

2. Все интерфейсы должны находиться в разных подсетях, т.е. мы можем подключить хост к любым коммутаторам.

3. Для приложений создается виртуальный LAN с соответствующим IP адресом. Виртуальный LAN может быть перемещен на любой хост.

4. OSPF протокол динамической маршрутизации, все маршруты строятся автоматически.

5. Пяти летний опыт использования протокола OSPF при эксплуатации сетевой структуры CU показал надежность данного решения, высокую доступность ресурсов при отказах сетевого оборудования и ПО, и удобства при сопровождении сетевого обеспечения.

-=-

OSPF (gated) - это же средство редактирования routing table, правильно. Значит с сервера куда-то (неважно куда) одномоментно будет существовать один маршрут. Понятно что в разные "неважно куда" их может быть несколько и если клиентов много, то даже возможна какая-то балансировка.

Но у меня другая проблема, которая в исходном посте описана. У меня не просто один сервер и один клиент, у меня еще и один TCP-поток, который я хочу пропустить по двум паралелльным гигабитам одновременно.

Правда этот поток - это работа с файловым сервером и multipath iSCSI меня скорее всего вылечит (и виндовый клиент это вроде бы умеет), буду в следущую порцию выходных развлекаться.

я не отследил причинно-следственную связь между "routing table" и "будет существовать один маршрут".
возможно в трактовка слова "одномоментно". для данного пакета - да, все верно.
Gor
P.S. ок. забей на gated. просто пропиши два статических маршрута с одинаковым весом...

BSD en0 - 192.168.0.1 en1 192.168.1.1
win en0 - 192.168.0.2 en1 192.168.1.2

BSD=10.0.0.1
WIN=10.0.0.2

организуй нахождение целевых адресов bind`а (и назначения, и, что не менее важно, источника) только на 10.x адресах. ???? PROFIT

P.P.S. эээ, я не знаю, насколько корректно сделан в BSD таргет. в смысле я видел его корректно сделанным только в железе - и только в netapp. что мы (Hp), что итаки, что ибм настоятельно не рекомендуют MP отличный от агрегирования каналов...

pps относился к iSCSI

Что-то я далек от уверенности, что два маршрута с одинаковым весом сделают мне load balance.
failover - да, будет.

Что касается iscsi и агрегирования - агрегирование имеет ту проблему, что канал в агрегате выбирается по по адресам потока (L2 или L3), то есть для одного потока счастья все еще не будет

А, знакомая проблема. Сам озадачивался, но так и не доделал пока.
Если смотреть теорию, то да, LACP в чистом виде не умеет такого.
К счастью, чисто LACP уже пожалуй давно никто не делает. Как минимум Dlink и Mikrotik умеют распределять на основе src/dst портов.
Скажем, мой "роутерный" Mikrotik (рекомендую, кстати), умеет следующие режимы Bonding'a:

Selects the transmit hash policy to use for slave selection in balance-xor and 802.3ad modes
...
layer-3-and-4 - This policy uses upper layer protocol information, when available, to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves. For fragmented TCP or UDP packets and all other IP protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy. This algorithm is not fully 802.3ad compliant.

А толку то (для моей задачи)
, although a single connection will not span multiple slaves.

Меня интересует, грубо говоря, бэкап ускорить, то есть строго один поток.

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

Меня интересует, грубо говоря, бэкап ускорить, то есть строго один поток

Политика

Я всё равно не пойму, почему нельзя делать обычный(не dual destination) incremental в локальное хранилище, а потом копировать новые файлы скриптом из локального в сетевое хранилище? Ускорение будет раз в сто.

PS:Задания Acronis'а вроде можно и из командной строки запускать

Да не будет раз в сто.

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

1. Вроде VMWare после снапшота создаёт новые файлы дисков, в которые пишет только delta (думаю так далжны делать и другие VM)
2. Также можно делить диски (VMWare может делить по 2gb)

А, да, судя по тому что я вижу - в последних билдах акрониса это самое "едет весь backup set" починили, едет только свежий.

Тогда не знаю :(

>Притом, если я сделаю несколько потоков, то я ничего не ускорю, а только хуже сделаю - медленные SATA-диски линейно пишут неплохо, а рандомно - ужасно.
Несколько это два потока (две сетевухи), полагаю. В таком случае (раз уж скидываться тем более это будет на RAID/ZFS), диски вполне должны выжить. Особенно с ada-драйвером (мы же о FreeBSD говорим?) винтов, поддерживающим NCQ.

Ну сетевух у меня на десктопе стало уже три (ввинтил туда ненужный intel PRO/1000), т.е. могу лить на сервер и три потока по гигабиту (там портов для этого можно расчистить). Правда он столько не прожует.

Но нет, если один поток в 100-110M - то уже небольшое дополнительное шевеление дисками (вроде buildworld в один поток) уже все сильно портит.

Т.е. я буду развлекаться с iscsi, меня для бэкапов это не устроит, понятное дело, а для других задач - вполне, там вроде можно мультилинк.

Вообще - интересно.
Две длинных записи (по 10gb при 2-гиговом arc_max) дали 90Mb/sec в каждом из потоков, сумма сохранилась.
Т.е. по двум интерфейсам вполне можно ходить к двум самбам и даже throughput будет не стыдный.

Но сначала - iscsi

Это при какой технологии bonding'a?

Кстати, чем так хорош iSCSI в реальной жизни?

Да вот говорят MS-овский iscsi умеет Multipath. Я пока не пробовал.

А чем хорош... скорее всего ничем не хорош, samba удобнее и все такое. Но интересно попробовать.

Add new comment