Бул жазда биз кээ бир киришүү темаларын талкууладык, мис. и . Алардын экинчисинде биз ZFSдеги ар кандай көп дисктүү топологиялардын иштешин изилдөөнү улантууну убада кылдык. Бул азыр бардык жерде жайылтылган кийинки муун файл системасы үчүн .
Бүгүн ZFS менен таанышуу үчүн эң сонун күн, кызыккан окурмандар. OpenZFS иштеп чыгуучусу Мэтт Аренстин жупуну баалоосунда "бул чындап эле кыйын" экенин билиңиз.
Бирок биз сандарга келээрден мурун - жана болот, мен убада берем - сегиз дисктүү ZFS конфигурациясынын бардык варианттары үчүн, биз сүйлөшүшүбүз керек. кантип Жалпысынан, ZFS дискте маалыматтарды сактайт.
Zpool, vdev жана түзмөк
Бул толук пулдун диаграммасы үч жардамчы vdevди камтыйт, ар бир класстын бири жана RAIDz2 үчүн төрт
Адатта дал келбеген vdev түрлөрүнүн жана өлчөмдөрүнүн бассейнин түзүүгө эч кандай себеп жок - бирок кааласаңыз, буга эч нерсе тоскоол болбойт.
ZFS файл тутумун чындап түшүнүү үчүн, анын иш жүзүндөгү түзүмүн жакшылап карап чыгышыңыз керек. Биринчиден, ZFS салттуу көлөмдү жана файл тутумун башкаруу катмарларын бириктирет. Экинчиден, ал транзакциялык көчүрмөнү жазуу механизмин колдонот. Бул өзгөчөлүктөр системанын кадимки файл тутумдарынан жана RAID массивдеринен структуралык жактан абдан айырмаланарын билдирет. Түшүнүү үчүн негизги курулуш блоктору биринчи топтому сактоо бассейни (zpool), виртуалдык аппарат (vdev) жана реалдуу түзмөк (түзмөк).
zpool
Zpool сактагыч бассейни ZFSдин эң жогорку түзүмү болуп саналат. Ар бир бассейн бир же бир нече виртуалдык түзмөктөрдү камтыйт. Өз кезегинде, алардын ар бири бир же бир нече реалдуу түзүлүштөрдү (аппараттарды) камтыйт. Виртуалдык бассейндер өзүн-өзү камтыган бирдиктер. Бир физикалык компьютер эки же андан көп өзүнчө бассейнди камтышы мүмкүн, бирок ар бири башкалардан толугу менен көз карандысыз. Бассейндер виртуалдык түзмөктөрдү бөлүшө албайт.
ZFS ашыкчасы бассейн деңгээлинде эмес, виртуалдык түзмөк деңгээлинде. Бассейн деңгээлинде эч кандай ашыкча болбойт — эгерде vdev же арналган vdev жоголсо, аны менен бирге бүт бассейн жоголот.
Заманбап сактагыч бассейндер виртуалдык түзүлүштүн кэшин же логун жоготкондо аман кала алышат - бирок алар электр энергиясы үзгүлтүккө учураганда же тутум бузулганда vdev журналын жоготуп алышса, аз өлчөмдө кир маалыматтарды жоготуп коюшу мүмкүн.
ZFS "маалымат тилкелери" бүт бассейнде жазылган деген жалпы туура эмес түшүнүк бар. Бул туура эмес. Zpool күлкүлүү RAID0 эмес, бул күлкүлүү татаал өзгөрмө бөлүштүрүү механизми менен.
Көпчүлүк учурда, жазуулар жеткиликтүү бош мейкиндикке ылайык жеткиликтүү виртуалдык түзүлүштөр арасында бөлүштүрүлөт, ошондуктан теориялык жактан алардын баары бир убакта толтурулат. ZFSдин акыркы версиялары учурдагы vdev колдонууну (таштандыруу) эске алат - эгерде бир виртуалдык түзүлүш экинчисине караганда кыйла бош болсо (мисалы, окуу жүктөмүнөн улам), бош орундун эң жогорку катышына карабастан, ал жазуу үчүн убактылуу өткөрүп жиберилет. .
Заманбап ZFS жазуу бөлүштүрүү ыкмаларына орнотулган кайра иштетүүнү аныктоо механизми күтүү убактысын азайтып, адаттан тыш жогорку жүктөө мезгилинде өткөрүү жөндөмдүүлүгүн жогорулата алат - бирок андай эмес карт бланш жай HDD жана тез SSD дисктерин бир бассейнде эрксиз аралаштыруу. Мындай бирдей эмес бассейн дагы эле эң жай аппараттын ылдамдыгы менен иштейт, б.а. толугу менен ушундай түзүлүштөрдөн тургандай.
vdev
Ар бир сактагыч бассейн бир же бир нече виртуалдык түзмөктөн (vdev) турат. Өз кезегинде, ар бир vdev бир же бир нече реалдуу түзмөктөрдү камтыйт. Көпчүлүк виртуалдык түзүлүштөр жөнөкөй маалыматтарды сактоо үчүн колдонулат, бирок CACHE, LOG жана SPECIAL сыяктуу бир нече vdev жардамчы класстары бар. Бул vdev түрлөрүнүн ар бири беш топологиянын бирине ээ болушу мүмкүн: бир түзмөк, RAIDz1, RAIDz2, RAIDz3 же күзгү.
RAIDz1, RAIDz2 жана RAIDz3 - бул эски адамдар кош (диагоналдык) паритет RAID деп атаган өзгөчө сорттор. 1, 2 жана 3 ар бир маалымат тилкесинде канча паритеттик блок бөлүнгөнүн билдирет. Паритетти камсыз кылуу үчүн өзүнчө дисктерге ээ болуунун ордуна, виртуалдык RAIDz түзмөктөрү паритетти дисктер боюнча жарым-жартылай тең бөлүштүрүшөт. RAIDz массиви паритеттик блокторго ээ болсо, ошончо дискти жогото алат; башкасын жоготсо, ал иштебей калат жана сактоо бассейнин өзү менен кошо алат.
Күзгү виртуалдык түзүлүштөрүндө ( Mirror vdev ), ар бир блок vdev ичиндеги ар бир түзмөктө сакталат. Эки кенен күзгүлөр эң кеңири таралганы менен, күзгү кандайдыр бир ыктыярдуу сандагы түзмөктөрдү камтышы мүмкүн — чоң орнотууларда үч эсе көп учурда окуунун натыйжалуулугун жана катага чыдамдуулукту жакшыртуу үчүн колдонулат. vdev күзгүсү, жок эле дегенде, vdev ичиндеги бир түзмөк иштеп турса, ар кандай катачылыктарга туруштук бере алат.
Жалгыз вдевдер табиятынан коркунучтуу. Мындай виртуалдык түзүлүш бир эле иштен чыга албайт - жана эгерде сактагыч же атайын vdev катары колдонулса, анда анын бузулушу бүт бассейндин бузулушуна алып келет. Бул жерде өтө этият болуңуз.
КЕШ, LOG жана АТАЙЫН виртуалдык түзүлүштөрдү жогоруда аталган топологиялардын каалаганында түзсө болот - бирок АТАЙЫН виртуалдык түзүлүштү жоготуу бассейнди жоготуу дегенди билдирерин унутпаңыз, андыктан ашыкча топология сунушталат.
түзмөк
Бул, балким, ZFSде түшүнүү үчүн эң оңой термин - бул түзмө-түз блоктук кокустук кирүүчү түзүлүш. Эсиңизде болсун, виртуалдык түзмөктөр жеке түзмөктөрдөн, ал эми бассейн виртуалдык түзүлүштөрдөн турат.
Магниттик же катуу абалдагы дисктер vdevдин курулуш материалы катары колдонулган эң кеңири таралган блоктук түзүлүштөр болуп саналат. Бирок, /dev ичинде дескриптору бар каалаган түзмөк жасайт - ошондуктан бүт аппараттык RAID массивдери өзүнчө түзүлүш катары колдонулушу мүмкүн.
Жөнөкөй чийки файл - бул vdev түзө турган эң маанилүү альтернативалуу блоктук түзүлүштөрдүн бири. Сыноо бассейндери бул пулдун буйруктарын текшерүүнүн жана берилген топологиянын бассейнинде же виртуалдык түзүлүшүндө канча орун бар экенин көрүүнүн абдан ыңгайлуу жолу.
Сиз бир нече секунданын ичинде сейрек файлдардан сыноо бассейнин түзө аласыз, бирок андан кийин бүт бассейнди жана анын компоненттерин жок кылууну унутпаңыз.
Айталы, сиз сегиз дисктүү серверди каалап жатасыз жана 10 ТБ (~9300 ГБ) дисктерди колдонууну пландап жатасыз - бирок кайсы топология сиздин муктаждыктарыңызга ылайыктуу экенин билбейсиз. Жогорудагы мисалда биз бир нече секунданын ичинде сейрек файлдардан сыноо бассейнин курабыз - эми 2 ТБ сегиз дисктен турган RAIDz10 vdev 50 TiB колдонууга жарамдуу кубаттуулукту камсыздай турганын билебиз.
Приборлордун дагы бир өзгөчө классы - SPARE. Кадимки түзмөктөрдөн айырмаланып, ысык алмаштыруучу түзмөктөр бир виртуалдык түзүлүшкө эмес, бүт бассейнге таандык. Эгер бассейндеги кандайдыр бир vdev иштебей калса жана запастык түзмөк бассейнге туташып, жеткиликтүү болсо, анда ал автоматтык түрдө жабыр тарткан vdevге кошулат.
Жабыркаган vdevге туташкандан кийин, алмаштыруучу аппарат жок түзмөктө болушу керек болгон маалыматтардын көчүрмөлөрүн же реконструкцияларын ала баштайт. Салттуу RAIDде бул "кайра куруу" деп аталат, ал эми ZFSде "кайрадан кайра куруу".
Бул алмаштыруучу аппараттар биротоло иштебей калган түзмөктөрдү алмаштыра албасын белгилей кетүү маанилүү. Бул vdev деградацияга кеткен убакытты кыскартуу үчүн убактылуу гана алмаштыруу. Администратор иштебей калган vdev түзмөгүн алмаштыргандан кийин, ал туруктуу түзмөккө ашыкчалык калыбына келтирилет жана SPARE vdevден ажыратылып, бүт бассейн үчүн запас болуп кайтып келет.
Маалымат топтому, блоктор жана секторлор
ZFS саякатыбызда түшүнө турган курулуш блокторунун кийинки топтому аппараттык камсыздоого азыраак жана маалыматтардын өзү кантип уюштурулганына жана сакталганына байланыштуу. Биз бул жерде бир нече катмарды өткөрүп жиберип жатабыз - мисалы, метаслаб - жалпы структураны түшүнүү менен бирге деталдарды чаташтырбоо үчүн.
Dataset
Биз биринчи жолу дайындар топтомун түзгөндө, ал бардык жеткиликтүү бассейн мейкиндигин көрсөтөт. Андан кийин биз квотаны койдук - жана монтаждык чекитти өзгөртөбүз. Magic!
Zvol негизинен файл тутумунун катмарынан ажыратылган маалымат топтому, аны биз бул жерде кадимки ext4 файл системасы менен алмаштырабыз.
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 түзмөгүн экспорттоодо арткы программа катары мааниси көбүрөөк.
блоктор
Файл бир же бир нече блок менен көрсөтүлөт. Ар бир блок бир виртуалдык түзмөктө сакталат. Блоктун өлчөмү, адатта, параметрге барабар рекорддук өлчөмү, бирок азайтууга болот 2^ашифт, ал метаберилиштерди же кичинекей файлды камтыса.
Биз чынында эле чындыгында Эгер сиз өткөөл көрсөткүчтү өтө эле төмөн коюп койсоңуз, биз чоң айып пул жөнүндө тамашалаган жокпуз
ZFS бассейнинде бардык маалыматтар, анын ичинде метаберилиштер блоктордо сакталат. Ар бир маалымат топтому үчүн максималдуу блок өлчөмү касиетте аныкталган recordsize (рекорддук өлчөмдө). Жазуунун өлчөмү өзгөрүшү мүмкүн, бирок бул маалымат топтомуна мурунтан эле жазылган блоктордун өлчөмүн же жайгашкан жерин өзгөртпөйт - бул жаңы блокторго жазылгандай гана таасир этет.
Башкасы белгиленбесе, учурдагы демейки киргизүү өлчөмү 128 КБ. Бул аткаруу кемчиликсиз болбойт, бирок көпчүлүк учурларда коркунучтуу болбойт. Recordsize 4Kдан 1Mге чейинки каалаган мааниге коюуга болот (кошумча орнотуулар менен recordsize андан да көп орното аласыз, бирок бул сейрек жакшы идея).
Ар кандай блок бир гана файлдын маалыматтарын билдирет — эки башка файлды бир блокко кысып албайсыз. Ар бир файл өлчөмүнө жараша бир же бир нече блоктон турат. Эгерде файлдын өлчөмү рекорддук өлчөмдөн кичине болсо, анда ал кичине блокто сакталат - мисалы, 2 КБ файлы бар блок дискте бир гана 4 КБ секторду ээлейт.
Эгер файл бир нече блокторду талап кыла тургандай чоң болсо, анда ал файлдын бардык жазуулары өлчөмү болот recordsize - анын ичинде акыркы жазуу, анын негизги бөлүгү болушу мүмкүн .
зволдук томдордун мулку жок 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 KiB сектору жана ар бир кириш үчүн.
Чыныгы дүйнөдө мындай жаза Samsung EVO SSD дисктерине таасир этет, алар үчүн ал колдонулушу керек 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 жазуудагы бош боштукка кабылбайт дегенди билдирет () - кайра жүктөөдөн кийин массивдин бузулушу менен система кыйраганга чейин тилке жарым-жартылай гана катталган көрүнүш. Бул жерде сызык атомдук түрдө жазылат, вдев дайыма ырааттуу жана .
ZIL: ZFS ниет журналы
ZFS синхрондук жазууларды өзгөчө жол менен иштетет - ал аларды убактылуу, бирок дароо ZILде сактайт, андан кийин аларды асинхрондук жазуулар менен бирге биротоло жазат.
Адатта, ЗИЛге жазылган маалыматтар кайра эч качан окулбайт. Бирок бул система бузулгандан кийин мүмкүн
SLOG же кошумча LOG түзмөгү бул жөн гана өзгөчө жана эң жакшысы абдан тез vdev, анда ZIL негизги сактагычтан өзүнчө сакталат.
Кырсыктан кийин, ЗИЛдеги бардык кир маалыматтар кайра ойнотулат - бул учурда, ZIL SLOGде, ошондуктан ал ошол жерде кайра ойнотулат.
Жазуунун эки негизги категориясы бар: синхрондуу (синхрондуу) жана асинхрондуу (асинхрондуу). Көпчүлүк жүктөмдөр үчүн жазуулардын басымдуу көпчүлүгү асинхрондуу болуп саналат - файл системасы аларды топтоп, партиялар менен чыгарууга мүмкүндүк берет, фрагментацияны азайтат жана өткөрүү жөндөмдүүлүгүн кыйла жогорулатат.
Синхрондук жазуулар такыр башка маселе. Тиркеме синхрондуу жазууну суранганда, ал файл тутумуна мындай дейт: "Сиз муну туруксуз эс тутумга тапшырышыңыз керек. так азыр, жана ага чейин мен кыла турган эч нерсе жок». Ошондуктан, синхрондуу жазуулар дароо дискке жүктөлүшү керек - жана бул фрагментацияны көбөйтсө же өткөрүү жөндөмдүүлүгүн азайтса, ошондой болсун.
ZFS синхрондуу жазууларды кадимки файл тутумдарына караганда башкача иштетет — аларды кадимки сактагычка дароо тазалоонун ордуна, ZFS аларды ZFS Intent Log же ZIL деп аталган атайын сактоо аймагына тапшырат. Айла бул рекорддор дагы эстутумда калып, кадимки асинхрондук жазуу суроо-талаптары менен бирге топтолуп, кийинчерээк толугу менен кадимки TXG (Транзакция топтору) катары сактагычка куюлат.
Кадимки иштөө учурунда ЗИЛ жазылат жана эч качан окулбайт. Бир нече мүнөттөн кийин, ЗИЛден алынган жазуулар оперативдүү эс тутумдан кадимки TXGлерде негизги сактоого берилгенде, алар ЗИЛден ажыратылат. ЗИЛден бир нерсе окулат, бул бассейнди импорттоодо.
Эгерде ZFS иштебей калса — операциялык системанын бузулушу же электр энергиясы өчүрүлүшү — ZILде маалымат бар болсо, ал маалымат кийинки пул импорттоо учурунда окулат (мисалы, иштен чыгуу системасы кайра иштетилгенде). ЗИЛде эмне болсо, ошонун баары окулат, TXGлерге топтолуп, негизги дүкөнгө тапшырылат, андан кийин импорттоо процессинде ЗИЛден ажыратылат.
vdev жардамчы класстарынын бири LOG же SLOG деп аталат, экинчилик LOG аппараты. Анын бир милдети бар - ЗИЛди негизги vdev сактагычында сактоонун ордуна, өзүнчө жана эң жакшыраак, бир топ тезирээк, өтө жогорку жазуу каршылыгы бар, ЗИЛди сактоо үчүн vdev түзүлүш менен камсыз кылуу. ZIL өзү сакталган жерге карабастан, өзүн бирдей алып барат, бирок LOG менен vdev өтө жогорку жазуу көрсөткүчүнө ээ болсо, анда синхрондуу жазуу тезирээк болот.
LOG менен vdevди бассейнге кошуу иштебейт мүмкүн эмес, асинхрондук жазуу натыйжалуулугун жогорулатуу - бардык ZIL менен жазууну мажбурласаңыз да zfs set sync=always, алар дагы эле TXGдеги негизги сактагычка журналсыз эле окшош жана бирдей темпте туташат. Түздөн-түз аткарууну жакшыртуунун жалгыз жолу - синхрондук жазуу кечигүү (себеби, журналдын жогорку ылдамдыгы операцияларды тездетет sync).
Бирок, синхрондук жазууларды көп талап кылган чөйрөдө vdev LOG кыйыр түрдө асинхрондук жазууларды жана кэштелбеген окууларды тездетет. ZIL жазууларын өзүнчө vdev LOGге түшүрүү негизги сактагычтагы IOPS үчүн азыраак талашты билдирет, бул бардык окуулардын жана жазуулардын иштешин кандайдыр бир деңгээлде жакшыртат.
Сүрөттөр
Жазуу боюнча көчүрүү механизми ZFS атомдук снапшоттору жана кошумча асинхрондук репликация үчүн зарыл негиз болуп саналат. Активдүү файл тутумунда бардык жазууларды учурдагы маалыматтар менен белгилеген көрсөткүч дарагы бар - сиз сүрөттү тартканда, сиз жөн гана бул көрсөткүч дарактын көчүрмөсүн жасайсыз.
Активдүү файл тутумунда жазуу кайра жазылганда, ZFS адегенде блоктун жаңы версиясын пайдаланылбаган мейкиндикке жазат. Андан кийин блоктун эски версиясын учурдагы файл тутумунан ажыратат. Бирок кээ бир сүрөт эски блокко шилтеме кылса, ал дагы эле өзгөрүүсүз калат. Эски блок чындыгында ал блокко шилтеме берген бардык сүрөттөр жок кылынмайынча бош орун катары калыбына келтирилбейт!
репликация
2015-жылы менин Steam китепканам 158 ГБ болгон жана 126 927 файлды камтыган. Бул rsync үчүн оптималдуу кырдаалга абдан жакын - тармак аркылуу ZFS репликациясы "болгону" 750% тезирээк болгон.
Ошол эле тармакта, бир 40 ГБ Windows 7 виртуалдык машина сүрөт файлын репликациялоо - бул таптакыр башка окуя. ZFS репликациясы rsyncке караганда 289 эсе тезирээк же "болгону" 161 эсе тезирээк, эгерде сиз --inplace которгучу менен rsyncти чалуу үчүн жетиштүү билимдүү болсоңуз.
VM сүрөтү масштабдаганда, rsync аны менен масштабдуу маселелерди чыгарат. 1,9 TiB өлчөмү заманбап VM сүрөтү үчүн анчалык чоң эмес — бирок ZFS репликациясы rsync --inplace аргументи менен да rsyncке караганда 1148 эсе тезирээк боло тургандай чоң.
Сүрөттөр кантип иштээрин түшүнгөндөн кийин, репликациянын маңызын түшүнүү оңой болот. Көз ирмемдик сүрөт жөн гана рекорддук көрсөткүчтөрдүн дарагы болгондуктан, анда биз муну жасайбыз 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, анан бул блокторго көрсөткүчтөрдү кошуңуз. Voila, бизде @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-деңгээлге жакындаган сайын кысуу коэффициенти жана CPU колдонулушу көбөйүү менен 9-9 кысуу деңгээли менен ишке ашырылышы мүмкүн. Алгоритм бардык тексттик (же башка өтө кысылган) колдонуу учурларына ылайыктуу, бирок көп учурда CPU көйгөйлөрүн башка учурларда пайда кылат - аны колдонуңуз этияттык менен, өзгөчө жогорку денгээлде.
- LZJB - ZFSдеги оригиналдуу алгоритм. Ал эскирген жана мындан ары колдонулбашы керек, LZ4 бардык жагынан жогору.
- ЖАМАН — нөл деңгээл коддоо, нөл деңгээл коддоо. Ал кадимки маалыматтарга такыр тийбейт, бирок нөлдөрдүн чоң ырааттуулугун кысып коёт. Толугу менен кысылбаган маалымат топтомдору үчүн (мисалы, JPEG, MP4 же башка кысылган форматтар) үчүн пайдалуу, анткени ал кысылбаган маалыматтарды этибарга албайт, бирок алынган жазуулардагы пайдаланылбаган мейкиндикти кысып коёт.
Биз дээрлик бардык колдонуу учурлары үчүн LZ4 кысуу сунуштайбыз; кысылбай турган маалыматтар менен иштөөдө аткаруу жазасы өтө аз жана өсүш типтүү маалыматтар үчүн аткаруу маанилүү болуп саналат. Windows операциялык тутумунун жаңы орнотуусу үчүн виртуалдык машинанын сүрөтүн көчүрүү (жаңы орнотулган OS, ичинде азырынча маалымат жок) compression=lz4 менен караганда 27% тез өттү compression=noneбоюнча .
ARC - адаптивдүү алмаштыруу кэш
ZFS биз билген жападан жалгыз заманбап файл системасы, ал операциондук системанын бет кэшине таянбастан, RAMдагы жакында окулган блоктордун көчүрмөлөрүн сактоо үчүн өзүнүн окуу кэштөө механизмин колдонот.
Түпкү кэш көйгөйлөрсүз болбосо да - ZFS жаңы эстутумду бөлүштүрүү суроо-талаптарына ядро сыяктуу тез жооп бере албайт, ошондуктан жаңы чалуу malloc() учурда ARC ээлеген RAM керек болсо, эстутум бөлүштүрүү иштебей калышы мүмкүн. Бирок, жок дегенде азыр, өз кэш колдонуу үчүн жакшы себептер бар.
Бардык белгилүү заманбап операциялык системалар, анын ичинде MacOS, Windows, Linux жана BSD, барактын кэшин ишке ашыруу үчүн LRU (Эң аз колдонулган) алгоритмин колдонушат. Бул ар бир окуудан кийин кэштелген блокту "кезектин башына" түртүүчү жана жаңы кэш каталарын кошуу үчүн блокторду "кезектин түбүнө" түртүүчү примитивдүү алгоритм. кэштен) жогоруга.
Адатта, алгоритм жакшы иштейт, бирок чоң иштеген маалымат топтомдору бар системаларда LRU оңой эле кыйратууга алып келет — тез-тез керектелүүчү блокторду чыгарып, кэштен эч качан окулбай турган блокторго орун бошотот.
"салмакталган" кэш катары каралышы мүмкүн болгон алда канча азыраак наивдуу алгоритм. Кэштелген блокту окуган сайын, аны чыгаруу бир аз оорлоп, кыйындайт - блокту чыгарып салгандан кийин да байкалган белгилүү бир убакыттын ичинде. Чыгарылган, бирок кайра кэшке окуу керек болгон блок да оорлойт.
Мунун бардыгынын акыркы натыйжасы - бул кэштин бир кыйла жогору коэффициентине ээ болгон кэш - кэш соккулары (кэштен окулат) жана өткөрүп жиберүү (дисктен окуйт) ортосундагы катыш. Бул өтө маанилүү статистика – кэштин хиттеринин өзү эле чоңдуктагы буйруктарды тез тейлебестен, кэш сагынуулары да тезирээк тейлениши мүмкүн, анткени кэш көбүрөөк соккулар болгон сайын, дискке параллелдүү суроо-талаптар ошончолук азыраак болот жана калган сагынуулар үчүн кечигүү азыраак болот. ал диск менен тейлениши керек.
жыйынтыктоо
Эми биз ZFSтин негизги семантикасын — жазууга көчүрүү кантип иштээрин, ошондой эле сактагыч бассейндердин, виртуалдык түзүлүштөрдүн, блоктордун, секторлордун жана файлдардын ортосундагы мамилелерди карап чыккандан кийин, биз чыныгы дүйнөдөгү аткарууну талкуулоого даярбыз. чыныгы сандар.
Кийинки бөлүктө биз чагылдырылган vdev жана RAIDz бассейндеринин иш жүзүндөгү натыйжалуулугун бири-бирине салыштырып, ошондой эле биз карап чыккан салттуу Linux ядросунун RAID топологиялары менен салыштырабыз. .
Башында биз негиздерди гана камтууну кааладык - ZFS топологияларынын өздөрү - бирок кийин бул Биз L2ARC, SLOG жана атайын бөлүштүрүү сыяктуу жардамчы vdev түрлөрүн колдонууну кошкондо, ZFSдин өркүндөтүлгөн конфигурациясы жана тюнинги жөнүндө сүйлөшүүгө даярбыз.
Source: www.habr.com