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

Снимки RBD в Ceph зависают, когда в LXC смонтирована файловая система ceph-fuse., Proxmox Виртуальная Среда

zdude

Guest

20.02.2024 13:30:00

Пытаюсь настроить систему резервного копирования для моей системы. Система использует гиперконвергентный Ceph-кластер с не привилегированными контейнерами LXC, образ контейнера находится в пуле Ceph RBD. В некоторых контейнерах смонтирована файловая система Ceph через ceph-fuse. Если я делаю снимок контейнера, у которого нет смонтированной файловой системы cephfs, то все работает корректно. Если я делаю снимок контейнера с смонтированной файловой системой cephfs и без открытых файлов из монтирования (в теории, это зависит от того, когда и как происходит сбой), то все работает корректно. Если я делаю снимок контейнера с смонтированной файловой системой cephfs и хотя бы один файл открыт, то кажется, что он всегда сбоит. После того, как система не смогла сделать снимок, кажется, что есть заблокированный процесс какого-то рода, который требует перезагрузки хоста. После перезагрузки GUI Proxmox показывает, что снимок существует, но не является родителем "NOW". При непосредственном просмотре образа RBD снимка в образе нет. Единственное, что я могу найти и что может быть релевантно, — это ошибка в syslog, указывающая на то, что мой ключ администратора Ceph отсутствует (затем ошибка ключа), хотя он очень даже есть. Похоже, что не-root процесс пытается прочитать ключ администратора Ceph, но я не могу найти никакого такого процесса. Кто-нибудь сталкивался с чем-то подобным раньше и если да, то какие есть предложения, как это обойти?

zdude

Guest

02.04.2024 13:29:00

Перенёс свой апдейт отсюда: Я смог получить немного больше информации и выявить причину проблемы. Похоже, последовательность событий, приводящая к зависанию PVE, выглядит так: LXC контейнер и монтирование fuse (любого типа) внутри контейнера (протестированы разные типы монтирования файловых систем корневого раздела). Запись процесса в файл внутри fuse монтирования в контейнере (в моей тестовой среде я просто использовал FIO) вроде бы не вызывает проблем. Создание снапшота корневого раздела для LXC контейнера. Я также нашёл этот отрывок из документации Proxmox: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pct_container_storage Похоже, это достаточно известная проблема. К сожалению, создание 50000 bind монтирований на хосте для меня просто нереально.

Alwin Antreich

Guest

02.04.2024 18:04:00

Я не имел в виду это, когда говорил о директорийном хранилище. Ты можешь создать хранилище на смонтированной CephFS [0] как директорийное хранилище. И ты можешь добавить туда том для LXC как директорию [1]. Или просто использовать его как есть, тогда будут создаваться raw-образы и всё будет работать через веб-интерфейс, out-of-the-box. Если это не то, то я не понимаю, что ты хочешь. [0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#storage_directory [1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_storage_backed_mount_points

alexskysilk

Guest

02.04.2024 18:52:00

Это не специфично для CephFS – это проблема любых монтирований внутри контейнера. Если вам так обязательно нужно работать, убедитесь, что внешняя файловая система смонтирована в конкретном месте (например, /mnt) и исключена из резервного копирования (--exclude-path в конфигурации задания резервного копирования).

zdude

Guest

03.04.2024 13:09:00

Согласно настройке, описанной в этом посте, все равно не работает. Резервное копирование завершается неудачей на этапе снимка. Кажется, директива exclude-path начинает использоваться только во время вывода данных. https://forum.proxmox.com/threads/p...irectories-from-lxc-backups.64241/post-636511. Мой случай — большое количество контейнеров Docker (на данный момент 722) внутри контейнера LXC, каждый со своими собственными тонкими разрешениями к файловой системе ceph-fs. Настроенным таким образом, каждый контейнер Docker может самостоятельно монтировать и управлять собственной точкой монтирования fuse. Управлять сотнями точек монтирования с хоста и передавать их индивидуальным контейнерам внутри LXC просто нереально. Я понимаю, что рекомендуется запускать Docker внутри VM, однако я обнаружил, что использование общего ядра между контейнерами LXC значительно снижает общее использование памяти. Запуск внутри VM потребовал дополнительных 115 ГБ памяти в ходе тестирования. Мое текущее решение этой проблемы — делать резервное копирование при остановке в самое тихое время недели. Пока что все работает довольно хорошо, единственная проблема — это ошибка последовательности выключения, оставляющая контейнер Docker с оторванной точкой монтирования, препятствующей перезапуску контейнера LXC.

Alwin Antreich

Guest

03.04.2024 17:10:00

Сопоставление ID для контейнера без привилегий — действительно проблема в данном случае. И да, рекомендовано запускать Docker в виртуальных машинах. А вы пробовали использовать KSM для уменьшения объема используемой памяти? Мы используем это даже в виртуальных машинах для нашего небольшого количества контейнеров Docker. В любом случае, это самый безопасный способ делать бэкапы.

Alwin Antreich Guest	#7 0 02.04.2024 10:42:00 Клиент CephFS fuse — это пользовательский процесс, монтирующий удаленное хранилище (даже если оно гиперконвергированное). Он не знает о сделанных снимках хранилища. https://docs.ceph.com/en/latest/cephfs/mount-using-fuse/ Возможно, тебе больше повезет с директорией хранилища, расположенной на cephfs.

Читают тему

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