Archiv:2011/IT/Dokumentation/Webcache
Es wird diskutiert, den Hauptserver zukünftig durch verteilte, davorgeschaltete Webcaches (Reverse Proxies) zu entlasten, die im DNS-Round-Robin angesprochen werden.
Vorrangiges Ziel ist, die wahrgenommene Verfügbarkeit der Websysteme zu erhöhen. Dies soll einerseits durch die Entlastung des zentralen Servers durch Cacheing geschehen, andererseits auch durch Vorhalten von dezentralen Kopien, die auch bei Ausfall des Zentralservers weiter ausgeliefert werden (stale-if-error). Dies unterscheidet sich vom "klassischen" Loadbalancer-Ansatz, bei dem Anfragen von einem Loadbalancer auf mehrere Zentralserver verteilt werden.
Ansprechpartner für die Hauptsysteme und DNS stehen in AG IT-Infrastruktur
Vorteil der Cache-Lösung gegenüber den Static Mirrors ist, dass diese eine "Fire&Forget" Lösung sind:
- alle Funktionen verfügbar (Edits werden durchgereicht)
- keine weitere Arbeit (Anpassungen, Updates) benötigt
- erzeugen keine zusätzlichen Peak-Lasten auf dem Originalsystem (z.B. für periodische Updates)
Der Varnish Cache des LV NRW wird für die Landtagswahl NRW 2012 entsprechend konfiguriert.
Domains / Webpräsenzen
Domain | Original-IP | Status | Stand |
---|---|---|---|
www.piratenpartei.de | 94.23.165.40 | nur zentral | 24.09. |
wiki.piratenpartei.de | 94.23.165.40 | nur zentral | 24.09. |
vorhandene Reverse-Proxies
Um per DNS-RoundRobin verteilbar zu sein, müssen produktiv genutzte Reverse Proxies auf Port 80 betrieben werden. Port 443 muss per IP-Forwarding auf die Webserver weitergeleitet werden.
IP | Domain | Provider/Standort | Servertyp | Proxy | Cache | max. Traffic | Logging | HTTPS | Status | Stand | Ansprechpartner |
---|---|---|---|---|---|---|---|---|---|---|---|
195.50.185.61 | deinschild.de | Boreus, Stralsund | VPS | squid3 | maximal 5GB | UL | Kein Logging | Nein | DOWN (503) | 2009-09-25 | tbe |
81.169.133.97 | srv02.9it.de | Berlin | Root | squid3 | 5GB | 2TB | Kein Logging | Nein | DOWN | 2009-09-25 | Rüdiger Pretzlaff |
78.46.171.190 | piraten.docx.org | Topnetworks / Hetzner | Linux-VServer | squid3 | 5GB | 1TB | Kein Logging | Nein | DOWN | 2011-03-31 | DocX |
84.38.66.191 | prauscher.homeip.net | ispOne / Frankfurt | Linux-VServer | squid3 | 5GB | 500 GB | Kein Logging | Nein | UP | 2009-09-25 | Prauscher |
84.19.191.213 | piraten.geekig.de | nbiserv, Erfurt | Hardware | squid2.7 | 10 GB | 6000 GB | kein Logging | Ja | DOWN | 2009-09-26 | data |
Beim Typ wird unterschieden zwischen Hardware und (providerseitig) virtuell. Bei letzterem ist zu beachten, dass hohe Last eventuell zu Reaktionen des Providers führen kann, siehe piratenpartei.net bei der Europawahl 2009.
Testsysteme, die auf anderen Ports laufen:
IP | Domain | Provider/Standort | Servertyp | Proxy | Cache | max. Traffic | Logging | Status | Stand | Ansprechpartner |
---|---|---|---|---|---|---|---|---|---|---|
87.230.9.130:8080 | 21studios.de:8080 | Hosteurope, Köln | VPS | squid3 | maximal 5GB | 500GB | Kein Logging | DOWN wg. Serverwechsel | 2009-07-13 | 21studios |
Proxy-Software
Wichtig für die Funktion zur Entlastung der Hauptserver sowie sind folgende Funktionen:
- Cacheing der Webseiten, um möglichst viele Abfragen schon vor dem Hauptserver abfangen zu können
- Bei Wegbrechen des Hauptservers soll der Proxy statt der "neuen" Fehlermeldung möglichst die bisherigen Webseiten ausliefern (stale-if-error, siehe http://www.mnot.net/blog/2007/12/12/stale)
- Als Feature für 3.2 geplant. (Tracker Bug)
- Ab Squid 3.2 wird es auch Stale-while-revalidate geben. Siehe Links oben.
- großer Cache (optimal: in den die gesamte Site passt) um einen Ausfall des Hauptservers möglichst viele Anfragen noch aus dem Cache bedienen zu können
Squid
Squid 2.7 beherrscht sowohl stale-while-revalidate als auch stale-if-error.
Für Squid v3 kann folgende Konfiguration genutzt werden:
# squid3 Konfiguration # fuer forum.piratenpartei.de + wiki.piratenpartei.de + *.piratenpartei.de # ----------------------------------------------------------------------------- # hier die IP des Caches statt 444.333.222.11 eintragen! http_port 444.333.222.111:80 accel defaultsite=www.piratenpartei.de vhost # ggfs. Spool-Location und Size eintragen, hier: 5 GByte = 5000 MByte cache_dir ufs /var/spool/squid3 5000 16 256 # das war's - Standard konfig folgt... # ------------------------------- # die echten Webserver und was darauf laeuft cache_peer 178.19.71.116 parent 80 0 no-query originserver name=wiki_pp cache_peer_domain wiki_pp wiki.piratenpartei.de cache_peer 178.19.71.20 parent 80 0 no-query originserver name=forum_pp cache_peer_domain forum_pp forum.piratenpartei.de cache_peer 178.19.71.117 parent 80 0 no-query originserver name=www_pp cache_peer_domain www_pp .piratenpartei.de # ------------------------------- # ACL - wir erlauben nichts anderes als zu den Piraten-Seiten acl piraten dstdomain .piratenpartei.de http_access deny !piraten # default ACLs acl Safe_methods method GET HEAD PUT POST http_access deny !Safe_methods acl Safe_ports port 80 http_access deny !Safe_ports # ------------------------------- # Logging - "none" = off access_log none # nur fuer Debugging: # access_log /var/log/squid3/access.log # ------------------------------- # Done # Votan 14:24, 24. Mai 2012 (CEST)
Varnish
Auch wenn die Feature-Liste anderes behauptet beherrscht Varnish stale-if-error - dies muss allerdings über die VCL "programmiert werden (siehe http://varnish.projects.linpro.no/wiki/VCLExampleGrace )
Mögliche Konfiguration (RFC):
backend wiki_pp { .host = "wiki.piratenpartei.de"; .port = "80"; .probe = { .timeout = 500m; .interval = 10s; .window = 3; .threshold = 2; .request = "GET /Hauptseite HTTP/1.1" "Host: wiki.piratenpartei.de" "Connection: close"; } } backend forum_pp { .host = "forum.piratenpartei.de"; .port = "80"; .probe = { .timeout = 500m; .interval = 10s; .window = 3; .threshold = 2; .request = "GET /index.php HTTP/1.1" "Host: forum.piratenpartei.de" "Connection: close"; } } backend www_pp { .host = "www.piratenpartei.de"; .port = "80"; .probe = { .timeout = 500m; .interval = 10s; .window = 3; .threshold = 2; .request = "GET /index.php HTTP/1.1" "Host: www.piratenpartei.de" "Connection: close"; } } sub vcl_recv { if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "CONNECT") { error 403 "Forbidden"; } if (req.http.host == "wiki.piratenpartei.de") { set req.backend = wiki_pp; } elsif (req.http.host == "forum.piratenpartei.de") { set req.backend = forum_pp; } elsif (req.http.host ~ ".piratenpartei.de$" || req.http.host == "piratenpartei.de") { set req.backend = www_pp; } else { error 403 "Forbidden"; } if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ return (pass); } if (req.http.Authorization || req.http.Cookie) { /* Not cacheable by default */ return (pass); } # stale-if-error if (req.backend.healthy) { # stale-while-revalidate set req.grace = 2m; } else { set req.grace = 1h; } return (lookup); } sub vcl_fetch { if (!obj.cacheable) { pass; } if (obj.http.Set-Cookie) { pass; } set obj.grace = 1h; set obj.prefetch = -30s; return (deliver); }
Nginx (+ncache)
Nginx beherrscht mit dem HttpProxyModul inzwischen detailliert konfigurierbare Cache-Mechanismen, siehe [1]
Ältere Forenbeiträgen zufolge scheint er empfindlicher hinsichtlich Expiring zu reagieren und so nur eingeschränkt zu cachen. Dies wurde bisher nicht überprüft.
Inzwischen kann eine stale-if-error Funktion konfiguriert werden. [2]
HTTPS-Forwarding
Da HTTPS (HTTP via SSL, port 443) nicht vom HTTP-Proxy verarbeitet werden kann, ohne dass jeder Reverse-Proxy ein gültiges Zertifikat bekommt (was z.Zt. nicht möglich ist), müssen HTTPS-Anfragen auf IP-Ebene direkt an den Piratenpartei-Server weitergeleitet werden.
Im Kernel müssen die nötigen Optionen (netfilter/iptables, MASQUERADE target) aktiviert sein. IPv4-Forwarding muss erlaubt sein (`sysctl net.ipv4.ip_forward` muss 1 sein). Mit den folgenden iptables-Kommandos kann nun das IP-Forwarding für Port 443 an den Piratenpartei-Server eingerichtet werden:
iptables -A PREROUTING -t nat -p tcp --dport 443 -d x.x.x.x -i eth0 -j DNAT --to 94.23.165.40:443 iptables -A FORWARD -t filter -p tcp --dport 443 -d 94.23.165.40 -i eth0 -j ACCEPT iptables -A POSTROUTING -t nat -p tcp --dport 443 -d 94.23.165.40 -o eth0 -j MASQUERADE
- x.x.x.x muss durch die IP-Adresse, die du für den Piratenpartei-Reverse-Proxy verwendest, ersetzt werden (wichtig wenn der Server mehr als eine IP-Adresse hat, sonst werden alle HTTPS-Verbindungen zu den Piratenpartei-Servern weitergeleitet!).
- eth0 muss evtl. auch ersetzt werden, falls bei dir ein anderes Interface mit dem Internet verbunden ist.