Улучшение ввода-вывода с помощью FlashCache

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

В связи с этим у меня есть следующие вопросы:

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

К сожалению, у меня нет доступа к тестовой системе, поэтому могу ли я установить flashcacheна работающий сервер без размонтирования дисков? Я нашел большой учебник здесь , который я бы использовать.

Flashcache для тех, кто не видел его раньше, - это метод расширения блочного кэша Linux с помощью SSD-накопителя. Это дешевле, чем запуск сервера с половиной ТБ ОЗУ только для кэширования.

Будет ли это даже работать?

Должно. Блок-кеш Linux работает путем кэширования блоков , к которым обращаются , а не файлов . До тех пор, пока вы не предоставляете машинам KVM прямой доступ к блочным устройствам (нет), блочный кэш Linux будет в игре. Тем не менее, если вы будете давать KVM машинам прямому доступ блок-устройство ответа есть менее ясно.

Если вы используете виртуальные диски с файловой поддержкой, это определенно будет работать.

Если вы используете виртуальные диски с LV-поддержкой, я не знаю.

Насколько я могу ожидать повышения производительности?

Это то, что мы не можем ответить. Это зависит от множества вещей. В абстрактном виде вы получите лучшую производительность, если размер вашего SSD больше, чем у активного набора блоков. Если вы получите идеальное кэширование, ваша производительность будет аналогична работе всей системы на SSD. Что вы будете эффективно делать.

Насколько большим должен быть SSD?

Определить, какой именно размер вам нужен, мы не можем. Очевидно, что чем больше, тем лучше, но найти точное соотношение между кеш-SSD и основным хранилищем - дело непростое.

Это усложняет запись, устанавливаемую для немедленной очистки, такой как определенные операции файловой системы и некоторые конфигурации базы данных. Эти записи будут кэшироваться только на короткое время, а их производительность не будет зависеть от наличия или отсутствия flashcache.

Что произойдет, если SSD умрет?

То же самое происходит, когда вы указываете Linux на drop-кэширование, но с изюминкой. При использовании drop-кешей любые незаполненные записи, находящиеся в кеше блоков, будут сброшены на диск. Что происходит, когда исчезает SSD, зависит от режима кэширования :

Запись : все записи записываются в кэш и основное хранилище параллельно, поэтому вероятность внезапной потери SSD, приводящей к ошибкам на виртуальных машинах, очень мала.

Writearound : Все записи записываются в основное хранилище и кэшируются только при чтении. Нет вероятности ошибок в виртуальных машинах.

Обратная запись : Все записи сначала отправляются в кэш, и записываются в основное хранилище в фоновом режиме. Скорее всего, это приведет к ошибкам в ваших виртуальных машинах в случае отказа SSD, и я бы не стал использовать этот режим в работе.

Насколько быстрее будет обратная запись по сравнению с записью и записью?

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

Кроме того, обратная запись является плохой политикой для того, что вы делаете, поэтому не используйте ее.

Да, он будет работать нормально, если вы используете правильные блочные устройства. И тут есть хитрость.

Когда LVM сканирует PV, он должен видеть раздел как через сам жесткий диск, так и через «виртуальное» устройство flashcache.

Одним из очевидных симптомов должно быть то, что инструменты LVM жалуются на дубликаты PV.

Исправление, чтобы избежать этих предупреждений и, что более важно, убедиться, что устройство flashcache используется LVM2, заключается в том, чтобы адаптировать фильтр в /etc/lvm/lvm.conf .

LVM.CONF(5)Страница руководства будет объяснить это лучше , чем у меня, но я оставлю вам пример, если все физические тома подкреплены 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 с этим набором приложений.