База знаний

Linux I / O. Second life.

Рано чи пізно в житті будь адміністратора (або власника сервера) настає момент, коли серверу вже недостатньо поточних ресурсів. Причому, враховуючи сучасні потужності, досить часто вузьким місцем стає дискова підсистема. Сьогодні ми хотіли б розповісти про те, як в певних умовах можна обійтися без істотного апгрейда устаткування при мінімумі затрат.
Дано:

Сервер з Linux (в даному випадку Centos) на борту, апаратний RAID-10, 4 x 500 GB HDD. Кожні 5 хвилин на диски пишеться велика кількість даних, що призводить до дуже істотного уповільнення роботи дискової підсистеми. При цьому пам'яті і процесорних ресурсів більш ніж достатньо, тому оновлювати обладнання не зовсім доцільно.

Задача:

Змусити сервер працювати швидко при мінімумі затрат.

І вихід був знайдений - модуль ядра flashcache, який був розроблений компанією Facebook.

Розроблявся він якраз для подібних випадків коли одні блокові пристрої (великі і повільні) використовуються для зберігання даних, а інші (невеликі та швидкі) - для кешування звернень до перших. Таким чином, flashcache з'єднує воєдино гідності обох видів дискових накопичувачів. На сьогоднішній день найшвидшими є SSD диски, і нами було прийнято рішення про придбання серверного SSD OCZ Deneva 2 60 GB.
Навіть якщо нікуди вставити ще один диск (а саме так і було у нас), вихід теж є: адаптер SATA форм-фактора Slim DVD, наприклад, Espada SS12

Отже, приступимо.

Викачуємо вихідні коди з GitHub, розпаковуємо.

Спочатку потрібно встановити необхідні для зборки пакети і заголовки поточного ядра:

yum -y kernel-headers-$(uname -r) redhat-rpm-config unifdef

Збираємо і встановлюємо модуль:

make
make install

Якщо складання пройшла успішно, завантажуємо модуль:

modprobe flashcache

Тепер приступимо до найцікавішого - створенню нового пристрою, з яким згодом і працюватиме ОС.

Припустимо, ми хочемо використати flashcache для кешування звернень до розділу / home, який є девайсом sda6.

Визначимо UUID диска:

ls -la /dev/disk/by-uuid/1f8a05a7-06ec-4490-a22f-6291cbba9cac -> ../../sda6

Про UUID вже багато сказано. Ми завжди вважаємо за краще використовувати UUID замість порядкових імен дисків в Linux, щоб при заміні одного з HDD не виникло проблем з нумерацією (хіба мало: все можуть помилитися, інженер дата-центру в тому числі)

Створимо новий девайс cachedev:

flashcache_create -v -p thru cachedev \
/dev/sdb /dev/disk/by-uuid/1f8a05a7-06ec-4490-a22f-6291cbba9cac

Розберемо кожен аргумент команди:

1. -p thru - Політика кешируючого пристрої WriteThrough, яку ми використовували при створенні кешируючого пристрої cachedev, вибрана не випадково: нехай вона буде не настільки швидка (ніж WriteBack), зате забезпечує більшу схоронність даних при різноманітних збоях.
2. /dev/sdb - наш SSD диск, який буде використовуватися для кешування
3. /dev/disk/by-uuid/... - UUID диска, операції з яким ми хочемо кешувати
4. -v - verbose (деталізація виведення результатів команди)

Далі правимо / etc / fstab, у нас вийшло так:

UUID=1f8a05a7-06ec-4490-a22f-6291cbba9cac /home ext4 defaults,usrquota,noatime 1 2

(UUID нового пристрою, точка монтування, фалового система, параметри і т.д. - все це у вашому випадку може і буде іншим).

Монтуємо новий девайс:

mount -o rw,remount /home

У підсумку, у нас вийшло так:


Стрілкою на графіку позначений момент перемикання на flashcache device. Як видно, iowait різко впав до нуля. Поточна статистика звернень до кешу:
У нашому випадку (ми багато-багато пишемо на диск, пам'ятаєте?) Кількість write hit досягає 99%.

PS: бонус для тих, хто дочитав статтю до кінця.
В описаних вище умовах, при завантаженні ОС виникне проблема: запис в fstab є, а сам розділ недоступний (на даному етапі модуль flashcache ще не завантажено, і ОС не може знайти блоковий пристрій). Для успішної експлуатації буде потрібно видалити запис про розділ з fstab, і скористатися init-скриптом. На 53 рядку буде потрібно поправити умова з -L на -e, т.к. умовою має виступати наявність файлу, а не директорії.

Помог ли вам данный ответ?

 Распечатать статью