Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Высокий ввод-вывод задержки после потери ноды.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Высокий ввод-вывод задержки после потери ноды., Proxmox Виртуальная Среда
     
    flotho
    Guest
    #1
    0
    09.07.2025 11:55:00
    Привет, у нас есть 4-узловой кластер с Ceph, установленный на 4 дисках на узел, то есть 16 OSD, и используется только 50%. Все диски NVMe, планировщик настроен с опцией mq-deadline в /sys/block/nvmeXXX/queue/scheduler. У узлов достаточно оперативной памяти и CPU.

    Сегодня один из узлов был выключен, и мы ожидали, что оставшиеся 3 узла будут работать "нормально". В итоге 3 доступных узла перегружены с очень высоким serverload и очень высоким IO Delay.

    iostat -x 1 показывает, что RDB потребляет много ресурсов Это кажется странным, поэтому я попробовал отключить некоторые опции: Тем не менее, iodelay и server load остаются очень высокими. Я даже попробовал снизить приоритет операций чем-то вроде:

    Code: ceph tell 'osd.*' injectargs --osd-max-backfills=1 --osd-recovery-max-active=3 --osd_recovery_op_priority=30

    Буду признателен за любые советы или рекомендации.

    С уважением
     
     
     
    flotho
    Guest
    #2
    0
    09.07.2025 12:11:00
    Дополнительная информация: HA пока не активирована. Когда сервер оживет, все должно заработать как часы. Мы выясняем, почему другие узлы так бурно реагируют на эту ситуацию.
     
     
     
    flotho
    Guest
    #3
    0
    09.07.2025 13:21:00
    Состояние Ceph показывает только предупреждения: , но iodelay все равно очень высокий.
     
     
     
    flotho
    Guest
    #4
    0
    09.07.2025 14:11:00
    Хм, кажется, это приоритетная проблема в операциях. Когда восстановление закончилось, задержки ввода-вывода уменьшились, и все работает нормально на трех узлах. Что я могу настроить, чтобы отдавать приоритет использованию клиентами, когда нет "аварийной ситуации"? С уважением.
     
     
     
    flotho
    Guest
    #5
    0
    09.07.2025 14:53:00
    Хм, кажется, я понял, что произошло. Конфа Ceph выглядит так: Насколько я понимаю, если OSD упал, то есть большая вероятность, что отсутствие OSD будет расценено как аварийная ситуация, и система среагирует, чтобы перераспределить отсутствующие PG. Я правильно понимаю?
     
     
     
    SteveITS
    Guest
    #6
    0
    09.07.2025 16:09:00
    Если копий меньше, чем min_size, ввод-вывод приостановится до тех пор, пока min_size не станет доступен. osd_pool_default_size = 3 # Записывать объект три раза. osd_pool_default_min_size = 2 # Принимать операции ввода-вывода на PG, в котором есть две копии объекта.
     
     
     
    flotho
    Guest
    #7
    0
    09.07.2025 21:42:00
    Спасибо, @SteveITS! Если я изменю этот параметр, Ceph создаст все "пропущенные группы размещения" (PG) и задействует 50% дополнительного дискового пространства?

    С уважением,
     
     
     
    SteveITS
    Guest
    #8
    0
    09.07.2025 22:16:00
    Если оставить параметр на 2/2 и разрешить восстановление (norecover=off), то Ceph со временем догонит/восстановится и позволит виртуальным машинам функционировать, как только все группы размещения (PG) для виртуальной машины будут иметь 2 валидных копий. Если установить значение 3/2, то да, это потребует больше места для хранения, но у вас будет запас, так что выход одного OSD не заблокирует группы размещения, у которых есть только 2 активных копии, потому что уже будут другие 2 копии PG. По умолчанию 3 копии находятся на разных узлах, так что для блокировки ввода-вывода нужно, чтобы вышли из строя два узла.
     
     
     
    VictorSTS
    Guest
    #9
    0
    10.07.2025 11:29:00
    Это, по сути, делает кластер бесполезным: как только выходит из строя хоть один OSD, ввод-вывод по PG, хранящимся на этом OSD, прекращается до тех пор, пока они не будут восстановлены из единственной копии, оставшейся в кластере. Всегда используйте, как минимум, size=3, min_size=2, если вы не готовы к таким простоям. Не говоря уже о риске отказа другого OSD одновременно, который может содержать другую копию тех же PG... Ввод-вывод, который вы видите, – это диски ваших ВМ, а не диск хоста, и вызван блокировкой ввода-вывода Ceph из-за наличия менее чем min_size копий некоторых PG, как объяснил SteveITS выше. Ваши ВМ пытаются выполнить ввод-вывод, Ceph не разрешает это до восстановления, ВМ накапливают все больше и больше процессов, ожидающих ввода-вывода, и так далее.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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