Многим сегодняшним пользователям Internet и внутрикорпоративных сетей такие традиционные способы получения информации, как протокол FTP, кажутся уже весьма неуклюжими. Их точку зрения не разделяют сетевые администраторы, у которых вызывает раздражение одна только мысль о напрасной трате сетевых ресурсов из-за массового применения средств HTTP для решения несвойственных им задач. Запросы и тех и других призвана удовлетворить распределенная файловая система. Она способна намного облегчить использование данных Сети и управление ими, сделав работу с сетевыми ресурсами столь же простой, как и с локальными.
В этом техническом обзоре, подготовленном Тестовым центром PC Week Labs, рассматриваются проблемы, связанные с практическим воплощением этой идеи. Мы надеемся, что приведенные здесь данные станут отправной точкой для сравнения систем, предлагаемых двумя основными разработчиками - фирмой Sun Microsystems и корпорацией Microsoft.
К достоинствам первой из них можно отнести широкое использование уже развернутой системы NFS (Network File System - сетевая файловая система) и лидирующее положение в области стандартизации Internet. Все это, как рассчитывает руководство Sun, поможет превратить создаваемую систему WebNFS в новый высокопроизводительный стандарт Сети.
Microsoft же делает акцент на то, что предложенная ею CIFS (Common Internet File System - общая файловая система Internet) в будущем станет одним из элементов Windows NT 4.0 и Windows 95. Кроме того, о поддержке этого проекта уже объявили корпорации Data General, Digital Equipment, Intel, Intergraph, а также фирма Network Appliance.
Однако разработчикам как WebNFS, так и CIFS придется преодолеть сильное противодействие уже существующей системы - Службы каталогов NetWare. В следующем году фирма Novell намерена вторгнуться на новые территории, предложив пользователям "родной" вариант своего детища для среды Windows NT.
Что под капотом
Одна из задач любой файловой системы состоит в том, чтобы сделать различия между применяемыми устройствами ввода-вывода и электронными средами хранения информации незаметными для пользователя. Но для распределенной файловой системы этого мало, к ней предъявляются дополнительные требования. Она должна скрывать от оператора не только проведение физических операций низкого уровня, но и размещение данных в различных физических хранилищах.
Для запуска программы или обращения к ресурсу пользователю распределенной файловой системы нужно знать только их имена, а где находится нужный ему файл - на жестком диске в этом же офисе или на другом континенте, его интересовать не должно.
Как WebNFS, так и CIFS упрощают доступ к содержимому файла, где бы он ни располагался физически, исключая утомительную и многоступенчатую процедуру его пересылки. CIFS использует для этого протокол SMB (Server Message Block - блоки сообщений сервера), который уже принят в качестве стандарта Open Group и описан в спецификации Open CAE Specification C209. На сегодняшний день он входит составной частью в Windows 95, Windows NT и OS/2, доступен на Unix, VMS и других платформах.
Однако нельзя забывать, что различные платформы налагают собственные ограничения даже на столь простой элемент, как имя файла. В стандарте FAT (File Allocation Table - таблица размещения файлов), применяемом в DOS и Windows, имена не должны включать больше 8 знаков (и никаких пробелов, пожалуйста!) плюс трехзначное расширение, которое, как правило, используется в качестве ненадежного идентификатора типа файла.
Пользователи Macintosh, напротив, привыкли к довольно длинным именам, которые могут состоять из 32 знаков. Но всех превзошла OS/2 ее файловая система High Performance File System предлагает имена, скорее напоминающие предложения, их длина может доходить до 255 знаков, включая пробелы. Такую же длину допускает и Windows 95, преодолевая тем самым ограничения FAT, однако здесь возможны самые непредсказуемые результаты - далеко не все старые приложения и утилиты поддаются на уловки новой операционной системы.
Важно, что внутри
Распределенная файловая система имеет дело с внешними ярлыками, поэтому ей приходится решать довольно сложную задачу определения содержания материала. Пользователи должны получать ту информацию, которая им требуется; в большинстве случаев им нет дела до другой, хранящейся под тем же именем. Разве что одноименные файлы выполняют специальные функции, например представляют собой несколько видов данных, необходимых для говорящих на разных языках людей.
Несоответствия полученной информации сделанному запросу легко избежать, если не допускать дублирования файлов. Однако в системах, разнесенных территориально на значительные расстояния, это приведет к снижению производительности. Чтобы обеспечить пользователям быстрый доступ к данным, требуется установить порядок автоматического кэширования локальных копий часто используемых файлов и своевременного обновления их содержания, причем последнее не должно приводить к чрезмерному расходу сетевых ресурсов.
Некоторые существующие файловые системы помогают решить такую задачу, другие же никаких средств для этого не предлагают. Например, в структуре файлов Macintosh предусмотрено ветвление ресурсов (resource fork) и ветвление данных (data fork). Первое из них содержит именованные модули, доступные только для чтения, которые загружаются по мере необходимости, а при нехватке свободной памяти могут удаляться из ОЗУ с возможностью последующей повторной загрузки.
Другие, более распространенные файловые системы такой внутренней структуры не имеют. Файлы в DOS и Unix представляют собой просто последовательность байтов, и каждое конкретное приложение - но не операционная система - решает, какая их часть ему необходима и как ее получить. Программные средства, требующие большого объема оперативной памяти и пространства хранения на локальном диске, при недостатке ресурсов могут отказаться функционировать должным образом.
Отсюда следует, что распределенной файловой системе приходится принимать на себя управление физическими операциями подсистемы хранения, скрывая их от интерфейса приложения. Таким образом она создает иллюзию, что приложению выделены все необходимые для его работы ресурсы, хотя на самом деле они одновременно используются и для решения других задач.
Но распределенная файловая система не должна ограничиваться пассивной защитой, обеспечивающей работоспособность подобных приложений. Ей необходимы и активные средства, предотвращающие возможность злоупотреблений, благодатную почву для которых создает простота подключения к другим компьютерам. Файловые системы, созданные для работы одного пользователя или для локальной группы, не имеют ни интегральных средств определения принадлежности файла, ни возможности легко устанавливать права на его чтение, редактирование или (в случае исполнительного файла) запуск.
В связи с этим перед разработчиками распределенной файловой системы возникает серьезная дилемма. Во-первых, их продукт должен обеспечивать такую же степень защищенности файлов, как и среда, где они размещаются физически. Во-вторых, нужно предоставить возможность прозрачного и простого доступа к файлам тем пользователям из другой клиентской среды, которые имеют право на работу с ними, но не знакомы с правилами обеспечения безопасности или не привыкли их выполнять.
Завоевание "Паутины"
С началом эры электронной коммерции в Internet возник мощный финансовый стимул для разработки платформно-независимых средств обеспечения безопасности. Многие сообщества производителей и пользователей склоняются к принятию стандарта электронной подписи. Он должен гарантировать, что полученные потребителем сообщения, данные и программы дошли до него в оригинальном виде и что при пересылке по неконтролируемым каналам в них не было внесено никаких изменений.
В этом плане привлекательные возможности открывает система кодирования информации в языке HTML, которая преобразует содержимое файла в поток байтов при обеспечении соответствующего уровня его защищенности. Это позволяет упаковывать данные в формат, независимый от системной архитектуры. Язык Java фирмы Sun предоставляет все необходимые средства для универсальной упаковки, пересылки и исполнения программ, а HTML-браузеры получают все более широкое распространение в качестве клиентского ПО для продуктов самых разных производителей.
Однако расширение масштабов и упрощение доступа к информации имеет и свои отрицательные стороны. Злонамеренные (или просто недисциплинированные) пользователи и некоторые приложения могут в буквальном смысле слова поглотить ресурсы своего хост-компьютера, создавая угрозу своевременному получению доступа к данным и скорости предоставления сетевых услуг. Эти проблемы, в свою очередь, не могут не вызвать появления различных организационных и технических средств их решения. Здесь напрашивается аналогия с платными частными автомагистралями, которые в разных частях США предлагают высокоскоростную альтернативу перегруженным общественным дорогам.
Подводя итог, отметим, что инициативы, подобные выдвинутым Sun и Microsoft, не следует рассматривать как монолитные решения. Они, скорее, призваны служить каркасом, на котором будут создаваться новые средства, отвечающие запросам самых разных типов пользователей.
Питер Коффи
С аналитиком в области передовых технологий Питером Коффи можно связаться по адресу: 3571756@mcimail.com.
В поисках справедливого распределения
Что должна обеспечить распределенная файловая система:
- Прозрачность - Доступ к любому файлу должен осуществляться столь же просто, как и к расположенным на локальной системе
- Скорость работы - Часто используемые удаленные файлы для обеспечения быстрого доступа должны кэшироваться или тиражироваться
- Безопасность - При распределенном доступе должен сохраняться тот же уровень безопасности данных, который обеспечивает локальная файловая система
- Узнаваемость - Файлы, размещенные на "чужой" платформе, должны появляться перед пользователем в том виде, который свойственен его клиентской системе
