SSD cache device to a hard disk drive using LVM
This article is to show how simple is to use an SSD cache device to a hard disk drive. We also included statistics and graphs for several days of usage in one of our streaming servers.
Our setup:
- 1 SSD disk Samsung 480G. It will be used for writeback cache device!
- 1 Hard disk drive 1T
We included several graphs of this setup from one of our static media servers serving HLS video streaming.
The effectiveness of the cache is around 2-4 times at least!
STEP 1) Install lvm2
Only this step is different on different Linux distributions. We included three of them:
Ubuntu 16+:
CentOS 7:
Gentoo:
STEP 2) Add the two partitions to the lvm2.
We are going to use two partitions, not the whole devices because one of the devices we have installed our Operating system. Here is the disk layout – sda is the SSD and where the Operating system is installed and sdb is the storage device.
Add partitions to the devices and create an LVM Volume Group.
STEP 3) Create cache and cache-pool logical devices.
First create the cache-pool, which consists of the cache device – the fast device like SSD. Then create the cache logical volume – the main device is the slow one like hard disk drive and attach the cache-pool device to it tuning the cache mode. Option “-l 100%FREE” uses the how available free space on the device.
Now format the device with the file system of your choice and add the mount point in the /etc/fstab. We use here ext4:
Mount the device and some more information:
Bonus – lvm cache statistics after several days of use in a video streaming web server
And 24 hours later than the above command (93% storage used). The read effectiveness (read hits/misses) is with ratio 3.717 and the write ratio is 1.675. The dirty blocks grew to 33% and the IO was pretty good.
HLS streaming with a peak of 200Mbits, here are the graphs. You can clearly see the advantage of the caching device. The caching device has 3-5 times more reads than the slow device, which lower the IO pressure against it and the load average is really low.
SCREENSHOT 1) Around 200Mbits at peak and load under 0.75.
SCREENSHOT 2) The fast (cache) device sda6 has 2
5 times the slow device sdb1 (hard disk drive) reads and writes.
SCREENSHOT 3) Around 200Mbits at peak and load under 0.2 in 95%. Almost half of the time the server’s load avarage is below 0.1.
SCREENSHOT 4) The fast (cache) device sda6 has 2
5 times the slow device sdb1 (hard disk drive) reads and writes.
3 thoughts on “SSD cache device to a hard disk drive using LVM”
Hello there, thanks for this great tutorial.
I have tried this on a Raspberry Pi 4 using an SSD partition of c220GB and a physical disk of c7.1TB formatted. I am finding that the read performance tested with hdparm is slower with the cache than of the physical disk alone (300mb/s vs 100mb/s) – is this an unfair/bad test or is my configuration just not a good idea (i.e. the cost of the caching processes is outweighing the benefit)? Is there a better way to compare before and after?
I don’t have this setup anymore to test it. But personally I would’ve tested it with fio not hdparm if I had it. As far as I remember it had a really good effect on a proxy streaming server related to IO and therefore the load of the server. Without the SSD cache, the IO just killed it during peak hours, but in fact, we had 10% top, which is well fitted in the SSD…
You may try to lower the chunk size, too…
Leave a Reply Cancel reply
Find Us
Address
101010010100 Main Street
Earth, EA 101010101010100
E-mail
info@ahelpme.com
Hours (in the TimeBank)
1000000:00:0:00:00 in time…
About This Site
Highly skilled hominins inhabited planet Earth a long long ago! And these hominins have a need to share some knowledge here.
LVM Cache на SSD
Современные ноутбуки, даже многие бюджетные модели поставляются либо с встроенным “маленьким SSD” помимо основного HDD, либо со слотом для установки оного.
Во многих случаях производитель создает RAID где-то глубоко в биосе, который объединяет между собой быстрый твердотельный диск и обычный HDD. Но вот например на моём ноутбуке система просто видела два диска, так что “возможны варианты”.
В принципе, идея не нова и “на поток” эту технологию поставила Apple с их Fusion Drive, который был успешно повторен энтузиастами. Правда, особого развития, на мой взгляд, технология не получила, да и “новые инновационные ноутбуки” с двумя дисками частенько оказываются в сервисе с диагнозом “поломка жесткого диска”, но мы-то знаем, что этот самый супер-raid тупо развалился из-за кончины SSD.
Особо упоротые, правда пытаются такое чинить…
Но это их личное горе.
Короче, к чему это всё. К тому, что данную инновацию в Линуксе можно и нужно заставить работать на себя, а именно — установить этот гребаный пингвинарий на LVM-диск и прикрутить к нему кэш!
Если у кого-то в системе 2 диска, можно сразу читать, как это работает. Для остальных — решительно лезьте в биос и отключайте этот проклятый RAID. Как — не имею понятия, это зависит от биоса вашего ноутбука, прямоты рук и фазы луны. Будем надеяться, что у вас всё получится.
Предположим, система у нас уже благополучно установлена на LVM-диск, команда mount выдает следующее:
/dev/mapper/vg0-root on / type btrfs (rw,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,inode_cache,subvolid=5,subvol=/)
Том, который используется у меня для файловой системы именуется “root” и расположен в группе томов “vg0”. В принципе, почти все современные дистрибутивы в “инсталляторе” умеют делать такое (устанавливать систему на LVM), а некоторые делают это вообще по дефолту.
Сам SSD видится в моей системе вторым диском (/dev/sdb).
Disk /dev/sdb: 29.8 GiB, 32017047552 bytes, 62533296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5EFAE4B4-A884-40B6-8723-5DECC274F9A3
Device Start End Sectors Size Type /dev/sdb1 2048 62533262 62531215 29.8G Linux LVM
Потребуется единственная партиция, размером на весь диск. Её нужно пометить типом “Linux LVM”.
Дальше 5 команд с комментариями, которые и создадут нам кэш.
- vgextend vg0 /dev/sdb1 — расширяем основную группу томов
- lvcreate -L 32M -n lv_cache_meta vg0 /dev/sdb1 — создаем том в 1000 раз меньше, чем наш кэш. Это метаданные, ну и называем его соответственно.
- lvcreate -L 29G -n lv_cache vg0 /dev/sdb1 — создаем непосредственно том с кэшем.
- lvconvert —type cache-pool —poolmetadata vg0/lv_cache_meta vg0/lv_cache — связываем наши метаданные с кэшем
- lvconvert —type cache —cachepool vg0/lv_cache vg0/root — включаем кэш для для тома “root”
Если всё хорошо, видим сообщение:
Logical volume vg0/root is now cached.
Теперь ваша файловая система кэшируется. Но это ещё не всё. Как и любой кусок opensource-говна, его ещё нужно допилить.
Я пользуюсь Arch и обязательно нужно добавить несколько модулей в mkinitcpio.conf для создания начального рамдиска — то есть рассказать системе, что у нас есть кэш на момент загрузки.
MODULES=»i915 btrfs vfat crc32c dm_cache dm_cache_mq dm_cache_smq»
В раздел HOOKS нужно добавить lvm2, хотя скорее всего он там уже будет. Ну и конечно образ нужно пересоздать:
# mkinitcpio -p linux
Возможно, в других дистрибутивах нужно будет похимичить с grub.
Следующий шаг — добавим “issue_discards = 1” в секцию “devices” файла /etc/lvm/lvm.conf, чтобы включить trim на lvm.
В принципе, всё должно работать. Если вдруг упомянутый кусок opensource-говна решил пойти вразнос, то лучше этот самый кэш отключить. Это, кстати нужно, если вы пытаетесь подмонтировать ваш диск с rootfs в каком-нибудь live-дистрибутиве.
Короче, отключить всю эту содомию с кэшем тоже просто:
lvremove vg0/lv_cache lvremove vg0/lv_cache_meta vgreduce vg0 /dev/sdb1
Если делаете это при загрузке с live-usb/cd/dvd — будьте внимательны и смотрите, какие буквы диска используются, а то удалите корневой том по ошибке.
Вот такой вот могучий костыль. Есть другие варианты кэширования, но, похоже, lvm-кэш самый распространенный и поддерживаемый. И да, реальный прирост скорости чувствуется, особенно при загрузке. К сожалению, аналогов под Windows 10 я лично особо и не знаю.
Вопросы по эксплуатации lvm cache
По совету данному мне в этом топике Как правильно организовать кластер на Proxmox , попытался поднять ссд-кеширование в lvm.
В общем-то все у меня получилось, но мучает меня один баааааальшой вопрос:при включенном кешировании невозможно создавать новые логические тома в пуле?
Т.е. чтобы добавить том надо выключить кеш, добавить том, переинициализировать кеш? ПРоцедура добавления тома должна быть именно такой? это же катастрофа какая-то, потому что у меня на томах планировалось разворачивать виртуальные машины. а их предпологается десятка 2-3. 🙁 и сразу я не знаю сколько мне их понадобится.
вообще — насколько я понял, при любых манипуляциях с томом придется отключать кеш?
я может чего-то где-то проглядел? или есть какой-то правильный автоматизирующий механизм этих действий?
Не проглядел — это большая унылость lvmcache в текущей реализации (по сути: lvm + dm-raid). Я (с некоторой жертвой производительности, но ради большего удобства), сделал так: vg — lv (почти на весь vg) — lvmcache — ext4 — qcow2. То есть через proxmox создаю прямо qcow и не парюсь. Снепшоты есть, кеширование есть, qcow лежат на диске — что приятнее чисто с психологической точки зрения.
Блджад. :(( Очень хотелось попробовать погонять проксмокс с подключенными виртуалками именно на лвм. 🙁 Конечно, потестить можно. Что я впрочем и сделаю.
И еще: мож кто прояснить сможет — кеш надо настраивать для группы томов или для каждого тома отдельно?
вроде как я при включении Кеша перечислял все логические тома..
Просто если можно работать с группой томов (используется кеш на весь пул) то это еще терпимо — отключил кеш, сделал новый волюм на пустом месте, а потом включил кеш.. Или я хочу невозможного?
Есть еще bcache. Lvmcache из-за этих особенностей не очень юзабелен.
«а их предпологается десятка 2-3. 🙁 и сразу я не знаю сколько мне их понадобится. » и Вы хотите отлично взлететь на RAID0 на двух SATA дисках?
«проксмокс с подключенными виртуалками именно на лвм» вопрос 30 минут.
Экономия на железках приведет к извращениям, проходили 100 раз.
lmvcache — это по сути КЭШ диска. На запись поможет в рамках своего размера, а дальше все приплыли. На чтение вообще не понтяно как поможет. Уж лучше тогда виртуалки поверх файловой системы юзать — и добавить оперативки побольше — для раздачи ее виртуалкам (ОСЬ в виртуалке задействует ее в качестве КЭШа)
«Просто если можно работать с группой томов (используется кеш на весь пул) то это еще терпимо — отключил кеш, сделал новый волюм на пустом месте, а потом включил кеш.. » а проксмокс это умеет? или Вы будете руками каждый раз это делать с консоли?
Вы намечали апгрейд по железку — купите уже сейчас RAID контроллеры с SSD кэшированием и весь изврат с lvmcache уйдет и LVM будет юзать.
Вот будет интересно провести тесты (fio, sqlio) на IOPSы с lvmcache вкл и выкл на объеме данных (тестовый файл) в два три раза большем чем размер lvmcache.
На запись поможет в рамках своего размера, а дальше все приплыли.
Это если запись постоянно 100% или около того, что бывает редко. А zfs и в этом случае может помочь, аккумулируя рандомные записи и сливая их последовательно на диск.
На чтение вообще не понтяно как поможет.
Короче, иди читай за кэши.
если идет операция чтения с диска и в кэше пусто — то как поможет кэш? ПРи повторном чтении того же места с диска — кэш может помочь если к этому времения не вымоется.
Блджад. :(( Очень хотелось попробовать погонять проксмокс с подключенными виртуалками именно на лвм.
А реально то надо? Как по мне, то выигрыш в целом от Lvmcache — вполне себе нивелирует чуть большую просадку на qcow2+ext4, и там в отличии от lvm, снапшоты более человечнее сделаны, да и довольно приятно видеть просто файлы qcow на диске.
Вот будет интересно провести тесты (fio, sqlio) на IOPSы с lvmcache вкл и выкл на объеме данных (тестовый файл) в два три раза большем чем размер lvmcache.
Так и не понял до конца по какому хитрому алгоритму оно работает. Но по идее тупо прямую запись — оно должно пропускать напрямую. В общем, скажу так: везде где у меня применяется lvmcache — попадание в кеш SSD при чтении 50%, вся случайная запись — точно летит через lvmcache. — Вполне себе не плохой вариант. Не скажу что я в шоколаде, но серверные SSD по 240 гиг в зеркале — в целом меня устраивают.
А zfs и в этом случае может помочь, аккумулируя рандомные записи и сливая их последовательно на диск.
Так и не понял в zfs on linux сделали так, чтобы l2arc после перезагрузки не сбрасывался в нули или нет?
Вы намечали апгрейд по железку — купите уже сейчас RAID контроллеры с SSD кэшированием и весь изврат с lvmcache уйдет и LVM будет юзать.
Давича на почту пришло сообщение от DELL, что в определенных случаях на их аппаратных RAID можно потерять все данные. — В общем, это я к тому, что идея не плохая, но нужно осторожно подходить к вопросу. Очень уж много пропиретарщины гнилой в этих RAID железках.
бекапы то делать никто не отменял
я на RAID10 на SATA дисках кручу десяток виртуалок поверх LVM и норм. Режима кэширования в настройках proxmox достаточно.
попадание в кеш SSD при чтении 50%» ну это хорошо, видимо у Вас такая обстановка запросов и наличия данных к этому моменту в КЭШе
Режима кэширования в настройках proxmox достаточно.
SSD при чтении 50%» ну это хорошо, видимо у Вас такая обстановка запросов
Вы считаете это весьма низкий показатель? Или адекватный?
видимо у Вас такая обстановка запросов
Не скажу что у меня hiload. Но для моего профиля нагрузки в Oracle, к примеру — прирост ощутимый.
я на RAID10 на SATA дисках кручу десяток виртуалок поверх LVM и норм
Да вполне нормально будет почему ж нет. У меня mdadm raid6 (весьма спорный выбор наверное) + lvmcache. Крутится у меня не много машинок тоже в общем то. На 4ех слабых, но продуктивных серверах кружится 60 машин (включая lxc).
Вот посмотрел статистику (ну я иногда делаю fullbackup от машинок), но в целом вот такой показатель:
zelenij , может тоже интересно будет.
Процент попадания в SSD кеш, конкретно у меня: 76% читается с SSD. Ну и вестимо пишется так же через SSD.
Считаю, что lvmcache, даже в таком кривом варианте — не плох.
я на RAID10 на SATA дисках кручу десяток виртуалок поверх LVM и норм
Скажите, а у вас они крутятся в контейнерах (qcow2/raw) или развернуты на отдельных томах?
Если на отдельных томах, то Вы создавали кеш для каждого тома отдельно?
Считаю, что lvmcache, даже в таком кривом варианте — не плох.
думаю что на завтра у меня высвободится пяток часов на эксперименты. буду пробовать lvmcache, bcache и flashcache. тестировать буду как записью на раздел, так и тестами внутри виртуалок (qcow и raw); если успею, то попробую еще и развернуть виртуалку на лвм раздел..
И еще вопрос: какую фс лучше использовать? изначально я планировал ext4. но теперь терзают смутные сомнения насчет zfs.
кстати, тесты буду делать на другой машине, на 2х 500гб и 1 ссд, на который уже установлена система. могу отрезать от него около 30гб. Какой, кстати размер кеша надо делать? я так думаю — чем больше — тем лучше?
В проксмоксе zfs — самая медленное из возможных хранилищ виртуалок. Если есть время, можешь рассказать потом результаты.
соответственно вопрос: а в чем его (ЗФСа) плюшки? На быстрых носителях можно пренебречь потерей производительности, в угоду плюшкам?
Ну и второй вопрос: какую ФС использовать для максимальной производительности?
Смотря что у тебя крутится на разделе с кешем. Если БД лежит, то сам понимаешь, что процент попадания в кеш будет высоким. Ещё хороши желёзки/фс с дедупликацией, они тоже увеливают процент.
Я не спец по этой ФС, тут есть подкованные люди, пропиши тэг. А так плюшки типа снепшотов, сжатия и дедупа. Сам смотри, нужны они тебе или нет. Мне нет, у меня lvm over iscsi. На том конце два сервера с 10 рейдами. Но иопсов все равно не хватает, жду покупку двухголовой хранилки. Заказал туда ССД, посравниваю ссдкеш против автоматического многоярусного хранения.