Насколько умны RAID-контроллеры, когда они находятся под нагрузкой?
Учитывая контроллер и шкаф среднего и высокого уровня (например, текущий стандартный комплект Dell или HP, готовый к использованию ...), RAID 5, оптоволокно 10 ГБ, не менее 3/4 используемого пространства и множество небольших не последовательный с тяжелым смешанным доступом для чтения / записи к файлам, например, на файловом или почтовом сервере ...
Вопрос практической реализации: Учитывая тот же объем места, что было бы быстрее, небольшое количество больших высокоскоростных дисков (например, 4x 1 ТБ 15 000 об / мин) или большее количество меньших, умеренных или низкоскоростных дисков (например, 9x 500 ГБ 7200 или 10 000 об / мин) диски?
Теоретический вопрос: Знают ли шкафы / контроллеры RAID, где в настоящее время находится головка диска и где им нужно искать, чтобы они могли назначать чтение диску с наименьшим расстоянием между головками? Или это важно?
Какие еще переменные важны для минимизации времени отклика и максимального увеличения пропускной способности при большом количестве непоследовательных небольших файлов в общем массиве хранения? Обратите внимание, что кеш не так сильно играет роль из-за природы данных.
Из вашего описания ваша рабочая нагрузка будет в значительной степени иметь произвольный доступ, поэтому ограничивающим фактором являются произвольные операции ввода-вывода в секунду. На RAID-5 вы получите (на практике) чуть меньше одного чтения или записи ввода-вывода за один оборот диска на физический шпиндель. В этой ситуации больше физических дисков и более высокая скорость вращения означает большую пропускную способность.
В случае сильно случайного ввода-вывода, когда рабочий набор запросов данных переполняет кэш, пропускная способность системы является функцией количества физических дисков x скорости диска. Чем больше дисков, тем лучше, чем быстрее, тем лучше.
Что касается вашего теоретического вопроса, диски поддерживают функцию, известную как 'помеченная очередь команд'. Это позволяет контроллеру отправлять запросы ввода-вывода дискам и получать запросы асинхронно. Внутренняя плата на диске является осведомлен о положении головок диска и может оптимизировать операции, выполняя их в оптимальном порядке. Алгоритм для этого есть вариант на 'Лифт в поисках'
Результаты могут быть возвращены не по порядку, но они помечаются номером запроса, чтобы RAID-контроллер знал, на какой запрос должен соответствовать ответ (отсюда и «помеченный»). SATA имеет немного другой протокол, известный как 'собственная очередь команд'это делает нечто подобное.
В этом случае RAID-контроллер не должен знать о физическом положении головок диска, так как этим управляет прошивка самого диска.
При большой нагрузке произвольного доступа одна пара петель FC будет поддерживать довольно много дисков. Для потоковых рабочих нагрузок, таких как видео, FC быстрее станет узким местом.
Некоторые контроллеры могут поддерживать впечатляюще большие размеры кэша. Вы можете попробовать оценить размер рабочего набора и посмотреть, действительно ли вы можете обновить кеш вашего контроллера, чтобы разместить его. Если у вас есть опыт работы со статистикой, вы можете построить модель Монте-Карло на основе статистики использования, собранной из запросов.
Другой возможностью повышения производительности может быть использование слоя твердотельных дисков для быстрого хранения, хотя это зависит от того, поддерживает ли ваш контроллер эту конфигурацию.
IOPS, IOPS и IOPS. Это то, что вам нужно учитывать. Вы можете получить больше операций ввода-вывода в секунду за счет более быстрого вращения диска. В качестве альтернативы вы можете получить больше операций ввода-вывода в секунду за счет большего количества шпинделей.
Есть хороший сравнительный статья Adaptec это отвечает почти на тот же вопрос.
Если у вас есть какие-то диски (например, от конкретного производителя), вы можете запустить математику.
В настоящее время нет дисков 1 ТБ со скоростью 15 оборотов в минуту, так что это в лучшем случае теоретически, но у нас есть аналогичные сценарии использования, и для системы среднего уровня, такой как вы смотрите, я настоятельно рекомендую использовать 2,5-дюймовые диски SFF SAS, в идеале со скоростью 15 оборотов в минуту. Массив приличного размера не очень дорог и очень быстр для последовательного трафика и чрезвычайно быстр для случайного. Обратите внимание на HP MSA 70.
Я провел множество тестов на серверах Dell с контроллерами Perc5 / i и 6 / i. Мы перепродаем Dell, и я редко могу устоять перед соблазном протестировать их на скорость всякий раз, когда новый сервер или новая конфигурация диска проходит через наши двери. NB Я тестирую с помощью тестера дисков собственной разработки. Я не предъявляю особых претензий к своему тестеру, за исключением того, что опыт нескольких лет показывает, что он хорошо коррелирует со скоростью сервера, когда он находится на месте. Видеть http://ratsauce.sourceforge.net/index.html#diskthrasher за кровавые подробности.
Как бы то ни было, мой опыт показывает, что как минимум до шести дисков RAID5, каждый дополнительный диск дает полезное увеличение скорости. Я тестировал диски SAS 15K, а также диски SATA (Western Digital RE2 и RE3), и хотя диски SATA, очевидно, намного медленнее при произвольном доступе, RAID5 с шестью дисками SATA по крайней мере так же хорош, как четыре диска SAS 15K дисковый RAID5. Так что я бы выбрал более дешевые диски.
Ваш вопрос о позиционировании головы при чтении будет относиться только к RAID1 или RAID10, и я их больше не использую, поэтому не могу комментировать. Судя по моей немного тусклой памяти, RAID1 на Perc 4e / Di заметно быстрее, чем один диск, что предполагает некоторую выгоду. Однако разница была небольшой, возможно, увеличение скорости на 10-20%, и это могло быть просто связано с лучшим кэшированием на контроллере RAID.
Между прочим, если вы загрузите мое приложение diskthrasher, я добавлю множество результатов тестов из различных конфигураций диска.
JR
Как правило, ответ будет зависеть от рассматриваемой системы. Если вы хотите, чтобы система была быстрой, я обычно смотрю на IOP, на которые способен привод, и использую это для принятия решения. Однако я бы предпочел большое количество дисков, чем меньшее.
Есть ряд других вещей, которые можно сделать в Linux для повышения производительности.
Обычно головы в системе Raid должны быть синхронизированы в системе Raid5 / 6. Убедитесь, что ему не нужно читать область, прежде чем он сможет ее записать, сделав записи достаточно большими.
Я думаю есть просто путь слишком много переменных, чтобы их можно было здесь рассмотреть, чтобы сделать общее предложение. Сравнение количества приводов и их скоростей нецелесообразно, потому что другие факторы, такие как количество головок и пластин, также будут иметь значение, поэтому это также зависит от модели привода.
В идеале вам следует выбрать несколько различных моделей, которые соответствуют требованиям вашего приложения, и сравнить их друг с другом с учетом вашей реальной рабочей нагрузки, а затем купить ту, которая соответствует вашим требованиям.
Если вы помните, что большинство «больших» SAN имеют накладные расходы ~ 50%, конечный результат обычно довольно быстрый.
Самым большим из них является то, что внешние интерфейсы NAS (пока что за исключением NetApp) не могут обрабатывать серьезную нагрузку метаданных, так что будьте осторожны.
Теоретически рейдовые контроллеры могут знать последнее ожидаемое местоположение головы и использовать его при повторном заказе запросов (в конце концов, это традиционная часть алгоритмов лифтов), но в наши дни гигантские кеши RAM просто проще.