10Gbit сетевое хранилище — 2

[@lolmaus]

Какова производительность дисковых подсистем десктопа и NAS, что им 1 Гб/с не хватает?

У меня копирование с SSD на HDD внутри системника идет со скоростью ~100 МиБ/с, это как раз на пределе возможности гигабитки.

[@track]

Вероятно такая, что им 1 Гб/с не хватает. ;)

У меня копирование с SSD на HDD внутри системника

А теперь представьте, что SSD и HDD у вас десяток, и каждый копироует на скорости 100Mb/s

[@DarkTwin]

Скорость же не линейно возрастает.
Самое правильно это взглянуть на статистику за неделю другую и желательно в период интенсивной работы на проектами.
Просто если не хватает 1Гб можно же поставить два и допилить напильником.
В памяти свежа тема habrahabr.ru/post/181822/#comment_6321008

[@track]

Скорость же не линейно возрастает.

А это уж как повезет. В случае задачи автора, то есть почти 100% последовательного чтения большими блоками, оно растет практически линейно.

Просто если не хватает 1Гб можно же поставить два и допилить напильником.

Это не всегда работает для файлового доступа, что связано с особенностями работы протоколов этого самого файлового доступа.
При этом даже 4 порта Gigabit Ethernet это все еще существенно меньше по скорости, чем один 10G, а возни, глюков и работы напильником настолко больше, что вся экономическая привлекательность испаряется.

[@lolmaus]

Статья называется «бюджетное сетевое хранилище», при чем тут SSD?

[@track]

Ну, знаете, бюджеты у всех разные ;) Или вы считаете, что само наличие SSD уже переводит решение в enterprise? ;)
Два десятка HDD SAS при 100% sequental read большими блоками (а это как раз задача автора, доступ к фотоархиву) запросто забьют канал и несколько гигабит в секунду.

[@lolmaus]

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

[@track]

Ну, даже не знаю что сказать. Не все же питаются дошираком? ;)
Для подобных задач это в самом деле вполне бюджетное решение.

[@lolmaus]

То есть, по вашему, все, кто не владеет парком спортивных авто или 10-гигабитным NAS на твердотельных дисках — все равно что питаются дошираком?

Сколько же зарабатывает ваш фотограф? И сколько должен, по вашему зарабатывать человек, чтобы не «питаться дошираком»?

UPD Я тут посмотрел, один 900-гиговый HDD SAS стоит 20 тысяч рублей. «Два десятка» — это уже 400 тысяч. И это не считая, собственно, решения, описываемого в сабже. Если это решение-эконом, то какое тогда среднее и какое дорогое?

[@track]

Мне печально видеть, что Хабр с некоторых пор превращается в тусовку… малоимущих, скажем минимально обидно.
Когда на пост «Как сделать мотороллер из говна и палок» начинаются возмущенные комментарии: «А у него там вообще вместо говна — пластилин, фу, это мажорство и жлобство, кто себе это вообще может позволить, пластилин!»

PS. Фотографы, кстати, вообще хорошо зарабатывают. Я имею ввиду не те, что «фотографы в инстаграм». ;)

[@lolmaus]

Еще раз. Вы считаете всех, кто не может позволить себе для личного пользования NAS за полмиллиона рублей, малоимущими?

[@track]

Я считаю, что ваши претензии по данному вопросу — смешны и неуместны.
Если для вас это — дорого, то вы можете написать сво пост, про то как сделать это дешевле, с удовольствием почитаю.

[@lolmaus]

Мои претензии касаются исключительно слов «бюджетный NAS для фотографа» в заголовке. Это введение читателей в заблуждение и некрасивые понты.

[@alsakharov]

Я бы хотел уточнить — в заголовке первой темы написано «10Gbit сетевое хранилище при умеренных затратах». В этой теме да, я употребил слово «бюждетное», но очередной раз указал, что бюджетность эта применяется к хранилищу с 10Gbit сетевым интерфейсом (по факту — с двумя такими интерфейсами).

Как вы понимаете, система должна быть сбалансированной. Делать низкоскоростное хранилище с высокоскоростным интерфейсом — это как-то странно.
Опять же, как было замечено, бюджет — он в каждом случае свой.
Больше про финансы было все-таки не в этой, 2й статье, а в первой.
И именно там оценивалась стоимость такого проекта. Напомню, что для соединения сетевого хранилища и рабочей станции 10Gbit линком, затраты составили чуть больше $500.
Учитывая, что стоимость только одного трансивета Cisco SFP-10G-SR начинается в районе 20тыс.рублей, а в моем случае суммарная стоимость двух 2х портовых карт, двух трансиверов и оптического патч-корда составили меньше этой суммы, я продолжаю считать предложенное решение бюджетным.
И я так же продолжаю считать коммутатор SG500X при его розничной цене в районе 40тыс. рублей достаточно бюджетным решением потому, что за эти деньги покупатель получает 24 гигабитных порта, 4 10гигабитных порта и 2 5гигабитных порта для стека.
Для нынешнего рынка small business моделей это очень интересное предложение.

[@lolmaus]

А зачем фотографу дома 30-портовый свич?

[@alsakharov]

А почему вы решили, что свич стоит дома?
И почему вы решили что фотограф один?
Посмотрите первую строчку первого поста.

Из этого поста последняя из перечня задач, которую должен решать коммутатор:
"— сегментирование сети на VLANы (для фото трафика, для IP камер видеонаблюдения, для систем контроля доступа и автоматики)."

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

[@lolmaus]

Потому что вы написали «бюджетный NAS для фотографа».

[@opium]

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

[@Mobby]

Какие красивые лампочки.

[@alsakharov]

А они еще и моргают.
И если подобрать правильный ритм, это должно производить неизгладимое впечатление на покупателя :-)

[@beho1der]

Собрали бы с Cisco статистику по портам по загрузке в течение рабочего дня

[@alsakharov]

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

[@JDima]

Даже запуск на сервере и раб. станции тестовой утилиты NTttcp для проверки скорости работы 10G интерфейсов не смог склько-нибудь заметно нагрузить CPU коммутатора.

Ну а, собственно, с чего процессору коммутатора задумываться над проходящими через железку TCP пакетами? :) Они вообще никак не касаются процессора. А если начинают касаться, это уже проблема.

У меня, кстати, такое бывало как-то. 3750-й, задействованный строго под L2, внезапно показал перегрузку ЦП. По симптомам — по какой-то причине транзитные пакеты (опять же, не роутящиеся) начали пунтиться в ЦП, около 5к pps. Дебаги показали, что в ЦП лупит один конкретный поток — ничем не отличающийся от остальных, и, по словам коллег, собирающийся продолжаться еще с неделю (копирование бешеных терабайтов). Чуялка говорит «баг, наверняка завязанный на 5-tuple, надо бы хотя бы одно значение в нем поменять и посмотреть, что будет», ну и никого не радовало прокачивать терабайты через ЦП свитча, долго это и чревато. Поток перезапустили, порт отправителя изменился — железке полегчало. Но не до конца. Теперь ей в ЦП бьет другой поток. Его перезапустили — возник третий. Маленький, так что можно было уже в спокойной обстановке обновлением заняться.

Мораль истории — не надо копить аптаймы даже аксессных свитчей, от которых ничего не требуется, по 5 лет, а надо периодически обновлять их :)

[@casperrr]

Хм. А много ли бешеных терабайтов 3750 перемелет процом (PowerPC 405 кажется) и не растянется ли это с недели на годы? Я на 3560 однажды поставил эксперимент — поднял gre-тонель (ессно это все работало чисто софтверно ибо по другому не умеет). 10 мбит через этот тунель — смерть цпу.
А если бы там еще control-plane был защищен неудачно…

[@JDima]

А много ли бешеных терабайтов 3750 перемелет процом

Мало, в том-то и проблема. Примерно 5-7к pps. Нет, он не помер, железка вполне отзывалась, благо поток был один, и TCP вовсе не пытался выжечь все такты до последнего. Но, скажем, при изменении топологии STP могло бы начаться веселье…

Коллег уговорил, они рестартанули задачу и вздохнули спокойно вместе со мной. Тот же самый поток с единственным отличием (номер порта отправителя) взлетел примерно до line-rate, забыв о существовании ЦП.

Кстати — при первоначальной диагностике перевод потока на другой свитч методом shutdown порта и отработки тиминга (у второго свитча идентичная модель, идентичный софт) дал тот же результат. Тот же самый поток начал лупить по ЦП. Т.е. не хардварная проблема. Точнее — хардварная (определенно некорректное программирование железа), но вызванная софтом. Но вот изучаю я архитектуру 3750 на доступном для непосвященных уровне и не понимаю, зачем вообще свитч влезал в L4 заголовок. Ну да, был включен ip routing, и что? На cat6500 например такие пакеты по идее не должны были бы подняться до L3/L4 engine внутри PFC/DFC, а L2 логике нет дела до номеров портов. Исходящий порт не был etherchannel'ом, т.е. даже хеши вычислять не требовалось. Просто без всяких обработок передать в соответствии с CAM таблицей на конкретный физический порт. И даже тут они умудрились накосячить.

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

[@casperrr]

«Дебаги показали, что в ЦП лупит один конкретный поток „

А не подскажите, как это смотрелось?

show processes cpu при этом наверное показывал IP input в топе и что-нибудь типа sh cef not-cef-switched нарастало не кисло. А как конкретную тсп-сессию отловить?

[@JDima]

#show processes cpu sorted 
CPU utilization for five seconds: 88%/71%; one minute: 82%; five minutes: 81%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process 
  59    14404034 451286517         31  9.10%  8.36%  7.89%   0 HLFM address lea 
 225         645       139       4640  0.95%  0.54%  0.12%   1 SSH Process    

#show controllers cpu-interface 
cpu-queue-frames  retrieved  dropped    invalid    hol-block  stray
sw forwarding     880320991  0          0          0          0         

(бешеный рост цифр у этого пункта)

А конкретный гад выявился так:
#debug platform cpu-queue software-fwd-q

Ага, мне тоже не понравилась перспектива включать дебаг, отлавливающий все прилетающие на ЦП пакеты, при перегруженном ими ЦП. Да и в доках не написано про безопасность этого дебага. Потому делал ночью, с включенным рейт-лимитером и отключенным логированием в консоль и терминал. ИЧСХ, железка прекрасно пережила его.