BBWC: теоретически хорошая идея, но сохранил ли кто-нибудь ваши данные?

Я знаком с тем, для чего предназначен BBWC (кэш записи с батарейным питанием), и ранее использовал их на своих серверах даже с хорошим ИБП. Есть очевидные сбои, для которых он не обеспечивает защиту. Мне любопытно понять, действительно ли это дает какую-то реальную пользу на практике.

(Примечание: я специально ищу ответы от людей, у которых есть 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 является уникальной. - Пока система использовалась, питание было прервано, когда данные были в памяти ускорителя массива. Однако из-за того, что это был торнадо, питание не было восстановлено в течение четырех дней, поэтому батареи батареи были разряжены, а данные внутри были потеряны. На сервере было два RAID-контроллера. Другой контроллер имел блок FBWC, который работает намного дольше, чем батарея. Этот диск восстановлен правильно. Некоторое повреждение данных привело к массиву, поддерживаемому разряженной батареей.

Несмотря на большое время работы от батареи на объекте, четыре дня без питания и опасных условий не позволяли никому безопасно отключать серверы.

Да, был тот случай.

Сервер "без ИБП" в центре обработки данных (с центром обработки данных, имеющим ИБП). Ошибка PDU - система сильно упала. Нет потери данных.

И это в основном все. Хорошая вещь о BBWC состоит в том, что это находится в машине. Есть ИБП - поверьте мне, иногда кто-то делает что-то глупое (например, выдергивает не тот кабель). ИБП внешний. О, это кабель;)

У меня было 2 случая, когда кэш с резервным питанием от батареи в контроллерах HW RAID полностью отказывал (в 2 отдельных компаниях).

Би-би-си полагается на неудивительную идею, что батарея работает. Загвоздка в том, что в какой-то момент батарея в контроллере выходит из строя, и что является разрушительным, это то, что во многих HW рейд-контроллерах происходит сбой бесшумно . Мы думали, что у нас есть кэш, защищенный от потери питания, но мы этого не сделали.

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

После этого я сказал «никогда больше», переключился на программное зеркалирование дисков (mdadm) в Linux + fs на основе журналов, которое имеет достойную устойчивость к потере питания (ext4) и никогда не оглядывалось назад. Конечно, я использовал его на серверах, у которых не было слишком большого количества операций ввода-вывода.

Это, кажется, требует второго ответа на вопрос ...

У меня только что был автономный хост 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. Все виртуальные машины восстановлены должным образом, и система находится в хорошем состоянии.

Помимо «сохранения ваших данных», они хороши для других вещей. Они также хороши в буферизации записи (в кеше), чтобы улучшить производительность подсистемы ввода-вывода, поддерживая низкую очередь на запись на диск. Это особенно важно для серверов, где первостепенное значение имеет интерактивная производительность - например, Citrix XenApp или Windows Terminal Services.

Это менее важно для веб-сервера или файлового сервера. Вы можете не заметить или даже привыкнуть к небольшому отставанию. Тем не менее, когда вы нажимаете на значок в приложении Office, вы ожидаете реагирования. И ваш генеральный директор тоже.