Как кластерные файловые системы избегают множества возможных состояний гонки?
Я пытаюсь разобраться в использовании кластерной файловой системы в архитектуре Мастер-Мастер. Я думаю конкретно о GlusterFS, поэтому детали реализации приветствуются, но я надеюсь на общий ответ.
Процесс GlusterFS состоит из модульных функциональных модулей, называемых «трансляторами». Блокирующий транслятор загружается как часть серверного стека, и операции, которые могут конкурировать, синхронизируются этим транслятором.
По умолчанию интерфейс командной строки gluster создает конфигурацию, которая включает в себя транслятор «функций / блокировок» как часть стека сервера GlusterFS.
Различные файловые системы кластера справляются с этим по-разному. По сути, проблема аналогична обработке любой другой совместно используемой структуры данных в сценарии параллельного доступа (например, поточно-ориентированные структуры). Доступ к данным на диске на несколько порядков более скрыт и медленнее (с меньшей пропускной способностью), чем данные, хранящиеся в ОЗУ. Таким образом, алгоритмы, используемые для обработки параллелизма в файловой системе кластера, будут соответствующим образом настроены.
«Традиционная» кластерная файловая система, например, VERTIAS Cluster Filesystem, использует диспетчер блокировок и процесс «ведущий / ведомый» (с механизмом ограждения) для обеспечения согласованности метаданных на диске.
Лично я не использовал GlusterFS и не могу сказать, что достаточно знаком с архитектурой, чтобы делать разумные комментарии. Из того, что я почерпнул из прочтения об этом, GlusterFS кажется скорее причудливым механизмом для «склеивания» базовых некластеризованных файловых систем на отдельных узлах хранения, а не «традиционной» кластерной файловой системой (где несколько клиентов напрямую обращаются к одному и тому же блочные устройства). Здесь вы можете получить некоторые полезные сведения (хотя я не знаю, насколько актуальны эти сведения в самых последних версиях): http://www.raidinc.com/pdf/whitepapers/wp-gfs-architecture.pdf