Организация единого дискового пространства — задача, легко решаемая с помощью аппаратного RAID-контроллера. Однако следует вначале ознакомиться с особенностями использования и управления таким контроллером. Об этом сегодня расскажем в нашей статье.
Надежность и скорость работы дисковых накопителей — вопрос, волнующий каждого системного администратора. Несмотря на заверения производителей о качестве собственных устройств — HDD и SSD продолжают выходить из строя в самое неподходящее время, теряя драгоценные данные. Технология S.M.A.R.T. в большинстве случаев дает возможность оценить «здоровье» накопителя, но это не гарантирует того, что диск будет продолжать беспроблемно работать.
Предсказать выход диска из строя со 100%-ой точностью невозможно, поэтому следует предусмотреть вариант, при котором это не станет проблемой или причиной остановки сервисов. Использование RAID-массивов решает эту задачу. Рассмотрим три основных подхода, применяющихся для этой задачи:
- Программный RAID — наименее затратный вариант, но и наименее производительный. Массив создается средствами операционной системы, вся нагрузка по обработке данных «ложится на плечи» центрального процессора.
- Интегрированный аппаратный RAID (еще его часто называют Fake-RAID) — микрочип, установленный на материнскую плату, который берет на себя часть функционала аппаратного RAID-контроллера, работая в паре с центральным процессором. Этот подход работает чуть быстрее, чем программный RAID, но надежность у такого массива оставляет желать лучшего.
- Аппаратный RAID — это отдельный контроллер с собственным процессором и кэширующей памятью, полностью забирающий на себя выполнение всех дисковых операций. Наиболее затратный, однако, самый производительный и надежный вариант для использования.
Давайте рассмотрим аппаратный RAID детально.
Внешний вид
Мы выбрали решения Adaptec от компании Microsemi. Это RAID-контроллеры, зарекомендовавшие себя удобством использования и высокой производительностью. Их мы устанавливаем, если наш клиент решил заказать сервер произвольной или фиксированной конфигурации.
Для подключения дисков используются специальные интерфейсные кабели. Со стороны контроллера используются разъемы SFF8643. Каждый кабель позволяет подключить до 4-х дисков SAS или SATA (в зависимости от модели). Помимо этого интерфейсный кабель еще имеет восьмипиновый разъем SFF-8485 для шины SGPIO, о назначении которой поговорим чуть позже.
Помимо самого RAID-контроллера существует еще два дополнительных устройства, позволяющих увеличить надежность:
- BBU (Battery Backup Unit) — модуль расширения с литий-ионной батареей, позволяющий поддерживать напряжение на энергозависимой микросхеме кэша. В случае внезапного обесточивания сервера его использование позволяет временно сохранить содержимое кэша, которое еще не было записано на диски.
Как только электропитание сервера будет восстановлено — содержимое кэша будет записано на диски в штатном режиме. По заявлениям производителя полностью заряженная батарея способна хранить данные кэша в течение 72 часов. - ZMCP (Zero-Maintenance Cache Protection) — специальный модуль расширения для RAID-контроллера, имеющий собственную энергонезависимую память и суперконденсатор. В случае возникновения сбоя сервера по электропитанию, суперконденсатор обеспечивает микросхемы электроэнергией, которой достаточно для записи содержимого энергозависимой памяти кэша в NAND-память ZMCP.
После того, как электропитание сервера восстановлено, содержимое кэша автоматически будет записано на диски. Именно такие модули устанавливаются в наши серверы с аппаратным RAID-контроллером и Cache Protection.
Это особенно важно, когда включен режим отложенной записи кэша (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 ТБ.
В качестве операционной системы будет установлена CentOS 7. Роль серверного приложения возьмет на себя 1C Bitrix24. Вначале мы соберем программный RAID-массив с помощью mdadm и измерим производительность с помощью встроенного в Bitrix24 теста. Каких-либо изменений или дополнительных настроек в систему специально не вносим — устанавливается демо-конфигурация с настройками по-умолчанию.
Затем в этот же стенд поставим RAID-контроллер Adaptec ASR 7805 с модулем защиты кэша AFM-700, подключим к нему эти же жесткие диски и выполним точно такое же тестирование.
С программным RAID
Несомненное преимущество программного RAID — простота использования. Массив в ОС Linux создается с помощью штатной утилиты mdadm. При установке операционной системы чаще всего создание массива предусмотрено непосредственно из установщика. В случае, когда такой возможности установщик не предоставляет, достаточно всего лишь перейти в соседнюю консоль с помощью сочетания клавиш Ctrl+Alt+F2 (где номер функциональной клавиши — это номер вызываемой tty).
Создать массив очень просто. Командой fdisk -l смотрим, какие диски присутствуют в системе. В нашем случае это 4 диска:
/dev/sda
/dev/sdb
/dev/sdc
/dev/sddПроверяем, чтобы на дисках не было метаданных, например, от предыдущего массива:
mdadm --examine /dev/sda /dev/sdb /dev/sdc /dev/sddНа всех 4-х дисках должно быть сообщение:
mdadm: No md superblock detectedВ случае, если на одном или нескольких дисках будут метаданные, удалить их можно следующим образом (где sdX — требуемый диск):
mdadm --zero-superblock /dev/sdXСоздадим на каждом диске разделы для будущего массива c помощью fdisk. В качестве типа раздела следует указать fd (Linux RAID autodetect).
fdisk /dev/sdXСобираем массив RAID 10 из созданных разделов с помощью команды:
mdadm --create --verbose /dev/md0 --level=10 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1Сразу после этого будет создан массив /dev/md0 и будет запущен процесс перестроения данных на дисках. Для отслеживания текущего статуса процесса введите:
cat /proc/mdstat
Пока процесс перестроения данных не будет завершен, скорость работы дискового массива будет снижена.
После установки операционной системы и Bitrix24 на созданный массив мы запустили стандартный тест и получили следующие результаты:
С аппаратным RAID
Прежде чем сервер сможет использовать единое дисковое пространство RAID-массива, необходимо выполнить базовую настройку контроллера и логических дисков. Сделать это можно двумя способами:
- при помощи внутренней утилиты контроллера,
- утилитой из операционной системы.
Первый способ идеально подходит для первоначальной настройки. Вход в утилиту в режиме Legacy (режим для наших серверов по умолчанию) осуществляется с помощью сочетания клавиш CTRL + A при появлении уведомления в процессе инициализации POST.
Утилита позволяет не только управлять настройками контроллера, но и логическими устройствами. Инициализируем физические диски (вся информация на дисках при инициализации будет уничтожена) и создадим массив 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.
Пользователям других дистрибутивов Linux также доступны исходные коды драйверов. Помимо драйверов и консольной утилиты ARCCONF производитель также предлагает программу с графическим интерфейсом для удобного управления контроллером — maxView Storage Manager.
С помощью указанных утилит можно, не прерывая работу сервера, легко управлять логическими и физическими дисками. Также можно задействовать такой полезный функционал, как «подсветка диска». Мы уже упоминали про пятый кабель для подключения SGPIO — этот кабель подключается напрямую в бэкплейн (от англ. backplane — соединительная плата для накопителей сервера) и позволяет RAID-контроллеру полностью управлять световой индикацей каждого диска.
Следует помнить, что бэкплэйны поддерживают не только SGPIO, но и I2C. Переключение между этими режимами осуществляется чаще всего с помощью джамперов на самом бэкплэйне.
Каждому устройству, подключенному к аппаратному RAID-контроллеру Adaptec, присваивается идентификатор, состоящий из номера канала и номера физического диска. Номера каналов соответствуют номерам портов на контроллере.
Замена диска — штатная операция, впрочем, требующая однозначной идентификации. Если допустить ошибку при этой операции, можно потерять данные и прервать работу сервера. С аппаратным RAID-контроллером такая ошибка является редкостью.
Делается это очень просто:
- Запрашивается список подключенных дисков к контроллеру:
arcconf getconfig 1 - Находится диск, требующий замены, и записываются его «координаты» (параметр Reported Channel,Device(T:L)).
- Диск «подсвечивается» командой:
arcconf identify 1 device 0 0
Например, на платформах Supermicro штатная работа диска — зеленый или синий цвет, а «подсвеченный» диск будет моргать красным. Перепутать диски в этом случае невозможно, что позволит избежать ошибки из-за человеческого фактора.
Настройка кэширования
Теперь пару слов о вариантах работы кэша на запись. Вариант Write Through означает, что контроллер сообщает операционной системе об успешном выполнении операции записи только после того, как данные будут фактически записаны на диски. Это повышает надежность сохранности данных, но никак не увеличивает производительность.
Чтобы достичь максимальной скорости работы, необходимо использовать вариант Write Back. При такой схеме работы контроллер будет сообщать операционной системе об успешной IO-операции сразу после того, как данные поступят в кэш.
Важно — при использовании Write Back настоятельно рекомендуется использовать BBU или ZMCP-модуль, поскольку без него при внезапном отключении электричества часть данных может быть утеряна.
Настройка мониторинга
Вопрос мониторинга статуса работы оборудования и возможности оповещения стоит достаточно остро для любого системного администратора. Для того чтобы настроить «связку» из Zabbix и RAID-контроллера Adaptec рекомендуем воспользоваться перечисленными решениями.
Зачастую требуется отслеживать состояние контроллера напрямую из гипервизора, например, VMware ESXi. Задача решается с помощью установки CIM-провайдера с помощью инструкции Microsemi.
Прошивка
Необходимость прошивки RAID-контроллера возникает чаще всего для исправления выявленных производителем проблем с работой устройства. Несмотря на то, что прошивки доступны для самостоятельного обновления, к этой операции следует подойти очень ответственно, особенно если процедура выполняется на «боевой» системе.
Если нашему клиенту требуется сменить версию прошивки контроллера, то ему достаточно создать тикет в нашей панели управления. Системные инженеры выполнят перепрошивку RAID-контроллера до требуемой версии в указанное время и сделают это максимально корректно.
Важно — не следует выполнять перепрошивку самостоятельно, поскольку любая ошибка может привести к потере данных!
Заключение
Использование аппаратного RAID-контроллера оправдано в большинстве случаев, когда требуется высокая скорость и надежность работы дисковой подсистемы.
Системные инженеры Selectel бесплатно выполнят базовую настройку дискового массива на аппаратном RAID-контроллере при заказе сервера произвольной конфигурации. В случае, если потребуется дополнительная помощь с настройкой, мы будем рады помочь в рамках нашей услуги администрирования. Также мы подготовили для наших читателей небольшую памятку по командам утилиты arcconf.
Используете ли вы аппаратные RAID-контроллеры? Ждем вас в комментариях.
Комментарии (15)
ISE73
04.06.2019 15:45Я не из Селектела, но, отвечу/спрошу: судя по «лишние 50k IOPS» в тестах учавствуют SSD. Для SSD желательно без «вот этих кэшей» с прямой записью на диск.
HiMem-74
04.06.2019 15:50Был у меня опыт взаимодействия с разными RAID, лет 8 назад.
1. Принесли на восстановление данных комп, софтовый рейд, 2 винта в зеркале, на них 1С базы, система на отдельном винте. Сгорел контроллер на матери, винты из зеркала не читаются по отдельности. Бэкап «по выходным». Поход в ближайший магазин, покупка такой же платы, всё читается.
Почему не читались данные, хотя должны были — не разбирался, глубокого анализа таблиц размещения, как на хабре любят, не будет. С тех пор обхожу софтовый рейд и никому не советую.
2. Самосбор из 6 или 8 винтов в 5 рейде на отдельном рейд-контроллере, кажется LSI, за давностью лет точно не помню. Бэкап суточный. Умирает контроллер, увлекательный квест по поиску такого же, нашли в соседнем городе за весьма завышенный прайс + 250 км путешествие.
Выводы: решили поиграть с рейд-контроллерами — покупайте сразу запасной и кладите на полку, может не повезти с поисками замены, особенно если вы не в %default_city%
С тех пор только Q-nap для неответственных данных и дисковые полки + carepack для ответственных данных.
Darksa Автор
04.06.2019 16:02Cудя по всему в первом случае это был Fake-RAID. Обычный программный RAID на mdadm легко бы прочитался на любом другом компьютере, вне зависимости от контроллера. А во втором случае — совет действительно стоящий. Именно поэтому у нас всегда есть определенный запас контроллеров используемых в платформах — чтобы при выходе из строя быстро заменить вышедший из строя контроллер на новый, точно такой же модели. Тем не менее из собственного опыта скажу, что выход контроллера из строя — достаточно редкая ситуация.
navion
04.06.2019 17:49Интеловский RST под линуксом сам использует mdadm. И со стеком от LSI диски из зеркала прочитаются без проблем, только с загрузкой придётся повозиться.
oller
05.06.2019 19:58Не только только такой же версии, но и версией или поколением выше, что даёт при имущество при 10+ серверах иметь только один запасной, а не 10. Часто у адаптека и lsi одна прошивка на все контролёры одного поколения, достаточно открыть документацию к прошивке
Так же стоит указать, что больше 4gb кэш не поддерживают контроллеры, те что есть с 8gb имеют много багов, тот же форум hp завален заявками о проблемах, по крайне мере год назад так было
Ещё не мало важно, стоит открыть и почитать документацию и список совместимости! Несовместимые диски могут не работать, а к 5летней давности контролёр дисков уже бывает не найти
Также из практики уже при 70* у контролёра может сносить крышу и почти обязательно нужно навешивать кулер для доп охлаждения
Am0ralist
04.06.2019 18:29+1Какой-то супермикро. Рейд встроенный в мать. Есть два типа портов — SAS и SATA. На паре сасовских дисках поднят рейд зеркало.
Решили воткнуть сата диск. При включении сервера обнаруживается, что контроллер полностью удалил информацию о рейде — как будто и не было его.
Ок, снова создается рейд, при инициализации которого с обоих дисков удаляется таблица разделов. Зеркальце — пустое.
Сказать, что мы офигели — не сказать ничего…
JerleShannara
04.06.2019 22:03+1LSI обычно чинибелен и без контроллера. А вот старая «тварь» 3ware очень делала мозги, когда контроллер на +- два семейства от трупного было сложно достать.
Karpion
04.06.2019 20:11-1Программный RAID — наименее затратный вариант, но и наименее производительный
О какой производительности речь — о дисковом вводе/выводе или о процессорной вычислительной мощности? Каковы типичные потери производительности?
В целлм я согласен с тем, что софтовый RAID — плохая идея. Но это лишь потому, что современные процессоры повадились непременно иметь FPU и прочее говно, которое во многих случаях не нужно.
Интегрированный аппаратный RAID — микрочип, установленный на материнскую плату, который берет на себя часть функционала аппаратного RAID-контроллера
Ну и как именно распределяется работа между CPU и микрочипом?
Аппаратный RAID — это отдельный контроллер с собственным процессором и кэширующей памятью
А чем отличается микрочип из второго пункта? Там нет процессора или нет памяти?
полностью забирающий на себя выполнение всех дисковых операций
Полностью? Гы, смешно!
Для подключения дисков используются специальные интерфейсные кабели.
Этого уже достаточно для того, чтобы предпочесть какой-то другой контроллер.
BBU (Battery Backup Unit) — модуль расширения с литий-ионной батареей, позволяющий поддерживать напряжение на энергозависимой микросхеме кэша.
Странная идея. Не лучше ли поставить Flash-память и сбрасывать отложенную запись туда — но только при сбое питания?
В нормальном режиме во Flash-память ничего не пишется — так что она не изнашивается. А при сбое питания — достаточно небольшого накопителя энергии, чтобы питать систему, пока данные из RAM будут переписаны во Flash-память; и храниться оно там будет не 72 часа, а практически вечность.
Это особенно важно, когда включен режим отложенной записи кэша (Writeback).
Вообще-то, WriteBack — это единственная причина защищаться от сбоя питания. Если использовать WriteThrow — то зашиты от сбоя питания не требуется.
При пропадании электропитания содержимое кэша не будет сброшено на диски, что приведет к потере данных и, как следствие, штатная работа дискового массива будет нарушена.
Я так понимаю, о транзакционном режиме работы программ (драйвера файловой системы и прикладных программ) Вы не слышали.
Все они оснащены небольшими пассивными радиаторами, что может вызвать ложное представление о небольшом тепловыделении.
Осталось понять, откуда там вообще взялось значительное тепловыделение.
При создании система запросит желаемый размер страйпа, то есть размер блока данных за одну I/O-операцию
Я всегда думал, что размер каждой I/O-операции определяется программной частью — прикладной программой или операционной системой. Интересно, что будет, если операционная система посылает контроллеру запрос на чтение всего одного сектора?
Сразу становится понятно, что аппаратный RAID-контроллер ускоряет операции чтения и записи на дисковый носитель за счет использования кэша
А я думал, что операции чтения и записи лимитируются скоростью дисков. Конечно, кэширование может помочь — но кэш можно организовать и в оперативной памяти, причём там наверняка можно сделать его больше, чем на контроллере (производители обычно жмотятся поставить приличную память и не желают ставить слот для обычной памяти, чтобы пользователь мог сам поставить туда сколько считает нужным).
Чтобы достичь максимальной скорости работы, необходимо использовать вариант Write Back. При такой схеме работы контроллер будет сообщать операционной системе об успешной IO-операции сразу после того, как данные поступят в кэш.
Нормальные люди делают операционную систему, которая способна понимать разницу между ситуациями «данные успешно заброшены на контроллер» и «данные успешно записаны на диск». Ну а контроллер умеет сообщать операционной системе статус каждого запроса: «стоит в очереди на исполнение», «прозводится запись», «запись завершена».
PS: Больше всего бесит отсутствие стандартов на организацию RAID-массивов; и документация разработчиков не публикуется. Как результат — нет средств восстановления порушенного RAID-массива.
По хорошему — RAID-контроллер должен быть устроен примерно как совеременная видеокарта: т.е. программу для работы с RAID-массивом туда должна закидывать операционка. Тогда можно быть уверенным, что программный код открыт, формат данных опубликован, в случае сбоя можно разобраться и спасти данные. Однако, производители предпочитают vendor-lock.JerleShannara
04.06.2019 22:06+1Вот с тепловыделением согласен полностью — реально бесит. Особенно когда «одноюнитный» адаптек ставится в 4-5U/вообще десктоп — хоть вешайся от этой печки. А чертовы старые 3ware 7-8-9 спокойно живут без радиаторов.
DaemonGloom
05.06.2019 12:11+1Этого уже достаточно для того, чтобы предпочесть какой-то другой контроллер.
Какой-то другой — это имеющий на себе 8 SATA в прямом виде? Нет, спасибо, SAS breakout cable — гораздо более удобный вариант. Тем более, что с тем же Adaptec в комплекте лежат сразу два кабеля.
Я так понимаю, о транзакционном режиме работы программ (драйвера файловой системы и прикладных программ) Вы не слышали.
Если включен кеш, но пропало питание (а батарея мертва), то с точки зрения софта — всё успешно было записано. Вот только что из этого успешно перенеслось до пропадания питания — знал лишь контроллер, но и тот забыл без батареи.
Осталось понять, откуда там вообще взялось значительное тепловыделение.
Многие контроллеры греются ощутимо, тут никуда не деться. Разве что охлаждение активное вешать на них, если не хочется тщательно продумывать воздушный поток.
Я всегда думал, что размер каждой I/O-операции определяется программной частью — прикладной программой или операционной системой. Интересно, что будет, если операционная система посылает контроллеру запрос на чтение всего одного сектора?
Размер страйпа больше нужен для raid5, ибо запись одного байта будет приводить именно к чтению страйпа целиком — контрольный блок считается по всему страйпу. И записи соответствующего количества информации на диск, а не всего одного байта.
pansa
05.06.2019 02:19+1Не mdadm'ом единым софтовые рейды ограничены. Да и насчет простоты их настройки можно было б поспорить. Потому как, если делать хорошо, то что софтовый, что железный рейды — оно будет «сложно». Чисто личный опыт после полугодовой эпопеи с построением хранилища примерно на 300тб на 3х серверах скажу, что железные рейды в общем проигрывают более-менее грамотно собранному пулу на ZFS. К сожалению, на сегодняшний день, zfs нормально работает только на FreeBSD (ну и на солярке, но это, имхо, совсем редкий зверь теперь). На Linux работает, но рискованно и скорее всего не так быстро.
А с железными рейдами я наелся, хоть и не админ по обязанностям. Что адаптек, что lsi — Imho, дрянь.
И да, я осознал за что бизнес платит такие бабки всяким EMC и netapp. =) Потому что все эти самопалы — всё равно баловство и наколеннечество. Иногда надо чтобы работало хорошо и вопрос денег отходит на второй план… Всё исключительное imho.
Tangeman
05.06.2019 09:24Если нужен RAID1/RAID10 — то по производительности (как и по загрузке проца) практической разницы железного с софтовым не будет (по крайней мере на современных процах), по надёжности тоже. Если говорить про RAID5/6, то всё зависит от нагрузок, но всё равно в большинстве случаев всё упирается в производительность самих дисков и размеры кэша (под линухом тут сильно может помочь bcache).
С другой стороны, из личного опыта — за последние 20 лет была куча проблем с железными, причём именно Adaptec — от полной потери данных массива (когда они сходили с ума) до банальных проблем вроде недоступности всего массива после выхода из строя всего одного диска. Не то что бы часто такое случалось, но сам факт несколько расстраивает — от железного RAID такой подставы совсем не ожидаешь. В то же время, с софтовыми (mdadm) вообще ни разу проблем не было, не говоря уже о том что с ними, в случае чего, нет проблем с восстановлением.pansa
05.06.2019 23:30+1bcache крайне не рекомендую. Пробовал. Крутил по всякому. Опасен спонтанными зависаниями. Причем, не стоит вестись на убеждение, что Write Through режим (или как он там в его реализации называется) безопасен — нет. Всё равно были потери данных после зависаний.
Опять же, никого убеждать не хочу — просто предупреждаю, что если захотите использовать bcache в чем-то серьезном — лучше сначала как следует погоняйте его под вашей нагрузкой хотя бы недельку.
Параллельно внимательно почитайте issue тикеты на этот проект. И подумайте, стоит ли оно.
amarao
Скажите, а ваше мнение по поводу 'WB повышает производительность' основывается на бенчмарках или просто "подумали и сказали"?
Вот у меня как я не кручу, лишние 50k IOPS с устройства теряются при включении WB. И график распределения latency из милого двугорбого существа превращается в шути что.
А у вас?
Darksa Автор
В рамках данной статьи тестирование производительности WB и WT не проводилось. Тут рассматривается стенд только с HDD. Вполне допускаю, что при использовании SSD — картина может быть другой, в том числе и падение IOPS.