Какой рейд сделать из 4 дисков
Небольшая вводная:
Рассматривать мы будем простейшие случаи — RAID10 из 4-х дисков и RAID5 из 3-х дисков. Все диски в системе примем одинаковыми.
В первоначальной версии статьи вместо RAID10 упоминался RAID0+1, но это вносит лишнюю путаницу. Корректное название конечно же RAID10 — сыплю голову пеплом.
Пусть n — вероятность отказа одного диска;
Итак — RAID10:
Кол-во дисков в массиве — 4;
Цена массива равна стоимости четырёх дисков;
Ёмкость массива будет равна удвоенной ёмкости используемых дисков (одного диска);
Максимальная скорость чтения данных равна удвоенной скорости одного диска;
Вероятность отказа массива для самого лучшего случая (когда контроллер реализует RAID1+0 как единую матрицу и умеет комбинировать накопители произвольным образом):
Вероятность отказа одного диска: P1=n(1-n)^3;
Вероятность отказа двух дисков: P2=(n^2)*(1-n)^2;
Вероятность отказа трёх дисков: P3=(n^3)*(1-n);
Вероятность отказа четырёх дисков: P4=n^4;
Вероятность безотказной работы: P0=(1-n)^4;
Полная вероятность: 4*P1+6*P2+4*P3+P4+P0=1;
Вероятность отказа массива: P(RAID10)=2*P2+4*P3+P4;
* В первом слагаемом вместо 6 стоит 2, так как только в двух случаях (при повреждении дисков с одинаковыми ыми данными) массив не может быть восстановлен.
Отдельно замечу, что большинство контроллеров не умеют комбинировать накопители, а значит отказ двух любых накопителей ведёт к потере данных, и надёжность массива в целом получается значительно ниже.
RAID5:
Кол-во дисков в массиве — 3;
Цена массива равно стоимости трёх дисков;
Ёмкость массива равна ёмкости двух дисков;
максимальная скорость чтения равна полуторной скорости чтения одного диска;
Вероятность отказа массива равна вероятности отказа двух дисков в нём:
Вероятность отказа одного диска: P1=n(1-n)^2;
Вероятность отказа двух дисков: P2=(n^2)*(1-n);
Вероятность отказа трёх дисков: P3=n^3;
Вероятность безотказной работы: P0=(1-n)^3;
Полная вероятность: 3*P1+3*P2+P3+P0=1;
Вероятность отказа массива: P(RAID5)=3*P2+P3;
Выводы:
Начнём конечно же с вероятности отказа — отнимем вероятность отказа RAID5 от вероятности отказа RAID10:
P(RAID10)-P(RAID5)=2n^2*(n-1)^2-n^3+n^4+3*n^2*(n-1)-4*n^3*(n-1)
Учитывая, что n->0 P(RAID10)-P(RAID5) Если же допустить, что накопители не могут комбинироваться произвольным образом, то RAID5 надёжнее.
Соотношение цен: RAID5 в 1.333 раза дешевле.
Соотношение скоростей: RAID5 в 1.333 раза медленнее чем RAID10, но при этом в полтора раза быстрее одиночного накопителя.
Внимание вопрос какой вариант лучше? Тот, который дороже и менее надёжен, хоть и немного быстрее. Или тот, что дешевле и надёжнее?
Лично моё мнение склоняется в сторону более надёжного и дешёвого RAID5 никуда не склоняется.
Дополнение:
В комментариях уважаемый track аргументировано указал, что в некоторых случаях RAID-5 может оказаться намного медленнее RAID1. По моему скромному мнению это должны быть очень и очень специфичные случаи, но иметь в виду следует.
Всякого рода замечания:
Время восстановления:
Восстановление RAID10 в идеале равно времени копирования всего объёма данных.
Для RAID5 ситуация сложнее, так как требуется восстановление данных по кодам коррекции.
При программной реализации время восстановления RAID5 будет определяться быстродействием процессора.
При аппаратной реализации время восстановления RAID5 равно времени восстановления RAID10.
Учитывая, что современные процессоры без проблем справляются с потоком данных порядка 100МБ/с (приблизительная пиковая скорость чтения современных накопителей) можно утверждать, что при правильной реализации программный RAID5 будет не намного медленнее RAID10.
Про надёжность во время восстановления. Для рассматриваемого случая об этого говорить вообще не приходится — резервные копии делать нужно! В общем же случае следует принимать во внимание, что на момент восстановления количество дисков в RAID10 больше, чем в RAID5, а значит вероятность отказа выше, и нельзя говорить о том, что на время восстановления RAID10 однозначно надёжнее.
Загрузка процессора:
Программная реализация RAID5 нагружает процессор. Для современных процессоров, это как правило не критично, но для быстрых накопителей нужно иметь в виду, что чем быстрее накопитель, тем сильнее нагрузка на процессор.
И снова надёжность — последний гвоздь в крышку гроба:
Почему-то при разговоре о RAID10 и особенно о RAID1 все упускают из вида один очень важный момент.
Да, в случае физического отказа накопителя он обеспечивет восстановление данных из копии, но что будет, если накопители вернут разные данные? Ведь в RAID1 нет способа узнать какие данные верны! Можно попытаться определить достоверность данных по их содержанию, но это не тривиальная задача, которая может быть выполнена только вручную, причём, далеко не всегда.
Именно по этой причине я вообще не рассматриваю здесь RAID1 — он не обеспечивает механизма контроля достоверности данных. И RAID10 в общем случае тоже.
А RAID5 (6?) в общем случае очень даже обеспечивает — если один из трёх накопителей вернёт неверные данные, то будет однозначно известно, что они не достоверны.
Как такое (недостоверность данных) может случиться?
Проблемы с перегревом дисков. Проблемы с питанием. Проблемы с прошивкой дисков. Масса вариантов! Вплоть до полного выгорания электроники в результате выхода их строя компьютерного источника питания. В таком случае диски можно попытаться оживить, поставив платы с аналогичных устройств, но не будет гарантии, что все данные на дисках достоверны.
И ещё один гвоздик туда же. В топике с которого всё началось много расписано про BER (bit error rates). Не вдаваясь в подробности лишь замечу что, во-первых, для жёстких дисков все же принято больше говорить о MTBF (mean time between failures), во-вторых, если и говорить о BER, то о UBER (uncorrectable bit error rates), а, в-третьих, это будет аргумент в пользу RAID5 — если накопители вернут искажённые данные (которые прошли через все процедуры коррекции), то как узнать какому накопителю верить?
Дополнение:
Вики говорит обратное — информация для восстановления не используется до тех пор, пока один из дисков не выйдет из строя. Жизненный опыт, правда, говорит иначе, но это было давно и я даже не помню на каком контроллере (возможно это был один нестандартных уровней RAID). Так что однозначно о достоверности данных можно говорить лишь для ZFS/RAID-6.
Вердикт:
Udpate2:
Вот так легко и не замысловато смысл статьи изменился если и не на противоположный, то уж точно кардинально.
Более того, скажем, RAID 0 из четырех дисков будет иметь не только учетверенную емкость, но и в 4 раза более высокую линейную скорость чтения-записи. А это уже 400-600 МБ/с, что единичному SSD той же цены даже не снилось! Таким образом, подобный массив будет работать гораздо быстрее SSD, по крайней мере, с потоковыми данными (чтение/запись/редактирование видео, копирование крупных файлов и мн. др.). Не исключено, что и в других типичных задачах персонального компьютера такой массив поведет себя отнюдь не хуже SSD — ведь процент последовательных операций в таких задачах весьма высок, да и случайные обращения, как правило, производятся на достаточно компактном участке такого емкого накопителя (файл подкачки, временный файл фоторедактора и пр.), то есть перемещение головок внутри этого участка будет происходить гораздо быстрее, чем в среднем по диску — за время в пару-тройку миллисекунд), что, безусловно, положительно скажется на его производительности. Если же многодисковый RAID-массив еще и кешируется в ОС, то от него можно ожидать внушительной скорости и на операциях с мелкими блоками данных.
Чтобы проверить наши предположения, мы протестировали четырехдисковые массивы RAID 0 и RAID 5 из терабайтных дисков Hitachi Deskstar E7K1000 со скоростью вращения 7200 об/мин и буфером 32 МБ. Да, они несколько медленнее по скорости пластин, чем более новые и продающиеся нынче по 1800-1900 руб./шт. накопители Hitachi 7K1000.C той же емкости. Однако их микропрограмма лучше оптимизирована для работы дисков в массивах, поэтому, несколько недобрав заветные 600 МБ/с по максимальной скорости чтения 4-дискового RAID 0, мы получим лучшую производительность в задачах с немалым количеством случайных обращений. А найденные нами закономерности можно будет распространить и на массивы из более быстрых (и емких) моделей дисков разных производителей.
Утилита Intel Matrix Storage Manager позволяет включать и отключать кеширование записи на такие дисковые массивы средствами операционной системы (то есть, используя оперативную память ПК), см. третью сверху строчку в правом поле Information на скриншоте:
Кеширование способно кардинально ускорить работу массивов с мелкими файлами и блоками данных, а также скорость записи на массив RAID 5 (что порой весьма критично). Поэтому мы для наглядности провели тесты с включенным и отключенным кешированием. Для справки мы также коснемся ниже вопросов нагрузки на процессор при включенном кешировании.
- процессор Intel Core 2 Duo E8400 (3 ГГц);
- 2 ГБ системной памяти DDR2-800;
- плата ASUS P5Q-E на чипсете Intel P45 Express с ICH10R;
- видеоускоритель AMD Radeon HD 5770.
Честь недорогого, но весьма производительного SSD емкостью 128 ГБ и ценой (на момент написания статьи) в районе 8000 руб. защищала модель PNY Optima SSD 128GB MLC. Сперва взглянем на нее чуть подробнее.
SSD PNY Optima 128GB Gen 2
Модель с номером P-SSD2S128GM-CT01 (прошивка 0309) представляет собой типичный 2,5-дюймовый SATA SSD в стильном черном металлическом корпусе толщиной 9,5 мм. Его производитель — компания PNY Technologies, больше известная своими флешками и модулями памяти.
PNY Optima SSD 128GB MLC
Накопитель основан на флеш-памяти Intel 29F64G08CAMDB с MLC-ячейками и контроллере JMicron JMF612, который позволяет этому SSD работать не только по Serial ATA, но и по интерфейсу USB 2.0 (мини-разъем последнего находится рядом с портом SATA в заднем торце корпуса диска).
То есть этот твердотельный накопитель можно использовать и в качестве ударостойкого переносного хранилища. Правда, USB-кабель комплектом поставки не предусмотрен. Зато и цену изделия никак нельзя назвать завышенной.
Плата накопителя PNY Optima SSD 128GB MLC
К слову, не следует заблуждаться и считать популярные MLC SSD на контроллере JMicron JMB612 решениями "низшего сорта". Как показывают многочисленные тесты, накопители на этом контроллере смотрятся в среднем ничуть не хуже, чем SSD сходной емкости и цены на контроллерах от Indilinx (IDX110), Intel, SandForce (SF1222) и Samsung, даже выигрывая у них в ряде дисковых бенчмарков.
Результаты тестов
Максимальная скорость последовательного чтения и записи полезных данных для SSD PNY Optima 128GB по результатам теста ATTO Disk Benchmark 2.41 (запись и чтение файла объемом 256 МБ блоками от 64 КБ до 8 МБ) составила соответственно 238 и 155 МБ/с, что чуть выше заявленных производителем значений (см. диаграмму).
Любопытно, что низкоуровневый тест HD Tach RW 3.0, использующий обращения к накопителю в обход файловой системы, показал для этих двух параметров значения в 217 и 165 МБ/с соответственно (см. график). Что же касается пары испытуемых нами четырехдисковых RAID-массивов, то RAID 0 показал максимальную скорость чтения/записи крупных файлов под 450 МБ/с (это подтверждается и графиком HD Tach RW 3.0), что вдвое-втрое больше, чем у данного SSD! Правда, включение кеширования записи (WC=yes на диаграммах) средствами Windows несколько снижает скорость последовательной записи, а также чтения, но не настолько критично, чтобы это можно было считать неприемлемым.
Другая существенная польза от Windows-кеширования массивов дисков — кардинальное ускорение работы с мелкими (менее 64 КБ) файлами и блоками данных. Это наглядно видно из результатов теста ATTO Disk Benchmark 2.41 (про вертикали слева здесь указан размер блока данных в КБ; колонки справа — значения скорости в КБ/с).
RAID 0 без кеширования
RAID 0 с кешированием
RAID 5 без кеширования
RAID 5 с кешированием
Как видно, при этом ускоряется работа не только при записи, но и при чтении. В общем, использование кеширования массивов в ОС является фактически непременным условием, если вы хотите получить на них хорошую производительность не только с потоковыми данными, но и во всем остальном (например, как системного диска).
Работу кеширования операций с RAID через оперативную память компьютера (причем как при чтении, так и при записи) наглядно демонстрирует следующая диаграмма, обычно приводимая нами в качестве иллюстрации скорости работы дискового интерфейса (SATA, SAS и пр.).
Скорость буферизованного чтения в 3-5 ГБ/с — это значения одного порядка с полосой пропускания системной памяти в ПК типа нашего тестового. Шина DMI, по которой южный мост интеловских чипсетов общается с системой, имеет куда более низкий потенциал, равный, по сути, шине PCI Express x4 первого поколения (то есть 1 ГБ/с в одном направлении). Второй полезный вывод из этой диаграммы — для RAID-массивов (даже без кеширования) скорость передачи данных по шине (нескольким шинам SATA) от хоста к накопителям возрастает условно пропорционально числу дисков в массиве. И для RAID 0, например, в разы превышает скорость обмена данными с одиночным SSD на шине SATA. Вывод, в общем-то, вполне очевидный.
Кстати, среднее время случайного доступа к массивам (мелкими блоками) при чтении не зависит от кеширования Windows, а вот при записи — меняется существенно (см. диаграмму). Причем, для простейшего (программного) RAID 5 без кеширования оно неприлично велико.
Что же касается вопроса дополнительной нагрузки на процессора от кеширования, то она, безусловно, есть, но для более ли менее современных десктопов ее нельзя назвать слишком обременительной. Взглянем на графики загрузки ЦП при выполнении того же теста ATTO:
RAID 0
RAID 5
Графики загрузки ЦП без кеширования RAID
И для RAID 0, и для RAID 5 загрузка ЦП при чтении и записи без RAID-кеширования Windows — единицы процентов. Если же кеширование включить, то на малых блоках загрузка ЦП возрастает до десятков процентов, порой переваливая за 50% (левые части графиков ниже).
RAID 0
RAID 5
Графики загрузки ЦП c кешированием RAID
Последнюю мы оценивали, в частности, по комплексным тестам, имитирующим работу разнообразных задач под Windows — PCMark Vantage, PCMark05 и Intel NAS Performance Toolkit. Детальные результаты по каждому паттерну этих тестов приведены в общей таблице. А в теле статьи мы представим только итоговые диаграммы, дающие представления об усредненной производительности накопителей под Windows.
В тесте PCMark05 данная модель SSD опережает 4-дисковый RAID 0 менее чем вдвое. Да, это заметное преимущество, но не такое фатальное, как при сравнении с одиночным винчестером. Любопытно, что достигается это преимущество лишь в трех из пяти паттернов PCMark05 (в основном — при запуске Windows и приложений), тогда как в паттерне Virus Scan наш RAID 0 оказывается на 10% быстрее, чем SSD, а в паттерне File Write — вообще быстрее, чем SSD, более чем втрое!
В более свежем тесте PCMark Vantage под Windows 7 преимущество SSD над нашими массивами подавляющее (в среднем минимум втрое). Очевидно, паттерны данного бенчмарка очень активно оперируют псевдослучайными обращениями к накопителям, в чем SSD вне конкуренции.
При детальном рассмотрении (см. табл.) оказывается, что в 10 из 12 паттернов кешируемый RAID 0 более быстр, чем SSD! Это касается и работы с видео, и Content Creation (создание контента), и офисной работы, и обработки фотографий (Photo Album), и копирования файлов. Лишь при 4-потоковом воспроизведении видео и копировании директории со многими файлами с диска твердотельный накопитель одержал вверх над RAID 0 из традиционных винчестеров. На этой оптимистичной ноте мы перейдем к заключению.
Заключение
И еще пару ремарок — относительно энергопотребления и надежности данных решений. Безусловно, 0,5-3 Вт потребления одного SSD не идут ни в какое сравнение с 20-40 Вт прожорливости массива из четырех НЖМД. Однако и мы ведь рассматриваем не ноутбук/неттоп, а полноценный десктоп (иначе, собственно, такой RAID и незачем городить). Поэтому потребление надо оценивать в сумме. А на фоне гораздо большей прожорливости типичных десктопных процессоров (100-200 Вт вместе с материнской платой) и видеокартой (50-300 Вт) еще пара десятков ватт на накопители совсем не кажется расточительством (только параноик станет считать лишние киловаттчасы от них на своем домашнем электросчетчике :)). Тем более если принять во внимание, что к SSD вам все равно придется докупать один-два НЖМД (для прикидки: 20Вт·8час·30дней=4,8кВт·ч, то есть максимум 15-20 дополнительных рублей на электричество в месяц). Что же касается надежности обоих решений, то и к SSD, и к RAID на чипсетных контроллерах, и даже к НЖМД в Сети можно найти многочисленные претензии, хотя производители и обещают для них миллионночасовые MTBF. Поэтому в любом случае, лучшей защитой от потери данных является их регулярное резервирование на независимых носителях. И об этом никогда не следует забывать.
На закуску — диаграмма, геометрически усредняющая производительность (в МБ/с) протестированных накопителей по всем 26 паттернам тестов PCMark05 (5 паттернов), PCMark Vantage x86 (7 паттернов), Intel NAS Performance Toolkit (12 паттернов) и чтения/записи крупных файлов в ATTO Disk Benchmark (2 паттерна). Смотрите и размышляйте. ;)
Приветствую!
Сразу скажу - по этим интернетам копался, ответа не нашел (может не прямолинейность ручных манипуляторов у меня обострилась).
Вопрос вот в чем. Есть, вернее был программный RAID 10, у него вышли из строя 2 диска из 4 (Причина кроется в SMART, но не в этом вопрос) Так вот как узнать выпавшие жесткие диски какое положение в данном RAID занимали?
отличная полная информация.. mdadm?
смотри lshw -C disk
ищи строки
physical id
serial
Спасибо за ответ!
Вывод:
0 и 1 это есть первое зеркало, 2 и 3 это есть второе зеркало?
ты понимаешь, что перед тобой?
это листинг информации о твоих дисках и физический id (их местоположение), на то и физически, ты же не /proc/mdstat смотришь.
Если хотите узнать о том, какие конкретно диски из массива отказали (sda,sdb. ), смотрите mdadm --query --detail /dev/md0 (подставьте имя своего массива), если хотите увидеть какой конкретно диск физически в какой интерфейс на mb включен, смотрите cat /proc/scsi/scsi
Может у меня от жары и злобнодышашего над ухом начальника пропала способность думать и четко излагать свои мысли.
Но, я физически-то знаю где-какой у меня жесткий диск, в какой порт он подключен и пр. информацию. Не понятно что - какой диск какую позицию в RAID занимает. Т.е. если мы видим physical id: 0, он подключен в первый порт на маме - тут все понятно без вопросов. А вот в RAID где он позиционируется?
Именно в этом то и вопрос. Допустим, physical id: 0 и physical id: 1 это одно зеркало, два остальных - это другое зеркало. Вот именно это и нужно узнать. Или же physical id: 0 и physical id: 2 это есть одно зеркало, а id:1 и id:3 то второе зеркало. Вот в чем соль.
И вам спасибо что не остались в стороне)
Какие диски отвалились выяснилось сразу. Вопрос в другом. см предыдущий комент.
Не верно понял ваш вопрос, тогда отсюда:
Используя это и вывод двух команд приведенных выше, я думаю, становится понятно как определить положение выпавшего диска в массиве. Смотрие Number и RaidDevice в выводе mdadm или число в [] в выводе cat /proc/mdstat за sda[], sbd[], узнаете порядок в котором собирались диски в массив и как в нем распределились. По-умолчанию используется layout n2, значит первые два диска (0,1 в выводе mdadm) будут первым зеркалом, вторые два (2,3) будут вторым.
Итого:
1. какой вариант nas для дома взять на итоговую емкость 30 Тб, чтобы при выходе хотя бы одного любого диска все не покрашилось в миг?
2. на мой взгляд, высока вероятность поломки не одного, а сразу двух дисков (они же в один момент покупаются, даже если куплю у разных поставщиков, партия производственная может быть одна). Какой вариант RAID брать чтобы не бояться краха 2 дисков в массиве?
- Вопрос задан более двух лет назад
- 3292 просмотра
какой вариант nas для дома взять на итоговую емкость 30 Тб, чтобы при выходе хотя бы одного любого диска все не покрашилось в миг?
NAS или RAID? Если NAS, то вы правильно выбрали Синолоджи, если RAID, то 5.
Нет, Вероятность этого варианта на порядки ниже, чем поломка одного.
RAID 6. Но вам "пятёрки" за глаза.
В конце концов, это сервер для бэкапов.
Вероятность выхода из строя двух дисков действительно существенно ниже вероятности выхода из строя одного, но ввиду того, что при ребилде массива идет повышенная нагрузка на диски, и учитывая объемы современных накопителей, вероятность того, что второй диск отвалится вскоре после первого (и до того, как ребилд будет завершен) довольна велика, из-за чего в последнее время приобретает популярность точка зрения, что при дисках емкостью более 3тб рейд5 уже не айс.
В любом случае, автору вопроса стоит задуматься о том, а на что он будет бэкапить то, что у него в рейде, и в каком объеме. Может статься, что при наличии бэкапа и рейд5 сойдет.
John Smith, ну я не думаю, что у автора будет такая жёсткая нагрузка на диски, что посыпется хотя бы один :)
Рональд Макдональд, нагрузка будет невысокой, это верно. Верно и то, что без "бекапа бекапа" и raid5, и raid6 все равно риск.
Я тут внезапно задумался о скорости записи на raid6, которая не высока совсем. Тоже надо иметь ввиду. Raid10, думаю, все же перебор для дома, так что пока raid6 побеждает.
Рональд Макдональд, диски - расходники, и дело не только и не столько в нагрузке.
Почитайте отчеты backblaze на досуге.
raid5 - это возможность без опаски потерять один диск
raid6 - возможность потерять два диска
Пример, почему имело бы смысл использовать 6 рейд - когда умирает один диск, вы покупаете ему замену и весь рейд начинает операцию rebuild, это очень длительная операция, она работает в idle, т.е. не должна заметно замедлить работу всего массива, но может длиться сутками. К сожалению из-за повышенной нагрузки на диски, все те косяки, которые привели тот умерший диск к смерти, могут возникнуть и на оставшихся дисках (особенно это актуально для дисков одного производителя и одной партии), т.е. шансы помереть дискам в момент ребилда массива - выше, и вот за надежность данных в этот период и будет следить raid6.
p.s. брать одинаковые диски рекомендуют чтобы тайминги были у них одинаковые, особенно это актуально для аппаратных рейдов, буквально цитата, можно получить разрушенный рейд на пустом месте из-за этого.
Полагаю это актуально для аппаратных рейдов, заточенных на производительность, а домашние софтовые рейды этой проблемой не страдают.
Согласен во всем, мнение насчет проблем при ребилде встречается часто. Честно говоря, пораскинул немного мозгами и не стал такое городить для дома. Не дешево, может выкинуть фокус с ребилдом, особенно годика через 4 или позднее, плюс бекапы просто разделил - пару стареньких nas, пару дисков usb, есть же скоростные диски thunderbolt - какие там wifi. фьють - и 40 Гб за мнгновения скопированы.
Вот спасибо. Копнул чуть в этом направлении, посмотрел https://habr.com/ru/post/78311/, https://www.synology-forum.ru/index.php?showtopic=9816, цитата так прямо золотая, на мой взгляд:
"на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0 . В случае любого отказа, даже самого маленького, даже, быть может, не отказа диска целиком, а просто сбоя чтения из за помехи, или проблем с кабелями, вы теряете всю на нем информацию".
Я же правильно все понимаю, что ребилд диска 10 Тб может идти сутки и более, и в этот момент надо только молиться, чтобы диски с одинаковым износом не покрашились? На практике raid1 встречал уже ситуацию, когда вышел один диск из строя, не трогал - сервер шелестел. Тронул на замену - и второй диск в помойку ушел.
MarvinD, да, это вполне реально, особенно на дисках большого объема.
Я в свое время столкнулся с netgear nas на 4 диска. Эта хрень стояла себе в стойке несколько лет, работала 24/7, потом вдруг стала присылать письма что smart одного диска репортит о нарастании некоего каунтера, приняли решение тупо поменять диски, все, т.к. диски уже отпахали несколько лет, да и места стало не хвататть. Последовательно поменял диски по одному через ребилд, неделю наверное процесс занял. Старые диски отправили мне на посмотреть, везли с заботой. Итог - 2 диска мертвые по механике, еще 2 стартанули не с первой попытки.
Там был raid6. Мне пищи для размышлений хватило.
poisons, недавно совсем ещё недоумевал, зачем в этих Synology процессоры мощные. а потом дома полтора суток на старом Qnap ждал ребилда 2 Тб.
Организация единого дискового пространства — задача, легко решаемая с помощью аппаратного RAID-контроллера. Однако следует вначале ознакомиться с особенностями использования и управления таким контроллером. Об этом сегодня расскажем в нашей статье.
Внешний вид
Мы выбрали решения Adaptec от компании Microsemi. Это RAID-контроллеры, зарекомендовавшие себя удобством использования и высокой производительностью. Их мы устанавливаем, если наш клиент решил заказать сервер произвольной или фиксированной конфигурации.
Для подключения дисков используются специальные интерфейсные кабели. Со стороны контроллера используются разъемы SFF8643. Каждый кабель позволяет подключить до 4-х дисков SAS или SATA (в зависимости от модели). Помимо этого интерфейсный кабель еще имеет восьмипиновый разъем SFF-8485 для шины SGPIO, о назначении которой поговорим чуть позже.
Помимо самого RAID-контроллера существует еще два дополнительных устройства, позволяющих увеличить надежность:
-
BBU (Battery Backup Unit) — модуль расширения с литий-ионной батареей, позволяющий поддерживать напряжение на энергозависимой микросхеме кэша. В случае внезапного обесточивания сервера его использование позволяет временно сохранить содержимое кэша, которое еще не было записано на диски.
Это особенно важно, когда включен режим отложенной записи кэша (Writeback). При пропадании электропитания содержимое кэша не будет сброшено на диски, что приведет к потере данных и, как следствие, штатная работа дискового массива будет нарушена.
Технические характеристики
Температура
Вначале хотелось бы затронуть такую важную вещь, как температурный режим аппаратных RAID-контроллеров Adaptec. Все они оснащены небольшими пассивными радиаторами, что может вызвать ложное представление о небольшом тепловыделении.
Производитель контроллера приводит в качестве рекомендуемого значения воздушного потока — 200 LFM (linear feet per minute), что соответствует показателю 8,24 литра в секунду (или 1,02 метра в секунду). Рассчитаны такие контроллеры исключительно на установку в rackmount-корпусы, где такой воздушный поток создается скоростными штатными кулерами.
От 0°C до 40-55°C — рабочая температура большинства RAID-контроллеров Adaptec (в зависимости от наличия установленных модулей), рекомендованная производителем. Максимальная рабочая температура чипа составляет 100°C. Функционирование контроллера при повышенной температуре (более 85°C) может вывести его из строя. Удобства ради приводим под спойлером табличку рекомендуемых температур для разных серий контроллеров Adaptec.
Series 2 (2405, 2045, 2805) and 2405Q | 55°C без модулей |
Series 5 (5405, 5445, 5085, 5805, 51245, 51645, 52445) | 55°C без батарейного модуля, 40°C с батарейным модулем ABM-800 |
Series 5Z (5405Z, 5445Z, 5805Z, 5805ZQ) | 50°C с модулем ZMCP |
Series 5Q (5805Q) | 55°C без батарейного модуля, 40°C с батарейным модулем ABM-800 |
Series 6E (6405E, 6805E) | 55°C без модулей |
Series 6/6T (6405, 6445, 6805, 6405T, 6805T) | 55°C без ZMCP модуля, 50°C с ZMCP модулем AFM-600 |
Series 6Q (6805Q, 6805TQ) | 50°C с ZMCP модулем AFM-600 |
Series 7E (71605E) | 55°C без модулей |
Series 7 (7805, 71605, 71685, 78165, 72405) | 55°C без ZMCP модуля, 50°C с ZMCP модулем AFM-700 |
Series 7Q (7805Q, 71605Q) | 50°C с ZMCP модулем AFM-700 |
Series 8E (8405E, 8805E) | 55°C без модулей |
Series 8 (8405, 8805, 8885) | 55°C без ZMCP модуля, 50°C с ZMCP модулем AFM-700 |
Series 8Q (8885Q, 81605Z, 81605ZQ) | 50°C с ZMCP модулем AFM-700 |
Нашим клиентам не приходится беспокоиться о перегреве контроллеров, поскольку в наших дата-центрах поддерживается постоянный температурный режим, а сборка серверов произвольной конфигурации происходит с учетом особенностей таких комплектующих (о чем мы упоминали в нашей предыдущей статье).
Скорость работы
Для того чтобы продемонстрировать, как наличие аппаратного RAID-контроллера способствует увеличению скорости работы сервера, мы решили собрать тестовый стенд со следующей конфигурацией:
- CPU Intel Xeon E3-1230v5;
- RAM 16 Gb DDR4 2133 ECC;
- 4 HDD емкостью по 1 ТБ.
Затем в этот же стенд поставим RAID-контроллер Adaptec ASR 7805 с модулем защиты кэша AFM-700, подключим к нему эти же жесткие диски и выполним точно такое же тестирование.
С программным RAID
Несомненное преимущество программного RAID — простота использования. Массив в ОС Linux создается с помощью штатной утилиты mdadm. При установке операционной системы чаще всего создание массива предусмотрено непосредственно из установщика. В случае, когда такой возможности установщик не предоставляет, достаточно всего лишь перейти в соседнюю консоль с помощью сочетания клавиш Ctrl+Alt+F2 (где номер функциональной клавиши — это номер вызываемой tty).
Создать массив очень просто. Командой fdisk -l смотрим, какие диски присутствуют в системе. В нашем случае это 4 диска:
Проверяем, чтобы на дисках не было метаданных, например, от предыдущего массива:
В случае, если на одном или нескольких дисках будут метаданные, удалить их можно следующим образом (где sdX — требуемый диск):
Создадим на каждом диске разделы для будущего массива c помощью fdisk. В качестве типа раздела следует указать fd (Linux RAID autodetect).
Собираем массив RAID 10 из созданных разделов с помощью команды:
Сразу после этого будет создан массив /dev/md0 и будет запущен процесс перестроения данных на дисках. Для отслеживания текущего статуса процесса введите:
Пока процесс перестроения данных не будет завершен, скорость работы дискового массива будет снижена.
После установки операционной системы и Bitrix24 на созданный массив мы запустили стандартный тест и получили следующие результаты:
С аппаратным RAID
Прежде чем сервер сможет использовать единое дисковое пространство RAID-массива, необходимо выполнить базовую настройку контроллера и логических дисков. Сделать это можно двумя способами:
- при помощи внутренней утилиты контроллера,
- утилитой из операционной системы.
Утилита позволяет не только управлять настройками контроллера, но и логическими устройствами. Инициализируем физические диски (вся информация на дисках при инициализации будет уничтожена) и создадим массив RAID-10 с помощью раздела Create Array. При создании система запросит желаемый размер страйпа, то есть размер блока данных за одну I/O-операцию:
- больший размер страйпа идеален для работы с файлами большого размера;
- меньший размер страйпа подойдет для обработки большого количества файлов небольшого размера.
Важно — размер страйпа задается только один раз (при создании массива) и это значение в дальнейшем изменить нельзя.
Сразу после того, как контроллеру отдана команда создания массива, также, как и с программным RAID, начинается процесс перестроения данных на дисках. Этот процесс работает в фоновом режиме, при этом логический диск становится сразу доступен для BIOS. Производительность дисковой подсистемы будет также снижена до завершения процесса. В случае, если было создано несколько массивов, то необходимо определить загрузочный массив с помощью сочетания клавиш Ctrl + B.
После того как статус массива изменился на Optimal, мы установили Bitrix24 и провели точно такой же тест. Результат теста:
Сразу становится понятно, что аппаратный RAID-контроллер ускоряет операции чтения и записи на дисковый носитель за счет использования кэша, что позволяет быстрее обрабатывать массовые обращения пользователей.
Управление контроллером
Непосредственно из операционной системы управление контроллером производится с помощью программного обеспечения, доступного для скачивания с сайта производителя. Доступны варианты для большинства операционных систем и гипервизоров:
- Debian,
- Ubuntu,
- Red Hat Linux,
- Fedora,
- SuSE Linux,
- FreeBSD,
- Solaris,
- Microsoft Windows,
- Citrix XenServer,
- VMware ESXi.
Следует помнить, что бэкплэйны поддерживают не только SGPIO, но и I2C. Переключение между этими режимами осуществляется чаще всего с помощью джамперов на самом бэкплэйне.
Каждому устройству, подключенному к аппаратному RAID-контроллеру Adaptec, присваивается идентификатор, состоящий из номера канала и номера физического диска. Номера каналов соответствуют номерам портов на контроллере.
Замена диска — штатная операция, впрочем, требующая однозначной идентификации. Если допустить ошибку при этой операции, можно потерять данные и прервать работу сервера. С аппаратным RAID-контроллером такая ошибка является редкостью.
Делается это очень просто:
-
Запрашивается список подключенных дисков к контроллеру:
Настройка кэширования
Теперь пару слов о вариантах работы кэша на запись. Вариант Write Through означает, что контроллер сообщает операционной системе об успешном выполнении операции записи только после того, как данные будут фактически записаны на диски. Это повышает надежность сохранности данных, но никак не увеличивает производительность.
Чтобы достичь максимальной скорости работы, необходимо использовать вариант Write Back. При такой схеме работы контроллер будет сообщать операционной системе об успешной IO-операции сразу после того, как данные поступят в кэш.
Важно — при использовании Write Back настоятельно рекомендуется использовать BBU или ZMCP-модуль, поскольку без него при внезапном отключении электричества часть данных может быть утеряна.
Настройка мониторинга
Зачастую требуется отслеживать состояние контроллера напрямую из гипервизора, например, VMware ESXi. Задача решается с помощью установки CIM-провайдера с помощью инструкции Microsemi.
Прошивка
Если нашему клиенту требуется сменить версию прошивки контроллера, то ему достаточно создать тикет в нашей панели управления. Системные инженеры выполнят перепрошивку RAID-контроллера до требуемой версии в указанное время и сделают это максимально корректно.
Важно — не следует выполнять перепрошивку самостоятельно, поскольку любая ошибка может привести к потере данных!
Заключение
Использование аппаратного RAID-контроллера оправдано в большинстве случаев, когда требуется высокая скорость и надежность работы дисковой подсистемы.
Системные инженеры Selectel бесплатно выполнят базовую настройку дискового массива на аппаратном RAID-контроллере при заказе сервера произвольной конфигурации. В случае, если потребуется дополнительная помощь с настройкой, мы будем рады помочь в рамках нашей услуги администрирования. Также мы подготовили для наших читателей небольшую памятку по командам утилиты arcconf.
Читайте также: