Что такое lvm thin pool
LVM Thin Provision: опыт эксплуатации на малом объекте
Краткая вводная
О тонких томах я уже писал в более ранней статье. Производительность хорошая, слабо зависит от количества снимков, за более чем год, не было сбоев по вине именно LVM, все проблемы были созданы лично мной для себя любимого.
Грабли
Всем, кто начинает использовать тонкие тома, настоятельно рекомендуется чтение man lvmthin с пристрастием. Упущение, казалось бы, маловажного аспекта, что место в пуле томов может кончится, может привести к печальным последствиям.
Исчерпание места в Data space:
В зависимости от ФС. Обычно, после остановки io с переполненным томом, ФС остается целой, особенно если ФС журналируемая. Если вы успели расширить пул, и io-операции не успели отвалится по таймауту, то вообще все будет хорошо. Иначе откат журнала и небольшая потеря данных.
Исчерпание места в Metadata space:
Рекомендации:
Задавайте политику автоматического расширения тонких томов глобально. Задав разумные значения, вы потом сможете используя профили, настроить любую другую политику для пула. Однако, если система не применит профиль (в метаданных пула хранится имя профиля, который могли удалить), она сообщит об этом факте где-то в логах (чего можно и не заметить), но благодаря глобальной политике, все будет относительно неплохо.
LVM Thin Provision отлично работает в ситуации ленивого планирования. Это значит, что стоит под разные задачи создать пулы тонких томов разумно небольших размеров. В этих пулах создать тома, и просто наблюдать, как по мере заполнения растут размеры пулов. Выделять место сразу не стоит, не всегда можно предугадать под, что нужно место.
Размеры chunksize задавайте исходя из задачи. Большие размеры приведут к снижению накладных расходов в метаданных, но повлекут больший расход места на снимках (если совпадет с RAID5-6, то и тут бонус будет).
Zeroing — если отключить, получите чуть-чуть бонуса по скорости, но готовьтесь, в выделенных блоках может встретится всяких мусор.
Работа со снимками
Снимок создается без проблем, а вот его применение может вызвать некоторую проблему. Все дело в том, что пока том активен (хотя и не используемый), снимок к нему не применяется до следующей активации (или применяется в ленивом режиме). Поэтому, перед накатом снимка, дезактивируйте целевой том.
По умолчанию снимки создаются с флагом отмены активации. Это может обескуражить, при попытке его подключить.
Несколько вопросов по LVM-thin
Если на VG закончится место, то не смотря на то что на самих LV свободное место не израсходовано, то может быть ай-яй-яй.
Proxmox будет немногословно сообщать о возникающих io-error.
Насколько я понял надо следить за значением Mapped size, но например Zabbix этого не делает, может через дополнительный шаблон?
Скажите, я правильно все понимаю?
Просто вчера у нас был сбой, я разобрался, но физику процесса, кажется, не до конца понял. Просветите…
Подскажите годных шаблонов для Zabbix.
Не надо выделять больше места, чем реально есть.
Про метаданные тоже не забывай. Вообще надо забыть о привычке выделять всё свободное место VG. В LVM принято оставлять в VG свободное место для будущего использования, ведь ты всегда сможешь увеличить LV, если это надо. Это свободное место пригодится и тогда, когда оно кончится в томе с метаданными.
Без ответа на «зачем тебе thin-pool?» тебе нельзя помочь.
Без ответа на «зачем тебе thin-pool?» тебе нельзя помочь.
Говорится что thin-pool дает прирост производительности по сравнению с обычными файловыми системами, поэтому на SSD томах мы его используем, как то так.
То есть у нас он для создания образОв VM
Если thin pool явно не нужен
Для одного единственного lv thin-pool явно не нужен. Также в конфигах lvm часто установлен флаг автоматического увеличения пула при заполнении, что можно тупо забить весь VG. Также для файловых систем на lv на thin-pool имеет смысл включить discard или периодически делать fstrim. Вся эта комбинация настроек дает разные способы мониторинга и администрирования.
А человек даже не понимает зачем нужен thin-pool.
Говорится что thin-pool дает прирост производительности
С такими тараканами точно не помочь.
Снапшоты для thin-lvm не тормозят, т.к. находятся в том же пространстве (в том же pool’e)
thin-pool насколько я помню при первом снапшоте теряет производительность в два раза, а далее уже работает в режиме подобным zfs снапшотам. По-сему, если снепшоты не нужны, юзать lvm-thin не вижу смысла. Если нужны: юзать zfs.
Говорится что thin-pool дает прирост производительности
охлол, говорится бабками у подъезда? а самому проверить, что это, мягко говоря, не так, совсем никак?
То есть у нас он для создания образОв VM
охлол, говорится бабками у подъезда? а самому проверить, что это, мягко говоря, не так, совсем никак?
Ты не поверишь, но я специально переделывал раздел с директории на thin-pool, и мерил попугаев тестом гилева.
Тест запускали раз по 10 в каждой конфиге на одном и том же физическом массиве и сервере.
Получали 9-11 попугаев в конфиге директорий, и 12-14 на thin, так что ты опять наложил себе в штаны 😉
То есть у нас он для создания образОв VM
не так выразился, не для создания образов VM, а для того чтобы эмитировать жесткие диски VM, к тому же переехать с Thin на raw дело пары часов… особо не комплексовали
спасибо ))) полезное есть, но не слова о Zabbix
а для того чтобы эмитировать жесткие диски VM
кому вы их эмитировать собрались, стесняюсь спросить
thin-pool насколько я помню при первом снапшоте теряет производительность в два раза
Ничего подобного. Никаких просадок, все на уровне комбайнов типа ZFS/BTRFS
в «два раза» твое утверждение – тебе доказывать
Вчера развернул мониторинг на тестовой ноде, сегодня буду на рабочих разворачивать
Если не выделять vm места больше, чем есть, то и проблем не будет. И мониторить не придется. Если есть достаточно оперативы, то попробуйте zfs. Я на Proxmox пробовал и то и то. LVM-Thin стараюсь не использовать, если возможно. И создаю тонкие тома вручную с указанием размера под метаданные с запасом. Шаблоны для zabbix есть под то и то на zabbix share.
Только что закончил развертывание, вроде предупреждений не прилетело, изучу вопрос детально в ближайшее время, спасибо за совет
Сколько у вас было юзеров? С чем сравнивать?
Я бы не сказал что сильно медленно. Сам иногда проделываю операции на их компе, все довольно комфортно.
Если сравнивать «расшаренную папку» где то в недрах убитой ЛВС, то намного быстрее.
Если сравнивать работу на локальном SSD, то да, разница заметна, но не критично.
У Гилева нет такого, что 12 и 24 работают в 2 раза быстрее, это означает что «папугаев» больше, и это уже не известно что.
А у нас 12 попугаев есть и днем, в рабочее время, и ночью, когда делали оптимизацию.
Юзеров не много.. под 2 сотни… Но попугаи гилева на то и попугаи, что бы не имело значение количество юзеров
попугаи Гилева это и есть производительность на ядро ))) весь тест вы один поток, ядро слабое и попугаев не жди. вот и весь ваш тест гилева, дефектив бай дизайн
Здравствуй, Шульман! Что тебе сказать … Я не знаю, в чем мой смертный грех. Десять лет тебе придется ждать. Ведь ответил я один за всех …
LVM Thin Provisioned volume, тонкие (разреженные) тома
RedHat (и CentOS) начиная с версии 6.4 поддерживают Thin provisioned storage разряженные тома. Основная мысль похожа на разреженные (sparce) файлы. Том выглядит большим, но на самом деле занимает мало места — только то, которое нужно для хранения данных.
1. Уже должна существовать группа дисков (VG) и в ней должно быть свободное место, например storage
2. Создается пул разреженных томов, например на 100Гб. Эти 100Гб сразу отмечаются в VG как занятые и их нельзя исползовать под обычные LVM-разделы. Разреженные тома создаются внутри этого пула. Пул разреженных томов нигде симлинками не отмечен и напрямую не используется.
3. Создается разреженный том. Видимый размер разреженного тома может быть больше чем доступное место в пуле и даже больше размера самого пула, пока данные фактически могут поместиться в пул. Для разреженного тома так же как и для обычного создается симлинк (/dev/storage/test) и далее с ним можно работать как с обычным LVM-томом.
Просмотр фактически занятого места в пуле и на томе:
Если место в пуле будет полностью израсходовано и кто-то в этот момент попробует записать данные на диск — операция ввода/вывода будет приостановлена пока в пуле не появится место (можно что-то удалить или расширить пул через lvextend), после появления места операция записи будет завершена.
Кроме постепенного выделения места поддерживается и освобождение в пуле места которое раньше было занято, но теперь не нужно. Например на каком-то разделе потребовалось место чтобы создать/распаковать большой архив. А потом архив удаляется. Освобождение места поддерживается через механизм TRIM (аналогично очистке места на SSD) и в LVM называется discard_data.
освобождать место можно двумя путями:
1. Вручную, командой fstrim — место освобождается только при запуске команды в указанной точке монтирования
2. монтировать файловую систему с опцией discard. например — тогда место освобождается сразу после удаления данных с диска. (прим. XFS активно кеширует все изменения, так что в случае использования XFS нужно сделать sync если нужно очистить место быстро, либо подождать несколько минут пока изменения фактически применятся на диск сами).
Что нам стоит LVM построить (принцип работы, производительность, Thin Provision)
Не смотря на наличие нескольких статей на Хабре, про LVM2 и производительность Thin Provisioning, решил провести своё исследование, так как имеющиеся показались мне поверхностными.
Кому интересно, добро пожаловать под кат.
Немного о LVM2
Собственно, LVM это система управления дисковым пространством. Позволяет логически объединить несколько дисковых пространств (физические тома) в одно, и уже из этого пространства (Дисковой Группы или группы томов), можно выделять разделы (Логические Тома), доступные для работы. ОС получает к ним доступ через DevMapper.
Логические тома могут свободно размещаться в дисковой группе, занимая непрерывные или разрывные диапазоны адресов, или находится частично на разных дисках группы. Логические тома можно с легкостью изменять в размерах (а вот ФС не все так могут) или перемещать между дисками группы, а также создавать мгновенные снимки состояния логического тома (снапшот). Именно снапшоты и представляют главный интерес в статье.
Как вообще работает LVM
Идея тут проста, все вертится вокруг таблиц соответствия логических и физических адресов.
Общая схема такая: Физические тома отражаются на Дисковую группу. Дисковая группа отражается на Логические тома.
Снапшоты чуть иначе: собственная таблица ассоциирует блоки оригинального тома и блоки снапшота (копия блоков оригинала, до их модификации). Работает по принципу копирования при записи (CoW, делается копия блока оригинального тома, потом происходит запись этого блока в оригинальном томе). Создать снапшот от снапшота невозможно.
Тонкие тома работают чуть иначе. В группе томов создается специальный том (пул тонких томов, на самом деле состоит из двух, для данных и мета данных), из этого пула происходит выделение виртуального пространства для тонких томов. Пространство виртуально, потому как до момента реальной записи, блоки не выделяются из пула. И вообще, можно задать виртуальный размер тома, больше чем пул. Когда том распухнет до предела, система заморозит запись в него, до увеличения размеров пула. Снапшоты тут похожи на своих «толстых» братьев, но оперируют уже не блоками, а ссылками на блоки. То есть, после создания снапшота, запись в оригинал происходит так-же как и до создания снапшота (перезаписываемые блоки выделяются из пула). Есть возможность создавать снапшот от снапшота, а также можно указывать внешний том оригинала (размещенный вне тонкого пула в той же группе томов, защищенный от записи).
Производительность
Производительность толстых томов без снапшотов равна обычным дисковым разделам (разница очень мала), а как обстоят дела со снапшотами?
Тесты показали ад и ужас. Из-за CoW, операции записи в оригинальным том замедляются катастрофически! И чем больше снапшотов, тем хуже.
Несколько исправить положение дел может задание большего размера фрагмента (по умолчанию, это 4 килобайта, что дает большой объем маленьких iops). Ситуация несравнимо лучше, если писать не в оригинальный том, а в снапшот.
Тонкие тома показывают более сбалансированную картину. Скорость работы слабо зависит от числа снапшотов, и скорость значительно ниже, чем для простого толстого тома без снапшотов и близка к скорости записи в толстый снапшот. Основной вклад в тормоза дает процесс выделения места (фрагмент размером в 4 килобайта).
Методика тестирования
Надежность
Оценивать надежность я буду просто, по уровню сложности механизма доступа к информации. Чем он сложнее, тем его надежность ниже (к реальной надежности это имеет довольно далекое отношение).
Самым надежным, выглядит конечно обычный раздел. Пространство линейно, никаких промежуточных абстракций. Ломаться особо не чему. Из клёвых плюшек нет ничего.
Второе место займет Толстый Том. Появившиеся абстракции конечно не делают его надежнее, но добавляют массу гибкости. Восстанавливать данные из рассыпавшегося LVM не так уж и легко, но скорее всего, большинство томов будут размещены линейно, с небольшой фрагментацией (и эти фрагменты возможно будут крупными, вряд ли вы будете расширят разделы маленькими блоками).
Самыми ненадежными выглядят Тонкие Тома. Сложный механизм выделения места, изначально фрагментированное пространство (но не сами данные, они то как раз размещены компактно и даже линейно). Повреждение таблицы трансляции адресов, сделает данные крайне сложно читаемыми. К слову, надежность btrfs, zfs или ntfs на более худшем уровне. У тонких томов только распределение пространства в опасности, а у ФС еще и своих абстракций полно.
Proxmox 4. День второй. Thin-LVM
Добрый день, друзья. После ранее опубликованной статьи много воды утекло, было поднято несколько серверов, несколько уже на новой 5-ой версии. Были и кластеры и CEPH и даже репликация с двумя нодами (появилась функция в 5-ке). Для себя принял решение (как и советовали в прошлых комментариях), что проще и удобнее ставить debian, правильно размечать диски и поверх рабочего soft-raid поднимать proxmox.
О разметке, о VLM и о тонких дисках далее и пойдет речь.
На одном сервере столкнулся с очень большой и неприятной вещью. Сервер отдельный, на debian 8. При разметке, в которой отдельное большое место выделяется под thin-lvm диск для хранения дисков виртуальных машин, есть одна тонкость, которую я не учитывал ранее.
Пример реальной конфигурации: создан soft raid-10 из 4 дисков по 3 Тб.
Из общих 5,7 Тб выделен отдельный диск в 5,37 типа LVM-Thin для дисков виртуалок. Размещены виртуальные машины, общий выделенный объем дисков которых составил 4,03 ТБ. Машины работали себе и понемногу заполняли диски. Заполнение за полгода составило в среднем на 20-30% в каждой из виртуалок.
В очередной день (естественно понедельник, который совпал еще и с первым днем долгожданного отпуска) наш сервер zabbix начал лихорадочно отправлять через телеграмм уведомления от витруалок. Сначала про отказы отдельных сервисов типа http или ssh, а потом и вовсе про потерю пингов. Полез подключаться через ssh на почтовую виртуалку, тормозит, с первых пары секунд ничего не понятно, тут прилетают еще с десяток сообщений от zabbix о проблемах других виртуалок. Боковым взглядом понимаю, что плохо у всех виртуалок, кроме самого гиперзивора. Залезаю на него и открываю консоль первой же проблемной машины.
Первым, что подумал, рассыпался soft-raid. Но почему не было уведомления на эту тема от самого гипера – раз, почему гиппер работает внешне корректно – два.
Лезу на lvm –a И вижу общие данные по pve\data
Data% — 23,51%
Meta% — 99,95%
Проверяю остальные виртуалки – лежат с такими же ошибками записи, сервисы лихорадочно дергаются в конвульсиях. Пользователи – в истерике.
Из всех вменяемых статей в гугле на эту тему – везде пишут одно и тоже средство – расширить место с помощью добавления дополнительного физического жесткого диска.
Учитывая, что попасть в наш местный форд нокс, где находится этот сервер сложновато, теряем кучу времени, отправляем атишника с флешкой на 8Гб. Через 1,5 часа он на месте, вставляет флешку, я добавляю ее в группу lvm, расширяю meta диск еще на 3 Гб командой:
И получаю в итоге Meta% — 1,58%
Перезапускаю по очереди машины, проверяя их диски и исправляя проблемы руками, т.к. некоторые (например, почтовый сервер) не захотели без проблем и исправлений по sfck запускаться по-человечески. И наконец-то решаю проблему.
Что это было, Карл? — спрашиваю я себя.
Создавая раздел Thin-LVM и добавляя его в proxmox я и не думал, что надо вручную учитывать емкость метаданных, вычислять их на калькуляторе и задавать вручную при создании диска. Почему такие важные, критичные показатели никак не мониторятся к примеру через тот же GUI Proxmox?
Ребята, если не сложно, в комментариях, очень прошу высказаться по этому поводу, что сделано не так, почему очень мало написано про создание Thin и именно про meta данные. И какие есть варианты решения проблемы помимо моего. Далеко не всегда рядом может оказаться авторизованный человек с флешкой, которого пустили в ДЦ, дали доступ в стойку, а я, находясь в отпуске за 1 тыс км, сумел-таки простоем в 2 часа решить проблему.