Webseiten automatisch vor Überlast schützen am Beispiel einer MediaWiki-Seite

Das Szenario: Man ist stolzer Betreiber eines eigenen Servers auf dem ein Wiki läuft. Plötzlich berichtet Heise über das eigene Projekt oder man wird von einer anderen der großen Nachrichten-Portale verlinkt und plötzlich geht auf dem Server gar nichts mehr. Selbst der Zugriff per SSH um zu schauen was los ist funktioniert nicht mehr richtig und alle Nagios-Instanzen schlagen Alarm.

Damit es zu diesem Szenario nicht kommt, gibt es natürlich verschiedene Ansätze. Von redundant vorgehaltenen Servern, die per DNS Round-Robin angesprochen werden, über Loadbalancer auf Routingbasis, etc.

Viele dieser Maßnahmen sind aber entweder recht kostspielig oder haben den Nachteil nicht so gut mit soetwas wie einem Wiki zusammenzuarbeiten.

Es gibt aber eine weitere Möglichkeit, die den Dienst http://coralcdn.org benutzt.

Coral Content Distribution Network

Das Coral Content Distribution Network funktioniert transparent durch das Anhängen einer Domain des Dienstes an eine beliebige Webadresse. So wird aus www.google.de ganz schnell die gecachte Version, wenn man statt dessen www.google.de.nyud.net aufruft.

An dieser Stelle vielen Dank an rbu für den Hinweis auf Coral!

Doch wie kann man diesen Dienst benutzen, um ein Wiki bei Überlast des Servers noch einigermassen erreichbar zu halten?

Ein eigener Host für Coral

Zunächst habe ich zum Testen einen weiteren Virtual Host für das Wiki aufgesetzt, so dass ich dort Einstellungen machen kann, ohne das Wiki unbrauchbar zu machen.

Ausserdem hat das den Vorteil, dass ich https-Zugriffe verhindern bzw. umlenken kann, die über Coral natürlich nicht richtig funktionieren.

Und, noch etwas, dieser Virtual Host soll später vielleicht mal auf einen weiteren Rechner umziehen und kann so noch mehr Last abfedern, indem er statische Dateien wie Bilder direkt aus seinem Cache ausliefert.

Dieser VHost hört auf den originellen Namen cache.meinedomain.tld.

Folgende Parameter wurden (zusätzlich) gesetzt:

      #Dies soll ein Proxy werden, also Zugriff auf
      #folgende Seiten per proxy erlauben:

      <Proxy proxy:http://wiki.meinedomain.tld/ >
            Order deny,allow
            Allow from all
      </Proxy>

      ProxyVia On
      ProxyRequests Off

      #Diese Seite liefern wir auf / aus:
      ProxyPass / http://wiki.meinedomain.tld/
      ProxyPassReverse / http://wiki.meinedomain.tld/

      #Ausserdem Cachen wir auf der Festplatte
      CacheRoot /var/cache/apache2
      CacheDirLevels 2
      CacheDirLength 10
      CacheMinFileSize 10
      CacheMaxFileSize 2000000
      CacheEnable disk /
      CacheEnable disk http://wiki.meinedomain.tld/
      CacheEnable disk proxy:http://wiki.meinedomain.tld/

      #Die Cookies wollen wir nicht mit speichern...
      CacheDefaultExpire 3600
      CacheIgnoreHeaders Set-Cookie

      # Bis hier war das nur die (optionale) proxy-Konfiguration
      # kommen wir nun zum LoadBalancer

      RewriteEngine on
      RewriteCond %{HTTP_USER_AGENT} !^CoralWebPrx
      RewriteCond %{QUERY_STRING} !(^|&)coral-no-serve$
      RewriteMap    lb      prg:/var/www/loadbalance.sh
      RewriteCond   ${lb:%{REQUEST_URI}|NULL} !^NULL
      RewriteRule   ^(.*)$ ${lb:$1|%1}           [P,L]

Der zweite Block definiert ein shellscript als Entscheidungshilfe für das Ziel eines Redirects, wenn der Request nicht von dem coral-webproxy kam. Diese Ausnahme müssen wir konfigurieren, da wir sonst den Coral-Server auf sich selbst umlenken würden.

Und dieses Script ist auch schon das Geheimnis.

Das Redirect-Script

Das folgende Script wird vom apache sofort beim Start geforkt und erhält auf stdin fortan die angefragte URL und kann auf stdout dann ausgeben, wohin denn der Request umgelenkt werden soll.

Damit kann man nun nach eigenem Ermessen Paramter suchen, die für einen Redirect sorgen sollen.

Ich nehme hier das maximum von zweien der Load-Werte, so dass bei zuviel Ansturm die Besucher umgelenkt werden und mit Abflauen des Ansturms (die Besucher bleiben dann ja auf dem Proxy) auch wieder neue Besucherrequests angenommen werden.

Ein wenig zusammengehackt und sicherlich nicht die schnellste Implementierung, aber es erfüllt erstmal seinen Zweck, sollte aber durch ein C-Programm ersetzt werden, welches ein _wenig_ effizienter implementiert ist.

#!/bin/bash

loadbalancer="cache.meinedomain.tld.nyud.net";

while read LINE; do
 load="$(awk '{gsub("\\.",""); if ($1>$2){ print $1} else { print $2 }  }'< /proc/loadavg)"
 if [ "$load" -gt "$(cat /var/www/maxload.conf)" ]; then
   logger -t "loadbalance-cache" "redirecting due to load=$load. request: $LINE"
   printf "http://%s/%s\n" "${loadbalancer}" "${LINE}"
 else
   printf "NULL\n"
 fi
done

In der Datei /var/www/maxload.conf habe ich testweise einfach die Zahl 550 eingetragen, so dass ab einer Load größer 5.5 ein Redirect erfolgt.

Konfiguration des Wikis

Bei Zugriffen über den Proxy muss das Wiki read-only arbeiten. Dafür gibt es mehrere Gründe:

Zum Einen sollen nicht die privaten Previews eines Benutzers gecached werden, zum anderen redirecten wir ja wegen hoher Last - und ein Edit eines Artikels wird sicherlich nicht zum Senken der Last beitragen.

Dazu gibt es einen Codeblock in der LocalSettings.php des Wikis:

if ( preg_match( "/^CoralWebPrx/", $_SERVER['HTTP_USER_AGENT']) > 0
    || preg_match( "/coral-no-serve$/", $_SERVER['QUERY_STRING']) > 0) {

 $wgReadOnly="<span style=\"background-color:yellow;\">Das Wiki ist aus Lastgründen read-only. Du greifst daher gerade über ein Cache auf eine gespeicherte Version zu.</span>";
}

Dadurch verlieren wir zwar auch die PageHits-Zählung im Wiki, aber über einen Proxy werden diese ohnhin nicht mehr korrekt gezählt.

Konfiguration des Wiki-Hosts

Nachdem alles getestet ist und funktioniert, können wir bei Überlast alle Requests auf den Wikiserver direkt auf die cache-Variante von Coral lenken. Dies machen wir mit einigen Zeilen in der Definition des Virtual Hosts:

RewriteEngine on
RewriteMap    lbwiki      prg:/var/www/wiki.meinedomain.tld/loadbalance.sh

Folgende Regeln fügen wir nun an die .htaccess des Wikis an. Das muss geschehen, da wir dort noch andere Rewrite-Regeln definiert haben.

# Alle requests des coral-proxies auf den cache lenken,
# requests von unserem Cache nicht auf unser Cache umlenken.
RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteCond %{REMOTE_ADDR} !^IP.DES.EIGENEN.PROXIES$
RewriteCond %{HTTP_USER_AGENT} ^CoralWebPrx
RewriteRule   ^(.*)$ http://cache.meinedomain.tld/$1           [R,L]

RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteCond %{REMOTE_ADDR} !^IP_DES_CACHES$
RewriteCond %{QUERY_STRING} (^|&)coral-no-serve$
RewriteRule   ^(.*)$ http://cache.meinedomain.tld/$1           [R,L]


#Folgender Block prueft ob die load zu hoch ist und
#redirected dann auf den gecachten cache...
#RewriteMaps muessen global in der vhost konfig gemacht werden.
RewriteCond %{REMOTE_ADDR} !^127.0.0.1$
RewriteCond %{REMOTE_ADDR} !^IP_DES_CACHES$
RewriteCond %{HTTP_USER_AGENT} !^CoralWebPrx
RewriteCond %{QUERY_STRING} !(^|&)coral-no-serve$
RewriteCond   ${lbwiki:%{REQUEST_URI}|NULL} !^NULL
RewriteRule   ^(.*)$ ${lbwiki:$1|%1}           [R,L]

Wichtig ist hier, dem LoadBalancer einen anderen Namen zu geben.

Wir benutzen für diesen Artikel wieder dasselbe script, so dass direkt auf den Host cache.meinedomain.tld.nyud.net verwiesen wird.

Der erste Block ist eher 'Kosmetik' und verhindert, dass man auf wiki.meinedomain.tld über Coral zugreifen kann.