Вопросы по эксплуатации lvm cache

Не проглядел - это большая унылость 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 от машинок), но в целом вот такой показатель:

# lvs -o cache_read_hits,cache_read_misses
  CacheReadHits    CacheReadMisses

        1963517448        468575847

# uptime
 295 days

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 рейдами. Но иопсов все равно не хватает, жду покупку двухголовой хранилки. Заказал туда ССД, посравниваю ссдкеш против автоматического многоярусного хранения.

Второй вопрос - лвм. Потом ext4.

Рядом тред про прелести zfs на проксе Swap и принудительная перезагрузка (proxmox)

Развернуты на отдельных томах (virtio,cache=writeback), аппаратный RAID10, lvmcache не настраивал.
Для критической виртуалки (1С в режиме терминала) пробросил зеркало из SSD в нее.

Если рассматривать пирог слоев относительно блина ЖД то нужно не забыть количество RAM которое выделяет СУБД (oracle,mssql) под КЭШ. RAM - самый быстрый КЭШ.

На Proxmox ZFS крутил не так много, но на SmartOS KVM-виртуалки на ZFS у меня живут, работают шустро и проблем не знают. Главное — оставить достаточно RAM для ARC. SSD для кэша чтения в ZFS-мире используют реже, чем для кэша записи (ZFS Ident Log, ZIL), потому что ZIL даёт *гораздо* больший прирост производительности, а с кэшем чтения и ARC хорошо управляется.

Саму SmartOS тебе рекомендовать не буду, потому что, как я понял, у тебя отдельный сервер-хранилище и тебе нужна удобная веб-морда для руления виртуалками. У SmartOS в чистом виде веб-морды нет — надо ставить SDC (Triton) или какой-нибудь там Project FiFo. И к сетевым хранилищам разработчики SmartOS относятся не очень.

Если памяти хватает. У меня из-за ошибок проектирования боевые бд выходят за все грани разумного.

Мое ИМХО такое:

Если нужно быстро, гибко, надёжно, не дорого, со снепшотами, но не очень емко и не HA:

• mdadm-raid 1+0 (или 10).
• lvm
• lvmcache - на двух SSD в raid1
• ext4

Для тестовых сред, сгодится и ZfsOnLinux, если ему ужать ARC - но собственно преимуществ для конкретных тестовых сред лично я не вижу, кроме как нативная поддержка инсталлятором proxmox конфигурации raid1 для такой связки, ну и сжатия by design. Только не нужно забывать, что больше 80%, том zfs заполнять не стоит, так что от сжатия выигрыш ну тоже так себе...

Zfs
On Linux, официально вроде никто не поддерживает, кроме ubuntu которая в инсталлятор вроде как включили его.
А за lvmcache +/- , но стоит rhel. Скажем так, не стоит, но в официальной документации у них это освещено.

zfs может дать преимущество на proxmox, если есть много серьёзных контейнеров и от них потребны снепшоты. В остальных случаях можно пользоваться lvm-thin томом, если нужны снепшоты от продуктивных контейнеров.

«ext4» на CentOS6.2 помню процесс с ext4 постоянно висел в списке процесов, что то он там частил с диском очень.
Для чего виртуалки размещать поверх ext4?, бекапы в проксмокс есть - в виде файлов хранятся.
«lvm-thin» у меня коллега тестил эту штуку, говорит хуже по производительности чем lvm.

«ext4» на CentOS6.2 помню процесс с ext4 постоянно висел в списке процесов, что то он там частил с диском очень.

Может быть, это было про это: http://fibrevillage.com/storage/474-ext4-lazy-init , на больших томах, до нескольких суток оно проходит.

Для чего виртуалки размещать поверх ext4?

Чтобы не покупать аппаратные RAID с кешированием на SSD, например.

«lvm-thin» у меня коллега тестил эту штуку, говорит хуже по производительности чем lvm.

Для того, чтобы иметь снепшоты на контейнерах (например для того же online backup, в том же proxmox - вполне себе решение).

если идет операция чтения с диска и в кэше пусто - то как поможет кэш?

Ты дурачок? А если идёт операция чтения и в кэше не пусто - то как не поможет кэш? А если ты только что записал пару блоков и теперь тебе надо их прочитать и отдать, они остались в кэше - то как не поможет кэш? Ещё раз настоятельно рекомендую ознакомиться с матчастью, перед тем как раздавать советы.

Без понятия.

Вы считаете это весьма низкий показатель? Или адекватный?

Мне тоже стало интересно мнение иксперта, так что я пока не буду эту цифру комментировать.

еще раз прочитай «если идет операция чтения с диска и в кэше пусто - то как поможет кэш?» с логикой плохо? при наличии чего либо в кэше утверждения не было.
+ почитай какие тесты я рекомендую проделать со всем пирогом с кэшами, файловыми системами и уровнями RAID.

а вообще спорить тут нечего, главное чтобы у ТС сложилось правильное понимание и он провел тесты и погонял виртуалки синтетикой и под реальной нагрузкой. Это и будет результат.

Чтобы не покупать аппаратные RAID с кешированием на SSD, например.

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

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

тесты я предлагаю делать на объеме данных которые превышают размер КЭШа (lvmcache) в два три раза, чтобы узнать во что упрутся IOPSы.
«но твоё утверждение было, мягко говоря, не об этом» - если людей не понимаете - переспрашивайте.

объём данных может быть и в 10 раз больше и всё равно может быть не кислый выйгр.

во что упрутся иопсы

это вообще малорелевантно при оценке эффективности кэша.

На чтение вообще не понтяно как поможет.

русским языком написано, что ты не понимаешь как кэш работает, что тут ещё переспрашивать?

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

В целом соглашусь, конечно! lvmcache и проч. - это конечно middle enterprise. ИМХО.

давно правда юзал вот такую штуку https://www.open-e.com/

Прикольно, я в общем то местами не гнушаюсь пользоваться freenasом, но понятное дело, что это решение на голову выше чем freenas. :)

Кокой midrange, окстись, даже не entry-level без двух нод с коросинком и ко.

https://forum.proxmox.com/threads/can-we-use-lvm-cache-in-proxmox-4-x.25636/
Если запустите lvmcache то в настройках виртуалки рекомендуют cache=none

Оффтоп, а как можно сделать такой изврат: ro_диск + rw_tmpfs с контролируемой синхронизацией изменений на этот ro_диск?

Те чтобы чтение шло с диска, а запись на tmpfs только.

tmpfs - это RAM диск?

А что в ней внутри, обычный стек с кастомным лицом? Репликацию там пробовал?

нет, перед покупкой второй ноды СХД контора в которой работал перестала существовать.

Да

Заболел я.. поэтому никаких тестов пока не сделал :( хотя не совсем... crystal disk mark в гостевой системе дал какие-то дурноватые результаты..... :( вообще ничего не понимаю...

-----------------------------------------------------------------------
CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :  5454.113 MB/s
  Sequential Write (Q= 32,T= 1) :  2364.766 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   460.356 MB/s [112391.6 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   330.107 MB/s [ 80592.5 IOPS]
         Sequential Read (T= 1) :  1352.666 MB/s
        Sequential Write (T= 1) :  1089.496 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    20.411 MB/s [  4983.2 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    19.878 MB/s [  4853.0 IOPS]

  Test : 500 MiB [C: 81.8% (26.4/32.2 GiB)] (x1)  [Interval=5 sec]
  Date : 2017/02/26 21:48:41
    OS : Windows Server 2008 R2 Enterprise (Full installation) SP1 [6.1 Build 7601] (x64)

Test : 500 MiB [C: 81.8% (26.4/32.2 GiB)] (x1) [Interval=5 sec]

Тест не корректен. Ты тестируешь свою оперативную память. Играйся с кешированием вирт. машины. И ставь объем файлов на побольше. - А дальше уже зависит от твоих SSDшек.

А что скажете про это «чудо»?

диск Z - «сетевой». Это расшареная самба(убунта, в qcow2), которая крутится на этом же хосте. Носитель для этой файлопомойки также находится в qcow2

-----------------------------------------------------------------------
CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :   281.224 MB/s
  Sequential Write (Q= 32,T= 1) :   475.380 MB/s
  Random Read 4KiB (Q= 32,T= 1) :    64.714 MB/s [ 15799.3 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :    57.337 MB/s [ 13998.3 IOPS]
         Sequential Read (T= 1) :   246.209 MB/s
        Sequential Write (T= 1) :   415.087 MB/s
   Random Read 4KiB (Q= 1,T= 1) :     6.128 MB/s [  1496.1 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :     7.422 MB/s [  1812.0 IOPS]

  Test : 1024 MiB [Z: 73.6% (144.8/196.7 GiB)] (x1)  [Interval=5 sec]
  Date : 2017/02/28 14:49:14
    OS : Windows Server 2008 R2 Enterprise (Full installation) SP1 [6.1 Build 7601] (x64)