Comments 13
Задам практический вопрос, который меня весьма волнует — а есть ли в продаже хоть один дешевый рейд-контроллер, который позволит собрать raid 1, дающий выигрыш по скорости чтения, аналогичный raid 0?
У RAID 1 и RAID 0 разное назначение, их нельзя сравнивать. RAID 1 не предназначен для увеличения скорости, он предназначен для защиты данных (дублирование). RAID 0, в противоположность этому, абсолютно не предназначен для защиты (потому он и 0, т.е. как бы и не RAID совсем). Использовать RAID 1 и получить выигрыш в скорости нельзя по определению. Скорость массива будет равна скорости диска. Хотите получить выигрыш в скорости при RAID 1 — используйте RAID 10. Его обеспечивают все контроллеры, даже интегрированные.
Вот неплохая статья про выбор типа RAID.
Вот неплохая статья про выбор типа RAID.
Ну, извините, но все приличные системы на базе raid1/10 и т.д. позволяют читать с обоих копий, то есть многопоточное чтение с raid1 в среднем будет быстрее, чем с одинокого диска.
Да, извините, был не прав. Читать одновременно с нескольких дисков в массиве RAID 1 умеют многие. Во всяком случае все контроллеры Adaptec это умеют, единственное исключение — Hybrid RAID, когда данные считываются только с диска SSD. Вроде как Intel тоже давно добавил такую функцию в свои интегрированные контроллеры. Но официально эту особенность почему-то никто особо не афиширует.
Вы о каком выигрыше? На линейном чтении? Его не будет, т.к. если запросы идут последовательно, то они обслуживаются одним из дисков в массиве. Если речь про многопоточное чтение, то речь идёт про, фактически, большую глубину очереди (64 против 32).
Таки о линейном.
Я с трудом себе представляю последовательность операций на линейном чтении, которая должна повысить скорость чтения в случае использования raid1.
Точно можно говорить, что в пределах блока никто не будет ничего параллелить. Значит, возможно параллелить только при размерах больше блока, а это означает очень большие запросы, либо гигантская очередь, которую кто-то забивает readahead'ом.
Поясняю, почему никто не будет параллелить в пределах блока. Потому что представьте себе картинку:
диск А чуть более готов к операции чтения, диск Б чуть менее. Запрос делится на две части, и отсылается диску А и диску Б. Диск А выполняет запрос за 1мс (потому что головка над правильным треком), а диск Б — за 5 (потому что seek). Ответы объединяются и отдаются назад. Итоговое время операции — 5мс. А если бы запрос ушёл целиком на диск А, то он бы его выполнил за 2мс (потому что seek'а нет, а блоки терпимого размера).
Заметим, распараллеливая блоки мы, фактически, удваиваем нагрузку на диски под рейдом (iops'ов в два раза больше). Никто такого делать не будет. А, значит, параллелиться могут только блоки, а для того, чтобы получить большую скорость, нужно запросить несколько блоков за раз.
Точно можно говорить, что в пределах блока никто не будет ничего параллелить. Значит, возможно параллелить только при размерах больше блока, а это означает очень большие запросы, либо гигантская очередь, которую кто-то забивает readahead'ом.
Поясняю, почему никто не будет параллелить в пределах блока. Потому что представьте себе картинку:
диск А чуть более готов к операции чтения, диск Б чуть менее. Запрос делится на две части, и отсылается диску А и диску Б. Диск А выполняет запрос за 1мс (потому что головка над правильным треком), а диск Б — за 5 (потому что seek). Ответы объединяются и отдаются назад. Итоговое время операции — 5мс. А если бы запрос ушёл целиком на диск А, то он бы его выполнил за 2мс (потому что seek'а нет, а блоки терпимого размера).
Заметим, распараллеливая блоки мы, фактически, удваиваем нагрузку на диски под рейдом (iops'ов в два раза больше). Никто такого делать не будет. А, значит, параллелиться могут только блоки, а для того, чтобы получить большую скорость, нужно запросить несколько блоков за раз.
amarao, если речь идет о линейном чтении, то почти наверняка читаются объемы, гораздо большие, чем размер блока (например, пользовательский файл с офисной файлопомойки). В реальности помимо размера файла рост производительности очень сильно зависит от логики работы контроллера (какими порциями он разбивает входящий поток на зеркальные пары, насколько умеет отличать линейные потоки от рандомных).
Немножко пруфов, простите, что 5-летней давности, блоки массивов везде по 64 кБ, смотреть на RAID10, и размер блоков запросов на чтение:
— линейное чтение, глубина очереди — 4 запроса:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138933.png
— мультипоточное чтение, глубина очереди 1 запрос, размер блока запроса 64 кБ, стоит обратить внимание на скорость одного потока чтения:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138921.png
— ну и файлики погонять можно:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138904.png
— Другой вопрос, что предсказывать поведение контроллеров невозможно, да и востребованность всего этого в современном окружении невелика.
С уважением, SV
Немножко пруфов, простите, что 5-летней давности, блоки массивов везде по 64 кБ, смотреть на RAID10, и размер блоков запросов на чтение:
— линейное чтение, глубина очереди — 4 запроса:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138933.png
— мультипоточное чтение, глубина очереди 1 запрос, размер блока запроса 64 кБ, стоит обратить внимание на скорость одного потока чтения:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138921.png
— ну и файлики погонять можно:
img.fcenter.ru/imgmat/article/hdd/Areca_ARC_1680ix_16/138904.png
— Другой вопрос, что предсказывать поведение контроллеров невозможно, да и востребованность всего этого в современном окружении невелика.
С уважением, SV
График линейного чтения заставляет плакать. Почему 8 дисков не отличаются от 4? Уж не боттлнек ли это в районе enclosure?
С другой стороны, тесты на виндах, да ещё поверх файловой системы. Винды чёрный ящик, что там происходит внутри никто сказать не может.
С другой стороны, тесты на виндах, да ещё поверх файловой системы. Винды чёрный ящик, что там происходит внутри никто сказать не может.
8 дисков сливающихся с 4-мя — это RAID10 из 8 дисков в degraded mode (с вытащенным одним диском) и RAID0 из четырех. Вполне логичное поведение. Enclosure нет как явления — 8 дисков висят напрямую на контроллере.
А вообще это 5 лет назад, контроллеры тогда только начали получать мощные процессоры и 800 МБ/с для большинства были в принципе максимумом пропускной способности. Поводов для слез и без того хватало: таких или таких. Сейчас, в целом, поведение контроллеров лучше, но все равно «сперва проверь, а потом ставь в работу» (а почитать и вовсе негде).
IOMeter, кстати, гонялся на дисках без файловой системы — потому что иначе винда вносила свои коррективы (никогда не забуду кого-то из журналистов, у которого на тестах записи все провалилось в кэш и он радостно отписал о полученных рекордах скорости).
А вообще это 5 лет назад, контроллеры тогда только начали получать мощные процессоры и 800 МБ/с для большинства были в принципе максимумом пропускной способности. Поводов для слез и без того хватало: таких или таких. Сейчас, в целом, поведение контроллеров лучше, но все равно «сперва проверь, а потом ставь в работу» (а почитать и вовсе негде).
IOMeter, кстати, гонялся на дисках без файловой системы — потому что иначе винда вносила свои коррективы (никогда не забуду кого-то из журналистов, у которого на тестах записи все провалилось в кэш и он радостно отписал о полученных рекордах скорости).
Я как-то в какой-то очень умной статье с кучей фамилий и двухколоночной вёрсткой про производительность кластерной фс, как-то наблюдал запуск dd без флага iflag/oflag=direct. Причём люди учёные, для измерения производительности запускали один и тот же тест цать раз подряд и высчитывали девиацию и погрешность. Лица на пальмы не хватает.
UFO just landed and posted this here
Подскажите, а Adaptec случайно не делилась структурой метаданных, которые они хранят на дисках?
Sign up to leave a comment.
Современные RAID контроллеры Adaptec от А до Я. Часть 1