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

Ceph 19.2.1: 2 OSD(s) испытывают медленную работу в BlueStore., Proxmox Виртуальная Среда

FrancisS

Guest

10.04.2025 09:02:00

Привет!

На наших кластерах 8.4.0 с момента обновления Ceph с версии 19.2.0 до 19.2.1 (pve2/pve3) у меня появились предупреждающие сообщения. Я применил "решение" по ссылке https://github.com/rook/rook/discussions/15403, но это не решило "проблему".

С уважением,
Francis

FrancisS Guest	#2 0 11.04.2025 10:01:00 Привет, Наконец-то я убрал "bdev_async_discard_threads" и "bdev_enable_discard", потому что думаю, что это создаёт ошибки ввода-вывода на некоторых SSD-дисках. С уважением, Фрэнсис.

Petr Svacina

Guest

16.04.2025 09:18:00

Привет, ребята, у меня та же проблема после обновления до CEPH 19.2.1... Конфигурация: 3 ноды: proxmox-ve: 8.4.0 (ядро: 6.8.12-9-pve) pve-manager: 8.4.1 ceph: 19.2.1-pve3 HEALTH_WARN: 2 OSD испытывают медленные операции в BlueStore osd.9 зафиксированы признаки медленной работы в BlueStore osd.15 зафиксированы признаки медленной работы в BlueStore Есть какие-нибудь успехи? Спасибо.

neodemus

Guest

11.04.2025 23:38:00

Определи, пожалуйста, что значит "remove" (удалить). Что именно ты сделал? Вот это? Bash: ceph config rm global bdev_async_discard_threads
ceph config rm global bdev_enable_discard видно через: ceph config dump с этим или без этого, у меня всё равно остались ошибки производительности OSD.

------------------------------------------
Редакция №2: Что помогло:
- добавление "bdev_async_discard_threads" и "bdev_enable_discard".
Как и предлагалось, не сработало.
- удаление "bdev_async_discard_threads" и "bdev_enable_discard" тоже ничего не изменило.
НО после того, как я это удалил, я освободил все хосты (8x2 кластер в конфигурации stretch) от ВМ.
Выключил сейчас -h, ждал целую минуту,
снова включил хост. Просто перезагрузка хоста не помогла!!!

FrancisS

Guest

12.04.2025 15:56:00

Да, это у меня происходит. Не работает и новые ошибки I/O DISCARD. Не работает. Пока что больше ошибок I/O DISCARD нет, перезагрузка не меняет проблему "медленного" OSD. Предупреждение о "медленном" OSD появляется после обновления Ceph с 19.2.0 до 19.2.1. С уважением, Франсис.

YAGA Guest	#6 0 13.04.2025 09:32:00 Привет, Фрэнсис! Не мог бы ты перезапустить OSD, вызывающий предупреждение о медленной работе, через GUI или CLI? Пожалуйста, проверь еще раз и держи нас в курсе. С уважением,

FrancisS Guest	#7 0 13.04.2025 18:38:00 Спасибо, Яга. Уже сделано, когда перезапускаю процесс OSDs, предупреждение о медленной работе исчезает, но через некоторое время сообщение появляется снова. С уважением, Фрэнсис.

FrancisS Guest	#8 0 14.04.2025 10:19:00 Привет, я установил PVE 8.4.1 и перезапустил все "медленные" OSD, пока что предупреждений о "медленных" нет. С наилучшими пожеланиями, Фрэнсис.

FrancisS Guest	#9 0 14.04.2025 10:27:00 Привет! Наконец-то снова получил это "медленное" предупреждение. Фрэнсис

wassupluke Guest	#10 0 14.04.2025 19:03:00 Такая же проблема. Подписался, чтобы следить за развитием событий.

rolandkim.amaro Guest	#11 0 15.04.2025 02:25:00 Привет, по, у меня тоже возникает это предупреждение: Кто-нибудь из вас решил эту проблему? У меня это появилось после обновления и апгрейда PVE до 8.3.5, а версия ceph теперь 17.2.8. С наилучшими пожеланиями, Ким.

Edwin_prox Guest	#12 0 15.04.2025 10:30:00 И у меня так же (osd.0 и osd.1). osd.0 зафиксировал признаки медленной работы в Bluestore, а osd.0 зафиксировал признаки заблокированного чтения в устройстве DB. Я использую pve-manager 8.4.1, kernel 6.8.12-9-pve и ceph version 17.2.8.

wuwzy

Guest

#13

16.04.2025 03:54:00

Да, у меня та же проблема. Окружение: 3 ноды Proxmox-VE: 8.4.0 (ядро: 6.8.12-9-pve) pve-manager: 8.4.1 (версия: 8.4.1/2a5fa54a8503f96d) ceph: 19.2.1-pve3 ceph-fuse: 19.2.1-pve3 Последние патчи применены. Сообщение об ошибке: HEALTH_WARN: 3 OSD испытывают медленную работу в BlueStore osd.8 зафиксировано замедление работы в BlueStore osd.14 зафиксировано замедление работы в BlueStore osd.15 зафиксировано замедление работы в BlueStore До этого было 6 ошибок OSD. Я перезагружал узлы кластера по одному, и они возвращались в нормальное состояние, но на следующий день опять появилась эта проблема.

itNGO

Guest

#14

16.04.2025 09:20:00

Стирающее кодирование или зеркалирование?

В последнее время в облачном хранилище возник горячий спор: что лучше для защиты данных – стирающее кодирование (Erasure Coding) или зеркалирование (Mirroring)? Давайте разбираться.

**Зеркалирование (Mirroring): Простота и скорость восстановления**

* Самый простой вариант: данные дублируются на несколько дисков.
* Восстановление занимает считанные минуты, так как нужно просто скопировать данные с резервной копии.
* Но тут есть загвоздка: для хранения данных требуется в 2-3 раза больше места.

**Стирающее кодирование (Erasure Coding): Эффективность и экономия места**

* Данные разбиваются на части, добавляются контрольные блоки, а затем распределяются по разным дискам.
* При выходе из строя одного или нескольких дисков, данные можно восстановить, используя остальные блоки.
* Круто то, что для хранения данных требуется значительно меньше места – например, в 6 раз меньше, чем при зеркалировании.
* Но восстановление данных занимает больше времени – от нескольких минут до часа, в зависимости от конфигурации.

**Так что же выбрать?**

Зависит от ваших приоритетов:

* **Нужна максимальная скорость восстановления?** Берите зеркалирование.
* **Хотите сэкономить место?** Стирающее кодирование – ваш выбор.

#cloudstorage #datacopying #erasurecoding #mirroring

Petr Svacina Guest	#15 0 16.04.2025 09:23:00 Баг Ceph? https://github.com/rook/rook/discussions/15403

Petr Svacina Guest	#16 0 16.04.2025 09:24:00 ?

itNGO Guest	#17 0 16.04.2025 09:28:00 CLI-> pveceph pool get POOLNAME

Petr Svacina

Guest

#18

16.04.2025 09:33:00

root@pve1:~# pveceph pool get cephfs_data
┌────────────────────────┬─────────────────┐
│ key │ value │
╞════════════════════════╪═════════════════╡
│ crush_rule │ replicated_rule │
├────────────────────────┼─────────────────┤
│ fast_read │ 0 │
├────────────────────────┼─────────────────┤
│ hashpspool │ 1 │
├────────────────────────┼─────────────────┤
│ id │ 1 │
├────────────────────────┼─────────────────┤
│ min_size │ 2 │
├────────────────────────┼─────────────────┤
│ name │ cephfs_data │
├────────────────────────┼─────────────────┤
│ nodeep-scrub │ 0 │
├────────────────────────┼─────────────────┤
│ nodelete │ 0 │
├────────────────────────┼─────────────────┤
│ nopgchange │ 0 │
├────────────────────────┼─────────────────┤
│ noscrub │ 0 │
├────────────────────────┼─────────────────┤
│ nosizechange │ 0 │
├────────────────────────┼─────────────────┤
│ pg_autoscale_mode │ on │
├────────────────────────┼─────────────────┤
│ pg_num │ 512 │
├────────────────────────┼─────────────────┤
│ pg_num_min │ 128 │
├────────────────────────┼─────────────────┤
│ pgp_num │ 512 │
├────────────────────────┼─────────────────┤
│ size │ 3 │
├────────────────────────┼─────────────────┤
│ use_gmt_hitset │ 1 │
├────────────────────────┼─────────────────┤
│ write_fadvise_dontneed │ 0 │
└────────────────────────┴─────────────────┘

FrancisS

Guest

#19

16.04.2025 15:59:00

Привет, ошибка в Ceph? https://github.com/rook/rook/discussions/15403 Решение проблему не решает.
# pveceph pool get pool_vm
┌────────────────────────┬─────────────────┐
│ key │ value │
╞════════════════════════╪═════════════════╡
│ crush_rule │ replicated_rule │
├────────────────────────┼─────────────────┤
│ fast_read │ 0 │
├────────────────────────┼─────────────────┤
│ hashpspool │ 1 │
├────────────────────────┼─────────────────┤
│ id │ 2 │
├────────────────────────┼─────────────────┤
│ min_size │ 2 │
├────────────────────────┼─────────────────┤
│ name │ pool_vm │
├────────────────────────┼─────────────────┤
│ nodeep-scrub │ 0 │
├────────────────────────┼─────────────────┤
│ nodelete │ 0 │
├────────────────────────┼─────────────────┤
│ nopgchange │ 0 │
├────────────────────────┼─────────────────┤
│ noscrub │ 0 │
├────────────────────────┼─────────────────┤
│ nosizechange │ 0 │
├────────────────────────┼─────────────────┤
│ pg_autoscale_mode │ on │
├────────────────────────┼─────────────────┤
│ pg_num │ 512 │
├────────────────────────┼─────────────────┤
│ pgp_num │ 512 │
├────────────────────────┼─────────────────┤
│ size │ 3 │
├────────────────────────┼─────────────────┤
│ target_size_ratio │ 1 │
├────────────────────────┼─────────────────┤
│ use_gmt_hitset │ 1 │
├────────────────────────┼─────────────────┤
│ write_fadvise_dontneed │ 0 │
└────────────────────────┴─────────────────┘

С уважением.
Francis

wuwzy Guest	#20 0 17.04.2025 03:59:00 Я провожу тест. Шаги: 1. Сначала используйте `ceph config dump`, чтобы проверить. 2. Введите команду снова: `ceph config set global bdev_async_discard_threads 1 ceph config set global bdev_enable_discard true`. 3. Снова используйте `ceph config dump`, чтобы проверить, работает ли это. Я жду уже 30 минут. Предупреждение не исчезает автоматически. Сейчас собираюсь перезагрузить ноду, это временно устранит проблему, но обычно на следующий день снова появится сообщение об ошибке. Мне нужно время, чтобы вам отчитаться. Если команда не решает проблему, можете использовать следующие команды, чтобы удалить две добавленные настройки и вернуть их в исходное состояние: `ceph config rm global bdev_async_discard_threads ceph config rm global bdev_enable_discard`

Читают тему

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