☰

Lastenausgleich des Ejabberd-Clusters mit AWS ALB

tag-icon • tag-icon ejabberd
Lastenausgleich des Ejabberd-Clusters mit AWS ALB

Ich fasse hier meine Anforderungen zusammen.

Konfigurieren Sie das Ejabberd-Cluster-Setup unter dem AWS-Anwendungslastenausgleich und registrieren Sie dann 10.000 Benutzer mit der Ejabberd-API-Anforderung. Sobald die Benutzerkonten erstellt sind, melden Sie sich mit diesen Benutzern an, erstellen Sie Räume und führen Sie den Chat-Test mit mehreren Räumen mit mehreren Benutzerkonten durch.

Zusammenfassung des vorhandenen Ejabberd-Cluster-Setups.

Ich habe das Ejabberd-Cluster-Setup mit zwei Knoten in der AWS-Instanz konfiguriert. Dann habe ich einen AWS Application Load Balancer mit zwei Zielgruppen erstellt, eine Zielgruppe mit Portnummer 5280 (Admin-URL) und die andere Zielgruppe 5222 (XMPP-Client-Authentifizierung). Dann registriere ich den Ejabberd-Benutzer mit der folgenden API-Anforderung (ich kann 10.000 Konten mit Skript erstellen).

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

Bis hierher funktioniert das Ejabberd-Setup einwandfrei (ich habe einen virtuellen Host mit dem AWS-Load-Balancer-Domänennamen in der Ejabberd-Konfigurationsdatei erstellt: „/opt/ejabberd/conf/ejabberd.yml“).

Wenn ich versuche, den registrierten Benutzer mit dem Pidgin XMPP-Client zu authentifizieren, kann ich den registrierten Benutzer nicht mit dem Domänennamen des Load Balancers authentifizieren.

Mir ist aufgefallen, dass die Ejabberd-Server die Anforderung von der internen privaten IP-Adresse des AWS-Load Balancers erhalten (nicht vom tatsächlichen Domänennamen des Load Balancers). Daher funktioniert die Ejabberd-Authentifizierung mit dem AWS-Anwendungs-Load Balancer nicht.

Bitte helfen Sie mir, diese Anforderung zu erfüllen.

Antwort1

Wenn ich versuche, den registrierten Benutzer mit dem Pidgin XMPP-Client zu authentifizieren, kann ich den registrierten Benutzer nicht mit dem Domänennamen des Load Balancers authentifizieren.

Warum nicht? Sie sollten Ihren Beitrag bearbeiten und die protokollierten Nachrichten zu diesem Authentifizierungsversuch anzeigen.

Ich kenne mich mit dem Lastenausgleich bei AWS nicht aus, möchte aber eine merkwürdige Begründung nennen:

Mir ist aufgefallen, dass die Ejabberd-Server die Anforderung von der internen privaten IP-Adresse des AWS-Load Balancers erhalten (nicht vom tatsächlichen Domänennamen des Load Balancers). Daher funktioniert die Ejabberd-Authentifizierung mit dem AWS-Anwendungs-Load Balancer nicht.

Ähm … Solange ejabberd die XMPP-Strophen zur Authentifizierung empfängt und die richtigen Kontoanmeldeinformationen bereitstellt, spielt es keine Rolle, woher die Verbindung kommt und mit welcher genauen Schnittstelle sie verbunden ist (5222-Listener, 5280, 127.0.0.1 oder eine andere Adresse, an der ejabberd lauscht).

Dies sind beispielsweise die Nachrichten, die protokolliert werden, wenn ein Konto registriert wird und die Anmeldung korrekt erfolgt:

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

Sind deine Accounts wirklich registriert? Wie kannst du dir sicher sein? Sind sie beim richtigen Host registriert?

Sie können die Konten im ejabberd WebAdmin überprüfen, die Datenbank in eine Textdatei schreiben und sich die Passwd-Tabelle ansehen oder ejabberdctl debug oder live und den folgenden Befehl verwenden:

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

verwandte Informationen