Назад | Перейти на главную страницу

Как сохранить целостность файлового сервера, не отключаясь от chkdsk?

Мне просто интересно, как люди справляются с постоянной стабильностью файловой системы при использовании Windows Server в качестве файлового сервера, не переводя систему в автономный режим для выполнения chkdsk / f или chkdsk / r? Очевидно, что на самом деле не нужно, чтобы файловый сервер был недоступен ... а файловые серверы теперь имеют так много хранилища, что запуск chkdsk может занять несколько дней ... так как вы защищаете данные от повреждения?

Я поддерживал файловые серверы с примерно 7 ТБ общих пользовательских данных. Эти 7 ТБ были созданы в основном из файлов офисного типа, так что мы говорим о миллионах. У меня нет точного числа, потому что это занимает очень много времени, но где-то между 7-12 миллионами файлов в различных файловых системах в нашем отказоустойчивом кластере Server 2008.

Мы никогда не запускаем chkdsk, кроме как для устранения проблем, и никогда не дефрагментируем.

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

Фактически, недавно мы пережили катастрофический отказ ИБП. Вся комната одновременно рухнула. NTFS восстанавливается без пика и запуска chkdsk.

О дефрагментации ... в нашем дисковом массиве FC 48 дисков, и поскольку это HP EVA, полосы случайным образом распределяются по шпинделям. Это означает, что даже в значительной степени последовательные обращения к дискам на самом деле являются случайными, что также означает, что значительно последовательная файловая система работает минимально лучше, чем значительно фрагментированная. Таким образом, стандартная дефрагментация очень мало помогает уменьшить накладные расходы ввода-вывода.

Что касается профилактического обслуживания, NTFS теперь достаточно автоматизирована, чтобы делать почти все это самостоятельно. Время от времени я запускаю chkdsk в режиме только для чтения чтобы увидеть, стоит ли запускать его в полном режиме. Пока что в нашем кластере еще предстоит. Даже на нашем 2 ТБ, 4 миллиона файловых LUN он запускается менее чем за день.


Тем не менее, вы можете принять некоторые архитектурные решения, которые помогут снизить возможную потребность в автономном chkdsk и ускорить его работу, если вам когда-либо понадобится:

  • Установите политику кэширования на контроллерах RAID / SAN, чтобы не кэшировать записи. Однако именно поэтому существует кэш с резервным питанием от батареи, поэтому производительность снижается. это вызовет принимать не нужно. Но это главное, что нужно сделать, чтобы предотвратить отключение chkdsk.
  • Делайте ваши LUN меньше. Количество файлов имеет большее значение, чем размер. LUN объемом 6 ТБ, заполненный образами-призраками, будет проверять намного быстрее, чем LUN объемом 512 ГБ, заполненный файлами 6 КБ.
  • Обеспечьте достаточно свободного места. Хорошее эмпирическое правило, основанное на полностью субъективных критериях: не менее 15% бесплатного контента в любое время.
  • Если ваши данные позволяют, используйте размер блока больше, чем размер блока 4 КБ по умолчанию для NTFS. Проведя статистику по моим файлам, я обнаружил, что могу использовать блоки размером 16 КБ для большинства файловых систем. Более крупные блоки означают меньшее количество блоков для проверки, а также позволяют подсистеме хранения лучше использовать упреждающее чтение. Да, очень битовые файлы занимают больше места, но на наших томах они добавили всего около 4% к общему размеру.

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

Раньше, где я работал, мы использовали Tripwire. Для получения дополнительной информации вы можете посмотреть здесь:Менеджер целостности файлов Tripwire

Здесь вы также найдете обзор имеющихся на рынке решений для проверки целостности файлов:Проверка целостности файлов

Microsoft опубликовала инструкции по повышению производительности и минимизации времени простоя при запуске checkdisk:

Лучшие практики и производительность NTFS Chkdsk
https://www.microsoft.com/downloads/en/details.aspx?FamilyID=35a658cb-5dc7-4c46-b54c-8f3089ac097a

Особо следует отметить:

  • Размер тома не влияет на производительность.

  • Для томов с большим количеством файлов (сотни миллионов / миллиарды) увеличение производительности за счет использования большего объема памяти для chkdsk является значительным.

  • Windows 2008 R2 chkdsk в два-пять раз выше производительности Windows 2008. Windows 2003 была настолько плохой, что они, вероятно, были слишком смущены, чтобы публиковать статистику.

  • Перед запланированным перезапуском необходимо заранее проверить, не загрязнены ли том (-ы). Это может помочь смягчить эффект неожиданных многочасовых задержек при запуске.

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