Marco Gabriel

Varnish ist ein extrem schneller caching reverse Proxy, der einem normalen Webserver vorgeschaltet wird. In der Regel beantwortet Varnish dann die Anfragen der Benutzer, entscheidet, ob er aus seinem eigenen Cache liefern kann und den Webserver dahinter nicht mehr fragen muss. Da Varnish den Proxy im Speicher hält, bedient er Anfragen extrem schnell. Was er nicht selbst bedienen kann, z.B. weil die Seiten aktive Inhalte haben oder nicht gecached werden dürfen, gibt er an den dahinter liegenden Webserver weiter. Darüber hinaus überwacht er die Webserver und verteilt Anfragen an mehrere Webserver. Fällt einer der Webserver aus, leitet Varnish dort einfach keine Anfragen mehr hin. Benutzer bekommen davon überhaupt nichts mit. Varnish ist übrigens auch völlig anpassbar über eine eigene Konfigurationssprache. Damit lassen sich extrem tolle Dinge relativ einfach realisieren.

Ich kam irgendwann auf die Idee, auch normale, einzelne Webserver mit einem Varnish auszustatten, um die Auslieferung von Web Inhalten zu beschleunigen. Zunächst klang das für mich bei allen oben genannten Vorteilen wie eine Verbesserung. Zumal der Varnish auf dem gleichen Host lief und über eine iptables Regel eingebunden wurde, d.h. mein Varnish war jederzeit im Betrieb transparent ein- und abschaltbar. Nicht mal die Webserver Konfiguration musste ich ändern.

Als ich mir die Statistiken des Varnish ansah, war dort allerdings kaum ein positiver Effekt zu erkennen. Die Cache Hit Rate war oft unter 1%, so dass sich kein erkennbarer Gewinn daraus erzielen liess. Varnishhist zeigt ein ähnliches Ergebnis, aber etwas schöner als Varnishstat:

Ausgabe von varnishhist: Unter (1) sieht man die Hits, unter (2) die an den Webserver weitergeleiteten Requests. Von links nach rechts erhöht sich die Antwortzeit.

Der Grund dafür ist recht schnell ausgemacht. Sobald Cookies existieren, geht Varnish von einer Session aus und leitet einfach alle Anfragen an den Webserver weiter. Da heute die meisten Websites Content Management Systeme für alles einsetzen, läuft bereits beim ersten Besuch ein Cookie auf und eine Session startet. Damit ist Varnish außen vor.

Varnish handelt an dieser Stelle völlig korrekt, um die Stabilität der Webanwendungen vor die Performance zu stellen.

Bei kleinen Webservern, die verschiedene Websites ausliefern und alle nicht auf Varnish optimiert sind, ergibt der Einsatz von Varnish deshalb (leider) auch keinen Sinn. Man kann mittels der Scriptsprache Varnish beibringen, dass er trotzdem statische Dateien wie Bilder, CSS, etc. cached, der Aufwand lohnt sich aus meiner Erfahrung heraus trotzdem nicht.

Neulich hatte ich eine Unterhaltung darüber, wie man die Laufzeit eines Programms möglichst einfach misst. Im konkreten Fall wollten wir wissen, wie lange ein mysqldump benötigt hat. Dazu gibts unter Linux den Befehl time, den man dem zu messenden Programm einfach voranstellt.

time <Programm und Parameter>
[...Ausgabe des Programms...]

real    0m56.754s
user    0m0.784s
sys    0m4.004s

Der Wert hinter real zeigt an, wie lange das Programm gelaufen ist, im obigen Beispiel 0 Minuten, 56 Sekunden und 754 Millisekunden.

Sicherlich ist es nicht nur legitim, sondern auch sinnvoll, die irgendwann einmal getroffenen Entscheidungen neu zu bewerten und zu prüfen, ob man richtig entschieden hat. So tut es die Stadtverwaltung München im Moment. Diese möchte erneut prüfen, ob man nicht zurück zu Windows wechseln möchte. München hatte vor Jahren für Aufsehen gesorgt als es entschied, die Stadtverwaltung auf Open Source Software umzustellen um damit langfristig kosten zu sparen und unabhängig von einzelnen Herstellern zu werden.

Wie ich nun in einem Golem Artikel gelesen habe, ist eine fehlende oder nicht ausreichende Groupware. Ich frage mich dabei, ob die Stadt München schon mal etwas von Zarafa gehört hat und ob ein Umstieg auf Zarafa für die gemeinsame Nutzung von E-Mail, Kalendern und Kontakten in Betracht gezogen wurde. Die vom  Oberbürgermeister angesprochenen Probleme erscheinen damit auch meiner eigenen Erfahrung nach jedenfalls sehr, sehr lösbar zu sein.

Natürlich halten sich auch Gerüchte, dass der plötzliche Wechsel vielleicht auch etwas mit dem neuerlich angekündigten Umzug der Microsoft Deutschland Zentrale nach München zu tun hat.

Was leider viel zu oft nicht bedacht wird, ist der Lock-In-Effekt bei der Verwendung proprietärer Software. Dieser sorgt vor allem beim Beenden einer Geschäftsbeziehung und dem Umstieg auf eine andere Lösung für Kosten. So sollte man auch betrachten, welche Kosten bei der Umstellung auf Linux entstanden sind, die eigentlich auf die vorher eingesetzte Software verbucht werden müssten - allerdings kommt diese Betrachtung meist zu kurz oder wird gar nicht erst gemacht.

Meiner Meinung nach macht die Stadt München einen gewaltigen Fehler, wenn sie nicht ergebnisoffen an diesen Rückblick geht und sich Microsoft an den Hals wirft. Gerade die öffentliche Hand sollte hier Vorreiter sein und auf offen verfügbare Standards setzen statt einem Hersteller die Tür zu öffnen, der sie dann auf Jahre in der Hand hat. Gerade jetzt, wo München die Umstellung quasi geschafft hat und nur noch die Verbesserung der Infrastruktur vorantreiben müsste.

Geht nicht? Geht doch. 

Und das Beste daran ist: "vimtutor" ist sehr wahrscheinlich schon installiert.

Einfach auf der Shell starten und den Anweisungen folgen:

vimtutor

vimtutor Screenshot

...könnte darauf hindeuten, dass rsync noch gar nicht installiert ist. 

apt-get install rsync

behebt das Problem.

Eben habe ich einen schönen Artikel gefunden, der diff, kompare und meld mal im Detail beschreibt. Ich nutze diff beispielsweise immer um bei Upgrades zu sehen, welche Optionen bei einer neuen Konfigurationsdaten dazu gekommen sind.

Sehr schöne Lösung: https://www.zabbix.com/forum/showpost.php?p=91083&postcount=18

Zabbix hat uns heute unseren Mailserver zugespammt mit berechtigten Fehlermeldungen. Eine einfache Möglichkeit, Mails eines bestimmten Absenders aus einer Postfix Queue zu löschen, bevor diese zugestellt werden, zeige ich hier (alles in einer Zeile):

mailq|grep absender@example.com|awk '{print $1}' > /tmp/zmails.tmp && while read LINE; do postsuper -d $LINE; done < /tmp/zmails.tmp && rm /tmp/zmails.tmp

Merke: Zeit richtig einstellen auf dem Zabbix Server hilft. 

Der besagte Zabbix Server hatte die falsche Zeitzone und ging damit zwei Stunden nach. Damit kamen bestimmte Pakete von anderen Agents nicht "rechtzeitig" und wurden verworfen. 

Nach Anpassung der Zeitzone mit

dpkg-reconfigure tzdata

lief die Queue auch schön leer.

Fragt man mit Zabbix per SNMP Hosts ab und erhält die Meldung

Error building asn.1 representation

liegt es vermutlich an den fehlenden (und vermutlich noch nicht installierten) MIBs. Um unter Debian/Ubuntu diese MIBs zu installieren, genügt ein

apt-get install snmp-mibs-downloader

Danach sollte Zabbix noch mal durchgestartet werden und die SNMP Fehlermeldung sollte weg sein.

Testen kann man dies beispielsweise mit

snmpget -v2c -c public <serveradresse> SNMPv2-MIB::sysUpTime.0

Erhält man wie erwartet die aktuelle Uptime als Antwort, werden die MIBs aufgelöst und es funktioniert.

Mit Cluster Filesystemen kann man schon ziemlich viel Zeit verbringen. Nicht nur beim Einrichten, sondern auch beim Warten auf Daten, die von eben jenen Filesystemen angefordert werden. 

Major Hayden beschreibt in seinem Blog, was ihn dazu bewogen hat, von GlusterFS auf ein OCFS2/DRBD Konstrukt zurück zu wechseln. Der Post ist schon von 2010, dürfte aber grundsätzlich noch immer relevant sein.

python -m SimpleHTTPServer

Der Befehl startet einen Webserver, der das aktuelle Verzeichnis über Port 8000 freigibt.

~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Man kann also nun über http://<adresse>:8000/ auf das Verzeichnis zugreifen. Da Python quasi überall vorhanden ist, werden keine weiteren Freigaben oder Software benötigt. Nicht einmal root Rechte braucht man dafür.

Wer einen anderen Port bevorzugt, kann diesen noch dahinter angeben:

python -m SimpleHTTPServer [port]

So etwas ähnliches gibt's auch in Bash, die obige Lösung finde ich aber einfacher.

Wenn man regelmäßig Daten transferieren oder abgleichen möchte, dann ist Rsync in der Regel das beste Mittel der Wahl. Rsync überträgt nur geänderte Dateien, tut dies sehr effizient, komprimiert dabei noch und verschlüsselt die Daten während des Transfers. Rsync funktioniert für regelmäßige Dateitransfers also extrem gut.

Schön wäre es nun, wenn man so etwas wie Rsync auch für sehr große Dateien oder Logical Volumes eines LVM verwenden könnte. Ein typischer Anwendungsfall ist die Sicherung von virtuellen Maschinen, bei denen diese Images auch schon mal mehrere hundert GB groß sind.

Wer hat schon zu viel Zeit? Und irgendwas zu optimieren gibt's doch immer:

• MySQL Tuning Primer Script in Launchpad
• MySQL Tuner (Unter Debian/Ubuntu auch über apt-get install mysqltuner installierbar)

Das Denken übernehmen die Scripte nicht, aber sie sind dabei sehr behilflich.

Neulich musste ich für die Umstellung eines Mailsystems ca. 3.300 Aliase umschreiben. Da diese Aliase aus mehreren Quellen stammen sollte das ganze auch automatisch und jederzeit wiederholbar sein. Ich kam irgendwann an den Punkt, an dem ich eine Datei lesen und mit jeder Zeile etwas tun musste. 

Der Klassiker in Bash ist einfach:

for LINE in $(cat /pfad/zur/datei)
do
    echo $LINE
done

Dazu gibt es jedoch eine meist bessere Alternative:

while read LINE
do
    echo $LINE
done < /pfad/zur/datei

Variante 2 nutzt das read Kommando unter Linux und liest die Datei wirkich zeilenweise, wogegen Version 1 wortweise liest.

Beispiel:

Quelldatei

zeile eins
zeile zwei

Ergebnis der Variante 1:

zeile
eins
zeile
zwei

Ergebnis der Variante 2:

zeile eins
zeile zwei

Mir gefällt mir die erste Variante durchaus besser von der Form, aber sie verhält sich eventuell nicht, wie man es erwarten würde.