Основы конфигурирования сетевых файловых систем (на примере NFS) (стр. 5 из 12)

Клиент NFS

Взаимодействие с системой виртуальной памяти

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

Рис. 4.5. Взаимодействие между приложением, файловой системой виртуальной памяти и NFS

Работа механизмов кэширования системы виртуальной памяти задерживает, а иногда и полностью отменяет работу NFS. Например, рассмотрим бездисковую рабочую станцию, выполняющую 1-2-3. Если и данные, и двоичные коды приложения размещаются удаленно, система должна будет, как и требуется, загрузить в страницы памяти выполняемые двоичные коды 1-2-3 с помощью NFS. Затем с помощью NFS в память будут загружены данные. Для большинства файлов 1-2-3 на типично сконфигурированной рабочей станции данные будут кэшироваться в памяти и оставаться там в течение значительного времени (скорее минуты, а не секунды). Если открывается и остается открытым временный файл, то само открытие файла выполняется немедленно как на клиенте, так и на сервере, но все обновления содержимого файла обычно кэшируются на некоторое время в клиенте перед передачей на сервер. В соответствии с семантикой UNIX-файла, когда файл закрывается все изменения должны быть записаны на внешнее запоминающее устройство, в данном случае на сервер NFS. В альтернативном варианте кэшированные записи могут записываться на внешнее запоминающее устройство с помощью демонов fsflush (Solaris 2.x) или udpated (Solaris 1.x). Как и в случае обычного дискового ввода/вывода, кэшированные данные ввода/вывода NFS остаются в памяти до тех пор, пока память не потребуется для каких-либо других целей.

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

Файловая система с репликацией данных (CFS)

Начиная с версии Solaris 2.3 Sun предлагает новую возможность, называемую файловой системой с репликацией данных или кэширующей файловой системой (CFS - Cashed File System). В соответствии со стандартным протоколом NFS файлы выбираются блок за блоком прямо с сервера в память клиента и все манипуляции с ними происходят прямо в этой памяти. Данные записываются обратно на диск сервера. Программное обеспечение CFS располагается между кодом клиента NFS и методами доступа сервера NFS. Когда блоки данных получены кодом клиента NFS, они кэшируются в выделенной области на локальном диске. Локальная копия называется файлом переднего плана (front file), а копия сервера - файлом заднего плана (back file). Любое последующее обращение к кэшированному файлу выполняется к его копии на локальном диске, а не к копии, находящейся на сервере. По очевидным причинам такая организация может существенно уменьшить нагрузку на сервер.

К сожалению, CFS - это не исчерпывающее средство для снижения нагрузки на сервер. Во-первых, поскольку она действительно создает копии блоков данных, система должна обеспечивать определенные мероприятия для поддержания согласованного состояния этих копий. В частности, подсистема CFS периодически проверяет атрибуты файла заднего плана (периодичность такой проверки устанавливается пользователем). Если файл заднего плана был модифицирован, файл переднего плана вычищается из кэша и последующее обращение к (логическому) файлу приведет к тому, что он заново будет выбран с сервера и кэширован. К сожалению, большинство прикладных программ продолжают работать с целым файлом, а не с определенными блоками данных. Например, программы vi, 1-2-3 и ProEngineer читают и записывают свои файлы данных целиком, независимо от действительных целей пользователя. (Вообще говоря, программы, использующие для доступа к файлам команду mmap(2), не обращаются к файлу в целом, в то время как, программы, использующие команды read(2) и write(2), обычно это делают). Как следствие, CFS обычно кэширует весь файл. В результате файловые системы NFS, подвергающиеся частым изменениям, оказываются не очень хорошими кандидатами для CFS: файлы будут постоянно кэшироваться и очищаться, что в конце концов приводит к увеличению общего сетевого трафика, по сравнению с простой работой через NFS.

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

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

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

Конфигурирование NFS-сервера

Исходные предпосылки

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

Является ли нагрузка интенсивной по атрибутам или интенсивной по данным?
Будут ли клиенты пользоваться кэширующей файловой системой для сокращения числа запросов?
Сколько в среднем будет полностью активных клиентов?
Какие типы клиентских систем предполагается использовать и под управлением каких операционных систем они работают?
Насколько большие файловые системы предполагается использовать в режиме разделения доступа?
Повторяются ли запросы разных клиентов к одним и тем же файлам (например, к файлам include), или они относятся к разным файлам?
Каковы количество и тип предполагаемых для эксплуатации сетей? Является ли существующая конфигурация сети подходящей для соответствующего типа трафика?
Достаточно ли в предполагаемой конфигурации сервера количество ЦП для управления трафиком, связанным с применяемыми сетями?
Если используются территориальные сети (WAN), имеют ли среда передачи данных и маршрутизаторы достаточно малую задержку и высокую пропускную способность, чтобы обеспечить практичность применения NFS?
Достаточно ли дисковых накопителей и главных адаптеров SCSI для достижения заданной производительности?
Требуется ли применение программных средств типа Online:DiskSuit для адекватного распределения нагрузки по доступу к дискам между всеми доступными дисковыми накопителями?
Если часто используются операции записи NFS, то имеются ли в конфигурации системы NVSIMM?
Соответствует ли предполагаемая стратегия резервного копирования типу, числу и размещению на шине SCSI устройств резервного копирования?

Конфигурация сети (локальной и глобальной)

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