Хранение и доступ к макетам как лучше устроить? - Страница 6 - Цифровая печать как бизнес - форум и портал
Индустрия цифровой печати - отраслевой портал  

Вернуться   Цифровая печать как бизнес - форум и портал > Компьютеры и программное обеспечение в оперативной полиграфии > Компьютеры для полиграфии

Реклама на форуме
  • Дополнительный доход для сервисного инженера. Узнать как…
Ответ
 
Опции темы
Старый 04.09.2013, 13:29   #1
Pavel Pe4atnikov
Строгий АДМИН
 
Регистрация: 30.07.2008
Сообщений: 4,656
Репутация: 624
По умолчанию Хранение и доступ к макетам как лучше устроить?

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

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

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

Какие идеи? У кого как?
Pavel Pe4atnikov вне форума   Ответить с цитированием
Старый 21.01.2014, 14:13   #101
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

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

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

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

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

Сделайте еще один финт:
У вас же будет самба? Расшарте на серваке папку и подключите ее к дизайнерскому компу. Положите туда ваш любимый гигабайтный файлик и попробуйте его скопировать на локальный диск у диза. Всего 1 комп, всего 1 свич, всего две сетевые.
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 14:18   #102
bubapb
Местный
 
Регистрация: 01.05.2011
Адрес: Липецк
Сообщений: 6,877
Репутация: 168
По умолчанию

называется забейте на самбу и освойте iSCSI, клиентов валом, у дизов будет диск-папка подмонтированная, куда он будет скидывать макеты, скорость этого протокола на порядок лучше SMB, эту фишку умеют все NAS, и не надо городить костыли из самосбора
bubapb вне форума   Ответить с цитированием
Старый 21.01.2014, 15:13   #103
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

Цитата:
Сообщение от 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 вне форума   Ответить с цитированием
Старый 21.01.2014, 15:20   #104
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

Цитата:
Сообщение от bubapb Посмотреть сообщение
и не надо городить костыли из самосбора
руководство пользователя, предлагаемого Вами QNap - около 800 (!!!!) страниц. Многие ли смогут разобраться во всей сотне предлагаемых им опций-настроек? Оптимально сконфигурировать данную коробку?
А если все-равно прибегать к услуге сторонних специалистов, то не проще ли этим спецам дать возможность "под себя" выбрать железо? Тем более, что самосбор в разы дешевле "коробки"....
d_Serg вне форума   Ответить с цитированием
Старый 21.01.2014, 16:59   #105
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

Цитата:
Сообщение от bubapb Посмотреть сообщение
называется забейте на самбу и освойте iSCSI
Ну вот так и сразу... я хотел плавно к этому подвести. Т.к. скорость (накладные расходы) самбы мягко говоря -- никаких агрегирований не хватит.
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 17:03   #106
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

Цитата:
Сообщение от d_Serg Посмотреть сообщение
Но для реального пользователя, что 0,3 секунды, что 0,6 секунд - имхо, не принципиально...
Ну и зачем тогда вообще все эти агрегирования?

Цитата:
Сообщение от d_Serg Посмотреть сообщение
а копирование сотни маленьких файлов - ооочень неактуальная для нас задача... К тому же, опять же есть кэш....
По другому я не смогу сэмитировать доступ к разрозненным данным на винтах. А именно это и будет наблюдаться в случае доступа большого количества народу к файлсерверу. Да и просто попробуйте открыть фотошопом файлик на файлсервере и поработать с ним, временами нажимая Ctrl-S.
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 17:04   #107
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

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

Тем более сами говорите:
Цитата:
Сообщение от d_Serg Посмотреть сообщение
Но для реального пользователя, что 0,3 секунды, что 0,6 секунд - имхо, не принципиально...
Ну добьетесь вы 70-80Мбайт на каждом компе. И чего? Если сейчас 60? Никто и не заметит.
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 17:42   #108
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

Цитата:
Сообщение от Boroda Посмотреть сообщение
Ну и зачем тогда вообще все эти агрегирования?.
Цитата:
Сообщение от Boroda Посмотреть сообщение
А зачем тогда весь этот огород. 45-60 это предел для гигабита в вашем варианте ИМХО.
Поправьте меня, если я не прав... При нынешнем раскладе 45-60 МБ делится на всех одновременно подключенных пользователей... и если этих пользователей 4-5 чел., то на каждого получается - совсем ничего.... Как я понимаю, за счет агрегирования мы не получаем существенной прибавки производительности, если в сети у нас только один пользователь, но для для нескольких одновременно подключенных пользователей прибавка будет фактически двукратной, я прав? Плюс на новом железе 8-кратное увеличение кэша (нынешний файл-сервер имеет 1 Гиг памяти, когда-то это был оооочень крутой комп - РИП для ФНА но прошло 9 лет....), плюс более скоростные винчи, плюс более скоростная обработка данных, плюс (надеюсь ) более оптимизированная файловая система...
Или я не прав? и возлагаем на новый сервер неоправданные надежды?
d_Serg вне форума   Ответить с цитированием
Старый 21.01.2014, 17:48   #109
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

коллеги, я серьезно! по-критикуйте наше решение!!!
d_Serg вне форума   Ответить с цитированием
Старый 21.01.2014, 17:50   #110
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

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

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

Кстати, интересно будет как будет распределяться нагрузка между двумя сетевыми в случае агрегирования.
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 17:58   #111
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

Boroda, да проверим!
Сейчас комп еще у программиста...
В конце недели у нас только появится управляемый свич - тогда и проверим "в боевых условиях"....
d_Serg вне форума   Ответить с цитированием
Старый 21.01.2014, 18:00   #112
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

d_Serg, а сейчас посмотрет загрузку сетевухи на существующем файлсервере?
Вот эту картинку имею в виду:
Изображения
Тип файла: jpg netloaad.jpg (19.1 Кб, 0 просмотров)
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 18:16   #113
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

Цитата:
Сообщение от Boroda Посмотреть сообщение
d_Serg, а сейчас посмотрет загрузку сетевухи на существующем файлсервере?
ну сейчас у нас вообще профилактика и нагрузка на файл-сервер - просто никакая ....
Ну и потом... мы же оперативщики.... мы же зарабатываем не на "вале", а на "потенциальных" возможностях наших печатень....
Если посчитать СРЕДНИЕ годовые печатные пробеги, то для большинства из нас будет достаточно принтера со скоростью печати 3-4 листа в минуту ))) только вот почему-то все хотят иметь более быстрые принтеры...
d_Serg вне форума   Ответить с цитированием
Старый 21.01.2014, 18:21   #114
Boroda
Местный
 
Аватар для Boroda
 
Регистрация: 13.08.2008
Адрес: Украина / Чехия
Сообщений: 9,795
Репутация: 862
Отправить сообщение для Boroda с помощью ICQ Отправить сообщение для Boroda с помощью Skype™
По умолчанию

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

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

Ну и рассказать нам.
Boroda вне форума   Ответить с цитированием
Старый 21.01.2014, 23:47   #115
PavelM
Местный
 
Регистрация: 13.01.2009
Адрес: Московская область
Сообщений: 3,136
Репутация: 188
Отправить сообщение для PavelM с помощью ICQ
По умолчанию

Цитата:
Сообщение от Boroda Посмотреть сообщение
Вот эту картинку имею в виду
Очень правильная картинка. Узким местом, как правило, является не сеть, а скорость чтения с дискового массива. Причем для файлсервера скорее параметр скорости произвольного чтения блоками 512К.
PavelM вне форума   Ответить с цитированием
Старый 22.01.2014, 05:44   #116
ЛЕКС
Местный
 
Регистрация: 03.07.2011
Адрес: Приморье
Сообщений: 165
Репутация: 7
По умолчанию

Nikit0s
как я понимаю, ваш Синилоги работает уже больше года, как, появились ли какие подводные камни или траблы? Выбрали версию похожую на вашу, только с меньшим количеством дисков, поэтому интересно.
ЛЕКС вне форума   Ответить с цитированием
Старый 23.01.2014, 13:58   #117
d_Serg
Местный
 
Регистрация: 19.06.2009
Адрес: СПб
Сообщений: 8,348
Репутация: 252
По умолчанию

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

Что можно сделать: можно сделать так, чтобы при ОДНОВРЕМЕННОМ обмене с нескольких рабочих компьютеров скорость кратно увеличивалась. Т е два клиента одновременно качают с сервера файлы, и он с гейта скачивается с суммарной скоростью в 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
Т е объединение каналов в одну сторону (от сервера к клиентам) сделать можно. Вопрос, нужно ли. Насколько это даст ускорение?
Стоит агрегирование оставить на дешевом свиче? или целесообразнее приобретать дорогой свич? Насколько будет устойчивая работа на дешевом свиче?

Или вообще, нах отказаться от этого агрегирования? (тогда непонятно, чего такого мы сильно выиграли с приобретением нового железа....)
d_Serg вне форума   Ответить с цитированием
Старый 23.01.2014, 14:18   #118
bubapb
Местный
 
Регистрация: 01.05.2011
Адрес: Липецк
Сообщений: 6,877
Репутация: 168
По умолчанию

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


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

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

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

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

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

Последний раз редактировалось bubapb; 23.01.2014 в 14:20..
bubapb вне форума   Ответить с цитированием
Старый 23.01.2014, 14:40   #119
stinol
Местный
 
Аватар для stinol
 
Регистрация: 08.03.2009
Адрес: Москва
Сообщений: 944
Репутация: 90
По умолчанию

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

Я, конечно, люблю дорогие хорошие вещи, мне дай волю я бы типографию в ЦОД превратил Но зачем?
stinol вне форума   Ответить с цитированием
Старый 23.01.2014, 14:44   #120
Nikit0s
Местный
 
Регистрация: 13.05.2009
Адрес: Городок у Дона
Сообщений: 5,839
Репутация: 456
По умолчанию

Цитата:
Сообщение от ЛЕКС Посмотреть сообщение
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. Обновления операционки выходят каждый месяц, а то и чаще.
Приятно, что система живая.
Nikit0s вне форума   Ответить с цитированием
Ответ

Опции темы

Быстрый переход

183 204 195 210 237 243 263 7 8 152 15 16 13 11 10 14 35 9 256 123 37 144 145 146 179 20 258 21 22 124 23 24 97 127 128 25 26 126 136 154 64 65 254 233 159 162 163 164 66 27 98 48 56 120 58 59 60 61 62 135 63 165 166 200 201 202 51 53 167 169 168 172 52 55 54 125 255 207 217 218 219 220 221 222 223 224


"Форум индустрии цифровой печати" 2008-2023

Все вопросы по сотрудничеству:

Электропочта: info@trade-print.ru

Москва, Печатников пер.

Текущее время: 23:48. Часовой пояс GMT +4.

Яндекс.Метрика