3.1 Появление NAS

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

Устройства хранения данных оставались достаточно дорогими, а потребность в объемах хранимых данных постоянно возрастала. Возможность установки большего количества устройств ограничивалась количеством жестких дисков, подключаемых к одному серверу (обычно поддерживалось семь или восемь адресов, причем адаптеру шины также требовался один из адресов; развитие стандарта SCSI привело к отмене этого ограничения). В результате приходилось устанавливать множество однотипных серверов. Наконец, операции ввода-вывода были ограничены пропускной способностью шины ввода- вывода. Только установка большего количества серверов позволяло снизить нагрузку на шину каждого сервера.

Производители воспользовались сложившейся ситуацией и приступили к развитию концепции сетевых хранилищ данных. Как отмечает Том Кларк (Tom Clark) в книге Designing Storage Area Networks, NAS представляет собой скорее маркетинговый, чем технический термин. Устройства NAS разрабатывались как простые в использовании, управлении и развертывании. Кроме того, устройства NAS представлялись в качестве специализированных устройств хранения данных, обеспечивающих оптимальную пропускную способность операций ввода-вывода. Хотя в некоторых случаях это соответствовало истине, т.е. операционные системы NAS были максимально упрощены, чаще всего NAS оказывались обычными, минимально «замаскированными» серверами общего назначения. ДаЖсе терминустройство NAS Указывает на специализированное устройство, а не на обычный сервер, к которому подключено множество устройств хранения данных.

Устройство NAS включает в себя серверное программное обеспечение, которое работает под управлением определенной операционной системы. Более того, стек программного обеспечения NAS основан на стандартной серверной файловой системе с добавлением стека ввода-вывода, основанного на коде сетевого сервера, стеках сетевого протокола и сетевой файловой системы (рис. 3.1). Последняя предоставляет такие возможности распределенной файловой системы, как кэширование и синхронизация. Три дополнительных элемента на рис. 3.1 обозначены серым цветом.

В целом сетевые особенности устройства NAS показаны на рис. 3.1 слева, а стек локальной файловой системь! и подсистемы хранения – справа. Чтобы упростить изложение, рассмотрим только стек протоколов TCP/IP, хотя иногда применяются другие сетевые протоколы, такие, как UDP/IP или устаревший Netware IPX/SPX.

На рис. 3.1 программное обеспечение сервера NAS отправляет запрос ожидания TCP/IP и ожидает входящего запроса от клиента. После того как клиент отправит запрос, ожидание сервера завершается и начинается сеанс TCP/IP. Как только сеанс TCP/IP будет установлен, клиент может пройти аутентификацию и отправить запрос на открытие, чтение или запись файлов по протоколам CIFS/SMB или NES (эти протоколы рассматриваются далее в главе). Как только программное обеспечение NAS получает запрос на ввод- вывод данных файла, сервер NAS использует локальную файловую систему для выполнения операции ввода-вывода. Результат операции (считанные данные или статус после записи) отправляется клиенту с помощью сетевой файловой системы и стека протоколов сетевого устройства.

Рис. 3.1. Стек ввода-вывода устройства NAS

Производители устройств NAS придерживаются разных стратегий при разработке операционных и файловых систем, применяемых в устройствах NAS:

использование стандартной операционной системы, например Windows NT или UNIX;

разработка собственных операционной и файловой систем, например Network Appliance;

приобретение операционной и файловой систем у другого производителя.

 

3.2 Сетевой стек Windows NT

Разобраться в особенностях стека сетевого ввода-вывода Windows NT важно по нескольким причинам. Клиент Windows NT использует стек сетевого ввода-вывода для получения доступа к ресурсам, которые находятся под управлением сервера, а также для передачи данных. Кроме того, при использовании сетевого хранилища часто возникает ситуация, когда один сервер получает доступ к ресурсам, которыми управляет другой сервер. Хорошим примером будет Wob-сервер под управлением Windows NT, который для ответа на запрос клиента запрашивает базу данных, размещенную на отдельном сервере SQL под управлением Windows NT. Web-сервер получает доступ к серверу SQL средствами стека сетевого ввода-вывода Windows NT.

Рис. 3.2. Сетевой стек Windows NT

На рис. 3.2 показан стек сетевого ввода-вывода Windows NT. В разделах 3.2.1–3.2.6 рассматриваются различные компоненты, представленные на рис. 3.2 снизу вверх (а также стек ввода-вывода).

Сетевой платой обычно управляет драйвер, совместимый со спецификацией NDIS (Network Driver Interface Specification). Она представляет собой интерфейс, обеспечивающий взаимодействие драйверов сетевой платы со стеком сетевых протоколов более высокого уровня. Следующий уровень – это стек TCP/IP. Термин TCP/IP используется для описания всех компонентов, которые задействованы в передаче данных по сети, например IP, DHCP или TCP. К следующему уровню относится интерфейс транспортного драйвера.

3.2.1 Интерфейс транспортного драйвера

Уровнем выше над стеком сетевых протоколов TCP/IP находится интерфейс транспортного драйвера (Transport Driver Interface – TDI). Этот высокопроизводительный интерфейс режима ядра предназначен для сетевых приложений, которым требуется запрос и получение услуг сетевых транспортных

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

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

3.2.2 Подсистема буферизаций перенаправленных дисков

На следующем уровне находится подсистема буферизации перенаправленных дисков (Redirected Drive Buffering Subsystem – RDBSS), которая отвечает за предоставление кода буферизации всем перенаправителям (redirectors). Подсистема обеспечивает полноценное взаимодействие с диспетчером кэша Windows NT для всех сетевых файловых систем. Подсистема RDBSS впервые появилась в Windows 2000; до этого момента всем сетевым файловым системам требовался полноценный драйвер, который обеспечивал взаимодействие с операционной системой.

3.2.3 Мини-перенаправители

Эти устройства обеспечивают работу функций, относящихся к конкретной сетевой файловой системе или протоколу и пользуются услугами RDBSS для обработки рутинных операций взаимодействия с Windows NT. В Windows 2000 и Windows ХР предоставляется несколько мини-перенаправителей.

Мини-перенаправителем CIFS оснащены Windows 2000, Windows ХР и Windows Server 2003. В более ранних версий Windows NT был реа- лизван монолитный перенаправитель. Код RDBSS, общий для всех мини-перенаправителей, реализовался независимо каждым поставщиком. Технология CIFS более подробно рассматривается в разделе 3.3.

Мини-перенаправитель WebDAV (Web Distributed Authoring and Ver- sioning) поддерживает протокол HTTP 1.1 и расширения WebDAV для чтения и записи документов Web. Он предоставляет возможности, позволяющие назначать буквы дисков серверу независимо от протокола доступа к последнему. Назначение поддерживается как для серверов HTTP, так и для серверов CIFS. Корпоративные брандмауэры обычно разрешают прохождение пакетов HTTP и зачастую блокируют запросы/ответы протокола CIFS. Таким образом, мини-перенаправитель WebDAV обеспечивает доступ к серверам HTTP через брандмауэры, блокирующие пакеты CIFS. Поскольку стандарты XML и HTTP играют все большую роль, важность мини-перенаправителя WebDAV со временем будет увеличиваться. Обратите внимание, что WebDAV представляет собой исключительно клиент-серверный протокол, не поддерживающий взаимодействие между серверами.

Система Windows NT Services for UNIX (SFU) поставляется с мини- перенаправителем, поддерживающим протокол NFS. Файловая система NFS рассматривается в разделе 3.4.

3.2.4 Поставщик множественных имен UNC

В Windows поддерживается универсальное соглашение об именовании (Universal Naming Convention – UNC), необходимое для получения доступа к удаленным файлам. Поддержка UNC своими корнями уходит во времена MS DOS 3.3, которая существовала задолго до создания Windows NT. Имена UNC позволяют приложениям указывать файлы согласно их расположению на сервере и общем ресурсе (помните, что на одном сервере может существовать несколько общих ресурсов). Формат имен UNC выглядит следующим образом:

\\ИмяСервера\Ресурс\Подкаталог1\...\ПодкаталогN\ИмяФайла

Поддержка UNC в разных версиях Windows различается следующими параметрами:

максимальная длина пути UNC;

максимальная длина каждого элемента пути UNC, например длина имени подкаталога;

максимальная длина имени сервера.

Для предоставления приложениям и утилитам возможности использования сетевых ресурсов с помощью путей UNC компания Microsoft создала поставщика множественных имен UNC (Multiple UNC Provider).

Поскольку Windows NT поддерживает несколько сетевых файловых систем, MUP работает как маршрутизатор, перенаправляя запросы нужной сетевой файловой системе, или же как мини-перенаправитель, который поддерживает конкретную сетевую файловую систему. Маршрутизация выполняется одним из двух способов.

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

2. По порядку опрашивается каждый мини-перенаправитель для подключений UNC, которые отсутствуют в кэше.

3.2.5 Маршрутизатор множественных поставщиков

Маршрутизатор множественных поставщиков (Multi-Provider Router – MPR) предоставляет функции, аналогичные MUP, перенаправляя запросы приложений соответствующему мини-перенаправителю, однако существует два отличия.

Код MPR работает в пользовательском режиме, а не в режиме ядра.

Маршрутизатор MPR предназначен для приложений, не использующих пути UNC, например для приложений, применяющих WinlNet API (термин WinlNet расшифровывается, как Windows Internet). Это программный интерфейс приложений, который предоставляет дополнительный уровень абстракции для программ, использующих стандартные протоколы Internet – HTTP, FTP и Gopher.

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

3.2.6 Клиентское кэширование

Мини-перенаправитель CIFS в Windows 2000 поддерживает функцию клиентского кэширования, которая позволяет кэшировать файлы локально на компьютере клиента. Кэшироваться могут как файлы документов (например, файлы Microsoft Word или Excel), так и выполняемые файлы (например, файлы приложений из пакета Microsoft Office). Кэширование инициируется одним из двух способов.

Пользователь явно запрашивает кэширование.

Мини-перенаправитель инициирует кэширование при открытии файла.

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

Кэширование возможно не для всех файлов – только для тех файлов общего ресурса, которые явно отмечены (администратором сервера) как разрешенные для кэширования. Эта информация передается мини-перенаправи- телю CIFS в ответном пакете SMB (Server Message Block). При этом протокол SMB модифицирован для доставки клиенту информации о возможности кэширования файлов, а также о типе кэширования, выполняемого клиентом. Допускается три типа кэширования.

Общие ресурсы, в которых разрешено кэширование только документов.

Общие ресурсы, в которых разрешено кэширование только программ.

Общие ресурсы, в которых кэширование запрещено.

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

Технология клиентского кэширования в Windows 2000 проектировалась для предоставления соответствующих функций приложениям Windows, для которых кэширование происходит совершенно незаметно. Хотя кэширование должно быть незаметным и для пользователей, им все же придется вмешиваться в процесс синхронизации данных и обработки ошибок при клиентском кэшировании. Другими словами, если несколько клиентов вносят конфликтующие между собой изменения в один документ в собственных кэшах, пользователю выдается сообщение о программном конфликте, причем решить проблему пользователь должен самостоятельно.

Можно выделить ряд компонентов, которые совместно предоставляют клиентам необходимые функции.

Мини-перенаправитель CIFS.

Программный интерфейс приложений, который предоставляется мини- перенаправителем CIFS и связанными с ним компонентами пользовательского режима. Этот интерфейс позволяет приложениям использовать предоставляемые возможности и управлять ими.

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

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

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

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

Изменения файла, внесенные в автономном режиме, сохраняются и синхронизируются. В случае конфликта в процессе синхронизации пользователь получает уведомление и запрос на решение конфликта.

 

3.3 Технологии CIFS и SMB

Общий протокол доступа к файлам Internet (Common Internet File System – CIFS) своим происхождением обязан технологии блока серверных сообщений (Server Message Block – SMB), которая впервые появилась в MS DOS 3.3. В стандарте SMB описан протокол отправки команд файловой системы (открыть файл, считать, записать, блокировать и закрыть) от клиента к файловому серверу.

Перед обсуждением технических подробностей технологий CIFS и SMB необходимо выяснить основные различия между ними. Изначально существовала только технология SMB, которая использовалась в качестве клиент-сер- верного файлового протокола в мире персональных компьютеров. В середине 1980-х годов компания Microsoft дала своей реализации протокола SMB название CIFS и начала позиционировать CIFS в качестве прямого конкурента стандартов WebNFS и NFS. Компания Microsoft предоставила ознакомительный документ RFC на рассмотрение группе IETF (Internet Engineering Task Force), и впоследствии срок действия документа истек без попыток превратить RFC в одну из спецификаций IETF.

Независимые от компании Microsoft поставщики устройств NAS приступили к разработке спецификации CIFS и организовали несколько мероприятий для популяризации CIFS. Ассоциация SNIA (Storage Networking Industry Association) взяла на себя задачу публикации CIFS. Компания Microsoft также выпустила спецификацию CIFS (она называлась Common Internet Filesys- tem Access Protocol), распространявшуюся бесплатно (ссылка на спецификацию находится в списке основных источников информации, приведенном в конце книги).

В похожих друг на друга спецификациях SNIA CIFS и CIFS от компании Microsoft описывается протокол, используемый клиентами Windows NT 4.0 для получения доступа к ресурсам серверов Windows NT. В обеих спецификациях не рассматривается протокол SMB, который применяется в новых версиях Windows (например, не затрагивается клиентское кэширование, которое поддерживается в Windows 2000 и описано в разделе 3.2.6). Кроме того, в спецификациях не описаны все протоколы взаимодействия между серверами. Новый стандарт SMB, не относящийся к бесплатным спецификациям, описан в соответствующей спецификации, которая за определенную плату распространяется компанией Microsoft, что стало возможным благодаря судебным решениям Европейского Союза и правительства США. Дополнительная информация доступна в статье «Microsoft Settlement Program: Communications Protocol Program» на Web-узле компании Microsoft по адресу: .

Таким образом, компания Microsoft вновь стала называть свою реализацию описываемой технологии блоком SMB. По сути, SMB от Microsoft – это закрытый протокол, представляющий собой расширенную версию индустриального стандарта CIFS.

Кроме того, следует обратить внимание на историческую связь между SMB/CIFS и NetBIOS. Программный интерфейс NetBIOS (уровень сеанса в модели OSI) на данный момент безнадежно устарел. Интерфейс реализует уровень абстракции, который позволяет приложениям работать с различными транспортными протоколами, например TCP/IP, NetWare или уже забытым протоколом XNS (Xerox Network System). Необходимость в программном интерфейсе приложений, который предоставляет возможность создания приложений, не зависящих от сетевого протокола, существует и поныне. Однако в настоящий момент для этого обычно используется интерфейс сокетов, в частности в мире Windows – интерфейс Winsock.

Компания Microsoft использовала NetBIOS для преобразования имен (преобразования имени сервера в сетевой адрес), но сейчас для этого предназначена стандартная служба DNS.

Изначально Microsoft не использовала TCP/IP в качестве транспортного протокола, что кардинально изменилось со временем, однако поддержка NetBIOS продолжала присутствовать. Тем не менее роль NetBIOS постоянно уменьшалась. После назначения порта TCP/IP для файловых серверов SMB зависимость от NetBIOS была полностью «излечена», по крайней мере в контексте базового протокола. Но ситуация оставалась запутанной, так как некоторым вторичным службам клиентов и серверов Windows все равно требовался протокол NetBIOS. Хорошим примером будет объявление серверами о своем присутствии в сети и предоставление списка доступных служб, а также передача этих объявлений клиентам другими серверами. Со временем службы были переделаны и NetBIOS был полностью снят со счетов с выходом Windows 2000.

Наконец, наследие SMB можно заметить в каждом запросе CIFS, поскольку каждый запрос и ответ должны начинаться со значение «OxFF», после чего следуют такие символы ASCII, как «SMB».

3.3.1 Разновидности стандарта CIFS

К сожалению, точного определения стандарта CIFS не существует. Различные типы протоколов SMB называются диалектами. Вот несколько возможных вариантов:

применяемый клиентами DOS и Windows 3. x;

используемый при подключении к серверам, не работающим под управлением Windows;

■ применяемый клиентами под управлением Windows NT.

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

Как описано в документе RFC компании Microsoft (по правилам IETF на данный момент он уже устарел), протокол CIFS обеспечивает взаимодействие клиента и сервера для доступа к файлам и управления ими. Такие функции, как объявление о наличии в сети доступных принтеров и серверов, выходят за рамки возможностей протокола CIFS.

Организация SNIA продолжает работу над спецификацией CIFS. Кроме того, SNIA проводит ежегодную конференцию, посвященную CIFS, и организует другие мероприятия, на которых обсуждаются вопросы взаимодействия систем по протоколу CIFS.

Спецификация SMB стала стандартом с 1992 года (X/Open CAE Specification С209) и описывает SMB как протокол для обеспечения взаимодействия между компьютерами под управлением DOS, Windows, OS/2 и UNIX.

3.3.2 Описание протокола CIFS

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

В табл. 3.1 приведена общая структура пакета SMB. Обратите внимание, что показаны только общие элементы для всех вариантов SMB. Подробности строения каждого варианта пакета SMB выходят за пределы тематики этой книги.

Некоторые поля в табл. 3.1 требуют более полного описания. Поле команды имеет размер в один байт и описывает тип запроса. Сервер копирует это значение в ответ, что позволяет клиенту анализировать последний. Спецификация CIFS содержит значения и определения для этого поля. Описанные команды позволяют выполнять такие операции, как открытие файла, чтение, запись и блокирование определенного диапазона файла. Все эти операции выполняются в качестве ответа на запрос приложения.

Кроме того, запросы клиента CIFS (и связанные с ними ответы сервера) инициируются кодом перенаправителя без явного вмешательства приложения. Примерами будут кэширование и оппортунистическая блокировка (opportunistic locking), которые рассматриваются в разделе 3.3.5. В спецификациях CIFS RFC и SNIA, а также Open Group определены значения и семантика кода команды CIFS размером в 1 байт.

Таблица 3.1. Структура заголовка SMB

Окончание табл. 3.1

Помните, что новые значения и семантика полей могут появиться без предупреждения с выходом новых версий Windows, так как протокол CIFS продолжает развиваться.

Существует несколько команд для выполнения одинаковых базовых операций; например, для открытия, чтения и записи существует несколько раз-

личных команд. Некоторые команды уже не применяются, а в ряде случаев могут использоваться альтернативные команды, в зависимости от выбранного диалекта протокола.

Далее представлены примеры функций, описанных в поле команды.

Выбор типа SMB.

Установка сеанса связи.

Переход по каталогам и перечисление файлов и каталогов.

Открытие, создание, закрытие или удаление файлов.

Блокировка и разблокировка определенных фрагментов файла.

Операции печати.

Уведомления об изменении файлов и каталогов.

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

В табл. 3.2 представлены функции поля Flags (флаги) из 3.1.

Таблица 3.2. Семантика поля Flags

В поле Flag2 из табл. 3.1 описано еще больше необязательных функций. Значения этого поля приведены в табл. 3.3.

Поле Заполнение/подпись изначально представляло собой последовательность «холостых» байт. Со временем значение этого поля изменилось. Поле заполнения теперь может включать в себя следующие элементы:

Таблица 3.3. Семантика поля Flags2

2 байта идентификатора процесса, что позволяет указывать 32-разрядные идентификаторы процесса;

8 байт для хранения подписи пакета SMB, если эта функция активизирована (см. описание поля Flags2 в табл. 3.3 и в разделе 3.3.3);

2 неиспользуемых байта.

3.3.3 Безопасность CIFS

Протокол CIFS обеспечивает безопасность средствами сервера. Администратор может отключить систему встроенной безопасности CIFS, в чем ед-

ва ли появится необходимость, поэтому система безопасности включена по умолчанию.

В старых вариантах CIFS допускается отправка незашифрованного текстового пароля от клиента к серверу, что категорически не рекомендуется. Протокол CIFS допускает защиту ресурсов сервера с помощью паролей отдельных пользователей (это называется безопасностью на уровне пользователя). Для обеспечения обратной совместимости серверы CIFS поддерживают защиту общего ресурса на базе пароля, одинакового для всех пользователей. Поскольку ресурс будет предоставлен в общее пользование,– этот метод называется безопасностью на уровне ресурса. Использовать механизм безопасности на уровне ресурса не рекомендуется, и в Windows 2000 Server эта система отсутствует. Первый пакет SMB, который отправляется серверу клиентом, называется SMB_NEG0TIATE_PR0T0C0L. Пакет применяется для выбора типа CIFS. В ответ на запрос SMB_NEG0TIATE_PR0T0C0L сервер сообщает об используемом механизме безопасности (уровень пользователя или ресурса).

Начиная с Windows NT4 SP3 и Windows 2000, компания Microsoft предоставила возможность размещения в пакетах SMB цифровой подписи. Сервер может быть настроен на обязательное требование цифровой подписи от клиента; в противном случае клиенту будет запрещен доступ к ресурсам. Использование цифровой подписи отражается на производительности как сервера, так и клиента, но это цена, которую приходится платить за безопасность. Обратите внимание, что подписывание и проверка имеют двунаправленную природу, т.е. клиент подписывает отправляемые запросы, сервер проверяет подпись клиента и подписывает отправляемые ответы, после чего клиент проверяет подпись сервера. Подпись пакета SMB хранится в поле Заполнение/подпись (см. табл. 3.1).

Ответ на запрос SMB_NEG0TIATE_PR0T0C0L используется для предоставления клиенту информации о поддержке сервером подписывания пакетов SMB и о необходимости обязательного подписывания пакетов SMB.

3.3.4 Аутентификация CIFS

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

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

Аутентификация может выполняться с помощью технологии, которая называется протокол запрос/ответ (challenge/response protocol). При отправке клиентом пакета SMB_NEGOTIATE_PROTOCOL для выбора типа CIFS флаг в ответе сервера указывает на возможность использования протокола запрос/ответ. Если сервер поддерживает этот протокол, в ответе сервера предоставляется 8-байтовый запрос. Запрос – это случайное значение с очень низкой вероятностью повторной генерации. И клиент и сервер формируют ключ из пароля пользователя. После этого запрос шифруется с помощью ключа и алгоритма DES (Data Encryption Standart). Клиент отправляет запрос серверу, а сервер сравнивает ответ с собственным подсчитанным значением. Если два значения совпадают, клиент доказывает знание пароля и подтверждает свою аутентичность.

Кроме того, протокол CIFS поддерживает систему расширенной безопасности (можете и не надеяться, что читатель, который догадается об указании на поддержку расширенной безопасности в ответе сервера на запрос SMB_NEG0TIATE_PR0T0C0L, получит награду). Механизм расширенной безопасности предоставляет возможность поддержки произвольного протокола аутентификации в рамках протокола CIFS. При выборе расширенной безопасности первый двоичный объект безопасности предоставляется в ответе на запрос SMB_NEG0TIATE_PR0T0C0L. Двоичные объекты безопасности не обрабатываются протоколом CIFS. В этом он полагается на механизмы клиента и сервера, предназначенные для генерации и обработки двоичных объектов. Последующие двоичные объекты безопасности могут передаваться с данными SMB.

Использование механизма расширенной безопасности позволило Microsoft обеспечить поддержку протокола Kerberos в Windows 2000 и более поздних версиях. Реализация Kerberos в Windows 2000 является примером использования закрытых элементов. Например, некоторые поля мандатов Kerberos применяются для передачи информации о группах, в которые входит клиент. Реализация Kerberos от Microsoft допускает взаимную аутентификацию, когда не только сервер проводит аутентификацию клиента, но и наоборот, клиент аутентифицирует сервер.

Компания Microsoft предлагает еще один способ установки сеанса связи между клиентом и сервером, который называется Netlogon. При этом используются данные о компьютере (а не о пользователе). Протокол Netlogon необходим для установки безопасного сеанса RPC и имеет намного больше возможностей, так как поддерживает маркеры доступа пользователей, которые не поддерживаются при регистрации средствами протокола CIFS. Обычно Netlogon используется для связи между серверами (один сервер выступает в роли клиента другого сервера). В ныне устаревшем документе RFC от Microsoft протокол Netlogon не описан.

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

3.3.5 Возможности по оптимизации CIFS

Протокол 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.4.1 Сетевая файловая система, версия 3

Файловая система NFS 3 позволяет увеличить быстродействие, особенно для больших файлов, разрешая клиенту и серверу динамически выбирать максимальный объем данных, которые передаются в одном логическом элементе пакета при записи или чтении. В файловой системе NFS 2 на размер пакета накладывалось ограничение в 8 Кбайт. Другими словами, клиент мог отправить максимум 8 Кбайт в запросе на запись, а сервер – максимум 8 Кбайт в ответе на запрос чтения. Кроме того, в NFS 3 переопределены смещения в файлах и размеры данных. Теперь это 64-разрядные значения, вместо 32-разрядных в NFS 2.

Далее представлены некоторые особенности NFS 3.

В дескрипторах файлов 6 NFS 3 указан переменный размер; их максимальных размер составляет 64 бит.

Файловая система NFS 3 позволяет клиентам и серверам выбирать максимальный размер имен файлов и каталогов.

В NFS 3 определяется список ошибок, которые сервер может возвращать клиентам. Сервер должен вернуть одну из определенных ошибок или не возвращать ошибку вообще.

В NFS 3 серверу разрешено кэшировать данные, которые клиент отправил вместе с запросом на запись. Сервер может кэшировать данные и отправлять клиенту ответ на запрос еще до того, как данные будут записаны на диск. Также добавлена команда COMMIT, которая позволяет клиенту убедиться, что все отправленные данные были записаны на

диск. Это дает возможность соблюсти баланс между повышением производительности и сохранением целостности данных.

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

3.4.2 Сетевая файловая система, версия 4

В NFS 4 полностью пересмотрены основополагающие принципы и реализовано много функций, характерных для CIFS, что весьма расстроило некоторых апологетов NFS. Если посмотреть на историю сетевых файловых систем, то можно увидеть, что NFS получила широкое распространение. Файловая система SMB разрабатывалась с учетом сильных и слабых сторон NFS и теперь, по крайней мере в среде клиентов, CIFS/SMB распространены больше, a NFS развивается, учитывая все недостатки и преимущества CIFS/SMB. Ниже рассматриваются возможности, которые были добавлены в NFS 4 для повышения быстродействия и безопасности, а также для улучшения взаимодействия с CIFS.

В NFS 4 появился запрос COMPOUND, который позволяет запаковывать несколько запросов в один запрос и несколько ответов в один ответ. Это нововведение предназначено для повышения производительности за счет снижения нагрузки на сеть и сокращения задержек при передаче запросов и ответов по сети. Если это несколько напоминает функцию CIFS AndX SMB (см. раздел 3.3.5.1), то, возможно, дело не в обычном совпадении.

Сетевая файловая система версии 4 заимствовала некоторые возможности у WebNFS, созданной компанией Sun. В частности, в NFS 4 некоторые вторичные протоколы поддерживаются в базовой спецификации, что делает NFS более подходящей для применения вместе с брандмауэрами. В NFS 3 и более ранних версиях использовался специальный протокол для монтирования общего ресурса сервера в дерево локальной файловой системы. Поскольку служба протокола монтирования не имела назначенного порта TCP или UDP, клиент сначала отправлял запрос службе отображения портов (portmapper daemon), предоставляющей номер порта, посредством которого ожидает запросов служба монтирования. Таким образом, кроме NFS, в процессе принимали участие протоколы монтирования и отображения портов. Более того, так как служба монтирования могла использовать произвольный порт, настройка брандмауэра весьма усложнялась. В NFS 4 протоколы монтирования и отображения портов были исключены. Кроме того, блокирование было включено в базовую спецификацию протокола NFS, а протокол NLM (Network Lock Manager), который применялся в более ранних версиях NFS, окончательно устарел.

Файловая система NFS 4 требует использования транспортного протокола, который предоставляет возможность обнаружения «заторов» в сети. Это значит, что клиенты и серверы NFS постепенно будут переходить к протоколу TCP вместо UDP, который обычно используется вместе с NFS 3.

В NFS 2 и NFS 3 допускалось использование набора символов U. S. ASCII или ISO Latin 1. Это приводило к возникновению проблем, когда клиент, использующий один набор символов, создавал файл и к этому файлу получал доступ клиент с другим набором символов. В NFS 4 используется набор символов UTF. -8, который поддерживает компактное сжатие 16- и 32-разрядных символов для их передачи по сети. Кроме того, набор символов UTF-8 содержит достаточный объем информации, чтобы избежать проблем при создании файла посредством одного набора символов и получении доступа к файлу с другим набором.

Файловая система NFS 4 требует от клиента отдельной обработки дескрипторов файлов. В NFS 3 клиент мог кэшировать дескриптор в качестве объекта, в то время как сервер заботился о том, чтобы дескриптор всегда указывал на файл. В NFS 4 определены два типа файловых дескрипторов. Один называется постоянные дескрипторы файлов и обладает возможностями дескрипторов файлов из NFS 3. Второй – временные дескрипторы файлов – предполагает истечение срока действия дескриптора после определенного промежутка времени или события. Это функция для серверов, файловые системы которых (например, NTFS) не могут обеспечить постоянного соответствия между отображаемыми файлами и дескрипторами.

В NFS 4 добавлена поддержка операций OPEN и CLOSE, семантика которых допускает взаимодействие с клиентами CIFS. Команда OPEN создает данные состояния на сервере.

Поддержка запроса OPEN в NFS 4 позволяет клиенту осуществлять запрос на открытие файла, структура которого будет аналогична запросам на открытие приложений Windows. Также поддерживается выбор совместного использования файла с другими клиентами или эксклюзивный доступ к файлу.)

3.4.2.1 Безопасность NFS 4

Файловая система NFS 4 позволяет усилить безопасность хранимых данных. В частности, в NFS 4 добавлена поддержка большего количества атрибутов файла. К одному из этих атрибутов относится список управления доступом (ACL) в стиле Windows NT. Это позволяет улучшить взаимодействие между файловыми системами и укрепить структуру безопасности.

В то время как в NFS 2 и NFS 3 использование возможностей системы безопасности только рекомендовалось, в NFS 4 это стало обязательным. Файловая система NFS 4 требует реализации механизма безопасности с помощью интерфейса RPCSEC_GSS (Generic Security Services) в общем и протоколов Kerberos 5/LIPKEY в частности. Обратите внимание, что RPCSEC_GSS просто выполняет роль интерфейса API и транспортного механизма для меток и данных, связанных с безопасностью. Файловая система NFS 4 позволяет использовать несколько, схем аутентификации и обеспечения безопасности, а также дает возможность выбрать подходящую схему для клиентов и серверов.

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

Клиенты могут аутентифицировать серверы по серверному сертификату, а для проверки сертификата используются службы сертификационного центра. Одним из популярных методов взлома является перехват «чужих» пакетов данных с их последующей отправкой через некоторый временной промежуток. При использовании Kerberos файловая система NFS добавляет в каждый пакет временную метку. Сервер записывает недавно полученные временные метки и сравнивает их с временными метками новых пакетов RPC. Если временные метки пакетов старше, чем полученные сервером ранее, сервер игнорирует полученные пакеты.

 

3.5 Проблемы доступа при использовании нескольких протоколов

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

Далее представлены примеры некоторых возможных технических проблем.

В различных операционных системах используются разные методы для отслеживания разрешений доступа пользователей и групп.

В различных операционных и файловых системах существует разная семантика открытия и блокировки файлов.

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

Данные и их структура различаются в различных файловых системах; например, одни файловые системы отслеживают две временные метки, в то время как другие – три метки (время последнего доступа к файлу, последней модификации и создания файла). Даже если обе файловые системы отслеживают две временные метки, единицы измерения могут отличаться. Еще одним примером служат единицы измерения смещений в файлах. В некоторых файловых системах поддерживаются 32- разрядные смещения, а в некоторых – 16- или 64-разрядные.

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

 

3.6 Windows и NAS

Компания Microsoft предлагает приобрести коммерческий пакет SAK (Server Appliance Kit). Он предназначен для производителей аппаратного обеспечения, которым требуется создать приложения для хранилищ данных, подключаемых к сети. Пакет SAK – это просто версия Windows, имеющая модульную структуру, а также набор средств программной разработки. Модульная структура версии Windows позволяет производителю выбрать (в пределах разумного) компоненты Windows, которые должны быть включены в готовое приложение. Таким образом, предоставляется возможность убрать из Windows все компоненты, которые не требуются для поддержки стека сетевых протоколов, файлового сервера и локального стека подсистемы хранения данных. Программные средства разработки позволяют производителям оборудования создавать собственные инструменты администрирования и распространять их вместе с аппаратными комплексами.

Кроме того, в состав SAK входят компоненты, не поставляемые с обычными серверными версиями Windows. Хорошим примером будет инфраструктура обеспечения надежности, которая следит за драйверами на предмет утечки памяти и незаметно перезапускает критические компоненты, если в этом возникает необходимость. Несколько поставщиков предлагают устройства NAS, работающие под управлением Windows NT. Одно из преимуществ использования Windows NT для организации NAS заключается в сокращении стоимости и временных затрат на создание готового решения. Компания Microsoft предоставляет стеки протоколов CIFS и NFS. Возможно, одно из главных преимуществ использования Windows в подобных системах – это доступность всех новейших функций SMB и отсутствие необходимости в обратном проектировании и дополнительной разработке.

Следующим преимуществом является возможность модификации программных решений посредством SAK. В состав SAK входят компоненты управления (в частности, удаленного управления) и компоненты защиты данных (например, функции для создания «моментальных снимков» образа диска). (Описание технологии моментальных снимков и сферы их применения приводится в главе 5.)

Некоторые производители аппаратного обеспечения разработали свои решения NAS, не используя пакет SAK. Доступно несколько альтернативных стеков протоколов CIFS и NFS. Феномен открытого исходного кода набирает популярность, и, если есть возможность потратить дополнительные ресурсы, использование исходного кода, допускающего внесение изменений, имеет ряд преимуществ. Например, доступность открытого исходного кода позволяет максимально сократить накладные расходы на уровне операционной систе

мы. Маркетинговое исследование этих подходов не является предметом нашего обсуждения.

 

3.7 Система Microsoft Exchange 2000 и NAS

Популярная корпоративная система обмена мгновенными сообщениями Microsoft Exchange 2000 представляет собой один из главных продуктов в семействе BackOffice от компании Microsoft. Архитектура Exchange 2000 значительно отличается от Exchange 5.5. Хотя в Microsoft Exchange 2000 было включено множество новых возможностей, не обошлось и без недостатков; один из них состоит в том, что эту систему нельзя использовать совместно с устройствами хранения NAS. В данной книге рассматриваются те компоненты Exchange 2000, которые имеют практическое значение.

На рис. 3.6 показан элемент архитектуры Microsoft Exchange 2000. Обратите внимание, что в данном случае рассматриваются только отдельные компоненты системы Exchange 2000, полное описание которой выходит за рамки книги. Протокольное ядро, показанное на рис. 3.6, предоставляет серверные функции для таких почтовых протоколов, как IMAP, РОРЗ и SMTP. Ядро Exchange Store (ESE) основано на базе данных Jet и используется для хранения и извлечения различных объектов, которые и формируют сообщение электронной почты. Файловая система ExIFS (Exchange Installable File System) предоставляет важные функции, описанные ниже.

■ Исключительно эффективный механизм межпроцессного взаимодействия для ESE и протокольного ядра Exchange.

Рис. 3.6. Архитектура подсистемы хранения Microsoft Exchange 2000

Рис. 3.7. Система Microsoft Exchange 2000 при использовании локального хранилища и хранилища NAS

Межпротокольный кэш файловых дескрипторов Windows NT. Дескриптор, созданный одним протоколом (например, POP), может использоваться другим протоколом (например, DAV).

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

Хотя ExIFS и предоставляет необходимые возможности, с точки зрения поставщиков решений NAS, эта файловая система является причиной основных проблем. В частности, при использовании NAS для хранилища Exchange драйвер ExIFS исключается из маршрута ввода-вывода данных (рис. 3.7).

Обратите внимание, что запросы Exchange Store или протокольного ядра Exchange к локальным файлам проходят через стек протоколов, изображенный в левой части диаграммы. Например, запрос на чтение проходит от Exchange Store к ExIFS, оттуда к NTFS, драйверу класса диска и драйверу порта. Но если запрос требует обращения к файлу, который хранится на устройстве NAS, то драйвер ExIFS находится вне маршрута ввода-вывода, поэтому запросы проходят через сетевой стек, изображенный в правой части диаграммы. Таким образом, запрос от Exchange Store будет направлен к пе- ренаправителю CIFS, оттуда в стек протоколов TCP/IP и к сетевой карте. Драйвер ExIFS в этом маршруте отсутствует.

Обратите внимание: архитектурные особенности, представленные на рис. 3.6 и рис. 3.7, относятся только к Microsoft Exchange 2000 и не имеют никакого отношения к Microsoft Exchange 5.5.

 

3.8 Сложности практической реализации

Начиная с Windows 2000, компания Microsoft предоставляет новую модель мини-драйвера, которая позволяет независимым поставщикам создавать сетевые файловые системы. От поставщиков требуется создать мини-драйвер, который поддерживает особенности протокола выбранной сетевой файловой системы. Общие для всех сетевых файловых систем возможности (взаимодействие с Windows и диспетчером кэша) обеспечиваются библиотекой драйвера. Компания Microsoft предоставляет мини-драйверы для файловых систем CIFS, NFS и WebDAV.

На данный момент CIFS де-факто является индустриальным стандартом для обеспечения взаимодействия между клиентами и серверами Windows. Файловая система CIFS реализована на различных платформах, поддерживающих сетевые файловые системы. Компания Microsoft, как и ассоциация SNIA (Storage Networking Industry Association), предоставляет бесплатную спецификацию CIFS. В обоих спецификациях CIFS рассматривается более старый протокол, реализованный в Windows NT 4.0. Кроме того, Microsoft за определенную плату предоставляет спецификации протокола SMB, который используется в более новых версиях Windows NT.

Компания Microsoft вступила в конкурентную борьбу с поставщиками решений NAS, построенных на платформах, отличных от Windows. Со своей стороны Microsoft предоставляет поставщикам устройств модифицированную версию операционной системы Windows. Время покажет, насколько успешной окажется эта стратегия, но на данный момент компании Microsoft удалось занять заметную нишу рынка операционных систем для решений NAS.

Программный продукт Microsoft Exchange 2000 не работает с устройствами NAS. Ожидается, что со временем компания Microsoft предложит версию этого продукта, которая поддерживает хранение данных на базе программы SQL Server. Учитывая, что новая версия SQL все еще не появилась в продаже, гарантировать сроки появления новых версий этих продуктов невозможно. Предпримет ли Microsoft шаги, необходимые для решения проблемы взаимодействия Microsoft Exchange 2000 и NAS? Помните о реальных сроках выхода продуктов на рынок и регулярных их переносах. Несмотря на то что Microsoft Exchange 2000 уже давно доступен на рынке, множество клиентов продолжают использовать Microsoft Exchange 5.5.

 

3.9 Резюме

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

Обычно к устройствам NAS обращаются клиентские системы. Обратите внимание: в данном случаеклиент – термин относительный. Клиентом устройства NAS может быть сервер баз данных. Клиенты используют протоколы CIFS/SMB или NFS. Первый, как правило, применяется клиентами, работающими под управлением Windows. Протокол NFS, в свою очередь, предназначен для клиентов на базе UNIX. Спецификации протокола CIFS разрабатываются компанией Microsoft и организацией SNIA. В этих спецификациях рассматриваются реализации протокола, которые характерны для Windows NT 4.0. Лицензия на протокол SMB для Windows 2000 и Windows Server 2003 предоставляется Microsoft за определенную плату.

Устройства NAS, которые одновременно обслуживают клиентов NFS и CIFS/SMB, характеризуются наличием серьезных проблем при обеспечении взаимодействия клиентов и сохранении метаданных файлов.