+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Можно ли перенести диск CEPH между узлами?, Proxmox Виртуальная Среда

proxwolfe

Guest

13.09.2022 21:18:00

Привет! У меня небольшой кластер из трех узлов на PVE и CEPH. Скоро собираюсь заменить узлы на новое оборудование. В связи с этим интересно, можно ли перенести диски CEPH с заменяемого узла на новую систему? Если нет, то, полагаю, придётся добавить новый узел с новым диском CEPH, вынуть один из старых дисков CEPH из узла, который нужно заменить, заново сбалансировать всё, чтобы скопировать данные на новый диск, и потом убрать старый диск CEPH. И так для каждого узла, который нужно заменить, при этом данные до и после будут одинаковыми. Звучит как куча копирования и времени, которое я бы хотел сэкономить. Так можно это сделать? Спасибо!

FarVision

Guest

25.10.2022 22:16:00

Как так, кстати, — использую кластер из 3 узлов с 4-хбайтовым esata-шасси на каждом, получается 12 дисков всего. Шасси умирает, и я переставляю диски на другой узел физически. GUI видит диски на новом узле как LV2_member. OSD In или Start не работает, потому что OSD-шки находятся в статусе "Out" на старом узле. Ceph не балансирует, потому что ожидает, что диски вернутся. Разрушить – единственный вариант? Хотелось бы что-то вроде Import или чтобы он распознал диски как члены OSD.

alexskysilk Guest	#3 0 25.10.2022 23:41:00 Обязательно убедись, что узлы и диски находятся в ТОЧНО ТЕХ же позициях, что и в исходном корпусе – иначе получишь не тот узел, обращающийся к дискам.

kyriazis

Guest

03.11.2022 00:22:00

В том же духе, у меня похожая проблема: хочу заменить загрузочный диск Proxmox на больший. Кажется, самый простой способ — это: (a) мигрировать ВМ/КТ на другие ноды (b) выключить машину и обновить оборудование © переустановить Proxmox на новый загрузочный диск (d) удалить старую версию ноды из Proxmox (e) добавить новую ноду в кластер. Теперь, OSD не сдвинулись ни на миллиметр, однако в /var/lib/ceph/osd нет записей для них. Лучше ли удалить и добавить OSD заново (хотя данные там уже есть), и таким образом затеять долгую миграцию, или можно как-то пересоздать директории /var/lib/ceph/osd? Можно ли просто сделать бэкап содержимого этих директорий со старой версии диска и восстановить их на новой? Спасибо!

FarVision

Guest

03.11.2022 00:34:00

Да и нет. Можно менять порядок дисков в корпусе, и он их найдёт. Можно даже поменять корпус, если понадобится, например, у меня были проблемы с eSATA корпусом, и я поставил USB 3 корпус. После перезагрузки он обнаружил все четыре диска Ceph. Проблема возникает, когда ты экспериментируешь с кучей железа и случайно вставляешь старый диск, который ты не уничтожил как следует. И вдруг у тебя два OSD, двойки, и куча красных ошибок. Если ты достаточно быстро поймёшь, что происходит, можно вытащить диск, а иначе будут какие-то недействительные блоки, которые в итоге, если повезёт, вычистятся при глубокой проверке. К счастью, это лаборатория, и реальные данные не были потеряны, но я ценю самовосстанавливающуюся природу системы, которая перераспределяет всё вокруг.

FarVision Guest	#6 0 03.11.2022 00:35:00 Если бы я этим занимался, я бы использовал что-то вроде Clonezilla, чтобы клонировать загрузочный диск на другой и расширить пространство. Я не совсем уверен, сможет ли gparted это сделать.

kyriazis Guest	#7 0 03.11.2022 01:00:00 Да, я думал об этом, но не уверен, как работать с tmeta разделами... Если у тебя есть какие-нибудь мысли, буду рад послушать.

FarVision

Guest

03.11.2022 01:11:00

Я бы, наверное, сам немного нервничал и скорее всего сразу создал бы образ Clonezilla или Macrium – как спасательный круг. Собственно, если у тебя есть внешний USB-корпус, ты можешь сделать загрузочный ISO Macrium из их бесплатной версии и посмотреть, что он обнаружит. Он довольно хорошо клонирует. Любые дополнительные узлы, которые я добавлю, будут только узлами обработки. Если бы мне пришлось добавить локальное хранилище, я, вероятно, просто добавил бы диск, отформатировал бы его как ZFS и поставил бы флаг 'VM Repository'. Тогда можно будет перенести данные на это хранилище. Придется посмотреть, как это работает.

alexskysilk

Guest

03.11.2022 01:29:00

В общем, это довольно просто сделать в офлайне: клонируйте загрузочный диск на новый (больший) диск, перезагрузитесь и измените размер по мере необходимости; нет необходимости переустанавливать или что-то менять в настройках кластера. Это можно сделать с любого linux livecd. (Только что заметил, что @FarVision уже предложил это – используйте Clonezilla. Не пытайтесь это сделать на смонтированной файловой системе корневого раздела.) Комментарий был специфичен для конфигурации с 4 узлами в шасси, о которой спрашивал пользователь. Вы правы, если нужные диски представлены нужным узлам. Я... не буду вам говорить, что это плохой способ работы с Ceph...

kyriazis

Guest

#10

03.11.2022 01:43:00

Clonezilla, скорее всего, то, что я буду использовать, ведь у нас оно уже есть на PXE-сервере, и мы довольно давно используем его для клонирования и резервного копирования физических машин. Просто я не уверен, как менять размер разделов tmeta, которые использует Proxmox..

FarVision

Guest

#11

03.11.2022 03:28:00

Это был интересный опыт обучения! Ceph фактически остановил автобус и отключил отдельные диски, чтобы система продолжала работать. Журналы были довольно крутые. Четыре диска были установлены во внутренний SATA-отсек. eSATA HBA по какой-то причине вызывал сбой и отключал отсек для дисков. Маленькая Rosewill пожертвовала собой ради дела. Подписи Ceph все собрались отлично, раз уж я всё делаю на каждом диске. Внешний корпус дисков пока отложил в сторону для чего-то другого. А ещё... USB2 в экстренной ситуации никогда не догонит. Возрождаю старое железо и смотрю, что будет. USB2 корпус работает нормально для PBS ZFS RAIDz.

kyriazis

Guest

#12

07.11.2022 22:33:00

Оказывается, Clonezilla — не решение. Он сбивается с толку из-за разделов tmeta и просто "задыхается", даже в режиме "dd". В итоге у меня получилось следующее:

- убедитесь, что нет демонов mgr/mds/mon и нет VM/CT на узле
- заархивируйте /var/lib/ceph на старом диске и сохраните где-нибудь в сети
- замените загрузочный диск и переустановите систему с нуля
- удалите старый узел из кластера
- добавьте "новый" узел в кластер
- восстановите tar-файл из вышеуказанного в /var/lib/ceph
- запустите следующий скрипт, который восстанавливает симлинк для ceph.conf и настраивает симлинки systemd, чтобы правильно настроить OSD:

Code: #!/bin/bash -x

# восстановить /etc/ceph/ceph.conf
cd /etc/ceph
rm -f ceph.conf
ln -s /etc/pve/ceph.conf .

# исправить файлы systemd
cd /etc/systemd/system/multi-user.target.wants
for a in $(ls /var/lib/ceph/osd); do
name=`echo $a | sed 's/ceph-//'`
ln -s /lib/systemd/system/ceph-volume@.service ceph-volume@lvm-$name-`cat /var/lib/ceph/osd/$a/fsid`.service
done и наконец перезагрузиться. Работает как по маслу.

FarVision Guest	#13 0 16.11.2022 17:08:00 Интересно. У тебя не было несоответствий в pgs? Я большой поклонник Ceph, но не помню, когда в последний раз у меня был зеленый статус. Всегда какая-нибудь ерунда.

kyriazis

Guest

#14

18.11.2022 23:29:00

Без несоответствий.. Есть небольшая задержка при запуске OSD, пока они не синхронизируются, но это то же самое, что и если нода была недоступна какое-то время, и OSD нужно наверстать. У меня занимает меньше времени, я точно понимаю, что ты имеешь в виду под "зелёным статусом". Всегда что-то найдется... Возможно, можно вручную создать записи OSD под /var/lib/ceph/osd, используя информацию из других источников, не нужно будет архивировать весь /var/lib/ceph, но это работает, и я доволен этим. Скрипт делает 2 вещи: 1. пересоздает симлинк из /etc/pve/ceph.conf в /etc/ceph/ceph.conff 2. пересоздает симлинки в /etc/systemd. Вот это странно. Без этих файлов startup systemd, /dev/dm-* соответствующие OSD, не имеют правильного владельца (он был бы root, а не пользователь ceph). Если проследовать симлинкам /var/lib/ceph/osd/osd.*/block, то попадешь к файлам /dev/dm, и без правильных разрешений OSD не запустятся.

FarVision

Guest

#15

19.11.2022 15:12:00

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

kyriazis Guest	#16 0 21.11.2022 02:59:00 Как я вижу, если этот метод не сработает, то какая альтернатива? Стереть диски и дать Ceph самому все сделать. В любом случае, попытка — это уже победа.

dlasher Guest	#17 0 10.01.2023 21:27:00 Украл немного информации из другой темы – недавно сам это проходил, решил поделиться тем, что сработало на 100% – уже около 20 дисков перенес, никаких проблем. ВАЖНО: это предполагает, что DB/WAL находятся на одном физическом диске. Если это не так, сначала нужно их консолидировать, а потом переносить. ((ceph-volume lvm migrate --osd-id <ID> --osd-fsid <FSID> --from db wal --target <FULL VG PATH>)) ORIGIN SERVER (исходный сервер): 1. Найди значения, которые тебе нужны для продолжения . FSID=cat /var/lib/ceph/osd/ceph-<ID>/fsid VG-ID=ls -l /var/lib/ceph/osd/ceph-<ID>/block \| cut -f2 -d">" \| cut -f3 -d"/" 2. Пометь OSD как out <ID> 3. systemctl stop ceph-osd@<ID>.service 4. ceph-volume lvm deactivate <ID> <FSID> 5. Vgchange -a n <VG-ID> 6. vgexport <VG-ID> вынь диск из сервера --> --> вставь диск в другой сервер DESTINATION SERVER (целевой сервер): 1. Pvscan 2. vgimport <VG-ID> 3. vgchange -a y <VG-ID> 4. ceph-volume lvm activate <ID> <FSID> 5. ceph osd in <ID> 6. ceph osd crush set <ID> <WEIGHT/SIZE> host=<NEWHOST> 7. systemctl status ceph-osd@<ID>.service Кредит: https://forum.proxmox.com/threads/osd-move-issue.56932/post-263918

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры