ФЕДЕРАЛЬНОЕ АГЕНТСТВО ВОЗДУШНОГО ТРАНСПОРТА
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
____________________________________________________________________________________________________________________
СЕТЕВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ.
СЕТЕВЫЕ ФАЙЛОВЫЕ СИСТЕМЫ
И СЛУЖБА КАТАЛОГОВ
Утверждено Редакционно-
издательским Советом МГТУ ГА
ББК 32.973.202-018.2я73-1+32.973.26-018.2я73-1
Печатается по решению редакционно-издательского совета
Московского государственного технического университета ГА
Рецензенты: канд. физ.-мат. наук, доц. ;
Ч48 Сетевые операционные системы. Сетевые файловые системы и служба каталогов: Учебное пособие. - М.: МГТУ ГА, 2010. –68 с. 10 ил., лит.: 4 наим.
Ц33(03)-10 Св. тем. план 2010 г.
ЧЕРКАСОВА Наталья Ивановна
Редактор
Подписано в печать 11.10.10 г.
Печать офсетная Формат 60х84/16 4,0 уч.-изд. л.
3,95 усл. печ. л. Заказ № 000/ Тираж 100 экз.
125493 Москва, ул. Пулковская, д.6а
© Московский государственный
технический университет ГА, 2010
Раздел 1. Состав сетевых операционных систем
1.1. Сетевые ОС. Определение, основные свойства
Сеть (Network) может быть какой угодно, начиная от простого набора компьютеров (два связанных компьютера уже есть сеть) до глобальной сети Internet , использующей множество разнообразных средств связи, включая микроволновые и спутниковые технологии.
Сеть состоит из компьютеров, средств связи (например, медных или оптоволоконных кабелей) и прочих устройств, таких как концентраторы различных типов и маршрутизаторы (которые позволяют управлять сетевым трафиком), адаптеры (служат для подключения компьютера к сети), образующие сетевую структуру. Технологии передачи информации также весьма разнообразны.
Рассматриваются две разновидности сетей: LAN (Local area network) – локальная сеть, набор компьютеров и устройств, объединенных в пределах одного здания, и WAN(Wide area network) – глобальная сеть совмещает в себе несколько географически разделенных локальных сетей, которые связаны посредством различных WAN - технологий.
Назначение сети зависит от потребностей человека или организации, но, в общем случае, можно перечислить следующие возможности использования сетей:
1) совместное использование файлов. Сеть позволяет использовать файлы данных как хранящиеся в компьютере конкретного пользователя, так и файлы, размещенные на специализированном файловом сервере;
2) совместное использование аппаратных средств;
3) совместное использование программного обеспечения ;
4) обмен информацией между пользователями;
5) сетевые игры.
Сеть представляет в пользование не только локальные ресурсы, но само наличие сети означает, что ее можно объединить с другими сетями.
Операционные системы для сетей во многом аналогичны ОС автономного компьютера. Однако если последняя представляет пользователю некую виртуальную вычислительную машину, то сетевая ОС, представляя пользователю некую виртуальную вычислительную систему, работать с которой гораздо проще, чем с реальной сетевой аппаратурой, не полностью скрывает распределенную природу своего реального прототипа. Можно сказать, что сетевая ОС предоставляет пользователю виртуальную сеть. В идеальном случае сетевая ОС должна представлять пользователю сетевые ресурсы в виде ресурсов единой централизованной виртуальной машины. Такие операционные системы называются распределенные ОС или истинно распределенные ОС.
Распределенные ОС, динамически и автоматически распределяя работы по различным машинам системы для обработки, заставляют работать набор сетевых машин как виртуальный унипроцессор. Распределенная ОС работает как единая операционная система в масштабах вычислительной системы.
Современные сетевые ОС не являются истинно распределенными, то есть степень автономности каждого компьютера в сети, работающего под управлением сетевой ОС, значительно выше по сравнению с компьютерами, работающими под управлением распределенной ОС.
Термин сетевая ОС используется в двух значениях: во-первых, как совокупность ОС всех компьютеров сети, во-вторых, как ОС отдельного компьютера, способного работать в сети. Функционально сетевую ОС можно разделить на следующие компоненты:
1) средства управления локальными ресурсами, то есть все функции ОС автономного компьютера;
2) серверная часть ОС – средство предоставления локальных ресурсов и услуг в общее пользование;
3) клиентская часть ОС – средства доступа к удаленным ресурсам и услугам;
4) транспортные средства ОС, которые совместно с коммуникационной системой обеспечивают передачу сообщений между компьютерами сети.
Совокупность серверной и клиентской частей ОС, предоставляющих доступ к конкретному ресурсу через сеть, называется сетевой службой. Сетевая служба предоставляет пользователю сети некий набор услуг, который называется сетевым сервисом. Каждая служба связана с определенным типом сетевых ресурсов и \ или определенным способам доступа к этим ресурсам.
Сетевые службы являются клиент – серверными системами, то есть содержит в своем составе клиентскую и серверную часть. Однако сетевая служба может быть представлена в ОС либо обеими частями, либо только одной из них.
Необходимо отметить, что при предоставлении сетевой службой некоторой услуги используются ресурсы не только сервера, но и клиента. Принципиальной же разницей между клиентом и сервером является то, что инициатором выполнения работы сетевой службы всегда выступает клиент, а сервер всегда находится в режиме пассивного ожидания запросов.
Хотя один тип сервера может быть рассчитан на работу с клиентами разного типа, клиент и сервер должны поддерживать общий стандартный протокол взаимодействия.
Глубина внедрения сетевых служб в ОС определяет несколько подходов к построению сетевых ОС:
1) сетевые службы объединены в виде некоторого набора – оболочки;
2) сетевые службы поставляются и производятся в виде отдельного продукта;
3) сетевые службы внедрены в ОС.
Различные цели, преследуемые при создании различных сетей, предполагают наличие различных типов сетей. Одноранговая сеть (Peer-to-Peer Network) представляет собой простой способ объединения персональных компьютеров в тех случаях, когда необходимо совместное использование файлов и прочих ресурсов. В одноранговой сети нет сервера, и все компьютеры функционируют как равноправные узлы. Одноранговую сеть часто называют рабочей группой (Workgroup), так как этот термин ассоциируется с равноправным сотрудничеством без централизованного управления.
Узел сети – компьютер, связывающий две сети, использующий одинаковые протоколы. Узел обеспечивает только связь двух совместимых программ на двух таких сетях. Узлы, существенно, используют адресную информацию, заключенную в передаваемых пакетах. Узлы являются устройствами сетевого уровня.
Рассмотрим программное обеспечение подобных сетей. В одноранговых сетях на всех компьютерах устанавливается такая ОС, которая предоставляет всем компьютерам сети потенциально равные возможности. Очевидно, что такие одноранговые ОС должны включать как серверные, так и клиентские компоненты сетевых служб.
При потенциальном равноправии всех компьютеров в одноранговой сети часто возникает функциональная неоднородность. В сети могут находиться пользователи, не предоставляющие свои ресурсы в совместное использование.
В этом случае серверные возможности их ОС не активизируются, и компьютеры выполняют роль «чистых» клиентов. Возможна и обратная ситуация, когда на некоторых компьютерах выполняются только функции по обслуживанию запросов клиентов, то есть они становятся «чистыми» серверами. Однако изначально в одноранговых сетях специализация ОС не зависит от роли компьютера.
ОС DOS не поддерживала одноранговые сети, поэтому для совместного использования файлов или принтеров требовались дополнительные программные продукты, т. е. сетевые функции реализовывались сетевыми оболочками, работающими поверх ОС. Для поддержки рабочих групп использовались такие программные продукты, как Artisoft LANtastic, Novell NetWare Lite, Personal NetWare и Windows for Workgroup 3.11. Все последующие версии Windows поддерживают рабочие группы.
Дистрибутивы Linux также поддерживают создание рабочих групп из компьютеров, работающих под управлением Windows или Linux с помощью программы Samba.
Хотя к основным достоинствам одноранговых сетей относится, прежде всего, простота установки, имеется и ряд других преимуществ:
1) обычно все необходимое обеспечение уже включено в состав ОС;
2) не требуется системное администрирование, и отдельные пользователи сами могут управлять ресурсами;
3) узлы сети не зависят от сервера, следовательно, они могут работать даже тогда, когда другие узлы недоступны.
Однако в подобной сети жестко определено количество компьютеров – не более десяти. Распределение ресурсов по сети при наличии большого числа узлов осложнит доступ к файлам, каждый из которых может быть защищен собственным паролем. Кроме этого, здесь невозможна централизованная защита, единственно возможной защитой является защита на уровне ресурса. В целом происходит повышение нагрузки на компьютеры из-за совместного использования ресурсов.
Сети с выделенным сервером (или серверами) (Server – based network) могут быть очень крупными и предоставлять пользователям более широкий диапазон ресурсов по сравнению с одноранговыми сетями. Связано это, прежде всего, с тем, что в такой сети имеются различные специализированные серверы.
Кроме того, эти сети позволяют осуществлять централизованное управление ресурсами и добавлять в сеть новые компьютеры, пользователей и ресурсы. Такие сети являются масштабируемыми, то есть могут легко расширяться.
Единственным требованием к такой сети является наличие компьютера, на котором запущена сетевая операционная система, такой компьютер называется сервером.
Как и у одноранговой сети, сети с выделенным сервером имеют свои достоинства и недостатки. Прежде всего, перечислим достоинства:
1) для получения доступа к сетевым ресурсам пользователь вводит только одно регистрационное имя и пароль;
2) управление безопасностью в сети и сетевыми ресурсами осуществляется централизованно;
3) централизованное размещение позволяет выполнять резервное копирование каталогов и файлов;
4) специализированные серверы обеспечивают быстрый доступ к ресурсам;
5) подобные сети можно расширять.
Теперь отметим ряд недостатков:
1) необходимо осуществлять настройку и управление ресурсами в сети, то есть необходим системный администратор;
2) при сбое главного сервера доступ к сетевым ресурсам прекращается;
3) экономически сети с выделенным сервером выгодны только для достаточно крупных компаний.
Таким образом, в зависимости от того, как распределены функции между компьютерами сети, они могут выступать в трех различных ролях:
1) компьютер в роли выделенного сервера сети, то есть только обслуживающий запросы других компьютеров;
2) компьютер, обращающийся с запросом к ресурсам другой машины, - клиентский узел;
3) компьютер, совмещающий функции клиента и сервера, - одноранговый узел.
Следовательно, можно определить различные схемы построения сети, как:
1) одноранговая сеть – сеть на основе одноранговых узлов;
2) сеть с выделенным сервером – сеть на основе клиентов и серверов.
Однако сеть может включать в себя узлы всех типов – гибридная сеть, которую иногда относят к сетям с выделенным сервером.
Клиентские ОС в сетях с выделенным сервером обычно освобождены от серверных функций, что значительно упрощает их организацию. Разработчики таких ОС уделяют основное внимание пользовательскому интерфейсу и клиентским частям сетевых служб. В тоже время на серверах используются специальные варианты сетевых ОС, которые оптимизированы для работы в качестве сервера и называются серверными ОС.
Специализация ОС для работы в качестве сервера является естественным способом повышения эффективности серверных операций, так как интенсивность запросов к совместно используемым ресурсам может быть очень большой и сервер должен справляться с ним без больших задержек. Чем меньше функций выполняет ОС, тем эффективней можно их реализовать.
Разработчики NetWare для оптимизации выполнения сервисных услуг полностью исключили из системы многие элементы универсальной ОС, оставив исключительно сетевые. Однако многие компании, разрабатывающие сетевые ОС, выпускают два варианта операционных систем, основанных на одном базовом коде, но отличающемся набором служб и утилит, - серверные и клиентские ОС.
Различные сетевые службы могут быть размещены на нескольких специализированных серверах, а центральный сервер не только разрешает пользователю входить в сеть, но и определяет, к каким ресурсам ему будет предоставлен доступ.
Рассмотрим основные специализированные серверы.
Файловые серверы используются для хранения файлов, необходимых для пользователей сети. Серверы печати используются для управления сетевым принтером, по сути это управляющий канал связи с принтером.
Коммуникационный сервер использует специальное программное обеспечение, позволяющее пользователям общаться в сети. Он поддерживает службы электронной почты и телеконференций. На сервере приложений размещаются различные приложения, а сервер позволяет создавать сайт, хотя для размещения сайта можно использовать услуги провайдера.
Некоторые типы серверов используются не для получения доступа к ресурсам, а для повышения качества и эффективности работы в сети. Например, DNS - сервер (Domaine Name Service) – служба имен доменов выполняет преобразование дружественных имен в соответствующие адреса.
Теперь рассмотрим более подробно взаимодействие клиента и серверной ОС. Когда компьютер обращается к файлу на локальном диске или к принтеру, подключенному напрямую, запрос направляется процессору компьютера. Процессор выполняет запрос и все операции выполняются локально. При обращении к общим ресурсам файлового сервера или печати на удаленном принтере сетевое клиентское программное обеспечение выполнят специальную операцию, благодаря которой компьютер считает сетевые ресурсы локальными.
Этот процесс осуществляется компонентом клиентского программного обеспечения, который называют редиректор (REDIRECTOR). Он перехватывает любые запросы, выполненные на компьютере, и в зависимости от типа запроса передает его на сетевой сервер для обработки или определяет, что этот запрос будет выполняться локально.
1.2. Поддержка сетей на основе ОС Windows 2000. Уровни OSI и сетевые компоненты ОС Windows 2000. Сетевые API
Рассмотрим механизмы построения сетевой операционной системы на примере ОС Windows 2000.
Эталонная модель OSI (The OSI Reference Model)
Чтобы помочь поставщикам в стандартизации и интеграции сетевого программного обеспечения в 1974 the International Organization for Standardization (ISO) определила программную модель пересылки сообщений между компьютерами. Результатом явилась the Open Systems Interconnection (OSI) – эталонная модель. Модель определяет семь уровней программного обеспечения (Рис.1).
DIV_ADBLOCK93">
Пунктирными линиями на рисунке показаны протоколы, применяемые для передачи запроса на удаленную машину. Каждый сетевой уровень считает, что он взаимодействует с эквивалентным уровнем на другой машине, который использует тот же протокол. Набор протоколов, передающих запросы по сетевым уровням, называется стеком протоколов.
Сетевые компоненты Windows 2000 (Networking Components)
На рис. 2 представлена общая схема сетевых протоколов Windows 2000, их соответствие уровням эталонной модели, а также протоколы, используемые различными уровнями. Как видно, между уровнями модели и сетевыми компонентами нет точного соответствия. Некоторые компоненты охватывают несколько уровней. Далее приводится список и краткое описание:
1) Networking(Сетевые) API обеспечивают независимое от протоколов взаимодействие приложений через сеть. Networking API реализуются либо в режиме ядра и пользовательском режиме, либо только в пользовательском. Некоторые networking API являются оболочками других API и реализуют специфическую модель программирования или предоставляют дополнительные сервисы. (Термином networking API обозначаются любые программные интерфейсы, представляемые сетевым программным обеспечением);
2) клиенты TDI (Transport Driver Interface). Драйверы устройств режима ядра, обычно реализующие ту часть сетевого API, которая работает в режиме ядра. Клиенты TDI называются так из-за того, что I/O пакеты запросов ввода-вывода (IRP), которые они посылают драйверам протоколов Windows 2000, форматируются по стандарту Transport Driver Interface standard (документировано в DDK). Этот стандарт определяет общий интерфейс программирования драйверов устройств режима ядра;
3) транспорты TDI. Представляют собой драйверы протоколов режима ядра и часто называются транспортами, (Network Driver Interface Specification), NDIS-драйверами протоколов или драйверами протоколов. Они принимают IRP от клиентов TDI и обрабатывают запросы, представленные этими IRP. Обработка запросов может потребовать взаимодействия через сеть с другими равноправными компьютерами, в этом случае транспорт TDI добавляет к данным IRP заголовки, специфические для конкретного протокола (TCP, UDP, IPX), и взаимодействует с драйверами адаптеров через функции NDIS (also documented in the DDK). В общем, транспорты TDI связывают приложения через сеть, выполняя такие операции, как сегментация сообщений, их восстановление, упорядочение, подтверждение и повторная передача;
4) библиотека NDIS (Ndis. sys). Инкапсулирует функциональность для драйверов адаптеров, скрывая от них специфику среды Windows 2000, работающей в режиме ядра. NDIS library экспортирует функции для транспортов TDI, а также функции поддержки для драйверов адаптеров;
5) минипорт – драйверы NDIS. Драйверы режима ядра, отвечающие за организацию интерфейсов между TDI transports и конкретными сетевыми адаптерами. NDIS miniport drivers пишутся так, чтобы они были заключены в оболочку Windows 2000 NDIS library. Такая инкапсуляция обеспечивает межплатформенную совместимость с потребительскими версиями Windows. NDIS miniport drivers не обрабатывают process IRP; а регистрируют интерфейс таблицы вызовов NDIS library, которая содержит указатели на функции, соответствующие функциям, экспортируемым библиотекой NDIS для TDI transports. NDIS miniport drivers взаимодействуют с сетевыми адаптерами, используя функции NDIS library, которые вызывают соответствующие (HAL) функции.
Примечание: Диспетчер ввода-вывода (I/O manager) определяет модель доставки запросов на ввод-вывод драйверам устройств. Большинство запросов ввода-вывода представляется I/O пакетами запросов ввода-вывода (I/O request packets IRP), передаваемых от одного компонента подсистемы ввода-вывода другому. IRP – это структура данных, которая содержит информацию, полностью описывающую запрос ввода-вывода.
Фактически четыре нижних сетевых уровня часто обозначают собирательным термином «транспорт», а компоненты, расположенные на трех верхних уровнях – термином « пользователи транспорта».
DIV_ADBLOCK96">
Протокол SMB является протоколом прикладного уровня, включающим сетевой уровень и уровень представления.
SMB реализует:
1) установление сессии;
2) файловый сервис;
3) сервис печати;
4) сервис сообщений.
CIFS – открытый Microsoft стандарт (документированный в Platform SDK), который позволяет другим платформам взаимодействовать с Windows 2000 файловым сервером и с Windows 2000 файловым клиентом. Например, Samba позволяет UNIX системам выступать в роли файлового сервера для Windows 2000 клиента и UNIX приложениям получать доступ к файлам, хранящимся в системах под управлением Windows 2000 систем. Другие поддерживающие CIFS платформы включают DEC VMS и Apple Macintosh.
Совместное использование файлов в Windows 2000 основывается на редиректоре (redirector FSD - redirector, для краткости), который выполняется на клиентской машине и взаимодействует с FSD redirector сервера. FSD перехватывает запрос Win32 file I/O, направленный в файлы, расположенные на сервере, и передает CIFS messages файловой системе сервера. Сервер получает CIFS messages и преобразует их обратно в запросы на операцию ввода-вывода, которые он выдает локальным FSDs, таким как NTFS.
Поскольку они интегрированны с подсистемой ввода-вывода Windows 2000 (I/O system), redirector and server FSDs имеют некоторые преимущества перед альтернативной реализацией файловых серверов:
1) они могут напрямую взаимодействовать с TDI transports и локальными FSD;
2) они бесшовно интегрируются с диспетчером кеша, что позволяет кешировать данные с файл-сервера на клиентских системах.
Приложения могут использовать стандартные Win32 file I/O функции, такие как CreateFile, ReadFile, and WriteFile для доступа к удаленным файлам.
В Windows 2000 redirector server FSD используют стандартные правила именования сетевых ресурсов, применяемые всеми файл-серверами и клиентскими программами режима ядра. Если подключение к сетевому ресурсу производится по букве диска, имена сетевых файлов указываются также как локальные. Тем не менее, redirector также поддерживает UNC имена
Как server FSD, так и redirector имеют Win32 сервисы, Server and Workstation, выполняемые в процессе service control manager (SCM) и предоставляющие драйверам интерфейсы административного управления.
Примечание:
Можно реализовать серверное приложение как простую исполняемую программу, но можно использовать особый вид – служба (сервис). Служба – это приложение, содержащее дополнительную инфраструктуру, которая позволяет SCM управлять этим приложениям. Все серверные приложения, поставляемые с системой, работают как службы.
Интерфейс транспортных драйверов (TDI)
Открытая архитектура сетевых средств Windows NT обеспечивает работу своих рабочих станций (и серверов) в гетерогенных сетях не только путем предоставления возможности динамически загружать и выгружать сетевые средства, но и путем непосредственного переключения с программных сетевых средств, ориентированных на взаимодействие с одним типом сетей, на программные средства для другого типа сетей в ходе работы системы. Windows NT поддерживает переключение программных средств на трех уровнях:
1) на уровне редиректоров - каждый редиректор предназначен для своего протокола (SMP, NCP, NFS, VINES);
2) на уровне драйверов транспортных протоколов, предоставляя для них и для редиректоров стандартный интерфейс TDI;
3) на уровне драйверов сетевых адаптеров - со стандартным интерфейсом NDIS 3.0.
Для доступа к другим типам сетей в Windows NT, помимо встроенного, могут загружаться дополнительные редиректоры. Специальные компоненты Windows NT решают, какой редиректор должен быть вызван для обслуживания запроса на удаленный ввод-вывод. За последние десятилетия получили распространение различные протоколы передачи информации по сети. И хотя Windows NT поддерживает не все эти протоколы, она, по крайней мере, разрешает включать их поддержку.
После того, как сетевой запрос достигает редиректора, он должен быть передан в сеть. В традиционной системе каждый редиректор жестко связан с определенным транспортным протоколом. В Windows NT поставлена задача гибкого подключения того или иного транспортного протокола, в зависимости от типа транспорта, используемого в другой сети. Для этого во всех редиректорах нижний уровень должен быть написан в соответствии с определенными соглашениями, которые и определяют единый программный интерфейс, называемый интерфейсом транспортных драйверов (TDI).
TDI позволяет редиректорам оставаться независимым от транспорта. Таким образом, одна версия редиректора может пользоваться любым транспортным механизмом. TDI обеспечивает набор функций, которые редиректоры могут использовать для пересылки любых типов данных с помощью транспортного уровня. TDI поддерживает как связи с установлением соединения (виртуальные связи), так и связи без установления соединения (дейтаграммные связи). Хотя LAN Manager использует связи с установлением соединений, Novell IPX является примером сети, которая использует связь без установления соединения. Microsoft изначально обеспечивает транспорты - NetBEUI (NetBIOS Extended User Interface), TCP/IP, IPX/SPX, DECnet и AppleTalk.
Исходя из описанного выше, представим следующие выводы.
Интерфейс транспортных драйверов (TDI) - это общий интерфейс, позволяющий таким компонентам, как редиректор и сервер связываться с различными сетевыми транспортами, т. е. оставаться независимыми от транспорта. Отметим, что (TDI) – это не драйвер, а стандарт для передачи сообщений между уровнями сетевой архитектуры. Microsoft определила стандарт TDI, чтобы драйверам сетевых протоколов не приходилось использовать отдельные интерфейсы для каждого необходимого им транспортного протокола.
Как уже говорилось, Интерфейс транспортных драйверов (TDI) по сути представляет правила формирования сетевых запросов в IRP, а также выделения сетевых адресов и коммуникационных соединений. Транспортные протоколы, отвечающие данному стандарту, экспортируют интерфейс TDI своим клиентам, в число которых входят драйверы сетевых API и редиректор. Транспортный протокол, реализованный в виде драйвера устройства, называется транспортами TDI, а поскольку они есть драйверы, то преобразуют получаемые от клиентов запросы в IRP. Интерфейс транспортных драйверов (TDI образуют функции поддержки из библиотеки \ winnt\system32\drivers\tdi. sys.
Библиотека NDIS (Ndis . sys )
Введем также понятие граничного слоя. Граница – это унифицированный интерфейс между функциональными уровнями в модели сетевой архитектуры. Создание границ как разделов между сетевыми уровнями облегчает третьим фирмам разработку сетевых драйверов и сервисов в среде открытых систем.
Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто были рассчитаны на взаимодействие с определенным типом транспортного протокола. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были писать различные варианты одного и того же драйвера, рассчитанные на связь с разными протоколами транспортного уровня.
Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые "спецификация интерфейса сетевого драйвера " (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т. п.), используя один сетевой адаптер и один сетевой драйвер. Среда NDIS использовалась в сетях LAN Manager, но для Windows NT она была обновлена.
Через свою нижнюю границу драйвер сетевого адаптера обычно взаимодействует непосредственно с адаптером или адаптерами, которые он обслуживает. Драйвер сетевого адаптера, реализованный для среды NDIS, управляет адаптером не непосредственно, а использует для этого функции, предоставляемые NDIS (например, для запуска ввода-вывода или обработки прерываний). Таким образом, среда NDIS образует некую оболочку, которая позволяет достаточно просто переносить драйверы сетевых адаптеров из одной ОС в другую. NDIS позволяет сетевым драйверам не содержать встроенных знаний о процессоре или операционной системе, на которых он работает.
Безопасность в сети и доменная структура
Безопасность в сети означает защиту всех компонентов аппаратуры, программного обеспечения и хранимых данных от уничтожения, похищения, несанкционированного использования. Хорошо продуманный и умело построенный план обеспечения компьютерной безопасности, предоставляющий хороший мониторинг, облегчает контроль использования сетевых компьютеров, практически исключает случайное уничтожение или повреждение данных и делает невозможным или чрезвычайно трудным несанкционированное использование ресурсов.
Корпорация Microsoft включила требования безопасности в состав начальной спецификации для разработки Windows NT. Вопросы безопасности в Windows NT имеют первостепенное значение. Модель безопасности включает компоненты для контроля доступа к объектам (таким как файлы и разделяемые принтеры). Эти компоненты определяют, кто и к каким объектам может получить доступ, какое действие может быть произведено над объектом (например, запись в файл и т. д.), и какие события подлежат аудиту.
Безопасность сети Windows NT включает и доверительные отношения между доменами, что делает эту операционную систему защищенной наилучшим образом.
Архитектура модели безопасности
На рис. 3 показаны компоненты модели безопасности Windows NT, в число которых входят:
1) процессы входа в систему (Logon processes), которые получают от пользователей запросы на вход. Они включают интерактивный вход, который производится с помощью начального диалогового окна входа, и удаленные процессы входа, которые предоставляют удаленным пользователям доступ к процессам сервера Windows NT;
2) локальная служба безопасности (Local Security Authority, LSA), которая следит за тем, чтобы пользователь имел право на доступ (permission) в систему. Этот компонент является центром подсистемы безопасности Windows NT. Он генерирует маркеры доступа (access tokens), управляет локальной политикой безопасности и обеспечивает интерактивную аутентификацию пользователя. Кроме того, LSA контролирует политику аудита и заносит в журнал аудиторские записи, генерируемые монитором безопасности;
3) диспетчер безопасности пользовательских учетных записей (Security Account Manager, SAM), поддерживающий базу данных учетных записей пользователей, также известную под названием базы данных каталога (directory database). Эта база данных содержит информацию по всем учетным записям пользователей и групп. SAM обеспечивает сервис проверки пользователей, который используется LSA;
4) монитор безопасности (Security Reference Monitor), который проверяет, имеет ли пользователь разрешение на доступ к объекту и право на операцию, которую он пытается выполнить. Этот компонент принудительным образом осуществляет проверку уровня доступа и проводит политику аудита, определенную LSA. Он обеспечивает сервис для режимов ядра и пользователя, выполняющий проверку наличия необходимого уровня доступа для всех пользователей и процессов, пытающихся получить доступ к объекту. В случае необходимости этот компонент также генерирует записи в файл аудита.
В совокупности все эти компоненты также известны, как подсистема безопасности. Эта подсистема, называемая интегральной подсистемой (integral subsystem), не является подсистемой среды (environmental subsystem), потому что она распространяет свое действие на всю операционную систему Windows NT.
Файловая система NFS (Network File System) создана компанией Sun Microsystems. В настоящее время это стандартная сетевая файловая система для ОС семейства UNIX, кроме того, клиенты и серверы NFS реализованы для многих других ОС. Принципы ее организации на сегодня стандартизованы сообществом Интернета, последняя версия NFS v.4 описывается спецификацией RFC ЗОЮ, выпущенной в декабре 2000 года.
NFS представляет собой систему, поддерживающую схему удаленного доступа к файлам. Работа пользователя с удаленными файлами после выполнения операции монтирования становится полностью прозрачной - поддерево файловой системы сервера NFS становится поддеревом локальной файловой системы.
Одной из целей разработчиков NFS была поддержка неоднородных систем с клиентами и серверами, работающими под управлением различных ОС на различной аппаратной платформе. Этой цели способствует реализация NFS на основе механизма Sun RFC, поддерживающего по умолчанию средства XDR для унифицированного представления аргументов удаленных процедур.
Для обеспечения устойчивости клиентов к отказам серверов в NFS принят подход stateless, то есть серверы при работе с файлами не хранят данных об открытых клиентами файлах.
Основная идея NFS - позволить произвольной группе пользователей разделять общую файловую систему. Чаще всего все пользователи принадлежат одной локальной сети, но не обязательно. Можно выполнять NFS и на глобальной сети. Каждый NFS-сервер предоставляет один или более своих каталогов для доступа удаленным клиентам. Каталог объявляется достудным со всеми своими подкаталогами. Список каталогов, которые сервер передает, содержится в файле /etc/exports, так что эти каталоги экспортируются сразу автоматически при загрузке сервера. Клиенты получают доступ к экспортируемым каталогам путем монтирования. Многие рабочие станции Sun бездисковые, но и в этом случае можно монтировать удаленную файловую систему к корневому каталогу, при этом вся файловая система целиком располагается на сервере. Выполнение программ почти не зависит от того, где расположен файл: локально или на удаленном диске. Если два или более клиента одновременно смонтировали один и тот же каталог, то они могут связываться путем разделения файла.
В своей работе файловая система NFS использует два протокола.
Первый NFS-протокол управляет монтированием. Клиент посылает серверу полное имя каталога и запрашивает разрешение на монтирование этого каталога в какую-либо точку собственного дерева каталогов. При этом серверу не указывается, в какое место будет монтироваться каталог сервера. Получив имя, сервер проверяет законность этого запроса и возвращает клиенту дескриптор файла, являющегося удаленной точкой монтирования. Дескриптор включает описатель типа файловой системы, номер диска, номер индексного дескриптора (inode) каталога, который является удаленной точкой монтирования, информацию безопасности. Операции чтения и записи файлов из монтируемых файловых систем используют дескрипторы файлов вместо символьного имени.
Монтирование может выполняться автоматически, с помощью командных файлов при загрузке. Существует другой вариант автоматического монтирования: при загрузке ОС на рабочей станции удаленная файловая система не монтируется, но при первом открытии удаленного файла ОС посылает запросы каждому серверу и после обнаружения этого файла монтирует каталог того сервера, на котором расположен найденный файл.
Второй NFS-протокол используется для доступа к удаленным файлам и каталогам. Клиенты могут послать запрос серверу для выполнения какого-либо действия над каталогом или операции чтения или записи файла. Кроме того, они могут запросить атрибуты файла, такие как тип, размер, время создания и модификации. NFS поддерживается большая часть системных вызовов UNIX, за исключением open и close. Исключение open и close не случайно. Вместо операции открытия удаленного файла клиент посылает серверу сообщение, содержащее имя файла, с запросом отыскать его (lookup) и вернуть дескриптор файла. В отличие от вызова open вызов lookup не копирует никакой информации во внутренние системные таблицы. Вызов read содержит дескриптор того файла, который нужно читать, смещение в уже читаемом файле и количество байт, которые нужно прочитать. Преимуществом такой схемы является то, что сервер не запоминает ничего об открытых файлах. Таким образом, если сервер откажет, а затем будет восстановлен, информация об открытых файлах не потеряется, потому что она не поддерживается.
При отказе сервера клиент просто продолжает посылать на него команды чтения или записи в файлы, однако не получив ответа и исчерпав тайм-аут, клиент повторяет свои запросы. После перезагрузки сервер получает очередной повторный запрос клиента и отвечает на него. Таки образом, крах сервера вызывает только некоторую паузу в обслуживании клиентов, но никаких дополнительных действий по восстановлению соединений и повторному открытию файлов от клиентов не требуется.
К сожалению, NFS затрудняет блокировку файлов. Во многих ОС файл может быть открыт и заблокирован так, чтобы другие процессы не имели к нему доступа. Когда файл закрывается, блокировка снимается. В системах stateless, подобных NFS, блокирование не может быть связано с открытием файла, так как сервер не знает, какой файл открыт. Следовательно, NFS требует специальных дополнительных средств управления блокированием.
В NFS используется кэширование на стороне клиента, данные в кэш переносятся поблочно и применяется упреждающее чтение, при котором чтение блока в кэш по требованию приложения всегда сопровождается чтением следующего блока по инициативе системы. Метод кэширования NFS не сохраняет семантику UNIX для разделения файлов. Вместо этого используется не раз подвергавшаяся критике семантика, при которой изменения данных в кэшируемом клиентом файле видны другому клиенту, в зависимости от временных соотношений. Клиент при очередном открытии файла, имеющегося в его кэше, проверяет у сервера, когда файл был в последний раз модифицирован. Если это произошло после того, как файл был помещен в кэш, файл удаляется из кэша и от сервера получается новая копия файла. Клиенты распространяют модификации, сделанные в кэше, с периодом в 30 секунд, так что сервер может получить обновления с большой задержкой. В результате работы механизмов удаления данных из кэша и распространения модификаций данные, получаемые каким-либо клиентом, не всегда, являются самыми свежими.
Репликация в NFS не поддерживается.
Служба каталогов
Назначение и принципы организации
Подобно большой организации, большая компьютерная сеть нуждается в централизованном хранении как можно более полной справочной информации о самой себе. Решение многих задач в сети опирается на информацию о пользователях сети - их именах, используемых для логического входа в систему, паролях, правах доступа к ресурсам сети, а также о ресурсах и компонентах сети: серверах, клиентских компьютерах, маршрутизаторах, шлюзах, томах файловых систем, принтерах и т. п.
Приведем примеры наиболее важных задач, требующих наличия в сети централизованной базы справочной информации:
Такие примеры можно продолжать, но нетрудно привести и контраргумент, заставляющий усомниться в необходимости использования в сети централизованной базы справочной информации - долгое время сети работали без единой справочной базы, а многие сети и сейчас работают без нее. Действительно, существует много частных решений, позволяющих достаточно эффективно организовать работу сети на основе частных баз справочной информации, которые могут быть представлены обычными текстовыми файлами или таблицами, хранящимися в теле приложения. Например, в ОС UNIX традиционно используется для хранения данных об именах и паролях пользователей файл passwd, который охватывает пользователей только одного компьютера. Имена адресатов электронной почты также можно хранить в локальном файле клиентского компьютера. И такие частные справочные системы неплохо работают - практика это подтверждает.
Однако это возражение справедливо только для сетей небольших и средних размеров, в крупных сетях отдельные локальные базы справочной информации теряют свою эффективность. Хорошим примером, подтверждающим неприменимость локальных решений для крупных сетей, является служба имен DNS, работающая в Интернете. Как только размеры Интернета превысили определенный предел, хранить информацию о соответствии имен и IP-адресов компьютеров сети в локальных текстовых файлах стало неэффективно. Потребовалось создать распределенную базу данных, поддерживаемую иерархически связанными серверами имен, и централизованную службу над этой базой, чтобы процедуры разрешения символьных имен в Интернете стали работать быстро и эффективно.
Для крупной сети неэффективным является также применение большого числа справочных служб узкого назначения: одной для аутентификации, другой - для управления сетью, третей - для разрешения имен компьютеров и т. д. Даже если каждая из таких служб хорошо организована и сочетает централизованный интерфейс с распределенной базой данных, большое число справочных служб приводит к дублированию больших объемов информации и усложняет администрирование и управление сетью. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая требуется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение адресов: WINS устанавливает соответствие Netbios-имен IP-адресам, справочник DNS (сервер имен домена) оказывается полезным при подключении NT-сети к Интернету, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Очевидно, что такое разнообразие справочных служб усложняет жизнь администратора и приводит к дополнительным ошибкам, когда учетные данные одного и того же пользователя нужно ввести в несколько баз данных. Поэтому в новой версии Windows 2000 большая часть справочной информации о системе может храниться службой Active Directory - единой централизованной справочной службой, использующей распределенную базу данных и интегрированной со службой имен DNS.
Результатом развития систем хранения справочной информации стало появление в сетевых операционных системах специальной службы - так называемой службы каталогов (Directory Services), называемой также справочной службой (directory - справочник, каталог). Служба каталогов хранит информацию обо всех пользователях и ресурсах сети в виде унифицированных объектов с определенными атрибутами, а также позволяет отражать взаимосвязи между хранимыми объектами, такие как принадлежность пользователей к определенной группе, права доступа пользователей к компьютерам, вхождение нескольких узлов в одну подсеть, коммуникационные связи между подсетями, производственную принадлежность серверов и т. д. Служба каталогов позволяет выполнять над хранимыми объектами набор некоторых базовых операций, таких как добавление и удаление объекта, включение объекта в другой объект, изменение значений атрибута объекта, чтение атрибутов и некоторые другие. Обычно над службой каталогов строятся различные специфические сетевые приложения, которые используют информацию службы для решения конкретных задач: управления сетью, аутентификации пользователей, обеспечения прозрачности служб и других, перечисленных выше. Служба каталогов обычно строится на основе модели клиент-сервер: серверы хранят базу справочной информации, которой пользуются клиенты, передавая серверам по сети соответствующие запросы. Для клиента службы каталогов она представляется единой централизованной системой, хотя большинство хороших служб каталогов имеют распределенную структуру, включающую большое количество серверов, но эта структура для клиентов прозрачна.
Важным вопросом является организация базы справочных данных. Единая база данных, хранящая справочную информацию большого объема, порождает все то же множество проблем, что и любая другая крупная база данных. Реализация справочной службы как локальной базы данных, хранящейся в виде одной копии на одном из серверов сети, не подходит для большой системы по нескольким причинам, и в первую очередь вследствие низкой производительности и низкой надежности такого решения. Производительность будет низкой из-за того, что запросы к базе от всех пользователей и приложений сети будут поступать на единственный сервер, который при большом количестве запросов обязательно перестанет справляться с их обработкой. То есть такое решение плохо масштабируется в отношении количества обслуживаемых пользователей и разделяемых ресурсов. Надежность также не может быть высокой в системе с единственной копией данных. Кроме снятия ограничений по производительности и надежности желательно, чтобы структура базы данных позволяла производить логическое группирование ресурсов и пользователей по структурным подразделениям предприятия и назначать для каждой такой группы своего администратора.
Проблемы сохранения производительности и надежности при увеличении масштаба сети обычно решаются за счет распределенных баз данных справочной информации. Разделение данных между несколькими серверами снижает нагрузку на каждый сервер, а надежность при этом достигается за счет наличия нескольких реплик каждой части базы данных. Для каждой части базы данных можно назначить своего администратора, который обладает правами доступа только к объектам своей порции информации обо всей системе. Для пользователя же (и для сетевых приложений) такая распределенная база данных представляется единой базой данных, которая обеспечивает доступ ко всем ресурсам сети вне зависимости от того, с какой рабочей станции поступил запрос.
Существуют два популярных стандарта для служб каталогов. Во-первых, это стандарт Х.500, разработанный ITU-T (во время разработки стандарта эта организация носила имя CCITT). Этот стандарт определяет функции, организацию справочной службы и протокол доступа к ней. Разработанный в первую очередь для использования вместе с почтовой службой Х.400 стандарт Х.500 позволяет эффективно организовать хранение любой справочной информации и служит хорошей основой для универсальной службы каталогов сети.
Другим стандартом является стандарт LDAP (Light-weight Directory Access Protocol), разработанный сообществом Интернета. Этот стандарт определяет упрощенный протокол доступа к службе каталогов, так как службы, построенные на основе стандарта Х.500, оказались чересчур громоздкими. Протокол LDAP получил широкое распространение и стал стандартом де-факто в качестве протокола доступа клиентов к ресурсам справочной службы.
Существует также несколько практических реализаций служб каталогов для сетевых ОС. Наибольшее распространение получила служба NDS компании Novell, разработанная в 1993 году для сетевой ОС NetWare 4.0, а сегодня реализованная также и для Windows NT/2000. Большой интерес вызывает служба каталогов Active Directory, разработанная компанией Microsoft для Windows 2000. Обе эти службы поддерживают протокол доступа LDAP и могут работать в очень крупных сетях благодаря своей распределенности.
Служба каталогов NDS
Служба NDS (NetWare Directory Services) - это глобальная справочная служба, опирающаяся на распределенную объектно-ориентированную базу данных сетевых ресурсов. База данных NDS содержит информацию обо всех сетевых ресурсах, включая информацию о пользователях, группах пользователей, принтерах, томах и компьютерах. ОС NetWare (а также другие клиенты NDS, работающие на других платформах) использует информацию NDS для обеспечения доступа к этим ресурсам.
База данных NDS заменила в свое время справочник bindery предыдущих версий NetWare. Справочник bindery - это «плоская», или одноуровневая база данных, разработанная для поддержки одного сервера. В ней также использовалось понятие «объект» для сетевого ресурса, но трактовка этого термина отличалась от общепринятой. Объекты bindery идентифицировались простыми числовыми значениями и имели определенные атрибуты. Однако для этих объектов не определялись явные взаимоотношения наследования классов объектов, поэтому взаимоотношения между объектами bindery устанавливались администратором произвольно, что часто приводило к нарушению целостности данных.
База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.
Служба NDS - это значительный шаг вперед по сравнению с предыдущими версиями за счет:
Распределенность заключается в том, что информация не хранится на одном сервере, а разделена на части, называемые разделами (partitions). NetWare хранит эти разделы на нескольких серверах сети (рис. 10.8). Это свойство значительно упрощает администрирование и управление большой сетью, так как она представляется администратору единой системой. Кроме того, обеспечивается более быстрый доступ к базе данных сетевых ресурсов за счет обращения к ближайшему серверу.
Рис. 10.8. Разделы базы данных NDS
Реплика - это копия информации раздела NDS. Можно создать неограниченное количество реплик каждого раздела и хранить их на разных серверах. Если один сервер останавливается, то копии этой информации могут быть получены с другого сервера. Это увеличивает отказоустойчивость системы, так как ни один из серверов не отвечает за всю информацию базы данных NDS.
Прозрачность заключается в том, что NDS автоматически создает связи между программными и аппаратными компонентами, которые обеспечивают пользователю доступ к сетевым ресурсам. NDS при этом не требует от пользователя знаний физического расположения этих ресурсов. Задавая сетевой ресурс по имени, вы получите к нему корректный доступ даже в случае изменения его сетевого адреса или места расположения.
Глобальность NDS заключается в том, что после входа вы получаете доступ к ресурсам всей сети, а не только одного сервера, как было в предыдущих версиях. Это достигается за счет процедуры глобального логического входа (global login). Вместо входа в отдельный сервер пользователь NDS входит в сеть, после чего он получает доступ к разрешенным для него ресурсам сети. Информация, предоставляемая во время логического входа, используется для идентификации пользователя. Позже, при попытке пользователя получить доступ к ресурсам, таким как серверы, тома или принтеры, фоновый процесс идентификации проверяет, имеет ли пользователь право на данный ресурс.
Network file system (NFS)
- протокол сетевого доступа к файловым системам, позволяет подключать удалённые файловые системы.
Первоначально разработан Sun Microsystems в 1984 г. Основой является Sun RPC: вызов удаленной процедуры (Remote Procedure Call). NFS независим от типов файловых систем сервера и клиента. Существует множество реализаций NFS-серверов и клиентов для различных ОС. В настоящее время используется версия NFS v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Благодаря этому любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без изменений самой программы.
NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.
Версии
NFSv1 была только для внутреннего пользования в экспериментальных целях. Детали реализации определены в RFC 1094.
NFSv2 (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP.
NFSv3 (RFC 1813, июнь 1995 года). Описатели файлов в версии 2 - это массив фиксированного размера - 32 байта. В версии 3 - это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счётчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, UNIX, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
Версия 2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в версии 3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
Размеры файлов и начальное смещение в байтах для процедур READ и WRITE стали использовать 64-битную адресацию вместо 32-битной, что позволяет работать с файлами большего размера.
Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты.
Записи (WRITE) могут быть асинхронными, тогда как в версии 2 они должны были быть синхронными.
Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).
На момент введения версии 3, разработчики стали больше использовать TCP как транспортный протокол. Хотя некоторые разработчики уже Использовали протокол TCP для NFSv2, Sun Microsystems добавили поддержку TCP в NFS версии 3. Это сделало использование NFS через Интернет более осуществимым.
NFSv4 (RFC 3010, декабрь 2000 г., RFC 3530, пересмотренная в апреле 2003), под влиянием AFS и CIFS, включила в себя улучшение производительности, высокую безопасность, и предстала полноценным протоколом. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF), после того, как Sun Microsystems передала развитие протоколов NFS. NFS версии v4.1 была одобрена IESG в январе 2010 года, и получила номер RFC 5661. Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые "облачные" ("cloud") хранилища и информационные системы.
Общий доступ в смешанной сети
Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется с большинством версий этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. Использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным.
Стандарты
RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
RFC 2224 NFS URL Scheme
RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
RFC 2624 NFS Version 4 Design Considerations
RFC 3010 NFS version 4 Protocol
RFC 3530 Network File System (NFS) version 4 Protocol
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol
Используемые источники
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com
1.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 имеет отличия в реализации.
Некоторые клиенты NFS проводят кэширование на стороне клиента, храня данные на дисках, что напоминает кэширование в CIFS. Также некоторые клиенты NFS меняют значение тайм-аутов в зависимости от времени отклика сервера. Чем медленнее отзывается сервер, тем больше значение тайм-аута, и наоборот.
Файловая система NFS проектировалась, как независящая от транспорта и изначально использовала транспортный протокол UDP. Различные типы NFS могут использовать протокол TCP и другие протоколы.
1.4.1 Сетевая файловая система, версия 3
Файловая система NFS 3 позволяет увеличить быстродействие, особенно для больших файлов, разрешая клиенту и серверу динамически выбирать максимальный объем данных, которые передаются в одном логическом элементе пакета при записи или чтении. В файловой системе NFS 2 на размер пакета накладывалось ограничение в 8 Кбайт. Другими словами, клиент мог отправить максимум 8 Кбайт в запросе на запись, а сервер - максимум 8 Кбайт в ответе на запрос чтения. Кроме того, в NFS 3 переопределены смещения в файлах и размеры данных. Теперь это 64-разрядные значения, вместо 32-разрядных в NFS 2.
Далее представлены некоторые особенности NFS 3.
■ В дескрипторах файлов в NFS 3 указан переменный размер; их максимальных размер составляет 64 бит.
■ Файловая система NFS 3 позволяет клиентам и серверам выбирать максимальный размер имен файлов и каталогов.
■ В NFS 3 определяется список ошибок, которые сервер может возвращать клиентам. Сервер должен вернуть одну из определенных ошибок или не возвращать ошибку вообще.
■ В NFS 3 серверу разрешено кэшировать данные, которые клиент отправил вместе с запросом на запись. Сервер может кэшировать данные и отправлять клиенту ответ на запрос еще до того, как данные будут записаны на диск. Также добавлена команда COMMIT, которая позволяет клиенту убедиться, что все отправленные данные были записаны на диск. Это дает возможность соблюсти баланс между повышением производительности и сохранением целостности данных.
■ В NFS 3 сокращено количество операций запрос/ответ между клиентом и сервером. Для этого данные об атрибутах файла отправляются вместе с первоначальным запросом. В NFS 2 от клиента требовалось получение имен файлов и дескриптора для каждого файла, только после этого передавались атрибуты файла.
1.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. Также поддерживается выбор совместного использования файла с другими клиентами или эксклюзивный доступ к файлу.
1.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. Если временные метки пакетов старше, чем полученные сервером ранее, сервер игнорирует полученные пакеты
1.5 Проблемы доступа при использовании нескольких протоколов
Несколько компаний стали предлагать системы, в которых одновременно реализована поддержка CIFS, NFS и других клиентов сетевых файловых систем. Поставщики проделали немалую работу, пытаясь преодолеть технические проблемы, которые возникают из-за потенциального использования клиентами различных операционных и файловых систем. Обратите внимание, что проблемы возникают не с самими данными, а с метаданными файлов. Простым тестом на наличие подобных проблем будет копирование фай¬ла с сервера на клиент и обратно на сервер (или наоборот). После размещения файла в первоначальном ресурсе метаданные должны содержать базовые значения, т.е. права доступа к файлу и временные метки не должны измениться. Если это не соответствует истине, то проблема обнаружена.
Далее представлены примеры некоторых возможных технических проблем.
■ В различных операционных системах используются разные методы для отслеживания разрешений доступа пользователей и групп.
■ В различных операционных и файловых системах существует разная семантика открытия и блокировки файлов.
■ Соглашения по именованию файлов обрабатываются разными способами. Различные файловые системы по-разному представляют максимальный размер имени файла, значение регистра в имени файла и набор символов, допустимый в именах.
■ Данные и их структура различаются в различных файловых системах; например, одни файловые системы отслеживают две временные метки, в то время как другие - три метки (время последнего доступа к файлу, последней модификации и создания файла). Даже если обе файловые системы отслеживают две временные метки, единицы измерения могут отличаться. Еще одним примером служат единицы измерения смещений в файлах. В некоторых файловых системах поддерживаются 32-разрядные смещения, а в некоторых - 16- или 64-разрядные.
■ Проблемы с адресацией отображаемых блокировок. Сервер CIFS принудительно поддерживает блокировку: если один клиент заблокировал область файла, то любая операция записи в эту область файла со стороны другого клиента приведет к возникновению ошибки. Однако принудительная блокировка не поддерживается серверами NFS. Поэтому необходимо выбрать, будет ли блокировка поддерживаться принудительно, что приведет к отправке сообщения об ошибке клиенту NFS.
#image.jpgНеплохого времени, читатели и гости моего блога. Очень большой перерыв меж постами был, но я снова в бою). В сегодняшней статье рассмотрю работу протокола NFS , а так же настройку сервера NFS и клиента NFS на Linux .
NFS (Network File System - сетевая файловая система) по моему мнению - идеальное решение в локальной сети, где нужен быстрый (более быстрый по сравнению с SAMBA и менее ресурсоемкий по сравнению с удаленными файловыми системами с шифрованием - sshfs, SFTP, etc...) обмен данными и во главе угла не стоит безопасность передаваемой инфы. Протокол NFS позволяет монтировать удалённые файловые системы через сеть в локальное дерево каталогов, как если бы это была примонтирована дисковая файловая система.
Тем локальные приложения могут работать с удаленной файловой системой, как с локальной. Но нужно быть осторожным (!) с настройкой NFS , ибо при определенной конфигурации можно подвесить операционную систему клиента в ожидании бесконечного ввода/вывода.
Протокол NFS основан на работе протокола RPC , который пока не поддается моему пониманию)) поэтому материал в статье будет малость расплывчат... Прежде, чем Вы сможете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет поддержку файловой системы NFS. Проверить поддерживает ли ядро файловую систему NFS можно, просмотрев наличие соответствующих строк в файле /proc/filesystems:
ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd
Если обозначенных строк в файле /proc/filesystems не окажется, то необходимо установить описанные ниже пакеты. Это скорее всего дозволит установить зависимые модули ядра для поддержки подходящих файловых систем.
Если после установки пакетов, поддержка NFS не будет отображена в обозначенном файле, то необходимо будет перекомпилировать ядро, с включением данной функции.
Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории Четыре версии. NFSv1 была разработана в Одна тыща девятьсот восемьдесят девять и являлась экспериментальной, работала на протоколе UDP. Версия Один описана в RFC 1094.
NFSv2 была выпущена в том же Одна тыща девятьсот восемьдесят девять г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при всем этом позволяла читать наименее 2Гб из файла. NFSv3 доработана в Одна тыща девятьсот девяносто 5 г. и описана в RFC 1813.
Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большущего размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в Две тыщи г. и описана в RFC 3010, в Две тыщи три г. пересмотрена и описана в RFC 3530.
4-ая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (а конкретно, Kerberos и LIPKEY с внедрением протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в Две тыщи 10 г., и получила номер RFC 5661.
Принципным нововведением версии 4.1, является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в образце сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.
Так как у нас NFS - это сетевая файловая система, то необходимо настроить сеть в Linux. (Так же можно почитать статью главные понятия сетей). Далее необходимо установить соответствующий пакет. В Debian это пакет nfs-kernel-server и nfs-common, в RedHat это пакет nfs-utils.
А так же, необходимо разрешить запуск беса на подходящих уровнях выполнения (команда в RedHat - /sbin/chkconfig nfs on, в Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults).
Установленные пакеты в Debian запускается в следующем порядке:
ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx Один root root 20 Окт Восемнадцать 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx Один root root 20 семь Окт 20 два 01:23 S16nfs-kernel-server -> ../init.d/nfs-kernel-server
Другими словами, сначала запускается nfs-common , позже сам сервер nfs-kernel-server .
В RedHat ситуация схожая, за тем только исключением, что 1-ый скрипт называется nfslock , а сервер называется просто nfs . Про nfs-common нам сайт debian дословно говорит следующее: общие файлы для клиента и сервера NFS, этот пакет нужно устанавливать на машину, которая будет работать в качестве клиента или сервера NFS.
В пакет включены программы: lockd, statd, showmount, nfsstat, gssd и idmapd. Просмотрев содержимое скрипта запуска /etc/init.d/nfs-common можно отследить следующую последовательность работы: скрипт проверяет наличие исполняемого бинарного файла /sbin/rpc.statd, проверяет наличие в файлах /etc/default/nfs-common, /etc/fstab и /etc/exports черт, требующих запуск бесов idmapd и gssd , запускает демона /sbin/rpc.statd , далее перед запуском /usr/sbin/rpc.idmapd и /usr/sbin/rpc.gssd проверяет наличие этих исполняемых бинарных файлов, далее для беса /usr/sbin/rpc.idmapd проверяет наличие модулей ядра sunrpc, nfs и nfsd, а так же поддержку файловой системы rpc_pipefs в ядре (другими словами наличие ее в файле /proc/filesystems), если все удачно, то запускает /usr/sbin/rpc.idmapd . Дополнительно, для беса /usr/sbin/rpc.gssd проверяет модуль ядра rpcsec_gss_krb5 и запускает бес.
Если просмотреть содержимое скрипта запуска NFS-сервера на Debian (/etc/init.d/nfs-kernel-server), то можно проследить следующую последовательность: при старте, скрипт проверяет существование файла /etc/exports, наличие модуля ядра nfsd, наличие поддержки файловой системы NFS в ядре Linux (другими словами в файле /proc/filesystems), если все на месте, то запускается бес /usr/sbin/rpc.nfsd , далее проверяет задан ли параметр NEED_SVCGSSD (задается в файле опций сервера /etc/default/nfs-kernel-server) и, если задан - запускает беса /usr/sbin/rpc.svcgssd , последним запускает беса /usr/sbin/rpc.mountd . Из данного скрипта видно, что работа сервера NFS состоит из бесов rpc.nfsd, rpc.mountd и если употребляется Kerberos-аутентификация, то и бес rcp.svcgssd. В краснойшляпе еще запускается бес rpc.rquotad и nfslogd (В Debian я почему-то не нашел инфы об этом демоне и о причинах его отсутствия, видимо удален...).
Из этого становиться понятно, что сервер Network File System состоит из следующих процессов (читай - бесов) , расположенных в каталогах /sbin и /usr/sbin:
В NFSv4 при использовании Kerberos дополнительно запускаются бесы:
Не считая обозначенных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind ). Данный пакет обычно устанавливается автоматом с NFS как зависимый и реализует работу сервера RPС, другими словами отвечает за динамическое назначение портов для некоторых служб, зарегистрированных в RPC сервере.
Дословно, согласно документации - это сервер, который преобразует номера программ RPC (Remote Procedure Call) в номера портов TCP/UDP. portmap оперирует несколькими сущностями: RPC-вызовами или запросами, TCP/UDP портами, версией протокола (tcp или udp), номерами программ и версиями программ. Бес portmap запускается скриптом /etc/init.d/portmap до старта NFS-сервисов.
Коротко говоря, работа сервера RPC (Remote Procedure Call) заключается в обработке RPC-вызовов (т.н. RPC-процедур) от локальных и удаленных процессов.
Используя RPC-вызовы, сервисы регистрируют или убирают себя в/из преобразователя портов (он же отображатель портов, он же portmap, он же portmapper, он же, в новых версиях, rpcbind), а клиенты с помощью RPC-вызовов направляя запросы к portmapper получают подходящую информацию. Юзер-френдли наименования сервисов программ и соответствующие им номера определены в файле /etc/rpc.
Как какой-либо сервис отправил соответствующий запрос и зарегистрировал себя на сервере RPC в отображателе портов, RPC-сервер присваивает сопоставляет сервису TCP и UDP порты на которых запустился сервис и хранит в себе ядре соответствующюю информацию о работающем сервисе (о имени), уникальном номере сервиса (в согласовании с /etc/rpc) , о протоколе и порте на котором работает сервис и о версии сервиса и предоставляет обозначенную информацию клиентам по запросу. Сам преобразователь портов имеет номер программы (100000), номер версии - 2, TCP порт 100 одиннадцать и UDP порт 111.
Выше, при указании состава бесов сервера NFS я указал главные RPC номера программ. Я, наверняка, малость запутал Вас данным абзацем, поэтому произнесу основную фразу, которая должна внести ясность: основная функция отображателя портов заключается в том, чтобы по запросу клиента, который предоставил номер RPC-программы (или RPC-номер программы) и версию, вернуть ему (клиенту) порт, на котором работает запрошенная программа . Соответственно, если клиенту нужно обратиться к RPC с определенным номером программы, он сначала должен войти в контакт с процессом portmap на серверной машине и отыскать номер порта связи с необходимым ему обслуживанием RPC.
Работу RPC-сервера можно представить следующими шагами:
Для получения инфы от RPC-сервера употребляется утилита rpcinfo. При указании черт -p host программа выводит список всех зарегистрированных RPC программ на хосте host. Без указания хоста программа выведет сервисы на localhost. Пример:
ARCHIV ~ # rpcinfo -p прог-ма верс прото порт 100 тыщ Два tcp 100 одиннадцать portmapper 100 тыщ Два udp 100 одиннадцать portmapper 100 тыщ 20 четыре Один udp 50 девять тыщ четыреста 50 один status 100 тыщ 20 четыре Один tcp Шестьдесят тыщ восемьсот 70 два status 100 тыщ 20 один Один udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Три udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Четыре udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Один tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Три tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Четыре tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ три Два tcp Две тыщи 40 девять nfs 100 тыщ три Три tcp Две тыщи 40 девять nfs 100 тыщ три Четыре tcp Две тыщи 40 девять nfs 100 тыщ три Два udp Две тыщи 40 девять nfs 100 тыщ три Три udp Две тыщи 40 девять nfs 100 тыщ три Четыре udp Две тыщи 40 девять nfs 100 тыщ 5 Один udp 50 одна тыща триста 6 mountd 100 тыщ 5 Один tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Два udp 50 одна тыща триста 6 mountd 100 тыщ 5 Два tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Три udp 50 одна тыща триста 6 mountd 100 тыщ 5 Три tcp 40 одна тыща четыреста 5 mountd
Как видно, rpcinfo указывает (в столбиках слева на право) номер зарегистрированной программы, версию, протокол, порт и название.
С помощью rpcinfo можно удалить регистрацию программы или получить информацию об отдельном сервисе RPC (больше опций в man rpcinfo). Как видно, зарегистрированы бесы portmapper версии Два на udp и tcp портах, rpc.statd версии Один на udp и tcp портах, NFS lock manager версий 1,3,4, бес nfs сервера версии 2,3,4, а так же бес монтирования версий 1,2,3.
NFS сервер (точнее бес rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт Две тыщи 40 девять жестко закреплен за NFS в большинстве реализаций.
Процесс монтирования удаленной файловой системы NFS можно представить следующей схемой:
Обыденный доступ к удаленной файловой системе можно описать следующей схемой:
Настройка сервера в целом заключается в задании локальных каталогов, разрешенных для монтирования удаленными системами в файле /etc/exports. Это действие называется экспорт иерархии каталогов . Основными источниками инфы об экспортированных каталогах служат следующие файлы:
Прим: вообще, в интернете куча трактовок и формулировок назначения файлов xtab, etab, rmtab, кому верить - не знаю #image.jpg Даже на http://nfs.sourceforge.net/ трактовка не однозначна.
В ординарном случае, файл /etc/exports является единственным файлом, требующим редактирования для функции NFS-сервера. Данный файл управляет следующими свойствами:
Неважно какая строка файла exports имеет следующий формат:
точка_экспорта клиент1(функции) [клиент2(функции) ...]
Где точка_экспорта абсолютный путь экспортируемой иерархии каталогов, клиент1 - n имя 1-го или более клиентов или Ip-адресов, разбитые пробелами, которым разрешено монтировать точку_экспорта . Функции обрисовывают правила монтирования для клиента, обозначенного перед опциями.
Вот обыденный пример конфигурации файла exports:
ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)
В данном примере компьютерам files и 10.0.0.1 разрешен доступ к точке экспорта /archiv1, при всем этом, хосту files на чтение/запись, а для хоста 10.0.0.1 и подсети 10.0.230.1/24 доступ только на чтение.
В файле exports употребляются следующие общие функции (сначала указаны функции применяемые по-умолчанию в большинстве систем, в скобках - не по-умолчанию):
Экспорт символических ссылок и файлов устройств. При экспорте иерархии каталогов, содержащих символические ссылки, необходимо, чтобы объект ссылки был доступен клиентской (удаленной) системе, другими словами должно выполняться одно из следующих правил:
Файл устройства относится к интерфейсу ядра Linux. При экспорте файла устройства экспортируется этот интерфейс. Если клиентская система не имеет устройства такого же типа, то экспортированное устройство не будет работать.
В клиентской системе, при монтировании NFS объектов можно использовать опцию nodev, чтобы файлы устройств в монтируемых каталогах не использовались.
Функции по умолчанию в разных системах могут различаться, их можно посмотреть в файле /var/lib/nfs/etab. После описания экспортированного каталога в /etc/exports и перезапуска сервера NFS все недостающие функции (читай: функции по-умолчанию) будут отражены в файле /var/lib/nfs/etab.
Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей Управление пользователями Linux. Каждый пользователь Linux имеет свои UID и главный GID, которые описаны в файлах /etc/passwd и /etc/group.
Сервер NFS считает, что операционная система удаленного узла выполнила проверку подлинности юзеров и назначила им корректные идентификаторы UID и GID. Экспортирование файлов дает пользователям системы клиента такой же доступ к этим файлам, как если бы они регистрировались напрямую на сервере. Соответственно, когда клиент NFS посылает запрос серверу, сервер употребляет UID и GID для идентификации пользователя в локальной системе, что может приводить к некоторым проблемам:
Следующие функции задают правила отображения удаленных юзеров в локальных:
Пример использования файла маппинга юзеров:
ARCHIV ~ # cat /etc/file_maps_users # Маппинг юзеров # remote local comment uid 0-50 Одна тыща два # сопоставление юзеров с удаленным UID 0-50 к локальному UID Одна тыща два gid 0-50 Одна тыща два # сопоставление юзеров с/span удаленным GID 0-50 к локальному GID 1002
Управление сервером NFS осуществляется с помощью следующих утилит:
Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов. Функции команды можно посмотреть в man nfsstat.
Утилита showmount запрашивает бес rpc.mountd на удалённом хосте о смонтированных файловых системах. По умолчанию выдаётся отсортированный список клиентов. Ключи:
При запуске showmount без аргументов, на консоль будет выведена информация о системах, которым разрешено монтировать локальные сборники. Например, хост ARCHIV нам предоставляет список экспортированных каталогов с IP адресами хостов, которым разрешено монтировать обозначенные сборники:
FILES ~ # showmount --exports archiv Export list for archiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2
Если указать в аргументе имя хоста/IP, то будет выведена информация о данном хосте:
ARCHIV ~ # showmount files clnt_create: RPC: Program not registered # данное сообщение говорит нам, что на хосте FILES бес NFSd не запущен
Данная команда обслуживает экспортированные сборники, данные в файле /etc/exports , точнее будет написать не обслуживает, а синхронизирует с файлом /var/lib/nfs/xtab и удаляет из xtab несуществующие. exportfs делается при запуске беса nfsd с аргументом -r. Утилита exportfs в режиме ядра 2.6 говорит с бесом rpc.mountd через файлы каталога /var/lib/nfs/ и не говорит с ядром напрямую. Без черт выдаёт список текущих экспортируемых файловых систем.
Свойства exportfs:
До того как обратиться к файлу на удалённой файловой системе клиент ( клиента) должен смонтировать её и получить от сервера указатель на неё . Монтирование NFS может производиться с помощью команды mount или с помощью 1-го из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Процесс монтирования отлично продемонстрирована выше на иллюстрации.
На клиентах NFS никаких бесов запускать не нужно, функции клиента делает модуль ядра kernel/fs/nfs/nfs.ko, который используется при монтировании удаленной файловой системы. Экспортированные сборники с сервера могут устанавливаться на клиенте следующими способами:
3-ий способ с autofs в данной статье я рассматривать не буду, ввиду его большой инфы. Может быть в следующих статьях будет отдельное описание.
Пример использования команды mount представлен в посте Команды управления блочными устройствами. Тут я рассмотрю пример команды mount для монтирования файловой системы NFS:
FILES ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ....... archiv:/archiv-small on /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)
1-ая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (другими словами для чтения и записи).
Хотя команда mount в последних дистрибутивах умеет обдумывать какой тип файловой системы употребляется и без указания типа, все же указывать параметр -t nfs лучше. 2-ая команда монтирует экспортированный каталог /archiv-big на сервере archiv в локальный каталог /archivs/archiv-big с опцией только для чтения (ro). Команда mount без черт наглядно указывает нам результат монтирования. Не считая функции только чтения (ro), может быть задать другие главные функции при монтировании NFS :
Атрибуты файлов , хранящиеся в inod (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются изредка для обыденных файлов и еще реже - для каталогов. Многи программы, например ls, обращаются к файлам только для чтения и не меняют атрибуты файлов или содержимое, но затрачивают ресурсы системы на дорогостоящие сетевые операции.
Чтобы избежать ненужных издержек ресурсов, можно кэшировать данные атрибуты . Ядро употребляет время модификации файла, чтобы отыскать устарел ли кэш, сравнивая время модификации в кэше и время модификации самого файла. Кэш атрибутов периодически обновляется в согласовании с данными параметрами:
Следующие функции управляют действиями NFS при отсутствии ответа от сервера или в случае возникновения ошибок ввода/вывода:
Описание файла /etc/fstab я затрагивал в соответствующей статье. В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций:
FILES ~ # cat /etc/fstab | grep nfs archiv:/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 Нуль Нуль nfs-server:/archiv-big /archivs/archiv-big nfs rw,timeo=50,hard,fg Нуль 0
1-ый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw).
Хост archiv подключен по быстрому локальному каналу, поэтому для роста производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS.
2-ой пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 10-х толикой сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не вышло зависания.
До того как сохранять конфигурации в /etc/fstab, обязательно попробуйте смонтировать вручную и убедитесь, что всё работает!!!
На производительность NFS могут влиять несколько черт, в особенности при работе через медленные соединения. При работе с медленными и высоконагруженными соединениями, лучше использовать параметр hard, чтобы таймауты не привели к прекращению работы программ. Но необходимо обдумывать, что если смонтировать файловую систему через NFS с параметром hard через fstab, а удаленный хост окажется недоступен, то при загрузке системы произойдет зависание.
Так же, одним из самых легких способов роста производительности NFS - увеличение количества байтов, передаваемых за один раз. Размер в Четыре тыщи девяносто 6 б очень мал для современных быстрых соединений, увеличивая это значение до Восемь тыщ 100 девяносто два и более можно экспериментальным способом найти наилучшую скорость.
Так же, не стоит упускать из внимания и функции тайм-аутов . NFS ожидает ответа на пересылку данных в течении промежутка времени, обозначенного в функции timeo, если ответ за это время не получен, то делается повторная пересылка.
Но на загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в конечном итоге чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после неответа в течении Семьсот мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до большего значения в Шестьдесят сек. Далее зависимо от параметра hard/soft произойдет какое-либо действие (см.выше).
Подобрать наилучший timeo для определенного значения передаваемого пакета (значений rsize/wsize), можно с помощью команды ping:
FILES ~ # ping -s 30 две тыщи семьсот шестьдесят восемь archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data. 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0.958 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archiv.DOMAIN.local ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms
Как видно, при отправке пакета размером 30 две тыщи семьсот шестьдесят восемь (32Kb) время его путешествия от клиента до сервера и вспять плавает в районе Один миллисекунды. Если данное время будет зашкаливать за Двести мс, то стоит задуматься о повышении значения timeo, чтобы оно превышало значение обмена в три-четыре раза. Соответственно, данный тест лучше делать во время сильной загрузки сети
Заметка скопипсчена с блога http://bog.pp.ru/work/NFS.html, за что ему большущее спасибо!!!
Запуск сервера NFS, монтирования, блокировки, квотирования и статуса с "правильными" портами (для сетевого экрана)
Если вы желаете сделать ваш разделённый NFS каталог открытым и с правом записи, вы можете использовать опцию all_squash в композиции с опциями anonuid и anongid. Например, чтобы установить права для пользователя "nobody" в группе "nobody", вы можете сделать следующее:
ARCHIV ~ # cat /etc/exports # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99)) # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))
Это также означает, что если вы желаете разрешить доступ к обозначенной директории, nobody.nobody должен быть владельцем разделённой директории:
# chown -R nobody.nobody /files
На клиенте необходимо примонтировать удаленный каталогудобным способом, например командой mount:
FILES ~ # mount -t nfs archiv:/files /archivs/files
Резюме
Фух... Статья завершена. На данный момент мы изучили что такое Network File System и с чем ее едят, в следующей статье попробую сделать HOWTO с аутентификацией Kerberos. Надеюсь материал вышел доходчивым и нужным.
Буду рад Вашим дополнениям и комментариям!
NFS HOWTO, nfs.sourceforge, man nfs? man mount, man exports
RFC Одна тыща девяносто четыре - NFSv1, v2
RFC Одна тыща восемьсот тринадцать - NFSv3
RFC Три тыщи 500 30 - NFSv4
RFC 5 тыщ 600 шестьдесят один - NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
man exports
