athacker

Вариант хранения всех файлов в облаке с монтированием локально по WebDAV вам не подойдёт? Винда умеет WebDAV-хранилища монтировать как локальный диск.

Горизонтально масштабируемые хранилища: Ceph, GlusterFS, Microsoft Scale-Out File server, Veritas Access.

1) фольгированная витая пара -- только между этажами. С обязательным заземлением, иначе толку от неё не будет. В остальном можно разводить обычной UTP без экранирования;

2) Коммутаторы должны быть на каждом этаже. Не хватает 16 портов -- ставьте 24-портовые. Не хватает 24-портовых -- ставьте по 48. Но реально жить будет проще, если у вас коммутаторы доступа будут стоять на каждом этаже. Потому что тогда вам можно будет купить менее ёмкие коммутаторы агрегации и поставить их в серверной. Менее ёмкие -- потому что туда не все на свете компы будут сведены, а только коммутаторы доступа. Подключение каждого коммутатора доступа к агрегации -- двумя линками, в ether-channel, для резервирования;

3) Citrix XenServer... Ну такое... Посмотрите на картинку и найдите там XenServer:


4) "SSD в рейд-массивах не дает преимуществ" -- шта? О_о Собирать SSD в RAID10 -- несколько расточительно. Хотя, конечно, если у вас бюджеты не ограничены... Я бы собирал массив так -- как можно бОльшее количество дисков небольшого объёма, которые бы уже собирал в RAID6 или RAID60 (в зависимости от количества дисков и потребных объёмов). Вот шпиндельные диски -- их имеет смысл в RAID10 собирать, т. к. больно медленные. Но подход тот же самый -- диски меньшего объёма, но в большем количестве. В последние годы я постоянно наблюдаю ситуации -- есть до фига объёмов, но не хватает производительности. Обратное -- производительность есть, но мало объёмов, пока не попадалось. Отсюда рекомендация брать диски поменьше, но количеством побольше. Хотя всё зависит от задач, конечно. И от бюджетов.

Да, и "RAID-массив в стойку" не поставить. Поставить можно железку. Какую-то. Промышленную СХД, например. Или самосборное хранилище (считай, обычный сервер, с линукс или FreeBSD на борту, настроенный на отдачу объёмов по какому-то storage-протоколу). Или корзину DAS. Или NAS. Перечислены в порядке предпочтения. Опять-таки, всё зависит от бюджета.

5) ИБП нужно брать с запасом не 50%, а 100% или даже 200%. Потому что когда вы докинете ещё серверов, то ваши 50% будут съедены моментом. Или когда у вас нагрузка поднимется, то тоже начнёте упираться в потолок мощности ИБП. А то, что нагрузка будет расти и сервера придётся добавлять -- это к бабке не ходи. Поэтому брать нужно с большим запасом, не менее 100%. Как вариант -- брать ИБП, к которым можно подключать внешние блоки батарей. Но мощность ИБП всё равно должен иметь с запасом не менее 100%.

6) Датчики влажности, температуры без регистрации и SMS и возможность отправки SMS-сообщений лучше реализовать с помощью устройств типа UniPing server v3/SMS. Датчиков там отдельно можно докупить всеразличных, вплоть до инфракрасных управлялок для кондиционеров в серверной.

7) RAID-ы в виртуалках -- это бред, конечно же. Достаточно обеспечить отказоусточивое дисковое хранилище. Лучше всего с отказоустойчивостью дела обстоят у промышленных СХД, конечно же. HPE MSA, Dell MF -- вот это вот всё.

8) Правила распределения сервисов по виртуалкам очень простое -- один выстрел -- один труп сервис -- одна машина. Т. е. под почтовый сервер -- одна виртуалка. Под DNS -- ещё машина. Даже две. Под контроллеры доменов -- две виртуалки (минимум). Под DHCP -- ещё машина.

XXX) Если заказчик хочет, чтобы всё работало хорошо -- то лучше, конечно, пригласить профессионалов. Потому как судя по вашим вопросам, вы пока ещё таковым не являетесь. Если же он готов терпеть и пожинать плоды экспериментов в течение довольно долгого времени -- тогда конечно.

XXX+1) Да, и про резервное копирование не забудьте. Чем бэкапить, и куда складывать. Hint: складывать на ту же хранилку, на которой виртуалки работают -- моветон и чревато печальными последствиями.

Начать с разъяснительной работы, что хранение документов на локальных дисках рабочих станций -- есть зло и большой риск для документа, т. к. железо рабочих станций по определению ненадёжно, а документы, хранящиеся на рабочей станции трудно бэкапить. Заручиться поддержкой руководства в последующих действиях

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

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

0. При работе по FTP файлы придётся скачивать локально ;-)
1. Неясно, с какими файлами Вы собираетесь работать.
2. OwnCloud -- тормозит и полон уязвимостей. Лучше использовать Seafile. В коммерческой версии, насколько я помню, есть даже редакторы офисных форматов.

как настроить доступ с персонального ПК

Копать в сторону организации VPN для сотрудников.

Всё зависит от планируемой нагрузки на этот сервер. Если вы его в интернет собираетесь выставлять, то с лихвой хватит Core2Duo типа T6600 и 2-4 гига оперативы. И дисковый контроллер не обязателен для дома -- достаточно найти материнку, где SATA-портов побольше. А отказоустойчивость можно и на софтверном уровне обеспечить, например, используя дистрибутив FreeNAS, который использует ZFS.

В принципе, если вы и в локалке по гигабиту собираетесь файлы гонять, то Core2Duo и 4 гига оперативы всё равно хватит с избытком :-) Да, и использовать RAID для увеличения IOPS на диски нет никакого смысла. У вас всё равно узким местом будут не диски, а сеть.

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

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

Интерфейс взаимодействия с объектными хранилищами -- да, запросы по HTTP/HTTPS. С точки зрения приложений это куда удобнее, чем парсить файловую систему или работать с её драйвером.

Плюсую за вариант, предложенный sanrega
ZFS raidz решает эту задачу. Если очень боитесь -- можно даже raidz2 (условиный аналог RAID6). Если совсем-совсем страшно -- ну, есть ещё raidz3 :-)

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

Это что касается гарантии неизменности. Что касается гарантий доступности -- всё зависит от того, какие конкретно вам гарантии нужны, и сколько денег вы можете на это потратить.

Microsoft Storage Spaces Direct.

Забей. В домашнем компе использовать можно без ограничений. Про надёжность -- в среднем, серверные диски лучше оттестированы, и вероятность того, что они проработают долго, выше. Заточенность под NAS/RAID означает, в случае линейки Red, что там в микропрограмме уменьшены таймауты при сбоях, чтобы диск не залипал на попытке прочитать сбойный сектор, а отдавал контроллеру ошибку быстрее.

А также там модифицирован алгоритм позиционирования голов для работы в условиях вибрации -- когда пачка дисков в одной корзине, корзина вибрирует (и диски, соответственно, тоже), и поэтому точно позиционировать головку сложнее. ХЗ, как это WD Red решает на софтверном уровне, но такое у них заявлено.

Вопрос: можно ли пользоваться owncloud без https и других средств безопасности?
Ответ: Не нужно.

:-)

Вы бы написали, чем вас не устраивает текущее решение, и чего хотите достичь. Какова цель перехода на БД? В чём разница -- искать файлы по каталогам, или искать файлы в интерфейсе какой-нибудь софтины, если и то и другое будет выглядеть как определённым образом структурированные папки?

А вы что расширять хотите? Объёмы, производительность, количество подключенных хостов?

Low range модели: HP MSA 2040 или IBM Storwize V3700, Huawei OceanStor V1, Dell PowerVault MD34xx

Если встаёт вопрос ограниченности бюджета, то лучше самосбор. FreeBSD+ZFS, плюс SSD-диск под L2ARC-кэш. Хотя это зависит от типа нагрузки, если будет в основном запись данных и мало чтения, то можно обойтись и без L2ARC.