In einem vorherigen Blogbeitrag (AWS - Migrieren eines ELB zum NLB on-the-fly) haben wir geziegt, wie man in AWS einen HA cluster mit Artifactory von einem “deprecated” ELB auf einen modernen NLB ohne Downtime umswitcht.
Kurz zum Setup
Das Setup von Artifactory umfasst drei Instanzen mit einem davor geschaltetem Loadbalancer von AWS. Jede Instanz von Artifactory selbst ist eine Tomcatanwendung und einem NGINX Reverse Proxy davor.
Vorherige Bedenken
Bedenken zum Switch von ELB zu NLB, die im Vorfeld vorhanden waren, bewahrheiteten sich nicht. Bedenken waren:
- Funktioniert Artifactory mit einem NLB als HA cluster. Der NLB arbeitet direkt auf dem TCP/TLS-Layer und nicht mehr auf Ebene des http(s)-Protokolls. Alle connections werden in einem SSL-handshake organisiert. Das bedeutet dass der Loadbalancer danach nicht mehr in Erscheinung ttritt. Die Client kommunizieren dirket mit dem NGINX Reverse Proxy.
- Bekommen die Nutzer von Artifactory Probleme mit dem self-signed certifiacte mit dem der NGINX Reverse Proxy läuft. Angemerkt muss bleiben, dass der LoadBalancer selbst mit einem von trusted certificate bereitgestellt von ACM läuft.
- AWS hat angemerkt, dass die Requests (Requests pro Sekunde) vom NLB schneller organisert werden, d.h. mehr Request pro Sekunde abgearbeitet werden. Bekommt Artifactory damit Probleme?
Ergebnis
Wie erwähnt waren die Bedenken unbegründet. Artifactory funktionierte mit dem NLB und die self-signed certificate hatten keine Auswrikung für die Clients. Diese sahen nur das trusted-certificate des NLB.
Wir haben kontinuierlich diverse Metriken via Datadog erfasst. In diesen sind den AWS Metriken (z.B. zum ELB und NLB) auch die Metriken aus den Systemen wie dem NGINX Reverse Proxy oder Artifactory berücksichtigt. Wir haben damit während des Switches eine durchgängige Metrikerfassung gewährleistet.
Die Metriken zeigten unerwartete Änderungen am unserem NGINX Reverse Proxy. Direkt nach dem Umstellung auf den NLB kommt der NGINX Reverse Proxy mit nur einem Drittel an TCP/TLS-Verbindungen aus.
Das Bild zeigt die Anzahl an connections über einen Zeitraum von 24 Stunden, die der NGINX Reverse Proxy über alle drei Artifactoryinstanzen offen gehalten hat. Man erkennt den Switch zum NLB um ~10:00 Uhr sehr deutlich.
Dies hatten wir nicht erwartet. Da Artifactory sowie NGINX Reverse Proxy in einer Microserviceumgebung basierend auf Docker aufgebaut war und sehr viele Anfragen auf dem Gesamtsytem auflaufen, war die Frage der maximalen Anzahl der konkurrierenden Connections immer immanent. Wir vermerkten ab einer bestimmten Anzahl an konkurrierenden Verbindungen die Erzeugung von HTTP-5xx Fehlren (“Internal Server Errors”). Verbindungen wurden nicht schnell genug abgeabeitet und damit abgebrochen.
Die Reduzierung um Zweidrittel war für uns sehr bemerkenswert. Auch vor dem Hintergrund, dass sich die Anzahl an Requests in dieser Zeit kaum verändert hat.
Das Bild zeigte die Anzahl der Requests über den gleichen 24-stündigen Zeitraum. In der Abendzeit zwischen ~18:00 Uhr abends and ~8:00 Uhr morgens ist die Anzahl der Requests zeitbeding niedrig. Ab ~8:00 Uhr morgens steigt die Anfragen an. Um 10:00 Uhr morgens, dem Switch auf den NLB, wurde kein signifikante Reduzierung der Anfragen gemesssen, d.h. der NGINX Reverse Proxy hat die gleiche Anzahl an Anfragen mit einem Drittel an Connections abgearbeitet oder anders ausgedrückt: Der NGINX Reverse Proxy kann jetzt mit einem Drittel der Verbindunge die geiche Anzahl an Anfragen abarbeiten. So wie es aussieht arbeitete der NGINX reverse proxy mit dem NLB sehr viel effizienter.
Analyse
Warum das so ist können wir aktuell nur spekulieren. Dadurch, dass der NLB nur noch Handshakes zwischen dem Client und dem Server organisiert ist damit eine direkte Kommunikation zwischen Client und Server möglich. Damit ist man eher in der Lage die Client/Server-Verbindung offen zu halten und wiederzuverwenden.
Der ELB ist zwischen dem Client und Server geklemmt und verteilt daher die Anfragen eines Clients eher auf die drei verschiedenen Artifactory-Server, so die Vermutung.
