Я изучаю способы создания и запуска огромного сервера хранения (должен быть запущен Linux), где для всех массивов данных я могу выполнить проверку согласованности и исправить, в то время как обычные приложения, использующие массивы (чтение и запись), продолжают работать как обычно .
Предположим, у вас есть много ТБ данных в одной традиционной файловой системе Linux (EXT4, XFS), которая используется сотнями пользователей, и внезапно система сообщает о проблеме с ее согласованностью / повреждением, или вы знаете, что машина недавно вышла из строя в грязный путь и повреждение файловой системы очень вероятно.
Перевод файловой системы в автономный режим и запуск проверки файловой системы может легко занять много часов / дней простоя, поскольку ни EXT4, ни XFS не могут запускать проверку и восстановление при нормальной работе; файловую систему нужно сначала отключить.
Как избежать этой слабости EXT4 / XFS с Linux? Как я могу построить большой сервер хранения, не отключая его на несколько часов для обслуживания?
Я много читал о ZFS и ее надежности из-за использования проверок согласованности данных / метаданных. Можно ли запустить проверку целостности и исправить файловую систему ZFS, не отключая ее? Будет ли лучше какая-то другая новая файловая система или другая организация данных на диске?
Еще один вариант, о котором я думаю, - это разделить массив данных на смехотворно много (сотни) разделов, каждый из которых имеет свою собственную независимую файловую систему, и исправить приложения, которые должны знать, чтобы использовать все эти разделы. Затем, когда возникнет необходимость проверить один из них, нужно будет отключить только его. Не идеальное решение, но лучше, чем ничего.
Есть ли идеальное решение этой проблемы?
Это будет случай для XFS или ZFS. FSCK - это не концепция в мире ZFS.
Есть много навыков, чтобы построить что-то подобное надежным способом. Если есть бюджет на привлечение эксперта или Консультант ZFS, вашей организации следует подумать об этом.
Грубая реальность такова, что унаследованные файловые системы не очень хорошо подходят для томов с несколькими ТБ. Например, RedHat рекомендует Файловые системы EXT4 не более 50 ТБ; с fsck время является одним из ограничивающих факторов.
XFS в лучшей форме, как из-за гораздо более быстрой xfs_repair (по сравнению со старым xfs_check) и текущему проекту добавить он-лайн скраб.
EXT4, XFS и другие файловые системы (за исключением BTRFS) можно проверить онлайн, сделав снимок основного тома и запустив fsck против снимка, а не самой основной файловой системы. Это позволит отловить любую серьезную ошибку без простоя, но для этого явно нужен диспетчер томов (с возможностью создания моментальных снимков) в файловой системе. Кстати, это одна из основных причин, почему RedHat по умолчанию использует LVM.
Тем не менее, ZFS, безусловно, является самой известной и надежной файловой системой с онлайн-очисткой: она была разработана с самого начала для эффективной поддержки очень больших массивов, а ее онлайн-очистка чрезвычайно эффективна. Если есть, то у него обратная проблема: ему не хватает не в сети fsck, что было бы полезно исправить некоторые редкие классы ошибок.
Проведите анализ непрерывности бизнеса, спросив организацию, сколько времени простоя для этого хранилища приемлемо. Чтобы добиться большего, чем несколько запланированных отключений и несколько часов простоя в год, обычно требуется инвестировать в решение с несколькими узлами.
Защитите от максимально возможного количества рисков простоя. Например, пожар в центре обработки данных отключит работу на пару часов, независимо от технологии хранения. Если обслуживание необходимо продолжить, реплицируйте данные в другую систему в другом здании.
Что касается файловой системы, выберите то, что вы можете исправить и / или ваш поставщик может поддержать. EXT4 будет настоятельно рекомендовать вам проверять каждое такое количество маунтов. XFS fsck ничего не делает из-за журнала, но xfs_check отключен. ZFS не имеет fsck, но есть онлайн-скрабы.
В некоторой степени может иметь смысл разделение данных на несколько томов. Изолирует сбои, возможно, по организационному подразделению или приложению. Однако сотни небольших томов просто для быстрой работы fsck увеличивают объем работы. Одно из преимуществ централизованно управляемого хранилища должно было заключаться в меньшем объеме административной работы.
Для обеспечения доступности и производительности нескольких узлов рассмотрите возможность добавления на другом уровне масштабируемой распределенной файловой системы. Ceph, Lustre, Gluster, другие. Совсем не похож на один большой массив. Реализации различаются в зависимости от того, используют ли они нижележащую файловую систему и предоставляют ли они пользователям блочные или файловые протоколы.