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

После обновления до Ceph Reef стали возникать переполнения БД., Proxmox Виртуальная Среда

BloodBlight

Guest

28.04.2024 20:36:00

У меня немного необычная конфигурация, но, думаю, ничего критичного. У меня по 2 OSD (HDD) на каждый DB/WAL устройство. DB — это SSD, а WAL — крошечный Optane. Это на трехузловом кластере с erasure encoding и пользовательским алгоритмом балансировки (который я сам придумал). Ну, с "необычностью" разобрались. После обновления до Ceph Reef (не сразу, примерно через два дня) я стал получать это предупреждение: Код: 4 OSD переживают BlueFS spillover. Детали состояния Ceph показывают: Код: [WRN] BLUEFS_SPILLOVER: 4 OSD переживают BlueFS spillover.

osd.3 пролило 3.2 GiB метаданных с устройства 'db' (используется 19 GiB из 45 GiB) на медленное устройство.
osd.4 пролило 4.3 GiB метаданных с устройства 'db' (используется 19 GiB из 45 GiB) на медленное устройство.
osd.5 пролило 3.1 GiB метаданных с устройства 'db' (используется 20 GiB из 45 GiB) на медленное устройство.
osd.6 пролило 4.5 GiB метаданных с устройства 'db' (используется 18 GiB из 45 GiB) на медленное устройство. Отмечу, что объем пролитых данных очень мал по сравнению с размером DB и их свободным пространством (у каждого более 50% свободно). Я проверил bluestore_max_alloc_size, он установлен в 0 на всех OSD.... Какие идеи? Что стоит проверить?

BloodBlight

Guest

30.04.2024 04:04:00

Небольшая поправка к этому. OSD 3, кажется, уменьшил свой пролив, а другие – увеличили. На данный момент нет репликации, и в целом очень мало операций ввода-вывода... OSD 5, кажется, увеличился более чем на гигабайт данных DB. Это кажется действительно странным. Код: [WRN] BLUEFS_SPILLOVER: 4 OSD(s) experiencing BlueFS spillover
osd.3 пролил 3.1 GiB метаданных с устройства 'db' (использовано 20 GiB из 45 GiB) на медленное устройство.
osd.4 пролил 4.6 GiB метаданных с устройства 'db' (использовано 19 GiB из 45 GiB) на медленное устройство.
osd.5 пролил 4.3 GiB метаданных с устройства 'db' (использовано 19 GiB из 45 GiB) на медленное устройство.
osd.6 пролил 4.7 GiB метаданных с устройства 'db' (использовано 18 GiB из 45 GiB) на медленное устройство.

BloodBlight Guest	#3 0 14.05.2024 01:40:00 И тут, после нескольких недель, ошибка просто исчезла. Объяснений никаких…

nh2

Guest

06.08.2024 05:46:00

Возможно, проблема в этом: https://tracker.ceph.com/issues/44509#note-8. Я могу исправить это на своем кластере, используя Bash: ceph tell 'osd.*' compact, что уменьшило переполнение до нескольких KiB на OSD, а затем скрипт, ссылка на который указана выше.

quanto11 Guest	#5 0 26.04.2025 14:13:00 Метод, который упомянул nh2, работает. Вот пример для osd1 тем, кто не хочет искать его самому:

Uberduck Guest	#6 0 23.05.2025 01:22:00 Мой кластер выдал 21 штуку такого после обновления, так что я написал скрипт, чтобы разобраться. Bash: #!/bin/bash set -ex export OSD=$1 export FSID=$(ceph-volume lvm list ${OSD} \| grep -m 1 "osd fsid" \| awk '{print $3}') export VG_NAME=$(ceph-volume lvm list ${OSD} \| grep '\[block\]' \| awk '{print $2}' \| awk -F '/' '{print $3"/"$4}') systemctl stop ceph-osd@${OSD}.service ceph-volume lvm migrate --osd-id ${OSD} --osd-fsid ${FSID} --from db wal --target ${VG_NAME} systemctl start ceph-osd@${OSD}.service Использование, чтобы исправить OSD 1-7 на хосте: Bash: for x in 1, 2, 3, 4, 5, 6, 7; do ./migrate_db.sh $x; done Это нужно запускать на каждом хосте только для OSD, которые на нём есть. Также, это скрипт, который делает вещи в вашей Ceph-установке без подтверждения и предоставляется только в качестве примера. Делайте бэкапы и всё такое.

Читают тему

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