In der Serie für die Loadbalancer für Artifactory hatten wir ja schon den OnTheFly-Switch vom ClassicELB zum Network Loadbalancer beschrieben (NLB) sowie die Änderungen an der Anzahl der konkurriernden Verbindungen dargestellt, die uns direkt nach der Umstellung auf den NLB aufgefallen sind (AWS - Reverse Proxy mit dem NLB in AWS).
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.
Probleme mit dem AWS Network Load Balancer
Wir haben den Loadbalancer jetzt einige Monate in der Produktionsumgebung laufen gelassen. Unser Bedenken haben sich auch nachträglich nicht bewahrheitet. Trotzdem sind wir im DevOps-Team übereingekommen, zum ClassicLoadbalancer zurückzugehen.
Verbindungsabbrüche
Es hat sich gezeigt, dass der NetworkLoadbalancer stabile Verbindungen nur im optimalen Fall aufrecht halten kann. Optimal in dem Sinne, dass die Verbindung zwischen Client und Server über ausreichend Bandbreite verfügt oder keine zu große räumliche Distanz zwischen beiden vorherscht, die zu Störungen führen können. Gerade bei Artifactory, mit der Möglichkeit des Downloads größerer Dateien ist das ein Problem.
Zudem kann Artifactory selbst nur schlecht mit Downloadunterbrechungen umgehen. Docker zum Beispiel nutzt “Resumable Pulls” (Docker - Resumable Pulls). “The client keeps the partial data and uses http Range requests to avoid downloading repeated data.” Mit Range Requests hat Artifactory aber Probleme gemäß einer Bugmeldung sowie durch die Bestätigung des jFrog-Supports (RTFACT-17182).
Artifactory ist jetzt “offen für die Welt”
Mit dem ClassicLoadbalancer konnte man über Security Groups die Kommunikation zwischen dem Loadbalancer und den Instanzen nach außen hin einschränken. “Die Welt” konnte sich nur mit dem Loadbalancer konnektieren, der dirkete Zugriff auf die Instanzen war durch die Firewall (Security Group) gesperrt. Dem NLB kann man aber keine Security Group zuweisen.
Der Grund ist vermutlich: Der NLB stellt nur noch einen Handshake zwischen dem Client und dem Server her und schickt sämtliche TCP/TLS packages vom Client zum Server (Artifactory), d.h der Client kommuniziert direkt mit Artifactory. Für den Server tritt der Loadbalancer nicht mehr in Erscheinung, kann daher auch nicht auf die Kommunikation mit diesen beschränkt werden. Dies hat als Resultat, dass die Server-Instanzen “offen zur Welt” sein müssen, bzw. auf die IP-Ranges der aufrufenden Clients eingeschränkt sein muss. Falls nicht alle Ranges bekannt sind muss für die Security Group der Artifactory-Instanzen das folgende Setup für Port 443 als Inbound Rule gewählt werden.
Für die Sicherheit stellt dies kein Problem dar, da auch der Aufruf von Artifactory über den SSL gesicherte Port 443 läuft. Zwar läuft hier im Hintergrund ein self-signed certificate, aber dies ist nur ein Problem für die Technik, z.B. würden Request aus einer Tomcatanwendung hier fehlschlagen. Aber dafür kommuniziert man ja gegen den NetworkLoadbalancer der über ein trusted-certificate von ACM verfügt. Es gibt für einen Client keinen Grund mit den Instanzen direkt zu kommunizieren.
Analyse der Fehler
Mit der Umstellung auf den NetworkLoadbalancer haben wir in Verbindung mit der Nutzung von Artifactory vermehrt Fehlermeldungen von unseren Kunden zurückgemeldet bekommen, die wir vorher nicht hatten. Diese wurden von verschiedenen Tools (Maven, Docker, Curl, Yarn usw.) und von unterschiedlichen Clients geworfen. Die Fehlermeldungen waren (Die URLs in den Meldungen wurde anonymisiert !):
curl https://thisurl.artifactory.de/artifactory/api/blobs/sha256:d7ca7c96d668289fb8d1ededdb9a6...89fc5b
{'errors':[{'code':'BLOB_UNKNOWN','message':'blob unknown to registry',...}
curl -k https://thisurl.artifactory.de/artifactory/repository/datadog-agent-6.13.0-1.x86_64.rpm \
--output test.rpm -v
curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104"`
docker build --tag <hidden> .
Sending build context to Docker daemon 11.78kB
Step 1/12 : FROM repository/production/centos:7
7: Pulling from repository/production/centos
gba884070f61: Downloading [==================================================>] 75.4MB/75.4MB
fa9bf97e24ad: Download complete
unexpected EOF
yarn install
yarn install v1.17.3
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error An unexpected error occurred:
"https://thisurl.artifactory.de/artifactory/api/npm/repository/npm/-/npm-6.10.3.tgz:
unexpected end of file".
yum install -y jq
Loaded plugins: langpacks, versionlock
https://thisurl.artifactory.de/artifactory/repository/repodata/6614b3605d96...97955780697-primary.sqlite.bz2:
[Errno 14] curl#56 - "TCP connection reset by peer"
Trying other mirror.
https://thisurl.artifactory.de/artifactory/repository/repodata/65b728bb447...b7860aaf042a-primary.sqlite.bz2:
[Errno 14] curl#56 - "TCP connection reset by peer"
Trying other mirror.
Die meisten Fehler traten auch nur sporadisch auf und konnten nur in seltenen Fällen reproduziert werden, was die Analyse und Lösung der Probleme erschwerte. Es gab aber zeitliche und geografische Schwerpunkte der Meldungen. Wir hatten in der Zeit mit mehrere Problemen und Änderungen umzugehen. Ein Problem war, dass an einem Firmenstandort die Bandbreite in die AWS Cloud (Direct Connect) temporär eingeschränkt war. Man hat dies an einer generellen Reduzierung der Downloadrate aus der AWS Cloud gemerkt. Zudem wurden via VPC peering neue AWS-Regionen aus den USA an Artifactory angebunden, das in einer europäischen Region betrieben wurde.
Es zeigte sich, dass die Meldungen aus den US-Regionen regelmäßig und aus dem Firmenstandort zu dem Zeitpunkt der eingeschränkten Netzbandbreite kamen. Meldungen aus der europäischen Region im Zusammenspiel mit Artifactory, die etwa 90% aller Anfragen ausmachten, wurden nicht vermerkt.
Ein Timeoutproblem konnte dabei ausgeschlossen werden. Manche Downloads wurden bereits nach ca. 25 Sekunden während des Downloads, weitab jeder Timeouteinstellung, abgebrochen Beispiel .
Analyse des Problems
Es war eindeutig, dass die Probleme im Zusammenhang mit dem Zusammenspiel zwischen dem NLB sowie eines überlasteten / instabilen Netzwerks herührte.
Fehler verursachten Anfragen aus den USA und aus dem Standort mit den temporären Netzwerkproblemen.
Wir analysierten die Probleme bis auf TCP-Level herunter (tcpdump). Hier zeigte sich zum Beispiel das Problem von Artifactory mit dem Rangerequest.
Request header:
User-Agent: docker/19.03.1 go/go1.12.5 git-commit/74b1e89 kernel/3.10.0-957.27.2.el7.x86_64 os/linux arch/amd64 UpstreamClient(docker-sdk-python/3.5.1)
Accept-Encoding: identity
Authorization: Bearer AKCp5bC1vqX<hidden>jWZ6JA6VL
Range: bytes=108628-
Umfasste der Header den Range-Parameter, kam es zum http-404 (“Not found”) Fehler in Artifactory.
Der Range-Request wurde aber von Docker pull bei unterbrochenen Verbindungen gefeuert. Da dies bei Netzwerkproblemen sehr häufig auftritt kam es vermehrt zu Downloadabbrüchen
wegen des Artifactorybugs (RTFACT-17182).
Behebung der Problems
Trotzdem konnte das DevOps-Team letztendlich das Problem lösen. Es zeigte sich, dass die Fehler auch mit dem NLB im Zusammanhang stehen, bzw. der NLB keine Mechanismen zur Stabilisierung von Verbindungen beinhaltet. Wenn wir die gleichen Requests zur gleichen Zeit und vom gleichen Standort gegen Artifactory mit einem ClassicLoadbalancer feuerten, traten die Fehler und Abbrüche nicht auf. Wegen der Netzwerkprobleme war aber die Downloadrate dann nicht sehr gut.
Vermutung zum Problem
Warum dies so ist, konnte uns auch der AWS Support nicht sagen. Eine Vermutung ist: Da der NLB nur noch ein Handshake zwischen Client und Server herstellt, d.h. die Kommunikation zwischen Client und Server direkt organisiert wird, fehlt damit ein stabilisierender Faktor bei Verbindugsabbrüchen. Der ClassicLoadbalancer umfasst mehr Logik, die die Verbindung auch bei Netzwerkproblemen für Artifactory aufrecht erhält. Dies ist wohl auch der Grund, warum der ClassicLoadbalancer im Vergleich zum ClassicLoadbalancer nicht so performant ist.
Beim NLB müsste die Stabilisierungsaufgabe letzendich der NGINX Reverse Proxy übernehmen. Der Aufwand für die Analyse und Umsetzung der Vermutung wären aber hoch.
Vor allem können HTTPS-Anfragen mit den klassischen Tools wie tcpdump wegen der Sicherung gar nicht analysiert werden.
