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 и размера – в большую сторону – подмена, конечно, неизбежна – на время.
НО результат меня вполне порадовал: при тестировании с помощью