Способ и устройство для восстановления нарушенной работоспособности узла, электронное устройство и носитель данных - RU2751551C1

Чертежи

Описание

В настоящей заявке испрашивается приоритет согласно заявке на патент Китая № 201711164996.X, поданной в Национальное управление по интеллектуальной собственности Китая 21 ноября 2017 г. и озаглавленной «СПОСОБ И УСТРОЙСТВО ДЛЯ ВОССТАНОВЛЕНИЯ НАРУШЕННОЙ РАБОТОСПОСОБНОСТИ УЗЛА, ЭЛЕКТРОННОЕ УСТРОЙСТВО И носитель данных», во всей полноте включенной в настоящую заявку посредством отсылки.

ОБЛАСТЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

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

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

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

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

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

В итоге, способ восстановления после выхода узла из строя, предложенный в вариантах осуществления изобретения по настоящей заявке, применим к прокси-серверу в системе «ведущий - ведомый». Система «ведущий - ведомый» дополнительно включает в себя целевой ведущий узел, управляемый прокси-сервером, и целевой ведомый узел, соответствующий целевому ведущему узлу. Целевой ведущий узел представляет собой ведущий узел базы данных кэша. Целевой ведомый узел выполнен с механизмом устойчивости для кэшированных данных. Целевой ведущий узел не выполнен с механизмом устойчивости. Если прокси-сервер обнаружит выход из строя и целевого ведущего узла, и целевого ведомого узла, определяют перманентный файл, сгенерированный целевым ведомым узлом посредством механизма устойчивости. Развертывают невышедший из строя целевой ведущий узел, на основе перманентного файла; и развертывают целевой ведомый узел, соответствующий невышедшему из строя целевому ведущему узлу.

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

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

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

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

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

ФИГ. 3 - принципиальная схема структуры системы «ведущий - ведомый» в варианте осуществления по настоящей заявке;

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

ФИГ. 5 - принципиальная схема структуры устройства для восстановления после выхода узла из строя, предложенного в варианте осуществления по настоящей заявке;

ФИГ. 6 - принципиальная схема структуры устройства для восстановления после выхода узла из строя, предложенного в другом варианте осуществления по настоящей заявке.

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

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

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

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

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

Например, узел кэшированных данных «Redis» может быть выполнен с механизмом устойчивости AOF (англ. AppendOnly File, файл «только для добавления»). Любая операция записи в узел кэшированных данных «Redis» будет происходить в перманентном файле appendonly.aof. В случае выхода из строя узла кэшированных данных «Redis», перманентный файл appendonly.aof не будет потерян. Когда будет перезагружен узел кэшированных данных «Redis» или будет создан новый узел кэшированных данных «Redis», данные, кэшированные в узле кэшированных данных «Redis» до выхода узла из строя кэшированных данных «Redis» можно будет восстановить на основе перманентного файла appendonly.aof.

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

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

Например, данные A кэшированы и в ведущем, и в ведомых узлах. В какой-то момент данные A, кэшированные в ведущем узле, удаляют. За счет механизма репликации «ведущий - ведомый» ведомый узел осуществляет локальное удаление кэшированных данных A, когда ему становится известно об удалении данных A, кэшированных в ведущем узле. В качестве другого примера, после выхода из строя ведомого узла создают новый узел взамен вышедшего из строя ведомого узла, а затем новосозданный узел создает локальную копию данных, кэшированных в текущем ведущем узле, посредством механизма репликации «ведущий - ведомый» для завершения создания ведомого узла.

Для решения проблемы неработоспособности системы «ведущий - ведомый» из-за сбоя и ведущего узла, и ведомого узла в известной системе «ведущий - ведомый», в вариантах осуществления изобретения по настоящей заявке предложены способ и устройство для восстановления после выхода узла из строя, электронное устройство и носитель данных.

Ниже раскрыт способ восстановления после выхода узла из строя, предложенный в варианте осуществления по настоящей заявке.

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

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

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

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

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

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

На ФИГ. 1 способ восстановления после выхода узла из строя, предложенный в варианте осуществления по настоящей заявке, включает в себя следующие операции.

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

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

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

Как сказано выше, целевой ведомый узел выполнен с механизмом устойчивости, за счет чего также будет происходить преобразование кэшированных данных в целевом ведомом узле в перманентные данные, например, перманентный файл, т.е. вышеупомянутый предварительно запомненный перманентный файл. Иначе говоря, перманентный файл генерируют на основе кэшированных данных в целевом ведомом узле. Например, целевой ведомый узел представляет собой узел кэшированных данных типа «Redis», выполненный с механизмом устойчивости AOF, при этом любая операция записи целевого ведомого узла будет зафиксирована в перманентном файле appendonly.aof.

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

На этапе S102 развертывают невышедший из строя целевой ведущий узел на основе перманентного файла, сгенерированного целевым ведомым узлом.

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

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

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

Операцию на этапе S102 можно реализовать с помощью любых допустимых известных технических решений. Вариант по настоящей заявке также предусматривает возможность необязательного варианта реализации. В частности, узлы в вышеуказанной системе «ведущий - ведомый» создают посредством построителя узлов. Построитель узлов может включать в себя систему LXC (англ. Linux Container) или виртуальную машину. Следует понимать, что в число узлов в системе «ведущий - ведомый» входит ведущий узел и ведомый узел.

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

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

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

Если целевой ведущий узел создан в первом построителе узлов, целевой ведущий узел может выйти из строя без выхода из строя первого построителя узлов, либо целевой ведущий узел может выйти из строя из-за выхода из строя первого построителя узлов.

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

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

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

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

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

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

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

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

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

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

Таким образом, если целевой ведущий узел и целевой ведомый узел, речь о которых идет в варианте по настоящей заявке, представляют собой узлы в кластере, вышеуказанная система «ведущий - ведомый» может, помимо целевого ведущего узла, дополнительно содержать не-целевые ведущие узлы, управляемые прокси-сервером, и не-целевые ведомые узлы, соответствующие каждому из не-целевых ведущих узлов. На ФИГ.3 показано, что служебная система «ведущий - ведомый» включает в себя прокси-сервер, целевой ведущий узел, целевой ведомый узел, не-целевые ведущие узлы с 1 по m и не-целевые ведомые узлы с 1 по m.

В этом случае, все указанные ведущие узлы и ведомые узлы в системе «ведущий - ведомый» в варианте по настоящей заявке образуют кластер базы данных кэша. Иначе говоря, целевой ведущий узел, целевой ведомый узел, не-целевые ведущие узлы с 1 по m и не-целевые ведомые узлы с 1 по m образуют кластер базы данных кэша.

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

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

Специалистам в данной области техники хорошо известно, что в кластере базы данных кэша существуют информационные взаимодействия между всеми узлами, а также то, что все узлы должны быть осведомлены о других узлах, существующих в кластере базы данных кэша. Поэтому каждый узел в кластере базы данных кэша может содержать файл конфигурации узла, могущий содержать протокольный адрес узла в сети Интернет (IP-адрес, англ. Internet Protocol (IP) address), и идентификационную информация, идентифицирующую узел, т.е. вышеуказанный универсальный уникальный идентификатор (UUID).

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

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

a1: определение того, потерян ли файл конфигурации целевого узла вышедшего из строя целевого ведущего узла.

Файл конфигурации целевого узла - это файл конфигурации узла, хранимый в целевом ведущем узле. В случае выхода из строя целевого ведущего узла, файл конфигурации целевого узла может быть потерян. Касательно операции a1, например, целевой ведущий узел создан в LXC, и до выхода из строя целевого ведущего узла файл конфигурации целевого узла node.conf хранился в каталоге X. В этом случае, после выхода из строя целевого ведущего узла, прокси-сервер осуществляет поиск файла конфигурации целевого узла node.conf в LXC. Если файл конфигурации целевого узла node.conf будет найден, определяют, что файл конфигурации целевого узла не потерян. Если файл конфигурации целевого узла node.conf не может быть найден, определяют, что файл конфигурации целевого узла потерян.

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

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

В варианте по настоящей заявке, после создания узла в новосозданном построителе узлов, созданный узел сперва добавляют в кластер базы данных кэша, чтобы созданный узел стал узлом в кластере базы данных кэша. Способ добавления узла в кластер базы данных кэша известен из уровня техники, а специалисты в данной области техники смогут добавить созданный узел в кластер базы данных кэша любым известным образом. Например, кластер базы данных кэша представляет собой кластер «Redis». Прокси-сервер может направить IP-адрес созданного узла другим узлам в кластере базы данных кэша и исполнить в них команду cluster_meet, чтобы эти узлы в кластере базы данных кэша узнали, что данный IP-адрес соответствует узлу в кластере базы данных кэша. Таким образом, созданный узел будет добавлен в кластер базы данных кэша.

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

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

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

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

Для операции a2, например, предположим, что кластер базы данных кэша - это кластер «Redis», в связи с чем прокси-сервер сперва использует файл конфигурации базы данных redis.conf и перманентный файл appendonly.aof, сгенерированный целевым ведомым узлом, для создания нового построителя узлов в кластере базы данных кэша. Далее прокси-сервер направляет IP-адрес созданного узла другим узлам в кластере «Redis» и исполняет команду cluster_meet в этих других узлах для добавления созданного узла к узлам базы данных кэша. И наконец, прокси-сервер получает универсальный уникальный идентификатор целевого ведущего узла от узлов, не являющихся целевым ведущим узлом, в кластере базы данных кэша, и присваивает созданному узлу универсальный уникальный идентификатор целевого ведущего узла. На этом создание целевого ведущего узла завершено.

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

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

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

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

Для операции a3, например, предположим, что кластер базы данных кэша представляет собой кластер «Redis», в связи с чем прокси-сервер сперва использует файл конфигурации базы данных redis.conf, файл конфигурации целевого узла node.conf и перманентный файл appendonly.aof, сгенерированный целевым ведомым узлом, для создания узла в новосозданном построителе узлов; затем направляет IP-адрес созданного узла другим узлам в кластере «Redis» и исполняет команду cluster_meet в указанных других узлах для добавления созданного узла к узлам базы данных кэша. На этом создание целевого ведущего узла завершено.

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

b1: определяют, потерян ли файл конфигурации целевого узла в вышедшем из строя целевом ведущем узле.

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

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

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

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

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

Например, предположим, что кластер базы данных кэша представляет собой кластер «Redis», в связи с чем прокси-сервер может использовать непосредственно файл конфигурации базы данных redis.conf, файл конфигурации целевого узла node.conf и перманентный файл appendonly.aof, сгенерированный целевым ведомым узлом, для перезагрузки вышедшего из строя целевого ведущего узла.

На ФИГ. 1 показано, что на этапе S103 развертывают целевой ведомый узел, соответствующий невышедшему из строя целевому ведущему узлу.

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

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

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

развертывание целевого ведомого узла, соответствующего невышедшему из строя целевому ведущему узлу, посредством механизма репликации «ведущий - ведомый».

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

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

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

Операция c2: если первый построитель узлов не вышел из строя или успешно перезагружен после выхода из строя, перезагружают вышедший из строя целевой ведущий узел посредством механизма репликации «ведущий - ведомый».

Операции c1 и c2 отличны от раскрытых выше операций S1021 и S1022 в том, что кэшированные данные в развертываемом целевом ведомом узле получены посредством механизма репликации «ведущий - ведомый», а кэшированные данные в целевом ведомом узле, развертываемом в операциях S1021 и S1022, получены на основе перманентных файлов. Прочие принципы реализации операций c1 и c2, детально не раскрываемые в варианте по настоящей заявке, можно узнать, ознакомившись с раскрытыми выше операциями S1021 и S1022.

Кроме того, прокси-сервер может контролировать, превышает ли время, затрачиваемое развернутым целевым ведомым узлом на создание локальной копии данных, кэшированных в развернутом целевом ведущем узле, заранее заданную продолжительность, независимо от того, был ли создан новый целевой ведомый узел в новосозданном построителе узлов, или был перезагружен вышедший из строя целевой ведомый узел. На практике, можно проверить значение поля master_link_status, которым может быть «up» или «down», в развернутом целевом ведомом узле. Значение «up» означает, что развернутый целевой ведомый узел завершил репликацию «ведущий - ведомый». Значение «down» означает, что развернутый целевой ведомый узел не завершил репликацию «ведущий - ведомый».

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

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

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

Например, в кластере «Redis», где был развернут целевой ведущий узел, во время его развертывания происходит запись данных в целевой ведущий узел. Если развернутый целевой ведущий узел вновь выйдет из строя до завершения развертывания целевого ведомого узла, данные будут потеряны из-за выхода из строя целевого ведущего узла, так как данные записаны только в целевом ведущем узле.

В варианте по настоящей заявке, во избежание вышеуказанной проблемы потери данных, в дополнение к любому из вариантов осуществления способа на ФИГ. 1 или ФИГ. 2, до раскрытой выше операции развертывания целевого ведомого узла, соответствующего невышедшему из строя целевому ведущему узлу, на этапе S103, раскрытый выше способ может содержать этап, на котором:

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

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

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

Таким образом, в варианте осуществления по настоящей заявке на ФИГ. 4 раскрытый выше способ содержит следующие операции.

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

На этапе S202 развертывают невышедший из строя целевой ведущий узел на основе перманентного файла, сгенерированного целевым ведомым узлом.

На этапе S203 осуществляют управление развернутым целевым ведущим узлом для блокирования услуги записи в отношении его собственной базы данных кэша.

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

На этапе S204 развертывают целевой ведомый узел, соответствующий невышедшему из строя целевому ведущему узлу.

На этапе S205 осуществляют управление развернутым целевым ведущим узлом для разблокирования услуги записи в отношении его базы данных кэша.

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

Операции S201, S202 и S204 в варианте способа на ФИГ.4 соответствуют операциям S101, S102 и S103 в варианте способа на ФИГ.1. Описание реализации и конкретные разъяснения по операциям S201, S202 и S204, повторно не раскрываемым в настоящем варианте, можно получить, обратившись к варианту способа на ФИГ.1.

Также следует понимать, что нужно время для того, чтобы преобразовать все кэшированные данные, записанные в развернутом целевом ведомом узле, в перманентные данные. Если развернутые целевой ведущий и целевой ведомый узлы вновь выйдут из строя после завершения развертывания целевого ведомого узла, но до преобразования развернутым целевым ведомым узлом всех записанных в нем кэшированных данных в перманентные данные, может произойти потеря данных. Это обусловлено отсутствием неповрежденного перманентного файла, соответствующего всем кэшированным данным в системе «ведущий - ведомый», в связи с чем прокси-сервер не может восстановить все кэшированные данные. В варианте по настоящей заявке, сделана попытка избежать данную проблему. В дополнение к раскрытому выше варианту способа на ФИГ.4, способ может содержать этапы, на которых: до выполнения на этапе S205 операции управления развернутым целевым ведущим узлом для разблокирования услуги записи в отношении его базы данных кэша и после операции развертывания целевого ведомого узла, соответствующего вышедшему из строя целевому ведущему узлу, выполняют следующие операции.

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

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

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

Следует понимать, что все варианты осуществления способа восстановления после выхода узла из строя на ФИГ. 1, 2 и 4 раскрыты для случая, в котором и целевой ведущий узел, и целевой ведомый узел в системе «ведущий - ведомый» выходят из строя. На практике, всегда есть два других случая выхода из строя узла в системе «ведущий - ведомый».

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

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

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

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

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

В случае сбоя перезагрузки построителя узлов, где расположен целевой ведущий узел, прокси-серверу нужно создать новый построитель узлов в управляемой им физической машине. В случае сбоя создания нового построителя узлов, генерируют аварийное сообщение об этом. Если новый построитель узлов будет создан успешно, в созданном построителе узлов создают узел и добавляют его в кластер «Redis» посредством команды cluster_add_slave. Таким образом, получают узел S.

Получив узел S, прокси-сервер принимает узел S в качестве целевого ведомого узла текущего целевого ведущего узла, то есть нового целевого ведомого узла. Далее новый целевой ведомый узел начинает создавать локальную копию данных, кэшированных в текущем целевом ведущем узле посредством механизма репликации «ведущий - ведомый». Прокси-сервер может контролировать, завершил ли новый целевой ведомый узел операцию репликации «ведущий - ведомый».

На практике, определяют значение поля master_link_status в целевом ведомом узле, которым может быть «up» или «down». Значение «up» указывает на то, что новый целевой ведомый узел завершил репликацию «ведущий - ведомый». Значение «down» указывает на то, что новый целевой ведомый узел не завершил репликацию «ведущий - ведомый». Одновременно прокси-сервер может контролировать, превышает ли время, затрачиваемое новым целевым ведомым узлом на создание локальной копии данных, кэшированных в текущем целевом ведущем узле, заранее заданную продолжительность. В случае превышения, может быть сгенерировано аварийное сообщение о нем, чтобы дать оператору возможность выявить причину, по которой время, нужное новому целевому ведомому узлу для создания локальной копии данных, кэшированных в текущем целевом ведущем узле, превышает заранее заданную продолжительность.

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

Следует понимать, что новый целевой ведомый узел выполнен с механизмом устойчивости, например, механизмом устойчивости AOF. Прокси-серверу также следует контролировать то, преобразовал ли новый целевой ведомый узел все записанные кэшированные данные в перманентные данные. Например, прокси-сервер может определить, равно ли 0 значение поля aof_base_size в новом целевом ведомом узле. Значение 0 указывает на то, что текущий новый целевой ведомый узел не преобразовал все записанные кэшированные данные в перманентные данные. Ненулевое значение указывает на то, что текущий новый целевой ведомый узел преобразовал все записанные кэшированные данные в перманентные данные.

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

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

Соответственно варианту способа на ФИГ.1, в варианте по настоящей заявке также предложено устройство для восстановления после выхода узла из строя, применимое к прокси-серверу в системе «ведущий - ведомый». Система «ведущий - ведомый» дополнительно включает в себя целевой ведущий узел, управляемый прокси-сервером, и целевой ведомый узел, соответствующий целевому ведущему узлу. На ФИГ. 5 показано, что вышеуказанное устройство для восстановления после выхода узла из строя содержит определяющий модуль 110, первый развертывающий модуль 120 и второй развертывающий модуль 130.

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

Целевой ведомый узел хранит резервную копию кэшированных данных, кэшированных в целевом ведущем узле, при этом перманентный файл генерируют на основе кэшированных данных в целевом ведомом узле.

Первый развертывающий модуль 120 выполнен с возможностью развертывания невышедшего из строя целевого ведущего узла на основе перманентного файла.

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

В частности, в соответствии с вариантом способа на ФИГ.2, узлы в системе «ведущий - ведомый» создают в построителе узлов. Построитель узлов представляет собой LXC или виртуальную машину.

Соответственно, первый развертывающий модуль 120 может быть выполнен с возможностью:

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

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

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

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

В соответствии с вариантом способа на ФИГ.2, вышеуказанный первый развертывающий модуль 120 может быть выполнен с возможностью:

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

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

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

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

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

если файл конфигурации целевого узла не потерян - перезагрузки вышедшего из строя целевого ведущего узла на основе перманентного файла и файла конфигурации целевого узла.

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

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

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

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

создания нового целевого ведущего узла в новосозданном построителе узлов на основе перманентного файла, если результатом контроля контролирующим модулем будет «да».

В необязательном случае реализации варианта по настоящей заявке, в дополнение к варианту способа на ФИГ. 4, устройство на ФИГ. 6 может дополнительно содержать:

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

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

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

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

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

развертывания целевого ведомого узла, соответствующего невышедшему из строя целевому ведущему узлу, посредством механизма репликации «ведущий - ведомый».

В одном из случаев реализации узлы в системе «ведущий - ведомый» создают в построителе узлов, при этом вышеуказанный второй развертывающий модуль может быть выполнен с возможностью:

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

если второй построитель узлов не вышел из строя или успешно перезагружен после выхода из строя - перезагрузки вышедшего из строя целевого ведомого узла посредством механизма репликации «ведущий - ведомый».

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

В варианте по настоящей заявке дополнительно предложено электронное устройство, раскрытое на ФИГ. 7, включающее в себя процессор 210 и память 220.

Память 220 выполнена с возможностью хранения компьютерной программы.

Процессор 210 выполнен с возможностью выполнения, при исполнении программы, хранимой в памяти, операций:

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

развертывания невышедшего из строя целевого ведущего узла на основе перманентного файла; и

развертывания целевой ведомого узла, соответствующего невышедшему из строя целевому ведущему узлу.

Конкретное описание реализации и соответствующие разъяснения по каждой операции способа, а также детали, не раскрытые здесь, можно получить, обратившись к вариантам способа на ФИГ. 1, ФИГ. 2 и ФИГ. 3.

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

Процессор 210, интерфейс связи и память 220 осуществляют связь друг с другом посредством шины связи. Шина связи, речь о которой идет в настоящем описании, может представлять собой шину по стандарту межсоединения периферийных компонентов (англ. Peripheral Component Interconnect, PCI) или шину по стандарту расширенной стандартной архитектуры для промышленного применения (англ. Extended Industry Standard Architecture, EISA). Шина связи может включать в себя адресную шину, шину данных, шину управления и т.п.

Память 220 может включать в себя оперативное запоминающее устройство (ОЗУ, англ. Random Access Memory, RAM), а также может включать в себя энергонезависимое запоминающее устройство (ЭНЗУ, англ. Non-Volatile Memory, NVM), например, по меньше мере одно дисковое запоминающее устройство. Память также может необязательно представлять собой по меньшей мере одно устройство хранения, расположенное на удалении от процессора.

Вышеуказанный процессор 210 может представлять собой универсальный процессор, в том числе - центральный процессор (ЦПУ, англ. Central Processing Unit, CPU), сетевой процессор (англ. Network Processor, (NP) и т.п. Он также может представлять собой цифровой сигнальный процессор (ЦСП, англ. Digital Signal Processor, DSP), специализированную интегральную схему (СИС, англ. Application Specific Integrated Circuit, ASIC), программируемую пользователем вентильную матрицу (ППВМ, англ. Field Programmable Gate Array, FPGA) или иные программируемые логические устройства, схемы на дискретных компонентах или устройства на транзисторных логических схемах, а также дискретные аппаратные компоненты.

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

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

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

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

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

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

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

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

Промышленная применимость

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

Реферат

Изобретение относится к области электронно-вычислительной техники. Технический результат заключается в восстановлении системы «ведущий - ведомый» в нормальное рабочее состояние после выхода из строя и целевого ведущего узла, и целевого ведомого узла. Такой результат достигается тем, что в случае выхода из строя целевого ведущего узла и целевого ведомого узла, прокси-сервер получает предварительно запомненный перманентный файл из целевого ведомого узла, целевой ведомый узел хранит резервную копию кэшированных данных, кэшированных в целевом ведущем узле, и перманентный файл, сгенерированный на основе кэшированных данных в целевом ведомом узле, развертывают невышедший из строя целевой ведущий узел на основе перманентного файла; и развертывают целевой ведомый узел, соответствующий невышедшему из строя целевому ведущему узлу. 4 н. и 16 з.п. ф-лы, 7 ил.

Формула