Обеспечение службы-свидетеля

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

 

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

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

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

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

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

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

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

Краткое описание чертежей

Не накладывающие ограничений и не исчерпывающие варианты осуществления описываются со ссылкой на следующие фигуры.

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

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

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

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

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

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

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

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

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

Фиг. 1 иллюстрирует систему 100, которая может использоваться для реализации некоторых вариантов осуществления. Система 100 включает в себя клиенты 102 и 104 и кластер 106 серверов. Клиенты 102 и 104 осуществляют связь с кластером 106 серверов посредством сети 108. Кластер 106 серверов хранит информацию, доступ к которой осуществляется посредством приложений на клиентах 102 и 104. Клиенты 102 и 104 устанавливают сеансы с кластером 106 для доступа к информации в кластере 106. Несмотря на то, что на Фиг. 1 показаны только клиенты 102 и 104 как осуществляющие связь с кластером 106, в других вариантах осуществления может присутствовать более двух клиентов, осуществляющих доступ к информации в кластере 106 серверов.

Как показано на Фиг. 1, кластер 106 серверов включает в себя серверы 106A, 106B, и 106C, которые обеспечивают как высокую доступность, так и надежность применительно к информации, которая хранится в кластере 106. В вариантах осуществления, кластер 106 может обладать файловой системой, базой данных или другой информацией, доступ к которой осуществляется со стороны клиентов 102 и 104. Несмотря на то, что на Фиг. 1 показано три сервера, в других вариантах осуществления кластер 106 может включать в себя больше трех серверов или меньше трех серверов.

В соответствии с одним вариантом осуществления, в дополнение к хранению информации, доступ к которой осуществляется со стороны клиентов 102 и 104, кластер 106 также обеспечивает службу-свидетель. Служба-свидетель позволяет клиентам 102 и 104 принимать уведомления, касающиеся состояния ресурсов, отслеживаемых кластером 106. Ресурсы могут быть ресурсами кластера или ресурсами сети. В одном варианте осуществления, каждый из серверов 106A, 106B и 106C выполнен с возможностью обеспечения службы-свидетеля. Т.е. клиенты 102 и 104 могут зарегистрироваться на любом из серверов 106A, 106B и 106C в службе-свидетеле в том случае, если клиент не использует сервер для доступа к ресурсам кластера. В других вариантах осуществления, может присутствовать только часть серверов кластера 106, которые обеспечивают службу-свидетель. Например, в данном варианте осуществления работа службы-свидетеля будет обеспечиваться только на серверах 106B и 106C. В других вариантах осуществления, кластер 106 может включать в себя серверы, которые выделены для обеспечения службы-свидетеля. Применительно к этим вариантам осуществления, несмотря на то, что не показано, кластер 106 может включать в себя серверы, которые специально сконфигурированы для обеспечения работы службы-свидетеля и не будут обеспечивать доступ клиентам 102 и 104.

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

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

Для иллюстрации одного варианта осуществления, клиент 102 устанавливает сеанс с сервером кластера 106. Например, клиент 102 может установить сеанс с сервером 106A для доступа к базе данных, которая хранится на сервере 106A. Так как клиент 102 осуществляет доступ к информации на сервере 106A, он может хотеть иметь своевременную информацию о любых отказах на сервере 106A. Своевременное обнаружение отказа позволит выполнить своевременное восстановление, которое сокращает количество времени, которое должно ожидать приложение на клиенте 102. Своевременное обнаружение и восстановление также сокращает промежуток времени, в течение которого ресурсы, зарезервированные для клиента 102 для повторного подключения, недоступны другим клиентам.

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

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

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

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

Обращаясь теперь к Фиг. 2, структурная схема программной среды 200, показывающей клиенты 202 и 204 и кластер 206 узлов, показана на Фиг. 2. Клиенты и кластер узлов осуществляют обмен сообщениями, используя протокол свидетеля, согласующийся с некоторыми вариантами осуществления. Фиг. 2 показана для иллюстрации общего примера среды для использования протокола свидетеля. Описание по Фиг. 2 подразумевается как общее и применимое к любому количеству ситуаций, таких как, например, когда клиенты 202 и 204 осуществляют доступ к файловой системе, которая хранится в кластере 206 узлов, где кластер 206 узлов является кластером серверов с распределенной файловой системой. В качестве другого примера, среда 200 может использоваться в ситуации, где клиенты 202 и 204 осуществляют доступ к базе данных, которая хранится в кластере 206 узлов.

Как показано на Фиг. 2, клиенты 202 и 204 осуществляют доступ к информации, обеспечиваемой кластером 206 узлов. Кластер 206 узлов включает в себя три узла, узел 1, узел 2, и узел 3. Как показано на Фиг. 2, каждый из узлов 1, 2, и 3 включает в себя различные компоненты, которые осуществляют связь с клиентами 202 и 204. Например, каждый узел включает в себя модуль доступа клиента, который осуществляет связь с клиентами 202 и 204 для установления сеансов с тем, чтобы разрешить клиентам доступ к информации, которая хранится в кластере узлов.

В варианте осуществления, показанном на Фиг. 2, узлы 1, 2 и 3 также включают в себя компонент управления свидетелем, который осуществляет связь с клиентами 202 и 204, как часть службы-свидетеля, обеспечиваемой в кластере 206 узлов. Компонент управления свидетелем обеспечивает информацию, касающуюся того, на каких узлах в кластере 206 узлов работает служба-свидетель, с тем чтобы клиенты 202 и 204 могли зарегистрироваться в службе-свидетеле. В дополнение, компонент управления свидетелем также регистрирует клиентов на уведомления о состояниях ресурса и также осуществляет связь с компонентом отслеживания, показанным на Фиг. 2, который принимает и обрабатывает события от ресурсов узла и сети. Компонент отслеживания обрабатывает события и обеспечивает информацию о состоянии и изменении состояния компоненту управления свидетелем, который в свою очередь уведомляет любых клиентов, зарегистрированных на уведомление о состоянии или изменении состояния ресурса. В некоторых вариантах осуществления, компонент отслеживания может использовать API, обеспечиваемый службой кластеров для отслеживания состояния ресурсов в кластере.

В варианте осуществления, показанном на Фиг. 2, клиент 202 установил сеанс с узлом 1 и отправляет запросы доступа, используя канал 208, компоненту доступа клиента из состава узла 1. Клиент 202 также инициировал отдельный канал (не показан) с узлом 1 для приема информации, касающейся службы-свидетеля, например, касаемо того, какие серверы обеспечивают службу-свидетель. Отдельный канал, установленный с узлом 1, позволяет узлу 1 сообщать информацию, касающуюся службы-свидетеля, не пересекаясь с запросами доступа, отправленными клиентом 202.

На Фиг. 2 клиент 202 зарегистрировался в службе-свидетеле, обеспечиваемой компонентом управления свидетелем в узле 2. Как показано на Фиг. 2, осуществление связи с компонентом управления свидетелем происходит по отдельному каналу 210. Соответственно, любой тип информации свидетеля, включая уведомления о состоянии, не пересекается с запросами доступа по каналу 208. Канал 216, показанный штриховой линией, иллюстрирует отдельный канал, который клиент 202 устанавливает для отправки запросов доступа в случае отказа ресурсов в узле 1. В некоторых вариантах осуществления, компонент управления свидетелем обеспечивает информацию, указывающую новый ресурс клиенту 202 для отправки запросов доступа в случае отказа, а также рекомендуемый сетевой путь или количество рекомендуемых сетевых путей для подключения к новому ресурсу.

Аналогичным образом клиент 204 установил сеанс с узлом 2 и отправляет запросы доступа по каналу 212 компоненту доступа клиента из состава узла 2. Клиент 204 также зарегистрирован в службе-свидетеле и осуществляет связь, используя канал 214, с компонентом управления свидетелем узла 3.

В одном варианте осуществления, компоненты управления свидетелем обеспечивают дополнительные функциональные возможности. В некоторых вариантах осуществления, эти компоненты обеспечивают функциональные возможности балансировки нагрузки. Т.е. в дополнение к отправке уведомлений, касающихся состояния ресурсов, компоненты управления свидетелем также могут отправлять уведомления, которые запрашивают, чтобы клиенты 202 и 204 подключились к другим ресурсам, на основании алгоритма для балансировки нагрузки в узле 206. Например, как показано на Фиг. 2, клиент 202 осуществляет связь с компонентом доступа клиента узла 1. Дополнительно, клиент 202 осуществляет связь с компонентом управления свидетелем узла 2, который обеспечивает клиенту 202 уведомления о любых изменениях состояния ресурсов, таком как отказ ресурсов в узле 1. В данном варианте осуществления компонент управления свидетелем из состава узла 2 может определять, что узел 1 функционирует плохо (например, высокая задержка), поскольку узлом 1 обслуживается чрезмерное количество запросов доступа. В качестве другого примера, может быть выполнено определение о разгрузке клиентов с узла 2 с тем, чтобы разрешить выключение узла 2 для экономии энергии или по другим причинам, таким как техническое обслуживание. В соответствии с алгоритмом узел 2 может отправить уведомление клиенту 202, указывающее на то, что он должен начать отправку любых последующих запросов доступа в узле 3, который может быть недогруженным. Затем клиент 202 должен установить сеанс, как иллюстрируется штриховыми линиями в виде канала 216, с узлом 3 для отправки последующих запросов. В других вариантах осуществления компонент управления свидетелем обеспечивает информацию, указывающую не только новый ресурс клиенту 202 для отправки запросов доступа, но также рекомендуемый сетевой путь или некоторое количество рекомендуемых сетевых путей.

Фиг. 3 иллюстрирует среду 300, аналогичную среде 200, описанной на Фиг. 2. Тем не менее, среда 300 показывает клиенты 302 и 304, запрашивающие доступ для чтения/записи к файловому серверу, который размещается в кластере 306 серверов. Кластер 306 серверов включает в себя сервер 1, сервер 2 и сервер 3, каждый из которых включает в себя файловый сервер, компонент управления свидетелем и компонент отслеживания кластера. В варианте осуществления, показанном на Фиг. 3, клиенты 302 и 304 включают в себя приложение, компонент управления свидетелем и редиректор. Фиг. 4 иллюстрирует циклограмму, показывающую один пример сообщений, обмен которыми может осуществляться в среде 300 в соответствии с вариантом осуществления.

Описание по Фиг. 3 и 4 ниже выполнено с использованием в качестве протокола доступа к файлу протокола блока сообщений сервера (SMB). Тем не менее, варианты осуществления этим не ограничиваются. Любой протокол доступа к файлу, включая разные версии SMB или сетевую файловую систему (NFS), может использоваться в вариантах осуществления в качестве протокола доступа к файлу. SMB используется в описании лишь для удобства и простоты иллюстрации.

Обращаясь к Фиг. 4, циклограмма иллюстрирует сообщения, обмен которыми осуществляется между клиентом 302 (Фиг. 3), сетью 400 DNS и кластером 306 серверов (Фиг. 3) в соответствии с одним вариантом осуществления. Сначала клиент 302 отправляет запрос 402 сети 400 DNS для разрешения IP адреса кластера 306 серверов, который хранит файловую систему, доступ к которой может быть получен, используя версию SMB. В ответ на запрос 402, сеть 400 DNS отвечает сообщением 404, которое включает в себя IP адрес кластера 306 серверов.

После приема ответного сообщения 404 клиент 202 отправляет сообщение 406 запроса доступа в кластер 306 серверов. Запрос доступа может быть отправлен посредством редиректора в клиенте 302. Как показано на Фиг. 3 и 4, сервер 1 обрабатывает запрос от клиента 302. Как показано на Фиг. 3, сервер 1 включает в себя компонент файлового сервера, который осуществляет связь с редиректором в клиенте 302 для установления сеансов доступа к файлу. В вариантах осуществления, запрос 406 может быть первым запросом для согласования сеанса SMB. Например, запрос может быть пакетом согласования SMB2. Как иллюстрируется на Фиг. 4, сервер 1 отправляет ответ 408 доступа, который устанавливает сеанс с клиентом 302. Ответ может быть, например, ответом настройки сеанса SMB2 или ответом подключения дерева SMB2.

Следует отметить, что несмотря на то, что Фиг. 4 и связанное с ней описание представлены для одного запроса 406 доступа и одного ответа 408 доступа, в вариантах осуществления это может быть лишь двумя сообщениями из числа сообщений, которые отправляются для того, чтобы установить сеанс. Как следует иметь в виду, для установления сеанса с использованием протокола SMB2, может осуществляться обмен некоторым количеством сообщений между редиректором в клиенте 302 и файловым сервером в сервере 1. Сообщения могут включать в себя одно или более из сообщений согласования SMB2, сообщений настройки сеанса SMB2 и/или сообщений подключения дерева SMB2. После того как сеанс установлен, клиент 302 начинает отправку запросов доступа (не показано), например, чтения/записи файла и/или каталога, серверу 1 кластера 306 по установленному каналу 308 (Фиг. 3).

Компонент управления свидетелем в клиенте 302 обнаруживает, что сервер 1 является частью кластера 306. Данное обнаружение может происходить в вариантах осуществления как часть обработки ответного сообщения 408 или посредством некоего другого закрытого средства. В результате определения того, что сервер 1 является частью кластера 306, компонент управления свидетелем в клиенте 302 в вариантах осуществления выполнен с возможностью регистрации в службе-свидетеле, обеспечиваемой кластером 306. В результате, компонент управления свидетелем в клиенте 302 использует новый канал 310 (Фиг. 3) для отправки запроса 410 в отношении информации свидетеля серверу 1.

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

Вновь обращаясь к Фиг. 4, компонент управления свидетелем из состава сервера 1 отвечает на запрос 410 ответом 412, который включает в себя информацию свидетеля. Ответ 412 отформатирован в соответствии с протоколом свидетеля и будет включать в себя информацию, которая идентифицирует другие серверы в кластере 306, которые обеспечивают службу-свидетель. В вариантах осуществления, ответ 412 также включает в себя другую информацию, которая необходима клиенту 302 для подключения к службе-свидетелю на одном из прочих серверов кластера 306. В данном примере, информация свидетеля в ответе 412 включает в себя информацию, которая идентифицирует, по меньшей мере, сервер 2 как обеспечивающий службу-свидетель.

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

В ответ на информацию свидетеля, принятую от сервера 1, клиент 302 будет использовать канал 310 (Фиг. 3) для отправки запроса 414 регистрации серверу 2. Запрос 414 регистрации также отформатирован в соответствии с протоколом свидетеля и включает в себя информацию, которая идентифицирует ресурсы, в отношении которых клиент 302 желает получать уведомления. В одном примере, клиент 302 может желать знать, когда сервер 1 находится в режиме офлайн, так чтобы он имел своевременное указание об отказе сервера 1. Обнаружение отказа позволит реализовать своевременное восстановление, которое сокращает количество времени, которое приложение на клиенте 302 ожидает выполнения операции (например, чтения/записи). В данном примере, клиент 302 регистрируется в компоненте управления свидетелем из состава сервера 2 на уведомления, касающиеся онлайнового/офлайнового состояния сервера 1. Сервер 2 отправляет ответ 416 статуса, который квитирует запрос регистрации. В вариантах осуществления, ответ 416 также будет включать в себя текущее состояние ресурсов, в отношении которых клиент 302 зарегистрировался на прием уведомлений.

В некоторых вариантах осуществления после операции 416, на сервере-свидетеле (сервере 2) может произойти отказ, отказ 417 сервера, показанный штриховыми линиями. В данном случае, клиент 302 должен повторно выбрать альтернативный сервер, что включает в себя в некоторых вариантах осуществления отправку другого сообщения, аналогичного сообщению 410, и прием другого сообщения, аналогичного сообщению 412 (от сервера 1 или другого сервера). Клиент 302 также отправит запрос регистрации свидетеля, аналогичный запросу 414, для регистрации в службе-свидетеле в альтернативном сервере.

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

Если в некоторый момент времени происходит отказ 418 сервера сервера 1, то отказ обнаружится сервером 2. Как отмечено выше, сервер 2 может обнаружить отказ посредством приема событий, сформированных службой кластеров, которая работает в кластере 306. Как только сервер 2 обнаруживает отказ 418 сервера, сервер 2 отправит уведомление 420 об отказе клиенту 302. В ответ на отказ, клиент 302 в данном варианте осуществления выполнен с возможностью временной приостановки любых последующих запросов 422 доступа к файлу. Как следует иметь в виду, если клиент 302 послал бы любые дополнительные запросы доступа, они бы не были обработаны из-за отказа сервера 1. Служба-свидетель сервера 2 в варианте осуществления также выполнена с возможностью отправки сообщения 424 клиенту 302, указывающее на то, что присутствует доступный ресурс на сервере 3 для обработки запросов доступа от клиента 302. После приема сообщения 424, клиент 302 возобновит отправку запросов 426 доступа к файлу в сервер 3. Редиректор в клиенте 302 отправляет запросы 426 доступа к файлу посредством канала 312 (Фиг. 3) в компонент файлового сервера из состава сервера 3.

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

Несмотря на то что не показано, в некоторых вариантах осуществления, когда клиент 302 начинает отправку запросов доступа к файлу в сервер 3, он также меняет сервер, от которого он принимает службу-свидетель. Например, после отправки запросов доступа к файлу в сервер 3, клиент 302 может начать процесс отправки запроса информации свидетеля в сервер 3. Сервер 3 может ответить с помощью информации, аналогичной ответу 412, который отправлен сервером 1, включающему в себя информацию, касающуюся того, какие серверы обеспечивают службу-свидетель. Информация может отличаться, например, она может идентифицировать другие серверы. Серверы, которые были ранее идентифицированы как обеспечивающие службу-свидетель, возможно также отказали и более недоступны, или другие серверы вошли в режим онлайн. Также, в некоторых вариантах осуществления, компоненты управления свидетелем выполнены с возможностью обеспечения информации свидетеля с ранжированием серверов, которые доступны для обеспечения службы-свидетеля. Вследствие этого, информация свидетеля, обеспечиваемая сервером 3, может отличаться от информации свидетеля, которая ранее была обеспечена сервером 2. В ответ на информацию свидетеля, отправленную сервером 3, клиент 302 может решить, запросить ли регистрацию в службе-свидетеле у другого сервера.

Фиг. 5 и 6 иллюстрируют операционные потоки 500, 550, 600 и 650 в соответствии с вариантами осуществления. Операционные потоки 500, 550, 600 и 650 могут выполняться в любой приемлемой вычислительной среде. Например, операционные потоки могут исполняться системами и средами, такими как проиллюстрированные на Фиг. 1-3. Вследствие этого, описание операционных потоков 500, 550, 600 и 650 может относиться, по меньшей мере, к одному из компонентов с Фиг. 1-3. Тем не менее, любая такая ссылка на компоненты с Фиг. 1-3 служит только в целях описания, и следует понимать, что реализации на Фиг. 1-3 являются не накладывающими ограничений средами для операционных потоков 500, 550, 600 и 650.

Кроме того, несмотря на то, что операционные потоки 500, 550, 600 и 650 иллюстрируются и описываются последовательно в конкретном порядке, в других вариантах осуществления операции могут выполняться в других порядках, несколько раз и/или параллельно. Кроме того, одна или более операции могут быть опущены или объединены в некоторых вариантах осуществления.

Операционные потоки 500 и 550 иллюстрируются вместе на Фиг. 5, чтобы показать, что этапы в операционном потоке 500 могут иметь соответствующие этапы в операционном потоке 550. Операционный поток 500 иллюстрирует этапы для приема уведомлений о состоянии в отношении ресурса. Операционный поток 550 иллюстрирует этапы для обеспечения уведомления о состоянии в отношении ресурса. В вариантах осуществления, клиенты, такие как описанные выше клиенты 102 и 104 (Фиг. 1) или клиенты 202 и 204 (Фиг. 2), могут реализовывать операционный поток 500. Клиенты, которые реализуют операционный поток 500, могут быть клиентом любого типа, включая компьютеры класса лэптоп, настольные компьютеры, устройства интеллектуального телефона (смартфона) или планшетные компьютеры. В вариантах осуществления, узлы, такие как узел 1, узел 2 и узел 3, показанные на Фиг. 2, реализуют операционный поток 550. Узлы могут быть частью кластера узлов, на котором работает служба кластеров.

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

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

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

Поток 500 переходит от операции 510 к операции 512, где принимается уведомление, касающееся ресурса. Затем поток 500 завершается на операции 514. В некоторых вариантах осуществления могут присутствовать дополнительные этапы, выполняемые в ответ на прием уведомления на этапе 512, такие как временная приостановка запросов доступа, повторное подключение к другому узлу в кластере и возобновление запросов доступа к другому узлу в кластере.

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

Поток 550 имеет этапы, соответствующие тем, что описаны выше в отношении потока 500. Как отмечено выше, в вариантах осуществления, узел 1, узел 2 и узел 3, показанные на Фиг. 2, могут реализовывать поток 550. Поток 550 начинается на операции 552, где принимается запрос на подключение к узлу в кластере узлов. Запрос может быть запросом установления сеанса для доступа к информации, хранящейся в кластере узлов. Поток переходит от операции 552 к операции 554, где отправляется ответ, указывающий на то, что сеанс установлен, чтобы разрешить доступ к информации, хранящейся на первом узле в кластере узлов. В некоторых вариантах осуществления, за операцией 554 последуют дополнительные этапы, не показанные в потоке 550. Например, как только установлен сеанс, как указано в ответе, отправленном на операции 554, может присутствовать некоторое количество запросов доступа, которые принимаются для доступа к информации, хранящейся в первом узле кластера узлов.

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

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

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

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

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

Операционный поток 600 иллюстрирует этапы для приема уведомлений о состоянии в отношении ресурса кластера от кластера, обеспечивающего распределенную файловую систему клиентам. Операционный поток 650 иллюстрирует этапы для обеспечения уведомлений о состоянии в отношении ресурса кластера в кластере, обеспечивающем файловую систему. В вариантах осуществления, клиенты, такие как описанные выше клиенты 102 и 104 (Фиг. 1) или клиенты 302 и 304 (Фиг. 3), могут реализовывать операционный поток 600. В вариантах осуществления, серверы кластера 306 серверов, такие как сервер 1, сервер 2 и сервер 3, показанные на Фиг. 3, реализуют операционный поток 650.

Поток 600 начинается на операции 602, где отправляется запрос на подключение к файловой системе в кластере серверов. Кластер серверов включает в себя более одного сервера и хранит файловую информацию, доступ к которой осуществляют клиенты. В некоторых вариантах осуществления, запрос, отправляемый на операции 602, является запросом установления сеанса с сервером в кластере серверов, чтобы осуществлять доступ к файлам в кластере. Сеанс в вариантах осуществления устанавливается с помощью протокола доступа к файлу, такого как некая версия SMB или NFS. После операции 602 поток переходит к операции 604, где принимается ответ, указывающий на то, что сеанс с сервером в кластере установлен. Операции 602 и 604 могут быть только двумя операциями в ряду операций, которые выполняются для согласования сеанса. Т.е. в других вариантах осуществления может присутствовать некоторое количество операций, которые выполняются между операциями 602 и 604.

После операции 604 на операции 606 в сервер отправляются запросы доступа для доступа к информации из файловой системы, хранящейся в кластере серверов. Запросы доступа могут включать в себя, например, запросы чтения/записи, которые отформатированы в соответствии с конкретными протоколами доступа к файлу, такими как некая версия SMB или версия NFS.

Как показано в варианте осуществления на Фиг. 6, операционный поток переходит от операции 606 к операции 608, где серверу отправляется второй запрос в отношении информации о службе-свидетеле. Информация о службе-свидетеле, среди прочего, идентифицирует, какие серверы в кластере обеспечивают службу-свидетель, с помощью которой можно зарегистрироваться на обеспечение уведомлений в отношении ресурса кластера. Запрос, отправляемый на операции 606, может быть отформатирован в соответствии с протоколом свидетеля, который отличается от протокола доступа к файлу, который используется на операциях 602-606.

На операции 610 принимается информация о службе-свидетеле. Информация о службе-свидетеле затем может использоваться для определения того, какой сервер в кластере обеспечивает службу-свидетель. Информация о службе-свидетеле используется на операции 612 для отправки запроса регистрации для регистрации на уведомления, касающиеся ресурса кластера. В одном варианте осуществления, ресурсом может быть сервер, с которым был установлен сеанс на операции 604 и через который осуществляется доступ к информации, используя запросы, отправляемые на операции 606. Запрос регистрации может указывать на то, что клиент желает принимать уведомления, касающиеся состояния сервера.

Поток 600 переходит от операции 612 к операции 614, где принимается уведомление, касающееся ресурса. В некоторых вариантах осуществления могут присутствовать дополнительные этапы, выполняемые в ответ на прием уведомления на этапе 614, такие как временная приостановка запросов доступа, повторное подключение к другому серверу в кластере и возобновление запросов доступа к другому серверу в кластере. После операции 614, на операции 616 отправляется запрос отмены регистрации. Поток 600 затем завершается на операции 618.

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

За операцией 654 следует операция 656, где принимаются запросы доступа к файлу. Запросы доступа к файлу могут быть запросами чтения или записи файловой информации, хранящейся на сервере. В вариантах осуществления, сообщения, отправляемые и принимаемые на операциях 652-656, отформатированы в соответствии с протоколом доступа к файлу, таким как некая версия SMB или версия NFS.

После операции 656 на операции 658 принимается запрос в отношении информации свидетеля. Этим запросом запрашивается информация свидетеля, касающаяся того, какие серверы в кластере серверов обеспечивают службу-свидетель. Поток 650 переходит к операции 660, где отправляется ответ, который включает в себя информацию свидетеля, с указаниями серверов в кластере сервера, которые обеспечивают службу-свидетель. Следует понимать, что запрос, принимаемый на операции 658, в варианте осуществления принимается от клиента, который отличается от клиента, отправляющего первый запрос (операция 652) и второй запрос (операция 658). Несмотря на то, что запросы, принимаемые в течение потока 650, отправляются разными клиентами, операции 652-668 в вариантах осуществления выполняются одним узлом.

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

После операции 664 поток переходит к операции 666, где отправляется уведомление, касающееся ресурса. Уведомление обеспечивает информацию, касающуюся состояния ресурса, который был указан в запросе регистрации, принятом на операции 662. В одном варианте осуществления уведомление может указывать, что сервер теперь находится в режиме офлайн. После операции 666 поток переходит к операции 668, где принимается запрос отмены регистрации. Запрос, принимаемый на операции 668, указывает на то, что предыдущая регистрация, такая как запрос регистрации, принятый на операции 662, должна быть отменена. Поток 650 завершается на операции 618.

Следует отметить, что в вариантах осуществления, операции 652-658 выполняются на одном сервере, а операции 660-664 выполняются на другом сервере. Например, операции 652-658 могут выполняться на первом сервере кластера серверов, а операции 660-664 на втором сервере кластера серверов. Тем не менее, в других вариантах осуществления один сервер может выполнять все операции 652-664, при этом операции 652-658 могут выполняться в отношении первого клиента, а операции 660-664 могут выполняться в отношении второго клиента. Другими словами, сервер может обслуживать запросы доступа к информации от первого клиента и также обеспечивать службу-свидетель второму клиенту.

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

В наиболее общей конфигурации система 700, как правило, включает в себя, по меньшей мере, один модуль 702 обработки данных и память 704. В зависимости от конкретной конфигурации и типа вычислительного устройства, память 704 может быть энергозависимой (такой как RAM), энергонезависимой (такой как ROM, флэш-память и т.д.) или неким сочетанием их двух. Данная наиболее общая конфигурация проиллюстрирована на Фиг. 7 штриховой линией 706. Системная память 704 хранит приложения, которые исполняются в системе 700. Например, память 704 может хранить информацию 720, касающуюся ресурсов, которые отслеживаются. Память 704 также может включать в себя регистрации 722 клиента на уведомления.

Используемое здесь понятие «машиночитаемый носитель информации» может включать в себя компьютерные носители данных. Компьютерные носители данных могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или по любой технологии для хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули или прочие данные. Все из системной памяти 704, съемного запоминающего устройства и несъемного запоминающего устройства 708 являются примерами компьютерных носителей данных (т.е. хранилища данных). Компьютерные носители данных могут включать в себя, но не в ограничительном смысле, RAM, ROM, электрически стираемое постоянное запоминающее устройство (EEPROM), флэш-память или иную технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или иные оптические запоминающие устройства, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитном диске или иные магнитные запоминающие устройства, либо любой другой носитель, который может использоваться для хранения информации и доступ к которому может быть осуществлен вычислительным устройством 700. Любой такой компьютерный носитель данных может быть частью устройства 700. Вычислительное устройство 700 также может иметь устройство(а) 714 ввода, такое как клавиатура, манипулятор типа мышь, перо, устройство ввода звука, устройство сенсорного ввода и т.д. Так же в состав может быть включено устройство(а) 716 вывода, такое как дисплей, громкоговоритель, принтер и т.д. Вышеупомянутые устройства являются примерами и могут использоваться другие.

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

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

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

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

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

2. Способ по п. 1, в котором ресурс представляет собой ресурс сети и первый узел принимает события от этого ресурса сети.

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

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

5. Способ по п. 1, в котором запрос на подключение к первому узлу и ответ, которым устанавливается сеанс для доступа к информации на первом узле, форматируются в соответствии с протоколом доступа к файлам.

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

7. Способ по п. 6, в котором протокол свидетеля использует вызов удаленных процедур (RPC) с протоколом управления передачей (TCP) в качестве транспорта.

8. Способ по п. 1, в котором информация об узлах идентифицирует множественные узлы, которые служат в качестве узлов-свидетелей.

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

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

11. Машиночитаемый носитель данных по п. 10, при этом упомянутым ресурсом является ресурс первого файлового сервера.

12. Машиночитаемый носитель данных по п. 10, при этом уведомление указывает отказ первого файлового сервера.

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

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

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

16. Машиночитаемый носитель данных по п. 15, при этом протокол доступа к файлам содержит версию протокола блока сообщений сервера (SMB).

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

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

19. Система по п. 18, в которой ресурс является ресурсом кластера и сервер принимает события от службы кластеров, работающей в кластере.

20. Система по п. 19, в которой уведомление указывает отказ упомянутого по меньшей мере одного ресурса.