Thin provisioning что такое
LVM Thin Provision: опыт эксплуатации на малом объекте
Краткая вводная
О тонких томах я уже писал в более ранней статье. Производительность хорошая, слабо зависит от количества снимков, за более чем год, не было сбоев по вине именно LVM, все проблемы были созданы лично мной для себя любимого.
Грабли
Всем, кто начинает использовать тонкие тома, настоятельно рекомендуется чтение man lvmthin с пристрастием. Упущение, казалось бы, маловажного аспекта, что место в пуле томов может кончится, может привести к печальным последствиям.
Исчерпание места в Data space:
В зависимости от ФС. Обычно, после остановки io с переполненным томом, ФС остается целой, особенно если ФС журналируемая. Если вы успели расширить пул, и io-операции не успели отвалится по таймауту, то вообще все будет хорошо. Иначе откат журнала и небольшая потеря данных.
Исчерпание места в Metadata space:
Рекомендации:
Задавайте политику автоматического расширения тонких томов глобально. Задав разумные значения, вы потом сможете используя профили, настроить любую другую политику для пула. Однако, если система не применит профиль (в метаданных пула хранится имя профиля, который могли удалить), она сообщит об этом факте где-то в логах (чего можно и не заметить), но благодаря глобальной политике, все будет относительно неплохо.
LVM Thin Provision отлично работает в ситуации ленивого планирования. Это значит, что стоит под разные задачи создать пулы тонких томов разумно небольших размеров. В этих пулах создать тома, и просто наблюдать, как по мере заполнения растут размеры пулов. Выделять место сразу не стоит, не всегда можно предугадать под, что нужно место.
Размеры chunksize задавайте исходя из задачи. Большие размеры приведут к снижению накладных расходов в метаданных, но повлекут больший расход места на снимках (если совпадет с RAID5-6, то и тут бонус будет).
Zeroing — если отключить, получите чуть-чуть бонуса по скорости, но готовьтесь, в выделенных блоках может встретится всяких мусор.
Работа со снимками
Снимок создается без проблем, а вот его применение может вызвать некоторую проблему. Все дело в том, что пока том активен (хотя и не используемый), снимок к нему не применяется до следующей активации (или применяется в ленивом режиме). Поэтому, перед накатом снимка, дезактивируйте целевой том.
По умолчанию снимки создаются с флагом отмены активации. Это может обескуражить, при попытке его подключить.
Что нам стоит LVM построить (принцип работы, производительность, Thin Provision)
Не смотря на наличие нескольких статей на Хабре, про LVM2 и производительность Thin Provisioning, решил провести своё исследование, так как имеющиеся показались мне поверхностными.
Кому интересно, добро пожаловать под кат.
Немного о LVM2
Собственно, LVM это система управления дисковым пространством. Позволяет логически объединить несколько дисковых пространств (физические тома) в одно, и уже из этого пространства (Дисковой Группы или группы томов), можно выделять разделы (Логические Тома), доступные для работы. ОС получает к ним доступ через DevMapper.
Логические тома могут свободно размещаться в дисковой группе, занимая непрерывные или разрывные диапазоны адресов, или находится частично на разных дисках группы. Логические тома можно с легкостью изменять в размерах (а вот ФС не все так могут) или перемещать между дисками группы, а также создавать мгновенные снимки состояния логического тома (снапшот). Именно снапшоты и представляют главный интерес в статье.
Как вообще работает LVM
Идея тут проста, все вертится вокруг таблиц соответствия логических и физических адресов.
Общая схема такая: Физические тома отражаются на Дисковую группу. Дисковая группа отражается на Логические тома.
Снапшоты чуть иначе: собственная таблица ассоциирует блоки оригинального тома и блоки снапшота (копия блоков оригинала, до их модификации). Работает по принципу копирования при записи (CoW, делается копия блока оригинального тома, потом происходит запись этого блока в оригинальном томе). Создать снапшот от снапшота невозможно.
Тонкие тома работают чуть иначе. В группе томов создается специальный том (пул тонких томов, на самом деле состоит из двух, для данных и мета данных), из этого пула происходит выделение виртуального пространства для тонких томов. Пространство виртуально, потому как до момента реальной записи, блоки не выделяются из пула. И вообще, можно задать виртуальный размер тома, больше чем пул. Когда том распухнет до предела, система заморозит запись в него, до увеличения размеров пула. Снапшоты тут похожи на своих «толстых» братьев, но оперируют уже не блоками, а ссылками на блоки. То есть, после создания снапшота, запись в оригинал происходит так-же как и до создания снапшота (перезаписываемые блоки выделяются из пула). Есть возможность создавать снапшот от снапшота, а также можно указывать внешний том оригинала (размещенный вне тонкого пула в той же группе томов, защищенный от записи).
Производительность
Производительность толстых томов без снапшотов равна обычным дисковым разделам (разница очень мала), а как обстоят дела со снапшотами?
Тесты показали ад и ужас. Из-за CoW, операции записи в оригинальным том замедляются катастрофически! И чем больше снапшотов, тем хуже.
Несколько исправить положение дел может задание большего размера фрагмента (по умолчанию, это 4 килобайта, что дает большой объем маленьких iops). Ситуация несравнимо лучше, если писать не в оригинальный том, а в снапшот.
Тонкие тома показывают более сбалансированную картину. Скорость работы слабо зависит от числа снапшотов, и скорость значительно ниже, чем для простого толстого тома без снапшотов и близка к скорости записи в толстый снапшот. Основной вклад в тормоза дает процесс выделения места (фрагмент размером в 4 килобайта).
Методика тестирования
Надежность
Оценивать надежность я буду просто, по уровню сложности механизма доступа к информации. Чем он сложнее, тем его надежность ниже (к реальной надежности это имеет довольно далекое отношение).
Самым надежным, выглядит конечно обычный раздел. Пространство линейно, никаких промежуточных абстракций. Ломаться особо не чему. Из клёвых плюшек нет ничего.
Второе место займет Толстый Том. Появившиеся абстракции конечно не делают его надежнее, но добавляют массу гибкости. Восстанавливать данные из рассыпавшегося LVM не так уж и легко, но скорее всего, большинство томов будут размещены линейно, с небольшой фрагментацией (и эти фрагменты возможно будут крупными, вряд ли вы будете расширят разделы маленькими блоками).
Самыми ненадежными выглядят Тонкие Тома. Сложный механизм выделения места, изначально фрагментированное пространство (но не сами данные, они то как раз размещены компактно и даже линейно). Повреждение таблицы трансляции адресов, сделает данные крайне сложно читаемыми. К слову, надежность btrfs, zfs или ntfs на более худшем уровне. У тонких томов только распределение пространства в опасности, а у ФС еще и своих абстракций полно.
О производительности Thin Provision в LVM2
С версии RHEL 6.4 в LVM2 включена поддержка thin provision. На русский я бы перевёл это как «тонкое резервирование», хотя перевод неточен и совершенно не согласуется с реальностью, поэтому далее наравне с русским будет использоваться английское написание.
Thin provisioning — это создание логических томов, которые изначально используют немного места и «растут» по мере записи в них данных. В ZFS это реализовано давно по самой философии этой ФС. В VMware это используется в каждом продукте. Дошло дело до LVM2, широко применяемом в Linux в наши дни. Также одним из основных нововведений является thin snapshots, когда для снэпшотов нет необходимости резервировать место заранее, а он «растёт» вместе с изменёнными данными. Также разрешаются и поощряются вложенные снэпшоты (снэпшоты снэпшотов c любой глубиной), при этом заявляется об отсутствии при этом падения производительности. О нескольких нюансах использования будет рассказано в статье.
Меня больше интересовали не снэпшоты, а производительность «тонких логических томов» (Thin Logical Volume) для использовании на серверах. Для нетерпеливых скажу сразу — падение производительности наблюдается, и существенное. Подробности ниже.
На одном и том же сервере с CentOS 6.4 2.6.32-279.2.1.el6.x86_64 на RAID1 сделанном при помощь mdadm, создаём «пул тонкого резервирования» (thin pool):
и обычный логический том (LV):
Измерим производительности линейного чтения и записи на эти устройства:
Thin pool:
Запись:
Чтение:
Как видно производительность при этом не различается для LV и thin pool.
Создаём thin volume (тонкий логический том) в thin pool
Запись:
Чтение:
Очень хорошо заметно, что линейная запись на 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 диск.
Запись:
Чтение:
Thin LV:
Запись:
Чтение:
Производительность случайной записи измерить не удалось.
И снова наблюдаем падение скорости линейной записи в два раза, как и в предыдущем тесте. Возможно это связано с нюансами виртуальной машины.
UPDATE: Произвёл ещё одно тестирование на «чистом» сервере без RAID и вирт.машин. Падение производительности линейной записи не наблюдается! Прошу прощения уважаемой аудитории за введение в заблуждение в связи с однобокостью тестирования в первые два теста. В результате считаю необходимо тестировать производительность для каждого конкретного случая.
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 если нужно очистить место быстро, либо подождать несколько минут пока изменения фактически применятся на диск сами).
Thin Provisioning — «кредитная карта» для хранилища
Вот уже около 20 лет назад в жизнь IT-отделов компаний вошло понятие SAN — Storage Area Network или специализированная сеть устройств хранения данных. Использование централизованных хранилищ, на которых размещаются используемые на серверах приложений их дисковые разделы, подключенные по специальным высокоскоростным протоколам, позволило значительно повысить эффективность и гибкость использования дискового пространства.
Причины, стоявшие за созданием SAN, отчасти были теми же, что стояли ранее за созданием обычной локальной сети LAN и shared-устройств в ней. Вместо того, чтобы давать каждому клиентскому компьютеру по лазерному принтеру, который будет простаивать в 99% времени, лучше дадим ему доступ к коллективно используемому принтеру, пусть более мощному и дорогому, но используемому с более высокой средней загрузкой, и тем самым повысим уровень использования ресурса и его экономическую эффективность.
В том числе использование «общего дискового ресурса» решило и проблему «недоиспользования». Если минимально доступный диск SATA на сегодня обычно не менее 500GB, то если мы не используем его для хранения накачанного из торрентов видео, то обычно, в рядовом использовании, он пуст на 90-95%. Типовая установка OS занимает 2-8 GB, приложения и его данные еще сколько-то, чаще всего несколько гигабайт, все же остальное пространство остается свободным, но увы, недоступным для, возможно, нуждающихся задач на других компьютерах.
Так было до тех пор пока не появилась Storage Area Network — SAN — специальная сеть для хранения и передачи данных. В этой сети используется специальный высокоскоростной протокол передачи данных, например FC или iSCSI, который позволяет использовать дисковое пространство с централизованного устройства хранения, без значительных потерь доступности и быстродействия, нарезав и раздав потребителям участки общего пространства нужного им размера, словно это локальные диски данного компьютера, а не разделы на большом общем сторадже.
Однако, отчасти решив использованием SAN проблему provisioning-а пространства хранения для приложений, мы все же вновь столкнемся с ней, правда на новом уровне.
Дело в том, что в практической жизни системный администратор никогда не «нарежет» приложению раздел ровно по запрошенному или занимаемому им пространству, так как всегда нужно пространство на внезапное увеличение объемов, рост базы, в случае базы данных, место под логи для вебсервера, и так далее. Закон природы сегодняшнего дня состоит в том, что объемы информации растут, и, подчас, растут экспоненциально.
Поэтому ничего удивительного, что на дисковых разделах в SAN (обычно их называют LUN) весьма значительное место бывает распределено, но не занято данными соответствующего приложения, однако и для других, более нуждающихся приложений, уже более недоступно.
Для того, чтобы не начинать каждый день с увеличения разделов данных, и не сталкиваться с неожиданно «упавшей» из за исчерпания места задачей, любой администратор системы хранения создает разделы данных на SAN «с запасом», подчас значительным, так, в результатах соответствующего исследования мне встречалось упоминание, что до 60-80% пространства на SAN-хранилищах это распределенное «на будущее», но ничем настоящее время не занятое место.
Таким образом, всего лишь найдя и использовав способ динамически выделять место на дисках SAN-системы, мы можем, в общем случае, экономить до 60-80% пространства, причем дорогостоящего, быстродействующего дискового пространства, бесполезно «похороненного» в настоящий момент в «нарезанных» LUN-ах «про запас».
Методика выделения пространства хранения приложениям не сразу при создании диска, а по мере возникновения в нем потребности у данных приложения, «on demand», получило название «thin provisioning». К сожалению на русском языке все еще нет общепринятого перевода, поэтому я предпочитаю называть это «экономное распределение».
Как ни удивительно, но с принципом thin provisioning вы широко знакомы в быту.
Так, например, работает кредит в банке. Когда банк выдает десять тысяч кредитных карточек с кредитным лимитом в 500 тысяч, он не хранит в обеспечение на счетах пять миллиардов, так как рассчитывает, что пользователи карточек не станут немедленно тратить все предоставленные им по кредиту деньги, иначе у банка просто бы не хватило активов. Тем не менее, когда это необходимо, вы сможете воспользоваться подлимитной суммой, если общий «пул» средств банка не исчерпан.
Также работают водопроводные и электрические компании, предоставляя вам ресурс они полагают, что весь многоэтажный дом не станет разом открывать краны или включат стиральные машины и электрические чайники, а за счет более гибкого расхода удается сэкономить на цене ресурсов и мощности инфраструктуры.
Точно также работают многозадачные OS и системы виртуализации. Вы можете использовать множество программ одновременно, с условием, что они не захотят одновременно, в одно и то же время, загрузить процессор полностью. Общие ресурсы процессора выделяются приложению по мере необходимости, но каждая программа при этом «питает иллюзию», что ей доступны все 12 ядер вашего нового сервера. Это действительно так, но не разом для всех.
Точно также складывается ситуация при использовании thin provisioning. Если программа желает иметь раздел данных размером 50GB (даже несмотря на то, что в данный момент у нее есть на нем всего 10GB данных), то мы можем предоставить ей раздел, видимый приложением как раздел размером 50GB, однако 40 из них будут «виртуальными», не занимая в этот момент места на дисках системы, пока в них не будут записаны реальные данные. Это позволит нам не «запирать» место «про запас», а использовать его по мере возникновения в нем необходимости.
Насколько мне известно, первой принцип thin provisioning в SAN начала использовать в своих системах хранения недавно купленная HP компания 3Par, у которой эта возможность была ключевой (да и практически единственной) «фишкой» их систем, однако, в числе первых, thin provisioning реализовала и NetApp в своих системах FAS. Для вас должно быть уже не сюрприз, что так просто и быстро (фактически — с новым релизом обновления внутренней OS) это появилось в уже существующих системах потому, что уже не раз помянутая добрым словом, созданная в 1993 году NetApp «файловая система WAFL», лежащая в основе всех систем хранения NetApp, позволила это сделать очень легко и просто.
ВСЕ свободное место на дисках системы хранения, использующей thin provisioning, доступно для увеличения пространства ВСЕМ LUN-ам, любого приложения. Место на дисках сетевой системы хранения становится по настоящему совместно используемым ресурсом.
Не попадите в плен не вполне верной визуализации, при увеличении занятого объема приложением А, данные других приложений не перемещаются по дискам, просто разделу приложения А выделяются и добавляются дополнительные сегменты дискового пространства, лежащие в области свободного места. Теоретически это увеличивает фрагментацию данных, но практически негативным эффектом от него можно пренебречь, так как выделение пространства осуществляется сравнительно протяженными кусками мегабайтного порядка, и, как показывает практика, разница в производительности между thin и thick-данными обычно «ниже измеряемого уровня».
Таким образом, использование thin provisioning позволяет решить проблему неэффективного распределения пространства в SAN, сэкономить место, облегчить админские процедуры распределения пространства приложениям на хранилище, и использовать так называемый oversubscribing, то есть выделить приложениям места больше, чем мы располагаем физически, в резонном расчете на то, что пространство приложениями не затребуется одновременно. По мере же возникновения в нем потребности мы сможем позже легко увеличить физическую емкость хранилища.