Ray History Server
Для пользователей Ray становится всё более обычным делом использовать кластеры Ray в качестве эфемерных вычислительных единиц, создаваемых для выполнения одной задачи и удаляемых сразу после её завершения. Этот шаблон повышает экономическую эффективность и позволяет лучше распределять ресурсы, особенно в условиях ограниченной емкости, где аппаратные ускорители являются дефицитными.
Компромиссом такого подхода является то, что, в отличие от долгоживущих кластеров, журналы сеансов, состояния в оперативной памяти и Ray Dashboard исчезают вместе с кластером. Пользователи могут экспортировать журналы и метрики во внешние системы наблюдаемости, но отладка неудачного задания означает необходимость сопоставления состояний задач и акторов, журналов отдельных узлов и трассировок ошибок. Ray Dashboard — это единственное место, которое объединяет всё это, и без него посмертная отладка практически невозможна.
С выходом последней версии Kuberay v1.7 History Server переведен в статус бета-версии и доступен для использования, что позволяет получать доступ к данным кластера Ray даже после его завершения.
Ray History Server устраняет пробел в наблюдаемости, восстанавливая необходимые конечные точки Ray после завершения работы кластера.
Страница выбора кластера
Прежде чем мы углубимся в работу History Server, давайте посмотрим, что он умеет. History Server предоставляет встроенную страницу выбора кластера, которая служит централизованной страницей для посмертной наблюдаемости, динамически обнаруживая и каталогизируя все исторические запуски, хранящиеся в объектном хранилище, а также текущие активные кластеры.
Пользователи могут искать и фильтровать прошлые или текущие запуски по имени кластера, пространству имен и ресурсу-владельцу. Каждая запись сеанса будет указывать, является ли сеанс активным или завершенным. И одним щелчком мыши по любому историческому или активному сеансу пользователи будут перенаправлены на соответствующий интерфейс Ray Dashboard.
Для завершенных сеансов History Server восстанавливает Dashboard из телеметрии, собранной в объектном хранилище. Для активных сеансов он проксирует запросы к работающему Ray Dashboard кластера, включая автоматическую вставку токена аутентификации для кластеров с включенной аутентификацией Ray, поэтому пользователи получают единую точку входа независимо от того, работает ли кластер в данный момент.
После выбора сеанса History Server предоставляет стандартный интерфейс Ray Dashboard, работающий на основе REST API, совместимого с Dashboard. Независимо от того, работает ли кластер или был завершен несколько часов или дней назад, пользователи перемещаются по тому же самому интерфейсу Dashboard, который они уже знают, и получают весь необходимый посмертный контекст, не поддерживая при этом простаивающие кластеры только ради сохранения доступа.
Обзор архитектуры
Итак, что именно входит в состав History Server? Существует два основных компонента, которые отражают фундаментальную разницу между двумя этапами, необходимыми для реанимации кластера Ray: запись данных и воспроизведение данных. Компонент, отвечающий за запись данных, — это коллектор (collector). А другой компонент, отвечающий за воспроизведение данных, — это сам History Server.
Глубокое погружение в коллектор
Начнем с коллектора. Коллектор — это sidecar-контейнер, который прикрепляется ко всем подам head и worker в Ray. И его задача, как упоминалось выше, — собирать данные из соответствующего контейнера Ray. Внутри коллектора есть два основных потока или подсистемы: одна отвечает за журналы, а другая — за события Ray.
Подсистема сбора событий предназначена для захвата высокоскоростной телеметрии от рабочих нагрузок Ray без чрезмерного потребления памяти кластера за счет реализации подхода с приоритетом записи на диск. При включенном API экспорта событий контейнеры Ray постоянно экспортируют структурированные события времени выполнения, начиная от жизненных циклов заданий драйвера и заканчивая событиями конкретных узлов. Вместо буферизации миллионов событий в оперативной памяти, подсистема сбора событий немедленно передает входящие полезные данные прямо на локальный диск. Эти файлы затем автоматически ротируются на основе настраиваемого интервала времени или пороговых значений размера файла. Файлы также могут быть сжаты непосредственно перед загрузкой в облачное объектное хранилище, чтобы минимизировать время загрузки и выгрузки. Для обеспечения стабильности контейнера коллектора, а также пода, коллектор также включает настраиваемый общий лимит диска с водяным знаком нагрузки на диск, который будет отклонять входящие запросы событий с ошибками 503 в случае временного сбоя или сетевой проблемы.
В то время как подсистема сбора событий отслеживает структурированные события, подсистема сбора журналов, как следует из названия, обрабатывает журналы Ray и метаданные кластера. Её основная задача — обеспечить загрузку журналов сеансов в объектное хранилище. Загрузка происходит в трех различных событиях жизненного цикла:
- При завершении пода: когда RayJob завершается или Kubernetes начинает удаление пода
При завершении пода: когда RayJob завершается или Kubernetes начинает удаление пода
- При запуске и восстановлении после сбоя: будут загружены остаточные журналы из предыдущего сеанса
При запуске и восстановлении после сбоя: будут загружены остаточные журналы из предыдущего сеанса
- При переходах сеанса: когда Ray ротирует или запускает новый сеанс во время работы
При переходах сеанса: когда Ray ротирует или запускает новый сеанс во время работы
Помимо загрузки журналов в объектное хранилище, сборщик журналов также выступает в качестве сборщика метаданных кластера. Только на head-поде он захватывает метаданные кластера, такие как версия Ray и часовой пояс, один раз при запуске, а также периодически делает снимки конечных точек Dashboard, которые не восстанавливаются из событий (например, наборы данных Ray Data и группы размещения), чтобы их последнее известное состояние оставалось доступным после завершения работы.
Глубокое погружение в History Server
History Server — это путь чтения системы: он воспроизводит данные, записанные коллектором. Он действует как механизм реконструкции по требованию без сохранения состояния для посмертной отладки. Он превращает необработанные сжатые файлы в объектном хранилище обратно в привычный интерфейс Ray Dashboard.
Обработка сотен файлов событий и журналов при каждом запросе создавала бы нагрузку на ресурсы, однако поддержание постоянного предварительно обработанного архива часто обходится дорого и большую часть времени простаивает. Чтобы оптимизировать производительность и обеспечить стабильность, History Server использует стратегию ленивой загрузки (lazy-loading), дополненную кэшем LRU.
- Ленивая загрузка: минимизирует запросы к объектному хранилищу и накладные расходы на инфраструктуру за счет откладывания извлечения и распаковки файлов событий до тех пор, пока пользователь не выберет конкретный сеанс. Это позволяет избежать ненужных операций чтения и устраняет зависимость от управляемой базы данных. Параллельные запросы к одному и тому же «холодному» сеансу объединяются, чтобы предотвратить лавинообразное чтение из объектного хранилища, а настраиваемый тайм-аут защищает от бесконечных зависаний.
Ленивая загрузка: минимизирует запросы к объектному хранилищу и накладные расходы на инфраструктуру за счет откладывания извлечения и распаковки файлов событий до тех пор, пока пользователь не выберет конкретный сеанс. Это позволяет избежать ненужных операций чтения и устраняет зависимость от управляемой базы данных. Параллельные запросы к одному и тому же «холодному» сеансу объединяются, чтобы предотвратить лавинообразное чтение из объектного хранилища, а настраиваемый тайм-аут защищает от бесконечных зависаний.
- LRU Cache: ограничивает использование памяти как лимитом количества записей, так и бюджетом в байтах. Поскольку размер сессий Ray значительно варьируется — от 2 МБ до более чем 500 МБ, — такие бюджеты, основанные на размере, необходимы для того, чтобы сервер истории постоянно оставался в рамках заданных лимитов памяти пода.
LRU Cache: ограничивает использование памяти как лимитом количества записей, так и бюджетом в байтах. Поскольку размер сессий Ray значительно варьируется — от 2 МБ до более чем 500 МБ, — такие бюджеты, основанные на размере, необходимы для того, чтобы сервер истории постоянно оставался в рамках заданных лимитов памяти пода.
Благодаря такой архитектуре один развернутый экземпляр сервера истории может обслуживать панели мониторинга для постмортем-анализа множества кластеров.
Хранилище объектов
Сервер истории по своей архитектуре не зависит от конкретного хранилища и построен на едином интерфейсе хранения. Это позволяет организациям подключать существующие объектные хранилища без привязки к поставщику. «Из коробки» поддерживаются следующие решения:
- Google Cloud Storage: нативная интеграция с GCS, поддерживающая GKE workload identity для беспарольной аутентификации.
Google Cloud Storage: нативная интеграция с GCS, поддерживающая GKE workload identity для беспарольной аутентификации.
- AWS S3 и MinIO: Amazon S3 и любое S3-совместимое объектное хранилище с аутентификацией через IAM Roles for Service Accounts или статические учетные данные.
AWS S3 и MinIO: Amazon S3 и любое S3-совместимое объектное хранилище с аутентификацией через IAM Roles for Service Accounts или статические учетные данные.
- Alibaba Cloud OSS: Aliyun Object Storage Service с использованием RAM Roles для Service Accounts.
Alibaba Cloud OSS: Aliyun Object Storage Service с использованием RAM Roles для Service Accounts.
- Azure Blob Storage: интеграция через Azure Workload Identity или строку подключения.
Azure Blob Storage: интеграция через Azure Workload Identity или строку подключения.
Структура хранения детерминирована, поэтому любую сессию можно найти с помощью простого поиска по префиксу, даже в многопользовательских средах. Данные организованы по принадлежности к ресурсам. Включение в путь владельцев ресурсов более высокого уровня, таких как RayJob и RayService, позволяет выполнять более детальную фильтрацию и устанавливает четкое происхождение рабочих нагрузок. Объектное хранилище разделено на два поддерева.
- cluster-metadata: легкий индекс пустых файлов, пути к которым кодируют пространство имен, владельца, кластер и сессию.
cluster-metadata: легкий индекс пустых файлов, пути к которым кодируют пространство имен, владельца, кластер и сессию.
- cluster-history: телеметрия сессии — необработанные логи, файлы событий и снимки конечных точек.
cluster-history: телеметрия сессии — необработанные логи, файлы событий и снимки конечных точек.
Производительность и эталонные тесты масштабирования
Мы протестировали путь прохождения данных сервера истории для сессий объемом от 1 тыс. до 50 тыс. задач, чтобы убедиться в линейности масштабирования. Были применены две настройки: выделение серверу истории не менее 1,5 ядер CPU и включение gzip-сжатия в сборщике. Сжатие сокращает накладные расходы на хранение примерно на 91%, а дополнительная мощность CPU ускоряет «холодную» загрузку сессий примерно в 2,4 раза и увеличивает максимальный размер открываемой сессии в 2,5 раза.
Метрика
Базовый уровень (gzip выкл., 0,5 ядра CPU)
Оптимизировано (gzip вкл., 1,5 ядра CPU)
Результат
Хранение событий на задачу
~3,75 КБ (4,3 события по 895 Б)
~355 Б (сжатие 10,85:1)
на 91% меньше
Хранилище для сессии на 100 тыс. задач
~385 МБ
~35,5 МБ
экономия ~349,5 МБ на сессию
Время холодной загрузки на задачу
~0,2 мс (ограничение CPU)
~0,084 мс (без ограничений)
в ~2,4 раза быстрее
Макс. размер открываемой сессии
~20 тыс. задач (более крупные сессии превышают лимит UI в 5 с)
~50 тыс. задач (открывается за 4,21 с)
в 2,5 раза больше
Производительность выходит на плато при 1,2 ядрах. Выделение большего количества CPU не показало измеримого улучшения, поэтому 1,5–2 ядра являются безопасной рекомендацией по начальному размеру для сервера истории. Полные результаты тестов доступны в репозитории с бенчмарками сервера истории.
Планы на будущее
Хотя текущая версия сервера истории находится в стадии бета-тестирования и предоставляет надежный сервис для постмортем-отладки, существуют улучшения, призванные еще больше упростить эксплуатацию и расширить возможности наблюдаемости.
- Автоматическая инъекция sidecar-контейнера сборщика — чтобы упростить внедрение, будущие версии представят стабильную автоматическую инъекцию сборщика в операторе KubeRay. Пользователи смогут декларативно включать сбор телеметрии в спецификации RayCluster. Ранняя версия уже доступна через feature gate RayClusterHistoryServer по ссылке HistoryServerOptions.
Автоматическая инъекция sidecar-контейнера сборщика — чтобы упростить внедрение, будущие версии представят стабильную автоматическую инъекцию сборщика в операторе KubeRay. Пользователи смогут декларативно включать сбор телеметрии в спецификации RayCluster. Ранняя версия уже доступна через feature gate RayClusterHistoryServer по ссылке .
- Расширение метрик и их воспроизведение — постмортем-отладка часто требует изучения системных метрик вместе с задачами, и мы стремимся включить нативную поддержку временных шкал исторических метрик путем захвата использования GPU/CPU, нагрузки на память и пропускной способности акторов.
Расширение метрик и их воспроизведение — постмортем-отладка часто требует изучения системных метрик вместе с задачами, и мы стремимся включить нативную поддержку временных шкал исторических метрик путем захвата использования GPU/CPU, нагрузки на память и пропускной способности акторов.
Попробуйте сегодня
Готовы внедрить постмортем-наблюдаемость для ваших рабочих нагрузок Ray в Kubernetes? Ознакомьтесь с документацией по Ray History Server, чтобы настроить сборщик и сервер истории в вашем кластере Kubernetes!
У вас есть вопросы или нужна помощь? Не стесняйтесь открывать issue в репозитории на GitHub. Мы приветствуем ваши отзывы, запросы на новые функции и вклад в развитие проекта! Вы также можете присоединиться к Ray Slack и задать вопросы в канале #ray-history-server.
