Я в настоящее время более внимательно рассмотрел в GlusterFS.
Для тестирования причин я настроил четыре виртуальных машины всего, каждый из них действуют как одноранговый узел Gluster.
Так как у меня есть доступ к двум DCS (которые расположены в различных местоположениях), я создал два из узлов Gluster в DC A, и другие два узла находятся в DC B.
Реплицированных том с количеством копии 4 использования все четыре узла Gluster, что означает, что у меня есть две копии каждого файла в каждом DC.
Оба DCS соединены друг с другом, что означает, что каждый сервер имеет способ получить доступ к другому серверу через внутренний IP-адрес.
Так как я также хочу получить доступ к файлам, я создал другой VM в DC, который сделал mount.glusterfs на реплицированных томе.
Теперь мой вопрос: GlusterFS "клиент" предпочитает локальные узлы Gluster (от того же DC) по большему количеству удаленных узлов Gluster (расположенный в другом DC)?
В противном случае существует ли способ влиять на поведение доступа к файлу "клиента Gluster"? Я попытался искать официальную документацию и погуглил больше 30 минут; однако, я не смог найти ответы на свои вопросы.
Причина, почему я задаю этот вопрос, состоит в том, потому что я хочу удостовериться, что мой "клиент" не получает доступ к узлам Gluster в другом DC для доступа к файлам. Я хочу держать трафик внутри текущего DC.
Вам нужен вариант чтения read-subvolume
. Без него при инициализации он получит самый быстрый ответ от сервера (который может быть DC-локальным, но это не всегда верно) и будет читать с него. Для записи клиент всегда будет писать на все узлы в наборе реплик.
Параметр read-subvolume описан здесь:
http://www.gluster.org/community/documentation/index.php/Translators / cluster