Назад | Перейти на главную страницу

LVM и аварийное восстановление

Я понимаю что LVM есть и чего он добивается, но я чувствую, что чего-то не хватает.

Допустим, у нас есть два физических диска, sda и sdb. Оба по 100 мегабайт. Я помещаю их в VolumeGroup1 и создаю один LogicalVolume1 на 200 мегабайт.

Что будет, если я создам файл размером 150 мегабайт? Будет ли 100 мегабайт физически на sda и 50 на sdb? Если да, то что говорит ОС, что часть файла находится на одном диске, а другая часть - на другом?

А как насчет сбоя диска? При отсутствии RAID, если sdb выйдет из строя, все данные на sda будут потеряны? Есть ли способ контролировать, какие файлы находятся на каких физических дисках?

Как вы в целом управляете LVM? Вы создаете одну или две большие группы томов, а затем делаете разделы, если это имеет смысл? Есть еще советы?

Допустим, у нас есть два физических диска, sda и sdb. Оба по 100 мегабайт. Я помещаю их в VolumeGroup1 и создаю один LogicalVolume1 на 200 мегабайт.
Что будет, если я создам файл размером 150 мегабайт? Будет ли 100 мегабайт физически на sda и 50 на sdb?

Правильно (при условии, что файловая система была пустой до создания файла).

Если да, то что говорит ОС, что часть файла находится на одном диске, а другая часть - на другом?

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

А как насчет сбоя диска? При отсутствии RAID, если sdb выйдет из строя, все данные на sda будут потеряны? Есть ли способ контролировать, какие файлы находятся на каких физических дисках?

Да, считайте данные потерянными.

Если вы создаете меньшие логические тома, вы можете использовать pvmove команда для перемещения их с диска на диск.

Как вы в целом управляете LVM? Вы создаете одну или две большие группы томов, а затем делаете разделы, если это имеет смысл? Есть еще советы?

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

Основная вещь, которая позволяет LVM и Software Raid в Linux работать, - это часть ядра, предназначенная для отображения устройств. Это то, что абстрагирует блочные адреса физических устройств до виртуальных блочных устройств, которые вы используете.

Когда вы используете LVM, как и все, что касается данных, вам нужно знать о последствиях доступности данных. Это не означает, что LVM опасен на самом деле, когда используются надлежащие методы, его влияние на доступность минимально.

В сценарии, который вы предлагаете в своем вопросе, доступность ваших данных будет такой же, как в RAID0, где отказ какого-либо диска приведет к потере данных.

На практике я бы не стал использовать LVM, не запустив его на каком-то RAID. Я использовал LVM на файловом сервере 30 ТБ, на котором было около 20 томов аппаратного RAID5 в одном VG. Но если у вас достаточно бесплатных экстентов, вы можете использовать pvmove для переноса данных с одного или нескольких PV, если это начнет вызывать у вас проблемы.

Но всегда имейте в наличии стратегию резервного копирования, которая время от времени проверяется.

Как вы в целом управляете LVM? Вы создаете одну или две большие группы томов, а затем делаете разделы, если это имеет смысл?

Моя общая стратегия состоит в том, чтобы поместить в отдельную группу томов физические тома, которые могут быть перенесены (в целом) в другую систему.

Если у вас есть внешнее хранилище, рекомендуется поместить его в отдельную группу томов. Его физически легко отключить от этого компьютера и подключить к другому, поэтому логически будет легко экспортировать / импортировать его в LVM, сохраняя данные нетронутыми.

Если у вас уже есть vg00 на внутреннем диске (ах), а затем вы покупаете другой внутренний диск для своей машины, задайте себе вопрос: будут ли данные на новом диске привязаны к vg00, и не было бы смысла когда-либо перемещать данные в другую систему? В этом случае он должен быть частью vg00. В противном случае я бы создал vg01, так как его можно легко экспортировать / импортировать самостоятельно.

Если у вас есть два диска в качестве физических томов в такой группе, то у вас есть массив JBOD (Just a Bunch Of Disks). Если один из дисков выйдет из строя, вы будете защищены не лучше, чем если бы диски были расположены в массиве RAID0.

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

Я считаю, что каждый PV в VG имеет копию макета LV, и данные не удаляются, как в RAID0, поэтому у вас есть больше шансов восстановить что-то, если один из ваших дисков выходит из строя, но если потеря данных вообще вызывает беспокойство Я бы вообще не рассматривал использование двух дисков таким образом (через LVM или RAID0).

Что будет, если я создам файл размером 150 мегабайт? Будет ли 100 мегабайт физически на sda и 50 на sdb? Если да, то что говорит ОС, что часть файла находится на одном диске, а другая часть - на другом?

LVM (Диспетчер логических томов) собирает физические тома в группы томов. Каждый физический том (сам диск) состоит из небольших частей, называемых физическими экстентами. Эти экстенты имеют уникальный идентификатор на диске. Фактически они нумеруются последовательно. Когда вы создаете логический том, он состоит из логических экстентов, которые связаны с физическими экстентами. Логические экстенты имеют уникальный идентификатор в логическом томе. В HP-UX вы можете проверить, какой логический экстент сочетается с каким физическим. В SLES11 я не понял, как это проверить. lvdisplay --maps должно быть хорошо, но не идеально (для меня).