Дистанционна миграция от UFS към ZFS
И така, реших, че е време да мигрирам към ZFS - те казват много хубави неща, а в пощенския списък хората се активираха - вече с ra > Очаквани проблеми - басейн, капризен към паметта - и има малко от него - само 128Mb. За ZFS се препоръчва минимум 512. Следователно определено ще има проблеми =). До купа искам да правя всичко през ssh - т.е. без режим за един потребител, IP-KVM и др. И така, актуализираме до 8 (имах 7.2 празен там), получаваме следното:
Системата стои на малък skazёm диск, на отделен контролер. Ще прехвърля с помощта на допълнителен диск:
Счупен на едно парче, монтиран асинхронно (да, аз съм перверзник =) Но - тестова машина - правя каквото си искам):
Зареждащият (зареждащ) в 8-ke е изграден по подразбиране без поддръжка за зареждане от ZFS. Или по-скоро дори не е така. За ZFS се използва отделен буутлоудър и първоначално няма такъв. Затова добавяме следния ред към make.conf:
и изградете отново всичко, свързано със зареждането на системата:
Регистрираме зареждането на ZFS модула:
и монтиране на файлови системи при зареждане:
Ние създаваме пул (можете да прочетете какво е пул и с какво се яде в дока с помощта на помощната програма zpool, но накратко - това е набор от устройства, които осигуряват физическо съхранение за ZFS):
Да видим какво се случи:
Експортираме пула - така че ZFS, по време на по-нататъшните ни действия, определено да не докосва диска, на който живее:
Напишете loaders - за първи и втори етап на зареждане:
Оковаване на басейна обратно:
В настройките на басейна задаваме липсата на точка на монтиране (коренът ("/"), не можем да го зададем веднага - защото празният пул веднага ще бъде монтиран като основна система и историята ще се обърне в другата посока -към история на тема "какво да направя, ако всичко се обърка")):
Ние монтираме файловата система, където е удобно за вас - аз - в / mnt :
Оттук започна обирът. Няколко минути по-късно хванах паника - заклех се, че няма достатъчно рамка за ядрото. Добавени рамки до 320Mb. След рестартиране и монтиране на дяла с ZFS направи:
Отново паника със същите симптоми. тъжно Вече нямах обикновен SDRAM. Трябваше да изтегля 2 SDRAM ECC 2Gb стика от най-близкия стар сървър - на тази машина те се виждаха като 2x256. Стартирайте отново dump/restore - пак паника. Намерих още един на гиг в скривалището - видях го и като 256 - общо се получиха 700 и нещо мега - процесът мина добре. Пишем в loader.conf къде да монтираме основния дял:
Премахваме от fstab, че всички записи са в ZFS дяла:
Рестартираме, виждаме следната картина:
И така, какво имаме - ядрото все още беше заредено по стария начин - от първия SCSI диск, с UFS. Но файловата система вече е монтирана от друг - на кой ZFS. Освен това, глупав момент - убиваме цялото съдържание на първия диск - само за това, малко по-рано, регистрирах зареждащи програми на втория диск - ако след убиване, но преди края на прехвърлянето, машината се рестартира - ще бъде възможно да стартирате от втория диск. Ако не регистрирате буутлоудър на него, няма да има от какво да стартирате. И така, убиваме всичко на зареждащото устройство:
Проверка дали всички секции са изчезнали:
И сега, финт с ушите - казваме на zpool, че трябва да сменим един диск с друг:
ДОБРЕ. Тогава нека се опитаме да репликираме - в мана има пример за отдалечен, трябва да работи и локално. Създайте нов пул на SCSI диск:
(VG е виртуална група, такова именуване е прието в AIX. Много по-удобно от резервоарите от ZFS докове) Да видим,расте ли заедно:
Направете моментна снимка на файловата система:
Прехвърляне на моментна снимка от една файлова система в друга:
Процесът, отбелязваме, е много ресурсоемък. Но, това се случва по-бързо от дъмп/възстановяване - на моменти (но много по-бавно от отразяване през zfs - там всичко е много бързо). Да видим какво се случи:
Свързвам го към друга точка на монтиране - за мое удобство първо го настроих да отсъства за този пул (обърнете внимание, че той беше монтиран автоматично в /rootVG, очевидно по време на предишната операция, също така отбелязвам, че е необходимо да премахнете тази точка на монтиране - в противен случай при стартиране вместо "/" пулът ще бъде монтиран в "/rootVG" - това не е точно това, от което се нуждаем =)):
Разделът ще бъде демонтиран автоматично - ако няма отворени файлове:
Коригиране на loader.conf - това трябва да се направи във всеки случай, няма значение дали е имало проблеми с по-малък диск, както аз имах, или ако първият ви диск е бил по-голям от / равен на втория - защото предишния път този файл беше докоснат след дублиране, на диск, който вече беше убит:
Колеги с големи/равни дискове трябва да пишат "rootFS", а не "rootVG". Сега можете да рестартирате и да видите какво се е случило:
Експортиране на "rootFS" - за да не пречи:
Създаваме дял с размер половин гига - за суап. И тук мой пропуск - суапът е препоръчително да се постави в началото на диска, аз го получих в средата. Беше необходимо да се извършат тези действия веднага след създаването на пула, преди прехвърлянето на данните:
Задаваме променливи за дяла - типа на файловата система и деактивираме изчисляването на контролни суми:
Освен това се опитах да взема този суап:
Откачен. Логично - това не е файлова система. След това да продължим по обичайния начин:
По-нататък по желание. Ще откача диска,така че на втория убивам файловата система:
Сега нека тестваме какво се е случило. Пуснах MySQL, apache2, php5, пуснах архива на моя форум. Хванах трудно увисване при опит за извличане на страница чрез извличане. Хм. ДОБРЕ. През изминалия уикенд намерих повече рамки - 512Mb ECC, които видях като 128. Не стигнах до концерта - оказа се 917Mb. Краш тестът, под формата на паралелно изтегляне на форум в 200 теми, системата оцеля. LA беше 160, суапът беше използван 10%. Начертайте следните променливи в loader.conf (получени чрез приблизителна екстраполация и допълнително коригиране на стойности от стабилна система със 768Mb кадър) и намалете количеството RAM до 256Mb:
не падна - тествано чрез прехвърляне на всичко от един пул в друг, чрез:
Вярно преди да стигна тези стойности ми падаше три пъти. Така че посоката на мисълта беше правилна. Тествах го отново, работейки паралелно с pax, за да изтегля форум в 200 теми и да индексирам базата на самия форум. Полетът е нормален.
Изводи. Работещ. Дори на малко количество рамка и x32 архитектурата може да бъде завършена, за да работи стабилно. Под amd64 всичко ще работи стабилно само по себе си. Въпреки това - препоръчват се 1Gb или повече рамки и архитектура amd64 - там работата с памет е по-добре организирана.
Майната ти! Статията изпревари времето си)))) Определено ще бъде полезна. Благодаря много.
wf, 2009-11-16 в 14:51:33
Аз също го пуснах на същия хардуер. Вкъщи направих топка по самба. Първо работеше на 128MB, много бавно, но се получи. На работа го сложих на amd64, всичко е наред в samba, но когато се опитах да запазя копие на винтовете чрез nfs (използвайки dd), изпаднах в паника. И през samba същото се оправи.
Neus, 2009-11-16 в 22:39:05
--- vm.kmem_size=\"200M\" vm.kmem_size_max=\"180M\" --- как става това? може ли вече да разменим 180 и 200 места?
Точно така работи =)
Не помня точно кой, но е достатъчно да зададете текущия на един от тези два параметъра - стойността на втората ОС вече няма да се използва.
angelas_, 2009-11-22 в 03:40:51
и значението на е влажно по някакъв начин)) ufs срещу zfs излагат тестовете
vadim64, 2009-11-23 в 9:37:24
*, 2009-11-22 в 17:02:27
и значението на е влажно по някакъв начин)) ufs срещу zfs излагат тестовете
)))))))) Вероятно сте объркали с офсайт. Иди ги питай за тестове.
Рома, 2009-12-06 в 20:20:44
Pomoymu изврати всичко, даде гиг памет само за да се гарантира, че просто не пада, когато иска? ще стоя пеша))
релевантни. не е перверзен, ако няма задачи, които го изискват, не означава, че не е необходимо. по същата причина Windows мутира от xp->sp1->sp2->sp3->Vista->win7 . и размерите на системите не са толкова гадни като тези на texttops, вземете prolant HP 4 xeon с четири глави и там до дупето на RAM и хард паметта.
и все пак, въпреки че предимствата (не само по отношение на скоростта) са неоспорими, но бих искал връзка към резултатите от реални тестове
искаш ли тестове направете го, хората ще са доволни. =) и тогава има много хора, които искат, но никой не иска да го направи
2: andre - Има смисъл да се правят тестове на "боен" хардуер във всеки смисъл.
Потребител, 2010-02-15 в 2:30:54
Но какво ще стане, ако gmirror в момента е конфигуриран?
Пендолф, 2010-04-15 в 23:48:24
zpool създава rootFS /dev/ad0
Без права на достъп. рестартира с активиран ZFS, но майка му стартира в i386 и прецака светът дойде
Калаби, 2010-04-22 в 13:20:39
Въпросът е защо LOADER_ZFS_SUPPORT=YES вmake.conf, а не в src.conf. Няма значение?
На i386 системи: echo 'vfs.zfs.prefetch_disable=0' >> /boot/loader.conf
P.S. Готино нещо: ако създадете diru в .zfs/, тогава ще имаме готова моментна снимка. С други думи, имаме rootVG/home директория. Можете да създадете моментна снимка по стандартния начин: zfs snapshot vrootVG/home@test и да я видите с zfs list -t snapshot. И можете да направите това: mkdir vrootVG/home/.zfs/test Е, ние проверяваме по същия начин: zfs snapshot vrootVG/home@test. Можете да работите с моментни снимки, без да ги монтирате. Ето как се получава интересно.)))
В предишния пост, разбира се, заменетеЕ, проверяваме по същия начин: zfs snapshot vrootVG/home@testсЕ, проверяваме по същия начин: zfs list -t snapshot, но това са дреболии. Факт е, че създаването/изтриването на моментна снимка, както вече писах, работи директно и с .zfs на NFS. Въпреки че, защо не плуг. ))))
Още рана. За отговорно производство не можете да поемате рискове, освен че няма да се откажете утре))) Разбира се, Лис се постара в парфюма си, но импровизира, беше приятно за четене. Но от гледна точка на практическото приложение, "ta-arapiTSya nooooo."
chpoqxie, 2010-10-16 в 12:00:02
Да, съгласен съм с предишното.
Тук се появи zfs при извършване на scrub'a - не исках да го монтирам след рестартиране - fryakha виси и това е всичко. веднага щом не танцувах с тамбура, опитвам се да импортирам и веднага да закача. зареден от инсталационния диск на дизелово гориво - zfs взет в полет.
все още е сурово, диво сурово и недовършено. fryakha 8.1.
Mfynf, 2011-07-09 в 8:19:08