Результат интеллектуальной деятельности: ДИНАМИЧЕСКОЕ ПРЕОБРАЗОВАНИЕ ИНТЕРФЕЙСА КОМАНДНОЙ СТРОКИ (CLI) ДЛЯ СГРУППИРОВАННЫХ ОБЪЕКТОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Представленное изобретение в целом относится к системам высокой готовности (аппаратным и программным) и конкретнее к управлению платформой, связанной с подобными системами высокой готовности.

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

Системы высокой готовности (известные также как НА системы) являются системами, которые предназначены, прежде всего, для повышения готовности служб, которые обеспечивают системы. Готовность может выражаться как процент от времени, в течение которого, система или служба может быть готова. Например, система, рассчитанная для 99,999 процентам готовности (также называемая готовностью с «пятью девятками»), относится к системе или службе, которая имеет время простоя только около 0,44 минуты/месяц или 5,26 минуты/год.

Системы высокой готовности обеспечивают соответствующий уровень готовности, прибегая к избыточным узлам, которые используются при обеспечении обслуживания, когда элементы системы выходят из строя. Например, если сервер, выполняющий конкретное приложение, терпит сбой, НА система будет выявлять сбой и перезапускать приложение на другом избыточном узле. Различные избыточные модели могут использоваться в НА системах. Например, N+1 модель избыточности обеспечивает единственный дополнительный узел (связанный со многими первичными узлами), который доставляется через сеть, чтобы взять на себя роль узла, который вышел из строя. Однако в ситуациях, где единственная НА система управляет множеством служб, единственный специализированный узел для обработки сбоев может не обеспечить достаточной избыточности. В таких ситуациях может использоваться, например, N+M модель избыточности, при этом более чем один (М) резервный узел подключены и доступны.

Т.к. НА системы становятся более обычными при поддержке важных служб, таких как совместное использование файлов, Интернет-порталов клиента, базы данных и т.п., стало желательным обеспечить стандартизованные модели и методологии для разработки подобных систем. Например, Service Availability Forum (SAF) стандартизовал службы применения интерфейса (AIS), чтобы помочь развитию портативных приложений высокой готовности. Как показано в схематичном архитектурном блоке Фиг.1, AIS 10 предназначен для обеспечения стандартизованного интерфейса между НА-приложениями 14 и НА-микропрограммным обеспечением 16, таким образом делая их независимыми друг от друга. Как описано ниже, каждый набор функциональных возможностей AIS связан с операционной системой 20 и базовой аппаратной платформой 22. Читатель, заинтересовавшийся дополнительной информацией относительно технических требований стандарта AIS, отсылается к Application Interface Specifications (AIS) версии В.02.01, которая доступна на сайте www.saforum.org, раскрытие которого включено через представленную здесь справочную информацию.

Особый интерес для настоящей заявки представляет инфраструктура управления готовностью (Availability Management Framework (AMF)), которая является объектом программного обеспечения, определенным в пределах технических требований AIS. Согласно техническим требованиям AIS AMF является стандартизованным механизмом для обеспечения пригодности службы при координировании избыточных ресурсов в пределах кластера, чтобы предоставить систему без единого пункта отказа. AMF обеспечивает ряд приложений программных интерфейсов (API), которые определяют, среди прочего, состояние компонентов в пределах кластера, и степень исправности этих компонентов. Компоненты также снабжены возможностью опрашивать AMF для информирования об их состоянии. Приложение, которое разработано, используя AMF API и последующую AMF системную модель, возлагает обязательство по управлению пригодностью его служб на AMF. Таким образом, такое приложение не должно иметь дело с динамической реконфигурацией проблем, связанных с компонентным отказом, эксплуатацией и т.д.

Как определялось в предыдущих стандартах, каждый объект программного обеспечения обеспечивает поддержку пригодности единственного логического кластера, который состоит из множества кластерных узлов и компонентов, пример которого показан на Фиг.2. Здесь, первый кластер А включает в себя свой собственный AMF 24, два узла 26, 28 и четыре компонента AMF 30-36. Точно так же второй кластер В имеет свой собственный AMF 38, два узла 40, 42 AMF и четыре компонента 44-50 AMF. Компоненты 30-36 и 44-50 каждый представляют собой ряд ресурсов аппаратных средств и программного обеспечения, которыми управляют AMF 24 и 38, соответственно. В физическом смысле компоненты понимаются как процессы НА-приложения. Узлы 26, 28, 40, 42 каждый, представляют логический объект, который соответствует физическому узлу, на котором соответствующие процессы управляются как запущенными AMF компонентами, так и элементами избыточности, распределенными для управления этими доступными узлами.

Стандарт AIS также определяет модуль обслуживания (SU) как логический объект, который объединяет набор компонентов, комбинируя их индивидуальные возможности таким образом, чтобы обеспечить более высокий уровень обслуживания. Модуль обслуживания может содержать любое число компонентов, но специфический компонент может быть скомпонован только в одном модуле обслуживания. Поскольку каждый компонент заключается в модуле обслуживания, из перспективы AMF, модуль обслуживания можно считать модулем возрастания избыточности в том смысле, что он является наименьшим логическим объектом, который может быть реализован способом резервирования, т.е. более чем одним. Другой пример AMF-модели, включающей в себя модуль обслуживания и компоненты, предоставлен ниже на Фиг.3.

На страницах этой модели каждый компонент 30-36 и 44-50 имеет атрибут, который определяет расположение соответствующей инсталляции программного обеспечения. Более определенно этот атрибут определяет префикс пути, который используется, когда реализуется соответствующий модуль обслуживания. Однако этот префикс пути предполагает, что компонент всегда реализуется на том же узле или что компонент реализован на узле, где существует инсталляция программного обеспечения, расположенная по тому же пути. В типичных кластерах эта последняя характеристика, как правило, верна, т.е. путь инсталляции всегда тот же на всех узлах. Если, все же, это допущение не обязательно верно, например в разнородных кластерах, где отдельные кластеры могут быть бездисковыми (например, использующие RAM-диск), в то время как другие узлы могут использовать вмонтированные диски или иметь локальные диски (или если узлы запускают различные операционные системы), в этом случае инсталляция будет давать сбой.

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

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

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

Согласно другому иллюстративному варианту осуществления логический узел инфраструктуры управления готовностью (Availability Management Framework (AMF)), используемый для реализации компонента на удаленном узле, AMF-логический узел включает в себя модуль поиска, который: принимает идентификатор типа компонента, который будет реализован на локальном узле, определяет по идентификатору типа, идентификатор программного обеспечения, который соответствует компоненту, определяет множество удаленных узлов, на которых инсталлировано программное обеспечение, соответствующее идентификатору программного обеспечения, определяет удаленный узел из множества удаленных узлов, на котором компонент должен быть реализован, и получает местоположение особого инсталлированного программного обеспечения на удаленном узле, используя тип компонента и идентификатор программного обеспечения.

В соответствии с еще одним иллюстративным вариантом осуществления способ для выполнения команды линейного интерфейса (Command Line Interface (CLI)) для компонента, связанного с Availability Management Framework (AMF) узлом, включает в себя этапы: поиск типа, связанного с вышеупомянутым компонентом, идентификация программного обеспечения, связанного с компонентом на основе типа, поиск префикса имени маршрута для идентифицированного программного обеспечения и использование префикса имени маршрута для выполнения CLI команды.

В соответствии с, опять же, другим иллюстративным вариантом осуществления способ для преобразования компонента в Availability Management Framework (AMF) узел включает в себя этапы: определение типа компонента, определение идентификатора программного обеспечения для программного обеспечения, связанного с компонентом, основанного на определенном типе, выбор AMF-узла, на котором компонент должен быть преобразован и определение инсталлированного местоположения конкретного узла для программного обеспечения на AMF-узле по атрибуту AMF, используя определенный тип и определенный идентификатор программного обеспечения.

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

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

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

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

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

Фигура 2 иллюстрирует кластерную архитектуру интегрированной системы управления готовностью (AMF).

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

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

Фигура 5 - это блок-схема, иллюстрирующая способ выполнения команды линейного интерфейса (Command Line Interface (CLI)) для компонента, связанного с узлом AMF, в соответствии с иллюстративным вариантом осуществления.

Фигура 6 - это иллюстрация узла/части системы в соответствии с иллюстративным вариантом осуществления и

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

Подробное описание

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

Чтобы обеспечить некоторый дополнительный смысл для этого обсуждения, рассматривают другую типичную AMF-управляемую систему, как показано на Фигуре 3. В ней четыре узла (A,B,C и D) связаны с двумя группами обслуживания (SG1 и SG2). Группа обслуживания - это группа модулей обслуживания (SU), которые обеспечивают готовность обслуживания для одного или более требований особенного обслуживания. Например, SG1 включает в себя и SU2, которые в этом примере, поддерживают требование службы электронной почты (аппаратного и программного обеспечения) и SG2 включает в себя SU3, SU4 и SU5, которые поддерживают два требования службы факса (аппаратного и программного обеспечения). Для требования службы электронной почты поддерживаемой SG1, SU1 присваивается активное состояние, а SU2 - состояние ненагруженного резерва.

Каждый из типичных модулей обслуживания в SG1 имеет два компонента, к тому же связанных. Компонент - это наименьший логический объект, на котором AMF 300 выполняет обнаружение ошибки и изоляцию, восстановление и ремонт. Таким образом, компонент, как правило, включает в себя все функции, которые не могут быть четко разделены для локализации ошибки или целей изоляции. Эти компоненты могут далее быть сгруппированы в группы защиты, которые отражают избыточность, связанную с обеспечением готовности почтовой службы. Например, компонент С1 или С3 могут сформировать первую группу защиты, а компонент С2 и С4 могут сформировать вторую группу защиты, связанную с требованием почтовой службы. Таким образом, и точно так же если компонент С2 выходит из строя, далее AMF 300 мог бы переключить компонент С4 в активное состояние.

Группа SG2 обслуживания иллюстрирует слегка отличную конфигурацию, в которой два требования из факсимильной службы поддерживаются тремя модулями службы SU3, SU4 и SU5. Например, SU3 и SU4, каждый мог бы назначить активное состояние так, что каждый поддерживает одно требование факсимильной службы, в то время как SU5 мог бы назначить состояние ненагруженного резерва и работать как избыточное резервное оборудование. В этом случае компоненты С5 и С7 сформировали бы одну группу защиты, связанную с одним или двумя требованиями факсимильной службы и компоненты С6 и С7 могли бы сформировать вторую группу защиты, связанную с другим из двух требований факсимильной службы. Объект программного обеспечения AMF 300 может работать, как описано в вышеупомянутой ссылке на AIS стандарт, за исключением того, что жизненный цикл компонента регулируется, например, реализацией, и взаимосвязанные функции будут выполнены, как описано ниже.

Как упоминалось выше, иллюстративные варианты осуществления обращаются к ситуации, где AMF-объект реализует новый служебный модуль и связанный компонент(ы) (или выполняет другие задачи жизненного цикла). В контексте примера Фигуры 3 предполагают, что компонент С6 связан со сбоями служебного модуля SU4. В этом случае, когда зарегистрировано состояние отказа, AMF 300 мог бы переключить SU5 из его состояния ненагруженного резерва в активное состояние, чтобы сохранить готовность второго варианта факсимильной службы. Однако AMF 300 мог бы также решить реализовать новый служебный модуль и связанный компонент со всем необходимым программным обеспечением, чтобы выполнить резервную роль, освобожденную SU5. Например, как показано на Фигуре 4, AMF 300 мог бы решить закончить SU4/C6 и реализовать SU6/C8, чтобы допустить новую резервную роль для второго варианта факсимильной службы. Чтобы выполнить эту реализацию, вместо предположения, что имя пути, связанное с необходимым программным обеспечением, будет всегда одинаковым для компонента, который выполняет эту особую факсимильную службу в соответствии с этими типичными реализациями, AMF 300 может получать эту информацию о пути (а также дополнительно другую информацию относительно команд жизненного цикла компонента) от одного из узлов, на котором этот конкретный тип компонента запущен, как описано ниже.

Например, каждый компонент, к примеру С1-С7, будет иметь тип компонента, ассоциированный с ним как атрибут, который может быть считан или отыскан AMF 300. Тип компонента будет, в свою очередь, относиться к идентификатору программного обеспечения, который идентифицирует программное обеспечение, необходимое для того, чтобы запустить функциональные особенности компонента, т.е. ту часть службы, которая его поддерживает в пределах собственного назначенного модуля обслуживания. Кроме того, каждый AMF узел, например узлы A-D на Фигурах 3 и 4, будет иметь атрибут, связанный с тем, который указывает, какие пакеты программного обеспечения там инсталлированы. Эти атрибуты и идентификаторы могут быть сохранены как объекты, например, в базе данных (не показана), например SAF-службой, называемой Службой Управления Информационной Моделью (IMM). AMF 300 может затем получить прежде описанную информацию от соответствующих объектов, сохраненных внутри IMM. Различные системы могут реализовывать IMM-базу данных различными путями, однако AMF 300 будет обеспечен интерфейсом, через который он сможет восстановить сохраненную информацию атрибута/идентификатора согласно этим иллюстративным вариантам реализации. С другой стороны AMF реализация может иметь свою собственную копию этой информации. Также может быть обеспечена в пределах системы информационная база управления (MIB), основанная на этой информации модель SNMP-доступа, чтобы считывать и устанавливать эти данные конфигурации. Независимо от особенности способа, которым эта информация сохранена и восстановлена, AMF 300 будет использовать эту информацию для, например, создания новой комбинации модуля/компонента сервиса SU6/C8 на Фигуре 4 в соответствии с иллюстративным вариантом осуществления, проиллюстрированного на блок-схеме Фигуры 5.

Там, на этапе 500 AMF 300 ищет тип, связанный с компонентом, например с компонентом С6 в примере Фигуры 3 и 4. Показатель типа, обеспечивает, в свою очередь, показатель идентификатора программного обеспечения, который позволяет AMF 300 идентифицировать программное обеспечение, связанное с компонентом С6 на этапе 502. Вместе с идентификатором программного обеспечения AMF 300 может затем отыскать префикс имени маршрута для AMF-узла, который был выбран для реализации SU6/C8, например, AMF-узла А в примере на Фигуре 3 и 4, на этапе 504. Существуют различные пути, в которых отдельный AMF-узел может быть отобран из числа доступных узлов для реализации SU6/C8. Например, модуль обслуживания или доступные атрибуты группы обслуживания, например из IMM, могут указать группу узла, на которой отдельный SU или SU группы обслуживания может быть реализован. AMF 300 может выбирать из итогового списка AMF-узлов, если такая информация доступна, например, основанной на порядке, в котором узлы указаны. Иначе, AMF 300 может выбрать любой узел в кластере, например, на основе загрузки, на которой реализовывать обслуживание модуля/компонента(ов). Префикс имени маршрута является AMF особым узловым и особым программным префиксом, который, когда сцеплен через команду с относительным именем маршрута, связанного с типом компонента, определяет имя маршрута для CLI команды. Это сцепление является одним примером того, как префикс имени маршрута, который был получен при помощи AMF 300, может использоваться на этапе 506 для выполнения CLI команды, например как команды для реализации новой службы модуля/компонента. Отметим, что хотя эти иллюстративные варианты выполнения сосредоточены на реализации и соответствующих CLI командах, они не накладывают ограничений на это. Вместо этого эти иллюстративные варианты выполнения также могут использоваться для способствования другим CLI командам, связанным с жизненным циклом компонента, такого как те, что связаны с завершением, очисткой, АМ_началом и АМ_остановкой. Завершение команды используется для остановки компонента и этим служба обеспечивается компонентом и оставляет этот компонент нереализованным. Команда очистки также оставляет компонент нереализованным и используется, когда AMF 300 восстанавливается от ошибок. Команда АМ_начало может выполняться AMF 300 после того, как компонент был успешно реализован, или чтобы возобновить мониторинг компонента для периодической оценки состояния компонента. Команда АМ_остановка может быть выполнена AMF 300, чтобы остановить мониторинг отдельного компонента.

В отношении Фигуры 6 системы и способы обработки данных в соответствии с иллюстративным вариантом осуществления настоящего изобретения могут быть выполнены одним или более процессорами 600, например частью сервера 601, выполняющего последовательность инструкций, содержащихся в устройстве 602 памяти. Такие инструкции могу быть считаны в устройство 602 памяти из других машиночитаемых сред, таких как вторичное устройство(а) 604 хранения данных. Выполнение последовательности инструкций, помещенных в устройство 602 памяти, заставляет процессор 600 работать, например, как описано выше. В альтернативном варианте осуществления аппаратно-проводная схема может использоваться вместо или в комбинации с инструкциями программного обеспечения, чтобы реализовать настоящее изобретение.

Независимо от особенностей способа, в котором эти иллюстративные варианты осуществления выполнены, будет цениться то, что объект программного обеспечения AMF в соответствии с этими иллюстративными вариантами осуществления может включать в себя поисковый модуль программного обеспечения, который хранится в машиночитаемой среде и содержит инструкции, которые, когда выполняются на компьютере или процессоре, содержат этапы, проиллюстрированные на блок-схеме Фигуры 7. Там, на этапе 700, модуль поиска принимает идентификатор типа компонента, для его реализации на локальном узле. Затем, на этапе 702, модуль поиска определяет по идентификатору типа, идентификатор программного обеспечения, который соответствует реализуемому компоненту. На этапе 704 модуль поиска определяет множество удаленных узлов, на которых инсталлировано программное обеспечение, соответствующее идентификатору программного обеспечения, и затем, на этапе 706, определяет удаленный узел из множества удаленных узлов, на котором должен быть реализован компонент. Местоположение инсталлированного специального программного обеспечения на удаленном узле получается на этапе 708, используя тип компонента и идентификатор программного обеспечения.

Согласно иллюстративному варианту осуществления атрибут, связанный с каждым AMF узлом, который показывает программное обеспечение, инсталлированное на нем и собственное местоположение, может быть обновлен, вместе с новой информацией программного обеспечения, например, когда программное обеспечение инсталлируется на узел. Таким образом, объект программного обеспечения AMF будет иметь доступ к новейшей информации, когда он стремится отобразить CLI-команду на любом из узлов, которыми управляет. Кроме того, так как AMF узлы являются самостоятельными логическими объектами, которые могут быть потенциально преобразованы на различных физических узлах (например, Cluster Membership (CLM) узлах), подобное CLI преобразование, как описано выше, может быть выполнено рекурсивно, на различных уровнях модели системы. Значит, это преобразование может быть выполнено, когда CLM узел преобразован на первоначальной операционной системе и когда AMF узел преобразован на CLM узле. Принимая во внимание вышесказанное, рассмотрим следующий пример. Предположим, что узел нового аппаратного средства добавлен на AMF-управляемую НА-систему. Эта система может, например, распоряжаться двумя кластерными узлами и AMF узлом на каждом. Таким образом, на AMF-уровне добавляются два узла (или, если они принадлежат различным кластерам AMF, один узел для каждого кластера). Однако в этой иллюстративной системе существует только один физический узел с диском, который может предназначаться полностью одному из кластерных узлов или распределяться между двумя и т.д. Каждая различная конфигурация может означать различное преобразование программного обеспечения AMF-узла на физическую память диска. Если узлы принадлежат различным кластерам, в этом случае требование на изоляцию изображений программного обеспечения может быть значительно более строгим и, таким образом, могло бы быть два различных изображения. Когда AMF-узел реализован таким же образом, что касается компонентов, описанных выше, когда они реализованы на другом узле, может быть обеспечено преобразование, чтобы в соответствии с этими иллюстративными вариантами осуществления допустить поиск программного обеспечения, которое должно быть доступным на узле AMF и сконфигурировано на уровне узла AMF.

Динамическое преобразование CLI может также выполняться по отношению к более высоким слоям управляемой системы. Например, контейнерные компоненты, которые могут использоваться в AMF-управляемых системах, чтобы объединить компоненты (Java, C++ и т.д.), которые не выполняются непосредственно операционной системой, могут также извлекать выгоду из ранее описанных методик. Таким образом, если контейнерный компонент, который управляет жизненным циклом некоторых имеющихся компонентов, располагается на узле, тогда такой контейнер может выполнить преобразование, описанное выше для AMF для CLI-команд, когда контейнеру нужно получить информацию о маршруте от (или отовсюду) отдельного узла.

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