Моя сборка NAS с открытым исходным кодом (на основе ZFS)

Мой первый NAS появился у меня в 2016 году, это DS215J от Synology. Но долгое время я не использовал его так часто, потому что у меня не было много данных, и большинство из них находилось в облаке.

До недавнего времени я начал хранить в NAS некоторые большие файлы, поэтому решил сделать апгрейд. Но Synology имеет очень низкий коэффициент рентабельности, и мне удалось построить маршрутизатор с ванильным Linux в прошлом году, поэтому я решил сделать NAS, надеюсь, он сможет удовлетворить мои потребности в хранении данных в течение следующих 10 лет.

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

Отказ от ответственности: я не уделял много внимания совместимости и переносимости, поэтому вы, вероятно, не сможете запустить его напрямую, только для справки.

Файловая система

Файловая система — самая важная часть NAS. Проведя не так много исследований, я обнаружил, что ZFS, вероятно, является файловой системой, которая в настоящее время прилагает больше всего усилий для обеспечения надежности данных.

ZFS — это файловая система, а также менеджер RAID, поэтому у нее есть некоторые особенности:

  • ZFS вычисляет контрольную сумму для каждого блока и периодически сканирует весь диск, восстанавливая его после подмены байтов космическими лучами.
  • Вы можете указать некоторые каталоги для хранения дополнительных копий в дополнение к конфигурации RAID. Это позволит вам восстановить данные даже в случае поломки RAID.

ZFS также поддерживает шифрование, сжатие и дедупликацию данных. Эти функции работают продуманно и не мешают друг другу. Все эти функции настраиваются на уровне каталогов (наборов данных) и могут быть изменены в любое время (применяются только к новым данным).

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

Аппаратное обеспечение

У меня не так много знаний об аппаратном обеспечении, поэтому я выбрал MicroServer Gen10 от HPE, это микросервер с 4 отсеками, использующий процессор AMD X3421, память 8G ECC, стандартное аппаратное обеспечение x86. Я думаю, что это может максимально уменьшить проблемы с аппаратным обеспечением.

Я установил NVME SSD в слот PCI-E с помощью карты-адаптера, использую для системного раздела и кэша чтения ZFS (L2ARC, но значительный эффект будет позже), диски с данными временно использую старые, буду обновлять их до 4T. Здесь следует отметить, что ZFS не может изменять конфигурацию raidz, поэтому необходимо настроить достаточное количество дисков на начальном этапе, а затем обновить их емкость позже. На самом деле, я подключил USB жесткий диск, чтобы удовлетворить количество.

ZFS

Я выбрал конфигурацию raidz (RAID5), потому что у меня есть 4 диска, один из них — диск четности. Если я увеличу их до 4T, я получу 12T реальной емкости.

root@infinity:~# zpool status
  pool: storage
 state: ONLINE
config:
    NAME                                 STATE     READ WRITE CKSUM
    storage                              ONLINE       0     0     0
      raidz1-0                           ONLINE       0     0     0
        sda                              ONLINE       0     0     0
        sdb                              ONLINE       0     0     0
        sdc                              ONLINE       0     0     0
        sdd                              ONLINE       0     0     0
    cache
      nvme0n1p4                          ONLINE       0     0     0

root@infinity:~# zpool list
NAME      SIZE  ALLOC   FREE  CKPOINT   FRAG    CAP  DEDUP    HEALTH
storage  7.27T  3.52T  3.75T        -    10%    48%  1.00x    ONLINE
Вход в полноэкранный режим Выход из полноэкранного режима

Люди считают, что RAID5 имеет высокий риск потери данных при восстановлении, например, второй диск сломался во время замены первого, или данные сгнили, что привело к сбою восстановления. Однако ZFS будет периодически проверять целостность данных, а количество и емкость дисков продумываются синтетически, поэтому я считаю риск приемлемым. И в последнее время я буду прикрывать свое резервное копирование за пределами сайта.

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

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

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

Служба хранения данных

Интересный факт: SMB — самый популярный протокол обмена файлами, все основные операционные системы имеют встроенную поддержку этого протокола. CIFS — это версия реализации SMB от Microsoft (Windows), а Samba — это другая реализация SMB, которую я буду использовать далее.

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

# Use a placeholder in `path` to provide a split home directory for every user
# Use user groups in `valid users` to control accessible users
[Home]
path = /storage/private/homes/%U
writeable = yes
valid users = @staff

# Samba creates files as login user by default, since NextCloud is running as www-data, we need to override the file user by `force user`
[NextCloud]
path = /storage/nextcloud/data/%U/files
writeable = yes
valid users = @staff
force user = www-data

# Those settings make macOS's Time Machine work through SMB
# See https://www.reddit.com/r/homelab/comments/83vkaz/howto_make_time_machine_backups_on_a_samba/
[TimeMachine]
path = /storage/backups/timemachines/%U
writable = yes
valid users = @staff
durable handles = yes
kernel oplocks = no
kernel share modes = no
posix locking = no
vfs objects = catia fruit streams_xattr
ea support = yes
inherit acls = yes
fruit:time machine = yes

# For shared folder, use `force group` to override the group of files, and use `create mask` to override the permission of files
[VideoWorks]
path = /storage/shares/VideoWorks
writeable = yes
valid users = @staff
force group = staff
create mask = 0775

# Only allowed the specific group to write, enable guests to read
[Resources]
path = /storage/public/Resources
guest ok = yes
write list = @staff
force group = +staff
create mask = 0775
Войти в полноэкранный режим Выход из полноэкранного режима

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

root@infinity:~# zfs list
NAME                USED  AVAIL     REFER  MOUNTPOINT
storage            2.27T   286G      169K  /storage
storage/backups     793G   286G      766G  /storage/backups
storage/db          741M   286G      339M  /storage/db
storage/nextcloud   207G   286G      207G  /storage/nextcloud
storage/private    62.2G   286G     62.2G  /storage/private
storage/public      648G   286G      613G  /storage/public
storage/shares      615G   286G      609G  /storage/shares
Войти в полноэкранный режим Выход из полноэкранного режима

Приложения

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

Все остальные приложения работают в Docker и управляются docker-compose, поэтому мы можем изолировать окружения друг от друга и повысить стабильность хоста, процессы установки, обновления и удаления также очень просты.

Наиболее важным из них является NextCloud, который представляет собой приложение для хранения файлов с открытым исходным кодом. NextCloud имеет довольно приятное приложение для iOS и имеет некоторую интеграцию с системой, например, синхронизация LivePhoto корректна или доступна в приложении «Файлы».

NextCloud будет читать или записывать файлы непосредственно в файловую систему на стороне сервера, а не хранить файлы в базе данных. Это означает, что к каталогу хранения NextCloud можно получить доступ по SMB, что очень удобно (но требует запуска cronjob для обновления метаданных в базе данных NextCloud).

Я также запускаю некоторые другие приложения в Docker:

  • Miniflux, сервер для чтения RSS, поддерживает большинство RSS-ридеров через Fever API.
  • Bitwarden (не официальная версия), менеджер паролей, предоставляет расширения для браузеров и клиенты на всех платформах.
  • Transmission, клиент BitTorrent, предоставляет веб-интерфейс для управления загрузками.

Публичный доступ

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

Обычный способ — использовать DDNS (динамический DNS) для преобразования домена в IP домашней сети, но для этого необходимо, чтобы домашняя сеть имела публичный IP, а провайдер разрешил предоставлять веб-сервис через 80 или 443 порт. Я не хочу полагаться на это, поэтому я использую frp в качестве обратного прокси. Если у вас есть публичный IP, вы можете использовать DDNS, он не требует сервера ретрансляции и имеет более высокую скорость.

Чтобы NextCloud имел фиксированный адрес (например, https://nextcloud.example.com), я разрешаю домен на маршрутизаторе отдельно: разрешаю на частный IP NAS внутри дома; разрешаю на сервер ретрансляции вне дома. Оба случая передаются по SSL (от Let’s Encrypt), поэтому не нужно беспокоиться о конфиденциальности на сервере ретрансляции.

Хотя мне не нужно набирать VPN перед доступом к NAS снаружи, но выставлять NextCloud в публичной сети небезопасно. Некоторые люди уже просят NextCloud добавить поддержку аутентификации сертификата на стороне клиента в их приложение, я тоже очень заинтересован в этой функции, она повысит безопасность доступа к публичной сети.

Я также установил WireGuard на свой NAS, это VPN-модуль, встроенный в Linux, также имеющий доступ к публичной сети через frp. Я могу получить доступ к другим сервисам, таким как SMB, SSH и Netdata через WireGuard вне дома.

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

Резервное копирование и целостность данных

В дополнение к raidz я настроил cronjob, который создает снимок каждый день, и написал сценарий для имитации Time Machine: сохранять ежедневные резервные копии в течение одной недели; сохранять резервные копии каждую неделю в течение одного месяца; сохранять резервные копии каждый месяц в течение одного года и каждый год.

root@infinity:~# zfs list storage/nextcloud -t snapshot
NAME                           USED  AVAIL     REFER  MOUNTPOINT
storage/nextcloud@2020-09-05  83.9M      -      182G  -
storage/nextcloud@2020-09-15  35.2M      -      207G  -
storage/nextcloud@2020-09-21  30.2M      -      207G  -
storage/nextcloud@2020-09-23  29.7M      -      207G  -
storage/nextcloud@2020-09-26  29.3M      -      207G  -
storage/nextcloud@2020-09-27  28.2M      -      207G  -
storage/nextcloud@2020-09-28  28.2M      -      207G  -
storage/nextcloud@2020-09-29  29.1M      -      207G  -
storage/nextcloud@2020-09-30  33.5M      -      207G  -
Вход в полноэкранный режим Выход из полноэкранного режима

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

И еще один cronjob выполняет резервное копирование на Backblaze B2 в качестве внесетевого резервного копирования с помощью restic. Backblaze B2 — это недорогое объектное хранилище, и это хороший выбор для резервного копирования. restic — это инструмент инкрементного резервного копирования, который также поддерживает шифрование. По соображениям стоимости, резервное копирование вне офиса включает только данные, созданные мной, не включая каталоги public и backups.

Я также подумал о том, чтобы запустить систему ZFS удаленно в качестве резервного копирования, zfs send и zfs recv поддерживают передачу снимка через двоичный поток — не нужно устанавливать никаких других программ, просто используйте оператор pipe оболочки shell для перенаправления двоичного потока команде ssh. Эта идея очень хороша с технической точки зрения, но я отказываюсь от нее, потому что цена блочного хранилища в 10 раз выше, чем объектного.

Рассчитайте стоимость

Мой бюджет на аппаратное обеспечение не очень ограничен, если заменить его некоторыми экономичными деталями, стоимость будет намного ниже:

  • Сервер (материнская плата, процессор, оперативная память, системный диск) — 3500 CNY (521 USD)
  • Жесткий диск (4 x 4T) — 2200 CNY (327 USD).

Если я смогу использовать его в течение 10 лет:

  • Аппаратное обеспечение — 570 CNY каждый год (84 USD)
  • Электричество (35W) — 110 CNY каждый год (16 USD)
  • Релейный сервер — 110 CNY каждый год (14 USD)
  • Внесетевое резервное копирование — 415 CNY в год за 1T данных (в пересчете на использование, 61 USD).

Подводя итог, можно сказать, что ежегодные затраты на 12 Тб емкости составляют 1195 CNY (177 USD), в пересчете на 8 CNY (1,2 USD) / 1 Тб, если исключить удаленный доступ и резервное копирование вне офиса, то всего 5 CNY (0,7 USD) / 1 Тб.

Почему самостоятельный хостинг

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

Кроме того, техническая причина заключается в том, что NAS внутри домашней сети может поддерживать онлайн-редактирование по SMB, например, загрузку медиафайлов непосредственно с NAS, даже размещение всего проекта на NAS. Облачные сервисы не поддерживают SMB, а если и поддерживают, то задержка неприемлема.

И мы должны поговорить о стоимости, здесь мы рассматриваем только те сервисы, которые тарифицируются по объему хранилища. iCloud, Google Drive и Dropbox имеют схожие тарифные планы, если ваше хранилище превышает 200 Гб (около $3 в месяц), то следующий план переходит к 2 Тб (около $10 в месяц), без промежуточных планов. В настоящее время облачный сервис уже не имеет преимущества, позволяющего платить по мере использования, поэтому самое время обратиться к самостоятельному хостингу, вы сможете вернуть свои инвестиции за 2-3 года.

В конце концов, самое главное — это ваш интерес, вам придется принять много решений, столкнуться со многими трудностями в процессе DIY, и, наконец, создать уникальное решение для самостоятельного хостинга. Это стоит того, если вы можете наслаждаться процессом, в противном случае это будет пустой тратой времени.

Оцените статью
Procodings.ru
Добавить комментарий