Уровень техники
Доступ к данным обеспечивается несколькими разными типами протоколов доступа к данным. Протоколы доступа к данным предусматривают правила обмена данными внутри компьютеров или между ними. Разные типы протоколов доступа к данным обеспечивают определенные преимущества при осуществлении доступа к данным. В частности, протокол совместного файлового доступа («SFA»), такой как протокол блока серверных сообщений («SMB»), может быть использован для осуществления доступа к ресурсам файловой системы, и протокол передачи состояния представления («REST») может быть также использован для взаимодействий между клиентом и сервером, ограниченных заданными архитектурными требованиями. Каждый протокол представляет собой четко определенный формат обмена сообщениями для осуществления доступа к данным. Таким образом, когда протоколы реализованы в виде интерфейсов прикладного программирования (API) для соединения со службами доступа к данным, библиотеки API одного протокола неизбежно функционируют при исключении API других протоколов. В этой связи, общепринятые протоколы доступа к данным и API являются неэффективными при обеспечении интегрированного взаимодействия между клиентом и сервером на основе совместного использования файлов и требований, поскольку общепринятые протоколы доступа к данным и API неспособны обеспечивать полную поддержку интегрированных функциональных средств SMB и REST.
Раскрытие изобретения
Данное раскрытие представлено для ознакомления с набором идей в упрощенной форме, которые дополнительно описаны ниже в разделе «Осуществление изобретения». Данное раскрытие не предназначено для идентификации ключевых признаков или существенных признаков заявленного объекта изобретения, а также не предназначено для использования изолированно в качестве помощи в определении объема заявленного объекта изображения.
В различных вариантах осуществления обеспечены способы и системы обеспечения доступа к файловым системам. Принимают операцию на основе SFA, имеющую модификатор операции, в отношении файла в файловой системе. Операцию на основе SFA задают на основе интерфейса передачи состояния представления (REST) файла. Интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST. Принимают операцию на основе REST для файла в распределенном файловом хранилище. Операцию на основе REST задают на основе интерфейса SFA-REST. Операцию на основе SFA исполняют с использованием модификатора операции. К модификатору операции обращаются с тем, чтобы исполнить операцию на основе REST. Операцию на основе REST исполняют на основе интерфейса SFA-REST. Файловая схема может быть реализована для осуществления доступа к файловой системе. Схема включает в себя таблицы для хранения файлов, причем таблицы содержат поля, соответствующие элементам интерфейса SFA-REST. Дополнительно предполагается, что может быть реализован компонент моментального снимка для резервирования общих файловых ресурсов в файловой системе.
Краткое описание чертежей
Настоящее изобретение описано подробно ниже со ссылкой на фигуры прилагаемых чертежей, на которых:
Фиг. 1 представляет собой блок-схему примерной вычислительной среды, подходящей для использования при реализации вариантов осуществления настоящего изобретения;
Фиг. 2А-D представляют собой блок-схемы примерной облачной вычислительной инфраструктуры и платформы, в которых могут быть применены варианты осуществления изобретения;
Фиг. 3 представляет собой блок-схему способа осуществления доступа к файлам в распределенных файловых системах в соответствии с вариантами осуществления настоящего изобретения;
Фиг. 4 представляет собой блок-схему, показывающую способ выполнения моментального снимка общих файловых ресурсов, в соответствии с вариантами осуществлениями настоящего изобретения;
Фиг. 5 представляет собой блок-схему, показывающую способ осуществления доступа к файлам в распределенных файловых системах, в соответствии с вариантами осуществления настоящего изобретения; и
Фиг. 6 представляет собой блок-схему, показывающую способ осуществления доступа к файлам в распределенных файловых системах, в соответствии с вариантами осуществления настоящего изобретения.
Осуществление изобретения
Объект изобретения согласно вариантам осуществления изобретения описан в данном документе особенным образом, чтобы выполнить установленные законодательством требования. Однако представленное описание само по себе не предназначено для ограничения объема данного патентного документа. Вместо этого, изобретатели имели в виду, что заявленный объект изобретения может быть также воплощен по-другому, чтобы включать в себя разные этапы или комбинации этапов, аналогичных тем, что описаны в данном документе, совместно с другими существующими или будущими технологиями. Более того, хотя термины «этап» и/или «блок» могут быть использованы в данном документе для обозначения разных элементов применяемых способов, эти термины не следует рассматривать как подразумевающие какой-либо определенный порядок среди раскрытых в данном документе различных этапов или между ними до тех пор, пока в явном виде не будет описан такой порядок отдельных этапов.
Применительно к данному раскрытию слово «включающий в себя» имеет то же широкое значение, что и слово «содержащий». Вдобавок, употребление слов в единственном числе не исключает их множества до тех пор, пока в явном виде не указано иное. Таким образом, например, слово «элемент» подразумевает наличие одного или более элементов. Кроме того, термин «или» подразумевает соединительный союз, разделительный союз, а также их сочетание (a или b, тем самым, подразумевает либо a, либо b, а также a и b).
Применительно к представленному ниже подробному обсуждению варианты осуществления настоящего изобретения описаны со ссылкой на операции на основе SFA, использующие операции на основе SFA и REST через HTTP, взаимодействующие для поддержки файловой службы на облачной вычислительной платформе; однако совместное использование контента через интерфейс SFA-REST для файловой службы на облачной вычислительной платформе является всего лишь примерным, и предполагается, что описанные методы могут быть применены при других обстоятельствах, когда происходит взаимодействие операций на основе SFA и операции на основе REST.
Протокол совместного файлового доступа используется для обеспечения совместного доступа к файлам, принтерам, последовательному порту и обмена данными между узлами в сети. В частности, протокол совместного файлового доступа позволяет клиенту манипулировать файлами так, словно они находятся на локальном компьютере. Поддерживаются все операции, такие как чтение, запись, создание, удаление; при этом единственная разница состоит в том, что файлы не являются локальными по отношению к вычислительному устройству, а находятся в действительности на удаленном сервере.
Реализации протокола совместного файлового доступа выполняются через подход клиент-сервер, при котором клиент отправляет специальные запросы, а сервер отвечает на них соответствующим образом. В частности, протокол SMB предусматривает доступ к файловой системе, чтобы клиенты могли отправлять запросы на файловый сервер. В качестве справки, файловая система используется для управления сохранением и извлечением данных таким образом, чтобы один элемент информации в хранилище файловой системы можно было отличить от другого. Структура и правила логики, используемые для управления данными и их именами, называются файловой системой. Сервера SMB делают их файловые системы и другие ресурсы доступными клиентам по сети. Как таковой протокол SMB представляет собой протокол предпочтительных общих файловых ресурсов.
Передача состояния представления («REST») относится к программному архитектурному стилю, состоящему из согласованного набора архитектурных требований, применяемых к компонентам, соединителям и элементам данных с распределенной системой гипермедиа. В этой связи, протокол REST может быть описан как протокол архитектурных требований. Формальные архитектурные требования REST включают в себя, среди прочего, сообщения между клиентом и сервером, сообщения без сохранения состояния, кэшируемые сообщения, сообщения с самоописанием и манипулированием ресурсами через представления. В частности, отсутствие сохранения состояния может относиться к случаю, когда связь между клиентом и сервером не ограничена контекстом клиента, хранящимся на сервере между запросами, или когда в клиенте между запросами состояние может вовсе не сохраняться. Каждый запрос из любого клиента содержит всю информацию, необходимую для обслуживания запроса, и состояние сеанса хранится в клиенте. REST может быть также сконфигурирован для выполнения посредством протокола передачи гипертекста («HTTP»). Например, может быть считана назначенная веб-страница, которая содержит файл с расширяемым языком маркировки («XML»), причем XML описывает и содержит требуемый контент. Протокол REST, реализованный в виде API, может быть использован в мобильных приложениях, на веб-сайтах социальных сетей и в автоматических производственных процессах. Стиль REST подчеркивает, что взаимодействия между клиентами и службами улучшаются за счет наличия ограниченного количества операций. Ресурсам могут быть назначены их собственные уникальные универсальные идентификаторы ресурсов («URI»).
Вычислительная платформа может в целом иметь отношение к существующей среде, обладающей элементами программного обеспечения, предназначенного для выполнения внутри платформы, соблюдения требований и использования средств платформы. Платформа включает в себя аппаратную архитектуру и программную инфраструктуру, причем их комбинация может позволять клиентам и серверам осуществлять связь, используя протокол доступа к данным. Типичные платформы включают в себя аппаратную архитектуру, операционную систему и библиотеки времени выполнения. Аппаратная архитектура имеет отношение к идентификации физических компонентов и взаимосвязей, а программная инфраструктура имеет отношение к абстрагированию, при котором программное обеспечение предоставляет общие функциональные средства. В частности, программная инфраструктура (например, API REST) может позволять осуществлять доступ к BLOB-объектам (двоичным большим объектам) в хранилище BLOB-объектов. В этой связи, например, пользователи могут осуществлять доступ к хранилищу данных (например, данных BLOB-объектов) для приложений в выделенной инфраструктуре платформы. Платформа может быть реализована в виде вычислительной платформы в распределенной облачной вычислительной инфраструктуре.
Как правило, облачная вычислительная платформа функционирует для сохранения данных или выполнения служебных приложений распределенным образом. Вычислительная платформа может охватывать большие географические территории, включая страны и континенты. Облачная вычислительная платформа может быть публичным облаком, которое обеспечивает разные типы служб, включая вычислительные службы (например, виртуальные машины, веб-сайты, облачные службы и мобильные службы), службы данных (например, хранилище, базы данных SQL, отчетность SQL, таблицы, резервную копию и восстановление), сетевые службы (например, виртуальную сеть, диспетчер трафика, передачу данных) и службы приложений (например, медиа-службы, служебную шину, узлы уведомления и многофакторную аутентификацию). Например, облачная вычислительная платформа предусматривает выполнение служебных приложений и сохранение данных на машинах в доступном через Интернет центре сбора данных.
Компоненты облачной вычислительной платформы (например, контроллер полносвязанной сети) дополнительно отвечают за различные функции, связанные с мониторингом, сохранением и управлением состоянием компьютерных ресурсов, сетевым оборудованием, устройствами с последовательным интерфейсом и блоками питания, которые поддерживают базовые функциональные средства полносвязанной сети. Различные различимые типы облачных конфигураций могут быть реализованы с использованием вариантов осуществления настоящего изобретения, и, таким образом, специалистам в данной области техники должно быть понятно и очевидно, что могут быть использованы подходящие структуры облачной вычислительной платформы, и что варианты осуществления настоящего изобретения не ограничены вышеописанными в данном документе.
Платформа может поддерживать службы, которые поддерживают доступ к данным. Доступ к данным обеспечивается несколькими разными типами протоколов доступа к данным. Протоколы доступа к данным предусматривают правила обмена данными внутри компьютеров или между ними. Разные типы протоколов доступа к данным обеспечивают определенные преимущества при осуществлении доступа к данным. В частности, протокол SMB представляет собой протокол совместного использования предпочтительных общих файловых ресурсов, и протокол REST зачастую используется для взаимодействий между клиентом и сервером на основе требований. Каждый протокол представляет собой четко определенный формат обмена сообщениями для осуществления доступа к данным. Таким образом, когда протоколы реализованы в виде интерфейсов прикладного программирования (API) для соединения со службами доступа к данным, библиотеки API одного протокола неизбежно используются при исключении API других протоколов. В этой связи, общепринятые протоколы доступа к данным и API являются неэффективными при обеспечении интегрированного взаимодействия между клиентом и сервером на основе совместного использования файлов и требований, поскольку общепринятые протоколы доступа к данным и API неспособны обеспечивать полную поддержку интегрированных функциональных средств SMB и REST. Вдобавок, традиционный доступ к файловой системе основан на решениях системы хранения данных с прямым подключением («DAS») и сети хранения данных («SAN»), которые зачастую являются сложными и требуют больших затрат на установку, конфигурирование и функционирование. На базовом уровне сегодня нет доступных облачных платформ для поддержки файловой службы, которая обеспечивает API SFA-REST («интерфейс SFA-REST») на основе протокола совместного файлового доступа и протокола REST для осуществления доступа к файловой системе. Файловая служба на облачной вычислительной платформе может обеспечивать полную поддержку параллельного доступа к файловой системе из клиентов, при этом выгодно используя возможности и масштабируемость облачной вычислительной инфраструктуры, поддерживающей платформу.
Соответственно, варианты осуществления настоящего изобретения обеспечивают простую и эффективную файловую службу для облачной вычислительной платформы и способы осуществления доступа к файлам на основе этой файловой службы, при этом файловая служба содержит интерфейс SFA-REST. В частности, компоненты интерфейса SFA-REST, которые охарактеризованы в данном документе, в широком смысле имеют отношению к интегральной реализации функциональных средств протокола SFA и протокола REST. В этой связи, интерфейс SFA-REST поддерживает операции на основе SFA для осуществления доступа к общему файловому ресурсу, и интерфейс SFA-REST основан, по меньшей мере, частично на реализации элементов протокола SFA. Интерфейс SFA-REST дополнительно поддерживает операции на основе REST для осуществления доступа к общему файловому ресурсу, и интерфейс SFA-REST основан, по меньшей мере, частично на реализации элементов протокола REST. Интерфейс SFA-REST может быть дополнительно реализован на платформе в облачной вычислительной инфраструктуре, которая обеспечивает виртуальные машины, хранилище, балансировку нагрузки и сетевую конфигурацию для файловой службы, которая обеспечивает доступ к совместно используемым файлам. Облачная вычислительная инфраструктура может независимо поддерживать файловую службу, однако в вариантах осуществления служба BLOB-объектов может выполняться параллельно с файловой службой. Файловая служба и служба BLOB-объектов могут выгодно использовать элементы, доступные в облачной вычислительной инфраструктуре.
Примерная реализация интерфейса SFA-REST, поддерживающего интегрированные функциональные средства, может быть проиллюстрирована с помощью кэш-компонента интерфейса SFA-REST. Кэш-компонент будет дополнительно обсуждаться подробнее ниже. Кэш-компонент может обеспечивать определение того, как много контента ресурса файловой службы (например, файла или каталога) может быть кэшировано в клиенте. Кэширование файла на основе SFA может упоминаться как аренда SMB, которая отличается от аренды REST. Особенности аренды REST также обсуждаются более подробно ниже. Возвращаясь далее к аренде SMB, в качестве примера, когда клиент SFA открывает файл, то клиент SFA может запросить максимальную степень кэширования (например, чтение, запись, манипулирование). Клиент SFA может обмениваться операцией на основе SFA, имеющей модификатор операции, которая запрашивает кэширование. Исходя из типа и количества других манипуляторов, доступных для этого файла, файловая служба может отправлять клиенту ответ с указанием того, могут ли быть выполнены в отношении заданного файла операции чтения, записи или даже уведомления о закрытии манипулятора или открытии большего количества манипуляторов. Когда доступ к файлу осуществляет исключительно первый клиент, система может предоставить разрешение с полным кэшированием (чтение, запись и манипулирование). Если второй клиент пытается открыть манипулятор для этого файла, системе может потребоваться прекратить аренду SMB для обеспечения гарантии того, что изменения, выполненные первым клиентом, видны второму клиенту. Прекращение аренды SMB содержит осуществление связи с первым клиентом, имеющим аренду SMB, для сброса данных об изменениях на сервер перед прекращением аренды SMB. Кэш-компонент может также поддерживать прекращение аренд SMB, когда операции на основе REST (например, чтение или запись) запрашиваются для файла при аренде SMB.
Кэш-компонент интерфейса SFA-REST может быть выполнен с возможностью поддержки ошибочных путей, которые теперь возможны вследствие параллельного доступа к файловой системе посредством клиента SFA и клиента REST. В качестве примера, клиент, который владеет арендой, может не отвечать, когда аренду SMB требуется прекратить. Интерфейс SFA-REST может поддерживать управление интегрированными функциональными средствами операций на основе SFA и операций на основе REST, ссылаясь на аренды SMB применительно к файлам. Например, операция чтения или записи на основе REST может запрашивать доступ для файла, в то время как файл открыт и кэширован на основе действующей аренды SMB. Файл может быть открыт согласно операции на основе SFA, имеющей модификатор операции, которая запрашивает кэширование. В этом случае операция чтения или записи на основе REST может быть заблокирована, пока аренды SMB прекращены. Предполагается, что прекращение аренд SMB может занимать некоторое время. Как таковой интерфейс SFA-REST может предусматривать ошибку из-за превышения времени ожидания в обстоятельствах, при которых прекращение аренд SMB было слишком долгим. Конкретный код ошибки может быть определен и сообщен клиенту, чтобы позволить клиенту повторно выполнить операцию на основе REST (например, чтение или запись) позже. В настоящем изобретении предполагаются любые другие изменения и комбинации операций на основе REST, интегрированных в качестве функциональных средств с операциями на основе SFA, поддерживаемыми посредством компонентов интерфейса SFA-REST.
Варианты осуществления настоящего изобретения дополнительно включают в себя схему, разработанную на основе компонентов интерфейса SFA-REST. Схема поддерживает файловую службу, которая обеспечивает параллельный доступ на основе SFA и REST к общим файловым ресурсам. Например, клиент SFA и клиент REST могут иметь доступ к общему файловому ресурсу в одно и то же время. Схема включает в себя множество таблиц, причем таблицы включают в себя поля на основе интерфейса SFA-REST, имеющего элементы протокола SFA и протокола REST. Схема дополнительно позволяет выполнять моментальный снимок файловой системы. Моментальный снимок создает резервную копию файловой системы. Выполнение моментального снимка может быть основано на механизме копирования при записи, чтобы впоследствии можно было осуществлять доступ к старым версиям при каждом моментальном снимке.
Соответственно, в первом аспекте настоящего изобретения предложен способ осуществления доступа к файлам в распределенных файловых системах. Способ содержит прием операции на основе SFA, имеющей модификатор операции, для файла в распределенной файловой системе. Операция на основе SFA задается на основе интерфейса передачи состояния представления (REST) файла. Интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST. Способ дополнительно содержит прием операции на основе REST для файла в распределенной файловой системе, причем операция на основе REST задается на основе интерфейса SFA-REST. Способ также включает в себя исполнение операции на основе SFA, используя модификатор операции. Способ включает в себя обращение к модификатору операции для исполнения операции на основе REST. Способ также включает в себя исполнение операции на основе REST согласно интерфейсу SFA-REST.
Во втором аспекте настоящего изобретения предложена система, имеющая схему файловой службы для осуществления доступа к файловым системам данных. Схема файловой службы включает в себя множество таблиц. Множество таблиц хранит состояние файлов в файловой системе. Множество таблиц содержит поля, соответствующие элементам интерфейса SFA-REST. Интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST для осуществления доступа к файлам в файловой системе.
В третьем аспекте настоящего изобретения предложен реализуемый на компьютере способ выполнения моментального снимка общих файловых ресурсов. Способ включает в себя обновление таблицы общих ресурсов, содержащей общий файловый ресурс. Обновление таблицы общих ресурсов содержит добавление строки в таблицу общих ресурсов, причем строка связана с новой версией общего файлового ресурса. Способ также включает в себя передачу узлу, связанному с общим файловым ресурсом, уведомления, предписывающего узлу начинать запись новой версии общего файлового ресурса. Способ дополнительно включает в себя определение того, что узел записывает новую версию общего файлового ресурса. Способ также включает в себя обновление таблицы общих ресурсов для указания, что моментальный снимок выполнен успешно.
После краткого описания общего вида вариантов осуществления настоящего изобретения далее обсуждается примерная операционная среда, в которой могут быть реализованы варианты осуществления настоящего изобретения, с тем чтобы обеспечить общее представление различных аспектов настоящего изобретения. В частности, сначала делается ссылка на Фиг. 1, на которой показана примерная операционная среда для реализации вариантов осуществления настоящего изобретения, которая в общем обозначена как вычислительное устройство 100. Вычислительное устройство 100 представляет собой всего лишь один пример подходящей вычислительной среды и не предназначено для какого-либо ограничения объема применения или функциональных возможностей изобретения. Вычислительное устройство 100 также не следует рассматривать как обладающее какой-либо зависимостью или требованием, связанным с каким-либо одним проиллюстрированным компонентом или комбинацией проиллюстрированных компонентов.
Изобретение может быть описано в общем контексте компьютерного кода или машиноиспользуемых инструкций, включая машиноисполняемые инструкции, такие как программные модули, исполняемые компьютером или другой машиной, такой как карманный компьютер или другое переносное устройство. В целом программные модули, включающие в себя подпрограммы, программы, объекты, компоненты, структуры данных и т.д., относятся к коду, который выполняет определенные задачи или реализует определенные типы абстрактных данных. Изобретение может быть реализовано на практике в виде множества системных конфигураций, включая переносные устройства, потребительские электронные устройства, компьютеры общего назначения, вычислительные устройства специального назначения и т.д. Изобретение может быть также реализовано на практике в распределенных вычислительных средах, в которых задачи выполняются с помощью удаленных устройств обработки, которые соединены через сеть связи.
Как показано на Фиг. 1, вычислительное устройство 100 включает в себя шину 110, которая напрямую или опосредованно соединяет следующие устройства: память 112, один или более процессоров 114, один или более компонентов 116 представления, порты 118 ввода/вывода, компоненты 120 ввода/вывода и иллюстративный источник 122 питания. Шина 110 может представлять собой одну или более шин (таких как адресная шина, шина данных или их сочетание). Хотя различные блоки показаны на Фиг. 1 с использованием линий в целях ясности изложения, в действительности очертания различных компонентов не являются такими уж четкими, и, говоря в переносном смысле, правильнее следует изображать линии серыми и нечеткими. Например, можно считать, что компонент представления, такой как устройство отображения, представляет собой компонент ввода/вывода (I/O). Процессоры также могут иметь память. Следует понимать, что это свойственно данной области техники, и, повторяя вновь, схема на Фиг. 1 является всего лишь иллюстрацией примерного вычислительного устройства, которое может быть использовано в сочетании с одном или более вариантами осуществления настоящего изобретения. Не делается никакого различия между такими категориями, как «рабочая станция», «сервер», «переносной компьютер», «переносное устройство» и т.д., так как все они предусмотрены содержанием Фиг. 1 и упоминаются как «вычислительное устройство».
Вычислительное устройство 100, как правило, включает в себя множество машиночитаемых носителей. Машиночитаемые носители могут быть любыми доступными носителями, доступ к которым можно осуществлять с помощью вычислительного устройства 100, и включают в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители. В качестве примера, но не ограничения, машиночитаемые носители могут содержать компьютерные носители информации и среду передачи данных.
Компьютерные носители информации включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули или другие данные. Компьютерные носители информации включают в себя, но ограничиваются ими: RAM, ROM, EEPROM, флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другой оптический дисковый накопитель, магнитные кассеты, магнитную ленту, магнитный дисковый накопитель или другие магнитные запоминающие устройства, или любой другой носитель, который может быть использован для хранения требуемой информации и доступ к котором можно осуществлять с помощью вычислительного устройства 100. Компьютерные носители информации не включают в себя сигналы как таковые.
Среда передачи данных, как правило, воплощает машиночитаемые инструкции, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущая волна или другое средство переноса, и включает в себя любую среду передачи информации. Термин «модулированный сигнал данных» означает сигнал, у которого одна или более его характеристик установлены или изменены таким образом, чтобы закодировать информацию в сигнал. В качестве примера, но не ограничения, среда передачи данных включает в себя проводную среду, такую как проводная сеть или непосредственное проводное соединение, и беспроводную среду, такую как акустическая, радиочастотная, инфракрасная и другая беспроводная среда. Сочетания любой из вышеуказанных сред должны быть включены в понятие машиночитаемых носителей.
Память 112 включает в себя компьютерные носители информации в виде энергозависимой и/или энергонезависимой памяти. Память может быть съемной, несъемной памятью или их сочетанием. Примерные аппаратные устройства включают в себя твердотельную память, жесткие диски, оптические дисковые накопители и т.д. Вычислительное устройство 100 включает в себя один или более процессоров, которые считывают данные с различных объектов, таких как память 112 или компоненты 120 I/O. Компонент(ы) 116 представления представляет(ют) индикации данных пользователю или другому устройству. Примерные компоненты представления включают в себя устройство отображения, динамик, компонент печати, вибрирующий компонент и т.д.
Порты 118 I/O позволяют вычислительному устройству 100 быть логически соединенным с другими устройствами, включающими в себя компоненты 120 I/O, некоторые из которых могут быть встроенными. Иллюстративные компоненты включают в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер, устройство печати, беспроводное устройство и т.д.
Со ссылкой на Фиг. 2А описана блок-схема, показывающая примерную облачную вычислительную распределенную инфраструктуру 200, подходящую для использования в вариантах осуществления изобретения. В общем, облачная вычислительная распределенная инфраструктура 200 иллюстрирует среду для предоставления служб через облачную вычислительную платформу. Облачная вычислительная инфраструктура 200 предоставляет масштабируемые, высоконадежные и длительные службы. Например, служба хранилища данных обеспечивает возможность хранения данных в разных типах хранилищ данных. Каждый тип хранилища данных имеет свои преимущества, и множество типов хранилищ данных может быть использовано при одном и том же применении. Облачная вычислительная инфраструктура может предоставлять служебные API для поддержки BLOB-объектов, очередей, таблиц и типов хранилищ данных файловой системы. В частности, варианты осуществления настоящего изобретения обеспечивают файловую службу, которая поддерживает операции на основе SFA и операции на основе REST для осуществления параллельного доступа к файловой системе на платформе. Файловая служба использует интерфейс SFA-REST, содержащий интегрированные функциональные средства протокола SFA и протокола REST. Интерфейс SFA-REST предоставляет файловую систему на основе протокола SFA, так что интерфейс SFA-REST позволяет открывать или создавать файлы, которые выдают манипулятор для файла в файловой системе. Когда манипулятор выдан, клиент может считывать и записывать файл, используя манипулятор. Интерфейс SFA-REST также содержит элементы протокола REST, который позволяет предписывать операции на основе REST, включая действия установления («PUT») и получения («GET»), в отношении файла. Протокольные компоненты являются интегрированными, чтобы совместно обеспечивать доступ к файловой системе параллельно. В частности, интерфейс SFA-REST задает правила взаимодействий между операциями на основе SFA протокола SFA и операциями на основе REST протокола REST. Интерфейс SFA-REST содержит API на основе SFA и API на основе REST, которые обеспечивают выполнение множества разных операций на основе параметров и возвращаемых значений, соответствующих каждой отдельной операции. Применительно к API на основе SFA, в качестве примера, API операции создания может включать в себя имя файла в качестве параметра и статус, файловый манипулятор, отметки времени файла, размер файла в качестве возвращаемых значений. API операции создания может позволять клиенту открывать или создавать файл, имеющий имя файла. Дополнительные параметры могут управлять разными аспектами файла и манипулировать возвращаемыми значениям. API на основе SFA дополнительно поддерживает команду уступающей блокировки (oplock), которая может быть установлена из службы в отношении клиента. Уступающая блокировка может быть реализована с помощью операции создания на основе SFA, когда файлы открыты или созданы, и серверу при определенных обстоятельствах может потребоваться прекратить уступающие блокировки. Дополнительные сведения о API на основе SFA, которые поддерживают уступающие блокировки, аренды SMB и взаимодействия с API на основе REST, обсуждаются более подробно ниже.
Важно отметить, что аренды SMB и уступающие блокировки могут быть использованы взаимозаменяемо в данном документе, но отличаются по их реализации. В частности, аренды SMB и уступающие блокировки управляются по-разному во время взаимодействий между клиентом и сервером. Уступающие блокировки могут быть случайно прекращены одним клиентом, выполняющим два процесса на одном и том же клиенте, который может прекратить уступающую блокировку, в то время как аренды SMB защищены от таких случайных прекращений при аренде SMB. Это отличие можно считать необходимым применительно к вариантам осуществления настоящего изобретения.
Что касается API на основе REST, то API на основе REST поддерживают операции без сохранения состояния. В качестве справки, отсутствие сохранения состояния может относится к случаю, когда связь между клиентом и сервером не ограничена контекстом клиента, хранящимся на сервере между запросами. Каждый запрос из любого клиента содержит всю информацию, необходимую для обслуживания запроса, и состояние сеанса хранится в клиенте, или в клиенте между запросами состояние может вовсе не сохраняться. В этой связи, нет зависимостей между запросами. Кроме того, аутентификация для операций на основе REST может быть обработана аналогичным образом для каждого запроса на основе подписания канонизированной версии запроса на аутентификацию операции на основе REST с использованием пользовательского ключа учетной записи хранения и передачи окончательной подписи вместе с запросом. Примерный API на основе REST может быть API операции создания файла, который позволяет клиенту создавать файл. API операции создания файла может иметь параметр «имя» и возвращаемой значение «статус». Дополнительные примерные API включены в приложение к данному документу.
Возвращаясь снова к Фиг. 2А, среди других непоказанных компонентов, облачная вычислительная распределенная инфраструктура 200, как правило, включает в себя клиент 202 SFA, клиент 204 REST, облачную вычислительную платформу 206, служебные API 208, хранилище 210, имеющее BLOB-объект 212, очередь 214, таблицу 216 и файловую систему 218, и сеть 220. Сеть 220 может включать в себя, без ограничения, одну или более локальных сетей (LAN) и/или глобальных сетей (WAN). Такие сетевые среды широко используются в офисах, корпоративных компьютерных сетях, сетях Интранет и Интернет. Соответственно, сеть 226 не будет дополнительно описана в данном документе.
Клиент 202 SFA и клиент 204 REST представляют собой вычислительные устройства, имеющие программное обеспечение или аппаратное обеспечение, которое осуществляет доступ к службам, предоставляемым облачной вычислительной платформой 206. Клиенты могут включать в себя любой тип вычислительного устройства, такого, например, как вычислительное устройство 100, описанное со ссылкой на Фиг. 1. Клиент может осуществлять доступ к облачной вычислительной платформе 206 через сеть 220. Клиент 202 SFA и клиент 204 REST могут, в частности, обращаться к компьютерным программам, которые опираются на протокол SFA и протокол REST, соответственно, чтобы осуществлять доступ к службам на облачной вычислительной платформе 206. Клиенты могут использовать служебные API 208 для того, чтобы иметь доступ к разным типам хранилищ данных. Типы хранилищ данных включают в себя BLOB-объект 212, предназначенный для хранения двоичных больших объектов со связанными с ними метаданными, такие как документы, изображения, видео и музыкальные файлы. Очередь 214 представляет собой тип хранилища данных для надежной асинхронной доставки сообщений. Тип хранилища данных в виде таблицы 216 обеспечивает возможность структурированного хранения для хранения упрощенных объектов данных, занимающих терабайты данных. Общий файловый ресурс 218 обеспечивает возможность хранения файлов, которые можно использовать совместно и к которым можно осуществлять доступ параллельно с клиента 202 SFA и клиента 204 REST.
Переходя к Фиг. 2В, клиент 202 SFA и клиент 204 REST, в частности, осуществляют доступ к файловой службе. Интерфейс 230 SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST для поддержки ресурсов 240 файловой службы. Ресурсы 240 файловой службы содержат учетную запись 242 хранения, общие ресурсы 244, каталоги 246 и файлы 248. В частности, общие ресурсы 244 обеспечивают способ организации наборов файлов и также могут быть заданы как общий файловый ресурс SMB, размещенный на облачной вычислительной платформе. Файловая служба может обеспечивать доступ к ресурсам 240 файловой службы на основе API («интерфейс SFA-REST») 230 файловой службы, в которых клиент 202 SFA и клиент 204 REST могут одновременно осуществлять доступ к ресурсам 240 файловой службы. Интерфейс SFA-REST может включать в себя API, которые поддерживают доступ к файловым ресурсам через операции HTTP. Операция может быть связана с типом ресурса и командой REST. Например, операция создания общего ресурса может иметь тип ресурса для общего ресурса и команду PUT REST, причем при исполнении операции создается новый общий ресурс в учетной записи хранения. Дополнительные операции предусмотрены в вариантах осуществления настоящего изобретения.
В вариантах осуществления операция может указывать версию API SFA-REST для его использования. Например, x-ms-версия могут быть заголовком HTTP, который используется для указания версии операции. По существу, пользователи могут указывать версию операции, которую они хотят использовать, посредством установки заголовка запроса x-ms-версии. Когда версия идентифицирована в заголовке HTTP, если доступна новая версия API, она не нарушит функциональные возможности вашего существующего кода. Пользователи могут модифицировать код для вызова более новой версии API путем указания заголовков HTTP x-ms-версии.
Как показано на Фиг. 2С, интерфейс 230 SFA-REST может включать в себя несколько разных интерфейсных компонентов (например, API), которые поддерживают разные интегрированные функциональные средства протокола SFA и протокола REST. Интерфейс SFA-REST содержит, среди прочего, компонент 250 доступа к данным, компонент 252 аренды, кэш-компонент 254, компонент 256 отметок времени, компонент 258 метаданных, компонент 260 атрибутов, компонент 262 блокировки байтового диапазона, компонент 264 присваивания имен и обращения и компонент 266 блокировки.
Как показано на Фиг. 2D, варианты осуществления настоящего изобретения дополнительно включают в себя ресурсы 270 схемы файловой службы. Ресурсы 270 схемы файловой службы обеспечивают доступ к файловой системе. Ресурсы 270 схемы файловой службы включают в себя схему, имеющую таблицы 272 доступа, таблицу 274 общих ресурсов и компонент 276 моментального снимка. Схема, имеющая таблицы 272 доступа и таблицу 274 общих ресурсов, обеспечивает доступ к файловой системе, имеющей файловые общие ресурсы, каталоги и файлы.
Следует понимать, что эта и другие схемы, описанные в данной документе, изложены лишь в качестве примеров. Другие схемы и функциональные средства (например, машины, интерфейсы, функциональные модули, команды и группы функциональных модулей) могут быть использованы в дополнение к уже показанным или вместо них, и некоторые функциональные средства могут быть исключены все вместе. Кроме того, многие из описанных в данном документе функциональных средств являются функциональными объектами, которые могут быть реализованы в виде дискретных или распределенных компонентов или в сочетании с другими компонентами, а также в любом подходящем сочетании и местоположении. Различные функции, описанные в данном документе как выполняемые одним или более объектами, могут быть осуществлены аппаратным обеспечением, программно-аппаратным обеспечением и/или программным обеспечением. Например, различные функции могут быть осуществлены процессором, исполняющим инструкции, хранимые в памяти.
Компонент доступа к данным может обеспечивать доступ к файловой системе. Компонент доступа к данным содержит API на основе SFA и API на основе REST, которые поддерживают доступ к файловой системе. В частности, API на основе SFA реализуют манипулятор, причем доступ к данным (например, открытие или создание файла) возвращает манипулятор для файла и позволяет считывать и записывать файл, используя манипулятор. API на основе REST не поддерживают эквивалентные функциональные средства манипулирования, определенные в протоколе SFA. API на основе REST поддерживает чтение и запись файлов без функциональных средств манипулирования, но включают в себя соответствующие элементы на основе протокола SFA.
Компонент аренды может обеспечивать исполнение аренды файлов для совместного доступа. Интерфейс SFA-REST включает в себя API на основе REST, который обеспечивает аренды REST. Аренды REST позволяют осуществлять доступ к файлу для совместного чтения и исключительной записи в течение некоторого периода времени. Период времени может быть заданным периодом времени, например, 1 минута, или бесконечным периодом времени. Интерфейс SFA-REST также включает в себя API на основе SFA, которые поддерживают совместный доступ на основе файловых манипуляторов. В качестве примера, когда пользователь создает или открывает файл с использованием операций на основе SFA, операция на основе SFA может включать в себя модификатор операции. Модификатор операции задает требование (например, доступ, совместное использование), которое модифицирует операцию на основе SFA. Требование может быть требованием доступа, таким как чтение, запись и удаление, и ограничение может быть требованием общего ресурса, таким как совместное использование для чтения, совместное использование для записи и совместное использование для удаления. Файловая служба может определять, следует ли выполнять операцию на основе SFA для обеспечения доступа к файлу, исходя из того, являются ли модификаторы операции из всех других манипуляторов, которые в настоящий момент открыты для этого файла, совместимыми с текущим модификатором операции в отношении операции на основе SFA.
Компонент аренды реализует API на основе REST для аренд REST, чтобы функционировать аналогично открытию файлового манипулятора для обеспечения доступа к этому файлу с целью его чтения, записи и удаления, и обеспечения совместного чтения из других манипуляторов. Компонент аренды выполняет проверку для подтверждения отсутствия существующих аренд, когда операция на основе REST приобретает или возобновляет аренду REST, и может возвращать ошибку, указывающую, что аренда не разрешена, поскольку имеются другие манипуляторы или аренды открываемого файла, которые совместимы с операцией на основе REST. Как таковая операция на основе REST или операция на основе SFA по открытию файла может быть исполнена неудачно в случае обращения к аренде, связанной с предыдущей операцией на основе REST, или модификатором операции, связанным с предыдущей операцией на основе SFA.
Кэш-компонент управляет взаимодействием операций на основе REST и операций с уступающей блокировкой. Уступающая блокировка (oplock) SMB представляет собой механизм кэширования, который клиенты SFA запрашивают с тем, чтобы улучшить производительность и уменьшить сетевые передачи. Это означает, что самое последнее состояние определенного файла или каталога может быть кэшировано в клиенте SFA. Существует множество типов уступающей блокировки, которые упоминаются как типы аренды SMB: чтение (R): при получении клиент может осуществлять чтение из локального кэша; запись (W): при получении клиент может осуществлять запись локально без необходимости сброса данных назад в службу SMB; манипулирование (H): при получении клиент не должен уведомлять службу SMB о том, когда происходит закрытие манипулятора. Уступающая блокировка полезна в случае, когда приложение продолжает открывать и закрывать файлы при одном и том же режиме доступа и совместного использования. Клиенту SFA не требуется уведомлять службу SMB о каждом закрытии мгновенно. Вышеуказанные типы аренды SMB не зависят от режима доступа и совместного использования, указываемого во время открытия манипулятора. Как правило, клиенты SFA пытаются получать все типы аренды всякий раз, когда они открывают новый манипулятор в отношении файла, вне зависимости от режима доступа и совместного использования.
В зависимости от операции на основе REST может быть необходимо, чтобы запросы REST прекращали существующие уступающие блокировки клиентов SFA. Это требовало бы от клиентов SFA сбрасывать кэшированные изменения в файловую службу в случае уступающей блокировки записи. Далее приведены некоторые из причин, при которых требуется прекратить каждый тип уступающей блокировки. Уступающую блокировку чтения (R) требуется прекращать всякий раз, когда операция REST записи выдается в виде Put Range («установить диапазон»). Уступающую блокировку записи (W) требуется прекращать всякий раз, когда операция REST чтения выдается в виде Get Blob («получить BLOB-объект»). Уступающую блокировку манипулирования (H) требуется прекращать всякий раз, когда клиент выдает операцию REST удаления, поскольку файловая служба не нуждается в манипуляторах открытия в отношении запроса удаления для достижения результата.
Прекращение уступающей блокировки содержит возможный сброс кэшированных изменений клиента SMB, и это может вызвать дополнительные задержки во времени ответа на служебную операцию REST или может обусловить неисполнение операции REST с кодом 408 состояния (время ожидания запроса) и идентификатором кода ошибки (например, ClientCacheFlushDelay). Примерный сценарий включает в себя случаи, когда требуются прекращение уступающей блокировки и сброс данных, и клиент REST столкнулся с задержкой. В этом сценарии клиент SFA открывает файл, получает данные об уступающей блокировке RWH и записывает данные локально. Клиент REST отправляет запрос на получение файла (Get File). Файловая служба прекращает уступающую блокировку записи (W) и оставляет в отношении клиента уступающую блокировку RH. Клиент SFA сбрасывает свои кэшированные данные в файловую службу и подтверждает прекращение уступающей блокировки. Файловая служба обрабатывает запрос на получение файла и возвращает назад ответ с запрошенными данными. В вышеописанном примере клиент REST будет сталкиваться с задержками, вызванными прекращением уступающей блокировки и временем, требуемым клиенту SFA для сброса своих данных в файловую службу. Любые последующие запросы на получение файла не будут подвергаться каким-либо дополнительным задержкам, поскольку уступающая блокировка записи (W) уже прекращена.
Другой примерный сценарий включает в себя случай, когда требуется прекращение уступающей блокировки, но клиент REST не сталкивается с задержкой. В этом сценарии клиент SFA уже имеет уступающую блокировку RH (в продолжение из вышеописанного примера). Клиент REST выдает запрос на установление диапазона (Put Range). Файловая служба отправляет запрос на прекращение уступающей блокировки клиенту SFA, но она не ожидает ответа. Файловая служба обрабатывает запрос на установление диапазона. В вышеописанном примере благодаря необходимости прекращения уступающей блокировки операция REST не испытывает каких-либо дополнительных задержек, поскольку ответ не требуется при прекращении уступающей блокировки чтения.
Файловая служба может иметь разные режимы работы, соответствующие каждой операции на основе REST, исходя из состояния уступающей блокировки для клиента SFA, который уже имеет открывающий маркер в отношении того же файла. Блокирование прекращения уступающей блокировки относится к тому случаю, когда файловая служба должна ожидать подтверждения того, что прекращение была успешной, в то время как в случае отсутствия блокирования файловая служба не делает этого. В случае необходимости блокирования прекращения уступающей блокировки, а также если прекращение не была выполнена успешна в течение указанного времени ожидания запроса и вплоть до 30 секунд, операция REST может быть не исполнена с кодом 408 состояния (время ожидания запроса) и идентификатором кода ошибки (например, ClientCacheFlushDelay).
Вдобавок, в качестве примера, запрос на удаление файла (Delete File) также требовал бы прекращения аренды манипулятора уступающей блокировки; это выполняется для обеспечения гарантии того, что нет файловых манипуляторов открытия со стороны SMB, когда запрос на удаление файла выдается из клиента REST. Если есть нарушение совместного использования, запрос не будет исполнен с кодом 409 состояния (конфликт) и идентификатором кода ошибки (например, SharingViolation).
Компонент отметок времени может функционировать для идентификации возникновения событий. В частности, компонент отметок времени может быть реализацией множества отметок времени, такой, что интегрированные функциональные средства протокола SFA и протокола REST могут быть доступны через интерфейс SFA-REST. API на основе REST обеспечивают поддержку для модели оптимистичного параллелизма. Модель оптимистичного параллелизма основана на точных отметках времени. В модели оптимистичного параллелизма, когда файловая служба принимает операцию на основе REST для осуществления доступа к файлу, файловая служба генерирует и возвращает метку объекта («ETAG»), которая является точной отметкой времени, которая гарантирована подвергается приращениям с каждой записью в файле. ETAG может передаваться назад последующим операциям на основе REST, таким как операции чтения или записи, в виде общепринятого заголовка, который будет вызывать неисполнение операции на основе REST, если файл изменился между обращениями к нему, или если ETAG не изменилась. API на основе SFA не реализуют модель оптимистичного параллелизма. Вместо этого выполняется обновление отметки времени, когда закрывается файловый манипулятор. Вдобавок, традиционные файловые системы обычно позволяют клиенту SFA в явном виде устанавливать отметку времени в файле произвольное число раз.
Компонент отметок времени поддерживает 5 разных отметок времени в отношении каждого файла. Четыре из отметок времени могут быть основаны на API на основе SFA. Отметки времени включают в себя время создания, время последней модификации, время последней записи и время последнего доступа. Четыре отметки времени могут быть реализованы с использованием одинаковой семантики протокола SMB. Пятая отметка времени представляет собой ETAG, которая может быть основана на оптимистичном параллелизме. Пятая отметка времени не видна через API на основе SFA. Все пять отметок доступны через API на основе REST. В этой связи, отметка времени может поддерживать интегрированные функциональные средства между операциями на основе SFA и операциями на основе REST, исходя из 5 разных отметок времени. В частности, поскольку операции на основе REST зависят от модели оптимистичного параллелизма, отметку времени ETAG требуется обновлять, когда операции на основе SFA исполняются в отношении файла. Как таковой интерфейс SFA-REST поддерживает обновление ETAG вместе с другими отметками времени, когда исполняется операция на основе SFA. В примерном сценарии с условной операцией на основе REST, если файл был обновлен с использованием операции на основе SFA, для последующей условной операции на основе REST требуется определить, что существует обновленная ETAG, чтобы проверить, можно ли выполнять условную операцию на основе REST.
Компонент метаданных может быть выполнен с возможностью поддержки описательной информации о контенте данных. API на основе REST позволяют связывать малый набор из произвольного имени и пар значений с файлом. API на основе SFA имеют расширенные атрибуты, которые могут быть связаны с файлом. Ограничения имени основаны на протоколе SMB, который является более ограниченным (длина и допустимые символы), чем обычный протокол REST. Чтобы сделать протокол SFA и протокол REST совместимыми, были реализованы API на основе REST с ограниченными именами, доступными метаданным.
Компонент присваивания имен и обращения может поддерживать осуществление доступа к ресурсам файловой службы. Доступ к ресурсу файловой службы может быть выполнен на основе имен или ссылочного синтаксиса. Учетная запись хранения содержит нулевое или большее количество общих ресурсов. Общий ресурс содержит свойства, метаданные и нулевое или большее количество файлов или каталогов. Файл может быть любым отдельным объектом, состоящим из двоичных данных, свойств и метаданных.
Что касается имен общих ресурсов, то правила, применяемые к именам общих ресурсов файловой службы, могут быть реализованы более жестко в API интерфейса SFA-REST, нежели протоколом SFA. Как таковые API для службы BLOB-объектов и API интерфейса SFA-REST могут совместно использовать похожие соглашения о наименованиях для контейнера BLOB-объектов и общего файлового ресурса.
Что касается имен каталогов и имен файлов, то интерфейс SFA-REST дополнительно поддерживает API, которые нечувствительны к регистру и защищены от регистра. Допустимые длины имен файла и каталога ограничены для каждого отдельного компонента (части между символами наклонной черты - «слешами») в API на основе REST, и общая длина составных имен для API на основе REST допускает более длинные и сложные имена, чем указанная в протоколе REST. Компонент присваивания имен и обращения содержит API на основе REST, которые больше не поддерживают символы, которые, как правило, разрешены в протоколе REST, в том смысле, что символы теперь не разрешены, а символы протокола SFA, которые, как правило, не разрешены в REST, теперь разрешены в API на основе REST. В одном варианте осуществления символы, которые не поддерживаются протоколом REST, но теперь поддерживаются в API на основе REST в компоненте присваивания имен и обращения, могут быть скрыты в API на основе REST. Сокрытие символов содержит кодирование выбранного символа с использованием кода %HEX. В вариантах осуществления настоящего изобретения подразумеваются другие изменения и комбинации кодирования неразрешенных символов протокола REST с тем, чтобы сделать их разрешенными в API на основе REST.
Составное имя содержит один или более компонентов составного имени (имя каталога или файла), отделенных символом прямого слеша «/». Все компоненты составного имени, за исключением последнего компонента составного имени, могут обозначать каталоги. Последний компонент составного имени обозначает каталог файлов. Составное имя может быть не более чем заданным числом (например, 1,024) символов в длину. Составное имя может состоять из одного или более компонентов составного имени, разделенных символом прямого слеша «/». Глубина подкаталога может быть выполнена такой, чтобы не превышать заданную глубину (например, 250). Файл не может совместно использовать тот же путь, что и каталог, и наоборот, т.е. одно и то же имя не быть использовано для файла или каталога, которые совместно используют родительский каталог. Пример: файл и каталог с именем «данные» не может существовать в одном и том же родительском пути.
Метаданные для общего ресурса или файлового ресурса могут храниться в виде пар «имя-значение», связанных с ресурсом. Каталоги могут быть реализованы без метаданных. Имена метаданных могут быть основаны на правилах наименования для идентификаторов C#. Имена метаданных могут поддерживать регистр, с помощью которого они были созданы, но являются нечувствительными к регистру в момент установки или чтения. Если в отношении ресурса поступили два или более заголовков метаданных с одним и тем же именем, файловая служба возвращает код 400 состояния (плохой запрос).
Интерфейс SFA-REST может поддерживать ссылки на унифицированный идентификатор ресурса («URI») в отношении общего ресурса, каталога или файла. Каждая ресурс файловой службы может иметь соответствующий базовый URI, который содержит ссылку на сам ресурс. Для учетной записи хранения базовый URI может включать в себя имя только учетной записи. Для общего ресурса базовый URI может включать в себя имя учетной записи и имя общего ресурса. Для каталога базовый URI может включать в себя имя учетной записи, имя общего ресурса и путь к каталогу. Для файла базовый URI включает в себя имя учетной записи, имя общего ресурса и путь к файлу. URI может однозначно реализовывать URI. Поскольку каждое имя учетной записи является уникальным, две учетные записи могут иметь общие ресурсы с одинаковым именем. Однако в пределах данной учетной записи хранения каждый общий ресурс может быть реализован с использованием уникального имени. Файлы в пределах данного общего ресурса или каталога могут также иметь уникальные имена в пределах этого общего ресурса или каталога. При попытке создать общий ресурс, каталог или файл с именем, которое нарушает наименования, соответствующий запрос может быть не исполнен с кодом 400 состояния (плохой запрос).
Компонент блокировки байтового диапазона может поддерживать блокировку байтового диапазона для интерфейса SFA-REST. API на основе SFA могут позволять клиенту SFA запрашивать эксклюзивный доступ к диапазону файла, а также доступ с чтением к диапазону файла. Это гарантирует, что нет других операций записей в пределах этого диапазона, но разрешены операции чтения. Компонент блокировки байтового диапазона может быть выполнен с возможностью отвергать операции записи или чтения через API на основе REST, когда возникает конфликт применительно к логике блокировок байтового диапазона SFA. API на основе SFA предусматривают блоки байтового диапазона для управления доступом с чтением и записью в области файла, API на основе REST могут не использовать выгодно эту возможность для определенной реализации. Вместо этого, как таковые API на основе REST могут требовать доступ с записью ко всему файлу. Это также означает, что операция на основе REST может не исполниться, если клиент SFA имеет блокировку в отношении любого диапазона внутри файла. Несмотря на это, операция на основе REST может быть реализована с помощью API на основе REST, которые поддерживают блокировку байтового диапазона.
Компонент доступа отвечает за поддержку доступа к файловой службе на основе двух разных конечных точек протоколов. Компонент доступа предусматривает конечную точку для протокола SFA и отдельную конечную точку для протокола REST. В этой связи, запросы и ответы для клиента SFA передаются через конечную точку протокола SFA, а запросы и ответы для клиента REST передаются из конечной точки протокола REST.
Компонент блокировки отвечает за управление файловыми блокировками. Компонент блокировки выполнен с возможностью обработки операции на основе SFA и исполнения операции с использованием модификатора операции, и обработки операции на основе REST путем обращения к модификатору операции. Модификатор операции может модификатором блокировки, который указывает режим доступа и режим совместного использования. В качестве примера, клиент SFA может задавать общий ресурс в качестве общего файлового ресурса. С помощью интерфейса SFA-REST клиент SFA может выгодно использовать механизмы блокировки файловой системы при осуществлении доступа через управление компонентом блокировки к совместно используемым файлам. Операция на основе SFA для осуществления доступа к файлу может включать в себя модификатор операции. Благодаря компоненту блокировки модификатор операции может представлять собой модификатор блокировки, который запрашивает полный совместный доступ к файлу для его чтения, записи и удаления или блокировки байтового диапазона для управления доступом с чтением и записью в области внутри одного файла. Когда клиент SFA открывает файл, операция на основе SFA для открытия файла включает в себя модификатор блокировки, имеющий режим доступа к файлу и его совместного использования. Обычно клиентами SFA используются следующие модификаторы блокировки доступа к файлу: чтение: файл открывается только для чтения; запись: файл открывается только для доступа с записью; чтение/запись: файл открывается с разрешениями на чтение/запись; удаление: файл открывается только для доступа с удалением.
Обычно клиентами SFA используются следующие модификаторы блокировки общего файлового ресурса: Отсутствие: Отклоняется совместное использование текущего файла. Любой запрос на открытие файла не будет исполняться до тех пор, пока файл не закроется. Совместное чтение: Разрешается последовательное открытие файла для чтения. Если этот флаг не указан, любой запрос на открытие файла с целью чтения не будет исполняться до тех пор, как файл не закроется. Совместная запись: Разрешается последовательное открытие файла с целью записи. Если этот флаг не указан, любой запрос на открытие файла с целью записи не будет исполняться до тех пор, пока файл не закроется. Совместное чтение/запись: Разрешается последовательное открытие файла с целью чтения или записи. Если этот флаг не указан, любой запрос на открытие файла с целью чтения или записи не будет исполняться до тех пор, пока файл не закроется. Совместное удаление: Разрешается последовательное удаление файла. Если этот флаг не указан, любой запрос на удаление файла не будет исполняться до тех пор, пока файл не закроется.
Совместное использование клиента SFA может быть дополнительно проиллюстрировано с помощью примеров. Например, Открытия файла без нарушения условий совместного использования: Клиент А открывает файл, используя FileAccess.Read и FileShare.Write (что отвергает последовательное чтение/запись при открытии). Клиент В затем открывает файл, используя FileAccess.Write с FileShare.Read (что отвергает последовательную запись/удаление при открытии). Результат: Это разрешается, поскольку нет конфликта между режимами доступа к файлу и файловыми общими ресурсами.
Нарушение условий совместного использования вследствие доступа к файлу: Клиент А открывает файл, используя FileAccess.Write и FileShare.Read (что отвергает последовательную запись/удаление при открытии). Клиент В затем открывает файл, используя FileAccess.Write с FileShare.Write (что отвергает последовательное чтение/удаление при открытии). Результат: Клиент В сталкивается с нарушением условий совместного использования, поскольку он указывает доступ к файлу, который отрицается режимом общего ресурса, указанного ранее клиентом А.
Нарушение условий совместного использования вследствие режима общего ресурса: Клиент А открывает файл, используя FileAccess.Write и FileShare.Write (что отвергает последовательное чтение/удаление при открытии). Клиент В затем открывает файл, используя FileAccess.Write с FileShare.Read (что отвергает последовательную запись/удаление при открытии). Результат: Клиент В сталкивается с нарушением условий совместного использования, поскольку он указал режим общего ресурса, который отвергает доступ с записью к файлу, который все еще открыт для доступа с записью.
Операция на основе REST может не открывать файл с использованием модификатора операции. Однако операция на основе REST учитывает режим общего ресурса, указанного для любого файла, открытого в клиенте SFA. Операции на основе REST, взаимодействующие с режимами общих ресурсов SMB, могут быть дополнительно проиллюстрированы с помощью примеров. Нарушение условий совместного использования во время операции получения файла на основе REST: Клиент SFA открывает файл, используя FileAccess.Read и FileShare.Write (что отвергает последовательное чтение/удаление при открытии). Клиент REST затем выполняет операцию получения файла (на основе API REST) в отношении файла (тем самым используя FileAccess.Read, как указано в таблице выше). Результат: Запрос клиента REST не исполнен с кодом 409 состояния (конфликт) и кодом ошибки SharingViolation, поскольку клиент SFA все еще имеет открытый файл, при этом отвергая доступ с чтением/удалением.
Нарушение условий совместного использования во время операции Put Range REST: Клиент SFA открывает файл, используя FileAccess.Write и FileShare.Read (что отвергает последовательную запись/удаление при открытии). Клиент REST затем выполняет операцию установления диапазона (на основе API REST) в отношении файла (тем самым используя FileAccess.Write, как указано в таблице выше). Результат: Запрос клиента REST не исполнен с кодом 409 состояния (конфликт) и кодом ошибки SharingViolation, поскольку клиент SFA все еще имеет открытый файл, при этом отвергая доступ с записью/удалением.
Предполагается, что режим совместного использования клиента SFA может иметь последствия для операций на основе REST. В зависимости от режима совместного использования, указываемого, когда клиент SFA открывает файл, файловая служба может возвращать сообщение о конфликте (например, код 409 состояния) с кодом ошибки SharingViolation. Файловая служба возвращает сообщение о нарушениях условий совместного использования вследствие того, что файлы открыты в клиенте SFA. В качестве примера, режим совместного использования файла клиентом SFA может быть совместным чтением, которое отвергает записи, и удалением. Как таковые операции создания файла, установки свойств файла, установки метаданных файла, удаления файла и операция Put range на основе REST не исполняются с указанием нарушения условий совместного использования. Файловая служба может возвращать сообщения о нарушениях условий совместного использования вследствие открытых файлов в клиентах SFA.
Компонент удаления отвечает за управление удалениями. Компонент удаления выполнен с возможностью обработки операции удаления на основе SFA и исполнения ее с использованием модификатора операции и обработки операции удаления на основе REST путем обращения к модификатору операции. Когда клиент SFA открывает файл для удаления, он маркирует файл как ожидающий удаления до тех пор, пока все другие манипуляторы открытия файла в клиенте SFA не будут закрыты. Пока файл маркирован как ожидающий удаления, любые операции на основе REST в отношении файла будут возвращать код состояния «конфликт» с идентификатором кода ошибки (например, SMBDeletePending). Код 404 состояния не возвращается, поскольку клиент SFA может удалить флаг ожидания удаления до закрытия файла. Другими словами, код 404 состояния (не найден) ожидается, когда файл был удален. Кроме того, когда файл находится в состоянии ожидания удаления SMB, он может быть не включен в результаты списка файлов. Предполагается, что операции удаления файла и удаления каталога на основе REST совершаются вместе и не приводят к состоянию ожидания удаления.
Компонент атрибутов выполнен с возможностью управления последствиями файловых атрибутов на операции на основе REST. Клиенты SFA, использующие операции на основе SFA, могут читать и устанавливать файловые атрибуты, включающие в себя «архивный», «только для чтения», «скрытый» и «системный». Если файл или каталог имеют установленный атрибут «только для чтения» (даже если он открыт в SMB с использованием совместного чтения), тогда любая операция на основе REST, которая пытается совершить запись в файле, может быть не исполнена с кодом 412 состояния (заданное условие не выполнено) и идентификатором кода ошибки (например, ReadOnlyAttribute). Эти операции на основе REST могут включать в себя: создание файла, установку свойств файла, установку метаданных файла и задать диапазон. Кроме того, предполагается, что файловые атрибуты могут не быть установленными или считанными с клиентов REST. Как только файл сделан предназначенным «только для чтения», клиенты REST будут неспособны выполнять запись в файл до тех пор, пока клиент SFA не удалит атрибут «только для чтения».
Возвращаясь вновь к Фиг. 2D, файловая служба поддерживает ресурсы 270 схемы файловой службы. Соответственно, интерфейс SFA-REST обеспечивает осуществление доступа к файлам на основе схемы. Каждый из клиента SFA или клиента REST может генерировать операцию на основе SFA или операцию на основе REST, соответственно, которая предназначена для осуществления доступа к файлу файловой системы, используя схему, реализуемую на основе интерфейса SFA-REST. В этой связи, поля схемы содержат элементы интерфейса SFA-REST, который поддерживает параллельный доступ на основе SFA и на основе REST к файловой системе.
Схема может быть логической схемой. Предполагается, что физическое представление схемы может быть разным для того, чтобы учитывать нюансы основной базы данных. Физическое представление схемы может также изменяться, чтобы она могла быть обратно совместимой. Схема может быть основана на множестве таблиц. В одной реализации схема включает в себя 8 таблиц доступа к файлам и таблицу общих ресурсов. Главная таблица может быть таблицей пространства имен, в которой файлы и каталоги сохранены на основе их имен. Таблица пространства имен может включать в себя имя общего ресурса. Таблица пространства имен может иерархической в том смысле, что файлы и каталоги сохраняются в качестве дочерних элементов их родительского каталога. Полный путь к файлу или каталогу определяется на основе множественных поисков в таблице пространства имен. Файлы могут включать в себя ID в таблице, который используется для поиска информации о файле в другой таблице доступа.
Схема может дополнительно включать в себя информационную таблицу. Информационная таблица может быть использована для хранения информации о содержимом файла. Информационная таблица не хранит само содержимое файла. Наиболее важным элементом в этой таблице является ID файла.
Схема может также поддерживать таблицу диапазонов страниц. Таблица диапазонов страниц может быть использована для хранения актуальных данных для сохраненного файла. Наиболее важные элементы таблицы диапазонов страниц включают в себя ID файла и смещение размера диапазона страницы, которое сохраняется.
Схема может дополнительно поддерживать таблицу манипуляторов. Таблица манипуляторов может быть использована для представления манипуляторов, которые были открыты в файле. Таблица манипуляторов поддерживает открытие или создание файлов, которые возвращают манипулятор файла в файловую систему. Когда манипулятор возвращен, клиент может читать и выполнять запись в файле, используя манипулятор.
Схема также поддерживает таблицу аренды. Таблица аренды может быть использована для поддержки аренд SMB, которые обеспечивают кэширование файла на основе модификаторов операций. В частности, таблица аренды может быть использована для сохранения состояния аренды на основе модификаторов операции в отношении операции на основе SFA, связанной с соответствующим файлом.
Две дополнительные таблицы доступа могут быть выполнены в схеме для хранения настроек и событий уведомления об изменениях в отношении каталогов. Эти две таблицы могут быть таблицей уведомления об изменениях и таблицей событий уведомления об изменениях. В частности, таблица уведомления об изменениях может быть обновлена, когда операция регистрирует обнаружение изменений внутри каталога. Каждый раз, когда выполняется операция записи в отношении файла, соответствующая операция выполняется для проверки таблицы уведомления об изменениях, чтобы опередить, требуется ли ввести в таблицу событий данные.
Таблица блокировки байтов может быть использована для хранения блокировки байтового диапазона в отношении файла. Блокировки байтового диапазона могут быть получены через файловую службу. Блокировка байтового диапазона относится к сценарию, в котором клиент SFA запрашивает эксклюзивный доступ к диапазону файла, а также доступ с чтением к диапазону файла. Это гарантирует, что нет других операций записи внутри диапазона, но разрешены операции чтения.
Возвращаясь вновь к Фиг. 2D, множество балансировщиков нагрузки (не показано) может быть реализовано для разделов в облачной вычислительной инфраструктуре. Транзакции, которые исполняются на атомарном уровне, исполняются в пределах одного раздела. В качестве справки, атомарная транзакция относится к последовательности операций базы данных, которые либо все происходят, либо ничего не происходит. Гарантия атомарности предотвращает обновления базы данных, происходящие только частично, что может привести к большим проблемам, чем отторжение всей последовательности сразу. Атомарность относится к неразделимости и невозможности сведения. В одном варианте осуществления схема разделена на уровне общих ресурсов. В этой связи, транзакция в отношении общего ресурса может быть реализована в пределах одного раздела. Схема может дополнительно позволять увеличивать количество ключевых элементов, которые являются частью ключевого разделительного элемента, так, чтобы общий ресурс мог быть сохранен во множестве разделов. Это может позволить сохранить один общий ресурс на множестве серверных узлов, что приведет к лучшей производительности.
Файловая служба поддерживает компонент моментального снимка, которые реализует выполнение моментального снимка, чтобы быстро и легко создавать резервную копию хранилища файлов. Схема обеспечивает выполнение моментального снимка. Таблица общих ресурсов в схеме поддерживает операции выполнения моментального снимка. В частности, новые изменения могут быть записаны в типе шаблона «копирование при записи», чтобы можно было позднее осуществлять доступ к старым версиям на каждом моментальном снимке. В нормальном состоянии перед тем, как сделать моментальный снимок, таблица общих ресурсов может иметь запись для каждого общего ресурса. Схема таблицы общих ресурсов содержит разрешения доступа в отношении общего ресурса, указание, является ли строка верной или неверной, последнее время модификации, время истечения и версию моментального снимка, которые обеспечивают выполнение операций моментального снимка.
Моментальный снимок общих ресурсов может быть основан на 3 операциях. Операция обновления обновляет таблицу общих ресурсов для указания, что будет создан моментальный снимок. Операция обновления и создания содержит добавление новой строки с идентификатором версии моментального снимка и обновление строки с идентификатором версии моментального снимка, чтобы включить в нее отметку времени моментального снимка. На данной стадии, если есть какие-либо клиенты, осуществляющие записи в общий ресурс, эти записи продолжаться с версией 0 моментального снимка. Если моментальный снимок не выполнен, операция удаляет версию 0 моментального снимка, так как она истекла 1 днем ранее. Операция уведомления о записи содержит уведомление узла, который поддерживает общий ресурс начинать записывать новую версию моментального снимка общего ресурса. И вновь, если произойдет неудача, это приведет к записи старой версии моментального снимка, и удаление может произойти позже. Третья операция представляет собой операцию завершения обновления, которая обновляет таблицу общих ресурсов для указания, что моментальный снимок выполнен успешно. Файловая служба может отправлять уведомление клиенту о том, что моментальный снимок выполнен успешно. Если изменения не могут быть выполнены в таблице, клиенты будут осуществлять запись в версию 1, которая также является верной.
Компонент моментального снимка дополнительно поддерживает сбор ненужных данных. Сбор ненужных данных может быть выполнен в отношении таблицы общих ресурсов после неудачи операции моментального снимка. Например, строка, имеющая неудачную версию моментального снимка, может автоматически очистить себя после заданного периода времени. Кроме того, компонент моментального снимка создает другой моментальный снимок, таблица может обновляться, и узел, осуществляющий запись в общий ресурс, может осуществлять запись в версию 2 моментального снимка.
Компонент моментального снимка может дополнительно поддерживать атомарные моментальные снимки, неатомарные моментальные снимки и атомарный моментальный снимок для перекрестного совместного использования. Компонент моментального снимка может осуществлять связь с узлами для создания атомарного моментального снимка. Каждый узел способен модифицировать раздел файловой схемы. В частности, каждый узел способен на атомарном уровне модифицировать раздел. Компонент моментального снимка может отправлять уведомления узлам. Процесс выполнения атомарного моментального снимка содержит два уведомления. Уведомление о блокировке предписывает одному или более узлам блокировать операции записи в выбранном разделе. Уведомление о блокировке может включать в себя фиксированный период времени, в течение которого необходимо блокировать операции записи в выбранном разделе. Уведомление о записи предписывает одному или более узлам начинать запись новой версии моментального снимка. Если операция записи не может быть завершена, в том смысле, что все из одного или более узлов не могут начать запись новой версии в течение фиксированного периода времени, компонент моментального снимка может не исполнять моментальный снимок. Компонент моментального снимка может после неудачи пытаться выполнить другую операцию моментального снимка. Новая операция моментального снимка может создавать новый моментальный снимок в качестве новой версии.
Компонент моментального снимка может также обеспечивать создание неатомарного моментального снимка. Неатомарный моментальный снимок может быть создан с использованием одного уведомления о записи. Компонент моментального снимка может передавать уведомление, предписывающее одному или более узлам начинать запись новой версии моментального снимка. Компонент моментального снимка может затем обновлять таблицу общих ресурсов, когда все из одного или более узлов используют новую версию моментального снимка.
Компонент моментального снимка может также обеспечивать создание атомарного моментального снимка для перекрестного совместного использования. Атомарный моментальный снимок для перекрестного совместного использования может относится к снимку, который может расширить на множество общих ресурсов. Компонент моментального снимка выполняет последовательность операций для осуществления атомарного моментального снимка для перекрестного совместного использования. Компонент моментального снимка может добавлять новую строку в таблицу общих ресурсов, которая являются частью моментального снимка. Компонент моментального снимка затем передает уведомление о записи, предписывающее одному или более узлам, соответствующим общим ресурсам моментального снимка, начинать запись новой версии моментального снимка. Компонент моментального снимка может затем обновлять таблицу общих ресурсов. Клиент SFA или клиент REST может обращаться к версии моментального снимка на основе отметки времени, связанной с версией моментального снимка. Отметка времени может быть назначена версиям моментальных снимков из множества общих ресурсов. В этой связи, общие ресурсы версии моментального снимка с одной и той же отметкой времени могут быть конструктивно связаны.
Со ссылкой теперь на Фиг. 3 предложена блок-схема, которая иллюстрирует способ 300 осуществления доступа к файлам в распределенных файловых системах. Сначала на этапе 300 принимается операция на основе SFA, имеющая модификатор операции для файла в распределенной файловой системе. Операция на основе SFA задается на основе интерфейса передачи состояния представления (REST) файла. Интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST. На этапе 310 обеспечивается операция на основе REST для файла в распределенной файловой системе, причем операция на основе REST задается на основе интерфейса SFA-REST. На этапе 330 операция на основе SFA исполняется с использованием модификатора операции. На этапе 340 к модификатору операции обращаются с тем, чтобы исполнить операцию на основе REST. Операция на основе REST исполняется на основе интерфейса SFA-REST.
Со ссылкой теперь на Фиг. 4 предложена блок-схема, которая иллюстрирует способ 400 выполнения моментального снимка общих файловых ресурсов. Сначала на этапе 410 обновляется таблица общих ресурсов, содержащая общий файловый ресурс. Обновление таблицы общих ресурсов содержит добавление строки в таблицу общих ресурсов, причем строка связана с новой версией общего файлового ресурса. На этапе 420 уведомление, предписывающее узлу начинать запись новой версии общего файлового ресурса, передается узлу, связанному с общим файловым ресурсом. На этапе 430 определяется, что узел записывает новую версию общего файлового ресурса. На этапе 440 таблица общих ресурсов обновляется для указания, что моментальный снимок выполнен успешно.
Со ссылкой на Фиг. 5 предложена блок-схема, которая иллюстрирует способ 500 для осуществления доступа к файлам в распределенных файловых системах. Сначала на этапе 510 из клиента SFA принимается операция на основе SFA для файла в распределенной файловой системе. Операция на основе SFA имеет модификатор операции, который указывает уступающую блокировку операции на основе SFA. Операция на основе SFA задается на основе интерфейса SFA-REST. На этапе 520 операция на основе REST исполняется в отношении файла путем обращения к модификатору операции для операции на основе SFA. На этапе 530 из клиента REST принимается операция на основе REST для файла в распределенной файловой системе. Операция на основе REST исполняется в отношении файла путем обращения к модификатору операции для операции на основе SFA.
Блок-схема на Фиг. может быть дополнительно описана с помощью примеров. Как отмечено выше, уступающая блокировка (oplock) SMB представляет собой механизм кэширования, который клиенты SMB могут запрашивать для того, чтобы улучшать производительность и уменьшать сетевые передачи. Как таковое самое последнее состояние определенного файла или каталога может быть кэшировано в клиенте SMB. Имеется множество типов уступающей блокировки, упоминаемых как типы аренды SMB: Чтение (R): При получении клиент может осуществлять чтение из локального кэша; Запись (W): При получении клиент может осуществлять запись локально без необходимости сброса данных назад в службу SMB; Манипулирование (H): При получении клиент не должен мгновенно уведомлять службу SMB о том, когда происходит закрытие манипулятора. Уступающая блокировка полезна в случае, когда приложение продолжает открывать и закрывать файлы при одном и том же режиме доступа и совместного использования. Важно отметить, что вышеуказанные типы аренды SMB не зависят от указанного режима доступа и совместного использования. Как правило, клиент SFA пытается получать все типы аренды всякий раз, когда он открывает новый манипулятор в отношении файла, вне зависимости от режима доступа и совместного использования.
В зависимости от вызванной операции REST может быть необходимо, чтобы запрос прекращал существующую уступающую блокировку. В случае уступающей блокировки записи клиент SMB должен сбрасывать кэшированные изменения в файловую службу. Далее приведены некоторые из причин, при которых требуется прекращать каждый тип уступающей блокировки: Уступающую блокировку чтения (R) требуется прекращать всякий раз, когда выдается операция записи, такая как Put Range; Уступающую блокировку записи (W) требуется прекращать всякий раз, когда выдается операция чтения, такая как получение файла; Уступающую блокировку манипулирования (H) требуется прекращать всякий раз, когда клиент выдает операцию удаления, поскольку файловая служба требует, чтобы никакие манипуляторы не могли быть открыты, если необходимо успешно выполнить операцию удаления. Уступающие блокировки манипулирования также прекращаются, когда операция REST сталкивается с нарушением условий совместного использования в отношении существующего манипулятора SMB (см. таблицу выше), чтобы проверить, является(ются) ли манипулятор(ы) в действительности все еще открытым(и) посредством приложения в клиенте.
Прекращение уступающей блокировки может требовать сброс кэшированных изменений клиента SMB, что может вызвать задержки времени ответа на операцию или может обусловить неисполнение операции с кодом 408 состояния (время ожидания запроса) и кодом ошибки ClientCacheFlushDelay. Далее приведены некоторые сценарии, в которых происходит прекращение уступающих блокировок:
В первом примере требуются прекращение уступающей блокировки и сброс данных клиента SMB, и клиент REST столкнулся с задержкой: (1) Клиент SMB открывает файл, получает данные об уступающей блокировке RWH и записывает данные локально. (2) Клиент REST отправляет запрос на получение файла. (2)(i) Файловая служба прекращает уступающую блокировку записи (W), оставляя в отношении клиента уступающую блокировку RH. (2)(ii) Клиент SMB сбрасывает свои кэшированные данные в файловую службу и подтверждает прекращение уступающей блокировки. (2)(iii) Файловая служба обрабатывает запрос на получение файла и возвращает назад ответ с запрошенными данными. В вышеописанном примере клиент REST может сталкиваться с задержками, вызванными прекращением уступающей блокировки и временем, требуемым клиенту SMB для сброса своих данных в файловую службу. Следует отметить, что последующие запросы на получение файла не будут подвергаться каким-либо дополнительным задержкам, поскольку уступающая блокировка записи (W) уже была прекращена.
Во втором примере требуется прекращение уступающей блокировки, но клиент REST не сталкивается с задержкой. (1) Клиент SMB получил уступающую блокировку RH. (2) Клиент REST выдает запрос Put Range. (2)(i) Файловая служба отправляет запрос на прекращение уступающей блокировки клиенту SMB, но она не ожидает ответа. (2)(ii) Файловая служба обрабатывает запрос Put Range. В вышеописанном примере требуется прекращение уступающей блокировки, но запрос Put Range не будет испытывать каких-либо дополнительных задержек, поскольку ответ не требуется при прекращении уступающей блокировки чтения.
Существует несколько операций в том случае, когда режим работы файловой службы для каждой операции REST основан на состоянии уступающей блокировки клиента SMB, который уже получил манипулятор в отношении то же файла, и когда предполагается, что манипулятор SMB доступа и совместного использования не находится в конфликте с операцией REST. Если конфликт имеется, то уступающая блокировка манипулирования также прекращается, чтобы с надежностью удостовериться, что манипулятор все еще открыт в клиенте. В случае блокирования прекращения уступающей блокировки, файловая служба может ожидать подтверждения, что прекращение была успешной. В случае отсутствия блокирования прекращения уступающей блокировки, она не должна ожидать подтверждения.
В случае, когда требуется блокирование прекращения уступающей блокировки, если прекращение не выполняется успешно в течение указанного времени ожидания запроса или в течение 30 секунд, вне зависимости от того, какое из них истечет первым, операция REST не будет исполняться с кодом 408 состояния (время ожидания запроса) и кодом ошибки ClientCacheFlushDelay. Предполагается, что запрос Delete File также требует прекращения аренды манипулятора (Н) уступающей блокировки. Это гарантирует, что какие-либо файловые манипуляторы все еще в действительности открыты посредством приложения в клиенте SMB, когда клиент REST выдает Delete. Если есть нарушение совместного использования, запрос не будет исполнен с кодом 409 состояния (конфликт) и кодом ошибки SharingViolation.
Со ссылкой на Фиг. 6 предложена блок-схема, которая иллюстрирует способ 500 осуществления доступа к файлам в распределенных файловых системах. Сначала на этапе 610 из клиента SFA принимается операция на основе SFA для файла в распределенной файловой системе. Операция на основе SFA имеет модификатор операции, который указывает режим совместного доступа операции на основе SFA. Операция на основе SFA задается на основе интерфейса SFA-REST. На этапе 620 операция на основе REST исполняется в отношении файла путем обращения к модификатору операции для операции на основе SFA. На этапе 630 из клиента REST принимается операция на основе REST для файла в распределенной файловой системе. Операция на основе REST задается на основе интерфейса SFA-REST. На этапе 640 операция на основе REST исполняется в отношении файла путем обращения к модификатору операции для операции на основе SFA.
Блок-схема на Фиг. может быть дополнительно описана с помощью примеров. Нарушение условий совместного использования во время операции получения файла на основе REST может произойти, когда клиент SMB открывает файл, используя FileShare.Write (а не FileShare.Read, что означало бы, что другим клиентам разрешено читать файл в одно и то же время). Клиент REST затем выполняет операцию получения файла (на основе API REST) в отношении файла (тем самым используя FileAccess.Read, как указано в таблице выше). Это приводит к неисполнению запроса клиента REST с кодом 409 состояния (конфликт) и кодом ошибки SharingViolation, поскольку клиент SMB все еще имеет открытый файл, при этом отвергая доступ с чтением/удалением.
Ссылаясь на таблицу 1, можно определить несколько разных режимов доступа SMB, когда операция на основе REST принимается с тем, чтобы операция на основе REST была исполнена на основе режима доступа.
Таблица 1
Таблица 2
(Запрет чтения, записи, удаления)
Создать файл
Получить файл
Установить свойства файла
Установить метаданные файла
Удалить файл
Установить диапазон
Составить список диапазонов
(Запрет записи, удаления)
Создать файл
Установить свойства файла
Установить метаданные файла
Удалить файл
Установить диапазон
(Запрет чтения, удаления)
Создать файл
Получить файл
Удалить файл
Составить список диапазонов
(Запрет чтения, записи)
Создать файл
Получить файл
Установить свойства файла
Установить метаданные файла
Установить диапазон
Составить список диапазонов
(Запрет удаления)
Создать файл
Удалить файл
(Запрет записи)
Создать файл
Установить свойства файла
Установить метаданные файла
Установить диапазон
(Запрет чтения)
Получить файл
Составить список диапазонов
(Ничего не запрещено)
Как показано в таблице 1, операции составления списка файлов (на основе API REST), получения свойств файла (на основе API REST) и получения метаданных файла (на основе API REST) не выполняются в отношении содержимого файла SMB и не требуют доступа с чтением к этому файлу (т.е. эти операции будут все еще успешно выполняться, даже если клиент SMB имеет файл, открытый для исключительного доступа с чтением).
Кроме того, предполагается, что в зависимости от указанного режима совместного использования, когда клиент SMB открывает файл, служба REST может возвращать код 409 состояния (конфликт) с кодом ошибки SharingViolation, как описано в таблице 2.
Варианты осуществления настоящего изобретения были описаны применительно к определенным вариантам осуществления, которые, как подразумевается во всех аспектах, являются иллюстративными, а не ограничительными. Альтернативные варианты осуществления будут очевидны специалистам в данной области техники, к которой имеет отношение настоящее изобретение, без отступления от его объема.
Исходя из вышесказанного, должно быть понятно, что данное изобретение само по себе выполнено с возможностью достижения всех целей и осуществления всех задач, описанных в данном документе и изложенных вместе с другими преимуществами, которые являются очевидными и свойственными данной структуре.
Должно быть понятно, что конкретные признаки и их подкомбинации обладают применимостью и могут быть использованы без ссылки на другие признаки или подкомбинации. Это подразумевается и заключено в объеме формулы изобретения.
| название | год | авторы | номер документа |
|---|---|---|---|
| ОБЕСПЕЧЕНИЕ ПРОЗРАЧНОЙ ОТРАБОТКИ ОТКАЗА В ФАЙЛОВОЙ СИСТЕМЕ | 2011 |
|
RU2595482C2 |
| МНОГОКАНАЛЬНЫЕ СОЕДИНЕНИЯ В СЕАНСАХ ФАЙЛОВОЙ СИСТЕМЫ | 2011 |
|
RU2595752C2 |
| ПРОЗРАЧНОЕ ВОССТАНОВЛЕНИЕ ПОСЛЕ ОТКАЗА | 2012 |
|
RU2595903C2 |
| СПОСОБ И СИСТЕМА ДЛЯ ТРАНЗАКЦИОННЫХ ФАЙЛОВЫХ ОПЕРАЦИЙ ПО СЕТИ | 2004 |
|
RU2380749C2 |
| ОТОБРАЖЕНИЕ ОБНАРУЖЕННЫХ ЭЛЕМЕНТОВ УНИВЕРСАЛЬНОГО РЕЖИМА "ПОДКЛЮЧАЙ И РАБОТАЙ" НА МЕСТОПОЛОЖЕНИЕ SMB | 2007 |
|
RU2448362C2 |
| МНОГОПРОТОКОЛЬНОЕ УСТРОЙСТВО ХРАНЕНИЯ ДАННЫХ, РЕАЛИЗУЮЩЕЕ ИНТЕГРИРОВАННУЮ ПОДДЕРЖКУ ФАЙЛОВЫХ И БЛОЧНЫХ ПРОТОКОЛОВ ДОСТУПА | 2003 |
|
RU2302034C9 |
| БЕЗОПАСНЫЙ ДОСТУП К ДАННЫМ ПОСЛЕ СБОЯ ХРАНИЛИЩА | 2015 |
|
RU2683167C2 |
| Система и способ перехвата файловых потоков | 2023 |
|
RU2816551C1 |
| ФАЙЛОВАЯ СИСТЕМА, ПРЕДСТАВЛЕННАЯ ВНУТРИ БАЗЫ ДАННЫХ | 2006 |
|
RU2398275C2 |
| ОБЕСПЕЧЕНИЕ СЛУЖБЫ-СВИДЕТЕЛЯ | 2012 |
|
RU2601863C2 |
Изобретение относится к системам и способам осуществления доступа к файлам в распределенной файловой системе. Технический результат заключается в обеспечении доступа к файлам в распределенной файловой системе. В способе принимают операцию для файла в интерфейсе протокола совместного файлового доступа (SFA) - протокола передачи состояния представления (REST) (интерфейсе SFA-REST); осуществляют доступ к файловой службе для выполнения операции, соответствующей упомянутому файлу, причем файловая служба содержит множество таблиц, каковое множество таблиц хранит состояния файлов в распределенной файловой системе, причем интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST для осуществления доступа к файлам в распределенной файловой системе; обрабатывают упомянутую операцию на основе интерфейса SFA-REST и выполняют эту операцию на основе, по меньшей мере, отчасти идентификации состояния файла для упомянутого файла, которое сохранено согласно схеме файловой службы упомянутой файловой службы. 6 н. и 34 з.п. ф-лы, 2 табл., 9 ил.
1. Система для осуществления доступа к файлам в распределенной файловой системе, содержащая один или более аппаратных процессоров и машиночитаемые носители, на которых сохранены машиноисполняемые инструкции, которые при их исполнении одним или более аппаратными процессорами предписывают одному или более аппаратным процессорам реализовывать компонент интерфейса протокола совместного файлового доступа (SFA) - протокола передачи состояния представления (REST) (интерфейса SFA-REST), выполненного с возможностью:
принимать одну или более основывающихся на SFA операций для файлов в распределенной файловой системе;
обрабатывать эти одну или более основывающихся на SFA операций на основе интерфейса SFA-REST, при этом интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST;
принимать одну или более основывающихся на REST операций для файлов в распределенной файловой системе;
обрабатывать эти одну или более основывающихся на REST операций на основе интерфейса SFA-REST;
выполнять основывающуюся на SFA операцию в отношении первого файла;
выполнять основывающуюся на SFA операцию в отношении второго файла; и
выполнять основывающуюся на REST операцию в отношении второго файла, отчасти на основе обращения к выполняющейся в текущий момент основывающейся на SFA операции, осуществляющей доступ ко второму файлу.
2. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит компонент доступа к данным, выполненный с возможностью возвращать дескриптор, соответствующий первому файлу, для основывающейся на SFA операции, не возвращая при этом дескриптор, соответствующий второму файлу, для основывающейся на REST операции.
3. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит компонент аренды для доступа, выполненный с возможностью:
предоставлять аренду REST для второго файла, при этом арендой REST поддерживается доступ ко второму файлу для совместного чтения и эксклюзивной записи; и
предоставлять совместный доступ к файлам на основе аренд REST или дескрипторов модификаторов операций, связанных с этими файлами, при этом упомянутые одна или более основывающихся на SFA операций включают в себя модификаторы операций, которыми задается ограничение, которое модифицирует эти одну или более основывающихся на SFA операций.
4. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит компонент кэша, выполненный с возможностью:
идентифицировать уступающую блокировку, связанную с модификаторами операций упомянутых одной или более основывающихся на SFA операций, причем уступающая блокировка указывает, что самое последнее состояние файлов кэшировано в клиенте SFA, связанном с основывающимися на SFA операциями;
определять прекратить уступающую блокировку основывающихся на SFA операций путем обращения к модификаторам операции; и
выполнять операцию прекращения уступающей блокировки, чтобы были выполнены упомянутые одна или более основывающихся на REST операций.
5. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит компонент кэша, выполненный с возможностью генерировать множество отметок времени для файлов в распределенной файловой системе как для упомянутых одной или более основывающихся на SFA операций, так и для упомянутых одной или более основывающихся на REST операций, причем данное множество отметок времени включает в себя, по меньшей мере, отметку времени метки объекта (ETAG) и одно или более из времени создания, времени последней модификации, времени последней записи и времени последнего доступа, при этом отметка времени ETAG обновляется как для упомянутых одной или более основывающихся на REST операций, так и для упомянутых одной или более основывающихся на SFA операций для поддержки оптимистичного параллелизма.
6. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит:
компонент метаданных, выполненный с возможностью предоставления набора ограниченных имен для метаданных, соответствующих упомянутым одной или более основывающимся на SFA операциям и упомянутым одной или более основывающимся на REST операциям; и
компонент именования и обращения, выполненный с возможностью реализации системы имен каталогов и имен файлов, нечувствительных к регистру и с сохранением регистра.
7. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит компонент блокировки байтов, выполненный с возможностью отклонения операций чтения или операций записи среди упомянутых одной или более основывающихся на REST операций, когда имеет место конфликт применительно к логике блокировок байтового диапазона упомянутых одной или более основывающихся на SFA операций, причем основывающаяся на SFA блокировка байтового диапазона определяет доступ на чтение и запись к областям файлов.
8. Система по п. 1, в которой компонент интерфейса SFA-REST дополнительно содержит компонент блокировки, выполненный с возможностью реализации модификаторов блокировки, связанных с упомянутыми одной или более основывающимися на SFA операциями, причем доступ к файлам обрабатывается на основе модификаторов блокировки этих одной или более основывающихся на SFA операций.
9. Система по п. 1, дополнительно содержащая схему файловой службы, содержащую множество таблиц, причем это множество таблиц хранит состояния файлов в распределенной файловой системе, при этом данное множество таблиц содержит поля, соответствующие элементам интерфейса SFA-REST.
10. Система по п. 1, дополнительно содержащая компонент моментального снимка, выполненный с возможностью выполнения моментального снимка общего файлового ресурса для резервного копирования содержимого этого общего файлового ресурса, при этом общий файловый ресурс содержит изменения в отношении общего файлового ресурса, записанные в общий файловый ресурс с использованием механизма копирования при записи, так чтобы доступ к предыдущей версии при каждом моментальном снимке мог осуществляться независимо, при этом выполнение моментального снимка общего файлового ресурса основывается на одном из:
атомарной операции выполнения моментального снимка, содержащей двухпроходную операцию уведомления и инструкции записи;
неатомарной операции выполнения моментального снимка, содержащей однопроходную операцию инструкции записи; или
атомарной операции выполнения моментального снимка для перекрестного совместного использования, содержащей создание моментальных снимков множественных общих файловых ресурсов.
11. Система по п. 1, дополнительно содержащая компонент моментального снимка, содержащий таблицу общих ресурсов, имеющую схему, которая представляет файлы и моментальные снимки общего файлового ресурса, при этом таблица общих ресурсов содержит запись для общего файлового ресурса и одну или более записей для моментальных снимков общего файлового ресурса.
12. Система для осуществления доступа к файлам в распределенной файловой системе, содержащая один или более аппаратных процессоров и машиночитаемые носители, на которых сохранены машиноисполняемые инструкции, которые при их исполнении одним или более аппаратными процессорами предписывают одному или более аппаратным процессорам реализовывать схему файловой службы, содержащую множество таблиц, причем в этом множестве таблиц хранятся состояния файлов в распределенной файловой системе, при этом данное множество таблиц содержит поля, соответствующие интерфейсу протокола совместного файлового доступа (SFA) - протокола передачи состояния представления (REST) (интерфейсу SFA-REST), при этом интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST для осуществления обращения между одной или более основывающимися на REST операциями и одной или более основывающимися на SFA операциями, одновременно выполняющимися для доступа к файлам в распределенной файловой системе.
13. Система по п. 12, в которой схема файловой службы дополнительно содержит иерархические таблицы для хранения файлов и каталогов на основе соответствующих имен файлов и каталогов, при этом файлы и каталоги извлекаются с использованием поисков по таблице пространства имен, хранящей множество идентификаторов файлов.
14. Система по п. 12, дополнительно содержащая таблицу пространства имен, причем таблица пространства имен является главной таблицей схемы файловой службы.
15. Система по п. 12, дополнительно содержащая информационную таблицу для файлов, причем в информационной таблице для файлов хранится информация о содержимом файлов, при этом информационная таблица для файлов содержит множество полей отметок времени для файлов.
16. Система по п. 12, дополнительно содержащая таблицу диапазонов страниц для файлов, причем в таблице диапазонов страниц для файлов содержатся данные, относящиеся к файлам, при этом ключ для данной таблицы содержит идентификатор файла и смещение размера сохраняемого диапазона страниц для файла.
17. Система по п. 12, дополнительно содержащая таблицу дескрипторов, причем в таблице дескрипторов содержатся один или более дескрипторов открытия для одной или более операций интерфейса SFA-REST.
18. Система по п. 12, дополнительно содержащая таблицу аренды, причем в таблице аренды хранятся аренды, связанные с файлами.
19. Система по п. 12, дополнительно содержащая таблицу уведомления об изменениях и таблицу событий уведомления об изменениях, при этом таблица уведомления об изменениях обновляется при регистрации обнаружения изменений внутри каталога, и таблица событий уведомления об изменениях обновляется при возникновении события, которое сохраняется.
20. Система по п. 12, дополнительно содержащая таблицу блокировок байтового диапазона, причем в таблице блокировок байтового диапазона хранятся блокировки для файлов с использованием, по меньшей мере, идентификатора блокировки и идентификатора дескриптора.
21. Компьютерно-реализуемый способ осуществления доступа к файлам в распределенной файловой системе, содержащий этапы, на которых:
принимают основывающуюся на протоколе совместного файлового доступа (SFA) операцию для файла в распределенной файловой системе из клиента SFA, причем основывающаяся на SFA операция имеет модификатор операции, который указывает уступающую блокировку основывающейся на SFA операции, при этом основывающаяся на SFA операция задается на основе интерфейса протокола SFA - протокола передачи состояния представления (REST) (интерфейса SFA-REST);
обрабатывают основывающуюся на SFA операцию в отношении файла на основе обращения к модификатору операции этой основывающейся на SFA операции;
принимают основывающуюся на REST операцию для файла в распределенной файловой системе из клиента SFA, причем основывающаяся на REST операция задается на основе интерфейса SFA-REST;
обрабатывают основывающуюся на REST операцию на основе интерфейса SFA-REST;
выполняют основывающуюся на SFA операцию в отношении файла;
выполняют основывающуюся на REST операцию в отношении файла на основе обращения к модификатору операции выполняющейся в текущий момент основывающейся на SFA операции.
22. Способ по п. 21, в котором упомянутое восполнение основывающейся на REST операции в отношении файла на основе обращения к модификатору операции дополнительно содержит этапы, на которых:
идентифицируют уступающую блокировку, связанную с модификатором операции упомянутой основывающейся на SFA операции, причем уступающая блокировка указывает, что самое последнее состояние файла кэшировано в клиенте SFA, связанном с этой основывающейся на SFA операцией;
определяют прекратить уступающую блокировку основывающейся на SFA операции на основе обращения к упомянутому модификатору операции; и
выполняют операцию прекращения уступающей блокировки, чтобы была выполнена основывающаяся на REST операция.
23. Способ по п. 21, в котором клиент SFA получает уступающую блокировку, содержащую одно или более из следующего:
чтение (R), при котором клиент SFA осуществляет чтение локально;
запись (W), при которой клиент осуществляет запись локально;
манипулирование (H), при котором клиент SFA не отправляет мгновенно уведомление о том, когда происходит закрытие дескриптора; при этом
уступающую блокировку чтения (R) прекращают, когда основывающаяся на REST операция представляет собой операцию записи;
уступающую блокировку записи (W) прекращают, когда основывающаяся на REST операция представляет собой операцию чтения; и
уступающую блокировку манипулирования (Н) прекращают, когда основывающаяся на REST операция представляет собой операцию удаления.
24. Способ по п. 23, в котором уступающую блокировку манипулирования (Н) прекращают, когда основывающаяся на REST операция инициирует нарушение условий совместного использования применительно к дескриптору основывающейся на SFA операции, причем режим доступа и режим совместного использования основывающейся на SFA операции отличаются от уступающей блокировки.
25. Способ по п. 23, в котором операция прекращения уступающей блокировки содержит:
сброс кэшированных изменений клиента протокола блока серверных сообщений (SMB); и
передачу уведомления о неудачном выполнении операции для сброса кэша клиента с задержкой на заданное время ожидания запроса.
26. Компьютерно-реализуемый способ осуществления доступа к файлам в распределенной файловой системе, содержащий этапы, на которых:
принимают основывающуюся на протоколе совместного файлового доступа (SFA) операцию для файла в распределенной файловой системе из клиента SFA, причем основывающаяся на SFA операция имеет модификатор операции, который указывает режим совместного доступа основывающейся на SFA операции, при этом основывающаяся на SFA операция задается на основе интерфейса протокола SFA - протокола передачи состояния представления (REST) (интерфейса SFA-REST);
обрабатывают основывающуюся на SFA операцию на основе интерфейса SFA-REST, причем интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST;
выполняют основывающуюся на SFA операцию на основе модификатора операции;
принимают основывающуюся на REST операцию для файла в распределенной файловой системе из клиента REST;
обрабатывают основывающуюся на REST операцию на основе интерфейса SFA-REST; и
выполняют основывающуюся на REST операцию в отношении файла на основе обращения к модификатору операции выполняющейся в текущий момент основывающейся на SFA операции.
27. Способ по п. 26, в котором основывающаяся на REST операция представляет собой операцию создания файла, причем операцию создания файла выполняют, только когда модификатор режима совместного доступа содержит одно из следующего: режим совместного использования с записью и режим совместного использования с записью/удалением.
28. Способ по п. 26, в котором основывающаяся на REST операция представляет собой операцию получения файла или операцию составления списка диапазонов, причем операцию получения файла или операцию составления списка диапазонов выполняют, только когда модификатор режима совместного использования содержит режим совместного использования с чтением.
29. Способ по п. 26, в котором основывающаяся на REST операция представляет собой операцию установления диапазона, операцию установления свойств или операцию установления метаданных файла, причем операцию установления диапазона, операцию установления свойств или операцию установления метаданных файла выполняют, только когда модификатор режима совместного использования содержит режим совместного использования с записью.
30. Способ по п. 26, в котором основывающаяся на REST операция представляет собой операцию удаления, причем операцию удаления выполняют, только когда модификатор режима совместного использования содержит режим совместного использования с удалением.
31. Способ по п. 26, в котором основывающаяся на REST операция представляет собой операцию составления списка файлов, операцию получения свойств файла или операцию получения метаданных файла, причем операцию составления списка файлов, операцию получения свойств файла или операцию получения метаданных файла выполняют в то время, пока файл открыт с использованием эксклюзивного доступа с чтением согласно основывающейся на SFA операции, имеющей модификатор режима совместного использования.
32. Способ по п. 26, дополнительно содержащий этап, на котором сообщают о нарушении условий совместного использования, когда модификатор режима совместного использования предотвращает доступ к файлу согласно принятой основывающейся на REST операции.
33. Компьютерно-реализуемый способ осуществления доступа к файлам в распределенной файловой системе, содержащий этапы, на которых:
принимают операцию для файла в интерфейсе протокола совместного файлового доступа (SFA) - протокола передачи состояния представления (REST) (интерфейсе SFA-REST);
осуществляют доступ к файловой службе для выполнения операции, соответствующей упомянутому файлу, причем файловая служба содержит множество таблиц, каковое множество таблиц хранит состояния файлов в распределенной файловой системе, причем интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST для осуществления доступа к файлам в распределенной файловой системе;
обрабатывают упомянутую операцию на основе интерфейса SFA-REST; и
выполняют эту операцию на основе, по меньшей мере, отчасти идентификации состояния файла для упомянутого файла, которое сохранено согласно схеме файловой службы упомянутой файловой службы.
34. Способ по п. 33, в котором упомянутое множество таблиц содержит поля, заданные в схеме файловой службы, соответствующей интерфейсу SFA-REST, причем данное множество таблиц связано на основе операций, заданных в интерфейсе SFA-REST для координирования операций взаимодействия между клиентами SFA и клиентами REST.
35. Способ по п. 33, в котором схема файловой службы поддерживает замену сохранения состояний файлов в памяти сохранением состояний файлов непосредственно в хранилище облачной вычислительной платформы, чтобы множество клиентов SFA и клиентов REST мгновенно осуществляли доступ к состояниям файлов, используя схему файловой службы.
36. Способ по п. 33, в котором схема файловой службы включает в себя иерархическую таблицу для хранения файлов и каталогов на основе соответствующих имен файлов и каталогов, при этом файлы и каталоги извлекаются с использованием поисков по таблице пространства имен, хранящей множество идентификаторов файлов.
37. Компьютерно-реализуемый способ осуществления доступа к файлам в распределенной файловой системе, содержащий этапы, на которых:
принимают операцию для общего файлового ресурса в интерфейсе протокола совместного файлового доступа (SFA) - протокола передачи состояния представления (REST) (интерфейсе SFA-REST), причем интерфейс SFA-REST содержит интегрированные функциональные средства протокола SFA и протокола REST для осуществления доступа к файлам в распределенной файловой системе;
осуществляют доступ к таблице общих ресурсов для выполнения упомянутой операции, соответствующей общему файловому ресурсу, причем в таблице общих ресурсов представлены общие файловые ресурсы и моментальные снимки общих файловых ресурсов с использованием семантики интерфейса SFA-REST, при этом таблица общих ресурсов содержит запись для общего файлового ресурса и запись для моментального снимка;
обрабатывают упомянутую операцию на основе интерфейса SFA-REST; и
выполняют эту операцию на основе, по меньшей мере, отчасти идентификации состояния общего файлового ресурса файла или состояния моментального снимка для общего файлового ресурса, сохраненного на основе таблицы общих ресурсов.
38. Способ по п. 37, дополнительно содержащий этап, на котором выполняют моментальный снимок общего файлового ресурса для резервного копирования содержимого общего файлового ресурса, при этом общий файловый ресурс содержит изменения в отношении общего файлового ресурса, записанные в общий файловый ресурс с использованием механизма копирования при записи, так чтобы доступ к предыдущей версии при каждом моментальном снимке мог осуществляться независимо.
39. Способ по п. 38, в котором выполнение моментального снимка общего файлового ресурса основывается на одном из:
атомарной операции выполнения моментального снимка, содержащей двухпроходную операцию уведомления и инструкции записи;
неатомарной операции выполнения моментального снимка, содержащей однопроходную операцию инструкции записи; или
атомарной операции выполнения моментального снимка для перекрестного совместного использования, содержащей создание моментальных снимков множественных общих файловых ресурсов.
40. Способ по п. 37, дополнительно содержащий этапы, на которых:
обновляют таблицу общих ресурсов, содержащую общий файловый ресурс, при этом обновление таблицы общих ресурсов содержит добавление строки в таблицу общих ресурсов, причем данная строка соответствует новой версии общего файлового ресурса;
передают в узел, связанный с общим файловым ресурсом, уведомление, инструктирующее данному узлу начать запись в новую версию общего файлового ресурса;
определяют, что данный узел осуществляет запись в новую версию общего файлового ресурса; и
обновляют таблицу общих ресурсов для указания того, что моментальный снимок выполнен успешно.
| US 6385701 B1, 07.05.2002 | |||
| Многоступенчатая активно-реактивная турбина | 1924 |
|
SU2013A1 |
| Многоступенчатая активно-реактивная турбина | 1924 |
|
SU2013A1 |
| US 8301608 B1, 30.10.2012 | |||
| РАСПРЕДЕЛЕННАЯ ФАЙЛОВАЯ СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ СОГЛАСОВАННОСТЬЮ БЛОКОВ ДАННЫХ В ТАКОЙ СИСТЕМЕ | 2009 |
|
RU2449358C1 |
