Курсовая работа: Основы конфигурирования сетевых файловых систем (на примере NFS)
Заключительные рекомендации по конфигурированию дисков
Основные правила по конфигурированию дисков можно обобщить следующим образом:
- В среде с интенсивным использованием данных следует конфигурировать от 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 были бы зафиксированы в стабильной памяти вместо их фиксации на диске. До тех пор, пока сервер возвращает данные, которые подтверждены предыдущими операциями записи, он может сохранять эти данные любым доступным способом.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
