Только  в середине 80-х годов появилось несколько распределенных файловых систем, которые обеспечили прозрачный доступ по сети к удаленным файлам. Это были Network File System (NFS) компании Sun Microsystems (1985), Remote File Sharing system (RFS) компании AT&T (1986) и Andrew File System (AFS) университета Карнеги-Меллона (1995). Эти три системы резко отличались друг от друга по целям разработки, архитектуре и семантике, хотя все они пытались решить одну и ту же фундаментальную проблему. Сегодня RFS доступна практически на всех системах, базирующихся на UNIX System V. Разработка ASF перешла корпорации Transarc, в которой она была развита и превращена в Distributed File System (DFS) - компонент распределенной вычислительной среды DSE (Distributed Computing Environment) Open Software Foundation. Но наибольшее распространение получила NFS, которая поддерживается на всех UNIX и многих "не UNIX" системах. Созданная в 1986 году фирмой AT&T одновременно с ОС UNIX System V Release 3, система RFS (Remote File Sharing) представляет собой средство, предназначенное для управления распределенными файлами. Назначение системы - обеспечить прозрачное разделение дисковых ресурсов и периферийных устройств между машинами UNIX, объединенными в локальную сеть.

      Компания Sun Microsystems представила NFS в 1985 году как средство обеспечения прозрачного доступа к удаленным файловым системам. Помимо публикации протокола Sun лицензировала его базовую реализацию, которая была использована различными поставщиками для портирования NFS на разные операционные системы. С тех пор NFS стала фактически промышленным стандартом, который поддерживается действительно всеми вариантами системы UNIX, а также некоторыми другими системами, например, VMS и MS-DOS.

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

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

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

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

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

• Сетевая прозрачность - Клиенты должны иметь возможность обращаться к удаленным файлам пользуясь теми же самыми операциями, что и для доступа к локальным файлам.
• Прозрачность размещения - Имя файла не должно определять его местоположения в сети.
• Независимость размещения - Имя файла не должно меняться при изменении его физического меторасположения.
• Мобильность пользователя - Пользователи должны иметь возможность обращаться к разделяемым файлам из любого узла сети.
• Устойчивость к сбоям - Система должна продолжать функционировать при неисправности отдельного компонента (сервера или сегмента сети). Однако это может приводить к деградации производительности или к исключению доступа к некоторой части файловой системы.
• Масштабируемость - Система должна обладать возможностью масштабирования в случае увеличения нагрузки. Кроме того, должна существовать возможность постепенного наращивания системы путем добавления отдельных компонентов.
• Мобильность файлов - Должна быть возможность перемещения файлов из одного месторасположения в другое на работающей системе.
• Имеется несколько важных вопросов, которые рассматриваются при разработке распределенных файловых систем. Они касаются функциональных возможностей, семантики и производительности системы. Различные файловые системы можно сравнивать между собой, выясняя как они решают эти вопросы:
• Пространство имен - Некоторые распределенные файловые системы обеспечивают однородное пространство имен такое, что каждый клиент использует одно и то же путевое имя для доступа к данному файлу. Другие системы позволяют клиенту создавать свое пространство имен путем монтирования разделяемых поддеревьев к произвольным каталогам в иерархии файлов. Оба метода имеют свою привлекательность.
• Операции с сохранением и без сохранения состояний - Сервер сохраняющий состояния обеспечивает хранение информации об операциях клиента между запросами и использует эту информацию о состоянии для корректного обслуживания последующих запросов. Такие запросы как open или seek связаны с изменением состояний, так как кто-то должен запомнить информацию о том, какие файлы открыл клиент, а также все смещения в открытых файлах. В системе без сохранения состояний каждый запрос является "самодостаточным" и сервер не поддерживает устойчивых состояний о клиентах. Например, вместо того, чтобы поддерживать информацию о смещении в открытом файле сервер может требовать от клиента указания смещения в каждой операции чтения или записи. Серверы с сохранением состояний работают быстрее, поскольку они могут использовать знания о состоянии клиента для существенного уменьшения сетевого трафика. Однако они должны иметь и целый комплекс механизмов поддержания согласованного состояния системы и восстановления после ее отказа. Серверы без сохранения состояний более просты в разработке и реализации, но не дают такой высокой производительности.
• Семантика разделения - Распределенная файловая система должна определить семантику, которая применяется когда несколько клиентов одновременно обращаются к одному файлу. Семантика UNIX требует, чтобы все изменения, сделанные одним клиентом, были бы видны другим клиентам, когда они выдают следующий системный вызов read или write. Некоторые файловые системы обеспечивают "семантику сессии" (session semantics), при которой изменения становятся доступными другим клиентам на основе гранулированности системных вызовов open и close. А некоторые системы дают даже еще более слабые гарантии, например, интервал времени, который должен пройти прежде, чем изменения наверняка попадут к другим клиентам.
• Методы удаленного доступа - В простой модели клиент-сервер используется метод удаленного обслуживания, при котором каждое действие инициируется клиентом, а сервер просто представляет собой агента, который выполняет заявки клиента. Во многих распределенных системах, особенно в системах, сохраняющих состояние, сервер играет гораздо более активную роль. Он не только обслуживает запросы клиентов, но и участвует в работе механизма обеспечения когерентности, уведомляя клиентов о всех случаях, когда кэшированные в нем данные становятся недостоверными.

3. Сравнительный анализ разных способов реализации файловых серверов

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

1. Серверная операционная система  семейства Майкрософт. Протоколы SMB, CIFS, FTP.
2. Unix подобная операционная система. Протоколы SMB, CIFS, FTP.

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

      Критерии, указывающие отличительные черты  от Windows:

1. Безопасность.
2. Гибкость.
3. Управление функциями.
4. Философия.
5. Стоимость.
6. Скорость.
7. Эффективность.
8. Надежность.
9. Работоспособность и подбор прикладного программного обеспечения.
10. Подверженность (чувствительность) к червям и вирусам.
11. Открытость и скорость разрешения известных дефектов (ошибок).
12. Кластеризация.
13. Многопользовательский режим.
14. Отсутствие графического пользовательского интерфейса GUI или HTTP браузера, как части операционной системы.

 

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

2. Реализация  файлового сервера  на операционной системе  Debian GNU Linux

      Установка дебиан.

      Для установки proftpd, в терминале вводится команда: apt-get install proftpd. При установке proftpd в Debian скрипт установщика самостоятельно создает директории, конфигурационный файл proftpd.conf и добавит запуск сервера в скрипты автоматической загрузки ОС.

      Для удобства доступа, выберем следующую  конфигурацию файлового сервера.

• чтобы каждый пользователь системы при авторизации на ftp попадал в свою директорию
• создать пользователя для анонимного доступа (например для доступа на чтение к какой-то определенной папке)

      Стандартный файл конфигурации пакета proftpd находится /etc/proftpd/, изменяется стандартным текстовым редактором, результат в приложении 1. В эту часть входит и авторизация пользователя в своем домашнем каталоге.

      Т.к. в конфигурации мы запускаем сервер proftpd через ined сервер, то идем в файл /etc/inetd.conf и раскомментируем строку и перезапустим inetd

ftp   stream  tcp  nowait  root  /usr/sbin/tcpd proftpd

Перезапускаем демон inetd

killall -HUP inetd

      Далее создается с именем anonymous. Почему именно с таким? Да потому что, теперь можно в программах клиентах ftp указывать только имя сервера без указания имени пользователя. По умолчанию в таком случае подставится имя anonymous. Пароль для данного пользователя можно задать, а можно и не задавать. А можно сделать совсем просто. В конфигурации proftpd.conf прописать alias пользователя anonymous на любого другого пользователя системы. Мы бы советовали прописать на пользователя ftp, т.к. он уже создан. 

UserAlias anonymous ftp

      Создаём директорию /home/ftp и назначаем права на неё для пользователя ftp. Если задаете пароль пользователю ftp(тогда anonymous будет с паролем), либо в конфигурации proftpd отключаете требование пароля на данного пользователя. Чтобы задавать различные права на какую-либо директорию в proftpd, для пользователя anonymous, который в данном случае может читать все каталоги в директории /mnt . Результат в приложении 2. 
 
 
 

Заключение

      1-2 стр.

Литература

      Примеры оформления ссылок на источники:

1. Азин А.А. Пример ссылки на книгу в центральных издательствах. – М^*.: Педагогика, 1993. – 176 с.
2. Гришин Г.Г. Пример ссылки на книгу ведомственного издания/ УрГПУ. Екатеринбург, 1996. – 55 с.
3. Мазин М.М. Пример ссылки на статью в журнале// Математика в школе. 1987. № 4. С. 34–38.
4. Программы для общеобразовательных учреждений. Геометрия. – М.: Просвещение. 1997. – 219 с.
5. Разин Р.Р. Пример ссылки на книгу с подзаголовком. Методические рекомендации. С-Пб. Школа-Пресс, 1994. – 234 с.
6. Семенов С.С. Пример ссылки на тезисы доклада на конференции/ Вопросы преподавания математики в школе: Тез. докл. Всеросс. науч.-практ. конф.// Омск. гос. пед. ун-т. Омск, 1998. С. 99.
7. Танина Т.Т. Пример ссылки на автореферат диссертации: Автореф. дис. … д-ра пед. наук. Челябинск, 1994.
8. Яшин Я.Я. Пример ссылки на материалы из Internet// www.uspu.ru/lito

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

^*Примечание: При указании в ссылках названий городов (в качестве места издания) Москва обозначается одной буквой (М.), Санкт-Петербург – С-Пб. Остальные города записываются полностью (Екатеринбург, Лондон). 
Приложения

ServerName                      "Mik FTP"

#ServerType                     standalone  #запуск #сервера в обычном режиме, через команду proftpd

ServerType                      inetd  #запуск через #inetd сервер, предпочитаю запускать через него

DefaultServer                   on 

# Port 21 is the standard FTP port.

Port                            21

PassivePorts                    49152 65534 

# Маска создания новых файлов

Umask                           022 

#количесво попыток авторизации

    MaxLoginAttempts            3

#Максимальное количество пользователей ftp сервера

    MaxClients                  20  "Sorry, max %m users -- try again later" 

  ServerAdmin root@localhost

#приветствие на сервере

  ServerIdent on "Welcome to Mik FTP server"   AllowLogSymlinks off   # не записывать в журнал файлы с #символическими ссылками

  DebugLevel 3

  LogFormat awstats "%t %h      %u      %m      %f      %s      %b"

  ExtendedLog /var/log/xferlog read,write awstats

  SyslogFacility FTP

  SyslogLevel debug

  TransferLog none

  WtmpLog on

  ListOptions "-a" 

#Число одновременных коннектов на сервер. Но данная #переменная работает только

#если у вас сервер запущен в standalone. А так количество #процессов ограничится

#настройками inetd

MaxInstances                    30 

# От какого пользователя будет стартовать сам сервер

User                            ftp

Group                           ftp