Файловый сервер (хранение документов)

Чем дальше в лес, тем больше дров ))
Мнения разделились, а я так и не могу понять что для меня лучше :huh:

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

Такая же структура и в онлайн хранилище (на сегодняшний момент).

Эта основная папка лежит на моем лептопе (1).
Сканер привязан к другому компу (2). Человек за тем компом сканирует и естественно сохраняет документы опять по подпапкам у себя на компе.
Потом он должен все залить в инет, при этом опять раскладывая все по под-под-под-папкам. Потом я могу работать с этими документами например из дома (1), а также мой человек в Украине (4).
Но так как просматривать в онлайн хранилище документы неудобно, мы зачастую перекачиваем эти же папки себе, чтобы быстрее работать.

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

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

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

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

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

 

Повторю в n-ый и последний раз: dropbox _идеально_ удовлетворяет _всем_ Вашим требованиям.

 

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

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

Т.е. я бы вначале выяснил, на сколько сложно получтить staticIP и сколько он будет стоить.
Может быть этот вариант отпадет сам собой....

 

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



Левая часть офис, правая удаленные пользователи.
По верхней схеме, будет нагрузка на интернет канал и будет замедление работы внутри офиса, так как одни и теже файлы будут несколько раз качаться туда обратно, одни и теже страници будут открывать несколько раз с разных станций, нужен будет "жирный" интернет в обе стороны. Надо настраивать синхронизацию всех станций на один Дропбокс.
По нижней схеме нагрузка на интернет канал значительно ниже так как происходит только синхронизация. Работа внутри офиса ничем не ограничена, ни обьемами, ни трафиком, ни интернетом. Надо настраивать синхронизацию офисных машин с локальным NAS-ом это будет происходить очень быстро, а сам NAS настраивать на синхронизацию с Дропбоксом синхронизация между ними будет происходить не влияя на работу офисных машин.

 

Как ты все это красиво обозвал, Андрюша ))

где ж такого взять?

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

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

 

заходите на
link и нажимаете Download Google Drive, в меню слева самый нижний пункт.


link

 

Вот еще обзор
ссылка
В любом случае никокой Cloud-service и ни какой NAS не панацея и врятли решат все и вся.

 

в этом обзоре, кстати, пишут, что SkyDrive даёт 25 гиг. они дали их только тем, кто пользовался сервисом до выхода новой версии. сейчас бесплатно дают только 7 гиг.

UPD: в таблице внизу всё верно, сорри

 

Андрей, ты красиво всё разрисовал и в принципе выдал отличное и недорогое решение для малого оффиса. Вторая картинка (нижняя) будет идеальным вариантом. И для 4 и 5 компов можно сделать доступ к насу без дропбокса (через динамический днс, если не будет возможности сделать статический айпи), а дропбокс юзать для резервирования.

Кстати, Дропбокс живёт в облаке Амазона.

 

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

 

Ну вот, вы все-таки придумали )) :bis:

То есть надо или вторую картинку Андрея в жизнь воплотить или то, что Gonzo написал.

Главный вопрос - кто может сделать????
Чем скорее, тем лучше...

 

Свет то что я нарисовал еще не решение.
Верхняя часть картинки это по сути то что ты сейчас используешь, и одновременно тоже самое что предлагают другие, основанное на том или ином Cloud-service полностью зависимое от интернета. Самое простое, но не самое оптимальное(скоростное) решение.
Нижняя часть картинки это только оптимизация файлообмена внутри офиса для снижения интернет трафика, только для того чтобы обмен файлов между компьютерами внутри офиса не зависил от интернета и его "жирности". Для этого и нужен локальный файл-сервер или NAS выполняющий его функции.
Будет удаленный доступ к NAS-серверу напрямую, или через Cloud-service не принципиально, просто будут различные удобства а не скорости процессов.

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

 

Пошарился по сайтам производителей NAS-ов.
Thecus - вся линейка на Intel base, имеет дополнительные модули для синхронизации с Dropbox.
QNAP - также все Intel base имеют модуль для синхронизации с Амазоном.
Synology - на сторонних сайтах пишут что начиная с SDM4.0 есть поддержка Dropbox и т.п. но их сайте ничего не нашол об этом, что странно.

Синхронизация с Google Drive пока самописными модулями для Intel base NAS-ов, либо со стророннего компа на который установлен GDrive клиент.

 

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

 

Меня самого заинтересовала эта тема, чемже лучше Cloud-service. Хочется даже определить для чего достаточно облачных сервисов, а для чего их не достаточно.
Предлагаю устроить небольшое тестирование для тех кто пользуется облачными хранилищами, чтобы выявить на что они способны. Удобства, дизайн, рющечки и прочее я не беру в учет.
Мне нужно от каждого из пользователей облачных хранилищ получить некоторые цыфры, по которым можно будет судить о тех или иных преимуществах и возможностях. Также нужно будет сделать небольшой тест производительности этих систем и отписать мне результаты и только.

И так мне нужно узнать следующие значения:
A. TotalFilesSizeOnCloud - (каков общий обьем всех файлов в вашем хранилище)
B. TotalCountFilesOnCloud - (каково общее колличество всех файлов в хранилище)
C. FilesOperationPerDay - (сколько суммарно файлов за один день на вашем хранилище считывается, записывается, меняется, двигается и т.п.)
На основании этого можно судить о том, кто и как использует хранилище и сколь интенсивно.

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

1. DownloadSpeed - (? Mb/s)
2. UploadSpeed - (? Mb/s)
результаты Test1
3. Test1UploadTime - (? min)
4. Test1FindFileTime - (? sec)
результаты Test2
5. Test2UploadTime - (? min)
6. Test2FindFileTime - (? sec)

Скачайте и распакуйте два тестовых архива.

ссылка

ссылка
Обьем всех файлов в каждом тесте по 100Мб, но их колличество разнится в 100 раз, в одном архиве 1024 файлов по 100Кб, а в другом 10 файлов по 10Мб. Результаты теста вам наглядно покажут разницу между множеством файлов и еденичными файлами при одинаковых обьемах.

Последовательность тестов следующая:
Замеряем скорость интернета на www.speedtest.net Надо узнать максимальные скорости Download (пункт 1) и Upload (пункт 2).
Делаем обычную синхронизацию, чтобы убедиться что никакие другие файлы не будут участвовать в тесте.
Теперь заливаем весь фолдер test1 в облака так как вы это всегда делаете, и замеряете сколько минут это будет длиться и записываем (пункты 3,5).
Потом пытаемся найти в этой папке файл "findme.file" (он спрятан в глубине директорий). Мы узнаем сколько времени уйдет на поиски "иголки в стоге сена" (пункты 4,6). Операция нелепая, но каждый из нас делает это по несколько раз на день и надо знать сколько времени мы на это убиваем и сколь интелектуальны средства поиска.
После того как файл нашли, эти тестовые файлы вы можете удалять, они свое отработали.
Тоже самое надо повторить для для Test2.
Надеюсь что это не потратит у вас слишком много времени, а результаты полученные дадут некоторую ясность.

 

В кратце о своем домашнем NAS хранилище (Cloud-service не использую).
A. TotalFilesSizeOnCloud - (3,6Tb)
B. TotalCountFilesOnCloud - (более 10 миллионов файлов)
C. FilesOperationPerDay - (до 100 но иногда бывает гораздо больше)
NAS на работе
А. A. TotalFilesSizeOnCloud - (2,4Tb)
B. TotalCountFilesOnCloud - (более 50 миллионов файлов)
C. FilesOperationPerDay - (от 100 до нескольких тысяч)

Предоставляю результаты моих тестов проведенных на работе.

Для NAS сервера в офисе
1. DownloadSpeed - (Lan)
2. UploadSpeed - (Lan)
Test1
3. Test1UploadTime - (1 min 20 sec)
4. Test1FindFileTime - (3 sec)
Test2
5. Test2UploadTime - (16 sec)
6. Test2FindFileTime - (0,01 sec)
Это значения для нашей локальной сети, при учете того что сервер постоянно вкалывает и висит на 100Мб роутере, хотя вся локаль 1Гб и может позволить гораздо больше.

Для удаленного сервера в штатах (корпоративный Cloud-service)
1. DownloadSpeed - (1 Mb/s) скорость лимитирована сервером
2. UploadSpeed - (1 Mb/s) скорость лимитирована сервером
Test1
3. Test1UploadTime - (41 min 35 sec)
4. Test1FindFileTime - (1 min 5 sec)
Test2
5. Test2UploadTime - (11 min 20 sec)
6. Test2FindFileTime - (2 sec)
Эти показания мне хочется сравнить с другими для себя лично.

Попозже еще добавлю результаты тестов которые сделаю дома.

 

Может кто нибудь подтвердить эфективность работы в локалке, сравнить "с" и "без"?

 

мне не очень понятен смысл этих замеров. меня, если честно, не очень заботит скорость синхронизации, т.к. открываю я локальные файлы.

 

Постараюсь обьяснить проще.
При работе с локальными файлами, ничто никого не заботит, так как скорости максимально возможные, задержки минимальны, и это принимается за эталон скорости работы. Именно поэтому никто не заморачивается на то сколько файлов и каких и сколь сложно их обрабатывать.
При работе с сетями, все регрессирует в геометрической прогрессии, и потоки данных и особенно транзакции на их передачу которые вообще мало кто берет в расчет.
Если вы работаете с файлами на локальном диске, то самый медленный на сегодня на всем протяжении передачи данных от источника к процессору это HDD. А чтобы интернету достичь таких скоростей нужен интернет канал на всем протяжении от А до Я в 1Гб/с. что далеко не скоро появится у нас в распоряжении. Именно из-за этого все колом упирается в самое слабое звено, а в разных схемах и реализациях это звено разное.
Тесты предназначены только для оценки реальной скорости на пути от вашего компа до облачного хранилища, чтобы выявить слабое звено, а не то какой ширины у вас канал. Условно все привыкли считать что если есть такой сервис, то скорость к нему такая какой мы имеем интернет, на самом деле это совсем не так, а гораздо хуже. Я не собираюсь вычислять где именно слабое звено, это бесполезно, маршруты передачи данных в интернете неисповедимы, но по результатам мы будем знать какую скорость мы имеем в общей цепи от вас до сервера неизвестно где находящегося. Нужно знать только это.

В случае описаном Светланой на сколь я понял схема такая:
Десктоп работает с локальными файлами и не создает тормозов, точнее они минимальны и в расчет неберутся. Новые файлы из локального диска передаются в общее Гугл хранилице. Клиент из Украины его оттуда забирает на свой комп. Тоже самое происходит и на втором компе в офисе, от точно также забирает из Гугла к себе. Тоже самое происходит во всех направления сходящихся в одну точку Гугл хранилища.
Так вот, путь от первого компа к компу на Украине целиком и полностью зависит от интернета, и его можно оптимизировать только увеличением каналов с обоих сторон либо самой слабой стороны для выравнивания. Поэтому оптимизацию в этом направлении я не рассматриваю она и так оптимальна на данный момент.
А вот путь от первого компа в оффисе до второго компа в офисе лежит через тотже самый гугл. Соответственно имеющийся в оффисе канал имеет две нагрузки и его возможности в максимальной нагрузке половинятся, это раз. Один и тотже файл по пути от первого компа до гугла и обратно на второй проходит по интернет каналу дважды, соответственно пиковую нагрузку можно еще в два раза сокращять, это два.
Итого на кой хрен гонять файлы туда обратно внутри офиса через гугл. К томуже с увеличением персонала в офисе пиковые нагрузки на интернет будут возрастать все больше и больше, время будет тратиться все больше и больше.
Цель оптимизации: производить синхронизацию с гуглом только с одного компа, исключая паралельные и повторные потоки данных.
Можно сделать шару на одном компе и туда всем ходить со всех станций. Постепенно нагрузка на шару возрастет и на этом компе труднее станет работать. Без этой шары (комп выключили) работа офиса пролизуется.
Решение: установка дополнительного компа который будет выполнять функции шары. Что по сути дела является выделением отдельного компа в роли файл-сервера с синхронизацией на гугл. И тут уже пофигу будет это просто комп, мини сервер или NAS, функции теже самые.