В прошлом году потребовалось мне создать инструкцию по установке операционной системы Ubuntu 18.04. К слову, ничего сложного в установке Ubuntu нет, но есть нюанс: я хотел использовать файловую систему ZFS как базовую. С одной стороны, Ubuntu поддерживает ZFS на уровне ядра, но инсталятора под неё еще нет, но есть инструкция, да: https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS Последовательность действий в этой инструкции в целом правильная, но некоторые моменты требуют корректировки. Так что далее не прямой перевод инструкции, а вольный с учетом исправлений, моего опыта работы с ZFS и прочего. Так же я не рассматриваю вопросы шифрования диска и используем MBR загрузчик. Мою же инструкцию по установке можно получить здесь. Первое, что пропущено в инструкции и никак не рассматривается, это то что ZFS не очень хорошо работает с аппаратными RAID массивами, в частности это связано с Write cache, что понятно: файловая система ZFS — журналируемая и требует полного контроля над операциями записи. Так же при использовании готового аппаратного RAID массива теряются возможности ZFS в части Cache, Spare и прочего. Поэтому, все диски требуется перевести в HBA Mode, а при невозможности оного — сделать для каждого диска сделать отдельный RAID и отключить Write Cache контроллера. Так же, при использовании агрегации сетевых портов можно их отключить на этапе установки, что бы её не усложнять (все дальнейшие операции я произвожу без bonding). Как было сказано ранее, к сожалению, еще нет готового установщика Ubuntu с использованием root on ZFS, поэтому установка осуществляется с помощью LiveCD диска: Качаем отсюда: http://releases.ubuntu.com/18.04/ubuntu-18.04.1-desktop-amd64.iso Загружаемся с LiveCD, выбираем Try Ubuntu и открываем терминал (Ctrl+Alt+T). Смотрим сетевые интерфейсы и находим тот через который будем соединятся: Настраиваем сетевой интерфейс: И DNS resolver: Обновляем репозитории: Для удобства установки можно поднять OpenSSH сервер и все дальнейшие операции производить через SSH клиент Задаем пароль для пользователя ubuntu: Устанавливаем и запускаем OpenSSH: И в терминале рабочей станции: В основной инструкции отсутствует важный момент о том — каким образом определять дисковые массивы. Обычно на серверах количество дисков такое: 1 диск не рассматриваем ибо это вообще аномалия. Тут все просто, один массив MIRROR (RAID1). Если есть еще один третий диск, то можно его поставить в горячий резерв (SPARE) либо собрать RAIDZ массив (RAID5). Но 3 диска в сервере, очень большая редкость. Если все диски у нас одинаковы, вариантов тут всего три (четвертый RAID0 я в принципе не рассматриваю): На практике я использую MIRROR + MIRROR массив, при этом очевидно, что наиболее выгоден RAIDZ массив, так как предоставляет большее дисковое пространство, но есть нюансы В части отказоустойчивости массивы располагаются в таком порядке (от лучшего к худшему): В части скорости работы массивы располагаются в таком порядке: В части скорости работы массива при деградации одного диска: Сравнение характеристик субъективное, но достаточно отражает мой выбор как золотую середину. При этом надо понимать, что “медленней” и “еще медленней” — это не в разы, а всего на 10-20 % в худшем случае, поэтому, если у вас не оптимизирована база или приложение для работы с дисками, то падение скорости вы в принципе не заметите. Фактор скорости записи следует учитывать только тогда, когда вам действительно это нужно. Основная проблема заключается в том, что если у нас много дисков и мы хотим сделать один общий массив для всего, то нам потребуется каждый диск размечать с загрузочным сектором либо немного делать финт ушами. На практике, для многодисковых платформ я стараюсь собирать такую конфигурацию: Это равно же относится и к 4-х дисковым серверам если мы хотим получить достаточно универсальную платформу; В случае если диски все одинаковы, и выделить два диска под отдельный массив бессмысленно (например 6 дисков по 8 Tb), то можно сделать загрузочными диски первой группы массива. То есть если вы собираетесь делать массив как: MIRROR + MIRROR + MIRROR или RAIDZ + RAIDZ, то загрузочный сектор размечаем только для первой группы. В принципе, можно разметить вообще только один диск даже для MIRROR и RAIDZ, а остальное подставить в “сыром” виде, ZFS сделает массив по меньшему элементу сам, но в таком случае, при сбое первого диска, вы теряете единственный загрузочный диск, поэтому не стоит так делать. Важно понимать, что в файловой системе ZFS — stripe это не совсем RAID0, и работает он немного по-другому и не требует одинаковых размеров дисков, поэтому выделение небольшого пространства под загрузочный сектор погоды особо не сделает, главное указать в BIOS правильный диск с которого загружаться. Для разметки диска используется пакет mdadm, ставим его: Смотрим, какие диски у нас в наличии: И чистим их: Собственно, загрузочный раздел: Основной раздел. Если же используем все пространство, то просто создаем раздел на все оставшееся место: Не забываем проверить, как что получилось: Далее, по порядку: Имя корневого системного дискового массива я по привычке указываю как tank, хотя в данный момент в среде Linux предпочитают использовать имя rpool (root pool). В своей практике я вообще использую такое именование массивов: И вообще, я крайне рекомендую сразу выработать практику именования чего либо что бы не путаться. В этой части из основной инструкции можно все выкинуть и забыть. Парни явно перестарались с дроблением и опциями из-за чего по ходу дела пришлось кое-что исправлять. Правда, помогло не очень. Так как в дальнейшем проявляются снова проблемы и в конце выясняется что это все-равно не работает, поэтому в пункте 4.11. это еще раз исправляется. Совсем уж эпично выглядит выделение отдельного радела для /var/games. Мне не жалко, но это явно перебор. То, что в ZFS разделы создаются просто и поддерживают иерархию, это не значит что следует отказываться от классических директорий. Простой пример: у меня однажды на группе серверов было более 4K ZFS разделов, так было нужно, но перезагрузка сервера замедлялась на несколько минут из-за монтирование этих разделов. Начнем с чистого листа. Есть статичные и динамические файловые разделы. К статичным файловым разделам относятся разделы с программами и их настройками, они наполняются один раз и в процессе работы не изменяются. При этом ранее статичные разделы подразделялись на системные и пользовательские (/usr), но в данный момент в операционных системах семейства Linux они перемешались и разделять их смысла нет никакого, да и не получится. К динамичным файловым разделам относятся разделы в которых хранятся: В семействах Linux к динамическим разделам относятся /tmp и /var, но это не точно, так как в /var/lib могут попасть, программы и библиотеки, в общем, все смешалось, но тем не менее… Для начала требуется решить, создавать раздел /tmp на диске или же в памяти как tmpfs. Если создаем на диске, то тогда для него создаем отдельный раздел: Выделяем отдельно раздел var: И пользовательские разделы: точка монтирования tank/home/root указана как legacy, а не как /root. Это правильно, та как монтирование этого раздела осуществляется в п.4.11 Теперь требуется временно примонтировать наши динамические разделы в /mnt: В итоге должны получить примерно такую картину: Размер пустого раздела 96К соответственно у нас пустым остался только tank/tmp, а в остальные при установке ядра была произведена запись, значит монтирование разделов было осуществлено правильно. Мы уже в новой системе… Локаль и время: И дополнительные редакторы, кому что нравится: Как сказано ранее, я использую устаревший MBR: Не забываем при этом поправить конфигурацию sshd: Добавляем публичный ssh ключ пользователю и задаем ему пароль: Далее по инструкции мало чего интересного, так как сильно зависит от предпочтений конкретных администраторов и задач сервера в целом, кроме одного момента, а именно: “Аварийная загрузка” И не забываем поставить FireWall Выполняем подготовку среды установки (п.1.) Во время подготовки происходит импорт ZFS массива, поэтому требуется его переимпортировать, но с правильной точкой монтирования: Далее, если это требуется, можно сделать chroot как в п.4.4., но не забыть в последствии размонтировать все как в п. 6.3. В пункте 3.3. мы рассмотрели вопросы дополнительных разделов и упростили работу с ними относительно исходной инструкции. Это обусловлено в первую очередь тем, что у меня другая практика использования динамических разделов: так, журналы приложений я сохраняю в разделе /spool, а данные храню в разделе /data. Причем при наличии второго дискового массива ZFS эти разделы создаются именно там. Архитектор