Стойка с функцией автоматического восстановления и способ автоматического восстановления для этой стойки

Группа изобретений относится к стойке с функцией автоматического восстановления. Технический результат – обеспечение перезагрузки контроллера управления материнской платой (BMC) для восстановления исходного состояния при отсутствии нормального взаимодействия контроллера управления стойкой (RMC) в стойке с BMC в узле стойки. Для этого стойка содержит модуль управления и множество узлов. Модуль управления содержит контроллер управления стойкой (RMC), а каждый из множества узлов содержит контроллер управления материнской платой (BMC). RMC взаимодействует с BMC через множество стандартных каналов связи соответственно, при этом RMC управляет узлами и передает необходимые им данные через BMC. При потере сигнала отклика от одного из BMC RMC повторно отправляет такой же сигнал неответившему BMC. Если достигнуто пороговое значение повторной отправки, то RMC отправляет управляющий сигнал на вывод сброса неответившего BMC непосредственно по каналу GPIO, чтобы заставить неответивший BMC перезагрузиться. 2 н. и 6 з.п. ф-лы, 4 ил.

 

Предпосылки создания изобретения

Область техники, к которой относится изобретение

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

Описание предшествующего уровня техники

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

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

В предшествующем уровне техники RMC в основном взаимодействует с BMC по каналам связи, таким как интеллектуальная шина управления платформой (IPMB), последовательная шина данных для связи интегральных схем (I²C) или локальная вычислительная сеть (LAN), а также использует каналы связи для передачи команд управления, информации и файлов.

Однако каждый канал связи, упомянутый выше, является двунаправленным. Более детально, если RMC необходимо взаимодействовать с заданным BMC, то RMC необходимо предварительно отправить начальный сигнал "ЗАПРОС" заданному BMC. После получения сигнала "ОТКЛИК" от заданного BMC RMC может удостовериться, что канал связи функционирует, а затем передавать реальные данные заданному BMC. Другими словами, если заданный BMC сам по себе или интерфейс связи BMC имеет неисправность (например, сбой внутреннего программного обеспечения или ошибку аппаратного сигнала), то заданный BMC не может ответить на сигнал "ЗАПРОС" от RMC, RMC не может успешно связаться с заданным BMC.

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

Если оператор получает вышеупомянутый сигнал об ошибке, то он или она выполняет перезагрузку BMC вручную (например, путем извлечения сервера из стойки (для прерывания питания BMC), а затем вставки сервера в стойку снова (для перезагрузки BMC).

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

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

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

Сущность изобретения

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

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

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

Краткое описание графических материалов

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

На фиг. 2 представлена коммутационная схема согласно первому варианту осуществления настоящего изобретения.

На фиг. 3 представлена коммутационная схема согласно второму варианту осуществления настоящего изобретения.

На фиг. 4 представлена блок-схема алгоритма перезагрузки согласно первому варианту осуществления настоящего изобретения.

Подробное описание изобретения

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

На фиг. 1 представлена коммутационная схема стойки согласно первому варианту осуществления настоящего изобретения. В настоящем изобретении предложена стойка 1, которая имеет функцию автоматического восстановления, подробно описанную ниже. В частности, стойка 1 содержит модуль 2 управления и множество узлов 3, причем модуль 2 управления содержит, по меньшей мере, печатную плату 21 и контроллер 22 управления стойкой (RMC), электрически соединенный с печатной платой 21, причем каждый из множества узлов 3 соответственно содержит материнскую плату 31 и контроллер 32 управления материнской платой (BMC), электрически соединенный с материнской платой 31. Функция автоматического восстановления в настоящем изобретении является, например, операцией перезагрузки, выполняемой для восстановления множества BMC 32 в узлах 3 в исходное состояние, не имеющее ошибок связи.

Модуль 2 управления и узлы 3 расположены соответственно в стойке 1, причем модуль 2 управления электрически соединен с каждым узлом 3. В результате RMC 22 в модуле 2 управления может взаимодействовать с каждым BMC 32 в каждом узле 3 и может управлять всеми узлами 3, собирать информацию из узлов 3 и передавать необходимые файлы (например, файл обновлений для обновления встроенного программного обеспечения) в узлы 3 посредством множества BMC 32.

На фиг. 2 представлена коммутационная схема согласно первому варианту осуществления настоящего изобретения. Как показано на фиг. 2, RMC 22 в модуле 2 управления соединен с BMC 32 в узлах 3 соответственно через множество стандартных каналов 4 связи. В этом варианте осуществления стандартные каналы 4 связи осуществлены с помощью интеллектуальной шины управления платформой (IPMB), последовательной шины данных для связи интегральных схем I²C, универсального асинхронного приемника/передатчика (UART) или локальной вычислительной сети (LAN), но не ограничены ими. RMC 22 взаимодействует с множеством BMC 32 через множество стандартных каналов 4 связи соответственно и передает файлы, необходимые узлам 3 в множество BMC 32 через множество стандартных каналов 4 связи, таким образом, BMC 32 могут контролируемо использовать файлы.

Например, каждый из множества узлов 3 соответственно содержит запоминающее устройство 33, электрически соединенное с BMC 32. Каждое запоминающее устройство 33 хранит базовую систему ввода/вывода (BIOS), необходимую узлу 3, в котором расположено запоминающее устройство 33. Когда BIOS узлов 3 нуждается в обновлении, RMC 22 принимает извне файл обновления (например, "*.ISO"-файл), и передает файл обновления на множество BMC 32 по стандартным каналам 4 связи соответственно. Таким образом, множество BMC 32 использует полученный файл обновления для обновления BIOS в запоминающих устройствах 33 соответственно.

Перед передачей файлов на множество BMC 32 для завершения упомянутых выше действий по обновлению RMC 22 необходимо заранее отправить сигнал "ЗАПРОС" на множество BMC 32 по стандартным каналам 4 связи соответственно. После приема сигнала "ОТКЛИК", соответствующего сигналу "ЗАПРОС", от множества BMC 32 соответственно RMC 22 определяет, что множество BMC 32 и стандартные каналы 4 связи функционируют в нормальном режиме. Таким образом, RMC 22 может передавать файлы, необходимые узлам 3, в множество BMC 32 по стандартному каналу 4 связи соответственно.

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

На фиг. 3 представлена коммутационная схема согласно второму варианту осуществления настоящего изобретения. На фиг. 3 изображен один из множества BMC 32 в стойке 1 в качестве примера, который не предназначен для ограничения объема настоящего изобретения.

Основной технической характеристикой стойки 1 в настоящем изобретении является то, что RMC 22 электрически соединен с печатной платой 21, BMC 32 электрически соединен с материнской платой 31 и, по меньшей мере один управляющий вывод (не показан) RMC 22 электрически соединен с выводом 321 сброса BMC 32 непосредственно через печатную плату 21 и материнскую плату 32. Более конкретно RMC 22 в этом варианте осуществления электрически соединен с выводом 321 сброса BMC 32 непосредственно по интерфейсу ввода/вывода общего назначения (GPIO), устанавливая, таким образом, канал 5 GPIO с BMC 32.

С помощью технического решения, описанного в настоящем изобретении, BMC 32 считается неответившим BMC 32, если RMC 22 отправляет сигнал "ЗАПРОС" BMC 32 и не получает сигнал "ОТКЛИК", соответствующий сигналу "ЗАПРОС", от BMC 32 после определенного времени ожидания. RMC 22 повторно отправляет такой же сигнал "ЗАПРОС" неответившему BMC 32. Если время повторной отправки сигнала "ЗАПРОС" больше, чем пороговое значение повторной отправки, то RMC 22 определяет, что неответивший BMC 32 работает со сбоями (т.е. неответивший BMC 32 считается проблемным BMC 32).

В этом варианте осуществления при определении, что неответивший BMC 32 является проблемным BMC 32, RMC 22 управляет проблемным BMC 32 по каналу 5 GPIO. В частности, RMC 22 передает управляющий сигнал (через управляющий вывод) на вывод 321 сброса в проблемный BMC 32 непосредственно по каналу 5 GPIO, чтобы заставить проблемный BMC 32 перезагрузиться.

Например, RMC 22 настроен так, чтобы выводить сигнал низкого потенциала ("0") или не выводить никакой сигнал посредством управляющего вывода в нормальном режиме работы, а когда вышеописанная проблема возникает, то RMC 22 переходит на вывод сигнала высокого потенциала ("1"). Если проблемный BMC 32 получает сигнал высокого потенциала на вывод 321 сброса, он вынужден перезагрузиться. Однако приведенное выше описание является лишь предпочтительным вариантом осуществления, но не ограничивается им.

Как уже упоминалось выше, независимо от того, какая проблема имеется у BMC 32 и является причиной сбоя RMC 22 при взаимодействии с BMC 32 по стандартному каналу 4 связи, RMC 22 всегда может заставить по каналу 5 GPIO перезагрузиться BMC 32, таким образом, восстановить исходное состояние BMC 32. Кроме того, RMC 22 может снова установить соединение с BMC 32 по стандартному каналу 4 связи после того как исходное состояние BMC 32 восстановлено, а затем взаимодействовать с восстановленным BMC 32 и передавать ему данные. При этом нет необходимости ждать оператора, который устранит вышеупомянутую проблему вручную, когда RMC 22 не может взаимодействовать с BMC 32 в нормальном режиме.

В других вариантах осуществления изобретения RMC 22 может прервать питание, подаваемое на BMC 32, а затем восстановить по каналу 5 GPIO питание BMC 32 или прервать питание, подаваемое на узел 3, в котором расположен BMC 32, а затем восстановить питание узла 3 с целью вызвать перезагрузку BMC 32.

В частности, стойка 1 в этом варианте осуществления содержит одну или несколько микросхем управления питанием (не показана), причем микросхема управления питанием электрически соединена с множеством узлов 3 и источником питания стойки 1. В этом варианте осуществления RMC 22 соединяется с микросхемой управления питанием по каналу 5 GPIO. Когда RMC 22 не может взаимодействовать с BMC 32 по стандартному каналу 4 связи, он может отправить команду сброса на микросхему управления питанием по каналу 5 GPIO. Микросхема управления питанием прерывает питание, подаваемое на узел 3 (или на BMC 32) в соответствии с содержанием команды сброса, а затем немедленно возвращает питание узла 3 (или BMC 32). Таким образом, BMC 32 может быть перезагружен и может восстановить исходное состояние после того как перезагрузка завершится.

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

На фиг.4 представлена блок-схема алгоритма перезагрузки согласно первому варианту осуществления настоящего изобретения. Как показано на фиг. 4, перед тем как RMC 22 требуется взаимодействие с BMC 32, он, во-первых, отправляет сигнал "ЗАПРОС" в BMC 32 по стандартным каналам 4 связи соответственно (этап S10). Во-вторых, RMC 22 определяет, получен ли из BMC 32 по стандартным каналам 4 связи сигнал "ОТКЛИК", соответствующий сигналу "ЗАПРОС" (этап S12). После того как RMC 22 получает сигнал "ОТКЛИК" от BMC 32, он может взаимодействовать с BMC 32 по стандартным каналам 4 связи соответственно (этап S14) и передавать данные и файлы, необходимые узлам 3.

В соответствии с приведенным выше описанием, если RMC 22 не получает сигнал "ОТКЛИК" от одного из BMC 32 в течение времени ожидания (то есть множество BMC 32 содержит по меньшей мере один неответивший BMC 32), он определяет, больше или нет время повторной отправки повторного сигнала "ЗАПРОС", чем пороговое значение повторной отправки (этап S16). Если время повторной отправки сигнала "ЗАПРОС" не больше, чем пороговое значение повторной отправки, то RMC 22 повторно отправляет сигнал "ЗАПРОС" неответившему BMC 32 по одному из стандартных каналов 4 связи, соответствующих опять неответившему BMC 32, т.е. RMC 22 повторно выполняет этапы S10 – S16.

Если время повторной отправки сигнала "ЗАПРОС" больше, чем пороговое значение повторной отправки, то RMC 22 определяет, что неответивший BMC 32 имеет проблему и считает неответивший BMC 32 проблемным BMC 32, и посылает управляющий сигнал на вывод 321 сброса проблемного BMC 32 по каналу 5 GPIO, чтобы заставить проблемный BMC 32 перезагрузиться (этап S18). Кроме того, RMC 22 ожидает перезагрузки проблемного BMC 32, а затем после завершения перезагрузки взаимодействует с перезагруженным BMC 32 по одному из стандартных каналов 4 связи (этап S20).

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

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

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

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

модуль управления, электрически соединенный с узлом, имеющий печатную плату и контроллер управления стойкой (RMC), электрически соединенный с печатной платой, причем RMC содержит управляющий вывод, и причем RMC взаимодействует с ВМС по стандартному каналу связи;

при этом управляющий вывод RMC электрически соединен с выводом сброса ВМС по каналу ввода-вывода общего назначения (GPIO) с целью отправки управляющего сигнала на ВМС через печатную плату, канал GPIO и материнскую плату, чтобы заставить ВМС перезагрузиться при отсутствии получения сигнала "ОТКЛИК" от ВМС по стандартному каналу связи.

2. Стойка по п. 1, отличающаяся тем, что стандартный канал связи осуществлен посредством интеллектуальной шины управления платформой (IPMB), последовательной шины данных для связи интегральных схем (I²C), универсального асинхронного приемника/передатчика (UART) или локальной вычислительной сети (LAN).

3. Стойка по п. 1, отличающаяся тем, что дополнительно содержит микросхему управления питанием, электрически соединенную с узлом и источником питания стойки, при этом RMC подключен к микросхеме управления питанием по каналу GPIO и отправляет команду сброса на микросхему управления питанием, если не получает сигнал "ОТКЛИК" от ВМС по стандартному каналу связи, а микросхема управления питанием прерывает питание, подаваемое на узел, в соответствии с содержанием команды сброса, а затем снова восстанавливает питание, подаваемое на узел.

4. Способ автоматического восстановления для стойки для восстановления узла, не имеющего ошибок связи с контроллером управления стойкой, при этом стойка содержит модуль управления и узел, электрически соединенный с модулем управления, модуль управления, содержащий контроллер управления стойкой (RMC), узел, содержащий контроллер управления материнской платой (ВМС), взаимодействующий с RMC по стандартному каналу связи, причем способ включает:

a) определение того, есть ли сбой при получении сигнала "ОТКЛИК" от ВМС по стандартному каналу связи на RMC, при этом узел имеет материнскую плату, ВМС электрически соединен с материнской платой и содержит вывод сброса, модуль управления имеет печатную плату, RMC электрически соединен с печатной платой и содержит управляющий вывод;

b) в случае сбоя при получении сигнала "ОТКЛИК" от ВМС по стандартному каналу связи на RMC управляющий вывод RMC отправляет управляющий сигнал на вывод сброса ВМС через печатную плату, по каналу ввода-вывода общего назначения (GPIO) и материнскую плату, чтобы заставить ВМС перезагрузиться, при этом управляющий вывод RMC и вывод сброса ВМС электрически соединены друг с другом по каналу GPIO.

5. Способ автоматического восстановления по п. 4, отличающийся тем, что RMC содержит управляющий вывод, ВМС содержит вывод сброса, управляющий вывод RMC электрически соединен с выводом сброса ВМС по каналу GPIO для отправки управляющего сигнала.

6. Способ автоматического восстановления по п. 5, отличающийся тем, что перед этапом а дополнительно включает этап а0 отправки сигнала "ЗАПРОС" на ВМС по стандартному каналу связи от RMC.

7. Способ автоматического восстановления по п. 6, отличающийся тем, что этап а включает следующие этапы:

a1) определение, получен ли сигнал "ОТКЛИК", соответствующий сигналу "ЗАПРОС", от ВМС по стандартному каналу связи;

а2) определение, является ли время повторной отправки сигнала "ЗАПРОС" больше, чем пороговое значение повторной отправки или нет, при отсутствии получения сигнала "ОТКЛИК";

а3) повторная отправка сигнала "ЗАПРОС" на ВМС по стандартному каналу связи, если время повторной отправки не больше, чем пороговое значение повторной отправки;

а4) выполнение этапа b, если время повторной отправки больше, чем пороговое значение повторной отправки.

8. Способ автоматического восстановления по п. 7, отличающийся тем, что дополнительно включает этап с: ожидания перезагрузки ВМС и взаимодействия с ВМС по стандартному каналу связи после завершения перезагрузки после этапа b.