Вопросы Теги

Опасности LVM и протесты

Karl B является правильной апачской страницей состояния, поможет Вам много. Проверьте, не ли запрос зарегистрирован errorlog. Могло случиться так, что количество активного запроса достигло максимального количества, указанного в апачском конфигурационном файле. Посмотрите, является ли MaxClients более крупным, чем:

sudo netstat -tnp|egrep -c 'apache|http'
191
задан 1 September 2011 в 23:03
6 ответов

Сводка

Риски использования LVM:

  • Уязвимый для записи кэширующихся проблем с SSD или гипервизором VM
  • Тяжелее восстановить данные из-за более сложных дисковых структур
  • Тяжелее изменить размер файловых систем правильно
  • Снимки трудно использовать, замедлиться и багги
  • Требует, чтобы некоторый навык настроил правильно, учитывая эти проблемы

Первые два объединения проблем LVM: если кэширование записи не работает правильно, и у Вас есть потери мощности (например, PSU или сбои UPS), Вам, вероятно, придется восстановиться с резервного копирования, имея в виду значительное время простоя. Основной причиной для использования LVM является более высокое время работы (при добавлении дисков, изменении размеров файловых систем, и т.д.), но важно получить настройки кэширования записи, корректные для предотвращения LVM, на самом деле уменьшающего время работы.

- Обновленный декабрь 2019: незначительное обновление на btrfs и ZFS как альтернативы снимкам LVM

Снижение рисков

LVM может все еще работать хорошо если Вы:

  • Разберитесь в своей установке кэширования записи в гипервизоре, ядре и SSD
  • Избегайте снимков LVM
  • Используйте недавние версии LVM для изменения размеров файловых систем
  • Имейте хорошие резервные копии

Подробнее

Я исследовал это вполне немного в прошлом, испытывавшем некоторую потерю данных, связанную с LVM. Основные риски LVM и проблемы, о которых я знаю:

Уязвимый для записи жесткого диска, кэширующейся из-за гипервизоров VM, кэширования диска или старых ядер Linux, и, мешает восстанавливаться, данные из-за более сложных дисковых структур - видят ниже для деталей. Я видел, что полные установки LVM на нескольких дисках повреждаются без любого шанса восстановления, и LVM плюс кэширование записи жесткого диска является опасной комбинацией.

  • Запишите кэширование, и переупорядочение записи жестким диском важно для хорошей производительности, но может не сбросить блоки к диску правильно из-за гипервизоров VM, кэширования записи жесткого диска, старых ядер Linux, и т.д.
    • Запишите, что барьеры означают, что ядро гарантирует, что завершит определенные записи на диск перед записью на диск "барьера", чтобы гарантировать, что файловые системы и RAID могут восстановиться в случае внезапных потерь мощности или катастрофического отказа. Такие барьеры могут использовать FUA (Доступ Единицы Силы) операция для непосредственной записи определенных блоков в диск, который более эффективен, чем полная очистка кэша. Барьеры могут быть объединены с эффективной теговой / организацией очередей собственных команд (выпускающий несколько диск запросы ввода-вывода сразу), чтобы позволить жесткому диску выполнить интеллектуальное переупорядочение записи, не увеличивая риск потери данных.
  • Гипервизоры VM могут иметь подобные проблемы: выполняя LVM в госте Linux сверху гипервизора VM, такого как VMware, Xen, KVM, Hyper-V или VirtualBox могут создать подобные проблемы к ядру без барьеров записи, должных записать переупорядочение записи и кэширование. Проверьте свою документацию гипервизора тщательно на "сброс к диску" или записи - через опцию кэша (существующий в KVM, VMware, Xen, VirtualBox и других) - и протестируйте его с Вашей установкой. Некоторые гипервизоры, такие как VirtualBox имеют настройку по умолчанию, которая игнорирует любые дисковые сбросы от гостя.
  • Серверы предприятия с LVM должны всегда использовать RAID-контроллер с аварийным батарейным питанием и отключать кэширование записи жесткого диска (контроллер имеет кэш записи с аварийным батарейным питанием, который быстр и безопасен) - см. этот комментарий автора этой записи FAQ XFS. Может также быть безопасно выключить барьеры записи в ядре, но тестирование рекомендуется.
  • Если у Вас не будет RAID-контроллера с аварийным батарейным питанием, то запрещение кэширования записи жесткого диска значительно замедлит записи, но сделает сейф LVM. Необходимо также использовать эквивалент ext3 data=ordered опция (или data=journal для дополнительной безопасности), плюс barrier=1 гарантировать, что кэширование ядра не влияет на целостность. (Или используйте ext4, который включает барьеры по умолчанию.) Это - самая простая опция и обеспечивает хорошую целостность данных за счет производительности. (Linux изменил значение по умолчанию ext3 опция к более опасному data=writeback некоторое время назад не полагайтесь на настройки по умолчанию для FS),
  • Отключить кэширование записи жесткого диска: добавить hdparm -q -W0 /dev/sdX для всех дисков в /etc/rc.local (для SATA) или использование sdparm для SCSI/SAS. Однако согласно этой записи в FAQ XFS (который очень хорош по этой теме), диск SATA может забыть эту установку после восстановления ошибки диска - таким образом, необходимо использовать SCSI/SAS, или если необходимо использовать SATA, затем помещает команду hdparm в задание крона, работающее каждую минуту или около этого.
  • Для хранения SSD / кэширование записи жесткого диска включило для лучшей производительности: это - сложная область - посмотрите раздел ниже.
  • При использовании Усовершенствованных дисков Формата т.е. физических секторов на 4 КБ посмотрите ниже - запрещающий кэширование записи, может иметь другие проблемы.
  • UPS очень важен и для предприятия и для SOHO, но недостаточно сделать сейф LVM: что-либо, что вызывает трудный катастрофический отказ или потери мощности (например, отказ UPS, отказ PSU или исчерпание аккумулятора для ноутбука) может потерять данные в кэшах жесткого диска.
  • Очень старые ядра Linux (2.6.x с 2009): в очень старых версиях ядра существует неполная поддержка барьера записи, 2.6.32 и ранее (2.6.31 имеет некоторую поддержку, в то время как 2.6.33 работ для всех типов цели устройства) - RHEL 6 использует 2.6.32 со многими патчами. Если эти старые 2,6 ядра не исправляются для этих проблем, большая сумма метаданных FS (включая журналы) могла быть потеряна трудным катастрофическим отказом, который уезжает, данные в буферах записи жестких дисков (скажите что 32 МБ за диск для общих дисков SATA). Потеря 32 МБ последний раз записанных метаданных FS и данных журнала, которые думает ядро, уже находится на диске, обычно средства большое повреждение FS и следовательно потеря данных.
  • Сводка: необходимо заботиться в файловой системе, RAID, гипервизоре VM и жестком диске / установка SSD, используемая с LVM. У Вас должны быть очень хорошие резервные копии при использовании LVM, и убеждаться конкретно создать резервную копию метаданных LVM, физической установки раздела, MBR и загрузочных секторов объема. Также желательно использовать диски SCSI/SAS, поскольку они, менее вероятно, будут лгать, как они действительно пишут кэширование - больше ухода требуется, чтобы использовать диски SATA.

Хранение кэширования записи включило для производительности (и преодоление лежащих дисков)

Более сложная, но производительная опция состоит в том, чтобы сохранить SSD / кэширование записи жесткого диска включило, и полагайтесь на барьеры записи ядра, работающие с LVM на ядре 2.6.33 + (перепроверка путем поиска сообщений "барьера" в журналах).

Необходимо также удостовериться, что установка RAID, установка гипервизора VM и барьеры записи использования файловой системы (т.е. требует диска сбросить незаконченные записи прежде и после ключевых записей метаданных/журнала). XFS действительно использует барьеры по умолчанию, но ext3 не делает, таким образом, с ext3 необходимо использовать barrier=1 в опциях монтирования, и все еще используют data=ordered или data=journal как выше.

SSD проблематичны, потому что использование кэша записи очень важно для времени жизни SSD. Лучше использовать SSD, который имеет суперконденсатор (для включения сбрасывания кэша на сбое питания, и следовательно позвольте кэшу быть обратной записью не, пишут - через).

Усовершенствованная установка диска Формата - кэширование записи, выравнивание, RAID, GPT

  • С более новыми Усовершенствованными дисками Формата, которые используют физические секторы на 4 кибибайта, может быть важно сохранить кэширование записи диска включенным, так как большинство таких дисков в настоящее время эмулирует 512-байтовые логические секторы ("512 эмуляций"), и некоторые даже утверждают, что имели 512-байтовые физические секторы при реальном использовании 4 кибибайт.
  • Выключение кэша записи Усовершенствованного диска Формата может вызвать очень большое влияние производительности, если приложение/ядро делает 512 побайтовых записей, диски как таковые полагаются на кэш для накопления 8 x 512 побайтовых записей прежде, чем сделать единственную физическую запись на 4 кибибайта. Тестированию рекомендуют подтвердить любое влияние при отключении кэша.
  • Выравнивание LVs на границе на 4 кибибайта важно для производительности, но должно произойти автоматически, пока базовые разделы для PVs выровненные, начиная с LVM, Физические Степени (PE) составляют 4 мебибайт по умолчанию. RAID нужно рассмотреть здесь - эта страница установки LVM и программного обеспечения RAID предлагает поместить суперблок RAID в конце объема и (при необходимости) использовать опцию на pvcreate выровнять PVs. Этот поток почтовой рассылки LVM указывает на работу, сделанную в ядрах в течение 2011 и проблемы частичных записей блока при смешивании дисков с 512-байтовыми и секторами на 4 кибибайта в единственном LV.
  • GPT, делящий с Усовершенствованной осторожностью о потребностях Формата, специально для boot+root дисков, для обеспечения первый раздел LVM (PV), запускается на границе на 4 кибибайта.

Тяжелее восстановить данные из-за более сложных дисковых структур:

  • Любое восстановление данных LVM, требуемых после трудного катастрофического отказа или потерь мощности (из-за неправильного кэширования записи), является ручным процессом в лучшем случае потому что нет, по-видимому, никаких подходящих инструментов. LVM способен создавать резервную копию своих метаданных под /etc/lvm, который может помочь восстановить базовую структуру LVs, VGs и PVs, но не поможет с потерянными метаданными файловой системы.
  • Следовательно полное восстановление от резервного копирования, вероятно, будет требоваться. Это включает намного больше времени простоя, чем быстрый основанный на журнале fsck если не с помощью LVM и данных, записанных, так как последнее резервное копирование будет потеряно.
  • TestDisk, ext3grep, ext3undel и другие инструменты может восстановить разделы и файлы от non-LVM дисков, но они непосредственно не поддерживают восстановление данных LVM. TestDisk может обнаружить, что потерянный физический раздел содержит PV LVM, но ни один из этих инструментов не понимает логических томов LVM. Инструменты вырезания файла, такие как PhotoRec и многие другие работали бы, поскольку они обходят файловую систему, чтобы повторно собрать файлы от блоков данных, но это - последнее средство, подход низкого уровня для ценных данных, и работает менее хорошо с фрагментированными файлами.
  • Ручное восстановление LVM является возможным в некоторых случаях, но является сложным и трудоемким - видят этот пример и это, это и это для того, как восстановиться.

Тяжелее для изменения размеров файловых систем правильно - легкое изменение размеров файловой системы часто дается как преимущество LVM, но необходимо работать, полдюжины команд оболочки для изменения размеров LVM основывали FS - это может быть сделано с целым сервером все еще, и в некоторых случаях с FS смонтировался, но я никогда не буду рисковать последним без актуальных резервных копий и использующих команд, предварительно протестированных на эквивалентном сервере (например, клон аварийного восстановления рабочего сервера).

  • Обновление: Более поздние версии lvextend поддерживайте -r (--resizefs) опция - если это доступно, это - более безопасный и более быстрый способ изменить размер LV и файловой системы, особенно если Вы уменьшаете FS, и можно главным образом пропустить этот раздел.
  • Большинство руководств по изменению размеров основанного на LVM FSS не принимает во внимание то, что FS должен быть несколько меньшим, чем размер LV: подробное объяснение здесь. При уменьшении файловой системы необходимо будет указать, что новый размер к FS изменяет размер инструмента, например. resize2fs для ext3, и к lvextend или lvreduce. Без большого ухода размеры могут немного отличаться из-за различия между 1 ГБ (10^9) и 1 гибибайтом (2^30), или способ, которым различные инструменты округляют в большую сторону размеры или вниз.
  • Если Вы не делаете вычислений, точно правильных (или используете некоторые дополнительные шаги вне самых очевидных), можно закончить с FS, который является слишком большим для LV. Все будет казаться прекрасным в течение многих месяцев или лет, пока Вы полностью не заполните FS, в которой точке Вы получите серьезное повреждение - и если Вы не будете знать об этой проблеме, трудно узнать, почему, поскольку у Вас могут также быть реальные ошибки диска к тому времени то облако ситуация. (Возможно, что эта проблема только влияет на сокращение размера файловых систем - однако, ясно, что изменение размеров файловых систем в любом направлении действительно увеличивает риск потери данных, возможно из-за пользовательской ошибки.)

  • Кажется, что размер LV должен быть больше, чем размер FS 2 x размер физической степени (PE) LVM - но проверить ссылку выше на детали, поскольку источник для этого не является авторитетным. Часто разрешение 8 мебибайт достаточно, но может быть лучше позволить больше, например, 100 мебибайт или 1 гибибайт, только быть безопасным. Проверять размер PE и Ваши логические volume+FS размеры, с помощью 4 кибибайт = 4 096-байтовые блоки:

    Шоу размер PE в кибибайте:
    vgdisplay --units k myVGname | grep "PE Size"

    Размер всего LVs:
    lvs --units 4096b

    Размер (ext3) FS, принимает FS на 4 кибибайта blocksize:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • В отличие от этого, установка non-LVM делает изменение размеров FS очень надежным, и легкий - выполняет Gparted и изменяют размер требуемого FSS, затем это сделает все для Вас. На серверах можно использовать parted от оболочки.

    • Часто лучше использовать Gparted Живой CD или Разделенное Волшебство, поскольку они имеют недавнее и часто больше Gparted без ошибок и ядро, чем версия дистрибутива - я когда-то потерял целый FS из-за Gparted дистрибутива, не обновляющего разделы правильно в рабочем ядре. При использовании Gparted дистрибутива, несомненно, перезагрузят прямо после изменяющихся разделов, таким образом, представление ядра корректно.

Снимки трудно использовать, замедлиться и багги - если снимок исчерпывает предварительно выделенное пространство, это автоматически отбрасывается. Каждый снимок данного LV является дельтой против того, что LV (не против предыдущих снимков), который может потребовать большого количества пространства, когда файловые системы создания снимков со значительным действием записи (каждый снимок больше, чем предыдущий). Безопасно создать снимок LV, это - тот же размер как исходный LV, поскольку снимок никогда не будет затем исчерпывать свободное пространство.

Снимки могут также быть очень медленными (значение в 3 - 6 раз медленнее, чем без LVM для этих тестов MySQL) - см., что этот ответ касается различных проблем снимка. Замедление частично, потому что снимки требуют многих синхронных записей.

Снимки имели некоторые значительные ошибки, например, в некоторых случаях они могут сделать начальную загрузку очень медленной, или заставить начальную загрузку перестать работать полностью (потому что ядро может привести к таймауту ожидания корневого FS, когда это - снимок LVM [зафиксированный в Debian initramfs-tools обновление, март 2015]).

  • Однако много ошибок состояния состязания снимка были, по-видимому, исправлены к 2015.
  • LVM без снимков обычно кажется вполне хорошо отлаженным, возможно, потому что снимки не используются так же как базовые функции.

Альтернативы снимка - файловые системы и гипервизоры VM

Снимки VM/cloud:

  • При использовании гипервизора VM или облачного поставщика IaaS (например, VMware, VirtualBox или Amazon EC2/EBS), их снимки часто являются намного лучшей альтернативой снимкам LVM. Можно довольно легко взять снимок в целях резервирования (но рассмотреть замораживание FS, прежде чем Вы сделаете).

Снимки файловой системы:

  • снимки уровня файловой системы с ZFS или btrfs просты в использовании и обычно лучше, чем LVM, если Вы находитесь на чистом металле (но ZFS кажется намного более сформировавшимся, просто больше стычки для установки):

    • ZFS: существует теперь ядро реализация ZFS, которая использовалась в течение нескольких лет, и ZFS, кажется, получает принятие. Ubuntu теперь имеет ZFS как 'из поля' опция, включая экспериментальный ZFS на корне в 19,10.
    • btrfs: все еще готовый к производственному использованию (даже на openSUSE, который поставляет его по умолчанию и выделил команду btrfs), тогда как RHEL прекратил поддерживать его). btrfs теперь имеет fsck инструмент (FAQ), но FAQ рекомендует Вам консультироваться с разработчиком при необходимости к fsck в поврежденной файловой системе.

Снимки для резервных копий онлайн и fsck

Снимки могут использоваться для обеспечения последовательного источника для резервных копий, пока Вы осторожны с выделенным местом (идеально, снимок является тем же размером как сохраняемый LV). Превосходный rsnapshot (начиная с 1.3.1) даже справляется, создание/удаление снимка LVM для Вас - см. это ПРАКТИЧЕСКОЕ РУКОВОДСТВО на rsnapshot, использующем LVM. Однако отметьте общие вопросы со снимками и что снимок нельзя считать резервным копированием сам по себе.

Можно также использовать снимки LVM, чтобы сделать fsck онлайн: создайте снимки LV и fsck снимок, все еще с помощью основного FS неснимка - описанный здесь - однако, это не совсем просто так лучше использовать e2croncheck, как описано Ted Ts'o, специалистом по обслуживанию ext3.

Необходимо "заморозить" файловую систему временно при взятии снимка - некоторые файловые системы, такие как ext3 и XFS сделают это автоматически, когда LVM создаст снимок.

Заключения

Несмотря на все это, я действительно все еще использую LVM в некоторых системах, но для настольной установки я предпочитаю необработанные разделы. Основное преимущество I видит от LVM, гибкость перемещения и изменения размеров FSS, когда у Вас должно быть высокое время работы на сервере - если Вам не нужно, это, gparted легче и имеет меньше риска потери данных.

LVM требует, чтобы большой уход на кэшировании записи установил из-за гипервизоров VM, жесткий диск / кэширование записи SSD, и так далее - но то же относится к использованию Linux как сервер БД. Отсутствие поддержки со стороны большинства инструментов (gparted включая критические вычисления размера, и testdisk и т.д.), мешает использовать, чем это должно быть.

При использовании LVM проявите большую заботу о снимках: используйте снимки VM/cloud, если это возможно, или исследуйте ZFS/btrfs для предотвращения LVM полностью - можно найти ZFS, или btrs является достаточно сформировавшимся по сравнению с LVM со снимками.

Нижняя строка: Если Вы не знаете об упомянутых выше проблемах и как обратиться к ним, лучше не использовать LVM.

254
ответ дан 16 December 2019 в 22:45

если Вы планируете использовать снимки для резервных копий - подготовлены к основному хиту производительности, когда снимок присутствует. читайте больше здесь. иначе это - вся польза. я использовал lvm в производстве в течение нескольких лет на десятках серверов, хотя моей главной причиной использовать его является атомарный снимок не способность развернуть объемы легко.

btw, если Вы собираетесь использовать диск на 1 ТБ, помнят о выравнивании раздела - этот диск по всей вероятности имеет 4 КБ физические секторы.

12
ответ дан 16 December 2019 в 22:45

Adam,

Другое преимущество: можно добавить новый физический том (PV), переместить все данные во что PV и затем удалить старый PV без любых прерываний сервиса. Я использовал ту возможность по крайней мере четыре раза за прошлые пять лет.

Недостаток я ясно еще не видел указанный: существует несколько крутая кривая обучения для LVM2. Главным образом в абстракции это создает между Вашими файлами и базовыми медиа. Если Вы работаете со всего несколькими людьми, которые совместно используют работу по дому на ряде серверов, можно найти дополнительную сложность подавляющей для команды в целом. У более многочисленных команд, выделенных работе IT, обычно не будет такой проблемы.

Например, мы используем его широко здесь на моей работе и заняли время, чтобы преподавать целой команде основы, язык и предметы первой необходимости о восстановлении систем, которые не загружаются правильно.

Одна осторожность конкретно для указания: если Вы загружаетесь от логического тома LVM2, Вы сделали, находят операции восстановления трудными, когда сервер отказывает. У Knoppix и друзей не всегда есть правильный материал для этого. Так, мы решили, что наш каталог начальной загрузки / будет на своем собственном разделе и всегда был бы маленьким и собственным.

В целом, я - поклонник LVM2.

5
ответ дан 16 December 2019 в 22:45

Я [+1] тот пост, и по крайней мере для меня я думаю, что большинство проблем действительно существует. Видел их при запуске нескольких 100 серверов и нескольких 100 ТБ данных. и, по крайней мере, я думаю, что большинство проблем действительно существует. Видел их при запуске нескольких 100 серверов и нескольких 100 ТБ данных. и, по крайней мере, я думаю, что большинство проблем действительно существует. Видел их при запуске нескольких 100 серверов и нескольких 100 ТБ данных. Для меня LVM2 в Linux кажется кому-то "умной идеей". Как и некоторые из них, они иногда оказываются «не умными». Т.е. отсутствие строго разделенных состояний ядра и пользовательского пространства (lvmtab) могло бы показаться разумным избавиться от этого, потому что могут быть проблемы с повреждением (если вы не понимаете код правильно)

Ну, просто это разделение было по какой-то причине - различия проявляются в обработке потери PV и онлайн-повторной активации VG с, например, отсутствующими PV, чтобы вернуть их в игру - Что такое легкий ветерок на «исходных LVM» (AIX, HP -UX) превращается в чушь на LVM2, так как обработка состояния недостаточно хороша. И даже не заставляйте меня говорить об обнаружении потери кворума (ха-ха) или обработке состояния (если я извлечу диск, он не будет отмечен как недоступный. У него даже нет проклятого столбца статуса )

Re: стабильность pvmove ... почему

pvmove data loss

занимает такое высокое место в моем блоге, хммм? Только сейчас я смотрю на диск, где физические данные lvm все еще находятся в состоянии из mid-pvmove. Я думаю, были некоторые утечки памяти, и общая идея о том, что копирование данных живых блоков из пользовательского пространства - это хорошо, просто грустна. Хорошая цитата из списка lvm "похоже на vgreduce --missing не обрабатывает pvmove" Фактически означает, что если диск отсоединяется во время pvmove, инструмент управления lvm переходит с lvm на vi. Да, также была ошибка, из-за которой pvmove продолжается после ошибки чтения / записи блока и фактически больше не записывает данные на целевое устройство. WTF?

Re: Снимки CoW выполняется небезопасно, путем обновления НОВЫХ данных в области lv снимка и последующего слияния после удаления снимка. Это означает, что у вас есть сильные всплески ввода-вывода во время окончательного слияния новых данных с исходным LV и, что гораздо важнее, у вас, конечно, также гораздо более высокий риск повреждения данных, потому что моментальный снимок не будет поврежден, когда вы нажмете стена, но оригинал.

Преимущество заключается в производительности, выполняя 1 запись вместо 3. Выбор быстрого, но небезопасного алгоритма - это то, чего, очевидно, ожидают от таких людей, как VMware и MS, на "Unix" я бы предпочел предположить все будет «сделано правильно». Я не видел особых проблем с производительностью, пока у меня есть резервное хранилище моментальных снимков на другом диске, отличном от основных данных (и, конечно, резервная копия на еще один)

Re: Барьеры Я не уверен, можно ли винить в этом LVM. Насколько я знаю, это была проблема с devmapper. Но некоторые могут быть виноваты в том, что эта проблема не особо заботилась об этой проблеме, по крайней мере, с версии ядра 2.6 до 2.6.33. AFAIK Xen - единственный гипервизор, который использует O_DIRECT для виртуальных машин, проблема была, когда использовался «цикл», потому что ядро ​​все еще кэшировало его. Virtualbox, по крайней мере, имеет некоторые настройки для отключения подобных вещей, а Qemu / KVM, как правило, разрешает кеширование. У всех FUSE FS также есть проблемы (нет O_DIRECT)

Re: Размеры Думаю, LVM «округляет» отображаемый размер. Или он использует ГиБ. В любом случае вам нужно использовать размер VG Pe и умножить его на номер LE LV. Это должно дать правильный размер нетто, и эта проблема всегда связана с использованием. Это усугубляется файловыми системами, которые не замечают таких вещей во время fsck / mount (hello, ext3) или не имеют работающего онлайн-файла "fsck -n" (hello, ext3)

Конечно, это говорит о том, что вы не могу найти хороших источников такой информации. "сколько LE для VRA?" «Какое физическое смещение для PVRA, VGDA, ... и т. д.»

По сравнению с исходным LVM2 является ярким примером того, «Те, кто не понимает UNIX, обречены на то, чтобы изобретать его заново»

. Обновление через несколько месяцев: к настоящему моменту я использовал сценарий «полного снимка» для теста. Если они заполнятся, блокируется моментальный снимок, а не исходный LV. Я был неправ, когда впервые опубликовал это. Я взял неверную информацию из какого-то документа, или, может быть, я ее понял. В моих настройках я Я всегда был очень параноиком, чтобы не позволять им заполняться, и поэтому я никогда не исправлялся. Также возможно увеличивать / уменьшать моментальные снимки, что является удовольствием.

Я все еще не могу решить, как определить возраст моментального снимка. Что касается их производительности, на странице проекта «thinp» Fedora есть примечание, в котором говорится, что методика создания снимков обновляется, чтобы они не замедлялись с каждым снимком. Я не знаю, как они это реализуют.

15
ответ дан 16 December 2019 в 22:45

Пара вещей:

Распределение LV между несколькими PV

Я видел людей, выступающих за (StackExchange и другие) расширение пространства VM в поперечном направлении: увеличение пространства путем добавления ДОПОЛНИТЕЛЬНЫХ PV к VG по сравнению с увеличением SINGLE PV. Это уродливо и распространяет вашу файловую систему (-ы) на несколько PV, создавая зависимость от все более и более длинной цепочки PV. Вот как будут выглядеть ваши файловые системы при горизонтальном масштабировании хранилища виртуальной машины:

Illustrative graphic add vs increase PV

Потеря данных, если PV потерял хостинг Часть связанного LV

Я видел много путаницы по этому поводу. Если линейный LV- и файловая система, которая в нем живет - распределены по нескольким PV, будет ли происходить ПОЛНАЯ или ЧАСТИЧНАЯ потеря данных? Вот проиллюстрированный ответ:

Illustration of data loss for Spanned LV if PV lost

Логически это то, чего мы должны ожидать. Если экстенты, содержащие наши данные LV, распределены по нескольким PV и один из этих PV исчезнет, ​​файловая система в этом LV будет катастрофически повреждена.

Надеюсь, эти маленькие каракули облегчили сложную тему для понимания рисков при работе с LVM

1
ответ дан 18 January 2020 в 12:12

Предоставляя интересное окно о состоянии LVM более 10 лет назад, принятый ответ теперь полностью устарел. Современный (то есть: LVM после 2012 г.):

  • учитывает запросы синхронизации/барьера
  • имеет возможность быстрого и надежного снимка в видеlvmthin
  • имеет стабильное кэширование SSD черезlvmcacheи политика быстрой обратной записи для NVMe/NVDIMM/Optane через dm-writecache
  • оптимизатор виртуальных данных ( vdo ) поддержка благодаряlvmvdo
  • интегрированному и RAID для каждого тома благодаря доlvmraid
  • автоматическое выравнивание до 1 МБ или 4 МБ (в зависимости от версии), что полностью исключает любые проблемы с выравниванием 4K (если только не используется LVM для смещенного раздела)
  • отличная поддержка расширения тома, особенно при добавлении других блочных устройств (что просто невозможно при использовании классической файловой системы ext4/xfs поверх простого раздела)
  • отличный, удобный и чрезвычайно полезный список рассылки по адресу (скрыт)

Очевидно, это не означает, что вы всегда должныиспользовать LVM. да. Например, для простых виртуальных машин вы, безусловно, можете использовать только классический раздел.Но если вы цените какие-либо из вышеперечисленных функций, LVM — чрезвычайно полезный инструмент, который должен быть в наборе инструментов любого серьезного системного администратора Linux.

11
ответ дан 27 July 2020 в 10:41

Теги

Похожие вопросы