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

PERC H730 установлен в серверах Dell PowerEdge 13-го поколения (R630, R730, R730xd, T630). В ходе аудита мы зафиксировали ключевые параметры контроллеров клиента:

• Процессор: LSI SAS3108 ROC с частотой 1.2 ГГц
• Кэш-память: 1 ГБ DDR3 с защитой от потери данных (NV cache)
• Интерфейс: SAS 3.0 (12 Гбит/с), обратная совместимость с SAS 6 Гбит/с и SATA 6 Гбит/с
• Максимум дисков: до 32 физических дисков
• Поддерживаемые RAID: 0, 1, 5, 6, 10, 50, 60
• Формат: Mini Mono (интегрированный) или адаптер PCIe

Контроллер оснащён батареей или суперконденсатором для защиты кэша при внезапном отключении питания. У одного из серверов клиента батарея была в статусе Degraded — это означало, что политика записи автоматически переключилась на Write Through, что в 5–10 раз медленнее. Мы сразу запланировали замену.

PERC H740 — контроллер для серверов 14-го поколения (R640, R740, R740xd, R940). На сервере R740xd клиента мы зафиксировали следующие характеристики:

• Процессор: LSI SAS3516 ROC с улучшенной производительностью
• Кэш-память: 8 ГБ DDR4 с NV-защитой (в 8 раз больше H730)
• Максимум дисков: до 64 физических дисков
• Поддержка NVMe: возможность создания RAID из NVMe-накопителей (PERC H740P)
• Улучшенная производительность: до 930 000 IOPS на случайное чтение

Увеличенный кэш H740 особенно заметен при интенсивной случайной записи — контроллер аккумулирует больше операций и записывает их оптимальными блоками. Для базы данных логистической системы это было критически важным преимуществом, которое мы использовали при перенастройке.

В ходе осмотра мы задокументировали форм-факторы контроллеров на серверах клиента:

Все три сервера клиента были оснащены контроллерами в формате Mini Mono, интегрированными на материнскую плату. Адаптерная версия используется, когда требуется второй RAID-контроллер для разделения нагрузки.

RAID 0 (Striping) — данные равномерно распределяются между дисками без избыточности. Обеспечивает максимальную производительность и полное использование дискового пространства. Выход из строя любого диска приводит к потере всех данных. Минимум: 2 диска.

RAID 1 (Mirroring) — зеркалирование данных на два диска. Каждый блок записывается дважды. Потеря одного диска не влияет на доступность данных. Эффективность использования пространства — 50%. Минимум: 2 диска.

RAID 5 (Striping with Parity) — данные и контрольные суммы (parity) распределяются между всеми дисками. Выдерживает выход одного диска. Эффективность: (N-1)/N. Минимум: 3 диска. Оптимален для файловых серверов и общего назначения.

RAID 6 (Dual Parity) — аналог RAID 5, но с двойной чётностью. Выдерживает одновременный выход двух дисков. Эффективность: (N-2)/N. Минимум: 4 диска. Рекомендуется для массивов с большими дисками, где rebuild занимает много часов.

RAID 10 (1+0) — комбинация зеркалирования и чередования. Данные сначала зеркалируются (RAID 1), затем зеркальные пары объединяются чередованием (RAID 0). Минимум: 4 диска. Эффективность: 50%. Выдерживает выход одного диска в каждой зеркальной паре. Лучший выбор для баз данных с интенсивной записью.

RAID 50 (5+0) — несколько групп RAID 5, объединённых в RAID 0. Минимум: 6 дисков. Выдерживает выход одного диска в каждой группе RAID 5. Хороший баланс производительности и ёмкости при большом количестве дисков.

RAID 60 (6+0) — несколько групп RAID 6, объединённых в RAID 0. Минимум: 8 дисков. Выдерживает выход двух дисков в каждой группе. Максимальная отказоустойчивость для больших массивов.

На основе анализа нагрузки и дискового состава серверов клиента мы разработали следующий план:

• Системный диск ОС (2 диска): RAID 1 — надёжность при минимуме дисков. Применили на всех трёх серверах
• Файловый сервер (6 дисков, R730 #1): RAID 6 — защита от двойного отказа, учитывая диски 4 ТБ NL-SAS
• База данных логистики (4 диска SAS 15K, R730 #2): RAID 10 — максимальная производительность случайной записи
• Хранилище архивов и бэкапов (8 дисков, R740xd): RAID 60 — максимальная отказоустойчивость при большой ёмкости
• Кэш для 1С (2 SSD, R730 #2): RAID 1 — скорость + зеркалирование

Важно: мы настояли на RAID 6 вместо RAID 5 для файлового сервера. При использовании дисков ёмкостью 4 ТБ и более время ребилда может превышать 24 часа, и вероятность выхода второго диска во время восстановления существенно возрастает. Именно эту ситуацию клиент уже пережил — и чудом не потерял данные.

При загрузке серверов Dell PowerEdge контроллер PERC инициализируется на раннем этапе POST. Для H730 на экране появляется приглашение Press Ctrl+R for PERC Configuration Utility. Для серверов 14-го поколения с H740 мы использовали System Setup (F2) → Device Settings.

Главный экран конфигуратора отображает:

• Controller: модель контроллера, версия прошивки, серийный номер
• Virtual Disks: список существующих виртуальных дисков (RAID-массивов)
• Physical Disks: список подключённых физических дисков с их состоянием
• Properties: параметры контроллера (кэш, политики чтения/записи)

На одном из серверов мы сразу увидели диск в статусе «Predictive Failure» — SMART предупреждал о скором выходе из строя. Мы зафиксировали это и включили замену диска в план работ.

Пошаговый процесс, который мы применили при создании RAID-массивов на серверах клиента:

Шаг 1. Выбираем контроллер PERC в списке устройств и нажимаем Enter.

Шаг 2. Выбираем Configuration Management → Create Virtual Disk.

Шаг 3. Указываем уровень RAID из выпадающего списка (RAID 0, 1, 5, 6, 10, 50, 60).

Шаг 4. В разделе Select Physical Disks отмечаем диски для массива:

• Выбираем тип интерфейса: SAS или SATA
• Выбираем тип накопителя: HDD или SSD
• Отмечаем конкретные диски чекбоксами
• Нажимаем Apply Changes

Шаг 5. Настраиваем параметры виртуального диска:

• Virtual Disk Name: понятное имя (мы использовали OS_Mirror, Data_RAID6, DB_RAID10)
• Virtual Disk Size: размер (по умолчанию — максимальный доступный)
• Strip Size: размер полосы (64 КБ для базы данных, 256 КБ для файлового хранилища)
• Read Policy: Read Ahead для файлового сервера, No Read Ahead для БД
• Write Policy: Write Back (быстрее, требует исправную батарею)

Шаг 6. Подтверждаем создание и дожидаемся инициализации.

Совет от наших инженеров: при создании массива для ОС мы всегда выбираем Fast Initialize вместо Full Initialize. Полная инициализация записывает нули на все диски и может занять несколько часов на больших массивах. Fast Initialize инициализирует только первые блоки.

Мы тщательно настроили политики кэширования под каждый тип нагрузки на серверах клиента:

Read Policy (политика чтения):

• Read Ahead: применили для файлового сервера — контроллер опережающе читает данные в кэш. Оптимально для последовательного чтения (потоковые операции с документами)
• No Read Ahead: применили для сервера базы данных — данные читаются только по запросу. Лучше для случайного чтения
• Adaptive Read Ahead: применили для архивного хранилища — контроллер автоматически переключается между режимами

Write Policy (политика записи):

• Write Back: применили на всех серверах после замены батареи — данные сначала записываются в кэш, затем на диски. Производительность записи в 5-10 раз выше. Требует исправную батарею/суперконденсатор!
• Write Through: временно использовали на сервере с разряженной батареей до её замены

Strip Size (размер полосы):

• 64 КБ: для сервера базы данных — хорош для смешанной нагрузки
• 256 КБ: для файлового сервера — для больших последовательных операций с документами
• 64 КБ: для архивного хранилища — универсальный вариант

На серверах клиента работал Windows Server, поэтому установка OMSA выглядела следующим образом:

# Скачиваем пакет с сайта Dell (dell.com/openmanagemanual)
# Или через Dell System Update (DSU)

# Установка DSU
msiexec /i Systems-Management_Application_GG4GH_WN64_2.0.0.0_A00.msi /quiet

# Установка OMSA через DSU
dsu --component-type=OMSA

# Или ручная установка:
SysMgmtx64.exe /auto /report=C:\omsa_install.log

Для Linux-серверов (если потребуется в будущем) мы оставили клиенту инструкцию:

# Добавляем репозиторий Dell
wget -q -O - https://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash

# Установка через DSU
yum install dell-system-update
dsu --component-type=OMSA

# Запуск сервисов
srvadmin-services.sh start

# Веб-интерфейс доступен на порту 1311
# https://server-ip:1311

После установки веб-интерфейс OMSA стал доступен по адресу https://server-ip:1311 на каждом сервере.

Мы обучили IT-специалиста клиента основным командам мониторинга через omreport:

# Общий статус контроллеров
omreport storage controller

# Список виртуальных дисков (RAID-массивов)
omreport storage vdisk controller=0

# Подробная информация о конкретном массиве
omreport storage vdisk controller=0 vdisk=0

# Список физических дисков
omreport storage pdisk controller=0

# Состояние конкретного диска
omreport storage pdisk controller=0 pdisk=0:0:0

# Проверка состояния батареи контроллера
omreport storage battery controller=0

# Журнал событий контроллера
omreport storage log controller=0

Расшифровка состояний виртуальных дисков, которую мы передали клиенту:

• Ready: массив работает нормально
• Degraded: один или несколько дисков вышли из строя, массив работает с пониженной отказоустойчивостью
• Rebuilding: идёт восстановление массива после замены диска
• Failed: массив неработоспособен, данные недоступны

Часть массивов мы создали непосредственно из ОС без перезагрузки, используя omconfig:

# Создание RAID 5 из трёх дисков
omconfig storage controller action=createvdisk \
  controller=0 raid=r5 \
  pdisk=0:1:0,0:1:1,0:1:2 \
  size=max stripesize=64kb \
  readpolicy=ra writepolicy=wb \
  name=Data_RAID5

# Создание RAID 10 из четырёх дисков
omconfig storage controller action=createvdisk \
  controller=0 raid=r10 \
  pdisk=0:1:0,0:1:1,0:1:2,0:1:3 \
  size=max stripesize=64kb \
  name=DB_RAID10

# Назначение Hot Spare для конкретного массива
omconfig storage controller action=assigndedicatedhotspare \
  controller=0 vdisk=0 pdisk=0:1:4

# Назначение глобального Hot Spare
omconfig storage controller action=assignglobalhotspare \
  controller=0 pdisk=0:1:4

# Изменение политики записи
omconfig storage vdisk action=changepolicy \
  controller=0 vdisk=0 writepolicy=wb

# Расширение массива (добавление диска)
omconfig storage vdisk action=expand \
  controller=0 vdisk=0 pdisk=0:1:4 size=max

Контроллеры PERC поддерживают два типа Hot Spare. Мы применили оба:

Dedicated Hot Spare (выделенный):

• Привязан к конкретному виртуальному диску
• Активируется только при сбое в «своём» массиве
• Должен быть не меньше самого маленького диска в массиве
• Мы назначили для массивов с базой данных — критичные данные

Global Hot Spare (глобальный):

• Доступен для всех массивов на контроллере
• Активируется для первого массива, который перейдёт в состояние Degraded
• Мы назначили по одному на каждый сервер — универсальная страховка

Настройка через BIOS PERC: выбираем физический диск → Assign as Hot Spare → выбираем тип (Dedicated или Global) → указываем целевой массив для Dedicated.

На основе нашего опыта мы применили следующую стратегию:

Для серверов клиента с несколькими массивами (RAID 1 для ОС и RAID 6 для данных) мы реализовали:

• 1 Dedicated Hot Spare для массива данных (RAID 6) на каждом сервере
• 1 Global Hot Spare на каждом сервере для всех массивов

Hot Spare должен быть того же типа (SAS/SATA, HDD/SSD) и не меньшего объёма, чем диски в массиве. Контроллер PERC не позволит назначить несовместимый диск в качестве Hot Spare. Мы заказали 6 дополнительных дисков — по 2 на каждый сервер.

Критически важно: мы настроили регулярную проверку состояния Hot Spare дисков. Неактивный Hot Spare может выйти из строя незаметно, и при отказе рабочего диска автоматическая замена не произойдёт. Эту проверку мы включили в автоматический мониторинг.

Поскольку Hot Spare на сервере клиента не было, мы действовали поэтапно:

Шаг 1. Определили вышедший из строя диск:

# Через omreport
omreport storage pdisk controller=0 | findstr /i "failed\|offline"

# Или в PowerShell через Dell RACADM
racadm raid get pdisks -o

Шаг 2. Физически заменили диск. Серверы Dell PowerEdge поддерживают горячую замену (Hot Swap) — выключать сервер не потребовалось. Логистические операции продолжались.

Шаг 3. Новый диск автоматически определился как «Ready». Запустили ребилд:

# Через omconfig
omconfig storage pdisk action=replacemember \
  controller=0 pdisk=0:1:5

# Или назначили новый диск в массив
omconfig storage vdisk action=rebuild \
  controller=0 vdisk=0

Шаг 4. Мониторили прогресс до завершения:

# Прогресс ребилда
omreport storage vdisk controller=0 vdisk=0 | findstr -i "progress\|state"

На сервере клиента с дисками 4 ТБ NL-SAS ребилд занял около 18 часов. Вот справочная таблица времени восстановления для разных конфигураций:

Во время ребилда производительность массива снижается на 30-60%. Наши рекомендации клиенту:

• Планируйте замену дисков на период низкой нагрузки (ночь, выходные)
• Мы увеличили приоритет ребилда через OMSA: Controller Properties → Rebuild Rate с 30% до 60% на ночь
• Не запускайте проверки целостности (Consistency Check) во время ребилда

Наши инженеры написали и внедрили скрипт автоматической проверки состояния RAID:

# Скрипт мониторинга RAID Dell PERC
# Разработан инженерами АйТи Фреш

$ErrorActionPreference = 'Stop'
$smtpServer = 'mail.company.ru'
$adminEmail = 'admin@company.ru'
$serverName = $env:COMPUTERNAME

# Получаем статус виртуальных дисков
$vdiskOutput = & omreport storage vdisk controller=0 -fmt ssv
$degraded = $vdiskOutput | Select-String -Pattern 'Degraded|Failed|Rebuilding'

# Получаем статус физических дисков
$pdiskOutput = & omreport storage pdisk controller=0 -fmt ssv
$failedDisks = $pdiskOutput | Select-String -Pattern 'Failed|Offline|Predictive'

# Проверяем батарею контроллера
$batteryOutput = & omreport storage battery controller=0 -fmt ssv
$batteryIssue = $batteryOutput | Select-String -Pattern 'Degraded|Failed|Charging'

if ($degraded -or $failedDisks -or $batteryIssue) {
    $body = @"
Сервер: $serverName
Дата: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')

--- Виртуальные диски ---
$($degraded -join "`n")

--- Физические диски ---
$($failedDisks -join "`n")

--- Батарея контроллера ---
$($batteryIssue -join "`n")
"@
    Send-MailMessage -From "raid-monitor@$serverName" `
        -To $adminEmail -Subject "[RAID ALERT] $serverName" `
        -Body $body -SmtpServer $smtpServer -Encoding UTF8
}

# Мы настроили запуск по расписанию (каждый час)
$trigger = New-ScheduledTaskTrigger -RepetitionInterval (New-TimeSpan -Hours 1) -At '00:00' -Daily
$action = New-ScheduledTaskAction -Execute 'powershell.exe' `
    -Argument '-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\Check-RAIDHealth.ps1'
Register-ScheduledTask -TaskName 'RAID Health Check' -Trigger $trigger -Action $action `
    -User 'SYSTEM' -RunLevel Highest

Для централизованного мониторинга всех трёх серверов мы настроили SNMP-трапы от OMSA:

# Включение SNMP-трапов
omconfig system alertaction event=virtualDiskDegraded \
  snmpdest=monitoring-server.company.ru community=public

omconfig system alertaction event=physicalDiskFailure \
  snmpdest=monitoring-server.company.ru community=public

omconfig system alertaction event=batteryWarning \
  snmpdest=monitoring-server.company.ru community=public

Ключевые события, которые мы настроили на отслеживание:

• Physical Disk Predictive Failure: SMART предупреждение — диск скоро выйдет из строя. Запланировать замену!
• Virtual Disk Degraded: массив работает в аварийном режиме. Немедленная замена диска
• Battery Low/Failed: кэш контроллера не защищён. Write-back отключается, производительность падает
• Rebuild Started/Completed: информационные события для журнала

Мы также развернули шаблон Template Dell PERC из репозитория Zabbix Community Templates. Шаблон опрашивает omreport и отслеживает все критичные метрики — теперь IT-специалист клиента видит состояние всех серверов в единой панели.

После завершения всех работ мы провели замеры производительности, чтобы продемонстрировать клиенту результат. Тестирование проводилось утилитами CrystalDiskMark и fio:

RAID 10 на сервере базы данных значительно превзошёл прежнюю конфигурацию по случайной записи. Переключение на Write Back после замены батареи контроллера дало прирост в 5-8 раз по сравнению с Write Through. Контроллер H740 с его 8 ГБ кэша показал на 10-15% лучшие результаты при интенсивной записи по сравнению с H730.

При установке новых дисков (один из них ранее использовался в другом сервере) контроллер обнаружил метаданные «чужого» RAID-массива. На экране появилось сообщение Foreign Configuration Found.

Мы выбрали Clear — так как данные на диске были не нужны:

# Очистка Foreign Configuration через omconfig
omconfig storage controller action=clearforeignconfig controller=0

# Если бы нужно было импортировать данные:
omconfig storage controller action=importforeignconfig controller=0

Внимание: при импорте конфигурации необходимо убедиться, что ВСЕ диски из оригинального массива перенесены. Импорт неполного набора дисков приведёт к массиву в состоянии Degraded или Failed.

Мы настроили регулярные проверки целостности на всех серверах клиента:

Patrol Read — фоновое чтение всех секторов дисков для обнаружения плохих блоков. Мы оставили автоматический режим (раз в 7 дней).

Consistency Check — проверка целостности массива: контроллер пересчитывает и сверяет контрольные суммы для RAID 5/6/50/60.

# Запуск Consistency Check вручную
omconfig storage vdisk action=checkconsistency controller=0 vdisk=0

# Настройка расписания Patrol Read
omconfig storage controller action=setpatrolreadmode \
  controller=0 mode=auto

# Ручной запуск Patrol Read
omconfig storage controller action=startpatrolread controller=0

Мы настроили ежемесячный Consistency Check через планировщик задач в период минимальной нагрузки (воскресенье, 3:00 ночи). Это позволяет обнаружить и исправить битовые ошибки (bit rot) до того, как они станут критичными.