Построение высокопроизводительного файлового сервера (между 2 компьютерами gigabit lan crossover)

Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС.

Модераторы: SLEDopit, Модераторы разделов

rPman
Сообщения: 22
ОС: Ubuntu

Построение высокопроизводительного файлового сервера

Сообщение rPman »

Компьютеры подсоединены напрямую (витая пара) через гигабитные сетевые карты встроенные в материнку (обе nvidia nForce):
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
nVIDIA MCP67/68 - LAN Controller (PHY: Realtek RTL8211/8212)
Наблюдается заметное понижение быстродействия программ, работающих вместо диска с сетевой шарой, причем от 30% до 'в разы'.
С пол года назад практиковал бездисковую станцию linux по nfs (на глазок ощутимая потеря производительности, добавляется лаг при работе с меню kde/gnome).
С клиентом windows делал больше тестов, поднимал на сервере samba, ставил на клиенте windows for unix 3.5 и поднимал nfs шары (почти никакой разницы в производительности, по шустрее линейное копирование), сейчас стоит iSCSI а на сервере LVM (2 stripe блок 64кб) - все равно к примеру игры запускается раза в 4-5 медленней, хотя линейное чтение доходит до 100мбайта/сек.

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

Что служит виной подобного лага? подключение комп-комп (слышал что для дешевых гигабиток какие то проблемы должны быть)? Вообще это нереально на гигабитной сетке сделать высокопроизводительное удаленное хранилище, может я не то сетевое ПО выбрал или протокол IP(вариант с монопольным использованием канала рассматриваем но нежелателен), хотя что в данном случае лучше iSCSI? Может что то можно на linux (gentoo) подкрутить, настройки samba, nfs, ietd, ядра? а может вина и в windows? может так же настройки какие можно найти?
Спасибо сказали:
Аватара пользователя
кодировщик
Сообщения: 974
Статус: зарёган в пятницу 13
ОС: Linux

Re: Построение высокопроизводительного файлового сервера

Сообщение кодировщик »

rPman писал(а):
02.02.2009 11:17
Наблюдается заметное понижение быстродействия программ, работающих вместо диска с сетевой шарой, причем от 30% до 'в разы'.

Например?!
Спасибо сказали:
Аватара пользователя
danger08
Сообщения: 715
ОС: Linux (CentOS, Ubuntu)

Re: Построение высокопроизводительного файлового сервера

Сообщение danger08 »

rPman писал(а):
02.02.2009 11:17
Компьютеры подсоединены напрямую (витая пара) через гигабитные сетевые карты встроенные в материнку (обе nvidia nForce):
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
nVIDIA MCP67/68 - LAN Controller (PHY: Realtek RTL8211/8212)

У меня проблема была с этими картами в CentOS 5.2, при использовании драйвера r8169 (у людей на Убунте было то же самое).
Заменил альтернативным драйвером r1000 (v1.05) и все встало и работает на ура.
Блогосайт - http://www.fateyev.com
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

Re: Построение высокопроизводительного файлового сервера

Сообщение rm_ »

при использовании драйвера r8169 (у людей на Убунте было то же самое).
Заменил альтернативным драйвером r1000 (v1.05)

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

Т.е. потеря производительности именно при операциях нелинейного чтения

Вопрос ("а должно ли быть быстрее") сложный, но полученные результаты в общем-то логике не противоречат...
Просто посчитайте, какая огромная разница в количестве промежуточных программных и аппаратных "слоёв" между прямым доступом к локальному диску, и доступом к диску на другом компьютере.
Посмотрите где-нибудь в настройках, осуществляет ли клиентская операционка кэширование чтения/записи на iSCSI (не отключено ли это).
Включены ли Jumbo-фреймы для соединения. Равен ли их макс. размер, заданный на обоих компьютерах. Последний момент особенно критичен, т.к. Реалтек больше 7200 не умеет, а nForce может и до 9000 (если не "обрезок").
Спасибо сказали:
Аватара пользователя
danger08
Сообщения: 715
ОС: Linux (CentOS, Ubuntu)

Re: Построение высокопроизводительного файлового сервера

Сообщение danger08 »

rm_ писал(а):
02.02.2009 13:59
при использовании драйвера r8169 (у людей на Убунте было то же самое).
Заменил альтернативным драйвером r1000 (v1.05)

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

Баги давно отрепорчены, только народ каждый день сталкивается с такой ситуацией. В будущем, может, что-то изменится, но врядли кого-то заинтересуют эти мега-интегрированные-девайсы, серьезные люди с ними не работают. Сам драйвер r8169 очень хорош для большинства моделей Realtek, только вот со встроенными сетевухами не особенно дружит - это проблема производителей железа с интегрированными сетевухами.

У меня при использовании r8169 были резкие падения пропускной способности при интенсивном сетевом обмене на довольно нагруженном хосте (файлопомойка), Сейчас стоит r1000 и никаких нареканий. Пусть человек попробует r1000, если это решит его проблему - больше ничего не надо.

Заголовок стоит "построение высокопроизводительного файлового сервера", встроенные гигабитки для этого не лучшее решение. Возьмите, например, нормальные карточки Intel, или Realtek на худой конец (только не встроенный :rolleyes: )
Блогосайт - http://www.fateyev.com
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

Re: Построение высокопроизводительного файлового сервера

Сообщение rm_ »

врядли кого-то заинтересуют эти мега-интегрированные-девайсы, серьезные люди с ними не работают

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

Пусть человек попробует r1000, если это решит его проблему - больше ничего не надо.

Как ничего не надо, ещё как надо:
- навсегда отказаться от возможности ставить готовые Убунтовские ядра
- самому сидеть и прикручивать драйвер к ядру, после чего компилить оное из исходников
- иметь эту мороку каждый раз при желании проапгрейдить ядро до свежего релиза.
Это всё очень неудобно. Поэтому правильнее - добиться, чтобы работало "из коробки".

Возьмите, например, нормальные карточки .... только не встроенный

И только не PCI.
Встроенные сетевухи сидят на PCI-E, а у nVidia вообще, на своей особой шине, так что на PCI-картах их обойти не выйдет.

или Realtek на худой конец

Если невстроенный реалтек чем-то лучше встроенного, то это баг, и его надо исправлять. :)
Чип по сути один и тот же, кардинальных различий никаких быть не должно.
Спасибо сказали:
Аватара пользователя
danger08
Сообщения: 715
ОС: Linux (CentOS, Ubuntu)

Re: Построение высокопроизводительного файлового сервера

Сообщение danger08 »

rm_ писал(а):
02.02.2009 15:25
Пусть человек попробует r1000, если это решит его проблему - больше ничего не надо.

Как ничего не надо, ещё как надо:
- навсегда отказаться от возможности ставить готовые Убунтовские ядра
- самому сидеть и прикручивать драйвер к ядру, после чего компилить оное из исходников
- иметь эту мороку каждый раз при желании проапгрейдить ядро до свежего релиза.
Это всё очень неудобно. Поэтому правильнее - добиться, чтобы работало "из коробки".

Проблема с таким девайсами у драйверов "из коробки".. А дел там реально на 5-10 минут:
- установить исходники ядра (чтоб хедеры зацепились при сборке драйвера);
- качнуть r1000_v1.05.tar.bz2 с сайта реалтек, это последняя версия, собирающаяся беспроблемно под последними ядрами;
- собрать модуль по инструкции внутри;
- внести изменения в modprobe.conf, загрузить через modprobe или перезагрузиться.
Если система ставит r8169 обратно, заблэклистить этот модуль.
Пересборки ядра и прочих страшных вещей не требует, даже для ярых бинарных дистрибутивов :rolleyes:

Если невстроенный реалтек чем-то лучше встроенного, то это баг, и его надо исправлять. :)
Чип по сути один и тот же, кардинальных различий никаких быть не должно.

Давно разговоры об этом идут, со временем должны пофиксить. В общем, не переключайтесь (stay tuned :tongue: )
Блогосайт - http://www.fateyev.com
Спасибо сказали:
skor
Сообщения: 419
ОС: RTFM-OS v127.0.0.1

Re: Построение высокопроизводительного файлового сервера

Сообщение skor »

[offtopic]ИМХО слова "высокопроизводительный" и "realtek" рядом не очень хорошо смотрятся.
Есть деньги на всякие SCSI, а на сетевую от Intel`а пожалели[offtopic]
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

Re: Построение высокопроизводительного файлового сервера

Сообщение rm_ »

skor писал(а):
02.02.2009 16:41
[offtopic]ИМХО слова "высокопроизводительный" и "realtek" рядом не очень хорошо смотрятся.
Есть деньги на всякие SCSI, а на сетевую от Intel`а пожалели[offtopic]

Спасибо, повеселили, советую почитать, что такое iSCSI. :)
Про реалтек зерно истины есть, но в отличие от стомегабиток 8139, гигабитные чипы 8169 (и их встраиваемые аналоги) больше не "худшие сетевые чипы планеты", и обладают вполне внушительным набором функций по разгрузке ЦПУ. Другой вопрос, насколько хорошо это реализовано, в том числе и в драйверах.
Спасибо сказали:
rPman
Сообщения: 22
ОС: Ubuntu

Re: Построение высокопроизводительного файлового сервера

Сообщение rPman »

кодировщик писал(а):
02.02.2009 11:34
rPman писал(а):
02.02.2009 11:17
Наблюдается заметное понижение быстродействия программ, работающих вместо диска с сетевой шарой, причем от 30% до 'в разы'.
Например?!
Технические тесты Roadkil's disk speed 2.0: hdd 500гб (wd)/100гб iscsi lvm stripe на 2-ух 320Гб - access time 12.81ms/11.09ms, linear read 52мб-89мб/45мб-73мб, random read для 64к блоков 4.79мб/2.73мб, overal score 787.9/580.7. Игра Mirror's Adge (загрузка любого этапа сразу после запуска) с локального диска 2 'избиения полицейского' :), с iscsi - 8-10, т.е. в 4-5 раз медленнее!

Т.е. потеря производительности именно при операциях нелинейного чтения

Вопрос ("а должно ли быть быстрее") сложный, но полученные результаты в общем-то логике не противоречат...
Просто посчитайте, какая огромная разница в количестве промежуточных программных и аппаратных "слоёв" между прямым доступом к локальному диску, и доступом к диску на другом компьютере.
Посмотрите где-нибудь в настройках, осуществляет ли клиентская операционка кэширование чтения/записи на iSCSI (не отключено ли это).
Включены ли Jumbo-фреймы для соединения. Равен ли их макс. размер, заданный на обоих компьютерах. Последний момент особенно критичен, т.к. Реалтек больше 7200 не умеет, а nForce может и до 9000 (если не "обрезок").
mtu менял от 1500 до 7200 (кстати, как это они могут быть разными на обоих концах? подключение кросовер, и как его менять под windows? :)), разница в технических тестах на грани погрешности, на практике никакой. Кэш на на запись в iscsi включен (кстати линейная запись iscsi - ntfs вообще медленная, в районе 12мб/сек! с samba - до 80мб/сек доходило, хотя это кстати логично...), по утилите ethtool фуллдуплекс включен, tso выключен (и не включается, как и др. фишки по -K).
Про уменьшение прослоек - ну нужно будет попробовать AoE (но если он может только все устройство целиком - мне не подходит, а если любое блочное устройство - то не уменьшит количество прослоек, да и поддерживается ли win.. хз)
Я конечно понимаю хотеть не вредно, но мало ли, хотелось и бездисковую (бесшумную) станцию и без серъезных потерь производительности и денежных :) средств. Может есть какие средства не IP-based? наверняка причиной тормозов именно разные tcp-stack windows. К тому же у меня были надежды использовать выделенное хранилище на linux (со всеми плюшками) для windows серверов (на которых плюшками и не пахнет), просто прежде чем закупать оборудование необходимо хотябы оценить порядок затрат.

rm_ писал(а):
02.02.2009 13:59
при использовании драйвера r8169 (у людей на Убунте было то же самое).
Заменил альтернативным драйвером r1000 (v1.05)

Надо пользоваться стандартным драйвером, тем более что для этой карты он давно входит в состав ядра.
Если с ним что-то не работает, репортить баги.
Задействованы модули 8139too и 8139cp (в комп вставлена еще 100-мбит сетевуха RTL-8139/8139C/8139C+ (rev 10)), какой модуль к какой сетевухе сейчас посмотреть не могу, серер работает давно и dmesg уже не показывает сообщения в с начала загрузки, а перегружать его пока не хочу.
Спасибо сказали:
Аватара пользователя
Ленивая Бестолочь
Бывший модератор
Сообщения: 2760
ОС: Debian; gentoo

Re: Построение высокопроизводительного файлового сервера

Сообщение Ленивая Бестолочь »

какой модуль к какой сетевухе сейчас посмотреть не могу

посмотреть какой модуль к чему:

Код: Выделить всё

 ls -l /sys/bus/pci/devices/*/driver
Солнце садилось в море, а люди с неоконченным высшим образованием выбегали оттуда, думая, что море закипит.
Спасибо сказали:
Аватара пользователя
danger08
Сообщения: 715
ОС: Linux (CentOS, Ubuntu)

Re: Построение высокопроизводительного файлового сервера

Сообщение danger08 »

rPman писал(а):
04.02.2009 10:37
Задействованы модули 8139too и 8139cp (в комп вставлена еще 100-мбит сетевуха RTL-8139/8139C/8139C+ (rev 10)), какой модуль к какой сетевухе сейчас посмотреть не могу, серер работает давно и dmesg уже не показывает сообщения в с начала загрузки, а перегружать его пока не хочу.

8139too и 8139cp - это ваше 100мбитное хозяйство (Realtek 8139). Они не используются для гигабиток.
Насчет dmesg - смотрите /var/log/dmesg, насчет модуля - можно посмотреть в /sys/bus/pci/devices/ или через lshal (параметр info.linux.driver для устройства)
Блогосайт - http://www.fateyev.com
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

Re: Построение высокопроизводительного файлового сервера

Сообщение rm_ »

Технические тесты Roadkil's disk speed 2.0: hdd 500гб (wd)/100гб iscsi lvm stripe на 2-ух 320Гб - access time 12.81ms/11.09ms, linear read 52мб-89мб/45мб-73мб, random read для 64к блоков 4.79мб/2.73мб

Так это ещё достаточно неплохо. :)
Попробуйте random read блоками по 4к, сдаётся мне, что вот там-то и будет основная разница.

mtu менял от 1500 до 7200 (кстати, как это они могут быть разными на обоих концах

Запросто могут быть разными, при этом пакеты большего размера на компьютере с меньшим размером MTU будут либо обрезаться, либо вообще не доходить, увеличивая счётчик "dropped" пакетов.

подключение кросовер

Это вообще ни при чём - в отличии от скорости и дуплекса, MTU не согласовывается на уровне подключения.

и как его менять под windows?

В свойствах сетевого подключения, в настройках TCP/IP.
Там обычно даётся всего три или четыре варианта: 1500, максимум, и одна-две ступени между ними.

Я конечно понимаю хотеть не вредно, но мало ли, хотелось и бездисковую (бесшумную) станцию и без серъезных потерь производительности

Это очень хорошее и правильное желание, но лично я не уверен, возможно ли вообще добиться скорости загрузки игр из сети, сравнимой с локальной. В моих тестах разница в скорости тоже была. Но я не так много с этим экспериментировал (например, не пробовал iSCSI).
Поэтому мне кажется стоит рассмотреть вариант установки локально жёсткого диска (для игр).
Обратите внимание на диски WD серии GreenPower (5400 оборотов), они должны быть очень тихими.

К тому же у меня были надежды использовать выделенное хранилище на linux (со всеми плюшками) для windows серверов (на которых плюшками и не пахнет)

Смотря что хранить на таком хранилище. Для многих применений, вполне разумным вариантом видится Samba. Добавочная плюшка с нею - возможность использования настоящей производительной и надёжной юниксовой ФС (XFS, JFS, или скоро btrfs), в то время как поверх iSCSI без вариантов пришлось бы городить NTFS.

какой модуль к какой сетевухе сейчас посмотреть не могу

lspci -k
Спасибо сказали:
rPman
Сообщения: 22
ОС: Ubuntu

Re: Построение высокопроизводительного файлового сервера

Сообщение rPman »

rm_ писал(а):
04.02.2009 12:31
Технические тесты Roadkil's disk speed 2.0: hdd 500гб (wd)/100гб iscsi lvm stripe на 2-ух 320Гб - access time 12.81ms/11.09ms, linear read 52мб-89мб/45мб-73мб, random read для 64к блоков 4.79мб/2.73мб
Так это ещё достаточно неплохо. :)
Попробуйте random read блоками по 4к, сдаётся мне, что вот там-то и будет основная разница.
диск 0 - локальный диск 1 - iscsi, какраз с меньшими блоками разницы нет... вообще то lv по умолчанию блоки 64к делает, но я делал 8кб, было только хуже (и readahead отключал), вернул все на по умолчанию.
rm_ писал(а):
04.02.2009 12:31
mtu менял от 1500 до 7200 (кстати, как это они могут быть разными на обоих концах
Запросто могут быть разными, при этом пакеты большего размера на компьютере с меньшим размером MTU будут либо обрезаться, либо вообще не доходить, увеличивая счётчик "dropped" пакетов.
ifconfig пишет все дропы, ерроры и т.д. по нулям. А ведь я и на 100мбтке ставил mtu 90.
rm_ писал(а):
04.02.2009 12:31
и как его менять под windows?
В свойствах сетевого подключения, в настройках TCP/IP.
Там обычно даётся всего три или четыре варианта: 1500, максимум, и одна-две ступени между ними.
я конечно понимаю что оффтопик, но не вижу, хоть убей. И не видел ни на серверных ни на десктопных виндах этого. в настройках тсп есть только ипишники, днс, винс и параметры фильтрации.
P.S. А если у меня бридж на винде? Просто mtu это же не уровень tcp это ниже?..
rm_ писал(а):
04.02.2009 12:31
Я конечно понимаю хотеть не вредно, но мало ли, хотелось и бездисковую (бесшумную) станцию и без серъезных потерь производительности
Это очень хорошее и правильное желание, но лично я не уверен, возможно ли вообще добиться скорости загрузки игр из сети, сравнимой с локальной. В моих тестах разница в скорости тоже была. Но я не так много с этим экспериментировал (например, не пробовал iSCSI).
Поэтому мне кажется стоит рассмотреть вариант установки локально жёсткого диска (для игр).
Обратите внимание на диски WD серии GreenPower (5400 оборотов), они должны быть очень тихими.
В винде без диска вообще никак, если загрузку по iscsi настроить можно, то своп по сети она не умеет. Сейчас у меня так и есть локально диск стоит для винды, игры либо в сеть либо локально устанавливаю, по ситуации, например в условиях 1г оперативки (отдельная песня, пока не куплю 2 планки по гигу, еще гиг будут валяться на полке) Crysis запускается на порядок шустрее по сети, а с локального диска уходит в непрерывный своп.
На глазок оценил, что на чтение iscsi быстрее samba/nfs исключительно из-за того, что метаинформация фс кешируется локально, но на запись медленней, потому что число запросов повыше. Еще не пробовал ставить драйвер какой-нибудь linux fs под windows
rm_ писал(а):
04.02.2009 12:31
какой модуль к какой сетевухе сейчас посмотреть не могу
lspci -k
Смешно, но модуля r8169 у меня нет :) но он показан.. как я понял он компилирован в ядро :) потому я его и не увидел по lsmod и modinfo.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

Re: Построение высокопроизводительного файлового сервера

Сообщение rm_ »

диск 0 - локальный диск 1 - iscsi, какраз с меньшими блоками разницы нет... вообще то lv по умолчанию блоки 64к делает, но я делал 8кб, было только хуже (и readahead отключал), вернул все на по умолчанию.

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

А ведь я на 100мбтке ставил mtu 90.

Сколько-сколько?)

И не видел ни на серверных ни на десктопных виндах этого. в настройках тсп есть только ипишники, днс, винс и параметры фильтрации.

Да, я перепутал, не в настройках TCP/IP, а в свойствах самой сетевой карты. Если нету - значит MTU выше 1500 не поддерживается. В случае с nForce'ами так оно и есть на удешевлённых версиях чипсетов, на Вашем - кажется должно.

В винде без диска вообще никак, если загрузку по iscsi настроить можно, то своп по сети она не умеет.

8 гигабайт ОЗУ, и без свопа.
Спасибо сказали:
Аватара пользователя
danger08
Сообщения: 715
ОС: Linux (CentOS, Ubuntu)

Re: Построение высокопроизводительного файлового сервера

Сообщение danger08 »

rPman писал(а):
05.02.2009 11:50
Смешно, но модуля r8169 у меня нет :) но он показан.. как я понял он компилирован в ядро :) потому я его и не увидел по lsmod и modinfo.

Но это не мешает собрать сторонний модуль, и назначить его для устройства (если есть в этом необходимость).
Блогосайт - http://www.fateyev.com
Спасибо сказали: