ПРОЗРАЧНОЕ ВОССТАНОВЛЕНИЕ ПОСЛЕ ОТКАЗА Российский патент 2016 года по МПК H04L12/00 

Предшествующий уровень техники

[01] Серверные кластеры обычно используются для обеспечения восстановления после отказа и максимальной доступности информации для клиентов. Использование серверного кластера обеспечивает клиентам прозрачное восстановление после отказа так, что при любом сбое сервер остается прозрачным для приложений, требующих операций сервера на клиентах. Серверные кластеры могут быть полезны в совместно используемых файловых системах для обеспечения доступа нескольких клиентов в сети к файловой информации. Однако проблемы могут возникнуть, когда совместно используемая файловая система использует протокол с сопровождением состояния, такой как протокол блока серверных сообщений (SMB). Когда отказывает сервер в серверном кластере, некоторые протоколы с сопровождением состояния не обеспечивают способа для передачи состояния клиента с отказавшего сервера на альтернативный сервер. Кроме того, те протоколы доступа к файлам, которые обеспечивают сохранение некоторой информации о состоянии, не обеспечивают различающимся компонентам сохранение различающейся информации о состоянии.

[02] Именно в отношении этих и других соображений были выполнены данные варианты осуществления. Кроме того, хотя обсуждались относительно конкретные проблемы, следует понимать, что варианты осуществления не должны ограничиваться решением конкретных проблем, выявленных в уровне техники.

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

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

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

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

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

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

[07] На фиг.1 показана система, которая может использоваться для реализации вариантов осуществления.

[08] На фиг.2 показана блок-схема клиента и кластера файлового сервера, осуществляющих обмен данными с использованием протокола доступа к файлу в соответствии с некоторыми вариантами осуществления.

[09] На фиг.3 показан операционный поток для обеспечения защиты воспроизведения информации при восстановлении сервера после отказа в соответствии с некоторыми вариантами осуществления.

[10] На фиг.4 показан операционный поток для поддержания целостности файловой информации в соответствии с некоторыми вариантами осуществления.

[11] На фиг.5 приведена блок-схема вычислительной среды, подходящей для реализации вариантов осуществления.

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

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

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

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

[15] В соответствии с одним вариантом осуществления серверы 106А, 106В и 106С используются для обеспечения постоянной доступности файловой системы, хранящейся на кластере 106. Это достигается путем использования компонентов клиентов 102 и 104 и серверов 106А, 106В и 106С для сохранения информации о состоянии, которая может использоваться для восстановления сеанса между клиентами 102 и 104 и кластером 106 при сбое сети 108 или отказе одного из серверов 106А, 106В и 106С. Как подробнее описано ниже, сохранение информации о состоянии обеспечивает клиентам 102 и 104 согласованный доступ к файлам и прозрачное восстановление после отказа для приложений, работающих на клиентах 102 и 104.

[16] В вариантах осуществления каждый сервер кластера 106, например 106А, 106В, 106С, обеспечивает доступ клиентов к файловой информации и выполнен с возможностью обеспечивать постоянную доступность файловой информации для клиентов. Чтобы проиллюстрировать один вариант осуществления, клиент 102 может послать запрос на установление сеанса с сервером кластера 106. Например, клиент 102 может установить сеанс с сервером 106A для доступа к совместно используемой файловой системе, хранящейся на серверном кластере 106. В качестве части процесса установления сеанса клиент 102 может использовать протокол доступа к файлу. В вариантах осуществления протокол доступа к файлу является версией сетевой файловой системы (NFS) или протоколом блока серверных сообщений (SMB).

[17] Установление сеанса может включать в себя обмен некоторым количеством согласовательных запросов и ответов, передаваемых между клиентом 102 и сервером 106A. В версиях протокола блока серверных сообщений (SMB) имеются специально определенные пакеты согласования, которые используются для согласования точной версии протокола, который будет использоваться в процессе сеанса, а также для объявления друг другу функциональных возможностей, например, как клиента 102, так и, например, сервера 106А. В одном варианте осуществления пакеты согласования могут содержать указание на то, что сервер 106A является частью кластера, например кластера 106. Это позволяет клиенту узнавать о том, что сервер 106 способен обеспечить согласованный доступ или, другими словами, возможности прозрачного восстановления после отказа.

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

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

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

[21] В какой-то момент клиент 102 может отключиться от сервера. Отключение может быть вызвано, например, сбоем сети или поломками. Как вариант отключение может произойти из-за отказа сервера 106A. В тех вариантах осуществления, которые включают в себя сбой сети, клиент 102 может обнаружить, что отключение произошло, и ждать, когда сеть станет доступной для восстановления соединения с сервером 106А. В других вариантах осуществления после того, как клиент 102 обнаруживает неисправность, он посылает запрос на восстановление соединения с кластером 106, который обеспечивает, чтобы сервер, обеспечивающий восстановление после отказа, обработал запрос на восстановление соединения.

[22] В любом случае клиент 102 посылает запрос на восстановление соединения. Запрос содержит идентификатор дескриптора. Сервер 106А или альтернативный сервер (106B или 106C) возвратит информацию о состоянии, основанную на идентификаторе дескриптора, восстановит предыдущее состояние с помощью информации о состоянии, а также пошлет клиенту ответ, указывающий, что восстановление соединения выполнено успешно. В некоторых вариантах осуществления восстановление соединения может оказаться невозможным в случае, если информация о предыдущем состоянии была потеряна или недоступна по другой причине. В данных ситуациях сервер может интерпретировать запрос на восстановление соединения как запрос на установление сеанса и ответить соответствующим образом.

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

[24] В некоторых вариантах осуществления, чтобы обеспечить прозрачное восстановление после отказа для приложений клиента 102, может использоваться информация о состоянии, сохраняемая на клиенте 102. То есть сервер 106A (или сервер, обеспечивающий восстановление после отказа) может не отвечать за сохранение всей информации о состоянии, которая необходима, чтобы восстановить состояние после возобновления соединения. В некоторых вариантах осуществления за восстановление определенного состояния может отвечать клиент. Например, если запросы на считывание файловой информации были посланы перед отключением, сервер может не нести ответственность за сохранение информации о состоянии в отношении запросов на считывание. Когда происходит возобновление соединения, клиент может нести ответственность за повторные посылки запросов на считывание. Дополнительное описание вариантов осуществления, в которых информация о состоянии восстанавливается другими компонентами, описана более подробно ниже со ссылкой на фиг.2.

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

[26] Теперь обратимся к фиг.2, где показана блок-схема среды 200 с клиентом 202, клиентом 204 и серверным кластером 206 с тремя серверами (сервер 1, сервер 2 и сервер 3). Также показано файловое хранилище 210, где файловая система хранит файловую информацию, и хранилище 212, где информация о состоянии может сохраняться на одном или более серверах из сервера 1, сервера 2 и сервера 3.

[27] Как показано на фиг.2, каждый из клиента 202 и клиента 204 содержит приложение, которое может запрашивать файловую информацию. Приложение может быть, например, текстовым приложением, приложением электронных таблиц, приложением браузера или любым другим приложением, которое запрашивает доступ к файлам. В варианте осуществления, показанном на фиг.2, файлы размещены в совместно используемой файловой системе, хранящейся в файловом хранилище 210. Каждый из клиента 202 и клиента 204 дополнительно содержит модуль переадресации запросов (редиректор), который перенаправляет запрос файлов со стороны приложений на файловый сервер, обеспечивающий доступ к общей файловой системе. Модули переадресации запросов обмениваются данными с файловыми серверами, используя протокол доступа к файлу. В некоторых вариантах осуществления протоколом доступа к файлу может быть версия NFS или протокола блока серверных сообщений (SMB). В целях иллюстрации фиг.2 будет описана в предположении, что модули переадресации запросов клиента 202 и клиента 204 обмениваются данными с файловыми серверами, используя версии протокола блока серверных сообщений, такого как SMB 2.0. Варианты осуществления, однако, не ограничиваются использованием протокола блока серверных сообщений.

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

[29] Использование протокола блока серверных сообщений для установления сеанса между клиентом и сервером начинается с модуля переадресации запросов, например модуля переадресации запросов на клиенте 202, посылкой запроса согласования файловому серверу, такому как сервер 1 в серверном кластере 206. Модуль переадресации запросов и файловый сервер обмениваются пакетами согласований, чтобы согласовать версию блока серверных сообщений, которая будет использоваться для сеанса. Дополнительно, во время согласования можно также обмениваться информацией о функциональных возможностях. В одном варианте осуществления файловый сервер может включать в состав ответного пакета согласования, который посылается от файлового сервера клиенту, флажок функциональных возможностей для указания клиенту на то, что файловый сервер поддерживает использование постоянных дескрипторов. В некоторых вариантах осуществления это делается в ситуациях, в которых файловый сервер является частью кластера, который может обеспечить согласованный доступ для клиента, путем аварийного переключения на другой сервер в кластере. В других вариантах осуществления автономные серверы также могут иметь такую возможность для того, чтобы иметь возможность повторно подключиться к клиентам, когда происходит сбой сети.

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

struct SMB2_DURABLE_HANDLE_ EQUEST_V2 {

ULONG Flags;

GUID Handheld; // клиент предоставляет уникальный идентификатор

// (ID) для данного дискриптора (используется для обнаружения

// повторных запросов).

ULONG Timeout; // время ожидания в секундах

ULONG Reserved; // должен задаваться как ноль }.

[31] В вариантах осуществления в ответ на запрос файловый сервер на сервере 1 отвечает выдачей постоянного дескриптора и предоставлением файлового идентификатора модулю переадресации запросов на клиенте 202. Тогда модуль переадресации запросов клиента имеет возможность доступа к информации из файла, которому соответствует постоянный дескриптор и идентификатор файла. В некоторых вариантах осуществления модуль переадресации запросов может запросить постоянный дескриптор для каталога. То есть вместо постоянного дескриптора, соответствующего отдельному файлу, дескриптор может соответствовать каталогу.

[32] В дополнение к файловому серверу на сервере 1, который выдает постоянный дескриптор, файловый сервер также сохраняет информацию о состоянии в запоминающем устройстве 212. Информация о состоянии может сохраняться в привязке к идентификатору дескриптора, сгенерированному модулем переадресации запросов, а также может сохраняться в привязке к идентификатору файла, предоставленному модулю переадресации запросов на клиенте 202. Как подробнее описано ниже, файловый сервер может непосредственно сохранять информацию о состоянии как информацию 216 о состоянии файлового сервера. В других вариантах осуществления файловый сервер может использовать фильтр возобновления для сохранения информации о состоянии. Однако в других вариантах осуществления файловый сервер может непосредственно сохранять информацию о состоянии, а также использовать фильтр возобновления для сохранения другой информации о состоянии.

[33] После того как взаимодействие завершено, модуль переадресации запросов посылает запросы на доступ к файлу используя, например, версию протокола блока серверных сообщений. В некоторых вариантах осуществления файловый сервер сохраняет информацию о состоянии для каждого из запросов, принятых от модуля переадресации запросов клиента. В некоторый момент времени может произойти разъединение между клиентом 202 и сервером 1, например в результате сбоя сети или отказа сервера 1. Клиент 202 может переустановить соединение с сервером 1, если отказ произошел из-за сбоя сети или после отказа произошло восстановление сервера (одного из сервера 2 или сервера 3). Как часть процесса переустановления соединения, клиент 202 может послать запрос на переустановление соединения, который будет содержать ранее предоставленный идентификатор дескриптора, а также идентификатор файла, предоставленный файловым сервером при согласовании первоначального сеанса. Поскольку информация о состоянии доступна в запоминающем устройстве 212, которое доступно для всех серверов в серверном кластере 206, сервер, обеспечивающий восстановление после отказа, может идентифицировать информацию о предыдущем состоянии, основываясь на идентификаторе дескриптора и/или идентификаторе файла, предоставляемых клиентом в запросе на переустановление соединения. В данных вариантах осуществления, когда клиент пытается переустановить соединение с сервером 1, файловый сервер на сервере 1 также может осуществить доступ к информации о состоянии, содержащейся в запоминающем устройстве 212, чтобы восстановить предыдущее состояние сеанса с клиентом.

[34] Как было отмечено выше, в некоторых вариантах осуществления различные компоненты среды 200 отвечают за сохранение различных типов информации о состоянии, чтобы обеспечить восстановление состояния клиентов, которые отключены. Как показано на фиг.2, каждый из файловых серверов содержит фильтр возобновления. Фильтр возобновления используется в вариантах осуществления для сохранения информации о состоянии для восстановления состояния, когда клиент повторно возобновляет соединение. Фильтр возобновления не зависит от конкретного протокола доступа к файлу, используемого файловым сервером. В вариантах осуществления, чтобы сохранять информацию о конкретном состоянии, файловый сервер сначала регистрируется в фильтре возобновления. После регистрации файловый сервер может передавать информацию о состоянии на фильтр возобновления, который сохраняет информацию о состоянии как информацию о состоянии фильтра 214 возобновления в запоминающем устройстве 212. В дополнении к информации о состоянии фильтра 214 возобновления сервер может сохранять отдельную информацию о состоянии, показанную как информация 216 о состоянии файлового сервера, в запоминающем устройстве 212. В вариантах осуществления другая информация о состоянии может сохраняться в других местах хранилища, нежели информация о состоянии фильтра 214 возобновления. Информация 216 о состоянии файлового сервера и информация о состоянии фильтра 214 возобновления могут сохраняться любым подходящим способом, например, в файлах регистрации. Как подробнее описано ниже, в вариантах осуществления типы информации о состоянии, которые хранятся в фильтре возобновления, являются общей информацией, в то время как информация о сервере является более конкретной информацией о состоянии.

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

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

[37] В одном варианте осуществления, в котором протокол блока серверных сообщений используется для осуществления связи между модулем переадресации запросов и файловым сервером, протокол SMB может обеспечивать, чтобы конкретные состояния сохранялись различными компонентами, показанными в среде 200. В одном варианте осуществления операции, доступные с использованием протокола SMB, разделены на три группы. Информация о состоянии, связанная с каждой группой, сохраняется различными компонентами.

[38] Первую группу можно отнести, в целом, к неидемпотентным операциям, что означает, что если эти операции повторно выполняются, например повторно применяются к файлу после того, как уже применялись перед отключением клиента, это создает несогласованное состояние на файловом сервере. В версиях протокола SMB, блокировки диапазонов байтов представляют пример операций, требующих обнаружения повторного выполнения, потому что вышеуказанные блокировки заносятся в стек и извлекаются из стека. Другие примеры включают в себя добавление записей и открытий/созданий, которые могут менять состояние диска, например, за счет создания новых файлов или перезаписи существующих файлов. В вариантах осуществления состояние, соответствующее данным типам операций, сохраняется файловым сервером, потому что файловый сервер должен распознавать, что эти операции выполняются повторно. В варианте осуществления, показанном на фиг.2, состояние, связанное с этими операциями, будет сохраняться файловыми серверами, которые находятся в каждом из сервера 1, сервера 2 и сервера 3, в хранилище 212, в качестве части информации 216 о состоянии файлового сервера. Идентификатор дескриптора, предоставленный клиенту во время согласования сеанса, как описано выше, используется в некоторых вариантах осуществления для идентификации того, что запрос является повтором предыдущего запроса.

[39] Вторая группа операций относится к операциям открытия данных. Такими операциями могут быть запросы на чтение, запись, исполнение или удаление информации в файле. Чтобы иметь возможность реализовывать режимы совместного использования и предотвращать воздействие других клиентов на уже имеющихся клиентов, состояние, относящееся к операциям открытия, должно сохраняться на стороне сервера в соответствии с вариантами осуществления. Состояние, относящееся к операциям открытия, также сохраняется на стороне сервера, чтобы блокировать локальные операции от воздействия с постоянными дескрипторами. Например, предотвращается изменение или иное воздействие со стороны программ, исполняемых на узлах кластера, в отношении дескрипторов, зарезервированных для клиентов. В вариантах осуществления состояние, относящееся к этим типам операций, сохраняется фильтром возобновления. Как отмечено выше, фильтр возобновления в вариантах осуществления не является специализированным для протокола SMB, но может также использоваться, когда файловый сервер использует другой протокол доступа к файлам, такой как NFS. В варианте осуществления, показанном на фиг.2, фильтр возобновления на каждом из сервера 1, сервера 2 и сервера 3 сохраняет информацию о состоянии для операций открытия в хранилище 212 как часть информации о состоянии фильтра 214 возобновления.

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

[41] В соответствии с вариантами осуществления состояние аренды не нуждается в постоянном поддержании на сервере, потому что фильтр возобновления блокирует все операции создания для данного файла, в то время как клиенты возобновляют свои дескрипторы после восстановления после отказа. Это неявным образом обеспечивает гарантию того, что аренды дескрипторов никогда не будут потеряны во время процесса восстановления после отказа, если клиенты переустанавливают соединение/возобновляют свои дескрипторы в течение периода отсрочки. Другими словами, клиенты всегда получают назад свои аренды дескрипторов во время фазы возобновления. Более того, эксклюзивные аренды, такие как аренды чтение/запись и чтение/запись/дескриптор в каждый момент времени предоставляются только одному клиенту. Это означает, что отсутствуют другие открытия данных для файла со стороны любого другого клиента. Так, во время восстановления после отказа, поскольку фильтр возобновления не разрешает новые операции создания в отношении файла, пока клиент, имеющий эксклюзивную аренду, не возобновит все свои дескрипторы, существует гарантия того, что клиент получит обратно свою эксклюзивную аренду. Совместно используемые аренды, которые не требуют подтверждения, такие как аренда чтения, могут утрачиваться в любое время без ведома либо сервера, либо фильтра возобновления, поскольку используемая файловая система разрешает продолжение операции, вызвавшей нарушение. Для таких аренд клиент в вариантах осуществления предполагает, что аренда нарушается после восстановления после отказа, и очищает свой кэш для предотвращения считывания устаревших данных. Состояние для операций в третьей группе может, следовательно, быть восстановлено клиентом без какой-либо дополнительной поддержки со стороны сервера. В варианте осуществления, показанном на фиг.2, модули переадресации запросов на клиентах 202 и 204 сохраняют информацию о состоянии для третьей группы операций.

[42] В процессе работы среда 200 позволяет приложениям на клиентах 202 и 204 запрашивать доступ к файлам, которые хранятся в файловом запоминающем устройстве 210 в совместно используемой файловой системе. Приложения могут прозрачным образом запрашивать файловую информацию. Модули переадресации запросов клиентов устанавливают сеанс с одним из серверов в кластере 206, как описано выше, запрашивая постоянный дескриптор, так что модуль переадресации запросов может вновь подсоединиться и восстановить сеанс, если произошло отключение. Файловый сервер сохраняет информацию о состоянии в хранилище 212 либо непосредственно как информацию 216 о состоянии файлового сервера, либо как информацию 214 о состоянии фильтра возобновления, используя фильтр возобновления. В некоторых вариантах осуществления клиент также сохраняет некоторую информацию о состоянии. В случае отключения модуль переадресации запросов может запросить возобновление соединения с файловым сервером или с сервером, обеспечивающим восстановление после отказа. Информация о состоянии, сохраненная на стороне сервера, например, в хранилище 212, и на стороне клиента, может затем использоваться для восстановления предыдущего состояния клиента. Все это происходит прозрачным образом для приложений на клиентах 202 и 204.

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

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

[45] Фиг.3 и 4 иллюстрируют операционные потоки 300 и 400 в соответствии с вариантами осуществления. Операционные потоки 300 и 400 могут выполняться в любой приемлемой компьютерной среде. Например, операционные потоки могут выполняться системами и окружениями так, как показано на фиг.1 и 2. Следовательно, описание операционных потоков 300 и 400 может относиться, по меньшей мере, к одному из компонентов на фиг.1 и 2. Однако любая такая ссылка на компоненты на фиг.1 и 2 делается только в описательных целях, и следует понимать, что реализации по фиг.1 и 2 не являются ограничивающими программными средствами для операционных потоков 300 и 400.

[46] Кроме того, хотя операционные потоки 300 и 400 показаны и описаны последовательно в определенном порядке, в других вариантах осуществления операции могут выполняться в другом порядке, несколько раз и/или параллельно. Кроме того, одна или более операций могут пропускаться или объединяться в некоторых вариантах осуществления.

[47] Операционный поток 300 иллюстрирует этапы обеспечения защиты от повторения на сервере при восстановлении после отказа. В вариантах осуществления поток 300, показанный на фиг.3, может выполняться файловым сервером, то есть выполняться сервером, который является частью серверного кластера, например сервером 1, сервером 2 и сервером 3 кластера 206 (фиг.2). Поток 300 начинается с операции 302, где принимается запрос на подсоединение к файловому серверу. Запрос, принятый в операции 302, является запросом на установление сеанса с файловым сервером для доступа к файловой информации, сохраняемой в совместно используемой файловой системе, доступной через файловый сервер. Запрос может быть послан клиентом, например клиентами 202 и 204 (фиг.2). После операции 302 поток 300 переходит к операции 304, где посылается ответ, указывающий, что сеанс был установлен. В некоторых вариантах осуществления запрос и ответ, посланные в операциях 302 и 304, могут быть несколькими сообщениями, которыми обмениваются клиент и сервер для согласования сеанса. Обмен сообщениями может включать в себя обмен функциональными возможностями, включая возможность файлового сервера обеспечить постоянные дескрипторы.

[48] Операционный поток переходит от операции 304 к операции 306, где принимается второй запрос на постоянный дескриптор. Запрос посылается клиентом и содержит идентификатор дескриптора, сгенерированный клиентом. Идентификатор дескриптора используется в вариантах осуществления сервером для сохранения информации о состоянии относительно сеанса, установленного между клиентом и файловым сервером. В рамках сохранения информации о состоянии в вариантах осуществления поток 300 может включать в себя операцию 308, в которой файловый сервер регистрируется в фильтре возобновления для того, чтобы сохранить некоторую информацию о состоянии. В вариантах осуществления фильтр возобновления располагается между уровнем протокола и используемой системой хранения и может использоваться в вариантах осуществления для сохранения информации о состоянии сеанса, установленного между файловым сервером и клиентом.

[49] В операции 310 информация о состоянии сохраняется в соответствии с идентификатором дескриптора. Информация о состоянии может сохраняться в любой подходящей форме, например в таблице, базе данных или файле регистрации. Запоминающее устройство является постоянным и доступным файловому серверу, чтобы при необходимости восстановить состояние. Информация о состоянии может сохраняться непосредственно файловым сервером. В других вариантах осуществления поток 300 включает в себя операцию 312, в которой для сохранения информации о состоянии используется фильтр возобновления. Как указано выше, для сохранения информации о состоянии в некоторых вариантах осуществления файловый сервер может регистрироваться в фильтре возобновления.

[50] Поток 300 переходит от операции 312 к операции 314, где клиенту посылается ответ, предоставляющий доступ к файлу с использованием постоянного дескриптора. Ответ содержит идентификатор файла, который в ответе обеспечивается файловым сервером и также сохраняется в привязке к информации о состоянии, сохраненной в операции 310, и опционально в операции 312.

[51] Поток 300 затем переходит к операции 316, где в необязательном порядке принимается ряд запросов доступа к файлу. Запросы доступа к файлу могут включать в себя перечень файловых операций, которые надо выполнить при работе с файлом, связанным с постоянным дескриптором. Операции могут быть, например, такие как открытие для чтения/записи данных, перечисление атрибутов, запросы аренд для обеспечения возможности локального кэширования данных, или другие операции доступа к файлу. Различные состояния, связанные с получением запросов доступа к файлу в операции 316, могут обновляться в операции 318. То есть когда эти запросы удовлетворяются для клиента, информация о состоянии, сохраненная в предыдущих операциях (310 и 312), обновляется для отображения дополнительной информации о состоянии.

[52] После операции 318 существует ряд дополнительных операций, определенных в блоке 319. Эти операции могут выполняться в результате отключения клиента от файлового сервера. Как можно понять, в ситуациях, когда файловый сервер, который первоначально выполнял операции 302-318, из-за отказа оказывается недоступным, дополнительные операции в блоке 319 выполняются сервером, обеспечивающим восстановление после отказа. В других вариантах осуществления, в которых отказ является результатом проблемы с сетью, операции в блоке 319 выполняются тем же файловым сервером.

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

[54] Поток 300 переходит от операции 320 к операции 322, где информация о состоянии используется для переустановления соединения с клиентом и его предыдущего состояния. После операции 322 поток переходит к операции 324, где принимаются новые запросы доступа к файлу. Операция 324, следовательно, может включать в себя ряд операций, где каждая включает в себя прием от клиента запроса доступа к файлу.

[55] Некоторые из запросов, принятых в операции 324, могут быть повторами предыдущих запросов, посланных до прекращения соединения между файловым сервером и клиентом. В результате некоторые из этих операций при их повторном применении на файловом сервере могут создать несогласованное состояние. В операции 326 обнаруживаются новые запросы доступа к файлу, являющиеся повторами. В вариантах осуществления эта операция может включать в себя идентификацию запросов доступа к файлу при помощи идентификатора дескриптора, ранее предоставленного клиентом. После того как в операции 326 обнаруживается повтор, запросы соответствующим образом обрабатываются в операции 328. То есть если бы повторные операции создали несогласованное состояние на файловом сервере, они бы могли быть проигнорированы при условии успешного выполнения предыдущей операции. Альтернативно, если предыдущая операция не была успешно выполнена, то может применяться повторная операция. Затем поток 300 заканчивается на 330.

[56] Операционный поток 400 иллюстрирует этапы осуществления поддержки согласованной доступности. В вариантах осуществления поток 400 может выполняться модулями переадресации запросов на клиентах, таких как клиенты 202 и 204 (фиг.2), которые осуществляют взаимодействие с файловым сервером для доступа к файлам в совместно используемой файловой системе. В вариантах осуществления клиент осуществляет взаимодействие с файловым сервером, используя протокол доступа к файлам, такой как версия протокола SMB или версия NFS.

[57] Поток 400 начинается с операции 402, где посылается запрос на подсоединение к файловому серверу. Запрос, посланный при операции 402, является запросом на установление сеанса с файловым сервером для доступа к файловой информации, хранящейся в совместно используемой файловой системе, доступной через файловый сервер. Запрос может посылаться файловым сервером на сервер, например сервер 1, сервер 2 и сервер 3, являющийся частью серверного кластера (фиг.2). Запрос форматируется в соответствии с протоколом доступа к файлам, таким как версия протокола SMB или NFS.

[58] После операции 402 поток 400 переходит к операции 404, где принимается ответ, указывающий на то, что сеанс установлен. В некоторых вариантах осуществления операции 402 и 404 могут быть частью ряда сообщений, которыми обмениваются клиент и сервер для согласования сеанса. Обмен сообщениями может включать в себя обмен функциональными возможностями, включающими в себя возможность файлового сервера обеспечивать постоянные дескрипторы.

[59] Операционный поток переходит от операции 404 к операции 406, где посылается запрос на постоянный дескриптор. В результате процесса согласования (операции 402 и 404) клиент может быть уведомлен о том, что файловый сервер способен обеспечить постоянные дескрипторы. Чтобы гарантировать, что состояния приложений на клиенте могут быть восстановлены после разъединения и возобновления соединения, клиент может запросить постоянный дескриптор в операции 406. Запрос включает в себя идентификатор дескриптора, сгенерированный клиентом.

[60] Поток 400 переходит от операции 406 к операции 408, где принимается ответ, предоставляющий доступ к файлу при помощи постоянного дескриптора. Ответ содержит идентификатор файла, который в ответе предоставляется файловым сервером.

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

[62] Поток 400 переходит от операции к операции 410 412, где клиент посылает ряд запросов доступа к файлу. Операция 412, таким образом, может включать в себя посылку нескольких запросов на выполнение файловых операций согласно вариантам осуществления. Вслед за операцией 412 выполняется операция 414, где информация о состоянии клиента обновляется. Понятно, что операция 414 может происходить много раз, а именно каждый раз, когда при выполнении операции 412 клиент посылает запрос доступа к файлу.

[63] От операции 414 поток переходит к операции 416, где обнаруживается отключение. Обнаружение может происходить вследствие истечения лимита времени ожидания, уведомления о событии или некоторыми другими путями. После операции 416 посылается запрос на восстановление соединения и переустановление сеанса, ранее установленного с файловым сервером при выполнении операции 418. Запрос включает в себя дескриптор файла, ранее предоставленный файловым сервером, а также идентификатор дескриптора, который использовался клиентом при запросе постоянного дескриптора.

[64] Поток 400 переходит от операции 418 к операции 420, где определяется, что восстановление соединения прошло успешно. После операции 420 поток переходит к операции 422, где информация о состоянии, сохраненная на клиенте, используется для восстановления предыдущего состояния. Операция 422 может содержать передачу ряда различных запросов, включая чтение, запись, перечисление, запросы на блокировки или другие операции для восстановления предыдущего состояния. Поток переходит от операции 422 к операции 424, где клиент посылает новые запросы на доступ к файлу. Поток заканчивается на этапе 426.

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

[66] В своей самой базовой конфигурации система 500 обычно включает в себя, по меньшей мере, один процессорный блок 502 и память 504. В зависимости от точной конфигурации и типа вычислительного устройства память 504 может быть энергозависимой (такой как ОЗУ), энергонезависимой (такой как ПЗУ, флэш-память и т.д.) или некоторой комбинацией этих двух. Данная наиболее общая конфигурация показана на фиг.5 пунктирной линией 506. В вариантах осуществления системная память 504 сохраняет приложения, такие как приложение 523, которое запрашивает доступ к файловой информации. Системная память 504 также включает в себя модуль 522 переадресации запросов, который перехватывает запрос и передает его на файловый сервер в соответствии с вариантами осуществления.

[67] Термин «считываемый компьютером носитель», используемый в данном документе, может включать в себя компьютерные носители данных. Компьютерные носители данных могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные. Системная память 504, съемное запоминающее устройство и несъемное запоминающее устройство 508 являются примерами компьютерных носителей данных (то есть устройств памяти). В вариантах осуществления данные, такие как, например, информация 520 о состоянии, сохраняются. Компьютерные носители данных могут включать в себя, но не в ограничительном смысле, ОЗУ, ПЗУ, электрически стираемое ПЗУ (EEPROM), флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другие оптические запоминающие устройства, магнитные кассеты, магнитную ленту, накопитель на магнитных дисках или другие магнитные запоминающие устройства или любой другой носитель, который может использоваться для хранения информации и к которому может быть осуществлен доступ компьютерной системой 500. Любой такой компьютерный носитель данных может быть частью компьютерной системы 500. Компьютерная система 500 может также иметь устройство(а) 514 ввода, такое как клавиатура, мышь, перо, устройство ввода звука, устройство сенсорного ввода и т.д. Устройство(а) 516 вывода, такое как дисплей, динамики, принтер и т.д., также могут быть включены в ее состав. Вышеупомянутые устройства являются примерами, но и другие могут использоваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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