Введение
Поскольку установленная TrueNAS Core (ранее FreeNAS) занимает практически буквально пару гигабайт, то возникает естественное желание задействовать драгоценное место на SSD (а, как мы знаем, лучше даже двух – для зеркалирования). В реальности использовать флешку для загрузки ОС на постоянной основе конечно же не стоит – об этом нас предупреждает установщик, да и вообще. Кстати про реальность – кажется с флешками на 8 гигов (и менее) возможны проблемы, так что лучше с запасом взять на 16 (что мы виртуально и сделаем).
Статья основывается на темах форума по TrueNAS – HOWTO: setup a pair of larger SSDs for boot pool and data (как настроить пару больших SSD для загрузочного пула и данных) и How to setup FreeNAS on a (partitioned) single SSD with boot and jails (как установить FreeNAS на одиночный SSD с разбиением на загрузку и клетки), а также пары статей по FreeBSD как таковой (напомню, что «под капотом» у TrueNAS ни что иное, как именно эта операционная система) - FreeBSD and UEFI Boot (FreeBSD и загрузка через UEFI) и Установка FreeBSD (как ни странно на русском в отличие от всех остальных).
Последние две статьи намекают на то, что в примере мы будем использовать именно загрузку в режиме UEFI, а не BIOS, поскольку полюбившийся мне VirtualBox позволяет загружаться с виртуальных USB и NVMe только таким образом. Кстати будьте внимательны – в интернете (и в частности второй теме форума) чаще подразумевается «старомодный» режим BIOS’а.
TL;DR
Что-то статья получилась весьма и весьма длинной, поэтому если вам не слишком интересно читать про развертывание виртуальной машины, установку TureNAS под UEFI и подробное объяснение, откуда что берется, то можно сразу перейти к разделу «Если применяются два SSD» – там без лишних слов приводится сводка команд. Также хотелось бы анонсировать задачу синхронизации в конце.
Создание виртуальной машины
При написании статьи использовался VirtualBox 6.1.20 с установленным набором расширений – это важно, поскольку именно через этот набор реализуются контроллеры USB 2.0/3.0 и NVMe.
Я предпочитаю «экспертные» режимы. Начало создания виртуальной машины стандартное: тип – BSD, версия FreeBSD (x64), объем памяти не менее 8192 MB.
На втором шаге создается основной диск ВМ. По умолчанию предлагается 16 гигабайт, но давайте поставим 120 и в дальнейшем будем рассматривать этот диск как SSD на NVMe. При «динамическом» формате хранения можно не переживать за место на реальном диске (хоста).
Переходим в настройки вновь созданной машины, вкладку «Система». В настройке материнской платы я обычно меняю чипсет на ICH9, а также включаю «Часы в системе UTC». В обязательном порядке включаем EFI.
Вкладку «Дисплей» пропускаем, переходим к «Носителям» – здесь-то и начинается самое интересное. По умолчанию созданный диск подключается к IDE контроллеру. Добавим NVMe (PCIe) контроллер, перенесем наш диск в него и включим режим твердотельного накопителя.
Добавим контроллер USB и создадим для него диск на 16 гигабайт, на сей раз для имитации «маленькой» флешки для первоначальной установки. Можно установить флаг «С горячей заменой», хотя влияет это наверное только на порядок следования дисков в перечне устройств. Для определенности – я этот флаг взвел.
Добавляем контроллер SCSI или SATA, давайте на сей раз остановимся на AHCI (SATA) как более близкому к «потребительской» платформе. Как обычно, добавляем два или три диска, чтобы TrueNAS не ругался. Объем для наглядности опять же поставим какой-то отличающийся от предыдущих двух, главное чтобы он был одинаковым для всех двух/трех. Сделал три по 500, чтобы мало не показалось.
Аудио отключаем и переходим в «Сеть». Воспользуемся «неразборчивым» режимом сетевого моста, чтобы работал DHCP для клеток (которые jail, напомню, что это «легковесная» виртуализация FreeBSD).
Остальные вкладки можно не трогать, параметры по умолчанию подходят (в частности в разделе USB должен быть включен USB-контроллер 2.0).
Установка TrueNAS Core
На момент написания статьи актуальной версией являлась TrueNAS CORE 12.0-U3 на основе FreeBSD 12.2. Справедливости ради, в апреле 2021 года уже вышла 13.0, слегка отстаем… Запускаем нашу виртуальную машину и попадаем в, не побоюсь этого слова, UEFI Interactive Shell v2.2.
Хм… И что тут делать? 
Монтируем скачанный ISO-образ на оптический привод (в меню окна виртуальной машины: Устройства – Оптические диски – Выбрать файл диска) и либо перезагружаем машину командой reset, либо выходим в некий «эмулятор BIOS» (штука сама по себе весьма интересная, но заострять на ней внимание не будем) командой exit, а затем возвращаемся в оболочку командой меню Continue либо опять-таки перезагружаем систему (Reset).
Несмотря на то, что вроде бы настроена загрузка с компакт-диска, все равно попадаем в оболочку UEFI, только теперь нам доступна файловая система оптического диска. Переходим в FS1: (именно так и вводим), а далее нам помогут «традиционные» команды dir и cd. В конечном итоге нам надо запустить bootx64.efi из \efi\boot. На скриншоте показан «подробный» путь к нужному файлу (на тот случай, если вдруг что-то изменится в последующих релизах).
Но вообще можно было бы сразу после перехода в FS1: запустить \efi\boot\bootx64.efi (обратите внимание – используются обратные слэши).
Начнется загрузка установщика, сначала появится меню, в котором в принципе особо ничего и не надо делать (можно нажать Enter, чтобы сэкономить несколько секунд). Вот оно, для контроля:
А затем мы наконец попадем собственно в программу установки. Сама по себе процедура установки достаточно обыденная (описываю сокращенно) – выбираем нашу флешку в качестве диска для установки:
При нашей настройке виртуальной машины ее определить очень просто – не только по размеру, но и по названию: SATA-шные (и IDE) диски называются ada; NVMe – nvd; SCSI и, как видим, USB – просто da. Модель, к сожалению, в VirtualBox одна – VBOX HARDDISK (за исключением NVMe), что таки слегка сбивает с толку.
На следующем шаге подтверждаем установку на выбранный диск (da0 в нашем случае). В диалоговом окне как раз говорится о том, о чем я в немалой степени говорил в начале: систему не рекомендуется устанавливать на флешки и вы не сможете использовать этот диск для пользовательских данных (позволю себе так перевести «You can’t use da0 for sharing data»). Также нас предупреждают об удалении всех разделов и данных с диска.
После подтверждения установки задаем пароль root и наконец выбираем загрузку по UEFI:
Что ж, осталось дождаться завершения установки. FreeBSD сама по себе как-то довольно медленно эмулируется, а тут еще и USB, так что времени процесс займет намного дольше, чем в случае стандартной установки в режиме BIOS на IDE-контроллер. После вывода сообщения об успехе возвращаемся в начальное меню.
В нем, соответственно, нужно выбрать Reboot System. При этом нужно умудриться вовремя виртуально извлечь комакт-диск (примерно когда секунду-другую висит черный экран, как я полагаю — хотя проще наверное нажать Esc когда идет обратный отсчет, спокойно «изъять диск из привода» и сделать reset), иначе есть опасность, что загрузка теперь пойдет автоматически с привода (где он раньше был, спрашивается), а не с виртуальной флешки. Отличить их можно по загрузочному меню – одно я показывал ранее на скриншоте (и называется TrueNAS Installer), а другое называется Welcome to TrueNAS и состав пунктов слегка отличается.
Дожидаемся генерации неких параметров DH, после чего наконец-то системой можно начинать пользоваться.
Напомню, что первым делом желательно перейти в раздел System – General, где нужно будет указать правильную временную зону и отключить сбор телеметрии. На свой страх и риск можно выбрать заодно и русский язык, но из-за неполного перевода на мой взгляд лучше так не делать.
Народ на форумах рекомендует также включить SSH, хотя отчасти это не обязательно – есть веб-консоль, да и окно самой виртуальной машины никто не отменял. Хотя «родным» PuTTY пользоваться удобнее, особенно Midnight Commander’ом, который любезно предустановлен разработчиками.
Итак, в разделе Services сначала в настройках сервиса SSH разрешаем вход под root по паролю (Log in as Root with Password), а затем включаем сервис и делаем загрузочным (Start Automatically).
На этом будем считать установку системы завершенной.
Клонирование флешки на SSD
Потихоньку подбираемся к тому, ради чего мы здесь собственно и собрались – взяв за основу нашу «маленькую» флешку, сделать ее клон на SSD. Внимание! В любом случае подобные «финты ушами» не являются поддерживаемыми TrueNAS, а если проводить подобные манипуляции в реальности, то в случае ошибки можно уничтожить данные.
Проверка состава дисков
Почти все операции проводятся в консоли, в немалой степени ради этого в предыдущем разделе включали SSH. Для начала еще раз перепроверим, где какой диск. Понятно, что их список был выведен в процессе установки, но мало ли. К примеру можно вернуться к веб-интерфейсу: Storage – Disks.
Если же говорить о консоли, то:
# geom disk list
Пример вывода для виртуальной машины:
root@truenas[~]# geom disk list Geom name: nvd0 Providers: 1. Name: nvd0 Mediasize: 128849018880 (120G) Sectorsize: 512 Mode: r0w0e0 descr: ORCL-VBOX-NVME-VER12 lunid: 3660c1d85dfc854f8598698c7c9faf84 ident: VB1234-56789 rotationrate: 0 fwsectors: 0 fwheads: 0 Geom name: cd0 Providers: 1. Name: cd0 Mediasize: 0 (0B) Sectorsize: 2048 Mode: r0w0e0 descr: VBOX CD-ROM ident: (null) rotationrate: unknown fwsectors: 0 fwheads: 0 Geom name: ada0 Providers: 1. Name: ada0 Mediasize: 536870912000 (500G) Sectorsize: 512 Mode: r0w0e0 descr: VBOX HARDDISK ident: VBcd896337-0fff11f0 rotationrate: unknown fwsectors: 63 fwheads: 16 Geom name: ada1 Providers: 1. Name: ada1 Mediasize: 536870912000 (500G) Sectorsize: 512 Mode: r0w0e0 descr: VBOX HARDDISK ident: VBfdb0b20d-54b78a8e rotationrate: unknown fwsectors: 63 fwheads: 16 Geom name: ada2 Providers: 1. Name: ada2 Mediasize: 536870912000 (500G) Sectorsize: 512 Mode: r0w0e0 descr: VBOX HARDDISK ident: VB2295d677-41b6ce8d rotationrate: unknown fwsectors: 63 fwheads: 16 Geom name: da0 Providers: 1. Name: da0 Mediasize: 17179869184 (16G) Sectorsize: 512 Mode: r1w1e2 descr: VBOX HARDDISK ident: (null) rotationrate: unknown fwsectors: 63 fwheads: 255
Эмм, какие-то геомы, провайдеры… В официальной документации GEOM названа модульной инфраструктурой преобразования дисковых запросов, что как-то не проясняет ситуацию! Но в нашем простейшем случае разобраться несложно, поскольку видим только по одному провайдеру на каждое имя.
Итак, сверим часы: флешка - da0, SSD – nvd0.
Подготовка SSD
Посмотрим текущее состояние таблиц разделов:
# gpart show
Пример вывода:
root@truenas[~]# gpart show
=> 40 33554352 da0 GPT (16G)
40 532480 1 efi (260M)
532520 32997376 2 freebsd-zfs (16G)
33529896 24496 - free - (12M)
Как видим, на данный момент таблица разделов (GPT) существует только на устройстве da0. В упор не понимаю, зачем установщик выделил под раздел efi аж 260 мегабайт, ну да ладно.
Кстати мы же можем посмотреть содержимое этого раздела:
root@truenas[~]# cd /media root@truenas[/media]# mkdir efi root@truenas[/media]# mount -t msdosfs /dev/da0p1 /media/efi root@truenas[/media]# cd efi root@truenas[/media/efi]# ls -Rl ./ total 16 drwxr-xr-x 1 root wheel 16384 Apr 26 13:35 efi ./efi: total 16 drwxr-xr-x 1 root wheel 16384 Apr 26 13:35 boot ./efi/boot: total 112 -rwxr-xr-x 1 root wheel 94208 Apr 26 13:35 BOOTx64.efi -rwxr-xr-x 1 root wheel 12 Apr 26 13:35 startup.nsh root@truenas[/media/efi]# cd ~ root@truenas[~]# umount /media/efi
Да уж, какие-то жалкие два файла на 100 килобайт. Ладно, едем дальше, и тут-то как раз начинаются деструктивные операции.
Если вдруг на ssd уже есть какая-то таблица разделов, то удалим ее:
# gpart destroy -F nvd0
Копируем таблицу разделов с флешки на SSD:
# gpart backup da0 | gpart restore nvd0
Еще раз обращаю внимание на имена устройств: backup с флешки, restore на ssd. Проверяем:
root@truenas[~]# gpart backup da0 | gpart restore nvd0
root@truenas[~]# gpart show
=> 40 33554352 da0 GPT (16G)
40 532480 1 efi (260M)
532520 32997376 2 freebsd-zfs (16G)
33529896 24496 - free - (12M)
=> 40 251658160 nvd0 GPT (120G)
40 532480 1 efi (260M)
532520 32997376 2 freebsd-zfs (16G)
33529896 218128304 - free - (104G)
Отлично, теперь необходимо сделать SSD загрузочным. Два варианта: скопировать раздел efi командой dd либо прописать загрузчик с помощью gpart bootcode.
# dd if=/dev/da0p1 of=/dev/nvd0p1 bs=1M
На всякий случай напомню, что if – источник, of – приемник, bs – размер блока. Последний параметр указать очень важно, иначе копирование будет происходить крайне медленно. В примере используются блоки по 1 мегабайту.
root@truenas[~]# dd if=/dev/da0p1 of=/dev/nvd0p1 bs=1M 260+0 records in 260+0 records out 272629760 bytes transferred in 48.835848 secs (5582574 bytes/sec)
В любом случае gpart работает как-то быстрее:
# gpart bootcode -p /boot/boot1.efifat -i 1 nvd0
Во FreeBSD есть заранее подготовленный образ EFI-загрузчика, это как раз файл /boot/boot1.efifat, указанный в параметре -p. Об этом можно узнать, видимо, из man uefi, поскольку man gpart подробно расписывает только вариант с BIOS (а то еще и MBR вдобавок). Хотя нашлось упоминание и в документации (примечание к разделу 20.3.11). Оставшиеся параметры говорят о том, что загрузчик надо записать в первый раздел устройства (геома) nvd0.
Пример вывода:
root@truenas[~]# gpart bootcode -p /boot/boot1.efifat -i 1 nvd0 partcode written to nvd0p1
Перенос загрузочного пула
Теперь начинается, пожалуй, самое интересное: делаем загрузочный пул зеркалом, а затем удаляем из него флешку. Сначала выведем список пулов ZFS:
# zpool list
В виртуальной машине на данный момент он всего один и называется boot-pool:
root@truenas[~]# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT boot-pool 15.5G 1.16G 14.3G - - 0% 7% 1.00x ONLINE -
Проверим состояние (zpool status [pool]):
root@truenas[~]# zpool status boot-pool
pool: boot-pool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
boot-pool ONLINE 0 0 0
da0p2 ONLINE 0 0 0
errors: No known data errors
Как и следовало ожидать, загрузочный пул работает на da0p2 (вспомним gpart show – раздел 2 на устройстве da0). Преобразовываем пул в зеркало из da0p2 и nvd0p2:
# zpool attach boot-pool da0p2 nvd0p2
Меня немного смущало указание имеющегося устройства, но таков синтаксис команды.
Проверяем (я не указываю пул при получении статуса, поскольку он один):
root@truenas[~]# zpool attach boot-pool da0p2 nvd0p2
root@truenas[~]# zpool status
pool: boot-pool
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Apr 26 17:10:21 2021
1.16G scanned at 10.7M/s, 407M issued at 3.67M/s, 1.16G total
405M resilvered, 34.20% done, no estimated completion time
config:
NAME STATE READ WRITE CKSUM
boot-pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
da0p2 ONLINE 0 0 0
nvd0p2 ONLINE 0 0 0 (resilvering)
errors: No known data errors
Процесс, как говорится, пошел. Меня вновь смущало слово resilvering, но используется именно такой термин. Можно заняться какими-то другими делами, периодически опрашивая статус, пока пул не приобретет примерно следующий вид:
root@truenas[~]# zpool status
pool: boot-pool
state: ONLINE
scan: resilvered 1.19G in 00:04:47 with 0 errors on Mon Apr 26 17:15:08 2021
config:
NAME STATE READ WRITE CKSUM
boot-pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
da0p2 ONLINE 0 0 0
nvd0p2 ONLINE 0 0 0
errors: No known data errors
Теперь можем удалить флешку из пула:
# zpool detach boot-pool da0p2
На форумах зачем-то перед этим переводят da0p2 в оффлайн, но этого не следует ни из man zpool-deatch (где предлагается использовать offline вместо detach, если нужно временно отключить диск), ни из моих испытаний перед написанием статьи (zpool status все равно показывал online).
Проверяем:
root@truenas[~]# zpool detach boot-pool da0p2
root@truenas[~]# zpool status
pool: boot-pool
state: ONLINE
scan: resilvered 1.19G in 00:04:47 with 0 errors on Mon Apr 26 17:15:08 2021
config:
NAME STATE READ WRITE CKSUM
boot-pool ONLINE 0 0 0
nvd0p2 ONLINE 0 0 0
errors: No known data errors
Создание пула на свободном месте
Осталось задействовать свободное место на SSD. Создаем раздел с параметрами по умолчанию:
# gpart add -t freebsd-zfs -l ssd0 nvd0
На всякий случай присвоил метку ssd0 (параметр -l). Параметр -t определяет тип файловой системы, ну а в конце – наш любимый геом (диск).
Пример вывода:
root@truenas[~]# gpart add -t freebsd-zfs -l ssd0 nvd0 nvd0p3 added
Прежде чем создавать новый пул, необходимо узнать GUID созданного раздела. Честно говоря, даже немного странно, что загрузочный пул установщик создает на именах разделов типа da0p2, а пулы для данных – на gptid. Возможно изменение размещения загрузочного диска представляется намного менее вероятным, чем устройств для хранения данных. Хотя для проверки в виртуальной машине я легким движением руки перенес «SSD» в IDE-контроллер, и все загрузилось. Немного отвлеклись – для определения GUID’ов воспользуемся командой gpart list:
# gpart list nvd0
Пример вывода:
root@truenas[~]# gpart list nvd0 Geom name: nvd0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 251658199 first: 40 entries: 128 scheme: GPT Providers: 1. Name: nvd0p1 Mediasize: 272629760 (260M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r0w0e0 efimedia: HD(1,GPT,6a48fe3b-a696-11eb-a80c-0800270ddf06,0x28,0x82000) rawuuid: 6a48fe3b-a696-11eb-a80c-0800270ddf06 rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b label: (null) length: 272629760 offset: 20480 type: efi index: 1 end: 532519 start: 40 2. Name: nvd0p2 Mediasize: 16894656512 (16G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 272650240 Mode: r1w1e1 efimedia: HD(2,GPT,6a4958c7-a696-11eb-a80c-0800270ddf06,0x82028,0x1f78000) rawuuid: 6a4958c7-a696-11eb-a80c-0800270ddf06 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: (null) length: 16894656512 offset: 272650240 type: freebsd-zfs index: 2 end: 33529895 start: 532520 3. Name: nvd0p3 Mediasize: 111681691648 (104G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 4282404864 Mode: r0w0e0 efimedia: HD(3,GPT,3a94404d-a69b-11eb-a80c-0800270ddf06,0x1ffa028,0xd005fb0) rawuuid: 3a94404d-a69b-11eb-a80c-0800270ddf06 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: ssd0 length: 111681691648 offset: 17167306752 type: freebsd-zfs index: 3 end: 251658199 start: 33529896 Consumers: 1. Name: nvd0 Mediasize: 128849018880 (120G) Sectorsize: 512 Mode: r1w1e2
Как видим, вывод достаточно большой (опять же проявляется польза от PuTTY, кстати веб-консоль плохо работает с буфером обмена), из всего этого благополучия нам требуется значение rawuuid 3-го раздела:
3. Name: nvd0p3 … rawuuid: 3a94404d-a69b-11eb-a80c-0800270ddf06
В вашем случае он разумеется будет другим. Итак, зная GUID раздела, создаем на нем пул под названием ssd (для примера):
# zpool create ssd gptid/3a94404d-a69b-11eb-a80c-0800270ddf06
Проверяем:
root@truenas[~]# zpool create ssd gptid/3a94404d-a69b-11eb-a80c-0800270ddf06
root@truenas[~]# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
boot-pool 15.5G 1.16G 14.3G - - 0% 7% 1.00x ONLINE -
ssd 104G 100K 104G - - 0% 0% 1.00x ONLINE -
root@truenas[~]# zpool status ssd
pool: ssd
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
ssd ONLINE 0 0 0
gptid/3a94404d-a69b-11eb-a80c-0800270ddf06 ONLINE 0 0 0
errors: No known data errors
Отлично, для пущей важности отмонтируем новый пул, удалим директорию (чтобы не мешалась) и экспортируем его (хотя вроде бы это не обязательно – импорт в веб-интерфейс выполнялся и так).
root@truenas[~]# umount /ssd root@truenas[~]# rmdir /ssd root@truenas[~]# zpool export ssd
Что интересно, после команды экспорта пул пропадает из списка:
root@truenas[~]# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT boot-pool 15.5G 1.16G 14.3G - - 0% 7% 1.00x ONLINE -
Вроде бы на этом почти все, выключаем машину:
# poweroff
В настройках виртуальной машины удаляем USB-контроллер из накопителей, а также отключаем USB на одноименной вкладке.
Если все сделано правильно, машина должна стартовать «как ни в чем ни бывало».
Если применяются два SSD
В этом случае большинство вышеуказанных команд надо повторять дважды для каждой SSD: очистить таблицу разделов (повторюсь, при наличии), склонировать, записать загрузчик:
# gpart destroy -F nvd0 # gpart destroy -F nvd1 # gpart backup da0 | gpart restore nvd0 # gpart backup da0 | gpart restore nvd1 # gpart bootcode -p /boot/boot1.efifat -i 1 nvd0 # gpart bootcode -p /boot/boot1.efifat -i 1 nvd1
Пул преобразовывать, как ни странно, тоже нужно поэтапно (я почему-то первоначально думал, что тройное зеркало можно сделать одной командой):
# zpool attach -w boot-pool da0p2 nvd0p2 # zpool attach -w boot-pool da0p2 nvd1p2
Я добавил опцию -w, чтобы сразу же дождаться этого самого resilvering. Хотя конечно же опросить состояние в любом случае не повредит.
Исключение флешки, очевидно, делается однократно:
# zpool detach boot-pool da0p2
Вновь дважды создаем разделы на свободных местах:
# gpart add -t freebsd-zfs nvd0 # gpart add -t freebsd-zfs nvd1
И создаем зеркальный пул на созданных разделах (получаем GUID’ы командой gpart list). Как видите, после имени пула добавил слово mirror, иначе создалось бы «линейное» объединение (stripe) дисков.
# zpool create ssd mirror gptid/f91a81d6-a914-11eb-9fd6-080027a663cc gptid/fa35b9dd-a914-11eb-9fd6-080027a663cc
Очистка и экспорт ради приличия:
# umount /ssd # rmdir /ssd # zpool export ssd
Завершение настройки в веб-интерфейсе
Переходим в раздел Storage – Pools, он скорее всего будет пустым. Сначала предлагаю импортировать пул, созданный нами на SSD. Добавляем пул (Add), на первом шаге выбираем «Import an existing pool», на втором оставляем вариант по умолчанию – No, continue with import (мы же ведь не шифровали ничего), на третьем выбираем ssd (в соответствии с тем, как он был назван командой zpool create), и на последнем шаге (забыл сделать скриншот) подтверждаем импорт (Import).
Поскольку при создании пула не использовались какие-либо дополнительные параметры, то сжатие отключено. Дедупликацию по большому счету лучше вообще никогда не включать (если только речь не идет о реально каких-то промышленных установках).
В настройках пула можно, к примеру, отключить Atime (обновление времени доступа к файлам, т.е. отключение по идее должно благотворно сказаться на ресурсе SSD) и включить сжатие (LZ4 по умолчанию, впрочем смотря что предполагается на этом пуле хранить – может ZLE в каких-то случаях типа h264/ac3 окажется уместнее).
С импортированным пулом обнаружился нюанс. Прежде чем сохранять настройки, нужно раскрыть Advanced options и установить ACL Mode – Passthrough. Поскольку изначально никакого значения там не установлено, это приводит к ошибке при сохранении.
Теперь стандартным образом создаем «основной» пул из подготовленных SATA-дисков. На первом шаге выберем (фактически оставим) Create New Pool, в окне Pool Manager нажимаем Suggest Layout, на трех дисках создастся Raid-z (что и предполагалось). Имя пусть будет традиционным для TrueNAS – tank.
Итак, должно получиться примерно следующее:
Сравним с консолью:
root@truenas[~]# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT boot-pool 15.5G 1.16G 14.3G - - 0% 7% 1.00x ONLINE - ssd 104G 94.8M 104G - - 0% 0% 1.00x ONLINE /mnt tank 1.45T 768K 1.45T - - 0% 0% 1.00x ONLINE /mnt
Хочу обратить внимание на то, что веб-интерфейс присвоил пулам так называемый ALTROOT. На прикладном уровне это означает, что «точки монтирования» находятся внутри /mnt, т.е. /mnt/ssd и /mnt/tank соответственно. Еще почему-то неправильно вывелся размер «танка», веб-интерфейс показывает более реалистичную цифру.
root@truenas[~]# zpool status
pool: boot-pool
state: ONLINE
scan: resilvered 1.19G in 00:04:47 with 0 errors on Mon Apr 26 17:15:08 2021
config:
NAME STATE READ WRITE CKSUM
boot-pool ONLINE 0 0 0
nvd0p2 ONLINE 0 0 0
errors: No known data errors
pool: ssd
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
ssd ONLINE 0 0 0
gptid/3a94404d-a69b-11eb-a80c-0800270ddf06 ONLINE 0 0 0
errors: No known data errors
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gptid/5083b011-a6a6-11eb-b83f-0800270ddf06 ONLINE 0 0 0
gptid/5090d879-a6a6-11eb-b83f-0800270ddf06 ONLINE 0 0 0
gptid/509a7fa4-a6a6-11eb-b83f-0800270ddf06 ONLINE 0 0 0
errors: No known data errors
Хочу поделиться «приколом». Как вы наверняка заметили, swap-раздел на установочном диске отсутствовал, так вот судя по всему веб-интерфейс создает разделы подкачки на дисках для данных при создании основного пула.
oot@truenas[~]# gpart show
=> 40 251658160 nvd0 GPT (120G)
40 532480 1 efi (260M)
532520 32997376 2 freebsd-zfs (16G)
33529896 218128304 3 freebsd-zfs (104G)
=> 40 1048575920 ada2 GPT (500G)
40 88 - free - (44K)
128 4194304 1 freebsd-swap (2.0G)
4194432 1044381528 2 freebsd-zfs (498G)
=> 40 1048575920 ada1 GPT (500G)
40 88 - free - (44K)
128 4194304 1 freebsd-swap (2.0G)
4194432 1044381528 2 freebsd-zfs (498G)
=> 40 1048575920 ada0 GPT (500G)
40 88 - free - (44K)
128 4194304 1 freebsd-swap (2.0G)
4194432 1044381528 2 freebsd-zfs (498G)
Причем swap отзеркаленный.
root@truenas[~]# swapinfo Device 1K-blocks Used Avail Capacity /dev/mirror/swap0.eli 2097152 0 2097152 0%
Репликация пула ssd
Если не путаю, на форумах было предложено делать периодические бэкапы SSD-пула на основной. Давайте так и поступим, но прежде надо сказать пару слов о снимках, поскольку система репликации в конечном итоге основана на них. Снимок можно представить как копию файловой системы, хотя есть пример сравнения снимка с некоей ссылкой на версию данных. На файловых системах типа copy-on-write снимки создаются очень быстро, однако при этом возникает такой нюанс: если вы удаляете файл, который есть в снимке, свободное место не высвобождается, нужно удалить все снимки, в которые входил удаленный файл.
Возвращаясь к резервному копированию, для начала создадим так называемый датасет (dataset) – если совсем уж на пальцах, его можно представить как продвинутую директорию – на основном пуле в качестве места назначения (Storage – Pools, меню пула – Add Dataset). К примеру назовем его ssd_backup, настройки в принципе можно не трогать (разве что сжатие переопределить, если установленное на уровне всего пула не подходит).
Добавляем задачу репликации (Tasks – Replication Tasks, Add). Source Location (источник): On this System (на этой системе), ssd. Destination Location (назначение): On this System (на этой системе), tank/ssd_backup.
Описание флага Recursive несколько вводит в заблуждение – в нем говорится о снимках, но по факту если внутри источника есть вложенные датасеты, то флаг нужно взводить.
На втором шаге предлагается настроить расписание, по умолчанию ежедневно в полночь (Daily). Также есть варианты Hourly (ежечасно), Weekly (по воскресеньям) и Monthly (ежемесячно). Конечно же можно указать и собственное расписание, однако для теста я выберу ежечасную репликацию. Получается как-то так: Replication Schedule – Run On a Schedule (запуск по расписанию), Destination Snapshot Lifetime – Same as Source, т.е. время жизни снимков будет совпадать с исходным (по умолчанию используется две недели).
Я нажал Run now, вроде что-то нареплицировал.
Задача репликации создала в свою очередь задачу периодического создания снимков (snapshot). Повторный ручной запуск задачи репликации уже ни к чему не приведет, поскольку новых снимков нет. Так что для проверки нужно будет создать какой-нибудь файл и дождаться начала следующего часа.
Список снимков находится в Storage – Snapshots, имеются команды удаления, клонирования снимка в новый датасет и отката.
Последний штрих, что называется – теперь при желании можно использовать пул ssd для размещения клеток (jail) и плагинов (которые по сути преднастроенные jail). При первом переходе в любой из этих разделов (т. е. Plugins или Jails) будет запрошен выбор пула. Укажем ssd:
В результате всех настроек наши пулы приобретают следующий вид:
Что интересно, ssd_backup переведен в режим «только чтение». Вот теперь, пожалуй, все.
Заключение
Очень жаль, что для казалось бы элементарного действия – разбиения загрузочного диска – приходится выполнять столь изощренную процедуру. Хотелось бы конечно пожелать добавить подобный функционал в установщик, но увы. Вероятность этого «крайне мала» ©. Стоит ли заморачиваться? Если найдется «маленький» SSD, то может быть и нет. А вот на относительно большом велик соблазн использовать клетки и/или плагины и тогда уже придется пуститься во все тяжкие… Будьте внимательны и не уничтожте случайно данные.