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

Иллюстрации

Показать все

Изобретение относится к средствам выбора и управления публичной сетью облачных вычислений для размещения учетной информации клиента. Технический результат заключается в автоматическом выборе публичного облака, которое удовлетворяет набору критериев, определенных администраторами, и обеспечении упрощенного взаимодействия с выбранным публичным облаком. Указанный результат обеспечивается выполнением способа распределения нагрузки по одной или более публичным вычислительным сетям, при этом: принимают выданный пользователем частной корпоративной сети запрос на обновление учетной информации; идентифицируют, с использованием средства координации, целевую вычислительную сеть из упомянутых одной или более публичных вычислительных сетей; переводят упомянутые одну или более команд в формат, совместимый с языком правил, соблюдаемым целевой вычислительной сетью при взаимодействии с внешним источником; и инициируют распределение этих одной или более переведенных команд по вычислительным ресурсам, связанным с целевой вычислительной сетью, которые предназначены для выполнения упомянутого обновления учетной информации. 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). Такие сетевые среды являются обычными в офисах, корпоративных компьютерных сетях, сетях интранет (локальных сетях, основанных на технологиях сети Интернет) и сети Интернет. Соотве