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

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

Распределение нагрузки по доступу к дискам с помощью программного обеспечения типа Online:DiskSuit

Одной из общих проблем серверов NFS является плохая балансировка нагрузки между дисковыми накопителями и дисковыми контроллерами. Например, для поддержки некоторого числа бездисковых клиентов часто используется конфигурация системы с тремя дисками. Первый диск содержит операционную систему сервера и двоичные коды приложений; второй диск - файловые системы root и swap для всех бездисковых клиентов, а третий диск - домашние каталоги пользователей бездисковых клиентов. Такая конфигурация сбалансирована скорее по логическому принципу, а не по реальной физической нагрузке на диски. В такой среде диск, хранящий область подкачки (swap) для бездисковых клиентов, обычно оказывается намного более загруженным, чем любой из двух других дисков: этот диск почти все время будет загружен на 100%, а другие два в среднем на 5%. Подобные принципы распределения часто применяются также и для работы в другой среде.

Для обеспечения прозрачного распределения доступа по нескольким дисковым накопителям с успехом можно использовать функции расщепления и/или зеркалирования, которые поддерживаются специальным программным обеспечением типа Online:DiskSuit. (Конкатенация дисков достигает минимальной степени балансировки нагрузки, но только когда диски являются относительно полными). В среде с интенсивным использованием данных расщепление с небольшим перекрытием обеспечивает увеличение пропускной способности дисков, а также распределение нагрузки обслуживания. Расщепление дисков существенно улучшает также производительность операций последовательного чтения и записи. Хорошим начальным приближением для определения величины перекрытия является отношение 64 Кбайт/число дисков в полосе. В среде с интенсивным использованием атрибутов, для которых характерен произвольный доступ, установленное по умолчанию перекрытие (один цилиндр диска) является наиболее подходящим.

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

В настоящее время в компьютерной промышленности рекомендуется максимальная степень загрузки каждого дискового накопителя на уровне 60-65%. (Степень загрузки диска можно выяснить с помощью команды iostat(1)). Обычно на практике не удается заранее спланировать распределение данных так, чтобы обеспечить этот рекомендованный уровень загрузки дисков. Для этого необходимо выполнить несколько итераций, которые включают съем статистики и соответствующую реорганизацию данных. Более того, следует отметить, что типовое распределение нагрузки на диски со временем меняется, причем иногда радикально. Поэтому распределение данных, которое обеспечивало даже очень хорошую работу системы во время инсталляции, может давать очень слабые результаты год спустя. При оптимизации распределения данных на существующем наборе дисковых накопителей имеется множество других соображений второго порядка.

Использование оптимальных зон диска

Многие диски, которые сегодня поставляются компаниями-поставщиками компьютеров, пользуются механизмами кодирования, которые получили название "записи битовых зон - zone bit recording"). Этот тип кодирования позволяет использовать геометрические свойства вращающегося диска упаковывать больше данных на тех частях поверхности диска, которые находятся дальше от его центра. Практический эффект заключается в том, что количество адресов с меньшими номерами (которые соответствуют внешним цилиндрам диска) превосходят количество адресов с большими номерами. Обычно это в пределе составляет 50%. Такой способ кодирования в большей степени сказывается на производительности последовательного доступа к данным (например, для диска 2.1 Гбайт указывается диапазон скоростей передачи данных 3.5-5.1 Мбайт/с), но он также сказывается на производительности произвольного доступа к диску. Данные, расположенные на внешних цилиндрах диска, не только проходят быстрее под головками чтения/записи (поэтому и скорость передачи данных выше), но эти цилиндры также просто больше по размеру. Заданное количество данных можно распределить по меньшему числу больших цилиндров, что приведет к меньшему числу механических перемещений каретки.

Заключительные рекомендации по конфигурированию дисков

Основные правила по конфигурированию дисков можно обобщить следующим образом:

• В среде с интенсивным использованием данных следует конфигурировать от 3 до 5 полностью активных 2.9 Гбайт дисков на каждый главный адаптер fast/wide SCSI. Необходимо предусматривать по крайней мере 3 дисковых накопителя на каждого активного клиента при использовании сети FDDI, или один дисковод для каждого активного клиента в сетях Ethernet или Token Ring.
• В среде с интенсивным использованием атрибутов следует конфигурировать примерно по 4-5 полностью активных 1.05 Гбайт или 535 Мбайт дисков на каждый главный адаптер SCSI. Необходимо предусматривать по крайней мере один дисковод для каждых двух полностью активных клиентов (в любой сетевой среде).
• К каждому главному адаптеру могут подключаться дополнительные накопители без существенной деградации производительности до тех пор, пока количество обычно активных накопителей на шине SCSI не превысит указаний, приведенных выше.
• Для распределения нагрузки доступа по многим дискам можно рекомендовать использование программного обеспечения типа Online:DiskSuit 2.0.
• Если это возможно, следует пользоваться наиболее быстрыми зонами на диске.

Нестандартные требования к памяти

Поскольку во многих UNIX-системах (например, в Solaris) реализовано кэширование файлов в виртуальной памяти, большинство пользователей склонны конфигурировать серверы NFS очень большой подсистемой основной памяти. Однако примеры типичного использования файлов клиентами NFS показывают, что данные восстанавливаются из буферного кэша в действительности относительно редко и дополнительная основная память обычно не обязательна.

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

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

Операции записи не могут использовать все преимущества механизма кэширования UNIX на сервере, поскольку протокол NFS требует, чтобы любая операция записи на удаленный диск выполнялась полностью синхронно, чтобы гарантировать согласованное состояние даже в случае выхода сервера из строя. Операция записи называется синхронной в этом смысле, поскольку логическая операция с диском в целом полностью завершается прежде, чем она будет подтверждена. Хотя данные кэшированы, операции записи NFS не выигрывают от буферизации и откладывания момента записи, которые обычно выполняются при реализации операций записи UNIX. Заметим, что клиент может и обычно выполняет операции записи в кэш точно таким же способом, что и любую другую операцию дискового ввода/вывода. Клиент в любом случае способен контролировать когда результаты операции записи сбрасываются на "диск" независимо от того, является ли диск локальным или удаленным.

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

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

• Если сервер в основном обеспечивает пользовательскими данными многих клиентов, следует конфигурировать относительно минимальную память. Для небольших коллективов обычно ее объем составляет 32 Мбайта, а для больших коллективов - примерно 128 Мбайт. В мультипроцессорных конфигурациях всегда необходимо предусматривать по крайней мере 64 Мбайт на каждый процессор. Приложения с интенсивным использованием атрибутов обычно выигрывают от увеличенного объема памяти несколько больше, чем приложения с интенсивным использованием данных.
• Если на сервере выделяется пространство для хранения временных файлов приложений, которые очень интенсивно работают с этими файлами (хорошим примером является Verilog фирмы Cadence), следует конфигурировать память сервера равной примерно сумме размеров активных временных файлов, используемых на сервере. Например, если размер временного файла клиента составляет примерно 5 Мбайт и предполагается, что сервер будет обслуживать 20 полностью активных клиентов, следует установить (20 клиентов х 5 Мбайт) = 100 Мбайт дополнительной памяти (конечно 128 Мбайт представляет собой наиболее удобную цифру, которую легко конфигурировать). Однако часто этот временный файл может быть размещен в локальном справочнике типа /tmp, что приведет к значительно более высокой производительности клиента, а также к существенному уменьшению сетевого трафика.
• Если главной задачей сервера является хранение только выполняемых файлов, следует конфигурировать память сервера примерно равной суммарному объему интенсивно используемых двоичных файлов. При этом нельзя забывать о библиотеках! Например, сервер предполагающийся для хранения /usr/openwin для некоторого коллектива сотрудников должен иметь достаточно памяти, чтобы кэшировать Xsun, cmdtool, libX11.so, libxwiew.so и libXt.so. Это приложение NFS значительно отличается от более типового сервера тем, что оно все время поставляет одни и те же файлы всем своим клиентам, а потому способно эффективно кэшировать эти данные. Обычно клиенты не используют каждую страницу всех двоичных кодов, а потому разумно в конфигурации сервера предусмотреть только такой объем памяти, которого достаточно для размещения часто используемых программ и библиотек.
• Размер памяти может быть выбран исходя из правила пяти минут: 16 Мбайт для ОС плюс объем памяти для кэширования данных, к которым будут происходить обращения чаще, чем один раз в пять минут.

Поскольку серверы NFS не выполняют пользовательских процессов, большого пространства подкачки (swap) не нужно. Для таких серверов пространства подкачки объемом примерно 50% от размера основной памяти более чем достаточно. Заметим, что большинство этих правил прямо противоположены тому, что все ожидают.

PrestoServe/NVSIMM

Дисковые операции по своей природе связаны с механическими перемещениями головок диска, поэтому они выполняются медленно. Обычно UNIX буферизует операции записи в основной памяти и позволяет выдавшему их процессу продолжаться, в то время как на операционную систему ложится задача физической записи данных на диск. Синхронный принцип операций записи в NFS означает, что они обычно выполняются очень медленно (значительно медленнее, чем операции записи на локальный диск). Если клиент выдает запрос записи, требуется, чтобы сервер обновил на диске сами данные, а также все связанные с ними метаданные файловой системы. Для типичного файла необходимо выполнить до 4 записей на диск: каждая операция должна обновить сами данные, информацию в каталоге файла, индицирующую дату последней модификации, и косвенный блок; если файл большой, то потребуется также обновить второй косвенный блок. Прежде, чем подтвердить завершение запроса записи NFS, сервер должен выполнить все эти обновления и гарантировать, что они действительно находятся на диске. Операция записи NFS часто может продолжаться в течение 150-200 миллисекунд (три или четыре синхронных записи, больше чем по 40 миллисекунд каждая), по сравнению с обычными 15-20 миллисекундами для записи на локальный диск.

Для того чтобы существенно ускорить операции записи NFS, серверы могут использовать стабильную память (non-volatile RAM - NVRAM). Эта дополнительная возможность опирается на тот факт, что протокол NFS просто требует, чтобы данные операции записи NFS были бы зафиксированы в стабильной памяти вместо их фиксации на диске. До тех пор, пока сервер возвращает данные, которые подтверждены предыдущими операциями записи, он может сохранять эти данные любым доступным способом.

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

Поскольку одна логическая операция записи NFS выполняет три или четыре синхронные дисковые операции, использование NVRAM существенно ускоряет пропускную способность операций записи NFS. В зависимости от условий (состояния файловой системы, наличия других запросов к диску, размера и месторасположения записи и т.п.) использование NVRAM ускоряет операции записи NFS в 2-4 раза. Например, типичная пропускная способность при выполнении операций записи NFS под управлением ОС Solaris 2 составляет примерно 450 Кбайт/с. При использовании NVRAM скорость повышается примерно до 950 Кбайт/с и даже несколько выше, если используется сетевая среда более быстрая, чем Ethernet. Никаких улучшений времени выполнения операций чтения NVRAM не дает.

С точки зрения дисковой подсистемы или клиентов NFS дополнительные возможности PrestoServe и NVSIMM функционально эквивалентны. Основная разница заключается в том, что NVSIMM более эффективны, поскольку они требуют меньше манипуляций с данными. Поскольку плата PrestoServe физически размещается на шине SBus, требуется, чтобы данные копировались на нее через периферийную шину. В отличие от этого, NVSIMM размещаются прямо в основной памяти. Записываемые на диск данные не копируются в NVSIMM через периферийную шину. Такое копирование может быть выполнено очень быстро с помощью операций память-память. По этим причинам NVSIMM оказываются предпочтительными в ситуациях, когда обе возможности NVSIMM и PrestoServe оказываются доступными.

В связи с важностью получаемого ускорения Sun рекомендует использование NVRAM действительно во всех своих системах, которые обеспечивают универсальный сервис NFS. Единственным исключением из этого правила являются серверы, которые обеспечивают только сервис по чтению файлов. Наиболее характерным примером такого использования являются серверы, хранящие двоичные коды программ для большого коллектива клиентов. (В Sun он известен как сервер /usr/dist или softdist).

Поскольку драйвер устройства NVSIMM/PrestoServe должен находится на диске в корневой файловой системе, ускорение с помощью NVRAM не может быть получено для работы с самой корневой файловой системы. Драйвер NVRAM должен успевать откачивать модифицированные буфера на диск прежде, чем станет активным любой другой процесс. Если бы и корневая файловая система была ускорена, она могла бы оказаться "грязной" (модифицированной) после краха системы, и драйвер NVRAM не мог бы загрузиться.

Еще одно важное соображение при сравнении серверов, которые оборудованы NVRAM и без него, заключается в том, что использование такого ускорения обычно снижает максимальную пропускную способность системы примерно на 10%. (Системы, использующие NVRAM, должны управлять кэшем NVRAM и поддерживать в согласованном состоянии копии в кэше и на диске). Однако время ответа системы существенно улучшается (примерно на 40%). Например, максимальная пропускная способность SPARCserver 1000 на тесте LADDIS без NVSIMM составляет 2108 операций в секунду с временем ответа 49.4 мс. Таже система с NVSIMM может выполнять только примерно 1928 операций в секунду, но среднее время ответа сокращается примерно до 32 мс. Это означает, что клиенты NFS воспринимают сервер, оборудованный NVRAM, гораздо более быстрым, чем сервер без NVRAM, хотя общая пропускная способность системы несколько сократилась. К счастью, величина 10% редко оказывается проблемой, поскольку возможности максимальной пропускной способности большинства систем намного превышают типовые нагрузки, которые вообще находятся в диапазоне 10-150 операций в секунду на сеть.

Обеспечение резервного копирования и устойчивости к неисправностям

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

• Простые, сравнительно небольшие резервные копии могут изготавливаться с помощью одного или двух ленточных накопителей. Местоположение этих накопителей на шине SCSI не имеет особого значения, если они не активны в течение рабочих часов системы.
• Создание полностью согласованных резервных копий требует блокировки файловой системы для предотвращения ее модификации. Для выполнения таких операций необходимы специальные программные средства, подобные продукту Online:Backup 2.0. Как и в предыдущем случае, местоположение устройств резервного копирования на шинах SCSI не имеет особого значения, если само копирование выполняется вне рабочего времени.
• Зеркалированные файловые системы дают возможность пережить полные отказы дисков и, кроме того, обеспечивают возможность непрерывного доступа к системе даже во время создания полностью согласованных резервных копий. Зеркалирование приводит к очень небольшим потерям пропускной способности дисков на операциях записи (максимально на 7-8% при произвольном, и на 15-20% при последовательном доступе; в системах с большим числом пользователей, каковыми являются большинство серверов, можно надеяться, что эти цифры уменьшатся вдвое). Зеркалирование автоматически улучшает пропускную способность при выполнении операций чтения.
• При создании зеркалированных файловых систем каждое зеркало должно конфигурироваться на отдельной шине SCSI.
• Если резервное копирование должно выполняться в течение обычных рабочих часов системы, то устройство копирования должно конфигурироваться либо на своей собственной шине SCSI, либо на той же шине SCSI, что и выключенное из работы зеркало (отдельное и неактивное), чтобы обойти ряд проблем с обеспечением заданного времени ответа.
• Когда требуется быстрое восстановление файловой системы в среде с интенсивным использованием атрибутов следует предусмотреть в конфигурации NVRAM.
• В среде с интенсивным использованием данных необходимо исследовать возможность применения высокоскоростных механических устройств типа стэккеров лент и устройств массовой памяти.

Предварительная оценка рабочей нагрузки

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

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

Измерение существующих систем

Имеется много разнообразных механизмов для измерения существующих систем. Самый простой из них - это просто использовать команду nfsstat(8), которая дает информацию о смеси операций. Поскольку эти статистические данные могут быть заново устанавливаться в ноль посредством флага -z, команда nfsstat может также использоваться для измерения пропускной способности системы с помощью скрипта Shell, подобного показанному ниже.

#!/bin/sh

nfsstat -z >/dev/null #zero initial counters

while true

do

sleep 10

nfsstat - z -s #show the statistics

done

Выход показывает количество NFS-вызовов, которые были обслужены в заданном интервале и, следовательно, скорость, с которой обрабатываются операции NFS. Следует иметь в виду, что при тяжелых нагрузках команда sleep может в действительности "спать" намного больше, чем запрошенные 10 секунд, что приводит к неточности данных (т.е. переоценке количества запросов). В этих случаях должно использоваться какое-либо более точное средство. Имеется много таких средств, среди которых можно указать SunNetManager, NetMetrix от Metrix и SharpShooter от AIM Technologies. Все эти средства позволяют выяснить пропускную способность системы под действительной нагрузкой и смесь операций. Для вычисления средней пропускной способности обычно требуется некоторая последующая обработка данных. Для этого можно воспользоваться разнообразными средствами (awk(1), электронная таблица типа WingZ или 1-2-3).

Оценка нагрузки в отсутствие системы

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

Оценка среды с интенсивным использованием данных

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

Например, рассмотрим клиентскую рабочую станцию, выполняющую приложение, которое осуществляет поиск областей с заданной температурой в некотором объеме жидкости. Типовой набор данных для решения этой задачи составляет 400 Мбайт. Обычно он читается порциями по 50 Мбайт. Каждая порция проходит полную обработку прежде, чем приложение переходит к следующей. Обработка каждого сегмента занимает примерно 5 минут времени ЦП, а результирующие файлы, которые записываются на диск имеют размер около 1 Мбайта. Предположим, что в качестве сетевой среды используется FDDI. Максимальная нагрузка на NFS будет возникать, когда клиент читает каждую порцию объемом 50 Мбайт. При максимальной скорости 2.5 Мбайт/с клиент будет полностью активным примерно в течение двадцати секунд, выполняя 320 операций чтения в секунду. Поскольку каждый запуск программы занимает примерно 40 минут (или 2400 секунд) времени, и на один прогон требуется (400 + 1) Мb х 125 ops/Mb = 50,125 ops, средняя скорость равна примерно 20 ops/sec. Сервер должен будет обеспечивать обслуживание пиковой скорости запросов (320 ops/sec) в течение примерно 20 секунд из каждых 5 минут, или примерно в течение 7% времени. Из этого упражнения можно извлечь три порции полезной информации: среднюю скорость активных запросов (20 ops/sec), пиковую скорость запросов (320 ops/sec) и вероятность того, что пиковая скорость требуется. На базе этой информации может быть сформирована оценка общей скорости запросов. Если в конфигурации системы будет 10 клиентов, то средняя скорость запросов составит 200 ops/sec. (Эту скорость не следует сравнивать с результатами теста LADDIS, поскольку в данном случае смеси операций очень отличаются). Вероятность того, что два клиента будут требовать работы с пиковой скоростью одновременно составляет примерно 0.07 х 0.07 = 0.049, или примерно 5%, а три клиента будут требовать пикового обслуживания только в течение 0.034% времени. Таким образом, из этой информации разумно вывести следующие заключения:

• Поскольку вероятность того, что три клиента будут одновременно активными, намного меньше 1%, максимальная нагрузка будет превышать индивидуальную пиковую нагрузку в 2-3 раза.
• Требуется только одна сеть, поскольку максимальная предполагаемая нагрузка составляет только 3 х 2.5 Mb/sec = 7.5 MB/s, т.е. намного ниже максимальной полосы пропускания сети FDDI (12.5 MB/sec).
• Поскольку в любой момент времени полностью активными будут только два или три клиента, требуется по крайней мере от 3 до 6 дисковых накопителей (хотя для типовых файлов размером по 400 MB очень вероятно, что потребуется более 6 дисков просто для хранения данных).
• Требуется по крайней мере два главных адаптера SCSI.
• Поскольку в состав системы входит одна высокоскоростная сеть, то рекомендуется использовать сервер с двумя процессорами SuperSPARC/SuperCashe.
• Поскольку маловероятно, что очень большой кэш файлов окажется полезным для работы такого сервера, требуется минимальный объем основной памяти - 128 Мбайт вполне достаточно.
• Если требуется сравнительно небольшая ферма дисков, например, объемом около 16 Гбайт, то система SPARCstation 10 Model 512 очень хорошо сможет справиться с этой задачей, поскольку один слот SBus требуется для интерфейса FDDI, а оставшиеся три слота могут использоваться для установки главных адаптеров SCSI, чтобы обеспечить в общей сложности 4 интерфейса FSBE/S, к каждому из которых подключается дисковые накопители общей емкостью по 4.2 Гбайт. Однако для этого приложения может лучше подойти система SPARCserver 1000, которая обеспечит большую емкость памяти: система с двумя системными платами позволяет создать конфигурацию с семью главными адаптерами SCSI и емкостью дисковой памяти более 28 Гбайт (по одному многодисковому устройству емкостью 4.2 Гбайт на каждую плату FSBE/S, не считая четырех встроенных дисков емкостью по 535 Мбайт). В случае, если потребуется большая емкость дисков, можно сконфигурировать систему SPARCcenter 2000 с двумя системными платами, чтобы обеспечить реализацию шести интерфейсов DWI/S и до 12 шасси с дисками емкостью по 2.9 Гбайт - примерно 208 Гбайт памяти.
• Во все предлагаемые системы можно установить NVSIMM без использования слотов SBus, и все они легко поддерживают установку двух требуемых процессоров. Использование NVSIMM вообще не очень важно, поскольку пропорция операций записи слишком мала (меньше, чем 1:400, или 0.25%).

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

Оценка среды с интенсивным использованием атрибутов

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

Рассмотрим клиентскую рабочую станцию, наиболее интенсивная работа которой связана с перекомпиляцией программной системы, состоящей из исходного кода объемом 25 Мбайт. Известно, что рабочие станции могут скомпилировать систему примерно за 30 минут. В процессе компиляции генерируется примерно 18 Мбайт промежуточного объектного кода и двоичные коды. Из этой информации мы можем заключить, что клиентская система будет записывать на сервер 18 Мбайт и читать по крайней мере 25 Мбайт (возможно больше, поскольку почти треть исходного кода состоит из файлов заголовков, которые включены посредством множества исходных модулей). Для предотвращения повторного чтения этих файлов включений может использоваться кэширующая файловая система. Предположим, что используется CFS. Во время "конструирования" необходимо передать 33 Мбайт действительных данных, или 33 Мb х 125 ops/Mb = 4125 операций с данными за 30 минут (1800 секунд), что примерно соответствует скорости 2.3 ops/sec. (Здесь предполагается, что каждая операция выполняется с данными объемом 8 Kb, поэтому для пересылки 1 Mb данных требуется 125 операций). Поскольку эта работа связана с интенсивным использованием атрибутов, необходимо оценить существенное количество промахивающихся операций с атрибутами. Предположив, что смесь операций соответствует смеси Legato, общая скорость будет примерно равна:

Объем читаемых данных * 125

NFSops/sec = или
22%

Объем записываемых данных * 125

NFSops/sec = .
15%

В данном случае скорость равна: (25 Мb по чтению х 125ops/Mb) / 22% / 1800 секунд, или 7.89 ops/sec. Для проверки мы также имеем (18 Мb по записи х 125 ops/Mb) / 15% / 1800 секунд, или 8.33 ops/sec. В данном случае соотношение операций чтения и записи очень похоже на смесь Legato, но это может быть и не так, например, если были открыты файлы программы просмотра исходного текста (размер файлов программы просмотра исходного текста (source brouser files) часто в 4-6 раз превосходит размер исходного кода). В этом случае у нас нет способа оценки пиковой нагрузки.

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

• Даже при совершенно невероятном условии, когда все двадцать рабочих станций полностью активны все время, общая скорость запросов составляет 8.33 ops/sec x 20 клиентов, или 166 ops/sec, т.е. ниже максимума в 200 ops/sec, который поддерживает Ethernet. Осторожные люди сконфигурируют для такой нагрузки две сети, но если материально-технические соображения заранее это исключают, то и одной сети вероятно будет достаточно.
• Поскольку нагрузка относительно легкая, система SPARCstation 10 Model 40 оказывается более, чем адекватной. (Даже в самом плохом случае, имеются только две сети). Процессорной мощности системы SPARCclassic также обычно вполне достаточно.
• Хотя общее количество данных очень невелико (25 Мбайт исходного кода и 18 Мбайт объектного кода; даже двадцать полных копий составляют только 660 Мбайт), то в рекомендуемую конфигурацию дисков можно включить два диска по 535 Мбайт. В предположении, что используется CFS, может быть достаточно и одного диска, поскольку файлы заголовков не будут часто читаться с сервера (они будут кэшироваться клиентами).
• При одном или двух дисках данных одной шины SCSI полностью достаточно.
• Объем данных очень маленький и большинство из них будут читаться и пересылаться многим клиентам многократно, поэтому конечно стоит сконфигурировать достаточно памяти, чтобы все эти данные кэшировать: 16 Мбайт базовой памяти под ОС, плюс 25 Мбайт для кэширования исходных кодов в конфигурации 48-64 Мбайт.
• Поскольку в этой среде операции записи достаточно часты, NVSIMM или PrestoServe являются существенными.
• Для окончательного варианта системы можно выбрать либо станцию начального уровня SPARCstation 10, либо хорошо сконфигурированную станцию SPARCclassic. Для контроля с точки зрения здравого смысла заметим, что максимальная скорость запросов в 166 ops/sec на 75% меньше показателей SPARCclassic (236 ops/sec) на тесте LADDIS (вспомните, что скорость 166 ops/sec предполагала, что все 20 клиентов полностью активны все время, хотя реальные журналы использования систем показывают, что этого никогда не бывает); Максимальная требуемая нагрузка наполовину меньше той, которую показывает SPARCstation 10 Model 40 на тесте LADDIS (411 ops/sec). Сравнение с показателем LADDIS соответствует ситуациям с интенсивным использованием атрибутов, поскольку результаты LADDIS используют интенсивную по атрибутам смесь операций.

Таблица 4.3. Показатели LADDIS для различных NFS-серверов Sun под управлением Solaris 2.3. Немного (на 5%) более высокие скорости достижимы при использовании FDDI,
немного меньшие скорости - при использовании 16 Мбит Token Ring.

Последняя возможность: использование похожей нагрузки

Если отсутствует система для проведения измерений и поведение приложения не очень хорошо понятно, можно сделать оценку базируясь на похожей прикладной нагрузке, показанной в таблицах 4.4 - 4.6. Эти данные дают некоторое представление и примеры измеренных нагрузок NFS. Это не означает, что они дают определенную картину того, какую нагрузку следует ожидать от определенных задач. В частности, заметим, что приведенные в этих таблицах данные представляют собой максимальные предполагаемые нагрузки от реальных клиентов, поскольку эти цифры отражают только тот период времени, когда система активно выполняет NFS-запросы. Как отмечено выше в разд. 3.1.4, системы почти никогда не бывают полностью активными все время. Примечательным исключением из этого правила являются вычислительные серверы, которые в действительности представляют собой непрерывно работающие пакетные машины. Например, работа системы 486/33, выполняющей 1-2-3, показана в таблице 4.2 и на рис. 4.2. Хотя представленная в таблице пиковая нагрузка равна 80 ops/sec, из рисунка ясно, что общая нагрузка составляет меньше 10% этой скорости и что средняя за пять минут нагрузка значительно меньше 10 ops/sec. При усреднении за более длительный период времени, нагрузка ПК примерно равна 0.1 ops/sec. Большинство рабочих станций класса SPARCstation2 или SPARCstation ELC дают в среднем 1 op/sec, а большинство разумных эквивалентов клиентов SPARCstation 10 Model 51, Model 512, HP 9000/735 или RS6000/375 - 1-2 ops/sec. Конечно эти цифры существенно меняются в зависимости от индивидуальности пользователя и приложения.

Таблица 4.4. Оценка нагрузки полностью активных клиентов NFS на бизнес-приложениях (операция/с и продолжительность этапов)

Таблица 4.5. Оценка нагрузки полностью активных клиентов NFS на приложениях САПР (операция/с и продолжительность этапов)

Таблица 4.6. Оценка нагрузки полностью активных клиентов NFS на приложениях разработки ПО (операция/с и продолжительность этапов)