процедура с multipath и lvm - миграция на новый массив хранения
Вместо синтаксического анализа выходных данных locate(, которые являются ненадежными и могут пропустить данные, которые изменились с момента последнего обновления базы данных или которые недоступны для всех пользователей ), используйте find. ].
Далее будут найдены все .cфайлы в текущем каталоге, которые являются обычными файлами, (не символическими ссылками):
find. -type f -name '*.c'
Учитывая структуру каталогов
.
|-- file-a.c
|-- file-b.c
|-- file-c.c
|-- file-d.c
|-- link-b.c -> file-b.c
`-- link-d.c -> file-d.c
Это вернет
./file-a.c
./file-b.c
./file-c.c
./file-d.c
Сосчитать их:
find. -type f -name '*.c' | wc -l
или, если у вас есть имена файлов с символами новой строки в именах,
find.//. -name '*.c' -type f | grep -c //
То же самое для символических ссылок потребует замены -type fна -type l.
Чтобы уточнить, вы собираетесь сделать зеркало с lvm, а затем разделить их? Или данные уже реплицируются между массивами?
Реплицируются ли данные из массива в массив. Процесс прост. Когда они синхронизированы. IO останавливается и экспортируется VG. Убрать видимость для хоста текущих дисков. Остановить реплику. Разделите реплику. Эта опция позволяет вернуться назад, если процесс завершился некорректно.
Подарите хосту новые диски. Это будет иметь новый UUID. UUID LUN/тома зависит от того, в каком массиве он находится. Импортируйте VG из новой кабины.
Вы закончили.
Разумеется, для новых дисков на узле необходимо заранее правильно настроить многопутевость.
Во всяком случае, прежде чем делать это с производственными данными. ТЕСТ ТЕСТ ПРОВЕРЬТЕ весь метод с небольшим количеством тестовых данных от источника до места назначения.
Если вы хотите, чтобы все работало с LVM?
Это широкий и, возможно, не очень конкретный вопрос.
Подводя итог. Это амбициозная задача, если у вас нет предварительных знаний о LVM.
Шаги будут :1.-Подарите хозяину новую каюту. 1.a производитель массива (HP, DELL, IBM,... )будет иметь определенные конфигурации этой модели массива для multipath.conf. Найдите и подайте заявку
1.b Затем новые диски представляются хосту.
mpathX — один из вариантов. Наверное, не лучший.
1.c В multipath.conf вы можете определить имена дисков.
- сканировать новые диски.
3. -Форматирование дисков
3.a Уточните, требуется ли производителю специальная регулировка. Обычно это зависит от того, является ли это pv всего диска или раздела.
4. -Создайте физические тома
5. -Отсюда есть несколько вариантов:
5.a Добавьте диски в группу VG и создайте зеркала каждого тома в каждом массиве.
5.a1 stop service.
5.a2 Separate the mirrors of each array --split-mirrors
5.a3 export old disks
По завершении у вас будет 1 полная копия в каждом массиве.
Запустить службу.
Делать это с производственными данными без предварительного знания LVMможет быть очень опасно.
Тест Можно создать новую небольшую ВГ, пару томов, добавить данные в файловые системы. Добавьте диск достаточного размера из новой будки. Соедините их вместе в одном VG и проделайте операции зеркала и --разделения -зеркал, чтобы получить представление о полной операции.
Результат проверки
Процесс перемещения файловой системы в новый массив завершен. Это были шаги.
Файловые системы массива были приостановлены, а затем размонтированы.
Файловые системы были удалены из /etc/fstab, чтобы они не монтировались при загрузке. Копия данных на уровне массива была сделана в новый массив хранения. LUN были отключены от старого массива и подключены к новому массиву. Хост был перезагружен. С помощью команды «multipath -ll» новые LUN были обнаружены как подключенные, а также были очевидны пути к устройствам scsi (/dev/sd *)(4 пути, соответствующие паре двухпортовых HBA ). Использование LVM :«pvs» показало физические устройства, как и ожидалось. Однако «vgs» не показывал ни одну из групп томов.
Запустил «vgscan», который затем показал все группы томов, и, следовательно, «vgs» тоже. Однако при монтировании файловой системы не удалось сообщить «нет такого файла или каталога» для пути /dev/mapper/vg _name/lv _name. Мы не смогли увидеть имена групп томов по этому пути в /dev. Запустил «vgchange -a y», который «активировал» группу томов, после чего путь был виден в /dev. Затем смонтировал файловую систему.
Подтвердил, что данные есть и они верны. Восстановлен /etc/fstab для включения файловых систем. Выполнил тестовую перезагрузку, чтобы убедиться, что все хорошо. Полный.
Значительно помогло понимание того, что LVM записывает заголовок в начале диска, который включает UUID. Это механизм, с помощью которого диск может быть идентифицирован и сохранен в правильных объектах LVM (pv, vg, lv )при изменении основных путей хранения и устройств.
Наконец, отсутствие информации о группе томов от «vgs» изначально и далее, когда путь не отображался в /dev, можно было бы легче диагностировать, используя «vgdisplay» вместо «vgs». «vgdisplay» показывает состояние группы томов и может дать полезные подсказки на этом этапе.
Весь процесс от подключения новых LUN до запуска машины занял около 15 минут и был бы значительно быстрее, если бы диагностика состояния группы томов проводилась сразу.
При подготовке мы позаботились о том, чтобы резервные копии всех соответствующих файлов и данных были созданы и хранились отдельно (/etc/fstab, /etc/lvm/, /etc/multipath.conf, /etc/multipathd/bindings и несколько более. Также захвачен вывод из pvdisplay, vgdisplay, lvdisplay, multipath -ll, fdisk -l и так далее. Сгенерировано несколько хэшей выборочных данных в каждой файловой системе, которые также использовались для проверки -, но на самом деле не использовались ). Мы также обеспечили доступ к консоли и поддерживали активный сеанс на протяжении всего изменения.