Концепция коммунальных вычислений (utility computing) предполагает объединение серверов, сетей и систем хранения в единый пул ресурсов с централизованным управлением. Мониторы виртуальных машин центра данных SoftUDC позволяют приложениям и административным доменам совместно использовать физические ресурсы при сохранении полной изоляции на функциональном уровне.

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

Среда коммунальных вычислений должна соответствовать нескольким ключевым требованиям.

  • Централизованное управление. Системным администраторам необходим единый пункт управления информационной инфраструктурой. Централизация управления упрощает администрирование и позволяет автоматизировать многие задачи.
  • Независимость от конфигурации оборудования. Системные администраторы должны иметь возможность развертывания приложений и изменения конфигурации системы без перемонтажа оборудования. Более того, они не должны перепроектировать или перестраивать инфраструктуру в процессе эксплуатации.
  • Совместное использование ресурсов. Для повышения коэффициента загрузки оборудования ресурсы должны предоставляться приложениям на условиях совместного использования. При этом суммарные требования к ресурсам могут превышать физические возможности оборудования.
  • Изоляция ресурсов. Пользователи должны иметь полный административный контроль и ощущение безраздельного владения ресурсами. Несмотря на лежащее в основе системы разделение ресурсов, сетевой трафик и обмен данными с дисками в одном административном домене должны быть невидимыми для других доменов.

Удовлетворить эти требования призван программно реализованный коммунальный центр данных SoftUDC (Software-based Utility Data Center), который виртуализирует ресурсы серверов, сетей и устройств хранения. SoftUDC опирается на мониторы виртуальных машин (Virtual Machine Monitor, VMM), выполняющиеся на каждом сервере. Каждый VMM поддерживает работу нескольких виртуальных машин, обеспечивая их виртуальными сетевыми ресурсами и ресурсами хранения данных. Мониторы VMM позволяют объединить несколько виртуальных машин, выполняемых на разных серверах, в изолированные виртуальные фермы.

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

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

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

В SoftUDC используются мониторы виртуальных машин из проекта Xen [1]; компоненты привратника включены в состав VMM, а также в специальную управляющую виртуальную машину, находящуюся с ним в тесном взаимодействии. На рис. 1 представлена общая схема программного комплекса SoftUDC на сервере с виртуальной машиной для управляющей операционной системы.

Виртуализация серверов

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

Интерфейс управления

Для выполнения задач, требующих привилегированных операций, управляющая ОС использует специальный API-интерфейс управления, доступный напрямую или через безопасное соединение. Кроме управления распределением ресурсов интерфейс обеспечивает доступ к службам, которые создают, «замораживают» или уничтожают виртуальные машины. К управляемым ресурсам относятся процессоры, память, пропускная способность сети и производительность операций ввода/вывода. Объем ресурсов, выделенных всем виртуальным машинам, может превышать сумму ресурсов системы, что позволяет эффективно эксплуатировать приложения, у которых потребности в ресурсах возникают в разное время.

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

Миграция виртуальных машин

SoftUDC позволяет перемещать виртуальную машину с одного физического сервера на другой, рассматривая всю совокупность физических серверов как единый унифицированный пул [2]. Перемещение виртуальных машин обеспечивает доступ к ресурсам другого физического сервера или повышение коэффициента их использования (путем переноса на один сервер нескольких виртуальных машин, имеющих сравнительно скромные потребности в ресурсах). Таким образом, при необходимости можно освободить конкретный физический сервер.

Шифрование данных

SoftUDC предполагает, что физический доступ к машине имеют лишь доверенные лица. Чтобы ослабить это ограничение, можно использовать технологию, развиваемую в рамках Trusted Computing Group (www.trustedcomputinggroup.org/home). На машине устанавливается доверительный аппаратный модуль TPM (Trusted Platform Module), который позволяет проверять целостность сервера без привлечения доверенных лиц. Пользователи могут убедиться в том, что на сервере в неизменном виде эксплуатируются конкретная система BIOS и платформа SoftUDC (в том числе VMM, базовая операционная система и привратник), а в результате — доверять платформе SoftUDC и ее средствам безопасности. Они способны защитить свои данные путем шифрования вне зависимости от действий и политик владельца физического сервера, и последнему не удастся расшифровать эти данные.

Виртуализация сети

Виртуализация сети создает у пользователей впечатление работы в собственной виртуальной локальной частной сети VNET, в пределах которой они могут использовать любой адрес MAC (Media Access Control) или IP-адрес. По уровню безопасности сети VNET должны быть сопоставимы с виртуальными сетями VLAN на базе аппаратных средств. Они не зависят от топологии базовой физической сети и способны поддерживать свою связность в процессе миграции виртуальных машин.

Виртуальный сетевой интерфейс

Виртуальные машины подключаются к сети через виртуальные сетевые интерфейсы (Virtual network InterFace, VIF), которые функционально схожи с устройствами Ethernet. Монитор VMM направляет исходящие сетевые пакеты на свой физический сетевой интерфейс, а входящие сетевые пакеты — на соответствующие интерфейсы VIF. Если бы функции VMM этим и ограничивались, виртуальным машинам пришлось бы использовать для пересылки пакетов физическую сеть. Их интерфейсам VIF понадобились бы допустимые адреса MAC и IP, а другие машины в физической сети могли бы наблюдать транзитные пакеты виртуальных машин.

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

Инкапсулируются кадры Ethernet, а не IP-трафик, поскольку это позволяет виртуальным машинам прозрачным образом использовать любой сетевой протокол. Кроме того, обработка кадров Ethernet осуществляется проще, чем разборка пакетов IP.

Модуль ядра должен направить инкапсулированный трафик VNET на подходящий IP-адрес. Этот временный (care-of) адрес основан на кадре Ethernet и MAC-адресе назначения в VNET. Если MAC-адрес является широковещательным или групповым, временный адрес будет локальным групповым адресом в сети VNET. Если же MAC-адрес является уникальным адресом, временный адрес будет реальным IP-адресом машины, на которой находится виртуальная информационная среда-получатель (Virtual Information Environment, VIE).

Для определения временных адресов VIE, которые изменяются в процессе миграции виртуальных машин, мы разработали протокол VARP (Virtual Address Resolution Protocol).

Изоляция сети

Для изоляции сетевого трафика SoftUDC использует виртуальные сети VNET. Монитор VMM инкапсулирует пакет и посылает его другому VMM или виртуальному маршрутизатору в той же сети VNET. VMM-получатель разворачивает пакет и доставляет его адресату. Если адресатом является виртуальная машина, она использует пакет по назначению. Если же адресат — это виртуальный маршрутизатор или двудомная виртуальная машина, то пакет может быть отправлен далее. На рис. 2 показано, как SoftUDC виртуализирует физическую сеть, чтобы обеспечить различные ее представления для машин, входящих в виртуальную ферму.

Объекты, совместно использующие физическую сеть, но принадлежащие разным виртуальным фермам, не должны иметь возможности обмениваться пакетами или читать данные в чужих пакетах. Протокол IPsec ESP (Encapsulating Security Payload) инкапсулирует пакеты VNET EtherIP, чтобы обеспечить идентификацию сообщений и сохранить конфиденциальность. Шифрование IPsec гарантирует, что прочесть данные сможет только адресат. Идентификация IPsec допускает отправку данных лишь с тех объектов, которые находятся в составе виртуальной фермы.

Сетевой экран

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

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

Территориально-распределенные виртуальные сети

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

Поэтому для поддержки территориально-распределенных виртуальных сетей SoftUDC использует специальных демонов vnetd. В каждом сегменте сети с интерфейсами VIF имеется свой демон vnetd, и все они связаны друг с другом. Каждый демон пересылает локальные групповые пакеты VNET своим «коллегам», а присланные ему пакеты рассылает по локальной сети. Эти демоны также пересылают запросы и ответы VARP.

Демоны vnetd прозрачны для мониторов VMM. Инкапсулированный трафик VNET обычно направляется непосредственно на хост-машину, а не через демонов vnetd, поскольку пересылка по VARP гарантирует, что мониторы VMM смогут определить адрес хост-машины даже в удаленной среде VIE. С помощью этих методов SoftUDC может обслуживать территориально-распределенные виртуальные сети, не требуя изменений в сетевой инфраструктуре или применения специального оборудования.

Виртуализация систем хранения

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

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

В SoftUDC виртуализацию систем хранения осуществляет менеджер виртуальных томов, который позволяет серверам совместно использовать запоминающие устройства центра данных. Менеджер виртуальных томов выполняется в составе привратника и предоставляет виртуальным машинам виртуальные устройства хранения (Virtual Storage Device, VSD) из общедоступного пула устройств (рис. 3). Он управляет отображением устройств VSD на физические запоминающие устройства этого пула. Отображение осуществляется на базе атрибутов, таких как требуемый уровень защиты (используется для выбора параметров RAID) и желаемая производительность (применяется для конфигурации параметров чередования). Они позволяют подобрать для данного виртуального устройства соответствующие физические устройства.

Традиционная виртуализация систем хранения данных для сервера позволяет объединить лишь ресурсы сети хранения, к которой он подключен. В свою очередь, SoftUDC может использовать любые запоминающие устройства в центре данных, в том числе напрямую подключенные к другим серверам. Менеджер виртуальных томов обеспечивает необходимую маршрутизацию и для осуществления операций ввода/вывода с равным успехом использует транспортные подсистемы сети хранения и локальной сети.

Миграция данных

Менеджер виртуальных томов способен прозрачным образом перемещать данные между физическими устройствами. Например, чтобы снять с эксплуатации устаревшее запоминающее устройство, сбалансировать нагрузку на диск или изменить атрибуты VSD, можно переместить данные на другое устройство. Менеджер виртуальных томов позволяет обращаться к данным VSD в процессе перемещения; он сдерживает запросы на ввод/вывод, чтобы снизить влияние миграции данных на производительность приложений [3, 4].

Изоляция ввода/вывода

Использование VSD создает иллюзию единоличного владения запоминающим устройством. Однако для реализации VSD менеджеру виртуальных томов нужны общедоступные физические устройства хранения. Хотя суперпозиция рабочих нагрузок в рамках общей инфраструктуры может повысить коэффициент использования ресурсов, на практике довольно трудно обеспечить изоляцию ввода-вывода. В SoftUDC предусмотрены следующие пути решения этой проблемы:

  • обеспечение достаточности общедоступных ресурсов [5];
  • сдерживание запросов ввода/вывода для изоляции перегрузок [3].

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

Изоляция хранения

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

Чтобы выполнить аналогичное требование к изоляции сети, SoftUDC использует протокол IPsec. В текущей версии предполагается, что идентифицированный сервер, оснащенный менеджером виртуальных томов, гарантирует целостность и конфиденциальность сохраняемых на нем данных. Если дело обстоит не так, клиент должен зашифровать данные до передачи менеджеру виртуальных томов.

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

Автоматизация управления

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

Оперативное обслуживание

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

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

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

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

Поскольку механизм обслуживания ОС в SoftUDC совместим с распространенными операционными системами, его ядро не нуждается в специальном обслуживании. Кроме того, этот способ обслуживания не требует наличия свободного узла. В результате операции обслуживания могут выполняться параллельно на нескольких узлах кластера или фермы, а не в виде последовательных обновлений, как подразумевается в большинстве сценариев «ползучего обновления» [9].

Обслуживание оборудования, VMM и встроенного программного обеспечения. Наряду с обслуживанием ОС SoftUDC обеспечивает оперативное автоматизированное обслуживание оборудования, мониторов VMM и встроенного программного обеспечения. Однако такое обслуживание должно выполняться для узла в целом, поэтому требует использования резервных узлов и не может параллельно выполняться для всего кластера или фермы.

Обслуживание начинается с выбора узла или группы узлов, которые должны быть модернизированы или отремонтированы. При обслуживании оборудования выбор делает администратор, а при обновлении VMM или встроенного программного обеспечения узел выбирает SoftUDC.

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

Автоматизация. Многие из программных элементов системы имеют интерфейсы управления для автоматизации обслуживания. Например, SoftUDC использует соответствующие подпрограммы управления VMM, чтобы дистанционно запустить виртуальную машину или переместить ее на другой узел. API-интерфейс управления на уровне миграции процессов позволяет выполнить обслуживание ОС. Имеются аналогичные интерфейсы на уровнях виртуализации сети и систем хранения данных.

Автоматизацию и управление оперативным обслуживанием осуществляет система SmartFrog.

Управление ресурсами

Центр данных SoftUDC основан на результатах предыдущих проектов автоматизированного управления ресурсами, реализованных в HP Labs. Например, проект Hippodrome [5] позволил продемонстрировать полностью автоматизированный цикл формирования и конфигурирования самоуправляемых систем хранения.

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

Динамическая балансировка нагрузки. После запуска системы ключевым фактором становится динамическая балансировка нагрузки, которая помогает снизить потребляемую мощность и справиться с меняющимися рабочими нагрузками, отказами узлов и перегрузками оборудования. Автоматическое перераспределение нагрузки осуществляется путем миграции виртуальных машин.

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

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

Подсистема хранения SoftUDC использует подобную же стратегию балансировки нагрузки.

Реализация центра данных

В системе BladeFrame компании Egenera (www.egenera.com) реализован аппаратный подход к построению центра данных, допускающего разделение на несколько изолированных ферм. Однако эта система, подобно проекту Utility Data Center компании Hewlett-Packard, зависит от аппаратной поддержки разделения. В отличие от них, SoftUDC осуществляет виртуализацию на базе имеющихся аппаратных средств и не накладывает ограничений на топологию сети или аппаратную инфраструктуру, в частности, не требует поддержки виртуальных сетей в локальных сетях и сетях хранения.

Управление центром данных с единой консоли могут обеспечить несколько систем управления кластерами, включая VirtualCenter компании VMware. Дополнительно SoftUDC автоматизирует повседневные задачи администрирования ферм, объединяет разрозненные сетевые ресурсы и запоминающие устройства.

Для достижения целей, стоящих перед SoftUDC, ключевую роль играет виртуализация процессоров. На повышение производительности и гибкости виртуализации нацелены несколько продуктов и проектов, включая Xen [1], Denali [10] и VMware ESX Server. В отличие от них, SoftUDC фокусируется на безопасности виртуальных ферм, которая достигается путем включения программ виртуализации сети и систем хранения данных в мониторы VMM и увязки программных средств виртуализации отдельных узлов в единый комплекс.

Литература
  1. P. Barham et al. Xen and the Art of Virtualization, Proc. 19th ACM Symp. Operating Systems Principles (SOSP 03), ACM Press, 2003.
  2. C.P. Sapuntzakis et al. Optimizing the Migration of Virtual Computers, Proc. 5th Symp. Operating Systems Design and Implementation (OSDI 02), ACM Press, 2002.
  3. M. Karlsson, C. Karamanolis, X. Zhu. Triage: Performance Isolation and Differentiation for Storage Systems, Proc. 12th Int?l Workshop Quality of Service (IWQoS 04), IEEE Press, 2004.
  4. C. Lu, G.A. Alvarez, J. Wilkes. Aqueduct: Online Data Migration with Performance Guarantees, Proc. Conf. Pile Systems and Technology (FAST 02), Usenix Assoc., 2002.
  5. E. Anderson et al. Hippodrome: Running Circles around Storage Administration, Proc. Conf. Pile Systems and Technology (FAST 02), Usenix Assoc., 2002.
  6. E. Lamb. Hardware Spending Spatters, Red Herring, June 2001.
  7. S. Osman et al. The Design and Implementation of Zap: A System for Migrating Computing Environments, Proc. 5th Symp. Operating Systems Design and Implementation (OSDI 02), ACM Press, 2002.
  8. Y. Huang et al. NT-SwiFT: Software Implemented Fault Tolerance on Windows NT, Proc. 2nd Usenix Windows NT Symp., Usenix Assoc., 1998.
  9. D.E. Lowell, Y. Saito, E.J. Samberg. Devirtualizable Virtual Machines Enabling General, Single-Node, Online Maintenance, to be published in Proc. llth Int?l Conf. Architectural Support for Programming Languages and Operating Systems (Asplos XI), ACM Press, 2004.
  10. A. Whitaker, M. Shaw and S.D. Gribble. Scale and Performance in the Denali Isolation Kernel, Proc. 5th Symp. Operating Systems Design and Implementation (OSDI 02), ACM Press, 2002.

Махеш Каллахалла (kallahalla@docomolabs-usa.com) — научный сотрудник лаборатории DoCoMo USA Labs. Над проектом SoftUDC работал в качестве исследователя лаборатории HP Labs. Мустафа Уизал (atmustafa.uysal@hp.com), Рем Сваминатан (ram.swaminathan@hp.com), Дэвид Лоуэлл (david.lowell@hp.com), Майк Рей (mike.wray@hp.com), Том Кристиан (tom.christian@hp.com), Найджел Эдвардс (nigel.edwards@hp.com), Крис Дэлтон (cid@hp.com), Фредерик Джиттлер (frederic.gittler@hp.com) — сотрудники лабораторий HP Labs (Пало-Альто, Калифорния и Бристоль, Великобритания).

Mahesh Kallahalla, Mustafa Uysal, Ram Swaminathan, David Lowell, Mike Wray, Tom Christian, Nigel Edwards, Chris Dalton, Frederic Gittler. SoftUDC: A Software-Based Data Center for Utility Computing, IEEE Computer, November 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.