☰

Балансировка нагрузки кластера Ejabberd с помощью AWS ALB

tag-icon • tag-icon ejabberd
Балансировка нагрузки кластера Ejabberd с помощью AWS ALB

Подводя итог моим требованиям, можно сказать следующее.

Настройте кластер Ejabberd под балансировщиком нагрузки приложений AWS, затем зарегистрируйте 10 тыс. пользователей с помощью запроса API Ejabberd. После создания учетных записей пользователей войдите в систему с этими пользователями, создайте комнаты и выполните тест чата с несколькими комнатами с несколькими учетными записями пользователей.

Подводя итог существующей настройке кластера Ejabberd.

Я настроил кластер Ejabberd с двумя узлами в экземпляре AWS. Затем я создал балансировщик нагрузки приложений AWS с двумя целевыми группами: одна целевая группа с номером порта 5280 (URL-адрес администратора) и другая целевая группа 5222 (аутентификация клиента XMPP). Затем я регистрирую пользователя ejabberd с помощью API-запроса ниже (я могу создать 10 тыс. учетных записей с помощью скрипта).

http://<AWS Load balancer domain name>:5280/api/register
{
      "user": "test_user1",
      "host": "<AWS Load balancer domain name>",
      "password": "********"
}

До сих пор настройка Ejabberd работала нормально (я создал виртуальный хост с доменным именем балансировщика нагрузки AWS в файле конфигурации Ejabberd: «/opt/ejabberd/conf/ejabberd.yml»).

Когда я пытаюсь аутентифицировать зарегистрированного пользователя с помощью клиента Pidgin XMPP, мне не удается аутентифицировать зарегистрированного пользователя с помощью доменного имени балансировщика нагрузки.

Я заметил, что серверы Ejabberd получают запрос с внутреннего частного IP-адреса балансировщика нагрузки AWS (а не с фактического доменного имени балансировщика нагрузки), поэтому аутентификация ejabberd не работает с балансировщиком нагрузки приложений AWS.

Пожалуйста, помогите мне выполнить это требование.

решение1

Когда я пытаюсь аутентифицировать зарегистрированного пользователя с помощью клиента Pidgin XMPP, мне не удается аутентифицировать зарегистрированного пользователя с помощью доменного имени балансировщика нагрузки.

Почему бы и нет? Вам следует отредактировать свой пост и показать сообщения, зарегистрированные относительно этой попытки аутентификации.

Я не знаю, как обстоят дела с балансировкой нагрузки AWS, но я просто упомяну одну странную причину:

Я заметил, что серверы Ejabberd получают запрос с внутреннего частного IP-адреса балансировщика нагрузки AWS (а не с фактического доменного имени балансировщика нагрузки), поэтому аутентификация ejabberd не работает с балансировщиком нагрузки приложений AWS.

Эм... Пока ejabberd получает строфы XMPP, пытающиеся выполнить аутентификацию, и они предоставляют правильные учетные данные, не имеет значения, откуда пришло это соединение и к какому конкретному интерфейсу оно подключается (прослушиватель 5222, 5280, 127.0.0.1 или любой другой адрес, который прослушивает ejabberd).

Например, вот сообщения, которые регистрируются при регистрации учетной записи и корректном входе в систему:

2020-12-04 12:16:08.006547+01:00 [info] The account user2@localhost
 was registered from IP address 127.0.0.1

2020-12-04 12:16:13.502761+01:00 [info] (<0.675.0>)
 Accepted connection 127.0.0.1:46309 -> 127.0.0.1:5222
2020-12-04 12:16:13.607712+01:00 [info] (tls|<0.675.0>)
 Accepted c2s DIGEST-MD5 authentication for user2@localhost by mnesia backend from 127.0.0.1
2020-12-04 12:16:13.650407+01:00 [info] (tls|<0.675.0>)
 Opened c2s session for user2@localhost/tka1

Ваши аккаунты действительно зарегистрированы? Как вы в этом уверены? Они зарегистрированы на правильном хосте?

Проверить учетные записи можно в ejabberd WebAdmin, или выгрузив базу данных в текстовый файл и посмотрев таблицу паролей, или используя ejabberdctl debug или live и команду:

(ejabberd@localhost)3> mnesia:dirty_read(passwd,mnesia:dirty_first(passwd)).
[{passwd,{<<"user2">>,<<"localhost">>},
         <<"mypass11'a},ca">>}]

Связанный контент