Хранение и доступ к макетам как лучше устроить?

[Pavel Pe4atnikov]

Раньше было у всех на компах все разные папки с клиентскими макетами... пора навести порядок.
Мне видится что надо или выделить отдельный комп под а-ля файл-сервер (напихать туда винтов и там хранить ВСЕ клиентские папки) или же купить один здоровый сетевой винт и врубить его в хаб. Как лучше?
Что надежней: комп с винтами или отдельный сетевой винт?

Далее. А как с этим работать? Допустим есть клиент ААА. Для него в общем хранилище сделана папка ААА. В разное время, а может и в один день, РАЗНЫЕ версталы работают с его макетами. Как это правильно осуществить/организовать?
1. создается под заказ папка на локальном компе диза, диз работает с файлами, а в конце дня эта папка сливается в общую папку клиента ААА? Это автоматом происходит или же он САМ должен эту свою папку сливать в общую папку клиента в хранилище?
2. работает и работает себе.... и раз в месяц, допустим, все папки сливаются с папками клиентов в хранилище?
У кого как?

Далее. Как и НАДО ли разграничивать в хранилище доступ к клиентским папкам для разных людей (версталов)? Допустим старший диз А работает с клиентом ААА и не хочет, чтобы другие дизы совали нос "куда не надо"... Как в таком случае разграничить права доступа и СТОИТ ЛИ?
1. Если стОит, то подключение данного диза к хранилищу должно осуществляться через логин/пароль или же можно как-то намутить, чтобы доступ к папке с одного компутера был, а с другого - не был?
2. Не делать разграничение доступа вообще (людям надо доверять )?

Какие идеи? У кого как?

[Boroda]

Сообщение от d_Serg

Насколько я понимаю (знатоки, поправьте меня!!!), без тонкой настройки всей нашей гигабитной офисной сети, мы сможем получить РЕАЛЬНУЮ пропускную способность около 70 МБайт/сек на 1 порт, при 2-портовом агрегировании - прим. вдвое выше.... Т.е. для того, чтобы нагрузить сервер "под завязку" (даже без учета кэша!!!) мы можем использовать агрегирование 3-х сетевух....

Теоретики
Какой из ваших дизайнерских компов способен принять трафик на скорости 70Мбайт/сек? Что у вас с кабельной инфраструктурой? Я к тому, что везде лежит экранированная витая пара и каналы прокладки витой и силовых кабелей не совпадают? Ведь только при плохой прокладке кабеля вы можете получить довольно значительное проседание скорости.

А теперь финт:
Положите в папку /mnt/tmp/ скажем десяток файлов и запустите десяток команд на копирование. Ну или достаточно просто закинуть туда сотню файлов по 20-100 Мб и сделать:
dd if=/mnt/tmp/ of=/mnt/tmp/ bs=32768

А потом напишете, что осталось от вашей скорости.

А копировать файл размером в Гиг да еще с пустого диска на пустой каждый может

Сделайте еще один финт:
У вас же будет самба? Расшарте на серваке папку и подключите ее к дизайнерскому компу. Положите туда ваш любимый гигабайтный файлик и попробуйте его скопировать на локальный диск у диза. Всего 1 комп, всего 1 свич, всего две сетевые.

[bubapb]

называется забейте на самбу и освойте iSCSI, клиентов валом, у дизов будет диск-папка подмонтированная, куда он будет скидывать макеты, скорость этого протокола на порядок лучше SMB, эту фишку умеют все NAS, и не надо городить костыли из самосбора

[d_Serg]

Сообщение от Boroda

Теоретики
Какой из ваших дизайнерских компов способен принять трафик на скорости 70Мбайт/сек? Что у вас с кабельной инфраструктурой? Я к тому, что везде лежит экранированная витая пара и каналы прокладки витой и силовых кабелей не совпадают? Ведь только при плохой прокладке кабеля вы можете получить довольно значительное проседание скорости.

А теперь финт:
Положите в папку /mnt/tmp/ скажем десяток файлов и запустите десяток команд на копирование. Ну или достаточно просто закинуть туда сотню файлов по 20-100 Мб и сделать:
dd if=/mnt/tmp/ of=/mnt/tmp/ bs=32768

А потом напишете, что осталось от вашей скорости.

А копировать файл размером в Гиг да еще с пустого диска на пустой каждый может

Сделайте еще один финт:
У вас же будет самба? Расшарте на серваке папку и подключите ее к дизайнерскому компу. Положите туда ваш любимый гигабайтный файлик и попробуйте его скопировать на локальный диск у диза. Всего 1 комп, всего 1 свич, всего две сетевые.

открыт к обсуждению! принимаю любые варианты улучшения!
по-поводу кабелей... Конечно не уверен, что кабеля проложены идеально, но даже при имеющейся топологии данные с нашего имеющегося файл-сервера прокачиваются с реальной скоростью 45-60 МБайт/секунду, причем как на комп к-ый стоит физически рядом с файл-сервером (длина кабелей 2 х 1,5 метра), так и на компы в др. комнате (при длине кабеля до 20-25 метров)... и это при имеющейся РЕАЛЬНОЙ забитости файлового пространства на 92%.... (это про 1 комп, 1 свич и две сетевых).
Понимаю, что маленькие файлы будут заливаться дольше... Но для реального пользователя, что 0,3 секунды, что 0,6 секунд - имхо, не принципиально... а копирование сотни маленьких файлов - ооочень неактуальная для нас задача... К тому же, опять же есть кэш....

[d_Serg]

Сообщение от bubapb

и не надо городить костыли из самосбора

руководство пользователя, предлагаемого Вами QNap - около 800 (!!!!) страниц. Многие ли смогут разобраться во всей сотне предлагаемых им опций-настроек? Оптимально сконфигурировать данную коробку?
А если все-равно прибегать к услуге сторонних специалистов, то не проще ли этим спецам дать возможность "под себя" выбрать железо? Тем более, что самосбор в разы дешевле "коробки"....

[Boroda]

Сообщение от bubapb

называется забейте на самбу и освойте iSCSI

Ну вот так и сразу... я хотел плавно к этому подвести. Т.к. скорость (накладные расходы) самбы мягко говоря -- никаких агрегирований не хватит.

[Boroda]

Сообщение от d_Serg

Но для реального пользователя, что 0,3 секунды, что 0,6 секунд - имхо, не принципиально...

Ну и зачем тогда вообще все эти агрегирования?

Сообщение от d_Serg

а копирование сотни маленьких файлов - ооочень неактуальная для нас задача... К тому же, опять же есть кэш....

По другому я не смогу сэмитировать доступ к разрозненным данным на винтах. А именно это и будет наблюдаться в случае доступа большого количества народу к файлсерверу. Да и просто попробуйте открыть фотошопом файлик на файлсервере и поработать с ним, временами нажимая Ctrl-S.

[Boroda]

Сообщение от d_Serg

при имеющейся топологии данные с нашего имеющегося файл-сервера прокачиваются с реальной скоростью 45-60 МБайт/секунду, причем как на комп к-ый стоит физически рядом с файл-сервером (длина кабелей 2 х 1,5 метра), так и на компы в др. комнате (при длине кабеля до 20-25 метров)... и это при имеющейся РЕАЛЬНОЙ забитости файлового пространства на 92%....

А зачем тогда весь этот огород. 45-60 это предел для гигабита в вашем варианте ИМХО.

Тем более сами говорите:

Сообщение от d_Serg

Но для реального пользователя, что 0,3 секунды, что 0,6 секунд - имхо, не принципиально...

Ну добьетесь вы 70-80Мбайт на каждом компе. И чего? Если сейчас 60? Никто и не заметит.

[d_Serg]

Сообщение от Boroda

Ну и зачем тогда вообще все эти агрегирования?.

Сообщение от Boroda

А зачем тогда весь этот огород. 45-60 это предел для гигабита в вашем варианте ИМХО.

Поправьте меня, если я не прав... При нынешнем раскладе 45-60 МБ делится на всех одновременно подключенных пользователей... и если этих пользователей 4-5 чел., то на каждого получается - совсем ничего.... Как я понимаю, за счет агрегирования мы не получаем существенной прибавки производительности, если в сети у нас только один пользователь, но для для нескольких одновременно подключенных пользователей прибавка будет фактически двукратной, я прав? Плюс на новом железе 8-кратное увеличение кэша (нынешний файл-сервер имеет 1 Гиг памяти, когда-то это был оооочень крутой комп - РИП для ФНА но прошло 9 лет....), плюс более скоростные винчи, плюс более скоростная обработка данных, плюс (надеюсь ) более оптимизированная файловая система...
Или я не прав? и возлагаем на новый сервер неоправданные надежды?

[d_Serg]

коллеги, я серьезно! по-критикуйте наше решение!!!

[Boroda]

d_Serg, а это легко проверить: какая скорость копирования гигабайтного файла скажем не на один, а на два (три) компа?

Запустите копирование. Посмотрите на нагрузку сетевухи на сервере.

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

[d_Serg]

Boroda, да проверим!
Сейчас комп еще у программиста...
В конце недели у нас только появится управляемый свич - тогда и проверим "в боевых условиях"....

[Boroda]

d_Serg, а сейчас посмотрет загрузку сетевухи на существующем файлсервере?
Вот эту картинку имею в виду:

[d_Serg]

Сообщение от Boroda

d_Serg, а сейчас посмотрет загрузку сетевухи на существующем файлсервере?

ну сейчас у нас вообще профилактика и нагрузка на файл-сервер - просто никакая ....
Ну и потом... мы же оперативщики.... мы же зарабатываем не на "вале", а на "потенциальных" возможностях наших печатень....
Если посчитать СРЕДНИЕ годовые печатные пробеги, то для большинства из нас будет достаточно принтера со скоростью печати 3-4 листа в минуту ))) только вот почему-то все хотят иметь более быстрые принтеры...

[Boroda]

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

На новом компе повторить тоже самое и возрадоваться

Ну и рассказать нам.

[PavelM]

Сообщение от Boroda

Вот эту картинку имею в виду

Очень правильная картинка. Узким местом, как правило, является не сеть, а скорость чтения с дискового массива. Причем для файлсервера скорее параметр скорости произвольного чтения блоками 512К.

[ЛЕКС]

Nikit0s
как я понимаю, ваш Синилоги работает уже больше года, как, появились ли какие подводные камни или траблы? Выбрали версию похожую на вашу, только с меньшим количеством дисков, поэтому интересно.

[d_Serg]

Коллеги, нужен Ваш профессиональный совет....
Вот какие ньюансы всплыли при попытке агрегирования....
Т.к. всплывшие факты лежат за пределами моих знаний, прошу помощи специалистов...

Получить кратный по скорости трафик по сравнению с одним сетевым соединением между сервером и одновременно подключенными рабочим компьютерами в рамках существующих протоколов агрегации сделать можно только частично....

Что можно сделать: можно сделать так, чтобы при ОДНОВРЕМЕННОМ обмене с нескольких рабочих компьютеров скорость кратно увеличивалась. Т е два клиента одновременно качают с сервера файлы, и он с гейта скачивается с суммарной скоростью в 2 гбит. Причем работает это только на трафике от гейта к рабочим компьютерам, трафик в обратную сторону идет с суммарной скоростью 1 гбит (т е это 1 гбит делится между компьютерами). Причина - все дешевые управляемые свичи не поддерживают нужный для двустороннего увеличения скорости протокол LACP (это часть протокола 802.3ad). Мой свич (цена ~12тыс) поддерживает только статический 802.3ad, без поддержки LACP, а выбранный Dlink вообще не поддерживает 802.3ad. Она поддерживает агрегирование только в очень простом виде, "trunking". Поддержка LACP заявлена в DLink начиная с 3-й серии, самый дешевый из них DGS-3426 за 24 тыс руб.
http://market.yandex.ru/model.xml?modelid=1577789

Если поставить свич такого плана, то можно будет ускорить как трафик от гейта на несколько рабочих компьютеров, так и трафик в обратную сторону.

На остальных свичах приходится использовать другие протоколы агрегирования (их в линухе кроме 802.3ad поддерживается еще 5 шт), т к 802.3ad без LACP нормально не работает (т е либо не работает совсем, либо очень медленно, с постоянными замираниями на несколько секунд).

Еще важный момент: в твоих условиях агрегирование даже на дорогом свиче будет срабатывать не всегда. Если мы агрегируем два канала, ваши 8 рабочих мест поделятся примерно пополам (примерно - т к деление произойдет на основе MAC-адреса сетевой карты и еще некоторых параметров). Деление это статическое, т е будет статически сформировано два пула, первый пул будет работать через один канал, второй пул через другой. Ускорение при одновременном качании будет только в том случае, если качают компьютеры из разных пулов, в противном случае между компьютерами будет разделяться один канал.

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

Я решил посмотреть, как это сделано у synology. Зашел сюда: http://www.synology.com/ru-ru/products/dsm_livedemo и посмотрел режимы агрегирования. Выяснилось, что поддерживаются только два "802.3ad" (обязательно требует дорогой свич с LACP) и "fault-tolerance" (это когда скорость не возрастает, а дублирование используется ради повышения надежности соединения, типа RAID1, но не из дисков, а из свичей).
И причем это на дорогущем RS3412xs за 114 тыс руб (т к демо от него, это видно из имени сервера на одном из скриншотов).

Что помешало им реализовать режимы, ускоряющие работу на дешевых управляемых свичах, не понимаю. Линух их поддерживает. Вот мои тесты с режимом агрегирования "balance-xor":

одновременная скачка двумя компьютерами с сервера:
[ 3] 0.0-30.0 sec 3.29 GBytes 942 Mbits/sec
[ 3] 0.0-30.0 sec 3.25 GBytes 929 Mbits/sec

одновременная закачка двумя компьютерами на сервер:
[ 4] 0.0-60.0 sec 3.65 GBytes 523 Mbits/sec
[ 5] 0.0-60.0 sec 2.98 GBytes 426 Mbits/sec

Видно, что в одном из направлений (от сервера) скорость удвоилась, а в другом (к серверу) оба компьютера поделили 1Гбит.

Столь высокий результат (950Мбит) определяется тем, что используется синтетический тест iperf http://ru.wikipedia.org/wiki/Iperf

Т е объединение каналов в одну сторону (от сервера к клиентам) сделать можно. Вопрос, нужно ли. Насколько это даст ускорение?
Стоит агрегирование оставить на дешевом свиче? или целесообразнее приобретать дорогой свич? Насколько будет устойчивая работа на дешевом свиче?

Или вообще, нах отказаться от этого агрегирования? (тогда непонятно, чего такого мы сильно выиграли с приобретением нового железа....)

[bubapb]

Сообщение от d_Serg

Коллеги, нужен Ваш профессиональный совет....
Вот какие ньюансы всплыли при попытке агрегирования....
Т.к. всплывшие факты лежат за пределами моих знаний, прошу помощи специалистов...


Т е объединение каналов в одну сторону (от сервера к клиентам) сделать можно. Вопрос, нужно ли. Насколько это даст ускорение?
Стоит агрегирование оставить на дешевом свиче? или целесообразнее приобретать дорогой свич? Насколько будет устойчивая работа на дешевом свиче?

Или вообще, нах отказаться от этого агрегирования? (тогда непонятно, чего такого мы сильно выиграли с приобретением нового железа....)

лисапед то не надо изобретать, на коленке особенно

начни с свича тогда, купи вот такой http://market.yandex.ru/model.xml?modelid=923611 (8.8Гбт внутреннего обмена я думаю тебе хватит выши крыши, мне хватает более чем, два гигабина на меде, и две оптики можно сконфигурить как надо), плюс настройте на текущем NAS iSCSI и подключи дизам (кто много трафика тянет), сейчас стоит "коробочка" или "самосбор на коленке"?
Если последнее воткни в него пару серверных Intel серевух, типа такой http://www.ulmart.ru/goods/195395 и уже уже с этим начинай плясать дальше. (либо можешь сразу менять мать-проц-винты на нормальные)

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

пысы: хочешь много сервер-свич-клиенты, в сервер оптику ставь 10гбт и в свич sfp модуль мультимод оптический

[stinol]

Господи, чем вы там занимаетесь, если у вас много человек одновременно(!) качает многогигабайтные файлы? Видео?
У нас 3 человека фигачит макеты туда/сюда на гигабите канале на сервере на фринасе — даже не замечают ничего. А принтеры вообще на 100 мбит висят.
Свитч на 200 баксов и Фринас.

Я, конечно, люблю дорогие хорошие вещи, мне дай волю я бы типографию в ЦОД превратил Но зачем?

[Nikit0s]

Сообщение от ЛЕКС

Nikit0s
как я понимаю, ваш Синилоги работает уже больше года, как, появились ли какие подводные камни или траблы? Выбрали версию похожую на вашу, только с меньшим количеством дисков, поэтому интересно.

Ну да, кое-что новое узнали...

1. Скорее всего правильнее бы было создавать на группе винтов один большой раздел емкостью на всю группу, и в этом одном разделе -- общие папки (в терминологии Windows -- разные диски, которым можно присваивать буквы типа L: M: N: и так далее). Мы же сделали не очень правильно -- создали под каждую общую папку свой раздел. Теперь расширение какого-либо диска возможно только добавлением новых винтов в массив. А если бы все общие папки (они же диски) были бы на одном разделе -- тогда свободное место у них бы было тоже общее.

Но это палка о двух концах: в первом случае проще контролировать забивание места. Во втором же случае получается, что если емкость забита -- то ВСЯ, полностью, на всех общих дисках.

2. Встроенный антивирус оно конечно хорошо, но полная проверка может занимать несколько суток. При этом фильтрация проверяемых файлов по расширению почему-то не работает. То есть например говорим ему: JPG не проверять. А он все равно проверяет. Сильно не вникал, может быть надо как-то иначе задавать фильтры.

3. Встроенное индексирование папок включать НЕ НАДО -- длится оно довольно долго, и при этом заметно снижается производительность.

4. Добавление восьмого диска на 3ТБ в RAID6 заняло примерно неделю. Но, надо отдать должное, без особых тормозов в работе. То есть тормоза были, но как выяснилось -- из-за включенного индексирования. После отключения индексирования все стало ОК.

5. Индикатор, показывающий загрузку процессора -- врет и не краснеет.
На самом деле он показывает загрузку проца программами, а загрузка проца собственно операциями ввода-вывода не учитывается.
Например, индикатор показывает загрузку проца 5%, а файлы еле качаются. Оказывается в это время идет индексирование всех общих папок, и процессор реально загружен на 95%. Чтобы посмотреть ПОЛНУЮ РЕАЛЬНУЮ загрузку процессора -- надо запустить из главного меню "Мониторинг ресурсов", там более правильные показания.
То же касается памяти.

6. Встроенный MailServer -- удобная штука для организации локальной почты.

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

8. Всякие дополнительные пакеты без особой нужды лучше не ставить -- результаты в плане быстродействия собственно файл-сервера могут быть негативными.

9. Температура винтов в норме, хотя стоят они очень плотно.
7 винтов WD RED -- температура вообще выше 36 градусов не поднимается, а обычно 32-35. Восьмой поставили RE (Raid Edition) -- он греется чуть больше, примерно до 39 градусов.

10. Обновления операционки выходят каждый месяц, а то и чаще.
Приятно, что система живая.