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


26

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

(Примечание: я специально ищу ответы от людей, у которых есть BBWC и у которых были сбои / сбои и помогло ли BBWC восстановлению или нет)

Обновить

После обратной связи я все более скептически отношусь к тому, добавляет ли BBWC какую-либо ценность.

Чтобы иметь какую-либо уверенность в целостности данных, файловая система ДОЛЖНА знать, когда данные были переданы в энергонезависимое хранилище (не обязательно диск - момент, к которому я вернусь). Стоит отметить, что многие диски лгут о том, когда данные были переданы на диск ( http://brad.livejournal.com/2116715.html ). Хотя кажется разумным предположить, что отключение кеша на диске может сделать диски более честными, все еще нет гарантии, что это так.

Из-за типично больших буферов в BBWC барьер может потребовать значительно больше данных для фиксации на диск, что приводит к задержкам при записи: общий совет - отключать барьеры при использовании энергонезависимого кэша обратной записи (и отключать кеширование диска). Однако это может подорвать целостность операции записи - просто потому, что в энергонезависимой памяти хранится больше данных, это не означает, что она будет более согласованной. Действительно, возможно, без разграничения между логическими транзакциями, кажется, меньше возможностей для обеспечения согласованности, чем в противном случае.

Если бы BBWC должен был признать барьеры в тот момент, когда данные попадают в его энергонезависимое хранилище (а не записываться на диск), то он, по-видимому, удовлетворял бы требованию целостности данных без снижения производительности - подразумевая, что барьеры все еще должны быть включены. Однако, поскольку эти устройства обычно демонстрируют поведение, совместимое с сбросом данных на физическое устройство (значительно медленнее с барьерами) и широко распространенными рекомендациями по отключению барьеров, они не могут вести себя таким образом. ПОЧЕМУ БЫ НЕТ?

Если ввод-вывод в ОС моделируется как последовательность потоков, то есть некоторая возможность минимизировать эффект блокировки барьера записи, когда кэширование записи управляется ОС - поскольку на этом уровне только логическая транзакция (один поток) ) нужно быть преданным. С другой стороны, BBWC, не зная, какие биты данных составляют транзакцию, должен будет зафиксировать весь кэш на диске. Чтобы ядро ​​/ файловые системы действительно реализовали это на практике, потребовалось бы гораздо больше усилий, чем я готов инвестировать в данный момент.

Комбинация дисков, сообщающих выдумкам о том, что было совершено, и внезапная потеря питания, несомненно, приводит к повреждению - и с файловой системой с журналированием или структурированным журналом, которая не выполняет полный fsck после сбоя, маловероятно, что повреждение будет обнаружено, не говоря уже о том, что сделана попытка его починить.

Что касается режимов сбоев, то, по моему опыту, наиболее внезапные перебои в подаче электроэнергии происходят из-за потери сетевого питания (легко устраняется с помощью ИБП и управляемого отключения). Люди, вытаскивающие неправильный кабель из стойки, подразумевают плохую гигиену центра обработки данных (маркировка и прокладка кабеля). Существуют некоторые типы внезапных потерь мощности, которые не предотвращаются ИБП - сбой в блоке питания или VRM BBWC с барьерами обеспечит целостность данных в случае сбоя, однако, насколько распространены такие события? Очень редко судя по отсутствию ответов здесь.

Безусловно, перемещение отказоустойчивости выше в стеке значительно дороже BBWC, однако реализация сервера в виде кластера имеет много других преимуществ для производительности и доступности.

Альтернативный способ смягчить влияние внезапной потери питания - внедрить SAN - AoE делает это практическим предложением (я не вижу смысла в iSCSI), но опять-таки это более высокая стоимость.


3
В течение многих лет файловые серверы NetApp имели кеширование записи NVRAM, и у меня было немало таких, которые теряют энергию и не портят свои файловые системы. Трудно доказать, что что-то спасло кого-то, потому что, так как кто-то был спасен, катастрофа не произошла; какие доказательства вы бы искали?
MadHatter поддерживает Монику

Возможно, вам следует также подумать о режимах отказа кэша записи с резервным питанием от батареи, а также кэша записи без батареи.
Стефан Ласевский,

1
Не опрос - я потратил много времени на изучение этого - и могу найти много информации о том, что должен делать BBWC - но очень мало информации о том, какие преимущества были реализованы на практике. Обратите внимание, что единственный ответ, который я получил ниже, где кто-то говорит, что BBWC сохранил свои данные, это когда не было никакого управляемого отключения в случае сбоя питания. Пока что ничто не опровергло мое подозрение, что: хотя BBWC может сохранять ваши данные в некоторых обстоятельствах, этих обстоятельств можно избежать другими способами.
Symcbean

1
Нет, это доказательство того, что отсутствие BBWC может потерять ваши данные . Доказательство этого - и я подозреваю, что у большинства системных администраторов дальнего следования в этой системе есть истории, в которых энергозависимые данные были потеряны при отключении электроэнергии; Я, безусловно, сделаю - не докажу, что наличие BBWC может спасти ваши данные , о чем просил ФП.
MadHatter поддерживает Монику

1
Некоторый дальнейший анализ и моделирование показывают, что BBWC + отсутствие барьеров может привести к необнаруженному повреждению с любым планировщиком ввода-вывода, кроме NOOP (я могу ошибаться по этому поводу, но очень старался найти доказательства, чтобы предложить иное). См. Также symcbean.blogspot.co.uk/2014/03/…
symcbean

Ответы:


34

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


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


5
Очень информативно, хорошая работа по сохранению этих результатов в течение сколь угодно длительного времени.
deed02392

Интересный! Интересно, планирует ли HP включить в контроллеры Smart Arrays тот же кэш без батареи, который они поместили в P2000
Габриэль Талавера,

4
@GabrielTalavera Да, HP использует флэш-накопители (конденсаторы) с 2010 года или около того. Нет больше батарей.
Ewwhite

То же самое здесь, используя Adaptec;) Больше никаких забот и регулярных замен.
TomTom

Спасибо ewwhite - именно то, что я ищу. Один вопрос: что случилось с питанием ИБП? Ваш ИБП не отключает систему при низком уровне?
Symcbean

10

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

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

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


Спасибо TomTom. Таким образом, он позволяет вам переносить данные к следующему барьеру, а не к предыдущему (если вы не используете журналирование или запись структурированных файловых систем). Это один из ключевых моментов, которые я пытаюсь здесь оценить. Казалось бы, это немного лучше удерживает роль файлового сервера, но не помогает с целостностью файловой системы или БД OLTP.
Symcbean

На самом деле это так - OLTP структурирован так, чтобы корректно обрабатывать сбои питания сервера до тех пор, пока записи в журнал записываются в точности;) И поскольку скорость ввода-вывода в журнал ограничена, «поддельные записи» (сообщаемые контроллером рейда) дают скорость - но с риском потери данных, если у вас нет энергонезависимого кэша.
TomTom

Я отмечаю, что RedHat считает, что вы должны отключить барьеры с BBWC - в то время как это улучшит производительность, оно не обеспечивает защиту в случае внезапного отключения, такого как потеря питания - ужасно! access.redhat.com/site/documentation/en-US/…
symcbean

@symcbean У вас не должно быть внезапной потери энергии в вашей среде. Это одна из самых простых ситуаций, которую можно предотвратить. Почему ваш сервер работает как дерьмо 100% времени для относительно редкого случая?
Ewwhite

1
На самом деле, единственная причина, по которой существует BBWC, заключается в смягчении проблемы внезапной потери питания. Следовательно, нет никаких препятствий.
TomTom

4

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

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

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

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


Спасибо JD: хотя не совсем то, о чем я спрашивал, я вижу, что это имеет большое отношение к предположениям, которые люди делают в отношении BBWC. Это находит отклик во многих дискуссиях об аппаратном и программном RAID, и я думаю, что для потомков следует отметить, что программный RAID не исключает использование контроллера кэширования (энергозависимого или иного).
Symcbean

Рейдовые карты IME, Dell и HP будут жаловаться (при условии, что у вас есть надлежащая система мониторинга) на неисправные батареи в BBWC.
mfinni

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

4

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

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


3

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

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


«Я знаком с тем, для чего предназначен BBWC (кэш записи с батарейным питанием)»
symcbean

2
Вы также сказали: «Мне любопытно понять, действительно ли это дает какую-то реальную пользу на практике». Я дал вам (и будущим читателям) конкретный. Из твоего вопроса было совсем не ясно, что ты знал об этой выгоде. И мой ответ не неправильный.
mfinni

Так чем же отличия, сделанные вами, от изменчивого кэша записи?
Symcbean

Очевидно, это была особенность, о которой вы знали. Но опять же, вы не дали понять это. @mfinni просто помогает.
deed02392

Некоторые системы не позволяют вам включить энергозависимый кэш записи, так что это так. Но нет, если вам нет дела до данных и вы можете использовать энергозависимый кэш записи, тогда сделайте это.
mfinni
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.