Деревянко_БС ЭВМ

2.2.5. Репликация

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

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

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

Прозрачность репликации

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

Прозрачность репликации зависит от двух факторов: используемой схемы именования реплик и степени вовлеченности пользователя в управление репликацией.

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

111

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

данных, а какие еще не обновлены.

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

При явной репликации пользователь создает файл с явным указанием сервера, на котором он размещается (первая реплика), а затем создается несколько реплик, причем для каждой реплики сервер также указывается явно.

При неявной репликации (implicit replication) выбор ко-

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

112

Согласование реплик

Существует несколько способов обеспечения согласованности реплик.

Чтение любой — запись во все. При записи в файл все реплики блокируются, затем выполняется запись в каждую копию, после чего блокировка снимается и файл становится доступным для чтения. Чтение может выполняться из любой копии (семантика в стиле UNIX). Недостаток - запись не всегда возможна, так как серверы, хранящие реплики файла, могут в момент записи быть неработоспособными.

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

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

Кворум. Этот метод обобщает подходы, реализованные в предыдущих методах.

113

2.3.Примеры сетевых файловых служб: FTP и NFS

2.3.1.Протокол передачи файлов FTP

Сетевая файловая служба на основе протокола FTP (File Transfer Protocol) представляет собой одну из наиболее ранних служб, используемых для доступа к удаленным файлам. Первые спецификации FTP относятся к 1971 году. Серверы и клиенты FTP имеются практически в каждой ОС семейства UNIX, а также во многих других сетевых ОС. Клиенты FTP встроены сегодня в браузеры Интернета.

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

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

Клиент и сервер FTP поддерживают параллельно два сеанса — управляющий сеанс и сеанс передачи данных. Управляющий сеанс открывается при установлении первоначального FTP-соединения клиента с сервером, причем в течение одного управляющего сеанса может последовательно выполняться несколько сеансов передачи данных, в рамках которых передаются или принимаются несколько файлов.

Общая схема взаимодействия клиента и сервера выглядит следующим образом.

1. Сервер FTP всегда открывает управляющий порт TCP 21 для прослушивания, ожидая приход запроса на установление управляющего сеанса FTP от клиента.

114

2.После установления управляющего соединения клиент отправляет на сервер команды, которые уточняют параметры соединения.

3.После согласования параметров пассивный участник соединения переходит в режим ожидания открытия соединения на порт передачи данных. Активный участник инициирует это соединение и начинает передачу данных.

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

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

Протокол FTP использует при взаимодействии клиента

ссервером несколько команд (не следует их путать с командами пользовательского интерфейса клиента, которые использует человек).

Эти команды делятся на три группы: команды управления доступом к системе, команды управления потоком данных, команды службы FTP.

В набор команд управления доступом входят следующие команды:

USER — доставляет серверу имя клиента. Эта команда открывает управляющий сеанс и может также передаваться при открытом управляющем сеансе для смены имени пользователя.

PASS — передает в открытом виде пароль пользователя.

CWD — изменяет текущий каталог на сервере.

REIN — повторно инициализирует управляющий сеанс.

QUIT — завершает управляющий сеанс.

115

Команды управления потоком устанавливают параметры передачи данных:

PORT — определяет адрес и порт хоста, который будет активным участником соединения. Например, команда PORT 194,85,135.126,7,205 назначает активным участником хост 194.85.135.126 и порт 1997 (вычисление номера порта не тривиально, но вполне однозначно);

PASV — назначает хост пассивным участником соединения по передаче данных. В ответ на эту команду должна быть передана команда PORT с указанием адреса и порта, находящегося в режиме ожидания;

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

Служба FTP может применяться для работы как со структурированными файлами, разделенными на записи или страницы, так и с неструктурированными.

Команды службы FTP инициируют действия по передаче файлов или просмотру удаленного каталога:

RETR — запрашивает передачу файла от сервера на клиентский хост. Параметрами команды является имя файла. Может быть задано также смещение от начала файла — это позволяет начать передачу файла с определенного места при непредвиденном разрыве соединения (этот параметр используется в команде reget пользовательского интерфейса).

STOR — инициирует передачу файла от клиента на сервер. Параметры аналогичны команде RETR.

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

116

Каждая команда протокола FTP передается в текстовом виде по одной команде в строке. Строка заканчивается симво-

лами CR и LF ASCII-кода.

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

Имеется также облегченная версия протокола FTP, которая не требует идентификации и использует UDP-протокол вместо TCP. Это протокол TFTP (тривиальный протокол передачи файлов). Он используется в первую очередь для удаленной загрузки.

Чтобы компьютер мог загрузить ОС по сети необходимо, чтобы его сетевая карточка содержала Boot-ROM (ПЗУ удаленной загрузки). При этом должны быть известны IPадреса клиента и сервера. Сетевой карте в момент загрузки известен только ее аппаратный адрес. Поэтому необходим сервер, который сможет выделить клиенту IP-адрес и сообщить адрес сервера, с которого можно взять ядро и имя файла на этом сервере. Для этого можно использовать либо протокол BOOTP, либо протокол DHCP, являющийся расширением BOOTP. DHCP поможет также снабдить IP-адресами рабочие станции Windows и ноутбуки, подключаемые к сети.

2.3.2. Файловая система NFS

Файловая система NFS (Network File System) создана компанией Sun Microsystems. Это стандартная сетевая файловая система для ОС семейства UNIX, кроме того, клиенты и серверы NFS реализованы для многих других ОС.

NFS использует модель удаленного доступа к файлам. Работа с удаленными файлами после монтирования становится достаточно простой — поддерево файловой системы сервера NFS становится поддеревом локальной файловой системы.

Одной из целей разработчиков NFS была поддержка неоднородных систем с клиентами и серверами, работающими

117

под управлением различных ОС на различной аппаратной платформе. Этой цели способствует реализация NFS на основе механизма Sun RPC, поддерживающего по умолчанию средства XDR для унифицированного представления аргументов удаленных процедур.

Для обеспечения устойчивости клиентов к отказам серверов в NFS принят подход stateless.

Основная идея NFS — позволить группе пользователей совместно использовать общую файловую систему. Можно работать с NFS и в локальной, и в глобальной сети. Каждый NFS-сервер предоставляет свои каталоги для доступа удаленным клиентам. Каталог объявляется доступным со всеми своими подкаталогами. Список каталогов, которые сервер передает, содержится в файле /etc/exports, так что эти каталоги экспортируются сразу автоматически при загрузке сервера. Клиенты получают доступ к экспортируемым каталогам путем монтирования. Выполнение программ почти не зависит от того, где расположен файл: локально или на удаленном диске. Если два или более клиента одновременно смонтировали один и тот же каталог, то они могут связываться путем разделения файла.

В своей работе файловая система NFS использует два протокола.

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

Монтирование может выполняться автоматически при загрузке ОС или первом открытии удаленного файла.

Второй NFS-протокол используется для доступа к уда-

118

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

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

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

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

Репликация в NFS не поддерживается.

119

2.4.Служба каталогов

2.4.1.Назначение и принципы организации

службы каталогов

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

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

Результатом развития систем хранения справочной информации стало появление в сетевых операционных системах специальной службы – службы каталогов (Directory Services),

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

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

120