Курсовая работа: Основы конфигурирования сетевых файловых систем (на примере NFS)

Например, в протоколе NFS отсутствуют запросы по открыванию и закрыванию файлов, поскольку они создали бы информацию о состоянии, которая должна запоминаться сервером. По этой же причине, запросы read и write передают в качестве параметра начальное смещение, в отличие от операций read и write с локальными файлами, которые получают смещение из объекта "открытый файл".

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

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

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

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

Общие сведения о работе и нагрузке NFS

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

Ниже в таблице 3.1 представлены 18 операций NFS. Шесть из них являются основными и представляют громадное большинство реально выполняемых операций как по количеству, так и по потреблению ресурсов: getattr, setattr, lookup, readlink, read и write. Эти операции реализуют поиск и модификацию атрибутов файла, поиск имени файла, разрешение символических связей, а также чтение и запись данных соответственно. Можно явно выделить два принципиально разных набора операций: в частности, операции read и write манипулируют действительным содержимым файла, в то время как другие операции манипулируют атрибутами файлов. Отличия между этими наборами операций определяются прежде всего типом нагрузки, которая ложится при выполнении соответствующего запроса на серверные и сетевые ресурсы системы.

Таблица 4.1. Операции NFS

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

Операции с атрибутами

Операции с атрибутами создают для системы намного меньшую нагрузку, чем операции с данными. Поскольку размер атрибутов файла очень мал (пара сотен байтов на файл), большинство атрибутов файловой системы, связанных с активными файлами, будет буферизоваться (кэшироваться) в основной памяти сервера. Даже если атрибуты файла не кэшируются, они просто отыскиваются и читаются с диска. После того как атрибуты файла выбраны сервером для какого-либо клиента, обслуживание любого запроса к этим атрибутам заключается лишь в манипулировании битами кэшированных атрибутов и выполнении обычного сетевого протокола. Накладные расходы, связанные с сетевой обработкой этих операций сравнительно высоки, поскольку относительное количество полезных байтов данных в реально передаваемом пакете невелико. Атрибуты пересылаются небольшими пакетами (большинство имеют размер 64-128 байт). В результате операции с атрибутами потребляют относительно небольшую полосу пропускания сети.

Операции с данными

В отличие от операций с атрибутами, операции с данными по определению имеют размер 8 Кбайт. (Это размер блока данных, определенный NFS. Сравнительно недавно анонсированная версия протокола NFS+ допускает блоки данных размером до 4 Гбайт. Однако это существенно не меняет саму природу операций с данными). Кроме того, в то время как для каждого файла имеется только один набор атрибутов, количество блоков данных размером по 8 Кбайт в одном файле может быть большим (потенциально может достигать несколько миллионов). Для большинства типов NFS-серверов блоки данных обычно не кэшируются и, таким образом, обслуживание соответствующих запросов связано с существенным потреблением ресурсов системы. В частности, для выполнения операций с данными требуется значительно большая полоса пропускания сети: каждая операция с данными включает пересылку шести больших пакетов по Ethernet (двух по FDDI). В результате вероятность перегрузки сети представляет собой гораздо более важный фактор при рассмотрении операций с данными.

Как это ни удивительно, но в большинстве существующих систем доминируют операции с атрибутами, а не операции с данными. Если клиентская система NFS хочет использовать файл, хранящийся на удаленном файл-сервере, она выдает последовательность операций поиска (lookup) для определения размещения файла в удаленной иерархии каталогов, за которой следует операция getattr для получения маски прав доступа и других атрибутов файла; наконец, операция чтения извлекает первые 8 Кбайт данных. Для типичного файла, который находится на глубине четырех или пяти уровней подкаталогов удаленной иерархии, простое открывание файла требует пяти-шести операций NFS. Поскольку большинство файлов достаточно короткие (в среднем для большинства систем менее 16 Кбайт) для чтения всего файла требуется меньше операций, чем для его поиска и открывания. Последние исследования компании Sun обнаружили, что со времен операционной системы BSD 4.1 средний размер файла существенно увеличился от примерно 1 Кбайт до немногим более 8 Кбайт.

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

Сравнение приложений с разными наборами операций NFS

В общем случае приложения, обращающиеся к множеству небольших файлов, могут характеризоваться как выполняющие интенсивные операции над атрибутами. Возможно наилучшим примером такого приложения является классическая система разработки программного обеспечения. Большие программные системы обычно состоят из тысяч небольших модулей. Каждый модуль обычно содержит файл включения (include file), файл исходного кода, объектный файл и некоторый тип файла управления архивом (подобный SCCS или RCS). Большинство файлов имеют небольшой размер, часто в пределах от 4 до 100 Кбайт. Поскольку обычно во время обслуживания транзакции NFS запросчик блокируется, время обработки в таких приложениях определяется скоростью обработки сервером легковесных запросов атрибутов. В общем числе операций операции над данными занимают менее 40%. В большинстве серверов с очень интенсивным выполнением операций с атрибутами требуется только умеренная пропускная способность сети: пропускная способность сети Ethernet (10 Мбит/с) обычно является адекватной.

Большинство серверов домашних каталогов (home directory) попадают в категорию интенсивного выполнения операций с атрибутами: большинство хранимых файлов небольшие. Кроме того, что эти файлы имеют небольшой размер по сравнению с размером атрибутов, они дают также возможность клиентской системе кэшировать данные файла, устраняя необходимость их повторного восстановления с сервера.

Приложения, работающие с очень большими файлами, попадают в категорию интенсивного выполнения операций с данными. К этой категории относятся, например, приложения из области геофизики, обработки изображений и электронных САПР. В этих приложениях обычный сценарий использования NFS рабочими станциями или вычислительными машинами включает: чтение очень большого файла, достаточно длительную обработку этого файла (минуты или даже часы) и, наконец, обратную запись меньшего по размерам файла результата. Файлы в этих прикладных областях часто достигают размера 1 Гбайт, а файлы размером более 200 Мбайт являются скорее правилом, чем исключением. При обработке больших файлов доминируют операции, связанные с обслуживанием запросов данных. Для приложений с интенсивным выполнением операций с данными наличие достаточной полосы пропускания сети всегда критично.

Например, считается, что скорость передачи данных в среде Ethernet составляет 10 Мбит/с. Такая скорость кажется достаточно высокой, однако 10 Мбит/с составляет всего 1.25 Мбайт/с, и даже эта скорость на практике не может быть достигнута из-за накладных расходов протокола обмена и ограниченной скорости обработки на каждой из взаимодействующих систем. В результате реальная предельная скорость Ethernet составляет примерно 1 Мбайт/с. Но даже эта скорость достижима только почти в идеальных условиях - при предоставлении всей полосы пропускания Ethernet для передачи данных только между двумя системами. К несчастью такая организация оказывается малопрактичной, хотя в действительности нередко случается, что только небольшое число клиентов сети запрашивают данные одновременно. При наличии множества активных клиентов максимальная загрузка сети составляет примерно 35%, что соответствует агрегатированной скорости передачи данных 440 Кбайт/с. Сама природа такого типа клиентов, характеризующихся интенсивным выполнением операций с данными, определяет процесс планирования конфигурации системы. Она обычно определяет выбор cетевой среды и часто диктует тип предполагаемого сервера. Во многих случаях освоение приложений с интенсивным выполнением операций с данными вызывает необходимость перепрокладки сетей.

В общем случае считается, что в среде с интенсивным выполнением операций с данными, примерно более половины операций NFS связаны с пересылкой пользовательских данных. В качестве представителя среды с интенсивным выполнением операций с атрибутами обычно берется классическая смесь Legato, в которой 22% всех операций составляют операции чтения (read) и 15% - операции записи (write).

Характер рабочей нагрузки NFS

Если бы клиенты NFS постоянно выполняли запросы к серверам (или сетям), то в конфигурацию системы пришлось бы включить огромное число выделенных сетей Ethernet или большое число высокоскоростных сетей типа FDDI или FastEthernet. К счастью, обычно трафик NFS имеет достаточно взрывной характер. Клиенты могут выполнять интенсивные запросы к файл-серверам или сетям, но периоды такой интенсивной работы возникают довольно случайно и относительно не очень часто.

"Полностью активные" клиенты

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

Типовой пример использования NFS

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

Рис. 4.2. Журнал трафика NFS в Sun Net Manager для клиента на базе 486/33 PC,
использующего Lotus 1-2-3

Страницы: 1, 2, 3, 4, 5, 6