Интерфейсов менеджеров ресурсов
Стандартный набор интерфейсов менеджеров ресурсов является слишком
ограниченным, для того, чтобы на их базе можно было построить
детерминированное планирование. Их использование порождает проблемы, которые будут рассмотрены ниже.
Определение исполнительных ресурсов. В рамках интерфейсов СПО
планировщик может получить только интегральную информацию о состоянии кластеров: количество заданий в очередях, общее число процессоров, число загруженных процессоров и т.п. Однако информация о характеристиках обрабатывающих компьютеров – платформа, характеристики их ресурсов – остается недоступной. Информация общего плана, которой располагает планировщик, позволяет построить аллокацию, в которой в качестве исполнительных ресурсов определен кластер, однако, не гарантируется, что в нем есть необходимые заданию компьютеры с нужной архитектурой, достаточным объемом памяти, и оно действительно может быть в нем запущено.
Планирование, основанное на такой информационной базе, может
применяться только в грид с однородными по ресурсам кластерами. Если же
это не так, то, по-видимому, единственно возможный способ планирования спекулятивный запуск заданий во все кластеры грид.
Оценка времени начала аллокации. При построении аллокации планировщик может точно оценить время ее начала только при условии, что в кластере есть достаточное для планируемого задания количество свободных компьютеров – тогда оно может начать выполняться сразу. В противном случае в результате использования аллокации задание будет поставлено в очередь, но время его запуска на счет будет неопределенным. Говоря точнее, оно зависит от всех заданий, находящихся в кластере – в состоянии выполнения или ожидания в очереди, а также от того, какие задания будут поступать в кластер в дальнейшем.
Возможность получения аллоцированных ресурсов. Даже в ситуации, когда в кластер не поступают локальные задания, неопределенность времени начала аллокации приводит к задержкам в обработке глобальных заданий (и простою ресурсов), однако, при разделении ресурсов с владельцами последствия будут более тяжелыми. Если в кластер поступает неконтролируемый планировщиком локальный поток, задание грид может оставаться в очереди кластера неограниченно долго – оно может “зависнуть”.
Хотя грид с кластеризованными ресурсами получил наибольшее распространение, развивается и альтернативный, весьма перспективный подход, в котором грид строится из отдельных компьютеров.
При включении ресурсов в грид без объединения их в кластеры менеджер
ресурсов устанавливается на каждый компьютер и обслуживает только его,
осуществляя локальное управление заданиями путем непосредственного
взаимодействия с ОС. При таком “индивидуальном” подходе информационные интерфейсы менеджера позволяют предоставлять планировщику полный набор данных (объемы и характеристики ресурсов), необходимых для того, чтобы отбирать исполнительные компьютеры в точном соответствии с ресурсным запросом. Решается также проблема гарантированного запуска заданий. Если в варианте с кластеризованными ресурсами время начала аллокации определяется путем опроса состояния кластера через интерфейсы СПО, что приводит к дефектам планирования, то менеджер компьютера сам определяет возможность выполнения задания грид и выдает планировщику запрос на его получение.
Основная проблема грид с некластеризованными ресурсами –
непредсказуемость времени окончания задания. Такой грид наиболее выгоден, если ресурсы используются в режиме разделения с владельцами. Разделение ресурсов происходит здесь непосредственно во время выполнения: ресурсы, в том числе и процессорные, делятся между заданием грид и приложениями, выполняемыми владельцем компьютера. Владелец компьютера устанавливает политику разделения ресуров таким образом, чтобы обработка задания грид не оказывала существенного влияния на его деятельность, то есть, фактически, разрешает занимать компьютер в периоды простоя. Помимо того, компьютеры могут выключаться в произвольные моменты времени. Эти обстоятельства приводят к тому, что реальное время обработки задания на таких ресурсах будет существенно отличаться от процессорного времени, заказанного в ресурсном запросе. Проблема планирования в этом случае – сделать реальное время выполнения приемлемым для пользователя.
3.5 Проблематика использования современных планировщиков
Большинство разработок предназначены для обслуживания
кластеризованных ресурсов, в том числе система WMS наиболее крупного
на сегодняшний день грид проекта EGEE, имеющего мировой масштаб.
Брокер системы WMS реализует централизованную схему планирования,
работающую в двух режимах распределения заданий: жадного и ленивого
(ленивый режим был впервые реализован в проекте Alien). В жадном
режиме распределение заданий происходит без глобальной очереди:
поступившее в брокер задание сразу же отправляется в некоторый кластер.
Для выбора кластера используется информационная база, содержащая данные о текущем состоянии всех ресурсов грид. Задания, запускаемые
пользователями в ленивом режиме поступают в глобальную очередь.
Кластеры, имеющие свободные ресурсы, информируют брокер о
характеристиках свободных ресурсов, а тот, выбирая из очереди подходящее
задание, передает его в кластер.
В обоих режимах происходит сопоставление характеристик ресурсов и
заданий на предмет выяснения возможности выполнения. Информационная
база жадного режима, построенная на информационной службе MDS
системы Globus Toolkit, недостаточно полна: она не содержит данных,
описывающих процессорные узлы, так что этот режим может использоваться
только в грид с однородными ресурсами. Сопоставление характеристик
ресурсов и заданий в ленивом режиме производится на основе метода
matchmaking и не имеет такого недостатка.
Основное решение планирования – выбор исполнительных ресурсов – в
жадном режиме делается по интегральной характеристике состояния кластера: выбирается тот, у которого в локальной очереди меньше всего заданий. Как было показано, это потенциально ведет к зависанию заданий, тем более, что глобальная очередь в этом режиме не поддерживается и распределение происходит в момент поступления задания в брокер. Подход ленивого режима более аккуратный – задания грид находятся в очереди, а кластер запрашивает у брокера новое задание в моменты времени, определяемые политикой, заданной администратором. Однако, вопрос о том, какой должна быть эта политика остается открытым. Простейший подход – запрашивать задание при пустой локальной очереди – не разрешает проблем неоднородного кластера и неотчуждаемых ресурсов.
Система управления заданиями проекта NorduGrid представляет
интерес как пример децентрализованной архитектуры планирования. В целом, схема планирования в ARC аналогична жадному режиму брокера WMS, однако планировщик здесь входит в состав программного обеспечения
каждого рабочего места пользователя, а планирование и передача задания в
кластер, выполняется непосредственно с места выдачи запроса. Преимущества децентрализованной архитектуры известны – это отсутствие “критической точки”, живучесть и масштабируемость. Так же в данной архитектуре планирование производится отдельно для каждого задания и
принимаемые решения могут оказаться не согласованными друг с другом.
В некоторых системах находят применение два новых механизма – резервирование и миграция. Сценарий Moab Grid Scheduler выглядит
следующим образом:
Задания грид поступают в глобальную очередь, планировщик посылает запросы в кластеры и получает от них время возможных аллокаций, исходя из полученной информации, выбирается кластер, производится резервирование ресурсов, задание отправляется в кластер.
Moab, также как и CSF (Community Scheduler Framework), который
также поддерживает резервирование в службе планирования, не дает все-таки полного решения, предполагая, что кластерное обеспечение имеет средства для принятия решений о том, когда могут быть отведены ресурсы для резервирования. В стандартных СПО таких средств нет, и их создание
составляет отдельную задачу.
Системы GridWay и GridLab Resource Management System (GRMS) используют механизм перераспределения заданий – миграцию. В GridWay
после того как глобальное задание отправлено в кластер специальная служба
осуществляет его мониторинг. В случае, если задание не запущено на счет в
локальном менеджере ресурсов за некий интервал времени, происходит
перепланирование данного глобального задания, и оно перемещается на
другие ресурсы.
Миграция представляет собой мощный механизм, который способен
расширить возможности планирования. Однако, его применение сопряжено с
большими временными затратами на перемещение файлов заданий, так что
миграция, по-видимому, может рассматриваться как дополнение к
качественному способу планирования.