Что именно делает Gluster?

Я играл с Gluster в течение последних 2 дней и задавал вопросы здесь и в их системе вопросов. Я действительно не понимаю некоторые вещи. Я вижу людей, говорящих такие вещи, как

Установите реплицированные блоки между серверами (так как вы используете только 3, реплицированный будет безопаснее), и каждый сервер будет видеть файлы всех других серверов как локальные - даже если один сервер отказывает, файлы были реплицированы на другие серверы.

или

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 мог убедиться в его репликации:

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

Мне не удалось найти хорошую страницу, описывающую механизмы сценариев сбоя внутри, например, как клиент обнаруживает, что что-то сломано. Однако при загрузке исходного кода и просмотре клиента выясняется, что существуют различные тайм-ауты, которые он использует для команд, и тест, который он часто делает для других систем в кластере. Похоже, что большинство из них имеют метки TODO и в настоящее время не конфигурируются, за исключением изменения исходного кода, что может быть проблемой для вас, если время конвергенции имеет решающее значение.

При репликации всего 2 узлов gluster мало чем отличается от автоматического сценария rsync. Все становится действительно интересным, когда у вас есть 4 или более узлов хранения - ваши клиентские машины видят пул пространства, но составляющие файлы распределены по всем узлам хранения (кирпичи). Это означает, что если ваши 4 сервера имеют 10 ТБ локального пространства, ваши клиентские машины могут видеть одно пространство имен размером 20 ТБ (реплицированное или 40 ТБ незащищенного хранилища).

Я видел краткий сбой - возможно, 30 секунд или около того - на клиентском компьютере, когда он пытается IO после того, как кирпич хранилища становится недоступным. Однако после сбоя ввод-вывод будет продолжаться в обычном режиме, пока в сети есть серверы, на которых все еще хранится полный набор данных тома.

Вы описываете непредвиденное поведение - я бы посоветовался с #gluster на irc.freenode.net или gluster-users@gluster.org или http://community.gluster.org/

-Джон Марк Глостер Сообщество Гай

Когда происходит сбой клиентского сервера (т. Е. Сервера, чей IP / DNS был использован клиентом для монтирования файловой системы), тогда весь том становится автономным для этого клиента, т.е. он не может читать / писать на томе.

Однако, если клиент смонтировал его, используя IP / DNS другого сервера, том все еще будет подключен к этому клиенту. Однако чтение / запись не пойдет в сбойный / сбойный экземпляр.