BBWC: теоретически хорошая идея, но сохранял ли кто-нибудь ваши данные?
Я знаком с тем, для чего предназначен BBWC (кэш записи с резервным питанием от батареи), и ранее использовал их на своих серверах даже с хорошим ИБП. Есть очевидные отказы, от которых он не защищает. Мне любопытно понять, действительно ли это дает реальную пользу на практике.
(NB, я специально ищу ответы от людей, у которых есть BBWC и у них были сбои / сбои, и помогал ли BBWC выздоровлению или нет)
Обновить
После отзывов здесь я все более скептически отношусь к тому, добавляет ли BBWC какую-либо ценность.
Чтобы быть уверенным в целостности данных, файловая система ДОЛЖНА знать, когда данные были переданы в энергонезависимое хранилище (не обязательно на диск - к этому я еще вернусь). Стоит отметить, что многие диски лгут о том, когда данные были зафиксированы на диске (http://brad.livejournal.com/2116715.html). Хотя кажется разумным предположить, что отключение кеша на диске может сделать диски более честными, все же нет гарантии, что это так.
Из-за типично больших буферов в BBWC, барьер может потребовать значительно большего количества данных для передачи на диск, что вызывает задержки при записи: общий совет - отключить барьеры при использовании энергонезависимого кеша с обратной записью (и отключить на- кэширование диска). Однако это может подорвать целостность операции записи - то, что больше данных хранится в энергонезависимой памяти, не означает, что они будут более согласованными. В самом деле, возможно, без разграничения между логическими транзакциями, кажется, меньше возможностей для обеспечения согласованности, чем в противном случае.
Если бы BBWC признал наличие барьеров в момент, когда данные поступают в его энергонезависимое хранилище (а не сохраняли их на диске), то казалось бы, что он удовлетворяет требованию целостности данных без потери производительности - подразумевая, что барьеры все же должны быть включены. Однако, поскольку эти устройства обычно демонстрируют поведение, соответствующее сбросу данных на физическое устройство (значительно медленнее с барьерами) и широко распространенным советам по отключению барьеров, они не могут вести себя таким образом. ПОЧЕМУ НЕТ?
Если ввод-вывод в ОС моделируется как серия потоков, тогда существует некоторая возможность минимизировать блокирующий эффект барьера записи, когда кэширование записи управляется ОС - поскольку на этом уровне только логическая транзакция (один поток ) необходимо совершить. С другой стороны, BBWC, не зная, какие биты данных составляют транзакцию, придется зафиксировать весь свой кеш на диске. Реализует ли ядро / файловые системы это на практике, потребует гораздо больше усилий, чем я готов вложить в данный момент.
Комбинация дисков, сообщающих неправду о том, что было совершено, и внезапная потеря питания, несомненно, приводит к повреждению - а с файловой системой с журналированием или структурированием журналов, которая не выполняет полный fsck после сбоя, маловероятно, что повреждение будет обнаружено, не говоря уже о том, чтобы сделана попытка отремонтировать.
Что касается режимов отказа, по моему опыту, наиболее внезапные отключения электроэнергии происходят из-за потери питания от сети (легко устраняется с помощью ИБП и управляемого выключения). Люди, вытаскивающие из стойки не тот кабель, подразумевают плохую гигиену в центре обработки данных (маркировка и прокладка кабелей). Есть несколько типов внезапных сбоев питания, которые не могут быть предотвращены с помощью ИБП - отказ в блоке питания или VRM, BBWC с барьерами может обеспечить целостность данных в случае сбоя, но насколько распространены такие события? Очень редко, судя по отсутствию здесь отзывов.
Конечно, повышение отказоустойчивости в стеке значительно дороже, чем BBWC, однако реализация сервера в качестве кластера имеет множество других преимуществ с точки зрения производительности и доступности.
Альтернативным способом смягчить влияние внезапной потери мощности было бы внедрение SAN - AoE делает это практическим предложением (я действительно не вижу смысла в iSCSI), но опять же, это более высокая стоимость.
Конечно. У меня был кэш с резервным питанием от батареи (BBWC) и более поздний кэш записи с резервным питанием (FBWC) для защиты данных в полете после сбоев и внезапного отключения питания.
На серверах HP ProLiant типичное сообщение:
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator
Что значит, "Эй, в кэше записи есть данные, которые пережили перезагрузку / отключение питания !! Я собираюсь записать это обратно на диск!"
Интересным случаем было мое вскрытие системы, которая потеряла мощность во время торнадо, последовательность массива была:
POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator
Ошибка POST 1793 уникальна. - Пока система использовалась, питание было отключено, пока данные находились в памяти Array Accelerator. Однако из-за того, что это был торнадо, электричество не было восстановлено в течение четырех дней, поэтому батареи массива были разряжены и данные внутри были потеряны. На сервере было два RAID-контроллера. У другого контроллера был блок FBWC, который работает намного дольше, чем батарея. Этот диск восстановился должным образом. Некоторое повреждение данных привело к массиву с разряженной батареей.
Несмотря на продолжительное время работы от батарей на объекте, четыре дня без электроэнергии и опасные условия сделали невозможным безопасное отключение серверов. 
Да, был такой случай.
Сервер «без ИБП» в ЦОД (с ИБП в ЦОД). Отказ PDU - система сильно сломалась. Без потери данных.
Вот и все. Плюс BBWC в том, что он находится в машине. Есть ИБП - поверьте, иногда кто-то делает глупости (например, выдергивает не тот кабель). ИБП внешний. Ой, ЭТО кабель;)
Кажется, это требует второго ответа на вопрос ...
У меня только что был автономный хост VMware ESXi, потерявший диск в массиве RAID 5. Ухудшенный массив повлиял на производительность на уровне виртуальной машины и приложения.
Smart Array P410i in Slot 0 (Embedded) (sn: 5001438011138950)
array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)
ИТ-специалист этой фирмы не знал, что диск вышел из строя, и полностью перезагрузил сервер (чтобы все стало лучше?).
Интересный эффект от этого для скомпрометированного массива с загруженными виртуальными машинами, работающими поверх, был следующим:
Подробные сведения о состоянии кэша: текущий контроллер массива хранил действительные данные в кэше записи, поддерживаемом батареей / конденсатором, при последнем сбросе или включении питания. Это указывает на то, что система могла быть отключена некорректно. Контроллер массива автоматически записал или попытался записать эти данные на диски. Это сообщение будет отображаться до следующего сброса или выключения контроллера массива.
Таким образом, даже несмотря на то, что система была внезапно остановлена, данные в полете были защищены BBWC. Все виртуальные машины восстановились должным образом, и теперь система находится в хорошем состоянии.
У меня было 2 случая, когда кэш с резервным питанием от батареи в HW RAID-контроллерах полностью отказал (в 2 отдельных компаниях).
BBC полагается на неудивительную идею о том, что аккумулятор работает. Загвоздка в том, что в какой-то момент батарея в контроллере выходит из строя, и что ужасно, так это то, что во многих HW raid контроллерах он выходит из строя тихо. Мы думали, что у нас есть кеш, защищенный от потери питания, но этого не произошло.
При отключении питания потеря данных в массиве RAID была настолько значительной, что все содержимое диска стало невосстановимым. Все было потеряно. В одном из случаев была машина, предназначенная исключительно для тестирования, но все же.
После этого я сказал «больше никогда», переключился на программное зеркалирование дисков (mdadm) в Linux + журнальной файловой системе, которая имеет приличную устойчивость к потере питания (ext4) и никогда не оглядывался назад. Конечно, я использовал его на серверах, на которых не было очень большого количества операций ввода-вывода.
Помимо «сохранения ваших данных» они хороши и для других целей. Они также хороши для буферизации записи (в кэш), чтобы повысить производительность подсистемы ввода-вывода, поддерживая низкий уровень очереди записи на диск. Это особенно важно для серверов, где интерактивная производительность имеет первостепенное значение, например, Citrix XenApp или Windows Terminal Services.
Это менее важно для веб-сервера или файлового сервера. Вы можете не заметить или даже привыкнуть к небольшому отставанию. Однако, когда вы щелкаете значок в приложении Office, вы ожидаете быстрого реагирования. И ваш генеральный директор тоже.