ВОССТАНОВЛЕНИЕ ПОСЛЕ СБОЯ КЛАСТЕРНОГО КЛИЕНТА Российский патент 2016 года по МПК G06F15/16 

Уровень техники

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

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

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

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

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

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

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

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

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

[0008] Фиг. 1 иллюстрирует систему, которая может быть использована для того, чтобы реализовывать варианты осуществления, описанные в данном документе.

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

[0010] Фиг. 3 является вариантом осуществления способа, который может выполнять клиент для того, чтобы получать непрерывный доступ к ресурсу в кластерном окружении.

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

[0012] Фиг. 5 иллюстрирует блок-схему вычислительного окружения, подходящего для реализации вариантов осуществления.

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

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

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

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

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

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

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

[0019] Фиг. 1 иллюстрирует систему 100, которая может быть использована для того, чтобы реализовывать некоторые варианты осуществления, раскрытые в данном документе. Система 100 включает в себя клиентский кластер 102 и серверный кластер 106. Клиентский кластер включает в себя несколько узлов, к примеру клиенты 102A и 102B. Клиенты 102A и 102B могут быть устройством или приложением, постоянно размещающимся в клиентском кластере 102. Клиентский кластер 102 может обмениваться данными с серверным кластером 106 через сеть 108. В вариантах осуществления сеть 108 может быть Интернетом, WAN, LAN или любым другим типом сети, известной в области техники. Серверный кластер 106 сохраняет ресурсы, к которым осуществляется доступ посредством приложений в клиентском кластере 102 (например, приложений, постоянно размещающихся в клиенте 102A или клиенте 102B). В вариантах осуществления клиент (например, клиент 102A) может устанавливать сеанс с кластером 106, чтобы осуществлять доступ к ресурсам на кластере 106 от имени приложения, постоянно размещающегося в клиенте. Хотя на фиг. 1 клиентский кластер 102 включает в себя только два клиента (например, клиент 102A и клиент 102B), специалисты в данной области техники должны принимать во внимание, что любое число клиентов может быть включено в клиентский кластер 102.

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

[0021] В вариантах осуществления клиентский кластер 102 предоставляет механизмы восстановления после сбоя, которые дают возможность клиенту мигрировать с первого клиентского узла на второй клиентский узел в случае ошибки или сбоя, возникающего в первом клиентском узле. Специалисты в данной области техники должны принимать во внимание, что любой тип механизма восстановления после сбоя может использоваться в системах и способах, раскрытых в данном документе. Способы и системы, раскрытые в данном документе, могут использоваться для того, чтобы не допускать чрезмерной задержки, когда приложение пытается восстанавливать доступ к ресурсу, мигрирующему из одного клиента на другой (например, из клиента 102A на клиент 102B) в случае восстановления после сбоя. В вариантах осуществления идентификатор экземпляра приложения, идентифицирующий приложение, осуществляющее доступ к ресурсу, может быть ассоциирован с ресурсом. Идентификатор экземпляра приложения может быть глобально уникальным идентификатором (GUID), который ассоциирован с приложением, действием, выполняемым посредством приложения, или дочерним процессом приложения. Например, в одном варианте осуществления приложение может быть ассоциировано с идентификатором экземпляра приложения, который является GUID. В другом варианте осуществления идентификатор экземпляра приложения может быть ассоциирован с конкретной операцией или действием, выполняемым посредством приложения. Например, если приложение выдает два различных запроса на открытие для двух различных файлов, каждый запрос на открытие может иметь собственный идентификатор экземпляра приложения. В еще одном другом варианте осуществления идентификатор экземпляра приложения может быть ассоциирован с одним или более дочерних процессов приложения. Как должно быть очевидным для специалистов в данной области техники из вариантов осуществления, описанных в данном документе, ассоциирование идентификатора экземпляра приложения для приложения с одним или более дочерних процессов позволяет дочерним процессам осуществлять доступ к ресурсу, если ресурс переключается в заблокированное или защищенное состояние, которое принадлежит приложению. В вариантах осуществления идентификатор экземпляра приложения может отправляться посредством клиента при или после отправки запроса на ресурс.

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

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

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

[0025] До того, как запросчик завершает операции на ресурсе, возникает ошибка, которая приводит к тому, что клиент 102A сбоит или иным образом теряет свое соединение с ресурсом. Поскольку клиент-запросчик завершает работу, он не прекращает управление ресурсом. Таким образом, ресурс может оставаться в защищенном или заблокированном состоянии. Запросчик или клиентский кластер 102 может использовать механизм восстановления после сбоя для того, чтобы выполнять миграцию запросчика из клиента 102A на клиент 102B. После того, как операция восстановления после сбоя закончена, клиент 102B может повторно подключаться к серверному кластеру 106 от имени запросчика. Клиент 102B может повторно подключаться к серверу 106A или устанавливать новое соединение с любым другим сервером в серверном кластере 106 (например, с сервером 106B или 106C). В примерном случае клиент 102B повторно подключается к серверу 106A. После повторного подключения клиент 102B может отправлять второй запрос на то, чтобы осуществлять доступ к ресурсу, от имени запросчика. Как отмечено выше, поскольку запросчик не прекращает управление ресурсом, ресурс при этом может быть в заблокированном или защищенном состоянии. Чтобы осуществлять доступ к ресурсу без ожидания автоматического изменения состояния ресурса посредством сервера, например, через операцию тайм-аута, запросчик снова может предоставлять идентификатор экземпляра приложения во втором запросе. Сервер 106A сравнивает идентификатор экземпляра приложения, предоставленный во втором запросе, с идентификатором экземпляра приложения, ассоциированным с ресурсом. Например, посредством сравнения идентификатора экземпляра приложения, принимаемого или иным образом ассоциированного со вторым запросом, с идентификатором экземпляра приложения, который сервер 106A ассоциирует с ресурсом. Ассоциированный идентификатор экземпляра приложения может быть сохранен в локальном кэше или таблице сервера 106A, либо он может быть сохранен в другом месте в серверном кластере 106. Если идентификатор экземпляра приложения, сохраненный в кэше, совпадает с идентификатором экземпляра приложения, который ассоциирован с ресурсом, сервер 106A признает недействительным или иным образом освобождает ресурс и дает возможность клиенту 102B снова осуществлять доступ к ресурсу от имени запросчика без ожидания высвобождения ресурса посредством некоторого другого механизма (например, посредством истечения тайм-аута защищенного или заблокированного состояния). Если идентификаторы экземпляров приложений не совпадают, клиент 102B должен ожидать освобождения ресурса до осуществления доступа к нему.

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

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

[0028] Обращаясь теперь к фиг. 2, чертеж иллюстрирует блок-схему программного окружения 200, показывающую кластер 201 клиентских узлов с несколькими клиентскими узлами (например, клиентами 202 и 204) и кластер 206 серверных узлов с несколькими серверными узлами (например, с узлом 1 208 и узлом 2 216). В вариантах осуществления клиент 202 запрашивает то, чтобы осуществлять доступ к ресурсу, к примеру к ресурсу 226, в кластерном серверном окружении 206 от имени запросчика. Кластер 201 клиентских узлов может представлять собой клиентский кластер, к примеру клиентский кластер 102 (фиг. 1). Хотя не проиллюстрировано, клиентский кластер может содержать более двух клиентов. Кластер 206 серверных узлов может представлять собой серверный кластер, к примеру серверный кластер 106 (фиг. 1), либо может представлять собой любой другой тип кластерного окружения, такого как, но не только, виртуальная сеть. Ресурс 226 может быть сохранен в хранилище 228 данных, которое является частью кластерного окружения. Хотя не показано, в альтернативных вариантах осуществления хранилище 228 данных может не быть частью кластерного окружения, но может подключаться к кластерному окружению по сети. Примеры такой сети включают в себя, но не только, Интернет, WAN, LAN или любой другой тип сети, известной в области техники. В еще дополнительных вариантах осуществления хранилище данных может быть частью узла (например, устройства), который является частью кластера 206.

[0029] Кластер 206 серверных узлов может включать в себя один или более узлов, к примеру узел 1 208 и узел 2 216. Хотя только два кластера узлов проиллюстрированы на фиг. 2, любое число кластеров узлов может быть включено в кластерное окружение 206. В вариантах осуществления кластеры 208 и 216 узлов допускают прием запроса на выполнение операции и/или предоставление разрешения на доступ к ресурсу 226. В вариантах осуществления ресурс 226 может быть файлом, объектом, приложением, данными или любым другим типом ресурса, сохраненного или доступного посредством узла в кластере 206 узлов или посредством автономного сервера.

[0030] В вариантах осуществления клиент отправляет начальный запрос 222 в кластерное окружение 206. Как проиллюстрировано на фиг. 2, начальный запрос 222 может отправляться посредством клиента 202 и приниматься посредством узла 1 208. Тем не менее, в альтернативных вариантах осуществления начальный запрос 222 может отправляться посредством клиента или любого другого клиентского узла в клиентском кластере 201 и приниматься посредством узла 2 216 или любого другого узла в серверном кластере 206. Примерные запросы включают в себя, но не только, запросы на то, чтобы создавать, открывать или иным образом осуществлять доступ к файлу. Запрос 222 может быть передан из клиента в кластер узлов через сеть, такую как, но не только, Интернет, WAN, LAN или любой другой тип сети, известной в области техники. Начальный запрос 222 может включать в себя запрос на то, чтобы осуществлять доступ к ресурсу, к примеру к ресурсу 226. В вариантах осуществления запрос 222 также может включать в себя идентификатор экземпляра приложения, который идентифицирует запросчик, от имени которого клиент 202 выполняет запрос. В вариантах осуществления начальный запрос 222 может состоять из одного или более сообщений. Например, запрос 222 может представлять собой одно сообщение, содержащее как запрос, так и идентификатор экземпляра приложения. В другом варианте осуществления запрос 222 может представлять собой несколько сообщений, которые включают в себя один или более запросов, а также один или более идентификаторов экземпляров приложений. В вариантах осуществления клиент 202 может включать в себя кэш 214 экземпляров приложений, который используется для того, чтобы сохранять и/или формировать один или более идентификаторов экземпляров приложений, которые могут быть переданы с запросом 222.

[0031] Как показано на фиг. 2, узел 1 208 может принимать запрос 222 и идентификатор экземпляра приложения из клиента 202. Если запрашиваемый ресурс 226 доступен, например не защищен или заблокирован посредством другого клиента или приложения, узел 1 может предоставлять разрешение по запросу клиента (например, клиента 202) на то, чтобы осуществлять доступ к ресурсу 226 от имени запросчика, который запущен в клиенте. После предоставления разрешения на доступ к ресурсу 226 драйвер 210 фильтра может выделять или иным образом создавать ассоциацию между клиентом 202 и ресурсом 226 посредством сохранения идентификатора экземпляра приложения, который он принимает из клиента 202. В вариантах осуществления ассоциация может быть сохранена в качестве объекта в кэше 212 экземпляров приложений, который является частью узла 1. Хотя проиллюстрированный вариант осуществления показывает кэш 212 экземпляров приложений в качестве части узла 1 208, в вариантах осуществления кэш 212 экземпляров приложений может быть сохранен в другом месте в качестве части кластера 206 узлов. Специалисты в данной области техники должны принимать во внимание, что кластер 206 узлов может включать в себя один или более кэшей экземпляров приложений, к примеру кэш 220 экземпляров приложений в узле 2 216. В вариантах осуществления, когда присутствуют несколько кэшей экземпляров приложений, данные, сохраненные в нескольких кэшах экземпляров приложений, могут реплицироваться через все кэши экземпляров приложений, либо каждый кэш экземпляров приложений может сохранять отдельные данные.

[0032] В одном варианте осуществления идентификатор экземпляра приложения, принимаемый из клиента, идентификатор экземпляра приложения, который идентифицирует запросчик (например, приложение или процесс), может быть сохранен в структуре _NETWORK_APP_INSTANCE_ECP_CONTEXT. Структура _NETWORK_APP_INSTANCE_ECP_CONTEXT может задаваться следующим образом:

typdef struct _NETWORK_APP_INSTANCE_ECP_CONTEXT {

USHORT Size;

USHORT Reserved;

GUID AppInstanceID;

}_NETWORK_APP_INSTANCE_ECP_CONTEXT, *PNETWORK_APP_INSTANCE_ECP_CONTEXT;

[0033] В таких вариантах осуществления переменная Size может сохранять информацию, связанную с размером структуры, и переменная AppInstanceID может быть уникальным идентификатором экземпляра приложения для отказоустойчивого кластерного клиентского приложения, такого как запросчик, запущенный в клиенте 202. В вариантах осуществления _NETWORK_APP_INSTANCE_ECP_CONTEXT либо другой объект или переменная, содержащая идентификатор экземпляра приложения запросчика, могут быть сохранены в кэше 214 глобально уникальных идентификаторов (GUID). В вариантах осуществления структура _NETWORK_APP_INSTANCE_ECP_CONTEXT может отправляться из клиента на сервер в ассоциации с запросом, чтобы осуществлять доступ к ресурсу (например, с запросом на создание или открытие). В одном варианте осуществления идентификатор экземпляра приложения запросчика может быть сохранен в GUID-кэше клиентского узла, в котором запущен запросчик в кластерном клиентском окружении 201. В другом варианте осуществления, хотя не показано на фиг. 2, кластер 201 клиентских узлов может иметь центральный репозиторий, который сохраняет идентификаторы экземпляров приложений. В таком варианте осуществления несколько клиентских узлов в кластере 201 клиентских узлов могут осуществлять доступ к централизованному репозиторию. В еще одном другом варианте осуществления идентификаторы экземпляров приложений могут быть сохранены в нескольких GUID-кэшах (например, в GUID-кэше 214 и GUID-кэше 216). В таких вариантах осуществления кластер 201 клиентских узлов может использовать алгоритм репликации, чтобы обеспечивать то, что эти несколько GUID-кэшей содержат идентичные идентификаторы экземпляров приложений.

[0034] Как описано выше, идентификатор экземпляра приложения может быть ассоциирован с ресурсом 226, в то время как клиент 202 осуществляет доступ к ресурсу 226 от имени запросчика. Серверный узел 206 может сохранять такую ассоциацию в одном или более кэшей экземпляров приложений, которые являются частью кластера 206 серверных узлов, к примеру в кэшах 212 и 220 экземпляров приложений. В одном варианте осуществления идентификатор экземпляра приложения может быть ассоциирован с ресурсом посредством добавления его в список дополнительных параметров создания (ECP) для ресурса 226. ECP-список может быть сохранен в кэше экземпляров приложений, который является частью кластера 206 серверных узлов, к примеру в кэшах 212 и 220 экземпляров приложений. В вариантах осуществления, когда ECP принимается посредством сервера, сервер извлекает идентификатор экземпляра приложения из ECP и добавляет его в кэш для ассоциирования с ресурсом, дескриптором ресурса и т.д. Как описано относительно сохранения идентификаторов экземпляров приложений в клиентском кластере 201, идентификаторы экземпляров приложений, ассоциированные с узлом, могут сохраняться в отдельном кэше экземпляров приложений в узле в кластере 206 серверных узлов, в центральном репозитории в серверном кластере 206 или реплицироваться в нескольких кэшах экземпляров приложений на нескольких узлах в кластере 206 серверных узлов.

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

[0036] Когда возникает ошибка в клиенте 202, запросчик может использовать механизм 232 восстановления после сбоя клиента, чтобы мигрировать на новый клиентский узел (например, клиент 204) в клиентском кластере 201. Специалисты в данной области техники должны принимать во внимание, что любой тип механизма восстановления после сбоя может использоваться при восстановлении 232 после сбоя клиента. В вариантах осуществления механизм 232 восстановления после сбоя также может включать в себя миграцию идентификатора экземпляра приложения запросчика, который, возможно, сохранен в GUID-кэше 214 в текущем сбойном клиенте 202. После выполнения миграции запросчик может пытаться восстанавливать доступ к ресурсу 202. В вариантах осуществления клиент 216 может отправлять второй запрос 224 в узел 1, чтобы запрашивать доступ к ресурсу 226 от имени запросчика. Тем не менее, без вариантов осуществления по обеспечению непрерывного доступа, раскрытых в данном документе, когда узел 1 208 принимает запрос на то, чтобы осуществлять доступ к ресурсу 226, от имени клиента 204 (отправляющего устройства второго запроса 224), он может отклонять запрос, поскольку ресурс 226 по-прежнему находится в защищенном или заблокированном состоянии с момента предыдущего доступа, который клиент 202 выполнил от имени ресурса. Без вариантов осуществления, раскрытых в данном документе, узел 1 208 должен распознавать, что второй запрос в ресурс 226 доступа исходит из другого местоположения (например, клиента 204). Узел 1 208 не имеет возможность определять то, что запрос предназначен для идентичного запросчика, который поддерживает блокировку ресурса 226, и, следовательно, определять то, что предоставление разрешения по запросу должно приводить к конфликту. Тем не менее, если идентичный запросчик пытается осуществлять доступ к ресурсу 224, нет проблемы конфликта, и вынуждение клиента ожидать освобождения ресурса может приводить к чрезмерным задержкам.

[0037] Идентификатор экземпляра приложения может быть использован для того, чтобы разрешать эту проблему. В вариантах осуществления второй запрос 224 также может включать в себя идентификатор экземпляра приложения из идентификации запросчика, который мигрировал на клиент 204 во время восстановления после сбоя, показанного на 232. В вариантах осуществления идентификатор экземпляра приложения запросчика может присутствовать в GUID-кэше 228 клиента 204 до миграции запросчика во время восстановления 232 после сбоя клиента. Например, механизм репликации, возможно, использован для того, чтобы реплицировать идентификатор экземпляра приложения запросчика через узлы в клиентском кластере 201. В другом варианте осуществления запросчик 203 может сохранять свой идентификатор экземпляра приложения. В еще одном другом варианте осуществления, идентификатор экземпляра приложения запросчика 203 может мигрировать во время восстановления 232 после сбоя клиента.

[0038] Как описано относительно запроса 222, идентификатор экземпляра приложения может быть передан в идентичном сообщении, что и второй запрос 224, либо второй запрос 224 может состоять из ряда различных сообщений. Когда второй запрос принимается в кластере 206 узлов или в отдельном узле в кластере, к примеру в узле 1 208, и приемный сервер определяет то, что ресурс защищен или заблокирован, выполняется определение в отношении того, является или нет идентификатор экземпляра приложения во втором запросе 224 идентичным идентификатору экземпляра приложения, ассоциированному с ресурсом 226. В вариантах осуществления узел 2 216 сравнивает идентификатор экземпляра приложения, принимаемый во втором запросе 222, с идентификатором экземпляра приложения, который ассоциирован с ресурсом 226. Идентификатор приложения, ассоциированный с ресурсом 220, может быть сохранен в кэше 212 экземпляров приложений узла 1 212. В вариантах осуществления, в которых несколько кэшей экземпляров приложений присутствует в кластере 206 узлов, определение может проверять несколько кэшей экземпляров приложений в кластере 206 узлов. В таких вариантах осуществления, если совпадающий идентификатор экземпляра приложения не находится в кэше 212 экземпляров приложений, узел 1 216 может отправлять запрос в узел 2 212, чтобы определять то, расположен или нет совпадающий идентификатор экземпляра приложения в кэше 220 экземпляров приложений.

[0039] В одном варианте осуществления, если идентификатор экземпляра приложения, принимаемый во втором запросе 224, не совпадает с идентификатором экземпляра приложения, ассоциированным с ресурсом 226 (который может быть сохранен в кэше 212 и/или 220 экземпляров приложений), разрешение по второму запросу 224 не может быть предоставлено до тех пор, пока ресурс 226 не станет свободным. Тем не менее, если совпадение обнаружено, приемный сервер (например, узел 1 208) и/или кластер 206 серверных узлов выполняет действия для того, чтобы предоставлять разрешение на доступ к ресурсу 226, без чрезмерной задержки для клиента 204 и запросчика 203. В таких случаях кластер 206 узлов может признавать ресурс 226 недействительным, за счет этого выводя ресурс 226 из защищенного или заблокированного состояния. В вариантах осуществления признание недействительным предыдущего доступа может содержать любое действие, которое выводит ресурс из защищенного или заблокированного состояния. Один неограничивающий пример представляет собой закрытие открытого файла (например, если ресурс 226 является файлом). После того, как предыдущий доступ признается недействительным, разрешение по второму запросу 224 на то, чтобы осуществлять доступ к ресурсу 226, может быть предоставлено, в силу этого предоставляя непрерывный доступ к запросчику 203.

[0040] В одном варианте осуществления узел, принимающий второй запрос 224, к примеру узел 1 208 на фиг. 2, может выполнять требуемые действия для того, чтобы признавать недействительным предыдущий доступ к ресурсу 226, если другой узел (например, узел 2 216) имеет доступ и/или разрешение признавать предыдущий доступ недействительным. Тем не менее, в некоторых случаях узел, принимающий запрос, может не иметь доступа или разрешения признавать предыдущий доступ недействительным. Например, такой случай может возникать, если исходный запрос 222 выполняется в узел 2 216, когда узел 2 216 может управлять ресурсом. В таких случаях узел, принимающий второй запрос 224, может отправлять запрос в управляющий узел, чтобы признавать предыдущий доступ недействительным. После того, как управляющий узел признает предыдущий доступ недействительным, узел, принимающий второй запрос 224, может предоставлять разрешение по второму запросу 224. В других вариантах осуществления узел, принимающий второй запрос 224, может отправлять запрос в другой узел, чтобы предоставлять клиенту 204 и/или запросчику 203 (теперь постоянно размещающемуся в клиенте 204) доступ к ресурсу 226.

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

[0042] Фиг. 3 является вариантом осуществления способа 300, который запросчик может использовать для того, чтобы получать непрерывный доступ к ресурсу в кластерном клиентском окружении. Например, запросчик может быть клиентом, к примеру клиентом 202 (фиг. 2), который использует способ 300, чтобы осуществлять доступ к ресурсу (например, к ресурсу 226). В вариантах осуществления ресурс может постоянно размещаться на удаленной машине, к примеру на сервере. Сервер может быть автономным сервером или частью кластерного окружения, к примеру серверного кластера 206 (фиг. 2). Последовательность операций начинается на этапе 302, на котором запрос на ресурс отправляется на сервер. В вариантах осуществления запрос может быть на осуществление доступа к ресурсу. В вариантах осуществления осуществление доступа к ресурсу может содержать открытие файла, создание файла или иное осуществление доступа или выполнение операции на ресурсе, который может быть удаленным для клиента. В вариантах осуществления запросчик может работать в кластерном клиентском окружении. В таких вариантах осуществления запрос, отправленный на этапе 302, может отправляться из первого клиента в кластерном клиентском окружении.

[0043] Последовательность операций переходит к этапу 304, на котором идентификатор экземпляра приложения отправляется, например, на сервер (например, на автономный сервер или узел в кластерном окружении). В одном варианте осуществления первый клиент, который отправил запрос, также может отправлять идентификатор экземпляра приложения от имени запросчика. Как описано выше, идентификатором экземпляра приложения является GUID, идентифицирующий запросчик (например, приложение, клиент или дочерний процесс приложения, запрашивающего доступ к ресурсу). В одном варианте осуществления идентификатор экземпляра приложения может отправляться в сообщении, передаваемом через сеть. Идентификатор экземпляра приложения может быть передан в идентичном сообщении, содержащем запрос на этапе 302, либо он может быть передан в другом сообщении. В таких вариантах осуществления объект, содержащий идентификатор экземпляра приложения, к примеру, но не только, _NETWORK_APP_INSTANCE_ECP_CONTEXT, описанный относительно фиг. 2, может отправляться на этапе 302.

[0044] В одном варианте осуществления интерфейс может быть использован для того, чтобы отправлять идентификатор экземпляра приложения на этапе 304. Интерфейс может быть интерфейсом уровня ядра, расположенным в клиенте или доступным клиенту, работающему в кластерном клиентском окружении. В вариантах осуществления интерфейс уровня ядра может быть использован посредством запросчика и/или клиента, чтобы отправлять идентификатор экземпляра приложения на сервер. Ниже приводится неограничивающий пример интерфейса уровня ядра, который может использоваться на этапе 304 для того, чтобы отправлять идентификатор экземпляра приложения:

#if (NTDDI_VERSION>=NTDDI_WIN8)

//

//Контекст ECP для приложения, чтобы предоставлять идентификатор экземпляра.

//

typedef struct _NETWORK_APP_INSTANCE_ECP_CONTEXT {

//

//Он должен задаваться равным размеру этой структуры.

//

USHORT Size;

//

//Он должен задаваться равным нулю.

//

USHORT Reserved;

//

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

//приложения.

//

GUID AppInstanceID;

}NETWORK_APP_INSTANCE_ECP_CONTEXT, *PNETWORK_APP_INSTANCE_ECP_CONTEXT;

//

//GUID, используемый для структуры APP_INSTANCE_ECP_CONTEXT.

//

//{6AA6BC45-A7EF-4af7-9008-FA462E144D74}

//

DEFINE_GUID(GUID_ECP_NETWORK_APP_INSTANCE, 0x6aa6bc45, 0xa7ef, 0x4af7, 0x90, 0x8, 0xfa, 0x46, 0x2e, 0x14, 0x4d, 0x74);

#endif//NTDDI_Version>=NTDDI_WIN8

[0045] Хотя предоставляется конкретный интерфейс уровня ядра, специалисты в данной области техники должны принимать во внимание, что другие интерфейсы уровня ядра могут использоваться на этапе 304 для того, чтобы отправлять идентификатор экземпляра приложения.

[0046] В другом варианте осуществления интерфейс прикладного программирования (API) может использоваться на этапе 304 для того, чтобы отправлять идентификатор экземпляра приложения. В таком варианте осуществления, запросчик и/или клиент могут отправлять идентификатор экземпляра приложения посредством выполнения вызова в API. API может размещаться на клиенте, выполняющем этап 304 (например, на первом клиенте в серверном кластере), либо API может размещаться на другом устройстве и быть доступным посредством запросчика или другого приложения или процесса. Ниже приводится неограничивающий пример API, который может использоваться на этапе 304 для того, чтобы отправлять идентификатор экземпляра приложения:

NTSTATUS RegisterAppInstance (

_in PGUID AppInstance

);

[0047] Хотя предоставляется конкретный API, специалисты в данной области техники должны принимать во внимание, что другой API может использоваться на этапе 304. Кроме того, хотя этап 304 проиллюстрирован в качестве дискретного этапа, специалисты в данной области техники должны принимать во внимание, что отправка идентификатора экземпляра приложения может выполняться одновременно с отправкой запроса на этапе 302.

[0048] Когда запрашиваемый ресурс не заблокирован, по запросу, отправленному на этапе 302, предоставляется разрешение, и последовательность операций переходит к этапу 306, на котором к ресурсу осуществляется доступ. Как описано выше, сервер или устройство, управляющее ресурсом, может переключать ресурс в защищенное или заблокированное состояние, в то время как запросчик осуществляет доступ к ресурсу на этапе 306. В некоторый момент при осуществлении доступа к ресурсу возникает ошибка, к примеру ошибки, описанные со ссылкой на фиг. 2, которая вызывает сбой или иную потерю клиентом соединения с ресурсом. Ошибка может приводить к тому, что клиент (например, первый клиент в серверном кластере) теряет доступ к ресурсу до того, как запросчик завершает использование ресурса. При таких обстоятельствах ресурс не может высвобождаться из защищенного или заблокированного состояния.

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

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

[0051] В вариантах осуществления после операции восстановления после сбоя клиента последовательность операций переходит к этапу 310. На этапе 310 второй запрос на идентичный ресурс отправляется в кластерное окружение. В вариантах осуществления второй запрос отправляется посредством второго клиента в клиентском кластере от имени запросчика. Второй запрос может отправляться с использованием идентичного способа, как описано относительно первого ресурса на этапе 302. Чтобы поддерживать непрерывный доступ к ресурсу и не допускать чрезмерной задержки, последовательность операций переходит к этапу 312, на котором идентификатор экземпляра приложения снова отправляется в кластерное окружение. Идентификатор экземпляра приложения может отправляться на этапе 308 согласно одному из вариантов осуществления, описанных относительно этапа 304. В вариантах осуществления, поскольку другой клиент (например, второй клиент) отправляет второй запрос, сервер, принимающий запрос, может не иметь возможность идентифицировать второй запрос как принадлежащий этому запросчику, который поддерживает блокировку ресурса (например, поскольку запрос выполняется из другой машины, другого адреса и т.д.). Тем не менее, посредством отправки идентификаторов экземпляров приложений на этапах 304 и 308 сервер должен иметь возможность идентифицировать запросы как принадлежащие этому запросчику и предоставлять непрерывный доступ к ресурсу, как описано выше относительно фиг. 1 и 2. Последовательность операций переходит к этапу 314, и запросчик возобновляет доступ к ресурсу. В вариантах осуществления второй клиент может принимать ответ на второй запрос из сервера, указывающий то, что сервер предоставляет разрешение по второму запросу. В вариантах осуществления при приеме индикатора второй клиент может осуществлять доступ к ресурсу от имени запросчика.

[0052] Фиг. 4 является вариантом осуществления способа 400, выполняемого посредством узла в кластерном серверном окружении для того, чтобы предоставлять непрерывный доступ к ресурсу. Варианты осуществления способа 400 могут быть выполнены посредством узла, к примеру узла 1 208 (фиг. 2) в кластерном окружении, таком как кластер 206 узлов (фиг. 2). В вариантах осуществления способ 400 может быть выполнен посредством узла, который имеет доступ к ресурсу. Последовательность операций начинается на этапе 402, на котором узел принимает запрос на ресурс. В вариантах осуществления ресурс может быть файлом, объектом, методом, данными или любым другим типом ресурса, который управляется и/или может быть доступен посредством узла, выполняющего этап 400. Идентификатор экземпляра приложения может быть принят с запросом на этапе 402.

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

[0054] Если ресурс находится в защищенном или заблокированном состоянии, последовательность операций переходит по ветви "Да" от этапа 404 к этапу 406 принятия решения. На этапе 406 принятия решения идентификатор экземпляра приложения, принимаемый с запросом на этапе 402, сравнивается с идентификатором экземпляра приложения, который ассоциирован с ресурсом. Например, как описано относительно фиг. 2, узел может ассоциировать идентификатор экземпляра приложения с ресурсом, когда клиент или приложение осуществляет доступ к ресурсу. Как описано выше, ассоциация идентификатора экземпляра приложения запросчика, осуществляющего доступ к ресурсу, может быть сохранена в узле, например в кэше экземпляров приложений, как описано в различных вариантах осуществления, поясненном на фиг. 2. В вариантах осуществления идентификатор экземпляра приложения, который предоставляется в ECP, отправленном с запросом на ресурс, например, в структуре _NETWORK_APP_INSTANCE_ECP_CONTEXT, может добавляться в ECP-список, ассоциированный с ресурсом.

[0055] В одном варианте осуществления ассоциация ресурса экземпляра приложения может постоянно размещаться локально в узле, осуществляющем способ 400. В таких случаях сравнение может осуществляться в локальном кэше экземпляров приложений, постоянно размещающемся на сервере. Тем не менее, как пояснено относительно фиг. 2, кластерное окружение может содержать определенное число кэшей экземпляров приложений, распределенных по различным узлам. Кроме того, различные кэши экземпляров приложений могут сохранять отдельные и/или различные данные. Идентификатор приложения, ассоциированный с защищенным или заблокированным ресурсом, может быть сохранен в другом узле в кластерном окружении. В таких случаях этап 406 может включать в себя отправку запроса в другой узел, чтобы выполнять сравнение на этапе 406. Запрос может включать в себя идентификатор экземпляра приложения, принимаемый на этапе 402.

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

[0057] Тем не менее, прием идентификатора приложения с запросом 402, который является идентичным идентификатору приложения, ассоциированному с защищенными или заблокированными ресурсами, указывает то, что, возможно, возникает ошибка, которая приводит к тому, что запросчик, который осуществляет доступ к ресурсу, теряет доступ к ресурсу без надлежащего высвобождения ресурса. Например, запросчик может работать в кластере клиентских узлов. Конкретный клиент, в котором работал запросчик, может терять соединение с сервером или иным образом сбоить до того, как запросчик завершает свои операции на ресурсе. Чтобы предоставлять непрерывный доступ к ресурсу, т.е. чтобы давать возможность запросчику восстанавливать доступ к ресурсу без чрезмерной или недопустимой задержки, последовательность операций переходит по ветви "Да" к этапу 408.

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

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

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

[0061] Способы 300 и 400 являются просто некоторыми примерами последовательностей операций, которые могут быть выполнены в соответствии с вариантами осуществления. Варианты осуществления не ограничены конкретным описанием, предоставленным выше относительно фиг. 3-6, и могут включать в себя дополнительные операции. Дополнительно проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно меньшее число или дополнительные этапы могут использоваться, применяться в способах, описанных на фиг. 3 и 4.

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

[0063] В наиболее обобщенной конфигурации система 500 типично включает в себя, по меньшей мере, один процессор 502 и запоминающее устройство 504. В зависимости от точной конфигурации и типа вычислительного устройства запоминающее устройство 504 может быть энергозависимым (например, RAM), энергонезависимым (например, ROM, флэш-память и т.д.) или какой-либо комбинацией. Эта наиболее обобщенная конфигурация проиллюстрирована на фиг. 5 посредством пунктирной линии 506. Системное запоминающее устройство 504 сохраняет инструкции 520, к примеру инструкции для того, чтобы осуществлять способы обеспечения постоянной доступности, раскрытые в данном документе, и данные 522, к примеру идентификаторы экземпляров приложений, которые могут быть сохранены в системе хранения файлов с устройством хранения, таким как устройство 508 хранения данных.

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

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

[0066] Варианты осуществления изобретения могут осуществляться на практике через внутрикристальную систему (SOC), в которой все или большинство компонентов, проиллюстрированных на фиг. 5, могут быть интегрированы на одной интегральной схеме. Такое SOC-устройство может включать в себя один или более процессоров, графических модулей, модулей связи, модулей виртуализации систем и функциональность различных приложений, все из которых интегрируются (или "записываются") на подложку кристалла в качестве одной интегральной схемы. При работе через SOC функциональность, описанная в данном документе относительно предоставления непрерывного доступа к ресурсу, может управляться через специализированную логику, интегрированную с другими компонентами вычислительного устройства/системы 500 на одной интегральной схеме (кристалле).

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

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

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

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

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

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

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

4. Способ по п. 1, в котором первый идентификатор приложения ассоциирован с, по меньшей мере, одним дочерним процессом приложения.

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

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

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

8. Способ по п. 6, в котором второй клиент отправляет второй запрос в ответ на восстановление после сбоя клиента.

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

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