Журнал LinuxFormat - перейти на главную

LXF165-166:ZFS в дей­ст­вии

Материал из Linuxformat
Перейти к: навигация, поиск

ZFS в дей­ст­вии

Содержание

ZFS on Linux: Как начать при­ме­нять

Алек­сей Фе­дор­чук про­дол­жа­ет рас­сказ о но­вой фай­ло­вой сис­те­ме – те­перь в прак­ти­че­ском ас­пек­те.

На­стоя­щая ста­тья по­свя­ще­на прак­ти­че­­ско­­му ис­поль­зо­ванию ZFS в Linux. Оно рас­смот­ре­но на при­ме­ре openSUSE, хо­тя поч­ти все из ска­зан­но­го при­менимо и к лю­бым дру­гим ди­ст­ри­бу­ти­вам – все дис­троспе­ци­фи­че­­ские де­та­ли ого­во­ре­ны яв­ным об­ра­зом.

Об­зор воз­мож­но­стей

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

Для на­ча­ла – немно­го цифр. В от­ли­чие от всех пред­ше­ст­во­вав­ших фай­ло­вых сис­тем и сис­тем раз­ме­щения дан­ных, ZFS яв­ля­ет­ся 128-бит­ной. То есть тео­ре­ти­че­­ское ог­раничение на ее объ­ем и объ­е­мы ее со­став­ляю­щих пре­вы­ша­ют не толь­ко ре­аль­ные, но и во­об­ра­жае­мые по­треб­но­сти лю­бо­го поль­зо­ва­те­ля. По вы­ра­жению соз­да­те­ля ZFS, Джеф­фа Бон­ви­ка [Jeff Bonwick], для ее за­полнения дан­ны­ми и их хранения по­тре­бо­ва­лось бы вски­пя­тить оке­ан.

Так, объ­ем пу­ла хранения дан­ных (zpool – мак­си­маль­ная единица в сис­те­ме ZFS) мо­жет дости­гать ве­ли­чи­ны 3 × 1023 пе­та­байт (а один пе­та­байт, на­пом­ню, это 1015 или 250 байт, в за­ви­си­мо­сти от сис­те­мы счисления). Ка­ж­дый пул мо­жет со­дер­жать до 264 уст­ройств (на­при­мер, дис­ков), а все­го пу­лов в од­ной сис­те­ме мо­жет быть то­же не боль­ше 264.

Пул мо­жет быть раз­де­лен на 264 на­бо­ров дан­ных (dataset – в этом ка­че­­ст­ве вы­сту­па­ют, на­при­мер, от­дель­ные фай­ло­вые сис­те­мы), по 264 ка­ж­дая. Прав­да, ни од­на из та­ких фай­ло­вых сис­тем не мо­жет со­дер­жать боль­ше 248 фай­лов. За­то раз­мер лю­бо­го фай­ла ог­раничи­ва­ет­ся опять же зна­чением в 264 байт.

Ко­ли­че­­ст­во та­ких ог­раничений мож­но ум­но­жить. Как уже бы­ло ска­за­но, они ле­жат вне пре­де­лов че­ло­ве­че­­ско­­го во­об­ра­жения и воз­мож­но­стей. И при­во­жу я их толь­ко для то­го, что­бы все­лить в поль­зо­ва­те­ля уве­рен­ность: ни он сам, ни его вну­ки и пра­вну­ки в ре­аль­но­сти не столк­нут­ся c ог­раничения­ми на раз­мер фай­ло­вой сис­те­мы или от­дель­но­го фай­ла, как это бы­ва­ло при ис­поль­зо­вании FAT или ext2fs.

Так что пе­рей­ду к осо­бен­но­стям ZFS, наи­бо­лее ин­те­рес­ным, по мо­ему мнению, де­ск­топ­но­му поль­зо­ва­те­лю. Здесь в пер­вую оче­редь на­до от­ме­тить гиб­кое управ­ление уст­рой­ст­ва­ми. В пул хранения дан­ных мож­но объ­е­динить про­из­воль­ное (в обо­зна­чен­ных вы­ше пре­де­лах) чис­ло дис­ков и их раз­де­лов. Уст­рой­ст­ва внут­ри пу­ла мо­гут ра­бо­тать в ре­жи­ме рас­ще­п­ления дан­ных, зер­ка­ли­ро­вания или из­бы­точ­но­сти с под­сче­том кон­троль­ных сумм, по­доб­но RAID’ам уровней 0, 1 и 5, со­от­вет­ст­вен­но. В пул мож­но вклю­чать на­ко­пи­те­ли, спе­ци­аль­но пред­на­зна­чен­ные для кэ­ши­ро­вания дис­ко­вых опе­ра­ций, что ак­ту­аль­но при со­вме­ст­ном ис­поль­зо­вании SSD и тра­ди­ци­он­ных вин­че­сте­ров.

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

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

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

Сре­ди дру­гих воз­мож­но­стей ZFS, ин­те­рес­ных на­столь­но­му поль­зо­ва­те­лю, мож­но упо­мя­нуть:

» соз­дание снап­шо­тов фай­ло­вой сис­те­мы, по­зво­ляю­щих восста­но­вить ее со­стояние в слу­чае ошиб­ки;

» клониро­вание фай­ло­вых сис­тем;

» ком­прес­сия дан­ных фай­ло­вой сис­те­мы и де­ду­п­ли­ка­ция (за­мена по­вто­ряю­щих­ся дан­ных ссыл­ка­ми на «пер­во­ис­точник»);

» соз­дание несколь­ких ко­пий бло­ков с кри­ти­че­­ски важ­ны­ми дан­ны­ми и, на­про­тив, воз­мож­ность от­клю­чения про­вер­ки кон­троль­ных сумм для по­вы­шения ско­ро­сти досту­па к ним.

В об­щем, да­же ес­ли не го­во­рить о бы­ст­ро­дей­ст­вии ZFS (а оно весь­ма вы­со­ко, осо­бен­но в мно­го­дис­ко­вых кон­фи­гу­ра­ци­ях), пе­ре­чис­лять ее досто­ин­ст­ва мож­но очень дол­го. Так дол­го, что понево­ле успе­ва­ешь за­дать­ся во­про­сом: а есть ли у нее недостат­ки?

Ра­зу­ме­ет­ся, есть. Хо­тя боль­шая их часть – ско­рее осо­бен­но­сти: на­при­мер, ог­раничения при до­бав­лении или уда­лении на­ко­пи­те­лей в пу­ле, или от­сут­ст­вие под­деж­ки TRIM.

По боль­шо­му сче­ту, для поль­зо­ва­те­ля Linux’а у ZFS об­на­ру­жи­ва­ет­ся два кар­ди­наль­ных недостат­ка: неко­то­рая услож­нен­ность ее ис­поль­зо­вания, обу­слов­лен­ная юри­ди­че­­ски­­ми фак­то­ра­ми, и вы­со­кие тре­бо­вания к ап­па­ра­ту­ре.

Пер­вый недоста­ток ес­ли не ли­к­ви­ди­ро­ван, то сгла­жен тру­да­ми Брай­а­на Бе­лен­дор­фа [Brian Behlendorf] со то­ва­ри­щи и майн­тайнера­ми про­грес­сив­ных ди­ст­ри­бу­ти­вов вку­пе с примк­нув­ши­ми к ним неза­ви­си­мы­ми раз­ра­бот­чи­ка­ми. Ап­па­рат­ные же пре­тен­зии ZFS мы сей­час и рас­смот­рим.

Ап­па­рат­ные по­треб­но­сти

Итак, ZFS пре­достав­ля­ет поль­зо­ва­те­лю весь­ма мно­го воз­мож­но­стей. И по­то­му впра­ве предъ­яв­лять нема­ло пре­тен­зий к ап­па­рат­ной час­ти – про­цес­со­ру (изо­би­лие воз­мож­но­стей ZFS соз­да­ет на него доста­точ­ную на­груз­ку), опе­ра­тив­ной па­мя­ти и дис­ко­вой под­сис­те­ме.

Впро­чем, пре­тен­зии эти от­нюдь не сверхъ­ес­те­ст­вен­ные. Так, про­цес­сор по­дой­дет лю­бой из от­но­си­тель­но со­вре­мен­ных, на­чи­ная, ска­жем, с Core 2 Duo. Минималь­ный объ­ем па­мя­ти оп­ре­де­ля­ет­ся в 2 ГБ, с ого­вор­кой, что при­менение ком­прес­сии и де­ду­п­ли­ка­ции тре­бу­ют 8 ГБ и бо­лее.

Са­ма по се­бе ZFS пре­крас­но функ­циониру­ет и на оди­ноч­ном дис­ке. Од­на­ко в пол­ном бле­ске предстает при двух и бо­лее на­ко­пи­те­лях. В мно­го­дис­ко­вых кон­фи­гу­ра­ци­ях ре­ко­мен­ду­ет­ся разнесение на­ко­пи­те­лей на раз­ные кон­трол­ле­ры: со­вре­мен­ные SSD спо­соб­ны пол­но­стью за­гру­зить все ка­на­лы SATA-III, и рав­но­мер­ное рас­пре­де­ление на­груз­ки на па­ру кон­трол­ле­ров мо­жет уве­ли­чить бы­ст­ро­дей­ст­вие.

К «же­лез­ным» пре­тен­зи­ям до­бав­ля­ют­ся и при­тя­зания про­грамм­ные. В пер­вую оче­редь, ZFS on Linux потре­бу­ет 64-бит­ной сбор­ки этой ОС, по­сколь­ку в 32-раз­ряд­ных сис­те­мах дей­ст­ву­ет ог­раничение на ад­рес­ное про­стран­ст­во фи­зи­че­­ской па­мя­ти. Кро­ме то­го, в кон­фи­гу­ра­ции яд­ра должнв быть от­клю­че­на оп­ция CONFIG_PREEMPT. По­это­му, на­при­мер, в openSUSE ZFS мо­жет ис­поль­зо­вать­ся с ядром kernel-default, но не kernel-desktop, ка­ко­вое, во­пре­ки на­званию, уста­нав­ли­ва­ет­ся по умол­чанию при стан­дарт­ной на­столь­ной ин­стал­ля­ции.

Ес­ли вас при­влек­ли досто­ин­ст­ва ZFS и не уст­ра­ши­ли ее «же­лез­ные» ап­пе­ти­ты, са­мое вре­мя оп­ро­бо­вать ее в де­ле. Что по­тре­бу­ет зна­ком­ст­ва с неко­то­ры­ми спе­ци­фи­че­­ски­­ми по­ня­тия­ми.

Тер­ми­но­ло­гия

» Пул хранения дан­ных [zpool] – цен­траль­ное по­ня­тие ZFS. В него мо­жет объ­е­ди­нять­ся несколь­ко фи­зи­че­­ских уст­ройств хранения – дис­ков или дис­ко­вых раз­де­лов, при­чем пер­вый ва­ри­ант ре­ко­мен­ду­ет­ся. Но не за­пре­ще­но и соз­дание пу­ла из од­но­го дис­ка или его раз­де­ла. В ка­ж­дый пул вхо­дят

> Вир­ту­аль­ные уст­рой­ст­ва [vdev], од­но или несколь­ко. В ка­че­­ст­ве та­ко­вых мо­гут вы­сту­пать уст­рой­ст­ва без из­бы­точ­но­сти (то есть все те же дис­ки и/или их раз­де­лы) или уст­рой­ст­ва с из­бы­точ­но­стью – зер­ка­ла и мас­си­вы ти­па RAID-Z.

> Зеркаль­ное уст­рой­ст­во [mirror] – вир­ту­аль­ное уст­рой­ст­во, хра­ня­щее на двух или бо­лее фи­зи­че­­ских уст­рой­ст­вах, но при чет­ном их ко­ли­че­­ст­ве, иден­тич­ные ко­пии дан­ных на слу­чай от­ка­за дис­ка.

> RAID-Z – вир­ту­аль­ное уст­рой­ст­во на несколь­ких уст­ройств фи­зи­че­­ских, пред­на­зна­чен­ное для хранения дан­ных и их кон­троль­ных сумм с од­но­крат­ным или двой­ным кон­тро­лем чет­но­сти. В пер­вом слу­чае тео­ре­ти­че­­ски тре­бу­ет­ся не менее двух, во вто­ром – не менее трех фи­зи­че­­ских уст­ройств.

Ес­ли пул об­ра­зо­ван уст­рой­ст­ва­ми без из­бы­точ­но­сти (про­сто дис­ка­ми или раз­де­ла­ми), то од­но из vdev, со­от­вет­ст­вую­щее ему це­ли­ком, вы­сту­па­ет как

> Корневое уст­рой­ст­во. Пул из уст­ройств с из­бы­точ­но­стью мо­жет со­дер­жать бо­лее од­но­го корнево­го уст­рой­ст­ва – на­при­мер, два зер­ка­ла.

Пу­лы, об­ра­зо­ван­ные вир­ту­аль­ны­ми уст­рой­ст­ва­ми, слу­жат вме­сти­ли­щем для на­бо­ров дан­ных [dataset]. Они бы­ва­ют сле­дую­щих ви­дов:

» фай­ло­вая сис­те­ма [filesystem] – на­бор дан­ных, смон­ти­ро­ван­ный в оп­ре­де­лен­ной точ­ке и ве­ду­щий се­бя по­доб­но лю­бой дру­гой фай­ло­вой сис­те­ме;

» снап­шот [snapshot] – мо­мен­таль­ный снимок те­ку­ще­го со­стояния фай­ло­вой сис­те­мы, доступ­ный толь­ко для чтения;

» клон [clone] – точ­ная ко­пия фай­ло­вой сис­те­мы в мо­мент его соз­дания; соз­да­ет­ся на осно­ве сним­ка, но, в от­ли­чие от того, досту­пен для за­пи­си;

» том [volume] – на­бор дан­ных, эму­ли­рую­щий фи­зи­че­­ское уст­рой­ст­во, на­при­мер, раз­дел под­кач­ки.

На­бо­ры дан­ных пу­ла долж­ны но­сить уникаль­ные име­на та­ко­го ви­да:

pool_name/path/[dataset_name][@snapshot_name]

Пу­лы и на­бо­ры дан­ных в име­ну­ют­ся по пра­ви­лам про­стран­ст­ва имен ZFS, впро­чем, до­воль­но про­стым. За­пре­щен­ны­ми сим­во­ла­ми для всех яв­ля­ют­ся сим­во­лы под­чер­ки­вания, де­фи­са, двое­то­чия, точ­ки и про­цен­та. Имя пу­ла при этом обя­за­тель­но долж­но на­чи­нать­ся с ал­фа­вит­но­го сим­во­ла и не сов­па­дать с одним из за­ре­зер­ви­ро­ван­ных имен – log, mirror, raidz или spare (по­следнее обо­зна­ча­ет имя уст­рой­ст­ва «го­ря­че­го» ре­зер­ва). Все осталь­ные име­на, в со­от­вет­ст­вие с де­мо­кра­ти­че­­ски­­ми тра­ди­ция­ми про­стран­ст­ва имен ZFS, раз­ре­ше­ны.

А вот об име­нах фи­зи­че­­ских уст­ройств, вклю­чае­мых в пул, сле­ду­ет ска­зать осо­бо.

Мо­де­ли име­но­вания уст­ройств

В со­вре­мен­ном Linux’е ис­поль­зо­вание для на­ко­пи­те­лей имен «верхнего уров­ня», имею­щих вид /dev/sda, не яв­ля­ет­ся обя­за­тель­ным, а в неко­то­рых слу­ча­ях и про­сто неже­ла­тель­но. Од­на­ко пра­ви­ла менед­же­ра уст­ройств udev по­зво­ля­ют оп­ре­де­лять и дру­гие мо­де­ли иден­ти­фи­ка­ции на­ко­пи­те­лей.

В ча­ст­но­сти, штат­ны­ми сред­ст­ва­ми дис­ко­вой раз­мет­ки дистрибутива openSUSE пре­ду­смот­ре­ны ва­ри­ан­ты иден­ти­фи­ка­ции накопителей по:

» метке тома (/dev/disk/by-label);

» иден­ти­фи­ка­то­ру дис­ка (/dev/disk/by-id);

» пу­ти к дис­ко­во­му уст­рой­ст­ву (/dev/disk/by-path);

» универсальному уникальному идентификатору, Universally Unique IDentifier (/dev/disk/by-uuid).

С пол­ным спи­ском ва­ри­ан­тов иден­ти­фи­ка­ции блоч­ных уст­ройств мож­но оз­на­ко­мить­ся, про­смот­рев име­на под­ка­та­ло­гов в ка­та­ло­ге /dev/disk; их со­дер­жи­мое – это сим­во­ли­че­­ские ссыл­ки на име­на «верхнего уров­ня».

С иден­ти­фи­ка­ци­ей по мет­ке то­ма и по UUID, ве­ро­ят­но, зна­ко­мо боль­шин­ст­во чи­та­те­лей. И к то­му же в про­стран­ст­ве имен ZFS они не ис­поль­зу­ют­ся. А вот с иден­ти­фи­ка­ци­ей by-path и by-id нуж­но по­зна­ко­мить­ся по­бли­же.

Мо­дель име­но­вания by-path ис­поль­зу­ет име­на уст­ройств, при­вя­зан­ные к их по­ло­жению на шине PCI и вклю­чаю­щие но­мер ши­ны и ка­на­ла на ней. Имя дис­ко­во­го уст­рой­ст­ва вы­гля­дит приблизитель­но так:

pci-0000:00:1f.2-scsi-0:0:0:0

Дис­ко­вые раз­де­лы мар­ки­ру­ют­ся до­бав­лением к имени уст­рой­ст­ва суф­фик­са part#.

Мо­дель име­но­вания by-path иден­ти­фи­ци­ру­ет уст­рой­ст­ва вполне од­но­знач­но, и осо­бен­но эф­фек­тив­на при на­ли­чии бо­лее чем од­но­го дис­ко­во­го кон­трол­ле­ра. Од­на­ко са­ми име­на и уст­ройств, и раз­де­лов опи­сы­ва­ют­ся до­воль­но слож­ной для воспри­ятия по­сле­до­ва­тель­но­стью. Да и в боль­шин­ст­ве «де­ск­топ­ных» си­туа­ций мо­дель эта из­бы­точ­на.

Мо­дель иден­ти­фи­ка­ции by-id пред­став­ля­ет име­на но­си­те­лей ин­фор­ма­ции в фор­ме, наи­бо­лее доступ­ной для че­ло­ве­че­­ско­­го понимания. Они об­ра­зо­ва­ны из на­звания ин­тер­фей­са, имени про­из­во­ди­те­ля, но­ме­ра мо­де­ли, се­рий­но­го но­ме­ра уст­рой­ст­ва и, при необ­хо­ди­мо­сти, но­ме­ра раз­де­ла, на­при­мер:

ata-SanDisk_SDSSDX120GG25_120823400863-part1

Та­ким об­ра­зом, все ком­понен­ты имени уст­рой­ст­ва в мо­де­ли by-id оп­ре­де­ля­ют­ся не усло­вия­ми его под­клю­чения или ка­ки­ми-то пра­ви­лами, а за­да­ют­ся про­из­во­ди­те­лем и же­ст­ко про­ши­ты в «же­ле­зе». И по­то­му эта мо­дель яв­ля­ет­ся наи­бо­лее од­но­знач­ной для име­но­вания уст­ройств. А так­же, что нема­ло­важ­но, стро­ит­ся по по­нят­ной че­ло­ве­ку ло­ги­ке. Не слу­чай­но имен­но она при­ня­та по умол­чанию в ин­стал­ля­то­ре openSUSE.

Ка­кую из мо­де­лей име­но­вания уст­ройств вы­брать для дан­но­го пу­ла – за­ви­сит от его на­зна­чения и мас­шта­бов. Име­на «верхнего уров­ня» це­ле­со­об­раз­но при­ме­нять для од­но­дис­ко­вых пу­лов (осо­бен­но ес­ли в ма­шине вто­ро­го дис­ка нет и не пред­ви­дит­ся, как обыч­но бы­ва­ет в но­ут­бу­ках). Они же, по при­чине удо­бо­по­нят­но­сти и про­сто­ты, ре­ко­мен­ду­ют­ся для экс­пе­ри­мен­таль­ных и раз­ра­ба­ты­вае­мых пу­лов. И очень не ре­ко­мен­ду­ют­ся – во всех осталь­ных слу­ча­ях, так как за­ви­сят от усло­вий под­клю­чения на­ко­пи­те­лей.

Это­го недостат­ка ли­ше­на мо­дель by-id: как пи­шет Брай­ан, при ее ис­поль­зо­вании «дис­ки мож­но от­клю­чить, слу­чай­но сме­шать и под­клю­чить опять про­из­воль­ным об­ра­зом – и пул бу­дет по-прежнему кор­рект­но ра­бо­тать». Как ее недоста­ток рас­смат­ри­ва­ет­ся слож­ность кон­фи­гу­ри­ро­вания боль­ших пу­лов с из­бы­точ­но­стью. И по­то­му она ре­ко­мен­ду­ет­ся для при­менения в «де­ск­топ­ных» и «квар­тир­ных» (ти­па се­мей­но­го сер­ве­ра) усло­ви­ях.

Для боль­ших (бо­лее 10 уст­ройств) пу­лов из дис­ков, под­клю­чен­ных к несколь­ким кон­трол­ле­рам, ре­ко­мен­ду­ет­ся иден­ти­фи­ка­ция by-path. Од­на­ко в на­ших це­лях она гро­мозд­ка и из­бы­точ­на.

На­конец, ZFS on Linux пред­ла­га­ет и соб­ст­вен­ную мо­дель иден­ти­фи­ка­ции – /dev/disk/zpool, в ко­то­ром име­нам by-path ста­вят­ся в со­от­вет­ст­вие уникаль­ные и осмыс­лен­ные «че­ло­ве­ко­чи­тае­мые» име­на, да­вае­мые поль­зо­ва­те­лем. Мо­дель эта ре­ко­мен­ду­ет­ся для очень боль­ших пу­лов, ка­ко­вых на на­столь­ной ма­шине ожи­дать труд­но.

Так что даль­ше я бу­ду ис­поль­зо­вать име­на «верхнего уров­ня», го­во­ря об аб­ст­ракт­ных или экс­пе­ри­мен­таль­ных си­туа­ци­ях, и об име­нах by-id, когда речь зай­дет о прак­ти­че­­ских при­ме­рах при­менения ZFS.

Вклю­чение под­держ­ки ZFS

Для прак­ти­че­­ско­­го ис­поль­зо­вания ZFS on Linux пер­во-на­пер­во необ­хо­ди­мо обес­пе­чить ее под­держ­ку в ва­шем ди­ст­ри­бу­ти­ве – ибо по при­чи­нам, опи­сан­ным в пре­ды­ду­щей ста­тье, са­ма со­бой она не под­дер­жит­ся ни в од­ном Linux’е.

Как это сде­лать, за­ви­сит от ди­ст­ри­бу­ти­ва. В Се­ти мож­но най­ти под­роб­ные ин­ст­рук­ции для Ubuntu и Gentoo, ко­то­рые лег­ко рас­про­стра­ня­ют­ся на кло­ны обе­их сис­тем. Не столь­ко ин­ст­рук­ции, сколь­ко ру­ко­во­дства к са­мо­стоя­тель­но­му дей­ст­вию име­ют­ся на сай­те про­ек­та ZFS on Linux для аб­ст­ракт­ных RPM- и Deb-based ди­ст­ри­бу­ти­вов. Я же рас­ска­жу о том, как это де­ла­ет­ся в openSUSE ре­ли­зов 12.1 и 12.2.

Как вы на­вер­ня­ка до­га­да­лись, ZFS не под­дер­жи­ва­ет­ся в openSUSE ни «ис­ка­роп­ки», ни в офи­ци­аль­ных ре­по­зи­то­ри­ях. Но за­то в ре­по­зи­то­ри­ях неофи­ци­аль­ных, так на­зы­вае­мых «до­машних», па­ке­ты ее под­держ­ки пред­став­ле­ны аж в двух эк­зем­п­ля­рах: в munix9 и в ghaskins. Точ­ные их ад­ре­са лег­ко най­ти че­рез сис­те­му OBS (Open Builging System) по клю­че­во­му сло­ву zfs.

Ка­ко­му из ре­по­зи­то­ри­ев от­дать пред­поч­тение – во­прос спор­ный. Пер­вые свои опы­ты с ZFS on Linux я про­во­дил, осно­вы­ва­ясь на па­ке­тах из munix9. И они про­шли без вся­ких осложнений, хо­тя и ве­лись в су­гу­бо экс­пе­ри­мен­таль­ном ре­жи­ме. К мо­мен­ту понимания, что эта сис­те­ма для ме­ня – «все­рь­ез и на­дол­го», по­след­няя тогда вер­сия zfs име­лась толь­ко в ре­по­зи­то­рии ghaskins. Од­на­ко его ис­поль­зо­вание тре­бу­ет неко­то­рых до­полнитель­ных манипу­ля­ций.

Кро­ме то­го, в ре­по­зи­то­рии ghaskins на дан­ный мо­мент име­ют­ся па­ке­ты толь­ко для openSUSE ре­ли­зов 12.1 и 12.2. Ре­по­зи­то­рий же munix9 ох­ва­ты­ва­ет все ак­ту­аль­ные ныне вер­сии SLE и openSUSE. вклю­чая Tumbleweed и Factory.

Раз­ли­ча­ют­ся ре­по­зи­то­рии и на­бо­ром па­ке­тов (рис. 1 и 2). Так что окон­ча­тель­ный вы­бор я пре­достав­ляю чи­та­те­лю. Но на ка­кой бы ре­по­зи­то­рий он ни пал, его сле­ду­ет под­клю­чить. Тех, кто с этим за­труд­ня­ет­ся, от­сы­лаю ко врез­ке.

Под­клю­чение ре­по­зи­то­рия

Сде­лать это мож­но лю­бым из трех спо­со­бов. Пер­вый – че­рез команд­ную стро­ку, с по­мо­щью zypper’а:

# zypper ar -f [URL] [Name]

Вто­рой – че­рез центр управ­ления YaST2 (см врез­ку «Шаг за ша­гом» на предыдущей странице).

По­сле под­клю­чения ре­по­зи­то­рия на­до бу­дет уста­но­вить (с по­мо­щью zypper’а или мо­ду­ля управ­ления па­ке­та­ми YaST’а) до­полнитель­ные ком­понен­ты (рис. 3).

На­конец, тре­тий спо­соб, для са­мых ленивых – оты­скать па­ке­ты zfs, spl и со­пут­ст­вую­щие че­рез OBS и при­бег­нуть к «уста­нов­ке в один клик». В этом слу­чае под­клю­чение ре­по­зи­то­ри­ев бу­дет со­вме­ще­но с уста­нов­кой па­ке­тов.


Воз­мож­но, не вред­ным ока­жет­ся и па­кет zfs-test. А вот zfs-dracut, пред­на­зна­чен­ный для соз­дания initrd с под­держ­кой ZFS, несмот­ря на его по­тен­ци­аль­ную нуж­ность, уста­но­вить не уда­ст­ся: тре­буе­мый для него па­кет dracut в openSUSE по­ка не под­дер­жи­ва­ет­ся.

Сле­ду­ет учесть, что при ис­поль­зо­вании яд­ра kernel-desktop (а ско­рее все­го, так оно и есть) па­кет zfs-kmp-default по­тянет за со­бой и со­от­вет­ст­вую­щее яд­ро kernel-default. Пункт за­груз­ки ко­то­ро­го бу­дет внесен в ме­ню Grub, но не бу­дет от­ме­чен как умол­чаль­ный – этим на­до оза­бо­тить­ся са­мо­му.

И, на­конец, при ис­поль­зо­вании па­ке­тов из ghaskins по­тре­бу­ет­ся, ско­рее все­го, сде­лать в ка­та­ло­гах /etc/init.d/rc3.d и /etc/init.d/rc5.d сим­во­ли­че­­ские ссыл­ки на файл /etc/init.d/zfs. Ина­че фай­ло­вые сис­те­мы ZFS, к соз­данию ко­то­рых мы при­бли­жа­ем­ся, не бу­дут ав­то­ма­ти­че­­ски мон­ти­ро­вать­ся при стар­те и раз­мон­ти­ро­вать­ся при оста­но­ве сис­те­мы.

При ис­поль­зо­вании ре­по­зи­то­рия munix9 эти дей­ст­вия бу­дут вы­полнены в хо­де уста­нов­ки па­ке­тов нечув­ст­ви­тель­но для пользователя.

Вот те­перь мож­но при­сту­пать к при­менению ZFS в мир­ных прак­ти­че­­ских це­лях. Что мы с вами и предпримем – но уже в сле­дую­щем но­ме­ре. |

Персональные инструменты
купить
подписаться
Яндекс.Метрика