Вопрос или проблема
Хотя мы уже выяснили причину и обходное решение этой проблемы, я публикую это здесь, потому что это может быть актуально для других, у кого аналогичная настройка.
Проблема
После регулярной периодической процедуры обновления на вычислительном и входном узле GPU нашего кластера HPC возникла проблема, когда сервер неожиданно перезагружался в очень неожиданные моменты. Обновление включало в себя некоторые обновления прошивки SSD, за которыми (после успешной перезагрузки) следовало обновление ОС (RHEL 8.10 oopta). Это включало обновление ядра с 4.18.0-553.30 до 4.18.0-553.36. Это также автоматически обновило программное обеспечение драйвера nvidia до последней версии в потоке (с 565 до 570), включая управление фабрикой (dnf module install nvidia-driver:latest-dkms/fm). После обновления система была успешно протестирована и введена в эксплуатацию. Только когда несколько пользователей одновременно вошли в систему и использовали различные приложения, происходили неожиданные перезагрузки системы. В процессе не оставалось никаких следов в файлах журналов или dmesg. Не было возможности получить журнал сбоев.
Технические характеристики
(неактуальные детали опущены) HPE ProLiant XL675d apollo с восемью GPU устройствами A100-80GB на плате HGX, 2TB RAM, стандартным контроллером RAID и смесью ssd и hdd для ОС и данных соответственно. Из восьми A100, четыре настроены в мультирежим MIG. Программное обеспечение: ОС Red hat 8.10, настроенная с использованием slurm в качестве диспетчера заданий. Мы используем ограничения устройств cgroup, чтобы предотвратить доступ пользователей к GPU-устройствам за пределами slurm-сессий через cgconfig:
...
# предотвратить доступ к GPU устройствам
devices {
devices.deny="c 195:* rwm";
}
Что мы пробовали?
Мы попробовали много вариантов. Изначально мы подозревали проблему с обновлением прошивки. Откатились назад и обновили всю остальную прошивку, включая GPU. Загружались с оригинальным ядром. Ограничили доступ к GPU. Отключили X через SSH, отключили xRDP. Ничего не помогло. В какой-то момент мы заметили, что сбои часто происходят после запуска приложения, содержащего chrome-sandbox. (Такие как pyCharm, CLion, Visual Code, chromium-browser.) В конце концов мы смогли вызвать сбой и перезагрузку контролируемым образом. Оказалось, что сбой происходил только тогда, когда хотя бы один из A100 был настроен в режиме MIG. Простое начало работы одного из упомянутых приложений вызывало сбой. Даже когда использование GPU было отключено (chromium-browser --disable-gpu) и когда доступ к GPU был ограничен с использованием linux cgroups или slurm.
Решение/обходной путь
Возврат драйверов nvidia к предыдущей версии решил проблему на данный момент:
dnf remove nvidia-driver
dnf module reset nvidia-driver
dnf remove libnvidia-nscq-570-570.86.15-1.x86_64
dnf module install nvidia-driver:565-dkms/fm
Вопрос
Хотя эта конкретная проблема нова с драйверами nvidia v570, мы не уверены, что использование cgconfig является надежным способом ограничения доступа к ресурсам GPU. Будем рады любым мыслям по этому поводу.
Ответ или решение
В контексте обсуждения проблем, связанных с внезапными системными сбоями в высокопроизводительных вычислительных системах (HPC), важно понимать натуру проблемы и какие шаги уже были предприняты для её решения. Описанная вами ситуация довольно специфична и связана с обновлением драйверов NVIDIA и использованием режима Multi-Instance GPU (MIG) на графических процессорах A100. Давайте детально рассмотрим вопрос использования cgconfig для ограничения доступа к GPU.
Теория
Сами по себе возможности операционной системы Linux для управления доступом к аппаратным ресурсам весьма развиты. Контрольные группы Linux (cgroups) позволяют администраторам управлять, ограничивать и изолировать ресурсы, такие как CPU, память, устройства ввода-вывода и другие. В вашем случае, cgroups используется для ограничения доступа к GPU устройствам, что делается с помощью правила devices.deny="c 195:* rwm";.
Существует несколько теорий относительного того, почему использование MIG может вызывать сбои при сочетании с определенными приложениями, основанными на Chrome. Вероятно, проблема связана с вопросами совместимости последних драйверов NVIDIA и особенностями работы MIG. В режиме MIG ресурс GPU делится между несколькими задачами, что может привести к непредсказуемому поведению при взаимодействии с системами, которые требуют полноценного доступа к графическому процессору.
Пример
В обсуждаемом случае, после обновления драйвера NVIDIA до версии 570 были выявлены критические сбои системы. Как оказалось, эти сбои происходили именно в тех приложениях, где используется компонент sandboxes Chrome. Используемая конфигурация включала возможность масштабирования ресурсов GPU с помощью MIG, что само по себе вводит дополнительные сложности, связанные с распределением и управлением ресурсами между несколькими изолированными процессами.
Применение
Теперь, зная параметры и возможности cgroups и особенности MIG, давайте рассмотрим возможные пути решения и улучшения конфигурации для предотвращения подобных инцидентов в будущем.
-
Обновление драйверов и программного обеспечения:
- Как временное решение, вы вернулись на предыдущую версию драйвера. В долгосрочной перспективе важно следить за обновлениями от NVIDIA, поскольку в будущих версиях проблема может быть решена.
- Также рекомендуется тесное сотрудничество с NVIDIA для диагностики и устранения проблем.
-
Оптимизация настройки MIG:
- Оптимальная конфигурация режимов и разбиения GPU может существенно повлиять на стабильность системы при использовании современных многоядерных архитектур и технологий виртуализации.
-
Детальное логирование:
- Обеспечение и мониторинг расширенного логирования с помощью инструментов, таких как
straceиgdb, позволяет лучше понять причину сбоя. - Системы APM (Application Performance Management) могут помочь найти перекосы или аномалии в производительности.
- Обеспечение и мониторинг расширенного логирования с помощью инструментов, таких как
-
Исследование альтернативных методов ограничения:
- Исследование других механизмов контроля доступа, таких как SELinux, AppArmor, или Kubernetes Device Plugin, для более гибкого и надежного управления ресурсами.
-
Контроль версий и тестирование:
- Внедрение более строгой политики контроля версий и более тщательное тестирование обновлений на отдельной тестовой инфраструктуре перед применением в продуктивной среде.
В частности, если вопрос касается надежности cgroups для ограничения доступа к GPU, стоит отметить, что cgroups сами по себе являются надежным инструментом. Однако при работе с драйверами GPU, особенно в контексте новых архитектур как Ampere и MIG, возможны специфические проблемы с совместимостью. В длительной перспективе стоит ориентироваться на обновления и рекомендации от NVIDIA для обеспечения максимальной совместимости и стабильности.