Хочу описать один интересный момент касательно нами любимых массовов RAID.
Как правило большинству известно, что рэйды существуют железные (хард-рэйд) и софтверные (софт-рэйд). И многие считают, что хард-рэйд это когда установлен железный дополнительный контроллер рэйда отдельной платой, а софт-рэйд это когда такого контроллера не установлено и обсчёт логики рэйда производит какой либо софт на центральном процессоре.
Исходя из собственного опыта я взглянул на этот вопрос немного с другой стороны.
Для начала, при построении массива, необходимо где то хранить информацию о его конфигурации.
Для упрощения рассмотрим ситуацию с RAID-1 (зеркалом).
Существуют реализации, хранящие служебную информацию на дисках и за их пределами.
Если служебка хранится на дисках, то вытащив один диск из зеркала и подключив его к отдельному компу, можно увидеть что угодно - от полностью не читаемого диска до одного или нескольких логических дисков самых неожиданных форматов.
Если же служебка не хранится на дисках, то проделав то же самое, можно лицезреть ту структуру, которую мы создавали на массиве.
Яркий пример - nas4free - операционка на freebsd для построения сетевых хранилищ, реализует второй случай.
Пример первого варианта - большинство дисковых корзин в серверах HP и, если мне не изменяет память, операционка NexentaStor.
За этим вполне простым нюансом хранится много различных слухов о выборе контроллера для нового сервера или на замену сгоревшему.
Не трудно догадаться, что для второго случая нам нужен контроллер или операционка такого же типа, не хранящие служебку на дисках. Тогда они без труда "соберут" из наших дисков развалившееся зеркало.
Если же служебка сохранена на диске то принципиальное значение имеет её формат. И если различные контроллеры или операционки, хранящие служебку на дисках, используют разные форматы, то они не смогут прочитать "чужие" диски и "собрать" чужие массивы.
Где же может храниться служебная информация о массивах, кроме как на дисках?
В случае физического контроллера - это собственная флэш-память этого контроллера.
В случае операционки nas4free - конфигурационные файлы этой операционки, лежащие на том диске, на который она установлена.
Вроде бы всё просто.
До этого момента нам было не важно, что реализует логику нашего массива - физический контроллер или некий софт.
Теперь давайте перейдём к вопросу о том, что обсчитывает логику наших массивов.
В случае физического контроллера - это размещённый на самом контроллере математический процессор.
В случае любой операционки - это центральный процессор нашего сервера.
В случае рэйд-контроллера, интегрированного в материнку - это опять же, наш ЦП.
И вот здесь начинается самое интересное. Те, кто делят рэйды на хардовые и софтовые по тому, обсчитывается ли их логика на основном ЦП, относят такой рэйд к софтовому. А те, кто делят рэйды по тому, чем эта логика реализуется, относят его к хардовому, поскольку она реализуется отдельным контроллером, хоть и размещённом на материнке.
Первые аргументируют это нагрузкой на ЦП. Но так ли это важно?
Да, при обсчёте логики массива на ЦП, он будет иметь дополнительную нагрузку, особенно при восстановлении одного из дисков массива RAID-5, но в случае nas4free никакой другой нагрузки на данном сервере и быть не должно.
И согласитесь, было бы странно поднимать массив RAID-5 на интегрированном в мать контроллере, ставить поверх винду и в момент пересчёта массива играть на нём в какую нибудь игру, отличную от пасьянса? Это скорее исключение. И строить классификацию рэйдов на исключениях наверное не стоит.
Вторые акцентируют внимание на контроллерах, имея ввиду производительность. Действительно, хороший дорогой серверный рэйд-контроллер и по надёжности и по производительности сильно превосходит интегрированный в мать, но этот выбор делается в зависимости от задачи. Нужен ли вам дорогой контроллер, когда узел на обычном ПК класса пентиум-4 и ОС nas4free без проблем справляется с любой конфигурацией рэйд из 6 дисков, упираясь в производительность дисков и сети? Думаю нет, если функции узла - файлопомойка или iscsi-target для размещения 4-5 виртуалок. Лично я размещал на такие хосты до 8 виртуалок на единственном LUN-е зеркального массива.
А топовые хранилища от EMC основаны на собственной ОС, а не на физических рэйд-контроллерах.
Какой из всего вышесказанного можно сделать вывод?
Деление рэйдов на хардовые и софтверные оказалось не столь однозначным, как казалось.
Существует мнение, что делить надо по наличию или отсутствию отдельного контроллера и как следствие реализацией им логики рэйда. Все реализации ОС попадают в категорию софт. Интегрированный в мать контроллер попадает в категорию хард.
Также существует мнение, что делить надо по тому, обсчитывает ли логику рэйда ЦП или нет. Все реализации ОС и контроллер, интегрированный в мать попадают в категорию софт.
Я же предлагаю ещё один метод деления - по хранению служебной информации на дисках (и как следствие, внесении изменений в структуру логических дисков) или нет. При таком делении и хардовым и софтовым рэйдом могут оказаться и отдельные рэйд-контроллеры, и интегрированные контроллеры, и все программные реализации.
Какой в этом смысл? Для начала, зная тип используемого рэйда, можно упростить выбор замены на случай необходимости собирать наш массив на другом оборудовании.
Лично для меня большим плюсом является сохранения структуры на диске неизменной - это позволяет при необходимости быстро получить доступ к данным имея на руках один диск из зеркала.
Ну и на последок замечу, что это всего лишь моё личное рассуждение на эту тему. Основная цель - дать пищу для размышлений. Возможно мой взгляд на soft-raid подтолкнёт кого то к написанию дополнения или продолжения, а может и собственного взгляда на soft-raid.