Большая часть предыдущих заметок была посвящена ручной разметке дисков — созданию слайсов, партиций, файловых систем, а также монтированию последних в древо FreeBSD. Однако на практике необходимость прибегать к такого рода мануальной терапии возникает не так уж часто — при начальной установке заботу обо всех этих проблемах берет на себя sysinstall. Причем все эти действия совершаются почти нечувствительно для пользователя. Возникает вопрос — а за каким же я столько распинался на эти темы, если большинству пользователей с ними столкнуться не придется?
Ответов, как обычно, несколько. Во-первых, я сам не так давно со всем этим разобрался, и потому решил поделиться приобретенными навыками:-). Во-вторых, всегда полезно понимать, что стоит за front-end'ными утилитами, особенно — за такой универсальной и многогранной, как sysinstall. В третьих, есть несколько видов установки и настройки, которые либо нельзя выполнить через sysinstall полностью, либо легче сделать без нее. Наконец, в четвертых — применение sysinstall для послеустановочного конфигурирования иногда бывает нежелательным, в ряде случаев она любит внести кое-какую отсебятину в уже настроенные конфигурационные файлы. Не очень существенную, но, тем не менее, требующую внимания.
Собственно говоря, очередную заметку цикла я собирался посвятить детальному описанию sysinstall — ее возможностей (весьма многочисленных) и ограничений (некоторые из которых имеют место быть). Однако вовремя вспомнил, что эта тема хорошо освещена и в Handbook'е, и в Иллюстрированном руководстве по установке FreeBSD. Да и в своей книге про FreeBSD (А.Федорчук, А.Торн. FreeBSD: установка, настройка, использование. СПб.: БХВ-Петербург, 2003) я немало страниц уделил sysinstall и ее применению. В частности, один из разделов ее так и назывался — «Алгоритм идеальной установки», так что повторяю — читайте меня, как говорил Бернард Шоу молоденьким девушкам:-).
И потому в этой заметке я остановлюсь на одном из частных вопросов установки FreeBSD — на программном RAID-массиве нулевого уровня. А заодно вернусь к идеальной инсталляции системы — как это видится мне теперь, по прошествии полутора лет.
Сразу оговорюсь, что установка производилась на машину с вышесредними ресурсами, в частности, гигабайтом памяти и двумя дисками по 80 Гбайт каждый (плюс в запасе имелся еще и 20-гигабайтник для резервного копирования данных), так что не стояло ни проблемы экономии ресурсов, ни задачи сохранения имеющихся данных. Однако ныне такие конфигурации не выглядят чем-то из ряда вон выходящим.Несколько слов о железе
Эти заявленные несколько слов могут потребоваться в дальнейшем. Итак, дано:
- процессор Pentium-4/2,53;
- материнская плата Albatron на чипсете i845PE с дополнительным контроллером IDE-RAID/SerialATA имени Promise FastTrak 376;
- память — два модуля DDR333, по 512 Мбайт каждый, беспородные (квази-Samsung);
- первый винчестер (Seagate Barracuda IV, 80 Гбайт) мастером на 1-м встроенном IDE-канале;
- второй винчестер (Seagate Barracuda же IV, 80 Гбайт), единственным устройством на IDE-RAID/UATA133;
- CD-R/RW (модель непринципиальна) слейвом на втором встроенном IDE-канале;
- прочее, для работы необходимое, но в данном контексте рояля не играющее.
Собственно, основным для дальнейшего являются RAID-контроллер и диски. Так вот, этот самый RAID был сделан так, что массив на нем можно было устроить из трех (ей же ей, так в документации) дисков — одного на разъеме UATA133 и двух — на SerialATA (именно столько их и было). Причем каждое устройство должно было быть мастером на своем разъеме, к коим устройств типа CD ROM подключать не следовало (и действительно, не работали). А аппаратно RAID'ы поддерживались уровней 0 и 1 (интересно, как это можно устроить mirroring для трех устройств — но, повторяю, так в документации было сказано.
Хотя вопросы аппаратного RAID'а меня не волновали — дисков SerialATA у меня не было, переходника Serial/Parallel ATA — также. Так что оставалось озаботиться только RAID'ом программным.
Я позволил себе задержаться на конфигурации потому, что она доставила мне немало веселья при общении с Linux'ами. Теоретически я всегда знал, что два современных винта на одном IDE-канале — вещь не самая быстрая. Но насколько она не быстра — понял, только когда (в Gentoo Linux, а затем — в самостройном) устроил на этом хозяйстве (две Барракуды на 1-м IDE) LVM-разделы. Оказалось, что даже перенести второй диск мастером на второй канал (в паре с CD) — и то быстрее было (хотя тогда началось экстремальное торможение при записи с CD). А целых три разъема дополнительного FastTrak'а бездействовали — ни одно ядро Linux (включая 2.4.21) видеть на нем винтов не желало в упор (собственно, конечно, только винтов на Parallel ATA, но, думаю, что и с сериальными была бы та же история). Так что когда Free пять-первой, еще беты, этот винт увидела — был весьма рад...
Что же касается дисков — подчеркну, что они были не только одного размера, но и одной модели, куплены в одном месте с разбежкой в пару-тройку месяцев. Тем не менее, в них обнаружилась одна странность, о которой будет сказано в свое время.Почему RAID
Собственно говоря, для использования двух винчестеров под одной ОС RAID-массив вовсе не обязателен — достаточно было бы создать на втором BSD-слайс, разметить его как одну партицию, создать на нем файловую систему и смонтировать ее в один из подкаталогов /home/user_имя_рек (мой домашний каталог — главный пожиратель дискового пространства). Просто, но не верх удобства.
Нужно все время помнить, что пользовательский каталог на самом деле не только образован двумя файловыми системами, но и лежит на двух винтах. Что, кроме всего прочего, накладывает ограничения на жесткие ссылки внутри него. Мы ведь помним, что жесткие ссылки могут существовать только в единой партиции. А для чего они нужны в домашнем каталоге — ответить не трудно: это один из простых и дешевых (с точки зрения расхода, как дискового пространства, так и времени) подстраховаться от случайного удаления данных. Смахнешь, бывалыча, в азарте каталог, показавшийся ненужным, хватишься — ан глянь, он в виде жесткой ссылки сидит где-нибудь в /home/user_имя_рек/dubles_data, и есть не просит...
Так что организовать два диска в виде единого пространства — безусловно, удобнее. А для этого в природе предусмотрено два механизма (кроме аппаратного RAID'а, но с ним, как уже говорилось — облом): программный RAID и механизм логических томов. Последний, насколько я понимаю, встроен в файловую систему JFS, относительно поддержки которой во Free информация промелькнула. Однако в текущей версии (5.1-STABLE) никаких упоминаний на сей счет я не обнаружил — в файле описания конфигурации ядра /usr/src/sys/conf/NOTES про JFS не говорилось ни слова. Да и от краткого с ней знакомства под Linux'ом впечатлений чего-то выдающегося она не оставила...
Так что оставался только программный RAID. Разумеется, level 0 — поскольку зеркалирование просто не соответствовало задаче, а level 5 показался сложным и неоправданным. Вообще, ИМХО, RAID-массивы с избыточностью на настольной машине — баловство: от ошибок пользователя (причины 99% потери данных в домашних условиях) они не страхуют (а иногда способны даже усугубить их последствия). От аппаратных же сбоев — только в том случае, если в столе лежит запасной винчестер на смену рухнувшему. Ситуация, вероятно, не редкая для админа локальной сети — но практически исключенная на дому; по крайней мере, если бы у меня завалялся ненужный винчестер, я нашел бы десятки способов пристроить его к делу...
Изучение вопроса показало, что под FreeBSD, как это в ней обычно бывает, есть не один способ реализации программного RAID-0: исторический (вернее, в масштабах индустрии — почти доисторический) ccd и более современный vinum. Последний, представляя собой, как можно догадаться из его man-страницы, нечто вроде менеджера логических томов, считается более гибким. Однако я остановился на ccd — рациональное объяснение этому дать затрудняюсь (разве что какие-то непонятки с лицензией на vinum). Подготовка к слиянию
Итак, ccd (Concatenated Disk driver), что в переводе означает — драйвер слияния дисков. Средство, как я уже сказал, весьма древнее — man-страница датирована 1995 г., — а значит, проверенное временем. Позволяет создавать программные RAID-массивы типа нулевого (stripping) и первого (mirroring) уровней. Как уже говорилось, меня интересовал только нулевой.
И тут обнаружилось, что и построение RAID'а средствами ccd может быть выполнено двумя способами. Согласно первому, в соответствие с заветом великого Ленина, прежде чем объединиться, следовало решительно размежеваться, согласно второму — наоборот.
Суть второго способа — интуитивно понятна (и аналогична построению RAID'а в Linux с помощью mdtools): два дисковых раздела одинакового объема сливаются воедино, а потом это объединенное пространство делится на партиции под нужные файловые системы (типа /usr, /var, /home). Первая схема выглядела в описании более сложной — сначала деление обоих дисков на симметричные партиции под будущие файловые системы, а потом попарное их слияние. Тем не менее, именно второй способ показался мне, уж не знаю, обоснованно или нет, идеологически более правильным. На нем я и остановился.
Важное замечание: в отличие, опять же, от Linux, во FreeBSD разместить на программном RAID'е (средствами ли ccd, или vinum, без разницы) корневую файловую систему нельзя. Поэтому прежде чем заниматься его построением, необходимо систему установить хотя бы в минимальном объеме. К чему я и приступил.
Итак, грузимся с инсталляционного CD (можно ограничиться и мини-диском) и попадаем в sysinstall. Тут быстро проскакиваем стадию начального конфигурирования опций — я здесь обычно только заменяю умолчальный редактор ee на любимый joe; в некоторых случаях, возможно, есть смысл присмотреться к опциям создания файловых систем (Newfs Args), хотя умолчальные -b 16384 -f 2048 видятся мне разумными. И отправляемся с пункт Custom главного меню, где выбираем подпункт Partition, отвечающий за создание слайсов.
Тут я столкнулся с первой неожиданностью: хотя диски мои казались одинаковыми по всем параметрам, sysinstall обнаружила в них разную геометрию, причем про один упорно утверждала, что она неправильна. Меня это несколько смутило, я вышел из sysinstall, загрузился с rescue-CD и вручную разметил (для страховки) оба диска в интерактивном режиме — командами $ fdisk -i /dev/ad0
и $ fdisk -i /dev/ar0
Правда, потом я понял, что необходимости в этом не было — sysinstall с подобными коллизиями справляется автоматически (а при необходимости скорректировать геометрию диска вручную можно прямо из нее). Но о потраченных усилиях не жалею — в итоге появился сюжет для одной из предыдущих заметок — про практику дискодробительства.
Оба диска были размечены в эксклюзивном режиме (помещения на них других ОСей не предполагалось, на сей предмет у меня был винт в запасе). После чего я вернулся к установочному диску и sysinstall, перейдя сразу к пункту Label (то есть разметке партиций.
Редактор разметки из sysinstall (Disk Label Editor) предусматривает режим автоматического разбиения BSD-слайса на партиции, создаю следующую конфигурацию разделов: Part Mount Size Newfs ---- ----- ---- ----- ad0s1a / 256MB UFS ad0s1b swap RAM*2 SWAP ad0s1d /tmp 256MB UFS+S ad0s1e /var 256MB UFS+S ad0s1f /usr ост. UFS+S
Я предполагал оставить непосредственно на BSD-разделе только корневую файловую систему, все остальное же перенести на конкатенированные партиции, а swap-раздел разнести на оба физические диска. И потому оставил только партиции a (в предложенном по умолчанию размере) и b (в размере вдвое меньше). Практика показала, что 256 Мбайт за глаза хватает для минимальной установки FreeBSD (а именно ею я и собирался ограничится — см. чуть ниже).
Должен заметить, что я попытался разметить разделы под дальнейшее применение ccd непосредственно из sysinstall. Не сказать, чтобы ничего не получилось, но кое-какие странности имели место. В частности, при попытке разметки второго диска регулярно возникали ошибки при определении последней партиции — после того, как я отводил гигабайт на swap, по полраздела под будущие конкатенированные /var и /usr (от раздела под /tmp я отказался, так как предполагал вынести его на mfs — см. предыдущую заметку), на попытку создать из остатка полураздел для будущего /home следовало сообщение о нехватке места. Правда, если создавать все это в обратном порядке, то есть сначала разделы под файловые системы, а уже потом — под swap, все вроде проходило. Но это мне все равно показалось неправильным, и я оставил свои попытки, решив вернуться к разметке партиций для ccd руками, после установки базовой системы.
А из базовой системы я выбрал только пункт собственно base и man-страницы (дабы не остаться с ccd один на один). В итоге вся инсталляция уложилась у меня менее чем в 150 Мбайт. Забегая вперед, скажу, что после вынесения из корневой партиции /var и /usr и досборки (через make world) недостающих, но нужных компонентов (системы безопасности, например — без нее из портов или пакетов даже links не собирается) в ней оказалось занятым всего 67 Мбайт. Конечно, при make world я от многого отказался, но все равно: умолчальный размер корневой партиции дается sysinstall с очень большим запасом, и при недостатке дискового пространства его спокойно можно урезать вдвое (повторяю, при вынесении /var, /usr и, конечно же, /home в отдельные разделы).
По завершении разметки диска и установки базовой системы я, отказавшись от установки пакетов, выполнил минимальный комплекс настроечных действий: определил пароль для root'а (аккаунт для обычного пользователя создавать пока нецелесообразно), сконфигурировал консоль для работы с кириллицей (на всякий случай) и настроил мышь (без консольной мыши жить несколько неуютно), а также удалил все ненужные мне (то есть — почти все вообще) стартовые сервисы. После чего вышел из sysinstall, перезагрузив машину.
Система, не смотря на свою предельную урезанность и вдвое сниженный объем swap'а, загрузилась нормально. Следовало приступать к разметке партиций под ccd.
Авторизовавшись root'ом, я перво-наперво подмонтировал свой дежурный исходняк-CD и из записанного на нем тарбалла собрал любимый редактор joe, определенный ранее в качестве системного. Версии joe из портов или пакетов FreeBSD, что стабильная, что developer'ская, устарели, поэтому я просто распаковал архив в /usr/local/src: $ mkdir /usrlocal/src $ cd /usrlocal/src $ tar xzvf /cdrom/src/joe-2.9.8.tar.gz
и, перейдя в образовавшийся каталог, выполнил конфигурирование, сборку и установку: $ cd joe-2.9.8 $ ./configure --bindir=/bin $ make $ make install
Опция --bindir=/bin предписывает установить исполнимый файл joe непосредственно в /bin, который при любых дальнейших манипуляциях останется в корневом разделе: всегда полезно, чтобы любимая командная оболочка и редактор, выполняющий роль системного, находились непосредственно в корне — на случай действий в однопользовательском режиме и всякого рода ремонтно-восстановительных работ.
Теперь — собственно разметка партиций. Перво-наперво — опять же переход в однопользовательский режим — вообще, лучше взять за правило все действия, связанные с разметкой дисков, выполнять из него — чисто для страховки.
Далее, вооружившись bsdlabel, запускаемой с опцией -e, калькулятором командной строки bc и, конечно же, man (8) bsdlabel, я на первом (/dev/ad0s1) эксклюзивном диске, в дополнение к имевшимся a: 524288 0 4.2BSD 2048 16384 32776 b: 2074624 524288 swap c: 156301488 0 unused 0 0
дописал строки, определяющие полуразделы под /var (256 Мбайт) и /usr (5 Гбайт), предназначив все оставшееся пространство (около 65 Гбайт — не будем забывать, что объем моих дисков исчислялся в гигабайтах, принятых среди астрологов, хиромантов и производителей дисков, то есть реально составлял по 76 истинных гигабайт) под половинку от /home. В результате получилось: d: 524288 2598912 4.2BSD 0 0 0 e: 10240000 3123200 4.2BSD 0 0 0 f: 142938288 13363200 4.2BSD 0 0 0
После этого я обратился ко второму диску (/dev/ar0s1), на котором создал парные к первому разделы под swap (1024 Мбайт), /var, /usr и /home (того же размера), что в итоге дало: b: 2074624 0 swap c: 156301312 0 unused 0 0 # «raw» part, don't edit d: 524288 2074624 4.2BSD 0 0 0 e: 10240000 2598912 4.2BSD 0 0 0 f: 142938112 12838912 4.2BSD 0 0 0
Можно видеть, что, не смотря на все мои усилия по ручной коррекции геометрии, добиться полной идентичности мне не удалось, но на практике это ничему не помешало. Вероятно, с точки зрения полной симметрии в начале второго диска следовало оставить 256 Мбайт неразмеченного пространства, зеркального по отношению к корню первого, но я этого не сделал (и вреда, как будто, ни малейшего). А так неиспользованный объем диска остался в самом его конце.Конкатенируем помаленьку
Все предыдущие действия можно было бы проделать и через sysinstall (с приведенными выше оговорками). Но теперь наступает время конкатенации партиций — и для этого в sysinstall средств как будто бы не предусмотрено. Но зато имеется специально для этого предназначенная утилита ccdconfig. Вооружаюсь соответствующей man-страницей — man (8) ccdconfig, — и выясняю, что и эту процедуру можно проделать двумя разными способами. Правда, оба требуют перехода в однопользовательский режим.
Первый способ — последовательный запуск ccdconfig для каждой пары сливаемых партиций примерно таким образом: $ ccdconfig ccd0 128 none /dev/ad0s1d /dev/ar0s1d $ ccdconfig ccd1 128 none /dev/ad0s1e /dev/ar0s1e $ ccdconfig ccd1 128 none /dev/ad0s1f /dev/ar0s1f
Где ccd# — имя создаваемого RAID-устройства, 128 (для примера — это умолчальное значение) — размер (в Кбайт) блоков чередования записи данных на парные диски (понятно выразился? — как это сказать более по русски, не придумал), флаг none отменяет зеркалирование (то есть создает именно sripped-массив, насколько я понял; чтобы сделать массив уровня 1, потребовалось бы указать флаг CCDF_MIRROR или его шестнадцатеричное значение — 0x04). Аргументы понятны — это имена файлов партиций, которые подвергаются конкатенации.
В результате в каталоге /dev будут автоматически созданы новые устройства — /dev/ccd0, /dev/ccd1, /dev/ccd2 (напоминаю — речь идет о версии 5.1, использующей файловую систему устройств; в версиях 4-й ветки эти устройства потребовалось бы предварительно создать скриптом /dev/MAKEDEV или командой mknod), а в каталоге /etc возникнет конфигурационный файл ccd.config.
Второй способ — создать предварительно конфигурационный файл /etc/ccd.conf (которому на самом деле можно дать произвольное имя и поместить где угодно) в текстовом редакторе, и описать в нем объединяемые примерно таким образом: # ccd ileave flags component devices ccd0 128 none /dev/ad0s1d /dev/ar0s1d ccd1 128 none /dev/ad0s1e /dev/ar0s1e ccd2 128 none /dev/ad0s1f /dev/ar0s1f
После чего запустить ту же утилиту конфигурации следующим образом: $ ccdconfig -C
в результате чего все необходимые сведения будут взяты из /etc/ccd.conf (если конфигу дали другое имя — следует указать его как аргумент с полным путем), устройства благополучно созданы.
Я проделал процедуру конкатенации обоими способами — одинаково просто и с идентичным (то есть неизменно превосходным) результатом. К слову — сбросить настройки ccd (если они почему-либо не устраивают) можно командой $ ccdconfig -U
после чего они безболезненно переконфигурируются заново.Завершающие штрихи
Дальнейшее обращение с конкатенированными массивами происходит точно так же, как и с обычными партициями: то есть их нужно разметить на BSD-разделы, на которых создаются файловые системы, которые монтируются в целевые каталоги. За одним исключением — прибегнуть к помощи sysinstall по-прежнему не удастся (по крайней мере, у меня не получилось), так что вся надежда только на собственные руки.
Итак, для начала размечаем созданные массивы: $ bsdlabel -w /dev/ccd0 auto $ bsdlabel -w /dev/ccd1 auto $ bsdlabel -w /dev/ccd2 auto
Что даст нам на каждом из них по партиции c, к использованию непригодной. И потому повторяем процедуру в ручном режиме: $ bsdlabel -e /dev/ccd#
что, как мы помним, вызовет текстовый редактор для прямой модификации дисковой разметки. Копируем строку, описывающую партицию c, изменяем маркирующую ее литеру (например, на d) и тип раздела (с unused на 4.2BSD). Необходимости указывать размеры блока, фрагмента и прочего — нет, эти значения будут определены при создании файловой системы. Что и проделываем: $ newfs /dev/ccd0d $ newfs /dev/ccd1d $ newfs /dev/ccd2d
Теперь созданные файловые системы остается только смонтировать в предназначенные для них каталоги /var, /usr, /home. Однако если последний девственно чист (не зря же мы отказались от создания пользовательского аккаунта при постинсталляционной настройке), то в прочих — имеют место быть файлы, не очень многочисленные (установка ведь велась по принципу минимализма), но жизненно важные для работы системы. Так что предварительно их следует перенести на новые, конкатенированные, файловые системы.
Со старым каталогом /var это проходит без проблем: монтируем предназначенный для него ccd-раздел в какую-нибудь специально созданную точку (например, /mnt/tmp) $ mount /dev/ccd0d /mnt/tmp
и просто перемещаем все содержимое: $ mv /var/* /mnt/tmp
С каталогом /usr поступаем также: $ mount /dev/ccd1d /mnt/tmp2 $ mv /usr* /mnt/tmp2
Если получается — все хорошо. Хотя тут возможны осложнения, если находящиеся в старом /usr файлы как-то используются в текущий момент системой. Конечно, при корректном переходе в однопользовательский режим такого случиться не должно, но чем черт не шутит. Так что не исключено, что для переноса файлов из /usr потребуется перезагрузка с rescue-CD (на деталях останавливаться не буду).
Тем или иным образом перенеся содержимое старых каталогов в новые конкатенированные файловые системы, остается только прописать их в /etc/fstab примерно таким образом: /dev/ccd0e /var ufs rw,noatime /dev/ccd1e /usr ufs rw,noatime /dev/ccd2e /home ufs rw,noatime
После чего — перезагрузка и радость от обретенных RAID'ов. Насколько значительная с точки зрения быстродействия — строго, то есть количественно, судить не возьмусь. Субъективно прирост быстродействия незначительный. Однако и падения оной также не наблюдается. Так что затраченные усилия вполне окупаются удобством обращения с конкатенированными партициями...
