МЕЖ-ОБЛАЧНОЕ УПРАВЛЕНИЕ И УСТРАНЕНИЕ НЕПОЛАДОК

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

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

Облачные вычисления возникли как один из способов оптимизации традиционного центра данных. Облако определено как набор ресурсов (например, обработки, хранения, или прочих ресурсов), доступных посредством сети, который может выполнять, по меньшей мере, некоторые функции традиционного центра данных для предприятия. Облако часто включает в себя уровень абстракции так, что приложения и пользователи облака могут не знать: конкретного аппаратного обеспечения, на котором работают приложения; где расположено аппаратное обеспечение; и т.д. Это предоставляет оператору облака некоторую дополнительную свободу с точки зрения ввода и вывода ресурсов для услуги, обслуживания, и т.д. Облака могут включать в себя общедоступные облака, такие как MICROSOFT TM Azure, Amazon Web Services, и другие, как впрочем и частные облака, такие как те, что предоставляются Eucalyptus Systems, MICROSOFT TM и другими. Компании начали предлагать устройства (например, MICROSOFT TM Azure Appliance), которые предприятия могут разместить в их собственных центрах данных, для соединения центра данных с разными уровнями функциональных возможностей облака.

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

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

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

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

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

Фиг. 1 иллюстрирует приложение, работающее на двух облаках со связанной инфраструктурой управления, в одном варианте осуществления.

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

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

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

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

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

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

Фиг. 1 иллюстрирует приложение, работающее в двух облаках со связанной инфраструктурой управления, в одном варианте осуществления. В некоторых вариантах осуществления система облачного управления задействует приложение (и/или администратора), используя инфраструктуру в одном облаке, которое имеет данные/доступ к данным во всех местоположениях, чтобы иметь возможность полного наблюдения за устранением неполадок приложения. В качестве примера рассмотрим приложение с экземплярами, работающими в двух облаках, облаке 110 и облаке 150, как показано на Фиг. 1. Облако 110 включает в себя экземпляр 120 устройства Azure MICROSOFT TM, которое включает в себя инфраструктуру 130. Экземпляр 120 устройства включает в себя экземпляр 125 приложения, который выполняет роль 140 и роль 145. Второе облако 150 включает в себя экземпляр 155 приложения, который выполняет роль 160 и роль 170. Второе облако 150 также включает в себя инфраструктуру 180. Экземпляр 120 устройства знает о каждой роли и то, что они являются частью одного и того же приложения. Инфраструктура, развернутая в каждом местоположении, позволяет экземпляру 120 устройства извлекать информацию о роле 160 и роле 170, выполняемой во втором облаке 150. Система может распределять либо отдельные роли, либо целые приложения, либо и то и другое. С помощью всех данных управления (например, журналов регистрации от приложений, машин, и инфраструктуры), система может получить доступ к работоспособности приложения, как если бы все роли были бы локальными, посредством применения предварительно определенных правил работоспособности. Система также может видеть работоспособность инфраструктуры в обоих местоположениях, как впрочем, и соединения между ними, для оценки того, возникла ли проблема с приложением или инфраструктурой/сетью.

Аналогичным образом, когда требуются этапы автоматического или ручного устранения неполадок или исправления, то инфраструктура 130 в облаке 110 может осуществлять координацию с инфраструктурой 180 в облаке 150 для обеспечения поддержки устранения неполадок и отладки. Например, структура системы может дотягиваться до местоположений для исполнения обширного обновления приложения, завершения и т.п. Специалистам в соответствующей области будут очевидны различные способы выполнения управления между местоположениями. Например, инфраструктура 130 может непосредственно управлять инфраструктурой 180, инфраструктура 130 может запросить инфраструктуру 180 исполнение от имени инфраструктуры 130, и т.д. Подобным образом, с помощью инструментов устранения неполадок оператора/администратора (например, визуализации наблюдения, предупреждения, просмотра данных журнала регистрации и конфигурации, и т.п.), доступно и логически отображается местоположение приложений и инфраструктура, а не задействуются отдельные инструменты и умственная гимнастика со стороны администратора для объединения всего вместе. Например, при устранении неполадок и просмотре данных по всем ролям, если следующим этапом администратора 105 является использование одного или более инструментов 195 для просмотра журналов регистрации приложения или запуска удаленного сеанса в отношении экземпляра роли, то система осуществляет непосредственное соединение администратора 105, независимо от того, в каком местоположении находится роль.

Исполнение системы облачного управления обеспечивает упрощенную и последовательную работу услуги на нескольких облаках/местоположениях. Система перемещает определение «вычислительного ресурса» с сервера, за пределы центра данных в часть сети интернет (центры данных и соединение между ними). Это предоставляет возможность осуществления определения, наблюдения, и управления соглашениями об уровне услуг (SLA) на уровне услуги - т.е. того, о чем больше всего заботятся владельцы услуги.

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

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

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

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

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

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

В другом примере поставщик облачных услуг принимает решение о передаче из одного кластера в другой. Команда планирования мощности общедоступного облака принимает решение о том, что кластер в центре данных в Чикаго критически заполнен, но хотят сохранить высокую загрузку. Они настраивают передачу в недогруженный кластер в центр данных Западного Побережья, когда загрузка достигает 90%. Администратор переходит в инструмент управления мощностью и выбирает соответствующих потребителей/приложения (например, с низким использованием данных), в качестве кандидатов на перемещение. Наступает день, когда использование кластера в Чикаго достигает порогового значения и система автоматически перемещает выбранные приложения (например, 10% кластерных приложений) в центр данных Западного Побережья на один день. Как только использование возвращается к уровню ниже порогового значения, система перемещает приложения обратно в Чикаго. Система упреждающе уведомляет назначенную команду наблюдения о возможности передачи, чтобы ответить на вопросы потребителей.

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

В другом примере предприятие настраивает глобально распределенное приложение с динамической балансировкой нагрузки. Потребитель предприятия хочет управлять мощностью между двумя или более экземплярами облака и имеет значительный объем своей нагрузки на независимых, но географически разнесенных экземплярах (например, поиск Bing с помощью центра данных в США и Великобритании, при этом оба обслуживают запросы из Германии). В нормальных обстоятельствах, средство глобального управления трафиком отправляет 50% трафика в каждое местоположение. Когда нагрузка становится высокой в основном местоположении, система выдает инструкцию средству балансировки нагрузки на отправку 75% трафика в систему Великобритании, тем самым высвобождая мощности экземпляра облака в США, приводя мощность к приемлемым уровням. Когда мощность возвращается к нормальному состоянию, система сообщает средству балансировки нагрузки вернуться к разбиению 50/50. Вариацией этого является использование общедоступного облака в качестве вспомогательного центра данных (скажем с 1% нагрузки, при этом на сайт потребителя с устройством возлагается 99%). В случае аварии или по другой причине перемещения нагрузки с сайта потребителя, 100% трафика смещается на общедоступное облако.

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

Фиг. 2 является структурной схемой, которая иллюстрирует компоненты системы облачного управления, в одном варианте осуществления. Система 200 включает в себя компонент 210 управления местоположением, хранилище 220 данных местоположения, компонент 230 интерфейса инструмента, один или более инструментов 240 управления, компонент 250 миграции данных, компонент 260 устранения неполадок, и компонент 270 тарификации и учета. Каждый из этих компонентов более подробно описывается далее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В некоторых вариантах осуществления система облачного управления предоставляет различные опции для восстановления в аварийных случаях. В некоторых случаях система может привлечь ресурсы на внешнем центре данных для наблюдения за основным центром данных в отношении перебоев. Если внешний центр данных становится не в состоянии достичь основного центра данных, тогда внешний центр данных может определить, что произошла авария, и переместить нагрузки приложения на внешний центр данных. В прошлых системах типичным для организации было содержание 200% требуемой мощности (при существенных затратах), чтобы успешно справляться с авариями. С помощью системы облачного управления организация может содержать меньший объем доступной мощности во втором местоположении (например, 10%) и может быстро запросить больше, как требуется, в случае отказа. Подобно страхованию, вероятность того, что все клиенты поставщика облачных услуг одновременно испытают отказ и запросят запасы большой мощности, низка, так что несколько клиентов могут совместно использовать набор избыточных вспомогательных ресурсов, которые будут использованы при отказе основных ресурсов. Система также может переориентировать инструменты управления и ресурсы устранения неполадок, чтобы они указывали на новое местоположение, вслед за восстановлением в аварийных ситуациях, таким образом, чтобы управление не прерывалось.

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