СИНХРОНИЗАЦИЯ ЖИЗНЕННЫХ ЦИКЛОВ ВИРТУАЛЬНОЙ МАШИНЫ И ПРИЛОЖЕНИЯ

Уровень техники

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

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

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

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

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

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

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

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

Фиг.1А иллюстрирует обзорное представление системы 100, которая содержит уровень 103 приложений и уровень 107 виртуальных машин, которые работают вместе для установки и управления виртуальными машинами совместно с приложениями. Например, фиг.1А показывает, что уровень приложений 103 содержит, по меньшей мере, управляющее приложение 105. Вообще, управляющее приложение 105 содержит один или более наборов исполняемых инструкций, которые выполняют различные запросы (например, установить приложение), исполняя описательную модель - описанный поток последовательности операций способа. Как будет понятно более подробно ниже, управляющее приложение 105 принимает информацию о заданном приложении из различных описательных моделей 115 и дорабатывает эту информацию в конкретные команды, которые посылаются к различным виртуальным машинам.

Например, фиг.1А показывает, что уровень 103 приложений содержит репозиторий 110 приложений. Репозиторий 110 приложений дополнительно содержит набор вышеупомянутых описательных моделей 115, которые связывают различные приложения 135 с соответствующими свойствами 137, включающие в себя "намерения" для приложения. Такие намерения приложения (т.е. в свойствах 137) в описательных моделях 115 могут включать в себя различные функциональные требования аппаратных средств и виртуальной машины для каждого приложения 135, а также информацию жизненного цикла приложения. В частности, намерения данной описательной модели 115 для управляющей программы могут включать в себя разновидности виртуальных машин (например, конкретные сконфигурированные шаблоны виртуальных машин, или даже существующие виртуальные машины), что может потребоваться для запуска заданного приложения 135, в дополнение к числу виртуальных машин, которые могут или должны быть использованы. Например, если запрошенное приложение 115 было распределенным приложением, описательные намерения могли точно определить несколько различных виртуальных машин (и даже типов виртуальных машин) и несколько различных физических хост-узлов (или типов физических хост-узлов) для каждого компонента распределенного приложения. Такие намерения описательной модели могут также включать в себя различную информацию жизненного цикла заданной прикладной программы, такую как максимальный временной интервал, в ходе которого приложение, являющееся перед этим установленным, может исполняться.

В дополнение, фиг.1А показывает, что уровень 103 приложений через управляющее приложение 105 может содержать одну или более общую структуру 123 данных. Вообще, одна или более общая структура 123 данных является доступной широкому диапазону компонентов (включая в себя другие управляющие приложения в системе). Общие структуры 123 данных хранят и соотносят информацию статуса о приложениях и виртуальных машинах, установленных в системе 100. По меньшей мере, в одной реализации структура 123 данных указывает, например, где и когда различные прикладные программы были установлены (физические и/или сетевые размещения), а также где и когда различные виртуальные машины были установлены (физическое и/или сетевое размещение). Как упомянуто ранее, структура 123 данных может дополнительно включать в себя информацию о приложении и/или жизненных циклах виртуальной машины, которую управляющее приложение 105 доработало/определило из описательных моделей 115. Поскольку структура 123 данных является общедоступной для обширного числа компонентов, к структуре 123 данных могут обращаться и обновлять ее различные компоненты на обоих уровнях - уровне 103 приложений и уровне 107 виртуальных машин, для того, чтобы содействовать в поддержке согласованности.

Обращаясь опять к фигурам, фиг.1А показывает, что уровень 107 виртуальных машин может содержать один или более менеджер 120 виртуальных машин. Менеджер 120 виртуальных машин в свою очередь содержит один или более наборов исполняемых инструкций для установки и деинсталлирования виртуальных машин, а также для выделения ресурсов виртуальных машин на заданном хост-узле. Менеджер 120 виртуальных машин также отслеживает производительность каждой виртуальной машины на физическом хост-узле. Например, когда менеджер 120 виртуальных машин устанавливает заданную виртуальную машину, менеджер 120 виртуальных машин также устанавливает один или более агентов-наблюдателей, которые предоставляют обратную связь к менеджеру 120 виртуальных машин. Такая обратная связь может включать в себя качество использования назначенного ресурса (например, являются ли назначения процессора и памяти достаточными), а также то, как запускаются различные прикладные программы, установленные на нем.

В дополнение, фиг.1А показывает, что менеджер 120 виртуальных машин может быть сконфигурирован для связи с одной или более библиотекой 125 виртуальных машин. Вообще, библиотека 125 виртуальных машин состоит из одного или более шаблонов 150 виртуальных машин, где каждый представляет "оперативный резерв", которые менеджер 120 виртуальных машин может копировать поверх и устанавливать на заданный физический хост-узел (например, 130). Например, фиг.1А показывает, что библиотека 125 виртуальных машин содержит хранилище виртуальных машин "VM₁" 150a, "VM₂" 150b, "VM₃" 150c и "VM₄" 150d. Каждая из этих виртуальных машин 150(a-d) в свою очередь может быть индивидуально сконфигурирована для работы с конкретными типами приложений и даже конкретными версиями приложений. Например, виртуальные машины 150a и 150b могут быть индивидуально сконфигурированы (в терминах назначений/потребностей ресурсов) для работы с конкретными версиями приложений базы данных, тогда как виртуальные машины 150c и 150d могут быть индивидуально сконфигурированы (в терминах назначений/потребностей ресурсов) для работы с другими версиями приложений базы данных или, альтернативно, с интернет-приложениями.

В любом случае, каждый из вышеописанных компонентов в системе 100 сконфигурирован для работы вместе для обеспечения того, что приложения и виртуальные машины установлены вместе и деинсталлированы вместе в рамках одних и тех же жизненных циклов. По меньшей мере, в одной реализации эта координация большей частью обрабатывается посредством уровня 103 приложений через управляющее приложение 105. Например, фиг.1А показывает, что уровень 103 приложений получает один или более запрос/инструкцию 113 для установки приложения (т.е. приложения 135a), и этот запрос 113 принимается управляющим приложением 105. В ответ, управляющее приложение 105 посылает один или более запросов 140 в пределах уровня 103 приложений для определения, как запрос должен быть обработан. Например, фиг.1А показывает, что управляющее приложение 105 посылает один или более запросов к репозиторию 110 приложений для идентификации свойств, предназначенных или, другими словами, ассоциативно связанных с запрошенным приложением. Более точно, фиг.1А показывает, что управляющее приложение 105 посылает запрос 140, который запрашивает свойства, ассоциативно связанные с приложением 135а.

Репозиторий 110 приложений в свою очередь идентифицирует одну или более описательные модели 115, ассоциативно связанные с запрошенным приложением 135а. Например, фиг.1А показывает, что этот репозиторий 110 приложений включает в себя хранилище для описательных моделей 115, которое ассоциативно связывает свойства 137a и 137b с приложениями 135a и 135b. Эти свойства выражают различные описательные намерения каждой прикладной программы 135. Такие описательные намерения могут включать в себя требуемую продолжительность запуска прикладной программы, количество и/или тип виртуальных машин, которые должны быть установлены для обработки приложения. Такие описательные намерения также включают в себя такую информацию, как различные сетевые (или физические) размещения, где прикладная программа должна исполняться. Например, администратор может определить, что некоторые приложения должны исполняться только на защищенных серверах и/или в защищенных сетевых размещениях.

В любом случае, по приему запроса 140, фиг.1А показывает, что репозиторий 110 приложений отвечает одним или более сообщениями 145 обратно к управляющему приложению 105. Управляющее приложение 105 может затем интерпретировать или "дорабатывать" свойства 137a, полученные от репозитория 110, и хранить их как набор соответствующих инструкций/команд в одной из одной или более общих структур 123 данных. Вообще, доработка в данном контексте означает прогрессивную переработку деталей принятой от репозитория 110 информации, такую как дополнение данных описательной модели (например, принятой от свойств 137a в сообщении 145), и запись добавленных данных в структуре 123 данных. Как понятно более подробно в материалах настоящей заявки, доработка перерабатывает детали, пока описательная модель не станет достаточно точно понятной и преобразованной конкретным драйвером виртуальной машины.

По меньшей мере, в одной реализации свойства 137, которые соответствуют описательным моделям приложения, могли включать в себя информацию, указывающую, что конкретное приложение 135a идеально устанавливается на две разных виртуальных машины, и эти виртуальные машины должны быть сконфигурированы для использования базой данных. Фиг.1А, таким образом, показывает структуру 123 данных, включающую в себя, по меньшей мере, указание, что приложение 135a должно быть установлено на виртуальных машинах 150a и 150b. В дополнение, свойства 137a могут также включать в себя предпочтение на исполнение прикладной программы 135а на конкретном физическом хост-узле. Таким образом, например, фиг.1А также показывает, что структура 123 данных указывает, что приложение 135 должно быть установлено на физическом хост-узле 130.

При определении различных свойств и инструкций для запрошенной прикладной программы уровень 103 приложений может затем отсылать одну или более инструкций к уровню 107 виртуальных машин для установки подходящих виртуальных машин. Например, фиг.1А показывает, что управляющее приложение 105 посылает одну или более инструкции 147, которые соответствуют доработанной информации, хранимой в структуре 123 данных, к уровню 107 виртуальных машин. Более точно, фиг.1А показывает, что инструкции 147 включают в себя один или более запросов для установки виртуальных машин 150a ("VM₁") и 150b ("VM₂"), и что менеджер 120 виртуальных машин в пределах уровня 107 виртуальных машин принимает эти инструкции.

Тогда уровень 107 виртуальных машин осуществляет запросы. Например, фиг.1А показывает, что менеджер 120 виртуальных машин осуществляет координацию с библиотекой 125 виртуальных машин для идентификации запрошенных шаблонов, которые должны быть установлены, в данном случае - виртуальных машин 150a и 150b. В дополнение, фиг.1А показывает, что менеджер 120 виртуальных машин посылает один или более запросов 155 к физическому хост-узлу 130 для установки виртуальных машин 150a и 150b. По меньшей мере, в одной реализации уровень 107 виртуальных машин (например, через менеджер 120 виртуальных машин) дополнительно осуществляет обратное взаимодействие с уровнем 103 приложений (например, с управляющим приложением 105) одним или более сообщениями (не показаны), которые указывают, что установка и конфигурация виртуальной машины теперь завершена.

Например, менеджер 120 виртуальных машин может передать информацию подтверждения установки (не показана) непосредственно к структуре 123 данных. Управляющее приложение 105 может тогда произвести чтение структуры 123 данных в качестве части периодического обзора или в ответ на некоторый сигнал о том, что структура 123 данных была обновлена. Тогда управляющее приложение 105 идентифицирует, что запрашиваемые виртуальные машины завершили установку. В других случаях, менеджер 120 виртуальных машин передает эту информацию непосредственно управляющему приложению 105, которое затем вносит эту информацию в структуру 123 данных. В любом случае, информация, предоставленная менеджером 120 виртуальных машин, может включать в себя не только сам факт установки на хост-узле 130, но также другую релевантную информацию, такую как имена виртуальных машин и сетевые адреса.

При подтверждении установки/развертывания запрошенных виртуальных машин уровень 103 приложений может тогда устанавливать и конфигурировать запрошенное приложение(я) посредством уровня 107 виртуальных машин. В этих целях фиг.1B показывает, что управляющее приложение 105 взаимодействует непосредственно с драйверами развернутых виртуальных машин 150 на хост-узле 130. Например, управляющее приложение 105 может использовать информацию, предоставленную менеджером 120 виртуальных машин, такую как имена виртуальных машин и сетевые адреса, для определения размещения и идентификации подходящих драйверов виртуальных машин.

В дополнение фиг.1B показывает, что уровень 103 приложений (через управляющее приложение 105) посылает одно или более сообщения/инструкции 160a и 160b к уровню 107 виртуальных машин. Драйверы соответственно адресованных виртуальных машин 150a и 150b тогда принимают сообщения 160a и 160b на физическом хост-узле 130. Вообще, сообщения 160a и 160b могут содержать не только инструкции по установке приложения для запрошенного приложения 135a, но также инструкции, относящиеся к свойствам 137a, предварительно принятым от репозитория 110 приложений. Например, сообщения 160a и 160b могут содержать индивидуально преобразованную/доработанную описательную информацию намерения в форме конкретных команд о жизненном цикле приложения, о том, как приложение должно исполняться на виртуальной машине, а также любую контролируемую информацию.

Драйверы для каждой виртуальной машины 150(a-b) в свою очередь преобразуют и/или реализуют эти команды (160) для соответствующих контейнеров приложений (не показаны) на виртуальной машине. Более точно, проиллюстрированные драйверы виртуальной машины преобразуют достаточно подробные описательные модели в императивные действия, которые должны быть осуществлены на виртуальной машине. Эти преобразованные инструкции в свою очередь управляют и конфигурируют контейнеры приложений и модули приложений на установленных виртуальных машинах 150 в соответствии с намерением, описанным в модели (например, через свойства 137).

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

Информация, предоставляемая драйверами виртуальных машин, может включать в себя не только информацию состояния, относящуюся к установленному приложению 135a и/или виртуальной машине 150(a-b), но также информацию, касающуюся событий о прекращении использования приложения. Например, драйверы виртуальной машины могут посылать одно или более сообщений к управляющему приложению 105, когда приложение, являющееся деинсталлированным, было деинсталлировано, или о том, что должно быть деинсталлировано с хост-узла 130. Информация, предоставляемая драйверами виртуальных машин, может, в свою очередь, быть принята и сохранена в структуре 123 данных. Например, драйверы виртуальной машины 150 посылают одно или больше таких сообщений непосредственно к структуре 123 данных или к управляющему приложению 105, которое затем, соответственно, обновляет структуру 123 данных. В любом случае, уровень 103 приложений может, таким образом, идентифицировать, когда ему нужно начать выводить из эксплуатации соответствующую виртуальную машину(ы).

Например, фиг.1С иллюстрирует, что может произойти, когда конкретная прикладная программа было деинсталлирована с виртуальной машины 150. В частности, когда прикладная программа деинсталлируется, фиг.1С показывает, что уровень 107 виртуальных машин (например, через драйверы на физическом хост-узле 130) посылает одно или более сообщений 170 к уровню 103 приложений для указания того, что приложение 135a должно быть деинсталлировано или было деинсталлировано. Как упоминалось выше, например, физический хост-узел 130 может передать сообщение 170 непосредственно к структуре 123 данных, тогда как в альтернативных реализациях физический хост-узел 130 посылает сообщение 170 к управляющему приложению 105. В любом случае, структура 123 данных в конечном счете обновляется, чтобы отражать удаление приложения. Например, фиг.1С показывает, что структура 123 данных содержит информацию о том, что приложение 135a теперь деинсталлировано. Поскольку в этом примере приложение 135а было единственным приложением, установленным на виртуальной машине 150a и 150b, уровень 103 приложений через управляющее приложение 105, таким образом, определяет, что виртуальные машины 150a и 150b теперь должны быть удалены с физического хост-узла 130, так как они больше не являются используемыми.

Соответственно, фиг.1С показывает, что уровень 103 приложений через управляющее приложение 105 посылает одно или более сообщений 180 к уровню 107 виртуальных машин. Как и ранее, менеджер 120 виртуальных машин затем получает сообщения 180 на уровне 107 виртуальных машин. В проиллюстрированном примере сообщения 180 включают в себя инструкции для удаления виртуальных машин 150a и 105b (т.е., "VM₁" и "VM₂") с одного или более физических хост-узлов, на которых они установлены, в данном случае с физического хост-узла 130. В ответ, уровень 107 виртуальных машин тогда осуществляет любые действия для удаления и подтверждения удаления виртуальных машин. Например, фиг.1С показывает, что менеджер 120 виртуальных машин посылает одно или более соответствующих сообщений 190 к физическому хост-узлу 130, эти сообщения инструктируют физический хост-узел 130 об удалении или деинсталляции виртуальных машин 150a и 150b.

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

Более того, виртуальная машина (или административный компонент, запускающий или хранящий виртуальную машину) может поддерживать несколько различных контрольных точек для заданной виртуальной машины. Таким образом, например, некоторые из виртуальных машин в библиотеке 125 виртуальных машин могут быть настроены различными способами не только по отношению к конкретным конфигурациям приложений, но также и на основе различных контрольных точек для произведенных исправлений или обновлений операционной системы. Подобны образом, виртуальные машины 150a-b, которые установлены на физический хост-узел 130, могут также подвергаться нескольким различным обновлениям контрольных точек, некоторые из них могут быть особенно подходящими для управляющего приложения 135a.

Как результат, в некоторых случаях администратор может выбирать или "удаление" или "вывод из эксплуатации" конкретной версии виртуальной машины 150a-b на физическом хост-узле 130, когда устраняется приложение 135а либо совместно с удалением виртуальной машины, либо лишь с возвращением виртуальной машины к конкретной контрольной точке. В таком случае инструкции 190, посланные от менеджера 120 виртуальных машин, могут альтернативно или дополнительно включать в себя инструкции для возвращения виртуальных машин 150a-b к предшествующей контрольной точке, которая может быть более широко применима для других приложений, которые могут быть позже установлены на физический хост-узел 130.

Будет принято во внимание, что сохранение более ранних версий виртуальных машин 150a-b на физическом хост-узле 130 может сохранить ресурсы, которые могли бы быть нужны в последующей точке для копирования целой виртуальной машины 150 из библиотеки 125 обратно на физический хост-узел 130. Конечно, было ли это удаление или выведение из эксплуатации (т.е. полное удаление, или возвращение к конкретной контрольной точке), система 100 сконфигурирована для обеспечения того, что структура 123 данных может поддерживать релевантную информацию, так что система 100 никогда не потеряет записи отслеживания состояния или присутствия конкретной виртуальной машины или приложения.

Например, фиг.1С дополнительно показывает, что при удалении или выведении из эксплуатации/деинсталляции/возврате виртуальных машин физический хост-узел 130 может тогда послать одно или более подтверждающие сообщения. В частности, уровень 107 виртуальных машин подтверждает уровню 103 приложений, что удаление (т.е. удаление, вывод из эксплуатации или возврат к контрольной точке) виртуальных машин было завершено. Например, физический хост-узел 130 может посылать одно или более подтверждающих сообщений обратно к менеджеру 120 виртуальных машин, который тогда сообщает такую информацию уровню 103 приложений, т.е. менеджер 120 виртуальных машин может обновлять структуру 123 данных информацией об удалении (удалении или возврате к контрольной точке) или, в другом случае, посылать соответствующее сообщение к управляющему приложению 105, которое этим же затем обновит структуру 123 данных. В дополнительных или альтернативных реализациях физический хост-узел 130 взаимодействует напрямую с структурой 123 данных и/или с управляющим приложением 105 для подтверждения удаления (удаления или возврата к контрольной точке) виртуальных машин 150(a-b).

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

В дополнение к вышеупомянутому, реализации настоящего изобретения могут также быть описаны в терминах блок-схем последовательностей операций способа, содержащих одно или более действий в способе для совершения конкретного результата. Например, фиг.2 иллюстрирует блок-схему последовательности операций способа с позиции исполнения приложения 105 для использования одного приложения для установки обеих виртуальных машин и прикладных программ на физическом хост-узле, тогда как фиг.3 иллюстрирует альтернативную блок-схему последовательности операций способа с позиции системы 100 для координирования установки и жизненных циклов прикладных программ и виртуальных машин. Этапы фиг.2 и 3 описаны более подробно ниже по отношению к компонентам и представлениям фиг.1А-1С.

Например, фиг.2 иллюстрирует, что способ с позиции управляющего приложения 105 может содержать этап 200 приема запроса для инициирования приложения. Этап 200 включает в себя прием одного или более запросов на уровне приложений для инициирования прикладной программы. Например, фиг.1А показывает, что уровень 103 приложений через управляющее приложение 105 принимает инструкции 113 по установке приложения, которые включают в себя один или более запросов на установку прикладной программы 135а.

Фиг.2 также показывает, что способ может содержать этап 210 определения виртуальных машин для развертывания. Этап 210 включает в себя определение от одного или более свойств запрошенной прикладной программы, какая из одной или более виртуальных машин должна быть развернута для исполнения запрошенной прикладной программы. Например, фиг.1А показывает, что управляющее приложение 105 устанавливает связь с репозиторием 110 приложений и обменивается сообщениями 140 и 145 для идентификации свойств запрошенного приложения 135а. Эти свойства 137а связывают различные описательные намерения описательных моделей 115, которые соответствуют запрошенному приложению 135a. В дополнение, управляющее приложение 105 дорабатывает и/или преобразует полученные свойства 137а в конкретные инструкции, которые затем поддерживаются в структуре 123 данных. В одной реализации преобразование этих команд включает в себя число и тип виртуальных машин 150, которые должны быть установлены для исполнения запрошенного приложения 135а.

В дополнение, фиг.2 показывает, что способ, с позиции управляющего приложения 105, может содержать этап 220 развертывания подходящих виртуальных машин. Этап 220 включает в себя отправку одного или более запросов от уровня приложений к уровню виртуальных машин для развертывания определенной одной или более виртуальных машин для запрошенной прикладной программы. Например, фиг.1А показывает, что управляющее приложение 105, находящееся на уровне 103 приложений, посылает одно или более сообщений 147 к менеджеру 120 виртуальных машин, находящемуся на уровне 107 виртуальных машин. Как показано на фиг.1А, инструкции 147 включают в себя один или более запросов на установку идентифицированных виртуальных машин 150a и 150b.

Более того, фиг.2 показывает, что способ может содержать этап 230 установки запрошенного приложения на виртуальной машине. Этап 230 включает в себя установку прикладной программы на развернутой одной или более виртуальной машине. Например, как показано на фиг.1B, как только виртуальные машины 150a и 150b были установлены менеджером 120 виртуальных машин на физическом хост-узле 130, уровень 103 приложений через управляющее приложение 105 посылает одно или более сообщений 160a и 160b к соответствующему уровню 107 виртуальных машин через драйверы виртуальных машин 150. Драйверы виртуальных машин, в свою очередь, инструктируют об установке и конфигурации запрошенного приложения 135а в соответствии со свойствами 137а.

В дополнение к вышеупомянутому, фиг.3 иллюстрирует, что дополнительный или альтернативный способ с позиции комплексной системы 100 в соответствии с реализацией настоящего изобретения может содержать этап 300 идентификации свойств приложения для запроса на установку. Этап 300 включает в себя прием одного или более запросов уровня приложений для инициирования прикладной программы, в котором запрошенная прикладная программа содержит одно или более свойств, которые указывают тип и количество виртуальных машин, которые должны быть использованы. Например, фиг.1А показывает, что при приеме запроса 113 на установку управляющее приложение 105 и репозиторий 110 приложений в уровне 103 приложений взаимодействуют для приема свойств 137а, которые относятся к запрошенному приложению 135а. Как обсуждено ранее, свойства 137а могут включать в себя многообразие типов информации о запрошенной прикладной программе 135а, такое как предпочтения типа или размещения физического хост-узла и типы, количества или потребности в ресурсах виртуальных машин, которые должны быть использованы для запуска прикладной программы.

Фиг.3 также показывает, что способ с позиции управляющего приложения 105 может содержать этап 310 просмотра структуры 123 данных для доступных виртуальных машин. Этап 310 включает в себя просмотр одной или более структур данных на уровне приложений для идентификации одной или более виртуальных машин, которые доступны в автоматизированной среде. Например, фиг.1А и 1В показывают, что управляющее приложение 105 на уровне приложений 103 интерпретирует и/или дорабатывает полученные свойства 137а для определения того, что приложение 135а должно быть установлено на хост-узел 130 и в пределах двух виртуальных машин, в данном случае - виртуальных машин 150а и 150b.

В дополнение, фиг.3 показывает, что способ с позиции управляющего приложения 105 может содержать этап 320 установки приложения на предназначенные виртуальные машины. Этап 320 включает в себя инструктирование уровня виртуальных машин по установке запрошенной прикладной программы на одну или более доступные виртуальные машины, которые установлены на один или более физические хост-узлы. Например, как показано на фиг.1А, уровень приложений 103 через управляющее приложение 105 посылает одно или более сообщений 147 к уровню 107 виртуальных машин через менеджер 120 виртуальных машин. Проиллюстрированные сообщения 147 включают в себя инструкции по установке виртуальных машин 150а и 150b на физическом хост-узле 130. Фиг.1А дополнительно показывает, что уровень 107 виртуальных машин действует на запрос так, что менеджер 120 виртуальных машин посылает одно или более соответствующих сообщений 155 к физическому хост-узлу 130. Сообщения 155 в свою очередь инструктируют физический хост-узел 130 об установке запрошенных виртуальных машин 150a и 150b.

Более того, фиг.3 показывает, что способ с позиции управляющего приложения 105 может содержать этап 330 удаления виртуальной машины, когда устраняется приложение. Этап 330 включает в себя, при идентификации посредством структуры данных, что запрошенная прикладная программа была деинсталлирована с виртуальной машины, руководствуясь удалением уровня приложений виртуальной машины с соответствующего физического хост-узла. Например, как показано на фиг.1С, уровень 103 приложений принимает сообщение 170 в структуре 123 либо непосредственно, либо посредством управляющего приложения 105. Управляющее приложение 105 тогда идентифицирует, что приложение 135а было деинсталлировано и, таким образом, что виртуальные машины 150а и 150b должны быть удалены (т.е. удалены с физического хост-узла 130 или возвращены к предыдущей версии на физическом хост-узле 130). Соответственно, уровень приложений 103 через управляющее приложение 105 посылает одно или более сообщений 180 к уровню 107 виртуальных машин для удаления (т.е. удаления или восстановления к контрольной точке) виртуальных машин 150а и 150b с хост-узла 130.

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

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

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

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

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

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