Экономические аспекты вычислений как услуги

--> Дата: Июн 17, 2008 53

Настоящая статья представляет собой попытку рассмотреть на примерах бизнес-модели и моделирование систем для услуги вычислений по запросу. Основное внимание уделялось формированию цен на услуги, перераспределению ресурсов и расходам, связанным с мерами упреждающей защиты.

По ожиданиям многих ИТ-специалистов, вычисления по запросу, или «вычисления как услуга» (Utility Computing), станут одним из новых важных источников дохода на рынке ИТ-услуг. Многие провайдеры услуг уже вышли на этот рынок, другие все еще изучают его потенциал. Большая часть исследований сосредоточена на возможных бизнес-моделях и ценообразовании в рамках этих моделей, архитектуре инфраструктуры и безопасности таких услуг. Поскольку существует множество альтернативных способов организации и предоставления вычислений как услуги, мы предлагаем методологию моделирования, с помощью которой можно изучить эти способы и их взаимодействие. В качестве платформы для моделирования и проведения расчетов мы использовали Demos 2000 [2]. Мы рассматривали главным образом «чистку» системы в целях безопасности, перераспределение ресурсов и ценообразование для вычислений как услуги.

Вычисления по запросу

Вычисления по запросу — это скорее иной подход к вычислительным ресурсам, чем новая технология вычислений. Главная его идея состоит в том, чтобы предложить вычислительный ресурс как услугу, оплачиваемую в зависимости от ее потребления, как электричество или газ. Тогда компаниям больше не нужно будет инвестировать в инфраструктуру, обеспечивать ее функционирование, обслуживание и защиту, чтобы иметь в своем распоряжении вычислительные ресурсы. Существует ряд услуг, которые возможно предоставлять в соответствии с парадигмой вычислений по запросу. Услуги сопровождения данных предлагают хранение больших объемов данных и широкую полосу пропускания — идеальные условия, например, для целей резервного копирования. Более распространены, однако, вычислительные услуги. Они предлагают вычислительную мощность, обычно из расчета процессорных часов, что очень удобно для рендеринга фильмов и других приложений с интенсивными вычислениями. На более высоком уровне стоят услуги аренды приложений. В этом случае провайдер услуг предлагает некое фирменное ПО вместе с аппаратным обеспечением, на котором оно работает. Типичные примеры приложений, предлагаемых по этой модели, — это системы управления взаимоотношениями с клиентами (CRM), СУБД и программы онлайн-бухгалтерии.

Инфраструктура обычно размещается в центре обработки данных, где провайдеру услуг удобно обеспечить управление ею и сопровождение, а клиент получает доступ к ресурсам дистанционно. В вычислительных услугах (которые мы в основном рассматриваем в данной статье) клиенты могут иметь разный уровень дистанционного доступа. На одном краю спектра модель аренды вычислительных ресурсов (Farm Renting), когда клиенту выделяется сеть из нескольких машин — так называемая ферма (farm), над которой он имеет полный контроль. На другом краю — модель представления работ (Job Submission), когда клиент через Web-интерфейс представляет для выполнения свое приложение вместе с управляющим сценарием. Результаты вычисления клиент также получает через Web-интерфейс. Модель аренды фермы позволяет клиенту отлаживать свое приложение до и во время выполнения работы, тогда как по модели представления работ приложение не должно содержать никаких ошибок. С другой стороны, модель представления работ связана с меньшей открытостью и, следовательно, лучше защищена. Более того, она позволяет лучше задействовать инфраструктуру, поскольку не требует назначать фиксированные объемы ресурсов. Можно также использовать схему перераспределения ресурсов (Resource Flexing), дополнительно выделяя простаивающие ресурсы для выполнения работ в периоды низкой нагрузки. В целом это должно увеличить количество доступных ресурсов в тот момент, когда поступает следующий запрос на выполнение работ, тем самым обеспечивая максимальную производительность инфраструктуры.

Защита инфраструктуры вычислений по запросу

На рынке вычислений по запросу уже существует довольно заметная конкуренция, на нем работает ряд поставщиков, предлагающих набор различных услуг. Однако безопасности в этой сфере пока не уделяется особого внимания. Многие провайдеры заявляют, что их услуги защищены, но никто из них не указывает, какие конкретно меры защиты приняты. Можно сказать почти наверняка, что когда вычисления по запросу станут более распространенными, произойдет ряд инцидентов, связанных с безопасностью, в которых клиентам будет нанесен значительный финансовый ущерб, а репутация поставщиков услуг пострадает. Так что к тому времени, когда рынок вычислений по запросу станет еще более конкурентным, доверие может стать тем фактором, который будет влиять на выбор поставщика услуг.

Существует ряд мер безопасности, защищающих инфраструктуру вычислений по запросу. Они включают, в числе прочего, сканирование загружаемых файлов на предмет вредоносного программного кода, шифрование и аутентификацию при взаимодействии между машинами (к примеру, посредством IPSec, TLS или SSH), разделение ферм (с помощью маршрутизаторов/межсетевых экранов и/или виртуальных локальных сетей), средства IDS/ IPS/AIS и системную «чистку» (scrubbing). В нашем анализе мы рассматриваем главным образом системную чистку, выделив четыре ее уровня.

Повторное использование системы. Этот уровень обеспечивает наименьшую степень защиты. Клиенту предоставляется машина с уже использованной ОС; для него создается новая учетная запись пользователя, а учетные записи предыдущих пользователей блокируются. Из-за уязвимостей в ОС может оказаться, что предыдущие пользователи инфицировали систему вредоносным кодом или же текущий пользователь имеет доступ к данным предыдущих пользователей. В первом случае риск можно уменьшить путем сканирования загружаемых данных. Помимо нарушения конфиденциальности вредоносный код может также снизить производительность машин. Стоит отметить, что если предыдущие пользователи просто удалят свои данные (без перезаписи поверх них), то данные становятся доступны последующим пользователям, но если они их сохраняют, то другие пользователи не могут напрямую получить к ним доступ.

Обновление системы. Клиенту предлагается машина с заново установленной ОС. В принципе это должно устранить риск заражения системы вредоносным кодом и гарантировать, что она работает с максимальной производительностью. Однако клиент все еще имеет возможность восстановить данные предыдущих клиентов.

Очистка. Этот подход предполагает удаление данных таким образом, чтобы их нельзя было восстановить обычными средствами ОС (т. е. не путем физического доступа к носителю). Для этой цели обычно достаточно одной перезаписи во всем пространстве памяти системы. Это более интенсивный процесс по сравнению с обновлением ОС, когда перед установкой операционной системы стирается только файловая таблица (FAT).

Санация. Этот способ имеет целью защиту от восстановления данных даже в том случае, если у злоумышленника есть физический доступ к носителю. Обычно это достигается посредством множества перезаписей либо стиранием магнитной записи.

Очистка и санация затрагивают не только внешние устройства хранения. Оперативная память и другие буферы памяти (например, буфер памяти сетевого адаптера) также могут содержать конфиденциальную информацию. К примеру, Министерство обороны США составило «матрицу санации» (Sanitization Matrix) [1], в которой перечислены процедуры, пригодные для очистки и санации различных средств хранения.

Ценообразование для вычислений по запросу

Как и в случае любой другой услуги общего пользования, конкретная бизнес-модель и цены на услугу играют решающую роль в ее успехе. Бизнес-модель должна отвечать потребностям заказчиков, в частности, в плане доступности, масштабируемости и удобства использования. Лучше всего разработаны бизнес-модели подписки (Subscription) и учета объема использования (Metered Usage). Встречаются также гибриды этих двух подходов: модель подписки с учетом объема (Metered Subscription) обычно применяют Интернет-провайдеры и операторы мобильной связи. Более детальное обсуждение бизнес-моделей для вычислений по запросу можно найти в [3].

В работе [5] Лоу и Байд предлагают стратегию ценообразования на основе аукциона. Утверждается, что эта схема должна обеспечить баланс между спросом и предложением. Есть все же некие тонкие различия между традиционными продажами с аукциона (скажем, на овощном рынке) и рынком вычислений по запросу. На рынке вычислений потребление товара может быть сильно растянуто во времени; следовательно, текущий спрос окажет влияние и на будущее предложение, не только на текущее. Рынок аукционного типа можно сравнить с системой управления с обратной связью. Задержка в контуре обратной связи снижает устойчивость системы, приводя к колебательному поведению, в результате которого система отклоняется от точки равновесия. Еще одно различие состоит в том, что покупатели вычислительных услуг порой появляются редко, и в этом случае покупатель, скорее всего, не будет иметь конкурентов или же торги придется продлить, что негативно скажется на доступности услуги. Кроме того, аукционная схема не позволяет учесть риска ситуации, когда провайдер, приняв относительно небольшой заказ на вычисления, через некоторое время оказывается не в состоянии выполнить более крупный (и более прибыльный) заказ. В работе [4] Палеолого указывает на неприменимость традиционного метода ценообразования «себестоимость плюс…» к вычислениям как услуге. Вместо этого предлагается метод ценообразования «цена при риске», который принимает во внимание неопределенность при назначении цены.

Наш вклад состоит в том, чтобы продемонстрировать, как компьютерное моделирование на основе исполнимых моделей [2] может помочь на стадии принятия решения о цене. Мы создали модель услуги вычислений по запросу, которую можно использовать, к примеру, для расчета параметров вычислительной мощности и выигрыша за счет мультиплексирования, используемых в методе «цена при риске». Она годится для количественной оценки выигрыша от стратегии перераспределения ресурсов или стоимости введения одной из схем системной чистки, обсуждавшихся выше. В нашей модели мы задаем для каждого запроса на работу определенный уровень обслуживания. Это определяет количество ресурсов, которые следует назначить для выполнения данной работы. В целом, чем быстрее выполнена работа, тем лучше для клиента. Следовательно, клиентам нужны услуги, которые требуют больше ресурсов в относительно короткие периоды времени. Но такой профиль спроса снижает эффективную мощность инфраструктуры. Ввиду этого мы принимаем ряд свойств, которыми должна обладать обоснованная схема ценообразования:

она должна способствовать постоянной нагрузке, избегая нежелательных профилей нагрузки;
стоимость выполнения работы должна быть пропорциональна ее объему;
стоимость выполнения работы должна увеличиваться с ростом качества обслуживания (QoS).

Мы реализовали две сходные схемы ценообразования, которые следуют этим правилам.

Схема № 1. Цена работы назначается за процессорный час в зависимости от уровня обслуживания. Уровень обслуживания в свою очередь определяет, сколько машин (в среднем) будет выделено для данной работы. Возможный недостаток этой схемы в том, что клиент может разбить свою работу на несколько более мелких и подать на них заявки одновременно как на отдельные работы с более низким уровнем обслуживания. В итоге он фактически получает тот же уровень обслуживания по более низкой цене.

Возьмем в качестве примера данные из табл. 1. Клиент A размещает заказ на работу в 1000 процессорных часов при уровне обслуживания 2. Его работа занимает 20 ч, и плата за нее составляет 1200 фунтов стерлингов. Клиент B разбивает свою работу в 1000 процессорных часов на пять работ по 200 процессорных часов и размещает их одновременно при уровне обслуживания 1. Работа занимает те же 20 ч, но с него берется плата лишь в 1000 фунтов.

Схема № 2. Цена назначается за процессорный час в зависимости от уровня обслуживания. Уровень обслуживания определяет количество времени, необходимое для выполнения работы. Поэтому количество выделенных на эту работу машин также зависит от объема работы. Конечно, не каждый заказ выполняется с самым высоким уровнем обслуживания. Более крупные заказы получают более высокий уровень за свои деньги. Это может показаться несправедливым, однако это разумно, если учесть, что клиент должен всегда получать лучшее обслуживание, чем он получил бы, вложив средства в собственную инфраструктуру.

Модель

Данная модель была реализована с помощью языка моделирования Demos 2000 [2]. В нашу модель (рис. 1) входит четыре основных объекта: «Клиенты», «Фермы» («Вычислительные ресурсы»), «Процессы чистки» и «Распределитель» (Allocator).

Единственное назначение клиентов — генерировать заказы на работу. Каждый клиент делает запросы независимо, причем интервал времени между запросами задается экспоненциальным распределением. Запрос на выполнение работы описывается двумя параметрами: объем работы W в процессорных часах и уровень обслуживания QoS. Параметр QoS интерпретируется в соответствии с принятой схемой ценообразования, но в целом чем выше QoS, тем быстрее выполняется работа.

Вычислительные фермы формируются распределителем в ответ на принятые от клиентов заказы. Каждая ферма соответствует одной работе и после ее выполнения высвобождается. Процесс управления фермами реализован как цикл, непрерывно ждущий инструкций (в форме синхронизаций), главным образом от распределителя. Определено пять видов инструкций.

Аренда истекла — сигнализирует, что время, выделенное для данной работы, подошло к концу. В ответ на это ферма высвобождает свои машины и прекращает работу.

Работа завершена — сигнализирует о том, что работа выполнена; в этом случае ферма высвобождает свои машины, но продолжает существовать, пока не будет получено сообщение «Аренда истекла». Включен также параметр состояния, указывающий на актуальность сообщения. Сигнал считается актуальным, если параметр состояния соответствует текущему состоянию фермы.

Инструкция по ресурсам — дает ферме указание взять либо высвободить определенное количество машин. Инструкция по ресурсам изменяет текущее состояние фермы и назначает новое время для инструкции «Работа завершена».

Запрос на перераспределение — запрашивает у фермы машины, которые у нее в данный момент загружены работой, но которые она может вернуть распределителю для выполнения других заказов.

Запрос о работе — запрашивает ферму о том, сколько процессорных часов ей необходимо для завершения работы. Эта информация нужна распределителю, чтобы понять, в какую ферму лучше добавить простаивающие машины в ходе перераспределения.

Процессы чистки создаются распределителем, чтобы выполнить чистку группы машин, прежде чем включить их в ферму. Машины берутся из пула ресурсов и удерживаются процессом чистки в течение периода времени, заданного параметром модели scrubTime. Варьируя этот параметр, можно смоделировать любую из четырех описанных выше схем чистки. По завершении процесс чистки просматривает «Список чистки», чтобы определить, в какую ферму (или фермы) следует направить машины. Наконец, процесс чистки высвобождает машины, посылает соответствующие сигналы вида «Инструкция по ресурсам» в нужные хозяйства и завершается.

Распределитель служит ядром всей модели и управляет большинством остальных объектов. Его основные обязанности таковы: обработка запросов на работы, управление ресурсами и их перераспределение, а также ведение журналов записей (таких, как список ферм и список чистки). Принятая в данной модели стратегия перераспределения использует алгоритм переназначения машин только в одну ферму. Если группа машин простаивает, распределитель просматривает список ферм и обращается к каждой с запросом о работе. Все простаивающие машины передаются в ферму с максимальным ожидаемым временем жизни. Время жизни L фермы F, имеющей MF машин и рабочую нагрузку WF, задается выражением:

L = (WF — MF ? TS) / (MF + MI), где MI — число простаивающих машин, TS — время чистки. Это схема с нулевым риском, так как каждой ферме всегда назначено достаточно машин, чтобы выполнить работу за выделенное ей время.

Работа модели в целом представлена на рис. 1, где показан поток информации между объектами и жизненный цикл машин. Клиенты отправляют запросы на работу (W, QoS) в распределитель. Распределитель выясняет, сколько машин потребуется для выполнения заказа, и проверяет, сколько машин доступно. Для начала он проверяет, сколько машин простаивает. Если их недостаточно, он просматривает список чистки на предмет машин, предназначенных для перераспределения. Если количество таких машин вместе с простаивающими оказывается недостаточным, то распределитель просматривает список ферм, выясняя, какие фермы имеют машины, доступные для перераспределения, и посылает им запрос на перераспределение. Фермы в ответ сообщают, сколько машин они могут высвободить (при этом завершив свою работу вовремя). Если общее количество машин достаточно, чтобы выполнить заказ, он передается ферме; в противном случае запрос на работу отклоняется. Процесс чистки создан для очистки простаивающих машин и машин, полученных от других ферм, а машины, прошедшие другой процесс чистки, перенаправляются в новую ферму путем корректировки списка чистки. Распределитель работает в бесконечном цикле, ожидая заказов на работу и других сообщений (например, уведомления о выполнении работ). При каждом запросе к нему он проверяет, есть ли простаивающие машины, и выполняет процедуру перераспределения.

Результаты

Данная модель имеет несколько потенциальных применений. Вот некоторые из задач, решаемых с ее помощью.

Определить вероятность того, что число машин будет достаточным, чтобы обслужить все запросы (для конкретного их распределения).
Рассчитать выигрыш в вычислительной мощности, которого можно достичь за счет определенной стратегии перераспределения.
Определить, какие расценки следует установить для конкретных уровней обслуживания.
Количественно оценить результат внедрения схемы чистки в архитектуру с перераспределением.
Оценить параметры, необходимые для расчета по методу «Цена при риске».
Получить данные для подготовки Соглашения об уровне обслуживания (SLA).

Разработанная нами тестовая модель прогонялась несколько раз, с различным числом машин. Использовалась схема ценообразования, описанная выше как схема №2 (цена для каждого уровня обслуживания указана в табл. 2). Вероятность, соответствующая каждому уровню обслуживания, есть вероятность того, что запрос на работу требует данного уровня обслуживания. На рис. 2 показано, каков был доход при каждом прогоне по мере увеличения количества машин. Эксперимент был повторен при значении времени чистки 1 ч вместо 5 ч и еще раз — без перераспределения. На рис. 3 представлены полученные в ходе тех же трех экспериментов оценки доли отклоненных запросов.

На рис. 2 красная и синяя кривые достигают наибольшей возможной величины дохода, тогда как зеленый график приближается к этому максимуму медленнее. Видно также, что доход несколько увеличивается при сокращении времени чистки. Вместо того чтобы сопоставлять доход, достигнутый для каждой конфигурации, мы можем провести сравнение в терминах инвестиций. В частности, мы можем сравнить, какая инфраструктура понадобится, чтобы выполнить один и тот же объем работ и, следовательно, получить одинаковый доход. Например, из рис. 3 видно, что для конфигурации из 5000 машин с перераспределением доля отклоненных работ составляет 7,9%. С другой стороны, в конфигурации без перераспределения требуется 6000 машин, чтобы достичь почти такого же уровня отклоненных работ (6,7%). Следовательно, такой сценарий потребует увеличения инвестиций на 20%, чтобы достичь того же дохода, что и в архитектуре с перераспределением.

Как уже говорилось выше, высокие значения QoS снижают эффективную вычислительную мощность инфраструктуры. Это, конечно, должно быть отражено в ценах на услуги. С помощью нашей модели можно количественно оценить эффективную вычислительную мощность, достигаемую при каждом QoS, а следовательно, определить справедливую цену для каждого уровня обслуживания. Модель была скорректирована таким образом, чтобы каждый QoS добавлял по 10 пенсов к цене процессорного часа. Затем она прогонялась восемь раз, причем в каждом прогоне все работы выполнялись при одном конкретном уровне обслуживания. Рис. 4 показывает, какой доход достигается для каждого уровня обслуживания. В качестве отправной точки для справедливой схемы ценообразования мы можем скорректировать стоимость каждого уровня обслуживания так, чтобы по всем столбцам предельный уровень дохода был одинаков. Например, согласно этим результатам, уровень обслуживания 8 должен стоить в три раза дороже, чем уровень обслуживания 7.

Рис. 4 демонстрирует довольно неожиданный эффект, заключающийся в том, что при переходе с уровня обслуживания 4 на более низкие (до уровня 1) доход снижается. В нашей модели клиент платит за услуги по завершении работы. Период прогона при моделировании составлял 2 года, а время выполнения работ варьируется от 1 дня до 6 месяцев в зависимости от уровня обслуживания. Таким образом, при более низких уровнях обслуживания к концу прогона накапливается больший объем работы, который на данный момент еще не оплачен. Эта ситуация может создать серьезную проблему с потоком наличности. К этому можно еще добавить инфляцию и затраты на сопровождение, которые также успевают вырасти при более длинном периоде вычислений. Таким образом, если клиенты будут платить по завершении работы, услуги с уровнем обслуживания с 1 по 4 будут неконкурентоспособны. Кроме того, можно обойти эту проблему, перейдя на бизнес-модель, в которой клиент платит либо авансом, либо частями по мере выполнения работы.

Другие исследования

Хороший обзор различных подходов к ценообразованию и бизнес-моделей для вычислений по запросу можно найти в [7]. В работе [8] описан прототип инфраструктуры вычислений «по требованию» Oceano, разработанный в IBM. Модель Oceano, включающая такие функции, как чистка и перераспределение, вполне согласуется с нашей моделью вычислений как услуги, хотя она ориентирована на Web-сервисы, а не на вычислительные ресурсы. Авторы [6] предлагают схему планирования на основе затрат, чтобы улучшить внутренний поток работ. Потенциально можно попытаться расширить эту схему, дополнив ее стратегией перераспределения.

Выводы и направления дальнейшей работы

Мы показали, что моделирование дискретных событий потенциально полезно при экономическом анализе в сфере ИТ и информационной безопасности. В данной статье мы изучили пример вычислений как услуги и показали, как наша простая модель может помочь в принятии бизнес-решений и в исследовании более широкого пространства возможностей.

При анализе мы поставили себе цель сделать модель возможно более простой. В ней не учитываются два фактора — фрагментирование ферм и атомная природа транзакций (неделимость операций) в распределенных заданиях. Алгоритм перераспределения передает машины из одной фермы в в другую, никак не учитывая расположение машин, что приводит к фрагментированию ферм. Главным образом это вызвано тем, что в DEMOS 2000 трудно ассоциировать элементы ресурсов с определенным их местоположением. Таким образом, в нашей модели не отражен дополнительный сетевой трафик, который может быть следствием конкретного алгоритма перераспределения. Во-вторых, распределенные задания обычно составлены из более мелких неделимых транзакций. Однако в модели допускается, что выполнение работы можно разбивать на сколь угодно малые операции. По-видимому, это будет нетрудно учесть, внеся в модель некоторые изменения. Другое ограничение состоит в том, что стратегия перераспределения реализована в допущении, будто задания можно распределять произвольно. К сожалению, это применимо только к ограниченному множеству проблем, таких, как исчерпывающий поиск криптографического ключа. Следовательно, упомянутый в разделе «Результаты» 20%-ный прирост в использовании инфраструктуры есть по сути верхний предел выигрыша от перераспределения, которого можно достичь за счет реализованного алгоритма перераспределения. Таким образом, если стоимость внедрения такой схемы перераспределения больше, чем стоимость расширения вычислительной инфраструктуры на 20%, то данная схема, очевидно, нежизнеспособна.

Направления дальнейшей работы могут быть связаны с дополнением модели, с тем чтобы она отражала эти факторы. Стратегию перераспределения можно расширить до схемы перераспределения с участием нескольких ферм, где простаивающие машины распределяются между множеством ферм, а не передаются одной из них. Можно также исследовать рискованное перераспределение, допускающее, что некоторые работы не будут выполнены вовремя. Кроме того, модель можно дополнить, включив в нее затраты на сопровождение и модернизацию ресурсов, чтобы детально изучить вопросы бесперебойного ведения бизнеса. Можно также использовать более общую модель для описания задач, например, представленную в [6]. Наконец, следует отметить, что модель легко адаптировать к описанию других видов услуг вычислений по запросу, таких, как Web-сервисы.

Мы благодарны Крису Дэлтону, Брайану Монахану, Крису Тофтсу и Майку Йеруорту за их советы по некоторым аспектам данной статьи.

Jean Paul Degabriele, David Pym. Economic Aspects of a Utility Computing Service. Trusted Systems Laboratory, HP Laboratories, Bristol.

Источники дополнительной информации

DoD 5220.22-M National Industrial Security Program Operating Manual (NISPOM). См. также http://www.usaid.gov/policy/ads/500/d522022m.pdf.

A. Christodolou, R. Taylor, C. Tofts. Demos 2000. См. http://www.demos2k.org.

M. A. Rappa. The utility business model and the future of computing services // IBM Systems Journal, vol. 43, No. 1, 2004. См. также http://www.research.ibm.com/journal/sj/431/ rappa.html.

G. A. Paleologo. Price-at-Risk: A methodology for pricing utility computing services // IBM Systems Journal, vol. 43, No. 1, 2004. См. также http://www.research.ibm.com/journal/sj/ 431/paleologo.html.

C. Low, A. Byde. Market-Based Approaches to Utility Computing // Technical Report HPL-2006-23, HP Laboratories, Bristol. См. также http://www.hpl.hp.com/techreports/2006/ HPL-2006-23.pdf.

Jia Yu, Rajkumar Buyya, Chen Khong Tham. Cost-based Scheduling of Scientific Workflow Applications on Utility Grids // Proc. of the 1st International Conference on e-Science and Grid Computing (e-Science 2005), Dec. 2005, pp. 140–147.

R. Buyya, D. Abramson, J. Giddy, H. Stockinger. Economic models for resource management and scheduling in Grid computing // Concurrency and Computation: Practice and Experience 2002; 14(13–15): 1507–1542.

K. Appleby, S. Fakhouri, L. Fong, G. Goldszmidt, M. Kalantar, S. Krishnakumar, D. Pazel, J. Pershing, B. Rochwerger. Oceano — SLA Based Management of A Computing Utility // 7th IFIP/IEEE Intl. Symp. on Integrated Network Management, May 2001, pp. 855—868.