Диски SATA, которые правильно обрабатывают кеширование записи?


15

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

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

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


linux позволяет отключить кэш записи на диске по отдельности через hdparam. Для дисков SATA, я считаю, что это должно быть написано в сценарии для повторного применения при каждом перезапуске. Я могу пойти по этому пути, если смогу по-прежнему соответствовать нашим требованиям к производительности без использования рейдового контроллера с батарейным питанием. Я предпочитаю использовать программный RAID, когда это возможно, так как он проще и дешевле. В любом случае, у меня определенно будет ИБП.
EAS

Ответы:


15

Вообще говоря, в прямом ответе на ваш вопрос я не знаю ни о каких основных марках дисков SATA, в которых сам диск имел ошибки относительно правильной работы с включенным кэшированием записи. То есть, только с точки зрения накопителя, накопитель делает то, что должен делать с точки зрения кэширования. Я хотел бы также отметить , что даже если кэширование записи будет включена, что задержка с диска записи на кабель SATA к вращающимся СМИ физически обновляемых до сих пор очень мало (~ 50 до 100 мс типично). Не похоже, что грязные данные кеша будут просто сидеть несколько секунд за раз ..... накопитель постоянно пытается извлечь грязные данные из кешана физический носитель, как только это возможно. Это не просто вопрос безопасности данных, это вопрос готовности принять будущие записи без каких-либо задержек (то есть: запись записи).

Проблема, которая возникает, когда включено кэширование, заключается в том, что порядок записи на диск по кабелю SATA и порядок записи на вращающийся носитель не совпадают. Это никогда не может вызвать проблемы, если только у вас нет потери питания или сбоя системы до того, как все содержимое кэша попадет на диск. Почему? ->

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

Теперь, конечно, разработчики файловой системы, баз данных, контроллеров RAID и т. Д. Знают (или наверняка должны знать) об этом явлении относительно кэширования записи. Кэширование записи крайне желательно с точки зрения производительности в большинстве сценариев ввода-вывода с произвольным доступом. Фактически, наличие доступного кэширования записи является ключевым элементом возможности получить реальную выгоду от более продвинутой Native Command Queuing ( NCQ).), который поддерживается в более новых SATA и последних нескольких реализациях PATA. Таким образом, чтобы гарантировать порядок на физическом носителе в такие критические моменты времени, файловая система и / или приложение и т. Д. Могут, в частности, запрашивать сброс кэшей записи на носитель. По завершении этого запроса на синхронизацию - все ожидающие от (потенциально) файловых буферов, кэширования диска ОС, кэширования физического диска и т. Д. Фактически отсутствуют на носителе в соответствии с проектом системы транзакций при правильных критических операциях. То есть это происходит правильно, если программисты делают правильный вызов (ы) вверху И каждый элемент этой цепочки программных и аппаратных уровней выполнил свою работу правильно. то есть: в этом отношении нет ошибок в приводе, контроллерах RAID, драйверах дисков, кэшах ОС, файловой системе, ядре базы данных и т. д. Это много программного обеспечения, которое должно работать правильно. Кроме того, проверка правильности в этом отношении очень трудна, потому что почти в любой ситуации обычно порядок записи вообще не имеет значения ... а сценарии сбоя питания и сбоя представляют собой сложные тесты для построения. Итак, в конце концов «отключение кэширования записи» на одном или нескольких различных уровнях и / или значениях этого термина… имеет репутацию «исправления» определенных видов проблем. По сути, отключение режима кэширования записи контроллера RAID, дисковых кешей ОС, диска и т. Д. Позволяет избежать одной или нескольких ошибок в системе ... и источника таких знаний. и сценарии сбоя питания и сбоя представляют собой сложные тесты для построения. Итак, в конце концов «отключение кэширования записи» на одном или нескольких различных уровнях и / или значениях этого термина… имеет репутацию «исправления» определенных видов проблем. По сути, отключение режима кэширования записи контроллера RAID, дисковых кешей ОС, диска и т. Д. Позволяет избежать одной или нескольких ошибок в системе ... и источника таких знаний. и сценарии сбоя питания и сбоя представляют собой сложные тесты для построения. Итак, в конце концов «отключение кэширования записи» на одном или нескольких различных уровнях и / или значениях этого термина… имеет репутацию «исправления» определенных видов проблем. По сути, отключение режима кэширования записи контроллера RAID, дисковых кешей ОС, диска и т. Д. Позволяет избежать одной или нескольких ошибок в системе ... и источника таких знаний.

В любом случае, возвращаясь к сути вопроса: в SATA специфическая обработка всех команд чтения / записи на диск и команд очистки кеша хорошо определяется спецификациями SATA . Кроме того, производители накопителей должны иметь подробную документацию для каждой модели накопителя или семейства накопителей, описывающую их реализацию и соответствие этим правилам, как в этом примере для накопителей Seagate Barracuda . В частности, смотрите подробности ОСОБЕННОСТИ SATA SETКоманда, управляющая режимом работы накопителя, и, в частности, опция 82h, может быть использована для отключения кэширования диска на уровне накопителя, поскольку по умолчанию определенно включено кэширование записи на всех накопителях, о которых я знаю. Если вы действительно хотели отключить кэш, эта команда должна выполняться при запуске каждого сброса диска или при включении питания и обычно находится под контролем драйверов дисков для вашей операционной системы. Возможно, вам удастся побудить драйвер ОС установить этот режим с помощью параметра типа IOCTL и / или параметра реестра, но это сильно варьируется.


5
Одна редакционная заметка к моему ответу: Аппаратные RAID-контроллеры работают с ошибками по многим причинам, включая проблемы, связанные с их внутренней реализацией кэширования записи. Я понятия не имею, почему, но, по неподтвержденным данным, RAID-контроллеры, похоже, являются одними из самых ошибочных программ, когда-либо написанных с точки зрения того, что имеет такое широкое применение. Конечно, стоит использовать очень распространенное, хорошо зарекомендовавшее себя и широко развернутое оборудование RAID от очень уважаемых поставщиков ..... и даже тогда исправления нетривиальных проблем кажутся слишком частыми!
Высокий Джефф

Спасибо, Джефф. Я много читал об этом, и я так же растерян, как и раньше. Я думаю, что проблема, с которой я сейчас борюсь, связана с «барьерами записи», которые позволяют приложениям и файловым системам инструктировать блочный уровень, чтобы гарантировать правильный порядок записи с использованием различных доступных механизмов. К сожалению, есть все виды проблем с внедрением барьеров. LVM, с одной стороны, очевидно, не поддерживает их, даже если базовые устройства поддерживают. Кроме того, мне кажется, что у системных администраторов должна быть опция fsync принудительно очищать кэш диска
eas

@eas - термин «барьеры записи», на который вы ссылаетесь, я предполагаю, является тем же базовым механизмом, который я назвал «синхронизацией» или «очисткой» кэшей в моем ответе выше. На ваш взгляд, это может инициироваться на разных уровнях доступа к файлу в «стеке». Чтобы создать настоящий барьер записи, он должен воздействовать на все уровни, на которых ожидающие данные записи (то есть: грязные кэши или буферы обратной записи), вплоть до физического носителя, чтобы фактически работать как задумано. Любое отключенное соединение в этой цепочке создает потенциальные проблемы при переупорядочении записей.
Высокий Джефф

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

3

По моему опыту, контроллер кеширующего диска с батарейным питанием отключит кеш на диске. Я не знаю, как иначе отключить кэш на диске. Даже если бы вы могли отключить кэш на диске, производительность значительно снизилась бы.

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


Мой комментарий выше должен был быть добавлен здесь. Я все еще изучаю этот сайт.
EAS

Некоторые контроллеры RAID отключают кэш на диске все время, некоторые нет, а некоторые имеют настройку. Это поведение в основном зависит от реализации стратегии кэширования RAID-контроллера. В некоторых реализациях они действительно хотят контролировать порядок записи на диск .... а в других это не имеет значения. Я ссылаюсь на некоторые вопросы здесь, в моем ответе.
Высокий Джефф

В моем, по общему признанию, небольшом наборе тестов (RAID-контроллеры LSI 9261, диски SATA, NL SAS и SAS) я обнаружил, что включение кэша записи диска, когда диск был подключен к RAID-контроллеру с кэш-памятью с резервным копированием / емкостью, не имеет значения производительность сверх того, что кэш контроллера RAID. Я бы еще не сказал, что это жесткое и быстрое правило, но для меня определенно ясно, что RAID-контроллер, отключающий кеш диска, не обязательно является проблемой.
Дэниел Лоусон

2

Я использую систему RAID с суперконденсатором, а не батарею для поддержания кеша. Аккумуляторы изнашиваются, должны контролироваться, должны заменяться и представлять потенциальную точку отказа в этом отношении. Конденсатор заряжается при запуске, очищает кэш при сбое питания от ИБП, длится практически вечно, не требует мониторинга и т. Д. Однако, если вы не ведете бизнес за чертой бедности (не редкость в наши дни), у вас должен быть ИБП и программное обеспечение, которое корректно отключает систему при сбое - обычно я даю ему 5–15 минут (в зависимости от нагрузки ИБП и, следовательно, наличия батареи) перед выключением, если снова включается питание.

Во время грозы вы можете (или можете иметь - энергосистемы становятся лучше), чтобы увидеть мерцание огней, иногда непосредственно перед тем, как они погаснут. Это устройство называется реклоузером. Это автоматический выключатель, который при срабатывании пытается замкнуть разомкнутый выключатель на случай, если перегрузка была кратковременной, а это большинство Если после трех попыток он не остается закрытым, он остается открытым. Какой-то бедняга должен выйти под дождь и разобраться с этим. Не жалейте его, делая только вдвое больше, чем вы и я, и вдвое больше, если это сверхурочно, это опасная работа.


2

Одно из заблуждений при кэшировании записи на диск заключается в том, что они теряют данные только при потере питания. Это не всегда так, особенно на устройствах sATA. Если на устройстве sATA имеется ошибка (например, ошибка FW в угловом случае или ошибка контроллера), и оно сбрасывается или сбрасывается извне, нет никакой гарантии, что данные в кэше обратной записи все еще доступны после зависания.

Это может привести к сценариям, когда устройство имеет временную ошибку, получает сброс, потеря данных происходит при потере любого грязного кеша, и это молчит над уровнем блоков драйверов.

Хуже того, отключение кэша диска с помощью инструментов ОС также будет потеряно при перезагрузке устройства, поэтому даже если устройство отключило кэш в начале дня, если устройство будет перезагружено, оно снова включит кэширование с обратной записью. При следующем сбросе устройство потеряет данные.

Диски SCSI / SAS и некоторые диски SATA имеют возможность сохранять состояние профиля обратной записи, чтобы гарантировать, что при перезагрузке свойство не будет потеряно - но на практике это редко используется.

RAID-контроллеры, которые интегрируют блочный уровень в верхние уровни, могут заметить перезагрузку диска и снова отключить кэш обратной записи - но стандартные контроллеры sATA и SAS не будут этого делать.

Это ограничение также распространяется на другие SET FEATURE и аналогичные параметры, которые настроены для производительности и надежности.


1

Как вы говорите, правильный RAID-контроллер с батарейным питанием будет дорогим, но вы можете найти контроллеры Dell Perc5 / i на eBay за 100 фунтов стерлингов ($ 150), и особенно с RAID5 скорость контроллера, подобного Perc5 / i, поразит вас. У меня есть несколько серверов с Perc5 / is и шесть дисковых массивов RAID5, и они являются одними из самых быстрых дисков, которые я когда-либо видел. Специально для приложений баз данных быстрые диски действительно улучшат производительность.

Я бы укусил пулю и купил бы контроллер RAID.

JR


1

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

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

Сколько IOPS требуется вашему приложению? Вы уверены, что ограничены кешем записи дисков или что небольшая (по сравнению с памятью вашего сервера) память будет полезна?


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