Плата контроллера массива несёт собственную микросхему памяти — от сотен мегабайт до нескольких гигабайт. Это не украшение и не способ поднять цифры в спецификации: без этого буфера схемы с чётностью работают на записи неприемлемо медленно. Но буфер создаёт и новую проблему — окно, в котором подтверждённые приложению данные физически ещё не лежат на дисках.
Зачем контроллеру собственная память
Разберём механизм на записи в массив с чётностью. Приложение меняет один блок внутри полосы. Чтобы обновить контрольную сумму, контроллеру нужно знать содержимое всей полосы, поэтому он читает старый блок данных и старую чётность, вычисляет новое значение и выполняет две записи. Одна логическая операция превращается в четыре обращения к дискам.
Буфер ломает эту арифметику двумя способами. Во-первых, он позволяет накопить несколько последовательных изменений в пределах одной полосы и переписать её целиком — тогда читать нечего, чётность считается из свежих данных, и обращений становится меньше. Во-вторых, он позволяет упорядочить операции перед отправкой на механические диски, сократив перемещения головок.
Вторая функция буфера — снятие задержки с приложения. В режиме отложенной записи контроллер подтверждает операцию, как только данные попали в его память, не дожидаясь их физической фиксации на носителе. Для приложения запись занимает микросекунды вместо миллисекунд. Именно этот режим даёт основной прирост, и именно он требует защиты.
Отложенная запись против сквозной
Альтернативный режим — сквозная запись: контроллер подтверждает операцию только после того, как данные ушли на диски. Данные в этом случае не могут потеряться при пропадании питания, но каждая запись стоит полного времени доступа к массиву. На схемах с чётностью разница между режимами измеряется разами, а на потоке мелких случайных записей — заметно больше.
Кэш на чтение работает иначе и рисков не несёт: там лежит копия того, что уже есть на дисках, и потеря буфера ничем не грозит. Опасен только грязный буфер — блоки, изменённые в памяти и ещё не записанные.
Ситуация усугубляется тем, что у самих накопителей тоже есть собственный буфер записи. Контроллер, отдавший данные диску, не обязательно получил их на носителе. Поэтому в серверных конфигурациях внутренний кэш дисков обычно отключают или требуют от накопителя честной обработки команды сброса буфера — иначе защита на уровне контроллера теряет смысл.
Чем защищают содержимое буфера
Исторически применялся аккумулятор на плате: при пропадании питания он подпитывает микросхему памяти, сохраняя грязные блоки живыми до возврата напряжения. При следующем старте контроллер обнаруживает несброшенные данные и дописывает их на диски. Ограничение очевидно — время автономности конечно, счёт идёт на десятки часов, и если сервер не подняли за этот срок, содержимое буфера теряется.
Более поздний подход убирает зависимость от времени. На плате стоит батарея конденсаторов большой ёмкости и микросхема энергонезависимой памяти. При потере питания конденсаторов хватает не на поддержание буфера, а на одну операцию — перекачку его содержимого во флеш-память. Дальше данные лежат без питания сколь угодно долго и будут применены при следующем включении.
У обоих решений есть расходуемый ресурс, и он деградирует со временем. Аккумулятор теряет ёмкость, конденсаторы — тоже. Контроллер периодически проводит проверку: разряжает элемент, замеряет фактическую ёмкость, заряжает обратно. Во время такой проверки защиты нет, поэтому контроллер сам временно переключается в сквозную запись.
Как это выглядит со стороны администратора
Типичная жалоба: сервер без видимых причин стал писать в разы медленнее, при этом ошибок нет, диски исправны, массив в норме. В подавляющем большинстве случаев причина именно здесь — контроллер снял отложенную запись. Причины две: либо идёт плановая проверка элемента питания и через несколько часов всё вернётся само, либо элемент исчерпал ресурс и режим отключён навсегда до его замены.
Отсюда практические следствия. Проверять состояние элемента защиты нужно в мониторинге наравне с состоянием дисков — это такой же расходник. Планировать проверки следует на окно низкой нагрузки, если контроллер позволяет задать расписание. И не стоит принудительно включать отложенную запись без защиты ради восстановления скорости: это ровно та настройка, которая превращает штатное отключение электричества в повреждённую базу данных. Что именно даёт резервирование по питанию на уровне сервера, разобрано в разделе о серверных блоках питания.
Твердотельные накопители и своя защита
У накопителей корпоративного класса есть собственный механизм на том же принципе: конденсаторы внутри устройства обеспечивают завершение операций, находящихся в его внутреннем буфере, при внезапном обесточивании. Это важнее, чем кажется: у твердотельного накопителя потеря питания в момент перезаписи страницы способна испортить не только записываемые данные, но и соседний блок из-за особенностей внутренней трансляции адресов. Накопитель без такой защиты в массиве с отложенной записью сводит на нет усилия контроллера.
Полная картина складывается из трёх уровней — буфер контроллера, буфер накопителя и внешнее резервирование питания. Защищать имеет смысл все три; пропущенное звено определяет реальную стойкость всей цепочки. Устройство и параметры самих плат разобраны в разделе о RAID-контроллерах.
