Archiv:2011/IT/Dokumentation/Webcache

HINWEIS: Diese Seiten enthält Informationen, die vor allem für Mitarbeiter und Interessierte wichtig sind.

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.