Производительность, утилиты и общие ключевые вопросы
О: Для запуска устройства RAID-0 на полную скорость, у Вас должны разделы на разных дисках. Кроме того, помещая две половины зеркала на один диск Вы не получаете защиты от отказа диска.
О: Не очевидно, что RAID-0 даст большую производительность; фактически, в некоторых случаях, он может сделать хуже. Файловая система ext2fs распределяет фалы по всему разделу, и пытается хранить все блоки файла вместе, в основном в целях избежания фрагментации. Таким образом, ext2fs ведет себя "как если бы" stripe-ы были (переменного размера) размером с файл. Если есть несколько дисков соединяются в один линейный RAID, это приведет к статистическому распределению файлов на оба диска. Таким образом, по крайней мере для ext2fs, линейный RAID работает во многом подобно RAID-0 с большим размером stripe. Наоборот, RAID-0 с маленьким размером stripe при одновременном доступе к нескольким большим файлам может вызвать излишнюю дисковую активность, приводящую к снижению производительности.
Во многих случаях, RAID-0 может явно выигрывать. Например, представьте большой файл базы данных. Так как ext2fs пытается объединить вместе все блоки файла, велики шансы, что она заполнит только одно устройство при использовании линейного RAID, но будет разделять на много кусочков, при использовании RAID-0. Теперь представим несколько нитей (ядра) пытающихся получить произвольный доступ к базе данных. При линейном RAID, весь доступ пойдет на один диск, что не так эффективно, как параллельный доступ, создаваемый RAID-0.
О: Для понимания этого, давайте рассмотрим пример с тремя разделами; 50Мб, 90Мб и 125Мб.
Назовем D0 50Мб диск, D1 90Мб диск и D2 125Мб диск. Когда Вы запускаете устройство, драйвер вычисляет 'strip zones'. В этом случае, он найдет 3 зоны, определенные подобно этому:
Z0 : (D0/D1/D2) 3 x 50 = 150MB всего в этой зоне Z1 : (D1/D2) 2 x 40 = 80MB всего в этой зоне Z2 : (D2) 125-50-40 = 35MB всего в этой зоне.
Вы можете видеть, что общий размер зон - размер виртуального устройства, но, в зависимости от зоны, striping различается. Z2 особенно неэффективна,так как там только один диск.
Так как ext2fs и большинство других файловых систем Unix распределяют файлы по всему диску, У Вас 35/265 = 13% шансов, что заполнение закончится на Z2, и не получится никаких преимуществ RAID-0.
(DOS пытается заполнить диск от начала до конца, и таким образом, старые файлы должны храниться на Z0. Однако, эта стратегия приводит к резкой фрагментации файловой системы, это причина того, что никто кроме DOS так не делает.)
О: Ответ зависит от используемой Вами конфигурации.
Производительность Linux MD RAID-0 и линейного RAID:
Если система слишком загружена вводом-выводом, статистически, часть пойдет на один диск, а часть на другой. Таким образом, производительность увеличится по сравнению с одиночным диском. Фактическое увеличение сильно зависит от текущих данных, размера stripe, и других факторов. В системе с низким вводом-выводом, производительность эквивалентна производительности одного диска.
Производительность чтения Linux MD RAID-1 (зеркализация):
MD реализует балансировку чтения. То есть, код RAID-1 будет поочередно выбирать каждый из дисков (двух или более) зеркала, производя поочередное чтение с каждого диска. В случае небольшого ввода-вывода, это вовсе не изменит производительность: Вы будете ждать завершения чтения одного диска. Но, с двумя дисками и при высокой загрузке вводом-выводом, возможно получить практически удвоенную производительность, так как опреации чтения будут выполняться с каждого диска одновременно. Для N дисков в зеркале, это может увеличить производительность в N раз.
Производительность записи Linux MD RAID-1 (зеркализация):
Нужно ждать, пока запишутся данные на все диски зеркала. Это из-за того, что копия данных должна быть записана на каждый из дисков зеркала. Таким образом, производительность будет приблизительно эквивалентна производительности записи на один диск.
Производительность чтения Linux MD RAID-4/5:
Статистически, данный блок может быть на любом из дисков, и, таким образом, производительность чтения RAID-4/5 во многом подобна RAID-0. Она зависит от данных, размера stripe, и приложения. Она не будет так хороша, как производительность чтения в зеркальном массиве.
Производительность записи Linux MD RAID-4/5:
Она, в общем, должна быть предположительно меньше, чем у одного диска. Это из-за того, что на один диск должна быть записана информация о паритете, в то время как на другой - данные. Однако, в случае вычисления нового паритета, старый паритет и старые данные должны быть сначала считаны. Старые данные, новые данные и старый паритет должны быть объединены операцией XOR для определения новой информации о паритете: это требует циклов процессора и дополнительного доступа к дискам.
О: Ваша цель максимальная пропускная способность, или минимальные время доступа? Нет простого ответа, так как на производительность влияет много факторов:
О: Так как RAID-5 создает загрузку ввода-вывода, которая одинаково распределена на несколько устройств, лучшая производительность будет получена, когда RAID набор сбалансирован использованием идентичных дисков, идентичных контроллеров, и одинаковым (небольшим) числом дисков на каждом контроллере.
Однако заметьте, что использование идентичных компонент увеличивает возможность множества одновременных отказов, например из-за внезапного толчка или урона, перегрева, или скачка электричества во время грозы. Смешивание марок и моделей помогает минимизировать этот риск.
О: Если используется текущая (Ноябрь 1997) RAID-4/5 реализация, строго рекомендуется создавать файловую систему с mke2fs -b 4096 вместо 1024 байтов, по умолчанию.
Это потому, что текущая реализация RAID-5 резервирует одну 4Кб страницу памяти на дисковый блок; если размер блока диска будет 1Кб, тогда 75% памяти, которую резервирует RAID-5 для осуществления ввода-вывода, не используется. Если размер блока диска совпадает с размером страницы памяти, тогда драйвер (потенциально) может использовать всю страницу. Итак, для файловой системы с размером блока 4096 в отличие от системы с размером блока 1024, драйвер RAID будет потенциально ставить в очередь 4 раза производя ввод-вывод с драйверам нижнего уровня без расходования дополнительной памяти.
Заметка: пометки выше НЕ применимы драйверу программного RAID-0/1/линейного.
Заметка: высказывание о 4Кб странице памяти применимо к архитектуре Intel x86. Размер страницы на Alpha, Sparc, и других процессорах различается; я думаю на Alpha/Sparc он 8Кб (????). Скорректируйте соответственно указанное значение.
Заметьте: если на Вашей файловой системе много небольших файлов (файлов размером менее 10Кб), значительная чaсть дискового пространства может быть потеряна. Это из-за того, что файловая система распределяет дисковое пространство частями размером в блок. Выделение больших блоков маленьким файлам приводит к потерям дискового пространства: таким образом, Вы можете поставить небольшой размер блока, получить большую эффективность использования емкости, и не беспокоиться о "потерянной" памяти из-за несоответствия размера блока размеру страницы памяти.
Заметка: большинство ''типичных'' систем не содержат много маленьких файлов. То есть, хотя могут быть тысячи небольших файлов, это будет приводить к потере только от 10 до 100Мб, что, возможно, приемлимо, учитывая производительность, на много-гигабайтном диске.
Однако, для серверов новостей, может быть десятки и сотни тысяч небольших файлов. В этом случае, меньший размер блока, и таким образом сохраненная емкость, может быть более важной, чем более эффективный ввод-вывод.
Заметка: существует экспериментальная файловая система для Linux, которая пакует маленькие фалы и группы файлов в один блок. Она имеет большую производительность, если средний размер файла намного меньше размера блока.
Заметка: Будущие версии могут реализовать схемы, которые лишат смысла вышеприведенную дискуссию. Однако, это сложно реализовать, так как динамическое распределение на ходу может привести к мертвым-блокировкам (dead-locks); текущая реализация выполняет статическое предварительное выделение.
О: Размер куска - количество смежных данных на виртуальном устройстве, которы смежные и на физическом устройстве. В этом HOWTO, "кусок" и "stripe" подразумевают одно и то же: что часто называется "stripe" в другой документации по RAID, в MD man страницах называется "кусок" ("chunk"). Stripe-ы или куски применимы только к RAID 0, 4 и 5, так как stripe-ы не используются в зеркализации (RAID-1) и простом соединении (линейный RAID). Размеры stripe влияют на задержку, пропускную способность, и конкуренцию между отдельными операциями (возможность одновременного обслуживания перекрывающихся запросов ввода-вывода).
Предполагая использование файловой системы ext2fs, и текущих правил ядра для упреждающего чтения, большие размеры stripe почти всегда лучше, чем маленькие размеры, и размеры stripe от почти четырех до полного цилиндра диска наилучшие. Чтобы понять это требование, рассмотрим эффективность больших stripe на маленьких файлах, и маленьких stripe на больших файлах. Размер stripe не влияет на производительность чтения на маленьких файлах: для массива из N дисков, файл имеет 1/N вероятность попасть целиком в один stripe на любой диск. Таким образом, и задержка и производительность чтения сравнима с чтением одного диска. Предположим, что маленькие файлы статистически хорошо распределяются по файловой системе, (и, на файловой системе ext2fs, они дожны), грубо в N раз более упорядочены, конкурентные чтения должны быть возможны без значительных коллизий между ними. Наоборот, если используются очень маленького размера stripe-ы, и последовательно читается большой файл, то чтение будет выдаваться всем дискам массива. Для чтения одного большого файла, задержка будет почти двойная, так как увеличивается вероятность нахождения блока в трех четвертях оборота диска или далее. Однако заметьте аргумент: пропускная способность может увеличиться почти в N раз для чтения одного большого файла, так как N дисков могут читать одновременно (то есть, если используется упреждающее чтение, то все диски остаются активными). Но есть другй контр-аргумент: если все диски уже заняты чтением файла, то попытки одновременного чтения второго или третьего файла приведут к значительной борьбе, разрушив производительность, так как алгоритмы управления диском будут двигать головками вдоль пластины. Таким образом, большие stripe-ы будут почти всегда приводить к большей производительности. Единственное исключение - случай, при использовании хорошего алгоритма упреждающего чтения, где один поток в одно время читает один большой файл, и он требует наивысшей возможной производительности. В этом случае желательны небольшие stripe-ы.
Заметьте, что этот HOWTO ранее рекомендовал небольшие размеры stripe-ов для спула новостей или других систем с множеством мелких файлов. Это плохой совет, и вот почему: спулы новостей содержат не только много маленьких файлов, но также и большие суммарные файлы, также как и большие каталоги. Если суммарный файл более одного stripe, его чтение задействует много дисков, замедляя все, так как каждый диск выполняют позиционирование. Подобным образом, текущая файловая система ext2fs просматривает каталоги в линейной, последовательной манере. Таким образом, чтобы найти данный файл или inode, в средней части будет прочитана половина каталога. Если этот каталог простирается на несколько stripe-ов (несколько дисков), чтение каталога (такое как при команде ls) будет очень медленным. Спасибо Steven A. Reisman < > за эту поправку. Steve также добавил следующее:
Я обнаружил, что использование 256k stripe дает намного лучшую производительность. Я подозреваю, что оптимальный размер должен быть размером с цилиндр диска (или, может быть размером с кеш диска). Однако, современные диски содержат зоны с различным количеством секторов (и размер кеша варьируется в зависимости от модели диска). Невозможно гарантировать, что stripe-ы не будут пересекать границу цилиндра.
Утилиты позволяют задавать размер в Кбайтах. Вы можете указать его величиной с размер страницы Вашего CPU (4Кб на x86).
mke2fs -b 4096 -R stride=nnn ...
Кокое должно быть значение nnn?
О: Флаг -R stride используется, чтобы указать файловой системе размер RAID stripe-ов. Так как только RAID-0,4 и 5 использует stripe-ы, а RAID-1 (зеркализация) и линейный RAID не используют, этот флаг применим только к RAID-0,4,5.
Знание размера stripe-а позволяет mke2fs
выделять блок и битовый поля inode так, что они не все хранятся на одном физическом устройстве. Неизвестный помощник написал:
Прошлой весной я заметил, что один диск из пары всегда больше занят вводом-выводом, и отследил - это из-за этих блоков мета-данных. Ted добавил опцию -R stride=, в мой вариант ответа и предложение обходного варианта.
Для файловой системы с блоком 4Кб, с размером stripe в 256Кб, нужно использовать -R stride=64.
Если Вы не доверяете флагу -R, Вы можете получить подобный эффект другим путем. Steven A. Reisman < > написал:
Другое соображение - файловая система используемая на устройстве RAID-0. Файловая система выделяет ext2 8192 блоков в группу. У каждой группы есть свой набор inode-ов. Если есть 2, 4 или 8 дисков, эти inode скапливаются на первом диске. Я распределили inode-ы по всем дискам, указав mke2fs выделять только 7932 блоков на группу.
Некоторые страницы mke2fs не описывают флаг [-g blocks-per-group]
используемый при этой операции.
О: Rod Wilkens < > написал:
Вот что я сделал: вставил ``mdadd -ar'' в ``/etc/rc.d/rc.sysinit'' прямо после загрузки модулей, и перед проверкой дисков ``fsck''. Таким образом, Вы можете вставить устройство ``/dev/md?'' в ``/etc/fstab''. Затем вставить ``mdstop -a'' прямо после де-монтирования всех дисков ``umount -a'', в файле ``/etc/rc.d/init.d/halt''.
Для raid-5, Вы должны посмотреть на код возврата mdadd, и если он ошибочен, сделать
ckraid --fix /etc/raid5.conf
для восстановления любых повреждений.
О: Да. (описать как это сделать)
О: Обычно, аппаратный RAID считается производительнее программного RAID, так как аппаратные контроллеры, часто содержат большой кеш, и могут лучше выполнять планирование параллельных операций записи. Однако, интегрированный программный RAID может (и дает) определенное преимущество при реализации в операционной системе.
Например, ... мммм. Мы обходим молчанием темное описание кеширования реконструированных блоков в буферный кеш ...
На дуальных PPro SMP системах, мне рассказывали, что производительность программного RAID превышала производительность плат аппаратного RAID известных производителей с кратностью от 2 до 5 раз.
Программный RAID также очень интересная опция для избыточных серверных систем высокой готовности. В такой конфигурации, два CPU подсоединены к одному набору SCSI дисков. Если один север рушится или отказывается отвечать, то другой сервер может mdadd, mdrun и mount массив программного RAID, и продолжить работу. Этот режим работы не всегда возможен с многими аппаратными RAID контроллерами, из-за состояний конфигурации которое аппаратные контроллеры могут поддерживать.
О: Нет, по крайней мере до смены старшего номера версии. MD версия x.y.z состоит из трех подверсий:
x: старший номер версии. y: младший номер версии. z: номер уровня патча.
Версия x1.y1.z1 драйвера RAID поддерживает RAID массив с версией x2.y2.z2 в случае (x1 == x2) и (y1 >= y2).
Различные номера патчей (z) для тех же (x.y) версий разработаны по большей мере совместимыми.
Младший номер версии увеличивается всякий раз, когда код RAID массива изменяется таким образом, что он несовместим с старыми версиями драйвера. Новые версии драйвера должны поддерживать совместимость с старыми RAID массивами.
Старший номер версии увеличивается, если более не имеет смысла поддерживать старые RAID массивы в новом коде ядра.
Для RAID-1, не правдоподобно, чтобы ни дисковый уровень ни структура суперблока изменились в ближайшее время. Скорее всего любые оптимизации и новые свойства (реконструкция, многопоточные утилиты, горячая замена, и т.п.) не отразятся на физическом размещении.
О: Есть процесс, который держит открытым файл на /dev/md0, или /dev/md0 все еще смонтирован. Завершите процесс или umount /dev/md0.
О: Существует новая утилита, называемая iotrace в каталоге linux/iotrace. Она читает /proc/io-trace и анализирует/строит графики из его вывода. Если Вы чувствуете, что блочная производительность Вашей системы слишком низкая, просто посмотрите на вывод iotrace.
О: SPEED_LIMIT используется для ограничения скорости реконструкции RAID при автоматической реконструкции. По существу, автоматическая реконструкция позволяет Вам e2fsck и mount сразу после неправильного завершения, без предварительного запуска ckraid. Автоматическая реконструкция также используется после замены отказавшего диска.
Для избежания подавления системы при реконструкции, нить реконструкции контролирует скорость реконструкции и уменьшает ее, если она слишком высока. Предел 1Мб/сек был выбран как разумная норма, которая позволяет реконструкции завершаться умеренно быстро, при создании только небольшой нагрузки на систему, не мешая другим процессам.
О: Синхронизация шпинделей используется для поддержания вращения нескольких дисков с одинаковой скоростью, так что пластины дисков всегда точно выровнены. Это используется некоторыми аппаратными контроллерами для лучшей организации записи на диски. Однако, в программном RAID, эта информация не используется, и синхронизация шпинделей может даже снизить производительность.
О: Leonard N. Zubkoff отвечает: Да она действительно быстра, но Вам не нужно использовать MD для получения striped подкачки. Ядро автоматически разделяет подкачку по нескольким пространствам подкачки с одинаковым приоритетом. Например, следующие записи из /etc/fstab разделяют подкачку по пяти дискам в три группы:
/dev/sdg1 swap swap pri=3 /dev/sdk1 swap swap pri=3 /dev/sdd1 swap swap pri=3 /dev/sdh1 swap swap pri=3 /dev/sdl1 swap swap pri=3 /dev/sdg2 swap swap pri=2 /dev/sdk2 swap swap pri=2 /dev/sdd2 swap swap pri=2 /dev/sdh2 swap swap pri=2 /dev/sdl2 swap swap pri=2 /dev/sdg3 swap swap pri=1 /dev/sdk3 swap swap pri=1 /dev/sdd3 swap swap pri=1 /dev/sdh3 swap swap pri=1 /dev/sdl3 swap swap pri=1
О: Во многих случаях, ответ - да. Используя несколько контроллеров для параллельного доступа к дискам увеличивает производительность. Однако, действительное приращение фактически зависит от вашей конфигурации. Например, как сообщили (Vaughan Pratt, Январь 98) что один 4.3Гб Cheetah подключенный к Adaptec 2940UW может дать до 14Мб/сек (без использования RAID). Установив два диска на один контроллер, и используя конфигурацию RAID-0 привело к увеличению производительности до 27 Мб/сек.
Заметьте,что 2940UW контроллер - "Ultra-Wide" SCSI контроллер, теоретически способный к пакетным передачам 40Мб/сек, так что указанные измерения не неожиданность. Однако, более медленный контроллер подключенный к двум быстрым дискам будет бутылочным горлышком. Также заметьте, что большинство внешних SCSI подключений (таких как секции с лотками горячей замены) не могут работать на 40Мб/сек, из-за проблем с кабелями и электрических шумов.
Если Вы разрабатываете систему с несколькими контроллерами, помните, что большинство дисков и контроллеров в среднем работает на 70-85% их максимальной скорости.
Также заметьте, что использование одного контроллера на диск может, по всей вероятности, уменьшить простой системы из-за отказа контроллера или кабеля (теоретически -- только в случае правильной обработки драйвером отказа контроллера. Не все драйвера SCSI представляются способными обрабатывать эту ситуацию без паники или иных блокировок).
