Несколько вопросов по LVM-thin
Если на VG закончится место, то не смотря на то что на самих LV свободное место не израсходовано, то может быть ай-яй-яй.
Proxmox будет немногословно сообщать о возникающих io-error.
# lvdisplay --- Logical volume --- LV Name nvme0 VG Name nvme LV UUID hzTNp1-ERld-5HBB-G357-N2M9-KJpI-C3f5P9 LV Write Access read/write LV Creation host, time pve08, 2020-11-06 14:27:16 +0500 LV Pool metadata nvme0_tmeta LV Pool data nvme0_tdata LV Status available # open 2 LV Size 438.18 GiB Allocated pool data 72.61% Allocated metadata 46.17% Current LE 112175 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:5 --- Logical volume --- LV Path /dev/nvme/vm-118-disk-1 LV Name vm-118-disk-1 VG Name nvme LV UUID y2ZSgB-smty-fBul-IGMm-FQRd-0Iqu-UHb2fD LV Write Access read/write LV Creation host, time pve08, 2020-11-11 00:29:43 +0500 LV Pool name nvme0 LV Status available # open 1 LV Size 400.00 GiB Mapped size 79.55% Current LE 102400 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:8 Насколько я понял надо следить за значением Mapped size, но например Zabbix этого не делает, может через дополнительный шаблон?
Скажите, я правильно все понимаю?
Просто вчера у нас был сбой, я разобрался, но физику процесса, кажется, не до конца понял. Просветите…
Подскажите годных шаблонов для Zabbix.
О производительности Thin Provision в LVM2
С версии RHEL 6.4 в LVM2 включена поддержка thin provision. На русский я бы перевёл это как «тонкое резервирование», хотя перевод неточен и совершенно не согласуется с реальностью, поэтому далее наравне с русским будет использоваться английское написание.
Thin provisioning — это создание логических томов, которые изначально используют немного места и «растут» по мере записи в них данных. В ZFS это реализовано давно по самой философии этой ФС. В VMware это используется в каждом продукте. Дошло дело до LVM2, широко применяемом в Linux в наши дни. Также одним из основных нововведений является thin snapshots, когда для снэпшотов нет необходимости резервировать место заранее, а он «растёт» вместе с изменёнными данными. Также разрешаются и поощряются вложенные снэпшоты (снэпшоты снэпшотов c любой глубиной), при этом заявляется об отсутствии при этом падения производительности. О нескольких нюансах использования будет рассказано в статье.
Для стабильной работы thin provision в LVM2 требуется ядро 3.4. В Red Hat бэкпортировано и работает на их «классическом» 2.6.32.
В близкой мне Debian Wheezy thin provisioning недоступен ввиду отсутствия ключа при компиляции lvm2 —with-thin=internal и других сложностей. При необходимости, для целей теста, можно скомпилировать этот пакет из исходников.
Меня больше интересовали не снэпшоты, а производительность «тонких логических томов» (Thin Logical Volume) для использовании на серверах. Для нетерпеливых скажу сразу — падение производительности наблюдается, и существенное. Подробности ниже.
На одном и том же сервере с CentOS 6.4 2.6.32-279.2.1.el6.x86_64 на RAID1 сделанном при помощь mdadm, создаём «пул тонкого резервирования» (thin pool):
lvcreate -L 50G -T /dev/VG/thin_poolи обычный логический том (LV):
lvcreate -L 50G /dev/VG/thick_volИзмерим производительности линейного чтения и записи на эти устройства:
Thin pool:
Запись:
dd if=/dev/zero of=/dev/mapper/VG-thin_pool bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.9126 s, 65.9 MB/sЧтение:
dd if=/dev/mapper/VG-thin_pool of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.19247 s, 250 MB/sLV:
FIO: Запись: iodepth=2, bw=943120 B/s, iops=230, avg=8645.48 usec# dd if=/dev/zero of=/dev/VG/thick_vol bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.8432 s, 66.2 MB/sFIO: Чтение: iodepth=2, bw=775490 B/s, iops=189, avg=10536.95 usec# dd if=/dev/VG/thick_vol of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.04925 s, 259 MB/sКак видно производительность при этом не различается для LV и thin pool.
Создаём thin volume (тонкий логический том) в thin pool
lvcreate -V 100G -T -n thin_vol /dev/mapper/VG-thin_poolЗапись:
FIO: Запись: iodepth=2, bw=1100.5KB/s, iops=275, avg=7241.55 usecdd if=/dev/zero of=/dev/mapper/VG-thin_vol bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 38.7505 s, 27.1 MB/sЧтение:
FIO: Чтение: iodepth=256, bw=86100KB/s, iops=21524, avg=11860.53 usecdd if=/dev/mapper/VG-thin_vol of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.45363 s, 235 MB/sОчень хорошо заметно, что линейная запись на thin volume производится в 2 раза медленнее, чем на обычный LV (27.1 MB/s против 66.2 MB/s). При этом скорость случайной записи даже возрастает, а для случайного чтения вообще не удалось замерить реальную производительность — показывает только уровень чтения из кеша, при этом сброс кеша не помог.
Падение производительности линейной записи настораживает и есть вероятность, что это связано с наличием RAID1 от mdadm, поэтому пришлось протестировать на другой машине, также посмотрим на производительность на уровне файловой системы. Виртуальная машина VMware Workstation Debian Wheezy 7.3 3.10-0.bpo.3-amd64 SSD диск.
LV:
Запись:
dd if=/dev/zero of=/delete.img bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 3.49623 s, 300 MB/sЧтение:
FIO: Чтение: iodepth=384, bw=158839KB/s, iops=39709, avg= 9.64 msecdd if=/delete.img of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 2.31352 s, 453 MB/sThin LV:
Запись:
dd if=/dev/zero of=/mnt/thin/delete.img bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 7.15546 s, 147 MB/sЧтение:
FIO: Чтение: iodepth=384, bw=176574KB/s, iops=44143, avg=8675.36 usecdd if=/mnt/thin/delete.img of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 2.33435 s, 449 MB/sПроизводительность случайной записи измерить не удалось.
И снова наблюдаем падение скорости линейной записи в два раза, как и в предыдущем тесте. Возможно это связано с нюансами виртуальной машины.
UPDATE: Произвёл ещё одно тестирование на «чистом» сервере без RAID и вирт.машин. Падение производительности линейной записи не наблюдается! Прошу прощения уважаемой аудитории за введение в заблуждение в связи с однобокостью тестирования в первые два теста. В результате считаю необходимо тестировать производительность для каждого конкретного случая.
ИТОГИ:
- При использовании thin volume в каждом конкретном случае необходимо производить тестирование производительности линейной записи, так как, к примеру, для RAID 1 с mdadm и вирт.машин VMware происходит падение скорости линейной записи на него в 2 раза по сравнению с «классическим» LV;
- При этом у случайной записи на thin volume такого падения не замечено и скорость на том же уровне, что я для LV;
- На Debian использовать в продакшне пока не буду ввиду отсутствия в стандартных репозиториях;
- lvm2
- thin-provision
- производительность
- линейная запись
- debian
LVM Thin Provision: опыт эксплуатации на малом объекте
О тонких томах я уже писал в более ранней статье. Производительность хорошая, слабо зависит от количества снимков, за более чем год, не было сбоев по вине именно LVM, все проблемы были созданы лично мной для себя любимого.
Грабли
Всем, кто начинает использовать тонкие тома, настоятельно рекомендуется чтение man lvmthin с пристрастием. Упущение, казалось бы, маловажного аспекта, что место в пуле томов может кончится, может привести к печальным последствиям.
Исчерпание места в Data space:
В зависимости от ФС. Обычно, после остановки io с переполненным томом, ФС остается целой, особенно если ФС журналируемая. Если вы успели расширить пул, и io-операции не успели отвалится по таймауту, то вообще все будет хорошо. Иначе откат журнала и небольшая потеря данных.
Исчерпание места в Metadata space:
Это очень стремная ситуация, так как ведет к остановке корректной работы всего тонкого пула, с необходимостью offline восстановления целостности данных пула. Это, часто приводит к серьезным нарушениям в Data space, и в 2 случаях из 3, проще было убить XFS и накатить бэкап, чем пытаться её восстановить.
Рекомендации:
Задавайте политику автоматического расширения тонких томов глобально. Задав разумные значения, вы потом сможете используя профили, настроить любую другую политику для пула. Однако, если система не применит профиль (в метаданных пула хранится имя профиля, который могли удалить), она сообщит об этом факте где-то в логах (чего можно и не заметить), но благодаря глобальной политике, все будет относительно неплохо.
LVM Thin Provision отлично работает в ситуации ленивого планирования. Это значит, что стоит под разные задачи создать пулы тонких томов разумно небольших размеров. В этих пулах создать тома, и просто наблюдать, как по мере заполнения растут размеры пулов. Выделять место сразу не стоит, не всегда можно предугадать под, что нужно место.
Размеры chunksize задавайте исходя из задачи. Большие размеры приведут к снижению накладных расходов в метаданных, но повлекут больший расход места на снимках (если совпадет с RAID5-6, то и тут бонус будет).
Zeroing — если отключить, получите чуть-чуть бонуса по скорости, но готовьтесь, в выделенных блоках может встретится всяких мусор.
Работа со снимками
Снимок создается без проблем, а вот его применение может вызвать некоторую проблему. Все дело в том, что пока том активен (хотя и не используемый), снимок к нему не применяется до следующей активации (или применяется в ленивом режиме). Поэтому, перед накатом снимка, дезактивируйте целевой том.
По умолчанию снимки создаются с флагом отмены активации. Это может обескуражить, при попытке его подключить.
Lvm thin что это
Это очень короткая шпаргалка по LVM – основные команды для создания тома.
Имеем виртуальный диск /dev/xvdb нужно сделать на нем том LVM с возможностью снапшотов (т.к. том не должен занять весь физический диск).
Итак:
Создаем раздел тип раздела 8e
fdisk -l /dev/xvdb Диск /dev/xvdb: 10.7 ГБ, 10737418240 байт 255 heads, 63 sectors/track, 1305 cylinders Units = цилиндры of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe90a3c2f Устр-во Загр Начало Конец Блоки Id Система /dev/xvdb1 1 1305 10482381 8e Linux LVM
Создаем физический том
pvcreate /dev/xvdb1
Создаем группу томов
vgcreate /dev/xvdb1
Смотрим какой получился размер у группы томов
число физических экстентов (2558):
~# vgdisplay | grep "Total PE" Total PE 2558
размер физического экстента (4,00 MiB):
~# vgdisplay | grep "PE Size" PE Size 4,00 MiB
Допустим мы хотим зарезервировать 400Мб под снапшоты, 400Мб = 100 физических экстентов, тогда размер LVM-тома должен быть “Total PE”-100 = 2458.
Создаем LVM-том нужного размера:
lvcreate -l 2458 —name
Узнать есть ли свободное место на физическом томе под снапшоты (400,00 MiB free):
pvscan PV /dev/xvdb1 VG mysql lvm2 [9,99 GiB / 400,00 MiB free] Total: 1 [9,99 GiB] / in use: 1 [9,99 GiB] / in no VG: 0 [0 ]
Уменьшить раздел
Сперва нужно проверить файловую систему на ошибки
e2fsck -f /dev/pve/data
Затем уменьшаем файловую систему на размер, меньший, чем будет раздел в итоге.
resize2fs /dev/pve/data 900G
Потом уменьшаем раздел LVM
lvreduce -L 1000G /dev/pve/data
И наконец, расширяем файловую систему до полного размера раздела
resize2fs /dev/pve/data
Thin LVM
Должны быть установлены thin-provisioning-tools
apt-get -y install thin-provisioning-tools
Создать пул тонких томов:
lvcreate -L 300G --name data pve lvconvert --type thin-pool pve/data --poolmetadatasize 10G
lvs -o+chunksize
Создать тонкий том в пуле:
lvcreate -T -V 100G -n thin-volume pve/data
Отобразить все тома включая скрытые
lvs -a
Ключевые моменты в работе тонких томов:
1. При создании тонкого тома дополнительно к исходному тому создаются два скрытых тома под метаданные (один запасной с названием lvol0_pmspare). Если метаданные испортились их можно попробовать восстановить при помощи lvconvert —repair VG/ThinPoolLV
2. Для метаданных (информация о выделенных блоках) сохраняется на отдельном томе (который автоматически создается), и когда на нем кончается место, то происходит порча метаданных и файловвых систем на тонких томах (т.к. ошибка записи будет).
3. Thin-LVM поддерживает автоувеличение томов, в том числе и тома metadata (что бы увеличить метадату, нужно что бы были свободные екстенты на vg, по этому под нужно всегда оставлять свободное место на VG!!). Автоувеличение настраивается в /etc/lvm.conf (thin_pool_autoextend)