LinkRay History Server
Среди пользователей Ray становится все более распространенным использование кластеров Ray в качестве эфемерных вычислительных единиц, создаваемых для одной задачи и удаляемых после ее завершения. Этот паттерн повышает экономическую эффективность и совместное использование ресурсов, особенно в условиях дефицита аппаратных ускорителей.
Обратной стороной такого подхода является то, что в отличие от долгоживущих кластеров, сеансовые логи, состояния в памяти и дашборд Ray исчезают вместе с кластером. Пользователи могут экспортировать логи и метрики во внешние системы наблюдаемости, но отладка сбойного задания требует сопоставления состояний задач и акторов, логов для каждого узла и трассировок ошибок. Дашборд Ray — это то единственное место, которое связывает их воедино, и без него посмертная отладка практически невозможна.
В последнем релизе Kuberay v1.7 History server переведен в статус бета-версии и доступен для использования, обеспечивая доступ к данным кластера Ray даже после его завершения.
Ray History Server устраняет пробел в наблюдаемости, восстанавливая необходимые конечные точки, связанные с Ray, после завершения работы кластера.
LinkCluster Selection Page
Прежде чем углубляться в историю работы сервера, давайте посмотрим, на что он способен. History server предоставляет встроенную страницу выбора кластера, которая служит централизованной точкой для постмортем-наблюдаемости, динамически обнаруживая и каталогизируя все исторические запуски, хранящиеся в объектном хранилище, а также текущие работающие кластеры.
Пользователи могут искать и фильтровать прошлые или текущие запуски по имени кластера, пространству имен и ресурсу-владельцу. Каждая запись сеанса указывает, является ли сеанс активным или завершенным. Одним щелчком мыши по любому историческому или активному сеансу пользователи перенаправляются на соответствующий интерфейс дашборда Ray.
Для завершенных сеансов history server восстанавливает дашборд на основе телеметрии, собранной в объектном хранилище. Для активных сеансов он проксирует запросы к работающему дашборду Ray кластера, включая автоматическую инъекцию токена аутентификации для кластеров с включенной аутентификацией Ray, поэтому пользователи получают единую точку входа независимо от того, работает ли кластер в данный момент.
После выбора сеанса history server предоставляет стандартный интерфейс фронтенда дашборда Ray на базе REST API, совместимого с дашбордом. Независимо от того, работает ли кластер или был завершен несколько часов или дней назад, пользователи работают с тем же самым интерфейсом дашборда, который они уже знают, и получают весь необходимый посмертный контекст, не сохраняя простаивающие кластеры только ради поддержания доступа.
LinkArchitecture Overview
Так что же именно входит в состав History server? Существуют два основных компонента, которые отражают фундаментальное различие между двумя этапами, необходимыми для реанимации кластера Ray: запись данных и воспроизведение данных. Компонент, отвечающий за запись данных, — это коллектор. А другой компонент, отвечающий за воспроизведение данных, — это сам history server.
LinkCollector Deep Dive
Начнем с коллектора. Коллектор представляет собой сайдкар-контейнер, который подключается ко всем главным (head) и рабочим (worker) подам Ray. Его задача, как упоминалось выше, — сбор данных из соответствующего контейнера Ray. Внутри коллектора есть два основных потока или подсистемы: одна отвечает за логи, а другая — за события Ray.
Подсистема сбора событий нацелена на захват высокоскоростной телеметрии от рабочих нагрузок Ray без чрезмерного потребления памяти кластера за счет реализации подхода к сбору данных с приоритетом диска. При включенном API экспорта событий контейнеры Ray непрерывно экспортируют структурированные события времени выполнения — от жизненных циклов задания-драйвера до специфичных для узлов событий. Вместо буферизации миллионов событий в памяти подсистема сбора событий немедленно передает входящие полезные данные напрямую на локальный диск. Эти файлы затем автоматически ротируются на основе настраиваемого интервала времени или пороговых значений размера файлов. Файлы также могут быть сжаты непосредственно перед выгрузкой в облачное объектное хранилище для минимизации времени выгрузки и скачивания. Для обеспечения стабильности контейнера коллектора, а также пода, коллектор также включает настраиваемый общий лимит диска с ватермарком давления на диск, который будет отклонять входящие запросы событий с ошибками 503 в случае временного сбоя или сетевой проблемы.
В то время как подсистема сбора событий отслеживает структурированные события, подсистема сбора логов, как следует из ее названия, обрабатывает логи Ray и метаданные кластера. Ее главная задача — обеспечить выгрузку сеансовых логов в объектное хранилище. Выгрузка происходит при трех различных событиях жизненного цикла:
- При завершении пода: когда RayJob завершается или Kubernetes начинает удалять под
При завершении пода: когда RayJob завершается или Kubernetes начинает удалять под
- При занесите и восстановлении после сбоя: остаточные логи с предыдущего сеанса будут выгружены
При занесите и восстановлении после сбоя: остаточные логи с предыдущего сеанса будут выгружены
- При переходах сеансов: когда Ray выполняет ротацию или запускает новый сеанс во время работы
При переходах сеансов: когда Ray выполняет ротацию или запускает новый сеанс во время работы
Помимо выгрузки логов в объектное хранилище, сборщик логов также выступает в роли сборщика метаданных кластера. Только на головном поде он фиксирует метаданные кластера, такие как версия Ray и часовой пояс, один раз при занесите, а также периодически делает снимки конечных точек дашборда, которые не восстанавливаются по событиям (такие как датасеты Ray Data и группы размещения), чтобы их последнее известное состояние оставалось доступным после завершения.
LinkHistory Server Deep Dive
History server представляет собой путь чтения системы: он воспроизводит данные, записанные коллектором. Он действует как бесস্টেковый механизм восстановления по требованию для посмертной отладки. Он превращает сырые, сжатые файлы в объектном хранилище обратно в нативный интерфейс дашборда Ray.
Обработка сотен файлов событий и логов при каждом запросе создает нагрузку на ресурсы, но поддержка постоянного предварительно обработанного архива часто стоит дорого и в основном простаивает. Для оптимизации производительности при обеспечении стабильности history server использует стратегию ленивой загрузки, дополненную LRU-кэшем.
- Ленивая загрузка: минимизирует количество запросов к объектному хранилищу и инфраструктурным накладным расходам за счет отсрочки извлечения и декомпрессии файлов событий до тех пор, пока пользователь не выберет конкретный сеанс. Это позволяет избежать ненужных чтений и устраняет зависимость от управляемой базы данных. Параллельные запросы для одного и того же холодного сеанса объединяются, чтобы предотвратить лавинообразные чтения (thundering herd) против объектного хранилища, а настраиваемый таймаут защищает от бесконечных зависаний.
Ленивая загрузка: минимизирует количество запросов к объектному хранилищу и инфраструктурным накладным расходам за счет отсрочки извлечения и декомпрессии файлов событий до тех пор, пока пользователь не выберет конкретный сеанс. Это позволяет избежать ненужных чтений и устраняет зависимость от управляемой базы данных. Параллельные запросы для одного и того же холодного сеанса объединяются, чтобы предотвратить лавинообразные чтения (thundering herd) против объектного хранилища, а настраиваемый таймаут защищает от бесконечных зависаний.
- LRU-кеш: ограничивает использование памяти с помощью лимита количества записей и бюджета в байтах. Поскольку размеры сессий Ray существенно варьируются (от 2 МБ до более чем 500 МБ), такие бюджеты на основе размера крайне важны для того, чтобы сервер истории стабильно укладывался в заданные лимиты памяти пода.
LRU-кеш: ограничивает использование памяти с помощью лимита количества записей и бюджета в байтах. Поскольку размеры сессий Ray существенно варьируются (от 2 МБ до более чем 500 МБ), такие бюджеты на основе размера крайне важны для того, чтобы сервер истории стабильно укладывался в заданные лимиты памяти пода.
Благодаря такой архитектуре один экземпляр развертывания сервера истории может обслуживать панели мониторинга для последующего анализа (post-mortem) множества кластеров.
LinkХранилище объектов
Сервер истории по своей архитектуре не зависит от конкретного хранилища и построен на основе единого интерфейса хранилища. Это позволяет организациям подключать свое существующее объектное хранилище без привязки к конкретному поставщику. Из коробки поддерживается следующее:
- Google Cloud Storage: Встроенная интеграция с GCS, поддерживающая учетные записи служб GKE (workload identity) для аутентификации без использования ключей
Google Cloud Storage: Встроенная интеграция с GCS, поддерживающая учетные записи служб GKE (workload identity) для аутентификации без использования ключей
- AWS S3 & MinIO: Amazon S3 и любое совместимое с S3 объектное хранилище с аутентификацией через роли IAM для учетных записей служб (IRSA) или статические учетные данные
AWS S3 & MinIO: Amazon S3 и любое совместимое с S3 объектное хранилище с аутентификацией через роли IAM для учетных записей служб (IRSA) или статические учетные данные
- Alibaba Cloud OSS: Aliyun Object Storage Service с ролями RAM для учетных записей служб
Alibaba Cloud OSS: Aliyun Object Storage Service с ролями RAM для учетных записей служб
- Azure Blob Storage: интеграция через Azure Workload Identity или строку подключения
Azure Blob Storage: интеграция через Azure Workload Identity или строку подключения
Структура хранения является детерминированной, поэтому любую сессию можно найти с помощью простого поиска по префиксу даже в многоарендных (multi-tenant) средах. Данные организованы по принципу принадлежности ресурсов. Включение в путь владельцев ресурсов более высокого уровня, таких как RayJob и RayService, позволяет выполнять более детальную фильтрацию и устанавливает четкое происхождение рабочей нагрузки. Объектное хранилище разбито на два поддерева.
- cluster-metadata: Легковесный индекс пустых файлов, пути которых кодируют пространство имен, владельца, кластер и сессию
cluster-metadata: Легковесный индекс пустых файлов, пути которых кодируют пространство имен, владельца, кластер и сессию
- cluster-history: Телеметрия сессии — необработанные логи, файлы событий и снимки конечных точек
cluster-history: Телеметрия сессии — необработанные логи, файлы событий и снимки конечных точек
LinkТестирование производительности и определение размеров
Мы провели тесты производительности путей передачи данных сервера истории на сессиях размером от 1 тыс. до 50 тыс. задач, чтобы убедиться в линейности масштабирования. Было применено два изменения: выделение серверу истории не менее 1,5 ядер ЦП и включение gzip-сжатия в коллекторе. Сжатие сокращает накладные расходы на хранение примерно на 91%, в то время как дополнительный ЦП ускоряет холодную загрузку сессий примерно в 2,4 раза и увеличивает максимально доступный для открытия размер сессии в 2,5 раза.
Метрика
Базовый вариант (gzip выкл., 0,5 ядра ЦП)
С оптимизацией (gzip вкл., 1,5 ядра ЦП)
Эффект
Хранение событий на задачу
~3,75 КиБ (4,3 события по 895 Б)
~355 Б (сжатие 10,85:1)
на 91% меньше
Хранилище для сессии со 100 тыс. задач
~385 МиБ
~35,5 МиБ
сохранено ~349,5 МиБ на сессию
Время холодной загрузки на задачу
~0,2 мс (ограничено ЦП)
~0,084 мс (без ограничений)
в ~2,4 раза быстрее
Максимальный размер открываемой сессии
~20 тыс. задач (более крупные сессии превышают лимит интерфейса в ~5 с)
~50 тыс. задач (открывается за 4,21 с)
в 2,5 раза больше
Производительность выходит на плато при 1,2 ядра. Выделение большего количества ЦП не показало измеримого улучшения, поэтому 1,5–2 ядра являются безопасной рекомендацией по первоначальному размеру для сервера истории. Полные сведения о тестах доступны в репозитории бенчмарков сервера истории.
LinkБудущая дорожная карта и планы на будущее
Хотя текущая версия сервера истории находится в статусе бета-тестирования и предоставляет надежный сервис для отладки после сбоев, в разработке находятся улучшения, призванные еще больше упростить эксплуатацию и расширить возможности наблюдаемости.
- Автоматизированная инъекция сайдкара-коллектора — для упрощения внедрения в будущих версиях появится стабильная автоматизированная инъекция коллектора в операторе KubeRay. Пользователи смогут декларативно включать сбор телеметрии в спецификации RayCluster. Ранняя версия уже доступна за функциональным флагом RayClusterHistoryServer через HistoryServerOptions.
Автоматизированная инъекция сайдкара-коллектора — для упрощения внедрения в будущих версиях появится стабильная автоматизированная инъекция коллектора в операторе KubeRay. Пользователи смогут декларативно включать сбор телеметрии в спецификации RayCluster. Ранняя версия уже доступна за функциональным флагом RayClusterHistoryServer через HistoryServerOptions.
- Расширение метрик и воспроизведение метрик — отладка после сбоев часто требует анализа системных метрик вместе с задачами, и мы планируем добавить встроенную поддержку временных шкал исторических метрик путем сбора данных об утилизации GPU/CPU, нагрузке на память и пропускной способности акторов.
Расширение метрик и воспроизведение метрик — отладка после сбоев часто требует анализа системных метрик вместе с задачами, и мы планируем добавить встроенную поддержку временных шкал исторических метрик путем сбора данных об утилизации GPU/CPU, нагрузке на память и пропускной способности акторов.
LinkПопробуйте прямо сейчас
Готовы внедрить наблюдаемость для посмертной отладки рабочих нагрузок Ray в Kubernetes? Ознакомьтесь с документацией по Ray History Server, чтобы настроить коллектор и сервер истории в своем кластере Kubernetes!
Есть вопросы или нужна помощь? Не стесняйтесь создавать тикет в репозитории на GitHub. Мы приветствуем ваши отзывы, запросы функций и вклад в развитие проекта! Вы также можете присоединиться к Ray Slack и задать вопросы в канале #ray-history-server.
