CPU- und Speicherauslastungsdiskrepanzen für Ejabberd- und Riak-Cluster auf AWS

Question

Ich betreibe einen Ejabberd-Cluster mit zwei Knoten (hinter einem Elastic Load Balancer), der wiederum mit einem 3-Knoten-Riak-Cluster verbunden ist (wiederum über einen ELB) auf AWS. Wenn ich die Plattform über Tsung lade (0,5 Millionen Benutzeranmeldungen), stelle ich fest, dass die CPU-Auslastung für die ejabberd-Knoten untereinander um 10% differiert. Bei den Riak-Knoten unterscheidet sich die CPU- und Speicherauslastung unter den Knoten um etwa 5%.

Die Knoten sind identisch konfiguriert, also fragen Sie sich, was zu diesen nicht-trivialen Unterschieden in der Nutzung führen könnte. Kann jemand bitte hier etwas Licht werfen/erziehen?

Liegt es am Load Balancer? Oder ein Netzwerkeinfluss? Ich erwarte, dass, sobald ein Cluster gebildet ist (entweder von Ejabberd oder von Riak KV), die Knoten alle im Verhalten identisch sind, insbesondere für Ejabberd, wo die gesamte Datenbank über den Cluster repliziert wird.

Nicht, dass diese Unterschiede sind ein Problem, aber wäre gut, das Innenleben der Cluster hier zu verstehen ...

Vielen Dank.

Answer 1

Elastic Load Balancing Mechanismus

• DNS-Server verwendet DNS Round-Robin, die Load-Balancer-Knoten in einer bestimmten Availablity Zone zu bestimmen, wird die Anfrage
• Die ausgewählten Load Balancer überprüft "sticky session" erhalten cookie
• die ausgewählten Lastausgleicher senden die Anforderung an die am wenigsten belastete Instanz

und in mehreren Details:

Availability Zones (unwahrscheinlich Ihr Fall)

standardmäßig innerhalb derselben Availability Zone des Load Balancer Knoten Routen Verkehr Instanzen Back-End. Um sicherzustellen, dass Ihre Back-End-Instanzen die Anforderungen in jeder Availability Zone verarbeiten können, ist es wichtig, dass in jeder Zone ungefähr die gleiche Anzahl Instanzen vorhanden ist. Wenn Sie z. B. zehn Instanzen in der Verfügbarkeitszone "us-east-1a" und zwei Instanzen in "us-east-1b" haben, wird der Datenverkehr weiterhin gleichmäßig auf die beiden Availability Zones verteilt. Folglich müssen die zwei Instanzen in us-east-1b dieselbe Menge an Verkehr bedienen wie die zehn Instanzen in us-east-1a. ein Lastenausgleich jede Anforderung unabhängig an die Server-Instanz mit der kleinsten Last

Sessions (höchstwahrscheinlich Ihren Fall)

standardmäßig. Im Vergleich bindet eine sticky-Sitzung die Sitzung eines Benutzers an eine bestimmte Serverinstanz, sodass alle Anforderungen, die während der Sitzung vom Benutzer kommen, an dieselbe Serverinstanz gesendet werden.

AWS Elastic Beanstalk verwendet vom Load Balancer generierte HTTP-Cookies, wenn für eine Anwendung "sticky sessions" aktiviert sind. Der Load Balancer verwendet einen speziellen von Load Balancer generierten Cookie, um die Anwendungsinstanz für jede Anforderung zu verfolgen. Wenn der Load Balancer eine Anforderung empfängt, überprüft er zuerst, ob dieser Cookie in der Anforderung vorhanden ist. Ist dies der Fall, wird die Anfrage an die im Cookie angegebene Anwendungsinstanz gesendet.Wenn kein Cookie vorhanden ist, wählt der Load Balancer eine Anwendungsinstanz basierend auf dem vorhandenen Lastenausgleichsalgorithmus aus. Ein Cookie wird in die Antwort eingefügt, um nachfolgende Anforderungen von demselben Benutzer an diese Anwendungsinstanz zu binden. Die Richtlinienkonfiguration definiert einen Cookie-Ablauf, der die Gültigkeitsdauer für jeden Cookie festlegt.

Routing-Algorithmus (weniger wahrscheinlich, dass Ihr Fall)

Lastenausgleich Knoten die Anforderung an gesunden Instanzen innerhalb derselben Availability Zone sendet die leastconns Routing-Algorithmus. Der Routing-Algorithmus leastcyns bevorzugt Back-End-Instanzen mit den wenigsten Verbindungen oder ausstehenden Anforderungen.

Quelle: Elastic Load Balancing Terminology And Key Concepts

Hoffnung, es hilft.