ЗА ПРОГРАМНИТЕ RAID
МАСИВИ
http://unix.ginras.ru/linux/base009.html
Алексей Федорчук
За какво е необходим програмен RAID на
потребителска машина? Разумният човек
ще отговори – защото няма апаратен
RAID. И даже да има, не е задължително,
произволно ядро на Linux да работи изправно
със също толкова произволен ATA RAID
контролер – моят опит показва, че
поддръжката им (даже и от съвременните
ядра, меко казано, е далеч
от идеала (за разлика от FreeBSD, където
всички попадали ми устройства от този
род се разпознаваха безпогрешно от
операционната система от 5-тия клон).
Така че, ако имате особено голямо желание
да използвате RAID, напълно е възможно да
се окаже, че неговата програмна реализация
(т. нар. Soft RAID) ще се окаже единствено
възможната.
ЕДНО ДРУГО ЗА RAID ИЗОБЩО
Независимо от това дали е реализиран
апаратно или програмно,
RAID масива е предназначен за представянето
на няколко физически диска (при програмният
подход, също и на дялове) във вид на едно
общо устройство. Различават се RAID масиви
с излишък и без излишък.
Към първите се отнасят RAID level 0 и програмният
линеен режим. Целта на такива масиви е
повишаването на бързодействието на
дисковите операции или повече удобство
при работа.
Масивите с излишък са предназначени
най-вече за повишаване надеждността на
съхранение на данните, а ако при това
постигнем и увеличаване на бързодействието
на дисковите операции, може да го
разглеждаме като безплатен бонус.
На практика, в Linux (и FreeBSD) се използват
само две нива на RAID с излишък – ниво 1 и
ниво 5 (в The Software-RAID HOWTO е описана и
конфигурация на програмното ниво 4, но
това не е нищо повече от догадка на
автора, според собственото му признание).
RAID level 1 (наричан още огледален режим,
mirroring) е просто огледало от два диска,
тоест този масив притежава 100% излишък
– при излизане от строя
на единия диск, цялата информация се
запазва на дублиращия диск (макар, че в
процеса на работа те са равноправни).
Разбира се, не може да говорим за никакво
увеличение на производителността в
този случай. Но е възможно комбинирането
на level 0 с level 1 (тази комбинация се нарича
level 0+1 или понякога
level 10), когато една двойка дискове в
паралелен режим се комбинира с друга
двойка, също работеща в паралелен
режим. Не е трудно да пресметнем, че в
този случай е желателно да имаме 4 отделни
IDE контролера.
При RAID level 5 данните се разпределят върху
всички дискове, които образуват масива
и се допълват с контролни суми, по които
се осъществява възстановяването на
данните в случай на отказ на едното
устройство. Минималното количество
дискове в този масив е три и неговият
общ обем е равен на произведението на
обема на най-малкият от тях по техния
брой минус единица, тъй като за съхранение
на контролните суми се използва част
от пространството на всеки диск, като
сумата от тези пространства е равна на
обема на единично устройство. Масивите
от 5 ниво се смятат за изключително
надеждни и теоретично даже обещават
увеличение на бързодействието1
НЯКОЛКО ДУМИ ЗА
АПАРАТНИЯТ ATA RAID
До неотдавна апаратните контролери ATA
RAID, реализирани на отделни PCI карти или
разхвърляни по дънната платка се
основаваха на чиповете, произвеждани
от три фирми – Promise, HighPoint и Silicon Image.
Теоретично, и трите чипа се поддържат
от каноничното ядро на Linux, за което при
неговото конфигуриран (в менюто
ATA/IDE/MFM/RLL support) трябва да се включи общата
поддръжка на ATA RAID (Support for IDE Raid controllers) и
поддръжката на съответният чип.
Поддръжката на ATA RAID може да бъде модулна
или, ако се предполага начално зареждане
от дисковия масив, вградена в ядрото. В
последният случай се предполага включване
на още една възможност – зареждане от
устройство на външен контролер (Boot
off-board chipsets first support), а също и използването
на някои трикове, ако за зареждане на
операционната система използваме GRUB.
Но на практика се оказва, че нещата не
са толкова добре и работата с ATA RAID не
може да се отнесе към силните страни на
Linux2.
От три преминали през мен дънни платки
с вградени RAID контролери, на две от тях
вграденият RAID контролер не се откри по
никакъв начин от системата. Вярно, че
след съответната настройка на ядрото,
самите контролери се познаваха от
системата, но включените към тях дискове
– не. Нещо повече – появи се един парадокс
– в качеството на RAID масив се представяше
нормалният Master диск на първия канала
на обикновения IDE контролер.
В някои случаи могат да помогнат
драйверите от производителя на чипа,
но трябва да помним, че тези драйвери
(всъщност, допълнителни модули към
ядрата) са достъпни изключително в
двоичен вид и са компилирани не само за
определена версия на ядрото, но и за
конкретна версия (по правило не най-новата)
на конкретна дистрибуция (при мен са
попадали обикновено за Red Hat и Suse). Така,
че не мога да гарантирам тяхната
работоспособност в произволна Linux
система.
Досега подобно състояние на нещата
можеше, ако не да се оправдае, то поне
да се обясни с факта, че ATA RAID се възприемаше
не толкова като екзотично устройство,
а по-скоро като пожелателно (въпреки,
че мои наблюдения, поне една трета от
дънните платки, произведени през
последните две години се комплектоваха
с RAID контролер от някоя фирма). В момента
такива проблеми вече няма – с появата
на чипсета i875/865 и неговият южен мост
във вариант ICH5R, апаратните RAID контролери
станаха стандартно устройство на
съвременните машини. Надяваме се, че
това ще подобри ситуацията с поддържането
на такива устройства от ядрото на Linux.
Още повече, че 5-ят клон на FreeBSD, в който
няма никакви проблеми с тях, е пред очите
ни.
НУЖЕН ЛИ Е RAID НА ХОРАТА?
Остава все пак да решим, защо въобще е
нужен RAID на настолна машина. Същият този
разумен човек3
ще каже, че е необходим:
или за увеличаване на производителността
(RAID level 0);
или за увеличаване на надеждността на
съхранение на данните (RAID level 1);
или за щастливото съчетаване на горните
две (RAID level 5, всички останали нива на
RAID за настолна машина нямат никакво
практическо значение).
На всички тези отговори, може да приведем
не по малко разумни възражения, такива
като:
обикновено производителността на
дисковата подсистема на настолна
машина4
нито при FreeBSD, нито особено при Linux, не
е критична;
RAID level 1 за повечето потребители не е
оправдан икономически;
RAID level 5 гарантира защитата на данни от
загуби само при условие, че излезлият
от строя диск може да се замени със
същия такъв, стоял в шкафа на масата5;
всеки RAID с излишък (а това означава от
ниво 1 нагоре) в никаква степен не е
застрахован от грешки на потребителя
– причини, поради които са били загубени
повече данни, отколкото от всички
проблеми с хардуера, взети заедно и ще
отбележа в скоби, че той по никакъв
начин не отменя резервното копиране
на данните.
По този начин, едва ли не единствената
причина за използването на RAID са
съображенията за удобство – дисковите
дялове на два или повече физически диска
се сливат и на тях се създава единна
файлова система, например за директорията
/home с всички потребителски данни (разбира
се, теоретично RAID масив може да се създаде
от дяловете на един диск, но в това има
също толкова смисъл, колкото и в това
да чешем дясното си ухо с палеца на левия
си крак).
Разбира се, съществува и друг начин за
свързване дяловете на различни дискове
– технологията LVM (Linux Volume Manager), подробно
описана в предишната
статия, която между другото предоставя
такива полезни възможности като изменение
размера на файловата система, включването
към нея “в движение” на допълнителни
дялове и т. н. Само че, нужно ли е това на
настолна машина? Моето мнение е (а аз
използвах LVM продължително време именно
на своята БНМ – бойна настолна машина),
че не е много необходимо. За една година
нито веднъж не се наложи да преразпределя
дисковото пространство. А ако изведнъж
се появяваха нови дискове – нямаше
нужда те да се добавят към съществуващата
файлова система, още повече, че вече
няма място къде да ги слагам в машината.
Така, че ако програмният RAID е по-лесен
начин за свързване на дисково пространство,
отколкото е технологията LVM, защо да не
се възползваме от него? Ето че реших и
да разуча този въпрос при поредната
преконфигурация на моята машина, на
основата на Linux. Още повече, че преди
това натрупах опит при създаване на
програмен RAID под управлението на FreeBSD
(където технологията LVM не се поддържа).
Нека се разберем веднага – нашият
програмен RAID ще се използва само за
файловата система, монтирана в директорията
/home – няма да става
дума нито за главната директория, нито
за зареждане с RAID. И поради това има
смисъл да разглеждаме само две
разновидности на RAID – така нареченият
линеен режим и RAID level 0. И при двете
разновидности дисковите дялове чисто
механически се съединяват и за
операционната система (и нейните
потребители) изглеждат като един дял.
Разликата между тях е в това, че при
линейния режим, данните физически се
записват първо на единия диск, след това
на втория, тоест те не осигуряват нищо
повече освен удобство при работата с
дисковете.
В масива от нулево ниво (наричан също
striple режим, който в случая може да се
приеме като паралелен) е обратно – всяка
порция от записваните данни се разделя
на две равни части, едната от които по
едно и също време се
записва на единия дисков дял, а другата
– на другия, което теоретично трябва
да води до повишаване на бързодействието
на дисковите операции. На практика
също се постига увеличаване на
бързодействието, но само в случаите,
когато дисковете са разположени на
различни IDE канали (SCSI дискове също няма
да обсъждаме). В противният случай не
само няма да имаме повишаване на
бързодействието, но е много вероятно
то да спадне (съдейки по собствения си
опит в случая с LVM, при която дисковият
обмен се извършва по подобен начин,
където бързодействието спадна просто
катастрофално)
Освен това, RAID level 0 не спомага за повишаване
надеждността на съхраняване на данните
– при отказ даже на един диск, ще пропаднат
всичките (докато при линейния режим
информацията ще се запази поне
приблизително). Още повече, че употребата
на паралелния режим може да бъде оправдана
– колкото и да приказвам за некритичността
на бързодействието на дисковите операции
при настолните машини, все пак е приятно,
когато два-три гигабайта се копират ако
не двойно, то поне 1,5 пъти по-бързо (вярно
е, че не мога да гарантирам за точността
на количествената оценка).
ПОДГОТВИТЕЛЕН ЕТАП
Както е обичайно за Linux, програмният
RAID от произволно ниво може да бъде
създаден по повече от един начин – в
този случай по два (между другото и при
FreeBSD има два начина за организиране на
RAID). Но независимо от това, на кой от
начините ще се спрем и какво ниво на
RAID сме избрали, във всеки един от случаите
ще изисква изпълнението на няколко
условия и определен комплекс от действия.
Първото условие, естествено е наличието
на повече от един физически диск. При
това е очевидно, че ако ще създаваме
RAID с линеен режим на работа, броят им
няма значение, докато ако ще създаваме
RAID level 0 за предпочитане е техният брой
да бъде четен (макар, че доколкото
разбирам, за разлика от апаратният RAID,
това не е задължително). И пак ще се
повторя – при линейния режим на включване,
няма значение какъв е реда на включване
на дисковете към контролера, докато при
избор на RAID level 0 е желателно да разположим
дисковете на различни контролери6.
След това е необходимо да създадем върху
дисковете (с помощта на fdisk,
cfdisk, parted или с други,
специфични за дистрибуцията специализирани
програми) два дяла. И пак, ако ще използваме
линеен режим, големината на дяловете е
без значение, докато при паралелния
режим е желателно те да бъдат равни (или
поне приблизително равни) по обем. В
противен случай, големината на общия
масив ще бъде намалена с разликата между
неговите съставящи го части.7
Накрая, на дяловете, предназначени за
обединяване в масив е добре да бъде
присвоен съответният идентификатор за
тип файлова система – fd (в шестнадесетична
нотация), който така и се нарича – RAID
auto detection. По принцип, това не е задължително,
но както ще стане ясно по-нататък,
сериозно опростява нещата.
Ако разделянето на диска се извършва с
програмата cfdisk, в нейния списък
с идентификатори няма RAID auto detection, което
не означава, че не може да го присвоим
с нея – трябва просто след избора на
менюто за смяна на типа на дяла, нагло
да въведем fd и всичко ще бъде наред.
Сега е ред на ядрото на системата – за
използване на програмен RAID, в неговата
конфигурация трябва да бъдат включени
съответните опции от раздела Multidevice
support (RAID and LVM) на главното меню, генерирано
с командата
$ make menuconfig
А именно:
Общата поддръжка на „множествени“
устройства може да бъде само вградена
в ядрото, а останалите опции могат да
бъдат или вградени, или включени като
модули (това е прието по подразбиране
в повечето пакетни дистрибуции от типа
на Red Hat). В разглеждания от нас случай,
това е без значение. Вграждането на
поддръжката на RAID в ядрото е задължителна
само в тези случаи, когато на масива се
разполага коренната файлова система
и/или той ще изпълнява ролята на зареждащо8
устройство – но ние се разбрахме да не
правим нито едното, нито другото. А и
при направена съответна конфигурация
на виртуален зареждащ диск (initrd), даже
и при тези случаи може да минем с модули
към ядрото. Още повече, че винаги вграждам
поддръжката на необходимите ми устройства
– нека ядрото стане по-голямо, но затова
ще имам по-малко грижи с настройването
на модулите (а и въобще ми се струва, че
така става по-бързо, а кой се интересува
вече от размера на ядрото?).
От опциите за конфигуриране на ядрото,
които не са директно свързани с RAID, е
добре да включим поддържането на
файловата система на процесите (procfs),
което ще ни позволи да имаме информация
за текущото състояние на масива. Това
се извършва в менюто File systems на главното
меню (/proc file system support). Разбира се, тази
файлова система трябва да бъде описана
във файла /etc/fstab със съответният ред:
proc /proc proc defaults 0 0
за автоматично монтиране при стартирането
на системата. Между другото, поддържането
на procfs никога не е излишна ...
ПРОЦЕСЪТ НА СЪЗДАВАНЕ
Вече може да пристъпим към създаването
на RAID масива, за което ще
ни е необходим съответният програмен
инструментариум. И тук се появява тази
алтернатива, за която споменах по-рано
– традиционният raidtools и по-новия mdadm. В
крайна сметка, във всяка пълнофункционална
дистрибуция ще се намери поне единият
от тях (и нещо ми подсказва, че този един
ще се окаже raidtools).
Но именно за него не ми се иска да говоря
тук. Първо, защото той е многократно
описан. Съществува фундаменталният The
Software-RAID HOWTO, написан от Якоб Остергаард
(Jacob Ostergaard) и преведен на руски език от
Максим
Дзюманенко9
(който може да бъде намерен и на
http://linux.yaroslavl.ru10).
Немалко внимание на RAID масивите е отделил
създателя на Gentoo Linux, Даниел Робинс в
своята серия от публикации на сайта на
IBM-Linux
(част
1, част
2). И всички тези документи са посветени
изключително на използването на raidtools
(на който родното място е
http://people.redhat.com/mingo/raidtools).
А за mdadm сведения може да се получат само
от неговата документация, като преводи
на руски език не съм срещал11.
Най-важното е, че mdadm превъзхожда raidtools
от гледна точна на удобството на
използване (за пореден път трябва да
подчертая, че разсъждавам от позицията
на потребител, а не на администратор).
И така – mdadm. Факт е, че не винаги може
да го намерите във вашата дистрибуция,
което не е голям проблем – винаги можете
да го изтеглите или от авторският
сайт, или от сайта
на каноничният Linux във вид на изходен
код (за текущата версия – mdadm-1.3.0.tgz),
работата с който, след обичайното (tar
-xzvf mdamd-1.X.X.tgz) разопаковане, е също
толкова обичайната последователност
от команди make и
make install (нека обърнем
внимание на факта, че програмата е
толкова проста, че не се нуждае от
предварително конфигуриране с командата
./configure).
След завършване на инсталацията, ние
намираме единственият изпълним файл в
директорията /sbin/mdadm (която може да
променим, ако редактираме на ръка
~/mdamd_src_dir/Makefile, но дали това е необходимо?
На такива програми мястото им е точно
в директорията /sbin), както и няколко
man-страници, имащи отношение по темата
(/usr/share/man/man5/mdadm.conf.5 и
/usr/share/man/man8/mdadm.8),
които съдържат напълно достатъчна
информация за да можем да пристъпим на
практика към създаване на собствен RAID
масив. Към което ще пристъпим и ние.
Не е трудно да се досетим, че щом от
целият пакет в крайна сметка се е получил
само един изпълним файл, трябва да го
стартираме именно него за да създадем
масива. Как – ще научим от man
-8 mdadm (някакви сведения може да
получим и от mdadm –help).
И единият, и другият източник показват,
че за образуването на RAID масив, командата
mdadm изисква едната от двете възможни
опции – -C (еквивалентно е --create) или -B
(еквивалент --build) – обърнете внимание
и в двата случая на регистъра на кратката
форма на въвеждане на опцията. Каква е
разликата между тях?
Опцията -B създава масив без собствен
суперблок, което, както ще стане ясно
по-нататък, за потребителя премахва
част от предимствата на mdadm и затова
повече към нея няма да се връщаме. А
използването на опцията -C създава същия
този суперблок и в която опция е цялата
сила на програмата mdadm.
И така – опцията -C. Елементарната логика
ни подсказва, че като основна опция, тя
изисква аргумент – името на файла на
устройството, отговарящо на създавания
масив (например /dev/md0 или
при задействана файлова система на
устройствата devfs - /dev/md/0), а също и
указването на някои допълнителни данни
като: ниво на масива (режим), количество
устройства в него, и накрая – имената
на файловете на устройствата, образуващи
масива. Това се постига с използване на
опцията --level=# (или съкратено -l #) и
--raid-devices=## (в съкратена форма - -n ##), след
което се изброяват имената на файловете,
нещо подобно на /dev/hda3, /dev/hdb3). В крайна
сметка, най-простият случай на създаване
на RAID с паралелен режим изглежда по
следния начин:
$ mdadm --create /dev/md0 --level=0
--raid-devices=2 /dev/hd[a,b]3
За масив от ниво 0, допустимите стойности
на опцията --level са raid0 или stripe, а за масив
с линеен режим, тя може да приема стойност
linear (тоест -l linear).
Допълнително, при паралелен режим, може
да зададем още един параметър – размера
на блока “разпределени”данни, така
нареченият chunk, във вида
chunk=размер_в_килобайтове (в съкратена
форма -c ##). Разсъждавайки теоретично,
колкото е по-голяма стойността на chunk
(дайте да не подбираме за нея руски
еквивалент), толкова по-голямо трябва
да бъде бързодействието на масива. Но
тази теория не се потвърждава от
практическите измерения, поради което
съвсем спокойно може да я пропуснем –
стойността и по подразбиране е 64
килобайта. Между другото, ако някой
успее чрез количествени тестове да
опровергае това мое твърдение, ще му
бъда особено благодарен. Очевидно е, че
за масив с линеен режим на работа, опцията
-c няма физически смисъл
Във всеки случай, след изпълнението на
посочената по-горе команда, RAID масива
ще бъде създаден, което лесно може да
проверим с командата
$ less /proc/mdstat
Веднага след създаването си, масива е
готов за използване – с команда от вида
mkefs (или в зависимост от предпочитанията
mkreiserfs, mkxfs и т. н.) на него може да се
създаде една или друга файлова система.
Макар, че никой не ни забранява да го
разделим на дялове с програмата
fdisk12.
Но пак ще повторя, ако ние сме създаваме
RAID за една единствена система от типа
/home, не са необходими никакви допълнителни
действия за разделяне на диска.
След като създадем файловата система
на новообразувания масив, ние трябва
да я монтираме в желаната директория с
помощта на ред, подобен на този, във
файла /etc/fstab
/dev/md/0 /home reiserfs noatime,notail 0 0
Не трябва да забравяме, разбира се, да
пренесем съдържанието на старата
директория /home в някакво временно
хранилище до преместването му на новото
място, след което може да рестартираме
системата и да се убедим в това, че нашата
/home директория се е уголемила по вълшебен
начин.
Внимателният читател, който е добре
запознат с документацията за raidtools може
да попита къде е конфигурационният
файл, който описва RAID масива. Отговорът
е, че при използване на mdadm, настройка
на съответните идентификатори на
образуващите масива дялове (тук е мястото
да споменете с добра дума RAID Auto detection) и
последно, създаването на масива със
собствен суперблок, няма нужда от никакъв
конфигурационен файл.
Но при наличие на желание е възможно
създаването и на конфигурационен файл
за масива – в някои случаи това може да
опрости неговото управление, за което
пак се връщаме към командата mdadm. Освен
споменатите по-горе основни опции, тя
има още няколко допълнителни. И във
формата
$ mdadm --detail --scan
е способна да изведе информация за
съществуващия масив. Достатъчно е да
пренасочим нейният изход във файл (а
такъв традиционно е /etc/mdadm.conf) и съответният
конфигурационен файл ще бъде създаден
(нека да извърша тази операция, докато
не съм забравил и след рестартирането
на системата ще продължа по-нататък)..
ДОПЪЛНИТЕЛНИ ЗАБЕЛЕЖКИ
От това, че продължавам своето съчинение,
можете да се убедите, че рестартирането
на системата е минало успешно. Така че
сега е точният момент да си спомним за
другите команди на mdadm. С една от тях се
запознахме още преди – това е –help за
извеждане на помощна информация. Каква,
може да конкретизираме, ако укажем тази
опция с някоя от останалите възможни
опции. Например, командата
$ mdadm --create --help
ще изведе с подробности процеса на
създаване на масива.
С друга опция (--detail или -D – всички основни
опции, в съкратената си форма се изписват
с главни букви) ние се сблъскахме в
предишния раздел – тя извежда информация
за съществуващите масиви. Подобно
предназначение имат и опциите –query и
–examine (в съкратена форма съответно -Q и
-E) – за подробности може да погледнете
в man страниците им.
А опциите –assemble (-A) и -monitor, или –follow (-F)
са предназначени за управление на
съществуващите масиви. В частност, те
позволяват да добавяте нови устройства
към него или да отстраните вече
съществуващо при определени условия.
Между другото и за това чичо Манчо13
ще ви разкаже подробно, ако го помолите
по съответния начин.
Най-общо казано, създаването на RAID масив
с възможностите на mdadm е много прост
процес (а управление на масива от редови
потребител на настолна машина, най-вероятно
няма да е необходимо). Така, че ако няма
нужда от допълнителните възможности,
предлагани от технологията LVM, при
наличие на два диска има разумна причина
да се ограничим с тях, още повече, че и
логическите томове никой не ни е забранил
да разположим върху програмен RAID масив.
АЛТЕРНАТИВА
В името на справедливостта трябва да
кажем и няколко думи за набора от програми
raidtools и начините за работа с тях. За
разлика от mdadm, той изисква непремено
наличие на конфигурационен файл –
/etc/raidtab, като е необходимо той да бъде
създаден (ръчно, в текстов редактор)
преди изпълнението на каквито и да са
команди за създаване на RAID.
Между другото, структурата на /etc/raidtab
е много проста. Трябва само да помним,
че всяка от изброените по-долу точки
трябва да бъде на отделен ред, стойностите
в който се отделят или с интервал, или
с табулация – все пак това е база данни
(макар и проста), а не кучешка опашка. И
така:
отначало се посочва името на файла на
raid устройството – например
raiddev
/dev/md0;
след това се поосчва нивото на масива
или неговия режим – raid-level
0 за паралелен режим или raid
level linear за линеен режим;
след това се посочва количеството
устройства в масива – nr-raid-disks
2;
след това се посочва размера на блока
за „разпределени данни“ (chunk) в
килобайтове – например chunk-size
32. Очевидно е, че при линеен режим
тази величина е безсмислена, поради
което, при линеен режим, тук може да се
сложи произволна стойност;
след всичко това е възможно (а по-скоро
е необходимо) да се посочи, че масива е
длъжен да има собствен суперблок –
persistent-superblock 1.
И най-накрая се изброяват имената на
всички обединявани устройства, с техните
поредни номера, започвайки от нула:
device /dev/hda3 raid-disk 0 device
/dev/hdb3 raid-disk 1
Завършвайки редактирането на файла
/etc/raidtab (ще рискувам да повторя, че това
е обикновен текстов файл, създаван с
текстов редактор), активираме RAID с
командата mkraid /dev/md0 и
преглеждаме файла /proc/mdstat за да се убедим,
че всичко е станало така, както сме го
замислили.
По-сложно е, отколкото употребата на
mdadm, но не толкова много, не е ли така?
Още повече, че целият процес за създаване
на RAID с използване на набора програми
от raidtools е детайлно описан в съответното
HOWTO, както и в редица специални статии.
КОМЕНТАРИ НА ВЛАДИМИР
ХОЛМАНОВ
За взаимодействието
между програмният RAID и LVM
По мои наблюдения, взаимодействие е
възможно само между soft-RAID 1 и LVM (останалите
нива са недостъпни, но това не е нищо
повече от „практическо наблюдение“).
Именно за това е необходима опцията -B
на командата mdadm. В противен случай, в
началото се създава raid огледало в стар
стил, тоест без дескриптор (а не със
суперблок, както е в статията) –
дескриптора е необходим за LVM. Суперблока
присъства независимо от стила и се
съхранява някъде в последните 4 kb на
дисковия дял, а мястото на дескриптора
е сред първите 512 байта. Като основа се
взимат първите два дяла, които не трябва
да са от тип 83 (като за „класическият
стар стил“), а от тип 8e. Разбира се, че
конфигурационният файл в директорията
/etc става задължителен (между другото,
предпочитам да използвам raidtools, но това
не трябва да оказва влияние).
За надеждността
на RAID
На мен един от дисковете от raid огледалото
се разхлопа, което не го забелязах
веднага и в резултат на това, някои от
лошите сектори се прехвърлиха върху
изправния диск. Но RAID може да се използва
с надежден „backup“. Ако някъде в опашката
на дисковете се създаде отделен RAID,
„демонтиран и деактивиран“ в процеса
на работа и монтиран само за „backup“ цели
– това е достатъчно надеждно14.
Mdadm vs raidtools
Пакета mdadm съдържа една голяма универсална
двоична програма, което е удобно за
интерактивна работа с RAID. Пакета raidtools
съдържа няколко специализирани, неголеми
двоични програми. А размера на файла е
важен параметър при използването за
начално зареждане на initrd15.
По традиция, в скриптовете за инициализация
се използват команди от raidtools. Даже ако
масива се създава с помощта на mdadm, след
рестартирането не трябва да има проблеми
– за дялове от тип fd. Но ако масива е
създаден на дял от друг тип, е възможна
ситуация, когато дясната ръка няма да
знае какво прави лявата. Причината за
това е, че автоматичното определяне не
работи, а конфигурационните файлове на
raidtools и mdadm да различни. Избора остава
на потребителите.
Превод: Николай
Ангелов
добре
зле
Вариант за отпечатване
