Механизм координации для выбора облака

Изобретение относится к средствам выбора и управления публичной сетью облачных вычислений для размещения учетной информации клиента. Технический результат заключается в автоматическом выборе публичного облака, которое удовлетворяет набору критериев, определенных администраторами, и обеспечении упрощенного взаимодействия с выбранным публичным облаком. Указанный результат обеспечивается выполнением способа распределения нагрузки по одной или более публичным вычислительным сетям, при этом: принимают выданный пользователем частной корпоративной сети запрос на обновление учетной информации; идентифицируют, с использованием средства координации, целевую вычислительную сеть из упомянутых одной или более публичных вычислительных сетей; переводят упомянутые одну или более команд в формат, совместимый с языком правил, соблюдаемым целевой вычислительной сетью при взаимодействии с внешним источником; и инициируют распределение этих одной или более переведенных команд по вычислительным ресурсам, связанным с целевой вычислительной сетью, которые предназначены для выполнения упомянутого обновления учетной информации. 3 н. и 17 з.п. ф-лы, 8 ил.

 

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

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

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

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

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

Варианты осуществления настоящего изобретения подробно описаны ниже со ссылкой на прилагаемые чертежи, на которых:

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

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

Фиг. 3 представляет собой примерное схематическое представление манифеста, в котором перечислены свойства, абстрагированные от публичных и/или частных облаков, в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 4 представляет собой примерное схематическое представление манифеста, в котором перечислены условия, представленные администратором для направления выбора публичного и/или частного облака(ов), в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 5 представляет собой структурную схему, иллюстрирующую распределенную вычислительную среду, используемую для облечения выбора публичного и/или частного облака(ов), в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 6 представляет собой структурную схему, иллюстрирующую распределенную вычислительную среду, используемую для облечения взаимодействия между публичным и/или частным облаком(ами), в соответствии с вариантом осуществления настоящего изобретения;

Фиг. 7 представляет собой блок-схему, показывающую общий способ для назначения нагрузки одной или более потенциально подходящим компьютерным сетям (компьютерным сетям-кандидатам) на основе критериев, предоставленных от клиента, в соответствии с вариантом осуществления настоящего изобретения; и

Фиг. 8 представляет собой блок-схему, показывающую общий способ для распределения нагрузки по одной или более публичным вычислительным сетям, внешним по отношению к частной корпоративной сети, в соответствии с вариантом осуществления настоящего изобретения.

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

Предмет вариантов осуществления настоящего изобретения описан со специфичностью в материалах настоящей заявки, чтобы удовлетворить установленным требованиям. Однако, само описание не предназначено для ограничения объема этого патента. Напротив, авторы настоящего изобретения предполагают, что заявленное изобретение также может быть воплощено другими способами, чтобы включать в себя другие шаги или комбинации шагов, аналогичные описанным в настоящем документе, в сочетании с другими существующими или будущими технологиями. Также будет отмечено, что раскрытие этого патентного документа содержит материал, на который распространяется защита авторского права, например, выражение "Гибридный облачный координатор". Обладатель авторского права не имеет возражений против факсимильного воспроизведения кем-либо, имеющим отношение к патентному документу или раскрытию патента, при его появлении в патентных фондах или регистрационных записях Патентного ведомства США, но во всех иных случаях абсолютно все любые другие авторские права защищены. Следующее замечание будет применяться к частям этого документа: Авторское право (Copyright) 2011.

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

Как используется в материалах настоящей заявки, выражение "механизм координации" не предназначено, чтобы быть ограниченным какой-либо конкретной частью программного обеспечения, находящейся в каком-либо одном местоположении, но в целом относится к интеллектуальному программному компоненту, способному управлять и балансировать использованием обоих облачных предложений (публичного и частного) непрерывным способом. Механизм координации может быть предложен как отдельный сервис от независимого субъекта. Или механизм координации может быть предложен как часть решения от поставщика облачного сервиса. В примерном варианте осуществления механизм координации выполняет, по меньшей мере, три взаимно дополняющие функции: (a) предоставление учетных записей в облаках, (b) отслеживание результатов/истории предоставления для будущего анализа и оптимизации, и (c) управление решениями на основе условий, предоставленных клиентом в свете свойств, абстрагированных от облаков.

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

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

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

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

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

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

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

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

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

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

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

Операционная среда

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

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

Как показано на Фиг. 1, вычислительное устройство 100 включает в себя шину 110, которая непосредственно или опосредованно соединяет следующие устройства: память 112, один или более процессоров 114, один или более компонентов 116 представления, порты 118 ввода/вывода (I/O), компоненты 120 ввода/вывода, и иллюстративный источник 122 электропитания. Шина 110 представляет то, что может быть одна или более шин (например, адресная шина, шина данных или их комбинация). Хотя различные блоки на Фиг. 1 показаны вместе с линиями для ясности, в действительности разграничение различных компонентов не так ясно, и в переносном смысле, линии были бы более точно серыми и нечеткими. Например, можно рассматривать компонент представления, такой как устройство отображения, как компонент I/O. Также процессоры имеют память. Авторы изобретения признают, что такова природа области техники, и повторяют, что схема на Фиг. 1 является лишь иллюстрацией примерного вычислительного устройства, которое может использоваться в связи с одним или более вариантами осуществления настоящего изобретения. Различие не делается между такими категориями, как "рабочая станция", "сервер", "ноутбук", "карманное устройство", и т.д., поскольку все рассматриваются в объеме Фиг. 1 и ссылки на "вычислительное устройство".

Вычислительное устройство 100, как правило, включает в себя множество машинно-читаемых носителей. Машинно-читаемые носители могут быть любыми доступными носителями, к которым может быть осуществлен доступ вычислительным устройством 100, и включают в себя как энергозависимые и энергонезависимые, так и съемные и несъемные носители. В качестве примера, а не ограничения, машинно-читаемые носители могут содержать компьютерные запоминающие носители и среды связи. Компьютерные запоминающие носители включают в себя как энергозависимые и энергонезависимые, так и съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как машинно-читаемые инструкции, структуры данных, программные модули, или другие данные. Компьютерные запоминающие носители включают в себя, но не ограничены этим, ОЗУ, ПЗУ, ЭСППЗУ (электрически стираемое и программируемое ПЗУ, EEPROM), флеш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другие оптические запоминающие устройства, магнитные кассеты, магнитную ленту, магнитные дисковые или другие магнитные запоминающие устройства, либо любой другой носитель, который может использоваться для хранения требуемой информации и к которому может быть осуществлен доступ вычислительным устройством 100. Среду связи, как правило, воплощают машинно-читаемые инструкции, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущая волна или другой транспортный механизм, и включают в себя любые среды доставки информации. Термин "модулированный сигнал данных" означает сигнал, который обладает одной или более из своих характеристик, устанавливаемых или изменяемых таким образом, чтобы закодировать информацию в сигнале. В качестве примера, а не ограничения, среды связи включают в себя проводную среду, такую как проводная сеть или прямое проводное соединение, и беспроводную среду, такую как акустическая, РЧ (радиочастотная, RF), инфракрасная и другие беспроводные среды. Комбинации любых из вышеперечисленных сред и носителей также должны охватываться понятием «машинно-читаемый носитель».

Память 112 включает в себя компьютерные запоминающие носители в виде энергозависимой и/или энергонезависимой памяти. Память может быть съемной, несъемной или комбинацией этого. Примерные аппаратные устройства включают в себя полупроводниковую память, жесткие диски, оптические дисковые приводы и т.д. Вычислительное устройство 100 включает в себя один или более процессоров, которые читают данные из различных сущностей, таких как память 112 или компоненты 120 ввода/вывода (I/O). Компонент(ы) 116 представления представляют указания данных пользователю или другим устройствам. Примерные компоненты представления включают в себя устройство отображения, динамик, печатающий компонент, вибрирующий компонент и т.д.

Порты 118 I/O позволяют вычислительному устройству 100 быть логически соединенным с другими устройствами, включающими в себя компоненты 120 I/O, некоторые из которых могут быть встроенными. Иллюстративные компоненты включают в себя микрофон, джойстик, игровой манипулятор, спутниковую тарелку, сканер, принтер, беспроводное устройство, и т.д.

Система для реализации

Вариантами осуществления настоящего изобретения представлена технология для предоставления и управления сервисами (например, приложениями и данными) в нескольких облаках, как частных, так и публичных. Эта технология также поможет определить оптимальное предназначение различных доступных облаков на основе критериев (например, политики конфигурации и целевое состояние), предоставленных клиентом, например, безопасность, производительность, стоимость, избыточность и резервное копирование. Примерная система для реализации этой технологии теперь будет обсуждена со ссылкой на Фиг. 2. В целом эта технология использует механизм 230 координации для взаимодействия между клиентом 205, частным облаком 210 и одним или более публичными облаками 250. В одном из примеров взаимодействие включает в себя абстрагирование информации (например, метрик), которая описывает сервисы, предлагаемые в нескольких облаках, где некоторые облака могут быть выполнены с избыточностью (предоставляя повышенную устойчивость и стабильность), тогда как другие облака являются менее дорогими (предлагают меньше возможностей). Как только информация абстрагирована и проанализирована, координация может опубликовать информацию клиенту 205, чтобы принять решение, какие облака выбирать в качестве целевых. Или координация может сравнить желаемые возможности, введенные клиентом 205, с абстрагированной информацией, чтобы автоматически выбрать в качестве целевого наиболее подходящее облако(а).

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

Как показано на Фиг. 2, проиллюстрирована структурная схема, показывающая распределенную вычислительную среду 200, подходящую для использования в реализации вариантов осуществления настоящего изобретения. Распределенная вычислительная среда 200 включает в себя клиента 205, связанного с частным облаком 210, уровень 220 абстракции в частном облаке 210, механизм 230 координации для взаимодействия между различными компонентами, механизм 235 обратной связи, подчиненное облако 240 для размещения различных компонентов, группу публичных облаков 250, ценового агента 260, агент 265 безопасности, базу 270 данных (БД, DB) правил, агент 275 производительности и БД 280 метрик. Рядовым специалистам в данной области техники будет понятно и принято ими во внимание, что облака 210, 240 и 250, показанные на Фиг. 2, являются лишь примером вычислительных сетей, подходящих для размещения нагрузки (например, данных и/или сервисных приложений), и не предназначены для какого-либо ограничения как объема использования, так и функциональности вариантов осуществления настоящего изобретения. Также облака 210, 240 и 250 не должны интерпретироваться как имеющие какую-либо зависимость или требование, связанное с каким-либо одним ресурсом, комбинацией ресурсов (например, БД 270 и 280) или набором API (например, механизмом 230 координации), чтобы получить доступ к ресурсам. Кроме того, хотя различные блоки на Фиг. 2 показаны вместе с линиями для ясности, в действительности разграничение различных компонентов не так ясно, и в переносном смысле, линии были бы более точно серыми и нечеткими.

Подчиненное облако 240 представляет любую сеть облачных вычислений (например, расширение частного облака 210 или одного из публичных облаков 250, рассматриваемых в качестве целевого) и может включать в себя различные ресурсы, которые коммуникативно связаны с механизмом 230 координации. Некоторые из ресурсов включают в себя механизм 235 обратной связи, ценовой агент 260, агент 265 безопасности и агент 275 производительности, которые представляют программные компоненты, программы или приложения, которые взаимно соединены через подчиненное облако 240. Подчиненное облако 240 размещает эти ресурсы на материальных вычислительных элементах, таких как узлы или виртуальные машины в узлах. Соответственно, ресурсы могут быть распределенным образом размещены по различным физическим вычислительным элементам, в противоположность тому, чтобы быть отдельными, автономными элементами. Кроме того, подчиненное облако 240 обеспечивает связь по каналам, соединяющим ресурсы с сервисами (например, уровнем 220 абстракции) в других сетях облачных вычислений, например, частном облаке 210 и публичных облаках 250. В качестве примера, каналы связи могут включать в себя, без ограничения, одну или более локальных сетей (LAN) и/или глобальных сетей (WAN). Такие сетевые среды являются обычными в офисах, корпоративных компьютерных сетях, сетях интранет (локальных сетях, основанных на технологиях сети Интернет) и сети Интернет. Соответственно, сеть дополнительно не описана в материалах настоящей заявки.

Примерная конфигурация БД 270 и 280 будет теперь обсуждена. Изначально, БД 270 и 280 представляют хранилища данных, являющиеся внутренними или внешними по отношению к подчиненному облаку 240 и запрограммированные для размещения различных типов данных. Например, БД 270 правил может быть запрограммирована, чтобы сохранить условия, предоставленные администратором (например, клиентом 205), связанные с частным облаком 210, где "условия" представляют критерии, которые администратор считает ценными для воплощения для внешней сети облачных вычислений. Таким образом, в процессе работы, условия помогают администратору идентифицировать возможности одного или более из публичных облаков 250, которые бы наилучшим образом поддерживали приложение или данные, которые должны быть размещены. Кроме того, условия помогают механизму 230 координации, при доступе к БД 270 правил, выбрать наиболее подходящее облако(а), публичное и/или частное, чтобы назначить в качестве целевых облаков для приема нагрузки. В другом варианте осуществления БД 280 метрик запрограммирована, чтобы принимать и поддерживать свойства (например, абстрагированную информацию), которые описывают качества публичных облаков 250, назначенных в качестве кандидатов для размещения учетной информации.

БД 270 и 280 в целом выполнены с возможностью хранения информации, связанной с процедурой анализа для сравнения абстрагированных от облака метрик с предоставленными клиентом критериями, как обсуждено ниже со ссылкой на Фиг. 5. В различных вариантах осуществления такая информация может включать в себя, без ограничений, условия, критерии, абстрагированную информацию, метрики и другие свойства облаков 210, 240 и 250. Кроме того, БД 270 и 280 могут быть выполнены, чтобы быть доступными для поиска подходящего доступа хранимой информации. Например, БД 270 правил может быть доступной для поиска условий, критериев и другой информации, показанной на Фиг. 4, тогда как БД 280 метрик может быть доступной для поиска метрик, свойств облаков и другой информации, показанной на Фиг. 3. Специалистам в данной области техники будет понятно и принято ими во внимание, что информация, хранимая в БД 270 и 280 может быть настраиваемой и может включать в себя любую информацию, относящуюся к функциональности, выполняемой механизмом 230 координации. Содержимое и объем такой информации не предназначены, чтобы ограничивать объем вариантов осуществления настоящего изобретения каким-либо образом. Кроме того, хотя проиллюстрированы в виде отдельных, независимых компонентов, БД 270 и 280 могут фактически быть множеством хранилищ данных, например, кластером баз данных, части которых могут располагаться в подчиненном облаке 240, других облаках 210 и 250, другом внешнем вычислительном устройстве (не показано) и/или комбинации перечисленного.

Примерный набор информации, хранимой в БД 280 метрик, будет теперь обсужден со ссылкой на Фиг. 3. В целом Фиг. 3 показывает примерное схематическое представление манифеста 300, в котором перечислены свойства, абстрагированные от публичных и/или частных облаков в соответствии с вариантом осуществления настоящего изобретения. Эти свойства могут храниться в виде записей в манифесте 300 БД 280 метрик. Как проиллюстрировано, первая запись в манифесте 300 описывает ресурс типа хранения в сети облачных вычислений, которой управляет сервис (например, Amazon), который направлен на то, чтобы хранить данные. Оценка доступности (99,9%) для этого сервиса хранения представляет одну из метрик, используемых механизмом 230 координации на Фиг. 2 для принятия решений в свете условий в БД 270 правил. В одном из примеров оценка доступности представляет процент времени, в течение которого ожидается, что сервис хранения будет доступен без разъединения или не упадет в режим офлайн. Оценка производительности (123,456) используется для выбора подходящего сервиса, когда вычислительная мощность (например, ГБ/с или CPU) заданы в качестве желаемых критериев. Ценовая схема ($0,02 за ГБ) обычно представляет собой тариф, взимаемый сервисом хранения за выделение вычислительной мощности на поддержку данных клиента удаленно.

Далее, вторая запись в манифесте описывает ресурс типа размещения в сети облачных вычислений, которой управляет сервис (например, Windows Azure), который направлен на размещение приложения. Как правило, приложение распределено по виртуальным машинам, работающим в узлах в сервисе размещения. По сравнению с сервисом хранения, оценивается, что сервис размещения имеет более высокую оценку доступности, что соответствует большей доступности клиентом. Также сервис размещения второй записи имеет более высокую оценку производительности, чем сервис хранения, что соответствует более быстрой обработке. Наконец, ценовая схема ($0,15 в час) сервиса размещения задана в формате, отличном от схемы сервиса хранения. БД 280 метрик выполнена с возможностью преобразования различных ценовых схем в нормализованную схему для получения возможности сравнения между сервисом хранения и сервисом размещения.

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

Обращаясь теперь к Фиг. 4, показано примерное схематическое представление манифеста 400, в котором перечислены условия или критерии, представленные администратором для направления выбора публичного и/или частного облака(ов), в соответствии с вариантом осуществления настоящего изобретения. Как правило, манифест 400 поддерживается БД 270 правил на Фиг. 2. Как проиллюстрировано, манифест 400 включает в себя две записи: первую запись, которая описывает критерии, связанные с хранилищем данных; и вторую запись, которая описывает критерии, связанные с размещением приложения на удаленной виртуальной машине. В частности, клиент определил первый критерий значимости в первой записи, который управляет выбором сервиса хранения в соответствии с ценой (например, цена <=$0,10 за ГБ), при этом клиент определил второй критерий значимости во второй записи, который управляет выбором виртуальной машины для размещения приложения в соответствии с отсутствием простоя (например, доступность >99,99%). Таким образом, клиент имеет возможность выбрать различные критерии важности по отношению к различным типам ресурсов, доступных в публичных облаках 250.

В процессе работы, например, механизм 230 координации может выполнять анализ критериев в манифесте 400 на Фиг. 4 относительно метрик в манифесте 300 на Фиг. 3. В результате анализа механизм координации может выбрать подходящее облако в качестве цели для использования, когда вызвано использование удаленных ресурсов. Как проиллюстрировано, когда дополнительное внешнее хранилище для данных частного облака разыскивается механизмом координации, клиент определил, что ценовые критерии будут ниже порога в $0,10 за ГБ. Метрики указывают, что сеть облачных вычислений Amazon взимает более высокий тариф $0,20 за ГБ и, соответственно, не рассматривалась бы в качестве кандидата для поддержки хранилища данных. Однако, когда дополнительная внешняя производительность обработки для виртуальных машин разыскивается механизмом координации, клиент определил, что критерий доступности будет выше, чем 99,99%. Метрики указывают, что сеть облачных вычислений Windows Azure предлагает доступность 99,999%, и, соответственно, вероятно рассматривалась бы в качестве кандидата для размещения приложения.

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

В вариантах осуществления механизмом 230 координации используется язык правил, который определяет, как механизм координации будет взвешивать критерии, которые соответствуют метриками, где обработка по взвешиванию (например, прикрепление различной важности к отдельным критериям) управляет решением касаемо того, какое публичное облако (например, облако I 251, облако II 252 и/или облако III 253) выбрать в качестве целевого для предоставления ресурсов для частного облака 210 на Фиг. 2. В одном из примеров язык правил может также способствовать в определении правил, используемых механизмом координации при выполнении анализа критериев в свете метрик. Например, правила могут управлять тем, какие критерии являются абсолютными (должны быть удовлетворены метриками облака, чтобы рассматривать его в качестве кандидата для размещения), а какие критерии являются необязательными (желательным атрибутом для облака, но не исключающим из рассмотрения).

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

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

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

Возвращаясь к Фиг. 2, сейчас будет обсужден уровень 220 абстракции (например, пакет программ для разработки приложений), расположенный в частном облаке 210. Как проиллюстрировано, уровень 220 абстракции включает в себя различные интерфейсы, которые обычно предоставлены, чтобы служить в качестве посредника, через которого клиент 205 может взаимодействовать с механизмом 230 координации, расположенным в подчиненном облаке 240, которое может быть, а может не быть связанным с частным облаком 210. Эти различные интерфейсы включают в себя, но не ограничены этим, следующие: интерфейс 221 правил, интерфейс 222 управления ресурсами и интерфейс 223 критериев.

В одном из примеров интерфейс 221 правил и интерфейс 223 критериев позволяют клиентам программно определять правила и критерии, соответственно, на которые механизм 230 координации обращал бы внимание при выборе облаков-кандидатов, что, в свою очередь, приводит к предоставлению ресурсов в выбранных облаках, которые соответствуют условиям, продиктованным/желаемым клиентом 205. Работа интерфейсов 221 и 223 будет обсуждена более полно ниже со ссылкой на способ обеспечения выбора облака, изображенного на Фиг. 5. В другом примере интерфейс 222 управления ресурсами работает как механизм для разрешения клиенту 205 прозрачно взаимодействовать с целевым облаком, выбранным из публичных облаков 250, без выполнения детальных преобразований команд или изучения протоколов внешних центров обработки данных. Соответственно, интерфейс 222 управления ресурсами на уровне 220 абстракции действует как библиотека протоколов, используемых публичными облаками 250, и, вдобавок, действует как переводчик, который использует библиотеку для автоматического преобразования команд клиента на подходящий язык и формат. Таким образом, интерфейс 222 управления ресурсами способен принимать абстрактные инструкции, такие как увеличить/уменьшить емкость внешнего хранилища файла, без какого-либо конкретного знания фактической реализации облака.

Как кратко отмечено выше, агентам 260, 265 и 275 определена задача периодического наполнения информации, которая подается в БД 280 метрик, чтобы обновлять метрики (например, записи манифеста 300 на Фиг. 3), которые доступны механизму 230 координации. В одном из примеров метрики извлекаются из публичных облаков 251-253 индивидуально. В другом примере метрики могут быть добыты из других источников, таких как подчиненное облако 240, частное облако 210 и тому подобные, чтобы рассмотреть эти другие источники в качестве кандидатов для размещения клиентских данных и/или приложения(ий). Точные источники, которые исследуются агентами 260, 265 и 275, могут быть определены вручную клиентом 205 или автоматически установлены системой. В одном из вариантов осуществления автоматического установления источников для исследования, схема базы данных может быть сгенерирована, чтобы управлять местоположением и идентификационными данными информации, которая собирается из источников.

В целом агентам назначаются отдельные роли, которые включают в себя взаимно исключающую информацию для сбора и представления в БД 280 метрик. Например, ценовому агенту 260 может быть назначена роль динамического сбора ценовой информации из различных источников. В конкретном примере ценовой агент 260 может быть направлен к различным онлайн местоположениям (например, адресам URL) и может быть программно настроен для извлечения ценовой информации из облаков, прибывшей в результате навигации по онлайн местоположениям. Как проиллюстрировано, ценовой агент 260 направлен к трем онлайн местоположениям, которые соответствуют публичному облаку I 251, публичному облаку II 252 и публичному облаку III 253, соответственно. Ценовой агент 260 может быть создан с параметрами, которые управляют тем, как взаимодействовать с публичными облаками 251-253. Далее, ценовой агент 260 может быть создан с параметрами, которые управляют тем, когда осуществлять контакт с публичными облаками 251-253. Например, ценовой агент 260 может быть запрограммирован для сбора определенной информации из публичных облаков 251-253, назначенных в качестве облаков-кандидатов, в предопределенном интервале. В вариантах осуществления механизм 230 координации отвечает за создание и управление параметрами ценового агента 260, тогда как клиент 205 часто имеет возможность изменять параметры конфигурации ценового агента 260, чтобы соответствовать одному или более правилам в БД 270 правил, например.

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

Хотя ценовой агент 260, который запрограммирован для извлечения ценовой информации (например, ожидаемой платы за использование) из публичных облаков 251-253, был подробно описан, варианты осуществления настоящего изобретения предполагают множество других агентов, которые взаимодействуют с публичными облаками 250 (например, взаимодействуют непосредственно или через API) и собирают множество другой информации, которая может считаться полезной для оценки облака. Подобно ценовому агенту 260, эти другие агенты могут быть запрограммированы для динамического сбора информации (например, свойств, атрибутов, характеристик и тому подобного) из публичных облаков 251-253 путем обхода публичных облаков 251-253 и сообщения собранной информации в БД 280 метрик. В одном из примеров агенты могут включать в себя агент 265 безопасности, который запрограммирован для измерения уровня безопасности, установленного публичными облаками 251-253 соответственно, и/или агент 275 производительности, который запрограммирован для измерения уровня поддержки доступности публичными облаками 251-253, соответственно.

Хотя различные определенные скорости сбора данных (например, 10 сканирований в минуту) были очерчены для агентов 260, 265 и 275, следует принимать во внимание и понимать, что варианты осуществления настоящего изобретения рассматривают любой тип временного основания для сбора информации из облаков, по которым совершили обход агенты 260, 265 и 275. Например, определенные взаимодействия клиента 205 с уровнем 220 абстракции могут побудить механизм 230 координации попросить, чтобы агенты 260, 265 и 275 обновили БД 280 метрик.

Кроме того, хотя изображены в подчиненном облаке 240, которое является тем же облаком, которое размещает механизм 230 координации, агенты 260, 265 и 275 могут быть расположены в любом частном или публичном облаке. Например, если агенты 260, 265 и 275 начинают потреблять слишком много ресурсов, они могут быть перемещены в одно или более из публичных облаков 250.

Механизм 235 обратной связи обычно выполнен с возможностью оценки решений механизма 230 координации, чтобы осуществить доступ в зависимости от того, удовлетворяет ли целевое облако критериям, определенным клиентом 205, присущим тому, чтобы быть выбранным для использования. В вариантах осуществления, оценка, выполненная механизмом 235 обратной связи, включает в себя различные шаги, такие как следующие: просмотр прошлых решений механизма 230 координации; самостоятельная оценка влияния этих решений, чтобы улучшить производительность; и применение результата самооценки к БД 270 правил. Соответственно, механизм 235 обратной связи автоматически устанавливает или изменяет правила, чтобы отфильтровать ложные критерии из тех критериев, которые так надежны, как ожидается. Таким образом, механизм 235 обратной связи может адаптировать правила к тому, чтобы повторно взвесить критерии и игнорировать некоторую информацию, взятую из публичных облаков 251-253, как являющуюся устойчиво неточной, чтобы фактически достичь желаемых результатов.

Механизм координации

Механизм 230 координации в целом представляет интеллектуальный программный компонент, приспособленный управлять и балансировать использование обоих облачных предложений (публичного и частного) прозрачным образом. В вариантах осуществления механизм 230 координации может быть предложен как часть решения частного облака (инсталлирован как функциональная составляющая в устройстве в частном облаке 210) или, как проиллюстрировано на Фиг. 2, расположен удаленно от клиента 205 в подчиненном облаке 240. Кроме того, механизм 230 координации может быть разделен или воспроизведен в двух или более центрах обработки данных. В процессе работы механизм 230 координации непрерывно выполняет две взаимно дополняющие функции: принятие решений на основе правил, предоставленных клиентом 205 в свете метрик; и предоставление учетных записей по облакам 210, 240 и/или 250, при этом отслеживая результаты/историю для будущего анализа и оптимизации (например, используя механизм 235 обратной связи).

Что касается первой функции, указанной выше, механизм 230 координации может быть спроектирован для решения касаемо того, какие из публичных облаков 250 рассматриваются в качестве облаков-кандидатов, и выбора в качестве целевого облака для размещения учетной информации клиента одного или более из облаков-кандидатов. В вариантах осуществления процесс решения, какие из публичных облаков 250 должны быть рассмотрены в качестве облаков-кандидатов, включает в себя доступ к БД 270 правил, чтобы рассмотреть критерии в свете правил, и доступ к БД 280 метрик, чтобы рассмотреть метрики (например, свойства, индивидуальные для публичных облаков 250). Как правило, рассмотрение включает в себя осуществление доступа к БД 270 и 280, которые содержат информацию, организованную в соответствии со схемой базы данных, чтобы способствовать их надлежащему обнаружению, и извлечение соответствующей информации из БД 270 и 280. В вариантах осуществления процесс выбора целевого облака из публичных облаков 250 включает в себя выбор целевого облака в зависимости от сравнения между извлеченной информацией и критериями, взвешенными/измененными с помощью правил, где целевое облако показывает метрики, которые в значительной мере удовлетворяют критериям. При выборе целевого облака, механизм 230 координации может быть дополнительно выполнен с возможностью отправки запроса в целевое облако, чтобы инициировать взаимодействие с целевым облаком и чтобы выделить вычислительные ресурсы для размещения, по меньшей мере, части учетной записи клиента.

Что касается второй функции, указанной выше, механизм 230 координации приспособлен управлять деятельностью клиента в целевом облаке(ах). В одном из примеров этот способ управления деятельностью клиента позволяет клиенту 205 предоставлять команды с запросами, которые состоят из абстрактной информации, которая в целом описывает намеченные взаимодействия частного облака 210 с основанной на облаке платформой (например, облаками 240 и 250). Эти запросы могут быть выданы и осуществлены без того, чтобы клиент 205 отслеживал и/или анализировал низкоуровневые детали повседневной работы системы. Таким образом, механизм 230 координации избавляет клиента 205 от понимания реализации каждого API, который отслеживает текущие транзакции между частным облаком 210, через интерфейс 222 управления ресурсами, и платформой облачных вычислений. Другими словами, клиент 205 не должен иметь заранее знаний о том, куда новые данные должны быть адресованы, и где хранятся старые данные. Вместо этого, клиент 205 отвечает лишь за генерирование не специфичных для облака запросов на использование ресурсов, где запросы включают в себя команды, которые сформированы абстрактным образом. В вариантах осуществления механизм 230 координации также содействует клиенту 205 в использовании мощности публичных облаков 250 всякий раз, когда оно удовлетворяет его целям, без нарушения нормальной работы частного облака 210.

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

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

Как только доступ к механизму 230 координации получен, компания может сконфигурировать механизм 230 координации путем установки правил и критериев через интерфейс 221 правил и интерфейс 223 критериев, соответственно, уровня 220 абстракции. При установке критериев компания может главным образом остановить свой выбор на самой низкой цене. Механизм 230 координации понял бы текущие цены для публичных облаков 250, которые назначены в качестве облаков-кандидатов (например, облака, которые компания идентифицировала, как те, которые она готова была бы использовать). Кроме того, компания может представить расходы по эксплуатации (т.е., стоимость обслуживания) для работы частного облака 210, чтобы сделать его рассматриваемым в качестве одного из облаков-кандидатов.

Через некоторое время компания может выдать запрос на определенное количество ГБ памяти для вновь сформированных данных. Механизм 230 координации во время выдачи запроса будет пытаться найти наименее дорогое облако-кандидат. Как только наименее дорогое облако-кандидат обнаружено, оно назначается в качестве целевого облака и предоставляется, чтобы служить требованиям компании по хранению данных, как передано в запросе. Кроме того, в вариантах осуществления механизм координации может вернуть маркер, представляющий учетную запись хранения, размещенную в целевом облаке. Компания может использовать маркер, чтобы вызвать учетную запись хранения через уровень 220 абстракции при выдаче команд чтения/записи, чтобы оказать влияние на данные в учетной записи хранения. Механизм координации использует маркер для идентификации целевого облака и для перевода команд чтения/записи в собственные команды целевого облака. Соответственно, ответственность компании за идентификацию целевого облака в запросе и за перевод команд, встроенных в запрос, принята на себя механизмом 230 координации.

Распределенная вычислительная среда 200 является только одним из примеров подходящей среды, которая может быть реализована для выполнения аспектов настоящего изобретения, и не подразумевается предлагающей какое бы то ни было ограничение в отношении объема использования или функциональных возможностей изобретения. Также проиллюстрированная примерная системная архитектура распределенной вычислительной системы 200 не должна интерпретироваться в качестве обладающей какой-либо зависимостью или требованием, относящимся к любому одному или комбинации из компонентов 220, 230, 235, 260, 265, 270, 275 и 280, как проиллюстрировано. В некоторых вариантах осуществления один или более из компонентов 220, 230, 235, 260, 265, 270, 275 и 280 могут быть реализованы как автономные устройства. В других вариантах осуществления один или более из компонентов 220, 230, 235, 260, 265, 270, 275 и 280 могут быть интегрированы непосредственно в одно или более из облаков 210, 240 или 250. Рядовым специалистам в данной области техники будет понятно, что компоненты 220, 230, 235, 260, 265, 270, 275 и 280, проиллюстрированные на Фиг. 2, являются примерными по природе и количеству и не должны быть истолкованы как ограничивающие.

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

Способ обеспечения выбора облака

Обращаясь теперь к Фиг. 5, показана структурная схема, иллюстрирующая распределенную вычислительную среду 500, используемую для облечения выбора публичного и/или частного облака(ов), в соответствии с вариантом осуществления настоящего изобретения. Как проиллюстрировано, вычислительная среда 500 включает в себя аспекты вычислительной среды 200 на Фиг. 2, где одинаковые ссылочные позиции представляют, по существу, аналогичные компоненты. Кроме того, вычислительная среда 500 будет обсуждена в контексте блок-схемы на Фиг. 7, где блок-схема показывает полный способ 700 для назначения нагрузки одной или более компьютерной сети-кандидату на основе критериев, предоставленных администратором 510, в соответствии с вариантом осуществления настоящего изобретения. Хоте термины "шаг" и "блок" используются ниже в материалах настоящей заявки, чтобы подразумевать различные элементы используемых способов, термины не должны интерпретироваться как подразумевающие какой-либо конкретный порядок среди или между различных шагов, раскрытых в материалах настоящей заявки, если не, и за исключением того, когда порядок отдельных шагов явно описан.

Изначально администратор 510 (сотрудник отдела ИТ клиента) может заметить, что частное облако 210 предприятия генерирует значительное увеличение в использовании приложения, таким образом создавая спрос на размещение сервисов, которые предоставляют виртуальные машины. Администратор 510 может выдать запрос 530 на ресурсы через уровень 220 абстракции в механизм 230 координации, как указано в блоке 710. В одном из примеров запрос 530 может быть на 100 терабайт вычислительных ресурсов для шестимесячного проекта.

Как указано в блоке 720, администратор 510 может дополнительно предоставить правила 520 и критерии 525 в запросе через интерфейс 221 правил и интерфейс 223 критериев, соответственно. В одном из примеров предоставления критериев 525 администратор 510 может осуществить доступ к приложению взаимодействия, которое сотрудничает с уровнем 220 абстракции, который визуализирует GUI, в котором администратор может представить запрос на вычислительную мощность с сопроводительными критериями 525. Как правило, критерии 525 определяют предпочитаемые клиентом свойства оптимального публичного облака. В качестве примера, сопроводительные критерии 525 могут указывать, что низкая цена является наиболее важной, тогда как другие критерии 525, такие как требования высокой безопасности и высокой производительности, являются желательными, хотя и необязательными.

При передаче запроса 530 в механизм 230 координации, механизм 230 координации может выполнить анализ критериев 525 по отношению к метрикам в БД 280 метрик, как указано в блоке 730. В примерном варианте осуществления процесс анализа включает в себя выполнение следующих шагов, на которых: осуществляют доступ к метрикам в БД 280 метрик (см. блок 740), и сравнивают критерии 525 с метриками (см. блок 750). В вариантах осуществления механизм 230 координации может учитывать метрики путем применения правил 520 из БД 270 правил к метрикам 525 критериев. На основе сравнения, частично, по меньшей мере, одно публичное облако из облаков-кандидатов обозначается как целевое, как указано в блоке 760. Обычно целевая компьютерная сеть показывает метрики, которые удовлетворяют критериям 525.

Через некоторое время, как указано в блоке 770, инициируется взаимодействие с целевой компьютерной сетью. Это взаимодействие может предоставить учетную запись в целевом облаке, которое удовлетворяет запросу. При предоставлении учетной записи, механизм 230 координации может вернуть URL, API и/или маркер с регистрационными данными администратору 510, которые позволяют читать и записывать (т.е., доступ аутентификации) в учетную запись в целевом облаке без администратора 510, создавая механизм преобразования языка для взаимодействия с учетной записью. Таким образом, механизм 230 координации не обязательно указывает идентификационные данные целевого облака администратору 510. В процессе работы маркер представляет список IP или MAC адресов тех виртуальных машин в целевом облаке, которые выделены частному облаку 210, а также регистрационные данные, необходимые для доступа к виртуальным машинам. Используя маркер, у администратора есть возможность удаленно зайти на выделенные виртуальные машины и продолжить их настройку, запуская в работу экземпляры ролей и/или устанавливая дополнительные ресурсы. Кроме того, когда администратор 510 больше не использует виртуальные машины, выделенные в целевом облаке, маркер может быть использован для запроса отмены сервиса и прекращения начисления расходов на них.

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

Механизм 230 координации может оптимизировать для граничного сценария. Предположим, что поставщики услуг управляют рядом облаков-кандидатов X, Y и Z. Если определяется, что поставщик услуг, связанный с облаком-кандидатом X, является наилучшим в классе, когда дело доходит до граничного кеширования и отправки контента, то запрос от администратора 510 был бы направлен к облаку-кандидату X, а не облакам-кандидатам Y или Z. Как используется в материалах настоящей заявки, выражение "граничное кеширование" относится к поддержке контента вблизи основной группы пользователей (например, клиенты в Японии хотят, чтобы копии медиа располагались близко к Токио, в отличие от Лос-Анджелеса, чтобы они могли быть воспроизведены быстрее).

Механизм 230 координации может оптимизировать для ценового сценария. Предположим, что поставщик услуг облака-кандидата X взимает $1/ГБ, тогда как поставщики услуг, связанные с облаками-кандидатами Y и Z взимают $0,50/ГБ с такой же надежностью. По ценовому сценарию механизм 230 координации может направить запросы на память в облака-кандидаты Y или Z, вместо облака-кандидата X. Между тем, ценовой агент 260 на Фиг. 2 может работать как автоматический сервис, чтобы сохранять механизм 230 координации в актуальном состоянии относительно различных ценовых схем облаков-кандидатов X, Y и Z.

Кроме того, ценовой сценарий может запрограммировать поведение в правила 520, так что части частного облака 210 могут не использоваться, когда более рентабельно использовать облака-кандидаты Y и Z (например, публичные облака 250 на Фиг. 2). Таким образом, публичное облако(а) может использоваться для выделения пространства в частном облаке 210, чтобы реагировать на внезапное увеличение чувствительной информации, которая предназначена для хранения внутри. Таким образом, частное облако 210 рассматривается в качестве кандидата механизмом 230 координации так же, как и любое другое отслеживаемое облако.

Механизм 230 координации может оптимизировать для сценария резервного копирования. Предположим, что администратор 510 указывает в рамках правил 520, что организация делает ставку на надежное резервное копирование важных данных. Далее, правила 520 определяют, что данные должны быть сохранены избыточно на двух или более из облаков-кандидатов X, Y и Z, чтобы обеспечить максимальную гарантию от потери данных. В этом сценарии резервного копирования решение механизма 230 координации может быть оптимизировано для избыточности на множестве облаков.

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

Механизм 230 координации может оптимизировать для сценария торгового посредника. В случае, когда администратор 510 руководствуется бизнес-моделью, где продажи компании приходят, в частности, от размещения сторонних клиентов в частном облаке 210 в сочетании с другими публичными облаками. Обычно сторонний клиент компании не обеспокоен деталями того, где его/ее данные размещены, пока критерии 525 выполнены до определенного уровня безопасности и надежности. Поэтому, в сценарии торгового посредника компания может использовать механизм 230 координации, чтобы он действовал в качестве брокера и комбинировал другие публичные облака, при этом участвуя в ценовой конкуренции и отслеживая объем, чтобы создавать значительный доход. Как правило, компания такого типа лицензировала бы этот механизм 230 координации, чтобы помочь выполнять свой бизнес.

Способ для обеспечения взаимодействия между облаками

На Фиг. 6 показана структурная схема, которая иллюстрирует распределенную вычислительную среду 600, используемую для облечения взаимодействия между публичным и/или частным облаком(ами), в соответствии с вариантом осуществления настоящего изобретения. Как проиллюстрировано, вычислительная среда 600 включает в себя аспекты вычислительной среды 200 на Фиг. 2, где одинаковые ссылочные позиции представляют, по существу, аналогичные компоненты. Кроме того, вычислительная среда 600 будет обсуждена в контексте блок-схемы на Фиг. 8, где блок-схема показывает полный способ 800 для распределения нагрузки по одной или более публичным вычислительным сетям, внешним по отношению к частной корпоративной сети, в соответствии с вариантом осуществления настоящего изобретения.

Изначально, способ 800 включает в себя шаги, на которых принимают запрос 620, выданный пользователем 610 частной корпоративной сети, или частного облака 210, чтобы обновить учетную информацию, размещенную в публичной вычислительной сети(ях) (см. блок 810), и идентифицируют целевую сеть из публичной вычислительной сети(ей) 250, которая является ответственной за размещение учетной информации (см. блок 820). В примерах, как указано в блоке 830, одна или более команд могут быть извлечены из запроса 620. В качестве примера, команда(ы) представляет, частично, инструкции для выполнения обновления. Как показано в блоке 840, команды могут быть переведены в формат, совместимый с языком правил, соблюдаемым целевой сетью при взаимодействии с внешним источником. Кроме того, переведенные команды 630 могут быть распределены по вычислительным ресурсам, связанным с целевой сетью, которые предназначены для выполнения обновления учетной информации, как указано в блоке 850.

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

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

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

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

принимают в средстве координации критерии, связанные с этим запросом, причем критерии определяют предпочитаемые клиентом свойства для потенциально подходящих компьютерных сетей;

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

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

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

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

инициируют взаимодействие с этой по меньшей мере одной целевой компьютерной сетью.

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

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

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

5. Считываемый компьютером носитель по п. 1, в котором способ дополнительно содержит этапы, на которых:

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

сравнивают критерии предпочитаемых клиентом свойств с обновленными метриками данного множества потенциально подходящих компьютерных сетей; и

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

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

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

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

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

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

11. Считываемый компьютером носитель по п. 1, при этом упомянутый анализ дополнительно содержит:

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

применение правил, чтобы оказать влияние на результат упомянутого сравнения критериев с метриками.

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

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

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

извлекают одну или более команд из упомянутого запроса, причем эти одна или более команд представляют, отчасти, инструкции для выполнения упомянутого обновления;

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

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

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

14. Компьютерно-реализуемый способ по п. 12, в котором упомянутое динамическое предоставление целевых вычислительных сетей дополнительно содержит этапы, на которых:

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

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

(c) выбирают целевую вычислительную сеть в зависимости от анализа упомянутых метрик в свете упомянутых условий.

15. Компьютерно-реализуемый способ по п. 12, в котором оценивание средства координации содержит:

просмотр предыдущих решений средства координации; и

оценку влияния этих предыдущих решений.

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

хранилище данных правил, которое сохраняет предусмотренные администратором условия, связанные с частным облаком, причем эти условия представляют критерии, которые администратор считает значимыми для воплощения для внешней сети облачных вычислений;

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

один или более агентов, которые запрограммированы для периодического и динамического сбора свойств путем исследования упомянутых одного или более публичных облаков и для сообщения собранных свойств в хранилище данных метрик, причем эти один или более агентов созданы с параметрами касаемо того, как взаимодействовать с этими одним или более публичными облаками; и

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

17. Компьютерная система по п. 16, при этом частное облако представляет собой частную сеть облачных вычислений, эксплуатируемую администратором, причем целевое облако представляет собой по меньшей мере одну публичную сеть облачных вычислений, эксплуатируемую поставщиком облачных сервисов.

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

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

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