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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JR

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

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

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