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

[РЕШЕНО]Проблемы с SSD NVMe снова возникают после последнего обновления ядра PVE?, Proxmox Виртуальная Среда

YAGA

Guest

11.03.2025 21:17:00

Привет, команда!

В конце 2023 года несколько пользователей сообщили о необъяснимой потере доступа к NVMe SSD, особенно Samsung 990 Pro NVMe SSD, которые есть у меня. Один или несколько NVMe SSD внезапно отключались и переставали обнаруживаться Linux. Сервер приходилось выключать и снова включать, чтобы обнаружить NVMe SSD; простой перезагрузки было недостаточно. Решением было добавить `nvme_core.default_ps_max_latency_us=0` в GRUB следующим образом: GRUB_CMDLINE_LINUX_DEFAULT="quiet nvme_core.default_ps_max_latency_us=0". Затем обновите GRUB с помощью `update-grub` перед перезагрузкой. После этого регулярные обновления ядра Linux в 2024 году полностью решили проблему, без сообщений о дефектах в течение года. Однако в начале 2025 года проблема внезапно повторилась, вероятно, из-за последних обновлений PVE Community Edition. Это не аппаратная ошибка, поскольку проблема возникает случайным образом на разных серверах с различными NVMe SSD. Чем больше NVMe SSD используются (например, для резервного копирования), тем чаще возникает сбой. Я убедился, что параметр GRUB все еще действует: `cat /sys/module/nvme_core/parameters/default_ps_max_latency_us 0`.

Вот версия ядра, которую я использую: Linux mars 6.8.12-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-8 (2025-01-24T12:32Z) x86_64 GNU/Linux.

Все эти NVMe SSD настроены как OSD BlueStore (Ceph). Когда происходит сбой, Ceph сообщает, что "демоны недавно аварийно завершили работу". Я думаю, что это следствие, а не причина. Первый сбой произошел в конце февраля, через несколько дней после обновления ядра.

Я один сталкиваюсь с этой проблемой снова? Хотя я не совсем уверен, что это исключительно проблема ядра, какой был бы самый разумный способ отката ядра? Какая версия ядра была бы наиболее надежной? Буду рад любым предложениям.

С уважением,

YAGA Guest	#2 0 22.03.2025 21:54:00 Они вставляются в слоты M.2 на материнской плате. Попробую протестировать с адаптером PCIe <-> M.2 в слоте PCIe.

pmtuxar

Guest

12.03.2025 14:34:00

У меня одни проблемы с некоторыми NVMe u.2 дисками для ЦОД (выпадают обычно в течение 24 часов): Intel P4600 6.4TB Micron 9200 MAX 6.4TB. Оба они отлично работают под ESXi, но случайным образом выпадают в Proxmox. Версии ядра во время проблем были где-то в районе 6.8.12-0-6.8.12-3 (по-моему). Я перепробовал все, что смог найти. Два поста в этой полусвязанной ветке здесь, примерно в октябре 2024 года (возможно, в одной из этих веток, которые вы уже нашли): Ветка 'NVMe Issue: Unable to change power state from D3cold to D0, device inaccessible' 2 января 2024 г. Привет! У меня проблема, когда один из моих двух NVMe дисков "пропадает" через некоторое время после загрузки. У меня два Samsung 990 PRO 4TB в ZFS Mirror для хранения моих ВМ, один из которых, похоже, имеет эту проблему, а другой работает идеально. Судя по dmesg, это не проблема температуры, как в других ветках, которые я нашел в Google, так как оба диска большую часть времени находятся при температуре 34-38°C. dmesg предлагает попробовать "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" и сообщить об ошибке. В других ветках я видел, что люди устанавливают его в значения вроде 5500 вместо 0, насколько это сильно влияет, так как я не... Trace8773 Ответы: 77 Форум: Proxmox VE: Установка и настройка Это очень-очень раздражает, потому что у меня есть эти замечательные диски, просто лежащие в ящике и ждущие доказательств того, что я смогу использовать их снова. Теперь, что я в настоящее время использую с большим успехом, так это диски Samsung 990 Pro (1 x 3TB и 1x 6TB). Никаких проблем с ними нет. Время безотказной работы превышает 30 дней... Я редко запускаю их дольше по разным причинам, в основном из-за других изменений оборудования, так как я все еще собираю систему.

amfern

Guest

12.03.2025 17:47:00

Я использую Arch Linux, и после выхода из сна у меня пропадает диск. Раньше я решал эту проблему с помощью параметра `nvme_core.default_ps_max_latency_us=0`, но после обновления ядра это снова началось. Похоже, что `nvme_core.default_ps_max_latency_us` больше не работает.

YAGA

Guest

12.03.2025 21:20:00

Согласен, ошибка появилась где-то в версии ядра 6.8.12-x и до сих пор есть в версии 6.8.12-8. Интересно, лучше ли откатиться до ядра младше 6.8.12-x, например, до kernel-6.8.8-2, или обновиться до ядра 6.11.11-1, которое сейчас тестируется. Да, спасибо, я тоже внес вклад в этот пост. По отзывам пользователей, проблема чаще встречается с накопителями Samsung 990 Pro. Очень странная ошибка, если у вас наоборот.

YAGA

Guest

12.03.2025 21:37:00

Кажется, параметр nvme_core.default_ps_max_latency_us=0 действительно не учитывается в новой версии grub, но после загрузки значение 0 все же есть. cat /sys/module/nvme_core/parameters/default_ps_max_latency_us возвращает значение 0. Возможно, ядро больше не корректно управляет default_ps_max_latency_us. Хочу протестировать ядро 6.11.11-1, потому что видел, что в управлении NVME SSD, особенно в обработке прерываний, начиная с ядра 6.10, есть улучшения https://kernelnewbies.org/Linux_6.10.

marcio79 Guest	#7 0 12.03.2025 21:40:00 Никаких проблем с 970 evo plus Kernel 6.11.0-1-pve, 128 дней работы без сбоев

YAGA Guest	#8 0 15.03.2025 11:55:00 Как и договаривались, я обновил ядро на каждом узле до версии 6.11.11-1-pve. Пока всё работает без проблем. Буду держать вас в курсе через пару дней, если эта версия ядра перестанет вызывать проблемы с NVMe SSD.

marcio79 Guest	#9 0 15.03.2025 12:14:00 6.11 — золото, мой друг.

YAGA

Guest

#10

22.03.2025 21:22:00

@marcio79 У меня всё ещё проблема с NVME SSD, они пропадают через несколько дней работы. Это происходит при интенсивном использовании, например, при создании резервных копий. Я также обновил BIOS до последней версии, включая AGESA 1.2.0.C. Ошибки те же. Я в тупике, не знаю, что ещё можно попробовать. Буду рад любым советам.

gfngfn256 Guest	#11 0 22.03.2025 21:51:00 Не знаю, как у тебя эти NVMe подключены к системе, но я бы попробовал другой контроллер/слот/соединение/шину/решение с этими дисками. Если проблема останется, попробуй поменять сами диски.

YAGA

Guest

#12

26.03.2025 18:16:00

Привет, команда! Перед тем, как подключить SSD к M.2 адаптеру в слоте PCIe, я заметил, что отсоединение SSD происходит только при очень специфических условиях. Моя конфигурация основана на 4 узлах и 1 qdevice с последними обновлениями PVE community, включая Ceph Squid 19.2:

* 1 SSD на каждом узле для PVE
* 2 SSD на каждом узле для CephRBD
* 3 HDD на каждом узле для CephFS

Все ВМ используют High Availability (HA).

* 1 PBS-сервер или 1 NFS-сервер или CephFS для резервного копирования.

Диски ВМ находятся на CephRBD.

У меня никогда не было отсоединений SSD во время работы, когда ВМ работают. Я не заметил отсоединений SSD, когда ВМ были остановлены перед резервным копированием. Я заметил частые и случайные отсоединения SSD, когда ВМ работают во время резервного копирования (снимок). Могут ли случайные отсоединения SSD быть связаны с HA, Ceph или самим процессом резервного копирования, когда ВМ работают?

С уважением

ipreferpie

Guest

#13

02.04.2025 08:20:00

Я еще хочу добавить, что у меня проблемы с версиями 6.8.12-9 и даже 6.11.11-2. Когда я использовал 6.8.12-4, было более-менее нормально. Для справки, мои диски – Intel D4502 7.68TB U.2 NVMe. Остальные NVMe работают без проблем, однако. Может, стоит откатиться к более старым версиям, например, 6.8.8, и посмотреть, как оно будет.

slavon Guest	#14 0 02.04.2025 13:17:00 Может, это поможет? https://web.git.kernel.org/pub/scm/.../?id=96b652eb5d514b2b549d5225d17816f463d23e30

YAGA Guest	#15 0 02.04.2025 21:21:00 Привет! Не могли бы вы рассказать поподробнее о вашей конфигурации: #nodes, #ssd на узел, HA?, CEPH? и когда происходит сбой? С уважением,

YAGA Guest	#16 0 02.04.2025 21:22:00 Спасибо, @slavon! Проверю этот коммит. С уважением.

ipreferpie

Guest

#17

04.04.2025 05:45:00

Рад рассказать немного о настройке и спасибо, что предложил высказаться…

Ноды: 3

Детали дисков на ноде:
1&2) 1x Samsung PM1733a 15.36TB, 1x Optane 905P 380GB как БД;
3) 2x Intel D4502 7.68TB (двойной канал работает как одноканальный), 2x Optane P1600X 118GB как БД

Ceph: репликация 3 с 2 min

Команды загрузки ядра Proxmox: PCIE_ASPM=off, nvme idle = 0

Proxmox версии, которые использовались: 6.8.12-7, 6.8.12-9, 6.11.11-2

Сбой происходит: когда большая нагрузка (запущен Plex и tdarr LXC, использующие хранилище Ceph pool для обработки файлов NFS с unRAID) обычно через 12-24 часа. Только диски Intel отваливаются, а Samsung работают нормально. Охлаждение в порядке, все диски примерно 40-50C. Странно, что когда Plex и tdarr работали в Windows VM (с хранилищем в Ceph pool), все было стабильно. А когда я использовал диски Intel на ESXi 6.7u3, они работали как часы.

YAGA

Guest

#18

06.04.2025 12:08:00

У нас много общего: оборудование хорошо работало в предыдущей конфигурации ПО. Ceph используется для SSD, это CephRBD том? Затронуто несколько SSD и несколько нод. Сбой происходит случайным образом, но чем больше нагрузка на систему, тем быстрее он возникает. Заметил, что проблема возникает чаще, когда ВМ работают с включенным HA во время резервного копирования (снимков). Каждый раз вижу сообщение об ошибке "1 демон недавно аварийно завершился" и 1 или несколько OSD пропадают с 1 или нескольких нод. Необходимо выключать затронутые ноды, а затем перезапускать их, чтобы вернуть OSD в онлайн. Сегодня я установил последние обновления из community repo, включая Ceph 19.2.1. Теперь у меня появилось новое предупреждение: [WRN] BLUESTORE_SLOW_OP_ALERT: 4 OSD(s) испытывают медленные операции в BlueStore. Эта проблема, похоже, известна в Ceph 19.2.1 https://github.com/rook/rook/discussions/15403 Буду держать вас в курсе, С уважением.

ALFi

Guest

#19

10.04.2025 17:49:00

Привет! Я добавил 2x Micron 7400 (M.2) как специальное устройство ZFS в ядро 6.8.x, и у меня один из дисков случайным образом отключался/переходил в оффлайн через 1-2 дня. Думаю, это исправило проблему: /etc/kernel/cmdline pcie_aspm=off pcie_port_pm=off. Теперь 6 дней работы на ядре 6.14.0-1-pve и ничего не отвалилось, я бы сказал, что 6.14 работает отлично. (HP MicroServer Gen10, Opteron X3216).

С уважением,

Редактирую: чтобы быть точнее: ядра 6.8.x и 6.14.x стабильно работают с параметрами: pcie_aspm=off pcie_port_pm=off. Без обоих параметров NVMe диски отваливаются через 1-3 дня.

gfngfn256 Guest	#20 0 10.04.2025 21:50:00 Похоже, там нет встроенного контроллера/соединения M.2. Ты, наверное, используешь какую-то карту PCI-riser в качестве контроллера — или еще какие-то хитрости через что-то другое. (Пустая трата M.2 Gen 4 диска!). Но суть в чем — я не уверен, что ты имеешь право комментировать стабильность ядра с дисками, когда в твоем случае это, скорее всего, связано с тем, как ты их подключаешь, а не сами диски по отношению к ядру. Что у тебя там установлено на этом двухядерном калькуляторе?

Читают тему

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