Какой степени потери или повреждения данных я могу подвергнуться риску, если включу буфер записи на файловом сервере?
Я нашел много статей в Интернете, предупреждающих о риске потери или повреждения данных для дисков с включенным буфером записи в случае потери питания. Тем не менее, я не нашел ничего, что на самом деле относится к шкале риска.
Я собираюсь создать зеркальный файловый сервер в Storage Spaces на Windows Server 2016 для небольшого офиса по редактированию видео. Производительность очень важна (следовательно, учитывается буфер записи), и наш сервер будет обрабатывать в основном два типа важных записей: выгрузку отснятого материала и сохранение файла проекта или документа.
Это заставляет меня задуматься о том, какой будет наихудший сценарий в случае неожиданной потери питания.
Для загрузки отснятого материала можно ожидать, что любое прерывание на сервере вызовет видимый сбой в сети при любой передаче файла. Поэтому, если сбой питания не произошел через несколько секунд после завершения сетевой части передачи файла, они будут знать о необходимости перезапустить передачу файла после того, как сервер снова будет в сети. Так как я знал бы о сбое сервера, я мог бы посоветовать офису использовать программу синхронизации, чтобы предположительно перезаписать любые поврежденные файлы локальными мастер-копиями.
Что касается сохранения документов и файлов проекта, большинство из них должно быть настолько маленьким, чтобы иметь минимальный риск даже оказаться в буфере во время сбоя. И если бы это было не так, наличие автосохранения или открытой версии на компьютере пользователя дало бы им второй шанс. Единственный риск, который я действительно могу видеть, - это если сбой питания произошел в тот момент, когда они сохранили и закрыли файл, и эта программа не сохраняла автоматически сохраняющиеся данные.
Является ли моя оценка точной, или я что-то упустил? Может ли коррупция в этой ситуации повлиять на большее количество данных, чем то, что было записано?
Спасибо
Изменить: я должен подчеркнуть, что я не особо ищу выводы о том, что я должен делать в этом сценарии. Я просто хочу правильно понять возможности, чтобы я мог принять обоснованное решение о реальности этого риска.
Многие веб-страницы, которые я читал по этому вопросу, до сих пор были удручающе неоднозначными, особенно в отношении разграничения между "кэшированием записи" и "очисткой буфера записи-кэша".
2 ответа
Вы должны были различать включенный буфер записи и отключенные очистки буфера. Чтобы полностью понять разницу, давайте начнем с основного.
Жесткие диски и твердотельные накопители почти всегда имеют частный кэш DRAM, используемый для краткого хранения и объединения входящих записей, что значительно повышает производительность их записи. В качестве справки рассмотрим, что быстрый SATA SSD накачал>500 МБ / с последовательной записи с включенным буфером и только ~5 МБ / с с отключенным буфером. Жесткие диски показывают менее серьезное снижение производительности, но все же.
В то же время, если эти частные кэши DRAM не защищены от потери мощности, может произойти серьезное повреждение данных (вплоть до потери всей файловой системы). Чтобы предотвратить эту проблему без полного снижения производительности, существуют некоторые возможности:
- используйте диски с кэшем записи, защищенным от потери мощности (т. е. корпоративный SSD и некоторые более новые механические жесткие диски с поддержкой NV)
- использовать аппаратный RAID-контроллер с кэшем, защищенным от потери энергии, отключая кэш DRAM на частном диске
- используйте дешевое потребительское оборудование с включенным незащищенным кешем DRAM, но с периодическими сбросами, чтобы гарантировать согласованность файловой системы (но не данных, поскольку влияние на производительность будет очень большим).
При использовании подходов, подобных программному RAID (например, Linux MDRAID, ZFS, Storage Spaces, ecc), вы никогда не должны отключать дисковые кэши, если только вы не готовы платить очень высокую производительность. Лучше всего оставить включенный кэш записи и позволить вашей ОС / файловой системе свободно выдавать команды синхронизации / очистки DRAM в любое время. Таким образом вы получаете повышение производительности включенного кэша, не рискуя уничтожить всю вашу файловую систему. Обратите внимание, что данные приложения не защищены автоматически: любое приложение, которое хочет обеспечить долговечность данных, должно периодически выдавать сброс (базы данных являются хорошим примером).
С другой стороны, вы НИКОГДА не должны отключать очистку кеша DRAM, если только вы не уверены на 200%, что ваши диски /RAID-карты имеют защищенный кэш обратной записи. Однако в этом случае оставление включенных сбросов не принесет большого вреда, так как почти любой недавний диск / карта просто игнорирует сброс, когда его защищенный кэш-память DRAM находится в исправном состоянии.
Может ли коррупция в этой ситуации повлиять на большее количество данных, чем то, что было записано?
Да. Записи могут обновлять саму файловую систему. В худшем случае потеря данных происходит практически для любого файла. Предупреждение не является конкретным, потому что буквально все может быть потеряно, а воздействие варьируется в зависимости от приложения.
Разве часы восстановления после потери данных не влияют на производительность пользователей? Примите этот совет и не отключайте очистку буфера записи-кэша.
Лучшее решение: получить больше и быстрее твердотельного хранилища, пока вы не получите удовлетворительную производительность.
Изменить: чтобы было ясно, я имею в виду более агрессивную опцию "отключить очистку буфера записи-кэша". "Включить кэширование записи", включенное по умолчанию для многих типов внутренних дисков, обычно является приемлемым компромиссом, поскольку Windows пытается очистить буфер и усилить запись.