Слияние кода завершено, страница обновится автоматически
DI Orchestrator архитектура
DI-engine фреймворк состоит из трёх важных модулей: coordinator, collector и learner. Обычно в рамках одной задачи DI-engine есть только один coordinator, а количество learner и collector может меняться. Функции каждого модуля следующие:
Из-за того, что в части learner часто используется параллельное обучение, во избежание путаницы мы называем модули, взаимодействующие с coordinator, logic learner, который является основной единицей для взаимодействия с coordinator. А отдельный процесс learner в параллельном обучении называется ddp learner. Несколько процессов ddp learner предоставляют услуги параллельного обучения. Один logic learner может соответствовать одному ddp learner (одному GPU) или нескольким ddp learner (нескольким GPU). Кроме того, для предоставления услуг параллельного обучения также требуется дополнительный модуль aggregator. Агрегатор отвечает за объединение результатов обучения нескольких ddp learner и отправку их координатору. Координатор взаимодействует только с логическими обучающими модулями.
Для получения более подробной информации о DI-engine см. DI-engine developer tutorial.
Чтобы обеспечить поддержку работы DI-engine в Kubernetes (K8s), мы разработали DI Orchestrator. В этой статье будет объяснено, как различные модули DI-engine создаются, обнаруживают друг друга и начинают обучение в системе K8s с использованием DI Orchestrator. Архитектура DI Orchestrator показана на рисунке ниже:
В целом он делится на два больших модуля: di-server и di-operator. DDPL обозначает ddp learner, Lm обозначает Learner, Cn обозначает Collector, а Aggregator + DDPL образуют один логический обучающий модуль. Далее мы сначала представим процесс создания задачи после отправки DI-engine задачи в K8s, а затем представим di-server и di-operator.
Процесс создания задачи Здесь описывается процесс создания задачи, который представляет собой весь жизненный цикл одной задачи DI-engine от создания до выполнения в K8s.
Di Operator Di-оператор — это компонент, отвечающий за организацию DIJob в системе K8s и использующий шаблон оператора в K8s для управления состоянием DIJob через контрольный цикл в шаблоне контроллера. Он изменяет состояние DIJob, чтобы оно соответствовало предопределённому состоянию.
Согласно характеристикам каждого модуля в DI framework, мы определили два типа пользовательских ресурсов (Custom Resource), а именно DIJob и AggregatorConfig. Первый используется для определения условий, необходимых для запуска координатора, коллекционера и обучающегося в RL задачах, включая изображения, команды запуска, необходимые вычислительные и запоминающие ресурсы, переменные среды и т. д.; второй используется для определения условий, необходимых для запуска агрегатора в RL задачах. Определение DIJob:
type DIJobSpec struct {
// Group is a collection of DIJobs
Group string `json:"group,omitempty"`
//Priority labels the priority of DIJob
PriorityClassName PriorityClassName `json:"priorityClassName,omitempty"`
// CleanPodPolicy defines the policy to clean pods after DIJob completed
CleanPodPolicy CleanPodPolicy `json:"cleanPodPolicy,omitempty"`
// Volumes defines the shared volumes for DI-engine components
Volumes []corev1.Volume `json:"volumes,omitempty"`
Coordinator CoordinatorSpec `json:"coordinator,"`
Collector CollectorSpec `json:"collector,"`
Learner LearnerSpec `json:"learner,"`
}
Определение AggregatorConfig:
type AggregatorConfigSpec struct {
Aggregator AggregatorSpec `json:"aggregator,"`
}
Почему агрегатор определяется отдельно? Агрегатор является общим ресурсом для всех задач RL, использующих DI-framework, поэтому мы определяем его как глобальный общий ресурс AggregatorConfig, и после отправки задачи di-сервер создаёт агрегатор, читая уникальный AggregatorConfig в кластере. Кроме того, агрегатор предназначен только для наиболее распространённого метода параллельного обучения, и если используются другие методы параллельного обучения, необходимо определить новый Custom Resource. Текст запроса:
means all the pods are in running state JobRunning Phase = "Running"
// JobSucceeded means job completed without error
JobSucceeded Phase = "Succeeded"
// JobFailed means some pods failed, job is also considered failed
JobFailed Phase = "Failed"
// JobUnknown means the job is in unknown state
JobUnknown Phase = "Unknown"
)
Один нормально запущенный и завершенный DIJob проходит через три этапа: Created, Running и Succeeded:
Если coordinator находится в этапе Failed, то DIJob также переходит в этап Failed. Aggregator, collector и learner после сбоя немедленно перезапускаются, не влияя на этап DIJob.
Этап Unknown пока не определен.
С помощью kubebuilder v3 создается проект, а необходимые компоненты (reflector, informer, indexer и др.) для оператора предоставляются controller-runtime и упаковываются в manager. Функция Reconcile предоставляется для настройки логики согласования, как показано в следующем коде:
func (r *DIJobReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
// your reconcile logic here
return ctrl.Result{}, nil
}
После отправки пользователем DIJob, informer получает уведомление о событии отправки и запускает handler. Затем вызывается функция Reconcile. В функции Reconcile вызывается метод list pod, который обнаруживает, что coordinator не создан. Затем считывается определение шаблона для coordinator из DIJob и создается соответствующий coordinator pod (где выполняется программа coordinator) и service (для связи между pods), а также некоторые переменные среды записываются в pod, включая имя pod, пространство имен pod и URL доступа к coordinator.
Каждый модуль в DI-engine имеет определенный порт по умолчанию:
DefaultCollectorPort = 22270
DefaultLearnerPort = 22271
DefaultAggregatorPort = 22272
DefaultCoordinatorPort = 22273
После создания coordinator, di-operator отслеживает состояние pods и изменяет состояние DIJob. После завершения DIJob (Succeeded или Failed), di-operator по умолчанию удаляет все pods в состоянии Running и все services, оставляя coordinator pod нетронутым.
При отправке DIJob могут возникнуть проблемы с вводом данных в yaml-файле, которые могут повлиять на ожидаемое выполнение DIJob или потребовать установки значений по умолчанию для некоторых полей DIJob. Если значения по умолчанию можно установить до отправки DIJob в кластер K8s, это поможет пользователям заранее обнаружить проблемы.
В K8s можно настроить webhook для проверки правильности перед отправкой DIJob в K8s кластер. K8s webhook делится на MutatingWebhook и ValidatingWebhook, первый используется для изменения значений ресурсов K8s, а второй — для проверки их правильности.
di-operator реализует методы проверки webhook, создавая MutatingWebhook для установки значений по умолчанию в DIJob и ValidatingWebhook для проверки правильности DIJob. Например, для поля CleanPodPolicy мы устанавливаем его значение по умолчанию равным Running в MutatingWebhook, указывая, что все запущенные pods будут удалены после завершения DIJob. Мы также проверяем значение поля CleanPodPolicy в ValidatingWebhook. Если пользовательское значение не равно None, ALL или Running, мы отклоняем отправку этого DIJob. Преимущества DI Orchestrator
DI Orchestrator предоставляет распределённую схему работы с контейнерами на основе K8s для фреймворка DI-engine. Для пользовательских DIJob, di-operator отвечает за организацию различных модулей в DI-engine, чтобы обеспечить их нормальное функционирование и выполнение тренировочных задач.
Через вызов интерфейса di-server координатору предоставляются функции добавления, удаления и запроса всех его коллекторов, учащихся и агрегаторов, что повышает способность динамического распределения ресурсов во фреймворке DI-engine.
В целом, DI Orchestrator предлагает следующие преимущества:
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )