Недавно я начал использовать LVM на своих серверах для жестких дисков размером более 1 ТБ. Это полезная технология, расширяемая и довольно проста в установке. Однако мне не удалось найти никаких данных о недостатках и уязвимостях LVM.
Каковы недостатки использования LVM?
Ответ 1
Риски использования LVM:
Уязвим для записи проблем с кешированием с гипервизором SSD или виртуальной машины
Сложнее восстановить данные из-за более сложных структур данных файловой системы
Труднее изменить размер файловой системы
Снапшоты сложно использовать, они медленные и могут содержать ошибки
Требуются определенные навыки для правильной настройки с учетом этих проблем
Первые две проблемы LVM сочетаются: если кэширование записи работает некорректно и у вас произошло отказ питания (например, сбой блока питания или ИБП), вам вполне может потребоваться восстановление из резервной копии, что означает значительное время простоя. Основной причиной использования LVM является более высокое время безотказной работы (при добавлении дисков, изменении размера файловых систем и т. д.), Но важно правильно настроить кэширование записи, чтобы LVM фактически не сокращал время безотказной работы.
Снижение рисков
LVM по-прежнему может работать хорошо, если вы:
Правильно настройте кэширование записи в гипервизоре, ядре и твердотельных накопителях
Избегайте снапшотов LVM
Используйте последние версии LVM для изменения размера файловых систем
Делайте чаще резервные копии
Подробности
Я довольно часто использовал эту технологию, испытав в том числе, потери данных, связанную с LVM. Основные риски и проблемы LVM, о которых я знаю:
Уязвим к кэшированию записи на жесткий диск из-за гипервизоров виртуальных машин, дискового кэширования или старых ядер Linux, а также затрудняет восстановление данных из-за более сложных структур на диске. Бывает, что настройки LVM на нескольких дисках были повреждены без каких-либо шансов на восстановление, а LVM плюс кэширование записи на жесткий диск - опасная комбинация.
Кэширование записи и изменение порядка записи на жесткий диск важны для хорошей производительности, но могут не сбрасывать буферы на диск правильно из-за гипервизоров виртуальных машин, кэширования записи на жесткий диск, старых ядер Linux и т. д.
Барьеры записи означают, что ядро гарантирует, что оно завершит определенные операции записи на диск до «барьерной» записи на диск, чтобы файловые системы и RAID массивы могли восстановиться в случае внезапного отключения питания или сбоя. Такие барьеры могут использовать операцию FUA (Force Unit Access) для немедленной записи определенных блоков на диск, что более эффективно, чем полная очистка кеша. Барьеры могут быть объединены с эффективной организацией очереди тегированных/собственных команд (выдача нескольких запросов ввода-вывода одновременно), чтобы жесткий диск мог выполнять интеллектуальное изменение порядка записи без увеличения риска потери данных.
Гипервизоры виртуальных машин могут иметь аналогичные проблемы: запуск LVM в гостевой системе Linux поверх гипервизора виртуальной машины, такого как VMware, Xen , KVM, Hyper-V или VirtualBox, может создавать проблемы, аналогичные ядру без барьеров записи, из-за кэширования записи и перезаписи. Внимательно проверьте документацию вашего гипервизора на предмет наличия возможности «сбросить на диск» или кеширования со сквозной записью (присутствует в KVM, VMware, Xen, VirtualBox и других) - и протестируйте его с вашими настройками.
Корпоративные серверы с LVM всегда должны использовать RAID-контроллер с батарейным питанием и отключать кэширование записи на жесткий диск (контроллер имеет кеш-память записи с батарейным питанием, который является быстрым и безопасным).
Если у вас нет RAID-контроллера с батарейным питанием, отключение кэширования записи на жесткий диск значительно замедлит запись, но сделает LVM безопасным. Вы также должны использовать эквивалент data=ordered опции ext3 (или data=journal для дополнительной безопасности), и barrier=1 чтобы убедиться, что кеширование ядра не влияет на целостность. (Или используйте ext4, которая по умолчанию включает барьеры). Это самый простой вариант, обеспечивающий хорошую целостность данных за счет производительности.
Чтобы отключить кэширование записи на жесткий диск: добавьте hdparm -q -W0 /dev/sdX для всех дисков /etc/rc.local (для SATA) или используйте sdparm для SCSI/SAS. Однако, согласно записи в FAQ XFS, диск SATA может потерять эту настройку после восстановления ошибки диска - поэтому вам следует использовать SCSI/SAS, или, если вы должны использовать SATA, то поместите hdparm в задании cron, выполняемом примерно раз в минуту.
Если вы используете диски расширенного формата, то есть физические сектора размером 4 КБ, отключение кэширования записи может вызвать другие проблемы.
ИБП важен как для предприятий, так и для SOHO, но недостаточен для обеспечения безопасности LVM: все, что вызывает серьезный сбой или потерю питания (например, отказ ИБП, сбой блока питания или разряд батареи ноутбука), может привести к потере данных в кэше жестких дисков.
Очень старые ядра Linux (2.6.x с 2009 года): в очень старых версиях ядра, 2.6.32 и более ранних, отсутствует полная поддержка барьера записи. Если эти старые ядра 2.6 не исправлены для устранения этих проблем, большой объем метаданных FS (включая журналы) могут быть потеряны из-за критического сбоя, который оставляет данные в буферах записи жестких дисков (скажем, 32 МБ на диск для обычных дисков SATA). Потеря 32 МБ последних записанных метаданных FS и данных журнала, которые, по мнению ядра, уже находятся на диске, обычно означает серьезное повреждение файловой системы и, следовательно, потерю данных.
Резюме: вы должны позаботиться о файловой системе, RAID, гипервизоре виртуальной машины и настройке HDD/SSD, используемых с LVM. У вас должны быть очень свежие резервные копии, если вы используете LVM, и обязательно сделайте резервную копию метаданных LVM, настройки физического раздела, MBR и загрузочных секторов тома. Также рекомендуется использовать диски SCSI/SAS, поскольку они с меньшей вероятностью сбоят о том, как они выполняют кэширование записи - для использования дисков SATA требуется больше осторожности.
Сохранение кэширования записи включенным
Более сложный, но эффективный вариант - оставить включенным кэширование записи SSD/HDD и полагаться на барьеры записи ядра, работающие с LVM в ядре 2.6.33+ (дважды проверьте, посмотрев «барьерные» сообщения в журналах).
Вы также должны убедиться, что в настройке RAID, настройке гипервизора виртуальной машины и файловой системе используются барьеры записи (т. е. требуется, чтобы диск сбрасывал ожидание записи до и после метаданных/записей журнала). XFS по умолчанию использует барьеры, а ext3 – нет, поэтому с ext3 вы должны использовать barrier=1 в параметрах монтирования и по-прежнему использовать data=ordered или, data=journal как указано выше.
К сожалению, некоторые жесткие диски и твердотельные накопители сбоят при сбросе своего кеша на диск (особенно старые диски, но в том числе некоторые диски SATA и некоторые корпоративные твердотельные накопители).
Более поздние диски SATA, поддерживающие Native Command Queuing(NCQ), хорошо работают без кэширования записи из-за NCQ.
Накопители SCSI/SAS более надежны, поскольку для нормальной работы им не требуется кэширование записи (через SCSI Tagged Command Queuing, аналогично SATA NCQ).
Если ваши жесткие диски или твердотельные накопители некорректны при сбросе своего кеша на диск, вы не можете полагаться на барьеры записи и должны отключить кеширование записи. Это проблема для всех файловых систем, баз данных, менеджеров томов и программного RAID, а не только для LVM.
Твердотельные накопители проблематичны, потому что использование кеша записи критично для срока службы SSD. Лучше всего использовать SSD с суперконденсатором (чтобы включить очистку кеша при сбое питания и, следовательно, включить обратную запись в кеш, а не сквозную запись).
Большинство корпоративных твердотельных накопителей должны подходить для управления кешем записи, а некоторые включают в себя суперконденсаторы.
У некоторых более дешевых твердотельных накопителей есть проблемы, которые нельзя исправить с помощью конфигурации кэша записи. Потребительские твердотельные накопители могут иметь серьезные проблемы с кэшированием записи, которые вызывают потерю данных, и не содержат суперконденсаторов, поэтому уязвимы для сбоев питания, вызывающих повреждение.
Настройка диска Advanced Format - кэширование записи, выравнивание, RAID, GPT
С новыми дисками расширенного формата, которые используют физические сектора 4 КБ, может быть важно оставить включенным кэширование записи на диски, поскольку большинство таких дисков в настоящее время имитируют 512-байтовые логические сектора ( «эмуляция 512»), а некоторые даже заявляют, что имеют 512-байтовые физические сектора, в то время как реально используется 4 КБ.
Отключение кеша записи на диске расширенного формата может вызвать очень большое влияние на производительность, если приложение/ядро выполняет запись размером 512 байт, поскольку такие диски полагаются на кэш для накопления 8 x 512-байтовых операций записи перед выполнением одной физической записи размером 4 КБ. Рекомендуется провести тестирование, чтобы подтвердить любое влияние, если вы отключите кеш.
Выравнивание LV на границе 4 КБ важно для производительности, но должно происходить автоматически, пока базовые разделы для PV выровнены, поскольку физические экстенты LVM (PE) по умолчанию составляют 4 МБ. Здесь необходимо разместить суперблок RAID в конце тома и (при необходимости) использовать опцию pvcreate для выравнивания PV.
Разделение GPT с помощью Advanced Format требует осторожности, особенно для загрузочных и корневых дисков, чтобы гарантировать, что первый раздел LVM (PV) начинается на границе 4 КБ.
Сложнее восстановить данные из-за более сложных структур на диске:
Любое восстановление данных LVM, необходимое после серьезного сбоя или потери питания (из-за неправильного кэширования записи), в лучшем случае является ручным процессом, потому что, очевидно, нет подходящих инструментов. LVM хорошо выполняющих резервное копирование своих метаданных /etc/lvm, что может помочь восстановить базовую структуру LV, VG и PV, но не поможет с потерянными метаданными файловой системы.
Следовательно, вероятно, потребуется полное восстановление из резервной копии. Это приводит к гораздо большему времени простоя, чем быстрый журнал fsck, когда LVM не используется, и данные, записанные с момента последней резервной копии, будут потеряны.
TestDisk, ext3grep, ext3undel и другие инструменты могут восстанавливать разделы и файлы с дисков без LVM, но они не поддерживают восстановление данных LVM напрямую. TestDisk может обнаружить, что потерянный физический раздел содержит LVM PV, но ни один из этих инструментов не распознает логические тома LVM. Инструменты вырезания файлов, такие как PhotoRec и многие другие, будут работать, поскольку они обходят файловую систему для повторной сборки файлов из блоков данных, но это крайний вариант, низкоуровневый подход для ценных данных, который хуже работает с фрагментированными файлами.
В некоторых случаях восстановление LVM вручную возможно, но это сложно и требует много времени.
Труднее правильно изменить размер файловой системы - простое изменение размера файловой системы часто является преимуществом LVM, но вам нужно запустить полдюжины команд оболочки для изменения размера FS на основе LVM - это можно сделать, когда весь сервер все еще работает, а в некоторых случаях с смонтированной FS, но я бы никогда не стал рисковать последним без актуальных резервных копий и использования команд, предварительно протестированных на эквивалентном сервере (например, клон производственного сервера для аварийного восстановления).
Моментальные снимки трудны в использовании, медленны и могут содержать ошибки - если для моментального снимка заканчивается заранее выделенное пространство, он автоматически удаляется. Каждый моментальный снимок данного LV представляет собой дельту по отношению к этому LV (не по сравнению с предыдущими моментальными снимками), для чего может потребоваться много места при создании моментальных снимков файловых систем (каждый моментальный снимок больше предыдущего). Безопасно создать снимок LV того же размера, что и исходный LV, так как в этом случае в моментальном снимке никогда не закончится свободное пространство.
Снимки также могут быть очень медленными (то есть в 3-6 раз медленнее, чем без LVM). Отчасти медлительность объясняется тем, что для создания снимков требуется много синхронных операций записи.
Альтернативы моментальным снимкам - файловые системы и гипервизоры виртуальных машин
Снимки VM/Cloud:
Если вы используете гипервизор виртуальной машины или облачного провайдера IaaS (например, VMware, VirtualBox или Amazon EC2 / EBS), их моментальные снимки часто являются гораздо лучшей альтернативой моментальным снимкам LVM. Вы можете довольно легко сделать снимок для резервного копирования.
Снимки файловой системы:
Снимки на уровне файловой системы с ZFS или btrfs просты в использовании и, как правило, лучше, чем LVM, если вы работаете на «голом железе» (но ZFS кажется намного более лучшим решением):
ZFS: теперь существует реализация ZFS в ядре, которая использовалась в течение нескольких лет, и ZFS, похоже, получает распространение. Ubuntu теперь имеет ZFS как вариант «из коробки», включая экспериментальную ZFS в корневом.
btrfs: все еще не готов к производственному использованию ( даже на openSUSE, который поставляется по умолчанию и имеет команду, посвященную btrfs), тогда как RHEL прекратил его поддерживать). btrfs теперь имеет инструмент fsck , но вам необходимо проконсультироваться с разработчиком.
Снимки для онлайн-резервного копирования и fsck
Снимки можно использовать для обеспечения согласованности резервных копий, если вы будете осторожны с выделенным пространством (в идеале снимок имеет тот же размер, что и резервный LV). Превосходный rsnapshot(начиная с 1.3.1) даже управляет созданием/удалением моментальных снимков LVM. Однако обратите внимание на общие проблемы со снимками и то, что снимок не следует рассматривать как резервную копию.
Вы также можете использовать моментальные снимки LVM для онлайн-fsck: снимок LV и снимок fsck, при этом все еще используя основную FS, поэтому лучше использовать e2croncheck.
Вы должны временно «заморозить» файловую систему во время создания снимка - некоторые файловые системы, такие как ext3 и XFS, сделают это автоматически, когда LVM создаст снимок.
Выводы
Несмотря на все это, я все еще использую LVM в некоторых системах, но для настольных систем я предпочитаю необработанные разделы. Основное преимущество LVM, которое я вижу, - это гибкость перемещения и изменения размера файловых систем, когда вам необходимо иметь время безотказной работы на сервере - если вам это не нужно, gparted проще и имеет меньший риск потери данных.
LVM требует большой осторожности при настройке кэширования записи из-за гипервизоров виртуальных машин, кэширования записи на HDD/SSD и т. д. - но то же самое относится к использованию Linux в качестве сервера БД. Отсутствие поддержки со стороны большинства инструментов ( gparted включая вычисления критического размера и testdisk т. д.) Затрудняет использование.
Если вы используете LVM, будьте очень осторожны со снимками: используйте снимки VM/Cloud, если это возможно, или исследуйте ZFS/btrfs.
Итог: если вы не знаете о проблемах, перечисленных выше, и о том, как их решать, лучше не использовать LVM.
Ответ 2
Если вы планируете использовать моментальные снимки для резервного копирования - будьте готовы к серьезному падению производительности при наличии моментального снимка, в остальном все нормально. Я использую lvm в продакшене пару лет на десятках серверов, хотя моя основная причина использовать его - это атомарный снимок, а не возможность легко расширять тома.
Кстати, если вы собираетесь использовать диск емкостью 1 ТБ, помните о выравнивании разделов - у этого диска, скорее всего, есть физические сектора размером 4 КБ.
Ответ 3
Еще одно преимущество: вы можете добавить новый физический том (PV), переместить все данные в этот PV, а затем удалить старый PV без каких-либо перерывов в обслуживании. Я использовал эту возможность как минимум четыре раза за последние пять лет.
Недостаток, который я еще заметил: для LVM2 довольно сложный процесс обучения. В основном в абстракции, которую он создает между вашими файлами и «железом». Если вы работаете в небольшой команде, которые разделяют обязанности на одном наборе серверов, вы можете столкнуться с дополнительными сложностями, которые непосильны для вашей команды в целом. В более крупных командах, занимающихся ИТ-работой, такой проблемы обычно не возникает.
Особо следует отметить одно предостережение: если вы загружаетесь с логического тома LVM2, вы усложняете операции восстановления в случае сбоя сервера.
Linux
