Главная страница » Статьи и инструкции » Ubuntu 18.04 Root on ZFS

Ubuntu 18.04 Root on ZFS

Обновлено: 10.01.2019

В прошлом году потребовалось мне создать инструкцию по установке операционной системы Ubuntu 18.04. К слову, ничего сложного в установке Ubuntu нет, но есть нюанс: я хотел использовать файловую систему ZFS как базовую. С одной стороны, Ubuntu поддерживает ZFS на уровне ядра, но инсталятора под неё еще нет, но есть инструкция, да:

https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS

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

0. Подготовка сервера

Первое, что пропущено в инструкции и никак не рассматривается, это то что ZFS не очень хорошо работает с аппаратными RAID массивами, в частности это связано с Write cache, что понятно: файловая система ZFS — журналируемая и требует полного контроля над операциями записи. Так же при использовании готового аппаратного RAID массива теряются возможности ZFS в части Cache, Spare и прочего. Поэтому, все диски требуется перевести в HBA Mode, а при невозможности оного — сделать для каждого диска сделать отдельный RAID и отключить Write Cache.

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

1. Подготовка среды установки

1.1. LiveCD

Как было сказано ранее, к сожалению, еще нет готового установщика Ubuntu с использованием root on ZFS, поэтому установка осуществляется с помощью LiveCD диска:

Качаем отсюда: http://releases.ubuntu.com/18.04/ubuntu-18.04.1-desktop-amd64.iso

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

Загружаемся с LiveCD, выбираем Try Ubuntu и открываем терминал (Ctrl+Alt+T).

1.2. Обновляем и устанавливаем репозитории

# sudo apt-add-repository universe
# sudo apt update

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

Смотрим сетевые интерфейсы и находим тот через который будем соединятся:

# sudo ip a

Настраиваем сетевой интерфейс

# sudo echo "auto {{ NAME }}" >> /etc/network/interfaces
# sudo echo "iface {{ NAME }} inet static" >> /etc/network/interfaces
# sudo echo "	address {{ IP }}" >> /etc/network/interfaces
# sudo echo "	netmask {{ NETMASK }}" >> /etc/network/interfaces
# sudo echo "	gateway {{ GATEWAY }}" >> /etc/network/interfaces
# sudo service networking restart

И DNS resolver:

# sudo echo 'nameserver 8.8.8.8' >> /etc/resolv.conf

Обновляем репозитории:

# sudo apt update

1.3. SSH сервер (опционально)

Для удобства установки можно поднять OpenSSH сервер и все дальнейшие операции производить через SSH клиент

Задаем пароль для пользователя ubuntu:

# passwd

Это важно! Так как иначе доступ по ssh будет осуществляться без пароля с правами sudo. При этом нельзя устанавливать простой пароль.

Устанавливаем и запускаем OpenSSH:

# sudo apt install openssh-server
# sudo service ssh start

И в терминале рабочей станции:

ssh ubuntu@{{ ip server }}

1.4. Становимся root

# sudo -s

1.5. Устанавливаем поддержку ZFS в среде LiveCD

apt install --yes debootstrap gdisk zfs-initramfs

2. Разметка и форматирование жестких дисков

2.0. Определяем дисковые массивы

В основной инструкции отсутствует важный момент о том — каким образом определять дисковые массивы.
Обычно на серверах количество дисков такое:

2 диска;
4 диска;
много дисков;

1 диск не рассматриваем ибо это вообще аномалия.

2.0.1. 2 диска

Тут все просто, один массив MIRROR (RAID1). Если есть еще один третий диск, то можно его поставить в горячий резерв (SPARE) либо собрать RAIDZ массив (RAID5). Но 3 диска в сервере, очень большая редкость.

2.0.2. 4 диска

Если все диски у нас одинаковы, вариантов тут всего три (четвертый RAID0 я в принципе не рассматриваю):

MIRROR + MIRROR — аналог RAID10 точнее RAID01, так как в ZFS это mirror + mirror. 50% доступного дискового пространства;
RAIDZ — аналог RAID5. 75% доступного дискового пространства;
RAIDZ2 — аналог RAID6. 50% доступного дискового пространства;

На практике я использую MIRROR + MIRROR массив, при этом очевидно, что наиболее выгоден RAIDZ массив, так как предоставляет большее дисковое пространство, но есть нюансы:
В части отказоустойчивости массивы располагаются в таком порядке (от лучшего к худшему):

RAIDZ2 — могут быть утеряны два диска, без потери данных;
MIRROR + MIRROR — может быть утерян один диск без потери данных, и с 66% вероятностью может быть потерян второй диск без потери данных;
RAIDZ — может быть потерян только один диск без потери данных;

В части скорости работы массивы располагаются в таком порядке:

MIRROR + MIRROR — как в части записи так и в части чтения;
RAIDZ — в части записи медленнее, так как кроме записи требуется рассчитать контрольную сумму;
RAIDZ2 — в части записи еще медленней так как требует расчета более сложных контрольных сумм;

В части скорости работы массива при деградации одного диска:

MIRROR + MIRROR — при выпадении одного диска по сути теряется только параллельное чтение с одного зеркала, второе зеркало работает без деградации производительности;
RAIDZ2 — деградация по снижению производительности выше так как требует обратного перерасчета блока из контрольной суммы для 1/4 данных + поиск блока;
RAIDZ — деградация сильно больше, так как требует обратного перерасчета блока из контрольной суммы для 1/3 данных + поиск блока;

Сравнение характеристик субъективное, но достаточно отражает мой выбор как золотую середину.

При этом надо понимать, что “медленней” и “еще медленней” — это не в разы, а всего на 10-20 %, поэтому, если у вас не оптимизирована база или приложение для работы с дисками, то падение скорости вы в принципе не заметите. Фактор скорости записи следует учитывать только тогда, когда вам действительно это нужно.

2.0.2. Много дисков

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

2 SSD диска — делаем зеркало и как основной загрузочный массив с операционной системой и ZFS кешом для второго дискового массива
Остальное забиваем SATA или SAS дисками и без разметки собираем ZFS дисковый массив;

Это равно же относится и к 4-х дисковым серверам если мы хотим получить достаточно универсальную платформу;

В случае если диски все одинаковы, и выделить два диска под отдельный массив бессмысленно (например 6 дисков по 8 Tb), то можно сделать загрузочными диски первой группы массива. То есть если вы собираетесь делать массив как: MIRROR + MIRROR + MIRROR или RAIDZ + RAIDZ, то загрузочный сектор размечаем только для первой группы. В принципе, можно разметить вообще только один диск даже для MIRROR и RAIDZ, а остальное подставить в “сыром” виде, ZFS сделает массив по меньшему элементу сам, но в таком случае, при сбое первого диска, вы теряете единственный загрузочный диск, поэтому не стоит так делать.

Важно понимать, что в файловой системе ZFS — stripe это не совсем RAID0, и работает он немного по-другому и не требует одинаковых размеров дисков, поэтому выделение небольшого пространства под загрузочный сектор погоды особо не сделает, главное указать в BIOS правильный диск с которого загружаться.

2.1. Подготовка к разметке и очистка диска

Для разметки диска используется пакет mdadm, ставим его:

# apt install --yes mdadm

Смотрим, какие диски у нас в наличии:

# lsblk

И чистим их:

sgdisk --zap-all /dev/{{ disk name }}

2.2. Разметка диска

Собственно, загрузочный раздел:

sgdisk -a1 -n1:34:2047 -t1:EF02 /dev/{{ disk name }}

Основной раздел. Вот тут могут быть вариации: если у вам требуется выделить дополнительный раздел SSD дисков, например, для ZFS Cache или для Aerospike, то основной раздел делаете ограниченного объема:

sgdisk -n2:0:+100GB -t2:BF01 /dev/{{ disk name }}
sgdisk -n3:0:0 -t2:BF01 /dev/{{ disk name }}

Если же используем все пространство, то просто создаем раздел на все оставшееся место:

sgdisk -n2:0:0 -t2:BF01 /dev/{{ disk name }}

Не забываем проверить, как что получилось:

# lsblk

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  1.8T  0 disk 
├─sda1   8:1    0 1007K  0 part 
└─sda2   8:2    0  1.8T  0 part 
sdb      8:16   0  1.8T  0 disk 
├─sdb1   8:17   0 1007K  0 part 
└─sdb2   8:18   0  1.8T  0 part 
...

2.3. Создание ZFS массива

zpool create                	\
    -o ashift=12            	\
    -O atime=off            	\
    -O canmount=off         	\
    -O compression=lz4      	\
    -O checksum=fletcher4   	\
    -O normalization=formD  	\
    -m legacy               	\
    -R /mnt                     \
    -f                      	\
  tank                      	\
    mirror                  	\
      /dev/{{ disk a part 2}}   \
      /dev/{{ disk b part 2}}

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

Далее, по порядку:

ashift=12 — использовать размер блока в 4К, в принципе я до сих пор не понимаю, почему зачастую в операционных системах размер блока по умолчанию 512 байт когда как таких дисков уже практически нет;
atime=off — отключить одновление даты доступа к файлам, всегда выключаю так как эта информация мне никогда особо не требовалась и нагружать лишний раз ядро для этого не требуется;
canmount=off — запретить возможность монтирования корневого раздела;
compression=lz4 — включить компрессию данных алгоритмом LZ4. Этот параметр рекомендуется включать не только для экономии дискового пространства, но и для снижения количества операций ввода-вывода. При этом для этого аглоритма сжатия крайне низкая утилизация CPU;
checksum=fletcher4 — алгоритм контрольных сумм по-умолчанию и так fletcher4 просто лишний раз уточнить стоит;
normalization=formD — используется для улучшения работы с UTF-8, по факту ограничивая возможность использования имен файлов не UTF-8. Тут уж каждый рашает сам, мы в своей работе всегда используем только кодировку UTF-8;
xattr=sa — Ускорение работы с расширенными атрибутами. Я не использую эту опцию по причине того, что при использовании этой опции отключается совместимость с другими реализациями OpenZFS (например: FreeBSD). А совместимость с Windows и прочим, нам мне нужна. Тем более что эту опцию можно включить на конечном разделе;
-m legacy — точка монтирования в никуда, и монтировать корневой раздел не надо;
-R /mnt — временный префикс монтирования разделов для установки ядра;
-f — форсировать создание массива. Если до этого на дисках был собран ZFS массив, то команда create не сработает, мало ли, может вы ошиблись и хотите важные данные перетереть;

Имя корневого системного дискового массива я по привычке указываю как tank, хотя в данный момент в среде Linux предпочитают использовать имя rpool (root pool). В своей практике я вообще использую такое именование массивов:

tank — основной системный массив;
store — дополнительный массив с большими дисками для хранения данных;
cache — дополнительный массив из SSD дисков, если основной раздел находится не на них;

И вообще, я крайне рекомендую сразу выработать практику именования чего либо что бы не путаться.

3. Установка системы

3.1. и 3.2. Создание корневой файловой системы

Я специально объединил пункты 3.1. и 3.2. так как считаю, что указание корневого раздела на третьем уровне абсолютно излишне. Вот правда, за несколько лет работы с ZFS мне ни разу не потребовалось производить какие-нибудь манипуляции с корневым разделом. Тем более, есть же снимки, с помощью которых можно делать контрольные точки. Поэтому корневым разделом у меня является tank/root:

# zfs create -o mountpoint=/ tank/root

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

# zpool set bootfs=tank/root tank

3.3. Создание дополнительных разделов

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

Совсем уж эпично выглядит выделение отдельного радела для /var/games. Мне не жалко, но это явно перебор.
То, что в ZFS разделы создаются просто и поддерживают иерархию, это не значит что следует отказываться от классических директорий. Простой пример: у меня однажды на группе серверов было более 4K ZFS разделов, так было нужно, но перезагрузка сервера замедлялась на несколько минут из-за монтирование этих разделов.

Начнем с чистого листа.

Есть статичные и динамические файловые разделы.

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

К динамичным файловым разделам относятся разделы в которых хранятся:

Временные данные — tmp, swap;
Журналы работы — var/log;
Пользовательские данные — home;
Данные — var/db и как повезет;
Прочие результаты работы программ в виде файлов;

В семействах Linux к динамическим разделам относятся /tmp и /var, но это не точно, так как в /var могут попасть, программы и библиотеки, в общем, все смешалось, но тем не менее…

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

# zfs create -o mountpoint=legacy tank/tmp

Опции com.sun:auto-snapshot=false setuid=off ну как бы погоды не сделают, не надо усложнять. А вот со SWAP сделаем позже в п.7.

Выделяем отдельно раздел var:

# zfs create -o mountpoint=legacy tank/var

И пользовательские разделы:

# zfs create -o mountpoint=/home tank/home
# zfs create -o mountpoint=legacy tank/home/root

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

точка монтирования tank/home/root указана как legacy, а не как /root. Это правильно, та как монтирование этого раздела осуществляется в п.4.11

Теперь требуется временно примонтировать наши динамические разделы в /mnt

# cd /mnt/
# mkdir var tmp root
# mount -t zfs tank/var /mnt/var/
# mount -t zfs tank/tmp /mnt/tmp/
# mount -t zfs tank/home/root /mnt/root/

3.4 Устанавливаем ядро

В основной инструкции еще пара ненужных команд, не обращаем внимание, видимо артефакты:

# debootstrap bionic /mnt

В итоге должны получить примерно такую картину:

# zfs list

NAME             USED  AVAIL  REFER  MOUNTPOINT
tank             213M  1.76T    96K  legacy
tank/home        208K  1.76T    96K  /mnt/home
tank/home/root   112K  1.76T   112K  legacy
tank/root        147M  1.76T   147M  /mnt
tank/tmp          96K  1.76T    96K  legacy
tank/var        64.6M  1.76T  64.6M  legacy

Размер пустого раздела 96К соответственно у нас пустым остался только tank/tmp, а в остальные при установке ядра была произведена запись, значит монтирование разделов было осуществлено правильно.

4. Конфигурация системы

4.1. Настраиваем hosts и hostname

echo HOSTNAME > /mnt/etc/hostname
echo “127.0.0.1 localhost” > /mnt/etc/hosts
echo “127.0.0.1 HOSTNAME” >> /mnt/etc/hosts

4.2. Настраиваем сетевой интерфейс

Таки да, у нас тут уже netplan:

# vi /mnt/etc/netplan/setup.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eno2:
      dhcp4: no
      dhcp6: no
      addresses: [{{ IP }}/{{ netmask }}, ]
      gateway4: {{ gateway IP }}
      nameservers:
        addresses: [8.8.8.8]

4.3. Настраиваем apt репозитории

# vi /mnt/etc/apt/sources.list

deb http://archive.ubuntu.com/ubuntu/ bionic main restricted universe
deb http://security.ubuntu.com/ubuntu/ bionic-security main restricted universe
deb http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted universe

src — не нужны в основном

4.4. Монтируем виртуальные файловые разделы LiveCD

# mount --rbind /dev  /mnt/dev
# mount --rbind /proc /mnt/proc
# mount --rbind /sys  /mnt/sys
# chroot /mnt /bin/bash --login

требуется использовать именно —rbind, а не —bind

Мы уже в новой системе…

4.5. Настраиваем базовую среду

# ln -s /proc/self/mounts /etc/mtab
# chmod 1777 /tmp
# apt update

Локаль и время:

# dpkg-reconfigure locales

  * en_US.UTF-8
  * ru_RU.UTF-8

# dpkg-reconfigure tzdata

И дополнительные редакторы, кому что нравится:

# apt install --yes vim nano

4.6. Устанавливаем поддержку ZFS

# apt install --yes --no-install-recommends linux-image-generic
# apt install --yes zfs-initramfs

4.8. Устанавливаем загрузчик

Как сказано ранее, я использую устаревший MBR:

# apt install --yes grub-pc

Во время установки загрузчика требуется выбрать все наши диски которые мы определили как загрузочные, при этом установщик ругнется на все остальные диски кроме первого, соглашаемся и делаем п.5 (непонятно почему остальное оставили на потом):

4.8.1. (5.1) Проверяем что корневая файловая система распознается:

# grub-probe /

zfs

4.8.2. (5.2) Обновляем initrd

# update-initramfs -u -k al

4.8.3. (5.3) Упрощаем отладку GRUB

# vi /etc/default/grub

...
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="console"
...

4.8.4. (5.4.) Обновляем конфигурацию загрузчика

# update-grub

4.8.5. (5.5.) Устанавливаем загрузчик на каждый диск которые разметили как загрузочные

# grub-install /dev/sda
# grub-install /dev/sdb
...

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

4.8.6. (5.6.) Проверяем, что модуль ZFS установлен

# ls /boot/grub/*/zfs.mod

/boot/grub/i386-pc/zfs.mod

4.10. Задаем пароль пользователя root

# passwd

И да, поставим сразу openssh, иначе получим сюрприз после рестарта, если работаем удаленно:

# apt install --yes openssh-server

Не забываем при этом поправить конфигурацию sshd:

# vi /etc/ssh/sshd_config

...
PermitRootLogin yes
...
PasswordAuthentication yes
...

4.11. Исправление монтирования файловых систем

Вот добрались до самого интересного. Дело в том, что монтирование ZFS разделов происходит после старта некоторых демонов, которые, в свою очередь самостоятельно создают некоторую структуру в /var начинают заполнять системные журналы. Когда же настает время монтирования ZFS разделов выясняется что точки монтирования не пустые и смонтировать ничего не получается, данные рассыпаются, все плохо. Поэтому требуется указать точки монтирования в /etc/fstab так как systemd в первую очередь ориентируется на них при обращении к папке:

# vi /etc/fstab

tank/var        /var   zfs  noatime,nodev 0 0
tank/tmp        /tmp   zfs  noatime,nodev 0 0
tank/home/root  /root  zfs  noatime,nodev 0 0

Остальное до п.6. уже сделано

6. Первая перезагрузка

6.1. Делаем снимок корневого раздела

# zfs snapshot tank/root@setup

Толку от него никакого, на практике я ни разу не не шатал корневой раздел системы и ни разу не использовал снимки этого раздела, но тем не менее пусть лежит, может пригодится

6.2. Выходим из chroot

# exit

6.3. Отмонтируем разделы LiveCD и выгрузим ZFS массив

# cd
# mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | xargs -i{} umount -lf {}
# zpool export tank

6.4 Перезагрузка

Перезагрузку лучше делать в терминале LiveCD, так как если вы работает через ssh клиент, перезагрузка через него может привести к «зависанию» сервера.

# reboot

Если все-таки что-то пошло не так и сервер в перезагрузку не ушел, то перезагрузку можно делать любым способом, так как ZFS массив экспортирован и повредить его сложно.

6.5. Ждем перезагрузки и заходим как root

6.6. Создаем учетную запись своего пользователя

# zfs create tank/home/{{ LOGIN }}
# useradd -u {{ UID }} -G adm,sudo -d /home/{{ LOGIN }}/ -s /bin/bash {{ LOGIN }}
# cp -a /etc/skel/.[!.]* /home/{{ LOGIN }}
# chown -R {{ LOGIN}}:{{ LOGIN}} /home/{{ LOGIN }}

Добавляем публичный ssh ключ пользователю и задаем ему пароль:

su - {{ LOGIN }}
mkdir .ssh
chmod 0700 .ssh
vi .ssh/authorized_keys
exit
passwd {{ LOGIN }}

В OpenSSH убираем возможность авторизоваться root и парольную авторизацию:

# vi /etc/ssh/sshd_config

...
PermitRootLogin no
...
PubkeyAuthentication yes
...
PasswordAuthentication no
...

# service ssh restart

6.7. 6.8. Уже не требуется

7. Настройка swap

7.1. Создаем раздел ZFS

# zfs create \
    -V 32G \
    -b $(getconf PAGESIZE) \
    -o compression=zle \
    -o logbias=throughput \
    -o sync=always \
    -o primarycache=metadata \
    -o secondarycache=none \
  tank/swap

-V 32G — Размер нашего SWAP, можно определить тот который требуется реально;
-b $(getconf PAGESIZE) — размер блока (4K c ashift=12);
compression=zle — выбираем минимальный по ресурсоёмкости алгоритм сжатия, по сути так как размер блока у нас 4К, то сжатия как таковое не даст утилизации по вводу-выводу, но при этом можно будет сэкономить на нулевых блоках;
logbias=throughput — установка пропускной способности для оптимизации синхронных операций;
sync=always — всегда синхронизировать запись. Это несколько снижает производительность, но полностью гарантирует достоверность данных;
primarycache=metadata — кешировать только метаданные, так как из swap не будет производится множественное чтение одного и того же блока;
secondarycache=none — вторичный кеш вообще отключить по причинам указанным выше;

7.2. Настраиваем раздел подкачки

# mkswap -f /dev/zvol/tank/swap
# echo /dev/zvol/tank/swap none swap defaults 0 0 >> /etc/fstab
# echo RESUME=none > /etc/initramfs-tools/conf.d/resume

7.3. Включаем swap

# swapon -av

Далее по инструкции мало чего интересного, так как сильно зависит от предпочтений конкретных администраторов и задач сервера в целом, кроме одного момента, а именно: “Аварийная загрузка”

И не забываем поставить FireWall

R. Аварийная загрузка

Выполняем подготовку среды установки (п.1.)

Во время подготовки происходит импорт ZFS массива, поэтому требуется его переимпортировать, но с правильной точкой монтирования:

# zpool export -a
# zpool import -N -R /mnt tank
# zfs mount -a

Тут, конечно забыли в исходной инструкции про то, что у нас некоторые разделы монтируются через fstab, но исправим эту ошибку:

# mount -t zfs tank/var /mnt/var/
# mount -t zfs tank/tmp /mnt/tmp/
# mount -t zfs tank/home/root /mnt/root/

Далее, если это требуется, можно сделать chroot как в п.4.4., но не забыть в последствии размонтировать все как в п. 6.3.

D. Динамические разделы

В пункте 3.3. мы рассмотрели вопросы дополнительных разделов и упростили работу с ними относительно исходной инструкции. Это обусловлено в первую очередь тем, что у меня другая практика использования динамических разделов: так, журналы приложений я сохраняю в разделе /spool, а данные храню в разделе /data. Причем при наличии второго дискового массива ZFS эти разделы создаются именно там.

Резюме

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

Опубликовано: 10.01.2019

КОНСАЛТИНГ  ПО POSTGRESQL

Консалтинг —  это когда мы сами выполняем работу

ЕЩЕ СТАТЬИ ПО ДАННОЙ ТЕМЕ

Новая функция резервного копирования и восстановления с поддержкой JSON

В новой версии Postgres 17 представлена функция офлайн-слияния инкрементных резервных копий в полные, что снижает нагрузку на сервер. Улучшены возможности SQL/JSON, включая функции JSON_TABLE(), JSON_EXISTS(), JSON_QUERY() и JSON_VALUE(). Это делает систему более привлекательной для предприятий.

Supabase привлекает $6 млн для развития открытого кода и ИИ базы данных

Supabase Inc. привлекла 6 миллионов долларов в рамках раунда финансирования серии C. Компания предлагает открытый исходный код и инструменты для разработки приложений, включая базу данных Postgres. Supabase активно использует искусственный интеллект, что привлекает крупных клиентов, таких как GitHub и Meta.

Tonic разрабатывает платформу для создания синтетических данных

Tonic разрабатывает платформу для создания синтетических данных, заменяющих подмножество баз данных с ЛДП или ЗЗИ. Новый инструмент Condenser, доступный на GitHub, упрощает процесс, минимально настраивая сложные базы данных с ограничениями внешних ключей.

Поддержка Postgre SQL

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

Ubuntu 18.04 Root on ZFS

0. Подготовка сервера

1. Подготовка среды установки

1.1. LiveCD

1.2. Обновляем и устанавливаем репозитории

1.3. SSH сервер (опционально)

1.4. Становимся root

1.5. Устанавливаем поддержку ZFS в среде LiveCD

2. Разметка и форматирование жестких дисков

2.0. Определяем дисковые массивы

2.0.1. 2 диска

2.0.2. 4 диска

2.0.2. Много дисков

2.1. Подготовка к разметке и очистка диска

2.2. Разметка диска

2.3. Создание ZFS массива

3. Установка системы

3.1. и 3.2. Создание корневой файловой системы

3.3. Создание дополнительных разделов

3.4 Устанавливаем ядро

4. Конфигурация системы

4.1. Настраиваем hosts и hostname

4.2. Настраиваем сетевой интерфейс

4.3. Настраиваем apt репозитории

4.4. Монтируем виртуальные файловые разделы LiveCD

4.5. Настраиваем базовую среду

4.6. Устанавливаем поддержку ZFS

4.8. Устанавливаем загрузчик

4.8.1. (5.1) Проверяем что корневая файловая система распознается:

4.8.2. (5.2) Обновляем initrd

4.8.3. (5.3) Упрощаем отладку GRUB

4.8.4. (5.4.) Обновляем конфигурацию загрузчика

4.8.5. (5.5.) Устанавливаем загрузчик на каждый диск которые разметили как загрузочные

4.8.6. (5.6.) Проверяем, что модуль ZFS установлен

4.10. Задаем пароль пользователя root

4.11. Исправление монтирования файловых систем

6. Первая перезагрузка

6.1. Делаем снимок корневого раздела

6.2. Выходим из chroot

6.3. Отмонтируем разделы LiveCD и выгрузим ZFS массив

6.4 Перезагрузка

6.5. Ждем перезагрузки и заходим как root

6.6. Создаем учетную запись своего пользователя

7. Настройка swap

7.1. Создаем раздел ZFS

7.2. Настраиваем раздел подкачки

7.3. Включаем swap

R. Аварийная загрузка

D. Динамические разделы

Резюме

КОНСАЛТИНГ ПО POSTGRESQL

Метки

ЕЩЕ СТАТЬИ ПО ДАННОЙ ТЕМЕ

Новая функция резервного копирования и восстановления с поддержкой JSON

Supabase привлекает $6 млн для развития открытого кода и ИИ базы данных

Tonic разрабатывает платформу для создания синтетических данных

Поддержка Postgre SQL

Postgres.men

Миграция

Мы в соцсетях

КОНСАЛТИНГ  ПО POSTGRESQL