Поліпшення IO за допомогою FlashCache


14

У мене є сервер з 2 HDD (2x 1 ТБ), працює в RAID 1 (SW-RAID). Я хочу покращити продуктивність IO, використовуючи flashcache. На ньому запущені віртуальні машини KVM, використовуючи LVM.

З цього приводу у мене є такі питання:

  • Це навіть спрацює? flashcacheпрацює для блокових пристроїв, однак це все віртуальні машини з власною установкою.
  • На скільки я б очікував підвищення продуктивності? Більшість віртуальних машин управляють веб-сайтами та деякими хост-іграми.
  • Наскільки великим повинен бути SSD? Чи матиме більший показник SSD, оскільки він може кешувати більше файлів?
  • Що станеться, якщо SSD помер? Як flashcacheотримати файли з традиційного жорсткого диска, і я міг би просто замінити SSD?
  • Наскільки швидше б writebackбути в порівнянні з writethroughі writearound?

На жаль, у мене немає доступу до тестової системи, тому я можу встановити flashcacheна живий сервер без демонтажу дисків? Я знайшов великий підручник тут , який я б використовувати.


Я думаю, вам сподобається більш стабільна продуктивність, якби ви могли використовувати SSD в якості основних дисків.
ewwhite

Немає доступу до тестової системи? Все, що вам потрібно, це робоча станція з жорстким диском, SSD і віртуальна машина з двома віртуальними дисками (по одному розміщено на кожному пристрої). Виробничі системи не використовуються як навчальні лабораторії.
Skyhawk

Посилання мертва в тому підручнику, який ви згадали. У будь-якому іншому місці я міг знайти цю інформацію?
Таелі

Відповіді:


18

Flashcache, для тих, хто цього раніше не бачив, - це метод розширення блокового кешу Linux з SSD-накопичувачем. Це дешевше, ніж запуск сервера з половиною TB оперативної пам’яті просто для кешування.

Це навіть спрацює?

Це повинно. Блок-кеш Linux працює, кешуючи блоки доступу , а не файли . Поки ви не надаєте машинам KVM прямий доступ до блокових пристроїв (ви ні), Linux Bloche Cache буде працювати. Тим НЕ менше, якщо ви будете давати KVM машинам прямому доступ блок-пристрій відповіді є менш ясно.

Якщо ви використовуєте захищені файлами віртуальні диски, вони обов'язково спрацюють.

Якщо ви використовуєте підтримувані LV віртуальні диски, я не знаю.

На скільки я б очікував підвищення продуктивності?

Це те, на що ми не можемо відповісти. Це залежить від різноманітності речей. В рефераті ви отримаєте найкращі показники розміру вашого SSD, щоб він був більшим, ніж активний набір блоків. Якщо ви отримаєте ідеальне кешування, продуктивність буде схожа на запуск всієї вашої системи на SSD. Що ви ефективно робите.

Наскільки великим повинен бути SSD?

Виявити потрібний вам розмір - це те, з чим ми не можемо допомогти. Очевидно, що краще, але знайти точне співвідношення між кешем-SSD та первинним сховищем - справа не проста.

Ускладнення цього полягає у тому, що записи записуються негайно, такі як певні операції з файловою системою та деякі конфігурації бази даних. Ці записи будуть лише на короткий час кешовані, і на їх ефективність жодним чином не впливатиме наявність чи відсутність флеш-кешу.

Що станеться, якщо SSD помер?

Те саме відбувається, коли ви говорите Linux, щоб він випускав кеші, але з поворотом. За допомогою кеш-пам’яті будь-які незаписані записи, що знаходяться в кеш-блоці, потраплять на диск. Що відбувається, коли SSD зникає, залежить від режиму кешування :

Writethrough : Всі записи записуються в кеш і первинне зберігання паралельно, так що шанси раптової втрати SSD викликають помилки на віртуальних машинах дуже мало.

Коло запису : усі записи записуються в первинний сховище і зберігаються в кешовому режимі лише при читанні. Немає шансів помилок у віртуальному комп'ютері.

Зворотний запис : Усі записи спочатку переходять у кеш-пам'ять і записуються в основний сховище у фоновому режимі. Найімовірніше, що призведе до помилок у ваших відеомагнітофонах, якщо SSD не вдасться, і я б не використовував цей режим у виробництві.

Наскільки швидше буде зворотне списання порівняно з написанням та обчисленням?

Залежить від того, скільки ви пишете. Якщо ваші записи періодично насичують ваше основне сховище, підвищення продуктивності може бути досить значним. Якщо ви здебільшого читаєте з деяким записом, ви, швидше за все, не помітите поліпшень.

Крім того, списання є поганою політикою для того, що ви робите, тому не використовуйте.


1
Привіт sysadmin, дякую за всебічну відповідь. Я не буду користуватися, writebackоскільки це може зіпсувати все без деяких BBU. Я взагалі не буду використовувати кешування SSD, а лише звичайний SSD. Знову дякую!
Девальватор

4

Так, це буде добре, доки ви не користуєтеся правильними блоковими пристроями. І є хитрість.

Коли LVM сканує PV-файли, він повинен бачити розділ через власне жорсткий диск, а також через «віртуальний» пристрій flashcache.

Одним із очевидних симптомів має бути те, що інструменти LVM скаржаться на повторювані ПВ.

Виправлення, щоб уникнути цих попереджень, і що ще важливіше, переконайтесь, що пристрій Flashcache використовується LVM2, полягає в адаптації фільтра /etc/lvm/lvm.conf.

Сторінка LVM.CONF(5)роз'яснить це краще, ніж я, але я залишу вам приклад, якщо всі фізичні обсяги підкріплені флеш-кешем:

filter = [ "a/.*dm.*/" ]


1

Деякі програми відкривають файли небуферним способом.

http://man7.org/linux/man-pages/man2/open.2.html

O_DIRECT (З Linux 2.4.10) Спробуйте мінімізувати ефекти кеш-пам'яті вводу-виводу до цього та з цього файлу. Загалом це погіршить продуктивність, але це корисно в особливих ситуаціях, наприклад, коли програми роблять кешування самостійно. Введення / виведення файлів виконується безпосередньо в / з буферів простору користувача. Прапор O_DIRECT самостійно докладає зусиль для передачі даних синхронно, але не дає гарантій прапора O_SYNC щодо передачі даних та необхідних метаданих. Для гарантування синхронного вводу-виводу, крім O_DIRECT, слід використовувати O_SYNC. Див. ПРИМІТКИ нижче для подальшого обговорення.

Наприклад, це дуже часто для баз даних. Тому перевірте, чи працює флеш-кеш із цим набором програм.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.