Вариант для распечатки		Пред. тема | След. тема
Форум Оптимизация и Промышленные системы (Хранилища данных)
Изначальное сообщение		[ Отслеживать ]

"Lvm без матрешки, pv over lvs, ну как?"	+/–
Сообщение от Kirikekeks (ok), 14-Ноя-22, 00:33
Доброй консоли. Есть способ, описанный подробно в статье habr.com https://habr.com/ru/post/492834/. Я эту статью грызу, кусаю, лижу, курю и тщетно. Думаю до посинения, без просветления. Сжальтесь, пожалуйста. Вот райд. Один pv, один vg, 1,2Тб. Хочу его нарезать, кусочек под кэш сюда, кусочек под кэш туда, вот тут почта, а этому lxc, а этот под облако. А вот эти два под тесты. Вот выше в статье все получается. Моя же Центось хочет работать с "реальными" девайсами, и кушать lvs-cache, как новый pv не желает категорически. А как кэшировать  hdd, если целый рэйд очень жирно, а lvs кэширющего устройства должен быть в одной группе томов кэшируемого? Как Чайфы + Жванецкий,"Ээ?эй есть ещё сдесь хоть кто-то, умнее меняяяя??" Буду очень признателен.
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от ACCA (ok), 16-Ноя-22, 18:20	+/–
> https://habr.com/ru/post/492834/. Я эту статью грызу, кусаю, лижу, курю и тщетно. Думаю > до посинения, без просветления. Сжальтесь, пожалуйста. > Вот райд. Один pv, один vg, 1,2Тб. Хочу его нарезать, кусочек под "Один pv" значит никакого тебе кэширования средствами LVM. Перечитай статью и посчитай сколько раз вызывается pvcreate. Особенно на чём именно и почему создаются эти PV. А вообще что-либо с RAID1 - так себе идея, ибо тормоза. Есть приличная замена - https://linuxhint.com/configure-zfs-cache-high-speed-io/ Только учти, что /boot и /root на ZFS в Linux лучше не совать - не всегда загрузишься.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3

2. Сообщение от Kirikekeks (ok), 17-Ноя-22, 19:37	+/–
>> https://habr.com/ru/post/492834/. Я эту статью грызу, кусаю, лижу, курю и тщетно. Думаю > А вообще что-либо с RAID1 - так себе идея, ибо тормоза. Есть > приличная замена - https://linuxhint.com/configure-zfs-cache-high-speed-io/ Спасибо, я перечитывал. И пересчитывал. Автор умудрился разрезать raid6 на кусочки, и эти кусочки произвольно складывать в новые pv, выиграв в iops, и бэкапах, и в лабораторных стендах. egrep '#pvcreate' lvm-matreshki.txt #pvcreate /dev/md0 #pvcreate /dev/md2 #pvcreate --metadatasize 64m /dev/md3 #####pvcreate /dev/root/cache #####pvcreate /dev/data/cache #####pvcreate /dev/root/images #pvcreate /dev/cache/cachedata А я неприятно упёрся в потолок понимания текста на русском. С фряхи я начинал, и кое-что про неё помню. Уважаю безмерно. Но мне не tank нужен, а вертолёт. А вертолёты это души сгоревших танков :-) Ладно, спасибо. Пойду по пути где я понимаю, разберу на диски, разобью на разделы и уже с ними буду экспериментировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Dorne (?), 04-Мрт-23, 11:16	+/–
> "Один pv" значит никакого тебе кэширования средствами LVM. Перечитай статью и посчитай > сколько раз вызывается pvcreate. Особенно на чём именно и почему создаются > эти PV. На самом деле, такое тоже возможно, но, это, скорее, для совсем уж ценителей искусства. Можно сделать JBOD из SSD + HDD. SSD в начале, HDD в конце. Из этого JBOD сделать pv, a на нем vg. В этом случае выбирать backing store для lv можно через pvmove или offset-ы. И, тогда, можно будет кэшировать и юзать thin в любой комбинациив с одним pv. Но, никакой практической пользы в этом подходе нет. Это сложно и не недежно. Так что, не советую)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4

4. Сообщение от Аноним (4), 04-Мрт-23, 11:39	+/–
>[оверквотинг удален] >> эти PV. > На самом деле, такое тоже возможно, но, это, скорее, для совсем уж > ценителей искусства. Можно сделать JBOD из SSD + HDD. SSD в > начале, HDD в конце. Из этого JBOD сделать pv, a на > нем vg. > В этом случае выбирать backing store для lv можно через pvmove или > offset-ы. И, тогда, можно будет кэшировать и юзать thin в любой > комбинациив с одним pv. > Но, никакой практической пользы в этом подходе нет. Это сложно и не > недежно. Так что, не советую) Спасибо. Я потом прочитал интересные заметки у amarao404 про деградацию mdadm raid ssd. И пустил 4 ssd в простой линейный vgs без raid, c созданиеm lvm-thin кэшированных на nvme. В целом полученным результатом доволен, и прежде всего пониманием что сделал и куда бежать, если что :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5

5. Сообщение от Kirikekeks (ok), 04-Мрт-23, 11:46	+/–
>[оверквотинг удален] >> В этом случае выбирать backing store для lv можно через pvmove или >> offset-ы. И, тогда, можно будет кэшировать и юзать thin в любой >> комбинациив с одним pv. >> Но, никакой практической пользы в этом подходе нет. Это сложно и не >> недежно. Так что, не советую) > Спасибо. Я потом прочитал интересные заметки у amarao404 про деградацию mdadm raid > ssd. И пустил 4 ssd в простой линейный vgs без raid, > c созданиеm lvm-thin кэшированных на nvme. В целом полученным результатом доволен, > и прежде всего пониманием что сделал и куда бежать, если что > :-) Ник у Вас подозрительно похож на автора статьи. Моё почтение, если так. Коммент выше - мой, но забыл залогиниться. Жду обещанного продолжения, про миграцию в геораспределенных кластерах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема