ESXi Home Server AIO: Часть 4. Настройка Nas4Free.

   Хост ESXi и машина N4F с пробросом контроллера созданы и запущены. Сделаны необходимые настройки операционной системы этой машины для работы в виртуализованной среде, корректировка параметров ZFS для использования всей выделенной памяти. Добавлены диски. Настало время сборки их в массивы и запуска необходимых сервисов виртуального хранилища.

   Снова немного о выборе железа и о том, почему пулов два.
   Изначально жесткие диски приобретались под вариант массива RAIDZ1 как наиболее подходящий (для меня) компромисс отказоустойчивости и накладных потерь емкости. Влияние на выбор моделей дисков оказало наличие посадочных мест в корпусе и их показатели по шуму и энергопотреблению. Корпус формата SFF InWin BL641 (с замененным блоком питания) идеально влезает в выделенное для него место и имеет 3 места под винты 3.5" и 1 место 5.25", куда встала корзина на 4 винта 2.5" от китайцев. В итоге в корпус влезло 2 массива: POOL-BIG (3х3.5") и POOL-SMALL (3x2.5"). В оставшееся место 2.5" встал SSD для local storage.

   Создание массива состоит из нескольких шагов: форматирование винтов как ZFS storage pool device, объединение группы из 3 дисков в vDev типа Single-parity RAID-Z (если диски имеют 4К сектора, как в моем случае, отмечаем Enable Advanced Format) и создание на основе этого vDev пула. Для второй группы из 3 дисков создается свой vDev и свой пул.

   Все винты моего хранилища имеют 4K сектора, с которыми FreeBSD по-умолчанию работает через программную прослойку GEOM, что можно заметить сразу после создания пула:

  pool: POOL-BIG
 state: ONLINE
  scan: none requested
config:

 NAME        STATE     READ WRITE CKSUM
 POOL-BIG    ONLINE       0     0     0
   raidz1-0  ONLINE       0     0     0
     da4.nop     ONLINE       0     0     0
     da5.nop     ONLINE       0     0     0
     da6.nop     ONLINE       0     0     0

errors: No known data errors

   Как видно, пул создан не на физических дисках, а на устройствах .nop, что может вызвать проблемы при замене диска в пуле. Пишут также, что эта прослойка увеличивает время доступа для дисков. Чуть больше об этом можно почитать тут.

Избавляемся от прослойки:

zpool export POOL-BIG
gnop destroy /dev/da4.nop /dev/da5.nop /dev/da6.nop
zpool import POOL-BIG

Все. Смотрим на состояние пула после операции:

pool: POOL-BIG
 state: ONLINE
  scan: none requested
config:

 NAME        STATE     READ WRITE CKSUM
 POOL-BIG    ONLINE       0     0     0
   raidz1-0  ONLINE       0     0     0
     da4     ONLINE       0     0     0
     da5     ONLINE       0     0     0
     da6     ONLINE       0     0     0

errors: No known data errors

Со вторым пулом поступаем аналогично.

   В принципе, можно работать: насоздавать на пулах папки, залить данные из резервных копий, что были сделаны перед переездом. Но для удобства управления стоит воспользоваться датасетами (dataset). Это, по сути, отдельные файловые системы поверх общего пула, обладающие собственными наборами характеристик (владелец и права доступа, квоты, использование компрессии и дедупликации). Для отдельных датасетов можно включить автоснапшоты. Довольно удобно для универсального хранилища с разными типами и важностью данных.

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

   Заводим новую группу и пользователей - будущих владельцев:

   Теперь можно создавать датасеты с требуемым набором параметров и с ограничениями доступа:

   Для большинства датасетов "файлопомойки" (видео, музыка, фото) оставил настройки параметров по-умолчанию. Но в случае служебной шары, отдаваемой по NFS обратно серверу ESXi для тестовых виртуалок выяснилось, что необходима установка параметра Sync в значение Disabled. Это значительно снизило нагрузку на процессор машины N4F и уменьшило задержки при доступе к этой шаре со стороны сидящих на ней машин.

    Созданные датасеты теперь можно шарить. 

   Вся домашняя инфраструктура построена на виндовом окружении, потому основной тип шары: CIFS/SMB. Из настроек сервиса стоит отметить тип аутентификации Local User (анонимный доступ запрещен), протокол SMB2 (использую Windows7 и Server2008R2). Разницы между включением/выключением Asynchronous I/O не заметил. Оставил отключенным. При создании шары отключил параметр Enable guest access и включил Inherit permissions.  Включенный параметр Shadow Copy позволит видеть и откатываться к предыдущим версиям файла при использовании автоснапшотов ZFS через встроенные средства Volume Shadow Copy Service (VSS) Windows. Крайне полезная  и удобно интегрированная в виндовый проводник (закладка "предыдущие версии" свойств файла) опция. Обязательно выставляем.

   Сервис NFS используется у меня для организации сетевого хранилища виртуальных машин ESXi и доступа к дистрибутивам при их создании. Кроме упомянутого отключения Sync дополнительных настроек не требуется (да их и нет). При создании шары NFS достаточно указать Authorised network и запретить маппинг всех пользователей в рута.

   Стоит упомянуть сервис SSH, включаемый как правило на этапе первоначальной настройки N4F. С целью повышения безопасности не стоит включать параметр Permit root login. Правильнее будет завести дополнительного пользователя с доступом в шелл  и включить его в группу Wheel для разрешения повышения его привилегий до рута.

   Сервис UPS, реализованный в N4F через nut, с моим APC ES525VA не подружился. И не у меня одного. Буду мониторить через usb, проброшенный в сервер вцентра.

   Из аппаратного мониторинга температуры в виртуализованной среде остался только SMART дисков, и глупо было бы его не использовать. Позже буду выяснять, можно ли их отдавать по SNMP, а пока добавил простое оповещение по почте при превышении заданных порогов. Для этого использовал специально созданный аккаунт гуглопочты, параметры которого добавил в System|Advanced|Email по этому примеру. Затем в разделе Disks|Management|S.M.A.R.T. включил мониторинг с периодичностью раз в полчаса (1800 сек.) и порогами в 40°C и 45°C для информационного и критического состояний. Репорт шлю себе на основную почту, которой пользуюсь постоянно.

   С сервисом BitTorrent пришлось повозиться. Изначально, сценарий его использования предполагает закачку в строго заданную и создаваемую заранее папку Download directory, принадлежащую пользователю transmission, под которым и крутится демон. Если предполагается хранить скаченное в другом месте, то туда это придется затем переложить вручную (ну или скриптом). Наверное это правильно, безопасно и вообще *nix-way, но это неудобно. Хочется сразу скачивать в финальное место назначения. Но это невозможно из-за нарушений прав доступа. В угоду удобству, но ценой безопасности эту проблему часто решают давая полные права для всех на все монтированные диски. Более безопасным выглядит другой способ: посадить пользователя transmission в группу владельцев датасетов, созданную выше, таким образом дав ему разрешение писать в произвольное место. 

   Редактирование свойств этого пользователя возможно через правку конфига сервера: загружаем в эдиторе /cf/conf/config.xml, в разделе <nas4free><system><usermanagement> ищем блок <user> для пользователя transmission и меняем параметр <group> со значения 50 на GID группы владельцев (в моем случае это был 1001). Сохраняем. 

   Теперь создаем директории для работы сервиса и задаем права доступа:

mkdir /mnt/POOL-SMALL/.transmission/
mkdir /mnt/POOL-SMALL/.transmission/config/
chown -R transmission:transmission /mnt/POOL-SMALL/.transmission/
chmod -R 770 /mnt/POOL-SMALL/.transmission/

   Переходим в Services|BitTorrent и выставляем:

   Включаем WebGUI, задаем пароль, пользователя и порт для подключения. Эти же параметры вбиваем в настройках соединения Transmission Remote GUI, а также прописываем сопоставление путей всех доступных пользователю ресурсов. Например:

/mnt/POOL-BIG/Downloads=\\адрес_сервера\Downloads
/mnt/POOL-BIG/Films=\\адрес_сервера\Films 
/mnt/POOL-SMALL/Music=\\адрес_сервера\Music

   Идея тут в том, что при выборе места закачки пользователь указывает одну из доступных ему шар, а клиент Transmission Remote GUI переводит это в путь, понятный серверу.

   Все. Теперь пользователь волен выбирать место закачки файла. Владельцем файла правда будет пользователь transmission, но это уже ни на что не влияет, даже удобно: можно узнать какие именно файлы были скачаны через торренты.

   Дальше думаю надо написать про jails, уж больно интересная штука.