Рис. 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-сервера является обеспечение достаточной полосы пропускания и степени готовности сети. Это требование на практике трансформируется в необходимость создания конфигурации с соответствующим количеством и типом сетей и интерфейсов.

    Сетевая среда, определяемая профилем приложения

Как отмечалось ранее, наиболее важным фактором, определяющим выбор конфигурации сети, является доминирующий тип операций NFS, используемых приложениями. Для приложений с интенсивной нагрузкой по данным требуется относительно небольшое количество сетей, но эти сети должны иметь большую полосу пропускания, как например, в сетях FDDI или CDDI. Эти требования могут удовлетворяться также с помощью сетей 100baseT (Ethernet 100 Мбит/с) или ATM (Asynchronous Transfer Mode 155 Мбит/с). Большинство интенсивных по атрибутам приложений работают и при наличии менее дорогой инфраструктуры, хотя может потребоваться большое количество сетей.

Принять решение по выбору типа сети сравнительно просто. Если для работы индивидуального клиента требуется агрегатированная скорость передачи данных, превышающая 1 Мбайт/с, или если для одновременной работы нескольких клиентов необходима полоса пропускания сети, превышающая 1 Мбайт/с, то такие приложения требуют применения высокоскоростных сетей. Реально эта цифра (1 Мбайт/с) искусственно завышена, поскольку она характеризует скорость передачи данных, которую вы гарантируете не превышать. Обычно более разумно рассматривать скорость сети Ethernet равной примерно 440 Кбайт/с, а не 1 Мбайт/с. (Обычно пользователи воспринимают Ethernet как "неотвечающую" уже примерно при 35% загрузке сети. Приведенная здесь цифра 440 Кбайт/с соответствует 35%-ной загрузке линии с пропускной способностью 1. 25 Мбайт/с).

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

Использование высокоскоростных сетей для предотвращения перегрузки Высокоскоростные сети наиболее полезны для обслуживания больших групп клиентов с интенсивной нагрузкой по данным скорее из-за более низкой стоимости инфраструктуры, а не по причине обеспечения максимальной пропускной способности при взаимодействии одной системы с другой. Причиной этого является текущее состояние протокола NFS, который в настоящее время работает с блоками данных длиной 8 Кбайт и обеспечивает предварительную выборку только 8 Кбайт (т. е. в одной операции с сервером можно определить максимально 16 Кбайт данных). Общий эффект такой организации проявляется в том, что максимальная скорость передачи данных между клиентом и сервером, которые взаимодействуют через кольцо FDDI, составляет примерно 2. 7 Мбайт/с. (Эта скорость достигается только при добавлении в файл /etc/system на клиенте оператора set nfs: nfs_async_threads = 16. Клиенты SunOS 4. 1. x должны запускать 12 демонов biod, а не 8, как это делается по умолчанию). Эта скорость всего в три раза превосходит максимальную скорость, которую обеспечивает Ethernet несмотря на то, что скорость среды FDDI в десять раз больше. (NFS представляет собой протокол прикладного уровня (уровня 7 в модели OSI). Протоколы более низких уровней, такие как TCP и UDP могут работать с гораздо более высокими скоростями, используя те же самые аппаратные средства. Большая часть времени тратится на ожидание ответов и другую обработку прикладного уровня. Другие протоколы прикладного уровня, которые не рассчитаны на немедленное получение ответа и/или подтверждения, также могут эффективно использовать значительно более высокую скорость среды). Пиковая скорость при использовании 16 Мбит/с Token Ring составляет примерно 1. 4 Мбайт/с. Сравнительно недавно была анонсирована новая версия протокола NFS+, которая устраняет этот недостаток, разрешая работу с блоками значительно больших размеров. NFS+ допускает пересылку блоков данных почти произвольных размеров. Клиент и сервер договариваются о максимальном размере блока при каждом монтировании файловой системы. При этом размер блока может увеличиваться до 4 Гбайт.

Главное преимущество 100-Мбитных сетей при работе с обычными версиями NFS заключается в том, что эти сети могут поддерживать много одновременных передач данных без деградации. Когда сервер пересылает по Ethernet данные клиенту со скоростью 1 Мбайт/с, то такая передача потребляет 100% доступной полосы пропускания сети. Попытки передачи по этой сети большего объема данных приводят к более низкой пропускной способности для всех пользователей. Те же самые клиент и сервер могут осуществлять пересылки данных со скоростью 2. 7 Мбайт/с по кольцу FDDI, но в более высокоскоростной сети эта транзакция потребляет только 21% доступной полосы пропускания. Сеть может поддерживать пять или шесть пересылок одновременно без серьезной деградации.

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

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