​​Прочитал интересную серию статей Building A 'Mini' 100TB NAS, где человек в трёх частях рассказывает, как он себе домой NAS собирал и обновлял. Железо там хорошее для дома. Было интересно почитать.

Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.

Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.

Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:

/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными

Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в /etc/snapraid.conf:

parity /mnt/diskp/snapraid.parity
content /var/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

И после этого запускаете синхронизацию:

# snapraid sync

Данные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.

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

Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.

Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.

Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.

Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.

Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.

SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.

⇨ Сайт / Исходники

#fileserver #backup

Регулярно приходится настраивать NFS сервер для различных прикладных задач. Причём в основном не на постоянное использование, а временное. На практике именно по nfs достигается максимальная скорость копирования, быстрее чем по scp, ssh, smb или http.

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

Обычно всё хранение файлов под различные нужды делаю в разделе /mnt:

# mkdir /mnt/nfs
# chown nobody:nogroup /mnt/nfs

Устанавливаем пакет для nfs-server:

# apt install nfs-kernel-server

Добавляем в файл /etc/exports описание экспортируемой файловой системы только для ip адреса 10.20.1.56:

/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)

Для всей подсети просто добавляем маску:

/mnt/nfs 10.20.1.56/24(rw,all_squash,no_subtree_check,crossmnt)

Для нескольких IP адресов пишем их каждый в своей строке (так нагляднее, но можно и в одну писать):

/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)
/mnt/nfs 10.20.1.52(rw,all_squash,no_subtree_check,crossmnt)

Перезапускаем сервер

# systemctl restart nfs-server

Проверяем работу:

# systemctl status nfs-server

Для работы NFS сервера должен быть открыт TCP порт 2049. Если всё ок, переходим на клиент. Ставим туда необходимый пакет:

# apt install nfs-common

Проверяем, видит ли клиент что-то на сервере:

# showmount -e 10.20.1.36
Export list for 10.20.1.36:
/mnt/nfs 10.20.1.56

Всё в порядке, видим ресурс для нас. Монтируем его к себе:

# mkdir /mnt/nfs
# mount 10.20.1.36:/mnt/nfs /mnt/nfs

Проверяем:

# df -h | grep nfs
10.20.1.36:/mnt/nfs         48G 3.2G  43G  7% /mnt/nfs

Смотрим версию протокола. Желательно, чтобы работало по v4:

# mount -t nfs4
10.20.1.36:/ on /mnt/nfs type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.1.56,local_lock=none,addr=10.20.1.36)

Создаём файл:

# echo "test" > /mnt/nfs/testfile

При желании можно в fstab добавить на постоянку:

10.20.1.36:/mnt/nfs /mnt/nfs nfs4 defaults 0 0

Не забудьте в конце поставить переход на новую строку. Либо подключайте через systemd unit. В моей заметке есть пример с NFS.

Похожие короткие инструкции для настройки SMB сервера:
◽на базе python
◽на базе ядерного ksmbd

#fileserver #nfs

​​В операционных системах Windows традиционно есть некоторые сложности с использованием протокола NFS. Длительное время она его вообще штатно никак не поддерживала, приходилось использовать сторонний софт. Это объясняется в первую очередь тем, что для передачи файлов по сети у них есть свой протокол SMB. В какой-то момент, уже не помню, в какой точно версии, в Windows появился встроенный NFS клиент.

Установить его можно через Панель управления ⇨ Программы ⇨ Программы и компоненты ⇨ Включение и отключение компонентов Windows ⇨ Службы для NFS ⇨ Клиент для NFS.

Можно включить более простым и быстрым способом через Powershell:

> Enable-WindowsOptionalFeature -FeatureName ServicesForNFS-ClientOnly, ClientForNFS-Infrastructure -Online -NoRestart

Можно примонтировать диск с NFS сервера, к примеру, развёрнутого из этой заметки:

> mount -o anon \\10.20.1.36\mnt\nfs N:
N: успешно подключен к \\10.20.1.36\mnt\nfs
Команда успешно выполнена.
> N:
> dir
..........

Диск N появится в качестве сетевого. С ним можно работать к с обычным сетевым диском. Условно, как с обычным, так как работа под Windows с NFS сервером на Linux будет сопряжена с множеством нюансов и неудобств, связанных с правами доступа, кодировкой, чувствительности к регистру в названиях файлов на Linux. В общем случае использовать такой сценарий работы не рекомендуется. Для постоянной работы с Windows проще поднять SMB сервер на Linux.

Для разовых задач или для использования в скриптах можно воспользоваться каким-то альтернативным консольным клиентом. Например, nfsclient. Это небольшая программа на Go уровня курсовой работы студента. Код самой программы простой, но используются готовые библиотеки для работы с NFS.

Программа кроссплатформенная и не требует установки. Это небольшой консольный клиент, который поддерживает простые операции:

◽просмотр содержимого ресурса
◽скачивание, загрузка, удаление файлов
◽создание и удаление каталогов

Работает примерно так. Монтировать диск не нужно. Смотрим список файлов на nfs диске:

>.\nfsclient.exe 10.20.1.36:/mnt/nfs root:0:0 ls ./

Скачиваем файл syslog:

>.\nfsclient.exe 10.20.1.36:/mnt/nfs root:0:0 down ./syslog

Загружаем в корень диска файл file.txt:

>.\nfsclient.exe 10.20.1.36:/mnt/nfs root:0:0 up .\file.txt ./file.txt

Синтаксис простой, потому что команд не так много: ls/up/down/rm/mkdir/rmdir.

#nfs #fileserver #windows

​​Для редактирования и совместной работы с документами через браузер есть два наиболее популярных движка с открытым исходным кодом:

▪️ OnlyOffice
▪️ Collabora Online

Про #OnlyOffice я регулярно пишу, можно посмотреть материалы под соответствующим тэгом. Там же есть инструкции по быстрому запуску продукта. Решил то же самое подготовить по Collabora Online, чтобы можно было быстро их сравнить и выбрать то, что больше понравится.

Движок для редактирования документов работает в связке с каким-то другим продуктом по управлению файлами. Проще всего потестировать его в связке с ownCloud. Запускаем его:

# docker run -d -p 80:80 owncloud

Идём по IP адресу сервера http://10.20.1.36, создаём учётку админа и логинимся. В левом верхнем углу нажимаем на 3 полоски, раскрывая меню и переходим в раздел Market. Ставим приложение Collabora Online.

Переходим опять в консоль сервера и запускаем сервер collabora:

# docker run -t -d -p 9980:9980 -e "extra_params=--o:ssl.enable=false" collabora/code

Возвращаемся в веб интерфейс owncloud, переходим в Настройки ⇨ Администрирование ⇨ Дополнительно. В качестве адреса сервера Collabora Online указываем http://10.20.1.36:9980. На этом всё. Можно загружать документы и открывать их с помощью Collabora Online. У меня без каких-либо проблем сразу всё заработало по этой инструкции. Работает, кстати, эта связка довольно шустро. Мне понравилось. Погонял там с десяток своих документов и таблиц.

Редактор Collabora Online сильно отличается от Onlyoffice как внешним видом, так и архитектурой. Если у Onlyoffice обработка выполняется на клиенте, что нагружает его, но снимает нагрузку с сервера, то Collabora Online всё обрабатывает на сервере. Мне кажется, это скорее плохо, чем хорошо. Ресурсов сервера потребляет в разы больше, чем Onlyoffice. Но при таком подходе надёжнее работает совместное редактирование, так как реально оно происходит на сервере, а клиентам передаётся только картинка.

Интерфейс Onlyoffice больше похож на Excel, интуитивно с ним проще работать. Основные форматы - .docx, .xlsx, .pptx. Соответственно и совместимость с ними лучше. Collabora построена на базе LibreOffice, а он заметно отличается от Excel, так что переход будет более болезненный. Основные форматы - .odt, .ods, .odp. Майкрософтовские документы открывает хуже.

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

#docs #fileserver

Для построения распределённого файлового хранилища наиболее популярной и зрелой технологией является Ceph. Это программная объектная отказоустойчивая сеть хранения данных. Минимальное количество нод для построения кластера - три. При этом максимальное количество может исчисляться десятками и возможно сотнями. Ceph сложен и в установке, и в эксплуатации.

Компания Canonical, авторы Ubuntu, создали проект MicroCeph, который позволяет очень быстро и просто развернуть небольшой кластер Ceph. Для обучения или тестовых задач его можно развернуть даже на одной машине. MicroCeph по своей сути тот же Ceph, только уже преднастроенный и упакованный в пакет snap.

Покажу, как быстро развернуть кластер из трёх нод на базе виртуальных машин Ubuntu 24. У нас будут 3 идентичные виртуалки, в каждой по два диска: системный sda, чистый sdb под ceph. Все три ноды видят друг друга по именам node-1, node-2, node-3, которые добавлены им в файлы /etc/hosts.

Устанавливаем microceph и сразу запрещаем обновление на всех трёх нодах:

# snap install microceph
# snap refresh --hold microceph

Теперь на node-1 инициализируем кластер и создадим токены для добавления двух других:

# microceph cluster bootstrap
# microceph cluster add node-2
# microceph cluster add node-3

Идём на node-2 и node-3 и добавляем их в кластер, используя полученные выше токены:

# microceph cluster join <token node-2>
# microceph cluster join <token node-3>

На каждой ноде добавим диск sdb к хранилищу:

# microceph disk add /dev/sdb --wipe

Смотрим, что получилось:

# microceph status

MicroCeph deployment summary:
- node-1 (10.20.1.34)
 Services: mds, mgr, mon, osd
 Disks: 1
- node-2 (10.20.1.35)
 Services: mds, mgr, mon, osd
 Disks: 1
- node-3 (10.20.1.36)
 Services: mds, mgr, mon, osd
 Disks: 1

Дальше с кластером можно работать, как с традиционным ceph. Смотреть статус:

# ceph status

Активировать модуль статистики для Prometheus:

# ceph mgr module enable prometheus

Метрики появятся по адресу http://10.20.1.34:9283/metrics. Смотрим использование кластера:

# ceph df

Он пока пустой, без данных. Нет ни одного пула. Создадим пул с распределённой файловой системой cephfs:

# ceph osd pool create cephfs_meta
# ceph osd pool create cephfs_data
# ceph fs new newFs cephfs_meta cephfs_data

Смотрим список пулов:

# ceph fs ls
# rados lspools

Смотрим ключ пользователя admin, который создан автоматически:

# ceph auth get-key client.admin

Этот ключ нам нужен для того, чтобы получить доступ к файловой системе по сети. Я это показываю для теста. В проде так делать не надо. Надо создать отдельную директорию, создать для неё пользователя с правами к этой директории. И использовать его. Всё это подробно описано в моей статье на сайте про ceph:

⇨ Установка, настройка и эксплуатация Ceph

Теперь мы можем подключить эту файловую систему на любую машину Linux. Для этого туда надо установить пакет ceph-common:

# apt install ceph-common

Подключаем cephfs:

# mkdir /mnt/cephfs
# mount.ceph 10.20.1.34,10.20.1.35,10.20.1.36:/ /mnt/cephfs -o name=admin,secret='AQB8nRpn7MBLAxAANpLgc8UxrLhT487Tt9Y4DA=='

Теперь все созданные файлы в /mnt/cephfs будут автоматически размещаться в кластере. Их будет видно со всех клиентов, к которым подключен этот же пул.

Помимо распределённой файловой системы вы можете использовать ceph для создания RBD дисков, которые можно монтировать индивидуально каждому клиенту, в отличии от общей cephfs, которая одна на всех. Также можно создать совместимое с S3 хранилище с помощью отдельного компонента RADOS Gateway (RGW). Инструкций в сети много, так как продукт популярный. Можно самому во всём разобраться.

Документация и примеры эксплуатации MicroCeph описаны в документации продукта. Она краткая, ёмкая и легкая для восприятия. Там монтируют немного по-другому, передавая файлы ключей из директории /var/snap/microceph/current/conf. Но общий смысл тот же самый.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#ceph #fileserver

Существует очень простой способ объединить несколько различных дисков в единый логический раздел. Речь идёт именно о логическом объединении. То есть у вас могут быть два абсолютно любых хранилища, смонтированных в разные разделы. Например, /mnt/sda и /mnt/sdb. Вы можете объединить их в единый диск в новой точке монтирования /mnt/sdab. Объём двух разделов суммируется в новой точке монтирования. При этом файлы будут писаться в зависимости от настроек в оба исходных диска, а /mnt/sdab просто будет единое место, к которому можно обращаться для работы с файлами.

Сразу поясню, где это может пригодиться.

🔹Видеосервер с записями камер. Можно объединить разнородные хранилища в единую точку монтирования и указать её в настройках видеосервера.

🔹У меня не раз бывали ситуации, когда мне нужно было объединить в единый раздел несколько raid1 или raid10. Для этого я их объединял с помощью LVM. Бывает так, что у вас есть сервер с 4-мя дисками, но при этом они одинаковые парами, например 2 по 2TB и 2 по 3TB. Вы делаете 2 зеркала mdadm, а потом поверх него пускаете LVM. Получаете 5TB в одном разделе. В некоторых случаях удобнее и безопаснее обойтись без LVM, а сделать логическое объединение.

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

🔹Сервер для бэкапов, где допустимо логическое объединение дисков. А для бэкапов это часто допустимо.

Работает всё это на базе mergerfs. Покажу сразу на практике. Допустим, у нас есть 2 диска sda и sdb по 20G. Создаём на них по одному разделу и монтируем в систему:

# cfdisk /dev/sda
# cfdisk /dev/sdb
# lsblk
# mkfs.ext4 /dev/sda1
# mkfs.ext4 /dev/sdb1
# mkdir /mnt/sda
# mkdir /mnt/sdb
# mount /dev/sda1 /mnt/sda
# mount /dev/sdb1 /mnt/sdb
# df -h
/dev/sda1    20G  24K  19G  1% /mnt/sda1
/dev/sdb1    20G  24K  19G  1% /mnt/sdb1

Создали, примонтировали, убедились, что всё работает. Устанавливаем mergerfs и создаём общий диск:

# apt install mergerfs
# mkdir /mnt/sdbc
# mergerfs -o defaults,allow_other,category.create=mfs,moveonenospc=true,minfreespace=1G /mnt/sda1:/mnt/sdb1 /mnt/sdab
# df -h | grep sdab
a1:b1      40G  48K  38G  1% /mnt/sdab

Я добавил к параметрам по умолчанию следующие:
◽️allow_other - позволяет пользователям видеть файловую систему, иначе увидит только root.
◽️category.create=mfs - политика распределения файлов по дискам в зависимости от наличия там свободного места, где больше места, туда пишем.
◽️moveonenospc=true - при сбое записи если, к примеру, на устройстве не осталось места или превышена квота, файл будет записан в другое место.
◽️minfreespace=1G - если на устройстве меньше 1G места, туда больше не пишем.

С такими настройками если записывать на общее хранилище одинаковые по размеру файлы, то они будут по очереди записываться на разные диски. Их можно будет напрямую увидеть в /mnt/sda1 и /mnt/sdb1.

# dd if=/dev/zero of=/mnt/sdab/tempfile1 bs=1M count=1000
# dd if=/dev/zero of=/mnt/sdab/tempfile2 bs=1M count=1000
# ls /mnt/sdab
tempfile1 tempfile2
# ls /mnt/sda1
tempfile2
# ls /mnt/sdb1
tempfile1

В репозитории описаны все настройки и возможные политики записи. Они могут быть применены к каждому диску индивидуально. Например, какое-то хранилище может быть подключено только для чтения, на какое-то перестаём писать, когда там остаётся свободно 10G, записываем данные последовательно, заполняя диски по очереди и т.д.

Общее хранилище можно подключать через fstab или systemd-mount. Примеры есть в репозитории.

Полезный прикладной софт. Работает просто, решает конкретную задачу.

⇨ 🌐 Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#fileserver

Я уже как-то рассказывал про утилиту sshfs, которая позволяет монтировать удалённую файловую систему через SSH. То есть просто монтируете сетевой диск, используя только SSH соединение. Это не очень быстро, так как подключение выполняется в пространстве пользователя, да и в целом по SSH не очень быстрые соединения. Но для некоторых задач это бывает удобно. Доступ по SSH есть практически всегда.

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

Ставим sshfs:

# apt install sshfs

Генерируем и копируем на удалённую машину ключ:

# ssh-keygen -t ed25519
# ssh-copy-id root@10.20.1.6

Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.

Всё готово, монтируем д иректорию /etc/letsencrypt с сервера 10.20.1.6 к себе в /mnt/letsencrypt:

# sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt

Проверяем:

# df -h | grep 10.20.1.6
root@10.20.1.6:/etc/letsencrypt  20G 1.8G  17G 10% /mnt/letsencrypt

Размонтировать можно вот так:

# fusermount -u /mnt/letsencrypt

Создаём службу systemd:

# systemctl edit --force --full sshfs.service

[Unit]
Description=Mount sshfs
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt
ExecStop=fusermount -u /mnt/letsencrypt

[Install]
WantedBy=multi-user.target

Сохраняем, запускаем, добавляем в автозагрузку:

# systemctl start sshfs.service
# systemctl enable sshfs.service

Если хотим отмонтировать, то просто останавливаем:

# systemctl stop sshfs.service

Я показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры

User=sftp-user
Group=sftp-user

Можно в systemd указать пользователя, под которым всё это будет монтироваться.

Способ подключения дисков через sshfs костыльный, но вполне рабочий. Пользоваться можно. Если есть возможность настроить nfs или smb, с ними будет лучше. Но, например, конкретно для монтирования директории с сертификатами, разницы никакой нет. Сразу подчеркну, что эту задачу можно решать и по-другому. Например, хуками и копированием сертификатов на целевой хост. Решения задачи может быть много. Я показал один из них.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#ssh #fileserver