Network File System (NFS) - сетевая файловая система. Что необходимо для того, чтобы это работало

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
Структура NFS включает три компонента разного уровня:
Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
Функции уровня представления выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.Подключение сетевых ресурсов
Процедура подключения сетевого ресурса средствами NFS называется "экспортированием". Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.
В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован (присоединён) "только для чтения", можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: "жесткое" (hard) или "мягкое" (soft).
При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS продолжит функционирование.
При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу. Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска.
Выбор режима зависит от ситуации. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более удобным.

Общий доступ в смешанной сети
Сервис 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

Сетевые файловые системы

Одна из наиболее полезных функций, которая может быть реализована с помощью сети, это разделение файлов через сетевую файловую систему. Обычно используется система, называемая Network File System или NFS, которая разработана корпорацией Sun.

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

Почта

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

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

Почтовая система состоит из множества различных программ. Доставка писем к локальным или удаленным почтовым ящикам производится одной программой (например, sendmail или smail), в то время как для обычной отправки или просмотра писем применяется большое количество различных программ (например, Pine или elm).Файлы почтовых ящиков обычно хранятся в каталоге /var/spool/mail.

Вопросы

1. Что такое NOS и каково ее назначение?

2. Какие функции сети выполняет сетевая операционная система?

3. Из каких частей состоит структура NOS?

4. Что такое редиректор?

5. Как подразделяются сетевые операционные системы по правам доступа к ресурсам?

6. Как подразделяются сетевые операционные системы по масштабу сетей?

7. Как зависят свойства сетевой операционной системы от масштаба сетей?

8. Дать характеристику сетевой операционной системы NetWare фирмы Novell.

9. Из каких элементов состоит структура сетевой операционной системы NetWare?

10. Дать характеристику файловой системы сетевой ОС NetWare.

11. Какие уровни протоколов поддерживает сетевая операционная система NetWare?

12. Перечислить функции протоколов IPX, SPX.

13. Дать характеристику сетевой операционной системы Windows NT.

14. Перечислить задачи сетевой операционной системы Windows NT.

15. Из каких элементов состоит структура сетевой операционной системы Windows NT?

16. Дать характеристику файловой системы сетевой ОС Windows NT.

17. Какие принципы защиты используются в сетевой ОС Windows NT?

18. Перечислить особенности сетевой операционной системы Windows NT с точки зрения реализации сетевых средств.

19. Назвать свойства сетевой операционной системы Windows NT.

20. Каковы области использования Windows NT?

21. Дать характеристику сетевой операционной системы UNIX.

22. Перечислить функции сетевой операционной системы UNIX.

23. Дать характеристику файловой системы сетевой ОС UNIX.

24. Какие принципы защиты используются UNIX?

25. Дать обзор сетевой операционной системы Linux.

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

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

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

Сетевая файловая система в общем случае включает следующие элементы :

Локальные файловые системы;

Интерфейсы локальной файловой системы;

Серверы сетевой файловой системы;

Клиенты сетевой файловой системы;

Интерфейсы сетевой файловой системы;

Протокол клиент-сервер сетевой файловой системы.

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

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

В операционных системах Windows основной сетевой файловой службы является протокол SMB (Server Message Block), который был совместно разработан компаниями Microsoft, Intel и IBM. Его последние расширенные версии получили название Common Internet File System, CIFS.

Протокол работает на прикладном уровне модели OSI. Для передачи по сети своих сообщений SMB использует различные транспортные протоколы. Исторически первым таким протоколом был NetBIOS (и его более поздняя версия NetBEUI), но сейчас сообщения SMB могут передаваться и с помощью других протоколов (TCP/UDP и IPX).

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

1. Отказ компьютера, на котором выполняется сервер сетевой файловой системы, во время сеанса связи с клиентом. Локальная ФС запоминает состояние последовательных операций, которые приложение выполняет с одним и тем же файлом, за счет ведения__ внутренней таблицы открытых файлов (системные вызовы open, read, write изменяют состояние этой таблицы). При крахе системы таблица открытых файлов теряется после перезагрузки серверного компьютера. В этом случае приложение, работаю-щее на клиентском компьютере, не может продолжить работу с файлами, открытыми до краха.

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

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

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

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

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

Перечисленные проблемы решаются комплексно путем создания службы центра лизованной аутентификации, репликации, кэширования и др. Эти дополнительные службы находят свое отражение в протоколе взаимодействия клиентов и серверов, в результате чего создаются различные протоколы этого типа, поддерживающие тот или иной набор дополнительных функций. Поэтому для одной и той же локальной ФС могут существовать различные протоколы сетевой ФС (рис. 5.30). Так, к файловой системе NTFS сегодня можно получить доступ с помощью протоколов SMB, NCP (NetWare Control Protocol) и NFS (Network File System - протокол сетевой ФС компании Sun Microsystems, используемой в различных вариантах ОС семейства UNIX).

С другой стороны, с помощью одного и того же протокола может реализоваться удаленный доступ к локальным ФС разного типа. Например, протокол SMB используется для доступа не только к ФС типа FAT, но и ФС NTFS, HPFS (рис. 5.31). Эти ФС могут располагаться как на разных, так и на одном компьютере.__

Контрольные вопросы к главе 5

1. Какими преимуществами обладают сети по сравнению с раздельным использованием компьютеров?

2. Всегда ли совпадают физическая и логическая топологии сети?

3. Как классифицируются сети по величине охватываемой территории?

4. Какой компьютер может выполнять роль сервера в сети?

5. Что такое файловый сервер и сервер печати?

6. Какие функции выполняют регистрационные серверы?

7. Какие функции выполняют серверы удаленного доступа?

8. Что такое прокси-сервер?

9. Перечислите возможных клиентов компьютерной сети.

10. Что такое ≪толстый≫ и ≪тонкий≫ клиенты в компьютерной сети?

11. Как вы понимаете термин ≪сегментация≫ сети?

12. Что такое МАС-адрес?

13. Чем распределенная ОС отличается от сетевой? Существуют ли в настоящее время по-настоящему распределенные сетевые системы?

14. Перечислите основные компоненты сетевой ОС. Что такое сетевая служба? Какие сетевые службы вы можете назвать?

15. Часть сетевых служб направлена не на пользователя, а на администратора. Какие это службы?

16. Что представляли собой первые сетевые ОС? Какие подходы к созданию сетевых ОС используются в настоящее время?

17. Назовите характерные черты одноранговых сетей. В чем основная особенность многоранговой сети?

18. Что такое серверная ОС? Какие они бывают? Чем серверная ОС отличается от клиентской?

19. Сколько вариантов двухзвенных схем используется для распределенной обработки приложений?

20. Чем хороша двухзвенная обработка приложений при сотрудничестве сервера и клиента?

21. Есть ли преимущества у трехзвенной схемы обработки приложений, в чем они заключаются?

22. Как могут взаимодействовать процессы в распределенных системах?

23. Какие основные примитивы используются в транспортной системе сетевой ОС?

24. Как организуется синхронизация процессов в сети?

25. Что понимается под вызовом удаленных процедур?

NFS: удобная и перспективная сетевая файловая система

Сетевая файловая система – это сетевая абстракция поверх обычной файловой системы, позволяющая удаленному клиенту обращаться к ней через сеть так же, как и при доступе к локальным файловым системам. Хотя NFS не является первой сетевой системой, она сегодня развилась до уровня наиболее функциональной и востребованной сетевой файловой системы в UNIX®. NFS позволяет организовать совместный доступ к общей файловой системе для множества пользователей и обеспечить централизацию данных для минимизации дискового пространства, необходимого для их хранения.

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

Краткая история NFS

Первая сетевая файловая система называлась FAL (File Access Listener - обработчик доступа к файлам) и была разработана в 1976 году компанией DEC (Digital Equipment Corporation). Она являлась реализацией протокола DAP (Data Access Protocol – протокол доступа к данным) и входила в пакет протоколов DECnet. Как и в случае с TCP/IP, компания DEC опубликовала спецификации своих сетевых протоколов, включая протокол DAP.

NFS была первой современной сетевой файловой системой, построенной поверх протокола IP. Её прообразом можно считать экспериментальную файловую систему, разработанную в Sun Microsystems в начале 80-х годов. Учитывая популярность этого решения, протокол NFS был представлен в качестве спецификации RFC и впоследствии развился в NFSv2. NFS быстро утвердилась в качестве стандарта благодаря способности взаимодействовать с другими клиентами и серверами.

Впоследствии стандарт был обновлен до версии NFSv3, определенной в RFC 1813. Эта версия протокола была более масштабируема, чем предыдущие, и поддерживала файлы большего размера (более 2 ГБ), асинхронную запись и TCP в качестве транспортного протокола. NFSv3 задала направление развития файловых систем для глобальных (WAN) сетей. В 2000 году в рамках спецификации RFC 3010 (переработанной в версии RFC 3530) NFS была перенесена в корпоративную среду. Sun представила более защищенную NFSv4 c поддержкой сохранения состояния (stateful) (предыдущие версии NFS не поддерживали сохранение состояния, т.е. относились к категории stateless). На текущий момент последней версией NFS является версия 4.1, определенная в RFC 5661, в которой в протокол посредством расширения pNFS была добавлена поддержка параллельного доступа для распределенных серверов.

История развития NFS, включая конкретные RFC, описывающие её версии, показана на рисунке 1.


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

Архитектура NFS

NFS использует стандартную архитектурную модель "клиент-сервер" (как показано на рисунке 2). Сервер отвечает за реализацию файловой системы совместного доступа и хранилища, к которому подключаются клиенты. Клиент реализует пользовательский интерфейс к общей файловой системе, смонтированной внутри локального файлового пространства клиента.

Рисунок 2. Реализация модели "клиент-сервер" в архитектуре NFS

В ОС Linux® виртуальный коммутатор файловой системы (virtual file system switch - VFS) предоставляет средства для одновременной поддержки на одном хосте нескольких файловых систем (например, файловой системы ISO 9660 на CD-ROM и файловой системы ext3fs на локальном жестком диске). Виртуальный коммутатор определяет, к какому накопителю выполняется запрос, и, следовательно, какая файловая система должна использоваться для обработки запроса. Поэтому NFS обладает такой же совместимостью, как и другие файловые системы, применяющиеся в Linux. Единственное отличие NFS состоит в том, что запросы ввода/вывода вместо локальной обработки на хосте могут быть направлены для выполнения в сеть.

VFS определяет, что полученный запрос относится к NFS, и передает его в обработчик NFS, находящийся в ядре. Обработчик NFS обрабатывает запрос ввода/вывода и транслирует его в NFS-процедуру (OPEN , ACCESS , CREATE , READ , CLOSE , REMOVE и т.д.). Эти процедуры, описанные в отдельной спецификации RFC, определяют поведение протокола NFS. Необходимая процедура выбирается в зависимости от запроса и выполняется с помощью технологии RPC (вызов удаленной процедуры). Как можно понять по названию, RPC позволяет осуществлять вызовы процедур между различными системами. RPC-служба соединяет NFS-запрос с его аргументами и отправляет результат на соответствующий удаленный хост, а затем следит за получением и обработкой ответа, чтобы вернуть его инициатору запроса.

Также RPC включает в себя важный уровень XDR (external data representation – независимое представление данных), гарантирующий, что все пользователи NFS для одинаковых типов данных используют один и тот же формат. Когда некая платформа отправляет запрос, используемый ею тип данных может отличаться от типа данных, используемого на хосте, обрабатывающего этот запрос. Технология XDR берет на себя работу по преобразованию типов в стандартное представление (XDR), так что платформы, использующие разные архитектуры, могут взаимодействовать и совместно использовать файловые системы. В XDR определен битовый формат для таких типов, как float , и порядок байтов для таких типов, как массивы постоянной и переменной длины. Хотя XDR в основном известна благодаря применению в NFS, это спецификация может быть полезна во всех случаях, когда приходится работать в одной среде с различными архитектурами.

После того как XDR переведет данные в стандартное представление, запрос передается по сети с помощью определенного транспортного протокола. В ранних реализациях NFS использовался протокол UDP, но сегодня для обеспечения большей надежности применяется протокол TCP.

На стороне NFS-сервера применяется схожий алгоритм. Запрос поднимается по сетевому стеку через уровень RPC/XDR (для преобразования типов данных в соответствии с архитектурой сервера) и попадает в NFS-сервер, который отвечает за обработку запроса. Там запрос передается NFS-демону для определения целевой файловой системы, которой он адресован, а затем снова поступает в VFS для обращения к этой файловой системе на локальном диске. Полностью схема этого процесса приведена на рисунке 3. При этом локальная файловая система сервера – это стандартная для Linux файловая система, например, ext4fs. По сути NFS – это не файловая система в традиционном понимании этого термина, а протокол удаленного доступа к файловым системам.


Для сетей с большим временем ожидания в NFSv4 предлагается специальная составная процедура (compound procedure ). Эта процедура позволяет поместить несколько RPC-вызовов внутрь одного запроса, чтобы минимизировать затраты на передачу запросов по сети. Также в этой процедуре реализован механизм callback-функций для получения ответов.

Протокол NFS

Когда клиент начинает работать с NFS, первым действием выполняется операция mount , которая представляет собой монтирование удаленной файловой системы в пространство локальной файловой системы. Этот процесс начинается с вызова процедуры mount (одной из системных функций Linux), который через VFS перенаправляется в NFS-компонент. Затем с помощью RPC-вызова функции get_port на удаленном сервере определяется номер порта, который будет использоваться для монтирования, и клиент через RPC отправляет запрос на монтирование. Этот запрос на стороне сервера обрабатывается специальным демоном rpc.mountd , отвечающим за протокол монтирования (mount protocol ). Демон проверяет, что запрошенная клиентом файловая система имеется в списке систем, доступных на данном сервере. Если запрошенная система существует и клиент имеет к ней доступ, то в ответе RPC-процедуры mount указывается дескриптор файловой системы. Клиент сохраняет у себя информацию о локальной и удаленной точках монтирования и получает возможность осуществлять запросы ввода/вывода. Протокол монтирования не является безупречным с точки зрения безопасности, поэтому в NFSv4 вместо него используются внутренние RPC-вызовы, которые также могут управлять точками монтирования.

Для считывания файла его необходимо сначала открыть. В RPC нет процедуры OPEN , вместо этого клиент просто проверяет, что указанные файл и каталог существуют в смонтированной файловой системе. Клиент начинает с выполнения RPC-запроса GETATTR к каталогу, в ответ на который возвращаются атрибуты каталога или индикатор, что каталог не существует. Далее, чтобы проверить наличие файла, клиент выполняет RPC-запрос LOOKUP . Если файл существует, для него выполняется RPC-запрос GETATTR , чтобы узнать атрибуты файла. Используя информацию, полученную в результате успешных вызовов LOOKUP и GETATTR , клиент создает дескриптор файла, который предоставляется пользователю для выполнения будущих запросов.

После того как файл идентифицирован в удаленной файловой системе, клиент может выполнять RPC-запросы типа READ . Этот запрос состоит из дескриптора файла, состояния, смещения и количества байт, которое следует считать. Клиент использует состояние (state ), чтобы определить может ли операция быть выполнена в данный момент, т.е. не заблокирован ли файл. Смещение (offset ) указывает, с какой позиции следует начать чтение, а счетчик байт (count ) определяет, сколько байт необходимо считать. В результате RPC-вызова READ сервер не всегда возвращает столько байт, сколько было запрошено, но вместе с возвращаемыми данными всегда передает, сколько байт было отправлено клиенту.

Инновации в NFS

Наибольший интерес представляют две последние версии NFS – 4 и 4.1, на примере которых можно изучить наиболее важные аспекты эволюции технологии NFS.

До появления NFSv4 для выполнения таких задач по управлению файлами, как монтирование, блокировка и т.д. существовали специальные дополнительные протоколы. В NFSv4 процесс управления файлами был упрощен до одного протокола; кроме того, начиная с этой версии UDP больше не используется в качестве транспортного протокола. NFSv4 включает поддержку UNIX и Windows®-семантики доступа к файлам, что позволяет NFS "естественным" способом интегрироваться в другие операционные системы.

В NFSv4.1 для большей масштабируемости и производительности была введена концепция параллельной NFS (parallel NFS - pNFS). Чтобы обеспечить больший уровень масштабируемости, в NFSv4.1 реализована архитектура, в которой данные и метаданные (разметка ) распределяются по устройствам аналогично тому, как это делается в кластерных файловых системах. Как показано на , pNFS разделяет экосистему на три составляющие: клиент, сервер и хранилище. При этом появляются два канала: один для передачи данных, а другой для передачи команд управления. pNFS отделяет данные от описывающих их метаданных, обеспечивая двухканальную архитектуру. Когда клиент хочет получить доступ к файлу, сервер отправляет ему метаданные с "разметкой". В метаданных содержится информация о размещении файла на запоминающих устройствах. Получив эту информацию, клиент может обращаться напрямую к хранилищу без необходимости взаимодействовать с сервером, что способствует повышению масштабируемости и производительности. Когда клиент заканчивает работу с файлом, он подтверждает изменения, внесенные в файл и его "разметку". При необходимости сервер может запросить у клиента метаданные с разметкой.

С появлением pNFS в протокол NFS было добавлено несколько новых операций для поддержки такого механизма. Метод LayoutGet используется для получения метаданных с сервера, метод LayoutReturn "освобождает" метаданные, "захваченные" клиентом, а метод LayoutCommit загружает "разметку", полученную от клиента, в хранилище, так что она становится доступной другим пользователям. Сервер может отозвать метаданные у клиента с помощью метода LayoutRecall . Метаданные с "разметкой" распределяются между несколькими запоминающими устройствами, чтобы обеспечить параллельный доступ и высокую производительность.


Данные и метаданные хранятся на запоминающих устройствах. Клиенты могут выполнять прямые запросы ввода/вывода на основе полученной разметки, а сервер NFSv4.1 хранит метаданные и управляет ими. Сама по себе эта функциональность и не нова, но в pNFS была добавлена поддержка различных методов доступа к запоминающим устройствам. Сегодня pNFS поддерживает использование блочных протоколов (Fibre Channel), объектных протоколов и собственно NFS (даже не в pNFS-форме).

Развитие NFS продолжается, и в сентябре 2010 года были опубликованы требования к NFSv4.2. Некоторые из нововведений связаны с наблюдающейся миграцией технологий хранения данных в сторону виртуализации. Например, в виртуальных средах с гипервизором весьма вероятно возникновение дублирования данных (несколько ОС выполняют чтение/запись и кэширование одних и тех же данных). В связи с этим желательно, чтобы система хранения данных в целом понимала, где происходит дублирование. Такой подход поможет сэкономить пространство в кэше клиента и общую емкость системы хранения. В NFSv4.2 для решения этой проблемы предлагается использовать "карту блоков, находящихся в совместном доступе" (block map of shared blocks). Поскольку современные системы хранения все чаще оснащаются собственными внутренними вычислительными мощностями, вводится копирование на стороне сервера, позволяющее снизить нагрузку при копировании данных во внутренней сети, когда это можно эффективно делать на самом запоминающем устройстве. Другие инновации включают в себя субфайловое кэширование для флэш-памяти и рекомендации по настройке ввода-вывода на стороне клиента (например, с использованием mapadvise).

Альтернативы NFS

Хотя NFS – самая популярная сетевая файловая система в UNIX и Linux, кроме нее существуют и другие сетевые файловые системы. На платформе Windows® чаще всего применяется SMB, также известная как CIFS ; при этом ОС Windows также поддерживает NFS, равно как и Linux поддерживает SMB.

Одна из новейших распределенных файловых систем, поддерживаемых в Linux - Ceph - изначально спроектирована как отказоустойчивая POSIX-совместимая файловая система. Дополнительную информацию о Ceph можно найти в разделе .

Стоит также упомянуть файловые системы OpenAFS (Open Source-версия распределенной файловой системы Andrew, разработанной в университете Карнеги-Меллона и корпорации IBM), GlusterFS (распределенная файловая система общего назначения для организации масштабируемых хранилищ данных) и Lustre (сетевая файловая система с массовым параллелизмом для кластерных решений). Все эти системы с открытым исходным кодом можно использовать для построения распределенных хранилищ.

Заключение

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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ВОЗДУШНОГО ТРАНСПОРТА

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ

ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ГРАЖДАНСКОЙ АВИАЦИИ»

____________________________________________________________________________________________________________________

Кафедра вычислительных машин, комплексов, систем и сетей

СЕТЕВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ.

СЕТЕВЫЕ ФАЙЛОВЫЕ СИСТЕМЫ

И СЛУЖБА КАТАЛОГОВ

Утверждено Редакционно-

издательским Советом МГТУ ГА

Москва - 2010

ББК 32.973.202-018.2я73-1+32.973.26-018.2я73-1

Печатается по решению редакционно-издательского совета

Московского государственного технического университета ГА

Рецензенты: канд. физ.-мат. наук, доц. ;

Ч48 Сетевые операционные системы. Сетевые файловые системы и служба каталогов: Учебное пособие. - М.: МГТУ ГА, 2010. –68 с. 10 ил., лит.: 4 наим.

Данное учебное пособие издается в соответствии с рабочей программой учебной дисциплины «Сетевые операционные системы» по Учебному плану специальности 230101 для студентов IV курса дневного обучения.

Рассмотрено и одобрено на заседаниях кафедры 11.05.10 г. и методического совета 14.05.10 г.

-038 ББК 32.973.202-018.2я73-1+32.973.26-018.2я73-1

Ц33(03)-10 Св. тем. план 2010 г.

ЧЕРКАСОВА Наталья Ивановна

СЕТЕВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ.
СЕТЕВЫЕ ФАЙЛОВЫЕ СИСТЕМЫ И СЛУЖБА КАТАЛОГОВ
Учебное пособие

Редактор

Подписано в печать 11.10.10 г.

Печать офсетная Формат 60х84/16 4,0 уч.-изд. л.

3,95 усл. печ. л. Заказ № 000/ Тираж 100 экз.

Московский государственный технический университет ГА

125993 Москва, Кронштадтский бульвар, д. 20

Редакционно-издательский отдел

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_ADBLOCK212">

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

Сетевые компоненты 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_ADBLOCK215">

Протокол 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.

Статьи по теме: