Прозрачное восстановление после отказа

Прозрачное восстановление после отказа

Иллюстрации

Показать все

Реферат

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

[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) или сетевую файловую систему