Гэтай вясной мы ўжо абмеркавалі некаторыя ўступныя тэмы, напрыклад, и . У другой з іх мы нават паабяцалі працягнуць вывучэнне прадукцыйнасці розных шматдыскавых тапалогій у ZFS. Гэта файлавая сістэма наступнага пакалення, якая зараз укараняецца паўсюль: ад да .
Ну што ж, сёння самы прыдатны дзень для знаёмства з ZFS, дапытлівыя чытачы. Проста ведайце, што па сціплай адзнацы распрацоўніка OpenZFS Мэта Арэнса, "гэта сапраўды складана".
Але перш чым мы дабяромся да лічбаў - а яны будуць, абяцаю - па ўсіх варыянтах васьмідыскавай канфігурацыі ZFS, трэба пагаварыць аб тым, як наогул ZFS захоўвае дадзеныя на кружэлцы.
Spool, vdev і device
Гэтая дыяграма поўнага пула складаецца з тры дапаможных vdev'а, па адным кожнага класа, і чатыры для RAIDz2
Звычайна няма чыннікаў ствараць пул з неадпаведных тыпаў і памераў vdev - але калі жадаеце, нішто не мяшае вам гэта зрабіць
Каб сапраўды зразумець файлавую сістэму ZFS, трэба ўважліва паглядзець на яе фактычную структуру. Па-першае, ZFS аб'ядноўвае традыцыйныя ўзроўні кіравання тамамі і файлавай сістэмы. Па-другое, яна выкарыстоўвае транзакцыйны механізм капіявання пры запісе. Гэтыя асаблівасці азначаюць, што сістэма структурна вельмі адрозніваецца ад звычайных файлавых сістэм і RAID-масіваў. Першы набор асноўных будаўнічых блокаў для разумення: гэта пул захоўвання (zpool), віртуальная прылада (vdev) і рэальная прылада (device).
zpool
Пул захоўвання zpool - самая верхняя структура ZFS. Кожны пул змяшчае адну ці некалькі віртуальных прылад. У сваю чаргу, кожнае з іх утрымоўвае адну або некалькі рэальных прылад (device). Віртуальныя пулы - гэта аўтаномныя блокі. Адзін фізічны кампутар можа змяшчаць два ці больш асобных пула, але кожны цалкам незалежны ад іншых. Пулы не могуць сумесна выкарыстоўваць віртуальныя прылады.
Надмернасць ZFS знаходзіцца на ўзроўні віртуальных прылад, а не на ўзроўні пулаў. На ўзроўні пулаў няма абсалютна ніякай надмернасці - калі які-небудзь назапашвальнік vdev ці адмысловы vdev губляецца, то разам з ім губляецца і ўвесь пул.
Сучасныя пулы захоўвання могуць перажыць страту кэша або часопіса віртуальнай прылады - хоць яны могуць страціць невялікую колькасць брудных дадзеных, калі страцяць часопіс vdev падчас адключэння харчавання або збою сістэмы.
Ёсць распаўсюджаная памылка, што "паласы дадзеных" (страйпы) ZFS запісваюцца праз увесь пул. Гэта няслушна. Zpool – зусім не пацешны RAID0, гэта хутчэй пацешны са складаным зменлівым механізмам размеркавання.
Па большай частцы запісу размяркоўваюцца паміж даступнымі віртуальнымі прыладамі ў адпаведнасці з наяўнай вольнай прасторай, так што тэарэтычна ўсе яны будуць запоўненыя адначасова. У пазнейшых версіях ZFS улічваецца бягучае выкарыстанне (утылізацыю) vdev — калі адна віртуальная прылада значна загружаней іншай (напрыклад, з-за нагрузкі на чытанне), яго часова прапусцяць для запісу, нягледзячы на наяўнасць самага высокага каэфіцыента вольнай прасторы.
Механізм вызначэння ўтылізацыі, убудаваны ў сучасныя метады размеркавання запісу ZFS, можа паменшыць затрымку і павялічыць прапускную здольнасць у перыяды незвычайна высокай нагрузкі - але гэта не карт-бланш на мімавольнае змешванне павольных HDD і хуткіх SSD у адным пуле. Такі нераўнацэнны пул усё роўна будзе працаваць з хуткасцю самай павольнай прылады, гэта значыць як быццам ён цалкам складзены з такіх прылад.
адз
Кожны пул захоўвання складаецца з адной або некалькіх віртуальных прылад (virtual device, vdev). У сваю чаргу, кожны vdev уключае адно або некалькі рэальных прылад. Большасць віртуальных прылад выкарыстоўваюцца для простага захоўвання дадзеных, але існуе некалькі дапаможных класаў vdev, у тым ліку CACHE, LOG і SPECIAL. Кожны з гэтых тыпаў vdev можа мець адну з пяці тапалогій: адзіная прылада (single-device), RAIDz1, RAIDz2, RAIDz3 ці люстэрка (mirror).
RAIDz1, RAIDz2 і RAIDz3 – гэта адмысловыя разнавіднасці таго, што олды назавуць RAID падвойнай (дыяганальнай) цотнасці. 1, 2 і 3 адносяцца да таго, колькі блокаў цотнасці выдзелена для кожнай паласы дадзеных. Замест асобных дыскаў для забеспячэння цотнасці віртуальныя прылады RAIDz паўраўнамерна размяркоўваюць гэтую цотнасць па дысках. Масіў RAIDz можа страціць столькі дыскаў, колькі ў яго блокаў цотнасці; калі ён страціць яшчэ адзін, то выйдзе са строю і забярэ з сабой пул захоўвання.
У люстраных віртуальных прыладах (mirror vdev) кожны блок захоўваецца на кожнай прыладзе ў vdev. Хоць найболей распаўсюджаныя падвойныя люстэркі (two-wide), у люстэрку можа быць любая адвольная колькасць прылад – у вялікіх усталёўках для падвышэння прадукцыйнасці чытання і адмоваўстойлівасці часта выкарыстоўваюцца патройныя. Люстэрка vdev можа перажыць любы збой, пакуль працягвае працаваць хаця б адна прылада ў vdev.
Адзіночныя vdev па сваёй сутнасці небяспечныя. Такая віртуальная прылада не перажыве ніводнага збою — і калі выкарыстоўваецца ў якасці сховішча ці адмысловага vdev, тое яго збой прывядзе да знішчэння ўсяго пула. Будзьце тут вельмі, вельмі асьцярожныя.
Віртуальныя прылады CACHE, LOG і SPECIAL могуць быць створаны па любой з вышэйпералічаных тапалогій - але памятаеце, што страта віртуальнай прылады SPECIAL азначае страту пула, таму настойліва рэкамендуецца залішняя тапалогія.
прылада
Верагодна, гэта самы просты для разумення тэрмін у ZFS - гэта літаральна блокавая прылада адвольнага доступу. Памятайце, што віртуальныя прылады складаюцца з асобных прылад, а пул зроблены з віртуальных прылад.
Дыскі - магнітныя або цвердацельнай - з'яўляюцца найбольш распаўсюджанымі блокавымі прыладамі, якія выкарыстоўваюцца ў якасці будаўнічых блокаў vdev. Аднак падыдзе любы девайс з дэскрыптарам у /dev - так што ў якасці асобных прылад можна выкарыстоўваць цэлыя апаратныя RAID-масівы.
Просты raw-файл з'яўляецца адным з найважнейшых альтэрнатыўных блокавых прылад, з якіх можа быць пабудаваны vdev. Тэставыя пулы з - вельмі зручны спосаб правяраць каманды пула і глядзець, колькі месца даступна ў пуле ці віртуальнай прыладзе дадзенай тапалогіі.
Можаце стварыць тэставы пул з разрэджаных файлаў усяго за некалькі секунд - але не забудзьцеся потым выдаліць увесь пул і яго кампаненты
Дапусцім, вы хочаце паставіць сервер на восем дыскаў і плануеце выкарыстоўваць дыскі па 10 ТБ (~9300 ГіБ) - але вы не ўпэўненыя, якая тапалогія лепш за ўсё адпавядае вашым патрэбам. У прыведзеным вышэй прыкладзе мы за лічаныя секунды будуем тэставы пул з разрэджаных файлаў – і зараз ведаем, што RAIDz2 vdev з васьмі дыскаў па 10 ТБ забяспечвае 50 Тіб карыснай ёмістасці.
Яшчэ адзін адмысловы клас прылад – SPARE (запасныя). Прылады гарачай замены, у адрозненне ад звычайных прылад, прыналежаць усяму пулу, а не адной віртуальнай прыладзе. Калі нейкі vdev у пуле выходзіць з ладу, а запасная прылада падлучанае да пула і даступна, то яно аўтаматычна далучыцца да пацярпелага vdev.
Пасля падлучэння да пацярпелага vdev запасны девайс пачынае атрымліваць копіі ці рэканструкцыі дадзеных, якія павінны быць на адсутнай прыладзе. У традыцыйным RAID гэта называецца аднаўленнем (rebuilding), а ў ZFS гэта "аднаўленне надмернасці" (resilvering).
Важна адзначыць, што запасныя прылады не назаўжды замяняюць якія выйшлі з ладу прылады. Гэта толькі часавая замена для скарачэння часу, на працягу якога назіраецца дэградацыя vdev. Пасля таго, як адміністратар замяніў прыладу vdev, якая выйшла з ладу, тое адбываецца аднаўленне надмернасці на гэтую сталую прыладу, а SPARE адлучаецца ад vdev і вяртаецца да працы запасным на ўвесь пул.
Наборы дадзеных, блокі і сектары
Наступны набор будаўнічых блокаў, якія трэба зразумець у нашым вандраванні па ZFS, ставіцца не гэтулькі да апаратнага забеспячэння, колькі да таго, як арганізаваныя і захоўваюцца самі дадзеныя. Мы тут прапускаем некалькі ўзроўняў - такіх як metaslab - каб не нагрувашчваць дэталі, захоўваючы разуменне агульнай структуры.
Набор даных (dataset)
Калі мы ўпершыню ствараем набор дадзеных, ён паказвае ўсю даступную прастору пула. Затым мы ўсталёўваем квоту - і змяняем кропку мантавання. Магія!
Zvol - гэта па большай частцы проста набор дадзеных, пазбаўлены свайго пласта файлавай сістэмы, які мы заменны тут цалкам звычайнай файлавай сістэмай.
Набор дадзеных ZFS прыкладна аналагічны стандартнай змантаванай файлавай сістэме. Як і звычайная файлавая сістэма, на першы погляд ён здаецца "проста яшчэ адной тэчкай". Але таксама, як і ў звычайных якія мантуюцца файлавых сістэм, у кожнага набору дадзеных ZFS уласны набор базавых уласцівасцяў.
Першым чынам, у набору дадзеных можа быць прызначаная квота. Калі ўсталяваць zfs set quota=100G poolname/datasetname, то вы не зможаце запісаць у змантаваную тэчку /poolname/datasetname больш, чым 100 ГіБ.
Заўважылі наяўнасць - і адсутнасць - слэшаў у пачатку кожнага радка? У кожнага набору дадзеных сваё месца як у іерархіі ZFS, так і ў іерархіі сістэмнага мантавання. У іерархіі ZFS няма кіроўнага слэша - вы пачынаеце з імя пула, а затым шляхі ад аднаго набору дадзеных да наступнага. Напрыклад, pool/parent/child для набору дадзеных з імем child пад бацькоўскім наборам дадзеных parent у пуле з крэатыўнай назвай pool.
Па змаўчанні, кропка мантавання набору дадзеных будзе эквівалентная яго імя ў іерархіі ZFS, са слэшам у пачатку - пул з назвай pool прымантуецца як /pool, набор дадзеных parent мантуецца ў /pool/parent, а даччыны набор дадзеных child змантуецца ў /pool/parent/child. Аднак сістэмную кропку мантавання набору дадзеных можна змяніць.
Калі мы пакажам zfs set mountpoint=/lol pool/parent/child, то набор дадзеных pool/parent/child змантуецца ў сістэму як /lol.
У дадатак да набораў дадзеных, мы павінны згадаць тамы (zvols). Том прыкладна аналагічны набору дадзеных, за выключэннем таго, што ў ім фактычна няма файлавай сістэмы - гэта проста блокавая прылада. Вы можаце, напрыклад, стварыць zvol з імем mypool/myzvol, затым адфарматаваць яго з файлавай сістэмай ext4, а затым змантаваць гэтую файлавую сістэму - зараз у вас ёсць файлавая сістэма ext4, але з падтрымкай усіх функцый бяспекі ZFS! Гэта можа здацца дурным на адным кампутары, але мае значна больш сэнсу ў якасці бэкенда пры экспартаванні прылады iSCSI.
блокі
Файл прадстаўлены адным ці некалькімі блокамі. Кожны блок захоўваецца на адной віртуальнай прыладзе. Памер блока звычайна роўны параметру recordsize, але можа быць паменшаны да 2^ashift, калі змяшчае метададзеныя ці невялікі файл.
Мы сапраўды, сапраўды не жартуем з нагоды велізарнай шкоды прадукцыйнасці, калі ўсталяваць занадта маленькі ashift
У пуле ZFS усе дадзеныя, уключаючы метададзеныя, захоўваюцца ў блоках. Максімальны памер блока для кожнага набору дадзеных вызначаецца ва ўласцівасці recordsize (памер запісу). Памер запісу можа змяняцца, але гэта не зменіць памер або размяшчэнне любых блокаў, якія ўжо былі запісаны ў набор дадзеных - ён дзейнічае толькі для новых блокаў па меры іх запісу.
Калі не вызначана іншае, то бягучы памер запісу па змаўчанні роўны 128 КіБ. Гэта свайго роду няпросты кампраміс, у якім прадукцыйнасць будзе не ідэальнай, але і не жахлівай у большасці выпадкаў. Recordsize можна ўсталяваць на любое значэнне ад 4K да 1M (з дадатковымі наладамі recordsize можна ўсталяваць яшчэ больш, але гэта рэдка бывае добрай ідэяй).
Любы блок спасылаецца на дадзеныя толькі аднаго файла - вы не можаце ўціснуць два розных файла ў адзін блок. Кожны файл складаецца з аднаго ці некалькіх блокаў, у залежнасці ад памеру. Калі памер файла меншы за памер запісу, ён захаваецца ў блоку меншага памеру — напрыклад, блок з файлам 2 КіБ зойме толькі адзін сектар 4 КіБ на дыску.
Калі файл дастаткова вялікі і патрабуе некалькі блокаў, то ўсе запісы з гэтым файлам будуць мець памер recordsize - уключаючы апошні запіс, асноўная частка якога можа апынуцца .
У тамоў zvol няма ўласцівасці recordsize - замест гэтага ў іх ёсць эквівалентная ўласцівасць volblocksize.
Сектары
Апошні, самы базавы будаўнічы блок - сектар. Гэта найменшая фізічная адзінка, якая можа быць запісана ці лічаная з базавай прылады. На працягу некалькіх дзесяцігоддзяў у большасці дыскаў выкарыстоўваліся сектары па 512 байт. У апошні час большасць дыскаў наладжана на сектары 4 КіБ, а ў некаторых – асабліва SSD – сектара 8 КіБ ці нават больш.
У сістэме ZFS ёсць уласцівасць, якое дазваляе ўручную ўсталяваць памер сектара. Гэта ўласцівасць ashift. Некалькі заблытана, што ashift з'яўляецца ступенню двойкі. Напрыклад, ashift=9 азначае памер сектара 2^9, або 512 байт.
ZFS запытвае ў аперацыйнай сістэмы падрабязную інфармацыю аб кожнай блокавай прыладзе, калі яно дадаецца ў новы vdev, і тэарэтычна аўтаматычна ўсталёўвае ashift належным чынам на аснове гэтай інфармацыі. Нажаль, шматлікія кружэлкі хлусяць аб сваім памеры сектара, каб захаваць сумяшчальнасць з Windows XP (якая была няздольная зразумець кружэлкі з іншымі памерамі сектараў).
Гэта азначае, што адміністратару ZFS настойліва рэкамендуецца ведаць фактычны памер сектара сваіх прылад і ўручную ўсталёўваць ashift. Калі ўсталяваны занадта маленькі ashift, то астранамічна павялічваецца колькасць аперацый чытання/запісы. Так, запіс 512-байтавых «сектараў» у рэальны сектар 4 КіБ азначае неабходнасць запісаць першы «сектар», затым прачытаць сектар 4 КіБ, змяніць яго з другім 512-байтавым «сектарам», запісаць яго назад у новы сектар 4 КіБ і гэтак далей для кожнага запісу.
У рэальным свеце такі штраф б'е па цвердацельнай назапашвальніках Samsung EVO, для якіх павінен дзейнічаць ashift=13, але гэтыя SSD хлусяць аб сваім памеры сектара, і таму па змаўчанні усталёўваецца ashift=9. Калі дасведчаны сістэмны адміністратар не зменіць гэты параметр, то гэты SSD працуе павольней звычайнага магнітнага HDD.
Для параўнання, за занадта вялікі памер ashift няма практычна ніякага штрафу. Рэальнага зніжэння прадукцыйнасці няма, а павелічэнне невыкарыстоўваемай прасторы бясконца мала (ці роўна нулю пры ўключаным сціску). Таму мы настойліва раім нават тым дыскам, якія сапраўды выкарыстоўваюць 512-байтавыя сектары, усталяваць ashift=12 ці нават ashift=13, Каб упэўнена глядзець у будучыню.
ўласцівасць ashift усталёўваецца для кожнай віртуальнай прылады vdev, а не для пула, як многія памылкова думаюць - і не змяняецца пасля ўстаноўкі. Калі вы выпадкова збілі ashift пры даданні новага vdev у пул, то вы беззваротна забрудзілі гэты пул прыладай з нізкай прадукцыйнасцю і, як правіла, няма іншага выйсця, акрамя як знішчыць пул і пачаць усё спачатку. Нават выдаленне vdev не выратуе ад збітай наладкі ashift!
Механізм капіявання пры запісе
Калі звычайнай файлавай сістэме трэба перазапісаць дадзеныя - яна змяняе кожны блок там, дзе ён знаходзіцца
Файлавая сістэма з капіраваннем пры запісе запісвае новую версію блока, а затым разблакуе старую версію
У абстрактным выглядзе, калі ігнараваць рэальнае фізічнае размяшчэнне блокаў, то наша "камета дадзеных" спрашчаецца да "чарвяка дадзеных", які перамяшчаецца злева направа па карце даступнай прасторы
Цяпер мы можам атрымаць добрае ўяўленне, як працуюць снапшоты капіявання пры запісе – кожны блок можа належаць некалькім снапшотам, і захаваецца да таго часу, пакуль не будуць знішчаны ўсе звязаныя снапшоты.
Механізм капіявання пры запісе (Copy on Write, CoW) – фундаментальная аснова таго, што робіць ZFS настолькі ўзрушаючай сістэмай. Асноўная канцэпцыя простая - калі вы папытаеце традыцыйную файлавую сістэму змяніць файл, яна зробіць менавіта тое, што вы прасілі. Калі вы папытаеце файлавую сістэму з капіяваннем пры запісе зрабіць тое ж самае, яна скажа "добра" - але схлусіць вам.
Замест гэтага файлавая сістэма з капіраваннем пры запісе запісвае новую версію змененага блока, а затым абнаўляе метададзеныя файла, каб разарваць сувязь са старым блокам і звязаць з ім новы блок, які вы толькі што запісалі.
Адлучэнне старога блока і звязванне новага ажыццяўляецца за адну аперацыю, таму яе нельга перапыніць - калі вы скідаеце харчаванне пасля таго, як гэта адбудзецца, у вас ёсць новая версія файла, а калі вы скідаеце харчаванне раней, то ў вас ёсць старая версія. У любым выпадку, у файлавай сістэме не ўзнікне канфліктаў.
Капіраванне пры запісе ў ZFS адбываецца не толькі на ўзроўні файлавай сістэмы, але і на ўзроўні кіравання дыскамі. Гэта азначае, што ZFS не схільная прабелу ў запісе () - феномену, калі паласа паспела толькі часткова запісацца да збою сістэмы, з пашкоджаннем масіва пасля перазагрузкі. Тут паласа пішацца атамарна, vdev заўсёды паслядоўны, і .
ZIL: часопіс намераў ZFS
Сістэма ZFS апрацоўвае сінхронныя запісы адмысловай выявай — яна часова, але неадкладна захоўвае іх у ZIL, перш чым пазней запісаць іх на сталай аснове разам з асінхроннымі запісамі
Звычайна дадзеныя, запісаныя на ZIL, больш ніколі не счытваюцца. Але гэта магчыма пасля збою сістэмы
SLOG, або другаснае LOG-прылада, - гэта проста спецыяльны - і, пажадана, вельмі хуткі - vdev, дзе ZIL можа захоўвацца асобна ад асноўнага сховішча
Пасля збою ўсе брудныя дадзеныя ў ZIL прайграваюцца - у дадзеным выпадку ZIL знаходзіцца на SLOG, так што яны прайграваюцца менавіта адтуль.
Існуе дзве асноўныя катэгорыі аперацый запісу - сінхронныя (sync) і асінхронныя (async). Для большасці працоўных нагрузак пераважная большасць аперацый запісу з'яўляюцца асінхроннымі - файлавая сістэма дазваляе агрэгаваць іх і выдаваць пакетамі, памяншаючы фрагментацыю і значна павялічваючы прапускную здольнасць.
Сінхронныя запісы - зусім іншая справа. Калі прыкладанне запытвае сінхронны запіс, яно кажа файлавай сістэме: «Табе трэба зафіксаваць гэта ў энерганезалежнай памяці прама зараз, а датуль я больш нічога не магу зрабіць». Таму сінхронныя запісы павінны быць неадкладна зафіксаваны на дыску - і калі гэта павялічвае фрагментацыю або памяншае прапускную здольнасць, так таму і быць.
ZFS апрацоўвае сінхронныя запісы інакш, чым звычайныя файлавыя сістэмы – замест таго, каб неадкладна заліваць іх у звычайнае сховішча, ZFS фіксуе іх у адмысловай вобласці захоўвання, якая завецца часопіс намераў ZFS – ZFS Intent Log, або ZIL. Хітрасць у тым, што гэтыя запісы таксама застаюцца ў памяці, быўшы агрэгаваны разам з звычайнымі асінхроннымі запытамі на запіс, каб пазней быць скінутымі ў сховішча як зусім нармальныя TXG (групы транзакцый, Transaction Groups).
У нармальным рэжыме працы ZIL запісваецца і ніколі больш не чытаецца. Калі праз некалькі імгненняў запісы з ZIL фіксуюцца ў асноўным сховішча ў звычайных TXG з аператыўнай памяці, яны адлучаюцца ад ZIL. Адзінае, калі нешта счытваецца з ZIL - гэта пры імпарце пула.
Калі адбываецца збой ZFS - збой аперацыйнай сістэмы або адключэнне харчавання - калі ў ZIL ёсць дадзеныя, гэтыя дадзеныя будуць прачытаныя падчас наступнага імпарту пула (напрыклад, пры перазапуску аварыйнай сістэмы). Усё, што знаходзіцца ў ZIL, будзе лічана, аб'яднана ў групы TXG, зафіксавана ў асноўным сховішча, а затым адлучана ад ZIL у працэсе імпарту.
Адзін з дапаможных класаў vdev завецца LOG ці SLOG, другасная прылада LOG. У яго адна задача - забяспечыць пул асобным і, пажадана, значна хутчэйшым, з вельмі высокай устойлівасцю да запісу, прыладай vdev для захоўвання ZIL, замест захоўвання ZIL на галоўным сховішчы vdev. Сам ZIL паводзіць сябе аднолькава незалежна ад месца захоўвання, але калі ў vdev з LOG вельмі высокая прадукцыйнасць запісу, то сінхронныя запісы будуць адбывацца хутчэй.
Даданне vdev з LOG у пул ніяк не можа палепшыць прадукцыйнасць асінхроннага запісу - нават калі вы прымусова выконваеце ўсе запісы ў ZIL з дапамогай zfs set sync=always, яны ўсё роўна будуць прывязаныя да асноўнага сховішча ў TXG такім жа чынам і ў тым жа тэмпе, што і без часопіса. Адзіным прамым паляпшэннем прадукцыйнасці з'яўляецца затрымка сінхроннага запісу (паколькі большая хуткасць часопіса паскарае выкананне аперацый sync).
Аднак у асяроддзі, якое ўжо патрабуе вялікай колькасці сінхронных запісаў, vdev LOG можа ўскосна паскорыць асінхронны запіс і некэшаванае чытанне. Выгрузка запісаў ZIL у асобны vdev LOG азначае малодшую канкурэнцыю за IOPS у першасным сховішчы, што ў некаторай ступені павялічвае прадукцыйнасць усіх аперацый чытання і запісы.
Снапшоты
Механізм капіявання пры запісе таксама з'яўляецца неабходнай асновай для атамарных маментальных здымкаў ZFS і інкрыментальнай асінхроннай рэплікацыі. У актыўнай файлавай сістэме ёсць дрэва паказальнікаў, якое адзначае ўсе запісы з бягучымі дадзенымі - калі вы робіце снапшот, вы проста робіце копію гэтага дрэва паказальнікаў.
Калі ў актыўнай файлавай сістэме перазапісваецца запіс, ZFS спачатку запісвае новую версію блока ў невыкарыстоўваную прастору. Затым адлучае старую версію блока ад бягучай файлавай сістэмы. Але калі нейкі снапшот спасылаецца на стары блок, ён усё роўна застаецца нязменным. Стары блок фактычна не будзе адноўлены як вольная прастора, пакуль усе снапшоты, якія спасылаюцца на гэты блок, не будуць знішчаны!
рэплікацыя
Мая бібліятэка Steam у 2015 годзе займала 158 ГіБ і ўключала 126 927 файлаў. Гэта даволі блізка да аптымальнай сітуацыі для rsync – рэплікацыя ZFS па сетцы была «ўсяго толькі» на 750% хутчэй.
У той жа сеткі рэплікацыя аднаго 40-гібібайтнага файла выявы віртуальнай машыны Windows 7 – зусім іншая гісторыя. Рэплікацыя ZFS адбываецца ў 289 разоў хутчэй, чым rsync - ці «ўсяго» у 161 разоў хутчэй, калі вы дастаткова падкаваныя, каб выклікаць rsync з ключом -inplace.
Калі выява віртуальнай машыны маштабуецца, праблемы rsync маштабуюцца разам з ім. Памер 1,9 ТиБ не такі вялікі для сучаснай выявы віртуальнай машыны але ён досыць вялікі, каб рэплікацыя ZFS апынулася ў 1148 раз хутчэй, чым rsync, нават з аргументам rsync inplace
Як толькі вы зразумееце, як працуюць снапшоты, будзе нескладана ўлавіць сутнасць рэплікацыі. Паколькі снапшот - гэта проста дрэва паказальнікаў на запісы, з гэтага вынікае, што калі мы робім zfs send снапшота, то мы адпраўляем і гэта дрэва, і ўсе звязаныя з ім запісы. Калі мы перадаем гэты zfs send в zfs receive на мэтавы аб'ект, ён запісвае як фактычнае змесціва блока, так і дрэва паказальнікаў, якія спасылаюцца на блокі, у мэтавы набор дадзеных.
Усё становіцца яшчэ цікавей на другім zfs send. Цяпер у нас дзве сістэмы, кожная з якіх змяшчае poolname/datasetname@1, а вы здымаеце новы снапшот poolname/datasetname@2. Таму ў зыходным кулі ў вас datasetname@1 и datasetname@2, а ў мэтавым кулі пакуль толькі першы снапшот datasetname@1.
Паколькі паміж крыніцай і мэтай у нас ёсць агульны снапшот datasetname@1, мы можам зрабіць інкрыментальны zfs send па-над ім. Калі мы гаворым сістэме zfs send -i poolname/datasetname@1 poolname/datasetname@2, яна параўноўвае два дрэвы паказальнікаў. Любыя паказальнікі, якія існуюць толькі ў @2, відавочна, спасылаюцца на новыя блокі - таму нам спатрэбіцца змесціва гэтых блокаў.
У выдаленай сістэме апрацоўка інкрыментальнага send такая ж простая. Спачатку мы запісваем усе новыя запісы, уключаныя ў паток send, а затым дадаем паказальнікі на гэтыя блокі. Вуаля, у нас @2 у новай сістэме!
Асінхронная інкрыментальная рэплікацыя ZFS - гэта велізарнае паляпшэнне ў параўнанні з больш раннімі метадамі, не заснаванымі на снапшотах, такімі як rsync. У абодвух выпадках перадаюцца толькі змененыя дадзеныя - але rsync павінен спачатку прачытаць з дыска ўсе дадзеныя абапал, каб праверыць суму і параўнаць яе. У адрозненне ад гэтага, рэплікацыя ZFS не счытвае нічога, акрамя дрэў паказальнікаў - і любых блокаў, якія не прадстаўлены ў агульным снапшоце.
Убудаваны сціск
Механізм капіявання пры запісе таксама спрашчае сістэму ўбудаванага сціску. У традыцыйнай файлавай сістэмы сціск праблематычна – як старая версія, так і новая версія змененых дадзеных знаходзяцца ў адной і той жа прасторы.
Калі разгледзець фрагмент дадзеных у сярэдзіне файла, які пачынае сваё жыццё як мегабайт нулёў ад 0x00000000 і гэтак далей - яго вельмі лёгка сціснуць да аднаго сектара на дыску. Але што адбудзецца, калі мы заменім гэты мегабайт нулёў на мегабайт несжимаемых дадзеных, такіх як JPEG ці псеўдавыпадковы шум? Нечакана гэтаму мегабайту дадзеных запатрабуецца не адзін, а 256 сектараў па 4 КіБ, а тут на дыску зарэзерваваны толькі адзін сектар.
У ZFS няма такой праблемы, бо змененыя запісы заўсёды запісваюцца ў невыкарыстоўваемую прастору – зыходны блок займае толькі адзін сектар 4 КіБ, а новы запіс зойме 256, але гэта не праблема – нядаўна зменены фрагмент з «сярэдзіны» файла быў бы запісаны ў невыкарыстоўваемую прастору. незалежна ад таго, змяніўся яго памер ці не, таму для ZFS гэта суцэль штатная сітуацыя.
Убудаваны сціск ZFS адключана па змаўчанні, і сістэма прапануе якія падключаюцца алгарытмы – цяпер сярод іх LZ4, gzip (1-9), LZJB і ZLE.
- LZ4 - Гэта струменевы алгарытм, які прапануе надзвычай хуткае сціск і дэкампрэсію і выйгрыш у прадукцыйнасці для большасці выпадкаў выкарыстання - нават на даволі павольных CPU.
- GZIP - Шаноўны алгарытм, які ведаюць і кахаюць усе карыстачы Unix-сістэм. Ён можа быць рэалізаваны з узроўнямі сціску 1-9, з павелічэннем ступені сціску і выкарыстанні CPU па меры набліжэння да ўзроўня 9. Алгарытм добра падыходзіць для ўсіх тэкставых (ці іншых надзвычай сціскаемых) варыянтаў выкарыстання, але ў адваротным выпадку часта выклікае праблемы c CPU — выкарыстоўвайце яго з асцярожнасцю, асабліва на больш высокіх узроўнях.
- LZJB - арыгінальны алгарытм у ZFS. Ён састарэлы і больш не павінен выкарыстоўвацца, LZ4 пераўзыходзіць яго па ўсіх паказчыках.
- ЗЛЭ - Кадзіроўка нулявога ўзроўню, Zero Level Encoding. Яна наогул не чапае нармальныя дадзеныя, але сціскае вялікія паслядоўнасці нулёў. Карысна для цалкам несжимаемых набораў дадзеных (напрыклад, JPEG, MP4 ці іншых ужо сціснутых фарматаў), бо ён ігнаруе несжимаемые дадзеныя, але сціскае невыкарыстоўваную прастору ў выніковых запісах.
Мы рэкамендуем сціск LZ4 практычна для ўсіх варыянтаў выкарыстання; штраф за прадукцыйнасць пры сустрэчы з несжимаемыми дадзенымі вельмі малы, а прырост прадукцыйнасці для тыповых дадзеных значны. Капіраванне выявы віртуальнай машыны для новай усталёўкі аперацыйнай сістэмы Windows (свежаўсталяваная АС, ніякіх дадзеных усярэдзіне яшчэ няма) з compression=lz4 прайшло на 27% хутчэй, чым з compression=none, У .
ARC - кэш адаптыўнай замены
ZFS - гэта адзіная вядомая нам сучасная файлавая сістэма, якая выкарыстоўвае ўласны механізм кэшавання чытання, а не належыць на кэш старонак аперацыйнай сістэмы для захоўвання копій нядаўна прачытаных блокаў у аператыўнай памяці.
Хоць уласны кэш не пазбаўлены сваіх праблем - ZFS не можа рэагаваць на новыя запыты аб выдзяленні памяці гэтак жа хутка, як ядро, таму новы выклік malloc() на размеркаванне памяці можа пацярпець няўдачу, калі яму запатрабуецца аператыўная памяць, занятая ў наш час ARC. Але ёсць важкія прычыны выкарыстоўваць уласны кэш, па меншай меры цяпер.
Усе вядомыя сучасныя АС, уключаючы MacOS, Windows, Linux і BSD, для рэалізацыі кэша старонак выкарыстоўваюць алгарытм LRU (Least Recently Used). Гэта прымітыўны алгарытм, які паднімае кэшаваны блок "уверх чаргі" пасля кожнага чытання і выцясняе блокі "ўніз чаргі" па меры неабходнасці, каб дадаць новыя промахі кэша (блокі, якія павінны былі быць прачытаныя з дыска, а не з кэша) уверх.
Звычайна алгарытм працуе нармальна, але ў сістэмах з вялікімі працоўнымі наборамі дадзеных LRU лёгка прыводзіць да трэшынгу - выцясненню часта неабходных блокаў, каб вызваліць месца для блокаў, якія ніколі больш прачытаюцца з кэша.
- значна менш наіўны алгарытм, які можна разглядаць як «узважаны» кэш. Пасля кожнага счытвання кэшаванага блока ён становіцца трохі «цяжэй» і яго становіцца цяжэй выцесніць - і нават пасля выцяснення блок адсочваецца на працягу вызначанага перыяду часу. Блок, які быў выцеснены, але затым павінен быць лічаны зваротна ў кэш, таксама стане "цяжэй".
Канчатковым вынікам усяго гэтага з'яўляецца кэш са значна вялікім каэфіцыентам траплення (hit ratio) - суадносінамі паміж трапленнямі ў кэш (чытанне, выкананае з кэша) і промахамі (чытанне з дыска). Гэта надзвычай важная статыстыка - мала таго, што самі хіты кэша абслугоўваюцца на парадкі хутчэй, промахі кэша таксама могуць абслугоўвацца хутчэй, бо чым больш хітоў кэша - тым менш паралельных запытаў да дыска і тым менш затрымка для тых астатніх промахаў, якія павінны абслугоўвацца з дыска.
Заключэнне
Пасля вывучэння асноўнай семантыкі ZFS – як працуе капіраванне пры запісе, а таксама адносін паміж пуламі захоўвання, віртуальнымі прыладамі, блокамі, сектарамі і файламі, – мы гатовыя абмеркаваць рэальную прадукцыйнасць з рэальнымі лікамі.
У наступнай частцы мы разгледзім фактычную прадукцыйнасць пулаў з люстранымі vdev і RAIDz, сябар у параўнанні з адным, а таксама ў параўнанні з традыцыйнымі RAID-тапалогіямі ядра Linux, якія мы даследавалі .
Спачатку мы хацелі разгледзець толькі асновы – самі тапалогіі ZFS – але пасля такога будзем гатовыя казаць аб больш прасунутай наладзе і цюнінгу ZFS, уключаючы выкарыстанне дапаможных тыпаў vdev, такіх як L2ARC, SLOG і Special Allocation.
Крыніца: habr.com