Я играл с gluster последние 2 дня и задавал вопросы здесь и по их системе вопросов. Я действительно не понимаю некоторых вещей. Я вижу, как люди говорят такие вещи, как
Настройте реплицированные блоки между серверами (поскольку вы используете только 3, репликация будет безопаснее), и каждый сервер будет видеть файлы всех других серверов как `` локальные '' - даже если один сервер выйдет из строя, файлы были реплицированы на другие серверы.
или
Gluster будет поддерживать синхронизацию файлов между томами (блоками) и имеет возможности «самовосстановления», которые устранят любые несоответствия из-за того, что один сервер отключен.
Так как я монтировать удаленный том от сервера к клиенту (ам) как gluster обрабатывает сбой серверного узла, на котором тома смонтированы? Из того, что я пробовал, папка на клиенте, где был смонтирован том, становится недоступной, и мне приходится использовать umount, чтобы разблокировать ее. И после этого с сервера нет контента.
Это, в основном, то, что я не вижу в каких-либо объяснениях: что происходит, когда серверный узел выходит из строя, и возможно ли действительно реплицировать контент, как это делает unison или rsync?
Недавно мы начали исследовать GlusterFS для собственного использования, поэтому этот вопрос был мне интересен. Gluster использует так называемые «переводчики» в клиенте FUSE для обработки того, как вы храните данные. Здесь перечислены несколько типов переводчиков:
http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3
Тот, о котором вы конкретно спрашиваете, называется переводчиком автоматической репликации файлов или AFR, и подробно рассматривается здесь:
http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator
Глядя на исходный код, кажется, что данные фактически записываются на узлы одновременно, что намного лучше, чем rsync!
Что касается восстановления после сбоя, я обнаружил одно интересное замечание. Система Gluster отличается от Ceph тем, что она активно не осведомлена об изменениях состояния репликации и должна быть «запущена». Поэтому, если вы потеряете узел в своем кластере, вам придется искать каждый файл, чтобы Gluster мог убедиться, что он реплицирован:
Мне не удалось найти хорошую страницу, описывающую внутренние механизмы сценария сбоя, например, как клиент обнаруживает, что что-то сломано. Однако при загрузке исходного кода и просмотре клиента выясняется, что существуют различные тайм-ауты, которые он использует для команд и зондирования, которые он так часто делает для других систем в кластере. Похоже, что большинство из них имеют отметки TODO и в настоящее время не могут быть настроены, кроме как путем модификации исходного кода, что может быть проблемой для вас, если время сходимости критично.
При репликации всего двух узлов gluster мало чем отличается от автоматического сценария rsync. На самом деле все начинает быть интересным только тогда, когда у вас есть 4 или более узлов хранения - ваши клиентские машины видят пул пространства, но составляющие файлы распределены по всем узлам хранения (кирпичам). Это означает, что если у ваших 4 серверов 10 ТБ локального пространства, ваши клиентские машины могут видеть одно пространство имен размером 20 ТБ (реплицированное или 40 ТБ незащищенного хранилища).
Я видел кратковременный сбой - может быть, 30 секунд или около того - на клиентском компьютере, когда он пытается выполнить ввод-вывод после того, как блок хранилища становится недоступным. Однако после сбоя ввод-вывод будет продолжаться в обычном режиме до тех пор, пока в сети есть серверы, которые все еще хранят полный набор данных тома.
Вы описываете неожиданное поведение - я бы посоветовался с #gluster на irc.freenode.net, gluster-users@gluster.org или http://community.gluster.org/
-Джон Марк Гластер, общественный деятель
Когда клиентский сервер выходит из строя (то есть сервер, чей IP / DNS использовался клиентом для монтирования файловой системы), тогда весь том становится недоступным для этого клиента, то есть он не может читать / писать на том.
Однако, если клиент смонтировал его, используя IP / DNS другого сервера, том для этого клиента все равно будет в сети. Однако операции чтения / записи не будут передаваться в отказавший / аварийный экземпляр.