Как одна «очередь» в ZFS тормозила мои NVMe

У меня на одном Proxmox-хосте было несколько ZFS-пулов: большой на медленных HDD и два на быстрых NVMe под ноды Kubernetes. Логично: быстрое к быстрому, медленное к медленному.

Во время ночного бэкапа большой ВМ с HDD k8s-ноды на NVMe начинали «залипать». Но метрики дисков были чистые: задержка NVMe 0.3 мс, загрузка 1–2%. Диск не виноват, а тормозит.

Причина оказалась неочевидной. Виртуальные диски в ZFS (zvol) обслуживает общий пул потоков ядра, один на все пулы сразу. Когда бэкап читает HDD, потоки заняты и ждут медленный диск. Запросы к NVMe встают в ту же очередь, хотя сам NVMe свободен. Это как одна касса на два магазина: медленный покупатель задерживает быстрого, а на самих полках пусто. Метрики «диска» этого не показывают: запрос ещё не дошёл до диска.

К чему пришёл:
— перевёл NVMe с ZFS на LVM-thin: запросы идут прямо в блочное устройство, без общей очереди ZFS;
— ZFS оставил на HDD, где его снимки и контрольные суммы нужнее;

Кому интересны подробности, гуглите ключики: zvol_request_sync и zvol_use_blk_mq

Выводы:
1. Быстрые и медленные накопители не стоит гонять через один общий слой, если у него общие очереди.
2. «Диск простаивает, а ВМ тормозит» - повод смотреть выше диска: очереди, потоки, PSI.
3. Метрики await и util нужны, но не всё показывают.
4. По дороге узнал, что PVE не даёт живую миграцию диска на обычный LVM при aio=io_uring: у него могут быть зависания. С LVM-thin такого ограничения нет.

#proxmox #zfs #lvm #nvme #devops