Протокол CIFS обладает различными возможностями по оптимизации взаимодействия между клиентом и сервером. Эти возможности рассматриваются в разделах 3.3.5.1 и 3.3.5.2.

3.3.5.1 Функция CIFS AndX

Протокол CIFS позволяет формировать последовательность взаимно зависящих друг от друга запросов, поэтому оптимизация этих операций позволяет завершить выполнение запроса за одно обращение к серверу. Эта функция называется AndX; Файловая система NFS версии 4 обеспечивает подобную функцию в виде процедуры COMPOUND. Примером может быть отправка запросов OpenAndRead или WriteAndClose серверу CIFS. При этом вместо отправки отдельных двух запросов, например Open, а затем Read, и получения двух ответов отправляется один запрос OpenAndRead и получается один ответ. Это имеет особое значение в том случае, когда время обращения запрос/ответ слишком велико.

3.3.5.2 Оппортунистическая блокировка •

Протокол CIFS поддерживает такую технологию оптимизации производительности, как оппортунистическая блокировка (opportunistic locking, или oplock). Существует две основные причины для использования оппортунистической блокировки. '

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

Представьте себе приложение, которое открывает файл на сетевом сервере для чтения и записи и записывает в файл 128-байтовые записи. Без оппортунистической блокировки каждая запись размером 128 байт потребует передачи данных по сети. Использование oplock позволяет локально кэшировать файл на клиентской системе и объединять несколько операций записи в одну, которая приводит к передаче данных по сети. Например, предположим, что клиент использует буферы размером 4096 и последовательно записывает в файл по 128 байт. Первый буфер будет содержать данные 32 операций записи (4096/128 = 32), и все данные 32 записей будут переданы по сети одним запросом на запись в файл. Если операция записи не может быть кэширована, по сети будет передаваться 32 операции записи (а не одна, как при кэшировании). Сокращение количества операций записи с 32 до одной приводит к значительному снижению нагрузки на сеть и существенному повышению производительности.

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

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

Оппортунистические блокировки реализуются в трех вариантах:

Последовательность операций при эксклюзивной оппортунистической блокировке

Рис. 3.3. Последовательность операций при эксклюзивной оппортунистической блокировке

■ эксклюзивная оппортунистическая блокировка;

■ пакетная оппортунистическая блокировка;

■ оппортунистическая блокировка второго уровня.

Далее эти сценарии описываются более подробно.

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

Для начала первый клиент отправляет запрос на открытие файла, запрашивая эксклюзивную оппортунистическую блокировку. Сервер выполняет необходимую проверку и предоставляет ее. Первый клиент начинает кэширование файла, выполняя операции упреждающего чтения и отложенной записи. Через некоторое время другой клиент, например клиент 2 (на рис. 3.3 не показан), отправляет серверу запрос на открытие того же файла. Сервер отмечает, что клиент 1 владеет эксклюзивной оппортунистической блокировкой для запрошенного файла, и отправляет уведомление о снятии блокировки клиенту 1. Клиент 1 очищает буферы данных, отправляя необходимые запросы на запись и на блокировку файла. Как только данные состояния файла будут записаны, клиент 1 сообщает серверу, что обработка уведомления о снятии оппортунистической блокировки завершена. На этом этапе сервер отправляет ответ клиенту 2, позволяя ему открыть файл. Клиент 1 продолжает работу с файлом, не проводя при этом локального кэширования. В данном случае предполагается, что клиент 1 открыл файл в режиме, допускающем открытие файла другими клиентами.

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

Обратимся к рис. 3.4. Клиент 1 начинает работу с запроса эксклюзивной оппортунистической блокировки и приступает к локальному кэшированию файла. В частности, клиент 1 проводит упреждающее чтение и локально кэширует блокируемые данные. Помните, что в данном случае клиент не собирается записывать данные в файл. На определенном этапе клиент 2 (он не показан на рис. 3.4) запрашивает доступ к этому же файлу. Сервер отправляет клиенту 1 уведомление с требованием понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня. Клиент аннулирует блокировки и сообщает, что обработка уведомления завершена. Далее серь вер отправляет клиенту 2 сообщение об успешном открытии файла и предоставляет клиенту оппортунистическую блокировку второго уровня. В данном случае предполагается, что клиент 1, открывая файл, сообщил серверу, что другие клиенты также могут получить доступ к файлу.

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

Оппортунистическая блокировка второго уровня ляет сократить объем информации, передаваемой по сети

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

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

Пакетная оппортунистическая блокировка На рис

Рис. 3.5. Пакетная оппортунистическая блокировка На рис. 3.5 приведена последовательность операций. Клиент 1 открывает командный файл и запрашивает пакетную оппортунистическую блокировку. Предположим, что сервер предоставляет пакетную блокировку, так как больше никто не выполняет запись данных в файл. Клиент 1 ищет в файле определенную строку и осуществляет операцию чтения. Интерпретатор выполняет прочитанную строку. Затем файл закрывается. Мини-перенаправитель CIFS не выполняет никаких действий при получении запроса на закрытие файла (т.е. выполняется операция отложенного закрытия). Интерпретатор командной строки открывает файл, но мини-перенаправитель CIFS не выполняет операцию открытия, а просто отменяет размещенную в очереди операцию отложенного закрытия файла. Когда интерпретатор командной строки выполняет операции поиска и чтения строки, мини-перенаправитель CIFS отправляет запросы на поиск и чтение.

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

3.4 Сетевая файловая система Файловая система CIFS доминирует на рынке сетевых файловых систем для платформы Windows. На платформе UNIX основной является сетевая файловая система (Network File System - NFS). Кроме того, NFS считается первой широко распространенной файловой системой, что произошло еще в середине 1980-х годов. Однако, несмотря на некоторые общие функциональные возможности CIFS и NFS (это сетевые файловые системы, позволяющие клиентам получать доступ к ресурсам серверов), эти системы имеют совершенно различные архитектурные особенности. С выходом NFS версии 4 некоторые различия были пересмотрены.

Протокол CIFS сохраняет сервисные данные, относящиеся к каждому клиенту. До версии 3 файловая система NFS не сохраняла статус клиента, что изменилось в версии 4.

Клиент NFS не “договаривается” с сервером NFS об установлении сеанса. Меры безопасности предпринимаются для всего сеанса или каждой операции обмена данными между клиентом и сервером. Реализация последнего варианта чрезмерно дорогостоящая, поэтому NFS возлагает задачу обеспечения безопасности на клиента. Сервер “предполагает”, что идентификаторы пользователя на клиентских и серверной системах совпадают (а клиент проверил личность пользователя перед тем, как дать ему зарегистрироваться под указанным идентификатором). Кроме того, NFS обеспечивает определенный уровень безопасности, контролируя список файловых систем, которые может монтировать клиент. Каждый раз, когда клиент CIFS открывает файл, получает дескриптор файла (т.е. сервисные данные, которые должен сохранять сервер) и использует его для проведения операций чтения или записи на стороне клиента, сервер NFS запрашивает ^сервер, который возвращает дескриптор файла. Этот дескриптор файла обрабатывается клиентами, поддерживающими стандарты NFS 3 и NFS 2. Клиент кэширует полученный дескриптор файла и ожидает, что дескриптор всегда будет указывать на один и тот же файл.

Для тех, кто знаком с UNIX, можно отметить, что дескриптор файла обычно состоит из номера inode (inode number), счетчика поколения inode (inode generation count) и идентификатора файла, который связан с разделом диска. Достаточно сказать, что inode представляет собой исключительно важную структуру данных, которая используется в файловых системах UNIX. Для удаления дескрипторов, кэшированных клиентами, хранится достаточный объем информации, необходимой, если соответствующий дескриптору файл изменился и дескриптор должен указывать на другой файл. Например, если файл удален и на его место скопирован файл с таким же именем, счетчик поколения inode будет изменен и кэшированный клиентом де скриптор файла окажется недействительным. Файловая система NFS 4 имеет отличия в реализации, которые рассматриваются в разделе 3.4.2.

Некоторые клиенты NFS проводят кэширование на стороне клиента, храня данные на дисках, что напоминает кэширование в CIFS. Также некоторые клиенты NFS меняют значение тайм-аутов в зависимости от времени отклика сервера. Чем медленнее отзывается сервер, тем больше значение тайм-аута, и наоборот.

Файловая система NFS проектировалась, как независящая от транспорта и изначально использовала транспортный протокол UDP. Различные типы NFS могут использовать протокол TCP и другие протоколы.

В разделах 3.4.1 и 3.4.2 рассматриваются особенности файловых систем NFS 3 и NFS 4. Информация, приведенная в этой книге, не заменит ряд отличных изданий, которые представлены в списке источников информации в конце книги.

3.3.4 аутентификация cifs | Системы хранения данных в Windows | 3.4.1 сетевая файловая система, версия 3


Системы хранения данных в Windows



Новости за месяц

  • Апрель
    2020
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31