Dell PERC H730/H740: настройка RAID, Hot Spare и rebuild на практике

Знаете, я, Семёнов Евгений Сергеевич, директор АйТи Фреш, могу вам честно сказать: за пятнадцать лет, что мы работаем с корпоративными инфраструктурами, я, кажется, видел просто всё. Контроллеры Dell PERC? От H310 на стареньких R610 до H755N на современных R750 – полный комплект. В этой статье я собрал свой практический опыт, особенно по тем моделям, что у нас чаще всего встречаются: H730 и H740. Покажу, как настроить RAID через BIOS или OMSA. И главное – как мы успеваем заметить проблему ещё до того, как она превратится в серьёзную аварию. А ещё будет классный кейс про логистическую компанию, где мы за месяц умудрились поменять пару дисков, но так, что ни один байт данных даже не ёкнул!

Почему именно PERC H730 и H740: что у нас в парке

На нашем обслуживании в АйТи Фреш сейчас крутятся 87 серверов Dell PowerEdge. Представьте, из них 62 машины — это целые поколения 13G и 14G! Речь о моделях R630, R730, R640, R740. Что там с контроллерами? На 13G обычно стоит PERC H730 или H730P. А на 14G, само собой, H740P. Ну и остальные: H330, если сборка бюджетная, H840 для шасси с внешними полками вроде MD1400/MD1420, и, конечно, H750 на совсем свежих R650.

Так в чём же основная разница между H730 и H740? Для любого инженера это ключевой момент.

• Кэш: H730 — 1 GB DDR3, H730P — 2 GB DDR3, H740P — 8 GB DDR4. На больших массивах разница в производительности случайной записи в 3–4 раза.
• Поддержка NVMe: H740P официально работает с NVMe SSD через PCIe Switch на бэкплейне, H730 — нет.
• Скорость интерфейса: H730 — SAS 12 Gbit, H740 — тоже SAS 12 Gbit, но с лучшей обработкой команд за счёт более мощного CPU LSI SAS3508 против SAS3108.
• Battery Backup Unit: на H730P и H740P батарея позволяет включить Write Back без риска потери данных при пропадании питания. На H730 базовом её часто не ставят, и приходится работать в Write Through, что роняет производительность 1С на 40–60 %.

Тормозит запись в базе 1С? И у вас H730 без BBU? На аудите я первым делом лезу проверять режим контроллера. Серьёзно, в половине случаев обнаруживается: батарея либо не активирована, либо её вообще нет! А админ годами сидит в режиме Write Through, и понять не может, почему всё так медленно.

Кейс: два отказа дисков за месяц на серверах логистической компании

Помню, в январе 2026-го к нам обратились ребята из логистической компании, что в Подольске. В принципе, клиент довольно типичный для нас: 38 рабочих мест, 1С УТ 11.5, где одновременно работали 14 пользователей, да ещё и своя WMS-система. Под это дело у них стояли два сервера Dell R630, оба с PERC H730, и в каждом — по шесть дисков SAS 10K 1.2 TB. А вот дальше началось самое интересное, прямо в тот самый январь: на одном сервере друг за другом «посыпались» два диска! Причём второй диск отказал ровно в тот момент, когда первый уже ребилдился на 73%. Вы вообще представляете эту картину? RAID 5, два отказа – по логике, по математике, массив просто обязан был лечь и не встать.

Но он выстоял! Вот это сюрприз, да? Нас спасло, что прежний админ оказался молодцом – он позаботился о Hot Spare. Вышло так, что второй диск, который вышел из строя, уже не участвовал в активном массиве, потому что его данные ребилдились на горячий резерв. Когда меня вызвали, чтобы я вник в эту ситуацию, я увидел, к сожалению, до боли знакомую картину: серверы ещё 2017 года выпуска, диски с наработкой под 67–72 тысячи часов. А самое тревожное – SMART-показатели у трёх оставшихся дисков уже просто кричали о проблемах: Reallocated Sector Count был больше полусотни, а Pending Sector Count перевалил за пять.

Что мы сделали за две недели:

1. Недавно, в рамках одного проекта, нам пришлось срочно расширить хранилище. Мы заказали целых 12 новых SAS-дисков Toshiba по 1.2 TB каждый, со скоростью 10K RPM. Что важно, они шли с официальной гарантией Dell, так как мы получили их через наш проверенный партнёрский канал. Вся партия из 12 дисков обошлась нам в 326 000 рублей.
2. На обоих серверах мы решили не рисковать и поэтапно мигрировали с морально устаревшего RAID 5 на куда более надёжный RAID 6, да ещё и добавили Hot Spare. Потому что использовать RAID 5 на шести дисках, особенно в перспективе до 2026 года — это, друзья, уже чистой воды лотерея. И я сейчас объясню, почему именно так.
3. Чтобы обеспечить полный контроль и удобство, мы развернули OMSA с интуитивно понятным веб-интерфейсом. А для того, чтобы ничего не пропустить, настроили SNMP-трапы, которые теперь летят прямиком в наш Zabbix. В итоге получилась отличная связка для мониторинга!
4. Нужно, чтобы важные уведомления приходили мгновенно, верно? Именно поэтому мы подключили почтовые алёрты прямо на iDRAC9. Но этого нам показалось мало, и мы добавили отправку сообщений в Telegram, используя для этого хитрый скрипт-прокладку. Теперь информация всегда под рукой.
5. Для проактивного контроля состояния дисков мы внедрили еженедельную проверку SMART. Эта задача запускается через команду racadm и аккуратно прописана в crontab нашей системы мониторинга. Мелочь, а экономит кучу нервов и предотвращает сюрпризы!

С тех пор на этих серверах было ещё пара отказов дисков. Оба раза Hot Spare отработал на отлично: ни инженера не беспокоили, ни 1С не простаивала. Клиент, конечно, платит абонентку. А мы спокойно спим, зная, что всё под контролем.

Какой уровень RAID выбирать в 2026 году

Когда я слышу про «RAID 5 на шести SATA-дисках по 4 TB», вы уж простите, но глаз начинает нервно дёргаться. Давайте я объясню, почему это такая плохая идея, максимально просто. Смотрите: вероятность невосстановимой ошибки чтения, она же URE, у Enterprise SAS — один к 10^15. А у обычного SATA? Уже один к 10^14! Теперь представьте: массив начинает ребилдиться, и контроллеру нужно прочитать вообще все оставшиеся диски подряд. На массиве из шести SATA-дисков по 4 TB это, между прочим, целых 20 TB чтений! И вот тут вероятность поймать ту самую URE просто катастрофически взлетает – до 80–90%. Понимаете? Один диск отказал, запустился rebuild, и если в процессе чтения попадётся бэдблок – всё, прощай, массив. Это печально, но это чистая математика.

А вот моя личная шпаргалка – как я выбираю RAID для контроллеров PERC H730/H740 на сегодня:

В 2026 году я использую RAID 5 крайне редко, практически не использую. Ну разве что на маленьких массивах из очень быстрых SAS SSD, скажем, 3–4 диска по 800 GB. Или как временное решение для тестовых стендов – там, где не критично. Но если мы говорим про настоящие production-системы, где стоят диски больше 1 TB, то мой выбор тут однозначен и бескомпромиссен: только RAID 6. И, естественно, обязательно с Hot Spare. Других вариантов быть не может.

Настройка RAID через BIOS контроллера (Ctrl+R)

Начну, пожалуй, с самого базового способа, которым я пользуюсь – это утилита PERC BIOS Configuration. Чем она хороша? Да тем, что работает вообще без операционной системы! По сути, это ваш первый инструмент для первичной разметки любого нового сервера. Вот та самая последовательность действий, которую я неизменно повторяю на каждом новом сервере, который попадает мне в руки:

1. При загрузке сервера в момент инициализации PERC появляется приглашение Press <Ctrl><R> to Run Configuration Utility. Жмём.
2. Как только вы заходите, перед вами предстаёт тот самый синий интерфейс. Сверху вы увидите список всех контроллеров — обычно, кстати, там всего один. А вот снизу уже расположены ваши физические диски и все существующие виртуальные диски, или, как мы их сокращенно называем, VD.
3. Если в системе уже была конфигурация (например, поставили б/у диски от другого сервера) — увидите Foreign Configuration. Идём в Foreign View, либо импортируем (если данные нужны), либо очищаем через Clear Foreign Config.
4. F2 на строке контроллера — выбираем Create New VD.
5. Теперь, конечно, нужно выбрать желаемый уровень RAID. Кстати, переключаться между полями очень удобно с помощью клавиши Tab.
6. Пробелом аккуратно отмечаем те диски, которые вы собираетесь включить в новый массив. У PERC есть просто отличная и очень полезная фича: в правой колонке сразу видно, какие диски с какого бэкплейна. Важно следить за этим, особенно при настройке RAID 10 — убедитесь, что пары дисков не попали на один и тот же бэкплейн, это критично!
7. Что касается Stripe Element Size, здесь есть свои тонкости. Для большинства общих задач смело оставляйте стандартные 64 KB. А если вы работаете с видеомонтажом или базами данных, где оперируют большими блоками, то лучше выбрать 256 KB. Ну а для систем OLTP, с их множеством мелких транзакций, оптимальными будут 16 KB. Выбирайте, исходя из вашей нагрузки!
8. В разделе Read Policy мы настоятельно рекомендуем выбрать Adaptive Read Ahead. Это по-настоящему умная опция: контроллер не ждёт запроса, а сам анализирует паттерны работы и решает, когда лучше начать читать данные упреждающе. Такая предусмотрительность заметно ускоряет доступ к информации.
9. Write Policy — Write Back при наличии исправной батареи. Если её нет — только Write Through, иначе при пропадании питания потеряете данные из кэша.
10. А вот с Disk Cache Policy лучше не экспериментировать и всегда оставлять его в положении Default. Почему? Потому что включать дисковый кэш безопасно лишь в очень специфических ситуациях: если диски сами оборудованы защитой от потери питания (PLP) и при этом у контроллера есть BBU. В противном случае вы рискуете потерять данные!
11. Initialize — выбираем Fast Init, если массив новый и пустой. Full Init нужен только если перепроверяете б/у диски.

Мы нажали Ctrl+R? Отлично, перезагружаемся. И вот, вуаля! В установщике операционной системы уже красуется наш новенький, готовый виртуальный диск нужного размера. На этом, скажем так, базовая настройка закончена. Всё, что остаётся, я делаю уже либо через OMSA, либо, если вдруг OMSA недоступна, при помощи racadm.

Управление RAID через Dell OpenManage Server Administrator

Что это за OMSA такая? По сути, это просто мегаудобный веб-интерфейс, который даёт возможность управлять железом сервера прямо изнутри операционной системы. И вот почему мы ставим её на абсолютно каждый Dell-сервер, который берём на обслуживание: потому что без OMSA любое действие, даже самое мелкое, требует перезагрузки в Ctrl+R! А это, друзья, не шутки, это десятки минут простоя 1С! Оно вам надо? Мне — точно нет.

Ну что, как установить OMSA на Windows Server 2019/2022?

# Скачиваем OM-SrvAdmin-Dell-Web-Windows-11.x.x.x.exe с support.dell.com
# Запускаем мастер, выбираем Typical Install
# По умолчанию веб-интерфейс на https://servername:1311

А вот как выглядит установка OMSA на Linux, включая RHEL 8, Rocky 9 и Ubuntu Server 22.04:

# Подключаем репозиторий Dell
curl -O https://linux.dell.com/repo/hardware/dsu/bootstrap.cgi
sudo bash bootstrap.cgi
sudo dnf install srvadmin-all
sudo systemctl enable --now dsm_om_connsvc
# Проверка
omreport storage controller

Что я регулярно делаю через OMSA:

• Знаете, что удобно? Вы можете создавать и удалять виртуальные диски прямо на ходу, без необходимости перезагружать сервер! Это экономит кучу времени. Просто зайдите в раздел Storage, выберите свой PERC-контроллер, а затем — Create Virtual Disk.
• Когда мы проводим тонкую настройку производительности 1С, иногда приходится вручную менять Cache Policy. Это позволяет нам выжать максимум из системы под специфические нагрузки 1С, оптимизируя отклик и скорость работы.
• Назначить Hot Spare диск — будь он Dedicated или Global — на удивление просто. Буквально пара кликов, и у вас появляется дополнительная надёжная защита от внезапного отказа любого из дисков в массиве. Разве не здорово?
• Чтобы все диски работали без сбоев, мы регулярно запускаем Patrol Read и Consistency Check. Это происходит строго по расписанию, чтобы гарантировать постоянную проверку и целостность ваших данных.
• Мы не просто смотрим SMART-показатели, а глубоко их анализируем для каждого диска. Что нас интересует? Predictive Failure Count — чтобы предсказать возможную поломку заранее. А ещё Media Errors и Other Errors, ведь они могут многое рассказать о состоянии носителя.
• Как только что-то идёт не так, мы должны об этом узнать первыми. Именно поэтому настраиваем SNMP-трапы: они мгновенно отправляются в Zabbix, если где-то вдруг "загорелось красным". Это наша система раннего оповещения.

Управление через racadm и iDRAC из командной строки

Нужна автоматизация? Какие-то скрипты для мониторинга? Мы в ITFresh всегда держим в уме racadm. Это же просто спасение – мощная командная утилита от Dell. Установить её проще простого, буквально одним пакетом! А работает как часы: хоть удалённо, по сети к iDRAC, хоть локально, напрямую через USB к карте управления. Гибкость – наше всё, не так ли?

Итак, как же поставить racadm на вашу Linux-машину администратора?

sudo dnf install srvadmin-idracadm8
# Удалённый запрос статуса
racadm -r 10.0.0.50 -u root -p calvin storage get pdisks
racadm -r 10.0.0.50 -u root -p calvin storage get vdisks
racadm -r 10.0.0.50 -u root -p calvin getsel

Вот они, те самые команды, без которых я лично никуда – всегда под рукой в моей шпаргалке:

# Статус всех дисков
racadm storage get pdisks -o

# Создать виртуальный диск (RAID 6 из 6 дисков)
racadm storage createvd:RAID.Integrated.1-1 -rl r6 \
    -pdkey:Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1,\
    Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1,\
    Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1,\
    Disk.Bay.3:Enclosure.Internal.0-1:RAID.Integrated.1-1,\
    Disk.Bay.4:Enclosure.Internal.0-1:RAID.Integrated.1-1,\
    Disk.Bay.5:Enclosure.Internal.0-1:RAID.Integrated.1-1

# Назначить Hot Spare
racadm storage hotspare:Disk.Bay.6:Enclosure.Internal.0-1:RAID.Integrated.1-1 \
    -assign yes -type ghs

# Применить изменения сразу, без перезагрузки
racadm jobqueue create RAID.Integrated.1-1 --realtime

# Очистить System Event Log
racadm clrsel

Hot Spare: правильное использование

Что такое Hot Spare? Это не просто запасной диск. Он физически находится внутри сервера, но пока не используется. Зато как только любой диск в массиве даёт сбой, контроллер тут же его «подхватывает» — автоматически! Таких спасателей бывает два вида:

• Dedicated Hot Spare (DHS) — резервный диск привязан к конкретному виртуальному диску. Если на сервере несколько массивов, DHS подхватит только в свой.
• Global Hot Spare (GHS) — резервный диск доступен для всех массивов на этом контроллере. На малых серверах с одним массивом — практически то же, что и Dedicated.

У меня, как у технаря с опытом, есть железное правило: любой сервер с RAID 5 или RAID 6 ОБЯЗАН иметь хотя бы один Hot Spare. А если уж говорим о наших критически важных, «боевых» машинах, то мы в ITFresh ставим по два. Вы просто подумайте: диск SAS 10K 1.2 TB сейчас обойдётся вам в 24–28 тысяч рублей. Это же пыль! Особенно если сравнить с затратами, которые понесёт бизнес от простоя 1С хотя бы на полдня! Помните кейс с логистической компанией? Там как раз на каждом сервере стоял по 1 GHS — и именно этот Hot Spare оказался спасителем, когда произошёл двойной отказ. Без него было бы очень грустно.

А вот тут важная штука, прямо критический нюанс: Hot Spare должен быть размером не меньше, чем самый крупный диск в вашем массиве. И, что не менее важно, желательно того же типа интерфейса! SAS к SAS, SATA к SATA, SSD к SSD — никаких компромиссов. Поставите SATA-диск как Hot Spare к SAS-массиву? Контроллер просто проигнорирует его в случае беды. И прощай, автоматическое восстановление.

Rebuild: как контроллер восстанавливает массив

И что же происходит, когда диск внезапно «умирает»? Контроллер не будет ждать ни секунды! Он моментально запускает процесс восстановления (rebuild) на Hot Spare. Или, если вы оказались быстрее, на тот новенький диск, что вы воткнули в освободившуюся ячейку. Для операционной системы, кстати, это всё абсолютно незаметно — работает прозрачно. Но есть один очень важный нюанс: во время rebuild производительность всего массива может просесть на ощутимые 30–50%. И вот это надо держать в голове.

Хотите управлять этим процессом? Параметр Rebuild Rate в OMSA или racadm позволяет найти тот самый баланс: между тем, как быстро ваш массив восстановится, и тем, как сильно это повлияет на его текущую работу.

# Текущий Rebuild Rate
racadm get storage.controller.RAID.Integrated.1-1.RebuildRate

# Поднять до 50 % (по умолчанию 30 %)
racadm set storage.controller.RAID.Integrated.1-1.RebuildRate 50
racadm jobqueue create RAID.Integrated.1-1 --realtime

Поднимать Rebuild Rate выше 50% мы советуем только когда сервер не сильно загружен, например, в нерабочие часы, или на тех машинах, где кратковременное падение производительности вообще не критично. А вот на «боевых» серверах с 1С я лично всегда держу 30%. Да, пользователи могут заметить, что система стала чуть медленнее, но работать при этом всё ещё вполне комфортно.

Основываясь на нашем опыте, вот реальные цифры по времени восстановления, которые мы зафиксировали на серверах наших клиентов:

Мониторинг RAID и проактивная замена дисков

А вот вам самое главное правило, которое я буквально вбиваю в головы каждому нашему инженеру: никогда, слышите, НИКОГДА не дожидайтесь, пока диск просто возьмёт и умрёт! Меняйте его заранее, превентивно. Ориентируйтесь на SMART-показатели, следите за событиями Predictive Failure прямо из iDRAC и обязательно отслеживайте рост счётчиков ошибок в OMSA.

Чтобы не пропустить ничего важного, мы в ITFresh настроили в нашем мониторинге Zabbix три чётких уровня оповещений для каждого сервера Dell:

• Warning — Predictive Failure на любом диске, любая запись в System Event Log с уровнем выше Info, температура CPU или дисков выше нормы.
• High — диск перешёл в статус Failed, виртуальный диск в Degraded, BBU начал процесс Learn (ёмкость батареи временно недоступна).
• Disaster — два или более Failed дисков, виртуальный диск Offline, контроллер потерял соединение.

Сборка SNMP-трапов идёт через стандартный template Dell-iDRAC9 в Zabbix, плюс мы парсим вывод omreport storage pdisk controller=0 раз в 6 часов и кидаем в Prometheus. Полная картина по парку из 87 серверов — на одном дашборде.

Типичные грабли, на которые наступают админы

За 15 лет в IT мы насмотрелись на такое количество ошибок, которые потом оборачивались для наших клиентов бессонными ночами и огромными проблемами. Вот наш анти-рейтинг, Топ-7 самых распространённых:

1. RAID 5 из 6+ дисков по 4 TB и больше. При rebuild почти гарантированный URE на одном из оставшихся дисков → массив насмерть. Только RAID 6 или RAID 60.
2. Write Back без BBU. При пропадании электричества потеряете последние 1–8 GB записей. На 1С это значит порванную базу.
3. Нет Hot Spare. «Куплю диск, когда что-то случится» — классика, заканчивающаяся выходными в офисе клиента.
4. Игнор предупреждений Predictive Failure. Контроллер за неделю-две до отказа сообщает «диск умрёт». Если игнорить — получите Failed в самый неподходящий момент.
5. Микс дисков разных серий. Контроллер примет диск, но скорость массива упадёт до самого медленного. Особенно болезненно с SSD разных моделей.
6. Не обновляют firmware PERC. Dell регулярно правит баги, в том числе криптические зависания. Обновлять минимум раз в год через Lifecycle Controller.
7. Считают RAID заменой бэкапа. Шифровальщик зашифрует все диски массива одновременно. RAID не спасёт.

Что мы делаем при приёмке нового Dell на обслуживание

Когда к нам приходит новый клиент и передаёт свой сервер Dell на обслуживание, мы всегда начинаем с нашего фирменного чек-листа. Это целых 18 пунктов! А вот первые 8 из них, те, что напрямую касаются RAID-подсистемы:

1. Снимаю инвентарь дисков через omreport storage pdisk и сохраняю в документацию.
2. Есть ли Battery Backup Unit (BBU)? А в каком он состоянии? Мы обязательно проверяем его наличие и текущий статус. Ведь это критически важно для защиты данных при внезапном отключении питания.
3. Мы очень внимательно проверяем Cache Policy на всех Virtual Drives (VD). И знаете что? Если установлен Battery Backup Unit (BBU), то Cache Policy просто обязана быть в режиме Write Back (WB). Это золотое правило, гарантирующее безопасность ваших данных.
4. А у вас есть Hot Spare? Мы всегда проверяем его наличие. Если вдруг его нет, тут же добавляем. Почему это так важно? Hot Spare — это ваш автоматический запасной диск, который сам вступит в работу при выходе из строя одного из основных, сохраняя массив функциональным.
5. Мы тщательно отслеживаем SMART-показатели всех дисков. Обнаружили, что параметр Reallocated превышает 50? Такой диск без разговоров ставится в очередь на замену. Мы не ждём полной поломки, а действуем на опережение.
6. Чтобы система работала как швейцарские часы, мы регулярно обновляем firmware. Это касается PERC, iDRAC и BIOS. Все обновления проводятся через Lifecycle Controller, что обеспечивает максимальную стабильность и безопасность.
7. Нам важно знать о каждом чихе вашей системы, чтобы оперативно реагировать на любые изменения. Поэтому мы тщательно настраиваем отправку всех SNMP-трапов непосредственно в наш центральный Zabbix. Это основа нашего проактивного мониторинга.
8. Мы регулярно запускаем Consistency Check. Зачем? Чтобы быть абсолютно уверенными: данные в массиве полностью целостны и консистентны. Ведь никто не хочет потерять важную информацию из-за скрытых ошибок.

Вы удивитесь, но эти 8 шагов занимают всего 2–3 часа и при этом не стоят клиенту ни копейки! Это просто часть нашей стандартной процедуры приёмки. Зато потом мы знаем весь ваш серверный парк как свои пять пальцев. И, что самое главное, в 3 часа ночи нам точно не звонят с паническими криками: «Ребята, у нас RAID развалился!» Тишина и спокойствие — бесценно.

FAQ — частые вопросы по PERC H730/H740

Какие уровни RAID поддерживают Dell PERC H730 и H740?

Оба контроллера поддерживают RAID 0, 1, 5, 6, 10, 50 и 60. На H740 быстрее работа с NVMe SSD за счёт более производительного процессора и 8 GB кэша против 1–2 GB у H730.

Можно ли настроить RAID без перезагрузки сервера?

Да, через OpenManage Server Administrator (OMSA) или racadm с iDRAC. Создание массива на горячую — стандартная функция начиная с PERC H700 и выше.

Что делать, если диск помечен как Foreign?

Это значит, что диск содержит конфигурацию RAID от другого контроллера. В Ctrl+R выберите Foreign View и либо импортируйте конфигурацию, либо очистите её через Clear Foreign Config.

Сколько времени занимает rebuild массива?

На SAS 10K 1.2 TB rebuild RAID 5 из 6 дисков занимает 8–14 часов. На SSD SAS 1.92 TB — 2–4 часа. На NVMe — 30–90 минут.

Нужно ли резервное копирование, если есть RAID 6?

Обязательно. RAID защищает только от отказа дисков, но не от удаления файлов, шифровальщиков, ошибок 1С и аппаратных сбоев материнской платы.