Заменяет ли UPS защиту кэша RAID-контроллера?

Нет. UPS полезен как дополнительный уровень защиты: он может дать серверу время на корректное завершение работы. Но он не защищает от отказа контроллера, сервера, блока питания, кабеля или дисковой корзины и не делает обычный энергозависимый кэш контроллера защищённым. Для Write Back нужна исправная защита dirty cache и документированное восстановление.

Защищает ли CacheVault кэш самих HDD и SSD?

Нет. CacheVault защищает подтверждённые ОС данные, которые ещё находятся в dirty cache RAID-контроллера. Внутренний write cache HDD или SSD — отдельный уровень. Его безопасность зависит от корректной обработки flush/FUA, политики кэша накопителя и, при необходимости, собственной защиты накопителя от потери питания, например PLP у SSD.

Можно ли включать Force Write Back при ошибке батареи?

Обычно контроллеры с адаптивной политикой при неисправной, отсутствующей или неготовой защите кэша переводят логический диск в Write Through. Так ведут себя указанные в статье семейства Broadcom MegaRAID, Dell PERC и HPE Smart Array, хотя точные формулировки и доступные опции зависят от модели и версии firmware. Опции Always Write Back, Forced Write Back или No-Battery Write Cache обходят это ограничение. Они не восстанавливают защиту dirty cache, а лишь разрешают подтверждать запись до её сброса на накопители. Поэтому включать их ради результатов benchmark не следует. До включения Write Back нужно проверить состояние кэша и модуля защиты, политику контроллера при отказе защиты, документированную процедуру восстановления preserved cache, а также настройки write cache самих HDD или SSD. Если статус защиты неизвестен, есть предупреждения или восстановление не подтверждено, следует использовать безопасную автоматическую политику либо Write Through.

Почему Write Through не гарантирует сохранность записи?

Write Through снижает риск, потому что контроллер ждёт завершения операции на нижнем уровне перед ответом ОС. Но гарантия зависит и от накопителей: диск может подтвердить запись, пока данные ещё находятся в его энергозависимом write cache. Нужны корректные flush/FUA, подходящая политика кэша дисков и, если требуется, защита питания накопителей.

Можно ли включить кэш записи дисков при защищённом кэше контроллера?

Не автоматически. Защищённый кэш RAID-контроллера и внутренний write cache HDD или SSD настраиваются отдельно. Наличие батареи, CacheVault или flash-backed cache не делает энергозависимый кэш диска безопасным. Включать его допустимо только при документированном соблюдении flush/FUA либо при подходящей защите накопителя от потери питания.

Поможет ли SSD с PLP сохранить данные из кэша RAID-контроллера?

Нет. PLP защищает данные и внутренние метаданные конкретного SSD при внезапной потере питания. Она не сохраняет подтверждённые записи, которые остались в памяти RAID-контроллера и ещё не были переданы накопителю. Для таких данных требуется исправная защита dirty cache контроллера и возможность его корректного восстановления после сбоя.

Кэш RAID-контроллера, Write Back и Stripe Size: выбор без лишнего риска

Режим Write-Back кэша снижает задержку записи: RAID-контроллер может подтвердить запрос ОС, когда данные ещё находятся только в его dirty cache. Включать Write Back допустимо лишь при исправной, документированно восстанавливаемой защите кэша и корректной политике накопителей. Stripe Size выбирают по профилю I/O, а медленная мелкая запись в RAID 5 обычно связана с обновлением чётности и циклом read-modify-write.

Одна запись: когда ОС получает подтверждение

Запись проходит несколько разных точек, которые нельзя считать одинаковыми: ОС получила успешный ответ; данные попали в RAID-кэш контроллера; контроллер передал их накопителю; накопитель сообщил о завершении; данные и служебные метаданные стали устойчивы к потере питания. Между этими событиями может быть заметный интервал.

Что означает подтверждение записи при разных политиках

Политика	Момент ответа ОС	Что происходит после ответа	Главное условие сохранности
Write Back	После помещения данных в dirty cache контроллера	Контроллер может объединить, переупорядочить и позднее сбросить записи на диски	Dirty cache должен быть защищён и пригоден к последующему восстановлению
Write Through	После того, как нижележащие накопители сообщили о завершении операции	Контроллер не оставляет подтверждённую запись только в собственном энергозависимом кэше	Накопители и весь стек должны корректно соблюдать flush/FUA и свою политику кэша записи

В Write Back контроллер принимает данные в грязный кэш, отвечает хосту и затем записывает накопившиеся блоки на диски. Поэтому короткие очереди записи могут завершаться с меньшей задержкой, а контроллер получает возможность собрать несколько небольших изменений в более крупные операции. Скорость не бесконечна: при длительной записи кэш заполняется, и производительность снова ограничивается массивом и накопителями.

В Write Through контроллер ждёт завершения нижнего уровня перед успехом для ОС. Это обычно увеличивает задержку и уменьшает скорость записи, особенно при небольших синхронных операциях. Но Write Through не следует трактовать как абсолютную гарантию: если диск подтвердил данные, пока они находятся лишь в его энергозависимом write cache, итог зависит от команд фиксации, возможностей устройства и защиты питания самого накопителя.

Что защищают BBU, CacheVault и суперконденсатор

BBU и комплектные системы защиты flash-backed cache, включая CacheVault, защищают не весь RAID-массив, а прежде всего подтверждённые ОС блоки, которые пока находятся в dirty cache контроллера. BBU поддерживает питание энергозависимой памяти, а flash-backed система при пропадании питания переносит содержимое кэша во флеш-память. Суперконденсатор в такой схеме служит источником энергии для переноса; сам по себе, без совместимых кэша, флеш-модуля и прошивки, он не является полноценной защитой dirty cache.

Защита кэша полезна только вместе с процедурой восстановления. После сбоя контроллер должен распознать сохранённый кэш, восстановить его содержимое и сбросить блоки на корректный массив. Условия зависят от семейства и OEM-исполнения: документация может требовать исходный или совместимый контроллер, совместимый модуль защиты, сохранённую конфигурацию и определённый порядок включения. При preserved или dirty cache не следует самовольно менять контроллер, разъединять модуль защиты или очищать конфигурацию; порядок действий описан в статье «BBU, CacheVault и суперконденсатор RAID-контроллера: проверка и замена».

UPS не заменяет защиту RAID-кэша

Источник бесперебойного питания может дать серверу время корректно завершить работу и остаётся полезным дополнительным уровнем защиты. Но UPS не устраняет отказ самого сервера, RAID-контроллера, блока питания, кабеля или соединения с дисковой корзиной. Он также не превращает обычный энергозависимый кэш контроллера в защищённый.

Когда включать Write Back, а когда оставить Write Through

Проверка перед включением Write Back

Порядок применим как логика принятия решения; названия статусов и опций зависят от модели контроллера, OEM-исполнения и версии прошивки.

1
Проверьте статус кэша и модуля защиты
Контроллер должен сообщать, что write cache доступен, а BBU, flash-модуль или суперконденсатор исправен и заряжен либо готов к работе. Зафиксируйте модель контроллера, OEM-вариант, версию firmware и точный текст предупреждений.
2
Подтвердите политику при отказе защиты
Из документации именно вашей модели выясните, отключает ли она write cache или переводит logical drive в Write Through при неисправной защите, и существует ли Force Write Back. Наличие такой опции не означает, что её безопасно применять.
3
Проверьте восстановление защищённого кэша
Должна быть документирована процедура обнаружения и сброса preserved cache после сбоя, включая требования к совместимости контроллера и модулей. Для работающего массива нельзя проверять это экспериментом без отдельного плана восстановления.
4
Проверьте нижний уровень хранения
Уточните настройки write cache HDD или SSD, обработку flush/FUA контроллером и накопителями, а для SSD — наличие защиты от потери питания, если она требуется выбранной схемой.
5
Оставьте безопасную автоматическую политику при сомнениях
Если защита кэша неисправна, её состояние неизвестно, восстановление не подтверждено или есть предупреждения контроллера, оставьте политику, выбранную контроллером, либо используйте Write Through до устранения причины.

Примеры относятся только к указанным семействам и редакциям документации. Перед изменением политики нужно сопоставить точную модель, OEM-исполнение, firmware и руководство: названия модулей и режимов нельзя переносить между поколениями.

Контроллер и источник	Защита кэша	Поведение при проблеме защиты	Принудительная политика и кэш накопителей
Broadcom MegaRAID SAS 9361-8i — руководство «12Gb/s MegaRAID SAS Software User Guide», документ 54183, Rev. F	CacheVault CVM02: флеш-модуль кэша и модуль суперконденсатора	Для политики Write Back с учётом состояния защиты контроллер переходит на Write Through, если CacheVault отсутствует или неисправен	Always Write Back разрешает запись вопреки состоянию защиты и повышает риск потери подтверждённых данных. Политика disk cache задаётся отдельно; наличие CacheVault не защищает энергозависимый кэш самого диска
Dell PERC H730/H730P — «Dell EMC PowerEdge RAID Controller 9 User’s Guide», Rev. A14	Энергонезависимый кэш контроллера с батарейным модулем	При неисправной или неготовой батарее адаптивная политика Write Back переводит виртуальный диск в Write Through	Forced Write Back может сохранить Write Back без исправной защиты. Disk Cache Policy является отдельной настройкой и не становится безопасной только из-за батареи PERC
HPE Smart Array P408i-a SR Gen10 — «HPE Smart Array SR Gen10 Controller User Guide», Part Number 882375-008	Flash-backed write cache с HPE Smart Storage Battery	Защищённая запись недоступна, пока батарея отсутствует, неисправна или не готова; после восстановления готовности контроллер может снова задействовать кэш	No-Battery Write Cache является отдельным небезопасным разрешением записи без готовой защиты. Physical Drive Write Cache настраивается отдельно и требует самостоятельного обоснования сохранности данных

Не включайте Force Write Back ради benchmark

Принудительный Write Back при Battery Low, CacheVault error, cache protection failed или аналогичном предупреждении может сделать запись видимо успешной для ОС, хотя она остаётся только в энергозависимой памяти контроллера. При сбое питания, зависании контроллера или отказе сервера такие уже подтверждённые записи могут не попасть на накопители. Точная доступность Force Write Back и формулировки предупреждений различаются между моделями и прошивками.

Кэш самих HDD и SSD: flush, FUA и PLP

После сброса блока из RAID-кэша контроллера данные могут оказаться во внутреннем write cache HDD или SSD. Это отдельный уровень кэширования. Команда завершена для контроллера не всегда означает, что данные уже записаны в энергонезависимую область накопителя.

Для упорядоченной фиксации записи стек хранения использует flush и FUA (Force Unit Access). Flush требует завершить ранее принятые записи до подтверждения барьера, а FUA требует устойчиво зафиксировать конкретную запись до сообщения о её завершении. У аппаратного RAID эти команды сначала получает логический диск контроллера: дальнейшее поведение определяется сочетанием драйвера, firmware, политики RAID-кэша и настроек накопителей. У MegaRAID 9361-8i, Dell PERC H730/H730P и HPE Smart Array P408i-a политика внутреннего write cache дисков регулируется отдельно от защищённого кэша контроллера. Поэтому наличие CacheVault, батареи или flash-backed cache нельзя считать разрешением на включение энергозависимого disk write cache: такое включение допустимо только при документированном соблюдении команд фиксации либо при подходящей защите от потери питания у накопителя.

PLP у SSD помогает накопителю сохранить данные и внутренние метаданные при внезапной потере питания. Однако SSD с PLP не заменяет защищённый кэш RAID-контроллера: PLP защищает состояние конкретного SSD, а не подтверждённые данные, оставшиеся в памяти контроллера. Аналогично UPS не отменяет необходимость корректных flush/FUA и документированной политики кэшей. Особенности SSD и NVMe RAID разобраны отдельно в статье о RAID на SSD, M.2 и NVMe.

Stripe Size: принятая терминология и расчёт полной полосы

В этой статье Stripe Size — это размер элемента полосы на одном диске: объём последовательных данных, после которого запись переходит к следующему data-диску. В интерфейсах производителей этот параметр может называться strip size, stripe element size или stripe size; одинаковое название не гарантирует одинаковый смысл. Перед настройкой сопоставьте термин с руководством конкретного контроллера и версии firmware.

Полная полоса данных — это все элементы данных одной полосы RAID без элементов чётности. В принятой терминологии: размер полной полосы данных = Stripe Size × число элементов данных в полосе. Для массива из N дисков таких элементов обычно N−1 в RAID 5 и N−2 в RAID 6. Это не означает, что отдельные накопители постоянно назначены дисками данных или чётности: в обычной распределённой схеме размещение блоков чётности меняется между полосами.

Примеры расчёта полной полосы данных

Конфигурация	Stripe Size на одном диске	Число data-дисков	Полная полоса данных
RAID 5 из 5 дисков	256 KiB	4	1024 KiB, то есть 1 MiB
RAID 6 из 6 дисков	128 KiB	4	512 KiB

Не переносите значения между контроллерами

Диапазоны Stripe Size, значение по умолчанию и возможность изменить параметр после создания logical drive зависят от конкретной модели, firmware и интерфейса управления. Если нет подтверждённого профиля нагрузки и документации, разумнее оставить документированное значение по умолчанию. Создание и настройка logical drive описаны отдельно для Dell PERC и HPE Smart Array.

Как соотнести Stripe Size с нагрузкой

Stripe Size не выбирают по универсальной таблице «для базы данных — одно значение». Важны фактический размер I/O, случайность доступа, глубина очереди, параллелизм, доля записи, файловая система, кэш приложения и возможность контроллера объединять запросы. Размер страницы СУБД сам по себе не определяет оптимальный размер элемента полосы.

Преимущественно последовательные большие записи. Более крупный элемент полосы может быть уместен, если приложение обычно передаёт большие непрерывные блоки и массив способен формировать полные полосы. Проверяют не только пиковую пропускную способность, но и устойчивую запись после заполнения кэша.
Мелкие случайные I/O. Изменение Stripe Size само по себе не устраняет read-modify-write при неполной записи полосы. Результат зависит от выравнивания запросов, их распределения, параллелизма и способности контроллера объединять записи. Размер страницы СУБД или блока файловой системы нельзя механически принимать за оптимальный Stripe Size: несколько допустимых значений сравнивают на репрезентативной устойчивой нагрузке.
Файловый сервер со смешанными файлами. Здесь встречаются и последовательные копирования, и мелкие случайные обновления. Начинать стоит с документированного значения по умолчанию контроллера, затем сопоставлять наблюдаемые размеры I/O и задержки с реальной нагрузкой.
База данных или виртуальные машины. Типичны случайные чтения и записи разного размера, иногда с требованиями к синхронной фиксации. Stripe Size оценивают вместе с RAID-уровнем, защищённым кэшем, выравниванием и хвостовой задержкой; для проектирования хранилища ВМ полезна отдельная статья «RAID для VMware, ESXi и Hyper-V».

Изменение Stripe Size не является безусловной оптимизацией. Оно может требовать создания нового логического диска и миграции данных, а эффект одной настройки на другом количестве дисков меняется вместе с размером полной полосы. Предположение следует проверять репрезентативной нагрузкой, а не только кратким тестом из кэша; методика измерений приведена в материале о производительности RAID.

Почему RAID 5 медленно выполняет часть мелких записей

В RAID 5 данные дополняет чётность. Если небольшая запись меняет лишь часть полосы, контроллеру часто нужен цикл чтение-модификация-запись: прочитать старый data-блок и старый блок чётности, вычислить новую чётность, затем записать новый data-блок и новую чётность. Дополнительная работа увеличивает задержку и внутреннюю нагрузку массива.

Упрощённая классическая модель для малой неполной записи RAID 5 — два чтения и две записи на стороне массива. Для RAID 6 модель обычно включает дополнительное чтение и запись второго блока чётности. Это описание backend I/O, а не постоянное число физических команд, не гарантированный коэффициент падения скорости и не прямой прогноз IOPS: контроллер может использовать другие алгоритмы, кэш, очереди, предвыборку и оптимизацию размещения.

Именно эту дополнительную внутреннюю работу называют штрафом записи RAID. Он заметнее при мелкой случайной записи, когда запросы плохо объединяются. При полной полосовой записи контроллер получает новые данные для всех data-элементов полосы, вычисляет чётность по ним и не обязан читать прежние данные и прежнюю чётность.

Когда кэш помогает RAID 5, а когда нужно пересмотреть RAID-уровень

RAID-контроллер с защищённым кэшем может накапливать, объединять и переупорядочивать записи. Это повышает вероятность full-stripe write и сглаживает часть штрафа RAID 5. Такой эффект особенно возможен при кратковременных всплесках и достаточной очереди запросов.

Кэш не отменяет ограничений массива при продолжительной интенсивной записи: dirty cache заполняется, контроллер начинает ждать накопители, а при проблеме с защитой может перейти в Write Through. Он также мало помогает, если запись нужно немедленно фиксировать, запросы не удаётся объединить или сам массив не обеспечивает нужную устойчивую задержку.

RAID 5 может быть приемлем для read-heavy или преимущественно последовательной нагрузки, если измеренная задержка и устойчивое число операций соответствуют требованиям. Для постоянной мелкой случайной записи, нагруженных баз данных и групп виртуальных машин часто рассматривают уровень с более предсказуемым поведением записи, например RAID 10. Это не автоматическое правило: решение требует одновременно оценить профиль I/O, полезную ёмкость, допустимый режим отказа и Rebuild. Сравнение уровней приведено в статье о RAID 0, 1, 5, 6 и 10.

RAID не заменяет резервные копии

Защищённый Write Back снижает риск потери подтверждённых, но ещё не сброшенных записей при части сбоев. Он не защищает от удаления данных, ошибок приложения, повреждения файловой системы, отказа нескольких компонентов или неверных действий с конфигурацией. Для возврата к прежнему состоянию нужны независимые проверяемые резервные копии: почему RAID — не резервное копирование.

Термины в статье

Аппаратный RAID: Реализация RAID, в которой специализированный контроллер формирует логические диски и выполняет операции массива. Наличие и защита кэша зависят от модели.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Грязный кэш: Грязный кэш содержит изменённые блоки, ещё не записанные в постоянное хранилище. Такие блоки нельзя безопасно отбросить до их сброса.
Дисковая корзина: Дисковая корзина — узел шасси с отсеками для установки нескольких накопителей и организации их подключения к питанию и контроллеру либо HBA.
Защита от потери питания: Защита от потери питания — функция SSD, сохраняющая данные и метаданные из энергозависимого кэша при внезапном отключении питания за счёт накопленной энергии.
Кэш со сквозной записью: Кэш со сквозной записью — режим, в котором кэш не подтверждает запись раньше нижележащего хранилища и не оставляет подтверждённые данные только в своей энергозависимой памяти.
Кэширование записи: Кэширование записи — временное размещение записываемых данных в быстрой памяти перед их передачей в нижестоящее хранилище для снижения задержки и оптимизации ввода-вывода. Момент подтверждения записи и гарантия её сохранности зависят от политики кэша и всех уровней стека хранения.
Логический диск: Логический диск — блочное устройство, которое RAID-контроллер или программная RAID-подсистема предоставляет хосту как отдельный накопитель.
Полная полосовая запись: Запись в RAID с чётностью, заменяющая все блоки данных одной полосы. Новая чётность вычисляется по поступившим данным, поэтому старые данные и чётность читать не требуется.
Полоса RAID: Полоса RAID — набор блоков одного логического диапазона, распределённых между дисками массива; в RAID 5 и RAID 6 она также включает блоки чётности.
Суперконденсатор: Накопитель энергии высокой мощности, применяемый для кратковременного питания кэша RAID-контроллера. При сбое питания он сохраняет данные до записи во флеш-память.
Чётность: Избыточные контрольные данные, вычисляемые из блоков одной полосы RAID. Один блок чётности защищает от отказа одного диска, два независимых блока RAID 6 — от отказа двух.
Чтение-модификация-запись: Чтение-модификация-запись — цикл частичной записи RAID-полосы: контроллер читает прежние данные и контрольную информацию, пересчитывает их и записывает обновление.
Штраф записи RAID: Штраф записи RAID — условное число внутренних дисковых операций на одну небольшую логическую запись, обусловленное зеркалированием или обновлением чётности.
BBU: Аккумуляторный модуль, поддерживающий питание энергозависимого кэша RAID-контроллера при сбое питания до восстановления питания и записи данных на диски.
CacheVault: CacheVault — технология защиты кэша записи RAID-контроллера, сохраняющая во флеш-память подтверждённые хосту, но ещё не записанные на диски данные при потере питания.
Dell PERC: Семейство RAID-решений Dell для серверов PowerEdge: аппаратные контроллеры PERC H и программные PERC S. Возможности и совместимость зависят от модели и поколения платформы.
Failed: Failed — статус физического накопителя, который RAID-контроллер признал отказавшим и перестал использовать для штатного ввода-вывода в составе массива.
HPE Smart Array: Семейство аппаратных и программных RAID-решений HPE для локальных SAS/SATA-накопителей и, в поддерживаемых tri-mode-конфигурациях, NVMe.
IOPS: IOPS — число завершённых операций ввода-вывода в секунду, которое накопитель, RAID-массив или СХД обеспечивает при заданном профиле нагрузки.
MegaRAID: Семейство аппаратных RAID-контроллеров Broadcom, которые объединяют накопители в массивы и предоставляют ОС логические диски, обрабатывая RAID на самом контроллере.
NVMe: NVMe — протокол обмена командами с энергонезависимыми накопителями, оптимизированный для параллельного ввода-вывода; локальные NVMe-SSD обычно подключаются по PCIe.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
RAID 10: Комбинированный уровень: чередование (RAID 0) поверх зеркальных пар (RAID 1). Сочетает высокую скорость и отказоустойчивость, отдавая под избыточность половину ёмкости.
RAID 5: RAID 5 — уровень RAID с чередованием данных и распределённой чётностью, выдерживающий отказ одного диска. Требует минимум трёх дисков.
RAID 6: Уровень RAID с чередованием данных и двойной распределённой чётностью. Выдерживает отказ любых двух дисков; минимум четыре диска.
RAID-контроллер: Устройство или модуль, который формирует RAID-массивы из накопителей и предоставляет ОС логические диски, управляя размещением данных, отказами и восстановлением избыточности.
RAID-кэш: Буфер быстрой памяти между хостом и накопителями RAID, используемый для кэширования чтения и записи. Может снижать задержку и повышать производительность ввода-вывода.
Rebuild: Процесс восстановления избыточности массива после замены отказавшего диска: контроллер вычисляет и записывает на новый диск недостающие данные из остальных дисков.
Stripe Size: Параметр чередования RAID: объём последовательных данных, размещаемых на одном диске до перехода к следующему. Значение термина stripe size зависит от вендора.
Write-Back кэш: Политика кэша RAID-контроллера: запись подтверждается после помещения данных в кэш, а на накопители переносится позже. Кэш требует защиты от потери питания.