Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    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 Виртуальная Среда
    Помогите! Multipathing постоянно ломает мой корневой ZFS пул.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Помогите! Multipathing постоянно ломает мой корневой ZFS пул., Proxmox Виртуальная Среда
     
    Sp00nman
    Guest
    #1
    0
    15.05.2025 07:25:00
    Всем привет, Proxmoxers! У меня серьезная проблема, и я в отчаянии, не знаю, как ее решить:

    - У меня кластер из 18 узлов, каждый настроен с 2 x SATA SSD в ZFS raid1 для ОС и различных хранилищ, развернутых с использованием iSCSI и LVM thick provisioning для общего хранилища для узлов 1-7 кластера. Эти узлы были настроены в прошлом году с использованием ISO Proxmox 8.1. Узлы 8-18 были установлены в этом году с использованием ISO Proxmox 8.3 и затем 8.4.

    Узлы 1-7 работают без проблем, а у новых узлов 8-18 постоянно возникает эта проблема:

    - После нескольких перезагрузок (случайное количество) многопутевое подключение как-то повреждает мой пул ZFS, перемаркировывая диски, что приводит к следующему:

    PRODUCTION [root@prox18-dc01 ~]# zpool status -v
    pool: rpool
    state: DEGRADED
    status: One or more devices could not be used because the label is missing or invalid.
    Sufficient replicas exist for the pool to continue functioning in a degraded state.
    action: Replace the device using 'zpool replace'.
    see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
    scan: scrub repaired 0B in 00:01:30 with 0 errors on Sun May 11 00:25:31 2025
    config:
    NAME                         STATE     READ WRITE CKSUM
    rpool                        DEGRADED     0     0     0
    mirror-0                   DEGRADED     0     0     0
    35111111012345679-part3  ONLINE       0     0     0
    5587448289148697325      UNAVAIL      0     0     0
    was /dev/sdb3
    errors: No known data errors

    Я пытался zpool replace диск, пытался принудительно удалить неработающий диск, форматировал и затем zpool attach/add обновленный диск — безрезультатно.

    Я предполагаю, что проблема связана с ошибкой в текущей интеграции Proxmox/ZFS, поскольку она не влияет на узлы, настроенные в прошлом году с использованием более старой версии Proxmox. Я предполагаю, что используется более старая версия ZFS (мое понимание заключается в том, что при создании пула ZFS пул создается с этой версией ZFS — даже если вы обновите версию ZFS, существующий пул останется на той версии, с которой он был создан, если вы специально не обновите пул).

    Сталкивался ли кто-нибудь с этой проблемой раньше и есть ли какие-нибудь идеи, как ее решить без необходимости переустановки хоста? Если я не смогу найти решение, мне придется вернуться к аппаратному RAID, как будто это 2001 год.

    Буду рад услышать ваши мнения.
     
     
     
    LnxBil
    Guest
    #2
    0
    15.05.2025 09:10:00
    Обновлены ли "рабочие" узлы, чтобы у всех были одинаковые версии пакетов? И как насчет конфигурационных файлов в /etc, есть ли между ними различия?
     
     
     
    Sp00nman
    Guest
    #3
    0
    15.05.2025 09:46:00
    По сути, абсолютно все узлы идентичны: одинаковое железо, одинаковая настройка и конфиг, одинаковая multipath-конфигурация, все пропатчены и обновлены до последней версии из корпоративного репозитория. Единственное отличие – дата развертывания и какая версия ISO Proxmox использовалась.
     
     
     
    bbgeek17
    Guest
    #4
    0
    15.05.2025 14:29:00
    Я несколько раз перечитал твой пост, и "multipath" встречается в заголовке, в утверждении, что это ломает работу, и в последующем утверждении о том, что конфигурация multipath одинакова на всех нодах. Возможно, я упустил, но как ты пришёл к выводу, что Multipath виноват в твоих проблемах с ZFS? Blockbridge: ультра-низкая задержка, общая хранилище на базе всех NVMe для Proxmox - https://www.blockbridge.com/proxmox
     
     
     
    Sp00nman
    Guest
    #5
    0
    15.05.2025 14:49:00
    Привет! Давай попробую показать тебе:

    - Ниже рабочий узел без проблем:
    Вот узел с проблемой:
     
     
     
    bbgeek17
    Guest
    #6
    0
    15.05.2025 14:57:00
    Серийные номера дисков в "хорошем" узле отличаются. В "плохом" узле — оба диска с одинаковым серийным номером. Это наверняка может запутать Multipath. Можно сразу исключить sda и sdb из рассмотрения Multipath в конфигурационном файле. Затем стоит проверить наличие обновлений прошивки для ваших дисков, внимательно изучить их параметры с помощью Udev и других инструментов, и, возможно, вернуть их производителю. Это диски для потребителей или корпоративного уровня? PS Можно также запустить: sg_inq /dev/sdX Blockbridge: Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
     
     
     
    Sp00nman
    Guest
    #7
    0
    15.05.2025 15:57:00
    @bbgeek17 – Да, думаю, ты попал в точку. Ноды 1-7 используют enterprise-диски, а ноды 8-18 — дешёвые коммерческие SSD (их куча, чтобы запас был на случай сбоев). Вернусь к использованию контроллера RAID на этих хостах – так диск, представленный RAID-контроллером, будет иметь уникальные свойства. Можно было бы избежать этой проблемы, добавив в /etc/multipath.conf чёрный список локальных дисков – это предотвратит проблему, но не исправит то, что уже произошло. Так что в любом случае предстоит долгий день… переустановка хостов, жди меня. Спасибо за твои подсказки.
     
     
     
    Maximiliano
    Guest
    #8
    0
    15.05.2025 16:30:00
    Привет, думаю, естественный вопрос здесь в том, почему твой хост видит разные диски с одинаковым серийным номером. Я могу представить, что это происходит, если диски были представлены хосту по двум разным путям, например, используя iSCSI с несколькими порталами к одному и тому же LUN, но я бы лично не рекомендовал использовать ZFS с нелокальными дисками. ZFS лучше всего работает с меньшим количеством слоев между ZFS и дисками, в их документации они даже рекомендуют избегать использования аппаратных контроллеров [1], если ты не используешь режим IT/HBA. Как ты добавлял диски в zpool? Multipath создает отображаемые устройства, когда видит два диска с одинаковым WWN (в `/dev/mapper/`), и передача их вместо дисков напрямую (например, по их пути в `/dev/by-id/` или `/dev/`) была бы лучшим вариантом, но вышеупомянутое предостережение все равно применилось бы. [1] https://openzfs.github.io/openzfs-d...uning/Hardware.html#hardware-raid-controllers
     
     
     
    bbgeek17
    Guest
    #9
    0
    15.05.2025 16:38:00
    Привет, @Maximiliano! Скорее всего, это не iSCSI, а dual-expander SAS диск, учитывая, что это загрузочные диски. Хотя, как известно, на форуме уже были сообщения о том, что массово производимые бюджетные диски для потребителей используют одинаковые серийные номера, особенно если они из одной партии. Так что это вполне в духе тех самых забавных производственных причуд. Blockbridge: ультра-низкая задержка, общая память на базе NVMe для Proxmox - https://www.blockbridge.com/proxmox
     
     
     
    alexskysilk
    Guest
    #10
    0
    15.05.2025 18:01:00
    Боже мой, зачем вы позволяете multipathd захватывать ваши SATA-диски? Не делайте этого. Там вообще ноль преимуществ, зато добавится еще одна точка отказа.
     
     
     
    LnxBil
    Guest
    #11
    0
    16.05.2025 16:39:00
    Ну вот, в итоге оказалось не так. Мы можем помочь с добавлением в чёрный список, если ты выложишь вывод команды lsscsi --size в CODE-теги. Часто можно просто использовать протокол, название продукта или производителя, чтобы исключить локальные диски из multipath.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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