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

LXF154:По рецептам доктора Брауна

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
 
Строка 1: Строка 1:
 
[[Категория: Постоянные рубрики]]   
 
[[Категория: Постоянные рубрики]]   
 
[[Файл:LXF00.tut1.chris2_fmt.png|100px|left]]
 
[[Файл:LXF00.tut1.chris2_fmt.png|100px|left]]
{{Врезка|Ширина=25%|Заголовок=|Содержание=Эзотерическое системное администрирование из причудливых заворотов кишок серверной}}
+
{{Врезка|Ширина=98%|Заголовок=Эзотерическое системное администрирование из причудливых заворотов кишок серверной|Содержание=}}
 
:'''''Д-р Крис Браун''': Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.''
 
:'''''Д-р Крис Браун''': Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.''
  

Текущая версия на 10:37, 24 июня 2018

LXF00.tut1.chris2 fmt.png
Д-р Крис Браун: Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.

Содержание

[править] По рецептам доктора Брауна

[править] Как небо и земля

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

В этом ме­ся­це я хо­чу рас­ска­зать вам о па­ре книг. Обе они – по сис­тем­но­му ад­минист­ри­ро­ванию, при­мер­но в той же сте­пени, в ко­то­рой Мо­царт и Джи­ми Хен­д­рикс оба му­зы­кан­ты: по­то­му что на этом сход­ст­во и за­кан­чи­ва­ет­ся.

Пер­вая, Red Hat Certified Technician & Engineer [Сер­ти­фи­ци­ро­ван­ный спе­циа­лист и ин­женер Red Hat] Асг­ха­ра Гхо­ри [Asghar Ghori] – во мно­гом книга из се­рии «как это сде­лать», и по­свя­ще­на Red Hat Linux. Вто­рая, The Practice of System and Network Administration [Прак­ти­ка сис­тем­но­го и сете­во­го ад­минист­ри­ро­вания] Ли­мон­чел­ли, Хо­га­на и Ча­лу­па [Limoncelli, Hogan & Chalup] – ско­рее книга из се­рии «по­че­му», не свя­за­нная ни с ка­кой кон­крет­ной ОС, не го­во­ря уж о ди­ст­ри­бу­ти­ве Linux.

Ес­ли вы хо­ти­те уз­нать, ка­кая ко­ман­да рас­ши­рит ло­ги­че­­ский раз­де­л, чи­тай­те Гхо­ри. Ес­ли вы хо­ти­те уз­нать, по­че­му сто­ит за­ранее и ре­гу­ляр­но вы­де­лить вре­мя для техоб­слу­жи­вания, чи­тай­те Ли­мон­чел­ли (это­му у него отведе­на це­лая гла­ва).

Книга Гхо­ри пред­на­зна­че­на для по­мо­щи в сда­че эк­за­ме­нов RH202 и RH302, но не при­вя­за­на на­мерт­во к за­даниям эк­за­ме­нов – это удоб­ное спра­воч­ное ру­ко­во­дство для ад­минист­ра­то­ров RHEL 5. В на­чале опи­сы­ва­ют­ся те­мы «конеч­но­го поль­зо­ва­те­ля» (основ­ные ко­ман­ды, фай­лы, ка­та­ло­ги, пра­ва досту­па, ре­дак­ти­ро­вание тек­ста и обо­лоч­ки).

За­тем по­сле раз­оча­ро­вы­ваю­щей гла­вы о на­пи­сании скрип­тов обо­лоч­ки Гхо­ри пе­ре­хо­дит к те­мам, ин­те­рес­ным сис­тем­но­му ад­минист­ра­то­ру – уста­нов­ке, управ­лению па­ке­та­ми, раз­де­лам, менед­же­ру ло­ги­че­­ских то­мов, RAID, swap, за­пуску сис­те­мы, яд­ру, ре­зерв­но­му ко­пи­ро­ванию и ши­ро­ко­му на­бо­ру се­те­вых сер­ви­сов. Да­на мас­са при­ме­ров за­пуска команд, таб­ли­цы па­ра­мет­ров команд и фай­лов на­строй­ки – хо­тя я за­cек пару оши­бок.

Книга Ли­мон­чел­ли на­пи­са­на на ином уровне. Ее це­ле­вая ау­ди­то­рия – сисад­мины средних и круп­ных ор­ганиза­ций, и о команд­ной стро­ке речь здесь не идет. Не­ко­то­рые раз­де­лы по­свя­ще­ны уст­рой­ст­вам (на­при­мер, 60-странич­ная гла­ва о про­ек­ти­ро­вании да­та­-цен­тра), а неко­то­рые – сер­ви­сам (гла­вы о пе­ча­ти, элек­трон­ной поч­те, хранили­щах, ре­зерв­ном ко­пи­ро­вании и web-сер­ве­рах).

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


[править] Etcetera в ил­лю­ст­ра­ци­ях – часть 2

LXF54.braun1.png

Ме­сяц за ме­ся­цем изу­чай­те фай­лы в /etc по на­ше­му удоб­но­му ру­ко­во­дству. По­зна­ко­мим­ся с fstab.

Файл /etc/fstab (со­кра­щение от “filesystem table” – таб­ли­ца фай­ло­вой сис­те­мы) оп­ре­де­ля­ет, как вся фай­ло­вая сис­те­ма Linux фор­ми­ру­ет­ся из раз­лич­ных ис­точников (дис­ко­вые раз­де­лы, ло­ги­че­­ские уровни, экс­пор­ти­руе­мые ка­та­ло­ги NFS и т. д.), об­ра­зуя еди­ную ие­рар­хию. В нем за­да­ют­ся фай­ло­вые сис­те­мы (с техниче­­ской точ­ки зрения, блоч­ные уст­рой­ст­ва) и их точ­ки мон­ти­ро­вания в де­ре­ве ка­та­ло­гов Linux. Этот файл при­ме­ня­ет­ся мно­го лет. Его син­так­сис доста­точ­но прост, но ес­ли вы не уве­ре­ны в

Три при­ме­ра строк из это­го фай­ла на пер­вом ри­сун­ке ил­лю­ст­ри­ру­ют три спо­со­ба оп­ре­де­ления мон­ти­руе­мой фай­ло­вой сис­те­мы. Тра­ди­ци­он­ное имя уст­рой­ст­ва, та­кое как /dev/sda6 – са­мый ста­рый и са­мый про­стой спо­соб, но он мо­жет при­вес­ти к про­бле­мам при до­бав­лении но­вых дис­ков, так как из­ме­нят­ся име­на уст­ройств. Бо­лее на­деж­ный ва­ри­ант – ис­поль­зо­вать тек­сто­вую мет­ку, за­пи­сы­вае­мую в раз­дел при соз­дании фай­ло­вой сис­те­мы. Обыч­но текст мет­ки со­от­вет­ст­ву­ет планируе­мой точ­ке мон­ти­ро­вания. В по­ряд­ке аль­тер­на­ти­вы, здесь мож­но ука­зать UUID. В средней стро­ке на ри­сун­ке по­ка­за­на запись для мон­ти­ро­вания NFS с фай­ло­во­го сер­ве­ра foo. Доступ к этим фай­лам осу­ще­ст­в­ля­ет­ся по про­то­ко­лу NFS – это не счи­та­ет­ся блоч­ным уст­рой­ст­вом, и мы не за­пуска­ем fsck для этой час­ти фай­ло­вой сис­те­мы: де­лать это нуж­но на сер­ве­ре.

Мон­ти­ро­вания для за­пи­сей, при­ве­ден­ных на рис. 1, вы­пол­ня­ют­ся ав­то­ма­ти­че­­ски, обыч­но команд­ной mount -a в за­гру­зоч­ном скрип­те.

Стро­ки на рис. 2 слу­жат дру­гой це­ли. Здесь оп­ция noauto оз­на­ча­ет, что запись бу­дет про­иг­но­ри­ро­ва­на ко­ман­дой mount -a (и мон­ти­ро­вание во вре­мя за­груз­ки про­из­во­дить­ся не бу­дет). Вме­сто это­го стро­ка свя­зы­ва­ет имя уст­рой­ст­ва с точ­кой мон­ти­ро­вания, по­это­му его мож­но смон­ти­ро­вать про­стой ко­ман­дой:

$ mount /dev/sdc

вме­сто

$ mount /dev/sdc /media/cdrom

Оп­ция user оз­на­ча­ет, что мон­ти­ро­вать уст­рой­ст­во мо­гут обыч­ные поль­зо­ва­те­ли. По умол­чанию мон­ти­ро­вать и раз­мон­ти­ро­вать уст­рой­ст­ва мо­жет толь­ко суперпользователь-root.

В фай­ле fstab вы так­же уви­ди­те за­пи­си, ко­то­рым со­от­вет­ст­ву­ют не фи­зи­че­­ские фай­ло­вые сис­те­мы, а псев­до­фай­ло­вые сис­те­мы, ко­то­рые яв­ля­ют­ся лишь пло­дом во­об­ра­жения яд­ра. Они пред­став­ля­ют струк­ту­ры дан­ных яд­ра в ви­де фай­лов. В них вхо­дят фай­ло­вая сис­те­ма proc (обыч­но мон­ти­ру­ет­ся в /proc) и фай­ло­вая сис­те­ма sysfs (мон­ти­ру­ет­ся в /sys).

LXF54.braun2.png


[править] Etcetera в ил­лю­ст­ра­ци­ях – часть 3

Те­перь на­стал че­ред зна­ком­ст­ва с фай­лом nsswitch.conf – ука­за­те­лем на ис­точники ин­фор­ма­ции.

LXF54.braun3.png

В стан­дарт­ной биб­лио­те­ке C в Linux есть се­мей­ст­во функ­ций, на­зы­вае­мых «раз­ре­ши­те­ля­ми»: они раз­ре­ша­ют за­про­сы. Так, функ­ция getpwuid() на­хо­дит учет­ную запись поль­зо­ва­те­ля по его чи­сло­во­му иден­ти­фи­ка­то­ру, а функ­ция gethostbyname() на­хо­дит ком­пь­ю­тер по имени, воз­вра­щая (сре­ди про­че­го) его IP-ад­рес. А, скажем, функ­ция getservbyname() ищет сер­вис по имени, воз­вра­щая но­мер его пор­та и про­то­кол.

Эти функ­ции су­ще­ст­ву­ют с давних пор – они бы­ли в UNIX еще до то­го, как про­блеск Linux мельк­нул в гла­зах Ли­ну­са Тор­вальд­са. В те да­ле­кие вре­ме­на ин­фор­ма­ция раз­ме­ща­лась в локаль­ных фай­лах, та­ких как /etc/passwd, /etc/hosts и /etc/services – и боль­ше ниче­го не бы­ло. Поз­же поя­ви­лись дру­гие ис­точники ин­фор­ма­ции. На­при­мер, в Sun Microsystems при­ду­ма­ли NIS, и у нас поя­вил­ся DNS для раз­ре­шения имен хостов. Sun так­же до­ба­ви­ла несколь­ко при­мо­чек, что­бы «раз­ре­ши­те­ли» ис­ка­ли ин­фор­ма­цию бо­лее чем в од­ном мес­те. Как буд­то при­по­ми­наю, что стро­ки в /etc/passwd, на­чи­нав­шие­ся с «+», ве­ле­ли «раз­ре­ши­те­лю» так­же пой­ти и за­гля­нуть в NIS.

Со­вре­мен­ные «раз­ре­ши­те­ли» ис­поль­зу­ют бо­лее эле­гант­ный и на­ра­щи­вае­мый ме­ханизм на­прав­ления к оп­ре­де­лен­но­му ис­точнику ин­фор­ма­ции – так на­зы­вае­мый файл пе­ре­клю­чения сер­ви­сов имен (Name Service Switch) /etc/nsswitch.conf. Фор­мат это­го фай­ла по­ка­зан на ри­сун­ке ввер­ху. Он доста­точ­но прост, хо­тя содержит од­но неоче­вид­ное обо­зна­чение – [NOTFOUND=return], ко­то­рое пред­став­ля­ет со­бой при­мер дей­ст­вия. Оно пре­достав­ля­ет бо­лее тон­кий кон­троль над ло­ги­кой про­цес­са по­ис­ка, свя­зы­вая ста­тус за­про­са (один из спи­ска SUCCESS, NOTFOUND, UNAVAIL или TRYAGAIN) с дей­ст­ви­ем (return или continue). Об­ра­ти­те внимание, что ста­тус NOTFOUND оз­на­ча­ет, что сер­вис был успеш­но оп­ро­шен, но со­об­щил, что у него нет дан­ных в от­вет на по­лу­чен­ный за­прос, а не то, что не уда­лось най­ти сам сер­вис.

LXF54.braun4.png

На­ра­щи­вае­мость ме­ханиз­ма по­ис­ка оз­на­ча­ет, что мож­но до­бав­лять но­вые ис­точники ин­фор­ма­ции. Это ра­бо­та­ет бла­го­да­ря то­му, что в nsswitch.conf за­да­ет­ся про­стое со­от­вет­ст­вие ме­ж­ду име­на­ми сер­ви­сов и биб­лио­те­ка­ми, их реа­ли­зую­щи­ми. На­при­мер, встре­тив mdns4 в за­пи­си hosts в nsswitch.conf, раз­ре­ши­тель имени хоста вы­полнит за­прос с ис­поль­зо­ванием раз­де­ляе­мой биб­лио­те­ки /lib/libnss_mdns4.so. Ин­тер­фейс для досту­па к этим биб­лио­те­кам стан­дарт­ный, по­это­му раз­ра­бот­чик мо­жет до­ба­вить соб­ст­вен­ный сер­вис.

При до­бав­лении биб­лио­те­ки libnss_xyz он до­бав­ля­ет ис­точник ин­фор­ма­ции xyz. Функ­ции раз­ре­ши­те­ля верхнего уров­ня (и вы­зы­ваю­щие их про­грам­мы) вы­зо­вут его ав­то­ма­ти­че­­ски, ес­ли xyz есть в фай­ле nsswitch.conf. В неко­то­рых ди­ст­ри­бу­ти­вах Linux есть гра­фи­че­­ские ути­ли­ты для ре­дак­ти­ро­вания nsswitch.conf. Ути­ли­та systemconfig-authentication в Fedora по­зво­ля­ет за­дать ис­точник ин­фор­ма­ции об учет­ной за­пи­си поль­зо­ва­те­ля. В Ubuntu для тех же це­лей мож­но восполь­зо­вать­ся скрип­том authclientconfig, хо­тя его основ­ное на­зна­чение – об­лег­чение об­нов­ления nsswitch.conf со сто­ро­ны уста­но­воч­ных скрип­тов па­ке­тов. Пол­ная до­ку­мен­та­ция по nsswitch.conf име­ет­ся на http://www.gnu.org/s/hello/manual/libc/Name-Service-Switch.html.


Рецепты доктора Брауна.

Д-р Крис Браун: Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.

[править] Про­грамм­ный RAID

Для соз­да­ния из­бы­точ­но­сти в хра­ни­ли­ще не обя­за­тель­но тра­тить­ся на до­ро­гие ап­па­рат­ные ре­ше­ния. Ваш сер­вер под­дер­жит про­грамм­ный RAID.


Дис­ки жи­вут не веч­но. Из­го­то­ви­те­ли дис­ков час­то на­зы­ва­ют среднее вре­мя на­ра­бот­ки на от­каз [MTBF – Mean Time Between Failure] в мил­ли­он ча­сов (это 114 лет). Это со­от­вет­ст­ву­ет го­до­вой ин­тен­сив­но­сти от­ка­зов [AFR – annual failure rate] в 1 % – но спра­вед­ли­во толь­ко для но­вых дис­ков. Ста­тья Google Failure Trends in a Large Disk Drive Population [Тен­ден­ции от­ка­зов в боль­ших же­ст­ких дис­ках] ри­су­ет дру­гую кар­ти­ну. В ней при­во­дят­ся зна­чения AFR от 2 до 6 %, в за­ви­си­мо­сти от воз­рас­та дис­ка. (Ста­тью мож­но про­честь на http://research.google.com/archive/disk_failures.pdf). По мо­им рас­че­там, ес­ли ве­ро­ят­ность от­ка­за дис­ка в этом го­ду со­став­ля­ет, ска­жем, 4 %, а в хранили­ще 10 дис­ков, то ве­ро­ят­ность про­жить год без неис­прав­но­стей со­став­ля­ет все­го 66 %. О циф­рах мож­но спо­рить, но факт оста­ет­ся фак­том: дис­ки вы­хо­дят из строя.

RAID (Redundant Array of Individual Disks – из­бы­точ­ный мас­сив от­дель­ных дис­ков) по­зво­ля­ет соз­да­вать хранили­ща, спо­соб­ные про­ти­во­сто­ять неис­прав­но­стям дис­ков. Су­ще­ст­ву­ет мно­же­ст­во ап­па­рат­ных дис­ко­вых кон­трол­ле­ров RAID, но в Linux так­же мож­но соз­да­вать про­грамм­ные мас­си­вы RAID с по­мо­щью стан­дарт­ных уст­ройств. Пре­ж­де чем уг­лу­бить­ся в де­та­ли, по­го­во­рим о кон­цеп­ции «блоч­но­го уст­рой­ст­ва» в Linux. Блоч­ное уст­рой­ст­во – уст­рой­ст­во хранения, к ко­то­ро­му мож­но ад­ре­со­вать­ся, а так­же счи­ты­вать и за­пи­сы­вать дан­ные по­блоч­но. Оче­вид­ный при­мер – же­ст­кий диск, но, как мы уви­дим, есть и дру­гие. Блоч­ные уст­рой­ст­ва в Linux важ­ны, по­то­му что на них стро­ит­ся фай­ло­вая сис­те­ма.

LXF54.braun5.png


Глу­бо­ко в недрах яд­ра Linux на­хо­дит­ся «со­поста­ви­тель уст­ройств» [device mapper] – сис­те­ма, спо­соб­ная соз­да­вать блоч­ные уст­рой­ст­ва «по­верх» дру­гих блоч­ных уст­ройств. Она ис­поль­зу­ет­ся для соз­дания про­грамм­ных уст­ройств RAID (на­ша те­ма), а так­же для ло­ги­че­­ских то­мов и за­шиф­ро­ван­ных раз­де­лов. Су­ще­ст­ву­ет несколь­ко спо­со­бов на­строй­ки уст­ройств RAID. Рас­смот­рим три из них.

[править] Хо­ро­шо, и как это ра­бо­та­ет в Linux?

Linux под­дер­жи­ва­ет RAID на уровне со­поста­ви­те­ля уст­ройств внут­ри яд­ра, а на­страи­ва­ет­ся RAID ути­ли­той команд­ной стро­ки mdadm, ко­то­рая по­зво­ля­ет соз­да­вать, на­ра­щи­вать и управ­лять уст­рой­ст­ва­ми про­грамм­но­го RAID. У этой ути­ли­ты мас­са па­ра­мет­ров, и внима­тель­ное чтение ее man-страницы мо­жет за­про­сто за­нять це­лый ве­чер. В ва­шей сис­те­ме она мо­жет быть не уста­нов­ле­на по умол­чанию. На­при­мер, в Ubuntu потребуется па­кет mdadm:

 $ sudo apt-get install mdadm 

Рас­смот­рим при­мер. Пусть у вас че­ты­ре дис­ка (sdb, sdc, sdd и sde), и вы хо­ти­те сфор­ми­ро­вать из них мас­сив RAID 5. Сле­дую­щая ко­ман­да сде­ла­ет всю ра­бо­ту:

# mdadm -C /dev/md0 -n4 /dev/sdb /dev/sdc /dev/sdd /dev/sde -l5


В слу­чае RAID 0 дис­ко­вое про­стран­ст­во по су­ти де­ла рас­про­стра­ня­ет­ся на несколь­ко дис­ков, для ими­та­ции од­но­го боль­шо­го дис­ка. Это мож­но сде­лать, сце­пив дис­ки (дан­ные за­пи­сы­ва­ют­ся на пер­вый диск, за­тем подряд на вто­рой, по­сле то­го как пер­вый за­полнит­ся). При этом дис­ки не обя­за­ны быть од­но­го и то­го же объема. Мож­но так­же че­ре­до­вать дис­ки (по­сле­до­ва­тель­ные фраг­мен­ты дан­ных за­пи­сы­ва­ют­ся на пер­вый диск, за­тем на вто­рой, за­тем на тре­тий). Из­бы­точ­но­сти при лю­бом раз­ме­щении дис­ков не возника­ет. Ес­ли один из дис­ков вы­хо­дит из строя, вы те­ряе­те весь RAID.

RAID 1, так­же из­вест­ный как «зер­ка­ли­ро­вание» – од­на из про­стей­ших кон­фи­гу­ра­ций RAID. В этом слу­чае ис­поль­зу­ют­ся два дис­ка, и дан­ные про­сто дуб­ли­ру­ют­ся на обо­их. Дис­ки долж­ны быть оди­на­ко­во­го объема. Ес­ли один из дис­ков вый­дет из строя, RAID про­дол­жит ра­бо­ту на остав­шем­ся дис­ке. По­сле за­ме­ны неис­прав­но­го дис­ка дан­ные про­сто сно­ва дуб­ли­ру­ют­ся на него с остав­ше­го­ся ра­бо­че­го дис­ка. Это про­сто и эф­фек­тив­но – недоста­ток в том, что вам нуж­но вдвое боль­ше фи­зи­че­­ско­­го мес­та на дис­ке: с па­рой дис­ков по 500 ГБ вы по­лу­чи­те все­го 500 ГБ для хранения дан­ных.


LXF154.sysadmin.raid w opt.jpeg
RAID 5

Од­на из наи­бо­лее час­то ис­поль­зуе­мых кон­фи­гу­ра­ций. Как и в RAID 0, в ней ис­поль­зу­ет­ся че­ре­до­вание, но здесь по­яв­ля­ет­ся блок чет­но­сти, ко­то­рый по­зво­ля­ет восста­но­вить со­дер­жи­мое раз­де­ла в слу­чае вы­хо­да из строя од­но­го из дис­ков. Бло­ки чет­но­сти рас­пре­де­ля­ют­ся по всем дис­кам. Это сложнее пред­ста­вить в го­ло­ве, по­это­му я на­ри­со­вал неболь­шую кар­тин­ку. Я не бу­ду про­из­во­дить рас­че­ты, но по­верь­те: ес­ли один диск вый­дет из строя, его со­дер­жи­мое мож­но бу­дет восста­но­вить с остав­ших­ся дис­ков. Для RAID 5 тре­бу­ет­ся не менее трех дис­ков, но та­кой мас­сив да­ет хо­ро­шее со­че­тание из­бы­точ­но­сти (он мо­жет вы­дер­жать по­те­рю од­но­го дис­ка) и эф­фек­тив­но­го ис­поль­зо­вания про­стран­ст­ва. На­при­мер, ес­ли у вас мас­сив из пя­ти дис­ков, толь­ко 20 % про­стран­ст­ва «тра­тит­ся» на хранение из­бы­точ­ной ин­фор­ма­ции.

Те­перь на этом уст­рой­ст­ве RAID мож­но соз­дать фай­ло­вую сис­те­му точ­но так же, как на обыч­ном раз­де­ле дис­ка или на лю­бом дру­гом блоч­ном уст­рой­ст­ве:

# mke2fs -j /dev/md0

За­тем ее мож­но смон­ти­ро­вать или до­ба­вить в /etc/fstab обыч­ным об­ра­зом.

[править] Де­ла­ем из­менения по­сто­ян­ны­ми

Уст­рой­ст­во RAID /dev/md0, ко­то­рое мы толь­ко что соз­да­ли, не бу­дет по­втор­но соз­да­но по­сле пе­ре­за­груз­ки сис­те­мы, ес­ли не до­ба­вить со­от­вет­ст­вую­щую стро­ку в файл /etc/mdadm.conf. Мож­но сде­лать так, что­бы mdadm до­ба­ви­ла ее за нас – при­мер­но так:

# mdadm --examine --scan >> /etc/mdadm.conf

Или мож­но вруч­ную пе­ре­соз­дать уст­рой­ст­во RAID:

# mdadm --assemble --scan

[править] Нет но­во­стей — это хо­ро­шая но­вость

Итак, ваш мас­сив RAID жуж­жит се­бе по­ма­лень­ку, но од­на­ж­ды ут­ром один из дис­ков вы­хо­дит из строя. К сча­стью, уст­рой­ст­во RAID про­дол­жит функ­циониро­вать, а сер­вер про­дол­жит ра­бо­тать: его един­ст­вен­ная при­чи­на жить – оста­вать­ся ра­бо­чим в подобных об­стоя­тель­ст­вах. Но те­перь у вас нет из­бы­точ­но­сти, и хо­тя ве­ро­ят­ность, что в тот же день вый­дет из строя дру­гой диск, ма­ла (с той же ве­ро­ят­но­стью мож­но по­лу­чить вто­рой про­кол по до­ро­ге в га­раж на про­ко­ло­той шине), вы долж­ны уз­нать о неис­прав­но­сти, что­бы поскорее за­менить по­вре­ж­ден­ный диск. Для это­го мож­но восполь­зо­вать­ся mdadm в ре­жи­ме монито­рин­га. В мо­ей CentOS 5 для это­го ис­поль­зу­ет­ся сер­вис mdmonitor, за­пускае­мый при стар­те сис­те­мы. Его мож­но за­пустить, ско­ман­довав

# service mdmonitor start

А на­стро­ить его за­пуск при стар­те сис­те­мы мож­но ко­ман­дой

# chkconfig mdmonitor on

В ре­жи­ме монито­рин­га mdadm бу­дет на­блю­дать за со­стоянием уст­ройств RAID и соз­да­вать со­бы­тия, ес­ли про­изой­дет что-то важ­ное. Со­бы­тия вклю­ча­ют DeviceDisappeared, RebuildStarted, RebuildFinished, Fail и FailSpare. Не­ко­то­рые из этих со­бы­тий (ка­саю­щие­ся пло­хих но­во­стей) при­ве­дут к том, что на ад­рес на­зна­чения, ука­зан­ный в mdadm.conf, бу­дет от­прав­ле­но пись­мо. Вам по­на­до­бит­ся нечто вро­де это­го:

MAILADDR chris@localhost

Ес­ли для отслеживания состояния системы вы поль­зуе­тесь ути­ли­той уров­ня пред­при­ятия вро­де Nagios, к ней есть модуль рас­ши­рения для от­сле­жи­вания со­стояния уст­ройств RAID. На­вер­ное, не помешает про­ве­рить пра­виль­ность ре­ак­ции RAID на от­каз дис­ка еще до­ это­го от­ка­за. От­каз дис­ка лег­ко ими­ти­ру­ет­ся следующим образом:

# mdadm /dev/md0 --fail /dev/sdc

mdadm: set /dev/sdc faulty in /dev/md0

Вы­вод ко­ман­ды mdadm -D те­перь да­ет такие ре­зуль­та­ты:

Number Major Minor RaidDevice State

0 8 16 0 active sync /dev/sdb

1 0 0 1 removed

2 8 48 2 active sync /dev/sdd

3 8 64 3 active sync /dev/sde

4 8 32 - faulty spare /dev/sdc 

Ес­ли ваш бюд­жет по­зво­ля­ет вам при­об­ре­сти лишний диск, мо­же­те применить его для «го­ря­чей за­ме­ны», восполь­зо­вав­шись оп­ци­ей --spare-devices ко­ман­ды mdadm. Это ку­пит вам ощу­щение спокойствия. Дис­ки «го­ря­чей за­ме­ны» так­же мож­но со­вме­ст­но ис­поль­зо­вать в несколь­ких уст­рой­ст­вах RAID, по­мес­тив их в од­ну раз­де­ляе­мую груп­пу. Под­робнее о про­грамм­ном RAID в Linux расскажут man-страницы mdadm и mdadm.conf; или зай­ди­те на raid.wiki.kernel.org.

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