Управление томом, использование файловой системы и тонкая настройка системы

Cуществующие файловые системы берут свое начало от файловой системы UNIX (UNIX File System, UFS): разработанная в 1965 г., в начале 70-х она была во вполне работоспособном состоянии. С тех пор не так много изменилось в файловых системах, а основные перемены связаны с оборудованием. Я считаю файловую систему и менеджер тома наиболее критичными компонентами в достижении максимальной производительности ввода/вывода как в операционной системе, так и в аппаратной части, поскольку они могут быть сконфигурированы столь неудачно, что производительность системы упадет. Поэтому в статье описание файловой системы и управления томом дополняется рекомендациями по конфигурации и тонкой настройке файловой системы.

ОСНОВЫ ФАЙЛОВОЙ СИСТЕМЫ И МЕНЕДЖЕРА ТОМА

Цель файловой системы — представление хранилища данных таким образом, чтобы пользователи могли создавать, удалять, открывать, закрывать, читать, записывать и дописывать файлы на устройстве (устройствах). Кроме того, файловые системы могут использоваться для обеспечения безопасности файлов.

Изначальная цель управления томом UNIX (Volume Management, VM), разработанного в конце 80-х гг., состояла в группировании дисковых устройств и создании файловой системы размером больше одного устройства, а также в достижении высокой производительности путем их чередования. Команда mkfs позволяла создать файловую систему только на одном устройстве, а менеджеры тома предоставляли такое единое устройство. Кроме того, в них была добавлена поддержка RAID.

Большинству файловых систем требуется менеджер тома для группирования дисковых или RAID-устройств. Чередование применяется для распределения данных по устройствам в зависимости от заданного в менеджере тома размера полосы (stripe). Следует отметить, что некоторые менеджеры тома поддерживают сцепление данных, когда данные записываются на следующее устройство, только если предыдущее уже заполнено. Цель чередования состояла в распределении данных между несколькими устройствами для увеличения производительности и поддержки операций поиска несколькими дисковыми головками одновременно. На Рисунке 1 показано, что происходит при чередовании, когда несколько файлов записываются на диске одновременно и когда удаляется один из файлов.

Рисунок 1. Файловая система с чередованием четырех файлов и пяти устройств.

Некоторые файловые системы способны обслуживать и понимать топологию устройства без посредства менеджера тома. Они поддерживают как чередование (striping), так и циклическое размещение по кругу (round-robin). Размещение по кругу означает, что каждое устройство используется индивидуально. В большинстве случаев любое открытие файла переносится на следующее устройство. В некоторых файловых системах все создаваемые каталоги перемещаются на следующее устройство. На Рисунке 2 показан пример размещения по кругу: он значительно отличается от чередования. Я продемонстрирую, как можно увеличить производительность с помощью размещения по кругу.

Рисунок 2. Файловая система с круговым принципом размещения с четырьмя файлами и пятью устройствами.

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

КАК РАБОТАЮТ МЕНЕДЖЕР ТОМА И ФАЙЛОВАЯ СИСТЕМА

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

Внутри каждой файловой системы поддерживается какой-либо метод представления пространства для файлов. Наиболее распространенные из них:

1. экстенты;
2. косвенные блоки.

Если файловая система использует выделение дискового пространства на базе экстентов (еxtents), то в формате описателя файла inode отводится поле для адресного блока информации о данных файла. В большинстве систем внутри базового inode формируется 15 адресов экстентов с данными, и последний адрес внутри inode присоединяется к следующему inode, где выделяются еще 15 адресов зон. К файловым системам с подобной адресацией относятся Veritas VxFS, Sun QFS, SGI xfs и Linux extfs-3.

При использовании косвенной блочной адресации последний блок выделенного под файл пространства показывает на следующее размещение. Следовательно, пространство базового inode отведено под данные, и последний блок выделенного под данные пространства показывает на следующее выделенное пространство. Данный метод адресации был изначально разработан для файловой системы UFS в 1970 г. В ту пору дисководы были настолько медленными, что во время операции поиска не требовалось возвращаться назад к inode для выделения дополнительного пространства. Файловыми системами с поддержкой размещения по принципу косвенных блоков являются Sun UFS, IBM JFS и MS FAT-32.

Размещение косвенными блоками и производительность чтения/записи по сравнению с методом размещения по экстентам оказываются намного медленнее. К примеру, предположим, что приложение производит случайные операции чтения/записи. Чтобы найти адрес блока для записи (record), файл размещения по методу косвенных блоков должен прочесть все области данных для запрашиваемой записи прежде, чем он сможет прочесть саму запись. При размещении по методу экстентов файловая система может просто прочитать соответствующий inode, что дает огромный выигрыш в производительности. Я не слышал, чтобы в каких-либо новых файловых системах использовалось размещение по принципу косвенных блоков из-за значительного проигрыша в производительности на случайных операциях чтения/записи. Даже в случае последовательного ввода/вывода производительность при применении косвенно-блочного размещения ниже, чем у файловых систем с использованием экстентов.

ВЫДЕЛЕНИЕ СВОБОДНОГО ПРОСТРАНСТВА

У каждой файловой системы имеется свой алгоритм для поиска и выделения свободного пространства. В большинстве систем применяется метод «двоичного дерева», но иногда свободное пространство представляется в виде растра. Каждый метод имеет свои достоинства и недостатки.

Растровое представление не так распространено. В соответствии с этим методом каждый бит в карте представляет одну единицу размещения, например 1024 байт, 512 Кбайт или даже сотни мегабайт. Следовательно, одним битом может быть представлено достаточно большое пространство.

Двоичное дерево является, по сути, сортированным списком всех свободных и используемых участков в файловой системе. Важно понимать, как пространство распределяется из дерева (см. ссылки во врезке «Ресурсы Internet»).

Для каждого типа размещения (двоичное дерево или карта битов) свободное место должно быть найдено и выделено согласно методу представления. Эти алгоритмы размещения находят свободное пространство в соответствии с внутренним алгоритмом поиска. Два наиболее распространенных метода — первый подходящий и наиболее подходящий.

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

Метод выбора наиболее подходящего состоит в попытке найти оптимальное место в файловой системе для размещения данных. С его помощью снижают общую фрагментацию файловой системы, но, по сравнению с методом первого подходящего, он требует бо?льших ресурсов центрального процессора, так как во время поиска должна быть просмотрена вся файловая система. (Нужно отметить, что в тех системах, где размещение возможно только по круговому принципу, поиск должен вестись по устройству, на котором было сделано изначальное размещение.) Как уже было сказано, метод используется для снижения фрагментации, особенно когда отсутствует упреждающее размещение файлов (для тех файловых систем, которые поддерживают этот метод), либо для размещения больших файлов (до нескольких мегабайтов). Многие производители не предлагают его поддержку, и по большей части выделяемое под размещение место в файловой системе имеет маленький размер, поскольку в противном случае накладные расходы оказались бы слишком высоки. На этот метод ориентирована старая файловая система Cray NC1FS, при этом она пользуется векторными регистрами оборудования для быстрого поиска.

ПРОМЕЖУТОЧНЫЕ ВЫВОДЫ

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

Ввод/вывод приложений с использованием библиотеки ввода/вывода на Си оказывает большое влияние на объем действий, которые приходится выполнять системе. Лишняя работа, создаваемая приложениями на дисковых операциях ввода/вывода, может быть значительно уменьшена либо исключена совсем в зависимости от того, как настроен менеджер тома. Точно так же плохо настроенный том может увеличить накладные расходы на операции ввода/вывода и значительно уменьшить производительность системы. В обоих случаях менеджер тома — важная часть уравнения, так что ниже мы обсудим все аспекты настройки системы для менеджеров тома.

ТОНКАЯ НАСТРОЙКА СИСТЕМЫ

Одним из ключевых моментов настройки является сбор информации и понимание функционирования операций ввода/вывода в системе. Многие операционные системы, менеджеры томов и файловые системы предусматривают ограничение на размер запросов ввода/вывода. В Solaris, к примеру, по умолчанию, максимальный физический запрос составляет 128 Кбайт. Эту величину можно изменить в файле /etc/system добавлением строки:

set maxphys= «значение в десятичном, восьмеричном
 или шестнадцатеричном представлении»

Для задания величины maxphys равной 8 Мбайт, вы добавляете в /etc/system:

set maxphys=8388608

или

set maxphys=0x800000

В Solaris любое относящееся к системе ввода/вывода устройство SCSI — sd (SCSI Device Driver), ssd (Fibre Channel Device Driver) и st (Tape Device Driver) — предусматривает для операций передачи верхний предел в 1 Мбайт, даже если у maxphys в /etc/system задано значение, превышающее 1 Мбайт. Драйвер каждого устройства должен быть изменен для выполнения запросов, превышающих 1 Мбайт.

Таким образом, максимальный объем, который из приложения может быть передан в систему или из нее, будет составлять 1 Мбайт при отсутствии изменений в драйвере устройства — даже при условии внесения изменений в /etc/system. Модификацию драйвера произвести гораздо сложнее, чем /etc/system. Ошибки в конфигурации драйверов устройств могут привести к недоступности устройства вообще. Изменения каждого драйвера в Solaris производятся в файлах конфигурации /kernel/drv/?имя драйвера?.conf. Там, где ?имя драйвера? — sd, ssd, или st, надо добавить следующую строку для каждого соответствующего типа устройства.

?имя драйвера?_max_xfer_six=?значение?

К примеру, для изменения драйвера sd для разрешения большего объема передачи, равного 16,777,216 (16 Мбайт):

sd_max_xfer_size=0x1000000;

Для Solaris 8 такое изменение вносится последней строкой в список устройств SCSI, но в Solaris 9 оно должно быть вставлено первой строкой в файле. Крайне важно соблюдать регистр символов в шестнадцатеричном представлении, в частности нельзя использовать заглавную X. Использование заглавных букв помешает работе драйвера со всеми устройствами, для которых он предназначен. Кроме того, строка должна заканчиваться точкой с запятой.

Не менее важно отметить, что некоторые адаптеры главной шины (Host Bus Adapter, HBA) для Fibre Channel не поддерживают запросы больше 8 Мбайт. Обычно это объясняется разрешенным размером DMA в микросхеме контроллера Fibre Channel. Любые изменения должны быть протестированы. Создание запроса большего размера, чем допускает адаптер главной шины, может привести к зависанию канала и прекращению операций ввода/вывода через канал. Я знаю, что этого не должно происходить, но так получается на самом деле. После того как файловая система была сконфигурирована, для проверки среднего размера запроса ввода/вывода можно воспользоваться командами dd и sar, чтобы окончательно удостовериться, что система сконфигурирована корректно. Быстродействие системы проверяется путем запуска следующих двух команд одновременно:

dd if=/dev/zero of=путь_файловой_системы/
любой_файл bs=8192K count=64 & sar -d 1 5

Команда dd выполняет поблочные операции ввода/вывода с размером блока (bs) 8192 Кбайт (8388308 байт), копируя 64 записи или блока. Команда sar с ключом -d выдает результирующую дисковую активность, как показано на следующем примере:

# sar -d 1 5
SunOS gandalf 5.8 Generic_108528-07 sun4u
 	04/16/02
16:59:36	Device	%busy	avque	r+w/s
	blks/s	avwait	avserv
16:59:37	sd2	0	0.0 	4
 	131076 	0.0 	0.0
sd3	0	0.0	0	0	0.0
	0.0
16:59:38	sd2	24	1.8 	3
	98304	57.9 	27.3
sd3	0	0.0	0	0	0.0
 	0.0
16:59:39 	sd2 	1 	0.0 	4
 	131184 	0.0 	6.7
sd3 	0 	0.0 	0 	0 	0.0
 	0.0
16:59:40 	sd2 	0 	0.0 	5
 	163846 	0.0 	0.0
sd3 	0 	0.0 	0 	0 	0.0
 	0.0
16:59:41 	sd2 	0 	0.0 	3
 	98406 	0.0 	0.0
sd3 	0	0.0 	0 	0 	0.0
 	0.0
Average 	sd2 	5 	0.4 	3.8
 	124562 	53.1 	25.6
sd3	0	0.0	0 	0 	0.0
 	0.0
#

Для определения среднего размера запроса ввода/вывода разделите количество переданных за секунду блоков (blks/s) на число операций чтения/записи в секунду (r+w/s). Получившаяся величина должна быть приблизительно равна 16384 (8192*2). (В этом примере средний запрос ввода/вывода около 16 390.)

Если средний размер запроса ввода/вывода гораздо меньше этой величины, возможно, ошибка в ядре. О подробностях можно узнать в /var/adm/messages, особенно в тех разделах, которые относятся к maxphys и «xx»_max_xfer_size.

Тонкая настройка ленточных устройств может быть весьма проблематичной, поэтому перед изменением драйвера устройства st и увеличением размера запросов следует сделать следующее.

1. Убедитесь, что ваше ленточное устройство допускает размер блоков больше 1 Мбайт, так как размер запроса в 1 Мбайт можно задать путем изменения /etc/system.
2. Проверьте, что приложения, которые вы используете, могут создавать большие запросы к ленточному устройству. Очень часто этого не происходит, так что изменения в st становятся бессмысленными.
3. Протестируйте изменения. Как говорится, "доверяй, но проверяй". Это прекрасное руководство к действию при внесении в систему критичных изменений. Даже если вы уверены, что ответы на шаги 1 и 2 положительны, запустите тест, используя предыдущий пример, чтобы убедиться, что вы действительно создаете большие запросы к устройству.

Другие операционные системы, например SGI IRIX, имеют аналог maxphys, называющийся maxdmasz. У IRIX нет ограничений в драйвере, как у Solaris. В AIX присутствуют ограничения собственно файловой системы, но они не зависят от ядра. Linux также ограничен реализацией файловой системы, но не ядра.

КОНФИГУРАЦИЯ МЕНЕДЖЕРА ТОМА

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

Для файловых систем, которым требуется менеджер тома, существует два важных фактора, с которыми необходимо считаться:

1. размер полосы тома;
2. настройки размера запроса.

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

1. количество и тип устройств, которые составляют том, в том числе:
   1. ширину полосы RAID;
   2. количество устройств на шине Fibre Channel или SCSI;
2. cкорость каждого устройства в томе.

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

Количество участвующих в чередовании устройств
 = 4.
Средний размер файла = 32 Кбайт.

Если величину полосы сделать равной 2 Мбайт, то в среднем на каждом устройстве может быть размещено 64 файла. Это удобно, если вы обращаетесь к этим файлам последовательно. Но если они запрашиваются случайным образом группами по 32, то производительность снизится, если все 32 файла будут на одном устройстве. Их размещение на разных устройствах способно повысить производительность. Нередко самая долгая операция в процессе ввода/вывода на любом массиве RAID или диске — это не операция передачи, а операция поиска.

Дополнительно некоторые менеджеры тома, в частности Veritas VxVM, предусматривают настройки для ограничения размера запросов к менеджеру тома. В VxVM такая переменная называется vxio:vol_maxio. По умолчанию, максимальный запрос, который может быть передан менеджеру тома без системной фрагментации запроса ввода/вывода, составляет 256 Кбайт. Для изменения этого значения в Solaris, добавьте следующую строку в /etc/system:

set vxio:vol_maxio = 32 768

Максимальное значение может быть задано равным 65535 или 32 Мбайт. Даже если установить maxphys, /kernel/ drv/sd.conf и vxio:vol_maxio в 32 Мбайт, максимальный запрос к драйверу SCSI в настоящее время составляет 32 Мбайт — 32 Кбайт — 1 байт. Комитет по стандартам собирается изменить эту величину и заодно максимальный нормальный LUN, который в настоящее время составляет 2 Тбайт. Некоторые производители (к примеру, IBM AIX) переписали драйверы устройств с поддержкой LUN большей емкости.

Кроме того, оптимальная величина может быть задана при учете следующих параметров:

1. количество устройств в томе;
2. размер запросов ввода/вывода в приложениях;
3. проблемы с фрагментацией и размером запроса ввода/вывода.

Количество устройств в томе — также важная величина. Учитывая, что большинство производителей, как и стандартов, поддерживают максимальный размер файловых систем в 2 Тбайт, количество подчиненных устройств может достигать только 11 дисков на 180 Гбайт. Надо знать, сколько устройств участвует в чередовании. К примеру, наличие 10 устройств с полосой размера 32 Кбайт ведет к тому, что полная полоса составит 1032 Кбайт. При задании размера полосы в 2 Мбайт вместо 32 Кбайт полная полоса увеличится до 20 Мбайт. Использование приложений, которые могут полностью занимать полосу или, предпочтительнее, несколько полос данных для упреждающего чтения, значительно увеличит производительность ввода/вывода. И совсем хорошо, если алгоритм массива RAID поддерживает упреждающее чтение. Но имейте в виду, что будет и обратный эффект — его описание я привожу ниже.

Теперь о том самом «обратном эффекте». Если выполняемые запросы ввода/вывода имеют небольшой размер и вы хотите полностью занять полосу данных, то производительность системы будет резко снижаться с уменьшением размера запроса. Скажем, ваше приложение выполняет запросы ввода/вывода на 256 Кбайт (их может выполнять Oracle при соответствующей настройке), и у вас есть восемь устройств и элемент полосы на 32 Кбайт. Производительность в реальном времени и по загрузке процессора с запросами объемом 32 Кбайт, по сравнению с запросами объемом 256 Кбайт, сильно отличается. На это оказывает влияние множество факторов, включая тип устройств, интерфейс (SCSI или FC) и файловую систему, но можно легко заметить уменьшение в мегабайтах в секунду на 50% и увеличение загрузки системы на 20%. Так что, как видно, трудно дать какие-то общие рекомендации относительно тонкой настройки. Кроме того, чтобы достичь хорошей производительности ввода/вывода, надо иметь представление о всем пути ввода/вывода.

Использование малых элементов полосы может привести к сильной фрагментации устройства, если размещение файлов не контролируется системой. Тонкий момент состоит в том, что в случае больших запросов ввода/вывода вы не получаете преимущества одновременного чтения/записи с нескольких устройств. В наши дни один массив RAID с коммутатором Fibre Channel может обеспечить приемлемую производительность практически для всех приложений. Так что одно из решений, которые мы предлагаем заказчикам, состоит в установке очень больших значений полосы вместо того, чтобы позволять нескольким устройствам участвовать в обслуживании запросов ввода/вывода. К примеру, многие базы данных используют файлы размером 2 Гбайт, и для них предлагается задавать размер полосы в 2 Гбайт. Таким образом, каждый файл базы данных циклически записывается на отдельное устройство.

ВЫВОДЫ

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

? CMP Media LLC

Ресурсы Internet

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

назад