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

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

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

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

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

Источник

4 ответа

Решение

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

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

Должно. Блок-кеш Linux работает путем кэширования блоков, к которым обращаются, а не файлов. Пока вы не предоставляете KVM-машинам прямой доступ к блочным устройствам (вы этого не делаете), Linux Block Cache будет в игре. Однако, если вы предоставляете машинам 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) 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_DIRECT необходимо использовать O_SYNC. Смотрите примечания ниже для дальнейшего обсуждения.

Например, это очень распространено для баз данных. Поэтому дважды проверьте, работает ли flashcache с этим набором приложений.

Источник
Другие вопросы по тегам