Zabbix OpenVPN Client Graphs

Verwundert habe ich festgestellt, dass es noch gar kein brauchbares Zabbix Template für die grafische Darstellung der verbundenen OpenVPN Clients gibt. Jedenfalls keines, was meinen Vorstellungen entspricht.

Ich habe mir deshalb ein Template erstellt:
Download Zabbix Template
Download userparameter_openvpn.conf (ggf. den Pfad zu OpenVPN anpassen)

Das Template einfach in Zabbix importieren und die userparameter Datei im Agentverzeichnis speichern (z.b. unter /etc/zabbix/zabbix_agentd.d/).
Anschließend den Zabbix Agent neu starten, dem Host das gerade importierte Template zuweisen und nach spätestens 20 Minuten werden die Graphs erstellt. Wer nicht warten möchte, kann den „Update interval“-Wert in der discovery Regel herabsetzen, wodurch die OpenVPN Server schneller erkannt werden.

Ergebnis:


Hochverfügbares WordPress-Cluster erstellen mit Jelastic

Der Schaden eines Komplettausfalls ist für jede Webseite immens. Einbrechende Besucherzahlen und Abstrafungen durch Suchmaschinenbetreiber sind die unmittelbaren Folgen. Deshalb sind Hochverfügbare-Dienste heute nicht mehr nur für große Unternehmen relevant.

Die sichere und stabile Konfiguration einer solchen Hochverfügbarkeitslösung ist jedoch nicht selten mit hohem Aufwand und erheblichen Kosten verbunden. Deshalb möchte ich in dieser kurzen Anleitung zeigen, wie sich ein hochverfügbares WordPress-Cluster in nur zwei Minuten mit Jelastic erstellen lässt.

 

WordPress-Cluster als fertigen Installer

Über den Marketplace im Jelastic Dashboard lässt sich das Paket WordPress-Cluster installieren.

Jelastic-Marketplace

Automatische-Installation

Die automatische Konfiguration der erforderlichen Instanzen dauert in der Regel 1-2 Minuten. Anschließend erhält man direkt den erforderlichen Admin-Zugang zu der WordPress-Installation.

Das hochverfügbare WordPress-Cluster besteht nun aus den folgenden Instanzen:

 

Nginx Load-Balancer

Die Lastverteilung erfolgt über zwei Nginx Load-Balancer, welche den Besuchertraffic immer optimal auf die Web- und Datenbankserver aufteilen. Sollte eine der Instanzen ausfallen, wird der Traffic automatisch umgeleitet, sodass es für die Webseitenbesucher zu keiner Beeinträchtigung kommt.

Nginx Webserver mit PHP

Zwei perfekt aufeinander abgestimmte Nginx-Instanzen dienen als Webserver mit PHP. Die Konfiguration der beiden Webserver ist bereits bestmöglich auf den Einsatz mit WordPress ausgerichtet.

MySQL-Datenbankserver

Natürlich sind auch die Datenbankserver redundant aufgebaut und von Jelastic vorkonfiguriert.

 

Fertig!

Nach nur wenigen Minuten steht eine hochverfügbare WordPress-Installation bereit für dessen Einrichtung und Konfigurations normaleweise Stunden erforderlich gewesen wären.

 

Falls Sie sich selber von dem Funktionsumfang überzeugen möchten, können Sie Jelastic unverbindlich 14-Tage kostenlos testen. Dazu benötigen Sie lediglich eine Email-Adresse, um sich im Dashboard zu registrieren.


Varnish unter Plesk samt SSL-Unterstützung

Ein Kunde von uns wollte Varnish in Verbindung mit Plesk betreiben. Er hat sich dafür an die diversen Anleitungen im Internet gehalten, aber die Einrichtung scheiterte. Die meisten Anleitungen basieren darauf, dass man den Frontend-Webserver auf einen alternativen Port setzt und Varnish auf Port 80 platziert. Derartige Vorgehensweisen haben jedoch diverse Nachteile und die SSL-Unterstützung fehlt.

Was ist Varnish und was bringt es?

Varnish kann dynamische und statische Inhalte cachen und verbessert die Webseitenperformance enorm. Varnish wird ausschließlich als Reverse-Proxy betrieben. Man muss also zusätzlich einen Backend-Webserver wie Apache verwenden.
Den Cache lagert Varnish standardmäßig im Arbeitsspeicher aus. Falls dem System wenig Arbeitsspeicher zur Verfügung steht, kann man über die Konfigurationsdatei den Cache in einer Datei auslagern. Allerdings ist der Arbeitsspeicher deutlich schneller und man erreicht damit in der Regel eine bessere Performance.

Zum Vergleich habe ich eine Wordpress-Testinstallation aufgesetzt:

WordPress Ladezeit – ohne Varnish Cache WordPress Ladezeit – mit Varnish Cache
:~$ time curl -s https://wp4.linevast.de/ > /dev/null
real 0m0.942s
user 0m0.044s
sys 0m0.008s
:~$ time curl -s https://wp4.linevast.de/ > /dev/null
real 0m0.330s
user 0m0.040s
sys 0m0.012s
In der linken Spalte wurde die Seite mit geleertem Cache aufgerufen. In der rechten Spalte das Ergebnis mit Cache. Die Ladezeit hat sich durch den Varnish-Cache mehr als halbiert. Für den Test wurde WordPress mit verschiedenen Plugins installiert um realistische Ergebnisse zu erhalten.

Plesk mit Varnish: Vorgehensweise

Diese Anleitung bezieht sich auf ein gewöhnliches Plesk-Setup – sprich Nginx als Frontend und Apache als Backend-Webserver.
Falls das Setup nicht wie gewünscht funktioniert oder man es erst mal nur testen möchte, kann man das gesamte Setup mit wenigen Befehlen rückgängig machen (siehe weiter unten).

Damit SSL-Verbindungen ebenfalls cached werden und es auch keine negativen Auswirkungen in Plesk gibt, platzieren wir Varnish nicht auf dem HTTP Port 80, sondern belassen die standardmäßigen Ports wie sie sind. Stattdessen leiten wir die Verbindungen von nginx auf Varnish um.
Der Verbindungsablauf sieht dann wie folgt aus:

 

1. Installation von Varnish

Varnish ist für diverse Linux-Distributionen verfügbar. In meiner Anleitung verwende ich CentOS 7. Über das EPEL-Repository kann Varnish installiert werden.

Hinweis: Varnish auf anderen Distributionen installieren
Varnish kann auf fast allen Distributionen installiert werden. Hier eine Anleitung für Debian. Die sonstigen Informationen dieses Eintrags gelten für alle Distributionen.

2. Konfiguration von Varnish

1. Damit Varnish weiß, ob es sich um eine HTTP- oder HTTPS-Anfrage handelt, wird Varnish auf zwei Ports gestartet. Ich habe dazu 6081 und 6080 ausgewählt.
Dazu öffnet man die Datei /etc/varnish/varnish.params und ersetzt die Zeile VARNISH_LISTEN_PORT=6081 mit VARNISH_LISTEN_PORT=6081,:6080

2. Damit Varnish die Anfragen richtig bearbeitet, muss man Regeln definieren. Man findet im Internet diverse fertige Regeln, beispielsweise diese hier für WordPress.
Die Regeln müssen in der Datei /etc/varnish/default.vcl festgelegt werden. Damit alles ordnungsgemäß in Verbindung mit Plesk funktioniert, wird ganz oben in der Datei immer folgendes definiert:

Wichtig: 'SERVERIP' ersetzen
Auch hier wieder darauf achten, dass die „SERVERIP“ mit der öffentlichen IP des Servers ersetzt wird. Würde man localhost oder 127.0.0.1 konfigurieren, funktioniert es aufgrund der Vhost-Konfiguration seitens Plesk nicht.
Hinweis: default.vcl Beispiel
Eine angepasste VCL gibt es hier – diese VCL gilt nur als Beispiel und basiert auf dem oben genannten GitHub-Template. In meinem Test funktioniert WordPress und das Caching damit. Ich würde jedoch empfehlen, sich in die Varnish-Konfiguration einzulesen und die VCL selbst zu erstellen (oder zu überarbeiten).

Nachdem die beiden Konfigurationen angepasst wurden, aktivieren wir den automatischen Start von Varnish und starten den Server:

Falls Varnish nicht startet, kann man sich per journalctl -xe das Problem ansehen.

3. Erstellen eines neuen Nginx-Vhosts & SSL-Termination

Nun erstellen wir einen neuen Nginx-Vhost, welcher die Verbindungen von Varnish an Apache weiterleiten wird. Prinzipiell könnte man auf diesen Vhost verzichten und die Verbindungen von Varnish direkt an Apache übergeben. Das hätte allerdings den Nachteil, dass Apache HTTPS Verbindungen nicht mehr erkennen würde. Der Webserver würde alle Anfragen als HTTP verarbeiten. Beispielsweise würden dadurch Umleitungen von HTTP auf HTTPS in einer Endlosschleife enden, sofern per .htaccess oder PHP (wenn PHP als Apachemodul ausgeführt wird) realisiert.

Um den neuen vhost anzulegen, wird folgendes ausgeführt:

Wer möchte, kann die Proxy-Parameter seinen Bedürfnissen entsprechend erweitern. Ein relevanter Parameter wäre beispielsweise client_max_body_size.

Wichtig: proxy_pass Parameter anpassen
Beim Parameter proxy_pass muss die IP des Servers angegeben werden. Sofern mehrere IPs genutzt werden, muss für jede IP ein Vhost angelegt werden.

4. Anpassen des Plesk vhost Templates

Das vhost Template von Plesk werden wir so umkonfigurieren, dass die Anfagen von Nginx an Varnish weitergeleitet werden. Varnish wird die Anfragen anschließend wieder zurück zum zuvor erstellten Nginx-Vhost leiten, welcher wiederum die Anfragen an Apache weiterleitet. Es klingt komplizierter als es ist.

Hinweis: Änderungen im Plesk-Template nachlesen
Die geänderten Stellen wurden kommentiert, sodass man sich in den Dateien ansehen kann, was verändert wurde.

5. Webserverkonfiguration neu erstellen

Damit die Konfigurationsänderungen auf allen bestehenden Domains übernommen werden, lassen wir diese neu erstellen.

Plesk sollte den Webserver automatisch neu starten und somit die neue Webserverkonfiguration übernehmen. Sollte das nicht passieren, kann man die Webserver manuell neu starten:

6. Varnish-Cache testen & leeren

Die Konfiguration ist hiermit abgeschlossen. Ruft jetzt eine Webseite auf und beobachtet die Ausgabe von varnishstat. Relevant sind die Werte MAIN.cache_hit und MAIN.cache_miss. Nach dem ersten Aufruf befindet sich die Seite im Cache. Weitere Aufrufe sollten den Wert von MAIN.cache_hit erhöhen. Dieser Wert gibt an, wie viele Anfragen aus dem Cache geladen wurden. MAIN.cache_miss hingegen gibt an, wie viele Anfragen durch den Backend-Webserver verarbeitet wurden.

Änderungen rückgängig machen – Varnish deaktivieren

Um die Änderungen rückgängig zu machen, reichen einige wenige Befehle: