У меня есть сервер с 2 жесткими дисками (2x 1 ТБ), работающий в RAID 1 (SW-RAID). Я хочу улучшить производительность ввода-вывода с помощью flashcache. На нем запущены виртуальные машины KVM, использующие LVM.
В связи с этим у меня есть следующие вопросы:
flashcache работает для блочных устройств, однако все это виртуальные машины с собственной настройкой.flashcache получить файлы с традиционного жесткого диска, а я мог бы просто заменить SSD?writeback быть по сравнению с writethrough и writearound?К сожалению, у меня нет доступа к тестовой системе, поэтому я могу установить flashcache на живом сервере без размонтирования дисков? Я нашел отличный учебник Вот который я бы использовал.
Flashcache, для тех, кто раньше этого не видел, - это метод расширения блочного кеша Linux с помощью SSD-накопителя. Это дешевле, чем запускать сервер с половиной ТБ ОЗУ только для кеширования.
Это вообще сработает?
Должно. Блочный кеш Linux работает путем кеширования, к блокине файлы. Пока вы не предоставляете KVM-машинам прямой доступ к блочным устройствам (вы не делаете этого), кэш блоков Linux будет в игре. Однако если вы являются Предоставляя KVM-машинам прямой доступ к блочным устройствам, ответ менее ясен.
Если вы используете виртуальные диски с файловой поддержкой, это определенно сработает.
Если вы используете виртуальные диски с поддержкой LV, я не знаю.
Насколько я могу ожидать увеличения производительности?
На это мы не можем ответить. Это зависит от множества вещей. Говоря абстрактно, вы получите лучшую производительность, если размер вашего SSD будет больше, чем активный набор блоков. Если вы получите идеальное кэширование, ваша производительность будет аналогична работе всей вашей системы на SSD. Что вы фактически и будете делать.
Насколько большим должен быть SSD?
Мы не можем помочь определить точный размер, который вам нужен. Очевидно, что чем больше, тем лучше, но найти точное соотношение между SSD-кешем и основным хранилищем не так-то просто.
Это усложняет запись, настроенная на немедленную очистку, например, определенные операции файловой системы и некоторые конфигурации базы данных. Эти записи будут кэшироваться только на короткое время, и на их производительность никоим образом не повлияет наличие или отсутствие flashcache.
Что будет, если SSD умрет?
То же самое происходит, когда вы приказываете Linux удалять кеши, но с некоторыми особенностями. При использовании drop-cache любые незаброшенные записи, которые находятся в блочном кэше, будут сброшены на диск. Что произойдет, когда SSD исчезнет, зависит от режим кэширования:
Написание: Все записи записываются в кэш и основное хранилище параллельно, поэтому вероятность внезапной потери SSD, вызывающей ошибки на виртуальных машинах, очень мала.
Обход: Все записи записываются в основное хранилище и кэшируются только при чтении. Никаких ошибок в виртуальных машинах.
Обратная запись: Все записи сначала идут в кэш и записываются в основное хранилище в фоновом режиме. С наибольшей вероятностью возникнут ошибки в ваших виртуальных машинах в случае отказа SSD, и я бы не стал использовать этот режим в производстве.
Насколько быстрее будет обратная запись по сравнению с записью и обходом записи?
Зависит от того, сколько вы пишете. Если ваши записи периодически переполняют ваше основное хранилище, повышение производительности может быть довольно значительным. Если вы в основном читаете и пишете, то вряд ли заметите улучшения.
Кроме того, обратная запись - это плохая политика для того, что вы делаете, поэтому не используйте ее.
Да, он будет работать нормально, если вы используете правильные блочные устройства. И есть хитрость.
Когда LVM просматривает PV, он должен видеть раздел через сам жесткий диск, а также через «виртуальное» устройство flashcache.
Одним из очевидных симптомов должно быть то, что инструменты LVM жалуются на дублирование PV.
Исправление, позволяющее избежать этих предупреждений и, что более важно, убедиться, что устройство flashcache используется LVM2, заключается в адаптации фильтра в /etc/lvm/lvm.conf.
В LVM.CONF(5) manpage объяснит это лучше, чем я, но я оставлю вам пример, если все физические тома поддерживаются flashcache:
filter = [ "a/.*dm.*/" ]
Также есть уровень от создателя lessfs. Это позволит вам создавать гибридные устройства между SSD и HDD. Производительность уровня, похоже, превосходит Flashcache.
http://www.lessfs.com/wordpress/
http://www.lessfs.com/wordpress/?p=776
// христианин
Некоторые приложения открывают файлы без буферизации.
http://man7.org/linux/man-pages/man2/open.2.html
O_DIRECT (начиная с Linux 2.4.10) Попытайтесь свести к минимуму эффекты кеширования ввода-вывода в этот файл и из него. Как правило, это снижает производительность, но это полезно в особых ситуациях, например, когда приложения выполняют собственное кэширование. Файловый ввод-вывод выполняется непосредственно в / из буферов пользовательского пространства. Флаг O_DIRECT сам по себе пытается передать данные синхронно, но не дает гарантий флага O_SYNC, что данные и необходимые метаданные передаются. Чтобы гарантировать синхронный ввод-вывод, необходимо использовать O_SYNC в дополнение к O_DIRECT. См. ПРИМЕЧАНИЯ ниже для дальнейшего обсуждения.
Например, это очень распространено для баз данных. Поэтому дважды проверьте, работает ли flashcache с этим набором приложений.