Миграция zfs на другой пул

Репликация send | receive с инкрементальной досылкой данных.

Но перед последней финальной досылкой придётся таки кратковременно тормознуть сервисы перед окончательным переключением.

Только зачем так делать? Такое IMHO полезно в случае полной замены оборудования или для дефрагментации свободного места в пуле.

Нет, тебе придётся перемонтировать разделы. Либо заранее смонтируй оба пула в overlayfs какой-нибудь, нояхз как это будет работать.

Да. Например, можно перенести работающую систему в RAM на время переноса.

Но скорее всего для этого нужно либо большой объём ОЗУ, либо небольшой объём системного пула.

Я так систему со страйпа на зеркало переносил.

Проворачивал такое на живом сервере с фряхой. Сделал рекурсивно снапшоты всех датасетов и при помощи zfs send переслал на другой сервак. Загрузил сервак, досинкал изменения и сразу же переключил. Даунтайм был около 30 сек, пока айпишник переключился.

Тормознуть на 1 сек это конечно лучше чем на несколько часов, но хотел избежать выключения/включения вообще. Ну ладно, видимо нельзя.

но хотел избежать выключения/включения вообще. Ну ладно, видимо нельзя.

Если использовать HA хранилку например, на базе DRBD и т.п.,

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

Но таки один раз надо сначала перейти на это с остановкой.

https://linbit.com/linstor/

Да. Например, можно перенести работающую систему в RAM на время переноса.

Какая разница, куда переносить, остановка будет нужна, если это не пул с распределёнными по разным узлам зеркалами типа DRBD, CEPH, etc.

офигеть, ну и советы пошли…

если это не пул с распределёнными по разным узлам зеркалами типа DRBD, CEPH, etc.

А как ты узнал, что у него пул на разных узлах?

ps: Пардон, не заметил «не».

Какая разница, куда переносить, остановка будет нужна

Мне не нужна была.

офигеть, ну и советы пошли…

Это не совет для его use кейса, а в целом, если подобные миграции планируются регулярно.

Я бы не рискнул связывать с OpenZFS в проде без DRBD, уже писал об этом.

А как ты узнал, что у него пул на разных узлах?

У него только попытка переноса на другой узел, насколько я понял. Т.е. вероятно у него пул на одном узле.

DRBD (неглючных версий) позволил бы в будущем не заморачиваться с send | receive и остановками.

Сомневаюсь, что это последняя его миграция пула. Через полгода-год он опять захочет мигрировать, и что тогда?

Мне не нужна была.

А как твой софт без остановки переключился на новую локацию?

У него только попытка переноса на другой узел, насколько я понял.

А как ты это понял, что именно на другой узел, а не просто на другой диск? ))

Мне не нужна была.

А как твой софт без остановки переключился на новую локацию?

Так я и не менял локацию, делал всё на одном ПК, просто диск заменил на другой, пока ОС в раме крутилась. (=

А как ты это понял, что именно на другой узел, а не просто на другой диск? ))

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

Так я и не менял локацию, делал всё на одном ПК, просто диск заменил на другой, пока ОС в раме крутилась. (=

Ты заменил диск в пуле или заменил пул на новый?

Ты заменил диск в пуле или заменил пул на новый?

Заменил именно диск, да. Ну раз пул остался старым, то очевидно, для дефрагментации не подходит.

Как же всё сложно с вами.. Но ТС и не уточнял для чего ему)

Если тебе перенести на другой диск равного или большего размера, но с сохранением пула, то можно через attach нового диска в mirror, затем дождаться завершения resilver, затем detach старый из пула. Не требуется ни перезагрузки, ничего.

Если нужно перенести на диск меньшего размера, то snapshot, send|recv, без вариантов.

Если нужно перенести на диск меньшего размера, то snapshot, send|recv, без вариантов.

Можно добавить новый диск меньшего размера в качестве нового отдельного vdev, а старые vdev вытолкнуть.

Только навряд ли это про прод, который нельзя тормознуть :)

Нежный прод, чувствительный к аптайму нужно хостить на хранилке с HA кластером типа DRBD или по слухам хотя бы на standalone Illumos.

А лучше таки IMHO собрать DRBD кластер на разных ZFS:

• node1: OpenZFS on Linux
• node2: OpenZFS on FreeBSD
• node3: ZFS on Illumos (SmartOS)

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

А лучше таки IMHO собрать DRBD кластер на разных ZFS:

• node1: OpenZFS on Linux
• node2: OpenZFS on FreeBSD
• node3: ZFS on Illumos (SmartOS)

Эм… А ничего, что на всех трёх сильнейший рассинхрон features в виду серьёзного рассинхрона версий?

А ещё я сильно сомневаюсь, что GEOM Gate (ggated(8) и ggatec(8)), штатный набор из FreeBSD, совместим с DRBD.

attach нового диска

У него некуда новые диски вставлять.

Так перенос на RAM тоже не бесшовный. Так то можно и просто файлы на новый пул скопировать.

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

Так перенос на RAM тоже не бесшовный. Так то можно и просто файлы на новый пул скопировать.

Точно такой же, как и с заменой диска через mirror. Если resilver – это шов, то окей, я умываю руки. Но да, можно и скопировать, если нужно заменить пул, а не накопительное устройство.

Который рейд? raid-1 например и есть mirror

Ты сделал vdev из ram-диска что ли? Ну вообще да, никто не запрещает.

А по-другому наверно и нельзя, да, ведь если / оставить на физическом диске то его никак не размонтировать будет.

vdev из ram-диска что ли?

Да, md(4).

А зачем для копирования пула или файлов нужен размонтированый / ?

Эм… А ничего, что на всех трёх сильнейший рассинхрон features в виду серьёзного рассинхрона версий?

DRBD работает на блочном уровне поверх zvol.

Т.е. нужна ещё какая-то FS поверх виртуального блочного устройства DRBD, но к ней требования по надёжности хранения уже не такие высокие, возможно подойдёт и ext3/4, потому что основная нагрузка по сохранности данных (резервирование, чексуммы, HA, работа с оборудованием и т.п.) ложится на DRBD и ZFS пулы.

Преимущество использования DRBD в том, что с ним при падении одного из ZFS узлов DRBD кластера ты можешь переключать клиентов на другой iSCSI target без каких-то дополнительных восстановлений упавшего пула, репликаций его и т.п. Т.е. все данные виртуального блочного устройства DRBD доступны автоматически на остальных зеркальных узлах DRBD (хранящих свои данные в других пулах ZFS в т.ч. на другом софте FreeBSD, Illumos, etc.).

Ты сделал vdev из ram-диска что ли? Ну вообще да, никто не запрещает.

Только непонятно, зачем.

А по-другому наверно и нельзя, да, ведь если / оставить на физическом диске то его никак не размонтировать будет.

Подразумевается размонтирование / работающей системы на ходу без её выключения?

А зачем для копирования пула или файлов нужен размонтированый / ?

Я вообще потерял нить обсуждения.

1. Недостаточно точно понятно, что именно нужно ТС и зачем.

• Что за пул
• Что в нём находится (только данные или rootfs работающей системы тоже)
• Что замонтировано, и зачем
• Зачем нужна миграция
• Миграция в пределах одного узла или двух
• И т.д. и т.п.

А так мы обсуждаем свои сферические фантазии в вакууме.

2. Вот эти советы про RAM диск IMHO добавляют ещё больше бредятины и в без того в сумрачную тему …

Это не у меня, это у Clockwork - он рут-фс переносил сначала на рамдиск а потом назад на физический, но уже на другой, а рамдиск был нужен потому что слотов под два диска одновременно не было.

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

Создаёшь рамдиск, добавляешь его в пул как mirror, делаешь resilver (будет очень быстро), удаляешь из пула диск (с этого момента пропажа питания критична), вынимаешь старый диск, втыкаешь другой диск (матплата должна поддерживать SATA hutplug, разумеется), добавляешь новый диск в пул, делаешь resilver (после этого пропажа питания не критична), удаляешь рамдиск из пула. Я так когда-то давно переносил систему.

attach нового диска

У него некуда новые диски вставлять.

Расписал способ с рамдиском.

DRBD работает на блочном уровне поверх zvol.

В таком случае зачем лишняя абстракция в виде ZFS? Тем более разных.

Т.е. все данные виртуального блочного устройства DRBD доступны автоматически на остальных зеркальных узлах DRBD (хранящих свои данные в других пулах ZFS в т.ч. на другом софте FreeBSD, Illumos, etc.).

send|recv блочных zvol для восстановления вышедшего узла? На разных ZFS? Так и не понял смысла в разных ZFS.

Ты сделал vdev из ram-диска что ли? Ну вообще да, никто не запрещает.

Только непонятно, зачем.

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

В таком случае зачем лишняя абстракция в виде ZFS?

ZFS нужен только в качестве супернадёжного (по сравнению с другими вариантами) софтового пула с резервированием и чексуммами. Не уверен, как работают снэпшоты DRBD, самостоятельно или используют низлежащие абстракции типа ZFS/LVM, etc.

Тем более разных.

Диверсификация софтовых реализаций. Если разработчики одной из веток ZFS офакапятся, то вероятность выживания DRBD кластера выше за счёт вероятности отсутствия точно таких же багов в другой реализации ZFS. Если раньше не офакапится собственно сам DRBD, LOL, что кстати, с ним уже однажды случалось на уровне багов в коде DRBD. Поэтому админы Illumos предлагают вообще не использовать хранилищные HA кластера, а просто поднять ZFS on Illumos (SmartOS или OmniOS) на надёжной и проверенной железке и не мучиться с кластеризацией, по крайне мере, если SLA допускает время переключения с одного ZFS узла на другой как раз с обычными инкрементальными досылками снэпшотов. IMHO при желании такое переключение тоже можно свести к нескольким минутам или даже секундам ожидания (в зависимости от времени рестарта прикладной софтины, которая размещает свои данные в ZFS), что не так уж и критично.

удаляешь из пула диск (с этого момента пропажа питания критична)

Если пул из одного диска то не критична, старый можно всё так же назад воткнуть и ребутнуться с него. Для надёжности можно сначала его электрически отключить (перед этим сделав sync или может у zfs другой аналог) и только потом из пула удалить, чтоб метаданные точно правильные остались.

Создаёшь рамдиск, добавляешь его в пул как mirror, делаешь resilver (будет очень быстро),

Но ненадёжно, если крашнется целиком весь хост или сбойнет питание.

удаляешь из пула диск (с этого момента пропажа питания критична),

И просто зависание хоста и различные глюки, вплоть до зависания при подключении нового диска из-за его глючности.

вынимаешь старый диск, втыкаешь другой диск (матплата должна поддерживать SATA hutplug, разумеется), добавляешь новый диск в пул, делаешь resilver (после этого пропажа питания не критична), удаляешь рамдиск из пула. Я так когда-то давно переносил систему.

Камикадзе detected. LOL

Для этого не нужен размонтированный / -> здесь уже расписали. Это подразумевает то что, фактически / остаётся на месте, за счёт другого (виртуального) диска, который поддерживает пул одновременно.

Но ненадёжно, если крашнется целиком весь хост или сбойнет питание.

Если у тебя крашнется весь хост или сбойнет питание, то весь хост – это ненадёжно.

И даже если ты в этот момент не переносил ничего, получится простой и те же самые проблемы.

Если у тебя крашнется весь хост или сбойнет питание, то весь хост – это ненадёжно.

Речь о потенциальной возможности утере инфы в раме, если в пул постоянно пишется что-то новое.

И даже если ты в этот момент не переносил ничего, получится простой и те же самые проблемы.

Проблемы не те же самые. Остановка будет, утери новых данных на дисках в отличие от рамы не будет.

ZFS нужен только в качестве супернадёжного (по сравнению с другими вариантами) софтового пула с резервированием и чексуммами.

У тебя скорее диск сдохнет или память сбойнёт.

Диверсификация софтовых реализаций. Если разработчики одной из веток ZFS офакапятся, то вероятность выживания DRBD кластера выше за счёт вероятности отсутствия точно таких же багов в другой реализации ZFS.

Одна из реализаций в один "прекрасный" момент может просто отказаться принимать поток, приняв его за несовместимые данные.

Но ненадёжно, если крашнется целиком весь хост или сбойнет питание.

И просто зависание хоста и различные глюки, вплоть до зависания при подключении нового диска из-за его глючности.

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

удаляешь из пула диск (с этого момента пропажа питания критична)

Если пул из одного диска то не критична, старый можно всё так же назад воткнуть и ребутнуться с него. Для надёжности можно сначала его электрически отключить (перед этим сделав sync или может у zfs другой аналог) и только потом из пула удалить, чтоб метаданные точно правильные остались.

Ну, можно и просто вынуть диск, в таком случае пул будет в состоянии DEGRADED, но да, это сработает. Если же ты сделаешь штатную замену через detach, то как пул этот отделённый диск ты сможешь импортировать только с ключом -D.

У тебя скорее диск сдохнет или память сбойнёт.

Если ты сравниваешь с вероятностью обнаружения ошибок в OpenZFS или даже просто её нестабильностью вплоть до зависания пула до ребута всего хоста, то ты неправ. У меня дома никогда не помирали диски в пулах, проверенная оперативка тоже очень живучая даже без ECC. А вот подвисшие OpenZFS пулы я встречал, и даже приходилось перезагружать хост из-за таких подвисаний. А ещё иногда дурит resilvering после возврата offline устройств обратно в состояние online. Реализация OpenZFS очень сырая для использования в production. Именно поэтому и нужен DRBD кластер, чтобы если один пул начнёт капризничать, то можно было бы продолжать работу на другом пуле без downtime в то время, как приводишь мозги глючащего пула в нормальное состояние.

Одна из реализаций в один «прекрасный» момент может просто отказаться принимать поток, приняв его за несовместимые данные.

Синхронизация частей DRBD зеркала происходит на уровне DRBD, zfs send | receive при этом НЕ используется. Ещё раз, ZFS при использовании с DRBD нужен только вместо аппаратного рейда ибо в среднем сильно круче и надёжнее, несмотря на все свои глюки.

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

Я вообще не понимаю, что там нужно @firkax и зачем, уже просил уточнить.

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

Я вообще не понимаю, что там нужно firkax и зачем, уже просил уточнить.

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

Ты уже кучу бестолковых предложений выкатил,

Прояви свою ответственность, укажи на мои якобы «бестолковые предложения», чтобы не выглядеть пустобрехом.

а теперь самое время сказать, что не понимаешь

Так не теперь, а примерно в середине дискуссии:

Миграция zfs на другой пул (комментарий)

По твоему уточнять по ходу обсуждения это плохо или запрещено?

Синхронизация частей DRBD зеркала происходит на уровне DRBD, zfs send | receive при этом НЕ используется.

Для оффлайн синхронизации до введения узла в кластер. В противном случае я ещё больше не понимаю смысла в зоопарке разных версий/реализаций ZFS.

проверенная оперативка тоже очень живучая даже без ECC

Как ты можешь быть на 100% уверен в отсутствии повреждений данных в ОЗУ? Консьюмерская оперативка имеет свойство сходить с ума уже через три-четыре недели аптайма.