RAID на практика: разширяване на масив от 8 на 24 TB и смяна на повреден диск без загуба на данни

Накратко

Разказваме ви за два отделни случая от практиката ни с RAID масиви:

1. Разширяване на RAID масив при голяма счетоводно-одиторска компания: увеличихме полезното място на сървъра от 8 на 24 TB с миграция от RAID1 към RAID5. Отне 1-2 работни дни, сървърът работеше 99% от времето и не загубихме нито един файл. Клиентът имаше и отделен архив на данните, но не се наложи да го използваме.
2. Смяна на повреден диск в RAID при друг клиент: мониторингът засече проблема навреме и дискът беше сменен планирано - сървърът работеше 99% от времето и нямаше загубени данни.

Случай 1: разширяване на RAID масив от 8 на 24 TB

Ситуацията

Компанията пази документите и данните на екипа си на Linux сървър със софтуерен RAID1 (mdadm). RAID1 държи пълно копие на данните на два диска - много надеждно, но полезното място е колкото един диск. С растежа на фирмата 8 TB вече не стигаха - нещо често, защото файловете растат по-бързо, отколкото изглежда при избора на сървър.

Обичайните варианти бяха нов сървър или изграждане на хранилището наново и връщане на данните от архив. И двата варианта са скъпи, бавни и спират работата на екипа.

Какво искаше клиентът

• повече полезно място на същия сървър;
• защита срещу повреда на диск по време на миграцията и след нея;
• без изграждане на масива наново и без връщане на данни от архив;
• възможно най-малко смущения в работата.

Как го направихме

1. Проверка на масива. Прегледахме конфигурацията на mdadm и състоянието на дисковете. Миграция започваме само при напълно здрав и синхронизиран масив. Клиентът имаше и отделен, редовно обновяван архив на данните - важна застраховка при всяка промяна по масива.
2. Подготовка на новите дискове. Проверихме, че обемът им стига за съществуващите данни и за новата конфигурация.
3. Миграция от RAID1 към RAID5 на същия масив. С mdadm преобразувахме съществуващия масив, без да прехвърляме данните на друга система.
4. Монтаж и добавяне на дисковете. Монтирахме новите дискове - за това сървърът спря само за няколко минути. След това ги добавихме в масива и той преразпредели данните върху всички тях. Следяхме процеса през цялото време, а сървърът работеше и екипът имаше достъп до файловете си.
5. Разширяване на файловата система. След като синхронизацията завърши, разширихме масива, дяловете и файловата система, така че новото място да е достъпно. Накрая обновихме настройките за стартиране на сървъра.

Резултатът

• Полезно място от 8 на 24 TB - три пъти повече, без нов сървър.
• Миграцията завърши за 1-2 работни дни.
• Сървърът работеше 99% от времето на операцията - спря само за няколко минути при монтажа на новите дискове.
• 0 загубени данни, а настройките и програмите останаха непроменени.
• Защита срещу повреда на един диск през цялото време.
• Отделният архив на данните остана само застраховка - не се наложи да го използваме.

Случай 2: планирана смяна на повреден диск в RAID

Ситуацията

При друг наш клиент Linux сървърът със софтуерен RAID (mdadm) имаше два физически диска и няколко RAID1 масива върху дялове на тези два диска. При такава схема повредата на един диск засяга всички масиви наведнъж.

Как мониторингът засече проблема

Нашият мониторинг 24/7 сигнализира за проблем с единия диск, докато масивите още работеха с другия и преди клиентът да усети каквото и да е. Наш администратор прегледа сървъра и потвърди повредата по състоянието на масивите ([U_] вместо [UU]) и по системните журнали. След това установи серийния номер на дефектния диск, за да сме сигурни кой точно диск сменяме. Именно ранното известие позволи смяната да мине планирано.

Как го направихме

1. Отбелязахме и извадихме дяловете на повредения диск от всеки засегнат масив.
2. Занесохме на място подходящ диск с поне същия обем (дори малко по-малък не позволява дяловете да се пресъздадат) и го сменихме. Сървърът спря само за няколко минути, колкото да монтираме новия диск.
3. Създадохме на новия диск същите дялове като на здравия и ги върнахме в масивите.
4. Следяхме възстановяването, докато всички масиви се синхронизираха напълно.

Резултатът

• Сървърът работеше 99% от времето на операцията - спря само за няколко минути при монтажа на новия диск.
• 0 загубени данни, без връщане на данни от архив.
• Мониторингът засече проблема, преди клиентът да усети нещо.
• Всички засегнати RAID1 масиви са отново напълно синхронизирани.

Мониторингът 24/7 е включен във всички наши планове за поддръжка.

Какво показват двата случая

• Повече място не значи непременно нов сървър. Съществуващият софтуерен RAID може да се разшири на същия сървър, ако е здрав и операцията е добре планирана.
• Повреден диск в RAID не значи дълъг престой. Когато мониторингът засече проблема навреме, дискът се сменя планирано, със спиране от няколко минути. А при сървър от професионален клас с хардуерен RAID и дискове с гореща смяна (hot-swap) дискът може да се смени и без никакво спиране.
• Добрата подготовка е половината работа. Преди всяка промяна проверяваме, че масивът е здрав, дисковете са подходящи и има актуален архив. Така рутинната операция не се превръща в проблем. А за по-тежките случаи всяка фирма има нужда и от план за възстановяване при срив.

Често задавани въпроси

Може ли RAID1 да стане RAID5 без загуба на данни?

Да. С mdadm софтуерният RAID1 може да се преобразува в RAID5 на същия сървър, като данните остават на масива. Условията са масивът да е здрав и синхронизиран, новите дискове да са подходящи и да има актуален архив на данните.

Колко време отнема разширяването на RAID масив?

Зависи от обема и от дисковете. В първия случай разширяването от 8 на 24 TB отне 1-2 работни дни, а сървърът работеше 99% от времето - спря само за няколко минути при монтажа на новите дискове.

Как се разбира, че диск в RAID масив се поврежда?

Мониторингът следи състоянието на масивите и дисковете и сигнализира веднага. В Linux здрав масив от два диска се показва като [UU], а масив с отпаднал диск - като [U_].

Трябва ли новият диск да е същият модел?

Не е задължително, но трябва да е с поне същия обем. Дори малко по-малък диск не позволява дяловете да се пресъздадат.

Може ли смяната на диск да мине без никакво спиране на сървъра?

Да. При сървър от професионален клас с хардуерен RAID контролер и дискове с гореща смяна (hot-swap) повреденият диск се изважда и сменя, докато сървърът работи - престоят е нула. В двата описани случая сървърите нямаха хардуерен RAID и дискове с гореща смяна, затова защитата им е изградена със софтуерен RAID чрез mdadm - стандартният инструмент в Linux, който дава надеждна защита на данните и без скъп RAID контролер. Цената за това беше само няколко минути спиране при монтажа на дисковете. Когато планираме нов сървър или подмяна, съветваме клиентите кога такъв хардуер си струва.

Заключение

И в двата случая не загубихме нито един файл. В първия разширихме масива от 8 на 24 TB на същия сървър. Във втория сменихме повредения диск само с няколко минути планирано спиране, защото мониторингът го засече навреме. Такива операции са част от нашата поддръжка на сървъри. Вижте и как спасихме данните от дефектиращ NVMe SSD при друг клиент от същия сектор.

Ако сървърът на фирмата ви наближава лимита си или работи с намалена защита, нека поговорим за вашите нужди и ще ви предложим най-доброто решение и цена.