Можно ли добавить диск в существующий массив RAID-5 на Windows Server 2012 R2?

Я всей истории не знаю. Насколько мне известно, аппаратный рейд-контроллер с массивом не дал в итоге запуститься винде. Сервер на базе Supermicro. Я тоже несколько удивлен, но задачку подкинули с такими вводными :) потому и вопрос такой.

Значит остается только копирование всего на вне, ломать массив и делать заново?

Роман Екимов: Да. Только ломать.
Но просто подумайте для чего вам вообще нужен RAID5?
Его сейчас не выгодно даже на аппаратном контроллере поднимать в большинстве случаев.

Рэйд используется в двух случаях - либо для повышения скорости дисковой системы, либо для обеспечения бесперебойной работы.

Бесперебойную работу отлично обеспечивает банальное зеркало - RAID1
А если нужна скорость, то ставят SSD. Ибо никакой рэйд даже близко не даст таких скоростей как SSD.

Конечно бывают исключения когда надо получить большую линейную скорость, там бывает обоснованным поставить SSD в десятый рэйд, но это крайне редко.

А программный RAID5 это вообще жесть - скорость уменьшается по сравнению с одиночным диском, надежность низкая, нагрузка на процессор огромная.

АртемЪ: Там тупо хранятся файлики (файлопомойка). Но приходится иметь дело с тем, что есть :) Моя текущая задачка изучить данный вопрос. Спасибо за разумные доводы, пригодятся.

АртемЪ: SSD по сравнению с RAIS дает IOPS до определенного количества дисков в рейде, но никак его не заменяет в плане скорости и уж точно намного дороже по деньгам, вы же не домашние SSD в сервер вставляете :)

Какая разница домашние, не домашние?
Если SSD серверные, то сравнивать надо с серверными HDD.
Так что по деньгам не намного дороже, а в большинстве случаев дешевле.

АртемЪ , Роман Екимов: На самом деле это интересная тема, и, если копнуть глубже, не всё в ней так однозначно. По крайней мере по моему опыту RAID5 (реже — RAID6) целесообразно использовать, как минимум, в трёх довольно конкретных случаях.

1. Когда всё равно есть ПОЛНЫЙ бэкап, отвязанный от массива, и нужно лишь обеспечить бесперебойность работы рабочего хранилища во время прогнозируемых отказов отдельных накопителей, потому что восстанавливать из бэкапа — медленно, а тупо удваивать количество дисков (а заодно шум, энергопотребление, место и другие связанные расходы) — дорого и неэффективно. Тем более, что это не отменяет времени на перестройку массива и простоя в случае смерти контроллера или другого компонента хранилища. Этот подход использовался как минимум в одной из серверных комнат компаний, где я работал.

2. Когда у организации есть потенциально ценные данные, и их СЛИШКОМ много для ПОЛНОГО бэкапа или зеркала, НО:
а) их ценность условна/неопределена/неоднозначна — например, это разного рода некоммерческие данные, архивные копии, файлопомойки, медиаисходники в высоком разрешении, разнообразные логи, записи систем видеонаблюдения и т. п. — то есть они, с одной стороны, МОГУТ пригодиться в неких крайних случаях, а с другой — их потеря в большинстве случаев некритична, потому что данные или уже «сыграли», или неликвидны в принципе, или стоимость их повторного получения сопоставима со стоимостью получения/хранения полного бэкапа;
б) существует второй слой избыточности/отказоустойчивости (как минимум, для наиболее чувствительных данных) на программном/архитектурном уровне — например, посредством MogileFS или другой распределённой файловой системы, на основе которой можно сделать масштабируемое облако из почти любого подручного железа.

Благодаря тому, что с таким подходом можно очень органично прикрутить к хранилищу балансировщик, рудиментарный CDN или хотя бы простой кеш, он довольно широко (как мне известно) использовался / используется / может использоваться для сервисов доставки мультимедийного контента — IPTV, Video-on-Demand, всяких веб-радио, магазинов цифровой музыки и пр. (ведь нет смысла переплачивать за хранение того, на что ты только покупаешь права), а также разнообразных сервисов веб-2.0, как минимум, на этапе их становления (например, MogileFS изначально создавалась под LiveJournal и первые пару лет сервис исправно работал на помоечном железе) и даже телеканалов узкого/сетевого вещания — например, именно так был устроен Коммерсантъ-ТВ (другая компания, в которой я работал, разрабатывала платформу онлайн-вещания, которую адаптировала, в частности, под Ъ-ТВ).

Поскольку с чисто архитектурной точки зрения у этого подхода не существует какой-либо привязки к объёму, классу, стоимости или производительности железа, его можно бесшовно масштабировать с первого дня и до пика развития аппаратного парка; более того, с ним упрощается обеспечение пространственной (location-aware) отказоустойчивости — можно разнести узлы хранилища и, соответственно, хранимые на них копии по разным комнатам, корпусам, городам и т. п.; файлы, которым требуется избыточность, копируются в соответствии с установленными политиками — например, на наименее загруженные узлы на определённой дистанции от исходного. В произвольный момент времени наиболее востребованная инфа всё равно скармливается из кеша (или цепочки кешей), который сам по себе — кратковременная избыточная копия, в то время как остальные узлы размеренно передают друг другу данные, не забивая каналы — примерно так же, как постепенно восстанавливается повреждённый массив после замены отказавшего диска.

В этом случае RAID5/RAID6 становится лишь относительно небольшой (но всё равно важной) частью общей системы отказоустойчивости на уровне отдельных аппаратных узлов общего хранилища. Когда речь идёт об объёмах данных, которые исчисляются петабайтами и экзабайтами — ОСОБЕННО если это некоммерческие данные! — такой подход к их хранению чаще всего и есть наиболее оправданный, потому что поддерживать АППАРАТНУЮ избыточность в 100% и более для таких объёмов крайне дорого, но, с другой стороны, всё равно либо не абсолютно надёжно (если вторая/третья копия не находится где-то в другой стране, например) — а то и вовсе бессмысленно. Ну вот вспыхнет у тебя в серверной пожар — сильно поможет бэкап, который торчит в соседней стойке? Таким образом, сочетание RAID5/RAID6 с грамотной облачной архитектурой может достичь эффективной избыточности в 120–150% для актуальных данных (≥20% для наименее актуальных) при средней фактической избыточности всего в 30–50%. Финансовые затраты в таком случае либо сопоставимы с объёмом фактической избыточности, либо ещё ниже — благодаря гибкости и масштабируемости используемых аппаратных средств (можно использовать компоненты потребительского класса, можно арендовать помещения или места в стойках там, где выгоднее, а не только в самых лучших/дорогих местах, и т. п.). Либо, если уж совсем приспичило, можно достичь эффективной избыточности в 300–400% при средней фактической в районе ≤150% — всей инфы будет как минимум по две копии, а самой важной — 4–5 копий, и каждая — в отдельном месте.

3. Как наиболее экономически эффективный способ нарастить отказоустойчивость данных только-для-чтения для бытовых и низкобюджетных нужд. Вот есть у вас, например, домашний медиасервер на 6 ТБ, состоящий из трёх дисков по 2 ТБ каждый — довольно обычная ситуация для тех, кто не любит слушать музыку и смотреть кино через уютный вконтактик. Если один из дисков откажет, восстановление данных потребует либо значительных денежных затрат (если оно вообще осуществимо), либо сопоставимых по стоимости затрат времени на поиск и загрузку/переписывание нужных данных.

Переписать содержимое такого архива целиком на болванки BD-R сегодня обойдётся в 20+ тысяч, не считая стоимости самого привода; на внешние ЖД — в 15+ тысяч (но срок их годности будет ниже). Для устройства RAID5 же понадобится ещё один диск на 2 ТБ за 5–5,5 тысяч или дешевле.

Во-первых, такой подход даёт возможность относиться к самим дискам как к расходному материалу и не покупать их по полной цене (всё равно диски очень часто умирают в первые два месяца), что значительно сокращает издержки при отказах. Во-вторых, один дополнительный диск стоит заведомо дешевле, чем даже однократное восстановление инфы в лаборатории, а на весь массив он покупается один раз и действует столько, сколько живёт сам сервер. В-третьих, даже софтовый или привязанный к контроллеру материнки RAID заведомо надёжнее, чем полное его отсутствие, потому что срок жизни и материнки, и операционной системы в медиасервере или любой подобной низконагруженной системе — в 2–3 раза дольше, чем у современного жёсткого диска. А запись в массив осуществляется достаточно редко, чтобы потеря скорости не напрягала.

Если относиться к такому подходу благоразумно и не использовать его как бэкап для всего ценного, что только есть, то выгоды будет куда больше, чем издержек. Именно так поступаю я у себя дома; за последние пять лет диски на 1 ТБ вылетали из массива медиасервера дважды с перерывом в полгода — замену им покупал с рук; потенциальный апгрейд в конце этого года собираюсь устраивать подобным образом.

В каких случаях однозначно не имеет смысла использовать RAID5/RAID6?

1. Когда бюджет позволяет построить RAID1/RAID10 без особого ущерба.
2. Когда у тебя на машине идёт постоянная (преимущественно последовательная) запись.
3. Когда это высоконагруженный рабочий сервер/станция, а не просто хранилище.
4. Когда проще и/или дешевле отобрать РЕАЛЬНО необходимые файлы и бэкапить только их — но нормально.

Вопрос может уже давно не актуален, но я думаю нужен лишь для того, чтоб увеличить место. Это считаю самое полезное от него. Т.к. если будет сбой то восстановление не очень то и простое будет, я имею ввиду сбой ОС которая создавала этот массив. А если железка то тоже думаю приятного будет мало.