Купить / Заказать / Узнать цену

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

Все статьи об оптимизации систем и технологий хранения данных, описания RAID.

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

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

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

Общее требование к RAID системе для таких операций - максимальное количество операций ввода/вывода в единицу времени. Производительность RAID системы в этом случае определяется числом IO операций за секунду (IO per second или IOPS). Фактическим стандартом в мире для оценки производительности в IOPS стала бесплатная программа IOMeter, в свое время разработанная корпорацией Intel и затем переданная ей для развития как свободного Open Source проекта. На www.iometer.org вы всегда можете найти подробную информацию о проекте. Итак, первый профиль для оптимизации - настройка RAID системы для  выполнения максимального количества операций ввода/вывода в секунду или maximum IO per second (IOPS). 

Вторая весьма широкая сфера применения - запись/чтение линейных потоков данных. Самый понятный и известный пример таких данных - видео- аудио- потоки. Действительно, работа с несжатым видео высокого разрешения, например, требует для данных 1920 x 1080/60i 4:2:0 скорости записи не менее 117 MB/s. В реальности скорость RAID массива должна быть раза в два больше для комфортной работы. Обработка оцифрованного кино или данных с видеокамер киноразрешения требует скоростей, превышающих 250 MB/s, а для комфортной работы скорость должна быть под 400 MB/s. Но, кроме кино и видео, существует еще ряд задач, требующих высокой линейной скорости записи. Одна из самых типичных - обработка геофизических данных. Здесь нередки требования к минимальной скорости записи от 200 MB/s. Таким образом, идея второго профиля понятна, это максимально возможная полоса пропускания RAID (Maximum throughput). Понятно, что производительность здесь измеряется в мегабайтах в секунду. Для тестирования производительности подойдет как IOMeter, так и ряд других программ.  

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

 - Игры ума

Итак, наша задача выжать максимум производительности с  RAID с помощью его настроек. 

О важности этого параметра и о том, каким его выбирать, очень часто идут споры, в результате которых до сих пор окончательно истина так и не родилась, несмотря на популярность поговорки о полезности споров. Stripe size, параметр, обычно допускающий изменения даже в самых недорогих моделях RAID систем, означает размер блока данных, записываемый на каждый диск RAID массива в каждой stripe. Если, например, у вас RAID из 4 дисков, то задание stripe size в 64 kB принудит RAID контроллер записывать/читать данные блоками по 64 kB на/с каждый диск в массиве. 

Исходя из здравого смысла, разумно полагать, что для работы с большими файлами в сотни мегабайт и более, т.е. для потоковых операций, следует выбирать максимально возможный размер stripe size, а для работы с множеством мелких данных выбирать если не минимальный размер, то близкий к минимальному. К сожалению, в данной ситуации надо руководствоваться не только здравым смыслом. Все дело в том, что разработчики RAID контроллеров отрабатывают и тем самым оптимизируют работу RAID практически для одного значения stripe size, и это значение обычно бывает либо 64 kB либо 128 kB. 

Поэтому мы рекомендуем в том случае, если у вас нет достаточно большого времени на тестирование производительности RAID системы именно под вашу задачу, оставить значение по умолчанию. Ежели время есть, то только тестирование сможет выявить наилучший размер stripe size для ваших приложений. Разумеется, размеры stripe size меньше 32 kB лучше не тестировать, как правило, 16 kB или 8 kB слишком мало для любых задач. 

Определяет размер блока, кратно которому процессор RAID контроллера будет читать/записывать данные в кэш-память контроллера. Этот параметр влияет на производительность очень опосредованно и мы рекомендуем выбирать его равным Stripe Size. Выбирать его значение большим, чем Stripe Size, кстати, запрещено в принципе.

Параметр Read Ahead multiplier (Множитель для упреждающего чтения) определяет, сколько секторов данных RAID контроллер должен заранее считать и положить в свою кэш-память, как бы упреждая запрос со стороны компьютера на считывание данных и тем самым ускоряя ответ на запрос. Правильное определение этого параметра целиком зависит от информации об используемом вами приложении. Понятно, что значение параметра должно быть, по крайней мере, не меньше, чем блок данных, запрашиваемый приложением. Если, например, вы знаете, что приложение считывает данные блоками по 16 байт, например, то значение Read Ahead multiplier надо выставить в 32. 

Поскольку упреждать запрос от компьютера есть смысл только при последовательных операциях чтения, надо понимать, что при случайных обращениях к различным мелким данным на массиве, большОе значение Read Ahead multiplier может только замедлить работу системы. Поэтому лучше экспериментально проверить реакцию вашего приложения на изменение параметра, благо для этого не требуется заново инициализировать массив. Если вы настраиваете массив на максимальное количество операций ввода/вывода, то этот параметр правильнее отключать вообще с помощью Read Ahead Policy. Для работы с потоками, наоборот, значение этого параметра следует установить в диапазоне от 8 до 32, подобрав наилучшее значение экспериментально.

Этот параметр определяет, запускать или нет процедуру упреждающего чтения, и, если да, то каким образом. Обычно Read Ahead Policy может принимать три значения:

• Always (Всегда) - упреждающее чтение выполняется всегда.

• Adaptive (Адаптивно) - контроллер, обнаружив команды на последовательное чтение, сам включает (или выключает) упреждающее чтение.

• Off (Выключить) - упреждающее чтение запрещается.

Рекомендуется здесь выбирать Adaptive, если RAID предназначен для решения широкого спектра задач и отдать тем самым принятие решения на откуп RAID контроллеру. Если RAID массив рассчитан на "переваривание" максимально возможного количества IOPS, то этот параметр обычно устанавливается в Off. 

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

Параметр будет использоваться, разумеется, только при включенном  в Adaptive или Always режиме Read Ahead Policy.

Параметр  Write cache periodic flush (Периодическая очистка кэш-памяти на запись) определяет, как часто контроллер будет принудительно записывать данные из кэш-памяти на диски, очищая тем самым кэш-память от данных на запись. Смысл этого параметра в попытке управления надежностью системы. Чем чаше содержимое будет сбрасываться на диски, тем меньше вероятность повреждения данных в случае нештатных ситуаций, таких как обрыв питания, например. 

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

Этот параметр может также называться Synchronize Cache. В этом варианте его запрет означает запрет на периодическую очистку кэш-памяти. 

Параметр определяет, после какого уровня заполнения кэш-памяти на запись следует принудительно записать содержимое кэш-памяти на диски и измеряется в процентах. Здесь резонно соблюсти тот же подход, что и в Write cache periodic flush - если система достаточно защищена от аварий, то можно увеличить этот процент до 90. 

Один из самых интересных параметров, влияющих, как правило, на производительность RAID системы вне зависимости от профиля производительности. Alignment offset (Выравнивающий сдвиг)позволяет сместить реальный стартовый сектор (реальный, разумеется, с точки зрения операционной системы) на требуемое число секторов. Это позволяет исключить "раскалывание" stripe на части и тем самым минимизировать количество внутренних операций ввода/вывода в RAID массиве. Идея Alignment offset иллюстрируется рисунком ниже.

Оптимальное значение этого параметра зависит как от операционной системы, так и от размера stripe size. Для Windows рекомендованные значения 63, Для *nix OS (и Mac) 64, но возможны и другие значения, зависящие от производителя системы хранения и типа конкретной файловой системы. Кроме этого, следует подбирать и размер одного блока данных (allocation unit, cluster и.п.), которым оперирует операционная система, причем этот параметр следует подбирать с учетом основного приложения, использующего RAID. В наших экспериментах прирост производительности за счет сдвига достигал 10%. 

Источник: Maxtronic