Гео-репликация glusterfs - сервер с двумя интерфейсами - объявлен частный IP
Я пытался настроить гео-репликацию с серверами glusterfs. Все работало, как и ожидалось, в моей тестовой среде, в моей промежуточной среде, но затем я попробовал производство и застрял.
Скажи у меня есть
gluster fs server находится на публичном ip 1.1.1.1
gluster fs slave общедоступен 2.2.2.2, но этот IP-адрес находится на интерфейсе eth1 eth0 на подчиненном сервере gluster fs - 192.168.0.1.
Поэтому, когда я запускаю команду на 1.1.1.1 (брандмауэр и ssh-ключи установлены правильно)
gluster volume geo-replication vol0 2.2.2.2::vol0 create push-pem
Я получаю ошибку.
Невозможно получить сведения о томе ведомого тома. Пожалуйста, проверьте подчиненный кластер и ведомый объем. команда гео-репликации не выполнена
Ошибка не так важна в этом случае, проблема в подчиненном IP-адресе
2015-03-16T11:41:08.101229+00:00 xxx kernel: TCP LOGDROP: IN= OUT=eth0 SRC=1.1.1.1 DST=192.168.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24243 DF PROTO=TCP SPT=1015 DPT=24007 WINDOW=14600 RES=0x00 SYN URGP=0
Как вы можете видеть в журнале удаления брандмауэра выше, порт 24007 ведомого демона gluster объявляется на частном IP-адресе интерфейса eth0 на подчиненном сервере и должен быть IP-адресом частного IP-адреса eth1. Таким образом, мастер не может подключиться и будет время ожидания
Есть ли способ заставить сервер Gluster рекламировать интерфейс eth1 или привязывать только к нему?
Я использую cfengine и ansible для продвижения конфигурации, поэтому привязка к интерфейсу может быть лучшим решением, чем IP, но любое решение подойдет.
Заранее спасибо.
2 ответа
Я столкнулся с этой проблемой, но в другом контексте. Я пытался выполнить гео-репликацию двух узлов, которые находились за NAT (экземпляры AWS в разных регионах).
Когда мастер подключается к ведомому через общедоступный IP-адрес для проверки совместимости / размера тома и других подробностей, он получает имя хоста подчиненного устройства, которое обычно разрешает что-то, что имеет значение только в этом удаленном регионе.
Затем он использует это имя хоста для обратного вызова подчиненного устройства при последующей настройке сеанса, который завершается неудачей, поскольку это имя хоста разрешается в частный IP-адрес в другом регионе.
Мой обходной путь для этой проблемы заключался в том, чтобы использовать имена хостов при создании томов, проверке одноранговых узлов и установлении гео-репликации, а затем добавить имя хоста /etc/hosts, отображающее имя хоста, которое обычно преобразуется в его частный IP в свой публичный IP, а не в частный IP.
Это приводит вас к тому, что вы начинаете сеанс, но мне не повезло, что он действительно синхронизировался, так как он где-то использует неправильный IP еще где-то.
Редактировать:
Мне действительно удалось запустить его, добавив хаки /etc/hosts с обеих сторон.
GlusterFS не имеет представления о сетевом уровне. Проверьте свои маршруты. Если следующий узел для вашего ведомого гео-репликации находится на eth1, то Gluster откроет порт на этом интерфейсе для подчиненного IP-адреса.
Также убедитесь, что ваш брандмауэр настроен на пересылку трафика гео-репликации на этот порт.