RAID. Немного теории построения. Или…

… почему нельзя сочетать несочетаемое.

Иногда, при постороении очередного RAID-массива возникает неочевидный, как выяснилось, вопрос – можно ли использовать в одной RAID-группе диски с разной скоростью вращения дисков? Ответ, который для меня однозначно очевиден – НЕТ, нельзя. Попробую ниже изложить соображения, почему именно – нельзя.

Как пример ниже – я говорю про диски Fiber Channel 10K и 15K. Все сказанное однозначно подходит и для случая с SATA дисками, например (ну или SAS, или даже IDE). SSD не имеет прямого отношения к нашему разговору – НО к нему это тоже можно применить (да, да – и там есть ньюансы – “быстро” – не всегда однозначно хорошо)…

Решил подытожить. Никаких пруфов и ссылок не будет – эти вещи – происходящие от природы построения RAID-массивов, достаточно просто почитать просто описания вида “что такое RAID” в интернетах, ну и нам, как специалистам, глянуть документацию на конкретные чипы/реализации.

Вводная и немного терминов – прилагается.

Все довольно банально. RPM (обороты в минуту) – 10K/15K – это величина, от которой зависят внутренняя скорость переноса данных (internal data transfer speed, измеряется в мегабитах), время доступа (access time, измеряется в миллисекундах).

Чем выше обороты, тем выше внутренняя скорость передачи данных, тем ниже время доступа (время доступа).

А теперь – про наших “баранов”.

Рассмотрим зеркало: RAID1, два диска, 10K+15K. В общем случае – никаких проблем – работаем по медленному диску. Совсем плохо будет чуть ниже.

Рассмотрим ЛЮБОЙ страйп: RAID10/RAID5/RAID6 и сочетания. В общем случае продолжаем работать по более медленному диску. С рядом существенных оговорок. В случае со страйпом запись идет на всю “полоску”, состоящую из искомого количества дисков. В результате, при работе по медленному диску, наши быстрые диски будут постоянно “перелетать” через данные, совершая больше “пустых” (холостых оборотов). Поясню – каждое чтение – чтение всей полоски (случай с деградацией RAID5 я даже рассматривать не буду – все будет исключительно весело). Идем дальше – каждый “перелет” будет порождать увеличение времени доступа. Чем больше дисков – тем больше “перелетов” (пропорционально количеству дисков). Что имеем в результате – непредсказуемую деградацию производительности при чтении на страйпе. Которая в результате (в случае с ОС Solaris) будет приводить, во-первых, к непредсказуемому и слабо коллерируемому с нагрузкой параметров asvc_t/wsvc_t (команда iostat), ну и параметра r/s, w/s, Mr/s, Mw/s того же iostat. Во-вторых, из более далеко идущих последствий – снижается надежность всей дисковой подсистемы, причем прямопропорционально количеству медленных дисков внутри RAID группы – медленные диски могут (и будут!) содержать данные о, например, четности с других, более быстрых, своих соседей по группе (в случае с RAID-5). Тем самым – мы СУЩЕСТВЕННО увеличиваем нагрузку на наши более медленные диски, и, как ни странно, УВЕЛИЧИВАЕМ нагрузку в пересчете на количество обработанных (считанных/записанных) данных на наших более быстрых дисках в соотношении перенесенных данных к кол-ву совершенных оборотов – наш быстрый диск будет делать слишком много холостых оборотов, образно говоря, ничего не делая, а в нужный момент – тратя много времени на поиск искомых данных.

Вернемся к “простому” случаю: зеркалу RAID1. Образно – у нас вроде как все хорошо, работаем по медленному. Скажем прямо – не совсем. В обшем случае работает балансировка нагрузки – контроллеры нынче умные пошли
– читаем попеременно с обеих половинок зеркал. Если быстренько подумать – и рассмотреть ситуацию, близкую к пиковой нагрузке нашей пары дисков – мы получим в результате совсем нелицеприятную картину – нелинейную передачу данных и абсолютно бесподобную картину времени доступа.

Я могу еще немного подумать (нехарактерное занятие, ага) – и привести еще ряд примеров, почему не стоит использовать микшированные конфигурации.

Если после этих измышлений еще есть желание рекомендовать заказчику микшировать 10-ки и 15-ки – wellcome, я все-таки не умею писать по русски 😉 А если серъезно – в длительной перспективе, рассматривая реальную пользовательскую нагрузку, а не сфеерических коней в вакууме и одним байтом записи в час на запись и 2-мя – на чтение – мы легко просматриваем слабо предсказуемое изменение (в ХУДШУЮ сторону) производительности, это раз, существенное и легко прогнозируемое снижение производительности в случае выхода из строя диска в RAID5 группе, и – общее снижение надежности системы в целом в длинной перспективе эксплуатации.

Если же Вы все-таки изъявляете желание перейти на микшированную – тестирование, тестирование и еще раз тестирование. Я готов допустить, что на дисковой подсистемы с приложением, для которого нормальные и приемлимые значения asvc_t – 10-20 ms, transfer rate – не более 50-100 Mb/s, на машине, которая в состоянии отдать много больше – например, таже 6180 в полной “набивке” – конфигурация с микшированием – допустима и приемлима. Только есть опасение, что ВСЕ варианты, возможные на площадки, оттестировать все равно не получиться – и мы получим очень неприятные последствия в САМЫЙ неподходящий момент.

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

4 thoughts on “RAID. Немного теории построения. Или…”

  1. Vadim says:

    Я на самом деле иногда отдаю для временной замены 15k диски 10k и наоборот – с информированного согласия, конечно. Вынужденно отдаю – правильные диски иногда проходят таможню по два месяца. Деградация проявляется, но, похоже, не так ярко выраженная для ненагруженных фс, типа /.

    Поэтому, когда выбор стоит между жить на одном диске пару месяцев и жить с двумя даже с серьезной деградацией – 4 из 5 заказчиков выбирают второе.

    1. О, Вадим, привет 🙂 В РнД еще тепло – +7, давай к нам! 🙂

      Да, root – то самое место, где смешение, на мой взгляд, и не окажет значимого воздейтствия – потому как – зеркало из пары дисков. Да и в случае с простыми ФС – количество прослоек минимально – в лучшем случае – диск – простой контроллер – программный RAID/mirror, в худшем – контроллер берет на себя зеркала (задача не сильно усложняется). Тем не менее – я все-таки полагаю, что выбор между 10к и 15к идет без оценки всех возможных последствий, которых может и не быть 😉

      ИМХО, САМЫЕ занимательные эффекты полезут только при использовании критически нагруженных дисковых подсистем – в моменты “вымывания” кешей, в моменты достижения “потолка” по IOPS на записи… В целом, пост лишь о том, что не стоит придумывать себе проблемы на ровном месте – еще на этапе планирования системы (ага, есть и такие товарищи – сам знаешь, кому я это говорю 🙂 ).

  2. Andrey says:

    Не убедил 🙂
    Странно что на этапе проэктирования системы вообще может возникнуть желание микшировать диски – обычно это случается уже по факту, когда нужно было вчера.
    Здравый смысл посказывает что Raid будет упираться в скорость самого медленного диска.

    Каким образом диск 15К замедлит Raid-5 из 10к дисков? (допустим кэши одинаковые)?

    1. Оо 🙂 Андрюха! 🙂

      Ты знаешь, я тоже удивился, когда увидел такое “щастье” в виде проекта 🙁 Отсюда и запись.

      1 диск 15К – среди 10К дисков – подумаю, как бы получше ответить. Видится мне, что влияния и не будет (видимого). Наоборот – вырастут ожидания, упадет data transfer.

Leave a Reply