Можно ли перейти с настройки LVM + Raid 1 на LVM в работающей системе?

Это может показаться глупым вопросом. Но вот он –

Некоторое время назад я настроил сервер Ubuntu, который содержал два идентичных диска. Оба диска были сконфигурированы в процессе установки с использованием LVM + Raid 1.

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

Эта система управляет хранилищем данных. (Точнее, Kafka. Если вы не знакомы с Kafka, просто представьте, что она хостит базу данных.)

Проблема в том, что у меня почти не осталось диска. Осталось примерно 5%.

Я пытался архивировать данные на другую систему, но понял, что это, вероятно, не сработает, так что у меня как-то исчерпались варианты.

В качестве последнего варианта, я задаюсь вопросом, есть ли способ разорвать Raid и объединить оба диска с помощью LVM.

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

Чтобы дать представление о текущей конфигурации, вот вывод sudo blkid.

/dev/nvme0n1p1: UUID="2A2B-A491" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a1d02797-..."
/dev/nvme0n1p2: UUID="3f3f1c59-..." UUID_SUB="ff3db717-..." LABEL="ubuntu-server:0" TYPE="linux_raid_member" PARTUUID="b4de5c71-..."
/dev/nvme0n1p3: UUID="4bd2d087-..." UUID_SUB="4ca62bb9-..." LABEL="ubuntu-server:1" TYPE="linux_raid_member" PARTUUID="51457661-..."
/dev/nvme0n1p4: UUID="db2acc5a-..." UUID_SUB="36fa3f0e-..." LABEL="ubuntu-server:2" TYPE="linux_raid_member" PARTUUID="e96c4c38-..."
/dev/nvme1n1p1: UUID="2971-0B61" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3fbcd197-..."
/dev/nvme1n1p2: UUID="3f3f1c59-..." UUID_SUB="6667f123-..." LABEL="ubuntu-server:0" TYPE="linux_raid_member" PARTUUID="81aed881-..."
/dev/nvme1n1p3: UUID="4bd2d087-..." UUID_SUB="453744c7-..." LABEL="ubuntu-server:1" TYPE="linux_raid_member" PARTUUID="f1b24cab-..."
/dev/nvme1n1p4: UUID="db2acc5a-..." UUID_SUB="8c55099f-..." LABEL="ubuntu-server:2" TYPE="linux_raid_member" PARTUUID="ffd89d37-..."
/dev/md0p1: UUID="9358becb-..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cc0d0a6a-..."
/dev/md1p1: UUID="4ca79c3f-..." TYPE="swap" PARTUUID="4015b3d7-..."
/dev/md2p1: UUID="e53db31b-..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="f845a5c8-..."
/dev/loop1: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

Я имею в виду, даже теоретически это не должно быть проблемой: вся суть RAID 1 в том, что если один диск выходит из строя, другой диск может функционировать самостоятельно.

Итак, в худшем случае: вы просто удаляете одно физическое хранилище, RAID 1 становится “сниженному” (т.е. нет зеркалирования, но затем вы продолжаете и просто копируете его содержимое на новый том LVM на пространстве, ранее используемом зеркалом. Затем вы удаляете оригинальный RAID1 и используете освобожденное пространство для расширения вашего тома LVM.

Я не уверен, что именно вы имеете в виду под RAID1+lvm. Если это lvmraid (см. man lvmraid): более элегантный способ (и то, что я бы рекомендовал, чтобы избежать полной копии диска) – это преобразовать lvmraid 1 в линейный:

lvconvert -m0 my_volume_group/my_volume

-m – это “количество зеркал”. Установка его на 0 означает полное удаление зеркалирования.

После этого вы захотите lvresize -l 100%FREE -r my_volume_group/my_volume, чтобы использовать освобожденное пространство для вашего тома.

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

Вы уверены, что это правильный путь? Будете ли вы сожалеть об этом решении вскоре?

Я бы спорил, что RAID1 почти никогда не является хорошей идеей с самого начала: вы получаете проблему “медленный писатель определяет максимальную возможную скорость в данный момент времени”, и ваша система даже не заметит, если два экземпляра расходятся из-за, скажем, одного битового переворота; и даже если система как-то заметила бы это расхождение (а она этого не делает), не было бы способа узнать, какой экземпляр правильный. Так что, на мой взгляд, RAID1 с двумя дисками имеет смысл только на основе томов с проверенной целостностью! Поэтому, слоение должно быть: физическое хранилище под слоем dm-integrity под LVM RAID. (Гораздо проще было бы использовать ZFS с zraid и контрольными суммами данных, это действительно делало бы проверку, является ли все прочитанное данные корректным.) И даже тогда, с двумя идентичными SSD с идентичной загрузкой данных, шансы на то, что если один выйдет из строя, другой уже может быть близок к выходу из строя, так что вам нужно быть чертовски быстрым в замене этого вышедшего из строя SSD.

Сама Kafka приносит репликацию; это может быть решением: вместо зеркалирования хранилища внутри одной машины, у вас есть две машины, и устанавливаете коэффициент репликации всех тем в 2.