нужно перенести разделы на другой сервер

ща, я наконец-то допиннал селектел, вроде как поставили флэшку загрузочную с gparted и clonelizza

пол-ночи их пиннал, чтобы заработал kvm нормально

попробую куданить все это слить сначала

А просто посмотреть в суперблоке MD? Не помню, был ли там статус, но вроде да.

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

да чтобы хоть что-то было… хз, умрет совсем до загрузки… потом загружусь, гляну

Может и есть, да… ты предлагаешь глянуть

mdadm --examine /dev/sda3
mdadm --examine /dev/sdb3

?

Да. Должно быть достаточно одного диска, но можно и оба, если состояние массива не очень ясно.

клонировать /dev/md126 нет смысла — ты получишь заведомо кривую копию

глупость, когда появится другой диск, данные на устройстве md126 прямее не станут, ты похоже не понимаешь как это работает

К сожалению да, с mdadm редко выпадает работа, обычно или аппаратный рейд, или диски с массива, или vmware.

Если ты прям в линуксе не очень, то тебе правильно посоветовали - перенеси систему просто на mdadm + ext4 (debian10 её уже поддерживает давно).

Останавливаешь все сервисы, оставляя только sshd, на одной машине tar cf –one-file-system … | nc newserver. На второй машине загрузиться с livecd, настроить сеть, диски как надо и nc -l | tar xf.

Потом правишь fstab и перегенерируешь grub и update-initrd/initramfs (ну и сеть тоже) и грузишься в перенесённую систему.

Я так дофига систем p2p/p2v/v2p перетаскивал.

Я пользуюсь при бекапе системы опцией --numeric-owner.

Вот здесь: https://help.ubuntu.com/community/BackupYourSystem/TAR сказано, что, как минимум, при распаковке архива с использованием лайв-сиди необходима эта опция:

--numeric-owner - This option tells tar to restore the numeric owners of the files in the archive, rather than matching to any user names in the environment you are restoring from. This is due to that the user id:s in the system you want to restore don't necessarily match the system you use to restore (eg a live CD).

Я сто лет как заучил tar cvzf и tar xvzf, а так же rsync -avh и другого мне не нужна

Доучи параметры для xattrs, ACL и хардлинков. Поможет избежать странных поломок в некоторых случаях.

Для атрибутов пользуюсь getfacl/setfacl, getfattr/setfattr. Советуют ещё добавлять опцию -S (sparse).

Про хардлинки не знал. Как пользоваться?

Ну не факт, что они вообще нужны, тот же постгрес сам эти атрибуты выставит на свою папочку с датой. В общем не убедил, мне точно не нужно

А вот ping может перестать работать под обычным пользователем. Починить тоже несложно, правда.

хардлинки и так таром копируются

ну это ты сам так систему свою настроил что ее по-человечески склонировать низя

Про хардлинки не знал.

Для tar не нужно, как уже сказали. Там было про tar и rsync, я не стал разделять. Для rsync это -H. Почти всегда использую rsync -aHAX …

Гибкая разметка нужна для:

Когда есть десятки тысяч железных серверов-гипервизоров, на которых надо динамически создавать/удалять сотни тысяч виртуальных машин с разными параметрами. Использовать при такой конфигурации для виртуальных машин физические разделы или образы в файле невозможно по множеству причин, один из которых - отсутствие гибкости, поэтому оптимальный вариант - создавать и пробрасывать в виртуальные машины lvm-тома. На виртуальных машинах может находиться кластер, например, базы данных. Часто нужно увеличить размер всех тысяч нод этого кластера на лету без перезагрузки. Не байтики экономить, а поднять размер в разы из-за возросших в процессе эксплуатации требований. Это простейший пример того, где нужна гибкая разметка.

А когда у тебя подкроватный локалхост на железе за 17 т.р., тогда, конечно, гибкость lvm не нужна.

Это не я, это из коробки. А ещё бывают дистрибутивы с рабочим SELinux. В общем, «по-человечески» — это как раз с расширенными атрибутами и ACL.

В твоём примере совершенно непонятно как организовано хранилище. И зачем тебе кластер базы данных, организованный как «сотни тысяч виртуалок на десятке тысяч серверов». И какое отношение имеет количество серверов к механике выделения места на диске. А lvm ты приплёл тупо от балды. Я не исключаю, что система, которую ты описываешь, действительно существует, но это не значит что так надо делать.

Я не удивлён, что ты не понимаешь. Потому что никогда с такими системами не работал. И судя по всему не только про файловые системы не знаешь, но и про распределённые кластера, отказоустойчивость и администрирование высоконагруженных сервисов. Такие системы в том или ином виде существуют у всех крупных компаний. И lvm там зачастую стандарт, как правильно заметили выше. Есть другие решения. Как опенсорсные, так и закрытые. Но никто в проде уже очень давно не использует фиксированные разделы на одном несчастном диске, как это сделано на твоём локалхосте.

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

Есть продукт, состоящий из сотен компонентов. Для каждого компонента создаются и удаляются базы/воркеры/фронты/Беки и прочие службы.

Всё это должно работать распределённо географически и структурно. Если говорить про базу, иногда не выгодно расти вверх, нужно расти вширь(шардировать). Когда тебе нужно создать для мелкого компонента бд(postgres, к примеру) на 100 шардов по 100 гигов в каждом, тебе надо где-то взять минимум 300 машин, на каждой из которых минимум 20 гигов под систему, столько же под логи и 150 гигов под раздел с базой. Получить эти триста машин нужно автоматически одной командой в минимальное время(максимум час). Для этого на трёх стах разных железных серверах в разных датацентрах создаётся 300 виртуальных машин, под каждую из которых выделяется по три lvm-тома. Через некоторое время объём данных этого компонента вырос и надо на всех машинах увеличить раздел по базу на сотню гигов. А ещё через некоторое время приходят аналитики и говорят, что логам перед синхронизацией не хватает локального места и на всех трёх стах машинах надо вдвое поднять место под логи. А через полгода, аналитики выяснили, что базу можно уменьшить вдвое и теперь надо уполовинить на всех машинах раздел с базой, чтобы освободить ресурсы. А потом один из железных серверов нужно ввести из эксплуатации. Все виртуалки на нём со всеми их данными надо быстро и прозрачно перекинуть на другой. Каждая операция должна выполняться одной командой без физического доступа к серверу, без его перезагрузки и быстро(времени медитировать на dd нет). И таких маленьких компонентов тысячи. И в каждом компоненте есть не только база. Крутить всё это на железных серверах с фиксированными разделами физически невозможно. Поднимать на каждом сервере кучу экземпляров базы и хранить всё в одном разделе - тоже. Виртуальные машины можно в некоторых случаях заменить на контейнеры(не всегда), но в контейнер тоже надо монтировать раздел, а не директорию с файлопомойки. Так что суть не меняется.

Про такие вещи как введение/выведение из pv дисков без потерь данных и без ручного копирования, простыми перемещением vg парой команд, я вовсе молчу. А в проде на таких объёмах просто статистическими железо летит регулярно.

Это всего один из простейших юз-кейсов.

И когда личности называют это экономией байтиков, возникает закономерный вопрос в их компетентности.

что у тебя хранится на 300 машинах если база данных днса какого-нибудь весит 30 гигабайт?

Смешно. :)

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

Я не знаю, откуда ты взял цифру в 30 гигов у DNS. Уверен, что эта цифра не верна.

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

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

Поэтому и смешно.

И чем же в данном случае файлы на raid-массиве хуже lvm-томов?

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

Ну это ты ерунду написал. Чтобы можно было быстро перекинуть - вариант только один это сетевое хранилище (и в его случае вдвойне непонятно зачем тебе lvm на хостах, т.к. управление томами тогда хранилищу и надо поручать). Но, как я понял из текста, у тебя все данные локальные. Если ты собираешься физически выключать какой-то сервер, куда воткнуты диски с данными, то без ожидания пока эти данные с него скопируются на устройство, не подлежащее выключению, ты в любом случае не обойдёшься, и «технология» их расположения на дисках тут не играет абсолютно никакой роли. Что же касается «одной командой», то разумеется в серьёзном проде это будет именно так, но lvm тут опять ни при чём. Команда будет «рассовать виртуалки на другие вычислительные ресурсы и отключить этот», делать её будет виртуалочная инфраструктура и реализовать это можно одинаково успешно вне зависимости от того, на чём лежат диски виртуалок (надо отзеркалить виртуальные диски на приёмник виртуалки, где-то ближе к концу или после этой операции быстро скопировать её оперативную память на приёмник и продолжить работу там, ну или можно оперативную память тоже зеркалить, если скорость сети позволяет).

Про такие вещи как введение/выведение из pv дисков без потерь данных и без ручного копирования, простыми перемещением vg парой команд, я вовсе молчу. А в проде на таких объёмах просто статистическими железо летит регулярно.

Ты серьёзно тривиальную функциональность рейдов приписываешь в заслугу lvm? Не говоря уж о том что все эти команды (не важно lvm-ные или рейдовые) вполне могут быть автоматизированы вплоть до «дежурный инженер вытаскивает диск из слота, горящего красным индикатором, суёт вместо него новый и он сам подхватывается» безо всяких твоих логинов туда?

От этого реальность не изменится. Наверное, база с анализами мочи чересчур денормализированная

DNS таки не монстр рынка, хотя думаю база у него заметно больше чем 30ГБ.

Монстры рынка это яндекс/вконтакт и подобное. И их очень мало.

И чем же в данном случае файлы на raid-массиве хуже lvm-томов?

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

Чтобы можно было быстро перекинуть - вариант только один это сетевое хранилище

Я посмотрю на производительность твоей системы, которая файлы бд хранит на сетевом хранилище.

Но, как я понял из текста, у тебя все данные локальные.

Нет, ты ничего не понял. Посмотри в словаре термин «распределённая». Заодно, что такое «репликация» и «шардирование».

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

И копировать удобно с помощью vg/lv, а не через dd. С сжатием без перетаскивания всех байтиков незанятой файловой системы и прочим.

делать её будет виртуалочная инфраструктура

Частью этой инфраструктуры зачастую является lvm. Погугли устройство продуктовых систем виртуализации.

Ты серьёзно тривиальную функциональность рейдов приписываешь в заслугу lvm?

См. выше. Ты серьёзно предлагаешь создавать/удалять/ресайзить тысячи рейд-разделов на каждом сервере, ждать синхронизации? На железных рейдах, ага. raid и lvm - это разные уровни одной системы. На нижнем уровне создаётся рейд, поверх него lvm. Разные инструменты под разные задачи. Ну я уже понял, что ты с нормальным продом не сталкивался ни разу. Вот и получается, что что-то объяснять тебе нет смысла. Твои теоритические изыскания на основе своего локалхоста совершенно не совместимы с современным крупным продом. Если ты ещё в 2000-ом живёшь, внимательно следи за новостями. Скоро появятся биткоины, срочно покупай!

И какая у тебя реальность в параллельной вселенной?

И те, и другие на серверах активно используют lvm. Про яндекс об этом рассказывали на какой-то из конференций. Во вконтакте я работал пару лет назад.

Монстров сильно больше и везде без lvm не обойтись. Тот пример, который я привёл - из другого российского монстра. В зарубежных компаниях та же картина. Это просто промышленный стандарт уже давно. Про побайтовое копирование на серьёзных серверах можно уже просто забыть. Либо lvm, либо специализированные файловые системы.

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

Это всё не отменяет моего вопроса.

Нет, ты ничего не понял

Если я не понял значит ты плохо описал систему.

репликация

Я ниже про неё писал как про средство переноса (словом «зеркалировать»). Локальность данных это не отменяет.

шардирование

Ты опять пытаешься понтоваться?

И копировать удобно с помощью vg/lv

Нет.

, а не через dd.

Причём тут dd вообще? Это консольная команда, а через консоль такие вещи незачем делать.

Ты серьёзно предлагаешь создавать/удалять/ресайзить тысячи рейд-разделов на каждом сервере, ждать синхронизации?

Какие ещё тысячи рейд-разделов, что ты несёшь? И какую синхронизацию ты собрался ждать? Я ничего такого не предлагал. Есть массив из физических дисков, на нём файловая система, на файловой системе данные виртуалок.

На железных рейдах

Если у тебя и так есть рейд, то твоя фраза про замену pv в lvm и про летящее железо выглядит ещё глупее чем раньше.

Про побайтовое копирование на серьёзных серверах можно уже просто забыть.

Копирование чего и куда?

Если я не понял значит ты плохо описал систему.

Нет. Это означает, что ты не понимаешь терминологию и предназначение инструментов. Рассказывать тебе всё это с нуля я не буду.

Ок. Но lvm всё равно не нужен.

1. Тебе надо скидывать не «LVM разделы» а LV (logical volumes). Потому что обычно «раздел» в контексте LVM это раздел диска, на котором создан PV (physical volume)

2. Копировать данные с помощью dd + ssh:

new-server # lvcreate new-vg --size 128G -n volume1

rescue-oldserver # dd if=/dev/old-vg/volume1 bs=1024k iflag=direct xz -c | ssh root@new-server -C "xz -D | dd of=/dev/new-vg/volume1 bs=1024k conv=nocreat oflag=direct"

LVM это как раз то что нужно ибо он давно уже и заменяет RAID.

Точнее, RAID давно реализуется средствами LVM практически во всех случаях, кроме раздела EFI и /boot, где пока трудно обойтись без софтрейдов.

Хардварные рейды также очень-очень давно остались уделом виндузятников и днищеэнтерпрайза (тоже виндового, естественно).

lvcreate –type mirror -m 1 –raidintegrity y –size 1T -n my-lv my-vgname

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

На нижнем уровне создаётся рейд, поверх него lvm

Или наоборот :-)

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

Кто пустил уборщицу в серверную уже спрашивали?

И всё-таки ты сферический архитектор в вакууме. Тем хуже, что тебе дают воплощать больные фантазии в жЫзнь :)

на файловой системе данные виртуалок

Предположим, нужна производительность получше, чем у qcow2. Ваши действия?

Я ничего такого не предлагал. Есть массив из физических дисков, на нём файловая система, на файловой системе данные виртуалок.

И я посмотрю на тебя, когда одна из виртуалок сожрет весь ввод-вывод диска, и нужно будет понять, какая именно.

Если их диски на LVM в виде LV, то нет проблем, iostat в помощь. В случае файлов на общей ФС — удачи в поисках.

Плюс производительность. Это куда быстрее qcow2, и несколько быстрее даже RAW дисков.

Да он вообще странный. Стандартный способ восстановления GRUB — chroot в ОС, потом переустановка и регенерация меню из него.

Он же предлагает ставить GRUB2 автономно, а потом писать конфиг руками. Ему так удобнее, потому что chroot непонятный.

С LVM то же. Я ему уже давно расписывал плюсы — ему он не нравится, потому что он убог, так как он не в состоянии руками найти, где какой LV на диске. Зачем ему это делать, когда есть device mapper, не говорит — но раз так, то убого и лишняя прослойка.

И я посмотрю на тебя, когда одна из виртуалок сожрет весь ввод-вывод диска, и нужно будет понять, какая именно.

Мне кажется, даже libvirt должен это уметь.

Да и вообще что угодно, что покажет I/O в разрезе процессов.

Ну да, если каждый юзкейс где он полезен, включая реальные случаи из жизни, объявлять нищебродской экономией дисков, ведь нормальные люди всегда выделяют по 1000% места про запас — то он не нужен.

Мальчик, диски стоят денег. Если бизнес будет тратить их на много дополнительного места ради существующей только у тебя в голове чистоте архитектуры вместо того, чтобы использовать гибкий инструмент, что позволяет работать с обычными объемами комфортно — он разорится.

Простой расчет — у нас 1000 виртуальных серверов, каждому нужно 50 гигов, итого нам нужно 50 терабайт. Но это минимум, возможен рост до 200 гигов на 50%, так что ещё 75 терабайт сверху.

Но без LVM вместо того, чтобы расширять виртуальные диски по нужде, может потребоваться с самого начала выделить всё нужное место (ведь с обычными разделами не всегда можно просто увеличить диск, а потом раздел на нём, модет мешать соседний раздел) — в итоге вместо 125 терабайт нам нужно уже 200.

А это я ещё малые объемы подсчитал. С точки зрения бизнеса ты предлагаешь слить много бабла на незанятое ничем место, которое нельзя будет использовать для иного, просто потому, что LVM некрасивый.

А я здесь при чём? Это не я придумал. Это стандартный подход, который во множестве крупных компаний по всему миру используется. Я с этим работаю и только улучшаю/допиливаю под конкретные особенности.