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

Использование raid-1 madm для прямого сжатия существующего диска EBS емкостью 8 ТБ. Возможно ? Риски?

Исходная ситуация
У меня на Amazon накопитель EBS емкостью 8 ТБ (ext4, смонтированный напрямую без разделов)
Я не использовал sw-raid целую вечность, поэтому мое предположение могло быть ошибочным, что я могу таким образом сжать диск.

Цель
Я хочу уменьшить размер этого диска EBS в производственной системе до 5 ТБ (-3 ТБ)
Диск будет постоянно записываться со скоростью 100-200 МБ / сек (производственная база данных и инструменты)

Проблема Amazon не предлагает сокращение EBS, единственные решения, которые я мог найти (и использовать в прошлом), включают создание второй EBS и копирование всего, обычно с использованием rsync.
Это не вариант, EBS работает медленно, и, учитывая, что у меня есть система, которая постоянно изменяет файлы размером более 2 ТБ (файлы базы данных), rsync никогда не сможет догнать изменения.

Идея Я подумал о «преобразовании» моего диска EXT4 8TB в RAID-1 (изначально с отсутствующим вторым диском). Я бы использовал версию метаданных, которая добавляет метаданные в конец моего диска (для этого я могу просто сжать файловую систему).

Первый вопрос При создании md0 моего диска 8 ТБ есть ли что-нибудь, что мешает мне снова установить его как EXT4 и игнорировать, что это рейд-диск?
Насколько я понял, единственное изменение на самом деле состоит в том, что «метаданные» добавлены (добавлены), поэтому они все равно должны быть «юридически» нормальным диском ext4?
Это правда ? И правда ли это, когда монтируешь его как MD0 и записываешь в него?

Учитывая, что это безрисково, я бы сейчас создал md0 с отсутствующим вторым диском, смонтировал его (так что несколько минут простоя задействованного сервера)

Теперь я хочу уменьшить размер файловой системы 2fs на 3 ТБ, а затем хочу уменьшить общий размер mdadm --grow (shrink) md0 до 5 ТБ.
Теперь я хочу добавить в рейд второй диск EBS (5 ТБ) в качестве второго диска и синхронизировать его.

Второй вопрос Могу ли я сделать это ? добавив таким образом диск на 5 ТБ?

третий вопрос
Я бы удалил исходный диск емкостью 8 ТБ и либо продолжал использовать однодисковый md0, либо просто монтировал ext4 md0 напрямую и больше не использовал raid.

Если mdadm не подходит, поддерживает ли LVM? (Я пришел к mdadm, потому что он, кажется, остается совместимым с ext4, поэтому я могу просто вернуться к прямому монтированию после того, как это будет сделано. С LVM это невозможно)

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

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

Просто для резюме некоторые заметки из чтения ваших вопросов выше:

  • Вовлеченный риск - это деловой риск. Вы описываете его как живую систему со 100-200 МБ записей в базу данных. Эти данные, скорее всего, получены из какого-то текущего бизнеса. Помимо технических деталей, должно быть ясно, что эта миграция содержит риск остановки работы экземпляра на несколько часов. Не только для целей восстановления я бы рекомендовал мигрировать с автономной базой данных во время планового отключения.
  • Идея звучит солидно и, скорее всего, удастся. Необходимо провести тестирование и потратить некоторое время, чтобы получить все необходимые детали.
  • Вы заявили, что на диске нет таблицы разделов, поэтому можно сжать ext4 и создать mdraid с метаданными в конце диска. Это не должно влиять на данные раздела ext4. Он определенно не будет работать с метаданными в начале диска, так как они перекрываются с метаданными ext4.
  • Метаданные добавляются, но не напрямую, в конец диска. Точное положение зависит от свойств жесткого диска, таких как размер блока, количество блоков и некоторые другие детали. Это тоже камень преткновения при такой установке. Если другой администратор вырастит ext4, он в конечном итоге убьет метаданные mdadm.
  • Создание рейда с missing диск можно, просто нужно указать, какой диск missing.
  • Для raid-1 Я думаю, что предположение, что это можно рассматривать как обычный диск, верно. Пока /dev/sd<x> используется для дублирования блоков и обновления метаданных, фактически механизм рейда не будет активен. Поэтому необходимо перенести крепление на /dev/md<x> для синхронизации прикрепленного позже тома.
  • Добавление диска 5 ТБ должно работать, на данный момент это основная функция mdadm, заменяющая отказавший raid-1 диск. На данном этапе произошедшая выше процедура не актуальна.
  • Я бы удалил рейд после миграции, так как блок метаданных исчезнет в какой-то неопределенный момент времени после следующего роста. Это может привести к полному отказу данных на томе. В случае, если рейд должен остаться для возможных дальнейших действий, подобных этому, было бы важно создать его с метаданными в начале, а ext4 только поверх /dev/<mdx>.
  • Выбор маршрута mdadm над lvm должен быть предпочтительным способом. В дальнейшем оба используют уровень raid-блока на уровне ядра. mdadm более гибкий, чем lvm. Обычно в случае, если требуется комбинация raid и lvm, mdadm используется для части raid. Поскольку это должно быть возможно легко вырастить ebs и ext4, вполне нормально оставить lvm вне настройки.

Практический совет: используйте новейшие инструменты ext4 с дисками такого размера.